---
title: Interoperability Under MDR: What the Regulation Expects for Connected Devices
description: How MDR Annex I §14.2(d) and §17.1 shape interoperability obligations for connected medical devices, with FHIR, HL7, DICOM, and IHE in context.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: interoperability MDR connected devices
canonical_url: https://zechmeister-solutions.com/en/blog/interoperability-mdr-connected-devices
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Interoperability Under MDR: What the Regulation Expects for Connected Devices

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **MDR does not name a specific interoperability protocol. It demands, through Annex I §14.2(d) and §17.1, that a connected device safely and reliably performs as intended when combined with other devices or software, and that state of the art is applied to design. Any chosen exchange pattern, whether FHIR, HL7 v2, DICOM, or an IHE profile, has to be verified, risk-assessed, and documented as part of the technical file.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- MDR Annex I §14.2(d) requires that devices intended to be used in combination with other devices or equipment are safe and do not impair the specified performance of the devices involved.
- MDR Annex I §17.1 requires that software devices are developed and manufactured in accordance with the state of the art, taking into account principles of development lifecycle, risk management, information security, verification, and validation.
- MDR does not mandate FHIR, HL7, DICOM, or IHE profiles. These are commonly used industry patterns that a manufacturer may choose, but the choice has to be justified and the interface verified.
- Every interface is a risk source. Each one belongs in the risk management file under EN ISO 14971:2019+A11:2021.
- Cybersecurity controls for the interface overlay on top of interoperability work, anchored by EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1.
- Notified Bodies expect to see interface specifications, protocol conformance evidence, integration test reports, and a clear story on what happens when the partner system misbehaves.

## Why connected devices stress test the MDR

A standalone device is simpler to certify than a connected one. Tibor has audited startups where the device itself was beautifully documented, and then the conversation turned to "so, what does your software do when the hospital PACS returns a malformed DICOM object" and the room went quiet.

Connected medical devices can mean many things. A bedside monitor streaming waveforms to an EHR over HL7 v2. A continuous glucose monitor sending data through a smartphone app into a cloud backend. A radiology AI that consumes DICOM from a PACS and writes structured reports back. A home care device that talks to a gateway over Bluetooth Low Energy. All of these sit inside the same MDR obligations, even though the engineering choices look nothing alike.

The MDR handles this with two clauses that founders tend to discover late: Annex I §14.2(d) for the combination question, and Annex I §17.1 for the software state of the art. Neither clause names a protocol. Both clauses expect a manufacturer to justify, verify, and document.

## What MDR actually says

### Annex I §14.2(d): combination with other devices

MDR Annex I Chapter II §14.2(d) requires that devices intended to be used in combination with other devices or equipment, including connection systems, are designed and manufactured in such a way that interoperability and compatibility are reliable and safe. The connection has to work. The connection has to be safe. And safety has to be preserved when the other end is a device the manufacturer does not own.

That last part is the trap. A startup shipping an AI triage module that ingests DICOM from any PACS cannot test against every PACS in Europe. The manufacturer still owns the obligation to demonstrate that the interface is safe across the range of systems the intended purpose covers.

### Annex I §17.1: software state of the art

MDR Annex I §17.1 requires that devices that incorporate electronic programmable systems, including software, or software that are devices in themselves, be designed to ensure repeatability, reliability, and performance in line with their intended use. §17.2 requires software development and manufacturing in accordance with the state of the art, taking into account development lifecycle, risk management, information security, verification and validation. §17.4 addresses minimum requirements for IT networks, IT security measures, and hardware characteristics where the device interacts with a network or operates in an IT environment.

In practice, this triangle of §14.2(d) plus §17.1 plus §17.4 is what a Notified Body auditor uses to decide whether a connected device has been designed responsibly.

### What MDR does not say

MDR does not mandate FHIR. MDR does not mandate HL7 v2. MDR does not mandate DICOM. MDR does not mandate IHE profiles. These are patterns that the industry has converged on because they work. A manufacturer is free to use them, free to use a proprietary protocol, free to combine approaches. What matters to the regulator is that the chosen approach is safe, verified, and state of the art.

## Common patterns, presented neutrally

FHIR (Fast Healthcare Interoperability Resources) is widely used for REST-style exchange of clinical data with modern EHRs. It is popular with cloud-based SaMD because it maps cleanly to JSON and HTTP. HL7 v2 remains dominant for real-time clinical messaging inside hospitals, especially for ADT, orders, and results. DICOM governs medical imaging and imaging workflow. IHE profiles describe reference integrations that combine these standards to solve named clinical use cases, for example XDS for document sharing or PIX for patient identifier cross-referencing.

Under MDR, each of these is an input to a design decision, not an authority. A founder who writes "the device is HL7 compliant" in the technical file has said almost nothing. A founder who writes "the device implements the HL7 v2.5.1 ORU^R01 message for results transmission, verified against reference messages A through E, with error handling for malformed segments 1 through 7, and risk controls X, Y, Z against data corruption scenarios" has made an MDR-grade statement.

Tibor has seen this gap often enough to call it the interoperability theater problem. The logo is on the slide. The conformance evidence is not in the file.

## Interface verification: what good looks like

A verified interface under MDR has several layers. Tibor looks for all of them during Stage 2 audits.

**Interface specification.** A written specification of every inbound and outbound interface, listing the protocol, the version, the supported messages or resources, the required and optional fields, the expected cardinalities, the error conditions, and the behavior on timeout or failure. This is a software requirement artifact under EN 62304:2006+A1:2015.

**Conformance evidence.** Where the interface follows a public standard, evidence that the implementation conforms. This can be vendor test suites, reference message archives, open source validators, or test harnesses run during integration testing. It is not a self-declaration in a marketing sheet.

**Integration test reports.** Evidence from integration testing, executed per EN 62304 §5.6 and §5.7, that the interface works end to end in realistic combinations. For a device intended to work with multiple third-party systems, the test plan has to sample those systems representatively and justify the sampling.

**Robustness and fault behavior.** Evidence that the device behaves safely when the other side misbehaves. Malformed messages, unexpected fields, truncated payloads, wrong character encoding, protocol version mismatches, network drops, and replay attempts all belong on the list. Risk controls for these belong in the risk management file under EN ISO 14971:2019+A11:2021.

**Traceability.** A trace from each interface requirement to the risk it addresses, the test that verifies it, and the design element that implements it. Without traceability, a Notified Body cannot tell whether the interface is covered, and will issue findings.

## Risk implications when multiple devices interact

The moment a device is part of a system, its risk profile changes. The hazard analysis has to consider hazards that arise only when the combination is active. Wrong patient association when a monitor and an EHR use different MRN schemes. Silent data loss when a message is accepted by the receiver but the content is dropped. Unit mismatch when one device reports mg/dL and the other assumes mmol/L. Time skew between devices confusing trend analysis. Stale data being treated as live.

These are not hypothetical. Tibor has reviewed post-market files where the serious incident trace led back to an interface assumption nobody had written down.

The Subtract to Ship move here is not to enumerate every possible combination. That path ends in paralysis. The move is to write the intended purpose with enough precision that the combinations in scope are finite and testable, and to say clearly in the instructions for use what the device is not intended to be combined with. MDR rewards precision. It punishes vague promises.

## Cybersecurity overlay

Every interoperability interface is also an attack surface. MDR Annex I §17.2 and §17.4 bring cybersecurity into the state of the art requirement. The operational standard for this is EN IEC 81001-5-1:2022, which defines a security lifecycle for health software and works alongside EN 62304. MDCG 2019-16 Rev.1 provides the interpretive guidance that Notified Bodies actually use during audits.

Practically, a connected device needs authenticated endpoints, authorised access, integrity protection on the wire, logging of security relevant events, and a process for handling disclosed vulnerabilities in the libraries that implement the protocol stack. FHIR over TLS with OAuth 2.0 is a common pattern. DICOM over TLS with user identity association is another. HL7 v2 inside a segmented hospital network with VPN termination is another. MDR does not prescribe which pattern. MDR expects the chosen pattern to be risk-assessed and documented.

The SBOM obligation matters here as well. A FHIR or DICOM client pulled from open source becomes a SOUP item under EN 62304 and a tracked component under the cybersecurity lifecycle. Tibor sees this missed regularly in first submissions.

## The Subtract to Ship playbook for connected devices

Felix coaches founders to keep the interoperability surface small and boring, then grow it on purpose.

**Step 1. Write the intended purpose before choosing the protocol.** The purpose constrains the combinations. The combinations constrain the protocols. Doing this in the other order creates a backlog of interfaces nobody asked for.

**Step 2. Pick one primary integration target for CE marking.** One EHR, one PACS, one gateway. Prove the interface against that target. Document the conformance evidence. Everything else is a change after launch, handled through the change control process required by MDR Article 10(9) and the Notified Body procedures.

**Step 3. Treat every interface as a SOUP or a software item.** If the protocol implementation comes from open source, log it as SOUP. If it is custom code, log it as a software item under EN 62304. Either way it needs requirements, verification, and traceability.

**Step 4. Run robustness tests on day one.** Malformed messages, wrong versions, network drops. If the device crashes or silently loses data, that is a design fix, not a test failure to be hidden.

**Step 5. Write the risk file as if the partner system is hostile.** Not because it is, but because the hazards are identical whether the partner is broken or malicious. This also feeds the cybersecurity risk analysis required under EN IEC 81001-5-1:2022.

**Step 6. Keep an interface change log.** Every time the partner system updates its protocol version, MDR expects a change impact assessment. A log saves months during audits.

## Reality Check

1. Can the team point to the exact sentence in the intended purpose that constrains which systems this device will be combined with, and has a Notified Body reviewer confirmed it?
2. Is there an interface specification for every inbound and outbound interface, version-controlled and traced to requirements?
3. Is there conformance evidence for each public protocol in use, independent of marketing claims?
4. Does the risk file contain hazards that can only arise when the device is connected, with controls and verification?
5. Has the device been tested against malformed, truncated, and out-of-version messages with documented pass criteria?
6. Is every third-party library implementing a protocol tracked as SOUP with a known vulnerability feed?
7. Is the cybersecurity file linked to the interoperability file, or do they live in separate silos?
8. If the partner system changes its version tomorrow, does the change control process trigger automatically, or does it rely on someone remembering?

## Frequently Asked Questions

**Does MDR require FHIR or HL7 specifically?**
No. MDR is protocol-neutral. Annex I §14.2(d) and §17.1 require safe and reliable interoperability with the systems the intended purpose covers, and state of the art software development. The choice of protocol is a manufacturer decision that has to be justified and verified.

**Does the device need to work with every EHR in Europe?**
Only if the intended purpose says so. A precise intended purpose that names the target integration environment limits the scope. A vague intended purpose that implies universal compatibility creates an obligation the manufacturer cannot fulfill.

**How does a Notified Body check interoperability claims?**
Auditors ask for interface specifications, conformance evidence, integration test reports, risk controls, and traceability. They look for gaps between marketing language and technical file content. Tibor has issued findings specifically for this mismatch.

**Is IHE profile compliance enough?**
Compliance with an IHE profile is useful evidence but not sufficient on its own. The manufacturer still has to show the interface has been verified inside the specific device context and that hazards from the combination have been addressed under EN ISO 14971:2019+A11:2021.

**Where does cybersecurity fit in?**
Every interoperability interface is a cybersecurity interface. EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 govern the security lifecycle. The interoperability and cybersecurity files should cross-reference, not duplicate.

**What changes when the protocol version updates?**
A protocol version change is a change under MDR Article 10(9) and has to be assessed for impact on conformity. For Notified Body supervised devices, some changes require prior approval. A clear interface change log makes that assessment fast.

## Related reading
- [Interoperability Requirements for Medical Software Under MDR](/blog/interoperability-medical-software-mdr) because that post goes deeper into the software-specific view of the same clauses.
- [MDR Annex I Section 17: Cybersecurity Requirements](/blog/mdr-annex-i-section-17-cybersecurity) because cybersecurity and interoperability share the same anchor clauses.
- [Cybersecurity for Connected IoT and IoMT Devices](/blog/cybersecurity-connected-iot-iomt) because most connected medical devices live inside an IoMT context.
- [SOUP and Off-the-Shelf Software Under MDR](/blog/soup-ots-software-mdr) because protocol libraries are typically SOUP.
- [Software Integration Testing Under IEC 62304](/blog/software-integration-testing-iec-62304) because that is where interface evidence is generated.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Chapter II §14.2(d); Annex I Chapter II §17.1, §17.2, §17.4.
2. EN 62304:2006+A1:2015, Medical device software, Software lifecycle processes.
3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, Activities in the product lifecycle.
4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.
5. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices, December 2019, Rev.1 July 2020.

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*