Blog des Johner Instituts:
Wissen zu medizinischer Software

Herzlich Willkommen beim Blog von Christian Johner über alle relevanten Themen zur medizinischen Software. Fast täglich überraschen wir Sie mit neuen Inhalten zu aktuellen Themen aus ISO 14971, IEC 62304, IEC 62366 usw.

Objective Evidence: Objektiver Nachweis im Audit

Montag 30. März 2015 von Christian Johner

“Objective Evidence” bzw. Objektiver Nachweis bei FDA und ISO 9000

Begriffsdefinitionen

Die FDA benutzt den Begriff “objective evidence” definiert im 21 CFR part 820 (den “Quality System Regulations”) bei der Definition von Verifizierung und Validierung. Auf eine Definition von “objective evidence selbst verzichtet die FDA aber leider.

Die ISO 9001 kennt mit dem “objektiven Nachweis” einen ähnlichen Begriff und definiert ihn als “Daten, die die Existenz oder Wahrheit von Etwas bestätigen”” Die Norm ergänzt, dass “objektive Nachweise durch Beobachtung, Messung, Tests oder mit anderen Mitteln erbracht werden können”.

Forderungen nach “Objective Evidence”

Die FDA fordert die Erbringung einer “objective evidence” v.a im Kontext des Design History Files, bei dem verschiedene Verifikations- und Validierungsaktivitäten gefordert sind wie z.B. bei der “Design Validation”. Aber auch die Prozessvalidierung muss durch “objective evidence” erfolgen.

objective evidence

Wie man “Objective Evidence” nachweisen kann

Viele Medizinprodukte-Hersteller sind unsicher, wie granular eine Dokumentation zu erfolgen hat:

  1. Variante: Es gibt eine Testspezifikation, die die Testschritte und erwarteten Ergebnisse beschreibt. Der Tester bewertet die Testergebnisse nur mit “passed” oder “not passed”.
  2. Variante: Der Tester notiert das Ist-Verhalten z.B. mit “wie spezifiziert” oder noch konkreter “die Warnmeldung ‘Ungültige Daten’ erscheint”.
  3. Variante: Die Tests sind so dokumentiert, dass ein beim Test nicht anwesender die Ergebnisse nachvollziehen kann, beispielsweise dokumentiert ein Screenshot, dass tatsächlich die Warnmeldung erscheint.
  4. Variante: Der gesamte Test wird als Video aufgezeichnet, das Video wird Teil der Testdokumentation.

Das Ziel der „objective evidence“ besteht darin, einem Auditor zu ermöglichen, alleine anhand der Dokumente zu überprüfen, ob die Tests (in diesem Fall) erfolgreich waren (oder eben nicht). Wenn jemand schreibt „passed“, dann kann ein Auditor das nicht, ohne den Test wiederholen zu lassen.

Es gibt keine allgemeingültige Antwort auf die Frage, welche der genannten vier Varianten, die “objective evidende” erfüllen. Die Antwort auf die Frage finden Sie am besten, wenn Sie sich fragen: Ist die von mir geplante (möglichst minimale) Dokumentation ausreichend, um die zwingende Beweisführung ohne weitere Informationen zu erlauben. Das kann im ungünstigsten Fall ein Video sein, wenn beispielsweise ein zeitliches Verhalten zu prüfen ist, es kann aber genauso auch eine Test-Log-Datei sein — das Thema 21 CFR part 11 mal außen vorgelassen.

In einem lesenswerten Beitrag zum Thema “objective evidence” schreibt eine ehemalige FDA-Mitarbeiterin, dass auch nicht unbedingt alle Screenshots angefertigt werden müssten. Beispielsweise müsse man kein Screenshot von Login-Dialog anfertigen, wenn dieser zwingend für folgende Schritte notwendig war und diese folgenden Schritten dokumentiert seien. Hier könnte ein “as expected” (ausnahmsweise) sogar genügen.

Kategorie: FDA, Regulatory Affairs
Keine Kommentare »

Verifizierung und Validierung: Unterschied & Definitionen

Freitag 27. März 2015 von Christian Johner

Wie unterscheiden sich die Verifizierung und Validierung und wie sind diese Begriffe definiert?

Update: Die Notwendigkeit der Verifizierung von Software hängt von deren Sicherheitsklasse ab. Doch Vorsicht: Auch bei Klasse A kann eine Verifizierung notwendig werden! Lesen Sie mehr»

Verifizierung (Definition und Beispiele)

Verifizierung von Medizinprodukten (allgemein)

Definition: Die Verifizierung ist eine Prüfung mit objektiven Mitteln, dass spezifizierte (Produkt-)Eigenschaften erfüllst sind. Diese (Produkt-)Eigenschaften oder Merkmale finden sich beispielsweise in einer System Requirements Specification (SRS).

Beispiele für spezifizierte Merkmale sind die Gestaltung der Benutzerschnittstelle (siehe auch Verifizierung der Gebrauchstauglichkeit), das Verhalten des Systems auf Aktionen über dessen technische oder Datenschnittstellen oder am Anwendungsteil. So könnte spezifiziert sein, dass an einem Defibrilator eine gewissen Spannung in einer bestimmten Pulsfolge anliegen muss. Die Verifizierung wäre dann die Prüfung, ob diese Spannung in der spezifizierten Pulsfolge tatsächlich anliegt.

Verifizierung der Gebrauchstauglichkeit

Definition: Die Verifizierung der Gebrauchstauglichkeit ist der objektive Nachweis, dass spezifizierte Produktmerkmale mit Bezug auf die Gebrauchstauglichkeit erfüllt sind. Sie ist also eine Untermenge der Verifizierung und wird von der IEC 62366 gefordert.

Beispiele für spezifizierte Produktmerkmale sind Schriftgrößen, Farben, Kontrastverhältnisse oder allgemeine Regeln wie das Markieren von Pflichtfeldern als solche sein. Diese Prüfung (Verifizierung) erfolgt üblicherweise in Form einer Inspektion durch einen Experten. Man prüft entweder gegen spezifizierte Produktmerkmale oder gegen allgemeine Regeln, wie sie beispielsweise die ISO 9241-Familie sehr umfassend beschreibt.

Möchten Sie mehr über die Verfahren zur Verifizierung und Validierung der Gebrauchstauglichkeit erfahren? Dann empfehlen wir Ihnen das Usability & Requirements Seminar von Thomas Geis. Und hier finden Sie einen Überblick unserer Medizintechnik- und Medizinsoftware-Seminare.

 Validierung (Definition und Beispiele)

Die Validierung hingegen ist der objektive Nachweis, dass ein spezifizierter Nutzer im spezifizierten Nutzungskontext seine spezifizierten Nutzungsziele erreichen kann.  Diese Prüfung hat zwei Aspekte, nämlich

  1. “Klassische Validierung”: Die Prüfung, ob man überhaupt das Nutzungsziel mit dem Medizinprodukt erreichen kann. Die Nutzungsziele finden sich in der Zweckbestimmung beschrieben.
  2. Validierung der Gebrauchstauglichkeit: Die Prüfung, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext, die Nutzungsziele (Zweckbestimmung) erreichen können.

Lesen Sie hier mehr zur Validierung von Medizinprodukten.

Ergebnisse der Verifizierung und  Validierung können unabhängig sein

Es ist durchaus denkbar, dass die Verifizierung des Medizinprodukts erfolgreich ist und die Validierung nicht und umgekehrt, wie folgende Beispiele zeigen:

  • Am Defibrillator liegen die spezifizierten 3000 Volt an den Pads an (Verifizierung erfolgreich). Das Herz des Patienten schlägt (Zweckbestimmung) aber nach Anwendung des Produkts nicht (Validierung gescheitert).
  • Am Defibrillator liegen statt der spezifizierten 3000 Volt an den Pads nur 2000 V an (Verifizierung gescheitert). Das Herz des Patienten schlägt (Zweckbestimmung) aber nach Anwendung des Produkts dennoch (Validierung erfolgreich).

Weitere Informationen zur V&V von Software / Medizinprodukten

Wenn Sie Fragen haben, dann schreiben Sie mir. Ich antworte gerne und kostenlos.

Alternativ (oder zusätzlich) empfiehlt sich der Auditgarant. In über zahlreichen Videotrainings beschreibt er genau, wie Sie die Anforderungen an Ihre Medizinprodukte erheben, spezifizieren und im Rahmen der Verifizierung und Validierung prüfen. Den Premium-Mitgliedern stehen zudem Checklisten und Templates zur Verfügung z.B. für einen Validierungsplan und die Dokumentation der Validierungsergebnisse.

Videotrainings zur Verifizierung und Validierung ansehen

Verifizizierung und Validierung: Besonderheiten von stand-alone Software

Regulatorische Anforderungen an die Entwicklung von Medizinprodukten

Die Richtlinien für Medizinprodukte, speziell die “Medical Device Directive” (93/42/EWG) und die “Active Implantable Device Directive” sind sich einig: Zu den grundlegenden Anforderungen eines Medizinproduktes zählt:

“Bei Geräten, die Software enthalten oder bei denen es sich um medizinische Software an sich handelt, muss die Software entsprechend dem Stand der Technik validiert werden, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements, der Validierung und Verifizierung zu berücksichtigen sind.”
Ergänzung durch die 2007/47/EC

Und wie lassen Sie nun Ihren Auditor vermuten, dass Sie Ihre Software nach dem Stand der Technik validiert haben? Normalerweise würden Sie eine Norm einhalten. Für die Software-Verifizierung ist die IEC 62304 anzuwenden, für die Software-Validierung gibt es aber keine spezifische Norm.

93-42-EWG-2007-47-EWG

 

Das übliche Blackbox-Testen ist meistens eine Verifizierungs- und keine Validierungsaktivität!

Verifizierung von Software-Anforderungen bei Sicherheitsklasse A

Laut IEC 62304 entscheidet die Software-Sicherheitsklasse über die Notwendigkeit von Software-Systemtests, die bei einer Verifizierung der Software entsprechen. Bei Sicherheitsklasse A sind keine Tests vorgeschrieben, keine Unit-, keine Integrations-, keine Systemtests. Also keine Verifizierung.

Laut ISO 14971 müssen Sie hingegen alle Maßnahmen, die zur Risikokontrolle beitragen, verifizieren. Wenn Sie also Maßnahmen in Software implementieren, müssen Sie diese unabhängig von der Sicherheitsklasse einer Verifizierung unterziehen!

Validierung und Verifizierung von Medical Apps

Zu meinem Beitrag zu den Mobile Medical Apps stellte man die folgende wichtige Frage:

Für mich bleibt dabei eine wesentliche Frage offen, die Apps von anderer Software unterscheidet: Wie muss ich die Plattform in den Prozess der Verifizierung und Validierung einbeziehen? Sprich, reicht es dass ich es auf einem System mit Android x.y teste, und dann kann ich es für alle Produkte mit dieser Version in Verkehr bringen? Oder muss ich unterschiedliche Hardware testen – die z.B. die von der App verwendete Bluetooth-Schnittstelle anders ansprechen? Was ist, wenn es ein Sicherheitsupdate der Android-Version gibt? Was ist, wenn andere Apps installiert werden, die auch dieselben Hardware-Schnittstellen nutzen möchten? Muss ich die alle testen?

Genau genommen sind das gleich mehrere Fragen. Lassen Sie uns diese einzelne adressieren:

1. Wie vollständig muss man Mobile Medical Apps verifizieren?

Die Verifizierung ist die Überprüfung, das spezifizierte Produkteigenschaften erfüllt sind – hier konkret die Software-Anforderungen. Zu diesen Software-Anforderungen zählt auch eine Beschreibung der Laufzeitumgebung, zu der die oben genannte Plattform zählt. Schauen Sie sich bitte im Institutsclub die Videotrainings zu den Software Requirements Specifications an, wenn Sie mehr darüber erfahren möchten.

Die Plattform umfasst Aspekte wie die Hardware einschließlich Bildschirmgrößen und Bildschirmauflösungen sowie das Betriebssystem, hier bestimmte Android-Versionen, ebenso wie die Verfügbarkeit und Korrektheit von Datenschnittstellen wie Bluetooth.

Ebenfalls ein Aspekt ist die “Verifizierung der Gebrauchstauglichkeit”, bei der der Hersteller gegen die “Spezifikation der Gebrauchstauglichkeit” prüft, die wiederum eigene Forderungen enthält oder/und auf Normen wie die ISO 9241-Familie verweist.

Eine vollständige Verifizierung ist wie alle Prüfungen in der Regel ausgeschlossen. D.h. alle „Tests“ werden nur Stichprobenprüfungen sein. Nun stellt sich die Frage, wie umfangreich diese Stichproben sein müssen. Die Antwort darauf kann sich nur im Risikomanagement finden. Nur dort können Sie abschätzen, welche Risiken sich dadurch ergeben könnten, dass die Plattform sich anders verhält, als Sie das vermuten.

2. Wie sind Mobile Medical Apps zu validieren?

Die Antwort mit dem Risikomanagement passt auch für diese Frage. Wir können aber noch spezifischer werden: Bei der Validierung geht es um einen Nachweis, dass spezifizierte Nutzer im spezifizierten Nutzungskontext ihre spezifizierten Nutzungsziele erreichen. Wie könnte dieses Ausmaß von der Plattform abhängen: Eine entscheidende Rolle spielt sicher die Größe und Auflösung der Bildschirme. Die anderen Faktoren sollten konstant sein bzw. über die Verifizierung bereits geprüft und beherrscht sein.

3. Wie geht man damit um, dass es noch andere Apps gibt?

Spätestens jetzt wird Sie die Kombinatorik überfordern: Das Zusammenspiel aller möglichen Apps werden Sie niemals testen können. Auch hier müssen Sie das Risikomanagement zur Hilfe ziehen: Wenn (inakzeptable) Risiken dadurch entstehen, dass andere Apps Schnittstellen belegen (oder die Plattform in anderer Weise beeinträchtigen), müssen Sie den üblichen von der MDD vorgeschriebenen „Dreisprung“ wählen:

  1. Inhärente Sicherheit anstreben (z.B. Funktionen nicht zu nutzen, Funktionalitäten nicht anzubieten, andere Plattform wählen usw.)
  2. Schutzmaßnahmen wählen: Beispielsweise könnte man in der Software erst prüfen, ob Schnittstellen nach außen funktionieren (z.B. über einen „Webservice-Ping“, wenn über einen Webservice Daten geladen bzw. verschickt würden)
  3. Nutzer über Risiken informieren.

Auch hier ist Testen kein Instrument, um die Korrektheit der Mobile Medical App nachzuweisen.

Wir haben Ihnen eine Präsentation vorbereitet, die Ihnen einen Überblick verschafft, wie Sie Schritt für Schritt Ihre Mobile Medical App zum CE-Zeichen bringen.

Auch die IEC 60601-1 verwechselt Verifizierung und Validierung

Wenn man in einer Schulung über Softwareentwicklung etwas gelehrt bekommt, ist es das V-Modell. Immer und immer wieder. Es ist auch ein wunderbares Modell, um vieles zu erklären.

Doch wie versteht die IEC 60601-1 dieses V-Modell?

Verwechslung Verifizierung und Validierung

Quelle: IEC 60601-1 bzw. IEC 62304.

Laut dieser Norm (siehe Abbildung) werden aus Anwenderbedürfnissen Anforderungen an ein programmierbares elektrisches medizinisches System, kurz PEMS, abgeleitet. Also Systemanforderungen.

Das erste, was man sich fragen muss, was die Norm unter Anwenderbedürfnissen versteht. Es handelt sich um einen nicht definierten Begriff. Wahrscheinlich verstehen die Autoren darunter ein nicht näher verstandenes Mischmasch aus Erfordernissen, Wünschen, Nutzungsanforderungen und direkt formulierten Systemanforderungen. Wer so unpräzise mit den Begrifflichkeiten umgeht, wird nachher auch unpräzise Ergebnisse erzielen.

Wohin diese mangelnde Präzision führt, erkennen Sie selbst: Die Norm glaubt die Erfüllung von PEMS-Anforderungen, also Systemanforderungen, validieren zu können.

Systemanforderungen kann man (im Systemtest) verifizieren, aber nicht validieren.

Validieren kann man definitionsgemäß hingegen Nutzungsanforderungen. Doch die tauchen wie eben diskutiert überhaupt nicht in dem Bild auf, sondern gehen im Nebel der Anwenderbedürfnisse unter.

Noch mehr Informationen zur Verifizierung und Validierung von Software/Medizinprodukten

Ihre nächsten Schritte

Nehmen Sie Kontakt mit uns auf!

Kategorie: Software & IEC 62304, Systementwicklung, Usability & IEC 62366
Tags: , , ,
4 Kommentare »

Kommunikationsserver: Aufgaben und Regularien

Donnerstag 26. März 2015 von Christian Johner

Dieser Beitrag konzentriert sich auf Kommunikationsserver im Krankenhaus bzw. im Gesundheitswesen, beschreibt deren Aufgaben und die regulatorischen Anforderungen, die Hersteller und Betreiber (z.B. Krankenhäuser) erfüllen müssen.

Kommunikationsserver: Zu was sie dienen

Die Kommunikationsserver dienen der Vermittlung von Daten zwischen zwei Endpunkten wie IT-Systemen oder Medizinprodukte. Dazu müssen sie folgende Aufgaben erfüllen:

  • Zwischen verschiedene Integrationsebenen, Protokollen, Formaten und Standards konvertieren
  • Zeitliche und logische Abläufe steuern
  • Ggf. Daten beim Ausfall von Systemen puffern

Konvertierung

Die Konvertierung von Daten kann auf allen Interoperabilitätsebenen notwendig sein.

Kommunikationsserver müssen verschiedene Systeme auf gleicher oder verschiedenen Interoperabilitätsebenen verbinden

Beispielsweise kann es sein, dass ein Kommunikationsserver Daten von einem System aus dem Dateisystem ausließt und per Webservice an ein anderes System übergibt. Oder ein Kommunikationsserver verbindet sich mit einem Bus-System eines Medizinprodukts und per HL7 über TCP/IP (MLLP) an ein PDMS übergibt. Auch die Konvertierung von HL7 Nachrichten in verschiedenen Versionen können zum Aufgabenspektrum eines Kommunikationsservers zählen.

Ablaufsteuerung

Mit Kommunikationsservern wie Orchestra von Soffico können Administratoren Abläufe steuern, Bedingungen und Schleifen visuell (mit BPMN) beschreiben und so die Ablauflogik in einem Krankenhaus modellieren und realisieren. Beispielsweise kann so ein Kommunikationsserver nach der Aufnahme von Patienten in einem KIS abhängig von Bedingungen einzelne Subsysteme mit den Patientendaten versorgen oder bei unvollständigen Daten eine Person per E-Mail informieren.

Regulatorischen Anforderungen an Kommunikationsserver

In Europa sind Kommunikationsserver, die grundsätzlich nur der Weiterleitung von Daten dienen, gleich ob das medizinische sind oder nicht, ob diese kritisch sind oder nicht, in der Regel keine Medizinprodukte. Denn ihre Zweckbestimmung dient der Weiterleitung von Daten, nicht der Diagnose, Therapie oder Überwachung von Krankheiten, Verletzungen oder physiologischer Vorgänge.

Das bedeutet, dass ein Kommunikationsserver wie ein Orchestra nicht unter das Medizinproduktegesetz fallen, solange keine (kritischen) Monitoring-Alarme (z.B. einer Intensivstation) damit weitergeleitet werden sollen.

PACS

Auch ein PACS-Server würde nicht als Medizinprodukt klassifiziert werden, wenn seine Aufgabe auf die “Communication” beschränkt wäre. Aber PACS dienen eben auch der Archivierung von Bildern, die der Verlaufskontrolle dienen. D.h. solange die Bilder nur archiviert aber nicht weiter für die Diagnose oder Therapie verwendet würden (z.B. nur für die Abrechnungsdokumentation), müsste solch ein Kommunikationsserver /PACS-Server nicht als Medizinprodukt in Verkehr gebracht werden.

Regulatorische Anforderungen an Kommunikationsserver in Europa versus USA

Sobald ein Kommunikationsserver als Medizinprodukt klassifiziert wird, unterliegen sowohl die Hersteller als auch die Betreiber den gesetzlichen Auflagen (MPG/MDD, MPBetreibV usw.).

In USA fallen Kommunikationsserver meist in die Klasse der Medical Device Data Systems MDDS. Lesen Sie darüber hier mehr.

Meinung eines Gewerbeaufsichtsamts zu einem Produkt, das der Weiterleitung von Daten dient

Einer unserer Kunden wollte ein Produkt als Medizinprodukt klassifizieren und bekam vom Gewebeaufsichtsamt folgende Stellungnahme:

Das Ergebnis der Plausibilitätsprüfung Ihrer DIMDI – Anzeige und den dazugehörigen übersendeten Unterlagen ist, dass es sich um kein Medizinprodukt handelt. Aus den übersendeten Unterlagen zur Einklassifizierung geht hervor, dass Sie das o. g. Produkt nach Regel 12 des Anhangs IX der Medizinprodukterichtlinie 93/42/EWG in Übereinstimmung mit Meddev 2.1.6 als Software eingestuft haben. Jedoch erfüllt das Produkt nicht die Definition eines Medizinproduktes nach § 3 Nr. 1 Medizinproduktegesetz (MPG). Die Software erfüllt keinerlei therapeutischen oder diagnostischen Zweck. Es wird bei einer Software nach MPG vorausgesetzt, dass die Leistung der Software über Speicherung, Archivierung, Datenkomprimierung, Suchfunktionen oder Kommunikation hinausgeht. Dies ist nicht der Fall. Auch eine Einstufung als Zubehör  für Medizinprodukte nach § 3 Nr. 9 MPG kommt nach derzeitigen Kenntnisstand nicht in Betracht. Ein Zubehör wird nicht allein dadurch zum Medizinprodukt, dass es ein Hersteller als Zubehör für ein Medizinprodukt deklariert. Voraussetzung hierzu ist, dass der Hersteller dem Zubehör eine Zweckbestimmung zuordnet, aus der deutlich hervorgeht, dass das Zubehör zum Betrieb eines Medizinproduktes erforderlich ist oder dessen Funktion unterstützt wird, damit das Medizinprodukt angewendet werden kann.

Kategorie: Regulatory Affairs
Keine Kommentare »

MDDS: Medical Device Data Systems

Mittwoch 25. März 2015 von Christian Johner

Zum 09. Februar 2105 hat die FDA den Entwurf zu den Medical Device Data Systems MDDS in ein finales Dokument überführt. Dieser Beitrag beschreibt, was ein MDDS ist und welche regulatorischen Anforderungen Sie diesbezüglich erfüllen müssen.

Medical Device Data Systems MDDS

Medical Device Data Systems (MDDS)

Definition

Die FDA definiert Medical Device Data Systems (MDDS) wie folgt

A medical device data system (MDDS) is a device that is intended to provide one or more of the following uses, without controlling or altering the functions or parameters of any connected medical devices:

  1. The electronic transfer of medical device data;
  2. The electronic storage of medical device data;
  3. The electronic conversion of medical device data from one format to another format in accordance with a preset specification; or
  4. The electronic display of medical device data.

An MDDS may include software, electronic or electrical hardware such as a physical communications medium (including wireless hardware), modems, interfaces, and a communications protocol. This identification does not include devices intended to be used in connection with active patient monitoring.

Beispiele

Als Beispiele nennt die FDA Software, die

  • Patientendaten wie beispielsweise Vitalparameter für eine spätere Begutachtung speichert
  • digitale Daten eines Pulsoximeters in ein druckbares Format wandelt
  • ein bereits gespeichertes Elektrokardiogramm eines bestimmten Patienten anzeigt.

Die FDA stellt klar, dass Alarmsystem, die zeitkritische Monitoring-Alarme übertragen (auch wenn die Daten unverändert bleiben), nicht unter die Definition von Medical Device Data Systems fallen.

Regulatorische Anforderungen

Klassifizierung Medical Device Data Systems (MDDS)

Im Februar 2011 änderte die FDA bereits die Klassifizierung dieser Gerät von Klasse III auf Klasse I. Für Klasse I Produkte muss man nur die „General Control“ wie Registrierung und „Labeling“ aber nicht die „Special Controls“ einhalten muss, die Performanz-Standards oder eine Marktüberwachung verlangen.

Enforcement Discretion

Nun geht die FDA noch einen Schritt weiter und schreibt im Guidance Document Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices“, dass sie die Einhaltung der Regularien – also die General Controls – nicht mehr erzwingen würde. Das gleiche gälte auch für Geräte zur Speicherung und Kommunikation von medizinischen Bilddaten (gemeint sind wohl PACS).

In anderen Worten: Die FDA fühlt sich für MDDS und PACS nichtmehr zuständig. Und wenn man gerade dabei ist:

FDA does not intend to enforce compliance with regulatory controls for a MDDS that is an in vitro device that is intended for assessing the risk of cardiovascular diseases (21 CFR 880.9(c)(4)) or for use in diabetes management (21 CFR 880.9(c)(5)).

MDDS in Europa

In die Klasse der MDDS fallen i.d.R. auch sogenannte Kommunikationsserver. Lesen Sie dazu mehr hier.

Kategorie: FDA, Software & IEC 62304
Tags:
2 Kommentare »

Risikomanagement im Krankenhaus und bei anderen Betreibern

Dienstag 24. März 2015 von Armin Gärtner

Es gibt zahlreiche regulatorische Vorgaben an das Risikomanagement im Krankenhaus bzw. für Betreiber. Dieser Artikel verschafft Ihnen einen Überblick über die gesetzlichen Grundlagen im Kontext von Medizinprodukten und IT.  Diese Fragestellung ergibt sich auch im Zusammenhang mit der Diskussion über die Anwendung der Risikomanagement-Norm DIN EN 80001-1.

Risikomanagement im Krankenhaus

Überblick über die gesetzlichen Grundlagen zum Risikomanagement

Es bestehen zwei gesetzliche Grundlagen zum Risikomanagement im Krankenhaus bzw. bei anderen Anbieter im Gesundheitswesen:

  1. Patientenrechtegesetz 2013 in allgemeiner Form
  2. Medizinproduktegesetz speziell mit der Medizinprodukte-Betreiberverordnung beim Anschluss von Medizinprodukten an andere Gegenstände (IT-Netzwerk)

Beide gesetzlichen Grundlagen stellen wir Ihnen nachfolgend kurz vor.

1. Patientenrechtegesetz

Das Gesetz zur Verbesserung der Rechte von Patientinnen und Patienten vom 20. Februar 2013 verpflichtet Krankenhäuser [allgemein], Risikomanagement- und Fehlermeldesysteme einzuführen [Quelle 1]. 

Patientenrechtegesetz, Artikel 2

Änderung des Fünften Buches SozialgesetzbuchNach § 137 Absatz 1c wird folgender Absatz 1d eingefügt:

„(1d) Der Gemeinsame Bundesausschuss bestimmt in seinen Richtlinien über die grundsätzlichen Anforderungen an ein einrichtungsinternes Qualitätsmanagement nach Absatz 1 Nummer 1 erstmalig bis zum 26. Februar 2014 wesentliche Maßnahmen zur Verbesserung der Patientensicherheit und legt insbesondere Mindeststandards für Risikomanagement- und Fehlermeldesysteme fest.

Über die Umsetzung von Risikomanagement- und Fehlermeldesystemen in Krankenhäusern ist in den Qualitätsberichten nach Absatz 3 Nummer 4 zu informieren.

Als Grundlage für die Vereinbarung von Vergütungszuschlägen nach § 17b Absatz 1 Satz 5 des Krankenhausfinanzierungsgesetzes bestimmt der Gemeinsame Bundesausschuss Anforderungen an einrichtungsübergreifende Fehlermeldesysteme, die in besonderem Maße geeignet erscheinen, Risiken und Fehlerquellen in der stationären Versorgung zu erkennen, auszuwerten und zur Vermeidung unerwünschter Ereignisse beizutragen.“

Der Gemeinsame Bundesausschuss (G-BA)

Der Gemeinsame Bundesausschuss (G-BA) ist das oberste Beschlussgremium der gemeinsamen Selbstverwaltung der Ärzte, Zahnärzte, Psychotherapeuten, Krankenhäuser und Krankenkassen in Deutschland [Quelle 5]. Er bestimmt in Form von Richtlinien den Leistungskatalog der gesetzlichen Krankenversicherung (GKV) für mehr als 70 Millionen Versicherte und legt damit fest, welche Leistungen der medizinischen Versorgung von der GKV erstattet werden. Darüber hinaus beschließt der G-BA Maßnahmen der Qualitätssicherung für den ambulanten und stationären Bereich des Gesundheitswesens.

Leitfaden des G-BAs zum Risikomanagement im Krankenhaus

Der G-BA hat am 23.01.2014 eine Leitlinie über klinisches Risikomanagement veröffentlicht. Aus der Presseveröffentlichung des G-BA wird dazu auszugsweise zitiert [Quelle 2]:

Risikomanagement- und Fehlermeldesysteme zur Verbesserung der Patientensicherheit in Klinik und Praxis 

Berlin, 23. Januar 2014 – In vertragsärztlichen und vertragszahnärztlichen Praxen sowie in Krankenhäusern gelten künftig neue Vorgaben zum Aufbau von Risikomanagement- und Fehlermeldesystemen. Dies hat der Gemeinsame Bundesausschuss (G-BA) am Donnerstag in Berlin beschlossen und erfüllt damit fristgerecht einen Auftrag aus dem im Februar 2013 in Kraft getretenen Patientenrechtegesetz. Dieses sieht unter anderem vor, dass der G-BA Mindeststandards für Risikomanagement- und Fehlermeldesysteme in der medizinischen Versorgung GKV-Versicherter festlegt. 

So hat der G-BA in den Qualitätsmanagement-Richtlinien zur vertragsärztlichen, vertragszahnärztlichen sowie stationären Versorgung nach umfassender Einbeziehung von Experten für das Risikomanagement beispielsweise das Erfordernis einer Risikoanalyse, -bewertung, -bewältigung und -überwachung sowie Schulungen der Beteiligten als Mindeststandards vorgegeben. Für Fehlermeldesysteme soll gelten, dass diese für Mitarbeiter in Praxen und Kliniken niederschwellig zugänglich sind und Meldungen freiwillig, anonym und sanktionsfrei erfolgen können und dass daraus entsprechende Verbesserungen resultieren.

Der Leitfaden verpflichtet die Krankenhäuser, wesentliche Maßnahmen zur Weiterentwicklung der Patientensicherheit ein- und durchzuführen.

§2 der Richtlinie des G-BA führt aus, dass durch die Identifikation relevanter Abläufe, deren systematische Darlegung und dadurch hergestellte Transparenz Risiken erkannt und Probleme vermieden werden sollen. Risikomanagement im Sinne des Patientenrechtegesetzes und des Leitfadens kann z. B. folgende Themen umfassen:

  • Hygiene
  • Einheitliche Ausstattungsstandards in der Medizintechnik zur Reduzierung von Bedienungsfehlern und Verbesserung der Patientensicherheit
  • u.a.

Zusammenspiel von Patientenrechtegesetz und G-BA-Leitfaden beim Risikomanagement im Krankenhaus

Das Patientenrechtegesetz spricht über den G-BA-Leitfaden nur eine allgemeine Verpflichtung aus und betrachtet Medizintechnik bzw. Medizinprodukte nicht weiter.

Dafür stellt das Medizinproduktegesetz die gesetzliche Basis dar, über die Betreiberverordnung Krankenhäuser und andere Anbieter im Gesundheitswesen zum Risikomanagement zu verpflichten, wenn sie Medizinprodukte vernetzten bzw. in ein IT-Netzwerk integrieren.

2. Medizinproduktegesetz (MPG) und MPBetreibV

Gesetzlicher Rahmen

Das Medizinproduktegesetz (MPG) [Quelle 3] richtet sich weitgehend an Hersteller von Medizinprodukten. Es enthält allerdings mit § 14 die gesetzliche Grundlage für die Medizinprodukte-Betreiberverordnung (MPBetreibV), die das Errichten, Betreiben, Anwenden und Instandhalten von Medizinprodukten regelt und sich somit an die Betreiber richtet. [Quelle 4]

In der MPBetreibV findet sich der Paragraf 2 (Allgemeine Anforderungen) Abs. 3.

(3) 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 dazu unter Berücksichtigung der Zweckbestimmung und der Sicherheit der Patienten, Anwender, Beschäftigten oder Dritten geeignet sind.

Anforderungen an das Risikomanagement im Krankenhaus

Dieser Paragraf der Verordnung enthält zwei wesentliche Anforderungen an Betreiber, die Medizinprodukte nicht nur mit weiteren Medizinprodukten sondern auch mit anderen Gegenständen wie einem IT-Netzwerk kombinieren:

  • Die Anbindung, Kombination bzw. Integration darf nur im Rahmen der Zweckbestimmung des Herstellers des Medizinproduktes erfolgen.
  • Die Anbindung, Kombination bzw. Integration darf nur erfolgen, wenn nachgewiesen wird, dass diese für die Sicherheit von Patienten, Anwendern und Dritten geeignet ist.

Die Forderung, die Eignung einer Kombination für die Sicherheit von Patient, Anwender und Dritten nachzuweisen, läßt sich nur durch eine entsprechende Dokumentation über das Risikomanagement im Krankenhaus führen.

Vernetzt also ein Betreiber wie ein Krankenhaus ein Medizinprodukt wie ein bildgebendes Ultraschallgerät mit dem IT-Netzwerk, um Daten darüber zu senden und auszutauschen, muss das Krankenhaus nachweisen, wie § 2 Abs. 3 der MPBetreibV erfüllt wird.

Bei der Integration eines Ultraschallgerätes in das IT-Netzwerk kann man die DIN EN 80001-1:2011 heranziehen, um über das in dieser Norm beschriebene Risikomanagement im Krankenhaus den Nachweis zu führen, dass diese Vernetzung sicher ist für Patient, Anwender und Dritte.

Zusammenfassung

Der Gesetzgeber hat eindeutige rechtliche Anforderungen an ein Risikomanagement im Krankenhaus bzw. für Betreiber von Krankenhäusern im Patientenrechtegesetz und in der MPBetreibV auf Basis des Medizinproduktegesetzes (MPG) formuliert. Es ist davon auszugehen, dass das geplante IT-Sicherheitsgesetz bezüglich Risikomanagement auch im Krankenhaus eine weitere gesetzliche Grundlage für Risikomanagement im Krankenhaus darstellen wird.

Literatur und Quellenangaben

  1. Patientenrechtegesetz http://www.bundesaerztekammer.de/downloads/Patientenrechtegesetz_BGBl.pdf letzter Zugriff 16.02.2015
  2. Leitfaden G-BA https://www.g-ba.de/institution/presse/pressemitteilungen/516/ letzter Zugriff 16.02.2015
  3. http://www.gesetze-im-internet.de/bundesrecht/mpg/gesamt.pdf letzter Zugriff 16.02.2015
  4. http://www.gesetze-im-internet.de/bundesrecht/mpbetreibv/gesamt.pdf letzter Zugriff 16.02.2015

Kategorie: Health IT & Medizintechnik, Risikomgt. & ISO 14971
Tags: ,
Keine Kommentare »

Unangekündigte Audits durch benannte Stellen

Freitag 20. März 2015 von Christian Johner

Unangekündigte Audits sind stichprobenhafte Prüfungen von Qualitätsmanagement-systemen durch benannte Stellen mit dem Ziel,

  • herauszufinden, ob Medizinproduktehersteller konform mit ihrem QM-System (z.B. gemäß ISO 13485) arbeiten,
  • Abweichungen schnell zu identifizieren und darauf reagieren zu können und
  • Betrugsversuche zuverlässiger aufdecken zu können.

Inzwischen liegen erste Erfahrungen mit unangekündigten Audits vor.

Unangekündigte Audits

Historie der unangekündigten Audits

Die unangekündigten Audits sind eine Folge des Brustimplantate-Skandals, nachdem die Forderung laut wurde, Medizinproduktehersteller nicht nur im Rahmen der ISO 13485 zu überprüfen, sondern auch unangekündigt und stichprobenhaft, um sicher zu stellen, dass die Vorgaben der QM-System im Arbeitsalltag wirklich erfüllt werden.

So wenig sich die Hardliner bei der Novellierung der Medizinprodukterichtlinie oder künftig Medizinprodukteverordnung durchsetzen konnten, mit einigen Verschärfungen scheint es die EU nun doch erst zu meinen. Die benannten Stellen sind inzwischen zu diesen unangekündigten Audits verpflichtet und führen diese auch durch. Sie sind bei den Auditoren selbst fast so unbeliebt wie den Auditierten, also den Herstellern.

Durchführung von unangekündigten Audits

Was bei unangekündigten Audits geprüft wird

Eine Verschärfung gilt den ungeplanten Audits durch benannte Stellen. Die EU hat eine Empfehlung veröffentlicht, wie diese Audits durchzuführen sind. Beispielsweise soll geprüft werden:

  1. Gibt es eine präzise Zweckbestimmung?
  2. Ist das Produkt richtig klassifiziert?
  3. Sind die grundlegenden Anforderungen erfüllt?
  4. Sind die Gefahren [Anm.: sind Gefährdungen gemeint?] ermittelt?
  5. Sind Risiken so weit wie möglich minimiert?
  6. Gibt es ein als akzeptabel bewertetes Risiko-Nutzen-Verhältnis?

In einem Interview mit DeviceMed berichtet ein Vertreter einer benannten Stelle, dass sie bei unangekündigten Audits besonders darauf achten würden, ob die Dokumentation aktuell sei und ob die Produkte tatsächlich den Kriterien entsprächen. Der erste Punkt betrifft etwas stärker die Entwicklung, der zweite etwas mehr die Produktion.

Diese Schwerpunktsetzung ist nachvollziehbar: Schließlich will man sicherstellen, dass Medizinproduktehersteller nicht in Vorbereitung auf reguläre Audits alles in Ordnung bringen und dazwischen die Vorgaben des eigenen QM-Systems nicht beachten oder sogar vorsätzlich dagegen verstoßen. Bei einem angekündigten Audit hat der Hersteller keine Chance mehr, beispielsweise

  • veraltete oder fehlende Entwicklungsdokumente zu aktualisieren zu verbessern
  • fehlende Produktprüfungen zu kaschieren
  • Aufzeichnungen von Produktprüfungen zu fälschen.

Wie oft unangekündigte Audits stattfinden

Mir hat ein Vertreter einer benannten Stelle verraten, nach welchen Kriterien sie die Hersteller auswählen bzw. die Frequenz bestimmen, mit denen sie einzelne Hersteller auditieren. Es sind drei Parameter:

  1. Das Risiko, das von den Produkten auftritt. Dabei orientiert sich die benannte Stelle v.a. an der Klassifizierung gemäß MDD (I, IIa, IIb, III).
  2. Die Probleme, die es mit dem Produkt oder der Produktklasse, in den letzten Jahren gab. Dabei ist es unerheblich, ob die Informationen von den Herstellern selbst oder aus anderen Quellen wie den BfArM-Berichten stammen.
  3. Das Maß, in dem sich Hersteller verdächtig machen, insbesondere bei einem Audit. Auditoren haben ein gutes Gefühl dafür, ob Hersteller mit offenen Karten spielen. Sie merken, auch wenn sie es nicht immer nachweisen können, ob das QM-System gelebt wird oder nur Potemkin’sche Dörfer sind.

Konkreter sind die Forderungen der EU: Die benannten Stellen sollten mindestens einmal alle drei Jahre unangekündigte Audits durchführen. Sie sollten die Häufigkeit der unangekündigten Audits erhöhen, wenn die Produkte ein erhebliches Risiko bergen, wenn die Produkte der fraglichen Art häufig nicht konform sind oder wenn bestimmte Informationen vermuten lassen, dass eine Nichtkonformität der Produkte oder des Herstellers vorliegt. Der Zeitplan der unangekündigten Audits sollte unvorhersehbar sein. Grundsätzlich sollte ein unangekündigtes Audit nicht weniger als einen Tag dauern und von mindestens zwei Prüfern durchgeführt werden.

Unterstützung bei der Vorbereitung auf unangekündigte Audits

Wenn Sie der Gedanke an solche unangekündigte Audits fürchten lässt, dann melden Sie sich. Mit meinem Team aus Auditoren und Risikomanagement-, Qualitätsmanagement-, Usability und Software-Experten kann ich Ihnen schnell helfen, die Konformität Ihrer Produkte und Ihrer Entwicklung mit den einschlägigen Gesetzen und Normen (IEC 62304, IEC 62366, ISO 14971 und ISO 13485) zu prüfen. Wir helfen Ihnen auch mit konkreten, schnell umsetzbaren Tipps, um mögliche Fehler auszubügeln; damit Sie unangekündigten Audits gelassen entgegensehen können.

Kategorie: Regulatory Affairs
Tags:
1 Kommentar »

User Errors und Use Errors im Usability Engineering

Donnerstag 19. März 2015 von Christian Johner

User Errors und Use Errors: Man muss schon genau lesen, wenn man auf den Unterschied dieser beiden Begriffe stoßen will. Dennoch ist dieser Unterschied wichtig:

Wenn Sie sich überlegen, was ein Benutzer mit einem interaktiven Gerät machen kann, stoßen Sie vielleicht auf folgende Taxonomie:

User errors und Use Errors

Das interessante daran ist, dass die nicht beobachtbaren Handlungen, also die kognitiven Leistungen, nicht unmittelbar zu einer Gefährdung führen. Erst daraus resultierende Handlungen, beispielsweise an einem interaktiven Gerät oder direkt am Patienten, können zu Gefährdungen führen.

Bei den kognitiven Leistungen kann der Benutzer etwas falsch erkennen (z.B. eine 1 (eins) mit einem l (Buchstabe) verwechseln) oder die richtig erkannte Information falsch verarbeiten (z.B. missinterpretierten), oder beides. Und selbst wenn er alles richtig erkannt und richtig verstanden hat, kann der Nutzer falsche Handlungen begehen. Wenn er beispielsweise etwas vergisst.

Im Usability Engineering geht es aber nicht darum, den Nutzer als den Schuldigen zu brandmarken (User Error), sondern darum, Fehler, die aus der (mangelnden) Gebrauchstauglichkeit her rühren (Use Errors), zu minimieren.

Wenn Sie sich für solche Konzepte interessieren und wissen wollen, wie man Benutzerschnittstellen herleitet, die das Attribut “gebrauchstauglich” wirklich verdienen, dann empfehle ich Ihnen aufs wärmste das Seminar mit Thomas Geis “Usability, Requirements und IEC 62366″.

Use Errors statt User Errors

Die IEC 62366, die Norm zur Anwendung des Usability Engineerings bei Medizinprodukten, spricht folglich nur von Use Errors (nicht von User Errors). Sie nennt Gründe, die zu Use Errors führen können.

Gründe für Use Errors laut IEC 62366

Momentan arbeiten wir an Begriffen wir normaler und anormaler Gebrauch und an „Use Error“, um den englischen Begriff zu nutzen. Die fehlerhafte Wahrnehmung („Perception“) wie das verwechseln eines Buchstaben “l” mit der Zahl “1” oder das Missverstehen von Daten (als Beispiel für „Cognition Errors“) wird die nächste Version der IEC 62366 betrachten.

Was die IEC 62366 generell nicht betrachtet ist der „abnormal use“, also die missbräuchliche und vorsätzlich falsche Nutzung.

Kategorie: Usability & IEC 62366
Keine Kommentare »

Design History File: Was Ihr DHF enthalten sollte

Mittwoch 18. März 2015 von Christian Johner

Die FDA fordert in 21 CFR part 820 (das sind die „Quality System Regulations“) ein Design History DHF. Dieses DHF sollte nicht mit dem Device History Record und dem Device Master Record verwechselt werden. Dieser Beitrag erläutert, was das Design History File enthalten muss und wie es sich von den beiden anderen „Akten“ unterscheidet.

Design History File: Ausschnitt  aus dem 21 CFR part 820

Ausschnitt aus dem 21 CFR part 820 mit Design History File, Device History Record und Device Master Record (zum Vergrößern bitte klicken)

Design History File

Die FDA fordert in 21 CFR part 820.30j (Design History File): Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate that the design was developed in accordance with the approved design plan and the requirements of this part.

Zu den Dokumenten, die ein Design History File enthalten sollte, zählen:

  • Design Inputs wie z.B. eine System oder Software Requirements Specification
  • Design Outputs wie System- oder Software-Architekturen, Bauteilzeichnungen sowie die Risikoanalyse und Risikobewertungen des Designs
  • Design Verification und Design Validation z.B. in Form von Komponenten-, Integrations- und System-Tests sowie Usability Verifizierungen und Validierungen, die sowohl während als auch zum Ende der Entwicklung stattfinden sollten.
  • Design Transfer, aus dem hervorgeht, wie das Produkt später produziert werden soll.

Bei Software gibt Ihnen auch das FDA Dokument „Content of the Premarket Submissions for Software Contained in Medical Devices“ weitere Informationen zum Inhalt eines Design History Files.

Allerdings darf das Design History File nicht nur den letzten Stand der Entwicklung repräsentieren. Vielmehr muss das Design History File den Verlauf der Entwicklung nachvollziehbar dokumentieren, beispielsweise wie Änderungen am Design (Design Change) eingeflossen, freigegeben und umgesetzt wurden. Das Design History File entspricht somit der Historie der Entwicklungsdokumentation.

Ihr Design History File muss den Nachweis erbringen, dass Sie als Hersteller sich an Ihre eigenen Verfahrensanweisungen insbesondere mit Bezug zur Entwicklung gehalten haben.

Unterschied von Design History File und DMR bzw. DHR

Device Master Record DMR

Nachdem das Design History File das zu entwickelnde Gerät zeigt, beschreibt der Device Master Record wie das Gerät genau zu produzieren ist. Dazu können Vorgaben zählen,

  • wie das Gerät zusammenzubauen ist,
  • wie Produktionsmaschinen einzustellen sind,
  • wie das Gerät zu prüfen ist,
  • wie das Gerät verpackt werden soll,
  • wie das Gerät installiert und gewartet werden muss
  • usw.

Für standalone Software kann der Device Master Record relativ dünn ausfallen.

Device History Record DHR

Der Device History Record schließlich liefert den Nachweis, dass man das Gerät gemäß den Vorgaben des Device Master Records produziert hat und die darin geforderten Akzeptanzkriterien erfüllt.

Diese „Akte“ enthält Aufzeichnungen wie die Ergebnisse von Produktprüfungen z.B. am Ende der Produktion. Jedes einzelne Gerät (bei Pharmaprodukten wären das die „Batches“) gilt es dabei zu identifizieren. Auch Wartungsberichte und Ergebnisse von Installationstests wären Bestandteil dieser Akte.

Für standalone Software wird auch der Device History Record schlanke sein, da es keine wirkliche Produktion gibt. Die Vervielfältigung auf Datenträger oder die Verteilung über Downloads zählen aber dazu.

Erstellen eines Design History Files (DHF)

Benötigen Sie Unterstützung beim Erstellen einer FDA-konformen Dokumentation insbesondere für eine 510(k) Submission? Wir helfen Ihnen gerne, schnell und kompetent, (nicht nur) Ihr Design History File konform mit den Forderungen des 21 CFR part 820 zu erstellen. Nehmen Sie mit uns Kontakt auf!

Kontakt aufnehmen (Webformular)

Kategorie: FDA
Keine Kommentare »

Usability Validierung: Konform mit IEC 62366 und FDA

Dienstag 17. März 2015 von Christian Johner

Die Usability Validierung ist eine Prüfung mit objektiven Mitteln, ob spezifizierte Nutzer im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele (Zweckbestimmung) effektiv und effizient erreichen können. Dieser Artikel

Regulatorische Anforderungen an die Usability Validierung

Die Medizinprodukte-Richtlinie MDD fordert explizit, dass Hersteller auch Risiken identifizieren und beherrschen müssen, die sich aus einem spezifischen Nutzungskontext und durch die Charakteristiken der Nutzer (z.B. Ausbildungsgrad, intellektuelle und sprachliche Fähigkeiten) ergeben. Das gleiche tut die FDA.

Um den Nachweis zu erbringen, dass diese Forderungen erfüllt sind, bedarf es einer Usability Validierung. Die IEC 62366 sowie das Human Factors Engineering Guidance Dokument der FDA geben Hinweise, wie diese Usability Validierung zu erfolgen hat.

1. Charakterisierung der Benutzer

Die Usability Validierung muss also mit typischen Vertretern der spezifizierten Nutzergruppe erfolgen, üblicherweise in Form einer teilnehmenden Beobachtung. Diese Prüfung setzt natürlich voraus, dass man spezifiziert hat:

  • Die Nutzergruppe, beispielsweise anhand des Alters, der Ausbildung, der Erfahrung mit dem Produkt, den körperlichen und intellektuellen Fähigkeiten.
  • Den Nutzungskontext, beispielsweise die “mentale Workload”, die Umgebung (Temperatur, Feuchtigkeit, Helligkeit, …), die zu erledigenden Aufgaben uvm.
  • Die Nutzungsziele, hier referenziert man üblicherweise die (medizinische) Zweckbestimmung.

Dass die Nutzer und die Nutzungsumgebung zu spezifizieren sind, verlangt die IEC 62366 in Kapitel 5.1.

2. Einbeziehung repräsentativer Benutzer in die Usability Validierung

Nur für die Usability Validierung benötigen Sie zwingend repräsentative Nutzer und einen repräsentativen Nutzungskontext (Gebrauchsumgebung).

3. Anzahl an Probanden bei der Usability Validierung

Die IEC 62366 verlangt bei der Validierung der Gebrauchstauglichkeit repräsentative Anwender. Wie viele das sind, sagt sie aber nicht. Das geht auch kaum, schließlich hängt die Anzahl auch davon ab, wie homogen die verschiedenen Nutzergruppen sind.

Die FDA hingegen referenziert in ihrem Guidance Dokument „Applying Human Factors and Usability Engineering to Optimize Medical Device Design“ eine Studie, die konkretere Zahlen nennt.


Anzahl bei der Usability Validierungzum Vergrößern klicken

Wie Sie sehen, können Sie mit fünf repräsentativen Nutzern im Mittel 85% der Nutzungsprobleme finden, mit zehn bereits 95%. Das sind doch mal konkrete Zahlen!

4. Durchführung

In den Usability Validierungsplan müssen laut IEC 62366 die Hauptbedienfunktionen einbezogen werden. Lesen Sie dazu mehr im folgenden Kapitel.

Verfahren zur Usability Validierung

Es gibt verschiedene Verfahren zur Prüfung der Gebrauchstauglichkeit (Usability). Man unterscheidet dabei die folgenden:

Verfahren zur Usability Verifizierung und Usability Validierung

Usability Verifizierung: Inspektion

Die Verifizierung der Gebrauchstauglichkeit wird Ihnen mit einer Inspektion gelingen. Das ist ein Prüfverfahren, bei dem ein oder mehrere Experten Ihr Produkt darauf prüfen,

  • ob die spezifizierten Anforderungen, wie man sie auch in Style Guides und Normen formuliert findet, umgesetzt sind oder/und
  • ob das Produkt (prinzipiell) in der Lage ist, die Nutzungsanforderungen zu erfüllen. Wenn die Nutzungsanforderung lautet, der Arzt muss die Patienten mit einem zu niedrigen Hämoglobinwert erkennen können, und das System zeigt den Hämoglobinwert nicht an, dann ist diese Anforderung nicht erfüllt.

Usability Validierung: Teilnehmende Beobachtung

Doch die Inspektion alleine genügt nicht. Sie müssen im Rahmen einer teilnehmenden Beobachtung echte Nutzer in einer tatsächlichen oder in einer simulierten Gebrauchsumgebung die Kernaufgaben durchlaufen und die sicherheitskritischen Funktionen ausführen lassen. Nur wenn die Nutzer tatsächlich in der Lage sind, die Nutzungsziele zu erreichen und damit die Nutzungsanforderungen als erfüllt nachzuweisen, haben Sie die Gebrauchstauglichkeit Ihres Produkts auch validiert.

Dies setzt voraus, dass Sie alle Kernaufgaben kennen. Diese führen Sie zu den häufig benutzen Funktionen. Weiter müssen Sie alle sicherheitskritischen Funktionen kennen. Diese ergeben sich aus der Risikoanalyse.

Benutzerbefragungen

Und für was bedarf es dann noch der Benutzerbefragungen? Im Sinn der IEC 62366 eigentlich gar nicht. Setzen Sie Fragenbögen ein, um Produkte oder Entwicklungsstände quantitativ zu vergleichen. Und setzen Sie Interviews ein, um Beschwerden zu objektivieren.

Weitere Begriffe bei der Prüfung der Usability

Was die FDA bereits umgesetzt hat, wird nun auch in die zweite Ausgabe der IEC 62366 Eoinzug halten: Die Begriffe Verifizierung und Validierung der Gebrauchstauglichkeit werden durch die Begriffe formative und summative Evaluierung “ersetzt”. Doch ist das wirklich ein Ersetzen?

Die FDA und die EN 62366 nutzen leider verschiedene Begriffe.

Eigentlich haben die beiden Begriffspaare wenig mit einander zu tun – abgesehen davon, dass sie alle mit der Prüfung der Gebrauchstauglichkeit in Verbindung stehen. Die beiden Begriffspaare beziehen sich vielmehr auf unterschiedliche Dimensionen: Usability Validierung und Usability Verifizierung unterscheiden sich in der Zielsetzung der Prüfung. Hingegen unterscheiden die Begriffe formative und summative Evaluierung den Zeitpunkt der Prüfung.

Beispielsweise wäre die Prüfung eines GUI Prototyps während der Entwicklung eine Validierung und eine formative Evaluierung. Eine Prüfung der Gebrauchstauglichkeit des fertigen Produkts mit repräsentativen Nutzern in einer repräsentativen Gebrauchsumgebung wäre ebenfalls eine Validierung, aber eine summative Evaluierung.

 Mit was Sie die Usability Validierung nicht verwechseln sollten

“Klassische” System-/Produkt-Validierung versus Usability Validierung

In einem weiteren Beitrag finden Sie den Unterschied zwischen diesen Verfahren beschrieben.

Usability Validierung versus klinische Studien

Ich bin über einen Artikel in der “European Medical Device Technology” zum Thema Gebrauchstauglichkeit gestoßen. Darin weist die Autorin auf einen Absatz der IEC 60601-1-6 hin, der mir als sehr wichtig erscheint:

It should be noted that clinical investigations conducted according to ISO 14155-1 and usability testing for verification or validation according to this standard are two fundamentally different activities and should not be confused.

Genauso ist es! Bei der Validierung der Gebrauchstauglichkeit geht man davon aus, dass es generell möglich ist, mit dem Produkt den medizinischen Zweck zu erfüllen. D.h. man setzt voraus, dass die klinische Erprobung erfolgreich war.

Die Validierung der Gebrauchstauglichkeit prüft hingegen, ob die Vertreter einer spezifizierten Nutzergruppe in einem spezifizierten Nutzungskontext tatsächlich das spezifizierte Ergebnis erreichen. Denn die Tatsache, dass das Gerät generell dazu in der Lage ist, lässt keine Rückschlüsse auf die Interaktion der Anwender mit dem Produkt zu.

In anderen Worten:

  • Die Usability Studie hat zum Ziel zu validieren, ob die spezifizierten Nutzer im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele effektiv und effizient erreichen können. Eine Voraussetzung für die Validierung der Usability sind repräsentative Nutzer.
  • Die klinischen Studien haben hingegen das Ziel nachzuweisen, dass das Produkt ein positives Nutzen-Risiko-Verhältnis hat. Voraussetzung für eine klinische Studie sind Patienten.

Obwohl beide Untersuchungen ggf. in der Klinik „in Echtbedingungen“ durchgeführt werden, sind die Zielsetzungen dennoch unterschiedlich, wenn auch nicht überschneidungsfrei. Oft ist es hilfreich, die Prüfungen voneinander zu trennen.

Usability Validierung versus Feldtest

Einer meiner Lieblingskunden kam auf die Idee, seine Software im Feldtest zu validieren, um so die entsprechenden gesetzlichen Forderungen nach Validierung zu erfüllen. Dabei hätte er sich um ein Haar strafbar gemacht.

Sein Gedanke war eigentlich gut, im Feld zu prüfen, ob die Zweckbestimmung und Nutzungsanforderungen erfüllt sind. Schließlich fordert die IEC 62366 sogar, dass man „echte“ Benutzer involviert. Die Anwendung aber unkontrolliert in einem Feldtest zu prüfen, entspricht einer Inverkehrbringung. Das ist strafbar.

Der richtige Ansatz wäre gewesen, diese Prüfung entweder in einer simulierten Umgebung wie einem Usability Lab oder in einer streng abgegrenzten klinischen Prüfung durchzuführen. An die klinischen Prüfungen sind aber einige Auflagen erfüllt.

Gerade für Software bedarf es derer aber häufig nicht. Aus diesem Grund empfehle ich das Usability Lab. Wer einmal Hersteller beobachtet hat, wie sie betroffen, ungläubig und fassungslos die Benutzer mit Ihrer Software arbeiten sehen, wird eines nicht mehr vermuten: Dass ein Usability Lab nicht geeignet sei, Nutzungsprobleme zu identifizieren. Schneller und preisgünstiger erfährt man nicht, was viele bei einer Validierung eigentlich gar nicht wissen wollen: Die nackte und oft brutale Wahrheit über ihr Produkt.

Weitere Informationsquellen

Seminar “Usability, Requirements & IEC 62366″

Wie Sie eine solche Validierung (in Form einer teilnehmenden Beobachtung) planen und durchführen lernen Sie im Seminar „Usability, Requirements und IEC 62366“ mit meinem Usability-Guru Thomas Geis. Es wird Ihren Blick auf die eigenen Produkte radikal ändern. Sie werden verstehen lernen, weshalb

  • es zwischen Ihrer Entwicklungsabteilung und dem Produktmarketing immer Reibereien gibt,
  • Ihre Kunden scheinbar ständig neue Wünsche haben,
  • Ihr Unternehmen sich schwerer tut, als Apple,
  • Sie noch kein Millionär sind.

Sie lernen aber nicht nur die Ursachen zu verstehen, sondern v.a. den Weg kennen, um genau diese Schwierigkeiten zu meistern. Für mich war und ist das Seminar wegweisend.

Wenn Sie dabei sein wollen, empfehle ich Ihnen, sich gleich einen Termin im nächsten Jahr zu sichern. Ich konnte Thomas Geis nur dreimal dafür gewinnen, nach Konstanz zu kommen. Nutzen Sie diese seltene Chance.

Mehr zum Seminar erfahren

 Usability Lab

Wir verfügen auch über ein  Usability-Lab, in dem wir Kundenprodukte testen und verschiedene Verfahren demonstrieren. Vom Cognitive-Walkthrough bis zur Experten-Evaluation. Vom Eye-tracking bis zum softwaregestützten Usability-Test (Usability Validierung).

Eye-trackerPupilleSoftware

Wir haben verschiedenen Produkten validiert und erkannt, welche zum Teil katastrophalen Mängel diese Anwendungen haben.

  1. Die Bundesanstalt für Arbeitsschutz und Arbeitsmedizin hat auch unter Mitwirkung von benannten Stellen das Ergonomiekompendium „Anwendung Ergonomischer Regeln und Prüfung der Gebrauchstauglichkeit von Produkten veröffentlich.
  2. Aus dem FDA-Umfeld stammt die ANSI/AAMI HE75:2009 — Human factors engineering – Design of medical devices

Beide Dokumente konzentrieren sich nicht auf Software. Dafür enthalten sie konkrete Vorgaben zur Spezifikation der Gebrauchstauglichkeit von Produkten – im Gegensatz zur IEC 62366, die eine Prozessnorm ist. Und noch etwas ist beiden Dokumenten gemein: ein Umfang von mehreren hundert Seiten.

Kategorie: Usability & IEC 62366
Tags:
Keine Kommentare »

Primäre und sekundäre Benutzer im Usability Engineering

Montag 16. März 2015 von Christian Johner

Was sind primäre Benutzer? Was sekundäre und gar tertiäre Benutzer? Welche spezifischen Anforderungen an diese Benutzertypen stellen die Regularien insbesondere die FDA und die IEC 62366?

Primäre Benutzer und sekundäre Benutzer

Primäre Benutzer, sekundäre Benutzer und indirekte Benutzer

Primäre Benutzer

Primäre Benutzer sind die Benutzer eines Produkts, die es nutzen, um den medizinischen Zweck zu erreichen. Beispiele dafür sind Ärzte, Pflegekräfte, medizinische Assistentinnen und Assistenten.

Sekundäre Benutzer

Sekundäre Benutzer sind die Benutzer eines Produkts, die es für den sonstigen bestimmungsgemäßen Gebrauch nutzen. Dazu zählen z.B. Servicetechniker und Personen, die für die Installation, Aktualisierung und Konfiguration verantwortlich sind.

Indirekte oder tertiäre Benutzer

Indirekte oder tertiäre Benutzer sind die Personen, die die Arbeitsergebnisse insbesondere der primären Benutzer für ihre eigene Arbeit benötigen. Beispielsweise benötigt ein Medizincontroller für die Abrechnung eines Krankenhaus-Aufenthalts die Beatmungsstunden, die ein andere Benutzer (primäre Benutzer) im medizinischen Informationssystem erfasst hat.

Regulatorische Anforderungen

Charakterisierung der primären Benutzer und sekundären Benutzer

Weder die FDA noch die IEC 62366 differenzieren diese Benutzertypen. Beide stellen keine Anforderungen mit Bezug auf die tertiären Benutzer. Allerdings fordern sowohl die FDA als auch die IEC 62366, dass Sie alle Benutzer, primäre Benutzer und sekundäre Benutzer charakterisieren. Sie können Benutzer charakterisieren anhand von

  • Ausbildung, Erfahrung im relevanten (medizinischen) Kontext
  • Erfahrungen mit dem Produkt oder Produkten der gleichem Produktklasse
  • Typische Aufgaben
  • Demographische Eigenschaften wie Alter und Geschlecht
  • Geistige und körperliche Fähigkeiten bzw. Einschränkungen
  • Sozialer und kultureller Hintergrund.

Weitere Anforderungen

Die FDA fordert, dass sowohl primäre Benutzer als auch sekundäre Benutzer bei der Spezifikation der Benutzer-Produkt-Schnittstelle zu berücksichtigen sind.

Die IEC 62366 verlangt das auch und kennt die Hauptbedienfunktionen als die sicherheitskritischen und häufig benutzten Bedienfunktionen.

  • Üblicherweise sind es die häufig benutzten Funktionen, die von den primären Benutzern genutzt werden.
  • Sicherheitskritische Funktionen gibt es sowohl bei den primären Benutzern als auch bei sekundären Benutzern. Regelmäßig übersehen Medizinproduktehersteller, dass das Konfigurieren – also eine Aufgabe v.a. der sekundären Benutzer – zwar selten erfolgt, Fehler aber gravierende Schäden zur Folge haben können, also sicherheitskritisch sind.

Kategorie: Usability & IEC 62366
Keine Kommentare »