Medizinproduktehersteller müssen die Stakeholder-Anforderungen systematisch erfassen, bewerten und nachweisen, dass diese erfüllt sind. Dabei gilt es, 5 Typen an Stakeholder-Anforderungen zu unterscheiden.

Inhalt

Diese Seite verschafft Ihnen einen schnellen Überblick

  1. über die Grundlagen (Was sind Stakeholder-Anforderungen?),
  2. wie Sie prüfen können, dass diese Anforderungen erfüllt sind,
  3. welche regulatorischen Anforderungen Sie beachten müssen,
  4. welche Fehler Sie dabei vermeiden sollten und
  5. wo Sie Unterstützung bei alldem erhalten.

1. Grundlagen

a) Definition

Definition: Stakeholder-Anforderung

„Eine Anforderung, die beschreibt, was aus Sicht einer Interessensgruppe (Gesetzgeber, Kaufentscheider, Betreiber, Benutzer) an einem System ermöglicht werden muss, um ein oder mehrere Erfordernisse zu befriedigen“

Quelle: adaptiert aus ISO/IEC 15288

b) Typen an Stakeholdern

Stakeholder sind diejenigen Personen, die Ansprüche oder Interessen an einem Unternehmen, Produkt oder Projekt haben. Dazu zählen:

  • Nutzer / Anwender
  • Personen, die mit den Ergebnissen weiterarbeiten
  • Investoren
  • Betreiber
  • Gesetzgeber
  • Kaufentscheider

b) Typen an Stakeholder-Anforderungen

Anforderungstyp Beschreibung Beispiel
Nutzungsanforderungen Anforderungen an die effiziente Erbringung eines Ergebnisses mit einem interaktiven System (z. B. Software) Der Nutzer muss am System die Patienten erkennen können, die Hepatitis-positiv sind.
Gesetzliche Anforderungen Anforderungen von Gesetzgebern und Behörden, z. B. in Form von Richtlinien, Gesetzen, Verordnungen, Normen usw. Nur befugte Personen dürfen die Laborwerte der Patienten sehen (Datenschutz).
Fachliche Anforderungen Anforderungen an die Vollständigkeit und Korrektheit eines Arbeitsergebnisses Der Hepatitis-Wert muss im Arztbrief auf eine Nachkommastelle genau angegeben sein.
Organisatorische Anforderungen Anforderung an das Verhalten von Personen oder Organisationseinheiten bei der Erbringung von Arbeitsergebnissen Die Ärzte müssen die Visite dokumentieren.
Marktanforderungen Anforderungen, die für die Kaufentscheidung entscheidend bzw. relevant sind Die Software muss sowohl auf Windows als auch auf Linux laufen.

Aus den Stakeholder-Anforderungen sollten Hersteller die Systemanforderungen ableiten.

Hinweis

Die Anforderungstypen müssen nicht disjunkt (überschneidungsfrei) sein. Beispielsweise könnte eine gesetzliche Anforderung darin bestehen, dass eine Medikamentenverschreibung ohne Prüfung von Medikamentenwechselwirkungen und Kontraindikationen verboten ist. Damit führt eine gesetzliche Anforderung direkt zu einer Nutzungsanforderung, z. B.:

„Der Nutzer muss am System Medikamentenwechselwirkungen (und deren potenzielle Auswirkungen auf den Patienten) erkennen können.“

Weiterführende Informationen

In folgenden Fachartikeln erhalten Sie weiterführende Informationen:

2. Prüfen von Stakeholder-Anforderungen

Die verschiedenen Typen an Stakeholder-Anforderungen bedürfen verschiedener Methoden zur Bewertung, ob die Anforderungen erfüllt sind.

Anforderungstyp Möglichkeit zur Überprüfung
Nutzungsanforderungen Die Prüfung erfolgt u.a. durch eine Usability-Validierung (summative Evaluation).
Marktanforderungen Das sind verkappte Systemanforderungen, die man durch eine Verifizierung prüft.
Fachliche Anforderungen
(an das Arbeitsergebnis)
Das ist die klassische Validierung. Neben der Usability-Validierung zählt hierzu die klinische Bewertung.
Organisatorische Anforderungen Diese richten sich nicht an das Produkt, sondern an den Menschen und sind weder zu verifizieren noch zu validieren.
Gesetzliche Anforderungen Gesetzliche Anforderungen können zu Nutzungsanforderungen führen (sind also entsprechend zu validieren) oder direkt zu Systemanforderungen, die verifiziert werden müssen.
Weitere Anforderungen, z. B. Anforderungen von Investoren an Umsatz, Anzahl verkaufter Geräte, Entwicklungszeit Wie sich diese Zahlen überprüfen lassen, ist offensichtlich, aber aus regulatorischer Sicht uninteressant.
Weiterführende Informationen

Lesen Sie hier mehr zum Unterschied zwischen Verifizierung und Validierung.

3. Regulatorische Anforderungen

Alle Normen für Qualitätsmanagement (z. B. ISO 9001, ISO 13485 oder 21 CFR part 820) verlangen, dass der Hersteller die Stakeholder-Anforderungen erhebt.

Die ISO 13485:2016 unterscheidet Anforderungen, die die Kunden ausdrücken, von den Anforderungen, die die Kunden nicht ausdrücken, die aber notwendig sind, damit das Produkt seine Zweckbestimmung erfüllen kann.

Den Autoren der Norm scheint bewusst zu sein, dass man Kundenanforderungen nicht direkt erfragen kann.

Die genannten Regularien verlangen zudem, dass die Hersteller sicherstellen, dass die Stakeholder-Anforderungen (insbesondere die Zweckbestimmung) erfüllt werden.

4. Typische Fehler

a) Verwechslung von Stakeholder-Anforderungen und Systemanforderungen

Die IEC 62304 übernimmt aus der IEC 60601-1 die Abbildung mit dem V-Modell – inklusive Fehler: Sie schreibt, man würde gegen die PEMS-Anforderungen validieren. Aber PEMS-Anforderungen sind Systemanforderungen. (Das „S“ in PEMS steht für System.) Systemanforderungen werden verifiziert, nicht validiert.

Validierung von Medizinprodukten gemäß IEC 60601-1

Abb. 1: Die IEC 60601-1 verwechselt die verschiedenen Anforderungstypen.

Weiter behauptet die Norm, die PEMS-Anforderungen ergäben sich aus Anwenderbedürfnissen. Der Begriff „Anwenderbedürfnis“ ist nicht definiert. Er entspräche noch am ehesten den Erfordernissen. Aber Systemanforderungen ergeben sich nicht aus Erfordernissen, sondern auch Stakeholder-Anforderungen. Letzte müssen die Erfordernisse erfüllen.

Weiterführende Informationen

Wenn Sie tiefer in das Thema eintauchen wollen, dann lesen Sie das Buch „Usability als Erfolgsfaktor“ von Thomas Geis und Christian Johner.

b) Falsche Methoden zum Ableiten von Stakeholder-Anforderungen

Viele Stakeholder-Anforderungen wie die Nutzungsanforderungen lassen sich nicht durch direktes Befragen der Stakeholder (hier der Nutzer) ableiten. Wenn Sie Nutzer (User) nach deren Anforderungen (Requirements) fragen, erhalten Sie nicht die User Requirements, sondern die User Requests.

Mehr zum Unterschied zwischen User Requirements und User Requests lesen Sie hier.

5. Unterstützung

Haben Sie noch Fragen zu den Requirements? Antworten erhalten Sie in unserem kostenlosen Micro-Consulting.

Im Seminar Usability, Requirements und IEC 62366-1 lernen Sie, die Anforderungen systematisch und normenkonform zu erheben.

Durch Usability Tests in den Labs des Johner Instituts stellen Sie sicher, dass die Stakeholder-Anforderungen normenkonform nachgewiesen sind und Ihre Produkte dank ihrer Gebrauchstauglichkeit erfolgreich werden.

Melden Sie sich gleich hier, wenn Sie Unterstützung wünschen. Wir helfen Ihnen gerne dabei, alle relevanten Anforderungen schnell, einfach und gesetzeskonform zu erheben und nachzuweisen. Denn damit werden Ihre Produkte sicher und gefragt und kommen schnell in den Markt.


Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen Die Vorstellungen darüber, was Lastenhefte und Pflichtenhefte enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma. Das liegt u. a. daran, dass die beiden Dokumente die verschiedenen Anforderungstypen nicht konsequent unterscheiden. Vielmehr unterscheiden sie sich in der Granularität und dem Detailgrad. Schon aus regulatorischer Sicht sollten Sie…

Weiterlesen

Use Scenario – User Story – User Task: Endlich durchblicken

Die IEC 62366-1 nutzt das Konzept (Hazard-Related) Use Scenario, auf deutsch „(gefährdungsbezogenes) Benutzungsszenario“. Die FDA kennt die Critical (User) Tasks. In der Entwicklung arbeitet man mit Use Cases und User Stories. Diese Begriffsvielfalt erschwert ein gemeinsames Verständnis. Das aber ist notwendig, um konsistente und gesetzeskonforme Gebrauchstauglichkeitsakten zu erstellen und regulatorische Probleme zu vermeiden. Dieser Artikel…

Weiterlesen

Mit User Centered Design die falschen Produkte entwickeln

Das 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…

Weiterlesen

‚Personas‘: die 5 häufigsten Fehler vermeiden

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

Design Input: Was Sie nicht vergessen sollten

Unter „Design Input“ versteht man die Entwicklungsvorgaben, an die nicht nur die FDA konkrete Forderungen stellt. Dieser Artikel beschreibt, welche Inhalte Ihr Design Input enthalten sollte. Sie erfahren, wie das Risikomanagement mit dem Design Input zusammenspielt.  Inhaltsübersicht Definition „Design Input“ » Regulatorische Anorderungen » Inhalte des Design Inputs » Risikoanalyse als Design Input »

Weiterlesen

UML Unified Modeling Language: Nicht nur für Software-Architekturen

Die UML, die Unified Modeling Language, ist eine standardisierte Sprache, mit der sich Software, aber auch ganze Systeme beschreiben lassen. Durch die wenigen aber genau definierten Notationselemente der UML sind Hersteller befähigt, Sachverhalten eindeutig und präzise zu beschreiben und so Anforderungen z.B. der IEC 60601-1 und IEC 62304 zu erfüllen.  Inhaltsübersicht Modellierung der Wirklichkeit » Modellierung von…

Weiterlesen