Protocol-Directed Care

Bruce I. Blum Introduction

This chapter discusses the use of the OCIS in the preparation of daily care plans that recommend clinical actions based on predefined protocols. There are relatively few clinical information systems that provide this type of support, and therefore this chapter addresses three issues: What is meant by protocol-directed care? What is the design of an “ideal” system? How does the OCIS support this function? The perspective is limited to the needs of the Oncology Center.1

The term protocol simply means a set of formal rules. It is frequently used in the context of diplomacy or etiquette. There also are electronic communication protocols that define the rules for interaction among devices. In the medical environment, the term may be used in a variety of ways. The following are the most common usages in the Oncology Center.

Research Protocol. The basic model for clinical research relies on an e^efiment in which a hypothesis is tested. An essentially homogeneous sample of patients is selected, and a formal therapeutic plan is designed; the plan changes only a limited number of variables in order to test the validity of the hypothesis. Although randomly introduced biases cannot be avoided, the protocol is designed to control potentially confounding factors, such as age and stage of disease.

One may view the research protocol as a formal algorithm for treatment. It includes the criteria for accepting a patient for treatment under the protocol and for evaluating the outcome of the treatment. The protocol typically is recorded in a document of up to 60 pages. A diagrammatic representation of the therapy organization, called the schema, is prepared to represent the salient features of the document for easy reference.

'For a more general discussion of this topic see B. I. Blum, Clinical Information Systems, SpringerVerlag, New York, 1986. This book also contains a chapter on the OCIS in which the database structures for the daily care plan system are described.

At the Oncology Center there are about 100 research protocols active at any time. These include cooperative national studies, in which the data are periodically transcribed and sent to a central processing facility, and local protocols that are managed within the Oncology Center. There is a Johns Hopkins protocol committee that must approve each study before it is put into clinical use.

Individual Therapy. In many cases, the essential features of a research protocol are to be followed for a patient who does not quality for admission into the study. In this case the research protocol is modified to meet the individual needs of the patient; this modification typically invalidates the use of any outcome data in the subsequent protocol analysis.

A second form of individual therapy involves the modification of standard treatment plans (as opposed to a research protocol) to accommodate individual needs.

General Clinical Support. The preceding two classes of protocol are generally restricted to antitumor therapy and responses to the side effects of that treatment. In some cases the responses to the side effects can be isolated as independent protocols. Examples are clinical responses to infection (which are almost always an integral part of a research protocol), pain, nausea, and low platelet counts (described in Chapter 7).

A generalization of the clinical support protocols are the standard treatment protocols that have been established as baseline plans for dealing with a medical problem. These problems normally are not related directly to the antitumor treatments. Most alert and reminder systems are concerned with this type of protocol.

Disease-Specific Follow-Up. There is the need for the management of long-term patient follow-up. This follow-up is related to the patient’s diagnosis. Examples include 6-month chest x-ray studies for breast cancer patients and 3-month monitoring of serum protein electrophoresis for certain multiple myeloma patients.

In most clinical settings, these protocols are managed by the clinician, who draws upon memory with occasional references to a written guideline. The problems with this approach have been well documented. For example, McDonald has shown how reminders alter physician behavior, especially with respect to clinically significant changes in therapeutics; the HELP system alerts have identified life-threatening drug-drug interactions that were subsequently altered for 1.8% of the hospital’s patients. Wirtshafter and Mesel implemented an algorithm-based breast cancer consultant extender that produced a 95% compliance rate from 75 local physicians, in contrast to a 64% compliance rate from the cancer center physicians.

As already described in Chapter 2, there is too much information to be managed in a stressful, time-sensitive clinical setting. The physician needs help in anticipating problems to avoid being in a position of reacting to a critical medical situation. In the case of therapeutic plans that involve the use of highly toxic drugs in combinations over an extended period of time, the physician requires tools to help ensure that the proper sequence is followed. (For example, phar-

micokenetic studies have shown that some drugs should be administered in two doses a precise number of hours or days apart; failure to adhere to this schedule will diminish the response.) Finally, in managing the care of a large number of patients with similar diseases, therapies, and problems, the physician requires tools to help identify the needs of each individual patient.

There are several approaches to providing this automated support. The remainder of this chapter describes the approach taken by the OCIS. This section concludes by briefly identifying some alternative methods. First, one can formalize the protocol as an algorithm. This may be done by using a form or checklist (e.g., the initial consultant extender) or coding the protocol as a program in a special protocol language (e.g., the extension of that concept by Gams). One also can combine orders into a block to be managed as a single unit (e.g., the use of protocols in the context of compound orders with the Technicon MIS). Next, one can formalize the protocol as a sequence of (often repeated) actions and print out extended plans and schedules (e.g., the systems of R. B. Friedman at Wisconsin University and R. H. Friedman at Boston University). Finally, one can treat the issue as an artificial intelligence problem, as Shortliffe and his colleagues have done with ONCOCIN.

The constraints placed upon the OCIS approach were that it be considered first and foremost a tool for supporting medical decision making in a large clinical setting. Therefore, it had to be easy to use and learn, understandable, low in risk, and natural to both the senior faculty (the researchers who define the protocols) and the health care providers (the house staff, nurses, physician assistants, etc., who must respond to the recommendations). In summary, the support for protocol-directed care had to use proven technology and be pragmatic in the selection of functions to be implemented. The design of a daily care plan facility was not considered a research activity; there was no research financial support for it. The clinical users were not interested in medical computing; their acceptance of a product and their patience in critiquing the evolving tools were directly related to their perception of the function’s utility in a clinical setting.

There is an interesting contrast between the OCIS approach and that of ONCOCIN. In the case of the latter, there is a clinical evaluation of a system that exploits artificial intelligence techniques, adds to our knowledge of medical informatics and computer science, and has the potential for going beyond the protocols that can be reduced to algorithms. In the case of the OCIS, on the other hand, a tool was designed for a specific environment, and its utility and evaluation were constrained by the local needs of that environment. Even though the goals and techniques differ, each contributes to our knowledge.

The Overall Design This section presents the general design of the daily care plan system. As suggested in Chapter 3, one develops a system first by building a conceptual model of how it should operate, then by translating that concept into a specific (and often incomplete) implementation, and finally by refining the model as the result of operational experience. Naturally, the process is iterative. The general design to be presented in this section is the conceptual model and its initial implementation; the topic of the next section is a description of the system as it is used operationally. There are differences between the two sections. Some parts of the conceptual model were never used in an operational setting. Some parts of the operational system (which are considered to be of great value) are not really part of the conceptual model. Thus, what follows here is limited to a systems analysis of the problem; the implementation experience is described in the next section.

When work on the OCIS first began, it was a given fact that the system would manage a clinical database that could support both the display of data and the recommendation of therapeutic actions. The early perceptions of the Oncology Center founders were that most of the clinical care in the new center either was managed by protocol or could be so organized. Therefore, a database that contained all the clinical data and the protocol rules could be referenced to print out, for each inpatient day and outpatient visit, a list of all the protocol recommended actions. The provider would then be able to base his or her orders on this plan. The following section will temper these assumptions with the results of operational experience, but for now the presentation will consider the problem from a higher, more abstract perspective on the basis of this assumption.

Organization of the Protocol Figure 1 contains the schema for a 1976 Eastern Cooperative Group protocol for the treatment of advanced stages of Hodgkin’s Disease. There is an induction phase in which the patient undergoes six cycles (repetitions) of treatment with a combination of five drugs. The note at the bottom identifies the drugs, doses, and special instructors. At the end of the sixth cycle, if there is a complete response (CR) or partial response (PR), then one of two other regimens is followed. Either the patient is treated with three cycles of four drugs or radiotherapy is begun. The final outcome is then evaluated.

In this particular schema the flow is straightforward and relatively easy to explain. Note that the therapy extends over a long period of time (6 x 28 days plus 3 x 35 days for about 9 months). Thus the physician must know what protocol the patient is on, what branch of the protocol, what cycle within the branch, and what day within the cycle. Different clinical decisions will require different knowledge of the patient’s status with respect to the protocol.

Information implicit in this protocol includes the criteria for accepting a patient into the study, definitions of CR, PR, etc., for protocol evaluation, definition of the stratification process, and the therapy details referenced in section 5 of the protocol. Of considerable importance is the detailing of what should be done if the drugs produce toxic reactions. Such toxicity is common in the aggressive treatment of cancer with drugs that are used in combinations powerful enough to destroy the diseased cells. Too low a dosage will have no impact on the tumor

Figure 1. Schema for Eastern Cooperative Oncology Group Protocol 1476.

; too high a dosage may threaten the life of the patient. Consequently, toxic effects must be recognized promptly, and drug dosage adjusted accordingly.

From this brief description of the schema, it can be seen that a protocol can be decomposed into the following components:

Descriptive Information. Descriptive information is textual information about the protocol that is best maintained in a descriptive fashion. It is referenced when the protocol is first used and is consulted periodically. It is seldom used in the making of clinical decisions. (The schema is designed to provide general reminders and guidelines.)

Therapy Regimen. A therapy regimen is a summary of the treatment to be given as a block over an extended period of time. Associated with the administration of drugs is the ordering of tests to monitor the patient’s status and provide early warnings of toxic reactions and responses to treatment.

Formal Rules. Formal rules is the set of rules that describe the relationships among the therapy regimens, the dose modifications in response to observed toxic reactions, the stratification criteria, etc. All formal rules, by definition, can be defined algorithmically. The therapy regimen is a special case of a formal rule; all such rules (when they reliably reflect actual practice) can be automated.

Given this representation of the protocol, it can be seen that one system design for protocol-directed care would structure its database to provide access to:

Protocol Description. Protocol description would make the protocol information available on line and in printed form. Access from the various clinical terminals would offer a valuable reference for medical decision making. In a truly closed system the protocol would be defined on the computer, and a printed listing would replace the standard document.

Treatment Sequences. Treatment sequences would contain all the therapy regimens in a formal language. They would identify what drugs to administer, what tests to order, what reminders to print, etc. The sequences would be decomposed into small cohesive blocks, and a single regimen might be expressed as more than one treatment sequence. Thus, a patient’s care might be determined by multiples of such treatment sequences.

Schema. A schema is essentially a directed graph (or program) that links the treatment sequences and cycles within a protocol. At the conclusion of a treatment cycle the schema would be able to determine which treatment sequences to terminate and which options were available to the physician. Once the physician chose an option, the appropriate treatment sequences would be initiated.

Dose Modification. Criteria formalize responses to toxicity. Some criteria could be stated formally, for example, if the white blood cell count were to fall below a given value, then the dosage of certain drugs would be reduced by 50%. Other criteria would result in the printing of a warning to the physician to take some appropriate action.

Supporting Information. Identifies the contents of the clinical database that would be useful in the management of patients on this protocol. Some of this information would be presented in the form of the data displays described in Chapter 4; other information would be presented as a part of the care plan.

This is the view that the OCIS implemented in its protocol-directed care facility.

Processing Flow The OCIS database maintains protocol descriptions containing the preceding information, together with the clinical data for each patient on a protocol. Therefore, the system should be able to access the protocol data and create a general plan for each patient. To do this, the OCIS uses the following processing flow:

Enter Patient on Protocol The patient is entered on a protocol by means of a communication with the research office. (For individual therapy, no such coordination is required.) From the perspective of the protocol-directed care function, entering the patient results in associating one or more treatment sequences with the patient. For example, a common practice is to enter the therapy for the first cycle of treatment, a sequence for long-term follow-up, and a sequence for followup related to the anticipated inpatient stay. These sequences become the patient’s standing orders.

Prepare Daily Care Plan. For inpatients, every morning the standing orders for each patient are processed, and a plan that identifies all therapies, tests, and reminders scheduled for that day is prepared. These are printed out in the various daily care plan formats. The processing also eliminates redundant tests. For example, if one treatment sequence requires a complete blood count (CBC) every two days (Q2D) and another requires a CBC Q3D, then the second request is never invoked. This allows physicians to define minimum criteria for each clinical situation independently and without concern for overutilization.

Review and Distribute Orders. Once the patient’s treatment sequences are processed, the daily care plans are printed and distributed to the clinical areas. Several formats are provided: for the physician, for the nurses and physician assistants, for the attending physicians, and for the unit clerk. The plans represent the protocol recommendations. (The extended definition of protocol is used here; it includes inidividual therapy, clinical support, and follow-up.) The plans are amended as necessary, and the unit clerk plan serves as an order guide.

Record Actions. Because the care plan must relate to the patient’s current status, it is essential that the actions of the previous plan be known before the next plan can be printed. For example, if a CBC was processed the previous day, then a sequence containing the order for CBC Q2D would not initiate a CBC order. On the order hand, of course, if the CBC was not ordered the previous day, then a request must be made for such a test order. In some cases, such as the CBC, it is possible to determine the status from the clinical data; in other cases, such as the reminder to read a skin test, a manual entry is required to close the loop.

In actual practice, as described in the following section, each morning the data coordinators enter the previous night’s actions, and the plans are produced for distribution near noon. Treatment sequence changes are normally made after morning rounds and processed asynchronously. When the treatment sequences change a patient’s standing orders, new plans are produced on demand.

Figure 2 represents an overview of this flow and system organization. Although the flow is quite simple, there are many problems in translating the conceptual model into operational use. The remainder of this section discusses how some of those problems were solved technically and/or operationally.

The Protocol Description From a technical point of view, the management of the protocol description was quite simple. The development environment (TEDIUM2) provided a text processor and text data type; building a tool to manage the description was straightforward. The protocol was divided into the following sections:

Identification. This contains the protocol identifier, the principal investigators, and key administrative dates associated with its use. This coded information is also shared with the Research Office programs.

General Description. This is a short (one- or two-page) overview of the protocol. It serves as an abstract and simple reminder of the protocol structure.

Patient Selection. This is a text description of the selection criteria. It also includes an explicit list of exclusions.

Evaluation Criteria. This is a text description of the evaluation criteria.

Dose Modification. This is either a tabular display of the dose modification or a description of the modification. The tabular display is managed internally so that a computer program can identify the test results and drugs to be modified; by use of this information, the dose recommendations in the daily care plan can be

2TEDIUM is a trademark of Tedious Enterprises, Inc.

Figure 2,

Figure 3a.

Johns Hopkins Oncology Center 06/23/88

E5181 ADJUVANT/OPERABLE N(+)

DOSE MODIFICATIONS for E5181 ADJUVANT/OPERABLE N(+):

RENAL 2

(RENAL DYSFUNCTION)

MTX

CYTX

5FU

PRED

TAMO

CREATININE

<1.3

100%

100%

100%

100%

100%

CREATININE

1.3 - 2.0

50%

100%

100%

100%

100%

CREATININE

2.1 - 3.5*

OMIT

100%

100%

100%

100%

CREATININE

> 3.5*

OMIT

OMIT

OMIT

100%

100%

RENAL 1

(RENAL 1)

RENAL

DYSFUNCTION

ADRA

THIO

VELB

PRED

TAMO

CREATININE

<1.3

100%

100%

100%

100%

100%

CREATININE

1.3 - 2.0

100%

100%

100%

100%

100%

CREATININE

2.1 - 3.5*

100%

100%

100%

100%

100%

CREATININE

>3.5*

OMIT

OMIT

OMIT

100%

100%

HEM TOX 4 (HEM TOXICITY)

PLTS AND WBC DOSE MODIFICATION

TABLE

CYTX

MTX

5FU

TAMO

PRED

PLTS>100KrWBC>4000

100%

100%

100%

100%

100%

PLTS>100K:WBC2500-4000

50%

50%

50%

100%

100%

PLTS>100K:WBC<2500

OMIT

OMIT

OMIT

100%

100%

PLTS 75K-100K: WB04000

50%

50%

50%

100%

100%

PLTS 75K-100K: WBC 2500-4000

50%

50%

50%

100%

100%

PLTS 75K-100K: WBC <2500

OMIT

OMIT

OMIT

100%

100%

PLTS <75K:WBC >4000

OMIT

OMIT

OMIT

100%

100%

PLTS <75K:WBC 2500-4000

OMIT

OMIT

OMIT

100%

100%

PLTS <75K: WBC <2500

OMIT

OMIT

OMIT

100%

100%

CYTX TOX (CYTOXAN TOXICITY)

ALL PATIENTS SHOULD BE INSTRUCTED ON THE IMPORTANCE OF VIGOROUS HYDRATION DURING CYTOXAN THERAPY. IF HEMORRHAGIC CYSTITIS SHOULD OCCUR DESPITE VIGOROUS HYDRATION, CYTOXAN SHOULD BE STOPPED AND SUBSEQUENT THERAPY MANAGED WITH MELPHALAN 4 MG/M2 PO DAYS 1 THROUGH 5 OF EACH TREATMENT CYCLE.

HEM TOX 3 (HEM TOX 3)

THIO

ADRA

VELB

TAMO

HALO

PLTS>100 K:WB04 000

100%

100%

100%

100%

100%

PLTS>100K:WBC 2500-4000

50%

50%

50%

100%

100%

PLTS>100 K:WBC<2500

OMIT

OMIT

OMIT

100%

100%

PLTS 75K-100K:WBC>4000

50%

50%

50%

100%

100%

PLTS 75K-100K:WBC 2500-4000

50%

50%

50%

100%

100%

PLTS 75K-100K: WBC<2500

OMIT

OMIT

OMIT

100%

100%

PLTS<75K :WBC>4000

OMIT

OMIT

OMIT

100%

100%

PLTS<75K :WBC 2500-4000

OMIT

OMIT

OMIT

100%

100%

PLTS<75K:WBC<2500

OMIT

OMIT

OMIT

100%

100%

Figure 3b,

altered to adjust for toxicity automatically. Where a tabular display does not exist, it often is possible to recognize when a warning message should be printed.

Protocol Schema. This is a formal language that describes the treatment sequence graph. It is managed as a text program and contains operators such as STOP seq and START seq. The format was never felt to be useful by the physicians, and, given the impact of a wrong decision, it was decided not to use the schema. Thus, although in the abstract the schema could produce reliable reminders and perhaps even automated support, such a tool was considered inappropriate in the clinical environment. Consequently, the development of a schema facility was terminated.

Figure 3 contains two pages from a protocol description. With the exception of the administrative data that were required for other purposes, the concept of online protocol definitions never matured. There were several reasons. First, the protocol had already been prepared in a typescript form, and the on-line description was redundant. It required reentry of the text plus an additional review by the principal investigators. Second, the tools used in development were primitive when compared with those now available in personal computers. Typewriters (rather than word processors) were the standard as the system was being developed. Without a strong demand for on-line access, the tool was seen as extra work for busy people. Finally, because there were so many protocols, many had few patients on study. One might argue that this would justify the need for on-line access to seldom-used protocols; however, the users perceived the definition of the automated form of the protocol to be a lot of work with a limited payoff.

The Treatment Sequences In some Darwinian sense the protocol descriptions (along with their automatic dose modifications and schema reminders) became extinct; the code remained, but the database atrophied. The treatment sequences, on the other hand, grew and flourished. In the very first prototypes, the treatment sequences were limited to the ordering of drugs and tests. The sequence could create orders cyclically (e.g., Q2D or Q1W), by day of week (e.g., M, W, F) or by day relative to the start of the treatment sequence (e.g., 1, 8).

The next iteration added features to deal with special situations. Because of operational considerations, for example, some labor-intensive tests might be ordered cyclically but should not be ordered on weekends or holidays. The standing orders had to accommodate this constraint. Warning messages were also added to the plans, and these were stratified by the audience (physician, nurse, physician assistant) and priority. Because many messages might be listed, there was a concern that important messages might become overlooked. These high-priority messages, therefore, were to be set aside and printed in a box.

In time, the treatment sequence functions matured. Ken Bakalar defined a language for specifying how the items were to be designated. Table 1 lists the key

Category

Illustration

Day of week

MT WHFSU

Odd or even day

E (any even day), ET (Tuesday if

(calendar day of the month)

an even day)

Cyclic

Q2D (every 2 days), Q3W (every 3 weeks)

Treatment sequence day

1, 3, 22, 56

Treatment sequence week

1W (day 1 to 7 of therapy if not

(use with outpatients)

Special operators (use with cyclic or sequence day)

* Not on weekends, use nearest weekday, e.g., *1 or *Q2D

+ Not on weekends, order on Monday — Not on weekends, order on Friday

# Order until verified, e.g., #12 > Order until canceled, e.g., > 4

/ Used to join conditions, i.e., and B or C indicates that the action begins or concludes on the given day

done previously)

definition rules, and Table 2 contains some example clauses. Liz McColligan defined a complex set of dictionaries that provided linkage between the plans and the clinical data. At the highest level, the terms used in the orders were the same, but there was a complication in going from the ordering of tests to the processing of test results. For example, a CBC includes a white blood cell count (WBC). Thus a treatment sequence for WBC Q2D should not initiate an order request if a CBC was ordered the previous (or current) day. Conversely, knowing that there is a WBC value may not provide information about the ordering of a CBC. Other Table 2. Sample Illustrations of Repeat Clauses

Clause

Interpretation

1, 2, 3

Order on days ,1, 2, 3

Q14D

Order every 14 days; this could be written Q2W

M, W, F

Monday, Wednesday, and Friday

B5/C14

Beginning on day 5, order test daily; cancel on day 14

B29/Q4W

Order test beginning on day 29 and every 4 weeks thereafter

B15/Q7D/C36;B36/Q14D

Beginning on day 15, order test every 7 days, until day 36; then order test every 14 days

*1, 3, 5

Order test on days 1, 3, and 5, except when they fall on a weekend or holiday; in that case order on the nearest working day

Figure 4.

dictionaries were created for text messages, and the clinical data coordinator was given the facility to define messages to be used for a specific treatment sequence.

Figures 4 through 6 contain some typical treatment sequences as they are now used. The first is the follow-up treatment for the bone marrow transplant (BMT) protocol starting on day zero. It orders blood tests and physician assist and nursing procedures. It indicates that the Direct Coombs Test (DIR COOMBS) is to be done on days 36, 71, and 101, except if they fall on a weekend, in which case the test is ordered for the nearest weekday. The Serum Osmolality (SR OSMOLAL) is to be ordered every Monday and Thursday. The treatment sequence also specifies that comments are also to be listed. Every seven days the message CHEST X-RAY SHOULD BE SCHEDULED Q7 DAYS, OR AS CLINICALLY INDICATED.

will be listed, and on day 1

Figure 5.

IT ISN'T NECESSARY TO DRAW AN ART. BLOOD GAS ON DAY OF BMT IF ONE HAS BEEN PREVIOUSLY DRAWN.

will be printed.

The portion of the treatment sequence in Figure 5 illustrates a set of drug orders for a BMT protocol. The therapy lines include the drug name (in the internal OCIS dictionary form) and the dose. In preparing the plan, the OCIS determines the patient’s weight in kilograms (or area if body surface area is specified) and computes the actual recommended dose. The plan also allows two different dose levels to be ordered. For example, CSA-P is administered at the rate of 10 mg/kg from day 17 through 44 and at the rate of 7.5 mg/kg from days 45 to 182. The therapy entry also includes a descriptive line providing administration information.

Finally, Figure 6 illustrates how the comments are used to present the dose modification information. The first message is printed starting day 1 and then daily. (The BMT sequences start on day 0.) The next block is related to the administration of the J8209/CYTX and is printed every 7 days starting on day 23. The final block is printed every day beginning on day 2 and concluding on day 5; this could also have been coded as 2, 3, 4, 5. In each case, the comment is identified by a mnemonic (e.g., AMPHOTERICIN), and the full comment is printed from the comment dictionary to make the treatment sequence easier to read.

Figure 6.

The Standing Orders Treatment sequences are independent of the patient. To be processed, the sequences must be associated with a patient. This can be done in two ways. First, a pointer to a treatment sequence can be tied to a patient. The advantage here is that the same sequence can be used for many patients, thereby saving space. The obvious disadvantage is that the sequence is associated with many patients, and therefore any changes to a treatment sequence may impact on the care of patients currently being managed with that sequence. Consequently, the system design chosen by the OCIS copies the treatment sequence to a patient treatment structure called the standing orders. These standing orders may be edited to provide individual therapy for a particular patient.

Because the patient standing orders typically are constructed from more than one treatment sequence, all order entries must identify the treatment sequence with which they are associated, along with the date on which the treatment sequence was initiated. Adding a treatment sequence to the standing orders involves the copying of all terms from the treatment sequence file to the patient standing order file while setting the start date to the current date. Stopping a treatment sequence involves going through the standing orders and deleting all entries for that sequence.

During the preparation of a patient’s daily care plan, each request (i.e., statement copied from the treatment sequence) is compared with the status of that request for that patient. For example, if the standing order item is to be ordered on day 3 and this is the third day on which the treatment sequence has been active for this patient, then the item will be included in the care plan. A somewhat more complex algorithm is used for some of the other cyclic requests, and the order processing concludes with a task that removes duplicate or overlapping requests, as for example, requests for a CBC and WBC. The fact that an item has been recommended is recorded in the patient’s standing orders; after validation, the fact that the item was actually ordered is also recorded. The updated standing orders are used to produce the printed daily care plans; the same information is available on line.

In addition to the treatment sequence recommendations, the patient protocol structure has the facility for maintaining a set of clinical findings, such as the cumulative doses of a drug, the last value of a test, the average of a test result over a given period, or the maximum result for a test value in some time window. When these clinical findings are requested, the daily care processing initiates the updating of the findings. (The only complicated aspect of this processing is the management of edits to the clinical database that may alter averages, maxima, etc.) The clinical findings may be listed in the daily care plan; they may also be used to recommend dose modifications, warn of excessive cumulative drug doses, or identify early trends in test results. The clinical findings functions were all implemented by Chris Brunn, but they did not seem to elicit much physician interest. Thus, although all the programs work and the outputs are included in most of the descriptive OCIS papers, this feature of the system is used only occasionally.

Outpatient Care Plans Before describing how the system operates, the issue of outpatient care plans must be addressed. There are several technical problems that make the processing of outpatient care plans more difficult. First, the periods between events is more variable. In the treatment sequences exhibited, the granularity is one day, whereas in an outpatient setting it may be weeks or months. For outpatients, the evaluation of a Q2W criterion implies a range of 11 to 17 days, and the protocols must be able to accommodate missed appointments and delays of a week or more. This implies that the outpatient plan must be integrated with the appointment system. Also, rules for allowable visit rescheduling when therapy is in progress must be defined. Finally, the feedback and processing flow for outpatients would have to be organized differently. There are not enough outpatient clinical data coordinators to manage the flow as it operates in the inpatient units; the processing of therapy actions must be integrated with the charge capture process. Fortunately two developers, Liz McColligan and Farideh Momeni, were able to work out many of these problems, and they implemented a prototype outpatient system.

Given the OCIS orientation to patients regardless of the location of their treatment and the fact that many protocols integrate inpatient and outpatient care, one might think that the clinical staff would be anxious to extend the daily care plans to the outpatient clinics. In fact, most of the automated support for cancer protocols developed at other institutions is restricted to outpatients. However, by dealing with the complexities of inpatient care, OCIS built a powerful system that many providers perceived to be too complex for casual use. That is, a considerable investment in protocol definition, learning, and system maintenance is required to make the care plans effective. Just as in the case of entering the protocol descriptions, no investigator was willing to commit the time required to make the system work in an outpatient setting. As a result, the prototype was never operationally tested, and the daily care plans are restricted to the inpatient units.

If the OCIS were a research project, this lack of interest in an outpatient facility would be met with disappointment; the concept could not be validated. However, from the development perspective, the OCIS outpatient daily care plans can be viewed as one of a series of experiments in building functions that the designers hope will meet real needs. Sometimes these experiments produce operational tools for which there is no immediate demand. If the demonstrations do not create the demand, then the tools are retired. Should the demand later materialize, then the first iteration of the tools will be available. Thus, one may view the OCIS as a dynamic organism that responds and adapts to its users’ needs. The discussion now turns to what the Oncology Center finds useful.

Daily Care Plan Processing As described in the previous section, the daily care plans are processed with the following flow: a patient is entered onto a protocol, and treatment sequences are activated and deactivated as the medical decisions are made. This information is organized by patient, and the data are referred to as the patient’s standing orders. Each morning, a data coordinator enters into the database any deviations from the previous day’s plan, for example, orders not carried out or additional or modified orders. This is a process called “verification.” Once it is complete for all patients, the daily care plans for the current day can be produced.

Figure 7 displays a two-page daily care plan for a BMT patient whose standing orders contain the following ten treatment sequences:

Treatment Sequence ID

Day started

Day number

7915 TX

05/16/88

39

BMTFOLC

05/19/88

36

BMTFOLT

05/27/88

28

BMT INT

05/16/88

39

CY4 INF

05/18/88

37

J8209

05/25/88

30

MARHARV

05/15/88

40

MAR INF

05/27/88

28

PFTS

05/15/88

40

TB14TX

05/23/88

32

The top of the plan contains the identification, some demographic data, information used in computing the drug dose, and the names of the providers. If the census entry includes text messages (as described in Chapter 4), then these messages will be printed at the top of the page as well. The use of census text is left to the provider. On the day that the daily care plans were printed out for this chapter, 13 plans were listed for consideration. Of these, 5 had text, and four of the text fields totaled 30 lines or more in length. (The 30 lines of text contained approximately 20 separate data-flagged messages.) The providers for the patients whose plans are presented in this chapter did not take advantage of the census messages.

Below the standard heading block are printed the protocols by which the patient’s treatment is being directed. These OCIS protocols represent modules of a larger integrated plan. There is no one-to-one correspondence between protocols and treatment sequences, and some protocols may not have a treatment sequence associated with them.

The next section of the plan lists the test and procedure recommendations for that day. Twelve blood and serum tests are to be ordered; there are several messages for the physician, and there are three physician assistant procedures along with a message. Because the messages are not of the first priority, they are printed in this location. When they are required, high-priority messages are printed in a box above this section.

The next section contains the recommended therapies. In this case two drugs are to be administered. The actual dose is computed by the system as a function of ideal body weight (65.8 kg, as listed at the top of the plan). Below the treatment block are the dose modification instructions. As noted earlier, even though some of the dose modifications are in the form of a table that implies the ability to adjust the dosages automatically, all modification instructions are simply text messages.

Figure 8 contains a portion of the patient’s standing orders that were used to generate this plan. The standing order entries are organized by type. Each entry contains

Figure 7a.

the order identifier, its schedule, the number of times that the order was carried out (its count or CNT), the date that it was last done (LST DONE), the day number of the treatment sequence that initiated this item, and the treatment sequence identifier.

This page of the standing orders begins with the P.A. procedures. The first procedure listed is BMRH (bone marrow aspirate for morphology or, as listed in the daily care plan, BM MORPH). This is requested by two different treatment sequences: BMT FOLT, for BMT follow up (T), and BMT INT, for BMT Initiation

Figure 7b.

. The schedule for BMRH under BMT FOLT is to begin on day 15 and then the procedure is to be ordered every 7 days until day 36, when the schedule is changed to every 14 days. (This is written B15/Q7D/C36;B36/Q14D.) The schedule under BMT INT is for the procedure to be ordered on day 2 unless that day is a holiday or weekend, in which case it is to be ordered on the working day closest to day 2. (This is written *2.)

The plan being ordered from this set of standing orders is for the following day, a Friday. As can be seen from the first line, this is day 28 of the BMT FOLT treatment sequence, and therefore the Q7D option is in effect. The BMRH was last ordered 06/17/88 and the next day (i.e., the day of the plan) is 06/24/88. This is 7 days since the last order, and a BMRH recommendation is required. The BMRY (BM CYTOGEN) is ordered because 06/23/88 is day 28 on BMT FOLT, and its schedule calls for an order on day 29 if it is not a weekend or holiday. Finally, BMBX (BM BIOPSY) is ordered every 4 weeks beginning on day 29 according to the same treatment sequence.

Notice that the P. A. procedure orders associated with BMT INT and the bone marrow harvest sequence, MAR HARV, are no longer active. These treatment sequences could be deleted without altering any future daily care plans. They are retained, however, because the providers find them helpful for documentation purposes.

Figure 8.

The standing orders identify 10 different dose modification messages. The plan in Figure 7 lists three modification messages: AMPHOTERICIN, LIVER TOX 3, and RENAL TOX 3. The first is listed every day starting with the first day, and the other two are listed from days 7 through 44. After day 44 the modification messages LIVER TOX 4 and RENAL TOX 4 are listed. As shown in the plan, the count of these other listings is 0, and the date for last done still is blank.

The final section in this standing order page lists the therapy recommendations. The order 209AP (8209/CSA-P) is to be listed with a dose of 10 mg/kg from

Figure 9.

days 17 through 44 under treatment sequence J8209 (the ninth Johns Hopkins protocol to be defined in 1982). The order for MPRD (METHL PRED) is to be changed on day 31 from a dose of 0.5 mg/kg to one of 0.4 mg/kg. No other drugs are to be ordered. The standing orders provide for a message field to be printed on the daily care plan, but the message was felt to clutter the output and therefore is not printed in the final plan. .

A second daily care plan is shown in Figure 9. This BMT patient is being treated with a different protocol, and there are five active treatment sequences.

Treatment

sequence ID

Date started

Day number

3SGEN

05/09/88

46

BMTFOL3

05/20/88

35

BMTFOLC

05/11/88

44

CYR INF

05/14/88

41

MAR INF

05/20/88

35

Figure 10a.

As shown in the plan, there are seven active protocols. The BMT protocol is used for documentation only; it identifies the BMT day. Two protocols, J8638 and J8809, have multiple branches, and the letter identifies the protocol branch to which the patient has been assigned.

In this plan there are 19 blood and serum tests, two physician messages, and two P.A. procedures with one message. The segment of the standing orders shown in Figure 10 illustrates how the messages are organized. In this set of standing

Figure 10b.

orders there are six levels of messages. Level 0 and the first of the Level 1 messages are on the first page of this standing order segment. Level 0 consists of critical information that is printed in a box at the top of the daily care plan. In this example all critical information is printed out only on day 1.

The plan in Figure 9 includes two physician messages (Level 2, M.D. comments). Each message in the standing orders is identified with a short mnemonic (BM BX PRN), and in this case the full message is printed below the status line.

BONE MARROW BIOPSY MAY BE DONE PRN WHEN BONE MARROW ASPIRATE IS DONE The number in parentheses to the left of the message indicates the order of the message relative to other messages of the same level when listed in a plan. The remainder of the comment order line is identical to that of the other standing order items.

BLOOD PROCEDURES

TEST NAME

AMOUNT

TUBE

LAB

SLIP

HEMATOCRIT

3 CC

SM LAVEND(

ONC

ONCOLOGY

WBC

SM LAVEND

ONC

ONCOLOGY

PLT CNT

SM LAVEND

ONC

ONCOLOGY

WBC DIFF

SM LAVEND

ONC

ONCOLOGY

RETIC CNT

3.00 CC

SM LAVEND

ONC**

ONCOLOGY

BLOOD CULT

BLOOD CULT

BACT

BACT

DIR COOMBS

3.00 CC

LAV

BLOOD BANK

PT REQN,BLD BNK

TYP&HLDX4 8

7 CC

YELLOW

BLOOD BANK

BLOOD BANK

TYPE & HOLD X 48 HOURS

TYPESHOLDA

10 CC

1YELL+1LAV

BLOOD BANK

BLOOD BANK

FOR PTS WITH ANTIBODIES;JUST CHECK

T&H

SMA-12

7.00 CC

RED TOP

MAIN CHEM

BLD CHEM I

STAT M6

4.00 CC

SM RED

MAIN CHEM

EMERG CHEM

SEND STAT

AMA&SMMSAB

7.00 CC

RED TOP

GI

MISC

ENA

7.00 CC

RED TOP

BLAL 917

MISC

STAT PRO TIME

5.00 CC

BLUE

MAIN/PARK

EMERG COAG

NO ADD BLD

NECESS IF FIBR IS DRAWN

STAT PTT

5.00 CC

BLUE

AD SP HEM

EMERG COAG

NO ADD BLD

NECESS IF FIBR IS DRAWN

ANTINUC AB

7 CC

SM RED

DX IMMUNO

DX IMMUNO

S IMMUN EP

10 CC

LG RED

DX IMMUNO

DX IMMUNO

CHECK "IMMUNOGLOBULIN

SURVEY" ON SLIP

RHEUM FACT

7 CC

SM RED

DX IMMUNO

DX IMMUNO

RHEUM FACTOR (RF SCREEN)

DNA ANTIBD

1 CC

YELLOW

916 BLALOC

MISC

1 CC IN YELLOW TOP TO

DR. EVAN FARMER

Figure 11a.

In this set of standing orders, the P. A. procedure for the bone marrow biopsy (BMBX) is recommended on days 15, 22, and 29. The other two bone marrow procedures (BMRH and BMRY) are ordered every 7 days from days 15 to 36 and every 14 days thereafter. This is the same schedule for the preceding physician reminder. The result is that the suggestion that a bone marrow biopsy be ordered PRN will be printed on the same day that the marrow aspirate is to be done.

The M.D. comment, CHEST XRAY, suggests that a chest x-ray be ordered every 7 days or as clinically indicated. If there was no order in at least 7 days, then

the message is printed. If the chest x-ray is not ordered when recommended, then the message will be repeated until one is ordered. On the other hand, if the chest x-ray was clinically indicated before the end of the 7-day cycle, then the fact that it was ordered will be entered into the standing orders during the verification process. The next reminder will always be printed 7 days after the last order.

Figure 11 contains the information in Figure 9 in the form of an order guide. This is delivered to the unit clerk for the preparation of the necessary laboratory

Unit

Beds

Patients

1985

1986

1987

2 North

14

Solid tumor

103

132

126

2 South

14

Leukemia

108

76

75

3 North

22

Solid tumor

107

168

149

3 South

20

BMT

119

149

143

Peds

14

Pediatric

85

119

118

Total

84

522

644

611

*Note that the table represents the number of patients admitted to an inpatient unit who were actively on a protocol. Readmissions of the same patient are not counted. Some of the numbers have been adjusted to account for administrative changes in the unit’s size and use. The relative stability since 1987 reflects the fact that, owing to the nursing shortage, fewer patients are being admitted.

slips. As shown on the first page, the test name, the"amount of blood to be drawn, the tube to be used, the laboratory to which the specimen is to be sent, and the requisition slip to be used are all specified. This is followed by spaces in which additional orders may be written. At the bottom of the blood procedures section, the order guide totals the amount of blood to be drawn, in this case 86 cc.

The second page contains space for urine and radiology procedures. The P. A. procedures are listed in the final section. At the bottom are places for the physician to indicate that these tests and procedures are to be ordered, for the unit clerk to indicate that the forms have been filled out, and for the phlebotomist to indicate that the blood has been drawn.

The signed order guide is used by the clinical data coordinator to update the patients’ standing orders. The OCIS maintains a verification list of all the tests and procedures that were included in the current daily care plan. Recommended tests and procedures not ordered or carried out are deleted from the list; added tests and procedures are appended to it. Once the list is correct, the plan is marked as verified, and the count and last-date-done fields of the standing orders are updated.

Evaluation From the examples in the previous section, it is clear that the protocol-directed-care plan function of the OCIS provides useful support in the clinical management of patients treated with very complex therapies. Obviously, these therapies are used in other cancer institutions, and one cannot make the claim that an automated system is a necessary tool for these therapeutic modalities. Nevertheless, we believe that protocol-directed care enables the Oncology Center to provide aggressive therapy in a safe and controlled environment in a relatively cost-effective manner. This is only an assertion. To demonstrate this as a fact, one would have to perform a multicenter study that compared therapeutic

Number of Tests Ordered

Unit

Patients

Automated (Plans)

Written in

2 North

14

16

230

2 South

10

337

13

3 North

15

854

130

3 South

5

2652

13

regimens, operating costs, and outcomes. Because this has not been done, our evaluation is subjective.

First we observe that the system has been in daily use since 1982 and is paid for out of patient care revenues. Thus, the clinical staff and hospital administration perceive it to be useful. In the previous sections we have described how some of the original system features were abandoned and how less sophisticated tools were added. This also implies that the system has adapted to meet the needs of its users. However, it must be observed that the demand for the daily care plans is limited. Several sophisticated features of the software were left to ossify; the outpatient plans were never tested. Consequently, one may conclude that, although the tools are used routinely, there is no predisposition to rely on automated reminders.

There are some characterizing metrics that suggest the extent of the system’s use. Table 3 shows the number of patients on protocol for five units. Table 4 summarizes the protocol-directed activity during one week in 1987. In the BMT and leukemia units, the care plans are used to manage most of the therapy. Few changes are made. However, in units where there is little reliance upon the protocol system, more orders must be entered manually. Of course, the units treat patients with very different types of diseases, and no comparisons among units would be valid. The table does make the point, however, that where the daily care plans are appropriate, they can be made to be complete.

What lessons does the OCIS experience offer to others who would like to formalize their therapy plans and automate part of the management of patient care? First, it must be recognized that there is a broad spectrum of protocol complexity. At the least complex level are actions such as the drug-drug interaction warnings, the Regenstrief therapy reminders, and the HELP alerts. These are highly modular and independent, each requires some physician feedback, and they are used only in exceptional situations. Studies have shown that these tools alter the physicians’ actions, but they do so in the context of feedback within the standard medical decision-making process.

The OCIS inpatient protocol system, as implemented for the BMT and leukemia units, is an example of a closed approach to an automated patient management system. The full set of therapy plans must be defined for all therapeutic situations, and the system must be able to prepare complete plans every day for every clinical situation. For complex treatment modalities, as practiced in units in which the plans are relied upon, there is a major benefit in using the plans. Compliance with the protocol is ensured, training and orientation of the rotating house staff is facilitated, documentation is created automatically, and the management of many different patients using essentially the same treatment regimens is controlled. The major cost for this type of system is the heavy investment in preparing the treatment plans. Where plans are used often and over an extended period of time, the preparation cost is justified.

It is the middle level of treatment planning that has the least automation and, perhaps, the greatest need. In the case of the OCIS, the treatment plans are not used in units that treat patients with many different protocols. The cost of preparing the plans does not seem to be justified. Perhaps, if the treatment plans could be produced as a by-product of the protocol definition process, then more plans would be documented and there would be more of an incentive to use the system. Alternatively, if new reporting requirements, say for FDA or NCI, were identified and the protocol system could satisfy them easily, then the system might be perceived to be a labor-saving tool, as well as a patient management aid. Finally, if some centerwide therapeutic objectives could be formulated, then these could be independently supported by the care plan system. (In fact, this has been done with the ordering of all inpatient blood tests.)

In conclusion, this chapter demonstrates that, if an organization knows what it wants to do in specific clinical situations, it is possible to use automation to guide the process. For a set of independent actions, there are ways of producing alerts or reminders to warn of potential problems. In complex therapeutic situations it is possible to offer a daily plan based on predefined rules. These automated systems can be defined as algorithms, or they may use inference mechanisms with various degrees of complexity. Limitations to success are the tool’s acceptance by the providers as a useful adjunct, the availability of broadly accepted decisions regarding what actions are appropriate in given situations, and the ease with which this knowledge can be maintained and the tool can be used. The OCIS experience illustrates that automation and the writing of computer programs are not limiting factors, except as they are affected by these constraints.

Рекомендуем к просомтру

www.kievoncology.com благодарны автору и издательству, которые способствует образованию медицинских работников. При нарушении авторских прав, сообщите нам и мы незамедлительно удалим материалы.