BfArM-Abstimmung

BfArM-Abstimmung

Vorschlag zur Klärung der regulatorischen Einordnung vor Studienbeginn

Hintergrund und regulatorische Einordnung

Die HyponaTrack-App ist eine iOS-Anwendung, die Patienten nach TSS beim 14-tägigen postoperativen Monitoring unterstützt. Sie erfasst Gewicht, Trinkmenge, Symptome und Vitalparameter und gibt über ein Ampelsystem (Grün/Gelb/Rot) eine Handlungsempfehlung aus.

Kernfrage: Medizinprodukt oder nicht?

Die regulatorische Einordnung hängt von der Zweckbestimmung und Funktion ab:

Kriterium Bewertung HyponaTrack
Zweckbestimmung Unterstützung des Monitorings, keine Diagnose
Entscheidungsunterstützung Ampelsystem mit Schwellenwerten – kritisch zu prüfen
Patientenrelevanz Direkte Handlungsempfehlungen (Rot = Notaufnahme)
MDR-Klasse Potenziell Klasse IIa (SaMD) gemäß MDR 2017/745
Studienkontext Beobachtungsstudie – ggf. vereinfachtes Verfahren
Tabelle 1: Regulatorische Einordnung von HyponaTrack.
Warnung

Das Ampelsystem mit konkreten Handlungsempfehlungen kann dazu führen, dass die App als Medizinprodukt (Software as a Medical Device, SaMD) gemäß EU MDR 2017/745 eingestuft wird. Dies ist die wichtigste Frage für die BfArM-Abstimmung.

Empfohlene Strategie: Dreistufiger Ansatz

Stufe 1 – Voranfrage bei BfArM (sofort)

Ziel: Verbindliche Aussage zur regulatorischen Einordnung vor Studienstart.

Vorgehen:

  1. Schriftliche Voranfrage an BfArM, Referat für Medizinprodukte
  2. Beschreibung der App-Funktionalität (Zweckbestimmung, Algorithmus, Datenfluss)
  3. Klarstellung: Beobachtungsstudie, kein Therapiegerät, kein Diagnostikum

Adresse: Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM), Kurt-Georg-Kiesinger-Allee 3, 53175 Bonn. E-Mail: medizinprodukte@bfarm.de.

Stufe 2 – Inhalt der Voranfrage

Betreff: Anfrage zur regulatorischen Einordnung einer Studien-App (SaMD) – HyponaTrack

Empfohlener Inhalt:

  1. Kurzbeschreibung: HyponaTrack ist eine iOS-App zur Unterstützung des postoperativen Monitorings von Patienten nach TSS. Die App erfasst Gewicht, Trinkmenge und Symptome und gibt eine farbcodierte Risikoeinschätzung (Grün/Gelb/Rot) aus. Die App ist Teil einer klinischen Beobachtungsstudie am UKE Hamburg.
  2. Technische Beschreibung: Plattform iOS 18+, SwiftUI, lokale Datenspeicherung (SwiftData). Algorithmus: Regelbasiertes Schwellenwert-System (keine KI/ML). Datenübertragung: Pseudonymisiert an REDCap (Studien-EDC). Kein Custom-Backend, kein Cloud-Service. Disclaimer in der App: “Diese App ersetzt keine ärztliche Diagnostik”.
  3. Zweckbestimmung (Vorschlag): “HyponaTrack dient ausschließlich der Erfassung und Visualisierung von Selbstmesswerten im Rahmen einer klinischen Beobachtungsstudie. Die App gibt keine Diagnosen, ersetzt keine ärztliche Beurteilung und stellt kein Medizinprodukt dar.”
  4. Abgrenzungsfragen an BfArM: (a) Stellt das Ampelsystem eine medizinproduktrelevante Funktion dar? (b) Welche Anforderungen gelten für eine Studien-App in einer nicht-interventionellen Beobachtungsstudie? (c) Ist eine CE-Kennzeichnung vor Studienbeginn erforderlich? (d) Welche Meldepflichten bestehen für schwerwiegende Vorkommnisse?

Stufe 3 – Je nach Rückmeldung BfArM

Szenario A: App = kein Medizinprodukt

  • Nur Ethikvotum erforderlich
  • Studienprotokoll bei zuständiger Ethikkommission einreichen
  • DSGVO-Compliance sicherstellen (DSFA bereits vorhanden)

Szenario B: App = Medizinprodukt (SaMD)

Anforderung Maßnahme
CE-Kennzeichnung Konformitätsbewertungsverfahren einleiten (Benannte Stelle)
QMS ISO 13485 – Medical Device Quality Management System
Technische Dokumentation IEC 62304 (SW-Lebenszyklus), IEC 62366 (Usability)
Risikoanalyse ISO 14971
Klinische Bewertung MDR Anhang XIV
UDI Unique Device Identification bei EUDAMED registrieren
Tabelle 2: Anforderungen bei SaMD-Klassifizierung.
Tipp

Empfehlung bei Szenario B: Zweckbestimmung der App anpassen (keine Handlungsempfehlungen, nur Datenvisualisierung), um Medizinprodukt-Status zu vermeiden.

Zeitplan für die BfArM-Abstimmung

Schritt Aktion Frist
T+0 Voranfrage ausformulieren und absenden Woche 1
T+4 Wo Antwort BfArM erwartet Woche 5
T+5 Wo Strategie anpassen (je nach Szenario A/B) Woche 6
T+6 Wo Ethikantrag einreichen Woche 7
T+10 Wo Ethikvotum erwartet Woche 11
Tabelle 3: Zeitplan BfArM-Abstimmung und Ethikantrag.

Parallelweg: Ethikkommission

Unabhängig von der BfArM-Einordnung ist ein Ethikvotum der zuständigen Ethikkommission (Hamburg) erforderlich.

Zuständig: Ethikkommission der Ärztekammer Hamburg (ethikkommission@aekhh.de).

Erforderliche Unterlagen:

  • Studienprotokoll / Synopsis
  • Einwilligungserklärung (ICF) – deutsch + englisch
  • DSFA gemäß DSGVO Art. 35
  • Verarbeitungsverzeichnis gemäß DSGVO Art. 30
  • Prüfarztqualifikation (CV Studienleiter)
  • Versicherungsnachweis (Probandenversicherung)
  • App-Beschreibung mit Screenshots
  • Technisches Sicherheitskonzept
  • Auftragsverarbeitungsvertrag (AVV) mit REDCap-Hoster
  • BfArM-Voranfrage-Antwort (ausstehend)

Regulatorische Grenze – Wann wird die App zum Medizinprodukt?

Aktuelle Einordnung: Kein Medizinprodukt

Die App berechnet einen Risiko-Score und zeigt eine Ampelfarbe. Der Patient entscheidet selbst, ob er die Klinik kontaktiert. Es gibt keine automatische Arzt-Benachrichtigung.

Grenzüberschreitungen (würden SaMD-Klassifizierung auslösen)

Feature Auswirkung
Automatische Push-Notification an Arzt bei ROT SaMD Klasse IIa
Diagnosevorschlag (“Verdacht auf SIADH”) SaMD Klasse IIa
Therapieempfehlung (“Desmopressin absetzen”) SaMD Klasse IIa/IIb
Automatische Medikamenten-Anpassung SaMD Klasse III
Tabelle 4: Features, die eine SaMD-Klassifizierung auslösen würden.
Wichtig

Die Eskalation muss beim Patienten bleiben: “Bitte kontaktieren Sie Ihre Klinik” – nicht “Wir haben Ihren Arzt benachrichtigt”. So bleibt die App ein Dokumentationswerkzeug und kein Medizinprodukt.

Für Phase 2 (mit automatischer Arzt-Benachrichtigung) wäre ein CE-Konformitätsbewertungsverfahren nach MDR 2017/745 erforderlich. Geschätzter Aufwand: 6–12 Monate, Kosten ca. 50.000–100.000 EUR für die Benannte Stelle.

Weiterführende Ressourcen

  • MDCG 2019-11: Guidance on Qualification and Classification of Software in MDR
  • BfArM-Leitfaden: “Orientierungshilfe Medical Apps” (2020)
  • DiGAV: Digitale Gesundheitsanwendungen (für Kontext, auch wenn nicht direkt anwendbar)
  • IMDRF/SaMD N41: Software as a Medical Device – Clinical Evaluation