MDR Anhang II · Anhang III · Regel 11 · IEC 62304
Checkliste für die technische Dokumentation medizinischer Software
Prüfen Sie, ob das Dossier einen Prüfer ohne Bruch in der Nachweiskette von der medizinischen Zweckbestimmung zum freigegebenen Code, zur klinischen Evidenz, zu Risikokontrollen und zu den Pflichten nach dem Inverkehrbringen führt.
Bewerten Sie 89 konkrete Prüfpunkte, dokumentieren Sie Verweise und Lücken und erstellen Sie einen übersichtlichen PDF- oder Druckbericht. Ihr Entwurf bleibt in diesem Browser und wird nicht an MDRC übertragen.
Prüfung starten ↓89 Prüfpunkte · 12 Dossierbereiche
Angaben zur Prüfung
Legen Sie Softwareprodukt und Dossierversion fest
Nur ausgefüllte Felder werden in den Bericht übernommen. Der Name des Softwareprodukts ist erforderlich.
Eingaben werden nur in diesem Browser gespeichert. Sie werden weder hochgeladen noch übermittelt.
Dossierprüfung
Prüfen Sie die vollständige Nachweiskette 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.
Basic UDI-DI, UDI-DI-Strategie und Produktkennungen sind den erfassten Konfigurationen zugeordnet
Verknüpfen Sie Basic UDI-DI, soweit vergeben die UDI-DI, Handelsnamen, Katalogkennungen, Module, Plattformen und Versionierungsregeln so, dass Dossier und Registrierungen dasselbe Produkt identifizieren.
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.
Frühere Generationen und ähnliche Produkte sind mit den wesentlichen Unterschieden benannt
Beschreiben Sie Entwicklungslinie, frühere Versionen, vergleichbare Produkte, relevante Markterfahrung und welche früheren Nachweise weiterverwendet werden, einschließlich der Begründung ihrer fortbestehenden Anwendbarkeit.
Ein Hauptverzeichnis deckt MDR Anhang II und III ab und nennt die aktuelle Dokumentversion
Benennen Sie für jedes erforderliche Element das gelenkte Dokument, den Abschnitt, die Version, den Verantwortlichen und den Genehmigungsstatus. Vermeiden Sie allgemeine Ordnerverweise, die den Prüfer zur Suche zwingen.
Das Dossier besitzt eine eindeutige Kennung, einen Genehmigungsnachweis und eine vollständige Änderungshistorie
Trennen Sie den genehmigten Einreichungssatz von Entwürfen und veralteten Nachweisen. Dokumentieren Sie, was geändert wurde, warum es geändert wurde und welche verknüpften Nachweise erneut bewertet wurden.
Die GSPR-Checkliste bewertet jede anwendbare Anforderung des Anhangs I auf Ebene der Unteranforderungen
Nennen Sie für jede anwendbare Anforderung die Konformitätsmethode und verweisen Sie auf den genauen Nachweis. Begründen Sie jede nicht anwendbare Anforderung produktspezifisch.
Das Normenverzeichnis nennt Ausgaben, Änderungen, Harmonisierungsstatus und Abweichungen
Erklären Sie, welche Abschnitte angewendet wurden und wie Lücken oder alternative Methoden ein gleichwertiges Sicherheits- und Leistungsniveau schaffen.
Kennzeichnungen, elektronische Anzeigen, Gebrauchsanweisung, Benutzerhandbücher und Installationsinformationen sind gelenkt
Halten Sie Produktname, Version, Hersteller, UDI, Zweckbestimmung, Warnungen, kompatible Umgebungen, Mindestanforderungen und Supportinformationen in allen bereitgestellten Formaten konsistent.
Warnungen, Einschränkungen, Restrisiken und erforderliche Anwenderhandlungen stimmen mit den Nachweisen überein
Verfolgen Sie risikomindernde Sicherheitsinformationen von der Risikomanagementakte bis zur genauen Stelle auf Bildschirm, Kennzeichnung oder Dokument und verifizieren Sie, dass der vorgesehene Anwender danach handeln kann.
Konformitätserklärung, Zertifikate und Registrierungen identifizieren denselben Produktumfang
Vergleichen Sie rechtlichen Hersteller, Bevollmächtigten, Produkt und Versionen, Klassifizierung, Konformitätsbewertungsweg, Normen, Basic UDI-DI, Zertifikatsumfang sowie EUDAMED- oder nationale Registrierungsdaten.
Übersetzungen und länderspezifische bereitgestellte Informationen sind versionsgleich
Bewahren Sie Übersetzungsprüfung und Genehmigung, Abdeckung der Vertriebsländer und ein Verfahren auf, das verhindert, dass nach einer Sicherheits- oder Produktänderung eine veraltete Sprachfassung verfügbar bleibt.
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.
Der Datensatz der freigegebenen Konfiguration nennt Quellcode-, Abhängigkeits-, Daten-, Modell- und Infrastrukturversionen
Dokumentieren Sie Quellcode-Commit oder Tag, Build-Werkzeuge, SOUP-Versionen, Konfiguration, Modell- und Datensatzkennungen, Bereitstellungsskripte, Datenbankschema, unterstützte Plattformen und soweit anwendbar den kryptografischen Hashwert.
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.
Softwareversionierung, UDI und bereitgestellte Informationen bleiben abgestimmt
Definieren Sie Haupt-, Neben-, Patch- und Build-Kennungen, erklären Sie, welche Version der Anwender sieht, bewerten Sie, wann eine neue UDI-DI erforderlich ist, und halten Sie Benutzeroberfläche, Gebrauchsanweisung, Erklärung, Zertifikat und Registrierungsdaten konsistent.
Eine Zusammenfassung der Freigabenachweise schließt jede Anforderung, Risikokontrolle und ungelöste Anomalie ab
Benennen Sie für die eingereichte Version die endgültigen Prüfberichte, Verifikation der Risikokontrollen, Schlussfolgerungen zu Gebrauchstauglichkeit und Klinik, Cybersicherheitsstatus, bekannte Anomalien, Freigabegenehmigung und jede begründete offene Maßnahme.
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.
Das Revisionsverzeichnis der technischen Dokumentation nennt jedes betroffene Dokument
Ordnen Sie die Produktänderung den geänderten Anforderungen, Architektur-, Risiko-, klinischen, Gebrauchstauglichkeits-, Cybersicherheits-, Verifikations-, Kennzeichnungs-, Registrierungs- und PMS-Dokumenten mit Version und Genehmigungsstatus zu.
Eine erforderliche Mitteilung oder Genehmigung der Benannten Stelle wurde vor der Bereitstellung bewertet
Wenden Sie Zertifikatsbedingungen und vereinbarte Meldeverfahren auf wesentliche Änderungen des QM-Systems, des erfassten Produktbereichs, der Zweckbestimmung, des Designs, der Leistung oder der Risikokontrollen an und bewahren Sie Entscheidung sowie Korrespondenz auf.
Die abschließende Einreichungsprüfung bestätigt Vollständigkeit, Konsistenz und lesbare Verweise
Prüfen Sie sämtliche Einträge des Hauptverzeichnisses, Querverweise, Dateinamen, Versionen, Genehmigungen, Anlagen, Hyperlinks, Suchbarkeit, Lesbarkeit und Konsistenz mit Zertifikat, Erklärung, Kennzeichnung und Registrierungsdaten.
Offene Feststellungen besitzen Verantwortliche, Termine, Zwischenmaßnahmen und eine dokumentierte Einreichungsentscheidung
Trennen Sie zulässige Restarbeiten von Nachweislücken, die eine Einreichung oder Freigabe verhindern. Genehmigen Sie jede akzeptierte offene Feststellung mit Risikobegründung, Zwischenkontrolle und Abschlussplan.
Löschen Sie den Suchbegriff oder deaktivieren Sie den Filter für offene Punkte.
Prüfung ausgeben
Erstellen Sie einen übersichtlichen Bericht zur Prüfung der technischen Dokumentation
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 Anhang II und III sowie Software-Lebenszyklusnachweisen aufgebaut
Die MDR ist rechtsverbindlich. Normen und MDCG-Leitlinien unterstützen die Umsetzung, ersetzen jedoch keine produktspezifische rechtliche, technische und klinische Bewertung. Der genaue Nachweissatz muss zur Software, ihrer Klasse, ihren Aussagen, Risiken und ihrem Bereitstellungsmodell passen.
Verordnung (EU) 2017/745
Anhänge I–III, Regel 11, klinische Bewertung und Pflichten nach dem Inverkehrbringen
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