HL7 v2 ADT to FHIR Patient
Convert an HL7 v2 ADT^A01 admit message into a FHIR R4 Patient resource with the visual mapping engine — no custom parsing code.
The workflow
The complete flow, exactly as it runs in the Workflow Builder. Scroll to explore, or use the zoom controls.
About this workflow
An HL7 v2 admit message and a FHIR R4 Patient resource describe the same event, but they don't look anything alike — one is pipe-delimited segments, the other is structured JSON. This workflow builds that conversion once, visually, with the mapping engine, and runs it on every incoming ADT^A01 message.
The problem
Most EHR interfaces still speak HL7 v2 for admissions, but a growing number of downstream systems — patient portals, care-coordination platforms, analytics pipelines — expect FHIR. Bridging the two usually means a custom parser: hand-written code that reads pipe-delimited segments, pulls out the fields that matter, and reshapes them into JSON. That code is brittle, hard to review, and has to be rewritten for every message type.
How it works
An Inject node carries a synthetic ADT^A01 message straight into an HL7 Parser, which validates it and produces a structured representation of every segment. A Mapper step then runs a saved mapping project — built visually in the mapping editor, not hand-coded — that wires the admit message's patient identifier, name, gender, birth date, and address fields to the matching FHIR Patient fields. The result lands on a Debug node showing the finished resource.
Why it matters
The mapping is authored once, visually, and reused everywhere it's needed — no parsing logic duplicated across workflows, no format-specific code to maintain. Anyone can open the mapping project and see exactly which HL7 field feeds which FHIR field, without reading a line of code.
Who it's for
Teams standing up a FHIR-facing integration on top of an HL7 v2 source system, or anyone who wants a concrete, working example of the mapping engine's HL7v2-to-FHIR path before building their own.
How to build this workflow
Recreate it in the Workflow Builder by wiring these steps in order — or download it above and import it directly.
Step 1: Receive the Message
An Inject node carries the built-in synthetic message straight into the flow — swap in an HL7 In listener to run against real traffic instead.
Step 2: Validate & Parse
The HL7 Parser validates the message and extracts its segment structure, so its fields are ready to wire.
Step 3: Run the Mapping
A Mapper step runs the saved mapping project, wiring the parsed fields into the target format — the same mapping built visually in the Mapping Engine guide.
Step 4: Confirm the Output
A Debug node shows the finished result, exactly as the mapping produced it.