Written by Technical Team | Last updated 30.01.2026 | 16 minute read
Secondary care EPR integration in the NHS is rarely a clean-sheet exercise. Even in Trusts that have invested heavily in modern platforms, the operational reality is that hospital environments are a living ecosystem of EPR modules, departmental systems, national services, and partner organisations—each with its own cadence of change, contractual constraints, and technical heritage. In that ecosystem, HL7 v2 remains the workhorse for a large proportion of hospital messaging, while FHIR has become the strategic direction for API-first interoperability, national connectivity, and vendor roadmaps.
For digital health vendors and NHS organisations alike, the challenge is not choosing one standard over the other. It is designing a safe, secure, and maintainable architecture where HL7 v2 and FHIR can coexist, complement one another, and evolve over time—without breaking clinical workflows, creating data ambiguity, or embedding fragile point-to-point integrations that become unmanageable after go-live.
This article explores how to architect HL7 v2 and FHIR coexistence in NHS hospital environments, with a practical focus on secondary care EPR integration. It aims to help you think beyond “connectivity” and towards an interoperability capability: one that respects clinical risk, information governance, operational resilience, and the nuanced realities of hospital delivery.
Hospital interoperability has always been shaped by two forces: the immediate need to keep services running safely today, and the long-term need to modernise. HL7 v2 sits firmly in the first category. It is ubiquitous across admissions, discharges, transfers, orders, results, scheduling, and departmental workflows because it is proven, widely supported, and deeply embedded in supplier products and hospital integration engines.
FHIR, meanwhile, represents an architectural shift rather than simply a new message format. It supports granular resource-based exchange, event-driven APIs, modern authentication patterns, and more consistent semantics when implemented with strong profiling and governance. It also aligns with how digital services are built today: iterative delivery, reusable components, API catalogues, and developer experience as a first-class concern.
In practice, this means NHS Trusts and vendors increasingly operate in a mixed landscape. A single end-to-end workflow might involve HL7 v2 messages from an EPR to a lab system, an API call to a modern clinical decision support service, a FHIR-based interaction with a national or regional capability, and an integration engine coordinating transformations, routing, and monitoring across the entire chain.
The coexistence problem appears when organisations treat HL7 v2 and FHIR as separate “integration projects” instead of designing a cohesive interoperability strategy. The result is often duplication of logic, inconsistent identifiers, competing sources of truth, mismatched event timing, and brittle workarounds that surface as clinical risk (for example, displaying out-of-date allergies or duplicating results). Coexistence done well avoids these outcomes by acknowledging that standards do not deliver interoperability on their own—architecture, governance, and operational control do.
There is also a commercial reality: many secondary care EPR suppliers are on a journey. Some expose mature FHIR APIs across key clinical domains; others provide FHIR for selected use cases while relying on HL7 v2 for core operational feeds; and some remain heavily message-oriented with proprietary interfaces. Your architecture must be adaptable across this spectrum, because a Trust’s environment is rarely homogeneous and will evolve across the lifespan of your integration.
Ultimately, HL7 v2 and FHIR coexistence is less about technical translation and more about designing a dependable bridge between two paradigms: message-driven, event-based integration on one side; and resource-oriented, API-driven interoperability on the other. The bridge must preserve meaning, timing, and safety at every step.
The strongest coexistence architectures are those that separate concerns clearly: transport, transformation, orchestration, clinical safety controls, and observability should not be conflated into a single hard-coded interface. In NHS secondary care, this usually means treating your integration layer as a product in its own right—whether that is an interface engine, an API gateway, a cloud integration platform, or a hybrid approach aligned to Trust constraints.
A common anti-pattern is “FHIR façade over HL7 v2” implemented as a thin converter that simply maps fields. This can work for limited read-only scenarios, but it often fails when you need reliable write-back, idempotency, event ordering, or clinical-grade reconciliation of updates. HL7 v2 messages are typically optimised for operational events (“patient admitted”, “order placed”), whereas FHIR resources are optimised for state (“what is the current patient record?”). Translating between event and state is not a simple mapping exercise; it requires explicit decisions about how events update state, how conflicts are handled, and how downstream consumers are protected from partial truth.
A more robust approach uses a coexistence architecture that acknowledges three layers:
This doesn’t require a single monolithic canonical model for every domain on day one. It does require a deliberate stance on which domains you will normalise, which you will pass through, and where you will enforce semantic consistency. Most organisations start with high-value, high-risk domains such as demographics, encounters, orders/results, allergies, medications, and documents—then expand.
Key architecture patterns you can adopt include:
When selecting a pattern, resist the temptation to optimise only for build speed. In NHS hospital environments, the cost of change after go-live is high because change must pass through clinical safety assurance, information governance, supplier release cycles, and Trust operational governance. The architecture you choose should therefore privilege maintainability: clear versioning, predictable transformations, robust monitoring, and safe fallbacks.
To make these patterns real, the following design considerations tend to matter most in secondary care EPR integration:
A practical way to operationalise this section is to treat HL7 v2 and FHIR as two “interfaces” into the same interoperability capability. HL7 v2 becomes your high-throughput event intake for core hospital operations; FHIR becomes your curated, governed contract for digital services, partners, and modern apps. The integration layer is the translator, but also the safety system, the audit trail, and the control plane.
If the architecture is the skeleton, semantics are the nervous system. In secondary care EPR integration, many projects stumble not because the message can’t be parsed or the API can’t be called, but because the meaning of data is interpreted differently across systems. Coexistence magnifies this risk because HL7 v2 and FHIR embody different assumptions about how meaning is represented.
HL7 v2 often encodes meaning through local code sets, repeated fields, implied context, and segment-specific conventions. Two Trusts can use the same HL7 v2 message type but populate key fields differently based on configuration, supplier customisation, or historical decisions. FHIR aims to be more explicit, but only becomes truly interoperable when profiles, terminology bindings, and implementation agreements are enforced. Without that discipline, you simply move ambiguity from messages to resources.
The first step is to decide what “correct” means for your integration. In hospital environments, “correct” must be defined in clinical workflow terms rather than purely technical terms. For example:
These decisions are clinical safety decisions as much as integration decisions. They determine whether a clinician could act on misleading information. That is why coexistence architecture must be paired with a clinical risk management approach that identifies hazards introduced by transformation, timing, and data presentation.
A reliable HL7 v2–FHIR coexistence strategy typically includes a “semantic contract” that covers identity, encounters, and clinical concepts:
Identity and patient matching is especially important in secondary care, where multiple identifiers coexist. You may have an NHS number, local hospital number, and system-specific identifiers. HL7 v2 messages may carry several, sometimes inconsistently. Your coexistence layer should implement a consistent approach to identifier precedence, validation, and cross-referencing. If you expose FHIR resources, you must ensure the identifier strategy is stable, predictable, and robust to merges/unmerges and temporary identifiers.
Encounters and location context are another frequent source of confusion. HL7 v2 can represent movements through PV1 and related segments, but interpretation varies. FHIR models encounters, locations, and episodes differently, and it’s easy to misrepresent the clinical context if you oversimplify. In hospitals, encounter context drives access decisions, clinical task lists, and operational dashboards; getting it wrong leads to both safety and operational impact.
Clinical concepts and terminologies—diagnoses, procedures, observations, allergies, medications—need a strategy for normalisation. You do not have to normalise everything on day one, but you must be clear where you will enforce consistent coding and where you will pass through local codes with clear labelling. A common approach is progressive normalisation: keep local codes for operational integration initially, then introduce standard coding for analytics, cross-organisational exchange, and advanced decision support.
Coexistence also brings a specific technical challenge: translating between event-based and state-based views of the world. HL7 v2 tells you what happened; FHIR consumers often want to query what is true now. Bridging the two safely requires:
This is where testing needs to go beyond “does the interface work?” and into “does the workflow behave safely under stress?” Testing should include replay scenarios, out-of-order events, duplicate message delivery, and late corrections. It should also include real clinical edge cases that appear frequently in hospitals: patient merges, newborn registration patterns, temporary identifiers, ward moves, bed swaps, and results that are corrected after initial posting.
Finally, clinical safety must be designed into the integration, not documented afterwards. The practical expression of this is designing controls that reduce the risk of harm. Examples include: refusing to overwrite higher-quality identifiers with lower-quality ones, blocking write-back when encounter context is uncertain, flagging data freshness to users, and implementing safe defaults when data is missing. Coexistence can be clinically safe, but only if the system acknowledges uncertainty and handles it explicitly.
Secondary care EPR integration is delivered in a governance-rich environment for good reason: hospital systems are safety-critical, process-sensitive, and entrusted with highly confidential data. When you design HL7 v2 and FHIR coexistence, you must align technical delivery with NHS expectations around information governance, assurance, and operational accountability.
A key point is that “integration” is not a single risk; it is a collection of risks across confidentiality, integrity, availability, and clinical safety. The coexistence layer becomes part of the clinical pathway, even if it is “just middleware”. That means it must be treated as a production service with clear ownership, support models, and controls.
Security design should start with data classification and access patterns. Hospital integrations often span on-premise networks, supplier-hosted environments, cloud services, and third-party applications. Trust network constraints, firewall rules, and supplier remote access models can all shape the feasible architecture. A secure design should assume that perimeter controls alone are not enough; you need layered security at the interface level.
In FHIR-based integrations, modern authentication and authorisation patterns are central. But even HL7 v2 interfaces need explicit controls: interface accounts, network segregation, message validation, and auditability. A common mistake is to focus heavily on API security while leaving HL7 v2 feeds under-protected because “that’s how it’s always been done”. In coexistence architectures, the HL7 v2 side is frequently the highest-volume, highest-impact channel—so it needs equally mature controls.
Operational assurance also includes resilience. Hospitals do not stop when an integration fails; they fall back to manual processes, create workarounds, or experience delays that harm flow and care quality. Your coexistence architecture must be designed for failure: queued delivery, back-pressure handling, message persistence, replay tooling, and transparent incident response processes. Monitoring is not optional; it is a safety feature.
The governance landscape also demands that you can evidence what you have done and why. In a Trust context, that means being able to show the rationale for data flows, the safeguards applied, the testing performed, and the approach to ongoing change. Coexistence solutions frequently evolve after go-live—new endpoints, new message fields, new clinical contexts—so you need a change control approach that keeps safety and compliance intact.
Here are practical governance and assurance elements that tend to make or break secondary care EPR integration programmes:
A useful way to think about this is: the more your coexistence layer becomes a hub for multiple systems, the more it must behave like a platform service. That includes product-grade operational maturity: runbooks, service level objectives, capacity planning, and structured change management. NHS hospital environments reward reliability and clarity. If your integration approach is opaque or fragile, it will quickly become a barrier to adoption—no matter how elegant the data model is.
Even the best architecture will struggle without a delivery approach that reflects how NHS secondary care operates. Hospital integration programmes have many stakeholders: Trust IT, clinical safety officers, information governance, EPR suppliers, departmental system suppliers, digital teams, and frontline services. They also have practical constraints: change windows, release freezes, vendor certification processes, and competing operational priorities.
A scalable delivery approach starts with discovery that is genuinely end-to-end. It is not enough to capture an interface specification; you must map clinical workflows, operational ownership, and how exceptions are handled. For coexistence in particular, discovery should clarify where HL7 v2 feeds exist today, what they mean in that Trust’s configuration, and what the future-state FHIR expectations are. You need to understand not only data fields, but also the “shape of change”: what events happen, how often, and what edge cases occur in real hospital life.
Design should then translate discovery into a coherent integration strategy that avoids accumulating one-off decisions. This is where the “platform mindset” matters. If every Trust deployment results in a bespoke mapping and a unique operational model, you will struggle to scale and maintain. Instead, aim for a core coexistence blueprint with configurable elements: identifier mapping rules, routing tables, profile constraints, environment endpoints, and workflow toggles. The goal is to enable Trust-specific variation without rewriting the integration each time.
Build and test should follow a “clinical realism” principle. Technical testing alone will not reveal the issues that cause the most pain in secondary care: duplicates, corrections, merges, timing delays, partial records, and conflicting updates. Incorporate scenario-based testing early, using realistic event sequences. Validate not only that the interface is correct, but that the consuming application behaves safely and predictably under common hospital edge cases.
Go-live planning must be operational. Secondary care go-lives are less about flipping a switch and more about coordinating people, processes, and rapid response. Your runbooks should include what happens when messages stop, when data quality issues appear, when an upstream supplier changes behaviour, and when a clinical team reports a mismatch. If you cannot observe and explain what the integration is doing in near real time, you will struggle during go-live even if the build is technically correct.
Finally, coexistence architecture requires a conscious approach to evolution. The whole point of designing HL7 v2 and FHIR together is to enable gradual modernisation without disrupting care. That means establishing a roadmap: which domains move towards FHIR first, what decommissioning looks like for legacy feeds, how you will handle versioning, and how you will onboard new consumers safely.
A mature delivery approach treats post-go-live as the start of a managed lifecycle, not the end of a project. Monitoring, optimisation, and iterative enhancements are where value compounds—especially when the integration becomes a reusable capability across multiple Trusts, services, or products.
If you want HL7 v2 and FHIR coexistence to be more than a technical compromise, you must design and deliver it as an operating model: clear ownership, robust controls, strong semantics, and a pathway to modernisation. Done well, secondary care EPR integration becomes an enabler of safer workflows, faster innovation, and better connected care across NHS hospital environments.
Is your team looking for help with secondary care EPR integration? Click the button below.
Get in touch