Unter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt.
| Inhaltsübersicht |
|---|
| Definition „Design Input“ » |
| Regulatorische Anorderungen » |
| Inhalte des Design Inputs » |
| Risikoanalyse als Design Input » |
Definition des Begriffs „Design Input“
Die FDA definiert den Begriff in 21 CFR 820.3(f) wie folgt:
„Design input means the physical and performance requirements of a device that are used as a basis for device design.“
Auch die ISO 13485 nutzt diesen Begriff, allerdings ohne ihn zu definieren.
Regulatorische Anforderungen
a) FDA 21 CFR 820.30
Die FDA legt auch die Anforderungen an den Design Input fest. Sie schreibt:
Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.
b) ISO 13485 Kapitel 7.3.3 („Entwicklungseingaben“)
Die ISO 13485 erwartet als Teil der Entwicklungseingaben:
- Anforderungen an die Funktion, Leistung und Sicherheit, um das Produkt der Zweckbestimmung entsprechend anwenden zu können,
- die regulatorische Anforderungen,
- ggf. Anforderungen, die sich aus vorangegangenen Entwicklungen ableiten lassen,
- Anforderungen, die sich aus dem Risikomanagement ergeben und
- sonstige Anforderungen (ohne diese näher zu spezifizieren).
Wie die FDA fordert auch die ISO 13485, dass die Produktanforderungen ermittelt, bewertet und dokumentiert werden.
c) Änderungen durch die ISO 13485:2016
Die ISO 13485:2016 hat die Anforderungen an den Design Input ergänzt.
Usability Requirements
Die Design Inputs müssen jetzt auch die „Usability Requirements“ beinhalten. Die Norm definiert nicht, was „Usability Requirements“ sind. Dazu dürften zählen:
- Nutzungsanforderungen d.h. was ein Nutzer am System eingeben, auswählen oder erkennen können muss
- Gestaltungsvorgaben wie Sie z.B. in Style Guides zu finden sind. Beispiele dafür sind Kontrastverhältnisse, Schriftgrößen und Positionen.
Verifizierbare oder validierbare Design Inputs
Bereits die Vorgängerversion der Norm verlangt, dass die Design Inputs eindeutig, widerspruchsfrei, vollständig und angemessen/korrekt sein müssen und dies durch ein Review zu überprüfen sei.
Die ISO 13485:2016 verlangt, dass die Anforderungen auch validierbar oder verifizierbar (sprich am Produkt testbar/prüfbar) sein müssen. Das sollte eigentlich selbstverständlich sein, wird jetzt aber explizit gefordert.
Entwicklungsakte
Die Design Inputs müssen Teil der Entwicklungsakte sein. Diese Akte wurde mit der ISO 13485:2016 eingeführt und entspricht dem „Design History File“ der FDA.
Lesen Sie hier mehr zum Thema Design History File.
Inhalte des Design Inputs
Weil Firmen häufig nicht sauber zwischen Zweckbestimmung, Erfordernissen, Stakeholder-Anforderungen und System-Anforderungen unterscheiden, wird alles als Design Input bezeichnet. Schließlich soll alles beim „Design“ beachtet werden. Doch das ist nicht korrekt.
Zweckbestimmung und Erfordernisse: Nicht Teil des Design Inputs
Die Zweckbestimmung zählt nicht zum Design Input. Die FDA fordert explizit, dass ein Verfahren dokumentiert sein muss, wie man die „Design Requirements“ (die sie synonym zu „Design Input“ verwendet) ableitet, damit diese die Zweckbestimmung erfüllen.
Die User Needs (zu deutsch Erfordernisse) zählen laut FDA noch nicht zu dem Design Input. Vielmehr muss der Design Input geeignet sein, diese Erfordernisse zu erfüllen.
Stakeholder-Anforderungen: Teil des Design Inputs
Die ISO 13485 zählt die regulatorischen Anforderungen, die zu den Stakeholder-Anforderungen zählen, explizit zu den Design Inputs.
Systemanforderungen und Systemspezifikation
Der Begriff der System Requirements Specification beinhaltet zweierlei:
- Die Systemanforderungen: Anforderungen an ein System (oft „unter der Haube“)
- Die Systemspezifikation: Festlegung, wie ein System genau gestaltet sein soll z.B. die UI-Spezifikation („über der Haube“)
Die Systemanforderungen sollte man dem Design Input zu schlagen. Schließlich bestimmen Sie die Anforderungen an das Produkt, was definitionsgemäß zum Design Input zählt.
Die System-Spezifikation (über der Haube) kann man sowohl dem Design Input zuschlagen wie dem Design Output:
- Einerseits kann man argumentieren, dass die UI-Spezifikation festlegt, wie das Produkt auszusehen hat. Dies ließe sich als Anforderungen an das Produkt und damit als Design Input deuten.
- Andererseits kann man argumentieren, dass die UI-Spezifikation bereits ein Ergebnis der Entwicklung darstellt und daher zum Design Output zählt.
Wir empfehlen die zweite Variante, weil die UI-Spezifikation in der Tat ein Entwicklungsergebnis ist.
Auch wenn die UI-Spezifikation zur Entwicklung zählt, sollte sie nicht die Aufgabe der Entwickler sein, sondern die von Usability Engineers, insbesondere Interaktionsdesignern.
Falls Sie zwischen Systemanforderungen und Systemspezifikationen nicht unterscheiden, dann schlagen Sie die System- bzw. Software-Requirements-Specification SRS dem Design Input zu.
Danke an Dr. Markus Bentrup für Hilfe bei der Präzisierung
Änderungen am Design Input
Im Lauf einer Entwicklung werden Sie den Design Input überarbeiten, entsprechend auch den Design Output. Achten Sie darauf, dass Sie alle Versionen dieser Dokumente Teil Ihres Design History Files werden lassen. Nur so können Sie die Entwicklungsgeschichte nachvollziehbar und damit glaubhaft dokumentieren.
Risikoanalyse als Design Input
Risikomanagement schlecht gemacht
Sehr oft beobachten wir folgendes Vorgehen bei Medizinprodukteherstellern:
- Medizinprodukt möglichst sicher bauen
- Risikoanalyse durchführen
- Falls inakzeptable Risiken entdeckt werden, entweder diese unter den Tisch kehren oder das Medizinprodukt sicherer machen (z.B. andere Systemarchitektur)
- Diese Maßnahmen verifizieren und alles in der Risikomanagementakte dokumentieren.
Bei diesem Vorgehen laufen Sie Gefahr, viel Zeit und Geld zu verlieren.
Besser: Risikoanalyse als Design Input
Das Ergebnis der Risikoanalyse sollte direkt Teil des Design Inputs werden.
Die Risikoanalyse sollte nicht (nur) auf Basis einer Systemarchitektur erfolgen, sondern die Anforderungen in Form eines Design Inputs bestimmen.
Wir schlagen Ihnen folgendes Vorgehen vor:
- Definieren Sie quantitativ die nicht akzeptablen Risiken. (im Auditgarant lernen Sie in drei kurzen Videos, wie das geht).
- Führen Sie eine Preliminary Hazard Analysis durch und identifizieren Sie die Gefährdungen.
- Finden Sie heraus, von welchen Outputs Ihres Geräts (kann auch UI sein), welche Gefährdungen verursacht werden können.
- Beschreiben Sie, wie der Output zur Gefährdung führen kann (wenn der Output nicht bereits die Gefährdung ist) und überlegen Sie, mit welcher Wahrscheinlichkeit die Gefährdung bei einem angenommenen Fehlverhalten des Outputs des Medizinprodukts auftritt.
- Bestimmen Sie nun mit Hilfe der Risikoakzeptanzmatrix die maximale Wahrscheinlichkeit, mit der sich ein Output falsch verhalten kann. Genau diese maximale Wahrscheinlichkeit ist nun der Design Input.
Erst jetzt entwickeln Sie Ihr Medizinprodukt gemäß dieses Design Inputs. Wenn beispielsweise der Design Input eine Wahrscheinlichkeit spezifiziert, die eine Gruppe von (Elektronik)-Bauteilen oder eine selbst geschriebene Software nicht gewährleisten kann, dann werden Sie eine andere Systemarchitektur wählen, z.B. eine diversitäre.
Leider beobachten wir fast nie, dass Design Inputs (d.h. Systemanforderungen) auf konkrete Wahrscheinlichkeiten eingehen. Die Folgen sind aufwendige Nachbesserungen, verzögerte Projekte oder/und unsichere Medizinprodukte. Vermeiden Sie diese Probleme!
