Clinical Decision Support

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. – Laurence J. Peter

Clinical decision support is of great interest right now in the United States. In September of 2007, the American Health Information Community released prototypes of six use cases, almost all of which call for clinical decision support in some way. Earlier this week, I spent about 45 minutes on the phone explaining the current state of clinical decision support standardization to a contractor working for ONC. It was an important call, even though unscheduled, and so I gave up about half the unscheduled time I had left in the day to the topic.

One reason for the interest in clinical decision support is that a number of activities can be streamlined through the use of these tools, improving care and reducing healthcare spending. These tools enable clinicians to access relevant information to provide safe and effective care. Having access to relevant information is critical. The volume of knowledge necessary to provide safe and effective care to patients is such that no human can know all that is necessary. This knowledge is growing at an extremely rapid pace. MEDLINE, a database of clinical research citations provided by the US National Library of Medicine adds hundreds of thousands of citations to its database annually.

Another reason for interest in clinical decision support is that these tools might enable automation of mandated reporting under various State and Federal regulations. A great deal of paper flows inside healthcare facilities in order to keep up with these reporting requirements. It takes a great deal of manual effort to keep this information flowing. Even when the reporting is done electronically, the information does not often originate from electronic sources, and must be manually gathered.

As the starting quote alludes to, clinical decision support is an incredibly complex problem. Before I dive into the details, I'd first like to describe what clinical decision support is. A common interpretation of clinical decision support is that it involves invoking an application (or interface or service), providing it with data, and having it invoke some action like alerting a provider or returning a treatment plan or suggestion for care (as in the case for drug interaction tools). This is just one of many different ways that clinical decision support is implemented.

Clinical decision support encompasses a variety of tools that assist healthcare providers in providing safe and effective care to patients. These tools take a variety of forms, including flowsheets, assessment instruments, drug interaction knowledge bases, vaccine forecasting tools, genetic risk assessment tools, chronic disease management solutions, population stratification tools, and quality measures.

• Flowsheets are designed to make the most relevant information available to healthcare providers quickly and easily to enable clinical decision-making.
• Assessment instruments support clinical decision-making by gathering certain information supplied by a provider or the patient, and using that information to compute results that can help providers implement appropriate care plans based on overall assessment scores.
• Drug interaction databases are probably the most common example of clinical decision support tools. These databases keep track of interactions between a drug and other drugs, allergies or conditions, and report potential difficulties when providers are ordering medications.
• Vaccine forecasting tools take information about a patients current allergies, conditions, medications, and vaccination history, and propose plans for immunizations that should be received and when.
• Chronic disease management solutions collect data on patients enrolled in a chronic disease management program, either through remote monitoring; telephone interviews, or electronic submissions from portals or provider EHR systems. These solutions review the gathered information and suggest various actions to take to facilitate management of the disease, including the scheduling appointments, patient contacts, et cetera.
• Genetic risk assessment tools gather information about a patient; including their medical history, family history, and genetic test results, and assess the patient's risk for genetically related diseases.
• Other tools allow populations to be ranked for disease risk to identify groups that may need alternate levels of care.
• Quality measures are clinical decision support tools that can be used to identify areas that need attention in a clinical practice.

All of these tools provide clinical decision support. Some are applied in the context of a single patient, while others apply to populations.

No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be. – Isaac Asimov

As the body that is responsible for selecting standards for the AHIC use cases, HITSP needs to take into account:

• existing standards,
• current works in progress,
• the impact of selected standards within and across use cases.

In March of this year, the HITSP Population Perspective TC and Care Management and Health Records TC hosted a Clinical Decision Support day at our face-to-face meeting. During that day, we heard from several experts in the area of clinical decision support, including developers of some of the clinical decision support standards described below. As a result of these discussions we learned a great deal about clinical decision support, including some of the information already provided in this blog.

At the end of the day, we synthesized a model describing clinical decision support that received a good deal of validation from the participants. An image of that model appears here.

In our model, we viewed Clinical Decision Support as a black box, through which we have three different kinds of inputs, and several different types of outputs. The inputs and outputs are of interest to HITSP because they represent areas where standards are needed to support interoperability. The three different inputs include:

1. Algorithms, or knowledge about how to make inferences or assertions based on existing instance or world knowledge.
2. Instance data describing the specific case that is being address by the clinical decision support application.
3. Ontological or "world knowledge", representing facts about the world, such as what drugs interact badly, or how body parts are related, or the relationships between genes and diseases.
   

Standards exist for each of these three areas, but also a need for more work to make these standards implementable in the healthcare environment. The puzzle is still missing a few pieces.

Algorithms
Several standards exist to support clinical decision support algorithms that need to make yes/no answers. More work is needed in this area to integrate those standards into a set of coherent tools that can be used together.

Arden Syntax
Arden Syntax is perhaps the oldest and most well known standard used for clinical decision support. Arden Syntax originated in 1989 at the Arden Homestead. In 1992, version 1.0 became an ASTM standard. It transitioned to HL7 and version 2.0 became an ANSI and HL7 standard in 1999. The HL7 Clinical Decision Support workgroup is responsible for maintaining the standard. The current version of Arden Syntax is 2.7, which passed HL7 Ballot in May of this year.

Arden Syntax is designed for use by clinicians with little or no formal training in programming. The benefit of this design is that it makes it easy for clinicians to verify the clinical accuracy of a particular medical logic module that is written in that language. Hundreds of medical logic modules have been created for Arden Syntax and are available from the CPMC Medical Logic Module Library.

A key problem in Arden Syntax is known in clinical decision support standards circles as the "curly brace" problem. In short, Arden does not define how an implementation of the language integrates with the healthcare application using it. Arden Syntax leaves that integration to statements that appear within pairs of curly braces { and } inside a medical logic module.

GELLO

GELLO has its ancestry in other expression languages and tools for clinical decision support, including GLIF and GLEE. GELLO is an object-oriented language designed to:

• Extract information from electronic health records,
• Compute decision critieria,
• and abstract or derive summary information.

GELLO is based on the Object Constraint Language developed originally by IBM and now part of the UML Standard. GELLO is not a proper subset of OCL, nor is it a pure extension as it explicitly leaves out some capabilities of OCL. However, developers familiar with OCL should find GELLO syntax readily accessible.
GELLO, like OCL is a declarative, rather than procedural language. The simplest way to explain a declarative language is by example. PROLOG and SQL are declarative languages. You describe the result you want to the SQL or PROLOG interpreter, and it decides the best way to obtain the result. The same is true in OCL and GELLO. Declarative programming requires a different way of thinking when expressing a decision problem. When you describe how to make a decision, most people express the decision making process procedurally.
The GELLO language is sufficiently different from OCL that it does require a grammar to be specified. HL7 had previously published a grammar for the GELLO language. However, that grammar has several defects that needed to be corrected. Some ambiguities in either the published grammar or the GELLO language specification have resulted in differing implementations of the language.
The HL7 Clinical Decision Support workgroup is presently working on a new release of the grammar intended to correct these deficiencies. In this context there are several discussions within that work group on whether GELLO should be defined as a subset of OCL, or should be defined in a way that would allow it to be mapped to OCL. One benefit of this approach might be an increase the availability of GELLO language implementation. There are several existing implementations of OCL in existence, including several supported by open source.
There is also an open source project that is developing GELLO tools (see http://www.gello.org/), however no applications or software are available for download as of today.
Like Arden Syntax, GELLO does not explicitly define how GELLO is integrated with an electronic health record. However, GELLO can easily be integrated with any HL7 RIM-based data model due to the object-oriented nature of the language. A simple data model is given as an example in Annex D of the HL7 GELLO language specification. GELLO is intended to be used with something called the vMR or Virtual Medical Record, which is described in more detail in the next section.
Instance Data
With regard to instance data, one of the problems that needs to be resolved is how to represent the information needed to support clinical decisions support applications, and how to exchange that information between applications needing to provide clinical decision support services.
Virtual Medical Record
In 2001, Johnson, Tu, Musen and Purves published a paper titled "A virtual medical record for guideline-based decision support" which can be found in the Proceedings of the AMIA Library . This often-referenced paper describes the concept of the Virtual Medical Record, or vMR that can be used to support guideline-based decision support. The concept of the virtual medical record is so often referenced in clinical decision support circles that I found it surprising that this wasn't defined by HL7 as a standard already. However, in January of this year, the HL7 Clinical Decision Support work group submitted a project to create an implementation guide for the virtual medical record, and expects to complete this work in the months ahead. This project will recommend a data model to use with the vMR, based on existing HL7 standards. One proposal for this model has already been made and recommended by several members of HL7 and co-chairs of various HL7 working groups. That recommendation is to use the HL7 Care Record and Care Record Query draft standards for trial use (A DSTU is essential a "prototype" standard, released for implementation testing).
The Patient Care Coordination Domain of Integrating the Healthcare Enterprise recently released an update to the Query for Existing Data (QED) profile, which makes use of the aforementioned standards, and a new profile know as the Care Management (CM) profile, using those same standards.
HL7 Continuity of Care Document
On of the recent things we've learned about the HL7 Continuity of Care Document or CCD is that templates can be extremely powerful. Having defined a few dozen templates in the CCD, we now find those same templates appearing in numerous other standards and implementation guides from HL7, IHE, Continua and CDA for Common Document Types projects. The benefit for clinical decision support to this proliferation of the CCD templates is that we are finding the same templates being reused over and over again to record the same kinds of information. That degree of consistency is absolutely necessary when you want to apply decision support to information that may be coming from different healthcare IT applications deployed all over the country.
The IHE Patient Care Coordination Technical framework uses the CCD templates as the basis for much of its material. Where the CCD has defined a particular template for use, IHE has either used it directly, or used and further constrained it in its technical framework. One profile that makes surprising use of CCD templates is the Query for Existing Data profile described next. The Care Management and Health Records TC in ANSI/HITSP is looking at a similar approach in the HITSP component specifications, as that committee is already responsible for four specifications that make use of the IHE PCC profiles to exchange content.
Query for Existing Data
The IHE Query for Existing Data integration profile explains how to use the HL7 Version 3.0 Care Record and Care Record Query DSTUs to query an EMR for clinical information. This profile also makes use of the Continuity of Care Document templates, but enforcing the rules of those templates on the clinical statements returned by the query transaction. The QED profile supports the ability for a clinical decision support system inside an enterprise to query for specific clinical data from that enterprises EHR system.
Care Management
The IHE Care Management (CM) integration profile uses the same standards as QED, but for a different purpose. In this integration profile, the HL7 Version 3.0 Care Record messages play an extremely important role. They allow systems that IHE describes as "Guideline Managers" to publish parts of a guideline. The part of the guideline that is published is the list of specific clinical data they downstream systems are interested in receiving. These descriptions are given in enough detail so that EHR applications can automatically determine what information updates need to be sent and when. These information updates can also be provided using existing HL7 Version 2 messages to support legacy applications.

HL7 Decision Support Service

The HL7 Service Oriented Architectures workgroup is presently working on implementations of the Decision Support Service Functional Model DSTU. One possible implementation for this service would utilize the HL7 Care Record DSTU previously mentioned several times to generate a vaccine forecast for a patient. The way this service would work would be to publish a Care Record Event which contained the necessary information to generate a vaccine forcast using the Care Record message. The response message from the DSS would be another Care Record Event that contained two pieces of information:

1. A validated list of immunizations
2. A care plan containing a proposed vaccination schedule for the patient.

This follows the general structure needed for many clinical decision support problems (e.g., drug interaction checking). The care plans produced by the service can describe different treatment alternatives, provide the reasons for the suggested treatments and the goals and risks asociated with each.
World Knowledge
Ontological or world knowledge often appears in terminology systems, such as SNOMED CT and RxNORM, which require frequent updates as new world knowledge is provided. Standards are needed to support the exchange and update this information on a routine rather than exceptional basis.
IHE ITI Sharing Value Sets
Enter the Sharing Values Sets (SVS) profile supplement published recently by IHE for public comment. This profile is intended to provide a mechanism to for applications needing value sets to obtain them repositories that maintain them. This will allow common value sets to be maintained in central locations. One use for value sets in clinical decision support is to identify specific sets of values that describe an aggregate concept that a clinical decision support system needs to act upon. An example would be the set of values that are used to identify reportable or notifiable conditions from a reference vocabulary such as SNOMED CT. In this example, a limited subset of SNOMED CT codes could be maintained as a value set to identify a set of conditions that require reports to be made to state or Federal public health officials. The benefit of this to interoperability is that these value sets can then be accessed by a large number of applications systems as needed.

Summary
There is a great deal of activity going on through various standards organizations in the area of clinical decision support. Not all of the pieces are ready today, but it is no accident than many of the pieces of the puzzle are starting to fit into place. Those of us who spend a great deal of time in healthcare standards are paying attention, and making sure that the relevant standards bodies do as well.
There is still a great deal of work that needs to be done in the area of Clinical Decision Support. Future discussions on this topic within AHIC and ONC should continue to include those of us who have been working on these standards.

Let's get coordinated!

-- Keith

P.S. In the interest of full disclosure, I've been intimately involved with many of the aforementioned standards activities in IHE and ANSI/HITSP to some degree also in HL7. I am the principle editor of the IHE Query for Existing Data and Care Management profiles, and have been involved in many of the dicussions on GELLO and the Virtual Medical Record within HL7, and co-chair the CMHR TC in ANSI/HITSP.