Device-to-EHR data integration
This is where a device reading either becomes trustworthy clinical data or becomes noise. This page explains the integration layer — the engines and middleware in between, how device values are mapped to LOINC codes and UCUM units, how data is validated before it is stored, and how to keep clinicians from being buried under it.
The layer between the device and the chart
Why integration is its own discipline
Devices and electronic health records rarely speak the same dialect natively. A monitor emits a proprietary or HL7 v2 stream; the EHR expects values mapped to its own flowsheets, coded and time-aligned. Bridging that gap is the job of an integration engine — sometimes called an interface engine or a vendor-neutral gateway — which captures device output, transforms it, and delivers it where it belongs.
The principle that keeps this safe is conservative: it is better to reject a value than to store a wrong one. A reading that cannot be matched to a patient, mapped to a code, or validated against a known unit should be held back and flagged — never silently filed. That discipline is what lets a clinician trust the number on the screen.
What the integration engine actually does
Every device-to-EHR path performs the same core transformations, regardless of vendor.
1. Capture the stream
A gateway receives the device's real-time output — often an HL7 v2 ORU R01 message or a FHIR Observation — without changing its meaning.
2. Match patient and encounter
The reading is associated with the correct patient and visit, attaching the encounter keys the EHR needs to file it against the right record.
3. Map the code
The device's vendor or IEEE 11073 term is converted to the EHR's expected concept, typically a LOINC code, so a systolic value always lands in the systolic field.
4. Validate the unit
A UCUM check confirms and, where needed, converts the unit. If the unit is unknown or implausible, the system rejects the value rather than passing a bad one through.
5. Align time and file
Timestamps are aligned to the institutional clock and the validated observation is written to the correct flowsheet — and, where appropriate, made available to the exchange.
LOINC and UCUM: the meaning and the measure
Two standards do the quiet, essential work of making device data consistent. LOINC answers "what is this observation?" — assigning a universal code so that a heart rate from one device and a heart rate from another are recognisably the same thing. UCUM answers "in what units?" — giving an unambiguous, machine-checkable representation of the measure, so a value in one unit can be validated and converted reliably.
The gap worth knowing about: many bedside monitors and infusion devices produce signals that LOINC does not yet cover. For those, IEEE 11073 device nomenclature supplies standardised codes. A robust integration uses LOINC where it exists, falls back to IEEE 11073 where it doesn't, and validates every unit with UCUM before anything is stored.
Avoiding alarm and data overload
Connected devices can produce more data than any clinician can read. Continuous monitors and a growing fleet of RPM devices generate a high volume of readings, and if every one of them raises an alert, the alerts stop meaning anything. Designing the integration is therefore as much about filtering as it is about capturing.
The neutral, well-established practice is to define which readings warrant attention, set thresholds with clinical input, suppress duplicates, and present trends rather than every individual point. The aim is a worklist a clinician can actually act on — not a firehose. This is a governance question as much as a technical one, and it belongs in the integration design from the start.
Frequently asked questions
01What is an integration engine?
It is the middleware that sits between devices and the EHR. It captures device output, matches it to the right patient, maps codes and units, validates the data, and delivers it into the record. Interface engine, integration engine and vendor-neutral gateway are largely interchangeable terms for this role.
02Why map to LOINC and UCUM rather than store the device's own format?
Because consistency is what makes data shareable and analysable. LOINC gives every observation a universal code and UCUM gives every value an unambiguous unit, so data from different devices and systems can be compared, trended and exchanged. Where LOINC lacks a code, IEEE 11073 nomenclature is used.
03What happens to a reading the system can't validate?
A well-designed integration rejects or quarantines it and flags it for review rather than filing a value it cannot trust. Storing a bad reading silently is the worse outcome, because a clinician may act on it.
Have an integration question for the council?
AzHeC convenes Arizona's providers, vendors and agencies around device interoperability on a neutral, standards-first basis. Get in touch with a question or to take part.