Scripting ist eine Form des Programmierens, bei dem Skriptsprachen wie Python, PHP, JavaScript und VB Script zum Einsatz kommen, also Programmiersprachen, bei denen der Code nicht kompiliert, sondern von einem Interpreter interpretiert wird.
Das Scripting bei Medizinprodukten birgt einige regulatorische Fallen, die Sie unbedingt kennen und vermeiden sollten. Dieser Beitrag gibt Ihnen Tipps dazu.
Einsatzgebiete des Scriptings
Die (Medizinprodukte-) Hersteller setzen Skripts ein beispielsweise
- serverseitig, um einem Client (Browser, App) HTML-Code oder Daten im JSON oder XML-Format über einen Webservice zur Verfügung zu stellen,
- um auf einem Web- oder Mobile-Client auf Aktionen der Benutzer reagieren zu können wie z.B. eingegebene Daten zu validieren oder Daten vom Server nachzuladen,
- um Teile der Funktionalität eines Produkts auszulagern, weil sich diese Funktionalitäten entweder schnell ändern oder sehr kundenspezifisch sind, oder
- um mit Scripting Produkte in Form von Makros zu steuern.
Regulatorische Fallen
Die IEC 62304 unterscheidet nicht zwischen verschiedenen Programmiersprachen und kennt kein Scripting. Die Forderungen der Norm an den Entwicklungsprozess umfassen:
- Kapitel 5.1, Entwicklungsplan: Hier würden Sie die Werkzeuge erwähnen, mit denen Sie Ihre Software entwickeln und testen
- Kapitel 5.2, Software-Anforderungen: Diese sollten unabhängig von der Programmiersprache formuliert sein
- Kapitel 5.3 und 5.4, Software-Architektur: Natürlich können auch für Skriptsprachen Architekturen modelliert werden. Nur viele Hersteller, die Scripting einsetzen, schlampen hier.
- Kapitel 5.5 bis 5.7: Bei der Verifizierung der Software gibt es keine Einschränkung beim Einsatz von Scripting. Hersteller sollten sich nur bewusst sein, dass viele Skriptsprachen keine statische Typisierung haben, was zu Fehlern führen kann, die es eben nur bei Skriptsprachen gibt. In diesem Kontext kommt Kapitel 5.5.4 eine besondere Bedeutung, das die Überprüfung der korrekten Variablen-Initialisierung explizit anspricht.
Medizinproduktehersteller sollten zudem die verschiedenen Einsatzgebiete des Scriptings unterscheiden:
Scripting in der Entwicklung
Sind die Skripts Teil des Medizinprodukts und dazu gedacht, dass die Entwickler(!) Funktionalitäten damit implementieren oder auslagern? Falls ja, unterliegen diese Skripts wie gerade dargestellt dem „normalen Entwicklungsprozess“.
Scripting durch die Kunden
Sind die Skripts dazu gedacht, um von Kunden angepasst zu werden beispielsweise um eigene Geschäftslogik zu implementieren? Falls dies der Fall ist, zählt das Ändern der Skripts zum bestimmungsgemäßen Gebrauch. Dies ist im Risikomanagement ganz genau zu untersuchen:
- Was passiert, wenn ein Kunde einen Algorithmus in einem Skript fehlerhaft implementiert?
- Was passiert, wenn das Skript nicht mehr interpretiert werden kann z.B. wegen Syntaxfehler?
- Kann über das Scripting das Berechtigungskonzept ausgehebelt werden?
- Können über die Skripts Funktionalitäten implementiert werden, die über die Zweckbestimmung des Produkts hinausgehen?
- Was würde passieren, wenn das Skript die Ressourcen (CPU, RAM usw.) über Gebühr belegt oder/und das gesamte Produkt ausbremst?
- Können die Skripts die UI beeinflussen? Falls ja, haben Sie Risiken durch mangelnde Gebrauchstauglichkeit wirklich analysiert und beherrscht?
- Kann es passieren, dass Skripts Risikokontrollmaßnahmen, die Sie bereits implementiert haben, wieder aushebeln?
Je weiter Sie Ihr Produkt durch Scripting für Ihre Kunden öffnen, umso unbeherrschbarer werden damit einhergehende Risiken! Wer nach allen Seiten offen ist, kann nicht mehr ganz dicht sein ;-).
Ihre Kunden sollten zudem die Frage beantworten, ob durch deren eigenes Scripting nicht sogar eine Eigenherstellung erfolgt. Dann müssten diese die Einhaltung der grundlegenden Anforderungen der Medizinprodukterichtlinie nachweisen können.
