Connected devices in hospitals, clinics, and patients' homes generate a constant stream of health and operational data. But IoT in healthcare is useful only when that data reaches a workflow someone can act on. A sensor that logs temperature in a vaccine refrigerator matters because it triggers an alert before doses spoil. A wearable that tracks heart rate variability matters because a clinician reviews the trend and adjusts a care plan. Without the workflow, the device is just hardware collecting dust and data.
This guide covers what healthcare IoT actually includes, where it creates measurable value, how the architecture works, and what security and build decisions you need to make before committing budget.
What IoT in healthcare actually includes
IoT in healthcare refers to connected sensors, devices, mobile apps, gateways, and backend systems that collect, transmit, and process health or operational data. The term covers a wide range of products and setups:
- IoMT (Internet of Medical Things) is the subset focused on connected medical devices: infusion pumps with network interfaces, continuous glucose monitors, connected pulse oximeters, smart imaging peripherals, and similar equipment that generates clinical data. Many of these are regulated by the FDA or equivalent bodies.
- Operational healthcare IoT includes environmental sensors (temperature, humidity, air quality), asset tracking tags, smart medication cabinets, and facility monitoring systems. These devices support hospital operations without directly measuring patient physiology.
- Consumer and wellness wearables sit at the edge of the definition. Fitness trackers and smartwatches are not medical devices by default, but when their data feeds into a clinical program (such as remote patient monitoring), they become part of a healthcare IoT system.
The distinction matters for compliance. A connected infusion pump that qualifies as a cyber device under FDA guidance has different regulatory obligations than a BLE beacon tracking wheelchairs. Treating every sensor the same way leads to either over-engineering or dangerous gaps.
IoT in healthcare use cases that justify the complexity
Not every connected device earns its integration cost. The use cases below have clear action owners, defined data flows, and proven operational or clinical returns.
- Remote patient monitoring (RPM): Wearables, connected blood pressure cuffs, glucose monitors, and pulse oximeters send data to an EHR, care management platform, or patient app. The main risk is alert fatigue from poorly tuned thresholds.
- Connected hospital devices: Infusion pumps, bedside monitors, ventilators, and smart beds feed EHRs, nurse call systems, or clinical decision support tools. Legacy firmware that cannot be patched is often the hard part.
- Asset and inventory tracking: RFID tags and BLE beacons help locate equipment, specimens, and supplies through ERP, inventory, or RTLS systems. Battery life, read range, and middleware quality decide whether the rollout works.
- Medication adherence and smart dispensing: Smart pill bottles and automated cabinets connect to pharmacy systems, EHRs, or patient apps. Teams need to account for false compliance signals, such as a bottle opening without the patient taking the dose.
- Environmental and facility monitoring: Temperature, humidity, cold chain, room occupancy, and hand hygiene sensors support facilities management and compliance reporting. Sensor drift and calibration planning matter.
- Wearable-driven behavioral health support: Smartwatch signals and patient-reported events can feed a clinical portal, caregiver dashboard, or analytics engine. Signal noise and patient engagement drop-off are the main risks.
RPM deserves a specific note on reimbursement. In the US, CPT codes 99453, 99454, 99457, and 99458 define billing for device setup, data transmission, and clinical time spent reviewing RPM data. These billing rules directly shape product requirements: the device must transmit data at least 16 days per 30-day period for 99454, and clinical staff must spend defined time thresholds for 99457/99458. The ACP billing overview covers the details. If you are building an RPM product, your remote patient monitoring software architecture needs to support these documentation and transmission requirements from day one.
For asset tracking specifically, RFID-based systems handle equipment location, specimen chain-of-custody, and supply replenishment. They overlap with broader IoT infrastructure but have their own read-range, tag-cost, and middleware considerations.
The architecture behind a healthcare IoT system
A production healthcare IoT system has more layers than most teams expect at the start. Here is what each layer does and where the common design decisions sit.
Device and sensor layer
This is the physical hardware: wearables, clinical-grade monitors, environmental sensors, RFID readers, or imaging peripherals. Each device has its own data format, transmission protocol (BLE, Wi-Fi, cellular, LoRa, Zigbee), sampling frequency, and power profile. Device selection should follow the use case, not the other way around.
Edge gateway or mobile app layer
Raw device data rarely goes straight to the cloud. An edge gateway (a local hub, tablet, or on-premise server) or a mobile app aggregates, filters, and forwards data. This layer handles local buffering when connectivity drops, initial data validation, and sometimes lightweight processing like threshold checks.
Ingestion, message broker, and API layer
Data from gateways and apps reaches the backend through MQTT brokers, REST/GraphQL APIs, or managed message queues (SQS, Kafka, Azure Event Hubs). The ingestion layer must handle variable throughput, device authentication, and payload normalization. Event-driven architecture works well here: telemetry arrives as events, gets routed to the right consumers, and triggers downstream processing.
Data storage and normalization
Raw telemetry goes into time-series or object storage. Normalized clinical observations get mapped to standard models. For clinical data exchange, HL7 FHIR provides the resource definitions (Observation, Device, Patient) that make downstream integration with EHRs possible. Not every data point needs FHIR mapping, but anything that enters a clinical record should follow a recognized standard.
Analytics and alerting layer
This is where data becomes actionable. Rules engines evaluate thresholds (blood pressure above 180/120 triggers an urgent alert). ML models can detect patterns (gradual weight gain trend in a heart failure patient). The design question is whether you need real-time streaming analytics, near-real-time alerts (seconds to low minutes), or batch processing (hourly or daily syncs). Most RPM programs work fine with near-real-time. True streaming is worth the cost for ICU monitoring or acute deterioration detection, not for daily weight check-ins.
Integration layer
IoT data needs to reach the systems where clinicians, operators, or patients already work: EHR, care management platforms, CRM, ERP, data warehouses, or patient-facing apps. This layer handles API calls to vendor systems, webhook subscriptions, bulk data exports, and identity/consent checks. Role-based access control determines who sees what.
Admin, observability, and device management
Device fleet management (firmware versions, connectivity status, battery levels), system monitoring (latency, error rates, queue depth), audit logging, and operational dashboards. This layer is easy to defer and expensive to retrofit.
A practical example of this architecture in action: the RAE Health platform combines Garmin SDK wearable data with a Flutter mobile app for patients, a clinical web portal for providers, and a caregiver-facing tool (RAE Connect). The backend runs on Java/Spring Boot with AWS infrastructure (ECS, RDS, Cognito, SQS). The system detects stress and craving events from wearable signals and manual patient input, then surfaces them to care teams through the portal. Over a 24-month-plus engagement, the architecture evolved to handle the reality that useful IoMT products require more than data capture. They need patient UX, clinician workflows, and backend infrastructure that turns signals into decisions.
Security, HIPAA, and FDA planning
Healthcare IoT security is not a single checklist. It is a set of overlapping responsibilities that depend on what your product does and what data it handles.
HIPAA obligations
If your system collects, stores, transmits, or processes protected health information (PHI), HIPAA applies. The practical requirements include:
- Encryption in transit (TLS 1.2+) and at rest (AES-256 or equivalent)
- Access controls with role-based permissions and multi-factor authentication for administrative access
- Audit logs for every access to PHI, with tamper-evident storage
- Business Associate Agreements (BAAs) with every cloud provider, device vendor, or third party that touches PHI
- Breach notification procedures and incident response plans
- Workforce training and operational safeguards
Your cloud architecture for PHI needs to reflect these requirements from the infrastructure layer up.
FDA cyber-device requirements
When your product is a regulated medical device with software and network connectivity, FDA Section 524B requirements apply. These include:
- Threat modeling during design
- A Software Bill of Materials (SBOM) listing all software components, including open-source dependencies
- Secure boot, signed firmware updates, and OTA update capability
- Vulnerability monitoring and coordinated disclosure processes
- Lifecycle cybersecurity planning, not just pre-market testing
Not every healthcare IoT product is FDA-regulated. An environmental monitoring sensor in a pharmacy is not a medical device. A connected pulse oximeter that informs clinical decisions likely is. Classify early and plan accordingly.
Practical device-level controls
Regardless of regulatory classification, connected healthcare devices benefit from:
- Device identity and authentication: Each device gets a unique certificate or token. No shared credentials across a fleet.
- Network segmentation: IoT devices sit on isolated VLANs or subnets, separate from clinical workstations and administrative systems.
- Least privilege: Devices communicate only with the endpoints they need, on the ports they need, using the protocols they need.
- Legacy device management: Many hospital-connected devices run outdated firmware that vendors no longer patch. Risk management for these devices includes network segmentation, traffic monitoring, compensating controls, and replacement planning on a realistic timeline.
- Logging and monitoring: Device behavior baselines help detect anomalies. Unexpected outbound connections, unusual data volumes, or authentication failures should trigger investigation.
Build vs buy: when custom healthcare IoT software makes sense
Buy when the workflow is standard and a vendor platform covers it. Device management platforms (AWS IoT Core, Azure IoT Hub), commodity dashboards for environmental monitoring, and off-the-shelf RPM kits with basic portals all work when your differentiation is not in the software.
Build when:
- Your clinical or operational workflow does not fit a vendor's default configuration, and customization costs approach a custom build anyway
- You need deep integrations with specific EHRs, pharmacy systems, or care management platforms that vendor products do not support natively
- The patient or clinician UX is your product's differentiator, not a commodity feature
- Your analytics, alerting logic, or ML models require control over the data pipeline
- Your business model depends on owning the platform (SaaS, licensing, or data products)
The hybrid approach is common: use managed cloud infrastructure and device SDKs, but build the application layer, integrations, and UX. For teams planning custom healthcare software, the decision often comes down to whether the value you create sits in the device, the data pipeline, or the workflow layer. If it is the workflow layer, that is where custom development investment should concentrate.
A practical implementation roadmap
- Choose the use case and define the action owner. Who acts on the data? A nurse, a pharmacist, a facilities manager, a patient? What decision does the data support? If you cannot name the person and the action, the use case is not ready.
- Select devices and vendors. Evaluate clinical accuracy, certification status, SDK/API availability, battery life, connectivity options, and total cost of ownership including per-device licensing.
- Define the data model and thresholds. Map device outputs to clinical or operational concepts. Set alert thresholds with clinical or operational input, not engineering guesses. Plan for threshold adjustment as real-world data arrives.
- Design the UX for every user role. Patients need simple, accessible mobile experiences. Clinicians need efficient views that fit their existing workflow. Administrators need fleet and compliance dashboards.
- Build integrations and data pipelines. Connect to EHR, care management, pharmacy, or facilities systems. Use FHIR where clinical data exchange is involved. Plan for vendor API rate limits, downtime, and versioning.
- Run security and compliance review. Threat model the full system. Classify regulatory requirements. Test encryption, access controls, audit logging, and incident response. Generate SBOMs. Engage compliance counsel before launch, not after.
- Pilot, measure, and iterate. Deploy with a small cohort. Track device connectivity rates, alert volumes, false positive rates, clinician response times, and patient engagement. Adjust thresholds, UX, and workflows based on real data before scaling.
The first decision in any healthcare IoT initiative is not which device to buy or which cloud to use. It is identifying who will act on the data and what that action looks like. Start there, and the architecture, security model, and build-vs-buy choices follow from a position of clarity rather than speculation.
