Software als Medizinprodukt: Definition und Geltungsbereich der Vorschriften
Veröffentlicht: 2019-09-06Seit den letzten 40 Jahren hat die Zahl der technologischen Innovationen sowohl innerhalb als auch rund um medizinische Geräte dramatisch zugenommen. Insbesondere in den letzten 20 Jahren hat sich der Sektor dank des Internets der Dinge und des Aufstiegs seiner anderen entsprechenden Teile wie drahtlose Konnektivität, Cloud-Computing und KI usw. beschleunigt. Diese Fortschritte haben die Prozesse im Gesundheitswesen verändert.
Auch nach 20 Jahren sorgen diese Spitzentechnologien weiterhin für eine seismische Veränderung im Prozess der Gesundheitsverwaltung und -versorgung.
Und jetzt haben auch mobile Anwendungen Einzug gehalten und sind zu einem wichtigen Bestandteil dieser stark nachgefragten, technologiebasierten medizinischen und nichtmedizinischen Zwecke geworden.
Diese Apps oder Software, die ein eigenständiges medizinisches Gerät sind – die Größe des Marktes für Software als medizinisches Gerät , ist zu einem festen Bestandteil des Lebens der Benutzer geworden. Die Anwendungen von SaMD beschränken sich nicht nur auf die Diagnose, sondern haben sich auch im Überwachungs- und Behandlungsprozess etabliert. Tatsächlich hat SaMD zur Entwicklung des Gesundheitswesens 1.0 zum Gesundheitswesen 3.0 geführt .
Angesichts der zunehmenden Einbeziehung von SaMD in die tägliche Gesundheitsversorgung hat das International Medical Device Regulators Forum (IMDRF), dem die US-amerikanische FDA angehört, das Konzept und die SaMD-Risikokategorien im Detail beschrieben, damit die Medizin-App-Entwicklungsbranche folgen kann. Die FDA -Software als Medizinprodukt hat risikobasierte Richtlinien für eine bessere Kommunikation der Anforderungen entwickelt und präzisiert und ihren regulatorischen Ansatz an die sich entwickelnde Natur digitaler Geräte angepasst.
* SaMD ist nicht die einzige Konformität, die Interessenvertreter der Gesundheitsbranche – Unternehmer von mHealth-Anwendungen und Gerätehersteller – befolgen sollten. Es gibt auch andere Konformitäten wie FDA, HIPAA, HL7 und FCPA. Wir haben diese Konformitäten ausführlich in unserem In diesem Artikel beleuchten wir SaMD, Software als Medizinprodukt-Verordnung, mHealth-App-Typen und andere Arten von medizinischer Software , die als Software als Medizinprodukt kategorisiert werden.
Inhaltsverzeichnis
- Was ist Software als Medizinprodukt?
- Woher wissen Sie, ob Ihre mobile App ein SaMD ist?
- Zu berücksichtigende Faktoren für die SaMD-Charakterisierung
- Was sind Beispiele für Software als Medizinprodukt?
- Wie klassifizieren Sie Software als Medizinprodukt?
- Was können SaMD-Hersteller tun, um Vorschriften zu gewährleisten?
- Fazit
- Häufig gestellte Fragen zu SaMD
Was ist Software als Medizinprodukt?
Die Terminologie – Software as a Medical Device steht für jede Software, die zur Verwendung für einen oder mehrere medizinische Zwecke bestimmt ist und diese Zwecke erfüllt, ohne in ein Hardware-Medizingerät integriert zu sein.
So definiert IMDRAF SaMD –
„Der Begriff „Software als Medizinprodukt“ (SaMD) ist definiert als Software, die dazu bestimmt ist, für einen oder mehrere medizinische Zwecke verwendet zu werden, die diese Zwecke erfüllen, ohne Teil eines medizinischen Hardwaregeräts zu sein.“
Woher wissen Sie, ob Ihre mobile App ein SaMD ist?
- SaMD ist ein Medizinprodukt und umfasst einige medizinische In-vitro-Diagnostika (IVD).
- Es kann auf allgemeinen (nicht medizinischen) Computerplattformen ausgeführt werden.
- Software erfüllt nicht die Definition von SaMD, wenn ihr bestimmungsgemäßer Zweck darin besteht, Hardware- Medizingeräte anzutreiben .
- Es kann mit anderen Produkten wie medizinischen Geräten verwendet werden.
- Es kann mit anderen medizinischen Geräten verbunden werden, einschließlich medizinischer Hardwaregeräte und anderer SaMD-Software sowie Allzwecksoftware.
Zu berücksichtigende Faktoren für die SaMD-Charakterisierung
Es gibt zwei Möglichkeiten, wie SaMDs charakterisiert werden:
Informationen von SaMD
- Um Patienten zu diagnostizieren oder zu behandeln
- Um das klinische Management zu informieren
- Um das klinische Management voranzutreiben
Gesundheitszustand
- Kritischer Zustand
- Ernster Zustand
- Nicht ernster Zustand
Auf der Grundlage dieser Charakterisierungen werden SaMDs in vier Kategorien eingeteilt.
Was sind Beispiele für Software als Medizinprodukt?
- Software als medizinisches Gerät kann mit anderen medizinischen Geräten, einschließlich medizinischer Hardware, und anderer Software als klinisches Gerät, auch als Software für den allgemeinen Gebrauch, verbunden werden. Software, die Grenzen setzt, wird zum Input für eine andere Hardwareausstattung oder andere SaMD. Beispielsweise kann eine Software als medizinisches Gerät eine Therapieplanungssoftware sein, die Daten bereitstellt, die in einem Linearbeschleuniger verwendet werden, wie SaMD.
- Zum Beispiel wird Software, die für die Analyse eines Zustands unter Verwendung des dreiachsigen Beschleunigungsmessers erwartet wird, der auf dem installierten Prozessor einer Digitalkamera für Verbraucher arbeitet, als Software als medizinisches Gerät betrachtet.
- Software, die mit einem medizinischen Hardwaregerät verbunden ist, aber von diesem Gerät nicht benötigt wird, um seinen medizinischen Zweck zu erfüllen, ist Software als medizinisches Gerät und kein Zubehör für das medizinische Gerät.
- SMD-Software kann auf Computerplattformen für allgemeine Zwecke (dh für nicht klinische Zwecke) ausgeführt werden. Diese Software, die auf diesen Allzweck-Computerplattformen läuft, könnte sich in einem medizinischen Hardwaregerät befinden.
Kategorieweise Beispiele für SaMD
Kategorie IV:
- SaMDs, die eine diagnostische Bildanalyse durchführen, um Behandlungsentscheidungen zu ermöglichen, wenn Patienten einen akuten Schlaganfall erleiden
- SaMDs, die die fraktale Dimension einer Läsion berechnen und eine strukturelle Karte erstellen, die verschiedene Wachstumsmuster aufzeigt, um eine Diagnose oder Identifizierung zu ermöglichen, wenn die Läsion gutartig oder bösartig ist.
- SaMDs kombinieren Daten aus den Immunoassays , um nach dem Ausbruch mutierbarer Krankheitserreger zu suchen, die hochgradig übertragbar sein können.
Kategorie III:
- SaMD, das das Mikrofon des Telefons verwendet, um Atemaussetzer während des Schlafs zu erkennen.
- Es wird verwendet , um Informationen bereitzustellen, indem Bilder angeklickt, das Wachstum oder andere Daten überwacht werden, um andere Informationen zu ergänzen, die ein Gesundheitsdienstleister zur Diagnose verwendet, ob eine Hautläsion gutartig oder bösartig ist.
Kategorie II:
- SaMDs, das die Herzfrequenz analysiert.
- SaMD, die die Gesundheitsdaten von Einzelpersonen verwenden, um die Risiken von Herzerkrankungen oder Schlaganfällen vorherzusagen und Präventionsstrategien zu entwickeln.
- SaMD, die mehrere Tests integrieren und analysieren, um Empfehlungen für die Diagnose bei bestimmten klinischen Indikationen zu geben.
Kategorie I:
- Software für medizinische Geräte , die Daten aus Symptomtagebüchern sammelt , um Informationen bereitzustellen, um das Auftreten eines Asthmaanfalls einzuschätzen.
- Software medizinische Geräte , die Bilder analysieren, Augenbewegungen zur Führung der nächsten diagnostischen Maßnahme für Astigmatismus.
- Software , die historische Blutdruckinformationen speichert , damit Gesundheitsdienstleister sie überprüfen können.
- Software , die Daten zur Hörempfindlichkeit, Sprache im Lärm verwendet und Benutzer auffordert, Fragebögen zu häufigen Hörsituationen zur Selbsteinschätzung des Hörverlusts zu beantworten.
Wie klassifizieren Sie Software als Medizinprodukt?
Die neue EU-MDR (The European Union Medical Device Regulation) gibt Definitionen, Regeln, Klassifizierungen und Verfahrensnotwendigkeiten für Medizinprodukte-Softwarestandards vor.
Der Anhang VIII der EU-MDR spricht von verschiedenen Software-Klassifizierungsregeln für Medizinprodukte.
Regel 11 in Anhang VIII bezieht sich auf die Klassifizierung von Software und befasst sich speziell mit der Klassifizierung von Software, die allein oder in Kombination mit Medizinprodukten verwendet wird.
Software, die dazu bestimmt ist, Daten bereitzustellen, die verwendet werden, um Entscheidungen in Bezug auf Diagnose- oder Therapiezwecke zu treffen, wird als Klasse IIa eingestuft, außer wenn diese Entscheidungen Auswirkungen haben, die zum Tod oder zu einer irreversiblen Verschlechterung der Gesundheit einer Person führen können. In solchen Fällen handelt es sich um Klasse III oder eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person oder einen chirurgischen Eingriff, in diesem Fall wird sie als Klasse IIb eingestuft.
Software, von der erwartet wird, dass sie physiologische Prozesse durchleuchtet, wird als Klasse IIa delegiert, außer wenn sie zur Beobachtung wesentlicher physiologischer Parameter vorgeschlagen wird, wenn die Art der Vielfalt dieser Parameter eine unmittelbare Bedrohung für den Patienten darstellen könnte, was in diesem Fall der Fall ist namens Klasse IIb. Alle andere verbleibende Software wird als Klasse I delegiert.
Zum Beispiel wird Software, die zum Screenen von Herzfrequenzen oder einigen anderen physiologischen Parametern während einer Routineuntersuchung verwendet wird, als Klasse IIa delegiert. Wenn sich die Überwachung zufällig auf zwingende physiologische Parameter konzentriert und diese Parameter zu einer unmittelbaren Gefährdung des Patienten führen könnten, wird die Einstufung in Klasse IIb angehoben.
Was können SaMD-Hersteller tun, um Vorschriften zu gewährleisten?
SaMD-Unternehmen sollten über ein gutes Qualitätsmanagementsystem verfügen, das in den Entwicklungsprozess integriert ist, um die Einhaltung aller Vorschriften sicherzustellen. Die gewählte QMS-Plattform sollte in der Lage sein, regulatorische Anforderungen wie FDA 21 CFR Part 820 und ISO 13485:2016 zu erfüllen.
Jeder Fehltritt in die Richtung kann zu schwerwiegenden Konsequenzen führen, wobei die Sperrung Ihrer Anwendung nur der Wendepunkt ist. In Anbetracht der Wichtigkeit wird empfohlen, dass Sie mit einem Unternehmen für die Entwicklung von kundenspezifischer Software für das Gesundheitswesen zusammenarbeiten , das mit Ärzten zusammenarbeitet, die diese Vorschriften und Konformitäten in ihrer Gesamtheit verstehen.
Fazit
Unternehmen für die Entwicklung von Gesundheits-Apps in den USA , die derzeit Software entwickeln, die in Verbindung mit medizinischen Geräten oder als eigenständiges medizinisches Gerät verwendet werden soll, sollten sich dieser Änderungen bewusst sein und sicherstellen, dass sie Maßnahmen ergreifen, um sicherzustellen, dass ihre Software mit dem neuen Regime konform ist.
Häufig gestellte Fragen zu SaMD
F. Was sind Beispiele für Software, die nicht SaMD ist ?
- Apps, die medizinische Hardwaregeräte benötigen, um ihre Rolle zu erfüllen.
- Apps, die von den Medizinproduktedaten abhängig sind.
- Apps, die die Kommunikation und Rationalisierung des klinischen Arbeitsablaufs ermöglichen, z. B. für die Planung von Besuchen, Video- oder Sprachanrufen usw
Die App-Beispiele sind nicht darauf beschränkt. Es gibt eine Reihe anderer App-Typen, die nicht unter die Definition von SaMDs fallen.
F. Was kann Software als Medizinprodukt eigentlich?
SaMD-Anwendungen sind solche, die als eigenständige Gesundheitsanwendung fungieren, die Benutzern einen Einblick in ihre körperliche Gesundheit geben, indem sie Diagnosen stellen, Röntgenaufnahmen machen oder Insulindosen berechnen.
F. Was ist IEC 62304?
IEC 62304 ist ein Standard, der die Lebenszyklusanforderungen spezifiziert, die für die Erstellung von Software als Medizinprodukt und Software in Medizinprodukten erforderlich sind. Zusammen mit ISO 13485 verwendet, bietet es einen Rahmen, der für die sichere Entwicklung und Wartung von Software für medizinische Geräte wichtig ist.
F. Beschreiben Sie Ihren QMS-Prozess für die Entwicklung von Software für medizinische Geräte
Wir haben unser eigenes internes QMS für die Zusammenarbeit mit Kunden aus dem Bereich Medizinprodukte und Pharmazeutika, um unsere eigene Qualität sicherzustellen. Wir werden nicht von Kunden, Dritten oder Aufsichtsbehörden geprüft.
Stufe 1 : Projekt initiieren: Führen Sie eine Auftakt-Telefonkonferenz mit dem Kunden durch, um:
Überprüfen Sie den Projektplan und den Zeitplan
Schließen Sie die wichtigsten Informationsquellen ab
Definieren Sie das Projektteam
Stufe 2 : Überprüfung der Dokumentation: Bewerten und untersuchen Sie alle relevanten Dokumente, einschließlich vorhandener Produktinformationen, nichtklinischer Daten/Pläne und regulatorischer Dokumentation. Die Quellen dieser Informationen sind:
Nichtklinische Daten, Zulassungskorrespondenz, technische Produktspezifikationen, Verweise auf Prädikatsprodukte, vorgeschlagene Produktansprüche und Verwendungszwecke/-indikationen usw.
Phase 3 : Bestimmen des Zulassungswegs Entwickeln Sie anhand der Informationen aus dem obigen Abschnitt einen FDA-Zulassungsweg, um festzustellen, ob 510(k) oder de novo am besten geeignet ist (eine PMA-Zulassungsstrategie ist komplexer und erfordert ein höheres Budget). Das Ziel besteht darin, den Kunden bezüglich des optimalen Ansatzes für die FDA zu beraten.