Epic device integration: HL7 ORU vs FHIR Observation, which path should readings take?
Bedside and home device readings reach an EHR in one of two shapes: an HL7 v2 ORU^R01 results message, usually through an interface engine, or a FHIR Observation written through an API. Which works depends first on what the receiving EHR accepts at that site, then on how each shape carries the patient, the device, the code and the acknowledgment.
How does a device reading map to ORU^R01 and to FHIR Observation?
Quick answer
For Epic device integration, HL7 ORU vs FHIR Observation is decided by the inbound path the site has enabled: ORU^R01 through an interface engine is the long-standing route for bedside device feeds, while FHIR Observation write suits apps where the site supports it. Agnotic Technologies maps every reading field to both shapes before choosing.
| Criterion | HL7 ORU^R01 | FHIR Observation |
|---|---|---|
| Patient identifier | PID-3 patient identifier list | Observation.subject referencing a Patient |
| Visit or encounter | PV1, such as PV1-3 assigned location and PV1-19 visit number | Observation.encounter referencing an Encounter |
| Device identity | OBX-18 equipment instance identifier | Observation.device referencing a Device or DeviceMetric |
| Parameter code | OBX-3, with ISO/IEEE 11073-10101 (MDC) codes in IHE PCD-01 | Observation.code; the vital signs profile requires LOINC codes for core vitals |
| Value | OBX-5, with the value type in OBX-2, such as NM for numeric | Observation.valueQuantity |
| Unit | OBX-6, coded as the receiving interface specifies | valueQuantity unit and code; the vital signs profile uses UCUM |
| Time of measurement | OBX-14 observation date and time, with OBR-7 for the report | Observation.effectiveDateTime or effectivePeriod |
| Result status | OBX-11, such as R for not verified or F for final | Observation.status, such as preliminary, final or amended |
| Acknowledgment | ACK over MLLP with MSA-1 of AA, AE or AR | HTTP status code, with an OperationOutcome describing errors |
| Grouping | One OBR per report and one OBX per parameter | One Observation per parameter, or components for multi-part values such as blood pressure |
What they are
What is HL7 ORU^R01
ORU^R01 is the HL7 v2 unsolicited observation result message. For device data it carries the patient in PID, the visit in PV1, a report header in OBR and one OBX segment per measured parameter. IHE's PCD-01 transaction profiles it for patient care devices, using ISO/IEEE 11073-10101 nomenclature.
What is FHIR Observation
Observation is the FHIR resource for measurements and simple assertions about a patient. A reading carries its code, value, unit, time and status, and references the patient, the encounter and the Device or DeviceMetric that produced it. The vital signs profile fixes the codes and units for common vitals.
Key differences
What does IHE PCD-01 standardize?
The IHE Devices Technical Framework, Volume 2, revision 10.0, defines transaction PCD-01, Communicate PCD Data, as an ORU^R01 message sent from a Device Observation Reporter to a Device Observation Consumer. It references HL7 v2.6 Chapter 7 and the ISO/IEEE 11073-10101 nomenclature, and puts the unique identifier of the particular device instance in OBX-18. If the device gateway speaks PCD-01, much of the mapping work is already defined.
Why do MDC codes and LOINC both appear?
Device profiles code parameters with the ISO/IEEE 11073-10101 nomenclature because that is how devices describe what they measure. The FHIR R4 vital signs profile requires each vital signs Observation to carry a status, a vital-signs category, a LOINC code, a patient, a time and a numeric value with a UCUM unit. A gateway that produces both shapes needs a maintained MDC to LOINC and unit mapping table, tested per device model.
How do acknowledgments and retries differ?
An HL7 v2 sender waits for an ACK on the same MLLP connection and resends when none arrives, which can create duplicates if the first message was in fact filed. A FHIR client gets an HTTP status and, on error, an OperationOutcome. For both, make writes idempotent: key each reading on device instance, parameter and measurement time, and on FHIR use an Observation identifier with a conditional create so a resend does not file twice.
When does a reading count as charted?
Most bedside workflows file device readings as unvalidated until a nurse reviews and accepts them in the flowsheet. The message shape must carry that state: OBX-11 status in HL7 v2, Observation.status in FHIR. Sending device values as final when they have not been reviewed is a clinical safety issue, not just a data issue.
Where does DeviceMetric fit in FHIR?
The FHIR R4 DeviceMetric resource describes the static properties of a measurement, setting or calculation produced by a medical device, and can also describe metric status, calibration and measurement mode. Observation.device may reference either a Device or a DeviceMetric, so decide early whether your consumers need the channel-level detail or only the device.
Is the gateway itself a medical device?
FDA's guidance on medical device data systems states that software functions solely intended to transfer, store, convert formats or display medical device data and results, including waveforms and signals, are not devices. A gateway that only moves and reformats readings sits there. Functions that analyze readings or raise clinical alarms need a separate look.
When to use each
When to use HL7 v2 ORU^R01
- The site already receives bedside device data through an interface engine.
- Readings must file into flowsheets through the EHR's existing results interface.
- Device gateways from the monitor or pump vendor already emit PCD-01 messages.
- High message volume from many beds, delivered over MLLP inside the network.
When to use FHIR Observation
- A patient app or home device platform sends readings over an API.
- The site has enabled a FHIR endpoint that accepts Observation writes from your app.
- Apps, analytics or a data platform need the same readings as resources.
- You want HTTP request and response semantics instead of MLLP sessions.
Where do device readings go wrong between the device and the chart?
1. Readings for an unassociated device. The monitor is not linked to a patient or bed when the reading arrives. Fix: hold readings in the gateway until ADT and bed association confirm the patient, and alert on unassociated devices.
2. Unit mismatch. A device sends one unit and the flowsheet row expects another. Fix: convert in the gateway against a tested unit table and reject unknown units instead of passing them through.
3. Duplicate resends. A missing ACK or a timeout causes the same reading to file twice. Fix: idempotent keys on device instance, parameter and time.
4. Unvalidated values filed as charted. Fix: map the device result status to the EHR's unvalidated state and leave acceptance to the nurse.
5. Clock drift. Device time and gateway time differ, so readings land in the wrong flowsheet column. Fix: synchronize device and gateway clocks and record both times.
6. Codes that are not mapped. A new device model sends a parameter the mapping table does not know. Fix: route unmapped codes to a work queue rather than dropping them.
7. One gateway, two outputs. The pattern that avoids most of this sends ORU^R01 to the EHR's results interface and FHIR Observation to apps and analytics from the same normalized reading, so corrections flow to both.
Which sources does this comparison rely on?
- IHE Devices Technical Framework, Volume 2, Rev. 10.0: PCD-01 Communicate PCD Data (ihe.net)
- HL7 FHIR R4: Observation resource (hl7.org)
- HL7 FHIR R4: Vital Signs profile (hl7.org)
- HL7 FHIR R4: DeviceMetric resource (hl7.org)
- FDA guidance: Medical Device Data Systems, Medical Image Storage Devices and Medical Image Communications Devices (fda.gov)