Trigger Events

Trigger events represent workflow transitions. Message type and trigger event in MSH-9 define contract intent, required segment structure, and downstream behavior.

• ADT: admissions, discharges, transfers, updates, merges.
• ORM/ORR/ORU: order lifecycle and result return.
• SIU: scheduling lifecycle events.
• DFT: charge and financial posting events.

Typical Patient Lifecycle (ADT)

This model treats A40 merge as a patient-identity correction that can interrupt multiple encounter states, rather than as the normal end state of an admission. In production interfaces, A08/A31 updates and A40 merges often occur repeatedly while the encounter remains open.

Patient Admission Workflow

1. Patient registers (often ADT^A04) and demographic context is created.
2. Registration updates are distributed to ancillary systems.
3. Patient is admitted to a unit (ADT^A01).
4. Admission is broadcast to ADT consumers, bed management, and billing.
5. At discharge, ADT^A03 closes encounter state across consumers.

Lab Order Workflow

1. Provider places imaging request.
2. Scheduler creates appointment (SIU^S12).
3. Reschedules emit SIU^S13 updates.
4. Cancellations emit SIU^S15 to all consumers.

DFT events communicate charges and financial transactions to billing and revenue cycle systems.

1. Clinical service is rendered and charge generated.
2. DFT^P03 posts charge to billing and claim preparation systems.
3. Payments and adjustments reconcile against financial transaction identifiers.

Radiology workflows combine HL7 order and result events with DICOM image lifecycle systems for complete clinical context.

HL7 v2.x to DICOM Integration

• HL7 orders (ORM/SIU) synchronize patient and scheduling context into modality workflow.
• DICOM Modality Worklist uses HL7-sourced demographics for acquisition safety.
• Results return in ORU while images persist in PACS/VNA systems.
• Identifier consistency (MRN, accession, placer/filler IDs) is critical for cross-system matching.

When publishing HL7 events to cloud buses, keep clinical semantics intact while adding routing metadata, observability context, and replay safety controls.

View full size

Source: AWS Healthcare Industry Lens interoperability architecturesLast verified: 2026-03-11

This official AWS view is useful because it keeps the HL7 v2 ingest edge separate from the cloud event-routing layer. EventBridge is not a replacement for MLLP framing or HL7 parsing; it becomes valuable after the message has been normalized into routable event metadata.

EventBridge Event Pattern for HL7

Serverless HL7 Processing Architecture

EventBridge Rule Examples

Scenario 1: Emergency Department Visit

1. Patient arrives and is registered (A04).
2. Patient is admitted to ED bed (A01/A08 updates).
3. Labs are ordered (ORM) and results returned (ORU).
4. Patient is discharged or transferred (A03/A02).

Scenario 2: Scheduled Surgery

1. Scheduling emits SIU^S12 appointment creation.
2. Pre-op updates trigger SIU reschedule/cancel events as needed.
3. Admission and perioperative updates use ADT messages.
4. Charges and procedures post with DFT transactions.

Scenario 3: Radiology Workflow

1. Order created (ORM) and appointment scheduled (SIU).
2. Modality workflow executes with DICOM image acquisition.
3. Interpretation is delivered as ORU result event.
4. Billing posts study charges through DFT.

ADT (Admission, Discharge, Transfer) events form the backbone of patient workflow tracking. This comprehensive table covers all common ADT trigger events with their operational impact and typical consumers.

The ORM (Order) to ORU (Result) workflow is the most common bidirectional pattern in healthcare interoperability. Understanding this lifecycle is essential for lab, radiology, and pharmacy integrations.

Complete Order-to-Result Lifecycle

Order Control Codes (ORC-1)

Result Status Codes (OBX-11)

Order Correlation Best Practices

• Preserve placer order number (ORC-2/OBR-2) from EHR through entire lifecycle.
• Capture filler order number (ORC-3/OBR-3) assigned by performing system.
• Use both identifiers for result correlation - never rely on one alone.
• Store order-result linkage in database for audit and reconciliation.
• Handle order cancellations (CA) by marking order as cancelled, not deleting.
• Support result corrections (C status) by versioning results, not overwriting.