Two standards for two jobs
HL7 v2 and FHIR come from the same organisation but were designed in different eras. HL7 v2 sends event messages between systems that already know each other. FHIR describes health data as resources with a web API, so that applications can read and write them.
Neither makes the other obsolete this year. The question for a hospital is practical: which standard does each partner publish, and how do you connect to all of them without building a separate system for each.
How they differ
| Aspect | HL7 v2 | FHIR R4 |
|---|---|---|
| Data model | Messages made of segments and fields | Resources such as Patient, Encounter, Observation and Claim |
| Syntax | Delimited text | JSON or XML |
| Typical transport | MLLP over TCP, inside a VPN or TLS | HTTPS, with REST or message exchange |
| Pattern | Event driven: something happened, here is the message | Resource based, with messaging and documents also available |
| Strength | Mature, widely supported by laboratory, radiology and pharmacy systems | Clear resource definitions, profiles and web tooling |
| Common weakness | Local variations between systems | Profiles and extensions vary between programmes |
What the region uses
The public specifications of regional platforms show that both standards are in use today.
- NPHIES in Saudi Arabia. Its published implementation guide for financial services uses HL7 FHIR R4.0.1 and exchanges messages over mutually authenticated HTTPS.
- NABIDH in Dubai. Its published interface documentation describes HL7 v2.5 messages, namely ADT, ORM, ORU, RDE, MDM and VXU, and C-CDA v2.1 documents.
- Malaffi in Abu Dhabi. Its published onboarding criteria require an HL7-capable EMR that exchanges ADT messages in real time and embeds Malaffi through single sign-on.
- Claims in the UAE. Abu Dhabi and Dubai exchange claims as structured XML through their own platforms, which are neither HL7 v2 nor FHIR.
A hospital group with sites in more than one of these markets therefore needs more than one standard from day one.
Designing for both
The pattern that holds up best is to keep one internal model and translate at the edge. The hospital system records events in its own structure. An integration layer maps those events to whatever a given partner publishes, and holds the mapping, the transport, the retries and the logs for that partner.
- One internal model. Do not let a partner's message format leak into the clinical record. A change at the partner should touch the mapping, not the chart.
- One mapping per partner. Keep each mapping versioned and tested on its own. HL7 publishes guidance for mapping between v2 and FHIR, and it is a good starting point, not a finished mapping.
- One place for delivery. Retries, a transaction log, a queue and reconciliation belong in the integration layer, whichever standard is used.
- One owner per interface. A named person answers when a partner changes a specification.
Questions to ask each partner
- Which standard and which version do you publish, and where is the current specification?
- Is there a test environment with synthetic data, and who grants access?
- Which code sets and identifiers must we send?
- How are errors returned, and how long do you keep messages?
- What certificates, network access or agreements are needed before testing?
- How are changes to your specification announced?
How Ventrecs approaches it
The Ventrecs hospital system produces FHIR R4-shaped resources from a durable outbox for an approved integration service, and payer eligibility connectors can use FHIR R4 or a generic REST interface. HL7 v2 and other transports run in the separate integration layer, Ventrecs Connect, scoped per project.
We treat each partner's published specification as the source of truth. A connection goes live once it has been tested and agreed with you and the partner.
Sources
- NPHIES Healthcare Financial Services implementation guide
- NABIDH HL7 API documentation, Dubai Health Authority
- Malaffi: connection requirements and definitions
- HL7 Version 2 to FHIR mapping guide
Frequently asked questions
Is FHIR replacing HL7 v2?
FHIR is growing and several platforms publish it, but HL7 v2 remains widely used in laboratory, radiology, pharmacy and exchange interfaces. Most hospitals use both for years.
Which version of FHIR do regional platforms use?
NPHIES publishes an implementation guide based on FHIR R4.0.1. Check the current guide of each platform, because versions and profiles change.
Can one interface serve several partners?
Rarely. Each partner publishes its own specification, code sets and identifiers, so each needs its own mapping, even if they share a transport.
Where should the translation happen?
In an integration layer between the clinical system and the partner, so that the clinical record stays independent of any one partner's format.
Related Ventrecs pages
- Integrations How Ventrecs scopes, tests and supports each connection.
- Ventrecs Connect The governed integration hub: monitoring, retries and reconciliation.
- The Ventrecs platform Six products on one patient record, one set of controls and one integration layer.
- Insurance and claims Payers, plans, pre-authorisation, eligibility checks and claims.
- HL7 and FHIR integration HL7 v2 and FHIR R4 side by side, and how an interface is scoped per project.
Planning a deployment?
Tell us which partners you need to connect to and which standard each one publishes. We can recommend where to translate and where to exchange natively.
More insights
- HL7 v2 explained: messages, segments and how hospital systems exchange them HL7 v2 is still how most hospital systems talk to each other. This is how a message is built, sent and acknowledged, and where interfaces go wrong.
- Healthcare integration readiness: scope every interface before go-live Most delays in a healthcare deployment come from interfaces nobody scoped. Use this guide to agree each connection, its owner and how it is tested before go-live.
- NPHIES integration guide: how FHIR R4 messaging works for Saudi providers and software vendors NPHIES connects Saudi healthcare providers and insurers through FHIR R4 messages. This is how the exchange works and what a hospital system has to be ready for.