Der -Routenplaner Stand April 2010 - MedTech · PDF filePraxiswissen Medizintechnik Der...

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.


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


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


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


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


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


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.


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


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.


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


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.


Markt 01300

Seite 1

Produktidee – Inhalt

02000 Produktidee


02200 Usability

02201 Das Produktkonzept: Wie Sie Ihre Produktidee konkretisierenSherille Veira-Schnitzler, Alexander Steffen


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.


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.


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.


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


Input f�rPositionie-rung ist dieMarktanalyse

Leistungs-merkmale for-men Alleinstel-lungsmerkmal


Produktidee 02201

Seite 1

Feasibility (Machbarkeit) – Inhalt

03000 Feasibility


03101 Feasibility oder Machbarkeitsuntersuchung vor demeigentlichen EntwicklungsstartAlexander Fink


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.


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.


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]


Feasibility (Machbarkeit) 03101

Seite 1

Entwicklungsplan – Inhalt

04000 Entwicklungsplan


04101 Festlegung der Bewertungskriterien f�r denRisikomanagementplanDirk B�chel, Martin Scherrer, Ulrich Matern

04200 Usability



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.


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.



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]



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.



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.



Seite 1

Lastenheft – Inhalt

05000 Lastenheft


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



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.


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.


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


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


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.


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


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


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


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


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


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


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


05201 Lastenheft

Seite 8

http://www.tuev-media.de/leseprob/maxi_lp/mpr/05201_a.doc

• 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


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


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


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.


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


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


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


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.


Lastenheft 05300

Seite 1

Pflichtenheft – Inhalt

06000 Pflichtenheft


06101 Anwenderzentrierte Spezifikation des Produktes imPflichtenheftArne Briest

06200 Usability

06201 Erstellung von Pflichtenheften imgebrauchstauglichkeitsorientierten EntwicklungsprozessPeter Hartung

06202 Pflichtenheft – Pflicht oder K�r?Alexander Fink



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.


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.


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


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.


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


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


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.


Pflichtenheft 06300

Seite 1

Entwicklung – Inhalt

07000 Entwicklung


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ß


075 Design Transfer, Industrialisierung – Inhalt

07500 Design Transfer, Industrialisierung

Dieses Kapitel finden Sie nur auf der CD-ROM.


07

Seite 1


07511 Eine Aufgabe f�r Profis – niemals ohne RisikomanagementMartin G. Schleicher, R�diger G. F�rster

07520 Usability



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.


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.


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.


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.



Vorwort

Aufbereitung


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-



Anforderungen

Iterativer De-signprozess


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ß


Beispiel


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


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


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


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)


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


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


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


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


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).


07203 Entwicklung

Seite 10


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.


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.


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.



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



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.



Seite 1

Verifizierung – Inhalt

08000 Verifizierung


08200 Usability

08201 Verifizierung der GebrauchstauglichkeitJoachim Harloff



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.


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.


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.


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


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.


Verifizierung 08300

Seite 1

Validierung – Inhalt

09000 Validierung


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



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.


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.


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.



Vorwort

Evaluation


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.


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


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.


Validierung 09300

Seite 1

Dokumentation – Inhalt

10000 Dokumentation


10101 Risikomanagementakte nach DIN EN ISO 14971Marcus Schorn

10200 Usability

10201 Die Dokumentation – eine Entwicklungs- undBewertungsgrundlage f�r MedizinprodukteTobias Walke



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.


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.


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]


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.


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


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.


Dokumentation 10300

Seite 1

Konformit�tsbewertung – Inhalt

11000 Konformit�tsbewertung


11101 Produktzulassung, klinische Forschung undKostenr�ckerstattung im EntwicklungsprozessArne Briest

11200 Usability



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.


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.



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



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.



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.



Seite 1

�nderungen – Inhalt

12000 �nderungen


12200 Usability



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.


�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.


�nderungen 12100

Seite 1

�nderungen – Usability

Analog zu Risikomanagement.


�nderungen 12200

Seite 1

�nderungen – Klinische Bewertung

Analog zu Risikomanagement.


�nderungen 12300

Seite 1

Entwicklungsreview – Inhalt

13000 Entwicklungsreview


13101 Verbesserung bzw. Erhalt der Produktsicherheit durchRisikomanagement in ReviewsSarah Haake

13102 Wiederkehrendes Design Review – „Failure Mode“ DesignReview Based on Failure Mode (DRBFM)Andreas Gerber


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.


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.



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



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



Seite 1

Marktbeobachtung – Inhalt

14000 Marktbeobachtung


14200 Usability



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.


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.



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.



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.



Seite 1

Allgemeine und �bergreifende Themen – Inhalt

15100 Normen


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!


Allgemeine und �bergreifende Themen 15100

Seite 1

Der -Routenplaner Stand April 2010 - MedTech · PDF filePraxiswissen Medizintechnik Der...

Documents

Transcript of Der -Routenplaner Stand April 2010 - MedTech · PDF filePraxiswissen Medizintechnik Der...