FHIR Translation Matrix
Synura translates HL7v2 messages into FHIR R4 resources. Every translation is deterministic, auditable and round-trip tested. This page documents exactly what goes in and what comes out.
How Translation Works
Section titled “How Translation Works”When an HL7v2 message arrives at Synura, the translation engine parses each segment, maps it to the corresponding FHIR resource and produces a compliant FHIR R4 Bundle. The original HL7v2 message is preserved in the audit log. Nothing is discarded, nothing is inferred, nothing is hallucinated.
Translation happens at the exchange layer. The sending system does not change. The receiving system gets clean FHIR. Both sides keep working the way they always have.
What’s included
Section titled “What’s included”Translation is part of the Translate tier and everything above it. Every standard HL7v2 message type listed on this page is in scope. Every FHIR resource listed on this page is produced.
Customers configure their own mapping rules per connection. Synura runs the translation engine and provides the rule format. If your implementation is standard, configure and go.
For non-standard implementations, Orchestrate adds bespoke translation work. Synura account engineers build the rules with you, test them against your real message traffic and deploy them. Custom message types, custom Z-segment schemas and organisation-specific field interpretations live there.
Admissions, Discharges and Transfers (ADT)
Section titled “Admissions, Discharges and Transfers (ADT)”ADT messages are the backbone of patient flow. They tell downstream systems when a patient arrives, leaves or moves.
ADT^A01: Patient Admission
Section titled “ADT^A01: Patient Admission”Triggered when a patient is admitted. Carries demographics, visit details, next of kin, insurance and diagnosis information.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics (name, DOB, address, NHS/MRN, gender, contact details) | Patient |
| Visit details (admission date, ward, bed, attending clinician, admission type) | Encounter |
| Sending and receiving system identifiers, message timestamp, event type | MessageHeader |
| Next of kin (name, relationship, contact number, address) | RelatedPerson |
| Admission diagnosis (ICD-10/SNOMED codes, description, clinical status) | Condition |
| Allergy alerts (allergen, reaction type, severity, clinical status) | AllergyIntolerance |
| Insurance and coverage details (plan, group number, subscriber, period) | Coverage |
ADT^A03: Patient Discharge
Section titled “ADT^A03: Patient Discharge”Triggered when a patient is discharged. Carries final diagnosis, discharge disposition and updated visit details.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics | Patient |
| Visit details including discharge date, disposition and discharge location | Encounter (status: finished) |
| Message routing and event metadata | MessageHeader |
| Discharge diagnosis codes and descriptions | Condition |
| Updated allergy information recorded during stay | AllergyIntolerance |
ADT^A08: Patient Update
Section titled “ADT^A08: Patient Update”Triggered when patient information changes. Carries updated demographics, visit amendments or corrected clinical data.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Updated patient demographics (address change, GP change, contact update) | Patient |
| Amended visit details (ward transfer, clinician change, expected discharge) | Encounter |
| Message routing and event metadata | MessageHeader |
| Updated next of kin or emergency contact details | RelatedPerson |
| Revised diagnosis codes | Condition |
| New or updated allergy records | AllergyIntolerance |
| Updated insurance or coverage details | Coverage |
Lab Results (ORU)
Section titled “Lab Results (ORU)”Lab results are the highest-volume message type in most health data exchanges. A single patient encounter can generate dozens of ORU messages.
ORU^R01: Unsolicited Observation Result
Section titled “ORU^R01: Unsolicited Observation Result”Triggered when a lab or diagnostic system produces a result. Carries the test, the values, the reference ranges and the clinical context.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics | Patient |
| Visit or encounter context | Encounter |
| Test results (LOINC codes, values, units, reference ranges, abnormal flags) | Observation (one per result line) |
| Report metadata (report status, result status, performing lab, report date) | DiagnosticReport (groups related Observations) |
| Original order reference that triggered this result | ServiceRequest |
| Message routing and event metadata | MessageHeader |
| Clinical notes or comments attached to results | Annotation (on DiagnosticReport) |
Clinical Orders (ORM)
Section titled “Clinical Orders (ORM)”Order messages initiate clinical workflows. A provider sends an order; a lab, pharmacy or radiology department receives it.
ORM^O01: General Order
Section titled “ORM^O01: General Order”Triggered when a clinician places an order for a test, procedure or service. Carries the order details, clinical context and patient information.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics | Patient |
| Visit or encounter context | Encounter |
| Order details (test code, priority, specimen requirements, ordering clinician) | ServiceRequest |
| Message routing and event metadata | MessageHeader |
| Diagnosis justifying the order (ICD-10/SNOMED code, clinical indication) | Condition |
| Clinical notes or special instructions for the performing lab | Annotation (on ServiceRequest) |
Scheduling (SIU)
Section titled “Scheduling (SIU)”Scheduling messages coordinate appointments between systems. They carry the who, when, where and why of every booked slot.
SIU^S12: New Appointment Notification
Section titled “SIU^S12: New Appointment Notification”Triggered when an appointment is booked. Carries patient, clinician, location, time and reason for visit.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics | Patient |
| Appointment details (date, time, duration, location, type, status) | Appointment |
| Visit context | Encounter |
| Reason for appointment (referral, follow-up, clinical indication) | Condition or ServiceRequest (depending on context) |
| Message routing and event metadata | MessageHeader |
Pharmacy (RDE)
Section titled “Pharmacy (RDE)”Pharmacy messages carry medication orders from prescriber to dispenser. They contain the drug, dose, route, frequency and clinical justification.
RDE^O11: Pharmacy/Treatment Encoded Order
Section titled “RDE^O11: Pharmacy/Treatment Encoded Order”Triggered when a prescriber creates or updates a medication order. Carries the full prescription with structured dosing instructions.
| What comes in (HL7v2) | What comes out (FHIR R4) |
|---|---|
| Patient demographics | Patient |
| Medication details (drug code, dose, route, frequency, duration, quantity) | MedicationRequest |
| Visit or encounter context | Encounter |
| Diagnosis justifying the prescription | Condition |
| Allergy information relevant to prescribing decisions | AllergyIntolerance |
| Insurance and formulary coverage | Coverage |
| Message routing and event metadata | MessageHeader |
Bespoke translation (Orchestrate)
Section titled “Bespoke translation (Orchestrate)”Standard HL7v2 has edges. Custom message types, locally defined Z-segments and organisations that interpret the spec their own way. For these, Orchestrate adds bespoke translation work.
Custom message types
Section titled “Custom message types”If your systems send non-standard or locally defined message types, Synura maps them. We build the translation rules with you, test them against your real message traffic and deploy them across your endpoints.
Custom Z-segment schemas
Section titled “Custom Z-segment schemas”Z-segments are the HL7 escape hatch. They carry organisation-specific data that no standard segment covers.
Z-segment passthrough as FHIR Extensions is baseline Translate. The data is preserved without loss; downstream systems receive the Extensions and interpret them as they need.
Custom Z-segment schemas live at Orchestrate. Synura builds the FHIR mapping for each Z-field with semantic meaning specific to your organisation, so the engine produces canonical FHIR with full structured semantics rather than passthrough Extensions.
Organisation-specific mapping rules
Section titled “Organisation-specific mapping rules”Standard translations assume standard implementations. In practice, every organisation interprets the HL7 spec slightly differently. Field overloading, local code systems, non-standard segment ordering. Orchestrate-tier mapping work encodes your organisation’s specific interpretation of the spec so what arrives in FHIR is exactly what was intended in HL7.
FHIR Resource Reference
Section titled “FHIR Resource Reference”Every resource Synura produces conforms to FHIR R4 (v4.0.1). Resources are bundled as FHIR Transaction Bundles with proper references between resources (Patient referenced by Encounter, Encounter referenced by Observation, and so on).
| FHIR Resource | What it represents |
|---|---|
| Patient | The individual receiving care. Demographics, identifiers, contact details. |
| Encounter | A clinical interaction. Admission, visit, appointment. |
| Observation | A measured or observed value. Lab result, vital sign, assessment score. |
| DiagnosticReport | A clinical report grouping related observations. Lab panel, radiology report. |
| ServiceRequest | An order or referral for a service, test or procedure. |
| MessageHeader | Routing metadata. Source, destination, event type, timestamp. |
| RelatedPerson | A person related to the patient. Next of kin, emergency contact, guardian. |
| Condition | A clinical condition, diagnosis or problem. ICD-10 or SNOMED coded. |
| AllergyIntolerance | A recorded allergy or adverse reaction. Drug, food, environmental. |
| Coverage | Insurance or funding coverage. Plan, subscriber, period. |
| Annotation | Clinical notes or comments attached to a resource. |
| Appointment | A scheduled clinical event. Date, time, location, participants. |
| MedicationRequest | A prescription or medication order. Drug, dose, route, frequency. |
| Extensions | Organisation-specific data preserved from non-standard HL7 segments (Z-segment passthrough). |
What Synura Does Not Do
Section titled “What Synura Does Not Do”Synura translates structured HL7v2 messages into structured FHIR resources. It does not:
- Infer missing data. If a field is empty in the HL7 message, the corresponding FHIR element is absent. No guessing.
- Validate clinical content. Synura validates message structure, not clinical accuracy. A diagnosis code passes through if it is syntactically valid, regardless of clinical appropriateness.
- Store patient data beyond transit. Messages are processed, translated and delivered. The audit log records metadata (timestamps, message types, status). Payload data is not retained after delivery.
Questions about translation coverage for your specific message types? hello@synura.io