IoT in Healthcare: How Healthcare IoT Systems Work in 2026

A connected glucose sensor is easy to buy. A system that turns its readings into a clinician’s decision, logs every access to that data, and survives an audit is much harder to build. That gap is the whole job. IoT in healthcare is that system: medical devices, wearables and sensors, the networks that carry their data, and the software that stores, analyzes and acts on it. The healthcare subset is often called the Internet of Medical Things, or IoMT.

This guide is written for CTOs, VPs of Engineering and product leaders. It covers how the stack fits together, which devices are already in production, what HIPAA and the FDA require at each layer, and where AI changes the design.

Key Takeaways

• A healthcare IoT system has four layers: devices, connectivity, edge and cloud, and applications. Most failed pilots under-scope the middle two.
• Connectivity is chosen per care setting, not per project. Wearables, home monitors and hospital equipment rarely share one protocol.
• Remote patient monitoring in Medicare grew from about 55,000 enrollees in 2019 to more than 570,000 in 2022, per HHS OIG.
• HIPAA does not name an encryption algorithm. FDA rules depend on a device’s intended use, and standalone software is regulated differently from software inside a device.
• Measure outcomes against a baseline you capture before launch. Device counts are not results.

How Healthcare IoT Systems Work: The Four-Layer Stack

Every IoT in healthcare deployment moves data through four layers: the device that measures, the network that carries the reading, the edge and cloud services that process it, and the applications people actually use. Understanding how the layers depend on each other is the difference between a pilot that works on twenty patients and a platform that holds up at thousands of devices.

1. Sensor and Device Layer

This is where data starts. It covers wearables such as the Apple Watch ECG app, continuous glucose monitors, ambient sensors that track movement in a room, and connected hospital equipment such as infusion pumps and ventilators.

Each device has its own sampling rate, power budget, and data-fidelity profile. The Dexcom G7 sends a glucose reading to a paired device every five minutes (Dexcom, 2022). A bedside monitor streams continuous waveforms and stays plugged in. Choices made here constrain everything above them. Get them wrong and no dashboard fixes it.

2. Connectivity Layer

Devices have to move data reliably from a patient’s home, an ambulance or a hospital corridor. Four protocol families cover most healthcare deployments, and each solves a different problem.

Our default guidance is straightforward. Use BLE for patient-facing wearables and NB-IoT for out-of-hospital monitoring. Use Wi-Fi 6 inside facilities where power and bandwidth are not constrained, and LoRaWAN for campus asset tracking. One protocol for everything is the usual mistake.

“Most connectivity mistakes surface months later, in the integration budget. A team picks one protocol for every device, then discovers home monitors drop readings and hospital gateways can’t keep up. Choose the protocol per care setting first, then design the data pipeline around it.”
— Linh Pham, Senior Solution Architect at Saigon Technology

3. Edge and Cloud Layer

Some processing has to happen close to the device. Latency decides. An arrhythmia alert can’t wait on a cloud round trip over a patchy home connection, so an edge gateway handles preprocessing, buffers readings during network dropouts, and runs time-sensitive inference.

“Anything that decides whether a nurse gets paged belongs at the edge. The cloud is where you store, analyze and audit readings; the gateway is where you act on them. Mixing the two roles is how alert delays reach production.”
— Linh Pham, Senior Solution Architect at Saigon Technology

From the edge, data flows to the cloud. AWS IoT Core, Azure IoT Hub and the Google Cloud Healthcare API are the common starting points. In the cloud, readings land in structured stores, are normalized to standards such as HL7 FHIR, and feed analytics and ML pipelines. For hospitals still on legacy on-premise data platforms, this layer is often a healthcare cloud migration project in its own right before any device work can start.

4. Application Layer

This is what people see: clinician dashboards, patient mobile apps, alerting and escalation rules, EHR integrations with Epic or Oracle Health (formerly Cerner), and, more and more, assistants that summarize overnight readings for the morning round. This is where IoT in healthcare turns device data into clinical value, and it is where user-experience discipline matters most. An alert nobody trusts gets muted.

IoT vs IoMT: Where Medical Rules Begin

Most IoT in healthcare discussions use the two terms interchangeably, but they are not the same. General IoT covers any connected device, from thermostats to industrial sensors. IoMT is the subset used in patient care, clinical operations or medical research. The distinction matters because medical devices handle protected health information and can affect patient safety, so the rules around them are heavier at every stage from design to update.

IoT vs. IoMT compared

8 IoT Devices in Healthcare Already in Production

These IoT devices in healthcare are deployed today. Each entry names a real product or system category and, where a primary source exists, a verifiable fact about it. Together they show how far IoT in healthcare now reaches, from a patient’s kitchen to the operating room.

1. Remote Patient Monitoring (RPM)

Continuous glucose monitors and connected blood-pressure cuffs send readings from a patient’s home to a clinician portal. Medicare use has grown fast: about 55,000 enrollees received remote patient monitoring in 2019, and slightly more than 570,000 in 2022, with Medicare payments rising from $15 million to more than $300 million over the same period (HHS OIG, OEI-02-23-00260, September 2024). RPM is the most common starting point for a first IoMT product, and remote patient monitoring software is one of our healthcare practice areas.

2. Wearable ECG in Clinical Use

The FDA granted De Novo classification to the Apple Watch ECG app in 2018 as over-the-counter electrocardiograph software that can indicate atrial fibrillation or sinus rhythm (FDA, DEN180044). The output is intended for informational use and is not a substitute for clinical evaluation by a qualified professional.

3. Smart Inhalers and Connected Drug Delivery

Connected inhaler sensors, such as those from Propeller Health, record when and where a rescue or controller inhaler is used. The adherence data flows to physicians, who can step in before an asthma or COPD exacerbation.

4. Hospital Asset and Staff Tracking (RTLS)

Real-time location systems, or RTLS, use BLE beacons or RFID tags to track infusion pumps, wheelchairs and other mobile equipment. The operational case is time: nurses spend less of a shift searching for equipment and more of it with patients.

5. Connected Imaging and Diagnostic Equipment

Modern MRI, CT and ultrasound machines report utilization, uptime and maintenance signals to manufacturer clouds, where the service team sees a failing component long before a radiographer does. Predictive maintenance catches failing components before an unplanned outage, and in an imaging department less downtime means more patients seen.

6. Ambient Clinical Intelligence

Ambient systems use room microphones and AI to capture the physician-patient conversation and draft a structured clinical note. In March 2025 Microsoft combined DAX ambient listening with Dragon Medical One dictation in Microsoft Dragon Copilot (Microsoft, 2025). The category sits where IoT meets generative AI.

7. Smart Pills and Ingestible Sensors

In November 2017 the FDA approved Abilify MyCite, aripiprazole tablets with an embedded sensor that tracks drug ingestion (FDA approval letter, NDA 207202). A sensor in the pill signals a wearable patch, the patch passes the record to a mobile app, and patients can share it with caregivers and physicians through a web portal. The category is small, but it shows how far connected sensing now reaches into pharma.

8. Connected Ambulances and Pre-Hospital IoT

Modern ambulances can stream 12-lead ECGs, vital signs and video to the receiving hospital, so the emergency department can prepare the team, the room and the equipment before the patient arrives, which matters most in time-critical stroke and cardiac protocols. Minutes count.

For the mobile side of these systems, see our healthcare mobile app development practice. Our HealthTech case study covers a multi-tenant SaaS EHR platform, the clinical system that device data ultimately has to reach.

What Healthcare IoT Delivers, and How to Measure It

The value of IoT in healthcare shows up in three places: clinical outcomes, operational capacity and cost. The evidence is real, but it attaches to how a program is run, not to the hardware alone. Two published findings make the point from opposite directions. Programs, not devices, produce outcomes.

The upside first. A prospective study across five hospitals monitored 590,736 patients with the TREWS early-warning system. Among patients with sepsis, those whose alert a provider confirmed within three hours had an 18.7% adjusted relative reduction in in-hospital mortality compared with patients whose alert was not confirmed in time (Adams et al., Nature Medicine, 2022). The benefit tracked clinician response to the alert. The algorithm alone did not produce it.

Now the warning. In Medicare, about 43% of enrollees who received remote patient monitoring in 2022 did not receive all three RPM components, and around 244,000 lacked a record for at least one (HHS OIG, 2024). A device that transmits readings without clinical follow-up is data collection, not care. Effective RPM depends on both reliable data and the clinical process that turns it into patient management.

That is why published ROI ranges travel badly between organizations. Before launch, pick the metric each application is meant to move and record its current value:

Outcomes to measure by application

For budgeting the build itself, our healthcare software development cost guide covers the main drivers.

Security and Compliance by Layer

Compliance for IoT in healthcare is a stack of overlapping rules for data, software and hardware, and each one attaches to a different layer of the system. Most projects underestimate this work because they treat it as a single checklist owned by one team. Each layer has its own owner.

HIPAA and HITECH (Data Layer)

The HIPAA Security Rule governs how protected health information moves through and is stored by connected systems. A vendor that handles PHI on a covered entity’s behalf needs a Business Associate Agreement, so cloud services must be BAA-eligible. The rule does not name an algorithm or a TLS version. Encryption at rest and in transit is an addressable implementation specification (45 CFR 164.312), which means you implement it or document why an equivalent safeguard is reasonable. In practice most teams choose AES-256 at rest, a current TLS version in transit, audit logging of every PHI access, and role-based access at each layer. We cover these patterns in the HIPAA-compliant app development guide.

FDA: SaMD and Software in a Medical Device (Software Layer)

The FDA defines SaMD as software intended for medical purposes that is not part of a hardware medical device (FDA). Software integral to or controlling a medical device may instead be regulated as part of that device. Intended use and software function determine the applicable FDA requirements, which may include design controls, validation, and post-market requirements. 21 CFR Part 11 covers electronic records and signatures used in regulated processes.

IEC 62304 (Software Lifecycle)

IEC 62304 is the international standard for the medical device software lifecycle. It sets requirements for planning, requirements analysis, design, implementation, integration, testing, release and maintenance. Software is classed by the harm a failure could cause, and Class C, where failure could lead to death or serious injury, carries the strictest obligations. Any team building software for an FDA-cleared or CE-marked device should work under IEC 62304 discipline from the first sprint.

IEC 60601 (Electrical Safety)

For devices that touch the patient or connect to hospital electrical systems, IEC 60601-1 covers electrical safety and IEC 60601-1-2 covers electromagnetic compatibility. The standard lives in the hardware world, but it still shapes firmware and connectivity choices, especially how a device behaves under fault conditions.

Device-Level Security Controls

Beyond the regulations, connected medical devices need engineering controls of their own.

Saigon Technology holds ISO 27001 certification, and NDAs are standard on our healthcare engagements. For deeper security architecture, see our healthcare data security guide.

AI and IoT Applications in Healthcare for 2026

IoT generates the data and AI extracts the value, which is why the two are converging faster than either changed alone. Four IoT applications in healthcare now pair devices with AI in production.

AI at the Edge

These are the IoT applications in healthcare where latency decides the architecture. Latency-sensitive inference runs on the device or gateway rather than in the cloud. Arrhythmia detection on a wearable, fall detection on an ambient sensor and image triage on a portable ultrasound all need an answer in milliseconds. Current edge accelerators make on-device inference practical for models that once needed a data center.

Prediction on Device Data Streams

Models running on continuous vitals can flag deterioration that intermittent checks miss. The TREWS study above is the strongest published example. Its lesson for builders is that the alert pathway, meaning who is paged, how fast, and what they confirm, carries as much weight as model accuracy. Chronic-disease models apply the same idea to months of home-monitoring data, looking for the slow drift in weight, blood pressure or activity that tends to show up before a patient decompensates and lands back in hospital.

Language Models Grounded in Sensor Data

Large language models paired with device data can now draft summaries of overnight monitoring, flag anomalies in patient-reported symptoms, and answer clinician questions grounded in a patient’s actual readings. The engineering load is heavy: retrieval over medical data, guardrails, and clinical validation before anyone relies on the output.

Generative AI for Patient Communication

Monitoring data combined with generative AI can produce patient education, weekly progress summaries and clinician-reviewed care-plan updates. Writing personalized messages at scale gets much cheaper, and the clinician-review step keeps accountability where it belongs.

Our AI-powered healthcare showcase at DX Summit 2025 covered several of these patterns. For conversational AI in clinical settings, see our healthcare chatbot development guide.

Challenges of Implementing Healthcare IoT

Healthcare IoT projects fail more often for organizational reasons than technical ones, but five technical problems account for most of the rework.

Device Fragmentation and Interoperability

No two hospitals run the same device fleet. HL7 FHIR helps at the data-integration layer, while device-level protocols remain a patchwork, so a real deployment needs an integration layer that abstracts device differences. We see the same pattern in IoT in transportation and logistics. The safety stakes make it more expensive to get wrong in healthcare.

Data Volume and Quality Management

Continuous waveform data grows quickly. Storage is the easy part. Storing all of it is expensive, and discarding it closes off future analytics. Quality is the harder problem: sensor artifacts, patients who stop wearing a device, and calibration drift all produce readings that need cleaning before they are useful.

“Teams budget for the devices and the dashboard, then under-scope the layer in between. Buffering during dropouts, normalizing readings to FHIR and logging every PHI access is where a pilot either becomes a platform or stalls before it scales.”
— Linh Pham, Senior Solution Architect at Saigon Technology

Legacy EHR Integration

Epic and Oracle Health both expose APIs, but integration remains meaningfully harder than connecting modern SaaS tools. Plan for it. Budget for interface testing, vendor review cycles and the clinical sign-off on where device data appears in the chart.

Regulatory Complexity Across Jurisdictions

A device cleared in the U.S. is not automatically approved in the EU (MDR), Japan (PMDA), Australia (TGA) or the UK (MHRA). Each regime has its own submission, testing and post-market surveillance rules, so multi-market products multiply the compliance workload.

Talent Scarcity

Teams that combine device integration, cloud engineering, AI/ML and healthcare compliance are rare. Few vendors cover all four. Saigon Technology’s healthcare work sits at the software, cloud and integration layers, and our 400+ engineers have staffed 85+ offshore dedicated teams for companies that cannot build this mix in-house.

The Future of IoT in Healthcare

Five shifts are shaping where IoT in healthcare goes next. Each one changes a design decision you would make today.

1. Private 5G in hospitals. Dedicated cellular networks give critical clinical devices more predictable reliability and security than shared Wi-Fi, and hospitals are moving them from evaluation toward production.
2. Digital twins of patients and facilities. Models of individual patients, fed by device data, support surgical planning and chronic-disease management. Facility twins help optimize patient flow and resource allocation.
3. Federated learning across health systems. With federated learning, models train across several hospitals without moving PHI between them, which opens up large-scale AI training within privacy rules.
4. Ambient, passive sensing. Sensors built into walls, floors and ceilings replace wearables for some uses. This matters most in care for older adults and behavioral health, where getting patients to wear a device can be a real barrier.
5. Regulation built for change. The FDA’s final guidance on a Predetermined Change Control Plan lets AI-enabled device software describe planned model updates up front (FDA). The EU AI Act (Regulation (EU) 2024/1689) adds its own obligations for high-risk AI, including medical uses. Teams that build for continuous validation will move faster than those retrofitting compliance later.

Building Healthcare IoT Systems With Saigon Technology

The question for most organizations is no longer whether to invest in IoT in healthcare but how to build systems that scale, comply and show measurable results without collapsing under their own complexity. The teams doing this well design for all four layers from day one, build compliance into the SDLC instead of adding it before launch, and plan the AI and IoT work together.

Saigon Technology has spent 14+ years building software for regulated industries, with 850+ projects delivered for 300+ clients. We are ISO 9001 and ISO 27001 certified, a Microsoft Solutions Partner, and ranked #1 on The Manifest’s Top 100 Enterprise App Developers in Vietnam. Our healthcare work includes AxiaGram, a HIPAA-compliant telemedicine platform for U.S. physicians that handles 6M+ medical records and cut development time by 40%.

Our published rate is $22–$46/hr, with regulated healthcare work toward the upper end of that band.

If you are scoping a healthcare IoT project, our healthcare software engineering practice is a good place to start.

Frequently Asked Questions

How much does it cost to build a healthcare IoT solution?

Cost depends mostly on four things: the number of device types you integrate, the regulatory class of the software, how deeply it connects to the EHR, and whether AI features need clinical validation. A single-device RPM app with a cloud backend sits at the low end. An FDA-regulated SaMD program with several device families sits at the top. Saigon Technology’s published engineering rate is $22–$46 per hour depending on seniority mix. See our healthcare software development cost guide for the full breakdown.

How is IoT data in healthcare kept HIPAA compliant?

Through administrative, physical and technical safeguards under the HIPAA Security Rule: Business Associate Agreements with every vendor that handles PHI, BAA-eligible cloud services, audit logging of PHI access, role-based access, and encryption in transit and at rest. HIPAA treats encryption as addressable and names no algorithm; most teams use AES-256 and a current TLS version. Device-level controls such as secure boot, signed firmware updates and Zero Trust segmentation complete the picture.

What are examples of IoT devices in healthcare?

Common IoT devices in healthcare include continuous glucose monitors such as the Dexcom G7, wearable ECGs such as the Apple Watch ECG app and AliveCor KardiaMobile, connected inhalers, hospital asset-tracking tags using BLE or RFID, connected imaging equipment, ambient clinical documentation systems such as Microsoft Dragon Copilot, ingestible sensors such as Abilify MyCite, and connected ambulance systems that stream vitals to the receiving hospital.

What does IoT mean in healthcare?

IoT in healthcare means using internet-connected devices, sensors and software to collect health data and support clinical, operational and administrative decisions. The healthcare-specific subset is called the Internet of Medical Things (IoMT), and it carries stricter rules than consumer IoT around data protection (HIPAA), software lifecycle (IEC 62304) and device safety (IEC 60601).