MDR Annex I §14.2(d) and §17.1 require manufacturers to address risks arising from interaction with other equipment, devices, or software. For medical software, this means every interface — data input, data output, and protocol exchange — must be specified, verified, and risk-assessed. HL7, FHIR, and DICOM are common patterns, but MDR does not mandate any of them; it mandates that whatever you use works safely and is proven to work safely.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I §14.2(d) requires that devices designed to be used in combination with other devices or equipment are safe and do not impair the specified performance of the devices; compatibility and interconnection must be addressed.
  • MDR Annex I §17.1 requires that software designed to be used in combination with computing platforms be designed to ensure repeatability, reliability, and performance in line with intended use.
  • MDR does not prescribe specific interoperability standards. HL7, FHIR, and DICOM are widely adopted integration patterns; the manufacturer decides what is appropriate and proves it works.
  • Every interface is a boundary of control — and every boundary of control is a source of risk under EN ISO 14971:2019+A11:2021.
  • Verification of interfaces follows EN 62304 clauses 5.6 and 5.7 (integration and system testing), with documented protocols, records, and traceability.
  • MDCG 2019-11 Rev.1 clarifies that software modules exchanging data with a medical device may themselves qualify as medical device software; interoperability is not a way out of classification.

Why interoperability is a regulatory problem, not an engineering problem

The engineering view of interoperability is: if the API contract is clean and the data format is standard, integrations work. The regulatory view is different. Interoperability under MDR is about what happens when your software depends on a system you do not control — and whether patients are safe when that system behaves unexpectedly.

Consider the real cases we see. A SaMD pulls lab results from a hospital EHR via HL7 v2. The hospital upgrades its middleware and starts sending temperature values in Fahrenheit instead of Celsius to one message type. The SaMD displays the temperature. A clinician misses a fever. Who is responsible? Under MDR, the manufacturer is responsible for anticipating foreseeable interaction failures and building controls. The interface is part of the device system even if the interface endpoint is someone else's server.

This is why MDR Annex I §14.2(d) exists. It reflects a hard-earned lesson from decades of medical device incidents: the failure modes at integration boundaries are different from failures inside a single system, and they require explicit treatment.

What MDR actually says

Annex I §14.2(d) addresses devices intended to be used in combination with other devices or equipment. The manufacturer must ensure that the whole combination, including the connection system, does not impair the specified safety and performance of the devices. The interface specification, the compatibility constraints, and the conditions of safe use are the manufacturer's responsibility.

Annex I §17.1 is the software-specific companion. Software, including software that is itself a device and software incorporated in a device, shall be designed to ensure repeatability, reliability, and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. For software intended to be used in combination with mobile computing platforms, it shall be designed and manufactured taking into account the specific features of the mobile platform and the external factors related to their use.

Annex I §17.2 (state-of-the-art software development) points at EN 62304:2006+A1:2015, which in clauses 5.3 (software architectural design) and 5.6 (integration testing) specifically requires the identification and verification of software interfaces, including interfaces to SOUP (software of unknown provenance) and to external systems.

MDCG 2019-11 Rev.1 is important here. It clarifies that a module performing interoperability functions between a medical device and another system can itself be medical device software if its output influences medical decisions. Interoperability layers are not automatically "just plumbing" — they may be part of the regulated device.

None of these references require HL7, FHIR, or DICOM. They require that whatever interface you build is specified, tested, risk-assessed, and documented. The choice of standard is an engineering decision. The obligation to prove safety is a regulatory one.

A worked example: a SaMD reading lab values

A Class IIa SaMD calculates a clinical risk score from five laboratory values. It reads those values from the hospital EHR through an integration layer. The engineering team uses HL7 FHIR R4 because the target customer publishes a FHIR endpoint. Good engineering choice. Now the MDR work begins.

Interface specification (EN 62304 clause 5.3). The software architecture document describes: - The FHIR resources consumed (Observation, Patient, Encounter). - The LOINC codes expected for each of the five lab values. - The unit expected per LOINC code, with explicit handling of unit mismatches. - The acceptable value ranges and the behaviour when values are missing, null, outside range, or flagged as preliminary. - Authentication, transport security, and data-at-rest handling. - Error handling when the FHIR endpoint is unreachable, slow, or returns malformed data.

Risk analysis (EN ISO 14971:2019+A11:2021). Hazards identified at the interface: - Unit mismatch (e.g. mg/dL vs mmol/L for glucose) leading to incorrect risk score. - Preliminary values being treated as final. - Stale data being displayed as current. - Silent integration failure — no data, but no visible error. - Mapping ambiguity between vendor-specific codes and LOINC.

For each hazard, a control measure is defined. The unit mismatch hazard is controlled by explicit unit verification on every received value, with a reject-and-alert behaviour on mismatch. Each control measure becomes a software requirement and a test.

Integration verification (EN 62304 clause 5.6). Test protocols verify each interface behaviour: the happy path, each documented failure mode, each risk control measure. Inputs are curated FHIR bundles; expected outputs are defined in advance; actual outputs are recorded; interpretation is written by a human.

System verification (EN 62304 clause 5.7). End-to-end tests in a production-like environment verify that the intended clinical behaviour — the risk score — is correct given realistic source data, including edge cases from the risk file.

Technical documentation (MDR Annex II). The interface specification, the risk analysis, the verification protocols and reports, and the traceability matrix linking requirements, risks, and tests all live in the technical file. The notified body can reconstruct the entire interoperability story from the documentation.

HL7 FHIR here is a vehicle. The regulatory substance is the same whether you use FHIR, HL7 v2, DICOM, a custom REST API, or a file drop.

The Subtract to Ship playbook for interoperability

1. Name every interface in your architecture, even the small ones. Every data input, every data output, every protocol exchange. If you cannot enumerate them, you cannot verify them. Include third-party SDKs, cloud services, authentication providers, logging services, and SOUP components.

2. Specify before you integrate. For each interface: data contract, units, error behaviour, timing, authentication, transport, and what happens when the other side misbehaves. EN 62304 clause 5.3 requires the architecture to describe interfaces to external systems and SOUP. Write the specification before the code ships.

3. Risk-assess every interface independently. Interfaces are boundaries of control. The hazards at a boundary are different from hazards inside a function. Run the EN ISO 14971 process on each interface: what can fail, how likely, how severe, how detectable. Generate control measures. Trace them into software requirements.

4. Treat common patterns as common patterns, not guarantees. HL7, FHIR, and DICOM are mature, widely adopted, and well-tooled. They are also implemented differently by different vendors. "We use FHIR" is not a compliance claim; "we verified our FHIR consumer against these specific resources, these specific codes, these specific failure modes" is.

5. Verify interfaces with realistic data. Integration tests that only use synthetic happy-path data miss the failure modes that matter. Use de-identified real-world samples when you can. Use adversarial inputs. Use the weird edge cases the customer's upstream system actually produces.

6. Monitor interfaces in production. MDR post-market surveillance (Articles 83-86, Annex III) covers the whole device. Interface behaviour should be monitored as part of PMS: connection health, error rates, data quality flags, mismatch rates. If an upstream system changes, you want to know before a clinician does.

7. Document SOUP and OTS components that participate in interoperability. EN 62304 clause 8.1 requires SOUP documentation: title, manufacturer, unique identifier, functional and performance requirements, hardware and software requirements the SOUP needs to satisfy. Interoperability libraries (FHIR clients, HL7 parsers, DICOM toolkits) are typically SOUP. Document them as such.

Reality Check

  1. Can you produce a complete list of every interface your software has — not just the ones the customer sees?
  2. For each interface, is there a written specification covering data contract, units, errors, timing, and security?
  3. Is there a risk analysis entry for each interface with documented hazards and control measures?
  4. Can you trace from each interface risk to a software requirement and from that requirement to a verification test?
  5. Do your integration tests include the edge cases from the risk file, or only the happy path?
  6. If the upstream system changed format tomorrow, how long until your PMS system detected it?
  7. Are your HL7, FHIR, or DICOM libraries documented as SOUP with the EN 62304 required fields?
  8. Does the interface specification state clearly what the device does NOT promise when connected to non-conforming upstream systems?

Any "no" in this list is a gap the notified body will find.

Frequently Asked Questions

Does MDR require me to use HL7, FHIR, or DICOM? No. MDR does not mandate any specific interoperability standard. It requires that whatever interfaces you build are safe, specified, verified, and risk-assessed. HL7, FHIR, and DICOM are common because they are mature and well-supported; the choice is engineering, the obligation to prove safety is regulatory.

Is my interoperability layer itself a medical device? It depends on what it does. MDCG 2019-11 Rev.1 clarifies that if the layer performs a function that influences medical decisions — not just data transport — it may itself qualify as medical device software and require classification under Rule 11. A pure transport layer usually does not; a transformation or decision layer often does.

Who is responsible when the upstream system sends bad data? The manufacturer of the medical software is responsible for anticipating foreseeable interaction failures and building controls. MDR Annex I §14.2(d) makes this explicit. You cannot fully offload this risk to the upstream vendor — you must handle it in your device.

Do I need to test every possible input permutation? No. You need to test the specified behaviour, the risk-controlled failure modes, and realistic edge cases from your risk file. Exhaustive testing is not a regulatory requirement; sufficient evidence of correct and safe behaviour is.

What about cloud services as part of the interface? Cloud components consumed by the device are part of the device system for conformity purposes. Their behaviour, availability, and failure modes must be considered. EN 62304 SOUP requirements apply where the component meets the SOUP definition.

How does interoperability affect my post-market surveillance? Interface behaviour is a first-class PMS signal. Upstream systems change. Your PMS plan should include monitoring of interface health and a mechanism to act on signals before they become clinical incidents.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §14.2(d), §17.1, §17.2.
  2. EN 62304:2006+A1:2015, Medical device software — Software life cycle processes. Clauses 5.3, 5.6, 8.1.
  3. MDCG 2019-11 Rev.1 (June 2025), Qualification and classification of software.
  4. EN ISO 14971:2019+A11:2021, Medical devices — Application of risk management to medical devices.