Clinical Decision Support: Crossing The Chasm

Clinical Decision Support (CDS) is certainly a "meaningful use" of electronic health records (EHRs). Despite its potential to improve the quality of care, CDS is not widely used in health care delivery today. In tech marketing parlance, CDS has not crossed the chasm. There are several issues that need to be addressed including: physicians buy-in into the concept of automated execution of evidence-based clinical guidelines, seamless integration into clinical workflows, usability, standardization, and CDS software architecture and design.

When I first started to explore CDS systems, I was quite overwhelmed by the number of different competing formalisms, standards, and academic projects in the field. To move us past the current gridlock in CDS adoption, I propose an agile approach to the development of CDS software with an emphasis on:

• Working CDS software that delivers results for providers and their patients
  
• Close daily collaboration between clinicians and software developers during the development process
  
• The use of agile techniques such as automated acceptance testing to facilitate the involvement of clinicians in CDS software quality assurance.
  

Working CDS Software

Different formalisms, methodologies, and architectures have been proposed for representing the medical knowledge in clinical guidelines for their automated execution. Examples include, but are not limited to the following:

• The Arden Syntax
  
• GLIF (Guideline Interchange Format)
  
• GELLO (Guideline Expression Language Object-Oriented)
  
• GEM (Guidelines Element Model)
  
• PROforma
  
• EON
  
• PRODIGY
  
• Asbru
  
• GUIDE
  
• SAGE
  
• SEBASTIAN
  
• The HL7 Decision Support Service (DSS) Functional Model Specification.
  

Many academic papers have been written to explain and compare these different approaches. Each of these projects represents an important contribution to the CDS field and will inform the design of future CDS software. However, it is quite easy to fall into analysis paralysis when reviewing and debating which formalism or standard is better. At the end of the day, what really matters to the pragmatic developer is tested and working CDS software that delivers results for clinicians and their patients.

Using business rule engines is not the only way to develop CDS software. However, I believe that because they are written in languages and frameworks that are accessible to mainstream software developers, business rule engines can accelerate the development, deployment, and availability of CDS software. Furthermore, many viable open source business rule engines are available today and can be leveraged.


Getting CDS Done with a Business Rule Engine

ARRA interim certification criteria for electronic health record (EHR) technology include the following CDS-related requirements:

1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to speciality or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list.
   
2. Automatically and electronically generate and indicate (e.g., pop-up message or sound) in real time, alerts and care suggestions based upon clinical decision support rules and evidence grade.
   
3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.
   

These requirements can be satisfied with simple conditional statements in any programming language. However, it is recognized that clinical decision support rules (like other complex types of business rules) are better implemented with a business rule engine. This allows the developer to externalize the medical knowledge in the clinical guideline in the form of declarative rules as opposed to embedding that knowledge in procedural code. This approach has many benefits notably resilience to change, ease of maintenance, and enabling collaboration with business users (in this case clinicians).


Collaboration between Clinicians and Software Developers

One of the most challenging aspects of CDS has been the translation of the medical knowledge in clinical guidelines into executable code. There are not that many people who are expert in the both the medical and software development fields. The Agile prescription to this problem is close and daily collaboration between clinicians and software developers.

Business Rules engines like JBoss Drools provide features such as Excel-based decision tables or the ability to write rules in a DSL (domain specific language) to allow clinicians to actively participate in the development and maintenance of decision support rules.

Automated Acceptance Testing

The quality of CDS software is of paramount importance for care safety reasons. The Agile prescription here is test-driven development (TDD), particularly the automated integration and acceptance testing of the proper execution of clinical decision support rules. "FIT for Rules" is an example of an automated acceptance framework for rule engines like ILog and Drools. Such frameworks allow both the developer and the clinician to participate in the acceptance testing process.


Service-Oriented CDS

The complexity and cost of developing CDS software strongly argue in favor of a service-oriented approach whereby CDS software capabilities are exposed as a set of services that can be consumed by other client health IT systems such as EHR and Computerized Physician Order Entry (CPOE) systems. To reduce costs, these CDS software services can be shared by several health care providers.

In this regard, the HL7 Decision Support Service (DSS) Functional Model Specification represents one of the most important specifications for CDS implementers today.

Interchange Standard

The complexity and cost inherent in capturing the medical knowledge in clinical guidelines and translating that knowledge into executable code remains an impediment to the widespread adoption of CDS software. Therefore, there is still a need for a standard for the sharing and interchange of executable clinical guidelines. Several formalisms and standards have been proposed such as the Arden Syntax, GLIF, GELLO, and GEM. However, none of these standards has been widely adopted. Although there is a lot that can be learned from these standards, I believe that they are not widely used because they are complex and specific to the healthcare domain, and therefore not accessible to mainstream developers. There is also a lack of open source and even commercial implementations of some of these standards.

If business rule engines are the pragmatic path to CDS adoption, then I would argue that the Rule Interchange Format (RIF) specification might be a solution to the interchange problem. The RIF Production Rule Dialect (PRD) is designed as a common XML serialization for multiple rule languages to enable rule interchange between different business rule management systems (BRMS). RIF is currently a W3C candidate recommendation and is backed by several BRMS vendors.

UPDATE: The following is the Final Meaningful Use criteria for Clinical Decision Support (CDS):

1. Implement rules. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) based on the data elements included in: problem list; medication list; demographics; and laboratory test results.
   
   
2. Notifications. Automatically and electronically generate and indicate in real-time, notifications and care suggestions based upon clinical decision support rules.
   

And here are the draft stage 2 requirements:

Use CDS to improve performance on high- priority health conditions.

Establish CDS attributes for purposes of certification:

1. Authenticated (source cited);
   
2. Credible, evidence-based;
   
3. Patient-context sensitive;
   
4. Invokes relevant knowledge;
   
5. Timely;
   
6. Efficient workflow;
   
7. Integrated with EHR;
   
8. Presented to the appropriate party who can take action