Software als medizinisches Gerät befindet sich in einer ungewöhnlichen regulatorischen Situation: Das Produkt ändert sich schneller, als die Dokumentationsprozesse, die ursprünglich für Hardwaregeräte entwickelt wurden, bewältigen konnten. Eine technische SaMD-Datei muss nicht nur erfassen, was die Software tut, sondern auch, wie sie über einen Release-Zyklus hinweg entwickelt, überprüft und gewartet wurde, der möglicherweise in Wochen statt in Jahren gemessen wird. Dieser Unterschied liegt darin, dass viele Teams unterschätzen, was tatsächlich erforderlich ist.
Was eine technische SaMD-Datei zeigen muss
Über die allgemeine Gerätebeschreibung und den beabsichtigten Verwendungszweck hinaus muss eine SaMD-Datei normalerweise Folgendes zeigen:
Eine definierte Softwaresicherheitsklassifizierung basierend auf der Bedeutung der von der Software bereitgestellten Informationen und dem Zustand der Gesundheitssituation oder des Zustands, auf den sie abzielt
Softwareanforderungsspezifikationen, Architekturdesign und detaillierte Designdokumentation, die nachverfolgen klar zu Verifizierungs- und Validierungsaktivitäten
Softwarespezifische Risikomanagementdokumentation, die sowohl das klinische Risiko der Softwarefunktion als auch das Cybersicherheitsrisiko der Software selbst abdeckt
Verifizierungs- und Validierungsaufzeichnungen für jede Veröffentlichung, nicht nur für die Ersteinreichung, da SaMD voraussichtlich als lebendes Produkt beibehalten wird
Änderungskontrollaufzeichnungen, aus denen hervorgeht, wie jedes Softwareupdate auf seine Auswirkungen auf Sicherheit und Wirksamkeit bewertet wurde und ob es erforderlich war Neue Zulassungsanträge
Wo Teams in Schwierigkeiten geraten
Die häufigste Lücke ist nicht die fehlende Dokumentation. Es handelt sich um eine Dokumentation, die vorhanden ist, aber nicht gut genug organisiert ist, um die von den Aufsichtsbehörden erwartete Rückverfolgbarkeit zwischen einer Anforderung, ihrer Designimplementierung, ihrem Verifizierungstest und allen damit verbundenen Fehlern oder Änderungen zu demonstrieren. Wenn diese Rückverfolgbarkeit zum Zeitpunkt der Einreichung über möglicherweise Dutzende von Softwareversionen hinweg manuell wiederhergestellt werden muss, wird sie zur größten Verzögerungsquelle.
Eine zweite häufige Lücke ist die Versionskontrollabweichung zwischen der Entwicklungsdokumentation und dem, was tatsächlich in der technischen Datei referenziert wird, insbesondere wenn Softwareteams schneller iterieren, als die behördliche Dokumentation entsprechend aktualisiert wird.
Wie ein validiertes Dokumentenmanagementsystem hilft
Ein Dokumentenmanagementsystem, das für regulierte Branchen entwickelt wurde, geht beide Probleme direkt an. Versionskontroll- und Genehmigungsworkflows sorgen dafür, dass jedes Dokument an eine bestimmte, nachvollziehbare Revision gebunden ist, sodass die technische Datei den tatsächlichen aktuellen Stand der Software widerspiegelt und nicht eine Momentaufnahme von Monaten zuvor. Querverweise zwischen verwandten Dokumenten, den Anforderungen an den Entwurf und die Verifizierung sorgen dafür, dass die Rückverfolgbarkeitskette automatisch intakt bleibt, während sich die Software weiterentwickelt, anstatt dass sie für jede Einreichung oder jedes Audit manuell neu erstellt werden muss.
Behandeln der technischen Datei als lebendes Dokument und nicht als einmalige Lieferung
Die Teams, die die SaMD-Dokumentation am reibungslosesten verwalten, tendieren dazu, die technische Datei auf die gleiche Weise zu behandeln, wie sie die Software selbst behandeln: kontinuierlich gepflegt, versioniert und zu jedem Zeitpunkt revisionsbereit. nicht nachträglich zusammengestellt werden, wenn eine Vorlage oder Prüfung fällig ist. Diese Änderung des Ansatzes ist es, die tatsächlich die Lücke zwischen der schnellen Softwareentwicklung und der von den Regulierungsbehörden geforderten Dokumentationsgenauigkeit schließt.
Wenn Ihr SaMD-Dokumentationsprozess bei der Rückverfolgbarkeit von Dokumenten über Releases hinweg Schwierigkeiten hat, ist Seite zum Dokumentverwaltungssystem erläutert, wie Versionskontrolle und Querverweise in einer 21 CFR Part 11-konformen Umgebung funktionieren.
