Written by Technical Team | Last updated 15.11.2025 | 11 minute read
MEDITECH Expanse has been positioned as a modern, web-based EHR designed to be interoperable and cloud-ready. It exposes a growing set of standards-based interfaces, including HL7 FHIR resources, SMART on FHIR app launch capabilities, RESTful APIs and traditional HL7 v2 messaging, all supported by tooling such as the Greenfield Workspace for developers. This marks a clear shift away from closed, monolithic hospital systems towards more open ecosystems in which partner solutions, analytics platforms and digital health tools can all coexist around the core EHR.
Yet, even with rich interoperability capabilities, many healthcare organisations still approach Expanse integration from a point-to-point mindset. Systems are wired up directly to the EHR via flat-file transfers, isolated interface engine routes, or tightly coupled API calls. Each new connection creates another bespoke thread in a growing web of dependencies. Over time, this becomes fragile and difficult to evolve, especially as care pathways change, new digital services emerge, and data volumes increase.
Event-driven architecture (EDA) offers a different foundation. Rather than thinking in terms of systems calling each other in sequence, EDA encourages organisations to think in terms of business events: admission, referral, discharge, medication prescribed, consent updated, appointment booked, observation recorded. When Expanse is integrated into an event-driven ecosystem, it is both a source and a consumer of these events. That shift has profound implications for scalability, resilience, and the organisation’s ability to innovate quickly without repeatedly re-plumbing the EHR.
At its core, event-driven architecture is about reacting to change. An event is simply a record that “something happened” that matters to the business. In healthcare, those events map naturally to clinical and operational milestones: a patient is registered, a lab result is verified, a referral is accepted, an ambulance arrives, a bed is assigned. Technically, those events might be represented as HL7 v2 messages, FHIR resources, JSON payloads on a message bus, or database change-data-capture records, but the conceptual model is the same: events are the primary building blocks of system interaction.
EDA typically makes use of a pub/sub (publish–subscribe) model. Systems that detect or originate a change publish an event to a broker or streaming platform, such as an integration engine with pub/sub capabilities or an event streaming backbone. Other systems subscribe to the categories of events they are interested in: for example, a population health tool might subscribe to all “discharge summarised” events, while a theatre scheduling system might subscribe to “surgery booked” events. Critically, the publisher does not need to know who the subscribers are. That decoupling reduces integration complexity and makes it far easier to add new consumers later.
In the healthcare domain, EDA and standards like FHIR complement each other. FHIR defines how clinical data is structured and exchanged, while EDA defines how and when systems communicate. A FHIR Observation resource can be used as the payload of a “new result available” event; a FHIR Appointment resource might be the body of an “appointment cancelled” event. By standardising both the shape of the data and the pattern of communication, organisations can reduce the friction of connecting Expanse to third-party services and internal systems.
Another important idea is the distinction between commands and events. A command is a request — for example, “create this appointment in Expanse” — while an event is a statement of fact — “this appointment was created”. In an event-driven Expanse ecosystem, external systems might publish commands to a dedicated API gateway or orchestration layer, which then interacts with Expanse via its RESTful APIs or FHIR endpoints. Once Expanse confirms the change, the integration platform publishes an event describing what actually happened. This pattern ensures that the event stream remains an accurate reflection of the EHR’s source of truth.
Over time, the event log itself becomes a strategic asset. Because events are immutable records of what occurred and when, they can support advanced analytics, retrospective investigations, auditability and the reconstruction of patient journeys across multiple systems. This is particularly powerful when MEDITECH Expanse is one of several EHRs or clinical systems in a regional or national environment, and organisations want to understand end-to-end care pathways that span multiple providers.
Using event-driven architecture as the foundation for Expanse integration requires a deliberate platform design. Rather than allowing each project to build its own bespoke plumbing, many organisations are moving towards shared integration platforms that combine event streaming, API management, transformation capabilities and observability. MEDITECH’s Greenfield Workspace and RESTful API Infrastructure sit within this broader context as EHR-facing components, while the organisation’s own integration platform acts as the backbone that connects everything else.
A common approach is to introduce a canonical event model for core clinical and operational events. For example, an “EncounterUpdated” event might include a canonical representation of the patient, encounter identifiers, location, care team, status and timestamps. When Expanse emits an HL7 v2 ADT message or a FHIR Encounter update, the integration platform transforms it into this canonical event and publishes it on the event bus. Downstream systems then subscribe to the canonical events rather than to the raw Expanse messages. This reduces the risk of downstream systems being tightly coupled to vendor-specific formats and makes it easier to incorporate additional sources in future.
Designing the flow from MEDITECH Expanse into the event-driven world often involves a combination of FHIR APIs, RESTful endpoints and legacy interfaces. For transactional scenarios such as patient-facing apps or virtual wards, FHIR R4 APIs exposed via Greenfield can be used to retrieve and update Expanse data in real time. For high-volume feed-style scenarios, existing HL7 v2 interfaces are still extremely valuable: ADT, ORM, ORU and other message types become a rich stream of events. The integration platform normalises these feeds, enriches them when necessary (for example, by resolving local codes to a terminologies service), and emits structured, versioned events.
Within the platform, it helps to clearly separate concerns: event transport, transformation, orchestration, and policy enforcement. A typical architecture will include components such as:
By treating these as shared platform capabilities rather than project-specific artefacts, organisations can significantly reduce the time and cost of integrating new solutions with MEDITECH Expanse. A new digital pathway might simply involve defining a new subscription to existing events, adding a focused microservice to perform some logic, and perhaps extending the canonical model slightly, rather than building a full stack of bespoke interfaces.
Security, privacy and regulatory compliance must be built into the platform from the outset. In practice, this means that events flowing from Expanse into the platform should be minimised to what is necessary, appropriately pseudonymised for analytics use cases, and encrypted in transit and at rest. Role-based access control and fine-grained scopes — including SMART on FHIR-style permissions — should be enforced at the gateway, with service-to-service communication authenticated via modern mechanisms such as mutual TLS or token-based authentication. An event-driven platform makes centralised enforcement easier, because events tend to flow through a small number of well-defined channels rather than ad hoc connections between every pair of systems.
When MEDITECH Expanse is integrated into an event-driven ecosystem, a wide range of use cases become easier to deliver and scale. Real-time, cross-system reactions to clinical activity stop being the exception and become the norm. Instead of a project-by-project fight to make Expanse talk to yet another system, teams can plug new capabilities into the event stream and let them react to the same source of truth as everything else.
One cluster of use cases concerns care coordination and patient flow. Admission, discharge and transfer events are natural candidates for an event-driven approach. Each time Expanse records a bed allocation or a change in ward, a corresponding event can drive automatic updates in bed management dashboards, portering systems, housekeeping workflows, and command centres. Because these systems subscribe to events rather than calling each other directly, it is easy to add, for example, an occupancy prediction service that consumes the same events and produces forecasts for operational leaders.
Another cluster of scenarios focuses on digital front doors and remote care. When a patient books or changes an appointment through a patient portal or national booking system, those actions can be handled as commands via APIs into Expanse. Once Expanse confirms the appointment, the integration platform emits appointment events that drive reminder services, pre-visit questionnaires, transportation coordination or remote monitoring kits. Later, when Expanse records clinical observations or outcomes from the visit, new events can drive follow-up tasks, primary care notifications, or research registry updates.
Event-driven integration with Expanse also unlocks powerful patterns around clinical decision support and automation. As FHIR resources such as Conditions, Observations or MedicationStatements are created or updated, events can trigger asynchronous decision-support services. These might check for guideline adherence, suggest alternative treatments, identify candidates for clinical trials, or flag safety issues such as potential interactions. Importantly, these services do not have to be built as modules inside Expanse; they can live as independent, cloud-native services that subscribe to the event stream and interact with clinicians through context-aware apps or notifications.
Common patterns that work well in this context include:
By adopting these patterns around MEDITECH Expanse, organisations create a much more flexible foundation. Need to add a new regional cancer analytics service? Subscribe to the relevant diagnosis, procedure and treatment events. Want to pilot a new digital diabetes pathway? Subscribe to observations, prescriptions and appointments related to a defined cohort, and publish new care-plan updates as events back into the platform for onward propagation.
While event-driven architecture offers significant benefits for MEDITECH Expanse integration, it also demands a higher level of governance than traditional point-to-point interfaces. Without clear ownership, versioning strategies and design principles, an event bus can become as tangled as any legacy interface landscape. The key is to treat events as first-class products, not just technical artefacts.
That starts with naming and modelling conventions. Each event type should have a clear definition, an owner (often a joint responsibility between clinical and technical stakeholders), and a lifecycle that is documented and versioned. Schemas for event payloads — whether based on FHIR profiles, canonical models or a hybrid — should be managed centrally, with tooling that validates messages against those schemas and tracks where each version is used. This is particularly important when events originate from Expanse but are destined for multiple consuming systems with differing levels of sophistication and regulatory oversight.
Robust observability is equally important. An event-driven integration platform for Expanse should provide end-to-end traceability: the ability to see, for a given patient or encounter, which events were produced, which services consumed them, what actions were taken, and where any failures occurred. From an operational perspective, this reduces the time to diagnose and resolve issues. From a clinical safety and regulatory perspective, it is essential for demonstrating that the organisation understands and controls its digital supply chain.
Security and privacy considerations go beyond simply encrypting traffic. In an event-driven world, it is easy for data to be over-shared if governance is weak. Role- and purpose-based access controls need to be enforced not only at the API gateway but also at the event broker. Some topics or event types should be restricted to a small number of highly trusted systems, while others may be anonymised or aggregated for broader consumption. Where Expanse data is used for research or secondary use, additional controls such as tokenisation, pseudonymisation and robust consent management must be in place.
Finally, event-driven integration is as much a change in mindset as in technology. Teams accustomed to building direct Expanse interfaces need to be supported in learning new patterns and practices. Clinical stakeholders should be involved in prioritising which events matter most, which pathways to tackle first, and how to safely introduce automation around the EHR. It often makes sense to start with a small number of high-value, low-risk use cases — such as real-time bed and flow dashboards or digital appointment notifications — and expand from there, gradually migrating legacy interfaces onto the new platform.
When done well, event-driven architecture does not replace MEDITECH Expanse; it elevates it. Expanse remains the system of record for much of the patient’s clinical story, while the event-driven platform becomes the nervous system that connects it to everything else. The result is an ecosystem that is more responsive, more resilient and better able to support the continuous evolution of digital health services, without repeatedly disturbing the core EHR every time innovation is needed.
Is your team looking for help with MEDITECH Expanse integration? Click the button below.
Get in touch