gms | German Medical Science

Einleitung: Seit der Publikation von Han et. al. [1] ist bekannt, dass die Einführung und die Anwendung von IT-Systemen in der Medizin nicht nur die Patientensicherheit verbessern kann, sondern auch mit Risiken für die Patientensicherheit verbunden ist. Für Software, die entsprechend der Europäischen Richtlinie (93/42/EWG) oder dem Medizinproduktegesetz (MPG) als Medizinprodukt zu klassifizieren ist (Software as a Medical Device, SaMD), gibt es entsprechende Verordnungen und Normen, die das Risikomanagement auf Herstellerseite (EN ISO 14971 "Anwendung des Risikomanagements auf Medizinprodukte" in Zusammenspiel mit der DIN EN 62366 "Anwendung der Gebrauchstauglichkeit auf Medizinprodukte" und der DIN EN IEC 62304 "Medizingeräte-Software - Software-Lebenszyklus-Prozesse") und auf Betreiberseite (Medizinprodukte Betreiberverordnung (MPBetreibV), Medizinprodukte Sicherheitsplanverordnung (MPSV), DIN EN IEC 80001-1) regelt. Bei der Veränderung von Software müssen folgende Fehlermöglichkeiten unterstellt werden:

• Unerkannte Veränderungen in der Funktionalität können den Anwender zu einer unbeabsichtigten Fehlbenutzung führen. (Anwenderfehler)
• Eine neu aufgetretene Inkompatibilität mit anderer Software oder anderen Softwarekomponenten kann zu einem fehlerhaften Systemverhalten führen
• Eine erforderliche Anpassung (Parametrierung) wird nicht oder nicht korrekt ausgeführt. Dadurch werden entweder nützliche Features nicht genutzt oder das System verhält sich fehlerhaft.
• Neue aufgetretene Fehler oder Seiteneffekte sind den Anwendern nicht bekannt und können von diesen nicht antizipiert und / oder kompensiert werden.

Aus diesem Grund sind Anwender und Betreiber (vertreten durch die Systembetreuer) auf Informationen durch die Hersteller angewiesen. Die Bereitstellung der Informationen wird durch die DIN EN ISO 80001 und 62304 gefordert, aber nicht hinreichend spezifiziert.

Das Ziel dieser Arbeit ist, einen Entwurf für eine einheitliche Versionierung von SaMD, sowie Mindestanforderungen für die Dokumentation (Releasenotes) als Diskussionsgrundlage zu erstellen.

Material und Methoden: Basierend auf eigenen Erfahrungen als Anwender und Systembetreuer von klinischen Informationssystemen und vernetzten Medizingeräten, sowie durch Fehleranalysen im Bereich von Beratungen und Gutachten, haben die Autoren die Auswirkungen von Änderungen in der Software aus erster Hand erfahren. Diese Fehler wurden kategorisiert und dahingehend analysiert, welche Informationen aus Perspektive der Betreiber erforderlich sind. Basieren auf diesen Erfordernissen wurden allgemeine Anforderungen, sowie zwei Lösungsvorschläge für den Aufbau der Releasenotes und die Versionsnummerierung definiert. Dies erfolgte in Anlehnung an die ISO / IEC 12207 [2]: “For each software item and its versions, the following shall be identified: the documentation that establishes the baseline; the version references; and other identification details.”

Ergebnisse: Erfordernisse: Aus Sicht der Systembetreuer sind u.a. folgende Fragen zu beantworten: Welche Änderungen an der Software vorgenommen? Gibt es Änderungen, die neue Software oder Hardware Anforderungen erfordern? Was muss an der Konfiguration (zwingend) geändert werden? Welche Veränderungen gibt es an der Benutzerschnittstelle / im Verhalten der Software? Welche Maßnahmen zur Information oder Schulung der Anwender werden empfohlen? Welche Restrisiken bestehen? Welche (kritischen) Fehler sind bekannt, mit welchen technischen oder organisatorischen Maßnahmen können diese beherrscht werden?

Allgemeine Anforderungen: Mit jeder Versionsänderung ist das Handbuch zu aktualisieren. Zusätzlich sollten zu jeder Änderung Release Notes mit einer detaillierten Beschreibung aller Änderungen am Produkt einschließlich aller für die Risikobewertung erforderlichen Informationen zur Verfügung gestellt werden. Handbuch und Releasenotes sind ein jeweils eigenes, in sich geschlossenes Dokument, damit sich Systembetreuer und geschulte Anwender die Informationen ohne Verweis auf andere Dokumente erschließen können. Dies könnte über ein signiertes Dokument (z.B. PDF) mit dem Tag der Veröffentlichung erfolgen.

Klassifikation von Versionswechseln und Nummerierung der Versionen: Um den Umfang des Versionswechsels aus der Perspektive des Systembetreuers schnell erkennen zu können wird folgende Klassifikation vorgeschlagen:

• Upgrade: Ein Upgrade ist ein Versionswechsel, bei dem ein Rollback zu einer früheren Version nicht oder nur mit großen Aufwand oder unter Datenverlust möglich ist.
• Major Update: Es sind erhebliche Konfigurationsanpassungen oder Anwenderschulungen erforderlich
• Minor Update: Es sind kleinere Konfigurationsanpassungen oder eine Information der Anwender erforderlich
• Patch: Sammlung von Softwareänderungen, die weder Konfiguration noch eine Anwenderinformation oder Anwenderschulung erfordern. (Meist Fehlerbehebung)
• Hotfix: Ein Patch der kritische Fehler beseitigt.

Ein Hinweis an die Systembetreuer und Betreiber interne Prozesse zu verkürzen um Fehler durch eine verzögerte Implementierung der neuen Version zu vermeiden.

Es wird vorgeschlagen, eine Fünfstellige Versionsnummer mit <Upgrade>.<Major Update>.<Minor Update>.<Patch>.<ReleaseInfo> zu verwenden, wobei die ReleaseInfo auf die eindeutige Nummer in dem Versionsverwaltungssystem der Softwareentwickler verweist um ggf. diese Version wieder herstellen zu können.

Mindestanforderungen und Strukturempfehlung für die Releasenotes: Insgesamt wurden 29 Punkte aufgeteilt in 4 Kapitel definiert [3].

Diskussion: Die Empfehlungen in diesem Beitrag sind als Vorschlag zu verstehen, die in den Fachgesellschaften und Normungsgremien aus der Hersteller, Betreiber und Anwenderperspektive kritisch hinsichtlich Vollständigkeit, und potentiellen Nutzern und Aufwand diskutiert werden sollten. Die Klassifikation des Versionswechsels stellt eine weiterführende Präzisierung der Definitionen in den Musterverträgen (EVB-IT) des Bundesamt für Sicherheit in der Informationstechnik (BSI) und den ITIL Release Arten [4] aus der Perspektive der Betreiber und Systembetreuer dar. Die Offenlegung von bekannten Fehlern einschließlich der Empfehlung von technischen und organisatorischen Maßnahmen zur Risikominimierung stellt eine wesentliche Maßnahme für die Patientensicherheit dar, wird aber nur unzureichend genutzt. Dies sollte den gesamten "normalen Gebrauch", also auch die unbeabsichtigte Fehlbedienung durch die Anwender umfassen [5]. Daher sind Releasenotes für jede neue Version der Software Verfügbar zu machen, die bei neu aufgetretenen Fehlern entsprechend zu aktualisieren sind.

Mit Issue-Tracking-Systemen, Softwareentwicklungsframeworks und Projektmanagement-Toolkits könnten die entsprechenden Dokumente für die Release-Informationen einschließlich der bekannten Fehler halbautomatisch erzeugt und so der Erstellungsaufwand begrenzt werden. Daher sind die Autoren überzeugt, dass sich der erhöhte Aufwand für die Releasenotes durch eine schnelleres Rollout in den Kliniken, geringere Fehlerhäufigkeit im Betrieb und den damit verbundenen Risiken und Supportkosten wirtschaftlich rechnet.

Erklärung: Der Beitrag wurde bereits auf dem Medical Informatics Europe 2015 vorgestellt [3].