Der Markt für Selbstzahler ist im deutschen Gesundheitswesen überschaubar, und der Weg in die Erstattung durch Krankenkassen herausfordernd.

Zwar existieren etablierte Erstattungswege wie die Aufnahme ins DiGA-Verzeichnis oder eine individuelle Vergütung über Selektivverträge, doch diese Zugangswege können langwierig, komplex und kostenintensiv sein.

Daher lohnt es sich, auch alternative Pfade zur Finanzierung zu betrachten, während man auf den Sprung in die Regelversorgung hinarbeitet. Eine solche Alternative für die Finanzierung und Erstattung digitaler Gesundheitslösungen ist der Innovationsfonds nach § 92a SGB V.

In diesem Fachartikel erklären wir …

• welche Möglichkeiten der Innovationsfonds bietet,
• welche Voraussetzungen für eine Förderung erfüllt sein müssen,
• wie hoch die Erfolgschancen bei Software-Produkten sind,
• und für welche Arten von digitalen Konzepten eine Antragstellung möglich ist.

Update – Dezember 2025: Im Dezember 2025 zog die „BASYS“ eine Bilanz über zehn Jahre „Neue Versorgungsformen“ im Innovationsfonds. Die wichtigsten Ergebnisse fassen wir in Kapitel 6 zusammen.

Inhaltsverzeichnis

• 1. Definition des Innovationsfonds
  • 1.1 Was ist der Innovationsfonds?
  • 1.2 Wie hoch ist das verfügbare Fördervolumen?
  • 1.3 Wer verwaltet den Innovationsfonds?
  • 1.4 Wer ist beteiligt?
  • 1.5 Förderkategorien im Überblick
• 2. Unterschied zwischen Förderung & Erstattung
• 3. Voraussetzungen für die Förderung durch den Innovationsfonds
  • 3.1 Welche Projekte werden gefördert?
  • 3.2 Welche Projekte werden nicht gefördert?
• 4. Das Antragsverfahren des Innovationsfonds
  • 4.1 Welche Antragsverfahren gibt es?
  • 4.2 Welches Antragsverfahren passt zu meinem Projekt?
  • 4.3 Was sind die Anforderungen für einen Antrag?
  • 4.4 Was sind die Kriterien zur Förderung?
  • 4.5 Beispiel für ein Innovationsfonds-gefördertes Projekt: INTEGRATE-ATMP
  • 4.6 Was passiert nach Projektende?
• 5. Für welche Software-Produkte kommt eine Innovationsfonds-Förderung infrage
  • 5.1 Komplexe Versorgungslösungen
  • 5.2 Produkte mit hohem Evidenzbedarf
  • 5.3 Nischenindikationen und seltene Krankheiten
  • 5.4 Präventions- und Versorgungsmanagement-Tools
• 6. Zwischenbilanz nach 10 Jahren Innovationsfonds: Was kommt wirklich in der Versorgung an?
• 7. Fazit: Lohnt sich der Innovationsfonds für Hersteller medizinischer Software?
• 8. Wo finde ich weitere Informationen zum Innovationsfonds?

1. Definition des Innovationsfonds

1.1 Was ist der Innovationsfonds des G-BA?

Der Innovationsfonds wurde Anfang 2016 durch das GKV-Versorgungsstärkungsgesetz ins Leben gerufen und ist beim Gemeinsamen Bundesausschuss (G-BA) angesiedelt.

Er dient dem Ziel, neue Versorgungsformen und Versorgungsforschung zu fördern, die über die bisherige Regelversorgung hinausgehen. Konkret sollen innovative Ansätze im Gesundheitswesen wissenschaftlich erprobt werden, um die Versorgung effizienter, patientenzentrierter und qualitativ besser zu gestalten. Der Fonds hat sich seither als zentrales Instrument etabliert, um (digitale) Innovationen im Gesundheitswesen unter realen Bedingungen zu testen.

1.2 Wie hoch ist das verfügbare Fördervolumen?

Seit dem Start stehen jährlich rund 200 Millionen Euro an Fördermitteln zur Verfügung. Ursprünglich war der Fonds befristet (bis 2019, später verlängert bis 2024), wurde jedoch nach positiver Evaluation entfristet und ab 2025 verstetigt.

Der Großteil des Budgets (160 Mio. €) fließt in Projekte zu neuen Versorgungsformen, während 40 Mio. € für Versorgungsforschung reserviert sind.

1.3 Wer verwaltet den Innovationsfonds?

Zuständig ist der Innovationsausschuss beim Gemeinsamen Bundesausschuss (G-BA), der in regelmäßigen Förderbekanntmachungen, thematische Schwerpunkte und Kriterien festlegt und über die Anträge entscheidet.

Projekte können typischerweise eine Laufzeit von bis zu drei (manchmal auch vier) Jahren haben und werden wissenschaftlich begleitet.

Nach Abschluss eines Projekts werden die Ergebnisse ausgewertet und an relevante Gremien weitergeleitet, um zu prüfen, ob die Innovation in die Regelversorgung übernommen werden sollte.

Der Innovationsausschuss setzt sich aus Vertretern der Trägerorganisationen des G-BA (Krankenkassen, Kassenärztliche Vereinigungen, Krankenhäuser) sowie dem Bundesministerium für Gesundheit und dem Bundesministerium für Forschung zusammen. Er wird zudem von unabhängigen Experten aus Wissenschaft und Versorgung.

Zusammensetzung des Innovationsausschusses

1.4 Wer ist beteiligt?

Typischerweise schließen sich für Innovationsfondsprojekte verschiedene Akteure im Gesundheitswesen zu Konsortien zusammen. Dazu gehören z. B.:

• Krankenkassen
• Krankenhäuser und Universitätskliniken
• ärztliche Netzwerke oder MVZ
• Forschungseinrichtungen
• Private Unternehmen (z.B. im Bereich Digital Health)

Gemeinsam entwickeln sie ein Versorgungskonzept, das dann für mehrere Jahre unter Alltagsbedingungen erprobt wird. Digitale Gesundheitslösungen sind dabei oft ein zentraler Bestandteil – etwa zur Koordination, Kommunikation oder zur Diagnostik.

1.5 Förderkategorien im Überblick

Der Innovationsfonds unterscheidet zwei Förderbereiche gemäß § 92a SGB V:

• Kategorie 1: Neue Versorgungsformen
• Kategorie 2: Versorgungsforschung

Förderkategorien und Fördervolumen des Innovationsfonds (2025)

1.5.1 Kategorie 1: Neue Versorgungsformen

Hierunter fallen Projekte, die neue Versorgungsmodelle oder organisatorische Abläufe in der Patientenversorgung erproben. Digitale Gesundheitsanwendungen sind dabei oft Bestandteil des Konzepts – etwa Telemedizin-Plattformen, digitale Kommunikations-Tools oder KI-gestützte Diagnose- und Therapiesteuerung.

Wichtig: Diese Projekte finden unter Alltagsbedingungen in der Versorgung statt – etwa als Pilotprogramme mit echten Leistungserbringern und Patienten. Die digitale Lösung wird dabei immer in ein Versorgungskonzept eingebettet, etwa um Prozesse zu optimieren oder Sektorengrenzen zu überwinden.

Begleitet wird das Ganze durch eine wissenschaftliche Evaluation, um die Effekte auf Versorgung und Patientenversorgung messbar zu machen.

Für Hersteller medizinischer Software ist diese Kategorie besonders relevant, da hier speziell komplett neue Lösungen und Strukturen evaluiert werden.

1.5.2 Kategorie 2: Versorgungsforschung

In diesem Bereich geht es nicht um die Umsetzung neuer Versorgungsmodelle, sondern um die Analyse der bestehenden Versorgungsrealität. Gefördert werden z. B. wissenschaftliche Studien zur Evaluation von G-BA-Richtlinien, Leitlinienentwicklungen oder gesundheitsökonomische Analysen.

Für Hersteller ist diese Kategorie nur dann relevant, wenn die eigene digitale Lösung bereits Teil der Regelversorgung ist und im Rahmen einer Studie evaluiert werden soll.

Wenn dagegen das Produkt erst noch in die Versorgung gebracht werden soll, fällt das Vorhaben nicht in diese Kategorie, sondern gehört zu den „Neuen Versorgungsformen“.

Hinweis: In diesem Artikel konzentrieren wir uns ausschließlich auf den Förderbereich „Neue Versorgungsformen“, da dieser für Hersteller medizinischer Software in der Praxis deutlich relevanter ist als die ebenfalls mögliche Förderung im Bereich Versorgungsforschung.

2. Unterschied zwischen Förderung & Erstattung

Wenn wir über die Finanzierung digitaler Gesundheitslösungen sprechen, ist es wichtig, den Unterschied zwischen Förderung und Erstattung zu verstehen. Eine Erstattung – wie etwa bei DiGA – bedeutet: Die Anwendung ist im Leistungskatalog der GKV enthalten, und jede Nutzung wird von der Krankenkasse bezahlt. Das schafft planbare Umsätze und ist Teil der Regelversorgung.

Der Innovationsfonds funktioniert anders: Hier handelt es sich nicht um eine dauerhafte Leistung, sondern um eine zeitlich begrenzte Projektförderung.

Für Hersteller von Software-Produkten bedeutet eine Förderung über den Innovationsfonds konkret: Die Kosten für die Software-Implementierung im Projekt sind gedeckt – sei es als Auftragnehmer oder Konsortialpartner. Und auch wenn die Software noch nicht offiziell von den Kassen erstattet wird, fließt bereits Geld – über den G-BA-Fördertopf.

Gleichzeitig entstehen dabei echte Versorgungsdaten, die später als Grundlage für weitere Erstattungswege dienen können: etwa Selektivverträge oder eine Vergütung über das DRG-System.

3. Voraussetzungen für die Förderung durch den Innovationsfonds

3.1 Welche Projekte werden gefördert?

Gefördert werden neue Versorgungsformen, die

• insbesondere die Weiterentwicklung der sektorenübergreifenden Versorgung zum Ziel haben:
  • Überwindung der Trennung der Sektoren
  • Optimierung intersektoraler Schnittstellen
  • Weiterentwicklung der selektivvertraglichen Versorgung
• ein tragfähiges Evaluationskonzept vorweisen und
• ein hinreichendes Potenzial für eine dauerhafte Aufnahme in die Versorgung (Umsetzungspotenzial) aufweisen.

Weitere Informationen dazu finden Sie hier.

3.2 Welche Projekte werden nicht gefördert?

Nicht jedes Projekt ist für eine Förderung durch den Innovationsfonds geeignet. Es gibt eine Reihe von Ausschlusskriterien, die Antragsteller kennen sollten, bevor sie Zeit und Ressourcen investieren. Hier die wichtigsten Punkte:

• Wirtschaftlich getriebene Produktentwicklung: Der Innovationsfonds ist kein Förderprogramm für klassische Produktentwicklung mit direktem kommerziellem Ziel. Projekte, bei denen Unternehmen der gewerblichen Wirtschaft ein unmittelbares wirtschaftliches Interesse am Ergebnis haben, sind ausgeschlossen – etwa die Entwicklung oder Erprobung eines Produkts mit dem Ziel, es anschließend direkt zu verkaufen.
• Klassische F&E, Zulassungs- oder Arzneimittelstudien
  • Forschung und Entwicklung von Medizinprodukten oder Arzneimitteln
  • Klinische Prüfungen nach EU-Medizinprodukteverordnung (EU) 2017/745
  • Leistungsbewertungsprüfungen für In-vitro-Diagnostika
  • AMNOG-Studien zur frühen Nutzenbewertung von Arzneimitteln
  • Studien zur Erprobung neuer Untersuchungs- und Behandlungsmethoden (§ 137e SGB V)
• DiGA- und DiPA-Nachweisstudien: Auch Studien zum Nachweis positiver Versorgungseffekte im Rahmen von DiGA (§ 33a SGB V) oder DiPA (§ 40a SGB XI) sind nicht förderfähig. Diese Nachweise müssen separat über das BfArM bzw. entsprechende Verfahren erbracht werden und fallen nicht in den Zuständigkeitsbereich des Innovationsfonds.
• Projekte in der Umsetzung oder mit anderer Förderung: Bereits gestartete Projekte oder Vorhaben, die zum Zeitpunkt der Antragstellung bereits anderweitig (z. B. aus öffentlichen Mitteln) gefördert werden, sind ausgeschlossen. Der Innovationsfonds fördert keine Doppelstrukturen oder rückwirkenden Maßnahmen.
• Doppelte Bewerbung ausgeschlossen: Für jede der in einem Jahr ausgeschriebenen Förderbekanntmachungen zu „Neuen Versorgungsformen“ darf man sich nur einmal Eine doppelte oder parallele Antragstellung mit gleichem Projektansatz ist nicht zulässig.

4. Das Antragsverfahren des Innovationsfonds

4.1 Welche Antragsverfahren gibt es?

Der Innovationsfonds unterscheidet im Bereich der Neuen Versorgungsformen vier verschiedene Förderformate. Diese unterscheiden sich im Hinblick auf Themenvorgabe, Ablaufstruktur (ein- vs. zweistufig) und Projektdauer:

1. Themenoffene Förderung – Einstufig lang

In diesem Verfahren wird ein vollständiger Antrag direkt eingereicht. Das Projekt muss dabei bereits umfassend geplant sein, inklusive Evaluationskonzept, Zeit- und Finanzplan sowie Konsortium.

2. Themenoffene Förderung – Einstufig kurz

Dieses Format richtet sich an kleinere, schneller startende Projekte mit einer Laufzeit von maximal 24 Monaten. Auch hier erfolgt die Antragstellung direkt und vollständig in einem Schritt.

3. Themenspezifische Förderung – Zweistufig lang

Bei diesem Verfahren gibt es zwei Phasen:

• Stufe 1: Konzeptphase – Einreichung einer Ideenskizze zu einem vorgegebenen Thema.
• Stufe 2: Vollantrag – Eingereicht wird ein kompletter Förderantrag mit vollständig ausgearbeitetem Versorgungskonzept, konkreten Versorgungszielen und Umsetzungsplanung, validiertem Evaluationskonzept, Zeit- und Finanzplan und verbindlichen Zusagen aller Konsortialpartner.

Dieses Verfahren eignet sich für komplexe Projekte mit größerem Planungsbedarf.

4. Themenoffene Förderung – Zweistufig lang

Auch hier ist das Verfahren zweistufig:

• Stufe 1: Konzeptphase – Ideenskizze ohne thematische Vorgabe.
• Stufe 2: Vollantrag – wie bei der themenspezifischen Variante.

Damit bietet diese Förderlinie Freiraum für innovative Ideen mit größerem Entwicklungsaufwand.

Hinweis: Alle Verfahren setzen voraus, dass die Antragsunterlagen vollständig und fristgerecht eingereicht werden. Welche Unterlagen erforderlich sind (z. B. Projektbeschreibung, Konsortialvertrag, Finanzierungsplan, Ethikkonzept), ist detailliert in den jeweiligen Förderbekanntmachungen geregelt.

→ Link zu den aktuellen Ausschreibungen:
https://innovationsfonds.g-ba.de/foerderbekanntmachungen/

4.2 Welches Antragsverfahren passt zu meinem Projekt?

Wann welcher Antrag am ehesten in Frage kommt, hängt vom Reifegrad der Projektidee ab.

1. Reifer Projektstand:
   1. Projektidee ist vollständig ausgearbeitet.
   2. Es liegt ein ausgereiftes Versorgungskonzept vor.
   3. Konsortialpartner (z. B. Kassen, Versorgungseinrichtungen) sind verbindlich eingebunden.
   4. Evaluationskonzept, Zeitplan und Budget sind konkret geplant.
      ➔ einstufiges Verfahren
      
2. Weniger ausgereifter Projektstand:
   1. Grundidee ist vorhanden, aber noch nicht detailliert ausgearbeitet.
   2. Es fehlt noch an validierten Partnern, konkreter Evaluation oder präziser Umsetzungsplanung.
   3. Ziel ist es, in einer 6-monatigen Konzeptphase (Stufe 1) die Projektidee zu schärfen.
   4. Danach kann ein Vollantrag in Stufe 2 gestellt werden.
      ➔ zweistufiges Verfahren

Vergleich des einstufigen und zweistufigen Verfahrens:

The post Innovationsfonds: Förderung für digitale Gesundheitslösungen appeared first on QuickBird Medical.

Was in Deutschland als „digitale Gesundheitsanwendung“ (DiGA) bezeichnet wird, heißt in Frankreich „Dispositifs Médicaux Numériques“ (DMN) und im internationalen Kontext „Digital Medical Device“ (DMD).

Für Hersteller entsteht damit ein strukturiertes Schnellverfahren, um digitale Medizinprodukte für einen zeitlich begrenzten Zeitraum über die gesetzliche Krankenversicherung in Frankreich erstatten zu lassen.

In diesem Beitrag liefern wir einen Leitfaden, der erklärt …

• wie PECAN funktioniert,
• inwiefern das Verfahren vom deutschen Erstattungsweg abweicht,
• welche Anforderungen gelten,
• und warum ein Transfer einer DiGA nach Frankreich zwar naheliegt, in der Praxis aber anspruchsvoll ist.

Überblick

• 1. Hintergrund: DiGA-Modell in Deutschland
• 2. Einführung: Erstattung von DMD in Frankreich: PECAN
• 3. Regulatorischer Rahmen des PECAN
  • 3.1 Anwendungsbereich
  • 3.2 Zentrale Prinzipien
  • 3.3 Erstattungskriterien und Anforderungen für DMD in Frankreich
  • 3.4 Ausschlussgründe
•  4. Antragsverfahren des PECAN
• 5. Verfahren nach positiver PECAN-Entscheidung
• 6. Kostenerstattung von DMD
  • 6.1 Erstattungshöhe während des PECAN-Jahrs
  • 6.2 Erstattung nach Ablauf des PECAN-Jahrs
• 7. Klinische Bewertung im PECAN-Verfahren
  • 7.1 Evidenzbasiert und kontextabhängig
  • 7.2 Datenbasis
  • 7.3 Klinischer Nutzen und Endpunkte
  • 7.4. Organisatorischer Nutzen als Innovationsargument
• 8. Akteure und Zuständigkeiten
• 9. Stand 2026: DiGA-Verzeichnis von Frankreich
• 10. Vergleich: DiGA Fasttrack vs. DMD und PECAN
• 11. Von Deutschland nach Frankreich: DiGA zu PECAN
  • 11.1 Beispiel: DiGA von „HelloBetter“ – Antrag auf PECAN-Erstattung
  • 11.2 Blick nach vorn: Deutsch-französische Annäherung
• 12. Hilfreiche Links
• 13. DiGA-Modelle in anderen Ländern
• 14. Fazit: Das DMD-Framework als DiGA mit Zusätzen

1. Hintergrund: DiGA-Modell in Deutschland

Seit 2019 gibt es in Deutschland mit dem DiGA-Fast-Track einen standardisierten Erstattungsweg für „Digitale Gesundheitsanwendungen“ (DiGA). Hersteller können beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) einen Antrag auf Aufnahme in das DiGA-Verzeichnis stellen. Im Rahmen des Fast-Tracks prüft das BfArM, ob die Anwendung die regulatorischen und formalen Anforderungen erfüllt (u. a. MDR/CE, Datenschutz/IT-Sicherheit) und ob ein positiver Versorgungseffekt nachgewiesen ist. Bei positiver Entscheidung wird die DiGA in das Verzeichnis aufgenommen und ist anschließend über die gesetzlichen Krankenkassen erstattungsfähig.

Der Fast-Track kennt dabei zwei mögliche Einstiegswege:

• Entweder erfolgt direkt eine dauerhafte Aufnahme, wenn der Nutzennachweis bereits vollständig vorliegt,
• oder eine vorläufige Aufnahme, wenn noch keine vollständige Studie zum positiven Versorgungseffekt existiert. In diesem Fall muss der Hersteller trotzdem ein Evaluationskonzept inklusive Evidenz aus einer Pilotstudie vorlegen. Bei positiver Bewertung wird die DiGA dann erstattet, während der Hersteller im sogenannten Erprobungsjahr die fehlenden Daten für eine vollständige Studie nachreicht. Erst nach erfolgreichem Abschluss kann die Anwendung dauerhaft im DiGA-Verzeichnis verbleiben.

Das französische Modell lehnt sich an dieses deutsche Modell zur Erstattung von digitalen Gesundheitsanwendungen an, hat aber gleichzeitig einige fundamentale Unterschiede.

2. Einführung: Erstattung von DMD in Frankreich: PECAN

PECAN steht für „Prise en Charge Anticipée Numérique“. Wörtlich: vorläufige digitale Kostenübernahme. Das Verfahren ermöglicht es Herstellern seit 2023, digitale Medizinprodukte mit vermutetem Innovationscharakter für maximal zwölf Monate vorläufig über die gesetzliche Krankenversicherung zu erstatten.

Frankreich hat mit PECAN vor allem die Idee der vorläufigen Erstattung aus dem DiGA-Fast-Track aufgegriffen. Der zentrale Unterschied zu Deutschland ist nämlich, dass der Übergang in die dauerhafte Erstattung nicht im selben Verfahren erfolgt. Die dauerhafte Erstattung muss anschließend über einen separaten regulären Weg (LPPR oder LATM) beantragt werden, der schon lange vor PECAN existierte.

Digitale Gesundheitsanwendungen werden in Frankreich zudem nicht als DiGA bezeichnet, sondern als „Dispositifs Médicaux Numériques“ (DMN) und im internationalen Kontext als „Digital Medical Devices“, kurz DMD.

3. Regulatorischer Rahmen des PECAN

Die rechtliche Grundlage des PECAN-Verfahrens ist Artikel L. 162-1-23 des französischen Sozialversicherungsrechts (Code de la Sécurité Sociale, CSS). Damit ist PECAN gesetzlich verankert und als vorläufiger Erstattungsmechanismus rechtlich verbindlich geregelt.

Zusätzlich stellt die französische Gesundheitsbehörde Haute Autorité de Santé (HAS) einen Leitfaden zur Verfügung, der Herstellern als praktisches Handbuch dienen soll. Er beschreibt nicht nur die wissenschaftlichen Anforderungen an die Nutzenvermutung, sondern konkretisiert auch die formalen Kriterien für technische Nachweise, insbesondere zu Interoperabilität und IT-Sicherheit. Ergänzend enthält das Dokument aktuelle Praxisbeispiele. Im Vergleich zum deutschen DiGA-Leitfaden fällt er mit rund 27 Seiten deutlich kompakter aus.

3.1 Anwendungsbereich

Der Anwendungsbereich umfasst zwei Kategorien digitaler Medizinprodukte:

1. digitale Medizinprodukte mit therapeutischer Zweckbestimmung und
2. digitale Medizinprodukte zur medizinischen Teleüberwachung.

Im Vergleich dazu ist der Anwendungsbereich des deutschen DiGA-Fast-Tracks enger gefasst und schließt keine Telemonitoring-Anwendungen ein.

3.2 Zentrale Prinzipien

Das PECAN-Verfahren folgt laut dem Leitfaden vier Prinzipien, die Hersteller kennen sollten:

1. Fast-Track zur vorläufigen Erstattung:
   PECAN ist ein gesondertes Verfahren, das der regulären Erstattung vorgelagert ist.
2. Zeitlich strikt begrenzt:
   Die vorläufige Erstattung gilt maximal 12 Monate ab Entscheidung, eine Verlängerung ist ausgeschlossen. Eine weitere Kostenerstattung ist nur über einen separaten Antrag in der Regelversorgung (LPPR oder LATM) möglich.
3. Kumulative Förderkriterien:
   Alle gesetzlichen Voraussetzungen müssen gleichzeitig erfüllt sein.
4. Technische Zertifizierung:
   Zusätzlich zur Bewertung durch die Commission nationale d’évaluation des dispositifs médicaux et des technologies de santé (CNEDiMTS) ist eine Zertifizierung durch die Agence du Numérique en Santé (ANS) erforderlich. Die einzelnen Institutionen werden in Kapitel 8 nochmal detaillierter betrachtet.

3.3 Erstattungskriterien und Anforderungen für DMD in Frankreich

Damit ein DMD für das PECAN-Verfahren infrage kommt, müssen die folgenden Kriterien und Anforderungen erfüllt sein. Wichtig ist dabei: Die Bewertung erfolgt immer indikationsspezifisch. Ein Produkt kann also für eine Indikation PECAN-fähig sein, für eine andere nicht.

3.3.1 Erstattungskriterium 1:  CE-Kennzeichnung nach MDR

Kurz gesagt: Ohne CE kein PECAN.
Wie auch in Deutschland gilt: Nicht jede Software ist eine digitale Gesundheitsanwendung, aber jede DMD ist ein Medizinprodukt und unterliegt der Medical Device Regulation (MDR).

Für PECAN bedeutet das:

• Das DMD muss eine gültige CE-Kennzeichnung nach MDR besitzen.
• Die beantragte Indikation muss mit der Indikation für die CE-Zertifizierung nach MDR übereinstimmen.

So wird geprüft:

• Maßgeblich ist die Indikation in der Gebrauchsanweisung.
• Weicht die im PECAN-Antrag genannte Indikation sprachlich oder inhaltlich davon ab, muss der Hersteller dies im Dossier klar begründen und erläutern.

Weitere Informationen zur Zulassung und Zertifizierung von Medizinprodukt-Software nach MDR finden Sie in unserem Leitfaden zum Thema.

3.3.2 Erstattungskriterium 2: Vermutete Innovation

Neben der CE-Kennzeichnung muss das DMD als mutmaßlich innovativ gelten. Entscheidend ist dabei, ob die Technologie:

• einen klinischen Nutzen erwarten lässt
  oder
• einen messbaren Fortschritt in der Organisation der Versorgung bietet.

Zwei Mindestanforderungen gelten dabei immer:

• Ein organisatorischer Fortschritt darf die Versorgungsqualität nicht beeinträchtigen.
• Für das digitale Medizinprodukt müssen laufende Studien vorliegen, die voraussichtlich genügend Daten liefern, um anschließend die dauerhafte Erstattung beantragen zu können.

Deutschland nutzt hierfür einen ähnlichen Bewertungsansatz: Statt „mutmaßlicher Innovation“ ist im DiGA-Fast-Track der „positive Versorgungseffekt“ entscheidend, der entweder über einen medizinischen Nutzen (mN) oder über eine patientenrelevante Struktur- und Verfahrensverbesserung (pSVV) nachgewiesen werden muss.

3.3.3 Erstattungskriterium 3: Technische Voraussetzungen

Parallel zur Bewertung durch die CNEDiMTS prüft die ANS die technischen Anforderungen.

Konkret muss das DMD:

• die Vorgaben zum Datenschutz erfüllen,
• die nationalen Interoperabilitäts- und IT-Sicherheitsstandards einhalten,
• einen standardisierten, interoperablen Datenexport ermöglichen,
• ggf. Schnittstellen zu Geräten zur Erfassung von Vitalparametern bieten.

Für die dauerhafte Erstattung ist zudem ein offizielles Interoperabilitätszertifikat erforderlich, u. a. im Zusammenspiel mit der französischen nationalen eHealth-ID (INS).

Auch mit dem DiGA-Fast-Track in Deutschland sind Datenschutz, Informationssicherheit und Interoperabilität zentrale Anforderungen.

Erstattungskriterien für PECAN im Vergleich zu DiGA

3.4 Ausschlussgründe

Eine vorläufige Erstattung ist nicht möglich, wenn:

• das DMD bereits eine PECAN-Erstattung für dieselbe Indikation hatte,
• eine PECAN bereits abgelehnt wurde
  → Ausnahme: Neue Daten bei zuvor unzureichender Evidenz,
• eine behördliche Aussetzung oder ein Verbot besteht,
• PECAN mit anderen Erstattungsmechanismen kombiniert werden soll (z. B. LPPR, LATM, Innovationspauschale, Übergangserstattung).

4. Antragsverfahren des PECAN

Das Antragsverfahren besteht insgesamt aus drei Phasen.

1. Einreichung & formale Prüfung des Dossiers

Der Hersteller reicht das Dossier bei den zuständigen Ministerien für Gesundheit und soziale Sicherheit ein, mit Kopie an die HAS.

In dieser ersten Phase wird geprüft:

• Ist das Dossier vollständig?
• Entspricht es den formalen Anforderungen der HAS?

Falls Unterlagen fehlen, erhält der Hersteller eine Nachforderung.

Frist: 30 Tage, um die fehlenden Informationen nachzureichen. Wer diese Frist verpasst, dessen Antrag wird als „zurückgezogen“ eingeordnet.

2. Stellungnahme durch die CNEDiMTS

Bei vollständigem Dossier bewertet die CNEDiMTS die Förderfähigkeit. Im Fokus stehen Indikation und vermutete Innovation.

Die Bewertung erfolgt ohne Rückfragen oder Anhörungen der Antragsteller.

Bearbeitungszeit: maximal 60 Tage ab vollständigem Antrag.

Am Ende steht eine positive oder negative Stellungnahme, die:

• an die Ministerien,
• an den Hersteller,
• und an die betroffenen Fachgremien (CNP) geht und öffentlich auf der HAS-Website veröffentlicht wird.

3. Entscheidung über die vorläufige Erstattung

Auf Basis der CNEDiMTS-Stellungnahme entscheiden die zuständigen Ministerien.

Frist: 30 Tage

Die Entscheidung wird per ministeriellem Erlass im „Journal officiel“ veröffentlicht und legt fest:

• ob das Produkt vorläufig erstattet wird,
• und zu welchen finanziellen Bedingungen.

5. Verfahren nach positiver PECAN-Entscheidung

Nach einer positiven PECAN-Entscheidung wird das digitale Medizinprodukt für maximal zwölf Monate vorläufig erstattet. In dieser Zeit muss der Hersteller den Übergang in die dauerhafte Erstattung vorbereiten. PECAN dient quasi als Brücke zur regulären Erstattung:

• Für digitale Medizinprodukte mit therapeutischer Zweckbestimmung ist der reguläre Erstattungsweg die Aufnahme in die Liste der erstattungsfähigen Produkte und Leistungen LPPR. Der Hersteller muss den Folgeantrag innerhalb von 6 Monaten nach der PECAN-Entscheidung einreichen. Auch hierfür stellt die HAS einen Leitfaden bereit.
• Für digitale Medizinprodukte zur medizinischen Teleüberwachung ist der reguläre Erstattungsweg die Aufnahme in die Liste der Aktivitäten der medizinischen Teleüberwachung LATM. Der Hersteller muss den Folgeantrag innerhalb von 9 Monaten nach der PECAN-Entscheidung einreichen. Auch hierfür stellt die HAS einen Leitfaden bereit.

Die untenstehende Abbildung fasst das PECAN-Verfahren und die nachfolgenden regulären Erstattungswege zusammen.

PECAN-Verfahren und anschließender Erstattungsweg der Regelversorgung

6. Kostenerstattung von DMD

Hier gehen wir auf die konkreten Regelungen zur Kostenerstattung von DMD im Rahmen des PECAN und danach ein.

6.1 Erstattungshöhe während des PECAN-Jahrs

Während des PECAN-Verfahrens werden Preise über staatlich definierte Pauschalen geregelt. Diese umfassen für:

Digitale Therapeutika (DTx)

• ein Erstpaket in Höhe von 435 €. Dieses kann einmalig pro Patienten abgerechnet werden. Es gilt für die effektive Nutzung des digitalen Medizinprodukts für maximal 3 Monate.
• Ein Folgepaket, das an das Erstpaket anschließt. Dieses wird anteilig entsprechend der vorgesehenen Verordnungsdauer und der tatsächlichen Nutzung abgerechnet und beträgt 38,30 € pro Monat.
• Die maximale finanzielle Entschädigung, bestehend aus den beiden zuvor genannten Pauschalbeträgen, beträgt 780 € pro Patienten und Jahr.

Weitere Informationen finden Sie im Absatz II des Artikels R. 162-117 des Sozialversicherungsgesetzbuches.

Für Telemonitoring-Lösungen

• erhält der technische Betreiber eine monatliche Pauschale von 50 € bis 91,67 € je nach nachgewiesenem Interesse.
• Die medizinische Überwachungsleistung wird separat vergütet (z. B. ärztlich oder pflegerisch).

Weitere Informationen finden Sie im Artikel L162-52 des Sozialversicherungsgesetzbuches.

6.2 Erstattung nach Ablauf des PECAN-Jahrs

Nach dem PECAN-Jahr endet die Pauschalvergütung. Für die dauerhafte Erstattung wird der Preis anschließend im jeweiligen Regelpfad über LPPR (für DTx) oder LATM (für Telemonitoring-Anwendungen) neu verhandelt, nutzbasiert und unter Einbindung des Comité économique des produits de santé (CEPS).

LPPR für digitale Gesundheitsanwendungen bzw. DTx

Im Regelpfad der LPPR erfolgt die Erstattung als Preis pro Einheit. Wichtig ist dabei, dass der tatsächliche Produktpreis höher sein kann als der Betrag, den die Krankenkasse erstattet. Die Differenz wird dann vom Patienten, seiner Zusatzkrankenversicherung (Mutuelle) oder einer anderen Organisation übernommen.

LATM für Telemonitoring

Im Regelpfad der LATM für Telemonitoring werden pro Patienten zwei Pauschalbeträge erstattet:

• ein Pauschalbetrag, der an den Fernüberwachungsbetreiber gezahlt wird, sowie
• ein Pauschalbetrag, der an den Betreiber gezahlt wird.

Die Sätze für die technischen Pakete werden dabei unter Berücksichtigung des organisatorischen oder klinischen Interesses festgelegt, das von der medizinischen Fernüberwachung zu erwarten ist. Das klinische Interesse wird anhand der Auswirkungen auf die Lebensqualität, die Morbidität oder die Mortalität bewertet.

7. Klinische Bewertung im PECAN-Verfahren

Die klinische Bewertung ist ein zentraler Bestandteil des PECAN-Verfahrens. Die CNEDiMTS prüft dabei, ob ein DMD als mutmaßlich innovativ gelten kann und ob die vorgelegten sowie laufenden Studien geeignet sind, kurzfristig die Grundlage für eine reguläre Erstattung über LPPR oder LATM zu schaffen. Maßgeblich sind dabei die Prinzipien der evidenzbasierten Medizin.

7.1 Evidenzbasiert und kontextabhängig

Die Bewertung erfolgt nicht losgelöst von der Versorgungspraxis. Die CNEDiMTS beurteilt die klinische Relevanz der Daten stets im Zusammenhang mit:

• der zugrunde liegenden Erkrankung,
• ihrer Epidemiologie,
• sowie der therapeutischen Strategie, in die das digitale Medizinprodukt eingebettet ist.

Entscheidend ist zudem, ob sich die Ergebnisse auf das französische Gesundheitssystem übertragen lassen. Bei begrenzten Rekrutierungsmöglichkeiten können internationale multizentrische Studien akzeptiert werden. Voraussetzung ist aber, dass ihre Übertragbarkeit auf das französische System nachvollziehbar begründet werden kann.

7.2 Datenbasis

Grundsätzlich stützt sich die CNEDiMTS bevorzugt auf produktspezifische klinische Daten. In bestimmten Fällen können jedoch auch nicht-produktspezifische Daten berücksichtigt werden, etwa zu technologisch vergleichbaren Lösungen oder früheren Versionen des Produkts.

Voraussetzung ist in diesen Fällen:

• eine schlüssige Begründung der technischen Äquivalenz,
• eine transparente Analyse möglicher Unterschiede,
• sowie der Nachweis, dass diese Unterschiede keinen relevanten Einfluss auf den klinischen oder technischen Effekt haben.

7.3 Klinischer Nutzen und Endpunkte

Der klinische Nutzen wird immer im Vergleich zu einer relevanten Vergleichsalternative bewertet. Dabei berücksichtigt die CNEDiMTS sowohl positive Effekte als auch potenzielle Risiken der Anwendung.

Beispielhafte Bewertungsdimensionen im PECAN-Leitfaden des CNEDiMTS sind:

• Lebensqualität,
• Morbidität oder Mortalität,
• Komplikationen,
• Reduktion ungeplanter Krankenhausaufenthalte.

Wichtig ist, dass die gewählten Endpunkte zur beanspruchten Indikation und zum Wirkversprechen des Produkts passen. In der Praxis zeigt sich, dass formal korrekte, aber inhaltlich unpassende Endpunkte häufig zu kritischen Bewertungen führen.

7.4 Organisatorischer Nutzen als Innovationsargument

Neben dem klinischen Nutzen kann auch ein Fortschritt in der Organisation der Versorgung zur Begründung der Innovationsannahme herangezogen werden. Das kann etwa durch neue Versorgungsprozesse oder eine verbesserte Zugänglichkeit der Versorgung, insbesondere im Bereich der Teleüberwachung, geschehen.

Die CNEDiMTS stellt jedoch fest, dass dieser Nutzen in Anträgen häufig nur beschreibend, aber nicht systematisch belegt wird. Empfohlen wird daher, organisatorische Effekte strukturiert darzustellen, z. B. anhand der beteiligten Akteure, veränderter Prozesse und geeigneter Bewertungskriterien.

8. Akteure und Zuständigkeiten

Für das PECAN-Verfahren sind vor allem die folgenden Akteure im französischen Gesundheitssystem relevant:

• CNEDiMTS („Commission nationale d’évaluation des dispositifs médicaux et des technologies de santé“ bzw. Nationale Kommission zur Bewertung von Medizinprodukten und Gesundheitstechnologien): Bewertet die medizinische und versorgungsbezogene Evidenz.
• ANS („Agence du Numérique en Santé“ bzw. Nationale Agentur für digitale Gesundheit): Prüft technische Anforderungen wie Datenschutz, Interoperabilität und IT-Sicherheit.
• Ministère chargé de la Santé & Ministère chargé de la Sécurité sociale (bzw. Ministerien für Gesundheit und soziale Sicherheit): Treffen die finale Entscheidung über die vorläufige Kostenübernahme und setzen diese per ministeriellem Erlass um, basierend auf den Stellungnahmen der CNEDiMTS und der ANS.
• HAS („Haute Autorité de Santé“ bzw. Französische Gesundheitsbehörde): Bietet u.a. sogenannte „frühe Beratungsgespräche“ an. Diese richten sich an Hersteller, deren Produkte sich noch in der klinischen Entwicklung befinden. Inhaltlich können dabei Fragen zur klinischen Evidenzstrategie besprochen werden, optional auch in Kombination mit gesundheitsökonomischen Themen (Effizienzbewertung). Wichtig: Die Gespräche sind optional, unverbindlich, vertraulich und kostenfrei. Sie gelten nicht als Bewertung und lassen keine Rückschlüsse auf die spätere Entscheidung der CNEDiMTS zu.
  • G_NIUS („Guichet National de l’Innovation et des Usages en e-Santé“ bzw. Nationale Anlaufstelle für Innovation und Anwendungen im Bereich E-Health): Ist eine nationale Plattform zur Förderung von Innovationen im Bereich Digital Health. Sie unterstützt Entwickler und Hersteller insbesondere bei der Orientierung im regulatorischen Umfeld, der Identifikation von Finanzierungs- und Fördermöglichkeiten, sowie der Vernetzung mit relevanten Akteuren im französischen E-Health-Ökosystem. Ziel ist es, die Markteinführung neuer digitaler Technologien zu erleichtern und zu beschleunigen.

9. Stand 2026: DiGA-Verzeichnis von Frankreich

Obwohl das PECAN-Verfahren seit 2023 operativ verfügbar ist, spielt es in der Versorgungspraxis bislang nur eine untergeordnete Rolle. Anders als in Deutschland gibt es kein eigenständiges öffentliches DMD-Register. Digitale Medizinprodukte erscheinen nur indirekt in bestehenden Erstattungsstrukturen:

• LPPR (Liste des Produits et Prestations Remboursables): zentrales Erstattungsverzeichnis für alle Medizinprodukte, ohne Kennzeichnung digitaler Anwendungen
• LATM (Liste des Activités de Télésurveillance Médicale): Verzeichnis für erstattungsfähige Telemonitoring-Leistungen, ebenfalls ohne expliziten DMD-Status

Damit gibt es keine öffentliche Übersicht, welche DMD aktuell (vorläufig) erstattet werden.

Öffentlich nachvollziehbar ist bislang nur eine Anwendung, die tatsächlich über PECAN erstattet wurde:

Cureety TechCare

• Telemonitoring-Lösung für onkologische Patienten
• Aufnahme in PECAN: 2023
• kein Übergang in die dauerhafte Erstattung über die LATM
• Als wesentliche Gründe werden fehlende oder nicht ausreichend belastbare Nachweise zum langfristigen klinischen Nutzen und organisatorischen Mehrwert genannt.

10. Vergleich: DiGA Fasttrack vs. DMD und PECAN

Deutschland und Frankreich verfolgen das gleiche Ziel: digitale Medizinprodukte schneller in die Versorgung zu bringen. Der Unterschied liegt vor allem in Struktur, Transparenz und Preislogik.

• Erstattungslogik:
  Sowohl das deutsche DiGA-Verfahren als auch das französische System sehen eine vorläufige Erstattung vor. In Deutschland sind die vorläufige und die dauerhafte Erstattung innerhalb desselben DiGA-Regelwerks verankert. In Frankreich ist die PECAN-Erstattung ausdrücklich als temporärer Einstieg konzipiert und auf zwölf Monate begrenzt. Eine dauerhafte Erstattung erfordert anschließend einen eigenständigen Antrag über LPPR oder LATM, also etablierte, nicht speziell auf digitale Anwendungen zugeschnittene Erstattungsmechanismen.
• Erstattung:
  In beiden Ländern übernehmen die gesetzlichen Krankenkassen die Kosten für die Erstattung.
• CE-Zertifizierung:
  In beiden Systemen ist die CE-Kennzeichnung nach MDR zwingend.
• Klinische Evaluation:
  Beide Verfahren arbeiten evidenzbasiert. DiGA zielt auf den positiven Versorgungseffekt, PECAN auf mutmaßliche Innovation plus belastbare Studienplanung.
• Datenschutz & IT-Sicherheit:
  Die Anforderungen sind in beiden Ländern vergleichbar hoch. Deutschland bündelt die Prüfung im DiGA-Verfahren. Frankreich trennt sie organisatorisch: klinisch über die CNEDiMTS, technisch über die ANS.
• Risikoklassen:
  In Deutschland ist der DiGA-Fast-Track auf Medizinprodukte der Risikoklassen I, IIa und IIb beschränkt. Produkte der Klasse III sind nicht inkludiert.
  PECAN enthält keine formale Begrenzung der MDR-Risikoklasse.
• Register & Transparenz:
  In Deutschland gibt es mit dem DiGA-Verzeichnis ein eigenes, öffentliches Register ausschließlich für DiGA-Anwendungen. Ein vergleichbares, separates Verzeichnis für digitale Medizinprodukte existiert in Frankreich bislang nicht, wodurch ein transparenter Marktüberblick deutlich erschwert wird.
• Preisbildung:
  Im DiGA-Fast-Track können Hersteller den Preis während des Erprobungszeitraums unter Einhaltung der Höchstbeträge frei festlegen. Für die dauerhafte Listung müssen sie einen Vergütungsbetrag mit dem GKV-Spitzenverband verhandeln.
  PECAN hingegen arbeitet in der vorläufigen Phase mit staatlich fixierten Pauschalen. Der endgültige Preis wird nach Ablauf des PECAN mit dem CEPS im Rahmen der regulären Erstattungswege verhandelt.

Unterschiede zwischen DMD und DiGA-Fast-Track

11. Von Deutschland nach Frankreich: DiGA zu PECAN

Nach dem Vergleich liegt der Gedanke nahe: Wenn eine DiGA in Deutschland funktioniert, warum nicht auch in Frankreich?

Auf dem Papier gibt es viele Parallelen: MDR-Basis, frühe Erstattung, Fokus auf Evidenz. Können deutsche DiGA-Hersteller also einfach mit den existierenden Produkten und Studien nach Frankreich gehen, um diesen neuen Markt zu erschließen?

In der Praxis scheint der Transfer leider nicht so einfach zu sein. Evidenz aus klinischen Studien in Deutschland wird in Frankreich ggf. nicht so einfach akzeptiert.

11.1 Beispiel: DiGA von „HelloBetter“ – Antrag auf PECAN-Erstattung

Das zeigt auch der Fall HelloBetter Insomnie. Als Hersteller von mehreren in Deutschland gelisteten DiGA reichte HelloBetter auch ein Dossier im PECAN-Verfahren ein.

Das Ergebnis war eine negative Stellungnahme der HAS und damit keine vorläufige Erstattung über PECAN. Als Begründung wurde angeführt, dass die vorgelegten Daten die erforderliche „Vermutung von Innovation“ nicht ausreichend belegen konnten. Damit sei kein ausreichender klinischer Nutzen bzw. Versorgungsfortschritt nachgewiesen worden.

Der Fall macht deutlich: DiGA-Evidenz aus Deutschland ist nicht automatisch PECAN-fähig. Unterschiede in Indikationsabgrenzung, Comparatoren, Versorgungslogik und Endpunkten spielen eine zentrale Rolle.

Stellungnahmen:

• Stellungnahmen der HAS finden Sie hier und hier
• Stellungnahmen des Herstellers „HelloBetter“ zu dieser Ablehnung finden Sie hier

11.2 Blick nach vorn: Deutsch-französische Annäherung

Trotz solcher Rückschläge ist die Richtung klar: Harmonisierung statt Insellösungen.
Der G-BA und die HAS arbeiten bereits an einer engeren Abstimmung, insbesondere bei:

• klinischen Evidenzanforderungen
• methodischen Standards
• technischer Bewertung digitaler Medizinprodukte

Ziel:
Hersteller sollen ihre Evidenz perspektivisch parallel für beide Märkte nutzen können.

12. Hilfreiche Links

Für weitere Informationen in Bezug auf die Erstattung von digitalen Gesundheitsanwendungen in Frankreich finden Sie hier eine Sammlung von wichtigen Links:

Links bezüglich PECAN-Verfahren:

• Rechtsgrundlage PECAN (CSS Art. L. 162-1-23): Der gesetzliche Rahmen für die vorläufige Kostenübernahme von DMD.
• PECAN-Leitfaden CNEDiMTS (HAS): Zentrales Dokument für Hersteller: Bewertungslogik, Anforderungen, Beispiele, typische Ablehnungsgründe.
• Arrêtés zur PECAN-Vergütung (DTx, Telemonitoring): Die Rechtsakte, die die Pauschalen/Parameter für die vorläufige Vergütung festlegen bzw. aktualisieren.
• PECAN-Übersicht (G_NIUS): Kurze, gut verständliche Zusammenfassung von PECAN inkl. Einordnung in die Erstattungslogik.

Links für Erstattung in der Regelversorgung (LPPR & LATM):

• HAS „Principes d’évaluation / DM pathway“ (2010 Guide): Überblick über Akteure und Erstattungswege rund um Medizinprodukte in Frankreich (v. a. MDR-Kontext/Marktüberwachung).
• LPPR/AMELI-Datenbank: Öffentliches Erstattungsumfeld für Medizinprodukte und Telemonitoring-Leistungen, ohne eigenes DMD-Register.
• LPPR-Leitfaden (HAS): Offizieller Leitfaden zur Antragstellung und Bewertung für die Aufnahme von Medizinprodukten in die LPPR.
• LPPR-Finanzierung (G_NIUS): Übersicht, wie Erstattung und Preislogik innerhalb der LPPR praktisch funktionieren.
• LATM-Leitfaden (HAS): Offizieller Leitfaden zur Einreichung eines Dossiers für Telemonitoring-Leistungen im LATM-Pfad.
• LATM-Finanzierung (G_NIUS): Erklärung der Vergütungslogik im Telemonitoring, inkl. Rollen, Pauschalen und Abrechnungsprinzip.

13. DiGA-Modelle in anderen Ländern

Immer mehr Länder planen einen standardisierten Prozess, um digitale Gesundheitsanwendungen in die Regelversorgung zu bringen. Neben Frankreich sollten Sie außerdem einen Blick in die folgenden Länder werfen:

• Belgien (Link zum Leitfaden für die Zulassung von DiGA in Belgien)
• Österreich (DiGA in Österreich: Zulassung digitaler Gesundheitsanwendungen (2026))
• Deutschland (Insider-Tipps für die Zulassung von DiGA in Deutschland)
• Schweiz (Erstattung von Digitalen Gesundheitsanwendungen (DiGA & dGA))
• Italien (Kommen DiGA bald nach Italien?)
• Erstattung von DiGA in der EU (Überblick über Zulassung von DiGA in allen Ländern der EU)

Außerdem gibt es eine breite Palette von öffentlichen Förderungen (siehe unser Praxisleitfaden zu Digital Health-Förderungen) und anderen Erstattungswegen (siehe unser Whitepaper zu Selektivverträgen) für Health-Software.

14. Fazit: Das DMD-Framework als DiGA mit Zusätzen

PECAN ist seit 2023 ein klar definiertes Verfahren, das Frankreich erstmals einen strukturierten Weg für die vorläufige Erstattung digitaler Medizinprodukte gibt.

Gleichzeitig zeigt die bisherige Praxis, dass PECAN aktuell noch kein verlässlicher Marktzugangspfad ist. Transparenz ist begrenzt, ein eigenes Register fehlt und öffentlich nachvollziehbare Erfolgsbeispiele scheint es kaum zu geben. Außerdem bleibt der Übergang in die dauerhafte Erstattung eine hohe Hürde, insbesondere wenn klinischer Nutzen oder organisatorischer Mehrwert nicht indikationsspezifisch und kurzfristig belastbar belegt werden können. Auch erfolgreiche DiGA-Evidenz aus Deutschland lässt sich nicht automatisch auf PECAN übertragen, wie der Fall von HelloBetter zeigt.

Für Hersteller heißt das: PECAN ist derzeit eher ein anspruchsvolles Übergangsinstrument als ein stabiler Erstattungskanal. Wer PECAN ernsthaft verfolgt, sollte auf eine belastbare Studienplanung achten und eine Strategie, die von Beginn an auf die dauerhafte Erstattung nach dem PECAN ausgerichtet ist.

Sie wollen eine digitale Anwendung auf den französischen Markt bringen?

Falls Sie die Zulassung einer digitalen Anwendung in Frankreich oder Deutschland planen, kontaktieren Sie uns gern. QuickBird Medical ist auf die auftragsbasierte Entwicklung und Zulassung von digitalen Gesundheitsanwendungen und Software-Medizinprodukten spezialisiert. Wir entwickeln Ihre Anwendung, lassen diese als Medizinprodukt nach MDR zu und führen Sie Schritt für Schritt durch das PECAN-Verfahren.

Zum Kontaktformular

The post PECAN & DMD – Leitfaden für DiGA in Frankreich appeared first on QuickBird Medical.

Dieser Artikel klärt wichtige Fragen zum Verhältnis zwischen DiGA und Medizinprodukten:

• Muss eine DiGA ein Medizinprodukt sein?
• Welche Risikoklassen sind für DiGA erlaubt?
• Was ist der Zusammenhang zwischen DiGA-Status und MDR?
• Welche Zusatzanforderungen müssen DiGA erfüllen?
• Darf eine DiGA mit Hardware-Medizinprodukten kombiniert werden?

Der Artikel richtet sich an angehende DiGA-Hersteller und andere Fachkreise, die verstehen wollen, welche regulatorischen Anforderungen für digitale Gesundheitsanwendungen gelten. Wir bei QuickBird Medical waren bereits in die Entwicklung von über 15 DiGA auf Auftragsbasis involviert und geben in Fachartikeln unser Wissen weiter.

Inhaltsverzeichnis

• 1. Zusammenspiel: DiGA und Medizinprodukt
  • 1.1 Muss eine DiGA also ein Medizinprodukt sein?
  • 1.2 Was bedeutet das konkret für Hersteller?
  • 1.3 Wann ist meine Software ein Medizinprodukt?
  • 1.4 Wann ist Software kein Medizinprodukt?
• 2. Welche MDR-Medizinprodukt-Klassen sind für DiGA erlaubt?
  • 2.1 Erweiterung durch das Digital-Gesetz (DigiG)
  • 2.2 Wie bestimme ich die Medizinprodukt-Risikoklasse für meine DiGA?
• 3. Medizinprodukt vs. DiGA: Zusatzanforderungen für DiGA
  • 3.1 Anforderungen als Medizinprodukt (MDR)
  • 3.2 Zusatzanforderungen für DiGA (DiGAV)
  • 3.3 Weiterführende Informationen
• 4. Anbindung von medizinischen Geräten & Hardware an DiGA
  • 4.1 Erstattungsfähige vs. nicht erstattungsfähige Hardware
• 5. Unterschiede zwischen Medizinprodukt und DiGA
• 6. Fazit: Empfehlungen für Hersteller

1. Zusammenspiel: DiGA und Medizinprodukt

Mit dem Konzept der DiGA wurde ein strukturierter Pfad geschaffen, um patientenorientierte medizinische Software und Apps in die Erstattung der gesetzlichen Krankenversicherung in Deutschland zu bringen.

Voraussetzung dafür: Die Anwendung muss zunächst als Medizinprodukt nach der europäischen Medical Device Regulation (MDR) auf den Markt gebracht werden. Als Medizinprodukt gilt Software, die vom Hersteller für einen medizinischen Zweck bestimmt ist: etwa zur Diagnose, Therapie oder Überwachung von Krankheiten. Erst mit gültiger CE-Kennzeichnung kann ein Hersteller den DiGA-Antrag beim Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) stellen.

Zusätzlich zur Zulassung als Medizinprodukt, muss eine medizinische Anwendung aber auch eine breite Palette weiterer Anforderungen erfüllen, um in das DiGA-Verzeichnis aufgenommen zu werden.

Anforderungen von DiGA und Software-Medizinprodukten

1.1 Muss eine DiGA also ein Medizinprodukt sein?

Die Antwort ist eindeutig: Ja, jede DiGA muss ein Medizinprodukt sein.

Das ergibt sich direkt aus der gesetzlichen Definition. § 33a SGB V definiert DiGA als „Medizinprodukte niedriger Risikoklasse, deren Hauptfunktion wesentlich auf digitalen Technologien beruht“. Eine DiGA ist also keine Alternative zum Medizinprodukt, sondern eine spezielle Kategorie von Medizinprodukten mit zusätzlichen Anforderungen.

1.2 Was bedeutet das konkret für Hersteller?

Bevor ein Hersteller überhaupt einen Antrag auf Aufnahme in das DiGA-Verzeichnis beim BfArM stellen kann, muss das Konformitätsbewertungsverfahren nach MDR vollständig abgeschlossen sein. Die CE-Kennzeichnung ist dabei der Nachweis, dass das Produkt die grundlegenden Sicherheits- und Leistungsanforderungen erfüllt und in Europa in Verkehr gebracht werden darf.

Wichtig zu verstehen: Das BfArM prüft im DiGA-Verfahren nicht die MDR-Konformität selbst. Diese wird vorausgesetzt und durch die CE-Kennzeichnung belegt. Das BfArM prüft stattdessen die zusätzlichen Anforderungen der DiGAV, etwa den Nachweis positiver Versorgungseffekte, Datenschutz und Interoperabilität.

1.3 Wann ist meine Software ein Medizinprodukt?

Bevor also die Frage nach dem DiGA-Status relevant wird, müssen Hersteller zunächst klären, ob ihre Software überhaupt ein Medizinprodukt ist. Diese Entscheidung ist grundlegend für den gesamten regulatorischen Weg.

Ob eine Software als Medizinprodukt gilt, hängt primär von der medizinischen Zweckbestimmung ab, die der Hersteller festlegt. Software ist nur dann ein Medizinprodukt, wenn sie einen medizinischen Zweck verfolgt, also wenn sie wie bereits erwähnt entweder die Diagnose, Therapie oder Überwachung von Krankheiten unterstützt.

Die Abgrenzung ist nicht immer trivial. Eine App, die einfach nur Fitnessdaten trackt, ist in der Regel kein Medizinprodukt. Dieselbe App mit einer Funktion zur Erkennung von Herzrhythmusstörungen hingegen schon. Entscheidend ist, welchen Zweck der Hersteller für das Produkt deklariert und welche Funktionen tatsächlich angeboten werden.

1.4 Wann ist Software kein Medizinprodukt?

Nicht jede Gesundheits-App ist automatisch ein Medizinprodukt. Folgende Kategorien fallen z. B. in der Regel nicht unter die MDR:

• Reine Datenspeicherung oder -übertragung: Software, die Gesundheitsdaten nur speichert oder weiterleitet, ohne sie medizinisch zu verarbeiten oder zu interpretieren
• Administrative Funktionen: Terminplanung, Erinnerungsfunktionen ohne medizinischen Kontext, Praxisverwaltung
• Allgemeine Gesundheitsinformationen: Apps, die generische Informationen bereitstellen, ohne individuelle Empfehlungen zu geben
• Lifestyle- und Wellness-Anwendungen: Fitness-Tracker, Ernährungs-Apps oder Meditations-Apps ohne medizinischen Zweck

Unser ausführlicher Leitfaden „Ist Ihre Software ein Medizinprodukt?“ behandelt dieses Thema im Detail mit konkreten Entscheidungshilfen.

2. Welche MDR-Medizinprodukt-Klassen sind für DiGA erlaubt?

Nicht jedes Medizinprodukt kann eine DiGA werden. Der Gesetzgeber hat die DiGA-Fähigkeit auf bestimmte Risikoklassen beschränkt. Dies spiegelt die Idee wider, dass DiGA als niedrigschwelliges Versorgungsangebot mit entsprechend begrenztem Risikopotenzial konzipiert sind.

Die folgende Übersicht zeigt, welche Risikoklassen für DiGA zugelassen sind:

(Klicken zum Vergrößern)

Bei Medizinprodukten der Klasse I kann der Hersteller die Konformitätsbewertung selbst durchführen und die Konformitätserklärung ausstellen. Bei Klasse IIa und IIb ist hingegen die Einbeziehung einer Benannten Stelle erforderlich, die das Qualitätsmanagementsystem und die technische Dokumentation prüft.

2.1 Erweiterung durch das Digital-Gesetz (DigiG)

Eine wichtige Änderung trat mit dem Digital-Gesetz (DigiG) am 26. März 2024 in Kraft: Seitdem können auch Medizinprodukte der Risikoklasse IIb in das DiGA-Verzeichnis aufgenommen werden. Zuvor waren nur die Klassen I und IIa zugelassen.

Diese Erweiterung ermöglicht DiGA mit höherem Risikoprofil. Allerdings gelten für Klasse-IIb-DiGA besondere Anforderungen: Eine vorläufige Aufnahme zur Erprobung ist zum Beispiel nicht möglich. Hersteller müssen bereits bei Antragstellung die Ergebnisse einer Studie zum Nachweis eines medizinischen Nutzens vorlegen.

2.2 Wie bestimme ich die Medizinprodukt-Risikoklasse für meine DiGA?

Die korrekte Klassifizierung ist einer der ersten und wichtigsten Schritte bei der Entwicklung einer DiGA. Sie bestimmt nicht nur, ob eine Benannte Stelle einbezogen werden muss, sondern beeinflusst den gesamten regulatorischen Aufwand und die Kosten.

Die Klassifizierung von Software-Medizinprodukten erfolgt nach den Regeln in Anhang VIII der MDR. Für Software ist dabei Regel 11 besonders relevant. Diese Regel klassifiziert Software u. a. anhand des Risikos, das von den bereitgestellten Informationen für den Patienten ausgeht.

Die Klassifizierung hängt von mehreren Faktoren ab: der Art der Erkrankung (schwerwiegend vs. nicht-schwerwiegend), der Art der Entscheidungsunterstützung (Diagnose, Therapie, Überwachung) und der Reversibilität möglicher Schäden durch falsche Informationen.

Unser Artikel Klassifizierung von Software-Medizinprodukten erläutert die Klassifizierungsregeln im Detail mit praktischen Beispielen.

Praxistipp: Befassen Sie sich frühzeitig mit der Klassifizierung – idealerweise bereits in der Konzeptionsphase. Die Risikoklasse bestimmt den regulatorischen Aufwand, die Kosten und den Zeitrahmen bis zur Markteinführung maßgeblich.

3. Medizinprodukt vs. DiGA: Zusatzanforderungen für DiGA

Eine DiGA muss zwei regulatorische Ebenen erfüllen: zunächst die MDR-Anforderungen als Medizinprodukt und darüber hinaus die spezifischen Anforderungen der DiGA-Verordnung (DIGAV). Dieser Abschnitt gibt einen Überblick über beide Ebenen und zeigt, welche zusätzlichen Hürden DiGA-Hersteller im Vergleich zu „normalen“ Medizinprodukte-Herstellern nehmen müssen.

3.1 Anforderungen als Medizinprodukt (MDR)

Jede DiGA muss zunächst die grundlegenden MDR-Anforderungen erfüllen. Diese bilden das Fundament, auf dem die DiGA-spezifischen Anforderungen aufbauen. Die MDR verlangt ein umfassendes Qualitäts- und Dokumentationssystem.

Zu den zentralen Anforderungen gehören:

• Qualitätsmanagementsystem nach ISO 13485, das alle qualitätsrelevanten Prozesse dokumentiert und steuert
• Risikomanagement nach ISO 14971, das potenzielle Gefährdungen identifiziert und Maßnahmen zur Risikominimierung definiert
• Software-Lebenszyklus nach IEC 62304, der die Entwicklung und den Betrieb von Software strukturiert
• Gebrauchstauglichkeit nach IEC 62366-1, die sicherstellt, dass das Produkt sicher und effektiv bedient werden kann
• Klinische Bewertung, die den klinischen Nutzen und die Sicherheit des Produkts belegt
• Post-Market-Surveillance, die das Produkt nach dem Inverkehrbringen kontinuierlich überwacht

Diese Anforderungen gelten für alle Medizinprodukte. Dies ist unabhängig davon, ob sie zusätzlich als DiGA in die Erstattung gebracht werden sollen.

Unser Artikel Zulassung & Zertifizierung von Software-Medizinprodukten behandelt die MDR-Anforderungen ausführlich.

3.2 Zusatzanforderungen für DiGA (DiGAV)

Über die MDR-Medizinprodukt-Anforderungen hinaus definiert die DiGAV spezifische Kriterien, die eine DiGA erfüllen muss. Diese Anforderungen werden vom BfArM im Rahmen des Fast-Track-Verfahrens geprüft.

3.2.1 Positive Versorgungseffekte (pVE)

DiGA müssen einen positiven Versorgungseffekt nachweisen. Dieser kann entweder ein medizinischer Nutzen sein (z. B. Verbesserung des Gesundheitszustands) oder eine patientenrelevante Struktur- und Verfahrensverbesserung (z. B. bessere Therapieadhärenz, vereinfachter Zugang zur Versorgung).

Für die dauerhafte Aufnahme ins DiGA-Verzeichnis ist eine vergleichende Studie erforderlich, die den positiven Versorgungseffekt belegt. Bei vorläufiger Aufnahme erhält der Hersteller einen Erprobungszeitraum von bis zu 12 Monaten (in begründeten Ausnahmen bis zu 24 Monate), um diesen Nachweis zu erbringen. Auch für eine Aufnahme auf Erprobung muss aber ein umfangreiches Evaluationskonzept inklusive Pilotstudie vorgelegt werden.

Mehr dazu: Positive Versorgungseffekte nachweisen

3.2.2 Datenschutz

Die DiGAV stellt über die DSGVO hinaus besonders strenge Anforderungen an den Datenschutz. Es sind nur bestimmte, abschließend definierte Zwecke der Datenverarbeitung zulässig. Für die Verarbeitung von Gesundheitsdaten außerhalb Deutschlands gelten besondere Regelungen. Transparenz über Art und Umfang der Datenverarbeitung ist Pflicht.

Mehr dazu: DiGA Datenschutz-Anforderungen

3.2.3 Datensicherheit

Ein Informationssicherheitsmanagementsystem (ISMS) ist für DiGA-Hersteller verpflichtend und muss sogar nach ISO 27001 zertifiziert werden.

Zusätzlich müssen DiGA-Hersteller eine Zertifizierung nach BSI TR-03161 erlangen. Dies ist eine sehr anspruchsvolle Zertifizierung für die Informationssicherheit, die durch Prüfstellen und abschließend das BSI (Bundesamt für Sicherheit in der Informationstechnik) vergeben wird.

Mehr dazu: BSI TR-03161 für DiGA

3.2.4 Interoperabilität

DiGA müssen interoperable Standards nutzen, damit Gesundheitsdaten zwischen verschiedenen Systemen ausgetauscht werden können. Konkret bedeutet das: Die Möglichkeit, DiGA-Daten im menschenlesbaren und maschinenlesbaren Format exportieren zu können (durch Nutzung von FHIR-Profilen und dem MIO DiGA Toolkit) sowie die Anbindung an die elektronische Patientenakte (ePA).

Mehr dazu: Interoperabilität für DiGA

3.2.5 Qualitätsanforderungen

Die DiGAV definiert weitere Qualitätsanforderungen in verschiedenen Bereichen:

• Robustheit: Die DiGA muss stabil funktionieren und fehlertolerant sein
• Verbraucherschutz: Transparente Information, keine irreführende Werbung, Einhaltung des Heilmittelwerbegesetzes
• Nutzerfreundlichkeit: Barrierefreie Gestaltung, intuitive Bedienung
• Unterstützung der Leistungserbringenden: Sinnvolle Integration in bestehende Versorgungsprozesse
• Qualität medizinischer Inhalte: Evidenzbasierung, Aktualität, fachliche Korrektheit
• Patientensicherheit: Risikominimierende Maßnahmen, angemessene Warnhinweise

3.2.6 Anwendungsbegleitende Erfolgsmessung (AbEM)

Nach der Aufnahme in das DiGA-Verzeichnis müssen Sie kontinuierlich Daten zur Nutzung und Wirksamkeit ihrer DiGA erheben. Die anwendungsbegleitende Erfolgsmessung umfasst Nutzungsdaten, Patientenzufriedenheit (PGI-C-Skala) und perspektivisch indikationsspezifische PROMs. Diese Daten müssen regelmäßig an das BfArM berichtet werden.

3.3 Weiterführende Informationen

Mehr Informationen, welche Kriterien Sie einhalten müssen, um eine DiGA zu sein, finden Sie auch hier: DiGA Definition & Kriterien

4. Anbindung von medizinischen Geräten & Hardware an DiGA

Eine häufige Frage von Herstellern betrifft die Kombination von DiGA mit Hardware: Kann eine DiGA auch Sensoren, Wearables oder andere Medizingeräte einbinden? Die Antwort ist differenziert. Grundsätzlich ja, aber unter bestimmten Bedingungen.

DiGA sind primär Software-Medizinprodukte. Ihre Hauptfunktion muss wesentlich auf digitalen Technologien beruhen. Sie können jedoch mit Hardware-Medizinprodukten und anderen Systemen kommunizieren, Daten austauschen und diese verarbeiten – solange die digitale Hauptfunktion überwiegt.

4.1 Erstattungsfähige vs. nicht erstattungsfähige Hardware

Ein wichtiger Aspekt für Hersteller ist die Frage der Erstattungsfähigkeit. Nicht jede Hardware, die mit einer DiGA kombiniert wird, wird auch von der GKV erstattet.

Die folgende Übersicht zeigt exemplarische Beispiele, welche Hardware-Typen potenziell erstattet werden und welche nicht:

(Klicken zum Vergrößern)

Grundregel: Erstattungsfähig sind spezialisierte medizinische Geräte, die keine Gegenstände des täglichen Lebens darstellen. Gebrauchsgegenstände des täglichen Lebens, auch wenn sie medizinische Funktionen haben, werden nicht von der GKV bezahlt, können aber mit einer DiGA verwendet werden.

5. Unterschiede zwischen Medizinprodukt und DiGA

Nachdem wir die einzelnen Aspekte im Detail betrachtet haben, fassen wir einige wesentliche Unterschiede zwischen einem „normalen“ Medizinprodukt und einer DiGA zusammen.

(Klicken zum Vergrößern)

Diese Liste könnte noch sehr stark ausgeweitet werden und dient nur dem grundlegenden Verständnis.

6. Fazit: Empfehlungen für Hersteller

Der Weg zur DiGA führt immer über das Medizinprodukt. Wer eine digitale Gesundheitsanwendung entwickelt und in die GKV-Erstattung bringen möchte, muss beide regulatorischen Ebenen von Anfang an mitdenken.

Unsere Empfehlungen für Hersteller:

• Frühzeitig die regulatorische Strategie festlegen: Klären Sie zu Beginn, ob Ihr Produkt ein Medizinprodukt ist und ob der DiGA-Weg sinnvoll ist. Nicht jedes Medizinprodukt muss eine DiGA werden.
• MDR-Konformität als Basis sicherstellen: Ohne CE-Kennzeichnung keine DiGA. Planen Sie ausreichend Zeit für die Konformitätsbewertung ein. Das gilt insbesondere bei Klasse IIa und IIb, wo Benannte Stellen einbezogen werden müssen.
• DiGAV-Anforderungen parallel planen: Datenschutz, Datensicherheit und Interoperabilität sollten von Beginn an in die Produktentwicklung einfließen. Nachträgliche Anpassungen sind aufwendig und teuer.
• Studienplanung für den pVE-Nachweis frühzeitig starten: Insbesondere wenn Sie eine dauerhafte Aufnahme anstreben, beginnen Sie früh mit der Konzeption der Nachweisstudie.
• Beratung beim BfArM nutzen: Das BfArM bietet kostenpflichtige Beratungsgespräche an. Diese Investition lohnt sich, um Unsicherheiten im Vorfeld zu klären.

Sie planen eine DiGA? Wir entwickeln digitale Gesundheitsanwendungen im Auftrag für Unternehmen: von der Konzeption über die MDR-Zulassung bis zur Aufnahme ins DiGA-Verzeichnis. Wir übernehmen alle Schritte bis zur erfolgreichen Erstattung und danach.

Mehr Informationen zum Service zur DiGA-Entwicklung

The post DiGA als Medizinprodukt (MDR): Anforderungen & Unterschiede appeared first on QuickBird Medical.

• Aber ist die KI-Verordnung für mein Medizinprodukt überhaupt relevant?
• Welche zusätzlichen Anforderungen müssen speziell Medizinprodukt-Hersteller umsetzen?
• Und wie schaffe ich es, diese in mein bestehendes Qualitätsmanagementsystem zu integrieren?

Diese und weitere Fragen beantworten wir in diesem umfangreichen Leitfaden zum EU-AI Act. Wir fokussieren uns hierbei komplett auf die Auswirkungen der KI-Verordnung auf MDR-Medizinprodukte.

Inhalte des Leitfadens zur KI-Verordnung

• 1. Was ist der AI Act? (Stand 2026)
• 2. Ist der AI Act für mein Produkt relevant?
• 3. Die 3 Produktkategorien des AI Act
  • 3.1 Produktkategorie 1: Verbotene KI Praktiken
  • 3.2 Produktkategorie 2: Hochrisiko-KI-Systeme
  • 3.3 Produktkategorie 3: Andere KI-Systeme (mit geringem Risiko)
  • 3.4 Zusatzkategorie: KI-Modelle mit allgemeinem Verwendungszweck
• 4. Anforderungen an Hochrisiko-KI-Systeme
  • 4.1 Anforderungen an Ihr Qualitätsmanagementsystem
  • 4.2 Anforderungen an die technische Dokumentation
  • 4.3 Anforderungen an das Produkt
• 5. Wie beeinflusst der AI Act die Zulassung meines Medizinprodukts?
  • 5.1 Risikoklasse I
  • 5.2 Risikoklasse IIa oder höher
• 6. Ab wann gilt der AI Act? Umsetzungs-Timeline
• 7. Fazit

1. Was ist der EU AI Act?

Der AI Act ist eine neue Verordnung, welche die Entwicklung und den Einsatz von künstlicher Intelligenz (KI, oder AI für Artificial Intelligence) in der EU regeln soll. Sie ist nicht auf Medizinprodukte beschränkt, sondern adressiert grundsätzlich jegliche Produkte, die unter die Definition eines KI-Systems fallen (siehe nächstes Kapitel “Ist der AI Act für mein Produkt relevant?”). Das übergeordnete Ziel der KI-Verordnung ist es, die Sicherheit und Grundrechte von Personen zu wahren. Die gesamte Verordnung finden Sie auf der Webseite der Webseite der Europäischen Union.

2. Ist der AI Act für mein Produkt relevant?

Der AI Act definiert KI-Systeme folgendermaßen:

Für die Zwecke dieser Verordnung bezeichnet der Ausdruck „KI-System“ ein maschinengestütztes System, das für einen in unterschiedlichem Grade autonomen Betrieb ausgelegt ist und das nach seiner Betriebsaufnahme anpassungsfähig sein kann und das aus den erhaltenen Eingaben für explizite oder implizite Ziele ableitet, wie Ausgaben wie etwa Vorhersagen, Inhalte, Empfehlungen oder Entscheidungen erstellt werden, die physische oder virtuelle Umgebungen beeinflussen können;

Zusammengefasst ist ein KI-System demnach eine Software, die aus den erhaltenen Inputs ableitet, wie ein bestimmter Output erzeugt werden kann. Zudem kann das System (aber muss nicht) autonom arbeiten und laufend weiterlernen. Unterm Strich ist damit zwar noch nicht 100% klar, welche Systeme davon genau exkludiert sind, aber da die meisten Produkte mit KI unter Machine Learning fallen, sind sie sehr eindeutig von dieser Definition erfasst.

Die MDCG hat ein Dokument veröffentlicht, welches das Zusammenspiel zwischen der MDR und dem AI Act verdeutlicht: MDCG 2025-6. Dieses Dokument ist speziell für Hersteller von Software-Medizinprodukten interessant. Dort werden Produkte, die sowohl der MDR, als auch dem AI Act unterliegen, als „Medical Device Artificial Intelligence (MDAI)“ definiert.

3. Die 3 Produktkategorien des AI Act

Gelten für alle KI-Medizinprodukte (MDAI) dieselben Anforderungen? Die kurze Antwort lautet: Nein. Ähnlich wie die MDR unterteilt auch der EU AI Act Produkte in verschiedene Klassen:

1. Verbotene KI Praktiken
2. Hochrisiko-KI-Systeme
3. Andere KI-Systeme (mit geringem Risiko)

In welche Klasse fällt mein KI- bzw. Software-Medizinprodukt? Und was hat das für mich als Hersteller zu bedeuten?

Entscheidungsbaum: In welche KI-Risikoklasse fällt mein KI- bzw Software-Mizinprodukt (MDAI)?

3.1 Produktkategorie 1: Verbotene KI-Praktiken

Auf das Wesentliche reduziert lässt sich sagen, dass vor allem solche Praktiken verboten sind, die zum Ziel haben, Personen zu schaden – und zwar durch unterschwellige Beeinflussung oder das Ausnutzen bestimmter Schwächen oder Schutzbedürftigkeiten (z.B. Behinderungen, Alter). Artikel 5 der KI-Verordnung listet noch eine Reihe weiterer verbotener Praktiken, die aber in der Regel für Medizinprodukte nicht relevant sind.

Fällt mein Medizinprodukt in diese Kategorie? Das Ziel, Personen zu schaden, widerspricht üblicherweise den Zielen eines Medizinprodukts, weshalb Sie grundsätzlich davon ausgehen können, dass Ihre KI nicht in die Kategorie der “verbotenen Praktiken” fällt. Dennoch sollten Sie sich die Kriterien in Artikel 5 genau ansehen, um sicherzugehen.

Welche Anforderungen muss ich bei „Verbotenen KI-Praktiken“ beachten? Das Produkt darf nicht auf den Markt gebracht werden.

3.2 Produktkategorie 2: Hochrisiko-KI-Systeme

In diese Kategorie fallen Produkte, die ein hohes Risiko für die Gesundheit und Sicherheit, oder die Grundrechte natürlicher Personen darstellen.

Fällt mein Medizinprodukt in diese Kategorie? Vor allem bei den Begriffen “Gesundheit” und “Sicherheit” liegt der Gedanke an “Medizinprodukte” nicht mehr fern, zumal auch die MDR einen starken Fokus auf die Sicherheit, der von ihr geregelten Produkte legt.

Gemäß MDCG 2025-6 ist ein Medizinprodukt dann ein Hochrisiko-KI-System, wenn folgende Kriterien erfüllt sind:

1. Das KI-System ist selbst ein Medizinprodukt oder eine Sicherheitskomponente davon
2. Es ist eine benannte Stelle in die Konformitätsbewertung nach MDR eingebunden

Wenn in das Konformitätsbewertungsverfahren Ihres Produkts eine benannte Stelle involviert ist (z.B., weil es in Risikoklasse IIa oder höher fällt), ist Ihr Medizinprodukt automatisch ein Hochrisiko-KI-System gemäß KI-Verordnung (siehe Entscheidungsbaum in der Abbildung oben). Die benannte Stelle hat dann nicht nur die Anforderungen der MDR, sondern auch jene des AI Act im Zuge der Konformitätsbewertung zu prüfen. Wenn aber keine benannte Stelle bei der Zulassung Ihres Produkts involviert ist (z.B., weil das Produkt in Risikoklasse I nach MDR fällt, oder es sich gar nicht um ein Medizinprodukt handelt), müssen Sie vor allem Anhang III des AI Acts prüfen. Dieser enthält eine Liste von Systemen, die als Hochrisiko-KI-Systeme gelten. Die meisten Medizinprodukte werden sich aber nicht in dieser Liste finden lassen, weshalb wir davon ausgehen, dass viele Medizinprodukte der Risikoklasse I nach MDR keine Hochrisiko-KI-Systeme sind.

Diese Einschätzung bestätigt auch die MDCG 2025-6, in welcher die untenstehende Tabelle aufgeführt ist:

Einordnung von Hochrisiko-KI-Systemen nach MDR

Welche Anforderungen muss ich beachten? Wenn Ihr Produkt in die Kategorie der Hochrisiko-KI-Systeme fällt, hat die KI-Verordnung möglicherweise starke Auswirkungen auf Ihre Organisation und Ihr Medizinprodukt. Die Inhalte des EU AI Acts definieren nämlich speziell Anforderungen an die Hersteller solcher Systeme und die Systeme selbst. Einen Überblick über die Anforderungen geben wir Ihnen weiter unten im Kapitel “Anforderungen an Hochrisiko-KI-Systeme”.

3.3 Produktkategorie 3: Andere KI-Systeme (mit geringem Risiko)

Alle KI-Produkte, die weder den verbotenen KI-Praktiken noch den Hochrisiko-KI-Systemen zugeordnet werden können, fallen in diese Kategorie. Es handelt sich dabei grob gesagt um Systeme, von denen keine nennenswerten Risiken für die Sicherheit und Grundrechte von Personen ausgehen. Fällt mein Medizinprodukt in diese Kategorie? Wenn Ihr Produkt die folgenden Kriterien erfüllt, fällt es vermutlich in diese Kategorie:

1. Es handelt sich um ein Produkt der Risikoklasse I nach MDR (es ist keine benannte Stelle in die Konformitätsbewertung involviert)
2. Es wurde ausgeschlossen, dass es sich um ein Hochrisiko-KI-System handelt
3. Es wurde ausgeschlossen, dass es sich um verbotene KI-Praktiken handelt

Welche Anforderungen muss ich beachten? Im Vergleich zu Hochrisiko-KI-Systeme kommen Produkte in dieser Kategorie wirklich gut weg. Im Grunde findet sich im gesamten AI Act nur eine Anforderung an solche Systeme: Transparenzpflichten. Und diese gelten auch nur für solche Systeme, die mit Menschen interagieren, mediale Inhalte erzeugen, oder zur Emotionserkennung dienen. Grob gesagt müssen Hersteller solcher Produkte sicherstellen, dass Nutzer wissen, dass sie es mit KI zu tun haben, und dass es sich bei den erzeugten Inhalten um keine echten Bilder, Videos, etc. handelt (z.B. Deepfake). KI-Systeme dieser Kategorie müssen in keiner gesonderten Datenbank angemeldet werden und sie bedürfen keiner Konformitätserklärung. Wenn Ihr Medizinprodukt also in diese Kategorie fällt, sind die Aufwände für die Konformität mit dem AI Act für Sie vermutlich überschaubar.

3.4 Zusatzkategorie: KI-Modelle mit allgemeinem Verwendungszweck

Unabhängig von der Risiko-Einstufung können bestimmte KI-Modelle als „KI-Modell mit allgemeinem Verwendungszweck“ (Englisch: „General-purpose AI model“) gelten. Das sind Modelle, die für verschiedene Zwecke verwendet werden können.

Da der Zweck von Medizinprodukten aber meist sehr genau definiert ist, wird diese Kategorie in der Praxis nur für wenige Hersteller relevant sein. Der Vollständigkeit halber möchten wir sie an dieser Stelle aber trotzdem nennen.

Falls Sie ein KI-Modell entwickeln, das über die Anwendung in einem konkreten Produkt hinausgeht, sollten Sie sich mit dieser Kategorie näher beschäftigen.

Die genauen Anforderungen an solche Modelle sind in Kapitel V des AI Act definiert.

4. KI-Verordnung – Anforderungen an Hochrisiko-KI-Systeme und deren Hersteller

Die genauen Anforderungen an Hochrisiko-KI-Systeme und ihre Hersteller sind in Kapitel III Abschnitt 2 und Abschnitt 3 des AI Act spezifiziert. Wir gehen an dieser Stelle davon aus, dass Sie bereits die Anforderungen der MDR erfüllen. Somit gehen wir hier vor allem auf die Punkte ein, die über die Anforderungen der MDR hinausgehen. Erfahren Sie mehr über die Anforderungen der MDR an KI-Medizinprodukte in diesem Artikel: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)

Die KI-Verordnung definiert die Pflichten der Anbieter von Hochrisiko-KI-Systemen wie folgt (Artikel 16). Sie müssen …

a) sicherstellen, dass ihre Hochrisiko-KI-Systeme die in Abschnitt 2 festgelegten Anforderungen erfüllen;

b) auf dem Hochrisiko-KI-System oder, falls dies nicht möglich ist, auf seiner Verpackung oder in der beigefügten Dokumentation ihren Namen, ihren eingetragenen Handelsnamen bzw. ihre eingetragene Handelsmarke und ihre Kontaktanschrift angeben;

c) über ein Qualitätsmanagementsystem verfügen, das Artikel 17 entspricht;

d) die in Artikel 18 genannte Dokumentation aufbewahren;

e) die von ihren Hochrisiko-KI-Systemen automatisch erzeugten Protokolle gemäß Artikel 19 aufbewahren, wenn diese ihrer Kontrolle unterliegen;

f) sicherstellen, dass das Hochrisiko-KI-System dem betreffenden Konformitätsbewertungsverfahren gemäß Artikel 43 unterzogen wird, bevor es in Verkehr gebracht oder in Betrieb genommen wird;

g) eine EU-Konformitätserklärung gemäß Artikel 47 ausstellen;

h) die CE-Kennzeichnung an das Hochrisiko-KI-System oder, falls dies nicht möglich ist, auf seiner Verpackung oder in der beigefügten Dokumentation anbringen, um Konformität mit dieser Verordnung gemäß Artikel 48 anzuzeigen;

i) den in Artikel 49 Absatz 1 genannten Registrierungspflichten nachkommen;

j) die erforderlichen Korrekturmaßnahmen ergreifen und die gemäß Artikel 20 erforderlichen Informationen bereitstellen;

k) auf begründete Anfrage einer zuständigen nationalen Behörde nachweisen, dass das Hochrisiko-KI-System die Anforderungen in Abschnitt 2 erfüllt;

l) sicherstellen, dass das Hochrisiko-KI-System die Barrierefreiheitsanforderungen gemäß den Richtlinien (EU) 2016/2102 und (EU) 2019/882 erfüllt.

Keine Sorge, wir lassen Sie mit dieser Liste nicht allein. Im Folgenden wollen wir deshalb beleuchten, was das für Sie als Hersteller eines KI-Medizinprodukts bedeutet. Wir gehen dabei auf die wichtigsten Punkte ein, die zu einer Anpassung Ihres Managementsystems und/oder des Medizinprodukts führen.

Die Anforderungen des EU-AI Act und der MDR überschneiden sich in zahlreichen Punkten.

4.1 AI Act – Anforderungen an Ihr Qualitätsmanagementsystem

Ein Medizinprodukthersteller wird von der MDR bereits dazu verpflichtet, ein Qualitätsmanagementsystem zu etablieren. In den meisten Fällen wird dabei unter anderem die ISO 13485 und – wenn es um Software geht – die IEC 62304 umgesetzt. Auf den ersten Blick sieht es so aus, als hätten Sie damit auch die Anforderung des AI Acts erfüllt. Auf den zweiten Blick wird aber deutlich, dass dies nur teilweise stimmt. Aber keine Angst, der Großteil Ihres Systems kann bleiben, wie er ist. Sie müssen lediglich ein paar Anpassungen und Erweiterungen vornehmen. Die Anforderungen aus Artikel 17 des EU AI Acts finden Sie in der untenstehenden Tabelle aufgelistet. Zusätzlich zu den genauen Anforderungen der Verordnung haben wir die konkreten Maßnahmen für Sie definiert, die Sie umsetzen müssen, um die entsprechende Konformität Ihres Qualitätsmanagementsystems herzustellen. Das Qualitätsmanagementsystem muss mindestens die folgenden Aspekte umfassen:

(Hinweis: Unsere Kommentare sind nicht als absolute Wahrheiten zu verstehen, sondern sollen lediglich etwaige Gemeinsamkeiten und Unterschiede zwischen dem AI Act und Ihrem bestehenden System verdeutlichen. Prüfen Sie daher für jeden Punkt, inwiefern Sie Maßnahmen ergreifen müssen.)

4.1.1 Risikomanagement

Als Medizinprodukt-Hersteller verfügen Sie bereits über ein Risikomanagementsystem und sind ggf. von verschiedenen Gesetzen zu Risikomanagement-Aktivitäten verpflichtet (z.B. MDR, DSGVO). Die Anforderungen an das Risikomanagementsystem sind aber in MDR und AI Act nicht deckungsgleich! Die wohl fundamentalste Unterschied ist, dass Sie nicht nur Risiken in Bezug auf die Sicherheit, sondern auch auf die Grundrechte von Personen berücksichtigen müssen. Teilweise kann dies durch die Einhaltung anderer Verordnungen (z.B. DSGVO) zwar umgesetzt sein, neben der körperlichen Unversehrtheit und dem Schutz personenbezogener Daten können aber auch andere Rechte durch ein KI-System verletzt werden. Werfen Sie daher auf jeden Fall einen Blick in die Grundrechte-Charta der Europäischen Union. Zudem müssen Hochrisiko-KI-Systeme mit geeigneten Verfahren regelmäßig getestet werden (dies gilt vermutlich vor allem für kontinuierlich weiterlernende Systeme, die unter der MDR nur in Ausnahmefällen zulassungsfähig sind). Dieses Testen ist auch erforderlich, um die geeignetsten Risikomanagementmaßnahmen zu ermitteln. Die ermittelten Risiken sind dabei so weit wie „technisch möglich“ und bis zu einem „vertretbar beurteilbaren“ Grad gesenkt werden.

4.1.2 System zur Beobachtung nach dem Inverkehrbringen

Durch die MDR müssen Sie bereits die Post-Market Surveillance Ihres Medizinprodukts sicherstellen. Darauf wird in der KI-Verordnung auch explizit eingegangen. Wenn Sie nämlich bereits ein solches System nach MDR etabliert haben, müssen Sie prüfen, ob dieses auch die folgende Anforderung erfüllt: Das System muss es Ihnen ermöglichen, die Konformität des Produkts fortlaufend bewerten zu können.

4.1.3 System zur Meldung schwerwiegender Vorfälle und Fehlfunktionen

Durch Ihr bereits etabliertes Vigilanz-System nach MDR gibt es in diesem Bereich wenig umzusetzen. Der AI Act hat hier sogar eine Sonderregel für Medizinprodukte. Dadurch, dass bereits eine Verpflichtung zur Meldung sicherheitsrelevanter Vorfälle besteht, müssen Sie Ihr System lediglich um die Meldung von “Verstößen gegen die Bestimmungen des Unionsrechts zum Schutz der Grundrechte” erweitern.

4.1.4 Daten und Daten-Governance

Hier werden Sie als Hersteller dazu verpflichtet, geeignete Prozesse zu etablieren, welche Folgendes regeln:

• Konzeptionelle Entscheidungen (z.B. Wahl des Modelltyps, Festlegung relevanter Features)
• Datenerfassung (z.B. Datenquellen)
• Datenaufbereitungsvorgänge (z.B. Labelling, Bereinigung, Aggregierung)
• Aufstellung relevanter Annahmen (z.B. Beziehung zwischen Features, potenzielle Einflussfaktoren)
• Vorherige Bewertung der Verfügbarkeit, Menge und Eignung der benötigten Datensätze
• Untersuchung im Hinblick auf mögliche Verzerrungen/Bias und geeignete Maßnahmen zu derer Erkennung, Verhinderung und Abschwächung
• Ermittlung möglicher Datenlücken, Mängel und Maßnahmen, diese zu beheben

Grundsätzlich stellt dieses Kapitel auch konkrete Anforderungen an Ihre Trainings-, Validierungs- und Testdaten. Diese Anforderungen sollten Sie direkt in Ihre Prozesse integrieren. Tipp: Berücksichtigen Sie bei der Erstellung dieser Prozesse auch die Anforderungen an die technische Dokumentation in Anhang IV und Artikel 11 der KI-Verordnung. Dadurch stellen Sie sicher, dass Ihre Verfahren auch die notwendigen Outputs generieren.

4.1.5 Aufbewahrungspflichten

Wenn Sie die Aufbewahrungspflichten der MDR einhalten, erfüllen Sie vermutlich auch jene des AI Acts. Dort ist definiert, dass Sie Ihre Dokumentation für einen Zeitraum von 10 Jahren nach dem Inverkehrbringen des KI-Systems aufbewahren müssen. Zu dieser Dokumentation zählt laut Artikel 18 der KI-Verordnung die technische Dokumentation, das Qualitätsmanagementsystem, von benannten Stellen freigegebene Änderungen und ausgestellte Dokumente, sowie die Konformitätserklärung. Vom Produkt automatisch erzeugte Protokolle müssen 6 Monate lang aufbewahrt werden.

4.2 AI Act – Anforderungen an die technische Dokumentation

„Technische Dokumentation“ ist ein Begriff, der Ihnen sicherlich bereits aus der MDR bekannt ist. Eine technische Dokumentation müssen Sie für Ihr Medizinprodukt ohnehin erstellen. Tatsächlich gibt es auch hier viele Parallelen und Sie werden die meisten Punkte bereits durch die Einhaltung der MDR umgesetzt haben. Darunter zählen beispielsweise die Produktbeschreibung, eine Konformitätserklärung und die Methoden, die bei der Produktentwicklung angewandt wurden. Dies gilt aber nicht in jedem Fall! Besonders für Software-Systeme der Software-Sicherheitsklasse A nach IEC 62304 könnten sich in Bezug auf die technische Dokumentation einige Besonderheiten ergeben. Die KI-Verordnung verpflichtet Sie z.B. dazu, eine Systemarchitektur und die Definition von Schnittstellen zu anderen Systemen zu dokumentieren. Dies geht über die Anforderungen der IEC 62304 für Software-Systeme der Sicherheitsklasse A hinaus. Tipp: Pauschal kann man also nicht sagen, in welchem Umfang Ihre technische Dokumentation erweitert werden muss. Gehen Sie den Anhang IV des AI Acts also am besten durch und prüfen Sie für jeden Punkt, inwiefern Sie diesen durch Ihre aktuelle Dokumentation bereits umgesetzt haben. Alle noch fehlenden Informationen erstellen Sie im Anschluss idealerweise im Zuge der neu definierten bzw. angepassten Prozesse.

4.3 Anforderungen an das Produkt

4.3.1 Protokollierung und Logs

Hochrisiko-KI-Systeme sind zur Protokollierung verpflichtet. Es handelt sich hier also um eine klare technische Vorgabe. Diese Protokollierung muss, wie so oft im “der Zweckbestimmung angemessenen Maße” stattfinden. Was genau das heißt, wird in Artikel 12 der KI-Verordnung definiert. Demnach geht es vor allem um die Aufzeichnung von Ereignissen, die für folgendes relevant sind: a) die Ermittlung von Situationen, die dazu führen können, dass das Hochrisiko-KI-System ein Risiko im Sinne des Artikels 79 Absatz 1 birgt oder dass es zu einer wesentlichen Änderung kommt, b) die Erleichterung der Beobachtung nach dem Inverkehrbringen gemäß Artikel 72 und c) die Überwachung des Betriebs der Hochrisiko-KI-Systeme gemäß Artikel 26 Absatz 5. Im Kern geht es also darum, Situationen, die mit Risiken und Schäden verbunden sind möglichst gut zu überwachen und rückverfolgen zu können. Bei der Umsetzung dieser Protokollierung müssen sich Hersteller an anerkannte Standards und Spezifikationen halten (z.B. Anforderungen des BSI).

4.3.2 Transparenz und Bereitstellung von Informationen für die Nutzer

Wenn Sie noch keine Gebrauchsanweisungen für Ihr Medizinprodukt haben, brauchen Sie spätestens jetzt eine. Sollten Sie bereits eine Gebrauchsanweisung haben, müssen Sie diese vermutlich überarbeiten. Auch wenn es einige Anforderungen gibt, die auch schon von der MDR gestellt werden, fordert der AI Act nun auch Informationen zu z.B. Cyber Security und Risiken für die Grundrechte. Hier müssen auch Genauigkeitsgrade und relevante Genauigkeitskennzahlen des Systems angegeben werden. Prüfen Sie also für Ihre aktuelle Gebrauchsanweisung, inwiefern Sie die Pflichten des AI Acts bereits erfüllen und machen Sie anschließend die notwendigen Anpassungen.

4.3.3 Menschliche Aufsicht

Die Pflicht zur menschlichen Aufsicht ist eine verpflichtende Risikokontrollmaßnahme für Hochrisiko-KI-Systeme. Das System muss so konzipiert und entwickelt werden, dass es von einem Menschen wirksam beaufsichtigt werden kann. Hier lassen sich einige Parallelen zu den Transparenzanforderungen erkennen. Im Grunde muss es einem Nutzer möglich sein, die Vorgänge im Produkt, sowie dessen Ausgaben zu verstehen. Zudem muss er in der Lage sein, das System abzuschalten oder in den Betrieb einzugreifen. Die Möglichkeit zur Aufsicht kann dabei entweder direkt in die Software eingebaut werden, oder auch an den Nutzer abgegeben werden. Grob zusammengefasst muss es schlichtweg möglich sein, Anomalien oder Fehlverhalten zu erkennen und das System im Zweifelsfall stoppen zu können.

4.3.4 Genauigkeit, Robustheit und Cybersicherheit

Hochrisiko-KI-Systeme müssen widerstandsfähig gegenüber Fehlern, Störungen oder Unstimmigkeiten sein, die innerhalb des Systems oder der Umgebung, in der das System betrieben wird, insbesondere wegen seiner Interaktion mit natürlichen Personen oder anderen Systemen auftreten können. Die Robustheit von Hochrisiko-KI-Systemen kann durch technische Redundanz erreicht werden, was auch Sicherungs- oder Störungssicherheitspläne umfassen kann. Hochrisiko-KI-Systeme, die nach dem Inverkehrbringen (oder der Inbetriebnahme) kontinuierlich weiterlernen, sind so zu entwickeln, dass auf möglicherweise verzerrte Ergebnisse mit geeigneten Risikominderungsmaßnahmen eingegangen wird. Hochrisiko-KI-Systeme müssen widerstandsfähig gegen Versuche unbefugter Dritter sein, ihre Verwendung oder Leistung durch Ausnutzung von Systemschwachstellen zu verändern. Die technischen Lösungen zur Gewährleistung der Cybersicherheit von Hochrisiko-KI-Systemen müssen den jeweiligen Umständen und Risiken angemessen sein. Die technischen Lösungen für den Umgang mit KI-spezifischen Schwachstellen umfassen gegebenenfalls Maßnahmen zur Verhütung und Kontrolle von Angriffen, mit denen versucht wird, den Trainingsdatensatz zu manipulieren („Datenvergiftung“), von Eingabedaten, die das Modell zu Fehlern verleiten sollen („feindliche Beispiele“), oder von Modellmängeln.

4.3.5 CE-Kennzeichnung

Eine CE-Kennzeichnung hat Ihr Medizinprodukt bereits, wenn Sie es konform im Rahmen der MDR zugelassen haben. Sie müssen nur noch die entsprechende Verordnung referenzieren, damit Nutzer nachvollziehen können, dass Ihr Produkt im Einklang mit den beiden Verordnungen (MDR und AI Act) entwickelt worden ist.

4.3.6 Registrierung des Produkts

Ähnlich wie EUDAMED für Medizinprodukte, wird es in Zukunft auch eine EU-Datenbank für Hochrisiko-KI-Systeme geben, in welcher Ihr Produkt registriert werden muss. Zum aktuellen Zeitpunkt ist eine solche aber noch nicht öffentlich zugänglich (Stand 20.01.2026).

5. Wie beeinflusst der AI Act die Zulassung meines Medizinprodukts?

Die Risikoklasse Ihres Medizinprodukts nach MDR hat Einfluss auf die Anwendbarkeit des AI Acts. Wie Sie die Risikoklasse nach MDR bestimmen, erfahren Sie in unserem Leitfaden zur Klassifizierung von Software-Medizinprodukten.

5.1 Risikoklasse I

Bei der Zulassung von Produkten der Risikoklasse I nach MDR ändert sich durch den AI Act nichts (bis auf die Anforderungen aus Kapitel 3.3) – solange das Produkt kein Hochrisiko-KI-System darstellt. Sollte dies aber der Fall sein, brauchen Sie für die Konformitätsbewertung in Zukunft eine benannte Stelle, welche die Konformität mit der KI-Verordnung prüft. Behalten Sie dies unbedingt im Hinterkopf, wenn Sie die Umsetzung eines Produkts der Risikoklasse I planen, da es den Markteintritt maßgeblich verzögern kann.

Achtung: Es gelten Ausnahmen für Produkte der Risikoklasse Im, Is und Ir, bei denen eine benannte Stelle in die Konformitätsbewertung involviert ist. Diese sind bei reinen Software-Produkten allerdings eher selten.

5.2 Risikoklasse IIa oder höher

Produkte der Risikoklasse IIa oder höher sind im Grunde automatisch auch Hochrisiko-KI-Systeme gemäß dem AI Act. Somit sind einige Zusatzanforderungen umzusetzen, die weiter oben im Artikel bereits ausgeführt wurden. Bei der Zulassung (insbesondere der Konformitätsbewertung) müssen Sie in Zukunft unbedingt darauf achten, dass Ihre benannte Stelle auch unter der KI-Verordnung akkreditiert ist, oder eine solche Akkreditierung anstrebt. Diese muss im Zuge der Konformitätsbewertung dann nicht nur die Konformität mit der MDR, sondern auch mit dem AI Act prüfen.

Die Konformitätsbewertung wird dann voraussichtlich aber nicht für beide Verordnungen separat, sondern im Zuge einer integrierten Prüfung durchgeführt.

Nur, wenn das Produkt mit beiden Verordnungen konform ist, darf es das CE-Symbol tragen. Setzen Sie sich also schnellstmöglich mit Ihrer benannten Stelle in Verbindung und klären Sie, ob eine solche Akkreditierung für die KI-Verordnung geplant ist.

Die MDCG hat im Juni 2025 in diesem Zusammenhang ein Dokument veröffentlich, welches das Zusammenspiel zwischen MDR und AI Act beschreibt: MDCG 2025-6

6. Ab wann gilt der AI Act? Umsetzungs-Timeline

Der EU AI Act tritt nicht sofort komplett in Kraft, sondern erst über die Zeit. Die aktuelle Timeline sieht vor, dass der Großteil der Verordnung bis 2. August 2026 in Kraft getreten ist und sie ab dem 2. August 2027 dann vollständig gültig ist.

Das geht aus der Timeline der Europäischen Kommission hervor:

Umsetzungs-Zeitplan für den AI Act der Europäischen Kommission (Quelle: AI Act implementation timeline)

Zusammengefasst bedeutet dies für Hersteller von KI- bzw. Software-Medizinprodukten (MDAI):

1. Viele grundsätzliche Regeln des AI Act sind bereits heute gültig (z.B. Verbotene KI-Praktiken)
2. Ab August 2026 gilt fast der komplette AI Act, allerdings mit einer wichtigen Ausnahme: Artikel 6(1). Dieser beschreibt die Einstufungsregeln für Hochrisiko-KI-Systeme.
3. Hersteller von Hochrisiko-KI-Systemen haben somit bis August 2027 Zeit, alle Anforderungen an ihr Produkt und an sich selbst als Hersteller umzusetzen (außer, es ist ein System, welches in Anhang III genannt ist). Denn erst ab diesem Zeitpunkt gilt die Einstufung als Hochrisiko-KI-System.

7. Fazit

Der AI Act unterscheidet sich von der MDR zu allererst durch seine Zielsetzung. Während die MDR v.a. darauf abzielt, die Sicherheit und Funktionstauglichkeit von Medizinprodukten sicherzustellen, schließt die KI-Verordnung auch den Schutz der Grundrechte von Personen mit ein. Grundsätzlich lässt sich sagen, dass vor allem auf MDR-Medizinprodukte der Risikoklasse IIa oder höher viele neue Anforderungen zukommen. Diese werden nämlich automatisch der Kategorie “Hochrisiko-KI-Systeme” gemäß des AI Acts zugeordnet. Doch auch Medizinprodukte der Risikoklasse I können im Einzelfall in diese Kategorie fallen. Für Produkte, die keine Hochrisiko-KI-Systeme darstellen und nicht zu den “verbotenen Praktiken” zählen, bringt die KI-Verordnung wenig Änderungen. Hersteller von Hochrisiko-KI-Medizinprodukten müssen einer Reihe von Stellen Anpassungen vornehmen, um die Anforderungen des AI Act einzuhalten. Neben den Anforderungen des AI Acts, müssen Sie natürlich auch die Anforderungen der MDR beachten, welche in Bezug auf künstliche Intelligenz relevant sind.

Benötigen Sie Unterstützung bei der Entwicklung eines medizinischen KI-Systems? Wir entwickeln medizinische KI-Systeme für Unternehmen im Gesundheitswesen auf Auftragsbasis.

Unsere KI-Services: – Technischer Review von medizinischen KI-Systemen – Entwicklung von neuen Machine Learning-Modellen im Gesundheitsbereich – Individuelle Beratung bezüglich regulatorischer Compliance für Ihr geplantes KI-basiertes Produkt

Wir helfen Ihnen, auch die umfangreichen Anforderungen der MDR und des AI Act umzusetzen und ein erfolgreiches Produkt zu entwickeln.

Kontaktieren Sie uns 

The post AI Act: Leitfaden für Medizinprodukt-Hersteller nach MDR (2026) appeared first on QuickBird Medical.

“Μια DiGA πρέπει να πληροί ορισμένες απαιτήσεις διαλειτουργικότητας.” 

Verstehen Sie diesen Satz? Sofern Sie kein Griechisch sprechen, vermutlich nicht. Daher benötigen Sie eine deutsche Übersetzung. Das wäre Ihre Interoperabilitätsanforderung an diesen Blogartikel. Wenn wir diese Anforderung umsetzen, lautet der Satz wie folgt:

“Eine DiGA muss bestimmten Interoperabilitätsanforderungen genügen.”

Genauso wie dieser Blogartikel muss auch eine DiGA mit angrenzenden Systemen kompatibel sein und ihr Datenaustausch muss konkreten Regeln folgen: der strukturellen, syntaktischen, semantischen und organisatorischen Interoperabilität. Was es mit diesen Begriffen auf sich hat, erfahren Sie hier. Lesen Sie weiter und erhalten Sie einen praxisnahen Einblick in die Umsetzung von Interoperabilitätsanforderungen an eine DiGA.

Übersicht

• 1. Schnittstellen von DiGA zu anderen Systemen
  • 1.1 Welche Schnittstellen müssen interoperabel ausgestaltet werden?
  • 1.2 An welchen Schnittstellen ist eine interoperable Ausgestaltung optional?
• 2. Anbindung der elektronischen Patientenakte (ePA)
• 3. Digitale Identität/GesundheitsID 
• 4. Fazit

1. Schnittstellen von DiGA zu anderen Systemen

Je nach Einsatzzweck und Funktionsumfang einer DiGA kann diese Schnittstellen zu zahlreichen anderen Systemen aufweisen. Zum Beispiel könnte eine DiGA Daten aus Google Fit oder Apple Health einlesen, Daten zu einem Krankheitsbild an die elektronische Patientenakte (ePA) übergeben, oder eine behandelnde Ärztin zum Therapieverlauf eines Patienten informieren. Nicht jede Schnittstelle muss dabei interoperabel ausgestaltet werden (z.B. zu anderen Apps). Gesetzliche Vorgaben gibt es nur an drei Schnittstellen. Diese werden im folgenden Kapitel näher beschrieben.

Interoperabilität für DiGA
(Auszug aus dem DiGA Leitfaden – Version 3.6)

1.1 Welche Schnittstellen müssen interoperabel ausgestaltet werden?

Wenn man sich die Kernaufgabe einer DiGA vor Augen führt, die Versorgungsqualität für Patienten zu optimieren, lässt sich schnell begreifen, an welchen Schnittstellen Interoperabilität dabei besonders wichtig ist. Die DiGAV besagt genau, welche Schnittstellen interoperabel ausgestaltet werden müssen. Insbesondere die Anlage 2 zur DiGAV ist für die Umsetzung der Anforderungen von großer Bedeutung.

Notwendige Interfaces für DiGA

Zur Sicherstellung der Versorgung sind in erster Linie Ärzten, Psychotherapeuten und die Patienten selbst von großer Bedeutung. 

1. Ein Datenexport in menschenlesbarem, ausdruckbarem Format muss also möglich gemacht werden.

Doch nicht nur Menschen, sondern auch andere Systeme des Gesundheitswesens, wie z.B. die ePA müssen die Daten der DiGA sinnvoll verwenden können. 

2. Auch ein Datenexport in einem interoperablen Format muss ermöglicht werden. Die Übermittlung von Daten erfolgt gemäß einer Festlegung für die semantische und syntaktische Interoperabilität. Von Bedeutung ist dabei insbesondere das MIO DiGA-Toolkit der KBV, um Daten in die elektronische Patientenakte (ePA) übertragen zu können.

DiGA, die zum Beispiel auf die Daten von Sensoren und anderen Messgeräten angewiesen sind, müssen auch hier eine interoperable Schnittstelle schaffen, um Hardware-Herstellern eine Anbindung an die DiGA zu ermöglichen.

3. Daher ist auch eine interoperable Schnittstelle zu Wearables und anderen Medizingeräten verpflichtend, die von verschiedenen Herstellern verwendet werden können, um Daten bereitzustellen.

1.1.1 Datenexport in menschenlesbarem, ausdruckbarem Format

Patienten und ihre medizinischen Versorger müssen in der Lage sein, die versorgungsrelevanten Daten einer DiGA zu verstehen und weiterzuverwenden. Aus diesem Grund fordert die DiGAV an dieser Schnittstelle auch eine Möglichkeit, Daten in einem menschenlesbaren, ausdruckbaren Format zur Verfügung zu stellen. Dabei ist es wichtig, dass der Datenexport zwar über die DiGA selbst eingeleitet werden kann, nicht aber durch diese erfolgen muss.

Ein Button, der den Download eines verschlüsselten Datenpakets initiiert, welches später über einen Server abgerufen werden kann, wird hierbei auch als legitime Umsetzung angesehen. Ein Beispiel für einen Datenexport in menschenlesbarem, ausdruckbarem Format wäre die Erstellung einer PDF-Datei, welche alle Blutzuckermesswerte aus der DiGA und andere relevante Daten abbildet.

Der Referentenentwurf zur zweiten Änderung der DiGAV vom 28.10.2025 sieht für die Zukunft außerdem eine Übertragung von diesem menschenlesbaren Export in die elektronische Patientenakte vor.

QuickBird Medical Tipp: Stellen Sie die relevanten Daten in kompakter und verständlicher Form zur Verfügung. Überlegen Sie sich, welche Daten in einem Versorgungsszenario sinnvoll sind, in dem die DiGA zum Einsatz kommt. Welche Daten sind für Patienten und Ärzten von Bedeutung und wie können diese verständlich dargestellt werden?

Abseits der gesetzlichen Interoperabilitätsanforderungen an dieser Schnittstelle, können Sie sich hier einen maßgeblichen Wettbewerbsvorteil verschaffen. Wenn sich Ihre DiGA nämlich gut in den Alltag von Ärzten und Psychotherapeuten integrieren lässt und einen spürbaren Mehrwert liefert, wird diese auch häufiger verschrieben. Je kompatibler Ihre DiGA mit bestehenden Prozessen im Gesundheitswesen ist, desto besser.

1.1.2 Datenexport in interoperablem Format (ePA)

Nicht nur Menschen, sondern auch andere Systeme sind Teil des Gesundheitswesens und wollen die Daten Ihrer DiGA weiterverwenden. Allen voran ist hier die elektronische Patientenakte (ePA) zu nennen, welche Daten von der DiGA in einem interoperablen Format beziehen können muss. Um den Anforderungen der Interoperabilität im Gesundheitswesen gerecht zu werden, ist es sinnvoll, sich auf einheitliche Standards zu einigen, welche zum Datenaustausch verwendet werden. Diese Standards werden von Standardisierungsorganisationen definiert und legen Format und Semantik von Datenströmen fest. Eine Adaption eines Standards für ein bestimmtes Land oder Einsatzfeld nennt man Profil.

Aus genau diesem Grund gibt es konkrete Vorgaben, welche Formate zum Datenexport zulässig sind. Es reicht nicht einfach, dass Ihre DiGA bestimmte Daten zur Verfügung stellt, auch deren Format ist entscheidend. Als DiGA-Hersteller müssen Sie sich nun also auf die Suche nach einem geeigneten Datenformat machen, doch wo sollen Sie anfangen zu suchen?

1. Suchen Sie zuallererst für jedes Datenelement nach einem von der KBV definierten medizinischen Informationsobjekt (MIO) aus dem DiGA Toolkit. Dieses sollte in der Regel Ihren Anwendungsfall halbwegs passend abdecken können. Hierfür gibt es auch generischere MIO-Profile wie „Observation_Free“.
2. Falls es aber wirklich kein einigermaßen passendes MIO gibt, haben Sie noch zwei Möglichkeiten:

• • Sie können sich eines anderen existierenden offenen, international anerkannten Schnittstellen- oder Semantikstandards bedienen (z.B. HL7 FHIR).
  • Sie können ein eigenes Profil über einen oder mehreren existierenden offenen, international anerkannten Schnittstellen oder Semantikstandard definieren. Dieses Profil muss dann in einem anerkannten Verzeichnis (z.B. FHIR Registry) zur freien Nutzung veröffentlicht werden.

Medizinische Informationsobjekte (MIO) – DiGA Toolkit

Ein MIO ist ein von der KBV definiertes Datenformat für medizinische Informationen. Mit dem großen Ziel, einen optimalen Datenaustausch zwischen allen in der medizinischen Versorgung beteiligten Systeme zu gewährleisten, werden von Zeit zu Zeit neue MIOs für verschiedene Informationen entwickelt. Insbesondere die Schnittstelle zur ePA ist einer der Hauptgründe für die Einführung von MIOs.

Dass Hersteller einen veröffentlichten Interoperabilitäts-Standard verwenden, ist gut. Immerhin wird die Form des Datenaustauschs somit transparent. Noch besser ist es natürlich, wenn der gewählte Standard auch noch zum Standard der ePA oder anderen Systemen passt. Somit ist eine direkte Anbindung möglich.

Ein Beispiel für ein MIO ist der elektronische Impfpass. Seine Struktur ist genau festgelegt und gibt vor, dass neue Impfeinträge einem klaren Format entsprechen müssen, um diese in den Impfpass zu integrieren. Das MIO definiert, welche Informationen enthalten und in welchem Format diese vorliegen müssen.

Speziell für DiGA ist das DiGA Toolkit interessant, welches dafür entwickelt wurde, die Interoperabilitätsanforderungen an DiGA umzusetzen.

Welche Daten müssen für den interoperablen Datenexport berücksichtigt werden?

Theoretisch können unzählige verschiedene Daten aus einer App exportiert werden. Für den interoperablen Datenexport müssen allerdings nur jene Daten berücksichtigt werden, die auf dem bestimmungsgemäßen Gebrauch durch die Nutzer basieren (siehe § 4 Absatz 2 Satz 1 Ziffer 1 DiGAV). Daten des bestimmungsmäßigen Gebrauchs sind solche, die für Zwecke benötigt werden, die in unmittelbarem Zusammenhang mit der Erreichung des medizinischen Nutzens oder von patientenrelevanten Struktur- und Verfahrensverbesserungen stehen.

Konkreter betrifft dies potenziell folgende Daten:

• durch die Nutzer eingegebene Daten
• über Geräte und Sensoren erfasste Daten
• Daten zum Nutzer und zum Nutzungskontext (sofern verfügbar)
• Angaben zur DiGA und Metadaten zum Datenexport

Folgende Daten müssen nicht als eigenständige Objekte exportierbar sein:

• Ableitungen auf erfassten Daten, die ausschließlich zur Sicherstellung des sicheren Betriebs der DiGA dienen.
• Auf den Daten angelegte statistische Verfahren, welche nur zum Nachweis des positiven Versorgungseffekts gespeichert werden.

1.1.3 Schnittstelle zu Wearables & medizinischen Geräten

Diese Schnittstelle ist nicht bei allen DiGA vorhanden und somit nicht für alle Hersteller relevant. Wenn aber Medizingeräte oder andere Wearables an der Funktion der DiGA beteiligt sind, gilt es auch an dieser Schnittstelle, einen interoperablen Datenaustausch zu gewährleisten. Der Grund dafür ist ganz einfach: es muss dem Patienten/der Patientin selbst überlassen werden, welches Gerät er oder sie verwenden möchte. Dazu ist es notwendig, dass Hardware-Herstellern klar ist, in welchem Datenformat mit der DiGA kommuniziert wird. Nur so können Sie Geräte entwickeln, die auch mit der DiGA interagieren können.

Anforderungen an Hardwarehersteller

Zur Umsetzung der Interoperabilität an dieser Schnittstelle haben DiGA-Hersteller folgende Möglichkeiten:

• Nutzung eines offengelegten, dokumentierten Profils des ISO/IEEE 11073-Standards (Medical Device Communication)
• Suchen Sie ein durch die BluetoothSIG spezifiziertes Health Device Profil.
• Nutzung eines offenen, international anerkannten Standards (z. B. HL7 FHIR) oder entsprechender Profile
• Definition eines eigenen Profils auf Basis offener Standards. Dieses muss zur freien Nutzung in einem anerkannten Verzeichnis (z. B. FHIR Registry) veröffentlicht werden. Als nationale Referenz- und Orientierungshilfe dient der INA – Interoperabilitäts-Navigator der gematik.

QuickBird Medical Hinweis: Ihre DiGA darf zusätzlich zu einer interoperablen Schnittstelle auch nicht-interoperable Schnittstellen anbieten. Das kann zum Beispiel der Fall sein, wenn Sie ein Wearable einbinden müssen, welches keine Datenübertragung in einem entsprechenden Format anbietet. Sie dürfen die Schnittstelle zu diesem Gerät aufrechterhalten, müssen aber zudem auch eine interoperable Schnittstelle für andere Geräte schaffen.

Muss eine DiGA auch eine interoperable Schnittstelle zu Geräten anbieten, deren Daten über Apple Health oder Google Fit eingelesen werden? Nein, in diesem Fall muss Ihre DiGA keine interoperable Schnittstelle zum Gerät selbst anbieten.

Auch Hersteller von Hilfsmitteln und Implantaten werden in Zukunft in puncto Interoperabilität in die Pflicht genommen. Hilfsmittel und Implantate, welche Patientendaten an ein Backend des Herstellers oder eine Drittpartei senden, müssen ab 1. Juli 2027 eine interoperable Schnittstelle für DiGA anbieten. So soll es möglich werden, dass DiGA auf Daten aus verschiedenen Quellen zugreifen können. Mehr dazu lesen Sie hier: Guide zum § 374a SGB V – Interoperabilität für DiGA, Hilfsmittel & Implantate

1.2 An welchen Schnittstellen ist die interoperable Ausgestaltung optional?

DiGA können, müssen aber nicht zu allen angrenzenden Systemen eine interoperable Schnittstelle anbieten. Zum Beispiel kann eine DiGA Daten aus anderen Apps, wie Apple Health beziehen, ohne dazu eine interoperable Schnittstelle zu haben. Auch ein direkter Datenaustausch zwischen DiGA und anderen Medical Apps erfordert nicht zwangsläufig eine interoperable Schnittstelle. Sehen Sie sich dazu die Abbildung unter dem Kapitel „Schnittstellen von DiGA zu anderen Systemen“ an. Dort sehen Sie, welche Schnittstellen Ihrer DiGA nicht interoperabel ausgestaltet werden müssen.

2. Anbindung der elektronischen Patientenakte (ePA)

Die Anbindung der DiGA an die elektronische Patientenakte ist ein zentraler Bestandteil der Interoperabilitätsanforderungen. Ziel ist es, versorgungsrelevante Daten aus der DiGA strukturiert, standardisiert und für andere Systeme des Gesundheitswesens nutzbar zu machen.

DiGA müssen den Export von Daten in die ePA in einem interoperablen Format ermöglichen. Dabei sind sowohl eine manuelle Datenübermittlung durch die Versicherten als auch eine regelmäßige automatisierte Übertragung vorzusehen. Die automatisierte Übermittlung muss jederzeit deaktivierbar sein, sodass den NutzerInnen stets beide Optionen zur Verfügung stehen.

Die technische Umsetzung erfolgt auf Basis der von der Kassenärztlichen Bundesvereinigung definierten Medizinischen Informationsobjekte (MIO), insbesondere des DiGA Toolkits, welches die semantischen und syntaktischen Anforderungen für den Datenaustausch mit der ePA festlegt.

Der Nachweis der erfolgreichen ePA-Anbindung in der Referenzumgebung erfolgt im Rahmen eines Bestätigungsverfahrens der gematik und ist Voraussetzung für die formale Vollständigkeit eines Antrags auf Aufnahme in das DiGA-Verzeichnis beim BfArM. Das BfArM testet die Anbindung außerdem im Rahmen der inhaltlichen Prüfung des DiGA-Antrags.

Wir unterstützen Sie gerne bei der technischen Anbindung Ihrer DiGA an die ePA. Mehr Informationen zu diesem Service finden Sie hier.

3. Digitale Identität bzw. GesundheitsID

Um in die ePA zu schreiben und aus dieser zu lesen, muss eine DiGA außerdem die Authentisierung eines Users mit einer digitalen Identität (GesundheitsID) implementieren. Auch wenn diese Anforderung nicht formell unter das Thema „Interoperabilität“ fällt, stellt sie dennoch eine weitere erforderliche Schnittstelle zu anderen Systemen im Gesundheitswesen dar.

Über die GesundheitsID kann eine DiGA die Krankenversichertennummer des Patienten anfragen. Diese ist Voraussetzung für den Export in die ePA. Daher ist eine Übertragung von Daten in die ePA nur möglich, wenn der Patient seinen DiGA-Account mit der GesundheitsID verbunden hat. Außerdem muss der Patient innerhalb seiner ePA-App den Zugriff für die entsprechende DiGA explizit freigeben.

Wir unterstützen Sie gerne bei der Implementierung der GesundheitsID-Schnittstelle. Mehr Informationen zu diesem Service finden Sie hier.

4. Fazit

Interoperabilität in der DiGA-Entwicklung ist auf den ersten Blick ein undurchsichtiges Unterfangen. Wenn man sich genauer damit befasst, lassen sich aber drei zentrale Punkte ableiten:

• Ein Mensch muss die Daten einer DiGA verstehen können (menschenlesbar)
• Andere Systeme (insb. die ePA) müssen Daten einer DiGA verstehen können
• Hersteller von Sensoren und Messgeräten müssen wissen, in welchem Format der Datenaustausch mit der DiGA stattfindet

Bei der Suche nach geeigneten interoperablen Dateiformaten sind die ersten Anlaufstellen für Sie als Hersteller die MIOs der KBV und vor allem das DiGA Toolkit.

Benötigen Sie Hilfe bei der ePA-Anbindung oder GesundheitsID?

Als spezialisierter Dienstleister waren wir bereits in die Umsetzung von über 15 verschiedenen DiGA-Projekten involviert. Wir unterstützen Sie gerne bei der Implementierung aller Interoperabilitäts-Anforderungen (z.B. Anbindung an die ePA). Mehr Informationen zu unserem ePA & GesundheitsID-Service finden Sie hier.

Bei allen weiteren Fragen, kontaktieren Sie uns gern über unser Kontaktformular: Zum Kontaktformular

The post Interoperabilität für digitale Gesundheitsanwendungen (DiGA) appeared first on QuickBird Medical.

Die Informationen aus diesem Artikel stammen u.a. aus dem seit 28.02.2024 gültigen Rahmenbedingungen des GKV-Spitzenverbands.

Stand Januar 2026: Mit dem Digital-Gesetz (DigiG) wurde am 26.03.2024 abschließend festgelegt, dass der Anteil erfolgsabhängiger Preisbestandteile ab dem 01.01.2026 mindestens 20 % des Vergütungsbetrags betragen muss. Auch diese Änderung wird in Zukunft eine wichtige Rolle in Preisverhandlungen spielen. Wir gehen in Kapitel 4 im Detail auf diese Neuerung ein.

Inhaltsverzeichnis

• 1. Die Timeline der DiGA-Preisverhandlung
• 2. Wann gilt welcher Preis für die DiGA?
• 3. Die Preisverhandlung mit dem GKV-Spitzenverband
  • 3.1 Beginn der Verhandlungen
  • 3.2 Notwendige Unterlagen
  • 3.3 Dauer der Verhandlungen
  • 3.4 Wichtige Faktoren zur Ermittlung des Vergütungsbetrags
  • 3.5 Weitere Informationen zur Preisverhandlung
• 4. Anwendungsbegleitende Erfolgsmessung (AbEM) für DiGA
• 5. Weitere Fragen?

1. Die Timeline der DiGA-Preisverhandlung

Es macht einen Unterschied, ob Sie eine dauerhafte oder vorläufige Aufnahme für Ihre DiGA beantragen. Je nach Antrag beginnen die Verhandlungen früher oder später.

Wenn Ihre DiGA gleich dauerhaft aufgenommen wird (ohne Erprobungsjahr):

1. Der Verhandlungszeitraum beginnt, nachdem ihre DiGA 4 Monate im Verzeichnis gelistet ist.
2. Sie übermitteln dem GKV-Spitzenverband alle notwendigen Unterlagen.
3. Nach 5 weiteren Monaten ist die DiGA-Preisverhandlung abgeschlossen.
4. Falls es zu keiner Einigung kommt, entscheidet in weiteren 3 Monaten die Schiedsstelle über den Vergütungsbetrag.
5. Der verhandelte oder durch die Schiedsstelle festgelegte Vergütungsbetrag ist grundsätzlich ab dem 13. Monat nach Eintragung der DiGA im Verzeichnis als Vergütung anzusetzen. Bis dahin gilt der tatsächliche Herstellerpreis. Wird der Vergütungsbetrag erst später festgelegt, erfolgt eine rückwirkende Korrektur bzw. Rückzahlung ab dem 13. Monat.

Wenn Ihre DiGA zuerst vorläufig aufgenommen wird (mit Erprobungsjahr):

1. Spätestens zum Ende der Erprobungsphase (in der Regel 12 Monate; ggf. verlängert) übermitteln Sie dem BfArM die erforderlichen Nachweise zum positiven Versorgungseffekt.
2. Nach spätestens weiteren 3 Monaten erhalten Sie einen Bescheid des BfArM über die dauerhafte Aufnahme und der Verhandlungszeitraum beginnt.
3. Sie übermitteln dem GKV-Spitzenverband alle notwendigen Unterlagen und einigen sich auf Verhandlungstermine.
4. Nach weiteren 5 Monaten ist die DiGA-Preisverhandlung abgeschlossen. Falls es zu keiner Einigung kommt, entscheidet in weiteren 3 Monaten die Schiedsstelle über den Vergütungsbetrag.
5. Der verhandelte oder durch die Schiedsstelle festgelegte Vergütungsbetrag wird grundsätzlich ab dem 13. Monat nach (vorläufiger) Eintragung der DiGA im Verzeichnis vergütet. Bis zur Festlegung gilt der tatsächliche Herstellerpreis. Wird der Vergütungsbetrag erst später festgelegt, erfolgt eine rückwirkende Korrektur ab dem 13. Monat mit entsprechenden Ausgleichszahlungen.

2. Wann gilt welcher Preis für die DiGA?

Der tatsächliche Herstellerpreis gilt ab dem Tag der Eintragung ins DiGA-Verzeichnis bis zur geschlossenen Vergütungsvereinbarung.

• Er gilt 12 Monate (unabhängig davon, ob die DiGA zunächst vorläufig oder sofort dauerhaft aufgenommen wurde).
• Bereits im ersten Jahr können Höchstbeträge zu beachten sein.
• Der Hersteller kann den tatsächlichen Preis innerhalb dieser 12 Monate einmal ändern.

Ab dem 13. Monat wird grundsätzlich der verhandelte oder durch die Schiedsstelle festgelegte Vergütungsbetrag vergütet. Wird der Vergütungsbetrag erst später vereinbart oder festgesetzt, wirkt er rückwirkend ab dem 13. Monat. Daraus können Ausgleichszahlungen resultieren.

3. Die Preisverhandlung mit dem GKV-Spitzenverband

3.1 Beginn der Verhandlungen

Der Start der DiGA-Preisverhandlung mit dem GKV-Spitzenverband hängt davon ab, ob Ihre DiGA mit oder ohne Erprobungsjahr ins Verzeichnis aufgenommen wurde. Aus diesem Grund gibt es zwei Fälle:

3.1.1 Ihre DiGA ist von Anfang an dauerhaft gelistet

In diesem Fall beginnt die Preisverhandlung 4 Monate nach der Aufnahme ins DiGA-Verzeichnis.

Hinweis: Durch das Inkrafttreten des DVPMG am 09.06.2021 wurde der Beginn der Verhandlungen von 6 auf 4 Monate verkürzt.

3.1.2 Ihre DiGA ist vorläufig gelistet

Wenn Ihre DiGA erst vorläufig ins Verzeichnis aufgenommen wurde, beginnen die Preisverhandlungen erst, sobald ein Bescheid über die endgültige Aufnahme vorliegt. Bei einem regulären Erprobungsjahr (12 Monate) und einer Bearbeitungszeit von bis zu 3 Monaten liegt dieser Bescheid typischerweise bis zum 15. Monat vor. Bei einer verlängerten Erprobungsphase entsprechend später.

3.2 Notwendige Unterlagen

• Bescheid des BfArM zur Aufnahme ins DiGA-Verzeichnis
• CE-Konformitätskennzeichnung oder die CE-Kennzeichnung
• Erklärung zu allen in der DiGAV Anlage 1 und Anlage 2 genannten Punkten (wenn vorhanden auch entsprechende Zertifikate)
• Studienberichte zum Nachweis der positiven Versorgungseffekte (ggf. auch Publikationen)
• Zahl der bis zu 5 Tage vor der Übermittlung der Unterlagen eingelösten Freischaltcodes/Rezeptcodes
• Informationen zu Preisen für die DiGA bei Abgabe an Selbstzahler
• Informationen zu Preisen für die DiGA in anderen europäischen Ländern, die dort von Kostenträgern übernommen werden
• Bei DiGA, die vorläufig aufgenommen wurden: die festgelegten Nachweise zur Evaluation, welche Sie auch dem BfArM übermittelt haben

Sie können auch noch andere Unterlagen einreichen, die zur Verhandlung eines Vergütungsbetrags dienlich sind. Bis zu 10 Tage vor dem ersten bzw. zweiten Verhandlungstermin können Sie beispielsweise noch folgende Unterlagen nachreichen:

• Anwendungsbegleitende Auswertungen der DiGA
• Studien zu positiven Versorgungseffekten
• Auswertungen von Leistungs- und Abrechnungsdaten

3.3 Dauer der Verhandlungen

Die DiGA-Preisverhandlung mit dem GKV-Spitzenverband dauert 5 Monate. Innerhalb dieser fünf Monate finden 3 Verhandlungstermine im Umfang von maximal 3 Stunden statt. Es besteht die Möglichkeit, sich auf einen zusätzlichen vierten Termin zu einigen. 

Hinweis: Durch das Inkrafttreten des DVPMG am 09.06.2021 wurde der Verhandlungszeitraum von 6 auf 5 Monate verkürzt.

Sollte es zu keiner Einigung kommen, wird nach der Verhandlungsphase die Schiedsstelle eingeschaltet, welche alle Unterlagen prüft und nach spätestens 3 Monaten über einen Vergütungsbetrag entscheidet. Die Kosten für das Schiedsstellenverfahren werden zwischen DiGA-Hersteller und GKV-Spitzenverband aufgeteilt. 

3.4 Wichtige Faktoren zur Ermittlung des Vergütungsbetrags

Der Vergütungsbetrag ermittelt sich auf Basis aller preisrelevanten Unterlagen und der im Verzeichnis öffentlichen Informationen. Für Sie als Hersteller ist aber wichtig zu wissen, dass die Stärke des Versorgungseffekts eine besondere Rolle für die Höhe des Betrags spielt. Aussagekräftige Daten, Studien und Publikationen dürften Ihnen hier also die meisten Vorteile verschaffen.

Was Sie beim Nachweis positiver Versorgungseffekte beachten müssen, erfahren Sie hier: DiGA: Leitfaden zum Nachweis positiver Versorgungseffekte

Auch die Preise vergleichbarer DiGA und Anwendungen werden einen Einfluss auf Ihren Vergütungsbetrag haben. Erarbeiten Sie also auch Argumente, die den Mehrwert Ihrer DiGA gegenüber anderen Angeboten unterstreichen.

Womöglich limitiert wird der Vergütungsbetrag allerdings durch gruppenspezifische Höchstbeträge. 

3.5 Weitere Informationen zur Preisverhandlung

Die Informationen in diesem Artikel sind zugunsten der Leserlichkeit bewusst vereinfacht dargestellt. Für eine detaillierte, rechtssichere Einordnung der DiGA-Preisverhandlung sind insbesondere die folgenden Quellen maßgeblich:

• GKV-Spitzenverband – Rahmenvereinbarung nach § 134 Abs. 4 und 5 SGB V: Zentrale Rechtsgrundlage für Ablauf, Fristen, Verhandlungsmechanik, Vergütungs- und Höchstbeträge sowie Ausgleichsregelungen im Rahmen der DiGA-Preisverhandlung.
• Bundesinstitut für Arzneimittel und Medizinprodukte – DiGA-Leitfaden des BfArM: Erläutert die Anforderungen an die Aufnahme ins DiGA-Verzeichnis, die Erprobungsphase sowie den Nachweis positiver Versorgungseffekte als Grundlage für die dauerhafte Listung.

Diese Dokumente sind für die konkrete Auslegung und Anwendung der Regelungen stets heranzuziehen.

4. Anwendungsbegleitende Erfolgsmessung (AbEM) für DiGA

Mit dem Digital-Gesetz (DigiG) wurde die anwendungsbegleitende Erfolgsmessung (AbEM) als Bestandteil der DiGA-Vergütungssystematik in § 134 SGB V verankert.

Für Vergütungsvereinbarungen, die ab dem 1. Juli 2026 neu abgeschlossen oder durch die Schiedsstelle festgesetzt werden, ist ein erfolgsabhängiger Vergütungsanteil verpflichtend vorgesehen. Dieser muss mindestens 20 % des Vergütungsbetrags umfassen und auf einer anwendungsbegleitenden Erfolgsmessung basieren.

Die AbEM beschreibt die systematische Erhebung und Auswertung von Nutzungs- und Ergebnisdaten einer DiGA im Versorgungsalltag. Ziel ist es, den tatsächlichen Versorgungseffekt unter Realbedingungen nachvollziehbar abzubilden und als Grundlage für die Ausgestaltung und Bewertung erfolgsabhängiger Preisbestandteile heranzuziehen.

Die AbEM ersetzt nicht den Nachweis positiver Versorgungseffekte für die Aufnahme in das DiGA-Verzeichnis. Sie kann diesen jedoch im Rahmen der Preisverhandlung ergänzen und zur weiteren Bewertung von Nutzung, Wirksamkeit und patientenrelevanten Effekten beitragen.

Wie genau DiGA-Hersteller diese Erfolgsmessung implementieren werden und, ob der variable Anteil zu einer durchschnittlichen Erhöhung oder Minderung des Vergütungsbertrags führen wird, ist aktuell noch nicht klar. Wir informieren Sie in unserem DiGA-Newsletter, sobald hierzu Neuigkeiten bekannt werden.

5. Weitere Fragen?

Als Dienstleister für die Entwicklung von DiGA und Medical Software sind wir mit den aktuellen gesetzlichen Bestimmungen für DiGA sehr vertraut. Daher finden Sie in unserem Blog auch zahlreiche weitere Fachartikel zur DiGA-Entwicklung.

Sie planen die Entwicklung einer DiGA? Sprechen Sie uns gerne an: Zum Kontaktformular

The post DiGA-Preisverhandlung mit dem GKV-Spitzenverband appeared first on QuickBird Medical.

Es stellt sich eine zentrale Frage: Lohnt sich die Entwicklung Ihrer DiGA-Idee für Sie?

Diese Frage stellen sich auch potenzielle Investoren für Ihr DiGA-Vorhaben. Daher sollten Sie eine Kalkulation mit belastbaren Zahlen vorweisen können.

Besonders relevant sind hierbei folgende Kennzahlen:

• Gewinn
• Umsatz (Umsatzpotenzial & Marktpotenzial bzw. TAM, SAM, SOM)
• Kosten (Entwicklung, Studie, Vermarktung etc.)

Mit diesem Artikel geben wir Ihnen eine detaillierte Anleitung an die Hand, um das Potenzial Ihrer DiGA für Ihre angestrebte Krankheitsindikation zu berechnen. Sie finden außerdem eine Vielzahl von Beispielrechnungen, um die Thematik für Sie möglichst greifbar zu machen.

Inhalte dieses Artikels

• 1. Gewinn & Return on Investment (ROI) einer DiGA
  • 1.1 Umsatz & Marktpotenzial
  • 1.2 Preis bzw. Vergütungsbetrag
  • 1.3 Anzahl der Freischaltcode-Einlösungen
  • 1.4 Marktdurchdringungsrate
  • 1.5 Folgeverordnungen von DiGA
  • 1.6 Beispiel: Prognose des DiGA-Umsatzes für Adipositas
• 2. Kosten für die Entwicklung und Vermarktung einer DiGA
• 3. Download: Excel-Planner zur Prognose von Umsatz & Kosten Ihrer DiGA
• 4. Update 2026: Anwendungsbegleitenden Erfolgsmessung (AbEM) bei DiGA
• 5. Fazit

1. Gewinn & Return on Investment (ROI) einer DiGA

Wir fangen mit der Prämisse an, dass Ihr DiGA-Vorhaben das Ziel hat, profitabel zu sein. Um zu entscheiden, ob Ihr DiGA-Case profitabel sein kann, sollten Sie den zukünftigen Gewinn bzw. Return on Investment (ROI) abschätzen.

Auch die Berechnung des Gewinns einer DiGA entzieht sich dabei nicht den betriebswirtschaftlichen Grundprinzipien und folgt der simplen Formel:

Gewinn = Umsatz – Kosten

Der Return on Investment (ROI) wird wie folgt kalkuliert:

ROI = Gewinn/Kosten

Nun stellt sich natürlich die Frage: Wie konkret lassen sich „Umsatz“ und „Kosten“ prognostizieren? Auf diese Frage gehen wir in den folgenden Abschnitten im Detail ein.

1.1 Umsatz & Marktpotenzial

Der Umsatz entsteht, sobald Patienten die DiGA durch Einlösung eines Freischaltcodes nutzen. Mit jeder Einlösung erhalten Sie als Hersteller Geld von den Krankenkassen in Höhe des Preises Ihrer DiGA.

Den Freischaltcode erhalten Patienten von der Krankenkasse. Dies geschieht über zwei Wege:

1. Verschreibung durch Arzt: Der Arzt verschreibt die DiGA an den Patienten auf Basis einer gestellten Diagnose
2. Direktweg zur Krankenkasse: Der Patient beantragt einen Freischaltcode bei der Krankenkasse auf Basis einer bereits gestellten Diagnose

Wichtig: Sie erhalten nur Geld, wenn der Patient am Ende erfolgreich einen Freischaltcode erhält und auch in Ihrer DiGA einlöst.

Die Formel für den Umsatz einer DiGA ist demnach:
Umsatz = DiGA-Preis * Freischaltcode-Einlösungen

Weitere mögliche Umsatz-Quellen für DiGA (B2B-Kooperationen, Selbstzahlermodelle etc.) behandeln wir der Einfachheit halber nicht in diesem Artikel.

Beginnen wir mit dem DiGA-Preis: wie können Sie prognostizieren, was der DiGA-Preis für Ihr Indikationsgebiet sein wird?

1.2 Preis bzw. Vergütungsbetrag

Nach der vorläufigen Aufnahme einer DiGA gilt innerhalb des ersten Jahres ein vom Hersteller festgelegter Preis (in Ausnahmefällen verlängerbar auf 2 Jahre). Dieser Preis wird nach Ablauf des Erprobungszeitraums mit dauerhafter Aufnahme der DiGA neu verhandelt und erfahrungsgemäß stark verringert. Der anfängliche Hersteller-Preis ist daher für den langfristigen Erfolg einer DiGA irrelevant und im Rahmen dieser Kalkulation vernachlässigbar.

Der finale Preis bzw. der Vergütungsbetrag einer DiGA wird zwischen dem DiGA-Hersteller und dem GKV-Spitzenverband verhandelt.

Der durchschnittliche Vergütungsbetrag aller dauerhaft gelisteten DiGA beträgt etwa 221 Euro (Stand 2024). Wie in der folgenden Grafik sichtbar, weicht auch keine DiGA stark von diesem Durchschnittspreis ab. Der niedrigste Vergütungsbetrag liegt bei 189 € (Kalmeda) und der höchste Betrag bei 243 € (elevida).

Sie können also davon ausgehen, dass auch Ihre DiGA mit hoher Wahrscheinlichkeit mit einem Betrag innerhalb dieser Spanne vergütet werden wird. Die wichtigsten Informationen zur DiGA-Preisverhandlung mit dem GKV-Spitzenverband finden Sie in diesem Blogbeitrag.

Wichtig ist hierbei auch zu erwähnen, dass der Preis Ihrer DiGA bestimmte Höchstbeträge (mit wenigen Ausnahmen) nicht überschreiten darf: Höchstbeträge und Schwellenwerte.

Verhältnis: Vergütungsbeträge dauerhaft gelisteter DiGA vs. ursprüngliche Herstellerpreise
Quelle: Daten des GKV-Spitzenverbandes gem. § 33a Abs. 6 SGB V; Stand 30.09.2023

QuickBird Medical – Empfehlung
Wir empfehlen eher konservativ zu rechnen, um später keine böse Überraschung zu haben, wenn der Best-Case Ihrer Kalkulation doch nicht eintritt. Kalkulieren Sie Ihren Case mal mit 200 Euro, um zu sehen, ob sich Ihr Vorhaben auch mit diesem Preis lohnen würde.

1.3 Anzahl der Freischaltcode-Einlösungen

Um die zukünftige Anzahl an Verschreibungen bzw. Nutzern einer DiGA abschätzen zu können, lohnt es sich, einen genaueren Blick auf die Prävalenz (Anteil der erkrankten Personen an der Gesamtpopulation) einer bestimmten Indikation zu werfen. Wenn wir in diesem Beitrag von „Prävalenz“ sprechen, beziehen wir uns immer auf die „12-Monatsprävalenz“.

Die Prävalenz kann aus epidemiologischen Datenbanken oder Gesundheitsberichten wie dem Robert Koch-Institut oder Statistiken des Bundesgesundheitsministeriums gewonnen werden. Eine Google-Recherche ist hierfür ein guter Startpunkt.

Sobald Sie die Prävalenz(-Rate) bestimmt haben, multiplizieren Sie diese mit der Anzahl Gesetzlichversicherten in Deutschland. Wenn Sie dies mit dem prognostizierten Preis multiplizieren (siehe oben) erhalten Sie einen groben Schätzwert für das Marktpotenzial Ihrer DiGA.

Maximale-Freischaltcode-Einlösungen = Prävalenz-Rate x Anzahl-Gesetzlichversicherter

Vereinfachtes Beispiel für den Adipositas-DiGA-Gesamtmarkt
(exklusive Folgeverordnungen)

2022 lag die Prävalenz von Adipositas in Deutschland bei 19 %. Bei aktuell ca. 74 Millionen Versicherten ergibt sich Folgendes:

Maximale-Freischaltcode-Einlösungen = 0,19 x 74.000.000 = 14.060.000
(= ca. 14 Millionen Code-Einlösungen pro Jahr)

Weiter unten im Artikel gehen wir außerdem noch auf den Einfluss von Folgeverordnungen auf den Gesamtmarkt ein.

1.4 Marktdurchdringungsrate

Bisher haben wir das maximale Umsatzpotenzial einer DiGA berechnet. Es ist jedoch nicht realistisch, dass Sie jeden einzelnen Patienten in Deutschland mit Ihrer DiGA erreichen werden. Im nächsten Schritt sollten Sie daher noch die Marktdurchdringungsrate abschätzen. Das ist der Prozentsatz der Patienten, die sie planen auch realistisch gesehen zu erreichen.

Für die Abschätzung der Marktdurchdringungsrate müssen Sie eine Vielzahl von Faktoren berücksichtigen: haben Sie bereits Zugang zur Patientengruppe oder den Behandlern? Wenn ja, wie viele Personen können Sie so erreichen? Wie technisch affin ist Ihre Zielgruppe und wer benützt auch wirklich ein Smartphone? Wie stark ist die Konkurrenz anderer DiGA-Lösungen? Wie oft werden gelistete DiGA in diesem Bereich aktuell verschrieben? usw.

Da die Marktdurchdringungsrate sehr individuell für jedes Unternehmen berechnet werden muss, können wir Ihnen hier keinen allgemeingültigen Richtwert an die Hand geben.

Beispiel auf Basis der Marktdurchdringungsrate
Wenn Sie eine prognostizierte Marktdurchdringungsrate von 10 % schätzen, kommen Sie bei einem Gesamtmarkt von 14.060.000 möglichen Freischaltcode-Einlösungen (siehe vorheriges Beispiel) bei Adipositas auf:

Prognostizierte Freischaltcode-Einlösungen = 0,1 x 14.060.000= 1.406.000
(ca. 1,4 Millionen Code-Einlösungen pro Jahr)

Das Beispiel veranschaulicht, wie die Kalkulation in der Praxis aussehen könnte.

QuickBird Medical – Empfehlung
Sehen Sie sich die Verschreibungszahlen anderer DiGA in den aktuellen DiGA-Berichten an, um ein Gefühl zu bekommen, wie oft DiGA in der Praxis aktuell wirklich verschrieben werden. In der folgenden Abbildung finden Sie eine Übersicht aus dem Jahre 2023.

Verordnungen für DiGA mit mehr als 5 Tsd. Verordnungen
Quelle: Daten des GKV-Spitzenverbandes gem. § 33a Abs. 6 SGB V – Stand 30.09.2023

1.5 Folgeverordnungen von DiGA

Es ist relevant auch einmal auf den Unterschied zwischen Erstverordnungen und Folgeverordnungen einzugehen, um dessen Bedeutung für die Kalkulation richtig einzuordnen.

Von einer Erstverordnung sprechen wir, wenn die DiGA zum ersten Mal verschrieben bzw. eingelöst wird. Eine Folgeverordnung kommt dann infrage, wenn mit der Erstverordnung das anvisierte Therapieziel nicht erreicht wurde. In diesem Fall können manche DiGA wiederholt verschrieben werden (falls es sich nicht um eine sogenannte Einmallizenz handelt).

Besonders wichtig ist es hierbei zu verstehen, dass 83 Prozent aller eingelösten Verordnungen zu den Erstverordnungen einer DiGA zählen. Demnach ergibt sich ein Großteil des DiGA-Umsatzes aus Erstverordnungen. Bei DiGA mit Einmallizenz ist eine Folgeverordnung sogar gänzlich ausgeschlossen.

Folgeverordnungen je DiGA
Quelle: Daten des GKV-Spitzenverbandes gem. § 33a Abs. 6 SGB V; Stand 30.09.2023

Bei der Prognosse Ihres DiGA-Umsatzes können Sie Folgeverordnungen in die prognostizierten Zahlen auf Basis der Krankheitsprävalenz einkalkulieren.

Vereinfachtes Beispiel für den Adipositas-DiGA-Gesamtmarkt
(inklusive Folgeverordnungen)

2022 lag die Prävalenz von Adipositas in Deutschland bei 19%. Bei ca. 75 Millionen Versicherten (Stand Januar 2026) und eine Folgeverordnungsquote von 34% der DiGA „Zanadio“ ergibt sich:

Maximale-Freischaltcode-Einlösungen = 0,19 * 74.000.000 * 1,34 = 18.840.400
(= ca. 19 Millionen Code-Einlösungen pro Jahr)

1.6 Beispiel: Prognose des DiGA-Umsatzes für Adipositas

Wichtige Aspekte der Umsatzprognose für DiGA haben wir in den vorherigen Kapiteln erklärt. Nun gehen wir die Formeln in einem Beispiel-Case im Adipositas-Bereich mit Ihnen durch.

Wichtig ist hierbei zu betonen, dass dieses Beispiel nur der Verständlichkeit dient. Kennzahlen wie die Marktdurchdringungsrate müssen individuell im Kontext Ihres Unternehmens kalkuliert werden.

Wir gehen von folgenden Kennzahlen für eine Adipositas-DiGA in Deutschland aus:

Anzahl der gesetzlich Versicherten: 74 Millionen
Prävalenz von Adipositas: 19 %
Prognostizierte Folgeverordnungsquote von Adipositas: 34 %
Prognostizierter DiGA-Vergütungsbetrag: 200 €
Beispielhaft geschätzte Marktdurchdringungsrate: 10 %

Somit ergeben sich folgende Kennzahlen für das Unternehmen:

Marktpotenzial bzw. TAM (Total Addressable Market)
= 74 Millionen x 0,19 x 1,34 x 200 € = 3.768.080.000 €
(3,7 Milliarden Euro)

Realistisch adressierbarer Markt bzw. Serviceable Obtainable Market (SOM)
= 74 Millionen x 0,19 x 1,34 x 200 € x 0,1 = 376.808.000 €
(376 Millionen Euro)

Dies ist eine vereinfachte Kalkulation für den gesamten Adipositas-DiGA Markt. Als DiGA-Unternehmen wird man sich meist auf spezifische ICD-Codes im Zielmarkt konzentrieren und die Rechnung kann so niedriger für die Unterauswahl der Indikationen ausfallen.

Beispiel-Rechnung für den Umsatz (Zanadio)

Wenn man sich im Adipositas-Bereich mit Zanadio ein Beispiel aus der Praxis aussieht, fallen die Umsätze zum aktuellen Zeitpunkt natürlich noch deutlich unter den beispielhaft kalkulierten, adressierbaren Markt:

Eingelöste Freischaltcodes im Zeitraum für Zanadio: 56.000
(56 Tsd – Daten des GKV-Spitzenverbandes gem. § 33a Abs. 6 SGB V; Stand 30.09.2023)

Vergütungsbetrag für Zanadio: 218,00 €

Mit diesen Werten kommt man auf diesen geschätzten Gesamtumsatz:
Umsatz = 56.000 x 218 € = 12.208.000 €
(etwa 12 Millionen Euro)

Da Zanadio zu Beginn auf Erprobung in das DiGA-Verzeichnis aufgenommen wurde, wird der reale Umsatz etwas höher liegen. Vor Verhandlung des finalen Vergütungsbetrags wurde ein Herstellerpreis von 499,80 € abgerufen. Die Kalkulation soll hier nur der Veranschaulichung dienen.

2. Kosten für die Entwicklung und Vermarktung einer DiGA

Nachdem wir nun berechnet haben, was eine DiGA maximal an Ertrag erwirtschaften kann, interessiert uns im nächsten Schritt natürlich, wie hoch die Kosten für die Entwicklung einer DiGA sind.

Die Entwicklung einer DiGA ist ein komplexer Prozess. Die Kosten können stark variieren und hängen von mehreren Faktoren ab. Um Ihnen einen besseren Überblick zu geben, listen wir in unserem kostenlosen Planungstool zur Finanzierung Ihrer DiGA alle Punkte auf, die bei der Kalkulation besonders ins Gewicht fallen.

3. Download: Excel-Planner zur Prognose von Umsatz & Kosten Ihrer DiGA

Mit unserem Excel-Planner kalkulieren Sie in wenigen Minuten den möglichen Umsatz und die Kosten Ihrer digitalen Gesundheitsanwendung.

Hinterlassen Sie hier Ihre E-Mail-Adresse und wir schicken Ihnen den Excel-Planner zu.

4. Update 2026: Anwendungsbegleitenden Erfolgsmessung (AbEM) bei DiGA

Seit Inkrafttreten des Digital-Gesetzes (DigiG) gibt es einen weiteren Faktor, dessen man sich bei der Umsatzkalkulation einer DiGA bewusst sein sollte: die anwendungsbegleitende Erfolgsmessung (AbEM). Sie ergänzt die bisherige Logik der DiGA-Vergütung, ohne diese aktuell grundlegend zu verändern.

Die AbEM wurde mit dem DigiG und der 2. Änderungsverordnung zur DiGAV (2. DiGAV-ÄndV) eingeführt und gilt für alle dauerhaft im DiGA-Verzeichnis gelisteten DiGA, die mindestens einen medizinischen Nutzen als positiven Versorgungseffekt nachgewiesen haben. Die verpflichtende Datenerhebung beginnt ab dem 01.07.2026. Die Ergebnisse sind halbjährlich an das BfArM zu melden, erstmals zum 15.04.2027.

Grundsätzlich kann die AbEM Einfluss auf die Vergütung einer DiGA haben, da gemäß § 134 SGB V ab dem 01.01.2026 ein erfolgsabhängiger Vergütungsanteil von mindestens 20 Prozent vorgesehen ist. Wie genau dieser Anteil auf Basis der AbEM-Ergebnisse berechnet wird, also ob er im Einzelfall eher erhöhend oder reduzierend wirkt, ist derzeit jedoch noch nicht abschließend geregelt.

Für die Praxis bedeutet das: Die AbEM hat potenziellen Einfluss auf die langfristige Vergütung, ist aber für die aktuelle Geschäftsmodell- und Umsatzkalkulation noch nicht konkret quantifizierbar. Für erste Wirtschaftlichkeitsrechnungen kann sie daher vernachlässigt werden, sollte jedoch bei der langfristigen Planung und Weiterentwicklung einer DiGA mitgedacht werden.

5. Fazit

Dieser Artikel hat Ihnen hoffentlich geholfen zu verstehen, wie Sie das Potenzial Ihrer DiGA-Idee abschätzen können.

Wichtig ist hierbei natürlich zu verstehen, dass wir nur auf eine Unterauswahl wichtiger Kennzahlen für die Evaluation eines DiGA-Business-Cases eingegangen sind. Es gibt eine Vielzahl an Kennzahlen, die zur Evaluation von Produkt-Ideen und Unternehmen herangezogen werden können. Zur Ihnen einen Überblick zu verschaffen haben wir uns erstmal auf die finanziellen Aspekte fokussiert, die am Anfang wohl am wichtigsten sind.

Außerdem relevant ist die Tatsache, dass die meisten Unternehmen einen Multi-DiGA-Ansatz planen und auf Basis der ersten DiGA weitere Indikationsgebiete angehen. Der Umsatz aller Indikationsgebiete sollte in diesem Fall aufsummiert werden.

Lohnt sich Entwicklung einer DiGA also schlussendlich? Wie sich über den DiGA-Excel-Planner leicht berechnen lässt, hängt dies stark von der Zielindikation Ihrer DiGA ab. Für Krankheiten mit einer hohen Prävalenz und z.B. einer digital-affinen Zielgruppe können perspektivisch beachtliche Umsätze generiert werden. Das hängt aber am Ende natürlich auch stark davon ab, ob das Marketing & der Vertrieb der gelisteten DiGA richtig geplant und ausgeführt wird (mehr dazu in unserem DiGA Marketing & Vertrieb-Leitfaden).

Die Monetarisierung Ihrer Gesundheitslösung kann auch über einen Selektivvertrag mit einer Krankenkasse erfolgen – als Alternative oder sogar Ergänzung zur DiGA. Alles, was Sie dazu wissen müssen, erfahren Sie in unserem Whitepaper.

Planen Sie eine DiGA?

Dann kontaktieren Sie uns gerne. Wir sind auf die auftragsbasierte Umsetzung von DiGA und Software-Medizinprodukten spezialisiert. Wir helfen Ihnen bei der Planung, Konzeption, der technischen Implementierung und der Einhaltung aller regulatorischen Anforderungen.

The post DiGA Umsatz & Kosten: Lohnt sich eine DiGA? appeared first on QuickBird Medical.

Der Eintrag in das zentrale DiGA-Verzeichnis selbst führt entgegen manchem Wunschdenken nicht dazu, dass Ärztinnen und Ärzte Ihre DiGA auch verschreiben. Daher ist die Wahl der richtigen Marketing- und Vertriebsinstrumente von entscheidender Bedeutung, um das volle Marktpotenzial der jeweiligen Nische auszuschöpfen. Die Möglichkeiten sind vielfältig, das Marktumfeld komplex. Dieser Artikel soll Ihnen einen Überblick verschaffen, und hilfreiche Einordnungen auf den Weg geben.

Überblick

• 1. Patient oder Arzt – zwei mögliche Adressaten, die unterschiedlich erreicht werden
• 2. Verschiedene Kanäle stehen für verschiedene Zielgruppen zur Verfügung
  • 2.1 Marketing für den Patient als Zielgruppe
  • 2.2 Vertrieb & Marketing für den Arzt als Zielgruppe
• 3. Praxis-Beispiel: Faxwerbung an Arztpraxen – ein prominenter DiGA-Case
• 4. Rezeption – viele Wege führen (nicht) zum Ziel
• 5. Bedürfnisse von Patienten und Ärzten verstehen
• 6. Fazit: Verstehen und Erreichen der Zielgruppe ist der Schlüssel zum Erfolg

1. Patient oder Arzt – zwei mögliche Adressaten, die unterschiedlich erreicht werden

Die erste Grundsatzfrage einer jeden Marketingstrategie ist die nach dem Adressaten. Im Falle einer DiGA kommen zwei Gruppen infrage:

• Der Patient, der selbst nach Behandlungsmöglichkeiten im Allgemeinen oder einer auf die eigenen Bedürfnisse zugeschnittenen digitalen Anwendung im Speziellen sucht, und diese bei der Krankenkasse selbst beantragen kann, oder
• Der Arzt oder Therapeut, der die DiGA als sinnvolle Ergänzung einer Therapie erachtet, und sie dem Patienten daher verschreibt.

Der Weg vom DiGA-Hersteller zum Patienten

2. Verschiedene Kanäle stehen für verschiedene Zielgruppen zur Verfügung

Der Arzt ist laut Ernst and Young (EY) mit 90% der Fälle der häufigere Verschreibungsweg, und in einigen Fällen auch in Form einer Ersteinschätzung verpflichtend vorgeschaltet. Das „Kräfteverhältnis“ zwischen beiden Zielgruppen für DiGA-Marketing und -Vertrieb erscheint zum aktuellen Zeitpunkt eindeutig: Für die meisten DiGA-Anbieter wird sich vor allem der Vertriebs/Marketing-Fokus auf den Arzt als Verschreiber der DiGA lohnen.

Dennoch lohnt sich der Blick auf beide Zielgruppen und ihre Erreichbarkeit. Dieser holistische Blick soll Gegenstand des folgenden Abschnittes sein.

2.1 Marketing für den Patient als Zielgruppe

Eine DiGA ist in aller Regel ein Nischenprodukt. Diese klare Abgrenzbarkeit der Zielgruppe(n) kann man sich als DiGA-Anbieter insbesondere durch digitale Werbung effektiv zunutze machen.

Eine Übersicht über denkbare Marketingkanäle, die die Patienten direkt erreichen:

• Suchmaschinenwerbung- und Optimierung – Durch die Optimierung der eigenen Internetpräsenzen für die Sichtbarkeit in Suchmaschinen (SEO), besonders aber durch das Schalten bezahlter Anzeigen, die den Usern großer Suchmaschinen beim Suchen bestimmter Schlüsselbegriffe (=Keywords) ausgespielt werden, kann eine äußerst granular definierte Zielgruppe sehr zielgerichtet erreicht werden. Die erzielte Reichweite hängt in erster Linie vom eingesetzten Budget ab, und kann im Voraus relativ zuverlässig kalkuliert werden. Eher unkalkulierbar insbesondere bei neuen Produkten ist hingegen die Conversion Rate, also die (relative) Zahl der aus der Reichweite heraus tatsachlich getätigten Kaufhandlungen.
  Im Falle von DiGA ist denkbar, mit dieser Methodik besonders solche Patienten zu erreichen, die sich aktiv über ihre Beschwerden, Diagnosen und denkbare Behandlungsoptionen informieren – dabei aber nicht zwangsläufig an eine DiGA denken. Als Keywords können hier beispielsweise Beschwerden und Diagnosen gesetzt werden.
• Social-Media-Marketing – Die sozialen Medien spielen als Informations- und Werbeplattform inzwischen eine entscheidende Rolle. Entsprechend sinnvoll könnte es sein, mit der eigenen DiGA auch hier Präsenz zu zeigen. Im Allgemeinen sind die Erfolgsfaktoren ein authentischer Auftritt, regelmäßiger Content und die Wahl der richtigen Kanäle. Die gewählten Plattformen müssen ebenso zum Produkt und der Zielgruppe passen wie die Art des Auftritts, die Bildsprache, das Wording und der Content. Eine Zielgruppe 50+ wird anders angesprochen als die Generation Z. Der Contentmix für die Bewerbung einer DiGA kann denkbarerweise aus abwechselnden Produktinformationen und Testimonials bzw. Erfahrungen von Nutzern bestehen.
  Auch zwei Spezialitäten von Social Media sind als Teil des Marketingmix‘ theoretisch denkbar: Die Zusammenarbeit mit Influencern (wenn diese als Teil der Zielgruppe glaubwürdig die DiGA bewerben können) und das Schalten von Werbekampagnen. (An dieser Stelle sei darauf hingewiesen, dass bei der Erstellung von Werbematerialien, Texten etc., die sich hier an Patienten direkt richten, besondere Sorgfalt geboten ist. Da eine DiGA immer auch ein Medizinprodukt ist, gilt hier das Heilmittelwerbegesetz (HWG). Beispielsweise darf keinesfalls suggeriert werden, dass der Einsatz der DiGA mit Sicherheit erfolgreich sein wird. Allzu reißerische Formulierungen sind also auch auf Social Media tabu, sonst drohen empfindliche Strafen.
• Display-Advertising – Hier werden auf i.d.R. gut frequentierten Webseiten (z.B. Nachrichtenportalen) frei gestaltbare Werbeanzeigen zwischen den eigentlichen Inhalten angezeigt. Auch hier lässt sich bei den meisten Anbietern (hier ist die Auswahl größer als bei den Suchmaschinen oder sozialen Medien) gut filtern, welche Personen mit welchen Interessen und welchen demografischen Merkmalen die Anzeige sehen sollen. Die Kosten hängen auch hier von der erzielten Reichweite ab – der Streuverlust ist hier jedoch relativ hoch. Im speziellen Fall einer DiGA kommt hinzu, dass diese hier mit zahlreichen anderen beworbenen Produkten um ein begrenztes Maß an Aufmerksamkeit konkurriert.
• Klassische Massenmedien – Natürlich besteht auch für digitale Produkte die Möglichkeit, diese in klassischen, analogen Kanälen (TV, Radio, Print…) zu bewerben. Verschiedene Punkte sprechen jedoch eher gegen diesen Weg – im Gegensatz zu allen digitalen Kanälen besteht außer der Auswahl des Mediums selbst keinerlei Möglichkeit, das Publikum zielgerichtet zu filtern, ebenso fehlen Instrumente zur Erfolgsmessung und Ergebnisanalyse. Die Investitionen in die Produktion der Medien selbst (Radiospots, TV-Clips…) sind sehr hoch, gleiches gilt für deren Ausspielung. Dem gegenüber steht ein hoher Anteil „toter“ Reichweite.
• (Werbe-)Partnerschaft mit Krankenkassen – Theoretisch ist die Kooperation mit Krankenkassen auch ein denkbarer Weg, Patienten direkt zu erreichen. Schließlich stellen diese die Schnittstelle zwischen Patienten und dem Gesundheitssystem dar, und verfügen über ein weit verzweigtes Kommunikationsnetz zu den Versicherten. Fraglich ist allerdings, wie diese von einer Kooperation überzeugt werden sollen: Werbewirkung für die Krankenversicherung selbst können sich zumindest die gesetzlichen Krankenkassen nicht (mehr) erhoffen, da sie durch den Gesetzgeber sowieso zur Erstattung der DiGA verpflichtet sind.

2.2 Vertrieb & Marketing für den Arzt als Zielgruppe

Die mit 90% der Verschreibungen deutlich wichtigere Zielgruppe stellt die Ärzteschaft dar. Diese kann besonders auf Wegen erreicht werden, die sich im Bereich des DiGA-Marketings/-Vertriebs von solchen des klassischen Pharmavertriebes wenig unterscheiden.

Hinweis: Aus Gründen der Lesbarkeit wurde in diesem Text der Begriff „Arzt“ als Synonym für alle Mediziner und Therapeuten verwendet, die DiGA verschreiben dürfen.

• Direktvertrieb: Klassischer Außendienst – Für Ärzte ist es Gewohnheit, regelmäßig von Außendienstlern der Pharmabranche aufgesucht zu werden. Durch den persönlichen Kontakt zu einem festen und physisch greifbaren Ansprechpartner wird Vertrauen und damit eine Bindung geschaffen. Auch ein DiGA-Hersteller kann prinzipiell diesen Weg gehen, um eine Anwendung in der Ärzteschaft zu etablieren. Der Aufbau eines kompletten Außendienstnetzes ist fraglos mit nicht unerheblichen Kosten verbunden. Dass er sich jedoch durchaus amortiseren kann, hat Marcus Bergler, Experte für DiGA-Vertrieb, in seinem Artikel plausibel errechnet. Dieser Vertriebskanal kommt der Ärzteschaft mutmaßlich am weitesten entgegen, da sie ihn bereits aus der Pharmabranche kennt.
• Direktvertrieb: Zusammen mit Partnern – In diesem Kontext ist zudem ein interessanter Trend zu beobachten: DiGA-Start-Ups schließen sich in unterschiedlichen Formen mit Pharmaunternehmen zusammen, Beispiele sind hier die Kooperationen von Kalmeda mit Pohl-Boskamp oder HelloBetter und Ratiopharm. Auch Pfizer und Roche zeigen großes Interesse am DiGA-Markt. Die bestehende, etablierte und weit verästelte Vertriebsstruktur der Pharmaunternehmen kann für den Vertrieb der DiGA mitgenutzt werden, im Gegenzug können die Pharmaunternehmen vom technologischen Know-How der Start-Ups profitieren. Eine Alternative zu diesem Modell – für solche DiGA-Hersteller, die von der Pharmaindustrie unabhängig agieren wollen – stellt eine gegenseitige Kooperation dar. DiGA-Hersteller bauen ein gemeinsames Vertriebsnetz auf, teilen sich somit Kosten und Risiken, und stellen bestmögliche Auslastung sicher.
• Klassische Breitenwerbung – Während der oben beschriebene „klassische“ Direktvertrieb wohl das zentrale Instrument zum unmittelbaren Vermarkten des Produktes ist, kann dieses durch flankierende Maßnahmen mit dem Zweck der Bekanntheitssteigerung und des allgemeinen Imagebuildings unterstützt werden. Klassische Mittel sind hier z.B. Werbeanzeigen oder optimalerweise das Erreichen „echter“ Berichterstattung in Fachmedien ebenso wie das Versenden speziell für die Ärzteschaft konzipierter Broschüren an Praxen mit relevantem Schwerpunkt. Ähnlich wie in anderen Branchen auch finden für Ärzte zudem regelmäßig Events statt. Je nach Format kann es sinnvoll sein, durch z.B. einen Stand und/oder einen Fachvortrag Präsenz zu zeigen.
• Sponsorings von Fortbildungen – Eine subtilere Maßnahme zur Bekanntheitssteigerung kann die Übernahme eines Sponsorings sein: Jeder Facharzt ist verpflichtet, innerhalb von fünf Jahren 250 sogenannter CME-Punkte zu erwerben. Die entsprechenden Fortbildungen werden häufig kostenfrei angeboten, und finanzieren sich u.A. über Sponsorings, z.B. von Arzneimittelherstellern. Auch wenn ein Sponsoring keinerlei Einfluss auf die Inhalte der Fortbildung haben darf, erhält der Sponsor doch eine gewisse Präsenz in der Veranstaltung, sei es durch Erwähnung und Positionierung des Namens oder Logos oder durch die Auslage von Werbeartikeln. Es existieren bereits CME-Fortbildungen speziell zum Thema DiGA. Noch geschickter kann sein, solche Fortbildungen zu sponsern, die sich mit dem durch die DiGA adressierten Krankheitsbild befassen. Mit einer solchen Maßnahme besteht Zugang zu einem Publikum, das durch die DiGA fachlich tangiert wird, und zugleich ggf. durch das Sponsoring erstmals von einer solchen hört.

Hinweis: Die Liste der genannten Distributionskanäle ist sicher nicht vollständig und sollen Ihnen vor allem einen initialen Überblick über einige möglich Maßnahmen geben. Sie sollten grundsätzlich auch andere Wege in Betracht ziehen, die hier nicht explizit genannt wurden.

3. Praxis-Beispiel: Faxwerbung an Arztpraxen – ein prominenter DiGA-Case

Ein viel beachteter Fall aus dem DiGA-Markt betrifft einen Hersteller einer Adipositas-DiGA, der eine gezielte Marketingtaktik einsetzte: Patient:innen, die Interesse an der DiGA zeigten, wurden vom Hersteller aktiv dazu bewegt, ihm eine Vollmacht zur Kontaktaufnahme mit der behandelnden Hausarztpraxis zu erteilen. Auf dieser Grundlage versandte der Hersteller ein Fax an den Arzt, um die Ausstellung einer Verordnung oder eines Kurzattestes anzustoßen.

Das Fax enthielt ein Anschreiben, ein Formular für ein Kurzattest (in dem die DiGA bereits voreingetragen war) sowie ein Formular zur kostenlosen Anforderung weiterer Informationen zur DiGA. Zudem wies der Hersteller auf abrechenbare ärztliche Leistungen im Zusammenhang mit der Nutzung der DiGA hin. Der Ansatz erwies sich als sehr wirksam und führte kurzfristig zu einer hohen Zahl an Verordnungen.

Rechtlich ist dieser Vertriebsweg jedoch nicht zulässig. Mit Urteil vom 18.11.2025 (Az. 6 U 130/24) stellte das OLG Brandenburg klar, dass es sich hierbei um unzulässige Werbung per Telefax nach § 7 UWG handelt, da der Arzt in eine solche Werbung nicht eingewilligt hatte. Maßgeblich war, dass das Fax über eine neutrale Weiterleitung des Patientenanliegens hinausging und gezielt absatzfördernde Elemente enthielt.

Der Fall zeigt exemplarisch: Auch sehr effektive, patientenseitig initiierte Marketingtaktiken stoßen im DiGA-Vertrieb an klare rechtliche Grenzen.

4. Rezeption – viele Wege führen (nicht) zum Ziel

Dass das Thema DiGA für den angesprochenen Arzt Neuland ist, ist nicht unwahrscheinlich. Laut einer Umfrage des Fraunhofer-Instituts aus dem Jahr 2021 „schätzen 75% der teilnehmenden Ärzte ihren Informationsstand zu DiGA als schlecht oder sehr schlecht ein“. Entsprechend hoch ist der Informationsbedarf und das Interesse: In derselben Umfrage erklären 37% der Ärzte eine „hohe oder sehr hohe Bereitschaft“, DiGA zu verordnen. Bisher getan haben dies laut eigenen Angaben jedoch erst 2%. Dennoch machen, wie erwähnt, Verschreibungen durch Ärzte 90% des Gesamtmarktes aus.

Ärzte sind ein attraktives Ziel für DiGA-Marketing

Geringer Informationsgrad, hohes Interesse, absolute Marktmacht: Die Ärzteschaft als Zielgruppe ist somit die „Low Hanging Fruit“, die es als ersten Schritt nach einem Markteintritt zu ernten gilt. Naheliegendster und erfolgversprechendster Schritt ist, hierfür den direkten Kontakt zu suchen. Kann oder will man das als einzelner DiGA-Hersteller nicht allein bewältigen, bietet sich an, mit Pharmaunternehmen oder anderen DiGA-Herstellern zu kooperieren. Flankiert werden kann das durch diverse Maßnahmen zur Steigerung des Bekanntheitsgrades: Werbeaktionen, Präsenzen auf Kongressen und Veranstaltungen oder Sponsoring entsprechender Fortbildungen.

Mit dem steigenden Bewusstsein für Gesundheit in der Gesellschaft einserseits und dem wachsenden Bekanntheitsgrad digitaler Technologien andererseits ist denkbar, dass sich das schnell ändert. Gegebenenfalls induziert durch Marketing- und Vertriebsaktivität seitens der DiGA-Hersteller selbst. Zur Vermarktung einer DiGA an den Patienten direkt steht nahezu die gesamte Klaviatur der Produktwerbung zur Verfügung, mit Blick auf die sehr klare Abgrenzbarkeit und die vorausgesetzte Digitalaffinität der Zielgruppe(n) erscheint besonders solche in digitaler Form sinnstiftend. Das Risiko ist hier zugleich geringer: Fixkosten entstehen nicht.

5. Bedürfnisse von Patienten und Ärzten verstehen

Ein Schlüssel für die erfolgreiche Definition der eigenen Marketingstrategie ist neben der Wahl der Kanäle auch die der Inhalte. Für beides von Bedeutung ist das Verstehen der Denkweise und Bedürfnisse der Zielgruppen. “Der Erfolg des digitalen Wandels im Gesundheitswesen steht und fällt damit, wie weit Patienten, Versicherte und Leistungserbringer digitale Lösungen akzeptieren”, stellt die Bertelsmann-Stiftung fest.

Der Markt muss nach der entsprechenden DiGA „verlangen“. Die Zielgruppe „Patienten“ muss eine sein, die eine gesundheitliche Herausforderung mit hohem individuellen Leidensdruck und zugleich begrenzten Therapiemöglichkeiten mit sich bringt. An diesen Punkten kann und muss das DiGA-Marketing den Patienten „abholen“, und ihm verdeutlichen, dass mit der DiGA eine unkonventionelle Methode zur Verfügung steht, die zudem bestenfalls äußerst nutzerfreundlich in den Alltag zu integrieren ist. Wie Sie Ihre Zielgruppe zielführend definieren und einen positiven Versorgungseffekt nachweisen, erfahren sie in unserem Leitfaden.

Für die Zielgruppe „Ärzteschaft“ ist von Bedeutung, dass die DiGA nachweislich „funktioniert“. Ärzte hören z.B. auch auf das Feedback, das Patienten diesen Nach Nutzung übermitteln. Wenn der Patient nicht von der DiGA überzeugt ist oder diese nicht nutzt, sinkt die Wahrscheinlichkeit für Folgeverordungen drastisch.

6. Fazit: Verstehen und Erreichen der Zielgruppe ist der Schlüssel zum Erfolg

Die Vielfalt an denkbaren Marketing- und Vertriebswegen ist enorm. Das kann besonders zum Start erschweren, sich für einen Ansatzpunkt, eine Strategie (und bestenfalls die „richtige“) zu entscheiden.

Klar ist jedoch auch: Eine universelle Handlungsempfehlung kann es nicht geben. Jede DiGA ist ein einzigartiges Produkt in einem jeweils einzigartigen und komplexen Marktumfeld. Für einen erfolgreichen Marktstart ist essenziell, dieses Umfeld genau zu analysieren, und darauf aufbauend die Marketing- und Vertriebsmethodik zu wählen, die am besten zu Produkt und Zielgruppe passt.

Sie stehen momentan noch am Anfang? Welche Faktoren Sie bei der Planung und Umsetzung Ihrer DiGA beachten sollten, erfahren Sie in unserem Whitepaper „13 Empfehlungen für die Zulassung von DiGA in 2026“.

Mit diesem Artikel war unser Ziel, Ihnen einen breit gestreuten Überblick über denkbare Instrumente zu verschaffen, und diese, der Natur eines Blogartikels entsprechend, verallgemeinert einzuordnen.

Über uns: QuickBird Medical ist auf die Umsetzung von DiGA auf Auftragsbasis spezialisiert. Falls Sie eine DiGA planen, sprechen Sie uns gerne an:  [email protected].

The post Leitfaden DiGA-Marketing und Vertrieb appeared first on QuickBird Medical.

1. Priorisieren Sie einen zeitnahen Marktstart

Gewinnbringende Geschäftsmodelle im Gesundheitswesen zu etablieren, erfordert Zeit. Wenn Sie z.B. Krankenkassen oder potenzielle B2B-Kunden von Ihrer Software-Lösung überzeugen möchten, werden Sie ggf. viel Zeit in Besprechungen und Verhandlungen verbringen. Dies kann sich Monate oder sogar Jahre in die Länge ziehen. Je später Sie mit diesen Erstkontakten beginnen, desto später können Sie mit Ihrer Lösung Umsatz generieren. Um in diese Besprechungen einzusteigen, benötigen Sie jedoch meistens schon einen funktionierenden Prototyp (bzw. MVP) oder sogar ein zertifiziertes Software-Medizinprodukt inklusive wissenschaftlicher Evidenz über den medizinischen Mehrwert und/oder Kosteneinsparungspotenziale. Daher sollten Sie sich in der Planung Ihrer Software-Features nicht verlaufen. Fokussieren Sie sich auf die Kernfunktionen und setzen Sie erstmal nur diese Kernfunktionen um. Alle Erweiterungen, die nicht unbedingt nötig sind („Nice-To-Have“), sollten Sie eventuell erst später umsetzen. Um dies nochmal zu betonen: Je mehr Zeit Sie für die Planung und Umsetzung der ersten Produkt-Version benötigen, desto später können Sie Umsatz am Markt generieren. Sales-Zyklen am Gesundheitsmarkt sind lang. Fangen Sie nicht zu spät damit an. Planung ist natürlich gerade bei regulierten Medizinprodukten, die einer Zulassung und Zertifizierung bedürfen, enorm wichtig. Optionale Zusatz-Features können aber auch bei Medizinprodukt-Software teilweise erstmal weglassen und auf spätere Produkt-Versionen verschoben werden.

Unsere Empfehlung: Starten Sie mit etwas Einfachem, das dennoch einen hohen Mehrwert für Ihre Zielgruppe mit sich bringt. Versuchen Sie, schnell  auf den Markt zu kommen. Um Erweiterungen, weitere Apps, oder stark innovative Features können Sie sich im nächsten Schritt kümmern.

2. Nutzen Sie vorhandene wissenschaftliche Evidenz

Um Ihr Software-Medizinprodukt auf den Markt zu bringen, müssen Sie für die Zertifizierung unter anderem wissenschaftlich nachweisen, dass Ihr Produkt den angestrebten medizinischen Zweck erfüllt. Für Produkte der Risikoklasse IIa oder höher müssen Sie hierfür womöglich eine aufwendige klinische Prüfung (Studie für Ihr Medizinprodukt) durchführen. Für Produkte der Risikoklasse I (gerade Produkte, die auf existierende medizinische Leitfäden aufsetzen) reicht der Aufsichtsbehörde gegebenenfalls eine systematische Literatur-Recherche.  Wenn Ihr Produkt also existierende medizinische Leitfäden oder Methoden digitalisiert, können Sie potenziell die existierende wissenschaftliche Evidenz nutzen, um Ihr Produkt zu validieren. Sie benötigen somit eventuell keine kostspielige klinische Studie bzw. klinische Prüfung. Ob dies für Ihr Produkt wirklich ausreichend ist, muss natürlich im Einzelfall abgeklärt werden. Wenn Ihr Produkt allerdings hochgradig innovativ ist und Sie komplett neue Methoden entwickeln, liegt hierfür natürlich keine Evidenz vor. Sie müssen diese Evidenz selbst generieren und z.B. eine klinische Studie durchführen. Wenn Sie triftige Gründe haben anzunehmen, dass Ihr Produkt einen medizinischen Nutzen nachweisen kann und am Markt viel Umsatz generieren wird, kann sich eine solche klinische Studie lohnen. Dies hängt vom Produkt und Anwendungsfall ab.

Unsere Empfehlung: Für den initialen Marktstart sollten Sie versuchen, erstmal existierende wissenschaftliche Evidenz zu nutzen, wenn dies möglich ist. Dies ermöglicht Ihnen potenziell einen deutlich schnelleren Marktstart ohne klinische Prüfung/Studie. Später werden Sie ggf. trotzdem weitere Studien zu Ihrem Produkt fahren (dies hilft auch ungemein bei der Vermarktung Ihres Produkts). Zu diesem Zeitpunkt ist Ihr Produkt aber im Optimalfall bereits am Markt und generiert Umsatz – eine deutlich angenehmere Ausgangslage.

3. Visieren Sie Risikoklasse I an

Eine Zeit lang kursierte die Nachricht, dass es unter MDR kaum noch Software-Medizinprodukte der Risikoklasse I geben würde, was zum Glück nicht stimmt. Fast alle unter MDR zugelassenen Anwendungen im DiGA-Verzeichnis sind der Risikoklasse I zugeordnet. Auf unserem DiGA-Dashboard für Hersteller erhalten Sie einen genauen Überblick über die Verteilung der Risikoklassen bereits gelisteter DiGA. Ob Ihr Medizinprodukt in die Risikoklasse I fällt, hängt von verschiedenen Aspekten ab. Werfen Sie einen Blick in unseren Leitfaden zur Klassifizierung von Software-Medizinprodukten nach MDR, um dies herauszufinden. Normalerweise ist die Zertifizierung von Software der Risikoklasse IIa mit einem erheblich höheren Aufwand und zusätzlichen Kosten verbunden, da eine benannte Stelle eingeschaltet werden muss. Bei der Risikoklasse I haben Sie weitaus höhere Chancen, Ihr Produkt auch ohne eine klinische Prüfung zuzulassen. Es könnte sich daher lohnen, Ihre Anwendung so aufzusetzen, dass sie in die Risikoklasse I fällt. Wir verstehen jedoch, dass solche Änderungen am Konzept nicht für jedes Produkt möglich sind. Insbesondere bei Produkten, die von Patienten verwendet werden, kann es jedoch häufig funktionieren. Es lohnt sich also möglicherweise, darüber nachzudenken. Gerne beraten wir Sie zu diesem Thema und evaluieren, ob die Risikoklasse I für Ihr Produkt geeignet ist.

Unsere Empfehlung: Gestalten Sie Ihre Anwendung so, dass eine Klassifizierung nach Risikoklasse I möglich ist, um erheblichen Mehraufwand ab Risikoklasse IIa zu vermeiden.

4. Wählen Sie die richtige Zielgruppe

Die gewählte Zielgruppe und der Verwendungszweck Ihrer Medizinprodukt-Software bestimmt maßgeblich über den Erfolg Ihrer Unternehmung. Relevante Fragen, die Sie evaluieren sollten, könnten sein:

Dies sind nur einige der relevanten Punkte bei der Wahl der Zielgruppe, aber es soll Ihnen ein Verständnis geben, wie wichtig die präzise Definition der richtigen Zielgruppe für Ihr Produkt ist.

Unsere Empfehlung: Führen Sie qualitative Interviews durch, recherchieren Sie zusätzliche Daten und testen Sie Ihr Produkt mithilfe eines Click-Dummies an Ihrer Zielgruppe. Somit können Sie frühzeitig erkennen, ob Sie die richtige Zielgruppe gewählt haben bzw. ob das Produkt zur Zielgruppe passt und vermeiden kostspielige Strategiewechsel im späteren Produktverlauf.

5. Nehmen Sie Datensicherheit und Datenschutz ernst

Die Datensicherheit und der Datenschutz laufen Gefahr, während der Produktentwicklung zu niedrig priorisiert zu werden. Dies liegt auch daran, dass der Nutzen von Datensicherheit leider erst dann klar wird, wenn es schon zu spät ist und z.B. ein Angreifer die Daten Ihrer Patienten gestohlen hat. Ein solches Datenleck kann neben möglichen Strafzahlungen einen massiven Reputationsschaden an Ihrem Unternehmen und Produkt anrichten. Dies sollten Sie natürlich auf das Nötigste vermeiden.

Leider bringt die Umsetzung des Datenschutzes nach DSGVO und der Datensicherheitsmaßnahmen z.B. nach ISO/IEC 27001 und BSI-Standards einen entsprechenden Aufwand mit sich. Sie brauchen Experten, die sich in diesem Gebiet auskennen und einen strukturierten Ansatz, um nicht nur technische, sondern auch organisatorische Datensicherheits-Risiken zu mitigieren. Hierfür gibt es existierende Leitfäden und Standards, die Sie nutzen sollten (z.B. Technische Richtlinien vom BSI, Leitfäden der OWASP Foundation und Normen wie die ISO/IEC 27001 und die IEC 81001-5-1).

Wichtig ist hierbei vor allem: Auch um die Kosten Ihrer Software oder App durch Krankenkassen erstatten zu können, ob über den DiGA-Pfad oder Selektivverträge, werden bestimmte Zusicherungen der Datensicherheit notwendig. DiGA müssen sogar eine Zertifizierung nach BSI TR-03161 vorweisen.

Unsere Empfehlung: Nehmen Sie das Thema Datensicherheit und Datenschutz sehr ernst. Bauen Sie intern Cyber-Security- und Datenschutz-Kompetenz auf oder arbeiten nur mit Dienstleistern, die nachweislich Datensicherheits-Prozesse (z.B. ein Information Security Management System nach ISO/IEC 27001 und IEC 81001-5-1) etabliert haben und DSGVO-Konformität nachweisen können.

6. Machen Sie sich ein holistisches Bild über verschiedene Finanzierungsoptionen

Je nachdem, ob Sie eine Patienten-App oder eine Software für Ärzte entwickeln, haben Sie viele verschiedene Finanzierungs-Optionen, die auch mit unterschiedlichen Zertifizierungs-Wegen einhergehen. Eine Software für Healthcare Professionals könnte z.B. einzeln an Arztpraxen oder Kliniken verkauft werden, Fördermittel des Bundes nutzen, den Weg über Hilfsmittel-Verzeichnis des GKV gehen oder durch Krankenkassen finanziert werden. Eine Patienten-App könnte z.B. 

• … durch Selektivverträge mit Krankenkassen erstattet werden.
• … als DiGA im Rahmen des Digitale-Versorungs-Gesetzes finanziert werden
• … von der Zentrale Prüfstelle für Prävention (ZPP) zertifiziert und so über Krankenkassen erstattet werden.
• … im Selbst-Zahler-Modell durch Patienten bezahlt werden.

Die Entscheidung für die richtige Option sollten Sie mit Bedacht treffen.  Hier ist z.B. eine Gegenüberstellung zweier Optionen für die Erstattung einer Patienten-App durch Krankenkassen:

Unsere Empfehlung: Evaluieren Sie vorab, welcher Finanzierungsweg am besten zu Ihrem Produkt und Ihrem Unternehmen passt. Sprechen Sie mit Experten und anderen Unternehmen, die solche Wege schon mit Ihren Produkten gegangen sind, um Erfahrungswerte zu hören. Klären Sie dies frühzeitig, weil durch das gewählte Finanzierungsmodell ggf. Zusatzanforderungen an Ihr Produkt oder die nötige wissenschaftliche Evidenz gestellt werden.

Sieben weitere Tipps zur Zertifizierung erhalten Sie in unserem Whitepaper…

Alle weiteren Zertifizierungs-Tipps finden Sie in unserem Medizinprodukt-Whitepaper. Einfach über das Formular downloaden.

Fazit: Erhöhen Sie die Erfolgswahrscheinlichkeit Ihrer Medizinprodukt-Software

Die Entwicklung einer Medizinprodukt-Software ist durch die regulatorischen Hürden kein Unterfangen, das unterschätzt werden sollte. Mit guter Planung und der richtigen Beratung können Sie die Chancen für die Zulassung und Zertifizierung und damit den erfolgreichen Markteintritt stark erhöhen. Wir hoffen, dass Ihnen die obigen Empfehlungen helfen, unnötigen Aufwand und potenzielle Risiken zu vermeiden. Weitere Informationen zu Themen wie dem Medizinprodukt-Zulassungsprozess, der Durchführung einer klinischen Bewertung für Ihre Software und sonstigen Themen im Qualitätsmanagement finden Sie auf der Übersichtsseite unseres DiGA- und Medical Software-Blogs.

The post Software als Medizinprodukt: 13 Zertifizierungs-Tipps für Hersteller appeared first on QuickBird Medical.

Und tatsächlich – viele zertifizierte DiGA, die es auf den Markt schaffen, zeigen überaus positive Verordnungs- und Umsatzzahlen. Andere hingegen bekommen keine Zulassung oder scheitern bereits vor der Antragstellung. Doch warum ist es so? Welche Faktoren beeinflussen das Scheitern oder den Erfolg Ihrer DiGA? In diesem Artikel fassen wir die wichtigsten Faktoren und Empfehlungen zusammen, die Sie im Jahr 2026 bei der Planung und Umsetzung bis hin zu der Zulassung Ihrer DiGA beachten sollten.

Inhaltsverzeichnis

• 1. Der positive Versorgungseffekt
• 2. Planen Sie BSI TR-03161 bereits beim Produktkonzept mit ein
• 3. Planen Sie Ihre klinische Studie ausreichend
• 4. Arbeiten Sie mit den richtigen Medizinprodukt-Beratern zusammen
• 5. Nutzen Sie das Beratungsangebot des BfArM
• 6. Visieren Sie Risikoklasse I an
• 7. Verwenden Sie existierenden Code zur Umsetzung der ePA- und GesundheitsID-Anbindung

1. Der positive Versorgungseffekt im Fokus

Bei der Konzeption und dem Design Ihrer DiGA sollte der positive Versorgungseffekt im Mittelpunkt stehen. Wenn Ihre Studie am Ende keinen signifikanten Effekt auf die Patientenpopulation nachweisen kann, wird Ihre DiGA auch nicht dauerhaft im DiGA-Verzeichnis aufgenommen. Das sollte daher der Mittelpunkt jeglicher Produkt-Design-Entscheidungen sein.

Studien-Endpunkte frühzeitig definieren

Definieren Sie frühzeitig, welchen positiven Versorgungseffekt Sie anstreben möchten. Seien Sie hierbei so konkret wie möglich. Definieren Sie die primären und sekundären Endpunkte Ihrer Studie ggf. bereits während der Produktplanung.

Design mit Fokus auf positivem Versorgungseffekt

Jedes Produkt-Feature, das nicht unmittelbar zu einer Steigerung des angestrebten Versorgungseffekts beiträgt, sollte hinterfragt werden. Es ist ohnehin schon eine große Herausforderung, im DiGA-Verzeichnis zu landen. Jede zusätzliche Produktkomplexität erhöht Ihre Kosten und Time-to-Market. Sie sollten zusätzliche Funktionen nur einbauen, wenn diese auch sehr wahrscheinlich einen positiven Einfluss auf den Versorgungseffekt haben.

Nutzung von existierender Evidenz

Nutzen Sie beim Design existierende Evidenz in Ihrem angestrebten Indikationsgebiet. Anerkannte Leitfäden bieten eine solide empirische Grundlage und etablierte Therapiemethoden sind gut erforscht. Daher stehen auch die Chancen gut, dass Sie mit Ihrer digitalen Lösung ebenfalls einen positiven Versorgungseffekt nachweisen können.

Unsere Empfehlung:
Stellen Sie sich bei jeder Produkt-Funktion die Frage: „Hat diese Funktion einen Einfluss auf den positiven Versorgungseffekt meiner DiGA?“. Features, die „nice-to-have“ sind, sollten Sie erstmal weglassen und sich auf die medizinisch relevanten Produkt-Funktionen fokussieren.

2. Planen Sie BSI TR-03161 bereits beim Produktkonzept mit ein

Seit 1. Januar 2025 müssen DiGA zur Aufnahme in das DiGA-Verzeichnis vorher von einer akkreditierten Prüfstelle nach BSI TR-03161 zertifiziert werden.
Die Sicherheitsanforderungen der BSI-TR-03161 sind umfangreich und haben teilweise einen tiefgreifenden Einfluss auf das technische Konzept und sogar die Nutzeroberfläche Ihrer DiGA.
Eine fertig entwickelte DiGA nachträglich BSI-konform zu machen ist allerdings deutlich mehr Aufwand als die Anforderungen von Anfang an bei der technischen Planung zu integrieren.
Die Sicherheitsanforderungen der BSI TR-03161 beeinflussen z.B. indirekt:

• Die Auswahl der Software-Frameworks & -Bibliotheken
• Die technische Architektur
• Die Auswahl des Server-Anbieters (Stichwort „C5-Zertifikat“)
• Verschlüsselungskonzept
• Technische Kommunikation der Komponenten
• Authentifizierungsmethoden
• Etc.

Unsere Empfehlung:

Wenn Sie Aufwand und Kosten sparen möchten, beschäftigen Sie sich mit der BSI TR-03161 bevor Sie die Entwicklung Ihrer Software beginnen. Identifizieren Sie die Anforderungen, die maßgeblichen Einfluss auf Ihr technisches Konzept haben und integrieren Sie diese entsprechend frühzeitig. Gerne unterstützen wir Sie hierbei mit Beratungs- oder Entwicklungsleistungen (hier finden Sie mehr Informationen).

3. Planen Sie Ihre klinische Studie ausreichend

Im Startup-Bereich gibt es viele einflussreiche Paradigmen, die es Unternehmern erlauben, die Erfolgswahrscheinlichkeit der eigenen Firma zu erhöhen:

• „Move fast and break things“ (Facebook)
• „Responding to change over following a plan“ (Agile Software Development Manifesto)
• „Fail Faster“

Diese Mantren und Strategien sind in gewissen Kontexten enorm hilfreich und wichtig. Wenn es um die Planung eines Medizinprodukts oder einer DiGA geht, ist Voraus-Planung jedoch deutlich wichtiger als im klassischen Software-Startup-Bereich.

Ihre DiGA muss in einer klinischen Studie den positiven Versorgungseffekt nachweisen, um dauerhaft im Verzeichnis gelistet zu sein. Diese sind sehr zeit- und kostenintensiv, weshalb das Budget oft nur für ein oder zwei Studien ausreicht. Daher können Sie nur eine begrenzte Anzahl an Produkt-Ansätzen ausprobieren bzw. evaluieren. Der Druck steigt, dass der erste Ansatz der Richtige sein muss. Demnach müssen Sie ausreichend planen, um die Erfolgswahrscheinlichkeit dieses Ansatzes zu erhöhen.

Die Planung der DiGA sollte natürlich auch die Ergebnisse aus etwaiger qualitativer und quantitativer User Research berücksichtigen. Sie können zu Beginn verschiedene Ansätze in Betracht ziehen. Sobald Sie sich jedoch für einen entschieden haben, ist ein Richtungswechsel deutlich schwieriger.

Abseits von der Produktkonzeption gilt es auch bei der Studie, auf Qualität zu achten. Wie Sie bestimmt wissen, müssen Sie eine vergleichende Studie durchführen.

Hier sind unter anderem die folgenden Fragen zu beantworten:

• Wie groß soll die Stichprobe sein?
• Für welche Patientengruppe (ICD-Code) wollen Sie konkret einen Nachweis erzielen?
• Wie erhalten Sie Zugang zu dieser Patientengruppe?
• Wie sieht deren aktuelle Versorgungsrealität aus?
• Welche ethischen Bedenken gibt es bei der Studie?
• Wie viele Vergleichsgruppen benötigen Sie?
• Wie wird bei der Gruppenzuweisung der Probanden vorgegangen?
• Welche Endpunk​​te sollen konkret gemessen werden – und wie wollen Sie diese erheben?
• Wie lange muss die DiGA genutzt werden, um einen positiven Versorgungseffekt nachzuweisen?
• Welchen Versorgungseffekt soll Ihre DiGA überhaupt erzielen?

Suchen Sie sich für die klinische Studie am besten einen zuverlässigen Partner, welcher speziell mit DiGA- und Software-Studien bereits Erfahrungen hat (gerne helfen wir Ihnen bei der Auswahl der CRO mit unserem Kontaktnetzwerk – schicken Sie uns einfach hierzu eine kurze Nachricht).

Außerdem steht nach Ende des Erprobungszeitraums die Preisverhandlung mit dem GKV-Spitzenverband an. Dort entscheidet sich, wie lukrativ Ihre Anwendung auf Dauer sein wird. Die Qualität Ihrer Studie und die Stärke des positiven Versorgungseffekts sind dabei enorm wichtige Verhandlungsargumente, die es Ihnen ermöglichen, einen dauerhaft höheren DiGA-Preis zu erzielen.

Unsere Empfehlung:

Prüfen Sie, ob es existierende wissenschaftliche Evidenz gibt, die suggeriert, dass Ihre DiGA einen positiven Versorgungseffekt nachweisen kann – und wenn ja, wie dieser aussieht. Fahren Sie erste qualitative und quantitative Untersuchungen, um zusätzliche Daten für die Produkt-Konzeption zu generieren. Planen Sie zudem das Studiendesign (ggf. mit einer CRO) wirklich gut, damit Sie keine Überraschungen während oder bei Abschluss der Studie zu erwarten haben. Je sauberer Ihr methodisches Vorgehen ist, desto größer ist die Chance, eine dauerhafte Zulassung zu bekommen und einen höheren Preis für Ihre DiGA zu verhandeln.

4. Arbeiten Sie mit den richtigen Medizinprodukt-Beratern zusammen

Eine DiGA muss vor dem Antrag als Medizinprodukt zugelassen werden. Gerade im Medizinprodukte-Bereich sollten Sie sich Partner suchen, die Sie zielführend hierbei beraten können. Schlechte Berater kosten Sie enorm viel Zeit und Geld. Gute Berater helfen Ihnen, zügig und kostenschonend auf den Markt zu gelangen.

Unpassende Berater zeichnen sich z.B. durch folgende Eigenschaften aus. Sie …

• … haben wenig Vorwissen in Bezug auf Standalone-Software. Die Berater kommen z.B. aus dem Hardware-Bereich und haben Schwierigkeiten, die Komplexität und das Mindset in der Standalone-Software-Entwicklung zu verstehen.
• … haben keine Erfahrung mit agiler Entwicklung, schon gar nicht in Bezug auf Medizinprodukte.
• … erklären Dinge unnötig kompliziert und zeigen keinen klaren Weg zur Umsetzung auf.
• … treiben die Beratungskosten künstlich in die Höhe, indem sie sich unersetzlich machen. Sie blockieren den Wissenstransfer zu Ihrem Unternehmen entweder wissentlich oder unbewusst.

Gute Berater hingegen …

• … finden pragmatische Lösungen, die kreativ und konkret umsetzbar sind. Gute Berater kennen die Regeln und wissen, wie man diese befolgt, ohne unnötig Ressourcen zu verbrennen.
• … erarbeiten Lösungen, die in Ihr Unternehmen passen, anstatt Ihnen umständliche ihre Standard-Prozeduren aufzuzwingen.
• … erklären Dinge in einfacher Sprache und ermöglichen somit Wissensvermittlung zu Ihrem Team. Gute Berater machen sich Stück für Stück selbst überflüssig, sodass Ihr Team irgendwann auf eigenen Beinen steht.
• … veranstalten nicht für jedes kleine Problem einen mehrtägigen Workshop, sondern helfen effizient beim Finden einer Lösung.

Vergessen Sie nicht, dass Sie jeden Monat, den Sie nicht als DiGA gelistet sind, kein Geld verdienen, aber dennoch Kosten haben. Daher ist gute Beratung absolut integral für den Erfolg Ihres Produkts.

Unsere Empfehlung:

Seien Sie sich der oben genannten Probleme bewusst und vorsichtig bei der Auswahl Ihrer Berater. Gerne helfen wir Ihnen hier mit unserem Netzwerk und vermitteln Ihnen vertrauenswürdige Berater für Ihre Problemstellung. Sprechen Sie uns einfach kurz über unser Kontaktformular hierzu an.

5. Nutzen Sie das Beratungsangebot des BfArM

In Bezug auf produkt-spezifische DiGA-Fragen sollten Sie mit dem BfArM Kontakt aufnehmen. Versuchen Sie natürlich zuerst, sich die Fragen selbst durch das Studieren des BfArM-Leitfadens und der DiGAV zu beantworten. Einige Fragen sind allerdings so individuell, dass Sie eine fallspezifische Einschätzung des Prüfers (dem BfArM) benötigen.

Zögern Sie also nicht, eine kostenpflichtige Beratung beim BfArM hierfür zu buchen. Wenn Sie Ihre Fragen gut vorbereitet haben, bekommen Sie so wichtige Antworten, die über den Erfolg Ihrer Listung im Verzeichnis entscheiden können.

Aber Vorsicht!
Wartezeiten für Beratungsgespräche mit dem BfArM sind teilweise enorm lang. Sie sollten ggf. damit rechnen, dass Sie mindestens 6 Monate auf einen Termin warten müssen.

Unsere Empfehlung:

Der BfArM-Leitfaden, sowie die Zusammenarbeit mit Beratern wird Ihnen den Großteil Ihrer Fragen beantworten. Für produktspezifische Schlüsselfragen sollten Sie sich jedoch an das BfArM wenden, um Überraschungen im Prüfprozess zu vermeiden.

6. Visieren Sie Risikoklasse I an

Aktuell herrscht weiterhin Unsicherheit, ob es unter MDR in Zukunft noch Software-Medizinprodukte der Risikoklasse I geben wird. Die aktuelle Situation (Stand 2026) beschreiben wir in unserem Fachartikel hier.

Kurz zusammengefasst: Es existiert eine gesetzliche Grauzone mit Interpretationsspielraum. In vielen Bundesländern ist aktuell aber weiterhin eine Zulassung unter Risikoklasse I möglich.

Bisher sind zum Beispiel fast alle unter MDR zugelassenen Anwendungen im DiGA-Verzeichnis der Risikoklasse I zugeordnet. In unserem DiGA-Verzeichnis für Hersteller können Sie sich darüber einen konkreten Überblick verschaffen.

Ob auch Ihr Medizinprodukt in die Risikoklasse I fällt, hängt von verschiedenen Faktoren ab. Lesen Sie dafür den oben erwähnten Artikel.

Generell geht mit einer Software der Risikoklasse IIa erheblicher Mehraufwand und Zusatzkosten für die Zertifizierung mit einer Benannten Stelle einher. Es kann sich lohnen, die Anwendung und vor allem die Zweckbestimmung so zu definieren, dass Ihr Produkt unter die Risikoklasse I fällt.

Uns ist natürlich vollkommen klar, dass eine entsprechende Änderung am Konzept nicht für jedes Produkt möglich ist. Da es aber insbesondere bei Produkten, die von Patienten verwendet werden, durchaus häufig funktionieren kann, lohnt es sich unter Umständen, über diesen Punkt nachzudenken.

Gerne beraten wir Sie hierzu und evaluieren, ob Risikoklasse I für Ihr Produkt klappen könnte.

Unsere Empfehlung:

Definieren Sie die Zweckbestimmung Ihrer Anwendung so, dass eine Klassifizierung nach Risikoklasse I potenziell möglich ist. Ab Risikoklasse IIa kommt erheblich mehr Aufwand auf Sie zu. Im Notfall können Sie Ihr Produkt später noch auf Risikoklasse IIa hochstufen und sich hierfür eine benannte Stelle suchen.

7. Verwenden Sie existierenden Code zur Umsetzung der ePA- und GesundheitsID-Anbindung

Die Anbindung an die elektronische Patientenakte (ePA) und die GesundheitsID kann eine erhebliche Herausforderung darstellen – insbesondere für Unternehmen, die sich erstmals mit diesen Schnittstellen auseinandersetzen. Die technischen Spezifikationen sind komplex, und die offizielle Dokumentation ist umfangreich und teils schwer verständlich.

Doch es gibt Abkürzungen: Statt sich mühsam durch die Spezifikationen zu arbeiten und eine eigene Implementierung von Grund auf zu entwickeln, lohnt es sich, auf existierenden Code und technische Beratung zurückzugreifen. Wer mit einem Partner zusammenarbeitet, der bereits Erfahrung mit der Integration hat, spart nicht nur Entwicklungsaufwand, sondern reduziert auch das Risiko von Implementierungsfehlern.

Unsere Empfehlung:

Nutzen Sie bestehende Implementierungen und das Know-how erfahrener Partner, um die ePA- und GesundheitsID-Anbindung effizient umzusetzen. So vermeiden Sie langwierige Trial-and-Error-Phasen und können sich schneller auf die eigentliche Entwicklung Ihres Produkts konzentrieren.

QuickBird Medical bietet sowohl wiederverwendbare technische Komponenten als auch technische Beratung hierfür an. Mehr Informationen finden Sie hier.

Sechs weitere DiGA-Tipps erhalten Sie in unserem Whitepaper…

Alle weiteren Tipps rund um die Zulassung und Zertifizierung finden Sie in unserem DiGA-Whitepaper. Einfach über das Formular downloaden.

Fazit

Erhöhen Sie die Erfolgswahrscheinlichkeit Ihrer DiGA

Die Entwicklung einer DiGA ist durch die regulatorischen Hürden kein Unterfangen, das unterschätzt werden sollte. Mit guter Planung und der richtigen Beratung stehen die Chancen jedoch gut, dass Sie die Zulassung in das DiGA-Verzeichnis schaffen. Wir hoffen, dass Ihnen die obigen Empfehlungen für die Zulassung ihrer DiGA helfen, unnötigen Aufwand und potenzielle Risiken zu vermeiden.

Weitere Informationen zu Themen wie dem DiGA-Zulassungsprozess, dem Nachweis des positiven Versorgungseffekts und der Preisverhandlung finden Sie auch in unserem DiGA- und Medical Software-Blog.

The post 13 Tipps für die Zulassung von DiGA in 2026 appeared first on QuickBird Medical.

Die EU-Kommission hat nun am 16. Dezember 2025 einen Änderungsvorschlag zur Medical Device Regulation (MDR) veröffentlicht. Unter anderem beinhaltet dieser Änderungsentwurf eine Änderung der berüchtigten Regel 11 zur Klassifizierung von Software-Medizinprodukten.

Die große Frage für Hersteller von digitalen Gesundheitsanwendungen (DiGA) und Medical Software: Welche Software-Produkte fallen unter dem neuen Entwurf in Klasse I, welche in Klasse IIa? 

Eines der Ziele dieses Änderungsvorschlags zur MDR, ist laut EU-Kommission, Innovationen zu fördern. Daher liegt die Annahme nahe, dass im neuen Entwurf jetzt klar geregelt wird, dass Produkte mit niedrigem Risiko auch in Risikoklasse I fallen. Wie Sie weiter unten lesen können, ist dem vermutlich leider nicht so.

Wir haben uns den Entwurf und alle in diesem Bezug relevanten Dokumente im Detail angesehen. In diesem Artikel liefern wir Antworten zur aktuell geplanten Klassifizierung von Software-Medizinprodukten.

Inhaltsverzeichnis

• 1. Aktueller Stand: Klassifizierung von Software-Medizinprodukten
• 2. Geplanter Entwurf: Änderung der Regel 11 für Software-Medizinprodukte
• 3. Interpretationen der MDR-Änderungen zur Risikoklassifizierung
  • 3.1 Interpretation 1: Strenge Auslegung
  • 3.2 Interpretation 2: Wörtliche Auslegung
• 4. Was fällt noch in Risikoklasse I mit dem Draft für Änderungen der MDR?
• 5. Ist dieser Änderungsvorschlag final und wird er so umgesetzt?
• 6. Zeitplan: Ab wann gelten die MDR-Änderungen und die neue Regel 11?
• 7. Weitere Interpretationen
• 8. Fazit

1. Aktueller Stand: Klassifizierung von Software-Medizinprodukten

Bis die geplanten Änderungen in irgendeiner Form in der MDR landen, gelten natürlich die aktuellen Bestimmungen erst einmal weiter. In diesem Zusammenhang haben wir drei detaillierte Leitfäden geschrieben, welche Software-Medizinprodukt-Herstellern bei der Einordnung in eine MDR-Risikoklasse helfen:

1. Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden
2. Klasse I Software nach MDR – Geht das noch?
3. MDR Risikoklasse I vs. IIa: Unterschiede für Software-Medizinprodukte

2. Geplanter Entwurf: Änderung der Regel 11 für Software-Medizinprodukte

Der wohl wichtigste Teil der MDR in Bezug auf die Klassifizierung von Software-Medizinprodukten ist die Regel 11. Diese Regel soll sich nun grundlegend ändern.

Den aktuellen Entwurf für diese Änderung finden Sie hier: Annex zum Proposal for a regulation to simplify rules on medical and in vitro diagnostic devices

Der neue Wortlaut der Regel 11 würde dann wie folgt lauten:

6.3 Rule 11

Software which is intended to generate an output that confers a clinical benefit and is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition is classified as class I, unless the output is intended for a disease or condition:

• in a critical situation with a risk of causing death or an irreversible deterioration of a person’s state of health, in which case it is classified as class III;
• in a serious situation with a risk of causing a serious deterioration of a person’s state of health or a surgical intervention, or to drive clinical management in a critical situation in which cases it is classified as class IIb;
• in a non-serious situation, or to drive clinical management in a serious situation or to inform clinical management in a critical or serious situation in which cases it is classified as class IIa.’;

Gemäß der vorgeschlagenen Regel landet also jede Software zunächst in Klasse I, sofern keine höherklassifizierenden Kriterien greifen. Dies ist eine Umkehrung der bisherigen Logik und klingt aus Herstellersicht erst einmal begrüßenswert. Es klingt beinahe so, als wäre Klasse I eher die Regel als eine Ausnahme bei Software-Medizinprodukten. Bei genauerer Betrachtung lässt sich dieser Eindruck aber nicht unbedingt bestätigen.

3. Interpretationen der MDR-Änderungen zur Risikoklassifizierung

Unser Experten-Team kam bei der Analyse der vorgeschlagenen Regel 11 zu zwei möglichen Auslegungen.

Zur Interpretation der Regel verwenden wir neben dem reinen Wortlaut auch folgende Dokumente:

• MDCG 2019-11 Rev.1: Das quasi-offizielle Guidance-Dokument zur Klassifizierung und Qualifizierung von Software-Medizinprodukten unter der MDR. Hier ist insbesondere die Tabelle in Annex III relevant, in welcher auf die Risikoklassifizierung der IMDRF verwiesen wird.
• IMDRF – Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations: Internationales Rahmenwerk zur risikobasierten Einordnung von SaMD. Es bewertet Software anhand der klinischen Bedeutung der erzeugten Information und der Schwere der medizinischen Situation und bildet die konzeptionelle Grundlage für die Software-Klassifizierung in der MDCG 2019-11.

Diese Dokumente helfen beim Verständnis zentraler Begriffe (z.B. „critical situation“, „drive clinical management“) des MDR-Änderungsvorschlags und beinhalten die unten verwendeten Tabellen.

3.1 Interpretation 1: Strenge Auslegung

Streng genommen kann man die Regel so lesen, dass einfach jede Software, die

• … in einer „critical situation“ verwendet wird, in Klasse III fällt.
• … in einer „serious situation“ verwendet wird, in Klasse IIb fällt.
• … in einer „non-serious situation“ verwendet wird, in Klasse IIa fällt.

Jegliche Ausnahmen (z.B. „to drive clinical management in a critical situation […] is classified as class IIb“) werden bei dieser Auslegung nicht berücksichtigt. Laut MDR gilt bezüglich der Klassifizierung nämlich immer die strengste anwendbare (Sub-)Regel. Demnach könnte man die neue Regel so auslegen, dass immer die allgemeine Regel zur Einordnung in die höhere Risikoklasse greift.

Gemäß dieser Auslegung würde man zu folgender Einstufung der Risikoklassen kommen:

Änderungsvorschlag der MDR-Regel 11 – Tabelle zur Einstufung der Risikoklassen mit strenger Auslegung

Wie Sie sehen, fehlt hier die Risikoklasse I komplett. Es gibt keine offensichtliche Argumentation, um Software in diesem Fall noch der Klasse I zuzuordnen.

Diese Auslegung scheint uns aber sehr unwahrscheinlich, da der Wortlaut der Regel 11 in diesem Fall sehr viel einfacher sein könnte und sich die EU-Kommission bestimmt etwas bei den Ausnahmen und Zusätzen gedacht hat. Rechtlich gesehen ist auch fraglich, ob man die Unterpunkte der Regel 11 als „Unterregeln“ im Sinne der MDR-Durchführungsvorschrift 3.5 bezeichnen kann (wonach quasi immer die strengste Unterregel zu Klassifizierung anzuwenden ist).

3.2 Interpretation 2: Wörtliche Auslegung

Man könnte die Regel zunächst genauso wie oben auslegen. Berücksichtigt man dann zusätzlich die explizit genannten Ausnahmen (z.B. “to drive clinical management in a critical situation […] it is classified as class IIb”), kommt man exakt zu der Tabelle in der MDCG 2019-11 Rev.1.

Gemäß dieser Auslegung würde man zu folgender Einstufung der Risikoklassen kommen:

Änderungsvorschlag der MDR-Regel 11 – Tabelle zur Einstufung der Risikoklassen mit wörtlicher Auslegung

Diese Auslegung ist sehr wahrscheinlich, denn sie würde bedeuten, dass die EU-Kommission versucht hat, die bereits veröffentlichte Tabelle im MDCG-Dokument in einen Gesetzestext zu übersetzen. Interessanterweise kam unser Team durch unsere eigene Analyse der vorgeschlagenen Regel-11-Änderung zu exakt der Tabelle im MDCG-Dokument, ohne sich an dieser zu orientieren.

Wie Sie sehen, fehlt aber auch hier die Risikoklasse I in der Zuordnung. Man müsste daher schon sehr kreativ mit der Argumentation werden, um noch Wege für Software nach Risikoklasse I zu finden.

4. Was fällt noch in Risikoklasse I mit dem Draft für Änderungen der MDR?

Die vorgeschlagene Änderung ist insbesondere für Hersteller von Produkten der Klasse I relevant, die Produkte herstellen, die nur zur Anwendung durch Patienten (medizinische Laien) bestimmt sind. Dazu gehören viele digitale Gesundheitsanwendungen (DiGA) und andere Digital Therapeutics (DTx).

Das aktuell populärste Argument dieser Hersteller zielt auf einen besonderen Wortlaut in der aktuellen MDR ab: „Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa, […] Sämtliche andere Software wird der Klasse I zugeordnet.“  – Hersteller argumentieren hier, dass ein Patient als medizinischer Laie keine diagnostischen oder therapeutischen Entscheidungen treffen kann. Mehr dazu lesen Sie in unserem Artikel: Klasse I Software nach MDR – Geht das noch?

In der geänderten Regel 11 gibt es diesen Wortlaut aber nicht mehr, wodurch die Rechtfertigung für Risikoklasse I für viele Hersteller nicht mehr ganz einfach werden könnte. Im Gegenteil, durch die Nutzung der Begriffe der MDCG im Gesetzestext (z.B. „Situation or patient condition“ und „Significance of information“) könnten auch deren Definitionen der IMDRF mehr Relevanz bekommen. Dort werden Laien als Nutzer des Medizinprodukts explizit in der Definition einer non-serious oder serious situation inkludiert. Somit würden auch Anwendungen für Laien mindestens in Klasse IIa fallen.

Für uns wäre es denkbar, dass sich dadurch die Diskussion um Begrifflichkeiten verschiebt zu

• Was bedeutet „Clinical Management“?
• Was ist eine Situation, die weder „critical“, „serious“, noch „non-serious“ ist?

Wenn Sie einen Prüfer in Zukunft von der Einordnung in Klasse I überzeugen möchten, müssten Sie daher entweder argumentieren, dass

1. die Signifikanz der von der App gelieferten Information nicht einmal „low“ ist oder
2. der Zustand des Patienten nicht einmal „non-serious“ ist.

Sie würden durch diese Argumentation quasi die existierende Tabelle um eine Spalte und Reihe erweitern:

Änderungsvorschlag der MDR-Regel 11 – Mögliche Wege in Klasse I

Es ist gut argumentierbar, dass Primärpräventionsanwendungen weiterhin in Klasse I fallen. Für jegliche therapiebegleitende App wird das Eis aber dünn und es ist nicht offensichtlich, wie hierfür noch eine Klasse-I-Argumentation erreicht werden kann.

Zumindest dann, wenn der Entwurf der MDR-Änderung wirklich so umgesetzt wird. Das ist aber alles andere als sicher und Adaptionen sind zu erwarten. Das bringt uns zu unserem nächsten Punkt:

5. Ist dieser Änderungsvorschlag final und wird er so umgesetzt?

Nein. Der vorgeschlagene Wortlaut der neuen Regel 11 ist aktuell lediglich ein Entwurf. Es handelt sich um eine frühe Version im europäischen Gesetzgebungsverfahren. Erfahrungsgemäß werden solche Entwürfe im weiteren Verlauf fachlich und politisch überarbeitet. Gerade bei komplexen Themen wie Software-Klassifizierung sind Änderungen sehr wahrscheinlich. Wir gehen daher aktuell nicht davon aus, dass die Regel 11 in dieser Form unverändert in den finalen Gesetzestext übernommen wird.

6. Zeitplan: Ab wann gelten die MDR-Änderungen und die neue Regel 11?

An dieser Stelle ist zu betonen, dass eine Änderung einer EU-Verordnung meist mehrere Jahre dauert. Daher rechnen wir frühestens im Jahr 2027 mit einer gültigen Revision der MDR (Stand Januar 2026). Auch dies ist eher optimistisch und der Prozess dauert ggf. noch länger.

Jedes Proposal für eine Änderung einer EU-Verordnung wird vor Verabschiedung einem mehrstufigen Prozess unterzogen:

1. Gesetzgebungsvorschlag (Legislative Proposal): Die Europäische Kommission erarbeitet einen formellen Verordnungsentwurf und legt diesen dem Europäischen Parlament und dem Rat der EU zur Prüfung vor.
2. Erste Lesung (First Reading): Das Europäische Parlament und der Rat befassen sich erstmals mit dem Vorschlag, können Änderungsanträge einbringen und versuchen, eine gemeinsame Position zu finden.
3. Zweite Lesung (Second Reading): Kommt es in der ersten Lesung zu keiner Einigung, folgt eine zweite Prüfung durch Parlament und Rat, bei der weitere Änderungen möglich sind oder der Vorschlag abgelehnt werden kann.
4. Vermittlungsverfahren (Conciliation): Können sich Parlament und Rat weiterhin nicht einigen, wird ein Vermittlungsausschuss eingesetzt, der innerhalb einer festen Frist einen gemeinsamen Kompromisstext ausarbeitet.
5. Dritte Lesung (Third Reading): Der im Vermittlungsverfahren ausgehandelte Text wird abschließend sowohl vom Europäischen Parlament als auch vom Rat angenommen oder verworfen. Erst danach kann die Verordnung in Kraft treten.

Der gesamte Prozess wird hier im Detail beschrieben.

Wir beobachten die weiteren Entwicklungen eng und aktualisieren diesen Artikel laufend. Über relevante Änderungen informieren wir in unserem Newsletter.

7. Weitere Interpretationen

Es gibt weitere Wege, den vorgeschlagenen Wortlaut der Regel 11 zu interpretieren. Fakt ist aber, dass dieser Wortlaut vermutlich nach entsprechenden Revisionen nicht genau so in der MDR landen wird. Demnach ist eine Auflistung jeder noch so unwahrscheinlichen Interpretationsmöglichkeit zum aktuellen Zeitpunkt bislang nicht zielführend.

8. Fazit

Der Änderungsvorschlag der Regel 11 erscheint uns nach der obigen Auslegung gravierend. Die meisten Software-Medizinprodukte der Klasse I würden mit der neuen Regel sehr klar in Klasse IIa (oder höher) fallen, was für viele Hersteller ein ernst zu nehmendes Problem wäre. Ob das mit Absicht ist, zweifeln wir aktuell stark an. Das würde dem erklärten Ziel der Innovationsförderung komplett widersprechen.

Auch erscheint uns die aktuelle Formulierung der Regel 11 fachlich inkonsistent. Insbesondere fehlt eine klare und nachvollziehbare Abbildung von Software mit sehr niedrigem Risiko, wie sie beispielsweise in der von der IMDRF vorgeschlagenen 3×3-Risikomatrix vorgesehen ist. Dort ist explizit eine Kategorie für geringfügige klinische Auswirkungen vorgesehen, die sachlich einer Klasse-I-Einstufung entsprechen würde. Diese Differenzierung geht im aktuellen Entwurf verloren. Daher gehen wir davon aus, dass dies ein unbeabsichtigter Fehler ist und in den kommenden Änderungen des Entwurfs noch angepasst wird.

Kategorien für Software as a Medical Device (SaMD) von der IMDRF

Generell blicken wir weiterhin hoffnungsvoll in die Zukunft: Der aktuelle Draft existiert nur in einer ersten Version. Bis so eine Änderung einer EU-Verordnung passiert, stehen noch mehrere formale Schritte im europäischen Gesetzgebungsverfahren an.

Erfahrungsgemäß wird der Wortlaut in diesem Prozess weiter angepasst und präzisiert. Dass der aktuelle Entwurf der MDR-Änderung so final in der Verordnung landet, ist unwahrscheinlich.

Wir halten Sie hierzu in unserem Newsletter auf dem neuesten Stand.

The post Änderungsentwurf der MDR (2025): Implikationen für Klasse I-Software appeared first on QuickBird Medical.

„Da wurde doch letztens eine Ärztin in der Süddeutschen interviewt! Die hat eindeutig gesagt, dass Mindfulness-Apps bei Depressionen helfen. Darauf können wir uns doch berufen, oder?“

So einfach ist das leider nicht. Unser überspitztes Beispiel würde die Aufsichtsbehörde oder eine benannte Stelle natürlich nicht überzeugen, denn die Medical Device Regulation (MDR) verlangt für Medizinprodukte ausführliche klinische Evidenz. Selbstverständlich sind auch Software-Medizinprodukte davon nicht ausgenommen.

In diesem Artikel erfahren Sie, welche Dokumente mit welchen Inhalten Sie erstellen müssen und wie Sie um das Schreckensgespenst einer klinischen Prüfung herumkommen können.

Gut zu wissen:

In diesem Artikel (wie auch in der MDR) werden zwei Begriffe voneinander unterschieden: klinische Bewertung (clinical evaluation) und klinische Prüfung (clinical investigation). Die klinische Bewertung umfasst die gesamte Sammlung klinischer Evidenz für ein Medizinprodukt. Dazu zählt die Planung der Suche klinischer Daten, dessen Durchführung und regelmäßige Aktualisierung. Die klinische Prüfung hingegen ist eine wichtige Quelle für ebenjene klinische Evidenz – und in den meisten Fällen mit sehr viel Aufwand verbunden, da Sie hier eine eigene Studie durchführen müssen.

Fokus dieses Artikels

Der Artikel fokussiert sich auf die klinische Bewertung von Medizinprodukten nach MDR. Das Hauptaugenmerk liegt dabei auf Software-Medizinprodukten, jedoch sind die meisten Inhalte auch auf andere Medizinprodukte übertragbar. Zudem verraten wir Ihnen, wie Sie im besten Fall sogar auf eine klinische Prüfung verzichten können.

Die Informationen in diesem Artikel stammen aus der MDR, der MEDDEV 2.7/1 revision 4, sowie verschiedenen MDCG Guidance Dokumenten und werden hier zusammengefasst.

Zusätzlich werfen wir in Kapitel 5 einen Blick in die Zukunft und gehen kurz auf den neuen Norm-Entwurf ISO 18969 ein, der als kommender internationaler Standard die klinische Bewertung über den gesamten Produktlebenszyklus hinweg harmonisieren soll.

Inhalte

• 1. Ziel der klinischen Bewertung
• 2. Welche Dokumente erfordert die MDR?
  • 2.1 Klinischer Bewertungsplan (Clinical evaluation plan)
  • 2.2 Bericht über die klinische Bewertung (Clinical evaluation report)
  • 2.3 Klinische Nachbeobachtung nach dem Inverkehrbringen (Plan und Bericht)
• 3. Muss ich eine klinische Bewertung durchführen (auch bei Klasse I)?
  • 3.1 Wie man gleichartige Produkte unter der MDR findet
  • 3.2 Wenn man kein gleichartiges Produkt findet
• 4. Muss ich die klinische Bewertung selbst erstellen?
• 5. Ein Blick in die Zukunft: Die neue ISO 18969
• 6. Hilfreiche Quellen
• 7. Fazit

1. Ziel der klinischen Bewertung

Das fundamentale Ziel der klinischen Bewertung ist der Beweis, dass ein Medizinprodukt die vom Hersteller definierte Zweckbestimmung erfüllt. Dabei sollen die angegebenen Leistungs- und Sicherheitsanforderungen nachgewiesen und unerwünschte Nebenwirkungen ausgeschlossen werden.

Zum Teil deckt sich dieses Ziel auch mit dem Risikomanagement, bei dem potenzielle Gefahren, die vom Produkt ausgehen, analysiert werden. Wenn man so will, findet die Symbiose von Risikomanagement und klinischer Bewertung in der Nutzen-Risiko-Abwägung statt.

Eine fundierte klinische Bewertung ist notwendig, damit man die Restrisiken dem evidenzbasierten Nutzen gegenüberstellen und bewerten kann.

2. Welche Dokumente erfordert die MDR?

Wenn Sie sich mit Regulatorik von Medizinprodukten eine Zeit lang beschäftigen, ist es nichts Neues mehr, dass fast alles, was ein Hersteller macht, auch festgehalten werden muss.

Auch bei der klinischen Bewertung hat die MDR klare Vorgaben, welche Dokumente vom Hersteller erstellt und gepflegt werden müssen. Diese Vorgaben sind zum Teil jedoch sehr abstrakt und werden durch eine Handvoll Guidance-Dokumente (z. B. MDCG) ergänzt.

Wir möchten in diesem Kapitel die Inhalte der vier Dokumente erläutern, die in Ihrer technischen Dokumentation enthalten sein müssen:

1. Klinischer Bewertungsplan (Clinical evaluation plan bzw. CEP)
2. Bericht über die klinische Bewertung (Clinical Evaluation Report bzw. CER)
3. Plan zur klinischen Nachbeobachtung nach dem Inverkehrbringen (Post-market clinical follow-up plan bzw. PMCF plan)
4. Bericht über die klinische Nachbeobachtung nach dem Inverkehrbringen (Post-market clinical follow-up report bzw. PMCF report)

Erforderliche Dokumente für die technische Dokumentation gemäß MDR

2.1 Klinischer Bewertungsplan (Clinical evaluation plan)

Der klinische Bewertungsplan ist das erste Dokument, das im Zuge der klinischen Bewertung erstellt wird. Er beschreibt – wie der Name schon sagt – die geplanten Aktivitäten während der klinischen Bewertung, sowie Anleitungen zur Suche klinischer Daten und Kriterien für deren Bewertung.

Betrachten wir am besten die einzelnen Anforderungen der MDR an den klinischen Bewertungsplan, um ein klareres Bild von den Informationen zu bekommen, die enthalten sein müssen. Diese finden sich in Anhang XIV Teil A Punkt 1 Buchstabe a) der MDR. Untenstehend listen wir jede der dort genannten Anforderungen für einen klinischen Bewertungsplan auf und gehen jeweils kurz darauf ein:

„Bestimmung der grundlegenden Sicherheits- und Leistungsanforderungen, die mit relevanten klinischen Daten zu untermauern sind;“

• Werfen Sie einen Blick in den Anhang I der MDR, um die grundlegenden Sicherheits- und Leistungsanforderungen für Ihr Produkt zu identifizieren. Im Anschluss überprüfen Sie, für welche Anforderungen noch klinische Daten benötigt werden. Die grundlegenden Sicherheits- und Leistungsanforderungen beschreiben alle Anforderungen, die ein Medizinprodukt erfüllen muss. Beispiele hierfür sind Vorgaben an die chemische Zusammensetzung und das Labeling. Wie Sie schon erkennen können, ist nicht jede Anforderung für jedes Produkt zutreffend. Gerade auf reine Softwareprodukte können viele Anforderungen nicht angewandt werden. Es liegt beispielsweise auf der Hand, dass Themen wie „chemische, physikalische und biologische Eigenschaften“ oder „Schutz vor Strahlung“ für Software-Code wenig Relevanz haben. Andere Anforderungen hingegen, wie die ausreichende Genauigkeit von Messfunktionen oder die Fähigkeit zur Erfüllung der Zweckbestimmung bei der Anwendung durch Laien könnten für Softwareprodukte durch klinische Daten untermauert werden.

„Spezifizierung der Zweckbestimmung des Produkts;“

• Vermutlich haben Sie bereits eine Zweckbestimmung für Ihr Produkt geschrieben. Falls nicht, sollten Sie sich schleunigst damit befassen! Die Zweckbestimmung wird Ihnen bei der Entwicklung eines Medizinprodukts noch häufiger über den Weg laufen. Diese ist unter anderem auch der entscheidende Faktor, wenn es um die Bestimmung der Risikoklasse geht und legt fest, welchen Sinn Ihr Produkt überhaupt hat. Eine frühzeitige Definition hilft also nicht nur bei der klinischen Bewertung. Eine Anleitung zur Formulierung der Zweckbestimmung finden Sie in diesem Artikel: Formulierung der Zweckbestimmung für (Software-)Medizinprodukte

„Genaue Spezifizierung der vorgesehenen Zielgruppen mit klaren Indikationen und Kontraindikationen;“

• Dieser Punkt ist fast selbsterklärend, bedenken Sie aber bei der Spezifizierung der Zielgruppen auch verschiedene Anwendergruppen. Beispielsweise wird Ihre Software von Medizinern verwendet und nicht nur von Patienten. Zusätzlich kann es hilfreich sein, neben der Indikation auch weitere Parameter zur Eingrenzung der Zielgruppe heranzuziehen (z.B. Alter, Sprachkenntnisse, etc.). Berücksichtigen Sie auch die Liste in Appendix A3 der MEDDEV-2.7/1 revision 4, um relevante Einschlusskriterien zu identifizieren.

„Detaillierte Beschreibung des angestrebten klinischen Nutzens für die Patienten, mit relevanten konkreten Parametern für das klinische Ergebnis;“

• Die MDR definiert den klinischen Nutzen folgendermaßen: „Klinischer Nutzen“ bezeichnet die positiven Auswirkungen eines Produkts auf die Gesundheit einer Person, die anhand aussagekräftiger, messbarer und patientenrelevanter klinischer Ergebnisse einschließlich der Diagnoseergebnisse angegeben werden, oder eine positive Auswirkung auf das Patientenmanagement oder die öffentliche Gesundheit;
• Ein klinischer Nutzen könnte also sein, dass sich die Lebensqualität eines Menschen verbessert. Im zweiten Schritt stellt sich die Frage, wie dieser Nutzen gemessen werden kann. Hier müssen Sie also einerseits definieren, welchen klinischen Nutzen Ihr Produkt anstrebt und wie Sie planen, diesen Nutzen nachzuweisen. Hierzu liefert der Appendix 7.2 der MEDDEV-2.7/1 revision 4 zusätzlichen Input.
• Der klinische Nutzen beschreibt die erwartete Leistung eines Produkts, welche aus der Zweckbestimmung abgeleitet wird. Er hat die Eigenschaft, dass er klar beobachtbar sein muss. Daher sollten Sie hier konkret messbare Faktoren spezifizieren, wie z.B. „Reduktion depressiver Symptomatik“ oder „Steigerung der Lebensqualität“.

„Spezifizierung der für die Prüfung der qualitativen und quantitativen Aspekte der klinischen Sicherheit anzuwendenden Methoden unter deutlicher Bezugnahme auf die Bestimmung der Restrisiken und Nebenwirkungen;“

• Methoden, die angewandt werden, um die klinische Sicherheit des Produkts, insbesondere auch Restrisiken und Nebenwirkungen zu evaluieren. Entscheidend ist hierbei die Bewertung von gefundenen klinischen Daten. Dazu zählt unter anderem, welche Datenbanken Sie durchsuchen möchten, welche Suchfilter Sie anwenden und nach welchen Kriterien Sie gefundene Quellen bewerten. Beispielsweise sollte aus Ihrem Dokument hervorgehen, dass eine randomisierte kontrollierte Studie mehr Aussagekraft hat als ein Experteninterview. Kapitel 9.3.2. Der MEDDEV-2.7/1 revision 4 liefert hilfreiche Informationen zur Bewertung der Relevanz von Quellen. Eine spannende Liste an Bewertungskriterien für Studien finden Sie im Appendix 6 dieses Dokuments. Diese umfasst beispielsweise die Stichprobengröße und die Offenlegung der angewandten Methoden.

„Nichterschöpfende Liste und Spezifizierung der Parameter zur auf dem neuesten medizinischen Kenntnisstand beruhenden Bestimmung der Vertretbarkeit des Nutzen-Risiko-Verhältnisses für die verschiedenen Indikationen und die Zweckbestimmung bzw. Zweckbestimmungen des Produkts;“

• Hier werden die Parameter spezifiziert, um die Vertretbarkeit des Nutzen-Risiko-Verhältnisses zu bewerten. Wichtig ist es hierbei, den aktuellen medizinischen Kenntnisstand mit einzubeziehen und auch die Wirksamkeit und Risiken anderer Methoden zu berücksichtigen.

„Angabe, wie Fragen hinsichtlich des Nutzen-Risiko-Verhältnisses für bestimmte Komponenten wie die Verwendung pharmazeutischer, nicht lebensfähiger tierischer oder menschlicher Gewebe zu klären sind […];“

• Dieser Punkt kann von Software-Herstellern ignoriert werden.

„Klinischer Entwicklungsplan: von explorativen Studien, wie Studien zur Erstanwendung am Menschen („First-in-man“-Studien), Durchführbarkeitsstudien und Pilotstudien bis hin zu Bestätigungsstudien, wie pivotale klinische Prüfungen, und einer klinischen Überwachung nach dem Inverkehrbringen gemäß Teil B dieses Anhangs, unter Angabe von Etappenzielen und Beschreibung möglicher Akzeptanzkriterien;“

• Der klinische Entwicklungsplan umfasst alle Schritte, die zur Sammlung und Schaffung klinischer Daten geplant sind. Gemeint sind hierbei insbesondere wissenschaftliche Untersuchungen, die Sie zu Ihrem Produkt planen.
• Im klinischen Entwicklungsplan werden auch geplante klinische Prüfungen angegeben und auf die entsprechenden Dokumente wird verwiesen.
• Auch eine geplante Literaturrecherche wird unter diesem Punkt abgebildet.

Wenn Sie planen, die klinische Bewertung unter Bezugnahme auf ein oder mehrere gleichartige Produkte durchzuführen, können Sie in diesem Plan auch schon die Produkte listen, welche auf Gleichartigkeit untersucht werden. Die Gleichartigkeit wird im Bericht über die klinische Bewertung demonstriert.

2.2 Bericht über die klinische Bewertung (Clinical evaluation report)

Nachdem der klinische Bewertungsplan das zentrale Vorgehen bei der klinischen Bewertung beschreibt, enthält der Bericht alle daraus resultierenden Daten, die zur klinischen Bewertung herangezogen werden. Er resultiert sozusagen aus dem klinischen Bewertungsplan und enthält eine Aussage dazu, ob Ihr Produkt seine Zweckbestimmung und grundlegende Sicherheits- und Leistungsanforderungen erfüllt (einen Leitfaden zur Formulierung Ihrer Zweckbestimmung finden Sie in diesem Artikel).

Ganz konkret sollte Ihr Bericht über die klinische Bewertung folgenden Anforderungen genügen (Appendix A10, MEDDEV-2.7/1 revision 4):

• Der Bericht muss für Drittparteien verständlich sein und die klinischen Daten so zusammenfassen, dass Ihre Aussagen und Schlussfolgerungen nachvollziehbar sind.
• Die vom Hersteller erzeugten Daten (z.B. Ergebnisse einer klinischen Prüfung) müssen zusammengefasst und referenziert sein.
• Beim Vergleich mit gleichartigen Produkten:
  • Die Gleichartigkeit beider Produkte muss nachvollziehbar beschrieben werden.
  • Alle Unterschiede zwischen Ihrem Produkt und dem gleichartigen Produkt müssen beschrieben werden. Zusätzlich benötigen Sie eine Erklärung, warum die Produkte dennoch als gleichartig zu betrachten sind.
• Der aktuelle Stand der Technik muss vollständig zusammengefasst und mit Literatur untermauert sein. Stand der Technik? Schon wieder ein Begriff, bei dem uns die MDR mit einer eindeutigen Definition im Stich lässt. Zum Glück gibt es eine nähere Spezifikation in der ISO 14971, wonach der Stand der Technik die gegenwärtig und allgemein anerkannte gute Praxis bei Technologie und Medizin umfasst. Es handelt sich also nicht um die technologisch und wissenschaftlich fortgeschrittensten Methoden, sondern um jene Produkte, Behandlungsmethoden, etc., welche in der Praxis bereits Anwendung finden und am Markt erhältlich sind.
• Der Bericht muss eine Erklärung beinhalten, warum das Nutzen-Risiko-Verhältnis in Bezug auf den Stand der Technik akzeptabel ist.
• Falls es Ihr Produkt in mehrfacher Ausführung gibt, müssen Sie erklären, dass die klinischen Daten für alle Varianten und Nutzergruppen ausreichend sind.
• Die Konformität mit allen zutreffenden Sicherheits- und Leistungsanforderungen muss bestätigt werden.
• Der Bericht muss eine Aussage darüber enthalten, dass das von Ihnen bereitgestellte Informationsmaterial auch mit den Inhalten des Berichts übereinstimmt.
• Alle verbleibenden Risiken und unbeantworteten Fragen, müssen gelistet werden. Diese müssen dann in der Überwachung nach dem Inverkehrbringen (Post-Market Surveillance) adressiert werden.
• Der Bericht muss ein Datum haben und die Lebensläufe (oder andere Qualifikationsnachweise) der beteiligten Personen enthalten. Zudem benötigen Sie eine Interessenerklärung aller Beteiligten. Lassen Sie den finalen Bericht am besten von allen unterschreiben.

2.3 Klinische Nachbeobachtung nach dem Inverkehrbringen (Plan und Bericht)

Die klinische Bewertung vor dem Markteintritt eines Produkts ist nur eine Momentaufnahme und bildet den aktuellen Kenntnisstand ab – dieser kann sich bekanntlich ändern. Beispielsweise führen Mediziner heute keinen Aderlass mehr durch und verzichten auf den Einsatz von Zigaretten bei Kopfschmerzpatienten. Doch diese Maßnahmen zählten irgendwann einmal zum aktuellen medizinischen Kenntnisstand. Deren schwerwiegende Folgen wurden erst über die Zeit erkannt.

Als Hersteller eines Medizinprodukts müssen Sie also sicherstellen, dass neue Erkenntnisse aus der Forschung und spezifisch zu Ihrem Produkt entdeckt werden – und dafür schreibt die MDR die „Klinische Nachbeobachtung nach dem Inverkehrbringen“ vor. Im Englischen heißt diese „Post-market clinical follow-up“ und lässt sich mit PMFC abkürzen.

Die PMCF beschreibt das kontinuierliche Sammeln und Analysieren klinischer Daten, die mit Ihrem Produkt in Verbindung stehen. Auch hier sollen Sie einen Plan und einen Bericht anfertigen.

Der PMCF-Plan leitet sich aus dem klinischen Bewertungsplan und den offenen Fragen und Unklarheiten aus dem Bericht über die klinische Bewertung ab. Er beschreibt – ähnlich wie der klinische Bewertungsplan – die geplanten Aktivitäten in der PMCF-Phase und viele Inhalte können auch eins zu eins übernommen werden.

Hierzu zählt zum Beispiel:

• Literaturrecherche in wissenschaftlichen Datenbanken
• Durchsuchung von Sicherheitsdatenbanken (z.B. BfArM safety database)
• Auswertung von Nutzerfeedback
• Durchführung von Studien zum Produkt

Der PMCF-Plan definiert auch, in welchem Intervall diese Aktivitäten stattfinden. In jedem Zyklus wird dann ein PMCF-Bericht erstellt, in dem die jeweiligen Ergebnisse dokumentiert und deren Auswirkungen auf den Bericht über die klinische Bewertung beschrieben werden.

Wichtig: Relevante Erkenntnisse aus dem PMCF-Bericht werden in den Bericht über die klinische Bewertung integriert. Außenstehende sollen in diesem Bericht über die klinische Bewertung also jederzeit das gesamte Wissen zum Produkt finden können – von der initialen Bewertung bis zum letzten PMCF-Zyklus.

Für die PMCF-Dokumente stellt die MDCG wertvolle Vorlagen bereit, an denen Sie sich orientieren können: MDCG 2020-7 für den Plan und MDCG 2020-8 für den Bericht.

Unterschied zwischen PMCF und Post-Market-Surveillance

Praktisch gesehen ist die PMCF Teil der Überwachung nach dem Inverkehrbringen (Post-Market Surveillance (PMS)). Bei der PMS geht es in erster Linie darum, kontinuierlich zu überwachen, ob ein Medizinprodukt seinen gewünschten Zweck erfüllt und sicher ist. Relevante Informationen können aus verschiedenen Quellen stammen, wie etwa aus direktem User Feedback oder der Auswertung von Nutzungsdaten. Wenn Ihre PMCF ausschließlich auf Literatur basiert, kann man sie als Subset von PMS betrachten. Eine Unterscheidung der beiden Begriffe ist insbesondere dann sinnvoll, wenn im Zuge der PMCF auch klinische Prüfungen und andere Studien durchgeführt werden.

3. Muss ich eine klinische Bewertung durchführen (auch bei Klasse I)?

Ja, eine klinische Bewertung muss in jedem Fall durchgeführt werden und ist für alle Medizinprodukte – auch für Risikoklasse I – verpflichtend.

Der Aufwand, den man für die klinische Bewertung einrechnen muss, kann sich allerdings gravierend unterscheiden. Teilt man die klinische Bewertung in einzelne Arbeitspakete auf, merkt man schnell, dass es einen besonders großen Block gibt – die klinische Prüfung.

MDR-Definition: „Klinische Prüfung“ bezeichnet eine systematische Untersuchung, bei der ein oder mehrere menschliche Prüfungsteilnehmer einbezogen sind und die zwecks Bewertung der Sicherheit oder Leistung eines Produkts durchgeführt wird;

Konkret handelt es sich bei der klinischen Prüfung um eine wissenschaftliche Untersuchung, die beim BfArM angemeldet werden muss. Es ist klar, dass dies oft mit enormen Kosten und erheblichem Zeitaufwand verbunden ist. Das Ganze kann aber unter Umständen sogar vermieden werden. Wenn es ein sogenanntes gleichartiges Medizinprodukt gibt, welches Ihrem Produkt derart ähnlich ist, dass Sie sich auch auf die Daten dieses Produkts berufen können, kommt man um die klinische Prüfung herum. Konkret kann dies eine Zeitersparnis von mehreren Monaten bedeuten – ganz zu schweigen von den Kosten.

3.1 Wie man gleichartige Produkte unter der MDR findet

Vermutlich geht es Ihnen nun, wie den meisten Herstellern und Sie stellen sich die Frage, ob es in Ihrem Fall ein geeignetes Produkt gibt, das bereits als Medizinprodukt am Markt ist und zu dessen klinischen Daten Sie Zugriff haben. Doch wie finden Sie heraus, ob eine Gleichartigkeit besteht?

Dafür benennt die MDR konkrete Kriterien zum Abgleich der Gleichartigkeit zweier Produkte:

Technisch: Das Produkt ist von ähnlicher Auslegung, wird unter ähnlichen Anwendungsbedingungen angewandt, hat ähnliche Spezifikationen und Eigenschaften einschließlich […] Software-Algorithmen, verwendet gegebenenfalls ähnliche Bereitstellungsmethoden und hat ähnliche Funktionsgrundsätze und entscheidende Leistungsanforderungen.

Biologisch: Ist für Software irrelevant.

Klinisch: Das Produkt wird unter der gleichen klinischen Bedingung oder zum gleichen klinischen Zweck, einschließlich eines ähnlichen Schweregrads und Stadiums der Krankheit, an der gleichen Körperstelle und bei ähnlichen Patientenpopulationen in Bezug auf u.a. Alter, Anatomie und Physiologie angewandt, hat die gleichen Anwender und erbringt eine ähnliche, maßgebliche und entscheidende Leistung im Hinblick auf die erwartete klinische Wirkung für eine spezielle Zweckbestimmung.

Kriterien für die Gleichartigkeit gemäß MDR

Für Software-Hersteller bleiben also zwei Punkte übrig: klinische und technische Gleichartigkeit. Die klinische Gleichartigkeit ist vergleichsweise einfach zu überprüfen. Ein Blick in die Zweckbestimmung oder Bedienungsanleitung anderer Anwendungen sollte hier bereits einen guten Aufschluss geben. Je nachdem, in welchem Entwicklungsstadium das eigene Produkt ist, können Hersteller hier auch z.B. noch Anpassungen bei ihrem Produkt oder der angestrebten Zielgruppe vornehmen, um Gleichartigkeit zu gewährleisten. Gerade bei einem initialen Markteintritt kann dies durchaus sinnvoll sein.

Bei der Prüfung der technischen Gleichartigkeit wird es allerdings schon schwieriger. Einer der entscheidenden Punkte ist hierbei die Bewertung der Software-Algorithmen. Aber bis wohin wird ein Algorithmus als „ähnlich“ definiert? Müssen zwei Algorithmen den exakt gleichen Softwarecode haben, um gleichartig zu sein? Ist die Auswertung zweier Fragebögen ähnlich, wenn bei beiden ein Summen-Score berechnet wird, selbst wenn sich die Fragen inhaltlich voneinander unterscheiden? Ist der Algorithmus zur Steuerung eines Blutdruckmessgeräts ähnlich wie jener zur Steuerung des Geräts von einem anderen Hersteller?

Fragen über Fragen, die auf Basis der verfügbaren Informationen nur schwer zu beantworten sind. Zumindest gibt es hierzu eine genauere Ausführung in der MDCG 2020-5, welche auch eine hilfreiche Tabelle in Anhang I beinhaltet. Diese besagt, dass es vorrangig um die Funktionsgrundsätze und die Zweckbestimmung geht, wenn man Software-Algorithmen miteinander vergleicht. Glücklicherweise ist es laut MDCG nicht notwendig, eine Äquivalenz des Softwarecodes zu beweisen.

Zitat aus der MDCG 2020-5: „It is the functional principle of the software algorithm, as well as the clinical performance(s) and intended purpose(s) of the software algorithm, that shall be considered when demonstrating the equivalence of a software algorithm. It is not reasonable to demand that equivalence is demonstrated for the software code, provided it has been developed in line with international standards for safe design and validation of medical device software.“ – Achtung: Die MDCG-Dokumente und deren Interpretationen der MDR sind rechtlich nicht bindend. Jedoch gelten sie als die wohl valideste Quelle zur Umsetzung der MDR-Anforderungen.

Ein wichtiger Hinweis an dieser Stelle: Wenn Sie sich auf ein gleichartiges Produkt beziehen, müssen Sie auch einen geeigneten Zugang zu den dazugehörigen klinischen Daten haben. Dabei durchsuchen Sie am besten zuerst wissenschaftliche Datenbanken nach relevanten Veröffentlichungen, oder Sie wenden sich direkt an den Hersteller. Eine relevante Anlaufstelle ist das Deutsche Register Klinischer Studien (DRKS). Das DRKS ist das zentrale Register für klinische Studien in Deutschland und Sie finden dort auch Untersuchungen zu Medizinprodukten.

3.2 Wenn man kein gleichartiges Produkt findet

Sollten Sie kein gleichartiges Produkt finden, gibt es für Sie leider nur eine Antwort: Sie müssen in den sauren Apfel beißen und eine klinische Prüfung durchführen. Es gibt eine Ausnahme, wenn Sie auf Basis von MDR, Artikel 61, Satz (10) begründen können, dass ein Nachweis auf Basis klinischer Daten für Ihr Produkt ungeeignet ist.

4. Muss ich die klinische Bewertung selbst erstellen?

Grundsätzlich ist die klinische Bewertung Teil der technischen Dokumentation Ihres Produkts, welche Sie als Hersteller erstellen und laufend pflegen müssen. Auch wenn Sie die Erstellung auch auslagern können, ist sie in den meisten Fällen jedoch auch von Ihnen selbst durchführbar – auch wenn Sie nur begrenzte Vorkenntnisse haben.

Selbst Start-ups haben klinische Experten (Mediziner oder andere Menschen mit wissenschaftlichem Hintergrund) oft bereits an Bord, welche ein grundlegendes Verständnis von klinischen Studien haben. Sie profitieren von der Durchführung einer klinischen Bewertung insofern, als Sie und Ihr Team durch das Lesen klinischer Studien Ihren Markt und Ihre Zielgruppe besser verstehen. Sie erhalten einen wissenschaftlichen Einblick in wirksame und möglicherweise wirkungslose Methoden und wissen auch nach dem Inverkehrbringen genau, worauf sie achten müssen und welche Daten in Zukunft relevant sind.

Bei der Durchführung einer klinischen Bewertung ist ein gewisses wissenschaftliches Verständnis wichtig, um die gefundenen Quellen einordnen und bewerten zu können. Wenn Ihnen Begriffe wie „randomisierte kontrollierte Studien“, „Stichprobengröße“ und „statistische Signifikanz“ nicht völlig fremd sind, haben Sie in den meisten Fällen gute Chancen, Ihre klinische Bewertung innerhalb weniger Wochen selbst zu erstellen (ausgenommen einer klinischen Prüfung).

Wir raten Ihnen auf jeden Fall dazu, sich zumindest grundlegend mit der Thematik auseinanderzusetzen – zu Beginn wirkt es oft komplizierter, als es eigentlich ist. Am Ende können Sie sich immer noch dazu entscheiden, das Thema auszulagern.

Für die Durchführung einer klinischen Prüfung lohnt es sich hingegen oft, einen entsprechenden Anbieter zu beauftragen. Diese haben bessere Möglichkeiten zur Rekrutierung von Studienteilnehmern und sind mit dem Design und der Durchführung solcher Untersuchungen vertraut. Wer hier keine tiefgreifende Erfahrung mitbringt, läuft Gefahr, Fehler zu machen, welche gravierende Auswirkungen haben können. Wird eine Studie beispielsweise falsch designt, könnte am Ende monatelange Arbeit umsonst gewesen sein. Geeignete Anbieter sind zum Beispiel Clinical Research Organizations (CRO), welche in den meisten Fällen über einen breiten Expertenpool im wissenschaftlichen, statistischen und medizinischen Bereich verfügen. Doch auch Hochschulen und Universitäten sind als Partner denkbar.

Achtung: Bei der Auswahl eines passenden Partners sollten Sie darauf achten, dass die durchgeführte Untersuchung auch den Anforderungen an klinische Prüfungen der MDR und des Medizinprodukterecht-Durchführungsgesetzes (nur für Deutschland relevant) genügt. Das trifft auf die meisten CRO zu, Universitäten sind hingegen in erster Linie am Erkenntnisgewinn und an Publikationen interessiert und mit harmonisierten Normen und Gesetzen nicht vertraut. Besprechen Sie Ihr Vorhaben also bereits vorab im Detail, damit es hier nicht zu Missverständnissen kommt. 

Natürlich kann auch die gesamte klinische Bewertung ausgelagert werden. Das ist besonders dann hilfreich, wenn Sie selbst keine Erfahrungen mit klinischen Untersuchungen und den regulatorischen Anforderungen haben – oder wenn Sie es sich einfach leisten können und Angst davor haben, Fehler zu machen.

Ein Vorteil davon ist, dass Sie die Unabhängigkeit der involvierten Personen recht plausibel belegen können. Das kann bei der Rechtfertigung der klinischen Nachweise nach außen helfen. Vorausgesetzt, niemand erhält einen Bonus, wenn die gefundenen Daten möglichst gut zu den Aussagen des Herstellers passen. Einem Gründer eines Health-Start-ups könnte man hingegen schon eher unterstellen, dass er sein Produkt in einem guten Licht dastehen lassen will und nur ausgewählte Fakten in seinen Bericht mit aufnimmt.

Die Nachteile hingegen sind die Kosten und das Know-how, das Ihrem Team dadurch eventuell verloren geht, wenn die Suche und Analyse klinischer Studien von Externen übernommen wird.

5. Zukunft: Die neue ISO 18969

Während die MEDDEV 2.7/1 Revision 4 aktuell noch der unangefochtene Goldstandard bleibt, wirft ein neuer internationaler Standard bereits seine Schatten voraus: die ISO 18969 „Clinical evaluation of medical devices“. Der Entwurf wurde im Jahr 2025 veröffentlicht und befindet sich nun in der öffentlichen Kommentierungsphase.

Die ISO 18969 beschreibt auf internationaler Ebene, wie klinische Bewertungen systematisch über den gesamten Produktlebenszyklus hinweg durchgeführt werden sollen. Sie gibt unter anderem präziser vor, welche Evidenzquellen herangezogen werden dürfen und wie die klinische Bewertung in das Qualitätsmanagement eingebettet wird.

Unsere Empfehlung: Bis die Norm final verabschiedet ist, orientieren Sie sich weiterhin an der MDR und der MEDDEV-Leitlinie. Dennoch lohnt sich ggf. ein Blick in den Entwurf der ISO 18969, um frühzeitig ein Gefühl für die mögliche kommende Harmonisierung zu bekommen und Ihren Prozess zukunftssicher aufzustellen.

6. Hilfreiche Quellen

MDR: Zentrales Werk, aus dem die Notwendigkeit und alle Anforderungen an die klinische Bewertung abgeleitet werden.

MEDDEV-2.7/1 revision 4: Leitlinie zur Erstellung der klinischen Bewertung. Zwar wurde das Dokument nicht explizit für die MDR verfasst, jedoch sind die meisten Inhalte nach wie vor aktuell.

ISO 18969: Entwurf des kommenden internationalen Standards zur klinischen Bewertung von Medizinprodukten. Er beschreibt die systematische Durchführung über den gesamten Produktlebenszyklus.

MDCG 2020-5: Leitlinie zur Evaluierung der Gleichartigkeit zweier Produkte

MDCG 2020-7: Vorlage für einen PMCF-Plan

MDCG 2020-8: Vorlage für einen PMCF-Bericht

Formulierung der Zweckbestimmung für (Software-)Medizinprodukte: Leitfaden zur Erstellung der Zweckbestimmung für Ihr Produkt

Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden: Anleitung zum Finden der Risikoklasse Ihres Produkts nach MDR

Leitfaden: Ist Ihre App ein Medizinprodukt?: Hier erfahren Sie, ob es sich bei Ihrem Produkt um ein Medizinprodukt nach MDR handelt.

7. Fazit

Der Aufwand, der mit der klinischen Bewertung einhergeht, hängt enorm von der Notwendigkeit einer klinischen Prüfung und dem Umfang der Literaturrecherche ab. Zwar ist es unter der MDR möglich, sich auf gleichartige Produkte zu berufen, die bereits am Markt sind, jedoch bedarf diese Gleichartigkeit einer zufriedenstellenden Erklärung. Gerade für Start-ups ist es sehr sinnvoll, den Markt intensiv zu durchforsten, um derartige Produkte ausfindig zu machen. Schließlich sind klinische Prüfungen teuer und dauern mehrere Monate bis Jahre. Die Chancen, ein geeignetes Produkt zu finden, sind natürlich von Fall zu Fall unterschiedlich und beim Zugang zu den passenden klinischen Daten ist man im Zweifelsfall auf die Gunst des Herstellers angewiesen.

Auch wenn sich die klinische Bewertung erst mal sehr komplex anhört und nach viel Aufwand klingt, sollten sich auch kleinere Unternehmen und Start-ups nicht gleich abschrecken lassen. In vielen Fällen kann sie intern durchgeführt werden und bedarf keiner externen Dienstleister. Dabei können Unternehmen stark profitieren, da sie neues Wissen generieren und der Aufwand für klinische Bewertungen in Zukunft besser abgeschätzt werden kann. Falls eine klinische Prüfung notwendig ist, greifen Unternehmen oft auf „Clinical Research Organizations“ (CROs) zurück.

Falls Sie eine Medical Software oder eine DiGA planen und Unterstützung bei der Entwicklung benötigen, setzen Sie sich gerne mit uns in Kontakt und wir besprechen das Ganze zusammen unverbindlich. Wir entwickeln Medical Apps und Medical Software für Unternehmen auf Auftragsbasis.

Weitere Fragen? Rufen Sie uns gerne an (+49 (0) 89 54998380) oder schreiben uns eine Email ([email protected]). 

The post MDR-Guide: Klinische Bewertung von Software-Medizinprodukten appeared first on QuickBird Medical.

Da in letzter Zeit immer mehr Gerüchte kursieren, dass eine Zulassung von Software-Medizinprodukten unter Risikoklasse I nicht mehr möglich ist, möchten wir mit diesem Artikel etwas Licht ins Dunkel bringen.

Dieser Artikel richtet sich vor allem an Hersteller von Medizinprodukt-Software, von denen keine oder nur geringe Risiken ausgehen. Das umfasst beispielsweise Trainingsapps, die von Patienten autonom genutzt werden und die keine Schäden am Patienten verursachen können.

Update – Juni 2025: Das Guidance-Dokument „MDCG 2019-11: Guidance on Qualification and Classification of Software […]“ liegt seit Juni 2025 in der überarbeiteten Revision 1 vor. In diesem Artikel sind sämtliche Anpassungen berücksichtigt. Eine detaillierte Übersicht der konkreten Änderungen finden Sie auch hier.

Update – Dezember 2025: Die EU-Kommission hat im Dezember 2025 einen Änderungsentwurf zur MDR veröffentlicht, der unter anderem eine Anpassung der Regel 11 zur Klassifizierung von Software-Medizinprodukten vorsieht. Auf die möglichen Auswirkungen für Risikoklasse-I-Software gehen wir im Kapitel 3 dieses Artikels ein.

Inhaltsverzeichnis

• 1. Risikoklassen der MDR
  • 1.1 Risikoklasse I oder IIa – Warum ist das wichtig?
  • 1.2 Regel 11 – Klare Grenze zwischen Klasse I und IIa?
  • 1.3 Schlussfolgerung – geht Klasse I noch?
• 2. Update der offiziellen MDCG-Guidance (Revision 1) – Juni 2025
• 3. Änderungsentwurf der MDR & Implikationen für Klasse I-Software – Dezember 2025
• 4. Umgang mit Unsicherheit bei der Risikoklasse
  • 4.1 Was passiert, wenn ich mein Produkt unter Risikoklasse I anmelde, obwohl ich mir unsicher bin?
• 5. Warum wir Risikoklasse I in der EU dringend brauchen
• 6. Fazit

1. Risikoklassen für Medizinprodukte der MDR

Da wir die Risikoklassen der MDR bereits in unserem Software-Klassifizierungs-Guide umfassend beschrieben haben, möchten wir es an dieser Stelle kurz halten:

• Die MDR unterscheidet bei Software im Kern die Risikoklassen I, IIa, IIb und III
• Entscheidend für die Bestimmung der Risikoklasse eines Produkts ist seine Zweckbestimmung

Die 4 MDR-Risikoklassen im Überblick

Falls Sie mehr über die Risikoklassifizierung von Software-Medizinprodukten erfahren möchten, helfen Ihnen folgende Leitfäden von uns:

1. Qualifizierung von Software-Medizinprodukten – Leitfaden: Ist Ihre App ein Medizinprodukt? 
2. Klassifizierung von Software-Medizinprodukten – Leitfaden: In welche Risikoklasse fallen Sie?

Die Zulassung von Produkten der Risikoklasse I ist im Vergleich zu höherklassigen Produkten sehr viel ressourcenschonender und schneller möglich. Daher stellen sich viele Hersteller die Frage, ob es sich bei ihrem Produkt um ein Produkt der Klasse I oder IIa handelt.

Warum das so ist, erfahren Sie im nächsten Kapitel.

1.1 Risikoklasse I oder IIa – Warum ist das wichtig?

Warum ist die Unterscheidung zwischen Klasse I und IIa überhaupt so wichtig? Und warum wird so viel darüber diskutiert?

Produkte der Risikoklasse I unterscheiden sich maßgeblich von höherklassigen Produkten.

Klasse I-Produkte …

• benötigen bei Marktzulassung kein Zertifikat einer benannten Stelle,
• können ohne Verzögerung (verursacht durch einen Audit) auf den Markt gehen und müssen keine Kosten für eine benannte Stelle tragen,
• werden lediglich unangekündigten Prüfungen durch die jeweilige Aufsichtsbehörde des Bundeslands unterzogen. Diese sind deutlich weniger aufwendig als die Zertifizierung bei einer benannten Stelle (Risikoklasse IIa und höher) und nicht kostenpflichtig.

Um das Ganze noch besser zu veranschaulichen, möchten wir hier einige Erfahrungswerte aufzeigen. Ein Klasse IIa Produkt bedeutet im Vergleich zu Klasse I:

• Verzögerung der Marktzulassung um 6–18 Monate (Dauer des Konformitätsbewertungsverfahrens einer benannten Stelle und Ausstellung des CE-Zertifikats)
• Kosten bis zu 6-stelligen Eurobeträgen für das Konformitätsbewertungsverfahren und die Zertifizierung des QMS
• Pflicht der Anzeige signifikanter Änderungen und weitere Prüfungen der benannten Stelle bei Produktänderungen nach der Zulassung

Wie lange es bis zum erfolgreichen Abschluss eines Konformitätsbewertungsverfahrens dauert, ist höchst individuell und hängt von verschiedenen Faktoren ab. In jedem Fall handelt es sich dabei um eine weitere Unbekannte, die man in der Planung seines Produkts nur schwer abbilden kann.

Die Unterscheidung zwischen Risikoklasse I und IIa entscheidet daher in vielen Fällen wirklich über die Existenz von Produkten und ganzen Unternehmen.

Deshalb ist Klasse I vor allem für Start-ups interessant, die auf eine schnelle Marktzulassung angewiesen sind und nur begrenzte Ressourcen haben.

Was genau bei einem Risikoklasse IIa-Produkt im Vergleich zu Klasse I auf Sie zukommt, erfahren Sie in einem gesonderten Fachartikel von uns: MDR Risikoklasse I vs. IIa: Unterschiede für Software-Medizinprodukte

1.2 MDR – Regel 11 – Klare Grenze zwischen Klasse I und IIa?

Die Antwort, ob Ihre Software oder App in die Risikoklasse I fallen kann, findet sich in der Medical Device Regulation (MDR) – Regel 11.

Zitat der MDR 6.3. Regel 11 (verkürzt):

Software, die dazu bestimmt ist, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen werden, gehört zur Klasse IIa,

[…]

Sämtliche andere Software wird der Klasse I zugeordnet.

In diesem Bezug fragen sich viele Hersteller:

• • Was sind Informationen, die zu Entscheidungen für diagnostische und therapeutische Zwecke herangezogen werden?
  • Wer kann solche Informationen überhaupt “heranziehen”, um diagnostische oder therapeutische Entscheidungen zu treffen?
  • Kann eine App, die einem Patienten nur Trainingsmodule und Wissen vermittelt, überhaupt die Therapie oder Diagnostik beeinflussen?
  • Ist die Empfehlung, eine bestimmte Übung zu machen, schon eine Therapieentscheidung?

Überraschung: Es gibt verschiedene Möglichkeiten, diese Regel 11 zu interpretieren. Denn das BfArM, benannte Stellen und Hersteller sind sich hier nicht einig. Es existiert viel Interpretationsspielraum, weshalb es immer wieder zu Diskussionen und Gerüchten kommt. Daher möchten wir hier die 2 wichtigsten Interpretationen dieser Regel 11 beschreiben.

1.2.1 Interpretation 1: Jede Software liefert Informationen, die die Therapie oder Diagnostik beeinflussen

Nach dieser Interpretation liefert auch eine App für Patienten Informationen für Entscheidungen zur Therapie oder Diagnose von Krankheiten. Der Patient würde sich ja selbst therapieren bzw. diagnostizieren und somit greife Satz 1 aus Regel 11.

Mit dieser Interpretation gibt es streng genommen keine Klasse I Standalone-Software, da Software definitionsgemäß immer einen Output (Informationen) auf Basis eines Inputs erzeugt. Eine Ausnahme wäre beispielsweise eine App, die jedem Nutzer den exakt gleichen Inhalt anzeigt, ohne irgendeine Individualisierung. Doch hier stellt sich die Frage, ob es sich dann überhaupt um ein Medizinprodukt handelt (siehe auch unser Leitfaden „Ist Ihre App ein Medizinprodukt?“).

1.2.2 Interpretation 2: Nur medizinisches Fachpersonal kann therapeutische oder diagnostische Entscheidungen treffen

Das ist die herstellerfreundliche Interpretation der Regel 11. Demnach würde eine Trainingsapp, die lediglich von Patienten verwendet wird, in Risikoklasse I fallen. Die Begründung: Ein Laie ist nicht dazu in der Lage, therapeutische oder diagnostische Entscheidungen zu treffen. Satz 1 aus Regel 11 greift daher nicht – Informationen werden nicht für Entscheidungen für diagnostische oder therapeutische Zwecke herangezogen.

Hinweis: Anders sieht es aber bei Produkten aus, die auch medizinisches Fachpersonal in die Nutzung einbeziehen und unterstützende Informationen liefern (z. B. über ein Web Dashboard). Dies wurde beispielsweise vom Hanseatische Oberlandesgericht im Fall von Dermanostic entschieden. In diesem Fall hat ein Mitbewerber ein Gerichtsverfahren gegen Dermanostic eingeleitet. Das Gericht entschied dann, dass es sich bei Dermanostic um ein Produkt der Klasse IIa handelt und nicht um eines der Klasse I. Mehr dazu lesen Sie hier.

1.2.3 Wessen Interpretation zählt nun?

Wir sehen, dass verschiedene Stakeholder unterschiedliche Auffassungen vertreten:

• • BfArM
  • Landesaufsichtsbehörde
  • Benannte Stelle
  • Hersteller
  • Gericht

Wenn Sie sich dazu entscheiden, den Weg zum Risikoklasse I Produkt zu gehen, ist vor allem Ihre eigene Meinung (Hersteller), aber natürlich auch die Meinung Ihrer Landesaufsichtsbehörde relevant. Diese Behörde ist nämlich in erster Linie verantwortlich für die Überwachung der Hersteller in Ihrer Region.

Auch die Entscheidung von Gerichten zählt natürlich, sofern es zu einem Rechtstreit (z.B. zwischen Ihnen und einem Konkurrenten) kommt – siehe Dermanostic .

Die Einschätzung benannter Stellen ist vor allem dann wichtig, wenn Sie Risikoklasse IIa oder höher anstreben. Bei Produkten der Risikoklasse I sind diese nämlich gar nicht eingebunden.

Das BfArM hat vor allem indirekten Einfluss auf die Risikoklassifizierung. Da es sich dabei um die Bundesbehörde handelt, kann das BfArM auch Einfluss auf die Landesaufsichtsbehörden ausüben und z.B. Empfehlungen herausgeben, denen Landesbehörden ggf. folgen.

1.3 Schlussfolgerung – geht Klasse I noch?

Ja, eine Zulassung von Software-Medizinprodukten der Risikoklasse I ist noch möglich. Allerdings ist das stark von Ihrer Landesaufsichtsbehörde abhängig. Unter Umständen kann es sich lohnen, den Sitz Ihres Unternehmens in Bundesländer zu verlagern, deren Aufsichtsbehörden „Klasse I-freundlich“ sind.

Alternativ gibt es ein weiteres spannendes Modell, das wir anbieten. Sie können uns als externen Inverkehrbringer beauftragen, Ihr Medizinprodukt auf den Markt zu bringen. Wir bieten diesen Service für Software-basierte Medizinprodukte und DiGA an: Mehr Informationen

Sprechen Sie uns gerne an, wenn Sie einen externen Inverkehrbringer für Ihre App oder andere Standalone-Software benötigen.

2. Update der offiziellen MDCG-Guidance (Revision 1) – Juni 2025

Die offizielle MDCG-Guidance zur Qualifizierung und Klassifizierung von Medical Device Software (MDSW) wurde im Juni 2025 in Revision 1 aktualisiert. Das Update wurde lange erwartet und erzeugte große Unsicherheit in der Digital Health-Szene. Die zentrale Frage im Raum: Bedeutet die neue Version das Ende von Risikoklasse I-Software?

Das ist glücklicherweise nicht der Fall. Es hat sich tatsächlich wenig in Bezug auf die (teilweise unkonkreten) Empfehlungen zur Risikoklasse I vs. IIa getan. Wir haben hier eine detaillierte Übersicht zu allen Änderungen erstellt: Alle Änderungen der MDCG 2019-11 Rev.1

3. Änderungsentwurf der MDR & Implikationen für Klasse I-Software – Dezember 2025

Am 16. Dezember 2025 hat die EU-Kommission einen Änderungsentwurf zur Medical Device Regulation (MDR) veröffentlicht. Ein zentraler Bestandteil dieses Entwurfs ist eine grundlegende Überarbeitung der Regel 11, welche wir in der aktuell gültigen Fassung oben erklärt haben.

Auf den ersten Blick wirkt der neue Wortlaut für Hersteller vielversprechend: Die Logik der Klassifizierung wird scheinbar umgedreht, sodass Software zunächst in Klasse I fällt, sofern keine höherklassifizierenden Kriterien greifen. Bei genauerer Analyse zeigt sich jedoch, dass diese Hoffnung trügerisch sein könnte. Je nach Auslegung würde der Entwurf dazu führen, dass ein Großteil medizinischer Software mindestens in Klasse IIa eingeordnet werden würde.

Wir haben den Änderungsentwurf, die neue Regel 11 sowie deren mögliche Interpretationen detailliert analysiert und die konkreten Auswirkungen auf Klasse-I-Software in einem separaten Fachartikel aufgearbeitet: Zum Fachartikel

Wichtig ist dabei: Der veröffentlichte Text ist ein früher Entwurf im europäischen Gesetzgebungsverfahren. Erfahrungsgemäß wird der Wortlaut in den kommenden Jahren weiter angepasst. Es ist daher unwahrscheinlich, dass dieser Entwurf für die Regel 11 unverändert in den finalen MDR-Text übernommen wird.

4. Umgang mit Unsicherheit bei der Risikoklasse

Wie kann ich sicher sein, dass meine Risikoklasse richtig ist? Eine absolute Rechtssicherheit gibt es bei diesem Thema eigentlich nie. Grundsätzlich ist eine höhere Klassifizierung immer “sicherer”, jedoch auch sehr viel aufwendiger und teurer.

Da sich ein solches Verfahren aber viele Firmen nicht leisten wollen oder können, möchten wir hier ein paar Möglichkeiten aufzeigen, die Sie als Hersteller eines Klasse-I-Produkts haben.

1. Lesen Sie die MDCG Guidance Dokumente (v.a. MDCG 2019-11).
2. Sehen Sie sich ähnliche Produkte auf dem Markt an, die unter MDR zugelassen sind. Dabei sollten Sie vor allem Produkte von Herstellern berücksichtigen, für die Ihre auch Ihre Aufsichtsbehörde verantwortlich ist.
3. Holen Sie Erfahrungswerte von Experten ein. Es gibt viele Berater, die in die Zulassung vieler Klasse I-Medizinprodukte involviert waren. Diese Erfahrungen sind in vielen Fällen auf ihr Produkt übertragbar. Sprechen Sie uns gerne an, wenn Sie dabei Unterstützung benötigen.
4. Holen Sie ein juristisches Gutachten ein. Ein solches wird von einem Anwalt ausgestellt und kann Ihre Argumentation vor einer Aufsichtsbehörde, aber auch vor Gericht untermauern. Es schafft zusätzliche Überzeugungskraft. Beachten Sie aber, dass ein solches Gutachten keine absolute Rechtssicherheit geben kann. Sprechen Sie uns an, wenn Sie an einem Gutachten interessiert sind. Wir vermitteln Sie gerne an einen Anwalt, der sich mit der Thematik auskennt.

4.1 Was passiert, wenn ich mein Produkt unter Risikoklasse I anmelde, obwohl ich mir unsicher bin?

Grundsätzlich können Sie das natürlich tun. Es liegt in der Verantwortung des Herstellers, die Klassifizierung seiner Produkte ordnungsgemäß durchzuführen.

ABER seien Sie sich bewusst, dass dies ein unternehmerisches Risiko darstellen kann. Einige dieser Risiken sind:

5. Warum wir Risikoklasse I in der EU dringend brauchen

Es gibt unzählige innovative Software-Produkte mit medizinischem Anwendungsfall, von denen kaum Risiken für Patienten ausgehen (z.B. Trainingsapps zur Reduktion von Ängsten). Der Zugang zu solchen Produkten wurde in den letzten Jahren (z.B. durch die Einführung von DiGA) enorm gefördert und tausende Patienten nutzen solche Produkte täglich effektiv zur Verbesserung ihres Gesundheitszustands. Das entlastet nicht nur Patienten, sondern das gesamte Gesundheitssystem.

Der Aufwand für eine Zulassung unter Risikoklasse IIa steht aus unserer Sicht in keinem Verhältnis zu den meist sehr geringen Risiken, die von Patienten-fokussierten Laienprodukten ausgehen.

Solche Produkte kommen zudem oft aus dem Startup-Umfeld, welches meist mit limitierten Ressourcen auskommen muss. Durch eine Überregulierung (und hart gesagt – das Unmöglich-Machen von Klasse I Software) erstickt man solche Innovationen im Keim. Kleine Unternehmen können es sich schlichtweg nicht leisten, ein Konformitätsbewertungsverfahren mit einer benannten Stelle zu durchlaufen – weder zeitlich, noch finanziell.

Das ist nicht nur schlecht für den Wirtschaftsstandort Deutschland, da Hersteller ihre Standorte in andere Länder verlagern, sondern am Ende auch eine politische Verhinderung einer besseren Patientenversorgung.

Wir benötigen daher dringend weiterhin die Möglichkeit, Software der Risikoklasse I zu entwickeln und auch zuzulassen.

6. Fazit zur Risikoklasse I nach MDR

Nach all den Gerüchten und Diskussionen stand die Frage im Raum: „Gibt es noch Standalone-Software-Medizinprodukte der Risikoklasse I?“

Die Situation ist zwar nach viel Recherche und zahlreichen Gesprächen in unserem Umfeld weiterhin nicht final geklärt, allerdings lassen sich einige Erkenntnisse gewinnen:

1. 1. Aufsichtsbehörden, benannte Stellen und Hersteller interpretieren die MDR unterschiedlich, weshalb bis heute kein klarer Konsens in Bezug auf die Risikoklasse I bei Software herrscht.
   2. Das offizielle Update der MDCG-Guidance hat wenig in Bezug auf die bisherige Unklarheit zwischen Risikoklasse I und IIa geändert. Das ist eine sehr gute Nachricht. Denn das bedeutet unterm Strich: Es wurde zumindest nicht gewollt, dass Risikoklasse I z. B. für DiGA und Übungs-Apps explizit ausgeschlossen wird. Es ist davon auszugehen, dass Risikoklasse I auch in Zukunft von den meisten Aufsichtsbehörden in Bezug auf risikoarme Übungs-Apps akzeptiert wird. Ob das BfArM sich hierzu irgendwann eine andere Meinung bildet, bleibt abzuwarten.

Wir von QuickBird Medical sind der Meinung, dass es unbedingt Softwareprodukte der Risikoklasse I geben muss. Die Risiken, die von solchen Produkten ausgehen, sind verschwindend klein, haben aber in der Masse einen riesigen Einfluss auf eine bessere Patientenversorgung. Eine höhere Risikoklasse senkt die Attraktivität erheblich, solche Produkte zu entwickeln und zuzulassen. Die damit einhergehenden Aufwände sind für viele Unternehmen nicht zu stemmen oder schlicht zu riskant. Unser Gesundheitssystem – und vor allem Patienten – profitiert aber enorm von Produkten der Risikoklasse I.

Abonnieren Sie unseren Newsletter, um zur Risikoklassifizierung auf dem neuesten Stand zu bleiben.

Sprechen Sie uns auch gerne an, wenn Sie die Realisierung eines Software-Medizinprodukts planen. Wir entwickeln regulierte Apps, Web-Anwendungen und andere medizinische Software auf Auftragsbasis für andere Unternehmen.

The post Klasse I Software nach MDR – Geht das noch? (Dezember 2025) appeared first on QuickBird Medical.

Update – Juni 2025: Im Juni 2025 wurde das offizielle Guidance-Dokument „MDCG 2019-11: Guidance on Qualification and Classification of Software […]“ in Revision 1 angepasst. Alle Änderungen werden in diesem Artikel vollumfänglich berücksichtigt. Eine detaillierte Auflistung aller Änderungen finden Sie in dem unten stehenden Kapitel: Link zum Kapitel.

Update – Dezember 2025: Im Dezember 2025 hat die Europäische Kommission einen Entwurf zur Änderung der MDR vorgelegt, der unter anderem die Regel 11 zur Einstufung von Software-Medizinprodukten betrifft. Die potenziellen Folgen für Software der Risikoklasse I werden in Kapitel 9 dieses Beitrags eingeordnet.

• 1. Ist Ihre Software überhaupt ein Medizinprodukt?
• 2. MDR-Risikoklassifizierung: kurz und knapp
• 3. Die Zweckbestimmung entscheidet
  • 3.1 Standalone-, Steuerungssoftware und Zubehör
• 4. In welche Risikoklasse fällt meine Software?
  • 4.1 Die Regel 11 der MDR
  • 4.2 Was fällt überhaupt noch in Klasse I?
  • 4.3 Fallbeispiele zur Bestimmung der Risikoklasse
• 5.Wer trifft die finale Entscheidung?
• 6. Auswirkungen der Risikoklassifizierung
• 7. Risikoklasse I, IIa & IIb = DiGA?
• 8. Update der offiziellen MDCG-Guidance (Revision 1) – Juni 2025
• 9. Änderungsentwurf der MDR (Dezember 2025): Auswirkungen für die Klassifizierung von Software
• 10. Software unter MDR vs. IVDR
• 11. Fazit

1. Ist Ihre Software überhaupt ein Medizinprodukt?

Die Zweckbestimmung entscheidet, ob Ihre Software überhaupt als Medizinprodukt einzustufen ist. Erst wenn das der Fall ist, können Sie sich mit der Risikoklassifizierung beschäftigen. Der Artikel 2 (1) der MDR definiert klar, welche Produkte als Medizinprodukte einzustufen sind. So kann eine App zur Analyse der Herzleistung zum Beispiel entweder als Fitnesstracker vorgesehen sein, oder einen Kardiologen bei der Diagnostik unterstützen. Nur im zweiten Fall gilt die App als Medizinprodukt. Als Hersteller entscheiden Sie selbst, welchen Zweck Ihre Software hat. Sie wollen wissen, ob Ihre Software ein Medizinprodukt ist? Dann erhalten Sie in unserem Leitfaden einen genaueren Überblick: zum Leitfaden. 

2. MDR-Risikoklassifizierung: kurz und knapp

Die Quintessenz der MDR Klassifizierungsregeln in aller Kürze:  Die MDR unterscheidet 4 Risikoklassen: I, IIa, IIb & III

Die 4 MDR-Risikoklassen im Überblick

Als Daumenregel lässt sich sagen: Je größer der mögliche Schaden durch den Einsatz einer Medizinprodukt-Software ist, desto höher ist tendenziell die Klasse.  Sobald Ihre Software Entscheidungen zu Therapie und Diagnostik eines Patienten beeinflusst, oder physiologische Prozesse (z.B. Schlafrhythmus) überwacht, fällt diese bereits mindestens in Klasse IIa (Regel 11). Wenn ein Patient dabei in großer Gefahr schwebt, steigt die Risikoklasse weiter an (z.B. Ihre App unterstützt nach einem Herzinfarkt). Eine Software, die vitale Parameter überwacht (Herz, Lunge, etc.) fällt ebenfalls in eine höhere Klasse. Sobald mehrere Regeln auf Ihre Software zutreffen, gilt die strengste Regel (die höchste Risikoklasse). Eine besonders hilfreiche Ergänzung zu diesem Leitfaden bietet das Guidance-Dokument der MDCG.

3. Die Zweckbestimmung entscheidet

Lassen Sie uns mit einem Beispiel beginnen, welches verdeutlicht, welchen Einfluss die medizinische Zweckbestimmung auf die Risikoklasse hat. 

1. Ihre App überwacht den Zyklus einer Frau, um die Wahrscheinlichkeit einer gewollten Schwangerschaft zu erhöhen. – Risikoklasse I
2. Ihre App überwacht den Zyklus einer Frau, um das Risiko einer ungewollten Schwangerschaft zu verringern. – Risikoklasse IIb

Eine Steigerung um zwei Risikoklassen, auch, wenn es sich um ein und dasselbe Produkt handelt? Ja, tatsächlich macht die Zweckbestimmung einen immensen Unterschied. Demnach sollten Sie sich zunächst genau überlegen, wie die Zweckbestimmung Ihrer Software oder App lauten soll. Es kann gut sein, dass Sie Ihre Zweckbestimmung noch anpassen, nachdem Sie diesen Artikel zu Ende gelesen haben. Unser Artikel zur Zweckbestimmung beschreibt die genauen Inhalte und hilft Ihnen bei der Formulierung. Ob Ihre Software überhaupt ein Medizinprodukt ist, erfahren Sie in diesem Artikel.

3.1 Standalone-, Steuerungssoftware, und Zubehör

Jede Software mit einer eigenen medizinischen Zweckbestimmung wird gesondert klassifiziert. Insgesamt gibt es drei verschiedene Arten von Software, die wir zu Beginn unterscheiden möchten:

• Eigenständige Software / Standalone Software
• Software, die in Verbindung mit einem anderen Medizinprodukt verwendet wird
• Software als Teil eines Medizinprodukts

Wichtig an dieser Stelle ist für Sie, dass Sie Ihre Software nicht gesondert klassifizieren müssen, wenn

1. sie integraler Bestandteil eines anderen Medizinprodukts ist (z.B. Embedded Software, wie Firmware eines Blutdruck-Messgeräts). Dies ist für mobile Apps fast nie zutreffend.
2. sie ausschließlich zur Steuerung eines anderen Medizinprodukts dient (z.B. UI zur Bedienung eines Defibrillators). Dann fällt sie automatisch in dieselbe Klasse, wie das gesteuerte Produkt. Falls die Software aber noch eine weitere Zweckbestimmung hat, müssen Sie prüfen, ob sie in eine höhere Klasse fällt.

In allen anderen Fällen gilt es, die richtige Klasse für Ihre Software zu finden. Erfahren Sie hier mehr über die Arten von Software als Medizinprodukt.

4. In welche Risikoklasse fällt meine Software?

Wie bereits erwähnt, liefert die Zweckbestimmung Ihrer Software die Grundlage zur Frage, in welche der vier Risikoklassen sie fällt. Sobald die Zweckbestimmung klar ist, finden Sie mit den Regeln in Anhang VIII zur MDR die richtige Klasse für Ihre Software.  Wir empfehlen, die Suche nach der Klasse bei Regel 11 zu beginnen, da diese speziell Software adressiert. Gleichzeitig lohnt sich ein Blick in das Guidance-Dokument der MDCG. Dessen Kerninhalte sind in diesem Artikel zusammengefasst. 

4.1 Die Regel 11 der MDR

Für medizinische Software ist in den meisten Fällen die Regel 11 entscheidend. Hier wird zwischen Software unterschieden, die Informationen für Therapie- und Diagnostik-Entscheidungen liefert, und jener, die physiologische Prozesse überwacht. Eine Software kann natürlich auch mehrere Zwecke haben. Gemäß Regel 11 müssen Sie folgende Entscheidungen treffen:

4.1.1 Ist Ihre Software dazu bestimmt, Informationen zu liefern, die zu Entscheidungen für diagnostische oder therapeutische Entscheidungen herangezogen werden?

Wenn ja, beantworten Sie im Folgenden diese Fragen: Können diese Entscheidungen den Tod oder eine irreversible Verschlechterung des Gesundheitszustands herbeiführen? Wenn das zutrifft, fällt Ihre Software in die Risikoklasse III. 💡 Beispiel:

Ihre Software liefert durch Bildanalysen die Entscheidungsgrundlage für einen Notarzt, wie er einen Patienten mit akutem Schlaganfall behandeln soll.

Können diese Entscheidungen eine schwerwiegende Verschlechterung des Gesundheitszustands oder einen chirurgischen Eingriff herbeiführen? Wenn das zutrifft, fällt Ihre Software in die Risikoklasse IIb. 💡 Beispiel:

Ihre Software liefert die Entscheidungsgrundlage für einen Physiotherapeuten, ab welchem Punkt ein verletztes Knie wieder belastet werden kann. Eine Überbelastung könnte zu einer Operation führen.

Wenn Sie beide Fragen mit “Nein” beantworten können, fällt Ihre Software vorerst in die Risikoklasse IIa. 💡 Beispiel:

Ihre Software misst mittels Fragebogen den Schweregrad einer ADHS-Symptomatik bei Erwachsenen.

Grafische Darstellung des Entscheidungsbaums des ersten Teils der Regel 11.

4.1.2 Ist Ihre Software zur Überwachung von physiologischen Prozessen bestimmt?

Wenn ja, beantworten Sie im folgenden diese Fragen: Ist die Software zur Überwachung vitaler physiologischer Prozesse (Herz-, Lungen-, Hirnfunktion, etc.) bestimmt, wobei die Art der Änderung dieser Parameter zu einer unmittelbaren Gefahr für den Patienten führen kann? Wenn das zutrifft, fällt Ihre Software vorerst in die Risikoklasse IIb. 💡 Beispiel:

Ihre App überwacht die Herzfrequenz einer Person, während diese im Koma liegt. Bei gesundheitskritischen Messwerten wird das medizinische Personal alarmiert, um rechtzeitig eingreifen zu können.

Wenn Sie diese Frage mit “Nein” beantworten können, fällt Ihre Software vorerst in die Risikoklasse IIa. 💡 Beispiel:

Ihre App überwacht den Schlafrhythmus eines Patienten zu Hause, um den Erfolg einer Therapie von Schlafstörungen zu messen.

Grafische Darstellung des Entscheidungsbaums des zweiten Teils der Regel 11.

4.1.3 Hat Ihre Software einen anderen Zweck?

Die Regel 11 besagt im letzten Satz eindeutig: “Sämtliche andere Software wird der Klasse I zugeordnet.” Somit haben Sie auch für diesen Fall Ihre Antwort – oder doch nicht? Leider nein, denn dann stellt sich die Frage, ob eine andere Regel auf Ihre Software angewandt werden kann. Relevant sind dabei insbesondere die Regeln 15 und 22:

• Regel 15 richtet sich an aktive Produkte, die der Empfängnisverhütung oder dem Schutz vor sexuell übertragbaren Krankheiten dienen. Software in diesem Bereich fällt in Klasse IIb.

💡 Beispiel:

Ihre mobile App ist zur Empfängnisverhütung bestimmt. Dafür erinnert sie eine Nutzerin an die tägliche Einnahme der Anti-Baby-Pille. Wenn die Einnahme bis zu einer bestimmten Uhrzeit nicht bestätigt wurde, erzeugt die App ein Warnsignal.

• Regel 22 richtet sich an aktive therapeutische Produkte mit integrierter oder eingebauter diagnostischer Funktion, die das Patientenmanagement durch das Produkt erheblich bestimmt, wie etwa geschlossene Regelsysteme oder automatische externe Defibrillatoren. Software in diesem Bereich fällt in Klasse III.

💡 Beispiel:

Ihre Software ist zur weiteren Begleitung nach einer psychotherapeutischen Behandlung von Depression bestimmt. Durch die eingebaute Diagnostikfunktion wird die Behandlung durch die Software angepasst und die Notwendigkeit einer erneuten Psychotherapie bestimmt.

Wichtig: Wenn Ihre Software gemäß Regel 11 in die Risikoklasse IIb oder niedriger fällt, müssen Sie sich alle anderen Regeln ansehen – denn vielleicht ist noch eine strengere dabei, welche die Risikoklasse erhöht. Wenn mehrere Klassifizierungsregeln auf Ihre Software angewandt werden können, ist immer die strengste Regel zutreffend!

4.2 Was fällt überhaupt noch in Klasse I?

Hier existiert tatsächlich eine Grauzone bei der Interpretation der Regel 11 in der MDR. Wir geben detaillierte Hilfestellung in unserem Leitfaden zum Thema: Klasse I Software nach MDR – Geht das aktuell noch?.

4.3 Fallbeispiele zur Bestimmung der Risikoklasse

Diese Fallbeispiele sollen den Prozess der Entscheidungsfindung veranschaulichen. Es handelt sich hierbei um fiktive Beispiele.

4.3.1 Fallbeispiel 1: App zur Begleitung von Expositionstherapie

Ihre App soll die Expositionstherapie eines Patienten mit Höhenangst begleiten. Dazu wird gemeinsam mit seiner Therapeutin eine Liste mit Situationen erarbeitet, die dem Patienten Angst machen (z.B. 5 Minuten auf dem Balkon seiner Wohnung stehen.). Diese Situationen werden von “wenig angsteinflößend” bis “sehr angsteinflößend” geordnet. Nun soll er selbstständig zu Hause versuchen, eine dieser Situationen aufzusuchen und auszuhalten. Im Nachgang erfasst die App mittels Fragebogen, wie sich der Patient in der Situation gefühlt hat. Auf Basis dieser Daten entscheidet der Therapeut wöchentlich, wann der richtige Zeitpunkt für eine Steigerung des Schwierigkeitsgrades ist. Wir beginnen bei Regel 11:

• Die App liefert Informationen, die therapeutische Entscheidungen beeinflussen. Wir könnten argumentieren, dass durch diese Entscheidungen weder der Tod, noch ein irreversibler oder ernsthafter Schaden entstehen kann. Demnach wäre das Produkt in Klasse IIa einzustufen.

Da keine andere Regel zutrifft, bleibt die App in Klasse IIa.  Es ließe sich evtl. auch argumentieren, dass der Patient durch Therapieempfehlungen in eine Gefahrensituation gelangen könnte, die einen Tod hervorrufen kann (z.B. eine steile Klippe eines Berges). Somit würde das Produkt in Klasse III fallen. Wir entscheiden uns hier aber ausdrücklich, derartige Empfehlungen nicht in der App abzugeben. Dies zeigt jedoch gut den Argumentationsspielraum bei der Klassifizierung eines Medizinprodukts.

4.3.2 Fallbeispiel 2: App für die Therapie nach einem Herzinfarkt

Sie haben eine App entwickelt, die die Herzleistung eines Patienten nach einem Herzinfarkt zu Hause überwacht, nachdem die Behandlung abgeschlossen ist. Auf Basis der Messwerte informiert die App den Patienten, sobald die Einnahme eines lebensnotwendigen Medikaments notwendig ist und wann er wieder zur Nachsorgeuntersuchung gehen soll. Wir beginnen bei Regel 11:

• Die App überwacht vitale physiologische Prozesse (Herzleistung). Demnach wäre die App ein Medizinprodukt der Klasse IIb.

Wir müssen uns auch die anderen Regeln anschauen, um herauszufinden, ob auch eine strengere Regel angewandt werden muss. Bei Regel 22 sehen wir:

• Ihre App passt die Therapie an und entscheidet selbst, welche Therapiemaßnahmen notwendig sind. Somit beeinflusst sie das Patientenmanagement.

Daher fiele Ihr Produkt in Risikoklasse III, weil immer die strengste Regel angewandt wird.

Achtung: Bei beiden Beispielen ließe sich sicherlich einen ganzen Nachmittag belebt diskutieren, ob diese Einschätzungen schlussendlich richtig sind. Wichtig für uns ist es hier, Ihnen einige greifbare Beispiele zum weiteren Verständnis zu geben. Eine glasklare Einstufung in eine Klasse ist nicht immer möglich, da das Gesetz unterschiedlich interpretiert werden kann. Es bleibt also Argumentationsspielraum. Genießen Sie diese Einschätzungen daher mit Vorsicht.

5. Wer trifft die finale Entscheidung?

Sie. Die Entscheidung, ob eine Software ein Medizinprodukt ist, trifft der Hersteller. Auch die Einstufung in eine Risikoklasse wird vom Hersteller vorgenommen. Dabei sollten Sie aber gewissenhaft vorgehen, denn die benannte Stelle kann die Zertifizierung verhindern, falls diese Ihrer Risikoklassifizierung nicht zustimmt. Hier erfahren Sie mehr über die Medizinprodukt-Zertifizierung: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR) Bei einer zugewiesenen Risikoklasse I haben Sie zwar keine benannte Stelle, aber auch hier kann die zugewiesene Aufsichtsbehörde auf eine falsche Klassifizierung aufmerksam machen und Sie potenziell auffordern, Ihr Produkt nachträglich vom Markt zu nehmen. Wenn Sie unsicher sind, holen Sie am besten ein Gutachten oder eine Einschätzung einer dritten Partei ein. Die Möglichkeiten hierfür sind:

• Ein spezialisierter Anwalt, der Ihnen ein Gutachten ausstellt 
• Ein Regulatory-Berater, der eine Einschätzung abgibt
• das BfArM (leider lange Antwortzeiten und daher kaum praktikabel)

Anmerkung: Weder eine Experteneinschätzung noch ein Gutachten schützen Sie rechtlich! Jedoch können solche Dokumente im Falle eines späteren Gerichtsverfahrens entscheidend sein.

6. Auswirkungen der Risikoklassifizierung

Die Risikoklassifizierung von Medizinprodukten hat entscheidenden Einfluss auf die regulatorischen Anforderungen und den Aufwand für die Zulassung und Marktüberwachung. Besonders der Übergang von Klasse I zu Klasse IIa ist hierbei kritisch, da mit der Höherklassifizierung erhebliche zusätzliche Anforderungen verbunden sind. Während Klasse-I-Produkte einer Eigenzertifizierung durch den Hersteller unterliegen, erfordert Klasse IIa die Einbindung einer Benannten Stelle, was die Dokumentationspflichten, Prüfverfahren und Kosten deutlich erhöht. Eine präzise und regelkonforme Risikoklassifizierung ist daher essenziell, um regulatorische Risiken zu minimieren und Verzögerungen im Marktzugang zu vermeiden. Was genau bei einem Risikoklasse IIa-Produkt im Vergleich zu Klasse I auf Sie zukommt, erfahren Sie in einem gesonderten Fachartikel von uns: MDR Risikoklasse I vs. IIa: Unterschiede für Software-Medizinprodukte

7. Risikoklasse I, IIa & IIb = DiGA?

Eine digitale Gesundheitsanwendung (DiGA) ist eine Software, die von ÄrztInnen und PsychotherapeutInnen verschrieben wird und deren Kosten von den gesetzlichen Krankenkassen übernommen werden. Damit eine Software oder App zur DiGA werden kann, muss sie in Risikoklasse I, IIa oder IIb fallen. Heißt das im Umkehrschluss, dass alle Software-Produkte, die diesen Risikoklassen angehören, auch automatisch DiGA sind? Nein! Um ins DiGA-Verzeichnis aufgenommen zu werden, müssen Apps einen dicken Anforderungskatalog erfüllen. DiGA sollen die Versorgung optimieren oder strukturelle Erleichterungen für PatientInnen schaffen. Software, deren Nutzer vorrangig ÄrztInnen sind, scheiden zum Beispiel bereits aus. Zudem dürfen DiGA auch keine reinen Primärpräventionen darstellen. Da unter Risikoklasse I jedoch überwiegend solche Angebote fallen, sind auch deshalb viele Apps von der DiGA-Regelung ausgenommen. Alle Kriterien für eine DiGA finden Sie in diesem Artikel. Digitalen Medizinprodukten, die in Deutschland aufgrund der Risikoklasse III im Moment von der DiGA-Definition ausgenommen sind, wird nun in Frankreich eine Chance eröffnet. Alles über DiGA in Frankreich erfahren Sie in diesem Blogartikel.

8. Update der offiziellen MDCG-Guidance (Revision 1) – Juni 2025

Im Juni 2025 wurde ein in der Digital-Health-Szene lange erwartetes Update des offiziellen Guidance-Dokuments der MDCG zur Risikoklassifizierung und Qualifizierung durchgeführt. Bisher war die MDCG-Guidance z.B. in Bezug auf patientenorientierte Übungssoftware (Großteil der im BfArM-Verzeichnis gelisteten DiGA) recht unkonkret. Es existierte eine relevante Grauzone bei der Interpretation der Regel 11 in Bezug auf die Einordnung in Risikoklasse I vs. IIa. Es wurde lange Zeit befürchtet, dass mit dem Update die Möglichkeit einer Risikoklasse I für Software-Medizinprodukte eliminiert werden könnte.

Entwarnung: Das ist glücklicherweise nicht passiert. Das neue Guidance-Dokument ist in Bezug auf Risikoklasse I vs. IIa z. B. bei patientenorientierter Software wie DiGA immer noch genauso unkonkret.

Persönliche Meinung von QuickBird Medical: Dass die Risikoklasse I für Patienten-Trainingsapps nicht explizit ausgeschlossen wurde, ist eine gute Nachricht. Eine Eingrenzung wäre ein schwerer Fehler gewesen. Sie hätte die europäische Innovation im Bereich digitaler Gesundheitsanwendungen massiv behindert. Risiken von Medizinprodukten müssen immer im Verhältnis zum Nutzen bewertet werden. Daher braucht es weiterhin Möglichkeiten, Apps unter Risikoklasse I zuzulassen. Nur so können auch kleine Unternehmen Innovationen auf den Markt bringen, von denen keine oder nur geringe Risiken ausgehen. Die Kosten und Aufwände eines Risikoklasse-IIa-Produkts sind für viele junge Unternehmen kaum finanzierbar. Nun zurück zur Guidance: Was hat sich also überhaupt geändert?

Konkrete Änderungen der Revision 1 im Juni 2025: Viel ist in Bezug auf Risikoklassifizierung tatsächlich nicht passiert. Hier sind die relevanten Änderungen zusammengefasst:

1. Neues Beispiel für MDR Regel 11: Es wurde bezüglich der Klassifizierungsentscheidung mit Regel 11 der MDR ein neues Beispiel hinzugefügt: „[…] a device intended to prevent the risk of illnesses or pathologies by analysing physiological parameters (e.g. placement of the dorsal vertebrae, analysis of arterial stiffness, etc.) can be considered as a device providing information which is used to take decisions with diagnosis purpose (potential detection of pathologies) and in this case is in class IIa.“. Diese Klarstellung betrifft nur einen Bruchteil der am Markt befindlichen Software oder Apps, und ändert z.B. im Bereich von DiGA wenig bis nichts.
2. Neuer Verweis auf MDCG-Guidance (Hardware-Software-Kombinationen): Es wird mehrmals auf die „MDCG 2023-4 Medical Device Software (MDSW) – Hardware combinations“ in Bezug auf Software-Hardware-Kombinationen verwiesen. Diese Guidance beinhaltet jedoch keine direkt relevanten Inhalte in Bezug auf die Risikoklassifizierung.
3. Neuer Verweis auf MDCG-Guidance (Allgemeine Klassifizierung): Es wird auf die „MDCG 2021-24 for the general principles of medical device classification.“ verwiesen, welche sich mit allgemeinen Klassifizierungsregeln beschäftigt. Das ist unabhängig davon, ob Ihr Produkt eine Software darstellt oder nicht. Das ändert auch erstmal nichts Grundlegendes.
4. Neue Informationen für Modularisierung: Das Kapitel über „Module“ wurde um weitere Informationen erweitert. Das könnte für Sie durchaus relevant sein, falls Sie bei der Unterteilung der Software in Medizinprodukt- und Nicht-Medizinprodukt-Komponenten Guidance benötigen.
5. MDSW ersetzt Standalone Software: Der Begriff „Standalone Software“ wurde ersetzt durch den Begriff „Medical Device Software (MDSW)“. Dies wird damit erklärt, dass der Ort der Software (Embedded, auf einer Plattform, in der Cloud etc.) für die Klassifizierung nicht relevant sei.

Das war’s auch schon. Allgemein ergeben sich aus diesen Einschüben kaum Änderungen in Bezug auf die Medical Device Software (MDSW)-Klassifizierung.

9. Änderungsentwurf der MDR (Dezember 2025): Auswirkungen für die Klassifizierung von Software

Am 16. Dezember 2025 hat die Europäische Kommission einen Entwurf zur Änderung der Medical Device Regulation (MDR) vorgelegt. Ein wesentlicher Fokus dieses Vorschlags liegt auf einer Neufassung der Regel 11, die für die Risikoklassifizierung von Software-Medizinprodukten maßgeblich ist.

Auf den ersten Blick erscheint der neue Entwurf positiv und lässt vermuten, dass Software künftig grundsätzlich der Risikoklasse I zugeordnet wird, solange keine expliziten Kriterien für eine höhere Klassifizierung erfüllt sind. Diese scheinbar herstellerfreundliche Systematik relativiert sich jedoch bei näherer Betrachtung: Abhängig von der Auslegung könnte der Entwurf dazu führen, dass der überwiegende Teil medizinischer Software mindestens als Klasse IIa einzustufen wäre – auch bei vergleichsweise geringem Risiko.

Eine vertiefte Analyse des Entwurfs, der vorgeschlagenen Fassung der Regel 11 sowie der daraus resultierenden Interpretationsspielräume haben wir in einem separaten Beitrag zusammengefasst. Dort beleuchten wir insbesondere die konkreten Konsequenzen für Softwareprodukte: Zum Fachartikel

Wichtig für Hersteller ist: Der veröffentlichte Text stellt keine finale Rechtsfassung, sondern einen frühen Schritt im europäischen Gesetzgebungsverfahren dar. Erfahrungsgemäß werden solche Entwürfe im weiteren Verlauf weiter überarbeitet. Entsprechend ist derzeit nicht davon auszugehen, dass die vorgeschlagene Regelung unverändert Eingang in die endgültige Fassung der MDR finden wird.

10. Software unter MDR vs. IVDR

Falls Ihr Produkt z.B. auf Basis von Laborproben diagnostische Entscheidungen trifft, fallen Sie womöglich nicht unter die MDR, sondern unter die IVDR (In-vitro-Diagnostika-Verordnung).

Hier gelten komplett unterschiedliche Klassifizierungsregeln. Weitere Informationen zur Qualifizierung und Klassifizierung von IVDR-Software finden Sie in unserem Leitfaden: IVDR Software: Qualifizierung und Klassifizierung

11. Fazit

Um die richtige Risikoklasse für Ihre Anwendung zu finden, beginnen Sie am besten bei der Regel 11 der MDR. Fällt Ihre Software nach dieser Regel nicht in die Risikoklasse III, sollten Sie noch einmal alle anderen Regeln überprüfen, um herauszufinden, ob eine strengere Regel für Ihr Produkt anzuwenden ist. Zusätzlich lohnt sich ein Blick in das Guidance Dokument der MDCG, um anhand von weiteren Beispielen ein Gefühl für die Klassifizierung von medizinischer Software zu bekommen. Wichtig zu wissen ist, dass Sie als Hersteller die finale Entscheidung in der Frage nach der Risikoklasse Ihres Produkts treffen. Seien Sie sich dieser Verantwortung bewusst und holen Sie auch Meinungen von Experten ein.

Falls Sie eine Medical App, DiGA oder DiPA planen und Unterstützung bei der Entwicklung benötigen, setzen Sie sich gerne mit uns in Verbindung und wir besprechen das Ganze zusammen unverbindlich. Wir entwickeln Medical Apps für Unternehmen und Forschungseinrichtungen auf Auftragsbasis. Weitere Fragen? Rufen Sie uns gerne an (+49 (0) 89 54998380) oder schreiben Sie uns eine E-Mail ([email protected]). Abonnieren Sie unseren Newsletter für DiGA- und Medizinprodukt-Software-Hersteller, um auf dem Laufenden zu bleiben.

The post Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden appeared first on QuickBird Medical.

Für die strategische Planung von neuen DiGA-Projekten und Marktanalysen ist es wichtig, die Verschreibungszahlen gelisteter DiGA zu berücksichtigen. Bei der Suche nach aktuellen Statistiken stößt man allerdings auf unterschiedliche Berichte von verschiedenen Institutionen (GKV-Spitzenverband, Spitzenverband Digitale Gesundheitsversorgung, etc.).

Daher bieten wir in diesem Beitrag einen chronologischen Überblick mit Links zu den DiGA-Reports der relevantesten Herausgeber.

Dieser Artikel wird fortlaufend aktualisiert.

Inhalte dieses Artikels

• Alle DiGA Reports auf einen Blick
  • DiGA Report 2024
  • DiGA Report 2023
  • DiGA Report 2022
  • DiGA Report 2021
• Welche Daten nutzen die gelisteten DiGA-Reports?
  • GKV
  • SVDGV
  • TK
  • Barmer
  • DAK
• Welchen DiGA Report sollten Sie sich ansehen?

Alle DiGA Reports auf einen Blick

Jährlich werden die Abrechnungsdaten aller gesetzlichen Krankenkassen bis zum 30. September ausgewertet und in den hier aufgeführten Berichten dargestellt und zusammengefasst. Die Veröffentlichung der Berichte erfolgt meist im Frühjahr des folgenden Jahres.

DiGA Report 2024

• DiGA-Bericht des GKV-Spitzenverbandes – Spitzenverband Bund der Krankenkassen: Bericht mit den Versicherten-Daten aller Krankenkassen
• DiGA-Report 2024 – Marktentwicklung digitaler Gesundheitsanwendungen – Spitzenverband Digitale Gesundheitsversorgung (SVDGV): Bericht mit den Daten aller DiGA-Hersteller nach Selbstauskunft

DiGA Report 2023

• TK DiGA Report II – Der Bericht der Techniker Krankenkasse erschien im April 2024. Der Bericht bezieht sich, wie der nachfolgende Barmer Arztreport, auf Daten aus 2023
• Barmer Arztreport 2024
• DiGA-Bericht des GKV-Spitzenverbandes – Spitzenverband Bund der Krankenkassen
• Marktentwicklung digitaler Gesundheitsanwendungen (DiGA-Report) – Spitzenverband Digitale Gesundheitsversorgung (SVDGV): Bericht mit den Daten aller DiGA-Hersteller nach Selbstauskunft

DiGA Report 2022

• DiGA-Bericht des GKV-Spitzenverbandes – Spitzenverband Bund der Krankenkassen
• TK DiGA Report – Techniker Krankenkasse

DiGA Report 2021

• Digitalisierungsreport – DAK Gesundheit

Aktuelle Nachrichten zu DiGA und Medical Software finden Sie in unserem Newsfeed.

Welche Daten nutzen die gelisteten DiGA-Reports?

GKV-Spitzenverband:

Der GKV-Spitzenverband veröffentlicht seit 2022 jährlich einen DiGA-Report. Als Datengrundlage dienen die Abrechnungsdaten aller gesetzlichen Krankenkassen bis zum 30. September desselben Jahres (nach § 33a Abs. 6 SGB V).

Zudem definiert der GKV mit den Krankenkassen die Vergütungsbeträge für DiGA, die ab dem 13. Monat nach Aufnahme erstattet werden, und vereinbart darüber hinaus mit den DiGA-Herstellerverbänden (wie dem SVDGV) eine Rahmenvereinbarung, die u. a. Regelungen zu den Vergütungsverhandlungen, zu den Höchstbeträgen und zu den Schwellenwerten beinhalten.

SVDGV:

 Mit dem diesjährig veröffentlichten DiGA-Report 2024 bietet der Spitzenverband Digitale Gesundheitsversorgung e.V. (SVDGV) erstmals Einblicke in die Entwicklungen des DiGA-Marktes auf Basis von Herstellerangaben. Die im Bericht erhobenen Daten wurden dementsprechend vom SVDGV einzeln bei jedem Hersteller für die jeweilige DiGA erfragt.

Da es sich um den ersten Report dieser Art handelt, umfasst er den gesamten Zeitraum nach der Listung der ersten DiGA vom Oktober 2020 bis September 2023.

2022 kritisierte der SVDGV den GKV-Spitzenverband scharf nach dessen Veröffentlichung des “DiGA Report 2022”. Laut SVDGV versäumte es der GKV damals erneut, den “noch jungen Versorgungsbereichs neutral darzustellen”. → zum Statement

Techniker Krankenkasse:

Deutschlands größte gesetzliche Krankenkasse mit über 11,3 Millionen Versicherten veröffentlichte bisher einmalig im Jahr 2022 einen expliziten DiGA-Report. Hierfür wurden Abrechnungsdaten von rund 16.000 TK-Versicherten ausgewertet, denen bis zum 31. Dezember 2021 eine DiGA verordnet oder genehmigt wurde.

BARMER:

In ihrem jährlich erscheinenden Arztreport setzt die Barmer erstmals 2024 ihr Schwerpunktthema auf DiGA und wertet hierzu die Daten ihrer rund 8,7 Millionen Versicherten aus. Zusätzlich wurden im November und Dezember 2023 insgesamt 1.000 Behandlerinnen und Behandler aus dem DocCheck Panel online über Einstellungen und Erfahrungen zu DiGA befragt.

DAK Gesundheit:

Die DAK veröffentlicht jährlich einen sogenannten Gesundheitsreport. Den letzten dezidierten „Digitalisierungsreport“, der letztlich auch das Thema DiGA umfasst, publizierte die in Hamburg ansässige Krankenkasse im Jahr 2021 in Kooperation mit der “Ärzte Zeitung”.

Als Datenbasis der zugrunde liegenden Studie dient hierbei eine Onlineumfrage vom 17. September bis zum 1. November 2021 sowie eine Befragung von ePatient Analytics mit 569 Ärztinnen und Ärzte als auch 16 Psychotherapeutinnen und -therapeuten aus ganz Deutschland.

Welchen DiGA Report sollten Sie sich ansehen?

Der DiGA-Report des GKV-Spitzenverbands bündelt zum jährlichen Stichtag am 30. September sämtliche Daten der gesetzlichen Krankenkassen und bietet dadurch mit Sicherheit die größte Datenmenge zur Inanspruchnahme von DiGA.

Allerdings sieht sich der GKV mit dem wiederholten Vorwurf des SVDGV konfrontiert, keine neutrale Berichterstattung zu liefern und DiGA zu delegitimieren, indem es die hohen Kosten von DiGA, das Zulassungsverfahren und die teils mangelnde Evidenz kritisiert. Das hatte diesjährig erstmals zur Folge, dass der SVDGV einen eigenen DiGA-Report veröffentlichte, ausschließlich basierend auf Herstellerangaben.

Die vereinzelten DiGA-(Zwischen-)Berichte der oben genannten Krankenkassen bieten ebenfalls interessante Erkenntnisse, allerdings begrenzt auf Daten der jeweils eigenen Versicherten.

Weitere Hilfestellungen und Marktanalyse-Tools für die Planung Ihrer DiGA:

• Blogbeitrag: Umsatz & Kosten: Lohnt sich eine DiGA? (inkl. Excel-Planner zur Prognose von Umsatz & Kosten Ihrer DiGA)
• DiGA-Verzeichnis: Analyse-Tool für Hersteller – Vergleich von DiGA anhand der Medizinprodukt-Risikoklasse, der Aufsichtsbehörde, der DiGA-Verordnungsdauer und dem Listen-Preis
• DiGA-Statistiken: Real-Time Dashboard – Informationen über die Risikoklassen-Verteilung, Preise bzw. Kosten, Dauer der Verordnungen u.v.m.
• Kostenloses Whitepaper: „13 wichtige Empfehlungen für angehende DiGA-Hersteller 2025“ – Erfahrungen aus unseren erfolgreich umgesetzten DiGA-Projekten zusammengefasst

The post Aktuelle DiGA Reports 2026: Offizielle Berichte im Überblick appeared first on QuickBird Medical.

Da wir DiGA auf Auftragsbasis für Start-ups, Pharma und andere Unternehmen entwickeln, sehen wir den kompletten Entwicklungszyklus einer DiGA: von der ersten Idee bis zur dauerhaften Zulassung und danach.

In diesem Beitrag möchten wir Ihnen einen Überblick über alle Themen geben, über die wir bereits geschrieben haben. Sie finden eine Übersicht aller Leitfäden und Fachartikel, eingeordnet nach Themengebiet.

Tipp: Wenn Sie neu in der Materie sind, macht es Sinn, dass Sie sich ganz einfach chronologisch von oben nach unten durch die Inhalte arbeiten. 

Inhaltsverzeichnis

• 1. DiGA: Entwicklung & Zulassung
  • 1.1 Ist Ihre App eine DiGA? Definition & Kriterien digitaler Gesundheitsanwendungen
  • 1.2 12 wichtige Empfehlungen für angehende DiGA-Hersteller
  • 1.3 Leitfaden zur DiGAV: Digitale-Gesundheitsanwendungen-Verordnung
  • 1.4 DiGA: Leitfaden zum Nachweis positiver Versorgungseffekte
  • 1.5 DiGA-Leitfaden: Historie aller Änderungen
  • 1.6 Interoperabilität für digitale Gesundheitsanwendungen (DiGA)
  • 1.7 Datensicherheits- & Datenschutz-Zertifikate für DiGA
  • 1.8 DiGA & Software-Medizinprodukte ohne Qualitätsmanagement & Regulatorik zulassen?
  • 1.9 BSI TR-03161 für DiGA: Zertifizierung der Datensicherheit
• 2. DiGA: Finanzen, Businessmodell, Marketing und Vertrieb
  • 2.1 DiGA-Preisverhandlung mit dem GKV-Spitzenverband
  • 2.2 Wie Sie DiGA-Daten für Vertrieb und R&D von Arzneimitteln nutzen können
  • 2.3 DiGA Umsatz & Kosten: Lohnt sich eine DiGA?
  • 2.4 Leitfaden: DiGA-Marketing und Vertrieb
• 3. DiGA: Statistiken und Marktsituation
  • 3.1 Das DiGA-Verzeichnis für Hersteller
  • 3.2 Aktuelle DiGA-Reports 2025: Offizielle Berichte im Überblick
• 4. DiGA: Modelle in Europa
• 5. Medizinprodukt-Entwicklung und Zulassung
• 6. Alternative Erstattungsoptionen zu DiGA
  • 6.1 Selektivverträge mit Krankenkassen: Die Alternative zu DiGA
  • 6.2 Zertifizierung digitaler Kurse nach ZPP – Zentrale Prüfstelle Prävention
  • 6.3 DiPA: Digitale Anwendungen für die Pflege
  • 6.4 Erstattung von Software im GKV-Hilfsmittelverzeichnis (HMV)
  • 6.5 Innovationsfonds und weitere Förderungen für Gesundheitssoftware
• 7. Weitere aktuelle Informationen zur Entwicklung von DiGA und Medizinprodukt-Software

1. DiGA: Entwicklung & Zulassung

Der Weg ins DiGA-Verzeichnis

Die folgenden Fachartikel & Leitfäden beschäftigen sich mit verschiedenen Aspekten der technischen und regulatorischen Entwicklung von DiGA:

1.1 Ist Ihre App eine DiGA? Definition & Kriterien digitaler Gesundheitsanwendungen

Zu Beginn Ihrer Planung stellt sich erstmal die Frage: Ist Ihre Anwendung überhaupt eine DiGA? Erfüllen Sie also alle Kriterien, um sich als DiGA zu qualifizieren?

→ Link zum Artikel

1.2 12 wichtige Empfehlungen für angehende DiGA-Hersteller

Bevor Sie in die Entwicklung einer DiGA einsteigen, sollten Sie von Fehlern anderer DiGA-Hersteller lernen, um diese für Ihr eigenes Vorhaben zu vermeiden. Wir geben exklusive Einblicke und wichtige Empfehlungen aus der Praxis, die Sie bei Ihrer Planung beachten sollten:

→ Link zum Whitepaper

1.3 Leitfaden zur DiGAV: Digitale-Gesundheitsanwendungen-Verordnung

Die DiGAV stellt die Grundlage für die gesetzlichen Anforderungen an digitale Gesundheitsanwendungen dar. Sie erhalten hier einen Überblick, was diese Anforderungen sind.

→ Link zum Artikel

1.4 DiGA: Leitfaden zum Nachweis positiver Versorgungseffekte

In diesem Artikel geben wir Ihnen einen detaillierten Leitfaden darüber, wie der Nachweis positiver Versorgungseffekte zu erfolgen hat. Dies inkludiert Pilotstudie, Evaluationskonzept und die vollumfängliche Studie zur dauerhaften Aufnahme der DiGA.

→ Link zum Artikel

1.5 DiGA-Leitfaden: Historie aller Änderungen

Der offizielle DiGA-Leitfaden ist wohl das wichtigste Dokument, das jeder DiGA-Hersteller gelesen haben sollte. Das BfArM aktualisiert diesen Leitfaden auch regelmäßig. Hierfür gibt es aber bisher leider keine detaillierte Änderungshistorie. Daher untersuchen wir alle Änderungen am DiGA-Leitfaden laufend stellen hier alle Änderungen mit Bildern und Kommentaren übersichtlich für Sie dar.

→ Link zum Artikel

1.6 Interoperabilität für digitale Gesundheitsanwendungen (DiGA)

An eine DiGA werden gesetzlich eine Reihe von Interoperabilitätsanforderungen gestellt. In diesem Artikel erfahren Sie mehr über diese Anforderungen und erhalten praktische Einblicke in die Implementierung von Interoperabilitätsstandards für eine DiGA.

→ Link zum Artikel

1.7 Datensicherheits- & Datenschutz-Zertifikate für DiGA

Digitale Gesundheitsanwendungen müssen strenge Datenschutz- und Datensicherheitsstandards erfüllen, um die Integrität und Vertraulichkeit patientenbezogener Daten zu gewährleisten. In unserem Artikel erhalten Sie einen umfassenden Überblick über die notwendigen Zertifikate und wie diese erlangt werden können.

→ Link zum Artikel

1.8 DiGA & Software-Medizinprodukte ohne Qualitätsmanagement & Regulatorik zulassen?

DiGA und die Medical Device Regulation (MDR) konfrontieren Hersteller mit umfassenden Herausforderungen. Dies umfasst den Aufbau eines Qualitätsmanagementsystems (QMS), das Erstellen detaillierter technischer Dokumentation sowie das Management erhöhter regulatorischer Haftungsrisiken. In diesem Zusammenhang überlegen viele Unternehmen, ob sie die umfangreichen regulatorischen Anforderungen für Medizinprodukte vollständig an einen externen Anbieter delegieren können.

Dies ist tatsächlich vollständig möglich, indem die Rolle des Legalherstellers an ein externes Unternehmen ausgelagert wird.

→ Link zum Artikel

1.9 BSI TR-03161 für DiGA: Zertifizierung der Datensicherheit

Seit dem 01.01.2025 müssen Hersteller digitaler Gesundheitsanwendungen (DiGA) die Erfüllung der Datensicherheitsanforderungen durch ein offizielles Zertifikat nachweisen. Als Basis der Zertifizierung wird die BSI TR-03161 herangezogen, welche 2020 erstmals veröffentlicht wurde.

Auf Basis unserer praktischen Erfahrungen aus mehreren durchgeführten TR-03161-Projekten schildern wir den aktuellen Stand der Zertifizierungsanforderungen.

→ Link zum Artikel

2. DiGA: Finanzen, Businessmodell, Marketing und Vertrieb

Grafik zu den möglichen DiGA-Vetriebswegen

2.1 DiGA-Preisverhandlung mit dem GKV-Spitzenverband

In diesem Artikel wird beschrieben, wie Preisverhandlungen für DiGA mit dem GKV-Spitzenverband geführt werden. Er erklärt die Unterschiede zwischen der vorläufigen und der dauerhaften Aufnahme einer DiGA ins Verzeichnis und die damit verbundenen Zeitfenster für den Beginn der Verhandlungen. Der Artikel gibt einen Überblick über die notwendigen Unterlagen und die Dauer der Verhandlungen sowie die Rolle der Schiedsstelle bei nicht erzielten Einigungen.

→ Link zum Artikel

2.2 Wie Sie DiGA-Daten für Vertrieb und R&D von Arzneimitteln nutzen können

Pharmazeutische Unternehmen ziehen großen Nutzen aus Real-World-Daten über die Zielgruppen ihrer Arzneimittel. Solche Daten sind besonders wertvoll für den Vertrieb bestehender Medikamente und die Entwicklung neuer Produkte.

Aber wie kann man mit einer DiGA Daten erheben, die dann z.B. für die Versorgungsforschung von Arzneimitteln verwendet werden können?

→ Link zum Whitepaper

2.3 DiGA Umsatz & Kosten: Lohnt sich eine DiGA?

Beim Start einer DiGA ist es wichtig, das finanzielle Potenzial zu bewerten. Die zentrale Frage lautet: Ist die Entwicklung Ihrer DiGA-Idee finanziell sinnvoll? Dies fragen sich auch potenzielle Investoren. Sie sollten daher überzeugende Kalkulationen präsentieren, die Gewinn, Umsatzpotential, Marktpotenzial und Kosten umfassen. Dieser Artikel bietet Ihnen eine detaillierte Anleitung und Beispielrechnungen, um das Potenzial Ihrer DiGA für die gewählte Krankheitsindikation genau zu ermitteln.

→ Link zum Artikel

2.4 Leitfaden: DiGA-Marketing und Vertrieb

Auch wenn alle regulatorischen Anforderungen erfüllt sind und Ihre DiGA im zentralen Verzeichnis gelistet wird, ist ein erfolgreicher Markteintritt damit noch nicht garantiert. Der bloße Eintrag bedeutet nicht automatisch, dass Ärzte Ihre DiGA verschreiben werden. Deshalb ist die Auswahl effektiver Marketing- und Vertriebsstrategien entscheidend, um das gesamte Marktpotenzial Ihrer Nische zu nutzen. Die Bandbreite der Möglichkeiten ist groß und das Marktumfeld komplex. Dieser Artikel bietet Ihnen einen Überblick und praktische Tipps.

→ Link zum Artikel

3. DiGA: Statistiken und Marktsituation

3.1 Das DiGA-Verzeichnis für Hersteller

Digitale Gesundheitsanwendungen (DiGA) lassen sich anhand verschiedener Kriterien wie der Medizinprodukt-Risikoklasse, der zuständigen Aufsichtsbehörde, der Dauer der DiGA-Verordnung oder des Listenpreises vergleichen. Unser DiGA-Analyzer bietet im Gegensatz zum BfArM-Verzeichnis speziell für Hersteller angepasste Suchfilter, die eine gezielte Marktanalyse ermöglichen.

→ Link zur DiGA-Verzeichnis-Analyse

DiGA-Statistiken: Aktuelle gelistete DiGA

DiGA Statistiken: Das DiGA-Verzeichnis in Zahlen

Analysieren Sie das DiGA-Verzeichnis mithilfe unseres Echtzeit-Dashboards. Entdecken Sie aktuelle Informationen zur Verteilung der Risikoklassen, den Preisen und Kosten, der Verordnungsdauer und weiteren wichtigen Statistiken über die DiGA-Landschaft.

→ Link zu den DiGA-Statistiken

3.2 Aktuelle DiGA-Reports 2025: Offizielle Berichte im Überblick

Die aktuellsten Zahlen und Berichte für zugelassene digitale Gesundheitsanwendungen (DiGA) sind für die strategische Planung und Marktanalyse neuer DiGA-Projekte von großer Bedeutung.

Verschreibungszahlen und weitere Statistiken finden Sie in Berichten verschiedener Institutionen wie dem GKV-Spitzenverband oder dem Spitzenverband Digitale Gesundheitsversorgung.

Da die Informationen verstreut sein können, bieten wir Ihnen in diesem Beitrag einen chronologischen Überblick und verlinken direkt zu den DiGA-Reports der wichtigsten Herausgeber.

→ Link zu den DiGA-Reports

4. DiGA: Modelle in Europa

Deutschland hat 2019 Pionierarbeit geleistet, indem es ein standardisiertes Modell für die Zulassung digitaler Gesundheitsanwendungen (DiGA) einführte. In der Folge ziehen nun andere Länder in Europa nach und entwickeln ebenfalls DiGA-Modelle oder haben bereits solche implementiert.

In den folgenden Artikeln und Whitepapern werfen wir einen Blick darauf, für welche Länder …

… bereits ein DiGA-Modell existiert,

… ein DiGA-Modell geplant wird,

… oder keinerlei DiGA-Modell in Aussicht steht.

→ DiGA & DTX in Italien
→ DiGA & DTX in Österreich: Zulassung digitaler Gesundheitsanwendungen (2025)
→ DiGA & DT in der Schweiz
→ DiGA & DTX in Frankreich
→ DiGA & DTX in Belgien
→ DiGA & DTX in der EU: Der DiGA-Fast-Track – bald auch europaweit? 

5. Medizinprodukt-Entwicklung und Zulassung

Vor der Zulassung als DiGA muss Ihr Produkt als Medizinprodukt nach Medical Device Regulation (MDR) zugelassen sein. Dies bringt zusätzlich zu den Anforderungen der DiGA-Verordnung viele Herausforderungen im Rahmen der MDR mit sich.

Wir haben eine Vielzahl von Fachartikeln geschrieben, welche sich speziell mit der Zulassung von Software-Medizinprodukten beschäftigen.

→ Link zur Übersicht über alle Artikel zur Medizinprodukt-Entwicklung und Zulassung

6. Alternative Erstattungsoptionen zu DiGA

In unserem Whitepaper „Alle Wege in die Kostenerstattung für medizinische Software und Gesundheits-Apps (in 2025)“ erhalten Sie einen Überblick über sämtliche Wege in die Kostenerstattung.

→ Link zum Whitepaper

Neben der Zulassung als DiGA gibt es eine Reihe weiterer Wege, um DTx bzw. digitale Lösungen in die Erstattung durch Krankenkassen zu bringen. Nicht für jeden Hersteller ist der DiGA-Zulassungsprozess der beste Weg.

In den folgenden Artikeln gehen wir auf andere Erstattungsoptionen im deutschen Gesundheitssystem ein.

6.1 Selektivverträge mit Krankenkassen: Die Alternative zu DiGA

Selektivverträge sind eine spannende Alternative zum stark regulierten DiGA-Zulassungsprozess.

→ Link zum Artikel

6.2 Zertifizierung digitaler Kurse nach ZPP – Zentrale Prüfstelle Prävention

Hersteller, die Produkte zur Krankheitsprävention entwickeln, sollten die Zertifizierungsmöglichkeiten durch die Zentrale Prüfstelle Prävention erwägen.

→ Link zum Artikel

6.3 DiPA: Digitale Anwendungen für die Pflege

DiPA ist das Äquivalent zur DiGA im Pflegebereich. Erfahren Sie, wie Sie DiPA in die Erstattung bringen können.

→ Link zum Artikel

6.4 Erstattung von Software im GKV-Hilfsmittelverzeichnis (HMV)

Softwareprodukte, die als medizinische Hilfsmittel gelten und beispielsweise körperliche Beeinträchtigungen ausgleichen, könnten in das Hilfsmittelverzeichnis aufgenommen werden. Dies eröffnet einen weiteren Weg zur Erstattung durch Krankenkassen.

→ Link zum Artikel

6.5 Innovationsfonds und weitere Förderungen für Gesundheitssoftware

Für Hersteller digitaler Gesundheitslösungen existieren verschiedene öffentliche Förderprogramme – je nach Projektfokus, Reifegrad und Zielmarkt. Eine der zentralen und praxisrelevantesten Förderquellen im deutschen Gesundheitswesen ist dabei zweifellos der Innovationsfonds des G-BA, der gezielt neue Versorgungsformen unterstützt und gerade für Softwareprojekte mit Versorgungsbezug attraktive Möglichkeiten bietet.

→ Link zum Artikel

7. Weitere aktuelle Informationen zur Entwicklung von DiGA und Medizinprodukt-Software

In die Leitfäden und Artikel ist viel Arbeit und Zeit geflossen. Wir hoffen, dass diese Ihnen als Hersteller bei Ihren Herausforderungen ein wenig helfen können.

Zuletzt können wir Ihnen noch unseren Newsletter empfehlen, wo wir monatlich einen detaillierten Bericht zu aktuellen Themen im Bereich der DiGA- und Medizinprodukt-Entwicklung versenden: Zum Newsletter

Aktuelle Entwicklungen und Nachrichten zum Thema DiGA & Medical Software finden Sie auch auf unserer News-Seite.

The post Alle Insights: DiGA-Entwicklung & Zulassung in 2026 appeared first on QuickBird Medical.

In diesem Beitrag möchten wir Ihnen einen Überblick über die Themen geben, zu denen wir bisher geschrieben haben.

Tipp: Wenn Sie neu in der Materie sind, macht es Sinn, dass Sie sich ganz einfach chronologisch von oben nach unten durch die Inhalte arbeiten. 

Inhaltsverzeichnis

• 1. Qualifizierung und Klassifizierung von Software-Medizinprodukten
  • 1.1 Formulierung des Verwendungszwecks für (Software-)Medizinprodukte
  • 1.2 Qualifizierung: Ist Ihre Software ein Medizinprodukt?
  • 1.3 Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden
  • 1.4 MDR-Risikoklasse I vs. IIa: Unterschiede für Software-Medizinprodukte
  • 1.5 Klasse-I-Software gemäß MDR – Ist das noch möglich? (Januar 2025)
  • 1.6 IVDR-Software: Qualifizierung und Klassifizierung
• 2. Leitlinien zu Aspekten der SaMD-Entwicklung und -Zulassung
  • 2.1 Zulassung und Zertifizierung von Software-Medizinprodukten (MDR)
  • 2.2 IEC 62304: Software-Lebenszyklusprozesse für Medizinprodukte
  • 2.3 ISO 13485 – Leitlinien zu Anforderungen und Inhalten
  • 2.4 Software als Medizinprodukt: 11 Zertifizierungstipps für Hersteller
  • 2.5 Validierung von Medizinprodukt-Software gemäß MDR
  • 2.6 MDR-Leitfaden: Klinische Bewertung von Software-Medizinprodukten
  • 2.7 Künstliche Intelligenz (KI) in Medizinprodukten – MDR-Leitfaden (2026)
  • 2.8 Zulassung von Software-Medizinprodukten ohne Qualitätsmanagement und Regulierung?
• 3. Erstattung und Vergütung für Software-Medizinprodukte
  • 3.1 Digitale Gesundheitsanwendungen – unsere detaillierten Leitlinien
  • 3.2 Selektive Verträge mit Krankenkassen: Die Alternative zur DiGA
  • 3.3 Zertifizierung digitaler Kurse gemäß ZPP – Zentralstelle für Prävention
  • 3.4 DiPA: digitale Anwendungen für die Pflege
  • 3.5 Erstattung für Software, die in der GKV-Liste der Hilfsmittel (HMV) enthalten ist
  • 3.6 Innovationsfonds und andere Förderungen für Gesundheitssoftware
  • 3.7 Kostenerstattung für Software in Krankenhäusern
• 4. Weitere aktuelle Informationen zur Entwicklung von Medizinproduktesoftware und DiGA

1. Qualifizierung und Klassifizierung von Software-Medizinprodukten

Zweckbestimmung und Qualifikation von Medizinprodukten

1.1 Formulierung der Zweckbestimmung für (Software-)Medizinprodukte

Zu Beginn jeder Medizinprodukt-Entwicklung sollte die Zweckbestimmung formuliert werden, welche auch als Basis für die Zuordnung zur Risikoklasse nach MDR dient:

→ Link zum Artikel

1.2 Qualifizierung: Ist Ihre Software ein Medizinprodukt?

Nachdem Sie die Zweckbestimmung formuliert haben, stellt sich die Frage „Ist Ihre Software überhaupt ein Medizinprodukt nach MDR?“. Wenn dies nicht der Fall ist, müssen Sie sich auch nicht weiter mit der MDR auseinandersetzen.

Lesen Sie diesen Artikel, um dies für Ihr Produkt herauszufinden.

→ Link zum Artikel

1.3 Klassifizierung von Software-Medizinprodukten: MDR-Leitfaden

Die Risikoklasse eines Medizinprodukts macht einen gewaltigen Unterschied für den notwendigen Aufwand und die Kosten, die Sie für die Zulassung investieren müssen. Sie sollten dies also vor Beginn der Produktentwicklung abklären.

→ Link zum Artikel

1.4 MDR Risikoklasse I vs. IIa: Unterschiede für Software-Medizinprodukte

Gerade zwischen Risikoklasse I und Risikoklasse IIa existieren enorme Unterschiede für Kosten und Zeitplan im Rahmen der Produktentwicklung. Was sind die Unterschiede für Sie in der Praxis?

→ Link zum Artikel

1.5 Klasse I Software nach MDR – Geht das noch? (Januar 2025)

Wir gehen darauf ein, welche Software-Medizinprodukte Stand 2025 noch in Klasse I fallen können.

→ Link zum Artikel

1.6 IVDR-Software: Qualifizierung und Klassifizierung

Falls Ihre Software für den Informationsgewinn durch In-vitro-Untersuchungen bestimmt ist, fällt sie möglicherweise unter die IVDR (In-vitro Diagnostics Regulation). In unserem Leitfaden erfahren Sie, wie Sie Ihre Software unter die IVDR qualifizieren und klassifizieren können, um sicherzustellen, dass sie die relevanten regulatorischen Anforderungen erfüllt.

→ Link zum Artikel

2. Leitfäden zu Aspekten der Entwicklung und Zulassung von SaMD

Timeline: Der Weg zur Medizinproduktzulassung

2.1 Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)

Hier gehen wir einen holistischen Überblick über alle Aspekte der Zulassung von Software as a Medical Device (SaMD) ein.

→ Link zum Artikel

2.2 IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten

Die IEC 62304 ist die wohl zentralste Norm zur Entwicklung von Software-Medizinprodukten. Doch wie genau lässt sich diese in die Praxis umsetzen und lässt sich dies mit agiler Entwicklung vereinen?

→ Link zum Artikel

2.3 ISO 13485 – Leitfaden zu Anforderungen und Inhalten

Das Qualitätsmanagementsystem eines SaMD-Herstellers sollte mit der ISO 13485 im Rahmen der MDR im Einklang stehen. Dies stellt die wichtigste Norm für die Konformität von Qualitätsmanagementsystemen für Medizinprodukte dar.

→ Link zum Artikel

2.4 Software als Medizinprodukt: 11 Zertifizierungs-Tipps für Hersteller

Seit über 10 Jahren entwickeln wir Software-Medizinprodukte auf Auftragsbasis für andere Unternehmen. Wir haben hier unsere wichtigsten Learnings und Tipps für zukünftige Hersteller aufgeschrieben.

→ Link zum Artikel

2.5 Validierung von Medizinprodukt-Software nach MDR

Bevor ein Software-Medizinprodukt auf den Markt gehen kann, muss es formal validiert werden. Was das genau bedeutet, erfahren Sie hier.

→ Link zum Artikel

2.6 MDR-Guide: Klinische Bewertung von Software-Medizinprodukten

Die klinische Bewertung ist das Kernstück der Validierung von Software-Medizinprodukt und stellt manch einen Hersteller vor große Herausforderungen. Wir gehen darauf ein, was Sie in diesem Rahmen tun müssen. Außerdem erklären wir, wann Sie eine klinische Studie/Prüfung durchführen müssen und wann eine Literaturrecherche ausreicht.

→ Link zum Artikel

2.7 Künstliche Intelligenz (KI) in Medizinprodukten – MDR Leitfaden (2026)

Auch MDR-Medizinprodukte dürfen natürlich Künstliche Intelligenz (KI) enthalten. Doch die Zulassung derartiger Produkte bringt eine Reihe von zusätzlichen Herausforderungen mit sich. Hier gehen wir darauf ein, was Sie bei der Entwicklung von KI-Medizinprodukten beachten sollten.

→ Link zum Artikel

2.8 Software-Medizinprodukte ohne Qualitätsmanagement & Regulatorik zulassen?

DiGA und die Medical Device Regulation (MDR) bringen für Hersteller eine Menge Herausforderungen mit sich – von der Einrichtung eines Qualitätsmanagementsystems (QMS) bis zur Erstellung der technischen Dokumentation. Kein Wunder, dass sich viele Unternehmen fragen, ob sie diese Komplexität auslagern können.

Die gute Nachricht: Ja, das geht! Indem die Rolle des Legalherstellers an einen externen Anbieter übertragen wird, lassen sich die regulatorischen Anforderungen komplett an eine dritte Partei auslagern.

→ Link zum Artikel

3. Erstattung & Vergütung von Software-Medizinprodukten

Die Zulassung als Medizinprodukt nach MDR befähigt Sie, Ihr Produkt auf dem Markt zu vertreiben. Das heißt aber noch nicht, dass Sie damit auch Geld verdienen.

Gerade im deutschen Gesundheitssystem ist es oft ratsam, einen Weg in die Erstattung durch Krankenkassen für Ihr Produkt zu finden. Hierfür gibt es je nach Art des Software-Produkts eine Palette an Erstattungsoptionen.

Die folgenden Leitfäden geben Ihnen einen Überblick über wichtige Wege für Software-Produkte in die Erstattung.

3.1 Digitale Gesundheitsanwendungen – unsere detaillierten Leitfäden

Die Zulassung als DiGA stellt für Patienten-orientierte Applikationen bzw. DTx den wohl beliebtesten Weg in die Erstattung dar. Die Zulassung ist aber alles andere als einfach und bringt enorme regulatorische Hürden mit sich. Wir haben zu vielen Aspekten der Zulassung Fachartikel geschrieben, um Herstellern mit Zusatzinformationen zu unterstützen.

→ Link zu allen Insights zur DiGA-Entwicklung und Zulassung in 2025

3.2 Selektivverträge mit Krankenkassen: Die Alternative zu DiGA

Selektivverträge mit Krankenkassen eigenen sich für eine breite Palette von SaMD und sind ein populärer Weg in die Erstattung.

→ Link zum Artikel

3.3 Zertifizierung digitaler Kurse nach ZPP – Zentrale Prüfstelle Prävention

Hersteller von Produkten, die sich auf die Prävention von Krankheiten konzentrieren, sollten sich mit der Zentralen Prüfstelle Prävention auseinandersetzen. Dies stellt einen möglichen Weg dar, die Kosten von derartigen Anwendungen (teilweise) zu vergüten.

→ Link zum Artikel

3.4 DiPA: digitale Anwendungen für die Pflege

Das Pendant zur DiGA in der Pflege sind die DiPA. Wie Sie DiPA potenziell in die Erstattung bringen, erfahren Sie hier.

→ Link zum Artikel

3.5 Erstattung von Software im GKV-Hilfsmittelverzeichnis (HMV)

Software-Produkte, die sich als Hilfsmittel qualifizieren und z.B. eine Fehlfunktion des Körpers ausgleichen, können potenziell ins Hilfsmittelverzeichnis aufgenommen werden. Dies stellt einen weiteren Weg in die Erstattung durch Krankenkassen dar.

→ Link zum Artikel

3.6 Innovationsfonds und weitere Förderungen für Gesundheitssoftware

Für Hersteller digitaler Gesundheitslösungen existieren verschiedene öffentliche Förderprogramme – je nach Projektfokus, Reifegrad und Zielmarkt. Eine der zentralen und praxisrelevantesten Förderquellen im deutschen Gesundheitswesen ist dabei zweifellos der Innovationsfonds des G-BA, der gezielt neue Versorgungsformen unterstützt und gerade für Softwareprojekte mit Versorgungsbezug attraktive Möglichkeiten bietet.

→ Link zum Artikel

Neben dem Innovationsfonds kommen weitere nationale und europäische Förderinstrumente in Betracht, die Entwicklungs-, Studien- oder Implementierungskosten reduzieren und den Markteintritt strategisch absichern können. Einen strukturierten Überblick über relevante Förderprogramme, typische Förderlogiken und strategische Einordnung bietet unser Whitepaper „Finanzierung und Förderung von Digital Health-Produkten“

→ Link zum Artikel

3.7 NUB als Kostenerstattung für Software-Produkte im Krankenhaus

Könnte das NUB-Verfahren („Neue Untersuchungs- und Behandlungsmethoden“) ein Weg sein, um Software-Innovationen im Krankenhaus zu erstatten? Wir haben über 2400 NUB-Anträge analysiert – mit spannenden Ergebnissen zu den Chancen und Grenzen der Kostenerstattung digitaler Lösungen im Krankenhaus.

→ Link zum Artikel

4. Weitere aktuelle Informationen zur Entwicklung von Medizinprodukt-Software und DiGA

In die Erstellung der Leitfäden und Artikel haben wir viel Arbeit und Zeit investiert. Wir hoffen, dass sie Ihnen als Hersteller bei Ihren Herausforderungen Unterstützung bieten können.

Als zusätzliches Angebot empfehlen wir Ihnen unseren Newsletter, in dem wir monatlich detaillierte Berichte zu aktuellen Themen im Bereich der und Medizinprodukt-Software- und DiGA-Entwicklung versenden.

Hier können Sie sich für den Newsletter anmelden: zum Newsletter

The post Alle Insights: Entwicklung & Zulassung von Software-Medizinprodukten in 2026 appeared first on QuickBird Medical.

Ist ein Markteintritt in die Schweiz für MDR-Medizinprodukte ohne Weiteres möglich? Wie kommen Schweizer Hersteller mit Ihren Produkten in den EU-Markt? Und wofür benötigt man einen Bevollmächtigten?

In diesem Artikel klären wir diese und weitere Fragen zum Eintritt in den jeweils anderen Wirtschaftsraum: von der EU in die Schweiz und andersherum.

Wir fokussieren uns hier auf Software-Medizinprodukte, die Inhalte treffen aber ebenso auf andere Arten von Medizinprodukten zu.

Inhalt

• 1. Schweizer Medizinprodukteverordnung (MepV) vs MDR
  • 1.1 Definition Medizinprodukt
  • 1.2 Rahmenabkommen EU-Schweiz
• 2. Als EU-Hersteller auf den Schweizer Markt kommen
  • 2.1 Bevollmächtigter in der Schweiz
  • 2.2 Importeur in der Schweiz
  • 2.3 Anmeldung in der Swissmedic Datenbank
• 3. Als Schweizer Hersteller auf den EU-Markt kommen
  • 3.1 Sie haben noch kein Medizinprodukt
  • 3.2 Sie haben bereits ein Medizinprodukt nach MepV
• 4. Fazit

Hinweis: Da wir in diesem Artikel nicht auf jeden Sonderfall eingehen können, werden hier die Anforderungen beschrieben, die im Allgemeinen für Hersteller gelten. Wir raten aber dazu, sich mit der zuständigen Aufsichtsbehörde in Verbindung zu setzen, um Auskunft zu etwaigen Übergangsregelungen zu erhalten.

1. Schweizer Medizinprodukteverordnung (MepV) vs MDR

Zu Beginn müssen wir uns den rechtlichen Rahmen in der Schweiz und der EU ansehen, um zu verstehen, woran sich Hersteller in den jeweiligen Regionen halten müssen.

Die schweizerische Medizinprodukteverordnung (MepV) ist geltendes Recht für Medizinprodukte in der Schweiz. Zunächst klingt das so, als gäbe es komplett unterschiedliche Regelungen, als jene von der MDR definierten. Bei genauerer Betrachtung finden sich jedoch starke Parallelen, zahlreiche Verweise und sogar komplette Kopien der MDR in der MepV wieder.

Kein Grund zur Panik also – die wichtigsten Unterschiede und die Implikationen, die sich daraus für Sie als Hersteller ableiten, fassen wir in diesem Artikel zusammen.

1.1 Definition Medizinprodukt

Die Definition eines Medizinprodukts ist in MDR und MepV nahezu deckungsgleich – bis auf ein paar unterschiedliche Formulierungen. Somit gibt es im Bereich der Qualifikation keinen Mehraufwand für EU- und Schweizer-Hersteller, wenn sie ihren Markt auf die EU bzw. Schweiz erweitern möchten.

Wenn Sie noch nicht wissen, ob es sich bei Ihrem Produkt um ein Medizinprodukt handelt, lesen Sie unseren Leitfaden: Ist meine App ein Medizinprodukt?

1.2 Rahmenabkommen EU-Schweiz

Ein geltendes Rahmenabkommen zwischen der Schweiz und der EU wurde lange diskutiert, ist am Ende aber leider gescheitert. Eine genaue Erörterung der Gründe dafür liefert für Sie als Hersteller keinen wirklichen Mehrwert, daher werden wir dieses Thema nicht weiter behandeln. Wichtig ist an dieser Stelle nur:

• Die Schweiz gilt als Drittland im Sinne der MDR.

Das bedeutet noch konkreter:

• Sie brauchen einen Bevollmächtigten mit Sitz in der Schweiz oder der EU, um ein Medizinprodukt auf den jeweiligen Markt bringen zu können (sofern Sie keinen eigenen Sitz dort haben). 

Das Rahmenabkommen der EU mit der Schweiz vereinfacht dargestellt

2. Als EU-Hersteller auf den Schweizer Markt kommen

Wenn Sie als Medizinprodukt-Hersteller nur in der EU ansässig sind und keinen Sitz in der Schweiz haben, besitzen Ihre Produkte bestimmt eine MDD- oder MDR-Zulassung. An dieser Stelle gibt es gute Nachrichten: Produkte, die eine CE-Kennzeichnung tragen, dürfen auch in der Schweiz auf den Markt gebracht werden und es gelten keine zusätzlichen Zertifizierungspflichten. 

Die Swissmedic (schweizerische Zulassungs- und Aufsichtsbehörde für Arzneimittel und Medizinprodukte) schreibt auf ihrer Webseite explizit, dass Produkte mit einer CE-Kennzeichnung in der Schweiz in Verkehr gebracht werden können. Die Hauptfunktion der Swissmedic läge insbesondere in der Überwachung von Medizinprodukten, weniger in deren Zulassung.

Dennoch gibt es ein paar Dinge, die Sie tun müssen, um Ihr Produkt legal in der Schweiz vertreiben zu können:

• Ernennung eines Bevollmächtigten in der Schweiz
• Weisung des Bevollmächtigten und Klärung der Pflichten
• Anmeldung des Bevollmächtigten und Ihres Produkts in der Swissmedic Datenbank
• Veröffentlichung von Kurzberichten zur Sicherheit und Leistungsfähigkeit von Produkten (nur für Klasse III- und implantierbare Produkte)
• Bestimmung eines Importeurs in der Schweiz

2.1 Bevollmächtigter in der Schweiz

Wenn Ihr Unternehmen keinen eigenen Firmensitz in der Schweiz hat, müssen Sie einen Bevollmächtigten ernennen, welcher diverse Pflichten aus der MepV bzw. MDR für Sie übernimmt. Dieser Repräsentant muss eine natürliche oder juristische Person mit Sitz in der Schweiz sein.

Der Bevollmächtigte ist zuständig für die formellen und sicherheitsrelevanten Belange im Zusammenhang mit dem Inverkehrbringen des Produkts. Dazu zählt beispielsweise die Pflicht zur Meldung von Vorkommnissen und Trends, für die nach schweizerischem Recht immer der Bevollmächtigte verantwortlich ist (anders als in der MDR). 

Wenn Sie die Pflichten des Bevollmächtigten in Artikel 51, MepV nachlesen, sehen Sie schnell, dass diese ansonsten (fast) deckungsgleich mit jenen der MDR sind. Dort wird nämlich schlichtweg auf Artikel 11 der MDR verwiesen.

Welche Aufgaben Sie an den Bevollmächtigten delegieren, bleibt zum Teil Ihnen überlassen, allerdings gibt es hier Einschränkungen. Nicht alle Herstellerpflichten können an den Bevollmächtigten abgegeben werden – dazu zählt beispielsweise die Durchführung einer klinischen Bewertung oder die Verantwortung für das Risikomanagement (alle Ausnahmen finden Sie in Absatz 4, Artikel 11 MDR).

Unabhängig davon hat der Bevollmächtigte die Pflicht, bei einer Anfrage der Behörde innerhalb von sieben Tagen dafür zu sorgen, dass diese die vollständige technische Dokumentation zu einem Produkt erhält. Der Schweizer Bevollmächtigte ist allerdings nicht dazu verpflichtet, eine Kopie dieser Dokumentation selbst zu haben – diese kann beim Hersteller bleiben. 

Für die Rolle des Bevollmächtigten eignen sich beispielsweise Dienstleister, die diesen Service in der Schweiz anbieten.

2.2 Importeur in der Schweiz

Zusätzlich zu einem Bevollmächtigten, welcher gewisse Pflichten im Sinne der Medizinprodukt-Regulatorik übernimmt, benötigen EU-Hersteller auch einen Importeur in der Schweiz, um das Produkt dort in Verkehr zu bringen. 

Die MepV definiert den Importeur als “jede in der Schweiz niedergelassene natürliche oder juristische Person, die ein Produkt aus dem Ausland auf dem Schweizer Markt in Verkehr bringt;”

Dieser hat ähnliche Pflichten, wie der Bevollmächtigte – im Detail nachzulesen sind diese in Artikel 13 und 16 der MDR bzw. Artikel 51 der MepV. Im Unterschied zum Bevollmächtigten benötigt er aber keine Person mit dem notwendigen regulatorischen Fachwissen im Medizinprodukte-Bereich. Ein Importeur übernimmt zum Beispiel aber auch bestimmte Pflichten in Bezug auf die Lagerung und den Transport von Medizinprodukten – da es sich bei (reiner) Software aber um kein physisches Produkt handelt, ist diese Anforderung bei Software-Medizinprodukten in der Regel nicht sinnvoll umsetzbar.

Auch der Bevollmächtigte selbst kann die Rolle des Importeurs übernehmen. In diesem Fall sind allerdings beide Rollen in der Swissmedic Datenbank anzumelden. Mehr dazu erfahren Sie im nächsten Kapitel.

2.3 Anmeldung in der Swissmedic Datenbank

Jeder Wirtschaftsakteur (Hersteller, Bevollmächtigter und Importeur) muss sich innerhalb von 3 Monaten, nachdem ein Medizinprodukt in der Schweiz in Verkehr gebracht wurde, in der Swissmedic Datenbank anmelden. Dabei werden Name, Anschrift und Kontaktdaten des Wirtschaftsakteurs, sowie der verantwortlichen Person gefordert. Nach der Registrierung erhält dieser eine CHRN – dabei handelt es sich um eine eindeutige Kennung. Sie ist das Äquivalent zur SRN in EUDAMED.

Der deutsche DiGA-Fast-Track – ein Modell für ganz Europa?

In diesem Whitepaper sehen wir uns an, in welchen EU-Ländern bereits ein DiGA-Modell existiert, ein DiGA-Modell geplant wird oder keinerlei DiGA-Modell in Aussicht steht. Außerdem klären wir die Frage: Kommt ein standardisiertes Modell in Europa für die EU-DiGA?

3. Als Schweizer Hersteller auf den EU-Markt kommen

Wenn Sie als Schweizer Hersteller ein Produkt auf den EU-Markt bringen wollen, müssen wir zunächst unterscheiden, ob Sie bereits ein Medizinprodukt haben, oder dessen Entwicklung erst bevorsteht. Beide Fälle beleuchten wir in den nachfolgenden Kapiteln.

WICHTIG: Als Schweizer Hersteller ohne Sitz in der EU benötigen Sie in jedem Fall einen Bevollmächtigten/Repräsentanten, sowie einen Importeur mit Sitz in der EU. Zudem müssen Sie Ihr Medizinprodukt in der EUDAMED Datenbank anmelden.

3.1 Sie haben noch kein Medizinprodukt

Bei der Entwicklung von Medizinprodukten für die EU gilt in erster Linie die MDR. 

Da die MDR in der Schweiz anerkannt ist und die MepV an vielen Stellen darauf verweist, sind die Anforderung an die Produktentwicklung zum größten Teil identisch. Dazu zählt zum Beispiel der Aufbau eines Qualitätsmanagementsystems und die Erstellung einer technischen Dokumentation. Die genauen Anforderungen haben wir in anderen Blogartikeln bereits zusammengefasst:

• Leitfaden für die Entwicklung von Medical Apps: Darauf müssen Hersteller achten (MDR)
• Leitfaden: Ist Ihre App ein Medizinprodukt?

Die Frage, ob Sie zuerst den Schweizer- (unter MepV) oder den EU-Markt (unter MDR) betreten möchten, sollten Sie zu Beginn klären. Beides hat gewisse Vor- und Nachteile, welche Sie für Ihr Unternehmen abwägen müssen. Dazu müssen Sie unter anderem herausfinden, welcher Markt für Sie interessanter ist und inwiefern Sie Ihre technische Dokumentation offenlegen möchten (z.B. an einen EU-Bevollmächtigten).

Falls Sie bereits ein Medizinprodukt entwickelt und zugelassen haben, lesen Sie im nächsten Kapitel weiter.

3.2 Sie haben bereits ein Medizinprodukt nach MepV

Wenn Sie bereits ein Medizinprodukt konform mit der MepV entwickelt haben, haben Sie für das Produkt auch ein Konformitätsbewertungsverfahren durchgeführt. Bevor Sie das Produkt nun auf den EU-Markt bringen können, müssen Sie prüfen, ob das durchgeführte Verfahren auch für die EU zulässig ist. Sofern eine bezeichnete Stelle in die Konformitätsbewertung des Medizinprodukts involviert war, stellen Sie sicher, dass diese auch als benannte Stelle nach MDR anerkannt ist. In vielen Fällen ist dies nämlich nicht der Fall und Sie müssen ein weiteres Konformitätsbewertungsverfahren gemäß MDR durchführen.

Außerdem benötigen Sie einen Bevollmächtigten und einen Importeur mit Sitz in der EU und müssen Ihr Produkt in EUDAMED anmelden. Mehr dazu erfahren Sie in den folgenden Kapiteln.

3.2.1 Konformitätsbewertungsverfahren nach MDR

Um die CE-Kennzeichnung auf einem Medizinprodukt anbringen zu können, müssen Hersteller ein sogenanntes Konformitätsbewertungsverfahren durchführen. Die MDR bietet drei verschiedene Bewertungsverfahren, welche deckungsgleich mit den Verfahren der MepV sind. Bei Software-Produkten handelt es sich dabei meist um eine Bewertung auf Basis des Qualitätsmanagementsystems und der technischen Dokumentation. Zu diesem Thema finden Sie weitere Informationen in unserem Artikel: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)

3.2.2 Bevollmächtigter & Importeur in der EU

Genauso wie EU-Hersteller in der Schweiz, benötigen auch Schweizer Hersteller in der EU einen Bevollmächtigten (auch “Repräsentant”), um ihre Produkte auf dem EU-Markt vertreiben zu können. 

Der Bevollmächtigte in der EU hat dieselben Pflichten, wie sein Äquivalent in der Schweiz (siehe weiter oben) – mit einer Ausnahme:

Der EU-Repräsentant muss über eine Kopie der technischen Dokumentation und der EU-Konformitätserklärung verfügen und diese auf Anfrage den zuständigen Behörden bereitstellen können.

Genauso wie in der Schweiz, benötigen Hersteller auch innerhalb der EU einen Importeur, welcher das Produkt in die EU importiert und auf dem Markt verfügbar macht.

Sie sind Medizinprodukt-Hersteller mit Sitz in der Schweiz? Dann sprechen Sie uns an – wir übernehmen gerne die Rolle des Bevollmächtigten und des Importeurs und stellen ein reibungsloses Inverkehrbringen Ihrer Produkte in der EU sicher.

3.3.3 Anmeldung in EUDAMED

Alle Wirtschaftsakteure (Hersteller, Bevollmächtigter und Importeur) müssen in EUDAMED registriert sein. Diese Anmeldung erfolgt über das entsprechende Online-Portal, nach welcher Sie eine SRN (eindeutige Kennung) erhalten.

Auch Medizinprodukte selbst müssen in der EUDAMED Datenbank registriert werden. Alles über die Zertifizierung und Zulassung von Medizinprodukten unter MDR erfahren Sie in unserem Artikel: Zulassung & Zertifizierung von Software-Medizinprodukten (MDR)

4. Fazit

Da aktuell kein Abkommen mehr zwischen der Schweiz und der EU besteht, wird die Schweiz im Sinne der MDR als Drittland behandelt. Das bedeutet, dass Medizinprodukt-Hersteller einen Bevollmächtigten/Repräsentanten in der EU brauchen, um ein Produkt dort in Verkehr zu bringen. Andersherum verhält es sich genauso, jedoch werden Medizinprodukte mit einer CE-Kennzeichnung in der Schweiz einseitig anerkannt, sodass für EU-Hersteller keine zusätzlichen Zertifizierungspflichten bestehen.

Schweizer Hersteller hingegen müssen häufig ein weiteres Konformitätsbewertungsverfahren (unter Einbezug einer benannten Stelle) durchführen, um Ihre Medizinprodukte in der EU anbieten zu können.

Mit Sitz in Deutschland übernimmt QuickBird Medical gerne die Rolle des Bevollmächtigten und des Importeurs innerhalb der EU. Sprechen Sie uns an, wenn Sie Unterstützung bei dem Inverkehrbringen oder der Entwicklung von MDR-Medizinprodukten benötigen. Wir helfen Ihnen gerne weiter.

Jetzt kontaktieren!

The post Medizinprodukte und die Schweiz: was Sie über MepV und MDR wissen müssen appeared first on QuickBird Medical.

Dieser Prozess für die Zulassung von DiGA diente als Vorbild für Länder wie Frankreich und Belgien. Beide Länder entwickelten daran angelehnte Zulassungs- und Erstattungsprozesse. Auch in Österreich ist es geplant, DiGA in die reguläre Gesundheitsversorgung zu integrieren.

Bedingt durch ihre Lage ist auch ein Blick in die Schweiz interessant. Dort werden digitale Gesundheitsanwendungen „dGA“ genannt. Kommt das deutsche DiGA-Modell im nächsten Schritt auch in die Schweiz? Und welche Erstattungsmöglichkeiten für dGA gibt es dort jetzt schon?

Update Dezember 2025: Mit Beginn zum 1. Juli 2026 übernimmt die obligatorische Krankenpflegeversicherung in der Schweiz u.a. die Kosten für digitale Gesundheitsanwendungen zur kognitiven Verhaltenstherapie bei leichten bis mittelschweren depressiven Episoden. Mehr dazu finden Sie im unten stehenden Fachartikel.

Wir widmen uns in diesem Artikel

• den grundsätzlichen Eigenschaften des schweizerischen Gesundheitssystems
• der Frage, ob dGA in der Schweiz eine feste Definition haben
• den bisherigen Erstattungsmöglichkeiten und
• der Frage, ob ein DiGA-ähnlicher Zulassungsprozess in der Schweiz etabliert wird.

Inhaltsverzeichnis

• 1. Überblick: Aufbau des Gesundheitssystems und der Krankenversicherung der Schweiz
  • 1.1 Das Gesundheitssystem
  • 1.2 Die Krankenversicherung
• 2. Anforderungen an DiGA
• 3. Definition von DiGA in der Schweiz
• 4. Aktuelle Erstattungsmöglichkeiten für DiGA
  • 4.1 Vergütung innerhalb MiGel (Mittel- und Gegenständeliste)
  • 4.2 Vertrauensprinzip und ärztliche Leistungen
  • 4.3 Fallpauschalen
  • 4.4 Komplexpauschalen (Bundled Payments)
  • 4.5 Leistungspflicht in Evaluation
  • 4.6 Pilotprojekte im Rahmen des KVG
  • 4.7 Selbstzahler und Krankenzusatzversicherungen
• 5. Zukunft: DiGA-Fast-Track bald in der Schweiz?
• 6. Fazit

1. Aufbau des Gesundheitssystems und Krankenversicherung

Zum besseren Verständnis, auf welches Umfeld DiGA in der Schweiz treffen, schauen wir uns zuerst an, wie das Gesundheitssystem dort funktioniert. Dies ist insofern von Bedeutung, als die historisch gewachsenen Gesundheitssysteme europäischer Länder selten miteinander vergleichbar sind: Unterschiede in Aufbau, Zuständigkeiten und Institutionen sowie Finanzierungssystemen erzeugen schlussendlich sehr unterschiedliche Anreizsysteme für alle beteiligten Gruppen.

Die Schweiz als Land in Europa, aber außerhalb der EU, ist hier keine Ausnahme.

1.1 Das Gesundheitssystem

Das schweizerische Gesundheitssystem ist dezentral organisiert. Während Gesetze und Vorschriften auf Bundesebene gelten, liegt die praktische Umsetzung bei den weitgehend autonom entscheidenden Kantonen: Ein Kanton in der Schweiz ist ein Gebiet mit eigener Regierung, eigenem Parlament und eigenen Gesetzen, das zusammen mit anderen Kantonen die Schweiz bildet.

Auch die Krankenversicherung ist kantonal sowie privatwirtschaftlich organisiert. Dies führt zu einer zersplitterten Gesundheitslandschaft, die jedoch für die Schweizer Bevölkerung im Allgemeinen eine sehr hochqualitative Versorgung bei gleichzeitig hoher finanzieller Eigenbeteiligung bietet.

Während auf Bundesebene vor allem die Gesetzgebung angesiedelt ist, können die Kantone die Umsetzung weitgehend selbst gestalten. Dadurch entsteht eine fragmentierte Gesundheitslandschaft.

1.2 Die Krankenversicherung

Seit 1996 gilt in der Schweiz eine Versicherungspflicht für die obligatorische Krankenpflegeversicherung (OKP). Die OKP deckt Gesundheitskosten, sobald die jährliche Mindestbeteiligung überschritten ist. Versicherte tragen weiterhin 10 % der Kosten bis zu einem Maximum von derzeit 700 Franken (Erwachsene) bzw. 350 Franken (Kinder) pro Jahr.

Die Beiträge variieren je nach Wohnort, Alter, gewählter Selbstbeteiligung (Franchise), Zusatzleistungen und Versicherungsmodell. Sie werden von den rund 40 Versicherern individuell festgelegt und jährlich vom Bundesamt für Gesundheit freigegeben. Arbeitgeber leisten keinen Beitrag.

Das Bundesamt für Gesundheit legt gültig für die gesamte Schweiz fest, welche Leistungen im Rahmen dieser Pflichtversicherung übernommen werden. Darüber hinaus bieten Krankenversicherungen eine Vielzahl an Zusatzversicherungen und Spezialtarifen an.

Die hohe Eigenbeteiligung der Versicherten, steigende Kosten und wachsende Prämien stellen das System vor große Herausforderungen.

2. Anforderungen an DiGA

In unserem Artikel „Medizinprodukte und die Schweiz: Was Sie über MepV und MDR wissen müssen“ finden Sie eine detaillierte Aufstellung dazu, welche Voraussetzungen Sie erfüllen müssen, um Ihr Software-Medizinprodukt in der Schweiz auf den Markt bringen zu können. Unberührt davon ist das Thema der Erstattung:

• Zulassung bedeutet, dass ein Medizinprodukt offiziell in der Schweiz verkauft und verwendet werden darf. Dafür muss das Produkt vereinfacht gesprochen nachweisen, dass es sicher ist und seinen medizinischen Zweck erfüllt. Die Zulassung wird durch gesetzliche Vorgaben geregelt. Mehr dazu finden Sie in unserem Leitfaden zur Medizinprodukt-Zulassung in der Schweiz.
• Erstattung bedeutet, dass etwa die Krankenversicherungen die Kosten für ein Produkt ganz oder teilweise übernehmen, sodass Patienten nicht (alles) selbst zahlen müssen.

In diesem Artikel geht es vor allem um Letzteres: alle Wege in die Erstattung für digitale Gesundheitsanwendungen in der Schweiz.

3. Definition von dGA: DiGA in der Schweiz

Vom Bundesamt für Gesundheit wurden DiGA im aktualisierten „Faktenblatt Vergütung von digitalen Gesundheitsanwendungen im Rahmen der OKP“ im November 2024 folgendermaßen definiert:

Unter digitalen Gesundheitsanwendungen (dGA) werden Produkte verstanden, welche zur Gesundheitsförderung, zur Unterstützung und Information von Patientinnen und Patienten, oder zu medizinischen Zwecken dienen und digitale Technologien nutzen.

Bei einer dGA kann es sich um eine Software, eine App, ein mobiles Gerät (z.B. Sensoren für die Erfassung von Körperparametern und Software zur digitalen Auswertung oder Übermittlung), oder auch um eine Kombination davon handeln. Auch kann der Einsatz von künstlicher Intelligenz (KI) zur Anwendung kommen. Ebenfalls kann eine dGA in Kombination mit einem nicht digitalen physischen Produkt (z.B. Personenwaage) zur Anwendung kommen. dGA können zur Selbstanwendung durch Patientinnen und Patienten oder gesunden Personen bestimmt sein oder zur Anwendung durch Fachpersonal.

Die Schweiz nutzt eine sehr breite Definition für digitale Gesundheitsanwendungen, die hier „dGA“ genannt werden.

Folgende Zwecke für eine dGA sind also möglich:

• Gesundheitsförderung (z. B. Fitness-, Ernährungs-, Bewegungs- oder Wellness-Apps)
• Unterstützung und Information (allgemeine, krankheitsbezogene Informationen und Verhaltensempfehlungen, ggf. mit Symptomtracking; wenn zur Information von Gesundheitspersonal gedacht, auch medizinischer Zweck denkbar)
• Medizinischer Zweck (Früherkennung, Verhütung, Diagnose, Überwachung, Prognose, Behandlung oder Linderung sowie Pflege von Krankheiten oder deren Folgen oder bei Mutterschaft)

Folgende Produktarten sind eingeschlossen:

• Software-Produkte
• Produkte, die Sensoren enthalten
• Produkte, die zusammen mit externer Hardware zur Anwendung kommen.

Nur für Produkte mit medizinischem Zweck ist dabei die Medizinprodukteverordnung (MepV) relevant.

Mehr zu verschiedenen Erstattungsmöglichkeiten von digitalen Gesundheitsanwendungen finden Sie im nächsten Kapitel.

4. Aktuelle Erstattungsmöglichkeiten für dGA

Nun interessieren Sie sich vermutlich dafür, ob DiGA im Rahmen des schweizerischen Gesundheitssystems vergütet werden können und ob es einen speziellen Zulassungsprozess gibt wie den deutschen DiGA-Fast-Track.

Digitale Gesundheitsanwendungen mit medizinischem Zweck werden in der Schweiz wie jedes andere (nicht-digitale) Medizinprodukt behandelt. Ein immer noch aktuelles Diskussionspapier aus dem Jahr 2022 skizziert folgende Möglichkeiten:

4.1 Vergütung innerhalb MiGel (Mittel- und Gegenständeliste)

DiGA können vom Bundesamt für Gesundheit (BAG) in die Leistungen der OKP (obligatorische Krankenpflegeversicherung) aufgenommen werden. Dabei handelt es sich um die Mindestversorgung, die Krankenversicherer ihren Versicherten anbieten müssen. Was zu dieser Mindestversorgung gehört, wird immerhin auf nationaler Ebene durch das BAG festgelegt und gilt somit in allen Kantonen.

Dafür müssten DiGA in die “Mittel- und Gegenstände-Liste” (MiGeL) aufgenommen werden, eine Art Hilfsmittelverzeichnis wie es auch in Deutschland existiert. Dort sind alle Hilfsmittel gelistet, die von der obligatorischen Krankenversicherung (OKP) übernommen werden. Beispiele wären Rollstühle oder Hörgeräte. Für jedes Produkt sind Produktgruppen, Preisobergrenzen, Mengen und Voraussetzungen für die Kostenübernahme aufgeführt.

Das MIGEL-Verzeichnis in der Schweiz ist für digitale Gesundheitsanwendungen nur bedingt geeignet, da die dort vorgesehenen Prozesse zur Abbildung von Innovationen zu langwierig sind. Sie dauern oftmals mehrere Jahre und stehen damit im starken Kontrast zu den kurzen Innovationszyklen digitaler Technologien.

Zusätzlich zur Einhaltung der Regeln nach MepV müssen Medizinprodukte für die Aufnahme in die MiGeL das sogenannte WZW-Prinzip erfüllen. Sie werden bei Antragstellung zur Vergütung nach OKP geprüft auf

1. Wirksamkeit
2. Zweckmäßigkeit
3. Wirtschaftlichkeit

Das WZW-Prinzip nach KVG
Quelle: Kohler, S., & Rau, A. (2023, 26. April). Vergütung von digitalen Gesundheitsanwendungen (DiGA) in der Schweiz. VISCHER.

Aktuelle Entwicklungen: Hier kam es Ende 2025 zu den ersten positiven Entwicklungen. Mit Beginn zum 1. Juli 2026 übernimmt die obligatorische Krankenpflegeversicherung die Kosten für DiGA zur kognitiven Verhaltenstherapie bei leichten bis mittelschweren depressiven Episoden sowie bei wiederkehrenden depressiven Störungen, die als Ergänzung oder Überbrückung zur Psychotherapie eingesetzt werden. Die als erste in der MiGeL aufgeführte DiGA ist die in Deutschland bereits dauerhaft gelistete DiGA deprexis“.

4.2 Vertrauensprinzip und ärztliche Leistungen

Für DiGA, die im Zusammenhang mit ärztlichen Leistungen stehen, kommt das sogenannte Vertrauensprinzip zur Anwendung. Dieses besagt, dass bei ärztlichen Leistungen grundsätzlich davon ausgegangen wird, dass sie den gesetzlichen Anforderungen an Wirksamkeit, Zweckmäßigkeit und Wirtschaftlichkeit entsprechen.

Aber:

Derzeit bestehen noch Unklarheiten bezüglich der konkreten Anwendung dieses Prinzips auf digitale Anwendungen. Aktuell gibt es zudem keine spezifisch auf digitale Leistungen ausgerichteten Abrechnungsmodelle im ärztlichen Tarifwesen. Auch die Integration solcher Leistungen in bestehende ärztliche Tarife ist noch nicht abschließend geregelt.

4.3 Fallpauschalen

Fallpauschalen kommen bisher vor allem im stationären Bereich zur Anwendung, sind aber auch für den ambulanten Bereich vorgesehen. DiGA könnten Bestandteil eines umfassenden Behandlungsprogrammes sein, das pauschal vergütet wird. In solchen Fällen muss klar definiert sein, welche Leistungen Bestandteil der Pauschale sind und wie diese tariflich berücksichtigt werden.

DiGA könnten insbesondere dann eingebunden werden, wenn sie Bestandteil eines standardisierten Behandlungspfades sind, der auch ärztliche Verordnungen und fachliche Begleitung der Patienten umfasst.

4.4 Komplexpauschalen (Bundled Payments)

Komplexpauschalen fassen verschiedene Leistungen eines Behandlungspfades über mehrere Leistungserbringer hinweg zusammen und vergüten diese pauschal. Sie können insbesondere bei planbaren Eingriffen und der Versorgung chronisch Erkrankter eingesetzt werden. Es handelt sich um eine relativ neue Möglichkeit zur Leistungsabrechnung.

Dabei werden Behandlungspfade definiert, die unterschiedliche Leistungsbestandteile (z. B. ärztliche Leistungen, DiGA, begleitende Betreuung) umfassen.

Neue Vergütungsmodelle wie die Komplexpauschalen haben es jedoch schwer, weil die bestehenden Strukturen und fehlende Anreize der Tarifpartner diesen im Weg stehen. Hürden sind unter anderem die unzureichende Einbindung der Leistungserbringer, die doppelte Spitalfinanzierung, der Kontrahierungszwang – also die Pflicht der Krankenkassen, mit allen zugelassenen Leistungserbringern Verträge abzuschließen – sowie das Verbot von Mehrjahresverträgen und rechtliche Unsicherheiten.

4.5 Leistungspflicht in Evaluation

Gemäß Art. 33, Abs. 3 KVG kann der Bundesrat vorsehen, dass neue oder umstrittene Leistungen – auch digitale – im Rahmen einer befristeten Leistungspflicht unter bestimmten Bedingungen vergütet werden, solange ihre Wirksamkeit, Zweckmäßigkeit und Wirtschaftlichkeit noch nicht abschließend geklärt sind. Dieses Verfahren wird als „Leistungspflicht in Evaluation“ bezeichnet. Eine Checkliste des Bundes dient der Bewertung, ob eine DiGA in dieses Verfahren aufgenommen werden könnte.

4.6 Pilotprojekte im Rahmen des KVG

Nach Art. 59b E-KVG können Pilotprojekte initiiert werden, um neue Modelle zur Kostensteuerung, Qualitätssicherung oder Digitalisierung zu testen. Diese Projekte können gezielte Ausnahmen im KVG-Rahmen erhalten, sind jedoch zeitlich und räumlich begrenzt und unterliegen einer Evaluation.

Für deren Durchführung ist eine Einigung zwischen den beteiligten Tarifpartnern erforderlich, ebenso wie substanzielle Vorleistungen durch die Projektpartner. Die Ergebnisse solcher Pilotprojekte könnten als Grundlage für spätere gesetzliche Anpassungen dienen, insbesondere bei der Entwicklung neuer Vergütungs- oder Versorgungsmodelle.

4.7 Selbstzahler und Krankenzusatzversicherungen

Zuletzt sei noch die Möglichkeit erwähnt, eine DiGA schlicht als Medizinprodukt auf den Schweizer Markt zu bringen und individuell an Selbstzahler zu vermarkten oder mit zugelassenen privaten Krankenversicherern in Verhandlungen über eine Kostenübernahme im Rahmen privater Zusatzversicherungen zu treten. In einem Leitfaden des Digital Center Bülach (LinkedIn) wird jedoch darauf hingewiesen, dass die Kostenübernahme durch einen oder mehrere Krankenversicherer die Übernahme über die zuvor beschriebenen Wege ausschließt. Andersherum gilt dies genauso.

5. Zukunft: DiGA-Fast-Track bald in der Schweiz?

Nun stellt sich die Frage, ob sich die Schweiz von ihren Nachbarländern inspirieren lässt, einen gesonderten Zulassungs- und Erstattungsprozess für „dGA“ zu etablieren, Stichwort DiGA-Fast-Track.

Bei einem Blick in die Strategie eHealth Schweiz 2.0, ist jedoch von DiGA nichts zu lesen. “Digitale Anwendungen” sind im Rahmen der Strategie lediglich in Form des elektronischen Patientendossiers erwähnt. Dies scheint allerdings noch nicht den Vorstellungen des Gesetzgebers nach umgesetzt zu sein, da eine Weiterentwicklung im Sommer 2023 vom Bundesrat veranlasst wurde.

Auch im Anschlussprogramm DigiSanté: Förderung der digitalen Transformation im Gesundheitswesen werden keine Pläne zur Implementierung von speziellen Zulassungs- und Erstattungswegen für DiGA erwähnt. Zentrales Ziel des Programms ist, dass “der Rückstand der Schweiz in der Digitalisierung des Gesundheitswesens aufgeholt” wird.

Dennoch ist eine vorsichtige Öffnung der OKP für digitale Therapien erkennbar. Die geplante Aufnahme digitaler Anwendungen zur kognitiven Verhaltenstherapie in die Leistungspflicht ab dem 1. Juli 2026 zeigt, dass digitale Gesundheitsanwendungen zumindest indikationsspezifisch zunehmend als regelversorgungsfähig angesehen werden. Dies könnte mittelfristig auch die Diskussion um strukturiertere Zulassungs- und Erstattungswege für weitere digitale Anwendungen befördern.

6. Fazit: Erstattung von dGA

In der Schweiz sind digitale Gesundheitsanwendungen (DiGA) bisher nicht als eigenständige Kategorie in die obligatorische Krankenpflegeversicherung integriert, und es existieren keine speziellen Zulassungs- oder Erstattungswege wie der DiGA-Fast-Track in Deutschland. Erste Ansätze, digitale Gesundheitsanwendungen über Zusatzversicherungen oder spezielle Programme anzubieten, sind vorhanden, bleiben jedoch begrenzt. Mit den jüngsten Entwicklungen in Bezug auf Psychotherapie-Anwendungen, könnte sich aber langfristig die MiGeL als ein vielversprechender Erstattungsweg für DiGA-Hersteller in der Schweiz etablieren.

Über unseren Newsletter halten wir Sie zum Stand von DiGA in der Schweiz und anderen Ländern auf dem Laufenden.

Für einen Überblick über den Erstattungsprozess von digitalen Gesundheitsanwendungen in anderen Ländern der EU sehen Sie sich folgende Whitepaper und Fachartikel an:

• DiGA in Deutschland
• DiGA in Frankreich
• DiGA in Belgien
• DiGA in Österreich
• DiGA in Italien
• Überblick über Zulassung von DiGA in allen Ländern der EU

Außerdem gibt es eine breite Palette von öffentlichen Förderungen (siehe unser Praxisleitfaden zu Digital Health-Förderungen) und anderen Erstattungswegen (siehe unser Whitepaper zu Selektivverträgen) für Health-Software.

Über uns: Wir bei QuickBird Medical entwickeln digitale Gesundheitsanwendungen und medizinische Software auf Auftragsbasis für Kunden der Gesundheitsbranche. Hierfür sind wir nach ISO 13485 und ISO 27001 zertifiziert. Wenn Sie ein digitales Produkt im Gesundheitswesen planen, setzen Sie sich gern mit uns über das Kontaktformular in Verbindung.

The post Schweiz: Erstattung von Digitalen Gesundheitsanwendungen (DiGA & dGA) appeared first on QuickBird Medical.

Die ISO 13485 ist eine Norm, welche Anforderungen an ein Qualitätsmanagementsystem für Medizinprodukt-Hersteller definiert. Im Kern dabei soll das Ziel verfolgt werden, sichere und funktionstaugliche Produkte zu entwickeln.

Doch wie genau soll das gelingen? Was ist ein prozessbezogener Ansatz? Was sind die Inhalte der ISO 13485 und wie setze ich sie in meinem Software-Unternehmen um?

In diesem Artikel beantworten wir die wichtigsten Fragen zu den Inhalten, Anforderungen und Kapiteln der ISO 13485 und zu Qualitätsmanagementsystemen im Allgemeinen.

Überblick

• 1. Qualitätsmanagementsystem – einfach erklärt
• 2. ISO 13485 – Leitfaden für Software-Hersteller 
  • 2.1 Prozessbezogener Ansatz 
  • 2.2 Erste Schritte – Starting from scratch 
  • 2.3 Wie liest man die ISO 13485? 
  • 2.4 Inhalte der ISO 13485 
  • 2.5 Update 2021 mit Amendment: ISO 13485:2016/A11:2021
  • 2.6 QMS-Software, Atlassian und Co. – Das richtige Tooling 
• 3. Frequently asked questions (FAQ) 
  • 3.1 Wer braucht die ISO 13485? 
  • 3.2 Was bestätigt ein ISO 13485 Zertifikat? 
  • 3.3 Ist die ISO 13485 Pflicht? 
  • 3.4 Wie ist die Beziehung zwischen der ISO 13485 und der MDR? 
  • 3.5 Kann die Herstellung von Medizinprodukten ausgelagert werden? 
  • 3.6 ISO 13485 als PDF herunterladen? 
• 4. Weitere relevante Normen für Software-Hersteller 
• 5. Medizinprodukt-Zulassung ohne Qualitätsmanagement-System?
• 6. Fazit

1. Qualitätsmanagementsystem – einfach erklärt

Bevor Sie sich an die Umsetzung der ISO 13485 setzen, sehen wir uns vorab kurz an, was ein Qualitätsmanagementsystem eigentlich ist. Ein Qualitätsmanagementsystem beschreibt die Gesamtheit aller Prozesse in Ihrem Unternehmen, die dazu notwendig sind, um Produkte gemäß den Produktanforderungen umzusetzen.

Der Begriff Qualität beschreibt hier im Grunde, wie gut das Ergebnis (Produkt) mit den Produktanforderungen (z.B. Patientensicherheit, medizinischer Nutzen, Kundenzufriedenheit) übereinstimmt.

Lassen Sie uns mit einem stark vereinfachten Beispiel beginnen, welches den Sinn eines Qualitätsmanagementsystems (nach ISO 13485) greifbarer macht:

Sie möchten ein Skalpell herstellen, wobei Sie das Metall (Rohstoff) von einem Lieferanten beziehen. Sie suchen online nach Stahl und finden ein gutes Angebot auf ebay von einem anonymen Anbieter, bei dem Sie sofort zuschlagen. Mit Ihrem Schleifstein aus der Küche bringen sie den Klumpen in Form und fertig ist das Medizinprodukt.

 

Das Skalpell wäre nun scharf und einsatzbereit. Würden Sie sich damit am offenen Herzen operieren lassen? Hoffentlich nicht.

 

Unter Einhaltung der ISO 13485 wäre die Herstellung des Skalpells nicht so unkontrolliert möglich. Sie müssten nämlich in diesem abgespeckten Beispiel schonmal auf jeden Fall die folgenden Prozesse dokumentieren und natürlich auch einhalten:

 

• Ermittlung der Produktanforderungen – Zunächst müssen Sie identifizieren, welche konkreten Anforderungen an Ihr Skalpell gestellt werden. Das können z.B. Forderungen von (potenziellen) Kunden, oder auch gesetzliche Vorschriften sein. (Kapitel 7.2.1 der ISO 13485)
• Bewertung des Lieferanten, welcher das Metall liefert anhand relevanter Kriterien – ein Privatanbieter auf ebay würde dieser vermutlich nicht standhalten (Kapitel 7.4.1 der ISO 13485)
• Bewertung des eingekauften Rohstoffs – Sie müssen überprüfen, dass der Rohstoff, den Sie einkaufen, auch genau Ihren Anforderungen entspricht (Verifizierung) (Kapitel 7.4.3 der ISO 13485)
• Sicherstellung einer geeigneten Arbeitsumgebung – eine private Küche birgt zahlreiche unkontrollierbare Einflüsse, welche die Qualität des Produkts gefährden könnten (Kapitel 6.4 der ISO 13485)
• Sicherstellung geeigneter Arbeitsausrüstung – Ihr alter Schleifstein ist für Skalpelle vermutlich nicht geeignet (Kapitel 6.3 der ISO 13485)
• Sicherstellung der Kompetenz des Personals – Als Buchhalter bringen Sie ggf. nicht die notwendigen Qualifikationen mit, um Stahl zu bearbeiten (Kapitel 6.2 der ISO 13485)
• … und so weiter (Kapitel 4 bis 8 der ISO 13485)

Man sieht also, die ISO 13485 ist streng und kontrolliert so ziemlich alles, was einen Einfluss auf die Qualität des Produkts haben könnte. Unternehmen, die die ISO 13485 einhalten, sind also zwangsläufig darum bemüht, möglichst nichts dem Zufall zu überlassen, um die konstante Qualität Ihrer Produkte zu gewährleisten – eben einfach das, was auch schon der Name “Qualitätsmanagement” sagt. 

Da die ISO 13485 aber eine sehr allgemeine Norm ist und für alle Medizinprodukthersteller gleichermaßen gilt, ist sie an vielen Stellen schwammig, kryptisch und vielleicht sogar unverständlich geschrieben – besonders für Software-Hersteller.

Was soll ein zum Beispiel ein Produktionsprozess für eine App sein? Muss ich mich in unserem Büro jetzt mit Kontamination beschäftigen? Und wie soll ich nachweisen, dass meine Software in sterilem Zustand ausgeliefert wird???

Fragen über Fragen – dieser Blogartikel soll Licht ins Dunkel bringen und die Umsetzung der ISO 13485 für Software-Hersteller erleichtern.

2. ISO 13485 – Leitfaden für Software-Hersteller

Wie eingangs beschrieben, ist die ISO 13485 eine Norm für alle Hersteller von Medizinprodukten. Ganz gleich, ob es um Skalpelle, Prothesen oder eben Softwareprodukte geht.

Deshalb möchten wir in diesem Leitfaden eine bessere Orientierung geben und pro Kapitel aufzeigen, was die zentralen Punkte für Software-Hersteller sind.

2.1 Prozessbezogener Ansatz

Die ISO 13485 verfolgt einen prozessbezogenen Ansatz. Wie der Name schon sagt, bedeutet das für Sie: Sie müssen Prozesse schreiben und anwenden.

Diese Prozesse erstrecken sich über den gesamten Lebenszyklus eines Medizinprodukts – Begonnen bei der Planung, bis hin zur Außerbetriebnahme und umfassen auch Bereiche, die nur indirekt mit dem Produkt zu tun haben.

Ein Prozess benötigt jeweils Eingaben und erzeugt Ausgaben, welche wiederum die Eingaben für andere Prozesse sind oder sein können.

Ein Beispiel für einen Prozess könnte Risikomanagement sein, welcher die in der Abbildung dargestellten Eingaben (z.B. Medizinische Zweckbestimmung) benötigt und bestimmte Ausgaben (z.B. Riskomanagement-Plan) erzeugt:

Der prozessbasierte Ansatz der ISO 13485

2.2 Erste Schritte – Starting from scratch

Wenn Sie zum ersten Mal eine ISO Norm aufschlagen, werden Sie vielleicht schlagartig darüber nachdenken, doch lieber eine klassische Lifestyle-App zu entwickeln, um den strengen Medizinprodukt-Vorschriften zu entgehen.

Doch auch wenn die ISO 13485 im ersten Moment überwältigend wirkt – so schlimm ist sie dann doch nicht. Sobald Sie verstanden haben, wie die Norm zu lesen ist, werden Sie es weitaus leichter haben, diese auch umzusetzen.

Hinweis: Wir empfehlen stark, für den Aufbau eines Qualitätsmanagementsystems einen erfahrenen Berater hinzuzuziehen.

Dieser kann nicht nur bei der Interpretation der Norm helfen, sondern erstellt mit Ihnen gemeinsam einen Projektplan und unterstützt Sie auch bei der Umsetzung der Norm speziell in Ihrem Unternehmen mit all seinen Besonderheiten.

2.3 Wie liest man die ISO 13485?

Die ISO 13485 ist an sich sehr angenehm zu handhaben – wenn man weiß, wie. Sie können jedes Unterkapitel aus den Hauptkapiteln 4, 5, 6, 7 und 8 im Grunde als eigene Anforderung betrachten, welche eine explizite Umsetzung erfordert. Das Inhaltsverzeichnis stellt daher schon die optimale Basis für ein entsprechendes Mapping dar.

Nun müssen Sie in der Theorie nur einmal von oben bis unten durchgehen und sich bei jedem Punkt überlegen, wie Sie diesen umsetzen. 

Vor allem, wenn Sie keine Vorerfahrungen haben, empfehlen wir NICHT, das gesamte Qualitätsmanagementsystem von Grund auf neu zu schreiben. Viel zielführender ist es, etwas Geld in die Hand zu nehmen und sich entsprechende Templates zu kaufen. Diese finden Sie online, wobei wir an dieser Stelle keinen Anbieter empfehlen. 

Natürlich sind eingekaufte Templates meist sehr generisch, sofern sie nicht eigens für Ihr Unternehmen durch eine Consulting-Firma erstellt wurden.

Daher werden Sie an einigen Stellen Anpassungen vornehmen müssen, damit die Prozesse auch auf Ihr Unternehmen anwendbar sind. Das Anpassen von Templates ist aber meist weniger fehleranfällig und führt zu besseren Ergebnissen, als der Starting-from-scratch Ansatz.

Bei der Anpassung von Templates kann Ihnen ebenfalls ein Berater helfen, damit Sie durch mehrere Review-Schleifen zu einem guten Ergebnis für Ihr Unternehmen kommen.

Stellen Sie unbedingt sicher, dass Sie auch wirklich alle Kriterien erfüllen, bevor Sie das Qualitätsmanagementsystem in die Praxis bringen und mit der Entwicklung Ihrer Medizinprodukt-Software beginnen.

Nun aber genug der einleitenden Worte – sehen wir uns die Inhalte der ISO 13485 genauer an.

2.4 Inhalte der ISO 13485

Die ISO 13485 umfasst insgesamt 8 Kapitel, wobei sich aus den ersten 3 keine konkreten Umsetzungsmaßnahmen ableiten lassen. Hier finden Sie den Anwendungsbereich der ISO 13485, Verweise auf andere relevante Normen sowie die Begriffsbestimmungen.

Deshalb fokussieren wir uns in diesem Leitfaden auf jene Kapitel, welche praktische Implikation für Sie als Hersteller beinhalten. Wie oben beschrieben, finden Sie alle umzusetzenden Anforderungen in den Kapiteln 4, 5, 6, 7 und 8.

Inhalte & Anforderungen der ISO 13485

Wichtig: Es ist möglich, einzelne Anforderungen aus den Kapiteln 6, 7 und 8 als “nicht anwendbar” zu deklarieren, wenn diese für Ihr Unternehmen nicht einzuhalten ist. Im Software-Umfeld umfasst dies zum Beispiel die besondere Anforderungen an sterile Medizinprodukte  (7.5.5). Wenn Sie bestimmte Kapitel aber nicht anwenden, müssen Sie eine Begründung dafür anführen.

2.4.1 Kapitel 4 – Qualitätsmanagementsystem

In diesem Kapitel finden Sie “Allgemeinen Anforderungen” an Ihr Qualitätsmanagementsystem, sowie “Dokumentationsanforderungen”.

Kapitel 4 erfordert etwa die Identifikation und Umsetzung aller notwendigen Prozesse, die von Ihrem Unternehmen umzusetzen sind. Die meisten davon finden Sie in der ISO 13485 selbst, jedoch gibt es auch Prozesse aus anderen Normen und Regularien, die hier von Bedeutung sind (z.B. MDR, IEC 62304 oder ISO 14971).

Dazu ist es notwendig, die Rolle(n) Ihres Unternehmens im Markt zu verstehen, um das Anwendungsgebiet des Qualitätsmanagementsystems definieren zu können. 

Zudem finden Sie in diesem Kapitel generelle Anforderungen an Ihre Prozesse und das Qualitätsmanagementsystem. Im Fokus hierbei steht die Aufgabe, die Wirksamkeit des Qualitätsmanagementsystems sicherzustellen. Dies geschieht etwa durch die Bereitstellung erforderlicher Ressourcen oder die Vergabe bestimmter Verantwortlichkeiten und Rollen.

Eine zentrale Eigenschaft des Qualitätsmanagementsystems ist die Pflicht, so ziemlich alles zu dokumentieren. Auch für die Lenkung (z.B. Erstellung, Freigabe, Sicherstellung der Verfügbarkeit, etc.) von Dokumenten und Aufzeichnungen finden Sie in Kapitel 4 entsprechende Anforderungen.

Eine weitere Forderung von Kapitel 4 ist die Erstellung eines Qualitätsmanagement-Handbuchs und einer Medizinproduktakte. Ersteres stellt sozusagen einen Überblick über das Qualitätsmanagementsystems dar. Dort wird der Anwendungsbereich klar definiert und die Prozesslandschaft dargestellt.

Das Qualitätsmanagement-Handbuch hat keinen klaren Produktbezug, sondern bezieht sich auf das Qualitätsmanagementsystem selbst.

Die Medizinproduktakte hingegen enthält (oder verweist auf) jene Dokumentation, welche die Konformität einzelner Medizinprodukttypen oder auch -gruppen darlegt. Inhalte sind beispielsweise die Zweckbestimmung sowie eine Liste von Produktanforderungen.

Sie sehen also, Kapitel 4 stellt in erster Linie grundlegende Regeln dar, auch welchen das gesamte Qualitätsmanagement aufbaut.

2.4.2 Kapitel 5 – Verantwortung der Leitung

In diesem Kapitel geht es vor allem um eines: Commitment.

Beispielsweise wird die Leitung dazu verpflichtet, die notwendigen Rahmenbedingungen für ein effektives Qualitätsmanagementsystem zu schaffen und die anwendbaren regulatorischen- und Kundenanforderungen zu identifizieren.

Dies soll etwa durch die Definition von Qualitätszielen, einer Qualitätspolitik und der Ernennung eines “Beauftragten der Leitung” erfolgen. Außerdem muss die Leitung für angemessene Kommunikationskanäle im Unternehmen sorgen (z.B. Slack, E-Mail, etc.).

Hinweis: “Leitung” bezieht sich meist auf das obere Management .

Zentral ist zudem die Pflicht zur Durchführung von Management Reviews (Managementbewertungen). Diese finden in einem definierten Intervall statt (z.B. jährlich) und haben das Ziel, die fortdauernde Eignung, Angemessenheit und Wirksamkeit des Qualitätsmanagementsystems sicherzustellen.

Diese Bewertung lässt sich nicht nach Gefühl vornehmen, deshalb muss diese Managementbewertung auch auf der Basis von Daten aus verschiedenen Quellen durchgeführt werden (z.B. Kundenfeedback). Aus der Managementbewertung sollen demnach Maßnahmen herauskommen, welche das Qualitätsmanagement und die Produkte selbst verbessern. Zudem soll der Bedarf an weiteren Ressourcen im Unternehmen ermittelt werden.

2.4.3 Kapitel 6 – Management von Ressourcen

MitarbeiterInnen, Fähigkeiten, Laptops, Git, … das alles sind nur einige Beispiele von Ressourcen, die Sie möglicherweise benötigen, um ein Software-Medizinprodukt zu entwickeln. Da es in Software-Unternehmen selten Lieferketten oder Fabrikhallen gibt, stehen vor allem die personellen und digitalen Ressourcen im Fokus, weshalb Kapitel 6 unter anderem ein starkes HR-Thema ist.

Hier wird besonders die Qualifikation von MitarbeiterInnen betont, welche durch Ihr Unternehmen sichergestellt werden muss. Das hat einerseits Auswirkungen auf die Selektion neuer MitarbeiterInnen, als auch auf das Training und die Weiterbildung bestehenden Personals.

Und auch wenn moderne Software-Unternehmen ohne festen Arbeitsplatz auskommen und deren MitarbeiterInnen lediglich einen Laptop als einzig notwendiges Arbeitsgerät bekommen, ist das Thema “Infrastruktur” nicht zu vernachlässigen.

Diese ist dann eben digital, aber dennoch zentral für die Entwicklung sicherer und funktionsfähiger Medizinprodukt-Software. Sie müssen Anforderungen an diese Infrastruktur ermitteln und dokumentieren.

Mit der Arbeitsumgebung und Kontamination hingegen müssen sich Software-Hersteller in der Regel nicht beschäftigen. Wichtig ist es aber, ein entsprechendes (kurzes) Statement für den “Ausschluss” dieser Anforderung zu dokumentieren. Dies wird einerseits von der Norm selbst, als auch von einigen Auditoren gefordert.

2.4.4 Kapitel 7 – Produktrealisierung

In Kapitel 7 wird es spannend, denn das ist der Teil, mit dem Sie sich am intensivsten beschäftigen werden, wenn Sie ein Qualitätsmanagementsystem nach ISO 13485 etablieren möchten.

Hier geht es nämlich um das eigentliche Produkt, das entwickelt werden soll – von der Planung bis zur Fertigstellung. Zunächst geht es darum, die Kundenanforderungen zu identifizieren und sicherzustellen, dass diese auch umgesetzt werden können.

Dazu zählen auch Anforderungen, die nicht explizit von Ihren Kunden gestellt werden (z.B. regulatorische Anforderungen).

In Kapitel 7 wird beschrieben, wie Sie die Produktrealisierung planen, die Produktanforderungen identifizieren und die Ergebnisse am Ende auch bewerten, verifizieren und validieren.

An dieser Stelle sei auf die IEC 62304 verwiesen, welche von Herstellern von Software-Medizinprodukten auf jeden Fall eingehalten werden sollte. Diese Norm beschreibt das Vorgehen bei der Software-Entwicklung präzise und stellt ergänzend zur ISO 13485 noch einmal zusätzliche Anforderungen an die Software-Entwicklung. 

Die Produktentwicklung läuft nach ISO 13485 grob wie folgt ab:

1. Entwicklungsplanung
2. Entwicklungseingaben
3. Entwicklungsergebnisse
4. Entwicklungsbewertung
5. Entwicklungsverifizierung
6. Entwicklungsvalidierung
7. Übertragung der Entwicklung an die Herstellung
8. Lenkung von Entwicklungsänderungen

Die Reihenfolge der Kapitel suggeriert, dass diese Tätigkeiten streng aufeinander folgen. Das ist in der Realität aber nicht zwangsläufig der Fall. Einige Tätigkeiten können durchaus parallel ablaufen (z.B. Entwicklungsplanung und Ermittlung der Produktanforderungen (Entwicklungseingaben)).

Außerdem gibt es keine Forderung, dass all diese Tätigkeiten nur ein einziges mal durchlaufen werden. Im Hardware-Bereich macht das möglicherweise Sinn, aber in der agilen Software-Entwicklung ist es durchaus möglich, einige dieser Tätigkeiten in einem Zyklus laufen.

Bei der Realisierung von Software-Produkten ist zudem die IEC 62304 einzuhalten – Lesen Sie mehr dazu in diesem Artikel (IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten).

Hinweis: Was viele Hersteller verwirrt, ist die Unterscheidung zwischen “Entwicklungsverifizierung” und “Entwicklungsvalidierung”

Die Produktrealisierung umfasst nach der eigentlichen Entwicklung auch die Verifizierung und Validierung des Produkts. Da diese Unterscheidung oft unklar ist, hier eine kleine Faustregel, um den Unterschied besser zu verstehen. Der Unterschied lässt sich am besten anhand zweier Fragen festmachen:

• Verifizierung: Wurde das Produkt richtig umgesetzt?
• Validierung: Wurde das richtige Produkt umgesetzt?

Bei der Verifizierung gleicht man das Ergebnis mit den klaren Produktanforderungen ab – zum Beispiel “Die App zeigt dem Nutzer Therapieempfehlungen” (z.B. durch Software-System-Tests)

Bei der Validierung wird überprüft, ob das Ergebnis seinen Zweck auch erfüllen kann – zum Beispiel “Die Therapieempfehlungen lindern die Erkrankung” (z.B. durch eine klinische Studie).

Mehr zur Validierung erfahren Sie in diesem Artikel: Validierung von Medizinprodukt-Software nach MDR

Zudem finden Sie in Kapitel 7 Anforderungen an die Identifizierbarkeit und Rückverfolgbarkeit von Produkten, was Sie am besten über ein Versionierungssystem gewährleisten. Falls Überwachungs- und Messmittel verwendet werden (z.B. spezielle Testing Tools), sind auch diese gemäß ISO 13485 zu behandeln.

Beschaffung

Neben der eigentlichen Entwicklung des Produkts geht es in Kapitel 7 auch um die Regulierung eingekaufter Produkte und Dienstleistungen. Dabei geht es um die Bewertung von Lieferanten und die Verifizierung der eingekauften Leistungen.

Wenn Ihr Entwicklerteam beispielsweise mit Jira arbeitet, müssen Sie einerseits Atlassian (dessen Hersteller) als Lieferanten bewerten und anschließend untersuchen,  ob Jira die von Ihnen gestellten Anforderungen an ein Ticket-Managementsystem erfüllt. Erst nach erfolgreicher Bewertung und Validierung dürfen Sie Jira in Ihrem Unternehmen einsetzen. Mehr zur Validierung von eingesetzter Software erfahren Sie in unserem Artikel: Validierung von Software nach MDR

2.4.5 Kapitel 8 – Messung, Analyse und Verbesserung

Sobald Ihr neues Qualitätsmanagementsystem im Einsatz ist, werden Sie bald sehen, dass die Prozesse an einigen Stellen noch nicht reibungslos funktionieren und vielleicht sogar zu regulatorischen Abweichungen führen. 

Der Umgang mit Optimierungen und Korrekturen wird in Kapitel 8 behandelt – denn natürlich brauchen Sie auch hierfür eigene Prozesse. Doch nicht nur Daten über das Qualitätsmanagementsystem selbst, sondern natürlich insbesondere zu Ihren Medizinprodukten müssen entsprechend gesammelt und verarbeitet werden.

In diesem Kapitel finden Sie daher Kriterien für die Datenanalyse, Überwachung, Umgang mit nicht-konformen Produkten, sowie stetige Verbesserungen Ihres Qualitätsmanagementsystems. 

Neben den regelmäßigen Überwachungsaudits sind Sie außerdem dazu verpflichtet, interne Audits durchzuführen, um die fortlaufende Konformität Ihres Qualitätsmanagementsystems sicherzustellen.

2.5 Update 2021 mit Amendment: ISO 13485:2016/A11:2021

2021 wurde die ISO 13485 durch die Änderung A11:2021 aktualisiert. Durch ISO 13485/A11:2021 wurde der Hauptteil der ISO 13485 nicht geändert. Neu hinzugekommen ist vor allem ein offizielles Mapping zur MDR. Dieses findet sich im Annex ZA.

Dieses Mapping ist bei der Analyse und Identifikation offener Anforderungen sehr hilfreich und sollte von Herstellern daher berücksichtigt werden.

Das heißt zusammengefasst, dass die Änderung A11:2021 keine neuen oder geänderten Anforderungen an das Qualitätsmanagementsystem stellt, sondern vor allem bei der Erlangung der MDR-Konformität unterstützt.

Da die neue Version harmoniert ist, sollten sie ab sofort die EN ISO 13485:2016/A11:2021 oder die DIN EN ISO 13485:2021 als Basis für Ihre MDR-Produkte verwenden.

2.6 QMS-Software, Atlassian und Co. – Das richtige Tooling

Sie sehen schon, ein Qualitätsmanagementsystem besteht aus zahlreichen Dokumenten und Aufzeichnungen, die in wechselseitiger Beziehung zueinander stehen. Ein sehr vernetztes System also, welches durch entsprechendes Tooling übersichtlicher gestaltet werden kann.

Qualitätsmanagementsystem klingt für viele Menschen immer noch nach sehr viel Papier. Natürlich kann man mit ausgedruckten Dokumenten arbeiten, und diese zum Beispiel mittels einer Unterschrift freigeben.

In der Regel ist dies aber nicht das Mittel der Wahl – gerade Software-Unternehmen, deren Mitarbeitende nicht immer an einem zentralen Ort arbeiten, stoßen mit diesem Ansatz auf Probleme. 

Natürlich gibt es mittlerweile auch zahlreiche digitale Möglichkeiten, ein Qualitätsmanagementsystem umzusetzen. Ein paar Möglichkeiten zur Umsetzung sind in der untenstehenden Tabelle aufgeführt.

3. Frequently asked questions (FAQ)

3.1 Wer braucht die ISO 13485?

Die ISO 13485 wird von Medizinproduktherstellern verwendet und beinhaltet Anforderungen an ein Qualitätsmanagementsystem. Ein solches wird beispielsweise von der MDR gefordert, um Medizinprodukte entwickeln zu können.

3.2 Was bestätigt ein ISO 13485 Zertifikat?

Ein ISO 13485 Zertifikat bestätigt, dass ein Unternehmen über ein Qualitätsmanagementsystem für Medizinprodukte verfügt. Ein solches ist in der gesetzlich vorgeschrieben, wenn Sie Medizinprodukte in der EU (und in vielen anderen Ländern) herstellen und vertreiben möchten. Es ist aber kein Nachweis dafür, dass Sie alle Anforderungen der MDR einhalten.

3.3 Ist die ISO 13485 Pflicht?

Nein, die ISO 13485 ist lediglich ein anerkannter Standard für Qualitätsmanagementsysteme für Medizinprodukte. Wer jedoch Medizinprodukte unter der MDR entwickeln möchte, ist mit einer entsprechenden Zertifizierung gut beraten. Vor allem eine benannte Stelle wird Ihr Qualitätsmanagementsystem unter die Lupe nehmen und ohne Zertifizierung könnte die Argumentation für Sie schwierig werden. Auch bei Herstellerüberwachungen von Aufsichtsbehörden ist ein ISO 13485 Zertifikat hilfreich.

3.4 Was muss ich bei Produkten mit künstlicher Intelligenz (KI) beachten?

Falls Sie künstliche Intelligenz (KI) in Ihr Produkt integrieren möchten, sollten einige weitere Aspekte bei der Umsetzung der ISO 13485 beachten. In unserem umfangreichen Leitfaden zu diesem Thema erklären wir im Detail, was für Sie bei der Zertifizierung von KI-Produkten besonders relevant ist: Zum KI-Leitfaden

3.5 Wie ist die Beziehung zwischen der ISO 13485 und der MDR?

Nach MDR müssen alle Medizinprodukt-Hersteller über ein Qualitätsmanagementsystem verfügen. Wie genau dieses auszusehen hat, spezifiziert die MDR allerdings nicht. Daher wurde die ISO 13485 zum Industriestandard in Europa, wenn es um Anforderungen an Qualitätsmanagementsysteme in der Medizinprodukt-Branche geht. Die ISO 13485 ist natürlich kein 1:1 Umsetzungsleitfaden für die MDR, denn es gibt auch Forderungen, die aus der MDR direkt hervorgehen und von der ISO 13485 nicht direkt abgedeckt werden (Beispielsweise die Ernennung einer “Person responsible for regulatory compliance – PRRC”, oder ein Prozess für die Meldung von Vorkommnissen an zuständige Behörden).

Wichtig: Die MDR spricht an keiner Stelle von der Umsetzung der ISO 13485, sondern immer von “Qualitätsmanagementsystem”. Formell gibt es also keine Pflicht, die ISO 13485 einzuhalten. Eine entsprechende Zertifizierung ist aber ein starker Nachweis für die Konformität Ihres Qualitätsmanagementsystems, weshalb wir eine solche sehr empfehlen. Die meisten MDR-Auditoren erwarten dies auch.

3.6 Kann die Herstellung von Medizinprodukten ausgelagert werden?

Ja, wenn Sie sich z. B. auf den Vertrieb und das Marketing fokussieren möchten, können Sie die Herstellung des Medizinprodukts auch an einen Dienstleister – wie QuickBird Medical – auslagern. Dadurch übernimmt der Dienstleister die Rolle des Inverkehrbringers und bringt das Medizinprodukt rechtlich auf den Markt. Somit geht die regulatorische Verantwortung auf den Dienstleister über.

Risikofreie Medizinprodukt-Zertifizierung ohne internen Aufwand für Ihr Team

Als zertifizierter Inverkehrbringer übernehmen wir für Sie die Hersteller-Verantwortung für Ihre Medizinprodukt-Software, Medical App oder DiGA. So müssen Sie kein Qualitätsmanagementsystem (QMS) bei sich aufbauen und werden als Unternehmen nicht durch die Regulatorik ausgebremst.

MEHR ERFAHREN

3.7 ISO 13485 als PDF herunterladen?

Die ISO 13485 ist kostengünstig über https://www.evs.ee/en zu erwerben und kann als PDF heruntergeladen werden (auf Englisch). Natürlich erhalten Sie die Norm auch auf zahlreichen anderen Plattformen, jedoch üblicherweise zu höheren Preisen. Die deutsche Version der ISO 13485 finden Sie unter anderem bei Beuth: https://www.beuth.de/de/norm/din-en-iso-13485/332674603

4. Weitere relevante Normen für Software-Hersteller

Als Ergänzung zur ISO 13485 müssen Sie sich als Hersteller von Software-Medizinprodukten auch mit weiteren Normen beschäftigen und diese umsetzen. Allen voran ist hier die IEC 62304 zu nennen, welche Anforderungen an die Software-Lebenszyklus-Prozesse stellt. Genaueres erfahren Sie in diesem Artikel: IEC 62304: Software-Lebenszyklus-Prozesse von Medizinprodukten

. Besonders für Hersteller von Standalone-Software lohnt sich außerdem ein Blick in die IEC 82304. Hier finden sich zwar zahlreiche Verweise auf die vorhin genannte IEC 62304, jedoch enthält sie zusätzliche Anforderungen an die Validierung von Gesundheitssoftware.

Zudem wird Ihnen auffallen, dass an einigen Stellen auf das Risikomanagement als begleitender Prozess verwiesen wird. Einen entsprechenden Prozess setzen Sie am besten nach ISO 14971 um, welcher durch die IEC 62366 (Anwendung der Gebrauchstauglichkeit auf Medizinprodukte) ergänzt wird. Weitere Informationen finden Sie in diesem Artikel: Leitfaden für die Entwicklung von Medical Apps: Darauf müssen Hersteller achten

Natürlich gibt es noch andere Normen, die für Sie relevant sein könnten. Unsere Auflistung beinhaltet lediglich jene, welche aus unserer Sicht den größten Implementierungsaufwand benötigen.

5. Medizinprodukt-Zulassung ohne Qualitätsmanagement-System?

Gibt es einen Weg, die regulatorischen Pflichten für Medizinprodukt-Hersteller komplett zu vermeiden?

Ja, den gibt es: die Auslagerung der sogenannten Legalhersteller-Rolle an ein externes Unternehmen. Dies ist eine effiziente und risikominimierende Lösung, um Ihre Ressourcen zu schonen und gleichzeitig regulatorische Sicherheit zu schaffen. Sie müssen kein Qualitätsmanagement-System aufbauen und können den regulatorischen Zulassungsprozess vollständig an uns abgeben.

So können Sie sich auf die Produktkonzeption und Vermarktung konzentrieren, während QuickBird Medical als Legalhersteller alle regulatorischen Anforderungen übernimmt und für die Einhaltung haftet.

Mehr Informationen dazu finden Sie hier: Zum Fachartikel

6. Fazit

Die ISO 13485 ist die wohl verbreitetste Norm für den Aufbau von Qualitätsmanagementsystemen für Medizinprodukt-Hersteller in Europa. Wenn Sie diese einhalten, decken Sie die meisten Anforderungen der MDR in Bezug auf Qualitätsmanagementsysteme ab.

Die Unterkapitel in den Kapiteln 4 bis 8 beschreiben jeweils einzelne Anforderungen, die von Ihnen als Hersteller umzusetzen sind und stellen somit bereits die ideale Basis für einen entsprechenden Fahrplan dar.

Auch wenn die ISO 13485 für die durchaus verständlich geschrieben ist, ist ihre Umsetzung nicht ganz selbsterklärend. Die Besonderheiten einzelner Unternehmen müssen stets berücksichtigt werden, weshalb es kein pauschales Qualitätsmanagementsystem gibt, welches alle Software-Unternehmen gleichermaßen anwenden können.

Dennoch ist es ratsam, sich entsprechende Vorlagen zu kaufen und diese anschließend anzupassen.

Zudem empfehlen wir, den Aufbau Ihres Qualitätsmanagementsystems gemeinsam mit einem erfahrenen Berater vorzunehmen. Entsprechende Software-Tools können Ihnen außerdem einen maßgeblichen Effizienz-Vorteil verschaffen.

Dennoch, der Aufbau eines Qualitätsmanagementsystems ist sehr zeitaufwändig und produziert Kosten. Daher kann es für Sie sinnvoll sein, die Rolle des Inverkehrbringers für Ihr Produkt (zunächst) an einen Dienstleister zu übergeben. Dieser übernimmt dann die regulatorische Verantwortung für Ihr Produkt und steht rechtlich für seine Konformität ein. In diesem Fall entgehen Sie der Pflicht, ein eigenes Qualitätsmanagementsystem aufzubauen.

Wenn Sie die Umsetzung eines Software-Medizinprodukts und/oder den Aufbau eines Qualitätsmanagementsystems planen, sprechen Sie uns gerne an. Wir unterstützen Sie bei Ihrem Vorhaben. Kontaktieren Sie uns jetzt.

The post ISO 13485 – Leitfaden zu Anforderungen und Inhalten appeared first on QuickBird Medical.

1. Datensicherheits-Zertifikat nach BSI TR-03161
2. Datenschutz-Zertifikat nach DSGVO

Hinzu kommt das Vorhalten eines nach ISO/IEC 27001 zertifizierten Informationssicherheitsmanagementsystems, welches jedoch nicht im Fokus dieses Artikels steht.

Wir erklären, was es mit dem Datenschutz- und Datensicherheits-Zertifikat auf sich hat, ab wann die Zertifizierungen verpflichtend sind und wie Sie diese als Hersteller erhalten können.

Inhaltsverzeichnis

• 1. Ab wann gilt die Pflicht zur Zertifizierung
• 2. Wie bekomme ich das DiGA-Zertifikat für Datensicherheit?
• 3. Wie bekomme ich das DiGA-Zertifikat für Datenschutz
• 4. Fazit
• 5. Vorbereitung auf die Zertifizierung

1. Ab wann gilt die Pflicht zur Zertifizierung?

Die aktuellen Fristen für die Zertifizierung von DiGA nach Datenschutz und Datensicherheit lauten wie folgt:

Datensicherheitszertifikat nach BSI TR-03161: 01.01.2025

Seit dem 1. Januar 2025 sind Hersteller digitaler Gesundheitsanwendungen (DiGA) verpflichtet, die Einhaltung der Anforderungen an die Datensicherheit durch ein offizielles Zertifikat zu belegen.

• Neue DiGA-Anträge: Für neue DiGA-Anträge gab es zwischenzeitlich eine Übergangsregelung, die nun aber nicht mehr relevant ist. Um in das DiGA-Verzeichnis aufgenommen zu werden, benötigen Sie aktuell zwingend eine Datensicherheitszertifizierung nach BSI TR-03161.
• Gelistete DiGA: Für bereits gelistete DiGA duldet das BfArM aktuell noch fehlende Zertifikate. Voraussetzung ist, dass der Hersteller nachweisen kann, dass er sich im laufenden Zertifizierungsprozess befindet. Diese Praxis kann sich jederzeit ändern. Hersteller gelisteter DiGA sollten sicherstellen, dass sie das Zertifikat des BSI sehr zeitnah erhalten.

Datenschutzzertifikat nach DSGVO: weiterhin unklar

Aktuell besteht für DiGA noch keine Pflicht zur Vorlage eines formalen Datenschutzzertifikats. Der Grund dafür ist, dass es zum jetzigen Zeitpunkt noch keine akkreditierten Zertifizierungsstellen für eine Zertifizierung nach den Datenschutzkriterien gemäß § 139e Absatz 11 SGB V und § 78a Absatz 8 SGB XI gibt.

Das BfArM arbeitet derzeit gemeinsam mit dem BfDI und dem BSI an der Umsetzung der gesetzlichen Vorgaben. Die zugrunde liegenden Datenschutzkriterien wurden bereits aktualisiert und veröffentlicht. Sie bilden künftig die Basis für ein offizielles Datenschutzzertifikat, das sowohl die Anforderungen der DSGVO als auch zusätzliche DiGA- und DiPA-spezifische Vorgaben abdeckt. Das Zertifikat befindet sich aber weiterhin in der Entwicklung. Änderungen an Prüfkriterien und Prüfmethoden sind daher möglich.

Solange eine Zertifizierung technisch und organisatorisch noch nicht möglich ist, gelten weiterhin die Datenschutzanforderungen der DiGAV.

Sobald Zertifizierungsstellen akkreditiert sind, wird das BfArM die Vorlage eines Datenschutzzertifikats mit ausreichendem zeitlichem Vorlauf einfordern. Konkrete Zeiträume werden auf der Webseite des BfArM veröffentlicht. Hersteller bereits gelisteter DiGA werden dann individuell zur Vorlage des Zertifikats aufgefordert.

2. Wie bekomme ich das DiGA-Zertifikat für Datensicherheit?

Das Datensicherheitszertifikat für DiGA basiert auf der BSI TR-03161 und wird über ein mehrstufiges Verfahren vergeben. Voraussetzung ist eine vollständige technische und organisatorische Umsetzung der Anforderungen.

Der Weg zum Zertifikat in Kurzform:

• Vorbereitung: Umsetzung der technischen und organisatorischen Anforderungen der BSI TR-03161 im Produkt und in den Prozessen des Herstellers.
• Prüfung durch eine akkreditierte Prüfstelle: Eine vom BSI zugelassene Prüfstelle prüft Produkt, Architektur, Quellcode, Dokumentation und Sicherheitsprozesse und erstellt einen Prüfbericht.
• Zertifizierungsentscheidung durch das BSI: Auf Basis des Prüfberichts entscheidet das BSI über die Erteilung des Zertifikats und stellt dieses bei positiver Bewertung aus.

Wir haben einen detaillierten Leitfaden geschrieben, der Ihnen einen Überblick über den gesamten Prozess der Datensicherheitszertifizierung nach BSI TR-03161 gibt. Wir befassen uns in diesem Rahmen damit:

• Was fordert die TR-03161 konkret?
• Wie läuft die Zertifizierung mit Prüfstelle und BSI ab?
• Mit welchen Kostenblöcken ist das Ganze verbunden und wie lange dauert eine solche Zertifizierung?
• Was sind die praktischen Implikationen der BSI TR-03161 auf DiGA?
• Wie sieht die Zukunft der BSI-Zertifizierung aus? (Stichwort: BSI TR-03185)

Hier finden Sie unseren Leitfaden zur BSI TR-03161-Zertifizierung: Zum Fachartikel

3. Wie bekomme ich das DiGA-Zertifikat für Datenschutz?

Das Datenschutz-Zertifikat ist eine Zertifizierung nach Artikel 42 DSGVO. Die zugrundeliegende Prüfung soll anhand von Prüfkriterien erfolgen, die vor einigen Monaten vom BfArM veröffentlicht wurden: DiGA und DiPA Datenschutzkriterien

Entsprechende Zertifikate können laut DSGVO von den Aufsichtsbehörden selbst, oder aber von akkreditierten Stellen ausgestellt werden. In der Praxis zeigt sich hier aber noch ein anderes Bild.

Das Bayerische Bundesamt für Datenschutzaufsicht (BayLDA) zum Beispiel führt „mangels personeller Ressourcen“ keine Zertifizierungen selbst durch. Stattdessen wird auf die bei der DAkkS (Deutsche Akkreditierungsstelle) akkreditierten Organisationen verwiesen, welche es aktuell aber auch noch nicht zu geben scheint (Quelle: BayLDA – Zertifizierung). (Stand vom 15.03.2024)

Viele Fragen, die DiGA-Hersteller beschäftigen, können heute leider noch nicht geklärt werden. Dazu zählen unter anderem:

• Wer kann entsprechende Prüfungen durchführen, die für die Zertifizierung benötigt werden?
• Wie lange dauern die Zertifizierungsverfahren?
• Wie viel kosten die Zertifizierungen?
• etc.

Die zentralen Informationen fehlen also noch, mit denen DiGA-Hersteller die gesetzlichen Vorgaben erfüllen können. Aktuell ist somit noch keine Datenschutzzertifizierung möglich.

Sobald sich dies ändert oder Neuigkeiten bekannt werden, benachrichtigen wir alle Abonnenten unseres DiGA-Newsletters. Wenn Sie hierzu auf dem neuesten Stand bleiben möchten, abonnieren Sie unseren Newsletter für DiGA-Hersteller hier.

4. Fazit

Wir beobachten die Situation mit der Datenschutzzertifizierung für alle unsere DiGA-Kunden aktiv und sind gespannt, wann es hierzu Neuigkeiten geben wird. Fakt ist: Die Datenschutzzertifizierung wird kommen. Es ist nur eine Frage der Zeit, wann dies so weit ist.

In Bezug auf die Datensicherheitszertifizierung existiert bereits ein Prüfprozess und über 10 DiGA sind bereits nach BSI TR-03161 zertifiziert (Stand Januar 2026). Der Prüfprozess hat an vielen Stellen Verbesserungspotenzial und daher ist auch hier zeitnah mit Updates zu rechnen. Mehr dazu finden Sie in unserem Fachartikel zur BSI-Zertifizierung von DiGA.

The post Datensicherheits- & Datenschutz-Zertifikate für DiGA appeared first on QuickBird Medical.

Update des DiGA-Leitfadens am 10.12.2025: Der offizielle DiGA-Leitfaden wurde in der Version 3.6 aktualisiert und enthält zahlreiche Ergänzungen in Bezug auf die Entscheidung „Ist Ihre Anwendung eine DiGA?“ (Qualifizierung). Die Neuerungen wurden in den untenliegenden Fachartikel bereits eingearbeitet. Einen Überblick über die Leitfaden-Änderungen finden Sie hier: Übersicht aller Änderungen

Inhaltsverzeichnis

• 1. DiGA-Kriterien im Überblick
  • 1.1 Kriterium #1: Medizinprodukt niedriger oder höherer Risikoklasse
  • 1.2 Kriterium #2: Positiver Versorgungseffekt, konsistent mit Zweckbestimmung des Medizinprodukts
  • 1.3 Kriterium #3: Digitale Hauptfunktion
  • 1.4 Kriterium #4: Mehr als eine Steuerung von Geräten
  • 1.5 Kriterium #5: Diagnose oder Therapie von Krankheiten oder Verletzungen
  • 1.6 Kriterium #6: Keine reine (Primär-)Prävention
  • 1.7 Kriterium #7: Nutzer ist der Patient
  • 1.8 Kriterium #8: Individualisierung
  • 1.9 Kriterium #9: Ausgeschlossene Leistungen
  • 1.10 Kriterium #10: Veröffentlichung vor Antrag
• 2. Der DiGA-Fähigkeit-Entscheidungsbaum
• 3. Die Anforderungen bei Erfüllung der Kriterien
• 4. Selektivverträge – Eine Alternative zu DiGA
• 5. Fazit

1. DiGA-Kriterien im Überblick

Der offizielle DiGA-Leitfaden des BfArM fasst die Definition von DiGA prägnant zusammen. Damit Ihr Produkt als DiGA für eine Kostenerstattung potenziell in Frage kommt, muss es die folgenden Kriterien erfüllen.

1.1 Kriterium #1: Medizinprodukt niedriger oder höherer Risikoklasse

Ihr Produkt muss ein Medizinprodukt niedriger oder höherer Risikoklasse sein (I, IIa oder IIb).

Natürlich ist nicht jede Software ein Medizinprodukt. Eine App, die beispielsweise die reine Dokumentation von medizinischen Daten zum Zweck hat, ist kein Medizinprodukt und damit auch keine DiGA. Falls Ihre App Blutdruck-Werte sammelt, diese jedoch nicht für die Diagnose oder Therapie von Krankheiten auswertet, ist dies kein Medizinprodukt. Mehr Informationen finden Sie in unserem Artikel zum Thema „Ist Ihre App ein Medizinprodukt?“.

Ihre App ist ein Medizinprodukt? Super! Allerdings ist dann aber noch offen, ob sie auch ein Medizinprodukt einer niedrigen oder höheren Risikoklasse (I, IIa oder IIb) ist.

Zur Bestimmung der Risikoklasse ist insbesondere die Regel 11 der MDR relevant. Auch hierzu haben wir einen detaillierten Leitfaden geschrieben: Praxis-Leitfaden zur Bestimmung der Risikoklasse bei Software-Produkten

1.2 Kriterium #2: Positiver Versorgungseffekt, konsistent mit Zweckbestimmung des Medizinprodukts

Die digitale Hauptfunktion der DiGA muss konsistent mit der Zweckbestimmung des zugrundeliegenden Medizinproduktes sein. Funktionen, die Teil der Erfüllung der medizinischen Zweckbestimmung sind, müssen auch den Funktionsumfang der DiGA ausmachen.

Hierbei sind u.a. folgende Aspekte relevant:

1. Exkludieren von DiGA-Funktionen: Manchmal hat eine DiGA bestimmte Funktionen, die man als Hersteller lieber nicht den strikten Anforderungen der DiGA-Verordnung unterwerfen will. Manche Funktionen erschweren oder verhindern z.B. die BSI-Sicherheitszertifzierung der DiGA oder den Nachweis des positiven Versorgungseffekts. Dennoch gilt: Wenn diese Funktionen zur Erfüllung der Zweckbestimmung des Medizinprodukts dienen, dürfen Sie diese nicht vom Funktionsumfang der DiGA exkludieren. Sie dürfen also nicht beliebige Funktionen aus dem Scope Ihrer DiGA ausschließen, auch wenn dies die initiale DiGA-Zulassung für Sie erschwert oder verhindert.
2. Inkonsistenz mit Zweckbestimmung: Eine andere Form der Inkonsistenz zwischen Medizinprodukt-Zweckbestimmung und Hauptfunktion der DiGA wäre Folgendes: Ihre DiGA zielt auf eine andere medizinische Indikation ab als das zugrunde liegende Medizinprodukt. Ihr Medizinprodukt dient der Therapie von Kniegelenksarthrose, aber Ihre DiGA hat die Handgelenksarthrose als Hauptfunktion. Das wäre eine Inkonsistenz in diesem Sinne und würde sich so nicht als DiGA qualifizieren.

1.3 Kriterium #3: Digitale Hauptfunktion

Ihr Produkt muss definitionsgemäß hauptsächlich auf digitalen Technologien beruhen. Das schließt aus, dass z.B. ein Blutdruckmessgerät selbst eine DiGA ist. Hardware ist keine DiGA.

Aber auch wenn Ihr Produkt z.B. ein App oder Web-Anwendung ist und somit scheinbar vollständig digital, sollten Sie beachten:

1. Hardware-Integration: Wenn Sie eine Hardware z.B. per Bluetooth mit Ihrer App verbinden: Der positive Versorgungseffekt Ihrer DiGA darf dann nicht durch den Einsatz der Hardware entstehen. Der positive Versorgungseffekt muss auf der digitalen Hauptfunktion (z.B. digitales Übungsprogramm) basieren und somit unabhängig von der Hardware sein.
2. Einbindung von Behandlern: Der positive Versorgungseffekt darf nicht durch die Einbindung z.B. eines Arztes entstehen. Wenn Ihre DiGA nur „wirkt“, wenn ein Arzt über Video-Calls persönliche Therapieempfehlungen gibt, dann ist das keine digitale Hauptfunktion Ihrer DiGA. Die DiGA darf für den positiven Versorgungseffekt nicht von dieser menschlichen Komponente abhängen. Diese muss optionalen Charakter haben, und im Optimalfall bei der Durchführung der DiGA-Studie in der Interventionsgruppe deaktiviert werden.

1.4 Kriterium #4: Mehr als eine Steuerung von Geräten

Ihre App muss den medizinischen Zweck wesentlich durch die digitale Hauptfunktion erfüllen. Falls Ihre App nur der Steuerung eines medizinischen Geräts dient – und damit den wesentlichen medizinischen Zweck nicht selbst erbringt – ist sie keine DiGA. Eine DiGA kann zwar mit medizinischen Geräten kommunizieren und z.B. Sensordaten auslesen, dies darf jedoch nicht der Hauptzweck sein.

Falls Ihre App externe Sensordaten eines medizinischen Geräts ausliest und auf dieser Basis eine Diagnose stellt oder Therapieempfehlungen gibt, ist dieses Kriterium erfüllt. Der wesentliche Zweck ist in diesem Fall Diagnose oder Therapieverbesserung, und der Zweck wird durch einen digitalen Algorithmus in Ihrer App/Software erfüllt.

1.5 Kriterium #5: Diagnose oder Therapie von Krankheiten oder Verletzungen

Eine DiGA wird definiert als eine Anwendung, welche die „Erkennung, Überwachung, Behandlung oder Linderung von Krankheiten oder die Erkennung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen“ unterstützt. Damit sind z.B. Verhütungs-Apps, Zyklus-Tracking-Apps, oder reine (Primär-)Präventions-Apps (Kriterium #5) keine DiGA. Eine Applikation, die beispielsweise Patienten mit diagnostizierter Sehschwäche durch digitale Sehübungen bei der Therapie unterstützt, erfüllt dieses Kriterium und könnte demnach auch eine DiGA sein.

1.6 Kriterium #6: Keine reine (Primär-)Prävention

Der DiGA-Leitfaden formuliert es folgendermaßen: Voraussetzung ist, dass ein Risikofaktor im Sinne einer Erkrankung vorliegt, die als Diagnose verschlüsselbar ist.

Eine App, die einen gesunden Menschen bei der Prävention von Krankheiten unterstützt, ist keine DiGA. Auch (Primär-)Präventions-Apps sind potentiell Medizinprodukte, jedoch damit noch keine DiGA. Denn eine DiGA wird z.B. vom Arzt im Falle einer Krankheits-Diagnose verschrieben und richtet sich damit immer an Personen mit einer bestimmten Indikation (ICD-10 Code).

1.7 Kriterium #7: Nutzer ist der Patient

Eine App, die hauptsächlich den Arzt bei seiner täglichen Arbeit unterstützt, ist keine DiGA. Eine DiGA muss für die Nutzung durch den Patienten bestimmt sein. Dabei kann die App durchaus den Arzt mit einbeziehen, solange der Patient der Hauptnutzer bleibt.

1.8 Kriterium #8: Individualisierung

DiGA müssen auf Basis der Eingaben der Patienten individualisierte Rückmeldungen generieren.

Beispiel: Ihre DiGA frägt in einem Onboarding-Fragebogen den Gesundheitszustand des Patienten ab. Danach erhält der Patient eine gleichbleibende Auswahl von Wissensinhalten und Übungen.

Das würde höchstwahrscheinlich das Individualisierungskriterium nicht erfüllen. Die Wissensinhalte und Übungen sollten stattdessen auf Basis der eingegebenen Werte aufbereitet werden. Sie könnten z.B. Patienten mit verschiedenem Schwergrad oder Stadium der Krankheit auch verschiedene Wissensinhalte und Übungen anzeigen. So individualisieren Sie die DiGA auf Basis der eingegebenen Daten.

1.9 Kriterium #9: Ausgeschlossene Leistungen

Die DiGA umfasst keine Leistungen, die nach dem Dritten Kapitel des SGB V ausgeschlossen sind. Ebenso darf sie keine Inhalte enthalten, zu denen der Gemeinsame Bundesausschuss bereits eine ablehnende Entscheidung nach den §§ 92, 135 oder 137c getroffen hat.

1.10 Kriterium #10: Veröffentlichung vor Antrag

Zum Zeitpunkt der Antragstellung muss die DiGA bereits verfügbar sein. Sie muss in den entsprechenden App Stores veröffentlicht sein oder im Fall einer Webanwendung über die vorgesehene Website öffentlich zugänglich sein.

2. Der DiGA-Fähigkeit-Entscheidungsbaum

Im DiGA-Leitfaden der Version 3.6 hat das BfArM eine übersichtliche Grafik eingefügt, die Ihnen bei der Qualifizierung Ihrer Anwendung als DiGA helfen soll:

Abbildung 3 aus dem DiGA-Leitfaden: DiGA-Fähigkeit Entscheidungsbaum. Quelle: BfArM.

Weitere Informationen zu allen Kriterien und Anforderungen finden Sie im offiziellen DiGA-Leitfaden des BfArM.

3. Die Anforderungen bei Erfüllung der Kriterien

Natürlich wird Ihre Software bei Erfüllung dieser Kriterien nicht automatisch in das DiGA-Verzeichnis aufgenommen und erstattet. Falls Sie grundsätzlich jedes dieser Kriterien erfüllen, müssen Sie sich im nächsten Schritt mit den Anforderungen an DiGA befassen. Diese Anforderungen regelt die Digitale Gesundheitsanwendungen-Verordnung (DiGAV). Im offiziellen DiGA-Leitfaden werden diese dann weiter ausgeführt.

Zu den Anforderungen gehören zum einen die „Anforderungen an Sicherheit, Funktionstauglichkeit, Datenschutz und -sicherheit sowie Qualität digitaler Gesundheitsanwendungen“. Zusammengefasst umfasst dieser Punkt folgende Anforderungen:

1. Anforderungen an Sicherheit und Funktionstauglichkeit
2. Anforderungen an Datenschutz und Datensicherheit
3. Anforderungen an Qualität und Interoperabilität
4. Anforderungen an Robustheit
5. Anforderungen an Verbraucherschutz
6. Anforderungen an Nutzerfreundlichkeit
7. Anforderungen an die Unterstützung der Leistungserbringer
8. Anforderungen an die Qualität der medizinischen Inhalte
9. Anforderungen an die Patientensicherheit

Außerdem müssen Sie mit Ihrer DiGA einen positiven Versorgungseffekt nachweisen. Ein positiver Versorgungseffekt ist laut DVG entweder ein medizinischer Nutzen oder patientenrelevante Struktur- und Verfahrensverbesserungen in der Versorgung. Diesen positiven Versorgungseffekt müssen Sie innerhalb wissenschaftlicher Studien belegen. Falls Sie derartige Studien zum Antragszeitpunkt nicht vorliegen haben, müssen Sie zumindest ein wissenschaftliches Evaluationskonzept vorlegen, mit dem Sie zu einem späteren Zeitpunkt die Versorgungseffekte nachweisen möchten.

Des Weiteren müssen Sie z.B. ein Datensicherheitszertifizierung beim BSI erlangen und Ihre DiGA an die elektronische Patientenakte anbinden.

4. Selektivverträge – Eine Alternative zu DiGA

Sollte sich Ihre digitale Lösung nicht als DiGA qualifizieren, gibt es in Deutschland auch die Möglichkeit, Selektivverträge mit einzelnen Krankenkassen abzuschließen. Dies ermöglicht Ihnen einen Weg in die Erstattung, der auf Ihre Anwendung zugeschnitten ist.

In unserem Leitfaden zu Selektivverträgen geben wir Ihnen einen Überblick über diese alternative Form der Kostenerstattung: Zum Leitfaden – Selektivverträge für digitale Lösungen

Sogar über Selektivverträge und DiGA hinaus gibt es noch weitere Wege in die Erstattung für Software-Produkte:

• Überblick über alle Wege in die Kostenerstattung: Zu unserem Whitepaper
• Erstattung von Software im GKV-Hilfsmittelverzeichnis (HMV): Zu unserem Leitfaden
• Digitale Pflegeanwendungen – DiPA-Verfahren: Zu unserem Leitfaden
• Zentrale Prüfstelle Prävention (ZPP): Zu unserem Leitfaden

Neben den genannten Wegen in die Erstattung lohnt auch der Blick auf öffentliche Fördermöglichkeiten, die den Weg dahin überbrücken können. Allen voran lohnt sich ein Blick auf den Innovationsfonds des G-BA, der digitale Versorgungslösungen in frühen Phasen finanziell unterstützt.

Mehr Informationen dazu finden Sie in unserem Leitfaden zum Innovationsfonds: Zum Leitfaden

5. Fazit

Ob Ihre App potenziell eine DiGA ist, wird durch die genannten Kriterien definiert. Der Teufel steckt allerdings oft im Detail. Sie sollten sich also für die Planung auch den offiziellen DiGA-Leitfaden genau durchlesen und von Erfahrungen anderer DiGA-Hersteller lernen. Auch wenn der DiGA-Leitfaden umfangreich ist und sicherlich viele Hilfestellungen bietet, gibt es leider weiterhin viel implizites Wissen bei den existierenden DiGA-Herstellern, welches dort noch nicht abgebildet wurde.

QuickBird Medical entwickelt DiGA auf Auftragsbasis, seit es sie gibt. Stand heute (2025) haben wir bereits über 15 DiGA-Projekte umgesetzt. Falls Sie eine DiGA planen und die Entwicklung sowie die Regulatorik an einen Dienstleister auslagern möchten, kontaktieren Sie uns gerne.

The post Ist Ihre App eine DiGA? Definition & Kriterien digitaler Gesundheitsanwendungen appeared first on QuickBird Medical.

Für die Listung einer Anwendung im DiGA-Verzeichnis prüft das BfArM die Zertifizierung als feste Voraussetzung. Ohne gültiges Zertifikat werden keine neuen DiGA mehr aufgenommen. Und auch gelisteten DiGA droht ohne Zertifizierung eine Streichung aus dem Verzeichnis (der Stichtag für gelistete DiGA existiert allerdings aktuell nicht).

Viele Hersteller unterschätzen, wie umfangreich die Implikationen dieser Zertifizierung sind und wie aufwendig sich der Prüfprozess gestaltet.

Mit diesem Artikel möchten wir (angehenden) DiGA-Herstellern einen strukturierten Überblick geben:

• Was fordert die TR-03161 konkret?
• Wie läuft die Zertifizierung mit Prüfstelle und BSI ab?
• Mit welchen Kostenblöcken ist das Ganze verbunden und wie lange dauert eine solche Zertifizierung?
• Was sind die praktischen Implikationen der BSI TR-03161 auf DiGA?
• Wie sieht die Zukunft der BSI-Zertifizierung aus? (Stichwort: BSI TR-03185)

Auf Basis unserer praktischen Erfahrungen aus mehreren durchgeführten TR-03161-Projekten schildern wir den aktuellen Stand der Zertifizierungsanforderungen.

Inhaltsverzeichnis

• 1. Für wen gilt die BSI TR-03161?
• 2. Anforderungen und Aufbau der BSI TR-03161
  • 2.1 Aufbau der BSI TR-03161
  • 2.2 Umfang: Sowohl Produkt als auch Prozesse
  • 2.3 Prüfaspekte
• 3. Der Zertifizierungsprozess
• 4. Kosten und Zeitrahmen des Zertifizierungsprozesses
  • 4.1 Kosten des Zertifizierungsprozesses
  • 4.2 Zeitrahmen für den Zertifizierungsprozesses
• 5. Gültigkeitsdauer & Rezertifizierung nach BSI TR-03161
• 6. BSI TR-03161-Zertifikat mit Auflagen
• 7. Änderungen an zertifizierten Produkten – BSI TR-03185
• 8. Praktische Implikationen für DiGA
• 9. Verpflichtender Penetrationstest für DiGA
• 10. BSI TR-03161 vs. ISO 27001
• 11. Kritik am Prozess
• 12. Wichtige Links und Ressourcen
  • 12.1 Allgemeine Informationen
  • 12.2 Liste der bereits nach TR-03161 zertifizierten Anwendungen
  • 12.3 Liste der Prüfstellen für die BSI TR-03161
• 13. Zukunftsausblick für die BSI TR-03161 und DiGA-Datensicherheitszertifizierung
• 14. Fazit

1. Für wen gilt die BSI TR-03161?

Die TR-03161 kann grundsätzlich für viele Anwendungen im deutschen Gesundheitswesen genutzt werden, die sensible Daten verarbeiten.

Gesetzlich verpflichtend ist sie jedoch vor allem für digitale Gesundheitsanwendungen (DiGA) nach § 139e SGB V und digitale Pflegeanwendungen (DiPA) nach § 78a SGB XI. Für diese Produkte muss ab 1. Januar 2025 ein offizielles Zertifikat vorgelegt werden.

In diesem Artikel liegt der Fokus auf DiGA, da hier die Zertifizierungspflicht aktuell die größte praktische Relevanz hat.

Für die Zertifizierung nach BSI TR-03161 ist zu beachten:

• Sie ist unabhängig von der Risikoklasse anwendbar
• Sie umfasst sämtliche Komponenten der Anwendung (also App, Backend, Webportal sowie Patienten- und Behandlerzugänge)
• Auch wenn Hosting oder Infrastruktur an externe Cloud-Anbieter ausgelagert werden, müssen diese Komponenten sich an die Anforderungen der BSI TR-03161 halten. Gleichzeitig müssen die Server-Anbieter ein C5-Testat vom Typ 2 vorweisen.
• Neue DiGA benötigen für die Aufnahme in das DiGA-Verzeichnis bereits jetzt eine Zertifizierung nach BSI TR-03161.
• Für zum aktuellen Zeitpunkt bereits gelistete DiGA wird es zurzeit vom BfArM noch geduldet, dass kein Zertifikat vorliegt, solange der Hersteller nachweisen kann, dass er sich im Zertifizierungsprozess befindet. Das kann sich allerdings jederzeit ändern.

Hinweis: Wir bezeichnen das Produkt eines (angehenden) DiGA-Herstellers in diesem Artikel einfachheitshalber immer als „DiGA“, unabhängig davon, ob diese bereits gelistet ist oder nicht. Natürlich ist aber nicht jede Anwendung bereits als DiGA gelistet, sobald sie den Zertifizierungsprozess nach BSI TR-03161 beginnt.

2. Anforderungen und Aufbau der BSI TR-03161

Die Technische Richtlinie TR-03161 definiert die Mindestanforderungen an Datensicherheit für digitale Gesundheits- und Pflegeanwendungen. Damit bildet sie die Grundlage für die gesetzlich geforderte Datensicherheitszertifizierung nach § 139e SGB V und § 78a SGB XI.

IT-Sicherheit im Allgemeinen und auch die BSI TR-03161 verfolgen im Wesentlichen drei Schutzziele: Vertraulichkeit, Integrität und Verfügbarkeit. Die Norm legt durch konkrete Maßnahmen fest, wie Sie als Hersteller sicherstellen müssen, dass sensible Daten vertraulich, integer und verfügbar bleiben.

• Vertraulichkeit bedeutet, dass nur berechtigte Personen oder Systeme auf sensible Daten zugreifen dürfen. Unbefugte dürfen Daten nicht einsehen oder mitlesen, weder in der App noch bei der Übertragung.
  
• Integrität stellt sicher, dass Daten korrekt und unverändert bleiben. Manipulationen oder unbeabsichtigte Änderungen werden verhindert oder eindeutig erkennbar gemacht.
  
• Verfügbarkeit bedeutet, dass Anwendung und Daten zuverlässig nutzbar sind. Ausfälle oder Unterbrechungen werden durch geeignete technische und organisatorische Maßnahmen minimiert.

2.1 Aufbau der BSI TR-03161

Die TR-03161 besteht aus drei Teilen, die zusammen alle sicherheitsrelevanten Komponenten einer digitalen Gesundheitsanwendung abdecken. Jeder Teil fokussiert sich auf eine bestimmte Systemebene und formuliert spezifische Anforderungen, die später im Zertifizierungsaudit einzeln geprüft werden. So entsteht ein vollständiges Sicherheitsmodell, das App, Web-Frontend und Backend gleichermaßen absichert.

Die drei Teile der Richtlinie decken alle technischen Komponenten einer DiGA ab. App, Web-Frontend und Backend werden jeweils separat geprüft und zertifiziert.

• Teil 1: Mobile Anwendungen (Apps): Teil 1 beschreibt die Sicherheitsanforderungen an mobile Anwendungen (beispielsweise iOS und Android). Er legt fest, wie Apps sensible Daten verarbeiten dürfen, wie sie Gerätefunktionen nutzen und wie sie vor Manipulation geschützt werden müssen.
• Teil 2: Web-Anwendungen: Teil 2 richtet sich an webbasierte Komponenten (z. B. eine Web-Oberfläche, die ein Behandler oder Patient im Browser aufrufen kann). Der Teil beschreibt, wie Webanwendungen im Browser sicher ausgeführt werden und wie typische Web-Schwachstellen verhindert werden müssen.
• Teil 3: Hintergrundsysteme (Backend): Teil 3 definiert die Anforderungen an serverseitige Komponenten, unabhängig davon, ob diese On-Premise oder in der Cloud betrieben werden. Da sensible Gesundheitsdaten in der Regel zentral verarbeitet werden, enthält dieser Teil besonders umfangreiche Vorgaben zur Architektur und zum Betrieb.

Wichtig ist hier, dass für jede DiGA individuell entschieden wird, welche dieser 3 Teile für das Produkt zutreffen. Eine Web-Anwendung mit Backend-Server muss z. B. nur Teil 2 und 3 und nicht Teil 1 (für mobile Anwendungen) im Rahmen der Zertifizierung berücksichtigen.

2.2 Umfang: Sowohl Produkt als auch Prozesse

Der Aufbau der Richtlinie folgt einer klaren Systematik, die auf einer sogenannten Security Problem Definition basiert. Diese umfasst:

• Annahmen über Browser, Endgerät und Backend-Infrastruktur
• definierte Bedrohungsszenarien wie unbefugten Zugriff, Datenmanipulation, Ausnutzen von Debug-Funktionen oder Fehlkonfigurationen
• organisatorische Sicherheitsrichtlinien, die der Hersteller umsetzen muss, zum Beispiel: Security-Lifecycle, Patch-Management, Offenlegung des Datenverarbeitungszwecks, Prozesse zur Meldung von Schwachstellen

Die TR-03161 betrachtet damit nicht nur die technische Umsetzung (Quellcode und Produkt), sondern auch Prozesse und Dokumentation. Ein produktbezogener Pen-Test reicht also nicht für eine Zertifizierung. Auch die Prozesse und die Dokumentation des Herstellers werden überprüft.

2.3 Prüfaspekte

Die Richtlinie strukturiert alle Anforderungen in Prüfaspekte. Jeder Prüfaspekt enthält konkrete Regeln, die mit MUSS, SOLL, KANN oder DARF NICHT versehen sind.

Jeder Teil der BSI TR-03161 enthält 11 (bei Teil 1 und 2) bzw. 10 (bei Teil 3) Prüfaspekte:

1. Anwendungszweck
2. Architektur
3. Quellcode
4. Drittanbieter-Software
5. Kryptographische Umsetzung
6. Authentisierung und Authentifizierung
7. Datensicherheit
8. Kostenpflichtige Ressourcen
9. Netzwerkkommunikation
10. Organisatorische Sicherheit (nur bei Teil 3 – Hintergrundsysteme)
11. Plattformspezifische Interaktionen (nur bei Teil 1 und 2 – Mobile & Web)
12. Resilienz (nur bei Teil 1 und 2 – Mobile & Web)

Tipp: Kopieren Sie sich eine Liste der einzelnen Prüfaspekte jedes Teils der TR-03161 in Ihre Unterlagen und haken Sie diese strukturiert nacheinander ab. Das ist ein hilfreiches Projektmanagementinstrument für Ihr Entwicklerteam.

3. Der Zertifizierungsprozess

Der gesamte Zertifizierungsprozess für eine DiGA verläuft über drei Phasen hinweg:

1. Vorbereitungsphase: Sie als DiGA-Hersteller bereiten sich auf den Prüfprozess vor. Sie arbeiten sich in die Norm BSI TR-03161 ein und setzen die Vorgaben nach bestem Gewissen innerhalb Ihres Produkts und Ihrer Prozesse um. Sie suchen sich außerdem eine Prüfstelle für die Zertifizierung, schaffen die vertragliche Basis für die Zusammenarbeit mit dieser und reservieren sich einen Prüftermin.
2. Prüfphase: Sobald Sie von Ihrer Seite mit der Umsetzung der TR-Vorgaben fertig sind, schicken Sie Ihre Unterlagen, Produktzugänge und Software-Quellcode an die Prüfstelle. Diese beginnt den Prüfprozess und schickt Ihnen nach Abschluss der Prüfung den Prüfbericht inklusive möglicher Abweichungen. Ob es auch zwischenzeitliches Feedback oder andere Kommunikation gibt, hängt dabei von der jeweiligen Prüfstelle ab. Falls die Prüfstelle in allen Punkten zufrieden ist, bereitet sie den Prüfbericht für die Versendung an das BSI vor.
3. Zertifizierungsphase: Die Zertifizierungsstelle des BSI erhält den fertigen Prüfbericht von der Prüfstelle und evaluiert, ob sie die Zertifizierung auf dieser Basis positiv bewerten kann. Wenn ja, erhalten Sie vom BSI nun das Zertifikat inklusive Konformitätsreport. Wenn nicht, schickt das BSI eine kommentierte Liste des Prüfberichts an die Prüfstelle zurück. Diese evaluiert das Feedback und gibt die für Sie als Hersteller relevanten Abweichungen an den DiGA-Hersteller zur Umsetzung weiter.

Hinweis: Die Prüfstelle bezeichnet ein privates Unternehmen, das durch das BSI offiziell für die Prüfung dieser technischen Richtlinie akkreditiert wurde. Eine Liste der Prüfstellen finden Sie hier unten im Artikel. Mit Zertifizierungsstelle bezieht man sich hingegen auf die Abteilung beim BSI, die für die Zertifizierung zuständig ist und darüber in letzter Instanz entscheidet.

Den Ablauf des Zertifizierungsprozesses haben auch wir in vereinfachter Form in der folgenden Abbildung skizziert.

BSI-Zertifizierungsprozess für DiGA-Hersteller nach TR-03161

4. Kosten und Zeitrahmen des Zertifizierungsprozesses

4.1 Kosten des Zertifizierungsprozesses

Für die interne Budgetplanung sollten Sie mit folgenden Kostenpaketen rechnen:

1. Die Kosten der Prüfstelle: Für die Arbeit der Prüfstelle zur Zertifizierung fallen natürlich Kosten an. Die Höhe dieser Kosten variiert zwischen den Prüfstellen und hängt außerdem von Ihrem Produkt und dem Umfang der Prüfung ab. Wir empfehlen Ihnen, mehrere Angebote einzuholen, um diese zu vergleichen.
2. Die Kosten für das BSI: Gegebenenfalls weniger offensichtlich ist, dass auch das BSI nach Abschluss des Zertifizierungsprozesses eine Rechnung an Sie schicken wird. Das passiert übrigens unabhängig davon, ob die Prüfung erfolgreich war oder nicht. Die Gebührenordnung finden Sie hier.
3. Entwicklungskosten: Für das Entwicklerteam werden signifikante Aufwände bei der Implementierung der TR-Anforderungen anfallen. Die damit zusammenhängenden Kosten sollten Sie natürlich auch einplanen.
4. Beratungskosten: Es empfiehlt sich, mit einem Team zusammenzuarbeiten, das den BSI-Zertifizierungsprozess schon für andere DiGA bereits erfolgreich abgeschlossen hat. So können Sie sich durch praxisnahe Insights oft wochenlange Arbeit ersparen. Die Kosten hierfür sind verhältnismäßig überschaubar, sollten aber eingeplant werden.

Wir bei QuickBird Medical unterstützen Unternehmen in allen technischen und organisatorischen Aspekten der BSI-Zertifizierung. Wir haben u. a. mit der von uns entwickelten DiGA „Oriko®“ eines der ersten 3 BSI-Zertifikate überhaupt erhalten. Wir helfen Ihnen, effizient und sicher durch die Zertifizierung zu kommen. Kontaktieren Sie uns hierzu gern: Kontakt aufnehmen

4.2 Zeitrahmen für den Zertifizierungsprozesses

Der Zertifizierungsprozess und somit auch der Zeitplan können in die oben genannten drei Phasen gegliedert werden:

1. Vorbereitungsphase: Hier implementiert Ihr Entwicklerteam die BSI-Vorgaben. Wie schnell Sie hierbei sind, kommt auf viele Faktoren an (Kompetenz der Entwickler, Zustand des aktuellen Systems in Bezug auf Security, Anzahl der Entwickler etc.)
2. Prüfphase: Der Zeitrahmen hängt hier stark von der Prüfstelle und der Qualität Ihrer Dokumentation und Produktimplementierung ab. Sie sollten mit mindestens 4 bis 6 Wochen rechnen, bis Sie einen Prüfbericht erhalten.
3. Zertifizierungsphase: Sobald die Prüfstelle den Prüfbericht für Ihr Produkt an das BSI geschickt hat, beginnt die Zertifizierungsphase. Auf offizieller Seite des BSI wird hier von 3 Wochen geredet. Unserer Erfahrung nach sollte man hier aktuell aber eher 6 Wochen ansetzen.

5. Gültigkeitsdauer & Rezertifizierung nach BSI TR-03161

Ein vom BSI erteiltes Zertifikat nach Technischen Richtlinien ist zeitlich befristet gültig. In der Regel beträgt die Gültigkeitsdauer eines Produktzertifikats fünf Jahre.

Abweichende Laufzeiten sind nur möglich, wenn dies im jeweiligen Zertifizierungsprogramm ausdrücklich festgelegt ist. Die Gültigkeit ist zudem immer auf die konkret geprüfte Produktversion sowie auf die zugrunde liegende Version der Technischen Richtlinie beschränkt.

Kann die Konformität eines Produkts nach Ablauf der Gültigkeit oder nach wesentlichen, sicherheitsrelevanten Änderungen nicht ohne erneute Prüfung bestätigt werden, ist eine Rezertifizierung erforderlich. Dabei wird erneut geprüft, ob das Produkt die Anforderungen der TR erfüllt. Der Prüfumfang kann sich auf die geänderten Teile beschränken, sofern frühere Prüfergebnisse weiterhin verwendbar sind. 

Laut offiziellem Zitat des BSI hier, sollte eine Rezertifizierung spätestens drei Monate nach Ablauf des bestehenden Zertifikats beantragt werden (ob das BfArM dem für DiGA auch so zustimmt, bleibt abzuwarten). Bei erfolgreichem Abschluss wird ein neues Zertifikat für die geänderte Produktversion ausgestellt.

6. BSI TR-03161-Zertifikat mit Auflagen

Ein Zertifikat nach BSI TR-03161 hat üblicherweise eine Gültigkeit von bis zu fünf Jahren. In Einzelfällen kann das BSI jedoch im Rahmen der Zertifizierungsentscheidung Nebenbestimmungen in Form von Auflagen festlegen, die vom Hersteller innerhalb eines definierten Zeitraums umzusetzen sind. 

In der Praxis bedeutet dies, dass ein Zertifikat bis zur Bearbeitung von bestimmten Auflagen mit einer Gültigkeit von wenigen Monaten erteilt werden kann. Der Hersteller erhält in diesem Fall zunächst einen gültigen Zertifizierungsnachweis (mit Auflagen), ist jedoch verpflichtet, die festgelegten Auflagen fristgerecht umzusetzen und nachzuweisen. Werden diese Auflagen nicht erfüllt, kann die Zertifizierung wieder aufgehoben werden. Bei nachweislicher Erfüllung der Auflagen innerhalb der Frist wird dann ein reguläres Zertifikat ohne Auflagen ausgestellt.

Dieses Vorgehen ermöglicht es, vereinzelte Abweichungen später nachzuziehen, um z. B. den DiGA-Antragsprozess nicht zu blockieren (bzw. vom BfArM abgelehnt zu werden). Ein BSI-Zertifikat mit Auflagen setzt aber eine umfassende Implementierung aller Anforderungen der BSI TR-03161 durch den DiGA-Hersteller voraus. Die Zertifizierung ist weiterhin enorm herausfordernd und sollte auf keinen Fall unterschätzt werden.   

7. Änderungen an zertifizierten Produkten – BSI TR-03185

Ein Zertifikat gilt ausschließlich für die im Rahmen der Konformitätsprüfung geprüfte Produktversion. Jede Änderung am Produkt, etwa durch Weiterentwicklung, Updates, Patches oder Hotfixes, führt zunächst zu einer neuen Version, für die das bestehende Zertifikat keine automatische Gültigkeit mehr besitzt. Ob und wie diese Änderungen zertifizierungsseitig behandelt werden, hängt von ihrer Auswirkung auf die TR-Konformität ab.

Können Auswirkungen auf die Konformität nicht ausgeschlossen werden, ist eine Re-Zertifizierung erforderlich. Handelt es sich hingegen um geringfügige Änderungen, bei denen eine Beeinträchtigung der Konformität eindeutig ausgeschlossen werden kann, kommt ein sogenanntes Maintenanceverfahren infrage. In diesem Fall wird das bestehende Zertifikat auf die neue Produktversion erweitert, ohne dass eine erneute vollständige Konformitätsprüfung notwendig ist. Die Entscheidung darüber trifft das BSI auf Basis einer vom Hersteller vorzulegenden Änderungsdokumentation und Auswirkungsanalyse. Die ursprüngliche Laufzeit des Zertifikats bleibt dabei unverändert.

Zukünftiger Umgang mit Produktänderungen – die neue BSI TR-03185

Jede kleinere Änderung durch das BSI absegnen zu lassen, macht den DiGA-Entwicklungsprozess natürlich deutlich ineffizienter. Gerade auch bei kritischen Fehlern einer DiGA ist es wichtig, Probleme durch Hotfixes schnell zu beheben. Der aktuelle Prozess mit BSI-Prüfungen jeder Änderung scheint hierfür nicht geeignet.

Aktuell arbeitet das BSI daher an einer grundlegenden Weiterentwicklung des Umgangs mit Produktänderungen bei DiGAs. Im Mittelpunkt steht dabei die geplante Einführung der BSI TR-03185 „Sicherer Software-Lebenszyklus“, die den Update- und Änderungsprozess von Softwareprodukten strukturiert adressieren soll. 

Mit der TR-03185 ist ein eigenständiges Zertifizierungsprogramm vorgesehen, bei dem Konformitätsprüfungen durch vom BSI akkreditierte IT-Grundschutz-Auditoren durchgeführt werden. 

Die Idee dahinter: DiGA-Hersteller mit einer zusätzlichen Zertifizierung nach BSI TR-03185 haben nachweislich einen sicheren Software-Entwicklungsprozess (bzw. Lebenszyklus). Daher soll es diesen Herstellern erlaubt sein, bestimmte Änderungen am Produkt auch ohne vorherige BSI-Prüfung zu veröffentlichen. 

Es ist vorgesehen, dass DiGA-Hersteller mit einer Zertifizierung nach BSI TR-03185 deutlich weniger Prüfverfahren für Folgeversionen ihrer nach BSI TR-03161 zertifizierten Produkte durchführen müssen. DiGA-Hersteller sind aber nicht explizit zur Zertifizierung nach BSI TR-03185 verpflichtet. Implizit wird der reibungslose Betrieb einer DiGA ohne die TR-03185-Zertifizierung aber vermutlich schwer möglich sein.

Die Inhalte der BSI TR-03185 können Sie hier einsehen: Link (BSI-Website) 

Aktuell sind noch keine Antragstellungen oder Zertifizierungen möglich. Nach aktuellem Stand werden erste Zertifizierungen frühestens ab Anfang 2026 erwartet. Die konkreten Rahmenbedingungen hierzu befinden sich jedoch noch in Abstimmung.

8. Praktische Implikationen für DiGA

Die Anforderungen der BSI TR-03161 wirken sich unmittelbar auf das Produkt sowie die Entwicklung, den Betrieb und die Weiterentwicklung von DiGAs aus. Wir bei QuickBird Medical haben die BSI-Anforderungen mittlerweile in mehreren DiGA vollständig implementiert und z. B. für die DiGA „Oriko®“ eins der ersten 3 BSI-Zertifikate erhalten.

Die BSI-Zertifizierung hatte auf unsere Kundenprojekte viele Auswirkungen. Einige fassen wir hier zusammen:

• Änderungen nach der Zertifizierung: Anpassungen am Produkt sind später deutlich aufwendiger, da ein komplexer Änderungsprozess durchlaufen werden muss und Genehmigungen pro Release zusätzliche Zeit und Kosten verursachen.
• Stark regulierte Zwei-Faktor-Authentifizierung: Es existieren sehr hohe Anforderungen an die Umsetzung von Zwei-Faktor-Authentifizierung in DiGA. Diese Anforderungen beeinträchtigen je nach Implementierung stark die Nutzerfreundlichkeit der DiGA. Es gibt hier bessere und schlechtere Varianten der Umsetzung im Sinne der Nutzerfreundlichkeit. (Kontaktieren Sie uns gern, falls Sie hierzu Input benötigen.)
• Kurze Session-Laufzeiten und potenziell häufige Re-Logins: Die Anforderungen der BSI TR-03161 führen dazu, dass Anmelde- und Session-Zeiten stark begrenzt werden müssen. Je nach technischer Umsetzung kann dies dazu führen, dass Nutzer sich vergleichsweise häufig erneut anmelden müssen, was den Nutzungskomfort der DiGA spürbar beeinträchtigen kann. Auch hier gibt es Möglichkeiten, das Ganze so zu lösen, dass es den Nutzer weniger beeinträchtigt. (Kontaktieren Sie uns gern, falls Sie hierzu Input benötigen.)
• Erhöhter Entwicklungsaufwand: Architektur, Implementierung, Tests und Dokumentation erfordern deutlich mehr Aufwand als bei nicht regulierten Anwendungen.
• Datenverlust bei Geräteverlust: Es gibt verschiedene Wege, die TR-Anforderungen in einer DiGA umzusetzen. Jede davon hat Vor- und Nachteile. Bei bestimmten Varianten in Bezug auf Authentifizierung ist es nahezu unmöglich, die DiGA-Daten wiederherzustellen, wenn ein Nutzer z. B. sein Handy verliert.
• Strenge Resilience-Anforderungen: Bestimmte Betriebssystemversionen und Gerätekonfigurationen sind ausgeschlossen, etwa ältere Android-Versionen oder aktivierter Developer Mode, obwohl diese bei einem relevanten Anteil der Nutzer noch verbreitet sind. Das ist auf der einen Seite aus Sicherheitssicht nachvollziehbar, aber führt dazu, dass z. B. bis zu 10% Ihrer Zielgruppe keinen Zugriff auf die DiGA erhalten können.
• Eingeschränkte Hotfix-Fähigkeit: Kurzfristige Fehlerbehebungen sind offiziell nur mit Freigabe durch das BSI möglich, was schnelle Reaktionen erschwert. Dies soll sich perspektivisch durch die zusätzliche Zertifizierung nach TR-03185 verbessern, wodurch bestimmte Änderungen ggf. keine Freigabe mehr erfordern würden.

9. Verpflichtender Penetrationstest für DiGA

Die Pflicht zu einem Penetrationstest („Pen-Test“) ergibt sich nicht aus der BSI TR-03161. Sie stammt aus dem gesetzlichen Rahmen der DiGA-Verordnung (DiGAV). Dort wird festgelegt, dass jede DiGA einen aktuellen Penetrationstest nachweisen muss, um die Anforderungen an die Datensicherheit gemäß Anlage 1 DiGAV zu erfüllen. 

Mit dem neuen DiGA-Leitfaden vom 10.12.2025 bezieht das BfArM hierzu konkrete Stellung: Durch die Zertifizierung nach TR-03161 entfällt die Notwendigkeit eines zusätzlichen Pen-Tests für die Zulassung einer DiGA. 

10. BSI TR-03161 vs. ISO 27001

Für die Listung einer DiGA im Verzeichnis im BfArM muss der Hersteller sowohl eine ISO 27001-Zertifizierung als auch eine BSI TR-03161-Zertifizierung vorlegen. Bei beiden geht es um Informationssicherheit. Wieso also zwei Zertifizierungen?

Der Grund hierfür liegt im Fokus dieser beiden Normen.

Die ISO 27001 ist eine reine Managementnorm: Sie definiert, wie ein umfassendes Informationssicherheits-Managementsystem (ISMS) im Unternehmen aufgebaut, betrieben und kontinuierlich verbessert wird. Zertifiziert wird also das Unternehmen und seine Prozesse, nicht ein einzelnes Produkt. Es findet keine produktbezogene Prüfung, kein Architektur-Review und keine Analyse von Quellcode oder konkreten Sicherheitsmaßnahmen eines Produkts statt.

Die BSI TR-03161 hingegen ist eine technische Produktzertifizierung speziell für digitale Gesundheits- und Pflegeanwendungen. Sie legt sehr konkrete technische und organisatorische Sicherheitsanforderungen fest und prüft, ob das einzelne Produkt (inklusive App, Backend, Schnittstellen) diese erfüllt. Damit ist sie wesentlich spezifischer, strenger und produktnäher als ISO 27001 und dient in Deutschland als gesetzliche Grundlage für DiGA– und DiPA-Zulassungen.

11. Kritik am Prozess

Sowohl die Verpflichtung zur Zertifizierung nach BSI TR-03161 als auch die daraus resultierenden, sehr strikten Anforderungen werden von vielen Seiten stark kritisiert. Häufig genannte Punkte sind dabei:

• Einschränkungen bei der Benutzerfreundlichkeit: Mehrstufige Sicherheitsmechanismen und strikte Vorgaben können die Usability spürbar beeinträchtigen. Es wird betont, dass Patienten dadurch einen erschwerten Zugang zu digitalen Gesundheitsangeboten haben.
• Eingeschränkte Zugänglichkeit für relevante Zielgruppen: Durch die sehr restriktiven Geräte- und Systemanforderungen der BSI TR-03161 werden viele Endgeräte ausgeschlossen. Insbesondere ältere Menschen sowie Personen mit körperlichen oder kognitiven Einschränkungen nutzen häufig Geräte, die diese Anforderungen nicht erfüllen und somit nicht akzeptiert werden. Dadurch bleibt ein erheblicher Teil der eigentlich relevanten Zielgruppe von der Nutzung digitaler Gesundheitsanwendungen ausgeschlossen.
• Hoher Aufwand in Umsetzung und Dokumentation: Die sehr detaillierten Sicherheits- und Prozessanforderungen führen nach Ansicht zahlreicher Hersteller zu erheblichen zusätzlichen Entwicklungs- und Dokumentationsarbeiten. Monatelange Zusatzarbeiten erschweren und verhindern derartige neue Innovationen.
• Steigende Kosten für Anbieter: Sowohl die Zertifizierung selbst als auch der kontinuierliche Nachweis der Konformität verursachen enorme Kosten aufseiten der DiGA-Hersteller. Gerade für kleine Unternehmen sind diese Kosten schwer bis unmöglich zu finanzieren.
• Unklarheit bei den Anforderungen: Bei vielen Punkten der TR-03161 ist nicht eindeutig, wie eine korrekte Umsetzung nach Ansicht des BSI auszusehen hat. Teilweise widersprechen sich einzelne Anforderungen auch gegenseitig. Somit stecken DiGA-Hersteller viel Zeit in eine Implementierung, die dann potenziell nach langen Wartezeiten durch das BSI abgewiesen wird.
• Nationaler Alleingang: Kritiker bemängeln, dass die BSI TR-03161 einen rein deutschen Sicherheitsstandard darstellt, der nicht mit europäischen Vorgaben harmonisiert ist. Dies erschwert die internationale Skalierung und erhöht den regulatorischen Aufwand für Hersteller.

Mehrere Branchenvertretungen haben diese Punkte in ihren Stellungnahmen hervorgehoben und eine ausgewogenere Lösung zwischen Sicherheit, Praktikabilität und wirtschaftlicher Umsetzbarkeit gefordert (siehe z. B. hier, hier und hier).

Inwiefern auf diese Punkte in Zukunft eingegangen wird, bleibt abzuwarten. Hier ist vor allem das nächste Update zur BSI TR-03161 relevant, welches vermutlich im Jahr 2026 erscheinen soll.

12. Wichtige Links und Ressourcen

12.1 Allgemeine Informationen

Hier finden Sie wichtige Ressourcen in Bezug auf die BSI-Zertifizierung:

• Links zu den PDFs der BSI TR-03161 (siehe unterer Teil der Seite): Link (BSI-Website)
• FAQ zur BSI TR-03161: Link (BSI-Website)
• Informationen zu TR-Zertifizierungen beim BSI: Link (BSI-Website)
• Links zu den PDFs der BSI TR-03161 (Sicherer Software-Lebenszyklus): Link (BSI-Website) 

12.2 Liste der bereits nach TR-03161 zertifizierten Anwendungen

Sie können in unserem DiGA-Verzeichnis-Analyzer bequem nach den BSI-zertifizierten DiGA filtern, die jeweilige Prüfstelle der DiGA sehen und weitere Attribute vergleichen: DiGA-Verzeichnis-Analyzer für Hersteller (inkl. BSI-Zertifizierungen)

Die offizielle Liste der digitalen Gesundheitsanwendungen (inkludiert Anwendungen vor Listung), die bereits ein Zertifikat vom BSI erhalten haben, finden Sie hier: Offizielle Liste der zertifizierten Anwendungen

12.3 Liste der Prüfstellen für die BSI TR-03161

Hier finden Sie eine Liste der vom BSI akkreditierten Prüfstellen: Liste der akkreditierten TR-Prüfstellen

Wenn Sie eine Textsuche auf der Seite nach „03161“ durchführen, finden Sie alle Stellen, welche Ihre Zertifizierung nach BSI TR-03161 begleiten können.

13. Zukunftsausblick für die BSI TR-03161 und DiGA-Datensicherheitszertifizierung

Die Anforderungen an Datensicherheit für DiGAs entwickeln sich aktuell weiter und werden in den kommenden Jahren weiter konkretisiert. Dabei zeichnen sich insbesondere drei relevante Entwicklungen ab, die von DiGA-Herstellern frühzeitig eingeplant werden sollten.

• Aktualisierung der BSI TR-03161: Für das kommende Jahr ist eine Aktualisierung der TR-03161 angekündigt. Erwartet wird, dass dabei praktische Erfahrungen aus der bisherigen Anwendung einfließen und einzelne Anforderungen präzisiert oder angepasst werden.
• Einführung der BSI TR-03185 zum sicheren Software-Lebenszyklus: Ergänzend zur TR-03161 ist mit der TR-03185 eine neue Zertifizierung für den gesamten Software-Lebenszyklus in Vorbereitung. Ziel ist es, Update- und Änderungsprozesse systematischer abzubilden und perspektivisch den Aufwand für wiederkehrende Re-Zertifizierungen bei Folgeversionen zu reduzieren.
• Datenschutz-Zertifizierung: Neben Datensicherheit ist weiterhin eine Datenschutz-Zertifizierung für DiGA geplant (und bereits gesetzlich verankert). Sobald ein Prüfprozess und Prüfstellen hierfür etabliert wurden, wird das BfArM diese Zertifizierung von DiGA-Herstellern einfordern.

14. Fazit

Für DiGAs steigt die Zahl verpflichtender Zertifizierungen scheinbar kontinuierlich weiter: Medizinprodukt-Zulassung bzw. Zertifizierung, ISO 27001, BSI TR-03161 und zukünftige Zertifizierungen wie die BSI TR-03185 (nicht verpflichtend, aber scheinbar unumgänglich) und das Datenschutz-Zertifikat für DiGA.

Dies führt zu einer zunehmenden regulatorischen Komplexität, die insbesondere kleinere Hersteller stark belastet. Das notwendige Budget zur Vorbereitung, Umsetzung und kontinuierlichen Erhaltung dieser Zertifizierungen wächst aktuell stetig weiter. Aus unserer Sicht besteht die Gefahr, dass Innovationsgeschwindigkeit und Markteintritt neuer Lösungen dadurch gebremst oder sogar verhindert werden. 

Dennoch ist das Ganze mit der richtigen Strategie (und ausreichendem Budget) weiterhin machbar. Wir haben in unseren DiGA-Projekten gelernt, mit der Komplexität umzugehen, und viele Learnings gemacht, die wir gerne weitergeben. Gerade in Bezug auf die BSI TR-03161-Zertifizierung fehlen bei einigen Anforderungen klare Vorgaben zur Umsetzung von offizieller Seite. Damit nicht jeder Hersteller diese Learnings neu machen muss, beraten wir Hersteller bei der Umsetzung der BSI-Vorgaben.

Falls Sie einen Partner benötigen, der Ihre DiGA implementiert, die BSI-Anforderungen umsetzt und alle weiteren regulatorischen Pflichten für Sie übernimmt: Kontaktieren Sie uns gerne. Wir waren bereits in die Umsetzung von über 15 verschiedenen DiGA-Projekten involviert und besitzen die notwendigen Zertifikate, um Ihre DiGA sicher auf den Markt zu bringen. Mehr Infos dazu finden Sie hier.

The post BSI TR-03161 für DiGA: Zertifizierung der Datensicherheit appeared first on QuickBird Medical.

Der aktuelle DiGA-Leitfaden des BfArM ist hier abrufbar. 

Inhaltsverzeichnis

• 1. Änderungen zwischen der Version 3.6 & Version 3.5 des DiGA-Leitfadens
  • 1.1 PDF-Dokument mit allen Änderungen
  • 1.2 Liste aller Änderungen
• 2. Änderungen zwischen der Version 3.5 & Version 3.4 des DiGA-Leitfadens
• 3. Zukünftige Änderungen des DiGA-Leitfadens

1. Änderungen zwischen der Version 3.6 & Version 3.5 des DiGA-Leitfadens

Die Aktualisierung des DiGA-Leitfadens vom 10.12.2025 (von Version 3.5 auf 3.6) ist umfangreich. Der Leitfaden ist von 177 auf 215 Seiten angewachsen und viele relevante Themenblöcke sind hinzugekommen.

Die größeren Änderungen inkludieren z. B.:

• DigiG: Neue Regelungen des DigiG wurden nun auch im DiGA-Leitfaden eingearbeitet (z. B. für DiGA der Risikoklasse IIb)
• DiGAV Update: Neue Regelungen des Referentenentwurfs der 2. DiGAV-ÄndV wurden eingearbeitet (vorwiegend anwendungsbegleitende Erfolgsmessung – AbEM)
• BSI TR-03161 als Standard: Datensicherheit wird vollständig über das BSI-Zertifikat abgedeckt. Der Nachweis der Datensicherheit über die DiGAV-Checkliste entfällt
• DiGA-Qualifizierung präzisiert: Klarere Abgrenzung zwischen DiGA und Nicht-DiGA inkl. neuem Entscheidungsbaum zur DiGA-Fähigkeit (Zweckbestimmung, Individualisierung, Steuerung aktiver Medizinprodukte, Risikoklasse IIb)
• Evidenzanforderungen konkretisiert: Präzisierungen zu Studiendesign, Signifikanzniveau (5 %), Randomisierung, Studienberichten und Auswertung
• Interoperabilität aktualisiert: Ablösung von „vesta“ durch „INA“ als Referenz für interoperable E-Health-Infrastruktur
• Prozessklarstellungen: Detailliertere Regelungen zu Fristen, Antragsportal, Lebenszyklus, Pflichten nach Listung und Löschung
• Umfang & Struktur erweitert: Allgemein deutlicher Ausbau des Leitfadens (177 → 215 Seiten) mit neuen Kapiteln, FAQs und Beispielen

Dazu kommen viele weitere kleinere bis mittelgroße Änderungen. Wir haben alle Änderungen analysiert und für Sie untenstehend zusammengefasst. Aufgrund des Umfangs der Änderungen geben wir hier nicht den genauen Wortlaut wieder, sondern fassen die Anpassungen jedes geänderten Kapitels grob zusammen.

Für interne Produktentscheidungen sollten Sie allerdings den Originalwortlaut im DiGA-Leitfaden nachlesen. Die folgende Liste soll Ihnen vor allem eine strukturierte Übersicht geben.

1.1 PDF-Dokument mit allen Änderungen (von Version 3.5 zu 3.6)

Zur einfacheren Durchsicht aller Änderungen können Sie auch das folgende Dokument nutzen. Dieses Dokument ist das Ergebnis eines automatisierten Vergleichs der beiden Versionen (3.6 vs. 3.5) des DiGA-Leitfadens.

Download der Gegenüberstellung aller Änderungen

1.2 Liste aller Änderungen (von Version 3.5 zu 3.6)

Abkürzungsverzeichnis
Folgende Abkürzungen wurden hinzugefügt:

• AbEM: Anwendungsbegleitende Erfolgsmessung
• CGI Scale: Clinical Global Impressions Scale
• DigiG: Digital-Gesetz
• J2R: Jump-To-Reference
• PGI-C: Patient Global Impression of Change
• PREMs: Patient-Reported Experience Measures
• PROMs: Patient-Reported Outcome Measures
• RCT: Randomisierte kontrollierte Studie
• SOP: Standard Operating Procedure
• INA: Interoperabilitäts-Navigator der Gematik

2.1 Was ist eine DiGA und was nicht?:
Präzisere Abgrenzung zwischen DiGA und Nicht-DiGA (Individualisierung, Konsistenz der Zweckbestimmung, Steuerung aktiver therapeutischer Medizinprodukte etc.); neuer „DiGA-Fähigkeit Entscheidungsbaum“ als Grafik; Inklusion von Risikoklasse IIb nach DigiG

2.1.1.1 Erstattungsfähigkeit von Hardware (neues Kapitel):
Klarstellung, dass Gebrauchsgegenstände des täglichen Lebens (z. B. Smartwatches, Smartphones, Tablets) sowie Hilfsmittel nach § 33 SGB V nicht über DiGA erstattungsfähig sind; Präzisierung der Gerätekategorien (keine, enthaltene, optionale, notwendige Zusatzgeräte)

2.1.1.2 Wahlfreiheit der Versicherten und ärztliche Therapiefreiheit (neues Kapitel):
Klarstellung, dass DiGA keine Lock-in-Effekte erzeugen dürfen und grundsätzlich mit vergleichbaren Hilfsmitteln nutzbar sein müssen; Ausnahme bei zwingender Bindung an ein spezifisches, nicht gelistetes Medizinprodukt aus Sicherheitsgründen.

2.1.2 Kombination mit Dienstleistungen:
Konkretes neues Beispiel, welches sich nicht als DiGA qualifizieren würde (DiGA für reine Datenübermittlung an ärztliches Personal)

2.1.3 Umfang der DiGA:
Konkretisierung, dass Nachweis für positiven Versorgungseffekt ohne optionale Funktionen erbracht werden muss und optionale Funktionen gekennzeichnet werden müssen

2.3 Vorläufige und dauerhafte Aufnahme:
Klarstellung, dass DiGA der MDR-Risikoklasse IIb nicht vorläufig bzw. auf Erprobung gelistet werden können.

2.3.1 Beantragung der dauerhaften Aufnahme in das DiGA-Verzeichnis:
Ergänzungen für DiGA der MDR-Risikoklasse IIb

3.1 Aufbau der Checklisten für die Anforderungen an DiGA:
Datensicherheit wird nicht mehr nach DiGAV-Checkliste nachgewiesen, sondern durch BSI-Zertifikat.

3.2 Sicherheit und Funktionstauglichkeit:
Konkretisierung, dass Konformitätsbewertungsverfahren für das Medizinprodukt vor DiGA-Antragsstellung abgeschlossen sein muss

3.3 Datenschutz:
Datenschutz-Zertifizierung aktuell weiterhin noch nicht möglich; Verweis auf zukünftige Pflicht der Zertifizierung, sobald dies möglich ist

3.3.2 Zulässige Datenverarbeitung nach § 4 Absatz 2 Satz 1 und 2 DiGAV:
Ergänzung von FAQ-Element zu Einwilligung bei externen Datenplattformen (z.B. Apple Health)

3.3.4 Ausblick auf die Datenschutzkriterien nach § 139e Absatz 11 SGB V:
Aktualisierung des aktuellen Stands in Bezug auf zukünftige Datenschutz-Zertifizierung (aktuell weiterhin noch nicht möglich)

3.4 Datensicherheit:
Viele Inhalte entfernt und ersetzt durch Referenzen zu BSI TR-03161 und dem damit einhergehenden Zertifizierungsprozess; DiGAV-Checkliste zur Datensicherheit muss nicht mehr ausgefüllt werden (stattdessen Referenz auf TR-03161 etc.)

3.4.2 Sicherheit als Prozess:
Klarstellung, dass das BSI-Zertifikat die Datensicherheit vollständig abdeckt und Pen-Test für den DiGA-Antrag nicht zusätzlich benötigt wird.

3.5.1.1 INA und MIOs als Basis einer interoperablen E-HealthInfrastruktur:
„vesta“ wird durch „INA“ abgelöst (mehr Infos hier)

3.5.4.3 Datenerfassung über Medizingeräte, Wearables und andere Sensorik:
„vesta“ wird durch „INA“ abgelöst (mehr Infos hier)

3.5.4.4 Schreiben der DiGA in die ePA/Implementierung der GesundheitsID:
Konkretisierungen für DiGA im Antragsverfahren (oder davor)

4.1.2 Patientenrelevante Struktur- und Verfahrensverbesserungen (pSVV):
Umfangreiche Klarstellungen, Beispiele und FAQ in Bezug auf pSVV

4.3 Allgemeine Anforderungen an Studien zum Nachweis positiver Versorgungseffekte:
Ergänzung des Mindest-Signifikanzniveaus von 5%; Ergänzungen zum Umgang mit Abbrechern bzw. Drop-outs, Sprachversion, Daten aus dem Ausland sowie Interventionszeitraum und Verordnungszeitraum

4.3.2 Grundsätze bei der Auswertung und Bewertung von Studienergebnissen durch den Hersteller (neues Kapitel):
Klarstellung, dass die Bewertung auf präspezifizierten, konservativen Analysen (insbesondere RCT-Zwischengruppenvergleiche) beruhen muss; Post-hoc-Analysen nur explorativ zu werten, vollständige Berücksichtigung der Kontrollgruppe sowie Einbezug von Konsistenz und klinischer Relevanz.

4.3.3 Auswahl und Begründung des Versorgungspfades (neues Kapitel):
Klarstellung, dass der Versorgungspfad das Studiendesign bestimmt, inkl. klarer Abgrenzung von alleiniger Therapie, Überbrückung und Add-on-Szenarien, vollständiger Dokumentation der Begleittherapien und ggf. Subgruppenanalysen bei heterogener Standardversorgung.

4.3.4 Anforderungen an Randomisierungsverfahren (neues Kapitel):
Konkretisierung der Anforderungen an eine valide, nicht manipulierbare Randomisierung inkl. Präspezifikation im Protokoll, dokumentierter Stratifizierung, geeigneter IT-Systeme, auditierbarer Verfahren, Zugriffsbeschränkungen und Maßnahmen zur Vermeidung von Vorhersehbarkeit (z. B. variable Blocklängen).

4.3.5 Studiendesign und methodische Planung (neues Kapitel):
Konkretisierung robuster Studiendesigns (u. a. RCT-Anforderungen), konservative Imputation fehlender Werte (z. B. J2R), präzise ITT-Definition sowie Pflicht zur vollständigen Dokumentation und Berichterstattung aller Abweichungen vom Studienprotokoll

4.3.6 Antragsunterlagen (neues Kapitel):
Klarstellung der einzureichenden Versionen (vor/nach Studienstart), verpflichtende Änderungsnachweise (Track Changes & Übersichtstabelle) sowie formale Anforderungen an Vollständigkeit und Dateiformat.

4.3.7 Inhaltliche und qualitative Anforderungen an Studienberichte (neues Kapitel):
Konkretisierung der Ergebnisdarstellung (Originalskalen, KI, p-Werte, Effektschätzer); verpflichtende Einordnung der klinischen Relevanz; detaillierte Drop-out-Analyse; klare Trennung der Analysepopulationen; hohe Anforderungen an Transparenz, Tabellen, Grafiken und Konsistenz der Berichterstattung

4.6.2 DiGA mit diagnostischer Komponente:
Konkretisierungen, was eine DiGA mit diagnostischer Komponente sein darf; neue FAQs

4.5.1 Begründung der Versorgungsverbesserung und systematische Datenauswertung:
Kleinere Ergänzungen zur Studien-Fallzahlplanung und statistischer Signifikanz

5 Ablauf des Verfahrens:
Ergänzung, dass Bescheide über Antragsportal übermittelt werden

5.1 Fristen für Antragsteller und BfArM:
Konkretisierungen zu Mängelschreiben und Fristen

5.2 Lebenszyklus einer DiGA im Verzeichnis:
Listung im Portal 5 Tage nach positivem Bescheid

5.2.2 Pflichten des Herstellers nach Aufnahme einer DiGA in das DiGA-Verzeichnis:
Pflicht zur vorzeitigen Anzeige von PZN-Änderungen

5.2.3 Verordnung einer DiGA:
Pflicht zur vorzeitigen Anzeige von PZN-Änderungen

5.2.5 Löschen einer DiGA aus dem DiGA-Verzeichnis:
Ergänzung der Mitteilungspflicht an Nutzer und Datenlöschung

5.4 Beratung durch das BfArM:
Empfehlung für frühzeitige Beratung bei Risikoklasse IIb-DiGA und DiGA mit Telemonitoring

6. Anwendungsbegleitende Erfolgsmessung (AbEM) (neues Kapitel):
Umfangreiches neues Kapitel zur AbEM aus dem Referentenentwurf der 2. DiGAV-ÄndV; detaillierte Definition der Datenpunkte, Berichtszeiträume und Fristen; Erklärung der geplanten Ausbaustufen der AbEM

Weitere kleinere Änderungen

Minimale Änderungen sind außerdem in den folgenden Kapiteln passiert: 2.3.4, 3.5.4, 4.3.8, 4.4.2, 5.2.4, 5.5

Diese sind größtenteils redaktionelle Optimierungen oder minimale Ergänzungen. Wir haben diese daher in der obigen Auflistung der Übersichtlichkeit halber weggelassen.

Abonnieren Sie unseren Newsletter, um über zukünftige Änderungen des DiGA-Leitfadens stets informiert zu bleiben.

2. Änderungen zwischen der Version 3.5 & Version 3.4 des DiGA-Leitfadens

Legende: Farbliche Veranschaulichung der Änderungen

In den Screenshots, die der jeweiligen Version des DiGA-Leitfadens entnommen sind, sind alle Änderungen farblich hinterlegt. Für die Markierung der Änderungsart werden die folgenden Farben verwendet.

Farbe	Art der Änderung
	Ergänzungen
	Streichungen

Änderungen im Kapitel 2.2.1.3 „Informationen für Leistungserbringende“

Der vorletzte Punkt in der Auflistung „Zur Verordnung relevante Informationen“ wurde um den Zusatz „und festgelegter Höchstbetrag“ ergänzt.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

Änderungen im Kapitel 3.4.2 „Sicherheit als Prozess“

Im FAQ-Bereich wurde die Anforderung, Penetrationstests als Teil des Sicherheitsprozesses durchzuführen, verschärft.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

Ergänzung eines neuen Kapitels 3.5.4.4 „Schreiben der DiGA in die ePA/Implementierung der GesundheitsID“:

Die neue Anforderung für alle Hersteller, nämlich das Schreiben der DiGA in die ePA sowie die Implementierung der GesundheitsID, wird erläutert. Die Umsetzungsfrist hierfür endet am 30.04.2024.

Neue Version 3.5:

Alte Version 3.4:

keine Entsprechung in alter Version, da neues Kapitel

Änderungen im Kapitel 4.2.2 „Angabe des positiven Versorgungseffektes“:

Mit einem neuen Hinweis wird die Anforderung des BfArM bezüglich des Nachweises mehrerer positiver Versorgungseffekte präzisiert. Demnach ist es für DiGA-Hersteller erforderlich, zunächst mindestens einen positiven Versorgungseffekt nachzuweisen, zu dem sie im Rahmen der vorläufigen Aufnahme durch einen BfArM-Bescheid verpflichtet wurden, bevor weitere positive Versorgungseffekte berücksichtigt werden können.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

Änderungen im Kapitel 4.3 „Verwendung von DiGA-Daten“:

Die Möglichkeit, eine Analyse eigener, bereits verordneter DiGA während des Erprobungszeitraums für die Einreichung von Nachweisen zur endgültigen Aufnahme zu verwenden, wurde konkretisiert. Es ist gestattet, eine Analyse eigener, nah an der Versorgung durchgeführter Daten aus dem Erprobungszeitraum als Unterstützung für die Nachweisführung zur dauerhaften Aufnahme zu nutzen. Dabei ist wichtig sicherzustellen, dass das Vorgehen im Voraus festgelegt wurde und ausführlich in einem separaten Studienbericht beschrieben ist.

Neue Version 3.5:

Alte Version 3.4:

Änderungen im Kapitel 4.3.3 „Übertragbarkeit von Studienergebnissen“:

Im Abschnitt „Durchführung der Studie in Deutschland“ hat das BfArM drei Kriterien festgelegt, um die Übertragbarkeit der Studienergebnisse auf den Versorgungskontext in Deutschland zu belegen.

Neue Version 3.5:

Alte Version 3.4

Änderungen im Kapitel 5.2.2 „Änderung der DiGA-Bezeichnung“:

Hier wird darauf hingewiesen, dass eine Änderung der Bezeichnung einer DiGA eine wesentliche Veränderung darstellt und beim BfArM anzuzeigen ist.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

Änderungen im Kapitel 5.2.3 „Kurzbezeichnung und PZN“:

Ein neuer Hinweis im Unterbereich „Pharmazentralnummer“ wurde hinzugefügt: Bei der Änderung der Kurzbezeichnung einer DiGA wird eine neue Pharmazentralnummer (PZN) vergeben.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

Änderungen im Kapitel 5.2.4 „Verweis auf Übergangsfristen“

Die neuen Fristen für den Übergang sind im Abschnitt 3.5.4.4 verzeichnet.

Neue Version 3.5:

Alte Version 3.4:

reine Ergänzung neuer Informationen – keine Entsprechung in alter Version

3. Zukünftige Änderungen des DiGA-Leitfadens

Wir bringen diesen Artikel mit jeder Aktualisierung des DiGA-Leitfadens auf den neuesten Stand.

Abonnieren Sie unseren Newsletter, um über zukünftige Änderungen des DiGA-Leitfadens stets informiert zu bleiben.

The post DiGA Leitfaden: Historie aller Änderungen appeared first on QuickBird Medical.

Diese Verordnung regelt Produkte, die Proben außerhalb des Körpers untersuchen, zum Beispiel Blut-, Urin- oder Gewebeproben. Der Begriff „in vitro“ bedeutet wörtlich „im Glas“ und beschreibt genau diese Untersuchungen außerhalb des menschlichen Körpers.

Dieser Artikel richtet sich an (angehende) Hersteller von IVD-Produkten, welche entweder komplett oder teilweise aus Software bestehen. Wir erklären Ihnen, wann Software unter die In Vitro Diagnostic Regulation (IVDR) fällt, wie die Qualifizierung funktioniert und nach welchen Kriterien die Risikoklassifizierung erfolgt.

Aus unserer praktischen Erfahrung in Kundenprojekten zur Umsetzung von IVDR-Software (und sogar mobilen IVD-Apps) können wir sagen: Die Einordnung ist nicht immer ganz einfach. Wir brechen das Thema für Sie daher herunter und teilen es in praxisnahe Unteraspekte auf. So erhalten Sie eine klare Grundlage, um die Qualifizierung und Klassifizierung Ihres Produkts vorzunehmen.

Inhaltsverzeichnis

• 1. Qualifizierung: Fällt Ihre Software unter die IVDR?
  • 1.1 Aspekt 1: Definition eines IVD nach IVDR
  • 1.2 Aspekt 2: Definition eines Medizinprodukts nach MDR
  • 1.3 Aspekt 3: Embedded, Zubehör oder Standalone-Software?
  • 1.4 Aspekte der Qualifizierung
  • 1.5 Schritt-Für-Schritt-Anleitung zur Qualifizierung
  • 1.6 Qualifizierung: Beispiele für IVDR und Nicht-IVDR
• 2. Klassifizierung: Unter welche Risikoklasse fällt Ihre Software?
  • 2.1 Welche Risikoklassen gibt es unter IVDR?
  • 2.2 Die wichtigsten Implikationen der Risikoklassen der IVDR
  • 2.3 Einordnung in die richtige Klasse: Regeln der IVDR
  • 2.4 MDCG-Guidance zur Klassifizierung nach IVDR
  • 2.5 Klassifizierung: Software-Beispiele für alle Klassen der IVDR
• 3. Wer trifft die finale Entscheidung zur Qualifizierung & Klassifizierung?
• 4. Gemeinsamkeiten und Unterschiede: MDR vs. IVDR
• 5. Fazit

1. Qualifizierung: Fällt Ihre Software unter die IVDR?

Die Qualifizierung dient dazu, herauszufinden, ob Ihre Software überhaupt als In-vitro-Diagnostikum gilt und damit unter die IVDR fällt. Die Basis hierfür stellt die Zweckbestimmung (mehr dazu hier) Ihres Produkts dar.

Für die Qualifizierung sollten Sie folgende 3 Aspekte für Ihr Produkt prüfen.

1.1 Aspekt 1: Definition eines IVD nach IVDR

Zusammengefasst fällt Ihre Software in den regulierten Bereich der IVDR, wenn diese in die Definition eines „In-vitro-Diagnostikum“ nach IVDR Artikel 2(2) fällt. Der Wortlaut dieser Definition ist der Folgende:

„In-vitro-Diagnostikum“ bezeichnet ein Medizinprodukt, das als Reagenz, Reagenzprodukt, Kalibrator, Kontrollmaterial, Kit, Instrument, Apparat, Gerät, Software oder System — einzeln oder in Verbindung miteinander — vom Hersteller zur In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben, einschließlich Blut- und Gewebespenden, bestimmt ist und ausschließlich oder hauptsächlich dazu dient, Informationen zu einem oder mehreren der folgenden Punkte zu liefern

a) über physiologische oder pathologische Prozesse oder Zustände,
b) über kongenitale körperliche oder geistige Beeinträchtigungen,
c) über die Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit,
d) zur Feststellung der Unbedenklichkeit und Verträglichkeit bei den potenziellen Empfängern,
e) über die voraussichtliche Wirkung einer Behandlung oder die voraussichtlichen Reaktionen darauf oder
f) zur Festlegung oder Überwachung therapeutischer Maßnahmen.

Prüfen Sie daher genau, ob Sie die Zweckbestimmung Ihres Produkts in dieser Definition wiederfinden.

1.2 Aspekt 2: Definition eines Medizinprodukts nach MDR

Im ersten Satz der obigen Definition sieht man, dass ein IVD auch ein „Medizinprodukt“ sein muss:

„In-vitro-Diagnostikum“ bezeichnet ein Medizinprodukt, das als Reagenz […]

Die IVDR verweist für die Definition eines Medizinprodukts auf die Medical Device Regulation (MDR). Daher müssen Sie zusätzlich zur obigen Definition auch die Definition eines Medizinprodukts mit der Zweckbestimmung Ihres Produkts abgleichen.

Wie genau die Definition eines Medizinprodukts nach MDR aussieht und wie Sie entscheiden, ob Sie mit Ihrem Produkt in diese Definition fallen, erfahren Sie in unserem Leitfaden: Ist Ihre Software ein Medizinprodukt?

Wichtig: Obwohl Sie unter die Definition eines Medizinprodukts nach MDR fallen, müssen Sie für ein In-Vitro-Diagnostikum nur die IVDR einhalten. Es gilt nicht gleichzeitig die MDR und die IVDR für Ihr Produkt.

1.3 Aspekt 3: Embedded, Zubehör oder Standalone-Software?

Neben der Beschäftigung mit der IVD-Definition, ist es aber vor allem auch wichtig, zu verstehen, wie die „regulatorische Architektur“ Ihres Gesamtprodukts aussieht:

• Wird die Software als Teil Ihres Hardware-Geräts mit-zertifiziert?
• Ist die Software gesondert zu behandeln und wird demnach als eigenes IVD-Produkt zertifiziert?
• Ist die Software ein Zubehör zu dem eigentlichen IVD-Produkt (z. B. Hardware)?

Die Antworten auf diese Fragen beeinflussen stark den Zulassungsprozess Ihres Produkts und sollten daher bereits zu Beginn der Entwicklung gefunden werden.

Hierfür müssen Sie entscheiden, in welche der folgenden drei Kategorien Ihre Software-Komponente fällt:

1.4 Zusammenfassung: Aspekte der Qualifizierung

Für Sie gilt es also herauszufinden:

1. Ist Ihre Software Teil eines Geräts, Zubehör oder Standalone-Software?
2. Fällt Ihre Software unter die Definition eines Medizinprodukts nach MDR?
3. Fällt Ihre Software unter die Definition eines In-Vitro-Diagnostikums nach IVDR?

Sie sollten diese Themen zu Beginn Ihres Vorhabens durchlaufen, um die Anwendbarkeit der IVDR für Ihr Produkt zu prüfen.

1.5 Schritt-für-Schritt-Anleitung zur Qualifizierung

Die Antwort auf die oben genannten Kernfragen ist nicht immer ganz eindeutig. Daher gibt es zusätzliche Guidance-Dokumente zur IVDR (und MDR), die einen offiziellen Charakter haben.

Bezüglich der Qualifizierung von Software in Bezug auf die IVDR sollten Sie konkret einen Blick auf die „MDCG 2019-11“ werfen. Diese versucht u.a., den Entscheidungsprozess im Rahmen der IVDR von Software für Sie zu vereinfachen bzw. zu konkretisieren: Link zur MDCG Guidance

Guidance-Dokumente der MDCG sind zwar genau genommen nicht rechtlich bindend, werden aber in der Praxis auch meist von benannten Stellen herangezogen, um derartige Entscheidungen im Rahmen der Zertifizierung zu treffen.

Wir haben den Entscheidungsbaum der MDCG 2019-11 auf Deutsch übersetzt und die Formulierungen zur besseren Verständlichkeit etwas vereinfacht:

Entscheidungsbaum zur Qualifizierung: Fällt Ihre Software unter die IVDR?

Schritt 1: Ist Ihre Software ein Medizinprodukt nach MDR?

Fallen Sie mit der Zweckbestimmung Ihrer Software in die Definition eines Medizinprodukts nach MDR? Hierfür lohnt sich ein Blick auf unseren Leitfaden zu genau diesem Thema: Leitfaden: Ist Ihre Software ein Medizinprodukt?

Schritt 2:
 Stellt Ihre Software Informationen bereit, die in den Anwendungsbereich der Definition eines In-vitro-Diagnostikums fallen?

Konkret formuliert: Stellt Ihre Software Informationen zu einem der folgenden Zwecke zur Verfügung? (siehe Definition eines IVD in der IVDR):

a) über physiologische oder pathologische Prozesse oder Zustände,
b) über kongenitale körperliche oder geistige Beeinträchtigungen,
c) über die Prädisposition für einen bestimmten gesundheitlichen Zustand oder eine bestimmte Krankheit,
d) zur Feststellung der Unbedenklichkeit und Verträglichkeit bei den potenziellen Empfängern,
e) über die voraussichtliche Wirkung einer Behandlung oder die voraussichtlichen Reaktionen darauf oder
f) zur Festlegung oder Überwachung therapeutischer Maßnahmen.

Schritt 3: Erzeugt Ihre Software Informationen ausschließlich auf Grundlage von Daten, die von In-vitro-Diagnostika gewonnen wurden?

Sind Sie sicher, dass die Daten nicht auch aus anderen Quellen wie z. B. einem Medizinprodukt (kein IVD) stammen? Nur dann können Sie diese Frage mit „Ja“ beantworten.

Schritt 4: Wird die Zweckbestimmung im Wesentlichen durch Datenquellen bestimmt, die von In-vitro-Diagnostika stammen?

Wenn es auch Informationen gibt, die nicht von einem IVD-Produkt stammen: Wird die Zweckbestimmung dann trotzdem im Wesentlichen durch IVD-Informationen bestimmt? Wie stark beeinflussen die „Nicht-IVD-Informationen“ denn die Zweckbestimmung?

Ergebnis: Sind Sie im Entscheidungspfad unten beim „Ergebnis IVDR“ angelangt?

Dann ist Ihre Software höchstwahrscheinlich ein IVD oder Teil eines IVDs, das unter die IVDR fällt. Leider hat natürlich jede Frage und jede Definition Platz für verschiedene Auslegungen. Insofern sollten Sie diese Entscheidung nicht voreilig treffen und sich im Zweifel professionelle Beratung zu diesem Thema einholen.

Hinweis: Unsere Grafik dient nur der Veranschaulichung. Für die finale Qualifizierung des Produkts empfehlen wir Ihnen, mit der englischen Version der MDCG-Guidance im Original-Wortlaut zu arbeiten. Sie können uns auch gerne kontaktieren, falls Sie Input für die Qualifizierung oder Klassifizierung Ihres Produkts benötigen. Wir entwickeln IVDR- und MDR-Software auf Auftragsbasis und geben gerne praktische Insights weiter.

1.6 Qualifizierung: Beispiele für IVDR und Nicht-IVDR

Um das Thema etwas greifbarer zu machen, finden Sie hier einige Beispiele für Software-Produkte, die laut MDCG-Guidances tendenziell …

1. … ein IVD nach IVDR sind.
2. … kein IVD sind, aber ein Medizinprodukt nach MDR sind.
3. … weder IVD noch Medizinprodukt sind.

Qualifizierungsbeispiel: IVD nach IVDR

Ein deutliches Beispiel für ein IVD ist Software, die Rohdaten aus Labortests automatisch auswertet. Zum Beispiel:

• Software, welche die optische Dichte eines ELISA-Lesegeräts analysiert. Bei einem ELISA entsteht durch eine chemische Reaktion in der Probe ein Farbwechsel. Das Gerät schickt Licht durch die Probe und misst, wie viel Licht absorbiert wird. Aus dieser Farbintensität kann abgeleitet werden, wie viel von einem bestimmten Stoff im Blut vorhanden ist.
• Software, die Muster eines sogenannten Blots interpretieren. Ein Blot ist ein Labortest, bei dem Proteine auf eine Membran übertragen werden und dort sichtbare Linien oder Punkte bilden. Diese Muster zeigen an, ob bestimmte Antikörper oder Eiweiße vorhanden sind.

Solche Software nimmt die Messdaten auf und berechnet daraus mithilfe von medizinischen Algorithmen einen diagnostischen oder prognostischen Befund. Deshalb gilt sie in der Regel als IVD-Software.

Ein weiteres spannendes Beispiel, das wir bei QuickBird Medical gut kennen, ist die App „Accu-Chek SugarView“ von Roche. Die Accu-Chek SugarView App bestimmt den Blutzuckerbereich, indem sie den Accu-Chek Active Teststreifen und zwei Fotos, die mit der Smartphone-Kamera vom Teststreifen aufgenommen werden, auswertet. Die intelligente Software funktioniert ohne jegliches zusätzliches Glukosemessgerät. Sie wurde als IVD-Software klassifiziert und hat die CE-Kennzeichnung erhalten (mehr dazu finden Sie hier)

Qualifizierungsbeispiel: Kein IVD, sondern Medizinprodukt nach MDR

Es gibt auch Software, die zwar einen medizinischen Zweck erfüllt, aber keine Laborproben auswertet. Solche Anwendungen fallen nicht unter die IVDR, sondern unter die MDR. Dazu gehören insbesondere Programme, die:

• medizinische Bilder verarbeiten oder analysieren, zum Beispiel in der Radiologie oder Dermatologie
• Messwerte eines medizinischen Geräts bewerten, solange diese Werte nicht aus In-Vitro-Tests stammen

Wenn die Software keine Blut-, Urin- oder Gewebeproben untersucht, aber trotzdem medizinische Entscheidungen unterstützt, handelt es sich dann eben womöglich um ein Medizinprodukt nach MDR und nicht um ein IVD.

Qualifizierungsbeispiel: Kein IVD und kein MDR-Medizinprodukt

Viele Softwareprodukte erfüllen weder die Definition eines IVD nach IVDR noch die eines Medizinprodukts nach MDR. Darunter fallen zum Beispiel:

• Laborinformationssysteme (LIS), die nur Daten verwalten oder Laborprozesse organisieren
• Programme, die Ergebnisse einfach darstellen, zum Beispiel in Form von Diagrammen oder einfachen Statistiken
• Software, die Messdaten lediglich speichert oder weiterleitet, ohne diese zu interpretieren oder zu analysieren

Solche Software trifft keine eigenen diagnostischen Aussagen und hat keinen direkten medizinischen Zweck. Deshalb fällt sie weder unter die IVDR noch unter die MDR.

2. Klassifizierung: Unter welche Risikoklasse fällt Ihre Software?

„Ja, ich will!“ – Können Sie diese Aussage mit Selbstbewusstsein in Bezug auf die IVD-Qualifizierung (siehe oben) machen? Fallen Sie also in den Anwendungsbereich der IVDR? (für viele Hersteller vermutlich kein „Ich will“, sondern eher ein „Ja, ich muss 😔“). Dann wird es nun Zeit, sich mit den Risikoklassen der IVDR zu beschäftigen.

Um die regulatorischen Anforderungen für Sie als Hersteller und Ihr Produkt zu bestimmen, müssen Sie erstmal wissen, in welche Risikoklasse Ihr Produkt bzw. die Komponenten Ihres Produkts fallen.

2.1 Welche Risikoklassen gibt es unter IVDR?

Die IVDR unterscheidet zwischen den folgenden Risikoklassen: A, B, C, D

Die Idee ist, dass man Produkten mit höherem Risiko (z.B. B, C oder D) auch strengere Anforderungen auferlegt als Produkten mit sehr geringem Risiko (Klasse A).

Hinweis: Damit unterscheidet sich die Risikoklassifizierung unter IVDR von Medizinprodukten, die unter die Medical Device Regulation (MDR) fallen. Die MDR unterteilt Medizinprodukte in die Risikoklassen I, IIa, IIb und III. Mehr dazu in unserem MDR-Leitfaden.

Recherche in der EUDAMED-Datenbank: Anzahl der IVDR-Produkte & IVDR-Software-Produkte pro Risikoklasse
(Beschreibung der Risiken jeweils nach IMDRF-Guidance)

In der Abbildung finden Sie das Ergebnis unserer Recherchen zur Risikoklassen-Verteilung von IVDR-Produkten innerhalb der EUDAMED-Datenbank. Vorsicht: Die Statistik hat keinerlei Aussagekraft in Bezug auf Ihr Produkt. Die Tatsache, dass die meisten Produkte in Klasse A eingeordnet sind, hat viele Gründe. Sie müssen trotzdem strukturiert evaluieren, in welche Risikoklasse Ihre Software fällt (und tatsächlich ist es gerade bei diagnostischer Software vermutlich nicht die Klasse A oder B).

2.2 Die wichtigsten Implikationen der Risikoklassen der IVDR

Die Risikoklasse eines IVD-Software-Produkts wirkt sich in vielerlei Hinsicht auf Entwicklung, Zulassungsprozess und Post-Market-Aktivitäten aus. Hier fassen wir die zentralen Aspekte für Sie zusammen.

Deckungsgleiche Anforderungen an das Qualitätsmanagement & technische Dokumentation

Je nach Risikoklasse, werden unterschiedlich strenge Anforderungen im Rahmen der IVDR gestellt. Dies betrifft aber tatsächlich nicht die sogenannten Grundlegenden Sicherheits- und Leistungsanforderungen an das IVD-Produkt. Die grundlegenden Anforderungen an das Qualitätsmanagementsystem des Herstellers und die technische Dokumentation des Produkts sind bei allen Risikoklassen (A, B, C und D) identisch (bei den höheren Risikoklassen C & D greifen aber vereinzelt Zusatzanforderungen).

Hierbei sind besonders relevant:

• Qualitätsmanagement nach ISO 13485 → Unser Leitfaden zur ISO 13485, speziell für Software-Produkte
• Software-Lebenszyklus nach IEC 62304 → Unser Leitfaden zur IEC 62304
• Risikomanagement nach ISO 14971
• Gebrauchstauglichkeit nach IEC 62366-1

Benannte Stelle ab Risikoklasse B

Der wohl größte Unterschied ist, dass Hersteller von Produkten der Klasse B, C oder D (im Gegensatz zu den meisten Produkten der Klasse A) durch einen Zertifizierungsprozess mit einer benannten Stelle gehen müssen, bevor die Produkte auf den Markt gelangen können. Eine akkreditierte Stelle muss also u.a. die technische Dokumentation und das Qualitätsmanagementsystem prüfen und freigeben.

Das ist übrigens sehr ähnlich zur Regelung unter Medical Device Regulation (MDR), wo Klasse I-Produkte quasi vom Hersteller selbst zertifiziert werden und ohne externe Prüfung auf den Markt gehen können (im Gegensatz zu Klasse IIa, IIb und III unter MDR).

Unterschiede zwischen Klasse B, C und D

Der Unterschied zwischen Risikoklasse A und B ist somit klar (die Prüfung der benannten Stelle). Gibt es ab Risikoklasse B dann jedoch keine weiteren Anforderungen mit steigender Risikoklasse (C und D)? Wofür dann 4 Klassen und nicht nur eine?

Antwort: Doch, die gibt es. Vereinfacht gesprochen, bei Risikoklasse C und D:

• Es werden vereinzelt weitere Dokumentationsanforderungen gestellt (z. B. ein zusätzlicher Kurzbericht über Sicherheit und Leistung).
• Der Detailgrad der Prüfung durch die benannte Stelle steigt mit steigender Risikoklasse.
• Bei Risikoklasse D wird ein Referenzlabor der Europäischen Union in die Prüfungen und Zulassung einbezogen.

Eine gute Übersicht bekommen Sie auch, wenn Sie im offiziellen Gesetzestext nach dem Stichwort „Klasse“ suchen und einmal alle Erwähnungen überprüfen.

2.3 Einordnung in die richtige Klasse: Regeln der IVDR

Wichtig ist zuallererst, dass die gesamte Klassifizierung auf Basis der Zweckbestimmung Ihres Produkts stattfinden muss. Wie genau Sie die Zweckbestimmung für ein Medizinprodukt definieren, erklären wir in unserem gesonderten Leitfaden hier.

Die Klassifizierung von IVDR-Produkten wird durch eine überraschend übersichtliche, kurze Liste von 7 Regeln bestimmt (ANHANG VIII der IVDR). Statt diese hier redundant in einigen Worten wiederzugeben, empfehlen wir Ihnen stark, sich einfach selbst einmal den kurzen Abschnitt in der IVDR hierzu durchzulesen (siehe unten). Wir haben den genauen Wortlaut aus der Verordnung für Sie im nächsten Kapitel eingefügt. Das ist tatsächlich auch der einzige Abschnitt der IVDR, der sich mit der Einordnung in die Risikoklasse beschäftigt.

2.3.1 Auszug der EU-Verordnung: Klassifizierungsregeln nach Anhang VIII der IVDR

Die folgenden Klassifizierungsregeln finden Sie in der Verordnung über In-Vitro-Diagnostika (IVDR) in Anhang VIII:

2. KLASSIFIZIERUNGSREGELN

2.1. Regel 1
Produkte mit den folgenden Zweckbestimmungen werden der Klasse D zugeordnet:
— Nachweis des Vorhandenseins von oder der Exposition gegenüber übertragbaren Erregern in Blut, Blutbestandteilen, Zellen, Geweben oder Organen oder in einem ihrer Derivate, um ihre Eignung für die Transfusion, Transplantation oder Zellgabe zu bewerten;
— Nachweis des Vorhandenseins von oder der Exposition gegenüber übertragbaren Erregern, die eine lebensbedrohende Krankheit mit einem hohen oder mutmaßlich hohen Verbreitungsrisiko verursachen;
— Bestimmung der Infektionslast einer lebensbedrohenden Krankheit, dessen Überwachung im Rahmen des Patientenmanagements von entscheidender Bedeutung ist.

2.2. Regel 2
Produkte, die zur Blutgruppenbestimmung oder zur Feststellung einer feto-maternalen Blutgruppen-Inkompatibilität oder zur Gewebetypisierung verwendet werden, um die Immunkompatibilität von für die Transfusion, Transplantation oder Zellgabe bestimmtem Blut, Blutbestandteilen, Zellen, Geweben oder Organen festzustellen, werden der Klasse C zugeordnet, es sei denn, sie werden zur Bestimmung eines der folgenden Marker eingesetzt:
— ABNull-System [A (ABO1), B (ABO2), AB (ABO3)];
— Rhesus-System [RH1 (D), RHW1, RH2 (C), RH3 (E), RH4 (c), RH5 (e)];
— Kell-System [Kel1 (K)];
— Kidd-System [JK1 (Jka), JK2 (Jkb)];
— Duffy-System [FY1 (Fya), FY2 (Fyb)].
In diesem Fall werden sie der Klasse D zugeordnet.

2.3. Regel 3
Produkte werden der Klasse C zugeordnet, wenn sie folgende Zweckbestimmung haben:
a) Nachweis des Vorhandenseins von oder Exposition gegenüber einem sexuell übertragbaren Erreger;
b) Nachweis eines Infektionserregers ohne hohes oder mutmaßlich hohes Verbreitungsrisiko im Liquor oder im Blut;
c) Nachweis eines Infektionserregers, wenn ein signifikantes Risiko besteht, dass ein fehlerhaftes Ergebnis den Tod oder eine ernste gesundheitliche Schädigung der getesteten Person, des getesteten Fötus oder Embryos oder der Nachkommen der getesteten Person verursacht;
d) Feststellung des Immunstatus von Frauen gegenüber übertragbaren Erregern zum Zwecke des pränatalen Screenings;
e) Feststellung des Vorliegens einer Infektionskrankheit oder des Immunstatus, wenn das Risiko besteht, dass ein fehlerhaftes Ergebnis zu einer Patientenmanagemententscheidung führen würde, die eine lebensbedrohende Situation für den Patienten oder die Nachkommen des Patienten schafft;
f) Einsatz als therapiebegleitende Diagnostika;
g) Einsatz zur Stadieneinteilung einer Krankheit, wenn das Risiko besteht, dass ein fehlerhaftes Ergebnis zu einer Patientenmanagemententscheidung führen würde, die eine lebensbedrohende Situation für den Patienten oder die Nachkommen des Patienten schafft;
h) Einsatz zur Krebsvorsorge, -diagnose oder -stadieneinteilung;
i) Durchführung von Gentests beim Menschen;
j) Überwachung des Niveaus von Arzneimitteln, Stoffen oder biologischen Komponenten, wenn das Risiko besteht, dass ein fehlerhaftes Ergebnis zu einer Patientenmanagemententscheidung führen würde, die eine lebensbedrohende Situation für den Patienten oder die Nachkommen des Patienten schafft;
k) Management von Patienten, die an einer lebensbedrohenden Krankheit leiden oder deren Zustand lebensbedrohend ist;
l) Untersuchung auf genetisch bedingte Störungen beim Embryo oder Fötus;
m) Untersuchung auf genetisch bedingte Störungen bei Neugeborenen, wenn der fehlende Nachweis und die fehlende Behandlung dieser Störungen zu lebensbedrohenden Situationen oder ernsten gesundheitlichen Schädigungen führen können.

2.4. Regel 4
a) Produkte zur Eigenanwendung werden der Klasse C zugeordnet, ausgenommen Produkte zur Feststellung einer Schwangerschaft, zur Fertilitätsuntersuchung und zur Bestimmung des Cholesterinspiegels und Produkte zum Nachweis von Glukose, Erythrozyten, Leukozyten und Bakterien im Urin, die der Klasse B zugeordnet werden.
b) Produkte zur Verwendung in patientennahen Tests werden für sich allein klassifiziert.

2.5. Regel 5
Die folgenden Produkte werden der Klasse A zugeordnet:
a) Erzeugnisse für den allgemeinen Laborbedarf, Zubehör ohne kritische Merkmale, Pufferlösungen, Waschlösungen sowie allgemeine Nährmedien und histologische Färbungen, die vom Hersteller dafür vorgesehen sind, die Produkte für In-vitro-Diagnoseverfahren im Zusammenhang mit einer spezifischen Untersuchung einsetzbar zu machen;
b) Instrumente, die vom Hersteller speziell für die Verwendung bei In-vitro-Diagnoseverfahren vorgesehen sind;
c) Probenbehältnisse.

2.6. Regel 6
Produkte, die nicht unter die zuvor beschriebenen Klassifizierungsregeln fallen, werden der Klasse B zugeordnet.

2.7. Regel 7
Produkte, bei denen es sich um Kontrollen ohne einen zugewiesenen quantitativen oder qualitativen Wert handelt, werden der Klasse B zugeordnet.

2.3.2 Auszug der EU-Verordnung: Durchführungsvorschriften für die Klassifizierung

Neben den Klassifizierungsregeln finden Sie in der IVDR noch einige Durchführungsvorschriften, welche die Klassifizierung betreffen. Untenstehend finden Sie den Auszug aus der IVDR im Anhang VIII.

1. DURCHFÜHRUNGSVORSCHRIFTEN

1.1. Die Anwendung der Klassifizierungsregeln richtet sich nach der Zweckbestimmung der Produkte.

1.2. Wenn das betreffende Produkt dazu bestimmt ist, in Verbindung mit einem anderen Produkt angewandt zu werden, werden die Klassifizierungsregeln auf jedes Produkt gesondert angewendet.

1.3. Zubehör für ein In-vitro-Diagnostikum wird unabhängig von dem Produkt, mit dem es verwendet wird, gesondert klassifiziert.

1.4. Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt. Ist die Software von anderen Produkten unabhängig, so wird sie für sich allein klassifiziert.

1.5. Kalibratoren zur Verwendung mit einem Produkt werden derselben Klasse zugerechnet wie das Produkt.

1.6. Kontrollmaterialien mit quantitativen oder qualitativen zugeordneten Werten, die für einen spezifischen oder mehrere Analyten bestimmt sind, werden derselben Klasse zugerechnet wie das Produkt.

1.7. Der Hersteller berücksichtigt alle Klassifizierungs- und Durchführungsregeln, um die angemessene Einstufung des Produkts festzustellen.

1.8. Wenn der Hersteller für ein Produkt mehrere Zweckbestimmungen angibt und das Produkt daher mehr als einer Klasse zuzuordnen ist, wird es in die höchste der Klassen eingestuft.

1.9. Für den Fall, dass für dasselbe Produkt mehrere Klassifizierungsregeln gelten, wird die Regel der Einstufung in die höchste dieser Klassen angewendet.

1.10. Jede Klassifizierungsregel gilt für erstmalige Tests, Bestätigungstests und Ergänzungstests.

2.4 MDCG-Guidance zur Klassifizierung nach IVDR

Nicht jeder Satz der oben gezeigten Klassifizierungsregeln der IVDR ist selbsterklärend und eindeutig. Daher gibt es zusätzliche Leitfäden der MDCG, die Ihnen u.a. bei der Bestimmung der Risikoklasse helfen sollen.

Für die Klassifizierung von Software-Produkten gibt es zwei relevante MDCG-Guidance-Dokumente:

1. Allgemeine Guidance – „MDCG 2020-16: Guidance on Classification Rules for in vitro Diagnostic Medical Devices under
   Regulation (EU) 2017/746“: Dieses Dokument liefert zu jeder Klassifizierungsregel der IVDR hilfreiche Beispiele und Anmerkungen. So erhalten Sie zusätzliche Unterstützung bei der Evaluation, ob bestimmte Klassifizierungsregeln auf Ihr Produkt anwendbar sind. –> Link
2. Software-spezifisch für MDR und IVDR – „MDCG 2019-11: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 IVDR“: Das Dokument geht u.a. auf die Besonderheiten der Qualifizierung und Klassifizierung von Software ein. Im Gegensatz zur MDCG 2020-16 ist der Umfang der relevanten Abschnitte verhältnismäßig knapp. –> Link

Hinweis: Die Formulierung „Regulation (EU) 2017/746“ steht für die IVDR. „Regulation (EU) 2017/745“ steht hingegen für die MDR.

2.5 Klassifizierung: Software-Beispiele für alle Klassen der IVDR

Auch für die Klassifizierung möchten wir Ihnen einige Software-Beispiele aus der MDCG-Guidance an die Hand geben, um die Thematik zu verdeutlichen. Natürlich sind dies nur Veranschaulichungen und der Teufel steckt manchmal im Detail. Insofern sollten Sie die Klassifizierung Ihres Produkts nicht rein auf dem Vergleich mit existierenden Beispielen vornehmen, sondern alle Regeln der IVDR einzeln prüfen.

Software-Beispiel für Risikoklasse A

Eine Software gehört vor allem zur Risikoklasse A, wenn sie ausschließlich dazu gedacht ist, ein IVD-Gerät (nach IVDR) zu steuern, welches ebenfalls in Klasse A eingestuft ist. Das ergibt sich aus Anhang VIII 1.4 der IVDR: „Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird derselben Klasse zugerechnet wie das Produkt.“

Ein konkretes Beispiel ist eine Software, die einen CRP-Analyser (C-reaktives-Protein-Gerät), der unter die Klasse A fällt, aus der Ferne bedient. Die Software trifft keine eigenen diagnostischen Aussagen, sondern sorgt nur dafür, dass das Gerät funktioniert. Deshalb wird sie in dieselbe Klasse wie das Gerät eingestuft, hier also Klasse A.

Software-Beispiel für Risikoklasse B

Etwas schwierig ist es, offizielle Beispiele für Software der Klasse B zu finden. (Software-)Produkte landen nur in Klasse B, falls sie in spezielle Produktkategorien zur Eigenanwendung (z.B. Schwangerschaftstests) fallen (Regel 4) oder sonst keine der anderen Klassifizierungsregeln greift (Regel 6).

In der Guidance „MDCG 2020-16¡ findet sich folgendes Beispiel:

„Blood gas analyser and the software driving and influencing it are classified as […] Class B (Rule 6) where the blood gas analyser directly measures a parameter from a specimen (in the absence of a reagent or disposable sensor cassette) AND where an erroneous result in a measured parameter WILL NOT LEAD TO a patient management decision resulting in a lifethreatening situation.“

Software-Beispiel für Risikoklasse C

Software, die in einem automatisierten ELISA-System HbA1c-Werte berechnet und zur Diabetes-Diagnose oder Verlaufskontrolle verwendet wird, fällt unter die Klasse C. Das lässt sich aus Regel 3(k) der IVDR ableiten.

Software, die in einem automatisierten PAP-Screening-System Abstriche als auffällig oder unauffällig klassifiziert, fällt auch unter Klasse C. Das lässt sich aus Regel 3(h) der IVDR ableiten.

Software-Beispiel für Risikoklasse D

Software, die die Ergebnisse eines automatisierten Line-Immunoassays für HIV-Antikörper interpretiert, fällt unter die Klasse D. Das lässt sich aus Regel 1 der IVDR ableiten. In diesem Fall bewertet die Software hochkritische Infektionsmarker.

3. Wer trifft die finale Entscheidung zur Qualifizierung & Klassifizierung?

Sie als Hersteller des Produkts müssen diese Entscheidung treffen. Die Verantwortung dafür, die Anwendbarkeit der IVDR auf Ihr (Software-)Produkt zu prüfen (Qualifizierung) sowie die Einstufung in die passende Risikoklasse, liegt initial komplett bei Ihnen.

Dabei ist eine sorgfältige Bewertung entscheidend, denn eine benannte Stelle kann die Zertifizierung ablehnen, wenn diese zu einer anderen Einschätzung bei der Risikoklassifizierung kommt. Außerdem sind Sie natürlich rechtlich angreifbar, falls Sie diese Einstufung nicht richtig vornehmen.

Gerade bei einer Einstufung in die Risikoklasse A sollten Sie vorsichtig sein, da die Klassifizierung hier initial nicht von einer benannten Stelle geprüft wird. Somit haben Sie noch weniger gefühlte Sicherheit bei der Auswahl der Risikoklasse.

Außerdem: Obwohl hier keine benannte Stelle eingebunden wird, kann die zuständige Aufsichtsbehörde eine fehlerhafte Klassifizierung bemerken und im schlimmsten Fall verlangen, dass das Produkt vom Markt genommen wird. Auch Produkte der Risikoklasse A werden in unregelmäßigen Abständen Prüfungen unterzogen. Des Weiteren wird im Falle eines Personenschadens durch Ihr Produkt sicherlich auch rechtlich hinterfragt, ob die von Ihnen als Hersteller zugewiesene Risikoklasse angemessen war.

Wenn Sie unsicher sind, lohnt es sich, eine unabhängige Einschätzung einzuholen. Mögliche Anlaufstellen sind:

• ein spezialisierter Rechtsanwalt, der ein Gutachten erstellen kann
• ein Regulatory-Expert oder Berater mit entsprechender Erfahrung
• das BfArM (in der Praxis aufgrund monatelanger Bearbeitungszeiten allerdings schwierig)

QuickBird Medical entwickelt IVDR- und MDR-Software für Kunden auf Auftragsbasis. Gerne geben wir Ihnen auf Basis unserer Erfahrung Input zur Klassifizierungs- und Qualifizierungsentscheidung. Bei Bedarf können wir Ihnen z. B. auch einen Anwalt aus unserem Kontaktkreis vermitteln, der für Sie ein Gutachten erstellen kann.
→ Kontakt aufnehmen

Wichtig: Weder eine externe Einschätzung noch ein formelles Gutachten bieten eine vollständige rechtliche Absicherung. Sie können im Falle eines Rechtsstreits jedoch als wichtige Entscheidungsgrundlage dienen.

4. Gemeinsamkeiten und Unterschiede: MDR vs. IVDR

Die MDR regelt klassische Medizinprodukte, die meist direkt am Patienten eingesetzt werden, während die IVDR In-vitro-Diagnostika betrifft, also Produkte, die z. B. Proben wie Blut oder Gewebe untersuchen.

Beide Verordnungen funktionieren in vielen Bereichen ähnlich: Hersteller brauchen ein Qualitätsmanagementsystem, eine technische Dokumentation, eine verantwortliche Person für die Regelkonformität und müssen ihre Produkte nach festen Risikoklassen einstufen.

Größere Unterschiede liegen u.a. in den folgenden Punkten:

1. Unterschiedliche Klassifizierungslogik: Die Risikoklassen und die Klassifizierungslogik der IVDR und MDR unterscheiden sich stark. Hier ist auch zu beachten, dass Software-Produkte unter IVDR deutlich seltener in die niedrigste Klasse (A) fallen, als dies bei MDR mit Klasse I der Fall ist. Somit ist bei den meisten IVD-Produkten mit Software eine benannte Stelle involviert.
2. Spezifischere Leistungsbewertung bei IVDs: IVD-Produkte müssen eine sehr umfangreiche Performance Evaluation durchlaufen. Diese umfasst unter anderem die wissenschaftliche Validität, analytische Performance (z. B. Sensitivität, Spezifität) und die klinische Performance. Auch unter MDR gibt es Medizinprodukte, die derartige Validierungsanforderungen einhalten müssen (z. B. ein Produkt zur Diagnose von Krankheiten auf Basis von CT-Bilddaten). Diese Anforderungen sind in der IVDR jedoch deutlich konkreter definiert als in der MDR.
3. Zusätzliche Prüfmechanismen bei Hochrisiko-IVDs: Produkte der IVDR-Klasse D (z. B. HIV- oder Hepatitis-Tests) müssen durch EU-Referenzlabore (EURLs) unabhängig überprüft werden.

5. Fazit

IVDR-Software bewegt sich im Spannungsfeld zwischen technischer Entwicklung, Laborrealität und strengen regulatorischen Anforderungen.

Dieser Artikel soll Ihnen helfen, die ersten zentralen Fragen zu beantworten: Fällt Ihre Software überhaupt unter die IVDR und in welche Risikoklasse gehört sie? Wenn diese Eckpfeiler stehen, haben Sie eine solide Basis, um Qualitätsmanagement, die weitere Dokumentation, Validierung und Zusammenarbeit mit einer benannten Stelle gezielt anzugehen.

Im Zuge der IVDR ist zu beachten, dass der Großteil aller Software-basierten Diagnose-Produkte nicht in Risikoklasse A fallen wird. Daher sollten Sie damit rechnen, dass Sie als Hersteller eine benannte in den Zulassungsprozess inkludieren müssen. Die Kosten und den zusätzlichen Zeitaufwand für diese Zertifizierung sollten Sie in Ihrer Produktplanung berücksichtigen.

Über uns: QuickBird Medical entwickelt IVDR- und MDR-Software für Kunden auf Auftragsbasis. Wir übernehmen sowohl die technische Umsetzung als auch die regulatorische Konformität Ihres (Software-)Produkts. Wenn Sie also ein IVDR- oder MDR-Produkt planen, welches Software-Komponenten enthält, kontaktieren Sie uns gern für ein unverbindliches Erstgespräch.
→ Kontakt aufnehmen

In Zukunft planen wir weitere Artikel, die Ihnen bei der Planung und Entwicklung von IVDR-Produkten bzw. speziell der Software-Komponente dieser helfen sollen. In unserem Newsletter informieren wir Sie über neue Artikel und Änderungen zu diesem Thema.

The post IVDR Software: Qualifizierung und Klassifizierung appeared first on QuickBird Medical.

Mit dem Digitale‑Versorgung‑und‑Pflege‑Modernisierungs‑Gesetz (DVPMG)  wurde im Juni 2021 auch ein Pendant dazu für die Pflege geschaffen: digitale Pflegeanwendungen (DiPA).

DiPA sollen den Alltag pflegebedürftiger Menschen und deren Umfeld durch Web- und Smartphone-Apps unterstützen. Beispielsweise könnte eine digitale Pflegeanwendung dazu beitragen, das Sturzrisiko von Pflegebedürftigen zu minimieren, oder die Kommunikation zwischen Angehörigen und Pflegekräften zu verbessern.

Die Verordnung zur Prüfung der Erstattungsfähigkeit digitaler Pflegeanwendungen (DiPAV) gibt Aufschluss darüber, wie das DiPA-Antragsverfahren abläuft und welche Anforderungen an DiPA gestellt werden, um in das Verzeichnis für digitale Pflegeanwendungen aufgenommen zu werden.

In diesem Artikel erklären wir den Unterschied zwischen der DiPA und DiGA und behandeln die wichtigsten Inhalte der DiPAV und haben letztlich einen Leitfaden für das DiPA-Verfahren erstellt. Dieser zeigt auf, welchen Prozess Ihre Anwendung durchlaufen muss, um in das BfArM-Verzeichnis aufgenommen zu werden.

Inhaltsverzeichnis

• 1. Aktuellste Entwicklungen: DiPA im Gesetz zur Befugniserweiterung und Entbürokratisierung in der Pflege (BEEP)
• 2. Abgrenzung der DiPA zur DiGA
  • 2.1 Krankenkasse vs. soziale Pflegekasse
  • 2.2 Eine DiPA muss kein Medizinprodukt sein
  • 2.3 Preisobergrenze
  • 2.4 Kann eine DiPA auch eine DiGA sein?
• 3. Leitfaden für die DiPAV
  • 3.1 Anforderungen an DiPA
  • 3.2 Antrag
  • 3.3 Beratung durch das BfArM
  • 3.4 Meine DiPA ist gelistet! Was nun?
  • 3.5 Schiedsverfahren
• 4. Weitere Wege in die Kostenerstattung durch Krankenkassen
• 5. Fazit

1. Aktuelle Entwicklungen: DiPA im Gesetz zur Befugniserweiterung und Entbürokratisierung in der Pflege (BEEP)

Wichtig: Im vorliegenden Artikel beschreiben wir die aktuell geltende gesetzliche Regelung zu DiPA. Allerdings wurde im November 2025 das BEEP-Gesetz (Gesetz zur Befugniserweiterung und Entbürokratisierung in der Pflege) vom Bundestag beschlossen, das in seiner jetzigen Fassung relevante Änderungen bezüglich DiPA vorsieht.

Das BEEP-Gesetz sollte zum ersten Januar 2026 in Kraft treten, wurde aber aufgrund kurzfristiger Ergänzungen zur Krankenhausfinanzierung vom Bundesrat in den Vermittlungsausschuss verwiesen. Sollte es unverändert in Kraft treten, wären wichtige Verbesserungen für DiPA enthalten:

• Ein Erprobungsjahr für DiPA soll analog zum DiGA-Fast-Track eingeführt werden. Voraussetzung ist ein entsprechendes Evaluationskonzept, da der vollständige Nutzennachweis noch nicht vorliegt. Gleichzeitig wird die Erforderlichkeitsprüfung für ergänzende Unterstützungsleistungen durch das BfArM gestrichen.
• Vergütungsverhandlungen mit dem GKV-Spitzenverband können parallel laufen. Der Anspruch auf Versorgung startet, sobald die Vergütung vereinbart ist. Diese gilt dann rückwirkend ab dem Tag der Verzeichnisaufnahme.
• Der Versorgungsanspruch pflegebedürftiger Personen wird von bisher 50 € pro Monat auf 70 € erhöht. Davon sollen 40 € auf die DiPA selbst entfallen, 30 € können gegebenenfalls für ergänzende Unterstützungsleistungen erstattet werden. Allerdings ist zu beachten, dass dieses monatliche Budget eventuell bereits bei Inanspruchnahme einer einzigen DiPA aufgebraucht ist. Da aber theoretisch mehrere DiPA parallel angewendet werden können, könnte es nach dieser Regelung weiterhin dazu kommen, dass nur die erste Anwendung erstattet wird und jede weitere DiPA von den Pflegenden oder Gepflegten aus eigener Tasche bezahlt werden muss.
• Fokus ist die Unterstützung von Pflegenden: Der Nachweis eines pflegerischen Nutzens für die pflegebedürftige Person durch DiPA-Hersteller ist nicht mehr zwingend notwendig. Wenn eine Entlastung der Pflegenden durch die DiPA erreicht wird, wird davon ausgegangen, dass sich dies positiv auf die Pflegebedürftigen auswirkt. Um diese Entlastung nachzuweisen, muss eine Evaluation vorgelegt werden. Wie diese aussehen kann, ist nicht näher definiert.
• DiPA sollen künftig nicht nur entlasten, sondern auch gezielt dazu beitragen, dass sich der Zustand pflegebedürftiger Menschen nicht weiter verschlechtert, also präventiv wirken und vorhandene Selbstständigkeit stabilisieren.
• Die Anwendung von DiPA bleibt auf den Bereich der ambulanten häuslichen Pflege beschränkt, der Einsatz in der stationären Pflege ist nicht vorgesehen.

Hinweis: Da das BEEP-Gesetz noch nicht in Kraft getreten ist und sich auch noch inhaltliche Änderungen ergeben können, aktualisieren wir den Artikel, sobald es neue Erkenntnisse gibt. Im Folgenden informieren wir über die aktuell geltende gesetzliche Regelung zu DiPA.

2. Abgrenzung der DiPA zur DiGA

Um die digitale Pflegeanwendung besser zu verstehen, hilft es, ihren Einsatz und Inhalt von der DiGA abzugrenzen.

DiGA sind Apps, die erkrankten Menschen bei der Therapie, Diagnostik, Kompensation oder Linderung von Krankheiten, Verletzungen und Behinderungen unterstützen. Ihr Einsatz wurde am 19. Dezember 2019 mit dem DVG gesetzlich festgelegt. Seitdem können DiGA von Krankenkassen als Teil der ärztlichen und psychotherapeutischen Behandlung erstattet werden. Die DiPA ist ein ähnliches Konzept, das sich aber in erster Linie an pflegebedürftige Menschen richtet. Sie fand Mitte 2021 durch das Digitale-Versorgung-und-Pflege-Modernisierungs-Gesetz (DVPMG) Einzug ins elfte Sozialgesetzbuch (SGB).

Unterschied zwischen DiGA und DiPA 

Da die Abgrenzung zwischen DiGA und DiPA auf den ersten Blick nicht ganz offensichtlich ist, möchten wir in den folgenden Kapiteln die wichtigsten Unterschiede beleuchten.

2.1 Krankenkasse vs. soziale Pflegekasse

Den ersten großen Unterschied zwischen DiGA und DiPA finden wir schon über ihren Platz im Gesetzestext. DiGA werden im SGB V – Gesetzliche Krankenversicherung, DiPA im SGB XI – Soziale Pflegeversicherung definiert. Eine DiGA wird demnach von der Krankenkasse erstattet, wohingegen für die Kosten einer DiPA die soziale Pflegekasse aufkommt.

Eine DiGA wird von ÄrztInnen und PsychotherapeutInnen verschrieben und dient explizit dazu, Menschen mit bestimmten Indikationen bei Linderung, Therapie und Diagnostik zu unterstützen. Die Voraussetzung, um eine DiGA von der Krankenkasse erstattet zu bekommen, ist ähnlich wie bei Medikamenten die Verschreibung eines Arztes oder Psychotherapeuten. Auch eine direkte Genehmigung der Krankenkasse ist möglich. Eine digitale Pflegeanwendung hingegen können Pflegebedürftige ausschließlich bei Ihrer Pflegekasse beantragen.

Antrag des Endanwenders für eine DiPA – Ablauf

Die Versorgung mit einer DiPA wird von der Pflegekasse auf Antrag der pflegebedürftigen Person bewilligt. Die erste Bewilligung muss befristet werden und darf höchstens sechs Monate umfassen. Innerhalb dieser Frist prüft die Pflegekasse, ob die digitale Pflegeanwendung tatsächlich genutzt wurde und ob der Zweck der DiPA in der konkreten Versorgungssituation erreicht wird.

Ergibt diese Prüfung, dass beide Voraussetzungen erfüllt sind, ist eine unbefristete Bewilligung zu erteilen. Ein neuer Antrag ist dafür nicht erforderlich.

Die unbefristete Bewilligung bedeutet, dass die Pflegekasse die monatliche Erstattung bis zu 50 Euro dauerhaft gewährt, solange die gesetzlichen Anspruchsvoraussetzungen bestehen.

2.2 Eine DiPA muss kein Medizinprodukt sein

40a Digitale Pflegeanwendungen SGB XI:

“(1) Pflegebedürftige haben Anspruch auf Versorgung mit Anwendungen, die wesentlich auf digitalen Technologien beruhen”

33a Digitale Gesundheitsanwendungen SGB V: 

“(1) Versicherte haben Anspruch auf Versorgung mit Medizinprodukten niedriger Risikoklasse, deren Hauptfunktion wesentlich auf digitalen Technologien beruht […].”

Dies sind die einleitenden Worte beider Paragrafen im Gesetzestext, welche sofort deutlich machen, dass es in puncto Anforderungen an die digitale Pflegeanwendung einen großen Unterschied gibt.

Während DiGA explizit als Medizinprodukte der Klasse I oder IIa definiert werden, ist bei DiPA nur von “Anwendungen” die Rede. Eine DiPA kann zwar, muss aber kein Medizinprodukt sein. Somit sind viele regulatorische Anforderungen, mit denen DiGA-Hersteller kämpfen, für viele DiPA (auf den ersten Blick) nicht relevant. 

Das BfArM stellt allerdings vergleichbare Anforderungen auch an DiPA, die kein Medizinprodukt sind. Beispielsweise müssen Hersteller über ein Qualitätsmanagementsystem verfügen und Vorgaben an die Sicherheit und Funktionstauglichkeit der App erfüllen. Im aktuellen DiPA Leitfaden (Stand 11.10.2023) werden daher zahlreiche ISO/IEC-Normen für Medizinprodukte referenziert und an vielen Stellen auf die Medical Device Regulation (MDR) verwiesen. Somit unterscheiden sich die Anforderungen an DiPA in den meisten Fällen nicht maßgeblich, da sie an den Anforderungen für Medizinprodukte nach MDR orientiert sind.

Sofern es sich um ein Medizinprodukt handelt, muss dieses einer niedrigen Risikoklasse (I oder IIa) angehören.

Falls Ihre Anwendung als Medizinprodukt zertifiziert werden soll, finden Sie hier weitere Informationen.

2.3 Preisobergrenze

Während die Preisgrenze sich für DiGA nach den anderen Anwendungen in derselben Kategorie richtet, ist für digitale Pflegeanwendungen eine fixe Preisobergrenze vorgesehen. Diese besagt, dass maximal 50 € pro Monat für eine DiPA erstattet werden können (§40b SGB XI). Dies wurde in Fachkreisen zwar kontrovers diskutiert, aber das Gesetz spricht klare Worte. Grundsätzlich kann eine DiPA auch teurer sein, Mehrkosten sind aber dann vom Konsumenten der DiPA selbst zu tragen.

2.4 Kann eine DiPA auch eine DiGA sein?

Eine Anwendung kann grundsätzlich sowohl eine DiPA als auch eine DiGA sein. Nach aktuellem Stand gilt für Hersteller, dass beide Anträge für ein und dieselbe App eingereicht werden können. Zu beachten sind hierbei aber Abweichungen in den Anforderungen. Sofern eine Listung in beiden Verzeichnissen erreicht wird, hat der Leistungsträger des Konsumenten individuell zu prüfen, von welcher Kasse die Anwendung erstattet wird.

3. Leitfaden für die DiPAV

Wir haben die Inhalte der DiPAV in Form eines Leitfadens zusammengefasst, welcher die Antragstellung sowie die Anforderungen und deren Nachweis übersichtlich erläutert. Besonders wichtig ist der Nachweis des pflegerischen Nutzens, welcher ebenfalls erklärt wird.

3.1 Anforderungen an DiPA

Die Anforderungen sind im Gesetzestext auf einem abstrakten Niveau aufgelistet. Eine zentrale Hilfestellung liefern die Anlage-Dokumente 1 und 2 der DiPAV, sowie die Anlage 1 zur DiGAV, denn diese beinhalten Checklisten, mit denen Hersteller die einzelnen Anforderungen an ihrem Produkt prüfen können. 

Folgende Anforderungen gelten für DiPAs:

1. Sicherheit & Funktionstauglichkeit (vgl. DiPAV Anlage 1): Hierbei wird zwischen Medizinprodukten und Nicht-Medizinprodukten unterschieden. Medizinprodukte erfüllen die Anforderungen an Sicherheit & Funktionstauglichkeit durch die CE-Konformitätskennzeichung. Nicht-Medizinprodukte müssen die Anforderungen nach Anlage 1 der DiPAV erfüllen, welche jedoch sehr ähnlich zu den Medizinprodukt-Anforderungen für Risikoklasse I sind. Diese erfordert beispielsweise den Aufbau eines Qualitätsmanagementsystems für Medizinprodukte (z.B. nach ISO 13485), sowie eines Risikomanagementsystems).
2. Datenschutz und Datensicherheit: Neben der DSGVO und dem allgemeinen Stand der Technik in der Datensicherheit sind die vom BSI vorgegebenen Anforderungen und die vom BfArM für DiGA und DiPA festgelegten Datenschutz-Prüfkriterien zu erfüllen. Außerdem sind alle Anforderungen aus der Anlage 1 zur DiGAV auch für DiPA zu erfüllen. Da einige Punkte davon aber nicht 1:1 übertragbar sind, liefert der DiPA-Leitfaden des BfArM weitere Informationen, wie mit diesen umzugehen ist.
3. Anforderungen an die Qualität: (vgl. DiPAV Anlage 2)
   1. Interoperabilität: Hier gelten ähnliche Bestimmungen, wie für DiGA. Ein interoperabler Export von Daten muss sowohl in maschinenlesbarer, als auch menschenlesbarer/ausdruckbarer Form angeboten werden. Die DiPA muss es ebenfalls erlauben, von NutzerInnen verwendete Medizingeräte anzuschließen, sofern Daten daraus benötigt werden. 
   2. Robustheit 
   3. Verbraucherschutz
   4. Altersgerechte Nutzbarkeit, Nutzerfreundlichkeit und Barrierefreiheit
   5. Unterstützung der Pflegebedürftigen und der Nutzer
   6. Qualität der pflegebezogenen Inhalte
   7. Sicherheit der Pflegebedürftigen (Patientensicherheit)
4. Pflegerischer Nutzen

Was ist ein pflegerischer Nutzen?

Der pflegerische Nutzen einer DiPA liegt vor, wenn durch Verwenden der Anwendung einer Beeinträchtigung der Selbständigkeit oder der Fähigkeiten der pflegebedürftigen Person entgegengewirkt wird. Auch das Fortschreiten der Pflegebedürftigkeit einer Person ist darin inbegriffen.

Zudem muss ein pflegerischer Nutzen in mindestens einem der folgenden Bereiche gegeben sein:

1. Mobilität
2. kognitive und kommunikative Fähigkeiten
3. Verhaltensweisen und psychische Problemlagen
4. Selbstversorgung
5. Bewältigung von und selbständiger Umgang mit krankheits- oder therapiebedingten Anforderungen und Belastungen
6. Gestaltung des Alltagslebens und sozialer Kontakte

→ Neben diesen Bereichen kann der pflegerische Nutzen auch im Bereich der Haushaltsführung gegeben sein. 

Wichtig ist hierbei noch zu erwähnen, dass NutzerInnen der DiPA nicht zwangsläufig die pflegebedürftige Person selbst sein müssen. Auch wenn pflegende Personen durch die Anwendung dabei unterstützt werden, in einem der oben genannten Bereiche Hilfe zu leisten, liegt ein pflegerischer Nutzen vor.

Zulässige Studien zum Nachweis des pflegerischen Nutzens

Um den pflegerischen Nutzen nachzuweisen, müssen Hersteller vergleichende Studien vorlegen. Dies können auch retrospektive vergleichende Studien einschließlich retrospektiver Studien mit intraindividuellem Vergleich sein.

Alternativ dazu sind prospektive Studien, und speziell randomisierte, kontrollierte Studien aufgrund der hohe Aussagekraft empfehlenswert. Die Studien sollen in Deutschland durchgeführt werden. Ist dies nicht möglich, muss eine Übertragbarkeit auf den deutschen Versorgungskontext belegt werden.

Leider wurde der bisher einzige öffentlich bekannte Antrag auf Listung im DiPA-Verzeichnis 2024 eben genau aufgrund der Studie abgelehnt. Laut der Pressemitteilung von Lindera kritisierte das BfArM unter anderem, dass die vorgelegte Studie die Effekte der App nicht unabhängig von bereits bestehenden Pflegeleistungen isoliert belegen konnte.

3.2 Antrag

Ablauf des Antrags

Der Antrag für die Aufnahme in das DiPA-Verzeichnis wird vom Hersteller an das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM) gestellt. 

14 Tage nach dem Eingang der vollständigen Antragsunterlagen bestätigt das BfArM dem Antragsteller den Eingang der Unterlagen oder fordert fehlende Unterlagen an. Der Hersteller hat bis zu drei Monate Zeit, fehlende Unterlagen zu ergänzen. Liegen nach Ablauf der Frist keine vollständigen Antragsunterlagen vor, wird der Antrag abgelehnt.

Nachdem alle Unterlagen vollständig sind, hat das BfArM im Normalfall 3 Monate Zeit, den Antrag zu prüfen und zu einer Entscheidung bezüglich der Aufnahme ins DiPA-Verzeichnis zu kommen. 

Inhalt des Antrags

Es ist wichtig anzumerken, dass digitale Pflegeanwendungen nur dauerhaft gelistet werden können. Eine Erprobungsphase gibt es nicht. Das bedeutet im Klartext, dass alle erforderlichen Unterlagen – auch der Nachweis über den pflegerischen Nutzen – bereits zum Zeitpunkt der Antragstellung vorliegen müssen. Der Antrag umfasst:

• Elektronischer Antrag über das Antragsportal beim BfArM
• Unterlagen zum Nachweis des pflegerischen Nutzens
• Unterlagen zum Nachweis der Erfüllung aller Anforderungen
• Ggf. weitere Unterlagen (z. B. Gebrauchsanweisung oder bei Medizinprodukten Konformitätsbewertung nach MDR bzw. MDD)

Im Antrag muss der Hersteller zudem folgende Angaben machen (nach §2 DiPAV): 

1. Hersteller und identifizierende Merkmale der DiPA  
2. Die Zweckbestimmung 
3. Zugehörige benannte Stelle (falls zutreffend)
4. Von der benannten Stelle ausgestellte Zertifikate und der Konformitätserklärung des Herstellers (falls zutreffend)
5. Gebrauchsanweisung
6. Zweckbestimmung, Wirkungsweise, Inhalt und Nutzung der DiPA in einer allgemeinverständlichen Form 
7. Funktionen der DiPA
8. An der Entwicklung der DiPA beteiligten Einrichtungen und Organisationen (falls zutreffend) 
9. Quellen für die in der DiPA umgesetzten pflegebezogenen Inhalte und Verfahren, insbesondere pflegerisch-medizinische Leitlinien und Expertenstandards, Lehrwerke und Studien 
10. Nachweis eines pflegerischen Nutzens einschließlich ergänzender Unterstützungsleistungen Dritter (nach “Nachweis des pflegerischen Nutzens” und “Studien zum Nachweis des pflegerischen Nutzens”) in einer einfachen und allgemeinverständlichen Kurzfassung  
11. Gruppe von Pflegebedürftigen, für die ein pflegerischer Nutzen nachgewiesen wurde 
12. Pflegerischer Nutzen, der für die angegebene Gruppe von Pflegebedürftigen und Nutzern nachgewiesen wurde 
13. Studie/n des Herstellers zum Nachweis des pflegerischen Nutzens einschließlich ergänzender Unterstützungsleistungen Dritter
14. Die Erfüllung der Anforderungen und Vorgaben an eine DiPA einschließlich der jeweiligen Fragebögen 
15. Vorgesehene Nutzerrollen 
16. Qualitätsgesicherte Nutzung der DiPA im häuslichen Umfeld inklusive Ausschlusskriterien für die Nutzung
17. Die für die Nutzung der DiPA erforderlichen und ergänzenden Unterstützungsleistungen Dritter nach Art, Inhalt, Umfang und Dauer, sofern zutreffend 
18. Standorte der Datenverarbeitung 
19. Kompatibilitätszusagen des Herstellers in Bezug auf unterstützte Plattformen und Geräte sowie erforderliches Zubehör und sonstige Produktbestandteile (falls zutreffend) 
20. Genutzte Standards und Profile sowie menschenlesbare Exportformate zur Herstellung von semantischer, syntaktischer und technischer Interoperabilität 
21. Deckungssumme der vom Hersteller für Personenschäden abgeschlossenen Haftpflichtversicherung

3.3 Beratung durch das BfArM

Das BfArM berät Hersteller sowohl vor als auch nach der Aufnahme ins DiPA-Verzeichnis. Die Themen, die in den Beratungsgesprächen behandelt werden, werden dabei maßgeblich von Ihnen als Hersteller bestimmt. Dabei ist es möglich, allgemeine Verständnisfragen zu den DiPA-Anforderungen zu klären, oder aber produktspezifische Unterlagen zu diskutieren.

Für Hersteller, deren DiPA bereits gelistet ist, können hingegen Fragen rund um die Änderung des Produkts behandelt werden.

Die Beratungsgebühr liegt hierbei zwischen 250 und 5.000 Euro (eine zugegeben sehr große Spannweite).

3.4 Meine DiPA ist gelistet! Was nun?

Nach einem positiven Bescheid des BfArM wird Ihre DiPA in das Verzeichnis aufgenommen. Herzlichen Glückwunsch – An diesem Punkt haben Sie einen großen Teil der Arbeit geschafft und können mit Ihrem Team feiern. Ganz am Ziel sind Sie allerdings noch nicht: Innerhalb von drei Monaten nach der Listung wird mit dem Spitzenverband Bund der Pflegekassen der Vergütungsbetrag für die DiPA verhandelt. Zudem sind technische und vertragliche Rahmenbedingungen für die Zurverfügungstellung der DiPA nach § 40a Absatz 4 SGB VI zu regeln.

3.5 Schiedsverfahren

Der Preis für die DiPA wird innerhalb der ersten drei Monate nach Aufnahme in das BfArM-Verzeichnis zwischen Hersteller und der Pflegekasse verhandelt. Erzielen diese beiden Parteien keine Einigung, legt das Schiedsgericht den Preis der DiPA fest. Details über den Ablauf des Schiedsverfahrens erfahren Sie im Abschnitt 8 (§ 30 – § 32) der DiPAV.

4. Weitere Wege in die Kostenerstattung durch Krankenkassen

Neben dem DiPA-Verfahren gibt es außerdem einige weitere Wege, die Software-Herstellern die Kostenerstattung im deutschen Gesundheitssystem ermöglichen. Dazu gehören unter anderem:

• • Überblick über alle Wege in die Kostenerstattung: Zu unserem Whitepaper
  • Kostenerstattung für Software im Krankenhaus: Zu unserem Whitepaper
  • Digitale Gesundheitsanswendungen – DiGA-Verfahren: Zu unserem Leitfaden
  • Selektivverträge mit Krankenkassen: Zu unserem Leitfaden
  • Erstattung von Software im GKV-Hilfsmittelverzeichnis (HMV): Zu unserem Leitfaden
  • Zentrale Prüfstelle Prävention (ZPP): Zu unserem Leitfaden
  • NUB als Kostenerstattung für Software-Produkte im Krankenhaus: Zu unserem Leitfaden

Neben den genannten Wegen in die Erstattung lohnt auch der Blick auf öffentliche Fördermöglichkeiten, die den Weg dahin überbrücken können:

• Der Innovationsfonds: Zum Leitfaden
• Viele weitere Förderungen für Digital Health-Produkte: Zum Leitfaden

5. Fazit

Die Anforderungen an DiPA allesamt zu erfüllen, ist gar nicht so leicht. Vor allem die Vorlage der Studie/n als Wirksamkeitsnachweis zum Zeitpunkt der Erstbeantragung gestaltet sich für Hersteller als Herausforderung. Für die Zulassung von DiGA gibt es ein Fast-Track-Verfahren, welches Herstellern ermöglicht, den Nutzen einer Anwendung innerhalb eines Jahres in einer Studie zu belegen. Ein solches Verfahren ist aber noch nicht für die DiPA umgesetzt. Es bleibt abzuwarten, ob der Fast-Track-Mechanismus wie geplant mit dem BEEP-Gesetz zeitnah gesetzlich verankert wird.

Dieser Leitfaden wird regelmäßig überarbeitet, um den aktuellen Stand zu garantieren.

QuickBird Medical entwickelt Health Apps und Medical Software für Unternehmen und Forschungseinrichtungen auf Auftragsbasis. Falls Sie eine Medical App, DiGA oder DiPA planen und Unterstützung bei der Entwicklung benötigen, setzen Sie sich gerne mit uns in Verbindung und wir besprechen das Vorhaben unverbindlich.

The post DiPA-Leitfaden: digitale Anwendungen für die Pflege appeared first on QuickBird Medical.

Deshalb erhalten DiGA auch erst Ihre Daseinsberechtigung, wenn ihr positiver Versorgungseffekt nachgewiesen werden konnte. Erst dann haben Sie eine Chance, dauerhaft ins Verzeichnis des BfArM aufgenommen zu werden. Am Ende soll Ihre DiGA schließlich einen echten Mehrwert für den Patienten liefern. Denn auch Krankenkassen wollen nur für Maßnahmen bezahlen, die einen Nutzen haben.

In diesem Artikel geben wir Ihnen einen detaillierten Leitfaden darüber, wie der Nachweis positiver Versorgungseffekte zu erfolgen hat.

Inhalt

• 1. Was ist ein positiver Versorgungseffekt?
  • 1.1 Medizinischer Nutzen
  • 1.2 Patientenrelevante Struktur- und Verfahrensverbesserung
• 2. Notwendige Angaben im Antrag
  • 2.1 Angabe der Patientengruppe
  • 2.2 Angabe des positiven Versorgungseffekts
• 3. Studie zum Nachweis positiver Versorgungseffekte
  • 3.1 Zulässige Studientypen
  • 3.2 Stichprobe
  • 3.3 Endpunkte
  • 3.4 Hypothesen
  • 3.5 Methode
  • 3.6 Minimal Clinically Important Difference (MCID)
• 4. Evaluationskonzept (bei vorläufiger Aufnahme)
  • 4.1 Fristen in der Erprobungsphase
• 5. Zusammenfassung

1. Was ist ein positiver Versorgungseffekt?

Ein positiver Versorgungseffekt kann viele Gesichter haben. Das merken wir beispielsweise, wenn wir uns einen typischen Behandlungsverlauf bei einer Depression ansehen:

1. Niedergeschlagenheit und andere depressive Symptomatik
2. Erstbesuch beim Hausarzt
3. Stellung einer Verdachtsdiagnose
4. Überweisung zu einem Psychotherapeuten
5. Wartezeit von 6 Monaten (Quelle: BR24)
6. Diagnostik & Diagnosestellung
7. Ambulante Psychotherapie (20 – 25 Wochen)
8. Rückfallprophylaxe

Schon in dieser sehr vereinfachten Darstellung wird deutlich, in welchen Bereichen die Versorgung von Patienten verbessert werden kann. Dazu gehört nicht nur die Optimierung der Therapie, sondern auch die Verbesserung von strukturellen Parametern, wie etwa eine Verkürzung der Wartezeit oder die Stärkung der Rolle des Patienten in der Therapie. Grundsätzlich unterscheidet die DiGA-Verordnung (DiGAV) beim positiven Versorgungseffekt zwischen zwei großen Kategorien: medizinischer Nutzen und patientenrelevante Struktur- und Verfahrensverbesserungen.

1.1 Medizinischer Nutzen

Im Grunde ist ein medizinischer Nutzen jede Form der Verbesserung von Diagnostik und Therapie. Konkret sind folgende vier Kategorien in der DiGAV als medizinischer Nutzen definiert: 

• Verbesserung des Gesundheitszustands
  • z.B. Rückgang von Symptomen
• Verkürzung der Krankheitsdauer
  • z.B. Schnellere Rehabilitation nach einer OP
• Verlängerung des Überlebens
  • z.B. Frühere Erkennung von Herzerkrankungen
• Verbesserung der Lebensqualität
  • z.B. besserer Umgang mit einer Erkrankung

QuickBird Medical Tipp: Wie man in unserem DiGA-Verzeichnis-Analyzer sieht, gibt es aktuell (Nov 2025) keine im Verzeichnis gelistete DiGA, die nicht einen medizinischen Nutzen nachgewiesen hat. Eine DiGA mit einem reinen strukturellen Effekt (pSVV – siehe nächstes Kapitel) hat generell schlechte Chancen auf eine Listung im DiGA-Verzeichnis. Sie sollten sich auf den medizinischen Nutzen fokussieren, um Ihre Erfolgswahrscheinlichkeit zu maximieren. Mehr Infos finden Sie in unserem DiGA-Verzeichnis-Analyzer: Link

1.2 Patientenrelevante Struktur- und Verfahrensverbesserung (pSVV)

Wie eingangs erwähnt, muss eine DiGA nicht zwangsläufig bei der Therapie oder Diagnostik einer Erkrankung unterstützen, um einen positiven Versorgungseffekt zu erzielen. Auch organisatorische Verbesserungen, wie etwa die Verkürzung von Wartezeiten oder ein einfacherer Zugang zu medizinischen Leistungen wird nach DVG als positiver Versorgungseffekt gewertet. Der pSVV unterteilt sich gemäß DiGAV §8, Absatz 3 in folgende Aspekte:

• Koordination von Behandlungsabläufen
  • Eine DiGA kann beispielsweise die Koordination zwischen dem Patienten und mehreren Leistungserbringern (z.B. Psychotherapeut und Neurologe) optimieren, um einen besser organisierten Therapieablauf zu ermöglichen.
• Ausrichtung der Behandlung an Leitlinien und anerkannten Standards
  • Umsetzung von Patientenleitlinien in Apps, um Betroffenen zu verdeutlichen, wie sie selbst an der Behandlung mitwirken können. Eine App könnte beispielsweise gesundheitsrelevante Informationen anzeigen und regelmäßig an notwendige Arzttermine erinnern.
• Adhärenz
  • Unterstützung bei der Umsetzung von Maßnahmen, die gemeinsam mit dem Arzt vereinbart wurden. Dadurch soll der Patient in seiner aktiven Rolle bestärkt werden.
• Erleichterung des Zugangs zur Versorgung
  • DiGA können dazu beitragen, den Zugang zu medizinischer Versorgung zu verbessern und somit Barrieren, wie den Wohnort oder andere Faktoren kompensieren.
• Patientensicherheit
  • Im Vordergrund steht hier die Vermeidung von Behandlungsfehlern. DiGA können diesen vorbeugen oder den Patienten dabei unterstützen, Fehler selbst zu erkennen.
• Gesundheitskompetenz
  • Menschen fällt es oft schwer, gesundheitsrelevante Informationen zu finden und zu interpretieren. DiGA können dieses Wissen gezielt transferieren und Patienten ein größeres Verständnis für ihre Erkrankung und die Therapie ermöglichen.
• Patientensouveränität
  • DiGA können Patienten darin bestärken, an den Entscheidungsprozessen in der Behandlung mitzuwirken und seine Erfahrungen miteinfließen zu lassen.
• Bewältigung krankheitsbedingter Schwierigkeiten im Alltag
  • Hier geht es um die Unterstützung bei der Kompensation und der Reduktion von Unsicherheiten im Alltag. Eine Anwendung kann dafür sorgen, dass sich ein Patient frühzeitig auf ein Symptom einstellen kann oder ihn bei alltäglichen Tätigkeiten unterstützen.
• Reduzierung der therapiebedingten Aufwände und Belastungen der Patienten und ihrer Angehörigen
  • Viele Therapien sind mit großen Aufwänden seitens der Patienten verbunden. Eine App kann hier beispielsweise helfen, indem sie Wartezeiten verkürzt oder sinnvoll überbrückt oder die physische Anwesenheit bei Terminen minimiert.

Sieht man sich die verschiedenen Bereiche an, merkt man schnell, dass es pSVV vor allem darum geht, die Rolle des Patienten in seiner eigenen Versorgung zu stärken.

Ökonomische Aspekte werden hier bewusst nicht berücksichtigt. Wenn Ihre DiGA den Patienten und Krankenkassen finanzielle Erleichterungen ermöglicht, ist das ein gutes Argument für Ihre Preisverhandlungen, gilt aber nicht als positiver Versorgungseffekt.

QuickBird Medical Tipp: Da eine DiGA als Medizinprodukt zertifiziert sein muss, muss sie laut MDR auch eine Form von diagnostischem oder therapeutischen Nutzen haben. Das hat zur Folge, dass manche Anwendungen, die nur einen pSVV bewirken, nicht als Medizinprodukt gelten und somit auch keine DiGA werden können.

Lesen Sie hier mehr über die Zweckbestimmung nach MDR und die Voraussetzungen für Medizinprodukte.

2. Notwendige Angaben im Antrag

Egal, ob Sie einen Antrag auf dauerhafte oder vorläufige Listung im DiGA-Verzeichnis stellen – einige Angaben sind für alle Hersteller obligatorisch.

2.1 Angabe der Patientengruppe

Sie müssen angeben, für welche Patientengruppe ein positiver Versorgungseffekt erzielt werden soll. Dafür ist ausschließlich eine Eingrenzung nach ICD-Codes zulässig. Jeder ICD-Code beschreibt eine Diagnose, wobei sowohl drei- als auch vierstellige Codes zulässig sind. Dreistellige Codes umfassen eine breitere Patientengruppe, wohingegen ein vierstelliger Code eine nähere Spezifikation dieser Patientengruppe darstellt.

Bedeutung von ICD-Codes

Beispiel:

• Dreistelliger Code:
  • F32 = Depressive Episode
• Vierstelliger Code:
  • F32.0 = Leichte depressive Episode
  • F32.1 = Mittelgradige depressive Episode

Falls Ihre DiGA bei mehreren Indikationen einen positiven Versorgungseffekt nachweisen soll, müssen Sie für jede Patientengruppe einen Nachweis erbringen. Sie können den Nutzen aber auch gleichzeitig für mehrere Indikationen nachweisen, wenn er im Wesentlichen für diese vergleichbar ist. Dazu müssen Sie aber auch alle Indikationen in Ihre Studie mit einbeziehen. Die finale Bewertung, ob der angestrebte Versorgungseffekt dann auch für alle Gruppen vorliegt, obliegt dem BfArM.

Achtung: Ihre DiGA kann am Ende auch nur bei den Indikationen verschrieben werden, für die Sie auch einen Nutzennachweis erbringen können. Definieren Sie in Ihrem Antrag beispielsweise nur F32.1 als Patientengruppe, kann ein Arzt oder Psychotherapeut die DiGA nicht an Patienten verschreiben, denen ein F32.0 (leichte depressive Episode) attestiert wird.

2.2 Angabe des positiven Versorgungseffekts

Eine DiGA muss mindestens einen positiven Versorgungseffekt nachweisen können. Zentral ist hierbei, dass dieser auch konsistent mit der Zweckbestimmung, den Funktionen und Inhalten der DiGA und den veröffentlichten Aussagen (z. B. in Werbematerial) ist. Daher sollten Sie sich zeitgleich mit der Medizinprodukt-Zertifizierung bereits an den Nachweis des positiven Versorgungseffekts denken.

Eine Zweckbestimmung kann nicht mehr so einfach geändert werden. Achten Sie also darauf, dass diese nicht allzu spezifisch formuliert ist. Sie wollen ja später nicht das Potenzial Ihrer DiGA verschenken, wenn diese z.B. auch für andere Indikationen geeignet ist.

QuickBird Medical Tipp: Ein Nachweis mehrerer positiver Versorgungseffekte kann einen großen Mehrwert für die späteren Preisverhandlungen schaffen. Hier erfahren Sie mehr über die Preisverhandlung mit dem GKV-Spitzenverband.

3. Studie zum Nachweis positiver Versorgungseffekte

Der Nachweis eines positiven Versorgungseffekts liefert die Daseinsberechtigung für jede DiGA. Selbstverständlich handelt es sich daher auch um eines der wichtigsten Dokumente, das dem BfArM vorgelegt werden muss. Beim Studiendesign gibt es klare Vorgaben, welche wir in diesem Kapitel behandeln.

Der Durchführungsort der Studie muss Deutschland sein. Denkbar sind zwar auch Länder, in denen das Gesundheitssystem mit dem deutschen vergleichbar ist – dies birgt allerdings große Mehraufwände und Sie müssen genau begründen, warum hier eine Vergleichbarkeit vorliegt.

Zudem muss die Studie auch in einem öffentlichen Studienregister eingetragen werden. Das anerkannte Primärregister für Deutschland ist das Deutsche Register klinischer Studien (DRKS) beim BfArM.

12 Monate nach Einreichung der Studienergebnisse beim BfArM muss die Studie auch veröffentlicht werden. Dabei ist eine Veröffentlichung auf der Webseite ausreichend.

Wenn Sie für die Zertifizierung als Medizinprodukt nach MDR im Zuge der klinischen Bewertung eine Studie durchführen müssen, sollten Sie in Betracht ziehen, diese auch direkt auf die Anforderungen des BfArM abzustimmen. Wenn Sie dabei sauber vorgehen, können Sie mit einer Studie sowohl die klinische Prüfung nach MDR durchführen als auch den positiven Versorgungseffekt nachweisen. 

QuickBird Medical Tipp: Buchen Sie unbedingt ein Beratungsgespräch beim BfArM, um Ihr Studiendesign bzw. Studiensynopse vorab zu besprechen. Auch wenn Sie von Qualität Ihrer geplanten Studie überzeugt sind, kann das BfArM hier eine andere Meinung haben. Am Ende zählt die Meinung des BfArM bei der Zulassung.

3.1 Zulässige Studientypen

Ein kurzes Experteninterview mit meinem Hausarzt sollte doch als Studie reichen, oder? Nein, so einfach geht das nicht.

Anwendungen im DiGA-Verzeichnis werden von den Krankenkassen finanziert und flächendeckend von Patienten genutzt. Das BfArM hat daher ein starkes Interesse daran, dass zu diesen Produkten auch aussagekräftige Erkenntnisse vorliegen. Deshalb vertrauen sie ausschließlich quantitativen Untersuchungen, wie es in der klinischen Forschung üblich ist. Als Mindestanforderung gilt, dass es sich um eine vergleichende Studie handeln muss. Nur so kann ein aussagekräftiger Nutzennachweis erbracht werden.

Einfach gesagt: Sie vergleichen Patienten, die Ihre DiGA nutzen mit Patienten, die Ihre DiGA nicht nutzen. 

Achtung: Es ist nicht gesagt, dass die Patienten, die Ihre DiGA nicht nutzen, keine Behandlung bekommen! Die Kontrollgruppe muss nämlich an der Versorgungsrealität orientiert sein und eine für ihre Situation übliche Behandlung erhalten. Schließlich wollen Sie nachweisen, dass Ihre DiGA den aktuellen Zustand verbessern kann.

Auch vergleichende Studientypen lassen sich noch einmal untergliedern. Beispiele hierfür sind Kohortenstudien, nicht-randomisierte- und randomisierte kontrollierte Studien.

QuickBird Medical Tipp: Randomisierte kontrollierte Studien haben eine sehr hohe Aussagekraft im Vergleich zu vielen anderen vergleichenden Studientypen. Dadurch sind Ihre Ergebnisse weniger angreifbar. Offiziell bringt die Wahl eines aussagekräftigen Studientyps keine Vorteile vonseiten des BfArM. Aktuell hat aber fast jede dauerhaft gelistete DiGA im Verzeichnis ihre positiven Versorgungseffekte mit einer randomisierten kontrollierten Studie nachgewiesen (Stand 14.06.2021).

Vereinfachte Darstellung einer randomisierten kontrollierten Studie

Bei einer kontrollierten Studie werden die Teilnehmer in Gruppen unterteilt. Im einfachsten Fall handelt es sich dabei um eine Kontroll- und eine Studiengruppe. Es ist aber auch denkbar, mehrere Gruppen zu formen, um die Studienergebnisse besser einordnen zu können. Teilnehmer in der Studiengruppe werden in der Studie Ihre DiGA verwenden.

Wichtig ist, dass die Kontrollgruppe an der Versorgungsrealität orientiert ist. Wenn Menschen mit einer Indikation üblicherweise eine bestimmte Behandlung erhalten, sollten die Teilnehmer in Ihrer Kontrollgruppe diese Behandlung auch erhalten. Denn nur so ist eine realistische Nutzenbewertung möglich. Erhalten Menschen üblicherweise keine Behandlung (z.B. wegen Wartezeiten auf einen Therapieplatz), müssen auch Studienteilnehmer in der Kontrollgruppe keine Behandlung erhalten.

Beispiel: Ihre DiGA soll eine ambulante Psychotherapie bei Depression unterstützen, indem sie zusätzliche Empfehlungen liefert, die einen Patienten im Alltag unterstützen. Üblicherweise erhalten Patienten in diesem Szenario also eine ambulante Psychotherapie. Sie könnten Ihre Studienteilnehmer demnach in folgende Gruppen unterteilen:

• Gruppe 1: Patienten, die nur ambulante Psychotherapie erhalten
• Gruppe 2: Patienten, die ambulante Psychotherapie erhalten & zeitgleich die DiGA verwenden

Da es immer mehr DiGA gibt, die flächendeckend eingesetzt werden, ändert sich in manchen Bereichen auch die Versorgungsrealität. Ist die Behandlung mit einer anderen DiGA also bereits ein gängiges Vorgehen, müssen Sie Ihre DiGA in der Studie auch mit der bereits etablierten DiGA vergleichen.

Die Versorgungsrealität, die Sie in der Kontrollgruppe abbilden müssen, kann also drei Formen haben:

• Nichtbehandlung
• Behandlung ohne Einsatz bestehender DiGA
• Behandlung mit Einsatz bestehender DiGA

Ein zusätzliches Qualitätsmerkmal von Studien ist die Verblindung. Verblindung soll verhindern, dass Studienteilnehmer wissen, in welcher Gruppe sie sich befinden. Bei Medikamentenstudien erhält eine Studiengruppe dazu beispielsweise oft ein Placebo-Präparat, welches keine medizinische Wirkung hat. Bei der Untersuchung von Apps ist die Verblindung allerdings nur schwer umzusetzen.

3.2 Stichprobe

Die Stichprobe umfasst alle Teilnehmer, die Sie in Ihre Studie mit einbeziehen. All diese Teilnehmer müssen die Diagnose aufweisen, die Sie in ihrer Patientengruppe spezifizieren. 

Ein großes Fragezeichen ist oft die Stichprobengröße. Im Zuge der Fallzahlplanung müssen Sie herausfinden und begründen, welche Stichprobengröße für die Studie optimal ist. Zu kleine Stichproben sind weniger repräsentativ und führen häufig dazu, dass existierende Effekte nicht erkannt werden. Zu große Stichproben sind für Sie als Hersteller natürlich teuer (Rekruitierung der Teilnehmer, Einschluss in die Studie etc.). Daher ist es wichtig hier eine möglichst präzise Prognose zu machen.

Die optimale Stichprobengröße wird im Rahmen einer statistischen Fallzahlplanung bestimmt. Dabei werden Annahmen über den erwarteten Effekt, die Streuung der Messwerte sowie das gewünschte Signifikanzniveau und die Power getroffen, um die notwendige Anzahl an Teilnehmern zuverlässig zu berechnen. Grundlage dafür sind mathematische Modelle und sofern verfügbar Parameter aus Pilotstudien oder der Literatur. Ein Statistiker übernimmt diese Planung üblicherweise.

Es ist auch möglich, für die Studie bereits existierende Daten zu verwenden (z.B. Abrechnungsdaten von Krankenkassen). Dadurch müssten Sie die Kontrollgruppe nicht selbst abbilden, ist allerdings oft mit erheblichen Aufwänden verbunden und erfordert gute Argumentation beim BfArM. Dabei müssen Sie sich außerdem auf die bereits gemessenen Endpunkte beschränken und sicherstellen, dass diese auch valide gemessen wurden. Sie sind also in der Freiheit eingeschränkt und haben keinen Einfluss auf die Qualität der Daten. 

Auch ein Vorher-Nachher-Vergleich ist grundsätzlich zulässig. In diesem Fall erheben Sie Daten von denselben Personen zu unterschiedlichen Zeitpunkten – z.B. einmal vor Anwendung der DiGA unter herkömmlicher Behandlung und einmal nach Anwendung der DiGA. Doch auch hier muss die Behandlung zum ersten Messzeitpunkt der Versorgungsrealität entsprechen. Dieses Vorgehen ist hauptsächlich bei stabilen Zuständen sinnvoll, in denen eine herkömmliche Behandlung keine Verbesserung mehr erzielt (z.B. Diabetes). 

3.3 Endpunkte

Die Endpunkte einer Studie beschreiben ihre angestrebten Ziele. Grundsätzlich können Sie beliebig viele Endpunkte definieren, der primäre Endpunkt wird aber der angestrebte positive Versorgungseffekt sein – z.B. Verbesserung der Lebensqualität. Die Nutzenbewertung kann über beliebig viele Endpunkte gemessen werden.

Je mehr Endpunkte Sie untersuchen und je mehr Nutzennachweise Sie erbringen können, desto vorteilhafter ist dies für die Preisverhandlungen. Bei der Definition von Endpunkten helfen Erkenntnisse aus der Literatur und der Pilotstudie (falls eine solche vorliegt). Je mehr primäre Endpunkte Sie definieren, desto teurer wird aber auch die Studie z. B. aufgrund einer größeren Stichprobengröße. Die meisten erfolgreichen DiGA beschränken sich auf genau einen primären Endpunkt.

Für die reine Aufnahme ins DiGA‑Verzeichnis ist der Nutzennachweis für einen patientenrelevanten Endpunkt ausreichend. Auch wenn sie nicht komplett deckungsgleich sein müssen, müssen Endpunkte konsistent mit der Zweckbestimmung der Anwendung sein.

Wichtig: Es zählen nur patientenrelevante Endpunkte. Endpunkte, die keinen Nutzen für den Patienten darstellen, spielen beim BfArM keine Rolle. Dazu zählen beispielsweise ökonomische Aspekte.

3.4 Hypothesen

Jede Studie muss konkrete Hypothesen untersuchen. Diese müssen so formuliert sein, dass sie entweder beleg- oder auch widerlegbar sind. Bei Hypothesen handelt es sich um klare Aussagen, die überprüft werden sollen. Idealerweise formulieren Sie für jeden Endpunkt, für den Sie einen Effekt nachweisen wollen, eine eigene Hypothese.

Beispiele:

• Patienten, die die DiGA verwenden, haben nach sechs Monaten eine höhere Lebensqualität als Patienten, die eine herkömmliche Behandlung erhalten.
• Unter Einsatz der DiGA verkürzt sich die Behandlungsdauer im Vergleich zu einer herkömmlichen Therapie.

3.5 Methode

Bei der Messung von Endpunkten müssen anerkannte Methoden eingesetzt werden. Zudem sind Endpunkte auch oft nur durch Selbstauskünfte der Studienteilnehmer messbar. Zum Beispiel gibt es kein Maßband, welches die Lebensqualität eines Menschen punktgenau messen kann. Die wichtigsten Methoden sind medizinische Messgeräte und psychologische Fragebögen.

Beispiele für Messinstrumente für einige positive Versorgungseffekte:

• Lebensqualität:
  • SF-36/SF-12
  • SWLS – Satisfaction with Life Scale
  • EuroQoL (EQ)-5D

• Bewältigung der Schwierigkeiten im Alltag:
  • SASS – Soziale Aktivität Selbstbeurteilungs-Skala
  • GAF – Global Assessment of Functioning

• Patientensouveränität/Selbstwirksamkeit:
  • ASKU – Allgemeine Selbstwirksamkeitserwartung
  • SWOP-9 – Fragebogen zu Selbstwirksamkeit-Optimismus-Pessimismus

Wenn Sie eigene Messmethoden einsetzen, müssen diese erst validiert werden.

3.6 Minimal Clinically Important Difference (MCID)

Der Minimal Clinically Important Difference (MCID) beschreibt den kleinstmöglichen Unterschied in einem Endpunkt, der für Patienten tatsächlich eine spürbare und relevante Verbesserung darstellt. Er hilft dabei einzuschätzen, ob ein statistisch signifikanter Effekt auch klinisch bedeutsam ist. In der Praxis führt genau dieser Punkt häufig zu Diskussionen zwischen Herstellern und dem BfArM: Während Hersteller einen bestimmten Effekt als ausreichend relevant ansehen, kann das BfArM diesen als klinisch nicht bedeutsam einstufen. Die Definition eines angemessenen MCID ist daher ein zentraler Bestandteil der Studienplanung und sollte frühzeitig gut begründet werden.

4. Evaluationskonzept (bei vorläufiger Aufnahme)

Bei einer vorläufigen Aufnahme möchte das BfArM natürlich zumindest einen Anhaltspunkt dafür, warum Ihre DiGA einen positiven Versorgungseffekt erzielen kann und wie man plant, diesen nachzuweisen.

Dies wird in Form eines Evaluationskonzepts sichergestellt und hier gilt eine sorgfältige Herangehensweise. Das Konzept muss von einer herstellerunabhängigen Institution erstellt werden und den allgemeinen wissenschaftlichen Standards entsprechen. Wichtig ist, dass das Evaluationskonzept zum Nachweis des positiven Versorgungseffekts geeignet ist, denn sie müssen sich bei der Durchführung der Studie auch an dieses Konzept halten.

Ein guter Grundstein für das Evaluationskonzept ist die verpflichtende “systematische Nutzerdatenauswertung”. Diese erfolgt auf Basis von Daten, die mit der DiGA erhoben wurden. Auch wenn es nicht öffentlich vom BfArM erwähnt wird, ist darunter eine Pilotstudie zu verstehen.

Diese sollte nicht unterschätzt werden! Das bedeutet nämlich unter anderem, dass Sie ein Ethikvotum dafür brauchen. Dafür ist von einer Wartezeit von mehreren Wochen oder gar Monaten auszugehen. Auch bei der Nutzerdatenauswertung muss Ihre Stichprobe eine gewisse Größe erreichen, um eine gewisse Aussagekraft zu haben (z.B. 50 Personen).

Des weiteren ist eine Literaturrecherche ist für das Evaluationskonzept notwendig. Diese soll einen Überblick über den aktuellen Stand der Forschung in Ihrem Bereich geben und Anhaltspunkte dafür liefern, welche Endpunkte untersucht werden. Die Ergebnisse der Nutzerdatenauswertung sollen zeigen, dass die DiGA funktioniert und den angestrebten Effekt bewirken kann.

Untersuchen Sie in Ihrer Pilotstudie gerne mehrere Endpunkte. Dies hilft Ihnen bei der späteren Fallzahlplanung und Sie können dann entscheiden, welche Endpunkte Sie auch in der geplanten Studie untersuchen möchten.

Dem Evaluationskonzept sind auch noch weitere Dokumente beizulegen. Ein Dokument, auf welches das BfArM ein besonderes Auge wirft, ist das Studienprotokoll. Hier sind insbesondere logistische Aspekte der Studie definiert, wie beispielsweise die Finanzierung, das Datenmanagement und Verantwortlichkeiten. Manche Informationen doppeln sich im Evaluationskonzept und dem Studienprotokoll. Achten Sie darauf, dass auch im Studienprotokoll alle relevanten Informationen enthalten sind.

Auch ein statistischer Analyseplan ist obligatorisch. Dieser enthält unter anderem Informationen zu Randomisierung, Verblindung, Endpunkten, Umgang mit fehlenden Daten und statistischer Analyse.

QuickBird Medical Tipp: Vor Durchführung der Pilotstudie empfehlen wir einen Termin beim BfArM, um die Studiensynopse zu besprechen.

4.1 Fristen in der Erprobungsphase

Mit dem Bescheid über die vorläufige Aufnahme ins DiGA-Verzeichnis gibt es kaum eine Verschnaufpause. Denn dann starten die 12 Monate, in denen DiGA-Hersteller die Möglichkeit haben, die geforderten Studienergebnisse vorzulegen. In diesem Zeitraum muss die Studie gemäß dem Evaluationskonzept vollständig durchgeführt und ausgewertet werden.

Gesetzlich ist zwar ein Antrag auf die Verlängerung des Erprobungszeitraums möglich, dieser muss aber plausibel begründet werden und ist beim BfArM ungern gesehen. Grundsätzlich gilt: kann der Nachweis aus eigenem Verschulden heraus nicht erbracht werden (z. B. durch falsche Planung), wird der Antrag abgelehnt. Zulässig sind nur externe Faktoren, wie etwa die Corona-Pandemie, wodurch die Studie nicht nach Plan durchgeführt werden konnte.

Spekulieren Sie also nicht schon zu Beginn auf die Verlängerung dieses Zeitraums. Wenn dies dem BfArM auffällt, wird auch der Antrag auf Erprobung abgelehnt.

Eine Verlängerung muss spätestens drei Monate nach Ablauf der Frist beantragt werden. Sie sollten allerdings sofort mit dem BfArM Kontakt aufnehmen, sobald sich abzeichnet, dass Sie diese nicht einhalten können.

5. Zusammenfassung

Der Nachweis eines positiven Versorgungseffekts ist essenziell für die dauerhafte Listung im DiGA-Verzeichnis. Der positive Versorgungseffekt wird in zwei Kategorien unterteilt: medizinischer Nutzen und patientenrelevante Struktur- und Verfahrensverbesserung.

Der positive Versorgungseffekt muss im Antrag gemeinsam mit der Patientengruppe (ICD-Code) spezifiziert werden. Den angegebenen Nutzen muss jeder Hersteller für seine DiGA im Zuge einer empirischen Studie nachweisen. Das BfArM hat hohe Anforderungen an derartige Studien. So gilt beispielsweise als Mindestanforderung, dass es sich um eine vergleichende Studie handeln muss. Empfehlenswert sind hierbei insbesondere randomisierte kontrollierte Studien. 

Anforderungen an die Studie im Überblick:

• Es muss mindestens eine vergleichende Studie sein
• Die DiGA muss mit der Versorgungsrealität verglichen werden
• Die Studie muss einen positiven Unterschied in einem patientenrelevanten Endpunkt nachweisen
• Zur Messung von Endpunkten müssen validierte Messinstrumente eingesetzt werden
• Der Durchführungsort der Studie muss Deutschland sein
• Die Studie muss in einem öffentlichen Register eingetragen werden
• Die Studienergebnisse müssen vollständig veröffentlicht werden

Anträgen zur vorläufigen Aufnahme ins DiGA-Verzeichnis ist ein Evaluationskonzept beizulegen, welches zumindest belegt, dass die DiGA funktioniert und es Anhaltspunkte für positive Versorgungseffekte gibt.

Inhalte des Evaluationskonzepts (bei vorläufiger Aufnahme):

• Genaues Vorgehen bei der Studie
• Systematische Nutzerdatenauswertung (Pilotstudie)
• Literaturrecherche
• Studienprotokoll
• Statistischer Analyseplan

QuickBird Medical übernimmt die Entwicklung und Regulatorik Ihrer DiGA und begleitet Sie bis zur Aufnahme ins BfArM-Verzeichnis. Kontaktieren Sie uns jederzeit, falls Sie Fragen haben, oder ein konkretes Projekt umsetzen möchten.

Jetzt kontaktieren!

The post DiGA: Leitfaden zum Nachweis positiver Versorgungseffekte appeared first on QuickBird Medical.

In diesem Artikel geben wir Ihnen einen Überblick über:

• den geplanten Zulassungsprozess in Österreich
• den aktuellen Stand (2026) der Anforderungen an DiGA in Österreich
• den Zeitplan zur Einführung eines DiGA-Zulassungsprozesses in Österreich

Inhalte dieses Artikels

• 1. Hintergrund des DiGA-Konzepts
• 2. Ausgangssituation
• 3. Zulassung als Medizinprodukt vs. Erstattung durch Krankenkassen
• 4. Der Weg zur Erstattung für DiGA in Österreich
  • 4.1 Anforderungen an DiGA in Österreich
  • 4.2 Zeitplan für DiGA in Österreich
  • 4.3 Das Pilotierungsverfahren zur Schaffung eines österreichischen DiGA-Prozesses
• 5. Bisherige Erstattungsmöglichkeiten in Österreich
• 6. DiGA-Modelle in anderen Ländern
• 7. Fazit

1. Hintergrund des DiGA-Konzepts

Deutschland hat 2020 als Pionier das Konzept einer digitalen Gesundheitsanwendung („DiGA“) eingeführt. DiGA sind auch als „Apps auf Rezept“ bekannt und können vom Arzt an Patienten verschrieben werden. Für sie wurde in Deutschland ein spezieller Zulassungsprozess geschaffen: der DiGA-Fast-Track. Digitale Produkte, die diesen Zulassungsprozess erfolgreich durchlaufen haben, werden von den Krankenkassen auf Rezept erstattet.

Länder wie Frankreich und Belgien folgten mit eigenen Zulassungs- und Erstattungsprozessen, die sich am deutschen Fast-Track Verfahren orientieren.

In Zukunft könnte das Konzept einer DiGA auch nach Österreich kommen – mehr dazu in den untenstehenden Kapiteln.

2. Ausgangssituation für digitale Gesundheitsanwendungen

Ausgelöst durch Deutschlands Einführung des DiGA-Fast-Tracks, verstärkte sich 2020 auch in Österreich die Diskussion zur Einführung eines Zulassungsprozesses für digitale Gesundheitsanwendungen (DiGA).

Seit Juni 2023 bildet der Digital Austria Act die Basis dieser Gespräche. Er zielt darauf ab, das österreichische Gesundheitssystem für digitale Innovationen zu öffnen und einen rechtlichen Rahmen für die Integration von DiGA zu schaffen.

Unter Punkt 7.4 ist dort aufgeführt:

„Die Verschreibung qualitätsgesicherter Digitaler Gesundheitsanwendungen soll in Zusammenarbeit mit der Sozialversicherung ermöglicht werden und die telemedizinische Versorgung ergänzen.“

Wie genau dieser Zulassungsprozess aussehen soll, ist noch nicht abschließend geklärt. Aufgrund des intensiven Austauschs mit deutschen Stakeholdern scheint es möglich, dass sich Österreich an ähnlichen Standards wie Deutschland orientieren wird. So sollen Qualität und Effektivität der erstattungsfähigen DiGA sichergestellt werden.

3. Zulassung als Medizinprodukt vs. Erstattung durch Krankenkassen

Im Zusammenhang mit digitalen Gesundheitsanwendungen ist es wichtig, zwischen zwei Zulassungsprozessen zu unterscheiden:

• Der Zulassung von (digitalen) Medizinprodukten nach Medical Device Regulation: Durch die Zulassung nach MDR sind Sie befugt, Ihr Medizinprodukt in Europa auf den Markt zu bringen. Dies bedeutet jedoch nicht, dass Sie auch Geld von den Krankenkassen für Ihr Produkt erhalten. Es geht hier erstmal nur um die Freigabe, dass Ihr Produkt sicher und leistungsfähig ist und somit grundsätzlich von Anwendern genutzt werden darf.
• Die Zulassung von digitalen Gesundheitsanwendungen (DiGA) für die Erstattung durch Krankenkassen: Wenn Sie Ihr digitales Produkt über die Gelder von Krankenkassen finanzieren möchten, müssen Sie sich mit länderspezifischen Regelungen beschäftigen. In Deutschland ist dies z.B. der DiGA-Zulassungsprozess beim BfArM, der es Ihnen ermöglicht, Ihr Produkt durch Krankenkassen erstatten zu lassen. Hierfür muss Ihr Produkt übrigens bereits als Medizinprodukt nach MDR zugelassen sein.

Ein digitales Medizinprodukt in Österreich auf den Markt zu bringen, ist aktuell durch die MDR bereits fest geregelt und ohne Probleme möglich. Ein standardisierter Prozess, wie Sie speziell ein digitales Gesundheitsprodukt in Österreich durch Krankenkassen erstatten lassen können, wird hingegen erst noch erarbeitet.

Eine stark vereinfachte Abbildung der regulatorischen Abgrenzungen von DiGA in Österreich.

4. Der Weg zur Erstattung für DiGA in Österreich

Zum jetzigen Zeitpunkt ist die genaue Ausgestaltung des Zulassungsprozesses noch weitestgehend unklar. Sowohl von Herstellerseite als auch von offizieller Seite wie der österreichischen Agentur für Gesundheit und Ernährungssicherheit (AGES) wird oft der deutsche DiGA-Fast-Track als Referenz angegeben. Es werden jedoch keine einzelnen Aspekte des deutschen Verfahrens hervorgehoben. Auch die Möglichkeit einer vorläufigen Zulassung ohne abgeschlossenen Wirksamkeitsnachweis wurde noch nicht abschließend geklärt.

Es gibt jedoch einige Anhaltspunkte, die mehr Aufschluss über die geplanten Anforderungen eines österreichischen DiGA-Zulassungsprozesses geben.

4.1 Anforderungen an digitale Gesundheitsanwendungen in Österreich

Konkrete Empfehlungen für Anforderungen an DiGA im österreichischen Gesundheitssystem hat das AIHTA (Austrian Institute for Health Technology Assessment) 2020 in einer ersten Studie veröffentlicht. Das AIHTA ist ein unabhängiges Institut zur wissenschaftlichen Entscheidungsunterstützung im Gesundheitswesen. Gesellschafter sind insbesondere die Länder Österreichs sowie der Dachverband der Sozialversicherungen.

Folgende Kriterien empfahl das AIHTA zur Qualitätsüberprüfung von DiGA:

• In einem ersten Schritt sollen DiGA auf Vorliegen einer CE-Kennzeichnung, sowie einer Einordnung nach Risikoklassen laut MDR überprüft werden.
• Die gemeldete Risikoklasse nach MDR soll anschließend dazu verwendet werden, die notwendigen Evidenznachweise, wie zum Beispiel die Durchführung von Studien, festzulegen. Zuständig dafür ist die AGES (Agentur für Gesundheit und Ernährungssicherheit).
• Eine Zulassung als erstattungsfähige DiGA soll unter Einbeziehung des Dachverbands der Sozialversicherungen ausgestellt werden. Die Kriterien sind dabei klinische Wirksamkeit und Sicherheit, zu erwartende Kosten im Gesundheitssystem, Datensicherheit und -schutz sowie Usability und Interoperabilität.
• Der Prozess soll laut Empfehlung des AIHTA pilotiert und dabei angepasst werden.

Viele der Kriterien des AIHTA wurden auch auf der LISAvienna Regulatory Konferenz im Herbst 2023 diskutiert:

• Therapietreue als Qualitätskriterium
• Nutzung von (anonymisierten) Gesundheitsdaten für ärztliches Fachpersonal, Hersteller oder zu Forschungszwecken
• Keine Brüche im digitalen Versorgungsweg: Anbindung an andere digitale Lösungen im Gesundheitswesen wie die österreichische Patientenakte ELGA
• Notwendigkeit der Bekanntmachung von digitalen Gesundheitsanwendungen, um Interesse an DiGA seitens Patienten sowie von ärztlicher Seite zu etablieren

Welche Kriterien schlussendlich im finalen Zulassungsprozess auch so übernommen werden, ist bisher noch nicht absehbar.

4.2 Zeitplan für DiGA in Österreich

Für die reguläre Erstattung von DiGA ist es von entscheidender Bedeutung, welche Anforderungen der Dachverband der Sozialversicherungsträger und die Österreichische Gesundheitskasse für DiGA festlegen. Erst danach ist absehbar, welche Art von digitalen Gesundheitsanwendungen überhaupt erstattungsfähig sind. Hier sollen die erarbeiteten Rahmenbedingungen im Rahmen der Pilotierung aus dem Jahr 2024 Aufschluss geben, die wir im nächsten Unterkapitel vorstellen.

Im Juni 2024 veröffentlichte das Bundesministerium für Soziales, Gesundheit, Pflege und Konsumentenschutz die „eHealth-Strategie Österreich“. Darin ist die konkrete Maßnahme zur Gestaltung eines Zulassungsprozesses für digitale Gesundheitsanwendungen festgelegt:

„M1.7: Schaffung eines einheitlichen Prozesses für die Bewertung digitaler Gesundheitsanwendungen (DiGAs) sowie digitaler Pflegeanwendungen (DiPAs) und in weiterer Folge bei darstellbarem Nutzen deren Einführung in die Gesundheitsversorgung. Priorisierung/zeitliche Planung: Kurzfristig (2024-2026)“

Das Pilotverfahren wurde November 2025 abgeschlossen. Bis Ende 2026 soll der gesetzliche Rahmen festgelegt werden, damit ab Anfang 2027 auch in Österreich DiGA verschrieben werden können.

4.3 Das Pilotierungsverfahren zur Schaffung eines österreichischen DiGA-Prozesses

Die Festlegung des Zulassungs- und Erstattungsverfahrens für DiGA wurde in Österreich im Rahmen eines Pilotprojekts vom Verband der Sozialversicherungen getestet. Die Praktikabilität des erarbeiteten Verfahrens sollte dabei anhand der Bewertung konkreter digitaler Gesundheitsanwendungen erfolgen.

Das Projekt wurde in einer schriftlichen Antwort an den SVDGV wie folgt skizziert:

Initiator des Projekts	Dachverband der Sozialversicherungen
Ziel des Pilotverfahrens	Praxistest erarbeiteter Bewertungskriterien durch den Dachverband der Sozialversicherungen
Laufzeit	August 2024 bis Ende Februar 2025, danach Start der Umsetzungsphase
Kriterien an DiGA zur Aufnahme ins Verfahren	– DiGA ist Medizinprodukt der Klasse I oder IIa – Teilnahme unterliegt der Vertraulichkeit – Bereitschaft des DiGA-Herstellers an Meetings teilzunehmen und Rückfragen zu beantworten – keine Vergütung für die Teilnahme – keine Garantie für die tatsächliche spätere Vergütung teilnehmender DiGA
Definition des Projekterfolgs	Teilnehmende DiGA sollen das zuvor erarbeitete HTA-Framework durchlaufen haben. Es soll dadurch eine Bewertung möglich gewesen sein. Das erarbeitete Verfahren wird anschließend vorgestellt.
Einbezogene Stakeholder	e-Health Beauftragter der „Bundeskurie niedergelassene Ärzte“ (Keine Einbindung von Patienten oder Ärzten)
Vorteile für DiGA-Hersteller durch die Teilnahme	Einblick in den geplanten HTA-Prozess

5. Bisherige Erstattungsmöglichkeiten in Österreich

Bereits jetzt können digitale Gesundheitsanwendungen in Österreich ausnahmsweise erstattet werden. Diese Anwendungen fallen unter die Kategorie „Sonstige notwendige Heilbehelfe“ gemäß § 137 des Allgemeinen Sozialversicherungsgesetzes (ASVG). Patienten können somit unter Einhaltung bestimmter Bedingungen einen Anspruch auf Kostenerstattung geltend machen.

Laut § 133 Abs. 2 ASVG ist es entscheidend, dass die DiGA den beabsichtigten Zweck erfüllt, ohne das notwendige Maß zu überschreiten. Die Überprüfung dieser Bedingung erfolgt individuell für jeden Antrag, wodurch die Erstattung nur in Einzelfällen gewährt wird.

Die Nutzung von Gesundheitsapps wird in Österreich bereits seit einiger Zeit gefördert. Eine Umfrage des österreichischen Dachverbands der Sozialversicherungen aus dem Jahr 2018 ergab, dass 9 von 16 Organisationen innerhalb der österreichischen Sozialversicherung insgesamt 22 Gesundheitsapps kostenfrei an ihre Versicherten abgaben. Auffällig dabei war, dass für die Mehrheit dieser Angebote kein Nachweis eines Versicherungsverhältnisses erforderlich war, was die Zugänglichkeit erhöhte. Im Jahr 2018 boten damit etwas mehr als die Hälfte der Krankenversicherungen in Österreich solche digitalen Gesundheitsanwendungen an.

Ein wesentliches Thema in diesem Zusammenhang ist die Qualitätsprüfung der angebotenen Apps. Bislang war die Klassifizierung als Medizinprodukt kein notwendiges Kriterium für die Bereitstellung der Apps. Es existiert hierzu keine einheitliche Qualitätskontrolle. Nichtsdestotrotz wurde versucht, bestimmte grundlegende Qualitätskriterien zu berücksichtigen, wie aus entsprechenden Grafiken und Auswertungen hervorgeht.

Interessanterweise konzentrierte sich der Großteil der verfügbaren Anwendungen auf die Prävention. Nur 5 der 22 untersuchten Apps waren in ein Behandlungs- oder Telemonitoring-Konzept integriert und somit speziell für erkrankte Personen konzipiert.

6. DiGA-Modelle in anderen Ländern

Immer mehr Länder planen einen standardisierten Prozess, um digitale Gesundheitsanwendungen in die Regelversorgung zu bringen. Neben Österreich sollten Sie außerdem einen Blick in die folgenden Länder werfen:

• Belgien (Link zum Leitfaden für die Zulassung von DiGA in Belgien)
• Frankreich (Link zum Leitfaden für die Zulassung von DiGA in Frankreich) 
• Deutschland (Insider-Tipps für die Zulassung von DiGA in Deutschland)
• Italien (Link zum Whitepaper: Kommen DiGA bald nach Italien?)
• Schweiz (Link zum Leitfaden für die Erstattung von Digitalen Gesundheitsanwendungen (DiGA & dGA) in der Schweiz)

Neben standardisierten DiGA-Zulassungsprozessen gibt es außerdem die Möglichkeit, digitale Lösungen über Selektivverträge erstatten zu lassen. Mehr hierzu in unserem Whitepaper zu Selektivverträgen.

Außerdem existiert eine breite Palette öffentlichen Förderungen, welche sich für Digital Health-Produkte eignen: Link zu unserem Förderungsleitfaden für Digital Health-Produkte

7. Fazit

2025 scheint Bewegung in die österreichische Diskussion um die Einführung von digitalen Gesundheitsanwendungen (DiGA) gekommen zu sein. Trotz der großen geäußerten Motivation aller Beteiligten ist aktuell jedoch noch kein gesetzlicher Zulassungsprozess in Sichtweite.

Die Ergebnisse des AIHTA-Pilotierungsverfahrens werden gespannt erwartet. Der nächste wichtige Schritt ist die Festlegung der Anforderungen, die eine DiGA in Österreich erfüllen muss. Wichtig sind anschließend die konkreten Voraussetzungen für die Erstattung durch die Krankenkassen.

Erst dann bieten sich für Hersteller gesicherte Rahmenbedingungen, um DiGA in Österreich zu vertreiben.

Wir aktualisieren den Artikel bei neuen Entwicklungen. Abonnieren Sie unseren Newsletter, um hierzu auf dem neuesten Stand zu bleiben.

Der deutsche DiGA-Fast-Track – ein Modell für ganz Europa?

In diesem Whitepaper sehen wir uns an, in welchen EU-Ländern bereits ein DiGA-Modell existiert, ein DiGA-Modell geplant wird oder keinerlei DiGA-Modell in Aussicht steht. Außerdem klären wir die Frage: Kommt ein standardisiertes Modell in Europa für die EU-DiGA?