I started treating connectivity as another design activity the year we shipped our first device that talked to the hospital network. Not a bolt-on feature, but a whole set of new hazards, processes and supplier relationships. Five notified-body audits later I still think interoperability is the place where good engineering meets paperwork — and where most Technical Files quietly fail.
Below are the practical things I now insist on before a device with networked interfaces reaches a clinical site. These are grounded in the usual standards (IEC 62304, ISO 14971, IEC 62366-1) plus the MDR expectation that devices remain safe and perform as intended when used in the foreseeable clinical environment (Annex I — General Safety and Performance Requirements). I also draw on MDCG cybersecurity guidance when we discuss update and logging strategies.
Interoperability is a systems problem, not a feature
Interoperability failures rarely look like a single bug. They are emergent from:
- an interface spec that is incomplete or ambiguous,
- a supplier component that implements a subset of the protocol,
- hospital network quirks (firewalls, proxies, NAT),
- clinical workflows that assume synchronous responses,
- and software updates that change message formats.
In practice this means you must treat interoperability like integration testing plus risk management plus clinician observation. If you only test at unit level, you will be blind to the clinical consequences.
The minimum folder I expect in a Technical File
When the notified body asks for evidence, they are asking for reproducible assurance that the device will behave in the wild. My checklist (concrete, non-negotiable) that I keep ready for audits:
- Architecture and data flow diagrams
- Network topology, external systems, data paths, and trust boundaries.
- Interface Control Document (ICD) / API specification
- Message formats, transport layers, error handling, timeouts.
- Standards and profiles declared
- e.g. HL7/FHIR resources used, DICOM conformance statements, IHE profiles where applicable.
- Integration test reports
- System-level tests with at least two independent peer implementations where possible.
- Risk assessment tied to interface hazards
- ISO 14971 mitigations for lost packets, malformed messages, delayed communication.
- Cybersecurity controls and verification
- Authentication, encryption, secure update mechanism, logging, and tests per MDCG cybersecurity guidance.
- Clinical impact assessment
- How an interoperability failure affects patient management and what mitigations exist.
- IFU and deployment guidance
- Network configuration, recommended firewall rules, supported versions of third-party systems.
- Supplier evidence and agreements
- Conformance claims from suppliers, version support commitments, change-notice obligations.
If any of the above is missing, expect questions. Notified bodies rarely accept "we'll test it later" when real-world connectivity is core to device performance.
Tests that actually matter to auditors
Auditors like repeatability. The most persuasive evidence I present is:
- Integration matrix: rows = our release versions; columns = third-party partner versions; cells = pass/fail plus test scenario reference.
- Interoperability test scripts and logs: automated tests with captures of real messages (anonymised) and timestamps.
- Fault-injection reports: what happens if a message is malformed, a connection drops, or authentication fails.
- Update/rollback verification: secure update applied and rollback path validated.
- End-user acceptance scenarios: clinicians running scripted workflows while you observe metrics and failure modes.
In practice this means automating as much as you can. Manual testing scales badly when you support multiple versions of peers.
Where risk and cybersecurity collide
You cannot silo ISO 14971 from your cybersecurity work. A missed handshake or weak auth is both a security issue and a patient-safety issue if it leads to incorrect dosing, stale alarms, or lost images.
My approach:
- Map cybersecurity threats to device hazards in the same risk file.
- Use CWE/CVE references when a supplier component is implicated; include the supplier's mitigation plan.
- Treat secure update and logging as risk controls and evidence them (signed packages, verification tests, tamper-evident logs).
This is also where your QMS matters: supplier change notices need to trigger CAPA-driven risk assessment and traceability back to the Technical File. The faster you can map a supplier patch to impacted items in the Technical File, the easier an audit becomes.
Practical QMS tooling I rely on
You can do all of this with documents and folders — I have seen teams do it — but it is slow and brittle. The features that matter for connected-device work are:
- Traceability across design, risk, tests and IFU (so a change to an API shows which risks and tests are affected).
- Change impact analysis for supplier updates (so you can prioritise).
- Test evidence attachments and versioned integration matrices.
- PMCF workflows that include connected-device field performance and interoperability incidents.
- Controlled workflows for security patches and emergency CAPAs — reviewable, traceable, and auditable.
In other words: connected workflow, not disconnected checklists. Automated CAPAs or AI-assisted triage are useful if they remain reviewable and controllable.
A few hard lessons
- Equivalence claims for interfaces are fragile. Notified bodies will want proof that "equivalent" peer implementations actually exercise the same behaviours your device relies on.
- IFUs need network operational guidance. Auditors expect more than "requires network access" — they want the concrete steps an IT team needs to configure the environment.
- Field monitoring matters. Post-market surveillance must capture interoperability incidents and turn them into learnings. A single hospital misconfiguration can be a pattern indicator.
Final thought
Interoperability is where clinical realism meets regulatory rigour. Treat it as continuous assurance, not a pre-market checkbox. Invest in integration testing, in supplier agreements that include change-notice and version support, and in QMS traceability so you can show causality from a field incident back to a risk control.
How do you capture and present integration evidence for multiple peer versions without the file ballooning into chaos?
Top comments (0)