Qualitätsmanagement
Der Markt für Medizinprodukte erfordert ein tiefes Verständnis der Situation im Bereich des Usability Engineering und der Sicherheitsvorschriften. Im medizinischen Bereich unterliegen Geräte der Regulierung durch die IEC 62366-1:2015 und der aktualisierten Änderung von 2020. Ästhetisches Aussehen und ansprechende Benutzeroberflächen spielen keine Rolle, wenn nicht nachgewiesen werden kann, dass der Entwicklungsprozess sicher ist. Die Vorschriften besagen, dass die Sicherheit im Zusammenhang mit der Nutzung des Geräts nur dann gewährleistet ist, wenn der Hersteller die präzisen Entwicklungsschritte befolgt und ordnungsgemäße Aufzeichnungen führt. Während der Produktentwicklung muss durch Validierungstests der menschlichen Faktoren nachgewiesen werden, dass das Gerät Anwendungsfehler in einer simulierten klinischen Umgebung minimiert.
Der schrittweise Usability-Engineering-Prozess
Phase 1: Formulierung der Zweckbestimmung
Der Sicherheitsprozess beginnt damit, dass genau aufgeschrieben wird, wofür das Gerät bestimmt ist. Hersteller müssen den medizinischen Verwendungszweck angeben, welche Krankheit damit behandelt oder diagnostiziert wird und wer der Patient ist, einschließlich Angaben wie Alter oder Gewicht. Sie müssen auch angeben, mit welchem Körpergewebe das Gerät in Berührung kommt. Ein wichtiger Teil besteht darin, das Benutzerprofil und die Benutzerumgebung schriftlich festzuhalten. Bei dieser Umgebung geht es nicht nur um Licht und Ton, sondern auch um die menschliche Seite, wie die Arbeit im Team oder allein, ob der Raum hektisch ist, wie gestresst das Personal ist und wie lang die Schichten sind. Auch die grundlegende Funktionsweise des Geräts muss detailliert beschrieben werden.
Phase 2: Gefahrenidentifikation und Zuordnung potenzieller Anwendungsfehler
Nach dem Verfassen der Spezifikation müssen Sie die Sicherheitsprobleme und Risikopunkte im Rahmen der Risikoregeln ermitteln. Die Ingenieure müssen die Hauptfunktionen des Geräts überprüfen, die für die Sicherheit von Bedeutung sind. Darauf basierend und unter Berücksichtigung der Gebrauchsspezifikation muss das Unternehmen die Fehler auflisten, die Anwendern bei der normalen Verwendung unterlaufen können. Dies umfasst sowohl aktive Fehler als auch vergessene Handlungsschritte, was laut den Regeln als mangelnde Benutzeraktivität gilt. Alle diese Daten fließen direkt in die Akte zur Gebrauchstauglichkeit (Usability Engineering File) ein.
Phase 3: Definition von Gefährdungen und Erstellung von Anwendungsszenarien
Als Nächstes nehmen Sie diese potenziellen Fehler und analysieren historische Daten von ähnlichen Geräten auf dem Markt, um bekannte Gefahren und kritische Situationen für Patienten oder Personal zu identifizieren. Anschließend erstellen Sie spezifische Anwendungsszenarien. Unsere Risikoanalyse bewertet jeden Schritt des Benutzer-Workflows, um die klinischen Auswirkungen potenzieller Bedienungsfehler zu ermitteln.
Phase 4: Szenarienauswahl und Schnittstellenspezifikation
Sie müssen nicht jedes einzelne Szenario auf dieselbe Weise testen. Sie müssen also entscheiden, welche Szenarien in die Endprüfung einfließen. Zur Auswahl stehen Option A, bei der alles getestet wird, Option B, bei der nur eine Teilmenge basierend auf dem Schweregrad des Schadens getestet wird (z. B. wenn ein Arzt eingreifen muss), oder Option C, die den Schaden in Kombination mit anderen spezifischen Unternehmensgründen berücksichtigt. Die Entscheidung und die Begründung dafür müssen in der Akte gespeichert werden. Anschließend erstellen Sie die Schnittstellenspezifikation mit den technischen Anforderungen und klaren Risikobeherrschungsmaßnahmen und geben an, ob Handbücher oder Anwenderschulungen erforderlich sind.
Phase 5: Formative Evaluation und iteratives Interface-Design
Jetzt beginnen Sie mit der Entwicklung des Designs und nutzen formative Tests, um die Schwachstellen und Stärken der Schnittstelle zu ermitteln. Diese Tests überprüfen Teile der Benutzeroberfläche, sodass Sie wissen, wann sie bereit ist. Sie können den Designprozess nicht einfach nach Belieben abbrechen; die Entscheidung aufzuhören, muss auf Qualitätsmetriken aus späten Tests basieren. Sie hören erst auf, wenn Sie sicher sind, dass die abschließende Prüfung ein ausreichend geringes Risiko aufzeigt. Für diese formativen Bewertungen sind die Anforderungen an das Protokoll flexibler, was den Einsatz von internem Personal oder klinischem Fachpersonal zur Simulation der vorgesehenen Benutzergruppe ermöglicht. Dies stellt sicher, dass Designfehler noch vor dem Einfrieren des Designs erkannt werden.
Phase 6: Formulierung des summativen Evaluationsplans
Vor dem Abschlusstest benötigen Sie einen genauen Plan für jedes ausgewählte Szenario. Der Plan muss die Testmethode nennen und eine fachliche Begründung enthalten, die zeigt, dass sie echte Belege liefert. Es muss dargestellt werden, wie die Testpersonen mit den realen Benutzerprofilen übereinstimmen, und eine Berechnung enthalten, wie viele Personen Sie in jeder Gruppe benötigen. Der Testraum und die Bedingungen müssen der realen Nutzungsumgebung entsprechen, was von Ihnen schriftlich zu begründen ist. Ganz entscheidend ist, dass Sie für jedes Szenario die genauen Parameter dessen aufschreiben, was als korrekte Nutzung gilt.
Phase 7: Durchführung summativer Tests und Isolierung der Ursachen
Der abschließende Test muss auf der echten Produktionsschnittstelle oder einer genau entsprechenden Umgebung stattfinden. Die Hersteller analysieren die Daten, um sowohl Anwendungsfehler als auch Anwendungsschwierigkeiten zu identifizieren. Eine Schwierigkeit liegt vor, wenn jemand kämpft oder fast einen Fehler macht, diesen aber noch rechtzeitig korrigiert – was einem Beinaheunfall entspricht. Wenn ein Fehler oder eine Schwierigkeit zu einer kritischen Situation führen kann, sind Sie gezwungen, die Ursache zu ermitteln. Sie dürfen nicht raten, sondern müssen analysieren, was der Benutzer getan und was er im anschließenden Interview gesagt hat.
Phase 8: Behebung von Befunden durch technische Schleifenregeln
Wenn jemand im Abschlusstest einen Fehler macht, können Sie diesen nicht ignorieren und müssen zwei Pfade befolgen. Wenn Sie das Design korrigieren können, fügen Sie neue Risikokontrollen hinzu und kehren zum Schritt der Spezifikation zurück. Wenn eine Korrektur nicht möglich ist, müssen Sie ein technisches Dokument erstellen, in dem Sie erklären, warum es nicht verbessert werden kann, herausfinden, wie das Risiko überwacht werden kann, und das verbleibende Restrisiko gemäß den Risikomanagement-Standards bewerten. Wenn Sie jedoch während des Tests völlig neue Fehler oder Gefahren entdecken, zwingt Sie eine strikte Regel dazu, zurückzugehen und den gesamten Prozess von den früheren Schritten an zu wiederholen.
Wie Morulaa helfen kann
Die Implementierung von IEC 62366 durch Outsourcing ist eine Option, dieses Projekt jedoch intern mit unseren vorhandenen Ressourcen abzuwickeln. Bei Morulaa HealthTech können wir Folgendes bereitstellen:
Protokollentwicklung und Studiendesign für Usability-Tests
Rekrutierung repräsentativer Nutzer in verschiedenen Regionen
Moderation von formativen und Validierungsstudien
Integration von Usability-Engineering in die Zulassungsstrategie
Erstellung aller für die Einreichung erforderlichen Usability-Dokumentationen, einschließlich FDA-Einreichungen
Als Beratungsunternehmen für Medizinprodukte und In-vitro-Diagnostika (IVD) unterstützen wir Hersteller bei der Implementierung von IEC 62366, der Durchführung von Usability-Studien und der Erstellung von Dokumentationen für Behörden in der EU und den USA. Unabhängig davon, ob Sie ein neues Projekt starten oder ein bestehendes Produkt aktualisieren, hilft Ihnen unser Team dabei, Compliance zu erreichen und sicherere Produkte auf den Markt zu bringen.
Häufig gestellte Fragen
Bietet diese Norm spezifische Informationen bezüglich der genauen Registrierungsfristen, Einreichungsgebühren oder finanziellen Kosten, die für den Eintritt in Zielmärkte wie Europa oder die Vereinigten Staaten erforderlich sind?
Nein, dieser Standard enthält keine Daten oder Details zu Registrierungsfristen, Gebühren oder Einstiegskosten für verschiedene Länder. Es handelt sich lediglich um einen technischen Standard für den Aufbau einer sicheren Benutzeroberfläche, der die geschäftliche Seite oder die Registrierung im jeweiligen Land nicht berücksichtigt.
Gibt es in diesem Text spezifische Markteintrittsbarrieren, länderspezifische Prüfungsprotokolle oder Details zu obligatorischen Vor-Ort-Besuchen ausländischer Regierungsinspektoren?
Nein, dieser Standard enthält keine Daten oder Details zu Registrierungsfristen, Gebühren oder Einstiegskosten für verschiedene Länder. Es handelt sich lediglich um einen technischen Standard zur Erstellung einer sicheren Benutzeroberfläche, der die geschäftliche Seite oder die Registrierung in den einzelnen Ländern nicht berücksichtigt.
Welche expliziten Anforderungen hinsichtlich der Erhebung und Nutzung klinischer Daten werden in diesem spezifischen Text dargelegt?
Diese Norm befasst sich mit Schnittstellentechnik und Sicherheit, nicht mit klinischer Wirksamkeit, weshalb klinische Entscheidungen außen vor bleiben. Die einzigen Daten, die sie erfordert, sind Usability-Daten aus Beobachtungen und Benutzerfeedback. Sie können Daten von älteren, gleichwertigen Benutzeroberflächen verwenden, wenn Sie ein technisches Dokument vorlegen, das beweist, dass diese identisch sind.
Welche Dokumentationsanforderungen gelten für einen Hersteller, der ein Legacy-Produkt verkaufen möchte, für das keine historischen Aufzeichnungen über einen Usability-Engineering-Prozess vorliegen?
Wenn eine Geräteschnittstelle unbekannte Datensätze aufweist, fällt sie unter Anhang C. Sie müssen nachträglich eine Spezifikation für den Benutzer erstellen, alte Reklamationen sowie Berichte über Vorkommnisse im Feld prüfen und alle alten Fehler mit entsprechenden Gefahren verknüpfen. Sie müssen überprüfen, ob die Risikobeherrschungsmaßnahmen wirksam sind und das verbleibende Risiko gemäß den aktualisierten Risikostandards bewerten.
Woher weiß ein Hersteller, ob eine Schwierigkeit des Benutzers während des Tests als formeller Anwendungsfehler oder nur als geringfügige Nutzungsschwierigkeit dokumentiert werden sollte?
Die Regeln teilen sie nach dem Endergebnis auf. Ein Fehler liegt vor, wenn eine Handlung oder das Ausbleiben einer Handlung zu einem anderen Ergebnis führt als vom Werk beabsichtigt oder vom Benutzer erwartet, einschließlich des Falls, dass die Aufgabe nicht abgeschlossen werden kann. Eine Schwierigkeit ist lediglich ein vorübergehendes Ringen oder Zögern, bei dem es den Benutzern schwerfällt, die Aufgabe jedoch letztendlich korrekt abgeschlossen wird. Fälle, in denen ein Teilnehmer eine falsche Handlung einleitet, diese jedoch vor dem Abschluss korrigiert, werden als abgefangene Bedienungsfehler („use error intercepts“) eingestuft.