Software for Medical Devices & IoT in Healthcare

Key Takeaways:

• Medical device software and healthcare IoT sit at the intersection of clinical technology, regulatory compliance, and connected infrastructure — requiring development teams that understand FDA pathways, HIPAA requirements, and real-time data processing simultaneously.
• The FDA has authorized over 1,250 AI/ML-enabled medical devices. The 2026 CDS Final Guidance reduces oversight for certain low-risk clinical decision support tools. IEC 62304 governs the software development lifecycle for all medical device software.
• Healthcare IoT encompasses wearable patient monitors, connected clinical devices, smart infusion pumps, environmental sensors, and asset tracking systems — each generating continuous data streams that must be ingested, processed, and acted upon in real time.
• Taction builds SaMD applications, device companion apps, IoT data platforms, clinical dashboards, and integration infrastructure that connects medical devices to EHR systems and clinical workflows.

Medical Device Software Landscape

Medical device software falls into two categories, each with different regulatory implications.

Software as a Medical Device (SaMD) — Software intended for medical purposes without being part of a hardware device. Examples include AI-powered diagnostic tools, clinical decision support applications, and digital therapeutics. SaMD is regulated by the FDA based on the significance of the information it provides and the seriousness of the healthcare situation.

Software in a Medical Device (SiMD) — Software that is part of or controls a hardware medical device. Examples include software running an infusion pump, controlling a ventilator, or processing data from an imaging device. SiMD is regulated as part of the hardware device’s overall classification.

Both categories require development under IEC 62304 (software lifecycle standard for medical devices) and compliance with the device’s overall risk classification.

SaMD Development and FDA Pathways

FDA Classification for SaMD

SaMD classification depends on two factors: the significance of the information provided (treat/diagnose, drive clinical management, inform clinical management) and the seriousness of the healthcare situation (critical, serious, non-serious).

Situation Significance	Critical	Serious	Non-Serious
Treat or diagnose	Class III (PMA)	Class III (PMA)	Class II (De Novo/510k)
Drive clinical management	Class III (PMA)	Class II (510k)	Class II (510k)
Inform clinical management	Class II (510k)	Class II (510k)	Class I (exempt/510k)

Most SaMD applications — diagnostic aids, clinical decision support tools with defined scope, risk scoring engines — fall into Class II and are cleared via the 510(k) pathway. The 2026 FDA CDS Final Guidance expands the criteria for CDS software that qualifies as non-device (exempt from FDA review), creating a faster path for tools where the healthcare professional can independently evaluate the AI’s recommendation.

Taction’s FDA-Aware Development Approach

We do not submit regulatory filings on your behalf — that requires a specialized regulatory affairs firm. What we do is build the software and documentation that regulatory submissions require.

Discovery phase: Determine the likely FDA classification. Identify the regulatory pathway (510(k), De Novo, exempt). Design the development process to produce the documentation that pathway requires.

Development under IEC 62304: Requirements traceability from user needs through system requirements through software requirements through test cases. Risk management per ISO 14971 throughout the lifecycle. Design history file maintained in real time — not retroactively compiled.

Validation documentation: Software verification and validation protocols. Test reports with traceability to requirements. Anomaly management and resolution documentation.

Quality management: Development under ISO 13485-aligned quality management system. Design controls, CAPA processes, and change management documented throughout.

For full details on our medical device software approach, see our medical device software development services.

Healthcare IoT Architecture

Healthcare IoT connects medical devices and environmental sensors to clinical systems, enabling continuous data collection, real-time monitoring, and automated clinical workflows.

Device Layer

Medical-grade wearables (blood pressure monitors, glucose meters, pulse oximeters, ECG patches, weight scales), connected clinical devices (smart infusion pumps, ventilators, patient monitors), environmental sensors (temperature monitoring for medication storage, air quality in operating rooms), and asset tracking devices (RTLS tags for equipment, staff, and patients).

Connectivity Layer

Bluetooth Low Energy (BLE) — Short-range, low-power connectivity for wearables pairing with smartphones or gateway devices. Most consumer and clinical wearables use BLE.

Cellular (LTE-M, NB-IoT) — Direct-to-cloud connectivity without requiring a smartphone or WiFi. Critical for RPM deployments serving older patients who may not have smartphones. Our RPM case study used cellular-connected devices to achieve 89% patient compliance.

WiFi — High-bandwidth connectivity for clinical devices within hospital networks. Infusion pumps, patient monitors, and imaging devices typically connect via hospital WiFi infrastructure.

MQTT and AMQP — Lightweight messaging protocols optimized for IoT device communication. MQTT’s publish-subscribe model handles intermittent connectivity and low-bandwidth scenarios common in remote monitoring.

Data Ingestion and Processing Layer

IoT data streams are continuous, high-volume, and time-sensitive. The ingestion layer must handle thousands of data points per second per device, validate and normalize incoming data (unit conversion, calibration adjustment, error detection), buffer data during connectivity interruptions (device-side caching with sync), and route data to the appropriate processing pipeline (real-time alerts vs batch analytics).

Technologies: Apache Kafka or AWS Kinesis for stream processing. Redis for real-time caching and alert queuing. Time-series databases (InfluxDB, TimescaleDB) for efficient storage and retrieval of device data.

Clinical Application Layer

Raw device data becomes clinically useful through applications built on top of the data platform.

Real-time clinical dashboards — Vital signs display, trend visualization, risk stratification, and alert management for clinical teams. See our healthcare data analytics services.

Alert and escalation engines — Configurable thresholds (per-patient, not one-size-fits-all) with ML-driven pattern detection that identifies multi-variable deterioration trends. Escalation workflows that route alerts to the right clinician at the right urgency level.

Patient-facing apps — Guided measurement workflows, personal health trends, medication reminders, and secure messaging with care team.

EHR integration — Device data flowing into the patient’s electronic health record via FHIR Device and Observation resources or HL7v2 ORU messages through Mirth Connect. Clinicians see device data in their normal EHR workflow without switching applications.

Device Data Integration with EHR Systems

Connecting medical devices to EHR systems is where most IoT healthcare projects struggle. The device generates data in its own format. The EHR expects data in HL7v2 or FHIR format. The mapping between the two requires clinical context — what does this device reading mean clinically, and where should it appear in the patient’s chart?

Integration Approaches

FHIR Device and Observation resources — The modern standard for device data integration. Each device reading maps to a FHIR Observation resource linked to a Device resource and a Patient resource. Supported by major EHRs including Epic and Oracle Health.

HL7v2 ORU messages — Legacy approach for feeding device data into EHRs that do not yet support FHIR device resources. Device readings are mapped to OBX segments within ORU messages and routed via Mirth Connect.

Proprietary device APIs — Some device manufacturers provide proprietary cloud APIs (Withings Health Mate API, iHealth API, Biobeat API). Data is pulled from the manufacturer’s cloud and transformed into FHIR or HL7v2 for EHR integration.

IEEE 11073 / Continua — Standards specifically designed for personal health device communication. Maps device data to standardized health observations. Increasingly supported by device manufacturers.

HIPAA Compliance for Device Data

All device data linked to a patient is PHI and must be protected under HIPAA. This includes data in transit (device to gateway, gateway to cloud, cloud to EHR) — encrypted via TLS 1.2+ or device-specific secure protocols, data at rest (time-series databases, data lakes, backup storage) — encrypted via AES-256, access controls — clinical users see only their patients’ device data, and audit logging — every access to device data is logged.

Security Considerations for Medical IoT

Connected medical devices expand the attack surface for healthcare organizations. Device security requires a defense-in-depth approach.

Device authentication — Every device must authenticate before transmitting data. Certificate-based mutual TLS for clinical devices. Token-based authentication for consumer wearables.

Network segmentation — Medical IoT devices should operate on isolated network segments, separated from general hospital IT and patient WiFi networks.

Firmware update management — Secure, authenticated firmware update mechanisms for connected devices. Unsigned firmware updates are a common attack vector.

Data validation — Incoming device data must be validated for format, range, and clinical plausibility. A blood pressure reading of 500/300 is not a data point — it is a device malfunction that should trigger an alert, not a clinical intervention.

Vulnerability monitoring — Connected devices must be included in the organization’s vulnerability management program with regular scanning and patch management.

What We Build for Medical Device and IoT Companies

Solution	Description
SaMD applications	AI-powered diagnostics, clinical decision support, digital therapeutics — with FDA pathway planning
Device companion apps	iOS/Android apps that pair with medical devices, display data, and guide patient usage
IoT data platforms	Stream processing, storage, analytics, and visualization for continuous device data
Clinical dashboards	Real-time monitoring, alerting, and escalation for clinical teams managing device-connected patients
EHR integration	Device data flowing into Epic, Oracle Health, and other EHRs via FHIR or HL7v2
RPM platforms	Complete remote patient monitoring solutions with device integration, clinical workflows, and billing automation
Regulatory documentation	IEC 62304 lifecycle documentation, design history files, validation protocols

Discuss Your Device Software Needs Building medical device software, a connected health platform, or an IoT-enabled clinical system? Schedule a free consultation to discuss your technical and regulatory requirements. Discuss Your Project →

Related Resources:

• • Medical Device Software Development (SaMD & FDA)
  • Remote Patient Monitoring
  • Case Study: RPM System — 35% Readmission Reduction
  • Healthcare AI & ML Development
  • AI in Healthcare Guide
  • FHIR API Development
  • Mirth Connect Integration
  • Healthcare Integration Guide
  • HIPAA Compliance Guide
  • Certifications & Compliance
  • Case Studies
  • Free Consultation