by Format-3

Share article

HL7 explained: a practical guide for healthcare IT

HL7 is the international family of standards that defines how health data is structured, exchanged, and secured across clinical and administrative systems. It is maintained by HL7 International, an ANSI-accredited, not-for-profit standards development organisation whose mission is to empower global health data interoperability. Three things you should know immediately:

• HL7 V2 remains a widely deployed messaging standard in hospital systems worldwide, including across NHS trusts, and will be part of your integration landscape for years to come.
• FHIR is the modern, API-first approach — built on RESTful APIs, JSON/XML, and OAuth2 — and is the direction NHS England is actively pushing for new digital health projects.
• UK practitioners must align with FHIR UK Core and NHS Digital guidance from the outset; retrofitting conformance is significantly more expensive than building to it.

This article is written for healthcare IT professionals and technical stakeholders in the UK who need a clear, implementation-ready understanding of HL7 — not a textbook overview, but a working map of what HL7 is, how it functions, and what to do with that knowledge.

Key takeaways

HL7 is a family of interoperability standards — not software, not a language — and choosing the right specification, aligning with FHIR UK Core, and treating implementation as a product challenge are the three decisions that determine whether your project succeeds.

Point: HL7 is a standards family, not a product | Details: HL7 International defines data models and exchange rules; your team builds the software that follows them.

Point: V2 remains the NHS workhorse | Details: Most NHS trust systems still emit HL7 V2 messages; plan for hybrid V2/FHIR environments in any integration project.

Point: FHIR is the direction of travel | Details: NHS England mandates FHIR R4 APIs for new national integrations; align new builds to FHIR UK Core from day one.

Point: Semantic interoperability is the hard part | Details: Technical compliance is necessary but insufficient; the same field must carry the same meaning across every connected system.

Point: Format-3 delivers product-led HL7/FHIR projects | Details: Format-3 combines product discovery, UX, engineering, and conformance testing for NHS-connected digital health products.

Table of Contents

• What is HL7 and who actually maintains it?
• How do the core HL7 specifications differ from each other?
• How does HL7 work technically?
• Is HL7 a programming language or an API?
• Who still uses HL7 today, and where is the momentum?
• What does the UK context look like for HL7 adoption?
• What should you plan for when implementing HL7 or FHIR?
• Format-3’s practical tips for delivering HL7/FHIR projects
• Where to go next: authoritative resources and practical tools
• Why product-led HL7/FHIR implementations win
• Format-3 brings product thinking to your HL7/FHIR project
• Sources

What is HL7 and who actually maintains it?

HL7 International was founded in 1987 and has grown into the world’s primary health data standards body, with members spanning hospitals, governments, vendors, and academic institutions across dozens of countries. The name “Level Seven” is a historical reference to the application layer of the OSI networking model — the layer concerned with how applications communicate meaning, not just bytes. For practical purposes today, that framing is largely academic. What matters is the output: a family of specifications that give disparate clinical systems a common language.

HL7 does not build software. It defines the rules — the data models, message structures, terminologies, and conformance requirements — that software must follow to interoperate. Think of it as the grammar of health data exchange: systems can be written in any programming language, run on any infrastructure, and still communicate coherently if they follow the same HL7 grammar.

National implementer bodies treat HL7 standards as foundational infrastructure for jurisdictional planning, precisely because no single vendor or government can define a universal health data language alone. HL7 International fills that gap through a consensus-driven, open standards process.

How do the core HL7 specifications differ from each other?

HL7 is not a single standard. It is a family, and choosing the wrong member of that family for your project is one of the most common and costly mistakes in health IT delivery.

HL7 V2

HL7 V2 is the workhorse. It uses an event-driven, pipe-delimited message format — segments like MSH, PID, and OBR will be familiar to anyone who has worked in clinical integration. V2 is extraordinarily widespread: most laboratory systems, radiology platforms, and patient administration systems in UK NHS trusts still emit V2 messages. The problem is flexibility. V2 allows extensive local customisation, which means two systems that are both technically “HL7 V2 compliant” can fail to interoperate without a site-specific Interface Control Document (ICD) negotiated between them.

HL7 V3 and CDA

HL7 V3 introduced a formal, model-driven approach using XML and a Reference Information Model (RIM). It is more rigorous than V2 but also significantly more complex to implement. The Clinical Document Architecture (CDA), which emerged from V3, is an XML-based standard for encoding the structure and semantics of clinical documents — discharge summaries, referral letters, and care plans. CDA remains relevant for document exchange, particularly where a structured, human-readable record needs to travel between organisations.

FHIR

FHIR (Fast Healthcare Interoperability Resources) is the specification that changes the paradigm. Where V2 sends events and V3 sends documents, FHIR exposes resources — discrete, addressable units of health data (Patient, Observation, MedicationRequest) accessible via RESTful APIs using JSON or XML. This aligns with how modern web and mobile applications are built, which is why FHIR enables an agile, API-driven delivery model that V2 simply cannot match without specialist middleware.

Specification: HL7 V2 | Primary use case: Event-driven clinical messaging | Typical format: Pipe-delimited | Common transport: MLLP over TCP | Best fit: Legacy integration, ADT notifications

Specification: HL7 V3 / CDA | Primary use case: Structured clinical documents | Typical format: XML | Common transport: SOAP / HTTP | Best fit: Document exchange, referrals

Specification: FHIR R4/R5 | Primary use case: API-based resource access | Typical format: JSON / XML | Common transport: HTTP / REST | Best fit: New builds, patient apps, NHS APIs

Use-case snapshots:

• V2: ADT (Admit, Discharge, Transfer) notifications between PAS and clinical systems.
• CDA: Structured discharge summaries shared between acute and community providers.
• FHIR: Patient-facing apps, GP Connect APIs, NHS login integrations, and greenfield platform builds.

How does HL7 work technically?

Understanding the mechanics of HL7 exchange helps you scope integration work accurately and avoid underestimating effort.

Message-based vs resource-based architectures

V2 is message-based: a sending system fires a trigger event (a patient is admitted), constructs a message, and transmits it to one or more receivers. The receiver processes the message and returns an acknowledgement. This is a push model, and it works well for high-volume, real-time clinical events. FHIR is resource-based: a client application queries a FHIR server for a specific resource or posts an update. This is a pull-or-push model that maps naturally onto REST conventions familiar to any web developer.

Formats and transports

V2 messages travel most commonly over MLLP (Minimal Lower Layer Protocol) on TCP — a lightweight framing protocol designed for reliable, ordered delivery on private networks. FHIR uses HTTP/REST, which means it can traverse standard web infrastructure, load balancers, and API gateways. CDA documents are typically exchanged via SOAP web services or secure file transfer, though FHIR DocumentReference resources are increasingly used to wrap and deliver CDA content.

Security and authorisation

For V2 over MLLP, security is largely a network concern: TLS on the connection, network segmentation, and audit logging at the application level. FHIR shifts security responsibility to the API layer. OAuth2 and OpenID Connect (OIDC) are the standard patterns for authorising FHIR API access, and NHS Digital’s API platform enforces these patterns for any system connecting to national services. This is a meaningful architectural shift for teams accustomed to V2 — it requires identity provider integration and token management that V2 projects rarely needed.

Engineering tasks to plan for when building HL7 interfaces:

• Select the appropriate Implementation Guide (IG) and version before writing a line of code.
• Define and document ICDs for V2 integrations; map local codes to national terminologies (SNOMED CT, dm+d).
• Build error handling for acknowledgement failures, rejected messages, and partial updates.
• Instrument monitoring and alerting from day one — silent message failures are a patient safety risk.
• Plan conformance testing against the relevant IG before connecting to any production system.

Is HL7 a programming language or an API?

No, and the distinction matters more than it might seem. HL7 is a set of standards — it defines data formats, message structures, and exchange rules. It is entirely independent of the transmission mechanism. You can carry an HL7 V2 message over MLLP, a REST endpoint, a message queue, or even a flat file. FHIR resources can be served by a REST API, bundled into a document, or exchanged asynchronously via a messaging broker.

The confusion arises because FHIR is so closely associated with RESTful APIs that people conflate the standard with the transport. FHIR defines what a Patient resource looks like and what operations are valid; the REST API is simply the most common way to expose those resources.

Three clarifications worth pinning to your project board:

• HL7 defines the what (data model, semantics, rules); your architecture defines the how (transport, API design, infrastructure).
• Choosing FHIR does not automatically give you a working API — you still need to build or procure a FHIR server and design the API surface.
• Architects should select or design the transport layer separately from the data model, and document both decisions explicitly.

Who still uses HL7 today, and where is the momentum?

The honest answer is: almost everyone uses V2, and almost every new project is being built on FHIR. These two facts coexist, and they define the interoperability challenge for the next decade.

Academic and technical literature confirms that V2 remains in active use across clinical environments, with migration to FHIR increasing in new systems. This is not a clean transition. Most NHS trusts run V2 integration engines — products like Rhapsody, Mirth Connect, or InterSystems HealthShare — that process thousands of V2 messages per day. Replacing that infrastructure wholesale is neither practical nor safe.

The practical implication: any interoperability project today must plan for a hybrid environment. You will be reading V2 from legacy systems and exposing FHIR APIs for modern consumers simultaneously, often for years.

The momentum behind FHIR is real and accelerating. NHS England’s API platform publishes FHIR R4 APIs for GP Connect, the National Record Locator, and other national services. The mandate is clear: new integrations should use FHIR where a suitable API exists.

Adoption patterns to plan around:

• V2 for event-driven notifications from PAS, LIS, and RIS systems in existing NHS trusts.
• FHIR for patient-facing applications, national API consumption, and greenfield platform builds.
• CDA for structured document exchange where a human-readable record is the primary artefact.
• Hybrid middleware layers to translate between V2 and FHIR during migration periods.

What does the UK context look like for HL7 adoption?

The UK has a clearer national direction on HL7 than most comparable health systems, which is both an advantage and a constraint.

HL7 UK is the national affiliate chapter of HL7 International, providing a community for UK implementers, hosting working groups, and contributing to the development of UK-specific implementation guides. For any team working on NHS-connected systems, engaging with HL7 UK early is worth the effort — the working groups surface conformance issues before they become production problems.

FHIR UK Core is the national implementation guide that profiles FHIR R4 for the UK context. It defines which FHIR resources are in scope, how UK-specific terminologies (SNOMED CT UK edition, dm+d, NHS number) are represented, and what conformance requirements apply. Aligning with FHIR UK Core from the start of a project reduces friction at every subsequent stage: NHS Digital API onboarding, clinical safety review, and IG conformance testing all become significantly smoother.

NHS England and NHS Digital publish guidance, API catalogues, and testing sandboxes that are the authoritative reference for any team building NHS-connected digital products. The NHS Developer Hub provides FHIR API documentation, sandbox environments, and onboarding pathways.

UK-facing action list for project leads:

• Register with HL7 UK and join the relevant working group for your clinical domain.
• Download and review the FHIR UK Core implementation guide before finalising your data model.
• Access the NHS Digital API catalogue to identify which national FHIR APIs are available for your use case.
• Engage NHS Digital’s onboarding and assurance process early — it takes longer than most teams expect.
• Plan for ongoing IG alignment as FHIR UK Core evolves; treat it as a living dependency, not a one-time reference.

What should you plan for when implementing HL7 or FHIR?

Interoperability projects fail in predictable ways: scope creep driven by underestimated mapping complexity, semantic gaps that only surface in testing, and monitoring gaps that make production failures invisible. A structured approach prevents most of these.

Implementation phases

1. Discovery: Map existing interfaces, identify source systems and their HL7 versions, document data flows, and engage clinical stakeholders to define the semantic requirements. This phase almost always reveals more complexity than the initial brief suggests.
2. Design: Select the appropriate IG (FHIR UK Core for new NHS projects), define your data model, produce ICDs for V2 integrations, and agree on terminology mappings (SNOMED CT, LOINC, dm+d).
3. Build: Develop interfaces and middleware, implement security patterns (TLS, OAuth2/OIDC for FHIR), and instrument logging and monitoring from the first sprint.
4. Test: Run conformance testing against the IG, integration testing with target systems, and performance testing under realistic load. For NHS-connected systems, engage the NHS Digital testing sandbox.
5. Deploy and operate: Release with a rollback plan, establish operational monitoring, and schedule regular reviews against updated IGs.

Pro Tip: Treat your ICDs and terminology mapping documents as living artefacts, not project deliverables. The teams that succeed in HL7 implementations are those that invest in test harnesses and keep their mapping documentation current through every system upgrade.

Data protection and security reminders for NHS/UK projects:

• All health data must remain within UK data residency boundaries unless explicitly approved otherwise.
• Audit logging of all data access is mandatory under NHS data security standards.
• Role-based access control and OAuth2 scopes must be designed to the principle of least privilege.
• Clinical safety must be assessed under DCB0129/DCB0160 for any system that processes clinical data.

Format-3’s practical tips for delivering HL7/FHIR projects

The technical specification is rarely where HL7 projects go wrong. The failure modes are almost always human: misaligned stakeholders, data models designed without clinical input, and APIs built without reference to the user journeys they are meant to serve.

At Format-3, we approach interoperability projects as product design challenges first and integration engineering challenges second. That sequence matters.

Delivery principles that change outcomes:

• Start with user journeys, not data models. Map the clinical workflow before you map the fields. A FHIR Observation resource means nothing until you understand which clinician needs which value at which point in the care pathway.
• Design the API surface for the consumer, not the source system. FHIR gives you flexibility; use it to expose data in the shape the consuming application needs, not in the shape the legacy system happens to store it.
• Build cross-disciplinary squads. Separating clinical informatics, integration engineering, and UX into sequential handoffs is how brittle, unusable systems get built. Co-locate the expertise from discovery through deployment.
• Test conformance continuously, not at the end. Conformance failures discovered in the final testing phase cost ten times more to fix than those caught in the build phase.
• Monitor semantics, not just uptime. A V2 interface that is technically “up” but silently dropping or misrouting messages is more dangerous than one that is visibly down.

Pro Tip: Invest in UX research for healthtech before finalising your FHIR resource profiles. The fields clinicians actually need in a workflow are rarely the fields an integration team assumes they need.

Common delivery traps Format-3 mitigates: scope creep from undocumented V2 customisations, brittle mappings that break on terminology updates, and monitoring gaps that make production failures invisible until a clinician reports a missing result.

Where to go next: authoritative resources and practical tools

The HL7 ecosystem has more documentation than most teams can absorb. These are the sources worth prioritising.

Authoritative references:

• HL7 UK — the national chapter; join the mailing list and relevant working groups.
• FHIR UK Core — available via NHS England’s technical documentation; the mandatory reference for NHS-connected FHIR projects.
• NHS Developer Hub — API catalogue, sandbox environments, and onboarding documentation for national NHS APIs.
• HL7 V2.9 Product Brief — the definitive reference for V2 messaging, including version history and segment definitions.

Practical tools and learning paths:

• FHIR R4 specification at hl7.org/fhir — the normative reference for resource definitions and operations.
• Simplifier.net — a platform for publishing, browsing, and validating FHIR implementation guides, including FHIR UK Core.
• HAPI FHIR — an open-source Java library and reference server for FHIR R4/R5, widely used for testing and development.
• Touchstone (AEGIS) — a conformance testing platform for FHIR that supports IG-based test scripts.
• HL7 Confluence and Zulip — community forums where working group discussions and implementation questions are active.

Immediate next steps:

• Sign up to HL7 UK and identify the working group relevant to your clinical domain.
• Download the FHIR UK Core IG and review the profiles applicable to your project’s data model.
• Spin up a HAPI FHIR sandbox and run your first resource queries before committing to a server architecture.
• Schedule a stakeholder discovery session that includes clinical, informatics, and engineering representation.

Why product-led HL7/FHIR implementations win

Here is the uncomfortable truth that most integration vendors will not tell you: the majority of HL7 implementation failures are not technical failures. They are product failures. The data model was designed without clinical input. The API surface was built for the source system’s convenience, not the consuming application’s needs. The UX was an afterthought bolted onto a technically compliant but practically unusable interface.

FHIR, in particular, creates a false sense of security. Because it uses familiar web patterns, engineering teams sometimes assume the hard work is done once the server is running and the resources are accessible. It is not. Semantic interoperability — the guarantee that the same field carries the same meaning across every system that reads it — is the real challenge, and it requires clinical, informatics, and product expertise working together from day one.

The teams that succeed are those that treat interoperability as a product discipline. They run discovery sprints before writing integration code. They design API surfaces around user journeys. They build cross-disciplinary squads where clinical informatics, engineering, and UX sit together rather than in sequential handoffs. And they monitor semantics in production, not just uptime.

The shift from V2 to FHIR is not just a technical migration. It is an opportunity to redesign how clinical data flows through your organisation in ways that actually serve the people who depend on it. That opportunity is wasted if you treat it as a pure integration project.

Format-3 brings product thinking to your HL7/FHIR project

Healthcare interoperability projects that stall usually share one root cause: they were scoped as integration exercises rather than product challenges. Format-3 brings end-to-end digital product delivery to HL7 and FHIR work — from discovery and data modelling through API design, engineering, conformance testing, and deployment. Our CareHive project demonstrates what this looks like in practice: a healthcare product built with clinical, UX, and engineering expertise working as a single squad, not a relay race.

If your team is scoping an NHS integration, planning a FHIR migration, or building a patient-facing application that depends on health data APIs, the right conversation starts with product discovery, not a technical specification. Speak to Format-3 about your project at Format-3.

Sources

These are the sources worth bookmarking for ongoing reference throughout an HL7 or FHIR implementation.

• HL7 Standards Product Brief - HL7 Messaging Standard Version 2.9 | HL7 International
• What Is HL7? – IT Explained | PRTG
• Active Learning of the HL7 Medical Standard - PMC - NIH
• Health Level Seven (HL7) - Implementer Digital Health

By Format-3

Press & Media

More thoughts

Thought leadership creates value, builds knowledge and takes a stand, bridging the gap between traditional and digital platforms