Medizingeräte-Software - Software-Lebenszyklus-Prozesse

Transkript

1 Schweizer Norm Norme Suisse Norma Svizzera Fachbereich Elektrotechnik EN EINGETRAGENE NORM DER SCHWEIZERISCHEN NORMENVEREINIGUNG SNV NORME ENREGISTREE DE L ASSOCIATION SUISSE DE NORMALISATION Medizingeräte-Software - Software-Lebenszyklus-Prozesse Logiciels de dispositifs médicaux - Processus du cycle de vie du logiciel Medical device software - Software life-cycle processes Diese Norm ist die deutsche Fassung EN 62304:2006 [IEC 62304:2006] Die Europäische Norm EN 62304:2006 hat den Status einer Schweizer Norm. Sie gilt in der Schweiz als anerkannte Regel der Technik. Die EN 62304:2006 gilt seit: Leerseite nach SN-Titelblatt Für die vorliegende Norm ist das Schweizerische Elektrotechnische Komitee (CES), Technisches Komitee 62 - Elektrische Apparate in medizinischer Anwendung - zuständig. Referenznummer / No. de référence SNEN62304:2006(D) Herausgeber / Vertrieb Editeur / Distributeur Electrosuisse Luppmenstrasse 1, CH-8320 Fehraltorf Electrosuisse

2

3 EUROPÄISCHE NORM EUROPEAN STANDARD NORME EUROPÉENNE EN Juli 2006 ICS Deutsche Fassung Medizingeräte-Software Software-Lebenszyklus-Prozesse (IEC 62304:2006) Medical device software Software life-cycle processes (IEC 62304:2006) Logiciels de dispositifs médicaux Processus du cycle de vie du logiciel (CEI 62304:2006) Diese Europäische Norm wurde von CENELEC am angenommen. Die CENELEC-Mitglieder sind gehalten, die CEN/CENELEC-Geschäftsordnung zu erfüllen, in der die Bedingungen festgelegt sind, unter denen dieser Europäischen Norm ohne jede Änderung der Status einer nationalen Norm zu geben ist. Auf dem letzten Stand befindliche Listen dieser nationalen Normen mit ihren bibliographischen Angaben sind beim Zentralsekretariat oder bei jedem CENELEC-Mitglied auf Anfrage erhältlich. Diese Europäische Norm besteht in drei offiziellen Fassungen (Deutsch, Englisch, Französisch). Eine Fassung in einer anderen Sprache, die von einem CENELEC-Mitglied in eigener Verantwortung durch Übersetzung in seine Landessprache gemacht und dem Zentralsekretariat mitgeteilt worden ist, hat den gleichen Status wie die offiziellen Fassungen. CENELEC-Mitglieder sind die nationalen elektrotechnischen Komitees von Belgien, Dänemark, Deutschland, Estland, Finnland, Frankreich, Griechenland, Irland, Island, Italien, Lettland, Litauen, Luxemburg, Malta, den Niederlanden, Norwegen, Österreich, Polen, Portugal, Rumänien, Schweden, der Schweiz, der Slowakei, Slowenien, Spanien, der Tschechischen Republik, Ungarn, dem Vereinigten Königreich und Zypern. CENELEC Europäisches Komitee für Elektrotechnische Normung European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Zentralsekretariat: rue de Stassart 35, B-1050 Brüssel 2006 CENELEC Alle Rechte der Verwertung, gleich in welcher Form und in welchem Verfahren, sind weltweit den Mitgliedern von CENELEC vorbehalten. Ref. Nr. EN 62304:2006 D

4 Vorwort Der Text des Schriftstücks 62A/523/FDIS, zukünftige 1. Ausgabe von IEC 62304, wurde von einer gemeinsamen Arbeitsgruppe zwischen SC 62A Überarbeitung und Anpassung der allgemeinen Bestimmungen des IEC Technischen Komitees TC 62 Allgemeine Bestimmungen für elektrische Einrichtungen in medizinischer Anwendung und dem ISO Technischen Komitee ISO TC 210 Qualitätsmanagement und allgemeine Aspekte für Medizinprodukte ausgearbeitet. Dieser Text wurde der IEC-CENELEC Parallelen Abstimmung unterworfen und von CENELEC am als EN angenommen. Nachstehende Daten wurden festgelegt: spätestes Datum, zu dem die EN auf nationaler Ebene durch Veröffentlichung einer identischen nationalen Norm oder durch Anerkennung übernommen werden muss (dop): spätestes Datum, zu dem nationale Normen, die der EN entgegenstehen, zurückgezogen werden müssen (dow): In dieser Norm werden die folgenden Schriftarten verwendet: Festlegungen und Definitionen: Normalschrift; Informationen außerhalb von Tabellen, wie Anmerkungen und Referenzen, in Kleinschrift. Normativer Text von Tabellen: Kleinschrift; IN DIESER NORM BENUTZTE BEGRIFFE, DIE IN ABSCHNITT 3 DEFINIERT SIND UND IM VERZEICHNIS DER DEFINIERTEN BEGRIFFE ANGEGEBEN SIND: KAPITÄLCHEN. Ein Stern (*) am ersten Buchstaben einer Überschrift oder am Anfang eines Abschnittes bedeutet, dass erklärende Hinweise in Anhang B gegeben werden. Tabelle C.5 wurde von ISO/IEC JTC 1/SC 7, Software und System-Engineering, erstellt. Der Anhang ZA wurde von CENELEC hinzugefügt. Anerkennungsnotiz Der Text der Internationalen Norm IEC 62304:2006 wurde von CENELEC ohne irgendeine Abänderung als Europäische Norm angenommen. In der offiziellen Fassung sind unter Literaturhinweise zu den aufgelisteten Normen die nachstehenden Anmerkungen einzutragen: IEC A1 IEC IEC ISO 9000 ISO 9001 ISO IEC ANMERKUNG Harmonisiert als EN : A1:1999 (nicht modifiziert). ANMERKUNG Harmonisiert als EN :2001 (nicht modifiziert). ANMERKUNG Harmonisiert als EN :2001 (nicht modifiziert). ANMERKUNG Harmonisiert als EN ISO 9000:2005 (nicht modifiziert). ANMERKUNG Harmonisiert als EN ISO 9001:2000 (nicht modifiziert). ANMERKUNG Harmonisiert als EN ISO 13485:2003 (nicht modifiziert). ANMERKUNG Harmonisiert als EN :2004 (nicht modifiziert). 2

5 Inhalt Seite Vorwort... 2 Einführung Geltungsbereich *Zweck *Anwendungsbereich Beziehung zu anderen Normen Einhaltung *Normative Verweisungen Begriffe *Allgemeine Anforderungen *Qualitätsmanagement-System *RISIKOMANAGEMENT *Software-Sicherheitsklassifizierung Software-Entwicklungs-PROZESS *Planung der Software-Entwicklung *Analyse der Software-Anforderungen *Design der Software-ARCHITEKTUR *Detailliertes Software-Design *Implementierung und VERIFIZIERUNG der SOFTWARE-EINHEITEN *Software-Integration und -Integrationsprüfung *Prüfung des SOFTWARE-SYSTEMS *Software-Freigabe Software-Wartungs-PROZESS *Festlegung eines Plans für die Software-Wartung *Analyse von Problemen und Änderungen *Implementierung von Änderungen *Software-RISIKOMANAGEMENT-PROZESS *Analyse von Software, die zu Gefährdungssituationen beiträgt RISIKOKONTROLL-Maßnahmen VERIFIZIERUNG von RISIKOKONTROLL-Maßnahmen RISIKOMANAGEMENT von Software-Änderungen *Software-Konfigurationsmanagement-PROZESS *Identifizierung der Konfiguration *Änderungskontrolle *Aufzeichnungen über den Status der Konfiguration *Problemlösungs-PROZESS für Software Erstellen von PROBLEMBERICHTEN Untersuchung des Problems

6 Seite 9.3 Unterrichtung beteiligter Stellen Anwendung des Änderungskontroll-PROZESSES Aufbewahrung von Aufzeichnungen Analyse von Problemen hinsichtlich Trends VERIFIZIERUNG der Lösung von Software-Problemen Inhalt von Prüfungsdokumentation Anhang A (informativ) Begründung für die Anforderungen dieser Norm Anhang B (informativ) Anleitung für die Bestimmungen dieser Norm Anhang C (informativ) Beziehung zu anderen Normen Anhang D (informativ) Implementierung Literaturhinweise Stichwortverzeichnis der definierten Begriffe deutsch-englisch Stichwortverzeichnis der definierten Begriffe englisch-deutsch Anhang ZA (normativ) Normative Verweisungen auf internationale Publikationen mit ihren entsprechenden europäischen Publikationen Bilder Bild 1 Überblick über Software-Entwicklungs-PROZESSE und -AKTIVITÄTEN... 6 Bild 2 Überblick über Software-Wartungs-PROZESSE und -AKTIVITÄTEN... 7 Bild B.1 Beispiel einer Aufteilung von SOFTWARE-KOMPONENTEN Bild C.1 Beziehung von wichtigen MEDIZINPRODUKTE-Normen zur IEC Bild C.2 Software als Teil des V-Modells Bild C.3 Anwendung von IEC mit IEC Tabellen Tabelle A.1 Zusammenfassung der Anforderungen nach Software-Sicherheitsklassen Tabelle B.1 Entwicklungs-(Modell-)Strategien wie in ISO/IEC definiert Tabelle C.1 Beziehung zu ISO 13485: Tabelle C.2 Beziehung zu ISO 14971: Tabelle C.3 Beziehung zur IEC Tabelle C.4 Beziehung zur IEC Tabelle C.5 Beziehung zu ISO/IEC Tabelle D.1 Checkliste für kleine Firmen ohne zertifiziertes QM-SYSTEM

7 Einführung Software ist oft ein integraler Bestandteil der MEDIZINPRODUKTE-Technik. Um die SICHERHEIT und Wirksamkeit eines MEDIZINPRODUKTS, das Software enthält, herzustellen, bedarf es der Kenntnis darüber, was die Software bewirken soll, und des Nachweises darüber, dass die Software diese Wirkung erzielt, ohne unvertretbare RISIKEN zu verursachen. Diese Norm stellt einen Rahmen von Lebenszyklus-PROZESSEN mit AKTIVITÄTEN und AUFGABEN bereit, der für den sicheren Entwurf und eine sichere Wartung von MEDIZINPRODUKTE-SOFTWARE erforderlich ist. Diese Norm stellt Anforderungen für jeden Lebenszyklus-PROZESS bereit. Jeder Lebenszyklus-PROZESS ist weiter unterteilt in einen Satz von AKTIVITÄTEN, wobei die meisten AKTIVITÄTEN weiter unterteilt sind in einen Satz von AUFGABEN. Als Voraussetzung wird angenommen, dass MEDIZINPRODUKTE-SOFTWARE innerhalb eines Qualitätsmanagement-SYSTEMS (siehe 4.1) und eines RISIKOMANAGEMENT-Systems (siehe 4.2) entwickelt und gewartet wird. Der RISIKOMANAGEMENT-PROZESS ist bereits sehr gut durch die Internationale Norm ISO abgedeckt. Diesen Vorteil nutzt die IEC 62304, indem sie einen normativen Verweis auf die ISO verwendet. Einige zusätzliche RISIKOMANAGEMENT-Anforderungen werden für Software benötigt, insbesondere wenn es darum geht, Software-Faktoren zu identifizieren, die zu GEFÄHRDUNGEN beitragen können. Diese Anforderungen werden zusammengefasst und in Abschnitt 7 als Software-RISIKOMANAGEMENT-PROZESS festgehalten. Ob Software ein Faktor ist, der zu einer GEFÄHRDUNG beiträgt, wird durch die AKTIVITÄT der GEFÄHRDUNGS- Identifikation innerhalb des RISIKOMANAGEMENT-PROZESSES ermittelt. GEFÄHRDUNGEN, die indirekt durch Software verursacht werden könnten (zum Beispiel durch Bereitstellung irreführender Informationen, die die Anwendung einer unangemessenen Behandlung verursachen könnte), müssen betrachtet werden, wenn ermittelt wird, ob die Software einen maßgeblichen Einfluss hat. Die Entscheidung, Software zur RISIKOBEHERRSCHUNG einzusetzen, wird während der AKTIVITÄT der RISIKOBEHERRSCHUNG innerhalb des RISIKOMANAGEMENT-PROZESSES getroffen. Der von dieser Norm geforderte Software-RISIKOMANAGEMENT- PROZESS muss in den Geräte-RISIKOMANAGEMENT-PROZESS nach ISO eingebunden sein. Der Software-Entwicklungs-PROZESS besteht aus einer Anzahl von AKTIVITÄTEN. Diese AKTIVITÄTEN sind in Bild 1 dargestellt und in Abschnitt 5 beschrieben. Weil viele Vorkommnisse im Feld mit dem Service oder der Wartung von medizinischen SYSTEMEN im Zusammenhang stehen, einschließlich unsachgemäßer Software- Updates und Software-Upgrades, wird der Software-Wartungs-PROZESS als ebenso wichtig erachtet wie der Software-Entwicklungs-PROZESS. Der Software-Wartungs-PROZESS ist dem Software-Entwicklungs-PROZESS sehr ähnlich. Er ist in Bild 2 dargestellt und in Abschnitt 6 beschrieben. 5

8 Bild 1 Überblick über Software-Entwicklungs-PROZESSE und -AKTIVITÄTEN 6

9 EN 62304:2006 Bild 2 Überblick über Software-Wartungs-PROZESSE und -AKTIVITÄTEN 7

10 Die Norm identifiziert zwei zusätzliche PROZESSE, die für die Entwicklung von sicherer MEDIZINPRODUKTE- SOFTWARE als wesentlich betrachtet werden. Dies sind der Software-Konfigurations-Management-PROZESS (Abschnitt 8) und der Problemlösungs-PROZESS für Software (Abschnitt 9). Diese Norm schreibt dem HERSTELLER keine Organisationsstruktur vor oder welcher Teil der Organisation welchen PROZESS, welche AKTIVITÄT oder welche AUFGABE durchführen soll. Diese Norm fordert nur, dass der PROZESS, die AKTIVITÄT oder die AUFGABE durchgeführt wird, um die Einhaltung dieser Norm nachzuweisen. Diese Norm macht keine Vorgaben für die Bezeichnung, das Format oder den expliziten Inhalt der Dokumentation, die zu erstellen ist. Diese Norm erfordert eine Dokumentation der AUFGABEN, aber die Entscheidung, wie diese Dokumentation gestaltet wird, wird dem Benutzer der Norm überlassen. Diese Norm schreibt kein spezifisches Lebenszyklus-Modell vor. Die Anwender dieser Norm sind verantwortlich für die Auswahl eines Lebenszyklus-Modells für das Software-Projekt und für das Abbilden der PROZESSE, AKTIVITÄTEN und AUFGABEN dieser Norm auf dieses Modell. Anhang A enthält die Begründung für die Abschnitte dieser Norm, Anhang B eine Anleitung für die Umsetzung dieser Norm. Für diese Norm gilt: muss bedeutet, dass die Erfüllung einer Anforderung zwingend ist für die Einhaltung dieser Norm; soll bedeutet, dass die Erfüllung einer Anforderung empfohlen wird, aber nicht zwingend ist für die Einhaltung dieser Norm; kann wird benutzt, um einen möglichen Weg zu beschreiben, wie die Erfüllung einer Anforderung zu erreichen ist; festlegen bedeutet: definieren, dokumentieren und implementieren. Wenn diese Norm den Begriff soweit angemessen im Zusammenhang mit einem erforderlichen PROZESS, einer AKTIVITÄT, einer AUFGABE oder einem Ergebnis benutzt, dann bedeutet das, dass der HERSTELLER diesen PROZESS, diese AKTIVITÄT, diese AUFGABE oder dieses Ergebnis benutzen muss, es sei denn, der HERSTELLER kann eine Rechtfertigung dafür dokumentieren, warum er dies unterlässt. 8

11 1 Geltungsbereich 1.1 *Zweck Diese Norm definiert Anforderungen an den Lebenszyklus von MEDIZINPRODUKTE-SOFTWARE. Die Zusammenstellung von PROZESSEN, AKTIVITÄTEN und AUFGABEN, die in dieser Norm beschrieben werden, legt einen allgemeinen Rahmen für Lebenszyklus-PROZESSE von MEDIZINPRODUKTE-SOFTWARE fest. 1.2 *Anwendungsbereich Diese Norm gilt für die Entwicklung und Wartung von MEDIZINPRODUKTE-SOFTWARE. Diese Norm gilt für die Entwicklung und Wartung von MEDIZINPRODUKTE-SOFTWARE, wenn die Software selbst ein MEDIZINPRODUKT ist oder wenn die Software ein eingebetteter oder integraler Bestandteil des fertigen MEDIZINPRODUKTS ist. Diese Norm deckt nicht Validierung und abschließende Freigabe des MEDIZINPRODUKTS ab, auch dann nicht, wenn das MEDIZINPRODUKT gänzlich aus Software besteht. 1.3 Beziehung zu anderen Normen Diese MEDIZINPRODUKTE-SOFTWARE-Lebenszyklus-Norm soll zusammen mit anderen geeigneten Normen benutzt werden, wenn ein MEDIZINPRODUKT entwickelt wird. Anhang C stellt die Beziehung zwischen dieser Norm und anderen relevanten Normen her. 1.4 Einhaltung Die Einhaltung dieser Norm gilt als erfüllt, wenn alle PROZESSE, AKTIVITÄTEN und AUFGABEN, die in dieser Norm im Bezug auf die Software-Sicherheitsklasse festgelegt sind, implementiert wurden. ANMERKUNG 1 Jeder Anforderung sind Software-Sicherheitsklassen zugeordnet. Die Angabe der Software- Sicherheitsklassen steht im normativen Abschnitt hinter der entsprechenden Anforderung. Die Einhaltung wird durch das Besichtigen der gesamten Dokumentation festgestellt, die von dieser Norm gefordert wird, einschließlich der RISIKOMANAGEMENT-AKTE, und durch die Beurteilung der PROZESSE, AKTIVITÄTEN und AUFGABEN, die für die entsprechende Software-Sicherheitsklasse gefordert werden. Siehe Anhang D. ANMERKUNG 2 Diese Beurteilung kann durch ein internes oder externes Audit durchgeführt werden. ANMERKUNG 3 Bei der Ausführung der festgelegten PROZESSE, AKTIVITÄTEN und AUFGABEN bestehen Freiheitsgrade in der Auswahl der Methoden zur Implementierung dieser PROZESSE und der Ausführung dieser AKTIVITÄTEN und AUFGABEN. ANMERKUNG 4 Für diese Beurteilung ist an den Stellen, an denen bestimmte Anforderungen den Zusatz soweit angemessen enthalten und nicht erfüllt werden, eine Begründung zu dokumentieren. ANMERKUNG 5 An den Stellen, an denen die ISO/IEC den Begriff Übereinstimmung verwendet, wird in dieser Norm der Begriff Einhaltung verwendet. 2 *Normative Verweisungen Die folgenden zitierten Dokumente sind für die Anwendung dieses Dokuments erforderlich. Bei datierten Verweisungen gilt nur die in Bezug genommene Ausgabe. Bei undatierten Verweisungen gilt die letzte Ausgabe des in Bezug genommenen Dokuments (einschließlich aller Änderungen). ISO 14971, Medical devices Application of risk management to medical devices 9

12 3 Begriffe Für die Anwendung dieses Dokuments gelten die folgenden Begriffe. 3.1 AKTIVITÄT Satz von einer oder mehreren aufeinander bezogenen oder sich gegenseitig beeinflussenden AUFGABEN 3.2 ANOMALIE jeglicher Zustand, der abweicht von dem, was auf Grund von Anforderungsspezifikationen, Entwicklungsdokumenten, Normen usw. oder von Wahrnehmungen oder Erfahrungen zu erwarten ist. ANOMALIEN können sich unter anderem beim Review, bei der Prüfung, der Analyse, der Kompilierung oder bei der Benutzung von SOFTWARE-PRODUKTEN oder zugehöriger Dokumentation finden. [IEEE 1044:1993, Definition 3.1], [14] N1) 3.3 ARCHITEKTUR Organisationsstruktur eines SYSTEMS oder einer Komponente [IEEE :1990], [13] N1) 3.4 ÄNDERUNGSANFORDERUNG dokumentierte Spezifikation einer Änderung, die an einem SOFTWARE-PRODUKT durchgeführt werden soll 3.5 KONFIGURATIONSELEMENT Einheit, die an einem gegebenen Referenzpunkt eindeutig identifiziert werden kann ANMERKUNG Basierend auf ISO/IEC 12207:1995, Definition 3.6 [9] N1). 3.6 ZU LIEFERNDES ERGEBNIS gefordertes Resultat oder Ergebnis (einschließlich Dokumentation) einer AKTIVITÄT oder AUFGABE 3.7 EVALUATION systematische Bewertung oder Beurteilung, inwieweit eine Einheit ihre festgelegten Merkmale erfüllt. [ISO/IEC 12207:1995, Definition 3.9], [9] N1) 3.8 SCHADEN physische Verletzung oder Schädigung der Gesundheit von Menschen oder Schädigung von Gütern oder der Umwelt [ISO/IEC Guide 51:1999, Definition 3.3], [12] N1) 3.9 GEFÄHRDUNG potentielle Quelle eines SCHADENS [ISO/IEC Guide 51:1999, Definition 3.5], [12] N1) N1) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. 10

13 3.10 HERSTELLER natürliche oder juristische Person, die für die Auslegung, Herstellung, Verpackung oder Kennzeichnung eines MEDIZINPRODUKTS, für den Zusammenbau eines SYSTEMS oder für die Anpassung eines MEDIZINPRODUKTS vor dem Inverkehrbringen oder der Inbetriebnahme verantwortlich ist, unabhängig davon, ob diese Tätigkeiten von dieser Person selbst oder stellvertretend für diese von einer dritten Person ausgeführt werden [ISO 14971:2000, Definition 2.6] 3.11 MEDIZINPRODUKT alle einzeln oder miteinander verbunden verwendeten Instrumente, Apparate, Vorrichtungen, Stoffe oder anderen Gegenstände einschließlich der für ein einwandfreies Funktionieren des MEDIZINPRODUKTS eingesetzten Software, die vom HERSTELLER zur Anwendung für Menschen für folgende Zwecke bestimmt sind: Erkennung, Verhütung, Erfassen, Behandlung oder Linderung von Krankheiten, Erkennung, Erfassung, Behandlung, Linderung oder Kompensierung von Verletzungen oder Behinderungen, Untersuchung, Ersatz oder Veränderung des anatomischen Aufbaus oder eines physiologischen Vorgangs, Lebenserhaltung oder Lebensunterstützung, Empfängnisregelung, Desinfektion von MEDIZINPRODUKTEN, Bereitstellung von Informationen für medizinische Zwecke mittels In-vitro-Untersuchung von Probestücken des menschlichen Körpers, und deren bestimmungsgemäße Hauptwirkung im oder am menschlichen Körper weder durch pharmakologische noch durch immunologische oder metabolische Mittel erreicht wird, deren Wirkungsweise aber durch solche Mittel unterstützt werden kann ANMERKUNG 1 Diese Definition wurde durch die Global Harmonization Task Force (GHTF) entwickelt. Siehe Literaturhinweis [15] in ISO 13485:2003. [ISO 13485:2003, Definition 3.7], [7] N2) ANMERKUNG 2 In den Definitionen, wie sie in den nationalen Regularien des jeweiligen Landes verwendet werden, können Unterschiede auftreten MEDIZINPRODUKTE-SOFTWARE ein SOFTWARE-SYSTEM, das entwickelt wurde, um in das in der Entwicklung befindliche MEDIZINPRODUKT integriert zu werden, oder das für die Benutzung als selbständiges MEDIZINPRODUKT vorgesehen ist 3.13 PROBLEMBERICHT Aufzeichnung über ein tatsächliches oder mögliches Verhalten eines SOFTWARE-PRODUKTS, von dem ein Anwender oder eine andere beteiligte Person glaubt, dass es unsicher, ungeeignet für den bestimmungsgemäßen Gebrauch oder widersprüchlich zur Spezifikation sei ANMERKUNG 1 Diese Norm fordert nicht, dass jeder PROBLEMBERICHT zu einer Änderung des SOFTWARE-PRODUKTS führt. Ein HERSTELLER kann einen PROBLEMBERICHT als Missverständnis, als Fehler oder als unbedeutendes Ereignis ablehnen. N2) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. 11

14 ANMERKUNG 2 Ein PROBLEMBERICHT kann sich auf ein freigegebenes SOFTWARE-PRODUKT oder auf ein noch in der Entwicklung befindliches SOFTWARE-PRODUKT beziehen. ANMERKUNG 3 Diese Norm fordert vom HERSTELLER, dass er für einen PROBLEMBERICHT, der sich auf ein freigegebenes Produkt bezieht, besondere Entscheidungen trifft (siehe Abschnitt 6) um zu gewährleisten, dass regulatorische Maßnahmen identifiziert und implementiert werden PROZESS Satz von in Wechselbeziehung oder Wechselwirkung stehenden AKTIVITÄTEN, der Eingaben in Ergebnisse umwandelt [ISO 9000:2000, Definition 3.4.1] ANMERKUNG Der Begriff AKTIVITÄTEN beinhaltet den Gebrauch von Ressourcen REGRESSIONSPRÜFUNG Prüfung, die erforderlich ist um festzustellen, dass eine Änderung einer SYSTEM-Komponente deren Funktionalität, Zuverlässigkeit und Leistungsfähigkeit nicht beeinträchtigt und keine zusätzlichen Defekte verursacht hat [ISO/IEC 90003:2004, Definition 3.11], [11] N3) 3.16 RISIKO Kombination der Wahrscheinlichkeit des Auftretens eines SCHADENS und des Schweregrades dieses SCHADENS [ISO/IEC Guide 51:1999, Definition 3.2], [12] N3) 3.17 RISIKOANALYSE systematische Auswertung verfügbarer Informationen, um GEFÄHRDUNGEN zu identifizieren und RISIKEN abzuschätzen [ISO/IEC Guide 51:1999, Definition 3.10], [12] N3) 3.18 RISIKOBEHERRSCHUNG PROZESS, in dem Entscheidungen getroffen und RISIKEN auf festgelegte Grenzen reduziert oder in diesen gehalten werden [ISO 14971:2000, Definition 2.16, modifiziert] N4) 3.19 RISIKOMANAGEMENT systematische Anwendung von Managementgrundsätzen, Verfahren und Praktiken auf die Analyse, Bewertung und Kontrolle von RISIKEN [ISO 14971:2000, Definition 2.18] N3) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. N4) Nationale Fußnote: Der Begriff wurde zur besseren Verständlichkeit von Risikokontrolle auf Risikobeherrschung geändert. In der neuen Ausgabe von DIN EN ISO 14971:2006 wird dieser Begriff ebenfalls verwendet. 12

15 3.20 RISIKOMANAGEMENT-AKTE Zusammenstellung von Aufzeichnungen und sonstigen Dokumenten, die durch den RISIKOMANAGEMENT- PROZESS erzeugt werden und nicht notwendigerweise an einer Stelle sein müssen [ISO 14971:2000, Definition 2.19] 3.21 SICHERHEIT Freiheit von unvertretbaren RISIKEN [ISO/IEC Guide 51:1999, Definition 3.1], [12] N5) 3.22 DATENSICHERHEIT Schutz von Informationen und Daten derart, dass nicht autorisierte Personen oder SYSTEME sie nicht lesen oder verändern können und dass autorisierten Personen und SYSTEMEN der Zugang zu ihnen nicht verweigert wird [ISO/IEC 12207:1995, Definition 3.25], [9] N5) 3.23 SCHWERE VERLETZUNG Verletzung oder Krankheit, die direkt oder indirekt a) lebensbedrohend ist, b) zu einer andauernden Beeinträchtigung einer Körperfunktion oder zu einer andauernden Schädigung des (menschlichen) Körpers führt oder c) ein medizinisches oder chirurgisches Eingreifen erfordert, um eine andauernde Beeinträchtigung einer Körperfunktion oder eine andauernde Schädigung des (menschlichen) Körpers zu verhindern ANMERKUNG Andauernde Beeinträchtigung bedeutet eine unumkehrbare Beeinträchtigung oder Schädigung des (menschlichen) Körpers oder einer Körperfunktion und schließt geringfügige Beeinträchtigungen oder Schädigungen aus LEBENSZYKLUS-MODELL DER SOFTWARE-ENTWICKLUNG konzeptionelle Struktur, welche die Lebenszeit der Software von der Anforderungsdefinition bis zur Freigabe für die Produktion umfasst und die die PROZESSE, AKTIVITÄTEN und AUFGABEN festlegt, die an der Entwicklung eines SOFTWARE-PRODUKTS beteiligt sind, die Reihenfolge und die Abhängigkeit von AKTIVITÄTEN und AUFGABEN beschreibt und die Meilensteine festlegt, bei denen die Vollständigkeit der festgelegten ZU LIEFERNDEN ERGEBNISSE verifiziert wird ANMERKUNG Basierend auf ISO/IEC 12207:1995, Definition 3.11 [9] N5) 3.25 SOFTWARE-KOMPONENTE jedes identifizierbare Teil eines Computerprogramms [ISO/IEC 90003:2004, Definition 3.14], [11] N5). ANMERKUNG Drei Begriffe kennzeichnen die Zerlegung der Software in einzelne Bestandteile. Die oberste Ebene bildet das SOFTWARE-SYSTEM. Die niedrigste Ebene, die nicht weiter zerlegt wird, ist die SOFTWARE-EINHEIT. Alle Ebenen, die Bestandteile vereinen, einschließlich der höchsten und niedersten Ebene, können als SOFTWARE-KOMPONENTEN bezeichnet werden. Ein SOFTWARE-SYSTEM ist folglich zusammengesetzt aus einer oder mehreren SOFTWARE- KOMPONENTEN, und jede SOFTWARE-KOMPONENTE ist zusammengesetzt aus einer oder mehreren SOFTWARE-EINHEITEN N5) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. 13

16 oder zerlegbaren SOFTWARE-KOMPONENTEN. Es ist der Verantwortung des HERSTELLERS überlassen, die Definition und die Unterteilung der SOFTWARE-KOMPONENTEN und SOFTWARE-EINHEITEN festzulegen SOFTWARE-PRODUKT Satz von Computerprogrammen, Prozeduren und möglicherweise zugeordneten Dokumentationen und Daten [ISO/IEC 12207:1995, Definition 3.26], [9] N6) 3.27 SOFTWARE-SYSTEM integrierte Sammlung von SOFTWARE-KOMPONENTEN, die so organisiert sind, dass eine spezifische Funktion oder ein Satz von Funktionen ausgeführt werden kann 3.28 SOFTWARE-EINHEIT SOFTWARE-KOMPONENTE, die nicht in weitere Komponenten unterteilt ist ANMERKUNG benutzt werden. SOFTWARE-EINHEITEN können zum Zweck des Software-Konfigurations-Managements oder zum Prüfen 3.29 SOUP (en: SOFTWARE OF UNKNOWN PROVENANCE) SOFTWARE UNBEKANNTER HERKUNFT SOFTWARE-KOMPONENTE, die bereits entwickelt und allgemein verfügbar ist und die nicht entwickelt wurde, um in das MEDIZINPRODUKT integriert zu werden (auch bekannt als Off-The-Shelf Software ), oder bereits fertig entwickelte Software, für die angemessene Aufzeichnungen zum Entwicklungs-PROZESS nicht verfügbar sind 3.30 SYSTEM integrierter Verbund, bestehend aus einem oder mehreren PROZESSEN, Hardware, Software, Einrichtungen und Personen, der eine Fähigkeit zur Verfügung stellt, um einen bestimmten Zweck oder ein bestimmtes Ziel zu erreichen [ISO/IEC 12207:1995, Definition 3.31], [9] N6) 3.31 AUFGABE eine Teilarbeit, die erledigt werden muss 3.32 RÜCKVERFOLGBARKEIT die Möglichkeit, eine Beziehung zwischen zwei oder mehr Produkten des Entwicklungs-PROZESSES herstellen zu können [IEEE :1990], [13] N6) 3.33 VERIFIZIERUNG Bestätigung durch Bereitstellen eines objektiven Nachweises, dass festgelegte Anforderungen erfüllt worden sind ANMERKUNG 1 Die Benennung verifiziert wird zur Bezeichnung des entsprechenden Status verwendet. [ISO 9000:2000, Definition 3.8.4] N6) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. 14

17 ANMERKUNG 2 Bei Design und Entwicklung beschäftigt sich die VERIFIZIERUNG mit dem PROZESS der EVALUATION des Ergebnisses einer gegebenen AKTIVITÄT um festzustellen, dass die für diese AKTIVITÄT aufgestellten Anforderungen eingehalten wurden VERSION gekennzeichnete Ausgabe eines KONFIGURATIONSELEMENTES ANMERKUNG 1 Die Änderung einer VERSION eines SOFTWARE-PRODUKTS, die in einer neuen VERSION resultiert, erfordert eine Konfigurations-Management-Aktion. ANMERKUNG 2 Basierend auf ISO/IEC 12207:1995, Definition 3.37 [9] N7). 4 *Allgemeine Anforderungen 4.1 *Qualitätsmanagement-System Der HERSTELLER von MEDIZINPRODUKTE-SOFTWARE muss seine Fähigkeit, MEDIZINPRODUKTE-SOFTWARE zu erstellen, die Kundenanforderungen und anwendbare regulatorische Anforderungen dauerhaft erfüllt, nachweisen. ANMERKUNG 1 Diese Fähigkeit kann durch die Anwendung eines Qualitätsmanagementsystems nachgewiesen werden, das ISO [7] oder einer nationalen Norm für Qualitätsmanagement-SYSTEME oder einem Qualitätsmanagement-System, das durch nationale Vorschriften gefordert wird, entspricht. ANMERKUNG 2 Anleitung für die Anwendung von Anforderungen für Qualitätsmanagement-Systeme findet sich in ISO/IEC [11]. 4.2 *RISIKOMANAGEMENT Der HERSTELLER muss einen RISIKOMANAGEMENT-PROZESS nach ISO anwenden. 4.3 *Software-Sicherheitsklassifizierung a) Der HERSTELLER muss jedem SOFTWARE-SYSTEM eine Software-Sicherheitsklasse (A, B oder C) zuordnen, je nach den möglichen Auswirkungen einer Gefährdung auf den Patienten, den Anwender oder andere Personen, zu der das SOFTWARE-SYSTEM beitragen kann. Die Software-Sicherheitsklassen müssen zu Beginn basierend auf dem Schweregrad wie folgt zugeordnet werden: Klasse A: Keine Verletzung oder Schädigung der Gesundheit ist möglich. Klasse B: Keine SCHWERE VERLETZUNG ist möglich. Klasse C: Tod oder SCHWERE VERLETZUNG ist möglich. Wenn die GEFÄHRDUNG davon herrühren könnte, dass das SOFTWARE-SYSTEM sich nicht entsprechend seiner Spezifikation verhält, muss die Wahrscheinlichkeit einer solchen Fehlfunktion als 100 Prozent angenommen werden. Wenn das RISIKO des Todes oder einer SCHWEREN VERLETZUNG, das von einem Software-Fehler herrührt, anschließend durch eine Hardware-RISIKOKONTROLL-Maßnahme auf ein vertretbares Maß verringert wird (wie in ISO definiert), und zwar dadurch, dass die Folgen des Fehlers verringert werden oder dass die Wahrscheinlichkeit des Todes oder einer SCHWEREN VERLETZUNG, die von diesem Fehler herrührt, verringert wird, so kann die Software-Sicherheitsklasse von C auf B herabgesetzt N7) Nationale Fußnote: Der Verweis zu den Literaturhinweisen fehlt in der Internationalen Norm. 15

18 werden, und wenn das RISIKO einer leichten Verletzung, das von einem Software-Fehler herrührt, in ähnlicher Weise durch eine Hardware-RISIKOKONTROLL-Maßnahme auf ein vertretbares Maß verringert wird, so kann die Software-Sicherheitsklasse von B auf A herabgesetzt werden. b) Der HERSTELLER muss jedem SOFTWARE-SYSTEM, das zur Implementierung einer RISIKOKONTROLL- Maßnahme beiträgt, eine Software-Sicherheitsklasse zuordnen. Sie basiert auf den möglichen Auswirkungen derjenigen GEFÄHRDUNG, die durch die RISIKOKONTROLL-Maßnahme kontrolliert wird. c) Der HERSTELLER muss die Software-Sicherheitsklasse, die jedem SOFTWARE-SYSTEM zugeordnet wurde, in der RISIKOMANAGEMENT-AKTE dokumentieren. d) Wenn ein SOFTWARE-SYSTEM in SOFTWARE-KOMPONENTEN zerlegt wird und wenn eine SOFTWARE- KOMPONENTE in weitere SOFTWARE-KOMPONENTEN zerlegt wird, so müssen diese SOFTWARE- KOMPONENTEN die Software-Sicherheitsklasse der ursprünglichen SOFTWARE-KOMPONENTE (oder des SOFTWARE-SYSTEMS) übernehmen, es sei denn, der HERSTELLER dokumentiert eine Begründung für die Klassifizierung in eine andere Software-Sicherheitsklasse. Eine solche Begründung muss darlegen, wie die neuen SOFTWARE-KOMPONENTEN so abgegrenzt sind, dass sie getrennt klassifiziert werden können. e) Der HERSTELLER muss die Software-Sicherheitsklasse jeder SOFTWARE-KOMPONENTE dokumentieren, wenn sich deren Klasse von der Klasse derjenigen SOFTWARE-KOMPONENTE, aus der sie durch Zerlegung entstanden ist, unterscheidet. f) Wenn ein PROZESS für SOFTWARE-KOMPONENTEN einer bestimmten Klasse gefordert wird und wenn dieser PROZESS notwendigerweise auf eine Gruppe von SOFTWARE-KOMPONENTEN angewandt wird, muss der HERSTELLER, um diese Norm einzuhalten, diejenigen PROZESSE und AUFGABEN verwenden, die durch die Klassifizierung der am höchsten klassifizierten SOFTWARE-KOMPONENTE in dieser Gruppe gefordert werden, es sei denn, der HERSTELLER dokumentiert eine Begründung für die Verwendung einer niedrigeren Klasse in der RISIKOMANAGEMENT-AKTE. g) Bis eine Software-Sicherheitsklasse zugeordnet ist, gelten für jedes SOFTWARE-SYSTEM die Anforderungen der Klasse C. ANMERKUNG Bei den folgenden Anforderungen werden die Software-Sicherheitsklassen, für die diese Anforderung durchgeführt werden muss, in der Form [Klasse ] festgelegt. 5 Software-Entwicklungs-PROZESS 5.1 *Planung der Software-Entwicklung Software-Entwicklungsplan Der HERSTELLER muss einen Software-Entwicklungsplan (oder -pläne) für die Durchführung der AKTIVITÄTEN des Software-Entwicklungs-PROZESSES erstellen. Dieser PROZESS muss dem Anwendungsbereich, dem Umfang und den Software-Sicherheitsklassen des zu entwickelnden SOFTWARE-SYSTEMS angemessen entsprechen. Das LEBENSZYKLUS-MODELL DER SOFTWARE-ENTWICKLUNG muss entweder vollständig definiert oder im Plan (oder Plänen) referenziert sein. Der Plan muss folgende Punkte umfassen: a) die PROZESSE, die bei der Entwicklung des SOFTWARE-SYSTEMS verwendet werden (siehe ANMERKUNG 4); b) die ZU LIEFERNDEN ERGEBNISSE (einschließlich der Dokumentation) der AKTIVITÄTEN und AUFGABEN; c) RÜCKVERFOLGBARKEIT zwischen SYSTEM-Anforderungen, Software-Anforderungen, SOFTWARE-SYSTEM- Prüfungen und RISIKOKONTROLL-Maßnahmen, die in Software implementiert werden; d) Software-Konfigurations- und Änderungsmanagement, einschließlich SOUP-KONFIGURATIONSELEMENTEN und Software, die zur Entwicklungsunterstützung verwendet wird, und e) Software-Problemlösung und Behandlung von Problemen, die bei SOFTWARE-PRODUKTEN, ZU LIEFERNDEN ERGEBNISSEN und AKTIVITÄTEN in jeder Phase des Lebenszyklus entdeckt werden. [Klasse A, B, C] ANMERKUNG 1 Das LEBENSZYKLUS-MODELL DER SOFTWAREENTWICKLUNG kann unterschiedliche Elemente (PROZESSE, AKTIVITÄTEN, AUFGABEN und ZU LIEFERNDE ERGEBNISSE) für unterschiedliche SOFTWARE-KOMPONENTEN entsprechend der Software-Sicherheitsklassifizierung für jede SOFTWARE-KOMPONENTE des SOFTWARE-SYSTEMS festlegen. 16

19 ANMERKUNG 2 Diese AKTIVITÄTEN und AUFGABEN können überlappend sein, können sich gegenseitig beeinflussen und können iterativ oder rekursiv durchgeführt werden. Es ist nicht die Absicht, die Anwendung eines bestimmten Lebenszyklus-Modells vorauszusetzen. ANMERKUNG 3 Andere PROZESSE werden in dieser Norm getrennt vom Entwicklungs-PROZESS beschrieben. Dies bedeutet nicht, dass sie als getrennte AKTIVITÄTEN und AUFGABEN implementiert werden müssen. Die AKTIVITÄTEN und AUFGABEN der anderen PROZESSE können in den Entwicklungs-PROZESS integriert werden. ANMERKUNG 4 Der Software-Entwicklungsplan kann auf bestehende PROZESSE verweisen oder neue definieren. ANMERKUNG 5 Der Software-Entwicklungsplan kann in einen Gesamt-SYSTEM-Entwicklungsplan integriert sein Aktualisierung des Software-Entwicklungsplans Soweit angemessen, muss der HERSTELLER den Plan dem Entwicklungsfortschritt entsprechend aktualisieren. [Klasse A, B, C] Referenz im Software-Entwicklungsplan auf SYSTEM-Design und -Entwicklung a) Der HERSTELLER muss SYSTEM-Anforderungen im Software-Entwicklungsplan als Vorgaben für die Software-Entwicklung referenzieren. b) Der HERSTELLER muss im Software-Entwicklungsplan Verfahren zur Koordination von Software- Entwicklung und Design- und Entwicklungs-Validierung einschließen oder referenzieren; dies ist für die Erfüllung von 4.1 erforderlich. [Klasse A, B, C] ANMERKUNG Es kann möglicherweise keinen Unterschied zwischen SOFTWARE-SYSTEM-Anforderungen und SYSTEM- Anforderungen geben, wenn das SOFTWARE-SYSTEM ein eigenständiges SYSTEM (eigenständiges Softwareprodukt) ist Planung von Normen, Methoden und Werkzeugen der Software-Entwicklung Der HERSTELLER muss im Software-Entwicklungsplan einschließen oder referenzieren: a) Normen, b) Methoden und c) Werkzeuge, die im Zusammenhang mit der Entwicklung von SOFTWARE-KOMPONENTEN der Klasse C stehen. [Klasse C] Planung der Software-Integration und der Integrationsprüfung Der HERSTELLER muss im Software-Entwicklungsplan einen Plan einschließen oder referenzieren, wie die SOFTWARE-KOMPONENTEN (einschließlich SOUP) integriert und wie während der Integration Prüfungen durchgeführt werden. [Klasse B, C] ANMERKUNG Es ist vertretbar, die Integrationsprüfung und die SOFTWARE-SYSTEM-Prüfung in einem Plan und einem Satz von AKTIVITÄTEN zu kombinieren Planung der Software-VERIFIZIERUNG Der HERSTELLER muss im Software-Entwicklungsplan folgende Informationen über die VERIFIZIERUNG einschließen oder referenzieren: a) ZU LIEFERNDE ERGEBNISSE, die eine VERIFIZIERUNG erfordern; b) die erforderlichen VERIFIZIERUNGS-AUFGABEN für jede AKTIVITÄT des Lebenszyklus, c) Meilensteine, bei denen die ZU LIEFERNDEN ERGEBNISSE VERIFIZIERT werden, und d) die Akzeptanzkriterien für die VERIFIZIERUNG der ZU LIEFERNDEN ERGEBNISSE. [Klasse A, B, C] 17

20 5.1.7 Planung des Software-RISIKOMANAGEMENTS Der HERSTELLER muss im Software-Entwicklungsplan einen Plan einschließen oder referenzieren, wie die AKTIVITÄTEN und AUFGABEN des Software-RISIKOMANAGEMENTS durchgeführt werden, einschließlich des Managements von RISIKEN, die sich auf SOUP beziehen. [Klasse A, B, C] ANMERKUNG Siehe Abschnitt Planung der Dokumentation Der HERSTELLER muss Informationen über die Dokumente, die während des Software-Entwicklungszyklus erzeugt werden sollen, in den Software-Entwicklungsplan mit einschließen oder in diesem referenzieren. Für jedes identifizierte Dokument oder jede Art von Dokumenten müssen die folgenden Informationen enthalten sein oder referenziert werden: a) Titel, Benennung / Bezeichnung oder Konvention der Benennung; b) Zweck; c) vorgesehene Zielgruppe des Dokuments und d) Verfahren und Verantwortlichkeiten für Entwicklung, Überprüfung, Genehmigung und Änderung. [Klasse A, B, C] Planung des Software-Konfigurationsmanagements Der HERSTELLER muss im Software-Entwicklungsplan Informationen über das Software-Konfigurationsmanagement einschließen oder referenzieren. Die Information über das Software-Konfigurationsmanagement muss enthalten oder referenzieren: a) die Klassen, Arten, Kategorien oder Listen von Komponenten, die kontrolliert werden sollen; b) die AKTIVITÄTEN und AUFGABEN des Software-Konfigurationsmanagements; c) die Organisation(en), die für die Durchführung des Software-Konfigurationsmanagements und der AKTIVITÄTEN verantwortlich ist (sind); d) deren Beziehung zu anderen Organisationen, wie zum Beispiel der Software-Entwicklung oder -Wartung; e) wann die Komponenten unter Konfigurationskontrolle gestellt werden sollen und f) wann der Problemlösungs-PROZESS benutzt werden soll. [Klasse A, B, C] Zu kontrollierende unterstützende Komponenten Zu den zu kontrollierenden Komponenten gehören Werkzeuge, Elemente oder Einstellungen, die zur Entwicklung der MEDIZINPRODUKTE-SOFTWARE benötigt werden und die die MEDIZINPRODUKTE-SOFTWARE beeinflussen könnten. [Klasse B, C] ANMERKUNG Beispiele für solche Komponenten sind Compiler-/Assembler-VERSIONEN, Make-Dateien, Batch-Dateien und spezifische Einstellungen der Entwicklungsumgebung Kontrolle der Software-KONFIGURATIONSELEMENTE vor der Verifizierung Der HERSTELLER muss planen, die KONFIGURATIONSELEMENTE unter eine dokumentierte Konfigurationsmanagement-Kontrolle zu stellen, bevor sie VERIFIZIERT werden. [Klasse B, C] 18

21 5.2 *Analyse der Software-Anforderungen Ableitung der Software-Anforderungen aus den SYSTEM-Anforderungen und Dokumentation Für jedes SOFTWARE-SYSTEM des MEDIZINPRODUKTS muss der HERSTELLER die Anforderungen an das SOFTWARE-SYSTEM aus den Anforderungen an das Gesamt-SYSTEM ableiten und dokumentieren. [Klasse A, B, C] ANMERKUNG Es kann möglicherweise keinen Unterschied zwischen SOFTWARE-SYSTEM-Anforderungen und SYSTEM- Anforderungen geben, wenn das SOFTWARE-SYSTEM ein eigenständiges SYSTEM (eigenständiges Softwareprodukt) ist Inhalt der Software-Anforderungen Soweit angemessen muss der HERSTELLER in die Software-Anforderungen für die MEDIZINPRODUKTE- SOFTWARE Folgendes einschließen: a) Anforderungen an die Funktionalität und die Leistungsfähigkeit; ANMERKUNG 1 Beispiele sind: Leistungsmerkmale (z. B. Zweck der Software, Anforderungen bezüglich Zeitverhalten), physikalische Merkmale (z. B. Programmiersprache, Plattform, Betriebssystem), Rechnerumgebung (z. B. Hardware, Speichergröße, Prozessor, Zeitzone, Netzwerk-Infrastruktur), in der die Software laufen soll, und Notwendigkeit der Kompatibilität mit Nachrüstungen oder mit mehreren SOUP- oder anderen Geräte-VERSIONEN. b) Ein- und Ausgaben des SOFTWARE-SYSTEMS; ANMERKUNG 2 Beispiele sind: Merkmale von Daten (z. B. numerisch, alpha-numerisch, Format), Bereiche, Grenzen und Werte der Voreinstellungen. c) Schnittstellen zwischen dem SOFTWARE-SYSTEM und anderen SYSTEMEN; d) Software-gesteuerte Alarme, Warnungen und Anwender-Meldungen; e) Anforderungen für die DATENSICHERHEIT; ANMERKUNG 3 Beispiele sind: Anforderungen im Zusammenhang mit der Beeinträchtigung vertraulicher Informationen, Authentifizierung, Autorisierung, Audio-Pfad, Integrität der Kommunikation. f) Anforderungen an die Gebrauchstauglichkeit, die maßgeblich sind hinsichtlich menschlichem Versagen und Ausbildung; ANMERKUNG 4 Beispiele sind solche in Bezug auf: Unterstützung für manuelle Tätigkeiten, Interaktionen zwischen Mensch und Gerät, Einschränkungen für das Personal und Bereiche, die eine konzentrierte menschliche Aufmerksamkeit erfordern. ANMERKUNG 5 Informationen über Anforderungen hinsichtlich der Entwicklung von Gebrauchstauglichkeit finden sich in IEC [15]. 19

22 g) Datendefinition und Datenbank-Anforderungen; ANMERKUNG 6 Beispiele sind: Form, Eignung, Funktion. h) Anforderungen für die Installation und Abnahme der gelieferten MEDIZINPRODUKTE-SOFTWARE am Standort/an den Standorten der Anwendung und Wartung; i) Anforderungen hinsichtlich Methoden des Betriebs und der Wartung; j) Anwender-Dokumentation, die entwickelt werden soll; k) Anforderungen hinsichtlich der Wartung durch den Betreiber und l) regulatorische Anforderungen. [Klasse A, B, C] ANMERKUNG 7 Möglicherweise sind nicht alle Anforderungen bei Beginn der Software-Entwicklung verfügbar. ANMERKUNG 8 ISO/IEC [8] liefert Informationen über Qualitätsmerkmale, die bei der Festlegung von Software- Anforderungen nützlich sein könnten Einbeziehen von RISIKOKONTROLL-Maßnahmen in die Software-Anforderungen Soweit es für die MEDIZINPRODUKTE-SOFTWARE angemessen ist, muss der HERSTELLER RISIKOKONTROLL- Maßnahmen für Hardware-Ausfälle und mögliche Software-Defekte in die Anforderungen aufnehmen. [Klasse B, C] ANMERKUNG Möglicherweise sind diese Anforderungen bei Beginn der Software-Entwicklung nicht verfügbar, und sie können sich im Verlauf der Software-Entwicklung und der weiteren Definition von RISIKOKONTROLL-Maßnahmen ändern Erneute EVALUATION der RISIKOANALYSE Wenn Software-Anforderungen festgelegt werden, muss der HERSTELLER die RISIKOANALYSE des MEDIZINPRODUKTS erneut EVALUIEREN und, soweit angemessen, aktualisieren. [Klasse A, B, C] Aktualisierung von SYSTEM-Anforderungen Der HERSTELLER muss sicherstellen, dass vorhandene Anforderungen, einschließlich der SYSTEM- Anforderungen, als Ergebnis der AKTIVITÄT der Analyse der Software-Anforderungen erneut EVALUIERT und, soweit angemessen, aktualisiert werden. [Klasse A, B, C] VERIFIZIERUNG von Software-Anforderungen Der HERSTELLER muss VERIFIZIEREN und dokumentieren, dass die Software-Anforderungen: a) die SYSTEM-Anforderungen einschließlich der Anforderungen für die RISIKOBEHERRSCHUNG implementieren; b) sich nicht gegenseitig widersprechen; c) so formuliert sind, dass Mehrdeutigkeit vermieden wird; d) so formuliert sind, dass sie die Festlegung von Prüfkriterien und die Durchführung von Prüfungen, die entscheiden, ob die Prüfkriterien erfüllt sind, ermöglichen; e) eindeutig identifiziert werden können; f) auf SYSTEM-Anforderungen oder andere Quellen zurückverfolgt werden können. [Klasse A, B, C] ANMERKUNG Diese Norm fordert nicht die Verwendung einer formalen Spezifikationssprache. 20

23 5.3 *Design der Software-ARCHITEKTUR Umsetzung von Software-Anforderungen in eine ARCHITEKTUR Der HERSTELLER muss die Anforderungen für die MEDIZINPRODUKTE-SOFTWARE in eine dokumentierte ARCHITEKTUR, die die Struktur der Software beschreibt und die die SOFTWARE-KOMPONENTEN identifiziert, umsetzen. [Klasse B, C] Entwicklung einer ARCHITEKTUR für die Schnittstellen zwischen SOFTWARE-KOMPONENTEN Der HERSTELLER muss eine ARCHITEKTUR für die Schnittstellen zwischen den SOFTWARE-KOMPONENTEN und den Komponenten außerhalb der SOFTWARE-KOMPONENTEN (Software und Hardware) sowie zwischen den einzelnen SOFTWARE-KOMPONENTEN entwickeln und dokumentieren. [Klasse B, C] Spezifikation der Funktions- und Leistungsanforderungen für SOUP-Komponenten Wenn eine SOFTWARE-KOMPONENTE als SOUP identifiziert ist, muss der HERSTELLER Funktions- und Leistungsanforderungen für die SOUP-Komponente festlegen, die für deren bestimmungsgemäßen Gebrauch notwendig sind. [Klasse B, C] Spezifikation der für die SOUP-Komponente erforderliche SYSTEM-Hardware und -Software Wenn eine SOFTWARE-KOMPONENTE als SOUP identifiziert ist, muss der HERSTELLER die SYSTEM-Hardware und -Software spezifizieren, die erforderlich ist, um den ordnungsgemäßen Betrieb der SOUP-Komponente zu gewährleisten. [Klasse B, C] ANMERKUNG Beispiele sind: Prozessortyp und -geschwindigkeit, Speichertyp und -größe, Typ der SYSTEM-Software, Anforderungen für Kommunikations- und Anzeigesoftware Festlegung der für die RISIKOBEHERRSCHUNG erforderlichen Abgrenzung Der HERSTELLER muss die Abgrenzung zwischen den SOFTWARE-KOMPONENTEN festlegen, die für die RISIKOBEHERRSCHUNG wesentlich ist, und muss zeigen, wie sichergestellt wird, dass die Abgrenzung wirksam ist. [Klasse C] ANMERKUNG Ein Beispiel einer Abgrenzung ist, dass SOFTWARE-KOMPONENTEN auf verschiedenen Prozessoren ausgeführt werden. Die Wirksamkeit der Abgrenzung kann dadurch sichergestellt werden, dass keine gemeinsamen Ressourcen zwischen den Prozessoren bestehen VERIFIZIERUNG der Software-ARCHITEKTUR Der HERSTELLER muss VERIFIZIEREN und dokumentieren, dass: a) die Software-ARCHITEKTUR die SYSTEM- und Software-Anforderungen einschließlich derer, die sich auf die RISIKOBEHERRSCHUNG beziehen, implementiert; b) die Software-ARCHITEKTUR in der Lage ist, Schnittstellen zwischen den einzelnen SOFTWARE- KOMPONENTEN und zwischen SOFTWARE-KOMPONENTEN und Hardware zu unterstützen, und c) die ARCHITEKTUR des MEDIZINPRODUKTS den ordnungsgemäßen Betrieb aller SOUP-Komponenten unterstützt. [Klasse B, C] 21

24 5.4 *Detailliertes Software-Design Feinaufteilung der Software-ARCHITEKTUR in SOFTWARE-EINHEITEN Der HERSTELLER muss die Software-ARCHITEKTUR solange weiter unterteilen, bis sie durch SOFTWARE- EINHEITEN dargestellt wird. [Klasse B, C] Entwicklung eines detaillierten Designs für jede SOFTWARE-EINHEIT Der HERSTELLER muss ein detailliertes Design für jede SOFTWARE-EINHEIT einer SOFTWARE-KOMPONENTE entwickeln und dokumentieren. [Klasse C] Entwicklung eines detaillierten Designs für Schnittstellen Der HERSTELLER muss ein detailliertes Design für alle Schnittstellen zwischen der SOFTWARE-EINHEIT und externen Komponenten (Hardware oder Software) sowie für alle Schnittstellen zwischen den einzelnen SOFTWARE-EINHEITEN entwickeln. [Klasse C] VERIFIZIERUNG des detaillierten Designs Der HERSTELLER muss VERIFIZIEREN und dokumentieren, dass das detaillierte Design der Software: a) die Software-ARCHITEKTUR implementiert, b) frei von Widersprüchen gegenüber der Software-ARCHITEKTUR ist. [Klasse C] 5.5 *Implementierung und VERIFIZIERUNG der SOFTWARE-EINHEITEN Implementierung jeder SOFTWARE-EINHEIT Der HERSTELLER muss jede SOFTWARE-EINHEIT implementieren. [Klasse A, B, C] Festlegung eines VERIFIZIERUNGSPROZESSES für SOFTWARE-EINHEITEN Der HERSTELLER muss Strategien, Methoden und Verfahren für die VERIFIZIERUNG jeder SOFTWARE-EINHEIT festlegen. Wenn die VERIFIZIERUNG durch Prüfung stattfindet, müssen die Prüfverfahren auf Korrektheit EVALUIERT werden. [Klasse B, C] ANMERKUNG Es ist vertretbar, Integrationsprüfung und SOFTWARE-SYSTEM-Prüfung in einem einzigen Plan und Satz von AKTIVITÄTEN zu kombinieren Akzeptanzkriterien für SOFTWARE-EINHEITEN Soweit angemessen, muss der HERSTELLER für SOFTWARE-EINHEITEN vor ihrer Integration in größere SOFTWARE-KOMPONENTEN Akzeptanzkriterien festlegen und sicherstellen, dass die SOFTWARE-EINHEITEN die Akzeptanzkriterien erfüllen. [Klasse B, C] ANMERKUNG Beispiele für Akzeptanzkriterien sind: Implementiert der Software-Code die Anforderungen einschließlich der RISIKOKONTROLL-Maßnahmen? Ist der Software-Code frei von Widersprüchen unter Berücksichtigung der Schnittstellen, die im detaillierten Design der SOFTWARE-EINHEIT dokumentiert sind? Entspricht der Software-Code festgelegten Programmier-Verfahren und Codierungsnormen? 22

25 5.5.4 Zusätzliche Akzeptanzkriterien für SOFTWARE-EINHEITEN Falls im Design vorhanden, muss der HERSTELLER zusätzliche Akzeptanzkriterien einfügen, soweit dies angemessen ist, für: a) richtige Abfolge von Ereignissen, b) Daten- und Kontrollfluss, c) die geplante Belegung von Ressourcen, d) Behandlung von Fehlern (Fehlerdefinition, Isolierung und Wiederaufnahme), e) Initialisierung von Variablen, f) Selbstdiagnose, g) Speichermanagement und Speicherüberlauf und h) Grenzwertbedingungen. [Klasse C] VERIFIZIERUNG der SOFTWARE-EINHEITEN Der HERSTELLER muss die VERIFIZIERUNG der SOFTWARE-EINHEITEN durchführen und die Ergebnisse dokumentieren. [Klasse B, C] 5.6 *Software-Integration und -Integrationsprüfung Integration der SOFTWARE-EINHEITEN Der HERSTELLER muss die SOFTWARE-EINHEITEN entsprechend dem Integrationsplan (siehe 5.1.5) integrieren. [Klasse B, C] VERIFIZIERUNG der Software-Integration Der HERSTELLER muss die folgenden Aspekte der Software-Integration in Übereinstimmung mit dem Integrationsplan (siehe 5.1.5) VERIFIZIEREN und dokumentieren: a) Die SOFTWARE-EINHEITEN wurden in SOFTWARE-KOMPONENTEN und in das SOFTWARE-SYSTEM integriert; b) die Hardware-Komponenten, SOFTWARE-KOMPONENTEN und die Unterstützung für manuellen Betrieb (z. B. Mensch-Maschine-Schnittstelle, Online-Hilfe-Menüs, Spracherkennung, Sprachsteuerung) des SYSTEMS wurden in das SYSTEM integriert. [Klasse B, C] ANMERKUNG Diese VERIFIZIERUNG zeigt nur, dass die Komponenten entsprechend dem Plan integriert wurden, nicht, dass sie bestimmungsgemäß funktionieren. Diese VERIFIZIERUNG wird sehr wahrscheinlich durch eine Inspektion implementiert Prüfung der integrierten Software Der HERSTELLER muss die integrierten SOFTWARE-KOMPONENTEN in Übereinstimmung mit dem Integrationsplan (siehe 5.1.5) prüfen und die Ergebnisse dokumentieren. [Klasse B, C] Inhalt der Integrationsprüfung Bei der Prüfung der Software-Integration muss der HERSTELLER darauf achten, ob die integrierte SOFTWARE- KOMPONENTE wie beabsichtigt funktioniert. [Klasse B, C] ANMERKUNG 1 Beispiele, die zu beachten sind: die geforderte Funktionalität der Software, 23

26 die Implementierung der RISIKOKONTROLL-Maßnahmen, festgelegtes Timing und andere Verhaltensweisen, festgelegte Funktion von internen und externen Schnittstellen und Prüfung unter abnormalen Bedingungen einschließlich des vorhersehbaren Missbrauchs. ANMERKUNG 2 Es ist vertretbar, die Integrationsprüfung und die SOFTWARE-SYSTEM-Prüfung in einem einzigen Plan und Satz von AKTIVITÄTEN zu kombinieren VERIFIZIERUNG der Integrationsprüfverfahren Der HERSTELLER muss die Korrektheit des Integrationsprüfverfahrens EVALUIEREN. [Klasse B, C] Durchführung von REGRESSIONSPRÜFUNGEN Wenn SOFTWARE-KOMPONENTEN integriert werden, muss der HERSTELLER REGRESSIONSPRÜFUNGEN durchführen, die geeignet sind zu zeigen, dass keine ANOMALIEN in die vorher integrierte Software eingeführt wurden. [Klasse B, C] Inhalt von Aufzeichnungen über die Integrationsprüfung Der HERSTELLER muss: a) das Prüfergebnis dokumentieren (pass/fail und eine Liste von ANOMALIEN), b) genügend Aufzeichnungen aufbewahren, um eine Wiederholung der Prüfung zu ermöglichen, und c) den Prüfer identifizieren. [Klasse B, C] Die Anforderung b) könnte zum Beispiel durch die Aufbewahrung folgender Aufzeichnungen implemen- ANMERKUNG tiert werden: Spezifikationen von Prüffällen, die die erforderlichen Aktionen und die erwarteten Ergebnisse zeigen, Aufzeichnungen über die Geräte, Aufzeichnungen über die Prüfumgebung (einschließlich Software-Werkzeuge), die für die Prüfung verwendet wurde Verwendung eines Problemlösungs-PROZESSES für Software Der HERSTELLER muss ANOMALIEN, die bei der Software-Integration und bei der Integrationsprüfung gefunden wurden, in einen Problemlösungs-PROZESS für Software einbringen. [Klasse B, C] ANMERKUNG Siehe Abschnitt *Prüfung des SOFTWARE-SYSTEMS Festlegung von Prüfungen für Software-Anforderungen Der HERSTELLER muss einen Satz von Prüfungen festlegen und durchführen, die durch Angabe von Eingabewerten, erwarteten Ausgaben, Pass/fail-Kriterien und Verfahren zur Durchführung von SOFTWARE- SYSTEM-Prüfungen so beschrieben sind, dass alle Software-Anforderungen abgedeckt werden. [Klasse B, C] ANMERKUNG 1 Es ist vertretbar, die Integrationsprüfung und die SOFTWARE-SYSTEM-Prüfung in einem einzigen Plan und Satz von AKTIVITÄTEN zu kombinieren. Es ist auch vertretbar, Software-Anforderungen in früheren Phasen zu prüfen. ANMERKUNG 2 Es können nicht nur Einzelprüfungen für jede Anforderung durchgeführt werden, sondern auch Prüfungen für Kombinationen von Anforderungen, insbesondere, wenn Abhängigkeiten zwischen Anforderungen bestehen. 24

27 5.7.2 Verwendung eines Problemlösungs-PROZESSES für Software Der HERSTELLER muss ANOMALIEN, die bei der SOFTWARE-SYSTEM-Prüfung gefunden wurden, in einen Problemlösungs-PROZESS für Software aufnehmen. [Klasse B, C] Prüfungswiederholung nach Änderungen Wenn bei der SOFTWARE-SYSTEM-Prüfung Änderungen gemacht werden, muss der HERSTELLER: a) soweit angemessen Prüfungen wiederholen oder modifizierte oder zusätzliche Prüfungen durchführen, um die Wirksamkeit der Änderung zur Problembehebung zu VERIFIZIEREN, b) geeignete Prüfungen durchführen, um zu zeigen, dass keine unbeabsichtigten Nebeneffekte eingeführt wurden, c) relevante RISIKOMANAGEMENT-AKTIVITÄTEN durchführen, wie in 7.4 definiert. [Klasse B, C] VERIFIZIERUNG der SOFTWARE-SYSTEM-Prüfungen Der HERSTELLER muss VERIFIZIEREN, dass: a) die benutzten VERIFIZIERUNGS-Strategien und Prüfverfahren angemessen sind; b) SOFTWARE-SYSTEM-Prüfverfahren sich auf Software-Anforderungen zurückverfolgen lassen; c) alle Software-Anforderungen geprüft oder anderweitig VERIFIZIERT wurden und d) Prüfergebnisse die erforderlichen Pass/fail-Kriterien erfüllen. [Klasse B, C] Inhalte der Aufzeichnungen der SOFTWARE-SYSTEM-Prüfungen Der HERSTELLER muss: a) das Prüfergebnis dokumentieren (pass/fail und eine Liste der ANOMALIEN), b) genügend Aufzeichnungen aufbewahren, um die Wiederholung von Prüfungen zu erlauben, c) die Prüfperson identifizieren. [Klasse B, C] ANMERKUNG Die Anforderung b) könnte zum Beispiel durch die Aufbewahrung folgender Aufzeichnungen implementiert werden: Spezifikationen von Prüffällen, die die erforderlichen Aktionen und die erwarteten Ergebnisse zeigen, Aufzeichnungen über die Geräte, Aufzeichnungen über die Prüfumgebung (einschließlich Software-Werkzeuge), die für die Prüfung verwendet wurde. 5.8 *Software-Freigabe Sicherstellen, dass die VERIFIZIERUNG der Software vollständig ist Der HERSTELLER muss sicherstellen, dass die VERIFIZIERUNG der Software abgeschlossen wurde und die Ergebnisse bewertet wurden, bevor die Software freigegeben wird. [Klasse B, C] Dokumentation bekannter restlicher ANOMALIEN Der HERSTELLER muss alle bekannten restlichen ANOMALIEN dokumentieren. [Klasse B, C] 25

28 5.8.3 Bewertung bekannter restlicher ANOMALIEN Der HERSTELLER muss sicherstellen, dass alle bekannten restlichen ANOMALIEN bewertet wurden, um sicherzustellen, dass sie nicht zu einem unvertretbaren RISIKO beitragen. [Klasse B, C] Dokumentation freigegebener VERSIONEN Der HERSTELLER muss die VERSIONEN des SOFTWARE-PRODUKTS, die freigegeben werden, dokumentieren. [Klasse A, B, C] Dokumentation, wie freigegebene Software erzeugt wurde Der HERSTELLER muss das Verfahren und die Umgebung dokumentieren, die verwendet wurden, um die freigegebene Software zu erzeugen. [Klasse B, C] Sicherstellen, dass AKTIVITÄTEN und AUFGABEN abgeschlossen sind Der HERSTELLER muss sicherstellen, dass alle AKTIVITÄTEN und AUFGABEN abgeschlossen sind und die zugehörige Dokumentation vollständig ist. [Klasse B, C] Archivierung der Software Der HERSTELLER muss Folgendes archivieren: a) das SOFTWARE-PRODUKT, die KONFIGURATIONSELEMENTE und b) die Dokumentation. Dies gilt zumindest für die längere der folgenden beiden Zeiten: Die Lebenszeit des Geräts, wie sie vom HERSTELLER definiert ist, oder die Zeitspanne, die durch relevante regulatorische Anforderungen festgelegt ist. [Klasse B, C] Sicherstellen der Wiederholbarkeit der Software-Freigabe Der HERSTELLER muss Verfahren festlegen, die sicherstellen, dass das freigegebene SOFTWARE-PRODUKT zuverlässig an die Stelle seiner Verwendung ausgeliefert werden kann, und zwar ohne Beschädigung oder nicht autorisierte Änderung. Diese Verfahren müssen die Produktion und die Handhabung der Medien, die das SOFTWARE-PRODUKT enthalten, adressieren. Soweit angemessen, ist Folgendes eingeschlossen: Vervielfältigung, Kennzeichnung der Medien, Verpackung, Schutzmaßnahmen, Lagerung und Auslieferung. [Klasse B, C] 6 Software-Wartungs-PROZESS 6.1 *Festlegung eines Plans für die Software-Wartung Der HERSTELLER muss einen Plan (oder Pläne) für die Software-Wartung festlegen, um die AKTIVITÄTEN und AUFGABEN des Wartungs-PROZESSES durchzuführen. Der Plan muss Folgendes adressieren: 26

29 a) Verfahren für Empfang, Dokumentation, EVALUATION, Lösung und Rückverfolgung von Rückmeldungen, die sich nach der Freigabe der MEDIZINPRODUKTE-SOFTWARE ergeben; b) Kriterien für die Entscheidung, ob Rückmeldungen als Problem zu betrachten sind; c) Verwendung des Software-RISIKOMANAGEMENT-PROZESSES; d) Verwendung des Problemlösungs-PROZESSES für Software für die Analyse und Lösung von Problemen, die sich nach der Freigabe der MEDIZINPRODUKTE-SOFTWARE ergeben; e) Verwendung des Software-Konfigurationsmanagement-PROZESSES (Abschnitt 8) für die Handhabung von Änderungen am bestehenden SYSTEM; f) Verfahren, um für SOUP Folgendes zu EVALUIEREN und implementieren: Nachrüstungen, Fehlerkorrekturen, Programmkorrekturen, Überalterung/Veralten. [Klasse A, B, C] 6.2 *Analyse von Problemen und Änderungen Dokumentation und EVALUATION von Rückmeldungen Überwachung von Rückmeldungen Der HERSTELLER muss Rückmeldungen über das freigegebene SOFTWARE-PRODUKT, sowohl von seiner eigenen Organisation als auch von Anwendern, überwachen. [Klasse A, B, C] Dokumentation und EVALUATION von Rückmeldungen Rückmeldungen müssen dokumentiert und daraufhin EVALUIERT werden, ob ein Problem in einem freigegebenen SOFTWARE-PRODUKT besteht. Jedes Problem muss als PROBLEMBERICHT aufgezeichnet werden (siehe Abschnitt 9). PROBLEMBERICHTE müssen wirkliche oder mögliche Schadensereignisse und Abweichungen von Spezifikationen enthalten. [Klasse A, B, C] EVALUATION von PROBLEMBERICHTEN auf Auswirkungen auf die SICHERHEIT Jeder PROBLEMBERICHT muss EVALUIERT werden um festzustellen, inwieweit die SICHERHEIT eines freigegebenen SOFTWARE-PRODUKTS betroffen ist, und ob eine Änderung des freigegebenen SOFTWARE- PRODUKTS erforderlich ist, um das Problem zu adressieren. [Klasse A, B, C] Verwendung des Problemlösungs-PROZESSES für Software Der HERSTELLER muss den Problemlösungs-PROZESS für Software (siehe Abschnitt 9) verwenden, um PROBLEMBERICHTE zu bearbeiten. [Klasse A, B, C] ANMERKUNG Wenn diese AKTIVITÄT erledigt ist, sollte jede Änderung der Sicherheitsklasse im SOFTWARE-SYSTEM oder seinen SOFTWARE-KOMPONENTEN bekannt sein. 27

30 6.2.3 Analyse der ÄNDERUNGSANFORDERUNGEN Zusätzlich zur Analyse, die in Abschnitt 9 gefordert wird, muss der HERSTELLER jede ÄNDERUNGS- ANFORDERUNG hinsichtlich ihrer Auswirkung auf die Organisation, auf freigegebene SOFTWARE-PRODUKTE und auf SYSTEME, zu denen sie eine Schnittstelle besitzt, analysieren. [Klasse B, C] Genehmigung von ÄNDERUNGSANFORDERUNGEN Der HERSTELLER muss ÄNDERUNGSANFORDERUNGEN, die freigegebene SOFTWARE-PRODUKTE ändern, EVALUIEREN und genehmigen. [Klasse A, B, C] Kommunikation mit Anwendern und zuständigen Behörden Der HERSTELLER muss diejenigen genehmigten ÄNDERUNGSANFORDERUNGEN identifizieren, die freigegebene SOFTWARE-PRODUKTE betreffen. Soweit es durch lokale Vorschriften gefordert wird, muss der HERSTELLER Anwender und zuständige Behörden über Folgendes informieren: a) Probleme in freigegebenen SOFTWARE-PRODUKTEN und die Konsequenzen aus deren weiterer Verwendung ohne Änderungen und b) jede Art von verfügbaren Änderungen für freigegebene SOFTWARE-PRODUKTE, und wie diese Änderungen erhältlich und installierbar sind. [Klasse A, B, C] 6.3 *Implementierung von Änderungen Verwendung eines festgelegten PROZESSES für die Implementierung von Änderungen Der HERSTELLER muss den Software-Entwicklungs-PROZESS (siehe Abschnitt 5) oder einen festgelegten Wartungs-PROZESS verwenden, um die Änderungen zu implementieren. [Klasse A, B, C] ANMERKUNG Für Anforderungen bezüglich des RISIKOMANAGEMENTS von Software-Änderungen siehe Erneute Freigabe eines geänderten SOFTWARE-SYSTEMS Der HERSTELLER muss geänderte SOFTWARE-SYSTEME nach 5.8 erneut freigeben. Änderungen können als Teil einer vollständigen erneuten Freigabe eines SOFTWARE-SYSTEMS freigegeben werden oder als Änderungs-Bausatz, der die geänderten SOFTWARE-KOMPONENTEN und die Werkzeuge enthält, die erforderlich sind, um die Änderungen als Änderungen eines bestehenden SOFTWARE-SYSTEMS zu installieren. [Klasse A, B, C] 7 *Software-RISIKOMANAGEMENT-PROZESS 7.1 *Analyse von Software, die zu Gefährdungssituationen beiträgt Identifikation von SOFTWARE-KOMPONENTEN, die zu einer Gefährdungssituation beitragen könnten Der HERSTELLER muss SOFTWARE-KOMPONENTEN identifizieren, die zu einer Gefährdungssituation beitragen könnten, wie in der RISIKOANALYSE-AKTIVITÄT für MEDIZINPRODUKTE von ISO (siehe 4.2) identifiziert. [Klasse B, C] ANMERKUNG Die Gefährdungssituation könnte das direkte Ergebnis eines Software-Ausfalls oder des Ausfalls einer RISIKOKONTROLL-Maßnahme, die in Software implementiert ist, sein. 28

31 7.1.2 Identifikation von möglichen Ursachen für den Beitrag zu einer Gefährdungssituation Der HERSTELLER muss mögliche Ursachen der SOFTWARE-KOMPONENTE identifizieren, die als zu einer Gefährdungssituation beitragend identifiziert wurden. Soweit angemessen, muss der HERSTELLER mögliche Ursachen betrachten, einschließlich der folgenden: a) fehlerhafte oder unvollständige Spezifikation der Funktionalität, b) Software-Defekte in der Funktionalität der identifizierten SOFTWARE-KOMPONENTE, c) Ausfall oder unerwartete Ergebnisse von einer SOUP, d) Hardware-Ausfälle oder andere Software-Defekte, die zu einer unvorhersagbaren Software-Funktionsweise führen könnten, und e) vernünftigerweise vorhersehbarer Missbrauch. [Klasse B, C] EVALUATION veröffentlichter Listen mit ANOMALIEN der SOUP Wenn ein Ausfall oder unerwartete Ergebnisse von einer SOUP eine mögliche Ursache dafür sind, dass die SOFTWARE-KOMPONENTE zu einer Gefährdungssituation beiträgt, muss der HERSTELLER zumindest jegliche veröffentlichten Listen mit ANOMALIEN für die VERSION der SOUP-Komponente EVALUIEREN, die im MEDIZINPRODUKT verwendet wird, um festzustellen, ob irgendeine der bekannten ANOMALIEN zu einer Folge von Ereignissen führt, die zu einer Gefährdungssituation führen könnten. [Klasse B, C] Dokumentation möglicher Ursachen Der HERSTELLER muss mögliche Ursachen der SOFTWARE-KOMPONENTE, die zu einer Gefährdungssituation beiträgt, in der RISIKOMANAGEMENT-AKTE dokumentieren (siehe ISO 14971). [Klasse B, C] Dokumentation von Folgen von Ereignissen Der HERSTELLER muss in der RISIKOMANAGEMENT-AKTE Folgen von Ereignissen dokumentieren, die zu einer Gefährdungssituation, wie in identifiziert, führen könnten. [Klasse B, C] 7.2 RISIKOKONTROLL-Maßnahmen Definition von RISIKOKONTROLL-Maßnahmen Für jede mögliche Ursache der SOFTWARE-KOMPONENTE, die, wie in der RISIKOMANAGEMENT-AKTE dokumentiert, zu einer Gefährdungssituation beiträgt, muss der HERSTELLER RISIKOKONTROLL-Maßnahmen definieren und dokumentieren. [Klasse B, C] ANMERKUNG Die RISIKOKONTROLL-Maßnahmen können in Hardware, in Software, in der Arbeitsumgebung oder in der Bedienungsanweisung implementiert werden RISIKOKONTROLL-Maßnahmen, die in Software implementiert werden Wenn eine RISIKOKONTROLL-Maßnahme als Teil der Funktionen einer SOFTWARE-KOMPONENTE implementiert ist, muss der HERSTELLER: a) die RISIKOKONTROLL-Maßnahme in die Software-Anforderungen aufnehmen; b) der SOFTWARE-KOMPONENTE eine Software-Sicherheitsklasse zuordnen, basierend auf den möglichen Auswirkungen der GEFÄHRDUNG, die durch die RISIKOKONTROLL-Maßnahme kontrolliert wird, und c) die SOFTWARE-KOMPONENTE in Übereinstimmung mit Abschnitt 5 entwickeln. [Klasse B, C] ANMERKUNG Diese Anforderung gibt zusätzliche Details zu ISO für Anforderungen zur RISIKOBEHERRSCHUNG. 29

32 7.3 VERIFIZIERUNG von RISIKOKONTROLL-Maßnahmen VERIFIZIERUNG von RISIKOKONTROLL-Maßnahmen Die Implementierung jeder RISIKOKONTROLL-Maßnahme, die in 7.2 dokumentiert wurde, muss VERIFIZIERT werden, und die VERIFIZIERUNG muss dokumentiert werden. [Klasse B, C] Dokumentation neuer Folgen von Ereignissen Wenn eine RISIKOKONTROLL-Maßnahme als SOFTWARE-KOMPONENTE implementiert wird, muss der HERSTELLER diese RISIKOKONTROLL-Maßnahme EVALUIEREN, um neue Folgen von Ereignissen, die zu einer Gefährdungssituation führen könnten, zu identifizieren und in der RISIKOMANAGEMENT-AKTE zu dokumentieren. [Klasse B, C] Dokumentation der RÜCKVERFOLGBARKEIT Soweit angemessen, muss der HERSTELLER die RÜCKVERFOLGBARKEIT von Software-GEFÄHRDUNGEN dokumentieren: a) von der Gefährdungssituation zur SOFTWARE-KOMPONENTE, b) von der SOFTWARE-KOMPONENTE zur spezifischen Software-Ursache, c) von der Software-Ursache zur RISIKOKONTROLL-Maßnahme und d) von der RISIKOKONTROLL-Maßnahme zur VERIFIZIERUNG der RISIKOKONTROLL-Maßnahme. [Klasse B, C] ANMERKUNG Siehe ISO RISIKOMANAGEMENT-Bericht. 7.4 RISIKOMANAGEMENT von Software-Änderungen Analyse von Änderungen an MEDIZINPRODUKTE-SOFTWARE in Hinblick auf die SICHERHEIT Der HERSTELLER muss Änderungen an der MEDIZINPRODUKTE-SOFTWARE (einschließlich SOUP) analysieren, um festzustellen, ob: a) zusätzliche mögliche Ursachen eingeführt wurden, die zu einer Gefährdungssituation beitragen, und b) zusätzliche Software-RISIKOKONTROLL-Maßnahmen erforderlich sind. [Klasse A, B, C] Analyse der Auswirkung von Software-Änderungen auf bestehende RISIKOKONTROLL- Maßnahmen Der HERSTELLER muss Änderungen an der Software, einschließlich Änderungen an der SOUP, analysieren, um festzustellen, ob die Software-Änderung bestehende RISIKOKONTROLL-Maßnahmen stören könnte. [Klasse B, C] Durchführung von RISIKOMANAGEMENT-AKTIVITÄTEN basierend auf Analysen Der HERSTELLER muss, basierend auf diesen Analysen, relevante RISIKOMANAGEMENT-AKTIVITÄTEN, wie in 7.1, 7.2 und 7.3 definiert, durchführen. [Klasse B, C] 30

33 8 *Software-Konfigurationsmanagement-PROZESS 8.1 *Identifizierung der Konfiguration Festlegung von Mitteln zur Identifizierung von KONFIGURATIONSELEMENTEN Der HERSTELLER muss ein Schema für die eindeutige Identifizierung von KONFIGURATIONSELEMENTEN und deren VERSIONEN festlegen, die für das Projekt überprüft werden sollen. Dieses Schema muss andere SOFTWARE-PRODUKTE oder -Einheiten enthalten, wie zum Beispiel SOUP und Dokumentation. [Klasse A, B, C] Identifizierung von SOUP Für jedes SOUP-KONFIGURATIONSELEMENT, das verwendet wird, einschließlich Standard-Bibliotheken, muss der HERSTELLER Folgendes dokumentieren: a) den Titel, b) den HERSTELLER und c) die eindeutige SOUP-Kennzeichnung. [Klasse A, B, C] ANMERKUNG Die eindeutige SOUP-Kennzeichnung könnte zum Beispiel eine VERSION, ein Freigabedatum, eine Programmkorrekturnummer oder eine Kennzeichnung einer Nachrüstung sein Identifizierung der Dokumentation der SYSTEM-Konfiguration Der HERSTELLER muss den Satz von KONFIGURATIONSELEMENTEN, aus denen die Konfiguration des SOFTWARE-SYSTEMS besteht, einschließlich ihrer VERSIONEN dokumentieren. [Klasse A, B, C] 8.2 *Änderungskontrolle Genehmigung von ÄNDERUNGSANFORDERUNGEN Der HERSTELLER darf KONFIGURATIONSELEMENTE nur als Reaktion auf eine genehmigte ÄNDERUNGS- ANFORDERUNG ändern. [Klasse A, B, C] ANMERKUNG 1 Die Entscheidung, eine ÄNDERUNGSANFORDERUNG zu genehmigen, kann Bestandteil des Änderungskontroll-PROZESSES oder eines anderen PROZESSES sein. Dieser Unterabschnitt fordert nur, dass die Genehmigung einer Änderung deren Implementierung vorangeht. ANMERKUNG 2 Unterschiedliche Akzeptanz-PROZESSE können für ÄNDERUNGSANFORDERUNGEN in unterschiedlichen Phasen des Lebenszyklus verwendet werden, wie in den Plänen angegeben. Siehe e) und 6.1e) Implementierung von Änderungen Der HERSTELLER muss die Änderung implementieren, wie in der ÄNDERUNGSANFORDERUNG festgelegt. Der HERSTELLER muss alle AKTIVITÄTEN identifizieren und durchführen, die als Ergebnis der Änderung wiederholt werden müssen, einschließlich von Änderungen der Software-Sicherheitsklassifizierung von SOFTWARE- SYSTEMEN und SOFTWARE-KOMPONENTEN. [Klasse A, B, C] ANMERKUNG Dieser Unterabschnitt gibt an, wie die Änderung implementiert werden sollte, damit eine angemessene Kontrolle über die Änderung erzielt wird. Dies bedeutet nicht, dass die Implementierung ein integraler Bestandteil des Änderungskontroll-PROZESSES ist. Die Implementierung sollte geplante PROZESSE verwenden. Siehe e) und 6.1e). 31

34 8.2.3 VERIFIZIERUNG von Änderungen Der HERSTELLER muss die Änderung VERIFIZIEREN, einschließlich der Wiederholung aller VERIFIZIERUNGEN, die durch die Änderung ungültig geworden sind, und unter Berücksichtigung der Unterabschnitte und 9.7. [Klasse A, B, C] ANMERKUNG Dieser Unterabschnitt fordert nur, dass Änderungen VERIFIZIERT werden. Dies bedeutet nicht, dass die VERIFIZIERUNG ein integraler Bestandteil des Änderungskontroll-PROZESSES ist. Die VERIFIZIERUNG sollte geplante PROZESSE verwenden. Siehe e) und 6.1e) Bereitstellung von Mitteln für die RÜCKVERFOLGBARKEIT von Änderungen Der HERSTELLER muss einen Audit-Pfad erstellen, wobei: a) jede ÄNDERUNGSANFORDERUNG, b) jeder relevante PROBLEMBERICHT und c) jede Genehmigung der ÄNDERUNGSANFORDERUNG zurückverfolgt werden kann. [Klasse A, B, C] 8.3 *Aufzeichnungen über den Status der Konfiguration Der HERSTELLER muss Aufzeichnungen über die Vorgeschichte von kontrollierten KONFIGURATIONSELEMENTEN einschließlich der SYSTEM-Konfiguration wieder auffindbar aufbewahren. [Klasse A, B, C] 9 *Problemlösungs-PROZESS für Software 9.1 Erstellen von PROBLEMBERICHTEN Der HERSTELLER muss für jedes Problem, das in einem SOFTWARE-PRODUKT entdeckt wurde, einen PROBLEMBERICHT erstellen. PROBLEMBERICHTE müssen wie folgt klassifiziert werden: a) Typ; Beispiel 1 b) Umfang und Korrektur, Vorbeugung oder Anpassung hinsichtlich einer neuen Umgebung Beispiel 2 Umfang der Änderung, Anzahl von betroffenen Geräte-Modellen, betroffenes unterstütztes Zubehör, beteiligte Ressourcen, Zeitbedarf für die Änderung c) Kritikalität. Beispiel 3 [Klasse A, B, C] Auswirkung auf Leistungsfähigkeit, SICHERHEIT oder DATENSICHERHEIT ANMERKUNG Probleme können vor oder nach der Freigabe, innerhalb oder außerhalb der Organisation des HERSTELLERS entdeckt werden. 9.2 Untersuchung des Problems Der HERSTELLER muss: a) das Problem untersuchen und, wenn möglich, die Ursachen identifizieren; b) unter Verwendung des Software-RISIKOMANAGEMENT-PROZESSES (Abschnitt 7) die Relevanz des Problems auf die SICHERHEIT EVALUIEREN; c) das Ergebnis der Untersuchung und EVALUATION dokumentieren und 32

35 d) eine ÄNDERUNGSANFORDERUNG erstellen für Aktionen, die erforderlich sind für die Korrektur des Problems, oder die Begründung dafür dokumentieren, dass keine Aktion erfolgt. [Klasse A, B, C] ANMERKUNG Die Einhaltung des Problemlösungs-PROZESSES durch den HERSTELLER verlangt nicht, dass ein Problem, das nicht SICHERHEITS-relevant ist, korrigiert werden muss. 9.3 Unterrichtung beteiligter Stellen Soweit angemessen, muss der HERSTELLER beteiligte Stellen über das Bestehen des Problems unterrichten. [Klasse A, B, C] ANMERKUNG Probleme können vor oder nach der Freigabe, innerhalb oder außerhalb der Organisation des HERSTELLERS entdeckt werden. Der HERSTELLER bestimmt die beteiligten Stellen abhängig von der Situation. 9.4 Anwendung des Änderungskontroll-PROZESSES Der HERSTELLER muss alle ÄNDERUNGSANFORDERUNGEN unter Beachtung der Anforderungen des Änderungskontroll-PROZESSES (siehe 8.2) genehmigen und implementieren. [Klasse A, B, C] 9.5 Aufbewahrung von Aufzeichnungen Der HERSTELLER muss Aufzeichnungen über PROBLEMBERICHTE und ihre Klärung einschließlich ihrer VERIFIZIERUNG aufbewahren. Soweit angemessen, muss der HERSTELLER die RISIKOMANAGEMENT-AKTE aktualisieren (siehe 7.4). [Klasse A, B, C] 9.6 Analyse von Problemen hinsichtlich Trends Der HERSTELLER muss eine Analyse durchführen, um bei PROBLEMBERICHTEN Trends zu entdecken. [Klasse A, B, C] 9.7 VERIFIZIERUNG der Lösung von Software-Problemen Der HERSTELLER muss die Lösungen VERIFIZIEREN, um festzustellen, ob: a) das Problem gelöst und der PROBLEMBERICHT geschlossen wurde, b) nachteilige Trends umgedreht wurden, c) ÄNDERUNGSANFORDERUNGEN in den entsprechenden SOFTWARE-PRODUKTEN und AKTIVITÄTEN implementiert wurden und d) zusätzliche Probleme verursacht wurden. [Klasse A, B, C] 9.8 Inhalt von Prüfungsdokumentation Bei Prüfung, Wiederholungsprüfung oder REGRESSIONSPRÜFUNG von SOFTWARE-KOMPONENTEN und SYSTEMEN in Folge einer Änderung muss der HERSTELLER Folgendes der Prüfungsdokumentation beifügen: a) Prüfungsergebnisse, b) gefundene ANOMALIEN, c) die VERSION der geprüften Software, d) relevante Hardware- und Software-Prüfungskonfigurationen, e) relevante Prüfwerkzeuge, 33

36 EN 62304:2006 f) Prüf-Datum und g) die Identität des Prüfers. [Klasse A, B, C] 34

37 Anhang A (informativ) Begründung für die Anforderungen dieser Norm Eine Begründung für die Abschnitte dieser Norm wird in diesem Anhang gegeben. A.1 Begründung Es ist die primäre Anforderung dieser Norm, dass bei der Entwicklung und Wartung von MEDIZINPRODUKTE- SOFTWARE ein Satz von PROZESSEN befolgt wird und dass die Wahl der PROZESSE den RISIKEN für Patienten und andere Personen angemessen ist. Dies folgt aus der Überzeugung, dass Prüfung von Software nicht ausreichend ist, um die sichere Funktionsweise festzustellen. Die von dieser Norm geforderten PROZESSE fallen in zwei Kategorien: PROZESSE, die gefordert werden, um die RISIKEN festzustellen, die von der Funktion jeder einzelnen SOFTWARE-KOMPONENTE in der Software herrühren; PROZESSE, die gefordert werden, um eine angemessen niedrige Ausfallwahrscheinlichkeit jeder SOFTWARE-KOMPONENTE zu erzielen; die PROZESSE werden auf der Basis der festgestellten RISIKEN ausgewählt. Diese Norm fordert, dass die erste Kategorie für jede MEDIZINPRODUKTE-SOFTWARE durchgeführt wird, die zweite Kategorie für ausgewählte SOFTWARE-KOMPONENTEN. Der Anspruch der Einhaltung dieser Norm soll deshalb eine dokumentierte RISIKOANALYSE enthalten, die vorhersehbare Folgen von Ereignissen identifiziert, die Software enthalten und zu einer gefährlichen Situation führen könnten. (Siehe ISO ) GEFÄHRDUNGEN, die indirekt von Software verursacht werden können (zum Beispiel irreführende Informationen, die zur Verabreichung einer unangebrachten Behandlung führen könnten), sollten in dieser RISIKOANALYSE enthalten sein. Alle AKTIVITÄTEN, die als Teil der ersten Kategorie von PROZESSEN gefordert werden, sind im normativen Text als [Klasse A, B, C] identifiziert; dies weist darauf hin, dass sie unabhängig von der Klassifizierung der Software, zu der sie gehören, gefordert werden. AKTIVITÄTEN werden mit der folgenden Begründung für alle Klassen A, B und C gefordert: Die AKTIVITÄT erzeugt einen Plan, der für das RISIKOMANAGEMENT oder für die Software-Sicherheitsklassifizierung relevant ist. Die AKTIVITÄT erzeugt ein Ergebnis, das eine Eingabe für das RISIKOMANAGEMENT oder für die Software- Sicherheitsklassifizierung ist. Die AKTIVITÄT ist ein Teil des RISIKOMANAGEMENTS oder der Software-Sicherheitsklassifizierung. Die AKTIVITÄT legt ein Verwaltungs-SYSTEM, eine Dokumentation oder ein Archivierungs-SYSTEM fest, dass das RISIKOMANAGEMENT oder die Software-Sicherheitsklassifizierung unterstützt. Die AKTIVITÄT findet normalerweise dann statt, wenn die Klassifizierung der entsprechenden Software unbekannt ist. Die AKTIVITÄT kann eine Änderung verursachen, die die gegenwärtige Software-Sicherheitsklassifizierung der betroffenen Software ungültig machen könnte. Dies schließt die Entdeckung und Analyse von sicherheitsrelevanten Problemen nach der Freigabe ein. Andere PROZESSE werden nur für SOFTWARE-SYSTEME oder SOFTWARE-KOMPONENTEN gefordert, die in die Software-Sicherheitsklassen B oder C eingestuft wurden. AKTIVITÄTEN, die als Teil dieser PROZESSE gefordert werden, sind im normativen Text als [Klasse B, C] oder [Klasse C] identifiziert; dies weist darauf hin, dass sie nur selektiv gefordert werden, abhängig von der Software-Klasse, zu der sie gehören. 35

38 AKTIVITÄTEN werden mit folgender Begründung selektiv für Software der Klassen B und C gefordert: Die AKTIVITÄT verbessert die Zuverlässigkeit der Software dadurch, dass mehr Details oder größere Strenge beim Design, bei der Prüfung oder bei einer anderen VERIFIZIERUNG gefordert werden. Die AKTIVITÄT ist eine verwaltende AKTIVITÄT, die eine andere für die Klassen B oder C geforderte AKTIVITÄT unterstützt. Die AKTIVITÄT unterstützt die Korrektur von sicherheitsrelevanten Problemen. Die AKTIVITÄT erstellt Aufzeichnungen über das Design, die Implementierung, die VERIFIZIERUNG und die Freigabe von sicherheitsrelevanter Software. AKTIVITÄTEN werden mit folgender Begründung selektiv für Software der Klasse C gefordert: Die AKTIVITÄT verbessert die Zuverlässigkeit der Software weiter dadurch, dass mehr Details, größere Strenge oder Aufmerksamkeit für spezielle Fragen beim Design, bei der Prüfung oder bei einer anderen VERIFIZIERUNG gefordert werden. Es ist zu beachten, dass alle PROZESSE und AKTIVITÄTEN, die in dieser Norm definiert werden, als hilfreich betrachtet werden, weil sie die Entwicklung und Wartung von Software hoher Qualität sicherstellen. Das Weglassen vieler dieser PROZESSE und AKTIVITÄTEN als Anforderungen für Software der Klasse A, die entsprechend Definition keine GEFÄHRDUNG verursachen kann, soll nicht bedeuten, dass diese PROZESSE und AKTIVITÄTEN nicht von Wert wären oder nicht empfohlen würden. Ihr Weglassen soll anerkennen, dass die SICHERHEIT und Wirksamkeit von Software, die keine GEFÄHRDUNG verursachen kann, leicht sichergestellt werden kann durch eine Gesamt-Validierungs-AKTIVITÄT während des Designs des MEDIZINPRODUKTS (was außerhalb des Anwendungsbereichs dieser Norm liegt) und durch einfache Software-Lebenszyklus- Kontrollen. 36

39 A.2 Zusammenfassung der Anforderungen nach Klassen Tabelle A.1 fasst zusammen, welche Software-Sicherheitsklassen zur jeweiligen Anforderung zugeordnet sind. Diese Tabelle ist informativ und wird nur aus Gründen der Zweckmäßigkeit zur Verfügung gestellt. Der normative Abschnitt identifiziert die Software-Sicherheitsklassen für die jeweilige Anforderung. Tabelle A.1 Zusammenfassung der Anforderungen nach Software-Sicherheitsklassen Abschnitte und Unterabschnitte Klasse A Klasse Abschnitt 4 Alle Anforderungen X X X , 5.1.2, 5.1.3, 5.1.6, 5.1.7, 5.1.8, X X X 5.1.5, , X X B Klasse C X , 5.2.2, 5.2.4, 5.2.5, X X X X X , 5.3.2, 5.3.3, 5.3.4, X X X X X 5.4.2, 5.4.3, X X X X 5.5.2, 5.5.3, X X X 5.6 Alle Anforderungen X X 5.7 Alle Anforderungen X X X X X 5.8.1, 5.8.2, 5.8.3, 5.8.5, 5.8.6, 5.8.7, X X X X X , 6.2.2, 6.2.4, X X X X X 6.3 Alle Anforderungen X X X 7.1 Alle Anforderungen X X 7.2 Alle Anforderungen X X 7.3 Alle Anforderungen X X X X X 7.4.2, X X Abschnitt 8 Alle Anforderungen X X X Abschnitt 9 Alle Anforderungen X X X 37

40 Anhang B (informativ) Anleitung für die Bestimmungen dieser Norm B.1 Anwendungsbereich B.1.1 Zweck Der Zweck dieser Norm ist es, einen Entwicklungs-PROZESS zur Verfügung zu stellen, der gleich bleibend sichere MEDIZINPRODUKTE-SOFTWARE hoher Qualität erzeugt. Um dies zu erreichen identifiziert diese Norm die minimalen AKTIVITÄTEN und AUFGABEN, die erledigt werden müssen, um das Vertrauen zu geben, dass die Software in einer Weise entwickelt wurde, die wahrscheinlich sehr zuverlässige und sichere SOFTWARE- PRODUKTE erzeugt. Dieser Anhang gibt Anleitung für die Anwendung der Anforderungen dieser Norm. Er fügt nichts zu den Anforderungen dieser Norm hinzu, noch ändert er sie anderweitig. Dieser Anhang kann dazu verwendet werden, um die Anforderungen dieser Norm besser zu verstehen. Man beachte, dass in dieser Norm AKTIVITÄTEN Unterabschnitte sind, die innerhalb eines PROZESSES aufgerufen werden, und dass AUFGABEN innerhalb der AKTIVITÄTEN definiert werden. Z. B. sind die AKTIVI- TÄTEN, die für den Software-Entwicklungs-PROZESS definiert sind, Software-Entwicklungsplanung, Analyse der Software-Anforderungen, Entwicklung der Software-ARCHITEKTUR, detailliertes Design der Software, Implementierung und VERIFIZIERUNG der SOFTWARE-EINHEIT, Software-Integration und Integrationsprüfung, SOFTWARE-SYSTEM-Prüfung und Software-Freigabe. Die AUFGABEN innerhalb dieser AKTIVITÄTEN sind die individuellen Anforderungen. Diese Norm fordert nicht ein bestimmtes LEBENSZYKLUS-MODELL DER SOFTWAREENTWICKLUNG. Die Einhaltung dieser Norm impliziert jedoch Abhängigkeiten zwischen PROZESSEN, weil Eingaben für einen PROZESS von einem anderen PROZESS erzeugt werden. Z. B. sollte die Software-Sicherheits-Klassifizierung des SOFTWARE- SYSTEMS abgeschlossen sein, nachdem der RISIKOANALYSE-PROZESS festgelegt hat, welche SCHÄDIGUNG von einem Ausfall des SOFTWARE-SYSTEMS herrühren könnte. Wegen solcher logischen Abhängigkeiten zwischen PROZESSEN ist es am einfachsten, die PROZESSE in dieser Norm in einer Reihenfolge zu beschreiben, was einen Wasserfall oder ein Einmal-durch -Lebenszyklus- Modell impliziert. Es können jedoch auch andere Lebenszyklen verwendet werden. Einige Entwicklungs- (Modell-)Strategien, wie in ISO/IEC [9] definiert, sind unter anderem (siehe Tabelle B.1): Wasserfall: Die Einmal-durch -Strategie, auch bekannt unter dem Namen Wasserfall, besteht darin, dass der Entwicklungs-PROZESS ein einziges Mal durchlaufen wird. Vereinfacht: Bestimmung der Anwender-Bedürfnisse, Definition der Anforderungen, Design des SYSTEMS, Implementierung des SYSTEMS, Prüfung, Korrektur und Auslieferung. Inkrementell: Die inkrementelle Strategie bestimmt die Anwender-Bedürfnisse und definiert die SYSTEM- Anforderungen, dann wird der Rest der Entwicklung in einer Folge von builds (Aufbauten) durchgeführt. Der erste Aufbau fügt einen Teil des geplanten Leistungsumfangs ein, der nächste Aufbau fügt mehr Funktionalität hinzu, und so weiter, bis das SYSTEM vollständig ist. Evolutionär: Die evolutionäre Strategie entwickelt das SYSTEM ebenfalls in builds (Aufbauten), unterscheidet sich aber von der inkrementellen Strategie dadurch, dass anerkannt wird, dass ganz am Anfang die Anwender-Bedürfnisse noch nicht vollständig verstanden sind und noch nicht alle Anforderungen vollständig definiert werden können. Bei dieser Strategie werden Anwender-Bedürfnisse und SYSTEM-Anforderungen zu Beginn teilweise definiert und dann bei jedem folgenden Aufbau verfeinert. 38

41 Tabelle B.1 Entwicklungs-(Modell-)Strategien wie in ISO/IEC definiert Entwicklungs-Strategie Sind alle Anforderungen zu Beginn definiert? Mehrfache Entwicklungs- Zyklen? Wird die vorläufige Software verteilt? Wasserfall (Einmal durch) Inkrementell (Vorgeplante Produkt-Verbesserung) ja nein nein ja ja vielleicht Evolutionär nein ja ja Welcher Lebenszyklus auch immer gewählt wird, so ist es notwendig, die logischen Abhängigkeiten zwischen PROZESS-Ergebnissen beizubehalten, wie zum Beispiel Spezifikationen, Design-Dokumente und Software. Das Wasserfall-Lebenszyklus-Modell erreicht dies dadurch, dass der Beginn eines PROZESSES verzögert wird, bis die Eingaben für diesen PROZESS vollständig und genehmigt sind. Andere Lebenszyklen, insbesondere evolutionäre Lebenszyklen, erlauben es, dass PROZESS-Ergebnisse erzeugt werden, bevor alle Eingaben für diesen PROZESS verfügbar sind. Zum Beispiel kann eine neue SOFTWARE-KOMPONENTE spezifiziert, klassifiziert, implementiert und VERIFIZIERT werden, bevor die ganze Software-ARCHITEKTUR abgeschlossen wurde. Solche Lebenszyklen haben das RISIKO, dass eine Änderung oder Entwicklung eines PROZESS-Ergebnisses ein anderes PROZESS-Ergebnis ungültig machen kann. Alle Lebenszyklen verwenden deshalb ein umfangreiches Konfigurations-Management-SYSTEM um sicherzustellen, dass alle PROZESS-Ergebnisse auf einen konsistenten Zustand gebracht und die Abhängigkeiten beibehalten werden. Die folgenden Prinzipien sind wichtig, unabhängig davon, welcher Software-Lebenszyklus verwendet wird: Alle PROZESS-Ergebnisse sollten auf einem konsistenten Zustand gehalten werden. Wenn irgendein PROZESS-Ergebnis erzeugt oder geändert wird, sollten alle damit zusammenhängenden PROZESS- Ergebnisse sofort aktualisiert werden, um die Konsistenz untereinander und alle Abhängigkeiten, die explizit oder implizit von dieser Norm gefordert werden, aufrechtzuerhalten. Alle PROZESS-Ergebnisse sollten verfügbar sein, wenn sie als Eingabe für weitere Arbeiten an der Software benötigt werden. Bevor eine MEDIZINPRODUKTE-SOFTWARE freigegeben wird, sollten alle PROZESS-Ergebnisse untereinander konsistent sein, und alle Abhängigkeiten zwischen PROZESS-Ergebnissen, die explizit oder implizit von dieser Norm gefordert werden, sollten beachtet werden. B.1.2 Anwendungsbereich Diese Norm gilt für die Entwicklung und Wartung von MEDIZINPRODUKTE-SOFTWARE und für die Entwicklung und Wartung von einem MEDIZINPRODUKT, das eine SOUP enthält. Die Anwendung dieser Norm fordert, dass der HERSTELLER ein RISIKOMANAGEMENT für das MEDIZINPRODUKT durchführt, das ISO einhält. Wenn deshalb die SYSTEM-ARCHITEKTUR des MEDIZINPRODUKTS eine erworbene Komponente enthält (dies könnte eine gekaufte Komponente oder eine Komponente unbekannter Herkunft sein), wie zum Beispiel ein Drucker/Plotter, der eine SOUP enthält, dann fällt die erworbene Komponente in die Verantwortung des HERSTELLERS und muss in das RISIKOMANAGEMENT des MEDIZINPRODUKTS eingeschlossen werden. Es wird angenommen, dass durch geeignete Leistungsfähigkeit des RISIKOMANAGEMENTS für das MEDIZINPRODUKT der HERSTELLER die Komponente verstehen und erkennen wird, dass sie eine SOUP enthält. Der HERSTELLER, der diese Norm verwendet, würde den Software- RISIKOMANAGEMENT-PROZESS als Teil des RISIKOMANAGEMENT-PROZESSES für MEDIZINPRODUKTE aufrufen. Die Wartung von freigegebener MEDIZINPRODUKTE-SOFTWARE bezieht sich auf die Erfahrung mit der MEDIZINPRODUKTE-SOFTWARE in den der Produktion nachgelagerten Phasen. Die Software-Wartung beinhaltet die Kombination aller technischen und administrativen Mittel einschließlich Aktionen der Überwachung, um an PROBLEMBERICHTEN zu arbeiten, damit eine Komponente in einem Zustand gehalten oder ein Zustand wieder hergestellt wird, in dem die Komponente eine geforderte Funktion sowie ÄNDERUNGSANFORDERUNGEN, die sich auf ein freigegebenes SOFTWARE-PRODUKT beziehen, ausführen kann. Dies schließt zum Beispiel die 39

42 Problembereinigung, regulatorische Berichte, die erneute Validierung sowie Vorsorgemaßnahmen ein. Siehe ISO/IEC [10]. B.2 Normative Verweisungen ISO/IEC [11] gibt Anleitung für die Anwendung eines Qualitätsmanagement-SYSTEMS für die Software- Entwicklung. Diese Anleitung wird von dieser Norm nicht gefordert, wird aber nachhaltig empfohlen. B.3 Begriffe und Definitionen Soweit möglich, wurden Begriffe definiert unter Verwendung von Definitionen aus Internationalen Normen. Für diese Norm wurde entschieden, drei Begriffe zu verwenden, um die Zerlegung eines SOFTWARE-SYSTEMS zu beschreiben (oberste Ebene). Das SOFTWARE-SYSTEM kann ein Unter-SYSTEM des MEDIZINPRODUKTS sein (siehe IEC [2]) oder ein eigenständiges MEDIZINPRODUKT. Die unterste Ebene, die nicht weiter zerlegt wird für die Zwecke der Prüfung des Software-Konfigurationsmanagements, ist die SOFTWARE- EINHEIT. Alle Ebenen der Zusammenstellung, einschließlich der obersten und untersten Ebene, können als SOFTWARE-KOMPONENTEN bezeichnet werden. Ein SOFTWARE-SYSTEM besteht demnach aus einer oder mehreren SOFTWARE-KOMPONENTEN, und jede SOFTWARE-KOMPONENTE besteht aus einer oder mehreren SOFTWARE-EINHEITEN oder zerlegbaren SOFTWARE-KOMPONENTEN. Es ist die Verantwortung des HERSTELLERS, die Definition und die Granularität der SOFTWARE-KOMPONENTEN und der SOFTWARE-EINHEITEN festzulegen. Wenn man diese Begriffe vage lässt, so kann man sie auf die vielen unterschiedlichen Entwicklungsmethoden und Typen von Software, die in MEDIZINPRODUKTEN verwendet werden, anwenden. B.4 Allgemeine Anforderungen Es gibt keine bekannte Methode, um für irgendeine Art von Software eine hundertprozentige SICHERHEIT zu garantieren. Es gibt drei wesentliche Prinzipien, die die SICHERHEIT für MEDIZINPRODUKTE-SOFTWARE fördern: RISIKOMANAGEMENT; Qualitätsmanagement; Software-Engineering. Für die Entwicklung und Wartung von sicherer MEDIZINPRODUKTE-SOFTWARE ist es notwendig, RISIKOMANAGEMENT als einen integralen Bestandteil eines Qualitätsmanagement-SYSTEMS festzulegen als ein gesamtes Rahmenwerk für die Anwendung von angemessenen Methoden der Software-Entwicklung und Software-Techniken. Die Kombination von diesen drei Konzepten ermöglicht es einem HERSTELLER von MEDIZINPRODUKTEN, einem klar strukturierten und immer wiederholbaren Entscheidungs-PROZESS zu folgen, um die SICHERHEIT für die MEDIZINPRODUKTE-SOFTWARE zu fördern. B.4.1 Qualitätsmanagement-System Ein disziplinierter und wirksamer Satz von Software-PROZESSEN schließt organisatorische PROZESSE ein, wie zum Beispiel Management, Infrastruktur, Verbesserung und Training. Um Duplizierungen zu vermeiden und um diese Norm auf Software-Techniken zu fokussieren, wurden diese PROZESSE aus dieser Norm weggelassen. Diese PROZESSE werden durch ein Qualitätsmanagement-SYSTEM abgedeckt. ISO [7] ist eine Internationale Norm, die speziell dafür gedacht ist, die Konzepte des Qualitätsmanagements auf MEDIZINPRODUKTE anzuwenden. Einhaltung von Anforderungen des ISO Qualitätsmanagement- SYSTEMS bedeutet nicht automatisch die Einhaltung von nationalen oder regionalen regulatorischen Anforderungen. Es ist die Verantwortung des HERSTELLERS, die Einhaltung relevanter regulatorischer Anforderungen zu identifizieren und festzulegen. B.4.2 Risikomanagement Die Software-Entwicklung nimmt an AKTIVITÄTEN des RISIKOMANAGEMENTS in ausreichendem Umfang teil, um sicherzustellen, dass alle vernünftigerweise vorhersehbaren RISIKEN im Zusammenhang mit der MEDIZINPRODUKTE-SOFTWARE bedacht werden. 40

43 Anstatt zu versuchen, einen angemessenen RISIKOMANAGEMENT-PROZESS in dieser Software-Entwicklungs- Norm zu definieren, wird gefordert, dass der HERSTELLER einen RISIKOMANAGEMENT-PROZESS anwendet, der ISO einhält, die sich explizit mit dem RISIKOMANAGEMENT für MEDIZINPRODUKTE beschäftigt. Spezielle AKTIVITÄTEN des Software-RISIKOMANAGEMENTS, die von GEFÄHRDUNGEN herrühren, die Software als eine beitragende Ursache haben, werden in einem unterstützenden PROZESS identifiziert, der in Abschnitt 7 beschrieben ist. B.4.3 Software-Sicherheitsklassifizierung Das RISIKO im Zusammenhang mit Software als Teil eines MEDIZINPRODUKTS, als Zubehör zu einem MEDIZINPRODUKT oder als eigenständiges MEDIZINPRODUKT wird als Eingabe für ein Software-Klassifizierungs- Schema verwendet, was dann die PROZESSE bestimmt, die während der Entwicklung und Wartung von Software verwendet werden müssen. RISIKO wird als eine Kombination des Schweregrads einer Verletzung und der Wahrscheinlichkeit ihres Auftretens betrachtet. Es gibt jedoch keine Übereinstimmung, wie die Wahrscheinlichkeit des Auftretens von Software-Ausfällen unter Verwendung von traditionellen statistischen Methoden bestimmt werden kann. In dieser Norm wird deshalb die Klassifizierung eines SOFTWARE-SYSTEMS basiert auf dem Schweregrad der GEFÄHRDUNG, die vom Ausfall der Software herrührt, unter der Annahme, dass der Ausfall stattfinden wird. SOFTWARE-SYSTEME, die zur Implementierung von RISIKOKONTROLL-Maßnahmen beitragen, werden klassifiziert auf der Basis des Schweregrads der GEFÄHRDUNG, die sie kontrollieren. Wenn ein SOFTWARE-SYSTEM in SOFTWARE-KOMPONENTEN zerlegt wird, kann jede einzelne SOFTWARE- KOMPONENTE ihre eigene Software-Sicherheitsklasse besitzen. Es ist nur dann möglich, das RISIKO im Zusammenhang mit dem Ausfall einer SOFTWARE-KOMPONENTE zu bestimmen: wenn eine SYSTEM-ARCHITEKTUR und eine Software-ARCHITEKTUR die Rolle der SOFTWARE-KOMPONENTE definieren, entsprechend ihrer Zweckbestimmung und ihren Schnittstellen mit anderen SOFTWARE- und Hardware-KOMPONENTEN; wenn Änderungen am SYSTEM kontrolliert werden; nachdem eine RISIKOANALYSE bezüglich der ARCHITEKTUR durchgeführt wurde und RISIKOKONTROLL- Maßnahmen spezifiziert wurden. Diese Norm fordert die minimale Anzahl von AKTIVITÄTEN, die die oben genannten Bedingungen für alle Klassen von Software erzielen. Das Ende der AKTIVITÄT der Software-ARCHITEKTUR ist der früheste Zeitpunkt in der Entwicklung, zu dem der volle Satz von SOFTWARE-KOMPONENTEN definiert ist und zu dem die RISIKOMANAGEMENT-AKTIVITÄT identifiziert hat, wie die SOFTWARE-KOMPONENTEN die SICHERHEIT beeinflussen. Dies ist deshalb der früheste Zeitpunkt, zu dem SOFTWARE-KOMPONENTEN entsprechend ihrer SICHERHEITS-Rolle endgültig klassifiziert werden können. Dieser Punkt korrespondiert mit dem Punkt, bei dem in ISO die RISIKO-KONTROLLE beginnt. Vor diesem Zeitpunkt identifiziert der RISIKOMANAGEMENT-PROZESS RISIKOKONTROLL-Maßnahmen für die ARCHITEKTUR, zum Beispiel durch Hinzufügen von Schutz-Sub-SYSTEMEN oder durch Verringern der Möglichkeiten, dass Software-Ausfälle einen SCHADEN verursachen. Nach diesem Zeitpunkt verwendet der RISIKOMANAGEMENT-PROZESS PROZESSE, die darauf abzielen, die Wahrscheinlichkeit des Ausfalls von SOFTWARE-KOMPONENTEN zu verringern. In anderen Worten spezifiziert die Klassifizierung einer SOFTWARE- KOMPONENTE diejenigen PROZESS-basierten RISIKOKONTROLL-Maßnahmen, die auf diese Komponente angewandt werden sollen. Es ist zu erwarten, dass HERSTELLER es nützlich finden, Software vor diesem Zeitpunkt zu klassifizieren, um zum Beispiel die Aufmerksamkeit auf Gebiete zu fokussieren, die untersucht werden sollen. Aber diese Klassifizierung sollte als vorläufig betrachtet werden und sollte nicht als Rechtfertigung für das Weglassen von PROZESSEN dienen. 41

44 Das Software-Klassifizierungsschema soll sich nicht an den RISIKO-Klassifizierungen der ISO ausrichten. Während das Schema der ISO die RISIKEN entsprechend ihrem Schweregrad und ihrer Wahrscheinlichkeit klassifiziert, klassifiziert die Software-Sicherheitsklassifizierung SOFTWARE-SYSTEME und SOFTWARE-KOMPONENTEN nach den PROZESSEN, die bei ihrer Entwicklung und Wartung angewandt werden sollen. Mit fortschreitendem Design könnten neue RISIKEN erkennbar werden. Deshalb sollte das RISIKOMANAGEMENT als integraler Bestandteil des Entwicklungs-PROZESSES angewandt werden. Dies ermöglicht die Entwicklung eines ARCHITEKTUR-Designs, das einen vollständigen Satz von SOFTWARE-KOMPONENTEN identifiziert, einschließlich solcher, von denen eine korrekte Funktion gefordert wird, um einen sicheren Betrieb zu gewährleisten, und solcher, die verhindern, dass Fehlfunktionen einen SCHADEN verursachen. Die ARCHITEKTUR sollte die Aufteilung von SOFTWARE-KOMPONENTEN fördern, die für den sicheren Betrieb erforderlich sind, und sollte die Methoden beschreiben, die verwendet werden, um eine wirksame Aufteilung dieser SOFTWARE-KOMPONENTEN zu gewährleisten. Wie in Abschnitt B.3 festgestellt, wurde für diese Norm beschlossen, drei Begriffe zu verwenden, um die Zerlegung eines SOFTWARE-SYSTEMS (oberste Ebene) zu beschreiben. Bild B.1 illustriert die mögliche Aufteilung von SOFTWARE-KOMPONENTEN innerhalb eines SOFTWARE-SYSTEMS und wie die Software-Sicherheitsklassen auf die Gruppe von SOFTWARE-KOMPONENTEN bei der Zerlegung angewandt würden. Bild B.1 Beispiel einer Aufteilung von SOFTWARE-KOMPONENTEN In diesem Beispiel weiß der HERSTELLER wegen der Art der MEDIZINPRODUKTE-SOFTWARE, die entwickelt wird, dass die vorläufige Software-Sicherheitsklassifizierung für das SOFTWARE-SYSTEM die Software- Sicherheitsklasse C ist. Während des Designs der Software-ARCHITEKTUR hat der HERSTELLER entschieden, das SYSTEM, wie gezeigt, in drei SOFTWARE-KOMPONENTEN aufzuteilen X, W und Z. Der HERSTELLER ist in der Lage, alle Elemente des SOFTWARE-SYSTEMS, die zu GEFÄHRDUNGEN beitragen, die zum Tod oder zu 42

45 einer SCHWEREN VERLETZUNG führen könnten, in die SOFTWARE-KOMPONENTE Z einzuordnen und alle übrigen Elemente des SOFTWARE-SYSTEMS, die zu GEFÄHRDUNGEN beitragen, die nur zu einer leichten Verletzung führen könnten, in die SOFTWARE-KOMPONENTE W einzuordnen. Die SOFTWARE-KOMPONENTE W ist als Software-Sicherheitsklasse B eingestuft, die SOFTWARE-KOMPONENTE Z ist in der Software-Sicherheitsklasse C. Die SOFTWARE-KOMPONENTE Y muss nach 4.3 d) als Klasse C eingestuft werden. Nach dieser Anforderung ist das SOFTWARE-SYSTEM ebenfalls in der Software-Sicherheitsklasse C. Die SOFTWARE- KOMPONENTE X wurde in die Software-Sicherheitsklasse A eingestuft. Der HERSTELLER ist in der Lage, eine Begründung für die Trennung zwischen SOFTWARE-KOMPONENTE X und Y sowie zwischen den SOFTWARE- KOMPONENTEN W und Z zu dokumentieren, um die Integrität der Trennung zu gewährleisten. Wenn eine Aufteilung nicht möglich ist, müssen die SOFTWARE-KOMPONENTEN X und Y als Software-Sicherheitsklasse C eingestuft werden. B.5 Software-Entwicklungs-PROZESS B.5.1 Planung der Software-Entwicklung Es ist die Zielsetzung dieser AKTIVITÄT, die AUFGABEN der Software-Entwicklung zu planen, um die durch Software verursachten RISIKEN zu verringern, um Verfahren und Ziele an die Mitglieder des Entwicklungsteams zu kommunizieren und um sicherzustellen, dass die Anforderungen der SYSTEM-Qualität für die MEDIZINPRODUKTE-SOFTWARE eingehalten werden. Die AKTIVITÄT der Software-Entwicklungsplanung kann AUFGABEN in einem einzelnen Plan oder in mehreren Plänen dokumentieren. Einige HERSTELLER könnten Richtlinien und Verfahren festgelegt haben, die für die Entwicklung ihrer ganzen MEDIZINPRODUKTE-SOFTWARE gelten. In diesem Fall kann der Plan einfach die bestehenden Richtlinien und Verfahren referenzieren. Einige HERSTELLER könnten einen Plan oder ein Satz von Plänen erarbeiten, die speziell für die Entwicklung von jedem einzelnen MEDIZINPRODUKTE-SOFTWARE- PRODUKT gelten und die im Detail spezifische AKTIVITÄTEN benennen und allgemeine Verfahren referenzieren. Eine andere Möglichkeit besteht darin, einen Plan oder einen Satz von Plänen für die Entwicklung von jedem MEDIZINPRODUKTE-SOFTWARE-PRODUKT maßzuschneidern. Die Planung sollte spezifiziert sein auf dem Detail- Niveau, das erforderlich ist, um den Entwicklungs-PROZESS auszuführen, und dieses Detail-Niveau sollte proportional zum RISIKO sein. Z. B. sollten SYSTEME oder Komponenten mit höherem RISIKO Gegenstand eines Entwicklungs-PROZESSES mit mehr Strenge sein und die AUFGABEN sollten im größeren Detail ausgeführt sein. Planung ist eine iterative AKTIVITÄT, die mit fortschreitender Entwicklung immer wieder überprüft und aktualisiert werden sollte. Der Plan kann sich entwickeln, um mehr und bessere Informationen zu enthalten, sobald mehr Verständnis herrscht über das SYSTEM und den Aufwand, der betrieben werden muss, um das SYSTEM zu entwickeln. Z. B. kann eine ursprüngliche Software-Sicherheitsklassifizierung eines SYSTEMS sich ändern als Ergebnis der Ausführung des RISIKOMANAGEMENT-PROZESSES und der Entwicklung der Software- ARCHITEKTUR. Oder die Entscheidung könnte getroffen worden seien, dass ein SOUP in das SYSTEM integriert werden soll. Es ist wichtig, dass der Plan/die Pläne aktualisiert wird/werden, um die momentane Kenntnis über das SYSTEM und das Maß an Strenge zu reflektieren, das für das SYSTEM oder die Komponenten im SYSTEM notwendig ist, um eine geeignete Kontrolle über den Entwicklungs-PROZESS zu ermöglichen. B.5.2 Analyse der Software-Anforderungen Diese AKTIVITÄT fordert, dass der HERSTELLER die Software-Anforderungen für die MEDIZINPRODUKTE- SOFTWARE festlegt und VERIFIZIERT. Das Festlegen von verifizierbaren Anforderungen ist wichtig um zu bestimmen, was gebaut werden soll, um zu bestimmen, dass die MEDIZINPRODUKTE-SOFTWARE ein vertretbares Verhalten zeigt, und um zu zeigen, dass die vollständige MEDIZINPRODUKTE-SOFTWARE fertig für den Gebrauch ist. Um zu zeigen, dass die Anforderungen wie gewünscht implementiert wurden, sollte jede Anforderung so formuliert werden, dass objektive Kriterien festgelegt werden können, um festzustellen, ob sie korrekt implementiert wurde. Wenn der RISIKOMANAGEMENT-PROZESS des Geräts Anforderungen an die Software stellt, um identifizierte RISIKEN zu kontrollieren, so müssen diese Anforderungen in den Software- Anforderungen so identifiziert werden, dass es möglich wird, die RISIKOKONTROLL-Maßnahmen auf die Software-Anforderungen zurückzuverfolgen. Alle Software-Anforderungen sollten so identifiziert werden, dass es möglich wird, die RÜCKVERFOLGBARKEIT zwischen den Anforderungen und der SOFTWARE-SYSTEM-Prüfung zu zeigen. Wenn die regulatorische Genehmigung in einigen Ländern die Einhaltung spezieller Vorschriften oder Internationaler Normen fordert, sollten diese Anforderungen der Einhaltung in den Software- Anforderungen dokumentiert werden. Weil die Software-Anforderungen festlegen, was in der Software 43

46 implementiert werden soll, muss eine Bewertung der Anforderungen erfolgen, bevor die AKTIVITÄT der Analyse der Anforderungen vollständig ist. Ein Bereich häufiger Verwirrung ist die Unterscheidung zwischen Kunden-Bedürfnissen, Design-Eingabe, Software-Anforderungen, funktionalen Software-Spezifikationen und Software-Design-Spezifikationen. Design-Eingaben sind die Übersetzung von Kunden-Bedürfnissen in formal dokumentierte MEDIZINPRODUKTE- Anforderungen. Software-Anforderungen sind die formal dokumentierten Spezifikationen dessen, was die Software tut, um die Kunden-Bedürfnisse und die Design-Eingaben zu erfüllen. Funktionale Software-Spezifikationen sind oft in den Software-Anforderungen enthalten und definieren im Detail, was die Software tut, um diese Anforderungen zu erfüllen, wenn auch viele andere Alternativen diese Anforderungen ebenfalls erfüllen könnten. Software-Design-Spezifikationen definieren, wie die Software entwickelt und zerlegt wird, um die Anforderungen und funktionalen Spezifikationen zu implementieren. Traditionell wurden Software-Anforderungen, funktionale Spezifikationen und Design-Spezifikationen als ein Satz eines oder mehrerer Dokumente geschrieben. Es ist nun möglich, sich diese Informationen als Daten- Komponenten innerhalb einer gemeinsamen Datenbank vorzustellen. Jede Komponente hätte ein oder mehrere Attribute, die ihren Zweck und ihre Verbindung mit anderen Komponenten in der Datenbank definieren würde. Dieser Ansatz erlaubt die Darstellung und den Druck von unterschiedlichen Ansichten der Information, die am besten für jede Gruppe von beabsichtigten Anwendern geeignet ist (z. B. Marketing, HERSTELLER, Prüfer, Auditoren), und unterstützt die RÜCKVERFOLGBARKEIT, um die angemessene Implementierung zu zeigen und das Ausmaß, in denen Prüffälle die Anforderungen prüfen. Werkzeuge zur Unterstützung dieses Ansatzes können einfach sein, wie ein Hypertext-Dokument, das HTML-Hyperlinks verwendet, oder umfangreich und leistungsfähig, wie Computer-unterstützte Software-Entwicklungswerkzeuge (CASE) und Werkzeuge zur Analyse von Anforderungen. Der PROZESS der SYSTEM-Anforderungen liegt außerhalb des Anwendungsbereichs dieser Norm. Die Entscheidung, Funktionalität des MEDIZINPRODUKTS mit Software zu implementieren, wird jedoch üblicherweise beim SYSTEM-Design gemacht. Einige oder alle SYSTEM-Anforderungen werden der Implementierung in Software zugeordnet. Die AKTIVITÄT der Analyse von Software-Anforderungen besteht aus der Analyse der Anforderungen, die der Software durch den PROZESS der SYSTEM-Anforderungen zugeordnet wurden, und der Ableitung eines umfangreichen Satzes von Software-Anforderungen, die die zugeordneten Anforderungen reflektieren. Um die Integrität des SYSTEMS zu gewährleisten, sollte der HERSTELLER einen Mechanismus zur Verfügung haben, um Änderungen und Klarstellungen an den SYSTEM-Anforderungen zu verhandeln, um Untauglichkeit, Unvereinbarkeit oder Mehrdeutigkeit in den darüber liegenden SYSTEM- oder Software-Anforderungen zu korrigieren. Der PROZESS der Erfassung und Analyse von Anforderungen des SYSTEMS und der Software kann iterativ sein. Diese Norm will nicht fordern, dass diese PROZESSE streng in zwei Ebenen unterteilt werden. In der Praxis werden SYSTEM-ARCHITEKTUR und Software-ARCHITEKTUR oft gemeinsam entworfen und die Anforderungen des SYSTEMS und der Software werden dann in einem Schichtenmodell dokumentiert. B.5.3 Design der Software-ARCHITEKTUR Diese AKTIVITÄT fordert vom HERSTELLER die Definition der wesentlichen strukturellen Komponenten der Software, ihrer von außen sichtbaren Eigenschaften und der Beziehung zwischen ihnen. Wenn das Verhalten einer Komponente andere Komponenten beeinflussen kann, sollte dieses Verhalten in der ARCHITEKTUR beschrieben werden. Diese Beschreibung ist speziell wichtig für Verhaltensweisen, die Komponenten des MEDIZINPRODUKTS, die außerhalb der Software liegen, beeinflussen können. Entscheidungen hinsichtlich der ARCHITEKTUR sind extrem wichtig für die Implementierung von RISIKOKONTROLL-Maßnahmen. Ohne das Verhalten einer Komponente, die andere Komponenten beeinflussen kann, zu verstehen (und zu dokumentieren), wird es nahezu unmöglich sein zu zeigen, dass das SYSTEM sicher ist. Eine Software-ARCHITEKTUR ist notwendig, um die korrekte Implementierung der Software-Anforderungen zu gewährleisten. Eine Software- ARCHITEKTUR ist erst dann vollständig, wenn alle Software-Anforderungen durch die identifizierten SOFTWARE- KOMPONENTEN implementiert werden können. Weil das Design und die Implementierung der Software von der ARCHITEKTUR abhängen, wird die ARCHITEKTUR VERIFIZIERT, um diese AKTIVITÄT zu vervollständigen. Die VERIFIZIERUNG der ARCHITEKTUR wird üblicherweise durch eine technische EVALUATION durchgeführt. 44

47 Die Klassifizierung von SOFTWARE-KOMPONENTEN innerhalb der AKTIVITÄT der Software-ARCHITEKTUR erzeugt eine Basis für die anschließende Auswahl von Software-PROZESSEN. Die Aufzeichnungen der Klassifizierung werden als Teil der RISIKOMANAGEMENT-AKTE unter Änderungskontrolle gestellt. Viele nachfolgende Ereignisse können die Klassifizierung ungültig machen. Dies sind unter anderem: Änderungen der SYSTEM-Spezifikation, der Software-Spezifikation oder der ARCHITEKTUR; die Entdeckung von Fehlern in der RISIKOANALYSE, insbesondere unvorhergesehene GEFÄHRDUNGEN, und die Entdeckung, dass eine Anforderung nicht machbar ist, insbesondere eine RISIKOKONTROLL- Maßnahme. Deshalb sollte die Klassifizierung des SOFTWARE-SYSTEMS und der SOFTWARE-KOMPONENTEN während aller AKTIVITÄTEN, die dem Design der Software-ARCHITEKTUR folgen, erneut EVALUIERT und falls notwendig überarbeitet werden. Dies würde eine Nacharbeit auslösen, nämlich die Anwendung von zusätzlichen PROZESSEN auf eine SOFTWARE-KOMPONENTE als Ergebnis ihrer Klassifizierung in eine höhere Klasse. Der Software-Konfigurationsmanagement-PROZESS (Abschnitt 8) wird verwendet um zu gewährleisten, dass alle erforderlichen Nacharbeiten identifiziert und vollständig sind. B.5.4 Detailliertes Design der Software Diese AKTIVITÄT fordert vom HERSTELLER, die SOFTWARE-KOMPONENTEN und Schnittstellen, die in der ARCHITEKTUR definiert wurden, zu verfeinern, um SOFTWARE-EINHEITEN und ihre Schnittstellen zu erzeugen. Obwohl SOFTWARE-EINHEITEN oft als eine einzelne Funktion oder ein Modul betrachtet werden, ist diese Sichtweise nicht immer angebracht. Wir haben die SOFTWARE-EINHEIT definiert als eine SOFTWARE- KOMPONENTE, die nicht in kleinere Komponenten unterteilt ist. SOFTWARE-EINHEITEN können separat geprüft werden. Der HERSTELLER sollte die Detailtiefe der SOFTWARE-EINHEIT definieren. Das detaillierte Design spezifiziert Algorithmen, Daten-Darstellungen, Schnittstellen zwischen verschiedenen SOFTWARE-EINHEITEN und Schnittstellen zwischen SOFTWARE-EINHEITEN und Datenstrukturen. Das detaillierte Design muss sich auch mit der Verpackung des SOFTWARE-PRODUKTS beschäftigen. Es ist erforderlich, das Design jeder SOFTWARE-EINHEIT und ihrer Schnittstelle zu dokumentieren, so dass die SOFTWARE-EINHEIT korrekt implementiert werden kann. Das detaillierte Design fügt die Details ein, die erforderlich sind um die Software zu konstruieren. Es sollte vollständig genug sein, so dass der Programmierer keine Ad-hoc-Design- Entscheidungen zu treffen braucht. Eine SOFTWARE-KOMPONENTE kann so zerlegt werden, dass nur einige wenige der neuen SOFTWARE- KOMPONENTEN die SICHERHEITS-bezogene Anforderung der ursprünglichen SOFTWARE-KOMPONENTE implementieren. Die verbleibenden SOFTWARE-KOMPONENTEN implementieren keine SICHERHEITS-bezogenen Funktionen und können in eine niedrigere Software-Sicherheitsklasse eingestuft werden. Die Entscheidung, dies zu tun, ist jedoch in sich selbst Teil des RISIKOMANAGEMENT-PROZESSES und wird in der RISIKO- MANAGEMENT-AKTE dokumentiert. Weil die Implementierung vom detaillierten Design abhängt, ist es erforderlich, das detaillierte Design zu VERIFIZIEREN, bevor die AKTIVITÄT vollständig ist. Die VERIFIZIERUNG des detaillierten Designs wird normalerweise bei einer technischen EVALUATION erledigt. Unterabschnitt fordert vom HERSTELLER, die Ergebnisse der AKTIVITÄT des detaillierten Designs zu VERIFIZIEREN. Das Design spezifiziert, wie die Anforderungen implementiert werden sollen. Wenn das Design Fehler enthält, kann der Code die Anforderungen nicht korrekt implementieren. Sofern im Design Merkmale vorhanden sind, von denen der HERSTELLER glaubt, dass sie für die SICHERHEIT wichtig sind, dann sollte er diese VERIFIZIEREN. Beispiele solcher Merkmale sind unter anderem: Implementierung der beabsichtigten Ereignisse, Eingaben, Ergebnisse, Schnittstellen, des logischen Flusses, der Zuordnung von CPU, der Zuordnung von Speicherplatz, Definition von Fehlern und Ausnahmen, Isolierung von Fehlern und Ausnahmen, Wiederherstellung nach Fehlern; Definition des Normalzustands, bei dem alle Fehler, die zu einer Gefährdungssituation führen können, mit Ereignissen und Übergängen adressiert werden; Initialisierung von Variablen, Speicher-Management und kalte und warme Resets, Standby und andere Zustandsänderungen, die die RISIKOKONTROLL- Maßnahmen beeinflussen können. 45

48 B.5.5 Implementierung und VERIFIZIERUNG von SOFTWARE-EINHEITEN Diese AKTIVITÄT fordert vom HERSTELLER, den Code für die SOFTWARE-EINHEITEN zu schreiben und zu VERIFIZIEREN. Das detaillierte Design wird in Quellcode übersetzt. Die Codierung ist der Zeitpunkt, zu dem die Zerlegung der Spezifikationen endet und die Zusammensetzung der ausführbaren Software beginnt. Um die gewünschten Code-Merkmale gleich bleibend zu erzielen, sollten Codierungsnormen verwendet werden, die einen bevorzugten Codierungsstil spezifizieren. Beispiele für Codierungsnormen sind unter anderem Anforderungen für die Verständlichkeit, Regeln oder Einschränkungen über den Gebrauch von Sprachen und das Management der Komplexität. Der Code für jede Einheit wird VERIFIZIERT um zu gewährleisten, dass sie wie im detaillierten Design spezifiziert funktioniert und dass sie die spezifizierten Codierungsnormen einhält. Unterabschnitt fordert vom HERSTELLER, den Code zu VERIFIZIEREN. Wenn der Code das Design nicht korrekt implementiert, wird die MEDIZINPRODUKTE-SOFTWARE nicht wie beabsichtigt funktionieren. B.5.6 Software-Integration und Integrationsprüfung Diese AKTIVITÄT fordert vom HERSTELLER, die Integration von SOFTWARE-EINHEITEN in größere SOFTWARE- KOMPONENTEN sowie die Integration von SOFTWARE-KOMPONENTEN in stärker zusammengefasste SOFTWARE- KOMPONENTEN zu planen und durchzuführen und zu VERIFIZIEREN, dass sich die SOFTWARE-KOMPONENTEN wie beabsichtigt verhalten. Der Ansatz der Integration kann von nicht-inkrementeller Integration bis hin zu jeder Form von inkrementeller Integration reichen. Die Eigenschaften der SOFTWARE-KOMPONENTE, die assembliert wird, diktieren die zu wählende Methode der Integration. Die Prüfung der Software-Integration konzentriert sich auf den Transfer von Daten und Kontrollen über die internen und externen Schnittstellen einer SOFTWARE-KOMPONENTE. Externe Schnittstellen sind solche mit anderer Software, einschließlich Betriebs-SYSTEM-Software, und MEDIZINPRODUKTE-Hardware. Die Strenge der Integrationsprüfung und das Maß an Detail der Dokumentation im Zusammenhang mit der Integrationsprüfung sollte dem RISIKO entsprechen, das mit dem Gerät verknüpft ist, der Abhängigkeit des Geräts von Software für möglicherweise gefährliche Funktionen und der Rolle von spezifischen SOFTWARE- KOMPONENTEN in Gerätefunktionen mit höherem RISIKO. Obwohl alle SOFTWARE-KOMPONENTEN geprüft werden sollten, sollten zum Beispiel Komponenten, die eine Auswirkung auf die SICHERHEIT haben, direkteren, genaueren und detaillierteren Prüfungen unterzogen werden. Soweit anwendbar zeigt die Integrationsprüfung das Programm-Verhalten an den Grenzen seiner Eingabeund Ergebnisbereiche und bestätigt Programmantworten auf ungültige, unerwartete und spezielle Eingaben. Die Aktionen des Programms werden offen gelegt, wenn es Kombinationen von Eingaben oder unerwartete Folgen von Eingaben bekommt, oder wenn definierte Timing-Anforderungen verletzt werden. Soweit angemessen, sollten die Prüfungsanforderungen im Plan die Arten von White-Box-Prüfungen enthalten, die als Teil der Integrationsprüfung durchgeführt werden sollen. White-Box-Prüfung, auch bekannt als Glas-Box-Prüfung, strukturelle Prüfung, Durchsichtige-Box- Prüfung und Offene-Box-Prüfung, ist eine Prüfungstechnik, bei der explizite Kenntnisse der internen Arbeitsweise der SOFTWARE-KOMPONENTE, die geprüft werden soll, verwendet werden, um die Prüfdaten auszuwählen. Die White-Box-Prüfung verwendet spezifische Kenntnisse über die SOFTWARE-KOMPONENTE, um Ergebnisse zu überprüfen. Die Prüfung ist nur dann genau, wenn der Prüfer weiß, was die SOFTWARE- KOMPONENTE tun soll. Der Prüfer kann dann sehen, ob die SOFTWARE-KOMPONENTE von ihrem beabsichtigten Ziel abweicht. Eine White-Box-Prüfung kann nicht garantieren, dass die vollständige Spezifikation implementiert wurde, da sie sich auf die Prüfung der Implementierung der SOFTWARE-KOMPONENTE konzentriert. Die Black-Box-Prüfung, auch bekannt als Verhaltensprüfung, als Undurchsichtige-Box- Prüfung und als Geschlossene-Box-Prüfung, konzentriert sich auf die Prüfung der funktionalen Spezifikation, und sie kann nicht garantieren, dass alle Teile der Implementierung geprüft wurden. So prüft die Black-Box-Prüfung gegen die Spezifikation und entdeckt Unterlassungsfehler, die anzeigen, dass ein Teil der Spezifikation nicht erfüllt wurde. Die White-Box-Prüfung prüft gegen die Implementierung und entdeckt Handlungsfehler, die anzeigen, dass ein Teil der Implementierung fehlerhaft ist. Um ein SOFTWARE-PRODUKT vollständig zu prüfen können Black-Box- und White-Box-Prüfungen erforderlich sein. 46

49 Die Pläne und die Prüfdokumentation, die in 5.6 und 5.7 identifiziert wurden, können individuelle Dokumente sein, die an spezifische Phasen der Entwicklung geknüpft sind oder an evolutionäre Prototypen. Sie können auch kombiniert sein, so dass ein einziges Dokument oder ein Satz von Dokumenten die Anforderungen von mehreren Unterabteilungen abdeckt. Alle Dokumente, oder Teile davon, könnten in Projektdokumente einer höheren Ebene integriert werden, wie zum Beispiel in einen Software- oder Projekt-Qualitätssicherungsplan oder einen umfangreichen Prüfungsplan, der alle Aspekte der Prüfung für Hardware und Software adressiert. In diesen Fällen sollte eine Querverweisung erstellt werden, die identifiziert, wie die verschiedenen Projektdokumente sich auf jede der AUFGABEN der Software-Integration beziehen. Die Prüfung der Software-Integration kann in einer simulierten Umgebung durchgeführt werden, an echter Ziel-Hardware oder am vollständigen MEDIZINPRODUKT. Unterabschnitt fordert vom HERSTELLER, dass er das Ergebnis der AKTIVITÄT der Software-Integration VERIFIZIERT. Ergebnis der AKTIVITÄT der Software-Integration sind die integrierten SOFTWARE-KOMPONENTEN. Diese integrierten SOFTWARE-KOMPONENTEN müssen korrekt funktionieren, damit die gesamte MEDIZIN- PRODUKTE-SOFTWARE korrekt und sicher funktioniert. B.5.7 Prüfung des SOFTWARE-SYSTEMS Diese AKTIVITÄT fordert vom HERSTELLER, die Funktionalität der Software zu VERIFIZIEREN, indem er VERIFIZIERT, dass die Anforderungen für die Software erfolgreich implementiert wurden. Die Prüfung des SOFTWARE-SYSTEMS zeigt, dass die spezifizierte Funktionalität existiert. Diese Prüfung VERIFIZIERT die Funktionalität und Leistungsfähigkeit des Programms, wie es gebaut ist, im Hinblick auf die Anforderungen für die Software. Die Prüfung des SOFTWARE-SYSTEMS konzentriert sich auf die funktionale Prüfung (Black Box), obgleich es wünschenswert sein könnte, White-Box-Methoden zu verwenden (siehe voriger Abschnitt), um bestimmte Prüfungen effizienter durchzuführen, um Stress-Bedingungen oder Fehler einzuführen oder um die Code- Abdeckung der Qualifikationsprüfung zu vergrößern. Die Organisation der Prüfung nach Typen und Prüfungsphase ist flexibel, aber die Abdeckung der Anforderungen, der RISIKOBEHERRSCHUNG, der Gebrauchstauglichkeit und der Prüftypen (z. B. Fehler, Installation, Stress) sollte demonstriert und dokumentiert werden. Die Prüfung des SOFTWARE-SYSTEMS prüft die integrierte Software und kann in einer simulierten Umgebung durchgeführt werden, an echter Ziel-Hardware oder am vollständigen MEDIZINPRODUKT. Wenn am SOFTWARE-SYSTEM eine Änderung durchgeführt wird (selbst eine kleine Änderung), sollte der Umfang der REGRESSIONSPRÜFUNG (nicht nur die Prüfung der individuellen Änderung) festgelegt werden, um zu gewährleisten, dass keine unbeabsichtigten Nebeneffekte eingeführt wurden. Diese REGRESSIONS- PRÜFUNG (und die Begründung dafür, dass nicht die ganze SOFTWARE-SYSTEM-Prüfung wiederholt wurde) sollte geplant und dokumentiert werden. Die Verantwortlichkeiten für die SOFTWARE-SYSTEM-Prüfung können verteilt sein, die Prüfungen können an unterschiedlichen Orten stattfinden und können von unterschiedlichen Organisationen durchgeführt werden. Unabhängig von der Verteilung von AUFGABEN, den vertraglichen Verhältnissen, der Herkunft von Komponenten, oder der Entwicklungsumgebung behält der HERSTELLER des Geräts jedoch letztlich die Verantwortung zu gewährleisten, dass die Software für ihre beabsichtigte Anwendung richtig funktioniert. Wenn ANOMALIEN, die während der Prüfung entdeckt wurden, wiederholt werden können, aber eine Entscheidung getroffen wurde, sie nicht zu korrigieren, dann müssen diese ANOMALIEN im Zusammenhang mit der GEFÄHRDUNGS-Analyse EVALUIERT werden, um zu VERIFIZIEREN, dass sie nicht die SICHERHEIT des Geräts beeinflussen. Die Ursache und Symptome der ANOMALIEN sollten verstanden sein und die Begründung dafür, dass sie nicht korrigiert werden, sollte dokumentiert werden. Unterabschnitt fordert, dass die Ergebnisse der SOFTWARE-SYSTEM-Prüfung EVALUIERT werden, um zu gewährleisten, dass die erwarteten Ergebnisse erzielt wurden. 47

50 B.5.8 Software-Freigabe Diese AKTIVITÄT fordert vom HERSTELLER, die VERSION der MEDIZINPRODUKTE-SOFTWARE, die freigegeben wird, zu dokumentieren, zu spezifizieren, wie sie erzeugt wurde, und geeignete Verfahren für die Freigabe der Software zu befolgen. Der HERSTELLER sollte in der Lage sein zu zeigen, dass die Software, die unter Verwendung des Entwicklungs-PROZESSES entwickelt wurde, auch diejenige Software ist, die freigegeben wird. Der HERSTELLER sollte auch in der Lage sein, die Software und die Werkzeuge, die für ihre Erzeugung verwendet wurden, wieder zu finden, für den Fall, dass sie in der Zukunft benötigt werden, und er sollte die Software in einem Zustand lagern, verpacken und ausliefern, der die Wahrscheinlichkeit minimiert, dass die Software beschädigt oder missbraucht wird. Definierte Verfahren sollten festgelegt werden um zu gewährleisten, dass diese AUFGABEN angemessen und mit gleich bleibenden Ergebnissen durchgeführt werden. B.6 Software-Wartungs-PROZESS B.6.1 Festlegung eines Plans für die Software-Wartung Der Software-Wartungs-PROZESS unterscheidet sich vom Software-Entwicklungs-PROZESS in zweierlei Hinsicht: Es ist dem HERSTELLER erlaubt, einen kleineren PROZESS als den vollständigen Software-Entwicklungs- PROZESS zu verwenden, um schnelle Änderungen in Reaktion auf dringende Probleme zu implementieren. 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). Unterabschnitt 6.1 fordert, dass diese PROZESSE in einem Wartungsplan festgelegt werden. Diese AKTIVITÄT fordert vom HERSTELLER, Verfahren zu erzeugen oder zu identifizieren, mit denen Wartungs- AKTIVITÄTEN und -AUFGABEN implementiert werden. Um korrigierende Maßnahmen zu implementieren, um Änderungen während der Wartung zu kontrollieren und um die Freigabe von überarbeiteter Software zu managen, sollte der HERSTELLER berichtete Probleme und Anfragen von Anwendern dokumentieren und lösen und Änderungen an der MEDIZINPRODUKTE-SOFTWARE managen. Dieser PROZESS wird aktiviert, wenn die MEDIZINPRODUKTE-SOFTWARE Änderungen am Code und der zugehörigen Dokumentation erfährt, entweder wegen eines Problems oder wegen des Bedarfs für Verbesserung oder Anpassung. Das Ziel ist es, freigegebene MEDIZINPRODUKTE-SOFTWARE unter Beibehaltung ihrer Integrität zu modifizieren. Dieser PROZESS schließt die Migration der MEDIZINPRODUKTE-SOFTWARE auf Umgebungen oder Plattformen ein, für die sie ursprünglich nicht freigegeben wurde. Die AKTIVITÄTEN, die in diesem Abschnitt dargestellt werden, sind spezifisch für den Wartungs-PROZESS; der Wartungs-PROZESS kann aber auch andere PROZESSE aus dieser Norm verwenden. Der HERSTELLER muss planen, wie die AKTIVITÄTEN und AUFGABEN des Wartungs-PROZESSES durchgeführt werden sollen. B.6.2 Analyse von Problemen und Änderungen Diese AKTIVITÄT fordert vom HERSTELLER, Rückmeldungen auf ihre Wirkung zu untersuchen, berichtete Probleme zu VERIFIZIEREN und eine Änderungsoption zu überlegen, auszuwählen und für die Implementierung genehmigt zu bekommen. Probleme und andere Anforderungen für Änderungen können sich auf die Leistungsfähigkeit, die SICHERHEIT oder die regulatorische Freigabe eines MEDIZINPRODUKTS auswirken. Eine Analyse ist erforderlich um festzustellen, ob aufgrund des PROBLEMBERICHTS irgendwelche Effekte existieren, oder ob irgendwelche Effekte resultieren werden aus einer Änderung, die gemacht wird, um ein Problem zu korrigieren oder eine Anforderung zu implementieren. Es ist besonders wichtig, durch Rückverfolgung oder Regressionsanalyse zu VERIFIZIEREN, dass die RISIKOKONTROLL-Maßnahmen, die in das Gerät eingebaut sind, nicht negativ geändert oder modifiziert werden durch die Software-Änderung, die als Teil der Software-Wartungs-AKTIVITÄT implementiert wird. Es ist auch wichtig zu VERIFIZIEREN, dass die modifizierte Software keine GEFÄHRDUNG verursacht oder ein RISIKO abmildert, wenn die ursprüngliche 48

51 Software keine GEFÄHRDUNGEN verursachte oder kein RISIKO abmilderte. Die Software-Sicherheitsklassifizierung einer SOFTWARE-KOMPONENTE könnte sich geändert haben, wenn die Software-Änderung jetzt eine GEFÄHRDUNG verursachen oder ein RISIKO abmildern kann. Es ist wichtig, zwischen der Software-Wartung (Abschnitt 6) und der Software-Problemlösung (Abschnitt 9) zu unterscheiden. Der Fokus des Software-Wartungs-PROZESSES liegt auf einer angemessenen Antwort auf Rückmeldungen, die nach der Freigabe des SOFTWARE-PRODUKTS entstehen. Als Teil eines MEDIZINPRODUKTS muss der Software-Wartungs-PROZESS gewährleisten, dass: SICHERHEITS-bezogene PROBLEMBERICHTE adressiert werden und an die entsprechenden Regulationsbehörden und betroffene Anwender berichtet werden; SOFTWARE-PRODUKTE nach einer Änderung erneut validiert und freigegeben werden mit formalen Kontrollen, die die Berichtigung des Problems und die Vermeidung weiterer Probleme gewährleisten; der HERSTELLER überlegt, welche anderen SOFTWARE-PRODUKTE betroffen sein könnten, und geeignete Vorkehrungen trifft. Der Fokus der Software-Problemlösung liegt auf dem Betrieb eines umfangreichen Kontroll-SYSTEMS, das: PROBLEMBERICHTE analysiert und alle Implikationen des Problems identifiziert; über eine Anzahl von Änderungen entscheidet und ihre Nebeneffekte identifiziert; die Änderungen implementiert unter Beibehaltung der Konsistenz der Software-KONFIGURATIONS- ELEMENTE einschließlich der RISIKOMANAGEMENT-AKTE; die Implementierung der Änderungen VERIFIZIERT. Der Software-Wartungs-PROZESS verwendet den Problemlösungs-PROZESS für Software. Der Software- Wartungs-PROZESS handhabt die Entscheidungen auf hoher Ebene über den PROBLEMBERICHT (ob ein Problem existiert, ob es eine signifikante Auswirkung auf die SICHERHEIT hat, welche Änderungen erforderlich sind und wann sie implementiert werden) und verwendet den Problemlösungs-PROZESS für Software, um den PROBLEMBERICHT zu analysieren, um alle Implikationen zu entdecken und um mögliche ÄNDERUNGS- ANFORDERUNGEN zu erzeugen, die alle KONFIGURATIONSELEMENTE identifizieren, die geändert werden müssen, und alle VERIFIZIERUNGsschritte, die erforderlich sind. B.6.3 Implementierung von Änderungen Diese AKTIVITÄT fordert vom HERSTELLER, einen festgelegten PROZESS zu verwenden, um die Änderung durchzuführen. Wenn ein Wartungs-PROZESS nicht definiert wurde, können die entsprechenden AUFGABEN des Entwicklungs-PROZESSES verwendet werden, um die Änderung durchzuführen. Der HERSTELLER sollte auch gewährleisten, dass die Änderung keinen negativen Effekt auf andere Teile der MEDIZINPRODUKTE- SOFTWARE verursacht. Eine Analyse der Auswirkung einer Änderung auf die ganze MEDIZINPRODUKTE- SOFTWARE ist erforderlich, es sei denn, die MEDIZINPRODUKTE-SOFTWARE wird als eine neue Entwicklung behandelt. Eine Begründung muss gegeben werden, die den Umfang der REGRESSIONSPRÜFUNG rechtfertigt, die durchgeführt wird, um zu gewährleisten, dass diejenigen Teile der MEDIZINPRODUKTE-SOFTWARE, die nicht geändert wurden, immer noch so funktionieren, wie sie dies taten, bevor die Änderung durchgeführt wurde. B.7 Software-RISIKOMANAGEMENT-Prozess Das RISIKOMANAGEMENT von Software ist ein Teil des RISIKOMANAGEMENTS des gesamten MEDIZINPRODUKTS und kann vernünftigerweise nicht isoliert betrachtet werden. Diese Norm fordert die Anwendung eines RISIKOMANAGEMENT-PROZESSES, der mit ISO übereinstimmt. RISIKOMANAGEMENT, wie es in ISO definiert ist, behandelt ganz speziell ein Rahmenwerk für das wirksame Management von RISIKEN im Zusammenhang mit der Verwendung von MEDIZINPRODUKTEN. Ein Teil von ISO betrifft die Kontrolle von identifizierten RISIKEN im Zusammenhang mit jeder GEFÄHRDUNG, die bei der RISIKOANALYSE identifiziert wurde. Der Software-RISIKOMANAGEMENT-PROZESS in dieser Norm soll zusätzliche Anforderungen geben für die RISIKOBEHERRSCHUNG von Software, einschließlich derjenigen Software, die bei der RISIKOANALYSE als möglicherweise beitragend zu einer gefährlichen Situation identifiziert wurde, oder Software, die verwendet wird, um die RISIKEN von MEDIZINPRODUKTEN zu kontrollieren. Der Software-RISIKOMANAGEMENT-PROZESS wird aus zwei Gründen in diese Norm eingefügt: 49

52 a) Die beabsichtigte Benutzergruppe dieser Norm muss die minimalen Anforderungen für RISIKOKONTROLL- Maßnahmen in ihrem Verantwortungsbereich, nämlich der Software, verstehen. b) Die allgemeine RISIKOMANAGEMENT-Norm, ISO 14971, die in dieser Norm normativ referenziert wird, adressiert nicht speziell die RISIKOBEHERRSCHUNG von Software und die Platzierung der RISIKO- BEHERRSCHUNG im Software-Entwicklungslebenszyklus. Das RISIKOMANAGEMENT von Software ist ein Teil des RISIKOMANAGEMENTS des gesamten MEDIZINPRODUKTS. Pläne, Verfahren und Dokumentation, die für die AKTIVITÄTEN des Software-RISIKOMANAGEMENTS gefordert werden, können eine Serie von separaten Dokumenten oder ein einziges Dokument sein, oder sie können in die AKTIVITÄTEN des RISIKOMANAGEMENTS des MEDIZINPRODUKTS und seiner Dokumentation integriert sein, solange alle Anforderungen dieser Norm eingehalten werden. B.7.1 Analyse von Software, die zu Gefährdungssituationen beiträgt Es wird erwartet, dass die GEFÄHRDUNGS-Analyse des Geräts Gefährdungssituationen und entsprechende RISIKOKONTROLL-Maßnahmen identifiziert, um die Wahrscheinlichkeit und/oder den Schweregrad von solchen Gefährdungssituationen auf ein vertretbares Maß zu verringern. Es wird auch erwartet, dass die RISIKOKONTROLL-Maßnahmen denjenigen Software-Funktionen zugeordnet werden, von denen erwartet wird, dass sie solche RISIKOKONTROLL-Maßnahmen implementieren. Es wird jedoch nicht erwartet, dass alle Gefährdungssituationen identifiziert werden können, bevor die Software-ARCHITEKTUR erzeugt wurde. Zu diesem Zeitpunkt ist bekannt, wie die Software-Funktionen in SOFTWARE-KOMPONENTEN implementiert werden, und die Durchführbarkeit der RISIKOKONTROLL-Maßnahmen, die Software-Funktionen zugeordnet wurden, kann EVALUIERT werden. Zu diesem Zeitpunkt sollte die GEFÄHRDUNGS-Analyse des Geräts überarbeitet werden und sollte Folgendes enthalten: überarbeitete Gefährdungssituation, überarbeitete RISIKOKONTROLL-Maßnahmen und Software-Anforderungen, neue Gefährdungssituationen, die von Software herrühren, z. B. Gefährdungssituationen im Zusammenhang mit der Ergonomie. Die Software-ARCHITEKTUR sollte glaubhafte Strategien enthalten für die Trennung von SOFTWARE- KOMPONENTEN, so dass sie nicht auf unsichere Weise miteinander interagieren. B.8 Software-Konfigurationsmanagement-PROZESS Der Software-Konfigurationsmanagement-PROZESS ist ein PROZESS, bei dem administrative und technische Verfahren im ganzen Software-Lebenszyklus angewandt werden, um SOFTWARE-KOMPONENTEN einschließlich der Dokumentation in einem SYSTEM zu identifizieren und zu definieren, um Änderungen und Freigaben der Komponenten zu kontrollieren und um den Status der Komponenten und der ÄNDERUNGSANFORDE- RUNGEN zu dokumentieren und zu berichten. Das Software-Konfigurationsmanagement ist notwendig, um eine SOFTWARE-KOMPONENTE wiederherzustellen, um ihre Bestandteile zu identifizieren und um die Vorgeschichte der Änderungen, die gemacht wurden, zur Verfügung zu stellen. B.8.1 Identifizierung der Konfiguration Diese AKTIVITÄT fordert vom HERSTELLER, Software-KONFIGURATIONSELEMENTE und ihre VERSIONEN eindeutig zu identifizieren. Diese Identifizierung ist erforderlich, um die Software-KONFIGURATIONSELEMENTE und die VERSIONEN, die in der MEDIZINPRODUKTE-SOFTWARE enthalten sind, eindeutig zu identifizieren. B.8.2 Änderungskontrolle Diese AKTIVITÄT fordert vom HERSTELLER, Änderungen der Software-KONFIGURATIONSELEMENTE zu kontrollieren, Informationen über die Identifizierung von ÄNDERUNGSANFORDERUNGEN zu dokumentieren und Dokumentationen über ihre Merkmale zu erstellen. Diese AKTIVITÄT ist erforderlich um zu gewährleisten, dass keine nicht autorisierten oder unbeabsichtigten Änderungen an den Software-KONFIGURATIONSELEMENTEN durchgeführt werden, und um zu gewährleisten, dass genehmigte ÄNDERUNGSANFORDERUNGEN vollständig implementiert und VERIFIZIERT werden. 50

53 ÄNDERUNGSANFORDERUNGEN können von einem Änderungskontroll-Ausschuss oder von einem Manager oder von einer technischen Führungsperson genehmigt werden, entsprechend dem Software-KONFIGURATIONS- MANAGEMENT-Plan. Genehmigte ÄNDERUNGSANFORDERUNGEN werden zurückverfolgbar gemacht auf die aktuelle Änderung und die VERIFIZIERUNG der Software. Es wird gefordert, dass jede aktuelle Änderung verknüpft ist mit einer ÄNDERUNGSANFORDERUNG und dass eine Dokumentation existiert, die zeigt, dass die ÄNDERUNGSANFORDERUNG genehmigt wurde. Die Dokumentation kann ein Protokoll des Änderungskontroll- Ausschusses, eine Genehmigungsunterschrift oder eine Aufzeichnung in einer Datenbank sein. B.8.3 Aufzeichnungen über den Status der Konfiguration Diese AKTIVITÄT fordert vom HERSTELLER, Aufzeichnungen über die Vorgeschichte der Software- KONFIGURATIONSELEMENTE aufzubewahren. Diese AKTIVITÄT ist erforderlich, um festzustellen, wann und warum Änderungen durchgeführt wurden. Zugriff zu dieser Information ist erforderlich, um zu gewährleisten, dass Software-KONFIGURATIONSELEMENTE nur autorisierte Änderungen enthalten. B.9 Problemlösungs-PROZESS für Software Der Problemlösungs-PROZESS für Software ist ein PROZESS, um die Probleme (einschließlich der Nicht-Übereinstimmungen) zu analysieren und zu lösen, was immer ihre Natur oder ihre Herkunft seien, einschließlich derjenigen, die während der Ausführung der Entwicklung, während der Wartung oder während anderer PROZESSE entdeckt wurden. Zielsetzung ist es, ein zeitgerechtes, verantwortungsvolles und dokumentiertes Mittel zur Verfügung zu stellen, um zu gewährleisten, dass entdeckte Probleme analysiert und gelöst werden, und dass Trends erkannt werden. Dieser PROZESS wird manchmal in der Literatur der Softwaretechnik als Fehlerverfolgung bezeichnet. In ISO/IEC [9] und IEC , Ergänzung 1 [2], wird er Problemlösung genannt. Wir haben beschlossen, ihn in dieser Norm Problemlösungs-PROZESS für Software zu nennen. Diese AKTIVITÄT fordert, dass der HERSTELLER den Problemlösungs-PROZESS für Software verwendet, wenn ein Problem oder eine Nicht-Übereinstimmung identifiziert wird. Diese AKTIVITÄT ist erforderlich um zu gewährleisten, dass entdeckte Probleme analysiert und auf mögliche Relevanz für SICHERHEIT (wie in ISO spezifiziert) untersucht und EVALUIERT werden. Pläne oder Verfahren der Software-Entwicklung, wie sie in 5.1 gefordert werden, sollen adressieren, wie Probleme oder Nicht-Übereinstimmungen behandelt werden. Dies schließt ein, dass in jeder Phase des Lebenszyklus die Aspekte des Problemlösungs-PROZESSES für Software, die formal und dokumentiert sind, spezifizierten werden, sowie auch, wenn Probleme und Nicht-Übereinstimmungen in den Problemlösungs- PROZESS für Software einbezogen werden sollen. 51

54 Anhang C (informativ) Beziehung zu anderen Normen C.1 Allgemeines Diese Norm gilt für die Entwicklung und Wartung von MEDIZINPRODUKTE-SOFTWARE. Die Software wird als ein Unter-SYSTEM des MEDIZINPRODUKTS betrachtet oder sie ist selbst ein MEDIZINPRODUKT. Diese Norm soll zusammen mit anderen entsprechenden Normen für die Entwicklung eines MEDIZINPRODUKTS verwendet werden. Management-Normen für MEDIZINPRODUKTE, wie zum Beispiel ISO [7] (siehe C.2 und Anhang D) und ISO (siehe Anhang C.3), stellen eine Management-Umgebung zur Verfügung, die eine Grundlage legt für eine Organisation, um Produkte zu entwickeln. Allgemeine Produkt- und Sicherheitsnormen, wie zum Beispiel IEC [1] (siehe Anhang C.4) und IEC [4] (siehe Anhang C.5), geben spezifische Anweisungen für die Erzeugung von sicheren MEDIZINPRODUKTEN. Wenn Software ein Teil dieser MEDIZIN- PRODUKTE ist, so gibt IEC detailliertere Anweisungen, was erforderlich ist, um sichere MEDIZINPRO- DUKTE-SOFTWARE zu entwickeln und zu warten. Viele andere Normen, wie zum Beispiel ISO/IEC [9] (siehe Anhang C.6), IEC [3] (siehe Anhang C.7) und ISO/IEC [11], können als eine Quelle von Methoden, Werkzeugen und Techniken betrachtet werden, die verwendet werden können, um die Anforderungen von IEC zu implementieren. Bild C.1 zeigt die Beziehung zwischen diesen Normen. Werden Abschnitte oder Anforderungen aus anderen Normen zitiert, so gilt für Begriffe und Definitionen in diesen Zitaten, dass sie in der anderen Norm definiert sind, nicht in dieser Norm. 52

55 Bild C.1 Beziehung von wichtigen MEDIZINPRODUKTE-Normen zur IEC C.2 Beziehung zur ISO Diese Norm fordert, dass der HERSTELLER ein Qualitätsmanagement-SYSTEM einsetzt. Wenn ein HERSTELLER ISO [7] verwendet, dann beziehen sich die Anforderungen von IEC direkt auf einige der Anforderungen von ISO 13485, wie in Tabelle C.1 dargestellt. Tabelle C.1 Beziehung zu ISO 13485:2003 Abschnitt in IEC Entsprechender Abschnitt von ISO 13485: Planung der Software-Entwicklung Design- und Entwicklungsplanung 5.2 Analyse der Software-Anforderungen Design- und Entwicklungsvorgaben 5.3 Design der Software-ARCHITEKTUR 5.4 Detailliertes Software-Design 5.5 Implementierung und VERIFIZIERUNG der SOFTWARE-EINHEITEN 5.6 Software-Integration und -Integrationsprüfung 5.7 Prüfung des SOFTWARE-SYSTEMS Design- und Entwicklungsergebnisse Design- und Entwicklungsbewertung 5.8 Software-Freigabe Design- und Entwicklungsverifizierung Design- und Entwicklungsvalidierung 6.1 Festlegung eines Plans für die Software-Wartung Lenkung von Design- und Entwicklungsänderungen 6.2 Analyse von Problemen und Änderungen 53

56 Abschnitt in IEC Entsprechender Abschnitt von ISO 13485: Implementierung von Änderungen Design- und Entwicklungsverifizierung Design- und Entwicklungsvalidierung 7.1 Analyse von Software, die zu Gefährdungssituationen beiträgt 7.2 RISIKOKONTROLL-Maßnahmen 7.3 VERIFIZIERUNG von RISIKOKONTROLL-Maßnahmen 7.4 RISIKOMANAGEMENT von Software-Änderungen 8.1 Identifizierung der Konfiguration Identifikation und Rückverfolgbarkeit 8.2 Änderungskontrolle Identifikation und Rückverfolgbarkeit 8.3 Aufzeichnungen über den Status der Konfiguration 9 Problemlösungs-PROZESS für Software C.3 Beziehung zu ISO Tabelle C.2 zeigt die Bereiche, wo IEC die Anforderungen an den RISIKOMANAGEMENT-PROZESS, der von ISO gefordert wird, erweitert. Tabelle C.2 Beziehung zu ISO 14971:2000 Abschnitt in ISO 14971:2000 N7) Entsprechender Abschnitt in IEC Verfahren der RISIKOANALYSE 4.2 BESTIMMUNGSGEMÄSSER GEBRAUCH/ZWECKBE- STIMMUNG und Feststellung der Merkmale, die sich auf die Sicherheit des Medizinprodukts beziehen 4.3 Feststellung bekannter oder vorhersehbarer GEFÄHRDUNGEN 7.1 Analyse von Software, die zu Gefährdungssituationen beiträgt 4.4 Einschätzung der RISIKEN für jede GEFÄHRDUNG 4.3 Software-Sicherheitsklassifizierung 5 RISIKOBEWERTUNG 6.1 Risikominderung 6.2 Analyse der Optionen Definition von RISIKOKONTROLL-Maßnahmen 6.3 Umsetzung von Maßnahmen zur Risikobeherrschung N8) RISIKOKONTROLL-Maßnahmen, die in Software implementiert werden VERIFIZIERUNG von RISIKOKONTROLL-Maßnahmen 6.4 Bewertung des RESTRISIKOS 6.5 RISIKO/Nutzen-Analyse 6.6 Weitere verursachte GEFÄHRDUNGEN Dokumentation neuer Folgen von Ereignissen 6.7 Vollständigkeit der RISIKOBEWERTUNG 7 Gesamt-RESTRISIKOBEWERTUNG 8 RISIKOMANAGEMENT-Bericht Dokumentation der RÜCKVERFOLGBARKEIT 9 Informationen aus den der Produktion nachgelagerten Phasen 7.4 RISIKOMANAGEMENT von Software-Änderungen N2) N3) Nationale Fußnote: In dieser Spalte entsprechen Begriffe in Großbuchstaben den definierten Begriffen in der ISO 14971:2000. Nationale Fußnote: Der Begriff wurde zur besseren Verständlichkeit von Risikokontrolle auf Risikobeherrschung geändert. In der neuen Ausgabe von DIN EN ISO 14971:2006 wird dieser Begriff ebenfalls verwendet. 54

57 C.4 Beziehung zu PEMS Anforderungen aus IEC :2005 C.4.1 Allgemeines Anforderungen für Software sind eine Untermenge der Anforderungen für ein programmierbares elektrisches medizinisches SYSTEM (PEMS). Diese Norm identifiziert Anforderungen für Software, die zusätzlich, aber nicht in Widerspruch zu den Anforderungen von IEC [1] für PEMS sind. Weil PEMS Elemente enthalten, die nicht Software sind, werden nicht alle Anforderungen von IEC für PEMS in dieser Norm adressiert. C.4.2 Software-Beziehungen zur PEMS-Entwicklung Wenn man das V-Modell, das in Bild C.2 gezeigt wird, verwendet, um zu beschreiben, was während einer PEMS-Entwicklung passiert, so kann man sehen, dass die Anforderungen dieser Software-Norm für das PEMS-Komponenten-Niveau gelten, von der Spezifikation der Software-Anforderungen bis zur Integration der SOFTWARE-KOMPONENTEN in ein SOFTWARE-SYSTEM. Dieses SOFTWARE-SYSTEM ist ein Teil eines programmierbaren elektrischen Unter-SYSTEMS (PESS), welches wiederum ein Teil eines PEMS ist. 55

58 Bild C.2 Software als Teil des V-Modells 56