T2.3: Customizes Terminology

Overview

In a HealthShare Unified Care Record (UCR) environment, data flows in from multiple facilities, each potentially using different local code sets for the same clinical concepts. A laboratory at one hospital might use "GLU" for glucose while another uses "GLUC" and a third uses the LOINC code "2345-7." Without terminology management, the Clinical Viewer cannot aggregate these as a single concept, resulting in fragmented patient histories and potential clinical risk.

Terminology management in UCR addresses this challenge by providing tools to normalize, translate, and enrich coded data during ingestion. This ensures that all data stored in the Edge Clinical Record (ECR) uses consistent, standardized codes, enabling meaningful aggregation and display across the federation.

Key Code Systems

• ICD-10-CM/PCS: International Classification of Diseases, 10th Revision, Clinical Modification (diagnoses) and Procedure Coding System (inpatient procedures). Required for billing and regulatory reporting.
• SNOMED CT: Systematized Nomenclature of Medicine - Clinical Terms. Comprehensive clinical terminology covering diagnoses, findings, procedures, body structures, and more. Used as a reference standard for normalization.
• LOINC: Logical Observation Identifiers Names and Codes. Standard for identifying laboratory and clinical observations. Essential for lab result aggregation across facilities.
• CPT/HCPCS: Current Procedural Terminology and Healthcare Common Procedure Coding System. Used for outpatient procedures and services.
• RxNorm: Standard for normalized drug names and codes. Enables medication reconciliation across facilities.
• CVX: Vaccine administered codes. Used for immunization records.
• NDC: National Drug Codes. Product-level drug identifiers.

Use Case Categories

• Interoperability: When sharing data via IHE profiles (XDS, XCA, PIX/PDQ), standard terminology is expected. Partners and health information exchanges require recognized code systems.
• Reporting: Population health reports, quality measures, and dashboards depend on consistent coding. A report counting diabetic patients must recognize all variations of diabetes codes across facilities.
• Clinical Decision Support: Alerting rules (e.g., drug interaction checks, allergy alerts) fire based on specific coded values. Without normalization, alerts may fail to trigger when local codes are used.
• Data Aggregation: The Clinical Viewer merges data from multiple sources. Terminology normalization ensures that lab results, medications, and diagnoses from different facilities appear as unified lists rather than duplicated entries.

---

Code Translation

Code translation is the most common approach. It uses explicit mapping tables (translation maps) to convert a source code from one coding system to an equivalent code in a target coding system. For example, translating a local lab code "BMP14" to LOINC code "51990-0" (Basic Metabolic Panel).

Translation maps are created per source-target coding system pair and are applied during data ingestion at the Edge Gateway. They require upfront effort to build but provide precise, predictable results.

Code Normalization

Code normalization is a broader term that encompasses translation but also includes ensuring that codes already in a standard vocabulary are validated and consistently formatted. Normalization may involve:

• Verifying that an incoming ICD-10 code is valid in the current code set
• Standardizing code formatting (removing dots, padding, case normalization)
• Mapping deprecated codes to their current equivalents
• Ensuring consistent use of code system identifiers (OIDs)

Code Enrichment

Code enrichment applies when incoming data lacks coded values entirely or has only free-text descriptions. The system can attempt to assign standard codes based on text matching algorithms. This is less precise than explicit translation but can recover coded data from text-only sources.

Enrichment scenarios include:

• Allergy descriptions that arrive as free text without codes
• Diagnosis descriptions from legacy systems without ICD-10 codes
• Medication names without RxNorm or NDC codes

When to Use Each Approach

Approach	Use When	Precision
Code Translation	Source uses known local codes consistently	High
Code Normalization	Source already uses standard codes but needs validation	High
Code Enrichment	Source provides only text descriptions	Medium
Pass-Through	Source codes are already in the target standard	Exact

---

Code Set Format

A code set within UCR consists of entries that each contain:

• Code Value: The actual code string (e.g., "J18.9", "2345-7")
• Description: Human-readable text describing the concept (e.g., "Pneumonia, unspecified organism")
• Coding System: The parent vocabulary this code belongs to
• Status: Active, inactive, or deprecated
• Effective Date: When the code became valid
• Expiration Date: When the code was retired (if applicable)

Import Mechanisms

Standard vocabularies are loaded from their official distribution files:

1. LOINC: Downloaded from the LOINC website as a CSV file. The import process maps CSV columns to UCR code set fields. 2. ICD-10-CM: Distributed by CMS as flat files. UCR provides importers for the standard distribution format. 3. SNOMED CT: Distributed as RF2 files. Import processes parse the concept and description files. 4. RxNorm: Distributed by NLM as RRF files. Import processes extract NDC-to-RxNorm and drug name mappings.

Custom or local code sets are typically prepared as CSV files with columns for code value, description, and optional metadata.

Management Portal Interface

To manage code sets through the Management Portal:

1. Navigate to HealthShare > UCR Management > Terminology 2. Select the coding system to manage 3. Use the Import function to load codes from files 4. Use the Browse function to view existing codes 5. Use the Edit function to modify individual code entries 6. Use the Add function to create new code entries manually

Bulk Loading Best Practices

• Always validate import files before loading (check for duplicates, format issues)
• Load standard vocabularies during initial setup before configuring translation maps
• Schedule regular updates when new vocabulary versions are released (e.g., annual ICD-10 updates)
• Maintain a record of which vocabulary versions are loaded
• Test after loading to verify code availability in translation maps

Modifying Existing Entries

• Adding a Code: Navigate to the coding system and create a new entry with code value and description
• Updating a Description: Edit the existing entry to correct or improve the description text
• Deprecating a Code: Set the status to deprecated and add an expiration date; do not delete, as historical data may reference the code
• Activating a Code: Set the status to active for newly approved codes

---

Overview

Not all data sources explicitly identify the coding system for every coded element in their messages. HL7 v2 messages may send a diagnosis code without specifying ICD-10-CM in the coding system field (CE/CWE segment). When this happens, the Edge Gateway needs a default coding system assignment to properly process and translate the code.

Default code set configuration tells the system: "When data from this feed contains a code without an explicit coding system, assume it belongs to this coding system."

Configuring Defaults

Default code sets are configured as part of the InboundCodeSystemProfile for each data feed:

1. Create or edit the InboundCodeSystemProfile for the data source 2. For each data category (diagnoses, labs, medications, procedures), specify the default coding system 3. The default applies when the incoming message does not include a coding system identifier 4. If the incoming message does include a coding system, the explicit value takes precedence over the default

Handling Unmapped Codes

When an incoming code does not exist in the default code set or has no translation map entry, several behaviors are possible:

• Pass-Through: Store the code as-is without translation. The original code and its source system are preserved.
• Log and Pass-Through: Store the code and generate a log entry for review. This helps identify gaps in translation maps.
• Default Mapping: Apply a catch-all mapping (e.g., map unmapped diagnosis codes to "R69" - Illness, unspecified).
• Rejection: Reject the code entirely. This is rarely used in production but can be appropriate during testing.

Best Practices

• Always configure default code sets for every active data feed
• Review unmapped code logs regularly to identify codes that need translation map entries
• Work with source facilities to improve code system identification in their outbound messages
• Document the default code set assignments for each facility in the federation configuration guide
• When a facility upgrades its EHR, review whether the default code set assignments are still correct

---

Overview

Code System Profiles (formally InboundCodeSystemProfiles) are configuration objects that describe the terminology characteristics of a specific data source. They answer the question: "What coding systems does this facility use for each category of clinical data?" This information is essential for the Edge Gateway to know which translation maps to apply during data ingestion.

Each facility feeding data into the UCR federation should have its own Code System Profile, as different facilities typically use different local code sets even if they share some standard vocabularies.

Creating a Code System Profile

1. Identify Source Coding Systems: Work with the facility to document which coding systems they use for each data category 2. Create the Profile: In the UCR management interface, create a new InboundCodeSystemProfile with a descriptive name 3. Configure Categories: For each clinical data category, specify:

• The source coding system (the facility's local vocabulary or standard vocabulary)
• The translation map to apply (from source to federation standard)
• Default behavior for unmapped codes

4. Save and Validate: Save the profile and review the configuration for completeness

Applying Profiles to Data Feeds

• Open the Edge Gateway production configuration
• Select the business host or process that handles data from the target facility
• Set the InboundCodeSystemProfile property to reference the created profile
• Ensure the corresponding TranslationProfile is also set to activate translation
• Restart the business host to apply the new configuration

Profile Settings and Behavior

• Coding System Override: The profile's coding system assignment overrides any coding system specified in the incoming data (when configured to do so)
• Translation Activation: Translation only occurs for categories where both a coding system and a translation map are configured
• Missing Category: If a data category is not configured in the profile, codes in that category pass through without translation
• Multiple Profiles: An Edge Gateway can have multiple profiles for different data sources, each assigned to the appropriate business host

Common Profile Configurations

Facility Type	Diagnosis System	Lab System	Medication System
Large Hospital	ICD-10-CM (standard)	Local lab codes	RxNorm (standard)
Small Clinic	ICD-10-CM (local subset)	Local lab codes	NDC
Lab System	N/A	LOINC (standard)	N/A
Pharmacy	N/A	N/A	RxNorm + NDC

---

Overview

Terminology translation maps are the core mechanism by which UCR converts codes from one coding system to another during data ingestion. A translation map defines explicit, entry-by-entry mappings between source codes and target codes. When properly configured and linked to Code System Profiles, translation maps enable automatic code normalization as data flows through the Edge Gateway.

Building complete and accurate translation maps is one of the most labor-intensive aspects of UCR implementation, but it is essential for meaningful data aggregation in the Clinical Viewer.

Creating Translation Maps

##### Manual Creation 1. Navigate to the terminology management interface 2. Select Translation Maps and create a new map 3. Specify the source coding system and target coding system 4. Add individual mapping entries:

• Source code value (e.g., "GLU")
• Source description (e.g., "Glucose, Serum")
• Target code value (e.g., "2345-7")
• Target description (e.g., "Glucose [Mass/volume] in Serum or Plasma")

5. Save each entry and continue adding mappings

##### Bulk Import from Files For large code sets, manual entry is impractical. Translation maps can be loaded from structured files:

1. Prepare a CSV file with columns: source_code, source_description, target_code, target_description 2. Navigate to the translation map import function 3. Select the source and target coding systems 4. Upload the CSV file 5. Review the import preview for errors or conflicts 6. Confirm the import to load all mappings

Loading Maps from Files

File-based loading supports several formats:

• CSV Format: Most common; columns map to source code, source description, target code, target description
• XML Format: Structured format with explicit element names for each mapping field
• Tab-Delimited: Simple format for facilities that export mapping tables from spreadsheets

Import considerations:

• Validate that source codes exist in the source coding system
• Validate that target codes exist in the target coding system
• Handle duplicate mappings (same source code mapped to different targets)
• Log import results for review (successes, failures, warnings)

Mapping Source Codes to Target Codes

Mapping strategies vary based on the relationship between source and target codes:

• One-to-One: A single source code maps to exactly one target code. This is the ideal case and provides the most precise normalization.
• Many-to-One: Multiple source codes map to the same target code. Common when the source system uses more granular codes than the target standard.
• One-to-Many: A single source code could map to multiple target codes. This is unusual and typically indicates that the source code is too broad. Requires clinical review to select the most appropriate target.
• Default/Fallback: A catch-all mapping applied when no specific mapping exists. Maps unmapped codes to a generic "other" or "unspecified" target code.

Applying Maps in Transformations

Translation maps are applied during Edge Gateway data processing:

1. The Edge Gateway receives an incoming message (e.g., HL7 v2 ADT or ORU) 2. During SDA transformation, coded elements are identified (diagnoses, lab codes, medications, etc.) 3. The InboundCodeSystemProfile identifies the source coding system for each element 4. The TranslationProfile determines which translation map to apply 5. For each coded element, the translation map is consulted:

• If a mapping exists, the target code replaces or supplements the source code
• If no mapping exists, the fallback behavior applies (pass-through, default mapping, or logging)

6. The normalized SDA is stored in the Edge Clinical Record (ECR)

Maintenance and Governance

• Regular Reviews: Schedule periodic reviews of translation maps to identify gaps (unmapped codes in logs)
• Version Updates: When target vocabularies release new versions (e.g., annual ICD-10 updates), review and update maps
• Clinical Validation: Have clinical informaticists review mappings for clinical accuracy
• Change Management: Track all map changes with effective dates and reasons
• Testing: After map changes, test with representative data to verify correct translation
• Documentation: Maintain documentation of all active translation maps, their scope, and their coverage percentage

---