Event Driven Automation in Healthcare — Part 2: The Middle Ground Between Events and Bundles

Part 1 made the case that the real integration shift isn't batch-to-event - it's fragmented messages to contextual Bundles. But Bundling everything is its own problem. Here's what actually works: lean transaction Bundles, persistent resources, and two architectural anchors that hold clinical context together.

Medi Harsini

Reading time: ~6-8 min

The Problem with "Bundle Everything"

In Part 1, we made the case that the real integration shift isn't about making data move faster. It's about making data travel with its clinical context intact - and that FHIR Bundles were designed to solve the context fragmentation problem that HL7v2 event messaging created.But there's a trap at the other end. If the response to "every event travels alone" is "put everything into one massive Bundle," you've traded one problem for another. A transaction Bundle containing Patient, Encounter, Practitioner, Organisation, Location, ServiceRequest, Condition, Consent, and Appointment is a large payload that forces the consumer to accept everything or nothing even when they only need one resource. It couples resources that have completely different lifecycles. A Patient resource might change once a year. An Encounter changes constantly. Resending the Patient every time the Encounter updates is waste.The practical architecture is neither "always individual resources" nor "always Bundle." It's knowing which resources genuinely need to travel together and which already exist and can be referenced.

Part 1 Diagram

HL7v2 Fragmented Events vs FHIR Bundle Evolution

A visual comparison of isolated event messages versus a context-preserving Bundle that carries related resources together.

Diagram comparing fragmented HL7v2 events with a FHIR Bundle that preserves clinical context

The Principle: Bundle What's New, Reference What Exists

The decision rule is straightforward:Bundle resources that are being created or updated as part of the same clinical act, where a partial write would leave the data in an inconsistent state.Reference resources that already exist in the target system and have their own lifecycle stable, persistent, addressable by ID.A Patient was registered last week. They have an ID. They're already in the system. They don't go in your Bundle they go in your Bundle's references: "subject": {"reference": "Patient/123"}.A Practitioner has been on staff for years. Same thing: "participant": [{"individual": {"reference": "Practitioner/456"}}].The Organisation is the hospital. It doesn't change per clinical event. Reference it.What IS being created at the moment of a clinical act the Encounter, the Condition, the ServiceRequest those are the resources that belong in a lean transaction Bundle. Three or four resources, not twelve. Everything else is a pointer to something the system already knows about.The receiving server resolves those references against resources it already holds. If it doesn't hold them, the reference is still valid it's a logical pointer the consumer can follow when it needs the detail. You get referential integrity without payload bloat.

Five Patterns: When to Bundle and When Not To

Here are the common integration scenarios, with a clear decision for each.

1. Inpatient admission — transaction Bundle

What's being created together: Encounter, Condition (reason for admission), ServiceRequest (initial orders).What's referenced: Patient, Practitioner, Organisation, Location.Why Bundle: An Encounter without the Condition is meaningless why is this patient here? A ServiceRequest without the Encounter has no context what episode does this order belong to? These resources are clinically incomplete without each other and must succeed or fail atomically.The Bundle: Three to four resources. Lean. Everything else is a reference to a persistent resource.

2. Diagnostic order with specimen — transaction Bundle

What's being created together: ServiceRequest, Specimen.What's referenced: Patient, Encounter, Practitioner.Why Bundle: A Specimen resource pointing to a ServiceRequest that failed to write is orphaned data. The lab has a sample with no order. These two must be atomic.The Bundle: Two resources. About as lean as it gets.

3. Observation result for an existing order — individual resource

What's being created: A single Observation.What's referenced: Patient, Encounter, ServiceRequest (the original order).Why not Bundle: Everything this Observation relates to already exists. The ServiceRequest was written when the order was placed. The Encounter was written at admission. The Patient has been in the system for days. You're adding one new resource to an established context. A single POST of the Observation resource, with references to the existing ServiceRequest and Encounter, is all that's needed.

4. Patient demographic update — individual resource

What's being updated: Patient.What's referenced: Nothing - this is a standalone update.Why not Bundle: The Patient resource has its own lifecycle. A name change, an address update, a new contact number these are independent of any clinical event. A simple PUT to the Patient resource is correct. Never Bundle this with clinical resources their lifecycles are unrelated.

5. Discharge summary — document Bundle

What's being assembled: A Composition resource (the document structure) plus the clinical resources it references: Conditions, MedicationStatements, Procedures, CarePlan.What's referenced: Patient, Encounter, Practitioner.Why this type: A discharge summary is a curated snapshot, not a live transaction. The Composition acts as a table of contents "this document has these sections, each section references these resources." The document Bundle type wraps the Composition and all its referenced resources into an immutable package. Once assembled, it doesn't change. It's the FHIR equivalent of a sealed PDF.

The Context Anchor: Encounter

Encounter is the single most important resource for maintaining clinical coherence in FHIR, and it's the one most teams underestimate.An Encounter says: "this clinical interaction happened, involving this patient, this practitioner, at this location, for this reason, during this time period." Almost every clinical resource created during a care episode references back to an Encounter.Here's how it works in practice:1. At the start of the episode, the Encounter is created typically in a lean transaction Bundle alongside the Condition and initial ServiceRequests. This is the anchoring event.2. Once the Encounter exists and has an ID, it becomes the reference point for everything that happens during that episode. Observations, DiagnosticReports, MedicationRequests, Procedures each is created individually, and each carries "encounter": {"reference": "Encounter/789"}.3. The Encounter doesn't travel with each subsequent resource. It doesn't need to. It's already in the target system. Every new resource just points to it.

Part 2 Diagram

Encounter as the Clinical Context Anchor

Once the Encounter exists, later resources keep the episode coherent by referencing it instead of re-sending the full context each time.

Diagram showing Encounter as the anchor resource that later clinical resources reference back to

This is how you maintain clinical coherence without shipping the entire episode in every payload. The Encounter creates the context anchor. Everything else hangs off it by reference. The consuming system can always reconstruct the full episode by querying all resources that reference a given Encounter but it doesn't need to receive them all at once.

The Document Anchor: Composition

Composition serves a different purpose from Encounter, and conflating them is a common mistake.Where Encounter is live, ongoing, and referenced by new resources throughout the care episode, Composition is assembled after the fact. It's a document a curated selection of resources, organised into sections, frozen at a point in time.The classic use is a discharge summary:1. The Composition resource defines the document structure: sections for "Diagnosis," "Medications on Discharge," "Procedures Performed," "Follow-up Plan."2. Each section references the relevant FHIR resources: the Condition resources under "Diagnosis," the MedicationStatement resources under "Medications," the Procedure resources under "Procedures."3. The Composition and all its referenced resources are wrapped in a document Bundle. This Bundle is immutable it's a snapshot of the clinical state at the point of discharge.The distinction matters for integration architecture:

Encounter-anchored workflows are transactional. Data is created and exchanged throughout the episode. The integration pattern is: lean transaction Bundle at episode start, individual resources during the episode, each referencing the Encounter.
Composition-anchored workflows are documentary. Data is assembled at a defined point (discharge, referral, transfer) into a curated document. The integration pattern is: a single document Bundle at the end of the process, containing the Composition and everything it references.

Some workflows need both. A referral involves an Encounter-anchored workflow at the referring organisation (clinical data is created during the episode) and a Composition-anchored document sent to the receiving organisation (the referral letter).

Putting It Together: An Inpatient Admission

Here's how the middle-ground architecture plays out for a single clinical episode, from admission to discharge.

Part 2 Diagram

Inpatient Admission: The Middle Ground Architecture

An admission timeline showing where lean transaction Bundles matter, where references are enough, and when a document Bundle closes the episode.

Inpatient admission timeline diagram showing lean transaction Bundles, individual resources, and a discharge document Bundle

Step 1 - Stable resources already exist. The Patient was registered previously. The admitting Practitioner is on staff. The Organisation and Location (ward, bed) are maintained as part of the hospital's reference data. None of these are created as part of this admission. They're persistent and addressable by ID.Step 2 - Admission (lean transaction Bundle). The Encounter, the admitting Condition, and the initial ServiceRequest are created together in a transaction Bundle. Three resources. The Bundle references the Patient, Practitioner, and Organisation by ID. If any resource in the Bundle fails to write, the entire transaction rolls back. The clinical context is atomic.Step 3 - During the stay (individual resources). As the episode progresses observations recorded, medications administered, procedures performed each is created as an individual resource via a standard REST operation. Each references the Encounter by ID: "encounter": {"reference": "Encounter/789"}. No Bundles needed. The context is maintained through the Encounter reference.Step 4 - Diagnostic orders (lean transaction Bundles). When a diagnostic order is placed, the ServiceRequest and Specimen are created together in a two-resource transaction Bundle. The result (Observation) comes back later as an individual resource referencing the ServiceRequest.Step 5 - Discharge (document Bundle). At discharge, a Composition is assembled: sections for diagnoses, procedures, medications on discharge, follow-up. The Composition references the relevant resources (Conditions, Procedures, MedicationStatements, CarePlan). The Composition and all referenced resources are wrapped in a document Bundle an immutable snapshot of the episode. This is what gets sent to the GP, to the referring clinician, to the patient.The result: atomicity where it matters (admission, orders), lightweight operations everywhere else (observations, updates), and a curated document at the end. No massive payloads. No coupling of resources with different lifecycles. Referential integrity throughout.

How to Start

For teams evaluating the migration from HL7v2 to FHIR, the middle-ground architecture suggests a practical starting sequence:1. Get your stable resources right first. Patient, Practitioner, Organisation, Location, HealthcareService these are the resources everything else references. They need to be persistent, well-maintained, and addressable by ID before you can use them as references in transaction Bundles. If your organisation doesn't have a clean, governed register of its own hospitals, you're not ready for FHIR you have a reference data problem that needs solving first.2. Pick one high-context workflow. Choose an integration where context fragmentation causes real operational pain where multiple HL7v2 messages must be correlated to build a complete picture. Referrals, admissions, or diagnostic order-to-result flows are common starting points.3. Design the lean transaction Bundle for the anchoring event. Identify which resources are being created simultaneously at the start of that workflow. Profile each one cardinality constraints, terminology bindings, mandatory elements. The profile is the contract between producer and consumer.4. Map the episode resources that follow. Identify the resources that will be created individually during the episode (observations, procedures, medications) and ensure each carries the Encounter reference. These don't need Bundles they need well-defined profiles and a clear Encounter anchor.5. Decide whether the workflow ends with a document. If the episode produces a summary (discharge, referral letter, transfer), design the Composition and its document Bundle. If the workflow is purely transactional (order-to-result), there's no Composition needed.6. Validate from day one. Every Bundle and every individual resource should be validated against its profile on arrival. The structural assurance is the entire point. Without it, you've just changed the wire format from pipes-and-hats to JSON and gained nothing.The middle ground isn't a compromise. It's the architecture FHIR was designed for: persistent, addressable resources connected by references, with transactional Bundles used surgically where atomicity genuinely matters, and document Bundles used to seal curated clinical snapshots. It's lighter than "Bundle everything," safer than "reference everything," and the practical path most teams should be building toward.If your Trust is designing the migration from HL7v2 to FHIR and wants help identifying which workflows need transaction Bundles, which need document Bundles, and which are better served by individual resources, WeHub's FHIR architecture team can walk through the design with you.

Keywords

FHIR Bundle healthcare integrationFHIR EncounterFHIR CompositionHL7 to FHIR migrationhealthcare workflow automationFHIR transaction Bundle

Ready to fix this in your workflow stack?

Related Blogs

Why Legacy Integration Engines Cannot Handle Modern Healthcare Workflows

Apr 30, 20268 min

Why Leave Entitlement in NHS ESR Keeps Breaking - and the Healthcare Integration Mistakes Behind It

Apr 28, 20267 min

Event Driven Automation in Healthcare — Part 1: Why Faster Plumbing Isn't the Real Problem

Apr 16, 20267 min

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