1、 Reference number ISO/TR 27809:2007(E) ISO 2007TECHNICAL REPORT ISO/TR 27809 First edition 2007-07-15 Health informatics Measures for ensuring patient safety of health software Informatique de sant Mesures assurant au patient la scurit des logiciels de sant ISO/TR 27809:2007(E) PDF disclaimer This P
2、DF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therei
3、n the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the
4、PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. COPYRIGHT PROTECTED DOCUMEN
5、T ISO 2007 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or ISOs member body in
6、 the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2007 All rights reservedISO/TR 27809:2007(E) ISO 2007 All rights reserved iii Contents Page Forew
7、ord iv Introduction v 1 Scope . 1 2 Terms and definitions. 1 3 Abbreviated terms 3 4 Outline of the issues. 3 5 General position on medical device controls 4 6 The border between health software products and medical devices . 4 7 Classifying health software products. 5 7.1 Options 5 7.2 Conclusions
8、5 8 Options for control measures for health software products . 5 8.1 Overview 5 8.2 Labelling and documentation 6 8.3 Clinical evidence. 7 8.4 Incident reporting . 7 8.5 Quality systems 8 8.6 Design control. 10 8.7 Risk management . 11 9 Standards relevant to risks of a particular nature. 11 9.1 Ge
9、neral. 11 9.2 Conclusions 11 10 Observation on safety and risks in the user domain 12 10.1 General. 12 10.2 Conclusions 12 11 Taxonomies . 12 11.1 General. 12 11.2 Conclusions 12 12 Summary of conclusions . 12 Annex A (informative) Position regarding medical devices in different countries 14 Annex B
10、 (informative) Analysis of classification procedures . 18 Annex C (informative) Risk management 24 Bibliography . 35 ISO/TR 27809:2007(E) iv ISO 2007 All rights reservedForeword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO membe
11、r bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmenta
12、l and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directi
13、ves, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies
14、 casting a vote. In exceptional circumstances, when a technical committee has collected data of a different kind from that which is normally published as an International Standard (“state of the art”, for example), it may decide by a simple majority vote of its participating members to publish a Tec
15、hnical Report. A Technical Report is entirely informative in nature and does not have to be reviewed until the data it provides are considered to be no longer valid or useful. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO sh
16、all not be held responsible for identifying any or all such patent rights. ISO/TR 27809 was prepared by Technical Committee ISO/TC 215, Health informatics. ISO/TR 27809:2007(E) ISO 2007 All rights reserved v Introduction The threat to patient safety In the past, health-related software was primarily
17、 applied to relatively non-critical administrative functions where the potential for harm to the patient, as distinct from disruption to the organization, was low. Clinical systems were generally unsophisticated often with a large administrative, rather than clinical, content and little in the way o
18、f 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. This has changed and will continue to change substantial
19、ly. 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” p
20、atients. 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 diseases is increasing significantly and it is in such applications involving large numbe
21、rs of subjects that there will be heavy reliance on software, administratively and clinically, to detect normals and abnormals and to “call” or “process” those deemed to be at-risk. Such software needs to be safe for its purpose. Chief Executives and others responsible for healthcare organizations n
22、eed to recognise that: health software products have the potential to harm patients; this potential is growing as the complexity of implementations grows; healthcare organizations are increasingly reliant on health software products. This means that, unless these risks are recognised and controlled,
23、 harm to patients may result with consequent damage to the reputation of a health organization and substantial financial consequences in terms of legal damages. There is mounting concern around the world about the substantial number of avoidable clinical incidents that have an adverse effect on pati
24、ents of which a significant proportion result in avoidable death or serious disability. See Bibliography 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 missing or incomplete information or simply ignorance, e.g.
25、 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 other reasons and there are others this will lead, a
26、nd is leading, to increasing utilization 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
27、 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
28、 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 numb
29、er and costs of clinical investigative tests is another. ISO/TR 27809:2007(E) vi ISO 2007 All rights reservedSystems such as those for decision support have considerable potential for reducing clinical errors and improving clinical practice. For example, a large body of published evidence gives test
30、imony 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
31、 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; fai
32、lure 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 deficien
33、cies 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 organization including financial loss. Harm to a patient may also have a
34、consequent impact on the organization, such as financial loss resulting from litigation. Whereas these adverse organizational impacts will be significant to an organization, they are not the subject of this document unless they result in harm to a patient. For example, the failure of a hospitals cen
35、tral 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 that is the
36、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. These measures are often backed by a range of safety-related standards from a number of sources, both national and inter
37、national, including the International Organization for Standardization (ISO), the International Electrotechnical Committee (IEC) and the European Committee for Standardization (CEN). Some software such as that necessary for the proper application or functioning of a medical device is often encompass
38、ed 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 is encompassed by medical device controls. A neces
39、sary precursor for determining and implementing appropriate design and production controls to minimize 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
40、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 produced) then it will need to be recognised that the
41、 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 desig
42、n and production, group products into 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 be exerted on the design, development, production
43、, 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 software products. TECHNICAL REPORT ISO/TR 27809:20
44、07(E) ISO 2007 All rights reserved 1 Health informatics Measures for ensuring patient safety of health software 1 Scope This Technical Report 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
45、 the proper application of a medical device or an accessory to a medical device or a medical device in its own right. This Technical Report 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 o
46、ther formal or informal or voluntary manner whether national, regional or local. However, it is not the purpose of this Technical Report to recommend whether or not health software products should be regulated. This Technical Report applies to any health software product whether or not it is placed
47、on the market and whether or not it is for sale or free of charge. It is addressed 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. Th
48、is Technical Report acknowledges that, on the boundary, there are health software products which 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 n
49、ot. 2 Terms and definitions For the purposes of this document, the following terms and definitions apply. 2.1 harm death, physical injury and/or damage to health or well being of a patient 2.2 hazard potential source of harm ISO/IEC Guide 51:1999 72.3 health software product software product for use in the health sector for health related purposes but excluding software which is: necessary for the proper application of a medical device or an accessory to a medical device or a medical device in its own r
