1、 g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58informatics products ICS 35.240.80Health informatics Classification of safety risks from health DRA
2、FT FOR DEVELOPMENTDD CEN/TS 15260:2006DD 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 6a European standard, to extend the life of the Technical Specification or to withdraw it. Co
3、mments should be sent in writing to the Secretary of BSI Technical Committee IST/35, Health informatics, at British Standards House, 389 Chiswick High Road, London W4 4AL, giving the document reference and clause number and proposing, where possible, an appropriate revision of the text.A list of org
4、anizations represented on this committee can be obtained on request to its secretary.Cross-referencesThe British Standards which implement international or European publications referred to in this document may be found in the BSI Catalogue under the section entitled “International Standards Corresp
5、ondence Index”, or by using the “Search” facility of the BSI Electronic Catalogue or of British Standards Online.This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application.Summary of pagesThis document comprises a front
6、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 document indicates when the document was last issued.Amendments issued since publicationAmd. No. Date CommentsComments arising from the use of this Dra
7、ft 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 organization so that a decision can be taken on its
8、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 Committee will decide whether to support the conver
9、sion into National forewordThis Draft for Development is the official English language version of CEN/TS 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
10、 on this provisional basis, so that information and experience of its practical application may be obtained.TECHNICAL SPECIFICATIONSPCIFICATION TECHNIQUETECHNISCHE SPEZIFIKATIONCEN/TS 15260March 2006ICS 35.240.80English VersionHealth informatics - Classification of safety risks from healthinformatic
11、s 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
12、members 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 leve
13、l 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 NORMALIS
15、ATIONEUROPISCHES 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 reference
16、s 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 mana
18、gement 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 organiza
19、tions 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, Romani
20、a, 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 organisa
21、tion, 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
22、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 clini
23、cal 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 pub
24、lic 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 tho
25、se 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
26、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
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 wil
28、l 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 sta
29、ndard 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 s
30、erious 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 syst
33、em 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 updat
34、e 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. T
35、his 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 b
36、e 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
37、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 n
38、ot 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
39、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 incr
40、easingly 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 applic
41、ation 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 organisatio
42、n 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 ha
43、rm 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 poss
44、ible). 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 safe
45、ty 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 devic
46、e (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 in
48、adequate 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 t
