Health software - Software life cycle processes

1.1 * Purpose This document defines the development and maintenance life cycle requirements for HEALTH SOFTWARE. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes a common framework for HEALTH SOFTWARE life cycle PROCESSES. 1.2 * Field of application This document applies to the development and maintenance of HEALTH SOFTWARE by a MANUFACTURER. MEDICAL DEVICE SOFTWARE is a subset of HEALTH SOFTWARE (see Figure 2). Therefore, this document applies to: - software as part of a MEDICAL DEVICE; - software as part of specific health hardware; - software as a MEDICAL DEVICE (SaMD); - software-only product for other health use. Figure 2 provides a graphical representation of the health software this document applies to. [Figure 2] NOTE 1 Examples of HEALTH SOFTWARE include the following: 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 machine. 2) software as part of specific health hardware: patient wristband printer software, healthcare scanner software, health app on specific wearable hardware (i.e. watch, wristband, chestband). 3) software as a MEDICAL DEVICE (SaMD): software that is itself a MEDICAL DEVICE, such as a software application that performs diagnostic image analysis for making treatment decisions. A definition of software as a MEDICAL DEVICE is provided in [46] 1. 4) software-only product for other health use: hospital information systems, electronic health records, electronic medical records, mobile applications running on devices without physiologic sensors or detectors, software as a service, i.e. software executed in an external environment, providing calculation-results that fulfil the definition of a MEDICAL DEVICE. NOTE 2 This document can be used in the development and maintenance of HEALTH SOFTWARE. Before any type of software can be placed into service, activities are necessary before the software product is integrated into the SYSTEM. These SYSTEM activities are not covered by this document (see Figure 1), but can be found in related product standards (e.g., IEC 60601-1 [1] or IEC 82304-1 [15]). For software as a MEDICAL DEVICE (SaMD) additional guidance on ACTIVITIES at a system level (e.g. clinical EVALUATION) can be found in regulatory authority guidance documents. [...]

Gesundheits-Software - Software-Lebenszyklus-Prozesse

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

Programska oprema v zdravstvu - Procesi v življenjskem ciklu programske opreme

General Information

Status
Not Published
Publication Date
03-Sep-2019
Withdrawal Date
03-Mar-2020
Current Stage
4060 - Enquiry results established and sent to TC, SR, BTTF - Enquiry
Start Date
26-Mar-2021
Completion Date
26-Mar-2021

Relations

Buy Standard

Draft
prEN IEC 62304:2021 (januar) - BARVE
English language
95 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day
Draft
prEN IEC 62304:2021 (marec) - BARVE
English language
102 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
oSIST prEN IEC 62304:2021
01-januar-2021
Programska oprema v zdravstvu - Procesi v življenjskem ciklu programske opreme
Health software - Software life cycle processes
Ta slovenski standard je istoveten z: prEN IEC 62304:2019
ICS:
13.020.60 Življenjski ciklusi izdelkov Product life-cycles
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
oSIST prEN IEC 62304:2021 en

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN IEC 62304:2021
---------------------- Page: 2 ----------------------
oSIST prEN IEC 62304:2021
62A/1349/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62304 ED2
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2019-10-04 2019-12-27
SUPERSEDES DOCUMENTS:
62A/1310/CD,62A/1319A/CC
IEC SC 62A : COMMON ASPECTS OF ELECTRICAL EQUIPMENT USED IN MEDICAL PRACTICE
SECRETARIAT: SECRETARY:
United States of America Ms Hae Choe
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:
TC 62,SC 62B,SC 62C,SC 62D,TC 65,TC 66,TC
76,TC 106,TC 108
Other TC/SCs are requested to indicate their interest, if
any, in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY

SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING

Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft
for Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.

This document is still under study and subject to change. It should not be used for reference purposes.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of

which they are aware and to provide supporting documentation.
TITLE:
IEC 62304 Ed. 2: Health software - Software life cycle processes
PROPOSED STABILITY DATE: 2024
NOTE FROM TC/SC OFFICERS:

Please note that IEC 62304 was circulated to IEC/SC 62A and ISO/TC 215 as a CDV/DIS in February,

2018. However, the document did not receive the approval to move forward. Therefore, the draft was

Copyright © 2019 International Electrotechnical Commission, IEC. All rights reserved. It is permitted to

download this electronic file, to make a copy and to print out the content for the sole purpose of preparing National

Committee positions. You may not copy or "mirror" the file or printed version of the document, or any part of it, for

any other purpose without permission in writing from IEC.
---------------------- Page: 3 ----------------------
oSIST prEN IEC 62304:2021
62A/1349/CDV – 2 – IEC CDV 62304 © IEC 2019

revised, based on the comments received and other input, and was circulated as a 3rd Committee Draft

in January 2019. The document was also circulated for information/comment to ISO/TC 210.

The comments submitted on the 3rd Committee Draft were resolved by the IEC 62304 Project Team

(see 62A/1319A/CC).

The document is being circulated for ballot as a 2nd CDV/DIS in IEC/SC 62A and ISO/TC 215. The

document will also be circulated for information to ISO/TC 210.
---------------------- Page: 4 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2019 – 3 – 62A/1349/CDV
NOTE DES RESPONSABLES DU TC/SC:

Please note that IEC 62304 was circulated to IEC/SC 62A and ISO/TC 215 as a CDV/DIS in February,

2018. However, the document did not receive the approval to move forward. Therefore, the draft was

revised, based on the comments received and other input, and was circulated as a 3rd Committee Draft

in January 2019. The document was also circulated for information/comment to ISO/TC 210.

The comments submitted on the 3rd Committee Draft were resolved by the IEC 62304 Project Team

(see 62A/1319A/CC).

The document is being circulated for ballot as a 2nd CDV/DIS in IEC/SC 62A and ISO/TC 215. The

document will also be circulated for information to ISO/TC 210.
---------------------- Page: 5 ----------------------
oSIST prEN IEC 62304:2021
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

---------------------- Page: 6 ----------------------
oSIST prEN IEC 62304:2021
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

---------------------- Page: 7 ----------------------
oSIST prEN IEC 62304:2021
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.
---------------------- Page: 8 ----------------------
oSIST prEN IEC 62304:2021
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
---------------------- Page: 9 ----------------------
oSIST prEN IEC 62304:2021
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

---------------------- Page: 10 ----------------------
oSIST prEN IEC 62304:2021
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.

---------------------- Page: 11 ----------------------
oSIST prEN IEC 62304:2021
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
---------------------- Page: 12 ----------------------
oSIST prEN IEC 62304:2021
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 * Purpos
...

SLOVENSKI STANDARD
oSIST prEN IEC 62304:2021
01-marec-2021
Programska oprema v zdravstvu - Procesi v življenjskem ciklu programske opreme
Health software - Software life cycle processes
Gesundheits-Software - Software-Lebenszyklus-Prozesse
Logiciels de santé - Processus du cycle de vie du logiciel
Ta slovenski standard je istoveten z: prEN IEC 62304:2021
ICS:
13.020.60 Življenjski ciklusi izdelkov Product life-cycles
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
oSIST prEN IEC 62304:2021 en

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
oSIST prEN IEC 62304:2021
---------------------- Page: 2 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV
COMMITTEE DRAFT FOR VOTE (CDV)
PROJECT NUMBER:
IEC 62304 ED2
DATE OF CIRCULATION: CLOSING DATE FOR VOTING:
2021-01-01 2021-03-26
SUPERSEDES DOCUMENTS:
62A/1349/CDV, 62A/1383B/RVC
IEC SC 62A : COMMON ASPECTS OF ELECTRICAL EQUIPMENT USED IN MEDICAL PRACTICE
SECRETARIAT: SECRETARY:
United States of America Ms Hae Choe
OF INTEREST TO THE FOLLOWING COMMITTEES: PROPOSED HORIZONTAL STANDARD:
TC 62,SC 62B,SC 62C,SC 62D,TC 65,TC 66,TC
76,TC 106,TC 108
Other TC/SCs are requested to indicate their interest, if
any, in this CDV to the secretary.
FUNCTIONS CONCERNED:
EMC ENVIRONMENT QUALITY ASSURANCE SAFETY

SUBMITTED FOR CENELEC PARALLEL VOTING NOT SUBMITTED FOR CENELEC PARALLEL VOTING

Attention IEC-CENELEC parallel voting
The attention of IEC National Committees, members of
CENELEC, is drawn to the fact that this Committee Draft
for Vote (CDV) is submitted for parallel voting.
The CENELEC members are invited to vote through the
CENELEC online voting system.

This document is still under study and subject to change. It should not be used for reference purposes.

Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of

which they are aware and to provide supporting documentation.
TITLE:
IEC 62304 Ed. 2: Health software - Software life cycle processes
PROPOSED STABILITY DATE: 2024

Copyright © 2020 International Electrotechnical Commission, IEC. All rights reserved. It is permitted to

download this electronic file, to make a copy and to print out the content for the sole purpose of preparing National

Committee positions. You may not copy or "mirror" the file or printed version of the document, or any part of it,

for any other purpose without permission in writing from IEC.
---------------------- Page: 3 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 2 – IEC CDV 62304 © IEC 2021
NOTE FROM TC/SC OFFICERS:

Please note that this draft is a joint project between IEC/SC 62A and ISO/TC 215 and is IEC led. During

the last CDV stage, this project was approved on the IEC side but not approved in ISO and CENELEC.

A task group was assigned to develop proposed resolutions to the comments and to the draft which

were reviewed by the 62304 Project Team and the IEC/ISO Joint Working Group. Attached is the result

of that extensive work. Some comments did not offer specific changes but provided ideas that may be

better utilized during the next maintenance cycle for this document.
---------------------- Page: 4 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2021 – 3 – 62A/1422/CDV
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

---------------------- Page: 5 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 4 – IEC CDV 62304 © IEC 2021

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

---------------------- Page: 6 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2021 – 5 – 62A/1422/CDV

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

---------------------- Page: 7 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 6 – IEC CDV 62304 © IEC 2021
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;
---------------------- Page: 8 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2021 – 7 – 62A/1422/CDV

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
---------------------- Page: 9 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 8 – IEC CDV 62304 © IEC 2021

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
---------------------- Page: 10 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2021 – 9 – 62A/1422/CDV
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.

---------------------- Page: 11 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 10 – IEC CDV 62304 © IEC 2021
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
---------------------- Page: 12 ----------------------
oSIST prEN IEC 62304:2021
IEC CDV 62304 © IEC 2021 – 11 – 62A/1422/CDV
245 HEALTH SOFTWARE –
246 SOFTWARE LIFE CYCLE PROCESSES
247
248 1 Scope
249 1.1 * Pu
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.