Special Topics in Vendor-Specific Systems: Assessing Decision
Support Capabilities of Commercial EHRs
Audio Transcript
Slide 1: Assessing Decision Support Capabilities of Commercial Electronic
Health Records
In this unit we will discuss decision support capabilities of commercial electronic
health records (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.
Slide 2: Objective
You will learn briefly of the history of clinical decision support systems and why
they are important for electronic 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.
Slide 3: 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.”
Slide 4: Types of CDS Applications
We will discuss two categories of clinical decision support 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.
Slide 5: Diagnostic Expert Systems
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
(hayfever), the abuse of nasal decongestants and, of course, the common cold.
Slide 6: Diagnostic Expert Systems (cont.)
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.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
1
Slide 7: Diagnostic Expert Systems (cont.)
Quick Medical Reference (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
Slide 8: Diagnostic Expert Systems (cont.)
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.
Slide 9: Diagnostic Expert Systems (cont.)
Another early diagnostic expert system was DXplain (pronounced Dee-Explain).
DXplain was developed at the Laboratory of Computer Science at the
Massachusetts General Hospital. It uses a set of clinical findings (signs,
symptoms, 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.
Slide 10: Types of CDC Applications
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 up 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
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
2
something on the screen that must be acknowledged. A suitable analogy might
be pop-up ads on web sites vs. less-obtrusive banner advertising.
Slide 11: Alerts/Reminders
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.
Slide 12: 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.”
Slide 13: 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.”
To determine whether clinical errors can be reduced by prospective computer
suggestions about the management of simple clinical events, I studied the
responses of nine physicians to computer suggestions generated by 390
protocols in a controlled crossover design. Physicians responded to 51 per cent
of 327 events when given, and 22 per cent of 385 events when not given
computer suggestions.
Slide 14: Example Alert
This graphic shows an example alert from a popular commercial CPOE system
marketed by Allscripts. In this case, a physician has attempted to order a chest xray 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.
Slide 15: Arden Syntax
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
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
3
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.
Slide 16: Example Medical Logic Modules (MLM)
Here we see a sample MLM. This MLM is designed to display an alert when a
clinician orders penicillin and the patient has a documented penicillin allergy.
Slide 17: Use of The 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 locallydeveloped 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,
Allscripts uses Arden Syntax MLMs extensively to provide decision support
capabilities, and Siemens and other EHR vendors also use Arden Syntax to
some degree.
Slide 18: Epic UsersWeb-Community Library
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.
Slide 19: Epic UserWeb Example Screen
This slide shows an example screen of Epic UserWeb. You can see the variety of
content available.
Slide 20: Rules For Implementing CDS Alerts
This slide and the following slide 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.
On the topic of 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)?
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
4
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?
Slide 21: Rules For Implementing CDS Alerts (cont.)
Regarding the intervention technique:
6. Is an alert the right type of intervention for the clinical objective, and is it
presented at the right time?
7. Is the intervention presented to the right person?
8. Is the alert presented clearly, and with enough supporting information, so that
the clinician feels confident in taking the recommended action immediately?
9. Does the intervention slow down the workflow?
10. Is the overall alert burden excessive (“alert fatigue”)? Were the study
providers receiving other types of alerts at the same time?
11. Is the clinical information system, including the use of CDS (e.g., the alerts),
well-liked and supported by clinicians in general?
And finally, regarding monitoring of clinical decision support alerts in an EHR:
12. Is there a way to monitor the response to the alert on an ongoing basis?
Slide 22: Intergrading 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 nextgeneration 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.
Slide 23: 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. 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,
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
5
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.
Slide 24: Allscripts/Eclipsys Intergrading Billing Solution
One example of the kind of integration that Allscripts’ Helios enables is shown in
this slide. Here we see a custom billing screen integrated into Allscripts 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 the
inpatient EHR to seamlessly submit their professional charges in their ambulatory
system (Allscripts Enterprise EHR).
Slide 25: Intergraded Billing Solution: Technical Architecture
This slide show the technical architecture for the 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.
Slide 26: Summary
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.
This concludes the module on assessing decision support capabilities of
commercial EHRs.
Slide 27: References
No Audio.
Health IT Workforce Curriculum Special Topics in Vendor-Specific Systems
Version 3.0 / Spring 2012
Assessing Decision Support Capabilities of Commercial EHRs
This material (Comp14_Unit7) was developed by Columbia University, funded by the Department of Health and Human Services,
Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000003.
6