MDR Artikel 10 Absatz 9 · Regel 11 · IEC 62304 · Interaktive Prüfung
MDR-QMS-Checkliste für Medizinproduktesoftware
Prüfen Sie, ob die Softwarekontrollen von der Zweckbestimmung und Klassifizierung nach Regel 11 bis zu Freigabe, Wartung und Überwachung nach dem Inverkehrbringen lückenlos verbunden bleiben.
Bewerten Sie 84 konkrete Prüfpunkte, dokumentieren Sie Nachweise und Lücken und erstellen Sie einen übersichtlichen Bewertungsbericht. Ihr Entwurf bleibt in diesem Browser und wird nicht an MDRC übertragen.
Prüfung starten ↓84 Prüfpunkte · 12 Software-Kontrollbereiche
Angaben zur Prüfung
Legen Sie Softwareprodukt und Prüfumfang fest
Nur ausgefüllte Felder werden in den Bericht übernommen. Der Name der Organisation ist erforderlich.
Eingaben werden nur in diesem Browser gespeichert. Sie werden weder hochgeladen noch übermittelt.
Systemprüfung
Prüfen Sie die vollständige QM-Kette der Software
Wählen Sie Erfüllt, Offen oder Nicht anwendbar. Ergänzen Sie Dokumentenverweise, Entscheidungen oder kurze Begründungen dort, wo sie die Prüfung unterstützen.
Der rechtliche Hersteller und das konkrete Softwareprodukt sind eindeutig bestimmt
Dokumentieren Sie den rechtlichen Namen, die SRN soweit vorhanden, Produktname, Module, Plattformen, Bereitstellungsmodelle, aktuelle Versionen und ob die Software ein eigenständiges Produkt, Bestandteil eines Produkts oder Zubehör ist.
Die Zweckbestimmung beschreibt die medizinische Funktion ohne vage Technologiebeschreibungen
Benennen Sie medizinischen Zweck, Zielpopulation, vorgesehene Anwender, Anwendungsumgebung, Ein- und Ausgaben, unterstützte klinische Entscheidungen, Einschränkungen und Kontraindikationen. Aussagen auf Website, App-Plattform, in Gebrauchsanweisung und klinischer Bewertung müssen übereinstimmen.
Die Qualifizierung als Medizinproduktesoftware ist für jede medizinische Funktion oder jedes Modul dokumentiert
Wenden Sie die MDR-Definition und MDCG 2019-11 Rev.1 an. Trennen Sie medizinische Funktionen von Speicherung, Kommunikation, Arbeitsablauf und allgemeinem Wohlbefinden und dokumentieren Sie Abhängigkeiten zwischen regulierten und nicht regulierten Modulen.
Die MDR-Klassifizierung ist anhand von Regel 11 und weiteren anwendbaren Regeln des Anhangs VIII begründet
Software zur Entscheidungsunterstützung fällt grundsätzlich in Klasse IIa und steigt auf IIb oder III, wenn eine Fehlentscheidung eine schwerwiegende Verschlechterung, einen chirurgischen Eingriff, den Tod oder eine irreversible Verschlechterung verursachen kann. Überwachungssoftware fällt grundsätzlich in IIa und in IIb, wenn sie Vitalparameter überwacht, deren Veränderung eine unmittelbare Gefahr hervorrufen kann. Andere Software kann Klasse I sein.
Der Konformitätsbewertungsweg entspricht der Softwareklasse und der Situation des Herstellers
Software der Klasse I kann selbst erklärt werden, sofern keine andere Eigenschaft eine Benannte Stelle erfordert. Für die Klassen IIa, IIb und III sind eine entsprechend benannte Stelle und ein dokumentierter Bewertungsweg erforderlich.
Die regulatorische Produktgrenze umfasst alle sicherheitsrelevanten Abhängigkeiten
Erfassen Sie Betriebssysteme, Browser, mobile Geräte, Cloud-Dienste, Datenbanken, Schnittstellen, Hardware, Netzwerke und externe Dienste, die für die sichere Funktion der Software erforderlich sind.
Werbeaussagen und Produktdarstellung werden durch den genehmigten Umfang und die Evidenz gedeckt
Verhindern Sie unbelegte diagnostische, prädiktive, präventive oder therapeutische Aussagen und stellen Sie sicher, dass Demonstrationen, Bildschirmabbildungen, App-Store-Texte und Vertriebsmaterial die Zweckbestimmung nicht erweitern.
Das QM-System umfasst ausdrücklich Entwicklung, Freigabe, Wartung und Nachmarktunterstützung der Software
Die Kontrollen nach Artikel 10 Absatz 9 müssen Anforderungen, Risiken, klinische Evidenz, Konfiguration, Verifikation, Freigabe, Lieferanten, Cybersicherheit, Beschwerden, Aktualisierungen und Außerbetriebnahme erfassen und dürfen nicht bei allgemeiner Dokumentenlenkung enden.
Eine aktuelle regulatorische Strategie verbindet jede Softwareversion mit den Marktanforderungen
Dokumentieren Sie Qualifizierung, Klassifizierung, Konformitätsbewertungsweg, anwendbare GSPR, Standards, klinischen Weg, UDI, Registrierungen, PMS-Ergebnisse und belieferte Länder.
Softwarebezogene Verantwortlichkeiten und Freigabebefugnisse sind dokumentiert
Bestimmen Sie Verantwortliche für Produkt, Architektur, Entwicklung, Risiko, Klinik, Cybersicherheit, Verifikation, Konfiguration, Freigabe, Beschwerden, Vigilanz und regulatorische Auswirkungsbewertung einschließlich Stellvertretungen.
Die PRRC ist in Entscheidungen zu Konformität, Freigabe und Wartung eingebunden
Stellen Sie der PRRC aktuelle Nachweise zur Verfügung, damit sie die Konformität vor Freigabe, die Pflege der technischen Dokumentation, PMS-Pflichten und Meldepflichten nach Artikel 15 prüfen kann.
Die Schnittstellen zwischen ISO 13485, IEC 62304 und unterstützenden Prozessen sind definiert
Zeigen Sie, wie das unternehmensweite QM-System Prozesse für Softwarelebenszyklus, Risiko, Gebrauchstauglichkeit, klinische Bewertung, Cybersicherheit, Lieferanten, Konfiguration, CAPA und PMS ohne Lücken oder widersprüchliche Freigabewege auslöst.
Regulatorische Änderungen sowie Änderungen von Standards und Plattformen werden durch benannte Verantwortliche überwacht
Verfolgen Sie MDR-Änderungen, MDCG-Dokumente, harmonisierte Normen, Richtlinien von Betriebssystemen, Browsern, Cloud-Diensten und App-Plattformen sowie Cybersicherheitsanforderungen mit dokumentierten Auswirkungsentscheidungen.
Ausgelagerte Softwarearbeiten bleiben unter Kontrolle des Herstellers
Verträge können Aufgaben, aber nicht die rechtliche Verantwortung übertragen. Definieren Sie Arbeitsergebnisse, Anforderungen an Code und Sicherheit, Aufzeichnungen, Zugriff, Auditrechte, Meldung von Vorfällen und Änderungen sowie Quellcodezugang oder Kontinuitätsvorkehrungen.
Für die aktuelle Freigabe besteht ein Plan für Softwareentwicklung und -wartung
Legen Sie Lebenszyklusmodell, Aktivitäten, Arbeitsergebnisse, Verantwortlichkeiten, Reviews, Konfigurationskontrollen, Werkzeuge, Verifikation, Anomaliebehandlung, Freigabekriterien und Wartung fest.
Die Software-Sicherheitsklasse nach IEC 62304 ist dokumentiert und begründet
Weisen Sie Klasse A, B oder C nach dem möglichen Schaden zu, wenn die Software zu einer Gefährdungssituation beiträgt, und berücksichtigen Sie externe Risikokontrollen. Diese Sicherheitsklasse ist von der MDR-Produktklasse getrennt und ersetzt sie nicht.
Das Lebenszyklusmodell bewahrt bei agilen Methoden die erforderlichen Nachweise
Sprints und User Stories sind nur dann geeignet, wenn genehmigte Anforderungen, Risikoverknüpfungen, Reviews, Prüfungen, Konfigurationsbaselines und Freigabeaufzeichnungen vollständig und rückverfolgbar bleiben.
Lebenszyklusaktivitäten werden risikogerecht skaliert, ohne verpflichtende Kontrollen auszulassen
Dokumentieren Sie die für jedes Softwareelement geltenden Aktivitäten, begründen Sie jede Anpassung und versehen Sie Komponenten mit höherem Risiko mit stärkerer Prüfung, Unabhängigkeit und Verifikation.
Für Altsoftware oder bereits entwickelte Software liegt eine dokumentierte Lückenanalyse vor
Ermitteln Sie fehlende Anforderungen, Architektur, Risikoverknüpfungen, Verifikation, Anomalie- und Konfigurationsaufzeichnungen und definieren Sie Abhilfen oder begründete alternative Nachweise, bevor die Software verwendet wird.
Problemlösungs- und Wartungsprozesse sind vor der Freigabe geplant
Definieren Sie Eingang, Triage, Sicherheits- und Cybersicherheitsbewertung, Untersuchung, Korrektur, Regressionstests, regulatorische Bewertung, Kundenkommunikation und Abschluss.
Lebenszyklusaufzeichnungen identifizieren Software, Werkzeuge und Umgebung eindeutig
Bewahren Sie Repositories, Zweige, Commits, Build-Werkzeuge, Compiler- oder Interpreterversionen, Abhängigkeiten, Testumgebungen und erzeugte Artefakte auf, die zur Rekonstruktion des freigegebenen Zustands erforderlich sind.
System- und Softwareanforderungen sind eindeutig gekennzeichnet, prüfbar und genehmigt
Erfassen Sie medizinische Funktionen, Leistungsmerkmale, Sicherheit, Cybersicherheit, Gebrauchstauglichkeit, Schnittstellen, Daten, Alarme, Installation, Wartung, regulatorische Beschränkungen und vorhersehbare Fehlanwendung mit messbaren Akzeptanzkriterien.
Jede Anforderung hat eine gelenkte Quelle und eine Begründung
Verfolgen Sie Anforderungen zu Nutzerbedürfnissen, Zweckbestimmung, GSPR, Risikokontrollen, klinischer Evidenz, Ergebnissen der Gebrauchstauglichkeit, Standards, Interoperabilitätsspezifikationen oder Nachmarktinformationen zurück.
Die Architektur identifiziert Softwareelemente, Schnittstellen und Trennung
Zeigen Sie Komponenten, Datenspeicher, externe Dienste, Vertrauensgrenzen, Sicherheitsklassen, Verantwortlichkeiten und wie Trennung oder Redundanz verhindert, dass ein einzelner Fehler eine Risikokontrolle außer Kraft setzt.
Datenflüsse und externe Schnittstellen sind durchgängig spezifiziert
Definieren Sie Datenquelle, Format, Einheiten, Zeitverhalten, Validierung, Transformation, Verhalten bei fehlenden oder veralteten Daten, Fehlerbehandlung, Authentifizierung und Ausgaben für APIs, Geräte, EHR-Systeme und Cloud-Dienste.
Für klinische Berechnungen, Schwellenwerte und Alarme bestehen genehmigte Spezifikationen
Dokumentieren Sie Formeln, Einheiten, Rundung, Referenzbereiche, Zeitverhalten, Priorität, Speicherung, Bestätigung und sicheres Verhalten an Grenzwerten, bei ungültiger Eingabe und Kommunikationsverlust.
Bidirektionale Rückverfolgbarkeit verbindet Bedürfnisse, Anforderungen, Risiken, Code und Prüfungen
Ein Prüfer muss von jeder medizinischen Aussage und Risikokontrolle zur implementierten Software und objektiven Verifikation und von jedem freigegebenen Softwareelement zurück zu einer genehmigten Anforderung gelangen können.
Anforderungsänderungen werden vor der Umsetzung geprüft
Bewerten Sie vor Genehmigung die Auswirkungen auf Architektur, Gefährdungen, klinische Aussagen, Gebrauchstauglichkeit, Cybersicherheit, Prüfungen, UDI, technische Dokumentation, Registrierungen und bereits bereitgestellte Versionen.
Die Software-Risikomanagementakte ist mit dem Risikomanagementprozess des Produkts verknüpft
Wenden Sie Risikomanagement über den gesamten Lebenszyklus an und verbinden Sie softwarebezogene Ursachen, Ereignisfolgen, Gefährdungssituationen, Schäden, Kontrollen, Verifikation sowie Produktions- und Nachmarktinformationen.
Softwarespezifische Gefährdungen und Fehlerarten werden systematisch analysiert
Berücksichtigen Sie falsche, verspätete, fehlende oder doppelte Ausgaben, Datenkorruption, falsche Einheiten, Alarmversagen, Automatisierungsbias, unbefugten Zugriff, Dienstausfall, Interoperabilitätsfehler, Updatefehler und vorhersehbare Fehlanwendung.
Cybersicherheitsrisiken werden hinsichtlich ihrer Sicherheitsauswirkungen bewertet
Verbinden Sie Bedrohungsszenarien mit möglichen Schäden für Patienten oder Anwender. Sicherheitskontrollen, die Produktrisiken mindern, müssen in der Risikomanagementakte stehen und derselben Umsetzungs- und Verifikationsdisziplin wie andere Risikokontrollen unterliegen.
Ein Gebrauchstauglichkeitsprozess deckt sicherheitsrelevante Benutzerinteraktionen ab
Bestimmen Sie Anwender, Umgebungen, kritische Aufgaben, Anwendungsszenarien und anwendungsbedingte Gefährdungen, führen Sie formative Bewertungen durch und validieren Sie die endgültige Benutzeroberfläche mit repräsentativen Anwendern und Bedingungen.
Die klinische Evidenz umfasst valide klinische Assoziation, technische Leistung und klinische Leistung
Verwenden Sie soweit anwendbar die Struktur aus MDCG 2020-1. Zeigen Sie, dass die Ausgabe mit dem Zielzustand zusammenhängt, die Software Eingaben korrekt verarbeitet und die Ausgabe den vorgesehenen klinischen Zweck in der Zielpopulation erreicht.
Für jede medizinische Leistungsangabe bestehen Akzeptanzkriterium und unterstützende Daten
Definieren Sie Datensätze, Referenzstandard, Endpunkte, Stichprobengröße, Umgang mit fehlenden Daten, Subgruppenanalysen, Unsicherheit und Konfidenzintervalle für Aussagen etwa zu Sensitivität, Spezifität, Genauigkeit, Vorhersage oder Therapieunterstützung.
Restrisiken, Einschränkungen und Benutzerinformationen stimmen überein
Übertragen Sie verbleibende Einschränkungen, Voraussetzungen, unterstützte Populationen, kompatible Umgebungen, erforderliche Benutzerprüfung und Ausweichmaßnahmen in klinische Bewertung, Risikomanagementakte, Kennzeichnung und Benutzeroberfläche.
Regeln für Programmierung, Code-Review und statische Analyse sind definiert und angewendet
Verwenden Sie sprach- und risikogerechte Kodierungsstandards, Peer-Review, sichere Programmierung, verbotene Konstrukte, Komplexitätsgrenzen und dokumentierte Bearbeitung von Feststellungen.
Modul-, Integrations- und Systemprüfungen decken Normal-, Grenz- und Fehlerverhalten ab
Prüfen Sie Berechnungen, Zustände, Schnittstellen, Zeitverhalten, Parallelität, ungültige Eingaben, Kommunikationsverlust, Ressourcenerschöpfung, Wiederherstellung und vorhersehbare Fehlanwendung auf der geeigneten Ebene.
Für jede umgesetzte Risikokontrolle besteht ein objektiver Wirksamkeitsnachweis
Verknüpfen Sie Kontrollen mit Prüfungen und vorab festgelegten Akzeptanzkriterien und bestätigen Sie, dass die Kontrollen keine neuen Gefährdungen oder unvertretbaren Nebenwirkungen erzeugen.
Der Prüfumfang wird anhand von Anforderungen und Risiken und nicht durch einen einzelnen Prozentwert begründet
Bewerten Sie Abdeckung von Anforderungen, Risikokontrollen, gegebenenfalls Code, Schnittstellenkombinationen, Datenklassen und offene Lücken. Ein hoher Wert der Zeilenabdeckung allein belegt keine angemessene Prüfung.
Die Unabhängigkeit der Verifikation ist dem Software-Sicherheitsrisiko angemessen
Legen Sie fest, wann Reviewer oder Tester von der Implementierung unabhängig sein müssen, und verhindern Sie, dass dieselbe Person ihre eigene risikoreiche Arbeit ohne wirksame unabhängige Kontrolle genehmigt.
Bekannte Anomalien sind vor der Freigabe dokumentiert und bewertet
Dokumentieren Sie Reproduzierbarkeit, betroffene Versionen, Sicherheits- und Cybersicherheitsauswirkungen, Umgehungslösung, Risikoakzeptanz, geplante Korrektur und Offenlegung. Ein Eintrag im Backlog ersetzt keine Freigabebewertung.
Die Validierung verwendet die endgültige oder gleichwertige Konfiguration unter repräsentativen Anwendungsbedingungen
Bestätigen Sie vorgesehene Anwender, Arbeitsabläufe, Hardware, Betriebssysteme, Browser, Netzwerke, Daten, Schnittstellen, Installation, Cybersicherheitskontrollen und Kennzeichnung, bevor Sie die Erfüllung der Nutzerbedürfnisse und Zweckbestimmung feststellen.
Ein aktuelles Verzeichnis von SOUP und Drittanbieterkomponenten ist vorhanden
Erfassen Sie Komponentenname, Lieferant, genaue Version, Funktion, Lizenz, Quelle, bekannte Anomalien, Supportstatus, Sicherheits- oder Cybersicherheitsrelevanz und die freigegebenen Produkte, in denen die Komponente verwendet wird.
Drittanbieterkomponenten werden vor Auswahl und Aktualisierung bewertet
Bewerten Sie Funktionalität, Reife, Herkunft, Dokumentation, bekannte Schwachstellen, Wartung, Kompatibilität, Lizenzpflichten, Ersatzmöglichkeiten und Folgen eines Ausfalls.
Die Überwachung von Schwachstellen und Supportende erfasst jede relevante Abhängigkeit
Nutzen Sie Lieferantenmitteilungen, Schwachstellendatenbanken und Komponentenverzeichnisse, um betroffene Versionen zu erkennen, Ausnutzbarkeit und Sicherheitsauswirkung zu bewerten und Korrektur oder dokumentierte Akzeptanz auszulösen.
Vereinbarungen über externe Entwicklung und Cloud-Dienste legen messbare Kontrollen fest
Definieren Sie Arbeitsergebnisse, Änderungsmitteilung, Vorfallmeldung, sicherheitsrelevante Verfügbarkeit, Sicherung, Datenstandort, Zugriffskontrolle, Auditrechte, Aufzeichnungen, Unterbeauftragung, Beendigung und Kontinuität.
Trainings-, Validierungs- und Testdatensätze werden bei KI oder statistischen Modellen gelenkt
Dokumentieren Sie Herkunft, Einwilligung oder Rechtsgrundlage, Ein- und Ausschluss, Kennzeichnung, Referenzstandard, Repräsentativität, Qualitätsprüfungen, Vermeidung von Datenleckage, Versionierung und Trennung von Trainings-, Abstimmungs- und Testdaten.
Die Modellleistung wird in klinisch relevanten Untergruppen und Bedingungen bewertet
Definieren Sie vorab Subgruppenanalysen, Fehlergrenzen, Unsicherheit, Bias-Kontrollen, Verhalten außerhalb der Datenverteilung und menschliche Aufsicht. Gesamtwerte dürfen unsichere Leistungen einzelner Untergruppen nicht verdecken.
Änderungen von Modellen, Algorithmen und Drittanbieterkomponenten werden versioniert und als Produktänderungen behandelt
Lenken Sie erneutes Training, Parameteränderungen, Datenaktualisierungen, Upgrades von Abhängigkeiten und Lieferantenfreigaben durch Auswirkungsbewertung, Verifikation, klinische Bewertung, regulatorische Prüfung und Bereitstellungsfreigabe.
Das Konfigurationsmanagement identifiziert jedes freigegebene Softwareelement eindeutig
Führen Sie Quellcode, Anforderungen, Architektur, Abhängigkeiten, Daten oder Modell, Skripte, Infrastrukturkonfiguration, Kennzeichnung und Prüfnachweise unter einer kontrollierten Freigabekennung zusammen.
Der Build ist aus einer genehmigten Baseline automatisiert oder anderweitig reproduzierbar
Lenken Sie Build-Anweisungen, Werkzeuge, Umgebung, Abhängigkeiten, Geheimnisse, erzeugte Artefakte und Prüfsummen so, dass eine befugte Person die Freigabe reproduzieren und prüfen kann.
Entwicklungs- und Bereitstellungswerkzeuge werden risikogerecht validiert
Definieren Sie die Zweckbestimmung und prüfen Sie Werkzeuge, die Tests, Build, Codegenerierung, Bereitstellung, Datenmigration, elektronische Genehmigung oder andere Arbeiten automatisieren, deren Versagen regulierte Ergebnisse ungültig machen könnte.
Freigabekriterien verlangen vollständige Nachweise und formale Genehmigung
Bestätigen Sie genehmigte Anforderungen, Prüfungen, Risikokontrollen, klinische und Gebrauchstauglichkeitsschlussfolgerungen, Anomaliebewertung, Cybersicherheitsprüfung, technische Dokumentation, Kennzeichnung, UDI und PRRC-bezogene Konformitätsprüfungen.
Die Bereitstellung verhindert Austausch oder unbefugte Änderung
Verwenden Sie gelenkte Repositories, Signierung, Hashwerte, Zugriffskontrolle, Eigentum an App-Store-Konten, Bereitstellungsprotokolle und Kundenberechtigungen, damit die installierte Version authentifiziert werden kann.
Installation, Aktualisierung, Migration, Rollback und Wiederherstellung sind verifiziert
Prüfen Sie unterstützte Upgradewege, beibehaltene Einstellungen, Datenbankmigration, Unterbrechung, fehlgeschlagenes Update, Rollback, Kompatibilität und Benutzeranweisungen, ohne eine Neuinstallation vorauszusetzen.
Softwareversion, UDI und bereitgestellte Informationen bleiben abgestimmt
Legen Sie fest, wann eine Änderung die Bewertung einer neuen UDI-DI oder Basic UDI-DI erfordert, und halten Sie Version, Kennzeichnung, elektronische Anzeige, Gebrauchsanweisung, Erklärung, Zertifikat und Registrierungsdaten konsistent.
Ein Cybersicherheitsplan und ein Bedrohungsmodell erfassen das gesamte Produktökosystem
Bestimmen Sie Werte, Akteure, Angriffsflächen, Vertrauensgrenzen, plausible Bedrohungen, Schwachstellen, Sicherheitsfolgen, Kontrollen, Verifikation, Restrisiko und Nachmarktwartung für Software und verbundene Dienste.
Sicherheitsanforderungen setzen mehrschichtige Abwehr und sichere Voreinstellungen um
Behandeln Sie soweit anwendbar Authentifizierung, Autorisierung, geringste Rechte, Verschlüsselung, Schlüsselverwaltung, Integrität, Sitzungssteuerung, Eingabevalidierung, Geheimnisse, Protokollierung, Updatesicherheit, sicheres Fehlerverhalten und Wiederherstellung.
Die Sicherheitsverifikation verwendet sich ergänzende Methoden
Kombinieren Sie Code-Review, statische und dynamische Analyse, Abhängigkeitsscans, Konfigurationsprüfung, Fuzzing oder Missbrauchstests, Schwachstellenscans und Penetrationstests entsprechend Architektur und Risiko.
Eine Softwarestückliste unterstützt die Reaktion auf Schwachstellen
Führen Sie für jede Freigabe maschinenlesbare oder anderweitig durchsuchbare Komponentennamen, Lieferanten, Versionen und Abhängigkeitsbeziehungen und verknüpfen Sie Feststellungen mit betroffenen bereitgestellten Versionen.
Ein Prozess zur koordinierten Schwachstellenmeldung und Vorfallbehandlung ist wirksam
Stellen Sie Meldeweg, Bestätigung, Triage, Sicherheits- und Ausnutzbarkeitsbewertung, Abhilfeziele, Befugnisse, Kundenkommunikation, koordinierte Offenlegung und Abschlussaufzeichnungen bereit.
Sicherheitsupdates werden über einen gelenkten und verifizierten Mechanismus bereitgestellt
Definieren Sie Authentizität, Integrität, Kompatibilität, Regressionstests, Dringlichkeit, Überwachung der Bereitstellung, Rollback, Benutzerkommunikation und Unterstützung für Anwender, die nicht sofort aktualisieren können.
Datenschutzkontrollen sind von MDR-Sicherheitskontrollen unterschieden, aber mit ihnen abgestimmt
Soweit die DSGVO gilt, dokumentieren Sie Rechtsgrundlage, Datenminimierung, Zweckbindung, Aufbewahrung, Betroffenenrechte, Auftragsverarbeiter, Übermittlungen und Verfahren bei Datenschutzverletzungen, ohne anzunehmen, dass MDR-Konformität allein Datenschutzkonformität herstellt.
Unterstützte Hardware, Betriebssysteme, Browser und Umgebungen werden kontrolliert
Veröffentlichen Sie genaue Kompatibilitäts- und Mindestanforderungen, verifizieren Sie repräsentative Kombinationen und definieren Sie Überwachung, Warnung und Reaktion, wenn sich eine Plattform ändert oder ihr Support endet.
Cloud-Verantwortlichkeiten sind ausdrücklich zwischen Hersteller und Anbietern aufgeteilt
Dokumentieren Sie, wer Verfügbarkeit, Sicherheit, Patches, Sicherung, Überwachung, Datenstandort, Vorfallreaktion, Unterauftragnehmer und Nachweise kontrolliert, während der Hersteller für die Produktkonformität verantwortlich bleibt.
Ziele für Verfügbarkeit, Latenz, Kapazität und Wiederherstellung entsprechen dem klinischen Risiko
Definieren Sie messbare Grenzen, Alarme, Eskalation und getestete Wiederherstellungsziele für Dienste, deren Verzögerung oder Ausfall eine medizinische Entscheidung beeinflussen oder die sichere Anwendung unterbrechen könnte.
Wiederherstellung aus Sicherungen und Notfallwiederherstellung werden geprüft
Verifizieren Sie Integrität der Sicherung, Wiederherstellungszeit, Datenkonsistenz, Konfigurationswiederherstellung, regionalen oder Lieferantenausfall und die fortbestehende Fähigkeit zur Beschwerde-, Vigilanz- und Kundenkommunikation.
Betriebsprotokolle und Audit-Trails unterstützen Sicherheitsuntersuchungen
Erfassen Sie soweit erforderlich Version, Konfiguration, Benutzer- oder Systemhandlung, Eingabequelle, Ausgabe, Zeitsynchronisierung, Fehler und Sicherheitsereignisse mit geschütztem Zugriff und begründeter Aufbewahrung.
Änderungen der Interoperabilität und Schnittstellen werden erkannt und bewertet
Überwachen Sie Änderungen an API, EHR, Geräten, Terminologie, Datenformat und Protokollen, verwenden Sie Vertrags- oder Kompatibilitätstests und verhindern Sie die unbemerkte Annahme inkompatibler oder semantisch geänderter Daten.
Kundenkonfiguration und Fernwartung erhalten den validierten Zustand
Definieren Sie zulässige Einstellungen, Installationsprüfungen, Fernzugriffskontrollen, Wartungsaufzeichnungen, Kundenverantwortung und wann eine Konfiguration zusätzliche Validierung verlangt oder eine Produktänderung darstellt.
Der PMS-Plan benennt softwarespezifische Datenquellen, Kennzahlen und Schwellenwerte
Berücksichtigen Sie Beschwerden, Supportfälle, Vorfälle, Versions- und Expositionsdaten, Updateerfolg, Verfügbarkeit, Fehler, Übersteuerungen, falsche Ergebnisse, Literatur, Sicherheitsfeststellungen, App-Store-Rückmeldungen, PMCF und relevante Wettbewerbersignale.
Expositionsdaten ermöglichen Häufigkeitsberechnungen nach Version und Nutzung
Erfassen Sie aktive Installationen oder Anwender, Analysen, Patienten, Sitzungen, klinische Entscheidungen oder andere begründete Nenner und unterscheiden Sie aktuelle, ersetzte und nicht mehr unterstützte Versionen.
Beschwerden, Softwareprobleme und Sicherheitsmeldungen gelangen in einen abgestimmten Triageprozess
Verhindern Sie doppelte oder fragmentierte Bewertungen durch Support, Entwicklung und Regulatory Affairs und dokumentieren Sie Kenntnisdatum, betroffene Version, Patientenauswirkung, Meldepflicht, Untersuchung und Abschluss.
Entscheidungen zu schwerwiegenden Vorkommnissen, Trendmeldungen und FSCAs werden fristgerecht getroffen und gemeldet
Verwenden Sie dokumentierte MDR-Entscheidungskriterien, Kenntnisdaten, Behördenabläufe und Nachverfolgung. Eine Fernkorrektur, Konfigurationsänderung oder Sicherheitsmitteilung kann eine FSCA sein, auch wenn kein physisches Produkt zurückgegeben wird.
PMS und PMCF verifizieren die Leistung bei realen Anwendern, Umgebungen und Untergruppen
Definieren Sie, wie Nachmarktevidenz klinische Leistung, Gebrauchstauglichkeit, Interoperabilität und Nutzen-Risiko-Verhältnis bestätigt und Datenverschiebungen, neue Populationen, Automatisierungsbias oder veränderte klinische Praxis erkennt.
PMS-Bericht oder PSUR aktualisiert das gesamte Evidenzsystem
Verwenden Sie die klassengerechte Ausgabe und Frequenz und führen Sie Schlussfolgerungen in Risikomanagement, klinische Bewertung, PMCF, Cybersicherheit, Anforderungen, CAPA, Kennzeichnung und technische Dokumentation zurück.
Updatesupport, Lebenszyklusende und Mitteilung von Lieferunterbrechungen werden gelenkt
Definieren Sie Supportzeiträume, Sicherheitswartung, Außerbetriebnahme, Kundenmigration, sicheres Abschalten und Bewertung nach Artikel 10a, wenn Unterbrechung oder Einstellung vorhersehbar schwerwiegenden Schaden verursachen könnte.
Jeder Änderungsantrag benennt Problem, Umfang und betroffene freigegebene Versionen
Bestimmen Sie gewünschtes Verhalten, Grund, Dringlichkeit, Abhängigkeiten, Anwender, bereitgestellte Population und ob die Änderung einen Fehler korrigiert, eine Aussage ergänzt, die Zweckbestimmung ändert oder eine Risikokontrolle betrifft.
Die Auswirkungsbewertung einer Änderung erfasst die gesamte regulierte Evidenzkette
Prüfen Sie vor Umsetzung Klassifizierung, GSPR, Architektur, Risiko, Gebrauchstauglichkeit, Cybersicherheit, klinische Evidenz, Verifikation, Validierung, UDI, Registrierungen, Kennzeichnung, PMS und Mitteilung an die Benannte Stelle.
Regressionstests werden aus dokumentierter Auswirkung und Risiko abgeleitet
Prüfen Sie geänderten Code und plausible Auswirkungen auf Schnittstellen, Daten, Berechnungen, Leistung, Sicherheit, Installation und bereits verifizierte Risikokontrollen, statt eine willkürliche feste Testsuite zu wiederholen.
Notfall-Patches bewahren Genehmigung, Rückverfolgbarkeit und nachträgliche Prüfung
Definieren Sie reduzierte, aber verpflichtende Nachweise vor Freigabe, befugte Risikoakzeptanz, Kunden- und Behördenkommunikation, Bereitstellungsüberwachung und eine Frist für vollständige Dokumentation und Regression.
CAPA behandelt systemische Ursachen und verifiziert die Wirksamkeit
Trennen Sie unmittelbare Korrektur von Ursachenmaßnahmen, berücksichtigen Sie prozessuale und organisatorische Ursachen, definieren Sie messbare Wirksamkeitskriterien und bestätigen Sie vor Abschluss die verringerte Wiederholung oder das verringerte Risiko.
Interne Audits verfolgen vollständige Softwareprozessketten
Ziehen Sie freigegebene Änderungen als Stichprobe vom Antrag über Anforderungen, Risiko, Code, fachliche Prüfung, Test und Freigabe bis PMS und auditieren Sie Lieferanten-, Cybersicherheits- und Cloud-Kontrollen mit unabhängigen kompetenten Auditoren.
Die Managementbewertung beurteilt Softwarequalität und regulatorische Leistung
Beziehen Sie Freigabequalität, entkommene Fehler, Beschwerden, Vorkommnisse, Schwachstellen, Updateannahme, Lieferantenleistung, klinische und PMS-Signale, Auditfeststellungen, CAPA, Ressourcenengpässe und bevorstehende regulatorische oder Plattformänderungen ein.
Löschen Sie den Suchbegriff oder deaktivieren Sie den Filter für offene Punkte.
Prüfung ausgeben
Erstellen Sie einen übersichtlichen Bericht zur Software-QMS-Prüfung
Der Bericht enthält keine Website-Navigation, Hilfetexte, Steuerelemente, leeren Projektfelder oder leeren Kommentarfelder. Wählen Sie im Druckdialog Als PDF speichern oder einen Drucker.
Regulatorische Grundlage
Auf MDR-Pflichten für Software und Lebenszyklusnachweisen aufgebaut
Die MDR ist rechtsverbindlich. MDCG-Leitlinien und Normen unterstützen Hersteller bei der Anwendung, ersetzen jedoch keine produktspezifische rechtliche, technische und klinische Bewertung. Eine Zertifizierung nach ISO 13485 ist nach der MDR nicht für alle Hersteller verpflichtend.
Verordnung (EU) 2017/745
Artikel 10 und 15, Anhänge I–III, Regel 11 und Konformitätsbewertung
MDCG 2019-11 Rev.1
Qualifizierung und Klassifizierung von Medizinproduktesoftware
IEC 62304
Lebenszyklusprozesse für Medizinproduktesoftware
ISO 14971
Risikomanagement über den Lebenszyklus von Medizinprodukten
MDCG 2019-16 Rev.1
Cybersicherheitsanforderungen und Lebenszykluskontrollen
MDCG 2020-1
Klinische Bewertung und Leistungsnachweise für Medizinproduktesoftware
MDCG 2025-4
Sichere Bereitstellung von Medizinprodukte-Apps auf Online-Plattformen
MDCG 2025-6
Zusammenspiel von MDR, IVDR und Verordnung über künstliche Intelligenz