Do not rewrite what works
A migration does not mean replacing every HL7 v2 interface. The safe pattern is to add FHIR at the edges and translate between the two in a dedicated layer, leaving working internal feeds alone. The reasoning is covered in FHIR vs HL7 v2.
Step 1: Inventory
List every HL7 v2 interface: message types, versions, sending and receiving systems, volumes and known quirks. Many hospitals discover interfaces nobody remembers.
Step 2: Choose target resources
For each message type, decide which FHIR resources it maps to — for example ADT messages to Patient and Encounter, ORU messages to DiagnosticReport and Observation. Use the list in FHIR R4 resources for hospital integration.
Step 3: Build the mapping and terminology tables
- ✓Field-level mapping documented in a spreadsheet agreed by clinicians and IT.
- ✓Code translation tables from local codes to SNOMED CT, LOINC or required value sets.
- ✓Rules for missing and conflicting data.
Step 4: Run in parallel
- ✓Keep the v2 feed live and generate FHIR beside it.
- ✓Compare outputs automatically and review mismatches daily.
- ✓Validate every FHIR resource against the target profile.
Step 5: Cut over one consumer at a time
Switch a single consumer — for example ABDM record sharing or a patient app — to the FHIR feed, watch error rates and keep a rollback path. Move the next consumer only when the first is stable.
Step 6: Monitor and own it
Set alerts for failed messages, queue growth and validation errors. Name an owner. Integrations without owners decay. If you are aiming for ABDM, see the milestone checklist, and for the project-level risks read why integration projects fail.
Frequently asked questions
Can we run HL7 v2 and FHIR side by side?
Yes, and it is the recommended approach. An integration layer receives v2, translates to FHIR and serves both audiences.
How long does a migration take?
It depends on the number of interfaces and data quality. Starting with one interface and one consumer gives a realistic estimate for the rest.
Do we need a FHIR server?
Not always. Some projects generate FHIR on demand, while others store resources in a FHIR server for querying and subscriptions.
Need help with this in your hospital?
Tell us your systems and your goal. We'll map it to a scoped plan.
Talk to our team →This guide is general information for engineering and planning purposes. It is not legal advice, and regulations and specifications change; confirm current requirements with the relevant authority or qualified counsel.
