IoMT, the Internet of Medical Things, is the population of networked medical devices in and around a health system: bedside monitors, infusion pumps, ventilators, imaging modalities, lab analyzers and the home devices patients take with them. Each one produces data someone needs and an attack surface someone has to manage.
This post is for hospital CTOs, clinical engineering leads and digital health founders whose products depend on device data. It covers how device data reaches the chart, how readings stay attached to the right patient, which security duties fall on makers and on hospitals, and where IoMT programs usually break down.
What is IoMT?
Connecting medical devices to clinical systems?
Agnotic builds device data pipelines, EHR integrations and the clinical apps that use connected device data, as the engineering team for health systems and device makers.
IoMT, the Internet of Medical Things, is the set of medical devices that connect to a network and exchange data with clinical systems. It spans hospital equipment such as patient monitors and infusion pumps as well as home devices such as blood pressure cuffs. A device counts as IoMT when its data leaves it and drives care.
For a health system, IoMT is less a technology choice than an operating problem: hundreds or thousands of devices from many makers, each with its own interface, firmware and support life, all expected to send accurate data to the right chart.
Which devices make up a hospital's IoMT estate?
A hospital typically runs several distinct device groups, and each one connects in a different way. Treating them as one category is the first planning mistake.
- Physiologic monitors: Bedside and central station monitors that produce vital signs and waveforms, usually through the monitor maker's own gateway.
- Infusion pumps: Smart pumps with drug libraries, which can report pump status and, with pump to EHR integration, receive programming from a verified order.
- Respiratory devices: Ventilators and related equipment, often older and harder to connect, with settings that clinicians still chart by hand in many units.
- Imaging and lab equipment: Modalities and analyzers that already speak DICOM or lab interface protocols to the PACS and laboratory system rather than to the EHR directly.
- Location and asset tags: Real-time location systems that track equipment, which feed asset management and sometimes staff and patient workflows.
- Home and remote devices: Cellular or Bluetooth devices used in remote monitoring and hospital-at-home programs, which reach the health system through a vendor cloud.
Each group has a different owner. Clinical engineering usually owns the bedside fleet, IT owns the network and integration engine, and a service line or vendor often owns the home devices. An IoMT plan has to name who owns each group's data and security.
How does bedside device data reach the EHR?
Bedside data usually flows from the device to a gateway, then through an integration engine, and into the EHR flowsheet as HL7 v2 results. Very few hospital devices write to the EHR directly.
The common standard for that path is IHE's Device Enterprise Communication (DEC) profile from the Patient Care Device domain. It sends device observations as HL7 v2 ORU^R01 messages, coded with the IEEE 11073 nomenclature, from a Device Observation Reporter to a Device Observation Consumer such as the EHR or a clinical data repository.
The gateway does more than forward data. It maps device codes to the terms the EHR flowsheet expects, attaches the patient identifier, normalizes units and time stamps, and decides how often to report. A monitor can produce readings every few seconds; the chart usually needs a validated value at a set interval.
The EHR should then hold device values as unverified until a nurse accepts them. That step matters clinically, because an artifact reading from a loose lead should not become a charted vital sign. The integration has to support the review queue, not bypass it.
Clock synchronization is a quiet requirement. If the device, gateway and EHR disagree on the time, readings land in the wrong flowsheet column, and medication and vital sign timelines stop lining up.
Alarms and waveforms are a separate stream. Alarm notification to nurse phones and waveform storage for review usually run through their own middleware, so the integration plan should state which system owns each stream and which one the EHR receives.
Linking each reading to the right patient
Patient association is the step where device integration can fail unsafely. A reading with the wrong patient attached is worse than no reading at all.
In hospitals, association usually comes from one of three methods: scanning the patient wristband and the device barcode, assigning the device to a bed that the ADT feed maps to a patient, or selecting the patient on the device itself. Bed-based association is convenient but breaks when a patient moves and the device stays.
The integration should end an association automatically on discharge or transfer messages from the ADT feed, and should stop sending data when the association is uncertain. Silent carry-over of the previous patient is the failure to design out.
Home devices raise the same problem over a longer time span. A blood pressure cuff returned by one patient and issued to another needs an explicit unassign and reassign step, with dates, so readings from the gap are held for review instead of filed to either chart.
Which security rules apply to connected medical devices?
Makers and hospitals carry different duties. Makers answer to FDA for what they put on the market, and hospitals answer for how devices run on their networks.
On the maker side, Section 524B of the Federal Food, Drug, and Cosmetic Act requires premarket submissions for cyber devices to include a software bill of materials, a plan to monitor and address postmarket vulnerabilities, and processes that provide reasonable assurance the device is cybersecure. FDA's premarket cybersecurity guidance describes what those submissions should contain.
On the hospital side, devices fall inside the HIPAA Security Rule's risk analysis when they hold or transmit ePHI. In practice, that means an inventory, a security review before purchase, network controls, and a process for acting on vulnerability notices.
The pre-purchase review usually starts from the maker's MDS2 form, the Manufacturer Disclosure Statement for Medical Device Security, which states what the device stores, how it authenticates and how it is patched. The SBOM a maker now supplies to FDA is also worth requesting, because it lets the hospital match the device against new vulnerability advisories, including CISA's ICS medical advisories.
Many devices cannot be patched quickly, because a change can need maker validation. Segmentation is the usual answer: put each device group on its own network segment and allow only the connections it needs, such as monitor to gateway and gateway to integration engine.
Where IoMT programs break down
Many of these failures are operational rather than technical. The list below covers the failure points to design against, with the control that prevents each one.
- No complete inventory: Devices bought by departments never reach the central list. Control: discover devices on the network and reconcile them against purchasing and clinical engineering records.
- Wrong patient association: A device keeps sending after the patient moves. Control: end associations on ADT transfer and discharge events and stop data when association is uncertain.
- Unreviewed data in the chart: Device values file as final without nurse validation. Control: keep the EHR review queue and alert when queues back up.
- Alert overload: Every out-of-range reading becomes a notification. Control: route only rules agreed with clinicians, and send trends to a review list instead.
- Unsupported devices: Devices outlive the maker's security support. Control: track end-of-support dates in the inventory and plan isolation or replacement before they arrive.
- Vendor cloud lock-in: Home device data is only visible in the maker's portal. Control: require a documented data export or API in the contract before deployment.
- Flat networks: Devices share a segment with workstations. Control: segment by device group and allow only the flows each group needs.
What should a health system decide before buying or building?
A handful of decisions set the cost and risk of every later device project. Make them once, as policy, rather than device by device.
- 1. Integration path: Decide whether device data goes through each maker's gateway, a vendor-neutral device integration platform, or a gateway your team builds and maintains.
- 2. Data scope: Decide which values go to the EHR flowsheet, which go to a separate repository for analytics or research, and which are never stored.
- 3. Association method: Pick barcode, bed-based or device-side association for each unit, and write the rule for ending an association.
- 4. Security baseline: Set the minimum a new device must meet, including MDS2 review, SBOM availability, supported authentication and a segment it will join.
- 5. Ownership: Name who owns the inventory, the integration engine channels, vulnerability response and each home monitoring program.
- 6. Exit terms: Require data export and a decommissioning process, including wiping stored patient data, in every device and platform contract.
Digital health companies selling into hospitals face the same list from the other side. A product that already answers these questions, with a clear integration path, a complete MDS2 and an SBOM, gets through hospital security review faster.
How Agnotic can help
Device projects stall at the seams between the device, the gateway, the integration engine and the EHR. Agnotic Technologies builds those seams for health systems and device makers: gateways and HL7 v2 or FHIR interfaces that carry device observations, patient association logic tied to ADT events, and the review queues and dashboards clinicians use.
For device makers, Agnotic builds the cloud and integration side of the product, including data export APIs and the documentation hospital security teams ask for during review.
Plan your IoMT project with Agnotic
Explore our healthcare software development work and IoMT integration page, or browse more articles in our Wearables hub.
Related reading on Agnotic
Continue with wearable technology in healthcare, the future of healthcare, IoT development, medical devices and RPM alert fatigue.
