Basiswissen Medizinische Software: Aus- und Weiterbildung zum Certified Professional for Medical Software

Von Christian Johner, Matthias Hölzer-Klüpfel und Sven Wittorf

Das Basiswerk für die Entwicklung von Software als Medizinprodukt

• Kompakter, umfassender Überblick über die relevanten Gebiete der normenkonformen Entwicklung von medizinischer Software
• Zur Vorbereitung auf die Prüfung zum »Certified Professional for Medical Software»

Dieses Buch beschreibt den gesamten Lebenszyklus von Software als Medizinprodukt. Es deckt den kompletten CPMS-Lehrplan (Foundation Level) ab und ergänzt ihn durch weitere Informationen. Behandelt werden im Einzelnen:

- Rechtliche Grundlagen
- Qualitäts- und Dokumentenmanagement (ISO 13485)
- Risikomanagement und -analyse (ISO 14971)
- Best Practices des Software Engineering (IEC 62304)
- Gebrauchstauglichkeit (Benutzungsschnittstellen und IEC 62366)
- Medizinische Informatik
- IT-Security

Das Buch eignet sich zur individuellen Vorbereitung auf die CPMS-Zertifizierungsprüfung und als Begleitliteratur zu den entsprechenden Vorbereitungsschulungen.

Die 3. Auflage wurde komplett überarbeitet und beinhaltet den aktuellen Stand der Normen und Richtlinien für die Medizintechnik.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 28. Okt. 2020
• ISBN: 9783969100585

Buchvorschau

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.