PLAN - Semantic Scholar

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001

PLAN: a Framework and Specification Language with an Event-ConditionAction (ECA) Mechanism for Clinical Test Request Protocols Bing Wu and Kudakwashe Dube Department of Computer Science Dublin Institute of Technology, Kevin Street, Dublin 8, Ireland Emails: [email protected], [email protected] Abstract It has been generally recognised that the need to improve the quality of health care has lead to a strong demand for clinical protocols/guidelines supported by computer systems in their creation and execution. How to efficiently and effectively manage, query and manipulate the computerised clinical test protocols has posed a major challenge but received little research attention so far. This paper addresses this issue from a unified approach based on an active rule mechanism. This paper first presents PLAN – a generic modelling framework and specification language with an Event-Condition-Action (ECA) mechanism for clinical test request protocols. It then discusses in detail components of the test protocol and patient test plan expressed in PLAN. The implementation of PLAN is also briefly discussed. This research is unique in that it introduces an active ECA mechanism into test protocol modelling and specification, and emphasises the importance of the efficient and effective management of computerised test request protocols.

1. Introduction The need to improve the quality of health care has led to a strong demand for clinical protocols/guidelines supported by computer systems in their creation and execution [17]. Clinical protocols contain medical concepts and knowledge about how to carry out specific activities (such as ordering timely and appropriate tests and planning treatment) [11]. Recently, one of the major challenges within this area is not only a matter of disseminating best practice, but also a matter of ensuring that the protocols enshrined in this best practice can be easily and readily specified and then integrated into the existing computing infrastructure, and are easily customisable to suit local practice and needs. This latter issue is being addressed by projects such as PRESTIGE [26] but the issue of specification and integration of clinical protocols with the existing IT infrastructure poses major challenges. At the same time there is growing interests in the Electronic Healthcare Record. It is clear

that there are considerable benefits to be derived from linking the Healthcare Records and Protocols together [12, 33]. Returning to clinical practice and the need for protocols: as an example, there have been two landmark prospective trials concerning the treatment of diabetes in recent years. The Diabetes Control and Complications Trial (DCCT, NEJM, 1993) proved unequivocally that tight control of blood glucose in patients with Type I diabetes reduced the major complications of retinopathy, nephropathy and neuropathy by at least 50% over the 9 year duration of the study. More recently, the UK Prospective Diabetes Study (UKPDS, Lancet, 1998) provided similar evidence in subjects with Type II diabetes studied over a 20-year period. The challenge now to public health agencies will be to implement the findings of these two trials on a wide scale. It has been recognised in the literature that the application of Information Technology can enhance the quality and efficacy by promoting best practise in the Clinical Laboratory Environment [1, 2, 3, 22] Currently, there is an on-going project in the Dublin Institute of Technology, Ireland, of which the main aim is to develop a generic framework and its associated specification language to specify clinical test protocols/guidelines. Together with this framework and language, a mechanism and implementation of protocolbased system for the creation, execution and management of the specified clinical test request protocols will also be developed by using the modern active rule mechanism. This paper presents PLAN, a framework and its associated specification language, for the specification of clinical test ordering protocols based on the EventCondition-Action (ECA) active rule mechanism. The paper also describes an execution scenario and, briefs the management of test protocols specified in the PLAN language. Section 2 outlines some of the related work. Section 3 briefly describes the ECA rule mechanism. Section 4 discusses PLAN, the protocol specification language and its associated framework. Section 5 briefly discusses the manipulation and querying of test protocols. Section 6 concludes and discusses the future work.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

1


2. Related work Research and practice on the computerised clinical protocols have been conducted for a relatively long time, although only recently they have become one of the major focuses. A pioneering work related to some aspects of the specification and implementation on clinical protocols can be found in [16]. There, a computerised medical record system was designed to detect and remind the responsible clinician about clinical events that might need corrective action. Peters et al [25] implemented a computerised management protocol system (mainly for liver transplant patients) which not only proposes the laboratory investigation to be performed on each patient but also performs related clinical functions. East et al [7] developed a computerised protocol system to direct the management of arterial hypoxemia in critically ill patients with adult respiratory distress syndrome. Lepage et al [14] implemented an on-line computerised, knowledge-based blood order critiquing system in 1987 and then a second blood ordering system using a consultation mode was developed. All these earlier systems were based on decision-support mechanisms. Three other works following the same route can be found in [18, 28, 31]. Recently research and practice are tending to deal with these issues at a more general level. It is generally recognised that the understanding and therefore expression of the ‘clinical protocols’ are of great importance. Naszlady [20] and Duftschmid et al [6] give the following definition of a clinical guideline, which is attributed to the Institute of Medicine (USA): “A guideline is a set of systematically developed statements to assist the medical practitioner and the patient in making decisions about appropriate healthcare for specific clinical circumstances.” Clinical guidelines and protocols∗ have been represented and specified using a number of methods. Miksch [17] describes some of the methods, including: 1) Free text; 2) Medical logic modules 3) Decision tables and 4) Flowcharts. Among these methods, medical logic modules might be of particular interest. Ohno-Machado et al [21] describes it as “ … software modules, written in Arden Syntax, that, when implemented in a clinical information system, run on databases of patient data and typically provide alerts or reminders for clinicians”. There are a number of clinical practice guideline and protocol models and systems that have been implemented over the past five years. Some of these include GLIF [21]; Asgaard/Asbru [27]; EON system [19], and ProForma [9]. In the domain of test ordering, Wijk et al [29, 30] have developed a protocol-based decision support system called BloodLink-Guideline whose objective is to help the clinician in the management of test ordering. The system developed in [29] selects and suggests appropriate tests ∗

Within this paper, ‘protocol’ and ‘guideline’ refer to the same concept.

after being given a clinical indication by the clinician. The early work in [15] uses rules to implement test-ordering protocols. The work presented in this paper differs from above works in two major aspects. First, instead of following the decision-support approach, it follows the modern active or ECA rule mechanism to develop a generic modelling framework and an associated specification language for clinical test ordering protocols. Second, emphasis is placed not only on the creation and execution, but also on the management (insertion, deletion, modification, querying) of the computerised test ordering protocols for each category of patients on a higher level, and the instantiated instances of protocols for each individual patient on a lower level. A clear line has been drawn between the high level static test order protocol for each category of patients, and the lower lever dynamic test-plan instantiated for an individual patient from a generic protocol for the category to which this patient belongs. Other works are mainly concentrated on developing systems that detect errors in test orders, abnormal test orders and test results, or systems that issue alerts, reminders and pagers [13, 23].

3. ECA rule mechanism The Event-Condition-Action (ECA) rule paradigm is well established in the database community, where it originated from the need to free individual applications from behavioural knowledge [32]. This was achieved by pushing this knowledge into database management systems (DBMS). The ECA mechanism frees applications from tasks like monitoring database events arising from end users or applications, and periodically polling the database for events of interest [24]. Generally, each ECA rule consists of three components 1) an event part, containing a so-called transitionpredicate that lists all possible events which are of concern to this rule; 2) a condition part, which can be an arbitrary predicate and, 3) an action part, which is an arbitrary list of executable functions. An ECA rule is triggered and the action part is executed only when any event of its transition predicate occurs and the ECA rule’s precondition evaluates to true. That is to say, an ECA rule consists of events, conditions and actions. The semantics of an ECA rule is that when the event occurs, evaluate the condition; if the condition is true, then execute the action(s) [10]. Characteristics of ECA rules and their collective behaviour in both relational and object-oriented database systems have been analysed by various researchers and are now well known [4, 24]. ECA rules have been used for database system extensions like supporting integrity constraints, for closed database applications like monitoring sales in a stock control database and, for open database applications in which there is a need to respond to situations outside the database. ECA rules can also be put to beneficial use in

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

2


process-oriented environments such as workflow systems [8]. Nowadays, most database management systems have integrated/implemented an active mechanism into the system kernels, such as Oracle for example. For an extensive review on active database systems please refer to [24]. In the clinical test-ordering domain, from the ECA rule point of view, a test order activity can be seen as such a procedure: when any of the specified events occur, check the order-condition; if the condition is true, then a test request is ordered. Therefore every test ordered is a result of an event – a decision is made to order the test. A possible event that triggers a test request may be the emergence of a patient with a problem, the passage of time, the occurrence of abnormalities in a patient's condition or, a combination of them. A possible condition can be a specification of the medical condition of a patient. A possible action can be issuing a test-request, sending an alarm or a reminder to clinician or, any other applicable clinical action. It is the author’s belief that the modern active database technology with ECA rule mechanism is of great potential in this area, and its applications here should be vigorously researched. In this paper, the authors seek to demonstrate that the ECA rule mechanism is useful in supporting applications within the healthcare domain, especially in the implementation of clinical protocol management systems.

4. PLAN: a framework and a language with an ECA mechanism As mentioned before, the main aim of this paper is to present a generic framework and its associated specification language to specify clinical test protocols/guidelines. In order to do so, some concepts and terms have to be defined before any further discussions. This section first identifies some concepts and terms in Subsection 4.1, then presents a generic framework PLAN of test-order protocols based on the ECA rule paradigm in Subsection 4.2. Subsection 4.3 describes the general structure of the PLAN language, and Subsection 4.4 gives an example of test-protocols specified in PLAN. Finally, Subsection 4.5 describes the instantiation scenario of how to create a dynamic patient-test-plan from a pre-defined static test-protocol for an individual patient.

on the protocol management to be addressed: 1) providing a way to specify, store, query and manipulate the test order protocols, 2) using the ECA rule technology and through clinicians to implement, schedule, execute, and advise protocol tasks as described by the protocol specification. A test request protocol (or test protocol in short) is a generic plan for ordering clinical tests for a particular patient category. It contains a set of base schedules of test orders. Each base schedule covers a variation in patient condition in a patient category. A test protocol also contains a set of protocol rules (defined below). A base schedule is a series of clinical tests to be ordered. The base schedule is expressed as a set of static rules. A patient test plan (or test plan in short) is a plan for ordering a set of tests for an individual patient within a particular patient category. It is derived from tailoring a test protocol to a specific patient in a particular category for particular time duration. A patient test plan is an instance of a test protocol that is relevant for a particular patient for a given time duration. A protocol rule is an ECA rule that dynamically monitors a base schedule and, dynamically intervenes to order actions. The actions can be ordering further tests or, paging a medic as required by the protocol based on certain inputs (test results, vital signs data, etc.). A static rule is an ECA rule to order tests subject to time being within a specified time set with reference to a given time point. A static rule is applicable during the lifetime of the containing base schedule. A dynamic rule is an instance of a protocol rule in the context of, and is contained in, a patient test plan. A dynamic rule is applicable only to a particular patient and, can only exist in a patient test plan. An event is an occurrence of something defined with a particular domain. Examples of events in the clinical test domain include 1) test result arrived, 2) time points, 3) patient checks in or out and, 4) changes in patient status or condition. A condition is a logical expression meaningful to the clinical test domain. An action is an operation that is meaningful to the clinical test domain. Examples of an action in the test domain are 1) ordering test, 2) issuing alarm and, 3) monitoring patient condition. These concepts and their derivatives will be further discussed and clarified in the next section.

4.1. Main concepts

4.2. The PLAN framework for clinical test request protocols

A protocol management system, in the context of this paper, is a computer system for the creation, storage, execution and management of a set of test order protocols. The execution flow of such a system is driven by a computer representation of the protocol logic based on the ECA rule mechanism. There are generally two main issues

Figure 1 shows the PLAN framework for modelling clinical test request protocols, expressed in an EntityRelationship model. Patients are placed into PatientCategories for the purposes of test ordering. Each PatientCategory has a Test-Protocol designed for it. A Test-

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

3


Protocol has a set of Base-Schedules, each covering a specific variation in patient condition such that each Patient in a Patient-Category has only one matching BaseSchedule. A Test-Protocol also contains several ProtocolRules. A Base-Schedule contains one or more Static-Rules. A Test-Protocol generates a Test-Plan that is specific to a particular patient belonging to a given Patient-Category. The Test-Plan is a dynamic version of the Test-Protocol that has been tailored to a specific patient. There can be many Test-Plans generated from a given Test-Protocol. But no single Test-Plan can be generated from two or more Test-Protocols (that is to say, multiple-inheritance is not allowed). Protocol-Rules and Static-Rules are of the ECA Rule type. A Static-Rule is an ECA Rule of which 1) Events are time points, 2) Condition is always true and, 3) Actions are mostly clinical test orders. The time events are defined with reference to an explicit reference time point. A StaticRule is a building block for the logic of the Base-Schedule. A Protocol-Rule is an ECA Rule with comprehensive Event, Condition and Action components. The Event here is based on occurrences in patient condition as well as time. The Condition here is based on checking test results and/or other patient data contained in the patient medical record. The Action of Protocol-Rules is an intervention that may involve 1) ordering further tests, 2) paging clinicians, 3) activating or deactivating other rules, 4) terminating or suspending of patient-test-plan and, 5) recommendations to clinicians. In Figure 1, the entity ECA Rule holds properties that are common to both Protocol-Rule and Static-Rule entity sets. P atientCategory

T estP rotocol

I s-F or

B aseS chedule

Has -A

Combines-With relationship also applies to Condition and, Action entity.

4.3. The PLAN language Based on the previously presented modelling framework for test protocols, a declarative specification language PLAN has been designed to provide a means of specifying test protocols. For the detailed BNF definition of this language, please refer to [35, 36]. This section describes the structure of the main components of a test protocol and a patient test plan specified in PLAN. 4.3.1 Structure of a test protocol in PLAN. The structure of a test protocol specification in PLAN is shown in Figure 2. It can be seen that a test protocol specification consists of three main parts: • the protocol header, which holds the fields of protocol name, protocol category, design and authorisation particulars; • several base schedules, each attached to a case condition that determines its selection; • a protocol rule set. T e s t-P r o to c o l P r o to c o l H e a d e r D e s i g n a n d a u th o r i s a t i o n p a r t i c u l a r s

C a s e < c o n d itio n 1 > B a s e -S c h e d u le < n a m e 1 > s t a ti c r u le 1 … s t a ti c r u le 2 … … C a s e < c o n d itio n 2 > B a s e -S c h e d u le < n a m e 1 > s ta tic ru le 1 … s ta tic ru le 2 … …

… . … . Ge ne rates

Be longs-T o

Conta ins

Has -A

C a s e < c o n d itio n .N > P atient

I s-F or

T est P lan

Pr otocolRule

G lobalR ule

Static- R ule

IS -A

B a s e -S c h e d u le < n a m e 1 > s ta tic ru le 1 … s ta tic ru le 2 … …

IS -A

P r o to c o l R u le S e t Co mbines-W ith

Condition

Has -A

P ro to c o l ru le 1 … p r o to co l r u le 2 … …

EC A R ule

H as-A

Has- A

E vent

Action

E n d -T e s t -P r o to c o l

M u ltip licity of Relat ion sh ip s O ne M an y

C ombine s-W ith

C ombines -W ith

Figure 2. General structure of a protocol specification

Figure 1. PLAN framework for modelling clinical test protocols The Event, Condition and Action entity each has a role relationship: Combines-With. The Combines-With role relationship captures the information that an event can combine with other events to create a composite event using the logical connectives, AND and OR. This

It is very important to note that, in PLAN, a testprotocol is a generic specification of a clinical protocol for a particular patient category. An individual patient will only be associated with a patient test plan, which is an instance of a test protocol. Based on the patient condition (such as a pregnant woman with age above 35 or below), a test plan will be instantiated differently from the baseschedules as different test orders may be required.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

4


(a) The protocol header: The general format of protocol header is shown in Figure 3. The protocol design and authorisation particulars, contained in the protocol header, specify the date and time of design, authorisation of the test protocol, as well as the name of the clinician who designed or authorised the protocol. This is needed for the management of any test protocol. D esigner: d esign erN a m e;

D esign-D ate: desig nD a te; D esign-T im e: d esig nTim e;

A uth oriser: a uthoriserN am e; A u tho rised-D a te: au tho rised D ate; A uthorised-T im e: a uth orisedTim e;

Figure 3. Protocol design and authorisation specification. The protocol header also specifies, as shown in Figure 4, the Patient Category for which the test protocol is designed. The Patient Category acts as the eligibility criteria for the applicability of the protocol. For a patient to be eligible for the protocol, he or she must be a member of the stated patient category. Otherwise he or she is not eligible. The clinician is responsible for placing a patient into a given category. P atient-C ategory: categoryNam e

Figure 4. Protocol eligibility specification.

switch with a condition for each case. The case conditions are to be written in such a way that only one base schedule is to be selected after the conditions are evaluated. The case conditions are attached to each base schedule and are evaluated during the process of generating a patient test plan. A base schedule is given a name by which it can be referenced. Every base schedule is specified to consist of a set of static rules. These static rules constitute the logic of the base schedule of tests to be ordered for a particular patient. (c) The structure of a static rule: The main purpose of the static rule is to monitor occurrences of specified time points at which tests are to be ordered for a particular patient during the lifetime of a patient test-plan. A static rule specification, shown in Figure 6, consists of the name of the rule, rule design particulars, the type and status of the rule, a time reference point, time events and actions in the form of clinical tests to be ordered. The rule type is specified as static. The status of the rule is one of active, or inactive. All time events are determined with respect to a time reference point, the zero time point. It can be seen that a static rule is also an ECA rule but with the condition part being always true. Therefore the condition part does not need to be explicitly specified here. Static-Rule: ruleName; Design-Date: dateDesigned; Rule-Type: static; Begin-Static-Rule Zero-Time: referenceTimePoint; On list of time points Do list of clinical tests to be ordered End-Static-Rule;

Designer-Name: nameOfDesigner; Design-Time: timeDesigned Rule-Status: active or inactive;

Figure 6. Static rule specification B e g in -C ase - S c he d ule s C ase : C a se C o n d itio n -1 B ase -S c h e d u le : B a se S c h ed u le -1 B e g in -B ase - S c he d ule L ist o f sta tic ru le s ; E nd - B a se -S c h e d u le ; C ase : C a se C o n d itio n -2 B ase -S c h e d u le : B a se S c h ed u le -2 B e g in -B ase - S c he d ule L ist o f sta tic ru le s ; E nd - B a se -S c h e d u le ; C ase :

C a se C o n d itio n -3 • •

E n d -C a se -S c h e d u le s;

B eg in-Pro to col-R ules P ro to co l-R ule ru leN a m e-1 ; D e sig n-D a te: d a teD esig ned R ule-T y pe: p roto co l B eg in-Pro to col-R ule O n e ven t spe cifica tion If con d ition spe cifica tion T he n a ctio n sp ecifica tio n E nd-pro to col-R ule;

D esig ner -N am e: n a m eO fD e sig n er; D esig n-T im e: tim eD esig ne d; R ule -Sta tus: active o r ina ctive

P ro to co l-R ule ru leN a m e-2 ; D e sig n-D a te: d a teD esig ned R ule-T y pe: p roto co l B eg in-Pro to col-R ule O n e ven t spe cifica tion If con d ition spe cifica tion T he n a ctio n sp ecifica tio n E nd-Pro to col-R ule ;

D esig ner -N am e: n a m eO fD e sig n er; D esig n-T im e: tim eD esig ne d; R ule -Sta tus: active o r ina ctive

P ro to co l-R ule ru leN a m e-3 ; • • • E nd-Pro to col-R ule s;

...

Figure 5. Specification of a base schedule of tests with a case switch

Figure 7. Specification of a set of protocol rules

(b) The structure of the base schedule: The general structure of a base schedule is shown in Figure 5. The base schedules are specified to be components of a case

(d) The structure of a protocol rule: Figure 7 shows the structure of a specification for a set of protocol rules. The specification of a protocol rule is similar to that of a static rule except that it includes the explicit

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

5


specification of a condition. This condition determines whether or not the specified action is to be executed on the occurrence of the specified event. The protocol rule event can be time-based. However, in most cases, it is based on a patient’s condition, which can be deduced from test results or other data from the patient medical record. (e) The structure of a global rule: Global rules have the same syntactic structure as protocol rules. Global rules apply to all protocols within a system and are not specified within a protocol specification.

4.4. Example test protocol Having described the general structure of the PLAN language, this subsection demonstrates the expressiveness of the language. To do so, an example clinical test protocol is given first, then it is expressed in the PLAN language. Figure 9 shows an example test protocol for the LIVER-TRANSPLANT patient category, which is used by Peters et al [25]. Liver Transplant Test Protocol

4.3.2. Structure of the patient test plan. A Test Plan specification in the PLAN language is shown in Figure 8. A Test Plan has the same syntax as a Test Protocol except that it adds a specification of the patient identification and the name of the protocol from which it derived. A Test Plan also subtracts the case switch and the protocol designer and authoriser details. The case switch is eliminated during protocol instantiation, when it is evaluated to tailor the protocol to a specific patient. The patient category specification is also not explicitly specified as it can be accessed using the specified protocol name. A test plan has only one base schedule determined by specific patient condition. Protocol rules are instantiated to become dynamic rules within a test plan. It should be emphasised here again that a test protocol is a specification of a generic clinical protocol for a particular patient category. But a test plan or patient test plan is an instance of a test protocol for a particular individual patient who belongs to the patient category associated with the test protocol. A test protocol is a static concept but a test plan is a dynamic test-ordering schedule for an individual patient. T est-P lan T e st Plan H eader Test P la n N a m e

Protocol na m e

P atient ID A uthoriser N a me

P atie nt N a m e T im e

D ate

B ase-Sc hed u le static rule 1 … static rule 2 … …

D y na m ic R ule Set P rotoc ol rule 1 … protocol rule 2 … …

(Example)

Day 0 = day after that entered in Class/Category 'LIVER TRANSPLANT' Fence post rules (Static rule): Do U&E tests on days -1,0,1,2,3,4,6,8,11(+3) Do LFTs , PT, FBC tests on days -1(+1), 14(+3) Do CYA test on days 0(+1) unless on FK trial Do MG test on days 0,7,14 HB,FBC,PT on days -1(+1),14(+3) Do Serum BANK on days 7(+7) Protocol Rules Do U&E tests on same day: If K > 5.5 or K < 3 Do U&E tests on day+1: If K >5.1 or K < 3.4 or |delta| >0.4 if(UR > 10 and day < 9) or UR > 20 or |delta| > 4 if (day < 9 and CREAT > 110) or (CREAT > 210) or |delta| > 25

Figure 9. An example test protocol for a LIVER TRANSPLANT patient category The protocol defines a zero time point to be the day on which a patient is placed into the LIVER-TRANSPLANT category. It also specifies static rules and protocol rules. The static rules state time points, with respect to the stated zero time point, at which specified tests are to be ordered. Protocol rules specify what action to take when certain patient conditions, determined by checking test result values, occur. In this example, the actions are mainly further test orders. Figure 10 shows the corresponding protocol specification expressed in PLAN language. The test protocol has only one base schedule that contains five static rules. There are two protocol rules, each of these rules orders a further test subject to a condition being satisfied. The case condition is specified to be NULL to denote that there is no condition to determine the selection of a base schedule since the protocol has only one base schedule. Static-rule-3 in the example protocol has a combined/conditioned event in which the time event, day 0 or day 1, is combined with the condition that the patient must not be currently on FK trial.

4.3 Execution scenario

E n d-T est-Pla n

Figure 8. Patient test plan specification

An earlier version of the PLAN framework and language has been implemented using JAVA following the ECA rule and Object-Orientation paradigm [2]. For the

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

6


modelling framework and language presented in this paper, an execution scenario on how a patient test plan can be instantiated from a general test protocol is described in Figure 11. P ro to co l N a m e: L T -Proto col-1 ; P a tien t-C a teg ory :L iv er-T ra nsp lant; D esign er-Na m e: D r AB ; D ate -D esig ned: 29 /5/2 00 0; T im e -D esig n: 1 41 7; A u th or ize r-N am e: D r. C D ; D a te-A u th o rized : 30 /5/20 00 ; T im e -A u th or ized : 141 7; C a se: N U L L B a se-sc he du le-N a m e:B S 1; B eg in -B a se-S ch ed u le R u le-N am e: static -rule-1 ; D esig ne r-N am e:Dr A B ; D esig n -da te :29 /5/20 00 ; D esig n-T im e :14 17 ; R u le-T y p e:stat ic; R ule -S ta tu s: activ e; B eg in -S ta tic-R u le Z ero -T im e:C h eck -in -D ay + O n d ay {-1 , 0 , 1 ,2,3,4,6 ,8,11 ,14 }D o o rd er-te sts{U a n d E } E n d -S ta tic-Ru le; Ru le -N a m e: static-ru le-2; De si gn er-N a m e:D r A B ; D e sig n -d ate:29 /5 /2 00 0; D esig n -T im e:14 1 7; Ru le -T y p e:static; R u le-S ta tu s:a ct ive; B eg in -S ta tic-R u le Z ero -T im e: C heck -in -D ay + O n d ay {-1 , 0 , 1 7} D o o rd er-te sts{L F T s, P T , F B C } E n d -S ta tic -R u le ; R u le-N a m e: static-ru le-3; D esign er-Na m e:D r AB ; D esign -d a te:2 9/5 /2 0 00 ;D e sig n -T im e:1 41 7; R u le-T yp e:static; R u le-S ta tu s: active; B eg in -S ta tic-R u le Z er o-T im e :C h eck-in -D ay + O n d a y { 0, 1} a n d P atient.C u rren tT h erapy= N O T F K -T ri alD o or der-tests{C Y A } E nd -S tati c-R u le; R u le-N a m e: static-ru le-4 ; D esig ner -Na m e :D r AB ; D esig n-da te: 29 /5 /20 00 ; D esign -T im e:14 17 ; R u le-T y pe :static; R u le-S tatus: active; B egi n-Static -R u le Z e ro -T im e:C h eck -in-D ay + O n da y {0 , 7,1 4} D o or der -tests{M G } E n d -S ta tic-R u le; R u le-N am e: static-ru le-5; D esig ne r-N am e:Dr A B ; D esign -da te: 29 /5 /20 00 ; D esig n-T im e :14 17 ; R u le-T y p e:stat ic; R ule -S ta tu s: activ e; B eg in -S ta tic-R u le Z ero -T im e:C h eck -in -D ay + O n d ay {7 , 14 } D o o rd er-te sts{S eru m -B A N K } E n d -S ta tic-Ru le; E n d -B a se-S ch ed u le; P r oto col R u le se t B egi n-P roro col-R u les R u le-N am e: pro toco l-ru le-1 ; D esig ne r-N am e:Dr A B ; D esig n -da te :29 /5/20 00 ; D esig n-T im e :14 17 ; R u le-T y p e: p rot ocol; R ul e-S ta tu s: active; B eg in -S ta tic-R u le Z ero -T im e:C h eck -in -D ay + O n d ay {to d a y} IF K > 5.5 O R K < 3 D o o rd er-tests{U & E } E n d -S ta tic-Ru le; R u le-N am e: pro toco l-ru le-2 ; D esig ne r-N am e:Dr A B ; D esig n -da te :29 /5/20 00 ; D esig n-T im e :14 17 ; R u le-T y p e: p roto col; R ule -S ta tu s: acti ve; B eg in -S ta tic-R u le Z ero -T im e:C h eck -in -D ay + O n d ay {to d a y} IF (K > 5.1 O R K < 3 .4 O R D elta > 4) a nd ( (U R > 10 a n d D a y< 9) or U R > 2 0 or D elta > 4 ) a n d ((D ay< 9 an d C R E A T > 1 10 )or C R E A T > 2 10 or Delta > 2 5 D o o rd er-tests{U & E } o n da y s {to d ay + 1} E n d -S ta tic-Ru le; E n d -P ro to co l-R u les.

Figure 10. Example test ordering protocol in PLAN language A-SET -Dyna mic-Rule

A-Patient

A-Patient-Category A-T est-Protocol

A-SET -Static-Rule

A-Ba se-Schedule

is initiated. The category and patient information is used to build up a patient-test-plan. Based upon the patient data, a template instance of a base-schedule is selected from the case-switch. Then the corresponding set of the static rules is built up to fill the base schedule of the test plan. Protocol rules are used to build up the corresponding dynamic rules. Finally, the patient-test-plan is built from the base schedule, static rules and dynamic rules. Figure 11 shows the execution scenario that has just been described to create a patient-test-plan. Once a patient-testplan is created, it is ready for enforcement by an active mechanism that is based on the ECA rule mechanism.

5. Management of test protocols and plans Once a test protocol is specified and instantiated, it becomes necessary to execute management operations on it. These operations are necessary since circumstances arise in which a protocol may need to be updated, modified or replaced by a new one. A clinician may also need to obtain information about aspects or components of existing protocols and, the information of active patient test plans. Therefore, management facilities need to be provided so as to enable the manipulation and query operations against both test protocols and plans. A test protocol is static whereas a patient test plan is a dynamic version of the test protocol. The management operations would view both a protocol and its test plans as data, which can be manipulated and queried. This section briefly outlines the management operations that are applicable to the test protocol and the test plan specified in the PLAN language. A more detailed discussion of the protocol specification management can be found in [5]. Before any further discussion, it is very important to point out that this section is not a description of the implementation of the required manipulating operations. Instead, this section discusses and describes the requirements of the manipulating operations applicable to the test protocols and patient test plans stored in a database.

A-Patient-Te st-Pla n

5.1. Test protocol and patient test plan manipulation

Patient C heck -in get Patient-Test-Plan

Crea te Test-P lan Create Crea te Create Create

Exec utio n scen ar io to create a Patient Test Plan

Figure 11. Execution scenario to create a patient test plan As it can be seen, a patient is first placed into a patient category. Once this is done, a test protocol for that category is identified and generation of a patient-test-plan

The manipulating operations that could be applied to test protocols and test plans specified and implemented in PLAN should include the following: • Displaying complete protocols and test plans, or their components; • Creating protocols and test plans or their components; • Changing or modifying components of existing protocols and test plans; • Terminating an executing test plan. Test plan manipulation should be able to be performed separately without affecting the test protocol from which the test plan is derived. Also when changes or

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

7


modifications are made to components of currently executing test plans, the updates should be immediately incorporated into the executing test plan. It is worth pointing out that a version/history concept for management of both test protocol and patient test plan is very important, and requires special attention.

5.2. Test protocol and patient test plan querying Querying allows one to obtain information about a defined protocol, the active and/or inactive test plans and their components. For querying to succeed, the protocol and test plans should be broken down into data items that can be organised for storage in a way that would permit queries to be defined in the data store. For a complete implementation of a protocol management system following the PLAN framework and language, a set of queries would have to be defined and implemented. Some classes of queries are as follows: a) protocol related queries: • Retrieve and display a named protocol. • Given a protocol name, what is the patient category associated with the named protocol? • What is the total number of currently existing protocols? • Given a protocol name, what are the currently active test plans and their total number? • Given a protocol name, what are the number and names of patients with test plans generated from this protocol? • Given a protocol name, what are the protocol rules or what are the base schedules? (b) test plan related queries: • What test plans are currently in execution? • Given a patient name, retrieve the patient’s test plan. • Given a test plan name, report on the test plan execution state. • Given a test plan, list all the tests that have been ordered under the test plan. (c) base schedule related queries • Retrieve information about base schedules defined in a test protocol • Retrieve information about the execution progress of a given schedule in a test plan. • Given a protocol, list all static rules or rules with a specified component characteristic. A rule component can be an event, condition or an action. • Given a base schedule, retrieve its selection condition. (d) rule related queries • Given a protocol, retrieve its protocol rules. • Given a protocol and a base schedule, retrieve the relevant static rules

• •

Given a test plan, retrieve a list of active/inactive static/dynamic rules Given a protocol, test plan, base schedule and a rule, retrieve rule components: events, condition and/or actions

5.3. Storage options for protocol and test plan specifications expressed in PLAN language In order to facilitate the manipulation and querying of protocols and test plans described above, the protocol and test plan specifications expressed in PLAN need to be mapped onto a database or data structure that can be stored, maintained and queried. Storing these specifications as a text file would render manipulation and querying impossible. Each protocol specification would therefore need to be broken down into semantically and syntactically meaningful data items or groups of data items that can be stored in a database. An issue to be considered, in the case of an executing test plan, is how to keep both the dynamic and static aspects of the active test plan up-to-date after modification. The modification of a test plan that belongs to a specific individual patient should not affect the generic test protocol from which the test plan is derived. It would seem that it is necessary to maintain test protocol data separately from test plan data. An advantage to be derived from the storage of specifications as data, would be the ability to keep a history of the process of ordering of laboratory investigations. There are at least two possible options that would be part of this project’s future consideration in handling the issue of storing protocols and test plans. In the first option, a protocol specification in the PLAN language would be mapped onto relations or classes that can be stored in a relational or object-oriented database respectively. The DBMS data manipulations could then be used to manipulate the protocol or test plan. Querying could also be done using an SQL-based query language for a relational database or an OQL-based query language for an object-oriented database. In the second option, a protocol or test plan specification would be mapped onto, and stored as, an XML document that can be stored in an XML document database on which queries can be defined.

6. Conclusion and future work The use of clinical practice guidelines and protocols that are linked to the electronic healthcare record is being encouraged as a way to improve healthcare. Automatically ordering of clinical tests based on test protocols could reduce costs by minimising unnecessary test orders while ensuring that all tests ordered are relevant for a particular patient condition. Within this paper, the authors have presented PLAN, a modelling framework and its associated specification language for specifying clinical

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

8


test request protocols. The proposed framework and language is based on the modern ECA rule paradigm. It allows a test protocol specification to contain 1) several base schedules of test requests to be ordered at certain time points and, 2) a set of protocol rules, which are of real ECA rule format, that monitor events that arise during the execution of the base schedule. The base schedule is specified as a set of time-driven ECA rules that monitor time points at which specific tests are to be ordered for a patient. In the dynamic execution scenario, a patient who is categorised into a particular patient category will have a test plan generated from a generic test protocol. The authors also outlined the required manipulating operations and the possible implementation approach for a protocol management database system following the PLAN approach. The future work will mainly involve the detailed implementation of a protocol management system following the PLAN approach. One possible way for the implementation is to map the test protocol specified in PLAN into a modern active database system, where an ECA mechanism is provided as a standard feature of the DBMS.

7. References [1] Bates W, Kuperman G J, Teich J M, Tanasijevic M J, Ma'Luf N, Rittenberg E, Jha A, Fiskio J, and Winkelman J (1999). A randomised control trial of computer-based intervention to reduce utilisation of redundant laboratory tests. JAMIA, Vol.106 No.2, pp.144-50. [2] Berry D, Wu B, Pardon S, Duignan F, Grimson W, Gaffney P, Clarke F, Feely J (1999) A Test Request Protocol System. IFCC WorldLab Conference, Bologna, Italy June 1999. [3] Boran, G., O'Moore, R., Grimson, W., Peters, M., Hasman, A., Groth, T., and Van Merode, F. A new clinical laboratory information system architecture from the OpenLabs project offering advanced series for laboratory staff and users. Clinica Chimica Acta (248):19-30, 1996. [4] Dittrich K R, Gatziu S and Geppert A (1995). The Active Database Management System Manifesto: A Rulebase of ADBMS Features. In T Sellis (eds.): Proc 2nd Workshop on Rules in Databases (RIDS), Athens, Greece, September 1995. Lecture Notes in Computer Science, Springer 1995. [5] Dube K and Wu B (2000). Specification, Implementation, Execution and Management of Clinical Test Ordering Protocols: a Database Approach. Submitted to: First European Workshop on Clinical Practice Guidelines, EWGLP 2000, Leipzig, Germany. [6] Duftschmid G, Miksch S, Shahar Y and Johnson P D (1998). Multi-Level Verification of Clinical Protocols. Proceedings of the Workshop on Validation and Verification of Knowledge-Based Systems, Trento, Italy. [7] East T D, Morris A H, Clemmer T, Orme J F, Wallace C J, Henderson S, Sittig D F and Gardner R M (1990) Development of computerised critical care protocols – a strategy that really works! Evaluation-Real KBS, Vol. 910: pp.564-568

[8] Eder J, Groiss H and Nekvasil H (1994). A Workflow System Based on Active Databases. In: Connectivity, pp.249-65. Oldeburg, 1994. [9] Fox J, Johns N and Rahmanzadeh A (1998). Disseminating medical knowledge: the PROforma approach. AI in Medicine, Vol.14 No.1, pp.157-82. [10] Gatziu E, Geppert A, Dittrich K R (1991). Integrating active concepts into an object-oriented database system. In: 3rd International Workshop on Database Programming Languages, Naphlion, Greece. [11] Gordan C, Herbert I, Johnson P, Nicklin P, Pitty D, Reeves P (1997) Telematics for Clinical Guidelines: A Conceptual Modelling Approach. Medical Informatics Europe ’97, IOS Press 1997 [12] Grimson W, Berry D, Grimson J, Stephens G, Felton E, Given P and O'Moore R (1998). Federated healthcare record server - the Synapses paradigm. International Journal Medical Informatics, Elsevier Science, Vol.52, pp.3-27. [13] Kuperman G J, Teich J M, Tanasijevic M J, Ma'Luf N, Rittenberg E, Jha A, Fiskio J, Winkelman J, and Bates W (1999). Improving response to critical laboratory results with automation: results of a randomised control trial. JAMIA, Vol.6 No.6, pp.512-22. [14] Lepage E F, Gardner R M, Laub R M and Jacbson J (1992) Assessing the effectiveness of a computerised blood order “consultation” system. Evalvation-Real KBS 955 pp3337 [15] Matimer D, McCauley B, Nightingale P, Ryan M, Peters M and Neuberger J (1992). Computerised protocols for laboratory investigation and their effect on use of medical time and resouces. Journal of Clinical Pathology, Vol.45, pp.572-574. [16] McDonalds C J, Wilson GA and McCabe G P (1980). Physician Response to Computer Reminders. JAMA Vol 244, No. 14 [17] Miksch S (1999). Plan Management in the Medical Domain. AI Communications, Vol.4. [18] Musen, M A, Tu S W and Shahar Y (1992) A problemsolving model for protocol-based care: from e0ONCOCIN to EON. MEDINFO 92 K C Lun et al Eds. Elsevier Science Publishers pp519-525. [19] Musen M A, Tu S W, Das A K and Shahar Y (1996). EON: A component-based approach to automation of protocoldirected therapy. JAMIA, Vol.3 No.6, pp.367-88. [20] Naszlady A (1998). Protocols guides and tools. Int’l Journal of Med Informatics, Elsevier Science, Vol.52: pp. 47-59. [21] Ohno-Machado L, Gennari J H, Murphy S, Jain N H, Tu S W, Oliver DE, Pattison-Gordon E, Greenes RA, Shortliffe EH, Barnett GO (1998). The GuideLine Interchange Format: A Model for Representing Guidelines. JAMIA Vol.5 No.4: pp357-372. [22] O’Moore R, Groth T, Grimson W, Boran G eds, (1996) Advanced Informatics and Telematics for Optimisation of Clinical Laboratory Services. Computer Methods and Programs in Biomedicine, Vol. 50 No2 85-206 [23] Overhage J M, Tierney W M, Zhou X H, and MacDonald C J (1997). A randomised trial of "corollary orders" to prevent errors of omission. JAMIA, Vol.4, pp.364-375. [24] Paton N W and Diaz O (1999). Active Database Systems. ACM Computing Surveys, Vol.31 No.1, pp.63-103. [25] Peters M, Clarke I R, Parekh J, et al (1991). Automatic application of rule-based decision-support - a specialist unit

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

9


[26]

[27]

[28]

[29]

[30]

[31]

[32] [33]

[34] [35]

investigation manager. In: B Richard, (ed), Current Perspectives in Healthcare Computing, pp129-136. PRESTIGE: Guidelines in Healthcare.http://www.rbh.nhs.uk/rbh/itdept/r&d/projects/pr estige.htm 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, Vol.14, pp.29-51. Thomson R (1995). Dilemma: Decision Support Primary Care, Oncology and Shared Care. In M. F. Laires et al (Eds), Health in the New Communications Age, IOS Press. van Wijk MAM, Mosseveld M, and van der Lei J (1999a). Design of a decision support system for test ordering in General Practice: choices and decisions to make. Methods of Information in Medicine, Vol.38, pp.355-61. van Wijk M A M, Bohnen A M, and van der Lei J (1999b). Analysis of the practice guidelines of the Dutch College of General Practitioners with respect to the use of blood tests. JAMIA, Vol.6 No.4, pp.322-331. de Wilde E J L, Pop P and Hasman A (1992) A decision support system for test request screening. S Andreassen el al Eds. IOS Press Artificial Intelligence in Medicine pp 331334 Widom J, Ceri S, (eds.) (1996). Active database systems: Triggers and Rules for Advanced Database Processing. San Francisco, California: Morgan-Kaufmann. Wu B, Lawless D, Bisbal J, Grimson J, Wade V and Richardson R (1997) The Butterfly methodology: a Gateway-free approach for migrating legacy information systems. in Proceedings of the 3rd IEEE conference on engineering of complex computer systems Wu B (1998) PLAN : the framework and its language for modelling clinical test request protocols. Internal Technique Reports. Department of Computer Science, DIT. Wu B and Dube K. (2000) The BNF definition of PLAN : the framework and its language for modelling clinical test request protocols. Internal Technique Reports. Department of Computer Science, DIT.

0-7695-0981-9/01 $10.00 (c) 2001 IEEE

10