FDA Interoperable Medical Devices

Interoperability means exchanging and using information

FDA's guidance addresses medical devices that electronically exchange and use information with other medical devices, products, technologies or systems. Safe interoperability requires more than successful transport: the receiving system must interpret and use information correctly within the intended clinical workflow.

Examples include patient monitors sending observations to an electronic record, infusion systems receiving orders, analysers communicating with laboratory systems, devices exchanging data with mobile applications and coordinated systems using commands or state information.

Use MTL-121 — Data, Connectivity and Interoperability for the broader engineering foundation.

Define what the connection is intended to achieve

Identify the systems, users, environments, data and actions in scope. Distinguish display-only information from data that drives calculations, alarms, treatment or device control. Define whether the interface is intended for specific products, a class of products or an open ecosystem.

• What information or commands are exchanged?
• What medical purpose does the exchange support?
• Which device or person remains responsible for each decision?
• What timing, accuracy, availability and sequence are required?
• Which external systems and versions are supported?
• What happens when the connection or data is invalid?

These decisions should agree with the device intended purpose and labelling described in MTL-102 — Intended Purpose, Users and Use Environments.

Specify the interface as a set of testable requirements

Interface requirements should address physical, communication, data, functional, performance, security and human aspects. A protocol name alone does not define compatible behaviour.

Control interface specifications and make responsibilities clear at both sides of the boundary. Use MTL-112 — Systems Engineering, Architecture and Interfaces for interface-management practices.

Architecture must expose dependencies and control

Show devices, external systems, gateways, networks, users, databases and cloud services involved. Identify trust boundaries, control paths, data stores, time sources, identity services and components that transform information.

Allocate responsibilities for validation, alarm generation, data quality, retries, reconciliation and recovery. Avoid ambiguous shared responsibility: if two components each assume the other detects an error, the system has no effective control.

Analyse failures across the complete interoperable system

Consider incorrect, delayed, duplicated, incomplete, misidentified, out-of-sequence and unavailable data. Analyse wrong-patient association, unit or scale errors, stale information, loss of context, incompatible versions and inappropriate commands.

Follow each failure to its possible effect on device behaviour, user decisions, clinical workflow and patient harm. Include foreseeable connections and misuse, and make assumptions about external controls explicit. Risk controls may reside in the sending device, receiving device, interface engine, network or user workflow.

MTL-105 — Medical-device Risk Management explains how to connect interface failures to hazardous situations and verified controls.

Interoperability and cybersecurity are inseparable

Connectivity expands the attack surface and can allow untrusted data or commands to affect device behaviour. Define device and system authentication, authorisation, confidentiality, integrity, replay protection, logging and secure failure behaviour.

Security controls must support clinical availability and recovery. An authentication failure, expired certificate or unavailable security service should not cause an uncontrolled clinical state. Apply the lifecycle expectations in MTL-308 — FDA Cybersecurity in Medical Devices Guidance.

Shared syntax does not guarantee shared meaning

Specify units, precision, reference ranges, timestamps, time zones, patient and device identity, data quality, status and provenance. Define how corrected, cancelled, preliminary or invalid data is represented and used.

Where standards such as HL7, FHIR, IEEE 11073 or DICOM are used, identify profiles, options, terminology and implementation constraints. Test the actual implementation rather than claiming compatibility from use of a standard name.

Test both conformance and real integration

Conformance testing checks implementation against a specification. Integration testing demonstrates behaviour with representative external systems, configurations and workflows. Both may be needed.

• Verify nominal messages, commands and data transformations.
• Challenge boundaries, invalid values, unexpected sequences and malformed input.
• Test timeout, retry, duplication, interruption and reconnection.
• Confirm patient, device and record association.
• Evaluate clock differences, stale data and data correction.
• Test cybersecurity controls and failure recovery.
• Use representative versions and document interoperability limitations.
• Perform end-to-end validation in the intended workflow.

Test laboratories and partners should receive controlled interface specifications and clear acceptance criteria. MTL-106 — Verification and Validation provides the wider evidence framework.

Labelling defines how to establish and maintain safe connections

Provide the information users and integrators need to select compatible systems, configure the interface, verify correct operation and recognise failures. Identify supported standards, versions, profiles, data, ports, security requirements, limitations and necessary network or external controls.

Explain installation, connection checks, alarm or error behaviour, troubleshooting and recovery. Avoid vague statements such as “HL7 compatible” or “connects to hospital systems” without the detail needed for safe integration.

Premarket evidence should explain the interoperability claim

FDA recommends submission information describing the intended interface, architecture, design requirements, risk analysis, verification and validation, cybersecurity and labelling. The depth should reflect the interface's effect on safety and effectiveness.

Show traceability from intended exchange and hazards to requirements, implementation and test results. Identify external dependencies and assumptions. Evidence should match the software, hardware and interface versions to be marketed.

Interoperability must survive ecosystem change

External products, protocols, certificates, operating systems, cloud services and network policies change. Establish compatibility monitoring, version support, change notification, regression testing and customer communication.

Use field data to detect communication failures, data-quality issues and unsafe integration patterns. Evaluate whether device or external changes require updated risk controls, labelling, validation or regulatory assessment through MTL-312 — FDA Changes to Existing Devices and Software.

Common misconceptions

Practical interoperability checklist

• Is the medical purpose of every intended exchange defined?
• Are supported systems, versions and configurations identified?
• Do requirements cover syntax, semantics, timing, security and failure?
• Are responsibilities clear across the interface boundary?
• Does risk analysis include incorrect, stale, missing and misassociated data?
• Are cybersecurity and privacy controls integrated?
• Have conformance, negative, integration and workflow tests been performed?
• Does labelling provide usable integration and recovery information?
• Is the submitted evidence configuration-specific and traceable?
• Can the organisation manage external-system and protocol changes after release?