HL7 vs. FHIR: a plain-English guide

01.HL7 v2: the older workhorse

HL7 v2 is the older workhorse. It sends messages, like "patient admitted" or "lab result ready", between systems. It is everywhere, it is reliable, and every hospital implements it slightly differently.

Think of it as a stream of short notices. When something happens in one system, it sends a message to others that need to know. A registration system announces an admission. A lab system announces a result. The format is compact, uses delimiters and positional fields, and is not friendly to people reading it for the first time.

Its strength is that it works, and it has worked for decades. Its weakness is that the standard leaves a lot of room for local choices. Two systems may both send a "lab result" message and place the same information in different fields. Integrating them means writing and maintaining mapping logic, usually by someone who has done it before.

02.FHIR: the modern standard

FHIR (Fast Healthcare Interoperability Resources) is the modern standard. It treats data as resources, like Patient, Observation or Medication, that apps can request over the web, much like any modern API. It is easier for developers and is the basis of the CMS-0057-F API requirements.

If you have built a web service, FHIR will feel familiar. You can ask a server for a patient, search for observations by date, or create a new resource using standard HTTP methods and JSON. Developers who are not healthcare specialists can start quickly, which is a large part of its appeal.

FHIR is not magic. It still needs careful mapping, terminology and patient matching. It also has profiles and implementation guides that narrow the options for a given purpose. Two FHIR servers can still disagree if they follow different guides.

03.Side by side

• Style. HL7 v2 sends event messages pushed between systems. FHIR offers web APIs that apps query.
• Best for. HL7 v2 suits real-time feeds inside a hospital. FHIR suits apps, patient access, and payer and provider exchange.
• Developer effort. HL7 v2 needs specialist knowledge and custom parsing. FHIR uses familiar REST and JSON.
• Regulatory pull. HL7 v2 covers existing interfaces. FHIR is behind the required APIs under CMS-0057-F.

04.Do you need to choose?

Usually not. Most organisations keep HL7 v2 for internal feeds and add FHIR for new apps and regulated exchange. The skill is bridging the two cleanly.

In practice, a bridge looks like an integration engine that receives HL7 v2 messages, validates them, maps their content to FHIR resources, and exposes those resources through a secure API. It also works in the other direction when a FHIR-based app needs to send something into a legacy system.

05.An example of bridging

Suppose a hospital wants a patient-facing app to show lab results. The lab system emits HL7 v2 result messages. The app expects FHIR Observation resources.

The integration layer receives each result message and checks it against basic rules. It maps the local test code to a standard code set. It links the result to the right patient. It then stores or exposes the data as an Observation resource, and logs every step. If a mapping is missing, the message goes to a review queue instead of disappearing.

That small flow covers most of what makes interoperability hard: formats, codes, identity and failure handling.

06.What developers actually notice

Developers who move from HL7 v2 to FHIR notice a few differences in the first week.

Readable payloads. A FHIR resource is JSON or XML with named fields. A v2 message is a string of pipe-delimited segments where meaning depends on position. Debugging the first is far easier.

Search. FHIR defines standard search parameters, so an app can ask for all observations for a patient in a date range. With v2, you receive what the sender chose to push, and you build your own store to answer questions later.

Tooling. Open-source libraries and test servers exist for FHIR in most mainstream languages. Teams can prototype in days. That speed is useful, but a prototype is not a production interface. Authorization, consent, audit and error handling still need real work.

Profiles. The base FHIR specification is deliberately flexible. Implementation guides narrow it for a specific use, such as a payer API. Always ask which guide and which version a counterpart is following, because two servers can both claim FHIR and still not interoperate.

07.Where each one goes wrong

HL7 v2 projects go wrong when every new interface is a custom job. Each sender gets a one-off parser, the parsers pile up, and nobody remembers why a field is handled in a special way. The cure is a common engine, shared mapping tables and tests built from real messages.

FHIR projects go wrong when teams assume the standard does the hard parts. It does not decide how to match patients, which code sets to use or who may see what. It gives a shared shape for data. The agreements around it still have to be made.

Both go wrong when monitoring is left until later.

08.How to decide

Use these questions:

• Is this a feed between internal systems that already works? Keep HL7 v2.
• Is a third-party app, patient or payer asking for data? Use FHIR.
• Is this subject to a regulated API requirement? Check what the rule specifies, and build to that.
• Will developers outside the hospital use it? FHIR is likely to be easier for them.
• Who will maintain it? Choose the option your team can actually support.

09.A word on versions

FHIR has been released in versions, and systems in the field run different ones. Before you commit to a design, confirm which version your counterparts use and which version the rule or guide you are following expects. Mixed versions are manageable, but only if you plan for them. Keep a list of the versions in play and test against each one.

10.Common mistakes

• Assuming FHIR removes the need for mapping and patient matching.
• Replacing working HL7 v2 feeds without a reason.
• Ignoring versions and implementation guides.
• Building the API without audit logging and access control.
• Treating a conformance statement as proof that two systems will work together.

11.A simple starting plan

• Pick one flow where an outside app or a regulated API is involved.
• Identify the source systems, usually still HL7 v2.
• Choose the FHIR resources you need and the implementation guide that applies.
• Write the mapping from source fields and local codes to those resources.
• Build the bridge with logging, access control and retry.
• Test with sample messages that include awkward cases: missing fields, unusual codes, duplicate patients.
• Run in parallel and compare before switching traffic.

12.What to do next

List the flows you run on HL7 v2 and the ones you expect to expose on FHIR. Mark which are regulated, which serve outside apps and which are purely internal. That alone clarifies the roadmap.

Brandsmashers can help with the design and build work, including the bridge between the two. We build to the published standards, and your organisation stays responsible for its own regulatory compliance.