Im letzten Blogeintrag lernten wir die groben regulatorischen Rahmenbedingungen für allgemeine Medizinprodukte im amerikanischen Rechtsraum kennen. In dem aktuellen Artikel sollen diese Inhalte vertieft und der Fokus auf unser eigentliches Thema, der medizinischen Software, gelegt werden.

Wie bereits im letzten Artikel erwähnt, regelt die Food and Drug Administration (FDA) die Sicherheit und Wirksamkeit u.a. von Medizinprodukten. Da Software mit medizinischer Zweckbestimmung in den Zuständigkeitsbereich dieser Behörde fällt, sollte Ihre Informationsquelle daher primär die offizielle Homepage der FDA sein Link.

Beginnen wir ganz oben: Der Code of Federal Regulations 21 (CFR21) behandelt viele Bereiche, welche für Hersteller von Medizinprodukten relevant sind. Alles Anforderungen, welche Ihre medizinische Software ebenfalls erfüllen muss. Exemplarisch aufgelistet einige Teile:

• Part 801: Bezeichnung und Beschriftung von Medizinprodukten
• Part 806: Meldepflicht bei Korrekturen am Produkt oder Rückrufaktionen
• Part 809: Spezielle Anforderungen an In-Vitro-Diagnostika
• Part 814: Pre-Market Approval

Eine spezielle Bedeutung für Sie als Hersteller stellt aber ohne Zweifel der Part 820 zu den Quality System Regulations dar. Zweck dieses Abschnitts ist die Festlegung der Anforderungen an das Qualitätsmanagement von Organisationen, welche Medizinprodukte entwickeln. So werden beispielsweise Anforderungen an die oberste Leitung, an die Dokumentenlenkung oder an den Beschaffungsprozess definiert.

Was aber ist jetzt für die tatsächliche Entwicklung Ihres Medizinprodukts erwähnt? Vor allem die unter Part 820.30 formulierten Design Controls, welche Ihnen bestimmt bekannt vorkommen. In kurzen Worten muss

1. die Entwicklung geplant,
2. der Design Input spezifiziert,
3. der Design Output dokumentiert,
4. der Design-Review festgelegt und
5. die Design-Verifizierung und Design-Validierung nachvollziehbar durchgeführt werden.

Diese Punkte werden genauer in den nächsten Blogartikeln aufgegriffen. Für den Moment reicht es, zu wissen, dass offensichtlich auch im amerikanischen Raum die Entwicklung von medizinischer Software innerhalb eines definierten Lebenszyklus stattfinden muss. Aber wie strukturiert man nun die enstehenden Dokumente, welche im Zuge der Durchführung der oben genannten Aktivitäten enstehen?

Die FDA definiert dafür drei Begriffe:

• Device Master Record (DMR): definiert das “Rezept” Ihres Produkts (Spezifikation, Arbeitsanweisungen…)
• Design History File (DHF): beschreibt, wie Ihre Entwicklung (Ihr “Rezept”) entstanden ist
• Device History Record (DHR): dokumentiert, dass ein Produkt oder eine Produktcharge gemäß des im DMR definierten “Rezepts” produziert wurde

Sie erinnern sich bestimmt an zwei der möglichen Zulassungsverfahren in Amerika, der Pre-Market Approval (PMA) und der Pre-Market Notification (510(k)). Für beide Verfahren ist ein kompletter und freigegebener DMR ein guter Startpunkt. In diesem DMR sollten demnach auch sämtliche Dokumente zu finden sein, welche den Lebenszyklus medizinischer Software beschreiben, welche, je nach Risikopotential Ihrer Software, in unterschiedlichem Umfang eingereicht werden muss. So müssen Sie beispielsweise für medizinische Software mit niedrigem Risikopotential (minor) keine Software-Architektur und nur eine grobe Anforderungsspezifikation einreichen. Dies ist ausführlich im Guidance Document “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” Link beschrieben. Auch wenn die Versuchung groß ist: Verwechseln Sie nicht die Software-Sicherheitsklasse der EN 62304 mit den Schweregraden (Level of Concern) in diesem Guidance Document. Der Level of Concern bezieht sich nur auf die einzureichende Dokumentation, die Software-Sicherheitsklasse auf die tatsächlich zu erstellenden Dokumente.

Abgesehen von dem erwähnten Dokument existieren noch weitere, für medizinische Software, relevante Guidance Documents:

• Guidance for Off-the-Shelf Software Use in Medical Devices regelt den Umgang mit Software-Systemen, welche in ein Medizinprodukt eingebettet sind, wo aber keine ausreichende Dokumentation über den Lebenszyklus verfügbar ist (z.B.: Betriebssysteme)
• Guidance for Industry - Cybersecurity for Networked Medical Devices Containing Off-the-Shelf Software definiert Anforderungen an Medizinprodukte, welche Off-the-shelf (OTS) Software beinhalten und an ein privates Netzwerk oder an das Internet angeschlossen werden.

Nach dem Lesen der letzten beiden Blogeinträge sollten Sie nun überblicksmäßig wissen, wie der amerikanische Rechtsraum für Medizinprodukte strukturiert ist. Insbesonders der CFR 21 sollte Ihnen nun ein Begriff sein, speziell die für Medizinprodukte relevanten Teile daraus. Die grundlegende Struktur der entstehenden Dokumentation und die für medizinische Software relevanten Guidance Documents der FDA sollten Sie nun ebenfalls kennen.

Nachdem in den vergangenen Blogeinträgen eine Übersicht geschaffen wurde, können wir in den kommenden Artikeln weiter ins Detail gehen.