Medical Grade Software

Dienstag 10. Dezember 2019

„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.

Hersteller werben mit dem Attribut „Medical Grade Software“. Zudem schießen neue Prüfsiegel und „Zertifikate“ aus dem Boden.

Als Inverkehrbringer eines Medizinprodukts sollten Sie vorsichtig sein, um eine versehentliche „Non Compliance“ und unnötige Aufwände zu vermeiden z.B. wenn Sie „Medical Grade Software“ in Ihrem Medizinprodukt verwenden wollen.

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.
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Klassifizierung von Software als Medizinprodukt.

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:

Definition: Gesundheits-Software
„Software, die speziell für das Management, die Aufrechterhaltung oder Verbesserung der Gesundheit von Einzelpersonen oder für die Pflege bestimmt ist.“
Quelle: DIN EN IEC 82304-1:2018-04

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.

Medical Grade Software sind Software-Anwendungen oder Komponenten, die auch, aber nicht ausschließlich für einen medizinischen Zweck genutzt werden sollen.
Abb. 1: Medical Grade Software sind Software-Anwendungen oder Komponenten, die auch, aber nicht ausschließlich für einen medizinischen Zweck genutzt werden sollen.

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.

Weiterführende Informationen

Die Definitionen der Begriffe „Software as Medical Device“ und „Medizinprodukte-Software“ (Medical Device Software) finden Sie im Artikel „Software als Medizinprodukt“.

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:

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“ entwickelt1). 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.
1) Die Begriffe sind nicht disjunkt.

War dieser Artikel hilfreich? Bitte berwerten Sie:
1 vote, average: 4,00 out of 51 vote, average: 4,00 out of 51 vote, average: 4,00 out of 51 vote, average: 4,00 out of 51 vote, average: 4,00 out of 5

Autor des Beitrags " Medical Grade Software

Johner Institut Gmbh

Logo Johner Institut klein

Bewertung 4 von 5 bei 1 Bewertungen


Kategorien: Regulatory Affairs, Software & IEC 62304

Kommentar schreiben