Using ECA Rules in Database Systems to Support Clinical Protocols

Using ECA Rules in Database Systems to Support Clinical Protocols 1

Kudakwashe Dube , Bing Wu1, and Jane B. Grimson2 1

Computer Science, School of Computing, Dublin Institute of Technology, Ireland {kudakwashe.dube, bing.wu}@dit.ie 2 Computer Science, Trinity College Dublin, Ireland [email protected]

Abstract. Computer-based support for clinical protocols or guidelines is currently a subject of a lot of interest within the Healthcare Informatics community. The Event-Condition-Action (ECA) rule paradigm, as supported in active databases and originating from production rules in expert systems, promises to be of great potential in supporting clinical protocols or guidelines. The problem being addressed in the authors’ work is that of managing complex information encountered in the management (i.e., the specification, execution and manipulation as well as querying) of clinical protocols whose specification and execution models are based on the ECA rule paradigm. This paper presents a generic framework and a mechanism for the management of ECA rule-based protocols using modern database technology.

1. Introduction Computer-based support for clinical guidelines and protocols1 is currently a subject of active research within the Healthcare Informatics community. Current approaches to computer-based support for clinical guidelines focus mainly on providing expressive specification languages and execution mechanisms that provide enough flexibility and ease-of-use for them to be acceptable by clinicians in daily routine patient care. An important aspect that is lacking in these approaches is the support for easy integration of the guideline support mechanisms with the electronic patient record systems. The Event-Condition-Action (ECA) rule2 paradigm, as found in active databases and originating from production rules in some expert systems, promises to be an effective means of representing, sharing, enforcing and managing medical knowledge and expertise in the form of clinical protocols. Researchers have highlighted several advantages of ECA rules within database systems [3][4][5][6][7]. The use of the ECA 1 A clinical guideline is “a set of schematic plans, at varying levels of detail, for the management of patients who have a particular clinical condition (e.g. insulin-dependent diabetes)” [1]. Clinical protocols are highly detailed clinical guidelines and are usually mandatory [2]. In this paper, the terms clinical guideline and clinical protocol refer to the same concept and are interchangeable. 2 An ECA rule monitors and reacts to a situation by performing a relevant action or task. Situation monitoring involves detecting an event of interest and evaluating a condition associated with the event. The action is performed only if the condition holds [3]. R. Cicchetti et al. (Eds.): DEXA 2002, LNCS 2453, pp. 226–235, 2002.  Springer-Verlag Berlin Heidelberg 2002

Using ECA Rules in Database Systems to Support Clinical Protocols

227

rule paradigm with database technology also promises to provide an excellent framework for integrating guideline and patient record systems. The rest of this paper is organised as follows: Section 2 covers related work in computer-based support for clinical guidelines/protocols. Section 3 presents our framework for supporting the management of ECA rule-based clinical protocols. Section 4 briefly outlines our ECA rule-based model and language, called PLAN (Protocol LANguage), for specifying clinical protocols and briefs on the database for storing protocol specifications. Section 5 presents the architecture that would support the framework, presented in Section 3, for specifying, storing, executing and manipulating clinical protocols. Section 6 briefly presents a summary and discussion of the framework and architecture, the current and future work. Section 7 concludes this paper.

2. Related Work This section gives a brief survey of the computer-based support for clinical guidelines with focus on those that use the rule-based formalism. Of special interest to the authors are the guideline support approaches that make use of the ECA rule paradigm in database systems. Several guideline modeling frameworks, architectures and representation languages have been developed for computer-based support of guideline-based care [2][8][9][10][11][12][13][14][15]. More recent approaches make use of Internet Technology such as HTML and XML [16][17][18]. One of the main reasons for the general lack of widespread use of these guideline systems is the difficulty associated with integrating these systems with the medical record so that the systems use the patient’s data and present guideline knowledge at the point of care while the clinician is accessing the patient’s data [1][19]. To the best of the authors’ knowledge, only two previous efforts have been encountered that apply the ECA rule paradigm in supporting clinical guidelines/protocols. These efforts are: the Arden Syntax and Medical Logic Modules (MLMs) [20]; and HyperCare [21]. The Arden Syntax is a language for encoding medical knowledge bases that consists of independent modules, the MLMs. MLMs are ECA rules stored as separate text files. An MLM is a set of slots categorised into maintenance information, library information, and the actual medical knowledge [22]. The knowledge slot is expressed in the ECA rule format and is the core of a MLM. The MLMs have been applied to generating alerts, patient management suggestions, management critiques and diagnostic scores3. Attempts have also been made to build complex care plans and clinical guidelines/protocols by chaining MLMs in such a way that the action of one MLM evokes the next MLMs [25][26][27]. Since MLMs specifications are stored as individual text files, they cannot be queried and manipulated easily4. As a result, a limitation of the Arden Syntax, which is important to this work, is the lack of support 3

4

The Arden Syntax is currently the only standard for sharing and encoding medical knowledge among systems in various medical institutions[23][24], which is an indication of the promise the ECA Rule paradigm has as a viable technology. In a study to quantify changes that occur as an MLM knowledge base evolves, 156 MLMs developed over 78 months were studied and 2020 distinct versions of these MLMs were observed. It was also found out that 38.7% of changes occur primarily in the logic slot while 17.8% and 12.4% of the changes occur in the action and data slots respectively [28]. For instance, changes in laboratory testing can cause disruptions in MLM execution unless the code of these MLMs is revised and modified [29].

228

K. Dube, B. Wu, and J.B. Grimson

for the manipulation, querying and the resultant difficulty in maintenance of the MLMs specifications. HyperCare [21] is a prototype system that employs the ECA rule paradigm in the active object-oriented database, Chimera, to support clinical guideline compliance in the domain of essential hypertension. The limitations of HyperCare are: 1) the difficulty in managing the rules making up the protocol; 2) lack of support for dynamic manipulation, querying, versioning and customisation of clinical protocol specifications and instances; and 3) it is an implementation of a specific guideline and does not attempt to provide a generic formalism to support similar protocols. In summary, the Arden Syntax and HyperCare make use of the ECA rule paradigm to support clinical protocols. Both the Arden Syntax and HyperCare do not create patient-specific instances; instead rules operate at a global level. The approach presented in this paper differs from the above works in that it permits generic clinical protocols not only to be declaratively specified, stored, and executed but also to be dynamically manipulated (i.e. operated on and queried) at the individual patient level, with both the specification and its instances being manageable on a full-scale.

3. Framework for the ECA Rule-Based Support for Clinical Protocols This section describes the framework for the computer-based support for the management of clinical protocols. The managed protocols guide the care of patients within clinical categories, which may be disease-based, such as diabetes mellitus and/or its sub-types: type I and type II. The challenge is to provide each patient with an executable care plan that is appropriate for the management of the patient’s clinical condition based on the patient’s recent pathology. The framework, illustrated in Figure 1, consists of the three planes: specification, execution and management of the protocol specifications and their instances, the individual patient care plans (Figure 1(a)). Protocol specifications are created in the specification plane. A declarative specification language, PLAN, is used to describe the protocol [30]. In the execution plane, the customisation of protocols produces plans that take into consideration the individual patient’s condition and recent pathology. Also in the execution plane, the patient’s care plan is executed. Execution state data is generated and made available for querying and decision-making. The protocol specifications and their instances are managed in the manipulation plane. The interaction between the specification and the execution aspects of the problem is illustrated in Figure 1(b). It involves: 1) the customisation of a generic specification to suit a specific situation (patient condition); 2) the instantiation of a customised specification; and 3) the propagation of dynamic changes between the specification and the executing instance. Interaction between the manipulation and the specification aspects involves: 1) the querying of specification’s components; 2) the manipulation of specifications such as adding, deleting and modifying components; and 3) the maintenance of versions of the specifications. The interactions between the manipulation and execution planes involve the dynamic querying and manipulation of the execution process. Central to the three planes, are the ECA rule mechanism and the database that form the core technologies employed in this approach.

Using ECA Rules in Database Systems to Support Clinical Protocols

Patient Plan Rules customised to monitor patient record

EXECUTION Plane

ECA Rules Each ECA rule maps to one or more database triggers

MANIPULATION Plane

Patient Plan

Operations and Queries

Protocol Linked to individual patient

Static & Dynamic Manipulation & Querying

SPECIFICATION Plane

Clinical Protocol

229

Customisation, instantiation and change propagation

Specification y, er n Qu tio n a io ul ip e r s n c e n v Ma n d e n a a int a m

ECA Mechanism + Database

Execution Q in u e r m ter y, d an ac yn ip tio a ul n m a t a ic io n d n

Management

Database Triggers

(a) Planes for supporting the management of clinical protocols

(b) Interactions between the specification, execution and manipulation planes

Fig. 1. Framework for supporting the management of clinical protocols using event-conditionaction (ECA) rules in a database system

In summary the framework presented here aims at allowing static and dynamic aspects of clinical protocols to be easily manageable on a full-scale. The next sections outline how this is achieved.

4. ECA Rule-Based Clinical Protocol Specification This section briefly outlines the PLAN model and language. For more details on PLAN, the reader is referred elsewhere [30]. Figure 2 illustrate the entity-relationship model for a clinical protocol specification. Patients are put into clinical categories and subcategories. Each category has a clinical protocol defined for it. A Clinical Protocol is a generic care plan consisting of ECA rule-controlled clinical tasks for the management of patients. The clinical protocol is made up of a collection of a set of schedules and one protocol rule set for managing a patient in a clinical category. Each patient is associated with a care plan, which consists of one schedule and one set of dynamic rules. The plan is derived from customising the generic protocol to suit the Fig. 2. Entity-Relationship Diagram patient. A schedule is a set of static5 rules, for the clinical protocol specification which is a time-driven rule that schedules using the ECA rule paradigm clinical tasks. The schedule also contains as a set of schedule rules. The Schedule, when contained in a patient plan, is a collection of static rules only. Only one schedule is required for a plan. Each schedule in a protocol is associated with entry criteria to be satisfied by a patient before the schedule is selected to be part of the patient’s plan. Patient

Care Plan

Clinical Category

Clinical Protocol

Schedule

Protocol Rule

Schedule Rule

Static Rule

Dynamic Rule

ECA Rule

5

The concept static for describing a rule refers to the idea that the firing time of the rule is predetermined and definite on creation of the rule. Static rules usually react to time events.

230

K. Dube, B. Wu, and J.B. Grimson

The Schedule and the Protocol Rule sets modularise the rules into two distinct sets with elements of one set interacting with elements of the other set. Schedule rules and protocol rules are dynamic6 rules, which are placed into one set when creating the patient plan. A Dynamic Rule is an ECA rule that monitors: 1) the state or effects of actions of a static rule or set of static rules and conditionally performs an action; and/or 2) the condition of a patient as reflected in in-coming test results and takes appropriate action. The plan has the ability to monitor and react to: 1) changes in the patient condition over time; and 2) feedback in form of test results and other measurements of the patient’s attributes. Figure 3 (a) illustrates the syntax of a Static Rule. Figure 3 (b) illustrates a Dynamic Rule. Figure 3(c) and 3(d) illustrates examples of static and dynamic ECA rules taken from a protocol for diabetes management. := ON STARTING EVERY ENDING [IF ] DO := , := period in milliseconds := , := list of actions relevant to this rule

(a) The syntax for the time-driven static ECA rule in BNF When the patient’s HbA1c result has been obtained, if the result is greater than or equal to the previous HbA1c result and the patient is in the type 2 diabetes mellitus category, then give the patient advice on diet and exercise. Rule: ON resultArrival(HbA1c) IF result(“HbA1c”) >= previousResult(“HbA1c”) ) AND subtype = “diabetes type 2” DO advice(diet_and_exercise)

(c) An example dynamic rule for diabetes management

::=ON IF DO { } ::=patient-entry | lab-result-arrival | new-test-order | execution-state-change ::= | ::= | , ::=store-message | send-alert | return-value | perform-management-operation

(b) The syntax of the dynamic ECA rule in BNF

Every two weeks before the date of the next consultation, perform HbA1c test. Rule: ON STARTING TODAY EVERY consultation_date – 14 days ENDING indefinite DO order(“HbA1c”)

(d) An example temporal/static ECA rule for diabetes management

Fig. 3. The Specification of clinical protocol rules in the PLAN language

A clinical protocol specification is initially created and saved as a text file in PLAN language. After being parsed, the protocol specification and the attributes of the protocol are stored in relational tables of the protocol specification database. Storing the protocol specifications in a database allows queries and manipulation operations to be performed on components of the specification. Individual specifications of ECA rules and other components such as entry criteria can be added, deleted, modified, and queried. This would be difficult if text files only were to be used, as is the case for MLMs [28]. While XML documents can be queried, manipulation operations such as deletions and insertions of components of the XML 6

The concept dynamic refers to the fact that whether or not the rule will fire and/or execute is determined dynamically depending on the situation at any point as the execution process proceeds.

Using ECA Rules in Database Systems to Support Clinical Protocols

231

documents are not yet as easy as manipulating structured data in relational tables. The next section presents the architecture for executing and manipulating the clinical protocols that have been specified and stored as described in this and the previous sections.

5. The Architecture for Supporting the Management of Clinical Protocols This section presents the architecture for supporting the management of clinical protocols using of ECA rules. As illustrated Figure 4, the architecture has three layers. External to the system are users and external systems. The top layer is the clinical protocol management functionality that allows users to specify, store, execute manipulate and query clinical protocols and external systems to supply and receive information from the system. The middle layer provides services that 1) extend the ECA rule execution mechanism of the underlying database system and 2) handle connections to the database. The bottom layer is the ECA rule execution mechanism, which is the ECA rule mechanism in a modern database system. Users of the system may be either clinicians or patients. Typically, users should be subject to security checks and authorization. Currently, basic security is provided through user-names and passwords. Besides users, the system interacts with external systems such as the Synapses Server [32] for access to the distributed patient’s record and the Laboratory Information System (LIS) for test orders and results. Other systems may want to access information relating to protocol specifications and their execution process. The Protocol Management Layer generally provides users with the functionality for i) managing patients and patient categories, ii) creation of protocol specifications for patient categories, iii) creating, executing and manipulating patient plans, and iv) querying the system’s static and dynamic information. The ECA Rule Mechanism Extension’s main purpose is to provide the functionality that is not adequately supported by the ECA rule execution mechanism in the underlying database system and to perform actions that need to be performed outside the database system. Due to space limitations, the technical aspects, especially for the external actions and the management of the temporal events, will not be presented here. The Time Events Generator extends the database trigger mechanism by providing a time event detector. It generates time events of interest to specific rules within each patient plan. The mechanism for supporting time triggers is illustrated in Figure 6. The Java-based subscription and time trigger mechanism is used to give signals for the occurrence of only those time events that are of interest to rules in the patient plans. The Time Events Generator was necessitated by the absence of the support for temporal triggers in most modern database systems. The Rule Activity Listener listens and receives messages from rules executing within the database. Modern database systems do not provide support for rules to communicate externally with applications outside the database. For instance, current database connectivity (e.g., JDBC and ODBC) do not support active behaviour or push functionality (only pull functionality is supported). Hence, there is a need for a separate mechanism to allow rules to communicate externally. With the Rule Activity Listener, rules inside the database can communicate with other modules of the system that are outside the database.

232

K. Dube, B. Wu, and J.B. Grimson

Lastly, the Dynamic SQL External Systems Users Statement Generator and the Database Access MaInstantiation External Specification Manipulation Query Re-Play & Execution Communications Module Module Module Module nager are the two componModule Module ents that are dedicated to handling standard communiTime Event Dynamic SQL (DDL & DML) Generator Generator cation through database ECA Rule Extention connectivity between the Database Access Manager Module database system and external components. The Rule Activity Dynamic SQL Statement Notifier (HTTP Client) Generator generates the Local Plan Protocol Patient Execution and Plan Database required SQL statements to Record Logs Specifications Triggers allow dynamic manipulation Database System of both rules and data in the database. Fig. 4. System architecture for supporting the management The trigger mechanism of a of ECA rule-based clinical protocols database system is used as the engine for executing the ECA rule-based clinical protocols. One ECA rule in Time Event Generator a patient plan is mapped to one or more database triggers. The mapping is predefined for each of the two main types of rules, i.e., the static rules and dynamic rules. A static (time-driven) rule is mapped Time Event Log to one Java-based time event generator trigger that signals the occurrence of a time event and one database trigger that reacts to this signal. Dynamic rules are mapped to only one database trigger. Each Database Trigger ECA rule in a plan monitors either the patient’s record or the plan’s execution logs such as the time event log. Database System The implementation of the framework and architecture presented in the previous sections is on- Fig. 5. Mechanism for supporgoing. Preliminary tests performed using an early ting time-driven ECA rules limited version of the prototype system conducted using the Java-based time event ran 100 protocol instances at the same time and generator proved to be promising. The prototype system is now being prepared for undergoing tests using clinical protocols for the diabetes domain at a Dublin hospital’s diabetes clinic within the framework of the MediLink Project7. In summary, the architecture presented in Figure 4 attempts to fully utilise the trigger mechanism within the database system in executing the ECA rule-based patient plans. The architecture allows the management of ECA rule-based clinical protocols by providing, within a layered framework, management functionality that allow operations to be performed and queries to be issued dynamically at any time during the execution of patient plans. The architecture provides support for the three planes in the framework presented in Section 4 of this paper. Every ECA rule is mapped to at least one trigger in the database. Issues of concurrency and efficiency in Protocool Management Layer

HTTP

TOPS Activity Listener (HTTP Server)

ECA Rule Extension and Database Access Layer

HTTP

DB Connectivity

ECA Rule Mechanism

Time-driven trigger

Database Trigger Mechanism

http://www.cs.tcd.ie/medilink/, June 2002.

Time event detection mechanism

Java time Trigger Mechanism

7

Using ECA Rules in Database Systems to Support Clinical Protocols

233

rule execution are not of concern as these are handled by the trigger mechanism within the database system with the exception of time driven triggers, which rely on an external time event generator (Figure 5).

6. Summary and Discussion In our framework clinical protocols are supported through the specification, execution and manipulation planes. A declarative language called PLAN is used to specify clinical protocols. More work still needs to be done to make PLAN more expressive by incorporating advanced research results on ECA rule event specification and event algebra. The protocols are mapped to ECA rules (or triggers) and other schema objects in the database on instantiation in the execution plane. Clinical protocol specifications are stored in the database together with the relevant patient’s data. This allows the specifications to be manageable on a full scale using the DML of the underlying database. The protocol specifications are customized using patient data to create individual patient care plans. The ECA rules in a modern database system are used to execute the care plans and to interface the model of the patient, as stored in the database, and the clinical guidelines/protocols from which the plan derives. The manipulation plane imposes modularisation on the underlying ECA rules by viewing them as bundled into sets and subsets making up the patient care plans. The manipulation plane also provides the functionality to manipulate and query both the static specifications and dynamic aspects of the ECA rules that make up the patient care plans. The ECA rule paradigm has the advantage that it can be easily integrated with the electronic medical record if combined with database technology and a way is found to represent guideline tasks using ECA rules. This paper has presented a framework and architecture for the use of ECA rules in database systems to support clinical protocols. An important requirement in supporting clinical protocols is that these protocols must be dynamically manageable on a full-scale in order to be acceptable for routine use in daily practice.

7. Conclusion It is the authors’ strong belief that a method and mechanism to support dynamic management (specification, execution and manipulation as well as querying) of ECA rules or sets of ECA rules in a database system can provide the flexible support for the management of ECA rule-based clinical protocols. Supporting the management of ECA rules and their composites in a modern database system can be used as a basis for providing the flexible management of clinical protocols whose specification and execution models are based on the ECA rule paradigm. The management of the collection of ECA rules in a database system is also an important and challenging requirement that can be of beneficial use in many applications within the healthcare and other domains.

234

K. Dube, B. Wu, and J.B. Grimson

References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

14. 15. 16. 17. 18. 19.

20. 21.

Shahar Y, (2001) Automated Support to Clinical Guidelines and Care Plans: the Intention-Oriented View, Ben Gurion University, Israel, http://www.openclinical.org/resources/reference/briefingpapers/shahar.pdf, 03/2002. Miksch S (1999). Plan Management in the Medical Domain. AI Communications, 12(4), pp.209-235. Dittrich KR, Gatziu S and Geppert A (1995). The Active Database Management System Manifesto: A Rulebase for ADBMS Features. In: Sellis T (ed): Proc 2nd Workshop on Rules in Database (RIDS), Athens, Greece, September 1995. Lecture Notes in Computer Science, Springer, 1995. Paton NW (1999). Active Rules in Database Systems. Springer, New York. Simon E and Kotz-Dittrich A (1995). Promises and realities of active database systems. In Proceedings 21st VLDB Conference, Zurich, Switzerland, pp.642-653. Appelrath H-J, Behrends H, Jasper H and Zukunft O (1995). Case studies on active database applications: Lessons learned. TR-AIS-9601, Tech. Report, University of Oldenburg, http://citeseer.nj.nec.com/appelrath95case.html, ResearchIndex, 03/2002. Widom J and Ceri S (1996). Active Database Systems: Triggers and Rules for Advanced Database Processing. Morgan Kaufmann, San Francisco, California, 1996. Shortliffe, E. H., Scott, C. A., and Bischoff, M. B. (1981). ONCOCIN: An expert system for oncology protocol management. In Proc. Seventh International Joint Conference on Artificial Intelligence, pages 876--881. Musen MA, Carlson RW, Fagan LM and Deresinski SC (1992). T-HELPER: Automated support for community-based clinical research. Proceedings of the 16th Annual Symposium on Computer Application in Medical Care, Washington, D.C., pp.719-723. Shahar Y, Miksch S, and Johnson P (1998). The Asgaard Project: A Task-Specific Framework for the Application and Critiquing of Time-Oriented Clinical Guidelines. Artificial Intelligence in Medicine 14:29-51, 1998. Fox J, Johns N and Rahmanzadeh A (1998). Disseminating medical knowledge: the PROforma Approach. Artificial Intelligence in Medicine, 14:pp.157-181. Ohno-Machado L, Gennari JH, Murphy S, Jain NL, Tu SW, Oliver DE, et al. The GuideLine Interchange Format: A Model for Representing Guidelines. Journal of the American Medical Informatics Association 1998;5(4):357-372. Peleg M, Boxwala AA, Omolala O, Zeng Q, Tu SW, Lucson R, Bernstam E, Ash N, Mork P, OhnoMachado L, Shortliffe EH and Greenes RA (2000). GLIF3: The evolution of a guideline representation format. In Overhage MJ, ed, Proceedings 2000 AMIA Annual Symposium, LA, CA, Hanley and Belfus, Philadelphia. C Gordon and M Veloso (1996). The PRESTIGE Project: Implementing Guidelines in Healthcare MIE 96 Johnson PD, Tu SW, Booth N, Sugden B and Purves IN (2000). Using scenarios in chronic disease management guidelines for primary care. In: Overhage MJ, ed, Proceedings of the of the 2000 AMIA Annual Symposium (LA, CA, USA), Hanley and Belfus, Philadelphia. Tang TC and Young CY (2001). ActiveGuidelines: Integrating web-based guidelines with computerbased patient records. 2001 AMIA Annual Symposium, http://www.amia.org/pubs/symposia/D200173.PDF, 3/2002. Karras BT, Nath SD, and Shiffman RN 2000). A Preliminary Evaluation of Guideline Content Markup Using GEM—An XML Guideline Elements Model. In Overhage M.J.,, Ed., Proceedings of the 2000 AMIA Annual Symposium (Los Angeles, CA, 2000), 942, Hanley & Belfus, Philadelphia. Shiffman RN, Karras BT, Agrawal A, Chen RC, Marenco L and Nath S (2000). GEM: A proposal for a more comprehensive guideline document model using XML. J. Am. Med. Inform. Assoc., 7:pp.488498. Tu SW and Musen MA (2001) Representation Formalisms and Computational Methods for Modeling Guideline-Based Patient Care, In: Heller B, Loffler M, Musen M and Stefanelli M (2001). ComputerBased Support for Clinical Guidelines and Protocols, Proceedings of the First European Workshop on Computer-based Support for Clinical Guidelines and Protocols, 2000, Leipzig, p.115-132, IOS Press, Amsterdam. Hripscak G, Luderman P, Pryor TA, Wigertz OB and Clayton PD (1994). Rationale for the Arden Syntax. Computers and Biomedical Research, 27:pp.291-324. Caironni PVC, Portoni L, Combi C, Pinciroli F and Ceri S (1997). HyperCare: a Prototype of an Active Database for Compliance with Essential Hypertension Therapy Guidelines. In: Proc 1997 AMIA Ann Fall Symposium, Philadelphia, PA, Hanley and Belfus, 1997:pp.288-292

Using ECA Rules in Database Systems to Support Clinical Protocols

235

22. Clayton PD, Pryor TA, Wgertz OB and Hripcsak G (1989). Issues and Structures for Sharing Medical Knowledge Among Decision-making Systems: The 1989 Arden Homestead Retreat. Proc Annu Symp Comput Appl Med Care, 1989:pp.116-121. 23. ASTM (1992). E-1460: Standard Specification for Defining and Sharing Modular Health Knowledge Bases (Arden Syntax for Medical Logic Modules). In 1992 Annual Book of ASTM Standards, Vol.14.01, pp.539-587. American Society for Testing and Materials, Philadelphia, 1992. 24. HL7 (1999). Arden Syntax for Medical Logic Modules. Standard of the Health Level 7, 1999, http://www.cpmc.columbia.edu/arden/arden-2.1-proposed-120300.doc, March 2002. 25. Starren JB, Hripcsak G, Jordan D, Allen B, Weissman C and Clyaton PD (1994). Encoding a postoperatice coronary artery bypass surgery care plan in Edern Syntax. Comput Biol Med 1994 Sep; 24(5): pp.411-7 26. Sherman EH, Hripcsak G, Starren J, Jenders RA and Clayton P (1995). Using intermediate states to improve the ability of the Arden Syntax to implement care plans and reuse knowledge. Proc Annu Symp Comput Appl Med Care 1995: pp.238-42 27. Sailors RM, Bradshaw RL and East TD (1998). Moving the Arden Syntax Outside of the (Alert) Box: A Paradigm for Supporting Multi-Step Clinical protocols. JAMIA, 5 (Symposium Supplement): pp.1071. 28. Jenders RA, Huang H, Hripcsak G and Clayton PD (1998). Evolution of a knowledge base for a clinical decision support system encoded in the Arden Syntax. In: Proc AMIA Symp, 1998:pp.558-62 29. Jenders RA, Hripcsak G, Sideli RV, DuMouchel W, Zhang H, Cimino JJ, Johnson SB, Sherman EH and Clayton PD (1995). Medical decision support: experience with implementing the Arden Syntax at the Columbia-Presbyterian Medical Center. In: Proc Annu Symb Comput Appl Med care, 1995:pp169-73 30. Wu B and Dube K (2001b) PLAN: a Framework and Specification Language with an EventCondition-Action (ECA) Mechanism for Clinical Test Request Protocols. In Proceedings of the 34th Hawaii International Conference on System Sciences (HICSS-34): the Mini-Track in Information Technology in Healthcare, Abstracts and CD-ROM of Full Papers, IEEE Computer Society, Los Alamitos, California, p.140. 31. Elmasri R and Navathe SB (2000). Fundamentals of Database Systems, 3rd Edition, Addison-Wesley, Massachusetts, Chap.3-4. 32. W Grimson, D Berry, J Grimson, G Stephens, E. Felton, P Given and R O'Moore. Federated healthcare record server - the Synapses paradigm. International Journal of Medical Informatics, Vol.52, 1998, pp3-27.