Data Act für vernetzte Medizinprodukte

Die EU-Datenverordnung, kurz Data Act, ist seit dem 11. Januar 2024 in Kraft und wird seit dem 12. September 2025 angewendet. Seither können Nutzer vernetzter Produkte verlangen, dass der Dateninhaber ihnen die Nutzungsdaten bereitstellt oder an einen benannten Dritten weitergibt – auch bei Geräten, die schon vorher im Feld standen. Zugleich muss vor Vertragsschluss klar sein, welche Daten ein Produkt erzeugt und wie sie abrufbar sind.

Am 12. September 2026 folgt die zweite Stufe: Vernetzte Produkte und zugehörige Dienste, die danach erstmals in Verkehr gebracht werden, müssen den Zugang schon durch ihre Gestaltung ermöglichen (Access by Design). Daten und Metadaten sollen standardmäßig, einfach, sicher, unentgeltlich und in einem strukturierten, gängigen, maschinenlesbaren Format bereitstehen – soweit relevant und technisch machbar auch direkt für den Nutzer. Nach Lesart der Kommission zählt jedes einzelne Gerät, nicht der Gerätetyp: Auch ein seit Jahren CE-gekennzeichnetes Modell ist betroffen, sobald ein Exemplar nach dem Stichtag erstmals in Verkehr gebracht wird.

Medizinprodukte sind ausdrücklich erfasst

Die Begründung der Verordnung nennt medizinische Geräte ausdrücklich, und laut den FAQ der Kommission gilt der Data Act auch für Produkte mit eigener Konformitätsbewertung. Ein Medizinprodukt muss also neben der MDR auch die Datenverordnung erfüllen, bevor es in Verkehr gebracht wird.

Wer ausgenommen ist

Kleinst- und Kleinunternehmen sind von den Zugangspflichten befreit, sofern sie nicht mit einem größeren Unternehmen verbunden oder als dessen Partner eingebunden sind und nicht im Auftrag eines anderen fertigen oder entwickeln. Mittlere Unternehmen erhalten nur eine Schonfrist von einem Jahr: im ersten Jahr, nachdem sie diese Größe erreicht haben, und für jedes Produkt im ersten Jahr nach dessen Inverkehrbringen. Unabhängig davon lassen sich die Zugangsrechte der Klinik nicht vertraglich zu ihrem Nachteil abbedingen; solche Klauseln binden sie nicht.

Warum das eine Sicherheitsfrage ist

Jede zusätzliche Schnittstelle vergrößert die Angriffsfläche. In der BSI-Studie ManiMed von 2020 wurden zu zehn vernetzten Medizinprodukten aus fünf Kategorien mehr als 150 Schwachstellen gemeldet – häufig in der begleitenden Infrastruktur, selten im Medizinprodukt selbst. Genau dort entstehen Portale, Programmierschnittstellen und Cloud-Ablagen für den Datenzugang. In Deutschland drohen bei Verstößen gegen Gestaltungs- oder Bereitstellungspflicht Bußgelder bis 500.000 Euro; zuständige Behörde ist seit dem 30. Mai 2026 die Bundesnetzagentur.

Zwei Feinheiten zählen: Auftragsverarbeiter im Sinne der DSGVO sind keine Dateninhaber – das betrifft Cloud-Anbieter ebenso wie den Hersteller, soweit er Patientendaten ausschließlich nach Weisung der Klinik verarbeitet. Und nicht personenbezogene Gerätedaten darf der Hersteller für eigene Zwecke wie Produktverbesserung nur auf Grundlage eines Vertrags mit der Klinik nutzen; wie weit das gesetzlich geforderte Auswertungen der Marktbeobachtung berührt, ist im Einzelfall zu klären.

Welche Daten erfasst sind

Erfasst sind Roh- und vorverarbeitete Daten, die ohne unverhältnismäßigen Aufwand verfügbar sind, samt Metadaten sowie Status- und Fehlermeldungen. Was erst durch zusätzliche Investitionen wie komplexe proprietäre Algorithmen entsteht, fällt grundsätzlich nicht darunter, sofern nichts anderes vereinbart ist – eine Ausnahme, die nur aus der Begründung der Verordnung folgt und Graubereiche lässt. Pseudonymisierung oder Verschlüsselung machen Daten nicht zu abgeleiteten. Lücken im Schutz des Geräts auszunutzen, ist kein zulässiger Weg zu den Daten.

Das Referenzmodell besteht aus vier Bausteinen: Ein bildgebendes Diagnosegerät liefert Bilder und Messwerte. Eine Planungssoftware leitet daraus Therapieparameter ab, die ärztliches Personal prüft und freigibt. Ein Therapiegerät führt den freigegebenen Plan aus und zeichnet den Ablauf auf. Hinzu kommt eine Hersteller-Cloud mit getrennten Mandanten je Klinik, Benutzerverwaltung, Updatebereitstellung und einem Webportal samt Programmierschnittstelle (Application Programming Interface, API).

Zwei Gestaltungsgrundsätze sind in solchen Systemen verbreitet: Die Verbindung zur Cloud wird aus der Klinik heraus aufgebaut, sodass keine eingehenden Zugänge aus dem Internet nötig sind, und die Cloud ist so entkoppelt, dass sie in eine laufende Therapie nicht eingreifen kann. Zur Datentür im Sinne des Data Act gehören in diesem Modell:

• das Webportal zum Einsehen und Herunterladen
• die API für automatisierte Abrufe durch Systeme der Klinik
• Exportpfade für umfangreiche Datenpakete
• eine Delegationsfunktion, über die die Klinik Dritte als Empfänger benennt
• gegebenenfalls ein lokaler Zugang am Gerät oder an einem Gateway

Direkter Zugang, bei dem die Klinik selbst abruft, oder indirekter Zugang, bei dem der Hersteller auf Anfrage bereitstellt – diese Designentscheidung hat Sicherheitsfolgen: Direkter Zugang braucht eine dauerhaft erreichbare, belastbar abgesicherte Schnittstelle, indirekter Zugang verlagert Risiken in manuelle Prozesse.

Ist der Cloud-Dienst selbst ein Medizinprodukt?

Das hängt von der Zweckbestimmung ab: Ein Dienst, der Daten nur speichert und weiterreicht, ist meist keine Medizinprodukte-Software; einer, der medizinisch auswertet oder Ergebnisse an die Planung zurückgibt, häufig schon. Begleitsoftware ohne Medizinproduktestatus, etwa eine installierbare Service- oder Export-Anwendung, kann im Einzelfall unter den Cyber Resilience Act fallen; reine Webdienste ohne zugehöriges Produkt erfasst er dagegen nicht.

Der Sicherheitsvorbehalt

Klinik und Hersteller können Zugang, Nutzung oder Weiterverbreitung von Daten vertraglich beschränken oder ausschließen, wenn die Datenverarbeitung gesetzlich festgelegte Sicherheitsanforderungen an das vernetzte Produkt untergraben und dadurch ernsthafte nachteilige Folgen für Gesundheit, Sicherheit oder Schutz von Menschen haben könnte. Bei Medizinprodukten kommen dafür vor allem die Cybersecurity-Vorgaben der MDR in Betracht – naheliegend, aber nicht ausdrücklich geregelt. Der Entwurf unverbindlicher Mustervertragsklauseln der Kommission, bislang nur in englischer Sprache, sieht optional vor, die konkrete Sicherheitsanforderung im Vertrag zu benennen.

Verweigert der Hersteller die Weitergabe, muss er die zuständige Behörde informieren – in Deutschland die Bundesnetzagentur über deren Formulare. Die Klinik kann sich dort beschweren oder eine Streitbeilegungsstelle anrufen. Im Referenzmodell ließe sich gut begründen, dass das Therapiegerät während einer laufenden Behandlung keine Live-Abfragen beantwortet und sicherheitskritische Konfigurationen nicht nach außen gehen. Schwer zu rechtfertigen wäre dagegen, der Klinik Fehler- und Ereignisprotokolle zum Lesen vorzuenthalten. Schreibenden Zugriff auf Planung oder Steuerung verlangt der Data Act ohnehin nicht.

Geschäftsgeheimnisse in drei Stufen

• Kennzeichnen und vereinbaren: Der Hersteller markiert Geschäftsgeheimnisse, auch in den Metadaten, und legt mit dem Empfänger Schutzmaßnahmen fest – etwa Vertraulichkeitsvereinbarungen, strenge Zugangsprotokolle, Normen oder Verhaltenskodizes.
• Zurückhalten oder aussetzen: Kommt keine Einigung zustande, werden vereinbarte Maßnahmen nicht umgesetzt oder wird die Vertraulichkeit verletzt, darf der Hersteller die Weitergabe zurückhalten oder aussetzen.
• Ablehnen: Nur unter außergewöhnlichen Umständen und im Einzelfall, wenn er anhand objektiver Kriterien nachweist, dass ihm trotz Schutzmaßnahmen sehr wahrscheinlich ein schwerer wirtschaftlicher Schaden entsteht.

In der zweiten und dritten Stufe ist die Entscheidung schriftlich zu begründen und der Behörde mitzuteilen. Werden Geheimnisse ohne Schutz offengelegt, kann zudem ihr Status nach dem Geschäftsgeheimnisgesetz leiden. Belastbare Begründungen für beide Handbremsen liefern Bedrohungsmodell und Risikoakte.

Was der Digital Omnibus ändern würde

Der Änderungsvorschlag „Digital Omnibus“ der Kommission vom November 2025 würde beim Geheimnisschutz einen weiteren Ablehnungsgrund schaffen, wenn ein hohes Risiko des Abflusses in Drittstaaten mit schwächerem Schutz besteht; den Sicherheitsvorbehalt lässt er unverändert. Beschlossen ist er nicht: Das Parlament hat nicht abgestimmt, und im Rat kam bis Mitte Oktober 2026 kein Verhandlungsmandat zustande – strittig ist unter anderem gerade der Geheimnisschutz.

DSGVO und ärztliche Schweigepflicht

Wo personenbezogene Daten betroffen sind, geht das Datenschutzrecht vor; eine eigene Rechtsgrundlage schafft der Data Act nicht. Ist die Klinik Nutzerin und die Patientin betroffene Person, braucht die Bereitstellung eine Rechtsgrundlage nach der DSGVO und bei Gesundheitsdaten zusätzlich eine der Ausnahmen für besondere Kategorien. Die Klinik bleibt in der Regel Verantwortliche, schuldet Datenschutz durch Technikgestaltung und benötigt für vernetzte Therapiesysteme meist eine Datenschutz-Folgenabschätzung.

Hinzu kommt die strafbewehrte ärztliche Schweigepflicht, die der Data Act nicht aufhebt. Patientendaten dürfen – sofern weder die Patientin entbunden hat noch eine gesetzliche Befugnis besteht – nur so weit an Dienstleister fließen, wie es nötig ist, und nur an solche, die im Auftrag der Klinik arbeiten und sich zur Vertraulichkeit verpflichtet haben. Eigene Auswertungszwecke des Herstellers sind davon nach unserer Einschätzung nicht gedeckt.

IEC 81001-5-1 verlangt für Gesundheitssoftware ein produktspezifisches Bedrohungsmodell, schreibt aber keine Methode vor. Ausgangspunkt ist ein Datenflussdiagramm des Gesamtsystems mit seinen Vertrauensgrenzen (Trust Boundaries). Mit dem Data Act entsteht zusätzlich eine Grenze zu externen Empfängern, die die Klinik auswählt. Am stärksten zu schützen bleibt die Grenze um das Therapiegerät. Die Leitlinie MDCG 2019-16 erwartet für vernetzte Produkte ohnehin eine vollständige Übersicht der Netzwerkdatenströme.

Die Methode STRIDE prüft jeden Datenfluss auf sechs Bedrohungsklassen: Identitätsvortäuschung (Spoofing), Manipulation (Tampering), Abstreitbarkeit (Repudiation), Offenlegung (Information Disclosure), Dienstverweigerung (Denial of Service) und Rechteausweitung (Elevation of Privilege). Ein Angriffsbaum zerlegt ergänzend ein Angreiferziel wie „manipulierte Planungsdaten erreichen das Therapiegerät“ in Teilschritte.

Bewerten und in die Risikoakte übernehmen

Für Systeme, deren Cloud viele Kliniken verbindet, empfiehlt die Cybersecurity-Leitlinie der US-amerikanischen Food and Drug Administration (FDA) vom Februar 2026 eine eigene Architektursicht auf Schäden bei vielen Patienten zugleich; Sicherheitsrisiken stuft sie nach Ausnutzbarkeit statt nach einer kaum schätzbaren Wahrscheinlichkeit ein. Bedrohungen mit möglicher Gefährdungsfolge werden als Ursachen in der Risikoakte nach ISO 14971 geführt. Kommen Schnittstellen oder neue Arten von Empfängern hinzu, ist das Modell zu aktualisieren.

Die MDR verwendet den Begriff Penetrationstest nicht. Die Leitlinie MDCG 2019-16 bezeichnet Testen jedoch als wichtigstes Mittel der Sicherheitsverifizierung und nennt ausdrücklich Tests der Sicherheitsfunktionen, Fuzzing mit fehlerhaften Eingaben, Schwachstellenscans und Penetrationstests. IEC 81001-5-1 fordert, dass die Prüfenden hinreichend unabhängig sind. Der Testumfang leitet sich aus Angriffsflächen, Systemgrenzen und den Szenarien des Bedrohungsmodells ab.

Prüfschwerpunkte an der Datentür

• Mandantentrennung: Mit Testzugängen für zwei Kliniken prüft das Team, ob sich über veränderte Kennungen fremde Datensätze abrufen lassen – fehlende Autorisierung auf Objektebene führt die OWASP API Security Top 10 von 2023 auf Platz eins.
• Anmeldung und Sitzungen in Portal und API, einschließlich Laufzeit, Bindung und Wiederverwendbarkeit von Zugriffstoken.
• Funktionsrechte: Lässt sich ein lesender Zugang zu Schreib- oder Steuerfunktionen ausweiten?
• Delegation an Dritte: Kann sich ein Angreifer als Empfänger eintragen oder den freigegebenen Datenumfang vergrößern?
• Exportpfade: Sind Datenpakete vollständig, korrekt pseudonymisiert und Geschäftsgeheimnisse gekennzeichnet?
• Eingabeverarbeitung: Wie reagieren API und Importfunktionen auf fehlerhafte oder bösartig präparierte Formate (Fuzzing)?
• Protokollierung: Werden Freigaben und Abrufe vollständig und manipulationssicher erfasst?
• Lastgrenzen und Entkopplung: Bleiben Planung und Gerätebetrieb bei massenhaften Abrufen verfügbar?

Rahmenbedingungen und Bericht

Geprüft wird als Grey-Box-Test mit Teilwissen über das System, mit synthetischen Datensätzen und in einer produktionsgleichen Umgebung – nie an einem Gerät im Patientenbetrieb. Der Bericht nennt, wie von der FDA erwartet, Unabhängigkeit, Umfang, Zeitraum, Methodik und Ergebnisse und begründet offen gebliebene Schwachstellen. Eingestuft wird nach Ausnutzbarkeit und möglicher Wirkung auf Patientinnen und Patienten; die Behebung läuft als Korrektur- und Vorbeugemaßnahme (Corrective and Preventive Action, CAPA) mit Nachtest und Ablage in technischer Dokumentation und Post-Market Surveillance. Regelmäßig wiederholt, belegt der Test auch die Wirksamkeit der Schutzmaßnahmen, die DSGVO und BSI-Gesetz verlangen.

An der Datentür treffen Data Act, MDR, DSGVO, BSI-Gesetz und Geschäftsgeheimnisgesetz aufeinander. Führen Regulatory Affairs, Informationssicherheit, Datenschutz und Recht getrennte Kataloge und Risikoskalen, fallen Widersprüche spätestens im Audit oder im Vorfall auf. Als Anker bietet sich das Qualitätsmanagementsystem nach ISO 13485 an, das Lieferanten, Risiken, Vigilanz und Änderungen bereits steuert. Weil ISO 13485 nicht der gemeinsamen Grundstruktur der übrigen ISO-Managementsystemnormen folgt, werden ISO/IEC 27001, ISO/IEC 27701 und gegebenenfalls ISO/IEC 42001 über eine Zuordnungstabelle angebunden.

Parallele Meldewege koordinieren

Ein Vorfall an der Datentür kann mehrere Meldepflichten zugleich auslösen, die ein Produkt-Sicherheitsteam (Product Security Incident Response Team, PSIRT) koordiniert: nach dem BSI-Gesetz 24 Stunden, 72 Stunden und ein Monat gegenüber der gemeinsamen Meldestelle von BSI und BBK; nach der DSGVO 72 Stunden gegenüber der Aufsicht, als Auftragsverarbeiter unverzüglich gegenüber der Klinik; nach der MDR 2, 10 oder 15 Tage, sofern ein schwerwiegendes Vorkommnis vorliegt. Setzt der Hersteller daraufhin Datenweitergaben aus, ist das der Bundesnetzagentur mitzuteilen; für Begleitsoftware können Meldungen nach dem Cyber Resilience Act hinzukommen.

Nach dem BSI-Gesetz verantwortet die Geschäftsleitung Umsetzung und Überwachung der Sicherheitsmaßnahmen. Die von der MDR vorgeschriebene Person für die Einhaltung der Regulierungsvorschriften (Person Responsible for Regulatory Compliance, PRRC) übernimmt nicht die Rolle der Beauftragten für Informationssicherheit oder Datenschutz; als Bindeglied bewährt sich eine Funktion für Produktsicherheit (Product Security). Benennt eine Klinik etwa einen KI-Dienst als Empfänger, lässt sich so in einem Durchgang klären, welche Daten fließen, auf welcher Rechts- und Vertragsgrundlage, mit welchem Restrisiko und mit welchem Beleg.

1. 1
   Betroffenheit klären

   Vernetzte Produkte und Dienste erfassen, KMU-Ausnahmen prüfen und die nach dem 12. September 2026 erstmals in Verkehr gebrachten Geräte bestimmen.

2. 2
   Datenkatalog erstellen

   Alle verfügbaren Produkt- und Dienstdaten erfassen und als bereitzustellende, abgeleitete, personenbezogene oder geheimhaltungsbedürftige Daten einordnen.

3. 3
   Informationspflichten erfüllen

   Angebote, Verträge und Gebrauchsanweisung so ergänzen, dass Art, Umfang, Format und Abrufweg der Daten vor Vertragsschluss klar sind.

4. 4
   Verträge vorbereiten

   Datennutzungsverträge für eigene Auswertungen sowie Klauseln zu Sicherheitsvorbehalt und Geheimnisschutz entwerfen; der Entwurf der Mustervertragsklauseln dient als Orientierung.

5. 5
   Datentür entwerfen

   Zugangsweg festlegen, Daten- und Steuerungsebene trennen, Mandantentrennung, Delegation und Protokollierung als Sicherheitsanforderungen spezifizieren.

6. 6
   Bedrohungsmodell fortschreiben

   Neue Vertrauensgrenzen und Datenflüsse mit STRIDE analysieren, sicherheitsrelevante Ursachen in die Risikoakte übernehmen und die Begründung der Handbremsen dokumentieren.

7. 7
   Testen und nachweisen

   Penetrationstest mit Fokus auf Autorisierung, Delegation und Exportpfade durchführen; Befunde über CAPA schließen und dokumentieren.

8. 8
   Änderung und Meldewege abstimmen

   Die Schnittstelle früh mit der Benannten Stelle besprechen und die Meldewege zu Bundesnetzagentur, BSI, Datenschutzaufsicht und Vigilanzbehörde in einem Planspiel üben.

Diese Seite gibt den Stand vom Oktober 2026 wieder. Sie ersetzt keine Rechtsberatung; Auslegungsfragen, insbesondere zur Abgrenzung abgeleiteter Daten und zum Umgang mit Altprodukten, sind im Einzelfall zu klären.