Written by Technical Team | Last updated 25.10.2025 | 19 minute read
Interoperability in digital health has moved from being a technical aspiration to becoming a clinical and regulatory necessity. Health and care providers are under pressure to share data in real time across settings, systems and organisational boundaries, from acute trusts and diagnostic providers through to social care teams and virtual wards. Yet the reality on the ground is still fragmented. Most health IT estates are a patchwork of electronic health record platforms, laboratory systems, pharmacy systems, scheduling software and population health tools that were never designed to work together. The traditional integration model has been to connect these systems through point-to-point interfaces or via a central integration engine that polls for updates and pushes consolidated messages on a schedule. This works, in the sense that data eventually moves, but it is not aligned with the way modern care is delivered: continuous, distributed, and increasingly virtual.
This is where event-driven architecture, or EDA, begins to matter. In an event-driven model, systems don’t wait to be asked for data, and they don’t share large batches of updates at the end of the day. Instead, they broadcast clinically meaningful events as they happen — such as “patient admitted”, “prescription dispensed”, “observation recorded”, “alert triggered”, or “risk score recalculated” — and any authorised system that cares about that event can consume it. Rather than repeatedly polling an EPR to see whether anything has changed, downstream services subscribe to events and react to them the moment they are published. This reduces latency, removes unnecessary load on source systems, lowers integration debt, and enables more intelligent workflows. For clinicians, that translates directly into better coordinated care. For operational leaders, it enables process automation. For patients, it means that the people looking after them are working with the same, current picture.
The event becomes the unit of interoperability. That sounds relatively simple, but it is in fact a major shift in mindset for healthcare technology teams. Historically, interoperability has been thought of as exchanging “records” — a PDF discharge summary, a full medication list, a PDF of clinic letters. Event-driven thinking reframes interoperability around state changes, not static documents. The significance of this shift cannot be overstated. If all you can share is a snapshot exported once a day, you cannot build safe virtual wards, remote monitoring at scale, community-based urgent care, or dynamic care coordination models. If you can share discrete, structured clinical events as they happen, you can.
Event-driven architecture is also a strategic response to the scalability problem in healthcare integration. When organisations attempt to integrate dozens or hundreds of systems using bespoke interfaces, cost and complexity balloon exponentially. Each new system needs to know about every other system it interacts with. With an event-driven model, you dramatically decouple producers and consumers. Systems publish events to a broker. Consumers subscribe. The producer does not need to know who will consume the data or how it will be used. That loose coupling is fundamental to future-proofing the health IT estate, reducing organisational lock-in, and making it possible to adopt new digital services without repeatedly rebuilding integrations.
From a governance and safety standpoint, event-driven interoperability also generates clear audit trails. Every event is timestamped, versioned and attributable to a source. This improves traceability and clinical safety monitoring, especially across organisational boundaries. In an environment where regulators, boards and clinical safety officers want to know “who knew what, when?”, a well-designed event pipeline becomes an asset not just for delivery, but for assurance.
At the heart of an event-driven architecture are three core actors: event producers, event consumers and the event broker (or event bus). Producers are the systems where clinically relevant changes originate. That may be an electronic patient record raising an “encounter started” event, a remote monitoring platform publishing a “vital sign out of range” event, or a pathology system emitting a “result available” event. Consumers are any downstream services that need to react — alerting tools, care coordination dashboards, shared care records, analytics services or automation engines that generate follow-up tasks. The broker, typically a highly available streaming or messaging platform, acts as the decoupling layer between the two. It receives events from producers, persists them, and makes them available to authorised subscribers in near real time.
Designing the event model is the most important architectural decision a digital health organisation will make in this context. Each event should represent a meaningful change in clinical or operational state. It should include enough context for downstream systems to act safely, but it should not attempt to ship the entire universe of patient data every time. A well-formed “medication administration recorded” event, for example, will identify the patient, the medicine, the dose, the time, the route, and the administering professional. It does not need to include the patient’s full medical history or full medication list. The key is to strike a balance between clinical safety and payload efficiency. If events are too minimal, they will not be useful. If they are too bloated, you are back to sending entire documents under a new label.
Another central principle is immutability. Events are facts about something that has happened. Once published, they are not edited in place; they are appended. If information changes, a new event should be raised to supersede or correct the old one, such as “allergy updated” or “order cancelled”. This immutability is not a purely technical nicety. In health and care, medico-legal defensibility matters. The ability to reconstruct the full timeline of clinically relevant events is invaluable in incident review, complaint handling, and service optimisation. It also allows advanced downstream consumers such as longitudinal analytics platforms or digital twins of patient pathways to replay history in order to detect patterns or predict risk.
Event ordering and idempotency are also crucial. In an asynchronous world, consumers might receive events slightly out of chronological order. Systems must therefore be explicit about sequence numbers, timestamps and identifiers so that consumers can reconcile state safely. Likewise, consumers should be able to process the same event more than once without causing unintended duplication of actions. If the “patient admitted” event is processed twice due to a network retry, for instance, the bed management system must not create two separate admissions. Building idempotency into consumer logic is a practical requirement in clinical environments, where duplicate referrals, duplicate tasks and duplicate alerts can introduce real patient safety risks.
Security, consent management and access control need to be first-class citizens in any health EDA. In other industries, events about user behaviour might be broadcast widely to fuel personalisation or analytics. In health, events often contain sensitive clinical information subject to both regulation and patient expectations. The event bus must therefore enforce fine-grained access rules, and events themselves should be structured to support downstream consent decisions. For example, a social care system may be allowed to consume “hospital discharge planned” events for individuals it supports, but it may not need to see the full diagnostic detail contained in “radiology result finalised”. This calls for a layered approach: topic-level segregation, field-level filtering or redaction, and dynamic enforcement of role-based or relationship-based access models.
Finally, standardisation is essential. Events must not be arbitrary blobs of proprietary data. They need to be structured, typed and consistently interpretable across systems and over time. Using common data models, clinically agreed terminologies and internationally recognised interoperability specifications — for example FHIR resources as payloads and controlled vocabularies for codes — reduces ambiguity and makes it easier to onboard new producers and consumers. Consistency is what allows an ICS, a region or even a national platform to treat event streams as infrastructure rather than as bespoke integration work every single time a new use case comes along.
Implementing an event-driven architecture in a live health ecosystem is not just an infrastructure exercise. It is an organisational change programme that touches clinical workflow, governance, information governance, technical architecture, vendor management and commissioning. A pragmatic strategy tends to follow a phased approach: prove value in a targeted workflow; build reusable capability; scale in a governed way.
A sensible first step is to identify a use case where latency genuinely matters and where the lack of timely data is already causing operational or clinical pain. Typical candidates include: informing community nursing teams when a patient is discharged from hospital; pushing early warning scores and deterioration alerts from virtual wards into urgent response teams; notifying primary care when a high-risk medicine has been changed in secondary care; or triggering rapid review of abnormal pathology results in out-of-hours settings. These are areas where minutes and hours matter, where duplication of phone calls and emails is rife, and where staff are already manually stitching systems together. By focusing on a narrow, high-value event flow — for instance, “discharge planned”, “discharge completed”, “follow-up required” — organisations can quickly demonstrate impact without having to rewire the entire estate.
Once a target workflow is chosen, the next step is to define the event contract. This includes agreeing the event types, the structure and vocabulary of each payload, how patients will be identified, which identifiers will be included for cross-organisational matching, and which metadata fields are mandatory to support audit, safety and triage. Getting clinicians, operational leads and IG stakeholders in the same room at this stage pays dividends. If governance requirements such as consent, safeguarding flags, mental health restrictions, or duty of care obligations are not embedded in the event model from day one, they will emerge later as blockers.
From a technical perspective, selecting and deploying an event broker is the backbone decision. Many organisations adopt mature, battle-tested messaging and streaming platforms that support high throughput, ordering guarantees, replayability and horizontal scaling. The broker should support topic-based publish–subscribe patterns, where producers publish to well-defined topics (for example, patient.admission.created or observation.vitals.abnormal) and consumers subscribe to the topics relevant to them. It should also support durable retention, so that consumers that come online later can still access past events. In a healthcare context, retention policies are often driven by clinical risk and regulatory audit needs: some events may need to be queryable for weeks or months to support investigations, while others (for example, rapidly generated telemetry from wearable sensors) may be aggregated downstream and not require full raw retention.
Integration with legacy systems is usually the hardest practical problem. Many incumbent health systems do not natively “speak events”. They generate HL7 v2 messages, batch CSVs, or expose polling-based APIs. Bridging these systems into an event-driven model typically involves building or procuring lightweight adapters that sit alongside the source system, monitor for state changes, and publish corresponding events onto the broker. Over time, those adapters become part of the standard integration toolkit. The beauty of this approach is that it avoids demanding that every legacy vendor redesign their product on day one, while still letting the wider ecosystem behave in a modern way.
Operational monitoring, observability and clinical safety oversight must never be an afterthought. When EPR A publishes an “allergy updated” event that should appear in shared care record B and medicines reconciliation workflow C, people need confidence that the event was received, processed and rendered. Health providers should invest in dashboards and alerting that track event throughput, failure rates, processing latency and consumer health. This is not just platform SRE hygiene. It is clinical safety. If deterioration alerts stop flowing from a virtual ward to urgent response, a patient could come to harm. Embedding clinical safety officers and IG leads into the design of these monitoring capabilities is a marker of maturity.
To turn a one-off event flow into a broader interoperability capability, organisations need governance. Without governance, an event bus will quickly become noisy, inconsistent and politically fraught. With governance, it becomes shared, trusted infrastructure. Good governance usually includes:
Once these foundations are in place, scaling tends to accelerate. Each new use case is no longer a ground-up integration project but an incremental extension of an already accepted pattern.
Although “event-driven architecture” sounds like a single architectural choice, in practice it is a stack of interlocking capabilities that need to work together smoothly and predictably in clinical environments. These building blocks include messaging infrastructure, canonical data models, identity resolution services, consent and access control services, and downstream consumers that can actually make use of the events.
A robust messaging or streaming layer is the transport fabric. It must deliver high availability, horizontal scalability, message durability and predictable latency. In healthcare settings, it should also support partitioning and isolation to meet data minimisation principles. For example, maternity events may be logically and access-wise distinct from mental health crisis events. The platform should be able to segregate these streams while still operating under a unified technical umbrella. Features such as replay, dead-letter queues and back-pressure handling become vital in real clinical operations, because not all consumers are equally fast or equally reliable. The broker therefore plays two roles: near-real-time delivery for operational workflows, and structured persistence for downstream analytics and audit.
On top of the transport layer sit the event schemas. Using a canonical, well-defined schema for each event type is what unlocks semantic interoperability, not just technical connectivity. In the health domain, it is sensible to align event payloads with widely adopted clinical data models, such as FHIR resources for observations, encounters, medication statements and diagnostic reports. This alignment buys two things. First, it avoids inventing an entirely new dialect for every trust, ICS or vendor. Second, it becomes easier to onboard suppliers and third-party applications, because they can map to existing healthcare standards rather than reverse-engineering bespoke formats. Canonical schemas should also include consistent metadata envelopes capturing provenance (which system created the event), timestamps, unique identifiers, and version information.
Identity resolution is another foundational component. Most health systems operate with more than one identifier for the same person, and sometimes even for the same care episode. A hospital may identify the patient with a local hospital number, primary care will typically use an NHS number or equivalent national identifier, community services may rely on yet another local identifier, and social care may have a case reference of its own. Events need to carry identifiers in a consistent, multi-identifier way, and the receiving systems need a reliable means to match them. This often calls for a patient identity service or master patient index that can reconcile identifiers, manage merges and splits, and surface potential mismatches with clear confidence scores. Without this, event-driven interoperability can propagate identity errors at machine speed.
Consent and lawful basis management are especially nuanced in the health and care context, where different care settings operate under different statutory frameworks, and where patient preferences genuinely matter. An oncology team may have a lawful basis to receive detailed diagnostic updates; a housing support worker in a local authority may only be entitled to know that a vulnerable adult was discharged and requires a home assessment, not the full clinical picture. Implementations should therefore include a policy decision point that evaluates, at subscription time and at consumption time, whether a given consumer is entitled to receive a particular event or subset of its fields. In advanced deployments, this can include dynamic field-level filtering, so that a single published event can safely be delivered to different consumers with different levels of detail.
Crucially, event-driven interoperability is only clinically valuable if someone, somewhere, actually acts on the event. That means frontline applications — virtual ward dashboards, bed management tools, shared care records, rapid response tasking systems, digital front doors — must be capable of subscribing to the event streams and incorporating them into their UX and workflow. Sometimes this involves extending existing systems so that they can consume events directly. Sometimes it means introducing lightweight, purpose-built micro front-ends that sit between the event bus and the workforce, e.g. a community falls response team’s task list that automatically populates from “999 call triaged” and “ED attendance avoided” events. The key is that the event is not the end product. The event is the raw material for clinical and operational action.
Patterns that consistently work in production healthcare environments include the following:
These patterns, applied thoughtfully, move digital health from a world of retrospective reporting to one of continuous, data-driven coordination.
The strategic benefits of implementing an event-driven architecture in digital health are wide-ranging and, increasingly, measurable. The most obvious benefit is timeliness. Care teams receive information when it is still actionable. A community frailty team can pick up a complex discharge within minutes of it being confirmed, rather than discovering it at the end of the day via a faxed discharge summary. Medicines safety teams can be alerted to high-risk prescribing changes immediately, closing the loop with primary care before harm occurs. Virtual wards monitoring long-term conditions can escalate deteriorations to urgent care rapidly, preventing avoidable hospital admissions and supporting system flow. Timely data is safer data.
A second benefit is resilience. In traditional point-to-point or hub-and-spoke integration patterns, every new connection increases the blast radius of change. If System A changes its schema, every consumer potentially breaks. In a well-governed event-driven model, producers publish to stable, versioned topics with clear contracts. Consumers choose when to migrate to new versions. This creates loose coupling between systems and suppliers, which is attractive for commissioners and CIOs who are wary of vendor lock-in. It means that an ICS or trust can add, replace or retire digital components without rebuilding the whole house.
A third benefit is automation. When clinically safe and properly governed, events can trigger workflows without manual intervention. That might mean automatically creating a community follow-up task when a patient is discharged on new high-risk medication, pre-populating the relevant context into the task so the clinician does not have to chase information. It might mean automatically updating system-wide bed state dashboards from admission and discharge events, rather than asking bed managers to ring round every ward. Or it might mean triggering patient-facing messaging (for example, advice, check-ins or safety-netting) in response to specific events, such as a new diagnosis or the issue of rescue medication. The opportunity here is not to “remove humans” but to remove friction, duplication and delay, so clinical staff can spend their time on the patients who most need them.
Cost efficiency is often underestimated. Integration teams in health systems currently spend a large proportion of their time building and maintaining bespoke point-to-point feeds and fixing brittle polling jobs. Over years, this becomes a drag on innovation because teams are stuck keeping the plumbing alive instead of enabling new models of care. An event-driven approach, once embedded, becomes reusable infrastructure. New use cases become about defining new event consumers rather than negotiating, designing, testing and deploying a brand-new interface every time. This reuse compounds over time and releases internal teams to focus on higher-value clinical and operational problems.
However, there are pitfalls — and they are not trivial. A common failure mode is to treat the event bus as “yet another integration engine”, simply mirroring existing HL7 feeds into topics with no thought to semantics, governance or consumer design. That usually results in noisy, low-signal streams that frontline teams ignore. Another mistake is underestimating data governance. Publishing sensitive clinical events into a broadly accessible bus without strict access control, redaction and consent logic is not acceptable in health and care and will (rightly) face regulatory and public scrutiny. Similarly, ignoring clinical safety and assuming that “if the message was published, the job is done” is dangerous. In health, missed events can cause harm, and duplicate or out-of-context events can create alert fatigue or lead to inappropriate action. Safety cases, hazard logs and end-to-end monitoring should be treated as mandatory, not optional.
Organisational readiness can also be a blocker. Event-driven interoperability exposes process gaps very quickly. For example, if you start publishing “discharge ready” events to community services, you may discover that those services are not actually resourced to pick up referrals in near real time. If you start pushing high-risk prescribing alerts to primary care, you may find that GPs cannot safely act without key context not yet included in the payload. Technology alone does not solve this; pathway redesign and workforce planning must travel alongside the architecture.
With those caveats in mind, several design principles help future-proof an event-driven interoperability strategy in digital health:
Taken together, these principles allow health and care systems to move beyond document exchange and batch integration, towards a living, responsive data ecosystem. They enable frontline teams to coordinate around the patient, not around the system boundary. They reduce friction between organisations. They support safer care at home and in the community. And they lay the groundwork for intelligent automation, predictive analytics and proactive population health at regional scale.
In a health and care landscape that is becoming more distributed, more virtual and more collaborative, adopting event-driven architecture is not simply an IT modernisation exercise. It is an operational capability. It is a patient safety capability. It is, increasingly, the foundation for sustainable, real-time interoperability in digital health.
Is your team looking for help with digital health interoperability? Click the button below.
Get in touch