Johner

HTW
SW Entwicklung/ Risikomanagement
IEC 62304
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf ISO 14971 Licenced for HTW Berlin - Kompakttag
Risikomanagementprozess
14971
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf Licenced for HTW Berlin - Kompakttag
Soll ich bei diesen
Wahrscheinlichkeit
hohen Inzidenzen
ins Restaurant ?
akzeptabel?
gehen?
Soll ich bei diesem

Wetter mit dem
Risiko? Nutzen?
Auto fahren?
Soll ich mein Geld in Könnte der Patient

Ist das
diesem Aktienfond
anlegen?
Medizinprodukt
einen Schlaganfall
entwickeln?
Schaden?
sicher?
Beispiel
Sichere Medizinprodukte
gewährleisten
Sicherheit = Freiheit von
unaktzeptablen Risiken
ISO 14971, Absschnitt 3.26
ISO 14971,
Ziel des Risikomanagements Einleitung
„(2) Von den Herstellern wird ein Risikomanagementsystem wie in Anhang I
Abschnitt 3 beschrieben eingerichtet, dokumentiert, angewandt und aufrechterhalten.“
Risikomanagementsystem
erforderlich
MDR, Artikel 10: Allgemeine Pflichten der Hersteller (Link MDR,

Artikel 10)
Risikomanagementprozess:
kontinuierlich, iterativ, über
den gesamten
Produktlebenszyklus
Beschreibung
Prozessschritte
Risikokontrolle: Rangfolge
beachten, akzeptables
Gesamtrestrisiko,
Information über
Restrisiken
Schnittstelle zur
Gebrauchstauglichkeit
MDR, Anhang I, 3.-5.: (Link MDR

Grundlegende Sicherheits- und Leistungsanforderungen
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf
Anhang I)
Licenced for HTW Berlin - Kompakttag
Tipp: Normen können beim
Beuth Verlag gesucht und
die Inhaltsverzeichnisse
Link zum Inhaltsverzeichnis der DIN EN ISO 14971 heruntergeladen werden
Link zum Fachartikel Risikomanagement & ISO 14971 EN ISO 14971:2019

+A11:2021
Link zum Fachartikel der aktuellen Normversion hier kurz als ISO 14971
bezeichnet
ISO 24971: Leitfaden für die Anwendung der ISO 14971, Link zum Fachartikel
Hilfestellung zur
ISO 14971: Anwendung der
Anwendung des Risikomanagements auf Medizinprodukte
ISO 14971
Falsches Verständnis der
Begriffe ist eine häufige
Fehlerquelle!
Die relevanten Begriffe

des Themas verstehen
Verkürzte Beeinträchtigung der
Tod Schmerzen Körperfunktion oder
Lebenserwartung
Körperstruktur:
Schaden Harm Knochenbruch,

verringertes
Sehvermögen
(Physische) Verletzung (Physical) injury or

oder Schädigung der damage to the health of
Gesundheit von people, or damage to
Menschen oder property or the
Schädigung von Gütern environment.
oder der Umwelt.
ISO 14971, Abschnitt 3.3
Gefährdung Hazard
Potenzielle Potential source of harm
Schadensquelle
Mechanische Biologische
Energie Materialien
Thermische Chemische
Energie Materialien
Elektrische
Daten
Energie
Elektro-
Diagnostische
magnetische Gefährdungen Informationen
Energie
Beispiele siehe ISO 14971 Tabelle C.1
Gefährdungssituation Hazardous situation
Umstände unter denen Circumstance in which
Menschen, Güter oder die people, property, or the
Umwelt einer oder environment are exposed
mehreren Gefährdungen to one or more hazard(s).
ausgesetzt sind.
ISO 14971, Abschnitt 3.3 ISO 14971, Abschnitt 3.3
Tod des Patienten
Gefährdung
? Blutverlust
Geplatzter Blutschlauch
Überdruck im Blutschlauch
Gefährdungs Überhöhte Pumpendrehzahl
- situation? Ausfall Pumpenüberwachung
Softwarefehler
Geschweifte Klammer fehlt
Übermüdeter Entwickler
Beispiel: Dialyse
Achtung: Begriffe nicht verwechseln!
Auslösende
Weitere Gefährdung Gefährdungs Schaden
Ursache
Ursache(n) (Hazard) -situation (Harm)
(Root Cause)
Geplatzter Patient ist dem
Blutschlauch Auslaufendes Blut
platzenden
Die Gefährdung ist die letzte Ursache Blutschlauch
ausgesetzt
in der Ursachenkette
Beispiele siehe ISO
vor der Gefährdungssituation 14971 Tabelle C.3
Ursachenkette und Link zum
Fachartikel
Gefährdung Schaden?
?
Schweregrad
Auftretenswahr-
scheinlichkeit?
Gefährdungs
- situation?
Risiko?
Beispiel: Kronleuchter
Auslösende
Weitere Gefährdung Gefährdungs- Schaden
Ursache
Ursache(n) (Hazard) situation (Harm)
(Root Cause)
Alterung Herabfallender Person steht
unter dem Zertrümmerter
Befestigung Kronleuchter Schädel
Kronleuchter
Ursachenkette
Schweregrad Severity
Maß der möglichen Measure of the possible
Auswirkung einer consequences of a hazard
Gefährdung
ISO 14971, Abschnitt 3.27 ISO 14971, Abschnitt 3.27
Aufregung um Parkplatz -
fällt die Treppe hinunter,
Herzstillstand - kämpft um sein
gebrochener Fuß, keine Heilung
Leben und wird am Ende gesund
möglich, braucht eine Prothese
entlassen
Auftretenswahrscheinlichkeit des Schadens
P1 P2 P3 P4
Weitere Gefährdungs-
Ursache Gefährdung Schaden
Ereignisse situation
Schweregrad
Risiko = f (Auftretenswahrscheinlichkeit, Schweregrad)
Erläuterung des
Risiko Konzepts siehe
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf ISO 14971 Anhang C.1
P1 P2 P3 P4
Weitere Gefährdungs-
Ursache Gefährdung Schaden
Ereignisse situation
Software Bug System zeigt Arzt verschreibt Patient nimmt Anaphylaktischer

falsches falsches falsches Schock
Medikament an Medikament Medikament ein

Risiko Risk
Kombination der Combination of the
Wahrscheinlichkeit des probability of occurance of
Auftretens eines harm and the severity of
Schadens und des that harm
Schweregrades dieses
Schadens
• Erstellung einer Liste relevanter Schäden
Schritt 1 • Bestimmung des größten relevanten Schadens
• Bestimmung der Anzahl der Schweregradklassen

Schritt 2 • Bestimmung der Klassennamen (z.B.: Gering, Ernst,…
• Bestimmung der Klassifizierungskriterien

• Bestimmung der Klassen
Schritt 3 • Zuweisung produktspezifischer Beispiele pro Klasse
Auftretens-
wahrscheinlichkeit
für den Schaden
Hohes
Risiko
Niedriges
Risiko
Schweregrad des
Schadens
Risikomatrix
Wahrscheinlichkeit
des Schadens
häufig
gelegentlich
unwahrscheinlich
unvorstellbar
gering ernst kritisch katastrophal

Schweregrad des Schadens
5. Risikoanalyse
5.2 Zweckbestimmung und vernünftigerweise vorhersehbare Fehlanwendung
5.3 Identifizierung sicherheitsbezogener Merkmale
5.4 Identifizierung von Gefährdungen und Gefährdungssituationen
5.5 Risikoeinschätzung Risikobeurteilung
6. Risikobewertung
4.4 Risikomanagementplan
Entscheidung über Vertretbarkeit der Risiken
7. Risikobeherrschung
7.1 Analyse der Optionen zur Risikobeherrschung
Risikomanagement
7.2 Implementierung von Maßnahmen zur Risikobeherrschung
7.3 Bewertung des Restrisikos
7.4 Nutzen-Risiko-Analyse
7.5 Durch Maßnahmen der Risikobeherrschung entstehende Risiken
8. Bewertung des Gesamt-Restrisikos
9. Überprüfung des Risikomanagements
10. Aktivitäten während der Herstellung und der Herstellung nachgelagerter Phasen
Prozessablauf ISO 14971,

Abschnitt 4.1
Risikoanalyse
ISO 14971,
Kapitel 5
Vorläufige Gefährdungsanalyse (Preliminary Hazard Analysis, PHA)
Fehlermöglichkeits- und -einflussanalyse (Failure Mode and Effect Analysis, FMEA)
Fehlerbaumanalyse (Fault Tree Analysis, FTA) Nähere

Informationen
Hazard and Operability (HAZOP) siehe Link zum
Fachartikel
Beispiele für Techniken zur Risikoanalyse

Geeignet für: frühe Entwicklungsstadien, Gefährdungen identifizieren
Methoden: Mögliche z. B.
Gefährdungen ISO 14971 Tabelle C.1,
- Brainstorming ? ISO 24971 Anhang A
Für Software: ISO 25010,
- Verwendung von Checklisten IEC 80002-1
Mögliche Fehler?
- In- und Output-Analyse →
Gefährdungen
Vorläufige Gefährdungsanalyse (Preliminary Hazard Analysis,
PHA)
Innere Kette Äußere Kette
Strahlung
Druck
Elektrische
Spannung
Information
Systemgrenze, innere Kette, äußere Kette

Risikobewertung
ISO 14971,
Kapitel 6
Auftretens- Typische Fehler Alle Risiken so weit wie
wahrscheinlichkeit siehe Fachartikel möglich reduzieren
des Schadens häufig Nicht
vertretbares
gelegentlich Risiko
(Möglicherweise)
unwahrscheinlich vertretbares
Risiko
unvorstellbar
gering ernst kritisch katastrophal

Schweregrad des Schadens
Risikobewertung Tipps siehe

Fachartikel
Risikobeherrschung
ISO 14971,
Kapitel 7
1. Inhärente Sicherheit In dieser Reihenfolge!
2. Schutzmaßnahmen
Neues
Risiko?
3. Sicherheitsinformationen
Risikobeherrschungsmaßnahmen
Risikomanager:innen
• Expertise für Methoden und Verfahren (Risikoanalyse, Dokumentation, …)
• Expertise für entsprechende Vorschriften und Normen Kompetenzen
Entwickler:in / System-Architekt:in
• Expertise für die innere Ursachenkette
ISO 14971, Abschnitt
Ärzt:innen
4.3
• Expertise für Wahrscheinlichkeiten und Schweregrade in Gefährdungssituationen
Kontextexperten:innen
• Expertise für die äußere Ursachenkette
Beteiligte Rollen
Johner Institut
SW Entwicklungsprozess
IEC 62304
Directives/ predefines supplements National
Legislation Regulations, National Law
Directives
MDR/ IVDR
requires requires requires requires
SW QM Risk Usability
General Safety and
Life Cycle System Management
Performance Requirements
certifies certifies certifies certifies
requires requires
requires
Harmonized IEC 62304 ISO 13485 ISO 14971 IEC 62366
Standards requires
Prozesse der IEC 62304
Software-Entwicklung (Kapitel 5)
Softwarewartung (Kapitel 6)
Software Risikomanagement(Kapitel 7)
Software Konfigurationsmanagement (Kapitel 8)
Software Problemlösungsprozess(Kapitel 9)
Dokumentation Software Entwicklungsplan
Software Anforderungen
Software Entwicklung
Software Architektur
Detailiertes Design
Unit Verifizierung
Integration Tests
System Tests
Software Freigabe
Agile Model
24 hours
Iterative refinement of
detailed design
SW-Component
Req. Specification 30 days sprint
High-level architecture Implementation
SW-Component
Tests
Software
Software Software Integration Tests
Req. Specification Architecture
Software
System Tests Potentially
Product Backlog Sprint Backlog shippable Software
https://www.johner-institut.de/blog/iec-62304-medizinische-software/agile-softwareentwicklung-fuer-medizinprodukte/
Fazit: Prozessmodelle
▪ Die IEC 62304 definiert kein Prozessmodell

▪ Der Hersteller ist frei bei der Wahl des Modells
▪ Allerdings: die Abhängigkeiten zwischen den geforderten Aktivitäten müssen
beachtet werden (Bsp. Risikoanalyse ist nicht abgeschlossen, bevor alle
Anforderungen benannt und die SW-Architektur definiert ist)
Software Entwicklungsplan
Der SW Entwicklungsplan muss Folgendes festlegen:
▪ Den zu verwendenden SW Entwicklungsprozess ▪ Verifizierung der SW
▪ Die zu liefernden Ergebnisse und Dokumente ▪ Risikomanagement für die SW

▪ Rückverfolgbarkeit von Anforderungen und ▪ Dokumentation
Risikokontrollmaßnahmen
▪ Konfigurations- und Änderungsmanagement

Der SW Entwicklungsplan
▪ Behandlung von Problemen während der muss während der
Entwicklung der SW aktuell
Entwicklung
gehalten werden !
▪ SW Integration und deren Prüfung
Johner Institut
SW Sicherheitsklassifizierung
Software-Sicherheitsklassen
Klasse A: Keine Verletzungen oder Schädigung der Gesundheit ist möglich

Klasse B: Keine schwere Verletzung ist möglich
Sicherheitsklasse in der IEC
Klasse C: Tod oder schwere Verletzungen ist möglich 62304 definiert sich
anhand des potentiellen
Schadens
Schwere Verletzung
lebens- andauernde Schädigung Medizinische

bedrohlich Intervention
Software-Sicherheitsklassen
EN 62304:2006 + Cor.:2008 + A1:2015

Auswirkung: Sicherheitsklasse C
Software Software-
Anforderungen Systemtest
Software Software-
Architektur Integrationstest
Detaillierte Design SW-

Komponententest
Implementierung
Auswirkung: Sicherheitsklasse B
Software Software-
Software Software-
SW-
Komponententest
Implementierung
Auswirkung: Sicherheitsklasse A
Software Software-
Nicht ausreichend gemäß MDR, Anhang II

(Allgemeine Sicherheits- und
Leistungsanforderung), SW Architektur
wird unabhängig von der
Sicherheitsklasse gefordert
Implementierung
Fazit: SW-Sicherheitsklasse
▪ Für die Ableitung der Sicherheitsklasse wird die Wahrscheinlichkeit eines
Software-Fehlers als 100% angenommen
▪ Es gibt drei Sicherheitsklassen: A, B, und C, die sich nach dem Schweregrad des
Schadens ermitteln, zu denen die Software beiträgt
▪ Die Sicherheitsklasse hat Auswirkungen auf die anzuwendenden (und zu
dokumentierenden) Prozessschritte
▪ Die Dokumentation gemäß SW Klasse A ist unter der MDR nicht ausreichend
Johner Institut
SW-Anforderungen und SW-Architektur

Software-Anforderungen
System-
anforderunge
n
Inhalte von SW-Anforderungen:

▪ Funktionalität
▪ Ein- und Ausgabedaten
▪ Schnittstellen zu anderen Systemen
▪ Alarmmeldungen, Warnungen, Benutzerhinweise
▪ Sicherheitsanforderungen !
▪ Gebrauchstauglichkeit
▪ Installations- und Installationsprüfung
▪ Betrieb- und Wartung
▪ Benutzerdokumentation
▪ Regulatorische Anforderungen
Verifikationskriterien von SW-Anforderungen:

▪ Vollständig
▪ Widerspruchsfrei
▪ Verständlich
▪ Überprüfbar
▪ Traceability
Software-Architektur
Fünf Forderungen der 62304 an eine Software-Architektur
1. System in Komponenten aufteilen
2. Schnittstellen beschreiben
3. Spezifikation der SOUPS
4. Abgrenzung zur Risikobeherrschung
5. Verifizierung
Kunden, Geschäftsführung Entwickler, Regulatory- Benannte Stellen
Anwender , Projektleiter Programmierer Affairs-Manager Behörden
• Funktionalität • Im Zeit- und • Klarheit, was • Konformität • Konformität

• Usability Kostenrahmen zu tun ist • Verständliche
• Keine Bugs • Wartbarkeit Dokumentation
Ziele einer Architektur

Komponente
Schnittstelle
Komponente
Komponenten im Bau
Namespace: Package, Assembly
Klasse
Webservice, Micro-Service
Prozess, exe, dll
...
Komponenten bei Software

1
Eigene
Rahmen-
Vorgabe-
bedingungen
dokumente
Architektur Architektu Architektur Aufzeich-

SRS
entwerfen r prüfen nungen
Architektur im Lebenszyklus
1
Organisatorische Rahmenbedingungen
• Zeit, Budget
Rahmenbedingungen
• Personen (Anzahl, Kompetenz)
• Möglichkeit zum Outsourcing
Technische Rahmenbedingungen
• Programmiersprachen Rahmenbedingungen
• Werkzeuge sollten dokumentiert sein
• SRS: Bestehende Systeme, Laufzeitumgebung
Gesetzliche Rahmenbedingungen
• Medizinprodukterecht: MDR, IVDR, IEC 62304, FDA, ...

• Datenschutzrecht: DSGVO, HIPAA, ...
• Schutzrecht: Lizenzrecht, Patente, ....
Software-System
Integrierte Sammlung von SOFTWARE KOMPONENTEN
die so organisiert sind, dass eine spezifische Funktion oder
ein Satz von Funktionen ausgeführt werden kann.
Software-Komponente
Jedes identifizierbare Teil eines Computerprogramms
Software-Einheit
Komponenten, die nicht in weitere Komponenten zerteilt sind
Verifikation der SW-Architektur
▪ System- und SW-Anforderungen wurden umgesetzt

▪ Anforderungen, die sich auf die Risikobescherrschung beziehen, wurden
implementiert
▪ Schnittstellen wurden berücksichtigt
▪ SOUP Komponenten funktionieren ordnungsgemäß
GUI UI library
«SOUP»
Math Library
«SOUP» BusinessLogic
.NET
«SOUP»
Utilities
«SOUP» Persistence
«SOUP»
Database
SOUPs
«SOUP»
Name Version Manufacturer Website Requirements Prerequisites
Statistics.dll 2.13.2 Statistica Inc. www.statistic.biz/releasenotes See chapter 5.1.2 32kb,…
SOUPs
Detailliertes Design
Fazit: Detailliertes Design

▪ Software wird bis auf die SW-Einheiten zerlegt
▪ Schnittstellen zwischen den SW-Einheiten werden spezifiziert
▪ Verhalten der SW-Einheiten wird beschrieben
Implementierung
▪ SW Einheiten implementieren
▪ Akzeptanzkriterien festlegen
▪ Codier-Richtlinien festlegen
Software-Testing
Taxonomie der Testmethoden
Testmethoden
Wer führt den Wird Code

Lebenszyklus Testziel Ist Code bekannt? …
Test durch? ausgeführt?
Komponenten- Nein: Nein:

Lasttest Entwickler-Tests
test Blackbox-Test Statische Tests
Ja:
Ja:
Integrationstest Stresstest Anwender-Tests Dynamische
Whitebox-Test
Tests
Systemtest Usability-Test Feld-Tests

74
Software Komponententest
Komponententests
Mögliche Arten von Komponententests:
▪ Codereview
▪ Unit Test
▪ Statische Analyse
Zusammenspiel der Komponenten
Bild Ariane/Pathfinder?
Software Integrations- / Systemtests
Stakeholder System-
Anforderungen Validierung
Produkt System Systemtest
Management Spezifikation (Verifizierung)
SystemArchitektur System-
Integrationstest
Komponenten Komponententest
Anforderungen
Komponenten Komponenten-
Software Software-
Hardware Anforderungen Systemtest
analog
Software Software-
SW-Komponenten SW-
Anforderungen Komponententest
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf Implementierung Licenced for HTW Berlin - Kompakttag
Integrationstests
IEC 62304 verlangt:

▪ Integrations-Strategie für Ihre Software-Tests bestimmen und dann
die Integrationstests entsprechend durchführen
▪ Integrationstests müssen Qualitätseigenschaften, wie Funktionalität,
Effizienz/Zeitverhalten, prüfen
▪ Integrationstests müssen für die Regressionsprüfung reproduzierbar sein
▪ Fehler, die bei Integrationstests entdeckt werden, dürfen nicht einfach
gefixed werden, sondern müssen den Problemlösungsprozess durchlaufen.
Code-Version
Tester Testcode
Reproduzier
Test barkeit Test
Ergebnisse Spezifikation
Reproduzierbarkeit
Test Infra-
struktur
Testdaten
Stakeholder System-
Anforderungen Validierung
Produkt System Systemtest
Management Spezifikation (Verifizierung)
SystemArchitektur System-
Integrationstest
Komponenten Komponententest
Anforderungen
Komponenten Komponenten-
Software Software-
Hardware Anforderungen Systemtest
analog
Software Software-
SW-Komponenten SW-
Anforderungen Komponententest
Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf Implementierung Licenced for HTW Berlin - Kompakttag
Systemtests
SW-Systemtest ist eine Prüfung des gesamten Software-Systems, ob die daran

gestellten Software-Anforderungen erfüllt sind.
Die Blackbox „Software-System“ wird über deren Schnittstellen (Benutzer-System-Schnittstellen
und System-System-Schnittstellen) getestet, entweder manuell oder automatisiert.
Anforderungen der IEC 62304:

▪ Vollständigkeit
▪ Pass-Fail-Kriterien
▪ Dokumentation und Reproduzierbarkeit
▪ Problemlösungsprozess
▪ Wiederholung bei Änderungen
https://www.johner-institut.de/blog/iec-62304- ▪ Geeignete Teststrategie
medizinische-software/software-systemtest/
▪ (Automatisieren Sie so weit wie möglich) Licenced for HTW Berlin - Kompakttag
Software Freigabe
IEC 62304 ✓ Aktivitäten erledigt: Verifikation
✓ Anomalien: Dokumentiert
& überprüft
✓ Version
✓ Reproduzierbarkeit
✓ Archivierung
Dokumentation Software Entwicklungsplan
Software-Entwicklung
Software-Architektur
Detailliertes Design
Softwareeinheiten Verifikation
Integrationstests
Systemtests

Software Freigabe Licenced for HTW Berlin - Kompakttag
Software-Wartung
Software-Risikomanagement
Software-Problemlösung
Software-Konfigurationsmanagement
Software-Wartung
SW-Konfigurationsmanagement
Indentifizierung
▪ SOUP, SW-Werkzeuge, Build-Scripte, Dokumente
▪ Elemente und Versionen kennzeichnen (Pfadangabe, Name des
Elements und Versionsangabe)
▪ Angaben für SOUP: Name, Hersteller, eindeutige Kennzeichnung
▪ Versionskontroll-System: Werkzeuge für die Verwaltung von
Konfigurationen (Entwicklungszweige, Baselines, Labels/Tags)
Software-Wartung
11. Wartungsprozess
Software-Wartung
9. Problemlösungs-Prozess
Johner Institut
Danke für die Aufmerksamkeit

und nun viel Erfolg bei den Übungen!
johner-institut.de

Johner

Hochgeladen von

Dokumentinformationen

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

Johner

Hochgeladen von

Copyright:

Verfügbare Formate

HTW

Soll ich bei diesem

Soll ich mein Geld in Könnte der Patient

MDR, Artikel 10: Allgemeine Pflichten der Hersteller (Link MDR,

MDR, Anhang I, 3.-5.: (Link MDR

Link zum Fachartikel Risikomanagement & ISO 14971 EN ISO 14971:2019

Die relevanten Begriffe

Schaden Harm Knochenbruch,

(Physische) Verletzung (Physical) injury or

ISO 14971, Abschnitt 3.4

Software Bug System zeigt Arzt verschreibt Patient nimmt Anaphylaktischer

Auftretenswahrscheinlichkeit des Schadens

• Bestimmung der Anzahl der Schweregradklassen

• Bestimmung der Klassifizierungskriterien

gering ernst kritisch katastrophal

Entscheidung über Vertretbarkeit der Risiken

8. Bewertung des Gesamt-Restrisikos

9. Überprüfung des Risikomanagements

Prozessablauf ISO 14971,

Fehlerbaumanalyse (Fault Tree Analysis, FTA) Nähere

Beispiele für Techniken zur Risikoanalyse

Systemgrenze, innere Kette, äußere Kette

gering ernst kritisch katastrophal

Risikobewertung Tipps siehe

requires requires requires requires

certifies certifies certifies certifies

Software Konfigurationsmanagement (Kapitel 8)

▪ Die IEC 62304 definiert kein Prozessmodell

▪ Den zu verwendenden SW Entwicklungsprozess ▪ Verifizierung der SW

▪ Die zu liefernden Ergebnisse und Dokumente ▪ Risikomanagement für die SW

▪ Konfigurations- und Änderungsmanagement

Klasse A: Keine Verletzungen oder Schädigung der Gesundheit ist möglich

lebens- andauernde Schädigung Medizinische

EN 62304:2006 + Cor.:2008 + A1:2015

Detaillierte Design SW-

Nicht ausreichend gemäß MDR, Anhang II

SW-Anforderungen und SW-Architektur

Inhalte von SW-Anforderungen:

Verifikationskriterien von SW-Anforderungen:

1. System in Komponenten aufteilen

3. Spezifikation der SOUPS

4. Abgrenzung zur Risikobeherrschung

• Funktionalität • Im Zeit- und • Klarheit, was • Konformität • Konformität

Ziele einer Architektur

Komponenten bei Software

Architektur Architektu Architektur Aufzeich-

• Medizinprodukterecht: MDR, IVDR, IEC 62304, FDA, ...

▪ System- und SW-Anforderungen wurden umgesetzt

▪ Schnittstellen wurden berücksichtigt

▪ SOUP Komponenten funktionieren ordnungsgemäß

Statistics.dll 2.13.2 Statistica Inc. www.statistic.biz/releasenotes See chapter 5.1.2 32kb,…

Fazit: Detailliertes Design

▪ Schnittstellen zwischen den SW-Einheiten werden spezifiziert

▪ Verhalten der SW-Einheiten wird beschrieben

Wer führt den Wird Code

Komponenten- Nein: Nein:

Systemtest Usability-Test Feld-Tests

Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf

Mögliche Arten von Komponententests:

IEC 62304 verlangt:

SW-Systemtest ist eine Prüfung des gesamten Software-Systems, ob die daran

Anforderungen der IEC 62304:

Dies ist ein lizensiertes Dokument, keine Weitergabe oder Verkauf

Danke für die Aufmerksamkeit