Healthcare is where IoT’s promise and its constraints meet most sharply. A sensor that measures glucose continuously and warns before a dangerous low can change a patient’s life. The same sensor, if it misreads, loses connection at the wrong moment, or leaks its data, can harm the person wearing it. Every design decision carries both sides.
Medical IoT, sometimes called the Internet of Medical Things, covers connected devices that touch patient care: wearables and implants, home monitoring kits, hospital equipment, and the infrastructure that tracks all of it. This guide explains the main categories, how remote patient monitoring is built, and the regulatory, safety and privacy requirements that make healthcare IoT different from a fitness tracker.
Three categories of healthcare IoT
Patient-facing devices. Continuous glucose monitors, connected blood pressure cuffs, pulse oximeters, ECG patches, smart inhalers, insulin pumps and cardiac implants with wireless telemetry. These measure the body and report to a phone, a hub or a clinic. Some only observe; some, like an insulin pump driven by a glucose sensor, act on the body, which places them in the strictest regulatory classes.
Clinical environment devices. Infusion pumps, ventilators, patient monitors and imaging equipment that already contain computers and increasingly connect to hospital networks for alarms, central monitoring and electronic health record integration. Most of these are legacy equipment with long service lives and limited update paths, which is a security problem the sector is still working through.
Operational IoT. Asset tracking of wheelchairs, pumps and beds with BLE or RFID tags, cold chain monitoring of vaccines and blood products, hand hygiene compliance sensors, and environmental monitoring of operating rooms. This category looks like any other building or logistics deployment and delivers value without touching patient safety classifications.
How remote patient monitoring is built
A typical RPM system has four parts. The device measures: a cuff, a scale, a glucose sensor, a wearable patch. A relay carries the reading: usually the patient’s phone over BLE, sometimes a dedicated cellular hub for patients without a smartphone, where LTE-M is the common choice because it works through walls and does not depend on the patient’s Wi-Fi. A cloud platform stores readings, applies thresholds and trends, and integrates with the clinical record. A care team reviews flagged patients and intervenes.
The design priorities are different from consumer IoT. Readings must be attributable to the right patient with certainty, so device identity and pairing are strict. Missed readings are clinically meaningful, so the system must distinguish “patient did not measure” from “device could not transmit” and surface both. Alerts must reach a human within a defined time, which means escalation paths and acknowledgment, not just a dashboard. And the patient must be able to use the device with no technical help, so onboarding is often done by a nurse and reconnection must be automatic.
Battery life is a clinical variable: a patch that dies in three days is a patch that gets taken off and forgotten. Deep sleep, efficient BLE connection intervals and small payloads are what make a two-week wearable possible.
Regulation: when a device becomes a medical device
The defining question is intended use. A watch that shows heart rate for fitness is a consumer product. The same watch, if it claims to detect atrial fibrillation, is a medical device in most jurisdictions and must be cleared or certified as one. In the U.S. that means the FDA’s device framework; in the EU, the Medical Device Regulation (EU) 2017/745 and CE marking under it. Classification rises with risk: software that only displays data is low class, a pump that doses a drug is high.
Medical device regulation reaches into the software lifecycle. Standards such as IEC 62304 for software processes, ISO 14971 for risk management and IEC 62366-1 for usability define how the software is developed, verified and maintained. Cybersecurity is now an explicit part of premarket submissions: since section 524B of the FD&C Act took effect in March 2023, the FDA requires a software bill of materials, a plan for monitoring and patching vulnerabilities and, under its guidance, threat modeling. In the EU, devices covered by the MDR are excluded from the scope of the Cyber Resilience Act and are instead held to the MDR’s own cybersecurity requirements.
For a product team the consequence is that “ship fast, patch later” does not apply. Every firmware change to a regulated device goes through change control, and a security fix may need its own regulatory assessment. This is why connected medical devices are designed with update mechanisms, rollback and logging from day one.
Privacy and data handling
Health data is the most protected category of personal data almost everywhere. In the U.S. HIPAA governs covered entities and their business associates; in the EU the GDPR treats health data as a special category with stricter conditions. The practical implications for an IoT design:
- Minimize what is collected and what leaves the device. A glucose sensor needs to send glucose values, not location.
- Encrypt in transit and at rest; end-to-end encryption between device and clinical platform prevents the relay phone or hub from reading the data.
- Separate identity from measurements in storage, so a breach of the telemetry store does not expose who the readings belong to.
- Define data retention, deletion and patient access processes up front.
- Keep data in the required jurisdiction; data sovereignty rules apply to health data strictly.
Consumer wellness devices that sit outside medical regulation are not outside privacy law, and their data has been subpoenaed, sold and breached. A product that collects health-adjacent data should behave as if it were regulated even when it is not.
Security on the hospital network
Hospitals run thousands of connected devices from hundreds of vendors, many on old operating systems that cannot be patched because the vendor’s certification covers a specific software image. The defensive answer is network segmentation: medical devices live in isolated zones, with monitoring of their traffic and tight control over what can reach them. Asset inventories, ideally automated, let security teams know what is on the network. Vendors are increasingly asked for a manufacturer disclosure statement describing a device’s security features, and for a published vulnerability disclosure process.
Where the value is clear
Chronic disease management shows the strongest results: continuous glucose monitoring for diabetes, remote monitoring of heart failure patients to catch fluid buildup early, home blood pressure monitoring with clinician review. Post-surgical monitoring shortens hospital stays by sending patients home with sensors. In the hospital itself, asset tracking returns value quickly by reducing time spent hunting for equipment and reducing over-purchasing. Cold chain monitoring of vaccines and blood prevents losses that are both expensive and dangerous.
What has proven harder is the general-purpose “smart hospital”: many pilots, less sustained adoption, usually because the workflow of the clinicians was not redesigned around the new data. As in industry, the technology is rarely the blocker.
Where to go next
- Bluetooth Low Energy for IoT covers the radio most patient-facing devices use.
- IoT security fundamentals and Device identity, certificates and PKI for IoT cover the controls regulators now expect.
- The IoT data pipeline explains the platform side of remote monitoring.
Topics: healthcare, medical IoT, remote patient monitoring, wearables, IoMT