Vernetzte Medizinprodukte: Konnektivität, MDR-Cybersecurity und der OTA-Lebenszyklus

Die meisten modernen Medizinprodukte kommunizieren: Sie verbinden sich mit Telefonen, Gateways, Clouds und Klinikern, oft über dieselben Protokolle wie Unterhaltungselektronik. Vernetzte Medizinprodukte sind so in den letzten fünf Jahren von der Nische zum Standard geworden. Die regulatorischen und architektonischen Entscheidungen sind aber noch immer nicht eindeutig.

Das wirft eine Frage auf:
Wie entwirfst du ein vernetztes Medizinprodukt, das die MDR-Cybersecurity-Erwartungen erfüllt, unter realen Funkbedingungen hält und über seinen Lebenszyklus klinisch nützlich bleibt?

Dieser Leitfaden behandelt vernetzte Medizinprodukte als Schichtmodell: Funk, Protokoll, Backend und klinischer Workflow. Wir zeigen dir, was MDR Anhang I §17 bei der Cybersecurity verlangt, was die DSGVO für Patientendaten ergänzt und wo Teams in der Konnektivitätsschicht Budget verbrennen. Am Ende hast du ein belastbares Modell der Schichten, der Normen und der operativen Pflichten, die Konnektivität zusätzlich zur MDR mitbringt.

Inhaltsverzeichnis

Warum Vernetzte Medizinprodukte Anders Sind

Vernetzte Medizinprodukte teilen die meiste regulatorische Struktur mit jedem anderen Gerät unter MDR. Die Klassifizierungsregeln gelten, die Anforderungen an die technische Dokumentation gelten und die klinische Bewertung gilt genauso. So weit ist also noch nichts Eigenes dabei.

Drei Zusätzliche Regulatorische Schichten

Die Unterschiede entstehen in drei geschichteten Bereichen. Jeder bringt dabei eigene Normen, eine eigene Risikofläche und eigenes regulatorisches Gewicht mit:

Der Konnektivitäts-Stack selbst, von der Funkschicht bis zum Klinikportal.
Die Cybersecurity-Erwartungen, die der vernetzte Betrieb erfüllen muss.
Die Komplikationen im Lebenszyklus, sobald Software wireless übertragen wird.

Dasselbe Produkt trägt vernetzt also drei zusätzliche Verpflichtungen. Nimm zum Beispiel ein Wearable ohne App: eine gewöhnliche Produktform, klassifiziert nach Regel 9 oder Regel 10, mit der üblichen technischen Akte (mehr dazu in unserem Leitfaden zu den Risikoklassen für Medizinprodukte).

Kommen App, Cloud und die Rückführung von Daten an ein Klinikerportal hinzu, ändert sich alles. Dasselbe Produkt hat nun vier Schnittstellen zu validieren, vier Risikoflächen zu verteidigen und vier bewegliche Teile im Lebenszyklus.

-> In kurz: Der Wechsel von offline zu vernetzt legt drei Schichten über die Standard-MDR: den Konnektivitäts-Stack, die Cybersecurity-Fläche und den OTA-Lebenszyklus. Jede braucht eigene Designentscheidungen und ein eigenes Nachweispaket.

Was ist zu tun:

Halte zuerst den Konnektivitäts-Stack des Geräts fest, bevor du die Architektur festlegst.
Behandle Cybersecurity außerdem als Design-Vorgabe der Phase 1, nicht als Dokumentationsaufgabe der Phase 4.
Plane schließlich OTA und die Steuerung von Software-Änderungen von Anfang an ins QMS ein.

Der Konnektivitäts-Stack: vom Funk zum Kliniker

Ein vernetztes Medizinprodukt ist ein Stapel aus vier Schichten. Jede hat dabei eigene Normen, eine eigene Risikofläche und eigene Post-Market-Pflichten. Jede trägt beim Audit zudem ihr eigenes Nachweispaket.

Die Funkschicht

Die Funkschicht ist dort, wo das Gerät Bits sendet und empfängt. BLE dominiert dabei Wearables und stromsparende Sensoren, während NB-IoT und Mobilfunk in eigenständigen oder implantierbaren Produkten mit Flächenabdeckung auftauchen. Wi-Fi ist dagegen in klinikgebundenen Geräten verbreitet, LoRa dort, wo Reichweite vor Durchsatz geht.

Auch die EMV- und Frequenzregeln leben hier. IEC 60601-1-2 regelt die elektromagnetische Verträglichkeit für medizinische elektrische Geräte samt Funkschnittstelle, darüber liegen zudem regionale Spektrumsregeln (CE für die EU, FCC für die USA). Die Funkschicht beinhaltetet damit ein Power-Budget, eine Einsatzumgebung und ein dokumentiertes Profil der Signalzuverlässigkeit.

Die Protokollschicht

Über dem Funk sitzt das Datenprotokoll. MQTT, CoAP und BLE-GATT-Profile übernehmen dabei die Kommunikation von Gerät zu Gerät oder zur Cloud, während HL7 FHIR und IEEE 11073 die Interoperabilität medizinischer Daten mit Kliniksystemen regeln. Auch Pairing-Protokolle und OTA-Update-Kanäle leben in dieser Schicht.

Hier landet außerdem die Software-Sicherheitsklassifizierung: IEC 62304 setzt die Lebenszyklus-Erwartung für Medizinprodukte-Software auf Sicherheitsklasse A, B oder C. Die meiste Software vernetzter Geräte landet dabei bei B oder C (die Regel-11-Logik dahinter erklären wir im Beitrag zu Software als Medizinprodukt). In der Protokollschicht muss deshalb die Mechanik der Software-Änderungskontrolle definiert werden.

Die Backend-Schicht

Das Backend ist alles auf der Serverseite: ein Geräteregister, ein Datenspeicher, ein Authentifizierungsdienst, ein Event-Bus und die Integrationspfade in EHR- und Forschungsdatenbanken sitzen hier. Für die meisten Produkte kristallisieren sich hier zudem die DSGVO-Pflichten. Hier wird außerdem die ISO-27001-Ausrichtung zur Glaubwürdigkeitsfrage im in Bezug auf die Anwendung in der Klinik.

EN IEC 81001-5-1:2022 verankert die Cybersecurity-Erwartung dieser Schicht. Die Norm definiert dabei einen Cybersecurity-Lebenszyklus für Gesundheitssoftware samt Cloud- und Integrationskomponenten und gilt als aktueller Stand der Technik. Wer diese nicht anwendet, muss dafür seine Gleichwertigkeit bei der benannten Stelle begründen.

Die Klinische Workflow-Schicht

An der Spitze des Stapels steht der Anwender, also Arzt. Vernetzte Medizinprodukte landen nämlich in einem klinischen Kontext: einem Portal, einer Alarm-Weiterleitung, einem Eskalationspfad und oft einer Integration in die elektronische Patientenakte. Entscheidungsunterstützung, Risikoschwellen und Bereitschafts-Routing gehören heir dazu.

Diese Schicht trägt außerdem die klinische Bewertung. MDCG 2020-13 setzt hier die Erwartung: Nachweis von Sicherheit und Leistung in der Zweckbestimmung, mit Rückverfolgbarkeit durch jede darunterliegende Schicht. Wo die Konnektivitätsschicht klinische Entscheidungen beeinflusst, müssen Nachweise folgen.

-> In kurz: Die vier Schichten (Funk, Protokoll, Backend, klinischer Workflow) tragen je eigene Normen und Risikoflächen. Auditfeste Evidenz musst du deshalb pro Schicht nachführen.

Was ist zu tun:

Diagrammiere zuerst den Stack vor jeder Sprint-Planung und markiere Funk, Protokolle und Normen je Schicht.
Bilde außerdem jede Schicht auf ihre Norm ab (IEC 60601-1-2, IEC 62304, EN IEC 81001-5-1, MDCG 2020-13).
Binde schließlich die technische Akte an den Stack, damit die Rückverfolgbarkeit pro Schicht hält.

MDR-Cybersecurity-Erwartungen für Vernetzte Geräte

Cybersecurity wiegt unter MDR schwerer, als die meisten Teams erwarten. Drei Dokumente legen dabei den Standard fest.

Anhang I §17 im Klartext

MDR Anhang I §17 setzt die grundlegenden Sicherheits- und Leistungsanforderungen speziell für Produkte mit Software. Hier wird vom Hersteller verlangt, Prinzipien von Entwicklungslebenszyklus, Risikomanagement, Verifizierung und Validierung anzuwenden und Mindestanforderungen an Hardware, IT-Netze und IT-Sicherheit festzulegen. Anhang I §17 ist damit die rechtliche Grundlage.

Der Wortlaut ist kurz aber die operativen Folgen sind es nicht. Die Umsetzungserwartungen kommen deshalb aus MDCG 2019-16 und EN IEC 81001-5-1:2022.

MDCG 2019-16 und IEC 81001-5-1

MDCG 2019-16 ist die Arbeitsguidance für Cybersecurity bei Medizinprodukten. Sie definiert dabei drei Domänen: allgemeine Prinzipien wie Security-by-Design und Defence-in-Depth, Cybersecurity-Prozesse wie das Sicherheits-Risikomanagement und technische Spezifikationen. Die meisten Beiträge zum Thema zitieren nur sie als Rahmen.

EN IEC 81001-5-1:2022 ist dagegen das zu selten zitierte Dokument. Es ist der aktuelle Stand der Technik für den Cybersecurity-Lebenszyklus von Gesundheitssoftware und gilt für alle Komponenten samt Cloud und Integration.

-> In kurz: Die Cybersecurity-Erwartungen unter MDR laufen von Anhang I §17 über MDCG 2019-16 bis EN IEC 81001-5-1:2022. Gerade die dritte Norm wird dabei meistens unterschätzt.

Was ist zu tun:

Erstelle zuerst in Phase 1 ein Bedrohungsmodell und ein Diagramm der Sicherheitsarchitektur.
Entscheide außerdem, ob EN IEC 81001-5-1:2022 gilt (meist ja) und dokumentiere die Grundlage.
Führe schließlich eine SBOM und eine Cybersecurity-Bewertung der Zulieferer parallel zum QMS.

Daten, Interoperabilität und die DSGVO-Ebene

Konnektivität bewegt Daten. Und wo Daten fließen, folgen die Vorschriften gleich mit.

DSGVO für Daten Vernetzter Geräte

Patientendaten, die durch ein vernetztes Medizinprodukt fließen, gelten meist als besondere Kategorie personen-bezogener Daten nach DSGVO Artikel 9. Der Hersteller ist damit neben dem Gesundheitsdienstleister, der das Gerät betreibt, Verantwortlicher dieser Daten. Beide Rollen bringen deshalb Pflichten zu Rechtsgrundlage, Transparenz, Datenminimierung und Meldung von Verletzungen.

Die praktischen Folgen für die Backend-Schicht sind konkret. Datenspeicherung in der EU ist dabei für viele Mitgliedsstaaten relevant. Aus vier weiteren Punkten werden zudem auditierte Designentscheidungen:

Pseudonymisierung der Datensätze, wo immer der Zweck es zulässt.
Verschlüsselung im Ruhezustand für alle gespeicherten Patientendaten.
Verschlüsselung bei der Übertragung über jede Schnittstelle.
Zugriffsprotokollierung, die nachweisbar und auswertbar bleibt.

Interoperabilitätsstandards

HL7 FHIR ist der moderne Interoperabilitätsstandard für den Austausch von Gesundheitsdaten: Die meisten EHR in der EU und den USA unterstützen FHIR nativ oder über ein Gateway. Integrationsprojekte mit der Klinik-IT setzen es zudem zunehmend voraus. Wo FHIR nicht ausreicht, deckt zudem IEEE 11073 die Semantik der Gerätekommunikation ab.

Auch Interoperabilität ist reguliert: Artikel 19 der MDR verlangt vom Hersteller, eine UDI zu vergeben und das Gerät in EUDAMED zu registrieren. Die Datenstrukturen dahinter setzen zudem bestimmte Standards voraus. Eine anfangs unbedachte Wahl der Protokollschicht zeigt sich deshalb später in der technischen Akte als Lücke.

-> In kurz: DSGVO und Interoperabilität stehen bei vernetzten Produkten neben der MDR. Beide prägen dabei schon in Phase 1 die Entscheidungen zu Backend und Protokoll.

Was ist zu tun:

Kläre zuerst den Status als Verantwortlicher oder gemeinsam Verantwortlicher mit dem Gesundheitsdienstleister, bevor du startest.
Setze außerdem für die Klinik-Interoperabilität standardmäßig auf FHIR und dokumentiere die Begründung.
Bilde schließlich die Datenflüsse durchgängig ab, damit dein Verzeichnis nach DSGVO Artikel 30 Bewertungsfest ist.

Wo Konnektivität Echten Klinischen Nutzen Bringt

Konnektivität sollte denn Alltag in der Klinik verbessern. Der Nutzen eines vernetzten Medizinprodukts kommt daher, was die Verbindung ermöglicht: Fernüberwachung, Nachweise aus der realen Welt, planbare Software-Updates und die Integration in den Workflow von Ärzten.

Fernüberwachung und Real-World-Evidenz

Fernüberwachung ist der etablierteste Anwendungsfall. Geräte streamen dabei Vitalwerte oder Gerätezustände zwischen den Besuchen an ein Ärzteportal und zeigen Trends auf, die sonst einen ambulanten Termin zur Erkennung bräuchten (genau solche Wearables für das medizinische Monitoring bauen wir). Ab Klasse IIa fließt der Monitoring-Strom zudem über den PMCF-Plan in die klinische Bewertung zurück.

PMCF für vernetzte Medizinprodukte kann als strukturiertes Register der gerätegenerierten Daten laufen. Der Hersteller führt dazu Sensorwerte, Alarmereignisse und Interventionsergebnisse in eine definierte Aktualisierungs-Taktung. Konnektivität liefert damit die klinische Evidenzschleife direkt.

OTA-Updates und der Post-Market-Lebenszyklus

Software-Updates über die Luft sind der operative Lohn von Konnektivität. Fehlerbehebungen, Sicherheits-Patches und schrittweise Algorithmus-Verbesserungen erreichen dabei die installierte Basis ohne Rückruf oder Servicebesuch, sofern OTA-Kanal und Änderungskontrolle im QMS sitzen. Gut gemacht ist OTA so der operative Unterschied zu einem Altgerät mit USB-Anschluss.

Schlecht gemacht wird OTA dagegen zum Weg in eine notwendige, erneute Bewertung. Behandle den OTA-Kanal deshalb als reguliertes Subsystem, mit signierten Images, Secure Boot, Rollback und einem dokumentierten Änderungsprozess für jeden Release.

-> In kurz: Konnektivität trägt ihr Gewicht, wenn sie Fernüberwachung, RWE-Rückfluss in den PMCF und disziplinierte OTA ermöglicht. Jedes davon trägt dabei seinen eigenen Audit-Trail.

Was ist zu tun:

Lege zuerst fest, welche klinischen Ergebnisse die Konnektivität verbessern soll, bevor die Architektur steht.
Binde außerdem den Monitoring-Strom mit benannten Datenpunkten und Taktung an den PMCF-Plan.
Baue schließlich OTA von Anfang an als QMS-gesteuerten Prozess mit signierten Images und Rollback.

Fehler, die wir Häufig bei Vernetzten Medizinprodukten Sehen

Über die vernetzter Medizinprodukte hinweg, an denen wir gearbeitet haben, tauchen fünf Fehlermuster öfters auf. Alle lassen sich aber mit ein paar konkreten Gewohnheiten vermeiden.

1. Pairing-UX als Nachträglicher Einfall

Das Patienten-Pairing wird oft für den Ingenieur entworfen, statt für die 75-jährige Patientin, die es nutzt. Das Ergebnis sind hohe Abbruchraten beim Onboarding, wiederholte Support-Anrufe und verlorene Datentage, an denen das Gerät ungepaart in der Schublade liegt.

Lösung: Führe deshalb einen Usability-Test mit der echten Zielgruppe in Phase 2 durch, bevor die Pairing-UX festgelegt wird.

2. Signalzuverlässigkeit zu Wenig Getestet

BLE funktioniert auf dem Labortisch und versagt im Klinikflur, wo 200 andere 2,4-GHz-Funker konkurrieren. Tests der Signalzuverlässigkeit in der echten Einsatzumgebung werden dabei oft ausgelassen oder zu spät gefahren.

Lösung: Validiere deshalb Reichweite, Signal-Rausch-Verhältnis und Paketverlust in der echten Einsatzumgebung, nicht nur im Labor.

3. Fehlende OTA-Update-Governance

Software-Updates gehen über die Luft, ohne dokumentierten Änderungsprozess im QMS. Die benannte Stelle fragt dann, wie Versionen verfolgt, wie der Rollback-Pfad definiert und wie die klinische Wirkung je Release bewertet wird.

Lösung: Entwirf OTA deshalb als QMS-gesteuerten Prozess mit signierten Images, Änderungsklassifizierung und einem Release-Register ab dem ersten Build.

4. Cybersecurity als Phase-4-Denken

Bedrohungsmodell, Secure Boot, Schlüsselverwaltung und Sicherheitsarchitektur tauchen erst als Dokumentation zur Einreichung auf. MDR Anhang I §17, MDCG 2019-16 und EN IEC 81001-5-1:2022 erwarten aber Security-by-Design ab Woche eins.

Lösung: Baue deshalb Bedrohungsmodell, Sicherheitsarchitektur und SBOM in Phase 1, parallel zum QMS-Gerüst und zur Risikoakte.

5. Backend als Blackbox

Cloud und Daten-Backend stehen außerhalb der technischen Akte. Beim Audit fragt die benannte Stelle dann nach Nachweisen zu Datenresidenz, Zugriffskontrollen, Verschlüsselung und Integrationstests, doch es gibt keine Spur.

Lösung: Nimm das Backend deshalb in den Umfang der technischen Akte auf, mit eigener Architekturbeschreibung, Bedrohungsmodell und Verifizierungsnachweis.

-> In kurz: Die fünf Fehlermuster sind einzeln vermeidbar. Tödlich werden sie erst, wenn sich bei einem Build zwei oder drei davon parallel ansammeln.

Fazit

Vernetzte Medizinprodukte sind die Standardrichtung in der MedTech. Die Arbeit, sie sicher, verteidigbar und klinisch nützlich zu machen, ist strukturell größer als bei Offline-Geräten, aber gut definiert: Der Stack, der Cybersecurity-Rahmen, die DSGVO-Ebene und der Post-Market-Lebenszyklus sind in Normen und Guidance dokumentiert. Teams, die die Konnektivitätsschicht als Design-Vorgabe der Phase 1 behandeln, erreichen die Zertifizierung deshalb mit planbaren Zeitplänen.

Wenn du an irgendeiner Stelle eines vernetzten Builds ein zweites Paar Augen auf den Konnektivitäts-Stack, die Cybersecurity-Architektur, das DSGVO-Setup oder die OTA-Governance wünschst, dann ist genau das die Arbeit, für die unsere Medizintechnikprodukt-Entwicklung existiert.

FAQs zu Vernetzten Medizinprodukten

Q1: Wie werden vernetzte Medizinprodukte unter MDR klassifiziert?

A1: Die Klassifizierung folgt denselben Regeln aus Anhang VIII wie bei jedem anderen Medizinprodukt. Zweckbestimmung, Art des Risikos und der Kontakt mit dem Körper oder mit Vitalfunktionen bestimmen dabei die Klasse. Für Software-Komponenten gilt zudem Regel 11. Die meiste Entscheidungsunterstützung oder Monitoring-Software landet dann in Klasse IIa oder höher. Die Konnektivität selbst ändert die Klasse nicht, sie bringt aber meist Klasse-IIa-Erwartungen an den Software-Stack.

Q2: Welche Cybersecurity-Normen gelten für ein vernetztes Medizinprodukt?

A2: Drei Dokumente definieren den Arbeitsrahmen. MDR Anhang I §17 setzt zuerst die rechtliche Erwartung. MDCG 2019-16 liefert dann die operative Guidance mit drei Domänen: allgemeine Prinzipien, Prozesse und technische Spezifikationen. EN IEC 81001-5-1:2022 deckt schließlich den Cybersecurity-Lebenszyklus von Gesundheitssoftware ab und ist der Stand der Technik, den benannte Stellen erwarten oder zu dem eine Gleichwertigkeit zu begründen ist.

Q3: Braucht ein vernetztes Gerät eine benannte Stelle, wenn es offline Klasse I wäre?

A3: Nicht sterile und nicht messende Klasse-I-Geräte sind selbst zertifiziert, unabhängig von der Konnektivität. Die meisten vernetzten Medizinprodukte enthalten aber Software, die unter Anhang VIII Regel 11 fällt, was die Software und damit das Produkt auf Klasse IIa oder höher hebt. Ab Klasse IIa ist dann ein Audit von QMS und technischer Dokumentation durch eine benannte Stelle nötig.

Q4: Dürfen Software-Updates ohne Neuzertifizierung über die Luft kommen?

A4: Ja, wenn OTA-Kanal, Änderungsprozess und Änderungsklassifizierung im QMS definiert und mit MDCG 2020-3 zu wesentlichen Änderungen vereinbar sind. Updates, die Zweckbestimmung, Leistungsaussagen oder Risikoprofil ändern, sind dagegen wesentlich und lösen eine erneute Einreichung aus. Fehlerbehebungen, Sicherheits-Patches und kleine Verbesserungen innerhalb der bestehenden Dokumentation tun das meist nicht.

Q5: Welche Funktechnik passt für ein vernetztes Medizinprodukt?

A5: Das hängt von Strombudget, Reichweite und Einsatzort ab. BLE passt zu Wearables und stromsparenden Sensoren am Körper, NB-IoT und Mobilfunk zu eigenständigen oder implantierbaren Geräten mit Flächenabdeckung. Wi-Fi passt dagegen zu klinikgebundenen Geräten mit Stromversorgung, LoRa dort, wo Reichweite wichtiger ist als Durchsatz. Wichtig ist vor allem, die Wahl früh gegen IEC 60601-1-2 und die regionalen Spektrumsregeln zu prüfen.

Q6: Wer ist bei einem vernetzten Gerät nach DSGVO verantwortlich?

A6: Meist teilen sich Hersteller und Gesundheitsdienstleister die Verantwortung. Fließen Patientendaten durch dein Backend, bist du oft Verantwortlicher oder gemeinsam Verantwortlicher nach DSGVO Artikel 9, weil es sich um besondere Kategorien personenbezogener Daten handelt. Beide Rollen tragen dann Pflichten zu Rechtsgrundlage, Transparenz, Datenminimierung und Meldung von Verletzungen. Kläre die Rollenverteilung deshalb vertraglich, bevor das Gerät live geht.

Q7: Muss das Cloud-Backend in die technische Dokumentation?

A7: Ja. Sobald Cloud, Datenspeicher und Integrationspfade Teil der Zweckbestimmung oder der Sicherheit sind, gehören sie in den Umfang der technischen Akte. Die benannte Stelle erwartet dazu eine Architekturbeschreibung, ein Bedrohungsmodell, Nachweise zu Datenresidenz und Zugriffskontrollen sowie Integrationstests. Ein Backend als Blackbox außerhalb der Akte ist einer der häufigsten Audit-Findings bei vernetzten Geräten.