Hier finden Sie Informationen zur Gebrauchstauglichkeit (Usability) von Medizinprodukten und zu regulatorischen Anforderungen wie die der FDA und der IEC 62366-1.
Die FDA sagt, dass der Begriff Usability häufig mit Design verwechselt würde, weshalb man besser den Begriff „Human Factors Engineering“ nutzen sollten. In der Tat, Usability hat erst einmal nichts mit schicken Farben und Schlagschatten oder trendigen Design-Elementen zu tun.
Die ISO 9241 definiert Gebrauchstauglichkeit/Usability als das Ausmaß, in dem ein interaktives System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.
Wichtig bei dieser Definition ist, dass die Gebrauchstauglichkeit eines Medizinprodukts keine absolute Eigenschaft ist, sondern von den Charakteristiken der Nutzer und der Nutzungsumgebung abhängt.
Die Definition des Begriffs Gebrauchstauglichkeit bei der IEC 62366-1 ist sehr ähnlich: Eigenschaft des User Interfaces, die den Gebrauch unterstützt und damit Effektivität, Effizienz sowie Zufriedenheit des Users in der festgelegten Nutzungsumgebung erzielt.
Die MTD schreibt in einem Artikel: „Nach Prof. Dr. Uvo Hölscher/FH Münster gehen Experten von 17.000 vermeidbaren Anwendungsfehlern mit Todesfolge pro Jahr in deutschen Krankenhäusern aus. Zwei Drittel aller unerwünschten Ereignisse im Rahmen der Medizintechnik beruhen auf Bedien- und nur ein Drittel auf Produktfehlern. […] An die Krankenhäuser appellierte Hölscher, die Ergonomie bei Einkaufsentscheidungen stärker zu berücksichtigen. Einfacheres, sicheres und schnelleres Bedienen würde langfristig zu Einsparungen führen.”
Damit werden die Hersteller nun von zwei Seiten gedrängt, die Gebrauchstauglichkeit ihrer Produkte zu verbessern. Von den Kunden (den Krankenhäusern) ebenso wie von den benannten Stellen, die bei den Audits auf die Einhaltung der Forderungen der IEC 62366-1 achten. Auch die FDA rückt die Gebrauchstauglichkeit (Usability) ins Zentrum ihrer Prüfungen.
Die MDR misst der Usability große Relevanz bei. Sie finden Anforderungen daran u. a. in folgenden Kapiteln:
Auch im Rahmen des Post-Market Clinical Follow-ups und der Post-Market Surveillance spielt die Usability eine Rolle: Rückmeldungen der Anwender und Informationen über Probleme (auch Nutzungsprobleme) müssen systematisch gesammelt und bewertet werden.
Analog zu Medizinprodukten gilt für In-vitro–Diagnostika (IVD) die IVDR in der EU, welche ebenfalls Anforderungen an die Usability bzw. Ergonomie stellt. Insbesondre ist Anhang I Absatz 19.2 beachtenswert. Dort wird explizit gefordert, dass Produkte zur Eigenanwendung und patientennahe Tests (Point of care-; Bedside-Produkte) vom Anwender „in allen Bedienungsphasen sicher und fehlerfrei“ verwendet werden können.
Die Hersteller von Medizinprodukten können im Rahmen einer Konformitätsbewertung (Auditoren, benannte Stellen) vermuten lassen, dass sie diese Forderungen erfüllen, wenn sie ihre Medizinprodukte konform der IEC 62366-1 entwickeln. Diese Norm trägt den Titel „Medizinprodukte – Anwendung der Gebrauchstauglichkeit auf Medizinprodukte“ auf Englisch „Medical devices – Application of usability engineering to medical devices“.
Hersteller müssen die Anforderungen des 21 CFR part 820 erfüllen. Dazu zählen auch die Design Controls des 21 CFR part 820.30. Die wiederum verlangen ein Risikomanagement, das auch Risiken durch mangelnde Gebrauchstauglichkeit betrachten muss.
Konkreter wir die FDA im „Guidance Document“ dem Titel „Applying Human Factors and Usability Engineering to Optimize Medical Device Design“. Dieses Dokument ist aber keine Norm. Entsprechend hat es nicht die gleiche sprachliche Reduktion und Präzision. Teilweise gleicht es mehr einem Lehrbuchcharakter als eine Liste konkreter Forderungen — obwohl es dieser viele beinhaltet.
Zwar fordert das Guidance Dokument keinen so detaillierten Prozess wie die IEC 62366-1 und orientiert sich in etwa an dem der ISO 14971. Dafür sind aber die anzuwendenden Verfahren erwähnt, die in der IEC 62366-1 bestenfalls im Anhang zu finden sind. Bei Widersprüchen mit anderen Standards wie der 62366-1 aber auch dem AAMI HE 75 nimmt das Guidance Dokument in Anspruch Vorrang zu haben!
Lesen Sie hier mehr zum FDA Guidance Document zum Human Factors Engineering und zu den Anforderungen der FDA an das Human Factors Engineering.
Nicht nur die US-Gesundheitsbehörde (FDA), sondern weitere Behörden stellen Anforderungen an die Gebrauchstauglichkeit:
Die britische „Medicine & Healthcare Products Regulatory Agency“ hat einen Leitfaden („Human Factors and Usability Engineering –
Guidance for Medical Devices Including Drug-device Combination Products“) herausgegeben. Dieser Leitfaden ist in mehrerer Hinsicht beachtenswert:
Der Leitfaden stellt somit keine neuen Anforderungen, hilft aber die gesetzlichen Anforderungen umzusetzen. Genau das haben sich die IEC 62366-1 und IEC 62366-2 auch vorgenommen.
Die Norm beschreibt v.a. einen „gebrauchstauglichkeitsorientierten Entwicklungsprozess“, auf Englisch „Usability Engineering Process“. Im Rahmen dieses Prozesses müssen die Hersteller
Der Fokus der IEC 62366-1 liegt eindeutig auf der Minimierung des Risikos durch mangelnde Gebrauchstauglichkeit. Weitere Ziele des Usability Engineerings wie höherer Markterfolg der (Medizin-)Produkte und die effiziente Entwicklung (ohne unnötige Iterationen) werden von der IEC 62366-1 nicht adressiert.
Medizinprodukte sind definitionsgemäß genau dann gebrauchstauglich, wenn spezifizierte Nutzer im spezifizierten Nutzungskontext die spezifizierten Aufgaben effektiv, effizient und zufriedenstellend erreichen können. Eine zwingende Voraussetzung dafür ist, dass die Nutzungsanforderungen (dieser Nutzer) erfüllt sind. Genau dies ist die Aufgabe des Requirements Engineerings, auch wenn die IEC 62366-1 auf diesen Aspekt kaum eingeht.
In einer Schulung fragte ein Kunde, welches denn der richtige Begriff für das Prüfen von Benutzerschnittstellen sei. Er sei verwirrt. Das kann man gut nachvollziehen. Ohne das Thema umfassend darstellen zu wollen, hier eine kleine Taxonomie an Begriffen:
Die Prüfung ist sicher der allgemeinste Begriff. Man unterscheidet dann auf der nächsten Ebene die Verifizierung (Prüfung, ob spezifizierte Produkteigenschaften erfüllt sind) und Validierung (Prüfung, ob spezifizierte Nutzer im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele effektiv, effizient und zur Zufriedenstellung erreichen).
Eine Verifizierung kann man automatisiert (Computer) und durch Personen, also durch ein Review durchführen. Dabei wird beispielsweise geprüft, ob spezifizierte Schriftgrößen, Kontrastverhältnisse oder Heuristiken eingehalten sind. Es gibt verschiedene Review-Verfahren unterschiedlichen Formalisierungsgrads wie den Walkthrough oder Inspektionen. Inspektionen gemein ist, dass Sie von Usability-Experten durchgeführt werden.
Die IEC 62366-1 hat nun auch die Begriffe formative und summative Evaluierung eingeführt. Die Norm fordert, dass die Usability des Produkts bereits während der Entwicklung anhand von Prototypen formativ evaluiert werden soll. Schließlich soll in einer summativen Evaluierung mit dem finalen UI-Design der objektive Nachweis erbracht werden, dass das UI von den vorgesehenen Anwendern in der vorgesehen Nutzungsumgebung sicher verwendet werden kann.
Lesen Sie hier mehr zu den Usability-Prüfverfahren:
Das Qualitätsmanagement und Usability Engineering spielen eng zusammen: Während die ISO 13485 allgemeine Konzepte und Anforderungen formuliert, stellt die IEC 62366-1 konkrete Anforderungen im Kontext Usability (Gebrauchstauglichkeit). Dieser Beitrag zeigt das Mapping beider Normen.
| Qualitätsmanagement ISO 13485 |
Usability IEC 62366-1 |
|---|---|
| Kapitel 6.1: Bereitstellung von Ressourcen | 4.3 Anpassen des Usability-Engineering-Aufwands |
| Kapitel 6.2: Personelle Ressourcen | 4.1.1 *Gebrauchstauglichkeitsorientierter Entwicklungs-Prozess |
| Kapitel 7.1: Planung der Produktrealisierung | 4.3 Anpassen des Usability-Engineering-Aufwands |
| Kapitel 7.3.2 Entwicklungsplanung |
5.5 *Auswählen der gefährdungsbezogenen Use Scenarios für die summative Evaluation 5.7 *Erstellen eines Plans für die User Interface Evaluation |
| Kapitel 7.3.3 Entwicklungseingaben |
5.1 *Erstellen der Use Specification 5.2 *Ermitteln von Merkmalen des User Interface in Bezug auf Sicherheit und mögliche 5.3 *Ermitteln bekannter oder vorhersehbarer Gefährdungen und Gefährdungssituationen 5.4 *Ermitteln und Beschreiben gefährdungsbezogener Use Scenarios 5.6 *Erstellen der User Interface Specification |
| Kapitel 7.3.4 Entwicklungsergebnisse | 5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation |
| Kapitel 7.3.5 Entwicklungsbewertung | 5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation |
| Kapitel 7.3.6 Entwicklungsverifizierung |
5.8 *Durchführen des Designs des User Interface, Implementierung und formative 5.9 *Durchführen der summativen Evaluation der Usability des User Interface |
| Kapitel 7.3.7 Entwicklungsvalidierung |
5.8 *Durchführen des Designs des User Interface, Implementierung und formative 5.9 *Durchführen der summativen Evaluation der Usability des User Interface |
Idee: IEC 62366 Normengremium
Diese Gegenüberstellung der Anforderungen aus dem Qualitätsmanagement und Usability Engineering kann Ihnen helfen, Ihre Verfahrensanweisungen ggf. zu konsolidieren, um zu vermeiden, dass Sie mehrere parallele aber eigentlich zusammengehörende Prozesse wie den Entwicklungsprozess und den Usability Engineering Prozess unabhängig voneinander pflegen und befolgen müssen.
Das Ziel dieses Usability FAQs besteht darin, Antworten auf häufige Fragen zu geben,
Wir plädieren dafür, die UI-Spezifikation möglichst zu Beginn von Usability Experten erstellen zu lassen und diese Spezifikation nicht möglichst lange im Unklaren zu lassen und letztlich implizit von Entwicklern erstellen zu lassen.
Die erste Frage in unserem Usability FAQ stellt diesen Ansatz in Frage. Schließlich könnte man zu diesem frühen Zeitpunkt gar nicht wissen, ob man das Spezifizierte später überhaupt umsetzen kann. Dies sei ein „Wasserfall-Denken“, das nur bei kleinen Projekten funktionieren würde.
In der Tat kommt es vor, dass in der UI-Spezifikation etwas festgelegt wird, was man derzeit technisch nicht realisieren kann, sei es weil die Technologie nicht so weit ist oder Ressourcen oder Zeit fehlen.
Das wird und muss dazu führen, dass man nochmals „zurückgehen“ muss und die UI an diese Limitierungen anpasst. Das ist absolut zutreffend. Aber kein Gegenargument!:
Uns sollte auch klar sein, dass auch das beste Usability und Requirements Engineering nicht immer zur perfekten UI-Spezifikationen führt. Aber wir sparen ein Vielfaches der eingesetzten Zeit, wenn wir mit einer 90% korrekten Spezifikation die Entwicklung starten statt mit 50%. Und mit einem frühen UI Prototyp können wir diesen Prozentsatz noch weiter erhöhen.
Ganz unabhängig davon sollte den Kritikern folgendes klar sein:
Produkte ohne eine entwicklungsbegleitende Bewertung der Gebrauchstauglichkeit zu entwickeln, ist nicht nur wenig klug, sondern schlichtweg im Widerspruch zu den Anforderungen der IEC 62366-1:2015 und FDA.
Wir plädieren dafür, die UI-Spezifikation nicht nur möglichst früh im Prozess, sondern möglichst präzise („pixelgenau?“) zu spezifizieren. Das führt zu der Befürchtung, damit einen unnötig hohen Aufwand zu betreiben, sowohl für das initiale Erstellen als auch für das kontinuierliche Anpassen dieser Spezifikation.
Wie präzise sollte eine UI-Spezifikation sein? Was spricht für und gegen eine genaue Spezifikation?
Die IEC 62366-1 lässt Ihnen in der Tat hohe Freiheitsgrade, wie konkret Sie die Anforderungen an die Usability bzw. das UI Ihrer Produkte formulieren. Die IEC 62366-1:2015 fordert aber, dass Sie alle Benutzungsszenarien festgelegt und bewertet haben, ob diese sicherheitsbezogen sind.
Wenn Sie diesen Forderungen nachkommen, wissen Sie bereits
Wenn Sie über alle diese Informationen verfügen, haben Sie das UI bereits sehr präzise spezifiziert.
Spezifizieren Sie die Benutzer-Produkt-Schnittstelle so präzise, dass die verbliebenen Freiheitsgrade es unwahrscheinlich machen, dass ein UI entwickelt wird, das die Erwartungen (Marktanforderungen) und Ansprüche nach Gebrauchstauglichkeit nicht erfüllt.
Solch eine Spezifikation muss keineswegs pixelgenau sein. Mockups bzw. Wireframes, die die ungefähre Position von UI-Elementen festlegen, zusammen mit einem Style-Guide sollten Ihnen die notwendige Genauigkeit Ihrer Spezifikation gewährleisten und helfen, kostenintensive und zeitaufwendige Nachbesserungen zu vermeiden.
Die dritte Frage im Usability-FAQ soll Ihnen als Argumentationshilfe dienen, wenn Vorgesetzte, Kollegen oder Kunden glaube, dass ein systematisches Identifizieren von Anforderungen und konsequentes Ableiten einer Benutzer-Schnittstelle, wie wir es in den Artikeln hier beschreiben, in der Praxis gar nicht funktionieren würde.
Die Verfahren funktionieren unabhängig von der Größe. Das wurde in unzähligen Projekten bewiesen. Vielmehr ist das Gegenteil korrekt:
Während man bei kleinen und weniger komplexen Projekten Fehler leichter beheben kann – und Fehler mit einer geringeren Wahrscheinlichkeit macht – kommt man bei großen Projekten ohne ein systematisches Vorgehen überhaupt nicht mehr aus. Wir Menschen sind mit Umfang und Komplexität der Aufgaben schlichtweg überfordert. Unser Gehirn kann das nicht leisten.
Es kommt noch schlimmer: Viele der großen Projekte sind gar nicht komplex, sondern nur groß. Wir sind nur überfordert und machen etwas Komplexes daraus. Wirklich gute Lösungen zeichnen sich durch eine Einfachheit aus, von der jeder nachher sagt: „Ist ja klar, was soll da so schwierig sein.“ Diese Einfachheit zu erreichen, ist das Ziel und die Fähigkeit guter Methoden bzw. Verfahren.
Fazit: Große Produkte sind nicht notwendigerweise komplex. Ob große Projekte tatsächlich komplex sind, bekommen Sie nur durch systematisches Usability und Requirements Engineering heraus.
Wir haben beispielsweise einst einen Hersteller einer Bestrahlungsplanungssoftware unterstützt, dessen UI vor UI-Elementen wie Parametern, Controls usw. überquoll. Die Algorithmik dahinter entstammte mehrere Doktor- und Habilitationsarbeiten von Mathmatikern, Physikern und Ärzten. Mathematisch war die Sache höchst komplex. Es stellte sich aber heraus, dass die (fast) einzige Nutzungsanforderungen lautete: „Der Nutzer muss am System den zu planenden Patienten auswählen können“. Können Sie sich vorstellen, wie wenig komplex das finale UI war?
Fazit: Die Komplexität „unter der Haube“ hat nichts mit der Komplexität „über der Haube“ zu tun. Den Unterschied bekommen Sie nur durch systematisches Usability und Requirements Engineering heraus.
Kleine und große Projekte/Produkte unterscheiden sich oft primär in der Anzahl der unterstützten Benutzer und der unterstützten Kernaufgabe. Erst die klare Identifizierung der Nutzergruppen und Kernaufgaben hilft Ihnen, gebrauchstaugliche Produkte zu entwickeln.
Viele Firmen haben das aber nicht verstanden und Produkte entwickelt, die alle Kernaufgabe für alle Nutzergruppen (gleichzeitig) unterstützen sollen. Das traurige Paradebeispiel ist SAP. Als Ergebnis hat man gebrauchsuntaugliche und komplexe Produkte.
Fazit: Ein systematisches Usability und Requirements Engineering hilft, die Komplexität zu reduzieren.
Häufig hört man Argumente wie „Bei uns arbeiten viele Personen an dem Produkt mit. Da können nicht einige wenige zu einem frühen Zeitpunkt im Projekt eine Benutzer-Schnittstelle spezifizieren, ohne zu wissen, ob das technisch überhaupt machbar ist.“ Dieser Satz offenbart bereits das Missverständnis:
Die Tatsache, dass so viele Leute mitarbeiten, ist nicht Ursache des Problems sondern die Folge. Gerade weil wir so viele Entwickler haben, möchte man die produktiv halten. Deshalb fangen die an zu entwickeln.
Weil Entwickler aber in ihrer Rolle als Entwickler Entwickler sind und keine Usability bzw. Requirements Engineers, entwickeln sie Produkte, deren Gebrauchstauglichkeit suboptimal ist. Das führt wiederum dazu, dass man häufig nachbessern muss. Und dafür braucht man viele Entwickler.
Die meisten Firmen haben zu viel Entwickler, nicht zu wenige. Das sage ich als Entwickler!
Die IEC 60601-1-8 ist eine Ergänzungsnorm zu der IEC 60601-1, der Norm mit den allgemeinen Festlegungen. Die IEC 60601-1-8 legt Anforderungen an Alarmsysteme sowie an deren Dokumentation und Prüfung fest. Damit gibt sie den Herstellern konkrete Handlungsleitungen bei der Spezifikation und beim Entwurf ihrer Medizinprodukte. Allerdings müssen die Hersteller sicher mit der Vielzahl der Begriffe…
WeiterlesenDas User Centered Design zielt darauf ab, künftige Anwender von Anfang an in die Entwicklung einzubeziehen. So einleuchtend dieser Ansatz klingt, so häufig führt er zu fatalen Fehlentwicklungen. Sie erreichen das Gegenteil dessen, was Sie wollten, nämlich unsichere und gebrauchsuntaugliche Produkte, die gegen regulatorische Vorgaben verstoßen. Doch mit drei Schritten wird es gelingen, das wirkliche…
WeiterlesenHersteller können auf Usability Tests in Zeiten von Corona nicht verzichten. Denn sowohl die IEC 62366-1 als auch die FDA bestehen auf diese Tests. Ausnahmen aufgrund von Corona gibt es keine. Mit dem geeigneten Sicherheitskonzept wird es Ihnen gelingen, gleichzeitig die Sicherheitsanforderungen zu erfüllen und gesetzeskonforme Usability Tests durchzuführen. Damit schaffen Sie die Voraussetzung für…
WeiterlesenAls Marktforschung bezeichnet man das systematische Sammeln und Bewerten von Marktdaten (z.B. Daten von Kunden und den Wettbewerbern) mit dem Ziel, die richtigen Entscheidungen zu treffen: bei der Entwicklung und Änderung von Produkten, bei Marketingmaßnahmen und vielem mehr. Die Marktforschung hilft Unternehmen dabei, Marktchancen zu entdecken, Risiken und Fehlentscheidungen zu vermeiden und regulatorische Anforderungen zu…
WeiterlesenHersteller müssen die Anforderungen der MDR an die Gebrauchstauglichkeit (Usability) für ausnahmslos alle Medizinprodukte nachweisen. Für einige Produkte gelten Übergangsfristen. Doch die Hersteller sind gut beraten, sich gleich mit den Unterschieden zwischen den Anforderungen der MDD und der MDR an die Usability vertraut zu machen. Nur so können Sie die Transition auf die MDR problemlos…
WeiterlesenDie heuristische Evaluation ist ein Verfahren, mit dem Usability-Experten die Gebrauchstauglichkeit von Produkten anhand von Heuristiken (dazu gleich mehr) beurteilen. Dieser Artikel zeigt, wie Sie heuristische Evaluationen nutzen können, um die regulatorischen Anforderungen ans Usability Engineering sehr schnell und kostengünstig zu erfüllen. Er verrät Ihnen auch, weshalb Sie die heuristische Evaluation nicht auf das (Medizin-)Produkt…
WeiterlesenDefinition des Begriffs UOUP (gemäß IEC 62366) Die IEC 62366-1:2015 (die Norm zur „Anwendung der Gebrauchstauglichkeit auf Medizinprodukte“) führt den Begriff UOUP ein und definiert ihn wie folgt: Eine UOUP (User Interface of Unknown Provenance) zu deutsch „Benutzerschnittstelle unbekannter Herkunft“ ist eine Benutzerschnittstelle oder Teile einer Benutzerschnittstelle mit unbekanntem Entwicklungsprozess, für die geeignete Aufzeichnungen eines gebrauchstauglichkeitsorientierten Entwicklungsprozesses gemäß IEC 62366-1 nicht…
WeiterlesenLastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen Die Vorstellungen darüber, was diese Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma. Regelmäßig beobachtet das Johner Institut, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Inhaltsübersicht Allgemeines zu Lasten- und Pflichtenheft » Lastenheft » Pflichtenheft » Der bessere Ansatz »…
WeiterlesenDas V-Modell ist ein Entwicklungsprozessmodell, das ursprünglich für staatliche Projekte entwickelt wurde. Das V-Modell unterscheidet sich vom Wasserfall-Modell dadurch, dass bereits während der konstruktiven Phasen (z.B. während dem Schreiben der Anforderungen oder dem Entwerfen der Architektur) die zugehörigen Tests spezifiziert werden müssen. Inhaltsübersicht Phasen im V-Modell » Verantwortlichkeiten » V-Modell s. agile Entwicklung » Typische Missverständnisse…
Weiterlesen
Viele Firmen verwenden Personas als Methode im Usability und Requirements Engineering. Eine Persona ist eine fiktive Person, die als repräsentativer Vertreter einer Gruppe dient, typischerweise einer Gruppe potenzieller Benutzer eines Systems. Besonders in der agilen Software-Entwicklung sowie bei Marketing- und Design-Agenturen sind Personas beliebt. Doch die Methode wird häufig missverstanden und birgt Risiken, die den meisten…
Weiterlesen