spice in der medizinischen software-entwicklung · organizational life cycle processes primary life...
TRANSCRIPT
Matthias Hölzer-Klüpfel
SPICE in der medizinischenSoftware-EntwicklungMedConf 2012
Medical SPICE
Medizinische SoftwareRegulatorische GrundlagenReferenzmodellMedical SPICE
Beispiele
1968: Software-Krise
CMM(I)
Initiative des Software-Engineering Institute der Carnegie MellonUniversität (1991)
Capability Maturity Model (Integration)
Hypothese:Produktqualität entspricht Prozessqualität
Bestimmung eines Reifegrades für die Prozesse der Software-Entwicklung
Reifegrade im CMMI
80
726
1306
51
184
0
200
400
600
800
1000
1200
1400
1 - anfänglich 2 - gemanaged 3 - definiert 4 - qulitativgemanaged
5 - optimiert
Anzahl Firmen
CMMI Appraisals (Stand 01/2009)
1989: Immer noch Krise…
46%
30%
19%
3%
2%
Funktionalität
geliefert, aber nicht bestellt
bestellt, aber nicht geliefert
mit großen Änderungennutzbar
mit kleinen Änderungennutzbar
genutzt wie geliefert
[Studie DOD 1989]
Software-Fehler in Medizinprodukten
other design andconstruction errors
Quelle: BfArM 2010
21 %Software-Fehler
Andere Design- undKonstruktions-Fehler
Medical SPICE
Medizinische SoftwareRegulatorische GrundlagenReferenzmodellMedical SPICE
Gesetzlicher Rahmen
Medical DeviceDirective
(93/42 EEC)
ActiveImplantable MDD
(90/385 EEC)
In VitroDiagnosticDirective
(98/79 EEC)
MedizinprodukteGesetz(MPG)
MedizinprodukteBetreiberver.(MPBetreibV)
MedizinprodukteVerordnung
(MPV)
MedizinprodukteSicherheitsver.
(MPSV)
Entwicklungsprozesse
„Die Konformitätsbewertung erfordert,dass für den Entwurf der Software ein Prozessbefolgt wird, der auf dem Risikomanagementbasiert und eineEntwicklungsmethode nutzt, die das Konzeptdes Software-Lebenszyklus beinhaltet.“
[Benannte Stellen (NB-MED/2.2/Rec4)]
Harmonisierte Normen
MPG §8 Harmonisierte Normen, Gemeinsame TechnischeSpezifikationen
Stimmen Medizinprodukte mit harmonisierten Normen oder ihnengleichgestellten Monografien des Europäischen Arzneibuches oderGemeinsamen Technischen Spezifikationen, die das jeweiligeMedizinprodukt betreffen, überein, wird insoweit vermutet, dass sie dieBestimmungen dieses Gesetzes einhalten.
Die Gemeinsamen Technischen Spezifikationen sind in der Regeleinzuhalten. Kommt der Hersteller in hinreichend begründeten Fällendiesen Spezifikationen nicht nach, muss er Lösungen wählen, die demNiveau der Spezifikationen zumindest gleichwertig sind.
Anwendbare Standards
ISO 14971
ISO 13485
IEC 62304
IEC 60601-1
IEC 62366
RisikomanagementRisikomanagement
QualitätsmanagementQualitätsmanagement
Software LebenszyklusSoftware Lebenszyklus
Programmierbare MedizinelektronikProgrammierbare Medizinelektronik
GebrauchstauglichkeitGebrauchstauglichkeit
IEC 62304
Kundenbedürfnisse Erfüllte Kunden-bedürfnisse
System-Entwicklungs-Aktivitäten (einschließlich Risikomanagement)
Aktivitäten außerhalb des Geltungsbereichs dieser Norm
Software-Risikomanagement-Prozess
Planung derSoftware-
Enwicklung
Analyse derSoftware-
Anforderung
Design derSoftware-
Architektur
DetailliertesSoftware-
Design
Implement./Verifizierung
SoftwareIntegration u.
-prüfung
Prüfung desSoftware-Systems
SoftwareFreigabe
Software-Konfigurationsmanagement-Prozess
Problemlösungs-Prozess für Software
Software Entwicklung
Allerdings..
Norm
IEC 60601-1
ISO 14971
IEC 62304
IEC 62366
ISO 13485
Qualitäts-management
Risiko-management
Konfigurations-management
SW-Entwicklung SW-Wartung
Medical SPICE
Medizinische SoftwareRegulatorische GrundlagenReferenzmodellMedical SPICE
Master These Sven Wittorf
Vereinheitlichung der Anforderungen an die Entwicklungmedizinischer Software:
1. Dekomposition der harmonisierten Standards
2. Elimination der redundanten Forderungen
3. Sortierung der Anforderungen nach Prozessgebieten
4. Re-Aggregierung der Elemente in Prozessanforderungen
Beispiel: Dekomposition
ISO 13485:2003, 7.3.1:
“The organization shall establish documented proceduresfor design and development.”
Task 1:Establish procedures
Result 1:Procedures
Task 2:Document procedures
Result 2:Documented Procedures
Role:Organization
performs is responsible for
performs
is responsible for
creates is input for creates
Medical SPICE
Medizinische SoftwareRegulatorische GrundlagenReferenzmodellMedical SPICE
ISO 15504 (SPICE)
normativ
informativ
Teil 1: Konzepte und Begriffe
Teil 2: Durchführung eines Assessments
Teil 3: Anleitung zur Durchführung einesAssessments
Teil 4: Anleitung zur Verwendung beiProzessverbesserungen
Teil 5: Ein Beispiel für einProzessassessmentmodell
Bestandteile
Process Reference ModelDomain and Scope
Process PurposeProcess Outcomes Process Assessment Model
ScopeIndicatorsMapping
Translation
Measurement FrameworkCapability Levels
Process AttributesRating Scale
Assessment ProcessPlanning
Data CollectionData Validation
Process Attribute RatingReporting
Roles and ResponsibilitiesSponsor
Competent AssessorAssessor
Initial Input Output
Assessment Framework
Process AssessmentModel
1 2 3 ........ nProcess entities
Capability S
cale
Process AssessmentModel
1 2 3 ........ nProcess entities
Capability S
caleProcess Reference Model (PRM)
Domain and ScopeProcesses with Purpose and
Outcomes
mapping
Process Reference Model (PRM)Domain and Scope
Processes with Purpose andOutcomes
mapping
Measurement FrameworkCapability LevelsProcess AttributesRating Scale
mapping
Measurement FrameworkCapability LevelsProcess AttributesRating Scale
mapping
Reifegrade
5 – OptimierendQuantitative Maßnahmen werden verwendet, um den Prozess kontinuierlich zuverbessern4 – VorhersagbarMetriken ermöglichen die Kontrolle der Prozess-Performance und derErgebnisse
3 – EtabliertVordefinierte Prozesse werden an spezifische Gegebenheiten angepasst
2 – GemanagtProzesse und Ergebnisse werden geführt, Verantwortlichkeiten sindidentifiziert
1 – DurchgeführtProzesse werden intuitiv durchgeführt
0 – UnvollständigChaotische Prozesse
Prozessattribute
Reifegrad Prozessattribute5 Optimierend PA 5.1 Prozessinnovation
PA 5.2 Prozessoptimierung4 Vorhersagbar PA 4.1 Prozessmessung
PA 4.2 Prozesssteuerung3 Etabliert PA 3.1 Prozessdefinition
PA 3.2 Prozessanwendung2 Gemanagt PA 2.1 Management der Durchführung
PA 2.2 Management der Arbeitsprodukte1 Durchgeführt PA 1.1 Prozessdurchführung
0 Unvollständig
Medical SPICE
Process AssessmentModel
1 2 3 ........ nProcess entities
Capability S
cale
1 2 3 ........ nProcess entities
Capability S
caleProcess Reference Model (PRM)
?
mapping
Process Reference Model (PRM)
mapping
Measurement FrameworkCapability LevelsProcess AttributesRating Scale
mapping
Measurement FrameworkCapability LevelsProcess AttributesRating Scale
mapping Medical SPICE
Unified Reference for MedicalIEC 62304incomlete
performedmanaged
establishedpredictable
optimizing
01
23
45
Assessment Modell
6 Prozessgebiete
25 Prozesse
154 Base Practices
71 Work Products
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Prozessgebiete
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle ProcessesOrganizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle Processes
Supporting Life Cycle ProcessesPrimary Life Cycle Processes
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Prozessgebiete (heute)
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle ProcessesOrganizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle Processes
Supporting Life Cycle ProcessesPrimary Life Cycle Processes
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Beispiel: Aggregierung
Base Practice SD.2.BP.1:
“Establish a Software Development Plan. Establish a plan forthe software development. Design the SoftwareDevelopment Plan appropriate to the scope, the magnitudeand the software safety classification of the softwaresystem.”
[ISO 62304:2006, 5.1.1; ISO 13485:2003, 7.3.1]
Anwendungsfälle
Klassische SPICE-Assessments
Prozessverbesserung
Lieferantenauditierung
Konformitätsbewertung
Vorlage für die Entwicklung vonBest-Practices
VDI-Richtlinie 5702
VDI-Richtlinienausschuss
Gründruck Anfang 2013
Weißdruck Ende 2013
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Software Development Process Group (SD)
SD.1 Software Development Life Cycle DefinitionSD.2 Software Development PlanningSD.3 Software Requirements AnalysisSD.4 Software Architectural DesignSD.5 Software Detailed DesignSD.6 Software ImplementationSD.7 Software IntegrationSD.8 Software System TestSD.9 Software ValidationSD:10 Software Release
Prozessgebiete (VDI-Richtlinie)
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle ProcessesOrganizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Management Proc. Group (OM)
OM.1 Top ManagementOM.2 Responsibility and CommunicationOM.3 Management ReviewOM.4 Resource Management
Organizational Life Cycle Processes
Supporting Life Cycle ProcessesPrimary Life Cycle Processes
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Software Maintenance Process Group (SM)
SM.1 Software Maintenance PlanningSM.2 Problem Resolution and
Modification AnalysisSM.3 Modification Implementation
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Documentation Management Proc. Group (DM)
DM.1 Document ControlDM.2 Record Control
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Quality Management Process Group (QM)
QM.1 Quality Policy EstablishmentQM.2 Quality PlanningQM.3 Quality Management System EstablishmentQM.4 Process DefinitionQM.5 Process Improvement
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Risk Management Process Group (RM)
RM.1 Risk Management PlanningRM.2 Risk AnalysisRM.3 Risk EvaluationRM.4 Risk ControlRM.5 Risk AcceptabilityRM.6 Risk Management ReportingRM.7 Risk Monitoring
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Configuration Mgmt. Proc. Group (SCM)
SCM.1 Configuration Item IdentificationSCM.2 Change ControlSCM.3 Configuration Status Accounting
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Software Problem Resolution Proc. Group (SPR)
SPR.1 Software Problem InvestigationSPR.2 Software Change Management
Zusammenfassung
Medizinische Software ist zahlreichenregulatorischen Auflagen unterworfen
Die Konformität mit den harmonisierten Normenalleine sagt wenig über die Reife desEntwicklungsprozesses aus
Mit Medical SPICE steht ein Assessment-Modellzur Verfügung, das die Bestimmung desReifegrads der Software-Entwicklung erlaubt
Kontakt
post Zweite Felsengasse 597082 WürzburgGermany
tel +49 931 32072-821fax +49 931 32072-819mobil +49 176 6085 7994
mail [email protected] www.hoelzer-kluepfel.de
…und natürlich hier auf der MedConf!
MATTHIAS HÖLZER-KLÜPFELDIPLOM-PHYSIKER, M.SC.