Integration · HL7 v2
HL7 v2 to live patient updates, without reading a single result
EDFlow turns the ADT, order and result-status messages your integration engine already routes into a normalized, signed event feed. The mapping is published, the result status tables are explicit, and result values are never read.
At a glance
ADT triggers
A04 and A01 arrival, A08 updates, A02 transfers, A03 departure, A11 and A13 reversals, A40 merges.
Orders and result status
ORM, OMG, OML and OMI new orders and status changes; ORU status from OBR-25 and OBR-22.
Reference channel
A reference channel, synthetic fixtures and a conformance script that replays your test traffic.
Triggers
| Message | Events |
|---|---|
| ADT^A04 / A01 (emergency visit) | Arrival; triage if a CTAS observation is present; care team if PV1-7 or ROL is present |
| ADT^A08 update | Location, care team, triage and patient updates, each only when its segment is present |
| ADT^A02 transfer | Location change; departure (admitted) when the new location is an inpatient unit |
| ADT^A03 discharge | Disposition and departure |
| ADT^A11 / A13 | Cancelled visit or left without being seen; discharge reversal |
| ORM^O01, OMG^O19, OML^O21, OMI^O23 | Order placed; status changes; cancellations; consults and nothing-by-mouth diet orders |
| ORU^R01 | Order status from OBR-25 and OBR-22 only; OBX segments ignored |
| SIU^S12 to S15 | Scheduled time of a linked order |
Result-status mapping
| OBR-25 | Meaning | Status shown |
|---|---|---|
| O | Order received | Ordered |
| S | Scheduled | Scheduled |
| I | Specimen received, incomplete | In the lab / scan in progress |
| R | Stored, not verified | In the lab / being read |
| A, P | Some or preliminary results | Being finalized |
| F | Final | Back |
| C | Corrected | Back (corrected) |
| X | Cancelled | Cancelled |
"Back" means a result exists. Patients never see what it says, and a result being back is never styled as good news: the care team explains results in person.
The reference engine channel
- Source: copy (tee) the existing ADT, order and result feeds rather than building new EHR interfaces.
- Filter: keep emergency visits (PV1-2 = E) and the department's locations; drop everything else at the engine.
- Transform: build normalized events, drop every field the contract doesn't name, compute stable event ids.
- Destination: an HTTP sender that signs each batch, with a retrying queue per feed so order is kept.
- Scheduled: a heartbeat every 60 seconds and the department roster every 15 minutes; a backfill of the current census at go-live.
The mappings follow the HL7 Version 2 to FHIR implementation guide concept maps where they apply, so HL7 v2 and FHIR sites get the same meaning.[1]
Technical documentation
- HL7 v2 adapterThe HL7 v2 adapter: supported versions and triggers per vendor, field maps and status tables.
- Engine configurationStore-and-forward configuration for Mirth Connect, Rhapsody, Cloverleaf and other engines, with signing snippets.
- Event contractThe normalized event contract: envelope, the 23 event types, prohibited fields, idempotency and ordering.
Frequently asked questions
Do you accept MLLP directly?
No. Hospitals keep MLLP inside their own network. The engine receives the messages, maps and signs them, and sends events over HTTPS. The engine acknowledges the EHR as usual; our destination is an asynchronous queue.
Do you read OBX result values?
No. OBX segments are ignored and never parsed for values. Only the order's status (OBR-25 or ORC-5) and its time are used.
Keep reading
- IntegrationFHIR R4 integration for emergency department statusHow EDFlow uses FHIR R4 for emergency department status: Encounter, ServiceRequest, Specimen, ImagingStudy and DiagnosticReport status mappings, Subscriptions Backport, SMART backend services and why HL7 v2 remains the census feed.
- IntegrationEpic integration for real-time ED patient statusHow EDFlow integrates with Epic for real-time emergency department status: HL7 v2 ADT, orders and result status through Bridges and the integration engine, FHIR R4 enrichment, SMART on FHIR launch and what to confirm with your Epic team.
- ArticleIntegrating with Epic and Oracle Health for real-time emergency department statusA practical guide to real-time emergency department status from Epic and Oracle Health: HL7 v2 through the integration engine, where FHIR fits, minimization and the shadow run.
Talk to us
See it with your own emergency department in mind
We'll walk through the patient, family and staff views with synthetic data, then map them to your EHR, your workflows and what you want a pilot to prove.
Sources
- [1]HL7 Version 2 to FHIR Implementation Guide (opens in a new tab) · HL7 International