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 Medical Device
IEC 60601-1-2 EMC Regulatory
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 Medical Electrical Equipment
IEC82304 IEC60601-1
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. MANUFACTURER to be used as a MEDICAL
Reference
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
Hazards Timing, budget
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 Release Notes
File
Reviews
Requirements
User Manual
Risk / Benefit Problem Reports
Control
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

Applicable clauses 5.7

5.8
System Testing
Release
5
4
5
8
5
8

per class 6 Software Maintenance

6.1 Establish Software Maintenance Plan
8
1
8
1
8
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

Safety Related System

System
Requirements Architecture &
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
Risk Management File

System
Product Standards
Verification Report

(Integration) Test
System Design Report

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
Verification Released
Upgrade after
baseline product
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
5.7.2 Not defined
5.6.8 6.2.2
Not
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