IEC 62304:2006

IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Medical device software – Software life cycle processes

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and definitions clause of
IEC publications issued between 2002 and 2015. Some
IEC Customer Service Centre - webstore.iec.ch/csc entries have been collected from earlier publications of IEC
If you wish to give us your feedback on this publication or TC 37, 77, 86 and CISPR.

need further assistance, please contact the Customer Service

Centre: sales@iec.ch.
IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
colour
inside
Medical device software – Software life cycle processes

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 11.140 ISBN 978-2-8322-2765-7

IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
REDLINE VERSION
colour
inside
Medical device software – Software life cycle processes

– 2 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
INTRODUCTION to Amendment 1 . 8
1  Scope . 9
1.1  * Purpose . 9
1.2  * Field of application . 9
1.3  Relationship to other standards . 9
1.4  Compliance . 9
2  * Normative references . 10
3  * Terms and de finitions . 10
4  * General requirements . 15
4.1  * Quality management system . 15
4.2  * RISK MANAGEMENT . 16
4.3  * Software safety classification . 16
4.4  * LEGACY SOFTWARE . 18
5  Software development PROCESS . 19
5.1  * Software development planni ng . 19
5.2  * Software requirements analys is . 21
5.3  * Software ARCHITECTURAL design . 23
5.4  * Software detailed design . 24
5.5  * SOFTWARE UNIT implementation and verification . 25
5.6  * Software integration and integration testing . 25
5.7  * SOFTWARE SYSTEM testing . 27
5.8  * Software release . 28
6  Software maintenance PROCESS . 29
6.1  * Establish software maintenance plan . 29
6.2  * Problem and modification analysis . 30
6.3  * Modification implementation . 31
7  * Software RISK MANAGEMENT PROCESS . 31
7.1  * Analysis of software contributing to hazardous s i tuations . 31
7.2  RISK CONTROL measures . 32
7.3  VERIFICATION of RISK CONTROL measures . 32
7.4  RISK MANAGEMENT of software changes . 33
8  * Software configuration management PROCESS . 33
8.1  * Configuration identification . 33
8.2  * Change control . 33
8.3  * Configuration status accounting . 34
9  * Software problem resolution PROCESS . 34
9.1  Prepare PROBLEM REPORTS . 34
9.2  Investigate the problem . 35
9.3  Advise relevant parties . 35
9.4  Use change control process . 35
9.5  Maintain re c o rds . 35
9.6  Analyse problems for trends . 35
9.7  Verify software problem resolution . 35

+AMD1:2015 CSV  IEC 2015
9.8  Test documentation contents . 36
Annex A (informative) Rationale for the requirements of this standard . 37
Annex B (informative) Guidance on the provisions of this standard . 40
Annex C (informative) Relationship to other standards . 58
Annex D (informative) Implement ation . 84
Bibliography . . 86
Index of defined terms . 88

Figure 1 – Overview of software development PROCESSES and ACTIVITIES . 7
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES . 7
Figure 3 – Assigning software safety classification . 16
Figure B.2 – Pictorial representation of the relationship of HAZARD, sequence of
events, HAZARDOUS SITUATION, and HARM – from ISO 14971:2007 Annex E . 44
Figure B.1 – Example of partitioning of SOFTWARE ITEMS . 46
Figure C.1 – Relationship of key MEDICAL DEVICE standards to IEC 62304 . 59
Figure C.2 – Software as part of the V-model . 62
Figure C.3 – Application of IEC 62304 with IEC 61010-1 . 72

Table A.1 – Summary of requirements by software safety class . 39
Table B.1 – Development (model) strategies as defined in ISO/IEC 12207 . 41
Table C.1 – Relationship to ISO 13485:2003 . 60
Table C.2 – Relationship to ISO 14971:2000 2007 . 61
Table C.3 – Relationship to IEC 60601-1 . 64
Table C.4 – Relationship to IEC 60601-4 .
Table C.5 – Relationship to ISO/IEC 12207 . 74
Table D.1 – Checklist for small companies without a certified QMS . 85

– 4 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
This consolidated version of the official IEC Standard and its amendment has been prepared
for user convenience.
IEC 62304 edition 1.1 contains the first edition (2006-05) [documents 62A/523/FDIS and 62A/528/
RVD] and its amendment 1 (2015-06) [documents 62A/1007/FDIS and 62A/1014/RVD].
In this Redline version, a vertical line in the margin shows where the technical content is
modified by amendment 1. Additions and deletions are displayed in red, with
deletions being struck through. A separate Final version with all changes accepted is
available in this publication.
International Standard IEC 62304 has been prepared by a joint working group of subcommittee
62A: Common aspects of electrical equipment used in medical practice, of IEC technical

+AMD1:2015 CSV  IEC 2015
committee 62: Electrical equipment in medical practice and ISO Technical Committee 210,
Quality management and corresponding general aspects for MEDICAL DEVICES. Table C.5 was
prepared by ISO/IEC JTC 1/SC 7, Software and system engineering.
It is published as a dual logo standard.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
In this standard the following print types are used:
• requirements and definitions: in roman type;
• informative material appearing outside of tables, such as notes, examples and references:
in smaller type. Normative text of tables is also in a smaller type;
• terms used throughout this standard that have been defined in Clause 3 and also given in
the index: in small capitals.
An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that
there is guidance related to that item in Annex B.
The committee has decided that the contents of the base publication and its amendment will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
NOTE The attention of National Committees is drawn to the fact that equipment MANUFACTURERS and testing
organizations may need a transitional period following publication of a new, amended or revised IEC or
ISO publication in which to make products in accordance with the new requirements and to equip themselves for
conducting new or revised tests. It is the recommendation of the committee that the content of this publication be
adopted for mandatory implementation nationally not earlier than 3 years from the date of publication.

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.

– 6 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
INTRODUCTION
Software is often an integral part of MEDICAL DEVICE technology. Establishing the SAFETY and
effectiveness of a MEDICAL DEVICE containing software requires knowledge of what the software
is intended to do and demonstration that the use of the software fulfils those intentions without
causing any unacceptable RISKS.
This standard provides a framework of life cycle PROCESSES with ACTIVITIES and TASKS
necessary for the safe design and maintenance of MEDICAL DEVICE SOFTWARE. This standard
provides requirements for each life cycle PROCESS. Each life cycle PROCESS is further divided
into consists of a set of ACTIVITIES, with most ACTIVITIES further divided into consisting of a set
of TASKS.
As a basic foundation it is assumed that MEDICAL DEVICE SOFTWARE is developed and
maintained within a quality management system (see 4.1) and a RISK MANAGEMENT system (see
4.2). The RISK MANAGEMENT PROCESS is already very well addressed by the International
Standard ISO 14971. Therefore IEC 62304 makes use of this advantage simply by a normative
reference to ISO 14971. Some minor additional RISK MANAGEMENT requirements are needed for
software, especially in the area of identification of contributing software factors related to
HAZARDS. These requirements are summarized and captured in Clause 7 as the software RISK
MANAGEMENT PROCESS.
Whether software is a contributing factor to a HAZARD HAZARDOUS SITUATION is determined
during the HAZARD identification ACTIVITY of the RISK MANAGEMENT PROCESS. HAZARDS
HAZARDOUS SITUATIONS that could be indirectly caused by software (for example, by providing
misleading information that could cause inappropriate treatment to be administered) need to be
considered when determining whether software is a contributing factor. The decision to use
software to control RISK is made during the RISK CONTROL ACTIVITY of the RISK MANAGEMENT
PROCESS. The software RISK MANAGEMENT PROCESS required in this standard has to be
embedded in the device RISK MANAGEMENT PROCESS according to ISO 14971.
The software development PROCESS consists of a number of ACTIVITIES. These ACTIVITIES are
shown in Figure 1 and described in Clause 5. Because many incidents in the field are related to
service or maintenance of MEDICAL DEVICE SYSTEMS including inappropriate software updates
and upgrades, the software maintenance PROCESS is considered to be as important as the
software development PROCESS. The software maintenance PROCESS is very similar to the
software development PROCESS. It is shown in Figure 2 and described in Clause 6.

+AMD1:2015 CSV  IEC 2015
Activities outside the scope of this standard
Customer needs
Customer needs
satisfied
SYSTEM development ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT
5.1 5.2 5.3 5.4 5.5 5.6
5.7
Software Software Software Software Software UNIT Software integration 5.8
Software SYSTEM
development requirements ARCHITECTURAL detailed implementation and and integration Software release
testing
planning analysis design design VERIFICATION testing
8 Software configuration management
9 Software problem resolution
IEC  722/06
Figure 1 – Overview of software development PROCESSES and ACTIVITIES
Activities outside the scope of this standard
Maintenance Request
request satisfied
System maintenance ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT
5.3 5.4 5.5 5.6
5.7
6.2
6.1
Software Software Software UNIT Software integration 5.8
Software SYSTEM
Problem and
Establish software
ARCHITECTURAL detailed implementation and and integration Software release
modification analysis
maintenance testing
design design VERIFICATION testing
plan
6.3 Modification implementation
8 Software configuration management
9 Software problem resolution

IEC  723/06
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES
This standard identifies two additional PROCESSES considered essential for developing safe
MEDICAL DEVICE SOFTWARE. They are the software configuration management PROCESS (Clause
8) and the software problem resolution PROCESS (Clause 9).
Amendment 1 updates the standard to add requirements to deal with LEGACY SOFTWARE, where
the software design is prior to the existence of the current version, to assist manufacturers who
must show compliance to the standard to meet European Directives. Software safety

– 8 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
classification changes include clarification of requirements and updating of the software safety
classification to include a risk-based approach.
This standard does not specify an organizational structure for the MANUFACTURER or which part
of the organization is to perform which PROCESS, ACTIVITY, or TASK. This standard requires only
that the PROCESS, ACTIVITY, or TASK be completed to establish compliance with this standard.
This standard does not prescribe the name, format, or explicit content of the documentation to
be produced. This standard requires documentation of TASKS, but the decision of how to
package this documentation is left to the user of the standard.
This standard does not prescribe a specific life cycle model. The users of this standard are
responsible for selecting a life cycle model for the software project and for mapping the
PROCESSES, ACTIVITIES, and TASKS in this standard onto that model.
Annex A provides rationale for the clauses of this standard. Annex B provides guidance on the
provisions of this standard.
For the purposes of this standard:
• “shall” means that compliance with a requirement is mandatory for compliance with this
standard;
• “should” means that compliance with a requirement is recommended but is not mandatory
for compliance with this standard;
• “may” is used to describe a permissible way to achieve compliance with a requirement;
• “establish” means to define, document, and implement; and
• where this standard uses the term “as appropriate” in conjunction with a required PROCESS,
ACTIVITY, TASK or output, the intention is that the MANUFACTURER shall use the PROCESS,
ACTIVITY, TASK or output unless the MANUFACTURER can document a justification for not so
doing.
INTRODUCTION to Amendment 1
The first edition of IEC 62304 was published in 2006. This amendment is intended to add
requirements to deal with LEGACY SOFTWARE, where the software design is prior to the
existence of the current version, to assist manufacturers who must show compliance to the
standard to meet European Directives. Software safety classification changes needed for this
amendment include clarification of requirements and updating of the software safety
classification to include a risk-based approach. Work is continuing in parallel to develop the
second edition of IEC 62304.
+AMD1:2015 CSV  IEC 2015
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for MEDICAL DEVICE SOFTWARE. The set of
PROCESSES, ACTIVITIES, and TASKS described in this standard establishes a common framework
for MEDICAL DEVICE SOFTWARE life cycle PROCESSES.
1.2 * Field of application
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE.
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE when
software is itself a MEDICAL DEVICE or when software is an embedded or integral part of the final
MEDICAL DEVICE.
NOTE 1 This standard can be used in the development and maintenance of software that is itself a medical
device. However, additional development activities are needed at the system level before this type of software can
be placed into service. These system activities are not covered by this standard, but can be found in IEC 82304-1
[22].
This standard describes PROCESSES that are intended to be applied to software which executes
on a processor or which is executed by other software (for example an interpreter) which
executes on a processor.
This standard applies regardless of the persistent storage device(s) used to store the software
(for example: hard disk, optical disk, permanent or flash memory).
This standard applies regardless of the method of delivery of the software (for example:
transmission by network or email, optical disk, flash memory or EEPROM). The method of
software delivery itself is not considered MEDICAL DEVICE SOFTWARE.
This standard does not cover validation and final release of the MEDICAL DEVICE, even when the
MEDICAL DEVICE consists entirely of software.
NOTE 2 If a medical device incorporates embedded software intended to be executed on a processor, the
requirements of this standard apply to the software, including the requirements concerning software of unknown
provenance (see 8.1.2).
NOTE 3 Validation and other development activities are needed at the system level before the software and
medical device can be placed into service. These system activities are not covered by this standard, but can be
found in related product standards (e.g., IEC 60601-1, IEC 82304-1, etc.).
1.3 Relationship to other standards
This MEDICAL DEVICE SOFTWARE life cycle standard is to be used together with other appropriate
standards when developing a MEDICAL DEVICE. Annex C shows the relationship between this
standard and other relevant standards.
1.4 Compliance
PROCESSES, ACTIVITIES, and
Compliance with this standard is defined as implementing all of the
TASKS identified in this standard in accordance with the software safety class.
___________
In preparation.
– 10 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
NOTE The software safety classes assigned to each requirement are identified in the normative text following the
requirement.
Compliance is determined by inspection of all documentation required by this standard
including the RISK MANAGEMENT FILE, and assessment of the PROCESSES, ACTIVITIES and TASKS
required for the software safety class. See Annex D.
NOTE 1 This assessment could be carried out by internal or external audit.
NOTE 2 Although the specified PROCESSES, ACTIVITIES, and TASKS are performed, flexibility exists in the methods
of implementing these PROCESSES and performing these ACTIVITIES and TASKS.
NOTE 3 Where any requirements contain “as appropriate” and were not performed, documentation for the
justification is necessary for this assessment.
NOTE 4 The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.
NOTE 5 For compliance of LEGACY SOFTWARE see 4.4.
2 * Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
ISO 14971, Medical devices – Application of risk management to medical devices.
3 * Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ACTIVITY
a set of one or more interrelated or interacting TASKS
3.2
ANOMALY
any condition that deviates from the expected based on requirements specifications, design
documents, standards, etc. or from someone’s perceptions or experiences. ANOMALIES may be
found during, but not limited to, the review, test, analysis, compilation, or use of MEDICAL
DEVICE SOFTWARE PRODUCTS or applicable documentation
NOTE Based on [IEEE 1044:1993, definition 3.1].
3.3
ARCHITECTURE
organizational structure of a SYSTEM or component
[IEEE 610.12:1990]
3.4
CHANGE REQUEST
a documented specification of a change to be made to a MEDICAL DEVICE SOFTWARE PRODUCT
3.5
CONFIGURATION ITEM
entity that can be uniquely identified at a given reference point
NOTE Based on ISO/IEC 12207:1995 2008, 3.6 4,7.
3.6
DELIVERABLE
required result or output (includes documentation) of an ACTIVITY or TASK

+AMD1:2015 CSV  IEC 2015
3.7
EVALUATION
a systematic determination of the extent to which an entity meets its specified criteria
[ISO/IEC 12207:1995 2008, 3.9 4.12]
3.8
HARM
physical injury, damage, or both to the health of people or damage to property or the
environment
[ISO/IEC Guide 51:1999, definition 3.3 ISO 14971:2007, 2.2]
3.9
HAZARD
potential source of HARM
[ISO/IEC Guide 51:1999, definition 3.5 ISO 14971:2007, 2.3]
3.10
MANUFACTURER
natural or legal person with responsibility for designing, manufacturing, packaging, or labelling
a MEDICAL DEVICE; assembling a SYSTEM; or adapting a MEDICAL DEVICE before it is placed on
the market and/or put into service, regardless of whether these operations are carried out by
that person or by a third party on that person’s behalf
NOTE 1 Attention is drawn to the fact that the provisions of national or regional regulations can apply to the
definition of manufacturer.
NOTE 2 For a definition of labelling, see ISO 13485:2003, definition 3.6.
[ISO 14971:2000 2007, 2.6 2,8]
3.11
MEDICAL DEVICE
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or
calibrator, software, material or other similar or related article, intended by the MANUFACTURER
to be used, alone or in combination, for human beings for one or more of the specific
purpose(s) of
– diagnosis, prevention, monitoring, treatment or alleviation of disease,
– diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
– investigation, replacement, modification, or support of the anatomy or of a physiological
PROCESS,
– supporting or sustaining life,
– control of conception,
– disinfection of MEDICAL DEVICES,
– providing information for medical purposes by means of in vitro examination of specimens
derived from the human body,
and which does not achieve its primary intended action in or on the human body by
pharmacological, immunological or metabolic means, but which may be assisted in its function
by such means
NOTE 1 This definition has been developed by the Global Harmonization Task Force (GHTF). See bibliographic
reference [15] (in ISO 13485:2003).
[ISO 13485:2003, definition 3.7]
NOTE 2 Some differences can occur in the definitions used in regulations of each country.
NOTE 3 In conjunction with IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012 the term “medical device”
assumes the same meaning as ME EQUIPMENT or ME SYSTEM (which are defined terms of IEC 60601-1).

– 12 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
3.12
MEDICAL DEVICE SOFTWARE
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the
MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE in its own right
NOTE This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.
3.13
PROBLEM REPORT
a record of actual or potential behaviour of a MEDICAL DEVICE SOFTWARE PRODUCT that a user or
other interested person believes to be unsafe, inappropriate for the intended use or contrary to
specification
NOTE 1 This standard does not require that every PROBLEM REPORT results in a change to the MEDICAL DEVICE
SOFTWARE PRODUCT. A MANUFACTURER can reject a PROBLEM REPORT as a misunderstanding, error or insignificant
event.
NOTE 2 A PROBLEM REPORT can relate to a released MEDICAL DEVICE SOFTWARE PRODUCT or to a MEDICAL DEVICE
SOFTWARE PRODUCT that is still under development.
NOTE 3 This standard requires the MANUFACTURER to perform extra decision making steps (see Clause 6) for a
PROBLEM REPORT relating to a released product to ensure that regulatory actions are identified and implemented.
3.14
PROCESS
ACTIVITIES that transform inputs into outputs
a set of interrelated or interacting
[ISO 9000:2000, definition 3.4.1]
NOTE The term “ACTIVITIES” covers use of resources.
3.15
REGRESSION TESTING
the testing required to determine that a change to a SYSTEM component has not adversely
affected functionality, reliability or performance and has not introduced additional defects
[ISO/IEC 90003:2004, definition 3.11]
3.16
RISK
combination of the probability of occurrence of HARM and the severity of that HARM
[ISO/IEC Guide 51:1999 definition 3.2 ISO 14971:2007, 2.16]
3.17
RISK ANALYSIS
systematic use of available information to identify HAZARDS and to estimate the RISK
[ISO/IEC Guide 51:1999 definition 3.10 ISO 14971:2007, 2.17]
3.18
RISK CONTROL
PROCESS in which decisions are made and RISKS are reduced to, or maintained within, specified
levels
[ISO 14971:2000 2007, 2.16, modified 2.19]
3.19
RISK MANAGEMENT
systematic application of management policies, procedures, and practices to the TASKS of
analyzing, evaluating, and controlling RISK
[ISO 14971:2000 2007, 2.18 2.22, modified – The phrase "and monitoring" has been removed]

+AMD1:2015 CSV  IEC 2015
3.20
RISK MANAGEMENT FILE
set of records and other documents, not necessarily contiguous, that are produced by a RISK
MANAGEMENT PROCESS
[ISO 14971:2000 2007, 2.19 2.23]
3.21
SAFETY
freedom from unacceptable RISK
[ISO/IEC Guide 51:1999 definition 3.1 ISO 14971:2007, 2.24]
3.22
SECURITY
protection of information and data so that unauthorized people persons or systems cannot read
or modify them and so that an authorized persons or systems are not denied access to them
NOTE Based on [ISO/IEC 12207:1995 2008, 3.25 4.39].
3.23
SERIOUS INJURY
injury or illness that directly or indirectly:
a) is life threatening,
b) results in permanent impairment of a body function or permanent damage to a body
structure, or
c) necessitates medical or surgical intervention to prevent permanent impairment of a body
function or permanent damage to a body structure
NOTE Permanent impairment means an irreversible impairment or damage to a body structure or function
excluding trivial impairment or damage.
3.24
SOFTWARE DEVELOPMENT LIFE CYCLE MODEL
conceptual structure spanning the life of the software from definition of its requirements to its
release for manufacturing, which:
– identifies the PROCESS, ACTIVITIES and TASKS involved in development of a MEDICAL DEVICE
SOFTWARE PRODUCT,
– describes the sequence of and dependency between ACTIVITIES and TASKS, and
– identifies the milestones at which the completeness of specified DELIVERABLES is verified.
NOTE Based on ISO/IEC 12207:1995, definition 3.11
3.25
SOFTWARE ITEM
any identifiable part of a computer program, i.e., source code, object code, control code,
control data, or a collection of these items
NOTE Three terms identify the software decomposition. The top level is the SOFTWARE SYSTEM. The lowest level
that is not further decomposed is the SOFTWARE UNIT. All levels of composition, including the top and bottom levels,
can be called SOFTWARE ITEMS. A SOFTWARE SYSTEM, then, is composed of one or more SOFTWARE ITEMS, and each
SOFTWARE ITEM is composed of one or more SOFTWARE UNITS or decomposable SOFTWARE ITEMS. The responsibility
is left to the MANUFACTURER to provide the definition and granularity of the SOFTWARE ITEMS and SOFTWARE UNITS.
NOTE 2 Based on [ISO/IEC 90003:2004, 3.14, modified and ISO/IEC 12207:2008, 4.41]

– 14 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
3.26
SOFTWARE PRODUCT
set of computer programs, procedures, and possibly associated documentation and data
[ISO/IEC 12207:1995 definition 3.26]
Not used
3.27
SOFTWARE SYSTEM
integrated collection of SOFTWARE ITEMS organized to accomplish a specific function or set of
functions
3.28
SOFTWARE UNIT
SOFTWARE ITEM that is not subdivided into other items
NOTE SOFTWARE UNITS can be used for the purpose of software configuration management or testing. The
granularity of SOFTWARE UNITS is defined by the MANUFACTURER (see B.3).
3.29
SOUP
software of unknown provenance (acronym)
SOFTWARE ITEM that is already developed and generally available and that has not been
developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-
the-shelf software”) or SOFTWARE ITEM previously developed for which adequate records of the
development PROCESSES are not available
NOTE A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP.
3.30
SYSTEM
integrated composite consisting of one or more of the PROCESSES, hardware, software,
facilities, and people, that provides a capability to satisfy a stated need or objective
NOTE Based on ISO/IEC [ISO/IEC 12207:1995 2008, 3.31 4.48].
3.31
TASK
a single piece of work that needs to be done
3.32
TRACEABILITY
degree to which a relationship can be established between two or more products of the
development PROCESS
[IEEE 610.12:1990]
NOTE Requirements, architecture, risk control measures, etc. are examples of deliverables of the development
PROCESS.
3.33
VERIFICATION
confirmation through provision of objective evidence that specified requirements have been
fulfilled
NOTE 1 “Verified” is used to designate the corresponding status.
[ISO 9000:2000, definition 3.8.4]
NOTE 2 In design and development, VERIFICATION concerns the PROCESS of examining the result of a given
ACTIVITY to determine conformity with the stated requirement for that ACTIVITY.

+AMD1:2015 CSV  IEC 2015
3.34
VERSION
identified instance of a CONFIGURATION ITEM
NOTE 1 Modification to a VERSION of a MEDICAL DEVICE SOFTWARE PRODUCT, resulting in a new VERSION, requires
software configuration management action.
NOTE 2 Based on ISO/IEC 12207:1995 2008, 3.37 4.56.
3.35
HAZARDOUS SITUATION
circumstance in which people, property or the environment are exposed to one or more
HAZARD(S)
[SOURCE: ISO 14971:2007, 2.4]
3.36
LEGACY SOFTWARE
MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today
but for which there is insufficient objective evidence that it was developed in compliance with
the current version of this standard
3.37
RELEASE
particular VERSION of a CONFIGURATION ITEM that is made available for a specific purpose
NOTE Based on ISO/IEC 12207:2008, definition 4.35.
3.38
RESIDUAL RISK
RISK remaining after RISK CONTROL measures have been taken
NOTE 1 Adapted from ISO/IEC Guide 51:1999, definition 3.9.
NOTE 2 ISO/IEC Guide 51:1999, definition 3.9 uses the term “protective measures” rather than “RISK CONTROL
measures.” However, in the context of this International Standard, “protective measures” are only one option for
controlling RISK as described in 6.2 [of ISO 14971:2007].
[SOURCE: ISO 14971:2007, 2.15].
3.39
RISK ESTIMATION
PROCESS used to assign values to the probability of occurrence of HARM and the severity of that
HARM
[SOURCE: ISO 14971:2007 2.20]
3.40
RISK EVALUATION
PROCESS of comparing the estimated RISK against given RISK criteria to determine the
acceptability of the RISK
[SOURCE: ISO 14971:2007 2.21]
4 * General requirements
4.1 * Quality management system
The MANUFACTURER of MEDICAL DEVICE SOFTWARE shall demonstrate the ability to provide
MEDICAL DEVICE SOFTWARE that consistently meets customer requirements and applicable
regulatory requirements.
– 16 – IEC 62304:2006
+AMD1:2015 CSV  IEC 2015
NOTE 1 Demonstration of this ability can be by the use of a quality management system that complies with:
- ISO 13485 [8]; or
- a national quality management system standard; or
- a quality management system required by national regulation.
NOTE 2 Guidance for applying quality management system requirements to software can be found in ISO/IEC
90003 [15].
4.2 * RISK MANAGEMENT
The MANUFACTURER shall apply a RISK MANAGEMENT PROCESS complying with ISO 14971.
4.3 * Software safety classification
a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or
RISK of HARM to the patient, operator, or other
C) according to the possible effects on
people resulting from a HAZARD HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can
contribute in a worst-case-scenario as indicated in Figure 3.
IEC
Figure 3 – Assigning software safety classification
The software safety classes shall initially be assigned based on severity as follows:
Class A: No injury or damage to health is possible
Class B: Non-SERIOUS INJURY is possible
Class C: Death or SERIOUS INJURY is possible
If the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the
probability of such failure shall be assumed to be 100 percent.
If the RISK of death or SERIOUS INJURY arising from a software failure is subsequently
reduced to an acceptable level (as defined by ISO 14971) by a hardware RISK CONTROL
measure, either by reducing the consequences of the failure or by reducing the probability
of death or SERIOUS INJURY arising from that failure, the software safety classification may
be reduced from C to B; and if the RISK of non-SERIOUS INJURY arising from a software
failure is similarly reduced to an acceptable level by a hardware RISK CONTROL measure, the
software safety classification may be reduced from B to A.

+AMD1:2015 CSV  IEC 2015
The SOFTWARE SYSTEM is software safety class A if:
– the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in
unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE
SYSTEM.
The SOFTWARE SYSTEM is software safety class B if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in
unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE
SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.
The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in
unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE
SYSTEM and the re
...

NORME CEI
INTERNATIONALE 62304
Première édition
2006-05
Logiciels de dispositifs médicaux –
Processus du cycle de vie du logiciel

Cette version française découle de la publication d’origine
bilingue dont les pages anglaises ont été supprimées.
Les numéros de page manquants sont ceux des pages
supprimées.
Numéro de référence
CEI 62304:2006(F)
Numérotation des publications
Depuis le 1er janvier 1997, les publications de la CEI sont numérotées à partir de

60000. Ainsi, la CEI 34-1 devient la CEI 60034-1.

Editions consolidées
Les versions consolidées de certaines publications de la CEI incorporant les

amendements sont disponibles. Par exemple, les numéros d’édition 1.0, 1.1 et 1.2

indiquent respectivement la publication de base, la publication de base incorporant

l’amendement 1, et la publication de base incorporant les amendements 1 et 2

Informations supplémentaires sur les publications de la CEI
Le contenu technique des publications de la CEI est constamment revu par la CEI
afin qu'il reflète l'état actuel de la technique. Des renseignements relatifs à cette
publication, y compris sa validité, sont disponibles dans le Catalogue des
publications de la CEI (voir ci-dessous) en plus des nouvelles éditions, amende-
ments et corrigenda. Des informations sur les sujets à l’étude et l’avancement des
travaux entrepris par le comité d’études qui a élaboré cette publication, ainsi que la
liste des publications parues, sont également disponibles par l’intermédiaire de:
• Site web de la CEI (www.iec.ch)
• Catalogue des publications de la CEI
Le catalogue en ligne sur le site web de la CEI (www.iec.ch/searchpub) vous permet
de faire des recherches en utilisant de nombreux critères, comprenant des
recherches textuelles, par comité d’études ou date de publication. Des informations
en ligne sont également disponibles sur les nouvelles publications, les publications
remplacées ou retirées, ainsi que sur les corrigenda.
• IEC Just Published
Ce résumé des dernières publications parues (www.iec.ch/online_news/justpub)
est aussi disponible par courrier électronique. Veuillez prendre contact avec le
Service client (voir ci-dessous) pour plus d’informations.
• Service clients
Si vous avez des questions au sujet de cette publication ou avez besoin de
renseignements supplémentaires, prenez contact avec le Service clients:
Email: custserv@iec.ch
Tél: +41 22 919 02 11
Fax: +41 22 919 03 00
NORME CEI
INTERNATIONALE 62304
Première édition
2006-05
Logiciels de dispositifs médicaux –
Processus du cycle de vie du logiciel

© IEC 2006 Droits de reproduction réservés
Aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
CODE PRIX
XC
Pour prix, voir catalogue en vigueur

– 2 – 62304  CEI:2006
SOMMAIRE
AVANT-PROPOS .6

INTRODUCTION.10

1 Domaine d'application.16

1.1 *Objet.16

1.2 * Domaine d'application .16

1.3 Relations avec d'autres normes .16

1.4 Conformité .16
2 * Références normatives.18
3 * Termes et définitions .18
4 * Exigences générales .26
4.1 * Système de management de la qualité.26
4.2 * GESTION DES RISQUES .28
4.3 * Classification de sécurité du logiciel .28
5 PROCESSUS de développement du logiciel .30
5.1 * Planification du développement du logiciel.30
5.2 * Analyses des exigences du logiciel.34
5.3 * Conception ARCHITECTURALE du logiciel .38
5.4 * Conception détaillée du logiciel .40
5.5 * Mise en œuvre et vérification des UNITÉS LOGICIELLES .40
5.6 * Intégration et essai d'intégration du logiciel.42
5.7 * Essais du SYSTÈME LOGICIEL .46
5.8 * Diffusion du logiciel .48
6 PROCESSUS de maintenance du logiciel .50
6.1 * Etablissement du plan de maintenance du logiciel .50
6.2 * Analyse des problèmes et des modifications.50
6.3 * Mise en œuvre de la modification .52
7 * PROCESSUS DE GESTION DES RISQUES du logiciel .54
7.1 * Analyse du logiciel en termes de contribution à des situations dangereuses .54
7.2 Mesures DE MAÎTRISE DU RISQUE .56
7.3 VÉRIFICATION des mesures de MAÎTRISE DU RISQUE.56
7.4 GESTION DES RISQUES des modifications du logiciel.58

8 * PROCESSUS de gestion de configuration du logiciel.58
8.1 * Identification de la configuration .58
8.2 * Maîtrise des modifications .60
8.3 * Documentation relative à l'état de la configuration .60
9 * PROCESSUS de résolution de problème logiciel .60
9.1 Elaboration des RAPPORTS DE PROBLÈME.60
9.2 Etude du problème .62
9.3 Information des parties concernées .62
9.4 Utilisation du processus de la maîtrise des modifications .62
9.5 Conservation des enregistrements .62
9.6 Analyse de tendance pour les problèmes .62
9.7 VÉRIFICATION de la résolution des problèmes du logiciel .64
9.8 Teneur de la documentation d'essai.64

– 4 – 62304  CEI:2006
Annexe A (informative) Justification des exigences de la présente norme .66

Annexe B (informative) Lignes directrices relatives aux dispositions de la présente norme.72

Annexe C (informative) Relations avec d'autres normes . 104

Annexe D (informative) Mise en œuvre. 146

Bibliographie . 150

Index des termes définis . 152

Figure 1 – Présentation générale des PROCESSUS et ACTIVITÉS de développement de
logiciels .12
Figure 2 – Présentation générale des PROCESSUS et ACTIVITÉS de maintenance de
logiciels .12
Figure B.1 – Exemple de découpage d'ÉLÉMENTS LOGICIELS .82
Figure C.1 – Relation des principales normes de DISPOSITIFS MÉDICAUX avec la
CEI 62304. 106
Figure C.2 – Logiciel comme partie du modèle en V . 110
Figure C.3 – Application de la CEI 62304 avec la CEI 61010-1 . 130

Tableau A.1 – Récapitulatif des exigences par classe de sécurité de logiciel .70
Tableau B.1 – Stratégies (modèle) de développement telles que définies dans
l’ISO/CEI 12207 .74
Tableau C.1 – Relation avec l'ISO 13485:2003 . 106
Tableau C.2 – Relation avec l'ISO 14971:2000 . 108
Tableau C.3 – Relation avec la CEI 60601-1. 114
Tableau C.4 – Relation avec la CEI 60601-1-4. 122
Tableau C.5 – Relation avec l’ISO/CEI 12207 . 134
Tableau D.1 – Liste de contrôle pour les petites entreprises sans SMQ certifié . 148

– 6 – 62304  CEI:2006
COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE

____________
LOGICIELS DE DISPOSITIFS MÉDICAUX –

PROCESSUS DU CYCLE DE VIE DU LOGICIEL

AVANT-PROPOS
1) La Commission Electrotechnique Internationale (CEI) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de la CEI). La CEI a pour objet de

favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. A cet effet, la CEI – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et des
Guides (ci-après dénommés «Publication(s) de la CEI»). Leur élaboration est confiée à des comités d'études,
aux travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec la CEI, participent également aux
travaux. La CEI collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon des
conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de la CEI concernant les questions techniques représentent, dans la mesure
du possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de la CEI
intéressés sont représentés dans chaque comité d’études.
3) Les Publications de la CEI se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de la CEI. Tous les efforts raisonnables sont entrepris afin que la CEI
s'assure de l'exactitude du contenu technique de ses publications; la CEI ne peut pas être tenue responsable de
l'éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de la CEI s'engagent, dans toute la
mesure possible, à appliquer de façon transparente les Publications de la CEI dans leurs publications
nationales et régionales. Toutes divergences entre toutes Publications de la CEI et toutes publications
nationales ou régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) La CEI n’a prévu aucune procédure de marquage valant indication d’approbation et n'engage pas sa
responsabilité pour les équipements déclarés conformes à une de ses Publications.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à la CEI, à ses administrateurs, employés, auxiliaires ou
mandataires, y compris ses experts particuliers et les membres de ses comités d'études et des Comités
nationaux de la CEI, pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre
dommage de quelque nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais
de justice) et les dépenses découlant de la publication ou de l'utilisation de cette Publication de la CEI ou de
toute autre Publication de la CEI, ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L’attention est attirée sur le fait que certains des éléments de la présente Publication de la CEI peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. La CEI ne saurait être tenue pour
responsable de ne pas avoir identifié de tels droits de propriété et de ne pas avoir signalé leur existence.
La Norme Internationale CEI 62304 a été établie par un groupe de travail mixte du sous-comité

62A: Aspects généraux des équipements utilisés en pratique médicale, du comité technique 62
de la CEI: Equipements électriques dans la pratique médicale et du comité technique 210 de
l'ISO, management de la qualité et aspects généraux correspondants des dispositifs médicaux.
Le Tableau C.5 a été préparé par le Comité Technique mixte ISO/CEI 1/SC7, Ingénierie du
logiciel et du système.
Elle est publiée comme norme portant un double logo.
Le texte de cette norme est issu des documents suivants:
FDIS Rapport de vote
62A/523/FDIS 62A/528/RVD
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à l'approbation de cette norme. A l’ISO, la norme a été approuvée par 23 membres
participants sur les 23 ayant voté.

– 8 – 62304  CEI:2006
La présente publication a été préparée conformément aux directives de l'ISO/CEI, Partie 2.

Les polices de caractère suivantes sont utilisées dans la présente norme:

• exigences et définitions: en caractères romains;

• des éléments d'information apparaissant hors des tableaux tels que les notes, les
exemples et les références: en petits caractères. Le texte normatif des tableaux est

également en petits caractères;

• les termes utilisés partout dans la présente norme, qui ont été définis dans l'article 3 et

énumérés également dans l'index: en petites majuscules.

Lorsqu'un astérisque (*) est utilisé comme premier caractère d'un titre ou au début d'un
paragraphe, il indique que des lignes directrices relatives à cet élément sont fournies en
Annexe B.
Le comité a décidé que le contenu de cette publication ne sera pas modifié avant la date de
maintenance indiquée sur le site web de la CEI sous «http://webstore.iec.ch» dans les données
relatives à la publication recherchée. A cette date, la publication sera
• reconduite;
• supprimée;
• remplacée par une édition révisée, ou
• amendée.
– 10 – 62304  CEI:2006
INTRODUCTION
Le logiciel fait souvent partie intégrante de la technologie des DISPOSITIFS MÉDICAUX. La

détermination de la SÉCURITÉ et de l'efficacité d'un DISPOSITIF MÉDICAL comportant un logiciel

exige que soit connu ce qu'il est prévu que le logiciel accomplisse et qu’il soit démontré que

son utilisation remplit ces objectifs sans entraîner de RISQUES inacceptables.

La présente norme fournit un cadre pour les PROCESSUS du cycle de vie en définissant les

ACTIVITES et TÂCHES nécessaires à la conception et à la maintenance en toute SÉCURITÉ des

LOGICIELS DE DISPOSITIFS MÉDICAUX. La présente norme fournit les exigences applicables à

chaque PROCESSUS du cycle de vie. Chaque PROCESSUS du cycle de vie est en outre divisé en

un ensemble D'ACTIVITÉS dont la plupart sont ensuite divisées en un ensemble de TÂCHES.
On suppose par principe que les LOGICIELS DE DISPOSITIFS MÉDICAUX sont développés et
maintenus dans le cadre d'un système de management de la qualité (voir 4.1) et d'un système
de GESTION DES RISQUES (voir 4.2). Le PROCESSUS DE GESTION DES RISQUES est déjà
parfaitement traité dans la Norme Internationale ISO 14971. En conséquence, la norme
CEI 62304 tire profit de cet avantage par une simple référence normative à l'ISO 14971.
Cependant, pour les logiciels, des exigences supplémentaires mineures de GESTION DES
RISQUES sont nécessaires, notamment dans le domaine de l'identification des facteurs
contributifs des logiciels en termes de DANGER. Ces exigences sont résumées et introduites
dans l'Article 7, PROCESSUS DE GESTION DES RISQUES liés au logiciel.
L'éventuelle contribution d'un logiciel à un DANGER donné est déterminée lors de L'ACTIVITÉ
d'identification des DANGERS du PROCESSUS DE GESTION DES RISQUES. LES DANGERS qui
pourraient être indirectement induits par les logiciels (par exemple la fourniture d'informations
propres à induire en erreur qui pourrait donner lieu à l'administration d'un traitement inadéquat)
doivent être pris en compte lorsqu'il s'agit de déterminer si le logiciel est un facteur contributif.
La décision d'utiliser le logiciel pour maîtriser les RISQUES est prise lors de L'ACTIVITÉ DE
MAÎTRISE DES RISQUES du PROCESSUS DE GESTION DES RISQUES. Le PROCESSUS DE GESTION DES
RISQUES lié au logiciel prescrit dans la présente norme doit être intégré au PROCESSUS DE
GESTION DES RISQUES lié au dispositif conformément à l'ISO 14971.
Le PROCESSUS de développement des logiciels couvre un certain nombre d'ACTIVITÉS. Ces
ACTIVITÉS sont illustrées en Figure 1 et décrites dans l'Article 5. Parce qu'il est notoire que de
nombreux incidents sur le terrain sont liés à l'entretien ou à la maintenance des SYSTÈMES DE
DISPOSITIFS MÉDICAUX comprenant des mises à jour et des mises à niveau inadéquates du
logiciel, on considère que le PROCESSUS de maintenance des logiciels est aussi important que
le PROCESSUS de développement des logiciels. Le PROCESSUS de maintenance des logiciels est
très similaire au PROCESSUS de développement des logiciels. Cela est illustré en Figure 2 et
décrit dans l'Article 6.
– 12 – 62304  CEI:2006
IEC  722/06
Figure 1 – Présentation générale des PROCESSUS et
ACTIVITÉS de développement de logiciels

IEC  723/06
Figure 2 – Présentation générale des PROCESSUS et ACTIVITÉS de maintenance de logiciels
La présente norme identifie deux PROCESSUS additionnels considérés comme essentiels pour
le développement de LOGICIELS DE DISPOSITIFS MÉDICAUX sûrs. Il s'agit du PROCESSUS de
gestion de la configuration du logiciel (Article 8) et du PROCESSUS de résolution des problèmes
de logiciel (Article 9).
– 14 – 62304  CEI:2006
La présente norme ne prescrit aucune structure organisationnelle pour le FABRICANT et
n'entend pas spécifier quelle organisation doit réaliser tel ou tel PROCESSUS, ACTIVITÉ ou TÂCHE.

La présente norme exige uniquement que le PROCESSUS, l'ACTIVITÉ ou la TÂCHE soit mené à

bien pour assurer la conformité à la présente norme.

La présente norme ne prescrit pas de désignation, de format ou de contenu explicite de la

documentation à produire. Elle exige que les TÂCHES soient documentées, mais c'est à

l'utilisateur de décider de la manière dont la documentation correspondante doit être

présentée.
La présente norme ne prescrit pas un modèle de cycle de vie spécifique. Il incombe aux

utilisateurs de la présente norme de choisir un modèle de cycle de vie pour un projet de logiciel
et de faire correspondre les PROCESSUS, ACTIVITÉS et TÂCHES définis dans la présente norme
avec ce modèle.
L’Annexe A fournit une justification des articles de la présente norme. L’Annexe B donne des
conseils relatifs aux dispositions de la présente norme.
Pour les besoins de la présente norme:
• «doit» signifie qu'une exigence donnée est obligatoire pour être conforme à la présente
norme;
• «il convient de – est recommandé» signifie qu'une exigence donnée est recommandée
mais n'est pas obligatoire pour être conforme à la présente norme;
• «peut – est admis» est utilisé pour décrire une manière autorisée pour être conforme à une
prescription donnée;
• «établir» signifie définir, documenter et mettre en œuvre; et
• Lorsque la présente norme utilise l'expression «si nécessaire» ou «le cas échéant»,
conjointement à un PROCESSUS, une ACTIVITÉ, une TÂCHE ou un résultat exigés, cela signifie
que le FABRICANT doit utiliser le PROCESSUS, l'ACTIVITÉ, la TÂCHE ou le résultat et dans le cas
contraire il doit justifier sa décision par écrit.

– 16 – 62304  CEI:2006
LOGICIELS DE DISPOSITIFS MÉDICAUX –

PROCESSUS DU CYCLE DE VIE DU LOGICIEL

1 Domaine d'application
1.1 *Objet
La présente norme définit les exigences du cycle de vie des LOGICIELS DE DISPOSITIFS
MÉDICAUX. L'ensemble des PROCESSUS, ACTIVITÉS et TÂCHES décrit dans la présente norme
constitue un cadre commun pour les PROCESSUS du cycle de vie des LOGICIELS DE DISPOSITIFS
MÉDICAUX.
1.2 * Domaine d'application
La présente norme s'applique au développement et à la maintenance des LOGICIELS DE
DISPOSITIFS MÉDICAUX.
La présente norme s'applique au développement et à la maintenance des LOGICIELS DE
lorsque le logiciel est un DISPOSITIF MÉDICAL ou lorsque le logiciel est
DISPOSITIFS MÉDICAUX
incorporé ou fait partie intégrante du DISPOSITIF MÉDICAL final.
La présente norme ne couvre pas la validation et la mise sur le marché du DISPOSITIF MÉDICAL,
même lorsque le DISPOSITIF MÉDICAL est intégralement constitué du logiciel.
1.3 Relations avec d'autres normes
La présente norme couvrant le cycle de vie des LOGICIELS DE DISPOSITIFS MÉDICAUX doit être
utilisée conjointement à d'autres normes pertinentes pour le développement d'un DISPOSITIF
MÉDICAL. L’Annexe C présente les relations existant entre la présente norme et d'autres
normes pertinentes.
1.4 Conformité
La conformité à la présente norme est définie comme la mise en œuvre de tous les
PROCESSUS, ACTIVITÉS et TÂCHES identifiés dans la présente norme en fonction de la classe de
sécurité.
NOTE Les classes de sécurité du logiciel assignées à chaque exigence sont identifiées dans le texte normatif
suivant l’exigence.
La conformité est déterminée par inspection de toute documentation exigée par la présente
norme y compris le DOSSIER DE GESTION DES RISQUES et l’évaluation des PROCESSUS, ACTIVITÉS
et TÂCHES requis pour la classe de SÉCURITÉ du logiciel. Voir l'Annexe D.
NOTE 1 Cette évaluation peut être effectuée par audit interne ou externe.
NOTE 2 Même lorsque les PROCESSUS, ACTIVITÉS et TÂCHES sont effectivement réalisés, il existe une certaine
flexibilité dans les méthodes de mise en œuvre de ces PROCESSUS et d'exécution de ces ACTIVITÉS et TÂCHEs.
NOTE 3 Lorsqu'une éventuelle exigence comporte la mention «le cas échéant» ou «si nécessaire» et qu'elle n'est
pas réalisée, une justification écrite est nécessaire pour cette évaluation.
NOTE 4 Dans la version anglaise de l’ISO/CEI 12207 le terme «conformance» est utilisé pour «conformité», alors
que dans la version anglaise de la présente norme, on utilise le terme «compliance».

– 18 – 62304  CEI:2006
2 * Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent

document. Pour les références datées, seule l'édition citée s'applique. Pour les références non

datées, la dernière édition du document de référence s'applique (y compris les éventuels

amendements).
ISO 14971, Dispositifs médicaux – Application de la gestion des risques aux dispositifs

médicaux.
3 *Termes et définitions
Pour les besoins du présent document, les termes et les définitions qui suivent s'appliquent.
3.1
ACTIVITÉ
ensemble d'une ou de plusieurs TÂCHES corrélées ou interactives
3.2
ANOMALIE
tout état qui s'écarte de ce qui est attendu sur la base des spécifications des exigences, des
documents de conception, des normes, etc., ou qui ne correspond pas à la perception ou à
l'expérience d'un individu donné. Les ANOMALIES peuvent être décelées, sans limitation aucune,
pendant la revue, l’essai, l'analyse, la compilation ou l'utilisation des PRODUITS LOGICIELS ou de
la documentation applicable
[IEEE 1044:1993, définition 3.1]
3.3
ARCHITECTURE
structure organisationnelle d'un SYSTÈME ou d'un composant
[IEEE 610.12:1990]
3.4
DEMANDE DE MODIFICATION
spécification écrite d'une modification à effectuer sur un PRODUIT LOGICIEL
3.5
ÉLÉMENT DE CONFIGURATION
entité qui peut être identifiée de manière univoque en un point de référence donné
NOTE Basé sur l’ISO/CEI 12207:1995, définition 3.6
3.6
LIVRABLE
résultat ou élément de sortie requis (y compris la documentation) d'une ACTIVITÉ ou d'une
TÂCHE
3.7
ÉVALUATION
détermination systématique de l’étendue à laquelle l’entité répond aux critères spécifiés
[ISO/CEI 12207:1995, définition 3.9]

– 20 – 62304  CEI:2006
3.8
DOMMAGE
blessure physique ou atteinte à la santé des personnes ou atteinte aux biens ou à

l'environnement
[ISO/CEI Guide 51:1999, définition 3.3]

3.9
PHÉNOMÈNE DANGEREUX (DANGER)
source potentielle de DOMMAGE
[ISO/CEI Guide 51:1999, définition 3.5]
3.10
FABRICANT
personne physique ou morale chargée de la conception, de la fabrication, du conditionnement
ou de l'étiquetage d'un DISPOSITIF MÉDICAL de l'assemblage d'un SYSTÈME ou de l'adaptation
d'un DISPOSITIF MÉDICAL avant mise sur le marché et/ou mise en service indépendamment du
fait que ces opérations soient effectuées par cette personne ou par une tierce partie pour le
compte de cette personne
[ISO 14971:2000, définition 2.6]
3.11
DISPOSITIF MÉDICAL
tout instrument, appareil, équipement, machine, dispositif, implant, réactif in vitro ou calibreur,
logiciel, matériel ou autre article similaire ou associé dont le FABRICANT prévoit qu'il soit utilisé
seul ou en association chez l'être humain pour la ou les fins spécifiques suivantes:
– diagnostic, prévention, contrôle, traitement ou atténuation d'une maladie,
– diagnostic, contrôle, traitement, atténuation ou compensation d'une blessure,
– étude, remplacement, modification ou entretien de l'anatomie ou d'un PROCESSUS
physiologique,
– entretien (artificiel) ou maintien de la vie,
– maîtrise de la conception,
– désinfection des DISPOSITIFS MÉDICAUX,
– communication d'informations à des fins médicales par un examen in vitro de spécimens
(prélèvement) provenant du corps humain,
et dont l'action principale voulue dans ou sur le corps humain, n'est pas obtenue par des
moyens pharmacologiques ou immunologiques ni par métabolisme mais dont la fonction peut
être assistée par de tels moyens

NOTE 1 Cette définition a été élaborée par le Groupe de Travail d'Harmonisation Mondiale. Voir la référence
bibliographique [15] (dans l'ISO 13485:2003).
[ISO 13485:2003, définition 3.7]
NOTE 2 Les définitions utilisées dans les réglementations de chaque pays peuvent présenter certaines
différences.
3.12
LOGICIEL DE DISPOSITIF MÉDICAL
SYSTÈME LOGICIEL qui a été développé pour être incorporé dans le DISPOSITIF MÉDICAL en cours
de développement ou qui est destiné à être utilisé comme un DISPOSITIF MÉDICAL à part entière
3.13
RAPPORT DE PROBLÈME
enregistrement du comportement réel ou potentiel d'un PRODUIT LOGICIEL qu'un utilisateur ou
une autre personne concernée considère être non sûr, inadéquat pour l'usage prévu ou
contraire aux spécifications
– 22 – 62304  CEI:2006
NOTE 1 La présente norme n'exige pas que chaque RAPPORT DE PROBLÈME donne lieu à une modification du

PRODUIT LOGICIEL. Un FABRICANT peut en effet rejeter un RAPPORT DE PROBLÈME en considérant qu'il s'agit d'un
malentendu, d'une erreur ou d'un événement insignifiant.

NOTE 2 Un RAPPORT DE PROBLÈME peut concerner un PRODUIT LOGICIEL diffusé ou encore en cours de
développement.
NOTE 3 La présente norme exige que le FABRICANT suive des étapes décisionnelles supplémentaires (voir l'Article

6) pour un RAPPORT DE PROBLÈME relatif à un produit diffusé afin de s'assurer que les mesures réglementaires

pertinentes sont correctement identifiées et mises en œuvre.

3.14
PROCESSUS
ensemble D'ACTIVITÉS corrélées ou interactives qui transforme des éléments d'entrée en

éléments de sortie
[ISO 9000:2000, définition 3.4.1]
NOTE Le terme «ACTIVITÉS» couvre l'utilisation des ressources.
3.15
ESSAI DE RÉGRESSION
essai exigé pour s’assurer qu’un changement d’un composant du SYSTÈME n’a pas altéré la
fonctionnalité, la fiabilité ou les performances et n’a pas entraîné de défauts supplémentaires
[ISO/CEI 90003:2004, définition 3.11]
3.16
RISQUE
combinaison de la probabilité d'un DOMMAGE et de sa gravité
[ISO/CEI Guide 51:1999, définition 3.2]
3.17
ANALYSE DU RISQUE
utilisation des informations disponibles pour identifier les PHÉNOMÈNES DANGEREUX (DANGERS)
et estimer le RISQUE
[ISO/CEI Guide 51:1999, définition 3.10]
3.18
MAÎTRISE DU RISQUE
PROCESSUS au cours duquel des décisions sont prises et des RISQUEs sont réduits ou
maintenus à des niveaux spécifiés
[ISO 14971:2000, définition 2.16, modifiée]

3.19
GESTION DES RISQUES
application systématique de politiques, de procédures et de pratiques de gestion aux TÂCHES
d'analyse, d'évaluation et de maîtrise du RISQUE
[ISO 14971:2000, définition 2.18]
3.20
DOSSIER DE GESTION DES RISQUES
ensemble d'enregistrements et autres documents qui ne sont pas nécessairement contigus et
qui sont produits par un PROCESSUS DE GESTION DES RISQUES
[ISO 14971:2000, définition 2.19]

– 24 – 62304  CEI:2006
3.21
SÉCURITÉ
absence de RISQUE inacceptable

[ISO/CEI Guide 51:1999, définition 3.1]

3.22
SÛRETÉ
protection des informations et des données de sorte que des personnes ou des SYSTÈMES non

autorisés ne puissent les lire ou les modifier et que l'accès à ces informations et données ne

soit pas refusé à des personnes ou des SYSTÈMES autorisés

[ISO/CEI 12207:1995, définition 3.25]
3.23
BLESSURE GRAVE
blessure ou maladie qui, directement ou indirectement:
a) menace la vie,
b) entraîne une carence permanente d'une fonction physiologique ou endommage de manière
définitive une structure du corps, ou
c) nécessite une intervention médicale ou chirurgicale pour prévenir une carence permanente
d'une fonction physiologique ou un endommagement définitif d'une structure du corps
NOTE Carence permanente signifie une carence irréversible ou un endommagement d'une structure du corps ou
d'une fonction, à l'exclusion des carences ou préjudices insignifiants.
3.24
MODÈLE DU CYCLE DE VIE DE DÉVELOPPEMENT DU LOGICIEL
structure conceptuelle couvrant la vie du logiciel depuis la définition de ses exigences jusqu’à
sa mise en fabrication et qui:
– identifie le PROCESSUS, les ACTIVITÉS et TÂCHES impliqués dans le développement d'un
PRODUIT LOGICIEL,
– décrit l’ordre et la dépendance entre ACTIVITÉS et TÂCHES, et
– identifie les repères auxquels la complétude des LIVRABLES spécifiés est vérifiée.
NOTE Basée sur la définition 3.11 de l'ISO/CEI 12207:1995
3.25
ÉLÉMENT LOGICIEL
toute partie identifiable d’un programme informatique
[ISO/CEI 90003:2004, définition 3.14, modifiée]

NOTE Trois termes identifient la décomposition du logiciel. Le niveau supérieur est le SYSTÈME LOGICIEL. Le
niveau le plus bas qui n’est pas décomposé plus en avant est l’UNITÉ LOGICIELLE. Tous les niveaux de composition,
y compris les niveaux supérieur et inférieur, peuvent être dénommés ÉLÉMENTS LOGICIEL. Un SYSTÈME LOGICIEL est
donc composé d’un ou de plusieurs ÉLÉMENTS LOGICIEL, et chaque ÉLÉMENT LOGICIEL est composé d’une ou de
plusieurs UNITÉS LOGICIELLES ou d’un ou de plusieurs ÉLÉMENTS LOGICIELS décomposables. Il incombe au FABRICANT
de fournir la définition et la granularité des ÉLÉMENTS LOGICIELS et des UNITÉS LOGICIELLES.
3.26
PRODUIT LOGICIEL
ensemble constitué de programmes informatiques, de procédures, et des données et
documentation éventuellement associées
[ISO/CEI 12207:1995, définition 3.26]
3.27
SYSTÈME LOGICIEL
ensemble intégré d'ÉLÉMENTS LOGICIELS organisé de manière à réaliser une fonction ou un
ensemble de fonctions spécifiques

– 26 – 62304  CEI:2006
3.28
UNITÉ LOGICIELLE
ÉLÉMENT LOGICIEL qui n'est pas subdivisé en d'autres éléments

NOTE Les UNITÉS LOGICIELLES peuvent être utilisées pour essais ou gestion de la configuration du logiciel.

3.29
SOUP (sigle pour l’anglais «Software Of Unknown Provenance»)

logiciel de provenance inconnue

ÉLÉMENT LOGICIEL qui est déjà développé, et généralement disponible, et qui n'a pas été

développé pour être incorporé dans le DISPOSITIF MÉDICAL (également appelé «logiciel de

série») ou logiciel précédemment développé pour lequel les enregistrements suffisants des

processus de développement ne sont pas disponibles
3.30
SYSTÈME
ensemble composite intégré constitué d'un ou de plusieurs PROCESSUS, matériels, logiciels,
fonctionnalités et individus qui fournissent une aptitude à satisfaire un besoin ou un objectif
déclaré
[ISO/CEI 12207:1995, définition 3.31]
3.31
TÂCHE
partie unique d’un travail qui doit être effectué
3.32
TRAÇABILITÉ
degré auquel une relation peut être établie entre deux ou plusieurs produits du PROCESSUS de
développement
[IEEE 610.12:1990]
3.33
VÉRIFICATION
confirmation par des preuves tangibles que les exigences spécifiées ont été satisfaites
NOTE 1 Le terme «vérifié» désigne l'état correspondant.
[ISO 9000:2000, définition 3.8.4]
NOTE 2 En conception et développement, la VÉRIFICATION est le PROCESSUS d'examen du résultat d'une ACTIVITÉ
donnée afin de déterminer la conformité à la prescription définie pour ladite ACTIVITÉ.
3.34
VERSION
instance identifiée d'un ÉLÉMENT DE CONFIGURATION
NOTE 1 La modification d'une VERSION d'un PRODUIT LOGICIEL, donnant lieu à une nouvelle VERSION exige une
action de gestion de la configuration du logiciel.
NOTE 2 Basé sur [ISO/CEI 12207:1995, définition 3.37]
4 * Exigences générales
4.1 * Système de management de la qualité
Le FABRICANT du LOGICIEL DE DISPOSITIF MÉDICAL doit démontrer la capacité à fournir un
LOGICIEL DE DISPOSITIF MÉDICAL qui réponde de manière cohérente aux exigences du client et
aux exigences réglementaires applicables.

– 28 – 62304  CEI:2006
NOTE 1 La démonstration de cette capacité peut se faire par l’utilisation d’un système de management de la

qualité conforme à:
− l'ISO 13485 [7] ; ou
− une norme nationale de système de management de la qualité ; ou

− un système de management de la qualité exigé par une réglementation nationale.

NOTE 2 L'ISO/CEI 90003 [11] fournit des lignes directrices pour l'application des exigences d'un système de

management de la qualité au logiciel.

4.2 * GESTION DES RISQUES
Le FABRICANT doit appliquer un PROCESSUS DE GESTION DES RISQUES conforme à l'ISO 14971.

4.3 * Classification de sécurité du logiciel
a) Le FABRICANT doit attribuer à chaque SYSTÈME LOGICIEL une classe de SÉCURITÉ du logiciel
(A, B ou C) en fonction des effets possibles sur le patient, l'opérateur ou d'autres
personnes résultant d'un PHÉNOMÈNE DANGEREUX auquel le SYSTÈME LOGICIEL peut
contribuer.
Les classes de SÉCURITÉ du logiciel doivent au départ être attribuées en se basant sur le
degré de sévérité suivant:
Classe A : Aucune blessure ou atteinte à la santé n'est possible
Classe B : Une BLESSURE NON GRAVE est possible
Classe C : La mort ou une BLESSURE GRAVE est possible
Si le PHÉNOMÈNE DANGEREUX peut résulter d'une défaillance du SYSTÈME LOGICIEL à se
comporter conformément aux spécifications, la probabilité d'une telle défaillance doit être
supposée de 100 %.
Si le RISQUE de mort ou de BLESSURE GRAVE provenant d’une défaillance logicielle est
ensuite ramené à un niveau acceptable (tel que défini par l’ISO 14971) par des mesures de
MAÎTRISE DES RISQUES matérielles, soit en réduisant les conséquences de la défaillance, soit
en réduisant la probabilité de mort ou de BLESSURE GRAVE provenant de cette défaillance, la
classe de sécurité du logiciel peut être ramenée de C à B. Si le RISQUE de BLESSURE non
GRAVE provenant d’une défaillance logicielle est de la même manière ramené à un niveau
acceptable par des mesures de MAÎTRISE DES RISQUES matérielles, la classe de sécurité du
logiciel peut être ramenée de B à A.
b) Le FABRICANT doit attribuer à chaque SYSTÈME LOGICIEL qui contribue à la mise en œuvre
des mesures de MAÎTRISE DES RISQUES une classe de sécurité du logiciel, fondée sur les
effets possibles du PHÉNOMÈNE DANGEREUX qui sont couverts par la mesure de MAÎTRISE DU
RISQUE.
c) Le FABRICANT doit consigner la classe de sécurité du logiciel attribuée à chaque SYSTÈME
LOGICIEL dans le dossier de GESTION DES RISQUES.

d) Lorsqu'un SYSTÈME LOGICIEL est décomposé en ÉLÉMENTS LOGICIELS et qu'un ÉLÉMENT
LOGICIEL est décomposé en d'autres ÉLÉMENTS LOGICIELS, ces ÉLÉMENTS LOGICIELs doivent
hériter de la classe de sécurité du logiciel de l'ÉLÉMENT LOGICIEL initial (ou du SYSTÈME
LOGICIEL) à moins que le FABRICANT ne justifie par écrit une classification dans une classe
différente de sécurité du logiciel. Une telle justification doit expliquer la manière dont les
nouveaux ÉLÉMENTS LOGICIELS sont différenciés pour pouvoir être classés séparément.
e) Le FABRICANT doit consigner la classe de sécurité du logiciel de chaque élément LOGICIEL si
cette classe est différente de la classe de l'ÉLÉMENT LOGICIEL à partir duquel il a été créé
par décomposition.
f) Pour la conformité à la présente norme, lorsqu'un PROCESSUS est exigé pour les ÉLÉMENTS
LOGICIELS d'une classe spécifique et que ce PROCESSUS est nécessairement appliqué à un
groupe d'ÉLÉMENTS LOGICIELS, le FABRICANT doit utiliser les PROCESSUS et TÂCHES qui sont
exigés par la classe de sécurité de l'ÉLÉMENT LOGICIEL la plus élevée définie dans le groupe
à moins que le FABRICANT ne justifie par écrit dans le dossier de GESTION DES RISQUES,
l'utilisation d'une classification plus basse.

– 30 – 62304  CEI:2006
g) Pour chaque SYSTÈME LOGICIEL, les exigences de la classe C doivent être appliquées

jusqu'à attribution d'une classe de SÉCURITÉ du logiciel.

NOTE Dans les exigences qui suivent, les classes de sécurité du logiciel pour lesquelles l’exigence doit être
réalisée sont identifiées en suivant l’exigence sous la forme [Classe.].

5 PROCESSUS de développement du logiciel

5.1 * Planification du développement du logiciel

5.1.1 Plan de développement du logiciel

Le FABRICANT doit établir un(des) plan(s) de développement du logiciel pour entreprendre des
ACTIVITÉS dU PROCESSUS DE DÉVELOPPEMENT DU LOGICIEL convenant au domaine d'application, à
l'importance et aux classes de sécurité du logiciel du SYSTÈME LOGICIEL à développer. Le
MODÈLE DE CYCLE DE VIE DE DÉVELOPPEMENT DU LOGICIEL doit être soit complètement défini, soit
référencé dans le ou les plans. Le plan doit traiter des éléments suivants:
a) les PROCESSUS à utiliser au cours du développement du SYSTÈME LOGICIEL (voir Note 4);
b) les LIVRABLES (y compris la documentation) des ACTIVITÉS et TÂCHES;
c) la TRAÇABILITÉ entre les exigences du SYSTÈME, les exigences du logiciel, les essais du
SYSTÈME LOGICIEL et les mesures de MAÎTRISE DU RISQUE mis en œuvre dans le logiciel;
d) la gestion de la configuration et des modifications du logiciel, y compris les ÉLÉMENTS DE
CONFIGURATION de LOGICIEL DE PROVENANCE INCONNUE (SOUP) utilisés à l'appui du
développement; et
e) la résolution des problèmes de logiciel pour le traitement des problèmes détectés dans les
PRODUITS LOGICIELS, dans les LIVRABLES et dans les ACTIVITÉS à chaque étape du cycle de
vie.
[Classes A, B, C]
NOTE 1 LE MODÈLE DU CYCLE DE VIE DE DÉVELOPPEMENT DU LOGICIEL peut identifier différents éléments (PROCESSUS,
ACTIVITÉS, TÂCHES et LIVRABLES) pour différents ÉLÉMENTS LOGICIELS en fonction de la classe de sécurité du logiciel
de chaque L'ÉLÉMENT LOGICIEL du SYSTÈME LOGICIEL.
NOTE 2 Il est possible que ces ACTIVITÉS et TÂCHES se chevauchent ou interagissent et elles peuvent être
réalisées de manière itérative ou récursive. La présente norme n'a pas pour but de recommander l'utilisation d'un
modèle de cycle de vie spécifique.
NOTE 3 D'autres PROCESSUS sont décrits dans la présente norme indépendamment du PROCESSUS de
développement. Ceci ne signifie pas qu'ils doivent être mis en œuvre comme des ACTIVITÉs et TÂCHES séparées.
Les ACTIVITÉS et TÂCHES des autres PROCESSUS peuvent être intégrées dans le PROCESSUS de développement.
NOTE 4 Le plan de développement du logiciel peut référencer des PROCESSUS existants ou en définir de
nouveaux.
NOTE 5 Le plan de développement du logiciel peut être intégré dans un plan de développement global du
SYSTÈME.
5.1.2 Mise à jour du plan de développement logiciel
Le FABRICANT doit mettre à jour le plan au fur et à mesure du développement, le cas échéant.
[Classes A, B, C]
5.1.3 Référence du plan de développement du logiciel à la conception et au
développement du SYSTÈME
a) Le FABRICANT doit référencer les exigences du SYSTÈME en tant qu'éléments d'entrée dans
le plan de développement du logiciel.
b) Le FABRICANT doit intégrer ou référencer dans le plan de développement du logiciel les
procédures de coordination du développement du logiciel ainsi que de validation de la
conception et du développement qui sont nécessaires POUR satisfaire aux exigences du 4.1.
[Classes A, B, C]
– 32 – 62304  CEI:2006
NOTE Il pourrait ne pas y avoir de différence entre les exigences du SYSTÈME LOGICIEL et les exigences du

SYSTÈME si le SYSTÈME LOGICIEL est un SYSTÈME autonome (dispositif uniquement logiciel).

5.1.4 Planification des normes, méthodes et outils de développement du lo
...

IEC 62304
Edition 1.0 2006-05
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Medical device software – Software life cycle processes

Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or
IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.

IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.
ƒ Catalogue des publications de la CEI: www.iec.ch/searchpub/cur_fut-f.htm
Le Catalogue en-ligne de la CEI vous permet d’effectuer des recherches en utilisant différents critères (numéro de référence,
texte, comité d’études,…). Il donne aussi des informations sur les projets et les publications retirées ou remplacées.
ƒ Just Published CEI: www.iec.ch/online_news/justpub
Restez informé sur les nouvelles publications de la CEI. Just Published détaille deux fois par mois les nouvelles
publications parues. Disponible en-ligne et aussi par email.
ƒ Electropedia: www.electropedia.org
Le premier dictionnaire en ligne au monde de termes électroniques et électriques. Il contient plus de 20 000 termes et
définitions en anglais et en français, ainsi que les termes équivalents dans les langues additionnelles. Egalement appelé
Vocabulaire Electrotechnique International en ligne.
ƒ Service Clients: www.iec.ch/webstore/custserv/custserv_entry-f.htm
Si vous désirez nous donner des commentaires sur cette publication ou si vous avez des questions, visitez le FAQ du
Service clients ou contactez-nous:
Email: csc@iec.ch
Tél.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC 62304
Edition 1.0 2006-05
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
Medical device software – Software life cycle processes

Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
XC
CODE PRIX
ICS 11.040 ISBN 2-8318-8637-6
– 2 – 62304 © IEC:2006
62304  IEC:2006 – 3 –
CONTENTS
FOREWORD.4
INTRODUCTION.6

1 Scope.9
1.1 * Purpose .9
1.2 * Field of application .9
1.3 Relationship to other standards.9
1.4 Compliance .9
2 * Normative references .10
3 * Terms and definitions .10
4 * General requirements.14
4.1 * Quality management system.14
4.2 * RISK MANAGEMENT.15
4.3 * Software safety classification.15
5 Software development PROCESS .16
5.1 * Software development planning .16
5.2 * Software requirements analysis .18
5.3 * Software ARCHITECTURAL design .20
5.4 * Software detailed design .21
5.5 * SOFTWARE UNIT implementation and verification.21
5.6 * Software integration and integration testing .22
5.7 * SOFTWARE SYSTEM testing.24
5.8 * Software release .25
6 Software maintenance PROCESS .26
6.1 * Establish software maintenance plan .26
6.2 * Problem and modification analysis.26
6.3 * Modification implementation .27
7 * Software RISK MANAGEMENT PROCESS .28
7.1 * Analysis of software contributing to hazardous situations .28
7.2 RISK CONTROL measures .29
7.3 VERIFICATION of RISK CONTROL measures.29
7.4 RISK MANAGEMENT of software changes .30
8 * Software configuration management PROCESS.30
8.1 * Configuration identification .30
8.2 * Change control.31
8.3 * Configuration status accounting.31
9 * Software problem resolution PROCESS.31
9.1 Prepare PROBLEM REPORTS.31
9.2 Investigate the problem.32
9.3 Advise relevant parties .32
9.4 Use change control process.32
9.5 Maintain records .32
9.6 Analyse problems for trends .32
9.7 Verify software problem resolution .33
9.8 Test documentation contents .33

62304 © IEC:2006 – 3 –
62304  IEC:2006 – 5 –
Annex A (informative) Rationale for the requirements of this standard.34
Annex B (informative) Guidance on the provisions of this standard .37
Annex C (informative) Relationship to other standards.53
Annex D (informative) Implementation .74

Bibliography .

Index of defined terms.77

Figure 1 – Overview of software development PROCESSES and ACTIVITIES.7
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES.7
Figure B.1 – Example of partitioning of SOFTWARE ITEMS .42
Figure C.1 – Relationship of key MEDICAL DEVICE standards to IEC 62304 .54
Figure C.2 – Software as part of the V-model .56
Figure C.3 – Application of IEC 62304 with IEC 61010-1.66

Table A.1 – Summary of requirements by software safety class .36
Table B.1 – Development (model) strategies as defined at ISO/IEC 12207.38
Table C.1 – Relationship to ISO 13485:2003 .54
Table C.2 – Relationship to ISO 14971:2000 .55
Table C.3 – Relationship to IEC 60601-1 .58
Table C.4 – Relationship to IEC 60601-1-4 .62
Table C.5 – Relationship to ISO/IEC 12207 .68
Table D.1 – Checklist for small companies without a certified QMS.75

– 4 – 62304 © IEC:2006
62304  IEC:2006 – 7 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62304 has been prepared by a joint working group of subcommittee
62A: Common aspects of electrical equipment used in medical practice, of IEC technical
committee 62: Electrical equipment in medical practice and ISO Technical Committee 210,
MEDICAL DEVICES. Table C.5 was
Quality management and corresponding general aspects for
prepared by ISO/IEC JTC 1/SC 7, Software and system engineering.
It is published as a dual logo standard.
The text of this standard is based on the following documents:
FDIS Report on voting
62A/523/FDIS 62A/528/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table. In ISO, the standard has been approved by 23 P-members
out of 23 having cast a vote.
62304 © IEC:2006 – 5 –
62304  IEC:2006 – 9 –
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
In this standard the following print types are used:
• requirements and definitions: in roman type;
• informative material appearing outside of tables, such as notes, examples and references:
in smaller type. Normative text of tables is also in a smaller type;
• terms used throughout this standard that have been defined in Clause 3 and also given in
the index: in small capitals.
An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that
there is guidance related to that item in Annex B.
The committee has decided that the contents of this publication will remain unchanged until the
maintenance result date indicated on the IEC web site under “http://webstore.iec.ch” in the data
related to the specific publication. At this date, the publication will be
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
– 6 – 62304 © IEC:2006
62304  IEC:2006 – 11 –
INTRODUCTION
Software is often an integral part of MEDICAL DEVICE technology. Establishing the SAFETY and
effectiveness of a MEDICAL DEVICE containing software requires knowledge of what the software
is intended to do and demonstration that the use of the software fulfils those intentions without
causing any unacceptable RISKS.
This standard provides a framework of life cycle PROCESSES with ACTIVITIES and TASKS
necessary for the safe design and maintenance of MEDICAL DEVICE SOFTWARE. This standard
provides requirements for each life cycle PROCESS. Each life cycle PROCESS is further divided
into a set of ACTIVITIES, with most ACTIVITIES further divided into a set of TASKS.
As a basic foundation it is assumed that MEDICAL DEVICE SOFTWARE is developed and
maintained within a quality management system (see 4.1) and a RISK MANAGEMENT system (see
4.2). The RISK MANAGEMENT PROCESS is already very well addressed by the International
Standard ISO 14971. Therefore IEC 62304 makes use of this advantage simply by a normative
reference to ISO 14971. Some minor additional RISK MANAGEMENT requirements are needed for
software, especially in the area of identification of contributing software factors related to
HAZARDS. These requirements are summarized and captured in Clause 7 as the software RISK
MANAGEMENT PROCESS.
Whether software is a contributing factor to a HAZARD is determined during the HAZARD
identification ACTIVITY of the RISK MANAGEMENT PROCESS. HAZARDS that could be indirectly
caused by software (for example, by providing misleading information that could cause
inappropriate treatment to be administered) need to be considered when determining whether
software is a contributing factor. The decision to use software to control RISK is made during
the RISK CONTROL ACTIVITY of the RISK MANAGEMENT PROCESS. The software RISK MANAGEMENT
PROCESS required in this standard has to be embedded in the device RISK MANAGEMENT
PROCESS according to ISO 14971.
The software development PROCESS consists of a number of ACTIVITIES. These ACTIVITIES are
shown in Figure 1 and described in Clause 5. Because many incidents in the field are related to
service or maintenance of MEDICAL DEVICE SYSTEMS including inappropriate software updates
and upgrades, the software maintenance PROCESS is considered to be as important as the
software development PROCESS. The software maintenance PROCESS is very similar to the
software development PROCESS. It is shown in Figure 2 and described in Clause 6.

62304 © IEC:2006 – 7 –
62304  IEC:2006 – 13 –
IEC  722/06
Figure 1 – Overview of software development PROCESSES and ACTIVITIES

IEC  723/06
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES
This standard identifies two additional PROCESSES considered essential for developing safe
MEDICAL DEVICE SOFTWARE. They are the software configuration management PROCESS (Clause
8) and the software problem resolution PROCESS (Clause 9).

– 8 – 62304 © IEC:2006
62304  IEC:2006 – 15 –
This standard does not specify an organizational structure for the MANUFACTURER or which part
of the organization is to perform which PROCESS, ACTIVITY, or TASK. This standard requires only
that the PROCESS, ACTIVITY, or TASK be completed to establish compliance with this standard.
This standard does not prescribe the name, format, or explicit content of the documentation to
be produced. This standard requires documentation of TASKS, but the decision of how to
package this documentation is left to the user of the standard.
This standard does not prescribe a specific life cycle model. The users of this standard are
responsible for selecting a life cycle model for the software project and for mapping the
PROCESSES, ACTIVITIES, and TASKS in this standard onto that model.
Annex A provides rationale for the clauses of this standard. Annex B provides guidance on the
provisions of this standard.
For the purposes of this standard:
• “shall” means that compliance with a requirement is mandatory for compliance with this
standard;
• “should” means that compliance with a requirement is recommended but is not mandatory
for compliance with this standard;
• “may” is used to describe a permissible way to achieve compliance with a requirement;
• “establish” means to define, document, and implement; and
• where this standard uses the term “as appropriate” in conjunction with a required PROCESS,
ACTIVITY, TASK or output, the intention is that the MANUFACTURER shall use the PROCESS,
ACTIVITY, TASK or output unless the MANUFACTURER can document a justification for not so
doing.
62304 © IEC:2006 – 9 –
62304  IEC:2006 – 17 –
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for MEDICAL DEVICE SOFTWARE. The set of
PROCESSES, ACTIVITIES, and TASKS described in this standard establishes a common framework
for MEDICAL DEVICE SOFTWARE life cycle PROCESSES.
1.2 * Field of application
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE.
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE when
software is itself a MEDICAL DEVICE or when software is an embedded or integral part of the final
MEDICAL DEVICE.
MEDICAL DEVICE, even when the
This standard does not cover validation and final release of the
MEDICAL DEVICE consists entirely of software.
1.3 Relationship to other standards
This MEDICAL DEVICE SOFTWARE life cycle standard is to be used together with other appropriate
standards when developing a MEDICAL DEVICE. Annex C shows the relationship between this
standard and other relevant standards.
1.4 Compliance
Compliance with this standard is defined as implementing all of the PROCESSES, ACTIVITIES, and
TASKS identified in this standard in accordance with the software safety class.
NOTE The software safety classes assigned to each requirement are identified in the normative text following the
requirement.
Compliance is determined by inspection of all documentation required by this standard
including the RISK MANAGEMENT FILE, and assessment of the PROCESSES, ACTIVITIES and TASKS
required for the software safety class. See Annex D.
NOTE 1 This assessment could be carried out by internal or external audit.
NOTE 2 Although the specified PROCESSES, ACTIVITIES, and TASKS are performed, flexibility exists in the methods
of implementing these PROCESSES and performing these ACTIVITIES and TASKS.
NOTE 3 Where any requirements contain “as appropriate” and were not performed, documentation for the
justification is necessary for this assessment.
NOTE 4 The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.

– 10 – 62304 © IEC:2006
62304  IEC:2006 – 19 –
2 * Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
ISO 14971, Medical devices – Application of risk management to medical devices.
3 * Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ACTIVITY
a set of one or more interrelated or interacting TASKS
3.2
ANOMALY
any condition that deviates from the expected based on requirements specifications, design
documents, standards, etc. or from someone’s perceptions or experiences. ANOMALIES may be
found during, but not limited to, the review, test, analysis, compilation, or use of SOFTWARE
PRODUCTS or applicable documentation
[IEEE 1044:1993, definition 3.1]
3.3
ARCHITECTURE
organizational structure of a SYSTEM or component
[IEEE 610.12:1990]
3.4
CHANGE REQUEST
a documented specification of a change to be made to a SOFTWARE PRODUCT
3.5
CONFIGURATION ITEM
entity that can be uniquely identified at a given reference point
NOTE Based on ISO/IEC 12207:1995, definition 3.6.
3.6
DELIVERABLE
required result or output (includes documentation) of an ACTIVITY or TASK
3.7
EVALUATION
a systematic determination of the extent to which an entity meets its specified criteria
[ISO/IEC 12207:1995, definition 3.9]

62304 © IEC:2006 – 11 –
62304  IEC:2006 – 21 –
3.8
HARM
physical injury, damage, or both to the health of people or damage to property or the
environment
[ISO/IEC Guide 51:1999, definition 3.3]
3.9
HAZARD
potential source of HARM
[ISO/IEC Guide 51:1999, definition 3.5]
3.10
MANUFACTURER
natural or legal person with responsibility for designing, manufacturing, packaging, or labelling
a MEDICAL DEVICE; assembling a SYSTEM; or adapting a MEDICAL DEVICE before it is placed on
the market and/or put into service, regardless of whether these operations are carried out by
that person or by a third party on that person’s behalf
[ISO 14971:2000, definition 2.6]
3.11
MEDICAL DEVICE
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or
calibrator, software, material or other similar or related article, intended by the MANUFACTURER
to be used, alone or in combination, for human beings for one or more of the specific
purpose(s) of
– diagnosis, prevention, monitoring, treatment or alleviation of disease,
– diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
– investigation, replacement, modification, or support of the anatomy or of a physiological
PROCESS,
– supporting or sustaining life,
– control of conception,
– disinfection of MEDICAL DEVICES,
– providing information for medical purposes by means of in vitro examination of specimens
derived from the human body,
and which does not achieve its primary intended action in or on the human body by
pharmacological, immunological or metabolic means, but which may be assisted in its function
by such means
NOTE 1 This definition has been developed by the Global Harmonization Task Force (GHTF). See bibliographic
reference [15] (in ISO 13485:2003).
[ISO 13485:2003, definition 3.7]
NOTE 2 Some differences can occur in the definitions used in regulations of each country.
3.12
MEDICAL DEVICE SOFTWARE
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the
MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE in its own right
3.13
PROBLEM REPORT
a record of actual or potential behaviour of a SOFTWARE PRODUCT that a user or other interested
person believes to be unsafe, inappropriate for the intended use or contrary to specification

– 12 – 62304 © IEC:2006
62304  IEC:2006 – 23 –
NOTE 1 This standard does not require that every PROBLEM REPORT results in a change to the SOFTWARE PRODUCT.
A MANUFACTURER can reject a PROBLEM REPORT as a misunderstanding, error or insignificant event.
NOTE 2 A PROBLEM REPORT can relate to a released SOFTWARE PRODUCT or to a SOFTWARE PRODUCT that is still
under development.
NOTE 3 This standard requires the MANUFACTURER to perform extra decision making steps (see Clause 6) for a
PROBLEM REPORT relating to a released product to ensure that regulatory actions are identified and implemented.
3.14
PROCESS
a set of interrelated or interacting ACTIVITIES that transform inputs into outputs
[ISO 9000:2000, definition 3.4.1]
NOTE The term “ACTIVITIES” covers use of resources.
3.15
REGRESSION TESTING
the testing required to determine that a change to a SYSTEM component has not adversely
affected functionality, reliability or performance and has not introduced additional defects
[ISO/IEC 90003:2004, definition 3.11]
3.16
RISK
combination of the probability of occurrence of HARM and the severity of that HARM
[ISO/IEC Guide 51:1999 definition 3.2]
3.17
RISK ANALYSIS
systematic use of available information to identify HAZARDS and to estimate the RISK
[ISO/IEC Guide 51:1999 definition 3.10]
3.18
RISK CONTROL
PROCESS in which decisions are made and RISKS are reduced to, or maintained within, specified
levels
[ISO 14971:2000 definition 2.16, modified]
3.19
RISK MANAGEMENT
systematic application of management policies, procedures, and practices to the TASKS of
analyzing, evaluating, and controlling RISK
[ISO 14971:2000 definition 2.18]
3.20
RISK MANAGEMENT FILE
set of records and other documents, not necessarily contiguous, that are produced by a RISK
MANAGEMENT PROCESS
[ISO 14971:2000 definition 2.19]

62304 © IEC:2006 – 13 –
62304  IEC:2006 – 25 –
3.21
SAFETY
freedom from unacceptable RISK
[ISO/IEC Guide 51:1999 definition 3.1]
3.22
SECURITY
protection of information and data so that unauthorized people or SYSTEMS cannot read or
modify them and so that authorized persons or SYSTEMS are not denied access to them
[ISO/IEC 12207:1995 definition 3.25]
3.23
SERIOUS INJURY
injury or illness that directly or indirectly:
a) is life threatening,
b) results in permanent impairment of a body function or permanent damage to a body
structure, or
c) necessitates medical or surgical intervention to prevent permanent impairment of a body
function or permanent damage to a body structure
NOTE Permanent impairment means an irreversible impairment or damage to a body structure or function
excluding trivial impairment or damage.
3.24
SOFTWARE DEVELOPMENT LIFE CYCLE MODEL
conceptual structure spanning the life of the software from definition of its requirements to its
release for manufacturing, which:
– identifies the PROCESS, ACTIVITIES and TASKS involved in development of a SOFTWARE
PRODUCT,
– describes the sequence of and dependency between ACTIVITIES and TASKS, and
– identifies the milestones at which the completeness of specified DELIVERABLES is verified.
NOTE Based on ISO/IEC 12207:1995, definition 3.11
3.25
SOFTWARE ITEM
any identifiable part of a computer program
[ISO/IEC 90003:2004, definition 3.14, modified]
NOTE Three terms identify the software decomposition. The top level is the SOFTWARE SYSTEM. The lowest level
that is not further decomposed is the SOFTWARE UNIT. All levels of composition, including the top and bottom levels,
can be called SOFTWARE ITEMS. A SOFTWARE SYSTEM, then, is composed of one or more SOFTWARE ITEMS, and each
SOFTWARE ITEM is composed of one or more SOFTWARE UNITS or decomposable SOFTWARE ITEMS. The responsibility
is left to the MANUFACTURER to provide the definition and granularity of the SOFTWARE ITEMS and SOFTWARE UNITS.
3.26
SOFTWARE PRODUCT
set of computer programs, procedures, and possibly associated documentation and data
[ISO/IEC 12207:1995 definition 3.26]
3.27
SOFTWARE SYSTEM
integrated collection of SOFTWARE ITEMS organized to accomplish a specific function or set of
functions
– 14 – 62304 © IEC:2006
62304  IEC:2006 – 27 –
3.28
SOFTWARE UNIT
SOFTWARE ITEM that is not subdivided into other items
NOTE SOFTWARE UNITS can be used for the purpose of software configuration management or testing.
3.29
SOUP
software of unknown provenance (acronym)
SOFTWARE ITEM that is already developed and generally available and that has not been
developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-
the-shelf software”) or software previously developed for which adequate records of the
development PROCESSES are not available
3.30
SYSTEM
integrated composite consisting of one or more of the PROCESSES, hardware, software,
facilities, and people, that provides a capability to satisfy a stated need or objective
[ISO/IEC 12207:1995, definition 3.31]
3.31
TASK
a single piece of work that needs to be done
3.32
TRACEABILITY
degree to which a relationship can be established between two or more products of the
development PROCESS
[IEEE 610.12:1990]
3.33
VERIFICATION
confirmation through provision of objective evidence that specified requirements have been
fulfilled
NOTE 1 “Verified” is used to designate the corresponding status.
[ISO 9000:2000, definition 3.8.4]
NOTE 2 In design and development, VERIFICATION concerns the PROCESS of examining the result of a given
ACTIVITY to determine conformity with the stated requirement for that ACTIVITY.
3.34
VERSION
identified instance of a CONFIGURATION ITEM
NOTE 1 Modification to a VERSION of a SOFTWARE PRODUCT, resulting in a new VERSION, requires software
configuration management action.
NOTE 2 Based on ISO/IEC 12207:1995, definition 3.37.
4 * General requirements
4.1 * Quality management system
The MANUFACTURER of MEDICAL DEVICE SOFTWARE shall demonstrate the ability to provide
MEDICAL DEVICE SOFTWARE that consistently meets customer requirements and applicable
regulatory requirements.
62304 © IEC:2006 – 15 –
62304  IEC:2006 – 29 –
NOTE 1 Demonstration of this ability can be by the use of a quality management system that complies with:
- ISO 13485 [7]; or
- a national quality management system standard; or
- a quality management system required by national regulation.
NOTE 2 Guidance for applying quality management system requirements to software can be found in ISO/IEC
90003 [11].
4.2 * RISK MANAGEMENT
The MANUFACTURER shall apply a RISK MANAGEMENT PROCESS complying with ISO 14971.
4.3 * Software safety classification
a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or
C) according to the possible effects on the patient, operator, or other people resulting from
a HAZARD to which the SOFTWARE SYSTEM can contribute.
The software safety classes shall initially be assigned based on severity as follows:
Class A: No injury or damage to health is possible
Class B: Non-SERIOUS INJURY is possible
Class C: Death or SERIOUS INJURY is possible
If the HAZARD could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the
probability of such failure shall be assumed to be 100 percent.
If the RISK of death or SERIOUS INJURY arising from a software failure is subsequently
reduced to an acceptable level (as defined by ISO 14971) by a hardware RISK CONTROL
measure, either by reducing the consequences of the failure or by reducing the probability
of death or SERIOUS INJURY arising from that failure, the software safety classification may
be reduced from C to B; and if the RISK of non-SERIOUS INJURY arising from a software
failure is similarly reduced to an acceptable level by a hardware RISK CONTROL measure, the
software safety classification may be reduced from B to A.
b) The MANUFACTURER shall assign to each SOFTWARE SYSTEM that contributes to the
implementation of a RISK CONTROL measure a software safety class based on the possible
effects of the HAZARD that the RISK CONTROL measure is controlling.
c) The MANUFACTURER shall document the software safety class assigned to each SOFTWARE
SYSTEM in the RISK MANAGEMENT FILE.
d) When a SOFTWARE SYSTEM is decomposed into SOFTWARE ITEMS, and when a SOFTWARE
ITEM is decomposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit the
software safety classification of the original SOFTWARE ITEM (or SOFTWARE SYSTEM) unless
the MANUFACTURER documents a rationale for classification into a different software safety
class. Such a rationale shall explain how the new SOFTWARE ITEMS are segregated so that
they may be classified separately.
e) The MANUFACTURER shall document the software safety class of each SOFTWARE ITEM if that
class is different from the class of the SOFTWARE ITEM from which it was created by
decomposition.
f) For compliance with this standard, wherever a PROCESS is required for SOFTWARE ITEMS of a
specific classification and the PROCESS is necessarily applied to a group of SOFTWARE
ITEMS, the MANUFACTURER shall use the PROCESSES and TASKS which are required by the
classification of the highest-classified SOFTWARE ITEM in the group unless the
MANUFACTURER documents in the RISK MANAGEMENT FILE a rationale for using a lower
classification.
– 16 – 62304 © IEC:2006
62304  IEC:2006 – 31 –
g) For each SOFTWARE SYSTEM, until a software safety class is assigned, Class C
requirements shall apply.
NOTE In the requirements that follow, the software safety classes that the requirement must be performed for are
identified following the requirement in the form [Class . . .].
5 Software development PROCESS
5.1 * Software development planning
5.1.1 Software development plan
The MANUFACTURER shall establish a software development plan (or plans) for conducting the
ACTIVITIES of the software development PROCESS appropriate to the scope, magnitude, and
software safety classifications of the SOFTWARE SYSTEM to be developed. The sOFTWARE
DEVELOPMENT LIFE CYCLE MODEL shall either be fully defined or be referenced in the plan (or
plans). The plan shall address the following:
a) the PROCESSES to be used in the development of the SOFTWARE SYSTEM (see Note 4);
b) the DELIVERABLES (includes documentation) of the ACTIVITIES and TASKS;
c) TRACEABILITY between SYSTEM requirements, software requirements, SOFTWARE SYSTEM
test, and RISK CONTROL measures implemented in software;
d) software configuration and change management, including SOUP CONFIGURATION ITEMS and
software used to support development; and
e) software problem resolution for handling problems detected in the SOFTWARE PRODUCTS,
DELIVERABLES and ACTIVITIES at each stage of the life cycle.
[Class A, B, C]
NOTE 1 The SOFTWARE DEVELOPMENT LIFE CYCLE MODEL can identify different elements (PROCESSES, ACTIVITIES,
TASKS and DELIVERABLES) for different SOFTWARE ITEMS according to the software safety classification of each
SOFTWARE ITEM of the SOFTWARE SYSTEM.
NOTE 2 These ACTIVITIES and TASKS can overlap or interact and can be performed iteratively or recursively. It is not
the intent to imply that a specific life cycle model should be used.
NOTE 3 Other PROCESSES are described in this standard separately from the development PROCESS. This does not
imply that they must be implemented as separate ACTIVITIES and TASKS. The ACTIVITIES and TASKS of the other
PROCESSES can be integrated into the development PROCESS.
NOTE 4 The software development plan can reference existing PROCESSES or define new ones.
NOTE 5 The software development plan may be integrated in an overall SYSTEM development plan.
5.1.2 Keep software development plan updated
The MANUFACTURER shall update the plan as development proceeds as appropriate. [Class A,
B, C]
5.1.3 Software development plan reference to SYSTEM design and development
a) As inputs for software development, SYSTEM requirements shall be referenced in the
software development plan by the MANUFACTURER.
b) The MANUFACTURER shall include or reference in the software development plan procedures
for coordinating the software development and the design and development validation
necessary to satisfy 4.1.
[Class A, B, C]
62304 © IEC:2006 – 17 –
62304  IEC:2006 – 33 –
NOTE There might not be a difference between SOFTWARE SYSTEM requirements and SYSTEM requirements if the
SOFTWARE SYSTEM is a stand alone SYSTEM (software-only device).
5.1.4 Software development standards, methods and tools planning
The MANUFACTURER shall include or reference in the software development plan:
a) standards,
b) methods, and
c) tools
associated with the development of SOFTWARE ITEMS of class C. [Class C]
5.1.5 Software integration and integration testing planning
The MANUFACTURER shall include or reference in the software development plan, a plan to
integrate the SOFTWARE ITEMS (including SOUP) and perform testing during integration. [Class B,
C]
NOTE It is acceptable to combine integration testing and SOFTWARE SYSTEM testing into a single plan and set of
ACTIVITIES.
5.1.6 Software VERIFICATION planning
The MANUFACTURER shall include or reference in the software development plan the following
VERIFICATION information:
a) DELIVERABLES requiring VERIFICATION;
b) the required VERIFICATION TASKS for each life cycle ACTIVITY;
c) milestones at which the DELIVERABLES are VERIFIED; and
d) the acceptance criteria for VERIFICATION of the DELIVERABLES.
[Class A, B, C]
5.1.7 Software RISK MANAGEMENT planning
The MANUFACTURER shall include or reference in the software development plan, a plan to
conduct the ACTIVITIES and TASKS of the software RISK MANAGEMENT PROCESS, including the
management of RISKS relating to SOUP. [Class A, B, C]
NOTE See Clause 7.
5.1.8 Documentation planning
The MANUFACTURER shall include or reference in the software development plan information
about the documents to be produced during the software development life cycle. For each
identified document or type of document the following information shall be included or
referenced:
a) title, name or naming convention;
b) purpose;
c) intended audience of document; and
d) procedures and responsibilities for development, review, approval and modification.
[Class A, B, C]
– 18 – 62304 © IEC:2006
62304  IEC:2006 – 35 –
5.1.9 Software configuration management planning
The MANUFACTURER shall include or reference software configuration management information
in the software development plan. The software configuration management information shall
include or reference:
a) the classes, types, categories or lists of items to be controlled;
b) the software configuration management ACTIVITIES and TASKS;
c) the organization(s) responsible for performing software configuration management and
ACTIVITIES;
d) their relationship with other organizations, such as software development or maintenance;
e) when the items are to be placed under configuration control; and
f) when the problem resolution PROCESS is to be used.
[Class A, B, C]
5.1.10 Supporting items to be controlled
The items to be controlled shall include tools, items or settings, used to develop the MEDICAL
DEVICE SOFTWARE, which could impact the MEDICAL DEVICE SOFTWARE. [Class B, C]
N
...

IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Medical device software – Software life cycle processes

Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC
copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or
your local IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org
The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,
variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English
committee,…). It also gives information on projects, replaced and French, with equivalent terms in 16 additional languages.
and withdrawn publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished
Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary
details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and
once a month by email. French extracted from the Terms and definitions clause of
IEC publications issued between 2002 and 2015. Some
IEC Customer Service Centre - webstore.iec.ch/csc entries have been collected from earlier publications of IEC
If you wish to give us your feedback on this publication or TC 37, 77, 86 and CISPR.

need further assistance, please contact the Customer Service

Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC - Electropedia - www.electropedia.org
webstore.iec.ch/advsearchform Le premier dictionnaire d'électrotechnologie en ligne au
La recherche avancée permet de trouver des publications IEC monde, avec plus de 22 000 articles terminologiques en
en utilisant différents critères (numéro de référence, texte, anglais et en français, ainsi que les termes équivalents dans
comité d’études,…). Elle donne aussi des informations sur les 16 langues additionnelles. Egalement appelé Vocabulaire
projets et les publications remplacées ou retirées. Electrotechnique International (IEV) en ligne.

IEC Just Published - webstore.iec.ch/justpublished Glossaire IEC - std.iec.ch/glossary
Restez informé sur les nouvelles publications IEC. Just 67 000 entrées terminologiques électrotechniques, en anglais
Published détaille les nouvelles publications parues. et en français, extraites des articles Termes et définitions des
Disponible en ligne et une fois par mois par email. publications IEC parues entre 2002 et 2015. Plus certaines
entrées antérieures extraites des publications des CE 37, 77,
Service Clients - webstore.iec.ch/csc 86 et CISPR de l'IEC.

Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-nous:
sales@iec.ch.
IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Medical device software – Software life cycle processes

Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 11.140 ISBN 978-2-8322-2765-7

IEC 62304
Edition 1.1 2015-06
CONSOLIDATED VERSION
REDLINE VERSION
VERSION REDLINE
colour
inside
Medical device software – Software life cycle processes

Logiciels de dispositifs médicaux – Processus du cycle de vie du logiciel

– 2 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
INTRODUCTION to Amendment 1 . 8
1 Scope . 9
1.1 * Purpose . 9
1.2 * Field of application . 9
1.3 Relationship to other standards . 9
1.4 Compliance . 10
2 * Normative references . 10
3 * Terms and definitions . 10
4 * General requirements . 16
4.1 * Quality management system . 16
4.2 * RISK MANAGEMENT . 16
4.3 * Software safety classification . 16
4.4 * LEGACY SOFTWARE . 18
5 Software development PROCESS . 19
5.1 * Software development planning . 19
5.2 * Software requirements analysis . 21
5.3 * Software ARCHITECTURAL design . 23
5.4 * Software detailed design . 24
5.5 * SOFTWARE UNIT implementation and verification . 25
5.6 * Software integration and integration testing . 26
5.7 * SOFTWARE SYSTEM testing . 27
5.8 * Software RELEASE for utilization at a SYSTEM level . 28
6 Software maintenance PROCESS . 29
6.1 * Establish software maintenance plan . 29
6.2 * Problem and modification analysis . 30
6.3 * Modification implementation . 31
7 * Software RISK MANAGEMENT PROCESS . 31
7.1 * Analysis of software contributing to hazardous situations . 31
7.2 RISK CONTROL measures . 32
7.3 VERIFICATION of RISK CONTROL measures . 32
7.4 RISK MANAGEMENT of software changes . 33
8 * Software configuration management PROCESS. 33
8.1 * Configuration identification . 33
8.2 * Change control . 34
8.3 * Configuration status accounting . 34
9 * Software problem resolution PROCESS . 34
9.1 Prepare PROBLEM REPORTS . 34
9.2 Investigate the problem. 35
9.3 Advise relevant parties . 35
9.4 Use change control process . 35
9.5 Maintain records . 35
9.6 Analyse problems for trends . 35
9.7 Verify software problem resolution . 36

 IEC 2015
9.8 Test documentation contents . 36
Annex A (informative) Rationale for the requirements of this standard. 37
Annex B (informative) Guidance on the provisions of this standard . 40
Annex C (informative) Relationship to other standards . 58
Annex D (informative) Implementation . 84
Bibliography . 86
Index of defined terms . 88

Figure 1 – Overview of software development PROCESSES and ACTIVITIES . 7
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES . 7
Figure 3 – Assigning software safety classification . 16
Figure B.2 – Pictorial representation of the relationship of HAZARD, sequence of events,
HAZARDOUS SITUATION, and HARM – from ISO 14971:2007 Annex E . 44
Figure B.1 – Example of partitioning of SOFTWARE ITEMS . 46
Figure C.1 – Relationship of key MEDICAL DEVICE standards to IEC 62304 . 59
Figure C.2 – Software as part of the V-model . 62
Figure C.3 – Application of IEC 62304 with IEC 61010-1 . 72

Table A.1 – Summary of requirements by software safety class . 39
Table B.1 – Development (model) strategies as defined in ISO/IEC 12207 . 41
Table C.1 – Relationship to ISO 13485:2003 . 60
Table C.2 – Relationship to ISO 14971:2000 2007 . 61
Table C.3 – Relationship to IEC 60601-1 . 64
Table C.4 – Relationship to IEC 60601-1-4 .
Table C.5 – Relationship to ISO/IEC 12207:2008 . 74
Table D.1 – Checklist for small companies without a certified QMS . 85

– 4 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and non-
governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
This consolidated version of the official IEC Standard and its amendment has been prepared
for user convenience.
IEC 62304 edition 1.1 contains the first edition (2006-05) [documents 62A/523/FDIS and 62A/528/
RVD] and its amendment 1 (2015-06) [documents 62A/1007/FDIS and 62A/1014/RVD].
In this Redline version, a vertical line in the margin shows where the technical content is
modified by amendment 1. Additions are in green text, deletions are in strikethrough red text. A
separate Final version with all changes accepted is available in this publication.

 IEC 2015
International Standard IEC 62304 has been prepared by a joint working group of subcommittee
62A: Common aspects of electrical equipment used in medical practice, of IEC technical
committee 62: Electrical equipment in medical practice and ISO Technical Committee 210,
Quality management and corresponding general aspects for MEDICAL DEVICES. Table C.5 was
prepared by ISO/IEC JTC 1/SC 7, Software and system engineering.
It is published as a dual logo standard.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
In this standard the following print types are used:
• requirements and definitions: in roman type;
• informative material appearing outside of tables, such as notes, examples and references:
in smaller type. Normative text of tables is also in a smaller type;
• terms used throughout this standard that have been defined in Clause 3 and also given in
the index: in small capitals.
An asterisk (*) as the first character of a title or at the beginning of a paragraph indicates that
there is guidance related to that item in Annex B.
The committee has decided that the contents of the base publication and its amendment will
remain unchanged until the stability date indicated on the IEC web site under
"http://webstore.iec.ch" in the data related to the specific publication. At this date, the
publication will be
• reconfirmed,
• withdrawn,
• replaced by a revised edition, or
• amended.
NOTE The attention of National Committees is drawn to the fact that equipment MANUFACTURERS and testing
organizations may need a transitional period following publication of a new, amended or revised IEC or
ISO publication in which to make products in accordance with the new requirements and to equip themselves for
conducting new or revised tests. It is the recommendation of the committee that the content of this publication be
adopted for mandatory implementation nationally not earlier than 3 years from the date of publication.

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.

– 6 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
INTRODUCTION
Software is often an integral part of MEDICAL DEVICE technology. Establishing the SAFETY and
effectiveness of a MEDICAL DEVICE containing software requires knowledge of what the software
is intended to do and demonstration that the use of the software fulfils those intentions without
causing any unacceptable RISKS.
This standard provides a framework of life cycle PROCESSES with ACTIVITIES and TASKS
necessary for the safe design and maintenance of MEDICAL DEVICE SOFTWARE. This standard
provides requirements for each life cycle PROCESS. Each life cycle PROCESS is further divided
into consists of a set of ACTIVITIES, with most ACTIVITIES further divided into consisting of a set
of TASKS.
As a basic foundation it is assumed that MEDICAL DEVICE SOFTWARE is developed and
maintained within a quality management system (see 4.1) and a RISK MANAGEMENT system (see
4.2). The RISK MANAGEMENT PROCESS is already very well addressed by the International
Standard ISO 14971. Therefore IEC 62304 makes use of this advantage simply by a normative
reference to ISO 14971. Some minor additional RISK MANAGEMENT requirements are needed for
software, especially in the area of identification of contributing software factors related to
HAZARDS. These requirements are summarized and captured in Clause 7 as the software RISK
MANAGEMENT PROCESS.
Whether software is a contributing factor to a HAZARD HAZARDOUS SITUATION is determined
during the HAZARD identification ACTIVITY of the RISK MANAGEMENT PROCESS. HAZARDS
HAZARDOUS SITUATIONS that could be indirectly caused by software (for example, by providing
misleading information that could cause inappropriate treatment to be administered) need to be
considered when determining whether software is a contributing factor. The decision to use
software to control RISK is made during the RISK CONTROL ACTIVITY of the RISK MANAGEMENT
PROCESS. The software RISK MANAGEMENT PROCESS required in this standard has to be
embedded in the device RISK MANAGEMENT PROCESS according to ISO 14971.
The software development PROCESS consists of a number of ACTIVITIES. These ACTIVITIES are
shown in Figure 1 and described in Clause 5. Because many incidents in the field are related to
service or maintenance of MEDICAL DEVICE SYSTEMS including inappropriate software updates
and upgrades, the software maintenance PROCESS is considered to be as important as the
software development PROCESS. The software maintenance PROCESS is very similar to the
software development PROCESS. It is shown in Figure 2 and described in Clause 6.

 IEC 2015
Activities outside the scope of this standard
Customer needs
Customer needs
satisfied
SYSTEM development ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT
5.1 5.2 5.3 5.4 5.5 5.6
5.7
Software Software Software Software Software UNIT Software integration 5.8
Software SYSTEM
development requirements ARCHITECTURAL detailed implementation and and integration Software release
testing
planning analysis design design VERIFICATION testing
8 Software configuration management
9 Software problem resolution
IEC  722/06
Figure 1 – Overview of software development PROCESSES and ACTIVITIES
Activities outside the scope of this standard
Maintenance Request
request satisfied
System maintenance ACTIVITIES (including RISK MANAGEMENT)
7 Software RISK MANAGEMENT
5.3 5.4 5.5 5.6
5.7
6.2
6.1
Software Software Software UNIT Software integration 5.8
Software SYSTEM
Problem and
Establish software
ARCHITECTURAL detailed implementation and and integration Software release
modification analysis
maintenance testing
design design VERIFICATION testing
plan
6.3 Modification implementation
8 Software configuration management
9 Software problem resolution

IEC  723/06
Figure 2 – Overview of software maintenance PROCESSES and ACTIVITIES
This standard identifies two additional PROCESSES considered essential for developing safe
MEDICAL DEVICE SOFTWARE. They are the software configuration management PROCESS (Clause
8) and the software problem resolution PROCESS (Clause 9).
Amendment 1 updates the standard to add requirements to deal with LEGACY SOFTWARE, where
the software design is prior to the existence of the current version, to assist manufacturers who
must show compliance to the standard to meet European Directives. Software safety

– 8 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
classification changes include clarification of requirements and updating of the software safety
classification to include a risk-based approach.
This standard does not specify an organizational structure for the MANUFACTURER or which part
of the organization is to perform which PROCESS, ACTIVITY, or TASK. This standard requires only
that the PROCESS, ACTIVITY, or TASK be completed to establish compliance with this standard.
This standard does not prescribe the name, format, or explicit content of the documentation to
be produced. This standard requires documentation of TASKS, but the decision of how to
package this documentation is left to the user of the standard.
This standard does not prescribe a specific life cycle model. The users of this standard are
responsible for selecting a life cycle model for the software project and for mapping the
PROCESSES, ACTIVITIES, and TASKS in this standard onto that model.
Annex A provides rationale for the clauses of this standard. Annex B provides guidance on the
provisions of this standard.
For the purposes of this standard:
• “shall” means that compliance with a requirement is mandatory for compliance with this
standard;
• “should” means that compliance with a requirement is recommended but is not mandatory
for compliance with this standard;
• “may” is used to describe a permissible way to achieve compliance with a requirement;
• “establish” means to define, document, and implement; and
• where this standard uses the term “as appropriate” in conjunction with a required PROCESS,
ACTIVITY, TASK or output, the intention is that the MANUFACTURER shall use the PROCESS,
ACTIVITY, TASK or output unless the MANUFACTURER can document a justification for not so
doing.
INTRODUCTION to Amendment 1
The first edition of IEC 62304 was published in 2006. This amendment is intended to add
requirements to deal with LEGACY SOFTWARE, where the software design is prior to the
existence of the current version, to assist manufacturers who must show compliance to the
standard to meet European Directives. Software safety classification changes needed for this
amendment include clarification of requirements and updating of the software safety
classification to include a risk-based approach. Work is continuing in parallel to develop the
second edition of IEC 62304.
 IEC 2015
MEDICAL DEVICE SOFTWARE –
SOFTWARE LIFE CYCLE PROCESSES
1 Scope
1.1 * Purpose
This standard defines the life cycle requirements for MEDICAL DEVICE SOFTWARE. The set of
PROCESSES, ACTIVITIES, and TASKS described in this standard establishes a common framework
for MEDICAL DEVICE SOFTWARE life cycle PROCESSES.
1.2 * Field of application
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE.
This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE when
software is itself a MEDICAL DEVICE or when software is an embedded or integral part of the final
MEDICAL DEVICE.
NOTE 1 This standard can be used in the development and maintenance of software that is itself a medical
device. However, additional development activities are needed at the system level before this type of software can
be placed into service. These system activities are not covered by this standard, but can be found in IEC 82304-1
[22].
This standard describes PROCESSES that are intended to be applied to software which executes
on a processor or which is executed by other software (for example an interpreter) which
executes on a processor.
This standard applies regardless of the persistent storage device(s) used to store the software
(for example: hard disk, optical disk, permanent or flash memory).
This standard applies regardless of the method of delivery of the software (for example:
transmission by network or email, optical disk, flash memory or EEPROM). The method of
software delivery itself is not considered MEDICAL DEVICE SOFTWARE.
This standard does not cover validation and final release of the MEDICAL DEVICE, even when the
MEDICAL DEVICE consists entirely of software.
NOTE 2 If a medical device incorporates embedded software intended to be executed on a processor, the
requirements of this standard apply to the software, including the requirements concerning software of unknown
provenance (see 8.1.2).
NOTE 3 Validation and other development activities are needed at the system level before the software and
medical device can be placed into service. These system activities are not covered by this standard, but can be
found in related product standards (e.g., IEC 60601-1, IEC 82304-1, etc.).
1.3 Relationship to other standards
This MEDICAL DEVICE SOFTWARE life cycle standard is to be used together with other appropriate
standards when developing a MEDICAL DEVICE. Annex C shows the relationship between this
standard and other relevant standards.
___________
In preparation.
– 10 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
1.4 Compliance
Compliance with this standard is defined as implementing all of the PROCESSES, ACTIVITIES, and
TASKS identified in this standard in accordance with the software safety class.
NOTE The software safety classes assigned to each requirement are identified in the normative text following the
requirement.
Compliance is determined by inspection of all documentation required by this standard
including the RISK MANAGEMENT FILE, and assessment of the PROCESSES, ACTIVITIES and TASKS
required for the software safety class. See Annex D.
NOTE 1 This assessment could be carried out by internal or external audit.
NOTE 2 Although the specified PROCESSES, ACTIVITIES, and TASKS are performed, flexibility exists in the methods
of implementing these PROCESSES and performing these ACTIVITIES and TASKS.
NOTE 3 Where any requirements contain “as appropriate” and were not performed, documentation for the
justification is necessary for this assessment.
NOTE 4 The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this standard.
NOTE 5 For compliance of LEGACY SOFTWARE see 4.4.
2 * Normative references
The following referenced documents are indispensable for the application of this document. For
dated references, only the edition cited applies. For undated references, the latest edition of
the referenced document (including any amendments) applies.
ISO 14971, Medical devices – Application of risk management to medical devices.
3 * Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
ACTIVITY
a set of one or more interrelated or interacting TASKS
3.2
ANOMALY
any condition that deviates from the expected based on requirements specifications, design
documents, standards, etc. or from someone’s perceptions or experiences. ANOMALIES may be
found during, but not limited to, the review, test, analysis, compilation, or use of MEDICAL
DEVICE SOFTWARE PRODUCTS or applicable documentation
NOTE Based on [IEEE 1044:1993, definition 3.1].
3.3
ARCHITECTURE
organizational structure of a SYSTEM or component
[IEEE 610.12:1990]
3.4
CHANGE REQUEST
a documented specification of a change to be made to a MEDICAL DEVICE SOFTWARE PRODUCT
3.5
CONFIGURATION ITEM
entity that can be uniquely identified at a given reference point

 IEC 2015
NOTE Based on ISO/IEC 12207:1995 2008, 3.6 4,7.
3.6
DELIVERABLE
required result or output (includes documentation) of an ACTIVITY or TASK
3.7
EVALUATION
a systematic determination of the extent to which an entity meets its specified criteria
[ISO/IEC 12207:1995 2008, 3.9 4.12]
3.8
HARM
physical injury, damage, or both to the health of people or damage to property or the
environment
[ISO/IEC Guide 51:1999, definition 3.3 ISO 14971:2007, 2.2]
3.9
HAZARD
potential source of HARM
[ISO/IEC Guide 51:1999, definition 3.5 ISO 14971:2007, 2.3]
3.10
MANUFACTURER
natural or legal person with responsibility for designing, manufacturing, packaging, or labelling
a MEDICAL DEVICE; assembling a SYSTEM; or adapting a MEDICAL DEVICE before it is placed on
the market and/or put into service, regardless of whether these operations are carried out by
that person or by a third party on that person’s behalf
NOTE 1 Attention is drawn to the fact that the provisions of national or regional regulations can apply to the
definition of manufacturer.
NOTE 2 For a definition of labelling, see ISO 13485:2003, definition 3.6.
[ISO 14971:2000 2007, 2.6 2,8]
3.11
MEDICAL DEVICE
any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or
calibrator, software, material or other similar or related article, intended by the MANUFACTURER
to be used, alone or in combination, for human beings for one or more of the specific
purpose(s) of
– diagnosis, prevention, monitoring, treatment or alleviation of disease,
– diagnosis, monitoring, treatment, alleviation of or compensation for an injury,
– investigation, replacement, modification, or support of the anatomy or of a physiological
PROCESS,
– supporting or sustaining life,
– control of conception,
– disinfection of MEDICAL DEVICES,
– providing information for medical purposes by means of in vitro examination of specimens
derived from the human body,
and which does not achieve its primary intended action in or on the human body by
pharmacological, immunological or metabolic means, but which may be assisted in its function
by such means
NOTE 1 This definition has been developed by the Global Harmonization Task Force (GHTF). See bibliographic
reference [15] (in ISO 13485:2003).

– 12 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
[ISO 13485:2003, definition 3.7]
NOTE 2 Some differences can occur in the definitions used in regulations of each country.
NOTE 3 In conjunction with IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012 the term “medical device”
assumes the same meaning as ME EQUIPMENT or ME SYSTEM (which are defined terms of IEC 60601-1).
3.12
MEDICAL DEVICE SOFTWARE
SOFTWARE SYSTEM that has been developed for the purpose of being incorporated into the
MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE in its own right
NOTE This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.
3.13
PROBLEM REPORT
a record of actual or potential behaviour of a MEDICAL DEVICE SOFTWARE PRODUCT that a user or
other interested person believes to be unsafe, inappropriate for the intended use or contrary to
specification
NOTE 1 This standard does not require that every PROBLEM REPORT results in a change to the MEDICAL DEVICE
SOFTWARE PRODUCT. A MANUFACTURER can reject a PROBLEM REPORT as a misunderstanding, error or insignificant
event.
NOTE 2 A PROBLEM REPORT can relate to a released MEDICAL DEVICE SOFTWARE PRODUCT or to a MEDICAL DEVICE
SOFTWARE PRODUCT that is still under development.
NOTE 3 This standard requires the MANUFACTURER to perform extra decision making steps (see Clause 6) for a
PROBLEM REPORT relating to a released product to ensure that regulatory actions are identified and implemented.
3.14
PROCESS
a set of interrelated or interacting ACTIVITIES that transform inputs into outputs
[ISO 9000:2000, definition 3.4.1]
NOTE The term “ACTIVITIES” covers use of resources.
3.15
REGRESSION TESTING
SYSTEM component has not adversely
the testing required to determine that a change to a
affected functionality, reliability or performance and has not introduced additional defects
[ISO/IEC 90003:2004, definition 3.11]
3.16
RISK
combination of the probability of occurrence of HARM and the severity of that HARM
[ISO/IEC Guide 51:1999 definition 3.2 ISO 14971:2007, 2.16]
3.17
RISK ANALYSIS
systematic use of available information to identify HAZARDS and to estimate the RISK
[ISO/IEC Guide 51:1999 definition 3.10 ISO 14971:2007, 2.17]
3.18
RISK CONTROL
PROCESS in which decisions are made and RISKS are reduced to, or maintained within, specified
levels
[ISO 14971:2000 2007, 2.16, modified 2.19]

 IEC 2015
3.19
RISK MANAGEMENT
systematic application of management policies, procedures, and practices to the TASKS of
analyzing, evaluating, and controlling RISK
[ISO 14971:2000 2007, 2.18 2.22, modified – The phrase "and monitoring" has been removed]
3.20
RISK MANAGEMENT FILE
set of records and other documents, not necessarily contiguous, that are produced by a RISK
MANAGEMENT PROCESS
[ISO 14971:2000 2007, 2.19 2.23]
3.21
SAFETY
freedom from unacceptable RISK
[ISO/IEC Guide 51:1999 definition 3.1 ISO 14971:2007, 2.24]
3.22
SECURITY
protection of information and data so that unauthorized people persons or systems cannot read
or modify them and so that an authorized persons or systems are not denied access to them
NOTE Based on [ISO/IEC 12207:1995 2008, 3.25 4.39].
3.23
SERIOUS INJURY
injury or illness that directly or indirectly:
a) is life threatening,
b) results in permanent impairment of a body function or permanent damage to a body
structure, or
c) necessitates medical or surgical intervention to prevent permanent impairment of a body
function or permanent damage to a body structure
NOTE Permanent impairment means an irreversible impairment or damage to a body structure or function
excluding trivial impairment or damage.
3.24
SOFTWARE DEVELOPMENT LIFE CYCLE MODEL
conceptual structure spanning the life of the software from definition of its requirements to its
release for manufacturing, which:
– identifies the PROCESS, ACTIVITIES and TASKS involved in development of a MEDICAL DEVICE
SOFTWARE PRODUCT,
– describes the sequence of and dependency between ACTIVITIES and TASKS, and
– identifies the milestones at which the completeness of specified DELIVERABLES is verified.
NOTE Based on ISO/IEC 12207:1995, definition 3.11
3.25
SOFTWARE ITEM
any identifiable part of a computer program, i.e., source code, object code, control code,
control data, or a collection of these items
NOTE Three terms identify the software decomposition. The top level is the SOFTWARE SYSTEM. The lowest level
that is not further decomposed is the SOFTWARE UNIT. All levels of composition, including the top and bottom levels,
can be called SOFTWARE ITEMS. A SOFTWARE SYSTEM, then, is composed of one or more SOFTWARE ITEMS, and each
SOFTWARE ITEM is composed of one or more SOFTWARE UNITS or decomposable SOFTWARE ITEMS. The responsibility
is left to the MANUFACTURER to provide the definition and granularity of the SOFTWARE ITEMS and SOFTWARE UNITS.
NOTE 2 Based on [ISO/IEC 90003:2004, 3.14, modified and ISO/IEC 12207:2008, 4.41]

– 14 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
3.26
SOFTWARE PRODUCT
set of computer programs, procedures, and possibly associated documentation and data
[ISO/IEC 12207:1995 definition 3.26]
Not used
3.27
SOFTWARE SYSTEM
integrated collection of SOFTWARE ITEMS organized to accomplish a specific function or set of
functions
3.28
SOFTWARE UNIT
SOFTWARE ITEM that is not subdivided into other items
NOTE SOFTWARE UNITS can be used for the purpose of software configuration management or testing. The
granularity of SOFTWARE UNITS is defined by the MANUFACTURER (see B.3).
3.29
SOUP
software of unknown provenance (acronym)
SOFTWARE ITEM that is already developed and generally available and that has not been
developed for the purpose of being incorporated into the MEDICAL DEVICE (also known as “off-
the-shelf software”) or SOFTWARE ITEM previously developed for which adequate records of the
development PROCESSES are not available
NOTE A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP.
3.30
SYSTEM
integrated composite consisting of one or more of the PROCESSES, hardware, software,
facilities, and people, that provides a capability to satisfy a stated need or objective
NOTE Based on ISO/IEC [ISO/IEC 12207:1995 2008, 3.31 4.48].
3.31
TASK
a single piece of work that needs to be done
3.32
TRACEABILITY
degree to which a relationship can be established between two or more products of the
development PROCESS
[IEEE 610.12:1990]
NOTE Requirements, architecture, risk control measures, etc. are examples of deliverables of the development
PROCESS.
3.33
VERIFICATION
confirmation through provision of objective evidence that specified requirements have been
fulfilled
NOTE 1 “Verified” is used to designate the corresponding status.
[ISO 9000:2000, definition 3.8.4]
NOTE 2 In design and development, VERIFICATION concerns the PROCESS of examining the result of a given
ACTIVITY to determine conformity with the stated requirement for that ACTIVITY.

 IEC 2015
3.34
VERSION
identified instance of a CONFIGURATION ITEM
NOTE 1 Modification to a VERSION of a MEDICAL DEVICE SOFTWARE PRODUCT, resulting in a new VERSION, requires
software configuration management action.
NOTE 2 Based on ISO/IEC 12207:1995 2008, 3.37 4.56.
3.35
HAZARDOUS SITUATION
circumstance in which people, property or the environment are exposed to one or more
HAZARD(S)
[SOURCE: ISO 14971:2007, 2.4]
3.36
LEGACY SOFTWARE
MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today
but for which there is insufficient objective evidence that it was developed in compliance with
the current version of this standard
3.37
RELEASE
particular VERSION of a CONFIGURATION ITEM that is made available for a specific purpose
NOTE Based on ISO/IEC 12207:2008, definition 4.35.
3.38
RESIDUAL RISK
RISK remaining after RISK CONTROL measures have been taken
NOTE 1 Adapted from ISO/IEC Guide 51:1999, definition 3.9.
NOTE 2 ISO/IEC Guide 51:1999, definition 3.9 uses the term “protective measures” rather than “RISK CONTROL
measures.” However, in the context of this International Standard, “protective measures” are only one option for
controlling RISK as described in 6.2 [of ISO 14971:2007].
[SOURCE: ISO 14971:2007, 2.15].
3.39
RISK ESTIMATION
PROCESS used to assign values to the probability of occurrence of HARM and the severity of that
HARM
[SOURCE: ISO 14971:2007 2.20]
3.40
RISK EVALUATION
PROCESS of comparing the estimated RISK against given RISK criteria to determine the
acceptability of the RISK
[SOURCE: ISO 14971:2007 2.21]
– 16 – IEC 62304:2006+AMD1:2015 CSV
 IEC 2015
4 * General requirements
4.1 * Quality management system
The MANUFACTURER of MEDICAL DEVICE SOFTWARE shall demonstrate the ability to provide
MEDICAL DEVICE SOFTWARE that consistently meets customer requirements and appl
...