CEN TR 15640-2007 Health informatics - Measures for ensuring the patient safety of health software《健康信息学 确保患者健康软件的安全措施》.pdf

《CEN TR 15640-2007 Health informatics - Measures for ensuring the patient safety of health software《健康信息学 确保患者健康软件的安全措施》.pdf》由会员分享，可在线阅读，更多相关《CEN TR 15640-2007 Health informatics - Measures for ensuring the patient safety of health software《健康信息学 确保患者健康软件的安全措施》.pdf（48页珍藏版）》请在麦多课文档分享上搜索。

1、PUBLISHED DOCUMENTPD CEN/TR 15640:2007Health informatics Measures for ensuring the patient safety of health softwareICS 35.240.80g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51

2、g60g53g44g42g43g55g3g47g36g58PD CEN/TR 15640:2007This Published Document was published under the authority of the Standards Policy and Strategy Committee on 28 September 2007 BSI 2007ISBN 978 0 580 56879 4National forewordThis Published Document is the UK implementation of CEN/TR 15640:2007.The UK p

3、articipation in its preparation was entrusted to Technical Committee IST/35, Health informatics.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include all the necessary provisions of a contract. Users are respons

4、ible for its correct application.Amendments issued since publicationAmd. No. Date CommentsTECHNICAL REPORTRAPPORT TECHNIQUETECHNISCHER BERICHTCEN/TR 15640August 2007ICS 35.240.80English VersionHealth informatics - Measures for ensuring the patient safety ofhealth softwareInformatique de Sant - Mesur

5、es pour assurer la scuritdu patient vis vis des logiciels de santInformatik im Gesundheitswesen - Sicherstellung derPatientensicherheit bei der Nutzung vonGesundheitsinformatikproduktenThis Technical Report was approved by CEN on 16 July 2007. It has been drawn up by the Technical Committee CEN/TC 2

6、51.CEN members are the national standards bodies of Austria, Belgium, Bulgaria, 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,

7、 Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMIT EUROPEN DE NORMALISATIONEUROPISCHES KOMITEE FR NORMUNGManagement Centre: rue de Stassart, 36 B-1050 Brussels 2007 CEN All rights of exploitation in any form and by any means reservedworldwide for CEN national Members

8、.Ref. No. CEN/TR 15640:2007: E2 Contents Page Foreword3 Introduction .4 1 Scope 6 2 Terms and definitions .6 3 Symbols and abbreviations 7 4 Outline of the issues .8 5 General position on medical device controls .9 6 The border between health software products and medical devices 10 7 Classifying he

9、alth software products10 7.1 Options .10 7.2 Conclusions .11 8 Options for control measures for health software products 11 8.1 General11 8.2 Labelling and documentation.12 8.3 Clinical evidence12 8.4 Incident reporting 13 8.5 Quality Systems.13 8.6 Design control15 8.7 Risk management 16 9 Standard

10、s specific to risks of a particular nature 17 9.1 Conclusions .17 10 Observation on safety and risks in the user domain.17 10.1 Conclusions .17 11 Taxonomies17 11.1 Conclusions .17 12 Summary of conclusions 18 Annex A (informative) Position regarding medical devices in different countries 20 A.1 The

11、 EU, Australia and Canada20 A.2 USA .21 A.3 The Global Harmonization Task Force (GHTF).22 Annex B (informative) Analysis of classification procedures 24 B.1 EU, Australian, Canadian and GHTF Medical Device Classification 24 B.2 USA Medical Device Classification25 B.3 USA FDA guidance related to soft

12、ware classification.25 B.4 CEN classification of health software products .26 B.5 Conclusions .29 Annex C (informative) Risk management .30 C.1 Attributes necessary for successful uptake of risk management processes.30 C.2 Minimum components for an effective risk management process 30 C.3 Enterprise

13、 risk management processes31 C.4 Healthcare related risk management standards.34 C.5 Related risk management standards.36 C.6 Overall conclusions regarding risk management standards.39 Bibliography 41 CEN/TR 15640:20073 Foreword This document (CEN/TR 15640:2007) has been prepared by Technical Commit

14、tee CEN/TC 251 “Health informatics”, the secretariat of which is held by NEN. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. CEN/TR 1

15、5640:20074 Introduction The threat to patient safety 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 un

16、sophisticated 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

17、major influence on which to rely routinely. This 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 pa

18、tient 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 patients concerned but may also have led to premature deaths. The trust of the general public has been severely affected. The scope for screenin

19、g 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 s

20、afe for purpose. Chief Executives and others responsible for healthcare organisations need to recognise that: health software products have the potential to harm patients; this potential is growing as the complexity of implementations grow; healthcare organisations are increasingly reliant on health

21、 software products. This means that, unless these risks are recognised and controlled, harm to patients may result with consequent damage to the reputation of a health organisation and substantial financial consequences in terms of legal damages. There is mounting concern around the world about the

22、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 involved poor or wrong diagnoses or other decisions. A contributing factor i

23、s often missing or incomplete information or simply ignorance e.g. of clinical options in difficult circumstances or cross-reaction of treatments. It is increasingly claimed that information systems such as decision support, protocols, guidelines and pathways could markedly reduce such adverse effec

24、ts. 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 as

25、pects, 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 cli

26、nical 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 econ

27、omic prescribing is the most obvious, but economy in number and costs of clinical investigative tests is another. CEN/TR 15640:20075 Systems such as for decision support have considerable potential for reducing clinical errors and improving clinical practice. For example a large body of published ev

28、idence 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 ca

29、n 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

30、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. Failur

31、es and deficiencies in health software 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 m

32、ay 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 h

33、ospitals 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

34、which is the subject of this document. Controlling the risks The safety of medicines and of medical devices is ensured in many countries through a variety of legal and administrative measures. In the European Union it is subject to several EU directives 7 8 9. These measures are often backed by a ra

35、nge 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). Some software such as that necessary for the proper a

36、pplication or functioning of a medical device is often encompassed by these legislative controls. However other software applied to health of a stand-alone nature is not usually covered or is encompassed in a less than clear manner. This document is concerned with software applied to health excludin

37、g that which is encompassed by medical device controls. 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 pr

38、esent 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 software products as to design and production control (and corresponding s

39、tandards 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, legisla

40、tion 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. Controls are then tailored to the class or type. This document follows that philosophy. There is a wide range of control

41、s which might be exerted on the design, development, production, distribution, installation, up-grading/version control/up-dating of a health software product etc. This document starts with considering how those controls are applied to medical devices and offers practical solutions how to adapt them

42、 to health software products.” CEN/TR 15640:20076 1 Scope This document considers the control measures required to ensure patient safety in respect to health software products. It does not apply to software which is: necessary for the proper application of a medical device or which is an accessory t

43、o a medical device or which is a medical device in its own right. The document is aimed at identifying what standards might best be used or created, and their nature, if health software products were to be regulated or controlled in some other formal or informal or voluntary manner whether national,

44、 regional or local. However it is not the purpose of this document to recommend whether or not health software products should be regulated. This document applies to any health software product whether or not it is placed on the market and whether or not it is for sale or free of charge. It is addre

45、ssed to manufacturers of health software products. NOTE The scope is intended to cover health software products which are not, in practice, covered by medical device regulations. Annex A considers this matter in detail. This TR acknowledges that, on the boundary, there are health software products w

46、hich are encompassed by medical device regulations in some countries but not in others and that some definitions of medical devices may appear to cover health software products in general but in practice do not. 2 Terms and definitions For the purposes of this document, the following terms and defin

47、itions apply. 2.1 harm death, physical injury and/or damage to health or well being of a patient ISO/IEC Guide 51:1999 modified 65 2.2 hazard potential source of harm ISO/IEC Guide 51:1999 10 2.3 health software product software product for use in the health sector for health related purposes but ex

48、cluding software which is: necessary for the proper application of a medical device or is an accessory to a medical device or is a medical device in its own right. NOTE For the purposes of this standard software includes firmware. 2.4 Manufacturer natural or legal person with responsibility for the

49、design, manufacture, packaging or labelling of a health software product, assembling a system, or adapting a health software product before it is placed on the CEN/TR 15640:20077 market and/or put into service, regardless of whether these operations are carried out by that person himself or on his behalf by a third party ISO 14971:2000, modified 2.5 medical device any instrument, apparatus, appliance material or other article, whether used alone or in combination, including the software necessa