prEN IEC 62304:2021

SLOVENSKI STANDARD
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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
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.

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.

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

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

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
62A/1422/CDV – 6 – IEC CDV 62304 © IEC 2021
96 INTERNATIONAL ELECTROTECHNICAL COMMISSION
97 ____________
99 HEALTH SOFTWARE –
100 SOFTWARE LIFE CYCLE PROCESSES
102 FOREWORD
103 1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national
104 electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all
105 questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC
106 publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and
107 Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC
108 National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental
109 and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with
110 the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between
111 the two organizations.
112 2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus
113 of opinion on the relevant subjects since each technical committee has representation from all interested IEC National
114 Committees.
115 3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in
116 that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC
117 cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
118 4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to
119 the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and
120 the corresponding national or regional publication shall be clearly indicated in the latter.
121 5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment
122 services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by
123 independent certification bodies.
124 6) All users should ensure that they have the latest edition of this publication.
125 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its
126 technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature
127 whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of,
128 or reliance upon, this IEC Publication or any other IEC Publications.
129 8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable
130 for the correct application of this publication.
131 9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights.
132 IEC shall not be held responsible for identifying any or all such patent rights.
133 International Standard IEC 62304 has been prepared by a joint working group of subcommittee
134 62A: Common aspects of electrical equipment used in medical practice, of IEC technical
135 committee 62: Electrical equipment in medical practice,in cooperation with ISO Technical
136 Committee 215, Health informatics. Table C.5 was prepared by ISO/IEC JTC 1/SC 7, Software
137 and systems engineering.
138 It is published as a dual logo standard.
139 This second edition cancels and replaces the first edition published in 2006 and
140 Amendment 1:2015. This edition constitutes a technical revision.
141 This edition includes the following significant technical changes with respect to the previous
142 edition:
143 a) the scope of this document has been expanded to HEALTH SOFTWARE;

IEC 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
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.
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.
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.

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
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.
IEC CDV 62304 © IEC 2021 – 11 – 62A/1422/CDV
245 HEALTH SOFTWARE –
246 SOFTWARE LIFE CYCLE PROCESSES
248 1 Scope
249 1.1 * Purpose
250 This document defines the development and maintenance life cycle requirements for HEALTH
251 SOFTWARE. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes
252 a common framework for HEALTH SOFTWARE life cycle PROCESSES.
253 1.2 * Field of application
254 This document applies to the development and maintenance of HEALTH SOFTWARE by a
255 MANUFACTURER. MEDICAL DEVICE SOFTWARE is a subset of HEALTH SOFTWARE (see Figure 2).
256 Therefore, this document applies to:
257 – software as part of a MEDICAL DEVICE;
258 – software as part of specific health hardware;
259 – software as a MEDICAL DEVICE (SaMD);
260 – software-only product for other health use.
261 Figure 2 provides a graphical representation of the health software this document applies to.
HEALTH SOFTWARE
MEDICAL
DEVICE
Software as
software
Software as
part of
part of a
specific
MEDICAL DEVICE
For specific
health
hardware
hardware
For general
Software as
computing Software-only
a MEDICAL
platform product for
DEVICE
other
(SaMD)
health use
MEDICAL DEVICE use Other health use
263 Figure 2 – HEALTH SOFTWARE field of application
264 NOTE 1 Examples of HEALTH SOFTWARE include the following:
265 1) software as a part of a MEDICAL DEVICE: software that is an integral part of a device such as an infusion pump or dialysis
266 machine.
267 2) software as part of specific health hardware: patient wristband printer software, healthcare scanner software, health app on
268 specific wearable hardware (i.e. watch, wristband, chestband).

62A/1422/CDV – 12 – IEC CDV 62304 © IEC 2021
269 3) software as a MEDICAL DEVICE (SaMD): software that is itself a MEDICAL DEVICE, such as a software application that performs
270 diagnostic image analysis for making treatment decisions. A definition of software as a MEDICAL DEVICE is provided in [46] .
271 4) software-only product for other health use: hospital information systems, electronic health records, electronic medical
272 records, mobile applications running on devices without physiologic sensors or detectors, software as a service, i.e.
273 software executed in an external environment, providing calculation-results that fulfil the definition of a MEDICAL DEVICE.
274 NOTE 2 This document can be used in the development and maintenance of HEALTH SOFTWARE. Before any type of
275 software can be placed into service, activities are necessary before the software product is integrated into the
276 SYSTEM. These SYSTEM activities are not covered by this document (see Figure 1), but can be found in related
277 product standards (e.g., IEC 60601-1 [1] or IEC 82304-1 [15]). For software as a MEDICAL DEVICE (SaMD) additional
278 guidance on ACTIVITIES at a system level (e.g. clinical EVALUATION) can be found in regulatory authority guidance
279 documents.
280 This document describes PROCESSES that are intended to be applied to software which executes
281 on a processor or which is executed by other software (for example an interpreter) which
282 executes on a processor.
283 This document applies regardless of the persistent storage device(s) used to store the software
284 (for example: hard disk, optical disk, permanent or flash memory).
285 This document applies regardless of the method of delivery of the software (for example:
286 transmission by network or email, EEPROM, Smart Drive, Cloud). The method of software
287 delivery itself is not considered HEALTH SOFTWARE.
288 This document does not cover the means of VALIDATION, even when the product consists entirely
289 of software. It also does not cover software life cycle steps after release for INTENDED USE of
290 the product, including implementation, configuration, integration (with other systems), go -live,
291 clinical use, operations, decommissioning or disposal, other than ACTIVITIES involving
292 maintenance of the software.
293 This document does not cover the VALIDATION of software tools used in the design of medical
294 devices (e.g. computer aided design (CAD) software), software used in MEDICAL DEVICE quality

295 systems or software for regulated processes (see ISO/TR 80002-2 [20] and AAMI TIR 36 [40]).
296 NOTE 3 If a product incorporates embedded software intended to be executed on a processor, the requirements of this
297 document apply to the software, including the requirements concerning SOFTWARE OF UNKNOWN PROVENANCE (SOUP) – see
298 8.1.2).
299 Data quality and VALIDATION of emergent characteristics or functionality of artificial intelligence
300 (AI) HEALTH SOFTWARE are not within the scope of this document.
301 NOTE 4 Users of this document may need to utilize other standards and technical sources to supplement this document in
302 addressing the unique performance characteristics of their AI HEALTH SOFTWARE. As AI is a rapidly developing field and as
303 further insights are gained, new updates may need to be incorporated into IEC 62034 via an amendment or a future new edition.
304 1.3 Relationship to other standards
305 This HEALTH SOFTWARE life cycle document is written in a way that it can be used together with
306 referencing standards when developing and maintaining a product that includes HEALTH
307 SOFTWARE (see Annex C).
308 2 * Normative references
309 The following documents are referred to in the text in such a way that some or all of their content
310 constitutes requirements of this document. For dated references, only the edition cited applies.
___________
Numbers in square brackets refer to the Bibliography.

IEC CDV 62304 © IEC 2021 – 13 – 62A/1422/CDV
311 For undated references, the latest edition of the referenced document (including any
312 amendments) applies.
313 3 * Terms and definitions
314 For the purposes of this document, the following terms and definitions apply.
315 ISO and IEC maintain terminological databases for use in standardisation at the following
316 addresses:
317 • IEC Electropedia: available at http://www.electropedia.org/
318 • ISO Online browsing platform: available at https://www.iso.org/obp
319 3.1
320 ACTIVITY
321 set of one or more interrelated or interacting TASKS
322 3.2
323 ANOMALY
324 condition that deviates from expectations based on requirements specifications, design documents,
325 standards, etc. or from someone's perceptions or experiences
326 [SOURCE: ISO/IEC 25051:2014, 4.1.2]
327 3.3
328 ARCHITECTURE
329 [SYSTEM] fundamental concepts or properties of a SYSTEM in its environment embodied in its elements,
330 relationships, and in the principles of its design and evolution
331 [SOURCE: ISO/IEC/IEEE Std 24765-2017, 3.216, definition 1]
332 3.4
333 CHANGE REQUEST
334 documented specification of a change to be made to HEALTH SOFTWARE
335 3.5
336 CONFIGURATION ITEM
337 entity that can be uniquely identified at a given reference point
338 3.6
339 DELIVERABLE
340 required result or output (includes documentation) of an ACTIVITY or TASK
341 3.7
342 EVALUATION
343 systematic determination of the extent to which an entity meets its specified criteria

62A/1422/CDV – 14 – IEC CDV 62304 © IEC 2021
344 3.8
345 EFFECTIVENESS
346 ability to produce the intended result
347 [SOURCE: ISO 81001-1:— , 3.2.5]
348 3.9
349 HARM
350 injury or damage to the health of people, or damage to property or the environment
351 [SOURCE: ISO 81001-1:—, 3.4.5]
352 3.10
353 HAZARD
354 potential source of HARM
355 Note 1 to entry: Potential sources of HARM include breach of SECURITY and reduction of EFFECTIVENESS.
356 [SOURCE: ISO 81001-1:—, 3.4.6, modified – Note 1 to entry has been added.]
357 3.11
358 HAZARDOUS SITUATION
359 circumstance in which people, property or the environment is/are exposed to one or more HAZARD(S)
360 [SOURCE: ISO 81001-1:—, 3.4.7]
361 3.12
362 HEALTH SOFTWARE
363 SOFTWARE intended to be used specifically for managing, maintaining, or improving health of individual
364 persons, or the delivery of care, or which has been developed for the purpose of being incorporated
365 into a MEDICAL DEVICE
366 Note 1 to entry: HEALTH SOFTWARE fully includes what is considered software as a MEDICAL DEVICE.
367 [SOURCE: ISO 81001-1:—, 3.3.9]
368 3.13
369 INTENDED USE
370 use for which a product, PROCESS or service is intended according to the specifications, instructions
371 and information provided by the MANUFACTURER
372 Note 1 to entry: The intended medical indication, patient population, part of the body or type of tissue iteracted with, user
373 profile, use environment, and operating principle are typical elements of the INTENDED USE.
374 [SOURCE: ISO 81001-1:—, 3.2.7, modified – The second preferred term "intended purpose" has
375 been deleted.]
___________
Under preparation. Stage at the time of publication: ISO/DIS 81001-1:2019.

IEC CDV 62304 © IEC 2021 – 15 – 62A/1422/CDV
376 3.14
377 LEGACY SOFTWARE
378 HEALTH SOFTWARE placed on the market before the publication of this document for which the
379 MANUFACTURER seeks conformance retrospectively
380 3.15
381 MANUFACTURER
382 natural or legal person with responsibility for designing, manufacturing, packaging, or labelling of
383 HEALTH SOFTWARE product, or adapting HEALTH SOFTWARE product before it is placed on the market
384 and/or put into service, regardless of whether these operations are carried out by that person or on
385 that person's behalf by a third party
386 Note 1 to entry: Attention is drawn to the fact that the provisions of national or regional regulations can apply to the definition of
387 MANUFACTURER.
388 Note 2 to entry: For a definition of "labelling", see ISO 13485:2016, 3.8.
389 Note 3 to entry: "Developer" or "developer organization" are commonly used terms and are synonymous with the term
390 "MANUFACTURER" in the context of health information technology.
391 3.16
392 MEDICAL DEVICE
393 instrument, apparatus, implement, machine, appliance, implant, reagent for in vitro use, software,
394 material or other similar or related article, intended by the MANUFACTURER to be used, alone or in
395 combination, for human beings for one or more of the specific medical purpose(s) of
396 – diagnosis, prevention, monitoring, treatment or alleviation of disease,
397 – diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
398 – investigation, replacement, modification, or support of the anatomy or of a physiological PROCESS,
399 – supporting or sustaining life,
400 – control of conception,
401 – disinfection of MEDICAL DEVICES,
402 – providing information by means of in vitro examination of specimens derived from the human body,
403 and which does not achieve its primary intended action by pharmacological, immunological or
404 metabolic means, in or on the human body, but which may be assisted in its function by such means
405 Note 1 to entry: Products which could be considered to be MEDICAL DEVICES in some jurisdictions but not in others include:
406 – disinfection substances,
407 – aids for persons with disabilities,
408 – devices incorporating animal and/or human tissues,
409 – devices for in-vitro fertilization or assisted reproductive technologies.
410 Note 2 to entry: In conjunction with IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012, the term "MEDICAL DEVICE" assumes
411 the same meaning as ME EQUIPMENT or ME SYSTEM (which are defined terms of IEC 60601-1).
412 [SOURCE: ISO 81001-1:—, 3.3.13, modified – Note 2 to entry has been added.]

62A/1422/CDV – 16 – IEC CDV 62304 © IEC 2021
413 3.17
414 MEDICAL DEVICE SOFTWARE
415 SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into a MEDICAL
416 DEVICE, or is developed to be software as a MEDICAL DEVICE (SaMD)
417 3.18
418 PROBLEM REPORT
419 record of actual or potential behaviour of HEALTH SOFTWARE that a user or other interested person
420 believes to be unsafe, inappropriate for the INTENDED USE or contrary to specification
421 Note 1 to entry: This document does not require that every PROBLEM REPORT results in a change to HEALTH SOFTWARE. A
422 MANUFACTURER can reject a PROBLEM REPORT as a misunderstanding, error or insignificant event with sufficient justification.
423 Note 2 to entry: A PROBLEM REPORT can relate to HEALTH SOFTWARE released for INTENDED USE or to HEALTH SOFTWARE that is
424 still under development.
425 Note 3 to entry: This document requires the MANUFACTURER to perform extra decision making steps (see Clause 6) for a
426 PROBLEM REPORT relating to HEALTH SOFTWARE to ensure that regulatory actions are identified and implemented.
427 3.19
428 PROCESS
429 set of interrelated or interacting ACTIVITIES that use inputs to deliver an intended result
430 Note 1 to entry: The term "ACTIVITIES" covers use of resources.
431 [SOURCE: ISO 81001-1:—, 3.2.10, modified – The note to entry has been added.]
432 3.20
433 REGRESSION TESTING
434 testing following modification to a test item or its operational environment to identify whether
435 regression failures occur
436 Note 1 to entry: Sufficiency of a set of regression test cases depends on the item under test and on modifications to that item
437 or its operational environment.
438 [SOURCE: ISO/IEC/IEEE 90003:2018, 3.6]
439 3.21
440 RESIDUAL RISK
441 RISK remaining after RISK CONTROL measures have been implemented
442 [SOURCE: ISO 81001-1:—, 3.4.9]
443 3.22
444 RISK
445 combination of the probability of occurrence of HARM and the severity of that HARM
446 [SOURCE: ISO 81001-1:—, 3.4.10, modified – The note to entry has been deleted.]

IEC CDV 62304 © IEC 2021 – 17 – 62A/1422/CDV
447 3.23
448 RISK ANALYSIS
449 systematic use of available information to identify HAZARDS and to estimate the RISK
450 [SOURCE: ISO 81001-1:—, 3.4.11]
451 3.24
452 RISK CONTROL
453 PROCESS in which decisions are made and RISKS are reduced to, or maintained within, specified levels
454 [SOURCE: ISO 81001-1:—, 3.4.13, modified – The definition has been rephrased.]
455 3.25
456 RISK ESTIMATION
457 PROCESS used to assign values to the probability of occurrence of HARM and the severity of that HARM
458 [SOURCE: ISO 81001-1:—, 3.4.14]
459 3.26
460 RISK EVALUATION
461 PROCESS of comparing the estimated RISK against given RISK criteria to determine the acceptability of
462 the RISK
463 [SOURCE: ISO 81001-
...