In 2000, the InterMed Collaboratory (developers of the GLIF formalism for representing clinical guidelines) asked HL7 to establish a Clinical Guidelines Special Interest Group (CG SIG) under the Clinical Decision Support Technical Committee (CDSTC) to pursue standardization in computerised guideline modeling methods. The work of the CG SIG included GELLO. GELLO was originally developed by InterMed as the GLIF v.3 expression language for query statements and decision rules. The current version of GELLO is a refinement of the specification made for GLIF.

The GELLO expression language is designed to meet the following requirements:

• the need for a standard, object-oriented language to formulate expressions for manipulating clinical data and providing decision support in various clinical applications.
• the need to support sharing of clinical knowledge between applications in heterogeneous clinical environments.
• the need to be vendor independent, platform independent, object oriented and compatible with the HL7 Reference Information Model (RIM), easy to read and write, free of side-effects, extensible and shareable.

GELLO is a class-based, object-oriented (OO) language made up of both query and expression (sub-)languages. GELLO is based on the Object Constraint Language (OCL) developed by the Object Management Group. Much of the functionality of OCL has integrated into GELLO to provide a suitable framework for manipulation of clinical data for decision support.

The GELLO language can be used to:

• "Build up queries to extract and manipulate data from medical records.
• "Construct decision criteria by building up expressions to reason about particular data features/values. These criteria can be used in decision support knowledge bases such as those designed to provide alerts and reminders, guidelines, or other decision rules.
• "Create expressions, formulae, and queries for other applications. The query and expression languages share a common OO data model since the expressions must operate on data supplied by queries."

"The GELLO query language has been designed within the context of a guideline execution model proposed in the HL7 CDSTC. This model proposes the use of a vMR (virtual Medical Record) that provides a standard interface to heterogeneous medical record systems..."

"The GELLO expression language can be used for specifying decision criteria, and abstracting or deriving summary values. The object-oriented approach of the language has the flexibility and extensibility that is needed for implementation in a broad range of applications. The expression language is strongly typed. In order to facilitate the process of encoding and evaluation of expressions and more importantly, to maximize the ability to share such queries and expressions, GELLO includes basic built-in data types while providing the necessary mechanisms to access an underlying data model with all its associated classes and methods. This is especially important in enabling decision rules and guidelines to successfully support different data models, inasmuch as classes and relationships specified could vary from one data model to another."

As noted above, the GELLO expression language has been designed to provide clinical knowledge services in the context of heterogeneous clinical environments. Most importantly, GELLO aims to be a platform independent knowledge representation that can be used and shared by any clinical application.

GELLO expressions can be translated into other languages by means of a compiler producing executable code compatible with institution-based applications. At the same time, GELLO expressions can be shared among institutions with different systems without the need of rewriting. GELLO expressions can be embedded at any point where decision rules, eligibility criteria, patient state specifications or guidelines are needed. The following two figures illustrate schematically the processes of authoring, validating and executing GELLO expressions.

Figure 1 (click for full-size image): Authoring and validating GELLO expressions is composed of three steps.

Step 1 - GELLO expressions are inserted into a clinical application(s). Examples of GELLO syntax are provided.

Step 2 - GELLO expressions are checked for correctness. In other words, each GELLO expression inserted in an application must satisfy GELLO syntax. If an expression is correctly written, it is compiled –“translated” into code that can be executed by a computer.

Step 3 - Original GELLO expressions are substituted by their equivalent in “executable code” and the application is ready for execution.

Figure 2 (click for full-size image): Executing GELLO expressions is made up of three steps.

Step 1 - The GELLO expression is evaluated to determine whether the expression is a request for patient information or an expression to evaluate previously requested patient information.

Step 2 - The dashed rectangle headed “Institution Information Systems” comprises three elements:

An HL7 RIM-compatible Database Model Structure (DBMS). To ensure compatibility, the information stored in the DBMS must be in the form of classes and properties equivalent to those found in the RIM.

An institution database containing patient-related information.

Mapping middleware tool which maps data from an institution database, in a specific format, into a standard HL7 RIM- compatible database. The mapping middleware contains a table of equivalences for elements in the Institution database and their equivalent classes and attributes in the RIM. If the expression is a request for data, the RIM-compatible DBMS receives a request for information. GELLO expressions requesting patient data are always written following the structure of the HL7 RIM, hence the need for mapping. However, if the institution database is RIM-compatible, mapping is not required.

Step 3 - Retrieved information is returned to the application (back to Step 1) and execution continues. If the expression is an evaluation expression (diamond in Step 1), the following step is to determine whether all the information required to evaluate the expression is available (diamond in Step 3). If this is the case, the evaluation takes place and the result is sent back to the application (Step 1) and execution again continues.