Basiswissen
Medizinische Software

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: hallo@dpunkt.de.

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 3. Auflage

Die Welt des Medizinprodukterechts dreht sich weiterhin schnell: Die EU-Medizinprodukteverordnungen (MDR und IVDR) haben die EU-Richtlinien weitestgehend abgelöst. Für die Hersteller bedeutet(e) dieser Umstieg eine hohe Belastung, zumal sich die Anzahl der benannten Stellen mehr als halbiert und damit die Verfügbarkeit benannter Stellen stark beeinträchtigt hat.

Für die Firmen und deren Mitarbeitende bleibt es herausfordernd, mit den Interpretationen der neuen Verordnungen, mit den Updates der Normen (z.B. zu den Software-Lebenszyklus-Prozessen und zur Gebrauchstauglichkeit), mit den neuen EU-Leitlinien sowie den Common Specifications Schritt zu halten.

Gleichzeitig nimmt der internationale Wettbewerb zu, neue Themen wie die künstliche Intelligenz und das Internet of Things wollen verstanden und beherrscht sein, und die Entwicklungszyklen werden immer kürzer.

Daher ist es wichtig, dass die Entwicklung medizinischer Software nicht durch unnötige QM-Bürokratie und missverstandene Regularien behindert wird.

Die dritte Auflage dieses Buches soll einen Beitrag dazu leisten, dass Firmen Medizinprodukte, die Software enthalten oder selbst Software sind, schnell, sicher und gesetzeskonform entwickeln können und damit im Markt erfolgreich und den Patienten dienlich sind.

Das Buch wurde um die Veränderungen und Neuerungen seit der letzten Auflage erweitert sowie an den aktualisierten Lehrplan des CPMS-Programms angepasst. Dadurch ist ein weiteres Kapitel zum Thema IT-Sicherheit hinzugekommen. Die bewährte Struktur des Kapitels zu den rechtlichen Grundlagen wurde beibehalten, alle Informationen wurden aber um die Inhalte der neuen Medizinprodukteverordnung ergänzt. Wir haben uns bewusst dazu entschieden, die Anforderungen der drei Richtlinien für Medizinprodukte noch nicht komplett aus dem Inhalt zu entfernen, da diese durch Übergangsfristen und möglicherweise weitere Verschiebungen noch mehrere Jahre relevant sein könnten.

Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf
Konstanz, Würzburg, Seeheim-Jugenheim, im August 2020

Vorwort zur 2. Auflage

Viel hat sich ereignet seit der ersten Auflage dieses Buches:

Skandale, wie der Einsatz gesundheitsgefährdender Brustimplantate, haben die Medizinproduktewelt aufgerüttelt, mit Folgen, deren Tragweite noch immer nicht ganz abschätzbar ist: Die europäischen Gesetzgeber haben die komplette Rechtsprechung überdacht, und es zeichnet sich ab, dass die Medizinprodukterichtlinien durch eine Medizinproduktverordnung abgelöst werden. Auf die daraus entstehenden Folgen für die Hersteller gehen wir in dieser zweiten Auflage ein. Des Weiteren wurden die benannten Stellen noch stärker zu unangekündigten Audits verpflichtet. Umso wichtiger ist es, dass die Hersteller die regulatorischen Forderungen einhalten, wozu dieses aktualisierte Buch ebenfalls beitragen wird.

Kontroverse Diskussionen innerhalb der EU haben dazu geführt, dass scheinbar über Nacht und ohne Übergangsfrist die Risikomanagementnorm EN 14971 zum 1. September 2012 überarbeitet wurde. Natürlich berücksichtigt das überarbeitete Kapitel 4 (»Risikomanagement«) diese Neuerung.

Doch nicht nur die Folgen regulatorischer Änderungen werden wir in dieser zweiten Auflage diskutieren, sondern auch auf aktuelle Trends wie die Mobile Medical Apps eingehen. Fehler in der ersten Auflage haben wir verbessert.

Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf
Konstanz, Würzburg, Seeheim-Jugenheim, im Februar 2015

Vorwort zur 1. Auflage

Wenn sich 70 Personen aus ganz Deutschland zusammenfinden, um – ohne dass sie dafür in irgendeiner Weise vergütet würden – ein Thema zu besprechen, dann scheinen sie ein aufrichtiges und gemeinsames Anliegen zu haben.

Diese Personen, die bei Medizinprodukteherstellern, bei sogenannten benannten Stellen, in Krankenhäusern oder bei Trainingsanbietern arbeiten, stellen sich alle die gleichen Fragen:

Was müssen Entwickler, Auditoren, Betreiber oder Anwender von Medizinprodukten, die Software enthalten oder eigenständige medizinische Software sind, wissen und können? Welche Begriffe müssen sie kennen? Was müssen sie tun, um die rechtlichen Rahmenbedingungen einzuhalten und gleichzeitig effektiv und effizient zu arbeiten? Welche Dokumente müssen sie erstellen? Wie sollen sie das Risikomanagement anwenden? Wie kommen sie zu gebrauchstauglichen Produkten? Und am wichtigsten: Wie schaffen sie es, Software zu entwickeln, mit der die Anwender Patienten schnell und zuverlässig diagnostizieren, therapieren und überwachen können, ohne dabei die Anwender, Patienten und Dritte unnötig zu gefährden?

Es sind genau diese Fragen, die die 70 Personen verbinden, die zu den ersten Mitgliedern und Interessenten des Vereins »International Certified Professional for Medical Software Board« (ICPMSB) zählen. Daher haben sie sich in ihrem Verein das Ziel gesetzt, einen Kanon an Wissen und Fähigkeiten zu definieren und dafür Konzepte zur strukturierten Weiterbildung sowie zur Zertifizierung zu entwickeln.

Dass es dieser Weiterbildung dringend bedarf, wird gleich mehrfach schmerzlich deutlich: Zum einen steigt die Anzahl der Probleme mit Medizinprodukten ständig. So veröffentlicht das Bundesamt für Arzneimittel etwa zwei Hinweise der Hersteller zu Risiken mit Softwarebezug – pro Woche! Des Weiteren fehlt in den meisten Curricula der einschlägigen Hochschulstudiengänge wie Medizintechnik oder Medizininformatik das Thema »gesetzeskonforme Entwicklung medizinischer Software«. In Folge finden sich zahlreiche Firmen, die medizinische Software auf sehr »hemdsärmelige« Art entwickeln. Viele dieser Firmen drängen erstmalig in den für sie neuen Markt Gesundheitswesen. Das Gesundheitswesen ist inzwischen die größte Branche in Deutschland. Eine Branche, die sich dadurch auszeichnet, dass fehlerhafte Produkte besonders direkte und fatale Auswirkungen auf die Gesundheit und das Leben von Menschen haben können.

Möge dieses Buch dazu beitragen, dass die Medizinproduktehersteller ebenso wie deren Kunden (z.B. Krankenhäuser) medizinische Software künftig noch kompetenter, verantwortungsvoller und der Gesundheit von Patienten dienlicher entwickeln, betreiben und anwenden und so der gemeinsamen Verantwortung gerecht werden. Denn damit ginge ein großer Wunsch nicht nur der 70 Personen in Erfüllung.

All diesen unermüdlichen Helfern danken die Autoren von Herzen. Ohne sie wäre das Buch nicht entstanden. Sie werden auch für den weiteren Erfolg des Vereins wesentlich sein. Besonderer Dank gilt unseren Koautoren Thomas Geis, Dr. Christof Gessner und Markus Manleitner.

Allen Lesern, seien es Hersteller von Medizinprodukten, seien es Mitarbeiter von Krankenhäusern, Arztpraxen oder benannten Stellen, seien es Studenten oder Anbieter und Teilnehmer von Trainingsprogrammen, wünschen wir vor allem dies: viel Freude beim Lesen sowie viele Erkenntnisse und Anregungen, die sie direkt im beruflichen Alltag umsetzen können.

Christian Johner, Matthias Hölzer-Klüpfel, Sven Wittorf
Konstanz, Würzburg, Darmstadt, im Februar 2011

Inhaltsübersicht

1Einleitung

2Rechtliche Grundlagen

3Qualitätsmanagement

4Risikomanagement

5Lebenszyklus medizinischer Software

6Gebrauchstauglichkeit

7Dokumentenmanagement

8Medizinische Informatik

9IT-Sicherheit bei Medizinprodukten

Anhang

Abkürzungsverzeichnis

Quellenverzeichnis

Index

Inhaltsverzeichnis

1Einleitung

1.1Aufbau dieses Buches

1.2Initiative »Certified Professional for Medical Software« (CPMS)

1.3Zuordnung der Kapitel dieses Buches zum Curriculum des CPMS

2Rechtliche Grundlagen

2.1Die Rechtslage in Europa

2.1.1Das sogenannte neue Konzept für Produktregulierung innerhalb der Europäischen Union

2.1.2Regulatorische Landkarte für Medizinprodukte

2.2Regulatorische Vorgaben für Medizinprodukte

2.2.1Die Medizinprodukterichtlinie und die Medizinprodukteverordnung

2.2.2Besonderheiten für aktive implantierbare medizinische Geräte

2.2.3Besonderheiten für In-vitro-Diagnostika

2.2.4Die Gesetzgebung in der Bundesrepublik Deutschland

2.3Harmonisierte Normen

2.3.1Das neue Konzept der Europäischen Union

2.3.2Entstehung von harmonisierten Normen

2.3.3Veröffentlichung von harmonisierten Normen

2.4Relevante harmonisierte Normen

2.4.1Qualitätsmanagement (EN ISO 13485)

2.4.2Risikomanagement (EN ISO 14971)

2.4.3Software-Lebenszyklus-Prozesse (EN 62304)

2.4.4Gebrauchstauglichkeit (EN 62366 und EN 60601-1-6)

2.4.5Normenfamilie EN 60601 über medizinische elektrische Geräte

2.5Anwendung und Kontrolle rechtlicher Vorgaben

2.5.1Lebenszyklus eines Medizinproduktes

2.5.2Überwachung von Herstellern

2.5.3Überwachung von benannten Stellen

2.6Weltweite Harmonisierungsbemühungen – die GHTF und das IMDRF

2.7Die Situation in den USA

2.7.1Aufbau der Gesetzgebung

2.7.2Federal Food, Drug, and Cosmetic Act (FD&C Act)

2.7.3Code of Federal Regulations Title 21 (21 CFR)

2.7.4Food and Drug Administration (FDA)

2.7.5Klassifizierung von Medizinprodukten

2.7.6Inverkehrbringen von Medizinprodukten

2.7.7Softwarespezifische Vorgaben

2.7.8Vergleich mit Europa

2.8Weitere internationale Behörden

3Qualitätsmanagement

3.1Aufbau der Norm ISO 13485

3.2Prozessorientierter Ansatz

3.3Dokumentationsanforderungen

3.3.1Qualitätsmanagement-Handbuch

3.3.2Zu dokumentierende Verfahren

3.3.3Dokumente und Aufzeichnungen

3.4Verantwortung der Leitung

3.5Management von Ressourcen

3.6Produktrealisierung

3.6.1Planung

3.6.2Einbindung des Kunden

3.6.3Design und Entwicklung

3.6.4Beschaffung

3.6.5Produktion und Dienstleistungserbringung

3.6.6Umgang mit Kundeneigentum

3.6.7Überwachung von Messmitteln

3.7Messung, Analyse und Verbesserung

3.7.1Sammeln von Rückmeldungen

3.7.2Internes Audit

3.7.3Messung von Prozessen

3.7.4Fehlerhafte Produkte

3.7.5Verbesserung

4Risikomanagement

4.1Einführung

4.1.1Regulatorischer Rahmen

4.1.2Bedeutung des Risikomanagements

4.1.3Begriffe

4.2Die Risikobewertungsmatrix

4.2.1Definition der Achsen

4.2.2Risikoakzeptanz

4.3Verfahren zur Risikoanalyse

4.3.1Vorläufige Gefährdungsanalyse (PHA)

4.3.2Fehlerbaumanalyse (FTA)

4.3.3Fehlermöglichkeits- und -einflussanalyse (FMEA)

4.3.4Abschätzen von Wahrscheinlichkeit und Schweregrad

4.4Die ISO 14971

4.4.1Allgemeine Anforderungen an das Risikomanagement

4.4.2Der Risikomanagementprozess

4.4.3Dokumentation

4.5Zusammenspiel mit anderen Normen

4.5.1Zusammenspiel mit der ISO 13485

4.5.2Zusammenspiel mit der IEC 62304

4.5.3Zusammenspiel mit der IEC 62366-1

4.6Risikomanagement bei Software

4.6.1Definition Softwaresicherheitsklassen

4.6.2Wahrscheinlichkeit und Softwaresicherheitsklassen

4.6.3Dekomposition des Softwaresystems

4.6.4Einflüsse auf die Architektur

4.7Zusammenfassung

5Lebenszyklus medizinischer Software

5.1Softwareentwicklungsprozesse

5.1.1Regulatorische Anforderungen

5.1.2Vorgehensmodelle

5.1.2.1Einführung

5.1.2.2Wasserfallmodell

5.1.2.3V-Modell

5.1.2.4Iterativ-inkrementelle Modelle

5.1.3Prozessbeschreibung

5.1.3.1Einführung

5.1.3.2Prozessgebiete festlegen

5.1.4Konformitätsnachweis

5.1.4.1Einführung

5.1.4.2Audits bestehen

5.2Softwareentwicklung

5.2.1Entwicklungsplanung

5.2.1.1Einführung

5.2.1.2Softwareentwicklung planen

5.2.1.3Entwicklungsprozesse anpassen

5.2.1.4Standards, Methoden und Werkzeuge auswählen

5.2.1.5Projekte planen

5.2.2Softwareanforderungsanalyse

5.2.2.1Einführung

5.2.2.2Softwareanforderungen ableiten

5.2.2.3Softwareanforderungen formulieren

5.2.2.4Softwareanforderungen verifizieren

5.2.3Softwarearchitektur

5.2.3.1Einführung

5.2.3.2Softwarearchitektur beschreiben

5.2.3.3Sicherheitsklasse reduzieren

5.2.3.4Risikobehandlung sicherstellen

5.2.3.5SOUP einsetzen

5.2.3.6Softwarearchitektur verifizieren

5.2.4Softwaredesign

5.2.4.1Einführung

5.2.4.2Softwaredesign beschreiben

5.2.4.3Schnittstellen definieren

5.2.4.4Design verifizieren

5.2.5Implementierung

5.2.5.1Einführung

5.2.5.2Softwareeinheiten implementieren

5.2.5.3Akzeptanzkriterien festlegen

5.2.5.4Codierrichtlinien einsetzen

5.2.5.5Softwareeinheiten verifizieren

5.2.6Integration

5.2.6.1Einführung

5.2.6.2Software-Build beherrschen

5.2.6.3Integrationsstrategie festlegen

5.2.6.4Integration verifizieren

5.2.7Softwaretest

5.2.7.1Einführung

5.2.7.2Testebenen auswählen

5.2.8Tests planen

5.2.8.1Tests durchführen

5.2.8.2Tests verifizieren

5.2.8.3Änderungen prüfen

5.2.9Freigabe

5.2.9.1Einführung

5.2.9.2Entwicklung abschließen

5.2.9.3Software archivieren

5.2.9.4Validierung durchführen

5.3Softwarekonfigurationsmanagement

5.3.1Einführung

5.3.2Konfigurationskontrolle

5.3.2.1Konfigurationselemente identifizieren

5.3.2.2Elemente und Versionen kennzeichnen

5.3.2.3Versionskontrollsystem nutzen

5.3.2.4Softwareversionen benennen

5.3.2.5SOUP identifizieren

5.3.3Änderungskontrolle

5.3.3.1Änderungsanforderungen genehmigen

5.3.3.2Änderungen implementieren

5.3.3.3Rückverfolgbarkeit sicherstellen

5.4Softwareproblemlösung und -wartung

5.4.1Einführung

5.4.2Softwareproblemlösung

5.4.2.1Problemberichte erstellen

5.4.2.2Probleme lösen

5.4.2.3Problemlösung verifizieren

5.4.2.4Trends analysieren

5.4.3Softwarewartung

5.4.3.1Wartung planen

5.4.3.2Rückmeldungen behandeln

5.4.3.3Änderung implementieren

5.4.3.4Software freigeben

5.5Umgang mit älterer Software

5.5.1Einführung

5.5.2Risikomanagement

5.5.2.1Rückmeldungen auswerten

5.5.2.2Risikomanagementaktivitäten durchführen

5.5.3Umgang mit Lücken

5.5.3.1Lücken identifizieren

5.5.3.2Aktivitäten planen

5.5.3.3Lücken schließen

5.5.4Dokumentation

5.5.4.1Version dokumentieren

5.5.4.2Nutzung begründen

6Gebrauchstauglichkeit

6.1Einführung

6.1.1Bedeutung der gebrauchstauglichkeitsorientierten Entwicklung

6.1.2Übersicht

6.1.3Definitionen

6.2Regulatorisches Umfeld

6.2.1EU-Verordnungen, Gesetze und Behörden

6.2.2Normen

6.3Weg zu validen Anforderungen

6.3.1Benutzer identifizieren und charakterisieren

6.3.2Kontext erheben und Zweckbestimmung festlegen

6.3.3Nutzungsanforderungen ableiten

6.4Benutzungsschnittstelle konzipieren

6.4.1Nutzungsszenarien für jede zu unterstützende Kernaufgabe konstruieren

6.4.2Benutzungsschnittstelle spezifizieren

6.4.3Prototyp entwerfen und prüfen

6.5Prüfung: Verifizierung und Validierung

6.5.1Inspektionsverfahren

6.5.2Teilnehmende Beobachtung (Usability-Test)

6.5.3Qualitative und quantitative Benutzerbefragungen

6.5.4Zusammenfassung der Prüfverfahren

6.6IEC-62366-1-konforme Dokumentation

6.6.1Gebrauchstauglichkeitsorientierter Entwicklungsprozess

6.6.2Gebrauchstauglichkeitsakte

6.7UOUP: Benutzer-Produkt-Schnittstellen unbekannter Herkunft

6.8Zusammenfassung

7Dokumentenmanagement

7.1Einführung

7.2Allgemeine Anforderungen an Dokumente

7.3Geforderte Dokumentation

7.3.1Qualitätsmanagement

7.3.2Risikomanagementakte

7.3.3Gebrauchstauglichkeitsakte

7.3.4Dokumentation der Softwareentwicklung

7.3.5Technische Dokumentation

7.3.6Sonstige Dokumente

7.3.7Übersicht über geforderte Dokumente

7.4Umgang mit Dokumenten

7.5Zusammenfassung

8Medizinische Informatik

8.1Einführung

8.1.1Gesundheitswesen

8.1.2Informationssysteme

8.2Interoperabilität

8.2.1Interoperabilitätsebenen

8.2.2Kommunikationsstandards

8.2.3Semantische Standards

8.3Zusammenfassung

9IT-Sicherheit bei Medizinprodukten

9.1Einführung

9.1.1Probleme mit der IT-Sicherheit

9.1.2IT-Sicherheit: Begriffsdefinition und Ziele

9.1.3Das STRIDE-Modell

9.2Regulatorische Rahmen

9.2.1MDR und IVDR

9.2.2Normen

9.2.3MDCG 2019-16

9.2.4Nationale Vorgaben für Medizinprodukte

9.2.5Vorgaben an die IT-Sicherheit, die nicht spezifisch für Medizinprodukte gelten

9.3IT-Sicherheit im Produktlebenszyklus

9.3.1Allgemeines

9.3.2Zweckbestimmung und Stakeholder-Anforderungen

9.3.3System- und Softwareanforderungen

9.3.4System- und Softwarearchitektur

9.3.5Testaktivitäten

9.3.6Softwarefreigabe

9.3.7Überwachung des Produktes im Markt nach dem Inverkehrbringen

9.4Produktanforderungen

9.4.1Authentifizierung und Autorisierung

9.4.2Daten und Kommunikation

9.4.3Audit-Log

9.4.4Begleitmaterialien

9.5Zusammenfassung

Anhang

Abkürzungsverzeichnis

Quellenverzeichnis

Index

1Einleitung

In atemberaubender Geschwindigkeit wächst der Anteil der Wertschöpfung, der durch Software generiert wird. Das gilt auch für den Markt der Medizinprodukte. Besonders offenbart sich dieser Trend bei eigenständiger Software wie Diagnose- oder Therapieplanungssystemen. Aber auch bei vielen klassischen Medizingeräten hängt die Wettbewerbsfähigkeit davon ab, wie schnell und zuverlässig Informationen verarbeitet und dem medizinischen Personal zur Verfügung gestellt werden. Das betrifft beispielsweise die Bildverarbeitung in CTs oder Kernspingeräten ebenso wie die Navigationssysteme für die Chirurgie.

Als weiterer Trend lässt sich das Zusammenwachsen von Medizintechnik und Medizin-IT beobachten: Es gibt kaum ein Medizingerät, das nicht in ein Netzwerk einzubinden ist und das nicht mit klinischen Informationssystemen Daten austauschen muss. Die viel diskutierte Telematikinfrastruktur zielt sogar auf eine deutschlandweite Vernetzung von medizinischen Systemen.

Dieser technologische Fortschritt bedeutet jedoch nicht nur große Chancen im Sinne einer wirkungsvolleren, schnelleren und kosteneffizienteren Diagnostik und Therapie. Er bedeutet auch zusätzliche Risiken für Patienten, Anwender und Dritte. Diese Risiken führen zu Gesundheitsschädigungen – bis hin zum Tod. Künftige Entwicklungen wie die personalisierte Medizin, die auf Methoden der Bioinformatik und Molekularmedizin basiert, werden es sicher nicht einfacher machen, ein ausgewogenes Chancen-Risiko-Verhältnis dieser neuen Technologien und Verfahren zu wahren.

Als Reaktion auf vermehrte Probleme, vor allem mit Bezug zur Software, verschärfen viele Länder seit nun fast einem Jahrzehnt die regulatorischen Vorgaben.

• Im Jahr 2010 wurde das Medizinproduktegesetz (MPG) novelliert.
• Im Jahr 2010 wurde die Norm IEC 80001-1 über das Risikomanagement von IT-Netzwerken verabschiedet.
• 2012 erschien die ISO 14971:2012, in der Risiken nicht mehr einfach als akzeptabel klassifiziert werden dürfen.
• Seit 2013 haben die benannten Stellen (verstärkt) begonnen, unangekündigte Audits durchzuführen.
• Die FDA hat in diesen Jahren zahlreiche Guidance-Dokumente veröffentlicht u. a. zu Medical Apps, zur Cybersecurity und zum Thema künstliche Intelligenz.
• Die Auditoren bauen die eigene Softwarekompetenz aus und verschärfen die Audits.
• Seit dem Jahr 2017 werden die Medizinprodukterichtlinien nach und nach durch Verordnungen abgelöst. Diese legen wesentlich strengere Maßstäbe an den Nachweis der Wirksamkeit von Medizinprodukten an und erhöhen massiv die Verpflichtungen für alle Wirtschaftsakteure im Gesundheitswesen, die mit Medizinprodukten umgehen.

Diese erhöhten regulatorischen Anforderungen führen aber nicht zwangsläufig und unmittelbar zu besseren, weil sicheren Medizinprodukten. Sie führen jedoch in den meisten Fällen zu einem erhöhten Aufwand bei Herstellern und Betreibern, besonders die Dokumentation betreffend. Häufig empfinden es beide als einen Spagat, die regulatorischen Anforderungen erfüllen zu müssen und den dabei entstehenden Aufwand vertretbar zu halten.

1.1Aufbau dieses Buches

In den folgenden Kapiteln will dieses Buch darlegen, dass es hier nicht notwendigerweise um einen Kompromiss geht, sondern es will Wege aufzeigen, mit denen eine Entwicklung (und der Betrieb) nach Best Practices implizit zur Gesetzeskonformität und gleichzeitig zu einem effektiven, kosten- und zeitsparenden Arbeiten führt. Und genau das möchten die Autoren der Normen auch erreichen. Es geht somit nicht um Kompromisse, sondern vielmehr um eine Portion gesunden Menschenverstand.

Kapitel 2 führt in die rechtlichen Grundlagen ein. Diese zu kennen und zu verstehen ist die Grundvoraussetzung für das Verständnis der weiteren Kapitel. Nach dem Lesen dieses Kapitels sollte es klarer sein, wie Richtlinien, Gesetze, Verordnungen und Normen ineinandergreifen und wo man bei welchen Fragen nachschauen muss.

Kapitel 3 stellt die ISO 13485 vor. Diese Norm nennt Anforderungen an ein Qualitätsmanagement und ist für die medizinische Software die unspezifischste Norm. Sie gibt jedoch den »großen Rahmen« vor.

Alle für medizinische Software relevanten Normen verweisen auf das Risikomanagement. Ohne ein adäquates Risikomanagement lässt sich kein Audit bestehen. Nur wer die Risiken seines Medizinproduktes kennt, kann viele Fragen beantworten, die im Laufe der Spezifikation, beim Entwickeln und dem Testen von medizinischer Software auftauchen. Daher widmet sich das Kapitel 4 ausschließlich dem Thema Risikomanagement und stellt die entsprechenden Bezüge zu den folgenden Kapiteln her.

Zu diesen Kapiteln zählt das Kapitel 5 zum Lebenszyklus medizinischer Software. Hier geht es sowohl um Aspekte und Best Practices des Software Engineering als auch um die Forderungen der IEC 62304. Für Softwarearchitekten und Programmierer wird dieses Kapitel eines der wichtigsten sein.

Das wahrscheinlich am meisten unterschätzte und gleichzeitig das bedeutendste Thema ist die »Usability«, die Gebrauchstauglichkeit, der Medizinprodukte. Fast alle Hersteller glauben zu wissen, was ihre Kunden benötigen, glauben, dass man durch ein Befragen dieser zu den Anforderungen kommt. Die Alltagsrealität kennt aber Feststellungen wie »die Kunden wollen jetzt etwas anderes« oder »es gibt neue oder geänderte Anforderungen«. Und genau diese Feststellungen sind ein trauriger Beweis des Gegenteils. Ebenso wie die Statistik der FDA, die 70% aller softwarebezogenen Rückrufe auf mangelnde Gebrauchstauglichkeit zurückführt. Aus diesem Grund geht das Kapitel 6 dediziert auf dieses Thema und die dazu relevanten Normen ein, die IEC 60601-1-6 und IEC 62366.

Gleichsam als verbindende Klammer um die vorangegangenen Kapitel dient das Kapitel 7 zum Dokumentenmanagement. Es hat zum Ziel, die wichtigsten Anforderungen an die Erstellung und Lenkung von Dokumenten zu erläutern und Hinweise zu einer Dokumentenlandschaft, also dem Aufteilen der Dokumente auf die verschiedenen Akten, zu geben.

Medizinprodukte sind wie oben beschrieben heute nur selten als isolierte Systeme zu sehen. Vielmehr müssen sie in einen Verbund aus anderen Medizingeräten und Informationssystemen integriert werden und mit diesen zusammenspielen. Die Interoperabilität ist somit eine wesentliche Voraussetzung. Kapitel 8 »Medizinische Informatik« geht der Frage nach, welche Systeme wie zu integrieren sind und welche Standards und Klassifikationen es auf den unterschiedlichen Integrationsebenen zu kennen und zu beachten gilt. Das 2020 in den Lehrplan aufgenommene Thema »IT-Sicherheit« wird in Kapitel 9 behandelt.

1.2Initiative »Certified Professional for Medical Software« (CPMS)

Genauso wie Normen helfen sollen, einheitliche Standards – in diesem Fall bei der Entwicklung medizinischer Software – zu schaffen, können Zertifizierungsprogramme dazu beitragen, einen einheitlichen Kanon an Wissen zu definieren, über den Personen verfügen sollen, die medizinische Software normen- und gesetzeskonform entwickeln, zulassen oder betreiben. Solch ein Kanon wird nur dann Anerkennung finden, wenn er durch ein unabhängiges Gremium erarbeitet, weiterentwickelt und geprüft wird.

Genau dieses Ziel hat sich der Verein »International Certified Professional for Medical Software Board e.V.« (ICPMSB e.V.) gesetzt. Seine Mitglieder – z.B. Vertreter von Herstellern, benannten Stellen, Trainingsanbietern und Beratern – definieren die Lehrinhalte, Lernziele und Prüfungsmodalitäten. Der Verein akkreditiert Trainingsanbieter und Institutionen, welche die Prüfungen abnehmen, und stellt so eine Einheitlichkeit und Vergleichbarkeit der Lehr- und Prüfungsinhalte sowie Prüfungsmodalitäten sicher.

Dieses Buch basiert auf dem Curriculum, welches das Gremium des ICPMSB e.V.¹ erarbeitet hat, das die Lehrinhalte und Lernziele definiert. Seine Kapitelstruktur deckt sich mit den Modulen des Basiscurriculums.

1.3Zuordnung der Kapitel dieses Buches zum Curriculum des CPMS

Die folgende Tabelle listet die bei Drucklegung gültige Kapitelstruktur des CPMS (v3.0) auf und verweist auf das Kapitel innerhalb dieses Buches, in dem die dortigen Themen behandelt werden. Da sich die Lernziele und die Struktur des Lehrplans mit fortschreitenden Veränderungen der Regularien ebenfalls verändern werden, ist eine jeweils aktuelle Tabelle online unter www.dpunkt.de/cpms verfügbar.

CPMS Curriculum v3.0		Buchkapitel
Kapitel	Titel
1	Curriculum Regulatorische Landschaft	Kapitel 2
1.1	Rechtliche Grundlagen	Abschnitt 2.1 und 2.3
1.1.1	Begriffe und Akteure	Abschnitt 2.1.1
1.1.2	Rechtliche Grundlagen in Europa	Abschnitt 2.1.1 und 2.3
1.2	Die europäischen Verordnungen	Abschnitt 2.2.1
1.2.1	Die Medizinprodukteverordnung (MDR)	Abschnitt 2.2.1
1.2.3	Umsetzung in nationales Recht	Abschnitt 2.2.4
1.3	Die harmonisierten Normen	Abschnitt 2.3 und 2.4
1.3.1	EN ISO 13485	Abschnitt 2.4.1
1.3.2	EN ISO 14971	Abschnitt 2.4.2
1.3.3	EN 62304	Abschnitt 2.4.3
1.3.4	EN 62366	Abschnitt 2.4.4
1.3.5	Die Normenfamilie EN 60601-x	Abschnitt 2.4.5
1.4	Kontrollen	Abschnitt 2.5
1.4.1	Kontrollen im Lebenszyklus eines Medizinprodukts	Abschnitt 2.5
1.4.2	Überwachung durch Behörden und Benannte Stellen	Abschnitt 2.5
1.5	Regularien außerhalb der EU	Abschnitt 2.7 und 2.8
1.5.1	Regulatorische Grundlagen für den US-Markt	Abschnitt 2.7
1.5.2	Zulassungsverfahren in anderen Ländern	Abschnitt 2.8
2	Curriculum Risikomanagement	Kapitel 4
2.1	Einführung in das Risikomanagement	Abschnitt 4.1
2.1.1	Regulatorische Forderungen	Abschnitt 4.1.1
2.1.2	Begriffsdefinitionen	Abschnitt 4.1.2
2.1.3	Risikomanagementplanung	Abschnitt 4.1.2
2.1.4	Risikomanagementakte	Abschnitt 4.4.3
2.2	Der Risikomanagement-Prozess nach ISO 14971	Abschnitt 4.4
2.2.1	Allgemeine Anforderungen	Abschnitt 4.4.2
2.2.2	Der Risikomanagementprozess	Abschnitt 4.4.2
2.2.3	Zweckbestimmung und bestimmungsgemäßer Gebrauch	Abschnitt 4.4.2
2.2.4	Gefährdungs- und Risikoanalyse	Abschnitt 4.4.2
2.2.5	Risikobewertungsmatrix	Abschnitt 4.2
2.2.6	Risikobewertung und Risikoakzeptanz	Abschnitt 4.2.2 und 4.4.2
2.2.7	Risikobeherrschung	Abschnitt 4.4.3
2.2.8	Risiko-/Nutzenbewertung	Abschnitt 4.4.2
2.2.9	Gesamt-Restrisiko und Risikomanagementbericht	Abschnitt 4.4.3
2.2.10	Nachgelagerte Phase	Abschnitt 4.4.2
2.3	Verfahren zur Risikoanalyse	Abschnitt 4.3
2.3.1	Grundlegendes zu Risikoanalyse	Abschnitt 4.3
2.3.2	Preliminary Hazard Analysis	Abschnitt 4.3.1
2.3.3	Fault Tree Analysis	Abschnitt 4.3.2
2.3.4	Failure Mode and Effects Analysis (FMEA)	Abschnitt 4.3.3
2.4	Dokumentation	Abschnitt 4.4.3
2.5	Risikomanagement bei Software	Abschnitt 4.3 und 4.4
2.6	IEC 80002-1	Abschnitt 4.5.2
3	Curriculum Software-Engineering	Kapitel 5
3.1	Softwareentwicklungsprozesse	Abschnitt 5.1
3.2	Entwicklungsplanung	Abschnitt 5.2.1
3.3	Software-Anforderungsanalyse	Abschnitt 5.2.2
3.3.1	Anforderungen ermitteln	Abschnitt 5.2.2.2
3.3.2	Anforderungen dokumentieren	Abschnitt 5.2.2.3
3.3.3	Anforderungen verifizieren	Abschnitt 5.2.2.4
3.3.4	Anforderungen verwalten	Abschnitt 5.2.2
3.4	Softwarearchitektur	Abschnitt 5.2.3
3.4.1	Softwarearchitektur beschreiben	Abschnitt 5.2.3.2
3.4.2	Sicherheitsklassen	Abschnitt 5.2.3.3 und 4.6
3.4.3	Risikobehandlung sicherstellen	Abschnitt 5.2.3.4
3.4.4	Softwarearchitektur verifizieren	Abschnitt 5.2.3.6
3.5	SW-Design	Abschnitt 5.2.4
3.5.1	Softwaredesign beschreiben	Abschnitt 5.2.4.1
3.5.2	Schnittstellen definieren	Abschnitt 5.2.4.3
3.5.3	Design verifizieren	Abschnitt 5.2.4.4
3.6	SW-Implementierung	Abschnitt 5.2.5
3.6.1	Softwareeinheiten implementieren	Abschnitt 5.2.5.2
3.6.2	Akzeptanzkriterien festlegen	Abschnitt 5.2.5.3
3.6.3	Codierrichtlinien einsetzen	Abschnitt 5.2.5.4
3.6.4	Softwareeinheiten verifizieren	Abschnitt 5.2.5.5
3.7	Software-Integration	Abschnitt 5.2.6
3.8	Softwaretest	Abschnitt 5.2.7 und 5.2.8
3.8.1	Allgemeine Anforderungen aus der IEC 62304	Abschnitt 5.2.7 und 5.2.8
3.8.2	Verifizierung vs. Validierung	Abschnitt 5.2.9.4
3.9	Software-Freigabe	Abschnitt 5.2.9
3.10	Softwarekonfigurationsmanagement (im LP alt 5.2)	Abschnitt 5.3
3.10.1	Konfigurationselemente	Abschnitt 5.3.1
3.10.2	Notwendigkeit des Konfigurationsmanagements	Abschnitt 5.3.1
3.10.3	Konfigurationselemente identifizieren	Abschnitt 5.3.2.2
3.10.4	Werkzeuge für das Konfigurationsmanagement	Abschnitt 5.3.2.3
3.10.5	Konfigurationsmanagementplan	Abschnitt 5.3.2.1
3.10.6	Änderungsmanagement	Abschnitt 5.3.3
3.11	Software-Wartung	Abschnitt 5.4
3.11.1	Planung der Software-Wartung	Abschnitt 5.4.3.2
3.11.2	Analyse von Problemen und Änderungen	Abschnitt 5.4.3.2 und 5.4.3.3
3.11.3	Implementierung von Änderungen	Abschnitt 5.4.3.3 und 5.4.3.4
3.12	Software-Problemlösung	Abschnitt 5.4
3.13	Traceability im SW-Entwicklungsprozess	Abschnitt 5.2.2.4
3.13.1	Grundlagen	Abschnitt 5.2.2.4
3.13.2	Tracing durchführen	Abschnitt 5.2.2.4
3.14	Software of Unknown Provenance (SOUP)	Abschnitt 5.2.3.5
3.14.1	Definition und Beispiele für SOUP	Abschnitt 5.2.3.5
3.14.2	Umgang mit Software of Unknown Provenance	Abschnitt 5.3.2.5, 4.3.3, 5.4.3.1 und 5.2.3.5
4	Curriculum Usability	Kapitel 6
4.1	Grundlagen Usability	Abschnitt 6.1
4.1.1	Allgemeine Anforderungen	Abschnitt 6.1.1
4.1.2	Begrifflichkeiten im Kontext der Gebrauchstauglichkeit	Abschnitt 6.1.3 und 6.2.2
4.2	Regulatorische Forderungen	Abschnitt 6.2
4.2.1	Regulatorische Anforderungen (Europa)	Abschnitt 6.2.1
4.2.2	Normen und weitere Richtlinien	Abschnitt 6.2.2
4.3	Forderungen der IEC 62366-1	Abschnitt 6.2.2
4.4	Vom Nutzungskontext zu Nutzungsanforderungen	Abschnitt 6.3
4.4.1	Grundlagen	Abschnitt 6.3.1
4.4.2	Nutzungskontext	Abschnitt 6.3.2
4.4.3	Ableiten der Nutzungsanforderungen	Abschnitt 6.3.3
4.5	Benutzungsschnittstelle	Abschnitt 6.4
4.5.1	Benutzungsschnittstelle konzipieren	Abschnitt 6.4.2
4.5.2	Benutzungsschnittstelle und Risiken	Abschnitt 6.6.2
4.6	Methoden der Evaluierung	Abschnitt 6.5
4.6.1	Grundlagen	Abschnitt 6.5
4.6.2	Formative Evaluation	Abschnitt 6.5
4.6.3	Summative Evaluation	Abschnitt 6.5
4.7	Dokumentation	Abschnitt 6.6
5	Curriculum Qualitäts- und Dokumentenmanagement	Kapitel 3 und 7
5.1	Qualitätsmanagement	Kapitel 3
5.1.1	Prozessorientierter Ansatz	Abschnitt 3.2
5.1.2	Dokumentationsanforderungen an das Qualitätsmanagementsystem	Abschnitt 3.3
5.2	Allgemeine Anforderungen an die Dokumentation	Kapitel 7
5.2.1	Lebenszyklus von Dokumenten und Aufzeichnungen	Abschnitt 7.4
5.2.2	Anforderungen an die Erstellung von Dokumenten	Abschnitt 7.2
5.2.3	Anforderungen an die Prüfung und Freigabe von Dokumenten	Abschnitt 7.4
5.3	Geforderte Dokumentation	Abschnitt 7.3
5.3.1	Grundlagen	Abschnitt 7.3
5.3.2	Die Technische Dokumentation	Abschnitt 7.3.5
6	Curriculum Medizinische Informatik	Kapitel 8
6.1	Informatik im Gesundheitswesen	Abschnitt 8.1.1
6.1.1	Grundlagen	Abschnitt 8.1.1
6.1.2	Daten im Gesundheitswesen	Abschnitt 8.1.1
6.1.3	Informationssysteme	Abschnitt 8.1.2
6.2	Interoperabilität	Abschnitt 8.2
6.2.1	Prinzipien der Interoperabilität	Abschnitt 8.2.1
6.2.2	Ordnungssysteme	Abschnitt 8.2.3
6.2.3	Interoperabilität medizinischer Daten	Abschnitt 8.2.2
6.2.4	Interoperabilität von Nachrichten	Abschnitt 8.2.2
6.2.5	Interoperabilität von Prozessen	Abschnitt 8.2.2
6.2.6	Praktische Umsetzung der Interoperabilität	Abschnitt 8.2
7	Curriculum IT Security	Kapitel 9
7.1	Allgemeine Anforderungen	Abschnitt 9.1 und 9.2
7.2	Anforderungen an die Prozesse	Abschnitt 9.3
7.3	Anforderungen an das Produkt	Abschnitt 9.4

2Rechtliche Grundlagen

Dieses Kapitel beschreibt die rechtlichen Rahmenbedingungen, unter denen in Deutschland und international Medizinprodukte entwickelt werden müssen. Es wirft zunächst einen Blick auf die Rechtslage in Europa und erläutert danach die europäischen Regularien, die sich mit Medizinprodukten beschäftigen. Es fasst die anwendbaren Normen zur Erfüllung dieser Regularien zusammen. Die nachfolgenden Kapitel dieses Buches gehen im Detail darauf ein und zeigen auf, wie diese regulatorischen Vorgaben die Planung, Entwicklung und Herstellung eines Medizinproduktes beeinflussen. Nach der Schilderung der Situation in Europa gibt der letzte Teil dieses Kapitels einen Überblick über internationale Anstrengungen und die Situation in den USA.

Neueinsteiger in die Thematik sollten dieses Kapitel von Anfang bis Ende durchlesen und sich nicht von der hohen Informationsdichte abschrecken lassen. Erfahreneren Lesern soll es als Nachschlagemöglichkeit dienen.

2.1Die Rechtslage in Europa

2.1.1Das sogenannte neue Konzept für Produktregulierung innerhalb der Europäischen Union

Eines der großen europäischen Ziele ist der Abbau von Handelshemmnissen innerhalb des europäischen Binnenmarktes und die technische Harmonisierung bestimmter Produktgruppen. Hierzu wurde 1985 das sogenannte »neue Konzept« (engl. New Approach) eingeführt¹. Im Sinne dieses neuen Konzeptes wurden seitdem für über 30 Produktgruppen europäische Richtlinien und Verordnungen erstellt. Neben Medizinprodukten sind dies z.B. Spielzeuge, Messgeräte, einfache Druckbehälter, Maschinen, Verpackungen und Verpackungsabfälle, Explosivstoffe für zivile Zwecke, Sportboote oder Aufzüge. Diese Richtlinien und Verordnungen beruhen auf den folgenden Prinzipien²:

• Die Harmonisierung beschränkt sich auf die wesentlichen Anforderungen.
• Nur Produkte, die den wesentlichen Anforderungen entsprechen, können in den Verkehr gebracht oder in Betrieb genommen werden.
• Bei [Konformität mit den] harmonisierten Normen, deren Fundstellen im Amtsblatt veröffentlicht und die in nationale Normen umgesetzt worden sind, ist eine Übereinstimmung mit den entsprechenden wesentlichen Anforderungen anzunehmen.
• Die Anwendung harmonisierter Normen oder anderer technischer Spezifikationen bleibt freiwillig, und den Herstellern steht die Wahl jeder technischen Lösung frei, solange die Konformität mit den wesentlichen Anforderungen gewährleistet ist.
• Hersteller haben die Wahl zwischen verschiedenen Konformitätsbewertungsverfahren, die in den anwendbaren Richtlinien vorgesehen sind.

Europäische Richtlinien

Die meisten Produktgruppen werden derzeit noch durch europäische Richtlinien reguliert. Diese Richtlinien haben aber in den Mitgliedsländern noch keinen rechtsverbindlichen Charakter; sie müssen zuerst innerhalb einer bestimmten Frist in nationales Recht umgesetzt werden. Allein dieses Recht ist die Grundlage für Hersteller, allerdings zitieren und verweisen diese Gesetze oft auf die Richtlinien, sodass eine enge inhaltliche Übereinstimmung vorhanden ist. Der Hauptteil der Richtlinien beschäftigt sich mit Regeln zum freien Handel und gibt keinerlei technische Vorgaben. Technische Vorgaben werden in den sogenannten wesentlichen oder grundlegenden Anforderungen (engl. Essential Requirements) immer in Anhang I einer Richtlinie zusammengefasst. Zum Nachweis deren Einhaltung können sogenannte harmonisierte Normen herangezogen werden, die sich mit einzelnen Anforderungen auf technischer Ebene beschäftigen. Welche Normen dies sind, wird durch die Europäische Kommission festgelegt und veröffentlicht. Die Normen selbst werden von Fachgremien erstellt und von den entsprechenden nationalen oder internationalen Normungsinstitutionen veröffentlicht. Die Mitarbeit in den Fachgremien steht allen Interessierten offen. Die wichtigsten Normen werden in Abschnitt 2.4 vorgestellt. Die Einhaltung aller wesentlichen Anforderungen wird durch das sogenannte Konformitätsbewertungsverfahren nachgewiesen und bestätigt. Auf dieses wird in Abschnitt 2.2.1 näher eingegangen.

Europäische Verordnungen

Da die Umsetzung von europäischen Richtlinien in nationale Gesetze ein recht zeitaufwendiger, allerdings rein formaler Akt ist, wurde in den vergangenen Jahren die Regulierung bei vielen Produktgruppen von Richtlinien auf Verordnungen umgestellt. Europäische Verordnungen gelten im Gegensatz zu europäischen Richtlinien in den Mitgliedsländern unmittelbar und müssen nicht in nationales Recht umgewandelt werden, sondern sind diesen im Konfliktfall sogar übergeordnet. Dies wird als »Durchgriffswirkung« bezeichnet. Auch europäische Verordnungen listen in ihren Anhängen die zu erfüllenden grundlegenden Anforderungen auf und ermöglichen den Nachweis deren Erfüllung durch Anwendung von harmonisierten Normen.