IEC/DIS 62304.3

Health software -- Software life cycle processes

Logiciels de santé -- Processus du cycle de vie du logiciel

Standards Content (sample)

DRAFT INTERNATIONAL STANDARD
IEC/DIS 62304.3
ISO/TC 215 Secretariat: ANSI
Voting begins on: Voting terminates on:
2021-01-01 2021-03-26
Health software — Software life cycle processes
Logiciels de santé — Processus du cycle de vie du logiciel
ICS: 11.040.01; 35.240.80
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
This document is circulated as received from the committee secretariat.
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
This draft is submitted to a parallel vote in ISO and in IEC.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
IEC/DIS 62304.3:2021(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION. IEC 2021
---------------------- Page: 1 ----------------------
IEC/DIS 62304.3:2021(E)
ii © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
IEC/DIS 62304.3:2021(E)
1 CONTENTS

3 FOREWORD ........................................................................................................................................... 6

4 INTRODUCTION ..................................................................................................................................... 9

5 1 Scope ............................................................................................................................................ 11

6 1.1 * Purpose ............................................................................................................................. 11

7 1.2 * Field of application ............................................................................................................ 11

8 1.3 Relationship to other standards ........................................................................................... 12

9 2 * Normative references .................................................................................................................. 12

10 3 * Terms and definitions .................................................................................................................. 13

11 4 * General requirements ................................................................................................................. 21

12 4.1 * Quality management ......................................................................................................... 21

13 4.2 * RISK MANAGEMENT .............................................................................................................. 21

14 4.3 Conformance ....................................................................................................................... 21

15 4.4 Software process rigor level ................................................................................................ 22

16 4.5 * LEGACY SOFTWARE ............................................................................................................. 25

17 5 Software development PROCESS ................................................................................................... 26

18 5.1 * Software development planning ........................................................................................ 26

19 5.2 * Software requirements analysis ........................................................................................ 29

20 5.3 * Software ARCHITECTURAL design ....................................................................................... 31

21 5.4 * Software detailed design ................................................................................................... 32

22 5.5 * SOFTWARE UNIT implementation ........................................................................................ 33

23 5.6 * Software integration and integration testing ...................................................................... 33

24 5.7 * SOFTWARE SYSTEM testing ................................................................................................. 35

25 5.8 * Software release ............................................................................................................... 36

26 6 SOFTWARE MAINTENANCE PROCESS ................................................................................................. 37

27 6.1 * Establish SOFTWARE MAINTENANCE plan............................................................................. 37

28 6.2 * Problem and modification analysis ................................................................................... 38

29 6.3 * Modification implementation.............................................................................................. 39

30 7 * Software RISK MANAGEMENT PROCESS ......................................................................................... 39

31 7.1 * Analysis of software contributing to HAZARDOUS SITUATIONS ............................................. 39

32 7.2 RISK CONTROL measures ...................................................................................................... 40

33 7.3 VERIFICATION of RISK CONTROL measures ............................................................................ 40

34 7.4 RISK MANAGEMENT of software changes ............................................................................... 41

35 8 * Software configuration management PROCESS ........................................................................... 41

36 8.1 * Configuration identification ................................................................................................ 41

37 8.2 * Change control .................................................................................................................. 42

38 8.3 * Configuration status accounting ........................................................................................ 42

39 9 * Software problem resolution PROCESS ........................................................................................ 42

40 9.1 Prepare PROBLEM REPORTS .................................................................................................. 42

41 9.2 Investigate the problem ....................................................................................................... 43

© IEC 2021 – All rights reserved
---------------------- Page: 3 ----------------------
IEC/DIS 62304.3:2021(E)

42 9.3 Advise relevant parties ........................................................................................................ 43

43 9.4 Use change control PROCESS .............................................................................................. 43

44 9.5 Maintain records .................................................................................................................. 43

45 9.6 Analyse problems for trends ................................................................................................ 43

46 9.7 Verify software problem resolution ...................................................................................... 43

47 9.8 Test documentation contents .............................................................................................. 44

48 Annex A (informative) Rationale for the requirements of this document .............................................. 45

49 Annex B (informative) Guidance on the provisions of this document................................................... 48

50 Annex C (informative) Relationship to other standards ........................................................................ 74

51 Annex D (informative) Implementation ................................................................................................. 96

52 Bibliography ........................................................................................................................................... 98

53 Annex ZA (informative) Relationship between this European standard and the General Safety

54 and Performance Requirements of Regulation (EU) 2017/745 aimed to be covered................. 101

56 Figure 1 – Overview of software development and maintenance PROCESSES and ACTIVITIES .............. 10

57 Figure 2 – HEALTH SOFTWARE field of application .................................................................................. 11

58 Figure 3 – Assigning software process rigor level ................................................................................. 24

59 Figure B.1 – Relation between HAZARD, HAZARDOUS SITUATION, HARM and SECURITY terminology ........ 52

60 Figure B.2 – Pictorial example of the relationship of HAZARD, sequence of events, HAZARDOUS

61 SITUATION, and HARM .............................................................................................................................. 53

62 Figure B.3 – Pictorial representation of the relationship of RISK MANAGEMENT (ISO 14971:2019

63 Figure 1) and software process rigor level ............................................................................................ 54

64 Figure B.4 – Determining software process rigor level in steps ............................................................ 55

65 Figure B.5 – SOFTWARE SYSTEM contributing to HAZARDOUS SITUATIONS ............................................... 57

66 Figure B.6 – SOFTWARE SYSTEM contributing to HAZARDOUS SITUATIONS with RISK CONTROL

67 measures ............................................................................................................................................... 58

68 Figure B.7 – Example of partitioning of SOFTWARE ITEMS ...................................................................... 65

69 Figure B.8 – Interaction between software problem resolution and software configuration

70 management .......................................................................................................................................... 72

71 Figure C.1 – Relationship of key MEDICAL DEVICE standards to this document ..................................... 75

72 Figure C.2 – Software as part of the V-model ....................................................................................... 79

73 Figure C.3 – Application of IEC 62304 with IEC 61010-1 ..................................................................... 87

74 Figure C.4 – Relationship between IEC 82304-1 and IEC 62304 ......................................................... 88

76 Table A.1 – Summary of requirements by software SAFETY class ......................................................... 47

77 Table B.1 – Development (model) strategies as defined in ISO/IEC 12207 .......... Error! Bookmark not

78 defined.

79 Table B.2 – Analysis of HAZARDOUS SITUATIONS .................................................................................... 56

80 Table B.3 – Identification of HAZARDOUS SITUATIONS with external RISK CONTROL measure .................. 58

81 Table B.4 – Identification of HAZARDOUS SITUATIONS with software SAFETY classification ...................... 60

82 Table C.1 – Useful SECURITY standards ................................................................................................ 76

© IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
IEC/DIS 62304.3:2021(E)

83 Table C.2 – Relationship to ISO 13485:2016 ........................................................................................ 77

84 Table C.3 – Relationship to ISO 14971:2019 ........................................................................................ 78

85 Table C.4 – Relationship to IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012 ........................... 80

86 Table C.5 – Relationship to ISO/IEC 12207:2017 ................................................................................. 90

87 Table D.1 – Checklist for small companies without a certified QMS ..................................................... 97

88 Table ZA.1 – Correspondence between this document and Annex I of Regulation (EU)

89 2017/745 [OJ L 117] ............................................................................................................................ 101

90 Table ZA.2 – Relevant Essential Health and SAFETY Requirements from Directive 2006/42/EC

91 on machinery that are addressed by this Document (according to article 1, item 12, of

92 Regulation (EU) 2017/745) .................................................................................................................. 102

© IEC 2021 – All rights reserved
---------------------- Page: 5 ----------------------
IEC/DIS 62304.3:2021(E)
96 INTERNATIONAL ELECTROTECHNICAL COMMISSION
97 ____________
99 HEALTH SOFTWARE –
100 SOFTWARE LIFE CYCLE PROCESSES
101
102 FOREWORD

103 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national

104 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all

105 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC

106 publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and

107 Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC

108 National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental

109 and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with

110 the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between

111 the two organizations.

112 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus

113 of opinion on the relevant subjects since each technical committee has representation from all interested IEC National

114 Committees.

115 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in

116 that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC

117 cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.

118 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to

119 the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and

120 the corresponding national or regional publication shall be clearly indicated in the latter.

121 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment

122 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by

123 independent certification bodies.

124 6) All users should ensure that they have the latest edition of this publication.

125 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its

126 technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature

127 whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of,

128 or reliance upon, this IEC Publication or any other IEC Publications.

129 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable

130 for the correct application of this publication.

131 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights.

132 IEC shall not be held responsible for identifying any or all such patent rights.

133 International Standard IEC 62304 has been prepared by a joint working group of subcommittee

134 62A: Common aspects of electrical equipment used in medical practice, of IEC technical

135 committee 62: Electrical equipment in medical practice,in cooperation with ISO Technical

136 Committee 215, Health informatics. Table C.5 was prepared by ISO/IEC JTC 1/SC 7, Software

137 and systems engineering.
138 It is published as a dual logo standard.

139 This second edition cancels and replaces the first edition published in 2006 and

140 Amendment 1:2015. This edition constitutes a technical revision.

141 This edition includes the following significant technical changes with respect to the previous

142 edition:
143 a) the scope of this document has been expanded to HEALTH SOFTWARE;
© IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
IEC/DIS 62304.3:2021(E)

144 b) Clause 4 related to general requirements has been updated to assure that this document would

145 meet the state of art of the use-environment and the way that HEALTH SOFTWARE is being used.

146 The text of this International Standard is based on the following documents:
FDIS Report on voting
62A/XX/FDIS 62A/XX/RVD
147

148 Full information on the voting for the approval of this International Standard can be found in the

149 report on voting indicated in the above table.

150 This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

151 In this document, the following print types are used:
152 – requirements and definitions: roman type;

153 – informative material appearing outside of tables, such as notes, examples and references: smaller type.

154 Normative text of tables is also in a smaller type;

155 – TERMS USED THROUGHOUT THIS DOCUMENT THAT HAVE BEEN DEFINED IN CLAUSE 3: SMALL CAPITALS.

156 The verbal forms used in this document conform to usage described in Clause 7 of the ISO/IEC

157 Directives, Part 2:2018. For the purposes of this document, the verb:

158 – "shall" means that compliance with a requirement is mandatory for compliance with this document;

159 – "should" means that compliance with a requirement is recommended but is not mandatory for

160 compliance with this document;

161 – "may" is used to describe a permissible way to achieve compliance with a requirement;

162 – "establish" means to define, document and implement.

163 Where this document uses the term "as appropriate" in conjunction with a required PROCESS, ACTIVITY,

164 TASK or output, the intention is that the MANUFACTURER shall use the PROCESS, ACTIVITY, TASK or output

165 unless the MANUFACTURER can document a justification for not so doing.

166 An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that

167 there is guidance related to that item in Annex B.

168 The committee has decided that the contents of this document will remain unchanged until the

169 stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to

170 the specific document. At this date, the document will be
171 • reconfirmed,
172 • withdrawn,
173 • replaced by a revised edition, or
174 • amended.

175 NOTE The attention of users of this document is drawn to the fact that equipment MANUFACTURERS and testing organizations

176 may need a transitional period following publication of a new, amended or revised IEC or ISO publication in which to make

177 products in accordance with the new requirements and to equip themselves for conducting new or revised tests. It is the

178 recommendation of the committee that the content of this publication be adopted for mandatory implementation nationally not

179 earlier than 3 years from the date of publication.
180
© IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
IEC/DIS 62304.3:2021(E)

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates that it contains

colours which are considered to be useful for the correct understanding of its contents. Users should

therefore print this document using a colour printer.
181
182
© IEC 2021 – All rights reserved
---------------------- Page: 8 ----------------------
IEC/DIS 62304.3:2021(E)
183 INTRODUCTION

184 Software is becoming increasingly important in healthcare. The use of software can help

185 contribute to more efficient and safe care of patients. Thus, HEALTH SOFTWARE needs to be

186 developed with appropriate controls to ensure its safe, effective and secure use.

187 Users of software in the care environment have expanded from clinical users (nurses,

188 technicians, dieticians, physicians, etc.) to include non-clinical users (patients, consumers,

189 laypersons, family care givers, etc.). IEC 62304:2006 and IEC 62304:2006/AMD1:2015 focused

190 on software life cycle activities for MEDICAL DEVICE SOFTWARE that was primarily used by clinical

191 users. For this reason, the scope of this document has been expanded to HEALTH SOFTWARE.

192 As software becomes more dependent on network connectivity and integral to clinical workflows,

193 additional considerations need to be made for SECURITY and USABILITY. HEALTH SOFTWARE is

194 being used more commonly in the home and outside of the hospital, so it becomes even more

195 important to develop these products with the user and use environment in mind. For these

196 reasons, Clause 4 related to general requirements has been updated to assure that this

197 document would meet the state of art of the use-environment and the way that HEALTH SOFTWARE

198 is being used.

199 This document does not duplicate well-established requirements from standards for USABILITY

200 and SECURITY.

201 Establishing the SAFETY and EFFECTIVENESS of HEALTH SOFTWARE requires knowledge of what

202 the HEALTH SOFTWARE is intended to do and demonstration that the use of the HEALTH SOFTWARE

203 fulfils those intentions without causing any unacceptable RISKS. To demonstrate the

204 EFFECTIVENESS, software VALIDATION is required, which is outside of the scope of this document.

205 The MANUFACTURER of HEALTH SOFTWARE is responsible for determining and complying with the

206 appropriate SAFETY, SECURITY, environmental, health, and interference protection practices.

207 Many laws, regulations, and other rules from authorities having jurisdiction have a direct impact

208 on the way SOFTWARE SYSTEMS are developed, tested, and maintained. From a software

209 development perspective, MANUFACTURERS consider these laws, regulations, and other rules as

210 inputs into the requirements that the HEALTH SOFTWARE supports. This means that the

211 requirements of some laws or regulations can translate into specific HEALTH SOFTWARE product

212 requirements. For example, if HEALTH SOFTWARE is going to send or share health data to a doctor,

213 hospital, or other covered entity, it has an obligation to adhere to privacy and SECURITY rules.

214 This can involve authentication and SECURITY mechanisms to protect patient information saved

215 in an electronic format. Other requirements of the laws or regulations can impact the PROCESS

216 used during the development of the HEALTH SOFTWARE product. For example, many national

217 regulations and quality systems standards have design control requirements that translate into

218 specific procedures to confirm that the product is designed, verified, and validated in a

219 systematic manner and per proven software engineering practices.

220 This document specifies that MANUFACTURERS develop and maintain HEALTH SOFTWARE within a

221 quality management SYSTEM (see 4.1) and a RISK MANAGEMENT SYSTEM (4.2).

222 This document provides a framework for a life cycle PROCESS. It defines the ACTIVITIES and

223 TASKS necessary for the safe design, development and maintenance of HEALTH SOFTWARE. The

224 development and maintenance life cycle ACTIVITIES are shown in Figure 1 and described in

225 Clause 5 and Clause 6. Some incidents in healthcare delivery are related to HEALTH SOFTWARE

226 SYSTEMS, including failures that can occur or be injected when software is modified.

© IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
IEC/DIS 62304.3:2021(E)
Customer
Customer
needs
Maintenance Request
needs
satisfied
request satisfied

Product development and maintenance activities (e.g., intended use, risk management, system requirements, validation,

information for users)

62304 Software Life Cycle Processes and Activities
9.0 Problem Resolution Process
8.0 Configuration Management Process
4.0 General
7.0 Software Risk Management Process
requirements
(infrastructure processes)
5.0 Development Process
4.1 Quality system
5.1 Software development
planning
5.2 Software requirements
4.2 Risk management
analysis
6.0 Maintenance Process
(safety and security)
5.3 Software architectural 6.1 Establish software maintenance
design plan
4.3 Conformance
6.2 Problem and modification
5.4 Software detailed design
analysis
5.5 Software unit
6.3 Modification implementation
implementation
4.4 Process rigor level
5.6 Software integration and
integration testing
4.5 Legacy software
5.7 Software system testing
5.8 Software release
227

228 Figure 1 – Overview of software development and maintenance PROCESSES and ACTIVITIES

229 This document identifies two additional supporting PROCESSES considered essential for

230 developing safe HEALTH SOFTWARE. They are the software configuration management PROCESS

231 (Clause 8) and the software problem resolution PROCESS (Clause 9).

232 This document does not specify a specific organizational structure nor responsibilities within

233 the organization of the MANUFACTURER to perform PROCESSES, ACTIVITIES, and TASKS. This

234 document specifies planning of software development, maintenance and supporting PROCESS

235 ACTIVITIES, and the completion of the ACTIVITIES or TASKS for conformance with this document.

236 This document does not prescribe the name, format, or explicit content of the documentation to

237 be produced. This document calls for adequate evidence of required ACTIVITIES and TASKS by

238 documentation. Regardless how content is structured and packaged, it is expected that a

239 controlled documentation PROCESS is in place. This document does not prescribe a specific life

240 cycle model. The users of this document are responsible for selecting a life cycle model for the

241 software project and for mapping the PROCESSES, ACTIVITIES, and TASKS in this document onto

242 that model.Annex A provides rationale for the clauses of this document. Annex B provides

243 guidance on the provisions of this document.
244
© IEC 2021 – All rights reserved
---------------------- Page: 10 ----------------------
IEC/DIS 62304.3:2021(E)
245 HEALTH SOFTWARE –
246 SOFTWARE LIFE CYCLE PROCESSES
247
248 1 Scope
249 1.1 * Purpose

250 This document defines the development and maintenance life cycle requirements for HEALTH

251 SOFTWARE. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes

252 a common framework for HEALTH SOFTWARE life cycle PROCESSES.
253 1.2 * Field of application

254 This document applies to the development and maintenance of HEALTH SOFTWARE by a

255 MANUFACTURER. MEDICAL DEVICE SOFTWARE is a subset of HEALTH SOFTWARE (see Figure 2).

256 Therefore, this document applies to:
257 – software as part of a MEDICAL DEVICE;
258 – software as part of specific health hardware;
259 – software as a MEDICAL DEVICE (SaMD);
260 – software-only product for other health use.

261 Figure 2 provides a graphical representation of the health software this document applies to.

HEALTH SOFTWARE
MEDICAL
DEVICE
Software as
software
Software as
part of
part of a
specific
MEDICAL DEVICE
For specific
health
hardware
hardware
For general
Software as
computing Software-only
a MEDICAL
platform product for
DEVICE
other
(SaMD)
health use
MEDICAL DEVICE use Other health use
262
263 Figure 2 – HEALTH SOFTWARE field of application
264 NOTE 1 Examples of HEALTH SOFTWARE include the following:

265 1) software as a part of a MEDICAL DEVICE: software that is an integral part of a device such as an infusion pump or dialysis

266 machine.

267 2) software as part of specific health hardware: patient wristband printer software, healthcare scanner software, health app on

268 specific wearable hardware (i.e. watch, wristband, chestband).
© IEC 2021 – All rights reserved
---------------------- Page: 11 ----------------------
IEC/DIS 62304.3:2021(E)

269 3) software as a MEDICAL DEVICE (SaMD): software that is itself a MEDICAL DEVICE, such as a software application that performs

270 diagnostic image analysis for making treatment decisions. A definition of software as a MEDICAL DEVICE is provided in [46] .

271 4) software-only product for other health use: hospital information systems, electronic health records, electronic medical

272 records, mobile applications running on devices without physiologic sensors or detectors, software as a service, i.e.

273 software executed in an external environment, providing calculation-results that fulfil the definition of a

...

DRAFT INTERNATIONAL STANDARD
IEC/DIS 62304
ISO/TC 215 Secretariat: ANSI
Voting begins on: Voting terminates on:
2019-10-04 2019-12-27
Health software — Software life cycle processes
Logiciels de santé — Processus du cycle de vie du logiciel
ICS: 11.040.01; 35.240.80
Member bodies are requested to consult relevant national interests in IEC/SC
62A before casting their ballot to the e-Balloting application.
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
This document is circulated as received from the committee secretariat.
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
IEC/DIS 62304:2019(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION. IEC 2019
---------------------- Page: 1 ----------------------
IEC/DIS 62304:2019(E)
ii © ISO/IEC 2019 – All rights reserved
---------------------- Page: 2 ----------------------
IEC/DIS 62304:2019(E)
62A/1349/CDV – 4 – IEC CDV 62304 © IEC 2019
1 CONTENTS

3 FOREWORD ........................................................................................................................... 6

4 INTRODUCTION ..................................................................................................................... 8

5 1 Scope ............................................................................................................................ 11

6 1.1 * Purpose .............................................................................................................. 11

7 1.2 * Field of application ............................................................................................. 11

8 1.3 Relationship to other standards ............................................................................. 12

9 1.4 Conformance ........................................................................................................ 12

10 2 * Normative references .................................................................................................. 12

11 3 * Terms and definitions .................................................................................................. 13

12 4 * General requirements .................................................................................................. 19

13 4.1 * Quality management ........................................................................................... 19

14 4.2 * RISK MANAGEMENT................................................................................................ 19

15 4.3 * USABILITY engineering ......................................................................................... 20

16 4.4 * Software safety classification.............................................................................. 20

17 4.5 * LEGACY SOFTWARE ............................................................................................... 22

18 5 Software development PROCESS ..................................................................................... 24

19 5.1 * Software development planning .......................................................................... 24

20 5.2 * Software requirements analysis .......................................................................... 26

21 5.3 * Software ARCHITECTURAL design .......................................................................... 29

22 5.4 * Software detailed design .................................................................................... 29

23 5.5 * SOFTWARE UNIT implementation .......................................................................... 30

24 5.6 * Software integration and integration testing ........................................................ 31

25 5.7 * SOFTWARE SYSTEM testing ................................................................................... 32

26 5.8 * Software release ................................................................................................ 33

27 6 SOFTWARE MAINTENANCE PROCESS .................................................................................. 34

28 6.1 * Establish SOFTWARE MAINTENANCE plan ............................................................... 34

29 6.2 * Problem and modification analysis ...................................................................... 35

30 6.3 * Modification implementation ............................................................................... 36

31 7 * Software RISK MANAGEMENT PROCESS ........................................................................... 36

32 7.1 * Analysis of software contributing to HAZARDOUS SITUATIONS ................................. 36

33 7.2 RISK CONTROL measures ........................................................................................ 37

34 7.3 VERIFICATION of RISK CONTROL measures ............................................................... 38

35 7.4 RISK MANAGEMENT of software changes ................................................................. 38

36 8 * Software configuration management PROCESS ............................................................. 39

37 8.1 * Configuration identification ................................................................................. 39

38 8.2 * Change control ................................................................................................... 39

39 8.3 * Configuration status accounting .......................................................................... 40

40 9 * Software problem resolution PROCESS ......................................................................... 40

41 9.1 Prepare PROBLEM REPORTS .................................................................................... 40

42 9.2 Investigate the problem ......................................................................................... 40

43 9.3 Advise relevant parties.......................................................................................... 40

44 9.4 Use change control PROCESS................................................................................. 41

45 9.5 Maintain records ................................................................................................... 41

46 9.6 Analyse problems for trends .................................................................................. 41

47 9.7 Verify software problem resolution ........................................................................ 41

© IEC 2019 – All rights reserved
---------------------- Page: 3 ----------------------
IEC/DIS 62304:2019(E)
IEC CDV 62304 © IEC 2019 – 5 – 62A/1349/CDV

48 9.8 Test documentation contents ................................................................................ 41

49 Annex A (informative) Rationale for the requirements of this document ................................ 43

50 Annex B (informative) Guidance on the provisions of this document ..................................... 46

51 Annex C (informative) Relationship to other standards ......................................................... 71

52 Annex D (informative) Implementation ................................................................................. 89

53 Bibliography .......................................................................................................................... 91

55 Figure 1 – Overview of software development PROCESSES and ACTIVITIES ................................ 9

56 Figure 2 – Overview of SOFTWARE MAINTENANCE PROCESSES and ACTIVITIES ............................. 9

57 Figure 3 – HEALTH SOFTWARE field of application ................................................................... 11

58 Figure 4 – Assigning software safety classification ................................................................ 21

59 Figure B.1 – Relation between HAZARD, HAZARDOUS SITUATION, HARM and SECURITY

60 terminology ........................................................................................................................... 50

61 Figure B.2 – Pictorial example of the relationship of HAZARD, sequence of events,

62 HAZARDOUS SITUATION, and HARM ........................................................................................... 51

63 Figure B.3 – Pictorial representation of the relationship of RISK MANAGEMENT

64 (ISO 14971:2019 Figure 1) and software safety classification ............................................... 52

65 Figure B.4 – Software classification in steps ......................................................................... 53

66 Figure B.5 – SOFTWARE SYSTEM contributing to HAZARDOUS SITUATIONS .................................. 54

67 Figure B.6 – SOFTWARE SYSTEM contributing to HAZARDOUS SITUATIONS with RISK

68 CONTROL measures ............................................................................................................... 55

69 Figure B.7 – Example of partitioning of SOFTWARE ITEMS ....................................................... 62

70 Figure B.8 – Interaction between software problem resolution and software

71 configuration management .................................................................................................... 69

72 Figure C.1 – Relationship of key MEDICAL DEVICE standards to this document ........................ 71

73 Figure C.2 – Software as part of the V-model ........................................................................ 76

74 Figure C.3 – Application of IEC 62304 with IEC 61010-1 ....................................................... 83

75 Figure C.4 – Relationship between IEC 82304-1 and IEC 62304 ........................................... 84

77 Table A.1 – Summary of requirements by software safety class ............................................ 45

78 Table B.1 – Development (model) strategies as defined in ISO/IEC 12207 ............................ 47

79 Table B.2 – Analysis of HAZARDOUS SITUATIONS ..................................................................... 54

80 Table B.3 – Identification of HAZARDOUS SITUATIONS with external RISK CONTROL

81 measure ............................................................................................................................... 55

82 Table B.4 – Identification of HAZARDOUS SITUATIONS with software safety classification .......... 57

83 Table C.1 – Useful SECURITY standards ................................................................................. 72

84 Table C.2 – Relationship to ISO 13485:2016 ......................................................................... 74

85 Table C.3 – Relationship to ISO 14971:2019 ......................................................................... 75

86 Table C.4 – Relationship to IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012 ............... 77

87 Table C.5 – Relationship to ISO/IEC 12207:2017 .................................................................. 86

88 Table D.1 – Checklist for small companies without a certified QMS ....................................... 90

© IEC 2019 – All rights reserved
---------------------- Page: 4 ----------------------
IEC/DIS 62304:2019(E)
62A/1349/CDV – 6 – IEC CDV 62304 © IEC 2019
91 INTERNATIONAL ELECTROTECHNICAL COMMISSION
92 ____________
93 HEALTH SOFTWARE –
94 SOFTWARE LIFE CYCLE PROCESSES
96 FOREWORD

97 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising

98 all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international

99 co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and

100 in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,

101 Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their

102 preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with

103 may participate in this preparatory work. International, governmental and non-governmental organizations liaising

104 with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for

105 Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

106 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international

107 consensus of opinion on the relevant subjects since each technical committee has representation from all

108 interested IEC National Committees.

109 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National

110 Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC

111 Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any

112 misinterpretation by any end user.

113 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications

114 transparently to the maximum extent possible in their national and regional publications. Any divergence between

115 any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.

116 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity

117 assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any

118 services carried out by independent certification bodies.

119 6) All users should ensure that they have the latest edition of this publication.

120 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and

121 members of its technical committees and IEC National Committees for any personal injury, property damage or

122 other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and

123 expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC

124 Publications.

125 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is

126 indispensable for the correct application of this publication.

127 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent

128 rights. IEC shall not be held responsible for identifying any or all such patent rights.

129 International Standard IEC 62304 has been prepared by a joint working group of subcommittee

130 62A: Common aspects of electrical equipment used in medical practice, of IEC technical

131 committee 62: Electrical equipment in medical practice and ISO Technical Committee 215,

132 Health informatics. Table C.5 was prepared by ISO/IEC JTC 1/SC 7, Software and systems

133 engineering.
134 It is published as a dual logo standard.

135 This second edition cancels and replaces the first edition published in 2006 and

136 Amendment 1:2015. This edition constitutes a technical revision.

137 This edition includes the following significant technical changes with respect to the previous

138 edition:
139 a) the scope of this document has been expanded to HEALTH SOFTWARE;

140 b) the general requirements section has been updated to assure that this document would

141 meet the state of art of the use-environment and the way that HEALTH SOFTWARE is being

142 used.
© IEC 2019 – All rights reserved
---------------------- Page: 5 ----------------------
IEC/DIS 62304:2019(E)
IEC CDV 62304 © IEC 2019 – 7 – 62A/1349/CDV
143 The text of this International Standard is based on the following documents:
FDIS Report on voting
62A/XXXX/FDIS 62A/XXXX/RVD
144

145 Full information on the voting for the approval of this International Standard can be found in the

146 report on voting indicated in the above table.

147 This document has been drafted in accordance with the ISO/IEC Directives, Part 2.

148 In this document, the following print types are used:
149 – requirements and definitions: roman type;

150 – informative material appearing outside of tables, such as notes, examples and references: smaller type.

151 Normative text of tables is also in a smaller type;

152 – TERMS USED THROUGHOUT THIS STANDARD THAT HAVE BEEN DEFINED IN CLAUSE 3: SMALL

153 CAPITALS.

154 The verbal forms used in this standard conform to usage described in Clause 7 of the ISO/IEC

155 Directives, Part 2:2018. For the purposes of this document, the verb:

156 • "shall" means that compliance with a requirement is mandatory for compliance with this

157 document;

158 • "should" means that compliance with a requirement is recommended but is not mandatory

159 for compliance with this document;

160 • "may" is used to describe a permissible way to achieve compliance with a requirement;

161 The term "establish" means to define, document, and implement.

162 Where this document uses the term "as appropriate" in conjunction with a required PROCESS,

163 ACTIVITY, TASK or output, the intention is that the MANUFACTURER shall use the PROCESS, ACTIVITY,

164 TASK or output unless the MANUFACTURER can document a justification for not so doing.

165 An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that

166 there is guidance related to that item in Annex B.

167 The committee has decided that the contents of this document will remain unchanged until the

168 stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related to

169 the specific document. At this date, the document will be
170 • reconfirmed,
171 • withdrawn,
172 • replaced by a revised edition, or
173 • amended.

174 NOTE The attention of National Committees and Member Bodies is drawn to the fact that equipment

175 MANUFACTURERS and testing organizations may need a transitional period following publication of a new, amended

176 or revised IEC or ISO publication in which to make products in accordance with the new requirements and to e quip

177 themselves for conducting new or revised tests. It is the recommendation of the committee that the content of this

178 publication be adopted for mandatory implementation nationally not earlier than 3 years from the date of publication.

179

IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates

that it contains colours which are considered to be useful for the correct understanding

of its contents. Users should therefore print this document using a colour printer.

180
181
© IEC 2019 – All rights reserved
---------------------- Page: 6 ----------------------
IEC/DIS 62304:2019(E)
62A/1349/CDV – 8 – IEC CDV 62304 © IEC 2019
182 INTRODUCTION

183 Software is becoming increasingly important in healthcare. The use of software can help

184 contribute to more efficient and safe care of patients. Thus, HEALTH SOFTWARE needs to be

185 developed with appropriate controls to ensure its safe, effective and secure use.

186 In the past, software in the care environment was used primarily by clinical users (nurses,

187 technicians, dieticians, physicians, etc.) and previous versions of this document addressed

188 product development activities focused on the use of MEDICAL DEVICE SOFTWARE by clinical

189 users. There are now software products that are being used by non-clinical users to measure,

190 manage, maintain, or improve the health of individual(s), or for the delivery of care. For these

191 reasons, the scope of this document has been expanded to HEALTH SOFTWARE.

192 As software becomes more dependent on network connectivity and integral to clinical

193 workflows, additional considerations need to be made for SECURITY and USABILITY. HEALTH

194 SOFTWARE is being used more commonly in the home and outside of the hospital, so it becomes

195 even more important to develop these products with the user and use environment in mind. For

196 these reasons, the general requirements section has been updated to assure that this document

197 would meet the state of art of the use-environment and the way that HEALTH SOFTWARE is being

198 used.

199 This document does not duplicate well-established requirements from standards for USABILITY

200 and SECURITY. The addition of USABILITY and SECURITY to this document followed the same

201 approach as RISK MANAGEMENT and quality management PROCESSES of previous versions of this

202 document (i.e. editions 1.0 and 1.1).

203 Establishing the SAFETY and effectiveness of HEALTH SOFTWARE requires knowledge of what the

204 HEALTH SOFTWARE is intended to do and demonstration that the use of the HEALTH SOFTWARE

205 fulfils those intentions without causing any unacceptable RISKS.

206 The MANUFACTURER of HEALTH SOFTWARE is responsible for determining and complying with the

207 appropriate SAFETY, SECURITY, environmental, health, and interference protection practices and

208 the applicable laws and regulations. Many laws, regulations, and other rules from authorities

209 having jurisdiction have a direct impact on the way SOFTWARE SYSTEMS are developed, tested,

210 and maintained. From a software development perspective, MANUFACTURERS consider these

211 laws, regulations, and other rules as inputs into the requirements that the HEALTH SOFTWARE

212 supports. This means that the requirements of some laws or regulations can translate into

213 specific HEALTH SOFTWARE product requirements. For example, if HEALTH SOFTWARE is going to

214 send or share health data to a doctor, hospital, or other covered entity, it is required to adhere

215 to privacy and SECURITY rules. This can require authentication and SECURITY mechanisms to

216 protect patient information saved in an electronic format. Other requirements of the laws or

217 regulations can impact the PROCESS used during the development of the HEALTH SOFTWARE

218 product. For example, many national regulations and quality systems standards have design

219 control requirements that translate into specific procedures to confirm that the product is

220 designed, verified, and validated in a systematic manner and per proven software engineering

221 practices.

222 This document specifies that MANUFACTURERS develop and maintain HEALTH SOFTWARE within a

223 quality management SYSTEM (see 4.1) and a RISK MANAGEMENT SYSTEM (4.2).

224 Whether software is a contributing factor to a HAZARDOUS SITUATION is determined during the

225 HAZARD identification ACTIVITY of the RISK MANAGEMENT PROCESS. However, software may also

226 be used to control RISK. The decision to use software to control RISK is made during the RISK

227 CONTROL ACTIVITY of the RISK MANAGEMENT PROCESS.

228 This document provides a framework for a life cycle PROCESS. It defines the ACTIVITIES and

229 TASKS necessary for the safe design, development and maintenance of HEALTH SOFTWARE. The

230 development life cycle ACTIVITIES are shown in Figure 1 and described in Clause 5. Some

231 incidents in healthcare delivery are related to HEALTH SOFTWARE SYSTEMS, including

© IEC 2019 – All rights reserved
---------------------- Page: 7 ----------------------
IEC/DIS 62304:2019(E)
IEC CDV 62304 © IEC 2019 – 9 – 62A/1349/CDV

232 inappropriate software updates and upgrades. The SOFTWARE MAINTENANCE PROCESS is

233 therefore as important as the software development PROCESS. It is shown in Figure 2 and

234 described in Clause 6.
Activities outside the scope of this document
Customer Customer
needs needs satisfied
SYSTEM development ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT PROCESS
5.1 5.2 5.3
5.6
5.5
5.4 5.7
5.8
Software Software Software
Software
SOFTWARE UNIT
Software detailed SOFTWARE SYSTEM
Software release
development requirements architectural
integration and
design implementation testing
planning analysis design
integration testing
8 Software configuration management PROCESS
9 Software problem resolution PROCESS
235
236 Figure 1 – Overview of software development PROCESSES and ACTIVITIES
Activities outside the scope of this document
Maintenance Request
request satisfied
SYSTEM maintenance ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT PROCESS
6.1 6.2 5.3
5.6
5.5
5.4 5.7
5.8
Establish SOFTWARE Problem and Software
Software
Software detailed SOFTWARE UNIT SOFTWARE SYSTEM
Software release
MAINTENANCE modification architectural
integration and
design implementation testing
plan analysis design
integration testing
6.3 Modification implementation
8 Software configuration management
9 Software problem resolution
237
238 Figure 2 – Overview of SOFTWARE MAINTENANCE PROCESSES and ACTIVITIES

239 This document identifies two additional supporting PROCESSES considered essential for

240 developing safe HEALTH SOFTWARE. They are the software configuration management PROCESS

241 (Clause 8) and the software problem resolution PROCESS (Clause 9).

242 This document does not specify a specific organizational structure nor responsibilities within

243 the organization of the MANUFACTURER to perform PROCESSES, ACTIVITIES, and TASKS. This

244 document specifies planning of software development, maintenance and supporting PROCESS

245 ACTIVITIES, and the completion of the ACTIVITIES or TASKS for conformance with this document.

© IEC 2019 – All rights reserved
---------------------- Page: 8 ----------------------
IEC/DIS 62304:2019(E)
62A/1349/CDV – 10 – IEC CDV 62304 © IEC 2019

246 This document does not prescribe the name, format, or explicit content of the documentation to

247 be produced. This document calls for adequate evidence of required ACTIVITIES and TASKS by

248 documentation. Regardless how content is structured and packaged, it is expected that a

249 controlled documentation PROCESS is in place. This document does not prescribe a specific life

250 cycle model. The users of this document are responsible for selecting a life cycle model for the

251 software project and for mapping the PROCESSES, ACTIVITIES, and TASKS in this document onto

252 that model.

253 Annex A provides rationale for the clauses of this document. Annex B provides guidance on the

254 provisions of this document.
255
© IEC 2019 – All rights reserved
---------------------- Page: 9 ----------------------
IEC/DIS 62304:2019(E)
IEC CDV 62304 © IEC 2019 – 11 – 62A/1349/CDV
256 HEALTH SOFTWARE –
257 SOFTWARE LIFE CYCLE PROCESSES
258
259
260
261 1 Scope
262 1.1 * Purpose

263 This document defines the development and maintenance life cycle requirements for HEALTH

264 SOFTWARE. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes

265 a common framework for HEALTH SOFTWARE life cycle PROCESSES.
266 1.2 * Field of application

267 This document applies to the development and maintenance of HEALTH SOFTWARE by a

268 MANUFACTURER. MEDICAL DEVICE SOFTWARE is a subset of HEALTH SOFTWARE (see Figure 3).

269 Therefore, this document applies to:
270 – software as part of a MEDICAL DEVICE;
271 – software as part of specific health hardware;
272 – software as a medical device (SaMD);
273 – software-only product for other health use.
HEALTH SOFTWARE
MEDICAL
DEVICE
Software as
software
Software as
part of
part of a
specific
MEDICAL DEVICE
For specific
health
hardware
hardware
For general
Software as
Software-only
computing
a MEDICAL
platform product for
DEVICE
other
(SAMD)
health use
Other health use
MEDICAL DEVICE use
274
275 Figure 3 – HEALTH SOFTWARE field of application
276 NOTE 1 Examples of HEALTH SOFTWARE include the following:

277 1) HEALTH SOFTWARE not part of a MEDICAL DEVICE: mobile applications running on devices without physiologic

278 sensors or detectors, hospital information systems;

279 2) MEDICAL DEVICE SOFTWARE: software that is an integral part of a device such as a infusion pump or dialysis

280 machine;

281 3) software as a MEDICAL DEVICE (SAMD): Software that is itself a MEDICAL DEVICE, such as a software application

282 that reviews images generated by an MRI. For definition of software as a MEDICAL DEVICE see

[33]
283 IMDRF/SaMD/WG/N10Final:2013 .

284 4) software as a service, i.e., software executed in an external environment, providing calculation -results that fulfil

285 the definition of a MEDICAL DEVICE.

286 NOTE 2 This document can be used in the development and maintenance of health software. Before any type of

287 software can be placed into service, activities are necessary at the SYSTEM level. These SYSTEM activities are not

[1]

288 covered by this document (see Figure 1), but can be found in related product standards (e.g., IEC 60601-1 or

© IEC 2019 – All rights reserved
---------------------- Page: 10 ----------------------
IEC/DIS 62304:2019(E)
62A/1349/CDV – 12 – IEC CDV 62304 © IEC 2019
[15]

289 IEC 82304-1 ). For software as a medical device (SaMD) additional guidance on activities at a system level (e.g.

290 clinical EVALUATION) can be found in regulatory authority guidance documents.

291 This document describes PROCESSES that are intended to be applied to software which executes

...