Einleitung
Methodik
Ergebnisse
DiGA-Bewertungsinstrumente
HTA Module for Mobile Medical Applications [9], AHTA (Adelaide Health Technology Assessment University of Adelaide), Australia | Evidence Standards Framework for Digital Health Technologies [10], NICE (National Institute for Health and Care Excellence), United Kingdom | Digital Health Care Services/Digi-HTA [11], Faculty of Medicine, University of Oulu, Finland | Design & Evaluation Framework for Digital Interventions/DEDHI [12], Center for Digital Health Interventions, University of St. Gallen & ETH Zürich, Switzerland | Digital Health Scorecard [13], Armstrong Institute for Patient Safety and Quality & Johns Hopkins Medicine, Baltimore, MD, USA | mHealth Agile Development & Lifecycle [14], Faculty of Medicine, University of Ottawa, Canada | |
---|---|---|---|---|---|---|
Finanzierung | Australian Government Research Training Program Scholarship and University of Adelaide, School of Public Health | National Health Service England | Regional Council of Northern Ostrobothnia (funding from the European Regional Development Fund), Funding by the Northern Ostrobothnia Hospital District | Health Promotion Switzerland, and the European Social Fund and the Free State of Saxony (Grant no. 100310385) | Das Framework entstand ohne Finanzierung aus dem öffentlichen, kommerziellen oder gemeinnützigen Sektor | Public Health Agency of Canada, Sanofi-Pasteur, the Canadian Institutes of Health Research, the Ottawa Hospital and Health Canada |
Jahr | April 2020 | März 2019 | November 2019 | November 2019 | Mai 2019 | September 2018 |
Zielgruppe | HTA Expert*innen, Entscheidungsträger*Innen | Technologieentwickler*Innen, Entscheidungsträger*Innen | HTA Expert*innen, Entscheidungsträger*Innen | Wissenschafter*Innen, Evaluator*Innen | Unabhängige Evaluator*Innen | Technologieentwickler*Innen, Entscheidungsträger*Innen |
Status Framework | In Entwicklung | Etabliert, in Erprobung | In Entwicklung/in Erprobung | In Erprobung | In Entwicklung | In Erprobung |
Anwendungsbereich/Titel | Mobile Medical Application (MMA) | Digital Health Technologies (DHT) | mHealth, Künstliche Intelligenz, Robotik | Digital Health Interventions (DHI) | Digital Health Products | mHealth/Digital Health Products |
Risikoklassen | Keine Erwähnung von Risikoklassen | Risikoklassifikation (1, 2, 3a/3b) entsprechend der Funktionalität der DHT | Keine definierten Risikoklassen, aber deskriptive Fragen nach klinischer Konsequenz | Keine Erwähnung von Risikoklassen | Keine definierten Risikoklassen, aber Differenzierung nach Funktionalitäten und deren klinischen Konsequenz | Keine definierten Risikoklassen, aber Differenzierung zwischen Niedrigrisiko- (keinerlei Risiken für Anwender*Innen) und Hochrisikoanwendungen |
Evidenzerfordernisse | Keine Erwähnung von Studiendesigns, nur von Vergleichsinterventionen, Analyse von Schaden durch Fehlinformation, ethische Aspekte | Evidenzerfordernisse entsprechend der Risikoklasse (RK), je RK Minimalerfordernisse vs. Best Practice, z. B. 3a: Beobachtungsstudie vs. Interventionsstudie 3b: Interventionsstudien/RCT Komparatoren, relevante Endpunkte | Empfohlene Studiendesigns: Fallstudien, RCTs, systematische Reviews | Orientierung am MOST Framework zu Evidenzerfordernissen in Produktentwicklungsphasen Phase 1: Studien zu Durchführbarkeit Phase 2: Studien zu Optimierung Phase 3: RCTs Phase 4: kontinuierliche Erhebungen zu Reichweite, Impakt und Nebenwirkungen | Keine Erwähnung von Studiendesigns, nur kritische Bewertung der Evidenz bezüglich Impakt auf definierte klinische Endpunkte. Vergleiche zu Goldstandard | Orientierung am IDEAS Framework zu Evidenzerfordernissen in Produktentwicklungsstadien Phase 2: Kohortenstudien, Fallserien Phase 3: RCTs (sofern mHealth-Produkte als Medizinprodukte definiert sind), A/B testing (Testung von App-Versionen) |
Zeitpunkt der Anwendung des Frameworks/Intention | Vor Refundierung | Vor Refundierung, zur Evidenzgenerierung | Vor Refundierung , zur Evidenzgenerierung, Post-market-Surveillance | Zur Evidenzgenerierung, Post-market-Surveillance | Zur Evidenzgenerierung, Post-market-Surveillance | Zur Evidenzgenerierung, Post-market-Surveillance |
Format des Frameworks | Herkömmliche HTA-Checkliste | Fragen zum Kontext zur Einordnung der DHT in eine Risikoklasse, tabellarische Evidenzerfordernisse (kumulativ, aufsteigend) | Fragebogen HTA-Checkliste | Checkliste zu F&E sowie Implementierung von DHIs | Scorecard (Scores sind nicht definiert) | Fragebogen zu F&E von mHealth-Apps im Lebenszyklus nach IDEAS |
Bewertungsdomänen | Technische Aspekte, Effektivität (Nutzen), Sicherheit, Kosten, Kosteneffektivität, organisatorische, legistische, ethische und soziale Aspekte | 1: Plausibilität, Relevanz, Akzeptanz, gleicher Zugang, Genauigkeit 2: Verlässlichkeit, Wert für Zielpopulation, Qualität und Datensicherheit 3a/3b: klinische Effektivität anhand relevanter Endpunkte 1–3: ökonomischer Impakt | Technische Aspekte, Effektivität (Nutzen), Sicherheit, ökonomische Aspekte, Anwenderaspekte und Zugang, organisatorische Aspekte, Interoperabilität | Benutzerfreundlichkeit, inhaltliche Qualität, Privatsphäre und Datenschutz, Verantwortlichkeit, Adhärenz, Ästhetik, empfundener Nutzen, Effektivität (Nutzen), Qualität des Service, Personalisierung, empfundenes Engagement, ethische Aspekte, Sicherheit | 4 Domänen: technische Aspekte, klinische Effektivität (Nutzen), Benutzerfreundlichkeit, Kosten | Phase 1 der Entwicklung: technische Aspekte, Performanz und Datensicherheit Phase 2: Anwenderaspekte, Akzeptanz Phase 3: Nutzen |
Technologiespezifische Aspekte: Datenschutz Datensicherheit Umgang mit Updates Künstliche Intelligenz (KI) | Datenschutz: ja Datensicherheit: ja Umgang mit Updates: ja Künstliche Intelligenz: k. A. | Datenschutz: k. A Datensicherheit: k. A Umgang mit Updates: k. A Künstliche Intelligenz: nur fixe Algorithmen, NICHT adaptive Algorithmen | Datenschutz: ja Datensicherheit: ja Umgang mit Updates: ja Künstliche Intelligenz: ja | Datenschutz: ja Datensicherheit: ja Umgang mit Updates: ja Künstliche Intelligenz: nein | Datenschutz: ja Datensicherheit: ja Umgang mit Updates: nein Künstliche Intelligenz: nein | Datenschutz: ja Datensicherheit: ja Umgang mit Updates: ja Künstliche Intelligenz: nein |
Involvierung Patient*Innenvertretung | k. A. | k. A. | k. A. | Nein | Nein | k. A. |
Framework-Spezifika Resümee | Systematischer Review zu derzeit verwendeten Evaluations-Frameworks. Derzeit kein eigenständiges Framework, nur Zusammenschau. Traditionelle HTA-Perspektive | Stellt die geforderte Evidenz in Relation zum möglichen Risiko der DHT. Auflistung geforderter Studiendesigns je nach Risikoklasse Einziges hoch entwickeltes Framework zur sofortigen Anwendung | Framework basiert auf systematischem Review, Interviews und Workshop. Vereint mHealth, KI und Robotik in einem Framework Ethische, soziale und rechtliche Aspekte sind explizit kein Bestandteil dieses Frameworks | Framework behandelt unterschiedliche Entwicklungsphasen einer Digital-Health-Intervention, die Implementierungsphase wird detailliert berücksichtigt | Die Digital Health Scorecard soll jeweils einmal vor als auch nach Marktzulassung angewendet werden | Das Framework vereint einen „agilen“ Entwicklungsprozess aus Perspektive von Technologienentwickler*Innen mit Methoden zur Nutzenbewertung |
Risikoklassen nach EU-Verordnung 2017/745 über Medizinprodukte (Regel 11) [2] | Evidenzstufen nach NICE Evidence Standards Framework [10] |
---|---|
Risikoklasse 1 | Stufe 1 |
Jede Software, die nicht in Risikoklasse 2a oder höher eingeteilt wird | Digitale Gesundheitsanwendungen ohne individuell messbare Effekte auf die Gesundheit von Anwender*innen. Organisatorische Anwendungen auf Systemebene Beispiele: elektronische Gesundheitsakte, Krankenhaus-Informations-Systeme |
Risikoklasse 2a | Stufe 2 |
Software, welche Information zur Entscheidung einer Diagnose oder therapeutischen Zwecken zur Verfügung stellt, ohne jedoch dabei ernstere Gesundheitsschäden verursachen zu können (s. nachfolgende Risikoklassen) Software, die physiologische Messwerte aufzeichnet, solange es sich dabei nicht um Vitalparameter handelt | Digitale Gesundheitsanwendungen, welche Gesundheitsinformationen anbieten, einfache Monitoringfunktionen übernehmen, oder Anwendungen zur Kommunikation Beispiele: Anwendungen mit Empfehlungen für einen gesunden Lebensstil, digitaler Kopfschmerzkalender, Anwendungen für Videosprechstunden mit Therapeut*innen |
Risikoklasse 2b | Stufe 3a |
Software, welche Information zur Entscheidung einer Diagnose oder therapeutischen Zwecken zur Verfügung stellt, bei der ernstere Gesundheitsschäden oder die Notwendigkeit einer chirurgischen Intervention entstehen können Software, die Vitalparameter aufzeichnet (Messwerte, bei denen eine Änderung eine unmittelbare Gefahr für die Patient*innen darstellen kann) | Digitale Gesundheitsanwendungen, die der Prävention und dem Selbstmanagement von Krankheiten dienen. Digitale Gesundheitsanwendungen mit individuell messbaren Effekten auf die Gesundheit von Anwender*innen. Sie können parallel zu konventioneller Therapie eingesetzt werden Beispiele: Anwendungen zur Raucherentwöhnung oder Gewichtsreduktion |
Risikoklasse 3 | Stufe 3b |
Software, welche Information zur Entscheidung einer Diagnose oder therapeutischen Zwecken zur Verfügung stellt, bei der diese Entscheidung ein Todesereignis oder irreversible Schäden der Gesundheit verursachen kann | Digitale Gesundheitsanwendungen, die der Diagnostik und Therapie von Krankheiten dienen. Digitale Gesundheitsanwendungen mit klinischen Konsequenzen (durch aktives Monitoring oder Berechnungen). Digitale Gesundheitsanwendungen mit individuell messbaren Effekten auf die Gesundheit von Anwender*innen Beispiele: Anwendungen, die anhand eingegebener Symptome Diagnosevorschläge machen, Anwendungen, die kognitive Verhaltenstherapie für Angststörungen anbieten, Anwendungen, die mit einem externen Sensor oder Implantat verknüpft sind und dessen Daten automatisch und kontinuierlich für Fernmonitoring gesendet werden |