# META-GLARE: A Computer-Interpretable Guideline System Shell
## 7 Related Work and Comparisons
### CIG Execution Tools  
Many CIG systems in the literature provide tools to support the execution of the acquired CIGs. In [8], [PERSON] and [PERSON] have proposed a comparison between different CIG systems (including GLARE). However, despite the fact that the title of their paper explicitly focuses on CIG execution, very few details are provided about the execution engines of the different systems. Indeed, although most CIG approaches provide an execution engine, very few in-depth descriptions of such engines can be found in the specialized literature. In the rest of this subsection, we focus on three execution engines, which concern three of the most famous CIG approaches in the literature: GLIF, Asbru, and PROforma. **GLIF** (GuideLine Interchange Format) was proposed in 1998 by a consortium involving Columbia University, Harvard University, and Stanford University to provide a standard guideline representation formalism [10]. Several versions of GLIF have been proposed, finally leading to GLIF3 [12] (see Section 1.3). The GLIF3 Guideline Execution Engine, called **GLEE**, has been described in detail in [37]. GLEE is a client-server system, in which each GLEE client corresponds to the application of a CIG to a particular patient, and a GLEE server supports several tasks, particularly the execution of a specific instance of a guideline on a specific patient. GLEE is based on the \"_system suggests_, _user controls_\" philosophy: at any time during the execution of a guideline, users are free to deviate from the guideline recommendations (e.g., not performing the CIG action suggested by the system). GLIF3 is based on the TNM model. GLIF3 distinguishes between _clinical tasks_ (the most important are _action steps_, _decision steps_, and _patient state steps_) and _scheduling tasks_ (including _branch step_, _synchronization step_, sequence step, and _subguideline_). The execution of _action steps_ depends on the type of task defined in that step. For instance, the execution of a medically oriented action consists of a message to notify the local clinical information system, while a data request task involves data retrieval from the clinical data repository. Two different types of _decision steps_ (_case steps_ and _choice steps_) are defined in GLIF3. The execution of a decision _case step_ involves the evaluation of the decision criteria associated with each alternative option until one criterion is satisfied. The corresponding option is then automatically selected by the system, and the subsequent step in that option is scheduled for execution. On the other hand, in the case of a decision _choice step_, the alternatives are presented directly to the user (GLEE waits for the user's answer and then schedules the corresponding step). Finally, a _patient state step_ models a criterion to define the patient's status and is executed by GLEE's execution engine by asking the user whether the patient meets the criterion or not. _Scheduling tasks_ basically define the _control flow_ in the execution of GLIF3 CIGs. In GLEE, the execution of a _branch step_ leads to the scheduling and concurrent or any-order execution of subsequent steps. A _synchronization step_ in GLIF3 represents a converging point in a CIG's algorithm and is associated with a continuation criterion. The execution of a synchronization step involves the evaluation of such a criterion: the executor waits until the completion of other converging steps eventually leads to its fulfilment. _Sequence steps_ simply regulate the order of execution, while the _subguideline_ construct supports the hierarchical representation and execution of CIGs. Notably, the execution of _steps_ in GLEE undergoes different execution _states_: (1) the _prepared_ state (the execution engine suggests that such a step is executable according to the CIG under execution), (2) the _started_ state, (3) the _stopped_ state, and (4) the _finished_ state. Finally, GLEE also supports an _event-driven_ execution model by defining triggering events for a specific CIG step.