Written for the integration architect and standards-minded reader, but deliberately built as the series hub: every later piece (v2 message types, UK Core conformance, v2-to-FHIR mapping, the terminology cluster, transfer of care) links back to this map, so it explains each standard just far enough to place it and then points onward. The patient-journey walkthrough is the piece's centre of gravity; it's the horizontal view no single standard's documentation provides. Standards are presented accurately with no connector claims.
A new integration architect's first month in a Trust follows a pattern. One spec cites HL7 v2.4. Another mandates FHIR R4 and UK Core. The clinical safety officer keeps asking about SNOMED CT. Then a transfer-of-care project lands, and the documentation is suddenly full of ITK3 and MESH. Each standard has excellent documentation of itself. What nobody hands you is the map: which standard does which job, and how they coexist in one working estate.
This is that map. Everything else on this blog hangs off it.
In brief
Four standards carry the weight in NHS integration, and they're not competitors; they're layers. HL7 v2 is the event layer: the high-volume, real-time messaging inside an organisation. FHIR, constrained by UK Core, is the API layer: the resource-based standard for national services and new integrations. SNOMED CT is the meaning layer: the clinical terminology carried inside the payloads of both. ITK3 is the document layer: the framework for structured correspondence, such as discharge summaries, moving between organisations. A working NHS estate speaks all four at once, and most real integration work is translation between them.
Why a map matters more than another explainer
Standards documentation is written vertically: each specification explains itself in depth and mentions the others in passing. Estates, meanwhile, are horizontal: an admission generates a v2 message, whose coded content should be SNOMED CT, whose onward journey to a national service happens over a FHIR API, and whose discharge ends as an ITK3 document to the GP. Get the map wrong and you make expensive category errors: procuring a FHIR platform to solve what is actually a terminology problem, or trying to force document-shaped correspondence through an event-shaped feed.
So the useful question for each standard isn't "what is it?" but "what job is it the right shape for, and where does it live in the estate?"
HL7 v2: the event layer inside the organisation
HL7 v2 is the oldest of the four and still carries the majority of live traffic inside any Trust. It's a pipe-delimited messaging standard, event-driven by design: something happens (an admission, a transfer, a result being filed) and a message announces it to every system that cares, typically over MLLP between the PAS, EPR, pathology, radiology and the departmental long tail.
Its strengths are exactly why it persists: it's lightweight, real-time, and universally implemented. Its weakness is that every sender speaks a dialect, so "supports HL7 v2" guarantees connection, not agreement. The message types you'll actually meet (ADT, ORU and friends) get their own piece on this blog; for the map, the essential fact is this: v2 is the intra-organisation event layer, and it isn't going anywhere soon.
FHIR and UK Core: the API layer for what's next
FHIR is the modern generation: data expressed as resources (Patient, Encounter, Observation), exchanged over ordinary REST APIs as JSON or XML. Where v2 announces events, FHIR lets systems ask questions and exchange structured records on demand, which is why national services and new integration specs are built on it.
The NHS-specific fact that matters: base FHIR is deliberately loose, so the NHS constrains it with UK Core, a set of profiles on FHIR R4 that pin down identifiers (the NHS number, verified the NHS way), mandatory elements and terminology bindings. When a spec says FHIR in an NHS context, it almost always means R4 shaped by UK Core. On the map: FHIR is the API and resource layer, the default for new builds and national connectivity, coexisting with the v2 estate rather than replacing it.
SNOMED CT: the meaning layer across everything
SNOMED CT is different in kind from the other three: it isn't a way of moving data, it's a way of meaning it. It's the NHS's standard clinical terminology: a vast, structured catalogue of clinical concepts, each with a unique identifier, human-readable descriptions and defined relationships to other concepts.
It lives inside the payloads of the transport standards. A coded diagnosis in a v2 message, a coded problem in a FHIR Condition resource, a coded procedure in an ITK3 discharge document: in a well-built estate, all of those carry SNOMED CT concepts drawn from governed value sets. That's why terminology deserves its own infrastructure and governance, which this blog covers in depth in the terminology cluster. On the map: SNOMED CT is the semantic layer, spanning all the others, and it's the layer estates most often neglect.
ITK3: the document layer between organisations
ITK3 (the third generation of the NHS Interoperability Toolkit) is the framework for structured correspondence between organisations, and its flagship use is transfer of care: discharge summaries, emergency care discharges and outpatient letters travelling from a Trust to the GP system.
Structurally, ITK3 wraps a FHIR document in a standard messaging envelope with defined acknowledgement and response behaviours, so the sender knows the correspondence arrived and was processed, and it typically travels over national transport such as MESH. One nuance worth knowing: ITK3's specifications were built on an earlier FHIR release (STU3) than the R4 that UK Core targets, which is precisely the kind of version seam a real estate has to absorb quietly. On the map: ITK3 is the inter-organisation document layer, doing a job neither a v2 event nor a bare FHIR API is shaped for.
How the four fit together on one patient journey
Follow one admission and the map animates. A patient is admitted: the PAS emits a v2 ADT message over MLLP, and the EPR, pathology and the bed board update in near real time. Bloods are taken: results return as v2 ORU messages, their test and result codes drawn from governed terminology. The clinical record accumulates SNOMED CT coded diagnoses and procedures as care proceeds. Demographics are confirmed against the national Personal Demographics Service over its FHIR API. And on discharge, a structured summary leaves the Trust as an ITK3 document over MESH, landing in the GP system with an acknowledgement flowing back.
One journey, four standards, each doing the job it's shaped for. No single one of them could carry the whole journey alone, which is the point the vertical documentation never quite makes.
Choosing the right standard for a given job
In practice you rarely choose a standard in the abstract; the estate and the counterparty choose, and your job is translation. But when a genuine choice exists, the shape of the job decides it. Real-time events inside the organisation: HL7 v2, because that's what the estate emits and consumes. New APIs, national service connectivity, or anything greenfield: FHIR R4 with UK Core, because that's where the NHS is standardising. The meaning of clinical content, in any of the above: SNOMED CT, bound through value sets rather than free-typed. Structured correspondence crossing organisational boundaries: ITK3, because documents with acknowledgement semantics are its whole purpose.
The practical corollary is that an integration layer earns its keep by speaking all four natively and translating between them. That conviction is why WeHub is built as one platform with four products (Studio for workflows and Term for terminology live today, with Records and Proof in development) rather than a tool for any single standard.
The bottom line
The standards aren't rivals and the estate isn't confused; it's layered, and the layers make sense once you see the whole map at once. Events inside the walls: v2. APIs and new builds: FHIR shaped by UK Core. Meaning throughout: SNOMED CT. Documents between organisations: ITK3. Keep this page as the index; the deeper pieces on each layer are where to go next, and a worthwhile exercise this week is to sketch your own estate against these four layers and mark where each boundary actually sits. The gaps you find are your integration roadmap.
