Wissen zu medizinischer Software https://www.johner-institut.de/blog Fachartikel zur Entwicklung von Medizinprodukten und medizinischer Software konform mit IEC 62304, ISO 14971, IEC 62366, ISO 13485 und FDA Mon, 23 Nov 2020 14:40:05 +0000 de-DE hourly 1 https://wordpress.org/?v=5.5.3 155191967 Dritte Ausgabe der ISO 14971 – Was sich ändert https://www.johner-institut.de/blog/iso-14971-risikomanagement/dritte-ausgabe-der-iso-14971/ https://www.johner-institut.de/blog/iso-14971-risikomanagement/dritte-ausgabe-der-iso-14971/#comments Thu, 19 Nov 2020 08:00:00 +0000 https://www.johner-institut.de/blog/?p=2182712 Die dritte Ausgabe der ISO 14971 steht seit Dezember 2019 bereit. Die neue Version der ISO 14971 wurde als ISO 14971:2019 publiziert. Sie ist eine evolutionäre Weiterentwicklung der ISO 14971:2007 und bricht nicht mit den bisherigen Konzepten.  Inhaltsübersicht 1. ISO 14971, dritte Ausgabe » 2. Änderungen im Überblick » 3. Rechtliche Verbindlichkeit » 4. Fazit [...]

The post Dritte Ausgabe der ISO 14971 – Was sich ändert appeared first on Wissen zu medizinischer Software.

]]>
Die dritte Ausgabe der ISO 14971 steht seit Dezember 2019 bereit.

Die neue Version der ISO 14971 wurde als ISO 14971:2019 publiziert. Sie ist eine evolutionäre Weiterentwicklung der ISO 14971:2007 und bricht nicht mit den bisherigen Konzepten.

Hersteller sollten sich mit den neuen und geänderten Anforderungen dieser Norm vertraut machen. Noch im Dezember 2019 hat die FDA die 3. Ausgabe Norm der ISO 14971 anerkannt. Mehr zu den Übergangsfristen weiter unten.

1. Dritte Ausgabe der ISO 14971

Die dritte Ausgabe („third edition“) der ISO 14971 folgt auf die Vorgängernorm, die ISO 14971:2007 („second edition“). Auf dieser zweiten Ausgabe basiert auch die EN ISO 14971:2012. Das ist die Norm, die für die EU-Medizinprodukterichtlinien harmonisiert ist.

Noch ist unklar, ob die EU-Kommission für die Medizinprodukteverordnung (MDR) die neue Version harmonisieren wird. Eine Harmonisierung mit in Krafttreten der MDR im Mai 2020 bzw. Mai 2021 erfolgt nicht. Die Harmonisierung der EN ISO 14971:2019 ist aber zumindest im Entwurf für einen Standardization Request vom Oktober 2020 vorgesehen.

Parallel hat die ISO auch die ISO 24971 überarbeitet, die ebenfalls als Entwurf vorliegt. Diese „Erläuterungsnorm“ gewinnt an Bedeutung, weil sie nun einige der nicht-normativen Anhänge der alten ISO 14971 enthält.

2. Die Änderungen im Überblick

a) Neue Kapitelstruktur

Als erstes fällt die neue Kapitelstruktur auf. Die ISO 14971:2019 folgt nun dem üblichen Aufbau, der mit den folgenden Kapiteln beginnt:

  1. Anwendungsbereich („Scope“)
  2. Normative Verweise („Normative Reference“)
  3. Begriffsdefinitionen („Terms and definitions“)

Durch das neue Kapitel mit den normativen Verweisen verschiebt sich die Nummerierung. Die ISO 14971:2019 hat nun zehn Kapitel.

 Neue Kapitelstruktur der dritten Ausgabe der ISO 14971 (ISO 14971:2019)
Abb. 1: Neue Kapitelstruktur der dritten Ausgabe der ISO 14971 (ISO 14971:2019) (Zum Vergrößern klicken)

Bereits die Kapitelstruktur offenbart einen weiteren Unterschied: Die Anforderungen an die nachgelagerte Phase sind umfangreicher und in vier Unterkapitel (10.1 bis 10.4) unterteilt.

b) Höhere Relevanz des Nutzen-Risiko-Verhältnisses?

Die ISO 14971:2019 behauptet, noch deutlicher Wert auf den Nachweis zu legen, dass der Nutzen die Risiken überwiegt. Sie ergänzt die fehlende Definition des Begriffs Nutzen („Benefit“).

Definition: Benefit
„positive impact or desirable outcome of the use of a medical device on the health of an individual, or a positive impact on patient management or public health“
Quelle: ISO 14971, 3rd edition

Beispiele für diesen Nutzen sind:

  • Schnellere Genesung, vollständigere Genesung
  • Heilung mit weniger Nebenwirkungen
  • Genauere Diagnose
  • Bessere öffentliche Gesundheitsversorgung

Damit ist klar, dass mit Nutzen der medizinische Nutzen gemeint ist und nicht etwa ein höherer ökonomischer Nutzen für den Betreiber.

Wirklich neue Anforderungen stellt die Norm nicht. Unverändert fordert sie, dass es die Aufgabe des Managements ist, die Risikopolitik festzulegen. Diese muss sich am Stand der Technik orientieren. Zumindest eine Definition des Begriffs „Stand der Technik“ ergänzt die dritte Ausgabe der ISO 14971:2019.

Definition: State of the Art
„developed stage of technical capability at a given time as regards products, processes and services, based on the relevant consolidated findings of science, technology and experience“
Quelle: ISO 14971, 3rd edition

Dieser Stand der Technik ist nicht mit dem Stand der Wissenschaft zu vergleichen. Er entspricht eher allgemein anerkannten technischen und medizinischen „Good Practices“.

Neu ist in der dritten Ausgabe der ISO 14971, dass die Hersteller für die Bewertung der Einzelrisiken andere Akzeptanzkriterien festlegen können als für die Bewertung des gesamten Restrisikos. Die Akzeptanzkriterien für die Einzelrisiken können verwendet werden, um über die Notwendigkeit von Maßnahmen zur Risikobeherrschung zu entscheiden. Die Akzeptanzkriterien für das Gesamtrisiko können herangezogen werden um zu entscheiden, ob das Produkt in den Verkehr gebracht werden darf.

Die Norm verpflichtet die Hersteller dazu, die Methoden zu beschreiben, mit denen die Akzeptanz des Gesamtrestrisikos bestimmt wird.

c) IT Security im Scope

Die dritte Ausgabe der ISO 14971 nimmt Risiken durch mangelnde „data and system security“ explizit in den Scope mit auf. Sie stellt dafür aber keine spezifischen Anforderungen.

Besonders im deutschsprachigen Raum besteht die Gefahr, dass die Hersteller die Schutzziele „Safety“ und „Security“ nicht präzise unterscheiden, weil beide mit „Sicherheit“ übersetzt werden.

Während die Abwägung von medizinischem Nutzen und „Safety-Risiken“ Sinn ergibt, kann die Abwägung von medizinischem Nutzen und „Security-Risiken“ in die Irre führen. Eine Erhöhung der Security kann sogar zu Lasten der Safety gehen.

d) Vernünftigerweise vorhersehbarer Missbrauch ist zu berücksichtigen

Die ISO 14971:2019 ergänzt die explizite Forderung, den vernünftigerweise vorhersehbaren Missbrauch zu analysieren. Sie definiert diesen „reasonably forseeable misuse“ wie folgt:

Definition: reasonably forseeable misuse
„use of a product or system in a way not intended by the manufacturer, but which can result from readily predictable human behaviour “
Quelle: ISO 14971, 3rd edition

Dieser Missbrauch kann absichtlich oder unabsichtlich erfolgen. Ein Beispiel wäre die Nutzung eines Produkts, ohne vorher die Gebrauchsanweisung studiert zu haben.

e) Sicherheitsbezogene Charakteristiken sind zu identifizieren

Neu ist zwar das Kapitel zu den sicherheitsbezogenen Charakteristiken, aber die Anforderungen sind es nicht. Diese Charakteristiken des Produkts müssen die Hersteller qualitativ und quantitativ erfassen – am besten mit Angabe von Grenzwerten, die für die Sicherheit des Produkts wesentlich sind. Alle Kenner der IEC 60601-1 denken sofort an die wesentlichen Leistungsmerkmale. Zu Recht.

Das Johner Institut empfiehlt, insbesondere die Systemanforderungen daraufhin zu untersuchen, ob ein Risiko folgen könnte, wenn diese nicht oder nicht im spezifizierten Maß erfüllt sind.

f) Anforderungen an die Produktion und die nachgelagerte Phase

Die auffälligste Änderung betrifft das Risikomanagement in der Produktion sowie in der der Produktion nachgelagerten Phase – sprich: der Post-Market-Phase. Die Anforderungen erinnern stark an die der MDR.

Sowohl die MDR als auch die dritte Ausgabe der ISO 14971 fordern ein proaktives Sammeln und Bewerten der Daten aus den Phasen nach der Entwicklung. Die MDR spricht von einem Prozess, die ISO 14971 von einem System.

Die ISO 14971:2019 fordert das aktive Sammeln und Bewerten der Daten sowie ggf. das Handeln.
Abb. 2: Die ISO 14971:2019 fordert das aktive Sammeln und Bewerten der Daten sowie ggf. das Handeln.

Ähnlich wie die MDR legt auch die Norm die Informationsquellen fest, die auf jeden Fall betrachtet werden müssen. Darunter finden sich z.B. öffentliche Informationen, Informationen zum Stand der Technik und Informationen, die bei der Installation, Anwendung und Wartung des Produkts entstehen.

Die Informationen müssen daraufhin bewertet werden, ob

  • neue, bisher nicht betrachtete Gefährdungen zu beachten sind,
  • die Risiken (Wahrscheinlichkeiten und Schweregrade von Schäden) richtig bewertet sind und
  • die Risiken weiterhin akzeptabel sind, z.B. weil sich der Stand der Technik geändert hat.

Abhängig von den Ergebnissen dieser Bewertung muss der Hersteller handeln. Konkret nennt die dritte Ausgabe der ISO 14971 Handlungen, die das Medizinprodukt betreffen (z.B. neue risikominimierende Maßnahmen implementieren) und Handlungen, die das Risikomanagement (z.B. den Risikomanagementprozess) betreffen.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema nachgelagerte Phase und Post-Market Surveillance.

3. Rechtliche Verbindlichkeit

a) Europa

Die ISO 14971:2019 ist unter den EU-Verordnungen (MDR, IVDR) bisher nicht harmonisiert. Eine Harmonisierung unter den EU-Richtlinien (MDD, AIMD, IVDD) ist nicht mehr vorgesehen.

Weil es keine harmonisierte EN ISO 14971 gibt, dürften und sollten die Benannten Stellen und Behörden den Stand der Technik einfordern und damit die aktuelle Version. Übergangfristen sind nicht definiert.

b) USA / FDA

Die FDA wird die zweite Ausgabe der Norm aus dem Jahr 2007 noch bis Ende 2022 gestatten. Spätestens danach besteht die FDA auf der Anwendung der dritten Ausgabe der ISO 14971.

4. Fazit

Die dritte Ausgabe der ISO 14971 ist noch besser als die bereits gute zweite Ausgabe. Viele Änderungen sind redaktioneller Art und sorgen für mehr Klarheit und Stringenz.

Besonders erwähnenswert sind die präzisierten Anforderungen an die nachgelagerte Phase. Dennoch bleibt der Umfang der Änderungen beschränkt, sodass „Version 2.1“ der Sache eher gerecht geworden wäre. Bedauerlich ist insbesondere:

  1. Viele hilfreiche Anhänge sind in die ISO 24971 verschoben worden. Das macht die ISO 14971 zwar schlanker, zwingt aber die Hersteller, eine zweite Norm zu kaufen.
  2. Einige Erläuterungen sind ganz verschwunden. So hatte die alte ISO 14971 noch klargestellt, dass sich das Risiko eben nicht aus der Multiplikation von Schweregrad und Wahrscheinlichkeit von Schäden berechnet. Wie kann eine so zentrale und berechtigte Feststellung verschwinden angesichts der Tatsache, dass 95 % der Hersteller genau dies tun?
  3. Es ist anzunehmen, dass die EU die Forderungen der MDR zum Risikomanagement durch die dritte Ausgabe nur teilweise abgedeckt sieht. Dadurch drohen wieder zusätzliche Anforderungen und normative Interpretationen in den Z-Anhängen.
  4. Das Zusammenspiel des Risikomanagements mit der klinischen Bewertung beschreibt die dritte Ausgabe der ISO 14971 gar nicht, die überarbeitete ISO 24971 nur rudimentär.
  5. Es ist nachvollziehbar, dass das Normengremium die Norm an die sonst übliche Kapitelstruktur angleichen wollte. Diese redaktionelle Änderung wird dazu führen, dass die meisten Hersteller ihre Vorgabedokumente (Verfahrensanweisungen, Arbeitsanweisungen, Templates) usw. daraufhin untersuchen müssen, ob die Referenzen auf die Kapitelstruktur noch stimmen. Viel Arbeit, die nicht der Patientensicherheit zugute kommt.

Trotz dieser Wehmutstropfen dürften die Hersteller mit dieser dritten Ausgabe der ISO 14971 gut leben können. Weniger ist eben manchmal mehr.


Änderungshistorie

  • 2020-11-16: Hinweis auf Standardization Request und damit auf die Planung einer Harmonisierung der EN ISO 14971:2019 eingefügt

The post Dritte Ausgabe der ISO 14971 – Was sich ändert appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/iso-14971-risikomanagement/dritte-ausgabe-der-iso-14971/feed/ 5 2182712
Regulatory Science: Europa im Blindflug https://www.johner-institut.de/blog/regulatory-affairs/regulatory-science/ https://www.johner-institut.de/blog/regulatory-affairs/regulatory-science/#comments Tue, 17 Nov 2020 07:00:00 +0000 https://www.johner-institut.de/blog/?p=3834003 Regulatory Science wird meist etwas holprig als Regulierungswissenschaften übersetzt. Im deutschsprachigen Bereich wird die Regulatory Science in systematischer Weise kaum betrieben. Genau dieser Missstand fällt den Medizinprodukteherstellern auf die Füße und schadet sowohl dem Gesundheitswesen als auch dem Standort. Höchste Zeit, dies zu ändern! 1. Was Regulatory Science ist a) Definition von Regulatory Science „Regulatory [...]

The post Regulatory Science: Europa im Blindflug appeared first on Wissen zu medizinischer Software.

]]>
Regulatory Science wird meist etwas holprig als Regulierungswissenschaften übersetzt. Im deutschsprachigen Bereich wird die Regulatory Science in systematischer Weise kaum betrieben.

Genau dieser Missstand fällt den Medizinprodukteherstellern auf die Füße und schadet sowohl dem Gesundheitswesen als auch dem Standort. Höchste Zeit, dies zu ändern!

1. Was Regulatory Science ist

a) Definition von Regulatory Science

„Regulatory Science“ ist eine Wissenschaft. Sie entwickelt die (technischen) Grundlagen, Prozesse, Methoden und Werkzeuge,

  • um darauf aufbauend regulatorische Anforderungen zu formulieren, die die Sicherheit, Leistungsfähigkeit und Wirksamkeit von Medizinprodukten gewährleisten, und
  • um ökonomische und andere Auswirkungen dieser regulatorischen Anforderungen auf die Gesundheitssysteme und die Wirtschaft zu verstehen und zu antizipieren.

Eine kurze und etwas vereinfachende Definition könnte lauten:

Definition: Regulatory Science
„Regulierungswissenschaft besteht aus der Anwendung von Wissenschaft zur Unterstützung der Regulierung, insbesondere der Regulierungsziele“.
Angelehnt an Quelle

b) Abgrenzung zu Regulatory Affairs

Die Regulatory Science kümmert sich im Gegensatz zu Regulatory Affairs nicht darum,

  • wie Regularien (Gesetze, Verordnungen, Richtlinien) juristisch korrekt formuliert und verkündet werden,
  • wie diese Vorschriften überwacht (z.B. auditiert) und durchgesetzt werden oder
  • welche Unterlagen Hersteller in welcher Form bereitstellen müssen.

Umgekehrt ist es nicht die Aufgabe von Regulatory Affairs, die Sinnhaftigkeit und Wirksamkeit der Regularien wissenschaftlich zu bewerten.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Regulatory Affairs.

2. Weshalb wir die Regulatory Science benötigen

a) Entweder erfolgt die Regulierung im kompletten Blindflug …

Wer handelt, sollte sich über die Konsequenzen seines Handelns bewusst sein. Doch genau dieser banalen Forderung kommen viele Regulierer (also Gesetzgeber und Behörden) nicht nach. Sie können es auch nicht, denn ihnen fehlt die wissenschaftliche Grundlage.

Die Befragung einiger Experten kann das nicht ersetzen. Einem Hersteller, der sich vornehmlich auf Befragungen von Patienten oder Experten stützen würde, würden die Behörden und Benannten Stellen mangelnde Evidenz vorwerfen. Zu Recht, denn Eminenz ersetzt nicht Evidenz.

Jedes Gesetz, jede Verordnung und jede Richtlinie hat Nebenwirkungen. Um das Nutzen-Risiko-Verhältnis durch die Gestaltung dieser Regularien zu optimieren, bedarf es eines Verständnisses der wirtschaftlichen und technologischen Abhängigkeiten. Diese zu erforschen, ist eine zentrale Aufgabe der Regulatory Science.

Fazit: Ohne ein Verständnis dieser Zusammenhänge fehlen den Gesetzgebern die Entscheidungsgrundlagen. Sie regulieren im kompletten Blindflug.

Ursache-Wirkungsdiagramm zeigt beispielhaft Abhängigkeiten und Auswirkungen von Regularien. Diese zu untersuchen ist die Aufgabe der Regulatory Science.
Abb. 1: Beispiel für Abhängigkeiten und Auswirkungen von Regularien. Diese zu untersuchen ist die Aufgabe der Regulatory Science.

b) … und gefährdet Märkte und Patienten …

Die Regulierung erfolgt meist in bester Absicht. Zwar dienen Gesetze und andere Vorschriften in einigen Ländern auch zur Marktabschottung. Aber sie verfolgen (hoffentlich) primär das Ziel, dank sicherer und klinisch wirksamer Produkte zu einer optimalen Gesundheitsversorgung beizutragen.

Doch auf zentrale Fragen wissen die Gesetzgeber keine Antwort:

  • Werden beispielsweise MDR und IVDR dieses Ziel besser erreichen als die bisherigen EU-Richtlinien (MDD, IVDD und AIMDD)?
  • Wie viele Tote und schwer geschädigte Patienten erhofft die EU-Kommission durch die neuen Verordnungen zu vermeiden?
  • Und wie viele Tote und schwer geschädigte Patienten nimmt die EU durch Produkte in Kauf, die durch MDR und IVDR verhindert werden?

Auf welcher Datenbasis hat Brüssel seine Entscheidungen getroffen? Es sind Entscheidungen, die direkt den europäischen MedTech-Markt mit einem Volumen von jährlich über 120 Mrd. EUR betreffen und indirekt den Gesundheitsmarkt insgesamt, der alleine in Deutschland eine Milliarde EUR an Wertschöpfung erwirtschaftet – pro Tag! [Quelle]

Die FDA behauptet sogar:

In the U.S., FDA-regulated products account for about 25 cents of every dollar spent by American consumers each year — products that touch the lives of every American every day.

Quelle
Bild zeigt stilisierte Waage: Die Regulatory Science soll zu einem optimalen Verhältnis vom Nutzen und den Schäden durch Regulierungen beitragen
Abb. 2: Regulatory Science soll zu einem optimalen Verhältnis von Nutzen und Schaden beitragen, die durch Regulierungen entstehen

c) … oder wir geraten in Abhängigkeiten …

Die FDA engagiert sich aktiv im Bereich der Regulatory Science. Auf der Webseite „Advancing Regulatory Science” bietet sie einen Überblick über ihre Aktivitäten.

Der bequeme europäische Ansatz könnte darin bestehen, diese Ergebnisse für sich zu nutzen, ohne sich zu engagieren und ohne in Regulatory Science zu investieren.

Doch es gibt Gründe, die gegen diese Bequemlichkeit sprechen:

  1. Unnötige Abhängigkeit
    Übernahme und Adaption dieser Ergebnisse stellen eine Abhängigkeit dar. Die FDA kann den Zugang zu diesen Daten jederzeit unterbinden.
  2. Limitierte Übertragbarkeit von Daten
    Der Fokus der FDA liegt berechtigterweise auf den USA. Das Anliegen der Behörde ist die Sicherheit der US-Patienten. Doch nicht alle Ergebnisse sind auf Europa übertragbar. Weder gibt es in Europa die identischen Produktklassen, noch ist die Bevölkerung in allen Attributen vergleichbar. Die Nutzungskontexte (z.B. Anwender, Arbeitsumgebungen) lassen sich nicht unreflektiert auf Europa übertragen.
  3. Suboptimale Evidenz
    Wissenschaft endet nicht an Ländergrenzen. Vielmehr ist eine Wissenschaft wie die Regulatory Science besonders dann erfolgreich, wenn ihr weltweit viele Ressourcen, insbesondere Daten und Wissenschaftler, zur Verfügung stehen. Es geht also nicht um „Europa vs. USA“ oder „Europa vs. den Rest der Welt“. Es geht darum, eine möglichst breite Datenbasis zu schaffen und einen möglichst hohen Erkenntnisgewinn zu erzielen.

d) … und die Hersteller verpassen Chancen und verlieren Zeit und Geld

Die Regulatory Science hat nicht nur die Aufgabe, unsichere Produkte zu verhindern. Sie hat auch die Aufgabe, Innovationen zu fördern und Herstellern neue Möglichkeiten aufzuzeigen, wie sie

  • Behörden und Benannten Stellen die Wirksamkeit und Sicherheit ihrer Produkte einfacher, glaubhafter und schneller nachweisen können (z.B. durch Computer-Modelle),
  • zuverlässig Risiken durch ihre Produkte während der Entwicklung und im Markt entdecken und beseitigen, bevor es zu Patientenschäden kommt,
  • den Stand der Technik verfolgen können,
  • von neuen und alternativen Prozessen, Methoden, Materialien und Werkzeugen erfahren, um schnell bessere Produkte zu entwickeln und sich einen Marktvorteil zu verschaffen.

3. Diese Fragen sollte Regulatory Science beantworten

Um die oben genannten Ziele zu erreichen, sollte Regulatory Science Antworten auf die relevanten Fragen aller Stakeholder liefern.

a) Fragen von Regulierern

Fragen zu den Auswirkungen auf Hersteller und den Medizinproduktemarkt

  • Was wird es die Hersteller kosten, neue Regularien umzusetzen?
  • Wie viele Gesundheitsschäden wird eine neue oder geänderte regulatorische Anforderung zu vermeiden helfen?
  • Wie viele Hersteller werden in der Lage sein, diese Anforderung zu erfüllen? Wie lange werden sie dafür benötigen?
  • Welcher Prozentsatz an Herstellern wird an dieser Hürde scheitern? Welche Medizinprodukte werden dadurch nicht oder erst später zur Verfügung stehen?
  • Was sind die Konsequenzen dieser Verzögerungen oder des Nicht-Inverkehrbringens für das Gesundheitssystem?
  • In welcher Weise schaden Regularien kleinen Firmen und/oder der Innovation? Wie kann es gelingen, dass Regularien Innovation sogar befördern?
  • Zu welchen Standortnachteilen oder Standortvorteilen führen neue Regulierungen? Wie kann der Standort durch Regularien gestärkt werden?
  • Wie können Regularien gestaltet und formuliert werden, damit Medizinprodukte sicherer und leistungsfähiger werden? Führen beispielsweise extra strenge Anforderungen bei einer klinischen Bewertung wirklich dazu, dass Medizinprodukte an Sicherheit, Leistungsfähigkeit und Wirksamkeit gewinnen?

Fragen zu den Auswirkungen auf Behörden und Benannte Stellen

  • Wie lange wird es dauern, bis Behörden und Benannte Stellen diese Anforderungen überwachen und einfordern können?
  • Zu welchen Engpässen kann es bei diesen Akteuren führen? (Personal, Ausbildung, Verfügbarkeit)
  • Sind diese in der Lage, die Anforderungen auch bei Herstellern außerhalb der EU wirksam einzufordern?
  • Mit welchen Werkzeugen können/sollen Behörden und Benannte Stellen die Einhaltung der Anforderungen möglichst effizient und effektiv überwachen?
  • Welche Zulassungsverfahren bieten sich bei welchen Produkten an?

Fragen zu den Auswirkungen auf Patienten

  • Wie sehr dienen Regularien dem Interesse der Patienten? Wo greifen sie unangemessen in die Entscheidungsfreiheit und die Risikoakzeptanz individueller Patienten ein?

Fragen zur künftigen Gesetzgebung

  • Auf welche Trends müssen wir uns einstellen? Für welche Produkte, Technologien, Methoden und Materialien werden künftig neue Regularien benötigt?
  • Welche derzeitigen regulatorischen Anforderungen entsprechen nicht mehr dem Stand der Technik?
  • Wo fehlen Regularien, die notwendig wären, um die Gesundheitsversorgung zu verbessern, z.B. durch sichere Produkte? Wo behindern Regularien und schaden dem Standort oder sogar der Gesundheitsversorgung?
  • Wie lässt sich das regulatorische Rahmenwerk so gestalten, dass einerseits dem tatsächlichen Stand der Technik ausreichend schnell Rechnung getragen wird und andererseits die Gesetzgebung dieser Geschwindigkeit gerecht werden kann? Was muss getan werden, dass auch die Hersteller diesem Stand der Technik folgen können?
  • Wie können Regularien so spezifisch formuliert werden, dass Hersteller einerseits genau wissen, was verlangt ist, und andererseits nicht unnötig in ihrer Gestaltungsfreiheit eingeschränkt werden?
  • Was müssen wir von Herstellern verlangen, damit sie die Sicherheit und Wirksamkeit tatsächlich nachweisen können, aber diese Nachweise (z.B. durch klinische Prüfungen) Patienten nicht unnötig gefährden?

Fragen zur Förderung und Gestaltung

  • Wie müssen wir uns als Gesetzgeber personell und inhaltlich aufstellen?
  • Welche Empfehlungen sollten wir Behörden und Benannten Stellen geben, um deren Effizienz und Effektivität (z.B. durch Digitalisierung) zu steigern?
  • Wie können wir die Aufgaben im Kontext der Regulatory Science auf Behörden, Industrie, Fachgremien, die Wissenschaft, Patienten(vertreter) und andere aufteilen?
  • Was können wir den Herstellern als Hilfestellung anbieten? Das betrifft Leitfäden ebenso wie validierte Computermodelle z.B. von Organen.
  • In welchen Bereichen fehlen wissenschaftliche Grundlagen? Wo würde sich eine Förderung besonders bezahlt machen?

b) Fragen von Herstellern

  • Was ist der Stand der Technik (bezüglich einer Fragestellung)? Wie bestimme ich ihn?
  • Welche Optionen habe ich, um die Sicherheit, Leistungsfähigkeit und Wirksamkeit meiner Produkte nachzuweisen? Welche der Optionen sind besonders effizient?
  • Werden die Benannten Stellen und Behörden diese Optionen akzeptieren?
  • Wie kann ich meine Medizinprodukte mit Hilfe von Computermodellen schneller entwickeln, verifizieren und validieren?
  • Was muss ich machen, um diese Computermodelle zu validieren?
  • Mit welchem Patientenkollektiv muss ich eine klinische Prüfung durchführen? Welchen Teil dessen kann ich durch in-silico clinical trials ersetzen?
Weiterführende Informationen

Lesen Sie hier mehr zum Thema Computer-based Modeling and Simulation und erfahren Sie, wie die FDA damit die schnellere Entwicklung und Prüfung von Medizinprodukten fördert.

c) Fragen von Behörden und Benannten Stellen

  • Wie bewerte ich die Risiken und die Leistungsfähigkeit neuer
    • Produkte und Produktklassen (z.B. Roboter),
    • Technologien (z.B. Machine Learning),
    • Methoden (z.B. 3D-Druck für die Herstellung) und
    • Materialien (z.B. Nanopartikel)?
  • Wie entdecke ich bei begrenzten zeitlichen und personellen Ressourcen mit einer möglichst hohen Wahrscheinlichkeit Nicht-Konformitäten bei Produkten und Herstellern?
  • In welchen Bereichen (Produkte, Hersteller, Märkte, Technologien) werden wir künftig mit Problemen zu rechnen haben? Wir können wir dem gegensteuern?
  • Wie kann es uns gelingen, die Zulassungsprozesse und die Marktüberwachung so zu digitalisieren, dass wir
    • schwarze Schafe schneller und wirksamer entdecken und
    • die eigenen Aufwände dafür begrenzen?
  • Wie kann ich abschätzen, wie sehr die Nachweise der Hersteller für möglichst alle Umstände (Nutzungskontexte, Patientenpopulationen) geeignet sind? Wie erkenne ich Lücken?

4. Regulatory Science betreiben

a) Die Akteure der Regulatory Science

Regulatory Science ist nicht nur eine Aufgabe der Universitäten. Das Betreiben von Regulatory Science ist vielmehr eine gesellschaftliche Aufgabe, an der sich beteiligen sollten:

  • Nationale und internationale Gesetzgeber, Behörden
  • Benannte Stellen
  • Fachgremien wie Normengremien, IMDRF usw.
  • Hochschulen, Universitäten und andere Forschungseinrichtungen
  • Krankenhäuser, Spitäler und sonstige Gesundheitseinrichtungen
  • Patienten
  • Hersteller
  • Dienstleister, Beratungsunternehmen, Testlabore, Weiterbildungsinstitute

Auch das Johner Institut arbeitet seit Jahren aktiv mit:

  • Entwicklung von Leitfäden (z.B. zur IT-Sicherheit oder zur künstlichen Intelligenz)
  • Beiträge zur Weiterentwicklung von Normen
  • Entwicklung von Konzepten, Daten- und Gedankenmodellen
  • Ausbildung des wissenschaftlichen Nachwuchses
  • Digitalisierung und damit Effizienzsteigerung von Prozessen wie
    • der Post-Market Surveillance und
    • der kontinuierlichen weltweiten Recherche neuer und geänderter Regularien

b) Die Methoden der Regulatory Science

Regulatory Science ist eine Wissenschaft.

Definition: Wissenschaft
„Die Wissenschaft bezeichnet die Gesamtheit des menschlichen Wissens, der Erkenntnisse und der Erfahrungen, welches systematisch erweitert, gesammelt, aufbewahrt, gelehrt und weitergegben wird.“

Das wissenschaftliche Arbeiten zeichnet sich dadurch aus, dass es

  • systematisch erfolgt,
  • Fragestellungen möglichst vollständig beantwortet,
  • objektiv ist,
  • im gegebenen Kontext Allgemeingültigkeit hat und damit relevant ist sowie
  • überprüfbar ist.
Bild mit den fünf Elementen, die die Voraussetzungen für Wissenschaftliches Arbeiten sind
Abb. 3: Kriterien wissenschaftlichen Arbeitens, die auch für Regulatory Science gelten

Um diesen Kriterien zu genügen, müssen die Wissenschaftler systematisch vorgehen und geeignete Methoden anwenden.

Zu den Methoden im Bereich der Regulatory Science zählen beispielsweise:

  • Berechnungen und Modellierungen, z.B. mit Computer-Modellen
  • Experimente; dazu zählen klinische Prüfungen und Usability Tests
  • Auswertung vorhandener Daten, das Data-Mining, die Suche nach Abhängigkeiten, der Vergleich von Gesundheitssystemen, Produkten, Methoden, Materialien
  • Befragungen und Beobachtungen
  • Prototyp-Entwicklung

5. Fazit, Zusammenfassung

a) Der bisherige Ansatz des Regulierens ist zu naiv

Der Ansatz vieler Regulierer, den Schutz der Patienten vor unsicheren Produkten als einziges Ziel zu verfolgen, greift zu kurz. Denn dann könnte man einfach alle Medizinprodukte verbieten und hätte damit absolute Sicherheit erlangt.

Vielmehr geht es darum, das Nutzen-Risiko-Verhältnis zu optimieren. Das wiederum setzt voraus, dass man den Nutzen und die Risiken kennt und bewertet.

Für die Bewertung benötigt man Daten. Ohne diese Daten verkommt auch eine gut gemeinte Gesetzgebung zu einem wilden „Rumregieren“ im Blindflug.

Fazit: Die Gesetzgeber erfüllen nicht die Anforderungen an den Nachweis eines positiven Nutzen-Risiko-Verhältnisses, die sie an die Hersteller stellen.

b) Es geht nicht um das Verhindern, sondern um das Gestalten

Eine professionelle Regulatory Science trägt dazu bei,

  • Innovationen zu fördern,
  • Märkte zu unterstützen und
  • sicherzustellen, dass dem Gesundheitssystem bezahlbare, wirksame und sichere Produkte zur Verfügung stehen.

Die FDA hat das längst erkannt und treibt die Regulatory Science voran. Mit über 15.000 Mitarbeitenden und einem Budget von mehr als 3 Mrd. USD verfügt sie über Ressourcen, von denen europäische Regulierer nur träumen können.

c) Die Regulatory Science braucht uns und wir brauchen die Regulatory Science

Sowohl in Deutschland als auch vielen anderen europäischen Ländern ähnelt die Landschaft der Regulatory Science weitgehend einer Wüste. Dass die Gesetzgeber es besser können, zeigten sie bei der Bekämpfung der Corona-Pandemie: Hier bezogen Politik und Behörden die Wissenschaft(ler) wie z.B. Virologen mit ein.

Würde man bei einer Pandemie so vorgehen wie beim Medizinprodukterecht, würde der Gesetzgeber nicht nur die Virologen ignorieren. Es gäbe nicht einmal eine Virologie.

Um von diesem Niveau auf das der FDA zu gelangen, sind große Kraftanstrengungen notwendig. Diese sind nur gemeinsam zu bewältigen. Das Johner Institut ist dabei.

The post Regulatory Science: Europa im Blindflug appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/regulatory-affairs/regulatory-science/feed/ 2 3834003
Safety Assurance Cases: Leidvolle Diskussionen mit Auditoren abkürzen https://www.johner-institut.de/blog/iso-14971-risikomanagement/safety-assurance-cases/ https://www.johner-institut.de/blog/iso-14971-risikomanagement/safety-assurance-cases/#comments Tue, 10 Nov 2020 08:00:00 +0000 https://www.johner-institut.de/blog/?p=3821856 Sind Sie die Diskussionen mit Ihrer Benannten Stellen leid, ob Ihre Produkte ausreichend sicher sind? Dann wenden Sie Safety Assurance Cases an. Mit diesem Top-Down-Ansatz führen Sie leicht und elegant den nachvollziehbaren Beweis. Mit einem Ansatz konform dem AAMI TIR 38, der ISO/IEC 15026 oder den Vorgaben der FDA haben Sie die Argumente auf ihrer [...]

The post Safety Assurance Cases: Leidvolle Diskussionen mit Auditoren abkürzen appeared first on Wissen zu medizinischer Software.

]]>
Sind Sie die Diskussionen mit Ihrer Benannten Stellen leid, ob Ihre Produkte ausreichend sicher sind? Dann wenden Sie Safety Assurance Cases an. Mit diesem Top-Down-Ansatz führen Sie leicht und elegant den nachvollziehbaren Beweis.

Mit einem Ansatz konform dem AAMI TIR 38, der ISO/IEC 15026 oder den Vorgaben der FDA haben Sie die Argumente auf ihrer Seite. Ihre Benannte Stelle wird nicht nur von der Konformität Ihrer Produkte überzeugt, sondern auch von Ihrer Professionalität angetan sein. Die Zulassung wird damit fast zur Formsache.

1. Was sind Safety Assurance Cases?

a) Definition #1

Definition: Safety Assurance Case
„Ein Safety Assurance Case ist eine strukturierte Argumentation, die von einer Reihe von Beweisen gestützt wird, die wiederum in überzeugender und vollständiger Weise die valide Annahme erlauben, dass ein Produkt für eine bestimmte Nutzung in einer bestimmten Nutzungsumgebung sicher und wirksam ist.“
angelehnt an ISO 15026 und andere Quellen

Diese Argumentation bedingt eine Reihe von bestimmten Aktivitäten, weshalb manche die Safety Assurance Cases auch als Methode bezeichnen.

b) Komponenten von Safety Assurance Cases

Die Beweisführung mit Hilfe von Safety Assurance Cases besteht aus mehreren Komponenten, wie sie die beispielsweise ISO 15026-2 benennt:

Komponente

Beispiele

Schlussfolgerung (Conclusion), zu der ein Prüfer (z.B. einer Benannten Stelle oder einer Behörde) kommen soll

Das Medizinprodukt erfüllt die regulatorischen Anforderungen.

Behauptung (Claim): Eine Aussage oder Zusicherung über eine Eigenschaft eines Produkts, Systems oder Subsystems, die belegt werden soll

Die Claims betreffen meist die Sicherheit oder Leistungsfähigkeit.

Ein Safety Assurance Case hat laut ISO 15026-2 einen oder mehrere Top-Level-Claims. Die Claims sind oft hierarchisch strukturiert.

Das Medizinprodukt ist sicher. (Top-Level-Claim)

Die elektrischen Gefährdungen sind beherrscht. (Sub-Claim)

Die Isolation ist ausreichend dimensioniert.

Kontext: Informationen z.B. über das Produkt, dessen Nutzung und Nutzungsumgebung

Zweckbestimmung, Ergebnisse der Risikoanalyse

Annahmen (Assumption): Voraussetzungen, die gegeben sein müssen, oder Sachverhalte, die üblicherweise auch ohne weitere Beweise akzeptiert werden bzw. unbestritten sind

Vorgesehene Anwender (z.B. mit Ausbildung und Erfahrungen)

Ableitströme, die kleiner als von der IEC 60601-1 gefordert sind, stellen keine inakzeptablen Risiken dar.

Belege/Nachweise (Evidence): Daten, die für die Beweisführung bzw. Argumentation genutzt werden, die z.B. durch die Verifizierung und Validierung gewonnen.

Testergebnisse (z.B. von Sicherheitsmaßnahmen), Beobachtungen, Expertenmeinungen, wissenschaftliche Prinzipien, Forschungsergebnisse

Argumentation (Argument): Begründung dafür, dass die Nachweise (Evidence) geeignet sind, die Behauptung (Claim) zu untermauern

 

Manchmal formuliert man im Rahmen der Safety Assurance Cases zusätzlich eine Strategie für die Beweisführung.

Vollständige Induktion

Auffinden und Beherrschen von Gefährdungen

Die ISO 15026-2 kennt zudem noch eine weitere Begründung, die Justification. Diese begründet aber nicht, weshalb ein Claim zutreffend ist, sondern weshalb man einen bestimmten Claim gewählt hat.

c) Definition #2

Entsprechend definiert die Norm Safety Assurance Cases wie folgt:

Definition: Assurance Case
„An assurance case is defined to be a quadruple of a claim c, a justification j of c, a set es of evidence and an argument g which assures c using es. “
Quelle ISO 15026-1, Kapitel 6.2

Die Regularien, insbesondere die grundlegenden Sicherheits- und Leistungsanforderungen geben viele Claims vor, die die Hersteller nachweisen müssen.

2. Struktur von Safety Assurance Cases

Ein Safety Assurance Case hat einen oder mehrere Top-Level-Claims, die das Ziel der Beweisführung sind. Deren Wahl benötigt eine „Justification“.

Claims können durch „Limitations“ eingeschränkt werden z.B. bezüglich der Dauer, der Sicherheit oder der Voraussetzungen.

Um einen Claim nachzuweisen, benötigt man entweder genau ein Argument oder einen oder mehrere (Sub-)Claims, Evidenzen oder Annahmen.

Argumente wiederum müssen durch einen oder mehrere Claims, Evidenzen oder Annahmen gestützt sein.

Bild zeigt UML Diagramm: Ein vereinfachtes Meta-Modell von Safety Assurance Cases, wie es sich aus der ISO 15026-2 ergibt
Abb. 1: Ein vereinfachtes Meta-Modell von Safety Assurance Cases, wie es sich aus der ISO 15026-2 ergibt. Die abstrakte Entität „Support“ kennt die Norm nicht.

Die OMG (Object Management Group) hat ein genaueres Metamodell in ihrem Dokument Structured Assurance Case Metamodel (SACM) veröffentlicht, das allerdings nicht ganz deckungsgleich mit der ISO 15025-2 ist.

3. Grafische Darstellung von Safety Assurance Cases

a) Goal Structuring Notation

Die Goal Structuring Notation (GSN) hilft, die Safety Assurance Cases grafisch darzustellen. Das erleichtert den schnellen Überblick.

Weiterführende Informationen

Sie finden hier eine kurze Einführung in die GSN und hier ein „Cheat-Sheet“ mit den Notationselementen.

Übersicht über die Notationselemente der Goal Structuring Notation (GSN)
Abb. 2: Übersicht über die Notationselemente der Goal Structuring Notation (GSN)

Auch der AAMI TIR 38 Medical device safety assurance case report guidance nutzt diese Notation.

Ein Ausschnitt eines Safety Assurance Cases, der mit der GSN modelliert wurde, kann dann wie in Abb. 3 dargestellt aussehen.

Bild zeigt Beispiel für einen Safety Assurance Case, der mit der Goal Structuring Notation GSN modelliert ist.
Abb. 3: Beispiel für einen Safety Assurance Case, der mit der Goal Structuring Notation (GSN) modelliert ist.
Tipp

Ob absichtlich oder nicht: Die AAMI hat eine hier kostenfrei die ältere Version des AAMI TIR 38 aus dem Jahr 2014 zum Download bereitgestellt.

b) Weitere grafische Modellierungssprachen

Eine etwas einfachere Notation nennt sich Claim Argument Evidence (CAE). Auch für diese Sprache gibt es Modellierungswerkzeuge.

Auch SysML wird als Vielzweck-Modellierungssprache für die Darstellung von Safety Assurance Cases genutzt.

Mit allgemeinen Zeichenwerkzeugen wie draw.io lassen sich alle Notationen darstellen.

4. Vorgehen beim Erstellen von Safety Assurance Cases

a) Zweckbestimmung erstellen

Eine wichtige Voraussetzung, um Safety Assurance Cases zu erstellen, ist eine vollständige Zweckbestimmung einschließlich der vorgesehenen Nutzer und der vorgesehenen Nutzungsumgebung. Denn davon hängen der Kontext und einige Annahmen ab.

Weiterführende Informationen

Der Artikel zum Erstellen von Zweckbestimmungen nennt Ihnen die Aspekte, die dieses Dokument festlegen sollte, um die regulatorischen Anforderungen zu erfüllen.

Die Checkliste in Anhang C der EN ISO 14971:20212 hilft, zum einen um die Zweckbestimmung und den Kontext zu bestimmen, und zum anderen um erste Risiken abzuleiten.

b) Top-Level-Claims formulieren

Die Hersteller müssen die Top-Level-Claims formulieren und dafür eine Strategie festlegen. Manche starten mit einer oder mehreren allgemeinen Behauptungen wie „Das Medizinprodukt ist sicher“. Andere leiten die Top-Level-Claims aus den Top-Level-Gefährdungen ab.

Beispiel Infusionspumpen

Für Infusionspumpen hat die FDA im Guidance-Dokument „Infusion Pumps Total Product Life Cycle“ diese Top-Level-Claims indirekt festgelegt. Denn die Claims müssen darin bestehen, dass die folgenden Probleme nicht auftreten:

  • Fehler bei Verabreichung der Infusion, z.B. durch eine falsche Dosis, ein falsches Volumen, zum falschen Zeitpunkt oder Ort
  • Inkorrekte Therapie durch ein falsch ausgewähltes oder verabreichtes Medikament
  • Biologische oder chemische Verunreinigung, z.B. durch einen unbeabsichtigten Kontakt oder eine ungewollte biologische Reaktion von Menschen auf/mit einer Substanz
  • Verletzung, z.B. Verbrennungen, Schnitte, Luftinfusionen, elektrischer Schock
Vorsicht!

Beachten Sie: Die FDA wirf leider die Begriffe Gefährdung (hazard), Schaden (harm) und Ursachen (cause) durcheinander. Eine Verbrennung ist keine Gefährdung, sondern ein Schaden. Wahrscheinlich meint sie auch biologische oder chemische Gefährdung und nicht Verunreinigung. Denn eine ungewollte Reaktion (Schaden) wird nicht nur durch Verunreinigungen verursacht.

Strategie

Eine der bewährten Strategien besteht in der Überlegung, dass die Sicherheit dann gewährleistet ist, wenn alle Gefährdungen bekannt und beherrscht sind.

Damit bieten sich für die Top-Level-Claims die Behauptungen an, dass genau diese Gefährdungen bzw. Gefährdungsklassen beherrscht sind.

c) Untergeordnete Claims formulieren

Die FDA gibt vor, dass Hersteller von Infusionspumpen die „Gefährdungsklassen“ in einzelne Gefährdungen zerlegen. Bei dieser Risikoanalyse müssen Sie verschiedene Ursachen (sources) betrachten:

  • Operational Sources, z.B. eine Verstopfung der Leitung durch Ausfällung von Substanzen
  • Environmental Sources, z.B. Fehlfunktionen durch EMV-Probleme
  • Electrical Sources, z.B. Batterieversagen oder zu hohe Ableitströme
  • Hardware Sources, z.B. Netzwerkfehler, Fehlalarme durch Sensorfehler
  • Software Sources, z.B. Nullpointer-Exception, Memory Leak
  • Mechanical Sources, z.B. Motorausfall oder Schädigung des Netzkabels
  • Biological and Chemical Sources, z.B. nicht biokompatible Materialien oder Schädigung des Geräts durch Reinigungsmittel
  • Use Sources, z.B. Fehlprogrammierung wegen mangelnder Gebrauchstauglichkeit
Tipp

Bei anderen Geräten existieren diese Listen an Gefährdungen und Ursachen nicht. Leiten Sie diese mit Hilfe der Methoden zur Gefährdungsanalyse wie der PHA, der FMEA oder der FTA ab.

Die (Sub-)Claims, d.h. die Behauptungen des Herstellers, bestehen darin, dass genau diese Gefährdungen beherrscht bzw. die Ursachen beseitigt sind. Sub-Claims könnte somit lauten:

  • Das System entdeckt Luftblasen und stoppt konsequent die Infusion.
  • Die Risiken durch eine Überdosierung sind auf ein akzeptables Niveau verringert.

Die Strategie besteht somit auch auf dieser Ebene darin, alle relevanten Gefährdungen zu identifizieren und zu mitigieren.

d) Entscheiden, wie man Claims beweist

Die ISO 15026-2 nennt die Möglichkeiten, um Claims nachzuweisen. Hersteller können, wie oben dargestellt, zwei Wege beschreiten:

  • Entweder begründet der Hersteller mit genau einem „Argument“, dass der Claim erfüllt ist. Dazu muss sich das Argument auf einen oder mehrere Claims, Evidenzen oder Annahmen stützen.
  • Andernfalls muss er einen Claim durch einen oder mehrere (Sub-)Claims, Evidenz(en) oder Annahmen begründen.

Eine „Bibliothek“ bereits formulierter Argumente und Checklisten hilft Herstellern dabei, redundante Arbeit zu vermeiden und keine Argumente zu vergessen.

5. Fazit

a) Hilfreiche Methode

Safety Assurance Cases sind sinnvoll und helfen Herstellern, ihre Argumentation logisch strukturieren. Damit können sie sich, den Behörden und den Benannten Stellen plausibel machen, dass ihre Produkte den regulatorischen Anforderungen genügen.

Sie sind auch hilfreich, um bereits während der Entwicklung für identifizierte Risiken systematisch Maßnahmen zur Risikobeherrschung auf Vollständigkeit und Wirksamkeit zu bewerten. Hersteller sollten das Arbeiten mit den Safety Assurance Cases in den Entwicklungsprozess einweben, insbesondere beim Ableiten von Anforderungen und beim Erstellen von Systemarchitekturen.

Für Infusionspumpen schreibt die FDA diese Methode sogar vor.

b) Nützliche und weniger nützliche Literatur

Den Firmen, die Safety Assurance Cases nutzen wollen, stehen viele Quellen mit Vorgaben und Beispielen zur Verfügung, u.a..:

  • Normen, z.B. die ISO-15025-Familie
  • Technical Reports wie der AAMI TIR 38
  • Das Guidance-Dokument der FDA zu den Infusionspumpen
  • Spezifikationen mehrerer Modellierungssprachen wie der GSN
  • Das Metamodell der OMG

Allerdings sind diese Dokumente nicht aufeinander abgestimmt. Unterschiedliche Notationen und Konzepte erschweren das Verständnis.

Das FDA-Dokument nutzt keine grafische Darstellung. Es ist nicht in sich konsistent und das Konzept der Strategie nutzt es nur implizit. Allerdings liefert dieses Guidance-Dokument für Hersteller von Infusionspumpen eine gute Checkliste − und außerdem ist es für diese Hersteller Pflicht.

Als interessant in diesem Kontext erscheint die IEC 60601-1: Sie definiert für viele Gefährdungen bereits Safety Assurance Cases, ohne dies explizit zu formulieren. Im Anhang A beschreibt die Norm die Strategien und Argumente.

c) Die Methode sinnvoll einsetzen

Entscheiden, ob man sie einsetzt

Hersteller sollten Safety Cases besonders dann einsetzen, wenn sie regulatorische gefordert sind oder wenn es keine Normen gibt, die ausreichend produktspezifisch sind.

Die Entscheidung für oder gegen diese Methode ist auch keine binäre. Es spricht nichts dagegen, einen ersten „Sicherheitsfall“ (wie es die deutsche ISO 15406-2 nennt) zu erstellen und dann über den Produktlebenszyklus hinweg weitere zu ergänzen. Diesen iterativen Ansatz kontinuierlicher Verbesserung schätzen Behörden und Benannte Stellen sehr.

Als Brücke zwischen Risikomanagement und Architektur nutzen

Falls Hersteller Safety Assurance Cases verwenden, können sie diese als Brücke zwischen Risikomanagement und Systemarchitektur nutzen:

  • Die Claims entsprechen oft Aussagen, dass die Risiken beherrscht sind.
  • Die Argumente entsprechen den Anforderungen, die das Produkt und damit dessen Architektur erfüllen müssen.

Der Top-Level-Claim entspricht oft einem der letzten Sätze des Risikomanagementberichts, mit dem der Hersteller bekräftigt, dass das Produkt sicher ist und dessen Nutzen die Restrisiken überwiegt.

Über den kompletten Produktlebenszyklus einsetzen

Genauso wie sich das Produkt weiterentwickelt und neue Erkenntnisse aus der Post-Market-Phase gewonnen werden, sollten die Hersteller auch die Safety Assurance Cases aktualisieren. Das bedeutet zwar zusätzlichen Aufwand. Aber damit sind die Grundlagen z.B. für den Post-Market Surveillance Update Report gelegt. Denn dieser Bericht soll schließlich bestätigen, dass das Produkt weiterhin sicher ist und der Nutzen die Risiken überwiegt.

d) Voraussetzungen müssen erfüllt sein

Safety Assurance Cases nehmen den Firmen das Denken nicht ab. Im Gegenteil: Diese Methode setzt voraus, in logischen Konzepten und dem MECE-Prinzip folgend denken zu können. Ohne solch ein präzises Denken verkommen die Safety Assurance Cases zu Grafiken, die nur die Illusion nähren, man habe die Beweise (für die Sicherheit der Produkte) geführt.

Auditoren, Behörden und Benannten Stellen werden solche Logikbrüche dort schneller finden als in einer Risikotabelle mit Tausenden von Einträgen.

Das gilt aber auch für das eigene Team: Es kann diese (eigenen) Fehler ebenso schnell erkennen und anschließend fundierte Argumentationsketten aufbauen. Und genau darin liegt die Stärke der Safety Assurance Cases.


Wünschen Sie Unterstützung beim Erstellen von Safety Assurance Cases? Wünschen Sie sich, dass jemand Ihre Argumente auf Vollständigkeit und Plausibilität prüft? Melden Sie sich z.B. über das Kontaktformular. Das Team des Johner Instituts freut sich auf Ihre Nachricht.

The post Safety Assurance Cases: Leidvolle Diskussionen mit Auditoren abkürzen appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/iso-14971-risikomanagement/safety-assurance-cases/feed/ 2 3821856
Jobangebote: Stand 09.11.2020 https://www.johner-institut.de/blog/karriere/jobangebote/ https://www.johner-institut.de/blog/karriere/jobangebote/#respond Mon, 09 Nov 2020 07:00:00 +0000 http://www.johner-institut.de/blog/?p=6181 Alle Anfragen zu Jobangeboten und Jobgesuchen behandeln wir absolut vertraulich. Sie können über uns oder direkt mit den angegebenen Kontaktpersonen kommunizieren. November 2020 Fresenius Medical Care − XENIOS Die XENIOS AG, eine Tochter des Fresenius-Konzerns, bietet Jobs mit hervorragenden Perspektiven für: Ingenieur/Medizintechniker als Service Manager (m/w/d) (in Reutlingen)Projektmanager (m/w/d) mit Schwerpunkt ProduktionBetriebswirt/Naturwissenschaftler (m/w/d) als Produktmanager [...]

The post Jobangebote: Stand 09.11.2020 appeared first on Wissen zu medizinischer Software.

]]>
Alle Anfragen zu Jobangeboten und Jobgesuchen behandeln wir absolut vertraulich. Sie können über uns oder direkt mit den angegebenen Kontaktpersonen kommunizieren.

November 2020

Fresenius Medical Care − XENIOS

Die XENIOS AG, eine Tochter des Fresenius-Konzerns, bietet Jobs mit hervorragenden Perspektiven für:

Bayer AG in Berlin

Bayer bietet eine spannende Stelle als Medical System Software Engineer in Berlin an.

Klinikum Stuttgart

Ein Alumnus des Masterstudiums kehrt ins Gesundheitswesen zurück und sucht gleich neue Mitstreiterinnen und Mitstreiter:

2020-11-05_Regulatory Affairs

TIB Molbiol Syntheselabor GmbH

Die TIB Molbiol Syntheselabor GmbH sucht ebenfalls Verstärkung für ihr Team:

Werfen Sie gleich einen Blick in diese Angebote des inhabergeführten, mittelständigen Biotechnologieunternehmens in Berlin.

Infoteam sucht Software-Consultant

Die Infoteam AG ist eine etablierte Firma in Bubenreuth in der Nähe von Erlangen. Sie ist auf der Suche nach einem „Software-Consultant“ für den Bereich Medizinprodukte und IVD.

Am besten werfen Sie einen Blick in die Stellenausschreibung. Die Stelle ist übrigens ab sofort verfügbar.

Oktober 2020

a) Software Engineer bei Berlin Cert

Berlin Cert sucht eine/n Software Engineer (m/w/d) im Bereich Cybersecurity und/oder Penetrationtesting als wissenschaftliche Kraft in Teilzeit.

b) Das Johner Institut wächst weiter

Wir am Johner Institut wünschen uns weitere Kolleginnen und Kollegen, die uns helfen, die Nachfrage nach unserer Unterstützung zu bewältigen. Besonderen Bedarf haben wir an Menschen, die uns helfen bei

Auf unserer Webseite finden Sie die Stellenausschreibungen und unsere Philosophie. Wir freuen uns auch über Initiativbewerbungen, denn wir suchen nicht nur Menschen, die auf Stellen passen. Vielmehr schaffen wir auch Stellen für Menschen.

c) Das Kantonsspital Glarus (CH) sucht einen Medizin- oder Wirtschaftsinformatiker/in

Zum 01.01.2021 möchte das Kantonsspital in Glarus seine Stelle für eine/n Medizin- oder Wirtschaftsinformatiker/in (80-100 %) neu besetzen. Weiterführende Informationen entnehmen Sie bitte der Webseite des Spitals. Ebenso ist die Stellenausschreibung zu empfehlen:

d) Zühlke sucht Lead Quality Manager

Egal ob ISO9001, ISO 13485 oder ISO 27001: Sind sind gefragt! Denn Zühlke sucht in Frankfurt/Eschborn eine/n „Lead Quality Manager“.

Am besten gleich die Stellenausschreibung lesen.

e) Dräger baut sein Usability-Team aus

Die Drägerwerke in Lübeck suchen einen Usability-Experten bzw. Expertin:

Interessiert? Dann sehen Sie sich die Online-Ausschreibung gleich an. Ein Klick auf den Link genügt.

September 2020

a) Erbe sucht Qualitätsplaner

Die Firma Erbe in Tübingen hat die Stelle eines Qualitätsplaners zu besetzen. Kenntnisse der MDR und einschlägigen Normen sind hilfreich, um sich für diese interessante Position zu qualifizieren.

August 2020

Dedalus (ex Agfa Healthcare)

Die Übernahme der Agfa Healthcare hat offensichtlich keinen negativen Einfluss auf das Wachstum der Firma. Im Gegenteil: Die Firma sucht gleich drei Consultants im KAS-Umfeld:

Zudem sucht Dedalus einen Applikationsspezialisten im Bereich Medizincontrolling:

Qualitätsmanager bei der CGM

Die CompuGroup Medical sucht einen Qualitätsmanager IT Medizinprodukte (m/w/d).

The post Jobangebote: Stand 09.11.2020 appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/karriere/jobangebote/feed/ 0 6181
Klinische Bewertung von Software: Drei Beweise für die Konformität https://www.johner-institut.de/blog/regulatory-affairs/klinische-bewertung-von-software/ https://www.johner-institut.de/blog/regulatory-affairs/klinische-bewertung-von-software/#respond Thu, 05 Nov 2020 08:00:00 +0000 https://www.johner-institut.de/blog/?p=565161 Für die klinische Bewertung von Software gelten die gleichen gesetzlichen Anforderungen wie für die klinische Bewertung aller Medizinprodukte. Das heißt, als Hersteller von Medical Device Software (MDSW) müssen Sie genau wie alle anderen Hersteller eine klinische Bewertung für Ihr Produkt erstellen. Für Software, die ein In-vitro-Diagnostikum (IVD) darstellt, muss eine Leistungsbewertung durchgeführt werden. Das wiederum [...]

The post Klinische Bewertung von Software: Drei Beweise für die Konformität appeared first on Wissen zu medizinischer Software.

]]>
Für die klinische Bewertung von Software gelten die gleichen gesetzlichen Anforderungen wie für die klinische Bewertung aller Medizinprodukte. Das heißt, als Hersteller von Medical Device Software (MDSW) müssen Sie genau wie alle anderen Hersteller eine klinische Bewertung für Ihr Produkt erstellen. Für Software, die ein In-vitro-Diagnostikum (IVD) darstellt, muss eine Leistungsbewertung durchgeführt werden.

Das wiederum erfordert klinische Daten zu dem Produkt, vielleicht aus einer klinischen Prüfung bzw. einer klinischen Leistungsstudie, oder zu einem nachgewiesenen Äquivalenzprodukt. Aber für Software ergibt dieser Ansatz oft wenig Sinn.

Doch das MDCG-Dokument MDCG 2020-1: Guidance on Clinical Evaluation (MDR)/Performance Evaluation (IVDR) of Medical Device Software zeigt einen möglichen alternativen Weg für Software-Produkte auf. Die Benannten Stellen haben nun erste klinische Bewertungen von Software akzeptiert, die von uns auf Basis dieses Dokuments erstellt wurden.

1. Kurze Wiederholung: Was ist eine klinische Bewertung bzw. eine Leistungsbewertung?

Definition: Klinische Bewertung eines Medizinprodukts
„klinische Bewertung“ bezeichnet einen systematischen und geplanten Prozess zur kontinuierlichen Generierung, Sammlung, Analyse und Bewertung der klinischen Daten zu einem Produkt, mit dem Sicherheit und Leistung, einschließlich des klinischen Nutzens, des Produkts bei vom Hersteller vorgesehener Verwendung überprüft wird“
Quelle: MDR Artikel 2
Definition: Leistungsbewertung eines IVDs
„Leistungsbewertung“ bezeichnet eine Beurteilung und Analyse von Daten zur Feststellung oder Überprüfung der wissenschaftlichen Validität, der Analyseleistung und gegebenenfalls der klinischen Leistung eines Produkts“
Quelle: IVDR Artikel 2

Damit werden die Ziele zumindest indirekt genannt: Es geht um die Prüfung, ob das Medizinprodukt

  • den Nutzen stiftet, den der Hersteller verspricht,
  • sicher ist und keine Risiken birgt, die in der Risikoanalyse nicht bereits identifiziert und als akzeptabel bewertet wurden, und
  • die Leistung erbringt, die der Hersteller verspricht.
Weiterführende Informationen

Lesen Sie hier weitere Artikel über die klinische Bewertung sowie über die Leistungsbewertung von IVD.

2. Klinische Bewertung von Software: Die Besonderheiten

a) Der wesentliche Unterschied: Die Schnittstellen

Während andere Medizingeräte viele Formen an „Outputs“ (= Schnittstellen nach außen) haben, wie elektrische Energie (z.B. HF-Chirurgie-Gerät), elektromagnetische Energie (z.B. CT) oder mechanische Energie (z.B. Ultraschallgerät), ist der „Output“ von Stand-alone-Software auf Informationen beschränkt.

Software unterscheidet sich von anderen Medizinprodukten durch die Schnittstellen. Und damit auch die klinische Bewertung von Software.
Abbildung 1: Medical-Device-Software und ihre Schnittstellen

Software unterscheidet sich von anderen Medizinprodukten also durch die Schnittstellen:

  1. Benutzer-Produkt-Schnittstelle, oft grafische Benutzungsschnittstelle (GUI)
  2. Produkt-Produkt-Schnittstelle, insbesondere Datenschnittstellen

Daher muss die klinische Bewertung bei Software prüfen, ob die Informationen dem Anwender einen Nutzen liefern, beispielsweise bei Diagnose oder Therapieauswahl, oder ob sie nützliche Informationen an andere Produkte weitergibt.

Dieses Konzept kommt IVD-Herstellern sicherlich bekannt vor. So liegt der Nutzen eines IVDs stets in der Bereitstellung angemessener medizinischer Informationen (s. IVDR, Erwägungsgrund 64). Der klinische Nachweis wird für die in-vitro diagnostische Software durch die Leistungsbewertung erbracht.

Vorsicht!

Den Fall, dass die Software zur Ansteuerung von Medizinprodukten dient, betrachten wir hier nicht. Denn die Software wäre in den meisten Fällen ein Zubehör zu dem jeweiligen Produkt, zu dem bereits eine klinische Bewertung existieren sollte.

b) Besonderer Nutzen von Stand-alone-Software

Stand-alone-Software dient v.a. einem der folgenden Zwecke:

  • Diagnose oder Bereitstellung diagnoserelevanter Informationen (Medizinprodukte/IVD)
  • Auswahl geeigneter Therapien, z.B. Auswahl eines geeigneten Medikaments oder Entscheidung, ob Chemotherapie oder Bestrahlung (Medizinprodukte/IVD)
  • Durchführen der Therapie selbst, z.B. Berechnung des Einstichwinkels eines chirurgischen Instruments, Bestrahlungsplanung, Dosisberechnung (nur Medizinprodukte)
Weiterführende Informationen

Das Guidance-Dokument MDCG 2019-11 „Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR“ liefert Vorgaben zur Unterscheidung von Software als Medizinprodukt bzw. IVD.

c) Klinische Bewertung bzw. Leistungsbewertung anhand Verifizierung und Validierung

Die klinischen Bewerter und Leistungsbewerter stellen sich bei Softwareprodukten häufig die Frage, welche Aspekte sie überhaupt bewerten müssen. Meistens ist es sinnvoll, sich auf die Algorithmen zu konzentrieren, z.B.:

  • Lässt ein Bildbearbeitungsalgorithmus Tumore mit ausreichender Wahrscheinlichkeit erkennen?
  • Hilft der Algorithmus eines Arzneimitteltherapie-Sicherheitssystems, Kontraindikationen und Wechselwirkungen zu erkennen und Fehlmedikationen zu vermeiden?

Manchmal sind diese Algorithmen banal. Dann stellt sich die Frage, was eine klinische Bewertung bzw. Leistungsbewertung von Software an Erkenntnissen bringen soll. In manchen Fällen kann es ausreichen, anhand von Verifizierungsergebnissen zu argumentieren.

Falls die Algorithmen hingegen komplexer sind, bedarf es des Beweises, dass sie den versprochen Nutzen bringen, d.h. klinisch valide sind. Genau diesen Ansatz verfolgt das MDCG-Dokument MDCG 2020-1.

3. Mit drei Beweisen zur klinischen Bewertung von Software laut MDCG 2020-1

Laut MDCG muss der Hersteller drei Beweise erbringen:

  1. Wissenschaftliche Validität („scientific validity“)
  2. Technische/analytische Leistungsfähigkeit („technical performance/analytical performance“)
  3. Klinische Leistungsfähigkeit („clinical performance“)

Bei der Beweisführung sollte der Hersteller dabei fünf Phasen durchlaufen:

  1. Planung
  2. Datensammlung
  3. Bewertung der Daten
  4. Analyse der Daten
  5. Dokumentation
Grafik mit einem Überblick über die Phasen der klinischen Bewertung von MDSW laut MDCG 2020-1
Abbildung 2: Überblick über die Phasen der klinischen Bewertung von Medical-Device-Software (MDSW) laut MDCG 2020-1. Sie gelten gleichermaßen für die Leistungsbewertung von IVD.

Diese drei Beweistypen werden im Folgenden vorgestellt.

a) Beweis 1: Wissenschaftliche Validität

Quelle MDCG 2020-1

Definition: VALID CLINICAL ASSOCIATION / SCIENTIFIC VALIDITY
„…is understood as the extent to which, the MDSW’s output (e.g. concept, conclusion, calculations) based on the inputs and algorithms selected, is associated with the targeted physiological state or clinical condition. This association should be well founded or clinically accepted“
MDCG 2020-1

Die wissenschaftliche Validität ist also der Evidenzbeweis, dass die „Outputs“ des Produkts (hier der Software) mit einem klinischen oder physiologischen Zustand verknüpft sind.

Ein Beispiel stellt die Berechnung eines Scores dar, der tatsächlich ein Maß für ein bestimmtes Risiko darstellen muss.

Zum Nachweis der wissenschaftlichen Evidenz sollen die Hersteller folgende Quellen nutzen:

  • Wissenschaftlicher Fachliteratur („peer reviewed articles“, Konferenzartikel)
  • Empfehlungen der Behörden
  • Wissenschaftliche Datenbanken, auch mit Ergebnissen klinischer Studien
  • Expertenmeinungen, z.B. in Büchern und Leitfäden

b) Beweis 2: Technische Leistungsfähigkeit

Definition: TECHNICAL PERFORMANCE / ANALYTICAL PERFORMANCE
„… is the demonstration of the MDSW’s ability to accurately, reliably and precisely generate the intended output, from the input data.“
MDCG 2020-1

Die Verifizierung der technischen Leistung ist somit die Demonstration der Fähigkeit des Software-Produkts, aus den Eingabedaten genau, zuverlässig und präzise die beabsichtigte Ausgabe zu erzeugen.

Die technische Leistungsfähigkeit beweisen Hersteller im Rahmen der Verifizierung und Validierung (V&V). Dabei sollen sie ggf. zurückgreifen auf:

  • 1. Verifizierungsaktivitäten, z.B.:
    • Unit-Tests
    • Integrationstests
    • Systemtests
  • 2. Validierungsaktivitäten, z.B. anhand von:
    • Kuratierten Datenbanken oder Registern
    • Referenzdatenbanken
    • Bereits gesammelten Patientendaten

Üblicherweise referenzieren Medizinprodukte-Hersteller bei der klinischen Bewertung von Software diese V&V-Ergebnisse.

IVD-Hersteller bewerten die technische Leistungsfähigkeit der Software abschließend während der analytischen Leistungsbewertung des IVDs und berücksichtigen vorliegende V&V-Ergebnisse.

c) Beweis 3: Klinische Leistungsfähigkeit

Definition: CLINICAL PERFORMANCE
„…is the demonstration of a MDSW’s ability to yield clinically relevant output in accordance with the intended purpose“
MDCG 2020-1

Der Hersteller muss bei der klinischen Leistungsfähigkeit eine klinische Relevanz in Bezug auf die Zweckbestimmung des Produkts nachweisen. Die klinische Relevanz einer Medical-Device-Software zeigt sich als positive Auswirkung auf

  • die Gesundheit eines Individuums, ausgedrückt in Form von messbaren, patientenrelevanten klinischen Endpunkten einschließlich Endpunkt(en) im Zusammenhang mit der Diagnose, Risikovorhersage, Vorhersage der Behandlungsreaktion(en), oder
  • Aspekte, die mit seiner Funktion zusammenhängen, z.B. die der Früherkennung, Überwachung, Diagnose oder Hilfe zur Diagnose von Patienten, oder
  • das Patientenmanagement oder zur öffentlichen Gesundheit.

Diese Daten können ebenso aus vom Hersteller durchgeführten klinischen Studien stammen wie auch aus anderen Quellen. Die Hersteller werden ermutigt, auch auf bestehende Daten von alternativen Verfahren und Produkten zurückzugreifen.

Sie sollten z.B. die folgenden Informationen heranziehen, um die klinische Leistungsfähigkeit zu beurteilen:

  • Klinische/diagnostische Sensitivität und/oder klinische/diagnostische Spezifität
  • Positiver/negativer prädiktiver Wert
  • Number needed to treat (Anzahl der Patienten, die aufgrund einer Erkrankung oder präventiv behandelt werden müssen, um ein zusätzliches Ereignis wie (Folge-) Krankheit oder Tod zu vermeiden)
  • Number needed to harm (Anzahl der Patienten, die diagnostiziert/behandelt werden müssen, um eine unerwünschte Wirkung auf einen Patienten zu haben)
  • Benutzerfreundlichkeit/Benutzeroberfläche
  • Konfidenzintervall(e)

d) Zusammenfassung der Schritte für die klinische Bewertung von Software

Das folgende Ablaufschema zeigt noch einmal die wesentlichen Schritte der Erstellung der klinischen Bewertung:

Grafik mit den Schritte bei der Durchführung der initialen klinischen Bewertung einer MDSW
Abbildung 3: Die Schritte bei der Durchführung der initialen klinischen Bewertung einer MDSW

4.  Klinische Bewertung von Software nach der Inverkehrbringung (Post-Market)

Die Hersteller müssen nach der Inverkehrbringung die Sicherheit, die Wirksamkeit und die Leistung des MDSW aktiv und kontinuierlich überwachen.

Wie bei allen Herstellern können die Informationen u.a. Beschwerde, direktes Endbenutzer-Feedback oder neu veröffentlichte Forschungen/Richtlinien umfassen. Ganz besonders relevant für MDSW ist aber die Erfassung von REAL-WORLD PERFORMANCE DATA, da diese mit Software relativ leicht zu gewinnen sind.

Dies ermöglicht sehr schnell und effektiv

  • die rechtzeitige Erkennung und Korrektur von Fehlfunktionen,
  • die Erkennung von systematischem Missbrauch,
  • ein Verständnis der Benutzerinteraktionen und
  • die laufende Überwachung der vorgesehenen klinischen Leistung (z.B. Sensitivität, Spezifität).
Weiterführende Informationen

Sie finden hier Informationen zur Post-Market Surveillance und zum Post-Market Surveillance Plan.

5. Beurteilung des Evidenz-Niveaus und der Daten

Die Hersteller müssen in erster Linie selbst entscheiden, ob für jeden Schritt das Niveau der Daten ausreichend ist und dies ggf. auch begründen. Hierbei geht es sowohl um die Menge als auch um die Qualität der Daten. Diese Bewertung kann sich an den folgenden Fragen orientieren:

a) Ausreichende Menge

  • Unterstützen die Daten den Verwendungszweck, die Indikationen, die Zielgruppen, die klinischen Behauptungen und die Kontraindikationen?
  • Sind die klinischen Risiken und die analytische Leistung bzw. klinische Leistung untersucht worden?
  • Wurden relevante MDSW-Merkmale wie die Dateneingabe und -ausgabe, die angewandten Algorithmen oder die Art der Zusammenschaltung bei der Generierung der Daten zur Unterstützung der Leistung des Produkts berücksichtigt?
  • Wie hoch ist der Innovationsgrad bzw. die Geschichte auf dem Markt (Wie groß ist der Bestand an wissenschaftlichen Erkenntnissen)?

b) Ausreichende Qualität

  • Waren die Art und das Design der Studie bzw. des Tests geeignet, die Endpunkte zu erreichen?
  • War der Datensatz angemessen und aktuell (Stand der Technik)?
  • War der statistische Ansatz angemessen, um zu einer gültigen Schlussfolgerung zu gelangen?
  • Wurden alle ethischen, rechtlichen und regulatorischen Erwägungen bzw. Anforderungen berücksichtigt?
  • Besteht ein Interessenkonflikt?

c) Nachweis der Konformität ohne klinische Daten

In einigen Fällen, insbesondere bei Medical-Device-Software der niedrigeren Risikoklassen I und IIa, sind klinische Daten zum Nachweis der Konformität oft nicht angemessen. Sowohl die MDR (Artikel 61, Abschnitt 10) also auch das MDCG-Dokument 2020-1 erlauben eine Ausnahme.

Der Nachweis der Übereinstimmung mit grundlegenden Sicherheits- und Leistungsanforderungen kann allein auf der Grundlage der Ergebnisse nichtklinischer Testmethoden einschließlich Leistungsbewertung, technischer Prüfung („bench testing“) und vorklinischer Bewertung erfolgen. Dies muss aber auf jeden Fall begründet werden. Dabei müssen die folgenden Punkte berücksichtigt werden:

  • Risikomanagements des Herstellers
  • Berücksichtigung der besonderen Merkmale des Zusammenspiels zwischen dem Produkt und dem menschlichen Körper
  • Bezweckte klinischen Leistung und Angaben des Herstellers zur Leistung
Vorsicht!

ACHTUNG: Die Hersteller müssen trotzdem eine klinische Bewertung erstellen, die zumindest die Begründung für den Ausnahmeweg, den Nachweis der nichtklinischen Testmethoden sowie die Darlegung des State of the Art enthält.

Auch für In-vitro-Diagnostika gilt, dass, wenn bestimmte Leistungsanforderungen nicht anwendbar sind, diese begründet ausgeschlossen werden können. Die IVD-Hersteller beschreiben ihre beabsichtigte Strategie zur Leistungsbewertung im produktspezifischen Leistungsbewertungsplan. Dort legen sie auch den Stand der Technik dar. Im Leistungsbewertungsbericht werden die Ergebnisse zum klinischen Nachweis und zum Nutzen-Risiko-Verhältnis abschließend zusammengefasst und bewertet.

6.  FDA & IMDRF zur Clinical Evaluation von Software as a Medical Device (SaMD)

Gemeinsam mit dem IMDRF hat die FDA bereits ein sehr ähnliches Guidance-Dokument „Software as a Medical Device: Clinical Evaluation“ publiziert. Es fordert, dass die Hersteller mit der klinischen Bewertung von Medizinprodukte-Software bzw. mit der Leistungsbewertung von IVD-Software die klinische Validität des Produkts überprüfen. Damit weisen sie nach, dass die beabsichtigte Zweckbestimmung erfüllt ist und keine inakzeptablen Risiken bestehen. Einige der Definitionen weichen von denen der MDCG ab. Das führt unter Umständen zu einem hohen Mehraufwand, falls beide Länder bedient werden müssen.

SOFTWARE AS A MEDICAL DEVICE (SAMD): CLINICAL EVALUATION
Abbildung 4: Das Guidance-Dokument im Überblick (zum Vergrößern klicken)

Die FDA gibt Hinweise, welche Schritte in Abhängigkeit von gewissen Parametern (Risikoklasse, Innovationsgrad etc.) gemacht werden müssen.

a) Klasse für die Software bestimmen

Die FDA verwendet für die klinische Bewertung von Software eine Klassifizierung aus anderen IMDRF Dokumenten:

 Significance of information provided by SaMD to healthcare decision
State of healthcare
situation or condition
Treat or diagnoseDrive clinical managementInform clinical management
CriticalIV.iIII.iII.i
SeriousIII.iiII.iiI.ii
Non-seriousII.iiiI.iiiI.i

Als Beispiele für die Anwendungsgebiete nennt die FDA:

  • „Treat or diagnose“
    • Treat
    • Provide therapy to a human body using other means
    • Diagnose
    • Detect
    • Screen
    • Prevent
    • Mitigate
    • Lead to an immediate or near term action
  • „Drive clinical management“
    • Aid in treatment
    • Provide enhanced support to safe and effective use of medicinal products
    • Aid in diagnosis
    • Help predict risk of a disease or condition
    • Aid to making a definitive diagnosis
    • Triage early signs of a disease or condition
    • Identify early signs of a disease or condition.
  • „Inform clinical management“
    • Inform of options for treatment
    • Inform of options for diagnosis
    • Inform of options for prevention
    • Aggregate relevant clinical information
    • Will not trigger an immediate or near term action

b) Evidenz abhängig von der Klasse nachweisen

Abhängig von der Klasse müssen die Hersteller Folgendes nachweisen:

 Grüne KlasseGelbe KlasseRote Klasse
Analytische ValiditätJaJaJa
Wissenschaftliche ValiditätJaJaJa
Bei neuen Verfahren zusätzliche Anforderungen
Klinische LeistungsfähigkeitNur bei neuen VerfahrenNur bei diagnostischen Produkten der Klasse II.iii und bei neuen VerfahrenNur bei diagnostischen Produkten und bei neuen Verfahren
Unabhängiges Review (Objektive und kompetente Person außerhalb des Herstellers)NeinNeinJa

c) Notwendige Evidenz bestimmen

Falls der Hersteller über Kompetenzen und Kapazitäten verfügt, besteht der nächste Schritt darin, die notwendige Evidenz festzulegen. Das heißt, der Hersteller sollte anhand der obigen Tabelle entscheiden, welche Nachweise zu erbringen sind:

  1. Analytische Validität
  2. Wissenschaftliche Validität
  3. Klinische Leistungsfähigkeit

Was sich hinter diesen drei Aspekten verbrigt, finden Sie oben ausgeführt.

d) Daten erheben

Das Erheben der Daten kann genauso erfolgen wie oben beschrieben. Auch bei der FDA zählen zu den üblichen Datenquellen:

  • Wissenschaftliche Fachliteratur
  • Ergebnisse der Verifizierung und Validierung der Software
  • Vorhandene Post-Market-Daten von eigenen und/oder fremden Äquivalenzprodukten
  • Ergebnisse klinischer Studien

e) Daten auswerten und klinische Bewertung von Software erstellen

Auch bei der FDA besteht der nächste Schritt darin, die Daten auszuwerten und die klinische Bewertung bzw. (bei IVD) den abschließenden Leistungsbewertungsbericht zu schreiben. Für Medizinprodukte gibt die MEDDEV 2.7/1 Hinweise zur Struktur von klinischen Bewertungen, auch wenn das MEDDEV-Dokument die FDA nicht im Anwendungsbereich hat.

Weiterführende Informationen

Der Auditgarant enthält neben Videos zur klinischen Bewertung auch Templates für klinische Bewertungen mit Beispielen und einer Anleitung zum Ausfüllen.

f) Fazit zu den Guidance-Dokumenten von IMDRF bzw. FDA

Der Aufwand für die klinische Bewertung bzw. Leistungsbewertung soll risikobasiert angepasst werden. Die FDA schlägt vor, bei der klinischen Bewertung von Software wie folgt vorzugehen:

Klinische Bewertung von Software: Der Ablauf laut FDA (zum Vergrößern klicken)
Abbildung 5: Klinische Bewertung von Software: Der Ablauf laut FDA (zum Vergrößern klicken)

Der IMDRF hat ein nicht leicht zu verdauendes Werk verfasst. Die Autoren stellen die verschiedenen Aspekte der klinischen Bewertung bzw. der Leistungsbewertung von Software gut dar. Sie verweisen auf viele weitere Publikationen der gleichen Organisation.

7. Zusammenfassung

Mit dem Dokument MDCG 2020-1 zur klinischen Bewertung bzw. zur Leistungsbewertung von Software versucht die europäische Medical Device Coordination Group den besonderen Anforderungen bei Software-Produkten Rechnung zu tragen. Die Autoren stellen die verschiedenen Aspekte der klinischen Bewertung von Software als Medizinprodukt bzw. IVD recht gut dar. Der Ansatz ist sehr viel pragmatischer als der bisherige.

Manches bleibt jedoch noch vage. Dank einiger konkreter Beispiele im Anhang wird verständlich, was gemeint ist sowie wann welcher Schritt des Algorithmus verpflichtend wird und wann nicht. Hier wäre eine genauere Abgrenzung der Notwendigkeiten (z.B. anhand der Einteilung der Funktionalitäten oder Klassifizierung der Software) sehr wünschenswert.

Außerdem fehlt jeglicher Bezug zu anderen MDCG-Guidance-Dokumenten hinsichtlich allgemeiner Aspekte der klinischen Bewertung, z.B. Anforderung an die Autoren.

Die FDA bietet ebenfalls ein Guidance-Dokument an, welches einen sehr ähnlichen Ansatz verfolgt. Hierin wird sehr viel klarer dargestellt, wann welche Nachweisausprägungen benötigt werden.

Wie bei jeder klinischen Bewertung sind die Anforderungen des MDCG-Guidance-Dokuments ohne ein wissenschaftlich und medizinisch kompetentes Team nicht umsetzbar.


Das Johner Institut ist darauf spezialisiert, klinische Bewertungen für Medizinprodukte konform mit MEDDEV 2.7/1 und MDCG 2020-1 zu erstellen und sicherzustellen, dass diese von den Benannten Stellen akzeptiert werden.

Gern unterstützt Sie das IVD-Team des Johner Instituts zudem bei der Erarbeitung einer Leistungsbewertungsstrategie für Ihre IVD-Software. 

Geben Sie gerne Bescheid (z.B. über das Kontaktformular), falls Sie an der Unterstützung durch die Expertinnen und Experten des Johner Instituts für klinische Bewertungen bzw. Leistungsbewertungen interessiert sind.

The post Klinische Bewertung von Software: Drei Beweise für die Konformität appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/regulatory-affairs/klinische-bewertung-von-software/feed/ 0 565161
Autonome Systeme: 4 Vorteile für Medizinproduktehersteller https://www.johner-institut.de/blog/systems-engineering/autonome-systeme/ https://www.johner-institut.de/blog/systems-engineering/autonome-systeme/#comments Tue, 03 Nov 2020 07:00:00 +0000 https://www.johner-institut.de/blog/?p=3810459 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 [...]

The post Autonome Systeme: 4 Vorteile für Medizinproduktehersteller appeared first on Wissen zu medizinischer Software.

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

Bild zeigt mehrere selbstfahrende Autos als Beispiel für autonome Systeme.
Abb. 1: Selbstfahrende Autos als Beispiel autonomer Systeme

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

In der Medizin existieren ebenfalls autonome Systeme, beispielsweise

Schematische Zeichnung, die ein autonomes System für die Schmerzmittelbehandlung zeigt. Es besteht aus einem Patient, mehreren Monitoren, einer Infusionspumpe, einem Knopf, mit dem der Patient mehr Schmerzmittel "beantragen" kann sowie einer zentralen Steuereinheit, die auch Alarme auslösen kann.
Abb. 2: Autonomes System zur Dosierung von Schmerzmitteln

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.

Weiterführende Informationen

Lesen Sie hier mehr zu den Herausforderungen und regulatorischen Anforderungen an den Einsatz künstlicher Intelligenz, insbesondere des Machine Learnings, in der Medizin.

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.

Weiterführende Informationen

Lesen Sie hier mehr zur Interoperabilität und erfahren Sie, welche Protokolle, Formate, Taxonomien und Nomenklaturen auf den verschiedenen Interoperabilitätsebenen zum Einsatz kommen.

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.
Grafik mit Box-Whisker-Plot, die verschiedene Genauigkeiten von Messgeräten illustrieren.
Abb. 3: Medizinprodukte können Messwerte mit unterschiedlicher Genauigkeit liefern

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.
Weiterführende Informationen

Lesen Sie hier mehr zu den Vorteilen von Computer-based Modeling and Simulation.

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.

The post Autonome Systeme: 4 Vorteile für Medizinproduktehersteller appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/systems-engineering/autonome-systeme/feed/ 2 3810459
Risikoprioritätszahl (RPZ): Definition und Berechnung https://www.johner-institut.de/blog/iso-14971-risikomanagement/risikoprioritaetszahl-rpz/ https://www.johner-institut.de/blog/iso-14971-risikomanagement/risikoprioritaetszahl-rpz/#comments Thu, 29 Oct 2020 05:00:00 +0000 http://www.johner-institut.de/blog/?p=5990 Firmen, die beispielsweise einen Bezug zur Pharmaindustrie haben, verwenden die Risikoprioritätszahl (RPZ). Es gibt jedoch Branchen, in denen das Risiko nicht über eine RPZ bewertet werden darf. Beispielsweise in der Medizintechnik ist die Definition der Risikoprioritätszahl nicht konform mit der Definition des Begriffs Risiko gemäß der ISO 14971. Das kann im Audit und bei Produktzulassungen zu Beanstandungen führen. [...]

The post Risikoprioritätszahl (RPZ): Definition und Berechnung appeared first on Wissen zu medizinischer Software.

]]>
Firmen, die beispielsweise einen Bezug zur Pharmaindustrie haben, verwenden die Risikoprioritätszahl (RPZ).

Es gibt jedoch Branchen, in denen das Risiko nicht über eine RPZ bewertet werden darf. Beispielsweise in der Medizintechnik ist die Definition der Risikoprioritätszahl nicht konform mit der Definition des Begriffs Risiko gemäß der ISO 14971. Das kann im Audit und bei Produktzulassungen zu Beanstandungen führen.

1. Berechnung der RPZ

Definition: Risikoprioritätszahl (RPZ)

„Die Risikoprioritätszahl berechnet sich als Produkt aus drei Größen

  1. Entdeckungswahrscheinlichkeit eines Fehlers,
  2. Wahrscheinlichkeit des Auftretens des Fehlers und
  3. Schweregrad des resultierenden Schadens.“
Quelle: Wikipedia zur FMEA
Grafik, die Koordinatensystem mit drei Achsen zeigt. Die Risikoprioritätszahl RPZ ist darin nicht erkennbar.
Abb. 1: Die Risikoprioritätszahl (RPZ) ist das Produkt aus drei Größen Wahrscheinlichkeit des Fehlers, Entdeckungswahrscheinlichkeit und Schweregrad bzw. Auswirkung des Fehlers. Die Akzeptanz des Risikos müsste als vierte Dimension dargestellt werden, was in dieser Darstellung nicht gelingt.

Meist quantifizieren die Hersteller diese drei Größen:

  1. Entdeckungswahrscheinlichkeit eines Fehlers: gering (10) bis hoch (1)
  2. Wahrscheinlichkeit des Auftretens des Fehlers: gering (1) bis hoch (10)
  3. Schweregrad des resultierenden Schadens: gering (1) bis hoch (10)

Damit kann die Risikoprioritätszahl RPZ Werte zwischen 1 und 1000 annehmen.

Beispiel

Ein Hersteller bestimmt die Wahrscheinlichkeit eines Fehlers als hoch (z.B. 9 von 10), die Entdeckungswahrscheinlichkeit als mittel (z.B. 5 von 10) und die Auswirkung des Fehlers als niedrig (z.B. 3 von 10). Dann berechnet sich die RPZ als 9 x 5 x 3 = 135.

In den Risikomanagementakten werden die Risiken häufig tabellarisch dargestellt:

Risiko-IDFehler = auslösende UrsacheMögliche Folge, SchadenWahrscheinlichkeit des Fehlers1 – Entdeckungs-wahrscheinlichkeitSchweregrade des SchadensRisikoprioritäts-zahl RPZMaß-nahmen
IDTextTextZahl
(1–10)
Zahl
(1–10)
Zahl
(1–10)
Zahl
(1–1000)
Text 
R001953135 

2. Worauf Sie bei Verwendung der RPZ achten sollten

a) Die RPZ quantifiziert nicht das Risiko konform ISO 14971

Vergleichen wir die Risikoprioritätszahl mit der Definition des Begriffs Risiko gemäß ISO 14971.

Definition: Risiko
„Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und des Schweregrades dieses Schadens“
Quelle: ISO 14971:2012 und ISO 14971:2019

Im Anhang schreibt die Norm sogar:

Das Risiko ist in 2.16 als Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und des Schweregrades dieses Schadens definiert. Dies bedeutet nicht, dass die beiden Faktoren multipliziert werden [Hervorhebung durch Johner Institut], um zu einem Risikowert zu gelangen. Ein Weg zur Beschreibung des Risikos und zur Veranschaulichung der Bedeutung der Definition wäre ein zweidimensionales Risikodiagramm.

Diese Definition kennt nur zwei Größen. Daher lässt sich das Risiko in einer zweidimensionalen Darstellung – konkret in einer Matrix – darstellen. Doch wie will man eine RPZ visualisieren? In 3D?

Einige versuchen, die RPZ dadurch in die „2D-Welt“ zu retten, indem sie behaupten, die Wahrscheinlichkeit des Schadens entspreche dem Produkt aus Auftretenswahrscheinlichkeit und (1 – Entdeckungswahrscheinlichkeit). Doch das stimmt nicht, denn bei einer Entdeckungswahrscheinlichkeit von null müsste die Auftretenswahrscheinlichkeit des Fehlers im Sinne der RPZ mit der Wahrscheinlichkeit des Schadens übereinstimmen. Das ist zum Glück nicht der Fall, denn nicht jeder (unentdeckte) Fehler führt automatisch zu einem Schaden.

b) Die RPZ kann zusätzlichen Aufwand verursachen

Selbst wenn das Johner Institut dafür plädiert, die Ursachenkette von der auslösenden Ursache bis zur „Gerätekante“ und von der „Gerätekante“ bis zum Schaden zu trennen und deshalb mit zwei Wahrscheinlichkeiten zu arbeiten, muss klar sein, dass für die RPZ immer zwei Wahrscheinlichkeiten bestimmt werden müssen. Zudem müssen „echte Wahrscheinlichkeiten“ in normierte Wahrscheinlichkeiten (z.B. von 1–10) umgerechnet werden.

Die Hersteller stehen vor der Aufgabe, statt für zwei Dimensionen die Klassifizierungskriterien für drei Dimensionen festlegen zu müssen. Zudem müssen sie das anstatt den üblichen vier bis fünf Klassen nun für 10 Klassen machen.

Das heißt, dass die Herstellen für insgesamt 100 Klassen die Klassifizierungsmerkmale definieren müssen!

c) Illusion einer Genauigkeit

Meist tun sich die Hersteller bereits damit schwer, die Klassifizierungskriterien für eine Schweregrad-Achse mit vier Kategorien festzulegen und die Risiken danach zu bewerten.

Bei 10-teiligen Skalen dürfte die Schätzgenauigkeit niedriger sein, als die Kategorien dies vermuten lassen. Damit wird die Risikoprioritätszahl zu einer sehr groben Schätzgröße. Die 1000 möglichen Werte für die RPZ stellen eher eine „Genauigkeitsillusion“ dar.

d) Unklares Risiko-Nutzen-Verhältnis

Wie sind eine Entdeckungswahrscheinlichkeit von drei und eine Auftretenswahrscheinlichkeit von sieben einzuordnen? Wie viele Schadensereignisse bedeutet das konkret? Das müssen Sie wissen, sonst können Sie den Nutzen und das Risiko durch Ihr Produkt nicht vergleichen.

Der Ansatz vieler Hersteller, den Wert 125 (5 x 5 x 5) als Grenzwert zwischen inakzeptablen und akzeptablen Risiken zu definieren, erscheint willkürlich. Dieser Grenzwert muss aus dem Nutzen abgeleitet werden.

Und genau das sollten Sie in der Risikoakzeptanzmatrix tun, auch, um die Forderung der Medizinprodukterichtlinie und der ISO 14971 nach einer Risiko-Nutzen-Bewertung gerecht zu werden.

Vorsicht!

Beachten Sie: Hersteller müssen die Akzeptanz von Risiken anhand des konkreten Nutzens begründen und dürfen dies nicht anhand eines willkürlichen Werts tun.

Zudem ergibt die Multiplikation von Werten nur auf Vergleichsskalen einen Sinn. Werte einer Schweregradachse in einer Multiplikation zu verwenden, ist genauso unsinnig wie bei einer Schulnotenskala: Ein Schüler mit der Note 2 ist nicht doppelt so gut wie ein Schüler mit der Note 4. Ein Schaden der Kategorie 4 ist nicht doppelt so hoch wie ein Schaden der Kategorie 2.

Dieser Probleme sind sich die meisten Hersteller, die mit einer RPZ arbeiten, nicht bewusst.

Weiterführende Informationen

Lesen Sie hier mehr zum Thema Herleiten von Risikoakzeptanzkriterien und Risikopolitik.

e) Irrtum, dass die RPZ (noch) etwas mit der FMEA zu tun habe

Spätestens in den neueren Veröffentlichungen zur FMEA ist das Konzept der RPZ verschwunden. In einer Übersicht über die Änderungen des AIAG & VDA-FMEA-Handbuchs wird darauf hingewiesen:

Das Risiko wird in der neuen Form als Aufgabenpriorität (Hoch – Mittel – Niedrig) dargestellt, welche sich zum Beispiel aus der Bedeutung und der Auftretenswahrscheinlichkeit ergibt. Die bisherige Risikoprioritätszahl entfällt.

3. Fazit: Vergessen Sie die RPZ

Was bedeutet das für Sie?

  1. Wenn Sie in der Medizintechnik arbeiten, vergessen Sie die Risikoprioritätszahl (zumindest in obiger Definition) und ersparen Sie sich unnötigen Ärger während des Audits. Nutzen Sie die Definition der ISO 14971.
  2. Nutzen Sie die Risikoprioritätszahl im Rahmen von Design- und Prozess-FMEAs, um Aufgaben zu priorisieren; nicht aber, um Risiken für Patienten zu quantifizieren.
Prof. Dr. Christian Johner
Benötigen Sie Unterstützung dabei, die Risiken durch Ihre Medizinprodukte zu identifizieren und quantifizieren? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

The post Risikoprioritätszahl (RPZ): Definition und Berechnung appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/iso-14971-risikomanagement/risikoprioritaetszahl-rpz/feed/ 11 5990
Computer-based Modeling & Simulation (CM&S): Ein Tool nicht nur für die schnellere Zulassung https://www.johner-institut.de/blog/systems-engineering/simulation/ https://www.johner-institut.de/blog/systems-engineering/simulation/#respond Tue, 27 Oct 2020 07:00:00 +0000 https://www.johner-institut.de/blog/?p=3799467 Die computerbasierte Modellierung und Simulation (CM&S) werden bei der Entwicklung und Zulassung von Medizinprodukten und für den Markterfolg vieler Hersteller zunehmend entscheidend. Dieser Artikel verschafft eine Übersicht über die Möglichkeiten der Modellierung und Simulation,nennt Hürden und regulatorische Voraussetzungen,verlinkt die wichtigsten Quellen undgibt konkrete Tipps zum Einsatz speziell für Medizinproduktehersteller. 1. Was man unter Computer-based Modeling [...]

The post Computer-based Modeling & Simulation (CM&S): Ein Tool nicht nur für die schnellere Zulassung appeared first on Wissen zu medizinischer Software.

]]>
Die computerbasierte Modellierung und Simulation (CM&S) werden bei der Entwicklung und Zulassung von Medizinprodukten und für den Markterfolg vieler Hersteller zunehmend entscheidend.

Dieser Artikel

  • verschafft eine Übersicht über die Möglichkeiten der Modellierung und Simulation,
  • nennt Hürden und regulatorische Voraussetzungen,
  • verlinkt die wichtigsten Quellen und
  • gibt konkrete Tipps zum Einsatz speziell für Medizinproduktehersteller.

1. Was man unter Computer-based Modeling & Simulation versteht

a) Begriffsdefinitionen

Eine hilfreiche Definition der Begriffe „Computer-based Modeling“ bzw. „Computational Modeling“ stammt von der FDA selbst:

Computational modeling is the process of representing a real-world system by means of a computer and then running the simulation by implementing a numerical scheme.

Frontiers in Medicine, September 2018, Volume 5, Article 241 by Tina Morrision (FDA) et al.

Eine der Anwendungsmöglichkeiten dieser Modellierung und Simulation ist die „in silico medicine“. Diese lässt sich wie folgt definieren:

It is the direct use of computer simulation in the diagnosis, treatment, or prevention of a disease. More specifically, in silico medicine is characterized by modeling, simulation, and visualization of biological and medical processes in computers with the goal of simulating real biological processes in a virtual environment.

Quelle

b) Modellierung und Simulation in anderen Branchen

Der Einsatz von Computermodellen und Simulationen ist in anderen Branchen weit verbreitet:

  • Automobilhersteller simulieren Crashtests. Sie nutzen Crashtests mit echten Autos vornehmlich zur Validierung und Weiterentwicklung von Computermodellen.
  • Die Entwicklung von Flugzeugen und die Überprüfung von deren Flugeigenschaften findet ausschließlich im Computer statt.
  • Die Vorhersage des Wetters basiert auf Computermodellen.
  • Die mechanischen Eigenschaften neuer Produkte berechnen Hersteller u.a. mit Hilfe der Finite-Elemente-Methode.
Drei Grafiken, die den Einsatz des Computer-based Modelings und der Simulation bei Crashtests, bei der Simulation des Wetters und bei Flugzeugen zeigen.
Abb. 1: Einsatz von computerbasierten Modellen und Simulation in anderen Branchen: Crahstests, Wetter, Strömungsmechanik

2. Einsatzgebiete in der Medizintechnik

Einsatzmöglichkeiten für computerbasierte Modellierung und Simulation bieten sich den Medizinprodukteherstellern in allen Phasen des Produktlebenszyklus.

a) Entwicklung von Medizinprodukten

Hersteller müssen die „gewählte Lösung“ begründen

Gesetze wie die MDR und IVDR verpflichten die Hersteller, die grundlegenden Sicherheits- und Leistungsanforderungen zu erfüllen. Dazu zählen Forderungen nach

  • der mechanischen, elektrischen, elektromagnetischen und biologischen Sicherheit der Produkte,
  • Zuverlässigkeit und Erstfehlersicherheit sowie
  • Erfüllung der Leistungsmerkmale

Die Hersteller müssen begründen, weshalb sie eine bestimmte Lösung gewählt haben, z.B. eine bestimmte Konstruktion:

„The documentation shall […] include a justification […] of the solutions adopted to meet those [general safety and performance] requirements.

MDR Anhang II, Kapitel 4.

Solch eine Begründung wird besonders dann gelingen, wenn Hersteller aufzeigen können, dass andere Lösungen der gewählten Lösung unterlegen sind.

Modellierung und Simulation bieten sich dafür an

Ein sehr effizienter Weg dazu besteht darin, alternative Lösungen im Computer zu simulieren und die beste Option zu wählen. Diese Optionen betreffen:

  • Auswahl von Materialien
  • Gestaltung von Bauteilen, z.B. Form, Materialdicken
  • Design und Positionierung von Antennen
  • Gestaltung von User Interfaces
Vier Bilder zum Einsatz der Modellierung am Beispiel einer implantierbaren Infusionspumpe: Von links nach rechts: Simulation des Antennendesigns, der Belastung des Gehäuses bei Stürzen, des User-Interfaces, der Druckverläufe und der Flussmenge
Abb. 2: Einsatz der Modellierung am Beispiel einer implantierbaren Infusionspumpe. V.l.n.r.: Simulation des Antennendesigns, der Belastung des Gehäuses bei Stürzen, des User-Interfaces, der Druckverläufe und der Flussmenge. Quelle: Ansys

Doch nicht nur das Produkt selbst ist Gegenstand der Modellierung, sondern auch die Anatomie und die Physiologie der Patienten.

Drei Abbildungen zeigen eine Simulation von Menschen mit deren Knochenstrukturen, deren ausgeatmeter Luft und deren Organen (hier Herz) Quellen: Cadfem Medical, Ansys, YouTube
Abb. 3: Simulation von Knochenstrukturen, ausgeatmeter Luft und Organen (hier Herz) Quellen: Cadfem Medical, Ansys, YouTube

b) Produktion

Einige Hersteller nutzen computerbasierte Modellierung, um Produktionsprozesse zu simulieren, z.B.:

  • Abfüllung von Produkten
  • Sterilisierung und Desinfektion
  • Gestaltung von Messständen

c) Verifizierung, Validierung und Zulassung

Auch der Nachweis, dass die Medizinprodukte sicher und leistungsfähig sind und den versprochenen klinischen Nutzen bieten, lässt sich mit Hilfe von Computermodellen ganz oder teilweise führen.

Die FDA hat in einigen Fällen die Zulassung von Medizinprodukten sogar ausschließlich auf Basis solcher Modelle und Simulationen ausgesprochen. Dazu zählt ein Produkt, dessen „Kernspin-Kompatibilität“ nachzuweisen war.

Weiter hat die FDA ein Gerät für die 3D-Mammographie zugelassen, dessen diagnostische Leistungsfähigkeit anhand synthetischer(!) Bilder bewertet wurde. Dazu simulierte der Hersteller sowohl die Brust (z.B. Größe, Fettanteil, Geometrie, Milchgänge, Gefäße, Läsionen) als auch das Medizinprodukt selbst.

Synthetische Bilder, die beim Leistungsnachweis und damit der Zulassung eines Geräts für die „Digital Breast Tomosynthesis (DBT)“ verwendet wurde
Abb. 4: Synthetische Bilder, die beim Leistungsnachweis und damit der Zulassung eines Geräts für die „Digital Breast Tomosynthesis (DBT)“ verwendet wurde. Quelle (zum Vergrößern klicken)

Damit wurde ein großer Teil der klinischen Prüfung durch die Simulation erbracht, also durch in-silico clinical trials.

d) Post-Market-Phase

Auch in der Post-Market-Phase, also nach der Inverkehrbringung, hilft die Simulation den Herstellern:

  • Fehlerbilder im Feld lassen sich anhand von Computermodellen nachstellen und Ursachen identifizieren.
  • Hersteller können schnell verschiedene Maßnahmen zur Fehlerbeseitigung ausprobieren und die beste Option wählen.
  • Auch die Verifizierung und Validierung dieser Maßnahmen und damit der Wirksamkeitsnachweis für Behörden gelingt mit Modellen.
  • Modelle helfen bei der Prognose künftiger Fehler. Hersteller sind damit in der Lage, auch Extremsituationen zu simulieren.

e) Zusammenfassung

Es gibt kaum eine Phase im Produktlebenszyklus, in der Modellierung und Simulation nicht zum Einsatz kommen können. Das sieht auch die FDA so.

Abb. : Die FDA sieht eine Vielzahl von Einsatzgebieten für das Computer-based Modeling und die Simulation.
Abb. 5: Die FDA sieht eine Vielzahl von Einsatzgebieten für Computer-based Modeling and Simulation (CM&S). Quelle (zum Vergrößern klicken)

3. Vorteile (nicht nur) für Medizinproduktehersteller

a) Beispiele

Die Vorteile von computerbasierter Modellierung und Simulation liegen auf der Hand:

  • Die Entwicklung kann schneller erfolgen, weil keine physischen Prototypen mehr entwickelt werden müssen.
  • Die Produkte sind sicherer, weil verschiedene Optionen ausprobiert und die beste Option gewählt werden kann.
  • Die Produkte können auch unter Extrembedingungen getestet werden, was ebenfalls deren Sicherheit erhöht.
  • Tierexperimente lassen sich minimieren oder sogar vermeiden.
  • Teure Teststände werden teilweise durch Computermodelle ersetzt.
  • Die Kosten und die Dauer für klinische Studien lassen sich minimieren.
  • An klinischen Studien brauchen nicht so viele Patienten teilnehmen.
  • Sicherheit und Leistungsfähigkeit lassen sich auch für Patienten nachweisen, die in ausreichender Anzahl nur schwer zu rekrutieren sind. Hier ist eine Erweiterung der Patientenkohorte um synthetische Patienten möglich.

b) Zusammenfassung

Die computerbasierte Modellierung verspricht somit viele Vorteile:

  • Kürzere „Time to market“
  • Niedrigere Kosten
  • Sichere Produkte
  • Weniger ethische Konflikte durch Tierversuche und klinische Prüfungen

Doch diese Methoden haben auch ihren Preis. Dazu weiter unten mehr.

4. Regulatorische Anforderungen im Kontext von CM&S

a) Europa

Selbst die aktuellen Gesetze wie die MDR enthalten keine spezifischen Anforderungen an den Einsatz von Computermodellen bei der Entwicklung von Medizinprodukten. Sie sehen allerdings deren Einsatz und die Simulation explizit vor.

[…] gegebenenfalls die Ergebnisse von Untersuchungen an biophysikalischen oder anderen Modellen, deren Gültigkeit bereits erwiesen wurde; (Anhang I, 10.1.a))
[…] Ergebnisse von Tests wie technischen, Labor-, Anwendungssimulations- und Tiertests bzw. Versuchen […]; (Anhang II, 6.1.a))
[…] die vorklinische Erprobung, zum Beispiel Laboruntersuchungen, Erprobung der simulierten Verwendung, Computermodelle, […] Tiermodelle (Anhang VII, 4.5.4.a))

Die ISO 13485 verpflichtet die Hersteller zur:

  • Computerized Systems Validation
  • Prozessvalidierung
  • Validierung von Messmitteln
  • Planung von Überwachungs- und Messprozessen
  • Verwendung angemessener statistischer Methoden

b) USA/FDA

Die FDA wurde vom US-Kongress verpflichtet, den Einsatz von CM&S zu fördern und zu regulieren. Die Behörde hat bereits im August 2011 das Dokument „Advancing Reglatory Science at FDA“ veröffentlicht. Darin hat sie „Use and develop computational methods and in silico modeling” als einen Schwerpunkt ihrer Arbeit erkoren.

Tina Morrision, die bei der FDA das Thema vorantreibt, hat 2018 in einer Publikation in „Frontiers in Medicine“ die Möglichkeiten des „Computational Modeling for Medical Devices“ und die notwendige „Regulatory Science“ erläutert.

Schon zuvor hatte sie das Guidance Document „Reporting of Computational Modeling Studies in Medical Devices Submission” maßgeblich entwickelt, das seit 2016 in einer finalen Version vorliegt.

Dieses Dokument beschreibt (wie der Name vermuten lässt), welche Dokumentation die FDA erwartet. Sehr spezifische Vorgaben zur Validierung der Modelle fehlen.

c) ASME V&V 40

Dafür verweist die FDA auf den „V&V 40“ der American Society for Mechanical Engineering (ASME) mit dem Titel „Verification and Validation of Computational Modeling of Medical Devices“.

Dieses Dokument beschreibt die Schritte, die Hersteller durchlaufen sollten, wenn sie Computermodelle validieren.

Prozessdiagramm: Die ASME nennt den Hersteller die Schritte, die sie durchlaufen sollten, wenn sie die „Glaubwürdigkeit“ ihres Modells nachweisen wollen.
Abb. 6: Die ASME nennt den Hersteller die Schritte, die sie durchlaufen sollten, wenn sie die „Glaubwürdigkeit“ ihres Modells nachweisen wollen. Quelle

Zu diesen Schritten zählen:

  1. Question of Interest formulieren
    Genau festlegen, welche Frage mit dem Modell beantwortet werden soll. Beispiel: „Wie viel Flüssigkeit soll ich Dialysepatienten entziehen?“
  2. Context of Use (COU) beschreiben
    Der COU beschreibt, welche Rolle das Modell bei der Beantwortung der Frage spielt und was der spezifische Gegenstand des Computermodells ist. Beispiel: „Es sollen die Flüssigkeitskompartimente der Patienten simuliert werden, um die Hydrierung des Patienten abzuschätzen.“
  3. Risiken analysieren
    Die Risiken sind bestimmt durch den Einfluss des Modells auf die Entscheidung des Herstellers und die Konsequenzen dieser Entscheidung. Beipsielsweise wäre der Einfluss des Modells größer, wenn sich der Hersteller ausschließlich auf das Modell verlässt.
  4. Credibility Goals festlegen
    Hier beschreibt das Dokument der ASME zahlreiche Aspekte (s. Abb. 7), bezüglich derer die Hersteller Kriterien bestimmen müssen. Das reicht von der Analyse der Diskretisierungsfehler über die Angemessenheit des Modells und seiner Formeln und Konstanten bis hin zur Überprüfung des Komparators, mit dessen Hilfe das Modell validiert werden soll.
Baumstruktur, die die Taxomomie zeigt: Die ASME nennt die Aspekte, die Hersteller adressieren sollten, wenn sie die „Glaubwürdigkeit“ ihrer Computermodelle nachweisen.
Abb. 7: Die ASME nennt die Aspekte, die Hersteller adressieren sollten, wenn sie die „Glaubwürdigkeit“ ihrer Computermodelle nachweisen. (zum Vergrößern klicken)

5. Der Einsatz von CM&S in der Praxis

a) Herausforderungen

Die Vorteile von Computermodellen bei der Entwicklung und Zulassung von Medizinprodukten sind offensichtlich. In der Praxis kämpfen die Hersteller jedoch mit zahlreichen Herausforderungen:

  • Mangel an Fachkräften
    Die Experten und Expertinnen sind rar gesät, die fähig sind, Computermodelle zu entwickeln und Medizinprodukte damit zu simulieren.
  • Regulatorische Unsicherheit
    Weil die europäischen Behörden und Benannten Stellen die Regulatory Science nicht im gleichen Maß vorantreiben wie die US-Amerikaner, bleibt eine regulatorische Unsicherheit. Werden Simulationen und Validierung der Modelle anerkannt? Wie viele andere Nachweise werden erwartet?
  • Hohe Kosten der Werkzeuge
    Es gibt viele Open-Source-Tools. Aber die haben meist nur einen sehr eingeschränkten Anwendungsbereich. Weiterhin fehlt der Support, die Validierung dieser Tools fehlt, und die Gebrauchstauglichkeit lässt Wünsche offen. Professionelle Werkzeuge hingegen können extrem teuer sein.
  • Hoher Aufwand für Entwicklung und Validierung der Modelle
    Entwicklung und Validierung von Computermodellen sind aufwändig. Beispielsweise dauerte dies bei der 3D-Mammographie 1,75 Jahre. Jedoch hätte es ohne den Einsatz dieser Methode vier Jahre gedauert.

b) Nächste Schritte gehen

Wie bei jedem Aufbruch ins Unbekannte empfehlen sich die folgenden Best-Practices:

  • Mit klarer und sehr begrenzter Fragestellung beginnen
  • Personen einsetzen, die erste Erfahrungen und v.a. Freude an dem Projekt haben
  • Hilfe holen, z.B. in Form von Beratung und Training
  • Schnell aus Fehlern lernen und Fragestellungen, Methoden und Werkzeuge anpassen
  • Nichts neu erfinden, auf Vorhandenes zurückgreifen: Dienstleister wie Cadfem Medical bieten „Simulation as a Service“ an und damit (vor-)validierte Modelle von Produkten und Menschen (Organen, Anatomie).
  • Die Aufgeschlossenheit und das Angebot der FDA nutzen und der Empfehlung von Tina Morrision (FDA) folgen, die CM&S für Zulassungen zu nutzen.

6. Zusammenfassung

a) Fast alternativlos – auch wegen neuer Wettbewerber

Es kann für die meisten Hersteller auf Dauer keine Frage sein, ob sie das computerbasierte Modellierung und Simulation bei der Entwicklung, Validierung und Zulassung ihrer Produkte einsetzen, sondern nur, wann.

Ohne diese Methoden wird es nicht gelingen, mit dem Wettbewerb Schritt zu halten. Wettbewerber sind nicht nur die bisherigen Firmen. Neue Unternehmen sowie Universitäten mit ihren Startups, die über Werkzeuge und Expertise in Bereich Modellierung und Simulation verfügen, werden neu in den Markt drängen.

b) Eine Frage der Ethik

Doch nicht nur der Wettbewerbsdruck sollte Hersteller veranlassen, sich auf den Weg zu machen. Patienten und Tiere unnötigen Versuchen und Risiken auszusetzen, ist schlicht unethisch.

Auch die FDA sieht hier Chancen:

[…] the all–in silico approach for conducting imaging trials is not intended to replace but rather complement or minimize traditional clinical trials. Incrementally incorporating computational results in regulatory submissions can, for example, help decrease the human trial size and length.

c) Hersteller, Behörden und Benannte Stellen sind gefragt

Das Maß, in dem Europa bei der „Regulatory Science“ vielen US-amerikanischen Initiativen im Bereich „Computer-based Modeling and Simulation“ hinterherhinkt, ist bedenklich. Hier wäre mehr Engagement von Behörden und Benannten Stellen wünschenswert.

Hersteller können sich in der Avicenna Alliance engagieren, um aktiv an der Gestaltung u.a. des regulatorischen Umfelds mitzuwirken.

Das Johner Institut wird noch intensiv Hilfestellung dabei geben, regulatorische Klarheit zu erlangen und die Modellierung und Simulation möglichst schnell und einfach nutzbar zu machen.


Bei weiteren Fragen wenden Sie sich gerne an das Johner Institut (Kontaktformular) oder Cadfem Medical.


Interessenserklärung: Das Johner Institut und Cadfem Medical haben bei der Keynote bei der MedConf 2020 zusammengearbeitet. Die Keynote bildet auch die Basis dieses Artikels. Es besteht keine kommerzielle Zusammenarbeit zwischen den beiden Firmen.

The post Computer-based Modeling & Simulation (CM&S): Ein Tool nicht nur für die schnellere Zulassung appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/systems-engineering/simulation/feed/ 0 3799467
FMEA: Defininition und Bedeutung am Beispiel von Medizinprodukten https://www.johner-institut.de/blog/iso-14971-risikomanagement/fmea-bei-medizinprodukten/ https://www.johner-institut.de/blog/iso-14971-risikomanagement/fmea-bei-medizinprodukten/#comments Thu, 22 Oct 2020 05:00:00 +0000 https://www.johner-institut.de/blog/?p=11165 Die FMEA, die Failure Mode and Effect Analysis (auf Deutsch „Fehlermöglichkeits- und -einflussanalyse“) ist ein Verfahren, um zu bekannten Ursachen unbekannte Auswirkungen zu untersuchen. Bei Medizinprodukten nutzt man die FMEA beispielsweise bei der Risikoanalyse, um die Folgen einer fehlerhaften Komponente zu analysieren, insbesondere die sich daraus ergebende Gefährdungen. 1. Wie Sie die FMEA nutzen sollten [...]

The post FMEA: Defininition und Bedeutung am Beispiel von Medizinprodukten appeared first on Wissen zu medizinischer Software.

]]>
Die FMEA, die Failure Mode and Effect Analysis (auf Deutsch „Fehlermöglichkeits- und -einflussanalyse“) ist ein Verfahren, um zu bekannten Ursachen unbekannte Auswirkungen zu untersuchen.

Bei Medizinprodukten nutzt man die FMEA beispielsweise bei der Risikoanalyse, um die Folgen einer fehlerhaften Komponente zu analysieren, insbesondere die sich daraus ergebende Gefährdungen.

1. Wie Sie die FMEA nutzen sollten

a) Bei der Entwicklung

Nutzen Sie die FMEA, um bisher unbekannte Gefährdungen zu identifizieren, die sich aus hypothetischen Fehlern ergeben:

  1. Beginnen Sie bei dieser Analyse mit den Inputs und den Komponenten des Produkts.
  2. Notieren Sie mögliche Fehlerzustände bei diesen Inputs und Komponenten.
  3. Finden Sie heraus, welche Auswirkungen (z.B. Produktfehlverhalten bzw. Gefährdungen) diese Fehlerzustände haben können.
Die FMEA untersucht die Auswirkungen fehlerhafter Komponenten und Inputs
Abb. 1: Die FMEA untersucht die unbekannten Auswirkungen von sich fehlerhaft verhaltenden Komponenten und Inputs, z.B. Gefährdungen.

Man bezeichnet die FMEA wegen des Wegs von der Ursache zur Wirkung als ein Bottom-Up-Verfahren.

b) Beim Austausch oder bei Änderungen von Komponenten

Als Medizinproduktehersteller sollten Sie die FMEA immer als bevorzugtes Verfahren zur Risikoanalyse (präziser: Gefährdungsanalyse) anwenden, um die Auswirkungen zu analysieren, die der Austausch oder die Änderung einer Komponente nach sich ziehen kann.

Die FMEA sollten Sie auch dann nutzen, wenn Sie die Release Notes und Bug-Reports Ihrer SOUPs lesen und mögliche Folgen dieser Fehler bewerten müssen. Das verlangt übrigens die IEC 62304.

Es ist möglich, die FMEA auch auf einzelne Komponenten anzuwenden, die aus Subkomponenten bestehen.

Komponenten-FMEA ist keine Risikoanalyse!

Allerdings dient diese Form der FMEA nicht der Risiko- bzw. Gefährdungsanalyse, weil die „Komponenten-FMEA“ nicht Gefährdungen als Auswirkungen diskutiert, sondern das Fehlverhalten der Komponente an deren „Außenkante“. Dieses Fehlverhalten kann wie beim Medizinprodukt selbst durch einen Fehler innerhalb der Komponente oder einen fehlerhaften Input an dieser Komponente verursacht sein.

In anderen Worten: Die Komponenten-FMEA ist keine Risikoanalyse, weil sie nicht Folgen im Sinne von Gefährdungen bzw. Schäden untersucht, sondern im Sinne von einer fehlerhaften Komponente. Sie kann also nur die äußeren Fehlverhalten und deren Wahrscheinlichkeiten analysieren.

c) Bei der Produktion

Das gleiche gilt für die FMEA bei der Produktion: Auch diese ist kein Risikoanalyseverfahren, weil sie ebenfalls keine Schäden bzw. Wahrscheinlichkeiten als Folge von Produktionsfehlern untersucht, sondern Fehler im produzierten Produkt bzw. in einer Komponente des Produkts (als Folge eines Produktionsfehlers).

Bei der Prozess- bzw. Produktions-FMEA untersucht der Hersteller Prozess- bzw. Produktionsschritt für Prozess- bzw. Produktionsschritt. Für jeden dieser Schritte werden die Auswirkungen möglicher Fehler analysiert. Mögliche „nach außen sichtbare“ Fehler sind:

  • Falsche physikalische, chemische oder biologische Beschaffenheit der Komponente
  • Komponente gibt in nicht spezifizierter Weise Informationen bzw. Daten weiter (zu wenig, zu viel, zu früh, zu spät, falsche Reihenfolge usw.)
  • Komponente gibt in nicht spezifizierter Weise Energien oder Materialien ab (zu wenig, zu viel, zu früh, zu spät, falscher Ort usw.)

Die Kenntnis, mit welcher Wahrscheinlichkeit zu welchen Fehlern im Produkt eine fehlerhafte Produktion führt, hilft im Rahmen der Entwicklungs-FMEA, die Wahrscheinlichkeiten des Fehlers in einer Komponente genauer abzuschätzen.

2. Tipps zur Anwendung der FMEA

a) Wesentliche Voraussetzung erfüllen: Eine dokumentierte System- bzw. Software-Architektur

Die FMEA setzt also im Gegensatz zur PHA eine Systemarchitektur bzw. Softwarearchitektur voraus. Erst wenn Sie diese Architekturen dokumentiert haben, kennen Sie die einzelnen Komponenten. Nur mit einer Architektur können Sie nachvollziehen, wie sich ein Fehler in einer dieser Komponenten auf das Gesamtsystem (Medizinprodukt) auswirkt.

Die Architekturen sollten aber nicht nur erkennen lassen, mit welchen anderen Komponenten eine Komponente interagiert, sondern auch wie. Um eine FMEA anwenden zu können, müssen Sie also wissen, welche

  • Daten/Informationen,
  • Materialien oder Stoffe bzw.
  • Energien

eine Komponente zur nächsten weitergeben kann. Bei „Datenschnittstellen“ sollten Sie diese Information der Komponentenspezifikation entnehmen können.

b) Ergebnisse tabellarisch dokumentieren

Medizinproduktehersteller dokumentieren die Risiken meist tabellarisch und nennen diese Tabelle nicht ganz zutreffend die „FMEA-Tabelle“. Dieser Begriff ist irreführend, weil die Tabelle geeignet ist, die Ergebnisse aller Risikoanalyseverfahren (z.B. auch die der Fault-Tree-Analysis, FTA) zu dokumentieren. Regelmäßig hat diese Tabelle folgende Spalten:

  • ID
  • Komponente/Input
  • Fehler in Komponente/Input
  • Innere Ursachenkette
  • Äußeres Fehlverhalten
  • Gefährdung
  • Wahrscheinlichkeit des Schadens
  • Schweregrad des Schadens
  • Risiko vor Maßnahmen
  • usw.
Die Ergebnisse der FMEA dokumentiert man meist tabellarisch

Ebenfalls in dieser Tabelle dokumentieren Hersteller üblicherweise auch die Maßnahmen zur Risikobeherrschung.

c) FMEA mit HAZOP kombinieren

Um mögliche Fehlverhalten von Inputs oder Komponenten systematisch zu identifizieren, lässt sich die FMEA mit der HAZOP-Analyse kombinieren. Dieses Verfahren beschreibt die IEC 61882. Es arbeitet u.a. mit Leitfragen wie „zu früh?“ „falsche Reihenfolge?“ „zu schnell?“ usw.

3. Vor- und Nachteile der FMEA

a) Vorteile

Die FMEA hat den Vorteil, ein sehr systematisches Verfahren zu sein. Man kann bei gegebener System- bzw. Software-Architektur jede Komponente untersuchen und so „abhaken“.

Dieses Verfahren ist einfach zu verstehen und entspricht der Denkweise vieler Entwickler, die mit „ihrer“ Komponente beginnen können.

b) Nachteile

Die FMEA ist ungeeignet, um logische Verknüpfungen viele Fehler zu untersuchen und zu beschreiben. Dazu eignet sich die Fault-Tree-Analysis (FTA).

Auf Basis einer FMEA lässt sich auch nicht beurteilen, wie granular Komponenten analysiert werden müssen. Viele Medizinproduktehersteller ersticken in „Risikotabellen“ mit hunderten und tausenden von Zeilen.

Weil Entwickler diese Methode gut anwenden können, überträgt man ihnen oft die vollständige Risikoanalyse. Dafür sind aber Entwickler – in ihrer Rolle als Entwickler – weder qualifiziert noch geeignet.

Viele Hersteller wenden die FMEA unter Verwendung der Risikoprioritätszahl RPZ an. Diese Definition des Begriffs Risiko stimmt nicht mit der der ISO 14971 überein. Lesen Sie hier mehr über dieses Problem.

In den Videotrainings des Auditgarant lernen Sie, wie Sie eine Risikoanalyse (auch Failure Mode and Effect Analysis) systematisch erstellen und dokumentieren. Die Premium-Version enthält sogar fertige Templates.
In den Videotrainings des Auditgarant lernen Sie, eine Risikoanalyse (auch FMEA) systematisch zu erstellen und dokumentieren. Die Premium-Version enthält fertige Templates.

The post FMEA: Defininition und Bedeutung am Beispiel von Medizinprodukten appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/iso-14971-risikomanagement/fmea-bei-medizinprodukten/feed/ 2 11165
ISO 27001: IT-Sicherheitsmanagement für alle Medizinproduktehersteller? https://www.johner-institut.de/blog/iec-62304-medizinische-software/iso-27001/ https://www.johner-institut.de/blog/iec-62304-medizinische-software/iso-27001/#respond Tue, 20 Oct 2020 07:00:00 +0000 https://www.johner-institut.de/blog/?p=3788769 Die ISO 27001 und die Informationssicherheitsmanagementsysteme (ISMS) werden bei ISO-13485-Audits immer häufiger zum Thema. Die Regularien geben dazu Anlass. Dazu zählt u.a. die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV), die die ISO 27001 in den Fokus vieler Medizinproduktehersteller gerückt hat. Hersteller müssen die regulatorischen Anforderungen erfüllen, um Ärger mit Behörden und Benannten Stellen zu vermeiden und um Patienten nicht [...]

The post ISO 27001: IT-Sicherheitsmanagement für alle Medizinproduktehersteller? appeared first on Wissen zu medizinischer Software.

]]>
Die ISO 27001 und die Informationssicherheitsmanagementsysteme (ISMS) werden bei ISO-13485-Audits immer häufiger zum Thema. Die Regularien geben dazu Anlass. Dazu zählt u.a. die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV), die die ISO 27001 in den Fokus vieler Medizinproduktehersteller gerückt hat.

Hersteller müssen die regulatorischen Anforderungen erfüllen, um Ärger mit Behörden und Benannten Stellen zu vermeiden und um Patienten nicht zu gefährden. Sie sollten aber keine unnötigen Aufwände betreiben. Daher sollten sie verstehen,

  • ob sie das Thema ISMS und damit die ISO 27001 überhaupt betrifft,
  • welche Anforderungen die ISO 27001 an sie stellt und
  • wie sie ggf. ein solches ITSM einführen können (insbesondere, wenn es bereits ein QMS gibt).

1. Wen die ISO 27001 betrifft

a) Regulatorischer Rahmen

Organisationen können verschiedene Rollen einnehmen:

  • Inverkehrbringer von Medizinprodukten
  • Betreiber von Medizinprodukten
  • Dienstleister für Inverkehrbringer oder Betreiber

Die regulatorischen Anforderungen richten sich v.a. an die Inverkehrbringer und Betreiber:

Rolle

MDR, IVDR

DSGVO

DIGAV

Inverkehrbringer

Ja (u.a. Herstellung, „Zulassung“, Post-Market Surveillance)

Nur bedingt (wie jede andere Firma)

Ja, technische Anforderungen an die DiGA, die in den Spezifikationen berücksichtigt werden müssen

Betreiber

Nur bedingt (siehe eigener Artikel dazu)

Ja (u.a. Schutz von Gesundheitsdaten)

Ja, technische und organisatorische Maßnahmen, zum Schutz von Gesundheitsdaten

Dienstleister

Nur bedingt (z.B. über QSVs)

Nur bedingt (wie jede andere Firma; Ausnahme: Auftragsverarbeiter)

Ja, Cloud Server, Plattformen, Auftragsverarbeiter müssen ihre Konformität mit der ISO 27001 oder BSI Standard 200-2 nachweisen, um von DiGAs genutzt werden zu können.

Die Digitale-Gesundheitsanwendungen-Verordnung (DiGAV) betrachtet die Firmen sowohl als Betreiber als auch als Hersteller.

b) Anwendbarkeit der ISO 27001 für Betreiber

Die Betreiber müssen die Gesundheitsdaten durch geeignete technische und organisatorische Maßnahmen gewährleisten. Das fordert u.a. die Datenschutzgrundverordnung DSGVO. Dazu ist i.d.R. ein Informationssicherheitsmanagementsystem (ISMS) erforderlich.

Um dessen Wirksamkeit nachzuweisen, sollten die Firmen den Vorgaben einschlägiger Normen wie der ISO 27001 oder den BSI-Standards (u.a. BSI 200-2) folgen.

Einige Regularien wie die DiGAV schreiben sogar eine Zertifizierung nach einem dieser Standards vor.

c) Anwendbarkeit der ISO 27001 für Hersteller

Für die Entwicklung sicherer Medizinprodukte gelten andere Normen

Die Hersteller müssen die IT-Sicherheit ihrer Produkte gewährleisten. Das setzt einen „Secure Development Lifecycle“ voraus. Dieser beinhaltet Vorgaben zur Entwicklung, zum Testing und zur Überwachung von Produkten, die Software enthalten.

Hierzu gibt es Normen und Leitfäden, z.B. die Normenfamilien IEC 62443 und ISO 15408 sowie der Leitfaden der Benannten Stellen, der auf dem Leitfaden des Johner Instituts aufbaut.

Für den Schutz der eigenen IT und Software ist die ISO 27001 dienlich

Eine direkte Forderung nach einem ISMS gibt es nicht. Allerdings müssen die Hersteller sicherstellen, dass die Medizinproduktesoftware bereits zum Zeitpunkt der Auslieferung frei von Schad-Code ist. Voraussetzung dafür ist u.a., dass Hersteller ihre eigene Informationstechnik schützen. Dazu ist ein ISMS dienlich.

Daher ist die ISO 27001 für Organisationen, die „nur“ in der Rolle eines Herstellers agieren, ein dienlicher Leitfaden, aber keine zwingende Notwendigkeit.

d) Anwendbarkeit für Dienstleister

In ihrer Rolle als Dienstleister müssen Firmen meist nur die Vorgaben erfüllen, die für alle Firmen bzw. Organisationen gelten. Allerdings verpflichten sie regelmäßig deren Kunden (die Inverkehrbringer/Hersteller und Betreiber), weitere Anforderungen zu erfüllen.

Falls der Dienstleister ein Auftrags(daten)verarbeiter ist, gelten für ihn vergleichbare Anforderungen wie für den Betreiber. Das bedingt ein ISMS, das z.B. nach ISO 27001 zertifiziert ist.

e) Zusammenfassung

Abhängig von ihrer Rolle müssen Organisationen unterschiedliche regulatorische Anforderungen erfüllen.

Ontologie, das die Abhängigkeiten zwischen Regularien, Objekten, Maßnahmen und Normen beschreibt. Die ISO 27001 ist für insbesondere für Medizinproduktehersteller relevant, die auch als Betreiber agieren und den Datenschutz von Gesundheitsdaten gewährleisten müssen. Hersteller müssen jedoch auch die eigenen Informationen und Informationstechnik schützen, um zu vermeiden, dass sie unsichere Produkte auf den Markt bringen.
Abb. 1: Die ISO 27001 ist insbesondere für Medizinproduktehersteller relevant, die auch als Betreiber agieren und den Datenschutz von Gesundheitsdaten gewährleisten müssen. Hersteller müssen jedoch auch die eigenen Informationen sowie die eigene Informationstechnik schützen, um zu vermeiden, dass sie unsichere Produkte auf den Markt bringen.

2. Was die ISO 27001 fordert (für eilige Leser)

a) Es gibt Gemeinsamkeiten mit einem QM-System konform ISO 13485

Die ISO 27001 beschreibt die Anforderungen an ein Informationssicherheitsmanagementsystem (ISMS), so wie die ISO 13485 die Anforderungen an ein Qualitätsmanagementsystem beschreibt. Daher finden sich in der ISO 27001 ähnliche Elemente wie in der ISO 13485, z.B.:

  • Verantwortung der Führung (Kapitel 5) u.a. mit der Pflicht, eine „Politik“ festzulegen
  • Forderung, die notwendigen Ressourcen (insbesondere kompetentes Personal) bereitzustellen (Kapitel 7.1 f.) und Informationen und Dokumentation zu lenken (Kapitel 7.3 ff.)
  • Forderung nach einer Managementbewertung und nach internen Audits (Kapitel 9)
  • Verpflichtung zur kontinuierlichen Verbesserung (Kapitel 10) inklusive Korrektur- und Vorbeugemaßnahmen (CAPA)
  • Risikomanagementprozess (u.a. Kapitel 6). Allerdings sind hier die Risiken anders definiert.
Mindmap mit Inhaltsverzeichnis der ISO 27001: Abb. 2: Die ISO 27001 umfasst zehn Kapitel sowie einen normativen Anhang. Einige Kapitel weisen Ähnlichkeiten mit der ISO 13485 auch, andere sind spezifisch für die IT-Sicherheit.
Abb. 2: Die ISO 27001 umfasst zehn Kapitel sowie einen normativen Anhang. Einige Kapitel weisen Ähnlichkeiten mit der ISO 13485 auf, andere sind spezifisch für die IT-Sicherheit (zum Vergrößern klicken).

b) Es gibt Anforderungen spezifisch für die IT-Sicherheit

Anforderungen im Anhang A

Die ISO 27001 beschreibt im normativen Anhang A viele konkrete Anforderungen, Ziele und Maßnahmen.

Mindmap, der die Struktur des Anhangs A der ISO 27001 zeigt
Abb. 3: Der Anhang A der ISO 27001 nennt konkrete Anforderungen, Ziele und Maßnahmen (zum Vergrößern klicken).

Beispielsweise fordert die Norm im Anhang A 9.2 eine Benutzerverwaltung. Diese muss das Ziel erfüllen, dass sichergestellt ist, dass „befugte Benutzer Zugang zu Systemen und Diensten haben und unbefugter Zugang unterbunden wird“.

Dazu definiert sie fünf Maßnahmen. Die erste lautet:

„Ein formaler Prozess für die Registrierung und Deregistrierung von Benutzern ist umgesetzt, um die Zuordnung von Zugangsrechten zu ermöglichen.“

Für Hersteller mit eigener Software-Entwicklung ist besonders der Anhang A.14 interessant, der u.a. Anforderungen an die „Sicherheit in Entwicklungs- und Unterstützungsprozessen“ fordert.

Der Anhang A fordert viele weitere, nachvollziehbare Maßnahmen:

  • Der Zugriff auf Informationen und Informationstechnik muss geregelt sein.
  • Daten müssen gesichert werden.
  • Die Sicherheit von Netzwerken muss durch geeignete Trennungen erhöht werden.
  • Elektronisch übertragene Daten müssen geschätzt werden.
  • Es muss geregelt sein, wie kryptographische Schlüssel verwaltet werden.

Hinweise, wie man diese Anforderungen konkret erfüllen kann, liefert nicht die ISO 27001, sondern die ISO 27002. Dazu mehr im Kapitel 4 dieses Artikels.

Anforderungen im „Hauptteil“

Ob und in welchem Detailgrad die Organisationen die Anforderungen des Anhangs A umsetzen, hängt von ihrem jeweiligen Schutzbedarf und ihrer „Politik“ ab.

Die ISO 27001 fordert daher, die Risiken systematisch zu identifizieren und anhand vorher festgelegter Risikoakzeptanzkriterien zu bewerten. Abhängig von dieser Bewertung sind die Hersteller verpflichtet, die Maßnahmen festzulegen und umzusetzen sowie deren Wirksamkeit regelmäßig zu überwachen (s. Abb. 4).

Zeichnung Zyklus zeigt: Die ISO 27001 fordert einen fortlaufenden Prozess zu Analyse, Bewertung und Beherrschung von Risiken für die IT-Sicherheit.
Abb. 4: Die ISO 27001 fordert einen fortlaufenden Prozess zur Analyse, Bewertung und Beherrschung von Risiken für die IT-Sicherheit.

Das Risikomanagement bezieht weniger auf die Safety wie die ISO 14971, sondern auf die Werte / Assets und deren Verlust, zu diesen zählen neben den Informationen und die Informationstechnik auch Prozesse im Unternehmen.

c) Vergleich mit dem BSI 200-1

Alternativ zur Zertifizierung nach ISO 27001 durch eine Zertifizierstelle können Hersteller eine Zertifizierung beim BSI nach BSI 200-1 IT Grundschutz anstreben. Die folgende Tabelle vergleicht beide Standards.

ISO/IEC 27001IT-Grundschutz nach BSI Standard 200-2
Forderungen eher allgemein und daher flexibel für das Unternehmen interpretierbarUmfangreiche Forderungen, die sehr detailliert beschrieben sind und den Unternehmen wenig Spielraum lassen
32 Seiten verpflichtend, ca. 250 Seiten optional180 Seiten IT Grundschutz-Methodik über 4000 Seiten inkl. Grundschutzkataloge
Anzahl der erforderlichen Maßnahmen kann flexibel festgelegt werdenMehr als 1000 Maßnahmen werden erwartet.
Allgemeine VorgabenKonkrete Vorgaben und Maßnahmen
Forderungen eher allgemein und daher flexibel für das Unternehmen interpretierbarUmfangreiche Forderungen, die sehr detailliert beschrieben sind und den Unternehmen wenig Spielraum lassen
Vollständige Risikoanalyse erforderlichDer Umfang der Risikoanalyse ist abhängig von den Ergebnissen der Schutzbedarfsanalyse
Vergleichsweise hoher Aufwand für Einführung und ZertifizierungVergleichsweise hoher Aufwand für Einführung und Zertifizierung
Internationale AnerkennungEnthält nationale Besonderheiten und ist international wenig bekannt
Eher für die WirtschaftsunternehmenEher für Behörden
Eher für kleine und mittlere UnternehmenEher für größere Organisationen geeignet
ISO 27001 und BSI 200-2 / IT Grundschutz – was eignet sich für wen? (Quelle)

3. Wie man ein ISO 27001-konformes ISMS einführt

Kein zweites Managementsystem einführen

MDR und IVDR verpflichten alle Medizinproduktehersteller zu einem Qualitätsmanagementsystem (QMS), meist sogar zu einem (nach ISO 13485) zertifizierten. Daher sollten die Hersteller kein zweites Managementsystem etablieren, sondern ein integriertes Managementsystem, das beide Ziele (Qualität, IT-Sicherheit) adressiert.

Schritt 1: Ziele und Anwendungsbereich festlegen

Organisationen sollten Klarheit darüber haben, welche Ziele sie erreichen wollen:

  • Regulatorische Anforderungen erfüllen, regulatorischen Ärger vermeiden
  • Anforderungen von Kunden erfüllen
  • Zertifizierung erreichen
  • (informationellen) Unternehmenswerte identifizieren
  • Schutz dieser Werte d.h. die Sicherheit für die Informationen und Informationstechnik der eigenen Organisation erhöhen
  • Sicherheit der eigenen Produkte erhöhen
  • Marketing-wirksamer kommunizieren können (z.B. mit Zertifikat)
  • Verständnis über den Stand der eigenen Organisation bezüglich IT-Sicherheit erlangen
  • Chaos in der eigenen Organisation reduzieren

Bei diesen Überlegungen sollten die Firmen auch Klarheit darüber erlangen,

  • welche Informationen und welche Informationstechnik sie schützen müssen und
  • welche finanziellen, juristischen und anderen Folgen und damit Risiken bestehen, wenn dieser Schutz nicht in ausreichendem Maß gegeben ist.

Als weiteres Ergebnis dieser ersten Analyse sollte eine Organisation den Anwendungsbereich eines künftigen ITSMs festlegen. Dies betrifft beispielsweise:

  • Standorte
  • Organisationseinheiten
  • Informationen, Daten
  • Infrastrukturen, Informationstechnik
  • Eigene Produkte

Schritt 2: Gap-Analyse durchführen

Mit diesem Verständnis kann es nun gelingen, eine Gap-Analyse durchzuführen, d.h. eine Abschätzung zu erhalten, welche Vorgaben der ISO 27001 bereits ganz, teilweise oder noch gar nicht umgesetzt sind.

Meist nutzen die Firmen oder unterstützenden Dienstleister dazu den Anhang A oder eigene Checklisten.

Schritt 3: Maßnahmen festlegen und umsetzen

Basierend auf diesen Ergebnissen geht es nun daran, geeignete Maßnahmen festzulegen. Typische Maßnahmen sind:

  • Bestehende Verfahrens- und Arbeitsanweisungen ergänzen, z.B.
    • zum internen Audit,
    • zum Onboarding neuer Mitarbeitenden oder
    • zur Software-Entwicklung
  • Fehlende Verfahrens- und Arbeitsanweisungen verfassen, z.B.:
    • Kommunikation von Sicherheitsvorfällen
    • Zugangskontrolle zu Systemen und Räumen
    • Entsorgung von Datenträgern
    • Verwendung von Passwörtern
  • Organisationsstruktur anpassen, z.B.:
    • Neue Rollen schaffen oder bestehende Rollen anpassen
    • Verantwortlichkeiten neu oder anders regeln, z.B. für die Überwachung von Systemen
    • Personen einstellen und Personal fortbilden
  • Technische Strukturen verbessern, z.B.:
    • Neue Hardware oder Software kaufen
    • Bestehende Systeme neu konfigurieren
    • Netzwerke trennen
    • Überwachungssysteme implementieren

Dieser Schritt erfordert ein interdisziplinäres Team, das explizit nicht nur IT umfasst. Die Umsetzung dieses Schrittes nimmt je nach Größe der identifizierten Gaps zwischen 3-12 Monaten in Anspruch.

Schritt 4: Internes Audit und Managementbewertung durchführen

Regelmäßig sollten sich die Firmen durch interne Audits vom Fortschritt und der Wirksamkeit der Maßnahmen überzeugen. Die von der Norm geforderten internen Audits sind dazu ein wirksames Instrument.

Zudem ist das Management verpflichtet, sich regelmäßig (mindestens jährlich) von der Wirksamkeit des gesamten Informationssicherheitsmanagementsystems zu überzeugen.

Beides, die internen Audits und die Managementbewertung, sind zwingende Voraussetzungen für den nächsten Schritt, die Zertifizierung.

Schritt 5: Zertifizierung beantragen und durchführen

Organisationen sollten darauf achten, dass sie nur akkreditierte Zertifizierungsorganisationen um Angebote bitten. Meist sind diese etwas günstiger und die Verfügbarkeit der Zertifizierer etwas besser als bei den Benannten Stellen. Allerdings sind einige Benannte Stellen auch für die ISO 27001 akkreditiert. Ein kombiniertes Audit kann zu Einspareffekten führen.

Der Ablauf der Zertifizierungsaudits gleicht etwa den QM-Audits, auch was die Dauer betrifft.

Zusammenfassung

Der Weg zum zertifizierten ISMS ist mit dem Weg zum zertifizierten QMS vergleichbar. Bei Medizinprodukteherstellern gibt es jedoch meist bereits ein QMS. Damit existiert ein höheres Verständnis für solche Managementsysteme.

Viele Prozesse wie für die Dokumentenlenkung, die Managementbewertung, die Korrektur- und Vorbeugemaßnahmen bestehen bereits.

Daher sind die Gap-Analyse und der Anhang A wichtige Hilfsmittel, um die Einführung des eigenen ISMS zu planen.

4. Was man sonst über die ISO-27000-Familie wissen sollte

a) Die ISO 27002 hilft bei der Umsetzung der ISO 27001

Die ISO 27002 dient als Leitfaden bei der Umsetzung der ISO 27001. Im Gegensatz zur ISO 27001 können sich Organisationen nicht nach ISO 27002 zertifizieren lassen.

Die ISO 27002 gibt konkretere Hinweise. Beispielsweise fordert die ISO 27001 im Anhang A 12.3.1:

Sicherheitskopien von Information, Software und Systemabbildern werden entsprechend einer vereinbarten Sicherungsrichtlinie angefertigt und regelmäßig getestet.

Die ISO 27002 gibt Hinweise dazu. So sollten Backups

  • an einem Ort mit ausreichender Entfernung ausgelagert,
  • von physischen Einflüssen geschützt und
  • verschlüsselt werden sowie
  • das gesamte System und nicht nur dessen Daten enthalten.

b) Die ISO 27799 ist spezifisch für das Gesundheitswesen

Die ISO 27799 gilt spezifisch für das Gesundheitssystem. Diese Norm

  • ergänzt einige Anforderungen, z.B., dass die Verschlüsselung beim Backup von Gesundheitsdaten erfolgen sollte,
  • verschärft bestehende Anforderungen, ersetzt z.B. „soll“ durch „muss“ und
  • gibt spezifische Erläuterungen und Anleitungen.

Eine Zertifizierung nach ISO 27799 ist ebenfalls nicht möglich.

6. Zusammenfassung und Fazit

a) IT-Sicherheit betrifft Hersteller und Betreiber

Organisationen, die Gesundheitsdaten verarbeiten, benötigen ein Informationssicherheitsmanagementsystem, um die regulatorisch geforderten technischen und organisatorischen Maßnahmen nachzuweisen. Zu diesen Herstellern zählen viele DIGA-Anbieter.

Medizinproduktehersteller müssen die IT-Sicherheit ihrer Produkte gewährleisten. Das bedingt wiederum, dass diese Produkte (insbesondere deren Software und damit die Entwicklungs- und Produktionsumgebung) ebenfalls sicher sind. Ein ISMS hilft dabei, genau diesen Schutz zu gewährleisten.

b) Die Normenfamilie ISO 27000 ist hilfreich

Die Normenfamilie ISO 27000 stellt nachvollziehbare und meist gut verständliche Anforderungen an ein Informationssicherheitsmanagementsystem (insbesondere ISO 27001) und gibt konkrete Hinweise zur Umsetzung (insbesondere die ISO 27001).

c) Hersteller müssen Voraussetzungen erfüllen

Ohne ein klares Management Commitment wird es eine Organisation auf Dauer nicht schaffen, ein ISMS aufzubauen und erfolgreich zu betreiben. Der Fisch stinkt auch hier vom Kopf.

Entscheidend für den Erfolg sind ebenso

  • die Investition in die Kompetenz der Mitarbeitenden,
  • deren Bewusstsein für die Bedeutung der IT-Sicherheit und
  • eine reibungslose Kommunikation innerhalb des Teams sowie mit externen Stellen.

d) ISMS darf nur als ein nie endender Weg verstanden werden

Die Anforderungen der Norm zu erfüllen, bedeutet viel Arbeit. Firmen sollten sich bewusst sein, dass sie sich auf einen Weg machen, der nie endet und kontinuierliche Aufwände mit sich bringt, aber die IT-Sicherheit erhöht.

Aber auch dieser Berg an Arbeit lässt sich in iterativen und inkrementellen Schritten bewältigen. Ein wichtiger Schritt ist die Gap-Analyse, die eine Übersicht über die Art und den Umfang dieser Arbeit verschafft.

Ein Informationssicherheitsmanagementsystem gemäß ISO 27001 oder anderer Leitfäden einzuführen, ist keine Rakentenwissenschaft. Diesen Weg sind Tausende Firmen bereits erfolgreich gegangen. Insbesondere Hersteller und Betreiber von Medizinprodukten und von IT-Systemen, die Gesundheitsdaten verarbeiten, sollten oder müssen sogar diesen Weg beschreiten.


Das Johner Institut unterstützt Medizinprodukteherstellern dabei, QM-Systeme und ISMS konform ISO 13485 und ISO 27001 einzuführen und damit die Voraussetzungen zu schaffen z.B. für eine Zertifizierung und eine Aufnahme der Produkte ins DIGA-Verzeichnis. Nehmen Sie gerne Kontakt auf.

The post ISO 27001: IT-Sicherheitsmanagement für alle Medizinproduktehersteller? appeared first on Wissen zu medizinischer Software.

]]>
https://www.johner-institut.de/blog/iec-62304-medizinische-software/iso-27001/feed/ 0 3788769