Medical Device Interoperability: HL7, FHIR, and Connected Device Standards in 2026

Why Medical Device Interoperability Is No Longer Optional

A patient in an intensive care unit is monitored by an average of 10 to 15 connected devices generating streams of data every second — vital signs monitors, infusion pumps, ventilators, pulse oximeters. Each device collects critical information about the patient's condition. Yet in most hospitals today, that data is siloed. It cannot flow cleanly into the electronic health record (EHR). It cannot reach the analytics platform that might detect a dangerous trend before a clinician does. Nurses manually transcribe values from device screens into charting systems, introducing transcription errors and delays.

This is the interoperability problem, and it is getting worse, not better. The medical device connectivity market was valued at $3.38 billion and is projected to surpass $17 billion by 2034. The broader Internet of Medical Things (IoMT) market is projected to exceed $860 billion by 2030. Each new device adds another data silo unless it is designed to communicate using standardized protocols.

Regulators have taken notice. The FDA's Center for Devices and Radiological Health has identified medical device interoperability as a public health priority. The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) is phasing in between January 2026 and January 2027, with operational prior authorization reforms already in effect and FHIR API mandates for payers taking effect January 2027. The EU is pushing connected device standards through the Cyber Resilience Act and MDR requirements for devices with electronic data interfaces. In March 2026, HL7 International launched the Caliper FHIR Accelerator specifically to address real-time medical device data interoperability.

This guide covers the standards landscape for medical device interoperability, how HL7 and FHIR work, what the FDA and EU regulators expect from manufacturers, the technical architecture for connected devices, and a practical implementation roadmap.

The Interoperability Standards Landscape

Medical device interoperability requires agreement at multiple layers — physical connectivity, data transport, data format, data semantics, and clinical workflow. No single standard covers all layers. Instead, a family of standards works together:

Core Standards for Medical Device Data Exchange

How These Standards Layer Together

A connected medical device typically uses this stack:

1. Physical layer — USB, RS-232, Bluetooth, Wi-Fi, Ethernet
2. Transport layer — TCP/IP, MQTT, HTTP/HTTPS
3. Device communication layer — IEEE 11073 (device-specific encoding and messaging)
4. Data format layer — HL7 FHIR resources, HL7 v2 segments, DICOM objects
5. Terminology layer — LOINC (lab observations), SNOMED CT (clinical terms), ICD-10 (diagnoses), UCUM (units)
6. Workflow layer — IHE integration profiles (PCD-01 for device observations, PCD-02 for alert communication)

The challenge is that legacy devices at the bedside often speak IEEE 11073 or proprietary protocols over RS-232 serial ports, while modern EHR systems expect FHIR over HTTPS. Bridging these worlds requires middleware — integration engines that translate between protocols.

HL7 v2: The Legacy That Refuses to Die

Health Level Seven version 2 (HL7 v2) has been the dominant standard for clinical data exchange in hospitals since the 1990s. It uses a pipe-delimited text format:

MSH|^~\&|PATMON|ICU|EHR_SYS|HOSPITAL|202604251200||ORU^R01|MSG00001|P|2.5.1
PID|1||12345^^^MRN||DOE^JOHN^A||19700101|M
OBX|1|NM|8867-4^Heart Rate^LN||78|bpm/min^bpm/min^UCUM|60-100|N|||F|||202604251159
OBX|2|NM|8480-6^Systolic BP^LN||122|mmHg^mmHg^UCUM|90-140|N|||F|||202604251159

Common HL7 v2 Message Types for Device Data

Limitations of HL7 v2

HL7 v2 was designed for a world of monolithic hospital information systems. Its limitations for medical device integration include:

• No standard API — interfaces require custom point-to-point configuration for every device-EHR pair
• Semantic ambiguity — the same data element can be encoded differently by different systems, requiring custom mapping for each interface
• No built-in security — HL7 v2 predates modern cybersecurity requirements; encryption and authentication must be bolted on at the transport level
• Limited query capability — HL7 v2 is primarily push-based (event-driven), not request-response
• Difficult version management — minor differences between v2.3, v2.5.1, and v2.7 cause integration failures

Despite these limitations, HL7 v2 remains the most deployed standard in hospitals worldwide. Any interoperability strategy must account for its continued presence.

HL7 FHIR: The Modern Standard for Health Data Exchange

Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is HL7's modern standard, designed from the ground up for the web era. FHIR uses RESTful APIs, JSON and XML data formats, and HTTP methods — technologies familiar to any software developer.

Core FHIR Concepts for Device Manufacturers

Resources. FHIR organizes health data into discrete, standardized units called Resources. For medical device data, the most relevant resources are:

API Operations. FHIR uses standard HTTP methods:

• GET /Observation?patient=123&category=vital-signs — retrieve vital signs for a patient
• POST /Observation — create a new observation (e.g., push a device reading)
• GET /Device/456 — retrieve device metadata (manufacturer, model, serial number)

Implementation Guides. FHIR is extensible through Implementation Guides (IGs) — standardized profiles that constrain FHIR resources for specific use cases. Key IGs for device interoperability include:

The Caliper FHIR Accelerator (2026)

In March 2026, HL7 International launched the Caliper FHIR Accelerator, a new implementation community specifically dedicated to medical device interoperability. Caliper builds on the HL7 Devices Work Group and the HL7–IHE Gemini Device Interoperability Program.

Caliper's goals include:

• Creating standardized FHIR profiles for real-time device data from critical care equipment and patient-facing technologies
• Aligning HL7 FHIR with IEEE 11073 device communication standards and IHE integration profiles
• Enabling consistent, reliable, and safe data flow from devices to EHRs and analytics platforms
• Supporting the full range of device data — from low-frequency personal health device readings to high-frequency ICU monitor waveforms

Caliper became fully operational on January 1, 2026, after spending 2025 in initiation and formation phases. It was featured at HIMSS26 with live demonstrations.

IEEE 11073: Device-Level Communication Standards

While HL7 and FHIR handle data exchange at the system level, IEEE 11073 addresses how devices communicate at the point of care. The standard has two main branches:

IEEE 11073 for Point-of-Care Devices (PoCD)

These standards define how hospital-grade devices (ventilators, monitors, infusion pumps) communicate:

• IEEE 11073-10101 — Nomenclature (standardized terms for device observations)
• IEEE 11073-10201 — Domain Information Model (device data structure)
• IEEE 11073-20702 — Service-oriented Device Connectivity (SDC) — the modern framework for real-time OR and ICU device communication

SDC is particularly important for surgical environments where real-time data from multiple devices must be aggregated for clinical decision support. It uses a service-oriented architecture with publish-subscribe patterns for low-latency data delivery.

IEEE 11073 for Personal Health Devices (PHD)

These standards support consumer and home health devices:

• IEEE 11073-104xx — Device specialization standards (e.g., 10407 for blood pressure, 10408 for thermometer, 10415 for weighing scale, 10471 for glucose monitor)
• IEEE 11073-20601 — Transport layer for personal health devices (optimized for Bluetooth, USB)

The challenge is bridging IEEE 11073 device data into FHIR resources. The "Devices on FHIR" (DoF) Implementation Guide maps IEEE 11073 observation data to FHIR Observation resources, enabling a pathway from bedside device to cloud-based analytics.

Regulatory Requirements for Connected Device Interoperability

FDA Expectations

The FDA does not mandate specific interoperability standards but has published guidance and expectations:

Design considerations. The FDA's guidance on medical device interoperability recommends that manufacturers:

• Use consensus standards (HL7, IEEE 11073, DICOM) where available
• Specify the types of data the device is designed to exchange
• Define the intended interfaces and communication protocols
• Implement appropriate cybersecurity controls for all data connections
• Test interoperability as part of design verification

Cybersecurity. The FDA's February 2026 final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions requires manufacturers to:

• Integrate cybersecurity into the quality management system (aligned with ISO 13485)
• Provide a Software Bill of Materials (SBOM) for all connected devices
• Document threat modeling and risk assessment for data interfaces
• Implement encryption for data in transit and at rest
• Establish a plan for vulnerability management and patch distribution

Premarket submissions. For 510(k) and De Novo submissions involving connected devices, the FDA expects:

• Description of data interfaces and supported protocols
• Cybersecurity documentation per the 2026 guidance
• Evidence of interoperability testing
• Risk analysis addressing data exchange failures

EU MDR and EU CRA Requirements

EU MDR. The Medical Device Regulation requires that devices with electronic programmable systems — including those that exchange data — address:

• Minimum requirements concerning IT security measures (including protection against unauthorized access)
• Data integrity and data loss prevention
• Interoperability with other devices or software where claimed

EU Cyber Resilience Act (CRA). Adopted in 2024 with phased implementation through 2027, the CRA imposes cybersecurity requirements on all products with digital elements, including medical devices. Key requirements include:

• Security-by-design and security-by-default principles
• Vulnerability handling and disclosure processes
• Software Bill of Materials
• Incident reporting within 24 hours of becoming aware of a serious incident
• Free security updates for the expected product lifetime

NIS2 Directive. The Network and Information Security Directive 2 applies to healthcare as an essential sector, requiring incident reporting, risk management, and supply chain security.

CMS Interoperability Mandate

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires:

• Payer-to-payer data exchange using FHIR APIs (effective January 2027)
• Provider access APIs for patient data (effective January 2027)
• Prior authorization APIs using Da Vinci Implementation Guides (PAS, CRD, DTR) (effective January 2027)
• Public API directory maintained by each payer
• Operational reforms including 72-hour expedited and 7-day standard prior authorization decisions (effective January 2026)

While CMS rules target payers and providers rather than device manufacturers directly, the effect cascades: hospitals that must comply with CMS interoperability mandates will increasingly demand FHIR-compatible device interfaces.

Technical Architecture for Connected Medical Devices

Architecture Patterns

There are three primary architecture patterns for medical device interoperability:

Pattern 1: Device-to-Gateway-to-EHR

[Medical Device] → [Gateway/Interface Engine] → [EHR/HIS]
    (IEEE 11073/       (Protocol translation,       (HL7 FHIR
     proprietary)       data normalization)            APIs)

This is the most common pattern. The device communicates using its native protocol (IEEE 11073, proprietary, or serial). A gateway or integration engine (e.g., Rhapsody, Mirth Connect, Redox, PilotFish) translates the data into HL7 v2 or FHIR messages and routes them to the EHR.

Pattern 2: Device-to-Cloud-to-EHR

[Medical Device] → [Cloud Platform] → [EHR/HIS]
    (MQTT/HTTPS/       (Data lake, FHIR         (FHIR APIs)
     BLE/Wi-Fi)         server, analytics)

This pattern is common for IoMT and wearable devices. Data flows from the device to a cloud platform (AWS HealthLake, Azure Health Data Services, Google Cloud Healthcare API), which provides FHIR server capability and routes data to downstream systems.

Pattern 3: Direct FHIR-Native Device

[Medical Device] → [EHR/HIS]
    (FHIR REST API      (FHIR Server)
     directly)

Emerging devices with sufficient compute resources can expose FHIR APIs directly. This is the ideal architecture for new device development, though it requires more processing power on the device itself.

Security Architecture

All architectures must address:

• Transport encryption — TLS 1.2 or higher for all data in transit
• Authentication — Mutual TLS, OAuth 2.0, or SMART on FHIR for API access
• Authorization — Role-based access control limiting who can read/write device data
• Data encryption at rest — AES-256 for stored data, aligning with the proposed 2026 HIPAA Security Rule update
• Audit logging — Complete audit trail of all data access and exchange
• SBOM management — Software Bill of Materials for cybersecurity vulnerability tracking

Implementation Roadmap for Manufacturers

Phase 1: Requirements Definition (Weeks 1–4)

• Identify which data elements the device needs to exchange (observations, alerts, configuration, firmware updates)
• Define target integration environments (EHR systems, clinical workflows, home monitoring platforms)
• Select communication protocols based on deployment environment (hospital bedside vs. home use vs. ambulatory)
• Document interoperability claims for regulatory submission

Phase 2: Standards Selection (Weeks 3–6)

• Map data elements to FHIR resources (Device, Observation, Patient, Endpoint)
• Select applicable Implementation Guides (US Core, Devices on FHIR, Caliper)
• Define IEEE 11073 device specialization if applicable
• Plan for HL7 v2 backward compatibility where hospital installations require it

Phase 3: Design and Development (Weeks 5–16)

• Implement device communication stack (physical layer through application layer)
• Develop FHIR API interfaces (REST endpoints for device data)
• Implement security controls (TLS, authentication, encryption, SBOM)
• Build data mapping between device-specific data and standard terminologies (LOINC, SNOMED CT)

Phase 4: Testing and Validation (Weeks 14–20)

• Unit testing — individual interface components
• Integration testing — end-to-end data flow from device to EHR
• Interoperability testing — against multiple EHR systems (Epic, Cerner/Oracle Health, MEDITECH)
• Security testing — penetration testing, vulnerability scanning, SBOM validation
• Regulatory testing — verify all data elements, protocols, and security controls match submission claims

Phase 5: Deployment and Maintenance (Ongoing)

• Install and configure integration at customer sites
• Provide ongoing vulnerability management and security patches
• Monitor interface performance and data quality
• Update SBOM and security documentation for each software release

Key Takeaways

Medical device interoperability has moved from a nice-to-have feature to a regulatory and market requirement. The convergence of CMS FHIR mandates, FDA cybersecurity expectations, EU CRA requirements, and the HL7 Caliper initiative means that manufacturers who ignore interoperability will face increasing barriers to market access. The standards stack — IEEE 11073 at the device level, HL7 FHIR at the system level, IHE profiles for workflow integration — is mature enough to implement today. Manufacturers should design connected devices with FHIR-native interfaces from the start, implement robust cybersecurity controls, and plan for both modern FHIR and legacy HL7 v2 environments during the transition period.