A bedside monitor, a ventilator and an infusion pump each produce clinically useful numbers every few seconds, and nurses still copy many of them into the EHR by hand. Medical device integration replaces that transcription with a data path from the device to the chart. The path is well standardized, yet most projects still lose months to details at the message level.
This guide is for device makers, hospital integration teams and interface engineers. It walks the path from bedside device to EHR flowsheet the way the IHE Patient Care Device (PCD) domain defines it, explains the PCD-01 message and its IEEE 11073 coding, and covers patient binding, validation and testing, which is where these projects usually stall.
What is medtech devices integration?
Connecting devices to an EHR?
Agnotic builds device-to-EHR interfaces for hospitals and medtech companies, from gateway output and interface engine routes to flowsheet filing.
Medtech devices integration is the engineering that moves measurements from hospital devices, such as patient monitors, ventilators and infusion pumps, into the EHR as discrete, time-stamped observations linked to the right patient. In most hospitals it runs through a device gateway and an interface engine using the IHE PCD Device Enterprise Communication profile over HL7 v2.
The aim is not to stream every second of data into the chart. It is to give clinicians accurate values at the documentation intervals they need, with a clear record of which device produced them and who validated them.
What does the IHE PCD DEC profile define?
The IHE PCD Device Enterprise Communication (DEC) profile defines how patient care device data reaches enterprise applications in one consistent form. IHE's overview says DEC maps device data from proprietary syntax and semantics into a single representation, time-stamped with a consistent enterprise time, with options that let applications filter for the data they want.
- Device Observation Reporter: The actor that sends data, usually a gateway or the device vendor's central system.
- Device Observation Consumer: The actor that receives data, such as an interface engine, a clinical data repository or the EHR.
- PCD-01 transaction: Communicate PCD Data, sent from the reporter to the consumer.
- Filtering: Options that let a consumer subscribe to the parameters and patients it needs instead of everything.
Other PCD profiles sit around DEC and cover alarm communication and infusion pumps, which raise their own safety questions. Start with DEC for periodic vital signs and add the others once the basic path is reliable.
How does data move from bedside device to flowsheet?
Data moves through four hops: the device, a gateway that speaks the device's protocol, an interface engine that routes and transforms messages, and the EHR, which holds values for a nurse to validate before they file to the flowsheet.
- 1. Bedside device: The monitor or pump produces measurements in its vendor protocol, over a serial link, the network or a vendor central station.
- 2. Gateway: Device integration software collects the data, converts it to PCD-01 HL7 v2 messages and adds device and patient identifiers.
- 3. Interface engine: Receives messages over the hospital's HL7 transport, filters, maps codes where needed, and routes to the EHR and any other consumers.
- 4. EHR: Receives the observations into a holding area, where a nurse reviews and accepts them into the flowsheet.
For Epic, the open.epic catalog lists an Incoming Device Data interface that receives discrete measurements from patient monitoring and documentation devices. The values file to the application where a user can validate them and add them to the chart, and for surgical procedures the interface can be set to validate and file automatically. Epic notes the interface is usually used with device aggregators and not for consumer or home monitoring.
What is inside a PCD-01 message?
A PCD-01 message is an HL7 v2 ORU^R01 observation result that carries device data as a series of OBX segments. IHE's PCD Technical Framework Volume 2 bases it on HL7 version 2.6 chapter 7 and maps the IEEE 11073 device information model into those segments.
- MSH: The message header, where MSH-21 carries the IHE message profile identifier for DEC.
- PID and PV1: The patient and visit, which must match the EHR's identifiers for the data to file.
- OBR: The observation request that groups the results in the message.
- OBX-3: The observation identifier, coded with ISO/IEEE 11073-10101 nomenclature, the standard vocabulary for device parameters.
- OBX-4: The containment position, a dotted path that says which device, channel and metric the value belongs to.
- OBX-17: The observation method, where the IEEE 11073 metric access code distinguishes periodic from episodic data.
The containment tree matters more than it first appears. A monitor with two invasive pressure channels sends the same kind of measurement twice, and only the OBX-4 path says which is the arterial line and which is central venous pressure. Interface code that ignores containment eventually files a value to the wrong row.
How is each reading bound to the right patient?
Each reading is bound to a patient by associating the device with the patient's encounter before data flows, and by checking that association on every message. A value from the wrong patient in the chart is a safety event, not a data quality issue.
- Location-based binding: The device's bed location is mapped to the patient assigned to that bed by ADT, which fails when patients move before the device is reassigned.
- Explicit association: A nurse scans the patient's wristband and the device, creating a device-to-patient link in the EHR or the gateway.
- EHR-driven association: Epic's catalog lists an Outgoing Device Association Interface that uses the IHE PCD profile to associate a device record with a patient.
- Release on discharge or transfer: The association ends when the patient leaves, so the next patient's data cannot attach to the old record.
Design the unhappy paths first. What happens to data that arrives with no association, or with an association to a patient who has just been transferred? The safe answer is to hold it, flag it to the unit and never file it automatically.
Why should device data be validated before filing?
Device data should be validated before filing because raw device values include artifacts: a pulse oximeter reading during movement, a blood pressure taken while a cuff was being adjusted, a pressure line zeroed at the wrong height. The nurse's review is the clinical check that turns a device value into documentation.
Validation also defines responsibility. The chart records that a named clinician accepted the value at a stated time, which is what the record needs for care and for legal purposes. Automatic filing without review is reserved for settings such as anesthesia, where the record is designed around continuous capture.
- Sampling interval: Send values at the documentation frequency the unit uses, such as hourly in a step-down unit, plus any value the nurse requests.
- Clear provenance: The flowsheet shows that a value came from a device and which one.
- Easy rejection: Nurses can reject an artifact with one action, and the rejection is logged.
How should a device integration be tested?
A device integration should be tested from the real device to the real flowsheet row, in a test environment that mirrors production codes and units. Message-level tests alone miss mapping and display problems that clinicians will see immediately.
- Parameter map: For every device model, list each parameter, its IEEE 11073 code, unit, the EHR flowsheet row and the expected display.
- Containment cases: Test multi-channel devices, such as two pressure lines and multiple temperature probes.
- Association cases: Admit, transfer, swap devices, discharge and a device left attached to an empty bed.
- Failure cases: Gateway restart, network loss and engine queue backlogs, checking that delayed data keeps its original timestamp.
- Clinical sign-off: Nurses from the target unit validate values on the flowsheet during a supervised trial.
Who owns what in a device integration project?
A device integration crosses four teams, and each owns a piece that the others cannot fix. Naming those owners at the start prevents the most common delay, which is a defect that sits between two teams for weeks.
- Biomedical engineering: Device inventory, firmware versions, network configuration and the device-to-bed map.
- Device or gateway vendor: PCD-01 output, IEEE 11073 codes, timestamps and the gateway's own monitoring.
- Interface team: Engine routes, code and unit maps, transport, queues and alerting when messages stop.
- Nursing informatics: Flowsheet rows, documentation intervals, validation workflow and training for each unit.
Operations need the same clarity after go-live. When a unit reports that values stopped arriving, the support runbook should say who checks the device, the gateway, the engine and the EHR, in that order, and how long each step should take before it is escalated.
Where do device integration projects stall?
- Code mismatches: The gateway sends vendor codes or older nomenclature that the EHR's mapping does not recognize.
- Unit surprises: Temperatures in Celsius against a Fahrenheit flowsheet row, or pressures in kilopascals.
- Time drift: Device clocks differ from the enterprise time, so values file to the wrong hour.
- Bed map gaps: Location-based binding breaks because the bed map is not maintained when rooms change.
- Too much data: Second-by-second values flood the engine and the validation screen.
Each of these is cheaper to fix in design than after go-live. A parameter map agreed by nursing informatics, biomedical engineering and the interface team before the first message is sent is the single most useful artifact in a device project.
Rollout order helps too. Go live on one unit with one device model, watch rejection rates and missed values for a few weeks, then add units in waves. A rising rejection rate on a unit usually points to a mapping or binding problem rather than to the nurses.
How Agnotic can help
Agnotic Technologies builds device integrations for hospitals and medtech companies. We configure gateway output to IHE PCD DEC, build interface engine routes and code maps, connect device association to ADT and the EHR, and test every parameter from device to flowsheet with the clinical team.
For device makers, Agnotic builds the PCD-01 output, the IEEE 11073 parameter tables and the documentation hospitals ask for during integration projects.
Plan your device to EHR path
Explore our EHR integration services, or browse the wearables and devices hub.
Related reading on Agnotic
Read about IoMT estates, medical device standards, HL7 orders and results, device software testing and wearable technology in care.
