CEN/TS 15260:2006

SLOVENSKI STANDARD
01-junij-2006
Zdravstvena informatika - Klasifikacija nevarnosti izdelkov zdravstvene
informatike
Health informatics - Classification of safety risks from health informatics products
Medizinische Informatik - Klassifikation von Sicherheitsrisiken bei der Benutzung von
Medizininformatikprodukten
Informatique de santé - Classification des risques de sureté des produits d'information de
santé
Ta slovenski standard je istoveten z: CEN/TS 15260:2006
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.

TECHNICAL SPECIFICATION
CEN/TS 15260
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
March 2006
ICS 35.240.80
English Version
Health informatics - Classification of safety risks from health
informatics products
Informatique de santé - Classification des risques de sûreté
des produits d'information de santé
This Technical Specification (CEN/TS) was approved by CEN on 24 October 2005 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania,
Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2006 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15260:2006: E
worldwide for CEN national Members.

Contents Page
Foreword.3
Introduction .4
1 Scope .7
2 Normative references .7
3 Terms and definitions .7
4 Abbreviated terms .8
5 Principles of hazard and risk analysis .8
6 Assignment of a risk class to a health informatics product .10
7 The analytical process .13
8 Examples of assignment of risk classes to products.17
9 Relationship of risk classes to design and control of production of products .17
Annex A (informative) Health informatics products and medical devices: rationale.18
Annex B (informative) Examples of assignment of Risk Classes .21
Annex C (informative) Illustration of the nature of the relationship between risk classes and
potential controls for risk management .26
Bibliography .29

Foreword
This Technical Specification (CEN/TS 15260:2006) has been prepared by Technical Committee CEN/TC 251
“Health informatics”, the secretariat of which is held by NEN.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden,
Switzerland and United Kingdom.
Introduction
In the past health-related software was primarily applied to relatively non-critical administrative functions
where the potential for harm to the patient, as distinct from disruption to the organisation, was low. Clinical
systems were generally unsophisticated often with a large administrative, rather than clinical, content and little
in the way of decision support. Even clinical decision support systems tended to be ‘light touch’, relatively
simple and understandable in their logic and used as a background adjunct to decisions, rather than a major
influence on which to rely routinely. That has changed and will continue to change substantially. The nature of
these changes will increase the potential for risks to patients.
There have been some high profile adverse incidents related to clinical software e.g. in the area of screening
and patient call and/or recall where software malfunctions have resulted in failure to ‘call’ ‘at-risk’ patients.
Such incidents have not only caused anguish for the many patients concerned but may also have led to
premature deaths. The trust of the general public has been severely dented. The scope for screening for
diseases is increasing significantly and it is in such applications involving large numbers of subjects that there
will be heavy reliance, administratively and clinically, on software to detect normals and abnormals and to ‘call’
or ‘process’ those deemed to be at-risk. Such software needs to be safe for purpose.
There is mounting concern around the world about the substantial number of avoidable clinical incidents which
have an adverse effect on patients of which a significant proportion result in avoidable death or serious
disability [1] [2] [3] [4] [5] [6]. A number of such avoidable incidents involve poor or ‘wrong’ diagnoses or other
decisions. A contributing factor is often missing or incomplete information or simply ignorance e.g. of clinical
options in difficult circumstances or cross-reactions of treatments.
It is increasingly claimed that information systems such as decision support, protocols, guidelines and
pathways could markedly reduce such adverse effects. If for no other reasons – and there are others – this
will lead, and is leading, to increasing utilisation of decision support and disease management systems which
inevitably will increase in sophistication and complexity. It can also be anticipated that, due to pressures on
time and medico-legal aspects, clinicians will increasingly rely on such systems with less questioning of their
‘output’. Indeed, as such systems become integrated with medical care any failure to use standard support
facilities may be criticised on legal grounds.
Increased decision support can be anticipated not only in clinical treatment but also in areas just as important
to patient safety such as referral decision-making, where failure to make a ‘correct’ referral or to make one 'in
time’ can have serious consequences.
Economic pressures are also leading to more decision support systems. The area of generic and/or economic
prescribing is the most obvious, but economy in number and costs of clinical investigative tests is another.
Systems such as for decision support have considerable potential for reducing clinical errors and improving
clinical practice. For example a large body of published evidence gives testimony to the reduction in errors
and adverse incidents resulting from the deployment of electronic prescribing. However all such systems also
carry the potential for harm. Harm can of course result from unquestioning and/or non-professional use albeit
that designers and suppliers can mitigate such circumstances through, for example, instructions for use,
training and on-screen presentation techniques, guidance or instruction. The potential for harm may equally lie
in the system design such as:
 poor evidence base for design;
 failure in design logic to properly represent design intentions;
 failure in logic to represent good practice or evidence in the design phase;
 poor or confusing presentation of information or poor search facilities;
 failure to update in line with current knowledge.
Some of these system deficiencies are insidious and may be invisible to the user.
A substantial increase in spending on information management and technology is evident in many national
health systems. Associated timetables are often tight and the goals ambitious. This increased spending can
be expected to attract new suppliers, some of which may be inexperienced in healthcare processes. Such
circumstances could lead to an environment of increased risks to patient well being.
Part of the foreseeable explosion in information and communications technology will be in telemedicine. Many
of the health informatics products supporting such applications will be innovative and untried and the distance
between clinicians and patients will make the scope for errors greater as well as less evident. Similarly,
increasing use of innovative mobile IT devices and their application to new fields is likely to be associated with
risks.
Whereas the paperless, film-less hospitals are many years distance, GP practices are heading that way. The
inability to fall back on paper and film brings increased reliance on computers and databases. Corruption and
loss of data can not only bring administrative chaos but can also significantly affect patient care.
In summary the potential for harm to patients from the use of information and communications technology
(ICT) in health applications will rise as the use of ICT in health applications rises; the sophistication of the
applications increases and the reliance on ICT grows. There is evidence of increasing concern amongst
professionals, and by the public, as incidents of malfunctions of software, leading to adverse health
consequences, raise public consciousness.
Consequently a number of health organisations are increasingly focusing on 'controls assurance' standards
including those on 'governance' and 'risk management'. An important feature of such controls is the
management of risk in the context of harm to patients and deficiencies in the quality of care. These controls
will often encompass the purchase and application of health informatics products.
Failures and deficiencies in health informatics products can, of course, have adverse impacts other than
causing harm to patients. They may, for example, create administrative inconvenience or even administrative
chaos, with a range of impacts on the organisation including financial loss. Harm to a patient may also have a
consequent impact on the organisation such as financial loss resulting from litigation. Whereas these adverse
organisational impacts will be significant to an organisation they are not the subject of this document unless
they result in harm to a patient. For example the failure of a hospitals central patient administration system will
certainly cause substantial administrative inconvenience but that adverse impact is not in itself within the
scope of this document unless it has the potential to cause harm to a patient (which is possible). It is the
potential harm to the patient which is the subject of this document.
The safety of medicines and of medical devices in the EU is assured through a variety of legal and
administrative measures and is subject to several EU directives [7] [8] [9]. These measures are backed by a
range of safety related standards from a number of sources, both national and international, including the
European Standards organisation (CEN), the International Standards Organisation (ISO) and the International
Electrotechnical Committee (IEC). Software necessary for the proper application of a medical device (together
with some software supplied as an accessory for a medical device but necessary for it to meet its purpose e.g.
for in vitro devices) is encompassed by these controls e.g. within EU directives and legislation implementing
them. However other software applied to health is not covered. This document is concerned with software
applied to health which is not encompassed by EU Directives covering medical devices.
A necessary precursor for determining and implementing appropriate design and production controls to
minimise risks to patients from product malfunction or inadequate performance, is a clear understanding of the
hazards which a product might present to patients if malfunction or an unintended event should occur and the
likelihood of such a malfunction or event causing harm to the patient. Additionally if guidance is to be given to
designers and producers of health informatics products as to design and production control (and
corresponding standards produced) then it will need to be recognised that the controls necessary for products
presenting low risks will not be the same as for those presenting high risks. Controls need to match the level
of risk which a product might present to a patient. For these purposes many standards, legislation and
specifications dealing with control of risks in design and production, group products in to a limited number of
classes or types according to the risk they might present. This document presents a process for such a
grouping of health informatics products. It proposes five risk classes. This will facilitate broad screening of
generic product types and of individual products to allow different levels of, or rigour in, the application of
design and production controls which are matched to risk. Thus the classification proposed may be a
precursor for standards on design and production control, where the latter might require a far more detailed, in
depth and rigorous risk analysis for a particular product than that required for the broad classification process
in this document. Examples of the application of the process for assigning a risk class are given for a number
of different types of health informatics products.
By ‘health informatics products’ is meant any health informatics product whether or not it is placed on the
market and whether or not it is for sale or free of charge. This document thus covers commercial products as
well as, for example, open-source health informatics software and software created for, and used in, only one
health organisation such as a hospital.
1 Scope
This document is concerned with the safety of patients and gives guidance on the analysis and categorisation
of hazards and risks to patients from health informatics products, to allow any product to be assigned to one of
five risk classes. It applies to hazards and risks which could cause harm to a patient. Other risks such as
financial or organisational are out of scope unless they have the potential to harm a patient.
This document applies to any health informatics product whether or not it is placed on the market and whether
or not it is for sale or free of charge. Examples of the application of the classification scheme are given.
This document does not apply to any software which is encompassed within EU Medical Devices Directives
[7] [8] [9].
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
harm
death, physical injury and/or damage to health or well being of a patient
3.2
hazard
potential source of harm
[ISO/IEC Guide 51]
3.3
risk
likelihood of a hazard causing harm and the degree of severity of the harm
3.4
hazard and risk analysis
investigation of available information to identify hazards and to estimate risks
3.5
tolerable risk
risk which is accepted in a given context based on the current values of society
[IEC 61508-4]
3.6
safety
freedom from unacceptable risk of harm
[ISO/IEC Guide 51]
3.7
risk class
classification of a health informatics product according to the underlying risk it might present to the safety of
patients
3.8
patient
any person who is subject to, or is utilising, a health informatics product. In this document that shall be taken
to include healthy persons where applicable (e.g. a healthy person accessing a knowledge data base to obtain
health-related information)
3.9
product
product comprises the entire entity proffered to a user including instructions for use and where applicable
training
3.10
health informatics product
software proffered for use in the health sector for health-related purposes but excluding software necessary
for the proper application of a medical device

4 Abbreviated terms
ICT Information and Communication Technologies
5 Principles of hazard and risk analysis
Designers and producers of health informatics products should have a clear understanding of the hazards
which their product might present to a patient, if it were to malfunction or to cause an unintended event and
the degree of likelihood that the hazard might be realised if it were to occur in reasonable circumstances of
use. That knowledge is necessary for the extent and nature of the control measures required, and the rigour
with which they must be applied, so as to reduce the risk to patients to a tolerable level e.g. through measures
such as inherent design features, instructions for use, induction training. What is tolerable will depend on
circumstances and the current views of society and regulators.
The essential precursor to this process is to undertake a hazard and risk analysis.
There are a variety of approaches to hazard and risk analysis: all share a set of underlying concepts. Existing
standards, guidance and publications tend to focus on particular sectors of activity (e.g. electronic safety
systems, aeronautics) or subject areas (e.g. financial risks, risks to property, risks to the security of personal
data). As such they need interpretation in the context of health informatics products. This document draws on
a variety of sources to keep in line with accepted general principles. The Bibliography provides a list of useful
sources of information on the subject. In considering the approach to take for health informatics products,
account has been taken of how medical devices are classified and controlled in terms of safety. Annex A
addresses this matter. The following presents some of the basic concepts in so far as they are utilised in this
document. This section is not intended to cover all aspects of hazard/risk analysis.
The risk to the safety of a patient or patients from a health informatics product will depend on the possible
consequence(s) that might result if the product malfunctioned or resulted in an adverse event or events, and
the likelihood that such consequence(s) would in fact be realised. Thus risk has two aspects: consequence
and likelihood.
Note that ISO/IEC Guide 73 [18] defines risk as the “combination of the probability of an event and its
consequence” whereas this standard defines it as “the likelihood of a hazard causing harm and the degree of
severity of the harm”. This is for two reasons. The probability that a hazard will be realised might, in some
domains, be represented quantitatively as a probability which may be based on historical or experimental
failure analysis and incident statistics. That is very unlikely to be the case with health informatics products
safety where such statistics and evidence are not available: qualitative judgements are necessary. Whereas
probability can of course be qualitatively expressed, the term ‘likelihood’ better conveys that meaning and is
therefore used in this standard. Additionally the standard is focussed only on events that are likely to cause
harm to patients and the severity of that harm rather than other events. Thus the definition refers to harm
rather than other events in general.
The consequence i.e. harm to the patient(s), may take different forms varying from, for example, death to
minor inconvenience. Consequences may be categorised. Such categories need interpretation according to
their sphere of application: in this case the application of ICT to health. This document proposes five
‘consequence’ categories each with a description of its scope (see section 6.2).
The likelihood that a hazard will be realised in reasonably foreseeable circumstances might, in some domains,
be represented quantitatively as a probability which may be based of historical or experimental failure analysis
and incident statistics. That is very unlikely to be the case with health informatics products safety where such
statistics and evidence are not available: qualitative judgements are necessary. This document proposes five
likelihood categories each with a description of its scope (see section 6.3).
As noted earlier, the risk to the safety of a patient or patients from a health informatics product depends on the
possible consequence(s) that might result if the product malfunctioned or resulted in an adverse event or
events, and the likelihood that such consequence(s) would in fact be realised. The level of risks can be
represented in a risk matrix where likelihood and consequence are its two dimensions (Table 1).
Table 1
Consequence
Likelihood
Worst  Least
Highest 1 2
Lowest  5 6
Each cell of the matrix thereby represents a level of risk. Thus in the risk matrix above the 25 cells represent
25 risk outcomes which reduce in severity on moving diagonally from top left to bottom right.
Such levels of risk outcomes can be grouped into classes such as:
 Highest risk class would be a group of cells in the top left such as 1, 2 and 3;
 Lowest risk class would be a group of cells in the bottom right such as 4, 5 and 6.
The cells of the risk matrix can thereby be populated with risk classes. Which cells are grouped together in to
a class requires consideration of the circumstances within the application sector and the meanings assigned
to each category of consequence and likelihood. The aim is to reduce complexity by identifying cells which
broadly represent a similar degree of risk to the patient and grouping them in to a class on that premise. Thus
a minor consequence with a high likelihood might broadly equate to a worse consequence but with lesser
likelihood.
This document proposes five risk classes (see section 6.4).
6 Assignment of a risk class to a health informatics product
6.1 Introduction
This section proposes categories for consequences arising from hazards, and categories for the likelihood of
such consequences being realised, in the context of health informatics products. It further proposes a number
of risk classes for health informatics products and relates those classes to the proposed categories of
consequence and likelihood through a risk matrix. Annex B demonstrates the application of these proposals to
different types of health informatics product.
6.2 Assignment to consequence categories
Hazards (potential for harm) which a health informatics product might present to a patient if it were to
malfunction or be the cause of an adverse event, shall be determined and the potential consequences of such
hazards shall be identified. Each such consequence shall be assigned to one of the following consequence
categories:
 catastrophic;
 major;
 considerable;
 significant;
 minor.
Note that it will not be necessary to identify and categorise all possible consequences that could arise. The
analysis to identify the realistic consequences and the likelihood of their occurring need be undertaken only to
the extent necessary to assign, with confidence, the product to a risk class though the iterative process
described in section 6.6.
The consequence categories shall be interpreted as in the Table 2. The descriptions have been created to suit
the context of this document, but are consistent with those in other sectors and in other complementary
disciplines and approaches [11] [12] [13].
Where there is doubt on the margins of two categories the consequence shall be assigned to the category of
worse consequence.
Table 2
Interpretation
Consequence
Category
Consequence Number of patients affected
Catastrophic Deaths. Multiple
Permanent life-changing incapacity and any condition for Multiple
which the prognosis is death or permanent life-changing
incapacity; severe injury or severe incapacity from which
recovery is not expected in the short term.
Major Death. Single
Permanent life-changing incapacity and any condition for Single
which the prognosis is death or permanent life-changing
incapacity; severe injury or severe incapacity from which
recovery is not expected in the short term.
Severe injury or severe incapacity from which recovery is Multiple
expected in the short term.
Severe psychological trauma Multiple
Considerable Severe injury or severe incapacity from which recovery is Single
expected in the short term;
Severe psychological trauma Single
Minor injury or injuries from which recovery is not expected in Multiple
the short term;
Significant psychological trauma Multiple
Significant Minor injury or injuries from which recovery is not expected in Single
the short term;
Significant psychological trauma, Single
Minor injury from which recovery is expected in the short Multiple
term.
Minor psychological upset; inconvenience; Multiple
Minor Minor injury from which recovery is expected in the short Single
term; minor psychological upset; inconvenience; any
negligible consequence.
In identifying the hazards which a health informatics product or product type may present to a patient, a
hazard shall not be dismissed simply because it is believed that the design of the product is such that there
are no circumstances in which the hazard would arise because of the particular product or general design
features. The potential for harm (hazards) which the product could present shall be determined as if such
design features and controls were not present or malfunctioned.
In identifying the hazards which a health informatics product may present to a patient if it were to malfunction
or be the cause of an unintended event, shall also not be dismissed simply because, even if the hazard were
to arise, no adverse consequences to a patient would occur because, for example, of vigilance of the user or
other events external to the product. This aspect is addressed by the assignment of likelihood to the
consequence occurring as described in sections 6.3 and 7.4.
6.3 Assignment of likelihood to consequences
For each consequence identified the likelihood of the consequence (s) occurring in reasonably foreseeable
circumstances shall be assessed. Note as pointed out in section 6.2 it will not be necessary to identify all
possible consequences that could arise. The analysis of possible consequences and the assignment to them
of a likelihood of them occurring need be undertaken only to the extent necessary to assign, with confidence,
the product to a risk class though the iterative process described in section 6.6.
Each likelihood shall be assigned to one of the following categories:
 very high;
 high;
 medium;
 low;
 very low.
The likelihood categories shall be interpreted as in the following table. The descriptions have been created to
suit the context of this document, but are consistent with categories in other domains e.g. corporate
governance in healthcare [14].
Where there is doubt on the margins of two categories the likelihood shall be assigned to the category of the
higher likelihood (Table 3).
Table 3
Likelihood
Scope
category
Very high Certain or almost certain; highly likely to occur.
High Not certain but very possible; reasonably expected to occur in the majority of cases.
Medium Possible; not unlikely but occur.
Low Could occur but in the great majority of occasions will not.
Very low Negligible or nearly negligible possibility of occurring.
In assessing likelihood, the likelihood of a consequence shall not be diminished in relation to any feature of
the product itself (including associated instructions for use - see definition). Likelihood in the context of this
section is not the likelihood of the product malfunctioning or being responsible for an adverse event. It is the
likelihood of the consequences of that malfunction or adverse event actually being realised in practice.
However it is permissible to take account of reasonably foreseeable circumstances external to the product.
Thus if for example the identified consequence of a hazardous event could be injury, the likelihood of that
consequence resulting in actual injury to a patient may take account of matters such as the possibility:
 hazardous event being noticed by a user with appropriate qualifications before the consequence occurs;
 consequence being avoided because the number of events over a period of time which would take place
before the consequence would result, would enhance the possibility of the hazard being identified;
 patient would be seen by a healthcare professional before any harm occurred and in sufficient time for
effective treatment or therapy to be delivered.
The circumstances which may be taken into account as reasonable when assigning a likelihood shall be
tempered by the severity of the consequence in question; the criteria being more stringent the more severe
the consequence.
It shall not be permissible to assume best circumstances in all cases. For example it is not permissible to
assume that the operator is always highly competent and/or experienced, since it is reasonably foreseeable
that circumstances will arise when the product will be used by an operator for the first time and that some
operators, even with training, may be only marginally competent. Accepting these circumstances, as a
possibility, is obviously important when a possible consequence is severe such as death.
6.4 Risk classes
This document is based on the concept of risk classes each of which represents a combination of consequent
categories and likelihood categories. Five risk classes are proposed:
 Class A;
 Class B;
 Class C;
 Class D;
 Class E.
Each comprises a grouping of consequence and likelihood combinations which broadly represent the same
level of risk to the safety of patients. Class A represents the highest potential risk and Class E the lowest.
The combinations that derive the risk classes are defined by the Table 4.
Table 4
Consequence
Likelihood
Catastrophic Major Considerable Significant Minor
Very high A A B B C
High A B B C C
Medium B B C D D
Low B C D D E
Very low C C D E E
6.5 Assignment of risk class to a health informatics product
Consequence and likelihood combinations shall be assigned to a risk matrix as in section 6.4 utilising the
iterative process described in section 6.6. The risk class of the health informatics product shall be the highest
identified where Class A is the highest and Class E is the lowest.
6.6 Process of iteration
The risk class into which a product falls depends on the combination of consequence category and likelihood
category. Thus a high consequence category combined with a low likelihood might result in a lower risk class
than a lesser consequence category but with a higher likelihood. Although any analysis will most likely focus
at the outset on realistic worst consequences it will be necessary to consider also lesser consequences to the
extent of being confident, by a process of iteration, that the highest of the resulting risk classes is finally
assigned to a product.
7 The analytical process
The following lists some of the processes which should be considered in the analysis leading to the
assignment of risk class.
7.1 Involvement of stakeholders
It will be essential that any analysis is founded on a clear and suitably in-depth understanding of the system,
the environments in which it will be used and of the users for which the system is intended. Agreement and
decisions should be obtained from representatives of key stakeholders in the health informatics product. This
might best be achieved by assembling a group representing at least:
 those engaged in system design, development and maintenance;
 users;
 those engaged in the business or process environment within which the system will be used.
The group might with advantage include representation or contribution from legal advisors and governance
experts.
For products that are to be offered on a commercial basis, care should be taken to ensure the analysis is not
unduly influenced by a sales view.
7.2 Understanding the system and user environment
The first step is for the team to reach a shared understanding of:
 intent of the system;
 environments in which it is intended to be used;
 system’s characteristics and modes of operation;
 system/human interface;
 dynamics of the processes with which the system will interface and influence.
These matters shall be documented including any scenarios considered and judged unreasonable.
7.3 Consequence analysis
In identifying what might happen if the system were to malfunction or cause an unintended event, and the
consequences of this, the group should:
 ensure the process is business/profession/user driven in contrast, for example, to being sales driven;
 ignore the system's underpinning controls and safety features;
 seek out the adverse events which would arise if the system malfunctioned or was the cause of an
unintended event or operated in an unintended manner including:
 human aspects (accidental and deliberate actions);
 physical failures;
 logical failures;
 communication failures;
 hardware failures;
 software failures;
 focus on scenarios considered to be 'reasonable worst cases';
 inform themselves of actual incidents with the system and learn from them;
 inform themselves of actual incidents with products of a like type, learn from the experience of others
including that reported in relevant literature;
 ensure all stakeholders are involved;
 employ innovative thinking;
 seek out any underlying/eventual impact not just immediate consequences;
 be imaginative but realistic;
 give full weight to the views of users and of those representing the healthcare environment in which the
system is intended to be used.
7.4 Likelihood analysis
In assessing the likelihood of a consequence being realised in reasonably foreseeable circumstances the
group should:
 have before them the adverse events which could arise from a malfunction etc as used in assigning
consequence categories;
 focus on the worst adverse events/consequences first;
 analyse the processes which might lead to harm to a patient arising from adverse events and the
constraints working on those processes;
 consider past incidents which led to harm including those reported in the 'literature';
 consider any likely changes and trends in the reasonably foreseeable future in the field in which the
product is intended to be used;
 in considering human roles in likelihood take into account;
 motivation;
 work pressures and opportunities;
 competencies;
 incentives and disincentives;
 work environment.
 seek out circumstances which might increase likelihood;
 avoid unreasonable confidence in professional or user competence in avoiding consequences;
 take account of the complexity of decisions or processes;
 take into account reasonable expectations of availability of resources, human and other, and particularly
the impact of scarcity;
 interdependency of events in a chain;
 time lag between an adverse event arising from the system to any consequence possibly taking place;
 volume of activity being handled and the extent of remoteness of any consequences from operators. For
example a 'call and recall' system for breast screening may handle many thousands of patients, raising
the statistical likelihood of a consequence being realised if that malfunction affected large numbers all of
whom would be remote from those operating the system and probably having little or no means of
recognising that an adverse event had occurred.
7.5 Iteration
As pointed out in 6.7, the risk class into which a product falls depends on the combination of consequence
category and likelihood category. A high consequence category combined with a low likelihood, might result in
a lower risk class than a lesser consequence category but higher likelihood. Thus although any analysis will
most likely focus at the outset on worst consequences it will be necessary to consider also lesser
consequences and their likelihoods. However not all consequences and their likelihood need be considered as
long as, by a process of iteration, a point is reached whereby there can be confidence in the risk class
assigned i.e. that no other combinations of consequence and likelihood could result in a higher risk class.
7.6 Reviews
Changes in the design of a product or the field of intended application will take place form time to time, for
example:
 Introduction of new or changed functions;
 marketing into new environment (e.g. taking a research system into a wide general market, opening a
market in a new country, targeting a different clinical specialty, healthcare environment or type of
organisation);
 Introduction of new or changed interfaces with other systems.
Changes of this type may change the risk class to which a product should be assigned.
Reviews shall be undertaken as appropriate both periodically and when any change takes place, or is
considered, which might affect the product’s risk class.
7.7 Documentation
The analytical process shall be fully documented including:
 malfunctions and adverse events considered and their consequences including those rejected as
unreasonable;
 analysis of likelihoods to be assigned to consequences including scenarios rejected as unreasonable;
 iterative process and the logic which led to the assignment of the risk class with confidence.
This documentation should be seen as core system documentation whose continued availability and currency
should be assured.
7.8 Incident library
Judgements on reasonable consequences and their likelihood will be greatly assisted by reference to an
incident library, therefore there shall be a means for collecting and storing such incidents.
8 Examples of assignment of risk classes to products
Annex B gives examples of the process for assigning a risk class to different types of health informatics
product.
9 Relationship of risk classes to design and control of production of products
An important application of this document will be the assignment of risk classes to different types of health
informatics products in order to group them for the purposes of presenting guidance, or a standard, for the
design and production of such products. The nature of those controls and the rigour with which they need to
be applied will depend on the risk class in which the product falls. Although it is not the purpose of this
document to specify what these controls should be for any risk class, an illustration of the nature of the
relationship between risk classes and potential controls for risk management is given in Annex C.
Annex A
(informative)
Health informatics products and medical devices: rationale
In many countries the safety of medical devices is assured through legislative provisions. The extent to which
software is encompassed by such controls differs in some details but generally, by definition and by practice,
software is covered only in so far as it is "necessary for the proper applications of a medical device” or is an
accessory to a medical device.

In practice, health informatics products (see definition Clause 3) are not covered by such controls, at least at
present, examples being GP systems, call and recall, research data bases, e-prescribing software, ambulance
dispatch systems etc.
In considering a classification for health informatics products it makes good sense to examine the approach
taken with medical devices and, in that field, the relationship between classifications and controls for assuring
safety so that, as far as practicable the approaches are on the same lines. This Annex considers these
matters briefly. In the interests of brevity no attempt is made to provide an in depth analysis and a number of
complex issues and definitional matters have been simplified.

With medical devices the approach is:

 first broadly to classify devices with classes based on perceived potential risk to patients (typically
four classes with sub-divisions);
 second to apply controls on matters such as design, production, quality systems, labelling etc where
the extent of the controls, and the rigour of their application, depends on the class: the higher the risk
class the stronger the controls.

In this scenario the matter of 'risk' arises in two very different contexts i.e. in the classification and in quality
systems controls.
The classification system is founded on the perceived potential risks to patients. However, for medical
devices, the assignment of class does not require a risk analysis per se (see later).

In contrast, a usual control measure is the requirement for a manufacturer to have a satisfactory quality
system. Part of the latter would be a requirement for risk management and to conduct a full and in depth ri
...