Integration
Works with the EHR you already run
EDFlow runs on the HL7 v2 feeds every hospital already has. Your integration engine turns admission, order and result-status messages into a small, signed event feed inside your network, so only the minimum needed ever leaves the hospital. FHIR R4 is supported, and a staff console covers every step when there is no feed.
At a glance
HL7 v2 first
Admission, order and result-status messages you already produce, copied by your engine. No vendor marketplace listing needed to start.
Minimized at the source
The engine drops every field the contract doesn't name. We also reject payloads that carry result values, notes or health card numbers.
Signed and idempotent
HMAC-SHA256 signatures, a 5-minute replay window, idempotent event ids and safe out-of-order delivery.
Manual fallback
The staff console drives every state through the same pipeline: live on day one, and still working when a feed drops.
How the feed works
The main feed is HL7 v2 through the hospital's integration engine. Admission (ADT), order and result-status messages are real time, every major EHR produces them, and the hospital already owns and runs the interfaces. The engine translates them, inside the hospital network, into a small vocabulary of 23 normalized event types, signs them and sends them to EDFlow over HTTPS.
| Path | When to use it | Data minimization |
|---|---|---|
| Normalized events (preferred) | The engine maps HL7 v2 or FHIR to events itself | Best: only named fields leave the hospital |
| FHIR adapter | The site runs a FHIR relay or prefers FHIR resources | Good: mapped at once, raw resources never stored |
| HL7 v2 adapter | Transitional: sandbox or early pilot | Weakest: full messages cross the network, parsed in memory and never stored |
| Staff console | Always available; the only path without a feed | Staff enter only what the screen asks for |
Principles your interface team will recognize
- Outbound only. The engine connects out on port 443 with TLS 1.2 or later. No inbound firewall rule.
- Signed. Each batch carries an HMAC-SHA256 signature over the timestamp, a delivery id and the body, with per-source keys that rotate with an overlap.
- Replay-safe. Timestamps must be within 5 minutes, and a delivery id can't be reused inside that window.
- Idempotent and order-tolerant. Every event states the current state of its subject with a stable id, so retries, duplicates and out-of-order delivery are safe.
- Honest when quiet. A heartbeat every minute and a roster every 15 minutes let the system notice a silent feed and close visits whose departure message was lost.
From EHR events to patient stages
Stages are derived from events, never guessed. A patient's visit moves to "Seen by a doctor" when the EHR records the assessment, to "Tests under way" when an order is placed, and to "Results are back, waiting to see your care team" when every counted result is final. If the evidence isn't there, the stage doesn't move.
By EHR and standard
Choose your EHR or standard for the details your interface analysts will want: the messages, the fields and the caveats.
- Epic: HL7 v2 through Bridges, FHIR R4 for enrichment, SMART launch.
- Oracle Health Millennium: outbound HL7 v2, FHIR R4 CareTeam and optional Communication write-back.
- HL7 v2: the triggers, status tables and the reference engine channel.
- FHIR R4: the resources we map, Subscriptions and why FHIR is not the census feed.
Technical documentation
- Event contractThe normalized event contract: envelope, the 23 event types, prohibited fields, idempotency and ordering.
- Engine configurationStore-and-forward configuration for Mirth Connect, Rhapsody, Cloverleaf and other engines, with signing snippets.
- Go-liveConformance checklist, the shadow run and its 98% agreement gate, cut-over and monitoring.
Frequently asked questions
Do we need to open firewall ports?
No. The hospital's integration engine opens an outbound HTTPS connection on port 443 with TLS 1.2 or later. No firewall port is opened into the hospital, and the engine acknowledges the EHR as usual, so an outage on our side never blocks the hospital's own feeds.
What data leaves the hospital?
The minimum needed to show the visit: arrival, triage and location changes, the care team's names and roles, order existence and status, consult and admission status, and department codes. Never result values, abnormal flags, notes, diagnoses, health card numbers, addresses or phone numbers. Identifiers are stored only as keyed hashes.
What happens if the feed goes down?
Staff drive every state from the staff console, through the same pipeline as EHR events. Patients see "updates may be delayed" when a feed goes quiet, never an old state presented as current.
Do you support EHRs other than Epic and Oracle Health?
Yes. The same normalized contract works for any EHR whose engine can send HL7 v2 or FHIR R4, including MEDITECH Expanse. Each site only needs its own mapping profile for locations, tests and roles.
Keep reading
- IntegrationHL7 v2 integration: ADT, orders and result status for the EDHow EDFlow maps HL7 v2 ADT, ORM/OML and ORU messages to real-time emergency department events: triggers, OBR-25 result-status mapping, the reference integration engine channel and signing, with OBX values never read.
- TrustSecurity and privacy: PHIPA, residency and controlsHow EDFlow protects patient privacy in the emergency department: PHIPA roles, minimum-necessary data, Canadian data residency, keyed-hash identifiers, audit logging, staff MFA, penetration testing and responsible disclosure.
- 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.