SIST EN 82304-1:2017

SLOVENSKI STANDARD
01-oktober-2017
Programska oprema v zdravstvu - 1. del: Splošne zahteve za varnost proizvodov
(IEC 82304-1:2016)
Health Software - Part 1: General requirements for product safety (IEC 82304-1:2016)
Ta slovenski standard je istoveten z: EN 82304-1:2017
ICS:
35.240.80 Uporabniške rešitve IT v IT applications in health care
zdravstveni tehniki technology
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 82304-1
NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2017
ICS 35.240.80
English Version
Health Software - Part 1: General requirements for product
safety
(IEC 82304-1:2016)
Logiciels de santé - Partie 1: Exigences générales pour la Gesundheitssoftware - Teil 1: Allgemeine Anforderungen für
sécurité des produits die Produktsicherheit
(IEC 82304-1:2016) (IEC 82304-1:2016)
This European Standard was approved by CENELEC on 2016-12-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 CEN-CENELEC
Management Centre 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 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, Serbia, 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
© 2017 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 82304-1:2017 E
European foreword
The text of document 62A/1140/FDIS, future edition 1 of IEC 82304-1, prepared by IEC/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 82304-1:2017.
The following dates are fixed:
• latest date by which the document has (dop) 2018-03-01
to be implemented at national level by
publication of an identical national
standard or by endorsement
(dow) 2020-09-01
• 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 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.
Endorsement notice
The text of the International Standard IEC 82304-1:2016 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 (series) NOTE Harmonized as EN 60601 (series).
IEC 60601-1:2005 NOTE Harmonized as EN 60601-1:2006.
IEC 61907:2009 NOTE Harmonized as EN 61907:2010.
IEC 62366-1:2015 NOTE Harmonized as EN 62366-1:2015.
IEC 80001-1:2010 NOTE Harmonized as EN 80001-1:2011.
ISO 9000:2015 NOTE Harmonized as EN ISO 9000:2015.
ISO 13485:2015 NOTE Harmonized as EN ISO 13485:2016.
ISO 14971:2007 NOTE Harmonized as EN ISO 14971:2012.
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
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.
NOTE 1 When an International Publication has been modified by common modifications, indicated by (mod), the relevant

EN/HD applies.
NOTE 2 Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year

IEC 62304 2006 Medical device software - Software life- EN 62304 2006
cycle processes
- -  + corrigendum Nov. 2008
+ A1 2015  + A1 2015
IEC 82304-1
Edition 1.0 2016-10
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
colour
inside
Health software –
Part 1: General requirements for product safety

Logiciels de santé –
Partie 1: Exigences générales pour la sécurité des produits

INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
INTERNATIONALE
ICS 35.240.80 ISBN 978-2-8322-3733-5

– 2 – IEC 82304-1:2016 © IEC 2016
CONTENTS
FOREWORD . 3
INTRODUCTION . 5
1 Scope . 6
1.1 Purpose . 6
1.2 Field of application . 6
1.3 Compliance . 6
2 Normative references . 6
3 Terms and definitions . 7
4 * HEALTH SOFTWARE PRODUCT requirements . 10
4.1 General requirements and initial RISK ASSESSMENT . 10
4.2 HEALTH SOFTWARE PRODUCT use requirements . 11
4.3 VERIFICATION of HEALTH SOFTWARE PRODUCT use requirements . 11
4.4 Updating HEALTH SOFTWARE PRODUCT use requirements . 12
4.5 System requirements . 12
4.6 VERIFICATION of system requirements . 12
4.7 Updating HEALTH SOFTWARE PRODUCT system requirements . 12
5 * HEALTH SOFTWARE – Software life cycle processes . 13
6 * HEALTH SOFTWARE PRODUCT VALIDATION . 13
6.1 VALIDATION plan . 13
6.2 Performing VALIDATION . 13
6.3 VALIDATION report . 14
7 HEALTH SOFTWARE PRODUCT identification and ACCOMPANYING DOCUMENTS . 14
7.1 * Identification . 14
7.2 ACCOMPANYING DOCUMENTS . 14
7.2.1 General . 14
7.2.2 Instructions for use . 15
7.2.3 Technical description . 17
8 Post-market activities for the HEALTH SOFTWARE PRODUCT . 18
8.1 General . 18
8.2 SOFTWARE MAINTENANCE . 18
8.3 Re-VALIDATION . 19
8.4 Post-market communication on the HEALTH SOFTWARE PRODUCT . 19
8.5 Decommissioning and disposal of the HEALTH SOFTWARE PRODUCT . 19
Annex A (informative) Rationale . 20
A.1 General . 20
A.2 Requirements for HEALTH SOFTWARE PRODUCTS . 21
A.3 Rationale for particular clauses and subclauses . 22
Bibliography . 26

Figure A.1 – HEALTH SOFTWARE application domains and scope of related standards . 22
Figure A.2 – IEC 82304-1: HEALTH SOFTWARE PRODUCT processes . 23

Table A.1 – Examples of software (SW) in or not in the scope of this document . 21

IEC 82304-1:2016 © IEC 2016 – 3 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
HEALTH SOFTWARE –
Part 1: General requirements for product safety

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.
International Standard IEC 82304-1 has been prepared by 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 215: Health
informatics.
It is published as a double logo standard.
The text of this standard is based on the following documents of IEC:
FDIS Report on voting
62A/1140/FDIS 62A/1151/RVD
Full information on the voting for the approval of this part of this standard can be found in the
report on voting indicated in the above table. In ISO, the standard has been approved by 21 P
members out of 22 having cast a vote.

– 4 – IEC 82304-1:2016 © IEC 2016
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.
Terms defined in Clause 3 of this standard are printed in SMALL CAPITALS.
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;
and
– “establish” means to define, document, and implement.
An asterisk (* ) as the first character of a title or at the beginning of a paragraph or table title
indicates that there is guidance or rationale related to that item in Annex A.
The committee has decided that the contents of this 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.
IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates
that it contains colours which are considered to be useful for the correct
understanding of its contents. Users should therefore print this document using a
colour printer.
NOTE The attention of National Committees is drawn to the fact that 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.

IEC 82304-1:2016 © IEC 2016 – 5 –
INTRODUCTION
HEALTH SOFTWARE PRODUCTS, within the context of this document, are software-only products.
These products are intended to be used with computing equipment not explicitly developed for
running the software. HEALTH SOFTWARE PRODUCTS may require specified platforms.
HEALTH SOFTWARE PRODUCTS are intended by their MANUFACTURER for managing, maintaining
or improving health of individual persons, or the delivery of care. Some HEALTH SOFTWARE can
contribute to a HAZARDOUS SITUATION. Accordingly, Clause 5 requires a RISK MANAGEMENT
process for all HEALTH SOFTWARE. For HEALTH SOFTWARE that can contribute to a HAZARDOUS
SITUATION, RISK CONTROL is needed to prevent HARM or reduce the likelihood of HARM
occurring. Testing of the finished product is not, by itself, adequate to address the SAFETY of
HEALTH SOFTWARE. Therefore, requirements for the processes by which the HEALTH SOFTWARE
is developed are necessary. This document relies heavily on IEC 62304:2006 and
IEC 62304:2006/AMD1:2015 for the software development process which can be applied to
HEALTH SOFTWARE PRODUCTS.
Whether a HEALTH SOFTWARE PRODUCT has to meet regulatory requirements is a matter of
national legislation. This document makes no attempt to determine whether a HEALTH
SOFTWARE PRODUCT is or should be regulated.
This document aims to provide requirements for the SAFETY and SECURITY of HEALTH
SOFTWARE PRODUCTS; it can only provide such requirements for software-only products.
Situations where HEALTH SOFTWARE is a part of—or embedded in— a physical device are
outside the scope of this document as these combined products are considered separately in,
for example, IEC 60601-1 and associated collateral and particular standards.
This document understands health in a meaning similar to the WHO definition: “Health is a
state of complete physical, mental and social well-being and not merely the absence of
disease or infirmity” (WHO, 1946). This definition appears not highly suitable for practical
purposes: ”a state of complete well-being” or the inclusion of social well-being could be
interpreted more widely than seems reasonable. For example dating software, games, or flight
simulator software could be considered within the scope of the standard. That is clearly not
the intent. However, a precise definition – or even delineation – of “health” for practical use in
“HEALTH SOFTWARE” is not available.
HEALTH SOFTWARE refers to software that contributes to the health of individual people as
observed and/or demonstrated using measurable health parameters or clinical expertise. This
is a subset of “health” as defined by the WHO. The requirements of the standard apply to the
software that impacts such health parameters, and/or to software where SECURITY violations
would undermine privacy or confidentiality of health and wellbeing information.
The reader is kindly referred to the Table A.1 for examples of what is in the scope and what is
outside the scope of this document.

– 6 – IEC 82304-1:2016 © IEC 2016
HEALTH SOFTWARE –
Part 1: General requirements for product safety

1 Scope
1.1 Purpose
This Part of 82304 applies to the SAFETY and SECURITY of HEALTH SOFTWARE PRODUCTS
designed to operate on general computing platforms and intended to be placed on the market
without dedicated hardware, and its primary focus is on the requirements for MANUFACTURERS.
1.2 Field of application
This document covers the entire lifecycle including design, development, VALIDATION,
installation, maintenance, and disposal of HEALTH SOFTWARE PRODUCTS.
In each referenced standard, the term “medical device” or “medical device software” is to be
substituted by the term “HEALTH SOFTWARE” or “HEALTH SOFTWARE PRODUCT”, as appropriate.
Where the term “patient” is used, either in this document or in a referenced standard, it refers
to the person for whose health benefit the HEALTH SOFTWARE is used.
IEC 82304-1 does not apply to HEALTH SOFTWARE which is intended to become part of a
specific hardware designed for health use. Specifically, IEC 82304-1 does not apply to:
a) medical electrical equipment or systems covered by the IEC 60601/IEC 80601 series;
b) in vitro diagnostic equipment covered by the IEC 61010 series; or
c) implantable devices covered by the ISO 14708 series.
NOTE This document also applies to HEALTH SOFTWARE PRODUCTS (e.g. medical apps, health apps) intended to be
used in combination with mobile computing platforms.
1.3 Compliance
Compliance with this document is determined by inspection of all documentation required by
this document.
Assessment of compliance is carried out and documented by the MANUFACTURER. Where the
HEALTH SOFTWARE PRODUCT is subject to regulatory requirements, external assessment may
take place.
Where this document normatively references parts or clauses of other standards focused on
SAFETY or SECURITY, the MANUFACTURER may use alternative methods to demonstrate
compliance with the requirements of this document. These alternative methods may be used if
the process results of such alternative methods, including traceability, are demonstrably
equivalent and the RESIDUAL RISK remains acceptable.
NOTE The term “conformance” is used in ISO/IEC 12207 where the term “compliance” is used in this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements of this document. For dated references, only the edition

IEC 82304-1:2016 © IEC 2016 – 7 –
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
IEC 62304:2006/AMD1:2015
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
ACCOMPANYING DOCUMENT
document accompanying HEALTH SOFTWARE containing information for the RESPONSIBLE
ORGANIZATION or USER, particularly regarding SAFETY and/or SECURITY
[SOURCE: IEC 60601-1:2005, 3.4, modified – Replace "ME EQUIPMENT, ME SYSTEM, equipment
and accessory" by "HEALTH SOFTWARE" and replace "OPERATOR" by "USER" and added “and/or
SECURITY”.]
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.
Note 1 to entry: ANOMALIES can be found during, but not limited to, the review, test, analysis, compilation, or use
of HEALTH SOFTWARE or applicable documentation.
[SOURCE: Based on IEEE 1044:1993, 3.1]
3.3
HARM
injury or damage to the health of people, or damage to property or the environment
[SOURCE: ISO/IEC Guide 51:2014, 3.1]
3.4
HAZARD
potential source of HARM
Note 1 to entry: Potential sources of HARM include breach of SECURITY and reduction of effectiveness.
[SOURCE: ISO/IEC Guide 51:2014, 3.2, modified – Note 1 to entry has been added.]
3.5
HAZARDOUS SITUATION
circumstance in which people, property or the environment is/are exposed to one or more
HAZARDS
[SOURCE: ISO/IEC Guide 51:2014, 3.4]

– 8 – IEC 82304-1:2016 © IEC 2016
3.6
* HEALTH SOFTWARE
software intended to be used specifically for managing, maintaining or improving health of
individual persons, or the delivery of care
Note 1 to entry: HEALTH SOFTWARE fully includes what is considered software as a medical device (see rationale
in A.1).
Note 2 to entry: The scope of this document refers to the subset of HEALTH SOFTWARE that is intended to run on
general computing platforms.
3.7
HEALTH SOFTWARE PRODUCT
combination of HEALTH SOFTWARE and ACCOMPANYING DOCUMENTS
3.8
INTENDED USE
INTENDED PURPOSE
use for which a product, process or service is intended according to the specifications,
instructions and information provided by the MANUFACTURER
[SOURCE: ISO 14971:2007, 2.5]
3.9
IT-NETWORK
INFORMATION TECHNOLOGY NETWORK
a system or systems composed of communicating nodes and transmission links to provide
physically linked or wireless transmission between two or more specified communication
nodes
Note 1 to entry: The scope of the IT-NETWORK in this document is defined by the RESPONSIBLE ORGANIZATION
based on where the HEALTH SOFTWARE in the IT-NETWORK is located and the defined use of the IT-NETWORK. It can
contain IT infrastructure, home health, or general computing components or systems not intended by design to be
used in a healthcare setting. See also 7.2.3.2.
[SOURCE: IEC 61907:2009, 3.1.1, modified – The definition has been rephrased and Note 1
to entry has been added.]
3.10
MANUFACTURER
natural or legal person with responsibility for the design, development, packaging, or labelling
of a HEALTH SOFTWARE PRODUCT, or adapting a HEALTH SOFTWARE PRODUCT before it is placed
on the market or put into service, regardless of whether these operations are carried out by
that person or on that person's behalf by a third party
Note 1 to entry: For a definition of labelling, see ISO 13485:2016, 3.8.
Note 2 to entry: Developer” or “developer organization” are commonly used terms instead of MANUFACTURER in the
context of health information technology.
3.11
RESIDUAL RISK
RISK remaining after RISK CONTROL measures have been taken
[SOURCE: ISO 14971:2007, 2.15]
3.12
RESPONSIBLE ORGANIZATION
entity accountable for the use and proper operation of a HEALTH SOFTWARE PRODUCT
Note 1 to entry: An accountable entity is, for example, a hospital, a healthcare provider, or a telehealth
organization.
IEC 82304-1:2016 © IEC 2016 – 9 –
[SOURCE: IEC 60601-1:2005, 3.101, modified – Replaced " maintenance of an ME
EQUIPMENT or an ME SYSTEM" by " proper operation of a HEALTH SOFTWARE PRODUCT".]
3.13
RISK
combination of the probability of occurrence of HARM and the severity of that HARM
Note 1 to entry: The probability of occurrence includes the exposure to a HAZARDOUS SITUATION and the possibility
to avoid or limit the HARM
[SOURCE: ISO/IEC Guide 51:2014, 3.9, modified – Note 1 to entry updated to remove the
reference to hazardous event.]
3.14
RISK ANALYSIS
systematic use of available information to identify HAZARDS and to estimate the RISK
[SOURCE: ISO/IEC Guide 51:2014, 3.10]
3.15
RISK ASSESSMENT
overall process comprising a RISK ANALYSIS and a RISK EVALUATION
[SOURCE: ISO/IEC Guide 51:2014, 3.11]
3.16
RISK CONTROL
process in which decisions are made and measures implemented by which RISKS are reduced
to, or maintained within, specified levels
[SOURCE: ISO/IEC Guide 63:2012, 2.12]
3.17
RISK EVALUATION
process of comparing the estimated RISK against given RISK criteria to determine the
acceptability of the RISK
[SOURCE: ISO/IEC Guide 63:2012, 2.14]
3.18
RISK MANAGEMENT
systematic application of management policies, procedures and practices to the tasks of
analyzing, evaluating, controlling, and MONITORING RISK
[SOURCE: ISO/IEC Guide 63:2012, 2.15]
3.19
SAFETY
freedom from unacceptable RISK
[SOURCE: ISO/IEC Guide 63:2012, 2.16]
3.20
SECURITY
protection of information and data so that unauthorized persons or systems cannot read or
modify them and authorized persons or systems are not denied access to them

– 10 – IEC 82304-1:2016 © IEC 2016
[SOURCE: ISO 12207:2008, 4.39]
3.21
SOFTWARE MAINTENANCE
modification of HEALTH SOFTWARE PRODUCT after release for INTENDED USE, for one or more of
the following reasons:
a) corrective, as fixing faults;
b) adaptive, as adapting to new hard- or software platform;
c) perfective, as implementing new requirements;
d) preventive, as making the product more maintainable
Note 1 to entry: See also ISO/IEC 14764:2006.
3.22
USER
person interacting with the HEALTH SOFTWARE PRODUCT
Note 1 to entry: In general, a USER is not considered to be a RESPONSIBLE ORGANIZATION, except for consumer
type HEALTH SOFTWARE PRODUCTS, e.g., for personal health applications, or products to be used by lay persons.
3.23
VALIDATION
confirmation, through the provision of objective evidence, that the requirements for a specific
INTENDED USE or application have been fulfilled
Note 1 to entry: The objective evidence needed for a VALIDATION is the result of a test or other form of
determination such as performing alternative calculations or reviewing documents.
Note 2 to entry: The word “validated” is used to designate the corresponding status.
Note 3 to entry: The use conditions for VALIDATION can be real or simulated.
[SOURCE: ISO 9000:2015, 3.8.13]
3.24
VERIFICATION
confirmation, through the provision of objective evidence, that specified requirements have
been fulfilled
Note 1 to entry: The objective evidence needed for a VERIFICATION can be the result of an inspection or of other
forms of determination such as performing alternative calculations or reviewing documents.
Note 2 to entry: The activities carried out for VERIFICATION are sometimes called a qualification process.
Note 3 to entry: The word “verified” is used to designate the corresponding state.
[SOURCE: ISO 9000:2015, 3.8.12]
4 * HEALTH SOFTWARE PRODUCT requirements
4.1 General requirements and initial RISK ASSESSMENT
The MANUFACTURER shall determine and document:
a) the INTENDED USE for the HEALTH SOFTWARE PRODUCT, including the intended USER profile
and the intended operational environment;
b) the characteristics related to the SAFETY and/or SECURITY of the HEALTH SOFTWARE
PRODUCT, identification of HAZARDS and estimation of the associated RISK(S). As
applicable, this includes situations where the HEALTH SOFTWARE PRODUCT can be
configured and/or supports interfaces to other products;

IEC 82304-1:2016 © IEC 2016 – 11 –
c) the need for RISK CONTROL measures for estimated RISKS that are considered
unacceptable.
NOTE 1 Subclause 4.1 does not require a formal and full RISK MANAGEMENT as, for example, per ISO 14971.
However, performing the initial steps of that process is considered good practice.
NOTE 2 RISK CONTROL measures can be hardware, an independent software system, health care procedures, or
other means.
NOTE 3 Sources of information on SECURITY vulnerabilities include publicly available reports from authorities, as
well as publications by suppliers of, for instance, operating systems and third party software.
4.2 HEALTH SOFTWARE PRODUCT use requirements
The MANUFACTURER shall determine and document:
a) requirements that address the INTENDED USE;
b) interface requirements, including USER interface requirements where applicable;
NOTE 1 In contrast to the USER interface specification as part of the HEALTH SOFTWARE PRODUCT system
requirements, USER interface requirements do not describe technical (realization) requirements. They describe the
purpose of the technical requirements.
EXAMPLE "The displayed information shall be readable from a distance of 3 m in an emergency unit.”
NOTE 2 IEC 62366-1:2015 provides a process to establish USER interface requirements.
c) requirements for immunity from or susceptibility to unintended influence by other software
using the same hardware resources;
d) privacy and SECURITY requirements addressing areas such as authorised use, person
authentication, health data integrity and authenticity, and protection against malicious
intent;
NOTE 3 See 7.2.3.1 and IEC TR 80001-2-2 (list of SECURITY capabilities) for further information on SECURITY
aspects.
e) requirements for ACCOMPANYING DOCUMENTS such as instructions for use (see 7.2.2);
f) requirements to support:
1) upgrades from previous versions, including maintaining data integrity, and
compatibility with prior versions,
2) rollback to the previous version after upgrade,
SECURITY patches and updates,
3) timely
4) software distribution mechanism that ensures integrity of installation,
5) decommissioning, irreversible deletion, transfer and/or retention of data;
g) requirements derived from applicable regulation, including rules for protected information.
NOTE 4 In some jurisdictions, data protection regulations (e.g. European data protection directive 95/46/EC,
revised in 2016) mandate citizens to maintain control over their personal data such as to delete or export data.
European directive 95/46/EC will be replaced by the European General Data Protection Regulation (2016/679) on
25 May 2018.
4.3 VERIFICATION of HEALTH SOFTWARE PRODUCT use requirements
The MANUFACTURER shall verify that the HEALTH SOFTWARE PRODUCT use requirements are:
a) defined and documented as input for system requirements;
b) such that the MANUFACTURER is able to meet the defined use requirements.
The results of the VERIFICATION shall be recorded.

– 12 – IEC 82304-1:2016 © IEC 2016
4.4 Updating HEALTH SOFTWARE PRODUCT use requirements
The MANUFACTURER shall ensure that the HEALTH SOFTWARE PRODUCT use requirements are
updated as appropriate, e.g. as a result of HEALTH SOFTWARE PRODUCT use requirements
VERIFICATION (see 4.3) or as a result of VALIDATION.
4.5 System requirements
The MANUFACTURER shall specify and document the system requirements for the HEALTH
SOFTWARE PRODUCT. These requirements shall include the functionality for INTENDED USE and,
as applicable:
a) inter-operability;
b) localization and language support;
c) RISK CONTROL measures that have to be implemented in the HEALTH SOFTWARE PRODUCT at
system level, based on the initial RISK ASSESSMENT of 4.1;
d) USER interface specification;
e) requirements on the software and hardware platforms for the HEALTH SOFTWARE PRODUCT
to function as expected under expected load, and with required performance levels;
f) features that allow for SECURITY compromises to be detected, recognized, logged, timed,
and acted upon during normal use;
g) features that protect essential functions, even when the software SECURITY has been
compromised;
h) methods for retention and recovery of product configuration by an authenticated privileged
USER.
The HEALTH SOFTWARE PRODUCT system requirements shall meet the HEALTH SOFTWARE
PRODUCT use requirements (see 4.2).
NOTE 1 The website http://www.himss.org/library/interoperability-standards/what-is-interoperability provides one
source of information on inter-operability.
NOTE 2 Technical requirements for the USER interface can include display colour, character size, or placement of
the controls.
NOTE 3 The typical software platform includes, but is not limited to: operating system, device drivers, software
libraries, and other USER application(s).
NOTE 4 There is not necessarily a difference between SOFTWARE SYSTEM requirements of IEC 62304:2006, 5.2.1
and and HEALTH SOFTWARE PRODUCT system requirements.
4.6 VERIFICATION of system requirements
The MANUFACTURER shall verify that the system requirements:
a) do not contradict each other;
b) are expressed in terms that avoid ambiguity;
c) are stated in terms that permit the establishment of test criteria and performance of tests
to determine that test criteria have been met; and
d) can be uniquely identified.
The results of the VERIFICATION shall be recorded.
4.7 Updating HEALTH SOFTWARE PRODUCT system requirements
The MANUFACTURER shall ensure that the HEALTH SOFTWARE PRODUCT system requirements are
updated as appropriate, e.g. as a result of modification on the HEALTH SOFTWARE PRODUCT use
requirements, as a result of system requirement VERIFICATION (see 4.6), or as a result of

IEC 82304-1:2016 © IEC 2016 – 13 –
applying 5.2 of IEC 62304:2006 and IEC 62304:2006/AMD1:2015 (software requirements
analysis).
5 * HEALTH SOFTWARE – Software life cycle processes
The system requirements for the HEALTH SOFTWARE PRODUCT established in 4.5 shall be used
as primary design input for the life cycle process of the HEALTH SOFTWARE PRODUCT.
The requirements in 4.2, 4.3, Clause 5, Clause 6, Clause 7, Clause 8 and Clause 9 of
IEC 62304:2006 and IEC 62304/AMD1:2015 shall apply to the HEALTH SOFTWARE in addition to
the other requirements of this document.
IEC 62304:2006 and IEC 62304/AMD1:2015 normatively references ISO 14971:2007. It is
recognized that the MANUFACTURER might not be able to follow all the process steps identified
in ISO 14971:2007 for each constituent component of the HEALTH SOFTWARE, such as
proprietary components, subsystems of non-healthcare origin, and legacy software. In this
case, the MANUFACTURER shall take account of the RESIDUAL RISKS and implement RISK
CONTROLS around those found to be unacceptable.
6 * HEALTH SOFTWARE PRODUCT VALIDATION
6.1 VALIDATION plan
The MANUFACTURER shall establish a VALIDATION plan addressing all HEALTH SOFTWARE
PRODUCT use requirements established in 4.2.
In the VALIDATION plan, the MANUFACTURER shall:
a) identify the VALIDATION scope and the corresponding VALIDATION activities;
b) identify the constraints that potentially limit the feasibility of VALIDATION activities;
c) select appropriate VALIDATION methods, input information, and associated acceptance
criteria for successful VALIDATION;
d) identify the enabling systems or services such as operating environment(s), including
hardware and software platforms, needed to support VALIDATION;
e) specify the required qualification of the VALIDATION personnel; where training is required,
this shall be completed before starting the VALIDATION;
f) define the appropriate level of independence of the VALIDATION team from the design
team.
NOTE 1 Constraints include: technical feasibility, cost, time, availability of VALIDATION enablers or qualified
personnel, contractual constraints, criticality of the mission, etc.
NOTE 2 VALIDATION methods include: inspection, analysis, analogy/similarity, demonstration, simulation, peer-
review, testing or certification. Relevant information: reference to standards and other publications such as
compatibility standards, regulatory authority guidance documents, and clinical literature.
6.2 Performing VALIDATION
The MANUFACTURER shall confirm readiness for VALIDATION once:
a) the VALIDATION plan has been established;
b) the VALIDATION team has been set up with the appropriately qualified personnel; and
c) as appropriate, development life cycle phases as required by Clause 5 have been
completed for those parts of the HEALTH SOFTWARE PRODUCT subject to VALIDATION.

– 14 – IEC 82304-1:2016 © IEC 2016
The VALIDATION team shall perform the VALIDATION activities in the intended operational
environment(s) according to the VALIDATION plan of 6.1. Where deviations from the VALIDATION
plan are deemed necessary, they shall be justified in the VALIDATION report.
When ANOMALIES are found in the HEALTH SOFTWARE PRODUCT during VALIDATION, these shall
be resolved through a problem resolution process according to Clause 9 of
IEC 62304/AMD1:2015. Where this problem resolution process results in modification of the
HEALTH SOFTWARE PRODUCT, the affected part of the VALIDATION shall be repeated, taking into
account the extent of the modification.
6.3 VALIDATION report
The VALIDATION team shall develop the VALIDATION report for the HEALTH SOFTWARE PRODUCT
subject to VALIDATION.
The VALIDATION report shall provide evidence that:
a) the VALIDATION results are traceable to the HEALTH SOFTWARE PRODUCT use requirements,
taken as input;
b) the HEALTH SOFTWARE PRODUCT meets the use requirements established in 4.2; and
c) the RESIDUAL RISK of the HEALTH SOFTWARE PRODUCT remains acceptable.
The VALIDATION report shall document the VALIDATION conditions and the results of the
VALIDATION activities. If, during VALIDATION, ANOMALIES were identified in the HEALTH SOFTWARE
PRODUCT, these shall be listed in the VALIDATION report.
The VALIDATION report shall list the members of the VALIDATION team (name, affiliation,
function).
The VALIDATION report shall include a summary of the VALIDATION results, and the conclusion
that the HEALTH SOFTWARE PRODUCT is validated for the INTENDED USE, based on the use
requirements.
7 HEALTH SOFTWARE PRODUCT identification and ACCOMPANYING DOCUMENTS
7.1 * Identification
A HEALTH SOFTWARE PRODUCT shall be identified with the name or trademark of the
MANUFACTURER, a product name, or type reference, and a unique version identifier such as a
revision level or date of release/issue.
NOTE 1 In some jurisdictions, a Unique Device Identification (UDI) is mandatory.
The identification of the HEALTH SOFTWARE PRODUCT shall be accessible to the USER when
using the HEALTH SOFTWARE.
NOTE 2 Including the identification in the opening page or log-in screen is considered good practice.
7.2 ACCOMPANYING DOCUMENTS
7.2.1 General
The MANUFACTURER shall make available ACCOMPANYING DOCUMENTS for the HEALTH SOFTWARE
to allow the USER and/or RESPONSIBLE ORGANIZATION to implement and use the HEALTH
SOFTWARE PRODUCT as intended.
The ACCOMPANYING DOCUMENTS shall include:

IEC 82304-1:2016 © IEC 2016 – 15 –
a) the name and contact information, including the website, of the MANUFACTURER;
b) the HEALTH SOFTWARE PRODUCT identification (see 7.1);
c) the version identifier(s) of the HEALTH SOFTWARE PRODUCT(S) ) such as revision level(s) or
date(s) of release/issue, necessary to identify the HEALTH SOFTWARE PRODUCT(S) to which it
applies;
d) the version identifier of the ACCOMPANYING DOCUMENTS such as revision level or date of
release/issue;
e) the instructions for use (see 7.2.2); and
f) the technical description (see 7.2.3).
The ACCOMPANYING DOCUMENTS may include software release notes and an indication of
typical installation environments.
The ACCOMPANYING DOCUMENTS shall specify any special skills, training and knowledge
required of the intended USER or the RESPONSIBLE ORGANIZATION, any restrictions on locations
or environments in which the HEALTH SOFTWARE PRODUCT can be used, and, as applicable, any
system interface, software platforms and tools, and hardware requirements or restrictions.
The ACCOMPANYING DOCUMENTS shall be provided at a level consistent with the education,
training and any special needs of the person(s) for whom they are intended.
NOTE Providing ACCOMPANYING DOCUMENTS in electronic format can improve usability. Regulatory authorities can
specify a particular format for ACCOMPANYING DOCUMENTS, or parts thereof, when provided electronically.
7.2.2 Instructions for use
7.2.2.1 General
The instructions for use shall
...