$$ - Implementing effective clinical decision support

Overview

The goal of decision support is often touted as one of the key drivers for Health IT, in that it will result in improvements in patient outcomes, cost savings and other benefits. According to AMIA’s Clinical Decision Roadmap, “decision support has the capability to reduce adverse effects, improve health maintenance and chronic disease management, improve efficiency of health care and reduce costs”. NEHTA’s response to the Boston Consulting Group Report also flagged decision support as an area of interest to examine over the coming year.

Decision support systems are not simple endeavours. While decision support is seen as the end game, many health informatics standards need to be in place before effective decision support can work. This includes atomic data in messages, good use of terminology, structured data collection, and an engine to run decision support rules. Medical-Objects have always had a plan to implement decision support in our systems — this plan has led us to embrace technologies such as SNOMED-CT, Archetypes in HL7 2.3.1 and to implement the world’s first GELLO Compiler.

Some of these concepts may be new to the readers, but in essence, the combination of these tools allows you to capture data in a structured way, make suggestions and in some cases automate decisions based on the existing EHR data.

Decision Support for Lymphoma

In 2006-07, the Haematology Society of Australia and New Zealand, the Leukaemia Foundation, Sullivan Nicolaides Pathology, Queensland Medical Laboratories and Medical-Objects all participated in the development of a tool called the Lymphoma Wizard. The purpose of this tool was to implement an executable version of the clinical practice guidelines for the diagnosis and management of lymphoma available from the Cancer Council’s web site.

Starting Small

Like most projects, especially IT systems, adoption of a decision support system needs to start small to create small victories.

Initially we created the archetypes that would be needed to capture the data and created an editor to represent the workflow and present static guideline information. These steps alone would constitute a decision support system that still would provide benefits. It can demonstrate the flow of actions that are recommended for the clinician, and the clinician would not have to refer to paper guideline documents that may already be out of date. When updates to a clinical guideline occur, these updates would automatically be pushed from the author to the clinician’s desktop. This is important as it allows for updates in best practice to be distributed automatically. In the case of the Lymphoma Wizard, updates could potentially incorporate new treatments relating to new drugs that help patients or give them a list of updated clinical trials that may benefit the patient.

Enhancing the Decision Support

At this point, we then had a working version of the decision support tool that was practical to use. Once this was in place, we could complement the system by incorporating decision support rules in the form of GELLO.

GELLO is an object orientated expression language (it is an ANSI standard programming language managed by the HL7 organisation) designed specifically to represent the logic in clinical guidelines. GELLO’s object orientated nature allows it to extract data in more powerful ways including queries, sorting, statistical analysis and much more. GELLO is based on the Objects Management Groups’ OCL (Object Constraint Language). Many software developers would be familiar with OCL as it is used in UML and in many tools that can support Model Driven Architecture (MDA).

What makes GELLO so effective for clinical decision support is that it is designed to work against the clinical record of a patient or patients using something known as a virtual Electronic Medical Record (vEMR). The vEMR is based on HL7 version 3 Reference Implementation Model (RIM) to model the patient information. As Australia predominantly uses HL7 version 2 as its messaging standard of choice, we have created an implementation of the HL7 v3 model that uses HL7 v2 as its data model. This allows for the results that are received from Pathology Labs, Specialists and other clinicians to be incorporated into the solution, and provides a pathway to HL7 v3 and CDA. While both HL7 v3 and CDA may be many years away from widespread Australian usage, the investment in the decision support logic will not be wasted.

The following snippet of Gello code demonstrates how to determine if a patient is allergic to Penicillin by examining the associated names with code or determining if there is a SNOMED-CT equivalence of Penicillin:

CODE

GELLO can be used for a variety of purposes. It can be used for screening of pathology results for notifiable conditions, perform preliminary checking on the patient to determine possible risks for surgery or contraindications for medications based on the patients past history.

Archetypes, which we will look at next, define the structure of clinical data collection. Medical-Objects implementation of Archetypes also includes support for GELLO as a way of calculating data about the patient, determining what information is valid and also what information should be visible or hidden based on the information known about the patient. We have combines Archetypes and GELLO to automate the calculation of clinical scores, such as the Crohn’s Disease Activity Index (CDAI), which can be used to monitor a patients progress. GELLO can read the results of recent blood tests automatically, removing the drudgery involved in calculating these scores manually.

A slightly more complex example using the patients past surgical history to screen for past open surgery:

CODE

Many in the health industry are aware of Archetypes, primarily as a result of their promotion through openEHR. Archetypes themselves are a concept not tied to openEHR and can be applied elsewhere, including HL7 v2.

Structuring information appropriately for data entry is essential to capture information particular to a clinical workflow. Many of those filling in the details of a clinical observation or incident are not concerned with the coding as such, however this coded information is essential to ensure that a computable level of information is provided in the data. The archetypes can map concepts to SNOMED‑CT and reduce the complexity of data entry by dynamically hiding and showing sections of the data entry form at run time. This eliminates text such as “If negative, go to section seven”. Section seven only appears when it is needed. The data entry forms are constructed automatically from the archetype and are dynamic.

The archetype fragment for the lymph node shown in Figure 2. The data entry form is created automatically. You would not realise by filling in the form that you are entering coded information that will then become part of the patients computable medical record. By consistently using data entry methods which enrich our knowledge of the patient that we are able to use the information gathered in ways that are not only available to use for our immediate use, but for data mining for public health, for determining what pathway the patient should take through a guideline, or by eliminating the need to order unnecessary tests.

The Lymphoma wizard includes electronic ordering and the content of the orders is dynamic and based on the patients path through the guideline. It is these features that can improve patient outcomes and reduce clinician workload and will allow us to move to a more pro-active mode of monitoring and also save costs and man-hours in unnecessary tests. Using Archetypes in HL7, the collected data can also be then on sent to applications that support HL7 from an enterprise hospital system, a disease registry or through to a practice management system.

GLIF - Workflow for Clinicians

The Guideline Interchange Format (GLIF) is designed to implement an executable clinical guideline in a single file that can be easily distributed to many groups. Since 2004, GLIF has used GELLO as a way of expressing decisions and eligibility criteria. In a practical sense, GLIF is used to obtain clinical findings and provide information in the form of diadatics. By providing information at the point of the decision and the ability to access patient data through GELLO, GLIF can provide one of the most sophisticated decision support environments possible.

The reality is that the Lymphoma Wizard is not a single application, but instead, it is a GLIF file that not only contains the information about the guideline and workflow steps, but also the Archetypes required for the guideline, in addition to the GELLO rules that evaluate the patient information based on what has been selected and what is available in the patient EHR.

The GLIF file is structured in XML and can be downloaded and updated easily. Making modifications to the guideline is an extremely easy process that can be done by clinicians with some training in the GELLO syntax and our GLIF editor.

The advantage of a system that supports GELLO is that it can be enhanced and extended by clinicians, and customised for an institution without recompiling the application. This allows domain experts to capture knowledge and logic that can examine the individual patients history, medications and lab results and make recommendations that are specifically customised to the patient sitting in front of the clinician. This eliminates noise by filtering and refining the recommendations to make them highly relevant and useful. It also opens the door for agent like processes to interrogate the EHR, constantly checking on a patients progress in the background, while the clinician is at home asleep.

Rector’s Model of Models

Many in the health informatics space will be familiar with Rectors model of models which analyses the interfaces between information, terminology and inference. Figure 4 presents Rector’s model in the context of the Medical-Objects’ solution, highlighting the links between the information, terminology and inference.

The interfaces between the models are a critical part of the solution. Between both the information model/inference model and the inference and concept model, GELLO is used. For the interface for the between the information and concept models. This interface can vary depending on how much semantic richness is to be found in either model, so sometimes SNOMED-CT has clinically relevant modelling richness, sometimes its the EHR model or the archetype that is rich. If the former situation obtains then we can make use of the richness of the SNOMED CT concept model. If the later, then SNOMED-CT can be dumbed down to simply supply attribute values.

Summary

The ability to build rich decision support capabilities is available today, and like the Lymphoma Wizard it needs to be built on the best knowledge available and in an easily updatable standards based format. By combining Electronic Health Records, HL7 based Archetypes, Clinical Terminologies, GLIF and GELLO the end game of decision support becomes possible. Standards are used at every level to ensure that the solution can be implemented by anyone.

References

  1. Greenes, Robert A. Clinical Decision Support - The Road Ahead. Rector’s Model of Models - http://cmbi.bjmu.edu.cn/news/report/2001/medinfo_2001/Papers/Ch4/253_Rector.pdf [Accessed on 2/2/2008].

Posted in Australian eHealth

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.