Lehrplan CPMS V20

International Certified Professional for Medical Software
Board e.V.
Certified Professional for

Medical Software
Lehrplan
Foundation Level
Advanced Level Process Management
Advanced Level Software Development
Version 2.0 / 2016-08-12
20
Certified Professional for Medical Software
Gesamtlehrplan
Das Urheberrecht © 2010-2016 dieses Lehrplans liegt beim International Certified Professional for Medical
Software Board e.V. (ICPMSB e.V.)
Die Autoren dieses Lehrplanes sind, in alphabetischer Reihenfolge:
Thorsten Bonhagen Julia Korus

Stefan Bolleininger Markus Manleitner
Dr. Christian Denger Hans-Werner Mürbeth
Michael Engler Michael Musick
Robert Eschbach Frederik Nitschke
Dr. Gunther Fritzer Manfred Öhlenschläger
Dr. Martin Geier Klaus Ostermayer
Thomas Gelsdorf Harald Schilg
Volker Gerling Christoph Schulte
Matthias Hölzer-Klüpfel Peter Seifter
Prof. Dr. Christian Johner Prof. Dr. Jürgen Stettin
Roland Kaib Burkhard Volkemer
Daniel Kerkow Sven Wittorf
Mario Klessascheck Patrick Zahnow
Prof. Dr. Martin Zauner
Wesentliche Überarbeitungen des Lehrplans in der Version 2.0 sind das Ergebnis eines vom
Bundesministerium für Bildung und Forschung (BMBF) geförderten Projektes des Spitzenclusters
Medizintechnik des Medical Valley EMN (Förderkennzeichen: 13EX1013A, 13EX1013H und 13EX1013K).
Die Autoren und der ICPMSB e.V. haben folgenden Nutzungsbedingungen zugestimmt:
Jede Einzelperson und jeder Seminaranbieter darf den Lehrplan als Grundlage für Seminare verwenden,
sofern die Inhaber der Urheberrechte als Quelle und Besitzer des Urheberrechts anerkannt und benannt
werden. Des Weiteren darf der Lehrplan zu Werbezwecken erst nach der Akkreditierung durch den ICPMSB
e.V. verwendet werden.
Jede Einzelperson oder Gruppe von Einzelpersonen darf den Lehrplan als Grundlage für Artikel, Bücher oder
andere abgeleitete Veröffentlichungen verwenden, sofern der ICPMSB e.V. als Quelle und Besitzer des
Urheberrechts genannt werden.
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Die Verwertung ist – soweit sie nicht
ausdrücklich durch das Urheberrechtsgesetz (UrhG) gestattet ist – nur mit Zustimmung der Berechtigten
zulässig. Dies gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmung,
Einspeicherung und Verarbeitung in elektronischen Systemen, öffentliche Zugänglichmachung.
© 2016 International Certified Professional for Medical Software Board e.V. 2

Gesamtlehrplan
Änderungshistorie
ATUM ÄNDERUNG AUT
OR
DATUM ÄNDERUNG AUTOR
2010-10-12 Erstfassung ICPMSB e.V.
2011-10-11 Erweiterung um ein Mapping auf die Kapitel des Lehrbuches. ICPMSB e.V.
2011-11-17 Detailliertere Auflistung der Lehrziele ICPMSB e.V.
2015-10-26 Version 2.0 nach Übernahme der Ergebnisse des ICPMSB e.V.
Förderprojektes
2016-08-12 Freigabe der Version 2.0 ICPMSB e.V.

Gesamtlehrplan
Inhaltsverzeichnis
ÄNDERUNGSHISTORIE 2
INHALTSVERZEICHNIS 3
EINFÜHRUNG 7
1. CURRICULUM REGULATORISCHE GRUNDLAGEN 8
1.1. RECHTLICHE GRUNDLAGEN 8

1.1.1. DEFINITION EINES MEDIZINPRODUKTES 8
1.1.2. RECHTLICHE GRUNDLAGEN IN EUROPA 9
1.2. DIE EUROPÄISCHEN RICHTLINIEN UND DIE NATIONALE UMSETZUNG 11
1.2.1. RICHTLINIE 93/42/EWG ÜBER MEDIZINPRODUKTE 12
1.2.2. RICHTLINIE 98/79/EG ÜBER IN-VITRO-DIAGNOSTIKA 16
1.2.3. RICHTLINIE 90/385/EWG ÜBER AKTIVE IMPLANTIERBARE MEDIZINISCHE GERÄTE 18
1.2.4. NATIONALE UMSETZUNG AM BEISPIEL DES MEDIZINPRODUKTEGESETZES 19
1.3. DIE HARMONISIERTEN NORMEN 22
1.3.1. EN ISO 13485: QUALITÄTSMANAGEMENTSYSTEME - ANFORDERUNGEN FÜR REGULATORISCHE ZWECKE 22
1.3.2. EN ISO 14971: ANWENDUNG DES RISIKOMANAGEMENTS AUF MEDIZINPRODUKTE 22
1.3.3. EN 62304: SOFTWARE-LEBENSZYKLUS-PROZESSE 24
1.3.4. EN 62366 - ANWENDUNG DER GEBRAUCHSTAUGLICHKEIT AUF MEDIZINPRODUKTE 25
1.3.5. DIE NORMENFAMILIE EN ISO 60601-1 ÜBER MEDIZINISCH ELEKTRISCHE GERÄTE 25
1.4. LEBENSZYKLUS EINES MEDIZINPRODUKTES 27
1.4.1. DER PRODUKTLEBENSZYKLUS AUS REGULATORISCHER SICHT 27
1.4.2. ÜBERWACHUNG DURCH BEHÖRDEN UND BENANNTE STELLEN 31
1.5. REGULATORISCHE GRUNDLAGEN FÜR DEN US-MARKT 33
1.5.1. RECHTLICHE GRUNDLAGEN IN DEN USA 33
1.5.2. KLASSIFIZIERUNG VON MEDIZINPRODUKTEN NACH AMERIKANISCHEM RECHT 35
1.5.3. INVERKEHRBRINGEN AUF DEM AMERIKANISCHEN MARKT 36
1.5.4. SOFTWARESPEZIFISCHE ANFORDERUNGEN 37
2. CURRICULUM RISIKOMANAGEMENT 41
2.1. EINFÜHRUNG IN DAS RISIKOMANAGEMENT 41

2.1.1. REGULATORISCHE FORDERUNGEN 41
2.1.2. BEGRIFFSDEFINITIONEN 43
2.2. RISIKOBEWERTUNGSMATRIX 45
2.2.1. AUFBAU UND ZIEL DER MATRIX 45
2.2.2. DIE ACHSEN DER RISIKOBEWERTUNG 47
2.2.3. RISIKOAKZEPTANZKRITERIEN 49
2.3. VERFAHREN ZUR GEFÄHRDUNGSANALYSE 50
2.3.1. GRUNDLEGENDES ZU GEFÄHRDUNGSANALYSE 50
2.3.2. PRELIMINARY HAZARD ANALYSIS 50
2.3.3. FAULT-TREE-ANALYSIS 52
2.3.4. FAILURE MODE AND EFFECTS ANALYSIS (FMEA) 53
2.4. DER RISIKOMANAGEMENT-PROZESS NACH ISO 14971 54
Gesamtlehrplan
2.4.1. ALLGEMEINE ANFORDERUNGEN 54

2.4.2. DER RISIKOMANAGEMENTPROZESS 55
2.4.3. RISIKOMANAGEMENTPLANUNG 56
2.4.4. ZWECKBESTIMMUNG UND BESTIMMUNGSGEMÄßER GEBRAUCH 57
2.4.5. GEFÄHRDUNGS- UND RISIKOANALYSE 58
2.4.6. RISIKOBEHERRSCHUNG 59
2.4.7. RISIKO-/NUTZENBEWERTUNG 60
2.4.8. NACHGELAGERTE PHASE 61
2.5. DOKUMENTATION 62
2.5.1. ÜBERSICHT ÜBER DIE DOKUMENTENLANDSCHAFT 62
2.5.2. RISIKOTABELLE 63
2.6. RISIKOMANAGEMENT FÜR SOFTWARE 63
2.6.1. RISIKOMANAGEMENT UND SOFTWARE-KLASSIFIZIERUNG 63
2.6.2. RISIKOANALYSE FÜR SOFTWARE 64
2.6.3. IEC 80002 67
3. CURRICULUM SW-ENGINEERING 69
3.1. SOFTWAREENTWICKLUNGSPROZESSE 69
3.1.1. REGULATORISCHE ANFORDERUNGEN 69
3.1.2. VORGEHENSMODELLE 70
3.1.3. PROZESSBESCHREIBUNG 71
3.1.4. ZUSAMMENSPIEL MIT DER KONFORMITÄTSBEWERTUNG UND DEM AUDIT 72
3.2. ENTWICKLUNGSPLANUNG 73
3.2.1. ENTWICKLUNGSPLANUNG 73
3.3. SOFTWARE-ANFORDERUNGSANALYSE 75
3.3.1. ANFORDERUNGEN ERMITTELN 75
3.3.2. ANFORDERUNGEN DOKUMENTIEREN 76
3.3.3. ANFORDERUNGEN VERIFIZIEREN 77
3.3.4. ANFORDERUNGEN VERWALTEN 78
3.4. SOFTWAREARCHITEKTUR 78
3.4.1. SOFTWAREARCHITEKTUR BESCHREIBEN 78
3.4.2. SICHERHEITSKLASSEN 79
3.4.3. RISIKOBEHANDLUNG SICHERSTELLEN 81
3.4.4. SOFTWAREARCHITEKTUR VERIFIZIEREN 82
3.5. SW-DESIGN 82
3.5.1. SOFTWAREDESIGN BESCHREIBEN 82
3.5.2. SCHNITTSTELLEN DEFINIEREN 83
3.5.3. DESIGN VERIFIZIEREN 84
3.6. SW-IMPLEMENTIERUNG 84
3.6.1. SOFTWAREEINHEITEN IMPLEMENTIEREN 84
3.6.2. AKZEPTANZKRITERIEN FESTLEGEN 85
3.6.3. KODIERRICHTLINIEN EINSETZEN 86
3.6.4. SOFTWAREEINHEITEN VERIFIZIEREN 87
3.7. SOFTWARE-INTEGRATION 88
3.7.1. SOFTWARE-INTEGRATION 88
3.8. SOFTWARETEST 89
3.8.1. ALLGEMEINE ANFORDERUNGEN AUS IEC 62304 89
3.8.2. VERIFIZIERUNG VS. VALIDIERUNG 92
3.9. SOFTWARE-FREIGABE 93
3.9.1. SOFTWARE-FREIGABE 93
3.10. SOFTWAREKONFIGURATIONSMANAGEMENT 94

Gesamtlehrplan
3.10.1. KONFIGURATIONSELEMENTE 94
3.10.2. NOTWENDIGKEIT DES KONFIGURATIONSMANAGEMENTS 94
3.10.3. KONFIGURATIONSELEMENTE IDENTIFIZIEREN 95
3.10.4. WERKZEUGE FÜR DAS KONFIGURATIONSMANAGEMENT 96
3.10.5. KONFIGURATIONSMANAGEMENTPLAN 96
3.10.6. ÄNDERUNGSMANAGEMENT 97
3.11. SOFTWARE-WARTUNG 98
3.11.1. PLANUNG DER SOFTWARE-WARTUNG 98
3.11.2. ANALYSE VON PROBLEMEN UND ÄNDERUNGEN 99
3.11.3. IMPLEMENTIERUNG VON ÄNDERUNGEN 100
3.12. SOFTWARE-PROBLEMLÖSUNG 101
3.12.1. PROBLEMLÖSUNG FÜR SOFTWARE 101
3.13. RÜCKVERFOLGBARKEIT IM SOFTWARE-ENTWICKLUNGSPROZESS 103
3.13.1. GRUNDLAGEN 103
3.13.2. TRACING DURCHFÜHREN 104
3.13.3. RÜCKVERFOLGBARKEIT ANDERER ARTEFAKTE IM SOFTWARE-ENTWICKLUNGSPROZESS 105
3.13.4. FORDERUNGEN DER FDA 105
3.14. SOFTWARE OF UNKNOWN PROVENANCE (SOUP) 106
3.14.1. DEFINITION UND BEISPIELE FÜR SOUP 106
3.14.2. UMGANG MIT SOFTWARE OF UNKNOWN PROVENANCE 107
3.15. COMPUTER-SYSTEM-VALIDIERUNG 110
3.15.1. EINFÜHRUNG 110
3.15.2. TOOL-VALIDIERUNG IN DER PRAXIS 111
3.15.3. WARTUNG DER WERKZEUGE 113
4. CURRICULUM USABILITY 115
4.1. GRUNDLAGEN DES USABILITY ENGINEERINGS 115

4.1.1. WESHALB USABILITY ENGINEERING WICHTIG IST 115
4.1.2. BEGRIFFLICHKEITEN IM KONTEXT DER GEBRAUCHSTAUGLICHKEIT 118
4.2. REGULATORISCHE FORDERUNGEN 120
4.2.1. REGULATORISCHE ANFORDERUNGEN (EUROPA) 120
4.2.2. NORMEN UND WEITERE RICHTLINIEN 121
4.3. VOM NUTZUNGSKONTEXT ZU NUTZUNGSANFORDERUNGEN 123
4.3.2. NUTZUNGSKONTEXT 125
4.3.3. ABLEITEN DER NUTZUNGSANFORDERUNGEN 127
4.4. BENUTZUNGSSCHNITTSTELLE 129
4.4.1. BENUTZUNGSSCHNITTSTELLE KONZIPIEREN 129
4.4.2. BENUTZUNGSSCHNITTSTELLE UND RISIKEN 131
4.5. USABILITY VERIFIZIERUNG UND VALIDIERUNG 132
4.5.2. VERIFIZIERUNG 133
4.5.3. VALIDIERUNG 135
4.6. SONSTIGES 137
4.6.1. DIN EN 62366 137
4.6.2. DOKUMENTATION 139
5. CURRICULUM QUALITÄTS- UND DOKUMENTENMANAGEMENT 141
5.1. QUALITÄTSMANAGEMENT 141

5.1.1. PROZESSORIENTIERTER ANSATZ 141
Gesamtlehrplan
5.1.2. DOKUMENTATIONSANFORDERUNGEN AN DAS QUALITÄTSMANAGEMENTSYSTEM 142

5.2. ALLGEMEINE ANFORDERUNGEN AN DIE DOKUMENTATION 144
5.2.1. UMGANG MIT DOKUMENTEN 144
5.2.2. ALLGEMEINE ANFORDERUNGEN AN DOKUMENTE 146
5.3. GEFORDERTE DOKUMENTATION 147
5.3.1. ÜBERBLICK 147
5.3.2. RISIKOMANAGEMENTAKTE 148
5.3.3. GEBRAUCHSTAUGLICHKEITSAKTE 149
5.3.4. DOKUMENTATION DER SOFTWAREENTWICKLUNG 150
5.3.5. TECHNISCHE DOKUMENTATION 151
5.4. FDA VS EU 153
5.4.1. DIE UNTERSCHIEDLICHEN ANFORDERUNGEN AN DIE DOKUMENTATION AUS FDA UND EU SICHT 153
6. CURRICULUM MEDIZINISCHE INFORMATIK 156
6.1. GRUNDLAGEN DES GESUNDHEITSWESENS 156

6.1.1. AKTEURE IM GESUNDHEITSWESEN 156
6.1.2. GELDFLUSS 156
6.1.3. INTERSEKTORALE KOMMUNIKATION UND VERSORGUNG 157
6.1.4. TRENDS 158
6.1.5. DATEN IM GESUNDHEITSWESEN 159
6.2. MEDIZINISCHE DOKUMENTATION 160
6.2.1. ZIELE DER MEDIZINISCHEN DOKUMENTATION 160
6.2.2. ORDNUNGSSYSTEME 161
6.2.3. ICD-10 162
6.2.4. LOINC 162
6.2.5. KLASSIFIZIERUNG VON MEDIKAMENTEN 164
6.2.6. WEITERE ORDNUNGSSYSTEME 164
6.3. INFORMATIONSSYSTEME IM GESUNDHEITSWESEN 165
6.3.1. AUFGABEN VON (MEDIZINISCHEN) INFORMATIONSSYSTEMEN 165
6.3.2. KLASSISCHE INFORMATIONSSYSTEME 165
6.3.3. TELEMEDIZIN 166
6.4. INTEROPERABILITÄT 166
6.4.1. INTEROPERABILITÄT - EINE EINFÜHRUNG 166
6.4.2. INTEROPERABILITÄTSEBENEN 168
6.5. HL7 V2 170
6.5.2. NACHRICHTEN UND DOKUMENTE 170
6.6. DICOM 172
6.6.2. DATENSTRUKTUR UND DATENMODELL 173
6.6.3. KOMMUNIKATION MIT DICOM 174

Gesamtlehrplan
Einführung
Der vorliegende Lehrplan ist das Ergebnis eines vom Bundesministerium für Bildung und
Forschung (BMBF) geförderten Projektes des Spitzenclusters Medizintechnik des Medical Valley
EMN (Förderkennzeichen: 13EX1013A, 13EX1013H und 13EX1013K) und der Überarbeitung des
bislang gültigen Lehrplans „Certified Professional for Medical Software“ (CPMS; Version 1.1).
Im CPMS Foundation Level (im Folgenden kurz: FL) werden Grundlagen der Entwicklung
medizinischer Software vermittelt.
Im CPMS Advanced Level Process Management (im Folgenden kurz: AL-PM) werden Inhalte zu
den Themenfeldern Prozessgestaltung, Regulatory Affairs und Qualitätsmanagement vertieft.
Im CPMS Advanced Level Software Development (im Folgenden kurz: AL-SW) werden Inhalte zur
Entwicklung medizinischer Software vertieft.
Der Lehrplan gliedert sich in sechs Module, deren Reihenfolge nicht willkürlich ist. Eine Übersicht
über die Zeiten findet sich jeweils zu Beginn des Moduls. Jedem Unterabschnitt sind Lernziele
zugeordnet. Die Lernziele sind jeweils einer der folgenden kognitiven Stufen zugeordnet:
 K1: sich erinnern
 K2: verstehen
 K3: anwenden
Die kognitive Stufe K4 (analysieren) wird nicht gefordert.
Der Eintrag "W" erfordert, im Advanced Level die Inhalte des Foundation Level zu wiederholen.
Hinweis für Schulungsanbieter: K2-Lernziele müssen anhand von Beispielen vermittelt werden.
Für K3-Lernziele ist eine Übung erforderlich.
Die Lernenden müssen die Begriffe, die im Absatz direkt unter der Überschrift genannt werden,
nur dann wiedergegeben können (K1), wenn dies in den Lernzielen explizit angegeben ist.

Gesamtlehrplan
1. Curriculum Regulatorische Grundlagen

Dieses Modul beschreibt die regulatorischen Grundlagen für die Entwicklung von Software als
Medizinprodukt.
1.1. Rechtliche Grundlagen

1.1.1. Definition eines Medizinproduktes
1.1.1.1. Hintergrund
Entspricht ein Produkt der Definition eines Medizinproduktes, greifen regulatorische
Anforderungen durch den Gesetzgeber, unabhängig von der eigenen Einschätzung des
Herstellers. Die einwandfreie Abgrenzung ist notwendig, um als Hersteller nicht mit dem Gesetz
in Konflikt zu geraten.
1.1.1.2. Begriffe Foundation Level
 Medizinprodukt
 Anwendung am Menschen
 Software als Teil eines Medizinproduktes
 Software als eigenständiges medizinisches Produkt
 Zweckbestimmung
1.1.1.3. Begriffe Advanced Level
 Medizinprodukt
 Anwendung am Menschen
 Software als Teil eines Medizinproduktes
 Software als eigenständiges medizinisches Produkt
 Zweckbestimmung
 Zubehör
 Kombinationsprodukt
1.1.1.4. Definition eines Medizinproduktes nach Medizinprodukterichtlinie 93/42/EWG
Lehrziele
Nummer Lehrziel FL AL
M1-LE1.1-1-1 Wissen, wie ein Medizinprodukt in Europa definiert K1 W
ist.
M1-LE1.1-1-1 Verstehen, was ein Medizinprodukt kennzeichnet und -- K2
welche Abgrenzungen es gibt.
Lehrinhalte Foundation Level
Die Definition eines Medizinproduktes nach der Medizinprodukterichtlinie 93/42/EWG vom
September 2007 lautet wie folgt:
Alle einzeln oder miteinander verbunden verwendeten Instrumente, Apparate, Vorrichtungen,
Software, Stoffe oder anderen Gegenstände, einschließlich der vom Hersteller speziell zur
Anwendung für diagnostische und/oder therapeutische Zwecke bestimmten und für ein
einwandfreies Funktionieren des Medizinproduktes eingesetzten Software, die vom Hersteller zur
Anwendung für Menschen für folgende Zwecke bestimmt sind:
 Erkennung, Verhütung, Überwachung, Behandlung oder Linderung von Krankheiten;
 Erkennung, Überwachung, Behandlung, Linderung oder Kompensierung von Verletzungen
oder Behinderungen;
 Untersuchung, Ersatz oder Veränderung des anatomischen Aufbaus oder eines
physiologischen Vorgangs;
 Empfängnisregelung;
Gesamtlehrplan
und deren bestimmungsgemäße Hauptwirkung im oder am menschlichen Körper weder durch

pharmakologische oder immunologische Mittel noch metabolisch erreicht wird, deren
Wirkungsweise aber durch solche Mittel unterstützt werden kann.
Lehrinhalte Advanced Level
Die Abgrenzung zwischen Medizinprodukten und anderen Produkten, beispielsweise
Arzneimitteln, ist nicht immer einfach. Vor allem, wenn physikalische Geräte und Arzneimittel
kombiniert werden, ist die Trennung schwierig.
Beispielsweise ist ein Stent, der zur Verhinderung von Abstoßungsreaktionen mit einem
Medikament überzogen ist, ein Medizinprodukt, da die Hauptwirkung die mechanische Stützung
eines Gefäßes ist.
Ein Rheuma-Pflaster dagegen, das ein Arzneimittel über einen längeren Zeitraum abgibt, ist ein
Medikament, da die Hauptwirkung die pharmakologische ist.
Kennzeichen eines Medizinproduktes:
 Für die Anwendung am Menschen bestimmt
 Erkennung, Behandlung und Überwachung von Krankheiten und Verletzungen
 Implantate und bildgebende Verfahren
 Nicht-medikamentöse Empfängnisregelung
Kein Medizinprodukt nach der obigen Definition:
 Schutzausrüstung (keine Verhütung von Verletzungen oder Behinderungen)
 Arzneimitteln (pharmakologische oder immunologische Wirkung)
 Trainingsgeräten (metabolische Wirkung)
1.1.1.5. Einordnung von Software in die Definition eines Medizinproduktes
Lehrziele
M1-LE1.1-2-1 Die Rolle von Software als Teil eines Medizinproduktes K2 W
oder als eigenständiges Medizinprodukt kennen und
verstehen.
Software wird explizit in der Definition eines Medizinproduktes in der Richtlinie aufgelistet. Damit
wurde klargestellt, dass Software auch ein eigenständiges Medizinprodukt sein kann. Ist Software
lediglich ein Teil eines Medizinproduktes, ist es unwichtig ob die Software medizinische
Funktionalität bereit stellt oder lediglich Steuerungsfunktionalität, solange die Software für ein
einwandfreies Funktionieren des Medizinproduktes notwendig ist. Die Anforderungen an ein
Medizinprodukt gelten somit in jedem Fall. Software als Medizinprodukt gilt gemäß Richtlinie als
aktives Medizinprodukt, da für dessen Funktionieren eine Spannungsversorgung notwendig ist.
Wiederholung FL.
1.1.2. Rechtliche Grundlagen in Europa
Die rechtliche Grundlage in Europa für Medizinprodukte wird von der europäischen Union durch
Richtlinien vorgegeben. Diese müssen von den Mitgliedsstaaten in nationales Recht überführt
werden. Als Hilfestellung für die Umsetzung der technischen Vorgaben in den Richtlinien und zum
Nachweis der Umsetzung dieser Vorgaben können Normen herangezogen werden.
 Europäische Richtlinie
 Medizinproduktegesetz
 harmonisierte Normen
Gesamtlehrplan

 Europäische Richtlinie
 harmonisierte Normen
 Normungsgremium
 Amtblatt der europäischen Union
1.1.2.4. Europäische Richtlinien
Lehrziele
M1-LE1.2-1-1 Die drei für Medizinprodukte relevanten europäischen K1 W
Richtlinien kennen.
M1-LE1.2-1-1 Die Ziele und Bedeutung einer europäischen Richtlinie K2 W
verstehen.
Für Entwicklung, Zulassung und Betreiben von Medizinprodukten innerhalb der europäischen
Union gelten drei Richtlinien:
 Richtlinie 93/42/EWG über Medizinprodukte (engl. Medical Device Directive, MDD)
 Richtlinie 98/79/EG über In-vitro-Diagnostika (IVDD)
 Richtlinie 90/385/EWG über aktive implantierbare medizinische Geräte (AIMDD)
Ziel der Richtlinien ist der Abbau von Handelshemmnissen innerhalb Europas und die
Formulierung grundlegender Anforderungen an ein Medizinprodukt, deren Einhaltung für das
Inverkehrbringen eines Medizinproduktes notwendig ist. Der Nachweis der Einhaltung dieser
grundlegenden Anforderungen wird mittels sogenannter Konformitätsbewertungsverfahren
erbracht.
Wiederholung FL.
1.1.2.5. Harmonisierte Normen
Lehrziele
M1-LE1.2-2-1 Den Begriff harmonisierte Norm kennen und die K2 K2
Bedeutung verstehen.
M1-LE1.2-2-1 Die relevanten Prozessnormen für Medizinprodukte K2 K2
kennen.
M1-LE1.2-2-1 Wissen, welche Organisationen Normen erstellen und K1 K2
wodurch diese zu harmonisierten Normen werden.
Die harmonisierten Normen wurden von der europäischen Kommission als Hilfsmittel zur
Umsetzung der grundlegenden Anforderungen an ein Medizinprodukt eingeführt. Normen geben
einem Hersteller konkrete technische Vorgaben an die Auslegung und Konstruktion des
Medizinproduktes. Harmonisierte Normen decken die grundlegenden Anforderungen der
Richtlinien ab. Daher gilt innerhalb der EU das „Vermutungsprinzip“, wonach bei Konformität mit
einer harmonisierten Norm vermutet werden kann, dass die grundlegenden Anforderungen
eingehalten wurden. Die Anwendung ist für einen Hersteller jedoch nicht verpflichtend.
Unterschieden werden Produkt- und Prozessnormen. Produktnormen sind lediglich für eine
Produktgruppe anwendbar, während Prozessnormen generell anwendbar sind. Für
Medizinproduktehersteller sind im Softwarebereich meist alle der folgenden harmonisierten
Normen relevant:

Gesamtlehrplan
 EN ISO 13485 (Qualitätsmanagement)

 EN ISO 14971 (Risikomanagement)
 EN 62304 (Software Lebenszyklus)
 EN 62366 (Usability)
 EN 60601-1 3rd Edition, Kapitel 14 (Programmable Electrical Medical Systems), im Fall von
embedded Software
Harmonisierte Normen entstehen in europäischen Normungsgremien, wie dem Comité Européen
de Normalisation (CEN) oder dem Comité Européen de Normalisation Electrotechnique (CENELEC)
und werden von diesen veröffentlicht. Erarbeitet werden diese Normen in internationalen
Gremien wie der ISO oder der IEC. Die Umsetzung in nationale Normen erfolgt durch nationale
Normungsgremien, in Deutschland z.B. durch das DIN.
Normen werden von der EU durch Veröffentlichung im Amtsblatt der europäischen Kommission
als harmonisierte Normen gekennzeichnet.
1.1.2.6. Nationales Recht
Lehrziele
M1-LE1.2-3-1 Das Medizinproduktegesetz (MPG) als Umsetzung der K1 W
europäischen Richtlinien in nationales deutsches
Recht kennen.
Damit die europäischen Richtlinien in den Mitgliedsländern der EU rechtsverbindlich werden,
müssen diese innerhalb einer bestimmten Frist in nationales Recht umgesetzt werden. In
Deutschland wurden alle drei Richtlinien durch das Medizinproduktegesetz (MPG) umgesetzt.
Dieses Gesetz bildet die verbindliche Grundlage für Hersteller in Deutschland und enthält neben
den gesetzlichen Anforderungen aus den Richtlinien auch die Strafen, die bei Verstoß gegen das
Gesetz greifen.
Wiederholung FL.
1.1.2.7. Regulatorische Landkarte
Lehrziele
M1-LE1.2-4-1 Aufbau der regulatorischen Landkarte kennen. K1 K1
M1-LE1.2-4-1 Die Zusammenhänge zwischen europäischen K1 K2
Richtlinien, nationalen Gesetzen und harmonisierten
Normen kennen.
M1-LE1.2-4-1 Aufbau der regulatorischen Landkarte kennen und die -- K2
Verweise zwischen den einzelnen Richtlinien,
Gesetzen und Normen verstehen.
Zusammenhänge zwischen den europäischen Richtlinien, den nationalen Gesetzen und den
harmonisierten Normen.
Vertiefung des Verständnisses über die Verknüpfungen und Abhängigkeiten zwischen den
Normen, Gesetzen, Richtlinien und Verordnungen
1.2. Die europäischen Richtlinien und die nationale Umsetzung

Gesamtlehrplan
1.2.1. Richtlinie 93/42/EWG über Medizinprodukte

Die Richtlinie 93/42/EWG über Medizinprodukte ist die wichtigste Richtlinie für die Entwicklung
und das Inverkehrbringen von Medizingeräten in Europa. Die Richtlinie ist für alle
Mitgliedsstaaten der europäischen Union verbindlich. Mit Staaten, die nicht Mitglied der EU sind,
handelt die EU bilaterale Abkommen aus (Bsp. mit den EFTA Staaten, die die Richtlinien
anerkennen). Auf diese Weise gelten die Richtlinien faktisch für alle geographischen EU Staaten.
Gültigkeit für die Hersteller erlangt die Richtlinie durch die jeweilige Umsetzung in nationales
Recht. Die Richtlinie definiert die Kriterien für den freien Warenverkehr von Medizinprodukten
innerhalb des europäischen Binnenmarktes und die grundlegenden Anforderungen an ein
Medizinprodukt. Zudem enthält die Richtlinie die verschiedenen
Konformitätsbewertungsverfahren für Medizinprodukte.
 Grundlegende Anforderungen
 Produktklassifizierung
 Konformitätsbewertungsverfahren
 CE-Kennzeichen
 Grundlegende Anforderungen
 CE-Kennzeichen
1.2.1.4. Inhalt und Aufbau der Richtlinie
Lehrziele
M1-LE2.1-1-1 Den Inhalt und den Aufbau der europäischen Richtlinie K1 W
über Medizinprodukte kennen.
Die Richtlinie 93/42/EWG über Medizinprodukte besteht aus 23 Artikeln, die sich mit dem freien
Warenverkehr innerhalb Europas auseinandersetzen. Die Artikel behandeln daher weniger die
Anforderungen an Medizinprodukte und deren Technik, sondern vielmehr die Anforderungen an
das Inverkehrbringen und die Überwachung von Medizinprodukten und die dafür zuständigen
Stellen. Konkretere Anforderungen finden sich in den zwölf Anhängen. Der erste Anhang
beschreibt dabei die grundlegenden Anforderungen an ein Medizinprodukt, während die
Anhänge II-XII die Prüfungs- und Konformitätsbewertungsverfahren schildern.
Die Anhänge sind im Laufe des Produktlebenszyklus anzuwenden.
1.2.1.5. Grundlegende Anforderungen
Lehrziele
M1-LE2.1-2-1 Die Bedeutung und den Inhalt der Grundlegenden K2 K2
Anforderungen kennen.
Die grundlegenden Anforderungen stellen die technischen Mindestanforderungen an die
Sicherheit eines Medizinproduktes auf dem europäischen Markt dar. Die Sicherheit schließt dabei
nicht nur Patienten, sondern auch Anwender und Dritte explizit mit ein. Die Einhaltung dieser
Anforderungen ist die wichtigste Vorgabe an die Hersteller von Medizinprodukten, der Nachweis
der Erfüllung ist Voraussetzung für das Inverkehrbringen (CE-Kennzeichnung) des Produktes.

Gesamtlehrplan
Die grundlegenden Anforderungen beinhalten:

 Berücksichtigung von Lebenszyklus, Risikomanagement sowie Verifikation und Validierung
beim Einsatz von Software
 Berücksichtigung ergonomischer Aspekte bei der Produktauslegung
 Identifikation und Berücksichtigung des Wissensstandes und der Fähigkeiten der Benutzer
 Sicherstellung der Produktleistungen über die gesamte Lebensdauer einschl. Transport,
Lagerung und Alterung
 Minimierung der Risiken beim Einsatz potenziell gefährlicher Stoffe wie Chemikalien oder
Arzneimitteln
 Regelungen für sterile Produkte oder Produkte mit potenzieller Infektionsgefahr
 Sicherstellung der Genauigkeit und Verständlichkeit bei vorhandener Messfunktion
 Sicherstellung von Strahlenschutz
 Schutz des Anwenders und der Umgebung vor thermischen, mechanischen und elektrischen
Risiken
 Korrekte Bezeichnung und Bereitstellung von weiteren Informationen wie z.B. die
Zweckbestimmung
 Korrekte Bereitstellung und Inhalt einer Gebrauchsanweisung
Für den Nachweis über die Erfüllung der grundlegenden Anforderungen kann ein Hersteller das
Konzept der harmonisierten Normen nutzen oder ein anderes ihm als geeignet erscheinendes
Verfahren.
1.2.1.6. Grundsätze der integrierten Sicherheit
Lehrziele
M1-LE2.1-3-1 Die drei Möglichkeiten der Risikominderung inklusive K2 W
der Priorität der Maßnahmen verstehen.
Für die Risikominderung schreibt die Richtlinie allen Herstellern vor sich nach den folgenden
Grundsätzen der integrierten Sicherheit zur Risikominimierung zu richten:
1. Beseitigung oder Minimieren des Risikos durch entsprechende Auslegung des Produktes
2. Integration angemessener Schutzmaßnahmen in das Produkt
3. Information des Benutzers über vorhandene Risiken
Die Reihenfolge der Maßnahmen bildet ebenso die Priorität der Maßnahmen ab. Die Prioritäten
müssen soweit möglich beachtet werden, um eine maximale Risikominderung zu erreichen.
1.2.1.7. Produktklassifizierung nach Vorgabe der Richtlinie
Lehrziele
M1-LE2.1-4-1 Wissen, in welchen Klassen Medizinprodukte K1 W
eingeteilt werden.
M1-LE2.1-4-1 Die Regeln der Produktklassifizierung kennen. K1 W
M1-LE2.1-4-1 Die Regeln der Produktklassifizierung für Software an -- K2
einem Beispiel anwenden können.
Medizinprodukte müssen anhand vorgegebener Klassifizierungsregeln einer von vier Klassen
zugeordnet werden. Die vier Klassen untergliedern sich in I, IIa, IIb oder III, wobei Klasse I die
risikoärmsten Medizinprodukte umfasst und Klasse III die risikoreichsten Medizinprodukte.
Anhang IX der Richtlinie enthält alle Definitionen, Anwendungsregeln und Klassifizierungsregeln,
nach denen Hersteller Medizinprodukte klassifizieren müssen. Die Klassifizierungsregeln basieren

Gesamtlehrplan
auf der Verletzbarkeit des menschlichen Körpers und berücksichtigen die potenziellen Risiken im
Zusammenhang mit der technischen Auslegung der Produkte und mit ihrer Herstellung.
Software wird immer als aktives Produkt betrachtet, daher gelten für Software folgende Regeln:
 Software, die ein Produkt steuert oder dessen Anwendung beeinflusst, wird automatisch
derselben Klasse zugerechnet wie das Produkt. Software, die Teil eines Medizinproduktes ist,
wird daher nicht eigenständig klassifiziert.
 Software als eigenständiges Medizinprodukt wird wie jedes andere Medizinprodukt
klassifiziert.
 Software als Zubehör wird unabhängig von dem Produkt, mit dem es verwendet wird,
gesondert klassifiziert.
Die Klassifikation von Medizinprodukten richtet sich nach einer ganzen Reihe von Regeln, die in
Anhang IX der Medizinprodukte-Richtlinie zu finden sind.
Grundsätzlich wird Software, die ein Medizinprodukt steuert oder beeinflusst, in die selbe Klasse
eingeordnet wir das zugehörige Medizinprodukt. Zu beachten ist dabei, dass Software stets als
aktives Medizinprodukt angesehen wird. Für aktive Medizinprodukte gelten zusätzliche Regeln.
Wesentliche Aspekte, die die Klassifizierung von Medizinprodukten beeinflussen, sind:
 Invasive oder nicht-invasive Anwendung
 vorübergehende oder dauernde Anwendung
 Anwendung am Herzen oder zentralen Kreislaufsystem
So wird beispielsweise eine Software zur Steuerung eines Dialyse-Geräts wie das Gerät selbst in
die Klasse IIb eingeordnet.
Soll eigenständige Software klassifiziert werden, so ist die Anwendung dieser Regeln mitunter
schwierig. Hierzu gibt es eine Richtlinie "MEDDEV 2.1/6", die einen Algorithmus zur Beurteilung
der Frage, ob die Software ein Medizinprodukt ist, definiert.
Der Algorithmus stellt folgende Fragen:
1. Ist die Software ein Computerprogramm? Wenn nicht, handelt es sich nicht um ein
Medizinprodukt
2. Ist die Software Teil eines Medizinprodukts? Dann wird entsprechend der Klassifikation des
Medizinproduktes weiter verfahren.
3. Erfüllt die Software nur einfache Aufgaben (Speicherung, Archivierung, verlustfreie
Kompression, Kommunikation oder einfache Suche? Dann handelt es sich nicht um ein
Medizinprodukt
4. Dient die Software dem Wohl individueller Patienten? Wenn nicht, dann handelt es sich um
kein Medizinprodukt
5. Dient die Software einem medizinischen Zweck im Sinne der MDD? Dann liegt eine Software
als eigenständiges Medizinprodukt vor. Wenn nicht, dann ist zu prüfen, ob es sich eventuell
um ein Zubehör zu einem Medizinprodukt handelt.
Als Beispiel für Software als eigenständiges Medizinprodukt werden unter anderem genannt:
 ein Planungssystem für die Strahlentherapie ist ein Medizinprodukt der Klasse IIb
 Software zur Präsentation von klinischen Parametern in Routine-Untersuchungen ist ein
Medizinprodukt der Klasse IIa
 Software zur Präsentation von klinischen Parametern auf Intensivstationen ist ein
Medizinprodukt der Klasse IIb
1.2.1.8. Sonderanfertigungen
Lehrziele
M1-LE2.1-5-1 Wissen, was ein Zubehör und was eine K1 W
Gesamtlehrplan
Sonderanfertigung ist.
M1-LE2.1-5-1 Die Anforderungen an Sonderanfertigungen kennen. -- K1
Zubehör zu einem Medizinprodukt ist ein Gegenstand, der selbst kein Medizinprodukt ist, aber
zusammen mit einem Medizinprodukt zu verwenden ist, damit dieses entsprechend seiner
Zweckbestimmung eingesetzt werden kann.
Eine Sonderanfertigung ist ein Produkt, das aufgrund einer ärztlichen Verordnung für einen
namentlich bekannten Patienten angefertigt wird. Beispiele für Sonderanfertigungen sind Brillen
oder Hörgeräte, die speziell für einen Patienten angepasst werden.
Sonderanfertigungen müssen allen Vorgaben der Medizinprodukte-Richtlinie genügen. Im
Gegensatz zu Serienprodukten tragen sie jedoch keine CE-Kennzeichnung. Der Hersteller muss
eine Dokumentation erstellen, aus der hervorgeht, dass das Produkt die Grundlegenden
Anforderungen erfüllt.
1.2.1.9. Technische Dokumentation
Lehrziele
M1-LE2.1-6-1 Inhalt und Umfang der technischen Dokumentation K2 --
verstehen.
Die technische Dokumentation eines Medizinproduktes dient der Bewertung der Konformität
eines Produktes mit den grundlegenden Anforderungen der anzuwendenden Richtlinie. Jeder
Hersteller ist verpflichtet, diese Dokumentation zu erstellen. Dabei ist es dem Hersteller
freigestellt, ob die technische Dokumentation aus einem zusammenhangendem Dokument oder
aus mehreren Dokumenten aus unterschiedlichen Quellen besteht, wie beispielsweise
Risikoanalyse, Bedienungsanleitung, Fertigungszeichnungen usw. Ein Hersteller muss jedoch in
der Lage sein, alle relevanten Informationen in angemessener Zeit zur Verfügung zu stellen.
1.2.1.10. Konformitätsbewertungsverfahren
Lehrziele
M1-LE2.1-7-1 Wissen, was eine Konformitätsbewertung ist. K1 W
M1-LE2.1-7-1 Die verschiedenen Konformitätsbewertungsverfahren K1 K2
kennen und verstehen. Das Ziel und den Ablauf eines
Konformitätsbewertungsverfahrens verstehen und
den Einfluss der Produktklassifizierung auf das
Konformitätsbewertungsverfahren kennen.
Je nach Klassifizierung eines Produktes sind in Abhängigkeit von der Klasse des Produktes
verschiedene Konformitätsbewertungsverfahren möglich.
Nach Anhang VII:
Für Produkte der Klasse I und IIa: Der Hersteller muss mittels einer Konformitätserklärung
bestätigen, dass sein Produkt die grundlegenden Anforderungen der Richtlinie erfüllt. Zudem
muss er die technische Dokumentation für das Klasse I Produkt erstellen, die den Nachweis über
die Erfüllung der grundlegenden Anforderungen erbringt. Notwendig ist weiterhin ein System zur
Marktüberwachung nach Inverkehrbringen des Produktes und zur Durchführung von Korrekturen
am Produkt. Das Hinzuziehen einer Benannten Stelle ist für Klasse I Produkte ohne Messfunktion
nicht notwendig.
Nach Anhang II:
Gesamtlehrplan
Für Produkte der Klasse IIa, IIb und III: Hersteller, die ein Konformitätsbewertungsverfahren nach
Anhang II benutzen, müssen ein Qualitätsmanagementsystem aufbauen und dieses durch ein
Audit einer Benannten Stelle zertifizieren und regelmäßig überprüfen lassen. Die Zertifizierung
erfolgt in der Regel nach ISO 13485.
Nach Anhang III:
Für Produkte der Klasse IIb und III: Ein Konformitätsbewertungsverfahren nach Anhang III prüft
die Auslegung und das Design eines Medizinproduktes und muss um ein
Konformitätsbewertungsverfahren ergänzt werden, welches die Produktion überprüft. Für die
Baumusterprüfung muss der Hersteller ein Baumuster seines Produktes und die dazugehörige
technische Dokumentation an eine Benannte Stelle übergeben, die das Baumuster auf
Konformität zu den grundlegenden Anforderungen und Übereinstimmung mit der
Dokumentation überprüft.
Nach Anhang IV:
Als Ergänzung zu Anhang III: Der Hersteller übergibt an die Benannte Stelle ein fertiges Produkt
zur Prüfung, um zu zeigen, dass er in der Lage ist das Baumuster korrekt zu reproduzieren.
Nach Anhang V:
Als Ergänzung zu Anhang III. Mit dem Konformitätsbewertungsverfahren nach Anhang V wird der
Produktionsprozess eines Herstellers geprüft und zertifiziert. Auch hier ist das Ziel sicherzustellen,
dass ein Hersteller in der Lage ist, ein Produkt korrekt reproduzieren.
Nach Anhang VI:
Als Ergänzung zu Anhang III. Das Konformitätsbewertungsverfahren zur Qualitätssicherung des
Produktes zielt auf die Endkontrolle der Fertigung. Auch hier ist eine Zertifizierung durch eine
Benannte Stelle notwendig, um die Produktion von konformen Produkten zu gewährleisten.
Für Software wird in der Regel das Konformitätsbewertungsverfahren nach Anhang II
angewendet, da alle anderen Bewertungsverfahren von den Benannten Stellen als nicht adäquat
eingeschätzt werden und weil die IEC 62304 ein Qualitätsmanagement System fordert. Zudem
gibt es keine Trennung zwischen Entwicklung und Produktion.
1.2.1.11. CE Kennzeichnung
Lehrziele
M1-LE2.1-8-1 Die Bedeutung des CE-Kennzeichens für den K1 W
europäischen Markt kennen.
Die CE-Kennzeichnung ist innerhalb Europas die sichtbare Kennzeichnung, dass ein Produkt den
grundlegenden Anforderungen der Richtlinie entspricht und somit in Verkehr gebracht werden
kann. Die Kennzeichnung wird vom Hersteller selbst angebracht.
Für Produkte der Klasse I (ohne sterile Teile und ohne Messfunktion) kann ein Hersteller die CE-
Kennzeichnung ohne Hinzuziehung einer Benannten Stelle anbringen. Wenn für ein höher
klassifiziertes Produkt eine Benannte Stelle hinzugezogen wurde, muss deren vierstellige
Kennnummer hinter der Kennzeichnung angegeben werden.
1.2.2. Richtlinie 98/79/EG über In-vitro-Diagnostika
Die Richtlinie 98/79/EG über In-vitro-Diagnostika enthält alle Anforderungen an Geräte oder
Produkte, die der Definition der Richtlinie entsprechen. Vom Aufbau ähnelt die Richtlinie der
Medizinprodukterichtlinie, enthält jedoch abweichende spezifische Vorgaben an diese
Geräteklasse und spezifische harmonisierte Normen.

Gesamtlehrplan
 CE-Kennzeichen
 In-Vitro-Diagnostik
 CE-Kennzeichen
 In-Vitro-Diagnostik
Lehrziele
M1-LE2.2-1-1 Die Definition eines In-vitro Diagnostikum und den K1 W
Inhalt und den Aufbau der europäischen Richtlinie
kennen.
Die Richtlinie über In-vitro Diagnostika beschäftigt sich mit Geräten die organische Vorgänge
beobachten oder beeinflussen, welche außerhalb des Körpers stattfinden.
Nach der Definition der Richtlinie ist „jedes Produkt, das als Reagenz, Reagenzprodukt,
Kalibriermaterial, Kontrollmaterial, Kit, Instrument, Apparat, Gerät oder System – einzeln oder in
Verbindung miteinander – nach der vom Hersteller festgelegten Zweckbestimmung zur In-vitro-
Untersuchung von aus dem menschlichen Körper stammenden Proben, einschließlich Blut- und
Gewebespenden, verwendet wird und ausschließlich oder hauptsächlich dazu dient,
Informationen zu liefern
 Über physiologische oder pathologische Zustände oder
 Über angeborene Anomalien oder
 Zur Prüfung auf Unbedenklichkeit und Verträglichkeit bei potentiellen Empfängern oder
 Zur Überwachung therapeutischer Maßnahmen
Die Richtlinie besteht aus 24 Artikeln und 10 Anhängen, die inhaltlich sehr nah an der
Medizinprodukterichtlinie liegen. In den grundlegenden Anforderungen wird jedoch auf größere
Exaktheit der Messungen Wert gelegt, so dass z.B. Messverfahren und mathematische Ansätze in
der Gebrauchsanweisung beschrieben sein müssen.
1.2.2.5. Konformitätsbewertungsverfahren für In-vitro-Diagnostika
Lehrziele
M1-LE2.2-2-1 Die Konformitätsbewertungsverfahren für In-vitro- -- K2
Diagnostika kennen und verstehen
Für ein Konformitätsbewertungsverfahren ist, wie in der Medizinprodukterichtlinie, zunächst eine
Klassifizierung notwendig. Diese basiert bei der In-vitro-Diagnostika Richtlinie nicht auf einem
Regelwerk, sondern auf vorgefertigte Listen, in die bereits konkrete Produkte eingeordnet
wurden und sich im Anhang II befinden.
Liste A: Blutgruppenbestimmung, Test auf HIV, Hepatitis
Liste B: Blutzuckerbestimmung oder Risikoabschätzung für Trisomie 21
Sonstige: Umfasst alle sonstigen In-vitro-Diagnostika
Für die Wahl des Konformitätsbewertungsverfahrens gibt es, abhängig von der Klasse des
Produktes, verschiedene Verfahren:

Gesamtlehrplan
Nach Anhang III

Für "sonstige" Produkte. Nach Anhang III ist vom Hersteller eine Konformitätserklärung
abzugeben und die notwendige Dokumentation zu erstellen. Das CE-Kennzeichen kann vom
Hersteller selbständig angebracht werden.
Nach Anhang IV
Für Produkte der Klasse A und B. Bei diesem Konformitätsbewertungsverfahren muss ein
Hersteller ein zertifiziertes Qualitätsmanagementsystem vorweisen können und dies durch
regelmäßige Audits von einer Benannten Stelle überprüfen lassen. Bei der CE-Kennzeichnung
muss die vierstellige Kennnummer einer Benannten Stelle hinter der Kennzeichnung angegeben
werden.
Nach Anhang V
Für Produkte der Klasse A und B. Ein Konformitätsbewertungsverfahren nach Klasse V setzt auf
den zweistufigen Aufbau mit Prüfung eines Baumusters und nachfolgender Zertifizierung des
Produktionsprozesses (Anhang VI) oder der Endkontrolle (Anhang VII). Bei der CE-Kennzeichnung
muss die vierstellige Kennnummer einer Benannten Stelle hinter der Kennzeichnung angegeben
werden.
1.2.3. Richtlinie 90/385/EWG über aktive implantierbare medizinische Geräte
Die Richtlinie 90/385/EWG über aktive implementierbare medizinische Geräte bezieht sich auf
den Spezialfall eines aktiven Medizinproduktes, das dazu bestimmt ist, dauerhaft im
menschlichen Körper zu verbleiben. Aufgrund dieser Eigenschaft ergeben sich einige
Unterschiede zur Richtlinie über Medizinprodukte.
 CE-Kennzeichen
 Implantierbare medizinische Geräte
 CE-Kennzeichen
 Implantierbare medizinische Geräte
Lehrziele
M1-LE2.3-1-1 Die Definition eines aktiven-implementierbaren K1 W
medizinischen Gerätes und den Inhalt und den Aufbau
der europäischen Richtlinie kennen
Aktive implementierbare Geräte bilden einen Spezialfall unter den Medizinprodukten, da sie
ebenso der Definition der Medizinprodukterichtlinie entsprechen. Aufgrund des Einsatzgebietes
und Zwecks ergeben sich jedoch Unterscheidungen, die in dieser Richtlinie behandelt werden. Ein
aktives medizinisches Gerät ist nach Definition der Richtlinie somit:
„Jedes aktive medizinische Gerät, das dafür ausgelegt ist, ganz oder teilweise durch einen
chirurgischen oder medizinischen Eingriff in den menschlichen Körper oder durch einen
medizinischen Eingriff in eine natürliche Körperöffnung eingeführt zu werden und dazu bestimmt
ist, nach dem Eingriff dort zu verbleiben.“
Gesamtlehrplan
Die beiden Richtlinien sind weitgehend deckungsgleich, jedoch spielt die Gebrauchstauglichkeit in
diesem Fall keine Rolle.
1.2.3.5. Konformitätsbewertungsverfahren für aktive implementierbare medizinische Geräte
Lehrziele
M1-LE2.3-2-1 Konformitätsbewertungsverfahren für aktive -- K2
implementierbare medizinische Geräte kennen und
verstehen
Für das Konformitätsbewertungsverfahren von aktiven implantierbaren medizinischen Geräten
gelten ähnliche Regelungen wie für Medizinprodukte der Klasse III.
Nach Anhang 2: Aufbau und Zertifizierung eines vollständigen Qualitätsmanagementsystems und
regelmäßige Überprüfung dieses Systems.
Nach Anhang 3: Prüfung eines Baumusters und nachfolgender EG-Prüfung des Produktes (Anhang
4) oder Zertifizierung des Produktionsprozesses (Anhang 5).
Die CE-Kennzeichnung muss mit der vierstelligen Nummer einer beteiligten Benannten Stelle
angegeben werden, eine Konformitätserklärung ohne Beteiligung einer Benannten Stelle ist nicht
vorgesehen.
1.2.4. Nationale Umsetzung am Beispiel des Medizinproduktegesetzes
Das Medizinproduktegesetz (MPG) ist die nationale Umsetzung der europäischen Richtlinien
93/42/EWG, 90/385/EWG und 98/79/EG für Deutschland und somit gültiges Recht für alle
Hersteller und Betreiber von Medizinprodukten in Deutschland.
 nationale Umsetzung
 nationale Ausnahmen und Besonderheiten
 Strafen und Bußgelder
 nationale Umsetzung
 nationale Ausnahmen und Besonderheiten
 Strafen und Bußgelder
1.2.4.4. Inhalt und Aufbau des MPG
Lehrziele
M1-LE2.4-1-1 Den Inhalt des MPG und die nationalen K1 W
Bestimmungen kennen.
Das deutsche Medizinproduktegesetz umfasst 44 Paragraphen, die in 9 Abschnitte gegliedert
sind. Die ersten 6 Abschnitte setzen die Vorgaben der Richtlinien teilweise wörtlich um, während
die verbleibenden drei Abschnitte nationale Gegebenheiten beinhalten.
Abschnitt sieben beinhaltet Sondervorschriften für die Bundeswehr, so ist es z.B. erlaubt, für
Medizinprodukte, die für die Bundeswehr bestimmt sind, auf die Angabe eines Verfalldatums zu
verzichten. Zudem ermöglicht dieser Abschnitt der Bundeswehr, in Einzelfällen Ausnahmen vom
Gesetz zuzulassen.
Gesamtlehrplan
Abschnitt acht regelt die Straf- und Bußgeldvorschriften für Verstöße gegen das MPG. Diese
bewegen sich zwischen Bußgeldern bei kleineren Verstößen bis hin zu Freiheitsentzug von bis zu
5 Jahren bei schweren Fällen, wenn beispielsweise grober Eigennutz vorliegt, die Gesundheit
einer großen Zahl von Menschen gefährdet wurde oder Menschen verletzt bzw. zu Tode
gekommen sind.
Abschnitt neun regelt die Übergangsvorschriften.
Zu beachten ist, dass das MPG selbst keine Anhänge führt, um beispielsweise die grundlegenden
Anforderungen zu listen oder die Konformitätsbewertungsverfahren zu beschrieben, sondern auf
die Anhänge der einzelnen Richtlinien verweist.
1.2.4.5. Besonderheiten des MPG gegenüber den europäischen Richtlinien
Lehrziele
M1-LE2.4-2-1 Die nationalen Ergänzungen gegenüber den -- K1
europäischen Richtlinien kennen.
Das MPG kennt einige Besonderheiten als Ergänzung zu den Richtlinien, da diese nur ein
Mindestmaß vorgeben.
Sicherheitsbeauftragter für Medizinprodukte:
Jeder Hersteller, der seinen Sitz in Deutschland hat, ist verpflichtet einen Sicherheitsbeauftragten
namentlich zu benennen. Die benannte Person muss die hierfür notwendige Sachkenntnis
vorweisen können. Die Aufgabe eines Sicherheitsbeauftragten für Medizinprodukte ist die
Sammlung und Bewertung von Meldungen über Risiken bei Medizinprodukten und die
Koordination von notwendig werdenden Maßnahmen. Zudem ist die Anzeigepflicht von Risiken,
die eigene Medizinprodukte betreffen, Aufgabe des Sicherheitsbeauftragten.
Medizinprodukteberater:
Der Medizinprodukteberater wurde in Deutschland (und in Österreich) eingeführt, um Kunden
verlässliche Informationen über Medizinprodukte zu bieten, besonders im Bereich der
telefonischen Beratung und Information. Zu den Aufgaben gehört auch die Einweisung von
Personal in die Handhabung eines Medizinproduktes.
Medizinprodukte aus Eigenherstellung:
Als Medizinprodukte aus Eigenherstellung (und das Zubehör) gelten alle Produkte, die von
Gesundheitseinrichtungen hergestellt und angewendet werden, ohne in den Verkehr gebracht zu
werden oder unter die Definition von Sonderanfertigungen zu fallen.
Medizinprodukte aus Eigenherstellung besitzen den gleichen Status wie Sonderanfertigungen.
1.2.4.6. Verordnungen als Ergänzungen zum MPG
Lehrziele
M1-LE2.4-3-1 Die deutschen Verordnungen zur Ergänzung des MPG -- K1
kennen und den Inhalt der wichtigsten Verordnungen
kennen
Das Medizinproduktegesetz wird vom Gesetzgeber durch verschiedene Verordnungen ergänzt.
Für Deutschland sind diese:
 Medizinprodukte-Verordnung (MPV)
 Medizinprodukte-Sicherheitsplanverordnung (MPSV)
 Medizinprodukte-Betreiberverordnung (MPBetrV)
 DIMDI-Verordnung (DIMDIV)
 Medizinprodukte-Gebührenverordnung (Medizinprodukte-GebuehrenV)
Gesamtlehrplan
 Verordnung über die Verschreibungspflicht von Medizinprodukten (MPVerschrV)

 Verordnung über Vertriebswege für Medizinprodukte (MPVertrV)
 Verordnung über klinische Prüfungen von Medizinprodukten (MPKPV)
Die Medizinprodukte-Verordnung:
Diese Verordnung beschreibt die Konformitätsbewertungsverfahren der drei europäischen
Richtlinien und setzt zusätzlich die Richtlinie 2005/50/EG zur Neuklassifizierung von Gelenkersatz
für Hüfte, Knie und Schulter im Rahmen der Richtlinie 93/42/EWG über Medizinprodukte in
deutsches Recht um. Diese Richtlinie stellt die Gelenkersatzprodukte unter Klasse III, unabhängig
von der Klassifizierung nach den Klassifizierungsregeln des MDD.
Die Medizinprodukte-Sicherheitsplanverordnung:
Diese Verordnung führt alle Fristen zur Meldungen über Vorkommnisse mit Medizinprodukten,
und deren Handhabung und Bewertung auf und beschreibt die zu treffenden Maßnahmen der
Hersteller. Des Weiteren beschreibt die Verordnung die zuständigen behördlichen Stellen.
Die Medizinprodukte-Betreiberverordnung:
Diese Verordnung richtet sich an die Betreiber von Medizinprodukten und beschreibt Tätigkeiten
zum Errichten, Betreiben, Anwenden und Instandhalten von Medizinprodukten. Zudem wird den
Betreibern durch diese Verordnung auferlegt, ein Medizinproduktebuch zu führen, in dem
Einweisungen, Kontrollen, Funktionsstörungen und ähnliche Informationen festgehalten werden
müssen. Außerdem müssen die Betreiber ein Bestandsverzeichnis aller nicht implantierbaren
Medizinprodukte führen und regelt die Aufbewahrung von Gebrauchsanweisungen und des
Medizinproduktebuches.
1.2.4.7. Nationale Umsetzung in den europäischen Mitgliedsstaaten
Lehrziele
M1-LE2.4-4-1 Eine Auswahl von Gesetzen kennen, durch die in -- K1
anderen europäischen Ländern die Richtlinien in
nationales Recht umgesetzt werden
Liste der nationalen Umsetzung in Europa:
UK:
 Statutory Instruments 2002 No. 618 + Amendments aus den Jahren 2003, 2007, 2008
Spanien:
 REAL DECRETO 414/1996, DE 1 DE MARZO, QUE DESARROLLA LA REGULACIÓN PRODUCTOS
SANITARIOS
Italien:
 Umsetzung MDD: DECRETO LEGISLATIVO 24 febbraio 1997, n.46
 Umsetzung AIMD: DECRETO LEGISLATIVO 14 dicembre 1992, n.507
 Umsetzung IVD: DECRETO LEGISLATIVO 8 settembre 2000, n.332
Frankreich:
 Code de la santé publique, Teil 5, Buch II, Titel I
Niederlande:
 Wet op de medische hulpmiddelen
Schweiz (nicht in der EU, hat aber das Regelwerk der EU übernommen):
 Heilmittelgesetz
Österreich:
Gesamtlehrplan
1.3. Die harmonisierten Normen

1.3.1. EN ISO 13485: Qualitätsmanagementsysteme - Anforderungen für
regulatorische Zwecke
Die EN ISO 13485 beschreibt die Anforderungen an ein Qualitätsmanagementsystem, die für eine
Zertifizierung des QM-Systems zur Entwicklung und Herstellung von Medizinprodukten beachtet
werden müssen.
 Qualitätsmanagement
 ISO 9001
 zertifiziertes Qualitätsmanagement-System
 ISO 9001
 zertifiziertes Qualitätsmanagement-System
1.3.1.4. Ziel und Bedeutung der ISO 13485
Lehrziele
M1-LE3.1-1-1 Die Bedeutung der Norm kennen und die Ziele, die die K2 W
Norm verfolgt, verstehen.
Die ISO 13485 beschreibt die Mindestanforderungen an ein durch den Hersteller aufzubauendes
Qualitätsmanagementsystem. Grundlage der ISO 13485 bildet die allgemeine Qualitätsnorm ISO
9001, die um relevante Aspekte aus der Medizintechnik ergänzt wurde, wie beispielsweise
Anforderungen an die Sterilität von Medizinprodukten. Im Vergleich mit der ISO 9001 wurden
auch ein paar Aspekte weggelassen, etwa die Verpflichtung zu stetiger Prozessverbesserung.
Die ISO 13485 enthält alle Anforderungen an ein Qualitätsmanagementsystem, die für ein
Konformitätsbewertungsverfahren nach Anhang II der MDD notwendig sind. Die Konformität zu
der Norm wird durch ein Audit von einer Benannten Stelle überprüft und mittels einer
Zertifizierung bestätigt.
Wiederholung FL.
1.3.2. EN ISO 14971: Anwendung des Risikomanagements auf Medizinprodukte
Risikomanagement beschreibt die Vorgehensweise für die Analyse und Minderung von Risiken
und ist damit ein integraler Bestandteil aller Aktivitäten zur Gewährleistung der Sicherheit von
Medizinprodukten.
 Risikomanagement
 Risikomanagement-Prozess
 Risikoanalyse
 Risikominimierung
 Restrisiko
Gesamtlehrplan
 Risikomanagementakte
 Risikomanagement
 Risikomanagement-Prozess
 Risikoanalyse
 Risikominimierung
 Restrisiko
1.3.2.4. Inhalt und Bedeutung der ISO 14971
Lehrziele
M1-LE3.2-1-1 Den Inhalt der Norm kennen und die Bedeutung des K2 W
Risikomanagements verstehen.
Die EN ISO 14971 beinhaltet einen Prozess zur Identifizierung, Bewertung und Kontrolle von
Gefährdungen für Patienten, Benutzern und Dritten durch ein Medizinprodukt, der sich über den
kompletten Lebenszyklus eines Medizinproduktes erstreckt.
Der Risikomanagementprozess gliedert sich grob in die Aktivitäten Risikoanalyse,
Risikobewertung und Risikokontrolle. Ein Hersteller muss sicherstellen, dass durch die zur
Risikokontrolle herangezogenen Maßnahmen zur Risikominderung keine weiteren unakzeptablen
Risiken entstehen. Restrisiken und das Gesamtrisiko des Produktes müssen nach Ergreifen von
Risikominderungsmaßnahmen evaluiert werden um sicherzustellen, dass der medizinische
Nutzen das verbleibende Restrisiko überwiegt. Abschließend fordert die Norm die Einrichtung
eines Mechanismus zur Sammlung und Auswertung von risikorelevanten Informationen nach dem
Inverkehrbringen.
1.3.2.5. Schnittstellen zur EN ISO 14971
Lehrziele
M1-LE3.2-2-1 Die Normen, die auf die EN ISO 14971 verweisen -- K2
kennen und den Sinn und Zweck der Verweise kennen
und verstehen.
Aufgrund der zentralen Positionierung der EN ISO 14971 für die Sicherheit eines
Medizinproduktes verweisen die harmonisierten Normen an verschiedenen Stellen auf die EN ISO
14971.
Verweis in der EN ISO 13485 in Kapitel 7.1, Planung der Produktrealisierung
Normativer Verweis in der EN 62304, Kapitel 2.
Verweise in
 Kapitel 4.2, Risikomanagement;
 Kapitel 4.3, Software Sicherheitsklassifizierung;
 Kapitel 7.1.1, Identifikation von Software-Komponenten, die zu einer Gefährdungssituation
beitragen könnten;
 Kapitel 7.1.4, Dokumentation möglicher Ursachen;
 Kapitel 7.2.2, Risikokontroll-Maßnahmen, die in Software implementiert werden;
 Kapitel 7.3.3, Dokumentation der Rückverfolgbarkeit
 weitere Verweise in den Anhängen
Normativer Verweis in der EN 62366, Kapitel 2.

Gesamtlehrplan
Verweise in
 Kapitel 4.1.2, Restrisiko;
 Kapitel 4.1.3, Sicherheitshinweise;
 Kapitel 5.3.1, Ermittlung sicherheitsbezogener Merkmale;
 Kapitel 5.3.2, Ermittlung bekannter oder vorhersehbarer Gefährdungen und
Gefährdungssituationen;
 Kapitel 5.5, Spezifikation der Gebrauchstauglichkeit;
 Kapitel 5.6, Validierungsplan für Gebrauchstauglichkeit;
 Kapitel 5.7, Gestaltung und technische Umsetzung der Benutzer-Produkt-Schnittstelle;
 Kapitel 5.9, Validierung der Gebrauchstauglichkeit
 weitere Verweise in den Anhängen
1.3.3. EN 62304: Software-Lebenszyklus-Prozesse
Die EN 62304 beschreibt die Prozesse entlang des Software-Lebenszyklus, von der Entwicklung bis
zur Freigabe der Software.
 Software-Entwicklungsprozess
 Verifizierung
 Änderungen an Software
 Wartung von Software
 Software-Sicherheitsklassifizierung
 Software-Entwicklungsprozess
 Verifizierung
 Änderungen an Software
 Wartung von Software
 Software-Sicherheitsklassifizierung
1.3.3.4. Inhalt der EN 62304
Lehrziele
M1-LE3.3-1-1 Den Inhalt der EN 62304 kennen. K1 W
Die EN 62304 enthält fünf Prozesse, die entlang des Software-Lebenszyklus ausgeführt werden:
1. Software-Entwicklungsprozess: Der Software-Entwicklungsprozess beschreibt die Aktivitäten
der Softwareentwicklung von der Planung bis zur Freigabe
2. Software Wartungsprozess: Der Wartungsprozess beschreibt das Vorgehen bei Änderungen
an Software und verweist für die Implementierung eines Änderungsantrags auf den Software-
Entwicklungsprozess
3. Software-Risikomanagementprozess: Der Prozess verweist auf die ISO 14971 und ergänzt
diese um softwarespezifische Aspekte.
4. Software-Konfigurationsmanagementprozess: Dieser Prozess beschreibt die Anforderungen
an die Identifizierung von Konfigurationen, Versionen und Fremdsoftware sowie die
Freigaben von Änderungen.
5. Software-Problemlösungsprozess: Beschreibt die Erstellung von Problemberichten, die
Untersuchung eines Problems und die Anwendung des Software-
Konfigurationsmanagementprozesses.
1.3.3.5. Schnittstelle zur Systementwicklung
Gesamtlehrplan
Lehrziele
M1-LE3.3-2-1 Die Abgrenzung zur System-Validierung und Freigabe K2 W
kennen und verstehen.
Die EN 62304 beschreibt alle Tätigkeiten der Softwareentwicklung bis zur Freigabe der Software,
klammert dabei jedoch explizit die Validierung und Freigabe eines Medizinproduktes als
Gesamtsystem aus.
1.3.4. EN 62366 - Anwendung der Gebrauchstauglichkeit auf Medizinprodukte
Die EN 62366 bzw. die EN ISO 60601-1-6 beschreiben die Anforderungen an die Sicherheit von
Medizinprodukten aus Sicht der Benutzbarkeit.
 Gebrauchstauglichkeit
 Usability
 Usability
1.3.4.4. Inhalt und Bedeutung der EN 62366
Lehrziele
M1-LE3.4-1-1 Den Sinn und Zweck der Norm EN 62366 kennen und K2 W
verstehen und die Bedeutung von
Gebrauchstauglichkeit für Medizinprodukte verstehen.
Die IEC 62366 beschreibt einen Entwicklungsprozess, der alle sicherheitsrelevanten Aspekte der
Gebrauchstauglichkeit eines Medizinproduktes behandelt. Der Fokus beschränkt sich dabei allein
auf die sicherheitskritischen Aspekte der Benutzbarkeit, das heißt auf alle Gefährdungen, die aus
dem normalen Gebrauch eines Medizinproduktes entstehen können. Der normale Gebrauch setzt
sich aus dem bestimmungsgemäßen Gebrauch sowie den Nutzungsfehlern zusammen.
Absichtlichen Missbrauch schließt die Norm explizit aus dem Geltungsbereich aus.
1.3.4.5. Ablösung der EN ISO 60601-1-6 durch die EN 62366
Lehrziele
M1-LE3.4-2-1 Wissen, dass die EN ISO 60601-1-6 von der EN 62366 K1 W
abgelöst worden ist und dass die Normen inhaltlich
nur wenige Unterschiede aufweisen.
Die EN 62366 ist die Nachfolgenorm der EN ISO 60601-1-6 und hat diese inhaltlich abgelöst. Die
dritte Auflage der EN ISO 60601-1-6 enthält nur noch einen Verweis auf die EN 62366 und eine
Klärung der leicht unterschiedlichen Begrifflichkeiten in beiden Normen. Die EN ISO 60601-1-6 ist
nach wie vor unter der MDD harmonisiert und verbindlich für medizinische elektrische Geräte.
Die EN ISO 60601-1 referenziert beim Thema Gebrauchstauglichkeit auf die EN ISO 60601-1-6, die
ihrerseits auf die EN 62366 referenziert. Auf diese Weise wurde die EN 62366 in den
Geltungsbereich der EN ISO 60601-1 gebracht.
1.3.5. Die Normenfamilie EN ISO 60601-1 über medizinisch elektrische Geräte
Gesamtlehrplan
Die Normenfamilie EN ISO 60601-1 kann zum Nachweis der Erfüllung der grundlegenden
Anforderungen bei medizinisch elektrischen Geräten (nicht für Stand-alone Software)
herangezogen werden.
 Medizinisch elektrische Geräte
 Validierung Gesamtsystem
 Medizinisch elektrische Geräte
 Validierung Gesamtsystem
1.3.5.4. Anwendungsbereich der Normenfamilie
Lehrziele
M1-LE3.5-1-1 Den Anwendungsbereich der EN ISO 60601-1 K1 W
Normenfamilie kennen
Die Normenfamilie gilt für medizinische elektrische Geräte und Systeme. Also Medizingeräte, die
einen elektrischen Anschluss an ein Versorgungsnetz haben und zwangsläufig in den Kontakt mit
den Patienten kommen müssen, um den medizinischen Zweck zu erfüllen. Die EN ISO 60601-1 gilt
somit auch für Geräte, die elektrisch betrieben werden, aber keine Software beinhalten. ME-
Geräte, die Software beinhalten nennt die Norm programmierbare elektrische medizinische
Systeme. Die EN ISO 60601-1 beschreibt im Abschnitt 14 die Grundsätze eines Entwicklungs-
Lebenszyklus und referenziert an verschiedenen Stellen auf die EN 62304. In Ergänzung zur EN
62304 behandelt die EN ISO 60601-1 auch das Thema Validierung.
1.3.5.5. Aufbau der Normenfamilie
Lehrziele
M1-LE3.5-2-1 Den Aufbau der Normenfamilie kennen. K1 W
Die Normenfamilie besteht aus der Basisnorm 60601-1, Allgemeine Festlegung für die Sicherheit
einschließlich der wesentlichen Leistungsmerkmale. Aufbauend auf der Basisnorm enthält die
Normenfamilie Ergänzungsnormen der Reihe 60601-1-x, die ergänzende
Sicherheitsanforderungen und Leistungsmerkmale enthalten, wie Elektromagnetische
Verträglichkeit, Gebrauchstauglichkeit oder Alarmsysteme. Weiterhin enthält die Normenfamilie
produktspezifisch besondere Festlegungen an die Basissicherheit und wesentlichen
Leistungsmerkmale in der Reihe 60601-2-x.
Die spezifischen Ergänzungsnormen sind dabei so angelegt, dass die Anforderungen der
Basisnorm überschrieben, ergänzt oder ersetzt werden können. Die Basisnorm und die
Ergänzungen der Reihe 60601-1-x beinhalten keine produktspezifischen Anforderungen und sind
somit auf alle Medizinprodukte anwendbar, die unter die Definition eines medizinisch
elektrischen Geräts fallen.
Mit der dritten Ausgabe der Basisnorm aus dem Jahr 2005 wurde die Struktur der Norm
verändert und einige Ergänzungsnormen in die Basisnorm übernommen, beispielsweise wurde
die Ergänzungsnorm 60601-1-4 in das Kapitel 14 der Basisnorm übernommen. Die Basisnorm
übernimmt in der dritten Ausgabe die Grundgedanken des Risikomanagements nach EN ISO
14971.
1.3.5.6. Bedeutung der Normenfamilie für medizinische Software

Gesamtlehrplan
Lehrziele
M1-LE3.5-3-1 Verstehen welche Teile der Normenfamilie auf die K2 W
Softwareentwicklung angewendet werden müssen
und welche Bedeutung diese Teile für medizinische
Software haben.
Für die Entwicklung von Software sind vor allem der Abschnitt 14 (PEMS Entwicklungs-
Lebenszyklus) der EN ISO 60601-1 und die Ergänzungsnorm EN ISO 60601-1-6 über
Gebrauchstauglichkeit von Bedeutung. Im Amendment 1 zur 3. Edition der EN ISO 60601-1
werden in Bezug auf Usability weitere Begriffe und Aktivitäten festgelegt, für die die Norm auch
auf die EN 62366 referenziert.
Der Abschnitt 14 der dritten Ausgabe der EN ISO 60601-1 enthält Anforderungen an die
Validierung des Gesamtsystems und ergänzt somit bei reiner Softwareentwicklung die EN 62304
um eben diesen Aspekt.
1.4. Lebenszyklus eines Medizinproduktes

1.4.1. Der Produktlebenszyklus aus regulatorischer Sicht
Die Kenntnis der einzelnen regulatorischen Aspekte ist für die Entwicklung eines
Medizinproduktes essentiell. Der zeitliche Ablauf dieser einzelnen regulatorischen Aspekte
beschreibt den Lebenszyklus eines jeden Medizinprodukts. Dabei zeigt sich, dass vor, während
und nach der eigentlichen Entwicklung eines Medizinproduktes weitere Tätigkeiten auszuführen
sind.
 Lebenszyklus
 regulatorischer Ablauf
 Zweckbestimmung
 bestimmungsgemäßer Gebrauch
 CE-Kennzeichnung
 Inverkehrbringen
 Lebenszyklus
 regulatorischer Ablauf
 Zweckbestimmung
 CE-Kennzeichnung
 Inverkehrbringen
1.4.1.4. Lebenszyklus eines Medizinproduktes
Lehrziele
M1-LE4.1-1-1 Den Ablauf des regulatorischen Lebenszyklus eines K2 W
Medizinproduktes kennen und verstehen.

Gesamtlehrplan
Überblick über den Lebenszyklus eines Medizinproduktes aus regulatorischer Sicht: (Bild 2-9 aus
dem Buch)
1.4.1.5. Medizinische Zweckbestimmung und bestimmungsgemäßer Gebrauch
Lehrziele
M1-LE4.1-2-1 Die Begriffe der medizinischen Zweckbestimmung und K2 W
des bestimmungsgemäßen Gebrauchs kennen und die
Bedeutung der beiden Begriffe verstehen.
Der erste Schritt im Lebenszyklus eines Medizinproduktes besteht in der Definition der
Zweckbestimmung dieses Produktes. Die Zweckbestimmung umfasst nach IEC 62366, 5.1, im
Wesentlichen die Punkte:
 medizinische Indikation
 vorgesehene Patientengruppe (inklusive Alter, Gesundheitszustand, Gewicht usw.)
 Körperregion bzw. Gewebe das untersucht (diagnostiziert, therapiert, überwacht) werden soll
 Benutzergruppe (inklusive Alter, Beruf, Ausbildung, Geschlecht, Sprachkenntnisse und
sonstige relevanten Kenntnisse)
 Benutzungskontext (Kernaufgaben, Häufigkeit der Anwendung, Arbeitsbelastung, zu
erzielende Ergebnisse)
 Umgebungsbedingungen (Temperatur, Helligkeit, Luftfeuchtigkeit usw.)
Die Beschreibung des bestimmungsgemäßen Gebrauchs umfasst die Informationen der
Zweckbestimmung und zusätzliche Informationen von der Installation über Betrieb und Wartung
bis zur Entsorgung.
 Umweltbedingungen für Lagerung und Transport (Luftfeuchtigkeit, Temperatur, Druck usw.)
 Installationsbedingungen (benötigtes Fachpersonal usw.)
 Wartungsbedingungen (Intervalle etc.)
 Reinigung
Die genaue Definition der Zweckbestimmung und des bestimmungsgemäßen Gebrauchs bilden
die Grundlage für die Beurteilung des Produktes im Sinne der Definition eines Medizinproduktes
und der Bestimmung, welche Richtlinie auf das Medizinprodukt anzuwenden ist.
1.4.1.6. Bestimmung der anzuwendenden Richtlinien
Lehrziele
M1-LE4.1-3-1 Die relevante Richtlinie und mögliche ergänzende K2 W
nationale Verordnungen kennen und bestimmen
können.
Aufgrund der beschriebenen Zweckbestimmung muss jedes Medizinprodukt einer der drei
Richtlinien entsprechend der Definitionen für Medizingeräte, aktive implementierbare Geräte
und In-vitro Diagnostika zugeordnet werden. Zusätzlich muss geprüft werden, inwieweit
weiterführende Richtlinien, wie beispielsweise die Maschinenrichtlinie oder die Richtlinie für
persönliche Schutzausrüstung beachtet werden müssen.
1.4.1.7. Klassifizierung eines Medizinproduktes
Lehrziele
M1-LE4.1-4-1 Die Lernenden kennen die Unterschiede bei der K1 W
Klassifizierung von In-Vitro-Diagnostika und
Medizinprodukten.
Gesamtlehrplan

Die Klassifizierung eines Medizinproduktes erfolgt anhand der Regeln oder Beschreibungen der
geltenden Richtlinie. Die Medizinprodukterichtlinie enthält die Regeln zur Klassifizierung in
Anhang IX, die Richtlinie über In-Vitro Diagnostika teilt Medizinprodukte anhand von Listen in
Anhang II in drei Gruppen ein und die Richtlinie über aktive medizinische Geräte nutzt nur eine
Klasse.
1.4.1.8. Bestimmung des Konformitätsbewertungsverfahrens
Lehrziele
M1-LE4.1-5-1 Die Bedingungen für die Auswahl eines K1 W
Konformitätsbewertungsverfahrens kennen und
verstehen.
Jede Richtlinie bietet mehrere Konformitätsbewertungsverfahren für Medizinprodukte an. Diese
sind teilweise abhängig von der Klassifizierung des jeweiligen Medizinproduktes. Gibt es für ein
Medizinprodukt mehrere Optionen, steht einem Hersteller die Auswahl eines der Verfahren frei.
Abhängig vom Bewertungsverfahren müssen spezifische Dokumente zum Nachweis erstellt
werden. Eine frühzeitige Festlegung auf ein Konformitätsbewertungsverfahren ermöglicht die
Berücksichtigung der zu erstellenden Dokumente im Entwicklungsprozess. Erfordert das
ausgewählte Bewertungsverfahren zudem den Kontakt mit einer Benannten Stelle, sollte diese zu
einem möglichst frühen Zeitpunkt hinzugezogen werden.
Für Softwareprodukte, die nicht der Klasse I zuzuordnen sind, ist der Nachweis eines
vollständigen Qualitätssicherungssystems nach Anhang II der Medizinprodukterichtlinie der
geeignete Weg.
Parallel zur Auswahl des Konformitätsbewertungsverfahren bietet es sich an, die zu erfüllenden
grundlegenden Anforderungen zu ermitteln und für nicht zutreffende grundlegende
Anforderungen eine Begründung festzuhalten, warum diese nicht zutreffen. Als Beispiel dienen
Anforderungen an die Sterilität von Medizinprodukten, die für reine Softwareprodukte keine
Bedeutung haben. Für den Nachweis über die Erfüllung der grundlegenden Anforderungen ist
seitens des Herstellers eine Strategie notwendig, wie dieser Nachweis erbracht werden kann.
Übliche Vorgehensweise ist die Nutzung der harmonisierten Normen als Nachweis über die
Einhaltung der grundlegenden Anforderungen.
1.4.1.9. Durchführung des Konformitätsbewertungsverfahrens
Lehrziele
M1-LE4.1-6-1 Durchführung des Konformitätsbewertungsverfahrens K2 W
Ein Konformitätsbewertungsverfahren ist zwar zeitlich der Entwicklung eines Medizinproduktes
nachgelagert, jedoch ist es nicht zweckmäßig, alle für ein Konformitätsbewertungsverfahren
notwendigen Tätigkeiten erst mit Abschluss der Produktentwicklung zu beginnen. Beispielsweise
sollte die technische Dokumentation parallel zur Entwicklung erstellt und gepflegt werden. Auch
andere Dokumente werden sinnvollerweise während der Entwicklung erstellt. Welche
Dokumente erstellt werden müssen und welche Anforderungen an diese Dokumente gestellt
werden, ist abhängig vom anzuwendenden Konformitätsbewertungsverfahren und den
einzuhaltenden Normen.
1.4.1.10. Klinische Bewertung
Lehrziele
M1-LE4.1-7-1 Den Zweck einer klinischen Bewertung kennen. K2 W
Gesamtlehrplan

Die klinische Bewertung eines Produktes ist ein erforderlicher Teil des
Konformitätsbewertungsverfahrens für ein Medizinprodukt.
Der Umfang der klinischen Bewertung kann aus einer reinen Literaturrecherche bis hin zur
klinischen Prüfung bestehen. Die klinische Bewertung ist mittels vorhandener Literatur möglich,
wenn belegt werden kann, dass die zugrundeliegenden Daten für ein sowohl technologisch als
auch bezüglich der Zweckbestimmung vergleichbares Produkt erhoben wurden. Ist dies nicht
möglich, muss eine klinische Prüfung zur Erhebung dieser Daten durchgeführt werden. Diese
muss beim DIMDI beantragt und von einer Ethik-Kommission genehmigt werden.
1.4.1.11. Konformitätserklärung und CE-Kennzeichnung
Lehrziele
M1-LE4.1-8-1 Inhalt einer Konformitätserklärung kennen und die K2 W
Bedeutung der Anbringung des CE-Kennzeichens
verstehen.
Nachdem ein Medizinprodukt fertig entwickelt wurde, muss der Hersteller eine
Konformitätserklärung erstellen und das CE-Kennzeichen anbringen, damit das Medizinprodukt in
Verkehr gebracht werden kann. Mit der Konformitätserklärung versichert ein Hersteller, alle
geltenden Vorgaben der entsprechenden Richtlinien erfüllt zu haben. Diese Versicherung wird
durch die Anbringung der CE-Kennzeichnung kenntlich gemacht.
Der Inhalt der Konformitätserklärung ist abhängig von dem gewählten Bewertungsverfahren,
umfasst aber immer mindestens folgende Angaben:
 Name und Anschrift des Herstellers (oder eines Bevollmächtigten)
 Angaben zum Produkt wie Name, Bauart oder Modellnummer sowie Los- Chargen- oder
Seriennummer und die produzierten Stückzahlen
 Alle berücksichtigten einschlägigen Bestimmungen
 Präzise, vollständige und eindeutige Angabe der Referenznormen oder anderer normativer
Dokumente: nationale technische Normen und Spezifikationen
 Name, Anschrift und Kennnummer der Benannten Stelle (wenn beteiligt)
 Datum der Ausstellung der Konformitätserklärung
 Unterschrift und Funktion oder eine gleichwertige Kennzeichnung des Bevollmächtigten
 Eine Erklärung, dass der Hersteller und gegebenenfalls sein Bevollmächtigter die alleinige
Verantwortung für die Ausstellung der Konformitätserklärung trägt
1.4.1.12. Registrierung eines Medizinproduktes
Lehrziele
M1-LE4.1-9-1 Wissen wie und wo ein Medizinprodukt registriert K1 W
werden muss.
Jeder Hersteller muss ein Medizinprodukt vor dem Inverkehrbringen bei einer nationalen
Behörde registrieren. In Deutschland wird diese Funktion vom DIMDI bereitgestellt. Die
Registrierung umfasst die Angabe der Adressdaten des Herstellers und die Bezeichnung des
Sicherheitsbeauftragten.
1.4.1.13. Inverkehrbringen von Medizinprodukten
Lehrziele
M1-LE4.1-10-1 Definition und Bedeutung des Inverkehrbringens K2 W
Gesamtlehrplan

Mit der Anbringung des CE-Kennzeichens und nach der Registrierung beim DIMDI kann ein
Medizinprodukt ohne Einschränkung auf dem europäischen Binnenmarkt gehandelt werden.
Da in der Medizinprodukterichtlinie auch die unentgeltliche Überlassung eines Medizinproduktes
als Inverkehrbringen gewertet wird, ist vom Hersteller darauf zu achten, dass es im Rahmen der
Produktvalidierung nicht zu einem unrechtmäßigen Inverkehrbringen kommt, da einem Hersteller
für das unrechtmäßige Inverkehrbringen von Medizinprodukten Strafen drohen.
1.4.1.14. Marktbeobachtung und Meldung von Zwischenfällen
Lehrziele
M1-LE4.1-11-1 Aufgaben eines Herstellers nach dem K2 W
Inverkehrbringen eines Produktes kennen und
verstehen.
Die Marktbeobachtung ist eine regulatorische Vorgabe an einen Hersteller nach dem
Inverkehrbringen eines Medizinproduktes. Hierzu muss ein Hersteller ein System für die
Sammlung und Auswertung von Kundenfeedback erstellen sowie ähnliche auf dem Markt
befindliche Produkte auf aufgetretene Probleme überwachen. Diese Pflicht erlischt erst mit
Ablauf der vorgesehenen Lebensdauer des letzten ausgelieferten Produktes oder
Außerbetriebnahme des letzten auf dem Markt befindlichen Produktes.
Erhält ein Hersteller aufgrund der Marktbeobachtung oder des Kundenfeedbacks Kenntnis über
Probleme oder Risiken, die sein Produkt betreffen, so muss er diese bewerten und eventuell eine
Meldung an die Aufsichtsbehörden machen. In Deutschland müssen schwerwiegende Probleme
mit Medizinprodukten an das Bundesinstitut für Arzneimittel und Medizinprodukte (BfArM)
gemeldet werden, das hierfür Formulare auf der Webseite bereithält. Eine vergleichbare
Institution muss in jedem europäischen Mitgliedsstaat vorhanden sein.
Die an das BfArM gemeldeten Maßnahmen sind öffentlich zugänglich und müssen somit von allen
Herstellern in regelmäßigen Abständen ausgewertet werden, um sicherzustellen, dass die dort
gemeldeten Vorfälle keine Auswirkungen auf deren Medizinprodukte haben.
Erlangt ein Hersteller aufgrund der Auswertung des Kundenfeedbacks, der Marktbeobachtung
oder einer Mitteilung des BfArMs Kenntnis über ein Problem bei seinem Produkt, müssen
herstellerseitig Maßnahmen ergriffen werden um Schaden von Patienten, Benutzern oder Dritten
abzuwenden. Die Maßnahmen können aus der Information von Kunden und des BfArM bestehen
und sich bis zum Rückruf aller betroffenen Medizinprodukte ausweiten.
1.4.2. Überwachung durch Behörden und Benannte Stellen
Zur Sicherstellung der Einhaltung aller regulatorischer Vorgaben werden Hersteller von
Medizinprodukten von sogenannten Benannten Stellen überwacht. Diese Benannten Stellen sind
privatwirtschaftliche Unternehmen und müssen daher von staatlicher Seite akkreditiert und
kontrolliert werden.
 Anzeigepflicht
 Benannte Stelle
 Zertifizierungsaudit
 Anzeigepflicht

Gesamtlehrplan
 Benannte Stelle
 Zertifizierungsaudit
1.4.2.4. Anzeigepflicht vor Aufnahme der Tätigkeit als Hersteller
Lehrziele
M1-LE4.2-1-1 Wissen, wann und wo sich der Hersteller eines K1 W
Medizinproduktes registriert.
Alle Hersteller von Medizinprodukten in Deutschland haben nach § 5 Medizinproduktegesetz die
Pflicht, die Aufnahme der Tätigkeit vor dem erstmaligen Inverkehrbringen eines
Medizinproduktes anzuzeigen. Diese Anzeige erfolgt unter Angabe der Anschrift bei der
zuständigen Behörde. Da die Bundesländer die Zuständigkeit eigenständig regeln können, hält das
DIMDI eine vollständige Liste aller verantwortlichen Behörden bereit und stellen zudem ein
Formular zu Anzeige der Tätigkeit (unter Angabe der Behörde) zur Verfügung.
Diese Registrierung ist ausreichend, solange es sich um ein Medizinprodukt der Klasse I handelt,
das weder steril ist und auch keine Messfunktion beinhaltet. Für alle anderen Produkte ist der
Kontakt zu einer Benannten Stelle notwendig.
1.4.2.5. Konformitätsbewertungsverfahren
Lehrziele
M1-LE4.2-2-1 Die Überwachungsmaßnahmen während eines K1 W
Konformitätsbewertungsverfahrens kennen.
Ein Konformitätsbewertungsverfahren wird, abhängig vom Weg der Konformitätserklärung, von
einer Benannten Stelle begleitet und überwacht. Diese Überwachung kann in Form von
Produktprüfungen, Dokumentenprüfungen oder Prozessprüfungen erfolgen.
1.4.2.6. Zertifiziertes Qualitätsmanagementsystem
Lehrziele
M1-LE4.2-3-1 Die Prüfungs- und Überwachungsmaßnahmen bei K1 W
Unterhaltung eines zertifizierten
Qualitätsmanagementsystems kennen.
Wird als Konformitätsbewertungsverfahren der Nachweise eines zertifiziertes
Qualitätsmanagementsystem gewählt, so muss das vom Hersteller erstellte QM-System von einer
Benannten Stelle zertifiziert sein. Die Zertifizierung erfolgt in der Regel nach EN ISO 13485.
Die Zertifizierung umfasst ein Vor-Audit, die Prüfung der QM-Unterlagen und dem
Zertifizierungsaudit beim Hersteller. Als Ergebnis erhält der Hersteller einen Auditbericht mit
Anmerkungen, Nebenabweichungen und Hauptabweichungen und das Zertifikat.
Enthält ein Auditbericht Hauptabweichungen, so müssen diese kurzfristig behoben werden, um
das Zertifikat zu erhalten. Geschieht dies nicht, können auch bereits bestehende Zertifikate
wieder eingezogen werden. Nebenabweichungen müssen dagegen in der Regel erst bis zum
nächsten Audit behoben werden, während Anmerkungen keinen Einfluss auf die Vergabe haben.
Ein solches Zertifikat muss alle drei Jahre erneuert werden, zudem erfolgen jährliche
Überwachungsaudits.
1.4.2.7. Überwachung der Benannten Stellen
Lehrziele

Gesamtlehrplan
M1-LE4.2-4-1 Die Überwachungsmaßnahmen kennen, denen eine K1 W
Benannte Stelle unterliegt.
Die Benannten Stellen sind ein wichtiges Element bei der Überwachung der Einhaltung aller
regulatorischen Vorgaben. Jedoch sind die Benannten Stellen privatwirtschaftlich geführte
Unternehmen, die somit gegenüber den Herstellern keine rechtliche Befugnis besitzen und der
Kontrolle und Überwachung durch die Bundesländer unterliegen.
Die Zulassung und Kontrolle einer Benannten Stelle liegt im Aufgabenbereich der nationalen
Behörden, lediglich die Vergabe der Kennnummern wird durch die europäische Kommission
geregelt. Die Zulassung einer Benannten Stelle erfolgt durch eine nationale Akkreditierungsstelle.
In Deutschland ist das die Aufgabe der Deutschen Akkreditierungsstelle (DAkkS).
1.4.2.8. Weiterführende Gremien und Verbände
Lehrziele
M1-LE4.2-5-1 Die Gremien und Verbände als Lieferanten von K1 W
hilfreichen Dokumenten kennen.
Der EK-Med ist ein Erfahrungsaustauschkreis, der nach dem Medizinproduktegesetz Benannten
Stellen auf nationaler Ebene. Die Gruppierung setzt sich aus den Vertretern der Benannten
Stellen, des Bundesministeriums für Gesundheit und anderer wichtiger Institute sowie Vertretern
der Akkreditierungsstelle zusammen. Die EK-Med tagt zweimal pro Jahr und die Ergebnisse der
Diskussionen werden in den EK-Med-Dokumenten veröffentlicht.
Auf europäischer Ebene gibt es das Team NB, die European Association of Notified Bodies for
Medical Devices. Die Gruppierung besteht aus Mitgliedern der europäischen Benannten Stellen
und ist vertreten in dem Zusammenschluss NB-MED, dem neben den Vertretern der Benannten
Stellen auch Vertreter der europäischen Kommission, der Industrie, der Mitgliedsstaaten und
unabhängige Experten angehören. Die Gruppierung veröffentlicht Empfehlungen in sogenannten
NB-MED-Dokumenten.
GHTF: Global Harmonization Task Force. Zusammenschluss von Vertretern der Industrie und der
Regulierungsbehörden der Länder USA, Kanada, Japan und der europäischen Union mit dem Ziel,
die nationalen regulatorischen Anforderungen in einem weltweiten Standard anzugleichen. Die
GHTF veröffentlicht Guidance Dokumente mit dem Ziel die Sicherheit der Patienten zu erhöhen
und den Zugriff zu medizinischen Technologien zu verbessern. Die GHTF wurde 2013 von der
Nachfolgeorganisation International Medical Devices Regulator Forum (IMDRF) abgelöst.
1.5. Regulatorische Grundlagen für den US-Markt

1.5.1. Rechtliche Grundlagen in den USA
Medizinproduktehersteller, die Ihre Produkte auf dem amerikanischen Markt vertreiben wollen,
fallen unter die Gesetzgebung der Vereinigten Staaten von Amerika. Die regulatorischen
Vorgaben des amerikanischen Gesetzgebers unterscheiden sich dabei von den Vorgaben der
europäischen Gesetzgebung. Eine genaue Kenntnis der rechtlichen Situation in den USA ist somit
notwendig, um den Verkauf von Medizinprodukten in den USA zu ermöglichen.
 Verfassung
 Gesetzesrecht

Gesamtlehrplan
 Verwaltungsrecht
 Food, Drug, and Cosmetic Act
 Code of Federal Regulations
 Food and Drug Administration
 Verfassung
 Gesetzesrecht
 Verwaltungsrecht
 Food, Drug, and Cosmetic Act
 Code of Federal Regulations
 Food and Drug Administration
1.5.1.4. Aufbau der amerikanischen Gesetzgebung
Lehrziele
M1-LE5.1-1-1 Den Aufbau der amerikanischen Gesetzgebung kennen K1 W
um ein Verständnis für die regulatorischen Vorgaben
auf dem amerikanischen Markt zu bekommen.
Die amerikanische Gesetzgebung besteht aus drei hierarchisch gegliederten Ebenen, die sich im
Detailgrad unterscheiden.
Die oberste Ebene bildet die Verfassung, die durch vom Kongress verabschiedete Zusätze ergänzt
werden kann. Unterhalb der Verfassung findet sich die Gesetzgebung der Regierung, das
sogenannte Gesetzesrecht. Die dritte Ebene bildet das Verwaltungsrecht, welches von einer der
Regierung unterstellten Behörde verfasst und durchgesetzt wird. Unterhalb dieser Ebene
existieren sogenannte Guidance Dokumente, die zwar keine rechtsverbindlichen Charakter
haben, aber eine hohe Praxisbedeutung besitzen. Auf gleicher Ebene und mit gleichem nicht
rechtsverbindlichem Charakter rangieren die "Recognized Consensus Standards", die den
harmonisierten Normen ähneln. Die Standards IEC 62304 und ISO 14971 sind beispielsweise laut
Webseite der FDA (Stand August 2012) vollständig anerkannt, wobei im Falle von IEC 62304
zusätzlich die einschlägigen Guidance-Dokumente zu beachten sind.
1.5.1.5. Federal Food, Drug, and Cosmetic Act
Lehrziele
M1-LE5.1-2-1 Wissen welche Teile des Federal Food, Drug, and K1 W
Cosmetic Act für Medizinproduktehersteller von
Bedeutung sind.
Der Federal Food, Drug, and Cosmetic Act bildet auf Ebene des Gesetzesrechts die rechtliche
Grundlage für die Hersteller von Medizinprodukten, ebenso wie für Nahrungsmittel, Arzneimittel
und Kosmetika.
Das Gesetz besteht aus 9 Kapiteln, von denen sich das fünfte auf Arzneimittel und
Medizinprodukte bezieht und die Rahmenbedingungen für die Zulassung von Medizinprodukten
in Amerika regelt. Abschnitt 510 des fünften Kapitels beschriebt unter dem Punkt k das
Meldeverfahren auf dem amerikanischen Markt. Die Bezeichnung 510(k) für das Meldeverfahren
leitet sich von der Nummerierung im Gesetz ab.
Weitere relevante Anforderungen finden sich in den Abschnitten mit den Nummern 505-1 für
Risikoanalyse und Minderung, 513 für die Klassifizierung von Medizinprodukten, 515 für die
erweiterte Prüfung von Medizinprodukten (Premarket Approval) sowie 522 für die
Marktüberwachung.
Gesamtlehrplan
1.5.1.6. Code of Federal Regulations Title 21

Lehrziele
M1-LE5.1-3-1 Die für Medizinproduktehersteller relevanten Teile K1 W
des CFR Titel 21 kennen.
Der Code of Federal Regulations Title 21 bildet auf der Ebene des Verwaltungsrechts die
gesetzliche Basis für die Hersteller. Das Unterkapitel H des ersten von drei Kapiteln des Gesetzes
enthält die Vorgaben für Medizingeräte, Unterkapitel A enthält allgemeine Anforderungen.
Den zentralen Teil des Gesetzes bildet der Teil 820 H mit den Anforderungen an
Qualitätsmanagementsysteme. Diese Anforderungen sind inhaltlich vergleichbar mit den
Anforderungen an ein Qualitätsmanagementsystem nach ISO 13485. Ein weiterer Punkt sind die
Anforderungen aus dem Teil 11 A mit den Anforderungen an elektronische Aufzeichnungen und
elektronische Unterschriften.
Die Umsetzung des Code of Federal Regulations obliegt der Food and Drug Administration.
1.5.1.7. Die Food and Drug Administration
Lehrziele
M1-LE5.1-4-1 Die Aufgabe und Bedeutung der FDA kennen. K1 W
Die Food and Drug Administration, kurz FDA ist die Regulierungsbehörde für Medizinprodukte in
den USA. Die Aufgabe der Behörde ist der Schutz der öffentlichen Gesundheit und die
Verbesserung der öffentlichen Gesundheit.
Die FDA kontrolliert und überprüft die Einhaltung aller Anforderungen durch Hersteller und
Produkte und ist für die Zulassung von Medizinprodukten zuständig. Außerhalb der Vereinigten
Staaten wird die FDA von akkreditierten Partnern repräsentiert, die die Hersteller nach den
Vorgaben der FDA auditieren.
1.5.2. Klassifizierung von Medizinprodukten nach amerikanischem Recht
Die amerikanische Gesetzgebung fordert ebenso wie die europäischen Vorgaben die
Klassifizierung eines Medizingerätes, von der das jeweilige Zulassungsverfahren abhängt.
1.5.2.2. Rechtliche Grundlage der Klassifizierung
Lehrziele
M1-LE5.2-1-1 Die rechtliche Grundlage für die Klassifizierung von K1 W
Medizinprodukten auf dem amerikanischen Markt
kennen.
Die Anforderung, Medizingeräte nach dem Risiko für Patienten und Anwender zu klassifizieren,
findet sich in Abschnitt 513 des Federal Food, Drug, and Cosmetic Act. Dieser Abschnitt
beschreibt drei Klassen, die Medizinprodukte nach dem Risiko der Schädigung von Menschen
einordnen. Klasse I enthält die Produkte mit dem geringsten Risiko und Klasse III die Produkte mit
dem höchsten Risiko.
1.5.2.3. Klassifizierung
Lehrziele

Gesamtlehrplan
M1-LE5.2-2-1 Die Vorgehensweise für die Klassifizierung eines K1 W

Medizinproduktes kennen.
Der Abschnitt 513 enthält kein Regelwerk zur Einordnung eines Medizinproduktes. Die
Regelungen finden sich auf Verwaltungsrechtsebene (21 CFR) unter den Teilen 862 – 892. Diese
Teile enthalten eine Beschreibung generischer Medizingeräte und deren Klassifizierung, unter der
ein Hersteller sein Medizinprodukt einzuordnen hat.
Die Identifizierung des Produkttyps erfolgt anhand einer siebenstelligen Nummer, die sich der
Teilnummer des Gesetzes und einer vierstelligen Kennnummer ergibt.
1.5.3. Inverkehrbringen auf dem amerikanischen Markt
Für die Zulassung von Medizinprodukten auf dem amerikanischen Markt existieren abhängig von
der Produktklassifizierung unterschiedliche Möglichkeiten. Gemeinsam ist allen
Zulassungsverfahren die Sicherstellung der Einhaltung der „General Controls“. Aufbauend auf
diese Prüfung muss je nach Neuartigkeit des Produktes das Premarket Notification (510(k)) oder
das Premarket Approval (PMA) Verfahren herangezogen werden.
 General Controls
 Premarket Notification (510(k))
 Premarket Approval (PMA)
 General Controls
 Premarket Notification (510(k))
 Premarket Approval (PMA)
1.5.3.4. General Controls and Premarket Notification 510 (k)
Lehrziele
M1-LE5.3-1-1 Die notwendigen Unterlagen und Tätigkeiten für die -- K2
Zulassung von Klasse I und II Medizinprodukten
kennen.
Die Einhaltung der General Controls und ein Premarket Notification Verfahren bilden die
Grundlage für die Zulassung von Medizinprodukten der Klasse I und II.
Die General Controls sind Anforderungen an Medizinprodukte, die in etwa den grundlegenden
Anforderungen in Europa ähneln. Die Anforderungen umfassen die Registrierung des Herstellers
und aller Produkte bei der FDA, die korrekte Kennzeichnung der Produkte nach 21 CRF Part 809
und die Einhaltung der Current good manufacturing practice (cGMP), auf die in 21 CFR Part 820
verwiesen wird.
Neben den General Controls müssen Hersteller ein weiteres, Premarket Notification (510(k))
genanntes Zulassungsverfahren beachten. Allerdings sind die meisten Klasse I und einige Klasse II
Produkte von diesem Verfahren befreit. Welche Produkte von einem 510 (k) befreit sind, wird in
der Klassifizierung nach 21 CFR Teile 862 – 892 ersichtlich.
Ziel eines 510 (k) ist es nachzuweisen, dass ein neues Medizinprodukt einem vergleichbaren
bereits auf dem Markt befindlichen Medizinprodukt in Zweckbestimmung und eingesetzter
Technologie ähnelt. Der 510 (k) muss mindestens 90 Tage vor dem geplanten Inverkehrbringen
bei der FDA eingereicht werden und nach 21 CFR 807, Subpart E folgende Dokumente enthalten:
1. Medical Device User Fee Cover Sheet (Form FDA 3601)
Gesamtlehrplan
2. CDRH Premarket Review Submission Cover Sheet

3. 510(k) Cover Letter
4. Indications for Use Statement
5. 510(k) Summary or 510(k) Statement
6. Truthful and Accuracy Statement
7. Class III Summary and Certification
8. Financial Certification or Disclosure Statement
9. Declarations of Conformity and Summary Reports
10. Executive Summary
11. Device Description
12. Substantial Equivalence Discussion
13. Proposed Labeling
14. Sterilization and Shelf Life
15. Biocompatibility
16. Software
17. Electromagnetic Compatibility and Electrical Safety
18. Performance Testing – Bench
19. Performance Testing – Animal
20. Performance Testing – Clinical
21. Other
Inhalt und der Ablauf des 510 (k) Verfahrens wird in einem eigenem Guidance Dokument "Format
for Traditional and Abbreviated 510(k)s" beschrieben und erläutert.
1.5.3.5. Premarket Approval
Lehrziele
M1-LE5.3-2-1 Die Tätigkeiten und den Umfang der Zulassung eines -- K2
Klasse III Medizinproduktes kennen.
Ist für ein Medizinprodukt der Klasse I und II der Nachweis der Ähnlichkeit zu einem bestehenden
Produkt mittels eines 510 (k) nicht möglich, muss vom Hersteller eine Premarket Approval (PMA)
eingeholt werden. Dies gilt ebenso für alle Produkte der Klasse III.
Für die Freigabe durch die FDA mittels eines Premarket Approval muss ein Hersteller den
Nachweis erbringen, dass sein Produkt im Rahmen seiner Zweckbestimmung sicher ist. Hierzu
muss ein Hersteller klinische Studien durchführen und Daten für den Nachweis erheben. Ebenso
muss eine detaillierte Beschreibung des Gerätes und seiner Komponenten bei der FDA
eingereicht werden. Der Antrag für ein PMA muss mindestens 180 Tage vor der geplanten
Inverkehrbringung bei FDA eingereicht werden.
1.5.4. Softwarespezifische Anforderungen
Die spezifischen Anforderungen an medizinische Software sind auf dem amerikanischen Markt
ebenso im Fokus der Regulierungsgremien wie auf dem europäischen Markt. Die spezifischen
Anforderungen werden von verschiedenen Guidance-Dokumenten abgedeckt, ähneln jedoch den
Vorgaben aus Europa.
 Guidance Dokumente
 Sicherheitsklassifizierung
 Level of Concern
 Off-The-Shelf Software

Gesamtlehrplan

 Guidance Dokumente
 Sicherheitsklassifizierung
 Level of Concern
 Off-The-Shelf Software
1.5.4.4. Softwarespezifische Anforderungen durch Guidance Dokumente
Lehrziele
M1-LE5.4-1-1 Wissen, dass softwarespezifische Anforderungen an K1 W
Medizinprodukte im Regulierungsbereich der FDA
nicht durch ein Gesetz, sondern durch Guidance-
Dokumente abgedeckt werden.
Anforderungen an Software in Medizinprodukten finden sich für den amerikanischen Markt
weder auf Gesetzesrechtsebene noch auf Verwaltungsrechtsebene. Die Anforderungen an
Software wurden nachträglich durch Guidance-Dokumente hinzugefügt, die sich mit den Themen
Software-Lebenszyklus, Dokumentation von Software im 510 (k) Verfahren und Nutzung von
Fremdsoftware beschäftigen.
1.5.4.5. Guidance General Principles on Software Validation
Lehrziele
M1-LE5.4-2-1 Anwendungsbereich und Bedeutung des Guidance- K1 W
Dokuments kennen.
Das Guidance Dokument deckt entgegen seines Titels nicht nur die Validierung von Software,
sondern den kompletten Lebenszyklus einer Software ab. Vom Inhalt ähnelt die Guidance der IEC
62304, jedoch umfasst der Anwendungsbereich jede Software, die Einfluss auf die Qualität eines
Produktes hat, also auch Software für die Herstellung und Qualitätssicherung der Produkte.
1.5.4.6. Guidance: Guidance for the Content of Premarket Submissions for Software Contained in
Medical Devices
Lehrziele
M1-LE5.4-3-1 Die Bedeutung des Guidance-Dokuments und der K2 W
Level of Concern kennen und verstehen.
Das Dokument beschreibt die für ein 510 (k) notwendige Dokumentation für Software. Um den
Umfang der Dokumentation auf die Bedeutung einer Software anzupassen, führt diese Guidance
das Konzept des „Level of Concern“ ein. Dieses Konzept klassifiziert eine Software basierend auf
dem Schaden, der durch diese verursacht werden kann, vergleichbar mit der
Sicherheitsklassifizierung der IEC 62304. Ein wichtiger Unterschied besteht jedoch bei der
Einstufung darin, dass das Konzept der Level of Concern den Einfluss von
Risikokontrollmaßnahmen nicht berücksichtigt. Die Einteilung erfolgt in die Klassen
 Major Level of Concern – für Software die zu schweren Verletzungen oder Tod führen kann
 Moderate Level of Concern – für Software die zu leichten Verletzungen führen kann
 Minor Level of Concern – für Software die nicht zu Verletzungen führen kann
Basierend auf dem Level of Concern ermittelt sich der Umfang der Dokumentation. Zu beachten
ist, dass der Level of Concern lediglich den Umfang der einzureichenden Dokumentation
beeinflusst, es müssen jedoch alle Dokumente erstellt werden.
Gesamtlehrplan
1.5.4.7. Guidance: Off-The-Shelf Software Use in Medical Devices

Lehrziele
M1-LE5.4-4-1 Die Besonderheiten beim Umgang mit Fremdsoftware K1 W
Off-The-Self (OTS) Software bezeichnet zugekaufte Software oder Softwarekomponenten, auf
deren Herstellungsprozess ein Hersteller prinzipiell keinen Zugriff und somit auch keine Kontrolle
hat. Das Guidance-Dokument "Off-The-Shelf Software Use in Medical Devices" beschäftigt sich
mit dem Umgang und der Dokumentation einer zugekauften Software, wie beispielsweise einem
Betriebssystem.
Der Umfang der Dokumentation basiert wiederum auf dem Risiko, welches die Nutzung einer OTS
Komponente nach sich zieht. Zur Klassifizierung wird folgendes Schema verwendet:

Gesamtlehrplan
(Aus Guidance for the Content of Premarket Submissions for Software Contained in Medical
Device)
Für die Basisdokumentation muss vom Hersteller folgende Informationen bereitgestellt werden:
 Beschreibung der Komponente
 Hardware- und Softwareanforderungen an die Komponente
 Beschreibung, wie sichergestellt wird, dass der Endnutzer die Komponente nicht negativ
beeinflussen kann
 Beschreibung der Funktionalität der OTS-Komponente und deren Zusammenspiel mit der
restlichen Software
 Beschreibung der Maßnahmen zur Sicherstellung der korrekten Funktionalität
 Beschreibung der Maßnahme zur Kontrolle der OTS-Komponente (Falsche Version,
Beobachtung von Buglisten)
Die besondere Dokumentation umfasst zusätzlich zur Basisdokumentation noch den Nachweis,
dass die OTS-Komponente mit derselben Sorgfalt entwickelt wurde wie die eigene Software.
Hierzu zählen Audits beim Hersteller der OTS-Komponente, Validierungs- und
Verifikationsschritte und die Sicherstellung der langfristigen Wartung der OTS-Komponente, auch
wenn diese vom Hersteller der Komponente aufgegeben wird.

Gesamtlehrplan
2. Curriculum Risikomanagement
Dieses Modul gibt einen Einblick in einen Kernprozess der Entwicklung medizinischer Software:
das Risikomanagement.
Hinweis: Es kann für die Durchführung der Schulung sinnvoll sein, die Abschnitte in geänderter
Reihenfolge zu präsentieren bzw. zu kombinieren.
2.1. Einführung in das Risikomanagement

2.1.1. Regulatorische Forderungen
Das Risikomanagement ist eine zentrale Forderung in den Regularien. Die Richtlinien für
Medizinprodukte (MDD, AIMD, IVD) fordern explizit, dass Risiken erkannt, bewertet und in einem
für Patienten, Anwender und Dritte vorteilhaften Verhältnis zum Nutzen stehen. Einige
harmonisierte Normen fordern das Risikomanagement explizit und verweisen dazu normativ auf
die EN ISO 14971.
2.1.1.2. Regulatorischer Rahmen
Lehrziele
M2-LE1.1-1-1 Wissen, dass die Richtlinien für Medizinprodukte und K1 W
die entsprechenden nationalen Gesetze ein
Risikomanagement fordern.
M2-LE1.1-1-1 Die grundlegenden Forderungen der Regularien K1 W
hinsichtlich des Risikomanagements kennen.
M2-LE1.1-1-1 Wissen, dass die EN ISO 14971 die harmonisierte K1 W
Norm ist, die das Risikomanagement bei
Medizinprodukten beschreibt.
M2-LE1.1-1-1 Die Relevanz der EN ISO 14971 für den Auditerfolg K2 W
verstehen.
M2-LE1.1-1-1 Verstehen, wie die Sicherheitsklassifizierung gemäß K2 W
IEC 62304 mit dem Risikomanagement
zusammenspielt.
M2-LE1.1-1-1 Wissen, dass die EN ISO 13485 ein Risikomanagement K1 W
verlangt und dazu die Anwendung der EN ISO 14971
empfiehlt.
M2-LE1.1-1-1 Wissen, dass EN 62304 und EN 62366 ein K1 W
Risikomanagement nach EN ISO 14971 normativ
verlangen.
M2-LE1.1-1-1 Die Abgrenzung von ISO 14971 und IEC 62366 K2 W
hinsichtlich der Risikoursachen verstehen.
M2-LE1.1-1-1 Wissen, dass die EN 60601-1 Normenfamilie für ME- K1 W
Geräte, die Software enthalten, weitere Gefährdungen
nennt und ein Risikomanagement nach EN ISO 14971
fordert.
M2-LE1.1-1-1 Die Aktivitäten, die von der EN 62304 vorgeschrieben -- K2
sind, den Aktivitäten innerhalb des
Risikomanagementprozesses zuordnen können (und
vice versa).

Gesamtlehrplan
M2-LE1.1-1-1 Die Bedeutung des Risikomanagements verstehen und -- K2

dessen Relevanz für die für die CE-Zulassung von
Medizinprodukten kennen.
M2-LE1.1-1-1 Wissen, für welche Arten von Medizinprodukten -- K1
Risikomanagement gefordert wird.
Der Nachweis der Einhaltung der "Grundlegenden Anforderungen" in dem Anhang I der
Richtlinien MDD, AIMD, IVD ist das Prinzip der CE-Kennzeichnung. Einige dieser grundlegenden
Anforderungen verlangen, dass der medizinische Nutzen die Restrisiken überwiegt. Nur wer im
Rahmen des Konformitätsbewertungsverfahren (siehe Modul "Regulatorische Grundlagen“) einen
dokumentierten Nachweis (Risikomanagementakte) für die Erfüllung dieser grundlegenden
Anforderung erbringt, darf sein Medizinprodukt in Europa in Verkehr bringen.
Wenn die harmonisierte Norm EN ISO 14971 (Anwendung des Risikomanagements auf
Medizinprodukte) eingehalten wird, dann gilt nach dem Vermutungsprinzip, dass die
grundlegenden Anforderungen bezüglich des Risikomanagements erfüllt sind.
Zentrale Elemente des Risikomanagements sind die Planung, Gefährdungsanalyse, Risikoanalyse,
Risikobewertung und Risikobeherrschung. Die Aktivitäten und deren Ergebnisse werden in der
Risikomanagementakte dokumentiert.
Wichtige Normen, die das Risikomanagement fordern und auf die ISO 14971 verweisen, sind:
 EN ISO 13485
EN ISO 13485 fordert in Kapitel 7.1, Planung der Produktrealisierung ein Risikomanagement und
empfiehlt die ISO 14971 anzuwenden.
 EN 62304
Im Gegensatz zur EN ISO 13485 fordert die EN 62304 explizit ein Risikomanagement nach EN ISO
14971 (normativer Verweis in Kapitel 2). Weitere Verweise finden sich an verschiedenen Stellen
in Kapitel 4, Kapitel 7 und in den Anhängen. Kernforderung der EN 62304 ist, dass alle Risiken in
jeder Phase der Entwicklung und während des gesamten Produktlebenszyklus (also auch in der
Wartungsphase) analysiert und beherrscht werden.
 EN 62366
Da mangelnde Gebrauchstauglichkeit eine nicht zu unterschätzende Ursache für Gefährdungen
darstellt, fordert auch die EN 62366 ein Risikomanagement nach EN ISO 14971 (normativer
Verweis in Kapitel 2). Weitere Verweise finden sich an verschiedenen Stellen in Kapitel 4, Kapitel
5 und in den Anhängen. EN 62366 konzentriert sich dabei auf Risiken, die durch mangelnde
Gebrauchstauglichkeit verursacht werden. EN ISO 14971 beschreibt, wie mit Risiken - gleich
welcher Ursache - umzugehen ist und fordert auch die Berücksichtigung des vorhersehbaren
Missbrauchs.
Auch die FDA fordert ein Risikomanagement und erkennt EN ISO 14971 an.
 EN 60601-1
Die Norm EN 60601-1 fordert im Abschnitt 4.2 explizit die Anwendung der EN ISO 14971 für den
Entwicklungsprozess von ME-Geräten, auch solchen ohne Software. Speziell im Abschnitt 14 der
Norm, der sich auf Programmierbare Elektrische Medizinische System (PEMS) bezieht, verlangt
die Norm dass Gefährdungen und Risiken, die speziell durch das Zusammenspiel von Software-
und Hardware auftreten, analysiert und beherrscht werden müssen. Dazu gehören auch
Gefährdungen, die durch den Daten- und Netzwerkverbund zwischen anderen Subsystemen, ME-
Geräten und Komponenten Dritter entstehen. Auch andere Ausgaben dieser Normenfamilie, wie
zum Beispiel die über Homecare und EMV, enthalten Anforderungen an das Risikomanagement.

Gesamtlehrplan
Wiederholung der Inhalte aus FL zur Auffrischung.

Außerdem: Wer in Europa ein Medizinprodukt in Verkehr bringt muss nachweisen können, dass
es die grundlegenden Anforderungen erfüllt (z.B. Medizinproduktegesetz (D, AT), Heilmittelgesetz
(CH)). Derjenige, der ein Medizinprodukt mit einer CE-Kennzeichnung versieht und in Verkehr
bringt, das die Grundlegenden Anforderungen nicht erfüllt, begeht nach §40 oder §41 MPG eine
Straftat.
Eine der ersten grundlegenden Anforderungen ist, dass etwaige Risiken gemessen am Nutzen
vertretbar sein müssen. Daher fordern auch alle zuvor genannten harmonisierten Normen die
Anwendung des Risikomanagements und verweisen dafür auf die EN ISO 14971. Damit ist ein
systematisches und präzises Risikomanagement faktisch unumgänglich.
Die Forderung nach einem Risikomanagement betrifft jedes Medizinprodukt das in Verkehr
gebracht wird, auch Medizinprodukte ohne CE Kennzeichnung, z.B. solche, die für eine klinische
Prüfung vorgesehen sind. Eigenständige Software zur Anwendung für therapeutische oder
diagnostische Zwecke ist gemäß MDD ein aktives Medizinprodukt und unterliegt den gleichen
Anforderungen.
2.1.2. Begriffsdefinitionen
Ein klares Verständnis der Begriffe Gefährdung, Gefährdungssituation, Schaden und Risiko und
deren Abgrenzung ist für das Risikomanagement unerlässlich.
 Gefährdung
 Gefährdungssituation
 Schaden
 Risiko
 Grundrisiko
 Restrisiko
 vertretbares Risiko
2.1.2.4. Begriffsdefinitionen
Lehrziele
M2-LE1.2-1-1 Die Begriffe Gefährdung, Gefährdungssituation, K2 W
Schaden, Risiko verstehen und Beispiele dafür geben
können.
M2-LE1.2-1-1 Gefährdung und Gefährdungssituation unterscheiden K3 W
können.
M2-LE1.2-1-1 Den Unterschied zwischen Grundrisiko, Restrisiko und -- K2
vertretbarem Risiko verstehen.
In der EN ISO 14971 werden einige grundlegende Begriffe erläutert:
GEFÄHRDUNG
"Eine Gefährdung ist eine potenzielle Schadensquelle."
Die Gefährdung stellt die eigentliche Ursache für einen potenziellen Schaden dar. Beispielsweise
stellt eine Spannungsquelle eine Gefährdung dar.
Beispiele für Gefährdungen sind:

Gesamtlehrplan
 Elektrische Energie
 Elektromagnetische Strahlung
 Mechanische Energie
 Thermische Energie (Hitze, Kälte)
 Biologische und chemische Materialien
Weitere Beispiele für Gefährdungen befinden sich im Anhang E der ISO 14971. Auch andere
Normen, die auf die ISO 14971 verweisen, nennen Beispiele bezogen auf deren Kontext.
Software selbst stellt nie eine direkte Gefährdung dar, kann aber Teil einer Ursachenkette sein,
die zu einer Gefährdung führt. Die Besonderheiten im Umgang mit Risikomanagement für
medizinische Software beschreibt die IEC 80002.
GEFÄHRDUNGSSITUATION
„Umstände, unter denen Menschen, Güter oder die Umwelt einer oder mehreren Gefahren
ausgesetzt sind.”
Betrachtet man den Zustand, in dem eine Person – Patient, Anwender oder Dritter – einer
Gefährdung ausgesetzt wird, beispielsweise bei der Anwendung eines Medizinprodukts, so wird
von einer Gefährdungssituation gesprochen.
Eine hohe elektrische Spannung ist eine potentielle Schadensquelle und damit eine Gefährdung.
Wenn ein Patient oder Anwender dieser Spannung ausgesetzt ist, beispielsweise weil er in deren
Nähe kommt, sprechen wir von einer Gefährdungssituation. Eine Berührung kann zu einem
Schaden führen.
Software kann zu einer Gefährdungssituation beitragen. Zum Beispiel durch eine falsche
Berechnung oder durch eine falsche Anzeige. Die falsche Anzeige stellt aber nicht die
Gefährdungssituation dar.
An dieser Stelle ist eine kurze Übung durchzuführen, in der die Teilnehmern für ein einfaches
Beispiel Gefährdung und Gefährdungssituation benennen.
SCHADEN
„Physische Verletzung oder Schädigung der menschlichen Gesundheit oder Schädigung von
Gütern oder der Umwelt.”
Bezogen auf das Beispiel mit der Spannungsquelle kann eine defekte Isolation zu einem
Stromschlag führen, infolge dessen eine Person einen Schaden in Form einer Verbrennung oder
eines Kammerflimmerns erleiden kann.
Software alleine kann niemals direkt zu einem Schaden führen.
RISIKO
„Kombination der Wahrscheinlichkeit des Auftretens eines Schadens und des Schweregrades des
Schadens."
Dabei wird unter Schweregrad das "Maß der möglichen Folgen einer Gefährdung" verstanden.
Um das Risiko zu ermitteln, muss bezogen auf das Beispiel abgeschätzt werden, unter welchen
Umständen und mit welcher Wahrscheinlichkeit es zu einer Beschädigung der Isolation kommt
und mit der Patient oder Anwender sich im Einflussbereich des Produkts befinden – also die
Wahrscheinlichkeit dass eine Gefährdungssituation entsteht. Weiterhin muss die
Wahrscheinlichkeit bestimmt werden, mit der dann eine Person einen Schaden erleidet. Zum
Schluss muss der Schweregrad des Schadens zum Beispiel Stromschlag oder Kammerflimmern
klassifiziert werden.
Weitere wichtige Begriffe des Risikomanagements sind:
RISIKOANALYSE

Gesamtlehrplan
"Systematische Verwendung von verfügbaren Informationen zur Identifizierung von

Gefährdungen und Einschätzung von Risiken."
RISIKOBEWERTUNG
„Prozess des Vergleichs des eingeschätzten Risikos mit gegebenen Risikokriterien, um die
Akzeptanz des Risikos zu bestimmen."
RISIKOBEHERRSCHUNG
Gemäß DIN EN ISO 14971 der für die Maßnahmen zur Risikobeherrschung festzulegende Prozess,
in dem "Entscheidungen getroffen und Maßnahmen implementiert werden, durch die Risiken auf
festgelegte Bereiche verringert werden oder auf diesen gehalten werden".
Wiederholung der Inhalte des FL zur Auffrischung mit folgender Vertiefung:
Weitere wichtige Begriffe sind:
SICHERHEIT
"Freiheit von unvertretbaren Risiken." (EN ISO 14971)
GRUNDRISIKO
„Unter Grundrisiko ist das größtmögliche Risiko zu verstehen, das sich für ein Medizinprodukt
ohne Integration von (zusätzlichen) sicherheitstechnischen Maßnahmen ergibt.” [1]
RESTRISIKO
„Risiko, das nach der Anwendung von Maßnahmen zur Risikobeherrschung verbleibt." (EN ISO
14971)
VERTRETBARES RISIKO
„Risiko, das nach der Durchführung von Maßnahmen zur Risikobeherrschung verbleibt." [1]
Da Sicherheit als Freiheit von unvertretbaren Risiken definiert wird, kann die Sicherheit eines
Medizinprodukts als Wahrscheinlichkeit dargestellt werden, dass von diesem Produkt innerhalb
einer bestimmten Zeitdauer oder einer bestimmten Anzahl Anwendungen keine
Gefährdungssituation ausgeht und damit auch kein Schaden zu erwarten ist. Der Festlegung der
Lebensdauer eines Medizinprodukts, in der die Sicherheit von Patienten, Anwendern und Dritten
gewährleistet sein muss, kommt in diesem Zusammenhang eine große Bedeutung zu.
Zur Ermittlung des Grundrisikos eines Medizinprodukts werden zunächst der Schweregrad und
die Eintrittswahrscheinlichkeit des Schadens ohne Integration von risikomindernden Maßnahmen
betrachtet. Für jedes Risiko müssen so möglich Maßnahmen zur Risikominimierung festgelegt
werden. Nach der Festlegung dieser Maßnahmen wird das verbleibende Restrisiko neu bewertet.
Den Akzeptanzbereich legt ein Hersteller mit seiner Risikopolitik fest. Risikomindernde
Maßnahmen können zu neuen Gefährdungen und zu neuen Risiken führen. Diese sind im Rahmen
des Risikomanagement-Prozesses ebenfalls zu bearbeiten.
2.2. Risikobewertungsmatrix
2.2.1. Aufbau und Ziel der Matrix
Die Darstellung der Risiken in Form einer Matrix wird von der ISO 14971 nicht gefordert, dient
aber einem besseren Überblick und wird im Anhang der Norm als Beispiel erläutert.
Gesamtlehrplan
 Risikobewertungsmatrix
2.2.1.3. Aufbau und Ziel der Matrix
Lehrziele
M2-LE2.1-1-1 Den Aufbau einer Risikobewertungsmatrix kennen. K1 W
M2-LE2.1-1-1 Verstehen, dass die Risikobewertungsmatrix dem K2 W
Überblick dient.
M2-LE2.1-1-1 Wissen, dass die Risikobewertungsmatrix nicht -- K1
gesetzlich vorgeschrieben ist.
M2-LE2.1-1-1 Wissen, dass die Risikobewertungsmatrix spezifisch für -- K1
jedes Produkt erstellt werden sollte.
M2-LE2.1-1-1 Wissen, dass die Risikobewertungsmatrix die K1 W
Risikopolitik des Herstellers ausdrückt.
Risiko ist immer eine Kombination aus Wahrscheinlichkeit und Schwere des Schadens. Diese lässt
sich gut in Form einer Matrix darstellen, wobei die beiden Achsen den beiden Parametern
"Wahrscheinlichkeit des Schadens" und "Schwere des Schadens" entsprechen:
Nachdem die Schweregrad- und Wahrscheinlichkeitsklassen möglichst präzise definiert wurden,

legt der Hersteller in dieser Matrix die Risikoakzeptanzkriterien (zum Beispiel durch farbige
Markierung) entsprechend der Risikopolitik fest.
Der rot markierte Bereich kennzeichnet den Bereich, in dem die Risiken als nicht akzeptabel
eingestuft werden. Gemäß der EN ISO 14971:2012 müssen alle Risiken so weit wie möglich („as
far as possible“) gemindert werden. Es gibt keine Risiken, die ohne Maßnahme per se akzeptiert
werden dürfen. Wenn sich ein Risiko, im gelben Bereich, durch eine Maßnahme wegen dem
Stand der Technik nicht sinnvoll mindern lässt, muss der Hersteller eine Begründung angeben,
wieso keine weitere Maßnahme festgelegt wird.

Gesamtlehrplan
Im Lauf der Risikoanalyse kann der Hersteller die Anzahl der Risiken mit der entsprechenden
Kombination aus Wahrscheinlichkeit und Schwere in die jeweiligen Zellen eintragen. Damit ist ein
wichtiges Ergebnis der Risikoanalyse auf sehr übersichtliche Weise dargestellt, nämlich, wie viele
Schäden mit welcher Wahrscheinlichkeit und welchem Schweregrad identifiziert wurden.
Üblicherweise werden eine Matrix mit der Verteilung vor der Festlegung der Maßnahmen und
eine Matrix mit der Verteilung nach der Implementierung der Maßnahmen zum Vergleich erstellt.
Die Abbildung unten zeigt die Umsetzung der Risikomatrix nach der nicht mehr harmonisierten
Ausgabe EN ISO 14971:2007. In dieser Vorgängerversion war es möglich, einen „grünen“ Bereich
festzulegen, in dem Risiken als akzeptabel eingestuft werden konnten und nicht weiter gemindert
werden mussten. Der gelbe Bereich galt als "so gering wie vernü nftigerweise praktikable"
(ALARP). Damit wurde einem Hersteller bei der Festlegung einer Minderung Raum für
ökonomische Überlegungen gelassen, was die Medizinprodukterichtlinien aber explizit
ausschließen.

Die Erstellung einer Risikobewertungsmatrix ist nicht gesetzlich vorgeschrieben, sie ist jedoch ein
geeignetes Mittel für die schnelle visuelle Darstellung der Gesamtsituation. Vorgeschrieben ist es,
die grundlegenden Anforderungen (MDD) zu erfüllen, nach denen der Hersteller
 Risiken identifizieren (und die Ergebnisse dokumentieren) und
 diese Risiken bewerten muss.
Die Einteilung der Matrix in unterschiedliche Akzeptanzbereiche spiegelt die Risikopolitik des
Herstellers wieder. Die Bewertung, ob das resultierende Risiko akzeptabel ist oder nicht, ist
produkt- und unternehmensspezifisch. Das Gleiche gilt für die Einteilung der Achsen, die jeweils
genau vom Hersteller zu definieren sind. Die zweidimensionale Darstellung der Risiken wird in der
EN ISO 14971 als ein Weg zur Veranschaulichung gezeigt.
2.2.2. Die Achsen der Risikobewertung

Gesamtlehrplan
Um die Risiken bewerten zu können, muss die Auftretenswahrscheinlichkeit und der Schweregrad
des Schadens abgeschätzt werden. Dazu müssen Wertebereiche festgelegt werden
2.2.2.2. Die Wahrscheinlichkeitsachse
Lehrziele
M2-LE2.2-1-1 Wissen, welche Faktoren zu berücksichtigen sind, um K1 --
den Wertebereich abzuschätzen.
M2-LE2.2-1-1 Beispiele für die Einteilung der Wahrscheinlichkeit K2 --
nennen können.
M2-LE2.2-1-1 Wissen, dass die Achse oft mehrere Größenordnungen -- K1
umfasst und in der Regel logarithmisch ist.
M2-LE2.2-1-1 Die Wahrscheinlichkeitsachse für einen einfachen -- K3
beispielhaften Fall selbst definieren können.
Die Einstufung der Wahrscheinlichkeit des Auftretens eines Schadens kann qualitativ oder
quantitativ erfolgen, wobei nach Möglichkeit eine quantitative Einstufung vorzuziehen ist.
Die Einteilung der Wahrscheinlichkeit erfolgt in den meisten Fällen in diskreten Werten, wobei
mindestens 3 Niveaus (besser: mehr) verwendet werden sollten. Bei der Definition der
Schadenswahrscheinlichkeit ist zu Beginn eine Betrachtung der höchsten und niedrigsten
relevanten Wahrscheinlichkeit hilfreich (auch bei qualitativer Einstufung).
Ein Beispiel für eine vierstufige Einteilung sind die folgenden Kategorien:
 Häufig: Bei jeder 10.ten Nutzung oder häufiger
 Gelegentlich: Häufiger als jeder 1000.ten Nutzung aber seltener als bei jeder 10.ten Nutzung
 Vorstellbar: Häufiger als bei jeder 100.ten Nutzung
 Unwahrscheinlich: Seltener als bei jeder 100.000.ten Nutzung
Dabei kann eine Wahrscheinlichkeitsbewertung aus Sicht der Anwendung eines einzelnen
Produktes erfolgen oder auch für die Verwendung aller sich auf dem Markt befindlichen Produkte
erfolgen.
Die Wahrscheinlichkeit eines Schadens ist das Produkt der Wahrscheinlichkeit, dass eine
Gefährdungssituation entsteht, multipliziert mit der Wahrscheinlichkeit, dass diese
Gefährdungssituation zum Schaden führt.
Bsp: Die Wahrscheinlichkeit, dass sich jemand auf Grund einer herumliegenden Bananenschale
einen Knochen bricht, ist umso höher,
 je mehr Menschen an dieser Stelle verkehren und
 je höher der Anteil von Menschen mit Osteoporose ist.
Wie bereits erwähnt, muss die Definition der Wahrscheinlichkeitsbereiche produkt- und
unternehmensspezifisch erfolgen. Dies gilt auch für die Granularität der Einteilung (3 Kategorien
oder eher 10 Kategorien...).
Bei der Definition der Wahrscheinlichkeitsachse sollte man die höchste und niedrigste relevante
Wahrscheinlichkeit bestimmen und diesen Bereich in Klassen unterteilen. Dabei entsteht meist
eine Skala, die sich über mehrere Größenordnungen erstreckt. Die Wahrscheinlichkeitsachse ist
daher in der Regel eine logarithmische. Für die Definition kommen viele Einheiten in Betracht wie
'pro Behandlung', pro 'Gerät und Jahr' usw. Hilfreich ist die Nennung von spezifischen Beispielen
(Interpretationshilfen).
In diesem Abschnitt ist eine Übung durchzuführen, in der die Schulungsteilnehmer für einen
einfachen Fall beispielhaft eine Einteilung erstellen und Interpretationshilfen geben.

Gesamtlehrplan
2.2.2.3. Die Schweregradachse

Lehrziele
M2-LE2.2-2-1 Wissen, auf was bei der Klassenbildung für die K1 --
Schweregradachse zu achten ist.
M2-LE2.2-2-1 Verstehen, dass für die Bewertung des Schweregrades -- K2
medizinischer Sachverstand erforderlich ist und es
deshalb eine interdisziplinäre Fragestellung ist.
Bei der Definition der Schweregradachse sollte man zuerst vom größtmöglichen Schaden
ausgehen. Gelegentlich wird das größte Schadensmaß unterschätzt. Bei der Wahl der einzelnen
Kategorien (Schadensklassen) sollte man darauf achten, dass deren Klassifizierungskriterien eine
eindeutige Zuordnung ermöglichen. Hierbei helfen klar abgrenzbare – binäre – Sachverhalte, die
mit Ja oder Nein beantwortet werden können. Nur so kann weitgehend sichergestellt werden,
dass die später durchgeführten Bewertungen der einzelnen Risiken konsistent sind. Die Nennung
anwendungsspezifischer Beispiele ist dabei hilfreich.
Bsp.: Klassifizierungsmerkmale für die Schweregradachse:
 Reversibel (j/n)
 Notwendigkeit einer medizinischen Intervention (j/n)
 Lebensbedrohliche Verletzungen oder Erkrankungen (j/n)
 Tod (j/n)
Die Bewertung des Schweregrades eines Schadens ist eine medizinische Fragestellung. Für die
Festlegung der Bereiche und Beispiele muss unbedingt medizinischer Sachverstand in das Team
geholt werden.
Das Schadensausmaß wird hauptsächlich aus Sicht des Patienten festgelegt. Für ME-Geräte im
Scope der EN 60601-1, können auch für den Bediener Schäden durch physikalisch direkt
verursachte Gefährdungen entstehen. Diese Schäden, sollten im Rahmen einer ersten
Gefährdungsanalyse (Bsp. PHA) ermittelt werden und bei der Festlegung der Schweregrade
berücksichtigt werden. Je nach Zweckbestimmung kann auch der Patient selbst der Bediener sein.
2.2.3. Risikoakzeptanzkriterien
Welches Risiko wann akzeptabel ist, hängt vom Produkt und dessen medizinische
Zweckbestimmung ab. Dies wird bei der Definition der Risikoakzeptanzkriterien berücksichtigt.
 Risikoakzeptanzkriterien
2.2.3.3. Festlegung der Risikoakzeptanzkriterien
Lehrziele
M2-LE2.3-1-1 Die Bedeutung von Risikoakzeptanzkriterien und den K1 --
Zusammenhang mit der Risikomatrix kennen.
M2-LE2.3-1-1 Verstehen, dass sich die Entscheidung, ob ein Risiko -- K2
akzeptabel ist oder nicht, am Stand der Technik zu
orientieren hat.
Wie bereits eingangs erläutert, unterscheidet man im Wesentlichen zwei Bereiche:

Gesamtlehrplan
 zu hohes, d.h. nicht akzeptables Risiko

 Risiken, die man in ihrer Summe betrachten, gegen den Nutzen abwägen und möglichst
minimieren sollte (AFAP)
Ob ein Risiko akzeptabel ist oder nicht, hängt also davon ab, wie groß der erwartete Nutzen ist
und ob es Alternativen gibt, mit denen der gleiche Nutzen mit geringerem Risiko erreicht werden
kann.
Ob ein Risiko akzeptabel ist oder nicht, muss für jedes Produkt individuell abgewogen werden.
Die Hersteller sind in der Entscheidung zwar frei, müssen sich aber am Stand der Technik
orientieren. Alle zur Verfügung stehenden Daten müssen genutzt werden müssen. Es dürfen
beispielsweise Risiken nicht als akzeptabel eingestuft werden, wenn es alternative Verfahren mit
der gleichen medizinischen Zweckbestimmung gibt, bei denen diese Risiken nicht auftreten, bzw.
dort nicht akzeptiert würden.
2.3. Verfahren zur Gefährdungsanalyse

2.3.1. Grundlegendes zu Gefährdungsanalyse
Die Gefährdungsanalyse ist der erste Schritt zur (gesetzlich vorgeschriebenen) Risikoanalyse.
 Gefährdungsanalyse
 Risikoanalyse
2.3.1.3. Grundlegendes zu Gefährdungsanalyse
Lehrziele
M2-LE3.1-1-1 Den Unterschied zwischen Risikoanalyse und K2 --
Gefährdungsanalyse verstehen.
M2-LE3.1-1-1 Wissen, dass die ISO 14971 kein Verfahren explizit K1 --
vorschreibt.
M2-LE3.1-1-1 Wissen das die erwähnten Normen bereits K1 --
verschiedene hilfreiche Checklisten für eine initiale
Gefährdungsanalyse bereitstellen.
Die Gefährdungsanalyse ist eine Teilaktivität der Risikoanalyse. Sie ist der erste Schritt zur
Risikoanalyse und dient der Identifikation der potentiellen Ursachen (Gefährdungen) für einen
Schaden.
Eine Liste mit möglichen Gefährdungen befindet sich im Anhang E der ISO 14971. Weiterhin
enthält die ISO 14971 im Anhang C eine Liste mit Fragen zur Identifizierung von Eigenschaften, die
die Sicherheit beeinflussen können. Auch andere Normen, die auf die ISO 14971 verweisen,
nennen Beispiele bezogen auf deren Normenkontext.
Während ISO 14971 die Risikoanalyse und die vorausgehende Gefährdungsanalyse normativ
fordert, trifft sie keine Festlegung, welches Verfahren verwendet werden muss. Die ISO 14971
nennt und beschreibt u.a. die in den nächsten Abschnitten erläuterten Verfahren.
--
2.3.2. Preliminary Hazard Analysis
Gesamtlehrplan
Die Preliminary Hazard Analysis (PHA) ist ein geeignetes Verfahren für eine initiale
Gefährdungsanalyse, wenn die vollständige technische Lösung noch weitgehend unbekannt ist.
 PHA
2.3.2.3. Preliminary Hazard Analysis
Lehrziele
M2-LE3.2-1-1 Wissen, für was PHA steht und was sich dahinter K1 --
verbirgt.
M2-LE3.2-1-1 Wissen, dass die PHA nur eines von mehreren K1 --
Verfahren zur Gefährdungsanalyse ist.
M2-LE3.2-1-1 Die Vor- und die Nachteile des Verfahrens kennen. K1 --
M2-LE3.2-1-1 Sich der Bedeutung von Checklisten, beispielsweise K1 --
der ISO 14971, bewusst sein.
M2-LE3.2-1-1 Verstehen, welche Aspekte bei einer PHA -- K2
berücksichtigt werden müssen.
Die PHA ist ein induktives Analyseverfahren mit dem Ziel, die Gefährdungen,
Gefährdungssituationen und Ereignisse festzustellen, die bei einer gegebenen Tätigkeit,
Einrichtung oder einem gegebenen System Schäden verursachen können. Vereinfacht gesagt,
versucht man, anhand von Checklisten und 'Nachdenken' die möglichen Gefährdungen zu
erfassen (allerdings ohne systematisch die Ursachen zu analysieren). Solche Checklisten befinden
sich beispielsweise in der Richtlinie, in den Anhängen der ISO 14971 und in der IEC 80002.
Die PHA wird meist früh bei der Entwicklung eines Projekts angewendet, wenn wenige Angaben
über Einzelheiten der technischen Umsetzung oder über Betriebsabläufe vorliegen. In der Regel
ist die PHA Vorläufer für weitere Studien. Die PHA sollte nicht als einziges Verfahren zur
Gefährdungsanalyse verwendet werden.
Die Abschätzung der Wahrscheinlichkeiten und Schweregrade ist in diesem frühen Stadium oft
nur schwer möglich und nicht das eigentliche Ziel einer PHA. Mit der PHA werden die
Gefährdungen einer Produktidee greifbar und der Hersteller kann endscheiden, ob der
Entwicklung vorgelagerte Machbarkeitsabklärungen notwendig sind. Die PHA ist daher eine gute
Ausgangsbasis für weitere Architektur- und Designüberlegungen.
Bei einer PHA wird eine Liste von Gefährdungen und allgemeinen Gefährdungssituationen
erarbeitet, indem Merkmale berücksichtigt werden wie:
 verwendete oder hergestellte Werkstoffe und deren Reaktionsweise
 verwendete Ausrüstungen und Technologien
 physikalisch technische Wirkungsweise
 Inputs und Outputs des Produkts
 die Betriebsumgebung
 die Gestaltung
Wichtig ist immer der bestimmungsgemäße Gebrauch. Damit ist nicht nur die medizinische
Zweckbestimmung gemeint, sondern auch andere Handlungen wie z.B. Transport, Reinigung,
Wartung.
Die IEC/TR 80002-1 enthält Fragenkataloge, die helfen, SW-spezifische Gefährdungen zu
identifizieren.
Die FTA kann auch spezifisch für die graphische Benutzeroberfläche eingesetzt werden. Ein
Benutzer kann an einem interaktiven System genau drei Dinge tun:
Gesamtlehrplan
 Eine kognitive Leistung erbringen (erkennen, verstehen, unterscheiden).

 Etwas auswählen.
 Etwas eingeben.
Ein System kann lediglich Informationen anzeigen oder ausgeben (z.B. Alarm). Alles, was hier
schiefgehen kann, ist eine mögliche Ursache für eine Gefährdung.
2.3.3. Fault-Tree-Analysis
Die Fault-Tree-Analysis ist ein Top-Down Verfahren zur Gefährdungsanalyse.
 FTA
2.3.3.3. FTA
Lehrziele
M2-LE3.3-1-1 Wissen, für was FTA steht. K1 --
M2-LE3.3-1-1 Verstehen, dass die FTA ein Top-Down-Verfahren ist K2 --
und was das bedeutet.
M2-LE3.3-1-1 Die Vor- und Nachteile der FTA kennen. K1 --
M2-LE3.3-1-1 Die Baumdarstellung der FTA verstehen. K2 --
M2-LE3.3-1-1 Für ein einfaches Beispiel eine FTA durchführen -- K3
können.
FTA (Fault-Tree-Analysis) ist eine Fehlerbaumanalyse. Ihr Ziel besteht darin, Ursachen zu
bekannten Gefährdungen zu finden. Es ist eine Top-Down Methode ausgehend von der
Gefährdung hin zu möglichen Ursachen.
In deduktiver Weise, ausgehend von einem "top event", d.h. der angenommenen Gefährdung,
sucht man möglichen Ursachen oder Kombinationen von Ursachen. So werden zu Elementen im
Fehlerbaum immer weiter verursachende Elemente gesucht, bis entweder eine Ebene erreicht ist,
auf der der Fehler beherrscht werden kann oder bis man auf ein nicht weiter sinnvoll zerlegbares
„Elementarereignis“ gestoßen ist. Auf diese Weise lassen sich Kombinationen von Fehlerursachen
aufzeigen. Um diese Ursachenkette bis zu Systemkomponenten zurückverfolgen zu können, muss
die Architektur des Systems bekannt sein.
Die Ergebnisse werden bildlich in Form eines Baums dargestellt. Auf jeder Ebene des Baumes
werden Kombinationen der Fehlermöglichkeiten mit logischen Operatoren beschrieben (UND,
ODER). Die im Fehlerbaum festgestellten Fehlermöglichkeiten können Ereignisse sein, die mit
Hardware-Fehlern, menschlichem Versagen oder jedem anderen relevanten Ereignis
zusammenhängen, das zu dem unerwünschten Ereignis führt. Sie sind nicht auf den Zustand des
Ersten Fehlers beschränkt.
Jedem Ereignis kann zudem ein Wert für eine Wahrscheinlichkeit, mit der dieses Ereignis eintritt,
zugeordnet werden. Aus der logischen Verknüpfung der Einzelwahrscheinlichkeiten in den
Ereignisketten lässt sich die Gesamtwahrscheinlichkeit, mit der das top Ereignis eintritt,
berechnen (im einfachsten Fall unabhängiger Ereignisse: UND = Multiplikation, ODER = Addition).
Ein weiterer Vorteil dieser Darstellung besteht darin, dass zu jedem Ereignis mögliche
Maßnahmen in der Grafik notiert werden können.
Alternativ können die Fehlerursachen in Form eines sogenannten Ursache-Wirkungs-Diagramms
dargestellt werden. Ein Beispiel dafür sind Ishikawa-Diagramm, die ebenfalls eine Baumstruktur
aufweisen, aber keine logischen Gates (UND, ODER) nutzen. Es ist möglich, dass schon aufgrund

Gesamtlehrplan
einer erkannten Fehlerursache unmittelbar Hinweise auf mögliche Maßnahmen zur

Fehlervermeidung abgeleitet werden können.
Hier Übung einbauen.
2.3.4. Failure Mode and Effects Analysis (FMEA)
Die Failure Mode and Effects Analysis ist ein Bottom-Up Verfahren zur Gefährdungsanalyse.
 FMEA
2.3.4.3. FMEA
Lehrziele
M2-LE3.4-1-1 Wissen, für was FMEA steht. K1 --
M2-LE3.4-1-1 Verstehen, dass die FMEA ein Bottom-Up-Verfahren K2 --
ist und was das bedeutet.
M2-LE3.4-1-1 Die Vor- und Nachteile der FMEA kennen. K1 --
M2-LE3.4-1-1 Verstehen, wie bei einer FMEA vorgegangen wird. -- K2
M2-LE3.4-1-1 Fehler in einer gegebenen FMEA finden können. -- K3
Die FMEA-Methode ist eine Bottom-Up-Verfahren, d.h. man startet mit einem angenommenen
Fehler in einer Komponente oder einem Input und sucht nach sich daraus resultierenden
unbekannten Wirkungen, beispielsweise Gefährdungen.
Im Gegensatz zur FTA wird bei der FMEA nur die unmittelbare Folge eines Ereignisses untersucht,
d.h. Kombinationen von Fehlern werden nicht betrachtet. Daher empfiehlt es sich, beide
Verfahren miteinander zu kombinieren.
Das Ergebnis der FMEA wird in der Regel in einer Tabelle mit folgenden Spalten festgehalten:
 Komponente/Funktion/Input
 Fehler in dieser Komponente/Funktion/Input
 Auswirkung auf Subsystem
 Auswirkung auf Gesamtsystem
 Gefährdung oder möglicher Schaden
 Wahrscheinlichkeit des Schadens
 Erwarteter Schweregrad des Schadens
 Resultierendes Risiko
Mit dieser Tabelle lassen sich auch die Ergebnisse anderer Methoden zur Gefährdungsanalyse
bzw. Risikoanalyse darstellen.
Die FMEA benötigt i.d.R. eine Systemarchitektur oder ein detailliertes Design und zeichnet sich
durch eine hohe Systematik und Verständlichkeit aus.
Die FMEA-Tabelle ergänzt man meist um weitere Spalten, um die Maßnahmen zur
Risikobeherrschung ebenfalls zu dokumentieren:
 eine Eingrenzung des betrachteten Systems,
 Maßnahmen- bzw. Lösungsvorschläge zu priorisierten Risiken
 eine Verfolgung vereinbarter Vermeidungs- und Entdeckungsmaßnahmen
 Wahrscheinlichkeit des Schadens nach Maßnahmen
 erwarteter Schweregrad des Schadens nach Maßnahmen
Gesamtlehrplan
 Resultierendes Risiko nach Maßnahmen

 Durch Maßnahmen resultierende neue Risiken
Die Bewertung der einzelnen Risiken vor und nach den Maßnahmen erfolgt durch
interdisziplinäre Teams, die wie im Abschnitt "Risikomatrix" bereits beschrieben, vorgehen. Für
jede Gefährdungsursache können dann das Risko berechnet und entsprechende Maßnahmen
festgelegt werden.
Nach der Erstbewertung (Grundrisiko) und der Implementierung der Maßnahmen erfolgt eine
erneute Risikobewertung. Es wird geprüft, ob die geplanten Maßnahmen das Risiko für einen
Schaden ausreichend minderen. Beide Bewertungen - vor und nach Festlegung von Maßnahmen -
werden in einer Risikobewertungsmatrix dargestellt. Verbleiben auch nach Maßnahmen noch
Risiken im nicht vertretbaren Bereich, müssen weitere Maßnahmen ergriffen und/oder
Lösungsansätze entwickelt werden. Lässt sich ein Risiko mit der verwendeten Technologie oder
der gewählten Architektur nicht ausreichend mindern, muss unter Umständen ein alternativer
technologischer Ansatz angewendet werden oder im schlimmsten Fall die Entwicklung
abgebrochen werden.
Die Umsetzung der Maßnahmen muss im weiteren Projektverlauf sichergestellt und verifiziert
werden.
In diesem Abschnitt ist eine Übung durchzuführen, in der die Schulungsteilnehmer in einer
gegebenen FMEA einen Fehler finden.
2.4. Der Risikomanagement-Prozess nach ISO 14971

2.4.1. Allgemeine Anforderungen
Die harmonisierte Norm ISO 14971 enthält Anforderungen an das Risikomanagement für
Medizinprodukte, sowie eine Beschreibung des zu etablierenden Risikomanagementprozesses.
2.4.1.2. Allgemeine Anforderungen
Lehrziele
M2-LE4.1-1-1 Wissen, dass die ISO 14971 die Norm zum K1 --
Risikomanagement bei Medizinprodukten ist.
M2-LE4.1-1-1 Den Risikomanagementprozess im Groben K2 --
beschreiben können.
M2-LE4.1-1-1 Wissen, dass Hersteller einen Risikomanagementplan K1 W
erstellen müssen.
M2-LE4.1-1-1 Die Forderungen der ISO 14971 in Bezug auf die -- K2
Organisation, den Risikomanagementprozess im
Allgemeinen und die Risikopolitik im Besonderen
(Kapitel 3) verstehen.
Die ISO 14971 legt für Hersteller einen Prozess fest, mit dem Gefährdungen durch
Medizinprodukten erkannt, Risiken abgeschätzt, bewertet und beherrscht, sowie die Wirksamkeit
dieser Risikobeherrschungsmaßnahmen überwacht werden.
Der von der Norm geforderte Risikomanagement-Prozess muss folgende Aktivitäten beinhalten:
 Risikoanalyse,
 Risikobewertung,
 Risikobeherrschung,
 Abschließende Nutzen-Risiko-Bewertung und

Gesamtlehrplan
 Informationen aus der Produktion und der Produktion nachgelagerten Phasen.

Die Anforderungen der Norm gelten für alle Phasen des Produktlebenszyklus eines
Medizinprodukts, also auch nach der Entwicklung und Produktion.
Das Risikomanagement muss geplant (Risikomanagementplan) und dokumentiert werden. Der
Risikomanagementplan muss Teil der Risikomanagementakte sein.
Wiederholung der Inhalte des FL zur Auffrischung und Vertiefung. Außerdem:
Die Verantwortung des Risikomanagements liegt bei der Geschäftsleitung. Diese ist u.a. dafür
verantwortlich, dass ausreichend viele und entsprechend geschulte Mitarbeiter, sowie die
notwendigen Ressourcen und Arbeitsmittel zur Verfügung stehen.
Ein Risikomanagementverfahren für Medizinprodukte soll sich an Kriterien für die Vertretbarkeit
von Risiken orientieren. Die Kriterien für vertretbare Risiken müssen vor Beginn der
Risikomanagementaktivitäten im Risikomanagementplan festgelegt werden.
Wenn der Hersteller bereits über ein QM-System nach ISO 13485 verfügt, kann das
Risikomanagement dort eingewoben werden.
2.4.2. Der Risikomanagementprozess
Eine Kernforderung der ISO 14971 lautet, dass der Hersteller eines Medizinproduktes einen
Risikomanagementprozess zu etablieren hat.
 Risikomanagementprozess
2.4.2.3. Der Risikomanagementprozess
Lehrziele
M2-LE4.2-1-1 Die Bedeutung des Risikomanagementprozesses K2 --
verstehen.
M2-LE4.2-1-1 Verstehen, warum der Risikomanagementprozess K2 --
über den gesamten Produktlebenszyklus
durchzuführen ist.
M2-LE4.2-1-1 Die Abfolge der Tätigkeiten im -- W
Risikomanagementprozess verstehen.
M2-LE4.2-1-1 Die zu berücksichtigenden Aspekte verstehen. -- K2
Die Abbildung zeigt den Risikomanagementprozess nach ISO 14971, welcher über den gesamten
Lebenszyklus eines Medizinprodukts angewandt werden muss.

Gesamtlehrplan
(Quelle: ISO 14971)

Der Lebenszyklus schließt den Betrieb, die Wartung und die Entsorgung ein. In diesem
Zusammenhang muss ein Hersteller das Produkt während dem gesamten Lebenszyklus
beobachten und feststellen, ob die gewünschte Wirksamkeit der risikomindernden Maßnahmen
gegeben ist und ob neue Risiken auftreten, die bei der Entwicklung noch nicht erkennbar waren.
Das Risikomanagement stellt ein wesentliches Werkzeug zur Erfüllung der Grundlegenden
Anforderungen und der für das jeweilige Medizinprodukt zulässigen
Konformitätsbewertungsverfahren dar. In jedem Konformitätsbewertungsverfahren für
Medizinprodukte werden vom Hersteller die Ergebnisse der Risikoanalyse, Risikobewertung und
Risikobeherrschung als Nachweis und damit Voraussetzung für die CE-Kennzeichnung eines
Medizinprodukts gefordert. Basierend auf den "Grundlegenden Anforderungen" ist der Nachweis
zu führen, dass etwaige Risiken – verglichen mit der nützlichen Wirkung für den Patienten –
vertretbar und mit einem hohen Maß des Schutzes von Gesundheit und Sicherheit vereinbar sind.
Folgende Aktivitäten sind für jedes Medizinprodukt (bzw. jedes Zubehör zu einem
Medizinprodukt) in einem kontinuierlichen Prozess für die gesamte Lebensdauer des
Medizinprodukts im Rahmen des Risikomanagements zu etablieren, aufrechtzuerhalten und zu
überwachen:
 Planen der Risikomanagement-Aktivitäten.
 Durchführen der geplanten Risikomanagement-Aktivitäten.
 Überprüfen, ob die Kriterien für die Vertretbarkeit von Risiken eingehalten werden
(Verifikation).
 Durchführen von Korrekturmaßnahmen bzw. präventiven Maßnahmen für den Fall, dass die
Kriterien für die Vertretbarkeit von Risiken nicht eingehalten wurden.
2.4.3. Risikomanagementplanung
Die Tätigkeiten im Risikomanagementprozess müssen über den Lebenszyklus des
Medizinproduktes geplant und dokumentiert werden.
Gesamtlehrplan
2.4.3.2. Risikomanagementplanung
Lehrziele
M2-LE4.3-1-1 Wissen, dass die Aktivitäten des Risikomanagement- K1 --
Prozesses für jedes Produkt geplant und dokumentiert
werden müssen.
M2-LE4.3-1-1 Die Planungsinhalte kennen. K1 K1
Der Risikomanagementplan beschreibt, wie der Risikomanagementprozess für ein konkretes
Medizinprodukt durchzuführen ist. Der Plan enthält sowohl eine Beschreibung des
Medizinproduktes (System) mit Zweckbestimmung und Anwenderkreis (professioneller
Anwender, Laie, Behinderter, etc.), als auch die für das Medizinprodukt (System) zutreffenden
Phasen des Lebenszyklus.
Im Risikomanagementplan müssen auch die Tätigkeiten einschließlich Verantwortlichkeiten sowie
die Risikopolitik und Akzeptanz des Herstellers festgelegt werden.
Für jedes Medizinprodukt müssen der Risikomanagementplan und die Ergebnisse aller
Risikomanagement-Aktivitäten während des gesamten Lebenszyklus des Medizinprodukts
dokumentiert werden und sind Teil der Risikomanagement-Akte.
Der Plan sollte folgenden Inhalt haben:
 Zweckbestimmung bzw. Referenz darauf
 Planung der Risikomanagement-Aktivitäten über den gesamten Lebenszyklus des Produktes
 Vorgaben zur Dokumentation
 Bestimmung der Verantwortlichkeiten für die Aktivitäten (interdisziplinäres Teams)
 Risikoakzeptanzkriterien (Risikopolitik), ggf. auch welche für den Fall, dass die
Wahrscheinlichkeit des Auftretens eines Schadens nicht eingeschätzt werden kann
 Ergebnisse aller Aktivitäten wie beispielsweise “FMEA-Tabelle“, Pläne und Ergebnisse der
Prüfungen (z.B. Tests), um die Wirksamkeit der Maßnahmen zu prüfen
 Ergebnisse der Aktivitäten im Zusammenhang mit der Herstellung und der Herstellung
nachgelagerten Phasen des Produkts.
Der Aufwand und Umfang der Planung sollte dem Risikograd angemessen sein.
2.4.4. Zweckbestimmung und bestimmungsgemäßer Gebrauch
Ganz entscheidend für die Gefährdungsanalyse sind die Zweckbestimmung bzw. der
bestimmungsgemäße Gebrauch.
 Bestimmungsgemäßer Gebrauch
 Zweckbestimmung
2.4.4.3. Zweckbestimmung und bestimmungsgemäßer Gebrauch
Lehrziele
M2-LE4.4-1-1 Die Begriffe Zweckbestimmung und K2 --
bestimmungsgemäßer Gebrauch unterscheiden und
Beispiele nennen können.
M2-LE4.4-1-1 Verstehen, dass ohne Festlegung des K2 --
bestimmungsgemäßen Gebrauchs eine vollständige
Gefährdungsanalyse nicht möglich ist.
M2-LE4.4-1-1 Die Definition eines bestimmungsgemäßen Gebrauchs -- K3
Gesamtlehrplan
auf Vollständigkeit prüfen können.

Um Risiken zu identifizieren, muss der Hersteller die Zweckbestimmung bzw. den
bestimmungsgemäßen Gebrauch des Medizinproduktes definieren. ISO 14971 (ebenso wie IEC
62366) beschränkt sich jedoch nicht nur auf die medizinische Zweckbestimmung, sondern
verlangt auch eine Definition des bestimmungsgemäßen Gebrauchs. Dieser umfasst weitere
Anwendungsszenarien wie Transport, Reinigung, Wartung usw.
Wird bei der Beschreibung der Zweckbestimmung und dem bestimmungsgemäßen Gebrauch
ungenau gearbeitet, ist auch die Risikoanalyse unvollständig.
Der Hersteller muss in der Zweckbestimmung und dem bestimmungsgemäßen Gebrauch
folgendes dokumentieren:
 Medizinischer Zweck, medizinische Indikation, Krankheit bzw. Verletzung;
 Patient, untersuchtes oder behandeltes Körperteil;
 Charakterisierung der Anwender, beispielsweise in Bezug auf Ausbildung, sprachliche und
intellektuelle Fähigkeiten;
 Gebrauchsumgebung: physikalische Merkmale wie Lichtverhältnisse, Feuchtigkeit,
Geräuschkulisse;
 Gebrauchsumgebung in Bezug auf eine „mentale Workload“, auf Stress usw.;
 Weitere Verwendungszwecke wie Reinigung, Transport und Wartung (bei Software Update,
Remote Control).
2.4.5. Gefährdungs- und Risikoanalyse
Eine zentrale Aktivität des Risikomanagementprozesses ist die Erstellung der Risikoanalyse.
2.4.5.2. Gefährdungs- und Risikoanalyse
Lehrziele
M2-LE4.5-1-1 Die Reihenfolge, in der Risiken gemäß ISO 14971 K2 --
abgeschätzt werden sollen, verstehen.
M2-LE4.5-1-1 Wissen, wie man von Gefährdungen auf Risiken K1 --
schließt.
M2-LE4.5-1-1 Wissen, welche Informationsquellen genutzt werden -- K2
können, um Wahrscheinlichkeiten von Risiken
abzuschätzen.
M2-LE4.5-1-1 Verstehen, dass die Abschätzung von -- K2
Wahrscheinlichkeit und Schweregrad nur im Team
vorgenommen werden kann.
Zur Erinnerung: Risikoanalyse bedeutet nach ISO 14971: Systematische Verwendung von
verfügbaren Informationen, um Gefahren zu identifizieren und Risiken abzuschätzen.
Dabei ist eine bestimmte Reihenfolge einzuhalten:
 Festlegung der Zweckbestimmung / des bestimmungsgemäßen Gebrauchs,
 Gefährdungsanalyse und schließlich
 Bewertung der Schweregrad und der Auftretenswahrscheinlichkeit.
Auf alle diese Punkte wurde bereits im Detail in den entsprechenden Abschnitten eingegangen.
Von den Gefährdungen kommt man also durch die Bewertung des Schweregrades und der
Wahrscheinlichkeit zu den Risiken. An die Risikoanalyse schließt sich dann die Risikobewertung
Gesamtlehrplan
an. Ob ein Risiko akzeptabel ist oder nicht, wird durch die Risikopolitik des Herstellers festgelegt
(siehe Abschnitt "Risikobewertungsmatrix").
Die Risikoanalyse kann nicht von einer Person alleine durchgeführt werden. Speziell für die
Bewertung von Schweregrad und Wahrscheinlichkeit muss ein interdisziplinäres Team
herangezogen werden. In der Regel wird die Risikoanalyse iterativ im Verlauf von mehreren
Workshops erstellt.
Da gerade die Bewertung der Auftretenswahrscheinlichkeit eine schwierige Aufgabe ist, nennt EN
ISO 14971 einige Quellen, aus denen Informationen hierfür herangezogen werden können:
 veröffentlichte Normen;
 wissenschaftlich-technische Daten;
 Einsatzdaten von ähnlichen, bereits in Anwendung befindlichen Medizinprodukten
einschließlich veröffentlichter Berichte über Zwischenfälle;
 Gebrauchstauglichkeitsuntersuchungen mit typischen Anwendern;
 klinische Nachweise;
 Ergebnisse geeigneter Untersuchungen;
 Expertenmeinungen; und
 externe Qualitätsbeurteilungsprogramme.
2.4.6. Risikobeherrschung
Ein Ziel des Risikomanagements besteht darin, Risiken zu beherrschen. Dafür werden
Risikobeherrschungsmaßnahmen definiert.
 Risikobeherrschung
2.4.6.3. Risikobeherrschung
Lehrziele
M2-LE4.6-1-1 Die Reihenfolge kennen, in der versucht werden muss, K1 --
identifizierte Risiken zu beherrschen.
M2-LE4.6-1-1 Wissen, welche Auswirkungen Maßnahmen zur K1 --
Risikobeherrschung haben.
M2-LE4.6-1-1 Wissen, dass eine Information über ein Risiko die K1 --
Wahrscheinlichkeit, dass dieser Schaden auftritt,
selten um mehr als eine Klasse reduziert.
M2-LE4.6-1-1 Für Software typische Maßnahmen (z.B. -- K1
Checksummen) kennen.
M2-LE4.6-1-1 Wissen, dass auch im Herstellungsprozess Risiken -- K1
liegen, die beherrscht werden müssen.
Der Hersteller hat für jedes Risiko, für das eine Maßnahme zur Risikominimierung notwendig ist,
 zuerst ein inhärent sicheres Design anzustreben,
 falls dies nicht möglich oder sinnvoll umsetzbar ist, Schutzmaßnahmen zu implementieren
oder
 falls auch das nicht realisiert werden kann oder ausreicht, einen Hinweis auf diese Restrisiken
zu geben.
Die Maßnahmen zur Risikominimierung wirken sich in der Risikobewertungsmatrix wie folgt aus:

Gesamtlehrplan
 Inhärente Sicherheit bedeutet, dass das entsprechende Risiko nach der Umsetzung nicht
mehr existiert.
 Schutzmaßnahmen können sowohl die Auftretenswahrscheinlichkeit als auch den
Schweregrad des Schadens verringern.
 Mit der Harmonisierung der EN ISO 14971:2012 sind Hinweise zur Sicherheit in einer
Gebrauchsanweisung alleine nicht mehr zur Reduzierung geeignet.
Jede dieser Maßnahmen ist bezüglich Umsetzung und Wirksamkeit zu verifizieren. Außerdem
muss geprüft werden, ob durch die Risikobeherrschungsmaßnahme neue Risiken entstehen
können.
Gerade für Software muss der Hersteller im Entwicklungsprozess verschiedene Aktivitäten
(qualitätssichernde Maßnahmen) definieren um das systematische Einschleppen von Fehlern zu
vermeiden. Der einfache Hinweis „Prozesses befolgen“ darf allerdings nicht als Maßnahme
festgelegt werden (siehe Grundlagen der integrierten Sicherheit aus der MDD). Neben den
qualitätssichernden Maßnahmen sind vor allem Design- und Architekturregeln eine Möglichkeit
zur Vermeidung von klassischen Softwarefehlern. Dies geschieht in der Regel in der SW-
Architektur (z.B. parallele, sich überwachende Prozesse) oder im SW-Design (z.B. durch
Checksummen). Design- und Programmierregeln, sowie die systematische Verifizierung aller
Artefakte sind weitere Risikobeherrschungsmaßnahmen, die beim Software-Entwicklungsprozess
ansetzen.
Die notwendige Risikobeherrschung betrifft nicht nur das Produkt(design) selbst und mögliche
Auswirkungen seines Einsatzes, sondern auch den Produktionsprozess. Ein nicht beherrschter
Produktionsprozess kann die Sicherheit des Medizinproduktes unmittelbar beeinträchtigen, z.B.
durch:
 verschmutzte Bauteile oder Beeinträchtigung der Sterilität,
 veränderte physikalische oder chemische Materialeigenschaften,
 fehlende oder falsche (z.B. gesperrte) Komponenten oder
 falsch montierte Bauteile.
Letztendlich fällt auch die Toolvalidierung (siehe Abschnitt "Toolvalidierung") in diese Kategorie
prozessorientierter Risikobeherrschungsmaßnahmen.
2.4.7. Risiko-/Nutzenbewertung
Trotz implementierter Risikobeherrschungsmaßnahmen sind Medizinprodukte meist nicht frei
von Risiken. Dies ist jedoch akzeptabel, wenn der durch das Produkt erreichte Nutzen überwiegt
und die Risiken nicht weiter reduziert werden können. Die Nutzenbewertung muss durch
klinische/medizinische Daten belegt sein.
2.4.7.2. Risiko-/Nutzenbewertung
Lehrziele
M2-LE4.7-1-1 Verstehen, dass verbleibende Risiken durchaus K2 --
akzeptabel sein können.
M2-LE4.7-1-1 Wissen, dass das Inverkehrbringen nicht gestattet ist, K1 --
wenn die Nutzen die Risiken (nach Umsetzung der
risikominimierenden Maßnahmen) nicht überwiegen.
M2-LE4.7-1-1 Wissen, dass die Risikobewertungsmatrix alleine nicht -- K1
ausreicht.

Gesamtlehrplan
Das Verfahren der Umsetzung von Maßnahmen und Neubewertung der Risiken ist solange
iterativ durchzuführen, bis keine weiteren risikominimierenden Maßnahmen sinnvoll angewendet
werden können.
Der Hersteller muss nachweisen, dass der Nutzen die Risiken überwiegt. Falls dies nicht möglich
ist, darf der Hersteller das Medizinprodukt nicht in den Verkehr bringen.
Der Hersteller muss sich bei der Risiko-Nutzen-Beurteilung der Tragweite seiner Entscheidung
bewusst sein. Dazu gehören technische, klinische, durch Vorschriften gegebene, ökonomische,
soziologische und politische Zusammenhänge, die es zu berücksichtigen gilt. Da diese Art der
Analyse äußerst produktspezifisch ist, ist eine Anleitung allgemeiner Art nicht möglich. Unter
Umständen ist eine klinische Prüfung nach einem gesetzlich anerkannten Verfahren erforderlich,
um zu verifizieren, dass das Verhältnis zwischen medizinischem Nutzen und Restrisiko vertretbar
ist.
Einw Möglichkeit für die Analyse der Risiko-Nutzen Beurteilung ist das folgende Schema (nicht aus
der Norm):
 Technische Fähigkeit: Liefert das System verlässliche Informationen?
 Diagnostische Korrektheit: Sind die Diagnoseergebnisse korrekt?
 Diagnostischer Impact: Dient die Benutzung als Alternative zu anderen Verfahren?
 Therapeutischer Impact: Beeinflusst das System Planung und Art und Weise der Therapie?
 Patient Outcome: Unterstützt oder verbessert das System die Gesundheit des Patienten?
2.4.8. Nachgelagerte Phase
Der Risikomanagementprozess ist eine kontinuierliche Aktivität, die auch nach Auslieferung des
Produktes an den Kunden fortgeführt werden muss.
2.4.8.2. Nachgelagerte Phase
Lehrziele
M2-LE4.8-1-1 Verstehen, dass der Risikomanagementprozess nicht K2 --
mit dem Ende der Entwicklung oder der Produktion
endet.
M2-LE4.8-1-1 Die Gründe benennen können, weshalb es dieser K2 --
nachgelagerten Phase bedarf.
M2-LE4.8-1-1 Die Informationsquellen kennen, die sie für ein -- K1
Risikomanagement in der nachgelagerten Phase
nutzen können.
M2-LE4.8-1-1 Wissen, wie man bei nicht mehr akzeptablen Risiken -- K1
reagieren muss/kann.
Hersteller müssen auch nach der Entwicklung, Produktion und Inverkehrbringen des Produkts
Informationen sammeln und auswerten, z.B. um
 bisher unbekannte Gefährdungen zu identifizieren
 Abschätzungen von Wahrscheinlichkeiten und Schweregraden von Schäden zu korrigieren
und
 die Gültigkeit der Akzeptanzkriterien bzw. der Risikopolitik zu prüfen bzw. anzupassen.
Die Informationen, die vom Bediener, vom Anwender oder von dem für die Installation, den
Gebrauch und die Wartung des Medizinprodukts verantwortlichen Personen erzeugt werden,

Gesamtlehrplan
müssen systematisch gesammelt und verarbeitet werden. Dazu muss der Hersteller ein System
festlegen. Es kann sich dabei um Rückmeldungen von Kunden, von eigenen Mitarbeitern, von
SOUP-Herstellern oder Anwendern handeln. Auch neue oder überarbeitete Normen können in
diesem Zusammenhang eine Rolle spielen. Schließlich sollten auch öffentlich zugängliche
Informationen (Behördenmeldungen wie vom BfArM oder der FDA, klinische Literatur) über
ähnliche auf dem Markt befindliche Medizinprodukte, Verfahren oder Technologien gesammelt
und überprüft werden. Hersteller, die ein Qualitätsmanagement implementiert haben, zum
Beispiel nach ISO 13485, müssen ein entsprechendes Reporting-System zur Erfassung und
Messung solcher Informationen unterhalten.
Diese Informationen müssen auf eine mögliche Sicherheitsrelevanz bewertet werden:
 Liegen vorher nicht erkannte Gefährdungen oder Gefährdungssituationen vor?
 Müssen die Wahrscheinlichkeiten und Schweregrade resultierende Schäden neu bewertet
oder sogar neue Schäden betrachtet werden?
 Ergeben sich neue oder/und nicht akzeptable Risiken?
Falls "ja", müssen die Auswirkungen auf vorher durchgeführte Tätigkeiten des
Risikomanagements bewertet werden und als Eingabe in den Risikomanagement-Prozess
zurückfließen. Außerdem ist eine Überprüfung der Risikomanagementakte für das
Medizinprodukt durchzuführen. Falls die Möglichkeit besteht, dass das Restrisiko bzw. die
Restrisiken oder deren Akzeptanz sich verändert hat (haben), müssen die Auswirkungen auf
vorher durchgeführte Maßnahmen der Risikobeherrschung neu bewertet werden.
Die nachgelagerte Phase dient auch der Prozessverbesserung. So wird z.B. der
Risikomanagementplan an sich bewertet und evtl. Maßnahmen (z.B. Schulungen) ergriffen.
2.5. Dokumentation
2.5.1. Übersicht über die Dokumentenlandschaft
Die Dokumentation ist ein wesentlicher integraler Bestandteil des Risikomanagements.
2.5.1.2. Übersicht über die Dokumentenlandschaft
Lehrziele
M2-LE5.1-1-1 Die zu erstellenden Dokumente kennen. K1 W
M2-LE5.1-1-1 Wissen, dass die Risikomanagementakte nicht als K1 W
physische Akte vorliegen muss.
M2-LE5.1-1-1 Wissen, dass die Konformität durch Inspektion der K1 W
Akte geprüft wird.
M2-LE5.1-1-1 Die in der Risikomanagementakte referenzierten -- K3
Dokumente mit anderen Dokumenten in Beziehung
stellen können.
ISO 14971 verlangt die Erstellung einer Risikomanagementakte für jedes Medizinprodukt. Ob die
regulatorischen Vorgaben erfüllt worden sind oder nicht, wird durch Einsicht in diese Akte
geprüft.
In dieser Akte werden alle Dokumente - physikalisch oder referenziert - hinterlegt, die im Rahmen
der Aktivitäten des Risikomanagements entstehen. Aus dem Inhalt der Akte hat hervorzugehen,
wie sich die Ergebnisse der Risikoanalyse, der Risikobewertung, der Implementierung und
Überprüfung der Risikomaßnahmen, sowie der Beurteilung der Restrisiken zurückverfolgen
lassen. Auch der bestimmungsgemäße Gebrauch und die Risiko/Nutzen-Analyse gehören zur
Risikomanagementakte.
Gesamtlehrplan

Wiederholung der Inhalte des FL zur Auffrischung und Vertiefung.
Außerdem:
In diesem Abschnitt ist eine (kurze) Übung durchzuführen, in der die Schulungsteilnehmer
bestehende Dokumente den einzelnen Kapiteln der ISO 14971 zuordnen.
2.5.2. Risikotabelle
Neben dem Risikomanagementplan ist die "Risikotabelle" ein zentraler Bestandteil der
Risikomanagementakte.
2.5.2.2. Risikotabelle
Lehrziele
M2-LE5.2-1-1 Den Aufbau der Risikotabelle beschreiben und -- K2
erklären können.
--
Die „Risikotabelle“ ist eine geeignete Methode, um Herstellern und Auditoren einen schnellen
Überblick zu verschaffen und um die Tätigkeiten auf Vollständigkeit zu prüfen. Die Risikotabelle
dokumentiert sowohl die Risikoanalyse als auch die Risikobeherrschung.
Besonders die FDA legt auf diese Form der Darstellung Wert.
2.6. Risikomanagement für Software

2.6.1. Risikomanagement und Software-Klassifizierung
Das Softwarerisikomanagement ist die Grundlage für die Vergabe der Softwaresicherheitsklasse
nach IEC 62304.
 Softwaresicherheitsklasse
2.6.1.3. Risikomanagement und Software-Klassifizierung
Lehrziele
M2-LE6.1-1-1 Wissen, dass jedes Software (Teil-)System risikobasiert -- K1
zu klassifizieren ist.
M2-LE6.1-1-1 Wissen, dass bei fehlender Klassifizierung die Software -- K1
automatisch als Klasse C eingestuft ist.
M2-LE6.1-1-1 Wissen, dass die SW-Klassifizierung sowohl bei der -- K1
Neuentwicklung wie auch bei Änderungen
durchzuführen und zu dokumentieren ist.
M2-LE6.1-1-1 Verstehen, wie die Software-Sicherheitsklasse durch -- K2
HW-Maßnahmen reduziert werden kann.

Gesamtlehrplan
Mit der Durchführung des Risikomanagements für das Produkt wird auch der Grundstein für das
Software-Risikomanagement gelegt und damit einhergehend für die Vergabe der Software-
Sicherheitsklassen nach IEC 62304.
Ein wesentlicher Punkt bei der Software-Entwicklung ist, dass jedem Softwaresystem nach DIN EN
62304 eine Software-Sicherheitsklasse zuzuordnen ist. Dabei ist der maximale durch die Software
verursachte Schaden (nicht der maximale durch das Medizinprodukt verursachte Schaden)
entscheidend.
Die IEC 62304 definiert die Sicherheitsklasse eines Software-Systems anhand des Schweregrads
eines potenziellen Schadens, den die Software im Fehlerfall anrichten kann. Als Konsequenz
ergibt sich hieraus die in der IEC 62304 erhobene Forderung, dass jedes Software-System einer
der folgenden Software-Sicherheitsklassen zuzuordnen ist:
 Klasse A: Die Software verursacht keine Verletzung oder Schädigung der Gesundheit.
 Klasse B: Die Software verursacht keine schwere Verletzung.
 Klasse C: Die Software kann den Tod oder eine schwere Verletzung verursachen.
Solange ein System, eine Komponente oder eine Einheit nicht klassifiziert ist, ist sie der Klasse C
zuzuordnen. Es ist jedoch möglich, die SW-Klassifizierung durch eine geeignete HW-Maßnahme
um eine Klasse zu reduzieren. Die Softwareklassifizierung muss nicht nur bei Neuentwicklungen
durchgeführt, sondern auch bei Software-Änderungen überprüft und ggf. angepasst werden.
Das Amendement zur IEC 62304 ändert die Sicherheitsklassifizierung dahingehend, dass
risikominimierende Maßnahmen außerhalb(!) des Software-Systems betrachtet werden. Falls die
dann verbleibenden Risiken akzeptabel sind, darf das Software-System als Klasse A klassifiziert
werden.
Die Klassifizierung kann entsprechend der Systemarchitektur weiter verfeinert werden, wobei
jedes Teil-System zunächst einmal die Klassifizierung des übergeordneten Systems "erbt". Wenn
der Hersteller nachvollziehbar belegen kann, dass das Teilsystem sauber vom Rest (keine
gemeinsamen Ressourcen wie Speicher) getrennt ist, kann das Teilsystem getrennt klassifiziert
werden. Die Software-Klassifizierung und ggf. die Begründungen müssen in der
Risikomanagementakte dokumentiert werden.
Wenn das Risiko, das von einem Software-Fehler ausgeht, durch eine Hardware-
Risikobeherrschungsmaßnahme auf ein vertretbares Maß verringert wird (im Sinne der ISO
14971), so kann die Software-Sicherheitsklasse um eine Klasse reduziert werden.
2.6.2. Risikoanalyse für Software
Stand-alone-Software selbst, kann nicht direkt schädigen, kann jedoch Teil einer Ereigniskette
sein, die zu einer Gefährdungssituation führt. Die Umstände, bei denen Software zu einer
Gefährdungssituation beitragen kann, müssen in der Risikoanalyse untersucht werden. Dabei
müssen einige Software-spezifische Aspekte beachtet werden. So ist z.B. die Abschätzung von
Wahrscheinlichkeiten für Software ganz besonders schwierig und wird daher in der ISO 14971
gezielt adressiert.
2.6.2.2. Typische Gefährdungen
Lehrziele
M2-LE6.2-1-1 Verstehen, dass SW selbst keine Gefährdung darstellt, -- K2
sondern Gefährdungssituationen beeinflusst.
M2-LE6.2-1-1 Beispiele für negative Beeinflussungen kennen. -- K1
Software stellt selbst keine Gefährdung dar. Niemand verletzt sich durch den Kontakt mit ihr. Da
Software meistens ein integrierter Bestandteil eines ME-Gerätes ist, können Software-Fehler Teil
Gesamtlehrplan
einer Ursachenkette sein, die in einer Gefährdungssituation resultieren. Somit kann Software
bestehende Gefährdungssituationen verändern oder neue Gefährdungssituationen schaffen.
Stand-alone-Software kann nicht direkt schädigen. Eine Software zur Berechnung einer
Medikamentendosis kann dadurch zu einer Gefährdungssituation führen, dass ein Arzt einen
falsch berechneten Wert sieht, aber nicht erkennt, dass der Wert falsch ist und einen Patienten
unter Umständen falsch medikamentös behandelt.
Bei embedded Software stellt sich die Situation anders dar. Hier kann ein Fehler in der Software,
die zum Beispiel die Beatmung steuert, via Hardware unmittelbar zu einem Schaden führen.
2.6.2.3. Typische Fehler
Lehrziele
M2-LE6.2-2-1 Wissen, dass regelmäßig die gleichen Fehlermuster -- K1
auftreten.
M2-LE6.2-2-1 Typische Fehler benennen können. -- K2
M2-LE6.2-2-1 Wissen das es sich dabei um systematische Fehler -- K2
handelt und wie diese beherrschbar werden.
--
Bei Software sind regelmäßig die gleichen Ursachen von Gefährdungen zu finden:
 Die Software ist nicht gebrauchstauglich (Benutzerschnittstelle), überfordert den Benutzer
mit zu vielen oder missverständlichen Informationen oder Alarmen,
 Die Software stürzt ab und verzögert dadurch die Behandlung,
 Die Gebrauchsanweisung ist unvollständig, fehlerhaft, in einer für den Benutzer nicht
ausreichend verständlichen Sprache oder gar missverständlich dokumentiert,
 Die Software speichert Daten nicht (korrekt),
 Die Software arbeitet mit der Sensorik nicht richtig zusammen,
 Die Software verarbeitet Daten falsch,
 Die Software nutzt fehlerhafte (und/oder nicht ausreichend spezifizierte und geprüfte)
Fremdkomponenten,
 Die Software überträgt Daten falsch (z.B. zu einem anderen Gerät oder zu einer anderen
Komponente),
 Die Software arbeitet mit anderen Daten, als dem Benutzer angezeigt werden,
 Die Software bekommt keine ausreichenden Systemressourcen (CPU, Speicher) zur Verfügung
gestellt.
Solche Fehler sind systematischer Natur. Systematische Fehler lassen sich nur durch einen
beherrschten Entwicklungsprozess minimieren, wie er auch in der IEC 60601-1, IEC 62304 und IEC
62366 gefordert wird. Eine weitere Strategie besteht darin, die gleiche Funktion mit einer
anderen Technologie zu realisieren ggf. sogar von zwei verschiedenen Teams.
2.6.2.4. Wahrscheinlichkeiten und Software
Lehrziele
M2-LE6.2-3-1 Wissen, dass die Fehlerwahrscheinlichkeit bei -- K1
Software laut IEC 62304 generell bei 100% liegt.
M2-LE6.2-3-1 Wissen, dass für die Risikoanalyse von medizinischer -- K1
Software Experten des gesamten Einsatzumfeldes
benötigt werden.
Gesamtlehrplan
--
Bei Software ist es schwierig, Wahrscheinlichkeiten zu schätzen. Die ISO 14971 empfiehlt eines
der folgenden Verfahren:
 Verwendung relevanter Daten aus der Vorgeschichte (vergleichbare Produkte, eigenes
Produkt, bisher aufgetretene Fehler)
 Vorhersage von Wahrscheinlichkeiten unter Verwendung von analytischen oder
Simulationstechniken
 Beurteilung durch Experten
IEC 62304 gibt die Wahrscheinlichkeit, dass Software einen Fehler enthält, generell mit 100% an.
Man geht also davon aus, dass mögliche Fehler auf jeden Fall früher oder später auftreten
werden. Die Norm sagt damit aber nicht, dass ein Softwarefehler per se mit einer
Wahrscheinlichkeit von 100% zu einem Schaden führt. Im Fall von Stand-alone-Software besteht
die Möglichkeit, dass ein Fehler (Bsp. Falschberechnung) vom Bediener erkannt wird. Ein Fehler in
einer embedded Software würde mit einer höheren Wahrscheinlichkeit als bei Stand-alone-
Software zu einem Schaden führen. Es kommt dann auf die Applikation an. Der Ausfall einer
Beatmung würde innerhalb einer Minute zu einem Schaden führen, der Ausfall einer
Spritzenpumpe eventuell erst nach einem längeren Zeitraum.
Was bereits für das Medizinprodukt als Ganzes gesagt wurde, gilt auch für die darin enthaltene
Software: Die Risikoanalyse von medizinischer Software ist nicht nur Aufgabe der Entwickler,
sondern der Experten des gesamten Einsatzumfeldes. Allerdings ist es nicht sinnvoll, immer alle
Beteiligten mit einzubeziehen. Die SW-Entwickler schätzen am besten die Wahrscheinlichkeit,
dass ein SW-Fehler zu einem nach außen sichtbaren Ereignis führt, welches Ursache einer
Gefährdung sein könnte. Über die Wahrscheinlichkeiten in der Kette "Ursache -> Gefährdung ->
Gefährdungssituation -> Schaden" kann der SW-Entwickler hingegen oft nur spekulieren. Diese
Wahrscheinlichkeiten sollten vom Anwender (also den Medizinern bzw. dem medizinischen
Personal) geschätzt werden. Auch für die Abschätzung des Schweregrades eines möglichen
Schadens bedarf es medizinischen Sachverstandes.
Weitere Hinweise zu den Besonderheiten des Risikomanagements bei Software gibt auch die IEC-
TR 80002-1 - „Guidance on the application of ISO 14971 to medical device software“.
2.6.2.5. FTA und FMEA bei Software
Lehrziele
M2-LE6.2-4-1 Die Voraussetzung kennen, die für Software gegeben -- K1
sein müssen, um eine FTA bzw. eine FMEA
durchzuführen.
M2-LE6.2-4-1 Eine FMEA beispielhaft für SW-Systeme anwenden -- K3
können.
Zur Erinnerung: Die Fault Tree Analysis FTA ist ein Analyseverfahren, das von einer bekannten
Gefährdung ausgeht und die Ursachenkette so lange zurückverfolgt, bis sie auf beherrschbare
(elementare) Ereignisse (Ursachen) stößt. Im Gegenzug dazu ist die FMEA ein Analyseverfahren,
das von einer elementaren Ursache (Softwarefehler, Tätigkeit eines Anwenders) ausgehend eine
Ursachenkette bis zu einer möglichen Folge z.B. einer Gefährdung verfolgt.
Beide Analyseverfahren eignen sich für die Software-Risiskoanalyse, vorausgesetzt, dass die
Architektur der Software bekannt ist. Für die FTA wird empfohlen, die Ursachenkette nicht zu
weit zu treiben (z.B. bis auf Codezeilenebene). Meist genügt es, die groben Komponenten zu
identifizieren, die ursächlich zu einer Gefährdung beitragen. Nur die sicherheitskritischen
Komponenten müssten dann weiter untersucht werden.

Gesamtlehrplan
Die FMEA bietet sich für die Risikoanalyse ebenfalls an, da Software bekanntlich Auslöser einer
Ursachenkette sein kann. Auch für die Risikoanalyse von nicht selbst entwickelten Komponenten
(z.B. IEC 62304: SOUP - Software unbekannter Herkunft) bietet sich die FMEA an, ebenso immer
dann, wenn (Software-)Komponenten geändert oder ausgetauscht werden.
Wie jedes Verfahren hat die FMEA Stärken und Schwächen:
 Bei einer FMEA argumentiert man weitgehend monokausal, das heißt, man untersucht die
unmittelbare Folge eines Ereignisses, aber nicht die Kombinationen mehrerer Fehler.
 Die FMEA eignet sich besonders, um die Auswirkungen von Änderungen an einer
Komponente oder dem Einsatz einer Fremdkomponente (Software-Bibliothek) abzuschätzen.
 Die FMEA birgt die Gefahr, bei zu granularen Komponenten zu beginnen und sich dadurch zu
verzetteln. Die Ergebnisse sind Tabellen, die Hunderte von Zeilen umfassen, im schlimmsten
Fall aber den Blick auf das Ganze vermissen lassen.
In diesem Abschnitt ist eine Übung durchzuführen, in der die Schulungsteilnehmer eine einfache
FMEA für Software erstellen.
2.6.3. IEC 80002
Die IEC 80002 ergänzt die ISO 14971 und schließt eine Lücke in punkto Software-Sicherheit.
 Software-Sicherheit
2.6.3.3. IEC 80002
Lehrziele
M2-LE6.3-1-1 Wissen, dass die IEC 80002 eine ergänzende Norm zur -- K1
ISO 14971 mit dem Charakter eines Leitfadens ist.
M2-LE6.3-1-1 Verstehen, dass die IEC 80002 eine Lücke im Bereich -- K2
der Software-Sicherheit schließt.
M2-LE6.3-1-1 Wissen, dass es in der IEC 80002 für jeden -- K1
Prozessschritt in der ISO 14971 eine
softwarespezifische Entsprechung gibt.
M2-LE6.3-1-1 Wissen, dass die IEC 80002 für alle Bereiche der -- K1
Medizintechniksoftware Anwendungshinweise gibt,
die nicht bereits durch existierende Normen
abgedeckt sind.
ISO 14971 definiert einen Risikomanagementprozess für alle Arten von Medizinprodukten. Es gibt
keine Einschränkung auf medizinische elektrische Geräte oder Software. IEC 62304 ist rein auf
Software ausgerichtet, verweist aber für das Risikomanagement auf die ISO 14971. Wie jedoch
das Risikomanagement für Software genau aussehen soll, wird in keiner der beiden Normen
wirklich klar benannt.
Weil Software zunehmend mehr in medizinischen Produkten zum Einsatz kommt, wurde eine
Leitlinie entwickelt, die bei der Anwendung der ISO 14971 für die IEC 62304 Unterstützung bieten
soll, die IEC 80002-1.
Die Struktur der IEC 80002- 1 "Medical device software – Part 1: Guidance on the application of
ISO 14971 to medical device software" ist an die Struktur der ISO 14971 angelehnt. Für jeden
einzelnen Prozessschritt in der ISO 14971 gibt es eine Entsprechung in der IEC 80002-1. Darin wird
beschrieben, was im Fall der Software speziell zu beachten ist.
Die IEC 80002 ist adressiert an:
Gesamtlehrplan
 Risikomanager, die wissen müssen, wie Risikomanagement angewendet wird, wenn Software
Bestandteil des Medizinproduktes ist.
 Softwareentwickler, die verstehen müssen, wie die Anforderung des Risikomanagements
nach ISO 14971 im Softwareentwicklungsprozess umzusetzen sind.
Die IEC 80002 enthält Informationen über die Anwendbarkeit des Risikomanagements für alle
Bereiche der Medizintechniksoftware, inkl.
 Embedded Software Systeme
 Stand-alone Software Systeme
 Informationssysteme (z.B. KIS/RIS-Systeme)
 Assistenz- und Zubehörsysteme (z.B. Bestrahlungsplanungssysteme)
 Telemedizinsysteme
Die IEC 80002 ist nicht auf folgende Softwarebereiche oder -systeme anwendbar:
 Bereiche, die bereits durch existierende Standards abgedeckt sind, z.B. Alarme, Netzwerke
etc.,
 Produktions- oder QS-Software,
 Softwareentwicklungswerkzeuge.

Gesamtlehrplan
3. Curriculum SW-Engineering
3.1. Softwareentwicklungsprozesse
3.1.1. Regulatorische Anforderungen
Die Normen, die mit der Medizinprodukterichtlinie der EU harmonisiert sind, enthalten
Forderungen an den Entwicklungsprozess für Software. Folglich ist es notwendig, bei der
Gestaltung des Software-Entwicklungsprozesses die Erfüllung dieser Kriterien sicherzustellen und
die Prozesse zu dokumentieren, um ihre Konformität nachweisen zu können.
 Softwareentwicklungsprozess
 Sicherheitsklasse
 Softwareentwicklungsprozess
3.1.1.4. Regulatorische Anforderungen
Lehrziele
M3-LE1.1-1-1 Wissen, dass die IEC 62304, ISO 13485 und IEC 60601- K1 --
1 Abschnitt 14 ebenso wie die FDA eine Beschreibung
des (Software-)entwicklungsprozesses verlangen.
M3-LE1.1-1-1 Wissen, dass der Softwareentwicklungsprozess sich an -- K1
den harmonisierten Normen orientieren muss, um die
Konformitätsvermutung zu begründen.
M3-LE1.1-1-1 Wissen, dass der Softwareentwicklungsprozess für die K1 W
verschiedenen Sicherheitsklassen unterschiedlich
strengen Anforderungen genügen muss.
M3-LE1.1-1-1 Unterschiedliche Ausprägungen des -- K2
Softwareentwicklungsprozesses für die
unterschiedlichen Sicherheitsklassen kennen.
Die Norm IEC 62304 macht Vorgaben, die bei der Festlegung eines
Softwareentwicklungsprozesses beachtet werden müssen. Diese Norm verlangt vom Hersteller,
Maßnahmen zur Planung, Entwicklung, Dokumentation und Validierung bis hin zur Wartung
bereits in Verkehr gebrachter Software zu ergreifen. Die genauen Anforderungen sind abhängig
von der Sicherheitsklasse (A, B oder C) der zu entwickelnden Software.
Darüber hinaus stellt auch die Qualitätsmanagementnorm ISO 13485 Anforderungen an die
Planung, Durchführung und Dokumentation sämtlicher Verfahren, was den
Softwareentwicklungsprozess einschließt.
Auch die Norm IEC 60601-1 stellt in Kapitel 14 Anforderungen an den Lebenszyklus von Software
in Medizinprodukten.
Soll das Produkt in den USA zugelassen werden, muss der Softwareentwicklungsprozess zudem
konform mit den Vorgaben der FDA sein. Trotz Harmonisierungsbemühungen sind diese nicht
hundertprozentig identisch zu den erstgenannten Normen.
Gesamtlehrplan

Um die Konformität eines Software-Medizinprodukt in Europa nachzuweisen, ist neben der
Erfüllung der Anforderungen an ein QM-System nach ISO 13485 die Konformität des
Softwareentwicklungsprozesses mit allen relevanten harmonisierenden Normen entscheidend.
Der Entwicklungsprozess muss daher auch die Forderungen anderer Normen erfüllen, z.B. neben
der IEC 62304 auch die ISO 14971 (Risikomanagement) oder die IEC 62366 (Usability Engineering).
Diskussion ein Beispiel für unterschiedliche Ausprägungen des Softwareentwicklungsprozesses in
den Bereichen
 Softwarearchitektur und Softwaredesign
 Verifizierung, Validierung (Festlegung von Akzeptanzkriterien)
3.1.2. Vorgehensmodelle
Für die Entwicklung von Software haben sich im Laufe der Zeit unterschiedliche Paradigmen und
Vorgehensmodelle herausgebildet.
Auch wenn das V-Modell sich auf den ersten Blick am besten auf die IEC 62304 abbilden lässt,
existiert seitens der Norm für Medizinsoftware keine strikte Vorgabe für eines dieser Modelle.
Folglich können auch im Sinne eines effektiven Prozesses andere Einflussfaktoren wie
Unternehmenskultur und Vorkenntnisse der Mitarbeiter berücksichtigt werden.
Auch die FDA lässt für die Ausgestaltung des Entwicklungsprozesses viel Spielraum. Dennoch sind
nicht alle Vorgehensmodelle uneingeschränkt geeignet.
 Vorgehensmodell
 Wasserfallmodell
 V-Modell
 iterativ-inkrementelle Modelle
 agile Entwicklungsmodelle
 Vorgehensmodell
 Wasserfallmodell
 V-Modell
 iterativ-inkrementelle Modelle
 agile Entwicklungsmodelle
3.1.2.4. Wahl des Vorgehensmodells
Lehrziele
M3-LE1.2-1-1 Wissen, dass die IEC 62304 kein spezielles K1 W
Vorgehensmodell vorschreibt, so dass
Wasserfallmodell und V-Modell genauso wie iterativ-
inkrementelle und agile Modelle angewendet werden
können
M3-LE1.2-1-1 Vor- und Nachteile agiler Entwicklungsmethoden für -- K2
die Entwicklung von Software als Medizinprodukt
einschätzen und vereinbaren können.
Die IEC 62304 schreibt kein spezielles Vorgehensmodell vor. Wasserfallmodell, V-Modell, iterative
und auch agile Vorgehensmodelle lassen sich mit den Anforderungen dieser Norm vereinbaren.
Das Wasserfallmodell ist für einfache Entwicklungen sehr gut geeignet, bei denen der
Gesamtlehrplan
Projektverlauf völlig planbar abläuft. Das V-Modell stellt jeder konstruktiven Phase eine
entsprechende Testphase gegenüber, die bereits während der Konstruktionsphasen geplant wird.
Für Wasserfallmodell und V-Modell sollten die Anforderungen zu Beginn der Entwicklung
hinreichend detailliert erhoben werden können.
Iterativ-inkrementelle und auch agile Modelle dagegen fügen mehrere Iterationen hintereinander
und sehen vor, dass auch Anforderungen sich von Iteration zu Iteration ändern können.
Wiederholung FL
Die IEC 62304 definiert Anforderungen an Prozesse und Aufgaben, die in dem
Softwareentwicklungsprozess geeignet abgebildet werden müssen. Die Anforderungen
unterscheiden sich dabei in Abhängigkeit von der Sicherheitsklasse des zu entwickelnden
Softwaresystems.
Agile Frameworks wie Scrum und iterative Prozessmodelle wie RUP können durchaus mit den
Anforderungen der IEC 62304 in Übereinstimmung gebracht werden. Für die Ausarbeitung eines
konkreten Softwareentwicklungsmodells müssen jedoch die zusätzlichen Anforderungen der
Norm berücksichtigt werden.
Ein Problem ist häufig das Umgehen mit den vielen kurzen Iterationen oder Sprints. Hier kann
eventuell ein deutlich höherer Verifizierungsaufwand entstehen. Dieser Aufwand muss bei der
Planung der Iterationen berücksichtigt werden. Späte Änderungen können zusätzliche Aufwände
für Verifikation, Risikomanagement, Usability Engineering, Architektur, Design, Implementierung
Bei einem agilen oder iterativ-inkrementellen Ansatz werden häufig zu Beginn der Entwicklung
nur Systemanforderungen und Architektur dokumentiert. Das Detailed Design wird dann
inkrementell in jedem Sprint erstellt und ergänzt. Dabei ist darauf zu achten, dass das Detailed
Design verifiziert wird, bevor die Implementierung beginnt. Die IEC 62304 sieht keine Ad-hoc-
Design-Entscheidungen vor (siehe Anhang B 5.4).
3.1.3. Prozessbeschreibung
Die IEC 62304 verlangt ebenso wie die IEC 60601-1, dass die Prozesse, die für die Entwicklung des
Softwaresystems verwendet werden, als Teil der Entwicklungsplanung beschrieben oder
referenziert sind.
Die Normen legen auch fest, welche Prozessgebiete und welche Aspekte für die einzelnen
Prozessgebiete dokumentiert sein müssen. Meist werden vorgefertigte Standardprozesse
verwendet und ggf. an die Erfordernisse des Projektes angepasst.
 Prozess
 Prozessgebiete
 Prozess
 Prozessgebiete
3.1.3.4. Prozessgebiete festlegen
Lehrziele
M3-LE1.3-1-1 Wissen, dass die Prozesse vorab festgelegt werden K1 --
müssen.
M3-LE1.3-1-1 Wissen, welche Prozessgebiete auf jeden Fall K1 W
beschrieben werden müssen.
M3-LE1.3-1-1 Wissen, welche Prozessgebiete beschrieben werden K1 W
Gesamtlehrplan
müssen, wenn die Software ein eigenständiges

Medizinprodukt ist.
M3-LE1.3-1-1 Notwendige Maßnahmen für Pflege und -- K2
Rückverfolgbarkeit von Prozessbeschreibungen
kennen.
Die IEC 62304 fordert, dass Prozesse vor ihrer Durchführung festgelegt und beschrieben werden
müssen. Nach IEC 62304 müssen mindestens folgende Prozesse beschrieben werden:
 Softwareentwicklung
 Softwarewartung
 Softwarerisikomanagement
 Softwarekonfigurationsmanagement
 Softwareproblemlösung
Für jedes Medizinprodukt muss ebenfalls beschrieben sein:
 Produktrisikomanagement
 Systemtest und Validierung
 Dokumentenmanagement
Ist die Software Teil eines Medizinprodukts, so können diese Prozesse an übergeordneter Stelle
für das Gesamtprodukt beschrieben sein.
3.1.4. Zusammenspiel mit der Konformitätsbewertung und dem Audit
Audits müssen prüfen, ob die Prozessbeschreibungen die Anforderungen der harmonisierten
Normen erfüllen. Dies gilt auch für die Beschreibung des Software-Entwicklungsprozesses. Zudem
prüfen Audits an Hand der verfügbaren Dokumente und Aufzeichnungen, ob und wie der
Hersteller die Forderungen konkret umgesetzt hat. Dazu werden auch weitere Vorgaben des
Herstellern geprüft, die der Hersteller sich selbst gegeben hat und in Verfahrens- und
Arbeitsanweisungen dokumentiert hat.
 Konformitätsnachweis
 Konformitätsnachweis
3.1.4.4. Konformitätsnachweis
Lehrziele
M3-LE1.4-1-1 Wissen was der Konformitätsnachweis ist. K1 W
M3-LE1.4-1-1 Wissen, dass nicht die bloße Auflistung der -- K1
normativen Anforderungen, sondern deren Adaption,
Umsetzung und daraus resultierende Aufzeichnungen
für das Bestehen von Audits notwendig ist
M3-LE1.4-1-1 Wissen, dass bei Zertifizierungsaudits zur ISO 13485 -- K2
bereits ein IEC 62304-konformer Entwicklungsprozess
unter Anwendung des Risikomanagements nach ISO
14971 vorhanden sein muss, wenn das Unternehmen
medizinische Software entwickelt
Gesamtlehrplan
Der Konformitätsnachweis ist das Ergebnis der Konformitätsbewertung. Diese ist in der
internationalen Norm ISO/IEC 17000:2004 „Konformitätsbewertung - Begriffe und allgemeine
Grundlagen“ als die „Darlegung, dass festgelegte Anforderungen bezogen auf ein Produkt, einen
Prozess, ein System, eine Person oder eine Stelle erfüllt sind“ definiert.
Eine Auflistung der normativen Forderungen mit Referenzen auf deren Umsetzung, z.B. in
tabellarischer Form, kann die Umsetzung der normativen Vorgaben nachvollziehbar
dokumentieren.
Es ist aber nicht ausreichend nur die Anforderungen der Norm aufzulisten, sondern es muss von
den Auditoren anhand von Stichproben geprüft werden, ob die Anforderungen aus der Norm sich
in den eigenen Prozessbeschreibungen wiederspiegeln und dann auch im Arbeitsumfeld
abgebildet und angewendet werden.
Die ISO 13485 und IEC 62304 fordern, dass die Umsetzung von Prozessen und Projekten
ausführlich durch Aufzeichnungen dokumentiert wird.
Für ein Zertifizierungsaudit nach ISO 13485 müssen die Prozesse zur Dienstleistungserbringung
beschrieben und gegebenenfalls validiert sein.
Wird Software als Medizinprodukt oder als Teil eines Medizinprodukts entwickelt, ist ein
Softwareentwicklungsprozess, der die Anforderungen der IEC 62304 und IEC 60601-1 erfüllt
erforderlich. Der Softwareentwicklungsprozess und dessen Umsetzung sind somit Voraussetzung
für eine Zertifizierung und werden im Regelfall von den benannten Stellen geprüft.
3.2. Entwicklungsplanung
3.2.1. Entwicklungsplanung
Bei der Entwicklung medizinischer Software fordern alle relevanten Normen, dass die Entwicklung
geplant werden muss. Dazu muss zuerst ein Plan erstellt und regelmäßig aktualisiert werden.
Anschließend werden die geplanten Aktivitäten durchgeführt. Den Abschluss einer jeden Aktivität
bildet eine Überprüfung der erzielten Ergebnisse beispielsweise durch eine Verifizierungen oder
ein Review.
 Softwareentwicklungsplan
 Softwareentwicklungsplan
3.2.1.4. Entwicklungsplanung
Lehrziele
M3-LE2.1-1-1 Inhalte eines Softwareentwicklungsplanes kennen K1 --
M3-LE2.1-1-1 Unterschied zwischen Projektplan und K2 --
Softwareentwicklungsplan kennen
M3-LE2.1-1-1 Die Abhängigkeiten zwischen Entwicklungsprozess und -- K2
Sicherheitsklassifikation kennen bezogen auf
einzusetzende Werkzeuge und Methoden.
Der Softwareentwicklungsplan muss Folgendes festlegen:
 Den zu verwendeten Entwicklungsprozess
 Die zu liefernden Ergebnisse und Dokumente
Gesamtlehrplan
 Die Sicherstellung der Rückverfolgbarkeit von Anforderungen und Risikokontrollmaßnahmen

 Das Konfigurations- und Änderungsmanagement der Software
 Die Behandlung von Problemen während der Entwicklung
 Die Softwareintegration und deren Prüfung
 Die Verifizierung der Software
 Das Risikomanagement für die Software
 Die Dokumentation
Der Softwareentwicklungsplan ist damit eine Art Handbuch, das genau beschreibt, wie bei der
Entwicklung eines konkreten Produkts vorzugehen ist.
In einem Softwareentwicklungsplan muss der verwendete Entwicklungsprozess festgelegt
werden. Dabei ist es ausreichend, auf im Unternehmen etablierte und dokumentierte
Entwicklungsprozesse zu referenzieren, die projektunabhängig sind. Wenn Abweichungen vom
Standardprozess gemacht werden, dann sind diese im Softwareentwicklungsplan zu beschreiben.
Falls nicht auf einen Standard-Entwicklungsprozess zurückgegriffen werden kann, erfordert die
Erstellung eines Softwareentwicklungsplanes die Festlegung der im konkreten
Entwicklungsprojekt anzuwendenden Prozesse und Verfahren.
Der Projektplan ist der Plan, nach dem der Projektleiter den Ablauf des Entwicklungsgeschehens
steuert. Da sich wesentliche Punkte des Projektplanes, etwa die zu erstellenden Dokumente und
Artefakte, direkt aus dem Softwareentwicklungsplan ergeben, scheint es naheliegend zu sein,
beide Dokumente zusammenzufassen.
Es gibt jedoch auch Gründe, beide die Dokumente getrennt zu führen: Im
Softwareentwicklungsplan sind vor allem statische Inhalte enthalten und das Dokument sollte zu
Beginn der Entwicklung geschrieben und freigegeben werden. Der Projektplan hingegen ändert
sich im Verlauf des Projektes sehr oft.
Die Norm verlangt, dass bei Softwareeinheiten der Sicherheitsklasse C bereits vorab im Rahmen
der Softwareentwicklungsplanung festgelegt wird, welche Standards für die Entwicklung gelten,
welche Methoden eingesetzt und welche Werkzeuge verwendet werden. Außerdem müssen alle
Normen, die für die Entwicklung eines Projektes in der Medizintechnik anzuwenden sind,
festgelegt werden. Aus Sicht der Software sind immer die folgenden harmonisierten Normen zu
beachten:
 EN 14971
 EN 62304
 EN 60601-1 (nur für MDD)
 EN 61010-1 (nur für IVD)
 EN 62366
Diese können je nach Anwendungsgebiet um weitere produktspezifische Standards und Normen
erweitert werden.
Bei der Entwicklung von sicherheitskritischer Software sollen nur etablierte und bekannte
Methoden eingesetzt werden, um Fehler bei der Anwendung zu reduzieren. Auch bei der
Auswahl der Werkzeuge sollte auf erprobte Werkzeuge zurückgegriffen werden. Es ist weiterhin
zu berücksichtigen, dass Werkzeuge, die einen Einfluss auf die Produktkonformität haben oder für
die Verifikation benutzt werden, vor dem ersten Einsatz validiert werden müssen.
Beispiel zur Festlegung von Methoden:
Es kann in der Beschreibung des Entwicklungsprozesses festgelegt sein, dass
 Softwarearchitektur in UML Komponentendiagrammen modelliert wird,
 Software konform mit dem MISRA Standard entwickelt werden oder
Software-Einheiten mit Hilfe von Äquivalenzklassen-basierten Tests geprüft werden müssen

Gesamtlehrplan
3.3. Software-Anforderungsanalyse
3.3.1. Anforderungen ermitteln
Software-Anforderungen haben eine herausragende Bedeutung im Software Engineering: Sie
stellen die Grundlage der Software-Entwicklung dar, denn sie definieren, was die zu entwickelnde
Software leisten muss und welche Eigenschaften sie haben muss. Die Norm IEC 62304:2006
verwendet Software-Anforderungen synonym zu Software-System-Anforderungen.
Zum Umgang mit Software-Anforderungen gehören grundsätzlich vier Tätigkeiten:
 ermitteln,
 dokumentieren,
 prüfen (und abstimmen) und
 verwalten
von Anforderungen
 System-Anforderung
 Software-Anforderung
 Software-System-Anforderung
 Funktionale Anforderung
 Qualitätsanforderung
3.3.1.3. Anforderungen ermitteln
Lehrziele
M3-LE3.1-1-1 Den Unterschied zwischen Ableitung und Ermittlung K2 --
der Anforderungen verstehen.
M3-LE3.1-1-1 Den Inhalt der Software-Anforderungen gemäß der K1 --
Norm IEC 62304 kennen.
M3-LE3.1-1-1 Die besondere Bedeutung von Risikokontroll- K2 --
Maßnahmen in den Software-Anforderungen
verstehen.
Die Software-Anforderungen müssen festgelegt werden. Die Norm IEC 62304:2006 geht davon
aus, dass einige oder alle System-Anforderungen durch Software erfüllt werden sollen. Daher
wird im Deutschen vom Ableiten der Software-Anforderungen aus den Anforderungen an das
Gesamtsystem gesprochen.
Die deutsche Übersetzung der Norm IEC 62304:2006 ist leider ungenau: Im Original heißt es
„define“, also festlegen, definieren, bestimmen und nicht „ableiten“. Das Ermitteln der
Anforderungen ist damit in beiden Fällen nicht gemeint. Der gängige englische Begriff dafür ist
„Elicitation“. Da die Norm selbst aber anmerkt, dass das System ein reines Software-System sein
könne, so dass System-Anforderungen und Software-Anforderungen identisch sind, müssen die
Anforderungen evtl. auch ermittelt werden. Die Norm geht darauf aber nicht ein. Diverse
Ermittlungstechniken und deren Einsatzmöglichkeiten werden in [IREB-FL] vorgestellt.
Die von den System-Anforderungen abgeleiteten Software-Anforderungen detaillieren die
System-Anforderungen und sind diesen zugeordnet.
Gemäß der IEC 62304 beinhalten die SW-Anforderungen:
 Funktionale Anforderungen, d.h. Anforderungen an Abläufe und Verhalten
 Anforderungen an Ein- und Ausgabedaten, d.h. Formate, Wertebereiche, Standardwerte
Gesamtlehrplan
 Anforderungen an Schnittstellen zu anderen Systemelementen

 Anforderungen an SW-gesteuerte Alarme, Warnungen und Anwender-Meldungen
 Anforderungen an die Datensicherheit, d.h. Vertraulichkeit, Authentifizierung, Autorisierung,
Integrität
 Anforderungen an die Gebrauchstauglichkeit, die maßgeblich sind hinsichtlich menschlichem
Versagen und Ausbildung, z.B. sinnvolle Anordnung der Bedienelemente
 Anforderungen an Daten und Datenbanken, z.B. Form, Eignung, Funktion
 Anforderungen an die Installation und Abnahme der Medizinprodukte-SW
 Anforderungen an den Betrieb und die Wartung
 Anforderungen an die Benutzerdokumentation
 Anforderungen an die Wartung durch den Betreiber
 Regulatorische Anforderungen
 Risikokontrollmaßnahmen
Einige dieser Anforderungen sind zumindest missverständlich dokumentiert:
 „Anforderungen an Daten und Datenbanken“ bedeutet nicht, dass beispielsweise ein Schema
einer Datenbank zu beschreiben wäre, die Teil des Software-Systems ist. Das wäre Aufgabe
der Architektur.
 Regulatorische Grundlagen sollten nicht ungesehen übernommen werden. Beispielsweise
wäre eine Anforderung an den Datenschutz in konkrete Software-Anforderungen zu
überführen wie z.B. die Anforderung, dass die Software einen Benutzer nach x Minuten
Inaktivität wieder ausloggt und auf den Login-Screen zurückwirft.
Wenn Risikokontrollmaßnahmen für Hardware-Ausfälle und Software-Ausfälle in Software
umgesetzt werden sollen, dann sind diese Risikokontrollmaßnahmen als Software-Anforderungen
aufzunehmen. Diese Risikokontrollmaßnahmen können auch während der Entwicklung definiert
werden oder sich während der Entwicklung ändern.
3.3.2. Anforderungen dokumentieren
Anforderungen sollten möglichst eindeutig und unmissverständlich formuliert und dokumentiert
werden. Hierbei helfen Satzschablonen (Dokumentation in natürlicher Sprache) und Modelle.
 Satzschablone
3.3.2.3. Anforderungen dokumentieren
Lehrziele
M3-LE3.2-1-1 Die Bedeutung der Dokumentation von K2 --
Anforderungen verstehen.
M3-LE3.2-1-1 Die erneute Evaluation der Risikoanalyse verstehen. K2 --
M3-LE3.2-1-1 Die Aktualisierung vorhandener Anforderungen K2 --
verstehen.
M3-LE3.2-1-1 Die 2 wichtigsten Stilregeln zur Dokumentation nach K1 --
[IREB-FL] kennen.
Die Dokumentation von Anforderungen dient unter anderem auch als Kommunikationsmittel, da
viele Personen im Rahmen einer Entwicklung eingebunden sind, die die dokumentierten
Anforderungen benutzen (z.B. Kunde, Entwickler, Tester.) Die wesentlichen Gründe für die
Dokumentation von Anforderungen sind ([IREB-FL]):

Gesamtlehrplan
 Anforderungen sind die Grundlage für die Entwicklung, denn Projektplanung, Design,
Entwicklung, Test oder Wartung benötigen Anforderungen als Basis.
 Anforderungen sind rechtlich relevant, daher hilft die Dokumentation von Anforderungen bei
der Klärung rechtlicher Konflikte.
 Anforderungsdokumente sind oftmals komplex und umfangreich, so dass eine geeignete
Dokumentation hilft, sich in der Vielzahl der Anforderungen zurechtzufinden.
 Anforderungen sollten allen Beteiligten zugänglich sein, denn in großen und länger
dauernden Projekten können Mitarbeiterwechsel und Änderungen geschehen. Durch die
Dokumentation wird ein aktueller Stand der Anforderungen ermöglicht.
Nachdem die Software-Anforderungen festgelegt wurden, ist ein wichtiger Baustein für die
weitere Entwicklung abgeschlossen worden. Daher muss der Hersteller die Risikoanalyse
aktualisieren. Das gilt auch für alle existierenden Anforderungen, insbesondere auch der System-
Anforderungen.
Um Anforderungen möglichst eindeutig und unmissverständlich zu dokumentieren, gibt es zwei
einfache Stilregeln ([IREB-FL]):
 Kurze Sätze und Absätze
 Nur eine Anforderung pro Satz formulieren. Dies beinhaltet auch die Formulierung im Aktiv,
die Verwendung nur eines Verbs und die Vermeidung verschachtelter Sätze.
Noch besser ist es, die Anforderungen an eine Software als Spezifikation derer Schnittstellen zu
formulieren:
 Spezifikation der Benutzer-System-Schnittstelle (z.B. GUI)
 Spezifikation der System-System-Schnittstellen (Datenschnittstellen z.B. zu anderen
Systemen, Sensoren, Aktoren usw.)
 Spezifikation der Laufzeitumgebung (z.B. Hardware (CPU, RAM, Bildschirmgrößen und –
auflösungen), Betriebssystem, „Run-times“ wie die Java-Runtime oder die.NET-Runtime.
3.3.3. Anforderungen verifizieren
Wie alle anderen Artefakte im Software-Entwicklungsprozess, müssen Anforderungen verifiziert
werden, bevor weiter mit ihnen gearbeitet wird.
3.3.3.2. Anforderungen verifizieren
Lehrziele
M3-LE3.3-1-1 Die Forderungen der Norm IEC 62304 zur Verifizierung K1 --
von Software-Anforderungen kennen.
M3-LE3.3-1-1 Die Bedeutung der wesentlichen Qualitätskriterien K2 --
von Software-Anforderungen in Bezug zur Norm IEC
62304 verstehen.
Die Software-Anforderungen sollten anhand folgender Kriterien verifiziert werden:
 Vollständigkeit: Die System-Anforderungen sind vollständig umzusetzen, sofern sie relevant
für die Software sind. Dazu gehören auch die Anforderungen aus dem Risikomanagement-
Prozess, wenn Risikokontrollmaßnahmen in Software umzusetzen sind.
 Konsistenz: Die Software-Anforderungen dürfen sich nicht gegenseitig widersprechen.
 Eindeutigkeit: Die Software-Anforderungen müssen so formuliert sein, dass sie von jedem
Leser auf die gleiche Weise verstanden werden. Die Verwendung von Satzschablonen kann
helfen, dies zu erreichen.

Gesamtlehrplan
 Überprüfbarkeit: Es muss möglich sein, die Software-Anforderungen mit Testkriterien zu

ergänzen und entsprechende Tests durchzuführen, um zu testen, inwieweit die Testkriterien
erfüllt sind.
 Rückverfolgbarkeit: Jede Software-Anforderung muss eindeutig identifizierbar sein. Dies ist
die Grundlage für die Rückverfolgbarkeit. Des Weiteren muss geprüft werden, ob Software-
Anforderungen zu ihren Quellen (typischerweise System-Anforderungen oder Stakeholder-
Anforderungen bei standalone-Software) zurückverfolgt werden können.
Die erfolgte Verifizierung der Software-Anforderungen muss dokumentiert werden.
3.3.4. Anforderungen verwalten
Anforderungsmanagement ist keine einmalige Aufgabe. Anforderungen müssen im Verlauf des
gesamten Entwicklungsprozesses verwaltet und ggf. geändert werden.
3.3.4.2. Anforderungen verwalten
Lehrziele
M3-LE3.4-1-1 Verstehen, dass Anforderungsmanagement- -- K2
Werkzeuge die Erfüllung bestimmter Anforderungen
der Norm IEC 62304 erleichtern.
--
Software-Anforderungen werden ermittelt, dokumentiert und hinsichtlich bestimmter
Qualitätskriterien geprüft.
Die Verwaltung von Anforderungen ist eine weitere wichtige Tätigkeit im Umgang mit
Anforderungen. Zu den wichtigsten Aspekten dieser Tätigkeit zählen die Definition von
Anforderungsattributen, die Versionierung und die Rückverfolgbarkeit von Anforderungen.
Anforderungen können mittels Attributen identifiziert, detailliert, kategorisiert, gefiltert und bzgl.
ihrer Umsetzung analysiert werden. Die Attribute-ID und Version einer Anforderung tragen
beispielsweise zur eindeutigen Identifikation von Software-Anforderungen bei (5.2.6e). Da die
manuelle Pflege dieser Attribute aufwendig ist, sollte ein Anforderungsmanagement-Werkzeug
eingesetzt werden, das die IDs und Versionen automatisch vergibt.
Durch Traces kann der Zusammenhang zwischen Softwareanforderungen und
Systemanforderungen hergestellt und dokumentiert werden. Diese Traces manuell zu pflegen ist
sehr aufwändig und sollte daher durch ein Werkzeug unterstützt werden. Ein weiterer Vorteil
eines Anforderungsmanagement-Werkzeugs bzgl. Traces liegt in der Analyse bestimmter Aspekte,
die mittels Traces realisiert sind.
Gemäß IEC 62304 muss jede Anforderung implementiert werden und auch getestet werden.
Moderne Entwickler Tools ermöglichen eine end-to-end Tracebility von der Anforderung bis zum
Ergebnis einer Verifikationsmaßnahme. Auf diese Weise kann sichergestellt werden, dass alle
Anforderungen verifiziert wurden.
3.4. Softwarearchitektur
3.4.1. Softwarearchitektur beschreiben
Die Softwarearchitektur ist ein zentraler Bestandteil der Software-Entwicklung. Sie liefert den
Plan, an dem sich die mit dem detaillierten Design und der Implementierung befassten Entwickler
orientieren. Nur für die Sicherheitsklassen B und C ist eine Dokumentation der
Gesamtlehrplan
Softwarearchitektur nach IEC 62304 zwingend erforderlich. Die Softwarearchitektur umfasst

grundsätzliche Entscheidungen z.B. zum Einsatz von SOUP und beschreibt im Normalfall sowohl
statische und dynamische Aspekte. Sie gibt, basierend auf den Anforderungen, den Rahmen für
das spätere Softwaredesign vor und befreit den Softwareentwickler von der Notwendigkeit,
später spontan eigene Designentscheidungen treffen zu müssen.
 Softwarearchitektur
 Statische Sicht
 Dynamische Sicht
 Softwaresystem
 Softwarekomponente
 Softwareeinheit
 Komponentendiagramm
 Sequenzdiagramm
 Aktivitätsdiagramm
3.4.1.3. Statische Sicht
Lehrziele
M3-LE4.1-1-1 Die Aufteilung der Software in Softwarekomponenten K2 --
und -Einheiten erläutern können.
M3-LE4.1-1-1 Wissen, dass die IEC 62304 nur die Beschreibung der K1 --
statischen Sicht fordert.
Die statische Sicht beschreibt den Aufbau und die Zusammensetzung der Software. Hierfür wird
das Softwaresystem vollständig in Softwarekomponenten und schließlich Softwareeinheiten
zerlegt. Die Granularität von Softwareeinheiten ist nicht vorgegeben, orientiert sich jedoch
üblicherweise an den gebräuchlichen Einheiten der eingesetzten Programmiersprache, z.B. einer
Klasse im Fall von objektorientierten Sprachen.
Die IEC 62304 fordert die statische Sicht zu beschreiben, konkret
 Softwarekomponenten zu identifizieren (eigen entwickelte Komponenten, SOUP)
 Schnittstellen zwischen den Softwarekomponenten zu beschreiben/spezifizieren
 Schnittstellen zu externen Komponenten spezifizieren (falls dies nicht bereits im Rahmen der
Software-Anforderungen erfolgt ist)
3.4.1.4. Dynamische Sicht
Lehrziele
M3-LE4.1-2-1 Wissen, was die dynamische Sicht beschreibt. K1 --
Die dynamische Sichtweise beschreibt den Ablauf der Software zur Laufzeit. Beispielsweise
beschreibt die dynamische Sicht die Aufrufsequenz von Methoden auch über mehrere
Komponenten hinweg.
3.4.2. Sicherheitsklassen
Nach der Beschreibung der Softwarearchitektur wird den Softwarekomponenten die jeweilige
Sicherheitsklasse zugewiesen. Dies erfordert ein Zusammenwirken von Risikoanalyse und
Softwarearchitektur.
Gesamtlehrplan
 Reduktion durch Hardwaremaßnahmen
 Reduktion durch Softwaremaßnahmen
 Reduktion durch Hardwaremaßnahmen
 Reduktion durch Softwaremaßnahmen
3.4.2.4. Sicherheitsklassen festlegen
Lehrziele
M3-LE4.2-1-1 Die Sicherheitsklassen und ihre Bedeutung kennen. K1 W
M3-LE4.2-1-1 Wissen, warum die Bestandteile der Software K2 W
klassifiziert werden und welche Folgen die
Sicherheitsklassifizierung hat.
M3-LE4.2-1-1 Wissen, wie und von wem die Klassifizierung -- K2
vorgenommen wird.
Die IEC 62304 sieht drei Sicherheitsklassen vor:
 Klasse A (keine Verletzung oder Schädigung der Gesundheit möglich)
 Klasse B (keine schwere Verletzung möglich)
 Klasse C (Tod oder schwere Verletzung möglich)
Abhängig von der Sicherheitsklasse stellt unterschiedliche Anforderungen der IEC 62304 an die
Entwicklung und Dokumentation von Komponenten. Während z.B. die Dokumentation der
Softwarearchitektur für Komponenten der Sicherheitsklassen B und C vorgeschrieben ist, kann sie
gemäß den Anforderungen der IEC 62304 für Komponenten der Sicherheitsklasse A entfallen.
Die Sicherheitsklasse der Software-Komponenten leitet sich aus der Sicherheitsklasse des
zugehörigen Software-Systems ab. Die Sicherheitsklasse einer Software-Komponente entspricht
per default der Sicherheitsklasse des übergeordneten Software-System bzw. der übergeordneten
Software-Komponente.
Wenn der Hersteller begründen kann, dass eine Komponente nicht dazu beitragen kann
(aufgrund einer geeignete Segregation), dass ein Fehler in ihr zu einem Fehler in der
übergeordneten Komponente bzw. dem übergeordneten System führt, so kann der Hersteller die
Komponenten niedriger klassifizieren.
3.4.2.5. Sicherheitsklassen reduzieren
Lehrziele
M3-LE4.2-2-1 Wissen, wieso die Reduzierung der Sicherheitsklasse K2 W
sinnvoll ist
M3-LE4.2-2-1 Wissen, dass die Sicherheitsklasse nur durch K1 W
Hardwaremaßnahmen und nur um eine Stufe
reduziert werden kann
M3-LE4.2-2-1 Wissen, wie bei der Reduktion der Sicherheitsklasse -- K2
vorzugehen und wie sie zu dokumentieren ist.
M3-LE4.2-2-1 Wissen, dass die Unterteilung in Sicherheitsklassen -- K1
praktisch identisch mit dem FDA-Level of concern ist,
jedoch andere Folgen nach sich zieht.
Gesamtlehrplan

Eine hohe Sicherheitsklasse bedingt aufgrund der Vorgaben der IEC 62304 höhere Aufwände bei
der Planung, Dokumentation, Implementierung und Wartung. Diesen Aufwand reduzieren zu
wollen ist legitim. Gleichzeitig ist die Reduktion der Sicherheitsklasse Zeichen einer erfolgten
Risikominderung für den Patienten oder andere Beteiligte. Die Reduktion der Sicherheitsklasse
eines Software-Systems kann nach IEC 62304 nur durch Hardwaremaßnahmen, also durch
Maßnahmen außerhalb des Software-Systems, erfolgen. Durch reine Softwaremaßnahmen darf
die Sicherheitsklasse gemäß IEC 62304 nicht reduziert werden.
Wiederholungen der Inhalte zu den Punkten:
 Wissen, wieso die Reduzierung der Sicherheitsklasse sinnvoll sein kann
 Wissen, dass die Sicherheitsklasse nur durch Hardwaremaßnahmen und nur um eine Stufe
reduziert werden kann
Die Reduktion durch Hardwaremaßnahmen muss als Teil des Risikomanagements erfolgen. In der
Software-Architektur sollten diese Maßnahmen ebenfalls dokumentiert sein. Die
Sicherheitsklassen entsprechen etwa dem FDA Level of Concern (LoC) (minor, medium, major).
Allerdings hat das LoC nur Einfluss auf den Umfang der einzureichenden Dokumentation, nicht
auf den Umfang der zu erstellenden Dokumentation.
3.4.3. Risikobehandlung sicherstellen
Nach der Risikoanalyse und einer möglichen Reduktion der Sicherheitsklassen muss durch die
Softwarearchitektur sichergestellt werden, dass Fehler in einer Komponente nicht das Versagen
einer anderen Komponente zur Folge haben können, insbesondere wenn die Komponenten
unterschiedliche Sicherheitsklassen besitzen.
 Abschottung/Abgrenzung
 Abschottung/Abgrenzung
3.4.3.4. Risikobehandlung sicherstellen
Lehrziele
M3-LE4.3-1-1 Wissen, dass Sicherstellung der Abschottung von der K2 W
Norm für Klasse C-Komponenten gefordert wird und
ein wichtiges Ziel der Softwarearchitektur ist.
M3-LE4.3-1-1 Die Wirksamkeit verschiedener Ansätze zur -- K2
Abschottung innerhalb eines Softwaresystems
bewerten können.
IEC 62304 verlangt, dass Komponenten mit unterschiedlicher Sicherheitsklasse (insbes. bei Klasse
C-Komponenten) sich nicht gegenseitig beeinflussen. Maßnahmen zur Abgrenzung sind
notwendig, damit eine kritische Komponente nicht durch eine weniger kritische Komponente
beeinträchtigt wird.
Es existieren verschiedene Ansätze zur Abschottung von Komponenten. Grundlegend notwendig
ist es, Schnittstellen genau zu definieren und zu überwachen, dass nur die beschriebenen Wege
zur Interaktion genutzt werden.

Gesamtlehrplan
Darüber hinaus ist ein erster Schutz bereits die eigentlich übliche Abschottung und
Modularisierung moderner Sprachen, Verzicht auf global-statische Variablen, ein wohlüberlegtes
Exception Handling und eine saubere Trennung nach dem "Separation of Concerns"-Prinzip.
Ein weiterer Schritt ist die Aufgleisung in verschiedene Threads oder Prozesse. Es kann sogar
sinnvoll sein, ein System in mehrere Subsysteme, z.B. mehrere miteinander kommunizierende
Rechner, zu unterteilen. Watchdogs zur Überwachung und Redundanz können weitere
Maßnahmen sein.
Vollständige Sicherheit vor gegenseitigen Auswirkungen wird jedoch erst erlangt, wenn die
gemeinsame Nutzung von Ressourcen ausgeschlossen ist. Hierbei ist gegebenenfalls das
Betriebssystem das Problem, weshalb Hersteller von Klasse Software mit Klasse C-Komponenten
oft auf spezialisierte Betriebssysteme zurückgreifen.
Die Norm macht keine konkreten Vorgaben, wie die Abschottung auszusehen hat. Sie sollte
jedoch dem Stand der Technik entsprechen und der von der Software ausgehenden Gefährdung
angemessen sein.
3.4.4. Softwarearchitektur verifizieren
Die Verifikation der Softwarearchitektur bildet den Abschluss und soll prüfen, ob die Architektur
geeignet ist, um die Anforderungen an die Software umzusetzen.
 Verifikation der Softwarearchitektur
 Funktionale Anforderungen
 Performance-Anforderungen
 Verfügbarkeit
3.4.4.3. Softwarearchitektur verifizieren
Lehrziele
M3-LE4.4-1-1 Wissen, welche Fragestellungen bei der Verifizierung K1 --
der Softwarearchitektur im Mittelpunkt stehen.
Durch die Verifizierung der Softwarearchitektur wird sichergestellt
 dass diese die System- und Software-Requirements rückverfolgbar implementiert,
insbesondere die Anforderungen zur Risikobeherrschung, aber auch andere nichtfunktionale
Anforderungen wie Vorgaben zur Performance, Wartbarkeit und Verfügbarkeit
 dass SOUP-Einheiten korrekt behandelt werden
 dass die Beschreibung der Schnittstellen zwischen verschiedenen Komponenten und nach
außen vollständig ist
 dass, wenn Klasse C-Komponenten vorhanden sind, die getroffenen Maßnahmen zur
Abschottung ausreichend sind
Die Verifikation der Softwarearchitektur ist zu dokumentieren, beispielsweise durch ein formales
Review mit Checkliste, die die genannten Punkte enthält.
3.5. SW-Design
3.5.1. Softwaredesign beschreiben

Gesamtlehrplan
Das Softwaredesign verfeinert die in der Softwarearchitektur vorgenommene Aufteilung und

beinhaltet die Strukturierung der Softwarekomponenten in Softwareeinheiten. Dies müssen nicht
zwangsweise Klassen sein, auch Module oder Namensräume sind zur Unterteilung denkbar.
 Softwareeinheiten
 Softwareeinheiten
3.5.1.4. Softwaredesign beschreiben
Lehrziele
M3-LE5.1-1-1 Geeignete Darstellungsmittel für die Beschreibung der K1 --
statischen Sicht und zeitkritischer Vorgänge benennen
können.
M3-LE5.1-1-1 Wissen, wann eine Beschreibung des Software Designs K1 --
gefordert wird.
M3-LE5.1-1-1 Wissen, welche Anforderungen speziell für Klasse C- -- K1
Komponenten gelten.
Zur Planung der Softwareeinheiten aus statischer Sicht bieten sich z.B. UML-Klassendiagramme
an. Zeitkritische Vorgänge dagegen können z.B. mit Timing-Diagrammen dokumentiert werden.
Die Beschreibung des Software Designs wird für die Sicherheitsklassen B und C gefordert. Für
Klasse C gelten darüber hinaus noch weitergehende Anforderungen.
Klasse C-Komponenten müssen bis zu den Software-Einheiten zerlegt werden. Darüber hinaus ist
für diese Einheiten eine Dokumentation der Schnittstellen vorgeschrieben. Hinzu kommt die
Forderung, das Design zu verifizieren.
Die FDA listet in ihrem Dokument „General Principles of Software Validation“ weitere
Anforderungen an die Software-Architektur und das detaillierte Design.
3.5.2. Schnittstellen definieren
Die Schnittstellen zwischen Softwareeinheiten sind als Bestandteil der Software-Architektur und
des Softwaredesigns zu dokumentieren, um ein gemeinsames Verständnis von Syntax und
Semantik herzustellen. Dies ist besonders dann wichtig, wenn die Verantwortung für
verschiedene Softwareeinheiten in verschiedenen Händen liegt.
 Schnittstelle/Interface
 Schnittstelle/Interface
3.5.2.4. Schnittstellen definieren
Lehrziele
M3-LE5.2-1-1 Mögliche Dokumentationsformen für Schnittstellen K1 --
benennen können.
M3-LE5.2-1-1 Wissen, dass auf der Ebene Software-Design nur für -- K1
Klasse C-Komponenten die detaillierte
Gesamtlehrplan
Schnittstellenbeschreibung vorgeschrieben ist, auf

Architektur-Ebene jedoch für Klasse B und C.
Die Beschreibung der Schnittstellen kann in Prosa, als Diagramm (z.B. als UML-Modell) erfolgen.
Sich auf Kommentare bei der Implementierung der Schnittstelle zu begrenzen, entspricht nicht
dem Gedanken der IEC 62304, die keine Ad-hoc-Design-Entscheidungen vorsieht.
Für Softwareeinheiten der Sicherheitsklasse C ist es vorgeschrieben, dass die Schnittstellen auch
auf Design-Ebene detailliert (sowohl innerhalb zwischen den Bestandteilen der Softwareeinheit
als auch nach außen) beschrieben werden. Für Klasse B kann dies also aus regulatorischen
Gründen entfallen. Aus technischer Sicht ist dies dennoch häufig sinnvoll. Zu beachten ist, dass im
Gegensatz dazu die Schnittstellen auf Architektur-Ebene auch für Klasse B-Komponenten zu
beschreiben sind.
3.5.3. Design verifizieren
Am Ende der Softwaredesignphase steht die Verifizierung derselben.
3.5.3.2. Design verifizieren
Lehrziele
M3-LE5.3-1-1 Wissen, dass das Softwaredesign für Klasse C- K1 --
Komponenten nachvollziehbar verifiziert werden
muss.
M3-LE5.3-1-1 Wissen, dass dabei die widerspruchsfreie K1 --
Implementierung der Softwarearchitektur
nachgewiesen werden muss.
Das Softwaredesign muss bei Softwareeinheiten der Klasse C verifiziert werden. Dies ist zu
dokumentieren. Dabei muss nachgewiesen werden, dass das Softwaredesign die
Softwarearchitektur implementiert, also den ihren Vorgaben folgt, sowie dass das Softwaredesign
widerspruchsfrei zur Softwarearchitektur ist.
3.6. SW-Implementierung
3.6.1. Softwareeinheiten implementieren
Die Implementierung setzt die Vorgaben aus der Softwarearchitektur und dem Softwaredesign
um.
 Implementierung
 Implementierung
3.6.1.4. Softwareeinheiten implementieren
Lehrziele
M3-LE6.1-1-1 Wissen, dass die IEC 62304 keine Vorgaben zur K1 --
Technologie oder Methode der Implementierung
Gesamtlehrplan
beinhaltet.
Die IEC 62304 fordert: Der Hersteller muss jede Software-Einheit implementieren. Konkrete
Vorgaben oder Einschränkungen zu Technologien oder Methodik ergeben sich hieraus nicht.
3.6.2. Akzeptanzkriterien festlegen
Die Akzeptanzkriterien legen für Klasse C und B fest, welche Anforderungen an die
Softwareeinheiten geprüft werden müssen.
 Akzeptanzkriterium
 Akzeptanzkriterium
3.6.2.4. Akzeptanzkriterien festlegen
Lehrziele
M3-LE6.2-1-1 Begriff Akzeptanzkriterium kennen K1 --
M3-LE6.2-1-1 Wissen, dass für Klasse B und C Akzeptanzkriterien für K2 W
Softwareeinheiten festzulegen sind und deren
Einhaltung vor der Integration dieser
Softwareeinheiten sichergestellt werden muss.
M3-LE6.2-1-1 Wissen, dass von IEC 62304 für die Sicherheitsklasse C K1 W
explizite Akzeptanzkriterien gefordert werden.
M3-LE6.2-1-1 Wissen, dass zu harte Akzeptanzkriterien mögliche K1 --
Quellen hohen Aufwands sein können.
M3-LE6.2-1-1 Die von der IEC 62304 geforderten Akzeptanzkriterien -- K1
für Klasse C-Softwareeinheiten kennen.
Die Norm fordert, dass für alle Softwareeinheiten der Klasse B und C Akzeptanzkriterien
festgelegt werden. Die Einhaltung dieser Kriterien ist vor der Integration dieser Softwareeinheiten
abzusichern. D.h. es genügt nicht, nur auf Komponenten- oder Systemebene das Produkt zu
verifizieren. Die Norm IEC 62304 gibt selbst Beispiele für Akzeptanzkriterien:
 Der Code implementiert die Anforderungen
 Der Code implementiert die Risikomaßnahmen
 Einhaltung von Kodierrichtlinien
Für Softwareeinheiten der Klasse C fordert die IEC 62304 mindestens zu folgenden Punkten die
Formulierung von Akzeptanzkriterien, soweit dies angemessen ist:
 Richtige Abfolge von Ereignissen
 Daten- und Kontrollfluss
 Geplante Belegung von Ressourcen
 Behandlung von Fehlern (Fehlerdefinition, Isolierung und Wiederaufnahme)
 Initialisierung von Variablen
 Selbstdiagnose
 Speichermanagement und Speicherüberlauf
 Grenzwertbedingungen

Gesamtlehrplan
Abhängig von der gewählten Programmiersprache, dem Betriebssystem und der

Laufzeitumgebung können diese Akzeptanzkriterien anwendbar sein oder nicht.
3.6.3. Kodierrichtlinien einsetzen
Das Ziel von Coderichtlinien ist es, den gesamten Quellcode einheitlich zu gestalten. Dies ist
insbesondere bei verteilten Projekten sehr vorteilhaft. Die Norm fordert nicht explizit die
Verwendung von Kodierrichtlinien, im Anhang wird sie jedoch empfohlen.
 Kodierrichtlinien
 Namenskonventionen
 Metriken
 inhaltliche Richtlinien
 formale Richtlinien
 Kodierrichtlinien
 Namenskonventionen
 Metriken
 inhaltliche Richtlinien
 formale Richtlinien
3.6.3.4. Kodierrichtlinien einsetzen
Lehrziele
M3-LE6.3-1-1 Typische Bestandteile von Coderichtlinien kennen K2 W
M3-LE6.3-1-1 Wissen was bei der Verwendung von Kodierrichtlinien -- K1
als Akzeptanzkriterium zu beachten ist.
Kodierrichtlinien werden von der Norm IEC 62304 nicht explizit gefordert, aber im Anhang
empfohlen. Aus Sicht des Software Engineering sind sie jedoch sinnvoll, da sie die Einheitlichkeit
und Pflegbarkeit des Quellcodes erhöhen.
Coderichtlinien enthalten beispielsweise Vorgaben
 zu Art und Umfang der Kommentierung
 zur Formatierung des Quellcodes
 zu Namenskonventionen
 zu Code-Metriken
Oftmals müssen Kodierrichtlinien nicht neu festgelegt werden, sondern können aus vorhandenen
Standards entnommen und ggf. angepasst werden (z.B. die Misra-Richtlinien).
Das FDA-Dokument „General Principles of Software Validation“ empfiehlt den Einsatz von Code-
Guidelines.
Wiederholung FL
Wird die Einhaltung einer Codierrichtline als Akzeptanzkriterium festglegt, muss diese als
gelenktes Dokument vorliegen. Sollen nicht alle Inhalte der Kodierrichtlinie verbindlich sein, muss
in der Richtlinie der entsprechende Sachverhalt als Empfehlungen gekennzeichnet sein, da
ansonsten ein Verstoß im Audit als Abweichung bewertet wird.
Inhaltliche Richtlinien: z.B. die Initialisierung aller Variablen, Formale Richtlinien: z.B. Regeln zur
Groß und Kleinschreibung von Bezeichnern.
Gesamtlehrplan
Eine Beispiel-Codierrichtline von z.B. Microsoft sollte vorgestellt und diskutiert werden.
3.6.4. Softwareeinheiten verifizieren
Die Verifizierung der Softwareeinheiten weist nach, dass der Code die Akzeptanzkriterien erfüllt.
 Codereview
 Unit-Test
 Statische Codeanalyse
 Codereview
 Unit-Test
 Statische Codeanalyse
3.6.4.4. Softwareeinheiten verifizieren
Lehrziele
M3-LE6.4-1-1 Die Forderungen der ISO 62304 und der FDA zur K1 W
Verifizierung von Softwareeinheiten kennen.
M3-LE6.4-1-1 Die drei Hauptverfahren zur Prüfung der K1 W
Akzeptanzkriterien kennen und erläutern können.
M3-LE6.4-1-1 Bewerten können, welche Form der Prüfung für -- K2
welche Akzeptanzkriterien geeignet ist.
Die IEC 62304 fordert die Verifizierung aller Softwareeinheiten der Sicherheitsklassen B und C.
Das Vorgehen muss geplant und die Durchführung dokumentiert sein. Für die Planung der
Verifizierungsmaßnahmen bietet sich der Verifizierungsplan oder das Testkonzept an, wobei die
Verifizierung auf anderen Ebenen der Entwicklung nicht vernachlässigt werden darf.
Zusätzlich muss gemäß IEC 62304, wenn zur Verifizierung Testverfahren angewendet werden,
deren Korrektheit bewertet werden. Auch die FDA macht in ihrem Dokument „General Principles
of Software Validation“ im Kapitel „Testing by the Software Developer“ umfangreiche Vorgaben,
wie sie sich die Verifizierung von Softwareeinheiten vorstellt.
Je nach Art der Akzeptanzkriterien können verschiedene Verfahren genutzt und kombiniert
werden:
 Code Reviews: Autor und ein oder mehrere Reviewer prüfen den Code gegen definierte
Vorgaben und dokumentieren die Ergebnisse.
 Unit-Tests eignen sich zur Prüfung der Funktionalität und der Implementierung von
Schnittstellen.
 Statische Codeanalyse prüfen formale Kriterien insbesondere der Kodierrichtlinien, aber auch
inhaltliche Kriterien wie Initialisierung von Variablen.
Wo möglich, sollten automatisierte Verfahren (Unit-Tests, Statische Codeanalyse) verwendet
werden, da sie ohne großen Aufwand wiederholt werden können.
Wiederholung FL
Zu den unterschiedlichen Verfahren zur Verifikation der Softwaremodule soll jeweils ein Beispiel
oder Anwendungsfall aufgezeigt werden, der die Anwendung des jeweiligen Verfahrens
unterschiedlichen Akzeptanzkriterien zuordnet.

Gesamtlehrplan
3.7. Software-Integration
3.7.1. Software-Integration
Die Integration ist das Zusammenführen der einzelnen Bestandteile der Software zu einem
Softwaresystem. Das betrifft alle selbst entwickelten Teile und auch alle SOUP Komponenten, die
Bestandteil des Softwaresystems werden.
 Integrationsplan
 Integrationsplan
3.7.1.4. Integrationsplan und Integrationsverifikation/-test
Lehrziele
M3-LE7.1-1-1 Inhalte des Integrationsplan kennen K1 W
M3-LE7.1-1-1 Schritte für die Integrationsverifikation kennen K2 W
M3-LE7.1-1-1 Die unterschiedlichen Integrationsstrategien kennen -- K2
und die unterschiedlichen Ausprägungen bewerten
können.
Die Integration ist abhängig von Art und Umfang des Softwaresystems unterschiedlich
ausgeprägt. Kleine, eingebettete Software oder einzelne Programme werden meist mit Hilfe des
Build-Prozesses integriert. Das erfolgt oftmals direkt aus der Entwicklungsumgebung heraus. Bei
Softwaresystemen, die dagegen aus mehreren ausführbaren Einheiten bestehen oder von
mehreren Entwicklern parallel programmiert werden oder bei denen viel externe Software
benutzt wird, kann die Integration ein aufwändiger Prozess sein, der gut geplant werden muss.
Diese Planung erfolgt im Rahmen des Softwareentwicklungsplanes.
Die Integrationsverifikation bildet den Abschluss der Integrationsphase. Hier gilt es nachzuweisen,
dass die Softwareeinheiten korrekt in das Softwaresystem integriert wurden. Zunächst ist nur die
korrekte Integration gefordert, noch nicht die Prüfung, ob das integrierte Softwaresystem korrekt
arbeitet.
Beim Integrationstest muss für die Softwareeinheiten der Klasse B und C nachgewiesen werden,
dass die integrieren Einheiten das erwartete Verhalten zeigen. Zu den wichtigen Punkten zählen
hier:
 Funktionalität der Software
 Implementation und Anwendung der Risikominderungsmaßnahmen
 Zeitliches Verhalten der Software
 Verhalten gegenüber internen und externen Schnittstellen
 und testen unter ungewöhnlichen Bedingungen und vorhersehbarer Missbrauch.
Alle beim Integrationstest aufgefallene Fehler/Fehlverhalten müssen im Software-
Problemlösungsprozess verwaltet werden.
Wiederholung aller Inhalte FL.
Bei der Integration von Softwarebestandteilen können unterschiedliche Integrationsstrategien
angewendet werden:
 Bottom-up-Integration
Gesamtlehrplan
 Top-down-Integration
 Kontinuierliche Integration
Bottom-up-Integration
Die Integration beginnt auf der untersten Ebene der Aufrufhierarchie und arbeitet sich von dort
nach oben. Es werden zuerst die hardwarenahen Teile der Software integriert. Testtreiber
übernehmen die Rolle aufrufender Funktionen.
Top-down-Integration
Die Integration beginnt auf der obersten Ebene der Software, z.B. mit der Benutzeroberfläche.
Stellvertreterobjekte (Mock-Objekte, Stubs) simulieren tiefer liegende Softwareeinheiten. Schritt
für Schritt ersetzt man diese durch ihre endgültige Funktionalität.
Kontinuierliche Integration
Von kontinuierlicher Integration spricht man, wenn die Integration nicht in einem separaten
Prozessschritt erfolgt, sondern jede neue Softwareeinheit unmittelbar in das zu diesem Zeitpunkt
bestehende Softwaresystem integriert wird.
Die Auswahl der Integrationsstrategie ist eng mit dem grundlegenden Prozessmodell der
Software-Entwicklung verwandt. Vor allem bei iterativ-inkrementeller Entwicklung wird häufig
eine kontinuierliche Integration eingesetzt.
3.8. Softwaretest
3.8.1. Allgemeine Anforderungen aus IEC 62304
Abhängig von der Sicherheitsklasse fordert die IEC 62304 mehr oder weniger intensive Prüfungen
der zu entwickelnden Software, wobei besondere Anforderungen hinsichtlich der Testplanung
und -durchführung zu beachten sind.
 Integrationsprüfung
 Regressionsprüfung
 Softwaresystemprüfung
 Systemtest
 Testplan
 Testprotokoll
 Testspezifikation
 Akzeptanzkriterien
3.8.1.4. In IEC 62304 geforderte Prüfungen
Lehrziele
M3-LE8.1-1-1 Verstehen, welche Prüfungen abhängig von der K2 --
Sicherheitsklasse nach IEC 62304 durchzuführen sind.
M3-LE8.1-1-1 Ziel und Inhalte der SW-Integrationsprüfung kennen. -- K1
M3-LE8.1-1-1 Ziel und Inhalte der SW-Systemprüfung kennen. -- K1
Für die Sicherheitsklassen B und C fordert die IEC 62304 in verschiedenen Phasen der
Softwareentwicklung Verifikationen: Integrationsprüfung, Regressionsprüfung und
Softwaresystemprüfung. Außerdem wird die Verifizierung von Software-Einheiten gefordert, die
bereits im Abschnitt "Implementierung" beschrieben wurde.
Gesamtlehrplan
Für die Sicherheitsklasse A werden Verifikationen nicht verbindlich vorgeschrieben. Als A

klassifizierte Softwarekomponenten werden im Rahmen des (Gesamt-)Systemtests mit geprüft.
Stellt die Software ein eigenständiges Medizinprodukt dar, erfolgt die (Softwaresystem-)Prüfung
durch den dann notwendigen Systemtest
Für die Sicherheitsklassen B und C fordert die IEC 62304 eine Integrationsprüfung mit dem Ziel,
sicher zu stellen, dass SW-Komponenten wie beabsichtigt integriert wurden. Zusätzlich ist es
sinnvoll zu prüfen, ob diese auch bestimmungsgemäß funktionieren insbesondere, dass die
Schnittstellen wie vorgesehen zueinander passen. Beispielhaft kann geprüft werden:
 Funktionalität der SW (funktionale Anforderungen)
 Wirksamkeit der Risikokontrollmaßnahmen
 Performanz (z.B. hinsichtlich Timing- oder Durchsatzanforderungen) und andere nicht-
funktionale Qualitätskriterien
 Funktion der externen Schnittstellen
 Funktion der internen Schnittstellen im Zusammenspiel
 Systemverhalten bei abnormalen Bedingungen, z.B. bei vorhersehbarem Missbrauch,
entsprechend der Risikoanalyse
3.8.1.5. Testplanung
Lehrziele
M3-LE8.1-2-1 Die Hauptbestandteile der Testplanung und ihren K1 W
Fokus kennen.
M3-LE8.1-2-1 Wissen, was im Zusammenhang mit den Testfällen im -- K1
Detail spezifiziert werden muss.
M3-LE8.1-2-1 Wissen, dass Integrations- und Software- -- K1
Systemprüfung kombiniert werden dürfen.
Tests müssen vor der Durchführung geplant werden. Die beiden Hauptbestandteile dieser
Planung sind:
 Testspezifikation: definiert die durchzuführenden Testfälle und damit den Inhalt der
Prüfungen
 Testkonzept: definiert u.a. den Gültigkeitsbereich, die Vorgehensweise, die Ressourcen und
die Zeitplanung der beabsichtigten Tests mit allen Aktivitäten (ISTQB Glossar)
Je nach Projekt kann das Testkonzept Teil des Software-Entwicklungsplanes oder ein
eigenständiges Dokument sein. Im Testkonzept wird u.a. festgeschrieben, welche Hardware
verwendet wird, welche Ressourcen in welchem zeitlichen Rahmen eingesetzt werden und wie
z.B. mit Hardware- oder Software-Varianten verfahren wird. Das Testkonzept enthält somit
sowohl organisatorische Aspekte als auch eine inhaltliche Beschreibung, was wie zu testen ist.
Für die Testfälle müssen die Ein- und Ausgabedaten spezifiziert werden, sowie Akzeptanzkriterien
für die Bewertung des Systemverhaltens im Test. Jede Anforderung muss durch mindestens einen
Testfall abgedeckt sein, was durch Verweise nachvollziehbar dokumentiert wird.
Es ist zulässig, Integrations- und Software-Systemprüfung in einem einzigen Satz von Aktivitäten
zu kombinieren.
3.8.1.6. Testdurchführung
Lehrziele
M3-LE8.1-3-1 Die notwendige Dokumentation der Testdurchführung K1 --
Gesamtlehrplan
kennen.
M3-LE8.1-3-1 Wissen, wie mit den im Test gefundenen Fehlern -- K1
umzugehen ist.
Um das Ergebnis der durchgeführten Tests reproduzierbar zu machen, sollten bei der
Durchführung alle beeinflussenden Parameter protokolliert werden: Tester, verwendete
Hardware, verwendete Testspezifikation, verwendete Testdaten, ermitteltes Testergebnis,
aufgetretene Anomalien etc. Auch die eingesetzten Testwerkzeuge müssen dokumentiert
werden, sofern dies noch nicht bereits im Testkonzept geschehen ist.
Werden Abweichungen vom erwarteten Testergebnis oder andere Anomalien festgestellt,
müssen diese über den Software-Problemlösungsprozess behandelt werden (gilt für
Sicherheitsklasse B und C).
3.8.1.7. Test von Änderungen und Regressionstests
Lehrziele
M3-LE8.1-4-1 Wissen, welche Prüfungen nach Änderungen W --
durchgeführt werden müssen.
M3-LE8.1-4-1 Die normativen Anforderungen der IEC 62304 an die -- K2
Planung und Durchführung von Regressionstests im
medizinischen Umfeld von Best Practices abgrenzen
können.
Sobald eine bereits geprüfte Software geändert wird, ist nicht mehr sichergestellt, dass die
bisherigen Prüfungsergebnisse noch gültig sind. Zum einen wurde möglicherweise der
Funktionsumfang geändert (neue Funktionalität / geändertes Verhalten) und zum anderen kann
eine bestehende Funktionalität beeinträchtigt worden sein. Daher müssen prinzipiell folgende
Aktivitäten durchgeführt werden:
 Tests neuer Funktionalitäten durch neu erstellter Testfälle oder überarbeitete Testfälle;
 Regressionstest (Wiederholung bestehender Testfälle zur Prüfung, dass eine bereits
vorhandene Funktionalität nicht beeinträchtigt wurde)
Ggf. müssen auch die Prüfverfahren selbst modifiziert und anschließend erneut verifiziert werden
(z.B. erneutes Review der automatisierten Testskripten).
Für Software der Sicherheitsklasse B und C sind die soeben beschriebenen Prüfungen laut IEC
62304 verpflichtend, wenn die Software im Verlauf der SW-Systemprüfung verändert wird. Auch
bei der Integration von neuen oder geänderten SW-Komponenten sind Regressionstests
durchzuführen, die zeigen, dass die vorher integrierte Software von der aktuellen Integration
nicht beeinträchtigt ist. Bei Änderungen, die über den Änderungsprozess eingespeist werden,
schreibt die IEC 62304 für alle Sicherheitsklassen eine Verifizierung der Änderung inkl.
Wiederholung der durch die Änderung ungültig gewordenen Prüfungen vor. Auch die Lösung von
Softwareproblemen muss für alle Sicherheitsklassen verifiziert werden.
Die IEC 62304 fordert nach Änderungen eine erneute Freigabe. Vor der Freigabe sind alle
vorgelagerten Aufgaben wie Risikoanalyse und Wiederholung von Software-Prüfungen, im
Zweifelsfalle im kompletten Umfang (abhängig von der Sicherheitsklasse) durchzuführen. Es ist
jedoch gängige Praxis, die Bereiche abzugrenzen, die von den Änderungen betroffen sind und so
den Testaufwand nach Änderungen auf ein notwendiges und sinnvolles Maß zu beschränken. Die
Argumentation, warum bestimmte Testfälle weggelassen werden können, basiert in der Regel auf
der Software-Architektur, über die sich (idealerweise) einzelne Bereiche klar abgrenzen lassen.
Gesamtlehrplan
Damit die Entscheidungsgrundlage nachvollziehbar bleibt, muss der Hersteller des

Medizingerätes den Änderungsumfang detailliert beschreiben und alle betroffenen
Anforderungen, Testfälle und Risikokontrollmaßnahmen auflisten. Außerdem muss die
Risikoanalyse entweder erneut durchgeführt oder aktualisiert werden, da möglicherweise neue
Fehler, die zu Gefährdungen führen können, hinzugekommen sind oder bestehende
Risikokontrollmaßnahmen nicht mehr wirksam sind.
3.8.2. Verifizierung vs. Validierung
IEC 62304 fordert, vereinfacht gesagt, die Verifizierung fast aller Aktivitäten. Darunter fallen auch
die bislang beschriebenen Tests. Die Validierung ist nicht Bestandteil der IEC 62304, jedoch eine
wichtige Phase im Entwicklungsprozess von Medizingeräten (ISO 13485).
 Verifizierung
 Validierung
 Akzeptanztest
 Klinischer Test
 Usability-Test
3.8.2.4. Verifizierung
Lehrziele
M3-LE8.2-1-1 Kriterien zur Verifizierung des Software-Systemtest K1 --
gemäß EN 62304 kennen.
M3-LE8.2-1-1 Den Begriff Verifizierung erklären können. K1 --
Die IEC 62304 definiert die Verifizierung als Bereitstellung eines objektiven Nachweises, dass
festgelegte Anforderungen erfüllt worden sind. Mit diesen Anforderungen sind Anforderungen an
das Software-System bzw. Software-Komponenten ebenso gemeint wie Anforderungen an
Tätigkeiten und Dokumente wie das Software-Anforderungsdokument, die Software-Architektur,
die Risikokontrollmaßnahmen.
Die Anforderungen an die Verifizierungsaktivitäten hängen von der Sicherheitskasse ab. Für
Sicherheitsklasse B und C müssen auch die Prüfverfahren selbst verifiziert werden. Für den
Software-Systemtest beispielsweise sind folgende Kriterien zu prüfen:
 Angemessenheit der Tests
 Tracing zwischen Tests und Anforderungen
 Vollständigkeit der Prüfung aller Anforderungen
 Erfüllung der Pass-/Fail-Kriterien durch die Testergebnisse
3.8.2.5. Validierung
Lehrziele
M3-LE8.2-2-1 Den Unterschied zwischen Validierung und K2 --
Verifizierung verstehen.
M3-LE8.2-2-1 Übliche Testverfahren der Validierung kennen. -- K1
Die ISO 13485 definiert Validierung als Bereitstellung eines objektiven Nachweises, dass die
Anforderungen an eine spezielle Zweckbestimmung oder Anwendung erfüllt worden sind. Der
Gesamtlehrplan
Fokus liegt also nicht darauf, ob die Anforderungen wie spezifiziert umgesetzt wurden, sondern
ob das entwickelte Produkt seine Zweckbestimmung erfüllt. Dies umfasst das gesamte Produkt,
also auch die enthaltene Software.
Die im Modul "Usability" beschriebene Validierung der Gebrauchstauglichkeit ist Bestandteil der
Produktvalidierung.
In der Regel erfolgt die Validierung von stand-alone Software im geplanten (klinischen) Kontext,
häufig zusammen mit den spezifizierten Anwendern des Produkts. Software als Teil eines
Medizinprodukts wird nicht validiert, sehr wohl aber das Medizinprodukt in Gänze.
Im Rahmen der Validierung werden u.a. folgende Testverfahren eingesetzt:
 Usability-Test: Szenarien werden von Anwendern durchgespielt.
 Klinische Prüfung: Die klinische Prüfung hat zum Ziel nachzuweisen, dass der beabsichtigte
medizinische Nutzen erreicht wird und keine Risiken bestehen, die nicht bereits in der
Risikoanalyse als akzeptabel bewertet wurden. Bei stand-alone Software ist diese Prüfung
häufig nicht notwendig, weil der Nachweis im Rahmen der klinischen Bewertung anhand von
Literaturdaten erfolgen kann oder weil eine Bewertung anhand von Performance-Daten
ausreicht. Eine klinische Prüfung wäre beispielsweise für einen neuen Algorithmus zur
Bildverarbeitung (z.B. Rauschreduktion, automatische Detektion von „Regions of Interest“)
notwendig. Die klinische Prüfung setzt voraus, dass alle grundlegenden Anforderungen erfüllt
sind.
3.9. Software-Freigabe
3.9.1. Software-Freigabe
Bei der Entscheidung zur Freigabe einer Software müssen einige Regeln beachtet werden. Die
Freigabe bezieht sich hier immer nur auf die Software, da für eine Marktfreigabe eines
Medizinproduktes zahlreiche weitere Schritte notwendig sind.
 Freigabe
 Archivierung
 Freigabe
 Archivierung
3.9.1.4. Software-Freigabe
Lehrziele
M3-LE9.1-1-1 Die Voraussetzungen für eine Freigabe kennen K1 W
M3-LE9.1-1-1 Die Archivierungsdauer für Software kennen -- K1
M3-LE9.1-1-1 Wissen welche Themen für die Produktion von -- K1
freigegebener Software beachtet werden müssen.
Zur Freigabe der Software müssen die folgenden Aufgaben erfüllt sein:
 Entwicklung abgeschlossen, inklusive Verifizierung, Systemtest für Komponenten der Klasse B
und C, Dokumentation und Bewertung der verbleibenden Fehler für Komponenten der Klasse
B und C
 Archivierung der Software, inklusive der Protokollierung des Erstellungsprozesses
Gesamtlehrplan
 Es muss sichergestellt werden kann, dass der Entwicklungsstand zu einem definierten

Freigabezeitpunkt wiederhergestellt werden kann.
Wiederholen der Inhalte aus FL.
Folgende Artefakte müssen bei der Softwarefreigabe archiviert werden:
 Software-Produkt
 Konfigurationselemente
 Dokumentation
Die Dauer der Archivierung entspricht entweder der Dauer der Lebenszeit des Geräts, wie sie vom
Hersteller definiert wurde oder sie ist durch relevante regulatorische Anforderungen festgelegt.
Nach der Softwarefreigabe muss der Hersteller sicherstellen, das zur Auslieferung und zur
Vervielfältigung Verfahren zur Anwendung kommen, die folgenden Punkte berücksichtigen:
 Vervielfältigung der Software
 Kennzeichnung der Medien
 Verpackung
 Schutzmaßnahmen, z.B. gegen Verfälschung oder Vertauschen
 Lagerung
 Auslieferung
3.10. Softwarekonfigurationsmanagement
3.10.1. Konfigurationselemente
Das Konfigurationsmanagement betrifft alle Konfigurationselemente eines Produkts.
 Konfigurationselement
 Konfigurationselement
3.10.1.4. Konfigurationselemente
Lehrziele
M3-LE10.1-1-1 Die verschiedenen Konfigurationselemente kennen, K1 W
die über das Konfigurationsmanagement kontrolliert
werden müssen.
Nicht nur der Quellcode der Software muss über das Konfigurationsmanagement kontrolliert
werden, sondern alle Artefakte, die im Entwicklungsprozess entstehen. Das schließt – in nicht
vollständiger Aufzählung - technische Spezifikationen, Programmbibliotheken, Testskripte und -
werkzeuge, Konfigurationsdateien und Handbücher ein. Es ist sinnvoll, tatsächlich jede
verwendete Datei und jedes Dokument dem Konfigurationsmanagement zu unterstellen.
Wiederholung der Inhalte des FL zur Auffrischung.
3.10.2. Notwendigkeit des Konfigurationsmanagements

Gesamtlehrplan
Das Konfigurationsmanagement soll gewährleisten, dass zu jedem Zeitpunkt im Lebenszyklus des

Produkts erkennbar ist, aus welchen Bestandteilen in welchen Versionen es sich zusammensetzt.
 Konfigurationsmanagement
 Konfigurationsmanagement
3.10.2.4. Notwendigkeit des Konfigurationsmanagements
Lehrziele
M3-LE10.2-1-1 Verstehen, wann und warum Konfigurationselemente K2 --
kontrolliert werden müssen.
M3-LE10.2-1-1 Die Normen benennen können, in denen -- K1
Konfigurationsmanagement explizit gefordert ist.
Ein geregeltes Konfigurationsmanagement ist schon aus Projektsicht notwendig, um zu
kennzeichnen, aus welchen Elementen sich ein Produkt zusammensetzt und diesen Stand auch
später noch einmal einsehen zu können. Das Konfigurationsmanagement ist ein übergreifender
Prozess der in allen Phasen des Produktlebenszyklus anzuwenden ist. Wichtige Teilaspekte sind
das Versionsmanagement und das Änderungsmanagement.
Das Konfigurationsmanagement wird von der IEC 62304 gefordert. Die Norm zum
Qualitätsmanagementsystem ISO 13485 schlägt das Konfigurationsmanagement vor, um die
Identifizierbarkeit und Rückverfolgbarkeit zu gewährleisten.
3.10.3. Konfigurationselemente identifizieren
IEC 62304 fordert ebenso wie die IEC 60601-1 ein vom Hersteller definiertes Schema zur
eindeutigen Identifikation der Konfigurationselemente.
 Identifikationsschema
 Baseline
 Identifikationsschema
 Baseline
3.10.3.4. Konfigurationselemente identifizieren
Lehrziele
M3-LE10.3-1-1 Ein typischen Schema zur Identifizierung von K1 --
Konfigurationselementen kennen
M3-LE10.3-1-1 Sinn und Zweck einer Baseline kennen. K1 --
M3-LE10.3-1-1 Verstehen, welche Attribute sich für die eindeutige -- K2
Identifizierung von Konfigurationselementen eignen.
Der Hersteller muss ein Identifikationsschema für die Konfigurationselemente festlegen. Dieses
Schema definiert, wie die Konfigurationselemente identifiziert werden. Typische Attribute, nach

Gesamtlehrplan
denen eine Identifizierung erfolgen kann sind beispielsweise Pfadnamen bzw. Dokumentnamen,
Versionsangabe, Änderungsdatum. Die genaue Festlegung hängt von den eingesetzten Verfahren
und Werkzeugen, sowie von den zu verwaltenden Elementen ab.
Ein wichtiger Bestandteil des Identifikationsschemas ist die Version des Konfigurationselementes,
welche nach vorab festgelegten Regeln bei jeder Änderung angepasst wird. Zu bestimmten
Zeitpunkten im Projektverlauf (z.B. vor der Integration der SW-Komponenten und den Projekt-
Meilensteinen) sollten außerdem sogenannte Baselines (Basislinien) gezogen werden. Eine
Baseline ist eine Referenzkonfiguration, die einen bestimmten, stabilen Stand der
Konfigurationselemente zu einem definierten Zeitpunkt zusammenfasst, auf den später Bezug
genommen werden kann.
Das Identifikationsschema für die Konfigurationselemente muss auch andere Softwareprodukte
oder -einheiten wie z.B. SOUP und Dokumentation enthalten. Es muss möglich sein, alle
Konfigurationselemente einschließlich deren Version zu identifizieren, aus denen eine bestimmte
Systemkonfiguration besteht. Attribute auf Dateiebene sind in der Regel keine verlässlichen
Identifkationsattribute. Beispielsweise kann sich das Datum einer Datei ändern, wenn sie als
Anhang eine E-Mail verschickt und von dort aus gespeichert wird. Für SOUP gelten besondere
Dokumentationsvorschriften, die im Modul "Software of Unknown Provenance" behandelt
werden.
3.10.4. Werkzeuge für das Konfigurationsmanagement
Werkzeuge erleichtern die Handhabung des Konfigurationsmanagements.
3.10.4.2. Werkzeuge für das Konfigurationsmanagement
Lehrziele
M3-LE10.4-1-1 Werkzeuge des Konfigurationsmanagements und -- K1
deren Einsatzbereiche kennen.
Um bei häufigen Änderungen am Quellcode nicht den Überblick zu verlieren, bietet sich der
Einsatz von Werkzeugen zur Versionsverwaltung an. Durch diese Werkzeuge können mehrere
Versionen einer Datei verwaltet werden. Auch ist es möglich gleichzeitige Änderungen durch
mehrere Entwickler zu verwalten und bei Bedarf die unterschiedlichen Entwicklungslinien wieder
zusammenführen. Viele Werkzeuge bieten darüber hinaus die Möglichkeit, Versionen zu
kennzeichnen (z.B. die Zugehörigkeit zu einer bestimmten Systemversion) und unterstützen damit
neben der Versionsverwaltung auch das Konfigurationsmanagement. Meist sind diese Werkzeuge
gut in die Softwareentwicklungswerkzeuge integriert. Es bietet sich an, auch Dokumente und
deren Versionen hiermit zu verwalten, wenn kein eigenes Dokumentenmanagementsystem
verwendet wird. Die Verwendung eines Werkzeugs ist nicht verpflichtend, in der Praxis aber
unumgänglich.
3.10.5. Konfigurationsmanagementplan
Konfigurationsmanagement muss geplant sein.
 Konfigurationsmanagementplan
 Konfigurationsmanagementplan

Gesamtlehrplan
3.10.5.4. Konfigurationsmanagementplan
Lehrziele
M3-LE10.5-1-1 Die Inhalte eines Konfigurationsmanagementplans K1 --
kennen.
Aufgrund der vielfältigen und komplexen Anforderungen an das Konfigurationsmanagement ist es
sinnvoll, die relevanten Festlegungen und Prozesse in einem eigenen Dokument festzuschreiben.
Hier wird niedergelegt, welche Konfigurationselemente wie identifiziert werden, welche
Werkzeuge eingesetzt werden, Konventionen um Versionen zu benennen und alle anderen
Festlegungen die mit dem Konfigurationsmanagement zusammenhängen. Der
Konfigurationsmanagementplan ist Teil des Softwareentwicklungsplans.
--
3.10.6. Änderungsmanagement
Das Änderungsmanagement soll gewährleisten, dass alle Konfigurationselemente eines Produkts
nur kontrollierten Änderungen unterworfen werden, sowie dass die erfolgten Änderungen
dokumentiert und später noch nachvollziehbar sind.
3.10.6.2. Änderungsmanagement
Lehrziele
M3-LE10.6-1-1 Die Notwendigkeit des Änderungsmanagements K2 K2
verstehen.
M3-LE10.6-1-1 Die grundsätzlichen Anforderungen aus IEC 62304 an -- --
das Änderungsmanagement kennen
M3-LE10.6-1-1 Die grundsätzlichen Anforderungen aus IEC 62304 an -- K3
das Änderungsmanagement umsetzen können.
Im gesamten Softwarelebenszyklus können die in einem Produkt eingesetzten
Konfigurationselemente Änderungen unterworfen sein. Dies können z.B. Fehlerkorrekturen, neue
Funktionalitäten und Erweiterungen sein. Damit Änderungen nicht unkontrolliert erfolgen und
später noch nachvollziehbar sind, fordert die IEC 62304 eine geregelte Änderungskontrolle für
alle Sicherheitsklassen. So können die Risiken, die mit der Änderung einhergehen, minimiert
werden. Außerdem ist es wichtig, nachvollziehen zu können, wann welche Information (z.B.
Anforderungsversion) zu Grunde gelegt wurde. Sollte eine Rückrufaktion nötig sein, kann
zurückverfolgt werden, wann und an wen die fehlerhafte Komponente ausgeliefert wurde.
Die IEC 62304 fordert, dass
 Änderungen zuvor durch eine Änderungsanforderung genehmigt werden müssen bevor sie
durchgeführt werden und
 Änderungen anschließend entsprechend der Spezifikation in der Änderungsanforderung
durchgeführt (implementiert) werden. Dabei muss beachtet werden, dass auch alle
notwendigen Aktivitäten durchgeführt werden, auf die die Änderung Auswirkungen haben
kann. Das können beispielweise Integrationstätigkeiten sein, aber auch eine eventuell
notwendig gewordene Neubewertung der Softwaresicherheitsklassifizierung.

Gesamtlehrplan
 Änderungen verifiziert werden müssen. Dies schließt nicht nur die Verifikationen für die
direkt geänderten Konfigurationselemente ein, sondern auch die mittelbar von der Änderung
betroffenen Elemente.
 Änderungen rückverfolgbar sein müssen. Das bedeutet, dass der Zusammenhang zwischen
Änderungsanforderung, Genehmigung und ggf. Problembericht nachvollziehbar dokumentiert
werden muss. Sinnvollerweise schließt dies alle Aktivitäten, die mit der Änderung in
Zusammenhang stehen ein (z.B. Verifikationsbericht, betroffene Anforderungen, etc.).
Diese Forderungen gelten für alle Sicherheitsklassen.
In diesem Abschnitt ist eine Übung durchzuführen, in der die Schulungsteilnehmer die
Dokumentation eines Änderungsantrags auf Korrektheit im Sinne der IEC 62304 prüfen.
3.11. Software-Wartung
3.11.1. Planung der Software-Wartung
Der Prozess der Software-Wartung muss in einem Wartungsplan festgelegt werden. Dieser
Wartungsplan muss vorliegen, bevor eine Software freigegeben wird, da die Wartungsprozesse
ab dem Zeitpunkt der Freigabe anlaufen.
 Rückmeldung
 Problem
 Änderung
 Nachrüstung
3.11.1.3. Planungsinhalte
Lehrziele
M3-LE11.1-1-1 Quellen für Rückmeldungen -- K2
M3-LE11.1-1-1 Kriterien für die Entscheidung, ob eine Rückmeldung -- K2
ein Problem ist
M3-LE11.1-1-1 Einbindung des Risikomanagement-Prozesses -- K2
M3-LE11.1-1-1 Überwachung von SOUP-Komponenten -- K2
Die IEC 62304 fordert in Analogie zur IEC 60601-1 einen Wartungsprozess. Die IEC 60601-1 spricht
von Änderungen: „Wenn irgendein Teil oder der gesamte Entwurf das Ergebnis von Änderungen
eines früheren Entwurfs ist, gilt dieser Abschnitt so, als handele es sich um einen neuen Entwurf,
oder die weitere Gültigkeit irgendeiner früheren Entwurfsdokumentation muss mittels eines
dokumentierten Verfahrens für Änderungen/Modifikationen bewertet werden.“
Entsprechend muss der Wartungsplan festlegen (analog dem Entwicklungsplan), wie die
Anforderungen an die Änderungen umgesetzt werden und dabei auf Aspekte eingehen wie den
Prozess, Methoden und Werkzeuge.
Bei den zu definierenden Verfahren geht es um den Empfang (Hotline, Anwendungsberater, etc.)
und die Dokumentation dieser Rückmeldungen, aber auch um Kriterien, ab wann eine
Rückmeldung als Problem betrachtet und eine Korrektur bereitgestellt werden muss. Beispiele für
diese Kriterien können sein:
 Auswirkungen auf die Sicherheit von Patienten und Anwendern
 Anzahl der betroffenen Anwender
 Anzahl der betroffenen Produkte
 Geschäftsrisiken
Gesamtlehrplan
Bei der Entscheidung, ob eine Rückmeldung als Problem angesehen wird, ist es wichtig, den
Risikomanagement-Prozess mit heran zu ziehen.
Besondere Bedeutung bei der Überwachung kommt der SOUP zu. SOUP Software hat einen
Lebenszyklus, der unabhängig von der Software des Medizinproduktes abläuft. Beispielsweise
veröffentlichen die Hersteller der SOUP Fehlerberichte, stellen korrigierte Versionen der SOUP
bereit oder erweitern den Funktionsumfang. Im Wartungsplan muss festgelegt werden, wie damit
umgegangen wird, wann also beispielsweise eine korrigierte Version einer SOUP zu einer
Wartungsversion des Medizinproduktes führen soll.
Hinsichtlich des Prozesses für die Software-Wartung sind die folgenden Sachverhalte zu
berücksichtigen.
 Der Hersteller kann einen anderen Prozess als den ursprünglichen Software-
Entwicklungsprozess verwenden, um schnelle Änderungen in Reaktion auf dringende
Probleme zu implementieren. Allerdings muss auch dieser Prozess den Anforderungen der EN
62304 genügen.
 In Reaktion auf Software-Problemberichte, die sich auf ein freigegebenes Produkt beziehen,
adressiert der Hersteller nicht nur das Problem, sondern er genügt auch lokalen Vorschriften
(üblicherweise dadurch, dass er ein proaktives Überwachungsschema betreibt für die
Sammlung von Problem-Daten aus dem Feld und für die Kommunikation mit Anwendern und
zuständigen Behörden über das Problem).
3.11.2. Analyse von Problemen und Änderungen
Korrekturen in bereits freigegebener Software stellen immer ein Risiko dar. Bei jeder Änderung
besteht die Gefahr, dass neue Probleme auftauchen. Daher dürfen Änderungen in freigegebener
Software nur nach sorgsamer Abwägung vorgenommen werden. Der erste Schritt dazu besteht
darin, das zu behebende Problem genau zu Verstehen und die Auswirkungen der geplanten
Änderungen zu analysieren.
Rückmeldungen über ein Fehlverhalten des freigegebenen Software-Systems müssen analysiert
und auf ihren Schweregrad hin untersucht werden. Auswirkungen auf die Sicherheit von
Patienten, Anwendern und Dritten müssen bestimmt werden. Besonders wichtig ist es
festzustellen, ob durch das vorliegende Problem Risiko-Kontrollmaßnahmen negativ beeinflusst
werden.
Treten aufgrund des Problems Risiken für die Patienten auf, dann müssen die Anwender und
gegebenenfalls die zuständigen Behörden informiert werden.
Es muss geklärt werden, welche Produkte von dem gemeldeten Problem betroffen sind. Oftmals
wird die gleiche oder ähnliche Software in einer Reihe von Produkten eines Herstellers eingesetzt.
Wird ein Problem in einem Modell gemeldet, so ist unbedingt zu überprüfen, ob dieses Problem
auch in anderen Modellen vorhanden ist, und dort ebenfalls korrigiert werden muss.
Sobald entschieden wurde, dass ein Problem behoben werden soll, wird der Problemlösungs-
Prozess für Software verwendet, um die Änderungen zu implementieren.
 Problembericht
 Änderungsanforderung
 zuständige Behörden
 Problembericht
 zuständige Behörden
3.11.2.4. Dokumentation und Evaluation von Rückmeldungen
Gesamtlehrplan
Lehrziele
M3-LE11.2-1-1 Überwachung und Dokumentation von K1 W
Rückmeldungen
M3-LE11.2-1-1 Prüfung der Rückmeldungen auf Sicherheitsaspekte K1 K2
M3-LE11.2-1-1 Verwendung des Problemlösungsprozesses K1 K2
M3-LE11.2-1-1 Erstellung und Genehmigung von K1 K2
Änderungsanforderungen
M3-LE11.2-1-1 Information von Anwender und zuständigen Behörden K1 K2
Jeder Hersteller muss sicherstellen, dass Rückmeldungen entgegengenommen werden. Diese
Rückmeldungen können sowohl von Anwendern als auch von Mitarbeitern des Herstellers selbst
stammen. In der Regel wird ein Hersteller verschiedene Wege vorsehen, auf denen
Rückmeldungen mitgeteilt werden können. Beispiele dafür sind Hotlines, E-Mail-Adressen oder
auch spezielle Anwenderbefragungen.
Jede Rückmeldung, die sich auf ein freigegebenes Produkt bezieht, muss dokumentiert werden,
unabhängig davon, ob es sich um ein tatsächliches Problem handelt. Erst danach wird überprüft,
ob die Rückmeldung tatsächlich auf ein Problem in einer freigegebenen Software zurückzuführen
ist.
Bei der Überprüfung der Rückmeldungen ist es vor allem wichtig zu prüfen, ob ein Problem
zugrunde liegt, dass einen Einfluss auf die Sicherheit des Medizinproduktes hat. Beispielsweise
könnte eine Risiko-Kontrollmaßnahme nicht korrekt funktionieren oder es liegt ein neues, zuvor
nicht betrachtetes Risiko vor. Die Dringlichkeit einer Korrekturmaßnahme hängt dabei natürlich
sehr stark vom Sicherheitsaspekt ab.
Sofern der Rückmeldung tatsächlich ein Problem zugrunde liegt, wird ein Problembericht erstellt
(oder zumindest die dokumentierte Rückmeldung als tatsächliches Problem kenntlich gemacht)
und mit Hilfe des Problemlösungsprozesses gelöst. Das Ergebnis des Problemlösungsprozesses ist
eine Lösung für das zugrundeliegende Softwareproblem. Der Wartungsprozess greift danach
wieder ein und stellt sicher, dass dem Anwender eine Software-Version zukommt, die die Lösung
für das Problem enthält.
Dazu wird eine Änderungsanforderung erstellt und geprüft. Eine Änderung eines freigegebenen
Software-Produktes ist nur auf der Grundlage einer genehmigten Änderungsanforderung zulässig.
Wiederholung FL
Sobald die geänderte Software freigegeben wurde, müssen die Anwender und, je nach Land,
zuständige Behörden über die Probleme und deren Lösung informiert werden.
3.11.3. Implementierung von Änderungen
Die Änderungen, die aufgrund eines Problems notwendig werden, können entweder mit Hilfe des
Entwicklungsprozesses für die ursprüngliche Software-Entwicklung durchgeführt werden, oder
mit Hilfe einer speziell angepassten Vorgehensweise. In beiden Fällen müssen natürlich die
Anforderungen des Risikomanagements berücksichtigt werden.
 Erneute Freigabe
 Erneute Freigabe
 Änderungs-Bausatz
Gesamtlehrplan
3.11.3.4. Prozess für die Implementierung von Änderungen

Lehrziele
M3-LE11.3-1-1 Prozess für die Implementierung von Änderungen K1 K1
Für die Implementierung von Änderungen muss ein zuvor festgelegter Prozess verwendet
werden. Dies kann der gleiche Prozess sein, der auch für die ursprüngliche Software-Entwicklung
eingesetzt wurde. Der Hersteller kann jedoch auch einen speziellen Prozess für die
Implementierung von Änderungen im Zuge des Wartungsprozesses vorsehen. Dieser wird in der
Regel weniger umfangreich ausfallen und schneller auszuführen sein.
In beiden Fällen muss aber sichergestellt sein, dass das Risikomanagement von Software-
Änderungen, wie es im Software-Risikomanagementprozess gefordert ist, korrekt ausgeführt
wird. Vor allem ist darauf zu achten, dass alle Risiko-Kontrollmaßnahmen weiterhin korrekt
funktionieren, und dass geprüft wurde, ob die Software-Sicherheitsklassifizierung durch die
Änderung angepasst werden muss.
Selbstverständlich muss die Lösung eines Softwareproblems auch nachweislich getestet worden
sein. Der Test der Lösung muss dokumentiert werden.
3.11.3.5. Erneute Freigabe
Lehrziele
M3-LE11.3-2-1 Erneute Freigabe der Software nach einer Änderung K1 K2
M3-LE11.3-2-1 Arten der Auslieferung geänderter Software -- K2
Nach dem Abschluss der Implementierung muss die geänderte Software erneut freigegeben
werden. Dabei sind die Aktivitäten und Prüfungen auszuführen, die auch schon bei der
erstmaligen Freigabe gefordert waren:
 Entwicklung abgeschlossen, inklusive Verifizierung, Systemtest für Komponenten der Klasse B
und C, Dokumentation und Bewertung der verbleibenden Fehler für Komponenten der Klasse
B und C
 Archivierung der Software, inklusive der Protokollierung des Erstellungsprozesses
 Es muss sichergestellt werden, dass der Entwicklungsstand zu einem definierten
Freigabezeitpunkt wiederhergestellt werden kann.
Die geänderte Software muss dem Anwender in einer Form zur Verfügung gestellt werden, die es
erlaubt, die geänderte Software in Betrieb zu nehmen. Dazu sind verschiedene Ansätze denkbar:
 Die Software kann als komplettes Software-System zur Verfügung gestellt werden
 Die Software kann als Änderungs-Bausatz verfügbar gemacht werden
In beiden Fällen müssen alle erforderlichen Werkzeuge und Dokumentationen, die für die
erfolgreiche Inbetriebnahme notwendig sind, bereitgestellt werden.
3.12. Software-Problemlösung
3.12.1. Problemlösung für Software
Der Problemlösungsprozess für Software kommt immer dann zum Einsatz, wenn ein Problem in
der Software festgestellt wurde und behoben werden muss. Das kann sowohl während der
ursprünglichen Entwicklung der Software der Fall sein, als auch nach der Freigabe.
Gesamtlehrplan
Ziel des Prozesses ist es sicherzustellen, dass die Probleme angemessen dokumentiert, untersucht
und zeitgerecht beseitigt werden.
 Problem
 Problembericht
 Klassifikation
 Kritikalität
 Beteiligte Stelle
 Trend
 Problem
 Problembericht
 Klassifikation
 Kritikalität
 Beteiligte Stelle
 Trend
3.12.1.4. Erstellen von Problemberichten
Lehrziele
M3-LE12.1-1-1 Notwendigkeit von Problemberichten K1 K2
M3-LE12.1-1-1 Klassifikation von Problemberichten K1 K2
Für jedes erkannte Problem ist ein Problembericht zu erstellen. Dies gilt auch schon vor der
ersten Freigabe einer Software. So wird sichergestellt, dass erkannte Probleme tatsächlich und
adäquat behandelt werden.
Jeder Problembericht muss klassifiziert werden. Für die Klassifikation können folgende Kriterien
herangezogen werden:
 Typ: Korrekturmaßnahme, Vorbeugende Änderung, Anpassung etc.
 Umfang: Betroffene Produkte, betroffenes Zubehör
 Aufwand: notwendige Ressourcen für die Korrektur, Korrekturaufwand etc.
 Kritikalität: Auswirkung auf die Leistungsfähigkeit, Auswirkung auf die Sicherheit etc.
Typischerweise wird einem Problembericht eine Priorität in Abhängigkeit von dieser Klassifikation
zugewiesen.
3.12.1.5. Untersuchung des Problems
Lehrziele
M3-LE12.1-2-1 Relevanz von Änderungen für die Sicherheit -- K2
M3-LE12.1-2-1 Notwendigkeit von Änderungsanforderungen -- K2
Jeder Problembericht muss untersucht werden, um zu versuchen die Ursache für das Problem zu
identifizieren. Dabei ist es wichtig nicht nur die Symptome des Problems zu beseitigen
(workaround), sondern der Ursache auf den Grund zu gehen (root-cause analysis). Nur so ist
ausgeschlossen, dass die Ursache in der Software verbleibt und andere als die gemeldeten
Probleme verursacht.
Gesamtlehrplan
Für jeden Problembericht muss ermittelt werden, ob das Problem oder die Ursache
Auswirkungen auf die Sicherheit hat. Dies ist offensichtlich immer da gegeben, wo das Problem
dazu führt, dass eine Risiko-Kontrollmaßnahme versagt. Aber ein Problem kann auch auf neue
Quellen von Risiken hindeuten.
Wenn die Ursache des Problems gefunden ist und beseitigt werden kann, dann wird eine
Änderungsanforderung gestellt, der alle Aktionen umfasst, die für die Korrektur notwendig ist.
Wenn keine Korrektur erfolgen kann oder soll, dann ist die Begründung für diesen Sachverhalt
ebenfalls zu dokumentieren.
3.12.1.6. Unterrichtung beteiligter Stellen
Lehrziele
M3-LE12.1-3-1 Notwendigkeit der Unterrichtung beteiligter Stellen -- K2
verstehen
Je nach Art des untersuchten Problems müssen eventuell nationale Aufsichtsbehörden oder
andere beteiligte Stellen informiert werden. Dies ist vor allem dann zu tun, wenn das Problem
Auswirkungen auf die Sicherheit hat.
In Deutschland muss beispielsweise das BfArM über Vorfälle mit Medizinprodukten und über
Korrekturen von erheblichen Problemen in einem Medizinprodukt informiert werden.
3.12.1.7. Analyse von Problemen hinsichtlich Trends
Lehrziele
M3-LE12.1-4-1 Notwendigkeit der Analyse von Problemen hinsichtlich -- K2
Trends
Oftmals äußern sich Fehler in Software mit einer ganzen Reihe von Fehlverhalten. Es ist nicht
immer einfach und eindeutig, von einem Fehlverhalten auf die genaue Ursache zu schließen. Die
Ursache ist dabei nicht nur in der Software zu suchen. Vielmehr sollen die Hersteller
tieferliegende Ursachen identifizieren wie beispielsweise ein ungeeigneter Entwicklungsprozess,
ungeeignete Verfahren und Technologien, mangelnde Konformität mit den eigenen Vorgaben
oder unzureichende Ausbildung.
Um diese tiefergehenden Ursachen entdecken zu können, müssen die Hersteller die
Problemberichte auf Trends hin untersuchen.
3.13. Rückverfolgbarkeit im Software-Entwicklungsprozess

3.13.1. Grundlagen
Die Rückverfolgbarkeit (engl. traceability) von Anforderungen ist eine wichtige Voraussetzung, um
sicherzustellen, dass alle Anforderungen implementiert und getestet werden.
 Rückverfolgbarkeit
 Horizontale Rückverfolgbarkeit
 Vertikale Rückverfolgbarkeit
3.13.1.3. Grundlagen der Rückverfolgbarkeit
Lehrziele
Gesamtlehrplan
M3-LE13.1-1-1 Die Forderungen der Normen IEC 62304 und ISO -- K1

13485 im Bezug auf die Rückverfolgbarkeit kennen.
M3-LE13.1-1-1 Die besondere Bedeutung der Rückverfolgbarkeit von -- K2
Risikokontrollmaßnahmen verstehen.
Das Thema "Rückverfolgbarkeit" hat zwei Aspekte. ISO 13485 fordert dokumentierte Verfahren
für die Rückverfolgbarkeit von Produkten. Der Schwerpunkt liegt also auf der Verfolgung der
produzierten Medizingeräte. Es geht u.a. darum, gezielt Rückrufaktionen zu ermöglichen. Die
Rückverfolgbarkeit im Sinne der ISO 13485 wurde bereits im Modul "Konfigurationsmanagement"
behandelt. IEC 62304 legt den Schwerpunkt auf die Rückverfolgbarkeit in der Entwicklung und
fordert vom Medizinprodukte-Hersteller ein Verfahren, welches die Verfolgbarkeit (engl.:
"traceability") zwischen Systemanforderungen, Software-Anforderungen, Software-Systemtests
und Risikokontrollmaßnahmen (sofern sie in der Software umgesetzt sind) sicherstellt. Dieses
Verfahren muss im Software-Entwicklungsplan festgelegt werden.
Mit der Rückverfolgbarkeit zwischen Software-Anforderungen und System-Anforderungen wird
sichergestellt, dass alle Anforderungen implementiert wurden. Sie ist für alle Sicherheitsklassen
verpflichtend. Für Sicherheitsklasse B und C (ab Amendment I für alle Sicherheitsklassen) fordert
die EN 62304 ferner die Rückverfolgbarkeit von Software-Systemtests zu den dazugehörigen
Software-Anforderungen. Damit wird sichergestellt, dass alle Anforderungen geprüft wurden. Für
Risikokontrollmaßnahmen, die in der Software umgesetzt werden, gehen die Forderungen der EN
62304 sogar noch weiter. Hier muss eine lückenlose Kette zwischen der Gefährdungssituation,
der beteiligten Software-Einheit, der spezifischen Ursache (Fehlverhalten der Software-Einheit),
der definierten Risikokontrollmaßnahme und schließlich zur Verifizierung dieser Maßnahme (in
der Regel ein oder mehrere Testfälle) hergestellt werden (Sicherheitsklasse B und C).
Risikokontrollmaßnahmen werden im Sinne des Tracing wie Anforderungen behandelt, jedoch
besonders gekennzeichnet.
3.13.2. Tracing durchführen
Um die Nachvollziehbarkeit zu gewährleisten, müssen Mechanismen aufgesetzt werden, die ein
Tracing erlauben.
 Trace-Matrix
3.13.2.3. Tracing durchführen
Lehrziele
M3-LE13.2-1-1 Zweck und Aufbau einer Trace-Matrix verstehen. -- W
M3-LE13.2-1-1 Eine Trace-Matrix erstellen können. -- K3
M3-LE13.2-1-1 Wissen, wie Tracing mit zeitgemäßen Werkzeugen -- K1
durchgeführt werden kann.
Bevor eine Entwicklungsphase abgeschlossen wird, wird durch das sogenannte Tracing oder
besser die Trace-Analyse nachgewiesen, dass alle Anforderungen realisiert bzw. getestet wurden.
Das Tracing kann auf verschiedenste Weisen durchgeführt werden. Zunächst ist es möglich,
sogenannte Trace-Matrizen aufzustellen, die manuell gepflegt werden. Es handelt sich dabei um
eine Matrix, bei der in den Zeilen die Anforderungen aufgetragen werden, in den Spalten die
untergeordneten Anforderungen oder Verifikationsaktivitäten. Über einen Eintrag im
Matrizenfeld wird dann der Zusammenhang zwischen den beiden Anforderungen bzw. zwischen
Anforderung und Verifikationsaktivitäten dokumentiert. Allerdings ist ein solches manuelle
Gesamtlehrplan
Vorgehen sehr fehleranfällig. Die Matrizen werden sehr schnell sehr groß und unübersichtlich und
nach umfangreichen Änderungen sind sie kaum mehr zu überblicken. Hier können Werkzeuge
Abhilfe schaffen.
Werkzeuge helfen, das Tracing aktuell zu halten. Viele Softwareentwicklungswerkzeuge - speziell
Werkzeuge zum Anforderungsmanagement und Testmanagement - bieten entsprechende
Funktionen zur Unterstützung der Tracebility an. Nahezu alle Werkzeuge zum
Anforderungsmanagement unterstützen zumindest das vertikale Tracing. Bei Änderungen von
Anforderungen können diese Systeme automatisch über die betroffenen Traces alle verbundenen
Anforderungen oder Testfälle ermitteln. Auch die meisten Testmanagementwerkzeuge verfügen
über Funktionen, um die Zuordnung zwischen Testfällen und Anforderungen verwalten und
aktuell halten zu können. Im Idealfall sind Anforderungsmanagement und Testmanagement in
einem Werkzeug integriert und erlauben so die Durchführung des Tracing ohne Systembruch.
3.13.3. Rückverfolgbarkeit anderer Artefakte im Software-Entwicklungsprozess
Neben Anforderungen und Risikokontrollmaßnahmen müssen auch andere Artefakte im
Software-Entwicklungsprozess rückverfolgbar sein.
3.13.3.2. Rückverfolgbarkeit anderer Artefakte im Software-Entwicklungsprozess
Lehrziele
M3-LE13.3-1-1 Die regulatorischen Anforderungen an die K1 --
Rückverfolgbarkeit von Änderungsanforderungen und
Problemberichte kennen.
Neben Anforderungen, Risikokontrollmaßnahmen und Testfällen gibt es weitere Artefakte, für die
deren "Werdegang" im Software-Entwicklungsprozess rückverfolgbar und damit nachvollziehbar
sein muss. Auf die in der ISO 13485 geforderte Rückverfolgbarkeit in der Produktion wurde
bereits im ersten Abschnitt eingegangen. Darüber hinaus müssen auch Korrektur- und
Vorbeugemaßnahmen in der Produktion verfolgt werden.
IEC 62304 fordert vom Hersteller, dass dieser Mittel bereitstellt, um für
 jede Änderungsanforderung,
 jeden relevanten Problembericht und
 jede Genehmigung einer Änderungsanforderung
einen sogenannten "Audit-Pfad" zu erstellen.
Wenn die Zusammenhänge zwischen diesen Einheiten, den Anforderungen und Testfällen leicht
zu verfolgen sind, können die Auswirkungen von Änderungen direkt benannt werden. Außerdem
lässt sich die Vollständigkeit (z.B. des Regressionstests) einfacher nachweisen.
3.13.4. Forderungen der FDA
Auch die FDA sieht in der Rückverfolgbarkeit von Artefakten eine zentrale Anforderung an den
Software-Entwicklungsprozess.
3.13.4.2. Forderungen der FDA
Lehrziele
M3-LE13.4-1-1 Die Richtlinien der FDA kennen, in denen die -- --
Rückverfolgung von Anforderungen gefordert wird.
M3-LE13.4-1-1 Die Anforderungen der FDA zur Rückverfolgung von -- K2
Gesamtlehrplan
Anforderungen verstehen.
Die FDA fordert in ihrer Richtlinie "General Principles of Software Validation; Final Guidance for
Industry and FDA Staff", dass das Rückverfolgen von Anforderungen und
Risikokontrollmaßnahmen an verschiedenen Stellen im Software- Entwicklungsprozess
durchgeführt wird. Ähnlich wie bei der IEC 62304 werden hier Systemanforderungen und
Risikokontrollmaßnahmen hinsichtlich der Rückverfolgbarkeit gleichgesetzt.
Im Einzelnen wird gefordert, dass in den jeweiligen Entwicklungsphasen die folgende
Rückverfolgbarkeit in beiden Richtungen gegeben ist:
 Anforderungsanalyse: Systemanforderungen (bzw. Risikokontrollmaßnahmen) zu Software-
Anforderungen
 Design: Software-Anforderungen zu Design-Spezifikation
 Codierung: Design-Spezifikation zu Quellcode; Quellcode zu Testfällen (Unittest)
 Test: Design-Spezifikation zu Unit-Test; Software-Anforderungen zu Funktions- /
Integrationstest; Systemanforderungen zu Systemtestfällen
3.14. Software of Unknown Provenance (SOUP)

3.14.1. Definition und Beispiele für SOUP
Software für Medizinprodukte wird selten komplett neu entwickelt. Für viele Problemstellungen
können existierende Funktionsbibliotheken eingesetzt werden, und im Medizinprodukt
eingesetzte Firmware oder gar Betriebssysteme können nicht jedes Mal individuell entwickelt
werden.
 Software of Unknown Provenance (SOUP)
 Off-the-Shelf-Software
3.14.1.3. Definition und Beispiele für SOUP
Lehrziele
M3-LE14.1-1-1 Die Definition von SOUP kennen. K1 --
M3-LE14.1-1-1 Sich an Beispiele für SOUP erinnern. K1 W
M3-LE14.1-1-1 Die Vor- und Nachteile des Einsatzes von SOUP und K2 W
die damit verbundenen Gefahren verstehen.
M3-LE14.1-1-1 Sich an allgemeine Überlegungen bei der Auswahl von -- K1
SOUP erinnern.
IEC 62304 unterscheidet zwei Arten von "Software unbekannter Herkunft" (SOUP - Software of
Unknown Provenance):
 Off-the-Shelf-Software (OTS Software), d.h. Software-Komponenten, die bereits entwickelt
und allgemein verfügbar sind, die aber ursprünglich nicht entwickelt wurden, um in ein
Medizinprodukt integriert zu werden und
 zuvor entwickelte Software, für die angemessene Aufzeichnungen des Entwicklungsprozesses
nicht verfügbar sind.
Beispiele für SOUP sind: Betriebssysteme, Datenbanken, Hardware-Treiber,
Funktionsbibliotheken oder fertige Software-Komponenten, sofern sie in das Medizinprodukt
integriert werden (d.h. Bestandteil der auszuliefernden Software sind).
Gesamtlehrplan
Beide Arten von SOUP haben eins gemeinsam: Dem Hersteller des Medizingerätes liegt keine
ausreichende Dokumentation über die SW-Komponente vor, wie sie für den Einsatz im
Medizinprodukt erforderlich wäre. Off-the-Shelf-Software wird sogar völlig außerhalb eines
speziellen Entwicklungsprozesses für medizinische Software entwickelt.
Die Verwendung von SOUP in einem Medizinprodukt stellt eine potentielle Quelle für neue
Gefährdungen dar. Da über die Qualität der Entwicklung keine ausreichende Aussage getroffen
werden kann, enthält die SOUP möglicherweise unkalkulierbare Fehlerquellen, die sich auf die
Sicherheit des gesamten Medizinprodukts auswirken können. Außerdem entsteht für den
Hersteller des Medizinproduktes eine Abhängigkeit vom Hersteller der SOUP hinsichtlich
Fehlerbehebung und Unterstützung. Andererseits ist es kaum sinnvoll, verfügbare Software-
Komponenten nicht zu nutzen, sondern selbst neu zu entwickeln. Gute Beispiele sind hierfür
Betriebssysteme, Datenbanken oder Treiber. Hier muss davon ausgegangen werden, dass die
verfügbaren Komponenten durch ihre Spezialisierung und weite Verbreitung von höherer Qualität
und damit letztlich sicherer sind, als neu entwickelte Alternativen. Außerdem schafft der Einsatz
von verfügbaren Funktionsbibliotheken und fertigen Software-Komponenten Freiraum, um sich
auf die eigentliche Anwendung zu konzentrieren.
SOUP, die Teil einer Medizingeräte-Software ist, unterliegt selbstverständlich allen
regulatorischen Anforderungen an medizinische Software. Diese lassen sich aber für SOUP nicht
alle in der Praxis umsetzen. So liegt dem Hersteller des Medizingerätes in der Regel keine
Information über die innere Struktur (Architektur und detailliertes Design) vor. Daher gelten für
den Umgang mit SOUP besondere Regeln, die sicherstellen sollen, dass durch die Verwendung
der Software keine neuen Risiken entstehen.
Bei der Auswahl von SOUP, die im eigenen Medizinprodukt eingesetzt werden soll, sollten die
folgenden Punkte berücksichtigt werden:
 Wie ist die Wartungspolitik des Herstellers?
 Gibt es bereits eine Hersteller-spezifische Risikoanalyse?
 Gibt es Validierungsunterlagen seitens des Herstellers?
 Nutzen und Risiken im Vergleich zu alternativen Lösungen (z.B. Eigenentwicklung)
Eine Sonderform von SOUP ist frei verfügbare Software, die nicht von einem kommerziellen
Anbieter erstellt und gewartet wird (Open Source Software). Hier entscheidet die Verfügbarkeit
des Quellcodes. Liegt die Software als Quellcode vor, kann sie in die eigenen Entwicklungs- und
Qualitätssicherungsprozesse aufgenommen werden und somit wie eigene Software konform zu
den Regularien verwendet werden.
3.14.2. Umgang mit Software of Unknown Provenance
Aus dem Einsatz solcher Software unbekannter Herkunft (Software of Unknown Provenance,
SOUP), die außerhalb des eigenen Entwicklungsprozess entwickelt wurde, ergeben sich wichtige
Fragestellungen für die Sicherheit des gesamten Medizinprodukts. Sowohl die IEC 62304 als auch
die Regularien der FDA fordern die Einhaltung besonderer Methoden beim Einsatz von SOUP in
einem Medizinprodukt.
3.14.2.2. Forderungen der IEC 62304 hinsichtlich des Einsatzes von SOUP
Lehrziele
M3-LE14.2-1-1 Sich erinnern, wie SOUP gemäß IEC 62304 im -- K1
Konfigurationsmanagement identifiziert werden muss.
M3-LE14.2-1-1 Wissen, dass SOUP besonders im Risikomanagement -- K1
berücksichtigt werden muss.
M3-LE14.2-1-1 Wissen, dass SOUP im SW-Wartungsprozess -- K1
Gesamtlehrplan
berücksichtigt werden muss.

M3-LE14.2-1-1 Wissen, dass es für SOUP im Zusammenhang mit -- K1
Software der Sicherheitsklassen B und C weitere
Forderungen gibt.
M3-LE14.2-1-1 Die Anforderungen an den Änderungs- und -- K2
Wartungsprozess von SOUP verstehen.
M3-LE14.2-1-1 Die Forderungen der IEC 62304 an den -- K1
Entwicklungsprozess bei Einsatz von SOUP im
Zusammenhang mit Software der Sicherheitsklasse B
und C kennen.
M3-LE14.2-1-1 Verstehen, warum eine genaue Abgrenzung des -- K2
Einsatzes von SOUP hilft, die normativen
Anforderungen zu erfüllen.
Die IEC 62304 erwähnt SOUP im Zusammenhang mit allen zentralen Aktivitäten des
Entwicklungsprozesses. Jede SOUP muss im Konfigurationsmanagement eindeutig identifiziert
werden (Titel, Hersteller, Version, etc.). Für alle Sicherheitsklassen gilt, dass bei
Softwareänderungen auch das durch die SOUP entstehende Risiko neu bewertet werden muss. Es
muss immer geprüft werden, ob zusätzliche Elemente in der Ursachenkette für
Gefährdungssituationen hinzugekommen sind und ob zusätzliche Risikokontrollmaßnahmen
notwendig werden. Entsprechend muss auch im Softwarewartungsprozess berücksichtigt und
bewertet werden, wenn sich die SOUP selbst durch Updates oder neue Programmversionen
ändert.
Für die Sicherheitsklassen B und C gelten weitere Forderungen.
Es müssen Verfahren definiert werden, wie mit Updates, neuen Programmversionen oder
Fehlermeldungen von SOUP umgegangen wird und wie diese bewertet werden. Auch das
"Veralten" von SOUP muss berücksichtigt werden.
Für Sicherheitsklasse B und C gelten weitere Forderungen.
 Anforderungen an die Funktionalität und Leistungsfähigkeit der SOUP müssen formuliert
werden.
 Die Integration von SOUP-Komponenten muss verifiziert werden.
 Die für den Einsatz der SOUP erforderliche Systemhard- und -software muss spezifiziert
werden.
 Die Software-Architektur muss dahingehend verifiziert werden, ob sie die richtige Funktion
aller SOUP-Komponenten unterstützt.
 Die Implementierung der Anforderungen muss verifiziert werden.
 Im Risikomanagement muss untersucht werden, in wie weit der Ausfall oder das unerwartete
Verhalten einer SOUP dazu beitragen kann, dass eine Gefährdungssituation entsteht.
 Veröffentlichte Listen mit Anomalien der SOUP müssen evaluiert werden, um zu ermitteln
inwieweit bekannte Anomalien zu Gefährdungssituationen beitragen können.
Das Vorgehen, wie mit Risiken im Zusammenhang mit dem Einsatz von SOUP verfahren wird,
entspricht dem Risikomanagement für Medizinprodukte gemäß ISO 14971 und wurde bereits im
Modul "Risikomanagement" erläutert.
Es ist es wichtig, genau abzugrenzen, wo die SOUP zum Einsatz kommt, welche Funktionalität
verwendet wird, welche Module der Software-Architektur des Medizinproduktes durch die SOUP
beeinflusst werden können (und welche nicht) etc. Durch diese genaue Abgrenzung lässt sich die
korrekte und sichere Funktionsweise der SOUP gezielter nachweisen. So müssen z.B. nicht
verwendete Funktionalitäten auch nicht geprüft werden, sofern ihre Verwendung definitiv
ausgeschlossen ist (z.B. durch ein Codereview).
3.14.2.3. Forderungen der FDA hinsichtlich des Einsatzes von OTS-Software
Gesamtlehrplan
Lehrziele
M3-LE14.2-2-1 Sich erinnern, dass die bei der FDA einzureichende -- K1
Dokumentation für OTS-Software abhängig von ihrem
möglichen Einfluss auf die Sicherheit von Patienten,
Anwendern und Dritte ist.
M3-LE14.2-2-1 Die Spanne zwischen der minimal zu erbringenden -- K1
Dokumentation und den maximalen Anforderungen
der FDA kennen (abhängig von der Klassifizierung).
M3-LE14.2-2-1 Verstehen, wie die FDA OTS-Software nach ihrem -- K2
Gefährdungspotential klassifiziert
M3-LE14.2-2-1 Die Inhalte der zu erstellenden Dokumentation -- K1
kennen.
M3-LE14.2-2-1 Gemeinsamkeiten und Unterschiede der Forderungen -- K1
von FDA und IEC 62304 hinsichtlich SOUP kennen.
Die FDA hat einen Leitfaden (Guidance Document) für die Industrie herausgegeben, das konkret
beschreibt, was sie an zusätzlicher Dokumentation erwartet, wenn SOUP im Medizinprodukt
eingesetzt wird, wobei hier der Schwerpunkt auf Off-the-Shelf-Software (OTS) liegt. Zur
Erinnerung: Die Definitionen von SOUP und OTS-Software sind nahezu deckungsgleich. In beiden
Fällen handelt es sich um Software, deren Entwicklungsprozess nicht bekannt/dokumentiert ist.
Die FDA bezieht sich nur auf Software, die allgemein verfügbar ist.
Abhängig vom möglichen Einfluss auf die Sicherheit von Patienten, Anwendern und Dritten teilt
die FDA die OTS-Software ganz analog zum gesamten Medizinprodukt in drei Klassen ein, für die
ein unterschiedlicher Umfang an Dokumentation und Risikobewertung im Rahmen des
Zulassungsantrags eingereicht werden muss.
 a) Minor Level of Concern: Es ist nicht zu erwarten, dass Mängel der OTS-Software zu
irgendwelchen Verletzungen führen können
 b) Moderate Level of Concern: Mängel (auch indirekte) der OTS-Software könnten zu leichten
Verletzungen führen.
 c) Major Level of Concern: Mängel (auch indirekte) der OTS-Software könnten zu schweren
Verletzungen und zum Tod führen.
Abhängig von der Zuordnung der OTS-Software zu den genannten Klassen, müssen laut FDA-
Handbuch verschiedene Dokumentationen EINGEREICHT werden. (Hier besteht ein klarer
Unterschied zur IEC 62304, in welcher spezifiziert wird, welche Aktivitäten DURCHGEFÜHRT UND
DOKUMENTIERT werden müssen).
Unabhängig vom "Level of Concern" muss immer eine Basisdokumentation eingereicht werden,
die recht umfangreich ist: Identifikation der OTS-Software und Rahmenbedingungen für den
Einsatz, Systemanforderungen an Hard- und Software, Anforderungen an die richtige Installation
und Konfiguration, Anforderungen an die OTS-Software selbst, Beschreibung der
qualitätssichernden Maßnahmen (inkl. deren Ergebnisse), sowie eine Beschreibung des
Änderungsmanagement. Stellt sich in der Risikoanalyse heraus, dass durch die OTS-Software in
keiner Weise Verletzungen von Patient, Bediener oder Dritten möglich sind, so ist die
Basisdokumentation ausreichend.
Falls durch die OTS-Software Verletzungen auftreten können (d.h. für "Moderate" und "Major
Level of Concern"), müssen Risikokontrollmaßnahmen definiert werden, welche die Schwere der
Gefährdung und/oder die Wahrscheinlichkeit ihres Auftretens vermindern. Erreicht werden kann
dies durch Designänderungen, um Gefährdungen von vornherein zu vermeiden,
Schutzmaßnahmen oder Anwender-Warnungen. Schließlich muss das verbleibende Risiko nach
Gesamtlehrplan
der Gefährdungsminimierung beschrieben und als vertretbar bewertet werden. Die

entsprechende Dokumentation muss bei der FDA eingereicht werden.
Sind auch nach der Gefährdungsminimierung noch schwere Verletzungen oder Tod durch die
OTS-Software möglich ("Major Level of Concern"), so ist eine "SPECIAL DOCUMENTATION for OTS
Software" zu erstellen. Diese weist nach, dass der Hersteller der OTS-Software
Entwicklungsmethoden anwendet, die im Einklang mit den Erfordernissen für den Einsatz im
Medizinprodukt stehen. Vorzugsweise erfolgt auch ein Audit des Herstellers der OTS-Software. Es
muss außerdem nachgewiesen werden, dass die Verifikations- und Validierungsmaßnahmen
bezüglich der OTS-Software und des ganzen Medizinprodukts ausreichend sind. Darüber hinaus
muss sichergestellt werden, dass die OTS-Software auch ohne den eigentlichen Hersteller der
OTS-Software betrieben und gewartet werden kann.
Die Vorschriften der FDA für OTS-Software, die in einem Medizinprodukt mit "Major Level of
Concern" eingesetzt wird, gehen somit über die Forderungen der EN 62304 hinaus.
Können die Forderungen nicht erfüllt werden, oder können die verbleibenden Risiken nicht als
"vertretbar" eingestuft werden, so darf das Medizinprodukt nicht auf den Markt gebracht
werden.
3.15. Computer-System-Validierung
3.15.1. Einführung
Im Softwareentwicklungsprozess eingesetzte Werkzeuge haben u.U. einen Einfluss auf das
Produkt und die Produktqualität. Die relevanten Normen fordern daher die Validierung der
eingesetzten Werkzeuge, um nachzuweisen, dass sie ihre Zweckbestimmung erfüllen.
 Werkzeug (Tool)
3.15.1.3. Abgrenzung Tool vs. SOUP
Lehrziele
M3-LE15.1-1-1 Die Abgrenzung von Werkzeug (Tool) zu SOUP -- K2
verstehen.
Unter den Begriff "Tool" fallen alle im Softwareentwicklungsprozess eingesetzten Werkzeuge, die
Einfluss auf das Produkt selbst oder dessen Qualität haben. Typische Beispiele: Quellcode-
Versionsverwaltungssysteme, Testmanagementsysteme, eigenentwickelte Skripte, etc. Unter
SOUP "Software of Unknown Provenance" versteht man hingegen Software, die selbst
Bestandteil des Produkts wird; z.B. Laufzeitbibliotheken, Funktionsbibliotheken, Betriebssysteme,
Datenbanken, etc. (immer vorausgesetzt, sie sind integraler Bestandteil der Medizinprodukte-
Software).
3.15.1.4. Motivation
Lehrziele
M3-LE15.1-2-1 Die Notwendigkeit der Tool-Validierung verstehen. -- K2
M3-LE15.1-2-1 Sich an die für die Tool-Validierung relevanten -- K1
Normen erinnern.
M3-LE15.1-2-1 Die Forderungen der relevanten Normen bezüglich der -- K1
Toolvalidierung kennen.
Gesamtlehrplan
Zeitgemäße Softwareentwicklungsprozesse müssen die Nachvollziehbarkeit der

Softwareentwicklung z.B. durch Tracing, Versionierung und teilweise auch Audit Trails
sicherstellen. Dazu ist es erforderlich, auch für die eingesetzten Werkzeuge nachzuweisen, dass
diese ihren bestimmten Zweck richtig erfüllen. In ISO 13485 und den Regularien der FDA wird
diese Werkzeugvalidierung explizit gefordert, sofern diese Einfluss auf die zu entwickelnder
Qualität der Produkte haben. Außerdem ergibt sie sich indirekt aus der ISO 14971, da
prozessunterstützende Werkzeuge potentiell Einfluss auf das Medizinprodukt bzw. dessen
Qualität haben können. Werkzeugvalidierung kann also als eine Art Risikokontrollmaßnahme im
Prozess angesehen werden.
Hersteller verlassen sich oft darauf, dass die Werkzeugen, das tun, wozu sie eingesetzt sind.
Beispielsweise, dass ein Unit-Test-Werkzeug Abweichungen von Soll- und Ist-Werten
dokumentiert und in einem Bericht zusammenfasst. Durch Fehlkonfigurationen und gelegentlich
durch Fehler in den Werkzeugen bleiben Abweichungen unerkannt. Um dies vermeiden, sollen
Hersteller prüfen, dass die Werkzeuge für den geplanten Zweck geeignet sind.
ISO 13485 fordert die Toolvalidierung in Kapitel 7.5.2.1 für alle Werkzeuge, die in der Herstellung
und/oder Produktion eingesetzt werden und direkt oder indirekt Einfluss auf das Medizinprodukt
haben. Zudem fordert die ISO 13485 in Kapitel 7.6 dass „bei Verwendung von Computersoftware
zur Erfassung und Messung festgelegter Anforderungen die Eignung dieser Software fü r die
beabsichtigte Anwendung bestätigt werden muss.“
Die FDA fordert in 21 CFR 820.70(i) explizit die Validierung von automatisierten Prozessen bei der
Produktion und Qualitätssicherung. Nach 21 CFR 11 ist eine Validierung erforderlich, sobald die
Werkzeuge von den Themen "elektronische Unterschrift" und "elektronische Aufzeichnung"
betroffen sind.
3.15.2. Tool-Validierung in der Praxis
In aller Regel lässt sich die Erfüllung der Zweckbestimmung der eingesetzten Werkzeuge nicht
vollständig nachweisen. Daher ist ein risikobasierter Ansatz anzuraten, ähnlich wie bei der
Produktsoftware selbst. Hierzu muss ein Validierungsplan erstellt werden, dessen Einzelschritte
für die Validierung durchgeführt und dokumentiert werden müssen.
 Audit-Trail
 Validierungs-Plan
3.15.2.3. Validierungsplan
Lehrziele
M3-LE15.2-1-1 Die Bedeutung des Validierungsplans kennen. -- K1
M3-LE15.2-1-1 Die Inhalte eines Validierungsplans kennen. -- K1
Der Validierungsplan beschreibt wie der Hersteller plant, ein konkretes Werkzeug zu validieren.
Dabei verweist der Validierungsplan häufig auf eine übergeordnete Verfahrens- oder
Prozessbeschreibung (SOP).
Für die Toolvalidierung ist mindestens erforderlich:
 eine Inventarliste der Werkzeuge mit eindeutiger Identifizierung,
 eine Impactanalyse für jedes eingesetzte Werkzeug, in der ermittelt wird, ob dieses Werkzeug
validiert werden muss,
 eine Beschreibung der geplanten Vorgehensweise für folgende Aktivitäten:
Anforderungsdefinition an die Werkzeuge, Testspezifikation, Testdurchführung, Archivierung
der Validierungsergebnisse und Werkzeuge, Wartung der Werkzeuge.
Gesamtlehrplan
Außerdem kann es sinnvoll sein, eine Vorgehensweise für die Evaluierung und Auswahl neuer
Werkzeuge festzulegen.
3.15.2.4. Inventarliste der Werkzeuge
Lehrziele
M3-LE15.2-2-1 Sich erinnern, was in die Inventarliste aufgenommen -- K1
werden muss.
M3-LE15.2-2-1 Aufbau und Inhalt der Werkzeug-Inventarliste -- K2
verstehen.
Bevor eine Validierung der im Entwicklungsprozess verwendeten Werkzeuge stattfinden kann,
müssen diese zunächst erst einmal identifiziert werden. Hierbei ist darauf zu achten, dass
tatsächlich alle Werkzeuge erfasst werden, insbesondere auch selbst entwickelte Skripte.
Für jedes Werkzeug muss festgehalten werden, für welchen Zweck es genau eingesetzt wird. Es
muss zudem eingeschätzt werden, wie groß die Auswirkungen auf das Produkt sein können. Je
größer die möglichen Auswirkungen sind, umso detaillierter muss die Validierung durchgeführt
werden. Sind die möglichen Auswirkungen dagegen unkritisch, so kann mit entsprechender
Begründung von einer Validierung abgesehen werden. Dies muss dann dokumentiert werden.
3.15.2.5. Anforderungsdefinition
Lehrziele
M3-LE15.2-3-1 Verstehen, wie Einsatzzweck und Anforderungen an -- K2
das Werkzeug den Validierungsumfang bestimmen.
Um eine Validierung des Werkzeugs für einen bestimmten Einsatzzweck durchführen zu können
und um nicht in die Verpflichtung zu kommen, das gesamte Werkzeug "an sich" validieren zu
müssen, gilt es, die Anforderungen an das Werkzeug für den vorgesehenen Einsatzzweck zu
definieren. Dabei ist der zuvor festgelegte Intended Use des Werkzeugs zu berücksichtigen. Das
Vorgehen entspricht hierbei dem üblichen Vorgehen bei einer Anforderungsanalyse. Die
Validierung kann dann auf die genutzte Funktionalität beschränkt werden.
3.15.2.6. Evaluierung von Werkzeugen
Lehrziele
M3-LE15.2-4-1 Vorteile der Werkzeug-Evaluierung kennen. -- K1
Werden Werkzeuge benötigt, die noch nicht im Softwareentwicklungsprozess eingebunden sind,
sollten diese vorab evaluiert werden. Als Vorgehensweise zur Evaluierung bietet es sich auch an,
Anforderungen zu formulieren, die die in Frage kommenden Werkzeuge erfüllen müssen. Zu
diesen Anforderungen können dann Tests entwickelt werden, anhand derer gemessen werden
kann, wie gut ein untersuchtes Werkzeug die vorab definierten Anforderungen erfüllt. Bei der
anschließenden Beurteilung der Prüfergebnisse kann das am besten passende Werkzeug
ausgewählt werden. Ein solches Vorgehen bietet einen dokumentierten Auswahlprozess und
vermeidet, dass Werkzeuge zum Einsatz kommen, welche die Anforderungen nur teilweise oder
gar nicht erfüllen. Die Evaluierungsergebnisse können dann auch bei der Validierung weiter
verwendet werden.
3.15.2.7. Impactanalyse für die eingesetzten Werkzeuge
Lehrziele
Gesamtlehrplan
M3-LE15.2-5-1 Verstehen, dass durch den Werkzeugeinsatz Risiken -- K2

entstehen können.
M3-LE15.2-5-1 Vorgehensweisen kennen, mit denen der Einfluss von -- K1
Fehlfunktionen eines Werkzeugs auf das
herzustellende Produkt begrenzt werden kann.
Für Werkzeuge, deren Verwendung im Rahmen des Einsatzzwecks Einfluss auf die Produktqualität
haben, kann eine detailliertere Impactanalyse durchgeführt werden. Dabei können die aus der
Risikoanalyse bekannten Methoden verwendet werden (z.B. FMEA).
3.15.2.8. Werkzeuge testen
Lehrziele
M3-LE15.2-6-1 Verstehen, dass die Tests der Anforderungen für -- K2
Werkzeuge geplant und spezifiziert werden müssen.
M3-LE15.2-6-1 Verstehen, worauf bei der Durchführung der Tests -- K2
geachtet werden muss.
Zum Nachweis, dass das Werkzeug die Anforderungen erfüllt und die ggf. definierten
Maßnahmen greifen, müssen entsprechende Tests formuliert werden. Hierbei muss jede
Anforderung und jede Maßnahme durch Tests abgedeckt sein. Wie bei Testspezifikationen üblich,
müssen für jeden Test die Testschritte und deren erwartetes Ergebnis festgelegt werden.
Außerdem muss die Zuordnung zu einer bestimmten Anforderung bzw. Maßnahme
nachvollziehbar sein. Soweit anwendbar, muss auch festgelegt werden, wie die Tests
durchzuführen sind (Hardware, Umgebung, Ressourceneinsatz, etc.) und welche Testdaten zu
verwenden sind (siehe Abschnitt "Validierungsplan").
Sobald die Planung und Spezifikation der Tests erfolgt ist, können die Tests (und damit die
eigentliche Validierung) durchgeführt werden. Die Testergebnisse, inklusive eventueller
Abweichungen, müssen dokumentiert werden. Hierbei gelten die bekannten Grundsätze für eine
nachvollziehbare Testdurchführung: Es muss festgehalten werden, wer, wann, auf welcher
Testumgebung und natürlich mit welchem Ergebnis die Tests durchgeführt wurden. Anschließend
muss dokumentiert werden, ob und mit welchen Einschränkungen die Validierung als erfolgreich
betrachtet werden kann. Außerdem muss geprüft und dokumentiert werden, dass alle
Anforderungen und Maßnahmen vollständig durch die durchgeführten Tests abgedeckt werden.
3.15.2.9. Archivierung
Lehrziele
M3-LE15.2-7-1 Die am Ende einer Werkzeugvalidierung zu -- K1
archivierenden Artefakte kennen.
Die bei der Validierung entstandenen Artefakte selbst, müssen gemäß den Vorgaben an die
Dokumentenlenkung archiviert werden, um auch auf dauerhaft nachweisen zu können, dass die
Validierung tatsächlich durchgeführt wurde. Dies umfasst alle Dokumente wie Validierungsplan,
Inventarliste, Evaluierungsunterlagen, Impactanalyse, Anforderungsdefinition, Testspezifikation,
Testprotokollierung, Validierungsbewertung. Ebenso ist das Werkzeug (einschließlich
Versionsinformation und Konfigurationsdaten) zu archivieren, um die Validierungsergebnisse
reproduzieren zu können.
3.15.3. Wartung der Werkzeuge
Gesamtlehrplan
Auch Werkzeuge "veralten" und müssen daher von Zeit zu Zeit aktualisiert werden. Dadurch wird
jedoch eine erneute Validierung erforderlich.
 Revalidierung
3.15.3.3. Werkzeug-Wartung
Lehrziele
M3-LE15.3-1-1 Verstehen, warum Werkzeuge gewartet werden -- K2
müssen und dass dann eine Revalidierung erforderlich
ist.
M3-LE15.3-1-1 Sich erinnern, dass bekannte Fehler des Werkzeugs -- K1
regelmäßig überwacht und ggf. in der Validierung
berücksichtigt werden müssen.
Nachdem das Werkzeug einmal validiert ist, würde man am liebsten nie wieder etwas daran
ändern. Leider ist dies nicht möglich, und auch nicht sinnvoll, da auch Werkzeuge "veralten". Es
werden immer wieder Fehler behoben. Außerdem kann es sein, dass sich die Werkzeuge an eine
geänderte Umgebung (z.B. ein neues Betriebssystem) anpassen müssen. Es müssen daher von
Zeit zu Zeit Updates eingespielt werden. Außerdem können neue Erweiterungen erforderlich sein
(z.B. wenn im Einsatz noch ein potentielle Fehlerquelle identifiziert wird, die Einfluss auf die
Produktqualität haben könnte).
Sobald Updates oder Erweiterungen der Werkzeuge eingesetzt werden, muss die
Werkzeugvalidierung teilweise oder komplett neu durchgeführt werden. Man spricht dann von
einer Revalidierung.
Der Hersteller des Medizinproduktes muss die von Werkzeugherstellern gepflegte Fehlerlisten
beobachten und beurteilen, ob die berichteten Sachverhalte für den eigenen Werkzeugeinsatz
und dessen Validierung von Belang sind oder nicht. Es muss entschieden werden, ob die
bekannten (bzw. die in der aktuellsten Version behobenen) Fehler ein Update des Werkzeugs
erforderlich machen oder eben gerade verhindern. Im Zweifelsfalle muss die Validierungs-
Testspezifikation um eine Prüfung erweitert werden, dass der bekannte Fehler keinen Einfluss auf
die Qualität des Medizinproduktes haben kann. Die Werkzeugvalidierung wird dann erneut ganz
oder teilweise neu durchgeführt werden. Wird etwas am Werkzeug geändert, muss prinzipiell
revalidiert werden.
Gesamtlehrplan
4. Curriculum Usability
Dieses Modul beschreibt die regulatorischen Anforderungen an die Gebrauchstauglichkeit mit
Schwerpunkt auf die IEC 62366 sowie die Methoden und Verfahren, um gebrauchstaugliche
medizinische Software zu entwickeln.
4.1. Grundlagen des Usability Engineerings

4.1.1. Weshalb Usability Engineering wichtig ist
Je komplexer die Medizingeräte und die Behandlungsverfahren werden, desto entscheidender ist
es, dass die Benutzer ihre Nutzungsziele sowohl überhaupt (effektiv) als auch effizient (ohne
Nutzungsprobleme) erreichen können. Andernfalls werden die Risiken durch mangelnde
Gebrauchstauglichkeit für Patienten, Anwender und Dritte kaum mehr zu beherrschen.
 Usability
 Nutzungskontext
 Anormaler Gebrauch
 vorhersagbarer Missbrauch
 Irrtum
 Mentales Modell
4.1.1.4. Probleme durch mangelnde Gebrauchstauglichkeit
Lehrziele
M4-LE1.1-1-1 Erklären können, warum mangelnde K1 W
Gebrauchstauglichkeit ein großes Problem darstellt
und welche Erklärungen es dafür gibt.
Nahezu täglich veröffentlichen Behörden wie in Deutschland das Bundesamt für Arzneimittel und
Medizinprodukte Meldungen von Herstellern über Risiken derer Produkte. Bei diesen Meldungen
sind die Risiken, die auf mangelnde Gebrauchstauglichkeit zurückzuführen sind,
unterrepräsentiert. Hersteller neigen dazu, diese als Benutzerfehler zu klassifizieren. Zudem
kommen die Betreiber und Benutzer wie die Krankenhäuser ihrer Pflicht, Probleme bei der
Anwendung der Produkte zu melden, nur unzulänglich nach.
Nach unbestätigten Zahlen stehen 70% der FDA-Recalls mit mangelnder Gebrauchstauglichkeit in
Verbindung.
Nutzungsfehler können auf verschiedene Ursachen zurückgeführt werden:
1. Die Nutzer erkennen eine Information an der Benutzer-Produkt-Schnittstelle nicht oder
falsch, beispielsweise weil sie zu klein dargestellt ist (Perception).
2. Die Nutzer erkennen die Information zwar, verstehen sie aber falsch (Cognition).
Beispielsweise ist dem Nutzer nicht klar, dass seine rote Markierung nicht für gefährlich steht,
sondern für arterielles Blut.
3. Es kann auch passieren, dass die Nutzer falsche handeln (Action), sogar unabhängig davon ob
sie die Informationen richtig erkannt und verstanden haben. Beispielsweise weil sie abgelenkt
sind. Falsche Handlungen können wieder am gleichen oder einem anderen Medizinprodukt
bei der Eingabe oder Auswahl erfolgen oder auch außerhalb des direkten Kontexts des
Gesamtlehrplan
Medizinprodukts. Ein Arzt der einem Patienten ein falsches Medikament verschreibt, begeht
einen Fehler, der auch durch ein Nicht- oder Falscherkennen oder Missverstehen von
Informationen begründet sein kann. Die Handlungen lassen sich zudem in beabsichtigte und
unbeabsichtigte unterscheiden. Ein Anwender kann unbeabsichtigt eine falsche Taste
bedienen, weil diese zu nah an einer anderen Taste liegt. Oder er kann eine falsche Handlung
absichtlich begehen. Ursache dafür können falsch oder fehlerhaft erkannte (Perception) oder
verstandene (Cognition) Informationen ebenso sein wie eine falsche Vorstellung darüber, wie
das Medizinprodukt funktioniert und welche Folgen eine Interaktion damit hat. Man spricht
dann darüber, dass die Nutzer des Medizinprodukts ein anderes mentales Model wie die
Entwickler des Medizinprodukts haben.
4.1.1.5. Gründe für Usability Engineering Prozess
Lehrziele
M4-LE1.1-2-1 Erkennen warum ein K1 W
gebrauchstauglichkeitsorientierter
Entwicklungsprozess wichtig ist und Vorteile bringt.
Hersteller sollten den gebrauchstauglichkeitsorientierten Entwicklungsprozess befolgen, um
1. gesetzliche Vorschriften einzuhalten,
2. die Risiken für Patienten Anwender und Dritte zu minimieren
3. den Markterfolg erhöhen und
4. die Entwicklungszeit und Kosten zu minimieren.
Dass Hersteller die gesetzlichen Vorschriften einhalten müssen, bedarf keines weiteren
Kommentars. Die Motivation der Gesetzgeber besteht genau darin, die Risiken durch das
Medizinprodukt (aufgrund mangelnder Gebrauchstauglichkeit) zu minimieren.
Gebrauchstauglichkeit ist eine der grundlegenden Anforderungen in der MDD. Genau das ist auch
der Fokus der IEC 62366.
Hersteller verstehen zunehmend, dass sie durch ein systematisches Requirements Engineering die
wirklichen Stakeholder Anforderungen identifizieren und damit Produkte entwickeln können, die
im Markt erfolgreich sein werden. Ein systematisches Vorgehen hat den Vorteil, dass die
Stakeholder-Anforderungen nicht durch "Try and Error" ermittelt werden müssen, sondern
zuverlässig und stabil zu Beginn der eigentlichen Entwicklung zur Verfügung stehen. Dies erspart
unnötige Iterationen und damit Zeit und Geld.
4.1.1.6. Beispiele für Probleme mit der Gebrauchstauglichkeit
Lehrziele
M4-LE1.1-3-1 Beispiele nennen können, wie mangelnde K2 W
Gebrauchstauglichkeit von Medizinprodukten,
insbesondere medizinischer Software, zu
Gefährdungen von Patienten, Benutzern und Dritten
führte.
Zu den Beispielen für mangelnde Gebrauchstauglichkeit zählen:
 Fehlerhaft oder inkonsistente (z.B. mit der Gebrauchsanweisung) Beschriftungen,
beispielsweise ein Textfeld, dessen Label Harnstoff statt Harnsäure nennt.
 Missverständliche Kennzeichnungen, beispielsweise weil sie nicht die Terminologie der
Benutzer oder übliche Kodierungen (z.B. über Formen oder Farben) verwenden, weil
Kodierungen inkonsistent genutzt oder weil Beschriftungen nicht klar den UI-Elementen
zugeordnet werden können. Ein Beispiel ist ein Beatmungsgerät mit einem Drehschalter, der
Gesamtlehrplan
nach rechts (mit blauer Farbe markiert) oder links (mit oranger Farbe markiert) gedreht
werden kann. Ein Arzt ist unsicher und entscheidet sich für „die blaue Richtung“, weil ihm
diese Farbe ungefährlicher erscheint. Das behandelte Kind stirbt. Quelle:
http://www.telegraph.co.uk/news/uknews/1513550/Baby-died-after-untrained-doctor-took-
50-50-gamble-on-pressing-right-button.html.
 Schlecht lesbare Benutzerschnittstellen, beispielsweise weil die Schriftart zu klein oder
ungeeignet ist oder weil Kontrastverhältnisse zu niedrig sind.
 Irreführende Elemente der Benutzerschnittstelle, beispielweise falsche Default-Werte oder
Skalen, die unzutreffende Normalwerte annehmen lassen.
 Nicht an die kulturellen Gepflogenheiten angepasste Benutzerschnittstellen wie eine
Infusionspumpe, die für den japanischen Markt entwickelt wurde und in Europa in Verkehr
gebracht wird. Für den japanischen Markt wird die Funktion Starte Infusion mit der Farbe Rot
gekennzeichnet – keine ungewöhnliche Wahl, wenn man bedenkt, dass Nutzer aus Japan mit
der Farbe Rot normalerweise Glück und andere positive Eigenschaften assoziieren. In
westlichen Kulturen ist die Farbe Rot normalerweise mit Gefahr und Stopp assoziiert, was
auch der Farbkodierung in internationalen Standards übereinstimmt. Es ist vorhersehbar,
dass Nutzungsfehler auftreten können, wenn diese Infusionspumpe in westlichen Kulturen
genutzt wird. Quelle: AAMI HE75
Häufig hindern auch eine umständliche Navigation oder eine schlecht strukturierte
Informationsarchitektur die Benutzer am effizienten Arbeiten. Das kann wiederum dazu führen,
dass Benutzer unvorhergesehene „Abkürzungen“ wählen, was zu unvorhergesehen Risiken führt.
Nur Wiederholung
4.1.1.7. Nutzungskontext und Gebrauchstauglichkeit
Lehrziele
M4-LE1.1-4-1 Verstehen, dass die Gebrauchstauglichkeit nur in K2 W
einem definierten Nutzungskontext bestimmt werden
kann.
M4-LE1.1-4-1 Beispiele nennen können, wie sich der K2 W
Nutzungskontext auf die Gebrauchstauglichkeit
auswirkt.
Die Gebrauchstauglichkeit eines Produkts lässt nur in einem gegebenen Nutzungskontext
beurteilen. Zu diesem Nutzungskontext zählen die Benutzer und Patienten ebenso wie die
Arbeitsumgebung einschließlich der Arbeitsbelastung, Ablenkungen und physikalischer Parameter
wie Helligkeit und Temperatur.
4.1.1.8. Typen von Benutzerhandlungen
Lehrziele
M4-LE1.1-5-1 Die verschiedenen Handlungen von Benutzern -- K1
benennen und die Taxonomie gemäß DIN EN 62366
Bild B.1 aufzeichnen können.
M4-LE1.1-5-1 Zusammenhang von anormalem Gebrauch und -- K1
vorhersagbarem Missbrauch erklären können.
Benutzer können beim Gebrauch von Medizinprodukten Fehler begehen. Bei diesen
Benutzungsfehlern unterscheidet man Aufmerksamkeitsfehler, Erinnerungsfehler und Irrtum. Nur
beim Irrtum begeht der Benutzer die Handlung beabsichtigt, beispielsweise weil er über ein
Gesamtlehrplan
mentales Modell des Produkts verfügt, welches nicht mit der tatsächlichen Funktionsweise
übereinstimmt. Auch eine vom Benutzer beabsichtigte aber vom Hersteller nicht vorhergesehene
Umgehungsmöglichkeit oder die falsche Anwendung einer Regel zählen zu Beispielen für einen
Irrtum.
Als anormalen Gebrauch definiert die DIN EN 62366 eine „vorsätzliche Handlung oder
vorsätzliche Unterlassung einer Handlung […] als Ergebnis einer Handlungsweise, die außerhalb
der angemessenen Möglichkeiten des Herstellers zur Risikobeherrschung liegt“. So ein
Missbrauch könnte darin bestehen, dass die Benutzer es für einen nicht vorhergesehen Zweck
benutzen, Sicherheitshinweise bewusst ignorieren oder es ohne entsprechende Ausbildung
einsetzen, obwohl dies explizit gefordert ist.
Der vorhersagbare Missbrauch umfasst Aktivitäten des Nutzers, die wissentlich darauf abzielen,
ein Ergebnis zu erzielen, das der Hersteller explizit vom ordnungsgemäßen Gebrauch
ausgeschlossen hat. Er entspricht damit dem "anormalen Gebrauch" gemäß DIN EN 62366.
Quelle: DIN EN 62366 Annex A, subclause 5.2
4.1.2. Begrifflichkeiten im Kontext der Gebrauchstauglichkeit
Usability hat sich zu einem populären Schlagwort entwickelt. Allerdings nutzen viele diesen
Begriff unterschiedlich und verstehen darunter eine Mischung aus Softwareergonomie und
Design. Das Zusammenspiel mit dem Risikomanagement wird hingegen seltener betrachtet. Ein
einheitliches und präzises Verständnis des Begriffs Gebrauchstauglichkeit stellt eine wesentliche
Voraussetzung dar, um Medizinprodukte normenkonform und mit beherrschbarem Risiko zu
entwickeln und zu betreiben.
 Ergonomie
 User Experience
 Validierung (der Gebrauchstauglichkeit)
 Verifizierung (der Gebrauchstauglichkeit)
4.1.2.3. Was Gebrauchstauglichkeit bedeutet
Lehrziele
M4-LE1.2-1-1 Anhand von Beispielen erklären können, was K2 W
Gebrauchstauglichkeit bedeutet. Den Begriff
definieren können.
M4-LE1.2-1-1 Den Begriff Gebrauchstauglichkeit in Zusammenhang -- K2
mit den Begriffen Ergonomie, Benutzbarkeit und der
„User Experience“ setzen können.
Die DIN EN 62366 definiert die Gebrauchstauglichkeit als "die Eigenschaft der BENUTZER-
PRODUKT-SCHNITTSTELLE, die die EFFEKTIVITÄT, EFFIZIENZ sowie die Lernförderlichkeit und
Zufriedenstellung des BENUTZERS umfasst." Etwas besser verständlich ist die Definition der ISO
9241-11: „Das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten
Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und
zufriedenstellen zu erreichen.""
Gebrauchstauglichkeit eines Medizinprodukts ist ein Qualitätsmerkmal, das am Produkt selbst
feststellbar und überprüfbar ist. Ergonomie hingegen ist definiert als:
Die wissenschaftliche Disziplin und das systematische Studium, die/das sich mit der Aufklärung
der Wechselwirkungen zwischen menschlichen und anderen Elementen eines Systems befasst,
Gesamtlehrplan
und der Berufszweig, der die Theorie, Prinzipien, Daten und Methoden auf die
(System)Gestaltung anwendet mit dem Ziel, das Wohlbefinden des Menschen und die Leistung
des Gesamtsystems zu optimieren. [ISO 6385:2004]
Software-Ergonomie ist demzufolge die Disziplin, die die Regeln zur gebrauchstauglichen
Softwaregestaltung ermittelt und fortschreibt.
Ein Aspekt der Ergonomie ist die Benutzbarkeit. Unter Benutzbarkeit versteht man die Tatsache,
dass einzelne User-Interface-Elemente erkennbar sind und Eingaben und Auswahlen ohne
Hindernisse zulassen [Geis, Johner; 2015].
Beispiele:
 Eine Null und der Buchstabe O sind in einer Anzeige unterscheidbar.
 Eine Tastatur hat zwischen den einzelnen Tasten ausreichend  Abstand, um nicht
versehentlich die falsche Taste zu drücken. Der Tastendruck ist nicht zu hoch und nicht zu
niedrig.
Beide Begriffe sollten nicht mit der Gebrauchstauglichkeit verwechselt werden. So ist die
Benutzbarkeit eines Systems eine notwendige aber nicht hinreichende Voraussetzung für dessen
Gebrauchstauglichkeit.
Der Begriff Gebrauchstauglichkeit (Usability) betrachtet ausschließlich die konkrete Situation in
der ein Produkt genutzt wird. Hingegen umfasst die Definition der ISO 9241-210„User
Experience“ zusätzlich die Wahrnehmung des Produkts vor der Nutzung („antizipierte Nutzung“)
und und die Wahrnehmung des Produkts durch den Nutzer nach der erfolgten Nutzung. Der
deutsche Begriff für „User Experience“ lautet demzufolge „Benutzererlebnis“.
4.1.2.4. Verifizierung und Validierung der Gebrauchstauglichkeit
Lehrziele
M4-LE1.2-2-1 Basierend auf der Definition des Begriff K2 W
Gebrauchstauglichkeit erklären können, dass die
Validierung der Gebrauchstauglichkeit ein wichtiger
Aspekt der Validierung des Produktes ist.
M4-LE1.2-2-1 Beispiele für die Verifizierung nennen können. Den K2 W
Begriff von der Validierung unterscheiden können.
Unter der Validierung der Gebrauchstauglichkeit versteht man den Nachweis, dass Benutzer ihre
Nutzungsziele effektiv und effizient (ohne Nutzungsprobleme) erreichen. Dies bedingt, dass man
überhaupt die Nutzungsziele mit dem Produkt erreichen kann, die die Zweckbestimmung nennt.
Dies wäre im Rahmen einer „klassischen“ Produktvalidierung nachzuweisen. Die Validierung der
Gebrauchstauglichkeit prüft zusätzlich, ob dies auch den spezifizierten Nutzern im spezifizierten
Nutzungskontext gelingt. Diese Validierung setzt somit die Einbeziehung der spezifizierten Nutzer
voraus.
Die Verifizierung tut dies nicht. Dabei können Usability Experten mehrere Aspekte prüfen:
Zum einen untersuchen sie das Produkt auf Verstöße gegen Gestaltungsrichtlinien wie mangelnde
Kontrastverhältnisse (z.B. graue Schrift auf weißem Untergrund (Lesbarkeit) oder auf
mehrdeutige oder verwechselbare Bezeichnungen (Unterscheidbarkeit)). Zum anderen können
Sie prüfen, ob es zu spezifizierten Nutzungsanforderungen überhaupt passende
Produktmerkmale gibt, beispielsweise zur Nutzungsanforderung "Der Nutzer muss am System
noch nicht untersuchte Patienten erkennen können" - eine Entsprechung an der
Benutzerschnittstelle wie eine farbliche Markierung oder eine Sortierung der Patienten. Zu den
Methoden zählen die Heuristische Evaluation, die eine Bewertung mit Hilfe von Experten
darstellt, und der Cognitive Walkthrough bei dem sich Experten in die Rolle der Benutzer
hineinversetzen.
Gesamtlehrplan
Eine erfolgreiche Verifizierung ist nicht hinreichend, um die Gebrauchstauglichkeit eines Produkts
nachzuweisen.
Nur Wiederholung und Vertiefung.
4.2. Regulatorische Forderungen

4.2.1. Regulatorische Anforderungen (Europa)
Die Gebrauchstauglichkeit rückt bei Audits zunehmend in den Vordergrund. Durch die
Harmonisierung der Norm DIN EN 62366 sind nun klare Anforderungen benannt, die die
Hersteller bei der Entwicklung und Schulung von Medizinprodukten einhalten müssen.
 Grundlegende Anforderung
 ZLG
4.2.1.4. Anforderungen der Medizinprodukterichtlinie
Lehrziele
M4-LE2.1-1-1 Aufbau der regulatorischen Landkarte kennen und die W W
Verweise zwischen den einzelnen Richtlinien,
Gesetzen und Normen verstehen.
M4-LE2.1-1-1 Die Anforderungen benennen können, welche die -- K1
Medizinprodukterichtlinie formuliert.
M4-LE2.1-1-1 Wissen, dass die Anforderungen an die -- K1
Gebrauchstauglichkeit im Anhang I der MDD mit den
grundlegenden Anforderungen zu finden sind und
durch die 2007/47/EC ergänzt wurden.
Die Medizinprodukterichtlinie fordert die Gebrauchstauglichkeit zumindest indirekt. In ihrem
Anhang I mit den grundlegenden Anforderungen verlangt sie u.a., dass
 Messskalen, Bedienungs- und Anzeigeeinrichtungen so ausgelegt sein müssen, dass sie unter
Berücksichtigung der Zweckbestimmung des Produkts ergonomischen Grundsätzen
entsprechen
 Risiken aufgrund ergonomischer Merkmale ausgeschlossen oder weitest möglich verringert
werden
 die Funktion von Bedienungs- und Anzeigeeinrichtungen auf den Produkten deutlich
angegeben sein muss
 visuell angezeigte Betriebs- oder Regelungsparameter für den Benutzer und gegebenenfalls
den Patienten verständlich sein müssen.
Die 2007/47, die die MDD ergänzt schreibt: "Die Produkte müssen so ausgelegt und hergestellt
sein, dass ihre Anwendung unter den vorgesehenen Bedingungen und zu den vorgesehenen
Zwecken weder den klinischen Zustand und die Sicherheit der Patienten noch die Sicherheit und
die Gesundheit der Anwender oder gegebenenfalls Dritter gefährdet, wobei etwaige Risiken im
Zusammenhang mit der vorgesehenen Anwendung gemessen am Nutzen für den Patienten
vertretbar und mit einem hohen Maß an Gesundheitsschutz und Sicherheit vereinbar sein
müssen. Dazu gehört
Gesamtlehrplan
 eine weitestgehende Verringerung der durch Anwendungsfehler bedingten Risiken aufgrund

der ergonomischen Merkmale des Produkts und der Umgebungsbedingungen, in denen das
Produkt eingesetzt werden soll (Produktauslegung im Hinblick auf die Sicherheit des
Patienten), sowie
 die Berücksichtigung der technischen Kenntnisse, der Erfahrung, Aus- und Weiterbildung
sowie gegebenenfalls der medizinischen und physischen Voraussetzungen der vorgesehenen
Anwender (Produktauslegung für Laien, Fachleute, Behinderte oder sonstige Anwender)."
4.2.1.5. Wiederholung: Verbindung zwischen Medizinproduktegesetz und Medizinprodukterichtlinie
Lehrziele
M4-LE2.1-2-1 Wissen, dass das Medizinproduktegesetzt die W W
grundlegenden Anforderungen der
Medizinprodukterichtlinie national übernimmt.
Das Medizinproduktegesetz fordert die Einhaltung der grundlegenden Anforderungen wie sie die
Medizinprodukterichtlinie benennt. Damit werden diese Anforderungen gesetzlich verpflichtend.
Nach Artikel 5 der Medizinprodukterichtlinie müssen die Mitgliedsstaaten, vertreten durch deren
benannte Stellen, die Einhaltung der grundlegenden Anforderungen vermuten, wenn die
entsprechenden harmonisierten Normen eingehalten werden.
4.2.1.6. Anforderungen an das Personal
Lehrziele
M4-LE2.1-3-1 Wissen, dass die ZLG verlangt, dass die Hersteller die -- K1
Qualifikation ihres Personals in Bezug auf die
gebrauchstauglichkeitsorientierte Entwicklung
nachweisen müssen.
Die ZLG fordert im EK-MED Beschluss 3.5 A 2, dass die Hersteller Personal mit fundierten
Kenntnissen in der Gebrauchstauglichkeit einzusetzen müssen; was im Rahmen von QM-Audits
entsprechend nachzuweisen ist. Dabei verlangt die ZLG Personal, das sich über Weiterbildungen
in Ergonomie oder vergleichbaren Ausbildungen durchlaufen oder sich die notwendigen
Kenntnisse durch Erfahrung erworben hat. Alternativ können die aus den Anforderungen der
Norm erwachsenden Aufgaben/Prüfungen auch im Unterauftrag an externe Unternehmen oder
Personen vergeben werden.
4.2.2. Normen und weitere Richtlinien
 PEMS
4.2.2.3. Harmonisierte Normen
Lehrziele
M4-LE2.2-1-1 Wissen, welche harmonisierten Normen es gibt, die K1 W
für die Gebrauchstauglichkeit relevant sind.
Es gibt derzeit zwei harmonisierte Normen, die EN 60601-1-6 und die DIN EN 62366. Die erste gilt
für programmierbare elektronische medizinische Systeme, die zweite für alle Medizinprodukte.
Da die Prinzipien einer gebrauchstauglichkeitsorientierten Entwicklung für alle interaktiven
Gesamtlehrplan
Systeme gelten, hat man die allgemeinere Norm, die DIN EN 62366, als die entscheidende
erkoren. Die EN 60601-1-6 bleibt zwar als Norm bestehen, besteht aber im normativen Teil nur
aus einem Verweis auf die DIN EN 62366.
4.2.2.4. Verbindungen zwischen den harmonisierten Normen
Lehrziele
M4-LE2.2-2-1 Wissen, dass die DIN EN 60601-1-6 und die DIN EN -- K2
62366 das Risikomanagement nach ISO 14971
normativ verlangen.
Sowohl die DIN EN 60601-1-6 als auch die DIN EN 62366 verweisen normativ auf die Norm ISO
14971 zum Risikomanagement. Der gebrauchstauglichkeitsorientierte Entwicklungsprozess geht
Hand in Hand mit dem Risikomanagementprozess. Es ist somit nicht möglich, den Forderungen
der DIN EN 62366 zu genügen, ohne ein normenkonformes Risikomanagement zu betreiben.
Damit wird klar, dass der Hauptfokus der DIN EN 62366 darauf liegt, Risiken zu vermeiden, die
durch mangelnde Gebrauchstauglichkeit bedingt sind. Es geht der Norm also weder darum,
Produkte zu fordern, die auf dem Markt erfolgreich oder von den Benutzern geschätzt werden,
noch darum, Anforderungen an die Ästhetik dieser Produkte zu benennen.
4.2.2.5. FDA Guidances
Lehrziele
M4-LE2.2-3-1 Die für Usability relevanten Guidance-Dokumente der -- K2
FDA dem Namen nach kennen und die wesentlichsten
Aspekte benennen können.
Die FDA hat eine Guidance mit dem Titel „Medical Device Use-Safety: Incorporating Human
Factors Engineering into Risk Management“ Diese Guidance ist jedoch in die Jahre gekommen.
Daher hat die FDA eine Guidance als Draft veröffentlicht mit dem Titel "Applying Human Factors
and Usability Engineering to Optimize Medical Device Design". Diese Guidance entspricht im
Moment am ehesten den Forderungen der FDA. Die Guidance fordert zwar keinen durchgängigen
Prozess wie die IEC 62366, beschreibt aber viele Verfahren zum Entwurf und Prüfen von Mensch-
Maschinen-Schnittstellen. Diese Prüfungen sollen vor allem bereits während des Designs
Anwendung finden. Das Dokument enthält konkrete Forderungen, die eine Validierung der
Usability in den USA nötig machen mit 15 Teilnehmern pro Nutzergruppe.
Als Hilfestellung hat die AAMI die Guideline AAMI HE 75 herausgebracht, die zu vielen Themen
der Gebrauchstauglichkeit praktische Hinweise gibt. Zudem hat die FDA die IEC 62366 als
recognized consensus standard anerkannt.
4.2.2.6. Weitere Normen
Lehrziele
M4-LE2.2-4-1 Weitere nicht harmonisierte, im Nutzungskontext der -- K2
Gebrauchstauglichkeit (von Software) relevante
Normen kennen und wesentliche Inhalte benennen
können.
Die im Nutzungskontext der Gebrauchstauglichkeit von Software (nicht nur medizinischer
Software) wichtigsten Normen, sind die der ISO 9241-Familie zur Ergonomie der Mensch-System-
Interaktion. Diese Normenfamilie beschreibt wichtige und ausführliche Empfehlungen, die auch
Gesamtlehrplan
auf medizinische Software angewendet werden sollten. Zu der Norm zählen u.a. die folgenden
Teile:
 Teil 1: Allgemeine Einführung (2002)
 Teil 2: Leitsätze zur Aufgabengestaltung (1993)
 Teil 11: Anforderungen an die Gebrauchstauglichkeit; Leitsätze (1999)
 Teil 12: Informationsdarstellung (2000)
 Teil 13: Benutzerführung (2000)
 Teil 14: Dialogführung mittels Menüs (2000)
 Teil 15: Dialogführung mittels Kommandosprachen (1999)
 Teil 16: Dialogführung mittels direkter Manipulation (2000)
 Teil 110: Grundsätze der Dialoggestaltung (2008)
 Teil 129: Leitlinien für die Individualisierung von User Interfaces (2011)
 Teil 143: Formulardialoge (2011)
 Teil 151: Leitlinien zur Gestaltung von Benutzungsschnittstellen für das World Wide Web
(2008)
 Teil 154: Dialogführung mittels Sprachdialogsystemen (2011)
 Teil 210: Prozess zur Entwicklung gebrauchstauglicher interaktiver Systeme; (2010; Englisch,
deutsche Übersetzung noch nicht verfügbar)
Die oben genannten Normen eigenen sich auch zur Erstellung von Checklisten als Bestandteil der
Spezifikation und Verifizierung der Gebrauchstauglichkeit.
Die Norm ISO/IEC TR 25060 beschreibt Anforderungen an die zu erzielenden Ergebnistypen eines
gebrauchstauglichkeitsorientierten Entwicklungsprozesses und ergänzt dadurch die DIN EN 62366
um konkret umsetzbare Hinweise.
4.3. Vom Nutzungskontext zu Nutzungsanforderungen

4.3.1. Grundlagen
Gebrauchstauglichkeit ist dann erreicht, wenn die Nutzungsanforderungen in einem bestimmten
Nutzungskontext erfüllt sind. Daher ist es entscheidend, diese Nutzungsanforderungen
zuverlässig zu erheben.
 Nutzungsanforderungen
 Nutzeranforderungen
 Systemanforderungen
4.3.1.3. Nutzungsanforderungen und Systemanforderungen
Lehrziele
M4-LE3.1-1-1 Die Begriffe Nutzungsanforderung, Nutzeranforderung K2 W
und Systemanforderung definieren, unterscheiden
und den Zusammenhang erläutern können.
Der DAkkS Leitfaden Usability definiert eine Nutzungsanforderung als „eine erforderliche
Benutzeraktion an einem interaktiven System, in einer die Tätigkeit beschreibenden Weise – nicht
in technisch realisierter Weise“. Diese Nutzungsanforderung muss erfüllt sein, damit der Benutzer
sein Nutzungsziel effizient (ohne Nutzungsprobleme) erreichen kann. Ein Beispiel für eine
Nutzungsanforderung ist: „Der Internist muss am System erkennen können, wie der
Hämoglobinwert des Patienten auf die Gabe von EPO reagiert.“ Das Nutzungsziel wäre hier die
Gesamtlehrplan
Anämie eines Patienten (medikamentös) zu verringern. (Eine Satzschablone wird später

vorgestellt.)
Hingegen spezifiziert eine Systemanforderung eine notwendige Fähigkeit oder Charakteristik des
Systems, die dazu geeignet ist, eine Nutzungsanforderung zu befriedigen. Das obige Bespiel
fortführend wäre eine Systemanforderung: „Das System muss den Hämoglobinwert kontinuierlich
berechnen.“
Nutzeranforderungen (manchmal auch als Stakeholder-Requirements umschrieben) umfassen die
Nutzungsanforderungen sowie weitere Anforderungen wie
 Gesetzliche Anforderungen
 Marktanforderungen
 Organisatorische Anforderungen
Nutzeranforderungen sollten keine konkrete Lösung verlangen, also keine Systemanforderungen
sein.
4.3.1.4. Die Beziehung von Nutzungs- und Systemanforderungen zur Verifizierung und Validierung
Lehrziele
M4-LE3.1-2-1 Die Nutzungsanforderungen und die K2 W
Systemanforderungen mit den zugehörigen Teststufen
Validierung mit Verifizierung in Beziehung setzen
können.
Unter Validierung versteht man die „Bestätigung durch Bereitstellung eines objektiven
Nachweises, dass die Anforderungen für einen spezifischen beabsichtigten Gebrauch oder eine
spezifische beabsichtigte Anwendung erfüllt worden sind“. Nur leicht umformuliert bedeutet
Validierung den Nachweis, dass ein Benutzer in einem gegebenen Nutzungskontext seine
Nutzungsziele effektiv („überhaupt“) und effizient (ohne Nutzungsprobleme) erreichen kann. Das
wiederum ist definitionsgemäß zentraler Gegenstand der Prüfung der Gebrauchstauglichkeit.
Die Überprüfung mit Benutzern, ob Nutzungsanforderungen erfüllt sind und das Produkt
gebrauchstauglich ist, entspricht der Validierung. Verifizierung in Bezug auf Gebrauchstauglichkeit
bedeutet, dass für jede Nutzungsanforderung ein passendes Produktmerkmal überhaupt
vorhanden ist sowie, dass beispielsweise Empfehlungen aus User-Interface-bezogenen Normen
umgesetzt sind und festgelegte Forderungen, beispielsweise die Systemanforderungen, erfüllt
worden sind.
4.3.1.5. Schwierigkeiten bei der Erhebung von Nutzungsanforderungen
Lehrziele
M4-LE3.1-3-1 Verstehen, dass Nutzungsanforderungen nicht direkt K2 W
erfragt werden können.
Menschen, unabhängig ob Experten oder Benutzer, tendieren dazu, Systemanforderungen oder
konkrete Lösungen zu formulieren. Henry Ford hat dazu Folgendes gesagt: „If I’d have asked my
customers what they wanted, they would have told me ‘A faster horse.’” Schnellere Pferde
entsprechen einer Systemanforderung („das System muss schneller werden“).
Systemanforderungen sind jedoch nur dann berechtigt, wenn eine zugehörige
Nutzungsanforderung existiert, die damit erfüllt wird.
Benutzerbefragungen sind somit kein geeigneter Weg, um Nutzungsanforderungen zu erheben.
Dazu nutzt man Kontextinterviews, die weiter unten vorgestellt werden.
Gesamtlehrplan
Nutzungsanforderungen sind in einem gegebenen Nutzungskontext konstant. Hingegen können

Systemanforderungen, also die Spezifikation von technischen Leistungen und erforderlichen
Charakteristiken, im Lauf der Zeit aufgrund technologischen Fortschritts wechseln. Aussagen wie
„die Anforderungen haben sich geändert“ sind somit ein Indiz dafür, dass die
Nutzungsanforderungen nicht systematisch und zutreffend erhoben wurden oder die
Anforderungen tatsächlich Systemanforderungen waren.
4.3.1.6. Projekterfolg und Nutzungsanforderungen
Lehrziele
M4-LE3.1-4-1 Erinnern, dass unzureichend erhobene K1 W
Nutzungsanforderungen einer der Hauptgründe für
das Scheitern von Projekten ist.
Der Standish Report hat Projekte untersucht, die entweder abgebrochen wurden oder den Zeit-
und Budgetrahmen um mindestens 189% überschritten, ohne dabei die notwendige
Benutzerakzeptanz zu erreichen. Unzureichend erhobene Anforderungen oder das
Anforderungsmanagement waren ursächlich für das Scheitern von etwa einem Drittel der
abgebrochenen und für die Hälfte der Projekte, die den Zeit- und Kostenrahmen weit
überschritten, ohne das Ziel vollständig zu erreichen.
Im Standish-Report finden sich diese Probleme unter Punkten subsumiert wie
 Unvollständige Anforderungen
 Unrealistische Anforderungen
 Nicht eindeutig formulierte Ziele
 Sich ändernde Anforderungen
 Unzureichende Einbeziehung von Nutzern
4.3.2. Nutzungskontext
 Benutzergruppen
 Personas
 Zweckbestimmung
 medizinische Indikation
4.3.2.4. Mehrere Benutzergruppen für ein Medizinprodukt
Lehrziele
M4-LE3.2-1-1 Verstehen, dass ein Medizinprodukt üblicherweise K2 W
mehr als eine Benutzergruppe hat und welche
Konsequenzen sich daraus ergeben.
Viele Medizinprodukte wie die meisten klinischen Informationssysteme sollen einer Vielfalt von
Benutzergruppen dienen. Beispielsweise zählen Pflegekräfte, Stationsärzte, Medizincontroller
und Radiologen zu den Nutzern eines KIS. Jede dieser Benutzergruppen hat spezifische Aufgaben
mit spezifischen Nutzungsanforderungen, die sich nur teilweise überlappen. Das bedeutet für die
Hersteller, dass sie zum einen die Nutzungsanforderungen mehrerer Benutzergruppen erheben
und ein dafür geeignetes System entwickeln müssen. Zum anderen dürfen sie keine
Gesamtlehrplan
unvertretbaren Risiken schaffen, die beispielsweise dadurch bedingt sind, dass die
Benutzungsschnittstelle für den einzelnen Benutzer unnötig viele Handlungsoptionen bietet oder
eine zu hohe Anpassbarkeit der Software die Komplexität, Wartbarkeit und Testbarkeit des
Produkts beeinträchtigt.
4.3.2.5. Benutzerprofile als Personas darstellen
Lehrziele
M4-LE3.2-2-1 Erinnern, dass Benutzerprofile mit Hilfe von Personas -- K2
beschrieben werden können.
Eine Persona ist eine Kurzbeschreibung („Steckbrief“) eines idealtypischen Vertreters einer
Benutzergruppe. Sie umfassen meist ein Foto und eine stichwortartige Beschreibung dieses
Vertreters. Zu dieser Beschreibung zählen, aus konkreten Daten extrahierte, prototypische
Beschreibungen
 des Alters
 der Ausbildung
 der Ziele
 der Sprachliche Fähigkeiten
 des Kulturellen und soziologischen Hintergrundes
 der Erfahrungen bei der Nutzung des Produkts oder eines vergleichbaren Produkts
 der Tätigkeiten im Nutzungskontext einschließlich der typischen Arbeitsbelastung und der zu
erwartenden Berufserfahrung
 der Funktion und Hierarchie innerhalb der Organisation
 der Körperlichen und geistigen Fähigkeiten und Einschränkungen
4.3.2.6. Zweckbestimmung, medizinische Indikation, bestimmungsgemäßer Gebrauch
Lehrziele
M4-LE3.2-3-1 Zweckbestimmung, medizinische Indikation und -- K2
bestimmungsgemäßen Gebrauch definieren und
unterscheiden können.
Die Zweckbestimmung von Medizinprodukten beschränkt sich auf den (medizinischen) Zweck, der
gemäß den Angaben des Herstellers mit dem Produkt erzielt werden soll. Beispielsweise zählt die
Entfernung von Giftstoffen aus dem Blut zur Zweckbestimmung eines Dialysegeräts oder die
Dokumentation der Fieberkurve zur Zweckbestimmung eines Krankenhausinformationssystems
(KIS). Üblicherweise beinhaltet die Zweckbestimmung Aussagen darüber, wie mit Hilfe des
Medizinprodukts Krankheiten, Verletzungen oder physiologische Vorgänge diagnostiziert,
überwacht oder behandelt werden.
Der bestimmungsgemäße Gebrauch umfasst weitere Tätigkeiten, die vom Hersteller mit dem
Produkt vorhergesehen sind - beispielsweise die Reinigung oder der Transport des Dialysegeräts
bzw. die Fernwartung des KIS.
Sowohl die Zweckbestimmung als auch der bestimmungsgemäße Gebrauch umfassen auch die
Festlegung, welche Benutzergruppen in welche Nutzungskontexten das Produkt nutzen
dürfen/sollen (und nicht nur wofür).
Die Begriffe „medizinische Indikation“ und „medizinischen Zweckbestimmung“ werden meist
synonym verwandt.
Anmerkung: Die DIN EN 62366 definiert ähnlich aber nicht identisch der obigen Darstellung und
der Definition der IEC 60601-1 den Begriff bestimmungsgemäßer Gebrauch als den normalen
Gesamtlehrplan
Gebrauch ohne Benutzungsfehler. Sie übersetzt den Begriff sowohl als „correct use“ als auch als
„intended use/intended purpose“, was nicht zwingend das Gleiche ist.
4.3.2.7. Beschreibungen der Patienten-Gruppe
Lehrziele
M4-LE3.2-4-1 Wissen, wie man die Patientenpopulation -- K2
charakterisiert.
Die Charakterisierung der Patientenpopulation sollte die Gesamtheit der Merkmale umfassen, die
diese Patientenpopulation von anderen Patientenpopulationen unterscheidet, z.B.:
 Alter
 Geschlecht
 Erkrankungen und Verletzungen, die im Nutzungskontext der Zweckbestimmung gelindert,
behandelt, überwacht oder diagnostiziert werden sollen
 Sonstiger Gesundheitszustand, beispielsweise Bewusstsein, Hör- und Sehfähigkeit
 Zurechnungsfähigkeit, Aufmerksamkeit, intellektuelle Fähigkeiten
Generell sind die Größen zu dokumentieren, die einen Einfluss auf die Nutzung des
Medizinprodukts und das davon ausgehende Risiko haben. Sind die Patienten gleichzeitig die
Benutzer, so sind die Nutzungsanforderungen für diese Benutzergruppe ebenfalls zu
dokumentieren.
4.3.2.8. Aspekte der Nutzungsbedingungen / Gebrauchsbedingungen
Lehrziele
M4-LE3.2-5-1 Die wichtigsten Aspekte einer Zweckbestimmung -- K2
aufzählen können. Die Besonderheiten von Software
nennen können.
Der Hersteller muss benennen, wie, durch wen, für wen und in welchem Nutzungskontext das
Medizinprodukt angewendet werden soll. Zu dieser „Spezifikation“ (gemäß Terminologie der DIN
EN 62366) zählen dazu:
 Das Benutzerprofil
 Das Patientenprofil
 Die vorgesehene medizinische Indikation (s.o.)
 Die vorgesehenen Gebrauchsbedingungen wie der Ort, die Häufigkeit des Gebrauchs, das
Stresslevel der Benutzer, die physikalischen Umgebungsparameter (z.B. Helligkeit,
Temperatur, etc.).
 Bei eigenständig laufender Software zählen auch die vorausgesetzte Hardware, Drittsoftware
und Schnittstellen zu anderen IT-Systemen zur Zweckbestimmung. Speziell bei
Bildschirmarbeitsplätzen spielen die Positionierung und die Umgebungshelligkeit eine Rolle.
Auch die physikalische Funktionsweise des Medizinprodukts muss Bestandteil der
Nutzungsbedingungen sein, was aber nicht spezifisch für Software ist.
4.3.3. Ableiten der Nutzungsanforderungen

 Erfordernis
Gesamtlehrplan
4.3.3.3. Nutzungsanforderungen ableiten

Lehrziele
M4-LE3.3-1-1 Die Schritte aufzählen können, um K2 W
Nutzungsanforderungen herzuleiten.
Nutzungsanforderungen lassen sich in der Regel nicht erfragen (s. M4-LE3.1-3). Daher bedarf es
eines systematischen Vorgehens, um diese abzuleiten. Dieses Vorgehen umfasst die folgenden
Schritte:
1. Nutzungskontext bestimmen (z.B. den Radiologen beim Befunden von CT-Bildern)
2. Nutzergruppen identifizieren
3. Kontextinterviews führen
4. Erfordernisse im Nutzungskontext identifizieren
5. Nutzungsanforderungen ableiten
4.3.3.4. Kontextinterviews
Lehrziele
M4-LE3.3-2-1 Faktoren für erfolgreiche Kontextinterviews benennen -- K1
können.
Der Erfolg von Kontextinterviews setzt voraus, dass die Benutzergruppen bekannt sind, deren
Nutzungskontext erhoben werden soll. Derjenige, der die Interviews führt, sollte geschult sein
und mit mindestens fünf repräsentativen Vertretern jeder Benutzergruppe (fünf) Einzelinterviews
führen. Diese Einzelinterviews sollten maximal 90 Minuten dauern. Der Interviewende soll nicht
Lösungen, sondern den Nutzungskontext erfragen. Beispiele für Leitfragen umfassen:
 Welche Aufgaben erledigen Sie wiederkehrend?
 Mit wem arbeiten Sie hierbei zusammen und wie?
 Wie führen Sie Ihre Aufgaben durch? Welche Hilfsmittel nutzen Sie hierbei?
 Welche Arbeitsergebnisse erzielen Sie hierbei?
 Welche Abweichungen gibt es vom normalen Ablauf? Wann treten diese auf?
 Wie bewerten Sie die Richtigkeit und Vollständigkeit Ihrer Arbeitsergebnisse?
 Woher wissen Sie, wann Ihre Arbeit erledigt ist? Wie beurteilen Sie die Qualität Ihrer Arbeit?
 Welchen Teil der Arbeit empfinden Sie als unnötig bzw. zu aufwändig?
Weitere Leitfragen finden sich im DAkkS Leitfaden Usability.
4.3.3.5. Formulierung von Erfordernissen
Lehrziele
M4-LE3.3-3-1 Den Begriff Erfordernis definieren können. K1 W
M4-LE3.3-3-1 Qualitätsmerkmale von Erfordernissen benennen K2 W
können. Wissen, wie man Erfordernisse formuliert.
Ein Erfordernis ist definiert [LEITFADEN] als eine notwendige Voraussetzung, die es ermöglicht,
den in einem Sachverhalt des Nutzungskontexts enthaltenen Zweck effizient zu erfüllen.
Gute Erfordernisse besitzen folgende Qualitätsmerkmale:
1. Sie stehen immer im Bezug zum Nutzungskontext und begründen das, was im
Nutzungskontext geschieht.
Gesamtlehrplan
2. Sie bestehen immer aus eine Zustand der gegeben sein muss, und dem Zweck, dem dieser
Zustand dient. Entsprechend sollten Sie formuliert sein als „Der [Rollenbezeichnung] muss
XYZ haben/wissen, um ZYX tun zu können.“ Ein Beispiel für ein Erfordernis lautet: „Der
Internist muss den Hämoglobinwert des Patienten kennen, um über die Fortführung der
Anämiebehandlung angemessen entscheiden zu können.“
3. Sie stehen noch nicht in Bezug zu einem zu entwickelnden System.
4. Sie sind unstrittig und für alle Beteiligten einer Benutzergruppe zutreffend.
4.3.3.6. Formulierung von Nutzungsanforderungen
Lehrziele
M4-LE3.3-4-1 Verstehen, wie man Nutzungsanforderungen K2 W
formuliert und bewertet.
Gute Nutzungsanforderungen zeichnen sich durch folgende Qualitätsmerkmale aus:
1. Sie beruhen auf einem Erfordernis
2. Sie formulieren noch keine konkrete Lösung
3. Sie formulieren die zu ermöglichende Handlung am User Interface im Sinne von „Der
Benutzer muss am System XXX eingeben/auswählen/erkennen können.
Benutzer können an interaktiven Systemen nur beobachtbare Handlungen durchführen, nämlich
eingeben und auswählen, oder kognitive Leistungen (erkennen, überblicken, unterscheiden)
erbringen.
4.4. Benutzungsschnittstelle
4.4.1. Benutzungsschnittstelle konzipieren
Benutzungsschnittstellen zu konzipieren, ist nicht die Aufgabe von Grafik-Designern, sondern
primär von Usability-Experten, insbesondere verantwortlich für das Interaktionsdesign und die
Informationsarchitektur.
 Hauptbedienfunktion
 Informationsarchitektur.
 Navigationsstruktur
4.4.1.3. Schritte zur Konzeption einer Benutzungsschnittstelle
Lehrziele
M4-LE4.1-1-1 Die Schritte benennen können, um eine -- K1
Benutzungsschnittstelle zu konzipieren.
Aus den Kontextinterviews leitet der Hersteller nicht nur die Nutzungsanforderungen ab, sondern
auch die zu unterstützenden Kernaufgaben. Für jede (durch das Medizinprodukt) zu
unterstützende Kernaufgabe wird dann ein Nutzungsszenario abgeleitet.
Ein Nutzungsszenario enthält
 die Vorbedingungen, die gegeben sind, bevor die Nutzung startet (normale und kritische),
und die Nachbedingung die gegeben ist, wenn die Nutzung beendet ist (Normalfall und
kritische Fälle)
 alle Teilaufgaben innerhalb der unterstützten Kernaufgabe
Gesamtlehrplan
 für jede Teilaufgabe alle Aktionen des Nutzers und die erwartungskonforme Reaktion des
Systems. So entsteht ein Drehbuch für die Benutzungsschnittstelle. Beispielsweise muss ein
Benutzer die Kernaufgabe „Werte sichern“ bearbeiten. Eine Teilaufgabe dabei besteht in der
Auswahl des Patienten. Im Rahmen dieser Teilaufgabe wählt der Benutzer aus der Liste der
Patienten einen bestimmten aus. Als Reaktion zeigt das System die demographischen Daten
dieses Patienten an. Somit sind Nutzungsszenarien die Basis für (technische) Use Cases (und
nicht umgekehrt wie oft beobachtet).
 Komponenten einer Benutzungsschnittstelle identifizieren
 Informationsarchitektur festlegen
 Navigationsstruktur festlegen
 Benutzungsschnittstelle entwerfen
 Benutzungsschnittstelle anhand eines Prototypen verifizieren und validieren
4.4.1.4. Semantische Komponenten einer Benutzungsschnittstelle
Lehrziele
M4-LE4.1-2-1 Die Komponenten einer Benutzungsschnittstelle -- K2
benennen können.
Zu den Komponenten einer Benutzungsschnittstelle zählen
 Nutzungsobjekte, beispielsweise die Liste von Patienten, ein einzelner Laborwert, die Liste
der Diagnosen usw.
 Werkzeuge, um die Nutzungsobjekte zu erzeugen, zu verändern, zu löschen,
 Wegweiser, die dem Benutzer helfen, User-Interface-Komponenten zu finden und auch
innerhalb von komplexen User-Interface-Komponenten zu navigieren. Beispiel für Wegweiser
sind Menüs, Menüeinträge, das Kontextmenü, Navigationsbäume.
 Rückmeldungen wie Warnungen, Hinweise oder Hinweise auf Fehler, die der Benutzer
quittieren muss.
 Statusinformationen, die zusätzliche Informationen über ein Nutzungsobjekt oder Werkzeug
liefern, beispielsweise, dass der Patient erfolgreich gespeichert wurde.
 Handlungsleitende Texte, wie z.B. Hilfe.
4.4.1.5. Spezifikation der Benutzungsschnittstelle
Lehrziele
M4-LE4.1-3-1 Beschreiben können, was eine Spezifikation der -- K2
Benutzungsschnittstelle umfasst.
Die Spezifikation der Benutzungsschnittstelle sollte umfassen:
 alle Nutzungsszenarien (Dialogablauf und Interaktionen, wie sie sich durch Flussdiagramm gut
darstellen lassen) einschließlich kritischer Vorbedingungen und Nachbedingungen. Dies
schließt häufige Szenarien ebenso ein wie vernünftigerweise vorhersagbare Szenarien für den
ungünstigsten Fall.
 eine Spezifikation der Nutzungsobjekte und Werkzeuge, die der Nutzer bei der
Aufgabenerledigung benötigt und anderen Komponenten
 einen interaktiv nutzbaren Prototyp
 alle Vorgaben für Größen, Positionen, Schriften, Farben, Grafiken („Gestaltungsrichtlinien“
und „Styleguide“)
4.4.1.6. Style Guide
Lehrziele
Gesamtlehrplan
M4-LE4.1-4-1 Anhand von Beispielen erläutern, was UI Style Guides, -- K2

Normen, Richtlinien beschreiben und fordern.
UI-Guidelines und die Normen wie die Familie ISO 9241 geben konkrete Richtlinien für die
Gestaltung der Benutzungsschnittstelle (z.B. Menüs, Formulare, Benutzerführung). Beispiele für
solche Richtlinien sind
 Menü-Elemente sind nach bekannten Konventionen oder Häufigkeit der Nutzung zu
strukturieren
 Die Größe der Schrift berechnet sich als gegebene Funktion des Sehabstands
 Buttons (an festen Orten) müssen über ein Symbol und (oder mindestens) einen Text
verfügen
 Pflichteingabefelder sind als solche markiert
 Farben dürfen nie als einziges Kodierungselement dienen
 Hierarchische Strukturen (z.B. Bäume, Menüs) sollen auf einer Hierarchieebene nicht mehr
als 8 Elemente haben
 Nicht editierbarer Text wird in schwarzer Schrift auf grauem Hintergrund angezeigt
 Ausgewählte Elemente sind als ausgewählt hervorgehoben
 Eingabefelder haben immer ein zugehöriges „Label“ mit einem eindeutig verständlichen Text
 Die Anzahl der Dialogschritte ist nur aus der Aufgabe hergeleitet
 Die Sprache lässt sich für die Benutzergruppe einstellen
 Rückmeldung sind eindeutig klassifiziert (informativ, warnend, Fehler)
 Fehlermeldungen müssen zuerst den Fehler, dann die Handlungsoptionen erklären
Styleguides wiederum beschreiben das genaue Aussehen von UI-Elementen und
Bildschirmabschnitten oder konkrete Töne.
4.4.1.7. Hauptbedienfunktionen
Lehrziele
M4-LE4.1-5-1 Erinnern, was die Hauptbedienfunktionen gemäß DIN -- K1
EN 62366 sind.
M4-LE4.1-5-1 Erinnern, weshalb die Hauptbedienfunktionen -- K1
relevant für die DIN EN 62366 sind.
Die DIN EN 62366 versteht unter den Hauptbedienfunktionen die Funktionen, die entweder
häufig benutzt werden oder die sicherheitskritisch sind. Beispiele für Hauptbedienfunktionen sind
 Bei einer Dialysemaschine: Blutflussraten-Einstellung
 Bei einem DICOM-Viewer: Körperstruktur-Vermessung
 Bei einem PDMS: Alarmgrenzen-Setzen
Mit Funktionen korrelieren meist ein oder mehrere UI-Elemente, insbesondere Nutzungsobjekte
und Werkzeuge.
Funktionen, die im Rahmen der Kernaufgabe zu bedienen sind, zählen zu den häufig benutzten
Funktionen und damit zu den Hauptfunktionen. Ob eine Funktion sicherheitskritisch ist, muss bei
der Risikoanalyse bewertet werden.
Die DIN EN 62366 fordert, dass überprüfbare Forderungen an die Gebrauchstauglichkeit der
Hauptbedienfunktionen gestellt werden.
4.4.2. Benutzungsschnittstelle und Risiken
Gesamtlehrplan
4.4.2.2. Entstehung von Gefährdungssituation durch Benutzerschnittstellen

Lehrziele
M4-LE4.2-1-1 Beispiele nennen können, wie eine -- K2
Benutzungsschnittstelle zu Gefährdungssituationen
beiträgt.
Beispiele
4.4.2.3. Benutzerprofil, Nutzungsbedingungen und Gefährdungen
Lehrziele
M4-LE4.2-2-1 Beispiele geben, wie das Benutzerprofil und die -- K2
Nutzungsumgebung die Wahrscheinlichkeit von
Gefährdungen beeinflussen:
Beispiel: Ein Defibrillator, der sich im hellen OP und durch einen erfahrenen Anästhesisten
angewendet bewährt hat, kann in den Händen eines Laien, der in einer dunklen Winternacht mit
Handschuhen einen bewusstlosen Menschen wiederbeleben muss, zu einem unbeherrschbaren
Risiko mutieren:
 Der Laie weiß nicht so genau, wann eine Reanimation notwendig ist und wann sie erfolgreich
war.
 Im Dunkeln sind ggf. Hinweise, „Labels“ und Informationen auf dem Gerät nicht mehr
ausreichend gut lesbar.
 Mit Handschuhen ergeben sich andere Anforderungen an die Gestaltung der
Benutzungsschnittstelle, beispielsweise die Größe betreffend.
4.5. Usability Verifizierung und Validierung

4.5.1. Grundlagen
Es gibt mehrere Verfahren, um Informationen über die Gebrauchstauglichkeit von interaktiven
Systemen zu sammeln. Aber nicht alle sind geeignet, um die Gebrauchstauglichkeit auch
tatsächlich zu verifizieren und/oder validieren.
 Inspektion
4.5.1.3. Prüfmethoden
Lehrziele
M4-LE5.1-1-1 Verschiedene Prüfmethoden zur Verifizierung und K2 --
Validierung der Gebrauchstauglichkeit benennen
können.
Man unterscheidet drei Klassen an Methoden, um die Gebrauchstauglichkeit zu prüfen:
1. Inspektionen: Bei den Inspektionen prüfen Experten die Benutzungsschnittstelle sowohl
anhand von Checklisten und Style Guides als auch darauf, ob die Nutzungsanforderungen
grundsätzlich erfüllt sind.
Gesamtlehrplan
2. Beobachtungen von Benutzern: Hier hat sich besonders die teilnehmende Beobachtung bei
der Erledigung der Kernaufgaben bewährt.
3. Benutzerbefragungen: Hierbei unterscheidet man die qualitative Benutzerbefragung, in der
Regel Einzelinterviews, und die quantitative Benutzerbefragung über standardisierte
Fragebögen.
4.5.1.4. Ziele der Prüfungen und Prüfkriterien
Lehrziele
M4-LE5.1-2-1 Ziele der Prüfmethoden kennen. K2 W
M4-LE5.1-2-1 Erinnern, dass eine Prüfung ohne Prüfkriterien nicht K1 W
möglich ist und dass sich die Prüfkriterien für die
verschiedenen Prüfverfahren unterscheiden.
M4-LE5.1-2-1 Verstehen, dass sich die Prüfkriterien für die K2 W
verschiedenen Prüfverfahren unterscheiden.
Die Prüfungen der Gebrauchstauglichkeit haben das Ziel festzustellen, inwieweit das entwickelte
Produkt über die spezifizierten Eigenschaften verfügt (-> Verifizierung) und ob die Benutzer ihre
Nutzungsziele effektiv, effizient und zufriedenstellend erreichen können (-> Validierung).
Bei der Verifizierung müssen folglich die Kriterien benannt sein, anhand der Prüfer vorgehen
muss. Dies gilt auch für die Validierung, wobei die Kriterien die Erfüllung Nutzungsanforderungen
zwingend einschließen. Ohne dokumentierte Nutzungsanforderungen wird mit hoher
Wahrscheinlichkeit nicht nur die Entwicklung, sondern auch die Validierung scheitern, da dort
dann die Nutzungsanforderungen erst entdeckt werden.
Es kann durchaus sein, dass die Verifizierung erfolgreich ist und Validierung scheitert. Das
Gegenteil beobachtet man seltener, weil eine erfolgreiche Verifizierung als notwendige aber nicht
hinreichende Voraussetzung für ein gebrauchstaugliches Produkt und damit für die Validierung
betrachtet wird.
4.5.2. Verifizierung
 Usability Labor
4.5.2.2. Inspektionen
Lehrziele
M4-LE5.2-1-1 Erklären, wie Inspektionen zur Verifizierung der K2 W
Gebrauchstauglichkeit dienen.
Idealerweise prüfen bei Inspektionen mehrere Experten unabhängig voneinander die
Benutzungsschnittstelle entweder auf Einhaltung der Forderungen von Checklisten, Heuristiken,
Normen und Style Guides oder daraufhin, ob die Nutzungsanforderungen erfüllt sind. Jeder
Experte notiert die von ihm gefundenen Abweichungen. In einem zweiten Schritt tragen die
Experten ihre Beobachtungen zusammen, diskutieren diese und erstellen einen Prüfbericht.
4.5.2.3. Prinzipien des Oberflächendesigns
Lehrziele
M4-LE5.2-2-1 Beispiele für allgemeine Prinzipien für die -- K2
Informationsdarstellung benennen können.
M4-LE5.2-2-1 Beispiele für allgemeine Prinzipien für die -- K2
Gesamtlehrplan
Dialoggestaltung benennen können.

M4-LE5.2-2-1 Gestaltgesetze kennen und Beispiele geben können. -- K2
Die Normen, Heuristiken und Style Guides beschreiben allgemeingültige Grundsätze, sowie
zugehörige Empfehlungen, die für die Prüfung durch Inspektionen angewendet werden können.
Dazu zählen insbesondere die in der DIN EN ISO 9241-110 beschriebenen sieben Prinzipien der
Dialoggestaltung:
1. Aufgabenangemessenheit: keine überflüssigen Schritte, keine überflüssige Information
2. Selbstbeschreibungsfähigkeit: notwendige Information in jedem Dialogschritt vorhanden
3. Erwartungskonformität: Systemreaktion entspricht immer dem zu erwartenden Verhalten
4. Lernförderlichkeit: System erschließt sich mit dem erforderlichen Aufgabenwissen von selbst
5. Steuerbarkeit: erforderliche Richtungen können zu jedem Zeitpunkt eingeschlagen werden
6. Fehlertoleranz: Fehler werden durch geeignete Gestaltung vermieden und (trotzdem)
gemachte Fehler können mit minimalem Aufwand durch den Nutzer behoben werden
7. Individualisierbarkeit: System kann wo erforderlich durch den Nutzer selbst angepasst
werden
sowie die in der DIN EN ISO 9241-12 beschriebenen sieben Prinzipien der
Informationsdarstellung:
1. Klarheit (Eindeutigkeit): Der Informationsinhalt wird schnell und genau vermittelt.
2. Unterscheidbarkeit: Die angezeigte Information kann genau unterschieden werden.
3. Kompaktheit: Den Benutzern wird nur jene Information gegeben, die für das Erledigen der
Aufgabe notwendig ist.
4. Konsistenz: Gleiche Information wird innerhalb der Anwendung entsprechend den
Erwartungen der Benutzer stets auf gleiche Art dargestellt.
5. Erkennbarkeit (Entdeckbarkeit): Die Aufmerksamkeit des Benutzers wird zur benötigten
Information gelenkt.
6. Lesbarkeit: Die Information ist leicht zu lesen
7. Verständlichkeit: Die Bedeutung ist leicht verständlich, eindeutig, interpretierbar und
erkennbar.
und die Gestaltgesetze:
 Gesetz der Nähe: User Interface Elemente, die räumlich nah beieinander sind, werden als
zusammengehörig wahrgenommen.
 Gesetz der Ähnlichkeit: ähnlich sehende Elemente werden eher als zusammengehörig erlebt
als einander unähnlich sehende. Die Ähnlichkeit kann hierbei auf Helligkeit, Farbe,
Orientierung, Größe und/oder Form bezogen sein.
 Gesetz der Kontinuität: Die horizontale Orientierung und vertikale Orientierung wird für den
Benutzer erleichtert (so wenig „Fluchtlinien“ wie möglich). Das User Interface wirkt
„aufgeräumt“.
Um diesen Prinzipien zu entsprechen gibt es zahlreiche Empfehlungen in der Normenreihe DIN EN
ISO 9241, wie sie Style Guides und Gestaltungsgrundsätze formulieren. Beispiele für letztere sind:
 Apple iOS Human Interface Guidelines
 Apple OS X Human Interface Guidelines
 „Google Design“  (z.B. „Material Design“)
 UI and User Experience Guidelines – Windows 8.1
 Guidelines for Windows Runtime apps
4.5.2.4. Verifizierungsbericht
Lehrziele
Gesamtlehrplan
M4-LE5.2-3-1 Beschreiben, welche Elemente ein -- K1

Verifizierungsbericht enthält.
Ein Verifizierungsbericht sollte die festgestellten vorhersagbaren Nutzungsprobleme beschreiben,
jeweils die dabei verletzte Regel (z.B. auch Checklisten, Style Guides, Normen) nennen und die
Auswirkungen auf den Benutzer bzw. entstehenden Risiken dokumentieren. Diese Auswirkungen
lassen sich auch nach Schwere priorisieren.
Der Prüfbericht muss sich auf eine konkrete Version der verifizierten Software beziehen und die
Schritte zum Reproduzieren, bzw. die Bildschirmseite, auf die Bezug genommen wird,
beschreiben.
Beispiel
1. Software: Retro-KIS, Version 7.1.3, Bildschirm „Patienten suchen“
2. Nutzungsproblem: Die Suche liefert nur den ersten Patienten zurück, der den Suchkriterien
genügt.
3. Verletztes Prinzip: Erwartungskonformität
4. Auswirkungen: Dem Benutzer fällt möglicherweise nicht auf, dass es mehrere Patienten mit
den Suchkriterien (z.B. dem Vor- und Nachnamen) gibt, weshalb er einen falschen Patienten
auswählt.
5. Schweregrad: kritisch
4.5.2.5. Grenzen der Verifizierung
Lehrziele
M4-LE5.2-4-1 Die Grenzen der Verifizierung kennen. -- K2
Bei einer Verifizierung prüfen die Inspektoren „nur“, ob es zu Kriterien passende
Produktmerkmale gibt, die für die Gebrauchstauglichkeit notwendig sind. Ob wirkliche Benutzer
mit dem Produkt ihr Nutzungsziel tatsächlich erreichen, also eine hinreichende Prüfung der
Gebrauchstauglichkeit, ist Gegenstand der Validierung.
4.5.3. Validierung
4.5.3.2. Beteiligung der Benutzerzielgruppe
Lehrziele
M4-LE5.3-1-1 Wissen, dass die DIN EN IEC 62366:2008 eine K1 W
Validierung der Gebrauchstauglichkeit verlangt, die
IEC 62366:2015 hingegen formative und summative
Bewertungen.
M4-LE5.3-1-1 Sich bewusst sein, dass die DIN EN 62366 die K1 W
Einbeziehung repräsentativer Benutzer verlangt.
Die DIN EN 62366:2008 verlangt eine Validierung einschließlich eines Validierungsplans, der die
Beteiligung einer repräsentativen Gruppe vorgesehener Benutzer beinhaltet. Dies
Benutzergruppe oder Benutzergruppen müssen denen entsprechen, die in der Zweckbestimmung
genannt sind.
Die IEC 62366:2015 überlässt dem Hersteller die Entscheidung über die Methoden, mit der die
Gebrauchstauglichkeit geprüft wird, verlangt aber Bewertungen der Gebrauchstauglichkeit
während und am Ende der Entwicklung (formative und summative Bewertung).
Gesamtlehrplan
4.5.3.3. Gebrauchsumgebung
Lehrziele
M4-LE5.3-2-1 Verstehen, was eine Gebrauchsumgebung ausmacht -- K2
und wie ein Usability Labor aufgebaut sein muss.
Die DIN EN 62366 verlangt weiter, dass der Validierungsplan die Validierung in einer echten
Gebrauchsumgebung, einer simulierten Gebrauchsumgebung oder in einem Usability Labor
vorsieht. Ein Usability Labor besteht üblicherweise aus einem Versuchsraum und einem
Beobachtungsraum. Im Versuchsraum sitzen der Proband und der Testleiter des Labors. Der
Proband wird mit einer Kamera und mit einem Mikrofon aufgezeichnet, ebenso alle Aktionen, die
er mit der Software ausführt (eingeben, auswählen). Im Beobachtungsraum sitzen Beobachter,
die kritische Nutzungssituationen direkt protokollieren (z.B. dass eine erforderliche Information
nicht gefunden wurde) sowie Vertreter des Herstellers, die den Probanden und dessen
Handlungen beobachten.
4.5.3.4. Methodik des Usability-Tests
Lehrziele
M4-LE5.3-3-1 Verstehen, dass die Gebrauchstauglichkeit nur K2 W
validiert werden kann, wenn repräsentative Benutzer
in einer repräsentativen Nutzungsumgebung ihre
Nutzungsziele nachweislich erreichen.
Der objektive Nachweis, dass Benutzer ihr Nutzungsziel in einem definierten Nutzungskontext
tatsächlich erreichen, lässt sich nur durch Beobachtung von repräsentativen Vertretern der
Benutzergruppe in einer echten oder einer vergleichbaren Gebrauchsumgebung erbringen. Diese
teilnehmende Beobachtung entspricht somit der Validierung.
4.5.3.5. Validierungsplan
Lehrziele
M4-LE5.3-4-1 Die Elemente eines Validierungsplans kennen -- K1
Der Validierungsplan muss nicht nur vorgeben, welche Benutzer in welcher Gebrauchsumgebung
das Medizinprodukt validieren, sondern auch wie diese Validierung erfolgt. Dafür werden dem
Probanden Aufgaben gestellt, die die Erreichung von bestimmten Zielen fordern. Diese Aufgaben
sind so ausgelegt, dass der Proband die Nutzungsszenarien ausführt, jedoch keine Schritt-für-
Schritt-Anleitung erhält. Wichtig ist zudem, dass der Proband die Szenarien selbständig und ohne
Hilfe durchläuft.
Wichtige Element sind:
 Zweck und Ziel des Tests
 Eigenschaften der Teilnehmer
 Testmethode
 Liste der Aufgaben, die sicherstellen, dass die Nutzer alle häufigen und alle im ungünstigsten
Fall vorhersehbaren Nutzungsszenarien durchlaufen
 Erfolgskriterien, ob eine Aufgabe erfüllt wurde, wozu auch die Zeit bis zum Abbruch der
Aufgabe gehört
 Beschreibung der Testumgebung
 Logistik des Testablaufs wie Geheimhaltungsvereinbarung, Belohnung der Teilnehmer, etc.
 Aufgaben des Moderators
Gesamtlehrplan
 Art und Struktur des Berichts

4.5.3.6. Validierungsbericht
Lehrziele
M4-LE5.3-5-1 Elemente eines Validierungsbericht beschreiben -- K2
können.
Der Validierungsbericht muss wieder die Software(-version) eindeutig identifizieren. Weiter sollte
er enthalten:
 Die geprüften Nutzungsszenarien (also die Kern- oder Teilaufgabe) und bei welchen
Nutzungsprobleme auftraten.
 Die Zeit, die einzelne Nutzer gebraucht haben.
 Ob die Akzeptanzkriterien erreicht wurden.
 Eine Beschreibung, was der Benutzer tat und wie das System reagierte
 Die nicht erfüllte Nutzungsanforderung
 Ggf. eine verletze Regel der allgemeinen Prinzipien und Grundsätze (M4-LE5.2-2)
 Ggf. eine Priorisierung bezgl. der Auswirkung des Nutzungsproblems (Ein standardisiertes
Verfahren hierzu ist im DAkkS Leitfaden Usability enthalten)
 Ggf. Einen Verbesserungsvorschlag bzw. Vorschlag zum Umgang mit dem Nutzungsproblem
4.6. Sonstiges
4.6.1. DIN EN 62366
4.6.1.2. Der gebrauchstauglichkeitsorientierte Entwicklungsprozess nach DIN EN 62366:2008
Lehrziele
M4-LE6.1-1-1 Die Schritte des gebrauchstauglichkeitsorientierten -- K2
Entwicklungsprozesses gemäß DIN EN 62366
beschreiben können.
M4-LE6.1-1-1 Änderungen durch DIN EN 62366:2008 + A1:2015 -- K1
kennen
M4-LE6.1-1-1 Wesentliche Änderungen durch die IEC 62366-1:2015 -- K1
kennen.
Die DIN EN 62366 beschreibt den Prozess, der durchlaufen werden muss, um gebrauchstaugliche
Produkte zu entwickeln. Dieser Prozess kann iterativ sein, muss aber die folgenden Aktivitäten
enthalten:
 Spezifizieren, wie das Medizinprodukt zu verwenden ist.
 Die häufig benutzten und die sicherheitskritischen Funktionen bestimmen, welche zusammen
die Hauptbedienfunktionen darstellen.
 Die Gefährdungen und Gefährdungssituationen bestimmen, die von den
Hauptbedienfunktionen ausgehen.
 Die Nutzungsszenarien bestimmen, insbesondere die häufigen und diejenigen für den
ungünstigsten vorhersagbaren Fall.
 Spezifizieren, welche gebrauchstauglichkeitsbezogenen Merkmale das Produkt erfüllen muss.
Dies könnten beispielsweise die Vorgaben aus den Normen und Styles Guides sein.

Gesamtlehrplan

 Die Benutzungsschnittstelle gemäß den Vorgaben entwickeln, verifizieren und validieren.
Mit dem „Amendement I“ führt die Norm das Konzept der UOUP (Benutzerschnittstelle
unbekannter Herkunft – User Interface of Unknown Provenance“) ein. Dieser gibt die Möglichkeit,
dass für ältere „Benutzeroberflächen“, die vor der Veröffentlichung der IEC 62366:2007
entworfen wurden und die sich im Feld als unkritisch erwiesen haben (was durch Daten aus der
Marktbeobachtung zu belegen ist), eine nachträgliche Spezifikation, Verifizierung und Validierung
verzichtet werden kann. Auf die Identifikation der Hauptbedienfunktionen und eine
Risikobewertung dürfen die Hersteller nicht verzichten.
Die IEC 62366-1:2015 führt weitergehende Änderungen ein. Dazu zählen:
 Die Hauptbedienfunktionen sind nur noch als die sicherheitsbezogenen Funktionen definiert,
nicht mehr auch als die häufig benutzten
 Die Norm fordert statt einer Verifizierung und Validierung der Gebrauchstauglichkeit
formative und summative Bewertungen.
 Im Rahmen des Risikomanagements müssen insbesondere die sicherheitsbezogenen
Benutzungsszenarien betrachtet werden (der Fokus verschiebt sich von den
Bedienfunktionen auf die Benutzungsszenarien).
 Die Kapitel zu den Trainings- und Begleitmaterialien wurden aufgelöst und in den “normalen”
Usability Prozess integriert.
4.6.1.3. Zusammenspiel mit ISO 14971
Lehrziele
M4-LE6.1-2-1 Beschreiben können, wie die ISO 14971 und die DIN -- K2
EN 62366 zusammenspielen.
Der Fokus der DIN EN 62366 liegt darauf, Risiken zu beherrschen, die durch mangelnde
Gebrauchstauglichkeit verursacht sind. Es geht konkret um die Umsetzung der
Nutzungsanforderungen die sich auf den Grundsatz „Fehlertoleranz“ beziehen. Entsprechend
spielt die Norm eng mit der ISO 14971 zusammen:
 Die Spezifikation, wie das Medizinprodukt zu verwenden ist (Kapitel 5.1 der DIN EN 62366),
muss in den bestimmungsgemäßen Gebrauch (Kapitel 4.2 der ISO 14971) einfließen.
 Die Gefährdungen, die laut ISO 14971, Kapitel 4.3 zu ermitteln sind, müssen durch die
Gefährdungen ergänzt werden, die beim gebrauchstauglichkeitsorientierten
Entwicklungsprozess (DIN EN 62366, Kapitel 5.3) identifiziert werden und vice versa.
 Wenn die Nutzungsanforderungen umgesetzt und Gebrauchstauglichkeit erreicht sind (durch
Validierung nachzuweisen), kann geprüft werden, ob durch diese Maßnahmen zur Steigerung
der Gebrauchstauglichkeit neue Gefährdungen entstanden (ISO 14971, Kapitel 6.6).
 Maßnahmen zur Reduktion des Risikos sind aus Sicht beider Normen zu dokumentieren und
deren Umsetzung und Wirksamkeit zu verifizieren.
 Lassen sich die Risiken nicht im gewünschten Maße reduzieren, muss eine Risiko-
Nutzenabwägung, bei das Medizinprodukt doch als akzeptabel erklärt werden könnte, im
Rahmen der ISO 14971 und der DIN EN 62366 erfolgen.
4.6.1.4. Anormaler Gebrauch
Lehrziele
M4-LE6.1-3-1 Erinnern, dass die DIN EN 62366 keine Vorgaben für -- K1
den anormalen Gebrauch gibt (s. A2, 5. Abschnitt)
Gesamtlehrplan
Während die ISO 14971 verlangt, auch den vorhersagbaren Missbrauch zu untersuchen,
beschränkt sich die DIN EN 62366 auf den Nutzer der das Medizinprodukt gemäss seiner
Zweckbestimmung anwendet. Die Risiken, die von diesem vorhersagbaren Missbrauch ausgehen,
sind aber gemäß ISO 14971 dennoch zu analysieren, zu bewerten und ggf. zu beherrschen.
4.6.2. Dokumentation
4.6.2.2. Prüfung der Einhaltung von normativen Anforderungen
Lehrziele
M4-LE6.2-1-1 Sich bewusst sein, dass die Einhaltung der DIN EN -- K1
62366 durch Inspektion der
Gebrauchstauglichkeitsakte erfolgt.
M4-LE6.2-1-1 Wissen, dass die Gebrauchstauglichkeitsakte nach DIN -- K1
EN 62366 nicht als physische Akte vorliegen muss.
Was nicht dokumentiert ist, existiert (für einen Auditor) nicht. Entsprechend sind alle Aktivitäten
in der Gebrauchstauglichkeitsakte zu dokumentieren. Dabei muss die Gebrauchstauglichkeitsakte
(vergleichbar der Risikomanagementakte) nicht als physische Akte oder als elektronische Akte
beispielsweise in Form eines Verzeichnisses in einem Dateisystem existieren. Es genügt, wenn der
Hersteller im Rahmen des Audits die Dokumente in angemessener Zeit beschaffen kann.
4.6.2.3. Inhalte der Gebrauchstauglichkeitsakte
Lehrziele
M4-LE6.2-2-1 Die Dokumente und Inhalte der -- K1
Gebrauchstauglichkeitsakte benennen können.
Die Gebrauchstauglichkeitsakte sollte umfassen:
 Die Spezifikation der Anwendung
 Die Liste der häufig benutzen und der sicherheitskritischen Funktionen
 Die Spezifikation der Gebrauchstauglichkeit einschließlich der Benutzungsszenarien (auch im
ungünstigsten Fall), ggf. Verweise auf Style Guides oder Normen, sowie zu erfüllende
Nutzungsanforderungen. Damit enthält die sogenannte Spezifikation der
Gebrauchstauglichkeit die Kriterien für Validierung und die Verifizierung der
Gebrauchstauglichkeit.
 Validierungsplan einschließlich der Methoden zur Validierung, der Benutzungsszenarien
(welche die Hauptbedienfunktionen beinhalten müssen) sowie der Benutzer
 Validierungs- und ein Verifizierungsbericht(e)
 Begleitpapiere
 Schulungsmaterial
Im Rahmen des Risikomanagements müssen als Teil der Gebrauchstauglichkeits-Akte beschrieben
sein
 Die Risiken, die durch (mangelnde) Gebrauchstauglichkeit verursacht werden, einschließlich
der Risiken, die durch Benutzungsfehler verursacht werden
 Maßnahmen, die zur Beherrschung der von mangelnder Gebrauchstauglichkeit ausgehenden
Gefährdungen getroffen werden
 Eine Bewertung des Restrisikos
4.6.2.4. Dokumentation nach IEC 25060
Gesamtlehrplan
Lehrziele
M4-LE6.2-3-1 Die Dokumente erinnern, die die IEC 25060 fordert, -- K1
und diese den Dokumenten der
Gebrauchstauglichkeitsakte zuordnen können.
Sowohl die ISO 9241 als auch die IEC 25060 beschreiben die Dokumente, die bei der Entwicklung
gebrauchstauglicher Produkte zu verfassen sind. Diese decken sich teilweise mit denen der DIN
EN 62366.
Gesamtlehrplan
5. Curriculum Qualitäts- und

Dokumentenmanagement
5.1. Qualitätsmanagement
5.1.1. Prozessorientierter Ansatz
In der Norm ISO 13485 werden die Anforderungen an ein Qualitätsmanagementsystem (QM-
System) festgelegt.
 Qualitätsmanagementsystem
 Produktrealisierung
 Leitung
 Lenkungsinstrument
 Qualitätsmanagementsystem
 Produktrealisierung
 Leitung
 Lenkungsinstrument
5.1.1.4. Prozessorientierter Ansatz
Lehrziele
M5-LE1.1-1-1 Wissen, dass die ISO 13485 eine Prozessnorm ist K1 --
Die ISO 13485 ist eine Prozessnorm. Jeder Vorgang, der Anforderungen zu Ergebnissen
verarbeitet, kann als Prozess mit Aufgaben und Aktivitäten angesehen werden. Damit eine
Organisation wirksam funktioniert, muss sie zahlreiche miteinander verknüpfte Prozesse
definieren und lenken. Die Prozesse sind mit einander verzahnt, wobei Ergebnisse eines Prozesses
als direkter Input für einen anderen Prozess dienen.
Die Gesamtheit dieser Prozesse einschließlich der Schnittstellen dieser Prozesse kann als
Prozessmodell der Organisation verstanden werden. Die wesentlichen Sachverhalte, die in einem
Prozessmodell abgebildet werden sollen, werden in der Norm in den Kapiteln 5 bis 8 beschrieben.
 Kapitel 5: Verantwortung der Leitung
 Kapitel 6: Management von Ressourcen
 Kapitel 7: Produktrealisierung
 Kapitel 8: Messung, Analyse und Verbesserung
Die Leitung (5) muss für die Organisation eine angemessene Qualitätspolitik festlegen und die
Qualitätsziele planen, ein funktionierendes QM-System implementieren und dessen Wirksamkeit
sicherstellen. Damit das QM-System gelebt werden kann, muss die Leitung die entsprechenden
Ressourcen (6) wie Personal, Infrastruktur, Arbeitsumgebung etc. zur Verfügung stellen. Die
Organisation muss für die Produktrealisierung (7) entsprechende Prozesse und Aktivitäten
planen, die geeignet sind um Produkte mit der geforderten Qualität herzustellen. Dazu gehören
auch Aktivitäten bezgl. Risikomanagement. Die Qualität der Produkte sowie die Zufriedenheit der
Kunden werden durch Messung und Analyse (Kapitel 8) mit geeigneten Kennzahlen bestimmt.
Gesamtlehrplan
Diese Kennzahlen stehen der Leitung (Kapitel 5) als Lenkungsinstrument zur Verfügung. Dadurch
ergibt sich ein geschlossener Kreis (PDAC-Modell), dessen Leistungsfähigkeit regelmäßig ermittelt
wird.
5.1.2. Dokumentationsanforderungen an das Qualitätsmanagementsystem
5.1.2.2. Dokumentationsanforderungen an das Qualitätsmanagementsystem
Lehrziele
M5-LE1.2-1-1 Die Dokumentationspyramide eines K1 --
M5-LE1.2-1-1 Bestandteile der Dokumentation des K1 --
M5-LE1.2-1-1 Inhalt des QM-Handbuchs kennen. K1 --
M5-LE1.2-1-1 Kenntnis der zu dokumentierenden Verfahren nach K1 --
ISO 9001 und ISO 13485.
M5-LE1.2-1-1 Unterschied zwischen Dokument und Aufzeichnung K2 W
verstehen.
M5-LE1.2-1-1 Zusätzliche Anforderungen an die Dokumentation im -- K1
Software-Entwicklungsprozess aus der ISO 13485 für
Software-Entwickler kennen.
M5-LE1.2-1-1 Zusammenhänge zwischen ISO 13485 und IEC 62304 -- K2
bezogen auf Dokumentenmanagement verstehen.
Die Einhaltung der Norm wird durch Prüfung der Dokumentation geprüft. Daher sind
Dokumentationsanforderungen zentral. Die Norm fordert die folgende Dokumentation:
 eine dokumentierte Qualitätspolitik und Qualitätsziele,
 ein Qualitätsmanagement-Handbuch,
 verschiedene dokumentierte Verfahren,
 jegliche Dokumentation, die die Organisation zur Sicherstellung der wirksamen Planung,
Durchführung und Lenkung ihrer Prozesse benötigt,
 umfängliche Aufzeichnungen, die zur Aufrechterhaltung des QM-Systems erforderlich sind
und
 jede andere Dokumentation, die durch nationale und regionale Regularien festgelegt ist
Das Dokumentationssystem kann man sich am besten als Pyramide vorstellen. Die oberste Ebene
enthält dann die Qualitätspolitik sowie das QM-Handbuch mit den folgenden Themen:
 Anwendungsbereich des QM-Systems
 Dokumentierte Verfahren oder Verweise darauf
 Beschreibung der Wechselwirkung der Prozesse des QM-Systems
Für jedes Medizinprodukt, das der Hersteller in Verkehr bringt, wird eine Akte gefordert, in der
die Spezifikationen an dieses Produkt aufgeführt sind. Diese Spezifikationen müssen den
gesamten Herstellungsvorgang einschließlich der Installation und der Wartung beschreiben.
Die dokumentierten Verfahren bilden die zweite Ebene. Diese Beschreibungen werden
üblicherweise in eigenen Dokumenten gepflegt werden, um flexible Änderung und Verteilung zu
ermöglichen. Zusätzlich der ISO 9001 genannten zu dokumentierenden Verfahren werden in der
ISO 13485 weitere zu dokumentierende Verfahren genannt. Dies sind Verfahren zur
 Sicherstellung der benötigten Arbeitsumgebung,
 Sicherstellung der Konformität eingekaufter Produkte,
Gesamtlehrplan
 Entwicklungsplanung,
 Produktion und Dienstleistungserbringung,
 Instandhaltung,
 Validierung eingesetzter Software,
 Sicherstellung der Rückverfolgbarkeit,
 Sicherstellung der Konformität von Produkten während der Verarbeitung,
 Sicherstellung der Konformität von Produkten mit begrenzter Haltbarkeit,
 Sicherstellung der Korrektheit von Messungen,
 Rückmeldungssystem und
 Erfassung und Analyse von Daten zur Darlegung der Eignung und Wirksamkeit des QM-
Systems.
Die ISO 13485 unterscheidet zwischen Dokumenten und Aufzeichnungen. Dokumente haben
grundsätzlich einen Vorgabecharakter. Beispiele sind Verfahrensanweisungen, in denen
verpflichtend vorgeschrieben ist, wie Verfahren durchzuführen sind sowie Arbeitsanweisungen, in
denen verpflichtend festgelegt wird, wie bestimmte Arbeiten auszuführen sind. Aber auch
produktspezifische Dokumente, wie Anforderungsspezifikationen oder Testspezifikationen sind
solche Dokumente. Ein Dokument soll gepflegt werden, kann also überarbeitet werden und
benötigt daher eine Versionierung. Es muss sichergestellt werden, dass alle Personen, auf die für
sie relevanten Dokumente in der letzten freigegebenen Version Zugriff haben.
Aufzeichnungen stellen einen besonderen Dokumenttyp dar. Aufzeichnungen dienen als
Nachweis das Produkte die Anforderungen erfüllen sowie als Nachweis der Konformität mit der
ISO 13485 und müssen daher aufbewahrt werden. Beispiele für Aufzeichnungen sind
Testprotokolle oder ausgefüllte Formulare. Aufzeichnungen sind also Nachweisdokumente und
dürfen daher nach der Erstellung und Freigabe nicht mehr verändert werden und benötigen somit
auch keine Versionierung.
Das QM-System benötigt ein dokumentiertes Verfahren, in dem beschrieben ist, wie die,
Identifizierung, die Aufbewahrung, der Schutz und die Wiederauffindbarkeit, der Dokumente und
Aufzeichnungen sichergestellt ist.
Wiederholung FL: Unterschied zwischen Dokument und Aufzeichnung
Die ISO 13485 fordert in Kapitel 7.1 - Planung der Produktrealisierung, dass eine Organisation
Prozesse planen und entwickeln muss, die für die Produktrealisierung erforderlich sind. Folgende
Forderungen müssen erfüllt werden:
 Festlegung der Qualitätsziele und Anforderungen des Produktes
 Festlegung der benötigten Prozesse und Ressourcen zur Herstellung des Produktes
 Festlegung der benötigten Verifikations- und Validierungsmaßnahmen
 Festlegung der zu erstellenden Dokumente zum Nachweis, dass die Produktanforderungen
erfüllt sind
Gemäß der ISO 1385 muss die Dokumentation für das Design und die Entwicklung folgende
Inhalte abdecken:
 Design- und Entwicklungsplanung: Einzelne Phasen der Entwicklung und abschließende
Prüfkriterien müssen festgelegt werden.
 Design- und Entwicklungsvorgaben: Produktanforderungen einschließlich.
Softwareanforderungen sowie Anforderungen aus dem Risikomanagement müssen erfasst
werden.
 Design- und Entwicklungsergebnisse: Architektur, Design und Code müssen den
Anforderungen genügen und dokumentiert sein.
 Design- und Entwicklungsvalidierung: Das Produkt einschließlich der zugehörigen Software
muss verifiziert und validiert werden und die Ergebnisse dieser Prüfungen müssen
aufgezeichnet werden.
Gesamtlehrplan
5.2. Allgemeine Anforderungen an die Dokumentation

5.2.1. Umgang mit Dokumenten
In jedem Qualitätsmanagementsystem muss festgelegt werden, welche Dokumente und
Aufzeichnungen darin gelenkt werden und wie deren Lenkung erfolgt. Die Normen machen keine
Vorgaben hinsichtlich der Art der Lenkung, so dass von reiner Papierdokumentation bis hin zur
Verwendung von komplexen Softwarewerkzeugen alles benutzt werden kann.
 Dokumentenlandschaft
 Langzeitarchivierung
 Dokumentenlandschaft
 Langzeitarchivierung
 Digitale Signatur
 Electronic Record
 Electronic Signature
 Handschriftliche Unterschrift
5.2.1.4. Umgang mit Dokumenten
Lehrziele
M5-LE2.1-1-1 Anforderungen an die Erstellung von Dokumenten K1 W
kennen.
M5-LE2.1-1-1 Anforderungen an die Zugriffberechtigung und K1 --
Verteilung kennen.
M5-LE2.1-1-1 Versionsverwaltung von Dokumenten in K1 --
Zusammenhang mit Änderungsprozessen kennen.
M5-LE2.1-1-1 Anforderungen an die Freigabe von Dokumenten K1 --
kennen.
M5-LE2.1-1-1 Den Lebenszyklus von Dokumenten kennen. -- K1
M5-LE2.1-1-1 Den Unterschied zwischen Prüfung und Freigabe -- K2
verstehen.
M5-LE2.1-1-1 Anforderungen an die Verfügbarkeit und Archivierung -- K1
von Dokumenten kennen.
M5-LE2.1-1-1 Die Bedeutung von Langzeitarchivierung kennen. K1 --
M5-LE2.1-1-1 Wissen, was ein Dokumentenmanagementsystem -- K2
(DMS) ist.
M5-LE2.1-1-1 Regularien zur Dokumentenlenkung kennen. -- K1
M5-LE2.1-1-1 Wissen, auf was geachtet werden muss, wenn -- K1
Dokumente und Aufzeichnungen nur elektronisch
vorhanden sind. 21 CFR Part 11 usw.
M5-LE2.1-1-1 Wissen, was die Begriffe digitale Signatur, Electronic -- K1
Signature und Electronic Record bedeuten und was sie
unterscheidet.
Gesamtlehrplan
Eine der zentralen Forderungen eines dokumentierten Qualitätsmanagementsystems, wie der ISO
13485, ist die Lenkung von Dokumenten und Aufzeichnungen. Daher werden klare und
nachvollziehbare Regeln für den Umgang mit Dokumenten und Aufzeichnungen gefordert, in
denen festgelegt ist, wie diese
 identifiziert,
 versioniert,
 verändert,
 verteilt,
 aktuell gehalten
 archiviert
 und aus dem Verkehr gezogen
werden. Auch muss klar sein, welche Dokumente und Aufzeichnungen überhaupt gelenkt werden
müssen. Grundsätzlich müssen alle in Verfahrens- und Arbeitsanweisungen aufgeführten
Dokumente und Aufzeichnungen gelenkt werden, um den Nachweis zu führen, dass die
Organisation konform zu den eigenen Prozessen funktioniert. Für bestimmte Projekte, etwa
einem Entwicklungsprojekt, empfiehlt es sich zusätzlich eine Übersichtstabelle zu erstellen, in der
alle, für dieses Projekt relevanten Dokumente und Aufzeichnungen aufgeführt sind.
ERSTELLUNG:
Jedes Dokument und jede Aufzeichnung müssen zunächst erstellt werden. Insbesondere
Aufzeichnungen können im Einzelfall problematisch sein, etwa wenn in bei der Testausführung
die Ergebnisse auf Papier festgehalten werden, die Unterschriften und die Dokumentation als
Ganzes jedoch elektronisch vorliegen soll. Hier ist auf klare Regeln und die Überprüfung der
Einhaltung dieser Regeln zu achten.
ZUGRIFF:
Es muss sichergestellt sein, dass jeder Betroffene auch Zugang zur aktuellen Version hat. Weiter
ist gefordert, dass nur gültige Dokumente benutzt werden. Im Regelfall sind dies die zuletzt
freigegebenen Versionen. Es muss also außerdem festgelegt werden, wie nicht mehr gültige
Versionen aus dem Verkehr gezogen werden
FREIGABE:
Dokumente müssen vor der Verwendung geprüft und freigegeben werden. Wer ein bestimmtes
Dokument prüfen oder freigeben darf, wird üblicherweise in der zugehörigen Verfahrens- oder
Arbeitsanweisung festgehalten. Zusätzlich bietet es sich an, eine Liste mit den Rollen zu führen,
die in de, Qualitätsmanagementsystem benutzt sind.
ARCHIVIERUNG:
Die vollständige Herstelldokumentation hat eine gesetzlich geregelte Aufbewahrungsfrist. Es
muss also sichergestellt werden, dass alle Dokumente und Aufzeichnungen während des
gesamten Zeitraums verfügbar und lesbar sind. Dies kann insbesondere bei digitalen
Dokumenten, die in proprietären Formaten vorliegen, problematisch sein. Als einziges
verlässliches Format existiert hier neben der Verwendung von reinen ASCII-Klartext-Dateien seit
2005 das PDF/A-Format, das speziell für digitale Langzeitarchivierung entwickelt wurde.
Die Lenkung von Dokumenten und Aufzeichnungen ist in der ISO 13485 gefordert. Ein
Qualitätsmanagementsystem muss ein Verfahren zur Lenkung von Dokumenten und
Aufzeichnungen beinhalten. Die Verfahrensanweisung muss folgende Sachverhalte beschreiben:
 Bewertung von Dokumenten bezüglich der Angemessenheit und Genehmigung vor der
Herausgabe
Gesamtlehrplan
 Bewertung von Dokumenten, bedarfsweise Aktualisierung und erneute Genehmigung

 Sicherstellen der Identifizierbarkeit von Änderungen
 Sicherstellen, dass nur gültige Fassungen zutreffender Dokumente an den jeweiligen
Einsatzorten verfügbar sind
 Sicherstellen, dass Dokumente lesbar und leicht identifizierbar bleiben
 Sicherstellung der Kennzeichnung und Verteilung von Dokumenten externer Herkunft
 Verhinderung der Verwendung veralteter Dokumente
Die FDA regelt im Gesetz FDA 21 CFR Part 11 den Umgang mit elektronischen Unterschriften und
definiert dafür die folgenden Begriffe:
 Digitale Signatur
 Electronic Record
 Electronic Signature
 Handschriftliche Unterschrift
Das Gesetz betrifft jedes Produkt, das von der FDA als qualitätsrelevant eingestuft wird und bei
dem eine zuvor auf Papier geleistete Unterschrift durch eine Elektronische Unterschrift ersetzt
wird. Begriffsdefinition (laut §11.3 FDA 21 CFR Part 11). Folgende Anforderungen werden von der
FDA an elektronische Unterschriften gestellt:
 Authentizität: Jede elektronische Unterschrift muss einzigartig für eine Einzelperson sein und
darf nicht von einer anderen Person wiederbenutzt oder einer anderen Person zugewiesen
werden.
 Überprüfung der Identität: Bevor eine Organisation die elektronische Unterschrift oder ein
beliebiges Element einer elektronischen Unterschrift einer Person einrichtet, zuordnet,
zertifiziert oder auf andere Weise genehmigt, muss die Identität der Person überprüft
werden.
 Kontrollen: Elektronische Unterschriften, die nicht auf biometrischen Verfahren beruhen
müssen mindestens 2 verschiedene Komponenten zur Identifizierung verwenden, wie z.B.:
Benutzername und Passwort oder Karte und Pin. Elektronische Unterschriften basierend auf
biometrischen Methoden müssen so entworfen werden, dass sichergestellt wird, dass sie von
keinem anderen als dem Eigentümer verwendet werden können.
 Erscheinungsformen einer Unterschrift: Elektronisch unterschriebene Aufzeichnungen
müssen mit der Unterschrift alle folgenden Informationen enthalten: den ausgeschriebenen
Namen des Unterzeichners, das Datum und die Uhrzeit zu der die Unterschrift geleistet
wurde, unddie mit der Unterschrift verbundene Bedeutung (wie z.B. Review, Genehmigung,
Verantwortung/Autor).
Die Konformität mit 21 CFR 11 setzt eine erfolgreiche Validierung der zugehörigen
Computersysteme voraus.
5.2.2. Allgemeine Anforderungen an Dokumente
Ein Qualitätsmanagementsystem stellt Anforderungen daran, wie mit Dokumenten und
Aufzeichnungen umgegangen werden darf. Insbesondere muss für jedes Medizinprodukt
festgelegt sein, welche Dokumente und Aufzeichnungen erforderlich sind, welchen Inhalt sie
haben müssen, für welche Zielgruppe sie erstellt wurden und wer sie prüfen und freigeben darf.
5.2.2.2. Allgemeine Anforderungen an Dokumente
Lehrziele
M5-LE2.2-1-1 Zweck der Dokumentation kennen. K1 --
M5-LE2.2-1-1 Formale Anforderungen an Dokumente kennen. K1 --
M5-LE2.2-1-1 Wissen wie ein Dokument grundsätzlich strukturiert -- K2
Gesamtlehrplan
sein soll.
M5-LE2.2-1-1 Wissen wozu ein Dokumentationsplan erforderlich ist. -- K2
Dokumente und Aufzeichnungen haben mehrere Zwecke. So dienen Dokumente dazu ein
gemeinsames Verständnis über einen bestimmten Sachverhalt langfristig zu sichern und so das
Lernen in der Organisation zu unterstützen (Wissensmanagement). Dokumente und
Aufzeichnungen haben vor allem den Zweck, die korrekte Durchführung von Verfahrens- und
Arbeitsanweisungen nachvollziehbar zu machen und damit letztendlich nachweisen zu können,
dass ein Medizinprodukt die grundlegenden Anforderungen erfüllt.
Es empfiehlt sich, Dokumente und Aufzeichnungen so zu strukturieren, dass sie ein klar
abgegrenztes Thema behandeln. Die ISO 13485 fordert aber nur bestimmte Inhalte. Die
Organisation kann grundsätzlich selbst entscheiden, wie die geforderten Inhalte auf bestimmte
Dokumente und Aufzeichnungen aufgeteilt werden.
Wiederholung der Formalen Anforderungen Diskussion eines Beispiels für eine Gliederung eines
Dokuments mit Zielpublikum, Zweck des Dokuments etc. Diskussion eines Beispiels für einen
Dokumentationsplan: Inhalte des Dokumentationsplan können sein:
 gezieltes Ablegen und Wiederauffinden aller Schriftstücke (elektronisch und auf Papier) im
Kontext des Projekts
 Schaffung einer vollständigen Gesamtdokumentation zum Projekt einschließlich
Zwischenberichten und Abschlussdokumentationen
 Basis für die Kontrolle des Projektforstschritts
 Schaffung von Transparenz im Projekt (->Zugang in angemessenem Umfang)
 Bestimmung von Verantwortlichkeiten
 Bestimmung von Sicherungsmechanismen (Backups)
5.3. Geforderte Dokumentation

5.3.1. Überblick
Während des Lebenszyklus eines Medizinprodukts sind Dokumentationen zu unterschiedlichen
Themengebieten zu erstellen. Neben den für das QM-System relevanten Dokumenten sind
Dokumentationen in Form einer Risikomanagementakte und Gebrauchstauglichkeitsakte zu
erstellen. Die technische Dokumentation ist ebenso gefordert wie entwicklungsbegleitende
Dokumentationen. Wichtig dabei ist herauszustellen, dass die Dokumentationen zu den einzelnen
Themenbereichen nicht isoliert voneinander erstellt und bearbeitet werden, sondern
zusammenhängen.
 Medizinproduktakte
 Gebrauchstauglichkeitsakte
 Technische Dokumentation
 Benannte Stelle
 Medizinproduktakte
 Gebrauchstauglichkeitsakte
 Technische Dokumentation
 Benannte Stelle
Gesamtlehrplan
5.3.1.4. Überblick
Lehrziele
M5-LE3.1-1-1 Die wesentlichen Dokumente kennen. K1 W
M5-LE3.1-1-1 Wissen, das Dokumente in verschiedenen Akten -- K2
referenziert werden und verstehen, wie man
Redundanzen vermeiden kann.
Folgende Dokumente sind notwendig:
 Dokument zur Definition der Zweckbestimmung,
 Produktspezifikation,
 Architekturdokumente mit Komponentenentwurf und SW-Sicherheitsklassifizierung,
 Verifizierungs- und Validierungsplan,
 Verifizierungs- und Validierungsprotokoll,
 Dokumentation der Fehlerberichte und Produktnachverfolgung,
 Dokumentation der Prozesse, Methoden und Werkzeuge, die bei der Entwicklung zum Einsatz
kommen,
 Dokumentation der Werkzeugvalidierung,
 Dokumentation der Risikopolitik,
 Risikobewertungsmatrix, Risikoanalyse,
 Schulungsunterlagen und Gebrauchsanweisung,
 Freigabeprotokolle
Grundsätzlich werden in den unterschiedlichen Akten wie Risiko-Management-Akte,
Gebrauchstauglichkeits-Akte, Entwicklungsdokumentation und Technische Dokumentation
Informationen für unterschiedliche Zielgruppen bereitgestellt. Um Redundanzen zu vermeiden
und um eine Übersichtlichkeit über die Dokumente zu behalten ist es zu empfehlen in den
sogenannten "Akten" keine Dokumente an sich zu führen, sondern dort nur Referenzen auf die
Dokumente und Aufzeichnungen und gültige Versionen zu hinterlegen.
Folgendes Vorgehen hat sich als praxistauglich bewährt: Während des Entwicklungsprozesses
werden Dokumente zu den entsprechenden Themenschwerpunkten nach dem V-Modell
angelegt. Diese werden dann in den Akten referenziert. Bei den Dokumenten handelt es sich um:
 Nutzeranforderungen
 System- und Produktanforderungen
 Softwarerequirementspezifikation mit Klassifizierung der Sicherheitsklasse (A, B, C)
 System- und Softwarearchitektur mit eindeutiger Zuordnung zu den Sicherheitsklassen
 Software Design Packages zu einzelnen Softwaremodulen
 Testkonzept
 Testspezifikationen
 Testprotokolle
5.3.2. Risikomanagementakte
5.3.2.2. Risikomanagementakte
Lehrziele
M5-LE3.2-1-1 Inhalte der Risikomanagementakte kennen. -- K1
M5-LE3.2-1-1 Aufbau der Risikomanagementakte kennen -- K1
Gesamtlehrplan
M5-LE3.2-1-1 Zusammenhänge und Verbindungen zwischen QM -- K2

System und Risikomanagement verstehen.
Eine Risikomanagementakte nach ISO 14971 enthält:
 Risikoanalyse inkl. aller ermittelte Gefährdungen und Risiken,
 Risikomanagementplan,
 Zweckbestimmung und bestimmungsgemäßer Gebrauch,
 Dokumentation der Risikobewertung, z.B. in Form einer Risikobewertungsmatrix (Risiken vor
und nach Risikokontrollmaßnahmen),
 Ergriffene Risikokontrollmaßnahmen und Verifikation deren Umsetzung und Wirksamkeit zur
Risikobeherrschung,
 Gesamtrisikobewertung,
 Daten aus der Marktbeobachtung
 Beurteilung der Akzeptanz des Restrisikos
Die Risikomanagementakte liegt oft nicht als physische Akte bzw. elektronisches Verzeichnis vor.
Vielmehr enthält sie Verweise auf andere bereits vorhandene Dokumente.
Dadurch kann bei kleineren Projekten die Risikomanagementakte bis auf ein umfangreiches
(Word)Dokument entschlackt werden. Die zu referenzierenden Dokumente sollen in einem
Beispiel gezeigt werden und sollten folgende Punkte beinhalten:
 Risikomanagementprozess
 Verantwortung der Leitung
 Qualifikation des Personals (Soll/Ist)
 Risikomanagementplan
 Zweckbestimmung
 Gefährdungen
 Einschätzung der Risiken
 Risikobewertung
 Analyse und Umsetzung der Maßnahmen
 Analyse des Restrisikos
 Risiko-Nutzen-Analyse
 Neue Risiken
 Vollständigkeit
 Bewertung Gesamtrisiko
 Risikomanagementbericht
 Nachgelagerte Phasen
Für eine übersichtliche Darstellung im Rahmen der Risikobewertung und Risikodokumentation
wird in der Praxis eine Tabelle verwendet. Die tabellarische Übersicht hat den Vorteil Herstellern
und Auditoren einen schnelleren Überblick zu verschaffen und die Tätigkeiten auf Vollständigkeit
zu prüfen. Ein Beispiel für eine Tabelle zur Risikodokumentation soll vorgestellt werden. In diesem
Beispiel soll auch gezeigt werden wie aus diesem Dokument heraus andere Dokumente mit
eindeutiger Identifizierung verlinkt werden können. Die von der IEC 62304 geforderte SW-
Sicherheitsklassifizierung der Softwarekomponenten könnte Teil der Produktakte sein und sollte
aus der Risikomanagementakte referenziert werden.
5.3.3. Gebrauchstauglichkeitsakte
5.3.3.2. Gebrauchstauglichkeitsakte
Lehrziele
Gesamtlehrplan
M5-LE3.3-1-1 Inhalte der Gebrauchstauglichkeitsakte kennen -- K1

M5-LE3.3-1-1 Nutzen der Gebrauchstauglichkeitsakte und die -- K2
Verbindung zu anderen Teilbereichen verstehen
Eine Gebrauchstauglichkeitsakte nach IEC 62366 muss folgende Dokumentation enthalten:
 Spezifikation der Anwendung: häufig benutzte Funktionen, Hauptbedienfunktionen,
sicherheitsbezogene Merkmale,
 Ermittelte Gefährdungen,
 Spezifikation der Gebrauchstauglichkeit,
 Validierungsplan für die Gebrauchstauglichkeit,
 Gestaltung und Entwurf der Benutzer-Produkt-Schnittstelle,
 Verifizierung und Validierung der Gebrauchstauglichkeit
 Begleitpapiere und Schulungsmaterial
Auf Grund der sehr großen Überschneidungen mit den Anforderungen an das Risikomanagement
und den Software-Lebenszyklus-Prozess werden im gebrauchstauglichkeitsorientierten
Entwicklungsprozess viele vorhandenen Dokumente um Aspekte der Gebrauchstauglichkeit
erweitert und müssen nicht neu erstellt werden. Im Rahmen des
gebrauchstauglichkeitsorientierten Entwicklungsprozesses ist es wichtig nicht nur das Produkt,
sondern auch alle Begleit- und Schulungsmaterialien berücksichtigt und damit natürlich auch der
Dokumentation hinzugefügt werden müssen.
Ein Beispiel für ein Usability Engineering-File ist vorzustellen und zu diskutieren. (10 Minuten) und
dabie auf den Nutzen der Gebrauchstauglichkeitsakte und die Verbindung zu anderen
Teilbereichen verdeutlichen.
5.3.4. Dokumentation der Softwareentwicklung
5.3.4.2. Dokumentation der Softwareentwicklung
Lehrziele
M5-LE3.4-1-1 Die Inhalte der Dokumentation einer K1 --
Softwareentwicklung nach IEC 62304 kennen
M5-LE3.4-1-1 Die wesentlichen Inhalte der entwicklungsbezogenen -- K1
Dokumente kennen
Die Dokumentation einer Softwareentwicklung nach IEC 62304 enthält:
 Planungsdokumente (Entwicklungsplan, Wartungsplan, Integrationsplan, Software-
Risikomanagementplan),
 Softwareanforderungen,
 Softwarearchitektur,
 detaillierter Entwurf der Software,
 Spezifikationen der Software Integrationstests und die zugehörigen Testergebnisse,
 Spezifikation der Software Systemtests und die zugehörigen Testergebnisse,
 Liste mit bekannten Fehlern,
 Liste mit Rückmeldungen,
 Liste mit Gefährdungen und Risikokontrollmaßnahmen,
 Freigabedokumentation
Die IEC 62304 verlangt, abhängig von der Sicherheitsklasse, für alle Phasen und Aktivitäten des
Entwicklungsprozesses von der Planung über die Anforderungsanalyse bis zur Freigabe die
entsprechenden Dokumente. Auch werden zum Nachweis der Vollständigkeit Verweise zwischen
Gesamtlehrplan
den einzelnen Dokumenten gefordert. Beispielsweise müssen alle Softwareanforderungen der

Risikoklassen B und C in der Architektur berücksichtigt und durch Software Systemtests
abgedeckt werden. Das ist in der Dokumentation nachzuweisen.
Die einzelnen Informationen in der Dokumentation müssen auf sehr granularer Ebene
identifizierbar bleiben. Es reicht deshalb nicht, wenn nur ein Anforderungsdokument eindeutig
identifizierbar ist, es muss auch jede einzelne Anforderung eindeutig sein.
Folgende Dokumente sind auf Produktanforderungsebene sinnvoll:
 Spezifikation der Systemanforderungen,
 Spezifikation der Nutzeranforderungen,
 Systemarchitektur
Folgende Dokumente sind für die Projektdokumentation unerlässlich: Bereich
Projektmanagement:
 Entwicklungsplan,
 Definition und Beschreibung der Entwicklungsumgebung und Laufzeitumgebung, Tooling,
 Konfigurationsmanagementplan,
Bereich der Software Requirements
 Software Requirement Specification,
 Softwarearchitektur
Bereich Software Verifikation und Validierung
 Integrationstestplan für Softwaremodule und -protokoll,
 Software Systemtestplan und - protokoll
 Softwarefreigabe
Bereich Produkt Verifikation und Validierung
 Systemintegrationsplan und - protokoll
 Systemtestplan und - protokoll
 Systemfreigabe
Ein Beispiel für Dokumente bzgl. Inhalt etc. ist zu empfehlen.
5.3.5. Technische Dokumentation
5.3.5.2. Technische Dokumentation
Lehrziele
M5-LE3.5-1-1 Die Ziele und den Inhalt der Technischen K1 --
Dokumentation kennen
M5-LE3.5-1-1 Wissen, was die benannten Stellen mit den -- K2
Dokumenten machen
Die Erstellung der technischen Dokumentation (auch Produktakte genannt) ist ein wesentlicher
Bestandteil der Konformitätsbewertung von Medizinprodukten. Sie ist das zentrale
Nachweisdokument, in dem der Hersteller die Erfüllung der grundlegenden Anforderungen als
Voraussetzung für die CE -Kennzeichnung bescheinigt. Die Technische Dokumentation ist ein Satz
von Dokumenten, der bei der benannten Stelle für Medizinprodukte ab Klasse IIa eingereicht
werden muss, um die Zulassung für ein Medizinprodukt zu erhalten. Diese umfasst für
Medizinprodukte folgende Informationen:
 Produktbezeichnung (Name auf dem Markt, Produktname mit ggf. Zusätzen)
Gesamtlehrplan
 Zweckbestimmung des Produkts mit Beschreibung, bestimmungsgemäßem Gebrauch und

Anwenderkreis
 Klassifizierung des Produkts nach Anhang 9 der Richtlinie mit Angabe der Regel und
Begründung
 Produktbeschreibung mit Leistungsdaten, besondere Anforderungen, sicherer und korrekter
Gebrauch, Kataloge, Produktmuster, Liste des festgelegten Zubehörs
 Vorhandene Zulassungen und Zertifikate, Auflistung der ganz oder teilweise angewandten
harmonisierten Normen
 Beschreibung möglicher Kombinationen mit anderen Produkten sowie Schnittstellen.
Auflistung nicht erlaubter Kombinationen
 Software / Softwarearchitektur
 Validierung von (Standalone-) Software oder des Produktes,
 Risikomanagementakte nach DIN EN ISO 14971
 Nachweis der Erfüllung der grundlegenden Anforderungen: es muss gezeigt werden können,
dass die wesentlichen Anforderungen aus den Anforderungsdokumenten erfüllt sind.
 Konformitätserklärung des Herstellers
 Anweisungen (hier sind nur die für Software relevanten Anweisungen aufgelistet):
Gebrauchsanweisung,Wartungsanleitung,Pflegehinweise,Montageanleitungen
 Schulungsunterlagen
 Freigabeprotokolle
 Produktnachverfolgung nach Abschluss der Entwicklungsphase: Fehler, die nach der
Marktfreigabe auftraten müssen hier dokumentiert werden bspw. in Form von
Fehlerberichten
Fast alle diese Dokumente sind in einer gewissenhaft durchgeführten Produktentwicklung bereits
vorhanden und müssen nur zusammengestellt werden.
Detaillierte Beschreibung zu softwarerelevanten Themen:
Produktbeschreibung mit Leistungsdaten, besondere Anforderungen, sicherer und korrekter
Gebrauch, Kataloge, Produktmuster sowie eine Liste des festgelegten Zubehörs. Dazu gehören
Artikelbeschreibungen auf der Homepage und Werbebroschüren etc., die das Produkt und seine
Anwendung für den Anwender beschreiben.
Beschreibung möglicher Kombinationen mit anderen Produkten sowie Schnittstellen. Auflistung
nicht erlaubter Kombinationen. Hier stehen vor allem mögliche Kombinationen unterschiedlicher
Hardwaremodule, Plugins und Erweiterungen des Systems im Fokus. Falls es unerlaubte
Kombinationen gibt, so müssen diese dort dokumentiert sein. Ebenso müssen nicht kompatible
Versionen von Soft- und Hardwareversionen hier dokumentiert sein.
Software / Softwarearchitektur: Die Software (Konfigurationsmanagement) und die Beschreibung
der Softwarearchitektur müssen in der technischen Dokumentation enthalten sein.
Validierung von (Standalone-) Software oder des Produktes. Neben den Validierungsplänen
gehören auch die entsprechenden Protokolle für das Gesamtprodukt in die technische
Dokumentation.
Anweisungen (hier sind nur die für Software relevanten Anweisungen aufgelistet):
 Gebrauchsanweisung
 Wartungsanleitung
 Pflegehinweise
 Montageanleitungen
Schulungsunterlagen: Wenn zur Benutzung der Software eine Schulung notwendig ist, dann
müssen in der Technischen Dokumentation auch die entsprechenden Schulungsprotokolle
enthalten sein.
Gesamtlehrplan
Produktnachverfolgung nach Abschluss der Entwicklungsphase: Fehler, die nach der

Marktfreigabe auftraten müssen hier dokumentiert werden bspw. in Form von Fehlerberichten.
Dabei muss eine Bewertung über die schwere des Fehlers und seine Auswirkungen in der
Technischen Dokumentation dokumentiert sein.
In mehreren Akten vorkommende Dokumente müssen nicht redundant gehalten werden. In der
Alltagspraxis gibt es folgende Aufbewahrungsorte für die in den Normen geforderten Dokumente.
 Qualitätsmanagementhandbuch auf Prozessebene des gesamten Unternehmens
 Risikomanagementakte für ein Produkt
 Gebrauchstauglichkeitsakte für ein Produkt
 Entwicklungsdokumentation für ein Produkt
 Technische Dokumentation für ein Produkt
Dabei lässt sich sagen, dass die Technische Dokumentation auf Produktebene die anderen
Dokumentationsorte zusammenfasst und als Gesamtheit der benannten Stelle für eine Zulassung
zur Verfügung gestellt werden muss. Die benannte Stelle prüft die Dokumente auf
Vollständigkeit, Plausibilität und Widerspruchsfreiheit.
5.4. FDA vs EU
5.4.1. Die unterschiedlichen Anforderungen an die Dokumentation aus FDA und EU
Sicht
FDA
 Record
 Design Control
 Design History File
 Design Master Record
 PMA
 510(k)
5.4.1.3. Begriffe und Anforderungen aus der FDA
Lehrziele
M5-LE4.1-1-1 Wie können geforderte Dokumente aus der ISO 62304 -- K2
auf die FDA Anforderungen an die Dokumentation
übertragen werden?
M5-LE4.1-1-1 Unterschiedliche Anforderungen der FDA und in EU an -- K2
die Dokumentenlenkung kennen
M5-LE4.1-1-1 Wissen, was ein Device History File ist -- K1
M5-LE4.1-1-1 Wissen, was ein Device Master Record ist -- K1
M5-LE4.1-1-1 Wissen, was ein Device Master Record ist -- K1
M5-LE4.1-1-1 Verstehen was die Unterschiede zwischen DHF, DMR -- K2
und DHR sind.
Die FDA hat sehr ähnliche Abforderungen an die Lenkung von Dokumenten und Aufzeichnungen:
 Es muss klar erkennbar sein, wer für das Anlegen, das Review oder die Freigabe eines
Dokuments verantwortlich war. Das muss mit Datum und Unterschrift dokumentiert werden.
 Die Dokumente müssen der FDA vorgelegt werden können.
Gesamtlehrplan
 Ungültige Dokumente müssen zurückgezogen werden können.

 Änderungen an Dokumenten werden ebenfalls dokumentiert, geprüft, freigegeben und
kommuniziert (Datum, Unterschrift).
 Zusätzlich zur ISO 13485 fordert die FDA die Sicherheit der Dokumente gegen Verlust,
Diebstahl und Verfälschung sicherzustellen
Ein Record ist eine Aufzeichnung von z.B. Ergebnissen. Auch Records müssen geprüft (Review)
und freigegeben werden. (Subpart M)
Die FDA beschreibt die allgemeinen Anforderungen an die Dokumentation in 21 CFR part 820,
Subpart C: Design Controls, Subpart M: Records. Dabei steht Design Control nicht für
Designkontrolle sondern für den gesamten Entwicklungsprozess. Dieser muss für alle
Softwareprodukte angewendet werden und beinhaltet folgenden Aktivitäten:
 Entwicklungsplanung: Wer führt welche Aktivitäten aus? Beschreibung des
Entwicklungsprozesses identisch zu Entwicklungsplanung IEC 62304, zusätzlich
Anforderungen zur Überführung der Entwicklung in die Produktion, Validierung und Erhebung
der Systemanforderungen
 Design input: Design- und Entwicklungsanforderungen: Welche Verfahren werden eingesetzt
zum Erheben von Erfordernissen und Zweckbestimmungen
 Design output: Es muss festgelegt werden, wie Entwicklungsergebnisse dokumentiert
werden. Es kann damit geprüft werden, ob das Produkt den Anforderungen genügt.
Unterschied EU: Die ISO 13485 fordert keine Verfahren, nur Aufzeichnungen
 Design review: ähnl. zu ISO 13485: an Meilensteinen müssen Reviews erstellt werden. Auch
die dazugehörigen Verfahren müssen dokumentiert werden.
 Design verification: Verfahren zur Verifizierung müssen beschrieben werden. Siehe auch ISO
9126
 Design validation: Verfahren müssen festgelegt und Ergebnisse müssen im DHF dokumentiert
werden. Auch die Gebrauchstauglichkeit ähnl. ISO 62366 muss validiert werden.
 Design transfer: Sicherstellen der Transfers der Entwicklungsergebnisse in die Produktion. ->
Wie landen die richtigen Artefakte auf der CD?
 Design changes: Änderungen am Produkt nach dem Entwicklungsprozess müssen erst
bewertet werden. Hier ist der Problemlösungs- und Wartungsprozess der IEC 62304
ausreichend.
 Design history files: Alle Verfahrensbeschreibungen, Records und Testergebnisse, die
während der Entwicklung entstehen haben hier zu landen.
Die FDA definiert die Begriffe Design History File (DHR), Device Master Record (DMR) und Device
History Record (DHR).
Design History File - DHF (21 CFR 820.3 (e)) = Entwicklungsentstehungsakte, die alle
Informationen enthält, welche die Entwicklungsentstehung des fertigen Produktes beschreiben.
Typische Dokumente sind:
 Entwicklungsplan, Softwarearchitektur
 Review-Aufzeichnungen
 Skizzen, Zeichnungen
 Aufzeichnungen der Komponentenqualifizierung
 Verifizierung von Prototypen
 Validierungsprotokolle
Device Master Record- DMR (21 CFR 820.181)
Dieses Dokument entspricht eher der "Technischen Dokumentation", wie sie in Europa bei den
Benannten Stellen eingereicht wird. Typische Dokumente sind:
 Zweckbestimmung
 Gebrauchsanweisung
 Designspezifikation (z.B. für Komponenten)
Gesamtlehrplan
 "Software specifications"
 Verfahrensbeschreibungen zur Produktion oder Testdurchführung eines Produktes
 Anforderungen an das Labeling, Lagerung und Transport
 Wartung und Installation
 Prüfberichte
Device History Record - DHR (21 CFR 820.184)
Der DHR soll nachweisen, dass ein Produkt so produziert wurde wie vorgesehen. Also so wie im
Device Master Record spezifiziert. Typische Teile des DHRs sind:
 Durchgeführte Prüfungen an den produzierten Medizinprodukten
Gesamtlehrplan
6. Curriculum Medizinische Informatik

Dieses Modul führt in einige Grundlagen der medizinischen Informatik ein. Es vermittelt eine
kurze Einführung in das Gesundheitswesen sowie grundlegende Aspekte der Interoperabilität
klinischer Systeme - IT und Medizintechnik.
6.1. Grundlagen des Gesundheitswesens

6.1.1. Akteure im Gesundheitswesen
Das Gesundheitswesen ist ein Markt, an dem viele Akteure mit teilweise im Konflikt stehenden
Interessen teilnehmen.
 Kassenärztliche Vereinigung
 Kassenärztliche Vereinigung
6.1.1.4. Übersicht über die Akteure im Gesundheitswesen
Lehrziele
M6-LE1.1-1-1 Die Akteure im Gesundheitswesen benennen können K1 W
M6-LE1.1-1-1 Wissen, welche staatlichen und halbstaatlichen -- K1
Institutionen es im Gesundheitswesen gibt.
Zu den Dienstleistungserbringern zählen die Krankenhäuser, Klinikketten,
Rehabilitationseinrichtungen, medizinische Versorgungszentren und die niedergelassenen Ärzte.
Auch ambulante Pflegeeinrichtungen und die Anbieter von Medikamenten, Heil- und Hilfsmitteln
wie Apotheken, Optiker und Sanitätshäuser erbringen medizinische Dienstleistungen. Weitere
Akteure sind die privaten und gesetzlichen Krankenkassen sowie die kassenärztlichen
Vereinigungen. Schließlich sind die Hersteller von Medizinprodukten und Arzneimitteln weitere
wichtige Akteure.
Wiederholung und folgende Ergänzung: Neben dem Bundesministerium für Gesundheit und
seinen Behörden wie dem Deutschen Institut für Medizinische Informatik (DIMDI), und dem
Bundesamt für Arzneimittel und Medizinprodukte (BfArM) gibt es weitere staatliche und
halbstaatliche Behörden und Organisationen wie Gesundheitsämter und das Institut für
angewandte Qualitätsförderung und Forschung im Gesundheitswesen (AQUA).
Dem DIMDI obliegt u.a. die Pflege von Klassifikationssystemen wie ICD-10 und OPS, das BfArM
veröffentlicht Meldungen von Herstellern über Risiken und werten diese aus.
6.1.2. Geldfluss
Das Zusammenspiel der Akteure und damit auch die Funktionalität vieler IT-Systeme werden
wesentlich durch Gesetze und den dadurch geregelten Fluss des Geldes bestimmt.
 DRG-System
 Gesundheitsfonds
 MorbiRSA
Gesamtlehrplan

 DRG-System
 Gesundheitsfonds
 MorbiRSA
6.1.2.4. Geldfluss im Gesundheitswesen
Lehrziele
M6-LE1.2-1-1 Erklären können, wie die Gelder im deutschen K1 W
Gesundheitswesen fließen.
M6-LE1.2-1-1 Aktuelle Trends den Geldfluss betreffend benennen -- K1
können.
Die Patienten entrichten Beiträge an eine oder mehrere gesetzliche und/oder private
Versicherungen. Im Versicherungsfall, also bei Inanspruchnahme, bezahlen die gesetzlichen
Versicherungen die Kosten für die Krankenhäuser und niedergelassenen Ärzte. Im letzteren Fall
findet aber keine direkte Kostenerstattung statt, sondern die gesetzlichen Versicherungen
bezahlen eine Kopfpauschale an die Kassenärztlichen Vereinigungen. Die schütten diese
Einnahmen an ihre Mitglieder, die niedergelassenen Kassenärzte, aus.
Privatversicherte Patienten erhalten von den niedergelassenen Ärzten und Krankenhäuser
Rechnungen, die sie von den privaten Krankenversicherungen PKV abhängig vom
Versicherungsvertrag erstattet bekommen. Oft übernehmen die PKVen die Bezahlung an die
Krankenhäuser auch direkt. Auch um die Versicherungsbeiträge zu begrenzen, hat die Politik
einen Gesundheitsfonds eingerichtet, der durch Steuermittel unterstützt wird. In diesen Fonds
zahlen somit die Patienten und Gesunden in ihrer Funktion als Steuerzahler ein. Weiter führen die
GKVen ihre Einnahmen an diesen Fonds ab, der den gesamten zur Verfügung stehenden Betrag
wieder an die GKVen ausschüttet. Diese Ausschüttung erfolgt aber abhängig von der Anzahl und
Risikoklasse der Patienten jeder Versicherung. Mit diesem sogenannten
MorbiRSA(Risikostrukturausgleich), sollen Versicherungen mit risikoreichen (alten,
multimorbiden) Patienten zu Lasten von Versicherungen mit risikoärmeren Patienten unterstützt
und damit der Wettbewerb zwischen den Krankenkassen gefördert werden.
Eine wesentliche Aufgabe vieler IT-Systeme im Gesundheitswesen besteht darin, diese Geldflüsse
abzubilden und zu unterstützen z.B. bei der Abrechnung. Auch sind viele
Interoperabilitätsstandards aus der Notwendigkeit geboren worden, abrechnungsrelevante Daten
zwischen verschiedenen IT-Systemen auszutauschen.
Wiederholung und folgende Ergänzung: Zunehmend mehr Leistungen, beispielsweise die
Medikamente betreffend, bezahlen die Patienten aus eigener Tasche. Auch beginnen
Krankenversicherungen damit, direkte Verträge mit niedergelassenen Ärzten zu schließen und
diese direkt zu bezahlen.
6.1.3. Intersektorale Kommunikation und Versorgung
Der Kostendruck im Gesundheitswesen macht es erforderlich, dass die Leistungserbringer wie die
Krankenhäuser und die niedergelassenen Ärzte über bestehende Sektorengrenzen hinweg besser
zusammenarbeiten.
 Interoperabilität
6.1.3.3. Sektorengrenzen
Gesamtlehrplan
Lehrziele
M6-LE1.3-1-1 Erinnern, dass die Versorgung künftig weniger an -- K1
Sektorengrenzen unterbrochen werden darf/wird.
M6-LE1.3-1-1 Erinnern, dass die intersektorale Versorgung -- K1
interoperabler Systeme bedarf und hohe
Anforderungen an den Datenschutz stellt.
Die bisherige Aufteilung der Gesundheitsversorgung auf niedergelassene Hausärzte und
Fachärzte sowie auf Krankenhäuser hat sich als nicht effizient und effektiv erwiesen. Die
Diagnostik und Therapie von Krankheiten endet nicht an diesen Sektorengrenzen. Diese Grenzen
führen vielmehr dazu, dass Untersuchungen mehrfach und Behandlungen unkoordiniert
durchgeführt werden. Dies erhöht die Kosten unnötig. Wenn die Gesundheitsversorgung
sektorenübergreifend erfolgen soll, müssen die Informationssysteme den Datenaustausch und
Prozessablauf auch sektorenübergreifend unterstützen. Dies stellt hohe Anforderungen
gleichermaßen an die Interoperabilität der Systeme wie an den Datenschutz.
6.1.4. Trends
Auch bedingt durch die Alterung der Gesellschaft und die technologische Weiterentwicklung
befindet sich das Gesundheitswesen selbst in einem kontinuierlichen Umbruch.
 CT
 MRT
6.1.4.3. Datenaufkommen.
Lehrziele
M6-LE1.4-1-1 Wissen, dass und weshalb immer mehr Daten erhoben -- K1
und verarbeitet werden.
Im Gesundheitswesen werden immer mehr Daten erhoben und ausgewertet. Zum einen stehen
immer mehr Daten zur Verfügung, beispielsweise Gen-Daten oder Daten durch neue
Untersuchungsverfahren. Zum anderen müssen die Leistungserbringer immer mehr Daten
bereitstellen, um für ihre Leistungen vergütet zu werden. Das liegt darin begründet, dass die
Vergütung zunehmend pauschalisiert, d.h. abhängig von einem Krankheitsbild und weniger
abhängig vom tatsächlichen Aufwand erfolgt. Die Klassifizierung in verschiedene Krankheitsbilder
wie im DRG-Systeme fordert umfangreiche (nicht nur) medizinische Daten. Auch der MorbiRSA
setzt medizinische und demographische Daten voraus.
Auch neue Untersuchungsverfahren wie hochauflösende und in umfangreichen Serien
aufgezeichnete MRT und CT Bilder, höchstauflösende Schnittbilder in der Pathologie und Gen-
Daten tragen zum steigenden Datenvolumen bei.
6.1.4.4. Zentralisierung
Lehrziele
M6-LE1.4-2-1 Wissen, dass die Versorgung und Datenverarbeitung -- K1
zunehmend zentralisiert erfolgt.
Gesamtlehrplan
Die Versorgung wird aus Kostengründen zunehmend zentralisiert, was den Einsatz von
Informationstechnologien voraussetzt, um die Patienten auch „remote“ untersuchen,
überwachen und betreuen zu können.
6.1.4.5. Informierte Patienten
Lehrziele
M6-LE1.4-3-1 Wissen, dass die Patienten zunehmend besser -- K1
informiert sind, und die Auswirkungen auf die
Dienstleistungserbringer kennen.
Die Patienten sind besser informiert. Gleichzeitig werden nur die Erbringer medizinischer
Dienstleistungen in Abhängigkeit der Qualität ihrer Arbeit bezahlt (von den Kostenträgern ebenso
wie von den Patienten, die zunehmend direkt zur Kasse gebeten werden). Beides zwingt die
Leistungserbringer, Qualität zu messen, zu verbessern und zu kommunizieren. Das setzt
konsistente und umfangreiche Daten voraus.
6.1.4.6. Konvergenz von Medizintechnik und IT
Lehrziele
M6-LE1.4-4-1 Wissen, dass die Medizintechnik und IT zunehmend -- K1
verschmelzen, und Auswirkungen dieses Trends
benennen können.
Medizintechnik, d.h. Medizingeräte und medizinische Informationssysteme arbeiten zusammen.
Das schafft neue Möglichkeiten bei der Diagnostik, Therapie und Überwachung, birgt aber auch
neue Gefahren und hat stellt neue Anforderungen an die Interoperabilität und die
Zusammenarbeit von Medizintechnik und IT. Die IEC 80001 adressiert das Risikomanagement für
vernetzte IT.
6.1.5. Daten im Gesundheitswesen
Die Menge und Vielfalt an Daten und Datenformaten stellt eine Herausforderung für die
Interoperabilität und die konsistente Datenverarbeitung dar.
6.1.5.2. Übersicht über die Daten im Gesundheitswesen
Lehrziele
M6-LE1.5-1-1 Die Lernenden können die wichtigsten Daten K1 W
benennen, die medizinische Systeme austauschen.
M6-LE1.5-1-1 Untersuchungen kennen, die besonders -- K1
umfangreichen Daten erzeugen
Zu den Daten, die im Rahmen der medizinischen Versorgung erfasst werden, zählen:
 Stammdaten: Namen, Geburtsdatum, Kontaktinformationen
 Versicherungsdaten: Versicherung, Zuzahlung, Status
 Anamnese: Beschwerden, Symptome, Vorgeschichte
 Befunde: Labor, körperliche Untersuchung, bildgebende Diagnostik (Röntgen, CT, MRT usw.),
Vitalparameter (Blutdruck, Temperatur)
 Diagnosen
 Therapien: Medikation, OP-Dokumentation, physikalische Therapie
Gesamtlehrplan
 Verlaufsdokumentation (z.B. Fieberkurve): Pflege, Beobachtung

Besonders umfangreiche Daten stammen zum Beispiel von
 genetischen Untersuchungen
 histologischen Untersuchungen (hochauflösende Bilder)
 Medizingeräten wie Überwachungsmonitore, Beatmungsgeräte usw.
Diese Informationen werden als Bestandteile von Nachrichten (z.B. „neuer Patient
aufgenommen“ oder „Laborwert steht zur Verfügung“) und von Dokumenten (Arztbrief,
Entlassbrief, Verlegungsbericht) ausgetauscht.
6.2. Medizinische Dokumentation

6.2.1. Ziele der medizinischen Dokumentation
Die Dokumentation der medizinischen Behandlung ist für viele Interessensgruppen auch
außerhalb der medizinischen Versorgung (der sogenannten primären Verwendung der Daten) von
Belang.

6.2.1.3. Strukturierte und unstrukturierte Daten
Lehrziele
M6-LE2.1-1-1 Ziele der medizinischen Dokumentation benennen K1 W
können. Den Unterschied zwischen strukturierter und
unstrukturierter Dokumentation verstehen.
M6-LE2.1-1-1 Verstehen, dass besonders mit strukturierter -- K1
Information ein einfacher Datenaustausch und eine
Zusammenführung und/oder Konsolidierung der
Daten beispielsweise für statistische Auswertungen
erfolgen kann.
M6-LE2.1-1-1 Zwischen primärer, sekundärer und tertiärer -- K1
Verwendung unterscheiden können.
Berechtigten Personen sollen relevante Information oder Wissen vollständig zum richtigen
Zeitpunkt, am richtigen Ort und in der richtigen Form zur Verfügung stehen. Medizinische
Dokumentation kann für verschiedene Zwecke verwendet werden. Je nach Verwendungszweck
ergeben sich unterschiedliche Anforderungen an die Dokumentation. Zu unterscheiden ist
unstrukturierte Dokumentation (z.B. Freitext), die handschriftlich oder elektronisch (z.B. Word, in
Freitextfeldern in einem KIS) erfolgen kann, von strukturierter Dokumentation auf Basis von
Ordnungssystemen. Beispielsweise erfasst man die Diagnosen in einem KIS i.d.R. in strukturierter
Form.
Die Nutzung der medizinischen Dokumentation – insbesondere mit IT-Methoden – wird in vielen
Fällen erst auf Basis strukturierter Dokumente möglich. Um patientenübergreifende
Fragestellungen beantworten zu können, müssen Ordnungssysteme verwendet werden und
Dokumentationsrichtlinien festgelegt und beachtet werden. Eine institutionsübergreifende
Nutzung wird erst möglich, wenn auch die Richtlinien und Ordnungssysteme
institutionsübergreifend vereinbart werden. Man unterscheidet folgende Verwendungen:
Gesamtlehrplan
 Primäre Verwendung: Direkte Leistungserbringung wie Diagnose, Therapie oder

Überwachung eines Krankheitsverlaufs
 Sekundäre Verwendung: z.B. Abrechnung
 Tertiäre Verwendung: Forschung, Statistik, Epidemiologie, Aufbau von Datenbanken,....
6.2.2. Ordnungssysteme
Semantische Interoperabilität wird erst mit Ordnungssystemen möglich. Die natürliche Sprache
ist oft zu differenziert, aber auch zu mehrdeutig, um ein einheitliches und präzises
Verständnisübertragener Informationseinheiten gewährleisten zu können. Abhängig von der
Granularität und dem Aufbau dieser Ordnungssysteme unterscheidet man beispielsweise
Terminologien, Klassifikationen und Ontologien.
 Taxonomie
 Terminologie
 Klassifikation
 DIMDI
 Taxonomie
 Vokabular
 Terminologie
 Thesaurus
 Ontologie
 Klassifikation
6.2.2.4. Ordnungssysteme
Lehrziele
M6-LE2.2-1-1 Die Begriffe Klassifikation, Taxonomie und K2 W
Terminologie verstehen. Ordnungssysteme diesen
Typen zuweisen können.
M6-LE2.2-1-1 Begriffe Thesaurus und Ontologie verstehen. -- K1
M6-LE2.2-1-1 Die Rolle des DIMDI kennen. -- K1
Die deutsche Sprache umfasst etwa 500.000 Worte, davon zählen 75.000 Worte zur
Standardsprache. Im medizinischen Kontext gibt es mehrere 100.000 Begriffe. Die Gesamtheit
alle dieser Begriffe und Benennungen (Fachausdrücke) einer Fachsprache nennt man
Terminologie. Terminologien findet man in einem Wörterbuch, einem Glossar oder einem
Thesaurus formuliert.
Für die Kommunikation ist es oft nicht notwendig, alle Begriffe zu differenzieren. So fast man
gleich (synonyme) und sehr ähnliche Begriffe in Klassen zusammen. Eine Klassifikation ist eine
planmäßige Sammlung von abstrakten Klassen (auch Konzepten oder Kategorien), die zur
Abgrenzung und Ordnung verwendet werden. Die einzelnen Klassen werden in der Regel mittels
Klassifizierung, das heißt durch die Einteilungen von Objekten anhand bestimmter Merkmale
gewonnen. Beispielsweise teilt man alle Krankheiten und Symptome mit Hilfe des
Diagnosekatalogs in etwa 1000 Klassen ein.
Taxonomien sind hierarchische Klassifikationen mit Über- und Unterklassen.
Gesamtlehrplan
Wiederholung. Zusätzlich: Thesauri setzen die Begriffe (einer Fachsprache) in Relation wie „ist
synonym zu“, „ist Oberbegriff von“, „ist verwandter Begriff zu“.
Ontologien gehen weiter und modellieren eine Fachdomäne. So lässt sich mit Ontologien
ausdrücken, dass eine Lungenentzündung ein Sonderfall einer Entzündung ist und dass
Entzündungen durch ein Agens verursacht wird. Eine Ontologie ist somit die
Wissensrepräsentation eines formal definierten Systems von Begriffen und Relationen.
Ontologien enthalten Regeln mit denen die Gültigkeit (->Integrität) geprüft und
Schlussfolgerungen (-> Inferenz) gezogen werden können.
Das Deutsche Institut für Medizinische Dokumentation und Informatik (DIMDI) verwaltet viele
dieser Ordnungssysteme die den Diagnosekatalog ICD-10.
6.2.3. ICD-10
Die internationale Klassifizierung der Krankheiten muss in Deutschland sowohl im ambulanten als
auch stationären Sektor eingesetzt werden und dient auch der Verschlüsselung der
Todesursachen.
6.2.3.2. Ziel und Aufbau des ICD-10
Lehrziele
M6-LE2.3-1-1 Ziel und Verwendung des ICD-10 kennen K1 W
M6-LE2.3-1-1 Wissen, dass es mehrere Versionen des ICD-10 gibt, -- K1
und wissen, wer diese pflegt.
M6-LE2.3-1-1 Probleme bei der Klassenbildung und -- K2
Kodierungsregeln verstehen.
Der ICD-10-Katalog ist eine Taxonomie. Er gruppiert Krankheiten, Verletzungen und Symptome
hierarchisch. Als Klassifizierungsmerkmale dienen beispielsweise die Anatomie (z.B. alle
Krankheiten des Verdauungstrakts, alle Krankheiten des Nervensystems) oder die Äthiologie (z.B.
alle Krankheiten die durch Infektionen verursacht sind, alle Neubildungen wie Krebs).
Der ICD-10-Katalog dient der Kodierung von Diagnosen und Todesursachen.
Die WHO pflegt den internationalen ICD-10-Katalog. Dieser wird (fast) weltweit unverändert zur
Kodierung von Todesursachen zum Zweck der Todesursachenstatistik genutzt.
Das Deutsche Institut für medizinische Informatik pflegt die deutsche Ausgabe (ICD-10 GM), die
sich durch kleine Modifikationen und die Übersetzung in die deutsche Sprache auszeichnet. Der
ICD-10-GM dient der Verschlüsselung von Diagnosen und damit auch der Abrechnung der
Leistungserbringer mit den Krankenkassen.
Viele Krankheiten lassen sich sowohl nach dem „Ort“ (der Anatomie) als auch der Ursache
(Ätiologie) klassifizieren. Beispielsweise ist der Darmkrebs eine Krankheit des Verdauungstrakts
als auch eine Krebserkrankung. Da Krankheiten aber eindeutig kodiert werden müssen, gibt es
Kodierungsregeln. Eine besagt, dass man zuerst nach der Ätiologie und erst dann nach der
Organmanifestation kodieren muss. D.h. der Darmkrebs ist primär eine Krebserkrankung. Weitere
Klassifizierungsregeln verlangen, dass man so spezifisch wie möglich („endständig“) kodieren
muss. Um Krankheiten, die nicht in eine der bestehenden Klassen passen, oder von denen man
nicht weiß, in welche Klassen Sie einzuordnen sind, ebenfalls endständig kodieren zu können, gibt
es sogenannte Resteklassen.
6.2.4. LOINC
Gesamtlehrplan
Laborwerte, Vitalparameter und Ergebnisse körperlicher Untersuchungen zählen mit zu den

wichtigsten Daten in der medizinischen Dokumentation.
 LOINC
 LOINC
6.2.4.4. Zweck und Aufbau des Ordnungssystems LOINC
Lehrziele
M6-LE2.4-1-1 Wissen, wozu LOINC dient und welche Daten man K1 W
damit kodieren kann
M6-LE2.4-1-1 Wissen wie das Ordnungssystem LOINC aufgebaut ist K1 W
M6-LE2.4-1-1 Wissen, wer LOINC pflegt -- K1
M6-LE2.4-1-1 Einen Vitalparameter oder Laborwert in LONC -- K3
Datenbank finden
LOINC ist ein Ordnungssystem, mit dem sich Untersuchungsergebnisse wie Laborwerte,
Vitalparameter, Ergebnisse von körperlichen Untersuchungen usw. kodieren lassen.
Jeder Wert wird anhand folgender Attribute spezifiziert:
 Komponente (Analyt): Was wird gemessen, z.B. Hämoglobin, systolischer Blutdruck im Sitzen
 Gemessene Eigenschaft (Messgröße), z.B. Massenkonzentration, Druck, Gewicht. Allerdings
spezifiziert LOINC nicht die Einheit, d.h. es unterscheidet beispielsweise nicht, ob die Länge in
Meter, in Zoll oder in Zentimeter bestimmt ist.
 Zeitangabe: Typischerweise ist das ein Zeitpunkt, gelegentlich aber auch ein Zeitraum wie bei
einem 24h-Urin oder 2h nach Gabe der Glukoseinfusion.
 Art der Probe (System), z.B. Vollblut, Urin, Liquor, Augenflüssigkeit
 Skala, z.B. quantitativ (Zahl), ordinal (z.B. groß-mittel-klein), nominal (z.B. Escherichia coli,)
oder als reiner Text wieder Befund einer CT-Untersuchung
 Messmethode (so notwendig), z.B. ob die Messung des Hämoglobins spektroskopisch oder
anhand einer Zählung der roten Blutkörperchen erfolgte.
Das Regenstrief-Institute in Indianapolis pflegt dieses Ordnungssystem, das als Datenbank mit
inzwischen über 60.000 Einträgen zur Verfügung steht. In Deutschland fördert das DIMDI die
Anwendung.
6.2.4.5. Zusammenspiel mit anderen Ordnungssystemen
Lehrziele
M6-LE2.4-2-1 Verstehen, wie LOINC bei HL7 V2 eingesetzt wird. -- K2
Möchte man Laborwerte als Teil einer HL7 V2 Nachricht übertragen, so bietet es sich an, die
Laborparameter (z.B. Hämoglobin im Vollblut) mit Hilfe von LOINC innerhalb des entsprechenden
HL7 V2 Feldes zu kodieren.
LOINC findet auch bei klinischen Dokumenten Anwendung, welche dem HL7-V3-CDA-Standard
genügen. Dieser Standard unterteilt klinische Dokumente wie Arztbriefe in Sektionen,
beispielsweise in eine Sektion mit der Anamnese, eine Sektion mit den Diagnosen usw. Diese
Gesamtlehrplan
Sektionen sind mit LOINC-Codes kodiert und können so von Informationssystemen erkannt und
beispielsweise in eine elektronische Patientenakte übernommen werden.
6.2.5. Klassifizierung von Medikamenten
Einer der größten Kostenfaktoren im Gesundheitswesen stellen die Medikamente dar. Daher hat
der Gesetzgeber besondere Anforderungen an die Klassifizierung von Arzneimitteln gestellt.
 ATC: Anatomisch, therapeutisch, chemische Klassifikation
 DDD: Daily Drug Dose
6.2.5.3. ATC
Lehrziele
M6-LE2.5-1-1 Zweck und Aufbau des Ordnungssystems ATC kennen. -- K1
ATC steht für anatomisch, therapeutisch, chemische Klassifikation. Es handelt sich dabei um eine
Taxonomie, die Arzneimittelwirkstoffe zuerst nach anatomischen, dannnach therapeutischen und
dann nach chemischen Gesichtspunkten klassifiziert. Beispielsweise ist EPO ein Wirkstoff, der
anatomisch für das Blut und die Blutbildenden Organe gedacht ist (KategorieB). Therapeutisch
setzt ma nEPO als ein Mittel gegen Blutarmut (Antianämikum) ein (Kategorie 03). Auf chemischer
Ebene (XA01) ist man dann bei Erythropoetin. Alle Medikamente, die (nur) diesen Wirkstoff
haben, ließen sich dann der Klasse B03XA01 zuweisen.
Das DIMDI definiert zusammen mit der ATC-Klassifikation auch die DDD. Diese entspricht dem
typischen durchschnittlichen Tagesverbrauch und dient dazu, eine Vergleichbarkeit der Kosten
von verschiedenen Herstellern eines Arzneimittel(-wirkstoffs) er erreichen.
6.2.6. Weitere Ordnungssysteme
Zahlreiche weitere Ordnungssysteme sind notwendig, um die semantische Interoperabilität bei
medizinischen Daten sicher zu stellen.
 SNOMED
 OPS
 OID
 monoaxiales Ordnungssystem
 monohierarchisches Ordnungssystem
6.2.6.3. OPS-Katalog
Lehrziele
M6-LE2.6-1-1 Den Zweck und Aufbau des OPS-Katalogs kennen. -- K1
Der OPS-Katalog ist ein vom DIMDI herausgegebenes monohierarchisches, monoaxiales
Ordnungssystem zum Kodieren von Untersuchungen, Prozeduren und Operationen. Die OPS
Ziffern werden v.a. für die Abrechnung benötigt.
6.2.6.4. SNOMED
Lehrziele
Gesamtlehrplan
M6-LE2.6-2-1 Zweck und Aufbau von SNOMED kennen. -- K1

SNOMED-CT ist eine Ontologie, genauer gesagt ein polyaxiales, polyhierarchisches
Ordnungssystem, mit dem sich komplexere Sachverhalte ausdrücken lassen. Beispielsweise ließe
sich mit den bisherigen Ordnungssystemen nicht beschreiben, dass der Versicherungsvertreter
Klaus Walther bei einem Verkehrsunfall in Deutschland mit einer Gehirnerschütterung erlitt.
6.3. Informationssysteme im Gesundheitswesen

6.3.1. Aufgaben von (medizinischen) Informationssystemen
Die Aufgaben und Funktionalitäten von Informationssystemen lassen sich gruppieren, was die
Beurteilung und Vergleichbarkeit der Systeme erleichtert
6.3.1.2. Einteilung der Aufgaben nach Haas
Lehrziele
M6-LE3.1-1-1 Einteilung der Aufgaben nach Haas kennen, die -- K1
Informationssysteme (im Gesundheitswesen)
wahrnehmen.
Man kann die Aufgaben, die Informationssysteme im Gesundheitswesen wahrnehmen, in
folgende Klassen einteilen [Haas]
 Verarbeitungsunterstützung: Berechnung von Abrechnungsziffern, statistische Auswertungen
 Dokumentationsunterstützung: Elektronische Patientenakte, Archivierung
 Organisationsunterstützung: Terminkalender, klinische Behandlungspfade
 Kommunikationsunterstützung (Mensch-Mensch, System-System): E-Maildienste,
Benachrichtigungen, Kommunikationsserver
 Entscheidungsunterstützung: Informationssammlungen, Leitlinien, Warnung bei
Medikamentenwechselwirkung
6.3.2. Klassische Informationssysteme
Informationssysteme gibt es im Gesundheitswesen bereits seit Jahrzehnten. Diese klassischen
Systeme sind in der Regel auf den Einsatz in einer Institution bzw. einem Standort konzipiert.
 KIS: Krankenhaus-Informationssystem
 RIS: Radiologie-Informationssystem
 LIS: Labor-Informationssystem
 PACS: Picture Archiving and Communication System
 Praxisverwaltungs- oder Arztinformationssystem
 DRG-Grouper
6.3.2.3. Klassische IT-Systeme in Krankenhäusern und Arztpraxen
Lehrziele
M6-LE3.2-1-1 Die typischen IT-Systeme in Krankenhäuser und bei -- K1
Arztpraxen nennen können.
Gesamtlehrplan
Die Systeme werden meist nach dem Einsatzgebiet oder den damit verwalteten Daten benannt.
So gibt es:
 Das Krankenhaus-Informationssystem, das oft als Synonym für die Gesamtheit aller IT-
Systeme in einem Krankenhaus verstanden wird. Im engeren Sinn versteht man darunter das
führende System, in dem alle Patienten und abrechnungsrelevanten Daten verwaltet werden.
 In niedergelassenen Praxen kommen die Arztpraxis(verwaltungs-)systeme zum Einsatz, die
u.a. der Dokumentation der Daten, dem Formulardruck und der Abrechnung dienen.
 Die Labor-Informationssysteme (LIS) dienen der Dokumentation, Beauftragung und
Auswertung von Laborwerten, Radiologie-Informationssysteme (RIS) analog der
Dokumentation, Beauftragung, Planung und Befundung von bildgebenden Verfahren wie
Röntgen-, CT-, MRT- und Ultraschalluntersuchungen.
 Sogenannte Picture Archive and Communication Systems (PACS) speichern und verwalten
Bilddaten (DICOM) und spielen eng mit den RIS zusammen.
 Grouper dienen der Berechnung der DRG-Codes v.a. anhand der Diagnose und
Behandlungsdaten.
6.3.3. Telemedizin
Zunehmend nutzt man IT-Systeme für die standortübergreifende Patientenbehandlung. Man
klassifiziert dabei verschiedene Anwendungsfälle.
 E-Health
 Telemedizin
 E-Health
6.3.3.4. Anwendungsfälle und Definitionen
Lehrziele
M6-LE3.3-1-1 Die Begriffe E-Health und Telemedizin erläutern -- K1
können.
M6-LE3.3-1-1 Typische Anwendungsfälle benennen können. -- K1
Gesundheitstelematik und E-Health werden meist synonym für vernetzte Anwendungen im
Gesundheitswesen verwendet, die den Benutzern unabhängig von Raum und Zeit zur Verfügung
steht.
Diese Anwendungen dienen der
 Telekommunikation: Elektronischer Austausch von Nachrichten und Dokumenten wie der e-
Arztbrief, das e-Rezept oder die e-Überweisung
 Teledokumentation: Beispiele sind die elektronische Patientenakte, die elektronische
Gesundheitskarte z.B. mit der Dokumentation des Notfalldatensatzes
 Telekooperation: Tele-Fallbesprechungen, Einholen von Zweitmeinungen sowie alle Formen
der Telemedizin wie Telepathologie, Teleradiologie und Telechirurgie.
6.4. Interoperabilität
6.4.1. Interoperabilität - eine Einführung
Gesamtlehrplan
Eine durchgängige medizinische Versorgung bedingt eine durchgängige Unterstützung durch IT-
Systeme. Diese Unterstützung darf weder an den Grenzen der einzelnen Systeme noch den
Sektorengrenzen enden. Das Ziel besteht folglich darin, ein funktionales und enges
Zusammenspiel der heterogenen IT-Landschaften zu ermöglichen und so Informationen
auszutauschen. In anderen Worten, um Interoperabilität zu erreichen.
 Best-of-Breed
 Holistischer Ansatz
 Synonym
 Homonym
6.4.1.3. Probleme bei mangelnder Interoperabilität
Lehrziele
M6-LE4.1-1-1 Die wichtigsten Gründe nennen können, aus denen K1 W
Interoperabilität angestrebt wird.
M6-LE4.1-1-1 Beispiele nennen können, wodurch Interoperabilität -- K1
auf technischer Ebene erschwert wird. (Heterogenität
der Systeme)
M6-LE4.1-1-1 Beispiele nennen können, wodurch Interoperabilität -- K1
auf inhaltlicher Ebene erschwert wird.
Es gibt viele Gründe, aus denen Systeme zusammengeschaltet werden sollen, was die
Interoperabilität dieser Systeme bedingt:
 Ein sektorenübergreifender Behandlungsprozess erlaubt es, Doppeluntersuchungen zu
vermeiden, bedingt aber, dass die Systeme interoperabel sind und dass es somit
Schnittstellen gibt.
 Auch innerhalb einer Institution hat man beispielsweise bei einem „Best-of-Breed-Ansatz“
zahlreiche Schnittstellen. "Best-of-Breed" bedeutet, dass eine Institution wie ein
Krankenhaus, für jede Aufgabenstellung das jeweils beste klinische Informationssystem kauft.
Das führt zu vielen Systemen vieler Hersteller, die es zu integrieren gilt. Hingegen wählen
Institutionen einem holistischen Ansatz nur ein möglichst umfassendes Informationssystem,
was zu weniger Schnittstellen führt, aber Kompromisse bei der Erfüllung der spezifischen
Anforderungen des Krankenhauses ein.
 Weiter entsteht die Notwendigkeit, Systeme mit einander zu „verschalten“ bei
Unternehmenszusammenschlüssen,
 bei der engeren Einbindung von „Lieferanten“ (z.B. Einweiser, Materiallieferanten) und
„Auftragnehmern“ wie bei der Anschlussbehandlung.
 Weiter erfolgen die Abrechnung und das Berichtswesen an Behörden und
Institutionenebenfalls auf elektronischem Weg. Jede manuelle Datenübernahme würde auch
hier Kosten und Fehler in die Höhe treiben, im schlimmsten Fall in Fehlbehandlungen oder
verzögerten Behandlungen resultieren.
Selbst einfach erscheinende Informationseinheiten bieten zahllose Varianten, in IT-Systemen
abgebildet zu werden. Beispielsweise modellieren viele klinische Informationssysteme einen
Patientennamen als zwei Zeichenketten, eine für den Vornamen, eine für den Nachnamen. Doch
wie geht man mit dem Titel um? Ist der Doktortitel, wie in Deutschland üblich, Teil des
Nachnamens? Wo steht der Geburtsname? Wie geht man mit Personen mit mehreren Namen
und mit Ordensbezeichnungen um? Wie mit Mittel- und Anfangsinitialen? Wie mit Personen aus
Kulturen, die das Konzept aus Vor- und Nachnamen nicht kennen? Wie mit Personen, aus Asien,
Gesamtlehrplan
deren Namen mit anderen Zeichensätzen zu beschreiben wären und die zudem noch über den
Namen in Lautschrift verfügen? Wie mit Personen, die ihren Namen nicht kennen, nennen wollen
oder können?
Weitere Herausforderungen im Kontext der Interoperabilität sind Homonyme, Synonyme,
Messwerte in verschiedenen Einheiten usw. Durch das Zusammenwachsen von Medizintechnik
und IT entsteht die Notwendigkeit, auch die Medizingeräte interoperabel mit den klinischen
Informationssystemen werden zu lassen. Medizingeräte stellen zusätzliche Informationen zur
Verfügung, die hierbei zu berücksichtigen sind.
Informationssysteme bieten meist Schnittstellen an, die sich zum einen dadurch entscheiden,
welche Informationen darüber verfügbar sind, zum anderen wie sie diese Informationen
bereitstellen. Dieses „Wie“ kann sich unterscheiden durch:
 Betriebssystem
 Dateiformat
 Form der Datenspeicherung (relationale DB, nicht-relationale DB, „Flatfiles“, POSIX usw.), Art
und Hersteller der Datenbank, Schnittstelle zur Datenbank z.B. SQL (-Dialekt)
 Programmiersprache
 Datentyp, Zeichenkodierung
 Netzwerkprotokoll
 Ordnungssysteme, Klassifikationssysteme zum Beschreiben/Kodieren von Daten
 Strukturierung der Information z.B. in Datenbanken
6.4.2. Interoperabilitätsebenen
Mangelnde Interoperabilität ist inzwischen kein primäres Problem der Datenübertragung selbst,
sondern der einheitlichen Interpretation dieser Daten.
 Netzwerkprotokolle
 Integrationsserver
 Netzwerkprotokolle
 Integrationsserver
 Integrationstopologien
 Integrationsebenen
6.4.2.4. Das Vier-Ebenen-Modell
Lehrziele
M6-LE4.2-1-1 Die Interoperabilitätsebenen verstehen und K1 W
„Standards“ den Ebenen zuweisen können.
M6-LE4.2-1-1 Wissen, welche Integrationsebenen man -- K1
üblicherweise unterscheidet.
Man unterscheidet vier Interoperabilitätsebenen:
 Die „unterste“ Ebene nennt sich strukturelle Interoperabilität. Sie soll gewährleisten, dass
Daten überhaupt von einem zum anderen Informationssystem übertragen werden. Dies ist
die Ebene des OSI Schichtenmodelles u.a. mit Netzwerkprotokollen. Hier sind Standards und
Begriffe wie TCP/IP, FTP, http, POP, SMTP und VPN anzusiedeln.
 Die nächste Ebene bezeichnet man als syntaktische Interoperabilität. Diese ist gegeben, wenn
man die einzelnen Informationseinheiten in dem (dank struktureller Interoperabilität)
Gesamtlehrplan
übertragenen Datenstrom (auch Dateien zählen hierzu) identifizieren kann. Dateiformate wie
XML oder csv, aber auch für das Gesundheitswesen spezifische Standards wie HL7
ermöglichen dies.
 Semantische Interoperabilität ist erreicht, wenn man die Bedeutung der einzelnen
Informationseinheiten versteht, d.h. wenn alle am Datenaustausch beteiligten Parteien das
gleiche Verständnis dieser Informationseinheit haben. Auf semantischer Ebene wird
beispielsweise geklärt, dass die übertragene Zahl „12“ den Hämoglobinwert eines
bestimmten Patienten an einem bestimmten Tag, gemessen mit einem bestimmten
Messverfahren, gemessen in einer bestimmten Probe (z.B. venöses Blut) und in einer
bestimmten Einheit ist. Auf dieser Ebene sind Homonyme und Synonyme zu klären. Auf
dieser semantischen Ebene operieren die Ordnungssysteme wie ICD, OPS, LOINC und ATC.
 Mit Hilfe der organisatorischen Interoperabilität möchte man übergreifende und einheitliche
Geschäftsprozesse und Benutzerberechtigungen erreichen.
Die meisten Informationssysteme sind mehrschichtig aufgebaut:
 Betriebssystem
 Auf dem Betriebssystem läuft eine Datenbank (-> Persistenzschicht).
 Auf diese greift das Anwendungsprogramm zu (-> Geschäftslogikschicht).
 Eine GUI (Fat-Client oder Browser) (-> Präsentationsschicht) stellt die Informationen dar und
nimmt die Eingaben der Benutzerentgegen.
Auf jeder dieser Ebenen können Daten ausgetauscht werden:
 Betriebssystem: Auf Betriebssystemebene ist der Dateienaustausch ein übliches Vorgehen.
 Persistenzschicht: Abhängig von der Art der Datenspeicherung erfolgt der Zugriff auch über
Dateien oder über SQL in die Datenbank.
 Geschäftslogikschicht: Möchte man auf Ebene der Geschäftslogik Daten austauschen, nutzt
man meist Programmierschnittstellen (API) oder Webservices.
 Präsentationsschicht: Nicht trivial aber möglich ist der Datenaustausch über die grafische
Benutzerschnittstelle (GUI) von Programmen. Im einfachsten Fall integriert man nur die
Darstellung der Informationen wie bei Portalen. Über Techniken wie Screen Scraping lassen
sich Daten aber auch programmatisch eingeben und auslesen.
Bei all diesen Integrationsebenen müssen alle Interoperabilitätsaspekte (strukturell, syntaktisch,
semantisch, organisatorisch) berücksichtigt werden. Die Webservices, um ein Beispiel zu nennen,
gewährleisten nur die strukturelle und syntaktische Interoperabilität. Erst die Nutzung von
Ordnungssystemen würde auch die semantische Interoperabilität sicherstellen.
6.4.2.5. Integrationsserver
Lehrziele
M6-LE4.2-2-1 Die Aufgaben eines Integrationsservers verstehen. -- K1
Integrationsserver nutzt man dazu, den Datenaustausch zwischen verschiedenen
Informationssystemen zu ermöglichen. Diese Integrationsserver greifen über die jeweils
verfügbaren Integrationsebenen auf die einzelnen Systeme zu und stellen Interoperabilität auf
oder zwischen diesen Interoperabilitätsebenen sicher. Beispielsweise greift der Integrationsserver
auf Betriebssystemebene auf die Medikamentenliste, die auf einem System in einer Datei
vorliegt, zu und überträgt diese Informationen über einen Webservice in ein zweites System.
Dabei konvertiert der Integrationsserver möglicherweise auf semantischer Ebene noch die
Kodierung der Inhaltsstoffe der Medikamente von einem Ordnungssystem (z.B. CAS-Nummer) in
ein anderes (z.B. ATC-Code).
Gesamtlehrplan
6.5. HL7 V2
6.5.1. Einführung
Für die Kommunikation im Gesundheitswesen spielen die von HL7, einer internationalen
Standardisierungsorganisation, definierten Standards eine maßgebliche Rolle. Der
Nachrichtenstandard "HL7 Version2" (HL7 V2) wird seit über 20 Jahren verwendet und
regelmäßig aktualisiert. Er ist weit verbreitet, aber ein theoretisches Fundament für
Designentscheidungen fehlt.
6.5.1.2. Anwendungsgebiete
Lehrziele
M6-LE5.1-1-1 Wissen, wo und wofür HL7 V2 eingesetzt wird. K1 W
HL7 V2 hat sich als der Standard zum Austausch von Nachrichten innerhalb der Krankenhäuser,
nicht aber für den intersektoralen Datenaustausch etabliert. HL7 V2 standardisiert nicht den
Aufbau und Austausch von (klinischen) Dokumenten, sondern von Nachrichten. Klinische
Informationssysteme tauschen via HL7 Nachrichten aus beispielsweise über
 Aufnahme, Entlassung und Verlegung von Patienten (Patientendatenverwaltung)
 Anforderung von Laborwerten (Auftragskommunikation)
 Meldung neuer Befunde wie Laborwerten (Befunddatenkommunikation)
 Leistungsdaten (Abrechnung, Controlling)
6.5.1.3. Kritik an HL7 V2
Lehrziele
M6-LE5.1-2-1 Kritik an HL7 V2 kennen. -- K1
HL7 V2 nennt man einen bottom-up-Ansatz, d.h. es fehlt ein theoretisches Fundament für
Designentscheidungen. Auch sind die semantischen Standards nur teilweise spezifiziert. HL7 V2
hat ohne Profile so viele Freiheitsgrade, dass eine direkte Implementierung von
Programmen/Programmkomponenten zum Datenaustausch ohne weitere Abstimmung zwischen
den Herstellern nicht möglich wäre.
6.5.2. Nachrichten und Dokumente
In Krankenhäuser werden sowohl Nachrichten wie die Mitteilung über das Vorliegen eines
Befundes wie komplette Dokumente, beispielsweise Arztbriefe, ausgetauscht.
 Nachricht
 Dokument
 Segment
 Feld
 Nachricht
 Dokument
 Segment
 Feld
Gesamtlehrplan
6.5.2.4. Unterschied von Nachrichten und Dokumenten

Lehrziele
M6-LE5.2-1-1 Den Unterschied von Nachrichten und Dokumenten -- K1
erklären können.
M6-LE5.2-1-1 Wissen, dass HL7 V3 Nachrichten und Dokumente -- K1
standardisiert.
Nachrichten dienen der Kommunikation zwischen Informationssystemen, Dokumente müssen
auch für Menschen lesbar sein. Weiter haben Dokumente einen Autor und müssen(elektronisch)
unterschreibbar sein. Dokumente werden im Gegensatz zu Nachrichten gespeichert. Dokumente
sind im Kontext vollständig. HL7 Nachrichten und Dokumente werden aber beide elektronisch
übertragen, bei HL7 V3 oft im XML-Format.
6.5.2.5. Aufbau von HL7 V2 Nachrichten
Lehrziele
M6-LE5.2-2-1 Wissen, wie eine HL7 V2-Nachricht aufgebaut ist. K1 W
M6-LE5.2-2-1 Verstehen, wie eine HL7-Nachricht aufgebaut ist. -- K2
M6-LE5.2-2-1 Verstehen, dass der Standard festlegt, aus welchen -- K2
Feldern ein Segment eines bestimmten Typs besteht
und welche Datentypen diese Felder haben.
HL7-Nachrichten werden als Text übertragen, dessen Informationseinheiten durch Trennzeichen
getrennt sind. Jede Nachricht besteht aus mehreren Segmenten, die durch einen Zeilenumbruch
(CR) getrennt sind. Das erste Segment heißt Message Header (MSH). Im MSH ist definiert, welche
weiteren Trennzeichen genutzt werden. Segmente sind typischerweise durch ein |-Zeichen in
Felder unterteilt. Ein Feld kann beispielsweise ein Datum, einen Laborwert oder einen
Patientennamen enthalten. Felder können in Komponenten unterteilt sein, beispielsweise der
Patientenname in den Vor- und den Nachnamen. Eine Unterteilung der Komponenten in Sub-
Komponenten ist ebenfalls möglich.
Das erste Feld jedes Segments nennt sich Segment-ID und gibt an, um welchen Typ eines
Segments es sich handelt. Beispiele für Segment-IDs sind MSH (Message Header), PID (Patient
Identification) und EVN (Event). Der HL7-V2-Standard legt für jeden Segmenttyp fest, welche
optionalen und verpflichtenden Felder das Segment enthält. Weiter bestimmt der Standard den
Datentyp für jedes Feld.
Das 9. Feld des MSH-Segments gibt den sogenannten Nachrichtentyp an, der wiederum erkennen
lässt, weshalb die Nachricht ausgelöst wurde (Trigger) und um welche Informationen es sich
handelt
6.5.2.6. HL7 v2 Nachrichtentypen
Lehrziele
M6-LE5.2-3-1 Die Begriffe Message Type und Trigger Event -- K1
verstehen und Beispiele für deren Bedeutung in der
nachrichtenbasierten Kommunikation geben können.
M6-LE5.2-3-1 Verstehen, dass der Standard festlegt, aus welchen -- K2
Segmenten eine Nachricht bestehen kann.
Gesamtlehrplan
Das neunte Feld des MSH-Segments bestimmt den Nachrichtentyp und das auslösende Ereignis
(Trigger Event). Beispiele für Nachrichtentypen sind
 ADT: Aufnahme, Verlegung, Entlassung (Admission, Transfer, Discharge)
 ORU: Unangeforderter Befund (Order response unsolicitated)
 DFT: Leistungsübermittlung (Detailed Financial Transaction)
Der Standard legt fest, welche Ereignisse, die jeweiligen Nachrichtentypen auslösen können. So
kann ein „Trigger Event“ A01 (Patientenaufnahme) nur eine ADT-Nachricht auslösen. Die
Kombination aus Message Type und Trigger Event ergibt den Namen des Nachrichtentyps (z.B.
ADT^A01). Der HL7-V2-Standard bestimmt anhand dieser Kombination auch, welche Segmente in
einer Nachricht dieses Typs vorkommen müssen oder dürfen und welche Segmente mehrfach in
dieser Nachricht verwendet werden dürfen.
6.5.2.7. Datentypen in HL7 V2
Lehrziele
M6-LE5.2-4-1 Wissen, dass HL7 v2 Datentypen standardisiert. -- K1
Wichtigste Datentypen kennen. Beispiele benennen
können.
M6-LE5.2-4-1 Im Standard diese Datentypen nachschlagen können. -- K2
M6-LE5.2-4-1 Verstehen, wie semantische Interoperabilität über das -- K1
Einbinden von Ordnungssystemen (Codesystemen,
Identifikationssystemen) erreicht wird.
HL7 V2 definiert Datentypen für die Werte von Feldern bzw. Attributen. Einige wichtige
Datentypen in V2 sind:
6.5.2.8. Übertragung von HL7 V2 Nachrichten
Lehrziele
M6-LE5.2-5-1 Verstehen, wie HL7 Nachrichten technisch übertragen -- K1
werden.
HL7-Nachrichten liegen textuell vor und werden meist als Datei (z.B. über FTP) oder noch häufiger
über das sogenannte MLL-Protokoll (Minimal Lower Layer Protokoll) übertragen. Dieses Protokoll
setzt direkt auf TCP/IP auf und stellt eine Socket-Verbindung dar, bei der der „HL7-Text“ mit
einem Start- und Endbyte zu Beginn bzw. Ende der Nachricht begrenzt und durch ein weiteres
Byte ("kleiner"CR"größer") abgeschlossen werden.
6.6. DICOM
6.6.1. Einführung
DICOM ist ein Standard, dessen Ursprünge bereits in die 70er Jahre zurückreichen, als die
Vereinigungen der US-amerikanische Radiologen und Medizintechnikhersteller die
Austauschbarkeit v.a. von CT-Bildern herstellerübergreifend gewährleisten wollten.
 Conformance Statement
Gesamtlehrplan
 DICOM
 Conformance Statement
6.6.1.4. Einsatzgebiet von DICOM
Lehrziele
M6-LE6.1-1-1 Wissen wo und wofür DICOM eingesetzt wird. K1 W
DICOM ist ein weltweit eingesetzter Standard, der gewährleisten soll, dass Informationen im
Kontext der medizinischen Bildgebung (z.B. Bilder, Befunde) herstellerübergreifend gespeichert,
übertragen, angefordert, gesucht, gedruckt usw. werden können. DICOM standardisiert somit
mehr als nur ein Datenformat, sondern auch die Kommandos und Nachrichten zum Suchen,
Drucken, Beauftragen von Untersuchungen usw.
Seinen Ursprung hat DICOM in dem ACR-NEMA-Standard, der in den 80er Jahren des 20.
Jahrhunderts durch eine Arbeitsgruppe entwickelt wurde, die aus dem American College of
Radiology (ACR) als Interessenvertretung der Anwender und der National Electrical
Manufacturers Association (NEMA) als Berufsverband des nordamerikanischen
Herstellerverbands.
Wiederholung FL
6.6.1.5. DICOM Conformance Statement
Lehrziele
M6-LE6.1-2-1 Wissen, was ein DICOM Conformance Statement ist: -- K1
Ein Gerät oder Hersteller ist nicht per se DICOM konform. Vielmehr gibt der Hersteller für jedes
Gerät in einem sogenannten DICOM Conformance Statement an, für welche „Bildtypen“
(Information Objects) er welche Dienste wie Drucken, Abspeichern entweder anbietet oder nutzt.
Damit können Käufer von Medizingeräten anhand dieses Conformance Statements prüfen, ob die
Geräte zueinander interoperabel sind, ob beispielsweise das PACS den Dienst „MRT Bild
speichern“ anbietet, den das MRT zum Speichern benötigt.
6.6.2. Datenstruktur und Datenmodell
Das Datenmodell orientiert sich an objektorientierten Konzepten.
 IOD: Information Object (Definition)
 IE: Information Entity
 Real World Information Model
6.6.2.3. Binäre Datenstruktur
Lehrziele
M6-LE6.2-1-1 Die Datenstruktur auf binärer Ebene kennen. Wissen, -- K1
was ein Data-Tag ist.
DICOM Information Objects (beispielsweise ein Bilddatensatz) besteht meistens aus einer Vielzahl
von Quadrupel aus Data-Tag, Datentyp, Länge des Werts und der Wert selbst. Beispielsweise
Gesamtlehrplan
besteht ein Quadrupel mit dem Patientennamen aus dem Tag (0010,0010), dem Datentyp PN
(„Person Name“), der Länge des Namens und dem Namen selbst.
DICOM spezifiziert für jeden Tag den Datentypen wie
 LO (Long String),
 CS (Code String, d.h. mit Verweis auf eine Kodiertabelle) und
 DA (Date).
Der Standard legt auch für jedes Tag die mögliche Kardinalität fest.
6.6.2.4. IOD, IE, Patient, Studie, Serie
Lehrziele
M6-LE6.2-2-1 Die Begriffe IOD und IE kennen. -- K1
M6-LE6.2-2-1 Beispiele für IODs und IEs nennen und mit dem Real -- K1
World Information Model in Beziehung setzen
können.
M6-LE6.2-2-1 Verstehen, dass der DICOM-Standard festlegt, aus -- K2
welchen Attributen, Modulen und Information Entities
ein IOD eines bestimmten Typs (z.B. CT-Bild) besteht.
M6-LE6.2-2-1 Verstehen, dass ein DICOM-Objekt aus vielen -- K2
Quadrupeln aus Tag, Datentyp, Länge und Wert
aufgebaut ist.
Ein DICOM-Objekt wie ein Bild (z.B CT-Bild, Röntgenbild, EKG-Kurve oder histologisches Bilde)
nennt man bei DICOM Information Object Definition IOD
Ein IOD besteht aus mehreren dieser Information Entities IE z.B. Patient, Studie, Serie. Die
Information Entities bilden DICOMs Modell der Welt ab ("Real World Information Model").
Für jeden dieser Patienten können eine oder mehrere Studien angelegt werden. Beispielsweise
könnte es eine Studie im Kontext eines Motorradunfalls geben.
Für jede dieser Studien kann es eine oder mehrere Serien geben. Eine neue Serie wird
beispielsweise für jedes Untersuchungsverfahren begonnen, aber auch wenn sich bei gleichem
Untersuchungsverfahren Messparameter ändern, wenn beispielsweise dem Patienten
Kontrastmittel gegeben wird.
Jede dieser Serien besteht aus einem oder mehreren Bildern (IODs).
Jedes einzelne CT-, Röntgen- oder MRT-Bild, also jedes IOD, besteht aus IE, die alle Informationen
über Studie, Serie und die Bildinformationen selbst enthalten.
Zudem enthält jedes dieser IODs eine IE die eigentlichen Bildinformationen.
Die IEs bestehen selbst wieder aus Modulen, die wiederum aus Quadrupeln zusammengesetzt
sind. Jedes dieser Quadrupel besteht aus einem Tag (eine ID des "Parameters", die pro IOD nur
einmal vorkommen darf), dem Datentyp (des Parameters), der Länge der Nutzlast/des Werts, und
der Nutzlast/dem Wert selbst.
Auch die Bildinformationen finden sich als Wert eines Quadrupels.
Der DICOM Standard legt fest, aus welchen IEs eine IOD besteht, welche Module diese IEs jeweils
enthalten müssen und welche Attribute zu einem Modul gehören.
DICOM legt auch fest, ob die Attribute optional oder verpflichtend sind.
6.6.3. Kommunikation mit DICOM
DICOM definiert nicht nur ein Datenformat sondern auch einen Standard zum Datenaustausch.
Gesamtlehrplan

 Service Object Pair
 Service Class Provider
 Service Class User
 DICOM Message Service Element
6.6.3.3. DIMSE, SOP, SCU, SCP
Lehrziele
M6-LE6.3-1-1 Erklären können, was DICOM standardisiert. -- K1
M6-LE6.3-1-1 Mit den Begriffen SOP, DIMSE, SCU und SCP umgehen -- K1
können.
DICOM standardisiert nicht nur die IODs, sondern auch, was man damit "machen" kann.
Beispielsweise kann man ein
 MRT-Bild speichern
 CT-Bild suchen
 Röntgenbild drucken
Die Substantive in dieser Aufzählung sind die IODs, die Verben sind die Dienste. Diese Dienste
nennt DICOM DIMSE, was für DICOM Message Service Element steht. Die Kombination aus einer
IOD und einem Dienst nennt man Service Object Pair (SOP), z.B. MRT-Bild speichern. Ein Gerät
kann nun solch ein SOP entweder anbieten oder nutzen. Wenn es solch ein SOP nutzt, tritt das
Gerät als Service Class User SCU, wenn es den Dienst anbietet als Service Class Provider SCP auf.
Ein PACS-Gerät wird wahrscheinlich als SCP für die SCP „MRT Bild speichern“ auftreten, das MRT
wird als SCU dieses Dienstes fungieren.

Lehrplan CPMS V20

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Lehrplan CPMS V20

Originaltitel:

Hochgeladen von

Copyright:

Verfügbare Formate

International Certified Professional for Medical Software

Certified Professional for

Thorsten Bonhagen Julia Korus

© 2016 International Certified Professional for Medical Software Board e.V. 2

© 2016 International Certified Professional for Medical Software Board e.V. 2

1. CURRICULUM REGULATORISCHE GRUNDLAGEN 8

1.1. RECHTLICHE GRUNDLAGEN 8

2.1. EINFÜHRUNG IN DAS RISIKOMANAGEMENT 41

2.4.1. ALLGEMEINE ANFORDERUNGEN 54

© 2016 International Certified Professional for Medical Software Board e.V. 4

4. CURRICULUM USABILITY 115

4.1. GRUNDLAGEN DES USABILITY ENGINEERINGS 115

5. CURRICULUM QUALITÄTS- UND DOKUMENTENMANAGEMENT 141

5.1. QUALITÄTSMANAGEMENT 141

5.1.2. DOKUMENTATIONSANFORDERUNGEN AN DAS QUALITÄTSMANAGEMENTSYSTEM 142

6. CURRICULUM MEDIZINISCHE INFORMATIK 156

6.1. GRUNDLAGEN DES GESUNDHEITSWESENS 156

© 2016 International Certified Professional for Medical Software Board e.V. 6

© 2016 International Certified Professional for Medical Software Board e.V. 7

1. Curriculum Regulatorische Grundlagen

1.1. Rechtliche Grundlagen

und deren bestimmungsgemäße Hauptwirkung im oder am menschlichen Körper weder durch

1.1.2.3. Begriffe Advanced Level

© 2016 International Certified Professional for Medical Software Board e.V. 10

 EN ISO 13485 (Qualitätsmanagement)

1.2. Die europäischen Richtlinien und die nationale Umsetzung

1.2.1. Richtlinie 93/42/EWG über Medizinprodukte

© 2016 International Certified Professional for Medical Software Board e.V. 12

Die grundlegenden Anforderungen beinhalten:

© 2016 International Certified Professional for Medical Software Board e.V. 13

© 2016 International Certified Professional for Medical Software Board e.V. 16

© 2016 International Certified Professional for Medical Software Board e.V. 17

Nach Anhang III

 Verordnung über die Verschreibungspflicht von Medizinprodukten (MPVerschrV)

1.3. Die harmonisierten Normen

© 2016 International Certified Professional for Medical Software Board e.V. 23

© 2016 International Certified Professional for Medical Software Board e.V. 26

1.4. Lebenszyklus eines Medizinproduktes

© 2016 International Certified Professional for Medical Software Board e.V. 27

Lehrinhalte Foundation Level

Lehrinhalte Foundation Level

kennen und verstehen.

© 2016 International Certified Professional for Medical Software Board e.V. 31

© 2016 International Certified Professional for Medical Software Board e.V. 32

1.5. Regulatorische Grundlagen für den US-Markt

© 2016 International Certified Professional for Medical Software Board e.V. 33

1.5.1.6. Code of Federal Regulations Title 21

© 2016 International Certified Professional for Medical Software Board e.V. 35

M1-LE5.2-2-1 Die Vorgehensweise für die Klassifizierung eines K1 W

2. CDRH Premarket Review Submission Cover Sheet

© 2016 International Certified Professional for Medical Software Board e.V. 37

1.5.4.3. Begriffe Advanced Level

1.5.4.7. Guidance: Off-The-Shelf Software Use in Medical Devices

© 2016 International Certified Professional for Medical Software Board e.V. 39

© 2016 International Certified Professional for Medical Software Board e.V. 40

2.1. Einführung in das Risikomanagement

© 2016 International Certified Professional for Medical Software Board e.V. 41

M2-LE1.1-1-1 Die Bedeutung des Risikomanagements verstehen und -- K2

© 2016 International Certified Professional for Medical Software Board e.V. 42

Wiederholung der Inhalte aus FL zur Auffrischung.

© 2016 International Certified Professional for Medical Software Board e.V. 43

© 2016 International Certified Professional for Medical Software Board e.V. 44