Die Entwicklung einer regulierten Medizinprodukt-Software nach Medical Device Regulation (MDR) geht mit Aufwand und Kosten einher. Es müssen die Vorgaben der MDR eingehalten und gleichzeitig die Konformität mit relevanten Normen (ISO 13485, IEC 62304, ISO 14971, IEC 62366 etc.) sichergestellt werden für eine Zertifizierung.
Diese Kosten müssen sich am Ende für Ihr Unternehmen natürlich auch strategisch und finanziell lohnen.
In diesem Artikel fassen wir die wichtigsten Empfehlungen zusammen, die Sie bei der Planung und Umsetzung Ihrer Medical Software oder Medical App beachten sollten. Unabhängig davon, ob Sie nun ein Clinical Decision Support System (CDSS) für Ärzte oder eine digitale Gesundheitsanwendung für Patienten entwickeln, sollten einige grundlegende Dinge beachtet werden, um Stolpersteine auf dem Weg zur Zertifizierung gekonnt zu umgehen.
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:
| Frage | Beispiel |
| Ist diese Zielgruppe digital affin?
Gibt es eine ähnliche Zielgruppe, die digital-affiner wäre? |
Wenn das Produkt von pflegebedürftigen Personen verwendet werden soll, ist das Durchschnittsalter der Zielgruppe vermutlich verhältnismäßig hoch. Die Zielgruppe ist daher weniger digital-affin als z.B. eine 20-jährige Patientin. Welche besonderen Bedürfnisse gilt es zu beachten? Könnten Sie stattdessen die Angehörigen der pflegebedürftigen Personen adressieren? Denn das sind oft junge Personen, die z.B. ihren pflegebedürftigen Eltern helfen und finanzielle Entscheidungen für diese treffen. |
| Adressieren Sie einen vorhandenen großen Schmerzpunkt Ihrer Zielgruppe oder ist Ihre App nur ein nice-to-have für diese Zielgruppe? | Viele Patienten mit mentalen Problemen haben mit langen Wartezeiten für Psychotherapeuten zu kämpfen. Diese Wartezeit stellte bisher eine Versorgungslücke dar, die nun viele Startups im Bereich Mental Health versuchen zu schließen. Der Leidensdruck der Zielgruppe ist groß und die Zielgruppe größtenteils digital affin, weshalb die Zielgruppe potenziell hohes Interesse an einer digitalen Anwendung hat. |
| Ist der Arzt oder der Patient Ihre Hauptzielgruppe?
|
Einem Produkt, das nur funktioniert, wenn sowohl Patienten und Ärzte an Bord sind, stehen große Hürden beim Marktzugang bevor. Sie müssen bei beiden Zielgruppen eine kritische Masse an Menschen erreichen. Fokussieren Sie sich daher lieber (falls möglich) erstmal nur auf eine der beiden Parteien und bauen Ihr Produkt so auf, dass es auch ohne Mitwirken der anderen Partei funktionieren könnte. Später können Sie Stück für Stück auch die andere Partei in Ihre Lösung involvieren. |
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 Daten-Leck kann neben möglichen Strafzahlungen einen massiven Reputationsschaden an Ihrem Unternehmen und Produkt anrichten. Dies sollten Sie natürlich auf Nötigste vermeiden.
Leider bringt die Umsetzung des Datenschutzes nach DSGVO und der Datensicherheits-Maßnahmen 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 27001), um die Anforderungen für die Zulassung zu erfüllen.
Gerade der organisatorische Teil der Datensicherheit wird bei IT-orientierten Teams oft unterschätzt. Angreifer kommen aber nicht nur über Software-Schwachstellen an Ihre Daten, sondern nutzen manchmal auch die menschliche Schwachstelle z.B. mithilfe von “Social Engineering” gezielt aus.
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 27001) 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.
- usw.
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:
| Finanzierung über Selektivverträge mit Krankenkassen | Finanzierung über Digitale-Versorgung-Gesetz (DiGA-Fast-Track) |
| Jede Krankenkasse muss separat überzeugt werden | Sofortiger Zugriff auf Erstattung durch alle gesetzlichen Krankenkassen |
| Keine transparenten, standardisierten Prüf-Kriterien | Standardisierter, transparenter Prüfprozess |
| Fokus ist meist auf möglichen Kostenreduktionen für die Krankenversicherung | Fokus kann auf Verbesserung der menschlichen Gesundheit liegen und ist dabei erstmal unabhängig vom Kosteneinsparungspotenzial für die Krankenkassen |
| Wissenschaftliche Evidenz muss meist vor dem Erstattungszeitpunkt vorliegen | Potenzial wissenschaftlicher Evidenz muss durch Evaluationskonzept (und Pilotstudie) initial geprüft werden, aber es muss im ersten Jahr keine vollumfängliche klinische Studie vorliegen |
| Kein klarer Zeitrahmen zur Finanzierung | Klarer Zeitrahmen durch gesetzlich festgeschriebene Prüfungsfristen (Rückmeldung innerhalb von 3 Monaten etc.) |
| Anforderungen an Studien sind ggf. niedriger | Sehr hohe Anforderungen an das Studien-Design |
| Anforderungen an Ihre Anwendung sind ggf. niedriger | Hohe Anforderungen an Datensicherheit, Datenschutz, Barrierefreiheit, Interoperabilität etc. |
| Anwendungsfälle denkbar, die rechtlich nicht als DiGA zugelassen werden können (z.B. Primärprävention) | DiGA sind beschränkt auf Patienten-zentrierte Anwendung, die meist der Therapie dienen (mehr dazu lesen Sie in unserem Blog-Artikel) |
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.
Fünf 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.
