implementation of a computerized protocol for
TRANSCRIPT
IMPLEMENT A TION OF A COMPUTERIZED PROTOCOL
FOR ANTICOAGULANT THERAPY
by
Peter 1. Malloy
A thesis submitted to the faculty of The University of Utah
in partial fulfillment of the requirements for the degree of
Master of Science
Department of Medical Informatics
The University of Utah
March 1995
Copyright © Peter James Malloy 1995
All Rights Reserved
THE UNIVERSITY OF UTAH GRADUATE SCHOOL
SUPERVISORY COMMITTEE APPROVAL
of a thesis submitted by
Peter J. l'tnlloy
This thesis has been read by each member of the following supelVisory committee and by majority vote has been found to be satisfactory.
/ / /' / I ' / / 1 / tJ (/ ill I c / ,I ! ) ,1 ;;'
/
) I�
Chair. T. Alian Pryor, Ph. D.
Peter J. Haug, M.D.
c. Gregory Elliott, M.D.
THE UNIVERSITY OF UTAH GRADUATE SCHOOL
FINAL READING APPROVAL
To the Graduate Council of the University of Utah:
I have read the thesis of Peter J. rlalloy in its final fonn and have found that (1) its fonnat, citations and bibliographic style are consistent and acceptable; (2) its illustrative materials including figures, tables and charts are in place; and (3) the final manuscript is satisfactory to the supervisory committee and is ready for submission to �e Graduate School. !
b,0;7/1 i f1tk1f-� Date / / T. Allan ?ryor, Ph. D.
Chair, Supe�isory Committee
Approved for the Major Department
,. . ·1
/,�1,t1�/1 ,rll{'Ct ��t-� EODer R. �qarne r
Chair/Dean
Approved for the Graduate Council
Ann W. Hart Dean of The Graduate School
ABSTRACT
Studies have demonstrated that the use of clinical protocols for a variety of
inpatient hospital therapies reduces variation in treatment and often leads to improved
outcome. At Latter Day Saints (LDS) Hospital in Salt Lake City, Utah, development
of clinical protocols has been given a high level of priority as part of the institution's
overall strategy, based on the principles of Total Quality Management, to achieve the
highest quality of care possible while simultaneously reducing cost. The use of
computers to manage clinical protocols is an area of special study at LOS Hospital
Lhat incorporates the use of the HELP (Health Evaluation Through Logical Processing)
clinical hospital information system. This research discusses the implementation of a
computerized protocol for anticoagulant therapy designed to manage therapy given to
patients with deep vein thrombosis on an inpatient general medical/surgical ward.
Many details need to be considered in the design of a computerized protocol to strike
a balance between computer automation and allowance for clinical judgement and
discretion. In addition to technical considerations, a successful implementation of a
computerized protocol is largely dependent upon organizational issues such as team
management and implementation process.
T ABLE OF CONTENTS
ABSTRACT .................................................. iv
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. VII
LIST OF FIGURES ............................................ viii
BACKGROUND AND PURPOSE .................................. .
IHC Management Strategy .................................. . Clinical Protocol Development on the National Agenda . . . . . . . . . . . . . .. 3 Medical Informatics at LDS Hospital . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6 Experience with Computerized Protocols at LDS Hospital ............. 9
A CLINICAL PROTOCOL FOR ANTICOAGULANT THERAPY .. . . . . . . . .. II
Background ............................................ 11 Overview of Protocol Logic ................................. 13
Risk Assessment and Placement on Protocol . . . . . . . . . . . . . . . .. 13 Medication Adjustment ............................... 15
COMPUTERIZATION OF THE PROTOCOL ......................... 17
Computerization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17 Knowledge Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17 System Implementation ............................... 18
Implementation Issues ..................................... 25 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25 Starting the Protocol ................................. 27 Content of Computer Generated Orders .................... 28 Notification and Delivery of Computer Order. . . . . . . . . . . . . . .. 29 User Interface and Work Flow Issues ..................... 30 Feedback Information ................................ 31 Medical Record Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32 Special Circumstances and Events . . . . . . . . . . . . . . . . . . . . . . .. 33 Data Storage and Record Keeping . . . . . . . . . . . . . . . . . . . . . . .. 34
Description of System ..................................... 35 Computerized Protocol Process Overview . . . . . . . . . . . . . . . . . .. 35 Special Features of System . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 41
Areas for Further SystelTI Enhancement ......................... 46 Tin1e Drive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 46 Interface to Order Communications . . . . . . . . . . . . . . . . . . . . . .. 46 Use of MIB for Automatic Charting of Heparin Dose .......... 48 Improved Application Development Tools .................. 48
EXPERIENCE ............................................... 50
SUMMARY AND CONCLUSIONS ................................ 53
REFERENCES ............................................... 54
VI
LIST OF TABLES
1. Nomogram for Adnlinistration of Heparin Based On PTT ............... 16
2. N01TIogram for Adnlinistration of Coumadin Based On INR . . . . . . . . . . . . .. t 6
3. Reject Reasons for Heparin Drip and PTT Lab Orders ................. 52
4. Reject Reasons for Coumadin Orders ............................. 52
LIST OF FIGURES
I. }-..'low Chart Depicting Placement on Protocol and Risk Assessment . . . . . . . .. 14
2. Computerized Risk Assessment ................................. 36
3. Medical Record Copy of Initial Order Set Printout .................... 37
4. Initial Order Set Displayed in the Computer. . . . . . . . . . . . . . . . . . . . . . . .. 39
5. System Flow Chart of Anticoagulant Therapy Protocol Process ........... 40
6. Heparin Change Order as Presented in the Computer .................. 44
7. Computer Screen for Selecting Order Reject Reasons .................. 45
8. 24-Hour Alert Review History .................................. 47
BACKGROUND AND PURPOSE
IHC Management Strategy
Intermountain Health Care (IHC) is a major health care system operating 24
hospitals located throughout Utah, southeast Idaho, and southwest Wyoming. Latter
Day Saints (LOS) Hospital, a 528 bed tertiary care facility located in Salt Lake City,
serves as the primary regional referral medical center for the IHC system. In 1985,
IHe developed a corporate strategic plan that embraced the principles of Total Quality
Management (TQM) to improve quality and reduce cost. Given its established
commitment to quality assurance, a clinical orientation for TQM activities was a
natural pathway for IHC. TQM relies heavily on information and statistical analysis to
discover management inefficiencies that may be addressed to improve quality. Since
IHC already had in place an excellent resource for clinical information in the HELP
computerized clinical information systen1, the n10ve towards a TQM strategy based on
clinical process management was particularly sensible.'
A fundamental TQM strategy is the implementation of systems for Continuous
Quality Improvement (CQI) through process control initiatives. Rather than relying
solely on surveillance techniques and retrospective review of clinical outcome which is
typical of quality assurance activities in hospitals, CQI systems seek to manage
clinical processes to achieve optinlal quality. Two American TQM theorists, W.
Edwards Deming and Joseph M. Juran, observed that problems, and therefore
2
opportunities to improve quality, had usually been built directly into the processes that
they studied. By identifying process problems, introducing changes into the process,
measuring the results, and identifying new problems, a system for continuous quality
improvement system may be achieved. 2
It is first important to define quality so that goals for quality improvement may
be established. Essentially, high quality is achieved by continual improveOlent
according to custoluers' expectations. Customer expectations may be di vided into two
major areas: I) expectations regarding the content of the output/product provided,
referred to as content quality, and 2) expectations about the way in which the service
or product is delivered and the interaction between provider and customer, referred to
as delivery quality. To iluplement a CQI system, the clinical process IUUSt be
established and standardized so it may be evaluated to determine its effectiveness in
achieving content and delivery quality. The patient is the primary customer, but
expectations regarding content quality, or medical outcome, are essentially set by the
medical profession by informal consensus. The establishment of clinical protocols hy
a teams of Iuedical professionals that know the process formalizes consensus setting
and is an integral pm·t of a CQI system?
True to its commitment to TQM, IHC strategic focus is on understanding and
managing care processes. Necessarily, this involves developing protocols consisting of
clear, scientifically grounded statements based on clinical process algorithnls for
delivering care. Once the protocol specification is made and documented, subsequent
steps in the CQI process may take place. First the protocol is implemented and
monitored for occurrences of inappropriate variation. The goal of this step is to relate
3
events of low quality to instances of variation in the process and to elirrlinate these
variations perhaps by refining the process itself. The final step in the CQI process is
to document continuous improverrlent and innovate. Once the protocol is in place and
sources of inappropriate variation eliminated, the team may introduce ideas about how
the process may be improved into the protocol specifications. Because other causal
factors of variation have been eliminated these ideas lTIay be tested with confidence
that changes in outcome are directly related to the newly introduced idea. The
proposed change can then be discarded, implemented or refined based on the results of
the test. 4
Clinical Protocol Development on the National Agenda
In 1989, Congress established the Agency for Health Care Policy and Research
(AHCPR) within the Department of Health and Human Services (HHS) to support
research on problenls related to the quality, delivery, and costs of health care services.
AHCPR has primary responsibility for implementation of the Medical Effectiveness
Treatment Program (MEDTEP) within HHS. The goal of MEDTEP is to "improve the
effectiveness and appropriateness of medical practice by developing and disseminating
scientific information regarding the effects of presently used health care services and
procedures on patients' survival, health status, functional capacity, and quality of life."s
The focus of MEDTEP research is on evaluating outcomes of care rather than studying
clinical processes. The process of evaluating outcomes involves specifying the various
tTIethods of health services delivery and making an association between method and
outcome. By identifying those variations in practice style that contribute towards poor
4
outcome and rnaking this information available to practitioners, inappropriate variation
may be minimized and outcome improved.
The recognition that variations in treatment patterns exist and that information
regarding treatment options and their effectiveness is not readily available to clinicians
is a primary justification for implementing outcomes research. Through outcomes
research, statistically grounded conclusions may be made regarding the efficacy of
existing popular treatment methods or new, innovative, and experimental ones. With
information from outcomes research along with opinion and consensus from experts,
recommendations may be made on practice styles that produce best results. The
development of these clinical practice guidelines is another important area of focus for
AHCPR. Specification and dissemination of clinical guidelines respond to the
imperative of translating the rich body of medical research knowledge into practical
tools for clinical decisionmaking at the patient bedside. Some of the clinical guideline
projects sponsored by AHCPR include acute pain management for operative or
medical procedures and trauma, management of urinary incontinence in adults,
poststroke rehabilitation and management of low back problems.
AHCPR emphasizes a descriptive rather than a prescriptive approach to clinical
guideline development where the practitioner's autonomy is preserved and allowances
are Inade for legitimate differences of clinical opinion. This author distinguishes
between practice guidelines and clinical protocols to the extent that clinical protocols
such as the Computerized Protocol for Anticoagulant Therapy apply a strict and
regimented set of rules and criteria for treatment. Although clinicians are encouraged
to exercise their clinical judgement and deviate from the protocol if warranted, no
alternate pathways are suggested or supported. Clinical protocols and clinical practice
guidelines are similar in most respects, however. Both are science-based relying on
objective evidence from carefully administered studies and corroborated by expel1s in
the field. Also, both guidelines and protocols are designed to be ongoing, dynamic
and capabJe of being easily modified in response to advances in medical knowledge,
technology, clinical utility and patient acceptance. Most importantly, protocols and
guidelines address the need to disseminate knowledge to care providers in an effort to
minimize inappropriate variation in treatment.°
5
The Clinton Administration has embraced practice guideline development as
integral to the quality management and improvell1ent principles that underlie the White
House health care reform proposal. Although no health care reform proposal was
adopted during the most recent session of Congress, the proposed Health Security Act
of J 993 laid the groundwork for what key quality management provisions should be
included in any future health care reform initiative. The Health Security Act of 1993
proposed the establishment of a National Quality Management Council to oversee a
perforolance-based program of quality management and improvement designed to
"enhance the quality, appropriateness, and effectiveness of health care services and
access to such services."7 In addition to establishing national measures of quality
performance and reporting requirements, the Council was given responsibility for
directing the Administrator for Health Care Policy and Research to develop and
disseminate practice guidelines. As outlined in the Health Security Act, practice
guidelines must meet certain requirelnents that include I) being based on available
research and professional judgement regarding the effectiveness and appropriateness of
6
health care services and procedures, 2) being presented in formats that may be easily
understood and used by clinicians, educators and consumers, 3) being
treatment-specific or condition-specific appropriate for use in clinical practice, and 4)
specifying the risks and benefits of alternative strategies for care management as well
as cost information where available. The National Quality Management Council was
also charged with establishing a program, administered by AHCPR, for evaluation and
ce11ification of guidelines developed by individuals and external entities.x
Medical Informatics at LDS Hospital
The HELP (Health Evaluation Through Logical Processing) system is a
comprehensive, integrated hospital information system (HIS) currently in active use at
LDS Hospital. HELP distinguishes itself from Inost other HIS's in its orientation
towards storage and management of clinical information rather than the processing of
financial and billing data. The evolution of the HELP system to its current form today
has occurred over a period exceeding 20 years and has been guided by pioneering
individuals in the emerging field of medical informatics. Many lessons have been
learned during this evolutionary period and have helped define many of the
fundamental principles of medical informatics. Indeed, lessons continue to be learned
today as ideas are tried and new c1inica1 applications are introduced.
That the HELP system adheres to these fundamental principles of nledical
informatics is why clinical decision support applications such as the computerized
anticoagulant therapy protocol are possible. As mentioned above, the HELP system is
integrated having a single clinical database that is the repository for all computerized
clinical infornlation for the patient. Although a few departmental systems exist, such
7
as the laboratory system, all data is fed into the HELP c1 inical database and is
available from one source. Most medical decisions require multiple bits of
information. For exmnple, for the computerized anticoagulant therapy protocol to
generate a heparin medication change order both the PTT laboratory value frOln the
laboratory system and the current heparin medication IV rate as charted in the nurse
charting system are needed. If these data items were not integrated into the clinical
database, the cornputer could not process such an order. A second important feature
of HELP is that the majority of data stored in the database is coded. For example, the
PTT lab value is uniquely identified in the database by a code rather than being stored
as a free text description of the result. Free text information is not easily processed by
a computer and coded data is a basic requirement of any clinical system that wishes to
provide decision support.
HELP was designed from the start for the purpose of not only delivering
information to care providers but assisting in processing data and making clinical
decisions. Although it is useful to be able to look up a PTT lab value in the computer
when considering how to adjust a patient's heparin dose, a more meaningful decision
support approach would involve alerting the clinician that a PTT value has been
reported and presenting a recommended heparin IV rate change. Clear1y, decision
support requires additional processing that usually involves applying medical logic or
rules to a set of clinical data. HELP supports an effective means of representing and
nlanaging medical knowledge by allowing for the representation of the knowledge
base separately from the inference engine. The knowledge base may be thought of as
the set of rules or clinical logic that may be applied to specific data as part of a
8
decision process. The inference engine is the actual computer instructions and
software code that processes the logic on the proper set of data. In HELP, the
knowledge base is represented in medical knowledge modules using a readable and
easy-to-understand computer language called HELP Frame Language. These medical
logic modules may be easily modified and refined without affecting or requiring
changes to the inference engine. This structure allows for the development of a robust
decision support environment where criteria for decisions change and evolve
influenced by technology, expert opinion, and clinical outcome.
Consistent with IHC's focus on managing care processes, HELP developers
have sought to design a system that delivers information at the point of service and in
a timely manner that integrates into the normal work flow of providing care.
Computer terminals are located on patient floors both in convenient work areas and at
the patient bedside. The patient database is constantly and dynamically updated both
by users at terminals (i.e. nurse charting) and directly from nledical devices such as IV
pumps. Additionally, ancillary systems such as the laboratory system and the EKG
system feed data into the HELP patient database on a constant basis. Having such real
ti me access to patient data is critical if point of service decision support is desired.
Recognizing this fact, the HELP hardware platform was converted in 1980 from a
CDC 3300 system to a Tandem mainframe computer that incorporates fault tolerance
and non stop system features. Currently, the HELP system experiences an average
downtime of less than I percent.
Experience with Computerized Protocols at LDS Hospital
Utilizing HELP's decision support capabilities to manage patient care protocols
has already nlet with success in the ICU setting at LDS Hospital. In the late 1980s
development began on a HELP-based computerized protocol for ventilator
9
management for patients with adult respiratory distress syndrome (ARDS). The
motivation for the project originated from the desire to study alternate methods of
ventilatory management. Conducting an experiment of this type required that study and
control groups be assigned and therapy procedures standardized. Paper protocols were
initially used to standardize therapy but the complexity of the instructions made them
difficult to follow. Therefore, a decision was made to computerize the protocol using
HELP.
Although the computerized ARDS protocol was initially used to manage
patients enrolled in a specific study, it has since been refined and extended to be used
for other patients with hypoxemia or ventilatory failure. A 1992 study conducted by
members of the Pulmonary and Critical Care Divisions at LDS hospital implemented a
computerized protocol to manage pressure control inverse ratio ventilation (PCIRV) in
ARDS patients. The protocol was used for 1,466 hours in ten around-the-c1ock
PCIRV evaluations on seven patients with severe ARDS. Patient therapy was
controlled by protocol 95 percent of the time with 90 percent of a total 2,158 protocol
instructions followed by staff. Clinical measures of respiratory function revealed
improved status and the protocol demonstrated the feasibility of using PEEPi as a
primary control variable for oxygenation.9
10
The peIRV protocol is an example of leveraging the advantages of
computerization to manage a complex process that would have been very difficult if
not impossible to manage manually with any accuracy. However, other areas of
patient care that involve simple clinical processes may also benefit from
computerization. Using data available from the HELP patient database, a study was
conducted in 1992 to examine the relationship between the timing of prophylactic
administration of antibiotics and the risk of surgical-wound infections. A retrospective
analysis of 2,847 surgical patients was done and the time of antibiotic administration
was collected in relation to the time of surgery. Antibiotics given 2 to 24 hours
before surgery was considered early, 0 to 2 hours before designated preoperative, up to
3 hours after incision was perioperative, and more than 3 hours postincision was
defined as postoperative. Results indicated that patients who received antibiotics
during the preoperative period experienced significantly fewer surgical-wound
infections. Ensuring that all future surgical patients received antibiotics during this
optimal time window required a simple process control measure. Based on the
scheduled time of surgery, the HELP system now delivers a simple instruction to
administer antibiotics preoperatively for all scheduled surgical patients. 1O
A CLINICAL PROTOCOL FOR ANTICOAGULANT THERAPY
Background
Venous thromboembolism is a condition that affects approximately 7 million
people annually in the U.S. ll The condition is caused by a blood clot forming in a
major vein and has symptoms of swelling and pain in the affected extremity.
Approximately 25-30 patients per month are admitted to LDS Hospital with a
diagnosis of venous thromboembolism and require some amount of anticoagulant
therapy medication to dissolve the clot. The most common location for a venous
blood clot to form is in the legs. This condition is more specifically denoted proximal
deep vein thrombosis of the lower extremities (DVT). Clots formed in veins above
the popliteal vein (near the knee) are pal1icularly dangerous and difficult to treat. The
primary risk of prolonged illness is the migration of the clot to the lungs and
development of a pulmonary embolism which can be fatal.
Classjc treatment of patients with DVT involves initial treatment with
intravenous sodium heparin followed by long-term oral anticoagulation using
Coumadin. Patient response to heparin therapy differs widely among patients
requiring treatment for DVT. For this reason, the traditional approach to heparin
administration is to nleasure the heparin response and adjust the heparin IV rate
accordingly. The accepted measure of anticoagulant response to heparin is the
patient's activated partial thronlboplastin time (PTT). Studies have demonstrated that
12
patients who achieve a therapeutic PTT range within the first 24 hours of therapy are
at a significantly reduced risk of recurrent venous throlnboembolism. Additionally,
evidence indicates that failure to exceed the lower limit of the therapeutic range
presents an unacceptably high risk of recurrent venous thromboembolism. However,
traditional practice has put equal or greater emphasis on avoiding overanticoagulation.
The clinical custom has been to take precautions not to exceed the upper limit of the
therapeutic range despite there being little evidence to support an increased risk of
bleeding from exceeding the upper limit of the therapeutic range.
Administration of heparin is typically done on an ad hoc, intuitive basis and
wide variations in practice exist even within hospitals. Often, fear of bleeding causes
an overly conservative approach to heparin dosing resulting in inadequate
anticoagulant effect and undesirable outcomes. For this reason, there is a pressing need
to establish guidelines for anticoagulant therapy and to integrate them into standard
medical practice to ensure quality. Recently, a rigorous quality assurance evaluation
was cornpleted at a Canadian hospital where two clinical protocols for anticoagulant
therapy were developed and implemented for use. One protocol was limited only to
heparin dosing and the other protocol prescribed both initial heparin and Inaintenance
Coumadin. Patients were randomized to the two study groups and results analyzed to
con1pare their effectiveness. Both protocols resulted in 99 percent of patients
achieving the goal of anticoagulant effect within 24 hours. 11 The protocol
implemented in this study that included Coumadin medication was recently
implemented at LDS Hospital and compared to non-protocol-directed treatment. Use
of the protocol by LDSH physicians resulted in 95 percent of patients achieving
anticoagulation within 24 hours cOlnpared to only 79 percent of patients who were
Inanaged without protocol. 11
Overview of Protocol Logic
13
The protocol implemented manually at LDS Hospital served as the foundation
for the logic incorporated into the computerized protocol. Development of the
protocol logic occurred through an extensive knowledge engineering exercise involving
obtaining consensus frool expert clinicians at LDS Hospital and thorough literature
review.
Risk Assessment and Placement on Protocol
Although the computerized protocol is designed to operate automatically
without interaction from the physician requiring only nurse involvement, initial
placement of the patient on protocol is done by the physician. The physician is first
required to assign the patient to either a high or low risk category for bleeding which
stratifies the patient into either a high or low risk protocol for anticoagulant therapy.
Regardless of risk assessment, upon placement on protocol, all patients are given an
initial 5000 unit IV bolus of heparin. Then, depending on the risk assessment, the
patient is placed on a continuous heparin IV infusion of either 1240 units/hr for high
risk or 1680 units/hr for low risk. Figure I depicts the process of risk assessment and
initial heparin medication administration. Although final assessment of bleeding risk
is left to the physician'S discretion, patients with the following conditions are
designated as high risk: I) major surgery, internal organ biopsy or major trauma
within the last two weeks, 2) bleeding requiring a transfusion within the last eight
No
--..... y Heparin IV Infusion
1680 u/hr
START !
t Heparin 5000 u Bolus
Yes
I , Heparin IV Infusion
1240 u/hr
I
..... Y....._. __ ........ __ . '1 ---~
Go to PTT ordering protocol ) ..... - ... ---~
Figure 1. Flow Chart Depicting Placement on Protocol and Risk Assessment ........ ~
15
weeks, 3) PT greater than 12 seconds, 4) PTT greater than 32 seconds, 5) platelet
count less than 150x 1091L, 6) platelet dysfunction, and 7) any other condition that may
warrant high risk designation. In addition to the initial heparin lnedication, all patients
arc given an initial 10 mg dose of Coumadin. Finally, initial orders for the protocol
include baseline laboratory tests (PTT, PT, SMAC20, CBC), daily labs (PT, PTT,
CBC), guaiac all stools, and complete bed rest with bathroom privileges only.
Medication Adjustment
The protocol logic for adjusting heparin dose is based on PTT laboratory blood
coagulation values. A PTT is always ordered 6 hours after any change in IV heparin
therapy. If no change in heparin therapy has occurred (i.e. the last protocol instruction
was to maintain current drip rate), the PTT ordering policy reverts to a daily PTT.
Table 1 outlines the heparin nomogram used for the computerized protocol for
anticoagul ant therapy.
The initial protocol order set also includes adnlinistering an initial Coumadin
dose of 10 mg to be given at 14:00 hours on the first day following enrollment on the
protocol. Subsequent Coumadin orders are given based on daily prothrombin time
(PT) laboratory results. Rather than using the actual PT value, a relative scale using
thc international normalized ratio (lNR) is used to adjust Coumadin. The nomogram
for Coumadin dosing based on INR value is outlined in Table 2.
16
Table 1. Nomogram for Administration of Heparin Based On PTT
PTT Range Protocol Instruction
PTT ~ 110 Stop heparin for I hour Restart at 6 cc/hr less than previous rate
85 ~ PTT < 110 Stop heparin for 1 hour Restart at 3 cc/hr less than previous rate
55 ~ PTT < 85 Maintain current heparin drip rate
45 ~ PTT < 55 Increase heparin IV drip rate by 3 cc/hr
PTT < 45 Rebolus 3000 u heparin Increase heparin IV drip rate by 6 cc/hr
Table 2. Nomogram for Administration of Coumadin Based On INR
INR Range Protocol Instruction
INR < 1.5 Give Coumadin 10.0 mg PO at 1400 hours
1.5 ~ INR < 1.9 Give Coumadin 7.5 mg PO at 1400 hours
1.9 ~ INR < 2.3 Give Coutnadin 5.0 Ing PO at 1400 hours
2.3 ~ INR < 3.0 Give Coumadin 2.5 mg PO at ] 400 hours
INR ~ 3.0 Hold Coumadin
COMPUTERIZA TION OF THE PROTOCOL
Computerization Process
Knowledge Engineering
Although knowledge engineering is not the focus of this report, it is an
important part of the process of computerizing a protocol. Even a protocol with
simple, straightforward rules such as the one presented here requires a significant
amount of work to encode the logic in the computer system. For this protocol
implementation, knowledge was obtained through examination of the medical literature
and consultation whh expert clinicians at LOS Hospital. Although it is important for
credibility reasons to have empirical research evidence that supports using a protocol
to improve quality of care, local development of the specifics of the protocol is
equally important. A team of LOS Hospital staff including physicians, nurses, medical
informatics staff and nursing informatics staff participated in developing the functional
requirements of the protocol. This multidisciplinary team approach was important to
ensure integration with patient care work flow and to gain support and consensus from
the actual care providers at the hospital.
The goal of the knowledge engineer is not only to accurately represent the
specifics of the protocol logic in the computer but to provide a model and develop a
mechanisJTI that promotes both easy modification of the knowledge and
transportability. For this project, the HELP Frame Language was used as the
18
computer programming language to represent the protocol logic. The advantages of
using the HELP Frame Language as the programming platform rather than some lower
level computer language are that it adheres to a standard developed for representing
medical knowledge called Arden Syntax and can be easily read, reviewed and
understood by clinicians who have no programming background. Also, the knowledge
frames can be transported to other facilities that use a non-HELP HIS that supports the
Arden Syntax for medical knowledge representation.
System Implementation
After the protocol logic development and knowledge engineering phases are
completed the computer application must be developed that notifies the care giver and
presents protocol instructions, interacts with care givers and users of the computer
system, operates within the normal work flow of a busy hospital, adheres to
computerization standards and policies, and updates the computerized patient record
with accurate and appropriate information. The focus of this report is on the myriad
of issues that arise during the development and imp1ementation of this computer
application.
The process of implementing the computerized protocol for anticoagulant
therapy application involved several steps. Probably the most critical step is
organizing an implementation team to participate in all aspects of systen1 feature
specification and design. It is important to recognize that the implementation of a
computerized protocol (or any clinical application for that matter) will impact not only
patients but the work processes of many care givers. It is imperative, therefore, that
the hospital personnel that will be impacted have some amount of representation on
19
the implementation team. Hospitals are often compared to small cities with many
special ized and disparate functions carried out by workers that all contribute to a
COJ1lmOn goal. Representation and input from these workers are not only necessary to
ensure involvement, buy-in, and proper communication of project goals, but invaluable
insight can be obtained about how the system will affect work flow in important
functional areas of the hospital. Although having a diverse implementation team is
desired, communication of team member roles and responsibilities is essential to gain
a mutual understanding of what each member can and should contribute to the process.
A physician project director that can make a strong commitment of tilne and
energy to the project is key to the success of implementing a computerized protocol.
The role of the physician director is twofold: 1) to serve as the authority and last word
on all clinical issues that need to be addressed, and 2) to provide the direction and
leadership necessary with the authority and willingness to make final decisions in the
face of converging opinions from team members. Also, having a prominent physician
who can champion the project and stimulate interest and enthusiasm among his
physician colleagues is of great benefit.
Ideally, the implementation of a clinical protocol should include the
administration of a research study to evaluate its effectiveness. Even if certain
protocols are well accepted in the medical community, implementation and
management via computer is fairly novel. Enrollment of study patients and collection
of data to measure performance is necessary if there is any expectation to learn fro III
the experience. At LDS Hospital, the Pulmonary Division has allocated significant
resources to research in several clinical areas. A team of three nurses specializing in
20
anticoagulant therapy were assigned to the implementation team to manage the process
of adlllinistering a research project. Their responsibility included obtaining informed
consent from patients, working with house staff to get patients properly enrolled on the
protocol, and monitoring the protocol by tracking all laboratory values returned for
study patients and recording the computer system's response. Research nurses also
remained on-call during the entire hospital admission for patients enrolled on the
protocol. Research nurses were the primary resource for responding to questions frolll
floor nurses regarding clinical management of patients on the protocol. Being expert
in coagulopathy, input from research nurses was invaluable during the process of
testing the conlputerized protocol prior to implementation. The initial testing phase
involved allowing the computer to run in the background on actual patients and
observing system response to laboratory data entered into the patient database.
Research nurses interacted with the computer to acknowledge computer generated
orders and provided feedback on the accuracy and appropriateness of orders delivered.
In addition, research nurses served as true pilot test end users and were able to provide
some useful suggestions relating to user interface issues.
Nursing Informatics (NIS) played a key role in the system design and in the
implementation of the system clinically. The West-8 Nursing Division is a 48-bed
general medical/surgical ward that is unique at LDS Hospital because it is the only
med/surg ward in which all nurse charting is done in the computer. It is the
responsibility of the Nursing Informatics coordinators to train and educate nurses on
use of the computer, document features of the nurse charting system, coordinate new
systelll development projects, and serve as the liaison between nurse end users on the
21
nursing division and the Medical Informatics Department. An NIS coordinator was
assigned to the computerized anticoagulant therapy protocol implementation team and
provided invaluable input by identifying potential conflicts between the proposed
system and existing nursing work flow. In proposing solutions to these identified
conflicts, the NIS coordinator sometimes recommended making system design changes
and in other instances addressed the problem by making minor work flow process
changes. Another area of involvement with NIS was in justifying and getting approval
for the project frOin the hospital Nursing Practice CounciL Any project that
represents a significant change from standard nursing practice needs to be presented
before the Nursing Practice Council for approval and the NIS coordinator served as a
liaison to this committee. Guidance from NIS was instrumental in the process of
proposing system features and capabilities particularly relating to complying with
existing user interface standards and integration with existing nurse charting
applications. NIS took the leadership role in specifying and documenting policies and
procedures for operating the computerized protocol as well as contingency planning in
the event of computer downtime. Finally, NIS coordinated the training of nurses on
the floor and served as the primary contact person for questions regarding how to
operate the computerized protocol once the system was implemented and patients
enrolled.
Ultilnate responsibility for system design and implementation was with the
Medical Infonnatics Depaltment. The process of implementing a computerized
clinical protocol requires many weeks of planning and system development where the
implementation team must t11eet on a weekly basis to discuss progress and plan next
22
steps. The medical informatics staff took the leadership role in establishing project
goals and timeliness, setting priorities, and assigning tasks and responsibilities to team
members. As the experts among the implelnentation team in computer systems and
application development, medical informatics staff proposed most of the basic system
requirements and features. Knowing the capabilities and limitations of the hospital
information system, they were also able to provide immediate feedback on the
feasibility of ilnplementing any proposed system features. It is important to note,
however, that although the medical infonnatics staff provided much of the initial
guidance and introduction of ideas, final determination of system features and user
interface specifications was made via group consensus and sometimes deviated
significantly from the original proposal. All cOlnputer programming and database
administration responsibilities were carried out by the medical informatics staff
including identifying and creating data elements, developing data storage structures
and standards, and establishing data retrieval lnethods and procedures. In addition to
developing the actual computer application, developing a testing and simulation
environment was also an important task that proved to be of significant value.
Another important process step that should occur before development of the
computerized protocol begins is completion of a study that implements a manual,
paper version of the protocol using the exact same protocol logic and instructions as
the computerized version will use. This is an important step for two reasons: I) it
provides an opportunity to evaluate the effectiveness of the protocol itself and tnake
any changes in the protocol logic that are necessary, and 2) data can be collected that
can later be used in a simulation to test the C0l11puter system's response to an actual
2:1
set of clinical data. Data that should be collected include medications given (time and
dose), laboratory tests ordered (time ordered, time results received and value of result),
risk assessment information, and any other infornlation that drives the protocol logic.
After the implementation team is assembled and comes to a consensus on the
primary system requirements and features, an initial prototype should be developed.
Testing at this stage can involve simple simulations using test patients. Having an
casy-to-use testing and simulation environment that can be operated by non
prograrnmers aJ]ows other members of the implementation team to test the initial
prototype and provide feedback.
Most likely, initial testing win stimulate recommendations for changes and
enhancements to system features. Once these changes are agreed upon and
incorporated into the system, a secondary testing phase can begin involving
background testing with actual patients. Under this scenario, patients are placed on
the compuLerized protocol but therapy is not driven by protocol instructions and any
order notification features are deactivated. The computer system nlay be observed to
identify inaccurate or inappropriate delivery of protocol instructions. Since protocol
orders generalJy depend upon appropriate completion of previous orders, the systenl
cannot be expected to behave exactly as if the protocol were running given the
likelihood that physicians are not prescribing treatment according to the protocol.
Nevertheless, system response can be evaluated to determine if orders are
appropriately responding to the laboratory and charting data that are entered. This
testing phase also provides the opportunity to examine computer response to the
situation where expected data are not avai lable in the patient database.
24
We found that the background testing phase stimulated a great deal of
discussion, ideas and recomtnendations at weekly meetings on system changes that
would be necessary for the systenl to operate effectively in a clinical environment.
Additional changes incorporated into the system based on these recommendations
brought the development cycle very near to the point of beta test readiness. At this
stage, an additional simulation was done using actual patient data gathered during the
study implenlenting the paper version of the protocoL The purpose of this step was to
compare computer generated instructions to actual orders given and carried out during
the study and to document deviations. Although patients may be on a manual
protocoL physicians wil1 sometimes deviate slightly from the protocol if, in their
clinical judgement, such action is warranted. In this respect, a paper protocol is much
less rigid and strict than a computer directed protocol that requires acknowledgement
of all computer generated orders. This testing phase will highlight potential problems
with the knowledge base and computer logic that may need to be addressed.
Once the system is at the point of beta test readiness, end users on the nursing
ward need to be formally oriented to the system and trained. Since it is human nature
to forget as time passes, it is ilnpol1ant to do the training as close to the anticipated
roll-out date as possible. During the training period, additional background testing
with actual patients can be done to fine tune the systeln. The first few patients
enrolled on the computerized protocol will require close supervision from members of
the implementation team and persons should be on-caJI to respond to clinical
questions, questions on how to operate the computer, and the event of computer
system faj] ure or crash.
Implementation Issues
During the process of implenlenting the computerized protocol for
anticoagulant therapy, many predicted and unpredicted issues arose which warrant
discussion. We have had an excellent opportunity to learn fronl our mistakes.
Communicating our experiences may help others who are interested in implementing
computerized protocols.
System Requirements
25
The computerized anticoagulant therapy protocol implementation team was
fortunate to have in its arsenal of tools a robust hospital infornlation systetTI (HELP)
upon which the application was built. An important feature of HELP is its integrated
patient database without which the conlputerized anticoagulant therapy protocol could
not have been developed. The computerized protocol requires data from the laboratory
results reporting system, the nurse charting system, and the pharmacy system. The
laboratory system is the source of PTT and INR values that drive the logic for
generating orders. The medication charting function of the nurse charting system
stores the current heparin IV rate which is also needed to generate a medication
change order. Finally, the computerized protocol automatically schedules Coumadin
and heparin in the pharmacy system.
A second system requirement is having flexible application development tools.
HELP sUPPOI1S a proprietary programming language called PAL for writing clinical
applications which used to create the user interface and alert acknowledgenlent screens
as well as perform database management tasks. PAL supports a modular programming
approach where processing functions can be broken down into individual application
modules called frames. These frames can be called and used by other programs and
fralnes thus allowing reusability of programming code.
26
A special feature of HELP is its ability to initiate processes based on din ical
events that involve writing data to the patient database. This function is called data
drive and is an ilnportant requirement for a protocol of this type. Whenever PT or
PTT laboratory values were reported in the HELP database, the data drive mechanism
would recognize the event and auton1atically invoke a process that generates the
proper computer order. The computerized protocol for anticoagulant therapy is an
event driven model that requires the data drive mechanism.
A final unique feature of HELP that was a critical systeln requirement of the
computerized protocol is its specialized alerting subsystem that allows for efficient
posting, storage and retrieval of messages and alerts. Alerts are stored in a special
alert file that is separate from the primary patient database and has its own unique
structure. When an alert is posted it is assigned a specific destination usually based
on terminal type (bedside or division terminal) and stored in the alert file with a key
field that identifies the destination type (,'RM"::patient room, IDY"::division).
Algorithms may be easily programmed to se,:ll'ch the alert file for the presence of alerts
and to display then1 if appropriate. For exarnple, at the patient bedside only alelts
with a destination type of "RM" are displayable by default and a flashing red "A" will
display in the corner of the computer screen indicating the presence of alerts posted to
the patient roonl. A flashing "A" will display at division terminals if any alerts have
been posted with a "DY" destination for any patient on the division.
27
Startin g the Protocol
It was clear from the outset that the physician should be ultimately responsible
for placing the patient on the computerized protocol. It was less obvious, however,
how this process should be done. One option to consider is the physician placing a
standard order requiring the nurse to interact with the computer and enroll the patient.
Another method would require that the physician directly interact with the computer
and enroll the patient. We believed it was ilnportant that the physician be closely
involved with the enrollment process and directly interact with the computer. The
computer could then manage the enrollment process to provide complete information
directly to the physician that would aid in making the decision to enroll or not.
The method of placement then has to be considered. Should the option to
place on protocol be associated with a medical problem? Should the physician be
required to pick from a list of all available protocols? Should a prompt for protocol
placement be stimulated by medications prescribed by the physician or laboratory tests
orders or radiology exams?
The computerized protocol for anticoagulant therapy relied upon a computer
generated risk asseSSlnent questionnaire to stratify patients into either a high or low
risk for bleeding protocol. The requirement to have multiple versions of a protocol
based on certain patient baseline clinical criteria is not unusual. Considering how best
to stratify patients is an important issue. If stratification is necessary, should a
computerized questionnaire approach be used or should stratification rely only on data
already present in the patient database? Should a combination of questionnaire and
database be used and, if so, should the physician be able to override the computer's
assessment?
Content of Computer Generated Orders
28
The iInportance of generating precise, complete, and unambiguous orders
cannot be stressed enough. Orders generated by the computerized anticoagulant
therapy protocol included both medication change orders and laboratory test orders.
The medication orders need to be presented like any physician generated order
including medication name, route, dose, and time. It is always important to present
information to users in ways that help them to better do their job. For example,
although nurses are used to receiving heparin IV change orders in units/hr fronl the
physician, they are required to adjust the IV AC pump in increments of cc/hr and,
therefore, lnust perform the calculation of cc/hr fronl units/hr. Although the computer
relied on charting data in units/hr, orders were always presented to nurse end users in
both units/hr and cc/hr to help make their job easier.
Wording of laboratory tests presented their own problems especially with the
presentation of the initial protocol order set that caBs for daily labs. A conflict arose
with ordering daily labs when a heparin change follow-up lab is ordered at about the
same time. This situation calls for vigilance in monitoring labs ordered so that blood
draws for daily labs can be coordinated with the follow-up lab. Ideally, lab orders
should be presented with the exact time the lab should be ordered (i.e. Draw PTT at
13(0). Since developing the logic to calculate a precise time for every lab order
would be very difficult, we took steps to add special instructions in the initial order set
to ensure coordination and tinling of labs.
29
For the computerized anticoagulant therapy protocol, a decision was made early
on that nurses should be required to acknowledge all orders and either accept and
follow the order or reject it if the order is inappropriate or inaccurate. Given this
expectation, we had to consider whether providing only the actual order was sufficient
or should additional information be presented to aid in making the decision to reject or
not. We identified two types of additional information that may be presented to aid in
the decision making process. The first information type is the data and computer logic
upon which the order was based. Questions to be considered include: Should the logic
be presented in a nan-alive that explains the logic or should just the data that drove the
orders be displayed? Should the information be presented directly with the order or as
a display option? The second information type consists of additional cOlnputer
reminders and alerts. Among the potentia) useful alerts are: reminder to chart
medication, reminder to order lab test, warning of possible spurious lab result, and
wanling of possible incorrect medication dose upon which order is based.
Notification and Delivery of Computer Order
Notification involves alerting users to the presence of orders in the computer
lhat require acknowledgeJnent. The process of delivering an order to its proper
destination stiInulates notification. A basic method of notification involves presenting
some sOli of signal or message at the computer terminal where the order has been sent
and awaits review. In HELP, the alerting subsystenl will send a beep and display a
red flashing!! AI! in the lower left corner of the computer terminal screen if an alert is
present. Several options may be considered for notification and delivery of computer
orders including: I) Sending only to nurse responsible based on computer sign-on ID.
30
Under this scenario, the nurse could be notified by a beep and a flashing "A" when
signing on to the cOInputer. Upon invoking the review alert function, the nurse would
be presented only with those alerts for her patients. 2) Send orders to all division and
bedside terminals requiring nurses to review their own patients. This approach would
stimulate a flashing HAil at all division terminals so nurses would have no way of
knowing if the pending orders are for their patient unless they go to the bedside
terminal to check for the flashing" A" or invoke the alert review function for their
patient from any terminal. 3) Send orders to division terminals only with ward c1erks
having rcsponsibility for reviewing alerts and notifying nurses of pending orders. This
solution may present probleITIs during nights and weekends when there is no ward
c1erk on duty. 4) Notification via pager system in parallel with one of the methods
mentioned above. When an order is generated for the patient, the nurse is
automatically paged and signs on to any terminal to review orders.
User Interface and Work Flow Issues
Once orders are delivered and displayed in the computer, the end user must
have the ability to acknowledge them. Designing a robust and easy-to-use mechanism
for acknowledging orders is key to the success of a computerized clinical protocol.
Equally important is establishing policies for order acknowledgement such as how to
handle acknowledgement of multiple order sets and when it is acceptable to not
immediate1y acknowledge an order.
A first question to consider is whether or not users should have the ability to
reject computerized orders. Consistent with hospital policy and nursing job
expectations, nurses should have the freedom to exercise their clinical judgement and
31
question the cl inical appropriateness of an order. For this reason, and given the
likelihood that the computer will sometimes generate improper orders, we advise
incorporating the capability to reject computer orders. Methods must be designed to
mark orders for rejection as well as capturing input from the user indicating a reason
for rejection. The implementation team should consider whether a free text reason for
rejection is adequate or whether the user should select from a pick list of coded
standardized reject reason. If the reason for an incorrect order is that the data upon
which it was based is incorrect, perhaps a capability to correct or update the database
and regenerate and alert should be incorporated into the system.
Establishing a smooth interface between protocol order review and
acknowledgement screens and other necessary computer functions such as nurse
charting is crucial. For example, once nurses accept and follow a heparin change
order the information must be charted in the computer. If it is not charted, the next
heparin order will indicate a rate adjustment from the old rate that will be incorrect!
Efforts should be made to automate these critical interfaces as much as possible.
Other interface issues to consider is making other relevant hospital information
system features and functions easily available. For example, having hot-key access to
laboratory results review, medication charting, and medication edit functions within the
alert review screens proved to be helpful.
Fcedback Information
Since the ultimate goal of implementing a computerized protocol is enhancing
quality of carc, providing mechanisms to monitor both clinical response and
compliance to the protocol is important. At a Ininimum, a capability to review the
32
history of orders acknowledged and the disposition of orders (accepted or rejected) is
recommended. Other types of feedback information could include a medication
administration history report for heparin and Coumadin, a graphical display of PTT
response to heparin therapy during the first 48 hours of the protocol, a graphical
display of PT response to Coumadin over the entire hospital stay, and an exception
report giving a count of total orders generated, a count of total orders rejected, and a
detail listing of orders rejected with reject reasons. With this kind of continuous
feedback, performance of the protocol may be assessed and recommendations made for
modifying the protocol to improve quality of care.
Medical Record Issues
The use of computers in clinical care presents some interesting issues relating
to documentation in the medical record. The argument can be made that duplicating
the electronic data in the computer for the paper nledical record is unnecessary and a
waste of paper. Certainly complete duplication of all data stored in the computer is
unwarranted, but some amount of paper documentation with signature sign-off and
accountability is required. The computerized protocol for anticoagulant therapy
essentially represents a standardized, sliding scale nledication schedule for
administering heparin and Coumadin. Therefore, documentation and paper copies of
all tnedication and lab orders should not be required for the computer protocol any
more than they would be required for a physician ordered sliding scale. The solution
employed for the computerized protocol for anticoagulant therapy was to generate a
printout of the initial protocol order set along with the sliding scale parameters for
Coumadin and heparin dosing. This printout required a physician signature and
became the only paper document in the medical record for the protocol.
Special Circumstances and Events
33
Administration of a computerized protocol will undoubtedly involve special
circumstances and events that can potentially interrupt the normal process and create
confusion for both the computer and end user. One issue that needs to be addressed
for the protocol to operate with maximum automation and minimal oversight is how to
temporarily suspend a patient from the protocol and then reenroJ] him. Complete
initiation of the protocol involving generation of the initial order set and physician
sign-off would not be necessary for reenrollment after protocol suspension. Similar to
this issue is the problem of how to enroll a patient who may already have been started
on therapy. Under this scenario, an initial order set would need to be generated and
signed by the physician but certain initial orders would be inappropriate such as
baseline labs, initial heparin bolus, and initial heparin drip rate.
Another extremely important issue is how to continue administration of the
protocol in the event of computer system failure. The two primary types of computer
failure that need to be addressed are total system failure (scheduled and unscheduled
downtime) and data drive failure resulting in alerts not being generated when they
should. Managing the protocol during computer downtime is probably the less
difficult of the two events to manage. For the anticoagulant therapy protocol, the
adopted policy for downtime is silnply to follow the prescribed protocol instructions
manually and chart medications using standard procedures. When the system comes
back up, special care must be taken to acknowledge order sets consistent with what
34
was already done clinically. Policies for operation when the data drive system fails is
more problenlatic. First of aU, detecting data drive failure is difficult because the
problem will not generally cause a system shutdown. Rather, the computer system
will continue to operate but alerts won't be generated when a lab value is reported as
expected. Once the problenl is identified, how should it be addressed? Should a
pseudo order that represents what should have happened be manually generated and
acknowledged? How do you document an event not occurring?
Data Storage and Record Keeping
Planning data collection and storage requirements should begin early in the
computerized protocol design process. Consideration should be given to what
Ineasurement variables will be needed to evaluate the effectiveness of the protocol.
Two types of effectiveness measures identified for this protocol include cornpliance
with protocol instructions and clinical outcome of the conlputer prescribed therapy.
Clearly Inedication charting data including medication dose and time given should be
collected as well as all laboratory results that may be used to evaluate effectiveness of
treatment. Data generated directly as a by product of the computerized protocol
process should be collected including stratification and risk assessment information,
person acknowledging order, order post time, order acknowledge time, disposition of
order (accepted or rejected), reasons for rejection, and data upon which order is based.
Description of System
Computerized Protocol Process Overview
35
EnroJiment on the computerized protocol for anticoagulant therapy is
accomplished by assigning a problem of DVT to the patient through a special HELP
application called the Problem List Manager. The Problem List Manager is an
implementation of a problem oriented medical record approach to managing patient
care and is designed to be used by physicians. When a problem of DVT is assigned,
the system prompts the physician with a message indicating that a computerized
protocol for treatnlent of DVT is available and may be "considered" for use by
proceeding. If the physician wishes to proceed, he is then presented with a risk
assessment questionnaire which stratifies the patient into either a high or low risk for
bleeding protocol. Figure 2 is a display of the computerized risk assessment. Once
the patient is stratified to a risk group, the physician is presented with a scrollable
window that outlines the initial order set and protocol instructions for adjusting
heparin and Counladin based on PTT and INR lab values, respectively. At this point
the physician may choose to either accept placement on protocol or not place on
protocoL If the physician chooses to accept placement on the protocol, a copy of the
initial order set and protocol instructions is printed. This printout requires a physician
signature and beconles the official and only physician order document for the medical
record. A sample printout of the initial order set is presented in Figure 3.
While the initial order set is being printed, the computer is busy generating
each order in the alerting subsystem. Fifteen initial orders are processed and
---------_._--- --~-~ --- .. --.----------------~ --------- ----------- ---.--
Name: TEST, PULM OR Pat ient B: 35527 Room: l,J836
Figure 2. Computerized Risk Assessment W 0'\
P,llient Name: TEST, PULM rm PhY,3Lcian: Dal e: 04 /2 1 / 9 4 Time; 1 'I : J 1 Poom: N910
Patient n: 3552'1 l-1edical H(~,' II:
* ~ * * * * * DVT II I GH R 1 K PR,OTOCOL FOR ANTI COAGULANT THERAPY * * * * * * *
PatIent placed on 11igh risk protocol with following high risk conditions:
Major trauma within the last two weeks Bleeding requiring transfusion within the last 8 weeks PATIENT IS ANEMIC
The initial DVT management orders for high risk will be:
(1) Initial labs before starti.ng heparin or Coumadin: CBC without Diff, SMAC PTT and PT (STAT Class ])
37
o
(2) PTT- 6hrs after IV start and each change in heparin therapy (STAT Class 3 (3) Daily labs: PT, PTT, CBC
Nursing to coordinate AM lab draws with scheduled PTT (4) Mark lab cards: "Phlebotomist to check with RN prior to draw" (5) Heparin bolus, 5000 u IV, after initial labs are drawn (6) Start heparin via IV drip at 1240 u/hr (31 cc/hr)
Premixed heparin solution (20,000 units in 500 cc DSW) (7) Coumadin, 2.5-10 mg per SS, PO, QD @ 1400 - beginning tomorrow (8) Bedrest with BRP only (no showers) (9) Guiac all stools
(10) DC all '-'lrrent heparin orders
Heparin dosage will be adjusted based on PTT value:
PTT < 45 (a) rebolus with IV heparin 3,000 u (b) increase current drip rate by 240 u/hr ( 6 cc/hr)
PTT 46 to 54 (a) increase current drip rate by 120 u/hr ( 3 cc/hr) PTT 55 to 85 (a) no change in therapy (therapeutic range) PTT 86 to 110 (a) stop heparin drip for 1 hour
(b) restart heparin drip, decreasing by PTT ::> llO (a) stop heparin drip for 1 hour
(b) restart heparin drip, decreasing by
Coumadin dosage will be adjusted based on PT INR value:
INR < 1.5 give coumadin 10 mg po INR 1.5 to 1.9 give coumadin 7.5 mg po INR 2.0 to 2.3 give coumadin 5.0 mg po INR 2.4 to 3.0 give coumadin 2.5 mg po INR > 3.0 hold coumadin
I authorize patient to be placed on protocol.
Physician signature:
FOR ASSISTANCE USING THE PROTOCOL PLEASE CONTACT:
Pulmonary Research Nurse NIS Coordinator Medical Informatics Staff C. Gregory Elliott, MD (project director)
Digital Pager Digital Pager Voice Pager Digital Pager
MEDICAL RECORD COpy
Figure 3. Medical Record Copy of Initial Order Set Printout
120
240
u/hr ( 3
u/hr (6
249-3548 249-4241 0390 249-4529
cC,hr)
cc/hr)
38
sent to both division terminals and the patient bedside terminal. Nurses arc notified of
pending orders for the patient via the paging system. Additionally, a red flashing "A"
will be presented at all division terminals and at the bedside terminal indicating the
presence of pending orders. Initial orders are acknowledged both by the ward clerk
and by the nurse. The ward clerk simply checks oIl on the paper printout that she has
reviewed all initial orders and processed the ones for which she is responsible. The
nurse is required to go to the computer and press function key F6 to review and
acknowledge each order displayed in the computer. The initial order set as presented
in the computer is displayed in Figure 4. Acknowledgement of an order requires
either accepting or rejecting the order. If an order is accepted it should be
immediately carried out. If it is rejected, the physician should usually be contacted
and a reason for rejection provided.
All subsequent medication change orders arc generated autoll1<.ltically by the
computer's data drive system hased 011 PTT and LNR values returned by the laboratory
system. Notification and acknowledgement of computer orders proceeds in the same
fashion as for initial orders. However, the generation of medication change orders is
more comrlex because of the data drive mechanism. For a correct heparin change
order to be generated the system must search the database to find the correct PTT
vallie and the correct current heparin drip rate. Coumadin orders depend only on
finding the correct INR value. Figure 5 is a now chaIt that describes the overall
system process or running the computerized anLicoagulant therapy protocol.
39
~ .-
-C';j .-...... . -~ -
Start
Give Reject Reasons
Save Orders to Patient Database
Problem List l\lanager
Risk Assessment
Display Initial Order Set
Display Order Set
Generate Order(s) HeparinlCoumadin
Chart Meds Manuall Auto
Drip Rate
Figure 5. System Flow Chart of Anticoagulant Therapy Protocol Process
Printout of Initial Order Set
PTT
PT
Save Orders to Patient Database
Schedule Labs
..J::>.. o
41
Special Features of System
Several special features and system enhancements were incorporated into the
computerized protocol to create a robust system that had the best chance of succeeding
in a live clinical environment. The computerized anticoagulant therapy protocol is the
first protocol to be developed and installed in a genera] medical/surgical ward at LDS
Hospital. Operation in a general med/surg ward presents some unique challenges
because it is a much less controlled and monitored environment than an intensive care
unit. For this reason, special steps had to be taken to ensure that processes critical to
the operation of the COITIputerized protocol were carried out. Also, implementation
team members had a vested interest in garnering user acceptance and, therefore, took
steps to incorporate value added features that would make the nurses job easier rather
than adding complexity and confusion to an already complex process.
Nurses are expected to utilize the HELP medication charting system to chart all
medications and IVs given to patients. Early in the development of the conlputerized
protocol it became apparent that medication charting was not done consistently and
that charting of IV rates was sporadic at best. Since the computerized protocol relied
upon the presence of heparin IV charting data to generate heparin change orders, the
neglecting to chart even one heparin drip rate was unacceptable. Therefore, a solution
was developed whereby accepting a computerized heparin IV order would
autonlatically schedule the medication in the pharmacy system and chart the new rate
in the medication charting system. This was a fairly simple process since an the
information necessary for charting was available in the computer generated order
except for the chart time. This feature also saves nurses the time and trouble of
manually going into the medication charting system after leaving the order review
screen to chart the medication. Although utilizing this automatic chalting feature is
optional, we believe that nurses will rarely choose to chart manually given the ease
and sinlplicity of automatic charting.
42
The solution for notifying nurses of pending orders employs paging nurses via
the ward paging system whenever a new order is posted. This required development
of a complex interface between the Tandem mainframe computer that runs HELP and
the pager systelu. The original solution involved sending alerts only to division
terminals and requiring ward clerks to monitor incoming orders and notify the nurse.
Utilizing the paging system is a much more direct notification process that involves
scnding a message of "Anticoag Order" which may be viewed on the LCD display of
the digital pager. The patient room and time the order was posted are also displayed.
The paging system will periodically repage the nurse until the nurse reviews the
pending orders in the computer.
A great deal of discussion surrounded the issue of what additional information
should be displayed with the computer order to aid in the decision making process of
whether to accept or reject an order. The solution that was developed involves
displaying two types of information directly with the order: based-on data, and
warnings. Based-on data include the data that drove the alert and that were used in
the logic to process the order. The information presented with heparin change orders
includes the PTT lab value and the current heparin IV rate. The information presented
with Couluadin orders includes the INR lab value. Currently, for each heparin order
generated logic is invoked to determine if two possible warnings should be generated
43
with the order. If a PTT is reported within 4 hours of the last PTT, it is considered to
be been ordered outside protocol guidelines and a warning is displayed. Similarly, a
warning is generated if a PTT is returned within the last 4 hours of a change in IV
heparin therapy. If this event occurs, the lab value is considered to be potentia))y
erroneous both because a steady coagulation state may not yet have been reached and
the lab was likely ordered outside of protocol guidelines. A sample heparin change
order is presented in Figure 6 with based-on information and warnings.
Special consideration was given to the process of rejecting alel1s to facilitate
tracking compliance with the protocol and documenting events where the protocol
logic failed or was inappropriate. If an aielt is rejected, users are required to indicate
a reason for rejecting by selecting frOill a list of standard reject reasons that include a
free text entry. If a physician directs that an order be rejected, the nurse is required to
identify the physician. Figure 7 shows the computer screen presented to the user for
selecting reject reasons. If the reason for rejecting an order is because the last heparin
drip rate was incorrect, the system provides a mechanism for correcting the rate and
regenerating a new order based on the new rate. This situation could potentially occur
if, for some reason, the nurse fails to chart a heparin drip rate in the computer.
Basic feedback information is available by invoking an order review history
function that defaults to displaying all orders acknowledged within the last 24 hours.
Detail information may be requested on individual orders showing such details as
based-on infonnation, warnings, acknowledge person, alert post tilne, and reject
reasons. The default 24-hour time range may be changed to renect a user defined
TEST, PULM DR 35527 lJ836 J 11/82/93 33Y F r.===========ALERT SELECT ION INSTRUCT IONSi=, ============n Select item numberlr~ange and action (A=Accept R=Reject):
Example: 1-4 A, 6-7 R, 11A <F7>=Or~der~ Histot~y <F8>=Lab <F9>=ChrtM <SF9>=MedEdit
Figure 6. Heparin Change Order as Presented in the Computer ~ ~
45
46
time period and the review history may be sent to a laser printer. A sample printout
of a 24-hour alert review history is presented in Figure 8.
Areas for Further System Enhancement
Time Drive
The systetTI could be enhanced significantly if HELP supported the capability
to manage time driven events. For example, the heparin change order for a PTT of
100 and a current drip rate of 1120 units/hr is as follows:
I) Stop heparin for I hour 2) Restart heparin at ] 000 units/hr
Currently, both of these orders are generated at the same tinle by the data drive
process when a PTT is reported in the HELP database. The acknowledgement policy
is to accept and follow order # I and then come back in 1 hour and accept and follow
order #2. However, the nurse is not notified or reminded in any way to acknowledge
#2 in I hour after initially dispensing with # I. A more elegant method would be to
invoke a time drive process when the nurse charts the stop heparin order to generate
the restart heparin order 1 hour from the chart time.
Interface to Order Communications
LDS Hospital is currently planning the installation of an Order
COlnmunications System for autolnated order entry of all types of orders including
laboratory and pharnlacy. Clearly, having an interface to Order Communications will
facilitate operation of the computerized protocol especially with regard to PTT and PT
laboratory tests. For example, rather than sending the order for a follow-up PTT in 6
47
hours to a terminal for nurse acknowledgement, the order would go directly to the
laboratory system for processing.
Use of MIB for Automatic Charting of Heparin Dose
48
Accurate and consistent charting of medications in the computer system is a
continuing problem at LDS Hospital. Computerized protocols are particularly sensitive
and vulnerable to missing charting data since this data is often used in the logic to
process instructions. For the computerized anticoagulant therapy protocol, utilizing the
medical information bus (MIB) for automatic capturing of IV drip rate data from the
IV AC pumps could potentially serve to improve the accuracy and consistency of
information. However, establishing the MIB interface and policies and procedures for
data capture is not a trivial process and should be implemented with deliberate and
careful planning.
Improved Application Development Tools
In recent years, the state-of-the art in cornputer application development tools
has advanced considerably. Although the application development tools at our
disposal for this project enabled us to build a fairly robust system, use of modern
object oriented programming languages and techniques would have facilitated the
developlnent of a more generic and extensible system for computerized managenlent
of protocols. One could easily envision representing alerts as objects utilizing pointers
to encapsulate based-on data, and to associate the charted medication rate with the
order that prescribed the rate change. Although object oriented database systems
represent a new and somewhat emerging model for representing persistent data, they
hoJd promise as an efficient and nleanlngful way to manage and represent medical
information.
49
EXPERIENCE
At the time of this writing, we have enrolled a total of seven patients on the
computerized protocol. We experienced several system problems during this ear1y
stage of implementation. The problems were prinlarily in two areas: I) orders not
being generated when expected, and 2) duplicate orders being generated. Fortunately,
we discovered a software error that was causing orders not to be generated when
expected and this problem has been corrected. However, the problem with duplicate
orders being generated is still being investigated. We have written a subroutine that
detects duplicate orders and rejects the order in the background with the reason
"duplicate order." This approach ensures duplicate orders are not presented to the
user.
These system problems have hampered our ability to measure the effectiveness
of the computerized protocol. Because of the potentially serious implications
associated with orders not being generated and the confusion created by duplicate
orders, use of the conlputerized protocol has required vigiJant monitoring by nursing
informatics and research nursing staff. Our goal is to achieve sufficient systenl
robustness so that the computerized protocol can operate in a relatively unattended
mode on an active clinical nursing unit. Only at this stage can we measure the
effectiveness of using a computerized system for anticoagulant therapy compared to
non-protocol-assisted therapy.
51
Because of the inconsistent behavior of the system, nurses were asked to verify
computer generated orders against a paper protocol. In essense, patients were
receiving protocol-directed therapy, but not relying on computer assistance. The third
and fourth enrolled patients were taken off the computerized protocol shortly after
being enrolled and nurses were instructed to reject all computerized protocol orders
giving the reason "patient on paper protocoL" By the time of our fifth patient, we had
corrected the system problems. For this patient, the entire course of therapy was
guided by the computerized protocoL This patient was successfully anticoagulated,
achieving a therapeutic PTT of 79 sec 23.3 hours after placement on the protocol. For
our sixth patient, we had a major system problem and no computer orders were
generated. The seventh and last patient placed on the protocol was hypersensitive to
heparin and had to be taken off the protocol shortly after therapy commenced.
For the seven patients placed on the protocol, a total of 215 orders were
generated by the computer and acknowledged. Of these, 64 (30 percent) were rejected
and 2] 5 accepted. Orders were rejected for a variety of reasons but mostly because
patients were placed on the paper protocol. Tables 3 and 4 summarize the reasons
given for rejecting orders. For some orders, more than one reject reason wasindicated.
These figures do not completely reflect the problem experienced with duplicate orders.
For the first two patients, severa] duplicate orders were generated and users
acknowledged and accepted them. We later made a policy that the appropriate way to
handle duplicate orders is to reject them giving a reason of "duplicate order." As
mentioned above, duplicate orders are currently acknowledged and rejected
automatically in the background. Capturing and analyzing reject reasons is an
Table 3. Reject Reasons for Heparin Drip and PTT Lab Orders
Reject Reason
Directed by physician Lab value drawn too soon Last heparin drip rate incorrect Patient put on paper protocol Duplicate order Patient taken off protocol Unknown
TOTAL
Table 4. Reject Reasons for Coumadin Orders
Reject Rea'ion
Second order for the day Patient put on paper protocol Patient being discharged Directed by physician Patient taken off protocol Unknown
TOTAL
Count
6 6 2
28 5
11 _I
59
Count
3 5 2 1 2
_1
14
important part of the protocol monitoring and refining process. Once the protocol is
stable and running in an unattended mode, reject reason analysis will be a primary
111echanism for identifying process and logic inconsistencies.
52
SUMMARY AND CONCLUSIONS
This project has shown that the implementation of computerized protocols for
specific therapy is feasible in a busy general medical/surgical ward. Choosing a
clinical domain that used a simple algorithm relying mostly on available, objective
clinical data certainly contributed towards its success. Computerized protocol
development is a classic exercise in team work and knowledge sharing. Without input
and cooperation from experts in many diverse fields, this project could never have
been completed. Despite the protocol's simplicity, the implementation team faced a
myriad of implementation issues that required multiple revisions to the software and
multiple phases of testing before it was ready for patient enrollment. While lessons
can certainly be learned from our experience, computerization of other protocols will
probably have their own unique set of issues and challenges. Only through
cooperative teamwork and organized leadership can a protocol computerization project
be successful. Although the process of protocol implementation is time consuming
requiring attention to many details, the reward can be establishing a system that
reduces variation in treatment, enhances work f1ow, and improves quality.
REFERENCES
I. Putting the T in Health Care TQM: A GoallQPC Health Care Application Research Conlmittee Report. Methuen, MA: GoaIlQPC, 1992; 84.
2. Berwick, OM. Continuous Improvenlent as an Ideal in Health Care. New England Journal of Medicine 1989; 320:55-56.
3. James, BC. Quality Measurement and Management Project: Quality Management for Health Care Delivery. Chicago: The Hospital Research and Educational Trust, 1989; 11-12.
4. James, BC. 28-32.
5. AHCPR Program Note: Medical Effectiveness Research. Washington, D.C.: AHCPR, March 1990. (AHCPR Publication No. OM90-0059.)
6. Clinton, JJ. AHCPR Research Activities: Special Guideline Edition: Overview. AHCPR, March 1992. (AHCPR Publication No. AHCPR92-0043.)
7. Health Security Act of 1993: Title V: Subtitle A. Washington D.C.: U.S. Printing Office, 1993; 824.
8. Health Security Act of 1993; 833-835.
9. East TO, Bohm SH, Wallace JC, et al. A Successful Computerized Protocol for Clinical Management of Pressure Control Inverse Ratio Ventilation in ARDS Patients. Chest 1992; 101: 697-710.
10. Classen DC, Evans RS, Pestotnik SL, Horn SD, Menlove RL, Burke JP. The Timing of Prophylactic Administration of Antibiotics and the Risk of Surgical-Wound Infections. N Engl J Med 1992; 326: 281-286.
I I. Moser KM. Venous Thromboembolism. Am Rev Respir Dis 1990; 14]: 235-249.
12. HuH RD, Raskob GE, Rosenbloom 0, et ai. Optimal Therapeutic Level of Heparin Therapy in Patients With Venous Thrombosis. Arch Intern Med 1992; 142: 1589-1595.
13. Elliott, CG, Hiltunen SJ, Sucyhta M, Hull RD, Raskob GE, et al. Physician Guided Treatment Compared with A Heparin Protocol for Deep Vein Thrombosis. (Manuscript in Preparation: LDS Hospital Pulmonary Division, Salt Lake City).
55