Date post: | 06-Feb-2018 |
Category: |
Documents |
Upload: | hoangtuong |
View: | 218 times |
Download: | 0 times |
Praxiswissen Medizintechnik
Der -RoutenplanerStand April 2010
Medizinprodukte planen,entwickeln, realisieren
A.H
erm
enei
t/A
.Ste
ffen
/J.S
tock
har
dt(
Hrs
g.)
In dieser Demo-Datei finden Sie jeweils die erste Seiteeines jeden Beitrags, der sich auf der Original-CD befindet. Rot gekennzeichnete Beiträge sind vollständigenthalten. Um aus diesen Beiträgen heraus auf dieentsprechenden Arbeitshilfen zuzugreifen, benötigen sieeine Internetverbindung. Sie finden diese Arbeitshilfenauch als Dateianlagen in diesem PDF-Dokument.
Herausgeber
Dr. Anne HermeneitSpectaris FachverbandMedizintechnikE-Mail: [email protected]://www.spectaris.de/medizintechnik.html
Alexander SteffenUser Interface Design GmbH (UID)E-Mail: [email protected]://www.uid.com
J�rg Stockhardtconsulting & moreE-Mail: [email protected]://www.consultingandmore.de
Redaktion
Cindy BouchagiarT�V Media GmbHAm Grauen Stein, 51105 K�lnTel. +49(0)2 21 8 06-35 07, Fax +49(0)2 21 806-3510E-Mail: [email protected]://www.ce-routenplaner.de
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbi-bliografie; detaillierte bibliografische Daten sind im Internet �ber http://dnb.d-nb.de abrufbar.
Die Inhalte dieses Werkes werden von Verlag, Herausgeber und Autoren nach bestem Wissen undGewissen erarbeitet und zusammengestellt. Eine rechtliche Gew�hr f�r die Richtigkeit der einzelnenAngaben kann jedoch nicht �bernommen werden. Gleiches gilt auch f�r die Websites, auf die �berHyperlinks verwiesen wird. Es wird betont, dass wir keinerlei Einfluss auf die Inhalte und Formu-lierungen der verlinkten Seiten haben und auch keine Verantwortung f�r sie �bernehmen. Grund-s�tzlich gelten die Wortlaute der Gesetzestexte und Richtlinien sowie die einschl�gige Rechtspre-chung.
H T�V, TUEV und TUV sind eingetragene Marken. Eine Nutzung und Verwendung bedarf dervorherigen Zustimmung.
ISBN 978-3-8249-1100-4 – Grundwerk 2009
ISBN 978-3-8249-1376-3 – 1. Akt./Erg.-Lieferung April 2010
E by T�V Media GmbH, T�V Rheinland Group, K�ln 2010
www.tuev-media.de
�berblick �ber den Inhalt
00 Wegweiser
01 Markt
02 Produktidee
03 Feasibility (Machbarkeit)
04 Entwicklungsplan
05 Lastenheft
06 Pflichtenheft
07 Entwicklung
075 Design Transfer, Industrialisierung
08 Verifizierung
09 Validierung
10 Dokumentation
11 Konformit�tsbewertung
12 �nderungen
13 Entwicklungsreview
14 Marktbeobachtung
15 Allgemeine und �bergreifende Themen
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
�berblick �ber den Inhalt 00090
Seite 1
Inhalts�bersicht
Stand
00090 �berblick �ber den Inhalt 100200 Stichwortverzeichnis 100300 Verzeichnis der Autoren 100400 Verzeichnis der Arbeitshilfen 1
01 Markt – Inhalt 101000 Markt GW
01100 Risikomanagement GW01101 Wissen schadet nicht! – Marktkenntnis reduziert
Risiken und steigert den Erfolg1
01200 Usability GW01201 Wie Sie eine Marktanalyse f�r innovative
Medizinprodukte durchf�hrenGW
01300 Klinische Bewertung GW
02 Produktidee – Inhalt GW02000 Produktidee GW
02100 Risikomanagement GW
02200 Usability GW02201 Das Produktkonzept: Wie Sie Ihre Produktidee
konkretisierenGW
03 Feasibility (Machbarkeit) – Inhalt GW03000 Feasibility GW
03100 Risikomanagement GW03101 Feasibility oder Machbarkeitsuntersuchung vor
dem eigentlichen EntwicklungsstartGW
Dieses Kapitel finden Sie nur auf der CD-ROM.
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
00100
Seite 1
Stichwortverzeichnis
A
AAMI, Association for the Advancement ofMedical Instrumentation, Kap. 09201/4
AIMDD, Active Implantable Medical De-vice Directive, Kap. 09201/1
Alleinstellungsmerkmale, Kap. 02201/1�nderungen, Kap. 13101/5�nderungsmanagement, Kap. 13102/2Anforderungen, grundlegende, Kap.
03101/7ANSI, American National Standards Insti-
tute, Kap. 09201/4Anwender, Kap. 01101/3Anwenderprofil, Kap. 09201/9Anwenderzentrierte Spezifikation, Kap.
06101/1Anwendungsteil, Kap. 06201/6Application Specification, Kap. 10201/9
B
Bediener/Anwender, Kap. 06201/5Benchmark-Analyse, Kap. 01201/31Benutzer, Kap. 06201/5benutzerorientierte Entwicklung, Kap.
07201/9Besonderheiten, l�nderspezifische, Kap.
09201/9Bestimmungsgem�ße Verwendung, Kap.
05101/1Bewertungsgrenzen, Kap. 06101/6Bewertungskriterien, Kap. 09201/15Bewertungsskala, Kap. 09201/18
C
CE-Kennzeichnung, Conformit� Europ�-enne / Kennzeichnung der �bereinstim-
mung mit EU-Richtlinien zur Produkt-sicherheit, Kap. 09201/1
Computersimulation, Kap. 03101/16
D
Design and Implementation, Kap. 10201/19Design Freeze, Kap. 11101/6Design Review Based on Failure Mode, Kap.
13102/4Design, robustes, Kap. 13102/11design rules, Kap. 06202/6Design Transfer, Kap. 07511/1Design�nderung, Kap. 09201/24Device History Record (DHR), Kap.
07511/10DIN 69901-5, Kap. 06202/1DIN EN 62366, 2008-09, Kap. 06201/1Dokumentation, Kap. 09201/23Dokumentation, technische, Kap. 03101/6Dokumentationsvorlagen, Kap. 10201/1DRBFM, Kap. 13102/4Dritte, Kap. 06201/5
E
Einweisung, Kap. 09201/20Entwicklungsmodell, Kap. 05101/1Entwicklungsprozess, Kap. 13101/1Ergonomie, Kap. 07201/7Evaluation , formative (begleitende), Kap.
09101/2Evaluation, summative, Kap. 09101/2
F
FDA, Food and Drug Administration, Kap.09201/3
Funktionsmerkmale, Kap. 06101/4
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Stichwortverzeichnis 00200
Seite 1
G
Gebrauch, Bestimmungsgem�ßer, Kap.06201/5
Gebrauchstauglichkeit, Kap. 06201/4Gef�hrdung, Kap. 13101/3Gef�hrdungssituation, Kap. 13101/3Gewerbliche Schutzrechte, Kap. 05102/1
H
Hands-on Session, Kap. 09201/8Hauptbedienfunktionen, Kap. 09201/12Human Factors Engineering Process, Kap.
09201/4
I
Integration of Design Evaluation, Kap.10201/22
Intended User Group, Kap. 01201/12Inverkehrbringen, Kap. 09101/2IVDD, In-vitro Diagnostic Directive, Kap.
09201/1
K
Kartellrecht, Kap. 05102/32Kennzahlen , Medizinische, Kap. 01201/2Klassifikation, Patientenversorgung, Kap.
01201/6Klassifizierung, Kap. 02201/5Klassifizierung, Krankheiten, Kap. 01201/1Komplexit�t der Produkte, Kap. 01101/2Konformit�tsbewertung, Kap. 02201/8Kostenr�ckerstattung, Kap. 11101/1
L
Lebenszyklus, Kap. 13101/1Leistungsmerkmale, Kap. 02201/1, 06101/4Lizenz, Kap. 05102/2
M
Machbarkeit, Kap. 03101/1Machbarkeitsuntersuchung, Kap. 03101/1Markt, amerikanisch, Kap. 06201/2MDD, Medical Device Direktive, Kap.
09201/1Medizinprodukt , positionieren, Kap.
02201/1Medizinprodukte-Richtlinie (2007/47/EG),
Kap. 06202/10Meinungsbildner, Kap. 01101/2Mensch-Maschine-Schnittstellen, Kap.
07201/16Mittelstand, Kap. 01101/1MPG, Kap. 13101/6MPG, Medizinprodukte-Gesetz, Kap.
09201/1Multiprojektmanagement, Kap. 13102/1
P
Patent, Kap. 05102/4Patient, Kap. 06201/5Patientenanschluss, Kap. 06201/6Patientenaufkommen, Kap. 01201/2Patientenpopulation, Kap. 01101/3Patientenumgebung, Kap. 06201/6Personas, Kap. 07203/2Pflichtenheft, Kap. 06202/1Pilotphase, Kap. 11101/9Primary Operating Functions, Kap.
10201/11Produkteigenschaften, Kap. 06101/4Produktionsphase, Kap. 11101/10Produktmerkmale, Kap. 06101/4Produktqualit�t, Kap. 09201/26Projekt-Kommunikation, Kap. 06101/1Projektmanagement, Kap. 05101/3Prototypen, Kap. 03101/16
E Medizinprodukte planen, entwickeln, realisieren 1. Aktualisierung
00200 Stichwortverzeichnis
Seite 2
R
Review, Kap. 13101/2Review-Protokoll, Kap. 13101/6Risiko, Kap. 13101/4Risikoanalyse, Kap. 03101/7, 13101/6Risikomanagement, Kap. 13102/4Risikomanagement-Akte, Kap. 13101/6Risikomanagement-Bericht, Kap. 13101/6Risikomanager, Kap. 13101/6Risk-/Hazard-Analyse, Kap. 07511/10
S
Schadensausmaß, Kap. 13101/4Servicebarkeit, Kap. 07511/3Sicherheitsbeauftragter, Kap. 13101/6SWOT-Analyse, Kap. 01201/32Szenarien, Kap. 07203/2
T
Testablauf, konsistenter, Kap. 09201/22Testteilnehmer, Anzahl der, Kap. 09201/11Thinking Aloud, Kap. 09201/8Traceability, Kap. 06202/9traceability analysis, Kap. 06202/4
U
Usability Engineering, Kap. 07201/9
Usability Engineering File, Kap. 10201/3Usability Specification, Kap. 10201/15Usability Validation, Kap. 10201/21Usability Validation Plan, Kap. 10201/16Usability Verification, Kap. 10201/18Use-Szenarien, Kap. 09201/13User-Centered Design, Kap. 07201/9,
09201/2
V
V-Modell, Kap. 05101/1Validierung, Kap. 06201/7Validierung, Gebrauchstauglichkeit, Kap.
06201/18Validierungskriterien, Kap. 09201/3Validierungsplan, Kap. 09101/15, 09201/7Verifizierung, Kap. 06201/6Vigilance, Kap. 11101/11
W
Wahrscheinlichkeit, Kap. 13101/4Wissensmanagement, Kap. 13102/2Worst-Case-Situation, Kap. 09201/14
Z
Zweckbestimmung, Kap. 02201/5, 05101/1,06201/5
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Stichwortverzeichnis 00200
Seite 3
Verzeichnis der Autoren
04101, 07201, 07202, 09101Dipl.-Ing., Bereichsleiter Usability & User Centered Design,wwH-c GmbH i.G.
09201Dipl.-Rom., stellvertretende Gesch�ftsleitung und Qualit�ts-managementbeauftragte, Use-Lab GmbH, Steinfurt.
06101, 11101Dipl.-Ing. (FH), MBA, Gesch�ftsf�hrer der VISAMEDGmbH.
07511Dipl.-Ing., Qualit�tsmanager, QM-Beauftagter, Dozent,Trainer und Unternehmensberater mit 25-j�hriger Erfahrungim Maschinenbau und bei Dienstleistungen. Seit 2000Schwerpunkt in der Medizintechnik (IvD-Systeme). Spezia-lisiert auf Prozessoptimierung (Schnittstellenmanagement)unter besonderer Ber�cksichtigung der effizienten Umset-zung der ISO 9001, ISO 13485, QSR 820 (FDA), vorrangig inmittelst�ndischen Unternehmen in Deutschland und denUSA.
03101, 05201, 06202Dipl.-Ing. (FH), Biomedizinische Technik, Gr�nder und Ge-sch�ftsf�hrender Gesellschafter der Metecon GmbH, Mann-heim, Ingenieurb�ro f�r Auftragsentwicklung von Medizin-produkten.
13102Manager Process Engineering, Bard GmbH, Karlsruhe, In-haber und Gesch�ftsf�hrer der AG-AQUA Gbr, Karlsruhe
B�chel,Dirk
Borgert,Anfried
Briest,Arne
F�rster,R�diger G.
Fink,Alexander
Gerber,Andreas
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Verzeichnis der Autoren 00300
Seite 1
Verzeichnis der Arbeitshilfen
03 Feasibility (Machbarkeit) – Inhalt
Kap. 03101 Feasibility (Machbarkeit)03101_a.xls Vorlage f�r Entwicklungsdokumentation03101_b.doc Vorlage f�r Testdokumentation
05 Lastenheft – Inhalt
Kap. 05101 Lastenheft05101_a.pdf Formular LastenheftKap. 05201 Lastenheft05201_a.doc Vorlage Lastenheft
06 Pflichtenheft – Inhalt
Kap. 06201 Pflichtenheft06201_a.pdf Formblatt “Validierungsplan zur Gebrauchstauglichkeit“06201_b.pdf Formblatt “Validierungsbericht zur Gebrauchstauglichkeit“06201_c.pdf Formblatt “Gebrauchstauglichkeitsakte“06201_d.pdf Checkliste zum Nachweis der Einhaltung der Anforderungen
der DIN EN 62366:2008-09Kap. 06202 Pflichtenheft06202_a.doc Vorlage eines Pflichtenhefts
13 Entwicklungsreview – Inhalt
Kap. 13101 Entwicklungsreview13101_a.doc Risikomanagement-Review-Protokoll
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Verzeichnis der Arbeitshilfen 00400
Seite 1
Markt – Inhalt
01000 Markt
01100 Risikomanagement
01101 Wissen schadet nicht! – Marktkenntnis reduziert Risiken undsteigert den ErfolgJ�rg Stockhardt
01200 Usability
01201 Wie Sie eine Marktanalyse f�r innovative Medizinproduktedurchf�hrenSherille Veira-Schnitzler, Alexander Steffen
01300 Klinische Bewertung
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
01
Seite 1
Markt
In der Marktphase geht es darum, kennenzulernen, in welchem Markt man sichmit dem eigenen Unternehmen bewegt. Interessant ist hier, welche Population,also welche soziale Zugeh�rigkeit, welche Altersstufen, Vorerkrankungen,welchen Bildungs- und Kenntnisstand die Patienten, aber auch die Anwendereines geplanten Produktes haben. Auch die m�gliche Ertragslage, also dieFrage, welche Preise in dem jeweiligen Marktsegment zu erl�sen sind, welchesErstattungssystem g�ltig ist – also die betriebswirtschaftliche Situation, ist in-teressant. Doch dies ist nichts wert, ohne zu wissen, in welchem geographischenMarkt man sich mit den Produkten bewegt und welche Historie das Unterneh-men oder �hnliche Produkte bislang in diesem Markt hatten.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Markt 01000
Seite 1
Markt – Risikomanagement
Die Aufgabe des Risikomanagement-Teams (Marketing & Vertrieb, Forschung& Entwicklung) ist es, in dieser Phase anhand der erhobenen Marktdaten dieZiel- und Anwendergruppen im Voraus festzulegen bzw. auszuw�hlen. Eben-falls ist es in dieser Phase zweckdienlich, die Bedingungen der Anwendung zuergr�nden, also zu ermitteln, mit welchem Kenntnisstand in welcher Anwen-dungsumgebung (z. B. Temperatur, Feuchtigkeit, Druck, Staub) der vorherseh-bare Anwenderkreis das m�gliche Produkt nutzen wird.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Markt 01100
Seite 1
Wissen schadet nicht! – Marktkenntnis reduziertRisiken und steigert den Erfolg
1 Situation und Fragestellung
Viele Unternehmen in Deutschland sind technologiegetrie-ben. Man f�hlt sich der technischen Entwicklung verpflichtetund meint, dem Markt immer die neueste Technik anbieten zum�ssen. Gerade im Bereich der Medizinprodukte ist diesverst�ndlich, da die innovativen Unternehmen dem Klein-und Mittelstand entstammen und somit meist von der Pro-duktidee getragen werden.
Doch auch das andere Extrem ist in der Branche zu beob-achten: Unternehmen wurden als reine Vertriebsgesellschaf-ten gegr�ndet und integrieren mehr und mehr Eigenproduktein das Produktportfolio. In diesem Fall ist die Produktauswahlvertriebsgetrieben.
Mischformen von Unternehmen, die den technologischen undden Vertriebsaspekt gleichwertig vereinen, sind dagegen re-lativ selten in der Gesundheitsbranche. Doch was sind dieNachteile?
Entwicklungsvorgaben werden immerknapper und Entwicklungszeiten k�rzer.Fehlversuche im Bereich des Product-Launches kann sich keiner leisten. – Dochwo liegt die L�sung?
Eigentlich einfach: Je mehr man von denAnwendern, dem Markt, der Anwendung
und deren Entwicklung weiß, desto effek-tiver ist die Produktentwicklung und destoh�her die Marktchancen.
Autor: J�rg StockhardtE-Mail: stockhardt@ -
consultingandmore.com
Technologie-oderVertriebs-orientierung
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Markt 01101
Seite 1
Markt – Usability
In der ersten Phase der Produktentwicklung greift das Usability-Team (For-schung & Entwicklung, Usability Engineers, User Experience Professionals)den Input des Risk Management auf. Es entstehen drei Dokumente, welche diek�nftigen Nutzer, die betroffene Patientenpopulation und die k�nftige Nut-zungsumgebung des zu entwickelnden Ger�tes beschreiben. Die Erstellungdieser Dokumente ist der erste Schritt zur Erf�llung der Anforderungen der DINEN 62366.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Markt 01200
Seite 1
Wie Sie eine Marktanalyse f�r innovativeMedizinprodukte durchf�hren
1 Das Patientenpotenzial einsch�tzen
Der erste Schritt bei einer Marktpotenzialanalyse ist die Ein-sch�tzung des Patientenpotenzials. Danach haben Sie nichtnur das Potenzial (Ihres Medizinprodukts) im Blick, sondernsprechen auch die Sprache der �rzte und Eink�ufer.
1.1 Klassifizierung der Krankheiten nach ICD-10
Als Grundlage des Patientenpotenzials dient Ihnen die Klas-sifizierung der Krankheiten. Verwenden Sie dazu die inter-nationale Klassifikation der Krankheiten und verwandterGesundheitsprobleme (ICD). Die ICD wird von der Weltge-
Noch in der Phase der Ideenfindung, unddamit lange bevor ein neues Medizinpro-dukt am Markt eingef�hrt wird, findet dieMarktanalyse statt. Sie gibt Antwort auffolgende Fragen:
• Wie viele Patienten profitieren vondem neuen Medizinprodukt?
• Wie werden diese Patienten momen-tan versorgt?
• Wer sind die wichtigsten Leistungser-bringer/Anwender?
• Welche Anforderungen in Bezug aufFunktionsmerkmale und Gebrauchs-tauglichkeit stellen die Leistungser-bringer/Anwender an das Medizinpro-dukt?
• Welche Wettbewerber und welcheWettbewerbstechnologien sind heuteschon am Markt?
• Gibt es eine Verg�tung f�r das neueMedizinprodukt?
In diesem Beitrag erfahren Sie, welche �f-fentlichen Informationsquellen Sie nutzenk�nnen, um diese Fragen zu beantworten.Des Weiteren lernen Sie verschiedeneAnalysetools kennen.
Autoren: Sherille Veira-SchnitzlerAlexander Steffen
E-Mail: [email protected]@uid.com
InternationaleKlassifikation
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Markt 01201
Seite 1
Markt – Klinische Bewertung
Informationen aus der klinischen Praxis erg�nzen in dieser Phase eine pr�ziseErfassung des Zielmarktes. Auch um eine m�glichst hohe Akzeptanz des Me-dizinproduktes in diesem Markt zu erreichen, ist ein genaues Erfassen der t�g-lichen Anforderungen, Rahmenbedingungen und Erfahrungen des Anwender-kreises ein wichtiger Schritt zu einem erfolgreichen Produkt.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Markt 01300
Seite 1
Produktidee – Inhalt
02000 Produktidee
02100 Risikomanagement
02200 Usability
02201 Das Produktkonzept: Wie Sie Ihre Produktidee konkretisierenSherille Veira-Schnitzler, Alexander Steffen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
02
Seite 1
Produktidee
In dieser Phase soll aus der vagen Idee einer m�glichen Anwendung eine Pro-duktidee werden. Dazu nutzen alle, die in der vorangegangenen Phase gewon-nenen Daten. Nun hat man eine klare Vorstellung des m�glichen Anwenders,kann die vorhersehbare bestimmungsgem�ße Verwendung eingrenzen unddaraus die Zweckbestimmung ableiten. Aus den betriebswirtschaftlichen Datender Erl�ssituation, der m�glichen Marktgr�ße, Absatzm�glichkeiten und denM�glichkeiten des Unternehmens kann der Kostenrahmen f�r den sp�terenVerkaufspreis und damit auch der m�glichen Entwicklungskosten projektiertwerden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Produktidee 02000
Seite 1
Produktidee – Risikomanagement
Die Definition der qualifizierten Produktidee gibt dem Risikomanage-ment-Team die M�glichkeit, die Anwendung des Produktes und damit vor allemdie Einschr�nkungen bei der Anwendung zu definieren. Parallel dazu werdendie vorgesehenen Funktionen (siehe Usability) des zuk�nftigen Produktes be-schrieben, womit eine Grey-Box zur Darstellung des Produktes erzeugt wird.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Produktidee 02100
Seite 1
Produktidee – Usability
Um ein Medizinprodukt zu gestalten, das sich durch gute Usability auszeichnetund sicher f�r Anwender und Patienten ist, muss ein benutzerzentrierter Ge-staltungsprozess durchgef�hrt werden. Dieser ist in der DIN EN ISO 13407beschrieben. In der dort geforderten Analysephase werden diejenigen Rah-menbedingungen beschrieben, die auch von der DIN EN 62366 f�r die weitereGestaltung gefordert werden. Dies sind allen voran die Hauptbedienfunktionen,die sp�ter an dem Ger�t/Produkt ausgef�hrt werden sollen. Diese werden un-terteilt in h�ufig genutzte Funktionen und sicherheitsrelevante Funktionen.Weiterhin wird die Zweckbestimmung, die typische physikalische Nutzungs-umgebung und der zu behandelnde Teil des K�rpers mit Usability-relevantenAspekten beschrieben. Die nutzerzentrierte Gestaltung erfordert es, dass zudiesem Zeitpunkt erste Use-Szenarien zu den Hauptbedienfunktionen erstelltwerden. Diese dienen zur Beurteilung der Machbarkeit.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Produktidee 02200
Seite 1
Das Produktkonzept: Wie Sie Ihre Produktideekonkretisieren
1 Das Medizinprodukt positionieren
Die Positionierung des Medizinprodukts bestimmt, mit wel-cher Leistung, in welchem Teilmarkt und bei welcher Ziel-gruppe das Medizinprodukt angeboten werden soll. Input f�rdie Positionierung ist die Marktanalyse (Kap. 01201 Markt).Die Produktpositionierung ist eine der wichtigsten strategi-schen Entscheidungen im Rahmen der weiteren Produktent-wicklung und der Marketingplanung.
1.1 Leistungs- und Alleinstellungsmerkmale
Die Leistungsmerkmale bilden das Herzst�ck der Produkt-positionierung. Im Rahmen des Usability-Prozesses sprichtman von den Hauptbedienungsfunktionen (Kap. 10200Dokumentation).
Lassen Sie bei der Beschreibung der Hauptbedienungsfunk-tionen unbedingt die Informationen zum Nutzungskontext
In diesem Beitrag erfahren Sie, wie SieIhre Produktidee konkretisieren und dabeidie Usability-Requirements ber�cksichti-gen.
Die Themen hierzu:
• Positionierung des Medizinprodukts• Qualitative und quantitative Produkt-
ziele
• Produktqualit�t• Rechtliche Rahmenbedingungen• Produktkommunikation
Autoren: Sherille Veira-SchnitzlerAlexander Steffen
E-Mail: [email protected]@uid.com
Input f�rPositionie-rung ist dieMarktanalyse
Leistungs-merkmale for-men Alleinstel-lungsmerkmal
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Produktidee 02201
Seite 1
Feasibility (Machbarkeit) – Inhalt
03000 Feasibility
03100 Risikomanagement
03101 Feasibility oder Machbarkeitsuntersuchung vor demeigentlichen EntwicklungsstartAlexander Fink
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
03
Seite 1
Feasibility
Diese Phase ist keine von der Medizinprodukterechtslage geforderte und damitn�tige Phase. Dennoch macht sie f�r die Unternehmenssteuerung Sinn. Hiersollte gepr�ft werden, welche Realisierungstechnik (Produkt, Produktion) indem Unternehmen umsetzbar ist. Sehr oft wird aus Kostengr�nden gefordert,auf den System- bzw. Plattformgedanken zuzugreifen, oder aber es stehen be-stimmte Maschinen und damit Fertigungstechniken zur Verf�gung, die genutztwerden m�ssen. All das schr�nkt die Kreativit�t der Entwickler ein und istdeshalb durchaus sinnvoll, vor dem eigentlichen Entwicklungsstart zu kl�ren.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Feasibility 03000
Seite 1
Feasibility – Risikomanagement
Hier kommt der Gedanke des unternehmensweiten Risikomanagement insSpiel. Investitionen in komplett neue Fertigungsstrassen, Maschinen oder neueTechnologien k�nnen Sinn machen, belasten ein Unternehmen prim�r aberschwer. Es ist also abzuw�gen, ob dieses Risiko (Bestandsrisiko) es wert ist,getragen zu werden und ob die Hausbank oder andere dieses st�tzen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Feasibility 03100
Seite 1
Feasibility oder Machbarkeitsuntersuchung vor demeigentlichen Entwicklungsstart
1 Definition und Zeitliche Einordnung
Wann haben Sie zuletzt etwas ausprobiert? Gerade gesternAbend: Ob das Auto vielleicht doch in diese enge Parkl�ckepasst? Oder ob Sie ein zweites Dessert ohne Bauchschmerzengenießen k�nnen? Diese Art von Machbarkeitsuntersuchun-gen kennen wir alle aus dem t�glichen Leben. F�r die Ent-wicklung von Medizinprodukten stellt sich die Untersuchungder Machbarkeit (engl.: feasibility study) in der Regel etwaskomplexer dar. Nichts desto weniger stellen sich dabei diegleichen Fragen:
„Geht das?“, „Wie geht das?“ und „Warum geht das nicht?“.
Neue Ideen f�r innovative Medizinproduk-te werfen die Frage auf, ob und wie eineProduktidee realisiert werden kann. DieAntwort auf diese Frage findet man, indemman die Machbarkeit der Produktidee un-tersucht. In dieser Machbarkeitsuntersu-chung (engl.: feasibility study) wird dieGrundlage f�r ein erfolgreiches, sicheresund rentables Medizinprodukt gelegt. Indiesem Kapitel finden Sie neben einer De-finition und der zeitlichen Einordnung imEntwicklungsprozess auch Hinweise auf
typische Fragen und zur optimalen Durch-f�hrung der Machbarkeitsuntersuchung.
Arbeitshilfen:
• Vorlage f�r Entwicklungsdokumenta-tion
• Vorlage f�r Testdokumentation
Autor: Alexander FinkE-Mail: [email protected]
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Feasibility (Machbarkeit) 03101
Seite 1
Entwicklungsplan – Inhalt
04000 Entwicklungsplan
04100 Risikomanagement
04101 Festlegung der Bewertungskriterien f�r denRisikomanagementplanDirk B�chel, Martin Scherrer, Ulrich Matern
04200 Usability
04300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
04
Seite 1
Entwicklungsplan
Ist die Entscheidung f�r den Start des Entwicklungsprojektes gefallen, ist essp�testens Zeit, das Projekt entsprechend inhaltlich zu planen. Dabei geht esnicht nur um die Zeit, das einzusetzende Team, die m�glichen Kosten, sondernauch darum, das Marketing, die Marketingaktivit�ten und die Zulassungsmo-dalit�ten (CE-Kennzeichnung bzw. Konformit�tsbewertungsverfahren) miteinzutakten.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsplan 04000
Seite 1
Entwicklungsplan – Risikomanagement
F�r den Bereich des Risikomanagements geht es in dieser Phase darum fest-zulegen, wer in welcher Entwicklungsphase Teil des Risikomanagement-Teamsist. Die Rechte und Pflichten der Teilnehmer m�ssen festgelegt werden. DieRisikophilosophie, die Akzeptanzkriterien etc. m�ssen definiert und mit derUnternehmens- bzw. Qualit�tsphilosophie abgestimmt werden, kurz der Risi-komanagementplan muss verabschiedet werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsplan 04100
Seite 1
Festlegung der Bewertungskriterien f�r denRisikomanagementplan
1 Vorwort
Risikomanagement ist seit einigen Jahren in der Medizin-produkteindustrie etabliert, wenngleich es oft noch nicht ent-wicklungsbegleitend durchgef�hrt wird. Oft ist das Festlegender Akzeptanzkriterien eine große Herausforderung f�r dieHersteller, wobei doch genau dieses f�r die sp�tere Erteilungder Marktreife entscheidend ist. Diese Definition der Ak-zeptanzkriterien f�r das individuelle Medizinprodukt soll indiesem Kapitel das Thema sein.
2 Gesetzliche Grundlage
F�r Medizinprodukte legt auf europ�ischer Ebene die Medi-zinprodukterichtlinie (92/93/EWG) resp. die EU-Richtlinie98/79/EWG, f�r In-vitro-Diagnostik und f�r aktive implan-tierbare medizinische Ger�te die EU-Richtlinie 90/385/EWGdie Voraussetzungen f�r medizinische Ger�te fest. Im Zugeder Umsetzung europ�ischer Rechtsvorschriften in nationalesRecht wurde in Deutschland die EU-Richtlinie in Form desMedizinproduktegesetzes (MPG) �bertragen.
Dieses Kapitel beschreibt das Vorgehenzur Risikobewertung und der vorangehen-den Definition der Akzeptanzkriterien imRisikomanagement eines Medizinproduk-teherstellers. Es werden Elemente derGebrauchstauglichkeit eingebunden.
Autoren: Dirk B�chelMartin ScherrerUlrich Matern
E-Mail: [email protected]@[email protected]
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsplan 04101
Seite 1
Entwicklungsplan – Usability
Das Usability-Team plant in dieser Phase die zeitliche und inhaltliche Durch-f�hrung von Usability-Maßnahmen mit und ohne Nutzerbeteiligung. Das be-inhaltet eine Auflistung der in den Studien zu untersuchenden Fragestellungenund Beschreibung der Rekrutierungskriterien f�r die Testpersonen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsplan 04200
Seite 1
Entwicklungsplan – Klinische Bewertung
Je nach regulatorischen Anforderungen an das zuk�nftige Medizinprodukt oderals Ergebnis der Literaturrecherche f�r die klinische Bewertung sind klinischeStudien zur Erlangung der CE-Kennzeichnung erforderlich. Aber auch aus an-deren Gr�nden werden immer h�ufiger klinische Studien geplant, z. B. f�rMarketingstrategien.
Daher ist es ist wichtig, fr�hzeitig klinische Experten in das Planungsteam zuinvolvieren. Diese mit der t�glichen Patientenversorgung vertrauten Fachleutek�nnen zu einer erfolgreichen und reibungslosen Durchf�hrung einer klinischenPr�fung erheblich beitragen. Allein die Planungsphase einer klinischen Pr�fungist komplex und dauert viele Monate. Auch eine Absch�tzung der Kosten solltehier erfolgen.
Auch die Frage der Erstattungsf�higkeit und damit die Eintragung in dieHilfsmittelliste u.�. ist in dieser Phase zu kl�ren; eventuell n�tige zus�tzlichePr�fungen sind einzuplanen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsplan 04300
Seite 1
Lastenheft – Inhalt
05000 Lastenheft
05100 Risikomanagement
05101 Das Lastenheft – Pflicht und K�r, aber dokumentiert!J�rg Stockhardt
05102 Gewerbliche SchutzrechteHenrik Holzapfel
05200 Usability
05201 Lastenheft – die Last mit den LastenAlexander Fink, Ulrike Kamecke
05300 Klinische Bewertung
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
05
Seite 1
Lastenheft
Diese Phase der Entwicklung steht nun ganz im Lichte der m�glichen Anwenderbzw. der behandelten / versorgten Patienten. Aus Sicht dieser Anwender werdennun das Produkt und dessen Anwendung definiert. Am Besten unter Zuhilfe-nahme von realen Anwendern werden die Anwenderanforderungen definiertund unter Ber�cksichtigung der rechtlichen Anforderungen fixiert.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05000
Seite 1
Lastenheft – Risikomanagement
Das hier entstehende Lastenheft zeichnet sich dadurch aus, dass es noch kei-nerlei technische Umsetzung enthalten muss, und genau das ist die St�rke desRisikomanagements in dieser Phase. Anhand der bereits vordefinierten Haupt-funktionen k�nnen jetzt und hier die m�glichen unterschiedlichen Realisie-rungsarten, technische L�sungen, Produktionsmethoden etc. subjektiv im Ri-sikomanagement miteinander verglichen werden. Nat�rlich werden die Ein-schr�nkungen der Feasibility-Phase ber�cksichtigt, aber mit relativ geringemAufwand kann hier eine echte, wenngleich subjektive Vorauswahl erfolgen unddamit der Entwicklungsaufwand reduziert werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05100
Seite 1
Das Lastenheft – Pflicht und K�r, aber dokumentiert!
1 Wieso eigentlich Lastenheft?
Welchem strukturierten Entwicklungsmodell (in Abbildung 1sehen Sie das V-Modell) ein Unternehmen auch folgt, immerwird an der Schnittstelle zwischen Forschung und Entwick-lung die Definition der Produktidee n�tig (Kap. 02000 Pro-duktidee) und, daraus abgeleitet, eine anwenderinduzierteBeschreibung der Funktionalit�t und des gew�nschten Nut-zens des Produktes.
Dieses beinhaltet auf jeden Fall die von der Rechtslage sobenannte Zweckbestimmung bzw. die Bestimmungsgem�ßeVerwendung.
Auch das in den USA �blicherweise nach Design ControlGuidance for Medical Device Manufacturers von 1997 [1]angewandte, strukturierte Entwicklungsverfahren nach demWasserfall-Modell (Abbildung 2), fordert diese Umsetzungder ,Customer Requirements’ in den ,Intended Use’.
Das erste regulatorisch erwartete inhalt-liche Entwicklungsdokument ist das Las-tenheft. In diesem soll sich der Kunden-wunsch wiederfinden.
Doch was will der Kunde und was ist nebendem Kundenwunsch noch Pflicht? Sindauch andere Informationen interessantund sinnvoll?
Dieser Beitrag zeigt Inhalte des Lasten-heftes auf und gibt Hilfen, wie Sie zu die-sen Daten kommen.
Arbeitshilfe:
• Formular Lastenheft
Autor: J�rg StockhardtE-Mail: stockhardt@consultingand-
more.com
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05101
Seite 1
Gewerbliche Schutzrechte
1 �berblick
Gewerbliche Schutzrechte sind Verbietungsrechte. Das heißt:Der Inhaber eines Schutzrechts kann Dritten alle Handlungenverbieten, bei denen sein Schutzrecht benutzt wird. Das Ver-bot kann mithilfe der Gerichte durchgesetzt werden. Siek�nnen gewerbliche Schutzrechte also dazu benutzen, dasInverkehrbringen oder den Betrieb des Medizinprodukts einesanderen zu verhindern.
Gewerbliche Schutzrechte sind kein unmittelbarer Bestandteildes CE-Kennzeichnungsverfahrens. Weder muss Ihr Unter-nehmen �ber eigene Schutzrechte verf�gen, damit ein Medi-zinprodukt in den Verkehr gebracht werden kann, noch wirdbei der Zertifizierung gepr�ft, ob Ihr MedizinproduktSchutzrechte Dritter verletzt. Dennoch sollten Sie gewerbli-che Schutzrechte bereits bei der Planung und Entwicklungeines Medizinprodukts ber�cksichtigen. Insbesondere solltenSie vermeiden, dass Ihr Produkt Schutzrechte Dritterverletzt. Denn die Investitionen Ihres Unternehmens in einneues Produkt werden wertlos, wenn dieses Produkt sp�ternicht in den Verkehr gebracht werden kann, weil ein Wettbe-
Gewerbliche Schutzrechte (z. B. Patente)k�nnen der Vermarktung eines Medizin-produkts entgegenstehen.
Was sollten Sie bereits bei Planung undEntwicklung eines Produkts beachten, umeine Verletzung fremder Schutzrechte zuvermeiden? Wie k�nnen Sie ggf. den Er-
werb eigener Schutzrechte sichern? Wassollten Sie bei der �bertragung oder Li-zenzierung von Schutzrechten beachten?
Autor: Henrik HolzapfelE-Mail: henrik.holzapfel@ -
gleisslutz.com
Verbietungs-rechte
Relevantf�r F&E
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05102
Seite 1
Lastenheft – Usability
Der Beitrag des Usability-Teams besteht in dieser Phase in der Formulierung derUser Interface Requirements. Diese k�nnen auch mit Nutzerbeteiligung be-schrieben werden. So k�nnen zum Beispiel k�nftige Anwender in einer Fokus-gruppe zur Ausf�hrung der Hauptbedienfunktionen im Rahmen des Ger�te-konzeptes befragt werden. Die Anforderungen an die Benutzer-Ger�t-Schnitt-stelle werden letztendlich in der Form von expliziten Designspezifikationenausgedr�ckt, die subjektive oder objektive Leistungsmaße beinhalten k�nnen.Die Designspezifikationen werden deshalb als Unterdokument des Design undder Implementierung der Benutzer-Ger�t-Schnittstelle verstanden. Genauso wiedie Functional Specification als Beschreibung aller funktionalen Anforderun-gen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05200
Seite 1
Lastenheft – die Last mit den Lasten
1 Was ist ein Lastenheft?
Nach Definition ist das Lastenheft die Beschreibung allerForderungen des Auftraggebers an Lieferung und Leistungdes Auftragnehmers. Diese Definition ist der DIN 69901-5„Projektmanagementsysteme – Begriffe“ entnommen. ImLastenheft legt also der Auftraggeber dar, was er als Ender-gebnis vom Auftragnehmer erwartet. Dabei k�nnen Auftrag-geber und Auftragnehmer sowohl verschiedene Unternehmen(Beauftragung externer Entwicklungsdienstleister), als auchverschiedene Personen innerhalb eines Unternehmens sein(Gesch�ftsf�hrung als Auftraggeber und Entwicklungsabtei-lung als Auftragnehmer).
Nach dieser Definition ist das Lastenheft eine Art Versiche-rung, dass am Ende das vom Auftraggeber gew�nschte Er-gebnis erzielt wird und der Auftragnehmer – sofern er alle imLastenheft aufgef�hrten Forderungen erf�llt – keine Re-gressforderungen des Auftraggebers f�rchten muss. Und wie
Das Lastenheft enth�lt die gesamten An-forderungen, die der Auftraggeber an dasneue Medizinprodukt stellt . Dieses Kapi-tel liefert Ihnen die grundlegenden Infor-mationen zum Erstellen eines Lastenhefts:Sie erhalten Argumente und Hinweise zuZweck und Inhalt des Lastenhefts. Au-ßerdem finden Sie Informationen zur Vor-gehensweise bei der Erstellung und denFormalien, die Sie beim fertigen Doku-ment beachten sollten. Dabei werdenauch die verschiedenen Sichtweisen des
Auftraggebers und des Auftragnehmersdargestellt.
Arbeitshilfe:
• Vorlage Lastenheft
Autoren: Alexander FinkUlrike Kamecke
E-Mail: [email protected]@metecon.de
BeschreibungallerForderungen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 1
beim Abschluss einer Versicherung ist es auch beim Lasten-heft ratsam, auf die Details zu achten und sich dar�ber zuverst�ndigen, ob beide Seiten in jedem Punkt das gleicheVerst�ndnis haben.
Man k�nnte sagen, das Lastenheft dient dazu, Streit und teureFehlentwicklungen zu verhindern. Weit dar�ber hinaus bietetder Erstellungsprozess des Lastenhefts aber auch die Chance,ein umfassendes Bild der Ideen und W�nsche aller Stake-holder des Produkts in die Entwicklung einfließen zu lassenund so ein optimales Produkt zu beschreiben und nachfolgendauch zu realisieren.
2 Braucht man ein Lastenheft?
Ein Lastenheft zu erstellen macht Arbeit. Und je nach demwie groß das Projekt ist, ist es auch richtig viel Arbeit, die daauf Sie wartet. Da ist die Versuchung f�r den Auftraggebernat�rlich groß, diesen Aufwand auf den Auftragnehmer zu�bertragen: Ein kurzes Briefing von Seiten des Herstellersund der Auftragnehmer soll kreativ werden und die Kosten f�rdas Lastenheft mit ins Angebot aufnehmen. Damit tun Sie alsHersteller– wenn �berhaupt jemandem – nur dem Auftrag-nehmer einen Gefallen, denn dieser kann Ihnen nun anbieten,was er gerne liefern m�chte. Ihrem Projekt und sich selbstschaden Sie damit eher. Warum eigentlich? Welchen Vorteilhaben Hersteller davon, das Lastenheft selbst zu erstellen?Die folgende Liste will darauf einige Antworten liefern.
• Die Kontrolle bleibt beim Hersteller! Sie entscheiden,welche Anforderungen unbedingt (must have oder need tohave) und welche nur eventuell (nice to have) erf�llt wer-den m�ssen.
Bild allerIdeen undW�nsche
Lastenheftselbst erstellen
Vorteile
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 2
• Sie reduzieren die Kosten, indem Sie �berfl�ssige Leis-tungen identifizieren, f�r die es einfache interne L�sungengibt.
• Nach dem Erstellen des Lastenhefts wissen Sie ganz ge-nau, was Sie haben wollen. Das st�rkt Ihre Position inGespr�chen und Verhandlungen nicht nur mit den Anbie-tern, sondern auch innerhalb Ihres Unternehmens.
• Es f�llt Ihnen leicht, alle Fragen der Auftragnehmer zubeantworten, da sich die Antworten aus dem Lastenheftergeben und Sie sich eingehend mit dem Thema ausein-ander gesetzt haben.
• Sie erhalten besser vergleichbare Angebote und reduzie-ren damit den Aufwand bei der Auswahl des Anbieters.
• Sie haben mehr Planungssicherheit, da Sie detaillierteAngebote bekommen und weniger Nachforderungen f�rvorher nicht vereinbarte Leistungen f�rchten m�ssen.
Eine ganze Reihe von guten Gr�nden, ein Lastenheft zuschreiben. Und so wie es sich beim Bauen eines Hauses nichtlohnt, am Fundament zu sparen, so ist ein gutes Lastenhefteine hervorragende Grundlage f�r den Erfolg des Entwick-lungsprojekts. Umgekehrt gilt auch, dass sich Misserfolge inEntwicklungsprojekten sehr oft auf eine schlechte Spezifi-kation der geforderten Leistungen zur�ckf�hren lassen.
3 Wie wird ein Lastenheft erstellt?
F�r die Erstellung des Lastenhefts gibt es verschiedene Vor-gehensweisen. Welche der im Folgenden beschriebenen An-s�tze Sie bevorzugen, h�ngt von der Unternehmensphiloso-phie und Ihren eigenen Erfahrungen und Pr�ferenzen ab. Eslohnt sich jedoch, die verschiedenen Ans�tze auszuprobieren,um selbst ein Gef�hl daf�r zu bekommen, welche Vorge-
VerschiedeneVorgehens-weisen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 3
hensweise am besten zu den eigenen Problemstellungen undzum eigenen Umfeld passt.
�bergreifend f�r alle drei Herangehensweisen sollten Siefolgendes ber�cksichtigen:
• Die an der Erstellung beteiligten Personen m�ssen dieFach- und Aufgabenkompetenz f�r den von ihnen vertre-tenen Bereich haben; dabei sollten diese Personen ihrenjeweiligen Kompetenzbereich nach M�glichkeit auch nurkontrolliert �berschreiten. So ist es beispielsweise ratsam,dass der Marketingspezialist sich auf die Anforderungenaus Marketingsicht beschr�nkt und die Entwicklungsin-genieurin bei den technischen L�sungen bleibt. In kleinenUnternehmen sind diese Aufgabenbereiche freilich nichtimmer ganz klar zu trennen.
• Die Anforderungen an das Produkt sollten problembezo-gen formuliert werden, die L�sung bleibt offen. So k�nntez. B. die Anforderung f�r einen elektrischen Rasierapparatlauten „Der Nutzer soll sich ohne Hautreizungen rasierenk�nnen.“ Diese Formulierung beschreibt das Problem undl�sst die L�sung weitgehend offen. Schlechter w�re dieFormulierung „Die Kontaktfl�che des Rasierapparatessollte m�glichst glatt sein, um Hautreizungen zu verhin-dern.“ Die Absicht ist hier die gleiche (Hautreizung ver-meiden), es wird aber schon eine L�sung vorgegeben.
3.1 Im Einzelinterview
Eine M�glichkeit, die Produktanforderungen zu sammeln, istdas Einzelinterview mit den verschiedenen Nutzer- und In-teressengruppen. Dabei befragen Sie als Autor des Lasten-hefts alle Personen, die einen konstruktiven Beitrag zu denProduktanforderungen liefern k�nnen. Der Fokus liegt dabeiauf der Befragung der Nutzer des Produkts.
Anforderungenohne L�sungformulieren
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 4
Der Interviewer versucht dabei, den Nutzer durch gezielteFragen in den Kontext der Benutzung zu versetzen (Kontext-interview). Dadurch werden idealerweise die Ziele der je-weiligen Handlungen des Nutzers herausgearbeitet und we-niger die Handlungsschritte der derzeitigen oder zuk�nftigenProbleml�sung beschrieben. Die Kunst f�r Sie als Interviewerliegt nun darin, sich von der L�sung – also dem Gedanken andas Produkt – zu befreien und ausschließlich �ber das Pro-blem bzw. die Aufgabe zu sprechen. Dabei helfen Ihnen of-fene Fragen (Wie? Warum?). Am Beispiel des Rasierapparatsk�nnte das Interview bspw. so ablaufen:
Nutzer: „Und dann m�sste der Rasierapparat auch richtigglatt sein.“ Interviewer: „Warum m�sste erdas sein?“ Nutzer:„Naja, damit die Haut nicht so gereizt wird und es nicht sobrennt“ Interviewer: „Sie haben also Probleme mit der Hautnach dem Rasieren?“ Nutzer: „Ja, ziemlich.“ Interviewer:„Und Sie w�rden sich w�nschen, dass Sie einen Rasierappa-rat finden, bei dem Sie weniger oder gar keine Hautproblemebeim Rasieren haben?“ Nutzer: „Ja, nat�rlich.“
Aus dieser Passage kann man nun die Anforderung „Rasierersoll Hautreizungen vermeiden“ herausfiltern. Ohne die ex-plizite Nachfrage des Interviewers w�re die Anforderung„Rasierer muss glatt sein“ in das Lastenheft eingeflossen unddie Produktanforderung w�re verf�lscht gewesen bzw. derL�sungsraum f�r die Entwickler w�re stark eingeschr�nktworden.
Solche Interviews k�nnen Sie auch mit anderen Stakeholderndes Entwicklungsprojekts f�hren. Diese Produktanforderun-gen erg�nzen dann die zentralen Anforderungen des Nutzers(z. B.: Gesch�ftsf�hrung: „Renditeziel erreichen“; Reklama-tionsbearbeitung: „Nicht mehr so viele w�tende Anrufer“;Marketing: „Muss ins Corporate Design passen“; ...).
Den Ideenfreien Lauf
Beispiel
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 5
3.2 In Gruppendiskussion
Die Gruppendiskussion ist eine weitere Organisationsform,die f�r die Durchf�hrung von Nutzerbefragungen angewendetwerden kann.
Ein offensichtlicher Vorteil der Gruppendiskussion liegt f�rSie darin, dass sich neue Ideen und Sichtweisen aus der Dis-kussion neue Ideen und Sichtweisen ergeben, die sich positivauf die Gestaltung des Produkts auswirken. Nachteil derGruppendiskussion ist, dass weniger extrovertierte Teilneh-mer leicht �bergangen werden und so eventuell wichtigeMeinungen und Informationen verloren gehen.
Wenn Sie sich f�r die Gruppendiskussion entscheiden, solltenSie bei der Einladung der Teilnehmer auf die Zusammenset-zung achten. Dabei spielen sicherlich auch firmenpolitischeund soziale Aspekte eine Rolle. Wenn von vornherein klar ist,dass die Diskussionsrunde dazu genutzt werden wird, Gra-benk�mpfe zwischen verschiedenen Abteilungen auszufech-ten, kann man sich die M�he getrost sparen und sollte zu eineranderen Organisationsform wechseln. Denn den Aufwand,zun�chst die Termine von mehreren Personen abzustimmenund dann eine Gruppendiskussion so zu leiten und zu proto-kollieren, dass hinterher verwertbare Ergebnisse herauskom-men, sollten Sie nicht untersch�tzen.
Wenn aber die „richtigen“ Personen in kreativer Atmosph�remit einem guten Diskussionsleiter zusammenkommen, kanndie Gruppendiskussion fantastische Ergebnisse liefern.
Diese Methode wird �blicherweise von Usability-Dienstleis-tern benutzt, um in der Analysephase das Anforderungsprofilf�r die Usability zu entwickeln, z. B. Hauptbedienfunktionen
Neue Ideenund Sicht-weisen
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 6
(Primary Operating Functions – POF), Nutzungskontextana-lyse, etc.
3.3 Autoren/Herausgeber-Prinzip
Es ist auch m�glich, einen Herausgeber des Lastenhefts damitzu beauftragen, die Anforderungen verschiedener Autorenzusammenzutragen und in einem Lastenheft zusammen zustellen. Dabei formulieren die jeweiligen Autoren ihre An-forderungen an das Produkt. Der Herausgeber sichtet alleBeitr�ge und verfasst daraus die Punkte des Lastenhefts.
Die große Schw�che des Autoren/Herausgeber-Prinzips: ImVergleich zu den vorgenannten Herangehensweisen agierendie einzelnen Autoren ohne Diskussionspartner. Im Tagesge-sch�ft erfordert es schon ein hohes Maß an Disziplin, sich dieZeit zu nehmen, ausf�hrlich alleine �ber die eigenen Ideenund eventuell neue Produktanforderungen nachzudenken unddiese zu notieren. Die Wahrscheinlichkeit ist also groß, dassdie Autoren schnell die wichtigsten Punkte zusammen-schreiben, um sich wieder z�gig ihrem Tagesgesch�ft widmenzu k�nnen. Wirklich neue und kreative Ans�tze sollten Sie beidieser Vorgehensweise nicht erwarten.
Ein weiterer Nachteil dieses Ansatzes ist die Notwendigkeitder Interpretation durch den Herausgeber. Dieser muss ent-scheiden, ob die Anforderungen der verschiedenen Autorenso �hnlich sind, dass sie zu einem Punkt zusammengefasstwerden k�nnen oder nicht. Dabei fließt in das Lastenheft sehrstark die Sichtweise der Person des Herausgebers mit ein undes besteht die Gefahr, dass wichtige Aspekte der Autorenverloren gehen.
Schw�che
Subjektiv
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 7
4 Was steht in einem Lastenheft?
Was tats�chlich in einem Lastenheft steht, entscheidet letzt-endlich der Auftraggeber. Geht es nach ihm, sollen Umfangund Aufwand �berschaubar bleiben. Aus Auftragnehmersichtkann das Lastenheft wiederum gar nicht ausf�hrlich genugsein.
Um die L�cke zwischen dem, was der Auftraggeber in dasLastenheft schreibt und dem, was der Auftragnehmer gernealles erfahren m�chte, m�glichst klein zu halten, kann mansich als Autor an hilfreichen Strukturen orientieren. Im Fol-genden stelle ich Ihnen eine m�gliche Struktur f�r Inhalt undGliederung eines Lastenhefts dar. Auf der CD-ROM findenSie ein Gliederungsbeispiel f�r ein Lastenheft als Word-Dateibeigef�gt.
4.1 Einf�hrung
Der Auftraggeber hat �blicherweise alle Informationen rundum sein angestrebtes Produkt. Er weiß um die Historie undden Weg, der zu der Produktidee gef�hrt hat; er kennt dieZiele, das Umfeld und das Unternehmen. Der Auftragnehmerweiß im schlechtesten (aber h�ufigen) Fall nichts davon!
Es ist daher ratsam, am Anfang des Lastenhefts all diese In-formationen f�r den Auftragnehmer so zusammenzustellen,dass dieser sich ein Bild von der Gesamtsituation machenkann.
• Was ist das Kerngesch�ft des Unternehmens bzw. dieHauptaufgabe des Auftraggebers?
• Wie ist die Ausgangssituation? Gibt es bspw. schon einVorg�ngerprodukt?
05201_a.doc
Wichtig:Ausf�hrlichesBriefing
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 8
• Warum m�chte man das Produkt?
• Was ist das Gesamtziel des Projekts, z. B. einen neuenMarkt erschließen oder ein bestehendes System abl�sen?
Dieses Kapitel des Lastenhefts soll dem Auftragnehmer eintieferes Verst�ndnis f�r die Situation und die Motivation desAuftraggebers erm�glichen. Diese Informationen sind f�r denAuftragnehmer bei der Erstellung des Pflichtenhefts wichtig,um nach M�glichkeit die optimalen L�sungswege f�r dieRealisierung der Anforderungen auszuw�hlen. Je ausf�hrli-cher Sie den Auftragnehmer informieren, desto gr�ßer ist f�rSie die Chance, kreative und gute L�sungen zu erhalten.
4.2 Beschreibung der Einsatzbedingungen
Um die sp�tere Beschreibung von Funktion und Anwendungdes Produkts verstehen zu k�nnen, ist es wichtig, dass derAuftragnehmer die Einsatzbedingungen des Produkts bzw.die Randbedingungen des Projekts kennenlernt.
Dieser Teil des Lastenhefts ist eng verbunden mit der Nut-zungskontextanalyse, die Teil der Analysephase f�r dieUsability-Betrachtungen ist. Hier werden dem Auftragneh-mer die unmittelbaren Umst�nde der Anwendung und desEinsatzes des Produkts vermittelt. Dabei sollten u. a. folgendeFragen m�glichst klar beantwortet werden:
• Was sind die Umgebungsbedingungen f�r den EinsatzIhres Produktes oder den Ablauf Ihres Projekts?Darunter fallen Angaben, die direkt mit dem Ger�t undden verwendeten Bauteilen in Verbindung stehen, wiez. B.:
– die Feuchtigkeit,
Nutzungs-kontext-analyse
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 9
– die Temperatur (Temperaturbereich, konstant oderver�nderlich),
– die Beweglichkeit (portabel oder ortsfest),
aber auch Angaben, die eher mit dem Anwender verbun-den sind, wie z. B.:
– die Beleuchtungssituation (Tages- oder Kunstlicht),
– die Lautst�rke der Umgebungsger�usche.
• Wird das Produkt alleine oder in Verbindung mit anderenProdukten angewendet?
• Welche Personen benutzen das Produkt? Wie ist der Aus-bildungsstand der Benutzer? Gibt es verschiedene odernur eine Nutzergruppe?
• Sind die Randbedingungen im gesamten Vertriebsgebietgleich?Durch unterschiedliche gesetzliche Rahmenbedingungenoder Verhaltensweisen der Nutzer k�nnen sich trotz glei-cher Anwendung regional verschiedene Anforderungen andas Produkt ergeben. So kann es auch innerhalb Europaszu unterschiedlichen Nutzungsszenarien f�r das gleicheProdukt kommen.
4.3 Funktionale Anforderungen
Unter den funktionalen Anforderungen versteht man alleAnforderungen, die die Funktion des Produkts betreffen. Dasklingt zun�chst einmal trivial. Und zugegebenermaßen ist esauch nicht schwierig zu erkl�ren, was Sie in diesem Kapiteldes Lastenhefts darstellen sollten. Im Prinzip geht es um vierDinge:
• Die Funktionen, die das Produkt unbedingt haben muss;
• Die Funktionen, die das Produkt nach M�glichkeit zu-s�tzlich haben sollte;
FunktionennachPriorit�ten
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 10
• Die Funktionen, die das Produkt nicht haben muss aberokay sind, wenn sie nicht st�ren oder mehr Aufwand er-fordern;
• Die Funktionen, die das Produkt auf keinen Fall haben solloder darf.
Die Einteilung der Funktionen nach Priorit�ten f�r die Rea-lisierung ist nicht nur hilfreich, sondern fast zwingend. Nurwenn der Auftragnehmer auch diese Informationen hat, kanner das Pflichtenheft und sein Angebot passend erstellen.
Aus unserer Erfahrung gibt es zwei Schwierigkeiten beimSammeln und Darstellen der Funktionen. Zum einen ist dasdie Tatsache, dass die Stakeholder meistens ziemlich genauwissen, was sie wollen, aber seltener, was sie nicht wollen.Zum anderen wird es mit steigender Anzahl der Stakeholderzunehmend schwieriger, eine Einigung �ber die Priorit�ten zuerzielen.
4.4 Nicht-funktionale Anforderungen
Unter den nicht-funktionalen Anforderungen versteht mandie Anforderungen, die sich nicht direkt auf die Anwendungdes Produkts beziehen. Darunter fallen neben anderen bei-spielsweise die wirtschaftlichen Anforderungen, die an dasProdukt gestellt werden (z. B.: „Soll im Einkauf nicht mehr als10,00 Euro kosten“) oder die Forderungen des Marketing(z. B.: „Muss farblich ins Corporate Design passen.“).
Wenn Sie bei der Informationsgewinnung f�r die Erstellungdes Lastenhefts alle Stakeholder miteinbezogen haben, soll-ten Sie die Informationen f�r die nicht-funktionalen Anfor-derungen bereits vorliegen haben. In den meisten F�llen liegtdie Unterscheidung zwischen funktional und nicht-funktionalklar auf der Hand. Manchmal ist aber auch schwierig zu ent-
Beziehen sichnicht direktauf dieAnwendung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 11
scheiden, ob eine Anforderung nun funktional odernicht-funktional ist. Es schadet in diesen F�llen nicht, wennSie die jeweiligen Aspekte in beiden Kapiteln darstellen.
Die folgende �bersicht z�hlt beispielhaft einige nicht-funk-tionale Anforderungen auf:
• Regulatorische Anforderungen
– Richtlinien
– Gesetze
– Normen
– Unternehmensinterne Verfahrensanweisungen (z. B.Validierungsvorschriften).
• Wirtschaftliche Anforderungen
– Herstellkosten
– Zuverl�ssigkeit und Lebensdauer
– Ausschluss der Verwendung von Zubeh�r andererHersteller
• Marketing
– Corporate Design
– Kleiner, sch�ner, hochwertiger als Wettbewerbspro-dukt.
4.5 Schnittstellen
Den Schnittstellen sollte bei den �berlegungen zum Lasten-heft ganz besonderes Augenmerk geschenkt werden. Dennerfolgreich wird Ihre Produktentwicklung nur dann, wenn Siees schaffen, aus den Schnittstellen Verbindungsstellen zumachen. Bei einer Produktentwicklung m�ssen zwei ganzunterschiedliche Arten von Schnittstellen betrachtet werden.
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 12
Einmal die technischen Schnittstellen Ihres Produkts und zumanderen die Schnittstellen im Projekt.
Zu den technischen Schnittstellen z�hlen u. a. die Schnitt-stellen zu anderen Ger�ten und Systemen und die zum Be-nutzer (Usability). Bei Medizinprodukten gibt es naturgem�ßauch h�ufig noch eine Schnittstelle zum Patienten.
Die Projektschnittstellen sind einmal fachlich und einmalzeitlich gegeben. Die zeitlichen Schnittstellen ergeben sichaus dem Projektplan und treten beispielsweise dann auf, wennan einem Meilenstein ein Ergebnis an andere Mitglieder desProjektteams �bergeben werden. Die fachlichen Schnittstel-len ergeben sich aus der Zusammensetzung des Projekts undder Zusammenarbeit der unterschiedlichen Fachleute.
Technische Schnittstellen bestehen bspw.:
• zu anderen Produkten, mit denen zusammen das Produktverwendet wird (z. B. Zubeh�r, Fremdprodukt);
• zur Haustechnik, wenn das Produkt z. B. an das Stromnetzangeschlossen wird;
• zu anderer Software, wenn bspw. Daten an eine zentraleDatenbank �bergeben werden sollen;
• zum Anwender, der das Produkt handhaben muss;
• zum Patienten, der mit dem Produkt in Ber�hrung kommt.
Die technischen Schnittstellen sind oftmals durch Standardsdefiniert (230V/50Hz, USB-BUS, Bluetooth-Protokoll, etc.).Wo diese Standards nicht greifen, m�ssen die Parteien beid-seits der Schnittstelle eine L�sung vereinbaren und auch dieVerantwortlichkeiten kl�ren. An dieser Stelle geht die tech-nische Schnittstelle oft in eine organisatorische Schnittstelle�ber.
TechnischeSchnittstellen
ZeitlicheSchnittstellen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 13
In der folgenden Aufz�hlung sind einige typische organisa-torische oder Projektschnittstellen bei der Entwicklung ei-nes Medizinprodukts aufgef�hrt:
• zwischen Fachabteilungen (bspw. elektronische Hardwareund Mechanik);
• zu externen Lieferanten und Entwicklungspartnern;
• zur Benannten Stelle;
• zu klinischen Pr�fzentren.
4.6 Abnahme
Gerade in der Zusammenarbeit mit anderen Firmen und Zu-lieferern sollte der Hersteller im Lastenheft auch Abnahme-kriterien definieren. Dabei sollten nicht nur die Kriterienaufgef�hrt werden, die Sie unbedingt erwarten. Es sollte auchdefiniert sein, wie der Auftragnehmer nachweisen muss, dasser die Kriterien des Lastenhefts erf�llt. Sonst hat leicht derAuftrageber den „Schwarzen Peter“, nachzuweisen, dass zu-gesicherte Leistungen vom Lieferanten nicht erf�llt wurden.
4.7 Formalien
Wenn Sie in einem zertifizierten Unternehmen arbeiten,k�nnen Sie die Formalien f�r die Erstellung des Lastenheftssehr wahrscheinlich den internen Verfahrensanweisungenoder dem Qualit�tsmanagement-Handbuch entnehmen. DieFormalien f�r das Lastenheft sind zumeist �berschaubar undschnell aufgez�hlt:
• In der Regel hat das Lastenheft ein Deckblatt, auf dem derName des Projekts und die Firmenbezeichnung und-adresse des Auftraggebers angegeben sind.
InterneVerfahrens-anweisungen
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
05201 Lastenheft
Seite 14
• Nach dem Deckblatt folgt eine Seite zur Dokumenten-verfolgung. Darauf sind der Autor und die Pr�fer bzw. diePersonen, die das Lastenheft letztendlich freigeben, auf-gef�hrt. Es sollte außerdem auch Platz f�r Datum undUnterschrift dieser Personen vorhanden sein. Des weiterensollten die Revisionsnummer des Dokuments und die�nderung zum vorherigen Revisionsstand ersichtlich sein.
• Legen Sie ein Inhaltsverzeichnis zumindest der Kapitel-�berschriften an.
• Eine der wichtigsten Formalien – vor allem dann, wenn Siedas Lastenheft an externe Dienstleister �bergeben m�ch-ten – ist ein Glossar. Erkl�ren Sie neben wichtigen Be-griffen vor allem auch die verwendeten Abk�rzungen undAkronyme. Und seien Sie an dieser Stelle sehr ausf�hrlich;holen Sie sich eventuell auch Feedback von außen, dennoft kommt es vor, dass Begriffe innerhalb eines Unter-nehmens oder einer Abteilung ganz selbstverst�ndlichbenutzt werden, sich f�r Außenstehende aber nicht vonselbst erschließen („Ist doch klar, dass die Sensoreinheitnur bis zum XY-Plug des Adapterkabels geht und die DTUdie Data-Transfer-Unit ist!“).
5 Und wann ist es fertig?
Formal dann, wenn der f�r die Freigabe Verantwortliche seineUnterschrift auf das Dokument gesetzt hat. In der Praxissollten Sie das Lastenheft aber lebendig halten, bis der„Freeze“ f�r das Projekt unbedingt notwendig ist. In derDiskussion mit den verschiedenen Spezialisten und Liefe-ranten finden Sie eventuell neue Ideen, die f�r Ihr Produktvorteilhaft sind. Und eine richtige Verbesserung sollten Sienicht mit dem Argument abtun, dass es viel zu kompliziert sei,das Lastenheft zu �ndern und neu freizugeben.
Unterschrift
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05201
Seite 15
Lastenheft – Klinische Bewertung
Wenn f�r das Medizinprodukt eine klinische Pr�fung vorgesehen ist, wird indieser Phase von Produktentwicklern und Klinikern die Planung diskutiert.M�gliches Design oder Zielparameter der Pr�fung werden hier durchdacht.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Lastenheft 05300
Seite 1
Pflichtenheft – Inhalt
06000 Pflichtenheft
06100 Risikomanagement
06101 Anwenderzentrierte Spezifikation des Produktes imPflichtenheftArne Briest
06200 Usability
06201 Erstellung von Pflichtenheften imgebrauchstauglichkeitsorientierten EntwicklungsprozessPeter Hartung
06202 Pflichtenheft – Pflicht oder K�r?Alexander Fink
06300 Klinische Bewertung
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
06
Seite 1
Pflichtenheft
Das Lastenheft war noch ein von technischen – also messbaren – Angaben,weitgehend freies Dokument. Das Pflichtenheft soll nun all diese Anforderun-gen in entsprechende Technische Anforderungen umsetzen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06000
Seite 1
Pflichtenheft – Risikomanagement
In dieser Phase ist der Schulterschluss zwischen Usability und Risikomanage-ment besonders eng. Es werden belastbare Daten gebraucht. Diese Daten, z. B.�ber m�gliche Einschr�nkungen der Patienten und damit maximale Bedien-kr�fte o.�. m�ssen aus Erfahrung mit ,Alt-Projekten’ oder durch Usabili-ty-Methoden gewonnen werden. Das Risikomanagement hilft hier, die richtigenParameter f�r die Absch�tzung von m�glichen Gef�hrdungen und deren Ursa-chen zu definieren. Sp�testens in dieser Phase sollten auch die Module festge-legt werden, aus denen das Produkt aufgebaut werden soll.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06100
Seite 1
Anwenderzentrierte Spezifikation des Produktes imPflichtenheft
1 Einf�hrung
Das zentrale und wichtigste Kommunikationswerkzeug jedesEntwicklungsprojektes ist die Spezifikation des Produktes imPflichtenheft. Ein effektives Pflichtenheft fokussiert die Be-m�hungen aller Projektteammitglieder aus Marketing, For-schung und Entwicklung, Produktion, Zulassung und klini-sche Forschung, die durch die zuk�nftigen Anwender ge-setzten Erwartungen an das Produkt zu erf�llen. DasPflichtenheft beschreibt f�r das Projektteam den Marktbedarfund die Anwendererwartungen an das zu entwickelnde Pro-dukt. Es beschreibt die Anwenderanforderungen ohne vor-weggenommene Bewertungen und so die Ausrichtung derProduktentwicklung. Es zeigt zentrale und weniger zentraleAnwenderforderungen auf und bietet somit Raum f�r ver-schiedene Produktkonzepte. Das Team erstellt das Pflichten-heft gemeinsam mit den Anwendern und bewertet die Wett-bewerbsf�higkeit, das Risiko-/Nutzenpotenzial des Produktes
Eine erfolgreiche Produktentwicklung mitparallel verlaufenden Aufgabenstellungenist nur erfolgreich bei exzellenter Kommu-nikation zwischen allen Projektteilneh-mern vom Start bis zum Ende des Projek-tes. Unzureichende Kommunikation zwi-schen den Projektteilnehmern wird oft alswichtigster Versagensgrund f�r Produkt-entwicklungen zitiert. Dieser Beitrag zeigteinen Ansatz zur Projekt-Kommunikation,die sich als effektiv zur Vermeidung von
Kommunikationsdefiziten erwiesen hat –die Anwenderzentrierte Spezifikation. AlleProjekt- oder Produktsspezifikationen be-inhalten zwei Schl�sselfaktoren, die Pro-dukteigenschaft und die Leistungs- bzw.Funktionsmerkmale, die die Anwender er-warten.
Autor: Arne BriestE-Mail: [email protected]
Marktbedarf/Anwender-erwartungen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06101
Seite 1
Pflichtenheft – Usability
In dieser Phase wird die Spezifikation der Anwendung erstellt. Sie dient alsBasis f�r die Erstellung der Spezifikation der Gebrauchstauglichkeit. Die Spe-zifikation der Anwendung muss bei der Identifizierung von Eigenschaften imZusammenhang mit Sicherheit und der Identifizierung von bekannten odervorhersehbaren Gef�hrdungen ber�cksichtigt werden.
Zus�tzlich muss eine Zusammenfassung der Spezifikation der Anwendung desMedizinprodukts in den Begleitpapieren enthalten sein. Im Englischen mitunterauch als ,Statement of Use’ bezeichnet.
Der zuvor erstellte Usability Validation Plan (siehe Entwicklungsplan) wird nunspezifiziert und enth�lt eine Beschreibung der Methoden f�r die geplante Vali-dierung und die Kriterien zur Feststellung einer erfolgreichen Validierung.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06200
Seite 1
Erstellung von Pflichtenheften imgebrauchstauglichkeitsorientiertenEntwicklungsprozess
1 Normative Anforderungen
Der gebrauchstauglichkeitsorientierte Entwicklungsprozessist f�r alle Medizinprodukte in der internationalen NormDIN EN 62366:2008-09 (Anwendung der Gebrauchstaug-lichkeit auf Medizinprodukte) beschrieben. F�r aktive Medi-zinprodukte ist zus�tzlich die DIN EN 60601-1-6:2008-02(Medizinische elektrische Ger�te – Teil 1–6: AllgemeineFestlegungen f�r die Sicherheit einschließlich der wesentli-chen Leistungsmerkmale – Erg�nzungsnorm: Gebrauchs-tauglichkeit) verbindlich anzuwenden.
Eine entscheidende Rolle bei der Ent-wicklung sicherer und wirksamer Medi-zinprodukte kommt der Erstellung desPflichtenheftes im Rahmen der Konzept-phase zu.
Dabei gliedert sich der gebrauchstaug-lichkeitsorientierte Entwicklungsprozessin f�nf Schritte:
• Feinspezifikation der Anwendung;• Ermittlung der sich aus dem Gebrauch
ergebenden Gef�hrdungen;• Ableitung der Hauptbedienfunktionen;• Spezifikation der Gebrauchstauglich-
keit;• Validierungsplanung zur Gebrauchs-
tauglichkeit.
In enger Interaktion mit dem Risikoma-nagement werden hier die Grundlagen f�rein sicheres und ergonomisches Medizin-produkt gelegt.
Arbeitshilfen:
• Formblatt “Validierungsplan zur Ge-brauchstauglichkeit“
• Formblatt “Validierungsbericht zurGebrauchstauglichkeit“
• Formblatt “Gebrauchstauglichkeits-akte“
• Checkliste zum Nachweis der Einhal-tung der Anforderungen derDIN EN 62366:2008-09
Autor: Peter HartungE-Mail: [email protected]
DIN EN62366:2008
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06201
Seite 1
Pflichtenheft – Pflicht oder K�r?
1 Das Pflichtenheft – Definition und Erl�uterung
Ebenso wie f�r das Lastenheft gibt es auch f�r das Pflichten-heft eine Definition in der DIN 69901-5. Dort kann man lesen,dass das Pflichtenheft „vom Auftragnehmer erarbeitete Rea-lisierungsvorgaben auf der Basis des vom Auftraggeber vor-gegebenen Lastenhefts“ enth�lt. Eine Vorlage f�r ein Pflich-tenheft finden Sie auf der CD-ROM
In dieser auf den ersten Blick kurzen Definition stecken zweiwichtige Informationen:
1. Der Auftragnehmer erarbeitet das Pflichtenheft. Da dieErstellung des Pflichtenhefts f�r den Auftragnehmer of-fensichtlich Arbeit ist, macht es Sinn, sich an dieser Stelledamit auseinanderzusetzen, warum und wie man dieseArbeit effizient und m�glichst gewinnbringend investiert.
2. Das Pflichtenheft basiert auf dem Lastenheft. Ohne Las-tenheft oder, weiter gefasst, ohne Beschreibung des Vor-habens wird es f�r den Auftragnehmer schwierig, dieRealisierung zu beschreiben.
Das Pflichtenheft bildet die Grundlage derProduktentwicklung. Dieses Kapitel lie-fert Ihnen die grundlegenden Informatio-nen zum Erstellen eines Pflichtenhefts:Hinweise zu Zweck und Inhalt des Pflich-tenhefts, zur Vorgehensweise bei der Er-stellung und zu den Formalien, die Siebeim fertigen Dokument beachten sollten.Dabei werden auch die verschiedenen
Sichtweisen des Auftraggebers und Auf-tragnehmers dargestellt.
Arbeitshilfe:
• Vorlage eines Pflichtenhefts
Autor: Alexander FinkE-Mail: [email protected]
Realisierungs-vorgaben
06202_a.doc
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06202
Seite 1
Pflichtenheft – Klinische Bewertung
Als Voraussetzung f�r das Inverkehrbringen und die Inbetriebnahme ist vorge-sehen, dass das geplante Medizinprodukt die grundlegenden Anforderungenerf�llen muss, die unter Ber�cksichtigung ihrer Zweckbestimmung anzuwendensind. F�r das zu entwickelnde Medizinprodukt wird eine CE-Checkliste mit denf�r das Produkt relevanten pr�klinischen und klinischen Punkten erstellt.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 06300
Seite 1
Entwicklung – Inhalt
07000 Entwicklung
07100 Risikomanagement
07200 Usability
07201 �ber die Entwicklung von intuitiven, sicheren und effizientenMedizinproduktenDirk B�chel, Martin Scherrer, Ulrich Matern
07202 Beispiel: Benutzerzentrierte Entwicklungsprozesse f�r einnicht t�glich verwendetes Notfallger�tDirk B�chel, Martin Scherrer, Ulrich Matern
07203 Usability-Methode „Personas und Szenarien“:Der rote Faden bei der ProduktentwicklungTomas Hansson, Kerstin Klauß
07300 Klinische Bewertung
075 Design Transfer, Industrialisierung – Inhalt
07500 Design Transfer, Industrialisierung
Dieses Kapitel finden Sie nur auf der CD-ROM.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
07
Seite 1
07510 Risikomanagement
07511 Eine Aufgabe f�r Profis – niemals ohne RisikomanagementMartin G. Schleicher, R�diger G. F�rster
07520 Usability
07530 Klinische Bewertung
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07
Seite 2
Entwicklung
Diese Phase stellt das eigentliche Doing der Entwicklung dar. Das Produkt- undProduktionskonzept, die Realisation derselben, bis hin zur Erzeugung des be-gr�ndeten Entwicklungsergebnisses (Produkt, Produktion, Vertrieb, Wartung,Labeling, Training etc.) ist in dieser Phase zu Hause. Entsprechend der Mo-dulstruktur und des Entwicklungsplans wird diese Phase abgearbeitet.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07000
Seite 1
Entwicklung – Risikomanagement
Parallel zu dem Entwicklungsprozess wird entsprechend des Entwicklungs-fortganges das Risikomanagement weiter gepflegt. Die einzelnen Module,Funktionen, Sub-Funktionen, Features werden immer genauer auf m�glicheGef�hrdungen abgeklopft und daraus konstruktive �nderungen oder Maßnah-men abgeleitet. Hinweise im Labeling (Kennzeichnung, Gebrauchs- und In-stallationsanweisung), aber auch das Training der Anwender, des Service-Teamsoder Wartungs- / Instandhaltungsmaßnahmen werden hier definiert.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07100
Seite 1
Entwicklung – Usability
Das Usability-Team verfeinert die Spezifikation der Gebrauchstauglichkeit.Dabei handelt es sich um das Unterdokument, das die Anforderungen an dieBenutzer-Ger�t-Schnittstelle im Hinblick auf die Gebrauchstauglichkeit be-schreibt.
Die Anforderungen an die Benutzer-Ger�t-Schnittstelle m�ssen �berpr�fbarsein und werden unter anderem f�r die Verifizierung der Gebrauchstauglichkeitund die Validierung der Gebrauchstauglichkeit herangezogen. Auch handelt essich um �berpr�fbare Anforderungen f�r die Hauptbedienfunktionen. DesWeiteren werden Benutzungs-Szenarien identifiziert und beschrieben, die sichaufteilen in Benutzungs-Szenarien, die oft vorkommen und Benutzungs-Sze-narien, die schlimmst-m�gliche F�lle darstellen, die vern�nftigerweise vorher-sehbar sind. Entwicklungsbegleitend werden f�r einzelne Funktionen, Kompo-nenten oder Module schon Usability-Tests durchgef�hrt.
Oft vergessen werden hier die Begleitdokumente (Gebrauchsanweisung/Schu-lungsunterlagen). Sie m�ssen in dieser Phase in einem Entwurf vorliegen undsollten auf ihre Verst�ndlichkeit und Gebrauchstauglichkeit �berpr�ft werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07200
Seite 1
�ber die Entwicklung von intuitiven, sicheren undeffizienten Medizinprodukten
Dieses Kapitel spiegelt die eigenen Erfahrungen der Autorenw�hrend des Entwicklungsprozesses neuer medizinischerInstrumente und Ger�te wider. Es erhebt keinen Anspruch aufVollst�ndigkeit und soll dem verantwortlichen Entwick-lungsingenieur Hinweise �ber den Weg vom Pflichtenheft�ber den Prototyp bis hin zum Marketing geben.
1 Was es zu vermeiden gilt
1.1 Im Bereich Hygiene
F�r Medizinprodukte die zur mehrfachen Anwendung be-stimmt sind (Mehrwegprodukte), ist der Prozess der Aufbe-
Dieser Beitrag beschreibt das grundle-gende Entwicklungsverfahren, das derEntwickler aktiver (Ger�te) und nicht ak-tiver (Instrumente) Medizinprodukte be-r�cksichtigen sollte, um f�r alle mit demProdukt arbeitenden Berufsgruppen, dieBedienung so einfach und damit so sicherwie m�glich zu machen. Zudem sind diewesentlichen Methoden zur Festlegungund Pr�fung der Entwicklungsziele aufge-f�hrt.
Der wichtigste Grundsatz lautet:
„Wenn man wissen will, was die Anwenderin Krankenhaus, Praxis, Pflegeheim oderzu Hause (z. B. �rzte, Pflegekr�fte, Reini-
gungsfachkr�fte, Techniker, Angeh�rige,Patienten,. . .) f�r Diagnostik, Therapieund Wartung ben�tigen darf man sie nichtfragen; man muss sie beobachten.“
Erg�nzend zeigen die Autoren inKap. 07202 die praktische Umsetzung amBeispiel eines Benutzerorientierten Ent-wicklungsprozesses f�r ein nicht t�glichverwendetes Notfallger�t.
Autoren: Dirk B�chelMartin ScherrerUlrich Matern
E-Mail: [email protected]@[email protected]
Vorwort
Aufbereitung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07201
Seite 1
Beispiel: Benutzerzentrierte Entwicklungsprozesse f�rein nicht t�glich verwendetes Notfallger�t
Die wwH-c GmbH entwickelte und testete im „Experimen-tal-OP“ die Bedienschnittstelle einer Herzkatheterpumpe mitHilfe des in Kap. 07201 beschriebenen benutzerzentriertenDesignprozesses.
Zuerst wurden die Anforderungen an das Ger�t ermittelt: UmGebrauchstauglichkeitsanforderungen f�r die Bedienschnitt-stelle abzuleiten, wurde ein Benutzerprofil erstellt sowie eineAufgabenanalyse und eine Umgebungsanalyse durchgef�hrt.Bereits in diesem ersten Schritt wurden Benutzer in die Ent-wicklung einbezogen. Benutzerbefragungen lieferten Er-kenntnisse �ber die durchzuf�hrenden Arbeitsaufgaben undAnforderungen aus der Praxis. Probleme bisheriger ver-gleichbarer Produkte wurden aufgezeigt. Zus�tzlich wurdenBenutzer in der realen Arbeitsumgebung beobachtet (Abbil-dung 1). Diese Beobachtung lieferte Erkenntnisse, welchenicht aus den Benutzerinterviews abzuleiten waren, dennauch in diesem Fall fiel es den Nutzern schwer, ihre Anfor-derungen zu verbalisieren oder �berhaupt zu erkennen.
Raskin betont in diesem Fall: „Schau, was deine Nutzer ma-chen, aber frage sie nie, was sie wollen“ [1].
Nach Ermittlung der Anforderungen und der Gebrauchs-tauglichkeitsziele konnte der iterative Designprozess, beste-
Autoren: Dirk B�chelMartin ScherrerUlrich Matern
E-Mail: [email protected]@[email protected]
Anforderungen
Iterativer De-signprozess
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07202
Seite 1
Usability-Methode „Personas und Szenarien“:Der rote Faden bei der Produktentwicklung
1 Einleitung
Ein Patient wird in die Notaufnahme gefahren und ben�tigtdringend Adrenalin. Der anwesende Arzt greift zur ent-sprechenden Spritze, eilt zum Patienten und injiziert dieFl�ssigkeit. Er sp�rt einen Stich im Daumen und bemerkt,dass er die Spritze falsch herum h�lt. Der Arzt hat sich selbstdas Medikament injiziert. Wichtige Zeit vergeht, bis derPatient endlich die lebensnotwendige Injektion bekommt.Der Arzt leidet anschließend zwei Tage unter starkenSchmerzen und einer Schwellung im Daumen. [1]
Bedienfehler wie der im Beispiel beschriebene sind oft aufeine ungen�gende Einbeziehung des Nutzungskontexts in dieEntwicklung zur�ckzuf�hren. Die Spritze im Einf�hrungs-
„Personas“ und „Szenarien“ sind wichtigeHilfsmittel bei der nutzerzentrierten Ge-staltung von Medizinprodukten. Sie funk-tionieren als roter Faden durch den Ent-wicklungsprozess und stellen sicher, dassdie Nutzer in allen Phasen der Entwicklungber�cksichtigt werden.
Dieser Beitrag gibt eine Einf�hrung inPersonas und Szenarien und deren Ver-wendung im Entwicklungsprozess und imUsability Engineering File (UEF). Nach der
theoretischen Definition erfolgt eine pra-xissorientierte Anleitung zum Verfassenund zur Anwendung von Personas undSzenarien. Mit dieser Anleitung k�nnenMedizinprodukte entwickelt werden, diebesser an die Zielgruppe und deren Be-d�rfnisse angepasst sind.
Autoren: Tomas HanssonKerstin Klauß
E-Mail: [email protected]@uid.com
Beispiel
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 1
beispiel war so gestaltet, dass auf die Schnelle nicht ersicht-lich war, in welche Richtung sie gehalten werden muss. Immerwieder werden Medizinprodukte auf den Markt gebracht, dienicht der Anwendungssituation und den Nutzern angemessensind und dadurch ein erh�htes Risiko bergen.
Um erfolgreiche und sichere Medizinprodukte entwickeln zuk�nnen, ist es notwendig, die Nutzer und den Nutzungskon-text zu kennen. Wer wird das Produkt verwenden und wof�r?Welche Eigenschaften, Bed�rfnisse und W�nsche haben dieNutzer? In welchem Kontext und unter welchen Umst�ndenwird das Produkt verwendet? Nur wenn diese Fragen beant-wortet sind, k�nnen intuitive und sichere Medizinprodukteentwickelt werden.
Dies sind viele Fragen, und um sie zu beantworten, werdenviele Informationen ben�tigt. Personas und Szenarien helfendabei diese Informationen zu strukturieren und in ein Formatzu bringen, das optimal bei der Produktentwicklung verwen-det werden kann. Personas beschreiben die Zielgruppen f�rein bestimmtes Produkt auf eine anschauliche und �bersicht-liche Art und Weise.
Der Einsatzbereich von Szenarien ist breit. Sie k�nnen bei-spielsweise beim IST-Zustand ansetzen und Probleme undSchwachstellen bei der Nutzung eines bestehenden Produktesbeschreiben. Oder sie illustrieren den SOLL-Zustand, derbeschreibt, wie der Nutzer seine Aufgabe optimal mit demProdukt erf�llen kann.
Der n�chste Abschnitt definiert Personas und Szenarien undbeschreibt die Vorteile dieser Methoden bei der Entwicklungvon Medizinprodukten. Anschließend wird beschrieben, wiePersonas und Szenarien in dem Entwicklungsprozess einge-
Nutzer undNutzungskon-text
Personas
Szenarien
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07203 Entwicklung
Seite 2
setzt und in das Usability Engineering File (UEF) integriertwerden k�nnen.
2 Definition von Personas und Szenarien undderen Einbindung im UEF
Eine Persona ist eine detaillierte Beschreibung einer fiktivenPerson. Diese Beschreibung basiert auf Informationen �berdie Nutzergruppen eines Produktes. [2] Die Eigenschaftendieser Nutzergruppe werden anhand eines typischen Vertre-ters textuell und mittels Bildern oder Skizzen beschrieben.Personas erleichtert die Identifikation und Beschreibung derHauptnutzergruppen eines Produktes. Nur wenige Personaswerden ben�tigt, um alle wichtigen Nutzergruppen abzude-cken. Personas stellen sicher, dass die Nutzer bei der Pro-duktentwicklung immer im Fokus bleiben, von der Anforde-rungserhebung bis hin zur Evaluation eines Produktes.
Ein Szenario ist eine Geschichte �ber Menschen und derenAktivit�ten. [3] Diese noch sehr allgemeine Definition l�sstbereits auf die Bandbreite schließen, die ein Szenario abde-cken kann. In unterschiedlichen Phasen des Entwicklungs-prozesses eines medizinischen Produkts werden Szenarienverschiedener Detaillierungsgrade und mit unterschiedlichenSchwerpunkten ben�tigt. Im Zentrum steht dabei immer derNutzer mit seinen Bed�rfnissen, Zielen, Interpretationen,Umgebungsfaktoren, seinem sozialen Umfeld und den zubew�ltigenden Aufgaben.
2.1 Vorteile bei Produktentwicklung mit Personas undSzenarien
Nach unserer Erfahrung gibt es in Entwicklungs-Teams im-mer wieder verschiedene Vorstellungen dar�ber, wer die
Personas:archetypischeBeschreibung
Szenarien:Nutzer imFokus behalten
Kommunika-tion in multi-disziplin�renTeams
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 3
Nutzer sind, welche Aufgaben sie erledigen m�ssen, und aufwelche Art und Weise sie dies tun wollen. Dies f�hrt oft zulangen und unproduktiven Diskussionen, in welchen jedesTeammitglied seine pers�nliche Meinung �ußert, die Nutzeraber dabei nicht ber�cksichtigt werden. So entstehen Pro-dukte, die nicht an die Eigenschaften und Bed�rfnisse derNutzer angepasst sind.
Hier setzen Personas an, indem sie ein klares und explizitesBild der Nutzer mit ihren Eigenschaften, Bed�rfnissen, Ein-stellungen und �ußeren Einflussfaktoren schaffen. Personasund Szenarien sind, im Gegensatz zu Use Cases oder UML-Diagrammen, f�r alle Teammitglieder verst�ndlich und er-leichtern so die Kommunikation im Team. Gerade in multi-disziplin�ren Teams bei der Entwicklung von Medizinpro-dukten ist eine gemeinsame, vom jeweiligen fachspezifischenKontext der Teammitglieder losgel�ste Basis ein Qualit�ts-merkmal.
Durch die Einbeziehung expliziter Personas und Szenarienwird der Nutzer ins Zentrum der Entwicklung gestellt. Sieerleichtern es den Teammitgliedern sich besser in die Nutzerhineinzuversetzen und Fragestellungen aus deren Sicht zudiskutieren. Die Verwendung von Personas und Szenarienerm�glicht eine konstante Evaluation verschiedener Design-vorschl�ge, bei der der Nutzer im Zentrum steht. Dies f�hrt zuk�rzeren Design-Zyklen und zu einer besseren Produktqua-lit�t.
Szenarien k�nnen schon zu einem fr�hen Zeitpunkt eingesetztwerden. Bereits noch sehr abstrakte L�sungsans�tze k�nnenfestgehalten, gepr�ft und weiterentwickelt werden. So kannmit Unsicherheit und �nderungen gut umgegangen werden,da Szenarien schnell �berarbeitet werden k�nnen. Diesesschnelle und �konomische Vorgehen erm�glicht es, mehrere
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07203 Entwicklung
Seite 4
L�sungen zu skizzieren und weiterzuverfolgen. Ein zu fr�hesFestlegen auf eine einzelne L�sung, die sich sp�ter eventuellals ungeeignet herausstellt, wird so verhindert.
2.2 Personas und Szenarien in Verbindung mit demUsability Engineering File (UEF)
Personas und Szenarien k�nnen sowohl auf Ergebnisse imUsability Engineering File (UEF) zur�ckgreifen als auch In-put hierzu liefern. Ergebnisse aus der Application Specifica-tion (AS) wie der Intended Use (IU) und die vorgesehenePatienten-Gruppe bieten wertvollen Input f�r die Erhebungvon Informationen, die f�r das Schreiben von Personas undSzenarien ben�tigt werden. So entscheidet sich beispielsweisewelche Zielgruppe beobachtet und welche typischen Nutzerin Form von Personas beschrieben werden sollen. Die PrimaryOperating Functions (POF) geben einen Rahmen f�r sinnvolleSzenarien, die die wichtigsten Aufgaben wie z. B. das Inji-zieren eines Medikaments in den K�rper abdecken.
In die Usability Specification (US) k�nnen Szenarien inmehrfacher Hinsicht sinnvoll eingebunden werden. Zum ei-nen werden in der US h�ufige Nutzungs-Szenarien direktgefordert. Zum anderen k�nnen von Szenarien Anforderun-gen f�r das zu entwickelnde Produkt abgeleitet werden, dieebenfalls in der US dokumentiert und referenziert werden.Wird also z. B. im Szenario beschrieben, dass ein Ger�t ineinem Kontext mit vielen weiteren medizinisch-technischenGer�ten benutzt wird, lassen sich davon Anforderungen an dieGestaltung des visuellen und auditiven Ger�te-Feedbacksableiten.
Auch im Usability Validation Plan (UVP) sind Szenarien undPersonas und die daraus abgeleiteten Anforderungen einwichtiger Input f�r die Validierung der Gebrauchstauglich-
Primary Ope-rating Func-tions (POF)
Usability Vali-dation Plan(UVP)
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 5
keit. So k�nnen anhand von Szenarien beispielsweise dienotwendigen und auch vorgeschriebenen Usability-Testskonzipiert und durchgef�hrt werden. Sie erlauben, den Nutzerbei der Ausf�hrung der Hauptbedienfunktionen am Produktzu beobachten und Schwachstellen sowie Optimierungs-m�glichkeiten aufzudecken.
F�r das Design und die Implementierung der Benutzer-Ge-r�te-Schnittstelle (User Interface Design and Implementation– DAI) sehen die zugrundeliegenden Normen (EN 62366;ISO 60601-1-6) die fr�hestm�gliche Einbindung von geeig-neten Methoden zur Sicherstellung eines gebrauchstauglichenProdukts vor. Szenarien decken in ihrer Bandbreite den ge-samten Design- und Implementierungsprozess ab. Sie k�nnenbereits fr�h in abstrakter Form eingesetzt werden und wach-sen dann St�ck f�r St�ck in der Entwicklung mit, sie beein-flussen und dokumentieren die entstehenden Konzepte.
Sowohl bei der Verifizierung (Usability Verification – UVE),die �berpr�ft, ob ein Produkt die Anforderungen erf�llt, dieim Vorlauf formuliert wurden, als auch in der Validierung(Usability Validation – UV), die �berpr�ft, ob das Produktauch in der Handhabung durch den Nutzer sich als zweck-m�ßig best�tigt, k�nnen Szenarien und die darin enthaltenenPersonas sinnvoll eingesetzt werden.
Die Vielzahl dieser Querverbindungen mit dem UEF zeigt,dass sich Personas und Szenarien wie ein roter Faden durchden Entwicklungsprozess ziehen. Der folgende Abschnittbeschreibt die Entstehung und schrittweise Weiterentwick-lung von Personas und Szenarien.
Personas undSzenarien – einroter Faden
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07203 Entwicklung
Seite 6
3 Roter Faden: Schritt f�r Schritt mit Personasund Szenarien entwickeln
Dieser Abschnitt beschreibt die Entwicklungsstufen von Per-sonas und Szenarien in den verschiedenen Phasen der Ent-wicklung und Realisierung von Medizinprodukten. Personasund Szenarien sind der rote Faden durch den Entwicklungs-prozess und illustrieren Nutzer, deren Bed�rfnisse und Anw-endungs-Realit�ten. Orientiert an den Szenarien-Typen, dieMary Beth Rosson und John M. Carroll [3] in ihrem Ansatzzum szenario-basierten Design beschreiben, stellt dieses Ka-pitel die Entwicklung von und mit Personas und Szenarien mitBezug zum medizinischen Bereich dar. Problemszenarien,Aktivit�tsszenarien, Informationsszenarien und Interaktions-szenarien werden schrittweise vorgestellt und anhand vonBeispielen veranschaulicht.
3.1 Voraussetzungen f�r gute Personas und Szenarien:Informationen aus der Nutzungskontextanalyse
Die Erstellung von grundlegenden Szenarien ist optimaler-weise bereits am Anfang des Entwicklungsprozesses ange-siedelt. Die Ergebnisse aus Analysen zu Nutzern, deren Auf-gaben und der Nutzungsumgebung, wie sie beispielsweiseeine Nutzungskontextanalyse erhebt, bieten dazu die Grund-lage und sind eine Voraussetzung f�r zuverl�ssige Personasund Szenarien. Wird diese Phase vernachl�ssigt und fehlenverl�ssliche Daten zum Nutzungskontext, leidet darunter dieQualit�t von Personas und Szenarien. Die darauf aufbauendenEntwicklungsschritte des Medizinprodukts werden somitverf�lscht.
In der Analysephase wird �bersehen, dass die typischenNutzer das Medizinger�t vor allem im Dunkeln einsetzen.
Problem-, Ak-tivit�ts-, Infor-mations- undInteraktions-szenarien
Beispiel
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 7
Bei der Auswahl des Displays und dessen Beleuchtung so-wie der Farb- und Kontrastgestaltung im Designkonzeptfehlt diese Information und wird somit nicht ber�cksichtigt.Erst ein Prototyp, der in einer schon weit fortgeschrittenenEntwicklungsphase des Produkts unter realistischen Nut-zungsbedingungen getestet werden soll, deckt auf, dass dasGer�t aufgrund schlechter Lesbarkeit kaum bedienbar istbzw. Bedienfehler beg�nstigt. Aufw�ndige Ver�nderungenan Hardware und Software sind notwendig, um die entste-henden Risiken zu eliminieren.
Auch die Norm DIN EN 62366 fordert f�r das UEF Infor-mationen zu Nutzern, Aufgaben und Umgebungsvariablen(siehe IUP, PP und ICU). Eine gr�ndliche Nutzungskontext-analyse erhebt zus�tzlich noch Informationen �ber Bed�rf-nisse, Motivationen, Einstellungen und Ziele der Nutzer, dienicht explizit in den Subdokumenten des UEF gefordert sind.
Der in der Analysephase erhobene IST-Zustand muss nun ineine Form gebracht werden, die den Entwicklungsprozessunterst�tzt. Ziel ist es die Informationen so aufzubereiten,dass sie f�r alle Beteiligten transparent, nachvollziehbar undkommunizierbar sind. Personas und Problemszenarien bietensich daf�r an, da sie detailliert aber auch flexibel sind und sichim Laufe des Entwicklungsprozesses mitentwickeln.
3.1.1 Personas
Aus der Nutzungskontextanalyse und Intended Use k�nnendie verschiedenen Nutzergruppen identifiziert werden. AufBasis der gesammelten Daten wird f�r die verschiedenenNutzergruppen jeweils eine Persona kreiert. Die Persona ent-steht meistens aus den folgenden Beschreibungsmerkmalen:
Beschreibungdes IST-Zustandes
Bestandteile
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07203 Entwicklung
Seite 8
• Name: Der Name kann darauf hinweisen, was f�r einePers�nlichkeit die Person hat.
• Alter, Familienstand, Kinder etc.
• Beruf: Der berufliche Hintergrund l�sst auf Qualifikatio-nen und andere Eigenschaften schließen.
• Aufgaben: Die Aufgaben beschreiben die Hauptt�tigkei-ten jeweils einer Persona mit dem Produkt und stellen eineTeilmenge der POFs dar. Diese Hauptaufgaben sind f�rverschiedene Nutzergruppen oft sehr unterschiedlich.
• Pers�nliche und berufliche Ziele: Die Ziele machen deut-lich, was die Nutzer motiviert und was sie mit dem Produkterreichen wollen. Ist Technik nur Mittel zum Zweck oderhat die Zielgruppe Spaß an technischen Raffinessen?
• Vorwissen: Wie gut sich die Nutzer im betreffenden Be-reich auskennen, hat einen großen Einfluss auf die Pro-duktentwicklung. M�ssen z. B. Begriffe und Funktionenerl�utert werden oder sind sie schon bekannt?
• Foto oder Skizze: Dieser visuelle Aspekt ist hilfreich, umeine Persona „lebendiger“ zu machen.
Wichtig bei der Erfassung von Personas ist die Beschreibungihrer Pers�nlichkeit. Es reicht nicht aus, Statistiken aufzu-z�hlen, die beispielsweise ein Marktsegment beschreiben.Personas k�nnen gut in Szenarien eingebunden werden, dennSzenarien beschreiben die Geschichten der Personas im Um-gang mit dem Produkt.
Pers�nlichkeit
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 9
Frau Dr. Annabelle Faber 37 Jahre, verheiratet, ein Sohn, Allgemeinmedizi-nerin und Diabetologin.
Sie arbeitet seit 8 Jahren als Ärztin in einer klei-nen Praxis.
Sie betreut hauptsächlich Diabetes-Patienten, die zu regelmäßigen Kontrollen in die Praxis kom-men. Zusätzlich untersucht sie neue Patienten und berät sie zu Anpassungen der Behandlungsart.
In stressigen Zeiten, muss Frau Faber sehr viele Patienten an einem Tag beraten. Deswegen ist ein reibungsloser Ablauf und gute Unterstützung der Sprechstundenhilfe für sie sehr wichtig.
Sie nimmt ihre Arbeit sehr ernst und kann sich nicht vorstellen, einen anderen Beruf als diesen auszuführen. Obwohl die Arbeit stressig und anstrengend ist, gelingt es ihr, immer freundlich zu den Patienten zu sein und den Überblick zu behalten.
Frau Faber ist sehr bemüht, ihren Patienten immer die best-mögliche Behandlung und Service anzubieten. Sie will sich dabei auf die Patienten konzentrieren und nicht auf technische Hilfsmittel oder Papierarbeit.
Frau Faber schätzt neue Technologien, wenn diese sie entla-sten. Sie hält es für wichtig, die Patientenakten immer aktuell und vollständig zu halten, findet aber, dass dies oft zu viel Zeit in Anspruch nimmt. Von diesen Aufgaben wünscht sie sich häufig Entlastung.
Abb. 1: Beispiel f�r eine Persona: Frau Dr. Annabelle Faber (�rztin).
E Medizinprodukte planen, entwickeln, realisieren Grundwerk
07203 Entwicklung
Seite 10
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklung 07203
Seite 11
Die Leseprobe umfasst die Seiten 1 bis 10 des Beitrages.
Pflichtenheft – Klinische Bewertung
Hier findet vor allem die Pr�-Klinik Beachtung. Materialien, Materialkombi-nationen und F�getechniken werden in Tests der Toxizit�t und Biokompatibilit�tauf Tauglichkeit �berpr�ft, um damit auch die Grundlage f�r sp�tere klinischePr�fungen zu liefern. Auch die nach REACH notwendigen Sicherheitsdaten-bl�tter werden hier erzeugt oder akquiriert.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Pflichtenheft 07300
Seite 1
Design Transfer, Industrialisierung
Im Rahmen der Entwicklung entstehen Prototypen, mit denen wir testen k�n-nen, ob wir das angestrebte Ziel wirklich erreichen k�nnen. Aber das machtnoch keine Aussage dar�ber, ob das sp�tere Serienprodukt die formuliertenAnforderungen ebenfalls erf�llen kann. Daher hat in den USA die Beh�rde(FDA in 21CFR820) eine eigene Phase f�r diesen Schritt vorgesehen. Diesermacht jedoch nicht nur in den USA Sinn. Erfahrene Entwickler wissen, dass oftgerade in dieser Industrialisierungsphase große Aufgaben stecken.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Design Transfer, Industrialisierung 07500
Seite 1
Design Transfer, Industrialisierung –Risikomanagement
Sp�testens in dieser Phase findet das Risikomanagement des Produktes in seinerAnwendung die Erg�nzung durch Risiken, die aus der Herstellung des Produktesherr�hren k�nnen. Hier werden meistens die Entscheidungen getroffen, obProduktpr�fungen in der Produktion ausreichend sind, oder vielleicht docheinzelne Prozessschritte oder Maschinen einer Validierung bed�rfen. Aber nurdiese Seite zu betrachten, macht keinen Sinn, auch die Arbeitssicherheit derMitarbeiter in der Produktion, im Lager etc. kommt hier ins Spiel.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Design Transfer, Industrialisierung 07510
Seite 1
Eine Aufgabe f�r Profis – niemals ohneRisikomanagement
1 Einf�hrung
In der Phase „Design Transfer“ eines Projektes zeigt sich, obdie Unterlagen, die w�hrend der Entwicklung erstellt wurden,dazu geeignet sind, das entwickelte Produkt unter Serienbe-dingungen zu produzieren. Betrachtet man ein Serienger�t,m�ssen folgende Faktoren innerhalb des Design-Transferserbracht und vor allem dokumentiert werden:
• Kontinuierliche Qualit�t des Produktes;
• Beherrschte Herstellbedingungen;
• Jederzeit nachvollziehbare Produktionsprozesse.
Wird dies zum Ende des Design-Transfers nicht erreicht, sok�nnen nicht alle oben genannten Kriterien vorausgesetztwerden und es ergeben sich Nachteile, die an Kosten und/oderZeit um ein Vielfaches h�her ausfallen als die Abarbeitungw�hrend des Design-Transfer ben�tigt h�tte.
Der Design-Transfer endet mit der Freigabe des Produktes,des entsprechenden Herstellprozesses und der dazugeh�rigen
In der Phase „Design Transfer“ des Pro-dukt-Entstehungsprozesses wird die�bergabe eines Entwicklungs-Projektes indie (beherrschte) Serienfertigung be-schrieben, mit dem Transfer der Verant-wortlichkeiten und allen relevanten Doku-mentationen f�r das Produkt (inkl. des
Nachweises der Serienreife der Entwick-lung).
Autoren: Martin G. SchleicherR�diger G. F�rster
E-Mail: [email protected]@t-online.de
Serienreife
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Design Transfer, Industrialisierung 07511
Seite 1
Design Transfer, Industrialisierung – KlinischeBewertung
Die Pr�-Klinik wird vervollst�ndigt, indem nun die Fertigprodukte aus derFertigung den Toxizit�ts- und Biokompatibilit�tstests unterzogen werden. Einbesonderes Augenmerk gilt hier vor allem den Produktionshilfsstoffen, wieTrennmittel, Schneid�le etc.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Design Transfer, Industrialisierung 07530
Seite 1
Verifizierung – Inhalt
08000 Verifizierung
08100 Risikomanagement
08200 Usability
08201 Verifizierung der GebrauchstauglichkeitJoachim Harloff
08300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
08
Seite 1
Verifizierung
Die Phase der Verifizierung dient dazu, die Einhaltung der Spezifikationen derGebrauchstauglichkeit aus dem Pflichtenheft nachzuweisen. Dies kann in ein-zelnen Stufen anhand der Module erfolgen, zuletzt aber muss eine Verifizierungdes gesamten Produktes erfolgen. Die Verifikation kann also schon oft parallelzu der Entwicklung begonnen werden, kann aber erst mit der Produktionsreifeabgeschlossen werden. Dazu k�nnen verschiedenste Mittel genutzt werden, dahier auch verschiedenste Spezifikationen abgepr�ft werden m�ssen. So geh�renhier Usability-Tests, Technische Tests aber auch pr�-klinische Untersuchungenzu den normalen Mitteln.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Verifizierung 08000
Seite 1
Verifizierung – Risikomanagement
Im Risikomanagement befinden wir uns hier eigentlich nur noch im Maßnah-menmanagement. Nun sehen wir, ob die erwartete Gef�hrdung �ber die ergrif-fenen Maßnahmen wirklich im erwarteten Maß reduziert werden kann. Somitkann hier die Effektivit�t der Risikomanagement-Maßnahmen nachgewiesenwerden. Das Risikomanagement dient hier aber auch zur Ableitung bzw. Fest-legung der Testanforderungen und der Testtiefe, Stichprobengr�ße etc.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Verifizierung 08100
Seite 1
Verifizierung – Usability
Die Verifizierung der Gebrauchstauglichkeit untersucht die Benutzer-Ge-r�t-Schnittstelle. Sie muss sicherstellen, dass das Design des Medizinproduktsden Anforderungen entspricht. Als Grundlage hierf�r dienen deshalb die �ber-pr�fbaren Anforderungen, die in der Spezifikation der Gebrauchstauglichkeitbeschrieben sind.
Die Verifizierung kann durch die Inspektion der Benutzer-Ger�t-Schnittstelle,insbesondere durch die Beobachtung von vorgesehenen Benutzern, stattfinden.Hierbei werden relevante Daten gesammelt, w�hrend der Benutzer mit demMedizinprodukt oder einem Prototypen in der vorgesehenen oder simuliertenGebrauchsumgebung arbeitet.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Verifizierung 08200
Seite 1
Verifizierung der Gebrauchstauglichkeit
1 Stellung im gebrauchstauglichkeitsorientiertenEntwicklungsprozess
Mit der Verifizierung der Gebrauchstauglichkeit pr�fen Siedie Einhaltung der in der Spezifikation der Gebrauchstaug-lichkeit festgelegten Forderungen und Gebrauchstauglich-keits-Ziele. Sie arbeiten die Ausgestaltung des Medizinpro-dukts im Verlauf des iterativen Entwicklungsprozesses mitHilfe der Ergebnisse der Verifizierung immer genauer aus. Sieverbessern das Produkt, bis die Verifizierung zeigt, dass dieSpezifikation eingehalten wird. Mit immer genaueren De-signentscheidungen arbeiten Sie auch die Spezifikation derGebrauchstauglichkeit zielgenauer aus.
Um etwaige Korrekturen m�glichst fr�h im Entwicklungs-prozess vornehmen zu k�nnen, sollten Sie die Verifizierungentsprechend fr�h beginnen. Andererseits k�nnen Sie zu ei-nem gegebenen Zeitpunkt im Entwicklungsprozess nur solcheMerkmale pr�fen, deren Festlegung und Umsetzung bereitsmit dem endg�ltigen Produkt vergleichbar sind. Umfang und
W�hrend der Verifizierung der Gebrauchs-tauglichkeit wird gepr�ft, ob ein Medizin-produkt oder sein Prototyp der Spezifika-tion der Gebrauchstauglichkeit ent-spricht. Die Verifizierung dient also derSteuerung und der Kontrolle des Entwick-lungsprozesses. Zugleich gibt die Aus-wertung der Pr�fungen Auskunft �ber Artund Ort von Verbesserungsnotwendigkei-ten. Die Verifizierung der Gebrauchstaug-lichkeit verteilt sich meist auf eine Abfol-
ge mehrerer Pr�fungen. Im Verlauf derProduktentwicklung werden immer kon-kretere, genauere Forderungen mit daf�rangemessenen Methoden gepr�ft. Nebenden Anforderungen der IEC 62366 sindauch Anforderungen des Qualit�tsmana-gements (ISO 13485) zu beachten.
Autor: Joachim HarloffE-Mail: joachimharloff@joachimhar-
loff.de
Steuerung undKontrolle derProduktent-wicklung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Verifizierung 08201
Seite 1
Verifizierung – Klinische Bewertung
Die in der CE-Checkliste enthaltenen Punkte der grundlegenden Anforderungenzu pr�klinischen und klinischen Daten m�ssen von dem Produkt f�r eine Zu-lassung erf�llt werden. Zum Nachweis werden nun f�r den pr�klinischen Teil dieTests durchgef�hrt. Eine bereits erfolgte Sichtung der wissenschaftlichen Lite-ratur dient der Sammlung der f�r das Produkt bereits vorhandenen klinischenDaten. Es werden die f�r einen Beleg der Produktaussagen zu Sicherheit undLeistungsf�higkeit geeigneten Literaturzitate zusammengestellt. Aus der Sich-tung der in der Literatur vorhandenen klinischen Daten k�nnen sich weiterePunkte f�r eine f�r das Produkt vorgesehene klinische Pr�fung ergeben. DieArbeitsergebnisse der langen Planungsphase der klinischen Pr�fung werden inden Pr�fungsdokumenten, z. B. Pr�fplan, Produktdossier, zusammengefasst.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Verifizierung 08300
Seite 1
Validierung – Inhalt
09000 Validierung
09100 Risikomanagement
09101 Validierung medizinischer Ger�te auch unterBer�cksichtigung des Menschlichen FaktorsDirk B�chel, Martin Scherrer, Ulrich Matern
09200 Usability
09201 Usability-Validierung bei der Entwicklung vonMedizinproduktenAnfried Borgert, Torsten Gruchmann, Leena Killy
09300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
09
Seite 1
Validierung
Stand bei der Verifizierung der Nachweis der Einhaltung des Pflichtenheftes an,so ist die Aufgabe nun der Nachweis der Erf�llung des Lastenheftes. Diesesbesteht ja aus vielen nicht zwingend messbaren Anforderungen, da bei seinerErstellung vor allem die Anwendung durch den vorhersehbaren Anwender be-trachtet wurde. Zwangsl�ufig muss also in dieser Phase genau diese Anwen-dungsf�higkeit, Nutzbarkeit oder Tauglichkeit nachgewiesen werden. Dies ge-schieht durch Usability-Tests oder klinische Daten bzw. klinische Tests.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09000
Seite 1
Validierung – Risikomanagement
Wiederum befinden wir uns nur im Maßnahmenmanagement. Der Beweis wirdgef�hrt, dass die erwartete Eind�mmung der Gef�hrdung mit den Maßnahmenwirklich erreicht werden konnte. Es soll die Effektivit�t der Risikomanage-ment-Maßnahmen nachgewiesen werden. Das Risikomanagement dient hier derAbleitung bzw. Festlegung des Beginns der klinischen Pr�fung und der Anfor-derungen, der Probantenauswahl und der Probantenzahl.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09100
Seite 1
Validierung medizinischer Ger�te auch unterBer�cksichtigung des Menschlichen Faktors
Die Validierung von Medizinprodukten ist ein weites Feld.Eines der Themen dabei ist die Gebrauchstauglichkeit, die imConsumer-Bereich l�ngst etabliert ist und ein entscheidendesKaufkriterium darstellt. In der Medizin wurde Gebrauchs-tauglichkeit jedoch in der Regel vernachl�ssigt. Erst seitKurzem r�ckt dieses Thema mehr und mehr in das medizini-sche Interesse. Besonders wichtig bei der Gebrauchstaug-lichkeitsbetrachtung in der Medizin ist die Validierung.Hierbei muss neben den bekannten Gebrauchstauglichkeits-kriterien auch die Sicherheit betrachtet werden. In diesemKapitel wird die Validierung der Medizinprodukteentwick-lung unter dem Aspekt der Gebrauchstauglichkeit und damitder Anwendungsicherheit vorgestellt.
1 Validierung
Validierung und Evaluation werden h�ufig synonym ver-wendet. In diesem Beitrag wird unter Validierung die G�l-tigkeitserkl�rung eines Medizinproduktes verstanden, das den
Dieser Beitrag beschreibt das grundle-gende Validierungsverfahren f�r einenHersteller von Medizinprodukten unter derBer�cksichtigung des Anwenders. Eswerden Elemente des Risikomanage-ments an der Schnittstelle zur Gebrauchs-tauglichkeit aufgezeigt und eine Methodevorgestellt, die diese miteinander ver-kn�pft.
Autoren: Dirk B�chelMartin ScherrerUlrich Matern
E-Mail: [email protected]@[email protected]
Vorwort
Evaluation
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09101
Seite 1
Validierung – Usability
W�hrend die Verifizierung der Gebrauchstauglichkeit die Benutzer-Ge-r�t-Schnittstelle „pr�ft“, „best�tigt“ die Validierung der Gebrauchstauglichkeit,dass das Medizinprodukt die Anforderungen der Gebrauchstauglichkeit f�r einebestimmte Anwendung oder f�r die Zweckbestimmung erf�llt und stellt sicher,dass das richtige Produkt gebaut wird. Es gilt hierbei zu erw�hnen, dass eineValidierung nur „summativ“ erfolgen kann, also erst dann, wenn das Ger�t,zumindest als Prototyp, in seiner Gesamtheit vorliegt und getestet werden kann.Als Grundlage f�r die Validierung dienen die Akzeptanz-Kriterien, die im Va-lidierungs-Plan beschrieben sind und in erster Linie anhand von Usability-Tests�berpr�ft werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09200
Seite 1
Usability-Validierung bei der Entwicklung vonMedizinprodukten
1 Einf�hrung in das Thema Usability-Validierung
1.1 Bezug zum Usability Engineering Process und zumMedizinproduktegesetz
Gem�ß der Prozessnormen DIN EN 60601-1-6 und DIN EN62.366 muss f�r die CE-Kennzeichnung der Usability Engi-neering Process in die Produktentwicklung vom Medizin-produktehersteller integriert und nachgewiesen werden. DieEU-Direktiven Medical Device Directive (Richtlinie f�r Me-dizinprodukte; MDD), In-vitro Diagnostic Directive (Richt-linie f�r In-vitro-diagnostische Medizinprodukte; IVDD) undActive Implantable Medical Device Directive (Richtlinie f�raktiv implantierbare Medizinprodukte; AIMDD), die bisM�rz 2010 in L�nderrecht umgesetzt werden – in Deutsch-land beispielsweise �ber das Medizinproduktegesetz (MPG) –verweisen auf eben diese Normen. Die Usability-Validierungals abschließendes Kapitel des Usability Engineering Process
Die Usability-Validierung ist einer der letz-ten Meilensteine in der Entwicklung einesMedizinprodukts vor der CE-Zulassung. Inden vorherigen Phasen hat der Herstellerdie Akzeptanzkriterien festgelegt. Die Va-lidierung pr�ft nun die m�glichen Restrisi-ken bei der Anwendung des Produktes.Dieser Beitrag soll Herstellern von Medi-zinprodukten eine praxisnahe Einf�hrungin die Thematik geben und h�ufig auftre-tende Fragen beantworten. Es wird auf-gezeigt, wie ein Usability-Test mit Anwen-
dern als Methode der Validierung richtiggeplant, durchgef�hrt und dokumentiertwird, um den Normenanforderungen zugen�gen.
Autoren: Anfried BorgertTorsten GruchmannLeena Killy
E-Mail: [email protected]@ [email protected]
Usability-Validierungals Zulassungs-voraussetzung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09201
Seite 1
Validierung – Klinik
Eine f�r das Produkt vorgesehene klinische Pr�fung kann nun durchgef�hrtwerden. Ab diesem Zeitpunkt sind Pr�fzentrum und klinische Monitore in dasProjekt involviert, welche den Verlauf der Pr�fung �berwachen und dokumen-tieren.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Validierung 09300
Seite 1
Dokumentation – Inhalt
10000 Dokumentation
10100 Risikomanagement
10101 Risikomanagementakte nach DIN EN ISO 14971Marcus Schorn
10200 Usability
10201 Die Dokumentation – eine Entwicklungs- undBewertungsgrundlage f�r MedizinprodukteTobias Walke
10300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
10
Seite 1
Dokumentation
Der Hersteller (Legal Manufacturer) soll eine Produktdokumentation vorhalten;dazu geh�rt auch das Design-Dosier. Dieses wird parallel zum Entwicklungs-prozess erstellt, aber sp�testens nach Abschluss der Validierungst�tigkeiten undihrer Berichte auf Vollst�ndigkeit gepr�ft bzw. noch vervollst�ndigt. Nichtvergessen sollte man, dass die Prozessdokumentation (Standing OperatingProcedure – SOP) der Herstellung ein Teil davon ist, wenngleich diese Doku-mente im QM-System gelenkt werden. Auch die Inhalte des Labeling sind Teildes Design-Dossiers und damit eingefroren.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10000
Seite 1
Dokumentation – Risikomanagement
Auch hier wird nun die Vollst�ndigkeit gepr�ft: Sind alle Nachweise f�r dieValidit�t der Maßnahmen da und mit dem Risikomanagementbericht verkn�pft?Die Risikomanagementzusammenfassung f�r das Gesamtprojekt kann nun er-stellt werden und das Risikomanagementstatement des Managements kannvorbereitet werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10100
Seite 1
Risikomanagementakte nach DIN EN ISO 14971
1 Risikomanagement als integraler Bestandteildes Entwicklungsprozesses
Vorgeben
Prüfen
Genehmigen
Verteilen
Nachweis archivieren
Dokumenten-management
Anforderungen
Priorisieren
Risikoanalyse(FMEA)
Risikoübersicht
Änderungen(DRBFM)
Risiko-management
Allgemeine Vorgabe-
dokumente
Produkt-spez.
RM-Akte
Maßnahmen
Maßnahmen
Anfordern
Abarbeiten
Bewerten
Abschließen
Nachweis archivieren
Maßnahmen-management
Abb. 1: Festlegung des Prozessablaufs im Dokumentenmanagement.
Die Entwicklung eines Medizinprodukteskann effizient und effektiv �ber unter-schiedliche und integrierte Qualit�ts- undEntwicklungsmethoden dokumentiertwerden. Diese Methoden steuern denEntwicklungsprozess im Sinne eines Sys-tem-Engineerings und erleichtern zeit-gleich die geforderte Dokumentationser-
stellung. Der Beitrag erkl�rt diese Doku-mentation an Hand einer integriertenRisikomanagement- und Engineering-Soft-ware.
Autor: Marcus SchornE-Mail: [email protected]
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10101
Seite 1
Dokumentation – Usability
Das Usability-Team erstellt ein Usability Engineering File (UEF) nach DIN EN62366, das alle Aufzeichnungen aus dem Entwicklungsprozess umfasst. DasUEF beinhaltet alle bis hierher angefallenen beschreibenden Dokumente undalle Ergebnisse aus Verifizierung und Validierung.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10200
Seite 1
Die Dokumentation – eine Entwicklungs- undBewertungsgrundlage f�r Medizinprodukte
1 Produktdokumentation – Anforderungen
Zur Inverkehrbringung von Medizinprodukten wird vomHersteller entsprechend der gesetzlichen Vorschriften (vgl.93/42/EWG EG Richtlinie �ber Medizinprodukte; QSR FDA21 CFR Part 820 „Quality System Regulation“ u. a.) eineumfassende Produktdokumentation gefordert. Dabei mussdas Produkt selbst sowie der Entwicklungs- und Produkti-onsprozess bis hin zu Ergebnissen der Marktbeobachtungdokumentiert werden. Es entsteht eine Vielzahl verschiedenerDokumente, die aufeinander abgestimmt werden m�ssen.Standards geben eine Orientierung bzgl. Inhalt und Strukturder geforderten Produktdokumentation (vgl. z. B. IEC62079:2001; IEC 62366). Doch was steckt eigentlich hinterdem Begriff der Produktdokumentation? F�r wen wird sieerstellt? Welche Hilfen f�r eine effiziente Erstellung derProduktdokumentation gibt es?
Eine wesentliche T�tigkeit im Produkt-entwicklungsprozess ist das Dokumentie-ren – das Festhalten von Eigenschaftenund Funktionsprinzipien des Produktes,seines Verwendungszwecks, aber auchdas Dokumentieren der Durchf�hrung ei-nes Usability Engineering Process gem�ßder Norm IEC 62366.
Eine qualitativ hochwertige Dokumentati-on hilft bei der Umsetzung dieses Prozes-ses und vereinfacht die CE-Kennzeichnungdes Medizinproduktes. Aufgrund der Viel-
f�ltigkeit der Anforderungen sind Doku-mentationsvorlagen und fr�hzeitig getrof-fene Festlegungen zu Struktur und Inhal-ten der Dokumente unabdingbar. DerBeitrag gibt einen �berblick �ber die beider Entwicklung eines Medizinproduktesgeforderte Dokumentation hinsichtlichdes Entwicklungsprozesses zur Sicher-stellung der Gebrauchstauglichkeit sowieHinweise f�r eine effiziente Realisierung.
Autor: Tobias WalkeE-Mail: [email protected]
Dokumentati-onspflicht
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10201
Seite 1
Dokumentation – Klinik
Ein Abschlussbericht der klinischen Pr�fung wird erstellt. Eine Zusammenfas-sung der pr�-klinischen und klinischen Daten erfolgt. Der Bericht zur klinischenBewertung wird geschrieben. Die „Safety and Effectiveness Evaluation“ wirdzusammengestellt.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Dokumentation 10300
Seite 1
Konformit�tsbewertung – Inhalt
11000 Konformit�tsbewertung
11100 Risikomanagement
11101 Produktzulassung, klinische Forschung undKostenr�ckerstattung im EntwicklungsprozessArne Briest
11200 Usability
11300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
11
Seite 1
Konformit�tsbewertung
Die Produktanforderungen sollten nun erf�llt sein, jedoch kommen noch dieAnforderungen an das Qualit�tsmanagementsystem hinzu und auch das Kon-formit�tsbewertungsverfahren mit organisatorischen Forderungen. Ist das allesauch erledigt, kann die Konformit�tserkl�rung vom Verantwortlichen f�r dasInverkehrbringen auf Basis des Risikomanagement freigegeben werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Konformit�tsbewertung 11000
Seite 1
Konformit�tsbewertung – Risikomanagement
Das Management bzw. der Verantwortliche f�r das Inverkehrbringen wird indieser Phase ein Risikomanagement-Review durchf�hren, bevor das Risiko-managementstatement von Ihnen freigegeben wird.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Konformit�tsbewertung 11100
Seite 1
Produktzulassung, klinische Forschung undKostenr�ckerstattung im Entwicklungsprozess
1 Der Entwicklungsprozess
Die meisten Unternehmen der Medizintechnologie entwi-ckeln Ihre Produkte mit einem Projektmanagementansatz.Das Projektteam besteht aus Projektleiter und Vertretern derverschiedenen Abteilungen. Das Team ist verantwortlich f�rdie Planung und die Umsetzung des Projekts. Besonders beineuen und innovativen Produkten oder Produktverbesserun-gen haben der Beitrag der klinischen Forschung und die Be-wertung der Kostenr�ckerstattungssituation h�chste Priorit�t.
Der Produktentwicklungszyklus kann grob in vier Phasengegliedert werden: Konzept-, Prototyp-, Pilot- und Produkti-onsphase. Dieser Ansatz entspricht den Standard-Projektma-nagementmodellen bestehend aus Projektdefinition, Projekt-planung, Projektverfolgung, Produktpflege und Projektab-schluss.
Ein systematischer Ansatz, der Vertretersowohl der klinischen Forschung als auchder privaten und gesetzlichen Kranken-kassen (Kostenr�ckerstattung) in denfr�hen Phasen des Produktentwicklungs-prozesses einbindet, kann die Erfolgs-wahrscheinlichkeit der Entstehung einesneuen Produktes wesentlich erh�hen.
Die Vertreter der klinischen Forschungund der Kostenr�ckerstattung bringenwichtige Erfahrungen und Kenntnisse zur
Anwendung des Produktes im t�glichenAlltag ein. Dies st�rkt das Produktent-wicklungsteam und f�hrt so zu einer wei-teren Verbesserung der Produktentwick-lung und potenziell zur Verk�rzung desProduktentwicklungszyklus. Daher solltenbeide Vertreter bereits in den fr�hen Pha-sen des Projekts vertreten sein.
Autor: Arne BriestE-Mail: [email protected]
Projektmana-gement in derEntwicklung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Konformit�tsbewertung 11101
Seite 1
Konformit�tsbewertung – Usability
Das Management bzw. der Verantwortliche f�r das Inverkehrbringen wird indieser Phase ein Review der Usability-Daten durchf�hren, bevor die Zusam-menfassung freigegeben wird.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Konformit�tsbewertung 11200
Seite 1
Konformit�tsbewertung – Klinische Bewertung
Vervollst�ndigen der CE-Checkliste mit pr�klinischen und klinischen Daten.Das Management bzw. der Verantwortliche f�r das Inverkehrbringen wird indieser Phase ein Review der klinischen Daten durchf�hren, bevor die Zusam-menfassung von Ihnen freigegeben wird.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Konformit�tsbewertung 11300
Seite 1
�nderungen – Inhalt
12000 �nderungen
12100 Risikomanagement
12200 Usability
12300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
12
Seite 1
�nderungen
�nderungen des Produkts k�nnen schon w�hrend der Entwicklung der Produkteauftreten; vor allem treten diese nach Abschluss der Entwicklung auf. Auch dasProduktionsverfahren, das Vertriebssystem oder das Vertriebsgebiet kann sich�ndern, ebenso wie das Wartungsteam oder die Wartungsintervalle, das Labe-ling oder Training. All dies muss wieder nach den oben beschriebenen Regelnangegangen werden.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
�nderungen 12000
Seite 1
�nderungen – Risikomanagement
Wie schon oben beschrieben muss auch das Risikomanagement wieder neuentsprechend des obigen Phasenmodells bem�ht werden. Oft dient das Risiko-management schon dazu, abzuw�gen, ob �nderungen �berhaupt Sinn machenund welche Auswirkungen diese h�tten.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
�nderungen 12100
Seite 1
�nderungen – Usability
Analog zu Risikomanagement.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
�nderungen 12200
Seite 1
�nderungen – Klinische Bewertung
Analog zu Risikomanagement.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
�nderungen 12300
Seite 1
Entwicklungsreview – Inhalt
13000 Entwicklungsreview
13100 Risikomanagement
13101 Verbesserung bzw. Erhalt der Produktsicherheit durchRisikomanagement in ReviewsSarah Haake
13102 Wiederkehrendes Design Review – „Failure Mode“ DesignReview Based on Failure Mode (DRBFM)Andreas Gerber
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
13
Seite 1
Entwicklungsreview
Entwicklungsreviews sollen regelm�ßig in den wesentlichen Entwicklungs-phasen durchgef�hrt werden, um den planm�ßigen Entwicklungsfortschrittbeobachten zu k�nnen. Dies kann dann R�ckwirkungen zum Beispiel auf dieEntwicklungsplanung haben. Zus�tzlich werden Reviews aber auch ereignis-bezogen durchgef�hrt, wenn z. B. Probleme w�hrend des Entwicklungsprozes-ses auftreten.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsreview 13000
Seite 1
Entwicklungsreview – Risikomanagement
In jeder Reviewphase wird wiederum eine Bewertung entsprechend des Pha-senmodells durchgef�hrt. So kommt es zu einer Versionierung der Risikoma-nagementberichte, die die sp�tere Nachverfolgung des Entwicklungsfortgangserm�glicht und damit viele �hnlich gelagerte Entwicklungsprojekte deutlichvereinfachen kann.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsreview 13100
Seite 1
Verbesserung bzw. Erhalt der Produktsicherheit durchRisikomanagement in Reviews
1 Review – warum?
Als Hersteller tragen Sie die Verantwortung f�r das von Ihnenin den Markt gebrachte Medizinprodukt w�hrend seines ge-samten Lebenszyklus. In Kapitel 9 der Norm DIN EN ISO14971:2007 [1] heißt es: „Der Hersteller muss ein System zurSammlung und Auswertung von Informationen �ber dasMedizinprodukt oder �hnliche Produkte w�hrend der Her-stellung [. . .] festlegen, dokumentieren und aufrecht erhal-ten.“
Sie als Hersteller haben sich in der Regel f�r eines der fol-genden Entwicklungsprozess-Modelle entschieden. DieserEntwicklungsprozess wird entweder als Wasserfall-Modell(siehe Abbildung 1), als Spiral-Modell (siehe Abbildung 2),als V-Modell (siehe Abbildung 3) oder durch ein �hnlichesModell dargestellt und erstreckt sich �ber den gesamten Le-benszyklus.
Zur �berpr�fung des Risikomanage-ment-Prozesses m�ssen geeignete Ver-fahren im Unternehmen implementiertwerden. Neue Informationen m�ssenw�hrend des gesamten Lebenszyklus desProduktes in regelm�ßigen Abst�nden inden Prozess integriert und aktualisiertwerden. Wie lassen sich diese Reviews
nun in den RM-Prozess einarbeiten unddarstellen?
Arbeitshilfe:
• Risikomanagement-Review-Protokoll
Autor: Sarah HaakeE-Mail: [email protected]
„Lebenslange“Verantwortung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsreview 13101
Seite 1
Wiederkehrendes Design Review – „Failure Mode“Design Review Based on Failure Mode (DRBFM)
1 Einleitung
St�ndige Produktinnovationen und gleichzeitig k�rzere Ent-wicklungszeiten von komplexen (Medizin-)Produkten fordernein Umdenken im Projekt- bzw. Entwicklungsmanagement.Das �ndern einer kleinen Produkt- oder Prozess-Spezifika-tion eines Produkts kann eine wesentliche Verschiebung vonProjektkosten und/oder Markteinf�hrungsterminen zur Folgehaben, wenn die gesetzliche oder vom Anwender geforderteQualit�t nicht erreicht wird. Betrachten wir diese �nderung ineinem Unternehmen, das mit mehreren Projekten aufeinand-erfolgend oder gar in Parallelit�t plant, f�hrt dies zur Folge-verschiebung von Kosten und Zeiten. Das kann die gesamteUnternehmensplanung in Gefahr bringen (Abbildung 1). Umdie zugeteilten Ressourcen zu komplexen Folgewirkungen aufdie Prozessketten von Projekten zu vermeiden, ist nicht nurein ausgekl�geltes Multiprojektmanagement notwendig,sondern auch ein sensibles Entwicklungs- und �nderungs-
Die immer k�rzer werdenden Entwick-lungszeiten bei innovativen und komple-xen Medizinprodukten erfordern ein Um-denken im Entwicklungsmanagement.Kleine �nderungen einer Produkt- oderProzess-Spezifikation k�nnen eine we-sentliche Verschiebung von Projektkostenund/oder Markteinf�hrungsterminen zurFolge haben, wenn die erforderliche Qua-lit�t nicht erreicht wird. Um mit den zuge-teilten Ressourcen komplexe Folgewir-
kungen auf die Prozessketten zu vermei-den, ist nicht nur ein ausgekl�geltesMultiprojektmanagement notwendig,sondern auch ein sensibles �nderungs-management. Dieser Beitrag beschreibtdie Design-Review-Based-on-Failure-Mo-de-Methode, die eine L�sung zu diesenProblemen darstellt.
Autor: Andreas GerberE-Mail: [email protected]
Umdenken imProjekt- bzw.Entwicklungs-management
1. Aktualisierung E Medizinprodukte planen, entwickeln, realisieren
Entwicklungsreview 13102
Seite 1
Marktbeobachtung – Inhalt
14000 Marktbeobachtung
14100 Risikomanagement
14200 Usability
14300 Klinische Bewertung
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
14
Seite 1
Marktbeobachtung
Der Hersteller ist gefordert, Marktbeobachtung f�r seine Produkte zu betreiben.Die Ergebnisse dieser aktiven Beobachtung werden in entsprechendenPost-Production-Reviews verarbeitet. Eventuell n�tige Maßnahmen werdendaraus abgeleitet, vielleicht wird sogar ein Re-Design begonnen.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Marktbeobachtung 14000
Seite 1
Marktbeobachtung – Risikomanagement
Mit jeder R�ckmeldung vom Markt und jeder Befragung, jedem Kontakt mitAnwendern, wird der Bewertungsmaßstab des Risikomanagement objektiver.Dies bedeutet aber auch, dass der Risikomanagementbericht stetig �berarbeitet,der Realit�t angepasst und daraus eventuell entstehender �nderungsbedarf ex-trahiert wird. Diese �berpr�fung der Risikoeinsch�tzung ist auch Grundlage desMedizinprodukte-Beobachtungs- und Meldesystems und damit der Entschei-dung �ber Meldepflicht, Korrekturmaßnahmen im Markt oder sogar Produkt-r�ckrufe.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Marktbeobachtung 14100
Seite 1
Marktbeobachtung – Usability
Die im Risikomanagement aufgezeigte regelm�ßige �berpr�fung der Risiko-einsch�tzung und des gew�hlten Designs kann auch eine Ver�nderung des An-wenderverhaltens aufzeigen, die dann zu Korrekturmaßnahmen am Produktf�hren kann. Hier muss der Usability-Ingenieur regelnd eingreifen und denEntwicklungsprozess ansteuern.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Marktbeobachtung 14200
Seite 1
Marktbeobachtung – Klinische Bewertung
Im Rahmen des „Post Market Clinical Follow-up“ sind Hersteller verpflichtet,die klinische Bewertung laufend zu aktualisieren. Je nach Produkt und der zubeobachtenden Kriterien, z. B. Langzeit-Sicherheit, kann dieses auch eine kli-nische �berwachung nach dem Inverkehrbringen beinhalten.
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Marktbeobachtung 14300
Seite 1
Allgemeine und �bergreifende Themen – Inhalt
15100 Normen
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
15
Seite 1
Relevante Normen
Unter den folgenden Internetlinks k�nnen Sie sich �ber Nor-men informieren, die f�r die CE-Kennzeichnung relevantsind. Die Listen werden regelm�ßig gepflegt, und zwar immerdann, wenn im Amtsblatt der EU eine neue Liste der harmo-nisierten Normen erschienen ist.
New Approach Standardisation in the Internal Market:
http://www.newapproach.org/Directives/DirectiveList.asp
• 90/385/EEC – Active Implantable Medical Devices(Stand 2009-07)http://ec.europa.eu/enterprise/newapproach/standar-dization/harmstds/reflist/implmedd.html#top
• 93/42/EEC – Medical devices (Stand 2009-07)http://ec.europa.eu/enterprise/newapproach/standar-dization/harmstds/reflist/meddevic.html
• 98/79/EC – In vitro diagnostic medical devices (Stand2009-04)http://ec.europa.eu/enterprise/newapproach/standar-dization/harmstds/reflist/invimedd.html
Bezugsquelle:
T�V Media GmbHChristian ErichsenTel.: [email protected]
Nutzen Sie auch das Faxbestellblatt auf der n�chsten Seite!
Grundwerk E Medizinprodukte planen, entwickeln, realisieren
Allgemeine und �bergreifende Themen 15100
Seite 1