- Email: [email protected]
A computerised guideline for pressure ulcer prevention
International Journal of Medical Informatics 58 – 59 (2000) 207 – 217
www.elsevier.com/locate/ijmedinf
A computerised guideline for pressure ulcer prevention S. Quaglini a,*, M. Grandi b, P. Baiardi b, M.C. Mazzoleni b, C. Fassino a, G. Franchi b, S. Melino b b
a Dipartimento di Informatica e Sistemistica, Uni6ersita` di Pa6ia, Via Ferrata 1, I-27100 Pa6ia, Italy IRCCS Fondazione ‘S. Maugeri’, Clinica del La6oro e della Riabilitazione, Via Ferrata 8, I-27100 Pa6ia, Italy
Received 29 December 1999; accepted 13 April 2000
Abstract This paper illustrates the implementation of a computerised guideline for pressure ulcer prevention. In particular, it describes the aspects related to the site-specification of a guideline delivered by the Agency for Health Care Policy Research (AHCPR), to its integration with the electronic patient record, and to its implementation within the clinical routine. The primary goal of the system is both to facilitate nurses assessing the risk of ulcer development, and to manage patients at risk by producing daily prevention work-plans. Concerning this functionality, particular attention has been paid to manage nurse’s non-compliance with the guideline suggestions and to collect data for evaluating the guideline impact. Moreover, since it is well known that nurses are often over-loaded, the human computer interaction has been studied in such a way to optimise the time spent for data input. An additional functionality of the system is the novice nurses’ education — they can browse a graphical representation of the guideline, asking details about the different tasks, and they can simulate patients to obtain real-time advice. The educational tool is written in Java and it is based on a representation of the guideline as a relational database. A preliminary evaluation of the system has been performed and the results are presented on the management of about 40 patients. © 2000 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Nursing informatics; Practice guideline; Guideline adherence; Decision support systems; Decubitus ulcer; Prevention
1. Introduction Despite the great emphasis that the medical community put on clinical practice guidelines (GLs) during the previous years [1,2], several problems are associated with GLs * Corresponding author. Tel.: +39-382-505679; fax: + 39382-505373. E-mail address: [email protected] (S. Quaglini).
diffusion and implementation in the clinical setting. ‘Official’ GLs, delivered by health care authorities (health agencies, medical associations, health policy makers, etc.), may show two opposite faults, if they are very general, their interpretation is difficult and ambiguous; while if they are very specific, they may not fit the organisational constraints of the different environments where they must be implemented [3]. In addition,
1386-5056/00/$ - see front matter © 2000 Elsevier Science Ireland Ltd. All rights reserved. PII: S 1 3 8 6 - 5 0 5 6 ( 0 0 ) 0 0 0 8 8 - 5
208
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
and independently from organisational reasons, health care operators often do not fully comply with GLs, simply because it is difficult to impose behavioural changes. If a local standard already exists, physicians offer resistance to change, and this is reasonable, especially if they do not perceive an advantage. To this concern, it must be recognised that often physicians are not provided with instruments for evaluating the benefits of a GL introduction, thus lacking the opportunity to be convinced by the evidence of improved outcomes. Using information technology for implementing GLs helps overcoming these difficulties. As a matter of fact: formalisms for computerised GL representation have been developed [4–6]. The experts developing GLs should use them, because often the prose is ambiguous and the ‘textual’ GL is not complete. On the contrary, a computerised representation requires the GL logical correctness; compliance may be improved by integrating GL with the electronic patient record (EPR) [7]; to this concern, it must be stressed that for performing sound statistics on the GL impact, it is necessary to verify which tasks have been completed and the motivations for the possible noncompliance; different inference engines (i.e. mechanisms for advice production, given the specific patient data) may be applied to the same GL, in order to achieve a user interaction that is tailored to the specific clinical setting. As for any other information tool or decision support system, it is very important that the GL does not badly interfere with the clinical routine and a user needs analysis, as well as a workflow analysis of the clinical environment must precede the GL implementation;
computerised representation, following the most recent medical informatics community suggestions [8], embeds knowledge about the goal of the guideline and, when it is the case, about the goal of particular tasks composing the guideline itself. Goalrelated outcomes are then stored in the EPR, in such a way as to measure the GL benefit. In this work, we focussed our attention on the GL/user interaction, and we distinguished three key interaction aspects that, in general, may be tackled differently, according to the specific user needs. 1. The ad6ice production: it can be ‘explicit’, i.e. as soon as a task is performed, the GL suggests the next steps. This can be a suitable modality for beginners. On the contrary, it can be ‘silent’, i.e. the user is advised only when non-compliance is detected. This can be worthwhile for expert users. 2. The approach to non-compliance: a GL could proceed to the next task(s) only if the user fully complied with the GL for what concerns the previous tasks. This should be the case for particularly mandatory procedures; another possibility is that the GL proceeds also in case of non-compliance, but only if the user provides a justification for that; finally the GL could proceed in any case, just recording the non-compliance. 3. The inter6ention time: a GL could react in real time to the users actions, and suggest, in real time as well, the next action(s). This implies for the user the possibility of interacting very frequently with the computer and thus a very efficient and distributed information system is necessary; on the contrary, the user could access the GL only in specific time slices. These three aspects concern the real-world implementation of the GL, but another im-
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
portant issue of this paper is the GL use for educational purposes, where the focus is on aspects such as explanations and literature pointers. In the following sections, we illustrate the implementation of a GL for the prevention of pressure ulcers, and motivate our design choices according to the framework illustrated above.
2. The clinical problem Pressure ulcers are defined as any lesion caused by unrelieved pressure that results in damage to the underlying tissue. They are serious problems that can lead to pain, a longer hospital stay, a slow recovery, and additional pharmacological treatment, all factors affecting both the quality of life and economic costs. Elderly people and patients with multiple ulcers may die from ulcer-related infections. Medical community considers the absence of pressure ulcers in a hospital ward as an index of the health care delivery quality. Pressure ulcer prevalence surveys point out the following percentages: in US [9] a figure of 9.2% refers to 1989, and an increase to 11.1% is shown for 1993. In Italy in 1994, a prevalence of 13.2% was computed on a sample of 2144 hospitalised patients belonging to general medicine, surgery, intensive care, traumatology and rehabilitation units. Taking into account the population at risk, prevalence increases, ranging from 18 to 47% depending on the clinical unit [10]. Prevention plays an essential role: risk evaluation and a preventive care plan are needed from the first days of hospitalisation. In fact, about 50% of pressure ulcers occurring during the stay appear within the first week. Nurses, who are traditionally sensitive to this problem, often lack a precise and standardised procedure to approach it. The
209
Agency for the Health Care Policy Research (AHCPR) [11] delivered a GL for the pressure ulcers prevention that has been the starting point for our study, as well as for past implementations [12,13]. The AHCPR document outlines the following goals: (1) identifying at-risk individuals who need preventive intervention and the specific factors placing them at risk; (2) maintaining and improving tissue tolerance to pressure in order to prevent injury; (3) protecting against the adverse effects of external mechanical forces (pressure, friction, and shear); and (4) reducing the incidence of pressure ulcers through educational programs.
3. The site-specification of the GL The AHCPR recommendations were used as a basis for the local guideline development effort. The GL was tailored according to the proposal of both a national organisation, the Italian Nurse Association for the Study of Skin Lesions (AISLEC), and our hospital physicians and nurses [14]. Variations were necessary in order to make the GL usable on all the hospitalised patients with efforts and resources maintained within acceptable limits. GL specification has also been done considering the already existing prevention protocol, when this was compatible with the AHCPR indications. These variations are detailed in Table 1, and they concern both the risk assessment and the prevention plan.
4. The GL formal representation Fig. 1 shows the site-specified GL, represented through the graphical editor GUIDE, written in Java and extensively described in [5]. It allows drawing GLs at different hierarchical levels. For example, Fig. 1a illustrates
210
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
Fig. 1. The site-specified guideline for pressure ulcer prevention, represented through the graphical editor GUIDE. A shadowed rectangle indicates a composite task, i.e. a task that may be expanded into another page. For example the task ‘(management of) patient at risk’, in part (a) of the figure, is detailed as shown in the pop-up page (b).
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
the main page, where the task ‘(management of) patient at risk’ is composite, and Fig. 1b illustrates the decomposition of that task. Very briefly, we report here the distinguishing characteristics of GUIDE: it allows drawing a guideline by drag-anddrop the icons representing the GL semantics (see left side of Fig. 1a); it is connected to a terminology server, drawn from the SNOMED and Mesh thesaurus [15], in order to maintain a common terminology among tasks shared by several GLs, possibly running in the same environment; it allows calling probabilistic decision models for performing preference-based or economic evaluation analyses — this is useful when a GL does not exactly suggest an action, but lets the user choose one among a set of actions; it may be connected to the EPR.
4.1. Using GUIDE as an educational tool GUIDE produces an internal representation of the GL in terms of relational tables
211
and it embeds an inference engine that generates advice according to the stored patient data. It is very useful for educational purposes because, in addition to the GL browsing facilities (the user may ‘navigate’ throughout the GL pages and inspect each task), the user can simulate patients, inserting data into the EPR, and obtaining suggestions in real time. Graphical facilities have been designed. Different colours indicate different task states (completed, in execution, next to execute). Different bullets indicate the strength of recommendation for that task: red for a strongly recommended task, yellow for a recommended task, and green for a suggested task. The strength of recommendation depends on the level of scientific evidence about the effectiveness of the task itself. The AHCPR used the following criteria for the three levels, (A) there is good research-based evidence to support the recommendation; (B) there is fair researchbased evidence to support the recommendation; and (C) the recommendation is based on expert opinion and panel consensus.
Table 1 Differences between the AHCPR guideline and the site-implemented guideline Risk assessment
Action to be taken
1. Age over 65 and previous ulcers were locally considered sufficient to alert nurses about possible risk of ulcer development (absent in the AHCPR GL). Nurses are then allowed to confirm or deny the risk 2. Nutritional deficit is inspected through different variables — total lymphocyte counts over 1800 and patient weight under 80% of ideal were substituted by haemoglobin less than 11 g/dl and Body Mass Index less than 19 kg/m2. Moreover, some predisposing pathologies together with the presence of an existing pressure ulcer are included in the evaluation of risk 1. The frequent (every 2 h) repositioning of the patient proposed by AHCPR with strength of evidence = B (high) was not accepted due to excessive induced overburden for nurses. ‘‘Every 4 h’’ was considered suitable 2. Skin evaluation every 2 days, instead of once a day 3. Detailed indication (drug names) is provided about medications to be used in order to reduce friction injuries
212
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
5. The functional architecture
Fig. 2. Clicking on a task, it is possible to obtain an explanation concerning the suggestion given by the task itself. In the figure, the motivation for measuring the Norton scale score is provided. The shown sentence has been retrieved from the AHCPR guideline text.
Fig. 3. The system architecture. At the start of their shift, nurses are provided with a printed prevention work-plan, for patients at risk, that they will use all daylong. At the end of the shift, data about administered treatments are inserted into the electronic patient record. The guideline inference engine takes into account both this information and data entered by other users, and elaborates the work-plan for the next day.
Pointers to literature may be associated to bullets as a GL task documentation. Fig. 2 illustrates an explanation obtained by clicking on the ‘Norton scale’ task.
As mentioned above, the GL implementation took into account possible bad interference with daily work. In the ward chosen as the pilot for our study, namely a general medicine ward of the hospital, an information system has been present for many years. We decided to use such a system as the data source for the GL inference engine. This allowed keeping the same user interface, so avoiding additional workload for nurse training. Thus, a preliminary analysis about data necessary for the GL implementation was performed in order to highlight which information was already present, more or less explicitly, in the actual EPR, and which additional information was needed. Once the EPR was modified according to this analysis, the connection with the GL inference engine was developed. Fig. 3 shows the system functionality. At the beginning of their shift, nurses ask the system for printing the work-plan of the day. The work-plan is produced by the GL inference engine, according to the GL rules, fired with data stored in the EPR. At the end of their shift, nurses store data about the executed work-plan. Of course, nurses adopting the GL were not the only users accessing the EPR. Physicians and laboratory technicians store additional information. The difference among users is that nurses must fill the EPR, because the GL would not produce the next day work-plan if the previous one had not been discharged. Storing the non-compliances is mandatory too, in order to continue with further work-plans: if some of the suggested actions had not been performed, nurses must give a justification, and the same actions will be suggested again the day after. A scratch of a printed work-plan is shown in Table 2 (bold items are filled by nurses).
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
This architecture requires the interaction with the system at specific time slices, namely at the beginning and at the end of the daily work. All day long, nurses annotate information on the paper work-plan. This has been considered as the optimal system/user interaction in our environment, because a real time storing of data about actions performed on the patient is impossible for logistic and technological reasons (lack of wireless datainput devices and low workstation number).
Moreover, there is no real need of a stricter interaction with the system, having most of the tasks a daily frequency.
6. The guideline integration into the EPR Fig. 4 shows the ulcer risk assessment form. This task is mandatory for every patient admitted to the ward. Patient weight and height, as well as information about the
Table 2 An example of the work-plan produced by the guideline inference engine Nurse work-plan — Friday, 17 December, 1999 Room Patient Tasks to be performed Ulcer site 21
22 24
Verdi Rosina Nerino Vittorio Celestino Albina
213
Task done
Ulcer evaluation Elbow Anti-decubitus matress Duoderm cream Shoulder Incontinence pad
Yes No Yes Yes
Skin examination
No
Notes/motivation
No more matress available
Patient transferred for examinations
Fig. 4. The form for the assessment of the patient risk of developing pressure ulcers.
214
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
Fig. 5. The form for evaluating the ulcer development and response to treatment. The percentage of the ulcer area reduction is calculated by the system.
presence of diseases that increase the ulcer risk are automatically retrieved from the EPR, because this form is filled up after the objective examination and patient history have been performed. The nurses fill in the remaining fields, namely the Norton scale attributes and the feeding type. The GL imposes the compilation of this form at predefined time intervals. As a matter of fact, to each item stored in the EPR, a time stamp is associated, that is compared with the persistence time of that item, stored in the GL. The persistence of a parameter value is defined as the maximum time interval for which the value itself may be considered valid. For example, the body temperature has a low persistence time, because it may change rapidly, while the weight has a longer persistence, because a sensible variation may occur within days, instead of hours. The GL will require a new input for a parameter, whenever the persistence time of the last measurement is over.
In addition to risk assessment, the same form is used for evaluating the ulcer evolution (see the button ‘Ulcer’ in the menu). As a matter of fact, despite the implemented GL aims at pre6enting ulcers, the user interface is flexible enough to access the ulcer treatment data. This is necessary because a patient may have an ulcer somewhere and may need prevention in another body part so that the nurse needs easy access to the EPR for the two problems. Fig. 5 shows the ulcer evaluation form. Fig. 6 illustrates the form that nurses fill at the end of their shift. It was an electronic copy of the paper work-plan that they used during the day (see Table 2). The pop-up window illustrates the input of the motivation for the non-compliance.
7. Results We have designed and implemented a decision support system for pressure ulcer pre-
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
215
Fig. 6. Data about the work-plan that has been followed during the day must be entered into the EPR at the end of the shift. If some actions have not been performed, a justification is necessary (pop-up window).
vention, integrating it into the existing electronic patient record of a general medicine ward. Data are now being collected with two aims, i.e. to evaluate the user satisfaction and to evaluate the benefits of the GL introduction on patient outcomes. Data about 40 patients are actually available and despite the small sample size, a preliminary evaluation has been performed on the first issue. Results are summarised in Table 3, where pros and cons have been highlighted. Users appreciated the documentation generated by the GL, which facilitated handing on duties to the next shift nurses. Detailed storing of actions taken was useful at the patient discharge, to plan the future home care, and also was a means for assessing the nurse workload required by the prevention programme. As regards the educational tool, it had been judged as rich and easy to use. On the other hand, nurses complained about a certain rigidity of the GL in assess-
ing the patient risk, and in continuously asking for task completion. Finally, they required minimising the time spent in data input by generating some default values. These complaints will be used as a feedback for improving the GL implementation.
Table 3 Results on the user evaluation of the GL after 1 month of testing Acknowledged advantages
Required modifications
Improved planning Detailed documentation Workload assessment Education
More flexibility on the risk assessment More flexibility in setting the action timing More facilities for quick data input
216
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
8. Discussion and future development In the ward chosen as pilot site, nurses were greatly interested into pressure ulcers and had already begun to both introduce an ulcer prevention plan and organise training sessions for personnel belonging to other wards. Moreover, reluctance to the use of computers had been overcome many years ago, at the time when the HIS was installed. This could represent the optimal condition for a more systematic approach to the problem based on decision support system. Nevertheless, some problems arose, in particular as regards the care delivery tool. Once an acceptable site-specified GL had been identified through many meetings, users offered a certain resistance to apply the GL (as regards risk assessment) to every patient admitted. This would have entailed an overburden in terms of data input. On the other hand, one of the aims of a GL was to ensure uniformity of care, and, not to disregard, only the systematic patient evaluation allowed calculating sound statistical ratios (i.e. prevalence and incidence of patients at risk and ulcers). Integration with the HIS, together with the adopted policy for the management of noncompliance, appeared to be a determinant factor to prevent odd user behaviours. To balance efforts and gains, production of reports detailing all the actions undertaken according to the prevention plan and the medications had been provided to nurses for each patient discharge as a consequence of the task completion data storage. No data are available yet in order to evaluate the benefits of the GL on patient outcomes, because the system has been installed for a too short time. Data will be collected with the aim of making comparisons with previous ulcer incidence in the same ward and with other wards where the GL has not been adopted. Data about non-compliance will be
used for discovering some organisational bottlenecks that impair the full GL implementation.
Acknowledgements This work is partially funded by the European Commission through the project Patient workflow management system (PatMan) within the Health Care Telematics Applications Programme, Project HC 4017.
References [1] M.J. Field, K.N. Lohr (Eds.), Institute of Medicine Guidelines for Clinical Practice: from Development to Use, National Academy Press, Washington, DC, 1992. [2] C. Gordon, J.P. Christensen (Eds.), Health Telematics for Clinical Guidelines and Protocols, IOS Press, 1995. [3] D.B. Fridsma, J.H. Gennari, M.A. Musen, Making generic guidelines site specific, in: J.J. Cimino (Ed.), Proceedings of the 1996 AMIA Annual Fall Symposium, Philadelphia, Hanley and Belfus, Philadelphia, 1996, pp. 597 – 601, J. Am. Med. Inform. Assoc. [4] J. Fox, N. Johns, A. Rahmanzadeh, Disseminating medical knowledge: the PROforma approach, Artif. Intell. Med. 14 (1998) 157 – 181. [5] S. Quaglini, L. Dazzi, L. Gatti, M. Stefanelli, C. Fassino, C. Tondini, Supporting tools for guideline development and dissemination, Artif. Intell. Med. 14 (1998) 119 – 137. [6] S.W. Tu, M.A. Musen, The EON model of intervention protocols and guidelines, in: J.J. Cimino (Ed.), Proceedings of the 1996 Am. Med. Inform. Assoc. Annual Fall Symposium, Hanley and Belfus, Philadelphia, 1996, pp. 587 – 591, J. Am. Med. Inform. Assoc. [7] D.F. Lobach, W.E. Hammond, Development and evaluation of a computer-assisted management protocol (CAMP): improved compliance with care guidelines for diabetes mellitus, in: Proceedings of the Symposium on Computer Applications in Medical Care, 1994, pp.787 – 791.
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
[8] L. Ohno-Machado, J.H. Gennari, S.H. Murphy, N.L. Jain, S.W. Tu, D.E. Oliver, E. Pattison-Gordon, R.A. Greenes, E.H. Shortliffe, G.O. Barnett, The guideline interchange format: a model for representing guidelines, J. Am. Med. Inform. Assoc. 5 (1998) 357–372. [9] M. Meehan, National pressure ulcer prevalence survey, Adv.Wound Care 7 (1994) 3. [10] P. Di Giulio, La prevalenza delle lesioni da decubito nei pazienti ospedalizzati, Rivista dell’infermiere 4(1) (1985) 20–34. [11] U.S. Department of Health and Human Services, Pressure ulcers in adults: prediction and prevention (AHCPR 92-0047), Agency for Health Care Policy and Research, Rockville, MD, May 1992. [12] D. Willson, C. Ashton, N. Wingate, C. Goff, S. Horn, M. Davies, R. Buxton, Computerised sup-
217
port of pressure ulcer prevention and treatment protocols, J. Am. Med. Inform. Assoc., Symposium (1995), 646 – 650. [13] R.D. Zielstorff, G.O. Barnett, J.B. Fitzmaurice, G. Estey, G. Hamilton, A. Vickery, E. Welebob, C. Shahzad, A decision support system for prevention and treatment of pressure ulcers based on AHCPR guidelines, J. Am. Med. Inform. Assoc., Symposium (1996) 562 – 566. [14] AISLEC, Profilassi delle lesioni da decubito e cambio posturale: ricerca multicentrica, linee guida, ANIN-NEU, 1995. [15] B.L. Humphreys, D.A.B. Lindberg, H.M. Schoolman, G.O. Barnett, The unified medical language system: an informatics research collaboration, J. Am. Med. Inform. Assoc. 5 (1998) 1 – 11.
www.elsevier.com/locate/ijmedinf
A computerised guideline for pressure ulcer prevention S. Quaglini a,*, M. Grandi b, P. Baiardi b, M.C. Mazzoleni b, C. Fassino a, G. Franchi b, S. Melino b b
a Dipartimento di Informatica e Sistemistica, Uni6ersita` di Pa6ia, Via Ferrata 1, I-27100 Pa6ia, Italy IRCCS Fondazione ‘S. Maugeri’, Clinica del La6oro e della Riabilitazione, Via Ferrata 8, I-27100 Pa6ia, Italy
Received 29 December 1999; accepted 13 April 2000
Abstract This paper illustrates the implementation of a computerised guideline for pressure ulcer prevention. In particular, it describes the aspects related to the site-specification of a guideline delivered by the Agency for Health Care Policy Research (AHCPR), to its integration with the electronic patient record, and to its implementation within the clinical routine. The primary goal of the system is both to facilitate nurses assessing the risk of ulcer development, and to manage patients at risk by producing daily prevention work-plans. Concerning this functionality, particular attention has been paid to manage nurse’s non-compliance with the guideline suggestions and to collect data for evaluating the guideline impact. Moreover, since it is well known that nurses are often over-loaded, the human computer interaction has been studied in such a way to optimise the time spent for data input. An additional functionality of the system is the novice nurses’ education — they can browse a graphical representation of the guideline, asking details about the different tasks, and they can simulate patients to obtain real-time advice. The educational tool is written in Java and it is based on a representation of the guideline as a relational database. A preliminary evaluation of the system has been performed and the results are presented on the management of about 40 patients. © 2000 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Nursing informatics; Practice guideline; Guideline adherence; Decision support systems; Decubitus ulcer; Prevention
1. Introduction Despite the great emphasis that the medical community put on clinical practice guidelines (GLs) during the previous years [1,2], several problems are associated with GLs * Corresponding author. Tel.: +39-382-505679; fax: + 39382-505373. E-mail address: [email protected] (S. Quaglini).
diffusion and implementation in the clinical setting. ‘Official’ GLs, delivered by health care authorities (health agencies, medical associations, health policy makers, etc.), may show two opposite faults, if they are very general, their interpretation is difficult and ambiguous; while if they are very specific, they may not fit the organisational constraints of the different environments where they must be implemented [3]. In addition,
1386-5056/00/$ - see front matter © 2000 Elsevier Science Ireland Ltd. All rights reserved. PII: S 1 3 8 6 - 5 0 5 6 ( 0 0 ) 0 0 0 8 8 - 5
208
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
and independently from organisational reasons, health care operators often do not fully comply with GLs, simply because it is difficult to impose behavioural changes. If a local standard already exists, physicians offer resistance to change, and this is reasonable, especially if they do not perceive an advantage. To this concern, it must be recognised that often physicians are not provided with instruments for evaluating the benefits of a GL introduction, thus lacking the opportunity to be convinced by the evidence of improved outcomes. Using information technology for implementing GLs helps overcoming these difficulties. As a matter of fact: formalisms for computerised GL representation have been developed [4–6]. The experts developing GLs should use them, because often the prose is ambiguous and the ‘textual’ GL is not complete. On the contrary, a computerised representation requires the GL logical correctness; compliance may be improved by integrating GL with the electronic patient record (EPR) [7]; to this concern, it must be stressed that for performing sound statistics on the GL impact, it is necessary to verify which tasks have been completed and the motivations for the possible noncompliance; different inference engines (i.e. mechanisms for advice production, given the specific patient data) may be applied to the same GL, in order to achieve a user interaction that is tailored to the specific clinical setting. As for any other information tool or decision support system, it is very important that the GL does not badly interfere with the clinical routine and a user needs analysis, as well as a workflow analysis of the clinical environment must precede the GL implementation;
computerised representation, following the most recent medical informatics community suggestions [8], embeds knowledge about the goal of the guideline and, when it is the case, about the goal of particular tasks composing the guideline itself. Goalrelated outcomes are then stored in the EPR, in such a way as to measure the GL benefit. In this work, we focussed our attention on the GL/user interaction, and we distinguished three key interaction aspects that, in general, may be tackled differently, according to the specific user needs. 1. The ad6ice production: it can be ‘explicit’, i.e. as soon as a task is performed, the GL suggests the next steps. This can be a suitable modality for beginners. On the contrary, it can be ‘silent’, i.e. the user is advised only when non-compliance is detected. This can be worthwhile for expert users. 2. The approach to non-compliance: a GL could proceed to the next task(s) only if the user fully complied with the GL for what concerns the previous tasks. This should be the case for particularly mandatory procedures; another possibility is that the GL proceeds also in case of non-compliance, but only if the user provides a justification for that; finally the GL could proceed in any case, just recording the non-compliance. 3. The inter6ention time: a GL could react in real time to the users actions, and suggest, in real time as well, the next action(s). This implies for the user the possibility of interacting very frequently with the computer and thus a very efficient and distributed information system is necessary; on the contrary, the user could access the GL only in specific time slices. These three aspects concern the real-world implementation of the GL, but another im-
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
portant issue of this paper is the GL use for educational purposes, where the focus is on aspects such as explanations and literature pointers. In the following sections, we illustrate the implementation of a GL for the prevention of pressure ulcers, and motivate our design choices according to the framework illustrated above.
2. The clinical problem Pressure ulcers are defined as any lesion caused by unrelieved pressure that results in damage to the underlying tissue. They are serious problems that can lead to pain, a longer hospital stay, a slow recovery, and additional pharmacological treatment, all factors affecting both the quality of life and economic costs. Elderly people and patients with multiple ulcers may die from ulcer-related infections. Medical community considers the absence of pressure ulcers in a hospital ward as an index of the health care delivery quality. Pressure ulcer prevalence surveys point out the following percentages: in US [9] a figure of 9.2% refers to 1989, and an increase to 11.1% is shown for 1993. In Italy in 1994, a prevalence of 13.2% was computed on a sample of 2144 hospitalised patients belonging to general medicine, surgery, intensive care, traumatology and rehabilitation units. Taking into account the population at risk, prevalence increases, ranging from 18 to 47% depending on the clinical unit [10]. Prevention plays an essential role: risk evaluation and a preventive care plan are needed from the first days of hospitalisation. In fact, about 50% of pressure ulcers occurring during the stay appear within the first week. Nurses, who are traditionally sensitive to this problem, often lack a precise and standardised procedure to approach it. The
209
Agency for the Health Care Policy Research (AHCPR) [11] delivered a GL for the pressure ulcers prevention that has been the starting point for our study, as well as for past implementations [12,13]. The AHCPR document outlines the following goals: (1) identifying at-risk individuals who need preventive intervention and the specific factors placing them at risk; (2) maintaining and improving tissue tolerance to pressure in order to prevent injury; (3) protecting against the adverse effects of external mechanical forces (pressure, friction, and shear); and (4) reducing the incidence of pressure ulcers through educational programs.
3. The site-specification of the GL The AHCPR recommendations were used as a basis for the local guideline development effort. The GL was tailored according to the proposal of both a national organisation, the Italian Nurse Association for the Study of Skin Lesions (AISLEC), and our hospital physicians and nurses [14]. Variations were necessary in order to make the GL usable on all the hospitalised patients with efforts and resources maintained within acceptable limits. GL specification has also been done considering the already existing prevention protocol, when this was compatible with the AHCPR indications. These variations are detailed in Table 1, and they concern both the risk assessment and the prevention plan.
4. The GL formal representation Fig. 1 shows the site-specified GL, represented through the graphical editor GUIDE, written in Java and extensively described in [5]. It allows drawing GLs at different hierarchical levels. For example, Fig. 1a illustrates
210
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
Fig. 1. The site-specified guideline for pressure ulcer prevention, represented through the graphical editor GUIDE. A shadowed rectangle indicates a composite task, i.e. a task that may be expanded into another page. For example the task ‘(management of) patient at risk’, in part (a) of the figure, is detailed as shown in the pop-up page (b).
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
the main page, where the task ‘(management of) patient at risk’ is composite, and Fig. 1b illustrates the decomposition of that task. Very briefly, we report here the distinguishing characteristics of GUIDE: it allows drawing a guideline by drag-anddrop the icons representing the GL semantics (see left side of Fig. 1a); it is connected to a terminology server, drawn from the SNOMED and Mesh thesaurus [15], in order to maintain a common terminology among tasks shared by several GLs, possibly running in the same environment; it allows calling probabilistic decision models for performing preference-based or economic evaluation analyses — this is useful when a GL does not exactly suggest an action, but lets the user choose one among a set of actions; it may be connected to the EPR.
4.1. Using GUIDE as an educational tool GUIDE produces an internal representation of the GL in terms of relational tables
211
and it embeds an inference engine that generates advice according to the stored patient data. It is very useful for educational purposes because, in addition to the GL browsing facilities (the user may ‘navigate’ throughout the GL pages and inspect each task), the user can simulate patients, inserting data into the EPR, and obtaining suggestions in real time. Graphical facilities have been designed. Different colours indicate different task states (completed, in execution, next to execute). Different bullets indicate the strength of recommendation for that task: red for a strongly recommended task, yellow for a recommended task, and green for a suggested task. The strength of recommendation depends on the level of scientific evidence about the effectiveness of the task itself. The AHCPR used the following criteria for the three levels, (A) there is good research-based evidence to support the recommendation; (B) there is fair researchbased evidence to support the recommendation; and (C) the recommendation is based on expert opinion and panel consensus.
Table 1 Differences between the AHCPR guideline and the site-implemented guideline Risk assessment
Action to be taken
1. Age over 65 and previous ulcers were locally considered sufficient to alert nurses about possible risk of ulcer development (absent in the AHCPR GL). Nurses are then allowed to confirm or deny the risk 2. Nutritional deficit is inspected through different variables — total lymphocyte counts over 1800 and patient weight under 80% of ideal were substituted by haemoglobin less than 11 g/dl and Body Mass Index less than 19 kg/m2. Moreover, some predisposing pathologies together with the presence of an existing pressure ulcer are included in the evaluation of risk 1. The frequent (every 2 h) repositioning of the patient proposed by AHCPR with strength of evidence = B (high) was not accepted due to excessive induced overburden for nurses. ‘‘Every 4 h’’ was considered suitable 2. Skin evaluation every 2 days, instead of once a day 3. Detailed indication (drug names) is provided about medications to be used in order to reduce friction injuries
212
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
5. The functional architecture
Fig. 2. Clicking on a task, it is possible to obtain an explanation concerning the suggestion given by the task itself. In the figure, the motivation for measuring the Norton scale score is provided. The shown sentence has been retrieved from the AHCPR guideline text.
Fig. 3. The system architecture. At the start of their shift, nurses are provided with a printed prevention work-plan, for patients at risk, that they will use all daylong. At the end of the shift, data about administered treatments are inserted into the electronic patient record. The guideline inference engine takes into account both this information and data entered by other users, and elaborates the work-plan for the next day.
Pointers to literature may be associated to bullets as a GL task documentation. Fig. 2 illustrates an explanation obtained by clicking on the ‘Norton scale’ task.
As mentioned above, the GL implementation took into account possible bad interference with daily work. In the ward chosen as the pilot for our study, namely a general medicine ward of the hospital, an information system has been present for many years. We decided to use such a system as the data source for the GL inference engine. This allowed keeping the same user interface, so avoiding additional workload for nurse training. Thus, a preliminary analysis about data necessary for the GL implementation was performed in order to highlight which information was already present, more or less explicitly, in the actual EPR, and which additional information was needed. Once the EPR was modified according to this analysis, the connection with the GL inference engine was developed. Fig. 3 shows the system functionality. At the beginning of their shift, nurses ask the system for printing the work-plan of the day. The work-plan is produced by the GL inference engine, according to the GL rules, fired with data stored in the EPR. At the end of their shift, nurses store data about the executed work-plan. Of course, nurses adopting the GL were not the only users accessing the EPR. Physicians and laboratory technicians store additional information. The difference among users is that nurses must fill the EPR, because the GL would not produce the next day work-plan if the previous one had not been discharged. Storing the non-compliances is mandatory too, in order to continue with further work-plans: if some of the suggested actions had not been performed, nurses must give a justification, and the same actions will be suggested again the day after. A scratch of a printed work-plan is shown in Table 2 (bold items are filled by nurses).
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
This architecture requires the interaction with the system at specific time slices, namely at the beginning and at the end of the daily work. All day long, nurses annotate information on the paper work-plan. This has been considered as the optimal system/user interaction in our environment, because a real time storing of data about actions performed on the patient is impossible for logistic and technological reasons (lack of wireless datainput devices and low workstation number).
Moreover, there is no real need of a stricter interaction with the system, having most of the tasks a daily frequency.
6. The guideline integration into the EPR Fig. 4 shows the ulcer risk assessment form. This task is mandatory for every patient admitted to the ward. Patient weight and height, as well as information about the
Table 2 An example of the work-plan produced by the guideline inference engine Nurse work-plan — Friday, 17 December, 1999 Room Patient Tasks to be performed Ulcer site 21
22 24
Verdi Rosina Nerino Vittorio Celestino Albina
213
Task done
Ulcer evaluation Elbow Anti-decubitus matress Duoderm cream Shoulder Incontinence pad
Yes No Yes Yes
Skin examination
No
Notes/motivation
No more matress available
Patient transferred for examinations
Fig. 4. The form for the assessment of the patient risk of developing pressure ulcers.
214
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
Fig. 5. The form for evaluating the ulcer development and response to treatment. The percentage of the ulcer area reduction is calculated by the system.
presence of diseases that increase the ulcer risk are automatically retrieved from the EPR, because this form is filled up after the objective examination and patient history have been performed. The nurses fill in the remaining fields, namely the Norton scale attributes and the feeding type. The GL imposes the compilation of this form at predefined time intervals. As a matter of fact, to each item stored in the EPR, a time stamp is associated, that is compared with the persistence time of that item, stored in the GL. The persistence of a parameter value is defined as the maximum time interval for which the value itself may be considered valid. For example, the body temperature has a low persistence time, because it may change rapidly, while the weight has a longer persistence, because a sensible variation may occur within days, instead of hours. The GL will require a new input for a parameter, whenever the persistence time of the last measurement is over.
In addition to risk assessment, the same form is used for evaluating the ulcer evolution (see the button ‘Ulcer’ in the menu). As a matter of fact, despite the implemented GL aims at pre6enting ulcers, the user interface is flexible enough to access the ulcer treatment data. This is necessary because a patient may have an ulcer somewhere and may need prevention in another body part so that the nurse needs easy access to the EPR for the two problems. Fig. 5 shows the ulcer evaluation form. Fig. 6 illustrates the form that nurses fill at the end of their shift. It was an electronic copy of the paper work-plan that they used during the day (see Table 2). The pop-up window illustrates the input of the motivation for the non-compliance.
7. Results We have designed and implemented a decision support system for pressure ulcer pre-
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
215
Fig. 6. Data about the work-plan that has been followed during the day must be entered into the EPR at the end of the shift. If some actions have not been performed, a justification is necessary (pop-up window).
vention, integrating it into the existing electronic patient record of a general medicine ward. Data are now being collected with two aims, i.e. to evaluate the user satisfaction and to evaluate the benefits of the GL introduction on patient outcomes. Data about 40 patients are actually available and despite the small sample size, a preliminary evaluation has been performed on the first issue. Results are summarised in Table 3, where pros and cons have been highlighted. Users appreciated the documentation generated by the GL, which facilitated handing on duties to the next shift nurses. Detailed storing of actions taken was useful at the patient discharge, to plan the future home care, and also was a means for assessing the nurse workload required by the prevention programme. As regards the educational tool, it had been judged as rich and easy to use. On the other hand, nurses complained about a certain rigidity of the GL in assess-
ing the patient risk, and in continuously asking for task completion. Finally, they required minimising the time spent in data input by generating some default values. These complaints will be used as a feedback for improving the GL implementation.
Table 3 Results on the user evaluation of the GL after 1 month of testing Acknowledged advantages
Required modifications
Improved planning Detailed documentation Workload assessment Education
More flexibility on the risk assessment More flexibility in setting the action timing More facilities for quick data input
216
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
8. Discussion and future development In the ward chosen as pilot site, nurses were greatly interested into pressure ulcers and had already begun to both introduce an ulcer prevention plan and organise training sessions for personnel belonging to other wards. Moreover, reluctance to the use of computers had been overcome many years ago, at the time when the HIS was installed. This could represent the optimal condition for a more systematic approach to the problem based on decision support system. Nevertheless, some problems arose, in particular as regards the care delivery tool. Once an acceptable site-specified GL had been identified through many meetings, users offered a certain resistance to apply the GL (as regards risk assessment) to every patient admitted. This would have entailed an overburden in terms of data input. On the other hand, one of the aims of a GL was to ensure uniformity of care, and, not to disregard, only the systematic patient evaluation allowed calculating sound statistical ratios (i.e. prevalence and incidence of patients at risk and ulcers). Integration with the HIS, together with the adopted policy for the management of noncompliance, appeared to be a determinant factor to prevent odd user behaviours. To balance efforts and gains, production of reports detailing all the actions undertaken according to the prevention plan and the medications had been provided to nurses for each patient discharge as a consequence of the task completion data storage. No data are available yet in order to evaluate the benefits of the GL on patient outcomes, because the system has been installed for a too short time. Data will be collected with the aim of making comparisons with previous ulcer incidence in the same ward and with other wards where the GL has not been adopted. Data about non-compliance will be
used for discovering some organisational bottlenecks that impair the full GL implementation.
Acknowledgements This work is partially funded by the European Commission through the project Patient workflow management system (PatMan) within the Health Care Telematics Applications Programme, Project HC 4017.
References [1] M.J. Field, K.N. Lohr (Eds.), Institute of Medicine Guidelines for Clinical Practice: from Development to Use, National Academy Press, Washington, DC, 1992. [2] C. Gordon, J.P. Christensen (Eds.), Health Telematics for Clinical Guidelines and Protocols, IOS Press, 1995. [3] D.B. Fridsma, J.H. Gennari, M.A. Musen, Making generic guidelines site specific, in: J.J. Cimino (Ed.), Proceedings of the 1996 AMIA Annual Fall Symposium, Philadelphia, Hanley and Belfus, Philadelphia, 1996, pp. 597 – 601, J. Am. Med. Inform. Assoc. [4] J. Fox, N. Johns, A. Rahmanzadeh, Disseminating medical knowledge: the PROforma approach, Artif. Intell. Med. 14 (1998) 157 – 181. [5] S. Quaglini, L. Dazzi, L. Gatti, M. Stefanelli, C. Fassino, C. Tondini, Supporting tools for guideline development and dissemination, Artif. Intell. Med. 14 (1998) 119 – 137. [6] S.W. Tu, M.A. Musen, The EON model of intervention protocols and guidelines, in: J.J. Cimino (Ed.), Proceedings of the 1996 Am. Med. Inform. Assoc. Annual Fall Symposium, Hanley and Belfus, Philadelphia, 1996, pp. 587 – 591, J. Am. Med. Inform. Assoc. [7] D.F. Lobach, W.E. Hammond, Development and evaluation of a computer-assisted management protocol (CAMP): improved compliance with care guidelines for diabetes mellitus, in: Proceedings of the Symposium on Computer Applications in Medical Care, 1994, pp.787 – 791.
S. Quaglini et al. / International Journal of Medical Informatics 58–59 (2000) 207–217
[8] L. Ohno-Machado, J.H. Gennari, S.H. Murphy, N.L. Jain, S.W. Tu, D.E. Oliver, E. Pattison-Gordon, R.A. Greenes, E.H. Shortliffe, G.O. Barnett, The guideline interchange format: a model for representing guidelines, J. Am. Med. Inform. Assoc. 5 (1998) 357–372. [9] M. Meehan, National pressure ulcer prevalence survey, Adv.Wound Care 7 (1994) 3. [10] P. Di Giulio, La prevalenza delle lesioni da decubito nei pazienti ospedalizzati, Rivista dell’infermiere 4(1) (1985) 20–34. [11] U.S. Department of Health and Human Services, Pressure ulcers in adults: prediction and prevention (AHCPR 92-0047), Agency for Health Care Policy and Research, Rockville, MD, May 1992. [12] D. Willson, C. Ashton, N. Wingate, C. Goff, S. Horn, M. Davies, R. Buxton, Computerised sup-
217
port of pressure ulcer prevention and treatment protocols, J. Am. Med. Inform. Assoc., Symposium (1995), 646 – 650. [13] R.D. Zielstorff, G.O. Barnett, J.B. Fitzmaurice, G. Estey, G. Hamilton, A. Vickery, E. Welebob, C. Shahzad, A decision support system for prevention and treatment of pressure ulcers based on AHCPR guidelines, J. Am. Med. Inform. Assoc., Symposium (1996) 562 – 566. [14] AISLEC, Profilassi delle lesioni da decubito e cambio posturale: ricerca multicentrica, linee guida, ANIN-NEU, 1995. [15] B.L. Humphreys, D.A.B. Lindberg, H.M. Schoolman, G.O. Barnett, The unified medical language system: an informatics research collaboration, J. Am. Med. Inform. Assoc. 5 (1998) 1 – 11.