I’ve spent the last five years arguing with testers, architects, and notified-body assessors about why a device “doesn’t work with the hospital network”. To be fair, network oddities happen — but in almost every case I’ve seen the root cause was a design and compliance gap we could have prevented.

Interoperability isn’t just an engineering exercise. Under the MDR it sits squarely inside your device’s safety and performance case (see Annex I, General safety and performance requirements). Practically, that means connectivity decisions belong in your Technical File from day one, not added as an afterthought at verification.

Why interoperability is more than APIs

When people say “interoperability” they usually mean three things at once:

• Data formats and semantics (HL7/FHIR, DICOM, device-specific payloads)
• Networking and transport (Wi‑Fi, BLE, TCP/IP, gateways)
• Operational behaviours (state machine, timeouts, retries, firmware updates)

A failure in any of these domains can become a safety issue. For example, a delayed message or a dropped firmware update can change device behaviour or clinical decisions. That immediately pulls ISO 14971 risk management and IEC 62304 software lifecycle workstreams into the picture.

In practice this means you must treat interoperability as a full risk item:

• Define intended connectivity scenarios in your intended use and user profiles
• Map hazards that specifically arise from network interactions
• Include mitigations for loss of connectivity, corrupted messages, and incompatible versions

What regulators and notified bodies actually look for

Across different notified bodies the questions vary, but the theme is consistent: “How do you know this will behave safely in the real environment?” Expect to show:

• A clear set of intended interoperability use cases in your IFU/labeling (Annex I)
• Traceable risk controls for each connectivity hazard (ISO 14971)
• Software architecture documentation showing how communication stacks are isolated and managed (IEC 62304)
• Cybersecurity risk assessment and patch/upgrade strategy (refer to MDCG guidance and IEC 81001‑5‑1 principles)
• Test matrices that include negative tests, flaky network tests, and version interoperability tests

Don’t be surprised if assessors ask for evidence of testing in “production-like” networks. Lab-only tests that assume perfect networks rarely satisfy them.

A practical checklist for your Technical File

I keep the following checklist in every connected-device Technical File. It’s concise enough for a reviewer and exhaustive enough for an audit.

Use-case and architecture

• Intended connectivity scenarios and user stories
• Network topologies considered (direct, via gateway, cloud)
• Software/SW-architecture diagram indicating communication layers

Risk and safety

• ISO 14971 hazard analysis items explicitly tying risk to connectivity
• Failure modes (e.g., message loss, replay, man-in-the-middle)
• Residual risk and rationale

Software & cybersecurity

• IEC 62304 software classification and V-model traceability
• Cybersecurity risk management file (threat model, mitigations, verification)
• Patch/upgrade policy and rollback strategy

Verification & validation

• Interoperability test matrix (protocols, versions, edge cases)
• Performance tests under degraded network conditions (latency, jitter)
• Usability testing for connectivity-related tasks (pairing, reconnection) per IEC 62366-1

Post-market

• PMCF/PMPF plan for connectivity incidents
• PSUR/SSCP items that monitor interoperable/failure modes
• Vulnerability disclosure and coordinated vulnerability response plan

How to operationalise this in your QMS

If your QMS treats connectivity as “just another feature”, you’ll pay in CAPAs later. Here’s what I change when I’m asked to harden a connected product:

• Make connectivity a distinct design control stream. Link requirements to architecture, tests, and risk items in one place (connected workflow). This prevents orphaned requirements that live only in Jira tickets.
• Use change impact analysis for network-related changes. A seemingly trivial firmware change can affect protocol behaviour — map that through design controls before release.
• Formalise supplier assurance for third-party stacks (Bluetooth stacks, cloud SDKs). Ask for evidence: CVE monitoring, security development lifecycle artefacts, and maintenance windows.
• Integrate incident handling with PMS. A security vulnerability can be a safety event; ensure your CAPA and vigilance triggers are aligned.
• Make traceability visible. In an audit I want to see a single trace from requirement → risk control → test → release. That reduces follow-up evidence requests and lowers audit friction.

If you use an eQMS, make these items native: traceability links, change impact mapping, and a CAPA workflow that includes cybersecurity and interoperability artefacts. Controlled assistance (AI-guided summaries, for example) is useful to surface gaps, but ensure reviewability and audit trails; regulators want to see human oversight.

A few pitfalls I keep seeing

• Treating “supported” interfaces as optional. If you ship with a GUI that exposes a connectivity setting, include it in usability and security testing.
• Ignoring version interoperability. Backward compatibility testing often gets cut; that’s when upgrades brick integrations in the field.
• Leaving vendor-supported cloud dependencies out of the Technical File. Cloud components that influence clinical behaviour are part of the device ecosystem.

Final thought

Interoperability and connectivity are systems problems, not feature checkboxes. Build them into your risk-management and software lifecycle artefacts from the outset, and your CAPA queue will thank you.

What connectivity failure have you seen in the field that could have been avoided with better design and traceability?