Digital Health & Data
FHIR vs HL7 v2: what's the difference?
In short: HL7 v2 is the long-established health messaging standard used across hospital systems; FHIR (Fast Healthcare Interoperability Resources) is the modern, web-API approach to exchanging health data. FHIR is easier for new web/mobile integrations; HL7 v2 still underpins much of the installed base. Real interoperability often means handling both.
HL7 v2
HL7 version 2 uses structured, pipe-delimited messages (e.g. ADT for admissions) and is deeply embedded in hospital and laboratory systems. It is robust and ubiquitous, but less friendly to modern web development.
FHIR
FHIR models health data as reusable resources (Patient, Observation, MedicationRequest…) exchanged over RESTful web APIs in JSON or XML. It suits modern apps, mobile and cloud, and is the direction of travel for new NHS and international integrations.
Choosing for your product
The right choice is driven by the systems you must integrate with and the workflows you support. Many products implement FHIR for new interfaces while still consuming HL7 v2 where the source systems require it. We map your integration targets and design a safe, standards-aligned approach.
Meds Global Health provides FHIR/HL7 readiness and clinical workflow design, part of Digital Health & Interoperability.
Beyond the base standard
Profiles, terminology and why "supports FHIR" is not enough
A frequent misconception is that two systems will interoperate simply because both "support FHIR". In practice, interoperability depends on agreement at several layers below the headline standard:
Profiles
A FHIR profile constrains and extends base resources for a context. In the NHS, UK Core profiles define how resources such as Patient and Observation should be used. Conforming to the same profile — not just FHIR in general — is what makes exchange reliable.
Terminology
The same concept must be coded the same way. NHS data typically uses SNOMED CT for clinical terms and dm+d for medicines. Mismatched code systems are a leading cause of "connected but not understood" failures.
Workflow fit
A technically valid message still has to land in the right place in a clinician's workflow. Data that arrives but is never surfaced safely adds risk rather than value.
This is why a standards label alone tells you little. The real question is which profiles, terminologies and workflows your target systems expect — and whether your product meets them.
In practice
A worked integration and its pitfalls
Picture a new web app that must read patient demographics and write back an observation to an existing hospital system. The hospital still emits HL7 v2 ADT messages for admissions, but exposes a FHIR API for newer integrations. A pragmatic design consumes the HL7 v2 feed where that is the only source, maps it to the appropriate FHIR resources and UK Core profile internally, and uses FHIR for the write-back. The two standards coexist by design rather than by accident.
The pitfalls cluster predictably: mapping errors between the v2 message and FHIR resources, mismatched code systems, untested edge cases (missing fields, unexpected values), and assuming the base standard when the target requires a specific profile. Testing against real, anonymised message samples early surfaces these before they reach a clinical setting. Interoperability is also assessed by NHS buyers within the DTAC, and your described data flows feed the DPIA — so getting the design right supports both safe care and procurement. We map your targets and design the path; see Interoperability & Workflow Design.
Answers
Frequently asked questions
What is the difference between FHIR and HL7 v2?
HL7 v2 is a long-established messaging standard using pipe-delimited messages; HL7 FHIR is a newer standard built on modern web APIs (REST, JSON/XML) with reusable "resources". FHIR is generally easier to implement for new web and mobile integrations; HL7 v2 remains widely used in existing hospital systems.
Is FHIR replacing HL7 v2?
Not entirely — many systems still rely on HL7 v2, and the two coexist. New integrations increasingly use FHIR, but interoperability often means working with both.
Which should my product support?
It depends on the systems you must connect to. We assess your integration targets and recommend the right standards. See Interoperability & Workflow Design.
What is a FHIR profile?
A FHIR profile constrains and extends the base FHIR resources for a specific context — for example, UK Core profiles define how resources are used in NHS settings. Conforming to the right profile, rather than only the base standard, is what makes two systems actually interoperate.
Does using FHIR or HL7 affect NHS assurance?
Interoperability is one of the areas NHS buyers assess in the DTAC, so demonstrating standards-aligned data exchange supports procurement. The data flows you describe also feed your DPIA and clinical-safety case. See DTAC.
How do I avoid integration pitfalls?
The common traps are mismatched profiles or code systems, mapping errors between HL7 v2 and FHIR, and untested edge cases. Mapping your integration targets and testing against real message samples early prevents most of them.
Planning an integration?
We'll map your FHIR/HL7 path and design it safely.