Digitale Gesundheit trifft auf Bürokratie: Was die Pharmaindustrie von Software als Medizinprodukt lernen kann

Pharma eilt, digitale Komponenten zu Arzneimitteln hinzuzufügen — Begleit‑Apps, Datenplattformen, KI‑gestützte Entscheidungsunterstützung — doch Software folgt nicht derselben regulatorischen Logik wie Tabletten und Injektionslösungen. In vielen Projekten überschreitet der Softwareanteil die Grenze zum regulierten Medizinprodukt (Software as a Medical Device, oder SaMD). Teams, die Software als Nebeneffekt behandeln, stellen spät fest, dass sie eigene Klassifizierungs-, Qualitäts‑ und Nachmarktpflichten mit sich bringt. Dieser Artikel überträgt das SaMD‑Playbook für Pharma‑Entscheider, damit Sie von Tag eins Evidenz, Zeitpläne und Risiken planen können.

Market Snapshot 2025: Warum das jetzt wichtig ist

Die öffentliche Liste der FDA umfasst inzwischen über 1.000 AI/ML‑gestützte Medizinprodukte, die in den USA zugelassen, genehmigt oder freigegeben wurden — ein starker Anstieg, der zeigt, wie schnell softwaregetriebene Produkte in Versorgungswege Einzug halten.

Digitale Gesundheitswerkzeuge vermehren sich weiter; Hunderttausende von Apps sind im Umlauf; zunehmend nutzt die Biopharma‑Branche sie zur Erhebung von Real‑World‑Daten und zur Unterstützung von Adhärenz, Sicherheitsüberwachung und Outcomes.

1) Was ist SaMD — und warum Pharma sich dafür interessieren sollte

SaMD ist Software, die für einen medizinischen Zweck bestimmt ist, ohne Teil eines Hardware‑Geräts zu sein. Beispiele sind KI‑Algorithmen zur Diagnose, patientenorientierte Apps, die die Therapie leiten, und Entscheidungsunterstützungs‑Tools für Kliniker. Pharma berührt SaMD, wenn:

• Begleit‑Apps mit Therapien gekoppelt werden.
• Real‑World‑Datenplattformen regulatorische oder HTA‑Einreichungen unterstützen.
• Algorithmen in Kombinationen aus Arzneimittel und Gerät eingebettet sind (z. B. vernetzte Inhalatoren oder Injektoren).

Wenn Sie in SaMD eingreifen, übernehmen Sie Geräte‑Regeln — Klassifizierung, Software‑Lifecycle‑Dokumentation, Usability‑Engineering, Risikomanagement und Nachmarktüberwachung.

2) SaMD ist nicht „nur Software“ — es ist ein reguliertes Produkt

Kernanforderungen umfassen:

• Qualität & Lebenszyklus: ISO 13485 für das QMS und IEC 62304 für den Software‑Lifecycle.
• Benutzerfreundlichkeit: IEC 62366‑Nachweise aus der Human‑Factors‑Forschung, wenn Patienten oder HCPs mit der Benutzeroberfläche interagieren.
• Risiko: ISO 14971 Risikomanagement bezogen auf den vorgesehenen Gebrauch und möglichen Schaden.
• Marktspezifika: Die risikobasierten Zulassungswege der FDA (510(k), De Novo, PMA) und die EU‑MDR‑Klassifizierung (insbesondere Regel 11 für Software). Planen Sie diese von Anfang an — sie später nachzurüsten verursacht Verzögerungen und Nacharbeit.

3) Globaler regulatorischer Überblick in Kürze

Vereinigte Staaten (FDA): Risikobasierte Premarket‑Wege. Für AI/ML‑fähiges SaMD hat die FDA Leitlinien zu Predetermined Change Control Plans (PCCPs) finalisiert, die es Sponsoren erlauben, vorab zu vereinbaren, wie Modelle nach Freigabe/Anerkennung aktualisiert werden dürfen. Die Behörde hat außerdem Good Machine Learning Practice (GMLP) und Transparenzprinzipien veröffentlicht, um Bias, Leistung und die Kommunikation an Nutzer zu steuern.

Europäische Union (MDR): Regel 11 stuft viele klinische Entscheidungs‑Softwarelösungen in Klasse IIa/IIb/III ein und löst damit die Begutachtung durch eine Notified Body sowie robuste klinische Evidenz aus. Aktualisierte MDCG‑Leitlinien klären Qualifikation und Klassifizierung von Software nach MDR/IVDR.

EU‑KI‑Verordnung: KI, die in Medizinprodukten eingesetzt wird, wird allgemein als „high‑risk“ eingestuft und legt AI‑spezifische Anforderungen (Daten‑Governance, Transparenz, Risikomanagement, menschliche Aufsicht) zusätzlich zur MDR/IVDR auf, gestaffelt nach Inkrafttreten.

Pharma‑spezifisch (PDURS): Der Entwurf der FDA‑Leitlinie zu Prescription Drug Use‑Related Software (PDURS) erläutert, wie von einem Arzneimittel‑Sponsor verbreitete Software‑Outputs als Arzneimittelkennzeichnung reguliert werden können — relevant, wenn Ihre Software an ein Arzneimittel gebunden ist und nicht als Gerät reguliert wird.

4) Fallbeispiele: Pharma‑Digitale Kombinationen in der Praxis

Vernetzte Atemwegslösungen: Propeller Healths Sensoren und Apps wurden mit großen Inhalator‑Marken gekoppelt, um Adhärenz und Symptomerfassung zu unterstützen.

Diabetes‑Ökosysteme: Die Übernahme von mySugr durch Roche brachte app‑zentriertes Diabetes‑Management in ein großes Pharma‑/Geräte‑Portfolio und verband Software, Messgeräte und Dienstleistungen.

Digitale Tabletten‑Lehren: ABILIFY MYCITE (Otsuka + Proteus) zeigte, wie Kombinationen aus Arzneimittel, Gerät und Software eine Zulassung erreichen können, dennoch aber Einführungs‑, Datenschutz‑ und Werteherausforderungen gegenüberstehen.

Verschreibungspflichtige digitale Therapeutika: Partnerschaften rund um Software‑Behandlungen (z. B. reSET/reSET‑O) illustrierten sowohl regulatorische Umsetzbarkeit als auch kommerzielle Gegenwinde.

5) Fünf praktische Lehren, die Pharma aus der SaMD‑Entwicklung übernehmen sollte

1. Früh klassifizieren. Wenden Sie FDA‑Kriterien und MDR‑Regel 11 bereits in der Konzeptphase an; dokumentieren Sie den vorgesehenen Gebrauch und die klinischen Entscheidungen, die Ihre Software beeinflusst.

2. Bauen Sie das QMS‑Rückgrat auf. Etablieren Sie Design‑Controls, Risikodateien und Software‑Lifecycle‑Prozesse, bevor Sie über einen Prototyp hinaus entwickeln.

3. Behandeln Sie Usability als Sicherheit. Planen Sie formative und summative Tests; verknüpfen Sie UI‑Entscheidungen mit Risikokontrollen und Restrisiken in Ihrer ISO 14971‑Dokumentation.

4. Validieren Sie Ihre Datenpipeline. Dokumentieren Sie Datenquellen, Qualität, Repräsentativität und Datenschutzmaßnahmen; dies untermauert sowohl AI‑Sicherheit als auch Vertrauen.

5. Entwerfen Sie für Updates. Bei AI/ML antizipieren Sie Modell‑Updates mit klaren Änderungsprotokollen (z. B. PCCP in den USA) und einem Nachmarkt‑Überwachungsplan.

6) KI/ML: Die Ausfallmodi, für die geplant werden muss

Algorithmus‑Drift: Die Leistung in der Praxis kann nachlassen, wenn sich Populationen, Behandlungsgewohnheiten oder Sensoren ändern. Überwachen und im Rahmen eines kontrollierten Plans neu trainieren.

Bias & Repräsentativität: Nicht‑repräsentative Trainingsdaten können Teilpopulationen schaden. Setzen Sie Bias‑Metriken, spezifizieren Sie Gegenmaßnahmen vorab und seien Sie transparent über Grenzen.

Erklärbarkeit & Transparenz: Stellen Sie den Nutzern klare Informationen über den beabsichtigten Einsatz, Eingaben, Ausgaben und bekannte Ausfallmodi zur Verfügung; richten Sie sich an veröffentlichte Transparenzprinzipien.

Mensch‑KI‑Teamarbeit: Definieren Sie, was der Mensch entscheidet vs. was die Software vorschlägt; gestalten Sie Schnittstellen so, dass sie die kognitive Belastung reduzieren und nicht erhöhen.

7) Nach dem Start: Lebenszyklus, Cybersicherheit und Überwachung

• EU MDR Nachmarkt: Pflegen Sie einen PMS‑Plan; für Klasse IIa/IIb/III bereiten Sie Periodic Safety Update Reports (PSURs) vor, die Sicherheits‑ und Leistungsdaten zusammenführen.

• US‑Erwartungen: Überwachen Sie die Leistung in der Praxis; bei cyber‑fähigen Geräten adressieren Sie sicheres Design, Vulnerability‑Management, koordinierte Offenlegung und stellen Sie eine Software Bill of Materials (SBOM) entsprechend den aktuellen FDA‑Erwartungen bereit.

• Update‑Management: Verknüpfen Sie Software‑Patches und Modell‑Updates mit Risikobewertung, Verifikation/Validierung und Nutzerkommunikation. Dokumentieren Sie alles.

8) Ethik, Datenschutz und Patientenvertrauen

Seien Sie explizit hinsichtlich der Daten, die Sie erheben, warum und wie sie geschützt werden. Stellen Sie GDPR/HIPAA‑Konformität sicher, minimieren Sie Daten, wo möglich, und kommunizieren Sie Nutzen und Risiken klar. Vertrauen ist eine Designentscheidung — bauen Sie es in Onboarding, Einwilligungsabläufe und Kennzeichnung ein.

9) Eine Checkliste für Pharmateams, die SaMD betreten

Fazit

Software ist inzwischen Teil der Therapie. Teams, die SaMD von Anfang an als reguliertes Produkt behandeln — mit klarer Klassifizierung, zweckmäßigen Evidenzen und einem Plan für Updates und Überwachung — werden schneller liefern und mit weniger Überraschungen.

Literaturverzeichnis

1. FDA – Liste der AI/ML‑Enabled Medical Devices; PCCP-Leitlinien; GMLP- und Transparenzprinzipien.

2. EU – MDR Regel 11 und MDCG-Leitlinien zur Software; EU AI Act (Pflichten für Hochrisiko-Anwendungen).

3. Fallbeispiele – Otsuka/Proteus ABILIFY MYCITE; Propeller Health‑Partnerschaften; Roche‑Akquisition von mySugr; Marktanalysen zur Adoption digitaler Gesundheit.