T11.3: Customizes Terminology

Knowledge Review - HealthShare Unified Care Record Technical Specialist

1. Terminology Normalization

Key Points

  • Multi-Facility Problem: Different facilities use different codes for the same clinical concept
  • Federation Consistency: Normalization ensures data from all facilities is comparable and searchable
  • Standard Vocabularies: UCR normalizes to standards like SNOMED CT, LOINC, ICD-10, RxNorm, CPT
  • Ingestion-Time Processing: Normalization occurs during data ingestion at the Edge Gateway
  • Clinical Viewer Impact: Normalized data enables consistent display, filtering, and aggregation across facilities

Detailed Notes

Overview

In a UCR federation, data comes from multiple facilities, each potentially using different terminology systems and local codes. A laboratory at Hospital A might use code "GLU" for glucose testing while Hospital B uses "GLUC" and Hospital C uses "2345-7" (the LOINC code). Without normalization, the Clinical Viewer would display these as three unrelated tests, making it impossible to see a patient's glucose history across facilities.

Terminology normalization is the process of mapping facility-specific codes to a common standard vocabulary during data ingestion. This ensures that clinicians viewing consolidated patient data in the Clinical Viewer see a unified, consistent view regardless of which facility originated the data.

Why Normalization Matters

  • Clinical Safety: Clinicians need to see all allergies, medications, and diagnoses regardless of source coding
  • Duplicate Detection: Normalized codes enable identification of duplicate orders or results from different facilities
  • Analytics: Aggregated reporting across the federation requires consistent coding
  • Decision Support: Clinical decision rules depend on standardized codes to fire correctly
  • Interoperability: Sharing data with external systems requires standard vocabularies

Standard Vocabularies Used

  • SNOMED CT: Clinical terminology for diagnoses, procedures, findings
  • LOINC: Laboratory and clinical observation identifiers
  • ICD-10-CM/PCS: Diagnosis and procedure classification codes
  • RxNorm: Normalized drug names and codes
  • CPT/HCPCS: Procedure and service codes
  • CVX: Vaccine codes
  • NDC: National Drug Codes

Normalization Approaches

  • Code Translation: Map source codes directly to standard codes using translation maps
  • Code Matching: Use algorithms to match source descriptions to standard terminology when codes are not available
  • Pass-Through: Accept source codes that already use the target standard vocabulary without translation
  • Code Enrichment: Add standard codes to data that only has free-text descriptions

---

Documentation References

2. Coding Systems Configuration

Key Points

  • Coding System Definition: A named vocabulary or code set used within the federation
  • System Identifier: Each coding system has a unique identifier (OID or URI)
  • Source vs. Target: Source coding systems represent facility vocabularies; target systems represent federation standards
  • Registry Management: Coding systems are managed through the Hub registry interface
  • Facility Association: Each facility's data sources are associated with their coding systems

Detailed Notes

Overview

Coding systems are the foundational building blocks of terminology management in UCR. A coding system represents a specific vocabulary or terminology standard, such as LOINC, SNOMED CT, or a facility's local laboratory codes. Configuring coding systems properly is the first step in establishing terminology normalization, as translation maps, code sets, and profiles all reference specific coding systems.

Each coding system in the federation is identified by a unique identifier (typically an OID) and contains a collection of codes with their associated descriptions and metadata.

Configuring Coding Systems

1. Navigate to the terminology management interface in the UCR Management Portal 2. Define each coding system with a unique name and identifier (OID) 3. Specify the type of coding system (standard vocabulary, local system, or custom) 4. Associate the coding system with its source (facility, standard body, etc.) 5. Import or manually enter the codes belonging to the system

Key Coding System Properties

  • Name: Human-readable name (e.g., "LOINC 2.74", "Hospital A Lab Codes")
  • OID: Object Identifier for IHE interoperability
  • Code Type: Indicates what kind of clinical data the codes represent (diagnoses, labs, medications, etc.)
  • Version: Version information for standard vocabularies
  • Status: Active or inactive

Coding System Relationships

  • Source coding systems are linked to specific facilities through assigning authorities
  • Target coding systems are the federation standards that source codes are translated to
  • Translation maps define the relationships between source and target coding systems
  • InboundCodeSystemProfiles associate data feeds with their source coding systems

---

Documentation References

3. Code Sets

Key Points

  • Code Set Definition: A defined collection of valid codes within a coding system
  • Code Properties: Each code has a value, description, and optional metadata
  • Import/Export: Code sets can be bulk imported from files or exported for sharing
  • Maintenance: Codes can be added, modified, or deprecated over time
  • Validation: Code sets enable validation of incoming data against known valid codes

Detailed Notes

Overview

Code sets are collections of individual codes within a coding system. While a coding system defines the vocabulary framework, code sets contain the actual code values, descriptions, and metadata. Managing code sets involves creating new codes, updating existing ones, deprecating obsolete codes, and importing bulk code data from external sources.

Well-maintained code sets are essential for accurate terminology translation and validation. They serve as the reference data that translation maps use to convert source codes to target codes.

Creating Code Sets

1. Select the target coding system 2. Add individual codes with their values and descriptions 3. Include additional metadata as needed (effective date, status, category) 4. For standard vocabularies, import from official distribution files 5. For local vocabularies, work with facility staff to document their code sets

Bulk Import

  • Code sets can be imported from CSV, XML, or other structured formats
  • Import processes validate code uniqueness and format
  • Existing codes can be updated or preserved during import
  • Import logs identify any errors or conflicts

Code Set Maintenance

  • Regularly review and update code sets as vocabularies evolve
  • Deprecate codes that are no longer valid (do not delete, as historical data may reference them)
  • Add new codes as facilities introduce new tests, procedures, or diagnoses
  • Track version changes for standard vocabularies (e.g., annual ICD-10 updates)
  • Coordinate code set updates across the federation

---

Documentation References

4. Translation Maps

Key Points

  • Translation Map: Defines mappings from source codes to target codes
  • One-to-One Mapping: Single source code maps to single target code
  • Many-to-One Mapping: Multiple source codes map to the same target code
  • Map Structure: Source system + source code → Target system + target code
  • Maintenance Interface: Manage maps through the UCR management interface or bulk import

Detailed Notes

Overview

Translation maps are the core mechanism for converting codes from one coding system to another in UCR. A translation map defines explicit mappings between source codes (from a facility's local vocabulary) and target codes (from the federation's standard vocabulary). During data ingestion, the Edge Gateway applies translation maps to convert incoming codes to the normalized standard.

Creating accurate translation maps requires collaboration between clinical informaticists who understand the source codes and terminology experts who can identify the correct standard code equivalents.

Translation Map Structure

  • Each entry in a translation map contains:
  • Source Coding System: The originating vocabulary
  • Source Code: The code value from the source system
  • Target Coding System: The destination vocabulary
  • Target Code: The equivalent code in the target system
  • Target Description: The standard description for the target code
  • Maps are directional: a map from System A to System B is separate from B to A

Creating Translation Maps

1. Identify the source coding system and its codes 2. Identify the target coding system (federation standard) 3. For each source code, determine the equivalent target code 4. Enter mappings individually or import in bulk 5. Review mappings for accuracy with clinical subject matter experts 6. Test mappings with sample data from the source facility

Mapping Strategies

  • Direct Mapping: When source and target codes have a clear one-to-one equivalence
  • Many-to-One: When multiple source codes represent the same concept at different granularity
  • Default Mapping: A fallback mapping for unmapped codes (e.g., map to "Other" or pass through)
  • No Mapping: Some codes may intentionally remain untranslated if no equivalent exists
  • Hierarchical Mapping: Map to a broader category when an exact equivalent is not available

Common Challenges

  • Source codes with no target equivalent (clinical review needed)
  • Ambiguous source codes that could map to multiple targets
  • Source codes that represent combined concepts requiring splitting
  • Version changes in target vocabularies requiring map updates
  • Volume of mappings for large code sets (thousands of codes)

---

Documentation References

5. Code Registry (Coded Entry Registry)

Key Points

  • Coded Entry Registry: Central registry for managing terminology entries across the federation
  • Hub-Based: Managed at the Hub (Registry) level for federation-wide consistency
  • CRUD Operations: Add, modify, and delete coded entries
  • Search and Browse: Find entries by code, description, or coding system
  • Federation Distribution: Registry entries are available to all Edge Gateways and Access Gateways

Detailed Notes

Overview

The Coded Entry Registry (also referred to as the Code Registry) is a centralized repository for managing coded terminology entries across the UCR federation. Located at the Hub, it serves as the authoritative source for coded values used in translation maps, display configurations, and data validation. The Coded Entry Registry ensures consistency by providing a single point of management for terminology data that is shared across all federation components.

Managing the Coded Entry Registry involves adding new entries, modifying existing ones, deleting obsolete entries, and ensuring that entries are properly distributed to Edge Gateways and Access Gateways.

Registry Operations

  • Add Entries: Create new coded entries with code value, description, coding system, and metadata
  • Modify Entries: Update descriptions, status, or metadata for existing entries
  • Delete Entries: Remove entries that are no longer valid (with caution for historical data)
  • Search: Find entries by code value, description text, or coding system
  • Browse: Navigate entries by coding system or category

Managing Coded Entries

1. Access the Coded Entry Registry through the UCR Hub management interface 2. Select the target coding system 3. Add new entries or modify existing ones 4. Validate entries against the official vocabulary source 5. Publish changes to make them available across the federation

Best Practices

  • Establish a governance process for terminology changes
  • Require clinical review for additions and modifications
  • Maintain audit trails for all registry changes
  • Coordinate updates with translation map maintenance
  • Schedule regular reviews of registry content for accuracy
  • Back up registry data before major changes

---

Documentation References

6. Inbound Code System Profiles

Key Points

  • Profile Purpose: Associates a data feed with its source coding systems and translation requirements
  • Edge Gateway Setting: Configured on Edge Gateway production components
  • Per-Facility Configuration: Each facility can have its own InboundCodeSystemProfile
  • Coding System Mapping: Maps data categories (diagnoses, labs, meds) to source coding systems
  • Translation Activation: Triggers appropriate translation maps during data ingestion

Detailed Notes

Overview

Inbound Code System Profiles are configuration objects that tell the Edge Gateway which coding systems to expect from a particular data source and how to handle code translation for that source. Each facility feeding data to an Edge Gateway may use different coding systems, and the InboundCodeSystemProfile ensures that the correct translation maps are applied to normalize the incoming codes.

Setting the InboundCodeSystemProfile is a critical step in configuring a new data feed, as it determines how terminology normalization is performed during ingestion.

Profile Configuration

  • Each profile defines a set of coding system associations for different data categories:
  • Diagnosis codes: source coding system (e.g., "Hospital A ICD-10 Local")
  • Lab codes: source coding system (e.g., "Hospital A Lab Codes")
  • Medication codes: source coding system (e.g., "Hospital A Pharmacy Codes")
  • Procedure codes: source coding system (e.g., "Hospital A CPT Local")
  • Each category association links to the appropriate translation map

Creating an Inbound Code System Profile

1. Navigate to the profile management interface 2. Create a new profile with a descriptive name (e.g., "Hospital A Inbound Profile") 3. For each data category, specify the source coding system 4. Associate each category with the appropriate translation map 5. Save the profile 6. Assign the profile to the Edge Gateway component processing data from that facility

Application to Edge Gateway

  • Set the InboundCodeSystemProfile property on the appropriate business host
  • The profile is applied during the transformation/normalization phase
  • When a coded value is encountered in incoming data, the profile identifies the source coding system
  • The associated translation map is consulted to find the target code
  • The normalized code replaces or augments the original code in the SDA

---

Documentation References

7. Translation Profile Relationship

Key Points

  • Two-Part Configuration: InboundCodeSystemProfile identifies source codes; TranslationProfile activates translation
  • InboundCodeSystemProfile: Declares which coding systems a data source uses
  • TranslationProfile: Specifies which translation maps to apply for normalization
  • Combined Effect: Together they ensure incoming codes are correctly identified and translated
  • Configuration Location: Both are set on Edge Gateway production components

Detailed Notes

Overview

Terminology normalization in UCR requires two complementary configuration settings working together: the InboundCodeSystemProfile and the TranslationProfile. The InboundCodeSystemProfile declares which coding systems the incoming data uses, while the TranslationProfile specifies the translation maps that convert those source codes to federation-standard codes. Both settings must be correctly configured on the Edge Gateway production components for normalization to work.

Understanding the relationship between these two settings is essential for configuring new data feeds and troubleshooting normalization issues.

InboundCodeSystemProfile Role

  • Identifies the coding systems expected in incoming data
  • Associates each data category with a source coding system
  • Provides context for the translation engine to know what type of codes it is processing
  • Without this profile, the system cannot determine which translation map to apply

TranslationProfile Role

  • References the translation maps that perform the actual code conversion
  • Specifies the target coding system for normalization
  • Controls whether translation is applied (if not set, no translation occurs)
  • Can reference multiple translation maps for different code categories

How They Work Together

1. Data arrives at the Edge Gateway with coded values (e.g., diagnosis code "J18.9" from coding system "ICD-10-CM") 2. The InboundCodeSystemProfile identifies the source coding system for the diagnosis category 3. The TranslationProfile determines which translation map applies to that coding system 4. The translation map is consulted to find the target code (e.g., SNOMED CT equivalent) 5. The normalized code is placed in the SDA along with or in place of the original code 6. The normalized SDA is stored in the ECR

Troubleshooting Normalization

  • No Translation Occurring: Verify both InboundCodeSystemProfile and TranslationProfile are set on the correct production component
  • Wrong Translation: Check that the InboundCodeSystemProfile correctly identifies the source coding system
  • Missing Translations: Review the translation map for unmapped codes; add missing mappings
  • Partial Translation: Some data categories may lack profile or map configuration; check each category
  • Testing: Use sample messages and trace the message flow to verify translation is applied at the correct pipeline stage

Configuration Checklist

1. Define coding systems for all source vocabularies 2. Create translation maps from each source system to the federation standard 3. Create an InboundCodeSystemProfile for each data source/facility 4. Set the InboundCodeSystemProfile on the Edge Gateway production component 5. Set the TranslationProfile on the Edge Gateway production component 6. Test with sample data from the source facility 7. Verify normalized codes in the ECR and Clinical Viewer

---

Documentation References

Exam Preparation Summary

Critical Concepts to Master:

  1. Normalization Purpose: Understand why terminology normalization is essential in a multi-facility federation
  2. Coding Systems vs. Code Sets vs. Translation Maps: Know the hierarchy — coding systems contain code sets, translation maps link coding systems
  3. Coded Entry Registry: Understand the role of the centralized Coded Entry Registry at the Hub
  4. InboundCodeSystemProfile: Know how to configure profiles that identify source coding systems for each data feed
  5. TranslationProfile: Understand how TranslationProfile activates translation maps during ingestion
  6. Two-Setting Relationship: Master how InboundCodeSystemProfile and TranslationProfile work together for normalization

Common Exam Scenarios:

  • Configuring terminology normalization for a new facility joining the federation
  • Creating translation maps from local lab codes to LOINC
  • Troubleshooting why codes are not being translated during data ingestion
  • Setting up InboundCodeSystemProfile for a facility that uses multiple local coding systems
  • Managing the Coded Entry Registry when a facility changes its terminology
  • Understanding the impact of missing or incorrect translation maps on Clinical Viewer display

Hands-On Practice Recommendations:

  • Configure coding systems for a sample source vocabulary and target standard vocabulary
  • Create a translation map with several code mappings
  • Set up an InboundCodeSystemProfile for a test data feed
  • Configure TranslationProfile and verify that codes are translated during ingestion
  • Use the Coded Entry Registry to add, modify, and search for coded entries
  • Test the full normalization pipeline with sample HL7 messages containing local codes
  • Troubleshoot a scenario where normalization is not working (missing profile, incomplete map)

Report an Issue