IEC 62304 An introduction the Software Life Cycle for Medical Devices Version 04
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 1 Content • The IEC62304 and its environment • SW Classification • IEC62304 implementation • The IEC62304 step by step • General Requirements • Software Development • Software Risk Management • Software Configuration Management • Software Problem Resolution • Software Maintenance • SOUP
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 2 But first who is who…..
• Willem vd Biggelaar • Quality and Medical Regulatory Consultant for 15 years now • Certified DEKRA auditor for ISO 9001 / ISO 13485 • Setup ISO 13485 certified Quality Management Systems (QMS) • Previous jobs • Quality Assurance Officer (5 years) • System Tester (1 year) • Embedded software engineer (7 years) • And you?
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 3 The IEC62304 and its environment
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 4 Just to set the scope…….IEC62304:2006 v1.0
• Is the de-facto process standard for the development of medical device software • New 2.0 version on it’s way, version 1.1 already available but not harmonized
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 5 Recognized by major markets (EU, USA, China)
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 6 Regulatory framework
Harmonized Standards presume conformance to GSPR Generic Product Standards examples
Process Standards IEC 60601-1 Electrical Safety ISO 13485 QMS for MDR contains GSPR medical devices IEC 60601-1-2 EMC Regulatory Medical Device requirements ISO 14971 Risk IEC 60601-1-6 Usability Management European Medical Satisfy Fulfill Devices Regulate Particular Product Standards Regulation (2017/ IEC 62366 Useability examples 745/EC) Engineering IEC 60601-2-10 safety of nerve and muscle stimulators IEC 62304 Software Life Mandatory. You have to comply cycle IEC 60601-2-57 Non-laser light source equipment
IEC 62471 Photobiological safety of lamps and lamp systems
Voluntary but if you do not follow them,a lot of justification is needed
European website where you can find the harmonized standards (based on current MDD): http://ec.europa.eu/growth/single-market/european-standards/harmonised-standards/medical-devices/index_en.htm
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 7 Relation with other standards
Standalone & embedded Embedded Standalone Health SW Medical Device SW Medical Device SW IEC62304 IEC60601-1 Medical Electrical Equipment IEC82304 Electrical equipment having an Medical Device Medical Electrical Health Software APPLIED PART or transferring energy to Software Equipment – Basic safety or from the PATIENT or detecting such Health SW energy transfer to or from the Any kind of software, which directly or Normative PATIENT and which is intended by its indirectly has an effect on health. Reference MANUFACTURER to be used as a MEDICAL E.g. Radiology Information Systems (RIS), DEVICE Prescription Management Systems (PMS), ISO14971 Laboratory Information Mngt Systems (LIMS) Risk Management
ISO13485 IEC62366 Quality Systems Useability
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 8 Out of scope of IEC62304: Validation
• Standalone Software: IEC82304 Health Software • Embedded Software: IEC60601-1 Medical Electrical Equipment: Chapter 14: PEMS
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 9 Relation with IEC60601-1 Medical Electrical Equipment
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 10 Content IEC62304 1. Scope 2. Normative references 3. Terms and definitions 4. General Requirements 5. Software Development 6. Software Maintenance 7. Software Risk Management 8. Software Configuration Management 9. Software Problem Resolution 10. Annex A Rationale for the requirements of this standard 11. Annex B Guidance on the provisions of this standard 12. Annex C Relationship to other standards 13. Annex D Implementation
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 11 Product creation in one picture
Maintenance feedback & Change Management Field impact on change Installed Base Customer Stakeholder Change Timing, budget Hazards Request product product CM Item Configuration Risk Project / Product Management Management Management (CM) Project Plan Release Product Release Risk V&V Plan Baseline Management Design File Release Notes Reviews Requirements User Manual Problem Reports Control Risk / Benefit Measures analysis V&V Specs V&V Reports
Requirements Requirements Verification & Management Specifications Validation (V&V)
Peer Regression Reviews Tests
Design Specs Peer Design & Software Code Reviews Implementation
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 12 So what is IEC62304 about?
Professional Software Development
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 13 Software Classification
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 14 Definition Software classification
Class A No injury or damage to health possible Class B Non serious injury possible Class C Death or serious injury possible
Dependent on the classification, more requirements from IEC62304 are to be implemented. The idea behind it is that The most unsafe SW requires the most strict SW process
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 15 A B C 5 Software Development 22 46 52 5.1 Development Planning 7 10 11 5.2 Requirements Analysis 5 6 6 5.3 Architectural Design 0 4 5 5.4 Detailed Design 0 1 4 5.5 Software Unit Implementation 1 4 5 5.6 Integration and Testing 0 8 8 5.7 System Testing 5 5 5 Applicable clauses 5.8 Release 4 8 8 6 Software Maintenance 8 8 8 per class 6.1 Establish Software Maintenance Plan 1 1 1 6.2 Problem and Modification Analysis 5 5 5 6.3 Modification Implementation 2 2 2 7 Software Risk Management 1 12 12 7.1 Analysis of software contributing to Hazards 0 5 5 7.2 Risk Control Measures 0 2 2 7.3 Verification of Risk Control Measures 0 2 2 7.4 Risk Management of Software Changes 1 3 3 8 Software Configuration Management 7 7 7 8.1 Configuration Identification 3 3 3 8.2 Configuration Control 4 4 4 8.3 Configuration Status Accounting 1 1 1 9 Software Problem Resolution 8 8 8 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 16 Differences classification mostly in development
• Class A • no architectural design • No detailed design • No unit verification testing • No integration testing • No evaluation of known residual anomalies • Class B • No detailed design
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 17 SW Classification process in the IEC62304
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 18 Inheritance of safety class
SW System C
SW Item SW Item SW Unit A B C
SW Unit SW Unit SW Unit SW Unit A A B B
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 19 SW Classification process in the IEC62304
• By default the whole SW system is class C • You may use class A only if……(Quote from DEKRA notified body): SW Classification process
• Perform the system risk analysis according to ISO14971 • Have the SW architecture defined • Filter out all hazards that have a SW component failure as source • Filter out all hazards that have SW component as control measure • Classify those SW components based on the severity of the hazard • If a HW control measure is defined, the classification can degrade
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 21 Example – surgical robotic system – initial assessment • The system manipulates an instrument inside the organ. The software of the system has full control over this manipulation and can cause serious injuries. Therefore, the software system as a whole is treated as safety class C, with certain subsystems having a lower safety class A. • All complexity and safety-critical aspects are centered in one subsystem. • Application Software subsystem – Class C Includes state control, robotic motion control and a safety layer. The state control controls the states of the system. The robotic motion control controls the manipulation motion of the surgical instrument • Service SW subsystem – Class A • User Interface (GUI) SW subsystem – Class A • Firmware (FW) Software subsystem – Class A
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 22 Example Lung function measuring device – full assessment measure, calculate and present lung function parameters without any diagnosis.
NO FORCED EXHALATION IS REQUIRED AS IN SPIROMETRY; PULMONARY FUNCTION VALUES ARE OBTAINED DURING TIDAL BREATHING both the single occlusion technique (SOT) and the interrupter technique (RINT) can be done. In addition, tidal flow volume (TFV) loops can be monitored and analysed Example Lung function measuring device
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 24 Example Lung function measuring device
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 25 Example Lung function measuring device
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 26 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 27 Example Lung function measuring device
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 28 Example Lung function measuring device
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 29 What I have seen gone wrong
• Not implementing IEC62304 for class A software • System risk analysis NOT used as input • No proper rationale why SW is A or B • Assigning SW classification without SW architecture • IEC62304 classification made equal to FDA Level of concern
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 30 Implementation of the IEC62304
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 31 Implementation of IEC62304
• Go through the standard, clause by clause • Adapt your software process accordingly • Adapt your software templates and checklists accordingly • Adapt your software environment accordingly (version control, coding checkers, ….)
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 32 Example software requirement template
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 33 The ultimate compliance check
• Fill the TRF for IEC62304 a.s.a.p. in the project
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 34 Outsource your software development?
• If you outsource…….. • Select your supplier based on • Prooven experience with medical device software • With at least class B development
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 35 What I have seen gone wrong
• IEC62304 implementation in QMS not detailed out • IEC62304 TRF filled in only at the end of the project (needed for submission to the notified body) • No static or dynamic code checkers at all • Outsource based on time/money not on software competence
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 36 The IEC62304 step by step
General Requirements Software Development Software Risk Management Software Configuration Management Software Problem Resolution Software Maintenance
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 37 4 - General requirements
• Have a quality system (also a demand from MDR) Article 10 MDR Manufacturers of devices, other than investigational devices, shall establish, document, implement, maintain, keep up to date and continually improve a quality management system that shall ensure compliance with this Regulation in the most effective manner and in a manner that is proportionate to the risk class and the type of device. • Have a risk management process conform ISO14971 • Assign a software safety class depending on the effects of a hazard to which the software system can contribute. A. no injury B. non-serious injury C. Death or serious injury
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 38 5 – SW development
• SW development planning • SW requirements analysis • SW architectural design • SW detailed design • SW unit implementation and verification • SW integration and integration testing • SW system testing • SW releases
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 39 System V-model Project Plan Verification & Intended Use Valildation Plan Clinical Claims User System Product requirements Validation Release
Basic Safety Essential Performance System System Technical Claims Requirements Verification
System Safety Related System Architecture & Requirements Integration Test Design
Component Component Risk Management File Requirements Verification Usability Engineering File
Component Component Designs Integration Tests
Implementation Code debugging
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 40 Requirements traceability
User Needs Intended Use & claims System Validation Report
System Requirements System
e Product Standards l
i Verification Report F
t n e m
e (Integration) Test g
a System Design
n Report a M
k s i R
Detailed Requirements Detailed Verification Report
Implementation Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 41 5.1 - SW development plan containing • Used processes • All deliverables (includes documentation) • Traceability between system requirements, SW requirements, SW system test, and SW risk control measures • SW configuration and change management • Define when configuration management starts for specific items [B,C] (at least prior to verification). • Link to system requirements and system V&V including procedures • Standards, methods and tools [C] • Integration and integration testing [BC] • Verification • SW Risk Management • SCM planning • Ensure supporting items are controlled [BC] • Procedure for Identification and avoidance of common software defects [BC]
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 42 New in edition 1.1 Identification and Avoidance of Common SW Defects
• Include in SW development plan a procedure to [BC] • identify categories of defects that may be introduced based on programming technology and • document evidence that these defects do not contribute to unacceptable risk • Annex B of IEC TR 80002-1:2009 gives examples 5. 1 - How many plans?
INC1 INC2 INC3 Combine?
Project plan
SW development plan
SW configuration management plan
Increment plan Increment plan Increment plan
SW Integration plan
SW Verification plan
Tool validation plan
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 44 5.2 – SW Requirement analysis • Define SW requirements from system requirements • Content • Verify (make part of peer review focus points) • Make risk control measures part of SW requirements [BC] • Re-evaluate after approved SW requirement: • System Risk Analysis • Existing requirements (f.i. system )
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 45 5.3 – Architecture [BC]
• Transform SW requirements into architecture • Content • SW structure • Identification of SW items • Interfaces • SOUP functional and performance reqs including required HW & SW • Required segregation for risk control [C] • Verify (make part of documented peer review)
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 46 5.4 – Detailed design [BC]
• Subdivide software until represented by SW units [BC] • Develop unit design [C] • Content • Any interface between SW Unit and external components HW or SW • Any interface between SW Units • Both detailed enough to implement each SW Unit and its interfaces correctly. • Verify (make part of documented peer review) [C]
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 47 5.5 – Unit implementation and verification • Implement • Establish SW unit verification process [BC] • Strategies, methods and procedures for verifying the SW Units. • Where verification is done by testing, the test procedures shall be evaluated for adequacy (e.g. by peer review) • Establish acceptance criteria for SW units prior to integration into larger SW items • More criteria for [C]
• Execute SW unit verification incl. reports [BC]
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 48 5.6 – Integration & testing [BC]
• Integrate according integration plan • Inspect (and record) that integration is done according plan • Test integrated SW according integration plan and record results:
• Evaluate integration test procedures for adequacy • Use regression testing at every integration • Use problem resolution for defects found
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 49 5.7 – System testing
• Evaluate adequacy of test strategies & procedures • Cover all SW requirements by SW system tests • Test records
• Use problem resolution process • Regression test after changes (+risk management) • Evaluate process
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 50 5.8 Software release
• Check all verifications are completed and results evaluated before release, see last bullet prev sheet • Document and evaluate (no contribution to unacceptable risk) known bugs • Document • Released versions • Release procedures and environment used to release [BC] • Ensure all tasks from plans are complete including documentation [BC] • Archive configuration items [BC] • Assure reliable delivery to point of use
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 51 7 – SW Risk management part of system RMF
1. Risk management plan (include SW risk management) 2. Risk analysis (table with hazard, cause, severity, probability, risk) 3. Risk control measures (part of requirements) 4. Risk Management Report (summary report)
Comply to ISO14971
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 52 7 – SW Risk management
• Identify SW items that could contribute to a hazardous situation • Identify potential causes. For SOUP, evaluate anomaly list [B,C]. • Define Risk Control Measures. Control measures implemented in SW must be included in the requirements [B,C]. • Verify Risk Control measures [B,C] • Assess risk management impact of changes
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 53 7.1 - SW Risk management – potential causes
Failed high level Hazardous Harm function / Faulty SW item situation requirement
Subsystem Risk System Risk Analysis Analysis
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 54 7.4 – SW Risk management – SW changes
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 55 Goal: recreate a SW item, to identify its 8 – SW Configuration management constituent parts, and to provide a history of the changes that have been • Define Configuration items made to it. • Define identification of configuration items + versions to be controlled according to planning, see 5.1 • Identify SOUP • Baselining • Status accounting • Maintain old versions of configuration items • Organize change control. • Approve – Implement – Verify • Ensure traceability.
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 56 8 - Configuration items: also documentation
Requirements Test Spec SW System Design Test Report
Requirements Test Spec
Design Test Report SW Item SW Item SW Unit
Requirements Test Spec Requirements Test Spec
Design Test Report Design Test Report
SW Unit SW Unit SW Unit SW Unit
Requirements Test Spec Requirements Test Spec Requirements Test Spec Requirements Test Spec
Design Test Report Design Test Report Design Test Report Design Test Report
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 57 8 - Traceability
• Implement above e.g. via trace tables
• Implement above e.g. via risk analysis table 8 - Product lifecycle
Released Verification Upgrade after product baseline 2 years baseline
For every version of each document: • Write / update • Peer review • Formal review • Approval
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 59 9 - SW Problem Resolution
UNIT DEV. SYSTEM DEV. RELEASE
Unit Integration Verification Validation Use testing testing testing testing
Not defined 5.7.2 6.2.2 Not 5.6.8 required PROBLEM Goal: ensure that REPORTING problems found during development and maintenance are analyzed and resolved and that Regression Testing trends are recognized
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 60 9 – SW Problem Resolution • Investigate • Evaluate impact on performance, safety or security • Evaluate risk analysis and software class (update RMF if needed) • Include info like devices affected, supported accessories affected • Identify cause if possible • Advise to relevant parties if needed on existence of problem e.g. users, regulators • Analyze problems for trends • Verify • PR resolved • No new problems introduced • Adverse trends are reversed.
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 61 Goal: respond to (urgent) field 6 – SW maintenance problems and (user) change requests and preserve the SW integrity after the change • Define maintenance plan • Gather input via a feedback process (typically Post Market Surveillance procedure) • Use software risk management, CR/PR and SCM processes • Have a procedure for SOUP upgrades/fixes/patches / obsolescence • CR/PR analysis and implementation (see section 9.) • Impact on organization • Impact on other SW parts and interface systems (use regression tests) • Impact on safety and adverse event analysis • Re-evaluate risk analysis and software class • Implement via software development process • Communicate changes to users and regulators
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 62 SOUP (Software Of Unknown Provenance “herkomst) Unknown Pedigree (“stamboom”)
For US market access, follow
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 63 SOUP characteristics
• It already exists • It cannot be re-engineered by the user • It is generic and is likely to contain functions that are unnecessary for the system application • It is often subject to continuous change (OTS) • There is no evidence of the controls on the development process
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 64 SOUP risks
• SOUP is by definition deemed to be capable of producing faults. • Carry out a software risk analysis on any SOUP item and justify why use of the item is acceptable. • Consider both • Risks related to the functions of the SOUP • Risks related to the influence of SOUP on other software and hardware
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 65 SOUP and IEC62304 classes
• a Class A SOUP item: • just use it with the basic controls • a Class B SOUP item: • strong rationale for using it • a Class C SOUP item: • strong rationale for using it • Only simple functions, well known and diversely applied
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 66 SOUP documentation
• SOUP Identification and Configuration item • SOUP Requirements (functional, performance, environment) • HW and SW necessary to support the proper operation of SOUP • Architecture supports proper operation of SOUP • Risk analysis • Integration and test planning • Build plans, release notes, etc. • Procedure to upgrade, bug fix, patch and obsolescence SOUP • SOUP bug reports
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 67 Audit report example • 5.1.5, Software integration and integration testing planning - lacking in the reviewed documentation • 5.1.7, Software Risk Management Planning - lacking in the reviewed documentation • 5.1.8, Documentation planning - incomplete. Provided Excel did not list all relevant documentation • 5.6, Integration Testing - Test plan not in Master Plan. Specific documents/reports not called out in the test plan • 7.1.2, Identify potential causes of contribution to a hazardous situation - inadequate risk management process • 7.1.3, Evaluate published SOUP anomaly lists - not done • 7.2.1, Define risk control measures - SOUP not included • 7.3.2, Document any new sequences of events - potential problems still not integrated – e.g. division by 0. Inadequate documentation of changes and reassessment of risk • 7.4.1, Analyze changes to medical device software with respect to safety – not done • 8.1.2 Identify SOUP - not done yet • 8.2, Change Control - not properly documented or implemented. Only changes to requirements, not all identified problems, automatically trigger change control process
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 68 QUIZ – TRUE or FALSE 1. The IEC62304 must be used in combination with the ISO14971 2. Software validation is covered by the IEC60601-1 3. The classification of a software system is by default A 4. A HW control measure may degrade a SW classification from B to A 5. A IEC62304 compliance report is part of the CE submission 6. For class B&C unit designs are to be developed 7. A trace is required between SW requirement and the SW system tests 8. For each defect found during unit testing a problem report has to be submitted 9. Software that is developed not according to IEC62304 is to be considered as SOUP
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 69 QUIZ – TRUE or FALSE 1. The IEC62304 must be used in combination with the ISO14971 → TRUE 2. Software validation is covered by the IEC60601-1 → TRUE 3. The classification of a software system is by default A → FALSE, C 4. A HW control measure may degrade a SW classification from B to A → TRUE 5. A IEC62304 compliance report is part of the CE submission → TRUE 6. For class B&C unit designs are to be developed → FALSE only for C 7. A trace is required between SW requirement and the SW system tests → T 8. For each defect found during unit testing a problem report has to be submitted → F, is not mandatory, is mandatory for system level testing 9. Software that is developed not according to IEC62304 is to be considered as SOUP → TRUE
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 70 Next steps
• Define user requirements (incl. intended use & clinical claims) • Define system requirements • Define system architecture • Start system risk assessment • Define software requirements & software architecture • Define software classes • Implement IEC62304 based on the classes
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 71 Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 72 Backup slides
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 73 Relation with IEC82304 Health Software
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 74 Scope IEC62304 versus IEC82304
Process Vision IEC62304 Medical Device Software – Life Cycle processes Sheet 75