Workflow Automation in Healthcare
Event Driven Automation in Healthcare — Part 1: Why Faster Plumbing Isn't the Real Problem
Most NHS Trusts already run event-driven clinical messaging. The problem isn't timing it's that every event travels alone, without context, without transactional integrity, and without structural assurance. Here's what actually needs to change.Medi Harsini
Reading time: ~5-7 minMost NHS Trusts already run event-driven clinical messaging. The problem isn't timing — it's that every event travels alone, without context, without transactional integrity, and without structural assurance. Here's what actually needs to change.
The Integration Problem Nobody Names Correctly
Somewhere in your Trust right now, a scheduled job is sitting idle. It ran at 02:00. The data it needed arrived at 02:07. So the record won't process until tomorrow's run, or until someone notices the gap and triggers it manually.This is a real cost. But it's not the biggest cost of how healthcare integration works today. The bigger problem is what happens when data does arrive on time: it arrives fragmented, without clinical context, without transactional guarantees, and without any structural validation. The ADT message fires. The order message fires separately. The result fires separately. The receiving system stitches them together or tries to and nobody can guarantee the complete clinical picture ever actually assembles.Event driven automation in healthcare is often presented as the solution: stop batching, start reacting. But making fragmented data move faster doesn't fix the fragmentation. It just delivers incomplete pictures more quickly.What Event Driven Automation Actually Means in Healthcare
Strip away the vendor language, and event driven automation is a straightforward concept: instead of running a workflow on a schedule, every hour, every night, or every Monday, you run it the moment something happens.A new staff record lands on the SFTP server. That's an event. A patient demographic update arrives via PDS. That's an event. An ADT message hits the HL7 listener. That's an event.In an event driven model, each of those triggers a workflow immediately. The data moves through transformation, validation, and delivery in seconds rather than sitting in a queue until the next scheduled window.For clinical workflow automation tools, this is a genuine improvement over batch scheduling. But it's an improvement within an architecture that has a deeper limitation one that speed alone cannot address.Why This Pattern Already Exists (and What It Gets Wrong)
Here's the part that rarely gets acknowledged: event driven clinical messaging is not new. Most NHS Trusts have been running it for years.HL7v2 integration engines Mirth, Rhapsody, InterSystems, TIE operate on exactly the pattern described above. An ADT A01 arrives on the HL7 listener. The engine evaluates the message type, routes it to the correct processing branch, transforms the content, and delivers it to the target system. Trigger, route, transform, deliver. This is the established operating model for clinical data exchange across the NHS.What's left to solve isn't when these events fire. It's what they carry when they do.Every HL7v2 message is a self-contained event. An ADT A01 tells you a patient was admitted. A separate ORM message tells you what was ordered. A separate ORU tells you what the results were. Each message travels independently. Each is processed independently. And if one message fails, arrives out of order, or gets lost in transit, the consuming system's picture of the clinical episode is broken with no mechanism to detect or recover from the inconsistency.There is no transactional guarantee across these messages. You cannot say "the admission AND the order AND the result must all succeed or none of them do." Each event is fire-and-forget. The integration engine is left to manage coherence across dozens of independent messages, and in practice, it manages it imperfectly.This is the context fragmentation problem. And it doesn't go away by making the events arrive faster.Where Individual Events Break Down in Practice
The consequences show up in specific, predictable places and they're not primarily about timing.Patient flow and clinical handover. An ADT A01 (admission) arrives and is processed. The associated Encounter details, the admitting Practitioner, the referring Organisation, and the initial ServiceRequest all travel as separate messages or aren't transmitted at all. The receiving system has the admission event but not the clinical context around it. Bed management sees a patient in a bed; the clinical team doesn't see who referred them or what was requested.Staffing and rostering. ESR data feeds workforce systems. When a mid-day change occurs a new starter, a role update, a leaver the data only surfaces when the next file lands. This is a genuine batch-source problem: ESR delivers flat files, typically daily. Event-driven processing can trigger on file arrival rather than on a timer, but the improvement is marginal. The file still arrives once a day. It's important to be honest about where event-driven patterns genuinely help and where the source data is the constraint.Order and result coherence. An ORM fires for a diagnostic order. The ORU fires later with results. If the order message fails and the result succeeds, the lab system shows a result for an order the clinical system never recorded. There's no atomicity no mechanism to say these two events are part of one clinical transaction and must be treated as such.Compliance and audit. DSPT submissions, CQC audit trails, and IG reviews depend on data being both current and complete. When clinical context is reconstructed from dozens of independent events, the completeness question is unanswerable without manual reconciliation. Teams compensate with spreadsheets, workaround processes, and institutional knowledge.The Real Shift: From Events to Bundles
The architectural response to context fragmentation is not faster event processing. It's packaging related data together so that context is preserved at the point of creation, not reconstructed by the consumer.This is what FHIR Bundles are designed to do.Instead of scattering a clinical episode across dozens of independent messages, a FHIR Bundle packages the related resources - Patient, Encounter, Practitioner, Organisation, ServiceRequest, Condition - into a single unit that travels together. The consumer doesn't stitch context together from a stream of events. The producer preserves the context before anything leaves the source system.The Bundle type is the architectural decision that determines how integrity is managed:1. A transaction Bundle tells the receiving server: process all of these entries atomically. If the Patient write succeeds but the Encounter write fails, roll the whole thing back. This is the ACID guarantee that HL7v2 never had.2. A message Bundle is the direct successor to the HL7v2 event model. It's triggered by a clinical event, carries a MessageHeader that plays the same role as the HL7v2 MSH segment, and includes all the resources relevant to that event in a single package. It preserves the event-driven pattern but solves the context fragmentation.3. A collection Bundle is a bag of resources with no processing semantics no transactional guarantee, no event context. It's useful for grouping, but provides none of the integrity benefits. Choosing the wrong Bundle type means losing the very thing the architecture was designed to provide.The integration pattern still follows the same shape: trigger, route, transform, deliver. But what moves through that pattern is fundamentally different.What Changes When Context Travels with the Data
Data integrity becomes enforceable. When a Bundle arrives, the receiving system can validate it against a FHIR profile before accepting it checking that mandatory fields are present, that terminology bindings are correct, that references between resources resolve, and that the structure conforms to an agreed specification. With individual events, validation is limited to checking whether a single message parses correctly. With Bundles validated against profiles, you're checking whether the complete clinical picture is correct.Error handling shifts from message-level to transaction-level. A failed HL7v2 message means one event was lost, and the downstream system may not know its picture is incomplete. A failed transaction Bundle means the entire clinical context was rejected nothing is half written, nothing is inconsistent. The blast radius of a failure is either zero or total, never partial.Terminology becomes governable. Individual HL7v2 events use locally defined code tables. FHIR resources carry explicit terminology bindings: a Condition's clinical code is bound to a specific ValueSet, backed by a CodeSystem, translatable through a ConceptMap. When these resources travel in a Bundle, the terminology travels with them. Validation can confirm that every coded element uses a recognised code from a governed source.Monitoring shifts from "did it arrive?" to "is it conformant?" With event-driven HL7v2, the monitoring question is whether the message was received. With FHIR Bundles validated against profiles, the question becomes whether the data met the agreed structural and terminological standard. That's a more useful question.What This Means in Practice
But there's a nuance that matters: you don't need to Bundle everything. Packaging every resource related to a patient into a single massive payload isn't the answer either it reintroduces the coupling and payload bloat that RESTful resource design was meant to eliminate.The practical architecture is a middle ground: Bundle what's being created together, reference what already exists.In Part 2, we'll walk through exactly how this works - when to use a lean transaction Bundle, when individual resources with references are the better choice, and how Encounter and Composition serve as the architectural anchors for clinical context. With worked examples.Keywords
event driven automation healthcarehealthcare workflow automationclinical workflow automation toolsFHIR BundleHL7 FHIR migration
Ready to fix this in your workflow stack?
Related Blogs
Turn healthcare workflow ideas into production-ready delivery
Whether you're exploring interoperability, workflow automation, HL7, FHIR, ESR, or internal operational delivery, WeHub helps teams design, govern, and run workflows without unnecessary complexity.
- Built for healthcare integration and operations
- Faster delivery with reusable workflow components
- Better governance, visibility, and scale