Data, Connectivity and Interoperability

Connectivity moves data; interoperability preserves its intended use

A connection allows two components or systems to exchange signals or data. Interoperability exists when they can exchange information and use it safely and effectively for an intended purpose. A successful network connection, parsed message or API response does not prove that the receiving system understood the information correctly or acted appropriately.

Interoperability is therefore a product and system property, not merely a communications feature. It depends on compatible technology, an agreed information model, controlled behaviour, suitable workflow integration and clear responsibility across the participating organisations.

Begin with purpose, workflow and system boundary

Define each intended connection in terms of the clinical or operational outcome it supports. A device that exports observations for retrospective review has different timing, integrity and availability needs from one that supplies real-time data to a closed-loop controller.

• Identify the producing and consuming systems, organisations and responsible people.
• Describe the user, patient and workflow in which the exchange occurs.
• State whether information supports display, storage, alarm transmission, decision support, control, configuration, servicing or another purpose.
• Define what lies inside the medical-device system boundary and which external systems are assumptions or dependencies.
• Identify whether the connection is required for basic safety, essential performance or a non-safety-related function.
• Define the expected environment, network ownership, administration, latency, availability and scale.
• State prohibited uses and connections as clearly as intended ones.
• Identify who configures, verifies, monitors and maintains the integrated system.

The boundary and workflow should remain consistent with MTL-102 — Intended Purpose, Users and Use Environments. Use MTL-112 — Systems Engineering, Architecture and Interfaces to allocate functions and responsibilities across the wider system.

Model the information—not just the fields

A data dictionary should define more than names and types. Safe interpretation depends on identity, clinical context, measurement meaning, timing, quality and provenance. These elements should be explicit, controlled and testable.

Identifiers require particular care. A correct measurement attached to the wrong patient, device, channel or time can be more dangerous than no measurement at all. Define creation, matching, update, reconciliation and exception rules rather than assuming identifiers are globally unique or permanently stable.

Design inputs should state the required information meaning and quality in verifiable terms. MTL-103 — User Needs and Design Inputs explains how to translate the workflow and risks into clear requirements.

Make the interface contract complete

An interface contract records what the participants promise to send, accept and do. It should remove avoidable ambiguity while allowing controlled evolution.

The contract should specify both normal and abnormal behaviour. If an optional field is omitted, a value is outside range or a message is repeated after a timeout, both participants must react predictably and safely.

Address every layer of interoperability

Interoperability can fail even when one layer works perfectly. Teams should identify the layers on which the intended use depends and assign requirements and evidence accordingly.

A standardised message can establish syntactic compatibility while leaving semantic or workflow choices open. State which implementation profiles, options, extensions, value sets and local configurations are supported.

Protect data integrity from acquisition to use

Consider the complete data path: acquisition, conversion, filtering, calculation, storage, transmission, transformation, display, export and deletion. Each step can alter meaning, quality or availability.

• Trace critical data from its source to every display, record, decision or control action.
• Preserve patient, device, channel, sample and time association through transformations.
• Control units, rounding, scaling, precision, limits and conversion algorithms.
• Detect truncation, corruption, partial transactions and incompatible encodings.
• Manage duplication, replay, loss and out-of-order delivery explicitly.
• Distinguish measured, calculated, manually entered, corrected and imported values.
• Make stale, provisional, invalid or low-confidence information visible to users and consuming systems.
• Maintain auditability and provenance where records or decisions may be reconstructed later.
• Define reconciliation when local and remote records disagree.

Risk controls and essential-performance claims can depend on data integrity. Link critical paths to MTL-113 — Essential Performance and Safety Concepts and the product risk-management file.

Design degraded and recovery behaviour deliberately

Real connections are unavailable, intermittent, congested, misconfigured and changed. The safe response must be designed rather than left to the operating system, communications library or integrator.

Users need an accurate mental model of the connected state. A green network icon must not imply that data is current, complete or accepted by the destination. Include connectivity failures and recovery in use-related risk analysis and realistic validation scenarios.

Manage risk across the connected system

Connectivity introduces hazards through incorrect information, delayed action, unintended control, unavailable functions and interaction between independently managed systems. Apply MTL-105 — Medical-device Risk Management to the device and its intended connections, then communicate residual dependencies to the integrating organisation.

• Identify hazardous situations arising from wrong identity, value, units, time, status or context.
• Consider information that is lost, duplicated, delayed, stale, corrupted, incomplete or disclosed.
• Analyse unintended commands, settings, software updates and configuration changes.
• Evaluate resource exhaustion, network congestion and interactions with other connected systems.
• Distinguish controls implemented by the device from controls expected of the external environment.
• Define the information and cooperation needed from healthcare providers, IT suppliers and other manufacturers.
• Verify controls at the level where the hazardous situation is actually prevented or detected.
• Assess changes to any participant, infrastructure or workflow that can affect the shared risk.

IEC 80001-1 addresses organisational risk management before, during and after connecting health IT systems within health IT infrastructure, with attention to safety, effectiveness and security. The manufacturer should supply enough information for the responsible organisation to manage the connection, without transferring away the manufacturer’s own design responsibilities.

Integrate cybersecurity and privacy

Interoperability expands trust boundaries and attack surfaces. Security controls must support the intended clinical use without obscuring safety-significant data or making recovery impractical.

Use MTL-108 — Medical-device Cybersecurity to integrate threat modelling, secure architecture, verification, monitoring and updates. Treat privacy requirements separately where necessary: information can remain accurate and available while still being collected or disclosed inappropriately.

Select standards and profiles for the intended exchange

Standards reduce unnecessary variation, but selecting a familiar protocol does not establish interoperability. Choose standards according to the information, workflow, environment and partners involved, then constrain the allowed choices.

• Use DICOM where appropriate for medical imaging information and related workflows.
• Consider HL7 messaging or FHIR resources and APIs for suitable clinical and administrative information exchange.
• Use relevant ISO/IEEE 11073 standards where device communication and nomenclature fit the application.
• Define implementation guides, profiles, resource subsets, terminology bindings, extensions and optional features.
• Control lower-level technologies such as Ethernet, Wi-Fi, Bluetooth, USB or serial communication separately from clinical meaning.
• Record the exact edition, version and conformance claims rather than naming only a standards family.
• Identify proprietary additions and ensure they cannot be mistaken for standard behaviour.
• Evaluate the standard’s error handling, security assumptions, maintenance model and installed-base compatibility.

Prefer established profiles and test tools when they genuinely match the use case. Avoid carrying every option into the product; optionality increases combinations, ambiguity and verification burden.

Verify more than protocol conformance

Conformance testing shows whether an implementation follows selected rules. Interoperability testing shows whether particular systems work together. End-to-end validation shows whether the integrated workflow meets user needs safely and effectively. All three can be necessary.

Control the exact software, firmware, hardware, schema, terminology, security configuration and partner versions used as evidence. MTL-106 — Verification and Validation provides the wider framework for representative test articles, protocols, acceptance criteria, anomalies and conclusions.

Support safe deployment, change and retirement

Integration information is part of the safety control. Labelling and technical documentation should enable competent organisations to determine whether a proposed connection is supported and how it must be configured, tested and maintained.

• Describe intended uses, supported partners, versions, profiles and prohibited connections.
• Specify network, performance, time, security, certificate and infrastructure requirements.
• Provide interface specifications, installation steps, configuration limits and acceptance checks.
• State responsibilities for integration, local validation, user management, backup, monitoring and incident response.
• Explain degraded modes, alarms, recovery, data reconciliation and residual risks.
• Maintain a compatibility matrix and a controlled process for partner, platform and standards changes.
• Monitor complaints, data-quality events, outages, vulnerabilities and integration problems.
• Provide migration, update, rollback and end-of-support arrangements that preserve access to necessary records.

Organise interface specifications, verification reports, supported configurations and change evidence within MTL-104 — Design Controls and Technical Documentation. A connected function is not finished at product release; the surrounding ecosystem will continue to change.

Connectivity and interoperability across the lifecycle

Build a connected interoperability evidence chain

A reviewer should be able to trace from the intended information use and resulting hazards to interface requirements, architecture, implementation, risk controls, test configurations, results, supported combinations and field monitoring. Gaps between organisations must not become gaps in accountability.

Common misconceptions