What is FHIR, and when would you still be dealing with HL7 v2?

Two standards with different shapes

HL7 v2 is a messaging standard. A system emits a message when something happens, encoded as lines of segments with fields separated by pipes and components by carets, and the receiver acknowledges it. The message type says what happened: ADT messages carry admission, discharge and transfer events, ORU carries observation results, order and scheduling messages have their own types. The classical transport is a framed stream over TCP with an application-level acknowledgement, so an interface is a long-lived connection with a queue behind it, not a request-response API.

FHIR is a resource-oriented API. Clinical and administrative concepts are modelled as a defined set of named resources - Patient, Encounter, Observation, MedicationRequest, Condition and so on - each with a specified structure, a JSON and XML representation, and a URL. You interact with them over HTTP using the ordinary verbs plus a search syntax, you compose several resources into a Bundle when you need them together or need them applied atomically, and resources reference each other by URL. R4 is the version most production deployments target; R5 is published and adoption of it trails well behind.

MSH|^~\&|EPIC|HOSP1|LIS|LAB1|20260726120000||ADT^A01|MSG00001|P|2.5.1
PID|1||1234567^^^HOSP1^MR||SMITH^JANE^A||19800214|F

{
  "resourceType": "Patient",
  "identifier": [{ "system": "http://hospital1.example.org/mrn", "value": "1234567" }],
  "name": [{ "family": "Smith", "given": ["Jane", "A"] }],
  "gender": "female",
  "birthDate": "1980-02-14"
}

The same patient, twice. The difference that matters is not verbosity: in the v2 segment HOSP1 names the assigning authority by a string whose meaning lives in a document agreed between two parties, whereas the FHIR identifier system is a URI, so the namespace is self-describing and two systems that have never spoken can tell whether they mean the same identifier space.

Why v2 has not gone away

v2 predates the web and has been deployed continuously ever since, so the internal nervous system of most hospitals is a v2 event fabric: registration tells the laboratory, radiology, pharmacy, billing and the bed board that a patient has arrived, and each of those interfaces was commissioned, tested and signed off as safe to use on patients. Replacing one is not a technology refresh but a clinical safety project with validation and downtime risk attached, and it delivers no new capability. Nobody funds that.

The interaction models also differ in a way that makes them complements rather than substitutes. v2 is push: the receiver learns about the discharge because it was told, immediately, without polling. FHIR's centre of gravity is pull, which is exactly right for a patient-facing app, a clinician's mobile view, a decision-support tool or a payer wanting one slice. FHIR does have publish mechanisms and a bulk export for population-scale extraction, but the everyday reality is that FHIR is the query surface at the edge of the enterprise while v2 remains the event spine inside it. Regulatory pressure has pushed hard on that edge, which is why a modern FHIR API in front of a decades-old v2 backbone is the normal case rather than a sign of neglect.

What an integration engine does

Sitting between all of this is an integration engine, and in healthcare it is not optional plumbing but the place most of the domain logic lives. It terminates the inbound interfaces, persists every message on receipt, then transforms, routes by content and delivers with retry. The properties that matter are the unglamorous ones: durable store-and-forward, so a laboratory system rebooting does not lose results; selective replay, so a mapping bug can be corrected and yesterday afternoon reprocessed; a searchable archive of every message in and out, because when a clinician says the result never arrived someone has to prove where it stopped; and terminology mapping, translating a local test code into a standard one the receiver can interpret.

It is also where v2 becomes FHIR. A pragmatic FHIR facade is very often an engine subscribing to the existing v2 feeds, mapping them into resources, and serving those - which is why a FHIR API can be entirely genuine and still expose only the data the underlying feeds happen to carry.

Profiling and extensions, which is where the real work is

The base FHIR specification is deliberately loose: it aims at the elements most implementations need, leaves most fields optional, and pushes the rest into local agreement. So two conformant servers can be mutually useless, because a resource where everything is optional guarantees nothing.

A profile closes that gap. It is a StructureDefinition that constrains a resource for a context: tightening cardinalities so a field becomes mandatory, binding a coded element to a specific value set with a stated strength, flagging elements as must-support so implementers know what a consumer will rely on, and slicing repeating elements so each occurrence has a defined meaning. Profiles ship in bundles called implementation guides, national and specialty, along with their value sets and expected server capabilities. When somebody asks whether your system is interoperable, the answerable form of the question is which implementation guide you conform to - and an instance can be validated against it mechanically.

An extension is the escape hatch for data the base resource has no element for. It is itself defined by a StructureDefinition and identified by a URL, so it is discoverable and validatable rather than an ad hoc field, which is a real improvement on the locally-invented segments v2 interfaces accumulated. But it remains a private vocabulary: a generic client will carry it through and never understand it. So the discipline is to look for a published profile that already defines the concept before minting your own, and to treat each extension as a bilateral agreement wearing standard clothing.

The claim that separates a strong answer

The weak version is "FHIR replaced v2, so v2 is legacy", which is wrong on the facts. The subtler trap catches experienced candidates: treating "we both speak FHIR R4" as meaning the integration is solved. It is not, and the reasons are consistent - each side binds the same coded element to a different code system, one populates an element the other never reads, identifier systems are asserted differently for the same real-world namespace, or one side's mandatory element is optional in the other's profile. Naming conformance, terminology binding and identifier semantics as the real integration work is what distinguishes someone who has delivered a healthcare interface from someone who has read about one.