A Sketchy Guide through Uncharted Terrain

General Information about TraumAID

Running & Using TraumAID

X-Trauma

MacTrauma

TexTrauma

HyperTrauma

the bottom of your bird cage

unsightly spots on your rug

Jonathan Kaye

Jonathan Kaye

Ulf Cahn von Steele

Abigail Gertner

Michael Niv

Last updated August, 1994

Part I — Understanding TraumAID

TraumAID has been developed over many years, but has remained principally in the programming hands of few. These few people have not always been careful in documenting what and how something works, because they are typically the only ones who had to deal with it. As TraumAID 2.0 progresses from the stages after its validation, our priorities need to include the importance of maintenance. A great part of this involves documenting how the program works and how our extensions to the program work, with hopes that future project members are not so confused by the program as are present project members.

Being confronted by the program, people in the beginning are naturally overwhelmed, though in reality the program is not very large. By understanding the key concepts, which we hope to elucidate here, one can gain a certain sense of control over how the program works, and later develop a better sense of pieces of the program by closer inspection.

Brief Description of TraumAID

TraumAID is a program to assist physicians during the critical period after the patient comes into the hospital and has been stabilized (the time referred to as ‘the initial definitive management’). In such an emergency situation, it is important to assess when it is appropriate to diagnose, and when it is appropriate to treat the injuries. Often, a physician must initiate therapy (abbreviated ‘Rx’) before completely diagnosing the extent of the injuries. Sometimes, therapeutic actions can also help diagnose the patient’s condition. From the known information, TraumAID proposes goals to address, such as a goal for diagnosing a particular condition or a goal for treating an injury. From these goals, TraumAID produces a plan (consisting of actions) that address the goals as best as possible, based on costs, time, location (some actions can only take place in certain areas, such as in the Operating Room), and other factors.

This document concentrates on the development version of TraumAID, where the program guides the user explicitly, or takes an active role in pursuing the diagnosis and treatment. For example, when the user enters the clinical findings and lets the program guide, the program may solicit more information or may decide it has enough information to act, in which case it suggests an action (the topmost from the plan). In general, bedside questions are asked first, and then the steps of the plan are executed.

It is important to note that the program does not compile a complete plan for diagnosis and treatment, then simply execute it. The program suggests a plan that addresses all the currently known goals, but as actions are done, more information becomes available which might change the plan. One of the most important aspects of TraumAID is its ability to change the plan to incorporate more information when it becomes available. The central philosophy behind this is that sometimes it is more important to act than it is to gather more information. TraumAID decides whether it is more worthwhile at the moment to pursue information gathering or perform treatment.

In contrast, the TraumAID installed in the Emergency Room takes a passive role. This means that it does not ask a question or tell the doctor what to do, rather it accepts the actions that the doctors have performed, and displays the plan to the physicians.

Brief History

The TraumAID project began around 1984 with TraumAID 1.0. The original version was developed on a Symbolics machine, in the Genera dialect of Lisp. TraumAID’s domain of expertise was limited to the abdomen. Over the next few years, Dr. Clarke and Michael Niv worked to expand the domain to the chest and abdomen.

Strictly speaking, TraumAID 1.0 was a production system, or expert system, that consisted of a rulebase that mapped findings to conclusions and prescriptions (actions to be done). After a few years, it was recognized that the system might perform better if the task were divided between an expert system to propose goals to achieve (based on findings and intermediate conclusions) and a planner that would design a plan of actions that were part of the chosen procedures for the known goals. The planner would consider factors such as which goals were currently relevant, which goals were urgent, where procedures had to take place, and how much time a procedure required. These factors would help in determining an optimal mix of actions for the procedures that were deemed necessary.

Since the goal was to have the system operational in an emergency room, the project took on another direction in the late eighties with the development of the HyperCard interface to TraumAID. The HyperCard interface was designed to be used at a nurse’s or technician’s station, where a person would enter information on one card and relevant information would be displayed on an external monitor, next to or above the patient’s bed. The interface would combine recording the case for hospital records and passing the information to TraumAID, where TraumAID would respond with its advice. The interface was originally designed and implemented as senior projects.

TraumAID 1.0 and 2.0 were developed on a Symbolics machine. TraumAID was linked with HyperCard using Symbolics’ MacIvory board, which essentially put a Symbolics machine inside a Macintosh. The original TraumAID 1.0 was also ported to C, and shown to execute on a laptop, for demonstration purposes.

Unfortunately, the Symbolics machines did not stand the test of time, as other machines became faster and much cheaper. It was clear that program development needed to be moved to a more general platform. In 1991, TraumAID was ported to the X-windows environment, under Lucid Common Lisp, and from there to the Macintosh, under Macintosh Common Lisp. TraumAID communicates with HyperCard using Apple Events, a System 7 feature that enables interprocess communication.

When we talk about TraumAID as a whole (the project), we talk about two different types of interfaces for TraumAID, the development interface and the actual interface. Quite naturally, we use the development interface to develop the TraumAID reasoner. The development interface is executable in X-windows, on the Mac, and through a simple text interface. The text interface would be useful if you were forced to run TraumAID from a VT100, or similar non-X-based platform. In this document, we talk about both interfaces, but concentrate almost exclusively on the programs that run with the development interface. The program that runs with the actual interface, HyperTrauma, is described in detail as well.

The Different Versions of TraumAID

While theoretically there is only one version of the TraumAID program, it exists on a few platforms. Therefore, there is some variation with respect to the interface on each platform. However, the core program (everything but the interface-specific routines) are exactly the same on all platforms. Currently, there exist the following versions of TraumAID 2.0:

The program is divided into three layers:

1. The core routines

2. The interface-independent routines

3. The interface-specific routines

X-Trauma is the version of TraumAID running in Lucid Common Lisp 4.1, that uses a package called ‘Tk/Tcl’ as an interface in the X-windows environment.

‘Tcl’, or ‘Tool Command Language,’ is a language for writing programs. This language has special commands for creating windows, menus, and other graphics. It is a very straightforward language. It is designed as a scripting language, similar in concept to Motif’s UIL (User Interface Language, I believe). The idea is that you write your C code to perform the functions you want in your program, but you don’t have a main program to control program execution. Instead, you write a script, in tcl, that calls your functions you have defined. The script is interpreted by an executable, built from a combination of your object code and Tk libraries. The Tk libraries provide routines for managing windows, creating graphics, managing events (like key entries, and button pushes), and all the system stuff you don’t want to have to do yourself in X.

So why do you want to do things like this? The point is that you do not have to write the code to manage windows, or menus. All the functions are defined for you. The scripting language gives you a convenient framework to integrate an interface with your specific code. This means that if you write C code, and link it with the Tk libraries, not only will you be able to do all the neat window stuff, but you will also get a scripting language for your program for free! This is useful so other people can write scripts that use your functions. So the heart of your application becomes an interpreter of tcl (which is provided), and when the interpreter reaches your command, which is not part of the predefined tcl (namely those routines in Tk that have been provided for you), it will call your routine and pass you the arguments nicely. As a bonus, interpreters can talk to each other (inter-process communication), even over a network (I believe). The ‘Tk/Tcl’ community is growing in popularity, and because it is completely free (even for commercial use), it is an attractive option for creating very useful programs.

What does this have to do with X-Trauma? The X-Trauma interface is actually a tcl script, and we use a default interpreter (we haven’t built in any of our own C functions) called wish. Oftentimes in this document we will mention wish, where we mean the process running wish (which is a tcl interpreter).

The following figure illustrates the connection between the X-Trauma system and the wish process that is executing the X-Trauma interface script.

The details of this interface will be discussed in a subsequent section. The one drawback in this scheme, as implemented, is that the communication is synchronous. This means that there is no way to interrupt the lisp processing (without killing the job). The user has to wait until the interface is waiting for a user command.

HyperTrauma is the version of the core TraumAID program that will be used in actual care. Its interface is the TraumAID HyperCard stacks. The programs communicate via Apple Events, which are asynchronous interprocess messages available in System 7.

In this scheme, each program is oblivious for whom it is processing a request. Each program defines a protocol for how to communicate with it, and any program that wants to send a message to another program must send the information according to the receiver program’s protocol.

Where it All Happens (John’s account)

What do I need to know to begin?

As with any project where efficiency is a concern, one should feel somewhat comfortable in Lisp before modifying program code.

(in-package :common-lisp-user)

> (in-package :common-lisp-user)

to transfer yourself to that package (when in Lucid). Alternatively, you may include the following alias in you .cshrc file (in your root directory):

alias lisp 'lisp+clos -e "(in-package :common-lisp-user)"'

The Representations in TraumAID

Overview

There are only a few different types of things in TraumAID, yet they can be confusing at first. Especially because the names are not always so intuitive. Nevertheless, most of the names have stuck and without a major overhaul, they may be here much longer than any of us. The next few paragraphs give a general overview of the types of knowledge in TraumAID.

‘Facts’ define the type of knowledge that TraumAID has access to. If a concept is not a ‘fact,’ then it cannot be reasoned with. A fact has properties, such as a SIDE. For example, a WOUND has, among other properties, a SIDE, a WOUND-DIRECTION, and a WOUND-TYPE. Each of these properties is called an ‘attribute.’ Facts are not something that is true or false; they merely define the concepts. ‘Instantiations’ are the objects in the system that represent that current knowledge about the case. So a gunshot wound to the abdomen, on the right side is the kind of information encoded in an instantiation. Instantiations can be true, false, suspected, and in some cases unknown.

The relationship of the knowledge is encoded in the rulebase, in the form of rules. There are currently three types of rules: conclude rules, suspect rules, and procedure rules. They will be discussed shortly.

The ultimate job of TraumAID is to suggest diagnostic and therapeutic action. To drive actions, TraumAID proposes goals. To satisfy goals, TraumAID (the planner) proposes procedures, which are made of collections of actions. Goals, actions, and procedures are themselves subclasses of ‘fact.’

Lastly, there are menus. As part of the interface-independent portion of TraumAID, we define virtual menus, on which to select and report information. There are a few types of menus, depending on the information to present.

Facts

The system is defined as a collection of objects of class "fact" (more correctly sub-classes of fact). When the rule-proving process starts, the system takes the fact objects (originally made in mobjects.lisp) that represent things such as (medical) procedures, actions, therapeutic goals, etc. and instantiates them as objects of some sub-class of "instantiation." This is a little confusing terminology, since fact objects are different from fact instantiations. When it refers to "instantiations" in the program, it means things of the "instantiation" class, not the conventional meaning of an instantiation of a fact. A fact object merely defines the characteristics of the fact.

For example, when an action is to be performed, or even comes up in the chaining process (something like the system is 'considering' it), the system instantiates the action fact as an action-instantiation. The action instantiation contains the dynamic information, such as which rule caused the instantiation, what variables bindings are present, and the like. The fact object tells the system what types of variables should get bound (i.e. get info from the user, like SIDE, BONE-NAME, etc.) when it creates an "instantiation" of the fact.

The system keeps track of instantiations in various places. One place is in the fact object itself, which has an "instances" slot that is a list of instantiations (class instantiation) of that fact. Note that this is NOT another instantiation of the fact (class fact), but an object of class 'xxx-instantiation.' We are warned in logic.lisp that the same instantiation in different places may have different values for its slots. See the note about this in logic.lisp or in the discussion of the instantiation class.

Rx_ "TREAT" convention for therapeutic goals

RO_ "RULE OUT" convention for diagnostic goals

Facts, as with rules, must be numbered uniquely.

User defines attribute types (a class of sorts) in def-attribute-type. Example attribute types are side (Left/Right), or test results (positive/negative). They are like enum types in Pascal. User gives the type name, range of possible values, and whether the values are exclusive (something can't be of more than one type, like test results). def-attribute-type creates an instance of the attribute type and puts it in the system-variables’ attribute-types list, the special-symbols list, and creates a property of the name of the type (property: attribute-type-flavor) that points to the instance in the system variables’ list.

Attribute types are defined in aux.lisp.

Note: ranges of all enumeration types must be unique, since they all end up on the special-symbols list as one big list. That means two types cannot have the same value (such as "Left").

In init.lisp, the (com-add-fact) routine and (com-add-neg-fact) use the function (pick-fact) to get the user to select a fact. Once that is selected, the system looks at the attributes for the fact and prompts the user for values for these attributes (with the menus associated with the attribute objects).

Instantiations

Treating UNKNOWN

If a bedside question is asked, one possible answer is UNKNOWN. This is neither YES or NO, which means any rule that depends on the question being TRUE or the rule being FALSE cannot be pursued. For bedside questions, the program simply records that the question was asked, and does not ask it again. However, it does not commit to either the answer being TRUE or FALSE, which means that any rule that depends on one of these answers will never be fired, in this case. Unfortunately, this situation makes it impossible to distinguish, in the rules, a question being answered as UNKNOWN and a question that has not been asked at all.

Actions (from the planner), as opposed to bedside questions (from the reasoner), can only be TRUE. There is no representation for an action that is explicitly not done and not planned for. When the planner asks questions, it makes an action that has a TEST-RESULT attribute. The TEST-RESULT can be POSITIVE, NEGATIVE, or UNKNOWN. When a TEST-RESULT is answered as one of these values, the program creates a positive instantiation (on fact-true-instantiations for the fact) of the fact with the TEST-RESULT given. It also instantiates TWO false instantiations (on fact-false-instantiations for the the fact) with the remaining two possible values of TEST-RESULT. This means that if a test is positive, the program says 'it is false that the test result is NEGATIVE and it is false that the test result is UNKNOWN.' If the test result is NEGATIVE, the two false instantiations are that the test result is POSITIVE and the test result is UNKNOWN. If the test result is UNKNOWN, then the two false instantiations are that the test result is POSITIVE and the test result in NEGATIVE. One should note carefully what this means: if a test result is NEGATIVE, it means that it is not true that the result is POSITIVE and it is not true that the result is UNKNOWN. If a test result is UNKNOWN, then it is not true that the test result is POSITIVE and it is not true that the test result is NEGATIVE. Note that this does not mean that the patient has or does not have the condition; rather it means that the result of the current test is not conclusive.

One noticeable difference between questions with TEST-RESULT attributes is the difference between questions asked in a test-interpretations menu (such as an X-Ray) and a question asked as a lone action-question (such as Urinalysis_Rbc). For test-interpretation menus, when a person says that a finding is UNKNOWN, TraumAID does not record that the TEST-RESULT is UNKNOWN. Rather, the program does not record anything about that fact. For example, if the user does not say whether X_Ray_Simple_Pneumothorax is POSITIVE or NEGATIVE, then the system does not record that the question was asked.

On the other hand, with lone action-questions, when the user enters the finding (such as Urinalysis_Rbc(UNKNOWN)), the program records that the action Urinalysis_Rbc was true (since the act of asking the question is true), but the TEST-RESULT is UNKNOWN.

One rationale for this inconsistency is that test-interpretation menus are recorded as being done separately from the individual questions on the menu. For example, when the program asks for a Survey_Chest_X_Ray, it records that the X-ray was done, regardless of the answers the user provides. So following the example in the second to last paragraph, the program does not record that the Simple_Pneumothorax question was asked, but it does remember that the chest X-ray was asked.

Rules

nnn: regular rule :-

antecedent1,

antecedent2,

...

antecedentn.

If the antecedents are true, then the consequent is true. A true consequent will then force the reasoner to evaluate the rules that the consequent participates in (participating as an antecedent). This is a forward-chaining process that finishes when there are no more rules to consider.

If any antecedent is false, then the consequent cannot be proven. If some antecedents are unknown (possibly the rest being true), then the consequent is unknown. If all conclude rules cannot be proven, then the conclusion is deemed false.

nnnP procedure-based rule. When the head is

a goal

head-goal :- alternative

procedures

a procedure

head-proc :- actions of

the procedure

a procedure

head-proc :- set of subprocedures

this distinction resolved by type of head (consequent) by

virtue of its class (goal/proc)

The point of procedure rules is to organize knowledge about which procedures can address which goals (the rules with the goal at the head specifies the alternative procedures, in order or preference, that can be used to achieve that goal). The planner uses this information to decide which procedures (and subsequently which actions to perform) to use to achieve the current set of projected goals.

Suspect rules are used to drive the asking of bedside questions. The idea is that if the antecedents of a suspect rule are true, then the fact becomes suspected. From the collection of suspected facts, TraumAID looks through (in a backward chaining fashion) how to conclude that fact. It gathers all the bedside questions (all the facts that can be ASKED) from the conclude rules and then presents those to the user.

nnn? goal suspected if anteceds true

Example:

55? Concl_X :-

Shock.

This says to suspect Concl_X if Shock is true.

60: Concl_X :-

Unconsciousness,

Shock.

If Concl_X is suspected, then TraumAID will add the question Unconsciousness to its bedside questions to ask.

In general, T/Unknown/F. If something in a rule is reported as Unknown, the rule succeeds in assigning Unknown to conseq. Something like that.

100: Some_conclusion :-

! Some_test(RESULT='POSITIVE),

Shock.

101: Some_conclusion :-

Some_test(RESULT='POSITIVE),

Tenderness.

This subsection gives a declarative semantics for the TraumAID inference engine, described by Michael Niv. In the current knowledge base, this covers how findings are mapped to questions and goals, but does not describe the mapping from goals to procedures or procedures to actions.

Facts are abstract concepts and have no truth value. An instantiation is an ordered pair <fact,attribute-value-list>. Instantiations can have the following 'truth' values

Unknown instantiations are not explicitly represented, since some attributes range over (possibly) infinite value-sets (e.g., cycle number) the set of unknown attributes is infinite. No instantiation may have more than one truth value simultanously.

An instantiation may be a question.

[informally: determined by backchaining to be of potential value]

Rules are an ordered quadruple

<rule-number,susp/conclude,antecedents,consequence> where:

The user may enter some instantiations as present and some as absent.

An instantiation is suspected just in case it is provably suspected. An instantiation is known true just in case it is provably true or entered as present. An instantiation is known false just in case it is provably false or entered as absent.

An instantiation i is provably suspected just in case

An instantiation i is provably true just in case

An instantiation i is provably false just in case

A rule is falsified for a particular unifying substitution s just in case it has an antecedent which is falsified.

An antecedent is falsified just in case it has mode '' and

An antecedent is satisfied just in case

An instantiation i is a question just in case

it is suspected

or there is a conclude rule r such that for some substitution s r's consequence is a

question q

and r is not falsified for a substitution compatible with q

(comment: this is good for turning off silly questions)

and i is an antecedent of r with mode ''

Actions

Procedures

Goals

Menus

Some facts are labelled as having FINDINGS menus. This is the same as a SIMPLE menu.

For a list of facts, choose Positive,Negative, or Unknown. Typically, these menus are groups of related questions, such as the results of a test.

This is a new distinction within test-interpretation menus, prompted by menus like ‘Pulses.’ Pulses is a test-interpretation menu, but it is not like an X-ray. For an X-ray, all the results are available at once. For Pulses, each entry is a separate question, and must be addressed individually.

This type of test-interpretation menu (the most common) tells the machine the results of some test, typically an X-ray or report on a chest tube.

def-attribute-type (in readkb.lisp), presumably called in defining the type of an attribute (left/right, positive/negative), creates a menu structure (in :menu slot) consisting of the possible values for the type. These menus are brought up in (ask-attribute), after the user has chosen a fact. Since each fact object contains a list of attributes (bindings), the system knows to prompt the user for values from those attribute menus.

I don't believe the dump-menu-... routines are used anywhere anymore.

During the loading of the knowledge base operation, the system loads the main interface menus (not attribute menus) from the file menu-structure.lisp. It goes through the structured list in that file to create different menus or windows to communicate with the user. Each menu has a 'root fact' from which the system determines the name of the menu to present and what type of menu it should use for that fact (the menu-type field of a fact, e.g. FINDINGS, INTERPRETATIONS, SIMPLE).

We need to pay attention to one special option that is used in the menu structure, the ":not-here" optional argument. For each fact, we record which menus the fact is present on. That way, if we want to know about a fact, we can prompt the user by displaying an appropriate menu. When a fact is followed by the symbol :not-here, as in

(CT_SCAN_ABD

...

(IVP_URETERAL_INJURY :not-here)

...)

it means that the IVP_URETAL_INJURY should be displayed in the menu at the current point, but that we SHOULD NOT RECORD this menu as the place to display when we want to ask about this fact. In this example, we want to display the face in the cat scan of the abdomen (since it can be observed there), but if the system wants to ask about it the system should present the IVP menu (a different test) to the user.

The program on the Symbolics compiles the menus from menu-structure.lisp into a form easily invokable. I have redefined the compilation in a more general way. The compilation produces an interface-independent representation of the menu, and provides a slot in the interface-independent menu object for an interface to hold interface-specific info. During compilation, compile-menu-tree calls an interface-specific function to do its stuff, then puts those results in the slot.

I think the interface-independent representation is better than a purely interface-specific representation because in this way, the interface can be implemented more simply (though it still is not trivial)- Lisp does the work in organizing the information, and the interface merely has to display it.

This requires essentially 3 routines from the specific interface:

1. build a simple menu (for user to choose an item)

2. build a test-interpretations menu

3. display and handle communication between menus (esp. test interp menus) and Lisp when system wants to display such a menu.

1. To do this, we have to build a new window with the items selected. I therefore create a new procedure, with the name of the root string, that displays the window and lets the user select an item.

2. Since all the info in a test interpretations menu could be dynamic, I have only one test interpretation menu and send Wish the info right before it displays the menu. We don't need to hold onto the name of the procedure for displaying the window, since that never changes (TImenu).

IMPORTANT NOTE!

Note that I keep track of the current setting for items in the test interpretations menus in the "interface-hook" slot of the test interp menu structure for the menu. I thought it would just be wasteful to have another slot to hold this information.

CAVEATS concerning details in menu-building:

As I mention in menus.lisp, I think it's a reasonable assumption that before we finish building a menu, we have to build (tell the real interface to build) any sub-menus. That way, when the real interface is told to build the menu, it can rely on the fact that it has already built any sub-menu of that menu (so the information in the interface-specific slot is correct, since it put it there when it built the sub-menu).

Class Hierarchy

Save-Case Formats

The Functional Parts of TraumAID

Motivating Issues

The Rules

The rule processing in TraumAID 2.0 is relatively straightforward, but since it originally was more complex, the code is designed to handle more unusual circumstances (and is therefore more complex than necessary).

The basic way the rules are used is as follows. When the system starts a new patient, some facts automatically become instantiated. You can see which facts these are by looking in the rulebase for rules of the form:

#### Some_Initial_Info :-

Truth.

The Planner (Abigail Gertner)

Plan-ahead has the following steps:

Here is how these steps work in more detail:

There are three top level planning functions: plan-ahead, plan-ahead-and-follow, and construct-plan. All three do pretty much the same thing except that plan-ahead displays the completed plan on the screen. Plan-ahead-and-follow displays the plan and also is responsible for the "let system guide" feature, so it triggers the asking of questions and execution of actions. Construct-plan just returns the completed plan, but doesn't display it on the screen. This is used mainly during the optimization phase.

Basically, these functions work as follows:

If the goals have changed since the last time a plan was created, create and optimise a new plan.

If the goals have not changed but any actions have been done, the plan has to be eoptimized since the new first action in the plan may not be optimal.

Otherwise, there is no need to create a new plan, so the last plan made will be returned.

The planner is basically a nested chain of functions that are called in order and back up whenever there is a failure. This is followed by the optimization phase which I will describe later. The following is a fairly high-level description of this chain of functions. Some of the details have been left out to make it more comprehensible. These details should be commented in the code.

The main function that starts things off is called plan-ahead-for-sorted-tgs and works on a list of goals that have been sorted by priority (actually a function of urgency and priority).

Plan-ahead-for-sorted-tgs works by picking one goal at a time and finding the best procedure to address that goal, in the context of what is in the plan so far. This is done by first calling solve-one-tg.

Solve-one-tg starts off with a list of the possible procedures that may be used to address the goal. It looks to see if any of these procedures are either planned for (which includes being partially executed), or have already been executed. If either of these is the case, that procedure or procedures are chosen as the way to address the goal. Otherwise, a procedure is chosen by choose-and-add-proc.

Choose-and-add-proc goes through the possible procedures for addressing the goal in order and picks the first one that can be added to the plan (without any contraindications, site conflicts, urgency constraints etc.) The adding to the plan is done by add-proc-to-plan.

Add-proc-to-plan first checks that the appropriate resources and personnel are available to carry out this procedure. Then it just calls add-proc-elts-to-plan to add the actions in the procedure to the plan.

Add-proc-elts-to-plan deals with each action in the procedure in turn. It does one of two things depending on whether the action is really an action or if it is a subgoal. If it is an action, it calls add-action-to-plan to add that action to the plan. If it is a goal plan-ahead-for-sorted-tgs is called recursively on the singleton list of that subgoal with the plan already created so far. If, at any time, an action fails to be added to the plan (reasons for this will be described under add-action-to-plan) the function returns 'error, which is propagated back up to choose-and-add-proc, which will then attempt to add the next procedure on the list.

Add-action-to-plan is the lowest level in this chain. It does the actual placing of individual actions in the plan. Each action has a range of sites it can be done in, as well as an urgency, priority, time it takes to do, and specification of how the scheduling of that action should be done (whether to consider urgency, priority, site, etc...).

The first thing that add-action-to-plan does is check a few simple things:

If any of the latter 3 are true then 'error is returned.

If none of these are the case, then we attempt to place the action in the appropriate place in the plan. This is done by looping through the plan constructed so far, adding order constraints between each action already in the plan and the plan we are adding. So, if one action *has* to be done before another because of either urgency (doing one action will take more time than we have before the other action must be done) or precedence constraints (one action must be done before the other because of a potential interaction) this constraint will be added to both actions.

After adding these ordering constraints a couple of final things are done. First, order constraints are added between actions in a single procedure (actions must be done in the order they are listed in the procedure). Next, the plan is checked for circularity -- actions that must be done before actions that must be done before them. If such a case occurs, 'error is returned.

Add-action-to-plan does not actually add all the pairwise ordering constraints that will eventually be in the plan -- just the ones that could result in a circularity, thus affecting whether the action can be added to the plan at all. Instead of fixing the site of an action when it is added to the plan (i.e. before all other actions are added) the site is left as a range and is fixed at the very end of the planning phase. This way, if a constraint appears due to an action added later on in the plan, there will not be an artificially created site constraint blocking one of the actions. The function fix-act-sites was added to determine the site of each action *after* all goals are solved.

fix-act-sites is actually called during the optimization process, after the first phase of optimization -- opt-replace-first-proc-for-more-covering-proc.

Opt-replace-first-proc-for-more-covering-proc is responsible for finding the optimal combination of procedures for addressing the first n goals (where n represents a pre-set optimization horizon). This works by taking the first n goals, one at a time, and creating a new plan by using procedures lower down on the list for those goals. The new plan is then compared to the original, non-optimized plan to see if the use of the alternative procedure results in an overall lower-cost plan.

After the optimization of procedure choices, fix-act-sites is called to determine where each action will be done and the order of actions within each site. Fix-act-sites works as follows:

After the sites have been determined, two more optimizations are applied to the plan. The first is done by opt-rush-to-OR. If there is an urgent goal that must be addressed by a procedure in the OR then any action that takes more than 2 minutes to do will be moved to the OR if it can be done there. Actions that take 2 minutes or less will be left in their original site. Other actions are eliminated from the plan.

The last optimization is opt-avoid-intubation, the purpose of which is to avoid intubating the patient in cases where a chest tube is called for but in which a thoracotomy is planned for in the near future, thus overriding the need for intubation. This optimization works as follows: If a thoracotomy is prescribed and there is a need to intubate then

That's it!

The Reasoner vs. The Planner

We have come to refer to the two principle parts of TraumAID's reasoning as the reasoner, which does forward and backward chaining on the rulebase to propose goals to achieve and questions to ask, and the planner, which attempts to create a plan that satisifies the outstanding goals. It may be observed that they are doing similar things in question-asking. The reasoner produces 'bedside questions,' which are those facts that can be asked about in the course of trying to prove a conclusion. The planner, on the other hand, creates a list of actions, but an action may be a question (such as "Did you cover the wound?"). The planner doesn't 'seek' a question the way the reasoner does: the planner is told, as part of a procedure, that a question should be asked. The rules then can use the result of this question to prove a conclusion that will drive a goal that depends on the answer.

To find bedside questions, the reasoner does back-chaining on those conclusions that it suspects. In the course of back-chaining, it collects a set of questions that can be used to prove or disprove the conclusion. One idea that has been floating around for some time, originally attributed to Ron Rymon, is to replace this backward-chaining, question-seeking process with action-questions, or scheduling all questions by making them actions and letting the planner arrange them. This would make the findings-to-goals simpler, because it would eliminate the back-chaining. It would also eliminate any interference between the question-seeking processes (the reasoner's question-seeking and the planner's question-seeking). So far, we have not pursued this, but it remains a possibility if we want to simplify the program.

Batch Verification

This format enables us to verify that the conclusions remain the same, as well as verifying that the same rules were used to derive the conclusions (as a consistency check). We do not, however, have a means to verify the planner's task—that is the goal of the new batch verification addition. It is important to verify the planner to detect problems that changes to the planner (or rulebase) might impact. The idea is to record not only the conclusions that TraumAID reaches, but also the order in which information is solicited. The new saved case format (Validation Format 2), therefore, records the conclusions TraumAID reached in a case (as usual) and the order in which TraumAID asks questions. The questions currently are of two types, but these types are not mutually exclusive (there is no distinction made within the system, this is only to clarify the type of information TraumAID solicits):

This section describes the previous batch verification system as well as the proposed changes and plan for the new system that incorporates the ordering of information. In the "Problems" section, I briefly outline existing problems in TraumAID with respect to this work.

Each of the findings in the GIVEN- entry is added as a false instantiation, and after each is added, TraumAID invokes any rules that can fire as a result. This is much simpler than the work done for GIVEN+ elements because of the natural restriction on the type of information in the Given as Negative category (we will never see recorded that TraumAID is NOT performing a particular action or test-interpretation menu).

After silly things are removed from these lists (like Add, Eq, or other system-detail propositions), the process prints out the new and old entries.

GIVEN+: Positive Findings

GIVEN-: Negative Findings

SUSPECT: Suspected goals

CONCLUDE+: Concluded goals

CONCLUDE-: Goals concluded as false (eliminated)

GOALS: Goals to pursue

PGOALS: Pursued goals

PPROC: Procedures performed

BULLET-COUNT: Number of bullets

Routines for verifying the new format will not replace the current routines, rather the current routines will be enhanced to support the new validation. In this way, we never lose the ability to verify cases saved in Validation Format One. The reason this path is chosen is that the current routines are used to validate the rulebase, by comparing the conclusions reached with those that have been saved. We still want to verify the rulebase; now we additionally want to verify the planner.

In this section, I discuss the requirements for the new batch verification and the solution implemented.

Validation Format Two contains a CASE_FORMAT entry, for future versions that may want to recognize the format version. Additionally, a file may contain a CASE_INFO entry that records case-specific information.

The principal change here is to give the user different options about loading a case. Loading a Validation Format One case means loading the GIVEN+ and GIVEN- information. Loading a Validation Format Two case means loading the INITIAL_FINDINGS information. This list consists of cons cells whose car is a finding and whose cdr is either POSITIVE_FACT or NEGATIVE_FACT. We treat POSITIVE_FACTs as we did entries in GIVEN+, and we treat NEGATIVE_FACTs as we treated GIVEN- entries.

When a user wants to retrieve a case, it is also possible to specify ‘Load Wounds Only,’ which means to extract and load only the wounds from a Validation Format One case. Typically, the user will choose the ‘SMART’ setting for loading a case, which finds out the version of the case and loads it according to which version it was saved as.

To verify that TraumAID is acting in the same way it originally handled the case, we want to have TraumAID analyze any discrepancies it finds between the saved version of a case and the way it handles the case currently. The analysis we desire is simple: if there are discrepancies, report about the following:

The following algorithm is implemented:

Variable Names (the actual names may be slightly different)

*saved-findings* is a list of findings from the saved case (in

the order which they were recorded)

*new-findings* is a list of findings discovered during the handling of

the case by TraumAID that WERE NOT entered in the saved

case

*current-finding-order* is a variable that records the order in which a

finding is discovered (starting with 0).

(setq *new-findings* NIL

*current-finding-order* 0

*saved-findings* A new list where each 'car' is the findings and

'cdr' is NIL)

;; *saved-findings* is used to record whether or not a saved finding

;; has been observed in the way TraumAID handles the case currently.

;; The cdr will indicate whether the finding is present in the current

;; handling of the case. If the cdr is NIL, it means the finding was

;; not in the current handling. If the cdr is non-NIL, it will be the

;; order it was entered (taken from *finding-order*).

;;

;; This way, when we're done handling the case, any of the findings in

;; *saved-findings* that does not have a non-nil cdr are those absent

;; from the current handling of the case (and hence a discrepancy to be

;; reported). To see how the order has changed, we simply go through

;; *saved-findings* noting if the relative order of the findings

;; remained the same. Here are some examples

;;

;; Ex 1. Ex. 2 Ex. 3

;; ((FINDING1 . 0) ((FINDING1 . 1) ((FINDING1 . 2)

;; (FINDING2 . 1) (FINDING2 . 3) (FINDING2 . 1)

;; (FINDING3 . 2) (FINDING3 . 4) (FINDING3 . 3)

;; ...) ...) ...)

;;

;; In Ex. 1, the order is the same, so there are no discrepancies.

;; In Ex. 2, the relative order is the same, so the only discrepancies

;; will be that *new-findings* will be non-NIL (if there's no finding

;; that is part of *saved-findings* with a cdr of 2).

;; In Ex. 3, the ordering is obviously different, and we can say pretty

;; much how different things are (whether any particular finding is in

;; the same relative order, because the cdrs of its closest

;; predecessor with a number should have a lower cdr value, while the

;; closest following finding with a number should have a higher

;; value). Therefore we can report these situations appropriately.

For each finding TraumAID requests,

1. Find the finding on *saved-findings*

(only search those entries with non-NIL cdrs).

2. If finding is there,

change the cdr to *current-finding-order*

Else

add finding to *new-findings* list with cdr of

*current-finding-order*

3. Increment *current-finding-order*

Implementation Note: These steps are easily implemented by

adding to the function record-finding in init.lisp, which

is called each time a new finding is reported. The finding

is reported as an object (instantiation or question), so we

use the same matching procedure that the original batch

verify uses to match TraumAID's objects (the result of the

current handling of the case) with the objects in their

printed form (from the saved case). This function will

be modified to call match-and-update-finding, in

batch.lisp, which will perform all these steps.

If *new-findings* then report new findings that were added

Go through *saved-findings* seeing if relative order of cdrs agrees

with the implicit ordering of *saved-findings* (since it is in the

order the findings were encountered in the saved case). Report

discrepancies. If a finding still has a NIL relative order, report

that the finding was never requested.

When a case is saved in Validation Format Two, we include a list of the findings TraumAID received during the course of diagnosing and treating the patient (currently REST_OF_FINDINGS). For batch verification, we want to make sure not only that the conclusions are the same, but also whether or not TraumAID needed all the information (or more) than when the case was actually saved.

The algorithm presented above resolves this problem as well as recognizing different plan orderings. If a finding has a NIL relative order, it means that finding was never sought by TraumAID in the current handling (verification) of the case.

N.B. One issue which is not resolved in this implementation of this is the impact of a finding being volunteered during question. Typically, the REST_OF_FINDINGS will consist of questions (tests) or actions that TraumAID asks either of the user or for the user to perform. It is possible, though, that during the original handling of the case, the user entered a finding voluntarily, that is without TraumAID asking for it. This finding is recorded at the point it was entered, but during the handling of the case for batch verification, the user is not given an opportunity to enter voluntary information (all the findings must be solicited by TraumAID). Therefore, there will be a discrepancy which may or may not be important to the handling of the case (depending on whether TraumAID finds that information relevant).

The first option is clearly whether to verify the cases in Validation Format One or Validation Format Two. Cases saved in Validation Format Two can be run through the Validation Format One process, since the CONCLUDE+, SUSPECT, and QUESTION elements still appear in the saved case. Typically, though, the user will run using Validation Format Two.

The other options given to the user (assuming Validation Format Two) are:

CASE_FORMAT: For future distinctions (cadr is a string

representing which format the file is saved in).

THIS MUST APPEAR FIRST (AFTER COMMENTS) IN THE

FILE.

CASE_INFO: Information about the case or patient

INITIAL_FINDINGS: Findings reported upon patient arrival

REST_OF_FINDINGS: Questions, Findings, and Actions entered

during diagnosis/treatment

OTHER_AVAILABLE_FINDINGS: Findings that were present during the case handling, but not provided as part of the case stem or asked by TraumAID during the case handling.

SUSPECT: Suspected goals

CONCLUDE+: Concluded goals

CONCLUDE-: Goals concluded as false (eliminated)

GOALS: Goals to pursue

PGOALS: Pursued goals

PPROC: Procedures performed

Notice we do not have GIVEN+, GIVEN-, or BULLET-COUNT as this information is available from INITIAL_FINDINGS.

Default Answers

Defaults show up in the saved case as the symbol DEFAULT, which precedes any question or entry that was derived from the default processing. During batch validation, TraumAID strips away the DEFAULT markers, and reapplies them if the case is to be stored again (meaning there was some change to the case). If an entry in a saved case was derived by default, and during the handling of the case currently (during batch validation) the system asks for the information, the system does not report the results from the file, rather it rederives the default (from the default processing). In this way, we can recognize when a default answer is different from a default answer that was part of the saved case.

The TraumAID Program Layout

The TraumAID Core

The part of the program identified as the core is the part that does not change from platform to platform, and in general does not concern itself with interface issues. It is the part that implements the reasoning in TraumAID.

The Interface-Independent Module

The Knowledge Base

CLASS-DEFS: The lexicon contains all names used in the system and their attributes:

- numeric name,

- whether it is askable

- what section of status to display it in (given/conclude/no_section)

- what kind of menu it is the head of (no_menu,interpretations,simple)

- what is its priority as a question

- what is its priority as a treatment

AUX: the aux file contains more information about facts:

- lists of related facts to be grouped as questions

- items of the form (context . fact) which restric the context in which

some facts should be asked as questions

- the part-of anatomical hierarchy

- safe assumptions

- autoasserts

The menu structure encodes the menu tree. The type of menu for a particular fact is determined by the fact’s MENU-TYPE slot.

The Interface-Specific Modules

The communication is clearly synchronous, which, although adequate, may ultimately be undesirable. The problem with making the communication asynchronous is that we would need a way of getting the attention (like an interrupt) of the processes while they were running. There may be solutions (polling, or defining routines that get called in idle system moments), but we have not pursued them.

Essentially, the Lisp process (LP) and the Wish process (WP) have two modes

1. The LP is the reader and the WP is the writer

2. The LP is the writer and the WP is the reader

The LP controls when the roles are changed. In Mode 1, the WP waits for user commands, such as Add Fact, etc. When it receives a command, it sends it to the LP which is waiting for information. The LP then takes control of the writing, and the WP listens. If the LP has information to display, or wants the WP to take some further action (such as put up windows for question answering) it goes into Mode 2, sending a message to the WP with the request. When the LP is done, it tells the WP and goes back to Mode 1.

Although on the Suns this is implemented in multiple processes, it does not have to be, since the flow-of-control is completely sequential (no asynchronous operations necessary). The LP is the real controller here, since it forks a process that runs the wish subprocess.

The Lisp process can be characterized by the following algorithm:

Create I/O streams

Make WP (Wish Process) writer, LP reader.

Loop until user quits {

/* Invariant: at this point, LP is reader and WP is writer */

Wait for some command from user (WP)

If user quits, exit loop

Upon some information, invert reader/writer roles of LP & WP

/* Invariant: at this point, LP is writer and WP is reader */

LP processes request,

sending output to WP when appropriate,

OR

If LP wants to direct questioning or get info from WP,

Send questions to WP

LP sends end-of-transmission message to WP

invert reader/writer roles back to start of loop

}

The sending part is very straightforward. Based on events in the WP, the WP sends a predetermined code to the listening Lisp process. The LP has a hash table, keyed by these codes, containing functions to invoke when the code is passed.

The LP has a function "define-trauma-command" which registers which function to call when a button (or what I call more generally 'a field activator') is activated.

Part II — Using TraumAID

General Operation

Standalone

Batch Verification

With HyperCard on the Macintosh

Extending/Revising TraumAID

Changing Existing Code

Writing new Trauma Commands

Running & Using TraumAID

X-Trauma

Type

~jclarke/run-xtrauma

Note: Because TraumAID is now compiled, you must be on a Sun 4 (LINC, UNAGI, SAUL, CENTRAL, etc.) to run it. Of course you must also be at a terminal capable of running X-Windows. Some of the HPs, however, cannot run Wish (probably because of the way Wish was setup rather than anything inherently weird about Wish), so you can't run TraumAID using some of the HPs as X-terminals.

You first need to load the defsystem. You do this by

(load "~jclarke/Xtrauma2/defsystem")

Since CLOS is already built into our images of Lucid 4.1, you do not need to load CLOS. If your Lisp image does not contain CLOS already, you would have to load it at this point.

(require "xtrauma")

or

(require "textrauma")

depending on which system you want to use. Once this is done, Lisp will load the appropriate system. To run TraumAID at this point, you must be in the common-lisp-user package, if you are not there already. To get into this package, type

(in-package :common-lisp-user)

alias lisp 'lisp -e "(in-package :common-lisp-user)"'

Now, to run traumaid, type

(traumaid)

(operate-on-system "xtrauma" :compile :force :new-source)

This recompiles source files which were modified since being compiled

(operate-on-system "xtrauma" :compile :force :all)

Recompiles all source files

(operate-on-system "xtrauma" :compile :force

:new-source-and-dependents)

The reason there isn’t much help available is that this a new feature, and no one has spent the time to add more information. You can easily add new topics and information, by following the format for the information in the file. The format is very simple, consisting of: