Safety and Computer Aided Design of Chemotherapy Plans

P. Hammond, S. Modgil, Dept of Informatics, Eastman Dental Institute for Oral Health Care Sciences,

J.C. Wyatt, Health Knowledge Management Centre, School of Public Policy,

University College London, U.K.

Keywords: chemotherapy, computer-aided design, planning, protocol, safety reasoning

Previously, generic principles were derived empirically from examples of reasoning about the efficacy and safety of chemotherapy. Some of the principles were used in a prototype decision support system for managing patients through chemotherapy. It reminded clinicians which, how and when drugs were to be given, suggested treatment modifications as a result of detected adverse events, and warned how unplanned actions undermine efficacy or exacerbate hazardous side-effects. Here, we investigate the use of the safety principles to generate symbolic and textual representations of new chemotherapy plans. In clinical trials of chemotherapy, a written protocol is essential, especially in obtaining ethical approval. The symbolic representation, from which textual extracts are derived, can be used in conjunction with software for managing chemotherapy.

Oncologists, clinical specialists in cancer treatment, employ chemotherapeutic drugs in quite complex combinations often over considerable time periods. Their side effects can be severe, permanent and even life threatening, so it is essential to monitor for adverse reactions as well as review their intended effect on a malignancy. Hence, chemotherapy is a fine balance between maximising efficacy and minimising risks and hazardous side effects. The monitoring of patients during chemotherapy can also be complex, and once more takes place over extended periods. It is likely, therefore, that the use of computerised reminders of treatments, patient monitoring and associated hazards will become more widespread and offer potential for improving data capture, statistical analysis of treatment results and patient safety.

Human error does occur in the management of cancer patients, often with disastrous results, for example if a drug is administered by an incorrect route (ref. 1). There is also concern that some patients are being treated by non-specialists (ref. 2) or are not receiving optimal treatment for which there may even be substantial published evidence (ref. 3).

We focus mainly on in-vivo adverse effects, but it is important to make a thorough analysis of all safety and efficacy issues since there are numerous ways in which hazardous situations can arise in chemotherapy treatment, including the following:

• exceeding maximum values for single or cumulative dosages, for treatment cycles or even over an individual’s lifetime
• achieving correct concentrations in administering solution or in blood plasma
• the administering route affects efficacy and toxicity, and because of localised effects a site may need to vary
• rates of administration can be hazardous
• drug interactions occur, often subtley
• drugs interact with equipment used for storage or administration
• the preparation of drugs and their accidental spillage can be hazardous

Following the inspection of over 100 chemotherapy treatment protocols, nine generic safety principles were previously extracted (ref. 4). Table 1 contains a summary of the principles and a single illustrative example for each. In all, more than 200 examples of such reasoning have been collected. The Exacerbation and Diminution principles described were included in OaSiS, prototype chemotherapy management software (ref. 5), to inhibit additions to treatment that might exacerbate a known hazard or undermine efficacy. The latter is considered a hazard given the potentially life threatening nature of malignancy. The two principles were used in OaSiS as integrity constraints on updates to a database representing the state of the treatment, the patient monitoring data and relevant knowledge of chemotherapeutic drugs and their side-effects. In addition, the Reaction principle was used, not as an integrity constraint, but as a filter so that drug doses, for example, could be modified when reported monitoring data heralded adverse reactions.

Table 1- Generic Safety Principles with Illustrative Examples

When devising new chemotherapy plans, oncologists make extensive use of publications such as ‘The Cancer Chemotherapy Handbook’ (ref. 6) or specialist sections of the ‘British National Formulary’. Rather than capture such efficacy and safety information as many ad hoc examples, we believe it is advantageous to capture them as generic safety principles.

In the remainder of this section, we demonstrate how the safety principles can contribute to the description of a chemotherapy plan involving the drugs cisplatin and taxol, both regularly used in cancer treatments. In practice, this will require a graphical or form-based interface more user friendly than the linear presentation given here. We show how information supplied by the plan designer and that present in an appropriate oncology knowledge base might interact with the safety principles to produce simple facts characterising the design of the chemotherapy plan, at what we refer to as "build-time". Facts defining a particular plan (always shown below in italics) are also then available for "run-time" use to configure software for the management of chemotherapy. In order to simplify the presentation, our Prolog implementation may be more complex than the descriptions suggest.

Use of the Efficacy principle: The design of a plan might begin with the selection of drugs with a desired effect on the target malignancy. Details of drug efficacy in the supporting oncology knowledge base could be expressed in terms of a general predicate

efficacy(Action,Focus, Efficacy)

with instances

There are a number of interpretations of the EFFICACY principle "Ensure that overall plans are efficacious in pursuing stated objectives". For example, at build-time, a plan designer would want to be informed that a suggested effect of a drug is unknown or might have previously been refuted. Of course, in some situations, a special class of users may seek, and be granted, permission to override such a veto. Alternatively, if there is a more effective way of administering a drug for a particular objective, then once again the designer should be informed. We might formulate the generic efficacy principle as the rules (1-3) below. The first two reject a proposed action for inclusion in a plan; the respective reasons being absence of acceptable evidence of efficacy, and evidence suggesting poor or inferior efficacy:

(1)

invalid(Action,Plan,Focus,unsubstantiated_effect) :-

not (efficacy_value(Efficacy),

efficacy(Action, Focus, Efficacy)).

(2)

invalid(Action,Plan,Focus,insufficient_effect) :-

efficacy(Action, Focus, Efficacy),

insufficient(Efficacy).

In rules 1 and 2, invalid(Action, Plan, Focus, Reason) can be read as "Action is ill advised in Plan with aim Focus because of Reason" .

Given specific facts describing what is more efficacious in chemotherapy, the third rule modifies the plan on the basis of evidence suggesting a more effective alternative:

(3)

advise_plan(Action1,Plan,Focus,Action2,Reason) :-

efficacy(Action1, Focus, Efficacy1),

efficacy(Action2, Focus, Efficacy2),

more_efficacious(Efficacy2, Efficacy1),

Reason = better(Action1,Focus,Action2).

where we might interpret advise_plan(Action1, Plan, Focus, Action2, Reason) as "In Plan with objective Focus action Action1 should be replaced or supplemented by Action2 for Reason". For example, a combination of rules (1-3) and the efficacy clauses will allow the nomination of cisplatin to treat ovarian cancer. But, they will question the use of ifosfamide if a single dose is proposed (because of its inferior efficacy) and suggest a more potent regime. Clearly, for this principle to be applied here it is necessary to know the intended effect (focus or objective) as well as the mode of drug administration.

Knowledge of typically used dosages can be used to check the acceptability of, or even guide, a user’s suggestions. For example, with the addition of the following instances in the knowledge base

of the predicate typical_dosage(Drug, Dose, Frequency, Cycle), the following facts could be generated, with some help from the user, for inclusion in the representation of the chemotherapy plan:

As stated earlier, the facts depicted in italics will form part of the symbolic description of the chemotherapy plan and can be used to configure a computerised system for the management of patients. They can also be translated to a textual form for inclusion in a protocol document associated with the chemotherapy plan.

Use of the Prevention, Monitoring and Sequence principles: Anticipated hazards such as dehydration and nephrotoxicity, and associated monitoring procedures, arising from use of the chemotherapeutic drug cisplatin might be described in clauses as:

(4)

anticipated_effect(admin(cisplatin,_,_),dehydration,[]).

(5)

anticipated_effect(admin(cisplatin,_,_),nephrotoxicity,

[monitor(creatinine_clearance)]).

These two clauses are instances of a predicate anticipated_effect(Action, Effect, Monitoring). Their hazardous nature might be recorded by two facts:

hazardous(nephrotoxicity).

(6)

hazardous(dehydration)

We represent the combination of prehydration and posthydration to prevent cisplatin induced dehydration in clause 7

(7)

prevention(admin(cisplatin,_,_),dehydration,

[prehydration(P),posthydration(P)]) :-

default_hydration(P).

default_hydration( [(normal_saline,1-2,litre),

(mgso4,8,mEq,per_litre)]).

Clause 7 is an instance of the more general form prevention(Action,Effect,Prevention).

In the previous section, we demonstrated how the efficacy principle can be used during the design of a plan to reject inappropriate actions (rules 1 and 2). We also described how changes to a plan might be advised (rule 3). One can consider the latter as a specific instance of a general scheme in which a user’s suggested addition to a plan is assessed, the plan is modified and a justification for the changes is given. We show how this scheme might be used for animating the prevention, monitoring and sequencing principles.

Prevention: The PREVENTION principle "Prevent or ameliorate hazards before executing an essential action" might be expressed in rule form as:

(8)

advise_plan( Action, Plan, Focus, Prevention,

ameliorate(Action, Effect) ) :-

anticipated_effect(Action, Effect,_),

prevention(Action, Effect, Prevention).

From clauses 4, 6, 7 and 8 and the query

one can derive:

PlanChange = [prehydration(P), posthydration(P)]

where

P=[(normal_saline,1-2,litre), (kcl,20,mEq,per_litre),

(mgso4,8,mEq,per_litre)].

This solution to the query would then be automatically translated to facts forming part of the description of the plan (which is why its components are italicised). Of course, in a fully operational system, the user will not enter Prolog queries, but interact with a more friendly interface where such complexities are hidden.

Monitoring: The MONITORING principle "Monitor responses which herald hazardous situations" can be represented in clausal form:

(9)

advise_plan( Action, Plan, Focus, Monitoring,

monitor(Action, Effect) ) :-

So the same query that was used for the animation of the prevention principle above will generate an additional solution:

PlanChange = [monitor(creatinine_clearance)]

Reason = monitor(admin(cisplatin,_,_),

Once again, this solution would be used to generate components of the description of the plan.

Should the user attempt to add the drug taxol to the plan for a combination therapy, then as before efficacy and dosage components of the knowledge base can help generate facts such as

If the knowledge base also includes details of the hazardous effect of the drug taxol on blood cell counts:

anticipated_effect(admin(taxol,_,_),neutropenia,

hazardous(neutropenia).

then the monitoring principle (clause 9) and the query

yield:

PlanChange = [monitor(cell_count)]

Reason = monitor(admin(taxol,_,_),neutropenia))

An appropriate formulation of this query solution will be also added to the description of the chemotherapy plan.

Sequence: The SEQUENCE principle "Order (essential) actions temporally for good effect and least harm" can be represented as the rule:

(10)

combined_effect(Seq,Effect,PlanChange),

hazardous(Effect),

Reason = warning( Seq,Effect).

The sequencing restriction on the order of administering taxol and cisplatin (see sequencing example in Table 1) is captured as:

(11)

combined_effect(

sequence([cisplatin,taxol]), neutropenia,

[sequence([taxol,cisplatin])]

The suggestion of using cisplatin followed by taxol, given clauses 10 and 11:

produces the response

PlanChange = sequence([taxol,cisplatin]

Reason = warning(sequence([cisplatin,taxol]),

From this solution two new facts will be generated. The first describes the inclusion of the correct sequence for using the two drugs. The second adds a warning about the hazardous nature of the incorrect ordering.

We now focus on the exacerbation principle and discuss both its run-time and build-time use. One might expect its typical use to be at run time, when for example a veto is placed on a suggested treatment of an adventitious medical condition by the managing clinician (see exacerbation example in table 1). At build time, it is important to anticipate such run time application. In this way, the protocol document describing the designed plan can demonstrate awareness of possible hazards arising during patient management, as well as appropriate responses to them. This not only enhances safe patient management, but is important in gaining ethical approval for a clinical trial of a new chemotherapy treatment.

We can represent the EXACERBATION principle in an expanded textual form An action is ill advised in a plan if there is another action in the plan with a hazardous effect that the proposed action exacerbates.

Corresponding to this might be the rule:

(12)

part_of_plan(Action2, Plan),

anticipated_effect(Action2,Effect, _),

hazardous(Effect),

exacerbation(Action1, Action2, Effect).

Suppose that the oncology knowledge base includes clauses describing the exacerbation of cisplatin induced nephrotoxicity by antibiotics that are themselves nephrotoxic (clauses 13-15 below) and in particular by the antibiotic gentamicin (clauses 16 and 17 below):

(13)

exacerbation(admin(Drug,_,_),admin(cisplatin,_,_),

antibiotic(Drug),

anticipated_effect(admin(Drug,_,_),nephrotoxicity,_).

(14)

anticipated_effect(admin(cisplatin,_,_),

nephrotoxicity,

[monitor(creatinine_clearance)]).

(15)

hazardous(nephrotoxicity).

(16)

anticipated_effect(admin(gentamicin,_,_),

(17)

antibiotic(gentamicin).

We need to suppose also that the user has declared the inclusion of cisplatin in the treatment plan. This is recorded as:

(18)

We can obviously use clauses 12-18 at run-time to veto a suggestion to use the antibiotic gentamicin in plan_1256. We could do this by solving an appropriate query as in the earlier examples using a standard Prolog interpreter. However, in the build-time situation, we want to make use of the exacerbation principle in its most general form to generate a form of words that captures its use in this particular treatment plan. For example, we might want to generate the general exhortation "Using nephrotoxic antibiotics is ill advised", or alternatively, the more specific "Using an antibiotic such as gentamicin is ill advised". The question is how to get from the symbolic form in clause (12) to these abbreviated but more appropriate textual abbreviations.

We have yet to consider fully the natural language generation requirements for producing protocol document extracts from the symbolic representation of the chemotherapy plan. However, we are confident that even definite clause grammars with some simple extensions can produce the majority of the extracts shown in table 2. Here, though, we confine ourselves to the problem outlined above, namely, the production of simple abbreviations of a generic safety rule for inclusion in the protocol document. In particular, we want to be able to generate the phrase labelled (*) in table 2.

We have implemented a natural language translation of the generic safety rules using a combination of simple templates for rule components and a variable referencing scheme. The sentence in (20) is the result of using this translation process on the exacerbation principle defined in clause (12).

(20)

An action₁ is ill advised in a plan if

another₃ action is part of the plan and

the other₄ action causes an effect and

the effect is considered hazardous and

the action₂ exacerbates the effect of the other₄ action

clause_read_as((Head :- Body)) è

head_read_as(Head),

{new_line(NL)},

body_read_as(Body,NL,` if `).

head_read_as(Head) è atom_read_as(Head).

body_read_as(true, A, B) è [].

body_read_as((Goal,Body),A,B) è

[A,B],

atom_read_as(Goal),

body_read_as(Body, ` and `,A).

with for example a template for the atomic predicate hazardous(Effect) :

atom_read_as(hazardous(Effect)) è

variable_read_as(Effect, effect),

[is, considered, hazardous].

In theory, (20) could be included in the protocol document of every chemotherapy plan. Of course, it would not be welcome because of its unspecific nature; it obviously needs specialisation. The problem is to decide just how specialised to make the rule. In the next section, we demonstrate how we currently use a metaprogram to create these more specialised forms.

Table 2 - Examples of textual extracts generated at build time for inclusion in a protocol document

The demo logic program defined below is a typical metaprogram for theorem proving with logic programs in the form of Horn clauses (KB denotes the knowledge base).

demo(KB, Goals) ¬ empty(Goals).

demo(KB,Goals) ¬

select_goal(Goals,Goal,RestGoals),

select_clause(KB,Clause),

rename_variables(Clause,Goals,RenamedClause),

parts(RenamedClause,Head,Body),

match(Goal, Head,Substitution),

add_body(Body,RestGoals,InterGoals),

apply_sub(InterGoals,Substitution,NewGoals),

demo(KB,NewGoals).

Intuitively, given a list of goals A, B, C…, the selection of a goal A and its subsequent resolution with the clause A` :- A1, A2 (where A and A` unify), yields the new set of goals A1``, A2``, B``, C`` with appropriate unification and variable renaming. We can use demo as the basis for a metaprogram that is able to execute (pure) Prolog programs. If we allow the unification, variable renaming, explicit knowledge base reference and resolution steps to be carried out by the underlying Prolog system we obtain:

demo(Goals) :- empty(Goals).

demo(Goals) :-

In a Prolog system, the built-in selection strategies are to choose the first goal in a sequence (from left to right) and the first clause whose head (or conclusion) can be unified (matched) with the selected goal. The clause selection is made by a built-in predicate and goal selection is defined by the meta-rule:

select_goal((Goal,RestGoals), Goal, RestGoals).

We use the term unfolding to refer to the steps

where a matching clause (Goal :- Body) is selected and Goal is replaced in the original conjunction of Goals by Body. Our simple unfolding metaprogram unfold is a variation of this demo theme:

unfold(stop, Rule).

unfold(continue, (Head :- Goals)) :-

select_goal(Head, Goals, Goal, RestGoals),

select_clause(Goal, (Goal :- Body)),

add_body(Body, RestGoals, NewGoals),

next_step(Choice),

unfold(Choice, (Head :- NewGoals)).

In unfold(_, Rule), we maintain a record of the latest, unfolded representation of a safety principle. The goal selection and the selection of a clause from those whose head matches the goal to be unfolded is left to the user to decide.

Although, the unfold metaprogram manipulates clauses and their components, the explanations below are more understandable if we use natural language forms to illustrate the unfolding process.

If the first condition of sentence 20) (is unfolded using the record of the intended use of cisplatin (clause 18) we obtain:

an action is ill advised in plan_1256 if

using cisplatin causes an effect and

the effect is considered hazardous and

the action exacerbates the effect of using cisplatin

Selecting the first condition of this unfolded rule and the matching clause (14) concerning the nephrotoxic effect of cisplatin, we end up with the sentence:

an action is ill advised in plan_1256 if

nephrotoxicity is considered hazardous and

the action exacerbates nephrotoxicity of using cisplatin

The goal "nephrotoxicity is considered hazardous" uniquely matches clause 15, so we actually unfold this automatically and obtain:

an action is ill advised in plan_1256 if

the action exacerbates nephrotoxicity of using cisplatin

Given clause 13, then unfolding the only condition left we further generate:

using a drug is ill advised in plan_1256 if

using the drug causes nephrotoxicity and

the drug is an antibiotic

This is still not as close as we would like to the target phrase (* in table 2). To get even closer versions, we need to extend our use of types and subtypes so that properties of types can be inherited by their subtypes, and subtypes can be used in the same way as we have already used types in the generation of textual summaries. For example, we can extend resolution to allow inferences of the form:

using an antibiotic is ill advised in plan_1256 if

using the antibiotic causes nephrotoxicity

A similar extension to handle properties of types (such as a drug being nephrotoxic) enables us to produce the final form:

using a nephrotoxic antibiotic is ill advised in plan_1256

which is much closer to our target phrase. Work is also currently in hand on generating the additional qualifying phrases that appear in parentheses in (*) of Table 2.

Generating symbolic descriptions of chemotherapy plans and related textual components of protocol documents is certainly a useful service to provide clinicians when they are preparing new chemotherapy schemes. Recent surveys have identified considerable anxiety amongst clinicians about their incomplete and incorrect knowledge of drugs and contraindications. The inclusion of generic safety principles to monitor the formulation of chemotherapy plans may discourage errors being made both in the design phase and subsequently in their application in the management of patients.

Even with our current very naïve approach to natural language generation, we can produce useful textual summaries of a chemotherapy plan and so reduce the burden on compiling a protocol document. However, much work remains to be done if the tools we are developing are going to be practicable and acceptable to clinicians. In particular, we must develop an interface that can be used effectively even with the kind of irregular exposure that many of its potential users are likely to experience.

1. ‘You’ll die’ doctor tells patient after mistake. The Sunday Times, Nov. 21^st 1993.

2. Doctors fail to refer cancer patients to specialist centres. The Guardian, Dec. 1^st 1993.

3. Breast cancer care inquiry call. The Guardian, Jan. 14^th 1994.

4. Hammond P, Harris A L, Das SK and Wyatt JC. Safety and decision support in oncology. Methods of Information in Medicine. 1994; 33(4): 371-381.

5. Hammond P and Sergot MJ. (1996) Computer support for protocol-based treatment of cancer. Journal of Logic Programming, 26(2), Feb 96, 93-111.

6. Fischer DS, Tisch Knobf M and Durivage H. The cancer chemotherapy handbook. (1993) 4^th Edition. Mosby, St Louis, USA.

7. Hammond P, Sergot MJ and Wyatt JC. Formalisation of Safety Reasoning in Protocols and Hazard Regulations (1995) 19^th Annual Symposium on Computer Applications in Medical Care.

Prof. Peter Hammond, Department of Informatics, Eastman Dental Institute for Oral Health Care Sciences, University College London, 256 Gray’s Inn Road, London, WC1X 8LD, UK. Telephone & Fax : +44 (171) 915 2303. Email: p.hammond@eastman.ucl.ac.uk .

Prof. Hammond is a computer scientist with an interest in the application of logic programming, computer graphics and image processing in biomedicine.

Dr. Sanjay Modgil, Department of Informatics, Eastman Dental Institute for Oral Health Care Sciences, University College London, 256 Gray’s Inn Road, London, WC1X 8LD, UK. Telephone: +44 (171) 915 2343. Email: s.modgil@eastman.ucl.ac.uk

Dr. Modgil recently completed a PhD in Logic and is currently a postdoctoral research assistant on the "Design-A-Trial" project.

Dr. Jeremy Wyatt, Health Knowledge Management Centre, School of Public Policy,

University College London, U.K. Telephone: +44 (171) 504 4986. Email: uctqjwy@eastman.ucl.ac.uk

Dr. Wyatt leads the Health Knowledge Management Centre. He is a qualified doctor of medicine with a longstanding involvement in medical informatics.

This work has been carried out within the Design-A-Trial project and is supported by the UK Engineering and Physical Sciences Research Council under the Healthcare Informatics Programme.