Written by Technical Team | Last updated 04.12.2025 | 11 minute read
Modern MEDITECH Expanse environments are rarely “pure FHIR” or “pure HL7”. In real hospitals and health systems, new digital tools must coexist with legacy integrations, long-established interfaces and operational realities that do not fit neatly into a single standard. That is why hybrid interoperability – consciously combining FHIR, HL7 v2 and custom interfaces – has become the most realistic path to integrating with MEDITECH Expanse at scale.
For digital health innovators, integration teams and provider organisations, this raises both risk and opportunity. The risk is a tangled ecosystem of point-to-point feeds, duplicated data and brittle interfaces that break whenever MEDITECH, a third-party system or the wider architecture changes. The opportunity is a carefully designed hybrid model in which each technology is used for what it does best: real-time events over HL7 v2, modern APIs via FHIR, and targeted custom interfaces for genuinely local needs.
This article explores how to think about hybrid interoperability with MEDITECH Expanse in a strategic way. It looks at where FHIR fits, where HL7 v2 remains indispensable, and where custom APIs or other mechanisms can and should be used. It also examines the architectural, governance and operational considerations needed to make this blend robust, safe and sustainable.
It is tempting to imagine FHIR as the new, clean layer that will eventually replace everything else. In practice, especially in established MEDITECH Expanse environments, organisations already rely on extensive HL7 v2 messaging for admissions, discharges, transfers, orders and results. These interfaces feed downstream systems such as PAS, theatre systems, laboratory platforms, radiology, billing and population health tools. Turning these off is not an option; the question is how to add FHIR and new interfaces in a way that complements what is already there.
Hybrid interoperability starts from the recognition that different standards are optimised for different jobs. HL7 v2 has long been the workhorse for real-time transactional messaging between clinical systems, particularly within a hospital. FHIR, by contrast, excels at modern API-driven access to clinical records, supporting mobile apps, cloud analytics, and cross-organisational services. Custom interfaces – whether REST APIs, file drops, ETL processes or proprietary connectors – fill in the gaps where neither FHIR nor HL7 v2 fully cover a particular workflow or data requirement.
In a MEDITECH Expanse context, this means you are unlikely to design a purely FHIR-based integration or a purely HL7-based integration, especially if your goal is to support both operational workflows and modern digital experiences. A remote monitoring platform might rely on FHIR APIs to pull longitudinal patient data while using HL7 v2 to receive real-time ADT events. A command centre solution might take a feed of HL7 v2 messages for bed movements and orders, supplemented by custom queries or ETL jobs to aggregate historical data.
The most important mindset shift is to treat hybrid interoperability as an intentional architecture, not a necessary evil. When you explicitly define which types of traffic use which standard, and how different integration paths relate to each other, you can control complexity instead of being controlled by it. That clarity underpins everything else: technical design, interface governance, troubleshooting and long-term evolution of the environment.
A robust hybrid architecture for MEDITECH Expanse begins with a simple question: which integration needs are transactional and event-driven, which are query-based and read-heavy, and which are genuinely bespoke? The answers guide where HL7 v2, FHIR and custom interfaces should sit within your overall design.
For many organisations, HL7 v2 remains the backbone for patient administration and order workflows. ADT messages carry information about admissions, discharges and transfers that downstream systems depend on for real-time awareness of patient location and status. ORM and ORU messages convey orders and results between MEDITECH and laboratory, radiology or other diagnostic systems. These flows are well understood, heavily tested and deeply embedded in operational processes. Replacing them wholesale with FHIR would be high risk and rarely cost-effective.
FHIR, in contrast, is ideal for use cases that require on-demand access to richer clinical context or data aggregation across multiple domains. Mobile ward-round applications, digital front door tools, virtual wards, remote monitoring solutions and advanced analytics platforms are all natural consumers of FHIR APIs. In a hybrid Expanse architecture, these systems can call FHIR endpoints to pull Patient, Encounter, Observation, Medication, Condition and other resources, while subscribing to HL7 v2 feeds for notifications of relevant events.
Custom interfaces still have a legitimate place, but they should not be the default answer whenever something is hard. Instead, they are best used when you need:
Within this hybrid landscape, an integration engine or interoperability platform plays a crucial role as the central mediator. It can route HL7 v2 messages, translate them into FHIR resources where helpful, orchestrate calls to MEDITECH FHIR APIs, and expose unified interfaces to downstream systems. This layer is also the natural home for cross-cutting concerns: auditing, error handling, monitoring, security and throttling.
The last piece of the design puzzle is tenancy and environment management. MEDITECH Expanse deployments often include separate test, training and live environments, and large organisations may operate multiple instances. A well-designed hybrid architecture abstracts these differences through configuration. HL7 feeds and FHIR endpoints for each environment are configured centrally, but the integration logic remains consistent. This makes it possible to move integrations from non-production to production with confidence, while reusing patterns across organisations and even across countries.
Once the architectural principles are clear, attention turns to implementation. In real MEDITECH Expanse projects, the most successful integrations are those that treat FHIR and HL7 v2 as complementary patterns rather than rivals. They use each technology where it shines and introduce translation or abstraction only where it genuinely adds value.
For HL7 v2, the emphasis is on consistency and robustness. ADT, ORM and ORU feeds should be clearly documented, with message structures, trigger events, optional segments and local Z-segments agreed and version-controlled. Downstream systems should consume these messages through a managed integration layer rather than via direct point-to-point connections wherever possible. That integration layer can enforce validation rules, provide dead-letter queues for problematic messages, and offer dashboards so support teams can see what is flowing where.
FHIR implementation involves a different set of patterns. Client applications need to implement secure access using OAuth or similar mechanisms, and they must handle pagination, search parameters, partial data and versioning in line with FHIR conventions. In MEDITECH Expanse environments, it is common to use FHIR primarily for read operations initially, gradually introducing write operations as clinical governance and confidence mature. Applications may also need to cope with variations in resource coverage and maturity across different Expanse deployments, so defensive coding and configuration-driven behaviour are important.
Some of the most powerful hybrid patterns arise when you consciously combine HL7 v2 events with FHIR queries. For example, a remote monitoring platform might subscribe to ADT messages to be notified when a patient is admitted, discharged or transferred, then call FHIR APIs to retrieve clinical details or care plans only when necessary. This reduces the volume of data moving through the system while ensuring that the application always has up-to-date context when it needs it. Similarly, a digital pre-assessment tool might use HL7 order messages to track when procedures are scheduled, supplemented by FHIR calls to fetch relevant lab results or allergy data.
One of the practical challenges of hybrid implementation is mapping between HL7 v2 messages and FHIR resources where you need a unified view. This mapping can be done on demand – for example, transforming selected HL7 fields into a FHIR representation for downstream services – or as part of a broader normalisation strategy feeding an enterprise data platform. Either way, you should take care to record how fields map, what code systems are involved, and where information may be lost or approximated. Clear mapping documentation becomes invaluable when troubleshooting and when onboarding additional systems.
The key is not to over-engineer. Not every HL7 v2 message stream needs to be transformed into FHIR, and not every FHIR resource needs a corresponding HL7 feed. Start with the specific workflows your organisation or product cares about, pick the simplest patterns that will work reliably, and build up a library of proven integration recipes over time.
Hybrid interoperability creates more touchpoints, more moving parts and more possibilities for things to go wrong – which is why data quality, clinical safety and governance cannot be afterthoughts. A MEDITECH Expanse integration that works technically but undermines data integrity or confuses clinicians will not last long in a live environment.
Data quality issues often arise where multiple standards and interfaces overlap. If a downstream system receives both HL7 v2 messages and FHIR payloads that appear to represent the same event, discrepancies in timing, coding or content can cause confusion. Similarly, if a custom interface writes data into a domain already populated via HL7 or FHIR, duplicates and conflicting records may appear. To avoid this, it is important to define clear “sources of truth” and update pathways for each data domain.
A practical approach is to establish governance rules such as:
Clinical safety should be treated as a first-class concern in hybrid MEDITECH Expanse projects. For clinician-facing applications, you must be explicit about how quickly data is expected to update, what happens if a message is delayed or a FHIR call fails, and how the user interface communicates data freshness and limitations. For example, an app that displays observations or orders should make clear whether it is showing real-time information or data last synchronised at a specific time. Where necessary, the application should encourage clinicians to verify critical information directly in MEDITECH before making high-risk decisions.
Governance structures, such as integration steering groups or digital clinical safety forums, can help keep a handle on the complexity. They provide a place for architects, clinicians, information governance and operational teams to agree standards, approve new interfaces and review incidents. Over time, these groups can curate a catalogue of approved integration patterns and reusable components, reducing the need to design each new interface from scratch.
The human factors side is just as important. Hybrid interoperability changes how people experience data and systems. Clinicians may see new sources of information, new alerts or new workflows that depend on integrated data. If these changes are not explained and supported, they can erode trust. Strong communication, training and feedback loops with end-users help ensure that the hybrid model enhances care rather than adding noise.
Designing one hybrid integration is challenging; doing it repeatedly across multiple organisations, regions or countries is where the true test lies. A scalable approach to MEDITECH Expanse interoperability treats each integration not as a one-off project, but as an instance of a standard pattern with clearly defined variation points.
For multi-hospital groups or vendors serving multiple Expanse customers, it is helpful to define a baseline integration blueprint: a documented, reference architecture that describes how HL7 v2, FHIR and custom interfaces fit together, what the mandatory and optional components are, and which elements can be configured per organisation. This blueprint can then be adapted for each site, rather than reinvented.
Operationally, scaling hybrid integrations means investing in monitoring, automation and support. You need visibility not just into whether a given interface is up or down, but into its latency, error patterns and utilisation. A central observability layer that spans HL7 feeds, FHIR calls and custom APIs makes it much easier to detect emerging issues before they impact clinicians or patients. Automation can help with repetitive tasks such as environment provisioning, configuration deployment and regression testing after MEDITECH upgrades or interface changes.
Continuous improvement is the final ingredient. As more systems, hospitals and partners join your hybrid ecosystem, patterns will emerge: recurring errors, common extension requirements, popular workflows and underused interfaces. Treat this as feedback. Retire patterns that no longer deliver value, refactor hotspots that cause disproportionate support effort, and update your blueprint to reflect what works best in practice. Over time, your hybrid interoperability model becomes an asset in its own right – a proven, evolving way of integrating with MEDITECH Expanse that new projects can rely on.
Hybrid interoperability with MEDITECH Expanse is not about choosing between FHIR, HL7 v2 or custom interfaces. It is about understanding the strengths and limitations of each, then combining them in a deliberate, well-governed architecture that can be trusted in clinical practice. With a clear strategy, careful implementation and ongoing optimisation, organisations can unlock the full value of Expanse while enabling modern digital health innovation on top of a stable, interoperable foundation.
Is your team looking for help with MEDITECH Expanse integration? Click the button below.
Get in touch