Autonome Systeme: 4 Vorteile für Medizinproduktehersteller

Zunehmend finden autonome Systeme auch in der Medizin Verwendung. Zu diesen autonomen Systemen zählen einzelne Medizinprodukte wie OP-Roboter. Aber auch Kombinationen einzelner (Medizin-)Produkte bilden autonome Systeme.

Vielen Medizinprodukteherstellern und Krankenhäusern ist nicht klar,

• welche Chancen ihnen diese autonomen Systeme bieten,
• welche regulatorischen Anforderungen sie dabei beachten müssen,
• welche Risiken sie beherrschen müssen, die bei vielen anderen Produkten nicht relevant sind.

1. Was sind autonome Systeme?

a) Beispiele

Zu den meistgenannten Beispielen für autonome Systeme zählen selbstfahrende Autos. Sie sind in der Lage, unabhängig vom Eingreifen eines Menschen das Fahrzeug sicher zu einem Ziel zu steuern.

Auch Haushaltsroboter sowie viele Industrieroboter zählen zur Klasse der autonomen Systeme.

In der Medizin existieren ebenfalls autonome Systeme, beispielsweise

• OP-Roboter wie das Da-Vinci-Operationssystem,
• Künstliche Bauchspeicheldrüsen, d.h. Systeme, die selbstständig die Insulinlevel im Körper regeln (Artikel zum künstlichen Pankreas)
• Systeme aus Infusionspumpen und Sensoren, die die richtige Dosis an Schmerzmitteln infundieren (s. Abb. 2).

Wer mehr über diese Systeme erfahren will, dem seien die Publikationen Autonomous Systems in Anesthesia: Where Do We Stand in 2020? A Narrative Review und Robotic anesthesia: not the realm of science fiction any more empfohlen.

b) Definition

Ein System wird als autonom bezeichnet, wenn es ohne menschliche Steuerung oder detaillierte Programmierung ein vorgegebenes Ziel selbstständig und an die Situation angepasst erreichen kann.

Quelle: Fachforum Autonome Systeme im Hightech-Forum: Autonome Systeme – Chancen und Risiken für Wirtschaft, Wissenschaft und Gesellschaft. Langversion, Abschlussbericht, Berlin, April 2017

Es gibt auch andere Definitionen, denn „autonom“ heißt erst einmal nur unabhängig von oder eigenständig. Die jeweiligen Definitionen spiegeln immer das wieder, was bei einem bestimmten System gerade wichtig ist, beispielsweise

• selbstständiges Nachladen bei mobilen Robotern,
• Fliegen ohne detektierbare Fernsteuerungssignale bei militärischen Drohnen.

Ein wesentliches Merkmal von autonomen Systemen ist ihre Fähigkeit zur Adaption. Das heißt, dass sie sich selbstständig an verschiedene Situation anpassen können.

c) Abgrenzung zur Automatisierung

Bei Automatisierung betrachtet man den Ersatz, bei Autonomie eher die Unabhängigkeit. Der Begriff „automatisiertes Fahren“ weist darauf hin, dass das Fahren automatisiert wurde. Der Begriff „autonomes Fahrzeug“ weist darauf hin, dass das Fahrzeug unabhängig vom Fahrer ist.

Allgemein gilt aber, dass autonome Systeme in der Lage sind, auch in komplexen und sich ändernden Umgebungen selbstständig zu arbeiten. Dies ist bei klassischer Vollautomatisierung nicht der Fall:

• Ein Industrieroboter, der programmiert wurde, um ein Bauteil auf ein Förderband zu legen, handelt vollautomatisch. Er ist kein autonomes System nach der obigen Definition.
• Ein Industrieroboter, der eigenständig Bauteile sucht und diese an Autos montiert, auch wenn es verschiedene Autos sind oder die Autos unterschiedlich positioniert sind und sich Menschen im Arbeitsbereich des Roboters aufhalten, handelt autonom. Er ist ein autonomes System.

d) Abgrenzung von Closed-Loop-Systemen

Viele autonome Systeme beinhalten geschlossene Regelkreise. Die populären Bezeichnungen „Sense Understand Decide Act“ (SUDA), „Monitor Analyze Plan Act – Knowledge (MAPE-K) oder „Cognitive Loop“ zielen alle auf folgende Schritte des Regelkreises ab:

• Situation wahrnehmen
• Vorhersage machen
• Entscheidung treffen
• Entscheidung umsetzen

Im Gegensatz zum „klassischen“ Closed-Loop-System sind beim autonomen System die Regeln für die Vorhersage und Entscheidung häufig nicht so starr bzw. nicht so explizit formuliert, d.h. programmiert. Regelmäßig kommen Verfahren des maschinellen Lernens zum Einsatz.

Zudem sind autonome Systeme meist auch vernetzte Systeme, weil verteilte Sensorik oft vorteilhaft ist, um ein hinreichendes Situationsverständnis zu erlangen. Das ist bei Closed-Loop-Systemen nicht notwendigerweise der Fall.

2. Spezifische Risiken autonomer Systeme

a) Risiken durch die Autonomie der Systeme

Autonome Systeme arbeiten unabhängig von beispielsweise menschlichem Eingreifen. Damit geht oft auch die Möglichkeit verloren, überhaupt eingreifen zu können. Dies erhöht die Wahrscheinlichkeit, dass ein Fehler des Systems unentdeckt bleibt und zu einem Schaden führt.

b) Risiken durch verschiedene technische Kontexte

Autonome Systeme sind adaptiv. Sie sollen also in der Lage sein, sich an verschiedene Kontexte anzupassen. Diese Kontexte unterscheiden sich u.a. durch technische Aspekte:

• Güte (Bandbreite, Latenz, Verfügbarkeit) und Art (verschiedene Protokolle, kabelgebundene versus kabellose Netzwerkanbindung)
• Art der Produkte, die Teil des Systems sind (z.B. verschiedene Modelle verschiedener Hersteller, verschieden konfigurierte Produkte eines Herstellers)
• Anzahl der Produkte, die Teil des autonomen Systems sind. Diese Anzahl kann sich dadurch ändern, dass der Betreiber Produkte hinzufügt oder entfernt.
• Produkte können auch wegen technischer Probleme des Netzwerks oder des Produkts selbst ausfallen, nicht mehr verfügbar sein oder nicht mehr die versprochene Leistung erzielen.
• Physikalische Umgebung (Helligkeit, Feuchtigkeit, Lärm, Schmutz u.a.)

c) Risiken durch verschiedene klinische Kontexte

Autonome Systeme sollten sich auch in den unterschiedlichen klinischen Kontexten sicher verhalten. Attribute dieser klinischen Kontexte sind:

• Anzahl, Verfügbarkeit und Ausbildung des Personals
• Mentaler Workload, Stress (z.B. durch Alarme, Schichtbetrieb, Schichtwechsel, Notfälle)
• Anzahl und Gesundheitszustand der Patienten
• Verfügbarkeit von Hilfsmitteln, Medizinprodukten und anderen Systemen

d) Risiken durch adaptive Algorithmen

Viele autonome Systeme erlangen die Fähigkeit, sich an die verschiedenen Kontexte anzupassen, indem sie adaptive Algorithmen der künstlichen Intelligenz verwenden.

e) Risiken durch mangelnde Interoperabilität

Wenn (Medizin-)Produkte zu einem (autonomen) System verbunden werden, steigt die Zahl der Schnittstellen überproportional. Insbesondere auf Ebene der semantischen Interoperabilität gibt es regelmäßig Probleme. Deshalb drängt die FDA auf die Verwendung internationaler Standards.

f) Fazit

In der Stärke der autonomen Systeme, nämlich mit variablen Kontexten umgehen zu können, liegt auch ihre Schwäche:

Die kombinatorische Explosion an Situationen ist sowohl für die Hersteller als auch die Betreiber autonomer Systeme nur schwer zu überblicken. Hersteller können zum Zeitpunkt der Entwicklung noch nicht alle künftigen Kontexte kennen. Die Betreiber wiederum verfügen nicht über alle notwendigen Informationen, um Produkte zu Systemen zu kombinieren.

3. Lösungsansätze zur Beherrschung der Risiken autonomer Systeme

a) Naiver Ansatz: Worst Case

Der nächstliegende Ansatz, um die Risiken zu bewerten und später zu beherrschen, besteht darin, für die verschiedenen Kontexte Worst-Case-Szenarien anzunehmen. Beispiele sind:

• Die Patienten sind in einem kritischen Zustand.
• Das Personal ist nicht in der Lage einzugreifen.
• Im System fallen ein oder mehrere Produkte aus.
• Ein oder mehrere Produkte liefern Daten am Rande des Spezifikationsbereichs.
• Das Netzwerk verfügt nicht mehr über die notwendige Bandbreite.
• Die Anwender konfigurieren die Systeme fehlerhaft.

Solch eine Worst-Case-Annahme führt regelmäßig zu nicht akzeptablen Konsequenzen:

• Das autonome System darf nicht in den Verkehr gebracht oder in Betrieb genommen werden.
• Die Leistungsanforderungen an die Produkte müssen so hochgeschraubt werden, dass die Kosten das Produkt wettbewerbsunfähig machen.
• Der Anwendungsbereich muss so eingeschränkt werden, dass der Nutzen des autonomen Systems − nämlich seine Fähigkeit zur Adaption − kaum noch zum Tragen kommt.

b) Modellbasiertes dynamisches Risikomanagement

Kontextabhängige Entscheidungen

Modellbasierte Ansätze (insbesondere ein modellbasiertes dynamisches Risikomanagement) versuchen, diese Konsequenzen zu vermeiden. Dies erfolgt, indem sie die Entscheidung über die Akzeptanz von Fehlern und Fehlverhalten kontextabhängig bewerten. Die folgenden Beispiele sollen dies illustrieren:

• Ein Blutdruck, der bei einem stabilen Patienten um 5 mm Hg ungenau ist, mag akzeptabel sein. Bei einem Intensivpatienten, dessen Medikamente abhängig vom Blutdruck gesteuert werden, hingegen nicht.
• Ein versehentlich vom Finger abgerutschter Sauerstoffsensor stellt möglicherweise kein Problem dar, wenn gleichzeitig die Atemluft über einen weiteren Sensor überwacht wird. Falls dieser zweite Sensor jedoch fehlt, ist eine Alarmierung unabdingbar.

Um solche kontextabhängigen Entscheidungen zu treffen, müssen alle notwendigen Informationen sowohl zu den einzelnen Produkten als auch dem Kontext vorliegen.

Schnittstellen, Modelle und Domain Specific Languages (DSL)

Dies wiederum erfordert einen standardisierten, produkt- bzw. herstellerübergreifenden Datenaustausch und damit gemeinsame Datenmodelle.

Mit domänenspezifischen Sprachen (domain specific languages, DSL) gelingt es, genau diese Datenmodelle und damit Schnittstellen zu beschreiben.

Über diese Schnittstellen kommunizieren die einzelnen Produkte, die Teil eines autonomen Systems sind, nicht nur ihre Werte (z.B. Sensordaten) und Anweisungen. Die Produkte geben auch Informationen über sich selbst weiter, z.B. ihren Zustand und die Verlässlichkeit bzw. Unsicherheit der kommunizierten Werte.

Das Fraunhofer IESE hat solche Sprachen und zugehörige Werkzeuge (u.a. für MagicDraw und Enterprise Architect) entwickelt. Die Beschreibungssprache zur Verlässlichkeit basiert auf einem Standard der Object Management Group (OMG) und wurde Open Source veröffentlicht.

Entscheidungsinstanz

Wenn alle (safety-relevanten) Informationen von allen Produkten und zum jeweiligen Kontext vorliegen, bedarf es einer (meist zentralen) Entscheidungsinstanz. Diese

• prüft, ob die Annahmen zum medizinischen Kontext erfüllt sind,
• prüft, wie vollständig die technischen Voraussetzungen (von denen der Hersteller zur Entwicklungszeit ausging) gegeben sind,
• antizipiert die kontextspezifischen Folgen einer Aktion (z.B. Gabe eines Medikaments durch eine Infusionspumpe bei gegebener Unsicherheit eines der Produkte) und
• führt die Entscheidungen aus und steuert Produkte an, z.B. eine Infusionspumpe oder einen Alarm.

Auch diese Entscheidungslogik sollte mit domänenspezifischen Sprachen formuliert werden. Dadurch erreicht man eine produkt- und herstellerübergreifende Interoperabilität.

Diese „Geschäftslogik“ zu beschreiben erfordert ein hohes Maß an Domänenwissen. Letztlich erfolgt dadurch eine Formalisierung des medizinischen Wissens.

Zusammenfassung

Die autonomen Systeme (bzw. deren Entscheidungsinstanzen) entscheiden über das Verhalten des gesamten Systems. Diese Entscheidungen trifft das System selbstständig und kontextspezifisch.

Domänenspezifische Sprachen beschreiben sowohl den Kontext als auch die Entscheidungslogik und damit

• die Produkte im System,
• deren Schnittstellen und
• die Auswirkungen von Entscheidungen für den Fall, dass die Annahmen erfüllt sind bzw. dass sie nicht erfüllt sind (z.B. Produkte sich nicht spezifikationsgemäß verhalten).

4. Vorteile autonomer Systeme

a) Vier Vorteile für Medizinproduktehersteller

Höhere Patientensicherheit

Hersteller dürfen und müssen zwar die Zweckbestimmung und den bestimmungsgemäßen Gebrauch und damit den klinischen und technischen Kontext festlegen; sie sind aber kaum in der Lage die Risiken zu bewerten, die bei allem Kombinationen von Produkten und Kontexten entstehen.

Das gilt insbesondere für Situationen, in denen die Anwender die Produkte nicht wie vorgesehen verwenden.

Damit wird es schwer, diese Risiken zu beherrschen und die Sicherheit der Patienten zu gewährleisten.

Autonome Systeme können (und sollten) prüfen, ob die Annahmen der Hersteller zu jeder Zeit gegeben sind. Kontextabhängig entscheiden sie dann, wie die Sicherheit auch dann garantiert werden kann, wenn Annahmen der Hersteller nicht erfüllt sind.

Keine unnötigen Produktkosten

Viele Hersteller versuchen, die Risiken für die kombinatorische Vielfalt an Situationen abzuschätzen, indem sie Worst-Case-Annahmen treffen. Um diesen zu begegnen, sind regelmäßig risikominimierende Maßnahmen erforderlich. Diese führen zu hohen Kosten oder sogar dazu, dass das Produkt nicht mehr wettbewerbsfähig ist und als Folge nicht mehr auf dem Markt gebracht werden kann.

Autonome Systeme sollten nicht von einem hypothetischen Worst-Case-Szenario ausgehen, sondern auf Basis des tatsächlichen „Cases“ entscheiden. Systeme haben mehr Möglichkeiten als einzelne Produkte, um auf konkrete Kontexte zu reagieren.

Damit sind Systemhersteller in der Lage, nicht nur kostengünstigere (effizientere), sondern durch dynamisches Risikomanagement sogar effektivere risikominimierende Maßnahmen zu realisieren. Das führt wiederum zu einer höheren Patientensicherheit.

Effizientere Entwicklung, Dokumentation und Zulassung

Die meisten Hersteller versuchen, durch Produktvarianten und Produktfamilien einerseits den Anforderungen ihrer Kunden gerecht zu werden und andererseits die Entwicklungskosten zu begrenzen.

Doch diese Kosteneffizienz wird nicht gelingen, wenn sie für jedes Produkt und jede Variante eine eigene technische Dokumentation erstellen und eine eigene Zulassung durchlaufen müssen.

In diesem scheinbaren Dilemma spielen modellbasierte Entwicklungen ihre Vorteile aus:

• Safety-Konzepte müssen nur einmal modelliert, entwickelt und getestet werden. Die Modellierung stellt sicher, dass diese Konzepte bei verschiedenen Varianten und Produkten identisch und wirksam umgesetzt wurden. Variationspunkte in der Produktlinie der Engineering-Artefakte sind mit den Variationspunkten der Safety-Artefakte verbunden und bilden eine sichere Produktlinie.
• Die Modellierung z.B. mit Hilfe von domänenspezifischen Sprachen bzw. Modellierungswerkzeugen führt direkt zur Schnittstellenspezifikation (und damit zu Produkt- bzw. Komponentenanforderungen). Die Modelle bilden auch gleichzeitig die konsistente Dokumentation, d.h., sie sind Teil der technischen Dokumentation.
• Das erhöht auch die „regulatory compliance“. Denn das häufig anzutreffende und meist unvollständige „Nachdokumentieren“ kann bei diesen modellbasierten Ansätzen nicht passieren.
• Zudem erlaubt die Modellierung bereits frühzeitig (nämlich auf der Ebene des Modells selbst) die Verifizierung und Validierung des Produkts bzw. der Komponente.

Fazit: Mit der Modellierung der Produkte und der Safety-Konzepte sparen Hersteller Zeit und Kosten für die Entwicklung und Dokumentation. Dieser Vorteil kommt umso mehr zum Tragen, je häufiger Produkte bzw. Komponenten in unterschiedlichen Konstellationen wiederverwendet werden, z.B. bei Produktfamilien.

Effizienzsteigerung anderer Prozesse

Dieser Artikel beleuchtet die autonomen Systeme nur im Kontext von Medizinprodukten. Aber Hersteller können autonome Systeme auch einsetzen bei der Produktion von Medizinprodukten (vergleichbar mit der Automobilindustrie) und bei der Automatisierung der Forschung (siehe dazu eine Pressemitteilung des Fraunhofer IESE).

b) Drei Vorteile für Betreiber (Krankenhäuser, Spitäler, Praxen)

Gesetzeskonformität

Gesetze und Verordnungen wie die Medizinprodukte-Betreiberverordnung stellen besondere Anforderungen an Gesundheitseinrichtungen, die vernetzte Medizinprodukte betreiben:

Miteinander verbundene Medizinprodukte sowie mit Zubehör einschließlich Software oder mit anderen Gegenständen verbundene Medizinprodukte dürfen nur betrieben und angewendet werden, wenn sie zur Anwendung in dieser Kombination unter Berücksichtigung der Zweckbestimmung und der Sicherheit der Patienten, Anwender, Beschäftigten oder Dritten geeignet sind.

MPBetreibV §4 (4)

Doch wie sollen die Betreiber diesen Anforderungen gerecht werden? Wie sollen sie in der Lage sein, die Risiken zu bewerten, wenn sie über die Produkte nur das wissen, was in den Begleitmaterialien beschrieben ist?

Autonome Systeme, deren Produktschnittstellen über domänenspezifische Sprachen beschrieben sind, unterstützen bei der Erfüllung der Anforderungen beim Betreiber.

Jetzt sind diese Voraussetzungen nicht nur in den Begleitmaterialien (falls überhaupt) formuliert. Vielmehr sind die Schnittstellenbeschreibungen, die auch computerauswertbar sind, notwendige Voraussetzung für den Einsatz des Produkts.

Fundierte Auswahl der Produkte

Dies erlaubt den Gesundheitseinrichtungen eine fundiertere Auswahl von Produkten: Nur Produkte, die über diese Schnittstellenbeschreibungen verfügen, kommen überhaupt noch für den Einsatz in autonomen Systemen in Betracht.

Ähnlich wie die DICOM-Konformitätserklärungen (mit IOD, SCP, SCU) die Interoperabilität DICOM-fähiger Geräte gewährleisten, erlauben Produkte mit den Schnittstellen, die über DSL beschrieben sind, die präzise Auswahl interoperabler Produkte.

Die Betreiber können diese Interoperabilitätsanforderungen explizit in Ausschreibungen benennen. Zudem können sie Produkte einfacher auswählen und durch andere Produkte ersetzen, solange diese über identische Schnittstellen verfügen.

Höhere Sicherheit für die Patienten

Der wichtigste Vorteil für die Betreiber besteht aber darin, dass die Interoperabilität der Produkte und die Fähigkeiten autonomer Systeme, spezifisch auf verschiedene Kontexte reagieren zu können, zu einer höheren Patientensicherheit führt.

Jetzt hängt diese Sicherheit nicht mehr vom zeitnahen Eingreifen des medizinischen Personals und vom spezifischen medizinischen und technischen Kontext ab. Denn autonome Systeme zeichnen sich gerade dadurch aus, dass sie eigenständig arbeiten und sich an verschiedene Gegebenheiten anpassen können.

5. Autonome Systeme aus der Brille des Medizinprodukterechts

a) Medizinprodukt versus System

Der Begriff „System“ assoziiert Systeme aus mehreren Produkten z.B. im Sinne von „Systemen und Behandlungseinheiten“ gemäß Artikel 22 der MDR. Doch dem ist nicht immer so.

Autonome Systeme können sein:

1. Ein einziges Medizinprodukt wie ein OP-Roboter. Dies wäre ein PEMS (programmierbares elektrisches medizinisches System) gemäß IEC 60601-1.
2. Eine von einer Firma in den Verkehr gebrachte Kombination von Produkten aus mindestens einem Medizinprodukte sowie ggf. aus anderen Produkten im Sinne des Artikels 22.
3. Mehrere von einer Gesundheitseinrichtung (z.B. Krankenhaus) miteinander verbundene Produkte (darunter auch Medizinprodukte), die gemeinsam einen spezifischen Zweck erreichen sollen.

MDR und IVDR stellen nur an die beiden ersten Fälle konkrete Anforderungen. Insbesondere die Anforderungen an das Risikomanagement sind herausfordernd: Die Hersteller müssen die kombinatorische Explosion von Produkten, Zuständen von Produkten und Kontexten bewerten, mit und in denen die Produkte betrieben werden können.

Normen wie die IEC 80001-1 beschreiben das Risikomanagement, das Gesundheitseinrichtung betreiben sollten, die Produkte zu einem „System“ kombinieren.

b) Anforderungen an die Interoperabilität

Zum bestimmungsgemäßen Gebrauch eines einzelnen Produkts kann zählen, vernetzt zu werden. Daher stellt die MDR zumindest die Anforderung, dass die Hersteller die Interoperabilität ihrer Produkte gewährleisten müssen. Diese Anforderungen finden sich beispielsweise im Anhang I.

Risiken im Zusammenhang mit der möglichen negativen Wechselwirkung zwischen Software und der IT-Umgebung, in der sie eingesetzt wird und mit der sie in Wechselwirkung steht;

Produkte, die gemeinsam mit anderen Produkten oder Produkten, die keine Medizinprodukte sind, eingesetzt werden sollen, werden so ausgelegt und hergestellt, dass das Zusammenspiel und die Kompatibilität zuverlässig und sicher sind.

Anhang I, Abschnitt 14.2 und Abschnitt 14.5

c) Klassifizierung

Falls ein Produkt ein geschlossenes Regelsystem (Closed-loop-System) enthält, sollten die Hersteller die Regel 22 des Anhangs VIII der MDR studieren.

Aktive therapeutische Produkte mit integrierter oder eingebauter diagnostischer Funktion, die das Patientenmanagement durch das Produkt erheblich bestimmt, wie etwa geschlossene Regelsysteme oder automatische externe Defibrillatoren, gehören zur Klasse III.

MDR, Anhang VIII, Regel 22

Diese Regel bezieht sich aber auf einzelne Produkte. Spezifische Regeln für Systeme aus mehreren (Medizin-)Produkten kennt die MDR nicht.

d) Fazit

Vielen Regularien, z.B. der MDR, fehlt der Blick auf vernetzte (autonome) Systeme. Sie stellen Anforderungen, die (nur) die einzelnen Produkte erfüllen müssen. Dazu zählen die o.g. Anforderungen an die Interoperabilität.

Die Verantwortlichkeit für das Funktionieren eines (autonomen) Systems aus mehreren Produkten von verschiedenen Herstellern regelt die MDR nicht. Diese Verantwortung liegt bei den Betreibern. Doch diese sind genau mit dieser Verantwortung oftmals überfordert.

6. Zusammenfassung

a) Autonome Systeme vereinen viele Herausforderungen

Die Vorteile autonomer Systeme sind offensichtlich. Viele der Herausforderungen auch:

• Es handelt sich um vernetzte Systeme aus vielen Produkten. Die kombinatorische Explosion an Konfigurationen und Problemen ist schwer zu beherrschen.
• Die Produkte verwenden oft Verfahren der künstlichen Intelligenz. Der Nachweis der Sicherheit und der Leistungsfähigkeit dieser Algorithmen ist besonders schwer zu führen.
• Die autonomen Systeme sind meist Closed-Loop-Systeme, die in kritischen Kontexten zum Einsatz kommen. Die Risiken in diesen Kontexten sind besonders hoch.

b) Aber es führt kein Weg daran vorbei

Auf Dauer ist der Ansatz zu naiv, mit isolierten Medizinprodukten und in Ignoranz konkreter technischer und medizinischer Kontexte Patienten individuell, sicher und wirksam behandeln zu wollen.

Der zunehmende Mangel an medizinischem Personal erfordert, dass Systeme tatsächlich autonom (d.h. ohne das Eingreifen von Menschen) und sicher auf die Kontexte wie den Ausfall von Systemkomponenten reagieren.

c) Besteht eine Mangel- und Fehlregulierung?

Die EU-Verordnungen werden der aktuellen Situation nicht gerecht. Zu sehr lenken sie den Blick auf das einzelne Produkt und dessen Interoperabilität. Der Systemgedanke – und damit sind nicht Systeme im Sinne des Artikels 22 gemeint – fehlt.

Die mögliche Freude mancher Hersteller, dass etwas nicht reguliert ist, mag verfrüht sein. Denn mangelnde Regulierung führt zu großer Unsicherheit bei der Zulassung der einzelnen Produkte. Maximalforderungen von Behörden und Benannten Stellen und die Diskussion unrealistischer Worst-Case-Szenarien erschweren die Zulassung.

Der Glaube, die Betreiber würden die Risiken durch die vernetzten Systeme wirksam analysieren und beherrschen, ist nicht mehr als ein Glaube.

d) Für die guten Hersteller bieten sich große Chancen

Herstellern, die schon jetzt daran scheitern, Medizinprodukte und auch die Dokumentation modular zu gestalten, wird es schwer fallen, Produkte für den Einsatz in autonomen Systemen zu entwickeln.

Denn modulare Architekturen sind die Voraussetzungen für

• die Wiederverwendbarkeit, Austauschbarkeit und Testbarkeit von Komponenten in verschiedenen Produkten und (autonomen) Systemen,
• wirksame Sicherheitskonzepte,
• die Erweiterung um modulare „Safety-Artefakte“ und
• eine schlanke, konsistente und gesetzeskonforme Dokumentation.

Hingegen sind diejenigen Hersteller bestens vorbereitet, die bereits modellgetrieben modulare Architekturen entworfen haben. Sie werden belohnt mit

• einer schnelleren „Time to Market“,
• niedrigeren Kosten für die Entwicklung und die Produkte,
• einer schlankeren Dokumentation ihrer Produkte und Produktfamilien,
• leichter erziel- und beweisbarer Gesetzeskonformität und damit schnellerer Zulassung,
• sichereren Produkten und
• einer höheren Wettbewerbsfähigkeit.

e) Die ersten Schritte gehen

Auch die längste Reise beginnt mit dem ersten Schritt. Beispiele für erfolgreiche erste Schritte sind:

• Klinische Kontexte festlegen, die man als Hersteller mit den eigenen Produkten bedienen will
• Die Modularität der eigenen Produkte überprüfen
• Den Stand der Modellierung im eigenen Unternehmen feststellen
• Den Entwicklerinnen und Entwicklern eine Weiterbildung anbieten zu folgenden Themen:
  • Autonome Systeme
  • Modellierung
  • Domänenspezifische Fragen
  • Sicherheitsarchitekturen
  • Risikomanagement
  • Regulatorische Anforderungen
• Mit Experten für autonome Systeme eine kleine Machbarkeitsstudie besprechen

Ähnlich wie beim Einsatz der computerbasierten Modellierung und Simulation liegt die Hürde für die Entwicklung autonomer Systeme hoch. Ohne klare Strategie und langfristige Investitionen in Mitarbeitende, Konzepte und Werkzeuge wird auch die Entwicklung autonomer Systeme nicht von Erfolg gekrönt sein.

Hingegen werden sich diejenigen Firmen entscheidende Wettbewerbsvorteile verschaffen, die konsequent diesen Weg weitergehen.

---

Für weitere Fragen stehen Dr. Rasmus Adler vom Fraunhofer IESE und das ganze Team des Johner Instituts z.B. über das kostenlose Micro-Consulting zur Verfügung.