1、 g49g50g3g38g50g51g60g44g49g42g3g58g44g55g43g50g56g55g3g37g54g44g3g51g40g53g48g44g54g54g44g50g49g3g40g59g38g40g51g55g3g36g54g3g51g40g53g48g44g55g55g40g39g3g37g60g3g38g50g51g60g53g44g42g43g55g3g47g36g58softwareICS 35.240.80Health informatics Classification of safety risks from health DRAFT FOR DEVELO
2、PMENTDD ISO/TS 25238:2007DD ISO/TS 25238:2007This Draft for Development was published under the authority of the Standards Policy and Strategy Committee on 31 August 2007 BSI 2007ISBN 978 0 580 56906 7to withdraw it. Comments should be sent to the Secretary of the responsible BSI Technical Committee
3、 at British Standards House, 389 Chiswick High Road, London W4 4AL.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 secretary.This publication does not purpo
4、rt to include all the necessary provisions of a contract. Users are responsible for its correct application.Amendments issued since publicationAmd. No. Date Commentsresponsible for its conversion to an international standard. A review of this publication will be initiated not later than 3 years afte
5、r its publication by the international organization so that a decision can be taken on its status. 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 respon
6、sible BSI Committee will decide whether to support the conversion into an international Standard, to extend the life of the Technical Specification or National forewordThis Draft for Development is the UK implementation of ISO/TS 25238:2007.This publication is not to be regarded as a British Standar
7、d.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 can be obtained.Comments arising from the use of this Draft for Development are req
8、uested so that UK experience can be reported to the international organization Reference numberISO/TS 25238:2007(E)TECHNICAL SPECIFICATION ISO/TS25238First edition2007-06-15Health informatics Classification of safety risks from health software Informatique de sant Classification des risques de scuri
9、t partir dun logiciel de sant DD ISO/TS 25238:2007ii iiiContents Page Foreword iv Introduction v 1 Scope . 1 2 Terms and definitions. 1 3 Abbreviated terms 2 4 Principles of hazard and risk analysis 2 5 Assignment of a risk class to a health software product. 4 5.1 Introduction . 4 5.2 Assignment to
10、 consequence categories4 5.3 Assignment of likelihood to consequences 5 5.4 Risk classes 7 5.5 Assignment of risk class to a health software product 7 5.6 Process of iteration 7 6 The analytical process . 7 6.1 General. 7 6.2 Involvement of stakeholders . 8 6.3 Understanding the system and user envi
11、ronment 8 6.4 Consequence analysis . 8 6.5 Likelihood analysis. 9 6.6 Iteration 10 6.7 Reviews 10 6.8 Documentation 10 6.9 Incident library 11 7 Examples of assignment of risk classes to products. 11 8 Relationship of risk classes to design and control of production of products . 11 Annex A (informa
12、tive) Health software products and medical devices: rationale 12 Annex B (informative) Examples of assignment of Risk Classes . 15 Annex C (informative) Illustration of the nature of the relationship between risk classes and potential controls for risk management . 20 Bibliography . 23 DD ISO/TS 252
13、38:2007iv Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for
14、 which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on a
15、ll matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are
16、 circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. In other circumstances, particularly when there is an urgent market requirement for such documents, a technical committee may decide to publis
17、h other types of normative document: an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in an ISO working group and is accepted for publication if it is approved by more than 50 % of the members of the parent committee casting a vote; an ISO Technical
18、 Specification (ISO/TS) represents an agreement between the members of a technical committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting a vote. An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for
19、 a further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an International Standard or be withdrawn. Attention is drawn to the possibilit
20、y that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO/TS 25238 was prepared by Technical Committee ISO/TC 215, Health informatics. DD ISO/TS 25238:2007vIntroduction In the past, health-re
21、lated software was primarily 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 and often with a large administrative (rather than clinical)
22、 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 influence on which to rely routinely. That has changed and wil
23、l 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 and/or recall where software malfunctions have resulted
24、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 public has been severely dented. The scope for screening for diseases is increasing significantly and it is in suc
25、h applications involving large numbers of subjects that there will be heavy reliance, administratively and clinically, on software to detect normal and abnormal elements and to “call” or “process” those deemed to be at-risk. Such software needs to be safe for its purpose. There is mounting concern a
26、round the world about the substantial number of avoidable clinical incidents having an adverse effect on patients, and of which a significant proportion result in avoidable death or serious disability (see References 1, 2, 3, 4, 5 and 6). A number of such avoidable incidents involve poor or “wrong”
27、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 information systems such as decision support, protocols, guidelin
28、es and pathways could markedly reduce such adverse effects. If only for this reason (quite apart from others, which do exist), this is leading to increasing utilization of decision support and disease management systems, which will inevitably increase in sophistication and complexity. It can also be
29、 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 standard support facilities may be criticized on legal grou
30、nds. 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 serious consequences. Economic pressures are also l
31、eading to more decision support systems. The area of generic and/or economic prescribing is the most obvious, but economy in number and the cost of clinical investigative tests is another. Systems such as for decision support have considerable potential for reducing clinical errors and improving cli
32、nical 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 of course result from unquestioning and/or no
33、n-professional use, even though manufacturers can mitigate such circumstances through, for example, instructions for use, training and on-screen presentation techniques, guidance or instruction. The potential for harm may lie equally in the system design, in such areas as: poor evidence base for des
34、ign; 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; failure to update in line with current knowledge. DD ISO/TS 25238:2007vi Some of
35、 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. This increased spending can be expected to
36、 attract new manufacturers, 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 in telemedicine. Many of the health
37、 software 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 application to new fields is likely to b
38、e associated with risks. Whereas we are many years away from paperless, film-less hospitals, 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 not only bring administrative chaos, but
39、can also significantly affect patient care. To sum up, 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 applications increases and the reliance
40、 on ICT grows. There is evidence of increasing concern amongst professionals and the public as incidents of malfunctions of software, leading to adverse health consequences, raise public consciousness. Consequently, a number of health organizations are increasingly focusing on “controls assurance” s
41、tandards, 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 application of health software products. F
42、ailures and deficiencies in health software products can, of course, have adverse impacts other than by 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
43、patient may also have a 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 Technical Specification unless they result in harm to a patient. For
44、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 Technical Specification unless it has the potential to cause harm to a patient (which is possible
45、). It is the potential harm to the patient that is the subject of this Technical Specification. The safety of medicines and of medical devices is assured in many countries through a variety of legal and administrative measures, e.g. in the European Union it is subject to several EU directives (see R
46、eferences 7, 8 and 9). These measures are often backed by a range of safety related standards from a number of sources, both national and international, including the International Organization for Standardization (ISO), the European Committee for Standardization (CEN) and the International Electrot
47、echnical Commission (IEC). Software necessary for the proper application or functioning of a medical device is often encompassed by these legislative controls. However, other software applied to health is not usually covered in this way. This Technical Specification is concerned with software applie
48、d to health excluding that which is necessary for the proper application or functioning of a medical device. A necessary precursor for determining and implementing appropriate design and production controls, in order to minimize risks to patients from product malfunction or inadequate performance, i
49、s a clear understanding of the hazards that 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 manufacturers of health software products on design and production control (and corresponding standards produced), then it will need to be recognized that the controls necessary for products presenting low risks will not be the same as for those presenting hig
