I’ve owned the regulatory side of several Class IIa/IIb connected devices. The technical novelty never worried me as much as the regulatory choreography: clinical risk that appears only when your device talks to hospital systems, software updates that silently change behaviour, and notified-body requests that treat “interoperability” as a full-scope feature, not an optional nice-to-have. To be fair, the regulatory focus is correct — connectivity expands the harm envelope. In practice this means your Technical File must treat interoperability as a product feature, with the same rigour as hardware safety or software verification.
Why regulators care (short version)
- Connected devices create new hazard pathways: network attacks, data corruption, unexpected clinical workflows.
- Interoperability failures show up at scale: a single erroneous message can affect many patients.
- Regulators and notified bodies expect evidence you considered these hazards and designed mitigations into the device and processes.
Genau: this is about safety and continuous assurance, not just one-off testing.
Standards and artefacts you will actually need
Don’t confuse “standards bingo” with readiness. The core references I use when preparing a Technical File and responding to NB questions are:
- ISO 14971 — risk management, explicitly including system-level risks introduced by connectivity.
- IEC 62304 — software lifecycle; include your architecture, S/W safety classes and V&V evidence.
- IEC 62366-1 — usability, because human-system interfaces change when systems interoperate.
- IEC 81001-5-1 (cybersecurity guidance for health software) and organisation-level cybersecurity policies.
- Communication/interop specs (FHIR/HL7, DICOM, proprietary APIs) — provide protocol conformance evidence and test reports.
- SBOM (software bill of materials) and vulnerability management records — increasingly asked for in audits.
What notified bodies typically ask for (and what I prepare)
From the audits I’ve been through, expect these concrete requests:
- System architecture diagram showing interfaces, trust boundaries, and data flows.
- Threat model and cybersecurity risk assessment mapped to ISO 14971 risks.
- Test reports: protocol conformance, fuzzing/negative tests, and integration tests with target systems (or documented test harnesses/emulators).
- Penetration-test summary and remediation plan; and evidence of follow-up verification.
- Software update/SOTA (secure over-the-air) policy, rollback and integrity verification tests.
- SBOM and supplier attestations for third-party components.
- Clinical evaluation addressing connected use-cases and a PMCF plan that monitors connectivity-related incidents.
- Traceability matrix mapping requirements → risks → mitigations → test cases. If you lack one of these artefacts, the NB will either ask for it or place heavy conditions on your certification.
Common pitfalls I've seen (so ist das halt)
- Assuming the hospital network will make your device safe. Networks vary; you must design assuming hostile or misconfigured networks.
- Equivalence claims for third-party modules that lack public verification evidence. Notified bodies push back hard here.
- Testing only “happy path” interactions. You need negative tests and state-recovery scenarios.
- No documented update/rollback testing. A patch that breaks interoperability is a legitimate field hazard.
- Fragmented traceability. If a connectivity CAPA starts in support tickets but isn’t linked to your risk file and design change records, auditors will flag it.
Practical checklist for your Technical File (copy-paste friendly)
- Architecture diagrams and interface specifications.
- Risk assessment including network-related hazards and mitigation traceability.
- Cybersecurity policy, threat model, and penetration-test report with remediation evidence.
- SBOM and supplier cybersecurity assessments.
- Interoperability and integration test reports (including negative tests).
- Software lifecycle evidence (IEC 62304): requirements, design, unit/integration/system tests.
- Clinical evaluation addressing connected scenarios and PMCF plan that tracks connectivity incidents.
- Update policy, verification of update mechanism, and logs/audit-trail evidence.
- Traceability matrix linking all of the above.
How your QMS can make this bearable
Connected devices create change — firmware updates, protocol tweaks, CVE patches. Your QMS must treat these as expected ongoing activities:
- Use change impact analysis that includes “communication interfaces” and downstream system dependencies.
- Link CAPAs to risk-file amendments and verification tasks — automated CAPAs are handy when you need to enforce a follow-up test after an update.
- Maintain a reviewable, traceable record of supplier security attestations and SBOM updates.
- Make the PMS/PSUR workflow native: connect your vigilance reports to your cybersecurity incident-response so field incidents trigger risk re-evaluation automatically.
A connected workflow that keeps traceability and reviewability front-and-centre reduces audit friction. To be explicit: this is not magic; it's process automation that prevents missed links between an incident report and a design change.
Final practical tip
Plan for interoperability tests early. Emulators and test harnesses save expensive hospital-integration time and make your NB comfortable with scope-limited external testing. And do the negative tests — recovery from malformed inputs, reconnection after network disruption, and update failures. Not glamorous, but auditors notice the gaps.
What interoperability or connectivity evidence did your notified body ask for that surprised you — and how did you close the gap?
