Blog

Softwareentwicklung für Medizinprodukte und IVD – Vom Kunstflug zum Formationsflug! 

Mein Vater pflegte zu sagen: „Es gibt alte Piloten und es gibt kühne Piloten, aber es gibt nicht viele alte, kühne Piloten“. Für diesen Blog können wir Piloten durch Programmierer für Medizinprodukte (MD) und In-vitro-Diagnostika (IVD) ersetzen. Programmieren macht Spaß! Es ist eine konzentrierte kreative Tätigkeit mit greifbaren Ergebnissen. Die Meldung „Hello World!“ auf einem Computerbildschirm oder eine blinkende LED auf einer Platine geben einem die sofortige Befriedigung, dass die Grundlagen funktionieren. Danach sind die Möglichkeiten unbegrenzt!

Kunstflug - Die Anfänge  

In meiner früheren Design-Karriere pendelte ich zwischen Elektronik-Design und Embedded-Software-Entwicklung (auch Firmware genannt). Mit der Zeit stellte ich fest, dass die Arbeit mit Firmware für mich angenehmer war - tief in den Eingeweiden des Instrumentes zu sein und alles zusammenzubringen kann einschüchternd sein, aber aus der Entwicklungsperspektive ist es das weniger. Der ganze Fokus lag auf der Programmierung mit ihren engen Zeitbeschränkungen und multidimensionalen Aspekten wie Interrupts und Taskwechsel. Wenn man während der Entwicklung einen Fehler macht, kann man ihn oft schnell beheben, neu kompilieren und voilà, der Zeitplan wird kaum beeinflusst. Hardware hingegen war weniger nachsichtig: Wenn man einen Fehler machte, bedeutete das entweder eine „Cut-n-Jump“-Aktion, eine nachträglich angebrachte integrierte Schaltung oder einen Neudruck der Platine - puh - so viel zum Projektzeitplan und -budget!

Software/Firmware war also früher sehr agil, weil es außer dem Code wenig zu ändern gab. Dann kam die Softwareentwicklung für Medizinprodukte. Diese erforderte viele der uns bekannten Design-Artefakte, die dem Softwareentwicklungsprozess etwas mehr Trägheit verliehen. Jetzt mussten wir planen, spezifizieren, verifizieren und, wenn Probleme auftauchten, zurückgehen und viele Änderungen an der Dokumentation vornehmen. Hinzu kamen Regressionstests und formale V&V-Wiederholungen. Wir mussten Konfigurationen, Fehleranomalien, Release-Prozesse und OTS/SOUP formal verwalten. Verglichen mit späteren Änderungen an der Hardware von Medizinprodukten und In-vitro-Diagnostika war das noch nicht so schlimm, aber bei weitem nicht so „agil“ wie früher.


Formationsflug - mehr als Software-Fokus 

Ich bin lange genug dabei, um zu erkennen, dass auch die Zeit der softwarezentrierten Prozesse hinter uns liegt. Die Softwareentwicklung für Medizinprodukte und In-vitro-Diagnostika ist heute wesentlich umfangreicher, mit entsprechend höherem Prozessaufwand. Sie ist so umfangreich geworden, dass der Programmieraufwand etwa den gleichen Anteil an der Entwicklung hat wie das Schaltungsdesign der Hardware an den Prozessen zur Produktrealisierung. Entscheidend ist, dass es inzwischen eine Vielzahl etablierter und anerkannter Standards gibt, die die Akzeptanzschwelle für Medizinprodukte und In-vitro-Diagnostika-Software sehr hoch legen. Man könnte diese Standards als die Weisheit der alten Piloten betrachten, die mit den mutigen Piloten geteilt wird (obwohl auch alte Hunde lernen müssen). Der Detaillierungsgrad dieser Standards ergibt sich oft aus realen Problemen und wird zur Pflicht. Halten Sie sich an diese Standards und Ihre Bemühungen können weitergehen, ignorieren Sie sie oder machen Sie nur Lippenbekenntnisse und Sie werden scheitern.

Das Problem mit Standards ist, dass sie ziemlich isoliert sind. Sie zielen darauf ab, ein bestimmtes Problem zu lösen, und obwohl sie versuchen, sich zu koordinieren und aufeinander abzustimmen, kann ihre praktische Anwendung sehr entmutigend sein.

Die Normen werden von verschiedenen Organisationen (ISO, IEC, AAMI usw.) herausgegeben, die aufeinander verweisen und versuchen, sie für den Anwender (d.h. den Hersteller) zu verknüpfen. Darüber hinaus erkennen verschiedene Regulierungsbehörden auf der ganzen Welt unterschiedliche Versionen an, was den globalen Markt noch herausfordernder macht (Qserve ist auf diesem Gebiet sehr erfahren). Da wir uns hier auf Software konzentrieren, wollen wir ein gängiges Software-Status-Diagramm verwenden, um zu zeigen, wie sich diese verschiedenen Standards auf die Entwicklungsaktivitäten des Herstellers auswirken.

Abbildung 1: Standard-Silos

Abbildung 2: Typisches Compliance-Verhaltensdiagramm

Wenn wir Software für Medizinprodukte entwickeln, sei es eingebettet in ein Medizinprodukt oder ein IVD (IVD-Software), sei es als Medizinprodukt (SaMD/AI) oder vielleicht als Zubehör zu einem Medizinprodukt, müssen wir uns damit auseinandersetzen, wie die Normen letztendlich unsere Softwareprozesse, Anforderungen, Architekturen, V&V usw. beeinflussen. Je nach Ressourcen kann dies für kleine Produkthersteller eine große Herausforderung darstellen. Selbst große Organisationen tendieren dazu, Abteilungen stark voneinander abzugrenzen, indem sie Fachexperten (SMEs) bestimmte Bereiche zuweisen. Diese konzentrieren sich auf ihr jeweiliges Fachwissen und auf das, was sie zufällig über das gesamte Fachgebiet und den Rest der geltenden Normen wissen. Dies kann zu einem Compliance-Ansatz führen, der an das Spiel „Hau den Lukas“ erinnert (Abb. 2). Wir neigen dazu, uns zu verschiedenen Zeitpunkten auf verschiedene Aspekte zu konzentrieren, indem wir in abgegrenzten Bereichen denken: Einmal schauen wir uns die Benutzerfreundlichkeit an, dann die Cybersicherheit, dann die Risiken, dann die Software und so weiter. Wir können von einem Bereich zum anderen springen, uns mit verschiedenen Aspekten der Standards befassen, verschiedene Lösungsansätze anwenden und manchmal sogar Lücken im Nachhinein füllen, um die Anforderungen hoffentlich zu erfüllen.

Formationsflug – Aufbau der Unterstützungsstruktur 

Im Laufe der Jahre habe ich die Systemperspektive immer mehr schätzen gelernt und befürworte sie nachdrücklich. Vom Verkehrswesen über die Gesetzgebung bis hin zu Medizinprodukten und der Entwicklung von In-vitro-Diagnostika halte ich eine systematische Sichtweise für entscheidend, bevor man sich für eine Lösung entscheidet. Zu Recht fordern die Grundnormen eine Planungsphase, was im Wesentlichen bedeutet: Treten Sie einen Schritt zurück und planen Sie! Das wird von Unerfahrenen leicht unterschätzt. Wie ein altes Sprichwort sagt: „Es gibt nie genug Zeit, es richtig zu machen, aber immer genug Zeit, es noch einmal zu machen!“e to do it over”!

Gut, ich habe ein Problem skizziert. Meine Absicht ist es, 1) ein Bewusstsein für diese Realität zu schaffen und 2) einen Einblick in eine mögliche Lösung zu geben (siehe unten). Eine Botschaft von unserem Sponsor: Qserve beschäftigt sich täglich mit diesem Problem und bedient viele verschiedene Kunden auf dem globalen Markt. Unser pragmatischer Ansatz reicht von einfacher Beratung über Verifizierung/Prüfung bis hin zur Initiierung oder Durchführung von Projekten. Wenn Sie ein leistungsfähiges Medizinprodukt oder IVD haben, möchten wir Ihnen helfen, es den Menschen zugänglich zu machen, die davon profitieren könnten. Das bedeutet Produktumsetzung!

Um diese Silosituation zu überwinden, muss der Hersteller/Entwickler einen Abgleichprozess durchführen. Da Designkontrollen eine zentrale Rolle spielen, sind sie am besten geeignet, als organisatorischer Rahmen zu dienen. Wir müssen den beabsichtigten Gebrauch, die Benutzer und die Märkte verstehen. Diese grundlegenden und zentralen Top-Level-Anforderungen beeinflussen unsere Planung und letztendlich den Grad der Genauigkeit, den wir bei der Anwendung der Normen anstreben.

Abbildung 3: KI ist auch Software!

Für diese Übung betrachte ich künstliche Intelligenz und Software als eine Einheit. Es gibt einige zusätzliche Aspekte, die berücksichtigt werden müssen (KI-Framework), aber denken Sie daran - KI ist Software und muss daher den Standards für Software-Entwicklung entsprechen.

Da der Platz in einem Blogbeitrag begrenzt ist und dieser dazu beitragen soll, eine systemische Perspektive zu fördern, werde ich nur einige Konzepte behandeln. Wir beginnen mit einer Tabelle (Excel ist gut geeignet) der relevanten großen Kategorien der Designkontrolle. Dann ziehen wir die Anforderungen aus den Normen in die verschiedenen Kategorien und platzieren sie dort als Platzhalter. Ziel ist es, die Anforderungen der Normen in einer prozessorientierten Struktur zu organisieren. Diese können wir dann in unsere eigenen Prozesse, Verfahren und Vorlagen einfügen. Auf diese Weise können wir während der Entwicklung mehrere Aspekte gleichzeitig berücksichtigen. Einige Normen, wie z.B. 62304, sind dafür gut geeignet, da es sich um Prozessnormen handelt. Andere, wie 60601-1 (Sie erinnern sich an Essential Performance?), sind weniger geeignet. Aber ihre Ergebnisse passen zu den Phasen der Entwurfskontrolle. Darüber hinaus erfordert jede Herstellerdomäne eine Anpassung und Abstimmung auf die spezifische Domäne. Wenn alles andere fehlschlägt, beginnen Sie mit der Planung. Wenn Ihre Pläne (Risikomanagement, Benutzerfreundlichkeit, Cybersicherheit, Softwareentwicklung usw.) von Standards geleitet werden und Sie diesen Plänen folgen, werden Sie ein standardkonformes Ergebnis erzielen!

Wenn Ihr Ziel der globale Markt ist, berücksichtigen Sie in den Spaltenüberschriften unter der Kategorie „Standard“ die geografisch anerkannten Standards. Zum Beispiel könnte Grün für allgemein anerkannte Standards stehen, während Besonderheiten, wie z.B. FDA-Richtlinien, blau markiert werden könnten. Wenn wir durch die Phasen gehen (hier ist nur die Planung dargestellt und ich habe keine weiteren Planungselemente aufgelistet), können wir jeden Aspekt der relevanten Norm in der entsprechenden Designphase umfassend abdecken.

Produkt-

realisierungsphase

13485

FDA-Richtlinien Designkontrollen

Allgemeine

Software

62304

FDA-Richtlinien Softwarevalidierung

Risiko

14971

80001-1

Software-Risiko

TIR 80002-1

AMI TIR34

Software

 Cybersicherheit

EN IEC 62443-2

(11073-40102)

 60601-4-5 

 TIR57

Benutzer-

freundlich-

keit

62366-1

FDA-

 HF/UE-

 Richtlinien

Verfahren

810001-5-1

TIR57

 

Netzwerk

80001-1

Produkt

EN

IEC

62443-2

60601-4-5

Planung

Projektplan

Software-Entwicklungsplanüü

Risikomanagementplan

Softwarerisiko-

Managementplan üü

 

Verfahren (Hersteller)

Cybersicherheitsplan

Planungsanforderungen üü

 

Benutzer-freundlich-

keits-plan üü

 

 

Design Input

üüEtc.

üüEtc.

üüEtc.

üüEtc.

üüNetzwerk 

 (Verantwortliche Organisation)

Anforderungen

 

üü

Produkt

Leistungsfähigkeit

Anforderungen

üüEtc.

Aus einer übergeordneten Software-Perspektive könnte man für die in den Normen aufgeführten Elemente etwas Ähnliches wie das unten abgebildete Diagramm erstellen. Die Pläne decken die Elemente ab, die für das Produktentwicklungsprojekt erforderlich sind, während die Designkontrollprozesse und -vorlagen für die Überprüfung verwendet werden.

Abbildung 4: Anpassung der Standards an den Designkontrollprozess

Diese Darstellung gilt für ein Produkt mit Software. Würde es sich um Software als Medizinprodukt (SaMD - KI) handeln, würde sich nicht viel ändern. Statt türkis, bei welchem die Software Teil der Betrachtung ist, wäre es grün, da die Software (SaMD) das System ist und daher eine vollständige Systemperspektive erfordert. Die Standards ermutigen zur Systemperspektive, wenn es um Software geht, aber das wird oft nicht erkannt. Übrigens, können Sie erkennen, wo die Codierungsaufgabe in dieser Entwicklung liegt? Offensichtlich hat jede der oben genannten Boxen viele weitere Details, aber wenn Ihre Pläne, Prozesse/Prozeduren und Vorlagen das gesamte Feld abdecken und diese Detailtiefe der beteiligten Standards berücksichtigen, dann wird Ihre Entwicklung das auch tun! Also, wenn ich Ihnen nur eine Sache mit auf den Weg geben kann: Schauen Sie in den Himmel und lassen Sie sich von der Weisheit der Generationen daran erinnern, dass in der Medizinprodukte- und IVD-Programmierung das koordinierte Fliegen der Solo-Flugakrobatik vorzuziehen ist! Medizinprodukte- und IVD-Softwareentwicklung, eine Systemperspektive - ist es Zeit für die Migration?

Abbildung 5: Software V-Diagramm - Systemperspektive

Tags

Benötigen Sie weitere Informationen?

Haben Sie Fragen oder benötigen Sie weitere Informationen zu diesem Thema? Nehmen Sie Kontakt mit uns auf. Wir helfen Ihnen gerne weiter.

Kontaktformular
Haben Sie Fragen oder benötigen Sie weitere Informationen? Kontaktieren Sie uns. Wir freuen uns auf Ihre Anfrage. Kontaktformular