Medical Apps sind mitterweile immer häufiger im Einsatz, z.B. in der Krankheitsprävention, Krankheitsdiagnostik, Krankheitsbehandlung oder bei der Überwachung von Vitalparametern.
Es ist aber gar nicht so leicht, eine Medical App auf den Markt zu bringen, die sicher und konform mit Datenschutz- und Medizinproduktrecht innerhalb der MDR (Medical Device Regulation) ist. In diesem Artikel behandeln wir die wichtigsten Herausforderungen, die auf App-Hersteller bei der Entwicklung einer Medical App zukommen.
Besonderheiten bei der Entwicklung von Medical Apps
Grundsätzlich müssen Sie bei der Entwicklung von Medical Apps natürlich erstmal dieselben Dinge beachten wie bei der Entwicklung von Apps in anderen Bereichen: ein intuitives User Interface, eine skalierbare und flexible Softwarearchitektur, etc.
Es gibt aber einige Anforderungen, die speziell bei Medical Apps besonders wichtig sind:
- Qualitätsmanagement im regulatorischen Rahmen
- Datenschutz
- Datensicherheit
- Software-Qualität
- Kommunikation mit medizinischen Geräten & Wearables
- Unterschiedliche Hardware- und Laufzeitumgebungen
In den folgenden Abschnitten werden wir diese Herausforderungen genauer unter die Lupe nehmen.
1. Qualitätsmanagement im regulatorischen Rahmen
Medizinproduktklasse und Zweckbestimmung definieren
Wir nehmen in diesem Artikel an, dass Sie Ihr Produkt erstmal auf dem europäischem Markt in Verkehr bringen möchten und fokussieren uns nicht auf die regulatorischen Bestimmungen anderer Märkte (z.B. der FDA in den USA).
Medizinprodukt-Hersteller in Deutschland und anderen EU-Staaten müssen sich an die Richtlinien der MDR (Medical Device Regulation) halten. Die MDR hat die MDD (Medical Device Directive) am 26.05.2021 abgelöst. In diesem Artikel beschäftigen wir uns daher explizit mit den Anforderungen der MDR.
Wenn Ihre App ein Medizinprodukt im Sinne der MDR ist, müssen Sie ein Qualitätsmanagement-System aufbauen und pflegen. Ob das so ist, und welche Risikoklasse es in diesem Fall hat, sollten Sie vor Beginn der Entwicklung unbedingt mit einem Regulatory-Experten abklären (kontaktieren Sie uns diesbezüglich gerne).
Als sehr grobe Daumenregel sind Apps, die als Zweck die Prävention, Diagnose oder Therapie von Krankheiten haben, meist ein Medizinprodukt. Wir haben zu dem Thema “Ist Ihre App ein Medizinprodukt?” auch einen umfangreichen Leitfaden geschrieben, den Sie hier finden können. Weitere Informationen erhalten Sie auch in unserem Artikel zur Zweckbestimmung.
Welche Medizinproduktklasse die App dann hat, hängt u.a. vom Patienten-Risiko ab. Je höher der mögliche (indirekte) Schaden durch Ihre App ist, desto höher wird die Medizinproduktklasse sein. Die Klassifizierungsregeln sind jedoch komplex, das Hinzuziehen eines Beraters ist unerlässlich. Für eine erste grobe Einschätzung kann der folgende vereinfachte Entscheidungsbaim hilfreich sein (basiert auf Regel 11 der MDR).
- Wenn Ihre App Informationen liefert, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden: Klasse IIa
- kann Ihre App jedoch potentiell den Tod oder eine irreversible Verschlechterung des Gesundheitszustands einer Person herbeiführen: Klasse III
- kann Ihre App potentiell eine schwerwiegende Verschlechterung des Gesundheitszustands einer Person herbeiführen: Klasse IIb
- Jede andere App: Klasse I
Auch für die Risikoklassifizierung einer App haben wir einen umfassenden Praxisleitfaden verfasst, welchen Sie hier finden.
Qualitätsmanagement-System aufbauen: ISO 13485
Wenn Sie eine App als Medizinprodukt auf den Markt bringen möchten, kommen Sie um den Aufbau eines nach ISO 13485 zertifizierten Qualitätsmanagement-Systems kaum herum. Die einzige Ausnahme stellen Apps der Klasse I dar. Hier wird kein zertifiziertes Qualitätsmanagement-System gefordert. Ein Basis-Qualitätsmanagement-System wird aber auch für Produkte der Klasse I gefordert.
Eine komplette Anleitung für den Aufbau eines Qualitätsmanagement-Systems nach ISO 13485 sprengt den Umfang dieses Artikels. Daher gehen wir hier vor allem auf die wichtigsten Normen ein, die Sie bei der Entwicklung einer Medical App beachten müssen.
Einhalten eines dokumentierten Software-Lebenszyklus: IEC 62304
Eine Medical App fällt unter die Definition einer “Medizingeräte-Software”. Daher werden Sie nach der Norm IEC 62304 arbeiten (nicht explizit gefordert, aber der absolute Standard), um das Konformitätsverfahren zu bestehen. Die Norm schreibt fünf Prozesse vor, nach denen die Software (weiter-)entwickelt werden muss:
- Software-Entwicklungsprozess
- Software-Wartungsprozess
- Software-Risikomanagementprozess
- Software-Konfigurationsmanagementprozess
- Problemlösungsprozess von Software
Im Rahmen des Software-Entwicklungsprozesses muss dann eine technische Dokumentation angefertigt werden, z.B. zur Software-Architektur und zu Unit-/Integrations- und System-Tests. Außerdem müssen Sie z.B. Ihre SOUP’s (Software of Unknown Provenance) umfangreich dokumentieren. Das sind zum Beispiel externe Software-Bibliotheken, die Sie verwenden. Davon gibt es bei mobilen Apps erfahrungsgemäß besonders viele.
Man hört von Zeit zu Zeit immer mal wieder Stimmen, die sagen, dass agile Entwicklung im regulatorischen Rahmen nicht möglich ist. Das ist aber so nicht richtig. Mit einem geeigneten Qualitätsmanagement-System und den richtigen Automatisierungstools ist natürlich auch bei der regulierten Entwicklung von medizinischen Apps agile Entwicklung möglich.
Mehr Informationen zur Norm finden Sie in unserem umfrangreichen Artikel zur IEC 62304. Aktuell wird außerdem diskutiert, ob in Zukunft zusätzlich zur IEC 62304 die IEC 82304 herangezogen wird. Die IEC 82304 stellt eine Erweiterung der IEC 62304 dar.
Risiken identifizieren und analysieren: ISO 14971
Sie sollten sehr genau wissen, wo die Risiken Ihrer App verborgen sind. Wenn Ihre App falsche Werte berechnet, abstürzt oder einfach nur falsch verwendet wird, kann potentiell ein Patient zu Schaden kommen.
Die Norm ISO 14971 beschäftigt sich daher mit dem Risikomanagement von Medizinprodukten. Risiken müssen identifiziert und beherrscht (und ggf. durch zusätzliche Vorkehrungen eliminiert) werden.
Grundsätzlich unterscheidet man zwischen Schaden (z.B. eine Schnittwunde), Gefährdung (z.B. ein Messer) und Risiko (die Kombination aus Wahrscheinlichkeit für das Auftreten des Schadens und dem Schweregrad dieses Schadens). Sie müssen nun für jedes Risiko unter Berücksichtigung der Schaden-Wahrscheinlichkeit und des Schaden-Schweregrads entscheiden, ob es akzeptabel oder nicht akzeptabel ist. Ob ein Risiko akzeptabel ist, hängt vom Produktnutzen ab. Sie müssen abwägen, ob das Risiko im Bezug auf den Produktnutzen akzeptabel ist. Wenn ein Produkt also z.B. keinen Nutzen hat, ist kein Risiko akzeptabel.
Zur Risikoanalyse gibt es verschiedene Verfahren, wie die Preliminary Hazard Analysis (PHA), die Fault Tree Analysis (FTA), und die Fehlermöglichkeits- und -einflussanalyse (FMEA).
Gebrauchstauglichkeit sicherstellen: IEC 62366
Ihr User Interface sollte nicht nur schön aussehen, sondern auch Fehler bei der Anwendung ausschließen. Nehmen wir beispielsweise eine App zur Steuerung einer Insulinpumpe: Dem Patienten muss in dieser App unmissverständlich kommuniziert werden, welcher Knopf eine Insulin-Injektion auslöst. Eine Insulin-Überdosis kann im schlimmsten Fall sogar zum Tod führen. Ein versehentliches Auslösen ist daher ein nicht vertretbares Risiko.
Genau damit beschäftigt sich die IEC 62366, die Norm zur Gebrauchstauglichkeit von Medizinprodukten. Viele Todesfolgen bei Medizinprodukten sind nämlich gar nicht unbedingt auf Fehlfunktionen zurückzuführen, sondern auf mangelnde Gebrauchstauglichkeit und daher falsche Anwendung. Gebrauchstauglichkeit bzw. Usability Engineering ist auch Teil des Risikomanagements. Um die Gebrauchstauglichkeit sicherzustellen, muss diese ggf. auch durch klinische Studien belegt werden und eine entsprechende Validierung erfolgen. Mehr dazu erfahren Sie hier: Validierung von Medizinprodukt-Software nach MDR
Benannte Stellen und der Auditing-Prozess
Wenn Ihre App unter die Risikoklasse IIa oder höher fällt, müssen Sie eine benannte Stelle hinzuziehen. Benannte Stellen sind meist privatwirtschaftliche Unternehmen (wie der TÜV), die staatlich ausgewählt wurden, um hoheitliche Aufgaben bei der Zulassung und Überwachung von Medizinprodukten zu übernehmen.
Benannte Stellen prüfen z.B. Ihre technische Dokumentation, sie auditieren und zertifizieren Ihr Qualitätsmanagementsystem. Darüber hinaus führen Sie in regelmäßigen Abständen unangekündigte Kontrollen (sog. Audits) durch, um zu prüfen, ob z.B. das dokumentierte Qualitätsmanagement auch tagtäglich vom Team gelebt wird. Hier erfahren Sie mehr über benannte Stellen und den Prozess bis zur Medizinprodukt-Zulassung: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)
2. Datenschutz
Beachten Sie zuallererst, dass Datenschutz und Datensicherheit zwei unterschiedliche Felder behandeln. Bei Datensicherheit geht es um technische Schutzvorkehrungen, um die Sicherheit von Daten zu gewährleisten (vor Viren, Manipulationen, Hackern etc.). Datenschutz beschreibt, wie personenbezogene Daten weiterverarbeitet werden können, um vor Missbrauch geschützt zu sein.
Mobile Health Apps oder Medical Apps speichern meist sehr sensible Daten, z.B. Ihre persönliche Krankheitsgeschichte. Ihr Nachbar sollte natürlich ohne Ihre explizite Zustimmung nicht wissen, welche Krankheiten sie haben oder hatten – ein Unternehmen schon gar nicht. Daher müssen sich App-Hersteller stark damit auseinander setzen, welche Daten sie speichern wollen. Im Zweifelsfall ist weniger mehr. Außerdem muss die App explizit kommunizieren, welche Daten gespeichert werden, wo Sie gespeichert werden, und was mit diesen Daten geschieht. Unternehmen, die ihr Produkt auf den europäischen Markt bringen, müssen sich daher mit der DSGVO auseinandersetzen. Datenschutz im Rahmen der DSGVO ist natürlich kein Thema, das nur medizinische Apps betrifft. Jede App muss DSGVO-konform sein.
3. Datensicherheit
Um Datensicherheit zu gewährleisten brauchen Sie zuallererst ein sehr versiertes technisches Team. Dieses muss umfangreiches Know-How darüber haben, wo Schwachpunkte einer Software liegen könnten.
Sie schaffen es mit einer Medical App mit unzureichender Datensicherheit evtl. auf den Markt, weil auch ein Auditor dies nur bedingt prüfen kann. Die Konsequenzen von nachträglichen Daten-Leaks sind allerdings drastisch (wie Beispiele von Vivy & Co. zeigen). Leichtfertiges Handeln kann einen massiven Reputationsschaden und weitreichende gesetzliche Schwierigkeiten nach sich ziehen.
Die besondere Herausforderung in diesem Bereich: Datensicherheit erlaubt keine 80 Prozent-Lösung. Während Unternehmen gerne beim Design der Software Kosten sparen, kann das bei Datensicherheit nach hinten los gehen.
Wenn Ihre App auch nur eine einzige, leicht-nutzbare Sicherheitslücke aufweist, werden Hacker das womöglich herausfinden. Ab diesem Zeitpunkt sind alle anderen Sicherheitsmaßnahmen irrelevant und der Hacker erhält Zugriff auf die Daten.
Wenn in einem verriegeltem Haus nur ein einziges Fenster offen steht, kann ein Einbrecher dennoch spielend leicht eindringen.
4. Softwarequalität
Eine skalierbare Software-Architektur, strukturierter Code und automatisierte Tests (Unit-, Integration- und System-Tests) sind wichtige Komponenten, um hohe Softwarequalität sicher zu stellen. Für Entwickler äußert sich schlechte Softwarequalität in immensem Mehraufwand bei der Software-Wartung und Integration von neuen Funktionen. App-Nutzer spüren mangelnde Softwarewarequalität meist durch Fehlfunktionen in der App, Abstürze, Performanz-Probleme oder eine schwer zu bedienende Nutzeroberfläche.
Derartige Mängel sind bei Medical Apps besonders fatal: Während ein Absturz der Facebook-App für Nutzer beispielsweise erstmal “nur” ärgerlich ist, kann der Absturz oder das Fehlverhalten einer Medical App gefährliche, oder sogar lebensbedrohliche Konsequenzen nach sich ziehen. Die Zuverlässigkeit der Software muss daher sichergestellt werden.
Der Einfluss von Software-Qualität wird gerne unterschätzt, auch weil diese als Außenstehender schwer zu evaluieren ist. Das Resultat sieht man oft erst, wenn es schon zu spät ist. Wir empfehlen daher Ihren versiertesten Software-Entwickler/Techniker bei der Auswahl von neuen Bewerbern und externen Dienstleistern zu Rate zu ziehen. Er kann durch gezielte technische Fragen meist schnell ein Gefühl für die Kompetenz des Gegenübers erlangen.
5. Kommunikation mit medizinischen Geräten & Wearables
Medical Apps werden oft für die Steuerung und Überwachung von medizinischen Geräten wie Glucose-Messgeräten verwendet. Die Kommunikation erfolgt dafür meist über Bluetooth, Wifi oder USB. Dabei gilt es u.a. auf folgende Dinge zu achten.
Zuallererst müssen Sie das Kommunikationsprotokoll des Geräts genau verstehen. Ein falscher Befehl kann ein medizinisches Gerät zu falschen Aktionen oder sogar zum Absturz bringen. Sie müssen sehr genau wissen, welche Befehle das Gerät in welcher Form erwartet und wie Ihre App die Daten des Geräts interpretieren sollte.
Das ist aufgrund unzureichender Schnittstellen-Dokumentation oft gar nicht so einfach. Es gibt sehr viele verschiedene Standards und viele Gerät benutzen ein nicht-standardisiertes, proprietäres Kommunikationsprotokoll. Dokumentationslücken sollten Sie daher in direkter Kommunikation mit dem Hersteller des Kommunikationsprotokolls klären. Extensives Testen ist auch hier natürlich unerlässlich. Mehr Informationen, auf was bei der sog. Interoperabilität von medizinischen Geräten bzw. Apps ankommt, können Sie auch in diesem Artikel finden. Wenn Sie die Entwicklung einer digitalen Gesundheitsanwendung (DiGA) planen, finden Sie in diesem Artikel konkrete Unterstützung in der Umsetzung der Interoperabilitätsanforderungen.
Darüber hinaus müssen Sie jederzeit mit Verbindungsabbrüchen rechnen. Eine Bluetooth-Verbindung kann aus vielen Gründen plötzlich abbrechen. Ihre Software muss damit souverän umgehen können und die Verbindung automatisch wiederherstellen.
Zuletzt sollten Sie sicher stellen, dass die Übertragungssicherheit gewährleistet ist, z.B. durch Datenverschlüsselung und Identitätsüüberprüfung von Sender und Empfänger. Ein anderes Gerät kann Ihre übertragenen Daten sonst einfach mitlesen oder sogar manipulieren.
6. Unterschiedliche Hardware- und Laufzeitumgebungen
Sogenannte “Embedded Software” läuft nur auf einem einzigen Gerät. Die integrierte Software eines Glucose-Messgeräts ist hierfür ein gutes Beispiel. Die Rahmenbedingungen sind also statisch und vorab bekannt. Das ist bei Medical Apps aber nicht der Fall. Eine App muss auf einer Vielzahl verschiedener Smartphone funktionieren. Bei jedem Smartphone variieren u.a. folgende Dinge
- Hardware: Bildschirm-Auflösung, Kamera, Sensoren etc.
- Betriebssystem und Betriebssystem-Version
- Andere Apps, welche die Funktionsweise der eigenen App beeinflussen (wie z.B. Batterie-Manager)
Das ist vor allem bei Android ein großes Problem: es gibt eine extrem große Menge an verschiedenen Geräten. Es ist daher unmöglich, die App auf allen Geräten zu testen, auf denen sie potentiell laufen wird.
Wie gehen Sie mit solch heterogenen Umgebungen um? Stark zusammengefasst ist folgendes wichtig:
- Diszipliniertes Testen: Ihre Software-Tester sollten die App auf jeder möglichen Betriebssystem-Version und auf möglichst unterschiedlichen Hardware-Konfigurationen überprüfen (beispielsweise ein kostengünstiges Smartphone mit langsamer CPU und kleinem Bildschirm, und ein Hochklasse-Smartphone mit 4K-Bildschirm und hochmoderner CPU).
- Schulung des Software-Teams: die Entwickler müssen darauf achten, keine Annahmen zu machen, die auf der Hardware oder Betriebssystem-Version des Handys basieren.
- Automatisiertes Testen: Manuelle Tests können oft mehrere Wochen Zeit in Anspruch nehmen, wenn sie auf vielen verschiedenen Geräten durchgeführt werden sollen. Mit automatisierten Tests hingegen können Sie Ihre App innerhalb kurzer Zeit z.B. auf 50 verschiedenen Geräten testen.
- Nutzung von Cloud-Angeboten zum Testen der App: Services wie Amazon Device Farm machen es einfach, die App und die zugehörigen Tests auf 50 verschiedenen Geräten auszuführen. Funktionalität, die auf Sensoren oder z.B. auf Bluetooth basiert, kann wiederum nicht auf diese Weise getestet werden.
Fazit
Eine Medical App zu entwickeln birgt viele Herausforderungen. Mit einem interdisziplinären Team aus versierten Software-Entwicklern, Regulatory-Experten, Testern und Medizinern is dies aber durchaus machbar. Außerdem wird es durch das neue Digitale-Versorgung-Gesetz (DVG) attraktiver eine solche App zu entwickeln: Die Vergütung wird vereinfacht und Preisverhandlungen beschleunigt.
Jede Hürde ist gleichzeitig immer auch ein Vorteil: Wenn Sie die genannten Herausforderungen bezwingen, haben Sie nur noch wenig Konkurrenz. Die meisten Startups schaffen es nämlich leider nicht so weit. Das Ganze sollten Sie daher als Chance sehen, sich einen langfristigen Platz auf dem Health-Markt zu sichern.
Auf diesem Weg unterstützen wir Sie gerne. QuickBird Medical hat bereits eine Vielzahl von Health und Medical Apps umgesetzt. Gemeinsam mit unseren Kunden haben wir diese entwickelt und erfolgreich am Markt platziert. Unsere Apps sind nicht nur sicher und verlässlich, sondern bestehen auch im Audit der benannten Stellen. Für eine kostenlose Erstberatung treten Sie gerne mit uns in Kontakt.
