Welche Anforderungen gelten, wann Software ein Medizinprodukt ist und wie wir unsere eigene Entwicklung einordnen.
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 K...
Antwort lesenSobald 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 therapeutis...
Antwort lesenGesundheitsdaten 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üc...
Antwort lesenMehr 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 Verpf...
Antwort lesenGrundsä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 Bereich...
Antwort lesenIn 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 2...
Antwort lesenDie 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 Anha...
Antwort lesenISO 14971:2019 verlangt einen dokumentierten Risikomanagementprozess über den gesamten Produktlebenszyklus: Gefährdungen identifizieren, Risiken bewerten, Kontrollen umsetzen, Restrisiken beurteilen und Erkenntnisse aus...
Antwort lesenIEC 62366-1:2015 mit Amendment 1:2020 fordert einen sicherheitsbezogenen Usability-Engineering-Prozess. Hersteller müssen Nutzungskontext, Nutzergruppen, kritische Bedienhandlungen und gefahrbezogene Nutzungsszenarien be...
Antwort lesenDie technische Dokumentation muss nach MDR-Anhang II die Zweckbestimmung, Produktbeschreibung, Entwicklung, Risikokontrollen und sämtliche Verifikations- und Validierungsnachweise nachvollziehbar zusammenführen; Anhang I...
Antwort lesenDie 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 va...
Antwort lesenIEC 62304:2006+A1:2015 strukturiert Entwicklung und Wartung medizinischer Software in nachvollziehbare Lebenszyklusprozesse. Verifikation prüft schrittweise, ob Anforderungen, Architektur, Module und integriertes System...
Antwort lesenJedes Update braucht eine dokumentierte Änderungsbewertung, die Zweckbestimmung, MDR-Qualifikation und -Klasse, Risiken, klinische Evidenz, Gebrauchstauglichkeit, Cybersecurity, Tests und UDI-Auswirkungen betrachtet. Ob...
Antwort lesenDie 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, Informa...
Antwort lesenHL7 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 Info...
Antwort lesenEin 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 Vor...
Antwort lesenDie 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 Softwar...
Antwort lesenDie 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 so...
Antwort lesenEine 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 Gesun...
Antwort lesenDie 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 A...
Antwort lesenEine 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 ein...
Antwort lesenDie 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. E...
Antwort lesenDie Ü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 k...
Antwort lesenEine 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...
Antwort lesenDie 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 Ab...
Antwort lesenDie 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 erfo...
Antwort lesenDie 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 Sicher...
Antwort lesenEine 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...
Antwort lesenDie 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 Sch...
Antwort lesenEine 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 in...
Antwort lesenDie 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...
Antwort lesenDie 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 reg...
Antwort lesenMedizinische 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 Bi...
Antwort lesenDie 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 Anfor...
Antwort lesenDie 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-Spezifi...
Antwort lesenDie 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 Anforderunge...
Antwort lesenDie 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, Wirks...
Antwort lesenMedizinische 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...
Antwort lesenDie 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....
Antwort lesenDie 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 identifiz...
Antwort lesenUm 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 ers...
Antwort lesenKostenloses Erstgespräch - ohne Verkaufsdruck, mit klaren Antworten.
