1、PUBLISHED DOCUMENT PD CEN/TR 15640:2007 Health informatics Measures for ensuring the patient safety of health software ICS 35.240.80 PD CEN/TR 15640:2007 This Published Document was published under the authority of the Standards Policy and Strategy Committee on 28 September 2007 BSI 2007 ISBN 978 0
2、580 56879 4 National foreword This Published Document is the UK implementation of CEN/TR 15640:2007. The UK participation 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 secret
3、ary. This publication does not purport to include all the necessary provisions of a contract. Users are responsible for its correct application. Amendments issued since publication Amd. No. Date CommentsTECHNICALREPORT RAPPORTTECHNIQUE TECHNISCHERBERICHT CEN/TR15640 August2007 ICS35.240.80 EnglishVe
4、rsion HealthinformaticsMeasuresforensuringthepatientsafetyof healthsoftware InformatiquedeSantMesurespourassurerlascurit dupatientvisvisdeslogicielsdesant InformatikimGesundheitswesenSicherstellungder PatientensicherheitbeiderNutzungvon Gesundheitsinformatikprodukten ThisTechnicalReportwasapprovedby
5、CENon16July2007.IthasbeendrawnupbytheTechnicalCommitteeCEN/TC251. CENmembersarethenationalstandardsbodiesofAustria,Belgium,Bulgaria,Cyprus,CzechRepublic,Denmark,Estonia,Finland, France,Germany,Greece,Hungary,Iceland,Ireland,Italy,Latvia,Lithuania,Luxembourg,Malta,Netherlands,Norway,Poland,P ortugal,
6、 Romania,Slovakia,Slovenia,Spain,Sweden,SwitzerlandandUnitedKingdom. EUROPEANCOMMITTEEFORSTANDARDIZATION COMITEUROPENDENORMALISATION EUROPISCHESKOMITEEFRNORMUNG ManagementCentre:ruedeStassart,36B1050Brussels 2007CEN Allrightsofexploitationinanyformandbyanymeansreserved worldwideforCENnationalMembers
7、. Ref.No.CEN/TR15640:2007:E2 Contents Page Foreword3 Introduction .4 1 Scope6 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 health
8、 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 reporting13 8.5 Quality Systems.13 8.6 Design control15 8.7 Risk management16 9 Standards specif
9、ic 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 EU, Austra
10、lia 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 software classif
11、ication.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 risk managem
12、ent 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 Committee CEN/TC 25
13、1 “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 15640:20074 In
14、troduction 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 unsophisticated
15、 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 influen
16、ce 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 patient call an
17、d/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 screening for disease
18、s 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 purpo
19、se. 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 software pro
20、ducts. 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 substantial n
21、umber 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 is often missi
22、ng 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 effects. If for no
23、 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, clinic
24、ians 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 treatme
25、nt 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 prescrib
26、ing 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 evidence gives
27、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 su
28、ch 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; f
29、ailure 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. Failures and defici
30、encies 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 may also have
31、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 cent
32、ral 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
33、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 range of safety
34、 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 application or
35、 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 excluding that which
36、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 present to pati
37、ents 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 standards prod
38、uced) 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 spec
39、ifications 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 controls which might
40、 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 to health so
41、ftware 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 to a medical d
42、evice 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, regional or
43、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 addressed to manuf
44、acturers 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 which are enco
45、mpassed 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 definitions apply.
46、 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 excluding softw
47、are 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 design, manuf
48、acture, 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 necessary for its proper application intended by the manufacturer to be used on human
