HL7 v2 and FHIR are not rivals

FHIR is often described as the replacement for HL7 v2. In practice, the two solve different problems, and a working integration usually needs both.

What each one is good at

HL7 v2 is event-driven. When a patient is admitted, a system sends a message such as ADT^A01, and every subscribed system receives the news. It is compact, widely implemented and already running inside most hospital departments.

FHIR is resource-driven. An application asks a server for a Patient, an Observation or a MedicationRequest over a REST API and gets back a structured record. That suits patient apps, partner access and anything that needs to read current data on demand.

The same patient in both

PID|1||4471^^^MRN||DOE^JANE||19800214|F

{
  "resourceType": "Patient",
  "identifier": [{ "value": "4471" }],
  "name": [{ "family": "Doe", "given": ["Jane"] }],
  "birthDate": "1980-02-14",
  "gender": "female"
}

The mapping looks simple here. The work is in everything this example leaves out.

Where the mapping gets hard

• Sites use v2 differently. Optional fields, local conventions and custom Z-segments mean one mapping rarely fits two hospitals.
• Codes are often local. A lab test may need translating to LOINC before another system can understand it.
• A message describes an event, while a resource describes current state. Updates, corrections and merges must be reconciled, not just converted.
• Identity needs a decision. Two sites may hold the same person under different record numbers.

A practical starting point

Leave working v2 feeds in place, and put an integration layer between them and the outside world. Map the messages you actually receive rather than the specification, starting from a sample of real traffic. Publish FHIR for the consumers that need it, and record every transformation so a wrong value can be traced to its source.