IEC/TR 80002-3:2014

IEC TR 80002-3
Edition 1.0 2014-06
INTERNATIONAL
STANDARD
Medical device software –
Part 3: Process reference model of medical device software life cycle processes
(IEC 62304)
IEC TR 80002-3:2014-06(en)

---------------------- Page: 1 ----------------------
THIS PUBLICATION IS COPYRIGHT PROTECTED
Copyright © 2014 IEC, Geneva, Switzerland

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é Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland 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.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bi bliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14

documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.

---------------------- Page: 2 ----------------------
IEC TR 80002-3


Edition 1.0 2014-06




INTERNATIONAL



STANDARD



















Medical device software –

Part 3: Process reference model of medical device software life cycle processes

(IEC 62304)


























INTERNATIONAL

ELECTROTECHNICAL

COMMISSION

PRICE CODE
U




ICS 11.040.01 ISBN 978-2-8322-1616-3



  Warning! Make sure that you obtained this publication from an authorized distributor.

---------------------- Page: 3 ----------------------
– 2 – IEC TR 80002-3:2014 © IEC 2014
CONTENTS

FOREWORD . 3
INTRODUCTION . 5
0.1 Background . 5
0.2 Organization of this technical report . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Medical device software life cycle processes . 7
4.1 Software development process . 7
4.1.1 Software development planning . 7
4.1.2 Software requirements analysis . 8
4.1.3 Software architectural design . 8
4.1.4 Software detailed design . 9
4.1.5 Software unit implementation and verification . 9
4.1.6 Software integration and integration testing . 10
4.1.7 Software system testing . 10
4.1.8 Software release . 11
4.2 Software maintenance . 11
4.2.1 Purpose . 11
4.2.2 Outcomes . 11
4.3 Software risk management . 12
4.3.1 Purpose . 12
4.3.2 Outcomes . 12
4.4 Software configuration management . 13
4.4.1 Purpose . 13
4.4.2 Outcomes . 13
4.5 Software problem resolution. 14
4.5.1 Purpose . 14
4.5.2 Outcomes . 14
Annex A (informative) Development of this technical report . 16
Annex B (informative) Mapping between IEC 62304:2006 and ISO/IEC 12207:2008 . 18
Bibliography . 28

Figure A.1 – Requirements in process elements of IEC 62304:2006 and
ISO/IEC 12207:2008 . 16
Figure A.2 – Development of process outcomes for medical device software
development PRM . 17

Table A.1 – Direct process mappings between IEC 62304:2006 and
ISO/IEC 12207:2008 . 17
Table B.1 – Mapping between process outcomes of the PRM and the requirements of
IEC 62304:2006, including their safety classes, and the requirements of
ISO/IEC 12207:2008 (1 of 9) . 19

---------------------- Page: 4 ----------------------
IEC TR 80002-3:2014 © IEC 2014 – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________

MEDICAL DEVICE SOFTWARE –

Part 3: Process reference model of medical
device software life cycle processes (IEC 62304)

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.
The main task of IEC technical committees is to prepare International Standards. However, a
technical committee may propose the publication of a technical report when it has collected
data of a different kind from that which is normally published as an International Standard, for
example "state of the art".
IEC TR 80002-3, which is a technical report, 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.
It is published as a double logo standard.

---------------------- Page: 5 ----------------------
– 4 – IEC TR 80002-3:2014 © IEC 2014
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
62A/918/DTR 62A/928/RVC

Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table. In ISO, the technical report has been approved
by 14 P members out of 16 having cast a vote.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2 and in
accordance with ISO/IEC 24774, Systems and software engineering – Life cycle management
– Guidelines for process description.
A list of all parts of the IEC 80002 series, published under the general title Medical device
software, can be found on the IEC website.
The committee has decided that the contents of this publication 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.
A bilingual version of this publication may be issued at a later date.

---------------------- Page: 6 ----------------------
IEC TR 80002-3:2014 © IEC 2014 – 5 –
INTRODUCTION
0.1 Background
Software is often an integral part of medical device technology. Establishing the safety and
effectiveness of a medical device containing software requires well designed software that
fulfils its purpose without causing any unacceptable risks. Following an internationally
approved set of software development practices provides one way of achieving this.
This technical report (TR) provides a framework of life cycle processes supporting the safe
design and maintenance of medical device software called the process reference model
(PRM). The process descriptions in this PRM are fully compliant with the requirements of
ISO/IEC 24774:2010, Systems and software engineering – Life cycle management –
Guidelines for process description.
This TR presents the PRM for medical device software development as a result of integrating
requirements from IEC 62304:2006 and from the international standard of software life-cycle
processes ISO/IEC 12207:2008.
This TR is aimed at medical device software developers who can use it for realizing the set of
requirements they have to achieve to be compliant with IEC 62304:2006 in the scope of the
safety class of the medical device software they are developing. Each process outcome with a
corresponding safety class is a requirement in IEC 62304:2006. The process outcomes
without a corresponding safety class are based only on ISO/IEC 12207:2008. These process
outcomes provide additions that are beneficial when achieving the purpose of the process and
could be regarded as a valuable contribution to safety-critical software development. The
PRM may also be used to provide a common basis for different models and methods for
process assessment, ensuring that the results of the assessments can be reported in a
common context. Assessors who are concerned with examining medical device software
processes can use the PRM as an agreed list of IEC 62304 process outcomes to inform audit
check listing and reporting.
The process descriptions in the PRM incorporate a statement of the purpose of the process
which describes at a high level the overall objectives of performing the process, together with
the set of outcomes which demonstrate the successful achievement of the process purpose.
These process outcomes are the software life cycle process requirements – the statements of
the overall goal of performing the process. In any process description, the set of process
outcomes are necessary and sufficient to achieve the purpose of the process.
A manufacturer of a medical device software system is required to assign 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 contributes, described in greater detail
in IEC 62304:2006. The software safety classes are 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.
0.2 Organization of this technical report
This TR is organized to follow the structure of IEC 62304. Annex A describes the development
of the TR in greater detail. Annex B provides a mapping from IEC 62304 clauses together with
their safety classes to the corresponding ISO/IEC 12207:2008 processes. The life cycle
processes of the PRM for medical device software development are described in terms of
process name, process purpose and the corresponding process outcomes. The outcomes
marked with an “[ISO/IEC 12207]” at the end of the outcome statement are derived from
ISO/IEC 12207:2008, with no directly corresponding requirement in IEC 62304. Users of this
PRM who wish to examine only the IEC 62304 requirements can elect to disregard the
outcomes that are based only on ISO/IEC 12207:2008.

---------------------- Page: 7 ----------------------
– 6 – IEC TR 80002-3:2014 © IEC 2014
MEDICAL DEVICE SOFTWARE –

Part 3: Process reference model of medical
device software life cycle processes (IEC 62304)



1 Scope
This part of IEC 80002, which is a technical report (TR), provides the description of software
life cycle processes for medical devices. The medical device software life cycle processes are
derived from IEC 62304:2006, with corresponding safety classes. They have been aligned
with the software development life cycle processes of ISO/IEC 12207:2008 and are presented
herein in full compliance with ISO/IEC 24774:2010. The content of these three standards
provides the foundation of this TR.
This TR does not address:
– areas already covered by existing related standards, e.g. the international standards that
relate to the four standards used to build this TR (see Bibliography);
– FDA guidance documents; or
– software development tools.
This TR describes the PRM for medical device software development and is limited in scope
to the life cycle processes described in IEC 62304:2006. The process names correspond to
those of IEC 62304:2006. The mappings provided in Annex B are essential for the alignment
between IEC 62304:2006 (which is based on ISO/IEC 12207:1995) and ISO/IEC 12207:2008,
developed to address the detailed normative relationship between the two standards.
This technical report is not intended to be used as the basis of regulatory inspection or
certification assessment activities.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
IEC 62304:2006, Medical device software – Software life cycle processes
ISO/IEC 12207:2008, Systems and software engineering – Software life cycle processes
3 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62304:2006 apply.
NOTE To be consistent with the requirements for developing a PRM, the guidelines set forth in ISO/IEC 24774
were followed. Having a dedicated software risk management process enables the software developers to realize
the set of requirements they have to adhere to when developing software for medical devices. This PRM also
enables the medical device software developers to determine the requirements necessary to develop software for a
specific safety class. The PRM presented in this TR includes only the software risk management requirements of
ISO 14971 that are a part of IEC 62304. The software risk management terminology is therefore derived directly
from ISO 14971. For the purposes of this TR, the software development-related terms and definitions used are
inherited from IEC 62304.

---------------------- Page: 8 ----------------------
IEC TR 80002-3:2014 © IEC 2014 – 7 –
4 Medical device software life cycle processes
4.1 Software development process
4.1.1 Software development planning
4.1.1.1 Purpose
The purpose of software development planning (IEC 62304, 5.1) is to establish a plan for
conducting the activities of the software development processes.
4.1.1.2 Outcomes
The successful implementation of software development planning shall ensure that:
a) a software development plan is established for the software development appropriate to
the scope, magnitude, and software safety classification of the software system.
[Classes A, B, C];
NOTE 1 The software development plan includes the description of the development processes, the
deliverables from the processes (including documentation), software configuration and change management
(including SOUP configuration items and software used to support development), and software problem
resolution.
b) the software development plan addresses how traceability between system requirements,
software requirements, software system test and risk control measures is established
[Classes A, B, C];
c) the software development plan is maintained throughout the software life cycle
[Classes A, B, C];
d) the software development plan references system design and development
[Classes A, B, C];
e) the software development plan includes or references the standards, methods and tools
associated with the development of software items for Class C [Class C];
f) the software development plan includes or references an integration strategy for software
units, including SOUP [Classes B, C];
g) the software development plan includes or references a verification strategy
[Classes A, B, C];
NOTE 2 Verification strategy includes ensuring that all activities and tasks are complete along with all the
associated documentation.
h) the software development plan includes or references a risk management plan, including
the plan to manage risks relating to SOUP [Classes A, B, C];
i) the software development plan includes or references a strategy identifying the
documentation to be produced during the software development life cycle, and the
standards to be applied for the development of the software documentation
[Classes A, B, C];
j) the software development plan includes or references a configuration management plan
[Classes A, B, C];
NOTE 3 The software configuration management plan includes or references:
i) the classes, types, categories or lists of items to be controlled;
ii) the software configuration management activities and tasks;
iii) the organization(s) responsible for performing software configuration management and activities;
iv) their relationship with other organizations, such as software development or maintenance;
v) when the items are to be placed under configuration control;
vi) when the problem resolution process is to be used;
vii) software configuration items that include other software products or entities such as SOUP.

---------------------- Page: 9 ----------------------
– 8 – IEC TR 80002-3:2014 © IEC 2014
k) the software development plan includes or references the supporting items or settings
used to develop medical device software requiring control [Classes B, C];
l) The software development plan includes the plan to place configuration items under
documented configuration management control before they are verified [Classes B, C].
4.1.2 Software requirements analysis
4.1.2.1 Purpose
The purpose of software requirements analysis (IEC 62304, 5.2) is to establish the
requirements of the software elements of the system.
4.1.2.2 Outcomes
A successful implementation of software requirements analysis shall ensure that:
a) the requirements allocated to the software system and their interfaces are defined
[Classes A, B, C];
b) software requirements are analyzed for correctness and testability [Classes A, B, C];
c) the impact of software requirements on the operating environment are understood
[Classes A, B, C];
d) consistency and traceability are established between the software requirements and
system requirements [Classes A, B, C];
e) prioritization for implementing the software requirements is defined [ISO/IEC 12207];
f) the existing requirements, including system requirements, are updated as appropriate as a
result of software requirements analysis [Classes A, B, C];
g) changes to the software requirements are evaluated for cost, schedule and technical
impact [ISO/IEC 12207];
h) the software requirements are baselined and communicated to all affected parties
[ISO/IEC 12207];
i) risk control measures implemented in software for hardware failures and potential
software defects are included in the software requirements [Classes B, C];
NOTE 1 Software architecture implements the defined risk management requirements.
NOTE 2 Software safety class is assigned to software items based on the possible effects of the hazard.
j) medical device risk analysis is re-evaluated and updated as appropriate when software
requirements are established [Classes A, B, C].
4.1.3 Software architectural design
4.1.3.1 Purpose
The purpose of software architectural design (IEC 62304, 5.3) is to provide a design for the
software that implements and can be verified against the requirements.
4.1.3.2 Outcomes
A successful implementation of software architectural design shall ensure that:
a) a software architectural design is developed and baselined that describes the software
items, including SOUP, that will implement the software requirements [Classes B, C];
b) in the case of SOUP items, all functional and performance requirements shall be
specified, including hardware and software requirements of the system [Classes B, C];
NOTE 1 Examples include processor type and speed, memory type and size, system software type,
communication and display software requirements.
c) internal and external interfaces of each software item are defined [Classes B, C];

---------------------- Page: 10 ----------------------
IEC TR 80002-3:2014 © IEC 2014 – 9 –
d) consistency and traceability are established between software requirements and software
design [ISO/IEC 12207];
e) the effectiveness of the segregation between the software items that is essential to risk
control is identified and ensured [Class C];
NOTE 2 An example of segregation is to have software items execute on different processors. The
effectiveness of the segregation can be ensured by having no shared resources between the processors.
f) software architecture implements system and software requirements, including those
relating to risk control [Classes B, C].
4.1.4 Software detailed design
4.1.4.1 Purpose
The purpose of software detailed design (IEC 62304, 5.4) is to provide a design for the
software detailed enough to permit coding and testing.
4.1.4.2 Outcomes
A successful implementation of software detailed design shall ensure that:
a) the software architecture is refined into software units [Classes B, C];
b) a detailed design of each software unit of the software item is developed [Class C];
c) external interfaces of each software unit are defined [Class C];
d) consistency and traceability are established between the detailed design and the
requirements and architectural design [ISO/IEC 12207];
e) a detailed design is verified and documented to ensure that it implements and does not
contradict the software architecture [Class C].
4.1.5 Software unit implementation and verification
4.1.5.1 Purpose
The purpose of software unit implementation and verification (IEC 62304, 5.5) is to produce
executable software units that properly reflect the software design.
4.1.5.2 Outcomes
A successful implementation of software unit implementation and verification shall ensure
that:
a) software units defined by the design are produced [Classes A, B, C];
NOTE 1 For Class A medical device software developers, it is not necessary to base software units on a
software design.
b) verification criteria are defined for all software units against their requirements
[Classes B, C];
NOTE 2 Where verification is done by testing, the test procedures are evaluated for correctness.
c) consistency and traceability are established between software units and requirements and
design [ISO/IEC 12207];
d) software unit acceptance criteria prior to their integration into larger software items are
established and it is ensured that software units mee the acceptance criteria
[Classes B, C];
e) additional software unit acceptance criteria for Class C medical device software are
established and it is ensured that Class C medical device software units mee the criteria
[Class C];

---------------------- Page: 11 ----------------------
– 10 – IEC TR 80002-3:2014 © IEC 2014
f) verification of the software units against the requirements and the design is accomplished
and documented [Classes B, C].
4.1.6 Software integration and integration testing
4.1.6.1 Purpose
The purpose of software integration and integration
...