oSIST prEN IEC 62304:2021
(Main)Health software - Software life cycle processes
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
Relations
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
2
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
54
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
76
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
89
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
95
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
2
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
55
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
75
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
93
94
95
---------------------- Page: 7 ----------------------
oSIST prEN IEC 62304:2021
62A/1422/CDV – 6 – IEC CDV 62304 © IEC 2021
96 INTERNATIONAL ELECTROTECHNICAL COMMISSION
97 ____________
98
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.