RE bei Medizinprodukten und in der Medizintechnik

Wo Pragmatismus und Regularien aufeinanderprallen

• Jedes Projekt hat sie (irgendwie): Requirements (Anforderungen).
• Jedes Projekt will sie (hoffentlich): Gute Requirements.
• Jedes Medizintechnikprodukt muss sie haben: Medical Device Regulation (MDR) - konforme Requirements.

Wenn man mit dem üblichen Pragmatismus mal schnell ein paar User Stories schreibt, wird man bei der Entwicklung von Medizinprodukten schnell mit der harten regulatorischen Realität konfrontiert. User Stories sind nicht verboten, aber: es gibt strenge formale Anforderungen an die Requirements und auch an die Prozesse im Requirements Engineering.

Warum ist Requirements Engineering in der Medizintechnik so besonders?

Da ist zunächst der regulatorische Hammer: Bei der Entwicklung und Herstellung von Medizinprodukten erweist sich die Einhaltung regulatorischer Anforderungen (Regulatory Requirements) wie der MDR (Medical Device Regulation), diverser Normen sowie Standards als sehr aufwändig. Beispielsweise beschreibt die ISO 13485 regulatorische Anforderungen an Qualitätsmanagementsysteme für Medizinprodukte. Die Norm für Medizingerätesoftware (IEC 62304) fordert die Dokumentation von Akzeptanzkriterien für die Verifizierung und Validierung von Softwareeinheiten. Die IEC 60601-1 enthält Anforderungen an den Nachweis der elektrischen Sicherheit von Medizinprodukten und die Festlegung von Akzeptanzkriterien für die wesentlichen Leistungsmerkmale. Nicht zu vergessen sind die Anforderungen an das Risikomanagement für Medizinprodukte (ISO 14971). Diese Norm unterstützt den Hersteller von Medizinprodukten bei der Identifizierung der mit dem Produkt verbundenen Gefahren, bei der Abschätzung und Bewertung der damit verbundenen Risiken, bei der Beherrschung dieser Risiken und bei der Überwachung der Wirksamkeit der Maßnahmen zur Beherrschung dieser Risiken.

Und das nur ein Auszug der zu erörternden Regularien.

Ist die reine Einhaltung der Regularien auch praktikabel und welche Risiken können dabei entstehen? Um Stolpersteine in der Entwicklung, Prüfung und Zulassung rechtzeitig zu erkennen und auf dem Weg zur Markteinführung weder Zeit noch Geld zu verlieren, ist es wichtig:

• ...zu verstehen, was hinter den Regeln steckt und welche spezifischen Risiken damit adressiert werden.
• ...frühzeitig ein Requirements Engineering (RE) mit den richtigen Fachleuten aufzubauen und die Anforderungen während des wachsenden Projekts kontinuierlich zu pflegen.

Was ist also nun der Grund für die komplexen Regularien?

Intended Use und Risk Management: Patientinnen und Patienten helfen, ohne sie zu gefährden

Am Anfang eines Medizinproduktes steht die Produktidee. Hier setzt das Requirements Engineering an und formuliert die grundlegenden Anforderungen, um den Intended Use (bestimmungsgemäßen Gebrauch) zu beschreiben. Wenn das Produkt fehlerhaft ist oder fehlerhaft angewendet werden kann, geht es nicht nur um Geld, sondern potentiell um Menschenleben!

Deshalb setzt hier das Risikomanagement an und betrachtet die Gefahren und Risiken, die sich aus dem Intended Use und den technischen Eigenschaften für Patientinnen, Patienten und Anwendende ergeben. Die Regelwerke bauen inzwischen auf jahrzehntelanger Entwicklungspraxis in risikobehafteten Bereichen auf, um durch entsprechende Normen zu helfen, Risiken von Anfang an beherrschbar zu machen.

Wie sieht nun ein risikobewusstes, regulatorisch korrektes, aber dennoch effizientes und pragmatisches Requirements Engineering aus?

Als Basis muss das Produkt mit seinen Eigenschaften gut definiert sein. Designentscheidungen müssen mit ihren Abhängigkeiten und Auswirkungen vom gesamten Team verstanden und überblickt werden können:

RE ist Kommunikation: ohne ständiges Austauschen und Abstimmen geht es nicht

Da der Fokus sehr stark auf den Produktrisiken liegt und deren Eigenschaften, Wechselwirkungen und Abhängigkeiten gut verstanden sein müssen, werden alle fachlichen und technischen Anforderungen vor und während des Projektes umfassend diskutiert: Eine kontinuierliche Kommunikation zwischen den Stakeholdern und den einzelnen Bereichen Qualitätsmanagement, Risikomanagement, Testmanagement, Releasemanagement und Changemanagement ist essentiell.

• Alle diese Bereiche beeinflussen die Anforderungen und die Anforderungen beeinflussen die Bereiche.

Werden die Anforderungen nicht ausreichend oder korrekt identifiziert, spezifiziert und dokumentiert, sind die Folgen:

• Qualitätssicherung (QS) ist immer nur so gut wie die Qualität der Requirements.
• Fehlende oder mangelhafte Dokumentation führt bereits im Entwicklungsprozess zu teuren Nacharbeiten.
• Im schlimmsten Fall erhält das Produkt keine Marktzulassung.
• Im schlimmsten Fall kommen Menschen zu Schaden, weil aufgrund einer mangelhaften Dokumentation eine Zulassung für ein fehlerhaftes Produkt erteilt wurde.

Der letzte Punkt zeigt noch einmal: Blindes Einhalten von Formalismen hilft nicht wirklich weiter, Kommunikation und Verständnis für das Produkt und seine Risiken sind wichtiger!

Requirements Engineering muss daher in ein kommunikatives und lernfähiges Projektvorgehen eingebettet sein. Agile Vorgehensweisen sind nicht nur erlaubt, sondern bringen die notwendige Flexibilität. Hier ist “nur” die Gewichtung der Dokumentation etwas höher als sonst üblich: Letztlich darf die nachhaltige Verschriftlichung der Konsensfindung nicht fehlen (frei nach Goethe). adesso unterstützt hier gerne mit vielseitigen Fachexpertinne und -experten und Qualitätsmanagement beim Aufbau und der Etablierung des Requirements Engineering!

Das Shit-in-Shit-Out-Prinzip: RE ist maßgeblich für die Qualitätssicherung

Durch den ständigen Austausch im Projekt und darüber hinaus stellt das Requirements Engineering sicher, dass folgende Punkte überprüft werden können:

• Risiken durch konstruktive Maßnahmen berücksichtigt werden (Risikomanagement / ISO 14971)

• Das Produkt gebrauchstauglich, ergonomisch und gegebenenfalls barrierefrei ist (Usability / IEC 62366)

• Die Zweckbestimmung wird korrekt und angemessen umgesetzt (Einhaltung der Zweckbestimmung / MDR)

• Die technischen Rahmenbedingungen sind über den gesamten Lebenszyklus durch Architektur und DevOPs-Prozesse abgedeckt (IEC 62304, ISO60601-1).

• Das Produkt kann effizient genutzt, betrieben und produziert werden (das Kosten-Nutzen-Verhältnis ist für Hersteller und Kunden angemessen).

Und wie schaffen wir es nun, dass unser Netz aus User Requirements, Software Specifications, Test Specifications etc. nicht zu einer großen Schüssel Spaghetti wird?

Traceability muss sein!

Ein weiterer Stolperstein kann die Frage der Rückverfolgbarkeit sein: Das bedeutet zunächst einmal viel Fleißarbeit und verlangt von allen Beteiligten Disziplin bei rein formalen Aspekten der Dokumentation. Aber nur so kann sichergestellt werden, dass beispielsweise Details im Produktdesign auf tatsächliche Anforderungen zurückgeführt werden können oder dass bestimmte Anforderungen sowohl implementiert als auch verifiziert (das heißt getestet) wurden. Wir müssen also im Dienste der Risikobeherrschung strikt darauf achten, dass alle gewollten Anforderungen - und nur diese! - und dass die implementierten Anforderungen auch vollständig verifiziert wurden.

Damit wir also einerseits nichts vergessen - und andererseits nachweisen können, dass wir an alles gedacht haben - ist die Traceability so wichtig. Sie stellt eine lückenlose „Beweiskette“ dar, ohne die ein Software Verification and Validation Report keine wirkliche Aussagekraft hat.

• Wohlbemerkt: wir sprechen von komplexen technischen Systemen, die ohne Gefahr für Leib und Leben nutzbar sein sollen!
• Traceability ist der rote Faden zwischen Rahmenbedingungen, Risiken, Requirements, Design und Implementierung und Qualitätssicherung.

Eine solche „Beweiskette“ verbindet zum Beispiel eine bestimmte Usability-Richtlinie mit einer im Risk Management festgehaltenen Gefährdungssituation, mit der daraus abgeleiteten und im Usability Engineering File spezifizierten Regel für das UX-Design, diese wiederum mit einer konkreten Software-Requirement für die Benutzerführung und so weiter.

So weit, so gut - aber es besteht immer noch ein gewisses Risiko der „Spaghettification“ der Dokumentation: Es ist an der Zeit, sich nach geeigneten Werkzeugen umzusehen.

Alles im Griff: Application Lifecycle Management (ALM)

Die ideale Lösung, um den großen und vielfältigen Zoo von Dokumenten, Links, Tickets und Workflows in den Griff zu bekommen, ist die Einführung eines so genannten Application Lifecycle Management Tools (ALM). Ein gutes ALM bietet Dokumentenmanagement, Anforderungsdatenbank, Ticketsystem und Workflowmanagement aus einem Guss. Es bietet die jeweils passenden Sichten für Requirements Engineering, Entwicklung und QA ohne Medienbrüche zwischen den Spezialsystemen. Damit kann auch die Nachvollziehbarkeit einfach dargestellt und gepflegt werden. Auch hier unterstützt adesso gerne mit Expertise, Templates und viel Erfahrung mit verschiedenen ALM-Systemen und berät bei der Beschaffung und/oder Einführung.

Fazit

Wie ihr sehen könnt, ist Requirements Engineering in der Medizintechnik durchaus eine Herausforderung. Wenn man aber den Fokus auf Intended Use und Patientenrisiko verstanden hat, ist es eine sehr spannende Angelegenheit.

Diese Herausforderung muss niemand alleine bewältigen: Unsere Expertinnen und Experten sind genau dafür ausgebildet! Durch unsere vielfältigen Projekterfahrungen und unser umfassendes Fachwissen können wir unseren Kunden maßgeschneiderte und praktikable Lösungen anbieten. Sprecht uns gerne an!