HL7 and FHIR: Healthcare Interoperability Explained
Key takeaway
FHIR is the modern, REST-based standard and the right default for new integrations, but HL7 v2 still carries most hospital messaging and won't disappear. In either case the schedule risk is rarely the code — it's vendor access, sandbox approval, and the site-specific variation in how fields are used.
Any product that touches clinical data eventually meets these standards. The good news is that the concepts are simpler than the acronyms suggest; the bad news is that conformance on paper and interoperability in practice are different things.
The standards you'll actually encounter
- HL7 v2 — pipe-delimited messages (ADT for admissions, ORU for results, ORM for orders) moved over a persistent connection. Decades old, ubiquitous, and highly variable between sites.
- FHIR — resource-based and REST/JSON, with defined resources like Patient, Observation, Encounter, and Medication. Far friendlier to modern developers and now the direction of travel.
- C-CDA — structured clinical documents, typically used for summaries exchanged between providers.
- DICOM — medical imaging, a separate world with its own networking model.
What FHIR changes
FHIR gives you predictable JSON resources over HTTP, standard search parameters, and OAuth-based authorisation (SMART on FHIR) for app launch inside an EHR. A developer who has built any REST integration can read a FHIR spec in an afternoon — which is precisely why it's winning.
Where projects actually lose time
- Vendor onboarding — sandbox access, app registration, and security review can take longer than the build.
- Optionality — much of a standard is optional, so two conformant systems can still disagree on which fields are populated.
- Local codes — sites map to LOINC and SNOMED inconsistently; expect a terminology mapping exercise.
- Identity — patient matching across systems without a shared identifier is a hard problem with clinical consequences.
- Write access — reading data is comparatively easy; writing back into a clinical record involves governance, not just an API.
How to plan one
- Name the exact data elements you need, in clinical terms, before choosing a standard.
- Start vendor access paperwork in week one — it's the critical path.
- Build against the vendor's own sandbox, not a generic reference server.
- Budget for a per-site configuration and validation phase; the second hospital is never free.
- Handle PHI under HIPAA from the first commit — encryption, audit logging, and minimum necessary access.