Mobile Medical Apps – Medizinische Apps

Mobile Medical Apps, auch medizinische Apps genannt, sind Anwendungen für mobile Endgeräte wie Smartphones oder Tablets, die medizinisches Personal oder Patienten bei der Diagnose, Therapie oder Überwachung von Krankheiten oder Verletzungen unterstützen.

1. Medical Apps als Medizinprodukte oder Zubehör

a) Allgemeines

Qualifizierung und Definition „Medizinprodukte“

Ob Medical Apps als Medizinprodukte zählen, hängt von den Gesetzen in den jeweiligen Märkten ab.

• In Europa gilt die Definition des Begriffs Medizinprodukt im Artikel 2 der MDR. Zudem ist die MDCG-Leitlinie 2019-11 zu beachten.
• In den USA definiert der „Food, Drug & Cosmetics Act“, was Medizinprodukte sind. Er schließt viele Software-Anwendungen aus. Die FDA hat ein Guidance-Dokument zu Medical Apps veröffentlicht, welche dieses Gesetz erläutert (s.u.).

Definition „Mobile“

Die EU definiert nicht, wann ein Medizinprodukt „mobil“ ist. Einzig die IEC 60601-1 (dazu später mehr) kennt das Konzept „tragbarer“ Medizingeräte.

Laut FDA sind „Mobile Applications“ Software-Anwendungen, die auf mobilen Plattformen wie kommerziellen „Handhelds“ laufen, wobei es unwesentlich ist, ob diese über eine drahtlose Verbindung (WLAN oder 5G) verfügen oder nicht. Auch Webanwendungen, die speziell für Mobilgeräte ausgelegt sind, fallen unter die Definition „Mobile Application“.

b) Beispiele

Medical Apps, die als Medizinprodukte zu qualifizieren sind

Sowohl in der EU als auch den USA gelten als Medizinprodukte:

• Apps, die Berechnungen oder Analysen für individuelle Patienten durchführen, z. B. Software für die Analyse von Labordaten
• Apps, die Medikamentendosen berechnen oder Wechselwirkungen identifizieren
• Apps, die der Diagnostik von radiologischen Bildern dienen

In Deutschland sind alle digitalen Gesundheitsanwendungen (DiGA) per definitionem Medizinprodukte.

Medical Apps im Graubereich

Die FDA nennt Beispiele für mobile Apps, die in den Graubereich fallen und einzeln zu bewerten sind:

• Apps, die Patienten unterstützen, ihren Alltag als Patient zu meistern, z. B. um die regelmäßige Einnahme von Medikamenten sicherzustellen
• Apps, mit denen Patienten ihre Werte dokumentieren und verfolgen, wie Blutdruck, Schmerzen oder andere Routinetätigkeiten
• Apps, die den Patienten für sie spezifische Informationen für ihre Krankheit zur Verfügung stellen
• Apps, über die Patienten mit ihren Ärzten kommunizieren können

In Europa zählen Apps, die ausschließlich Daten weiterleiten, anzeigen oder abspeichern, nicht als Medizinprodukte.

Medical Apps, die keine Medizinprodukte sind

Weiter gibt es Apps, die in den USA und in Europa nicht als Medizinprodukte qualifizieren:

• Apps, die einer elektronischen Kopie eines Buchs oder Nachschlagewerks entsprechen
• Apps, die der Ausbildung z. B. von klinischem Personal oder Patienten dienen
• Apps, die der Abrechnung dienen
• Apps, die nicht spezifisch für den medizinischen Bereich entwickelt wurden, z. B. eine digitale Lupe

Apps, die Zubehör sind

Zubehör ist zwar definitionsgemäß kein Medizinprodukt. Aber es gelten die gleichen regulatorischen Anforderungen. Beispiele für Medical Apps, die als Zubehör gelten können, sind:

• Remote-Control für einen Röntgentisch
• Service-Werkzeug, z. B. zum Diagnostizieren oder Kalibrieren eines Medizingeräts
• Apps, die Messwerte eines Medizinprodukts anzeigen
• Apps, die zu einer Erweiterung der Plattform gehören oder diese ansteuern; Beispiel: eine Blutzuckermesseinheit, die man ans Mobiltelefon andockt, um sie zu starten oder um Werte auszulesen, zu berechnen und anzuzeigen

2. Regulatorische Anforderungen an Medical Apps

a) Anforderungen, die für alle Medizinprodukte und für SaMD gelten

Mobile Medical Apps, die Medizinprodukte sind, müssen die gleichen regulatorischen Anforderungen erfüllen wie alle anderen Medizinprodukte. Das sind insbesondere:

• Qualitätsmanagementsystem
• Risikomanagementsystem
• Gebrauchstauglichkeit
• Software-Lebenszyklus-Prozesse
• IT-Sicherheit und Datenschutz

b) Spezifische Anforderungen an mobile Anwendungen

Europa

Die MDR geht nur im Anhang I auf mobile Anwendungen ein:

Bei der Auslegung und Herstellung der in diesem Abschnitt behandelten Software, die zur Verwendung in Verbindung mit mobilen Computerplattformen bestimmt ist, werden die spezifischen Eigenschaften der mobilen Plattform (z. B. Größe und Kontrastverhältnis des Bildschirms) und die externen Faktoren im Zusammenhang mit ihrer Verwendung (sich veränderndes Umfeld hinsichtlich Lichteinfall und Geräuschpegel) berücksichtigt.

MDR, Anhang I, Abschnitt 17.3

Anforderungen an die Barrierefreiheit gelten nicht nur für mobile Apps, sondern beispielsweise für alle DiGA.

USA

Die FDA hat ein Guidance-Dokument speziell für Mobile Medical Apps veröffentlicht. Eine Besonderheit ist das Konzept der „Enforcement Discretion“. Hier gibt sich die Behörde die Freiheit, fallweise zu entscheiden, ob sie die regulatorischen Anforderungen an Medizinprodukte einfordert.

Neben den Anforderungen der FDA sollten die Hersteller auch die Anforderungen der FTC mit der Health Breach Notification Rule und HIPAA beachten, auch wenn diese nicht spezifisch für Medical Apps sind.

IEC 60601-1 In Europa müssen Hersteller, die „nur“ Medical Apps für handelsübliche Endgeräte (Tablets und Smartphones), aber keine spezifische Hardware dafür entwickeln, nicht die elektromagnetische Verträglichkeit und elektrische Sicherheit nachweisen. Die zugehörige Norm IEC 60601-1 ist nicht anwendbar. Allerdings würde eine Erweiterung des Endgeräts, etwa ein physischer Aufsatz für ein Smartphone, um Blutzuckermessstreifen auszuwerten, diese Vereinfachung zunichtemachen.

3. Besondere Herausforderungen für die Hersteller

Herausforderung 1: Vielfalt der Plattformen für Medical Apps

Während klassische Medizingerätehersteller embedded Software für genau eine Laufzeitumgebung (z. B. Hardware, Betriebssystem) entwickeln, müssen App-Entwickler eine Vielzahl an Plattformen unterstützen. Diese Vielfalt betrifft:

• Die Hardware, insbesondere die Formfaktoren, Bildschirmgrößen und Bildschirmauflösungen. Wir sind bereits auf fatale Probleme gestoßen, weil UI-Elemente auf kleinen Bildschirmen nicht (richtig) angezeigt wurden.

• Die Betriebssysteme: Besonders bei Android ist der Zoo an Versionen kaum zu überblicken.

• „Runtime“: Bei Medical Apps zählen dazu v. a. die Browser mit ihren JavaScript Engines, die Java Runtime oder die .NET-Laufzeitumgebung. Wer glaubt, dass Webseiten mit identischem HTML, CSS und JavaScript Code in verschiedenen Browser gleich angezeigt werden, hat noch nie ernsthafte Webentwicklung betrieben.

• Weitere Software: Die Medical Apps teilen sich die Plattform mit anderen Apps, die fehlerhaft sein oder bei der Installation Komponenten austauschen können. Das lässt sich kaum vorhersagen.

Herausforderung 2: Vielfalt der Nutzer und Nutzungsumgebungen

Für ein HF-Chirurgiegerät ist es vergleichsweise einfach, die Nutzer und Nutzungsumgebungen zu spezifizieren. Bei Medical Apps, die oft ohne Einschränkungen auf einen Nutzerkreis angeboten werden, kann diese Aufgabe zur Herausforderung insbesondere im Risikomanagement werden:

• Verschiedene Sprachen und Kulturkreise, intellektuelle und körperliche Fähigkeiten und die unterschiedlichen mentalen Modelle der Nutzer haben nur schwer vorhersagbare Auswirkungen auf das Nutzungsverhalten und damit auf Risiken.
• Die Umgebungsbedingungen sind häufig unbekannt. Nutzen die Anwender die Medizinprodukte-App im Büro oder während der Autofahrt? Bei Helligkeit oder Dunkelheit? Mit oder ohne (OP-)Handschuhe?
• Die internationale Verbreitung führt zu weiteren Herausforderungen, der sich App-Entwickler stellen müssen: Die Apps müssen umgehen können mit unterschiedlichen Sprachen (des Betriebssystems), Zahlenformaten (z. B. Dezimaltrennzeichen), Währungen, Zeichensätzen (Encoding) und Zeitzonen (Mit welcher Zeit sollen Berechnungen durchgeführt werden, der des Clients oder der des Servers?).

Herausforderung 3: Technologien und Entwicklung

IT-Sicherheit

Mobile Medical Apps nutzen meist Server-Funktionalitäten. Damit sind sie aber von einer sicheren Client-Server-Kommunikation abhängig.

Iterative Entwicklung, kurze Entwicklungszyklen

Weiter ist es im App-Umfeld üblich, mehrere Releases pro Quartal, manchmal pro Monat zu veröffentlichen. Die Entwicklungszyklen werden ebenso wie die Technologiezyklen immer kürzer. Das birgt potenzielle Probleme:

• Das agile Vorgehen erfolgt nicht konform mit den Regularien wie der IEC 62304. Man trifft ad hoc Design-Entscheidungen, hält sich nicht an den Entwicklungsplan und schlampt bei der Verifizierung und Validierung.
• Insbesondere versäumt es der Hersteller bei Änderungen, die Usability Validierung zu wiederholen.
• Das Produkt und die zugehörige Dokumentation laufen auseinander.
• Die Hersteller begleiten die raschen Änderungen nicht durch ein adäquates Risikomanagement.
• Die SOUPs, die es bei Apps in besonders hoher Anzahl gibt, werden nicht ausreichend beschrieben und untersucht.
• Der Prozess der Konformitätsbewertung und das Einbeziehen benannter Stellen halten mit dieser Geschwindigkeit nicht mit.

Herausforderung 4: Regularien, Gesetze und mehr

Abgrenzung des Produkts

Viele App-Hersteller, speziell wenn sie einen Server-Teil entwickeln, können nicht benennen, was Teil des Medizinprodukts ist. Gehört die Server-Hardware dazu? Das Betriebssystem des Servers? Der Web-/Applikationsserver? Die Datenbank? Die PHP-Laufzeitumgebung?

Diese Unklarheit rührt auch daher, dass es häufig nur genau eine Instanz des Produkts (zumindest des Server-Teils) gibt. „Normale“ Medizinprodukte werden hingegen oft millionenfach verkauft. Hier ist klar, was dazugehört und was nicht.

Anforderungen an den Datenschutz

Medical Apps gehen mit medizinischen Daten um. Die entsprechenden Datenschutzbestimmungen einzuhalten, ist herausfordernd; insbesondere, wenn es sich um viele Länder handelt. Dabei muss auch geklärt werden, welche Gesetze welchen Landes anzuwenden sind: Das Land, in dem sich der Nutzer befindet? Das Land, in dem der Server steht? Das Land, dem der Patient entstammt?

Klassifizierung

In Europa fallen wegen der Regel 11 der MDR fast keine Apps mehr in die Klasse I. Damit muss selbst bei unkritischen Apps eine Benannte Stelle einbezogen werden. Das verzögert die Inverkehrbringung dieser Produkte erheblich.

Hersteller ist auch Betreiber

Sobald der Hersteller auch den Server betreibt (oder betreiben lässt), muss er  die gesetzlichen Vorschriften beachten, die sich an die Betreiber wenden. Stichpunkte sind hier die MPBetreibV oder die IEC 80001.

Mangelnde Erfahrungen

In kaum einer Produktklasse gibt es so viele neue „Player“, die vom Medizinprodukterecht wenig Ahnung haben, wie bei den Medical Apps: Agenturen, Marketingabteilungen, Medical Startups. Aber Unwissenheit schützt nicht vor Strafe.