gms | German Medical Science

Einleitung und Zielstellung: Mit der Gültigkeit der Medical Device Regulation (MDR) [1] wird die Entwicklung und Herstellung von klinischen Entscheidungsunterstützungssystemen (CDSS) für den Einsatz in der klinischen Praxis erheblich aufwändiger [2]. Jede Software, deren Zweckbestimmung die Diagnose, Vorbeugung, Überwachung, Vorhersage oder Behandlung einer Krankheit, einer Verletzung oder einer Behinderung ist, gilt als Medizinprodukt im Sinne der MDR (Art. 2 Nr. 1 MDR). Diese wird als Medical Device Software (MDSW) bezeichnet. CDSS sind nach der MDR in die Klasse IIa oder höher zu klassifizieren. Dies hat zur Folge, dass die Entwicklung eines CDSS, welches in der klinischen Routine oder im Rahmen einer Studie am Patienten, bzw. in der Versorgung eingesetzt werden soll, bereits von Beginn des Entwicklungsprozesses die Anforderungen an die Prozesse der Grundlegenden Sicherheits- und Leistungsanforderungen erfüllen muss [3].

Im Rahmen des Use Cases HELP des SMITH-Konsortiums der Medizininformatik Initiative (MII) haben wir ein System entwickelt, das eine Entscheidungshilfe für die Diagnose und Behandlung von Patienten mit bestimmten Blutstrominfektionen bietet. Eine datengesteuerte Softwarelösung, die die Entscheidungsfindung unterstützt, gilt in Bezug auf die MDR als Medizinprodukt. Mit der vorliegenden Zweckbestimmung ist das CDSS als Medizinprodukt, bzw. MDSW als Klasse IIa oder IIb einzustufen. Dies hängt in dem konkreten Beispiel von dem Funktionsumfang zur Unterstützung der Arzneimittelverordnung ab. In dem Projekt SMITH wird ein Ansatz mit einem nicht durch Daten gesteuerten CDSS mit einer ähnlichen Entscheidungshilfe bereits eingesetzt und dessen klinischer Nutzen in einer klinischen Studie evaluiert [4].

In diesem Artikel stellen wir die Ziele der Entwicklung des datengesteuerten CDSS vor: die Machbarkeit der Implementierung eines solchen als Medizinprodukt in einer akademischen Umgebung zu evaluieren. Wir schlagen ein wiederverwendbares Softwarearchitekturkonzept vor, welches die Entwicklung von CDSSs als Medizinprodukt erleichtert.

Konzept und Implementierung: In der Softwarearchitektur der Anwendung können wir zwischen zwei Hauptteilen unterscheiden. In einem Teil haben wir eine Benutzeroberfläche (UI) für die Visualisierung der Patientendaten, die im CDSS verwendet werden („Patientendaten-Visualisierer“), und im anderen Teil die Komponente, welche die tatsächliche Entscheidungsunterstützung bietet („CDSS-Komponente“). Indem wir diese beiden Hauptteile so weit wie möglich entkoppeln und sie zu autarken Einheiten machen, die unabhängig voneinander entwickelt werden können, können wir der CDSS-Komponente eine andere (d.h. höhere) Kritikalität zuweisen und folglich die regulatorische Belastung für die anderen Teile der Anwendung verringern. Des Weiteren können wir so die Entwicklung der verschiedenen Komponenten parallelisieren und sogar den Patientendaten-Visualisierer für diverse CDDSs verschiedener Anwendungsfälle wiederverwenden.

Die Softwareentwicklung findet nach einem vordefinierten, strukturierten Prozess statt, der in einem Softwareentwicklungsplan zu beschreiben ist. Dazu gehört auch der Plan für die Verifikation und das Testen der Software. Für das HELP-Projekt wurden im Rahmen einer testgetriebenen Entwicklung Unit-Tests implementiert und danach Integrationstests im Rahmen einer kontinuierlichen Integrationsstrategie (CI) durchgeführt. Dieser Ansatz ermöglicht die Verifikation und Überprüfung der Funktionsfähigkeit der Software während des gesamten Softwareentwicklungsprozesses. Darüber hinaus empfiehlt es sich die Abhängigkeit von externer Software unbekannter Herkunft (SOUPs) auf das unvermeidbare Minimum zu reduzieren, da SOUPs die Verifikation erheblich erschweren können. Begleitet wird der gesamte Entwicklungsprozess von einer umfangreichen, normgerechten Dokumentation des Entwicklungsprozesses und der Software. Es gilt das Motto: „Nur was dokumentiert wurde, wurde auch gemacht.“ Die Gebrauchstauglichkeit wird in mehreren formativen und normativen Usability-Untersuchungen validiert.

Lessons learned: Die Entwicklung eines CDSS als MDSW aus dem akademischen Umfeld heraus stellt eine große Herausforderung dar. Als Hauptfaktoren konnten wir folgende identifizieren:

1.

Die Mitarbeiter*innen im akademischen Umfeld sind häufig Promotionsstudent*innen unmittelbar nach dem Studium. Sie verfügen i.d.R. über wenig Erfahrung. Die Softwareentwicklung innerhalb eines QM-Systems setzt neben den Fachkenntnissen die Kenntnis zahlreicher Standards und Prozesse voraus.

2.

Für die Entwicklung eines Medizinproduktes werden verschiedene Expertisen und Rollen benötigt, wie z.B. Spezialisten für die Anforderungsanalyse, den Usability-Prozess, die Softwarearchitektur, die Implementierung (Programmierung), die Verifikation, die Durchführung von Usability-Tests und das begleitende Risikomanagement. Dies ist standardisiert mit gelenkten Dokumenten zu dokumentieren. In der üblichen Förderung ist dies häufig von einer Person zu übernehmen, die zu Beginn des Projektes in den meisten Feldern über keine oder nur wenig Erfahrung verfügt.

3.

Das primäre Interesse von Promovierenden liegt auf der wissenschaftlichen Arbeit/Promotion und der Promotion der Ergebnisse. Hinzu kommen akademische Aufgaben wie Mitwirkung in der studentischen Lehre oder der akademischen Gremienarbeit. Die Einarbeitung in ein SOP-System und die Durchführung einer Normenkonformen technischen Dokumentation stellt einen Aufwand dar, der im Rahmen einer normalen Drittmittelförderung nicht zu bewältigen ist.

4.

Der Aufwand für die technische Dokumentation und die Erfüllung der Grundlegenden Sicherheits- und Leistungsanforderungen für akademische Prototypen, der in der Krankenversorgung in einer sonstigem klinischen Studie nach Artikel 82 MDR evaluiert werden soll, wird systematisch unterschätzt.

5.

Die Verweildauer von wissenschaftlichen Mitarbeiter*innen in der Akademia ist zur Sicherstellung des Ausbildungsauftrags der Hochschulen durch das Wissenschaftszeitvertragsgesetz bewusst begrenzt. Diese gewollte Personalfluktuation steht im Gegensatz zu der Notwendigkeit die Kompetenzen innerhalb eines QM-Systems für die Softwareentwicklung aufzubauen.

Fazit: Spätestens mit der Gültigkeit der MDR stellt die translationale Forschung im Bereich der MDR eine besondere Herausforderung dar. Die Universitäten müssen entsprechende Strukturen schaffen, mit denen dies umgesetzt werden kann. Dies erfordert eine Sensibilisierung der Forscher*innen bereits bei der Antragstellung, sowie Förderprogramme die diesen Mehraufwand abdecken. In dem Modul 2b-Projekt fit4translation wird der Kompetenzaufbau in der akademischen Community hierzu bearbeitet.