medicalvalues hat ein klinisches Entscheidungsunterstützungssystem entwickelt, das sowohl im ambulanten als auch stationären Bereich eingesetzt werden kann, um Ärztinnen und Ärzten bei der frühen und gezielten Diagnosestellung zu unterstützen und auf Künstliche Intelligenz zurückgreift.

Eine spezielle Funktion ist, dass wir sagen, welche Erkrankung vorliegen könnte, und warum, aber auch stufendiagnostische Hinweise bietet. Die Software gibt beispielweise nicht nur an, dass es Rheuma sein könnte, sondern auch, welche Diagnostik nun weiter notwendig oder auch nicht notwendig ist. Das ist zum Beispiel wichtig, wenn es um Doppeltestungen geht, die man vermeiden will. Wir verbinden also Künstliche Intelligenz und Workflows miteinander. Da zu unseren ersten Kunden unter anderem niedergelassene Labors gehörten, war uns von Anfang an bewusst, dass wir für eine umfassende medizinische Diagnostik ein breites Krankheitsspektrum abdecken müssen.

Die klinische Entscheidungsunterstützung und medizinische Dateninterpretation als Kernfunktionalität sind Teil des zugelassenen Medizinproduktes. Wir bilden jedoch auch Themen wie Datenmanagement, elektronische Patientenakte oder LOINC¹-Mapping ab, die nicht unter das Medizinproduktegesetz fallen, weil dort keine medizinischen Vorschläge entstehen.

Unser Produkt fällt in die Klasse IIa, weil wir medizinische diagnostische Vorschläge liefern. Um dies festzustellen, haben wir uns damals Beratung eingeholt. Gemeinsam mit dem Beratungsunternehmen geht man den Entscheidungsbaum zur Identifikation der relevanten Risikoklasse durch. In welche Klasse das Produkt genau eingeteilt wird, ändert jedoch kaum noch etwas am Aufwand, denn man muss ab der Klasse II das Risikomanagement berücksichtigen, mit der Benannten Stelle arbeiten usw..

Meiner Ansicht nach ist aber ein Schritt vorher noch der viel Wichtigere. Die Frage lautet: „Wann wird meine Software ein Medizinprodukt?” Ein Produkt im Softwarebereich wird zu einem Medizinprodukt, wenn mit dieser Software Daten manipuliert bzw. Daten interpretiert werden. Dabei kann interpretieren auch bedeuten, dass man einen Teil der Daten weglässt.

Es gibt zu dieser Thematik zurzeit zahlreiche Diskussionen, beispielweise um Software, die einen Arztbrief schreibt oder ein Gespräch zwischen Ärztin bzw. Arzt und Patientin bzw. Patient mitschneidet und anschließend zusammenfasst. Ich sehe es sehr kritisch, diese Software nicht als Medizinprodukt zu bewerten, denn wenn man ein Gespräch zusammenfasst, handelt es sich dabei auch immer um eine Komprimierung. Wenn Daten weggelassen werden, werden diese vorher interpretiert, sodass in diesen Fällen ein Medizinprodukt vorliegt. Auch wenn man natürlich bezüglich der Zweckbestimmung anders argumentieren kann.

Eine Hürde bei uns war - und da erzähle ich nichts Neues -, dass die zeitlichen Vorlaufzeiten sehr schwer planbar sind. Wenn man ein Produkt auf den Markt bringen möchte, muss man einen genauen Zeitplan machen. Man stellt sich jedoch fortwährend die Fragen: „Wie lange dauert der Zertifizierungsprozess?” „Wann bekommt man von der Benannten Stelle eine Rückmeldung?” Man wartet also wiederholt auf die Rückmeldung von Dritten. Das ist eine kritischere Herausforderung als man zunächst erwartet. Wichtig dabei ist, die Situation und den Zeitplan mit seinen Kunden, Partnern und Investoren gut zu kommunizieren. Unsere Kunden sind ebenfalls in einem regulierten Bereich unterwegs, weil z. B. Labore selbst Tests entwickeln oder an Studien teilnehmen. Daher gab es vonseiten der Kunden oft viel Verständnis für die Situation.

Was zusätzlich noch essenziell ist: Mein Mitgründer und ich wissen durch unsere vorherigen Tätigkeiten, wie Enterprise-Software aussieht, und wie man professionell Software entwickelt. Ich kann daher nur empfehlen, nicht einfach drauflos zu programmieren, sondern Tests zu schreiben sowie in einer Entwicklungsumgebung und einer modernen Softwarearchitektur zu arbeiten. Die Kernprozesse des Unternehmens sollten also state-of-the-art aufgebaut sein. Ich würde sogar so weit gehen, dass man hinsichtlich der Entwicklung und deren Prozesse deutlich mehr machen muss, als in den Medizinprodukteregularien vorgeschrieben wird. Für uns war diese Softwarekenntnis von enormem Vorteil, da wir uns so mit den Beratern aus dem Medizinproduktebereich sehr gut ergänzen konnten.

Es ist immer gut, um sich eine Zweitmeinung zu holen; auch, um ganz konkrete Fragen zu beantworten. Aber ansonsten war unser Learning, dass man nicht daran vorbeikommt, sich selbst Gedanken zu machen, Bücher zu kaufen und sich zu belesen. Denn besonders, wenn der Kern und Schwerpunkt eines Unternehmens die Entwicklung von Software als Medizinprodukt ist, dann ist das Thema Regulatory ein Kernprozess, und dieses Wissen kann man nicht auslagern. Man muss eigenes Know-how aufbauen. Wir haben aber natürlich auch mit verschiedenen Beratern, Mentoren und Netzwerken regelmäßig Rücksprache gehalten und uns Tipps eingeholt.

Es ist gut beschrieben, welche Anforderungen man erfüllen muss, um ein Medizinprodukt der Klasse IIa in Verkehr zu bringen. Es gibt sehr viele Blogs, Literatur, Open-Source- und Beratungsangebote. Um aber eigenständig die Beratung beurteilen zu können, muss man die Regulatorik für sich einordnen und auf dem Laufenden bleiben. Dazu muss man in den Primärdokumenten und in den Regulatorien eigenständig genau nachlesen, diese verstehen und auch kritisch hinterfragen. Man will in der Regel den leichten Weg gehen, sich einen Blog durchlesen und starten. Aber es lohnt sich, einen Schritt zurückzutreten und sich zu überlegen, welches Ziel man hat.

Am Anfang macht es Sinn, zu generischen Veranstaltungen zu gehen. Diese sind gut, um den Überblick zu bekommen. Und danach würde ich empfehlen, sehr spezifisch nachzufragen. Wir haben uns auf ein Treffen mit Beratungsunternehmen immer vorbereitet, indem wir unseren Prozess erarbeitet und vorgestellt haben. Es ist wichtig, dass man erst einmal aufschreibt, wie man es umsetzen will und für richtig hält und dann nach einer zweiten Meinung fragt. Weiterhin ist es von Bedeutung, sich frühzeitig an die Benannte Stelle zu wenden.

Der EU AI-Act muss in unserem Fall beachtet werden. Wichtig dabei ist die Risiko- und Konformitätsbewertung sowie die Wahrung der Grundrechte der Patientinnen und Patienten. Zudem muss beispielweise über die Funktionsweise und den Prozess zur Entscheidungsfindung informiert, die Markteinführung überwacht und im Falle von Problemen schnell reagiert werden. Aber sehr viele Anforderungen aus dem AI-Act erfüllt man ohnehin, wenn man ein Medizinprodukt entwickelt, wie zum Beispiel das Risikomanagement. Dennoch sollte man sich mit dem AI-Act beschäftigen, denn es gibt auch Aspekte, die in den Medizinprodukteregularien nicht beschrieben sind.

Ein großes Problem liegt bei der hohen Nachfrage nach den Benannten Stellen. Vielleicht wäre es daher auch für die Benannten Stellen einfacher, wenn es hier einen übergeordneten Service geben würde. Dort könnten die Vorlaufzeiten, Geschäftsbereiche und Ansprechpartner gesammelt dargestellt werden.