Smart & connected medical devices
Infusion pumps, bedside monitors, ventilators and connected wearables now produce a near-continuous stream of clinical data. This page explains how those devices expose their readings, the standards that name and carry the data, and the integration patterns that move a value from device to record automatically.
What "connected" actually means
From a measurement to a message
A modern medical device does more than display a number. To be "connected" it must represent each measurement digitally, name it unambiguously, and emit it over a network in a structure another system can parse. The difference between a device that shows a heart rate and one that integrates is entirely about that structured output.
Three layers do the work. First, a nomenclature says what was measured — that this value is a systolic pressure, not a diastolic one. Second, a message or resource format carries the value, its units, a timestamp and a device identifier. Third, a connectivity pathway physically moves it. Get all three right and a reading can flow from the bedside into the chart with no one re-typing it — which is both faster and far less error-prone than manual entry.
The standards that carry device data
Connected devices rarely rely on a single standard. Each layer below solves a different part of the problem, and they are designed to work together rather than compete.
HL7 v2 device messages
The workhorse of acute-care device data. The HL7 v2 ORU (observation result) message carries device readings into clinical systems; IHE's Patient Care Device profiles add the context needed to file them correctly.
Read the primerIEEE 11073
The ISO/IEEE 11073 family standardises device communication and, critically, a nomenclature — coded terms naming each parameter. It covers acute-care devices and personal health devices alike, and complements HL7 rather than replacing it.
Standards work areaFHIR
The modern, API-based approach. FHIR represents a device reading as an Observation resource linked to a Device, exchanged over web APIs — increasingly the path for newer and home-based equipment.
Read the primerLOINC & UCUM
Coding the meaning and the units. LOINC identifies what the observation is; UCUM specifies its unit precisely. Many bedside devices lack LOINC coverage, so IEEE 11073 nomenclature codes fill the gap.
How mapping worksAn endpoint on the network is an endpoint to protect
The moment a device joins a network it becomes part of the organisation's attack surface. Connected devices vary widely in how current their software is and how they authenticate, which makes endpoint security a first-class concern rather than an afterthought.
Sound practice treats device traffic like any other clinical data flow: encrypted in transit, segmented onto controlled network zones, authenticated at the integration boundary, and logged so that every reading has a verifiable origin. None of this is device-specific advice — it is the same privacy-and-security discipline that governs the rest of health data exchange, applied to a class of endpoints that historically received less of it.
Frequently asked questions
01Why are there both HL7 v2 and FHIR for device data?
HL7 v2 is mature and deeply embedded in hospital systems, so most acute-care device integration still runs on it via the ORU message and IHE Patient Care Device profiles. FHIR is the newer API-based standard, well suited to home and wearable devices. They are complementary; many organisations run both.
02What does IEEE 11073 add that HL7 doesn't?
IEEE 11073 provides a standardised nomenclature — agreed codes naming each measured parameter — and device communication profiles. Many bedside monitors and infusion devices have signals that LOINC does not yet cover, and IEEE 11073 nomenclature supplies standardised codes for them. It sits alongside HL7 and FHIR rather than replacing either.
03Does AzHeC recommend specific connected devices?
No. This is educational, vendor-neutral content about how device data integrates with the record and the exchange. It does not evaluate or recommend any product or manufacturer.
Continue through the Connected Devices work area
Next, see how a captured reading is mapped, validated and filed in the electronic health record — and how to keep clinicians from drowning in data.