A Pattern-based Analysis of Clinical Computer-interpretable Guideline Modeling Languages

Introduction

Clinical practice guidelines and protocols apply to diverse areas, including policy development, utilization management, education, reference, clinical decision support, conduct of clinical trials, and workflow facilitation. Clinical guidelines seek to improve the quality of patient care and reduce costs. Creating computer-interpretable representations of the clinical knowledge supporting clinical guidelines is crucial for developing decision-support systems that provide patient-specific advice at the point of care. Automated guideline-based systems can improve adherence over paper-based guidelines.1

Although many parties have been engaged in developing languages for representing computer-interpretable guidelines (CIGs),2 3 4 5 6 7 8 9 little standardization exists of languages that fully support representation of the logic of guidelines that unfold over time. Standards would facilitate sharing and enable adaptation in local practice settings.10 Indeed, the three standards, Arden Syntax, Guidelines Elements Model (GEM), and Guideline Expression Language, Object-oriented (GELLO), which have been developed in the domain of clinical decision support, do not satisfy these requirements. GEM,11 a standard of the American Society for Testing and Materials (ASTM), is an XML-based knowledge model for guideline documents. GEM elements relate to a guideline’s identity, developer, purpose, intended audience, method of development, target population, knowledge components, testing, and review plan. Although this standard includes elements for marking up components of clinical algorithms, the resulting markup does not support computer execution that requires automatic inference. The Arden Syntax12 is a standard of ASTM and of Health Level Seven (HL7) that has been substantially used in industry. This standard is suitable for representing individual decision rules in self-contained units called Medical Logic Modules (MLMs), which are usually implemented as event-driven alerts or reminders. Arden Syntax is not designed for encoding complex multistep guidelines that unfold over time and does not offer mechanisms for complexity management and for managing linked MLMs.13 Guideline Expression Language, Object-oriented (GELLO),14 which has been recently accepted as an HL7 and ANSI standard, is a vendor-independent, object-oriented, side-effect-free, and extensible expression language that could be used for specifying and sharing decision logic and eligibility criteria, calculations, patient state definitions, conditions, and system actions. Because it was developed as an expression language, it does not support specification of entire clinical algorithms, but focuses on specifying logical expressions. GELLO is the first component of a CIG language that HL7 started to standardize to support a full CIG formalism. The other components that HL7 sought to standardize include, among others, a control-flow language.15

Because there is no standard CIG formalism, this article concentrates on nonstandard CIG formalisms of the type termed task-network models (TNMs).15 TNM CIG formalisms have in common a process-flow-like model that decomposes guidelines into a network of tasks that unfold over time, but they differ from each other in their approaches to addressing particular modeling challenges. Investigators15 compared six guideline modeling languages: Asbru, EON, Guideline Interchange Format (GLIF), GUIDE, Prescribing Rationally with Decision-support In General-practice studY (PRODIGY), and PROforma according to eight components that capture the structure of CIG languages (see Related Work section). In this article, we examine the modeling languages using control-flow patterns. The control-flow patterns have been tested by evaluating a multitude of workflow systems and standards. The feedback from industry has resulted in the revision and extension of the control-flow patterns, which nowadays serve as an accepted benchmark.17 The evaluation of CIG modeling languages is a big challenge because the terminology used in these languages is inconsistent, the semantics of the control-flow of some of the languages is incompletely and informally defined, and the approaches used by the languages for guideline modeling are heterogeneous. CIGs represent clinical algorithms that unfold over time by specifying the ordering of tasks and activities. The ordering of tasks in a process model is also referred to in the literature as control-flow, which is the perspective we focused on during the analysis. We compared the control-flow component of CIG languages by evaluating their degree of support of control-flow patterns16 17 that are known as workflow patterns. Although workflow patterns come from the business process-modeling community, they are suitable for comparing CIG languages. A CIG language is a computer-interpretable TNM of a clinical care process that realizes a clinical/medical goal, while a workflow model is a computer-interpretable TNM of a business process that realizes a business objective. From the control-flow perspective, both of these types of models (languages) are TNMs and are comparable from the control-flow perspective.

Initially, we intended to analyze the current versions of the same set of TNM languages as considered in Peleg15: Asbru,31 EON,3 GLIF,4 NewGuide,7 PRODIGY5 and PROforma.39 However, we excluded from our analysis NewGuide because it is still under development and PRODIGY because it is no longer actively supported.

Background

This section describes the main concepts of the CIG modeling languages Asbru, EON, GLIF, and PROforma and presents work related to workflow patterns.

Computer-interpretable Guidelines

Table 1 illustrates terms used in the CIG modeling languages that correspond to the main workflow concepts that will be used throughout this article. These terms include process model, case, task, parallel branching, and exclusive branching and are defined in van der Aalst et al.18 A process model consists of a number of tasks that have to be carried out and a set of conditions that determine the order of tasks. A task is a logical unit of work that is carried out as a whole. Tasks can be executed based on sequential, parallel or conditional routing. Parallel branching specifies that two or more tasks are executed independently of each other. Exclusive branching splits a process in several branches, only one of which can be selected based on the fulfillment of a condition associated with a given branch.19 Process models are executed for specific cases (e.g., a patient with high blood pressure being managed by a hypertension CIG). Each case involves a process being performed, with its current active tasks. In Appendix 1 (available as a JAMIA online data supplement at www.jamia.org), we describe in more detail the main concepts of CIG modeling languages by modeling a patient diagnosis scenario in Asbru/AsbruView, EON/Protege-2000, GLIF/Protege-2000, and PROforma/Tallis, as shown in Figures 1-4 respectively, in the online data supplement.29

Workflow Patterns

The recent Workflow Patterns Initiative17 has taken an empirical approach to identifying the most common control constructs inherent to modeling languages adopted by workflow systems. In particular, a broad survey of modeling languages resulted in 20 workflow patterns being identified.20 The collection of patterns was originally limited to the control-flow perspective, thus the data, organizational, and application perspectives were missing. In addition, the set of control-flow patterns was not complete because the patterns were gathered nonsystematically: they have been obtained as a result of an empirical analysis of the modeling facilities offered by selected workflow systems. The first shortcoming has been addressed by means of the systematic analysis of data and resource perspectives and resulted in the extension of the collection of the control-flow patterns by 40 data patterns and 43 resource patterns.21 22 The issue of the incompleteness of the control-flow patterns has been resolved by means of the systematic analysis of the classical control-flow patterns against Workflow Pattern Specification Language.23 Furthermore, the originally identified set of the 20 control-flow patterns has been revised and extended with 23 new patterns. A comprehensive description of the full set of 43 control-flow patterns is found in Russell et al.16

The 43 patterns can be divided into several groups: basic control-flow patterns, advanced branching and synchronization patterns, structural patterns, multiple instances patterns, state-based patterns, cancellation patterns, and the 23 new patterns that will be classified outside the scope of this research. Due to the lack of space, in this article we provide only the description of patterns that have received different ratings by the examined languages, and are therefore the most interesting. These definitions are given in the Results section, so that the discussion of the different ways in which the CIG languages support these patterns could be easily followed.

Workflow patterns have become a standard for assessing strengths and weaknesses of process specifications. Many workflow systems and standards such as XML Processing Definition language (XPDL), Unified Modelling Language (UML), Business Process Execution Language (BPEL), The eXtensible Language (XLANG), Web Services Flow Language (WSFL), Business Process Modelling Language (BPML), and Web Service Choreography Interface (WSCI) were evaluated from the perspective of the control-flow patterns, a summary of which is available17 The patterns have inspired the improvement and development of 10 languages and tools.17 Furthermore, the workflow patterns were used for selecting a workflow management system (WfMS) (i.e., a system in which workflows are defined, created, and executed) and have been used in teaching.17

Research Questions

The main research questions addressed by this study are: “What is the degree of support of the control-flow patterns in special-purpose languages for modeling clinical guidelines?” and “What are the differences, from the control-flow perspective, between process languages offered by workflow management systems and modeling languages used to design clinical guidelines?”

Methods

In this section we describe the types of analyses that we carried out and the criteria used for evaluating the pattern support offered by the examined CIG modeling languages.

Analysis

We evaluated the set of CIG languages against the revised set of 43 control-flow patterns, described in detail.16

To compare the examined languages, we used quantitative and qualitative measures. We calculated the number of patterns supported by the examined languages directly, indirectly, and not supported at all. Furthermore, we analyzed in greater detail the differences between the languages based on the support of patterns that have received different ratings. In particular, we underlined the strengths of CIG languages that were unique in their support of particular patterns, the significance of this support to clinical guidelines, the different ways in which the considered languages support the workflow patterns, and how they differ from process modeling languages used in the business domain.

Evaluation Criteria

For each language, we checked whether it is possible to realize the control-flow pattern with the facilities offered by the language. As a means for evaluation, we used evaluation criteria explicitly defined.16 These evaluation criteria specify a set of context conditions an analyzed language has to fulfill in order to support a pattern. The pattern support has been rated as full, partial, or no support. A pattern is fully supported (+) if the examined language fully satisfies the evaluation criteria for the pattern and provides direct support for each of them via constructs found in the language. A pattern is supported partially (+/−) if the examined language provides indirect support for all of the criteria either via extended workarounds or programmatic extensions. A pattern is not supported (−) if the examined language does not satisfy any of the criteria for direct or indirect support. To make sure that our understanding of the CIG languages abilities was correct, the developers of the four languages that we compared reviewed our article before its submission.

Results

Comparing CIG Languages Support of Categories of Workflow Patterns

Table 2 summarizes the support of the full set of 43 patterns by the languages. The brief description of pattern categories used for the evaluation is given in Table 3. We explicitly elaborate on patterns that received different ratings by the examined languages (i.e., patterns that are supported only by a subset of the examined languages), which underline the weaknesses and strengths of these languages essential for understanding of the article in Appendix 2 (available as a JAMIA online data supplement at www.jamia.org). We provide the full set of results in an online source.24

After analyzing how the four CIG languages support the specific workflow patterns, as summarized in Table 2, we tried to arrive at more general conclusions about the languages’ support of categories of workflow patterns. As the results of the analysis have shown, PROforma offers direct support for the largest number of patterns (22 of 43) among the examined offerings. Asbru and GLIF offer support for 20 and 17 patterns, respectively. Even fewer patterns are supported by EON (it supports only 11 patterns).

More detailed analysis of the pattern support reveals that all examined offerings directly support basic control-flow patterns. At least half of the advanced branching and synchronization patterns, which are relatively common to business processes used in practice, are supported by all offerings. Note that the structured synchronizing merge pattern is not supported by all examined offerings. Although PROforma supports this pattern directly, Asbru adds a time restriction to the process of synchronization to approximate the desired behavior. The semantics of the synchronization blocks in EON and GLIF are not precise enough, i.e., they do not specify what happens to the active tasks after the synchronization task has been executed. This also is the reason why some of the new patterns addressing variants of the synchronization merge are not supported by EON and GLIF.

None of the examined modeling languages have the concept of a multiple instance activity, and therefore, patterns from the multiple instances pattern group and new patterns related to the multiple instances activity are not supported directly.

Not all examined languages have full support for the state-based patterns. Although EON and GLIF have the notion of the patient state, they lack the notion of the process state. The only language that used these concepts is PROforma. All analyzed languages support the cancellation patterns relatively well.

Unique Features of the CIG Languages

While evaluating the modeling languages and studying their documentation, we identified several scenarios not covered by the set of the control-flow patterns that we had used as a reference framework. In particular, a deferred multichoice is a capability to defer the selection of multiple options by a user until the user decides that no more options will be selected (for instance, selecting several medicines from the recommended ones for the treatment of the patient). The functionality of the deferred multichoice has been encountered in GLIF3.5/Protege-2000, EON/Protege-2000 and PROforma/Tallis. Another scenario is related to forced trigger, where any internal or external event triggers the execution of a task even if the task precondition was not satisfied at the moment of triggering. The functionality of the forced trigger has been encountered in PROforma/Tallis.

In addition, guideline modeling languages allow for some flexibility by offering expression languages that support modeling of complex decisions. They also provide ways for modeling decisions as argumentation rules (rule-in and rule-out), which are unique features that affect control-flow specification and are not offered by workflow management systems.

Another aspect of flexibility, offered in EON and GLIF, is the ability to specify multiple entry and exit points to a guideline. Such a feature might be useful when, due to unpredictable changes in a patient’s state, a patient has to jump from one state of the guideline, at which he was situated at the previous encounter, to another state that reflects his current situation (e.g., his condition deteriorated despite the use of the guideline, or due to a different guideline that was applied to him, medications were added, etc.). However, such support of multiple entry points is not unique to EON and GLIF and has alternatives; similar behavior can be achieved by means of the state triggers in PROforma.

Discussion

Members of the computerized guidelines community have emphasized how important it is to support flexibility in guideline formalisms.4 15 25 However, when we examined guideline modeling languages, we found only limited additional flexibility not present in business process modeling languages. The CIG languages we studied support only two new patterns not encountered in business process models. This is remarkable because one would have expected dedicated constraints allowing for more flexibility given the more dynamic nature of care processes.

Moreover, only half of the workflow patterns elicited from business process modeling languages are supported by CIG languages. An interesting question is whether the patterns that are not supported by CIG languages could be useful in the domain of clinical guidelines automation. Many of these patterns relate to flexibility of process execution. In the business processes domain, multiple threads of execution that relate to the same activity are often supported (e.g., an insurance claim with a variable number of witness statements or an order containing multiple order lines). Similar situations may arise when a clinical trial is executed for groups of patients, for example. To identify whether there is a need for CIG modeling constructs supporting multiple instances, more research has to be done addressing the nature of the clinical guidelines requirements.

Because CIG languages do not offer substantially more control-flow constructs than business process modeling languages, the medical community might rethink the use of more general formalisms and tools, which have formal foundation and have been widely tested and used in industry, for expressing control flow of guideline models. For instance, the case-handling system FLOWer26 offers a high degree of flexibility during the execution of a case (i.e., a process instance). FLOWer is based on an information-driven approach and takes the process as its focal point, whereas traditional workflow management systems are based on the routing of activities from work tray to work tray, leading to inflexibility. Although FLOWer suggests which steps have to be performed according to the modeled process description, a user is able to execute any task from the given list, even to re-execute some of them. This may be very useful for clinicians who are using guidelines and disagree with the advice provided by the CIG because they think that their patient’s case was not considered by the developers of the CIG or that new evidence suggests another treatment option. We note that some of the CIG execution engines (e.g., GLIF’s execution engine Guideline Expression Language Object-oriented (GLEE)) support execution of any task that is defined in the CIG, at any point in time, if the user wishes to do so. Yet, this execution semantics is not part of the semantics defined for the GLIF language.

In addition to the set of constructs discussed in this article, the medical community may also consider using configurable modeling constructs, found in business process formalisms.27 A CIG developed by one organization can be locally adjusted by another organization by using configurable modeling constructs. Such configurable constructs enable specifying ahead of time what part of a model can be configured and how. For instance, a choice between various kinds of tests performed by a laboratory can be configured to a choice between a blood analysis and a urine analysis that are performed by an assistant of a family doctor. This is very important, as some changes that are made locally could violate the purpose of the guideline and it is therefore important to define what changes should be permitted.

Another area that has been developing in the business process community and could benefit the CIG community (especially if it would adopt a workflow-based semantics of process models) is the area of process mining.28 Mining logs of executed events (e.g., medication ordering, patient referrals) can be used to discover the actual workflow of patient care and how it deviates from a CIGs process model.

The results of the evaluation presented in this article could be used to clarify language specifications. Moreover, the evaluation results can be used as a means for comparing the capabilities of the languages to express the control-flow patterns and for selecting an appropriate modeling language. For instance, medical organizations that plan to automate their processes and improve the quality of care by using CIGs may match the list of their requirements against the results of the pattern-based evaluation. For example, if an organization requires exclusive execution of activities in non-predefined order, then Asbru might be chosen, because no other language from the evaluated ones offers these feature (see pattern 17). If a requirement is to incorporate transient triggers (pattern 23), then the best choice would be PROforma; persistent triggers (pattern 24) also are supported by GLIF. PROforma is also a good choice if such requirements as synchronization of variable number of paths (pattern 37) or support of milestones (pattern 18) are important. The milestone pattern is important for modeling medical guidelines. For example, in a cancer protocol, two treatment strategies could be used: a surgery or medication. A surgery may be performed only if medication cannot be prescribed or it does not help. Checking the state of medication effect before enabling the surgery could be done by means of the milestone pattern. GLIF or EON could be a language of choice if flexibility in the structure of a guideline is required (they support the arbitrary cycles pattern).

The analysis we performed and reported in this article has several limitations. It concentrates only on the control-flow aspect of the guideline formalisms and does not take into consideration other aspects such as data and resources. Furthermore, the evaluation has been performed on the limited set of the languages. In particular, a few formalisms that are recognized as standards, e.g., Arden syntax and GEM, were not included in the study. Note that Arden syntax has been excluded because it is used to model individual decisions (not guidelines that unfold over time). GEM is focused on the guideline DOCUMENT model—structuring the evidence statements and the decision variable. GEM permits to markup text as imperative recommendations or as parts of decisions tables; at the same time, it misses the logic of a guideline that unfolds over time.

Conclusion

From a flow-control perspective, the Asbru, EON, GLIF3.5, and PROforma CIG languages are very similar to the process languages of workflow management systems, although they do not make use of many of the workflow patterns in such systems. The additional workflow patterns supported by process languages of workflow management systems may be useful for clinical guideline applications. A suitable CIG can be selected for a specific modeling and execution task on the basis of pattern-based requirements.