Parametrisierung von Software

Dienstag 12. Februar 2019

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.

Dieser Artikel gibt Herstellern und deren Kunden wichtige Hinweise, auf was sie bei der Parametrisierung achten sollten und wie sie die üblichen Fallen vermeiden können.

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?
Vorsicht!

Wenn die Rollen und Verantwortlichkeiten nicht geklärt d.h. die o.g. Fragen nicht beantwortet sind, erhöhen sowohl der Hersteller als auch die Unternehmen ihre rechtlichen Risiken. Dies gilt zivilrechtlich (beim Streit miteinander) als auch strafrechtlich (z.B. bei Verstößen gegen das MPG oder die MPBetreibV).

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

Definition: Parametrisierung, Parametrierung
„Parametrisierung von Software: die Anpassung einer Software an den gewünschten Funktionsumfang durch setzen von Parametern.“
Quelle: Johner Institut und weitere

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

Parametrisierung einer Software in Abgrenzung zur Erweiterung (zum Vergrößern klicken)
Abb. 1: Parametrisierung einer Software in Abgrenzung zur Erweiterung

b) Konfiguration

Definition: Konfiguration
„Unter Konfiguration versteht man, das Zusammenstellen einer Software aus verschiedenen Modulen und dem „Verknüpfen“ dieser Module. Diese Module stammen vom Hersteller des Softwaresystems oder von Dritten (z.B. Plugins) oder sie wurden maßgeschneidert entwickelt.“
Quelle: Johner Institut
Konfiguration eines Software-Systems aus Modulen (zum Vergrößern klicken)
Abb. 2: Konfiguration eines Software-Systems aus Modulen

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.

Das Customizing umfasst die Parametrisierung, die Konfiguration und die Erweiterung durch Spezialentwicklungen. (zum Vergrößern klicken)
Abb. 3: Das Customizing umfasst die Parametrisierung, die Konfiguration und die Erweiterung durch Spezialentwicklungen.

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?

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Eigenherstellung und der Abgrenzung zur Inverkehrbringung.

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.

Weiterführende Informationen

Lesen Sie hier mehr zur Computerized Systems Validation CSV, den entsprechenden regulatorischen Anforderungen und einigen Best Practice Guides wie IEC 80002-2 und AAMI TIR 36.

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

Tipp

Die Parametrisierung darf nicht missbraucht werden, um ein systematisches Requirements Engineering zu ersetzen.

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.

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Kategorien: Health IT & Medizintechnik, Regulatory Affairs, Software & IEC 62304
Tags: , , , ,

4 Kommentare über “Parametrisierung von Software”

  1. Andreas P schrieb:

    Ein sehr interessanter Artikel.
    Software ist an sich schon sehr schwer zu managen, da es eben nichts physisches ist und schnell verändert/angepasst werden kann. Es scheint nahezu unmöglich eine solch offene Thematik in die engen regulatorischen Vorschriften der Medizintechnik zu pressen.
    Ich komme selbst aus der IT und habe ERP-System für Kunden programmiert, bevor ich in die Medizintechnik umstieg. Wie Sie schon schreiben, ist die Parametrisierung wahnsinnig komplex, da man es jedem Kunde recht machen will.
    Allerdings sehe ich es so, dass Erweiterungen/Plugins durch Dritte wie SOUP zu behandeln sind. Die 62304 sieht dafür Vorgehensweisen vor. Mitunter sollten diese Plugins also individuell geprüft und inverkehrgebracht werden.

    Beste Grüße
    Andreas P

  2. Prof. Dr. Christian Johner schrieb:

    Danke für Ihren wertvollen Gedanken!

    Ich stimme Ihnen absolut zu, dass Erweiterungen wie SOUPs behandelt werden können. Alternativ ist eine Entwicklung auch unter dem Dach des QM-Systems des (Eigen-)Herstellers denkbar.

    Viele Grüße, Christian Johner

  3. Peter Brandstetter schrieb:

    Interessanter Artikel, allerdings sehe ich die Unterscheidung zwischen Parametrierung und Entwicklung nicht generell zielführend. Ein einfaches Programm kann weniger Risiko eines Fehlverhaltens haben als eine komplexere Parametrierung.
    Eine Risikobetrachtung aller im speziellen Einsatzfall angewendeten Möglichkeiten eine Software anzupassen sollten betrachtet und bewertet werden.

    lg,

    Peter Brandstetter

  4. Prof. Dr. Christian Johner schrieb:

    Sehr geehrter Herr Brandstetter,
    danke für Ihre Gedanken!

    Ich stimme Ihnen völlig zu, dass ein einfaches Programm fehlerfreier funktionieren kann als ein komplexes parametriertes. Man würde damit verschiedene Komplexitäten vergleichen.

    Regulartorisch wichtig ist meines Erachtens die Unterscheidung zwischen einer Parametrierung, die üblicherweise im Rahmen der Zweckbestimmung erfolgt, und der Entwicklung, die das nicht ist.

    Nochmals besten Dank!

    Viele Grüße, Christian Johner

Kommentar schreiben