Medical device software - Software life-cycle processes

PWI created for possible future // procedures

Medizingeräte-Software - Software-Lebenszyklus-Prozesse

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

Programska oprema za medicinske aparate - Procesi v življenjskem ciklu programske opreme - Dopolnilo A1

General Information

Status
Published
Publication Date
09-Nov-2015
Current Stage
6060 - National Implementation/Publication (Adopted Project)
Start Date
05-Nov-2015
Due Date
10-Jan-2016
Completion Date
10-Nov-2015

RELATIONS

Buy Standard

Amendment
SIST EN 62304:2006/A1:2015
English language
45 pages
sale 10% off
Preview
sale 10% off
Preview

e-Library read for
1 day

Standards Content (sample)

SLOVENSKI STANDARD
SIST EN 62304:2006/A1:2015
01-december-2015
Programska oprema za medicinske aparate - Procesi v življenjskem ciklu
programske opreme - Dopolnilo A1
Medical device software - Software life-cycle processes
Medizingeräte-Software - Software-Lebenszyklus-Prozesse
Logiciels de dispositifs médicaux - Processus du cycle de vie du logiciel
Ta slovenski standard je istoveten z: EN 62304:2006/A1:2015
ICS:
13.020.60 Življenjski ciklusi izdelkov Product life-cycles
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
SIST EN 62304:2006/A1:2015 en

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------
SIST EN 62304:2006/A1:2015
---------------------- Page: 2 ----------------------
SIST EN 62304:2006/A1:2015
EUROPEAN STANDARD EN 62304:2006/A1
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2015
ICS 11.040
English Version
Medical device software - Software life-cycle processes
(IEC 62304:2006/A1:2015)

Logiciels de dispositifs médicaux - Processus du cycle de Medizingeräte-Software - Software-Lebenszyklus-Prozesse

vie du logiciel (IEC 62304:2006/A1:2015)
(IEC 62304:2006/A1:2015)

This amendment A1 modifies the European Standard EN 62304:2006; it was approved by CENELEC on 2015-07-31. CENELEC members

are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this amendment 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 CEN-CENELEC

Management Centre or to any CENELEC member.

This amendment 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 CEN-CENELEC Management Centre has the same status as

the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,

Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,

Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,

Turkey and the United Kingdom.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2015 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.

Ref. No. EN 62304:2006/A1:2015 E
---------------------- Page: 3 ----------------------
SIST EN 62304:2006/A1:2015
EN 62304:2006/A1:2015
European Foreword

The text of document 62A/1007/FDIS, future IEC 62304:2006/A1, prepared by SC 62A "Common

aspects of electrical equipment used in medical practice" of IEC/TC 62 "Electrical equipment in

medical practice" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as

EN 62304:2006/A1:2015.
The following dates are fixed:
• latest date by which the document has to be (dop) 2016-05-01
implemented at national level by
publication of an identical national
standard or by endorsement
(dow) 2018-07-31
• latest date by which the national
standards conflicting with the
document have to be withdrawn

Attention is drawn to the possibility that some of the elements of this document may be the subject of

patent rights. CENELEC [and/or CEN] shall not be held responsible for identifying any or all such

patent rights.

This document has been prepared under a mandate given to CENELEC by the European Commission

and the European Free Trade Association, and supports essential requirements of EU Directive.

For the relationship with EU Directive 93/42/EEC, 98/79/EC, 90/385/EEC see informative Annex ZZ,

included in EN 62304:2006/corrigendum Nov. 2008.
Endorsement notice

The text of the International Standard IEC 62304:2006/A1:2015 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:
Replace the existing references with the following:
IEC 60601-1:2005 NOTE Harmonized as EN 60601-1:2006.
IEC 60601-1:2005/AMD1:2012 NOTE Harmonized as EN 60601-1:2006/A1:2013.
IEC 60601-1-4:1996 NOTE Harmonized as EN 60601-1-4:1996.
IEC 60601-1-4:1996/AMD1:1999 NOTE Harmonized as EN 60601-1-4:1996/A1:1999.
IEC 60601-1-6 NOTE Harmonized as EN 60601-1-6.
IEC 61508-3 NOTE Harmonized as EN 61508-3.
IEC 61010-1:2010 NOTE Harmonized as EN 61010-1:2010.
ISO 9000:2005 NOTE Harmonized as EN ISO 9000:2005.
ISO 9001:2008 NOTE Harmonized as EN ISO 9001:2008.
ISO 13485:2003 NOTE Harmonized as EN ISO 13485:2003.
---------------------- Page: 4 ----------------------
SIST EN 62304:2006/A1:2015
EN 62304:2006/A1:2015
IEC 62366-1:2015 NOTE Harmonized as EN 62366-1:2015.
NOTE Harmonized as EN 82304-1
IEC 82304-1
1) At draft stage.
---------------------- Page: 5 ----------------------
SIST EN 62304:2006/A1:2015
---------------------- Page: 6 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304
Edition 1.0 2015-06
INTERNATIONAL
STANDARD
AMENDMENT 1
Medical device software – Software life cycle processes
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 11.040 ISBN 978-2-8322-2720-6

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

---------------------- Page: 7 ----------------------
SIST EN 62304:2006/A1:2015
– 2 – IEC 62304:2006/AMD1:2015
© IEC 2015
FOREWORD

This amendment 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.
This publication is published as a double logo standard.
The text of this amendment is based on the following documents:
FDIS Report on voting
62A/1007/FDIS 62A/1014/RVD

Full information on the voting for the approval of this amendment can be found in the report

on voting indicated in the above table. In ISO, the standard has been approved by 30 P-

members out of 30 having cast a vote.

The committee has decided that the contents of this amendment and the base publication will

remain unchanged until the stability date indicated on the IEC website 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.
_____________
INTRODUCTION TO THE AMENDMENT

The first edition of IEC 62304 was published in 2006. This amendment is intended to add

requirements to deal with LEGACY SOFTWARE, where the software design is prior to the

existence of the current version, to assist manufacturers who must show compliance to the

standard to meet European Directives. Software safety classification changes needed for this

amendment include clarification of requirements and updating of the software safety

classification to include a risk-based approach. Work is continuing in parallel to develop the

second edition of IEC 62304.
FOREWORD
Add the following note at the end of the Foreword:

NOTE The attention of National Committees is drawn to the fact that equipment MANUFACTURERS and testing

organizations may need a transitional period following publication of a new, amended or revised IEC or

ISO publication in which to make products in accordance with the new requirements and to equip themselves for

conducting new or revised tests. It is the recommendation of the committee that the content of this publication be

adopted for mandatory implementation nationally not earlier than 3 years from the date of publication.

---------------------- Page: 8 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304:2006/AMD1:2015 – 3 –
© IEC 2015
INTRODUCTION

Replace, in the second paragraph, the existing third sentence with the following:

Each life cycle PROCESS consists of a set of ACTIVITIES, with most ACTIVITIES consisting of a

set of TASKS.

Replace, in the first sentence of the fourth paragraph, the phrase "contributing factor to a

HAZARD" with " contributing factor to a HAZARDOUS SITUATION".

Replace, in the second sentence of the fourth paragraph, the term, "HAZARDS" with

"HAZARDOUS SITUATIONS".
Add, after the existing sixth paragraph, the following new paragraph:

Amendment 1 updates the standard to add requirements to deal with LEGACY SOFTWARE, where

the software design is prior to the existence of the current version, to assist manufacturers

who must show compliance to the standard to meet European Directives. Software safety

classification changes include clarification of requirements and updating of the software

safety classification to include a risk-based approach.
1 Scope
1.2 * Field of application
Replace the entire existing text of this subclause with the following:

This standard applies to the development and maintenance of MEDICAL DEVICE SOFTWARE

when software is itself a MEDICAL DEVICE or when software is an embedded or integral part of

the final MEDICAL DEVICE.

NOTE 1 This standard can be used in the development and maintenance of software that is itself a medical

device. However, additional development activities are needed at the system level before this type of software can

be placed into service. These system activities are not covered by this standard, but can be found in IEC 82304-

1 [22].

This standard describes PROCESSES that are intended to be applied to software which

executes on a processor or which is executed by other software (for example an interpreter)

which executes on a processor.

This standard applies regardless of the persistent storage device(s) used to store the

software (for example: hard disk, optical disk, permanent or flash memory).

This standard applies regardless of the method of delivery of the software (for example:

transmission by network or email, optical disk, flash memory or EEPROM). The method of

software delivery itself is not considered MEDICAL DEVICE SOFTWARE.

This standard does not cover validation and final release of the MEDICAL DEVICE, even when

the MEDICAL DEVICE consists entirely of software.

NOTE 2 If a medical device incorporates embedded software intended to be executed on a processor, the

requirements of this standard apply to the software, including the requirements concerning software of unknown

provenance (see 8.1.2).
___________
In preparation.
---------------------- Page: 9 ----------------------
SIST EN 62304:2006/A1:2015
– 4 – IEC 62304:2006/AMD1:2015
© IEC 2015

NOTE 3 Validation and other development activities are needed at the system level before the software and

medical device can be placed into service. These system activities are not covered by this standard, but can be

found in related product standards (e.g., IEC 60601-1, IEC 82304-1, etc.).
1.4 Compliance
Delete, in the second paragraph, the instruction “See Annex D.”
Add, after existing Note 4, the following new note:
NOTE 5 For compliance of LEGACY SOFTWARE see 4.4.
3 * Terms and definitions
3.2
ANOMALY
Replace, in the definition, "SOFTWARE PRODUCTS" with "MEDICAL DEVICE SOFTWARE".
Replace the existing source reference with the following note:
NOTE Based on IEEE 1044:1993, definition 3.1.
3.4
CHANGE REQUEST
Replace "SOFTWARE PRODUCT" with "MEDICAL DEVICE SOFTWARE".
3.5
CONFIGURATION ITEM

Replace, in the note, "ISO/IEC 12207:1995, definition 3.6" with "ISO/IEC 12207:2008, 4.7".

3.7
EVALUATION
Replace the existing source reference with "[ISO/IEC 12207:2008, 4.12]".
3.8
HARM
Replace the existing source reference with "[ISO 14971:2007, 2.2]".
3.9
HAZARD
Replace the existing source reference with "[ISO 14971:2007, 2.3]".
3.10
MANUFACTURER
Add the following new notes:

NOTE 1 Attention is drawn to the fact that the provisions of national or regional regulations can apply to the

definition of manufacturer.
NOTE 2 For a definition of labelling, see ISO 13485:2003, definition 3.6.
Replace the existing source reference with "[ISO 14971:2007, 2.8]".
---------------------- Page: 10 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304:2006/AMD1:2015 – 5 –
© IEC 2015
3.11
MEDICAL DEVICE
Add the following new note:

NOTE 3 In conjunction with IEC 60601-1:2005 and IEC 60601-1:2005/AMD1:2012 the term “medical device”

assumes the same meaning as ME EQUIPMENT or ME SYSTEM (which are defined terms of IEC 60601-1).

3.12
MEDICAL DEVICE SOFTWARE
Replace the existing definition with the following:

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

NOTE This includes a MEDICAL DEVICE software product, which then is a MEDICAL DEVICE in its own right.

3.13
PROBLEM REPORT

Replace, in the definition and in Notes 1 and 2, "SOFTWARE PRODUCT" with "MEDICAL DEVICE

SOFTWARE" (4 times).
3.16
RISK
Replace the existing source reference with "[ISO 14971:2007, 2.16]".
3.17
RISK ANALYSIS
Replace the existing source reference with "[ISO 14971:2007, 2.17]".
3.18
RISK CONTROL
Replace the existing source reference with "[ISO 14971:2007, 2.19]".
3.19
RISK MANAGEMENT

Replace the existing source reference with "[ISO 14971:2007, 2.22, modified – The phrase

"and monitoring" has been removed]".
3.20
RISK MANAGEMENT FILE
Replace the existing source reference with "[ISO 14971:2007, 2.23]".
3.21
SAFETY
Replace the existing source reference with "[ISO 14971:2007, 2.24]".
3.22
SECURITY
Replace the existing definition with the following:

protection of information and data so that unauthorized persons or systems cannot read or

modify them an authorized persons or systems are not denied access to them.
NOTE Based on ISO/IEC 12207:2008, 4.39.
---------------------- Page: 11 ----------------------
SIST EN 62304:2006/A1:2015
– 6 – IEC 62304:2006/AMD1:2015
© IEC 2015
3.23
SERIOUS INJURY
Delete, in the first line of the definition, the words "directly or indirectly".
3.24
SOFTWARE DEVELOPMENT LIFE CYCLE MODEL
Delete, in the second line of the definition, the phrase "for manufacturing".

Replace, in the first dashed item, the words "a SOFTWARE PRODUCT" with "MEDICAL DEVICE

SOFTWARE".
3.25
SOFTWARE ITEM
Replace the existing definition with the following:

any identifiable part of a computer program, i.e., source code, object code, control code,

control data, or a collection of these items

NOTE 1 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 granularity of the SOFTWARE ITEMS and SOFTWARE UNITS.

NOTE 2 Based on ISO/IEC 90003:2004, 3.14 and ISO/IEC 12207:2008, 4.41.
3.26
SOFTWARE PRODUCT
Delete the existing term and definition and add “Not used”.
3.28
SOFTWARE UNIT
Replace the existing note by the following:
NOTE The granularity of SOFTWARE UNITS is defined by the MANUFACTURER (see B.3).
3.29
SOUP
software of unknown provenance (acronym)

Replace, in the third line of the definition, “software previously developed” with ‘SOFTWARE

ITEM previously developed”
Add the following new note:
NOTE A MEDICAL DEVICE SOFTWARE SYSTEM in itself cannot be claimed to be SOUP.
3.30
SYSTEM
Replace the existing source reference with the following note:
NOTE Based on ISO/IEC 12207:2008, 4.48.
3.32
TRACEABILITY
Add the following new note:
---------------------- Page: 12 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304:2006/AMD1:2015 – 7 –
© IEC 2015

NOTE Requirements, architecture, risk control measures, etc. are examples of deliverables of the development

PROCESS.
3.34
VERSION

Replace, in the existing text of Note1, the words "a SOFTWARE PRODUCT" with "MEDICAL DEVICE

SOFTWARE".
Replace the existing text of Note 2 with the following
NOTE 2 Based on ISO/IEC 12207:2008, 4.56.
Add the following new definitions:
3.35
HAZARDOUS SITUATION

circumstance in which people, property or the environment are exposed to one or more

HAZARD(S)
[SOURCE: ISO 14971:2007, 2.4]
3.36
LEGACY SOFTWARE

MEDICAL DEVICE SOFTWARE which was legally placed on the market and is still marketed today

but for which there is insufficient objective evidence that it was developed in compliance with

the current version of this standard
3.37
RELEASE

particular VERSION of a CONFIGURATION ITEM that is made available for a specific purpose

NOTE Based on ISO/IEC 12207:2008, definition 4.35.
3.38
RESIDUAL RISK
RISK remaining after RISK CONTROL measures have been taken
NOTE 1 Adapted from ISO/IEC Guide 51:1999, definition 3.9.

NOTE 2 ISO/IEC Guide 51:1999, definition 3.9 uses the term “protective measures” rather than “RISK CONTROL

measures.” However, in the context of this International Standard, “protective measures” are only one option for

controlling RISK as described in 6.2 [of ISO 14971:2007].
[SOURCE: ISO 14971:2007, 2.15].
3.39
RISK ESTIMATION

PROCESS used to assign values to the probability of occurrence of HARM and the severity of

that HARM
[SOURCE: ISO 14971:2007 2.20]
3.40
RISK EVALUATION

PROCESS of comparing the estimated RISK against given RISK criteria to determine the

acceptability of the RISK
[SOURCE: ISO 14971:2007 2.21]
---------------------- Page: 13 ----------------------
SIST EN 62304:2006/A1:2015
– 8 – IEC 62304:2006/AMD1:2015
© IEC 2015
4.3 * Software safety classification
Replace existing items a) and b), and insert a new Figure 3, as follows:

a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B,

or C) according to the RISK of HARM to the patient, operator, or other people resulting from

a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case-

scenario as indicated in Figure 3.
IEC
Figure 3 – Assigning software safety classification
The SOFTWARE SYSTEM is software safety class A if:
– the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or

– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in

unacceptable RISK after consideration of RISK CONTROL measures external to the
SOFTWARE SYSTEM.
The SOFTWARE SYSTEM is software safety class B if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in
unacceptable RISK after consideration of RISK CONTROL measures external to the
SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.
The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in
unacceptable RISK after consideration of RISK CONTROL measures external to the
SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.

For a SOFTWARE SYSTEM initially classified as software safety class B or C, the MANUFACTURER

may implement additional RISK CONTROL measures external to the SOFTWARE SYSTEM
(including revising the system architecture containing the SOFTWARE SYSTEM) and
subsequently assign a new software safety classification to the SOFTWARE SYSTEM.
---------------------- Page: 14 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304:2006/AMD1:2015 – 9 –
© IEC 2015

NOTE 1 External RISK CONTROL measures can be hardware, an independent SOFTWARE SYSTEM, health care

procedures, or other means to minimize that software can contribute to a HAZARDOUS SITUATION.

NOTE 2 See ISO 14971:2007 subclause 3.2, Management Responsibilities, for the definition of risk acceptability.

b) Not used.

Add, at the end of the first sentence in item d), the following parenthetical phrase: "(software

safety classes assigned according to 4.3 a) replacing “SOFTWARE SYSTEM” with “SOFTWARE

ITEM”)".
Replace the existing text of item f) with the following:

f) For compliance with this standard, when applying this standard 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.
Replace the existing text of the note with the following:

NOTE In the clauses and subclauses that follow, the software safety classes for which a specific requirement

applies are identified following the requirement in the form of [Class . . .].
Add the following new subclause:
4.4 * LEGACY SOFTWARE
4.4.1 General

As an alternative to applying Clauses 5 through 9 of this standard, compliance of LEGACY

SOFTWARE may be demonstrated as indicated in 4.4.2 to 4.4.5.
4.4.2 RISK MANAGEMENT ACTIVITIES
In accordance with 4.2 of this standard, the MANUFACTURER shall:

a) assess any feedback, including post-production information, on LEGACY SOFTWARE

regarding incidents and / or near incidents, both from inside its own organization and / or

from users;

b) perform RISK MANAGEMENT ACTIVITIES associated with continued use of the LEGACY

SOFTWARE, considering the following aspects:
– integration of the LEGACY SOFTWARE in the overall MEDICAL DEVICE architecture;

– continuing validity of RISK CONTROL measures, implemented as part of the LEGACY

SOFTWARE;

– identification of HAZARDOUS SITUATIONS associated with the continued use of the

LEGACY SOFTWARE;

– identification of potential causes of the LEGACY SOFTWARE contributing to a HAZARDOUS

SITUATION;

– definition of RISK CONTROL measures for each potential cause of the LEGACY SOFTWARE

contributing to a HAZARDOUS SITUATION.
4.4.3 Gap analysis

Based on the software safety class of the LEGACY SOFTWARE (see 4.3), the MANUFACTURER

shall perform a gap analysis of available DELIVERABLES against those required according to

5.2, 5.3, 5.7, and Clause 7.

a) The MANUFACTURER shall assess the continuing validity of available DELIVERABLES.

---------------------- Page: 15 ----------------------
SIST EN 62304:2006/A1:2015
– 10 – IEC 62304:2006/AMD1:2015
© IEC 2015

b) Where gaps are identified, the MANUFACTURER shall EVALUATE the potential reduction in

RISK resulting from the generation of the missing DELIVERABLES and associated ACTIVITIES.

c) Based on this evaluation, the MANUFACTURER shall determine the DELIVERABLES to be

created and associated ACTIVITIES to be performed. The minimum DELIVERABLE shall be

SOFTWARE SYSTEM test records (see 5.7.5).

NOTE Such gap analysis should assure that RISK CONTROL measures, implemented in LEGACY SOFTWARE, are

included in the software requirements.
4.4.4 Gap closure activities

a) The MANUFACTURER shall establish and execute a plan to generate the identified

DELIVERABLES. Where available, objective evidence may be used to generate required

DELIVERABLES without performing ACTIVITIES required by 5.2, 5.3, 5.7 and Clause 7.

NOTE A plan on how to address the identified gaps can be included in a software maintenance plan (see

6.1).

b) The plan shall address the use of the problem resolution PROCESS for handling problems

detected in the LEGACY SOFTWARE and DELIVERABLES in accordance with Clause 9.

c) Changes to the LEGACY SOFTWARE shall be performed in accordance with Clause 6.

4.4.5 Rationale for use of LEGACY SOFTWARE

The MANUFACTURER shall document the VERSION of the LEGACY SOFTWARE together with a

rationale for the continued use of the LEGACY SOFTWARE based on the outputs of 4.4.

NOTE Fulfilling 4.4 enables further use of LEGACY SOFTWARE in accordance with IEC 62304.

5 Software development PROCESS
5.1 * Software development planning
5.1.1 Software development plan
Replace, in list item e), “SOFTWARE PRODUCTS” with “MEDICAL DEVICE SOFTWARE”.
5.1.3 Software development plan reference to SYSTEM design and development
Replace the existing text of list item b) with the following:
b) In the software development plan, the MANUFACTURER shall include or reference
procedures for coordinating the software development with the system development

necessary to satisfy 4.1 (such as system integration, verification, and validation).

5.1.5 Software integration and integration testing planning
Add the following new note and renumber the first note as Note 1:
NOTE 2 See 5.6.
5.1.8 Documentation planning
Delete list item c).
Add the following new note:

NOTE See Clause 8 for consideration of configuration management of documentation.

5.1.9 Software configuration management planning

Replace, in list item c), “software configuration management and ACTIVITIES” with “software

configuration management ACTIVITIES”.
---------------------- Page: 16 ----------------------
SIST EN 62304:2006/A1:2015
IEC 62304:2006/AMD1:2015 – 11 –
© IEC 2015
Add the following new note:
NOTE See Clause 8.
5.1.10 Supporting items to be controlled
Add the following new note and renumber the first note as NOTE 1:
NOTE 2 See Clause 8.
5.1.11 Software CONFIGURATION ITEM control before VERIFICATION
Replace “under documented configuration management” with “under configuration
management”.
Add the following new subclause:
5.1.12 Identification and avoidance of common software defects

The MANUFACTURER shall include or reference in the software development plan a procedure

for:

a) identifying categories of defects that may be introduced based on the selected

programming technology that are relevant to their SOFTWARE SYSTEM; and

b) documenting evidence that demonstrates that these defects do not contribute to

unacceptable RISK.

NOTE See Annex B of IEC TR 80002-1:2009 for examples of categories of defects or causes contributing to

HAZARDOUS SITUATIONS.
[Class B, C]
5.2 * Software requirements analysis
5.2.2 Software requirements content
Add to the bulleted list of examples in Note 3 the following additional item;
– system security/malware protection.
Replace the existing text of list item f) with the following:
f) user interface requirements implemented by software;

Replace, in Note 5 “IEC 60601-1-6.” with “IEC 62366-1 [21] among others (e.g., IEC 60601-1-

6 [3]).”
Replace the existing text of list item j) with the following new text and note:
j) requirements related to IT-network aspects;
NOTE 9 Examples include those related to:
– networked alarms, warnings, and operator messages;
– network protocols;
– handling of unavailability of network services.
Add the following new note after list item l):
NOTE 10 The requirements in a) through l) can overlap.

Replace, in existing Note 8, “ISO/IEC 9126-1 [8]” with “Among others, ISO/IEC 25010 [12]“

---------------------- Page: 17 ----------------------
SIST EN 62304:2006/A1:2015
– 12 – IEC 62304:2006/AMD1:2015
© IEC 2015
5.2.3 Include RISK CONTROL measures in software requirements
Delete the phrase “for hardware failures and potential software defects".
5.2.5 Update system requirements
Replace the existing title of the subclause with the following:
5.2.5 Update requirements
5.2.6 Verify software requirements

Delete, in the existing text of list item d) the phrase "to determine whether the test criteria

have been met".
5.3 Software ARCHITECTURAL design
5.3.5 Identify segregation necessary for RISK CONTROL
Replace the existing text of the subclause with the following:

The MANUFACTURER shall identify any segregation between SOFTWARE ITEMS that is necessary

for RISK CONTROL, and state how to ensure that such segregation is effective. [Class C]

NOTE 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. Other means of

segregation can be applied when effectiveness can be ensured by the software ARCHITECTURE design (see B.4.3).

5.3.6 Verify software ARCHITECTURE
Add the following new note:

NOTE A TRACEABILITY analysis of ARCHITECTURE to software requirements can be used to satisfy requirement a).

5.4 * Software detailed design
5.4.1 Refine SOFTWARE ARCHITECTURE into sOFTWARE UNITS
Replace the existing title and text of this subclause with the following:
5.4.1 Subdivide software into SOFTWARE UNITS

The MANUFACTURER shall subdvide the software until it is represented by SOFTWARE UNITS.

[Class B, C]
NOTE Some SOFTWARE SYSTEMS are not divided further.
5.4.2 Develop detailed design for each SOFTWARE UNIT
Replace the existing text with the following:
The MANUFACTURER shall document a design with enough detail to allow correct
implementation of each SOFTWARE UNIT. [Class C]
5.4.3 Develop detailed design for interfaces
Replace the existing text with the following:

The MANUFACTURER shall document a design for any interfaces between the SOFTWARE UNIT

and external components (hardware or software), as well as any interfaces between

-----------------
...

Questions, Comments and Discussion

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