Parametrisierung von Software

Die Parametrisierung von Software – man spricht in dem Kontext auch von Parametrierung, Customizing oder Konfiguration – führt regelmäßig zu Diskussionen z.B. über die Verantwortlichkeit und über die Abgrenzung zur Eigenherstellung.

1. Parametrisierung: Beispiele

a) Beispiele für Aktivitäten

Viele Software-Anwendungen wie z.B. ERP-Systeme oder Krankenhaus-Informationssysteme müssen bei deren Einführung erst angepasst (z.B. „parametrisiert“) werden, um im Unternehmen genutzt werden zu können. Beispiele für diese Anpassungen sind:

• Rollen und Berechtigungen definieren
• Benutzer anlegen und Rollen zuweisen
• Prozesse definieren und Workflows anpassen
• Schnittstellen konfigurieren
• Die Berechnung von Scores anpassen
• Warnungen festlegen und Alarmgrenzen bestimmen
• Datenbank-Parameter einschließlich Passwörter eingeben

b) Beispiele für typische Schwierigkeiten

Bei diesen Tätigkeiten müssen sich die Beteiligten über Folgendes einig sein:

• Wer ist für die Parametrisierung verantwortlich?
• Liegt noch eine Parametrierung oder bereits eine Eigenherstellung vor?
• Erfolgt die Parametrierung vor oder nach der Inverkehrbringung?
• Agieren die Mitarbeitenden des Herstellers in der Rolle desjenigen, der das Produkt herstellt, oder in der (zusätzlichen) Rolle eines Dienstleisters, der im Auftrag des Betreibers (Unternehmens) die Software parametrisiert?
• Wenn die Software durch Komponenten Dritter oder durch eine Eigenentwicklung ergänzt werden muss, um die benötigte Funktionalität zu gewährleisten: Wer ist für das Zusammenspiel des Gesamtsystems verantwortlich? Wer für dessen Konformität?

2. Definitionen

Die Begriffe Parametrisierung, Parametrierung, Customizing und Konfiguration werden häufig synonym verwendet. Sie sind es aber nicht in allen Fällen.

a) Parametrisierung, Parametrierung

Die Begriffe Parametrisierung und Parametrierung sind Synonyme.

Die Parametrisierung erfolgt innerhalb des vom Hersteller bereitgestellten Funktionsumfangs. Benötigt hingegen der Kunde (Unternehmen, Krankenhaus) zusätzliche Funktionalitäten, bedarf es entweder zusätzlicher Module (s.u.: Konfiguration) oder/und einer zusätzlichen Programmierung.

Entweder programmiert der Hersteller selbst und erweitert dadurch den ursprünglich bereitgestellten Funktionsumfang, oder der Kunde bzw. ein von ihm beauftragter Dritter führt die Programmierung durch (s. Abb. 1).

b) Konfiguration

Der Begriff Konfiguration wird jedoch unterschiedlich definiert. Die obige Definition stammt aus dem Konfigurationsmanagement. Es gibt kein allgemeines Verständnis, wie breit dieser Begriff verstanden werden soll:

• Nur Freischalten von vom Hersteller entwickelten Modulen
• Zusammenstöpseln der Module, die vom Hersteller stammen und von diesem auch vorgesehen sind
• Zusammenstöpseln der Module, die vom Hersteller vorgesehen sind unabhängig davon, von wem sie stammen
• Zusammenstöpseln von Module unabhängig davon, ob diese auch vom Hersteller dafür vorgesehen sind

c) Customizing

Das Customizing umfasst alle der oben genannten Maßnahmen. Es geht um das Anpassen der Software an die Bedürfnisse des Kunden (daher „Customizing“) unabhängig davon, wie diese Anpassung erfolgt.

3. Typische Fallen

Falle 1: Unklare Absprachen

Regelmäßig gelingt es den Herstellern nicht, die Kundenanforderungen durch ein standardisiertes Produkt zu erfüllen. Daher sehen sie sich gezwungen, eher einen Baukasten zu entwickeln, mit Hilfe dessen die Software durch Parametrisierung, Konfiguration und Sonderentwicklungen – sprich Customizing – erst erstellt wird.

Damit laufen die Hersteller und Kunden Gefahr, dass wichtige Fragen unbeantwortet bleiben:

• Abgrenzung Produkt
  Was ist das Produkt, das der Kunde kauft bzw. das der Hersteller in den Markt bringt? Ist die Konfiguration beim Kunden noch Teil der Entwicklung oder entspricht sie bereits einer Nutzung des Produkts im Rahmen dessen Zweckbestimmung?
• Medizinprodukt?
  Ist das vom Hersteller ausgelieferte Produkt (überhaupt noch ein) Medizinprodukt oder eher eine Sammlung an Modulen und Werkzeugen, um ein Medizinprodukt damit zu erstellen?
• Inverkehrbringung versus Eigenherstellung
  Gibt es überhaupt noch einen Medizinproduktehersteller oder liegt eine Eigenherstellung vor oder gar beides?
• Verantwortlichkeiten
  Sind Entwicklungsaktivitäten, die Mitarbeiter des Herstellers durchführen, Entwicklungen des Herstellers und sind somit die Ergebnisse Teil des ausgelieferten Produkts? Oder sind diese Aktivitäten als Dienstleistungen zu betrachten, die die identischen Personen im Auftrag des Kunden durchführen?

Falle 2: Parametrisierung wird zur Eigenherstellung

Übernimmt das Unternehmen die Aufgabe, das Softwaresystem zu parametrisieren, muss es darauf achten, dass es das Produkt im Rahmen der vom Hersteller vorgesehenen Zweckbestimmung nutzt. Andernfalls nimmt es eine Eigenherstellung vor und übernimmt damit vom Hersteller die Verantwortlichkeit, die regulatorischen Anforderungen zu erfüllt.

Diese Abgrenzung wird immer dann schwierig, wenn die Hersteller die Zweckbestimmung nicht präzise festlegen. Wenn beispielsweise der Hersteller das Produkt mit der Möglichkeit versieht, es durch Skripts zu erweitern: Ist dann ein in dieser Skript-Sprache entwickelter Algorithmus zur Kontraindikationsprüfung durch die Konformitätserklärung des Herstellers abgedeckt?

Wenn das Produkt im Rahmen seiner Zweckbestimmung eingesetzt wird, fallen die Parametrisierung und Konfiguration unter das, was die ISO 13485 als Installation bezeichnet. Die Anforderungen der ISO 13485 an die Installation sind zu beachten.

Falle 3: Update-Fähigkeit geht verloren

Je standardisierter ein Produkt ist und bleibt, desto leichter fällt es dem Hersteller dafür Updates, Upgrades und Patches zu entwickeln. Jede Parametrisierung, jede Konfiguration und jede Sonderentwicklung erhöhen die Komplexität und damit die Schwierigkeit, Updates zu entwickeln, zu testen und beim Kunden zu installieren.

All dies erhöht die Aufwände und damit den Preis. Eine Sonderentwicklung kostet einmalig Geld. Die Regressionsprüfung dieser Lösung ggf. dauerhaft.

Daher sollten die Betreiber sorgfältig abwägen, wie sehr sie auf „Sonderlösungen“ bestehen. Diese haben regelmäßig für beide Seiten Nachteile:

• Für die Hersteller, weil deren Aufwände für die Pflege alter Versionen steigen
• Für die Betreiber, weil die diese Aufwände letztlich bezahlen müssen und Gefahr laufen, wegen eines nicht-upgradebaren Produkts mit alten und weniger leistungsfähigen Versionen arbeiten zu müssen.

Falle 4: Nichterfüllen regulatorischer Anforderungen

Wenn ein Hersteller ein Medizinprodukt maßgeschneidert für einen Kunden entwickelt und es dieses Produkt nur einmal gibt, so ist es dennoch ein Medizinprodukt, das alle regulatorischen Anforderungen erfüllen muss. Dazu zählt insbesondere der Nachweis der grundlegenden Anforderungen:

• Software-Lebenszyklusprozesse
  Die Software-Entwicklung ist möglicherweise nicht auf die Räumlichkeiten des Herstellers beschränkt, sondern dehnt sich auf die des Kunden aus.
• Risikomanagement
  Der Hersteller muss die Risiken nicht nur des Baukasten, sondern alle Risiken betrachten. Das schließt die Risiken ein, die sich durch die spezielle Zweckbestimmung, Funktionalitäten und Architektur des Produkts ergeben.
• Usability
  Speziell wenn durch das Customizing spezifische oder neue User Interfaces und Benutzungsszenarien entstehen, müssen diese ebenfalls im Rahmen einer formativen oder summativen Usability-Bewertung unterzogen werden. Das findet meist nicht statt.
• Labeling
  Es gibt kein Gesetz, das besagt, dass die Anforderungen z.B. an die Existenz und Vollständigkeit von Handbüchern für Produkte, die nur einmal verkauft werden, nicht gelten. Ein Handbuch, das nur beschreibt wie man den „Baukasten“ verwendet, aber nicht das ganze Produkt, erfüllt wahrscheinlich nicht die Anforderungen bezüglich Vollständigkeit.

Die grundlegenden Anforderungen – die MDR spricht von „grundlegenden Sicherheits- und Leistungsanforderungen – gelten für Eigenherstellungen genauso für wie für alle anderen Medizinprodukte.

Zusätzlich zu diesen Anforderungen sollten sich Unternehmen, die Software-Systeme betreiben, auch der möglichen Pflicht zur Computerized Systems Validation bewusst sein, wie sie z.B. die ISO 13485:2016 fordert und der GAMP 5 beschreibt.

Falle 5: Zu hohe Flexibilität

„Wer nach allen Seiten offen ist, kann nicht mehr ganz dicht sein“, so lautet ein zynisches Bonmot. Dieses trifft die Situation vieler Hersteller: Sie wollen sich für alle möglichen Situationen und Kundenanforderungen wappnen. Daher vertagen sie möglichst viele Festlegungen und Spezifikationen auf später, in dem sie jeden Parameter einstellbar gestalten.

Genau diese Flexibilität fällt ihnen später auf die Füße: Die kombinatorische Vielfalt an Parametern ist nicht mehr beherrschbar. Der Abdeckungsgrad beim Testen kollabiert, und Qualitätsprobleme sind im wahrsten Sinne des Wortes „vorprogrammiert“.

4. Fazit und Zusammenfassung

Produkte, insbesondere Software-Anwendungen, die in weiten Grenzen parametrisiert werden können, zeichnen sich durch eine hohe Flexibilität aus. Gleichzeitig lassen Sie die Grenzen zwischen Entwicklung und Anpassung verschwimmen. Dies birgt Risiken für die regulatorische Compliance und für die Sicherheit der Patienten, Anwender und Dritter.

Auch deshalb sollten Kunden wie Krankenhäuser es nicht als Sieg feiern, wenn sie ihren Hersteller zu einer weiteren Sonderlösung gezwungen haben. Diese hat ihren Preis, den sie wissentlich oder nichtwissentlich mitbezahlen werden.

Je weniger standardisiert Hersteller ihre Produkte ausliefern, desto mehr müssen sie auf Folgendes achten:

• Exakte Spezifikation dessen, was das ausgelieferte Produkt ist
• Präzise Festlegung der Zweckbestimmung des Produkts (und nicht nur dessen Funktionalität)
• Klarheit darüber, an welcher Stelle die Entwicklung endet und wann die Parametrisierung beginnt
• Einheitliches Verständnis zwischen Hersteller und Kunde, welche Tätigkeiten im Rahmen der Entwicklung stattfinden und welche als Dienstleistung im Auftrag der Kunden zu verstehen sind

Es ist absurd, dass Hersteller durch immer umfangreichere regulatorische Anforderungen und durch die benannten Stellen gezwungen werden, sichere Produkte zu entwickeln, und gleichzeitig deren Kunden fast unbehelligt von Behörden diese Produkte in großem Umfang an ihre Bedürfnisse anpassen.

Hersteller sollten sich dadurch absichern, indem sie durch gesetzeskonforme Verifizierungen und Validierungen nachweisen, dass sich das Produkt bei der Auslieferung spezifikationsgemäß verhielt. Damit kann man Ihnen nicht Fehler zu Last legen, die durch die Betreiber verursacht wurden.

Für Patienten ist es allerdings unerheblich, ob das Produkt unsicher ist, weil der Hersteller es bereits unsicher ausgeliefert hat, oder weil der Betreiber das Produkt durch eine fehlerhafte Parametrisierung unsicher gemacht hat.