Medical Grade Software

„Wir entwickeln Medical Grade Software“, behaupten Hersteller und Entwicklungsdienstleister, ohne zu spezifizieren, was sie unter „Medical Grade“ verstehen. Diese Definition ist wichtig. Nur so lässt sich einschätzen, wie sehr diese Software beitragen kann, um regulatorische Anforderungen zu erfüllen.

1. Beispiele für Medical Grade Software

Es gibt Software, die selbst kein Medizinprodukt ist, aber laut Hersteller als Teil eines Medizinprodukts oder zu anderen Zwecken im Gesundheitswesen eingesetzt werden kann. Allerdings möchten die Hersteller den Einsatz dieser Software regelmäßig nicht auf das Gesundheitswesen beschränken.

Beispiele für solche Software-Produkte sind:

• Software, die aus 2D-Schichtbildern ein 3D-Volumenmodell rendert, das später auch in Medizinprodukten für diagnostische Analysen genutzt werden soll.
• Komponente (z.B. eine dll) zur Bildbearbeitung beispielsweise zur Kantendetektion, die auch in Medizinprodukten z.B. für die Segmentierung und / oder die Bestrahlungsplanung verwendet werden soll.
• Integrationsserver, der verschiedene Kommunikationsprotokolle umwandeln und Informationsflüsse routen kann und auch im medizinischen Kontext eingesetzt werden soll. Beispielsweise um klinische Informationssysteme und Medizinprodukte wie Laborgeräte zu verbinden.
• App, die als Patiententagebuch dient, aber kein Medizinprodukt ist.
• Software, die medizinischen Zwecken dient, aber durch die MEDDEV 2.1/6 bzw. deren Nachfolge-Leitlinie MDCG 2019-11 nicht als Medizinprodukt dient, weil sie z.B. nur der Abspeicherung oder Weiterleitung von (medizinischen) Daten dient.

Gesetzliche Anforderungen an Medizinprodukte wie die MDR greifen bei diesen Software-Anwendungen und Software-Komponenten nicht, wenn wie oben beschrieben, kein medizinischer Zweck festgelegt wurde. Dennoch möchten die Entwickler und Hersteller eine Aussage über die Güte dieser Software-Produkte treffen und sprechen daher oft von „Medical Grade Software„.

Vergleichbare Aussagen kennt man von „Medical Grade PCs“ oder „Medical Grade Hardware“. Auch hier fehlen häufig Definitionen und ein gemeinsames Verständnis dieser Begriffe.

2. Begriffsbestimmungen und Abgrenzungen

Die IEC 82304 definiert den Begriff Gesundheits-Software:

Im Gegensatz zur Gesundheits-Software ist eine Medical Grade Software nicht notwendigerweise speziell für „das Management, die Aufrechterhaltung oder Verbesserung der Gesundheit von Einzelpersonen“ bestimmt.

Unter Medical Grade Software versteht man meist Software, die konform mit den regulatorischen Anforderungen an Medizinprodukte-Software entwickelt wird ohne deshalb notwendigerweise ein Medizinprodukt oder ein Teil dessen zu sein.

Medizinprodukte und Gesundheits-Software müssen zumindest ein „Medical Grade Niveau“ erreichen. Die Anforderungen gehen allerdings über die an eine Software mit dem Anspruch „Medical Grade“ hinaus, wie das nächste Kapitel darlegt.

3. Regulatorische Anforderungen

Da der Begriff „Medical Grade Software“ nicht definiert ist, lassen sich keine konkreten regulatorischen Anforderungen benennen.

Allerdings kann man davon ausgehen, dass der Hersteller mit dem Attribut „Medical Grade“ signalisieren möchte, dass sich die Software für den Einsatz in Gesundheitsanwendungen und sogar Medizinprodukten eignet.

Den Inverkehrbringern der Medizinprodukte muss aber bewusst sein, dass der Hersteller einer „Medical Grade Software“ (MGS) nur einen Teil dieser Anforderungen betreffen kann:

Anforderungen (u.a. Sicherheits- und Leistungsanforderungen)	Nachweis möglich?	Kommentar
Software-Lebenzyklus-Prozesse	Ja	z.B. Konformität mit IEC 62304
Verifizierung der Software	Ja	z.B. Konformität mit IEC 62304
Validierung der Software inkl. klinische Validierung und Usability-Validierung	Nein	Nur das damit erstellte Produkt kann validiert werden.
Risikomanagement	In der Regel nein	MGS-Hersteller kennen meist den technischen und klinischen Kontext nicht ausreichend. Eine FMEA zur Analyse der Auswirkung von Fehlern ist jedoch sinnvoll.
IT-Sicherheit	In großen Teilen ja	Die IT-Sicherheit beinhaltet auch organisatorische Aspekte und ist spezifisch für die Hardware. Beides obliegt nicht MGS-Herstellern.
Datenschutz	Eher nein	Organisatorische Maßnahmen und die rechtlichen Grundlagen für die Datenverarbeitung kann nur der Inverkehrbringer bestimmen. Der MGS-Hersteller kann „nur“ die technischen Voraussetzungen (> IT-Sicherheit) schaffen.
Trainings- und Begleitmaterialien	Nein	Die Begleitmaterialien müssen u.a. die Restrisiken offenbaren. Das liegt in der Verantwortung des Inverkehrbringers.
Post-Market Surveillance	Teilweise	MGS-Hersteller sollten Informationen über ihre Software im Markt sammeln und an die Inverkehrbringer weiterleiten.

Die Anforderungen an eine Software steigen, je eindeutiger sie eine medizinische Zweckbestimmung verfolgt:

Software	Kriterium	Regulatorische Anforderung
Medizinprodukte-Software	Eigener medizinischer Zweck Software unterstützt medizinisches Wirkprinzip	Gesetze zur allgemeinen Produktsicherheit MDR, MDD, … QM-System (Harmonisierte) Normen
Gesundheitssoftware, die keine Medizinprodukte-Software ist	Dient einem medizinischen / gesundheitlichen Zweck, fällt aber nicht unter die Definition des Begriffs „Medizinprodukt“	Gesetze zur allgemeinen Produktsicherheit QM-System IEC 82304 IEC 62304 ISO 14971 IEC 62366-1
Medical Grade Software, die keine Gesundheits-Software ist	Kein eigener medizinischer Zweck unterstützt das technische Funktionsprinzip eines anderen Medizinprodukts	Gesetze zur allgemeinen Produktsicherheit QM-System IEC 62304

4. Kritik und Fazit

a) Wildwuchs an Zertifikaten, Prüfsiegel und Behauptungen

Die MDR benennt die Anforderungen an Medizinprodukte-Software sehr klar. Dennoch fühlen sich weitere Institutionen bemüßigt, weitere Anforderungen und Kriterienkataloge festzulegen, wie diese Beispiele belegen:

• Das DVG verpflichtet das BfArM digitale Gesundheitsanwendungen, welche Medizinprodukte der Klasse I und IIa sind, (nochmals?!?) zu prüfen z.B. auf IT-Sicherheit.
• Die Arbeitsgemeinschaft der Wissenschaftlichen Medizinischen Fachgesellschaften (AWMF) e.V. fordert einen Expertenbeitrag für die Bewertung von Apps (Quelle).
• Die Deutsche Hochdruck-Liga zertifiziert Blutdruck-Apps (Quelle) und vergibt ein Prüfsiegel.
• Die Eidgenossen haben ebenfalls einen Kriterienkatalog erarbeitet (Quelle).
• DNVF-Memorandum – Gesundheits- und Medizin-Apps

Teilweise richten sich diese Kriterienkataloge auch an Software, die kein Medizinprodukt bzw. ein Teil dessen ist.

b) Probleme für Hersteller und Anwender

Diese Flut an Katalogen führt zu konkreten Problemen:

1. Für Patienten wird die Anzahl der Prüfsiegel und Zertifikate immer unübersichtlicher. Das betrifft nicht nur die Menge, sondern auch die Verbindlichkeit und Aussagekraft dieser Siegel und Zertifikate.
2. Für Hersteller bedeuten diese teilweise redundanten Prüfungen und Zertifizierungen zeitlichen und finanziellen Aufwand. Es gilt, spezifische Dokumente zu erstellen und Formulare auszufüllen und Gebühren zu begleichen.
3. Der Scope und die Prüfverfahren (nicht zu verwechseln mit den Prüfkriterien) sind teilweise intransparent oder nicht präzise bestimmt. Das erschwert eine zielgerichtete Vorbereitung.
4. Jedes professionelle Prüfinstitut muss sich selbst prüfen und akkreditieren lassen. Genau diese Hürde scheinen viele selbsternannte „Zertifizierer“ nicht nehmen zu wollen. Die extern überprüfte Qualitätssicherung muss nicht nur für die Hersteller, sondern auch für prüfende Organisationen verpflichtend sein.

Wir sollten darauf achten, dass der Wildwuchs an Zertifikaten und Prüfsiegeln nicht zu einer modernen Wegelagerei unter dem Deckmantel der Patientensicherheit ausartet.

c) Sonderfall Medical Grade Software

Mit noch mehr Vorsicht als die oben genannten Nachweise müssen Aussagen zu „Medical Grade Software“ betrachtet werden. Ohne nachvollziehbare Prüfungen mit spezifizierten und transparenten Prüfkriterien, Prüfverfahren und Prüfergebnissen (idealerweise durch eine akkreditierte Prüforganisation) ist eine Aussage, dass eine Software „Medical Grade“ sei, nur bedingt nützlich.

Hersteller von Medizinprodukten, die solche Software in oder mit Ihren Medizinprodukten einsetzen wollen, sollten auf diese Nachweise drängen oder Alternativen erwägen:

• Die Software unter dem Dach eines zertifizierten QM-Systems (z.B. des eigenen) selbst entwickeln (lassen).
• Den Hersteller der „Medical Grade Software“ mit einer QSV verpflichten, die Software-Entwicklung nach den eigenen Standards zu dokumentieren oder / und Lieferantenaudits zu gestatten.
• Die Medical Grade Software als SOUP deklarieren und im eigenen Produkt verwenden.

Hersteller von Medical Grade Software, die solche Software in oder mit Ihren Medizinprodukten einsetzen wollen, sollten konkret darlegen, was sie unter dem Begriff „Medical Grade“ verstehen und welche Nachweise sie erbracht haben, um diese implizite Qualitätsbehauptung zu untermauern.

Diese Hersteller sollten auch einen nicht-medizinischen Zweck und eine mögliche Verwendung innerhalb eines Medizinprodukts möglichst klar bestimmen.

d) Abgrenzung von Medizinprodukten

Weil „Medical Grade Software“ die Funktionalität eines Medizinprodukts unterstützen soll, kann sie leicht selbst zum Medizinprodukt oder zu einem Zubehör dafür werden. Ob dies der Fall ist, hängt v.a. davon ab, ob sie eher das technische oder eher das medizinische Wirkprinzip des Medizinprodukts unterstützt.

Die MEDDEV 2.1/6 bzw. deren Nachfolge-Leitlinie MDCG 2019-11 helfen bei der Abgrenzung. Falls der Hersteller eine Zweckbestimmung festlegt, die unabhängig von der Domäne „Medizin“ (z.B. ein 3D-Volumen berechnen) oder eher technisch formuliert ist (z.B. eine bestimmte Hardware ansteuern) spricht das dafür, dass die Software als „Medical Grade Software“ zählt, aber nicht als eigenständiges Medizinprodukt.

Dennoch kann sie als „Medizinprodukte-Software“ im Sinne der Leitlinie MDCG 2019-11 klassifiziert werden, die Teil eines Medizinprodukts ist.

e) Fazit

Es sollte keine Rolle spielen, ob man „Medical Grade Software“, „Medizinprodukte-Software“ oder „Software als Medizinprodukt“ entwickelt¹⁾. Hersteller sollten jede Form von Software „anständig“ entwickeln. Die IEC 62304 legt die Untergrenze dessen fest, was man noch als anständig bezeichnen kann.

Transparenz schafft Vertrauen. Das gilt für Software, die den Anspruch „Medical Grade“ hat.

Mit bestem Dank an Robert Dick-Hambeck für Anregungen und Inhalte.
¹⁾ Die Begriffe sind nicht disjunkt.