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.

Inhalt

Diese Seite verschafft einen schnellen Überblick über die Medical Apps und verlinkt für ein vertieftes Verständnis auf weiterführende Fachartikel.

  1. Mobile Medical Apps als Medizinprodukte und Zubehör
  2. Regulatorische Anforderungen an Mobile Medical Apps
  3. Besondere Herausforderungen
  4. Unterstützung für Hersteller von Medical Apps

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.).
Weiterführende Informationen

Weitere Hilfestellungen finden Sie in den Beiträgen zur Qualifizierung und Klassifizierung von Medizinprodukten und zur Standalone-Software.

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:

Weiterführende Informationen

Der Artikel zu den Anforderungen der MDR an Software gibt eine Übersicht über die relevanten Normen und Gesetze.

Die IEC 82304-1 ist bei jeder „Health Software“ anwendbar.

Der Artikel zur FDA listet relevante Guidance-Dokumente.

Beachten Sie auch die Vorgaben der FTC und deren „interactive Tool“, das hilft, alle regulatorischen Anforderungen zu identifizieren.

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.

IEC60601-1 und Mobile Medical-Apps

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.

4. Unterstützung für Hersteller von Medical Apps

a) Unterstützung durch kostenfreie Angebote

Einen schnellen Überblick über die regulatorischen Anforderungen verschafft Ihnen das Starter-Kit.

Falls Sie noch Fragen zu Mobile Medical Apps haben, erhalten Sie  Sie im Micro-Consulting kostenlose Antworten.

b) Unterstützung beim Lernen

Einen einfachen Einstieg ermöglichen Ihnen die Seminare. Für Hersteller von Medical Apps sind besonders empfehlenswert das

Der Auditgarant ist eine E-Learning-Plattform, die in Videos Schritt-für-Schritt alle notwendigen Arbeiten und Dokumente erklärt und fertige Templates für eine komplette Produktakte und ein vollständiges QM-System enthält.

c) Weitere Unterstützung

Unsere qualifizierten Expertinnen und Experten helfen Ihnen bei allen Tätigkeiten:

Wenn Sie keine Zeit oder kein Geld haben, um ein eigenes QM-System aufzubauen, können Sie das Johner Institut auch als Legal-Hersteller beauftragen.

Nehmen Sie gleich Kontakt auf, damit wir gemeinsam die nächsten Schritte bestimmen können, um Ihre App möglichst schnell gesetzeskonform zu entwickeln und in den Markt zu bringen.


IEC 81001-5-1: Die Norm für sichere Health-Software

Die Cybersecurity-Norm IEC 81001-5-1 befasst sich damit, wie IT-Sicherheit im Software-Lebenszyklus berücksichtigt werden muss.  Als spezielle Norm für Gesundheitssoftware ergänzt sie unter anderem die IEC 82304-1 bzw. die IEC 62304 und kann Lücken schließen, die dringend geschlossen werden müssen. Die EU plant die Harmonisierung der IEC 81001-5-1 derzeit mit Zieldatum 24. Mai 2024. In diesem Beitrag…

Weiterlesen

Wie Sie die Anforderungen an die Datensicherheit und den Datenschutz für DiGA erfüllen

Die Anforderungen an die Datensicherheit und den Datenschutz von DiGA (Digitalen Gesundheitsanwendungen) gehen weit über den Fragenkatalog der DiGAV hinaus. Unzählige weitere Vorschriften machen es den Herstellern (nicht nur) digitaler Gesundheitsanwendungen immer schwerer, den Überblick im regulatorischen Dschungel zu bewahren. Dabei sollten Hersteller möglichst keine Anforderungen übersehen. Andernfalls drohen Probleme bei der Zulassung ihrer Produkte.…

Weiterlesen
MDR Regel 11 : Der Alptraum der Software-Hersteller?

MDR Regel 11: Der Klassifizierungs-Albtraum?

Die MDR enthält speziell für Software eine Klassifizierungsregel: Regel 11. Diese Regel 11 hat Sprengkraft! Sie hat das Potenzial, die Innovationskraft in Europa weiter zu schwächen. Hersteller sollten die Interpretation der MDCG kennen, um Fehlklassifizierungen von Software zu vermeiden und um der Argumentation benannter Stellen und Behörden folgen zu können. Diese Interpretation lernen Sie in…

Weiterlesen

Software als Medizinprodukt – Software as Medical Device

Unter Software als Medizinprodukt (Software as Medical Device, SaMD) versteht man (eigenständige) Standalone-Software, die ein Medizinprodukt ist, aber nicht Teil eines solchen. Sie ist nicht zu verwechseln mit Medical Device Software im Sinne der EU. Wann müssen Sie als Hersteller Software als Medizinprodukt und wann als Medical Device Software qualifizieren? Das erfahren Sie hier – und können…

Weiterlesen

FHIR: In drei Schritten zum eigenen Profil

FHIR ist inzwischen der Standard für den Datenaustausch im Gesundheitswesen. Moderne klinische Informationssysteme, viele Medizinprodukte und selbst Health-Apps kommen an FHIR nicht vorbei. FHIR steht für „Fast Healthcare Interoperability Resources“ und wird wie das englische „fire“ ausgesprochen. Dieser von HL7 ins Leben gerufene Standard soll alle „Use Cases“ abdecken: vom Abfragen von Versicherungsstammdaten über den…

Weiterlesen