SIST-TS 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. Co
...