Nach dem ersten App-Hype stellen viele Hersteller inzwischen etwas ernüchtert fest: Medical Apps sind auch nur (fast) normale Produkte, und die rechtlichen Hürden sind schwer zu überwinden.
Die App-Stores der Internetgiganten Apple und Google freuen sich über Milliardenumsätze. Diesen einfachen Zugang zu globalen Märkten möchten Startups ebenso nutzen wie etablierte Unternehmen, auch in der Gesundheitsbranche. So verwenden Pharmaunternehmen Apps als Instrument für das digitale Marketing. Anwendungen zur Medikationsauswahl und Dosisberechnung haben fast alle Branchengrößen in der Entwicklung oder bereits im Angebot. Hersteller klinischer Informationssysteme möchten Anwendern einen Zugang zu den Systemen auch via Mobilgerät gewähren. Unternehmen, die Sensoren beispielsweise zur Blutzucker- oder EKG-Messung herstellen, vertreiben Hardware-Erweiterungen für Smartphones und Tablets. Forschungseinrichtungen – aber auch selbst ernannte Experten – entwickeln Systeme zur Berechnung von Scores, Diagnosen und Therapieempfehlungen.
Den Wildwuchs, der sich dabei zum Teil entwickelt, beobachten Behörden mit wachsender Sorge. Das hat beispielsweise die FDA bewogen, 2013 ein „Guidance Document“ zu Mobile Medical Apps zu publizieren. Das Erstaunliche: Obwohl die FDA die App-Stores bisher sehr aktiv überwacht – im Gegensatz zu den meisten europäischen Behörden–, hat sie in dem neuen Dokument angekündigt, einige „unkritische“ Apps nicht den strengen Regularien unterwerfen zu wollen („enforcement discretion“). Das bedeutet, es gibt eine neue Klasse von Apps, die zwar Medizinprodukte sind, aber nach Ansicht der FDA ein so geringes Risiko aufweisen, dass der Hersteller sie nicht zulassen muss. Die FDA ignoriert sie gewissermaßen.
Die gesetzlichen Anforderungen an Medizinprodukte in Europa und den USA sind zwar insgesamt vergleichbar. Weder hier noch dort gibt es aber spezifische Regularien für medizinische Apps, so dass die bestehenden Gesetze auf Apps übertragen werden. In den USA muss der Hersteller für die Zulassung einer App einen umfangreichen Dokumentensatz einreichen, der unter anderem eine Risikomanagementakte und eine „Software-Akte“ mit einer Beschreibung von Software-Anforderungen, Software-Architektur, Tests und so weiter beinhaltet. Zudem verlangt die FDA, die „Quality System Regulations“ zu befolgen. Es muss also ein QM-System etabliert sein, was im Rahmen von Inspektionen beim Hersteller überprüft wird. Das Guidance Document schafft hiervon Ausnahmen.
In Europa müssen Hersteller vergleichbare Dokumente bereitstellen. Die Klasse des Medizinprodukts entscheidet aber darüber, ob ein QM-System erforderlich ist und die Akten bei einer benannten Stelle eingereicht werden müssen. Erleichterungen, wie sie das Guidance Document vorsieht, gibt es dagegen nicht.
Darüber hinaus sind in der EU einige Details wichtig wie die Frage nach dem Inverkehrbringer. Inzwischen herrscht Konsens, dass nicht die Betreiber der Stores die Inverkehrbringer sind, sondern die Hersteller. Wie diese aber der Anforderung des deutschen Medizinproduktegesetzes an einen Medizinprodukteberater Rechnung tragen sollen, ist meist ungeklärt.
Dann gilt es, die Systemabgrenzung festzulegen. Besteht das Medizinprodukt nur aus der App oder auch aus einer Server-Komponente? Falls der Hersteller den Server betreibt, wird er auch im gesetzlichen Sinn zum Betreiber und unterliegt damit in Deutschland der Medizinproduktebetreiber-Verordnung. Der Konsequenzen sind sich viele nicht bewusst: Sie reichen von einer Meldepflicht bei Vorkommnissen über die Pflicht zum Führen eines Medizinproduktebuchs bis zur Notwendigkeit sicherheitskritischer Kontrollen.
Weitere Besonderheiten ergeben sich beim Risikomanagement. Wer eine App zum Download anbietet, muss davon ausgehen, dass die sprachlichen und intellektuellen Fähigkeiten der Anwender ebenso heterogen sind wie deren Ausbildung, deren spezifische Vorkenntnisse und Erfahrungen. Dies erschwert das Abschätzen von gebrauchstauglichkeitsbedingten Risiken. Andererseits sind die im App-Store hinterlegten Kommentare ein strukturierter Kanal, um Rückmeldungen zu sammeln und auszuwerten, was nicht nur die ISO 14971 fordert. Eine weitere Herausforderung ist die explodierende Anzahl an Typen von Mobilgeräten, die ein vollständiges Testen nahezu unmöglich macht.
Vor diesem Hintergrund klingen die anfängliche Euphorie und der Wunsch vieler, „einfach mit einer eigenen App dabei sein“ zu wollen, ab. Sie weichen der Erkenntnis, dass Apps – wie klassische Medizinprodukte – einen ökonomischen Sinn ergeben müssen, was im Gesundheitswesen in seltenen Fällen über große Stückzahlen gelingen mag. Die Chancen liegen eher darin, konventionelle Medizinprodukte zu ergänzen oder deren Vermarktung zu unterstützen. Der Aufwand, um die rechtlichen Vorgaben zu erfüllen, bedeutet aber besonders für kleine und in diesem Markt unerfahrene Unternehmen relativ hohe Hürden.
Prof. Christian Johner Institut für Informationstechnologien im Gesundheitswesen, Konstanz
Weitere Informationen Über das Institut für Informationstechnologien im Gesundheitswesen: www.johner-institut.de
Regulatorischer Rahmen
Vereinfacht ausgedrückt sind Medizinprodukte alle Produkte, die der Hersteller dazu vorsieht, Krankheiten und Verletzungen zu diagnostizieren, zu therapieren oder zu überwachen. Dabei ist es unerheblich, ob das Produkt ein physisches Produkt ist oder eine Stand-alone-Software wie eine App, eine Webseite oder eine auf einem Computer zu installierende Anwendung. Ein Gesundheitsratgeber fällt demnach sicher nicht unter diese Definition – eine App, die der Berechnung von Narkosemitteln für Kinder dient, schon. Natürlich gibt es einen Graubereich wie „Berechnungswerkzeuge“, die auf Basis eines vom Patienten zu beantwortenden Fragenkatalogs Empfehlungen zur Lebensführung oder gar Therapie geben. Da das europäische Medizinprodukterecht für diese Gruppe von Apps keine Erleichterung wie das Guidance Document der FDA kennt, sollten Anbieter von Medical Apps gleich zu Entwicklungsbeginn wichtige Voraussetzungen erfüllen:
- Die Hersteller sollten ein Qualitätsmanagement-System gemäß ISO 13485 beziehungsweise 21 CRF part 820 errichten. Es muss unter anderem die Software-Lebenszyklusprozesse wie Entwicklungs- und Wartungsprozess definieren. Im Rahmen des Entwicklungsprozesses gilt es, die Stakeholder-Anforderungen, die Software-Anforderungen, die Software-Architektur, Software-Tests und Reviews zu dokumentieren. Häufig arbeiten die Hersteller konform mit der Norm IEC 62304 oder dem „Software Validation Guidance“ der FDA, um vermuten zu lassen, dass sie diese Forderung nach Software-Lebenszyklusprozessen erfüllen.
- Hersteller sollten ein Risikomanagement etablieren, das konform mit der Norm ISO 14971 ist und dabei hilft, Risiken zu erkennen, zu minimieren sowie die Vertretbarkeit des Nutzen-Risiko-Verhältnisses sicherzustellen.
- Sie sollten ein Usability Engineering betreiben, wozu die Norm IEC 62366 oder der „Human Factors Engineering Guidance“ der FDA als Richtschnur dienen.
- Falls die Hersteller nicht nur eine App, sondern eine Hardware-Erweiterung für das Mobilgerät anbieten, beispielsweise zum Auslesen von Diagnosestreifen, werden die Produkte zu einem so genannten PEMS, einem programmierbaren elektrisch-medizinischen System. Die Gesetze stellen an diese Systeme zusätzliche Anforderungen, wie elektromagnetische Verträglichkeit und elektrische Sicherheit, die gemäß weiterer Normen nachzuweisen sind.
- Erwartungen an Medical Apps
- Ausnahmen in der Überwachung durch die FDA
- Relevante Normen und Vorschriften für den europäischen Markt
- Wirtschaftliche Chancen
Ihr Stichwort
Unsere Whitepaper-Empfehlung
Gewährleisten Sie Sterilität bei Medizinprodukten, wie Implantaten und OP-Material. Das Whitepaper von BGS Beta-Gamma-Service gibt Einblicke in den Ablauf, Vorteile, Validierungsschritte der Strahlensterilisation & wichtige Aspekte beim Wechsel des Sterilisationsverfahrens. Jetzt…
Teilen:
