1、DRAFT FOR DEVELOPMENTDD CEN/TS 15260:2006Health informatics Classification of safety risks from health informatics products ICS 35.240.80g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g
2、38g50g51g60g53g44g42g43g55g3g47g36g58DD CEN/TS 15260:2006This Draft for Development was published under the authority of the Standards Policy and Strategy Committee on 31 July 2006 BSI 2006ISBN 0 580 48892 6National forewordThis Draft for Development is the official English language version of CEN/T
3、S 15260:2006.This publication is not to be regarded as a British Standard.It is being issued in the Draft for Development series of publications and is of a provisional nature. It should be applied on this provisional basis, so that information and experience of its practical application may be obta
4、ined.Comments arising from the use of this Draft for Development are requested so that UK experience can be reported to the European organization responsible for its conversion to a European standard. A review of this publication will be initiated 2 years after its publication by the European organi
5、zation so that a decision can be taken on its status at the end of its 3-year life. Notification of the start of the review period will be made in an announcement in the appropriate issue of Update Standards.According to the replies received by the end of the review period, the responsible BSI Commi
6、ttee will decide whether to support the conversion into a European standard, to extend the life of the Technical Specification or to withdraw it. Comments should be sent in writing to the Secretary of BSI Technical Committee IST/35, Health informatics, at British Standards House, 389 Chiswick High R
7、oad, London W4 4AL, giving the document reference and clause number and proposing, where possible, an appropriate revision of the text.A list of organizations represented on this committee can be obtained on request to its secretary.Cross-referencesThe British Standards which implement international
8、 or European publications referred to in this document may be found in the BSI Catalogue under the section entitled “International Standards Correspondence Index”, or by using the “Search” facility of the BSI Electronic Catalogue or of British Standards Online.This publication does not purport to in
9、clude all the necessary provisions of a contract. Users are responsible for its correct application.Summary of pagesThis document comprises a front cover, an inside front cover, the CEN/TS title page, pages 2 to 30, an inside back cover and a back cover.The BSI copyright notice displayed in this doc
10、ument indicates when the document was last issued.Amendments issued since publicationAmd. No. Date CommentsTECHNICAL SPECIFICATIONSPCIFICATION TECHNIQUETECHNISCHE SPEZIFIKATIONCEN/TS 15260March 2006ICS 35.240.80English VersionHealth informatics - Classification of safety risks from healthinformatics
11、 productsInformatique de sant - Classification des risques de sretdes produits dinformation de santThis 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 m
12、embers of CEN will be requested to submit theircomments, 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 availablepromptly at national level
13、 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,
14、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 STANDARDIZATIONCOMIT EUROPEN DE NORMALISA
15、TIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: rue de Stassart, 36 B-1050 Brussels 2006 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. CEN/TS 15260:2006: E2 Contents Page Foreword3 Introduction .4 1 Scope 7 2 Normative references
16、 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 products17 9 Relationship of risk classes to design and control of
17、production of products 17 Annex A (informative) Health informatics products and medical devices: rationale18 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 manag
18、ement 26 Bibliography 29 CEN/TS 15260:20063 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 organizat
19、ions 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
20、, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. CEN/TS 15260:20064 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 organisat
21、ion, 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
22、 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 clinic
23、al 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 publ
24、ic 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 thos
25、e 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
26、 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
27、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
28、 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 stan
29、dard 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 se
30、rious 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
31、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
32、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 syste
33、m 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; CEN/TS 15260:20065 failure to update
34、 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. Th
35、is 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
36、 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 a
37、pplication 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 no
38、t 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 a
39、pplications 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 incre
40、asingly 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 applica
41、tion 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
42、 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 har
43、m 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 possi
44、ble). 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 safet
45、y 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
46、 (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
47、document is concerned with software applied to health which is not encompassed by EU Directives covering medical devices. CEN/TS 15260:20066 A necessary precursor for determining and implementing appropriate design and production controls to minimise risks to patients from product malfunction or ina
48、dequate 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
49、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 a
