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 matthias@hoelzer-kluepfel.deweb www.hoelzer-kluepfel.de

…und natürlich hier auf der MedConf!

MATTHIAS HÖLZER-KLÜPFELDIPLOM-PHYSIKER, M.SC.