Assessing Decision Support Capabilities of Commercial EHRs

Introduction

In this unit we will discuss decision support capabilities of commercial electronic health records (EHRs).

Objectives

  • Compare decision support capabilities and customizability options of vendor EHRs
  • Understand the importance of clinical decision support (CDS) systems
  • Describe decision support capabilities and customization capabilities of different vendor EHRs

Nearly all-commercial EHRs have decision support capabilities and can typically be customized in various ways to meet local needs. This presentation will describe some of these capabilities.

You will learn briefly about the history of clinical decision support systems and why they are important for electronic health records.  In addition, after completing this unit, you will be able to articulate some of the decision support capabilities and customization capabilities of various vendor systems.

Clinical Decision Support (CDS)

In the realm of health information technology, the term ‘Clinical Decision Support’ may be defined as follows: “…any computer program designed to help health professionals make clinical decisions…deal with medical data about patients or with the knowledge of medicine necessary to interpret such data.”
(EH Shortliffe JAMA 1987;251:61-6)

Types of CDS Applications

  • Expert Systems
    • Primary intended as diagnostic aids

  • Alerts/Reminders
    • Interruptive or passive

We will discuss two categories of clinical decision support (CDS) applications. The first category is expert systems, many of which have been employed as a way to support clinical diagnosis. The second category is Alerts and Reminders.

Diagnostic Expert Systems

  • Generate differential diagnosis based on list of user-entered findings

Several clinical expert systems were designed to generate a differential diagnosis based on a list of findings entered by the system user. Findings might include information such as whether or not a patient has a fever, whether or not a patient has chest pain, and so on. The differential diagnosis is a short list of possible diseases a patient may have given the current findings. For example, the differential diagnosis of rhinitis (a runny nose) includes allergic rhinitis (hay fever), the abuse of nasal decongestants and, of course, the common cold.

INTERNIST-I (1974)

  • Rule-based expert system designed at the University of Pittsburgh (R. Miller, H. Pople, V. Yu)

  • Diagnosis of complex problems in general internal medicine

  • Designed to capture the expertise of just one man, Jack D. Myers, MD, chairman of internal medicine in the University of Pittsburgh School of Medicine

  • It uses patient observations to deduce a list of compatible disease states

One of the first expert systems to support clinical diagnosis was Internist-One. Internist-One was a rule-based system designed at the University of Pittsburgh. It was designed to diagnose complex problems in general internal medicine. Specifically, Internist-One was created to capture the expertise of just one man, Jack D. Myers, MD, who was a brilliant diagnostician and chairman of Internal Medicine in the University of Pittsburgh School of Medicine.

Quick Medical Reference (QMR)

  • In the mid-1980s, INTERNIST-I was succeeded by a microcomputer-based consultant developed at the University of Pittsburgh called Quick Medical Reference (QMR)

  • QMR was intended to rectify the technical and philosophical deficiencies of INTERNIST-I

  • Because QMR remained dependent on many of the same algorithms developed for INTERNIST-I, and the systems are often referred to together as INTERNIST-I/QMR

In the mid-1980s, Internist-One was succeeded by a microcomputer-based consultant, also developed at the University of Pittsburgh, called Quick Medical Reference (QMR).

QMR was intended to rectify the technical and philosophical deficiencies of Internist-One.

Because QMR remained dependent on many of the same algorithms developed for Internist-One, the systems are often referred to together as Internist-One /QMR

MYCIN (1976)

  • Developed at Stanford University as the doctoral dissertation of Edward Shortliffe

  • Written in LISP

  • Rule-based expert system designed to diagnose and recommend treatment for certain blood infections (extended to handle other infectious diseases)

  • Clinical knowledge in MYCIN is represented as a set of IF-THEN rules with certainty factors attached to diagnoses

In 1976, Edward Shortliffe developed an expert system called MYCIN as part of his doctoral dissertation in Computer Science at Stanford University. Mycin was written using the “Lisp” programming language. It was a rule-based expert system designed to diagnose and recommend treatment for certain blood infections. Later it was extended to handle other infectious diseases. Clinical knowledge in MYCIN is represented as a set of IF-THEN rules with certainty factors attached to diagnoses.

DXplain

Another early diagnostic expert system was DXplain. DXplain was developed at the Laboratory of Computer Science at the Massachusetts General Hospital. It uses a set of clinical findings (signs, symptoms, and laboratory data) to produce a ranked list of diagnosis using a Bayesian Network. The knowledge base of DXplain has over 2,200 diseases and 5,000 symptoms. One of the valuable features of DXplain was its ability to provide users with an explanation for why each disease displayed should be considered in the differential diagnosis. Moreover, Dxplain could suggest what further clinical information would be useful to collect for each disease.

Types of CDC Applications

  • Expert Systems
    • Primary intended as diagnostic aids

  • Alerts/Reminders
    • Interruptive or passive

Despite the considerable effort undertaken by developers of diagnostic expert systems, these systems have never been widely incorporated into electronic health records. One noted informatician stated that “we don’t need expert systems. We need mediocre systems to keep us from making stupid mistakes.”

In contrast to expert systems, most EHRs today do have Alerts and Reminders of various types. For the purpose of this lecture we will consider alerts to be interruptive—that is, the EHR would interrupt a clinician during the performance of a task to provide information and potentially disallow an action (for example, preventing a doctor from ordering a flu shot for a patient who just received the shot last week). We consider reminders to be non-interruptive—in other words, reminders do not impede the clinician from his or her work by displaying something on the screen that must be acknowledged. A suitable analogy might be pop-up ads on web sites vs. less-obtrusive banner advertising.

Alerts/Reminders

  • Tools for focusing attention
    • Remind the clinician of issues that might be overlooked

  • Examples
    • Clinical laboratory systems that alert clinicians of critical abnormal results
    • Computerized Provider Order Entry (CPOE) systems that alert ordering providers of possible drug interactions or incorrect drug dosages

Alerts are tools for focusing a user’s attention on information or issues that might have been overlooked. For example, a clinical laboratory system might alert clinicians of critical abnormal results, such as sending a message about a patient’s dangerously low hematocrit to a physician’s pager. Another example can be seen in Computerized Provider Order Entry, or CPOE, systems that alert providers of possible drug interactions or incorrect drug dosages when they place orders in the system.

Why Alerts/Reminders Are Needed

The need for alerts and reminders in electronic health records is demonstrated in the following quotation from Dr. David Eddy. He said, “It is simply unrealistic to think that individuals can synthesize in their heads scores of pieces of evidence, accurately estimate the outcomes of different options, and accurately judge the desirability of those outcomes for patients.”
(David M. Eddy, MD, PhD - JAMA 1990; 263:1265-1275)

Computerized Reminders-Early Efforts

Scientifically, it has been demonstrated that clinical decision support tools can be effective. One of the first experiments with computerized alerts was performed in 1976 by Dr. Clem McDonald. In an article published by the New England Journal of Medicine, he wrote: “It appears that computerized prospective reminders do reduce errors, and that many of these errors are probably due to man's limitations as a data processor rather than to correctable human deficiencies.”

Protocol-based computer reminders, the quality of care and the non-perfectability of man
(McDonald CJ. N Engl J Med; 295(24): 1351-5, Dec. 9, 1976)

Example Alert

The above image shows a sample alert from a popular commercial CPOE system marketed by Eclipsys. In this case, a physician has attempted to order a chest x-ray for a patient, but the system identified an already-existing chest x-ray order. An alert like this can reduce redundant and possibly harmful tests and procedures. The same alerting infrastructure is used to notify clinicians of potential drug-allergy, drug-food, and drug-drug interactions.

Arden Syntax

  • The Arden syntax is an artificial intelligence (AI) frame-based grammar for representing and processing medical conditions and recommendations as “Medical Logic Modules (MLMs)”

  • Intent was for MLMs to be used in shared across EHRs

  • Arden syntax is now part of HL7

  • The name, "Arden Syntax", was adopted from Arden House, the upstate New York location where early meetings held to develop and refine the syntax and its implementation

Some commercial EHR vendors have adopted a Health Level 7 standard for encoding clinical decision support logic known as the Arden Syntax. Developed in the 1990s, Arden Syntax is an artificial intelligence frame-based grammar for representing and processing medical conditions and recommendations as “Medical Logic Modules (MLMs).” The intent of its designers was for MLMs to be used and shared across EHRs in different locations and from different vendors. The name, "Arden Syntax", was adopted from Arden House, the upstate New York location where early meetings were held to develop and refine the syntax and its implementation.

Example Medical Logic Modules (MLM)

Here we see a sample MLM. This MLM is designed to display an alert when clinicians’ orders penicillin and the patient have a documented penicillin allergy.

Use of The Arden Syntax

  • The Regenstrief Institute, Inc. uses Arden Syntax MLMs in its CARE system to deliver reminders or hints to clinicians regarding patient treatment recommendations

  • LDS Hospital in Salt Lake City (HELP System) contributed much to this standard as well as the general body of knowledge

  • Eclipsys Sunrise uses Arden Syntax MLMs to provide decision support capabilities

  • Siemens and other EHR vendors also use Arden Syntax

Although Arden Syntax is a powerful tool for developing and sharing clinical decision support knowledge, it has not been broadly adopted by all EHR vendors. The Regenstrief Institute, Inc. uses Arden Syntax MLMs in its locally-developed CARE system to deliver reminders or hints to clinicians regarding patient treatment recommendations. LDS Hospital in Salt Lake City and Columbia University Medical Center also contributed much to this standard as well as the general body of knowledge in this domain. Among EHR vendors, Eclipsys uses Arden Syntax MLMs extensively to provide decision support capabilities, and Siemens and other EHR vendors also use Arden Syntax to some degree.

Epic UsersWeb-Community Library

  • Contains 15,000 clinical decision support rules known as Best Practice Alerts that are shared among Epic users

  • Content is human readable

  • The UserWeb has 12,000 active users (2008)

Epic maintains a website for its customers known as Epic UserWeb. One of the features of UserWeb is a Community Library where Epic clients can view and share human-readable clinical content such as decision support rules, order sets, documentation templates, and more. As reported in 2008, UserWeb had over 12,000 active users and 15,000 clinical decision support rules, which are known as Best Practice Alerts.

Epic UserWeb Example Screen

Above is a sample screen of Epic UserWeb. You can see the variety of content available.

Rules For Implementing CDS Alerts

This section and the next section list a set of rules for implementing clinical decision support alerts. These implementation suggestions were created by Dean Sittig and colleagues and published in the journal Pediatrics.

Communication and Acceptance

  1. Has the clinical rule or concept that will be promoted by the intervention been well communicated to the medical staff in advance?

  2. Does the intervention, if accepted, change the overall plan of care, or is it intended to cause a limited, corrective action (such as preventing an allergic reaction to a drug)?

  3. Are the data used to trigger the alert likely to be accurate and reliable, and are they a reliable indicator for the condition you are trying to change?

  4. What is the likelihood that the person receiving the alert will actually change his or her patient management as a result of the alert?

  5. Is the patient likely to agree that the recommended actions are beneficial?

Intervention Technique

  1. Is an alert the right type of intervention for the clinical objective, and is it presented at the right time?

  2. Is the intervention presented to the right person?

  3. Is the alert presented clearly, and with enough supporting information, so that the clinician feels confident in taking the recommended action immediately?

  4. Does the intervention slow down the workflow?

  5. Is the overall alert burden excessive (“alert fatigue”)? Were the study providers receiving other types of alerts at the same time?

  6. Is the clinical information system, including the use of CDS (e.g., the alerts), well-liked and supported by clinicians in general?

Finally, regarding monitoring of clinical decision support alerts in an EHR:

  1. Is there a way to monitor the response to the alert on an ongoing basis?

Integrating Alerts Into the Clinical Workflow

The rules for CDS alerts from Sittig and colleagues allude to the difficulty of integrating alerts into the clinical workflow in a way that is helpful (and minimally disruptive) to care providers. The graphic shown here demonstrates a next-generation alert intervention, which is being developed under a grant from the U.S. Agency for Healthcare Research and Quality. The goal of the alert is to notify a pediatric ambulatory care provider that his or her current patient needs a flu shot. Nearly everyone should be offered a yearly flu shot, but there are many “missed opportunities”—clinic visits where children could be immunized, but are not. The screens here collect the relevant patient-and-clinic-specific information pertaining to the influenza vaccine from a commercial EHR. This intervention is integrated into the clinician workflow, and allows the pediatrician to order the vaccine electronically in an efficient manner.

Case Study: AllScripts/Eclipsys Helios

  • EHRs historically have been difficult for customers to customize or modify due to the closed architecture employed by most vendors.

  • Helios
    • Open Architecture platform enabling custom development and/or integration of third-party modules

By mid-2010, at least two vendors, Eclipsys and Allscripts had made considerable progress toward opening their systems in a way that better enables system extensibility. Interestingly, these two vendors merged in September 2010 and the combined entity is now known as Allscripts.

Allscripts is promoting an Open Architecture platform known as Helios, which employs web services to facilitate custom development and/or integration of third-party modules into its EHR offerings.

Allscripts/Eclipsys Intergrading Billing Solution

One example of the kind of integration that Allscripts’ Helios enables is shown above. Here we see a custom-billing screen integrated into Eclipsys Sunrise Clinical Manager that exchanges information with the backend of an Allscripts Enterprise EHR deployment. The purpose of this integration was to allow physicians who wrote their notes for hospital patients electronically in Eclipsys to seamlessly submit their professional charges in their ambulatory system (Allscripts Enterprise EHR).

Intergraded Billing Solution: Technical Architecture

The above image shows the technical architecture for the Eclipsys/Allscripts integrated billing solution. In addition to billing data, patient diagnoses and information about notes is exchanged between the two vendor systems via Web Service calls.

Summary

  • All EHR vendors provide decision support capabilities and options for customization
  • Sharing content with other organizations may be desirable
  • Vendor adoption of industry standards and “open architecture” may benefit EHR users

In summary, nearly all EHR vendors provide decision support capabilities and options for customization. Because of the vast amount of knowledge engineering and clinical and informatics expertise necessary to create clinical decision support resources, sharing content with other organizations may be desirable—even if they don’t use the same EHR. In this context, vendor adoption of industry standards and “open” system architectures may greatly benefit EHR users.

Return to Previous Page

Return to Index