Medical device software

IEC TR 80002-3:2014 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 process reference model 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.

Logiciels de dispositifs médicaux

General Information

Status
Published
Publication Date
04-Jun-2014
Current Stage
6000 - International Standard under publication
Start Date
05-Jun-2014
Ref Project

Buy Standard

Technical report
IEC/TR 80002-3:2014 - Medical device software
English language
23 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

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

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.