User Storys in der Entwicklung medizintechnischer Produkte

Karl Bredemeyer hat in seinem Artikel “Scrum in der Medizintechnik” die allgemeinen Vorteile agiler Methoden für die Entwicklung medizintechnischer Produkte beschrieben. Durch einen iterativen und inkrementellen Ansatz sind Verifikation und Validierung durch die gesamte Entwicklung hindurch möglich. In diesem und den nächsten beiden Beiträgen zeigen wir anhand von konkreten Beispielen aus unseren Projekten, wie das geht.
Anders als bei reinen Softwarelösungen sind bei medizintechnischen Produkten in der Regel verschiedene Komponenten – Mechanik, Eletronik, Software – miteinander zu integrieren, um ein Produktinkrement zu erreichen. Nehmen wir ein Beispiel:
Bei einem Gerät zur Laborautomatisierung soll ein Schließmechanismus für Röhrchen gebaut werden – dies ist unser Produkinkrement. Die Mechanik wird sich um Greifarme und Achsen kümmern müssen, die Elektronik um Motorsteuerung und Fahrmethode, und die Software um die Koordination der Arbeitsabläufe. Die Integration aller Komponenten zu einem funktionierenden Mechanismus mit wirtschaftlichem Wert kann nur dann gelingen, wenn zu jedem Zeitpunkt spezifiziert ist, wie sich das Gesamtsystem zu verhalten hat. Ausgangslage dafür sind in Scrum so genannte Epics. Sie postulieren, welche Funktionalität ein Benutzer des Systems braucht, und welchen Nutzen er davon hat.
Beispiel: Als Medizinisch Technische Assistentin (MTA) brauche ich einen automatischen Schließmechanismus für Röhrchen, damit ich die Laborproben nicht mehr von Hand verschließen muss.
In der Regel gibt es mehr als eine Epic pro Produkt. Neben dem Schließmechanismus könnten beispielsweise Öffnungsmechanismus, Transportmodul, Aliquotierfunktion sowie Ein- und Aussortierer dazukommen. Die Auflistung aller Epics in einer nach wirtschaftlichem Wert priorisierten Liste bildet das Product Backlog.
Im nächsten Schritt werden die Epics in Anforderungen, Akzeptanzkriterien und -tests sowie in Rahmenbedingungen analysiert. Das kann dann für die Epic aus unserem Beispiel folgendermaßen aussehen:
Anforderungen: Die Röhrchen sollen durch automatisches Aufdrücken einer Kappe verschlossen werden.
Akzeptanzkriterium:Der MTA muss keine zugelassenen Röhrchen mehr von Hand verschließen.
Akzeptanztest:600 Röhrchen mit zugelassenen Maßen werden innerhalb von 30 Minuten auslaufdicht verschlossen.
Rahmenbedingungen:

Ist eine Epic so heruntergebrochen, lässt sich bestimmen, welche Komponenten welchen Entwicklungsstand haben müssen, und welche Tests auf Komponenten- und Systemeben laufen müssen, um die Epic laut Akzeptanzkriterium zu erfüllen. Im hier genanten Beispiel werden Software, Elektronik und Mechanik so zusammenspielen müssen, dass Röhrchen zuverlässig versiegelt werden können. Ist dieses funktionale Zusammenspiel erreicht, ist das Produktinkrement erbracht.
Die Entwicklung orientiert sich an der sequenziellen Fertigstellung von Epics, die nach ihrer Priorität fertig gestellt werden. Somit ist zu jedem Zeitpunkt ein Produkt vorhanden, das potenziell (natürlich begrenzt auf die aktuell vorhandenen Funktionen) verwendbar ist. Weitere, nicht notwendige Funktionen (z.B. Zentrifugierung) können dann mit einem späteren Release ausgeliefert werden.
Im nächsten Beitrag erfahren Sie, wie Sie ein Entwicklungsteam zusammenstellen, das in der Lage ist, Produktinkremente zu liefern.

Adaptive Licensing – Zulassung medizintechnischer Produkte als Lernprozess

Wer  ein medizintechnisches Produkt auf den Markt bringen möchte, muss einen langen Atem und viel Geld mitbringen. Die zwei wichtigsten Zulassungsbehörden – die FDA in den USA und die EMA in Europa – verlangen Nachweise dafür, dass das Produkt korrekt funktioniert und dass die Vorteile für die Gesundheit die bekannten Risiken überwiegen.
Keiner zweifelt an, dass eine solche Qualitätskontrolle in der Medizintechnik notwendig ist. Und doch gibt es in letzter Zeit vermehrt Überlegungen, wie der Zulassungsprozess sinnvoller gestaltet werden kann.
Derzeit werden Zulassungen erteilt, nachdem Nachweise über Funktionsweise und Wirksamkeit vollständig erbracht worden sind. Unter dem Schlagwort “adaptive licensing” wird eine Alternative verfolgt, die von einer stufenweisen Zulassung ausgeht. So könnten Medikamente oder Geräte zu einem frühen Zeitpunkt für eine Zielgruppe freigegeben werden, die davon in besonders hohem Maße profitiert und daher bereit ist, auch ein höheres Risiko einzugehen. Im Gegensatz zu klassischen klinischen Studien, in denen nur wenige Probanden zur Verfügung stehen, würde das Produkt unter produktionsnahen Bedingungen getestet werden. Die Herstellung würde unter Serienbedingungen, die Anwendung in verschiedenen klinischen Umgebungen laufen, und die Wirkung könnte anhand einer breiten, repräsentativen Bevölkerungsschicht getestet werden.

Zulassung als lernendes System

Eine solche, frühe Zulassung in begrenztem Umfang würde aus dem Zulassungsprozess ein lernendes System machen, das nicht eine, sondern mehrere Zulassungsstufen mit unterschiedlichen Akzeptanzkriterien kennt. Die Vorteile dieser Herangehensweise liegen auf der Hand: Patienten, die nicht mehr Jahre warten können, bekämen Zugang zu medizintechnischen Innovationen. Hersteller können bereits vor der finalen Zulassung umfangreiche Informationen zu Funktion und Wirksamkeit sammeln und Anpassungen noch während des Entwicklungsprozesses vornehmen. Und die Zulassungsbehörden bekämen mit jeder Zulassungsstufe ein akkurateres Bild davon, ob das Produkt die Anforderungen für die finale Freigabe erfüllt. Dadurch sollte die Anzahl an Recalls (Produkte, die nach der Zulassung wieder vom Markt genommen werden müssen) sinken. Am Ende profitieren alle davon.
Die Reform des Zulassungsverfahrens wird nicht von heute auf morgen geschehen. Doch das hindert uns nicht daran, die Produktentwicklung schon jetzt so zu gestalten, dass eine stufenweise Zulassung im Prinzip möglich wäre. Mit Scrum haben wir eine iterative und inkrementelle Produktentwicklung, mit der das Produktdesign kontinuierlich validiert werden kann. So ist die Prüfung der Machbarkeit kein Konzept mehr, sondern empirisch nachweisbar. Das Produkt ist zu jedem Zeitpunkt auf einem Stand, auf dem es prinzipiell ausgeliefert werden könnte. Projektfortschritte sind nachvollziehbar und der geschaffene Wert lässt sich beziffern.
Der genaue Weg dorthin wird in den nächsten drei Beiträgen genauer beschrieben:
1) Lieferung von Produkt- statt Komponenteninkrementen
2) Aufbau eines cross-funktionalen Teams, damit 1) machbar ist
3) Einsatz von Reviews, um Validierung nach IEC 62366 zu erlangen
Referenz: If everyone hates the FDA approval process, let’s fix it

5 minutes on regulations – wie gute Prozesse in der Medizintechnik Innovation verhindern

Ich hatte letztens das Vergnügen, drei Stunden Einführung in RUO und IVD Regulatorien zu bekommen. RUO steht für “Research Use Only” und IVD für “In Vitro Diagnosis”.[1] Diese strengen Richtlinien der FDA (Food And Drug Agency) beschreiben, was ein Hersteller vorweisen muss, damit die FDA seine Produkte auf dem amerikanischen Markt zulässt.
Ich kann hier gar nicht auf all das eingehen, was gefordert wird, aber ich habe zwei Zahlen für euch: Für ein RUO-Produkt – also eines, das nur für Forschungszwecke herangezogen werden darf – müssen ungefähr 2500 Seiten Dokumentation an die FDA geschickt werden, auf denen sorgfältig festgehalten wurde, wie dieses Produkt funktioniert. Ein IVD-Verfahren verlangt ungefähr 10.000 Seiten Dokumentation.
Das aber in Wahrheit Merkwürdige: Wer ein IVD-Produkt einreichen will, muss nachweisen, inwieweit dieses Produkt im Vergleich zu einem bereits bestehenden Produkt besser ist. In irgendeinem Faktor. Es wird also nur etwas Neues mit etwas Altem verglichen. Wer etwas noch nie Dagewesenes erfindet, muss sich also mit der FDA darüber einigen, wie man damit umgehen will.
Okay, das ist noch alles irgendwie verständlich. Es geht um das Leben von Menschen und da müssen Fehler so weit als möglich vermieden werden. Aber jetzt wird es noch faszinierender: Angenommen, man hat die Zulassung und will etwas am Gerät verändern – sagen wir, das User Interface der Adminoberfläche eines computerunterstützten Produkts. Dann könnte es passieren, dass alle 10.000 Seiten erneut eingereicht werden müssen. Ach ja, das Ganze kostet ca. 250.000,- US Dollar.
Sicher, wer will entscheiden, ob es nur eine kleine, unbedeutende Änderung ist, oder eine mit schwerwiegenden, vielleicht noch nicht absehbaren und möglicherweise tödlichen Folgen. Aber was sich damit natürlich wie von selbst erledigt, ist Innovation. Innovation findet, wie wir spätestens seit dem Buch „The Innovator’s Dilemma“ wissen wissen, am Rand – “in the fringe” – statt. Da, wo es noch keine großen Gelder gibt. Da, wo noch nicht klar ist, wie etwas funktioniert. Es zeigt sich im Kleinen.
Prozesse wie jene der FDA sind notwendig, keine Frage – doch wir brauchen intelligente Antworten darauf, wie wir diese Anforderungen erfüllen. Wir brauchen diese Antworten, weil wir auch in der Medizin noch viele Probleme lösen müssen.
[1]”In vitro diagnostic products are those reagents, instruments, and systems intended for use in diagnosis of disease or other conditions, including a determination of the state of health, in order to cure, mitigate, treat, or prevent disease or its sequelae. Such products are intended for use in the collection, preparation, and examination of specimens taken from the human body. [21 CFR 809.3]” Mehr Information dazu hier

Scrum in der Medizintechnik: Wie stelle ich ein erfolgreiches Team zusammen?

Auch in stark regulierten Branchen wie der Medizintechnik ist es möglich, Produkte mit Scrum zu entwickeln – das hat sich mittlerweile von den IT-Abteilungen deutscher Dienstleistungsunternehmen über den innovativen Mittelstand bis in die großen Konzerne durchgesprochen*. Aber wo anfangen, wenn die Entscheidung für Scrum einmal gefällt wurde? Der Erfolg Ihres Projekts steht und fällt mit dem Team.
Scrum, richtig gelebt, bietet Ihnen die Möglichkeit, sämtliches Know-how, das Sie für die Entwicklung Ihres Produkts benötigen, in einem Team zu bündeln. Auf diese Weise lassen sich zusätzliche Aufwände und Redundanzen an Übergabepositionen minimieren und gleichzeitig dringend benötigtes Wissen beinahe automatisch auf mehrere Köpfe verteilen.
baseball-74003_640

Herausforderungen für die Medizintechnik

Für die Hersteller medizintechnischer Geräte bedeutet das allerdings nicht nur, Anwendungsentwickler und Tester zusammenzusetzen. Zu der ohnehin schon komplexen Aufgabe, Hardware und Software miteinander zu kombinieren, kommt hinzu, dass konstruierte Teile bestellt, Risikomanagement-Checklisten abgearbeitet und vor allem regulatorische Anforderungen erfüllt werden müssen. Neben Hard- und Softwareentwicklern sowie Konstrukteuren brauchen Sie in Ihrem Team also auch noch einen Einkäufer, jemanden aus der Produktdokumentation und eine Person, die sich mit den regulatorischen Anforderungen auskennt.

Pilotteams nicht als Wetterfrösche missbrauchen!

Viele Unternehmen treffen die Entscheidung, Scrum zunächst in Pilotprojekten auszuprobieren, um die Organisation nicht zu überfordern und ein Gefühl dafür zu bekommen, ob das funktionieren kann, oder nicht. Der Gedanke, die Organisation nicht zu überrumpeln, ist nachvollziehbar, und das Aufsetzen einer Pilotgruppe auch empfehlenswert.
Aber: Jedes Pilot-Team wird früher oder später an strukturelle Grenzen stoßen, vor allem wenn die Abteilungen, die den Teams zuarbeiten, nicht entsprechend geschult sind. Insbesondere wenn es um Anforderungen „aus dem Feld“ oder seitens der Regulierungsbehörden geht, kann die Integration entsprechender Know-how-Träger in ein Scrum-Team sehr viel Zeit sparen. Heißt das, mein QM – Mitarbeiter ist jetzt 100% der Zeit im Scrum-Team? Nicht unbedingt.

Verantwortungsbewusstsein schaffen

Allein das Commitment „entwicklungsfernerer“ Kollegen, regelmäßig zu Meetings wie Sprint Planning, Daily oder Review zu erscheinen, wird einen großen Beitrag zu mehr Effizienz Ihrer Scrum-Teams leisten.
Bei einem unserer Kunden in der Laborautomatisierung gibt es beispielsweise einen Projekteinkäufer, der regelmäßig die Dailies mehrerer Scrum Teams besucht und somit für das Team stets zu verlässlichen Zeitpunkten als Ansprechpartner zur Verfügung steht, sollte es beispielsweise Rückfragen zu Lieferzeiten geben. Und auch für die Arbeit des Projekteinkäufers ergeben sich durch die Unmittelbarkeit viele Vorteile. So bekommt er schnell ein Gefühl für die Dringlichkeit sowie über mögliche Zusammenhänge einzelner Bestellungen.
Auch bei der Erstellung von Bedienungs- oder Servicehandbüchern lassen sich eine Vielzahl von Verzögerungen und doppelten Arbeitsschritten durch die rechtzeitige Einbindung entsprechender Kollegen vermeiden. Schaffen Sie ein Bewusstsein dafür, dass Ihr Projekt nur durch das Zusammenwirken aller Parteien erfolgreich werden kann und das Scrum hierfür den notwendigen Rahmen bietet. Haben Sie die Rahmenbedingungen einmal abgesteckt und kommuniziert, werden sich Ihre Teams so aufstellen, wie sie es für eine anwenderfreundliche und normgerechte Produktentwicklung brauchen.
*Sowohl der Technical Information Report TIR 45:2012 der AAMI (Association for the Advancement of Medical Instrumentation ) als auch die Prozess-Norm IEC 62304 geben Herstellern explizit die Freiheit, ihre Produkte so zu entwickeln, wie sie es für richtig halten – solange die Produktsicherheit und -qualität gewährleistet bleiben.

Don't blame the User: Gebrauchstauglichkeit bei Medizinprodukten

Wir alle kennen die Situation: Man möchte eine Herdplatte anmachen, steht jedoch vor vier Knöpfen. Welcher passt zu welcher Herdplatte? Auch nach mehreren Jahren Gebrauch kann es passieren, dass die falsche Platte angeschaltet wird. Hier bleibt das ohne ernsthafte Konsequenzen – man sieht, dass die falsche Herdplatte aufleuchtet und bemerkt den Bedienungsfehler. Was aber, wenn es es nicht um die Herdplatte, sondern um eine Herzpumpe geht?
Ein Fallbeispiel: Eine Krankenschwester wollte das Alarmsignal einer Insulinpumpe kurzfristig abschalten, schaltete es stattdessen aber komplett aus. Die nachfolgende Untersuchung zeigte: Der Unterschied zwischen den beiden Schaltern – einmalige versus dauerhafte Abschaltung – war für den Benutzer nicht erkennbar. Und: Der Hinweis, dass der Alarm ausgeschaltet ist, war in einer Ecke des Bildschirms als kleines Symbol versteckt und in der Informationsflut für den Benutzer schlicht untergegangen.
Die Food and Drug Administration (FDA) erhält im Jahr circa hunderttausend Incident Reports über medizintechnische Geräte. Über ein Drittel davon sind auf Benutzerfehler (user errors) zurückzuführen (Quelle: Invetech)
Wie die IEC 62366 einen Entwicklungsprozess für Gebrauchstauglichkeit beschreibt
Es ist leicht, in solchen Fällen die Schuld beim Benutzer zu suchen. Und, sicherlich: Mit einer adäquaten Schulung, einer ausführlichen Einarbeitung und einer weniger hektischen Arbeitsatmosphäre ließen sich viele Fehler im Gebrauch vermeiden. Das aber ist Verantwortung von Krankenhäusern, Praxen und Laboren. Für den Hersteller gilt: Baue ein Produkt, das Benutzerfehler so gut es geht ausschließt.
Die Norm IEC 62366 befasst sich mit der Gebrauchstauglichkeit von medizinischen Produkten. Sie beschreibt einen Entwicklungsprozess, der die Gebrauchstauglichkeit von der Erhebung der Anforderungen bis zum Testen im Blick hat. Dazu gehören folgende Schritte:

Scrum bietet mit seinem Fokus auf den User verschiedene Möglichkeiten, die Gebrauchstauglichkeit im Entwicklungsprozess zu berücksichtigen. Hier seien zwei zentrale Elemente vorgestellt:

  1. Der Einsatz von so genannten Personas ist eine gute Möglichkeit, Benutzerrollen zu identifizieren. Einer unserer Kunden, der Geräte zur Laborautomatisierung herstellt, hat als eine von mehreren Personas eine 25-jährige Lab-Operator mit dem Namen María Morales. Sie nimmt die Laborproben entgegen, packt sie aus und transportiert sie ins Labor. Sie hat mittelmäßige Englisch-Kenntnisse, liest keine Benutzerhandbücher, und verlässt sich stark auf ihre Intuition. María Morales gibt es nicht wirklich, aber ihr Alter, ihre Bildung und Arbeitsweise sind repräsentativ für viele Lab-Operators. Wer solche Personas bei der Produktentwicklung im Blick hat, kann von Anfang an auf ihre Bedürfnisse eingehen und braucht erst gar nicht darauf zu hoffen, dass der Benutzer in kritischen Situationen das Handbuch zu Rate ziehen wird.
  2. Mit dem Review-Meeting am Ende jeden Sprints können die funktionalen Produktinkremente vom Benutzer validiert werden. Fallbeispiel: Ein Kunde entwickelt eine neue Schublade zur Aufnahme von Schalen mit Plastikspitzen, die zum Aliquotieren von Urin- oder Blutproben verwendet werden. Indem eine pharmazeutisch-technische Assistentin (PTA) zum Review der ersten Prototypen  eingeladen wird, kann sie bereits die Schublade in Betrieb nehmen und mögliche Bedienungsfehler (z.B. Öffnen der Schubladen im laufenden Betrieb oder Einklemmen der Plastikspitzen) sichtbar machen.

Weitere Möglichkeiten der Validierung über das Review hinaus hat Roman Pichler hier beschrieben.
Literatur:
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag
Jamie Hartford: Human Factors: Identifying the Root causes of Use Errors

Der Lebenszyklus medizinischer Software

Im Beitrag “Medizintechnik – im Dickicht der Normen” erwähnte ich, dass sich die regulatorischen Anforderungen der Medizintechnik erst seit einem knappen Jahrzehnt eigens mit Softwareentwicklung beschäftigen.
Das hat einen einfachen Grund: Die Software spielte bei der Entwicklung medizintechnischer Produkte lange Zeit eine untergeordnete Rolle. Software war “das Programm”, mit dem die Geräte bespielt werden mussten, “Hardware was king” (http://rtcmagazine.com/articles/print_article/102203). Heute kann man sich dieses Weltbild nicht mehr leisten. Je mehr Software in einem Produkt steckt, desto größer deren Bedeutung – und Komplexität. Es stellt sich die Frage, wie diese überhaupt in den Griff zu bekommen ist. Wie ist zu gewährleisten, dass die Software das (und zwar nur das!) tut, was sie tun soll? In einer Spiele-App kann noch verziehen werden, wenn die Applikation unvorhergesehenes Verhalten zeigt. Schlimmstenfalls ist dann ein Neustart erforderlich. In der Medizintechnik kann das gleiche Verhalten Leben kosten.
Vor diesem Hintergrund wurde 2007 die EN IEC 62304 verabschiedet. Hierbei handelt es sich um eine mit den entsprechenden Richtlinien harmonisierte Norm, die sich mit dem so genannten “Lebenszyklus” (lifecycle) medizinischer Software beschäftigt. Mit “Lebenszyklus” ist der Lebenslauf der Software von der Planung bis zur Wartung gemeint. Die IEC 62304 nennt in diesem Zusammenhang fünf Prozessgebiete, die spezifisch für Software zutreffen:

Für jeden dieser Bereiche macht die EN 62304 Vorschläge zur Umsetzung. Die EN 62304 legt sich jedoch auf kein Entwicklungsmodell fest. Vielmehr erwähnt sie Wasserfall, iterativ-inkrementelle, und evolutionäre Vorgehensweisen als Beispiele, mit denen gearbeitet werden kann. Schauen wir uns die Umsetzungsvorschläge dieser Norm genauer an:

Die hier genannten Aktivitäten ziehen einen nicht geringen Dokumentationsaufwand nach sich. Dieser Aspekt führt häufig zur Meinung, dass agile Methoden für die Einhaltung solcher Normen nicht geeignet seien. Martin Bakal von IBM schlägt in dieselbe Kerbe, wenn er schreibt:
“There is even a fairly new standard, IEC 62304, adopted worldwide that is wholly focused on software traceability from requirements through architecture to tests. These requirements and others mean we need traceability and reporting we typically only see in heavy-weight processes like waterfall.” (http://agile.dzone.com/articles/making-agile-development-work)
Hier müssen wir unterscheiden zwischen den Möglichkeiten agiler Frameworks und ihrer aktuellen Nutzung. Natürlich werden Scrum und andere agile Frameworks u.a. in Projekten angewandt, die ein geringes Maß an Reporting und Traceability erfordern. Das heißt aber noch lange nicht, dass Scrum et al. zur Anwendung in hochregulierten Branchen ungeeignet sind.
Eher im Gegenteil: Mit ihrem Anspruch, am Ende jedes Sprints potenziell auslieferbare Funktionalitäten fertigzustellen, sind agile Frameworks wie Scrum von Natur aus darauf ausgerichtet, Verifikation und Validation in die Sprints zu packen. Continuous Integration und Testautomatisierung führen dazu, dass Software permanent auf ihre Integrität getestet wird. Auch das Risikomanagement lässt sich mit Scrum hervorragend integrieren: In einem unserer derzeitigen Projekte prüft das Entwicklungsteam jede neue Story mit Hilfe eines Templates auf Produktrisiken. Diese Prüfung ist Teil der Definition of Done dieses Teams, so dass Stories nicht erledigt sind, solange die Risikoprüfung nicht stattgefunden hat. Auch gibt es mitterweile eine Reihe von Tools, die speziell dafür entwickelt wurden, den Lebenszyklus medizinischer Software für agile Produktentwicklung inklusive umfassender Traceability abzubilden.
In der nächsten Folge: Qualitätsmanagement mit der Norm EN ISO 13485

Medizintechnik – im Dickicht der Normen

Keine Frage: Die Medizintechnik ist ein stark regulierter Bereich. In forschenden und entwickelnden Unternehmen kann das Dickicht an Richtlinien, Normen und Verordnungen zu einem permanenten schlechten Gewissen führen. Gerade in Entwicklungsteams hängt das Thema Dokumentation dann wie eine schwarze Wolke über dem Projekt – nicht selten wird die Umsetzung der regulatorischen Anforderungen so lange wie möglich hinaus gezögert, um sie dann ganz zum Schluss mehr schlecht als recht auf Papier zu bringen.
Dabei geht es auch ganz anders. Regulatorische Anforderungen sind weder Metaphysik noch Mystik. Wer sie kennt und beherrscht, der wird sie bald so normal und banal finden wie Zähne putzen oder Hände waschen. Es geht am Ende darum, sie in den Entwicklungsprozess so einzuflechten, dass sie permanent eingeübt werden. Dazu muss man sie jedoch erst einmal kennen.
Ein guter Überblick über die gängigen Anforderungen ist recht schnell hergestellt. Denn die regulatorischen Anforderungen in der Medizintechnik beziehen sich im Wesentlichen auf vier Bereiche, für die es in Europa jeweils eine maßgebende Norm gibt:

Jedem dieser Bereiche wird in den kommenden Wochen ein einzelner Beitrag gewidmet sein. Heute geht es um die Entkräftung einiger Vorurteile, die einen normalen Umgang erschweren.

Vorurteil eins: Die Anwendung der oben genannten Normen ist verpflichtend.

Falsch. Hersteller von Medizinprodukten sind allein dazu verpflichtet, die Anforderungen bestimmter Richtlinien zu erfüllen (v.a. die Medizinprodukt-Richtlinie 93/42/EWG). Die dort formulierten Vorgaben sind jedoch so allgemein gehalten, dass sie nicht unmittelbar handlungsweisend sind. Beispielsweise findet sich dort die Forderung, dass “durch Anwendungsfehler bedingte Risiken aufgrund der ergonomischen Merkmale eines Produktes” so weit wie möglich reduziert werden sollen. Wie die Umsetzung geschehen soll und welcher Prozess dafür anzuwenden ist – darüber sagt die Richtlinie nichts. Die europäischen Normen füllen dieses Vakuum und treten als Umsetzungshilfen der Richtlinie an. Mehr noch: Wer die europäischen Normen einhält, der kann davon ausgehen, dass die entsprechenden Anforderungen in der Richtlinie ebenfalls erfüllt sind (im Fachjargon sagt man, die Norm sei mit der Richtlinie “harmonisiert”).

Vorurteil zwei: Die Normen für die Medizintechnik sind ganz spezieller Natur.

Nicht überall. Die Norm zum Qualitätsmanagement (EN ISO 13485) ist beispielweise in großen Teilen deckungsleich mit der weit verbreiteten ISO 9001.

Vorurteil drei: Software-Entwicklung ist den gleichen Richtlinien unterworfen wie die Hardware-Entwicklung.

Seit ihrer Überarbeitung im Jahr 2007 findet sich in der Medizinprodukt-Richtlinie die Forderung, dass der Software-Lebenszyklus nach dem Stand der Technik entwickelt werden soll. Die dazu korrespondierende Norm EN 62304 beschäftigt sich nur mit der Software-Entwicklung und beschreibt die einzelnen Phasen von der initialen Produktplanung bis zur Wartung. Spannenderweise legt sie sich nicht auf einen Entwicklungsframework fest, sondern bleibt hier offen. Inkrementelle und evolutionäre Ansätze werden als mögliche Herangehensweisen explizit erwähnt.
Literatur:
Christian Johner u.a. (2011): Basiswissen Medizinische Software. dpunkt.verlag