Data Mapping

Data mapping operates at the atomic field level, defining explicit correspondences between individual data elements in the source and target schemas. This is not a document-level transformation but a precise, cell-by-cell translation.

• Source Field: PID-3.1 (Patient Identifier List) in an HL7 v2 ADT message
• Target Field: Patient.identifier.value in a FHIR R4 Patient resource
• Transformation Logic: Strip leading zeros and append the assigning authority OID as a namespace URI

Without this granularity, critical clinical context is lost during interface engine processing.

A mapping is incomplete without explicit transformation rules that govern how source data is manipulated before populating the target. These rules handle data type coercion, code translation, and structural reorganization.

• Type Coercion: Converting a string timestamp like 202410281430 to an ISO 8601 datetime
• Code Translation: Mapping a local hospital charge code to a standardized CPT or Revenue Code using a crosswalk table
• Conditional Logic: Applying IF/THEN rules, such as "If PV1-2 (Patient Class) equals 'I', set Encounter.class to 'inpatient'"
• Default Values: Inserting a static value when the source field is empty to maintain target schema integrity

Mappings must explicitly reconcile differences in cardinality (how many times an element can appear) and optionality (whether it is required) between schemas. Failure here causes schema validation errors.

• One-to-Many: A single source field like a pipe-delimited diagnosis list in an HL7 v2 DG1 segment must be split into multiple repeating Condition resources in FHIR
• Many-to-One: Multiple source fields (e.g., street address, city, state, zip) are concatenated into a single formatted string
• Required Field Enforcement: If the target schema mandates a field (e.g., resourceType in FHIR) that has no source analog, the mapping must inject a hardcoded value

A specialized mapping function that translates between disparate medical terminology systems. This is the semantic glue of healthcare interoperability.

• Standard-to-Standard: Mapping SNOMED CT concept 22298006 (Myocardial Infarction) to ICD-10-CM code I21.9
• Local-to-Standard: Translating a proprietary lab code like GLUC to the universal LOINC code 2339-0 for glucose in blood
• Version Management: Crosswalks must be version-aware, as code systems like ICD-10-CM receive annual updates that deprecate or add codes
• Equivalence Mapping: Defining whether the relationship is exact match, broader-to-narrower, or merely associated

Effective data mapping is not purely syntactic; it requires contextual awareness of the clinical or operational meaning of the data. The same source field may map to different targets based on surrounding trigger events or segment context.

• Trigger Event Routing: An HL7 v2 message with MSH-9 (Message Type) of ADT^A01 (Admit) maps patient demographics differently than an ADT^A08 (Update)
• Segment Context: The value in OBX-5 (Observation Value) is interpreted based on OBX-3 (Observation Identifier). A value of '1+' maps to a qualitative result if the identifier is a urine dipstick code, but would be an error if the identifier expects a numeric value
• Temporal Context: Mapping a lab result requires associating it with the correct encounter based on specimen collection time, not message receipt time

A production-grade mapping specification must define graceful degradation paths for when source data is missing, malformed, or violates business rules. This prevents interface engine crashes and data corruption.

• Missing Data: Define a default value or omit the target element entirely based on a configurable policy
• Data Type Violation: If a numeric field receives alphabetic characters, the mapping may log the error, populate a dedicated error field, and route the message to a Dead Letter Queue for manual review
• Code Lookup Failure: If a local code has no entry in the crosswalk table, the mapping may pass through the original code with a flag or halt processing depending on the criticality of the field
• Truncation Rules: Define whether a string exceeding the target field length is silently truncated, triggers an error, or attempts abbreviation