Software im medizinischen Umfeld

Die sichere Integration von Patientendaten in Software erfordert mehrere Maßnahmen. Zunächst ist die Einhaltung der Datenschutz-Grundverordnung (DSGVO) unerlässlich, um die rechtlichen Anforderungen zu erfüllen. Zudem sollten Datenverschlüsselung und sichere Authentifizierungsverfahren implementiert werden, um unbefugten Zugriff zu verhindern. Regelmäßige Schulungen des Personals zu Datenschutzbestimmungen und Sicherheitsprotokollen sind ebenfalls wichtig.

Praxen können den Schutz von Daten im Cloud-Umfeld durch verschiedene Maßnahmen gewährleisten. Dazu gehören die Auswahl eines vertrauenswürdigen Cloud-Anbieters, der die Einhaltung von Datenschutzstandards garantiert. Zudem sollten Daten durch Verschlüsselung gesichert und regelmäßige Backups erstellt werden. Die Schulung des Personals im Umgang mit sensiblen Daten ist ebenfalls entscheidend.

Die Häufigkeit von Software-Updates in Praxen hängt von verschiedenen Faktoren ab, einschließlich der Art der Software, der Sicherheitsanforderungen und der Empfehlungen des Herstellers. Generell wird empfohlen, Updates regelmäßig, mindestens jedoch einmal pro Monat, durchzuführen. Kritische Sicherheitsupdates sollten sofort installiert werden, um potenzielle Risiken zu minimieren. Eine regelmäßige Überprüfung der Software auf Updates ist ebenfalls ratsam.

Bei der Auswahl von Medizinsoftware achten Praxen auf verschiedene Faktoren, die die Effizienz und Sicherheit der Patientenversorgung beeinflussen. Dazu gehören die Benutzerfreundlichkeit der Software, die Einhaltung gesetzlicher Vorschriften sowie die Integration in bestehende Systeme. Auch die Datensicherheit und der Support des Anbieters sind entscheidend. Zudem spielt die Anpassungsfähigkeit der Software an spezifische Praxisbedürfnisse eine wichtige Rolle.

ISO 27001 spielt eine entscheidende Rolle im Cloud-Umfeld von Medizinsoftware, da sie einen Rahmen für das Management von Informationssicherheit bietet. Diese Norm hilft dabei, Risiken zu identifizieren und zu steuern, die mit der Speicherung und Verarbeitung sensibler Gesundheitsdaten in der Cloud verbunden sind. Durch die Implementierung von ISO 27001 können Unternehmen sicherstellen, dass sie die erforderlichen Sicherheitsmaßnahmen ergreifen, um die Vertraulichkeit, Integrität und Verfügbarkeit von Daten zu gewährleisten. Dies ist besonders wichtig, um den gesetzlichen Anforderungen und den Erwartungen der Nutzer gerecht zu werden.

Software im medizinischen Umfeld unterliegt je nach Zweckbestimmung sehr unterschiedlichen Anforderungen. Dient sie der Diagnose oder Therapie, ist sie ein Medizinprodukt nach der EU-Verordnung 2017/745 und braucht ein Konformitätsverfahren. Reine Verwaltungssoftware für Termine und Dokumentation fällt in der Regel nicht darunter, unterliegt aber strengen Datenschutzanforderungen.

Sobald der Hersteller sie für einen medizinischen Zweck bestimmt – Diagnose, Überwachung, Behandlung oder Linderung von Krankheiten. Regel 11 der MDR ordnet Software, die Entscheidungen zu diagnostischen oder therapeutischen Zwecken liefert, mindestens der Klasse IIa zu. Reine Datenspeicherung, Archivierung oder Kommunikation ohne eigene Bewertung fällt nicht darunter.

Gesundheitsdaten dürfen nach Art. 9 DSGVO nur unter engen Voraussetzungen verarbeitet werden – in der Praxis meist gestützt auf die Behandlung selbst. Erforderlich sind Verschlüsselung, ein Rollen- und Rechtekonzept, lückenlose Protokollierung der Zugriffe und ein Auftragsverarbeitungsvertrag mit jedem Dienstleister. Zusätzlich bindet die ärztliche Schweigepflicht nach § 203 StGB auch externe Dienstleister.

Mehr als eine Datenschutzerklärung: ein Verzeichnis der Verarbeitungstätigkeiten, Verträge mit allen Dienstleistern mit Datenzugriff, ein Rollen- und Rechtekonzept, Zugriffsprotokollierung, ein Löschkonzept und die Verpflichtung aller Beteiligten zur Verschwiegenheit. Ab bestimmten Voraussetzungen kommt ein Datenschutzbeauftragter hinzu.

Grundsätzlich ja, unter engen Voraussetzungen: Auftragsverarbeitungsvertrag, gesonderte Verpflichtung nach § 203 StGB, Verarbeitung möglichst innerhalb der EU, Verschlüsselung und ein Rollenkonzept. Für bestimmte Bereiche der gesetzlichen Krankenversicherung bestehen zusätzliche Anforderungen an den Verarbeitungsort.

In der Schweiz gilt die Medizinprodukteverordnung (MepV) auf Grundlage des Heilmittelgesetzes; sie ist inhaltlich weitgehend an die europäische MDR angeglichen, ist aber eigenständiges Schweizer Recht. Seit dem 26. Mai 2021 gilt die Schweiz gegenüber der EU im Medizinproduktebereich als Drittstaat, weil das Abkommen über die gegenseitige Anerkennung nicht aktualisiert wurde. Welches Recht auf Verträge angewendet wird, steht hier: auf Anfrage.

Die MDR-Klasse ergibt sich nicht aus der Technik oder dem Vertriebsweg, sondern aus Zweckbestimmung und möglicher Auswirkung einer fehlerhaften Softwareinformation. Für viele Medizinsoftwareprodukte ist Regel 11 des Anhangs VIII maßgeblich: Je nach Entscheidungs- oder Überwachungsrisiko reicht die Einordnung von Klasse I bis III.

ISO 14971:2019 verlangt einen dokumentierten Risikomanagementprozess über den gesamten Produktlebenszyklus: Gefährdungen identifizieren, Risiken bewerten, Kontrollen umsetzen, Restrisiken beurteilen und Erkenntnisse aus Produktion und Marktbeobachtung zurückführen. Die Norm gibt keine allgemeingültige Risikoschwelle vor; der Hersteller muss objektive Akzeptanzkriterien festlegen.

IEC 62366-1:2015 mit Amendment 1:2020 fordert einen sicherheitsbezogenen Usability-Engineering-Prozess. Hersteller müssen Nutzungskontext, Nutzergruppen, kritische Bedienhandlungen und gefahrbezogene Nutzungsszenarien bestimmen, die Benutzeroberfläche iterativ prüfen und durch eine summative Evaluation belegen, dass verbleibende anwendungsbedingte Risiken vertretbar sind.

Die technische Dokumentation muss nach MDR-Anhang II die Zweckbestimmung, Produktbeschreibung, Entwicklung, Risikokontrollen und sämtliche Verifikations- und Validierungsnachweise nachvollziehbar zusammenführen; Anhang III ergänzt die Nachmarktbeobachtung. Für Software gehören insbesondere Version, Architektur, Anforderungen, Rückverfolgbarkeit, Tests, Cybersecurity, Gebrauchstauglichkeit und klinische Evidenz dazu.

Die klinische Bewertung ist nach Artikel 61 und Anhang XIV MDR ein geplanter, fortlaufender Prozess. Für Medizinsoftware werden Zweckbestimmung und klinische Aussagen in prüfbare Endpunkte übersetzt; anschließend sind valide klinische Zusammenhänge, technische Leistung und klinische Leistung mit ausreichender Evidenz zu belegen und während der Marktphase aktuell zu halten.

IEC 62304:2006+A1:2015 strukturiert Entwicklung und Wartung medizinischer Software in nachvollziehbare Lebenszyklusprozesse. Verifikation prüft schrittweise, ob Anforderungen, Architektur, Module und integriertes System korrekt umgesetzt wurden; die abschließende Validierung des fertigen Medizinprodukts für Zweckbestimmung und reale Nutzung liegt zusätzlich außerhalb des alleinigen Umfangs der Norm.

Jedes Update braucht eine dokumentierte Änderungsbewertung, die Zweckbestimmung, MDR-Qualifikation und -Klasse, Risiken, klinische Evidenz, Gebrauchstauglichkeit, Cybersecurity, Tests und UDI-Auswirkungen betrachtet. Ob eine Änderung „wesentlich“ ist, hängt vom regulatorischen Kontext ab; MDCG 2020-3 Rev. 1 behandelt ausdrücklich Legacy-Produkte in der Übergangsregel des MDR-Artikels 120 und ist nicht pauschal auf jedes MDR-Produkt übertragbar.

Die MDR verlangt Cybersecurity als Teil von Sicherheit und Leistung über den gesamten Lebenszyklus. Anhang I Nummer 17.2 fordert Softwareentwicklung nach dem Stand der Technik unter Einbezug von Risikomanagement, Informationssicherheit sowie Verifikation und Validierung; Nummer 17.4 verlangt Mindestanforderungen an IT-Umgebung, Netzwerke und Schutzmaßnahmen in den Herstellerinformationen. MDCG 2019-16 Rev. 1 und IEC 81001-5-1:2021 konkretisieren den sicheren Produktlebenszyklus.

HL7 bezeichnet eine Familie von Interoperabilitätsstandards; FHIR ist ein moderner Standard dieser Familie. Während HL7 Version 2 häufig ereignisbezogene Nachrichten zwischen Klinikanwendungen überträgt, bildet FHIR Informationen als typisierte Ressourcen ab und stellt sie beispielsweise über eine REST-Schnittstelle in JSON oder XML bereit. Wirkliche Interoperabilität entsteht erst durch gemeinsam festgelegte Profile, Terminologien, Identitäten und Tests.

Ein möglicher Sicherheitsvorfall muss sofort technisch gesichert und regulatorisch bewertet werden. Für Hersteller gelten nach MDR-Artikel 87 abgestufte Höchstfristen: grundsätzlich 15 Kalendertage für schwerwiegende Vorkommnisse, 10 Tage bei Tod oder unerwarteter schwerwiegender Gesundheitsverschlechterung und 2 Tage bei einer schwerwiegenden Gefahr für die öffentliche Gesundheit. Fehlende Details dürfen die fristgerechte Erstmeldung nicht verzögern.

Die ISO 13485 legt Anforderungen an ein Qualitätsmanagementsystem für die Entwicklung medizinischer Software fest. Dazu gehören die Dokumentation von Prozessen, Risikomanagement, Validierung und Verifizierung der Software sowie die Einhaltung von regulatorischen Vorgaben. Die Norm fordert eine kontinuierliche Verbesserung der Qualität und die Einbeziehung von Kundenfeedback. Zudem müssen alle relevanten Dokumente und Aufzeichnungen ordnungsgemäß geführt werden.

Die Zweckbestimmung einer medizinischen Software beschreibt klar und präzise, wofür die Software entwickelt wurde und welche spezifischen Funktionen sie erfüllt. Sie sollte die beabsichtigte Verwendung, die Zielgruppe sowie die medizinischen Indikationen umfassen. Eine gut formulierte Zweckbestimmung ist entscheidend für die Einhaltung regulatorischer Anforderungen und die Gewährleistung der Sicherheit und Wirksamkeit der Software. Es ist wichtig, dass die Zweckbestimmung verständlich und nachvollziehbar ist.

Eine Gesundheits-App wird nicht als Medizinprodukt eingestuft, wenn sie keine medizinischen Zwecke verfolgt oder keine diagnostischen, therapeutischen oder präventiven Funktionen hat. Apps, die lediglich allgemeine Gesundheitsinformationen bereitstellen oder das Wohlbefinden fördern, fallen in der Regel nicht unter die strengen regulatorischen Anforderungen für Medizinprodukte. Zudem ist die Absicht des Herstellers entscheidend: Wenn die App nicht zur Diagnose oder Behandlung von Krankheiten gedacht ist, gilt sie nicht als Medizinprodukt.

Die CE-Kennzeichnung einer Medizinsoftware erfordert mehrere Schritte, die sicherstellen, dass das Produkt den europäischen Richtlinien entspricht. Zunächst muss die Software klassifiziert werden, um die entsprechenden Anforderungen zu bestimmen. Anschließend sind eine Risikobewertung und die Erstellung der technischen Dokumentation erforderlich. Schließlich erfolgt die Konformitätsbewertung, gefolgt von der Erstellung einer EU-Konformitätserklärung und der Anbringung des CE-Zeichens.

Eine Benannte Stelle muss einbezogen werden, wenn Medizinprodukte oder Medizinsoftware in die höheren Risikoklassen eingestuft werden. Insbesondere Produkte der Klassen IIa, IIb und III erfordern eine Bewertung durch eine Benannte Stelle, um die Konformität mit den europäischen Vorschriften zu bestätigen. Diese Stellen sind für die Durchführung von Prüfungen und Bewertungen zuständig, die für die CE-Kennzeichnung notwendig sind.

Die UDI (Unique Device Identification) ist für Medizinsoftware relevant, die als Medizinprodukt klassifiziert ist. Hersteller müssen eine UDI für ihre Produkte erstellen und diese in der EUDAMED-Datenbank registrieren. EUDAMED dient der zentralen Erfassung von Informationen über Medizinprodukte, einschließlich ihrer UDI. Die Einhaltung dieser Pflichten ist entscheidend für die Marktüberwachung und Rückverfolgbarkeit von Medizinsoftware.

Die Überwachung nach dem Inverkehrbringen (Post-Market Surveillance, PMS) für Software erfordert eine systematische Planung, um die Sicherheit und Leistung des Produkts kontinuierlich zu gewährleisten. Zunächst sollten klare Ziele und Methoden zur Datensammlung definiert werden, einschließlich der Analyse von Nutzerfeedback und der Überwachung von Vorfällen. Zudem ist es wichtig, regelmäßige Bewertungen der gesammelten Daten durchzuführen, um potenzielle Risiken frühzeitig zu identifizieren und gegebenenfalls Maßnahmen zu ergreifen. Die Dokumentation aller Schritte ist entscheidend für die Nachverfolgbarkeit und Compliance.

Eine klinische Nachbeobachtung für Software ist erforderlich, wenn die Software als Medizinprodukt eingestuft wird und potenziell Risiken für die Patienten oder Benutzer birgt. Dies gilt insbesondere für Software, die in der Diagnose, Behandlung oder Überwachung von Patienten eingesetzt wird. Die Nachbeobachtung dient dazu, die Sicherheit und Wirksamkeit der Software im realen Einsatz zu überprüfen und gegebenenfalls Anpassungen vorzunehmen. Die genauen Anforderungen können je nach Klassifizierung des Medizinprodukts variieren.

Die Dokumentation von Abweichungen, Ursachen und Korrekturmaßnahmen erfolgt in der Regel in einem strukturierten Format, das die Identifikation, Analyse und Nachverfolgung dieser Elemente ermöglicht. Zunächst wird die Abweichung detailliert beschrieben, gefolgt von der Analyse der Ursachen, die zu dieser Abweichung geführt haben. Anschließend werden die festgelegten Korrekturmaßnahmen dokumentiert, um sicherzustellen, dass die Abweichung behoben wird und zukünftige Vorkommen vermieden werden. Diese Dokumentation ist entscheidend für die Qualitätssicherung und die Einhaltung von Normen.

Die IEC 62304 behandelt Open-Source-Komponenten und Software of Unknown Provenance (SOUP) als potenzielle Risiken im Software-Lebenszyklus. Bei der Verwendung solcher Komponenten ist eine sorgfältige Risikobewertung erforderlich, um die Sicherheit und Wirksamkeit des Endprodukts zu gewährleisten. Die Norm fordert eine Dokumentation der verwendeten SOUP sowie die Durchführung von Tests und Validierungen, um sicherzustellen, dass die Software den erforderlichen Standards entspricht.

Die IEC 62304 definiert drei Software-Sicherheitsklassen: Klasse A, B und C, die auf dem Risiko basieren, das von der Software ausgeht. Klasse A umfasst Software, deren Ausfall keine negativen Auswirkungen auf die Sicherheit des Medizinprodukts hat. Klasse B bezieht sich auf Software, deren Ausfall zu leichten negativen Auswirkungen führen kann, während Klasse C Software beschreibt, deren Ausfall zu schweren oder tödlichen Folgen führen kann. Diese Klassifizierung beeinflusst die Anforderungen an den Entwicklungsprozess und die Risikomanagementmaßnahmen.

Eine Software Bill of Materials (SBOM) ist für Medizinsoftware unerlässlich, um Transparenz über die verwendeten Softwarekomponenten zu gewährleisten. Sie ermöglicht eine bessere Nachverfolgbarkeit und Verwaltung von Abhängigkeiten, was insbesondere bei Sicherheits- und Compliance-Anforderungen von Bedeutung ist. Zudem hilft eine SBOM, potenzielle Sicherheitsrisiken zu identifizieren und zu bewerten, die aus der Verwendung von Drittanbieter-Software oder Open-Source-Komponenten resultieren können. In der regulierten Umgebung der Medizinprodukte ist eine SBOM ein wichtiges Werkzeug zur Einhaltung von Normen und Vorschriften.

Die Organisation von Schwachstellenmeldungen und Sicherheitsupdates erfordert einen strukturierten Ansatz über den gesamten Produktlebenszyklus. Zunächst sollten klare Prozesse für die Identifizierung und Meldung von Schwachstellen etabliert werden. Anschließend ist es wichtig, Sicherheitsupdates zeitnah zu planen und durchzuführen, um potenzielle Risiken zu minimieren. Eine kontinuierliche Überwachung und Dokumentation der Sicherheitslage ist ebenfalls entscheidend, um die Integrität des Produkts zu gewährleisten.

Eine Datenschutz-Folgenabschätzung (DSFA) ist erforderlich, wenn Gesundheitssoftware personenbezogene Daten verarbeitet, die ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen darstellen. Dies ist insbesondere der Fall, wenn sensible Daten, wie Gesundheitsdaten, verarbeitet werden. Die DSFA sollte vor der Verarbeitung durchgeführt werden, um potenzielle Risiken zu identifizieren und geeignete Maßnahmen zur Risikominderung zu ergreifen.

Die Verarbeitung von Gesundheitsdaten ist in der Datenschutz-Grundverordnung (DSGVO) geregelt. Insbesondere Artikel 9 der DSGVO stellt klar, dass die Verarbeitung solcher Daten grundsätzlich verboten ist, es sei denn, es liegt eine der spezifischen Ausnahmen vor. Zu diesen Ausnahmen gehören unter anderem die ausdrückliche Einwilligung der betroffenen Person oder die Notwendigkeit zur Erfüllung von rechtlichen Verpflichtungen im Gesundheitsbereich.

Die Gestaltung von Rollen, Zugriffsrechten und Protokollen für Patientendaten ist entscheidend für den Datenschutz und die Datensicherheit. Es sollten klare Rollen definiert werden, die den Zugriff auf Patientendaten regeln, wobei nur autorisierte Personen Zugang erhalten. Protokolle sind notwendig, um Zugriffe zu dokumentieren und im Falle von Sicherheitsvorfällen nachvollziehbar zu machen. Die Implementierung von Zugriffskontrollen und regelmäßigen Audits trägt zur Einhaltung der Datenschutzanforderungen bei.

Medizinische Software sollte sowohl bei der Speicherung als auch bei der Übertragung von Daten starke Verschlüsselungsverfahren einsetzen. AES (Advanced Encryption Standard) mit einer Schlüssellänge von mindestens 256 Bit wird häufig für die Speicherung von Daten empfohlen. Für die Übertragung sind Protokolle wie TLS (Transport Layer Security) unerlässlich, um die Daten während der Übertragung zu schützen. Diese Maßnahmen sind entscheidend, um die Vertraulichkeit und Integrität sensibler Gesundheitsdaten zu gewährleisten.

Die Wiederanlaufzeiten von Backup- und Notfallkonzepten im klinischen Betrieb sind entscheidend für die Aufrechterhaltung der Patientenversorgung. Diese Zeiten variieren je nach Art der Systeme und den spezifischen Anforderungen der Einrichtung. In der Regel sollten kritische Systeme innerhalb von Stunden wiederhergestellt werden, während weniger kritische Systeme auch längere Wiederanlaufzeiten tolerieren können. Die genaue Festlegung sollte auf einer Risikoanalyse basieren.

Die Validierung einer DICOM-Schnittstelle erfolgt durch mehrere Schritte, die sicherstellen, dass die Implementierung den DICOM-Standards entspricht. Zunächst sollte eine Überprüfung der Konformität mit den DICOM-Spezifikationen erfolgen, gefolgt von Tests der Kommunikationsprotokolle. Zudem sind Funktionstests durchzuführen, um die korrekte Übertragung und Verarbeitung von Bilddaten zu gewährleisten. Abschließend sollte die Interoperabilität mit anderen DICOM-konformen Systemen getestet werden.

Die Prüfung von FHIR-Schnittstellen gegen Profile und Terminologien erfolgt in mehreren Schritten. Zunächst wird die Konformität der Schnittstelle mit den definierten FHIR-Profilen überprüft, die spezifische Anforderungen an die Datenstruktur und -inhalte festlegen. Anschließend erfolgt die Validierung der verwendeten Terminologien, um sicherzustellen, dass die richtigen Codes und Begriffe verwendet werden. Dies kann durch automatisierte Tools oder manuelle Überprüfungen geschehen.

Die Anforderungen an KI-Funktionen in medizinischer Software sind vielfältig und umfassen sowohl technische als auch regulatorische Aspekte. Zu den zentralen Anforderungen gehören die Gewährleistung der Sicherheit, Wirksamkeit und der Nachvollziehbarkeit der KI-Algorithmen. Zudem müssen die Systeme den geltenden Normen und Richtlinien entsprechen, wie beispielsweise der EU-Verordnung über Medizinprodukte. Eine kontinuierliche Überwachung und Validierung der KI-Funktionen ist ebenfalls erforderlich, um die Qualität der medizinischen Software zu sichern.

Medizinische Software kann als Digitale Gesundheitsanwendung (DiGA) zugelassen werden, wenn sie die Anforderungen des deutschen Gesundheitsrechts erfüllt. Dazu gehört die Nachweisführung der medizinischen Zweckbestimmung, die Sicherheit und die Wirksamkeit der Anwendung. Zudem muss die Software in der Lage sein, die Versorgung der Patienten zu verbessern und die Gesundheitsdaten sicher zu verarbeiten. Die Zulassung erfolgt durch das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM).

Die Registrierung von Medizinsoftware bei Swissmedic erfolgt in mehreren Schritten. Zunächst muss die Software in die richtige Risikoklasse eingeteilt werden, was entscheidend für den weiteren Registrierungsprozess ist. Anschließend sind die erforderlichen Unterlagen, wie technische Dokumentationen und Nachweise zur Sicherheit und Wirksamkeit, einzureichen. Nach Prüfung durch Swissmedic wird die Software in das Register aufgenommen, sofern alle Anforderungen erfüllt sind.

Die Validierung von Cloud-Diensten und externen Softwarelieferanten im Qualitätsmanagement erfordert eine systematische Vorgehensweise. Zunächst ist eine Risikobewertung durchzuführen, um potenzielle Risiken zu identifizieren. Anschließend sollten die Anforderungen an die Software und die Dienstleister klar definiert werden. Die Überprüfung der Compliance mit relevanten Normen und Vorschriften ist ebenfalls entscheidend, gefolgt von regelmäßigen Audits und Bewertungen der Dienstleister.

Um nach einer Datenmigration nachzuweisen, dass keine Patientendaten fehlen oder verändert wurden, sind mehrere Schritte erforderlich. Zunächst sollte ein umfassendes Datenmapping zwischen den Quell- und Zielsystemen erstellt werden. Anschließend sind Datenintegritätsprüfungen durchzuführen, um sicherzustellen, dass alle Daten korrekt übertragen wurden. Zudem empfiehlt sich der Einsatz von Prüfziffern oder Hash-Werten, um Veränderungen an den Daten zu identifizieren.