SIST EN 62304:2006

SLOVENSKI SIST EN 62304:2006
STANDARD
oct 2006
Programska oprema za medicinske aparate – Procesi v življenjskem ciklu
programske opreme (IEC 62304:2006)
Medical device software - Software life-cycle processes (IEC 62304:2006)
ICS 13.020.60; 35.240.80 Referenčna številka
©  Standard je založil in izdal Slovenski inštitut za standardizacijo. Razmnoževanje ali kopiranje celote ali delov tega dokumenta ni dovoljeno

EUROPEAN STANDARD
EN 62304
NORME EUROPÉENNE
July 2006
EUROPÄISCHE NORM
ICS 11.040
English version
Medical device software -
Software life-cycle processes
(IEC 62304:2006)
Logiciels de dispositifs médicaux - Medizingeräte-Software -
Processus du cycle de vie du logiciel Software-Lebenszyklus-Prozesse
(CEI 62304:2006) (IEC 62304:2006)

This European Standard was approved by CENELEC on 2006-06-01. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and notified
to the Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Cyprus, the Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Central Secretariat: rue de Stassart 35, B - 1050 Brussels

© 2006 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62304:2006 E
Foreword
The text of document 62A/523/FDIS, future edition 1 of IEC 62304, prepared by a joint working group of
SC 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, was submitted to the IEC-CENELEC parallel
vote and was approved by CENELEC as EN 62304 on 2006-06-01.
The following dates were fixed:
– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2007-03-01
– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2009-06-01
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.
Table C.5 was prepared by ISO/IEC JTC 1/SC 7, Software and system engineering.
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 62304:2006 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards indicated:
IEC 60601-1-4 + A1 NOTE  Harmonized as EN 60601-1-4:1996 + A1:1999 (not modified).
IEC 61508-3 NOTE  Harmonized as EN 61508-3:2001 (not modified).
IEC 61010-1 NOTE  Harmonized as EN 61010-1:2001 (not modified).
ISO 9000 NOTE  Harmonized as EN ISO 9000:2005 (not modified).
ISO 9001 NOTE  Harmonized as EN ISO 9001:2000 (not modified).
ISO 13485 NOTE  Harmonized as EN ISO 13485:2003 (not modified).
IEC 60601-1-6 NOTE  Harmonized as EN 60601-1-6:2004 (not modified).
__________
- 3 - EN 62304:2006
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

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.

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year

1) 2)
ISO 14971 - Medical devices - Application of risk EN ISO 14971 2000
management to medical devices
1)
Undated reference.
2)
Valid edition at date of issue.

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