Turn any HL7 v2 message into validated FHIR — losing nothing.
Bidirectional HL7 v2 ↔ FHIR with round-trip fidelity. Every message type maps to the right FHIR resource, every code is normalized, every bundle is validated against US Core — AI-drafted and human-reviewed. The mapping that used to take weeks is drafted in minutes; your team just reviews it.
- ADT, ORM, ORU, SIU, MDM, DFT, VXU → the correct FHIR resources
- Round-trip fidelity: v2 → FHIR → v2, tested and diffed
- US Core R4.0.1 conformance with exportable reports
- Custom Z-segments and non-conformant senders handled
MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitusAgent
{ "resourceType": "Patient",
"identifier": [{ "value": "MRN12345" }],
"name": [{ "family": "Doe",
"given": ["John","A"] }],
"gender": "male",
"birthDate": "1970-12-25" }
{ "resourceType": "Condition",
"code": { "coding": [{
"system": "…/icd-10-cm",
"code": "E11.9" }] } }In short
E11.9 → a coded Condition), assembled into a referentially-correct bundle, and validated against US Core R4.0.1. Because most hospitals still run HL7 v2 for real-time messaging, translation is bidirectional with round-trip fidelity — the exact bridge the Cures Act transition to FHIR requires.Every message type, mapped to the right resource
HL7 v2 trigger events map to specific FHIR resources — not a lossy dump into a generic bundle. Here's how the common message types translate.
| HL7 v2 message | Trigger event | FHIR resources | Mapping notes |
|---|---|---|---|
| ADT | A01/A03/A04/A08 — admit, discharge, register, update | Patient · Encounter · Location · Coverage | PID → Patient, PV1 → Encounter, IN1 → Coverage; DG1 → Condition |
| ORM / OMG | O01 — new / changed order | ServiceRequest · Specimen · Task | ORC/OBR → ServiceRequest; ordering provider → PractitionerRole |
| ORU | R01 — observation / lab result | DiagnosticReport · Observation · Specimen | OBR → DiagnosticReport, OBX → Observation; LOINC-coded |
| SIU | S12/S14/S15 — schedule new, modify, cancel | Appointment · Schedule · Slot | SCH → Appointment; AIL/AIP → participants & location |
| MDM | T02/T08 — document notification & content | DocumentReference · Composition · Binary | TXA → DocumentReference; OBX content → Binary attachment |
| DFT | P03 — post detail financial transaction | ChargeItem · Account · Claim | FT1 → ChargeItem; CPT/HCPCS via terminology service |
| VXU | V04 — unsolicited vaccination update | Immunization · Patient | RXA → Immunization; CVX-coded vaccine |
| MFN / ADT merges | Master files, A40 patient merge | Patient (link) · Organization · Location | Identity merges reconciled by the Identity agent (EMPI) |
Reverse direction (FHIR → HL7 v2) is supported for each type, so downstream systems that consume v2 keep working unchanged.
The translation pipeline, step by step
Parse, map & normalize, assemble, validate — with the right AI agent owning each stage and your team reviewing the result.
- 1
Parse & structure
The inbound HL7 v2 message is parsed segment-by-segment (MSH, PID, PV1, OBR, OBX, DG1…), with adaptive handling of custom Z-segments and non-conformant senders. Malformed messages are auto-repaired where safe and flagged where not.
- 2
Map & normalize
The Mapping agent proposes segment→resource mappings; the Terminology agent normalizes codes — HL7 tables to FHIR value sets, local lab codes to LOINC, ICD-10 E11.9 to a coded Condition. Every decision carries a confidence score and a plain-English rationale.
- 3
Assemble the bundle
Resources are stitched into a referentially-correct FHIR bundle — Patient, Encounter, Condition, Observation — with stable identifiers and provenance so references resolve and nothing is orphaned.
- 4
Validate against US Core
The Validation agent checks cardinality, must-support elements and value-set bindings against US Core R4.0.1 (and Da Vinci / IPS where relevant), producing an exportable conformance report.
MSH|^~\&|EPIC|HOSP|H1ST|DST|202601..||ADT^A01|
PID|1||MRN12345^^^HOSP^MR||DOE^JOHN^A||
19701225|M|||123 MAIN ST^^AUSTIN^TX
PV1|1|I|ICU^101^A|||...admit...
DG1|1|I10|E11.9^Type 2 diabetes mellitusAgent
{ "resourceType": "Patient",
"identifier": [{ "value": "MRN12345" }],
"name": [{ "family": "Doe",
"given": ["John","A"] }],
"gender": "male",
"birthDate": "1970-12-25" }
{ "resourceType": "Condition",
"code": { "coding": [{
"system": "…/icd-10-cm",
"code": "E11.9" }] } }The same engine, every other format
C-CDA, X12, NCPDP and DICOM run through the identical parse → map → validate pipeline — each with its own real code and exchange. Pick a format to see the actual transformation.
<ClinicalDocument> <recordTarget><patientRole> <patient><name> <given>John</given> <family>Doe</family></name> <section><!-- Problems --> <entry><observation> <value code="E11.9"/></observation>
Agent
{ "resourceType": "Composition",
"type": { "text": "CCD" },
"title": "Continuity of Care" }
{ "resourceType": "Condition",
"subject": { "reference":
"Patient/john-doe" },
"code": { "coding": [{
"system": "…/icd-10-cm",
"code": "E11.9" }] } }Round-trip fidelity is the honesty test
Anyone can throw an HL7 v2 message at an LLM and get FHIR-shaped JSON back. The hard part is losing nothing. Health1st tests fidelity the only way that matters: it converts v2 → FHIR → v2, diffs the output against the original, and surfaces any drift. Identifiers stay stable, references resolve, coded values survive normalization, and repeated fields aren't collapsed. That's what makes it safe to put in front of a system that still consumes HL7 v2 — and what separates a real engine from a demo.
MRNs, order numbers and account IDs preserved across the round trip.
Every FHIR reference resolves; no orphaned Observations or Conditions.
LOINC, SNOMED, ICD-10 and CPT codes map out and back without loss.
From an HL7 v2 feed to validated FHIR in five steps
The same path whether you're modernizing a legacy interface estate or standing up a new FHIR API for CMS-0057-F.
- 1
Point us at a sample feed
Send a batch of representative HL7 v2 messages — ADT, ORU, whatever your interface carries. The Onboarding agent learns the format, including custom Z-segments, from the samples.
- 2
Review the AI-drafted mapping
The Mapping and Terminology agents draft segment-to-resource mappings and code crosswalks. Your team reviews each mapping in the studio, with a plain-English explanation and confidence score for every field.
- 3
Validate against US Core
Run output through the Validation agent to check conformance against US Core, Da Vinci or IPS profiles, and export a conformance report for procurement and audit.
- 4
Round-trip test both directions
Confirm fidelity by converting v2 → FHIR → v2 (and back) and diffing the result, so no data is lost when messages flow to systems that still speak HL7 v2.
- 5
Promote and deliver
Approve the mapping, version it, and let the Orchestration agent route messages in real time, batch or streaming — with guaranteed delivery, retry and replay.
What the engine actually guarantees
Not ‘we use AI’ — measurable behavior: bidirectionality, round-trip fidelity, message coverage, terminology accuracy and conformance.
Bidirectional, not one-way
v2 → FHIR to expose modern APIs and patient access; FHIR → v2 to keep feeding the ADT, lab and pharmacy systems that still run HL7 v2. Both directions are first-class.
Round-trip fidelity
Convert v2 → FHIR → v2 and diff the result. The Transformation agent preserves data through the round trip so translation never silently drops fields.
Every message type mapped
ADT, ORM, ORU, SIU, MDM, DFT and VXU each map to the correct FHIR resources — Patient, Encounter, DiagnosticReport, Appointment, DocumentReference, ChargeItem, Immunization.
Terminology done right
HL7 v2 tables to FHIR value sets, local codes to LOINC/SNOMED, ICD-10 to coded Conditions, CPT/HCPCS on charges — normalized and confidence-scored by the Terminology agent.
US Core conformance built in
Output is validated against US Core R4.0.1, Da Vinci and IPS — must-support, cardinality and bindings — with an exportable report auditors and buyers accept.
Z-segments & non-conformant senders
Adaptive parsing handles custom Z-segments, proprietary variants and messy real-world senders, with safe auto-repair of malformed messages and clear flags where review is needed.
The engine doesn't work alone
Translation is the core — but a clean HL7 v2 ↔ FHIR conversion also needs normalized codes, conformance validation, identity resolution, guaranteed delivery, and a full audit trail. Eight specialized agents surround the engine so every message that ships is correct, conformant, deliverable, and traceable.
Translation Engineparse · map · normalize · validate · deliver
Mapping Agent
AI-drafts the field- and segment-level mappings the engine executes — with rationale your team reviews.
Terminology Agent
Normalizes ICD-10, SNOMED, LOINC, RxNorm & NDC so the mapped output actually passes validation.
Validation Agent
Conformance-tests every bundle against US Core, Da Vinci & IPS before a single message ships.
Orchestration Agent
Routes, retries and guarantees delivery — real-time, batch or streaming — so nothing is silently lost.
Translation Engineparse · map · normalize · validate · deliver
Identity Agent
Patient matching / EMPI keeps records lined up across every connected source and destination.
Compliance Agent
Consent, provenance, immutable audit and SMART / OAuth policy on every exchange of PHI.
Observability Agent
Monitors throughput and latency and flags anomalies before they turn into outages.
Onboarding Agent
Learns a new partner's format from sample messages and bootstraps the first interfaces in days.
Follow one message
An inbound ADT^A01 hits the engine. The Mapping Agent drafts the segment-to-resource mapping; the Terminology Agent resolves the DG1 code to ICD-10/SNOMED; the engine assembles the FHIR bundle; the Validation Agent conformance-checks it against US Core; the Identity Agent reconciles the patient; the Compliance Agent records provenance and consent; and the Orchestration Agent delivers it with retry and guaranteed delivery — while Observability watches the whole path. Your analysts review; the agents do the work.
Frequently asked questions
See a live HL7 v2 ↔ FHIR translation on your own messages.
Send us a sample feed. We'll show you the AI-drafted mapping, the US Core conformance report, and the round-trip diff — on a live demo, no obligation.