Stephan R.A. Deibel Decision Systems Group Brigham & Women's Hospital Harvard Medical School Boston, Massachusetts November 4, 1996
Guideline interchange can take place through a variety of modalities (e.g., via text file, via binary file, or via network interfaces). As a result, the InterMed Collaboratory created a Guideline Interchange Format, or GLIF, as a means to specify this common guideline representation. We chose an abstract representation of GLIF, upon which we have layered standards for interchange via several modalities. The abstract representation defines the data constructs that are involved in guideline interchange. It does not, however, define how these constructs are represented in memory or on disk. This is left to the modality-specific standards. We have currently developed interchange formats for text files (see Appendix One), and for CORBA software component interface (see Appendix Two).
The latest official version of GLIF as of this writing (GLIF-2, version 3, 8/01/96) is complete as far as exchange of human-readable guidelines is concerned. However, it is missing details required for interchange of guidelines for processing by software (e.g., in automated selection of guidelines, or traversal within a guideline). A version of GLIF, called GLIF2.5_beta2, has been proposed by the Decision Systems Group to add some of the supported required for software processing. The text that follows is, however, based on GLIF2 version 3 and indicates areas in which GLIF requires additional specification work, as addressed in GLIF2.5_beta2. This document will be updated when GLIF2.5_beta2 or some future version of GLIF is accepted universally by the InterMed group. This process may be relatively lengthy due to the required evaluation period for introducing more structured models for patient data and actions.
GLIF consists of a number of object class definitions, each of which carries some data. A guideline is made up of a collection of data elements, or instances, that are structured according to these class definitions. At the highest level, each guideline is described by the Guideline class, which is represented as follows:
interface Guideline {
attribute string name;
attribute sequence <string> authors;
attribute string intention;
attribute Criterion eligibility_criteria;
attribute sequence <Guideline_Step> steps;
attribute Guideline_Step first_step;
attribute sequence <Supplemental_Material> didactics;
};
Each guideline is thus endowed with a name, a list of authors, a
characterization of the guideline's intention, eligibility criteria, a list of
all steps in the guideline, the starting step in the guideline, and a list of
supporting didactic material.
The intention of the guideline is a formal characterization of the purpose of the guideline, which is currently encoded as free text, and will subsequently be formalized. Eligibility criteria include an unordered list of conditions that must be true before a guideline is applied to a given case. Didactics consist of WWW URLs or other pointers to supporting materials for the guideline as a whole. Throughout GLIF, didactics are associated with various classes that make up the guideline specification. The detailed definition of Supplemental_Material can be found in Appendix Three.
The guideline consists of a collection of steps, arranged in a graph structure that may be traversed according to the nature of a specific case. A number of step types are defined for capturing the nature of decision making and actions that take place during the patient care process. Each of these steps contains a name and a list of supporting didactic material. The generic guideline step is defined as follows:
interface Guideline_Step {
attribute string name;
attribute sequence <Supplemental_Material> didactics;
};
Each guideline step class descends from this class, and thus inherits the name and didactics attributes (which are not again listed explicitly in the text that follows).
Action steps are used to record the actions that are actually performed during the patient care process that is being modeled by the guideline. Each action step contains an action specification, optionally a sub-guideline, which details the action at a finer level of granularity, and a pointer to the next step in the guideline, that is reached once the action has been performed. The action step is defined formally as follows:
interface Action_Step:Guideline_Step {
attribute Action_Spec action;
attribute Guideline subguideline;
attribute Guideline_Step next_step;
};
Each action step may contain exactly one action, which is defined as containing
a name, an intention (the goal of the action; currently free text, which will
be formalized in the future), a list of patient data which are collected by the
action (if not already available), a description (also free text; may be
formalized in the future), and the usual list of associated supporting didactic
materials. The action specification is defined formally as:
interface Action_Spec {
attribute string name;
attribute string intention;
attribute sequence <Patient_Data> patient_data;
attribute string description;
attribute sequence <Supplemental_Material> didactics;
};
Each action may in turn contain zero or more patient data elements, which are
values that are collected as a result of that action (note, however, that some
actions are purely therapeutic, and do not result in data collection). Patient
data are current modeled as containing, for each data element: a data element
name, type, an optional list of acceptable values, a measure of how recent
a value must be to be considered valid, and a list of supporting didactic
materials. However, the formal specification for patient data, given below,
requires further refinement in order for patient data to be sufficiently
structured for software manipulation and interpretation of values.
interface Patient_Data {
attribute string name;
attribute string type;
attribute sequence <string> possible_values;
attribute string temporal_constraint;
attribute sequence <Supplemental_Material> didactics;
};
Conditional steps direct flow to one of two other guideline steps, depending on the truth value of a conditional. The conditional step is defined formally as:
interface Conditional_Step:Guideline_Step {
attribute Criterion condition;
attribute Guideline_Step destination; /* When condition is TRUE */
attribute Guideline_Step otherwise;
};
The criterion combines patient data values with arithmetic and boolean
comparisons, evaluating to TRUE or FALSE; three-valued logic is also supported.
The Criterion is detailed in Appendix Three.
Branch steps direct flow to one or more of a number of guideline steps, according to a non-boolean selection method. Branches are "traversed" either in parallel (simultaneously) or one at a time. The branch step is formally defined as follows:
enum t_ordering {any_order, parallel};
enum t_selection {all_of, some_of, one_of};
interface Branch_Step:Guideline_Step {
attribute sequence <Guideline_Step> branches;
attribute t_selection selection_method;
attribute t_ordering order_constraint;
};
Synchronization steps are used in conjunction with branch steps to
synchronize flow of control through multiple, parallel paths. When the
selection method on a branch step is "parallel", the synchronization step is
placed further along each possible path exiting the branch step, in order to
re-synchronize the flow of control before additional steps in the guideline are
visited. The synchronization step is formally defined as follows:
enum t_continue {wait_for_all, proceed_after_one, loop};
interface Synchronization_Step:Guideline_Step {
attribute Guideline_Step next_step;
attribute t_continue continuation;
};
When the continuation value is set to "wait_for_all", all of the preceding
steps must be completed before control moves along to the next step; when it is
set to "proceed_after_one", one of the preceding steps must be completed before
moving to the next step; and when it is set to "loop", the next step is
repeated each time that one of the preceding steps has completed.
GLIF defines guidelines as being constructed from a variety of guideline steps, including action steps, and various types of decision steps. During traversal of a guideline in a given case, the guideline is entered from a starting point, and traversal is defined according to the values of data that are collected by actions in the guideline, and the values of conditions on conditional steps in the guideline. The model provides support for parallel "execution" of portions of the guideline, and for the association of supporting or didactic materials with various parts of the guideline.
GLIF guideline steps are relatively primitive, making it possible to map higher-level guideline representations to and from GLIF. E.g., a higher-level guideline node that contains multiple actions and conditionals on outgoing paths may map to a number of GLIF action steps, combined with a series of cascaded GLIF conditional steps. With some additional formalization of actions, patient data, and criteria, traversal of GLIF guidelines will be computable, based on the evaluation of conditionals against known patient data values for a specific case.
This appendix briefly describes the text-based guideline interchange format (GLIF) that was developed using the abstract guideline specification given in Appendix Three. It is excerpted from technical report number DSG-96-04, written by Edward Pattison-Gordon.
GLIF is based on a more generic object data interchange formation called ODIF, for Object Data Interchange Format, that was developed at the Decision Systems Group. ODIF is a formal notation for representing instances of objects in text. Since objects have attributes, an instance of an object will have particular values stored in its attributes. ODIF, then, provides a syntax for recording these values in a text file. The values can be retrieved from the text file in order to recreate the object.
ODIF is concerned with the interchange of object instance data. Each object instance belongs to some externally defined class, such as those that are defined in the abstract guideline interchange specification given in Appendix Three.
For example, the abstract specification for the guideline class is:
interface Guideline
{
attribute string name;
attribute string intention;
attribute Criterion eligibility_criteria;
attribute sequence <Guideline_Step> steps;
attribute Guideline_Step first_step;
attribute sequence <Supplemental_Material> didactics;
};
An instance of this class given in ODIF is encoded in text as:
Guideline breast_mass_evaluation
{
name = "Breast Mass Guideline";
intention = "Evaluation of breast mass.";
eligibility_criteria = NULL;
steps =
SEQUENCE 3
{
(Guideline_Step 1);
(Guideline_Step 2);
(Guideline_Step 3);
};
first_step = (Guideline_Step 1);
didactics =
SEQUENCE 1
{
Local_Material 1
{
label = "critique";
MIME_type = "text/plain";
material = "Published guideline does not contain explicit eligibility criteria.";
};
};
}
This instance of the Guideline object been given the unique identifier,
"breast_mass_evaluation". The object's attributes are listed, followed by their
values. ODIF provides syntax for representing all of IDL's basic data types.
Thus, for example, string values are enclosed in quotes and sequences begin
with the keyword, "sequence", followed by the number of items in the sequence,
then a list of the items themselves.
When the value of an attribute is an object, the object instance can either be included explicitly in the representation as is the case, for example, with the instance of the object, "Local_Material", in the attribute "didactics" -- or a reference can be made to the instance, which must be included somewhere in the interchange file. An object reference is composed of the name of the object class and the instance's unique identifier. The value of "first_step", for example, is given with an object reference and the value of "steps" is a sequence of object references. (Note that unique identifiers can be either names or numbers.) Another form of object reference is "NULL", which is used when there is no object for the value of an attribute. This is the situation, for example, with the attribute "eligibility_criteria".
The complete ODIF grammar specification is beyond the scope of this document. The reader is advised to combine examination of sample guidelines in GLIF text format, available from members of the Intermed collaboratory, with reference to the ODIF grammar, as given in the Decision Systems Group's technical report number DSG-96-04
A number of guidelines have been encoded by members of InterMed using the GLIF text format, several with duplicate encodings at each site, in order to evaluate the degree to which authors will produce uniform guidelines in the same area. These can be compared from the InterMed Guideline Representation Evaluation page. Or, for a quick sampling, see one of the following:
In the process of actual guideline development, the author can choose to work directly in text-based GLIF. However, to facilitate this process, guideline authoring environments that can import and export textual GLIF have been developed at least at Stanford and the Decision Systems Group.
The following Interface Definition Language (IDL) specification was developed for use with the CORBA standard for distributed object computing. It is currently in use at the Decision Systems Group at Harvard, where we are developing a guideline server based on it. This specification enables API-level integration of guideline-oriented software components. Guidelines and guideline fragments are retrieved from a guideline provider via direct calls, without requiring the translation of guidelines into the text-based guideline interchange format (GLIF). This approach is oriented towards scalable production integration of software components, where guideline information is passed among software components routinely as part of the execution of the system's routine tasks.
The IDL specification given here is based on the InterMed Guideline Interchange Format Two (GLIF-2), version 3, (see Appendix Three). The semantics and salient structure of the GLIF specification have been retained throughout. However, classes in GLIF are represented as structures here, due to the semantics of classes and structs in the CORBA specification. In some cases multiple classes where combined into a single struct.
Additionally, GSt_Unique IDs are introduced to support (a) partial retrieval of the guideline structure, and (b) recursive structures. The guideline is treated as (1) a list of guideline steps, and (2) a list of transition criteria. IDs are used to define the guideline and criteria recursive structure.
Items that are currently of unspecified format and subject to change are marked "unspec". Note that enums are augmented from the GLIF spec to include as their first value a bad/invalid enum marker.
/***************************************************************************
*
* (c) Copyright 1996, Decision Systems Group. All rights reserved.
*
* This source code is owned by the Decision Systems Group. However,
* it may be copied and distributed freely, so long as this copyright
* notice is left intact and unaltered. Altered versions of this source
* code may be distributed, so long as they are clearly marked as such,
* and this notice is left intact and unaltered.
*
* Any other copying or distributing of any part of this or any
* derivative file is in violation of federal and international copyright
* laws, and will be prosecuted to the full extent of the law.
*
* ==========================================================================
*
* FILE: GS.idl
*
* AUTHOR:
*
* John Rosenberg
* Ed Pattison-Gordon
* Stephan R.A. Deibel
*
* CREATION DATE:
*
* July 1996
*
* DESCRIPTION:
*
* IDL description for Guideline Server.
*
*/
/****************************************************************************/
/* DEFINES */
/* Guideline model ID type */
#define ID_TYPE_INT 1
#define ID_TYPE_STRING 2
/****************************************************************************/
/* TYPES */
/*----------------------------------
* Unique ID types
*---------------------------------*/
/* Unique IDs are used to uniquely identify a construct within its */
/* immediate context (e.g., a guideline node within its guideline, */
/* or a guideline on its server). They are persistent in nature, */
/* and can be used to reference the construct between server access */
/* sessions. */
typedef long GSt_UniqueID;
typedef long GSt_VersionID;
typedef sequence <GSt_UniqueID> GSt_UniqueIDSeq;
typedef sequence <string> GSt_StringSeq;
/*----------------------------------
* GLIF Supporting Materials (all types)
*---------------------------------*/
enum GSt_MaterialType { GSk_MTNone, GSk_MTLocal, GSk_MTWWW };
union GSt_MaterialData switch (GSt_MaterialType) {
case GSk_MTLocal: string material; // unspec
case GSk_MTWWW: string URL;
};
typedef struct t_GSt_Supplemental_Material {
// Core fields: Including label/purpose of the material and MIME type
string label;
string MIME_type;
// The material data
GSt_MaterialData data;
} GSt_Supplemental_Material;
typedef sequence <GSt_Supplemental_Material> GSt_MaterialSeq;
/*----------------------------------
* GLIF Logical Criteria (all types)
*---------------------------------*/
enum GSt_LogicType { GSk_BadValueLogic, GSk_TwoValuedLogic,
GSk_ThreeValuedLogic };
enum GSt_CriterionType { GSk_CTNone, GSk_CTBoolean, GSk_CTKofN };
typedef struct t_GSt_KofN {
long k;
GSt_UniqueIDSeq criteria;
} GSt_KofN;
union GSt_CriterionData switch(GSt_CriterionType) {
case GSk_CTBoolean: string spec; // unspec
case GSk_CTKofN: GSt_KofN kofn;
};
typedef struct t_GSt_Criterion {
// Core fields
GSt_UniqueID id;
GSt_LogicType logic_type;
GSt_MaterialSeq didactics;
// Data for criterion
GSt_CriterionData data;
} GSt_Criterion;
typedef sequence <GSt_Criterion> GSt_CriterionSeq;
/*----------------------------------
* GLIF Patient Data
*----------------------------------*/
typedef struct t_GSt_Patient_Data {
string name; // Persistent name; unspec
string type; // Data type; unspec
GSt_StringSeq possible_values; // Acceptable values; unspec
string temporal_constraint; // Time period of validity; unspec
GSt_MaterialSeq didactics;
} GSt_Patient_Data;
typedef sequence <GSt_Patient_Data> GSt_PatientDataList;
/*---------------------------------
* GLIF Action Specification
*--------------------------------*/
typedef struct t_GSt_Action_Spec {
string name; // Persistent name; unspec
string intention; // Goal of action; unspec
GSt_PatientDataList patient_data; // Patient data to be collected
string description; // Action specification; unspec
GSt_MaterialSeq didactics;
} GSt_Action_Spec;
/*---------------------------------
* GLIF Guideline Step (all types)
*--------------------------------*/
/* Types for branch step */
enum GSt_Ordering { GSk_BadValueOrder, GSk_AnyOrder, GSk_Parallel };
enum GSt_Selection { GSk_BadValueSel, GSk_AllOf, GSk_SomeOf, GSk_OneOf };
/* Types for synchronization step */
/* Values: Wait for all preceding steps to complete; proceed as */
/* soon as one preceding step completes; repeat this step each */
/* time one of the preceding steps completes */
enum GSt_Continue { GSk_BadValueContinue, GSk_WaitForAll,
GSk_ProceedAfterOne, GSk_Loop};
/* Step data types */
enum GSt_StepType { GSk_STNone, GSk_STAction, GSk_STConditional,
GSk_STBranch, GSk_STSynchronization };
typedef struct t_GSt_Action_Step {
GSt_Action_Spec action;
GSt_UniqueID subguideline; // Sub-GSt_Guideline for this step
GSt_UniqueID next_step; // Next GSt_Guideline_Step
} GSt_Action_Step;
typedef struct t_GSt_Conditional_Step {
GSt_UniqueID condition_id; // ID of GSt_Criterion
GSt_UniqueID destination; // Destination GSt_Guideline_Step
GSt_UniqueID otherwise; // Alternative GSt_Guideline_Step
} GSt_Conditional_Step;
typedef struct t_GSt_Branch_Step {
GSt_UniqueIDSeq branches; // Destination GSt_Guideline_Steps
GSt_Selection selection_method;
GSt_Ordering order_constraint;
} GSt_Branch_Step;
typedef struct t_GSt_Synchronization_Step {
GSt_UniqueID next_step; // Next GSt_Guideline_Step
GSt_Continue continuation;
} GSt_Synchronization_Step;
union GSt_StepData switch(GSt_StepType) {
case GSk_STAction:
GSt_Action_Step action_step;
case GSk_STConditional:
GSt_Conditional_Step conditional_step;
case GSk_STBranch:
GSt_Branch_Step branch_step;
case GSk_STSynchronization:
GSt_Synchronization_Step synchronization_step;
};
/* Step struct */
typedef struct t_GSt_Guideline_Step {
// Core fields
GSt_UniqueID id;
string name;
GSt_MaterialSeq didactics;
// Step data
GSt_StepData data;
} GSt_Guideline_Step;
typedef sequence <GSt_Guideline_Step> GSt_StepSeq;
/*---------------------------------
* Guideline-level primitives
*--------------------------------*/
typedef unsigned long GSt_Version;
typedef sequence <GSt_Version> GSt_VersionSeq;
typedef struct t_GSt_GuidelineInfo {
GSt_UniqueID id;
GSt_VersionSeq versions;
string name;
GSt_StringSeq authors;
string intention;
GSt_Criterion eligibility_criteria;
} GSt_GuidelineInfo;
typedef sequence <GSt_GuidelineInfo> GSt_GuidelineInfoSeq;
/****************************************************************************/
/* INTERFACES */
/*---------------------------------
* Guideline interface
*--------------------------------*/
interface GSC_Guideline {
// Core attributes
readonly attribute GSt_GuidelineInfo info;
readonly attribute GSt_Version selected_version;
readonly attribute GSt_UniqueID first_step;
readonly attribute GSt_MaterialSeq didactics;
// Guideline step access
GSt_StepSeq GetAllSteps(out GSt_CriterionSeq criteria);
GSt_StepSeq GetStepsByID(in GSt_UniqueIDSeq step_ids,
out GSt_CriterionSeq criteria);
GSt_StepSeq GetNextSteps(in GSt_UniqueID parent, in long depth,
out GSt_CriterionSeq criteria);
};
/*---------------------------------
* Guideline Server interface
*--------------------------------*/
interface GSC_GuidelineServer {
// Guideline selection
GSt_GuidelineInfoSeq GetGuidelineList();
GSC_Guideline OpenGuideline(in GSt_UniqueID id, in GSt_Version version);
};
Although the specification is given in DDL, which provides an abstracted representation of the data types involved in guideline exchange, it is used in a variety of ways, including in the definition of the GLIF text-based guideline interchange format (see Appendix One), and in the construction of guideline interchange APIs (see Appendix Two).
/*--------------------------------------------------------------------------*
/*
/* InterMed Guideline Representation Specification
/*
/* GLIF-2, Version 3, Last updated on 8/01/96 by John Gennari
/*
/*--------------------------------------------------------------------------*/
/****************************************************************************/
/* FORWARDS */
interface Guideline;
interface Guideline_Step;
interface Patient_Data;
interface Action_Spec;
interface Criterion;
interface Supplemental_Material;
/****************************************************************************/
/* TYPES */
typedef sequence <Guideline_Step> t_step_list;
typedef sequence <Patient_Data> t_data_list;
typedef sequence <Criterion> t_criterion_list;
typedef sequence <Supplemental_Material> t_supplement_list;
typedef sequence <string> t_string_list;
/****************************************************************************/
/* CLASSES */
/*------------------------
* Top-level classes
*------------------------*/
interface Guideline_Model
{
};
/*------------------------
* Guideline
*------------------------*/
interface Guideline:Guideline_Model
{
attribute string name;
attribute t_string_list authors;
/* a formal characterization of the guideline */
/* -- format has yet to be decided */
/* -- perhaps a combination of {Evaluation, Management, Treatment} with */
/* a specific problem, e.g., Evaluation of Breast Mass */
attribute string intention;
/* an unordered list of criteria that all must be true of a patient */
/* before applying this guideline */
attribute Criterion eligibility_criteria;
/* an unordered list of all Step objects used to represent the guideline */
attribute t_step_list steps;
/* the first Step object in the guideline */
/* -- if the eligibility criteria are true, start here */
attribute Guideline_Step first_step;
attribute t_supplement_list didactics;
};
/*------------------------
* Guideline_Step: an abstract class.
*------------------------*/
interface Guideline_Step:Guideline_Model
{
attribute string name;
attribute t_supplement_list didactics;
};
/*------------------------
* Action_Step
*------------------------*/
interface Action_Step:Guideline_Step
{
/* specification of the action, if any, to be performed in this step */
attribute Action_Spec action;
/* optional specification of the action at a finer level of granularity */
attribute Guideline subguideline;
/* next step in the guideline after action */
attribute Guideline_Step next_step;
};
/*------------------------
* Conditional_Step
*------------------------*/
interface Conditional_Step:Guideline_Step
{
/* the criteria that must be true in order to go to destination */
attribute Criterion condition;
/* step to take if condition is true */
attribute Guideline_Step destination;
/* step to take if condition is not true */
attribute Guideline_Step otherwise;
};
/*------------------------
* Branch_Step
*------------------------*/
enum t_ordering {any_order, parallel};
enum t_selection {all_of, some_of, one_of};
interface Branch_Step:Guideline_Step
{
/* an unordered list of possible subsequent steps */
attribute t_step_list branches;
/* which of the steps must be performed */
attribute t_selection selection_method;
/* true if the steps must be performed in parallel */
attribute t_ordering order_constraint;
};
/*------------------------
* Synchronization_Step
*------------------------*/
enum t_continue {wait_for_all, proceed_after_one, loop};
interface Synchronization_Step:Guideline_Step
{
/* specification of the next step */
attribute Guideline_Step next_step;
/* This attribute has three possible values enumerating rules about */
/* when to proceed to the next step: */
/* "wait_for_all" -- all of the preceding steps must be completed */
/* "proceed_after_one" -- continue when any of the preceding steps */
/* has completed */
/* "loop" -- used for looping: thus, repeat the action whenever */
/* one of the preceding steps has completed. */
attribute t_continue continuation;
};
/*------------------------
* Action Specification
*------------------------*/
interface Action_Spec:Guideline_Model
{
attribute string name;
/* the goal that is supposed to be achieved by performing this action */
/* - specification format has not yet been determined */
attribute string intention;
/* the patient data for which the action is to be performed. */
/* if this data is already available (and meets temporal_constraint), */
/* the action does not need to be performed */
attribute t_data_list patient_data;
/* the action specification */
/* - specification format has not yet been determined */
attribute string description;
attribute t_supplement_list didactics;
};
/*------------------------
* Patient Data
*------------------------*/
interface Patient_Data:Guideline_Model
{
/* formal identification of patient data item */
/* - patient data model has not yet been determined */
attribute string name;
/* what is the data type of the data item */
attribute string type;
/* the possible values for this data item */
attribute t_string_list possible_values;
/* how recent the data item has to be in order to be useful */
attribute string temporal_constraint;
attribute t_supplement_list didactics;
};
/*------------------------
* Classes for logical Criteria
*------------------------*/
enum t_logic_type {k_two_valued, k_three_valued};
interface Criterion:Guideline_Model
{
/* the logic is typed by the number of possible values it can evaluate to */
attribute t_logic_type type;
attribute t_supplement_list didactics;
};
interface Boolean_Criterion:Criterion
{
/* formal specification of criterion logic */
/* - specification language has not yet been determined */
attribute string spec;
};
interface K_Of_N_Criteria: Criterion
{
/* the K criteria that must be true */
attribute short number_to_select;
/* the set of N criteria */
attribute t_criterion_list criteria;
};
/*------------------------
* Classes for Supporting Materials
*------------------------*/
interface Supplemental_Material:Guideline_Model
{
/* the purpose of the material */
attribute string label;
/* extensible MIME standard for type of material */
attribute string MIME_type;
};
interface Local_Material:Supplemental_Material
{
/* the material */
attribute string material;
};
interface WWW_Material:Supplemental_Material
{
/* URL of supplemental material */
attribute string URL;
};