Pay No Attention to the Man Behind the Curtain

Pay No Attention to the Man Behind the Curtain^*

Gail E. Kaiser and Wenke Lee
Columbia University
Department of Computer Science
New York, NY 10027
kaiser@cs.columbia.edu
April 7, 1996

The first author has worked on process-centered software engineering environments since 1986, originally in the Marvel^** project [1,2] and later the Oz ⁺ project [3,4]. Process is the term used in the software engineering community to refer to workflow, and a process-centered environment is a form of workflow automation and management system. While long aware that process modeling and enactment are general-purpose technology applicable to many domains, we only recently investigated specific workflow applications outside software engineering -- most notably healthcare. We provide brief background information on Oz, discuss our preliminary results in workflow automation for care plans, and conclude with evaluation and future directions.

Oz Background

Oz provides a rule-based process modeling language in which to define new processes or tailor reusable processes for an organization or project. A rule generally corresponds to a workflow step, and specifies the step's name as it would appear in a user menu or agenda; typed parameters and bindings of local variables from the project objectbase; a condition that must be satisfied before initiating the activity to be performed during the step; the tool envelope and arguments for the activity; and a set of effects, one of which asserts the actual results of completing the activity.

The process engine enforces that rule conditions are satisfied, and automates the process via forward and backward chaining. When the user requests to perform a step whose condition is not currently satisfied, the system backward chains to attempt to execute other rules whose effect may satisfy the condition; if all possibilities are exhausted, the user is informed that it is not possible to enact the chosen step at this time. When a rule completes, its asserted effect may trigger automatic enactment of other rules whose conditions have now become satisfied. Both procedures operate recursively. Users usually control process performance by selecting rules representing entry points into tasks consisting of one main rule and a small number of auxiliary rules (reached via chaining), but it is possible to define complete workflows as a single goal-driven or event-driven chain. Built-in operations such as add an object, delete an object, etc., are modeled as rules for a uniform approach.

Oz supports object-oriented data definition and query languages. A class specifies one or more superclasses, primitive attributes (integers, strings, timestamps, etc.), file attributes (pathnames to files in an intentionally opaque ``hidden file system''), composite attributes in an aggregation hierarchy, and reference attributes allowing arbitrary 1-to-N relations among objects. Ad hoc and embedded (in rules) queries may combine navigational and associative clauses. Rules are treated as multi-methods and perform all data manipulation. Commercial off-the-shelf (COTS) tools and other external programs are interfaced to an environment through shell script envelopes, using augmented notation that hides from tool integrators the details of accessing the ``hidden file system'' and passing input and output parameters [5]. A return code from the envelope determines which of the several rule effects is asserted.

Oz employs a client/server architecture. Clients provide the user interface and invoke external tools. Servers context-switch among multiple clients, and include the process engine, object management, and transaction management for concurrency control and recovery. An Oz environment consists of one or more servers (sites), each with its own process model, data schema, objectbase and tools. Clients are always connected to one ``local'' server, and may also open and close connections to ``remote'' servers. Servers communicate among themselves to establish Treaties -- agreed-upon shared subprocesses, and to coordinate Summits -- Treaty-defined process segments that involve data and/or users from multiple sites. We stretch the International Alliance metaphor a bit, since Treaties among sites precede and specify Summits rather than vice versa.

We have developed production environments for process model construction, testing and evolution, C programming, latex document processing, and teaching assistant support, and have been using Marvel or Oz in our daily work since January 1992. Demos range from 5-queens and blocks world exercises to C++ and Ada development. The environment we use for continued Oz development contains about 280k lines of code with (at last count) about 972 objects, 78 rules, 27 classes, and 32 tool envelopes in the baseline site (there are additional and different components in the workspace sites). Oz is implemented in C, lex and yacc, runs on Unix, and provides tty, X11-based, and Web-based user interfaces.

Healthcare Applications

A care plan is a specified process for caring for a particular illness or condition; it outlines specific procedures and protocols to be carried out at certain points during treatment and/or recuperation. Care plans are defined most commonly in manual forms, where healthcare workers are expected to adhere to the textual lists of recommended practices through ``check off'' compliance. Studies have shown that adherence to the manual plans reduces lengths of hospital stays by 30% and the cost of care by 20-25% [6]. It is widely believed that computer-automated care plans will result in more substantial savings.

A care plan is a form of workflow because it describes the steps for delivering healthcare to patients. However, care plans have some unique characteristics: There are thousands of existing standard care plans and the number is growing. More significantly, when each care plan is used in practice, it is to be delivered to a specific patient and every patient can have individual circumstances that make a ``one-size-fits-all'' plan inappropriate. While in some other domains staff might be required to stick to policies, even at the cost of individual creativity, to guarantee a high degree of quality assurance, a physician should not be forced to follow standard care plans under ``unusual'' situations.

Requirements for Care Plan Management

A care plan workflow system must have a general approach to modeling and managing care plans, given the sheer numbers of care plans to be supported. It must also be specific enough to give precise guidelines for each patient, based on patient data from other components of the clinical information system. It should provide attractive features to try to entice physicians and hospital administrators to use the system.

From the data management point of view, a care plan consists of a set of care elements, which are medical care events (tasks). Each (instance of a) task must be associated with a patient's medical record number (MRN), which is the key used to retrieve all demographic and medical information about the patient. Each task is assigned a group of care givers (physicians, nurses, therapists, etc.).

From the medical care point of view, each care element has a medical activity (task), and its start time and stop time. The start time is used to schedule the task and the stop time is the deadline for completion of the task. When scheduling tasks, resources such as available hospital beds, operating rooms, etc. must be considered; when assigning care elements as tasks to care givers, their specialities and availabilities (schedules) need to be considered. Before a task can be carried out, some preconditions must be satisfied. These can be categorized into logistic conditions (e.g., the task has been assigned and the care giver is available) and medical conditions (e.g., patient's vital signs have been stable for the past 24 hours). The evaluation of the medical preconditions normally requires invocation of the Medical Logic Modules (MLMs) [7] associated with the task. Each task, when finished, also has postconditions used in determining which task(s) to carry out next. Again, MLMs may be used to obtain ``expert system'' medical advice to evaluate the current state of the care plan. For example, if the task is completed normally, the original care plan (a set of pre-scheduled tasks) can be continued; otherwise, additional medical procedures may be added to the care plan or even the entire care plan may be replaced.

From the hospital administration point of view, the workflow system should monitor the progress of care plans. It should generate reminders for pending tasks as well as alarms for past due (not yet completed) tasks. It should also track the MLMs invoked, their suggestions, whether the suggestions are actually taken by care givers, and their success/failure rates. It should instrument what tasks are delayed most frequently and the possible causes. The care plan system must be an integral part of a clinical information system, for example, it needs to communicate with the patient database, event monitors and MLMs using the standard Health Level 7 (HL7) format for information exchange [8].

OzCare Prototype

We studied manual care plans, for Physical Therapy and Occupational Therapy following open knee surgery, supplied by the Columbia-Presbyterian Medical Center (CPMC). We then developed a prototype system on top of Oz, called OzCare, that automates these care plans. The principles and techniques behind this prototype are general, so we expect they would apply to most other care plans.

Since a care plan specifies a set of care elements (workflow steps), it is tempting to model a care plan as an Oz process so that each care element is one or more Oz rules. But there are thousands of standard care plans and any given patient's care plan may be a variant of some standard one. Mapping care plans to Oz processes would mean a set of Oz rules for at least each standard care plan, possibly for each patient, resulting in rule bases several orders of magnitude larger than the typical hundred or so in our production processes. Although Oz supports a form of process evolution [9], it does not allow for the kind of dynamism that would be needed to alter care plans on the fly; thus all possible contingencies would need to be described in the original care plan (facilitated by the multiple effects per rule).

We took an alternative approach: We defined a general data schema for arbitrary care plans, and a process model for manipulating care plan objects. A care plan is a set of care elements, each of which represents a medical activity (no direct relation to the activities of Oz rules); see Figure 1. Such a care plan is treated as a ``template'' object, which is instantiated (copied) for each admitted patient. A patient-specific care plan can be obtained by modifying the copy. Thus healthcare workflows are directly reified in the objectbase, and interpreted by the process model (whose rules are not represented in the objectbase).

PATIENT_CARE_PLAN :: superclass ENTITY;
 name : string;
 care_element : set_of CARE_ELEMENT;
 report : text;
 start_date : time;
 ...
end

CARE_ELEMENT :: superclass CLINICAL_EVENT;
 care_giver : set_of link HEALTHWORKER;
 MRN : string;
 start_time : time;
 stop_time : time;
 assign_status : (None, Assigned) = None;
 report : text;
 queue_status : (None,ToBeQueued,EventQueued,Queued,Dequeued) = None;
 state : string = OK;
 source : (Standard, Specific) = Standard;
 pre_mlm : MLM;
 activity : string;
 post_mlm : MLM;
 ...
end

Figure 1: Data Model Fragment for Care Plan and Care Element

We identified a general set of policies and functions that control the execution of the care elements (the activities), which are then modeled as Oz rules. Figure 2 shows an example. This ReportCareElement rule is invoked when a care giver reports the completion of a care element. Note that the rule activity, report_element, is implemented by a tool envelope. Within this tool envelope, the MLM for the care element is invoked and its result returned -- through a rather complex series of intermediaries since the MLM server is located on a remote mainframe at CPMC. Clinical events at CPMC may also cause the MLM server to asynchronously communicate with Oz, triggering rules that modify care plans or otherwise update the workflow state.

ReportCareElement [?care_element:CARE_ELEMENT, ?report:LITERAL,
                   ?vital_signs:LITERAL]:
 (and (exists MLM ?mlm suchthat
	(member [?care_element.post_mlm ?mlm]))
      (forall HEALTHWORKER ?worker suchthat
	(linkto [?care_element.care_giver ?worker]))
      (exists PATIENT ?patient suchthat
	(?patient.MRN = ?care_element.MRN)))
 :
 (and (?care_element.status <> Reported)
      (?care_element.status = CheckedOut))
 {CarePlan_tool report_element ?care_element.report ?report
			       ?care_element.Name ?care_element.MRN
			       ?mlm.name ?mlm.input ?vital_signs
			       return ?report_status ?mlm_output}
 (and (?care_element.update_time = CurrentTime)
      (?mlm.output = ?mlm_output)
      (link [?patient.track_record ?care_element])
      (link [?worker.track_record ?care_element]));

Figure 2: The Report Rule

One particular difficulty for process modeling was the notion of timed events -- events that must start and end at (or before or after) certain times (or at certain intervals). Although Oz already had a built-in primitive time type, it is rather weak at expressing and processing temporal constraints (there are few software engineering tasks that must be repeated at, say, four-hour intervals and not be more than 30 minutes early or late). We therefore used the general-purpose shell script capabilities of envelopes to make complex time calculations. Further, we defined in the schema an EVENT_QUEUE and an ALARM_QUEUE. Care elements are placed in the EVENT_QUEUE based on their start_time, and in the ALARM_QUEUE based on their stop_time. A Unix cron job periodically brings up a ``batch'' Oz client (an option to the dumb terminal client that already existed for other purposes) to check the two queues and generate alerts.

One pragmatic requirement imposed by the healthcare community is that the system should be integrated into the World Wide Web (WWW) [10]. WWW provides a standard graphical user interface (Netscape Navigator is the de facto standard), easy access to information from the National Library of Medicine, and permits collaboration among healthcare-related institutions spread across the country.

In our prototype, the users interact with Common Gateway Interface (CGI) forms through a regular Web browser and never see Oz's native user interface; the CGI scripts are processed by a normal Web server. After several false starts to communicating with the relevant Oz server, which introduced security loopholes⁺⁺ and/or great inefficiencies, we decided to have each CGI script: (1) accept the user's input on the submitted form; (2) generate an ad hoc query or rule invocation based on the input; (3) send this input via a Unix pipe to a special Oz ``pipe'' client to execute the commands and return the output on another pipe; and (4) parse and format (in HTML, the HyperText Markup Language) the output and send it back to the Web browser.^%

Evaluation and Future Work

We were able to implement the prototype care plan management system relatively quickly, about 3.5 person-months, with only 200 lines of Oz code changed (all bug fixes); the new ``pipe'' client was added on later to improve performance. This shows that the Oz process technology is general enough for at least one major workflow domain unrelated to software engineering. We have received very positive feedback from CPMC.

However, some improvements are in order. Although tool envelopes (external programs) can do complex time calculations, it would be better to extend the rule language with a rich set of temporal operators, such as before, ago, after, later, until, and between. We also need some direct means to express repetition at time intervals (repetition whenever some non-time-based condition becomes satisfied is already supported, e.g., for the edit-compile-debug cycle). A user-friendly presentation of the ``big picture'' of progress through a multi-step subprocess such as a care plan -- preferably in graphical form -- would be helpful in orienting the user. We are looking into coupling Oz with TeamWare activity networks [11] (which were designed with non-technical users in mind) for this and other purposes.

The healthcare venue had the side-effect of sparking our interest in WWW technology as a general user interface paradigm for workflow systems, without requiring hand-construction of a hoard of CGI scripts for each application. We have recently developed a generic approach whereby a modified Oz client operates as a proxy server between Netscape browsers and arbitrary Web servers [12].

Acknowledgements

Paul D. Clayton, Steve Luxenberg, Eric Sherman, James J. Cimino, George Hripcsak, Robert Jenders, and Justin Starren at CPMC provided crucial direction and input to this research. We would also like to thank Jeff Do, Steve Linde and Peter Skopp for their work on the CGI-bins and alternative Oz interfaces for OzCare, Issy Ben-Shaul for his sample CGI interface to Oz, and Richard Baldwin for his help with demo screens. Steve Dossick and Jack Yang are working on new approaches to integrating WWW and Oz. Marvel and Oz are available without support; send email to MarvelUS@cs.columbia.edu for licensing information. Manuals can be accessed via anonymous ftp.

This paper is based on work sponsored by Advanced Research Project Agency under ARPA Order B128 monitored by Air Force Rome Lab F30602-94-C-0197, National Science Foundation CCR-9301092, and New York State Science and Technology Foundation Center for Advanced Technology in High Performance Computing and Communications in Healthcare NYSSTF-CAT-95013. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the US or NYS government, ARPA, Air Force, NSF, or NYSSTF.