Prof. Dr. Christian Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

FDA Guidance ‚Interoperable Medical Devices‘

Dienstag 26. September 2017

Die FDA hat das Guidance Dokument ‚Interoperable Medical Devices‘ am 6. September 2017 veröffentlicht.

Die US-Behörde möchte damit der Tatsache Rechnung tragen, dass einerseits die Interoperabilität von Medizinprodukten immer wichtiger für die Gesundheitsversorgung wird. Andererseits führen Probleme mit mangelnder Interoperabilität immer häufiger zu Risiken.

Dieser Beitrag verschafft Ihnen einen schnellen Überblick über die Anforderungen der FDA an ‚Interoperable Medical Devices‘ und gibt Tipps wie Sie diese erfüllen können.

Wen das FDA Dokument betrifft

Das Guidance Document ‚Interoperable Medical Devices‘ wendet sich an Hersteller, die Medizinprodukte mit Datenschnittstellen in den USA verkaufen wollen. Die FDA möchte mit diesem Dokument gleichzeitig auch den eigenen Inspektoren das Verständnis der eigenen Behörde zu diesem Thema vermitteln.

Wie alle „Guidance Documents“ ist auch dieses nicht „legally binding“.

Vorsicht!

Die FDA erwartet, dass die Hersteller bei Einreichungen (z.B. alle Formen der 510(k), PMA) die in diesem Dokument geforderten Informationen beilegen!

Zudem sind Hersteller, die in die USA importieren, generell gut beraten, alle FDA „Guidance Documents“ zu befolgen.

Die FDA gewährt eine 60-tägige Übergangsfrist, die Anfang November 2017 ausläuft.

Gleichzeitig liefert dieses Dokument auch Medizinprodukteherstellern außerhalb des US-Markts wertvolle Hinweise zum Entwickeln interoperabler Medizinprodukte.

Was die FDA unter Interoperabilität versteht

Die FDA folgt den üblichen Definitionen des Begriffs „Interoperabilität“. Demnach versteht man unter Interoperabilität die Fähigkeit von zwei oder mehr Produkten, Technologien oder Systemen, Informationen auszutauschen und ausgetauschte Informationen zu nutzen.

Weiterführende Informationen

Lesen Sie in diesem Artikel mehr darüber, was man unter Interoperabilität versteht und welche Interoperabilitätsebenen man unterscheidet.

Was das Guidance Dokument ‚Interoperable Medical Devices‘ fordert

Das mit 21 Seiten erfreulich kurze Dokument führt in den ersten vier Kapiteln ins Thema ein, und benennt den Anwendungsbereich sowie Definitionen.

Übersicht über FDA Guidance Interoperable Medical Devices

Abb. 1: Übersicht über FDA Guidance Interoperable Medical Devices (zum Vergrößern klicken)

Die wesentlichen Forderungen finden sich in den Kapiteln V und VI:

  • Das Kapitel V gibt Empfehlungen, was man beim Entwickeln interoperabler Medizinprodukte beachten soll.
  • Das Kapitel VI legt fest, welche Informationen die FDA bei Einreichungen erwartet.

Kapitel V: ‚Design Considerations for Interoperable Medical Devices‘

Die FDA verlangt, dass die Hersteller beim Entwurf interoperabler Medizinprodukte die folgenden Aspekte adressieren:

A) Zweck der (elektronischen) Schnittstelle

Die Hersteller müssen in einer Zweckbestimmung festlegen,

  • welche Daten
  • in welchem Format,
  • in welcher Weise (Protokolle, uni-/bidirektional etc.)
  • zwischen welchen Geräten
  • zu welchem Zweck (z.B. Alarm übertragen, Gerät ansteuern)
  • in welchem klinischen Kontext (z.B. bei Beatmung von Patienten)

ausgetauscht werden sollen.

Damit fordert die FDA nicht nur den „Zweck“ („purpose“) zu beschreiben, sondern die Schnittstelle zu spezifizieren.

B) Vorgesehene Anwender

Die FDA nennt Anwendergruppen wie Kliniker, Service-Personal, Systemintegratoren, Mitarbeiter der IT und Patienten. Diese verfolgen bei der Nutzung der Schnittstelle verschiedene Ziele und verfügen über unterschiedliches Wissen.

Hersteller müssen diese Anwendergruppen kennen und beim Risikomanagement berücksichtigen.

C) Risikomanagement

Die Hersteller sind verpflichtet, die Risiken durch mangelnde Interoperabilität zu identifizieren und zu beherrschen. Dazu zählen Risiken durch falsche Daten oder Kommandos, durch Fehlfunktionen der Schnittstellen, durch Probleme mit der IT-Security oder dem Netzwerk (Bandbreite, Latenz etc.).

Die Hersteller müssen die Basissicherheit und wesentlichen Leistungsmerkmale (siehe IEC 60601-1) gewährleisten.

Zudem betont die FDA, dass die Hersteller die Risiken über den kompletten Produktlebenszyklus (also nicht nur bei der Entwicklung, sondern auch in der Post-Market-Phase) analysieren und beherrschen müssen.

D) Verifizierung und Validierung

Weiter nennt die FDA Beispiele dafür, was die Hersteller beim „Testen“ (der Verifizierung und Validierung) berücksichtigten sollten:

  • Erkennung korrupter Daten
  • Sicherer Betrieb auch bei Daten außerhalb von Wertebereichen
  • Übergang in den sicheren Zustand
  • Konformität mit Interoperabilitätsstandards (wenn diese festgelegt wurden)
  • Autorisierung und Authentisierung
  • Gebrauchstauglichkeit
  • Auswirkungen auf das Netzwerk und andere Geräte und Systeme
  • Diese Tests sollen die Hersteller in simulierten Nutzungsumgebungen durchführen.

E) „Labeling“

Beschriftungen, Gebrauchs- und Installationsanweisungen und weitere Elemente des „Labelings“ sollen dafür ebenfalls zur Minimierung von Risiken beitragen. Was das Labeling genau enthalten soll, beschreibt das Guidance Document im Kapitel VI Teil D.

F) „Consensus Standards“

Die FDA weist (empfehlend) auf die „Consensus Standards“ hin, ohne im Dokument direkt welche zu benennen. Vielmehr verlinkt sie die Liste dieser Standards. Beispiele für diese Standards finden Sie weiter unten gelistet.

Tipp

Nutzen Sie dieses Kapitel V dazu, um Ihren Entwicklungsplan zu ergänzen bzw. auf Vollständigkeit zu prüfen!

Kapitel VI: ‚Recommendations for Contents of Pre-market Submissions‘

Im Kapitel VI beschreibt die FDA, welche Informationen sie bei der Einreichung für ‚interoperable medical devices‘ erwartet. Diese Informationen entsprechen im Wesentlichen den im Kapitel V genannten. Daher seien hier nur einige Besonderheiten dieses Kapitels erwähnt:

  • Die Dokumentation sollte ggf. beinhalten: Zweck und Technologien der Schnittstelle, verwendete Standards, Art der ausgetauschten Daten, funktionale und nicht funktionale Anforderungen, ggf. Beschreibung der API
  • Die ISO 14971 und die Forderungen der 21 CFR part 820.30(g) sind zu beachten.
  • Bei kritischen Anwendungen wie Infusionspumpen kann es sein, dass alle Testspezifikationen und -ergebnisse einzureichen sind. Bei unkritischen genügen ggf. Zusammenfassungen.
  • Das Labeling muss auch den Anforderungen des 21 CFR part 801 und 809 genügen.
  • Das Labeling (gemeint ist wahrscheinlich v.a. die Gebrauchsanweisung) sollte die im Kapitel V in den Unterkapiteln A und B genannten Aspekte beschreiben. Auch sollten den Anwendern Möglichkeiten gegeben werden, das korrekte Funktionieren der Schnittstellen zu prüfen.

Wie Sie die Anforderungen erfüllen können

Dokumente ergänzen

Das FDA Guidance Document ‚Interoperable Medical Devices‘ stellt Anforderungen an die Entwicklung und Dokumentation von Medizinprodukten. Sie können diese Anforderungen umsetzen, indem Sie die folgenden Schritte gehen:

  1. Zweckbestimmung ergänzen
    Stellen Sie sicher, dass die Zweckbestimmung Ihrer Medizinprodukte die in diesem Guidance-Dokument genannten Punkte festlegt wie z.B.
    – Klinischer Kontext
    – Einzubindende Geräte
    – Vorgesehene Anwender
    – Zweck des Datenaustauschs
  2. System-/Software Requirements Specification ergänzen
    Ergänzen Sie die Anforderungsdokumente. Spezifizieren Sie darin die Systeme / Software als Blackbox. Nutzen Sie das Blackbox-Modell.
    Lesen Sie mehr zu diesem Thema in den Artikeln über das Blackbox-Modell und Anforderungen
    Nutzen Sie Consensus Standards wo immer möglich. Mehr dazu lesen Sie weiter unten.
  3. Gebrauchs- und Installationsanweisungen ergänzen
    Mit diesen Festlegungen ergänzen Sie Ihre Anweisungen für die Anwender. Nutzen Sie Kapitel VI D als Checkliste, um die Vollständigkeit zu gewährleisten.
  4. Risikomanagementakte ergänzen
    Ergänzen Sie nun die Risikomanagementakte. Das betrifft die Risikotabelle ebenso wie den Risikomanagementplan, der auch die nachgelagerte Phase beinhalten muss. Ggf. passen Sie den Post-Market Surveillance Plan an. Er soll dazu verpflichten, gezielt und proaktiv nach Informationen über Risiken durch Interoperabilitätsprobleme zu suchen.
  5. Produkt testen
    Führen Sie die Verifizierungs- und Validierungsaktivitäten durch. Die System bzw. Software Requirements Specification und das Kapitel VI C dienen Ihnen dabei als Input.
    Eine große Herausforderung wird darin bestehen, Systemumgebungen zu schaffen, die repräsentativ für die echten Umgebungen sind.

„Consensus Standards“ einhalten

Die FDA hat eine umfangreiche Liste an Consenus Standards publiziert wie die folgenden:

  • ISO/IEEE 11073–10417 Third edition 2017–04 Health informatics—Personal health device communication—Part 10417: Device specialization—Glucose meter.
  • ISO/IEEE 11073–10418 First edition 2014–03–01 Health informatics—Personal health device communication—Part 10418: Device specialization: International Normalized Ratio (INR) monitor [including TECHNICAL CORRIGENDUM 1 (2016)].

Diese Liste wurde, wie Sie am Datum erkennen, auch kürzlich aktualisiert.

Sie finden diese Consenus Standards auf der Seite der FDA, in dem Sie dort im Feld „Standards Title or Keywords“ das Schlagwort „Informatics“ eingeben:

Suchmaske FDA Consensus Standards

Abb. 2: Suchmaske FDA Consensus Standards (zum Vergrößern klicken)

Zusammenfassung und Fazit

Eineinhalb Jahre hat die FDA benötigt, um den Entwurf in ein finales Dokument zu überführen. Dieses mit 21 Seiten kompakte und lesbare Guidance Document verdient das Prädikat nützlich.

Dass die FDA ständig nur von „legally non binding“ und von „recommendation“ spricht, ist irreführend, um nicht zu sagen unehrlich: Das sind „harte Forderungen“. Schließlich erwartet die US-Behörde bei Einreichungen genau diese in diesem Dokument genannten Informationen.

Das Guidance Document nennt keine „Consensus Standards“, sondern verweist auf die Liste der publizierten. Das macht das Dokument „wartbar“. Die Liste der Consensus Standards ist aber (zu) sehr auf (physische) Medizingeräte und die Normenfamilie ISO/IEC 11071 beschränkt. Für Stand-alone-Software hätte man sich mehr Hilfestellung gewünscht.


Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Regulatory Affairs, Software & IEC 62304
Tags: , , , , ,

Kommentar schreiben