SPICE in der medizinischen Software-Entwicklung

Transkript

1 SPICE in der medizinischen Software-Entwicklung MedConf 2012 Matthias Hölzer-Klüpfel

2 Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE

3 Beispiele

4 1968: Software-Krise

5 CMM(I) Initiative des Software-Engineering Institute der Carnegie Mellon Universität (1991) Capability Maturity Model (Integration) Hypothese: Produktqualität entspricht Prozessqualität Bestimmung eines Reifegrades für die Prozesse der SoftwareEntwicklung

6 Reifegrade im CMMI Anzahl Firmen anfänglich 2 - gemanaged 3 - definiert 4 - qulitativ gemanaged 5 - optimiert CMMI Appraisals (Stand 01/2009)

7 1989: Immer noch Krise Funktionalität 2% 3% geliefert, aber nicht bestellt 19% bestellt, aber nicht geliefert 46% mit großen Änderungen nutzbar mit kleinen Änderungen nutzbar 30% genutzt wie geliefert [Studie DOD 1989]

8 Software-Fehler in Medizinprodukten Software-Fehler 21 % other design and construction errors Andere Design- und Konstruktions-Fehler Quelle: BfArM 2010

9 Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE

10 Gesetzlicher Rahmen Medical Device Directive (93/42 EEC) Active Implantable MDD (90/385 EEC) In Vitro Diagnostic Directive (98/79 EEC) Medizinprodukte Gesetz (MPG) Medizinprodukte Betreiberver. (MPBetreibV) Medizinprodukte Verordnung (MPV) MedizinprodukteSi cherheitsver. (MPSV)

11 Entwicklungsprozesse Die Konformitätsbewertung erfordert, dass für den Entwurf der Software ein Prozess befolgt wird, der auf dem Risikomanagement basiert und eine Entwicklungsmethode nutzt, die das Konzept des Software-Lebenszyklus beinhaltet. [Benannte Stellen (NB-MED/2.2/Rec4)]

12 Harmonisierte Normen MPG 8 Harmonisierte Normen, Gemeinsame Technische Spezifikationen Stimmen Medizinprodukte mit harmonisierten Normen oder ihnen gleichgestellten Monografien des Europäischen Arzneibuches oder Gemeinsamen Technischen Spezifikationen, die das jeweilige Medizinprodukt betreffen, überein, wird insoweit vermutet, dass sie die Bestimmungen dieses Gesetzes einhalten. Die Gemeinsamen Technischen Spezifikationen sind in der Regel einzuhalten. Kommt der Hersteller in hinreichend begründeten Fällen diesen Spezifikationen nicht nach, muss er Lösungen wählen, die dem Niveau der Spezifikationen zumindest gleichwertig sind.

13 Anwendbare Standards ISO Risikomanagement ISO Qualitätsmanagement IEC Software Lebenszyklus IEC Programmierbare Medizinelektronik IEC Gebrauchstauglichkeit

14 IEC Kundenbedürfnisse Erfüllte Kundenbedürfnisse Aktivitäten außerhalb des Geltungsbereichs dieser Norm System-Entwicklungs-Aktivitäten (einschließlich Risikomanagement) Software-Risikomanagement-Prozess Software Entwicklung Planung der SoftwareEnwicklung Analyse der SoftwareAnforderung Design der SoftwareArchitektur Detailliertes SoftwareDesign Implement./ Verifizierung Software Integration u. -prüfung Prüfung des SoftwareSystems Software-Konfigurationsmanagement-Prozess Problemlösungs-Prozess für Software Software Freigabe

15 Allerdings.. Norm IEC ISO IEC IEC ISO Qualitätsmanagement Risikomanagement Konfigurationsmanagement SWEntwicklung SW-Wartung

16 Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE

17 Master These Sven Wittorf Vereinheitlichung der Anforderungen an die Entwicklung medizinischer Software: 1. Dekomposition der harmonisierten Standards 2. Elimination der redundanten Forderungen 3. Sortierung der Anforderungen nach Prozessgebieten 4. Re-Aggregierung der Elemente in Prozessanforderungen

18 Beispiel: Dekomposition ISO 13485:2003, 7.3.1: The organization shall establish documented procedures for design and development. Role: Organization performs is responsible for performs is responsible for creates Task 1: Establish procedures is input for Result 1: Procedures Task 2: Document procedures creates Result 2: Documented Procedures

19 Medical SPICE Medizinische Software Regulatorische Grundlagen Referenzmodell Medical SPICE

20 ISO (SPICE) Teil 1: Konzepte und Begriffe Teil 2: Durchführung eines Assessments Teil 3: Anleitung zur Durchführung eines Assessments Teil 4: Anleitung zur Verwendung bei Prozessverbesserungen Teil 5: Ein Beispiel für ein Prozessassessmentmodell normativ informativ

21 Bestandteile Process Reference Model Domain and Scope Process Purpose Process Outcomes Initial Input Process Assessment Model Scope Indicators Mapping Translation Assessment Process Planning Data Collection Data Validation Process Attribute Rating Reporting Roles and Responsibilities Sponsor Competent Assessor Assessor Measurement Framework Capability Levels Process Attributes Rating Scale Output

22 Assessment Framework Capability Scale mapping Measurement Framework Capability Levels Process Attributes Rating Scale Process Assessment Model n Process entities mapping Process Reference Model (PRM) Domain and Scope Processes with Purpose and Outcomes

23 Reifegrade 5 Optimierend Quantitative Maßnahmen werden verwendet, um den Prozess kontinuierlich zu verbessern 4 Vorhersagbar Metriken ermöglichen die Kontrolle der Prozess-Performance und der Ergebnisse 3 Etabliert Vordefinierte Prozesse werden an spezifische Gegebenheiten angepasst 2 Gemanagt Prozesse und Ergebnisse werden geführt, Verantwortlichkeiten sind identifiziert 1 Durchgeführt Prozesse werden intuitiv durchgeführt 0 Unvollständig Chaotische Prozesse

24 Prozessattribute Reifegrad Prozessattribute 5 Optimierend 4 Vorhersagbar 3 Etabliert 2 Gemanagt 1 Durchgeführt PA 5.1 PA 5.2 PA 4.1 PA 4.2 PA 3.1 PA 3.2 PA 2.1 PA 2.2 PA Unvollständig Prozessinnovation Prozessoptimierung Prozessmessung Prozesssteuerung Prozessdefinition Prozessanwendung Management der Durchführung Management der Arbeitsprodukte Prozessdurchführung

25 Medical SPICE 4 predictable established managed 1 performed incomlete Capability Scale 5 optimizing mapping Measurement Framework Capability Levels Process Attributes Rating Scale Process Assessment Model Medical SPICE n Process entities mapping Process Reference Model (PRM) IEC Unified Reference? for Medical

26 Assessment Modell 6 Prozessgebiete 25 Prozesse 154 Base Practices 71 Work Products

27 Prozessgebiete Primary Life Cycle Processes Software Development Process Group (SD) SD.1 SD.2 SD.3 SD.4 SD.5 SD.6 SD.7 SD.8 SD.9 SD:10 Software Development Life Cycle Definition Software Development Planning Software Requirements Analysis Software Architectural Design Software Detailed Design Software Implementation Software Integration Software System Test Software Validation Software Release Software Maintenance Process Group (SM) SM.1 SM.2 SM.3 Software Maintenance Planning Problem Resolution and Modification Analysis Modification Implementation Organizational Life Cycle Processes Organizational Management Proc. Group (OM) OM.1 OM.2 OM.3 OM.4 Top Management Responsibility and Communication Management Review Resource Management Supporting Life Cycle Processes Documentation Management Proc. Group (DM) DM.1 DM.2 Document Control Record Control Quality Management Process Group (QM) QM.1 QM.2 QM.3 QM.4 QM.5 Quality Policy Establishment Quality Planning Quality Management System Establishment Process Definition Process Improvement Risk Management Process Group (RM) RM.1 RM.2 RM.3 RM.4 RM.5 RM.6 RM.7 Risk Management Planning Risk Analysis Risk Evaluation Risk Control Risk Acceptability Risk Management Reporting Risk Monitoring Software Configuration Mgmt. Proc. Group (SCM) SCM.1 SCM.2 SCM.3 Configuration Item Identification Change Control Configuration Status Accounting Software Problem Resolution Proc. Group (SPR) SPR.1 SPR.2 Software Problem Investigation Software Change Management

28 Prozessgebiete (heute) Primary Life Cycle Processes Software Development Process Group (SD) SD.1 SD.2 SD.3 SD.4 SD.5 SD.6 SD.7 SD.8 SD.9 SD:10 Software Development Life Cycle Definition Software Development Planning Software Requirements Analysis Software Architectural Design Software Detailed Design Software Implementation Software Integration Software System Test Software Validation Software Release Software Maintenance Process Group (SM) SM.1 SM.2 SM.3 Software Maintenance Planning Problem Resolution and Modification Analysis Modification Implementation Organizational Life Cycle Processes Organizational Management Proc. Group (OM) OM.1 OM.2 OM.3 OM.4 Top Management Responsibility and Communication Management Review Resource Management Supporting Life Cycle Processes Documentation Management Proc. Group (DM) DM.1 DM.2 Document Control Record Control Quality Management Process Group (QM) QM.1 QM.2 QM.3 QM.4 QM.5 Quality Policy Establishment Quality Planning Quality Management System Establishment Process Definition Process Improvement Risk Management Process Group (RM) RM.1 RM.2 RM.3 RM.4 RM.5 RM.6 RM.7 Risk Management Planning Risk Analysis Risk Evaluation Risk Control Risk Acceptability Risk Management Reporting Risk Monitoring Software Configuration Mgmt. Proc. Group (SCM) SCM.1 SCM.2 SCM.3 Configuration Item Identification Change Control Configuration Status Accounting Software Problem Resolution Proc. Group (SPR) SPR.1 SPR.2 Software Problem Investigation Software Change Management

29 Beispiel: Aggregierung Base Practice SD.2.BP.1: Establish a Software Development Plan. Establish a plan for the software development. Design the Software Development Plan appropriate to the scope, the magnitude and the software safety classification of the software system. [ISO 62304:2006, 5.1.1; ISO 13485:2003, 7.3.1]

30 Anwendungsfälle Klassische SPICE-Assessments Prozessverbesserung Lieferantenauditierung Konformitätsbewertung Vorlage für die Entwicklung von Best-Practices

31 VDI-Richtlinie 5702 VDI-Richtlinienausschuss Gründruck Anfang 2013 Weißdruck Ende 2013

32 Prozessgebiete (VDI-Richtlinie) Primary Life Cycle Processes Software Development Process Group (SD) SD.1 SD.2 SD.3 SD.4 SD.5 SD.6 SD.7 SD.8 SD.9 SD:10 Software Development Life Cycle Definition Software Development Planning Software Requirements Analysis Software Architectural Design Software Detailed Design Software Implementation Software Integration Software System Test Software Validation Software Release Software Maintenance Process Group (SM) SM.1 SM.2 SM.3 Software Maintenance Planning Problem Resolution and Modification Analysis Modification Implementation Organizational Life Cycle Processes Organizational Management Proc. Group (OM) OM.1 OM.2 OM.3 OM.4 Top Management Responsibility and Communication Management Review Resource Management Supporting Life Cycle Processes Documentation Management Proc. Group (DM) DM.1 Document Control DM.2 Record Control Quality Management Process Group (QM) QM.1 QM.2 QM.3 QM.4 QM.5 Quality Policy Establishment Quality Planning Quality Management System Establishment Process Definition Process Improvement Risk Management Process Group (RM) RM.1 RM.2 RM.3 RM.4 RM.5 RM.6 RM.7 Risk Management Planning Risk Analysis Risk Evaluation Risk Control Risk Acceptability Risk Management Reporting Risk Monitoring Software Configuration Mgmt. Proc. Group (SCM) SCM.1 SCM.2 SCM.3 Configuration Item Identification Change Control Configuration Status Accounting Software Problem Resolution Proc. Group (SPR) SPR.1 SPR.2 Software Problem Investigation Software Change Management

33 Zusammenfassung Medizinische Software ist zahlreichen regulatorischen Auflagen unterworfen Die Konformität mit den harmonisierten Normen alleine sagt wenig über die Reife des Entwicklungsprozesses aus Mit Medical SPICE steht ein Assessment-Modell zur Verfügung, das die Bestimmung des Reifegrads der Software-Entwicklung erlaubt

34 Kontakt MATTHIAS HÖLZER-KLÜPFEL DIPLOM-PHYSIKER, M.SC. post Zweite Felsengasse Würzburg Germany tel fax mobil mail web matthias@hoelzer-kluepfel.de und natürlich hier auf der MedConf!