Implementing Clinical Decision
Support: Strategies and Challenges
Prakash M. Nadkarni
Classification of Decision
Support
Tactical / Single Patient
Strategic / Sets of Patients
Single-Patient Support Logic
Simple Logic
Complex Logic
Simple Logic
Single-step interaction with a user in a
specific circumstance – e.g., ordering
specific medications
Alerting – e.g., drug-drug interactions
Reminders
Access to necessary information
Complex Decision Support
(Workflow)
Several steps, with branching logic, possible
parallel execution
The steps may be separated over time
Duration of several months or longer
Steps may involve multiple individuals.
The state of the patient must be preserved
between steps.
The current state of system must be
auditable.
Simple Alerts
Must be useful
High Signal to Noise Ratio
Must not insult the user’s intelligence
Must facilitate workflow where
possible
if the system knows what the problem is,
it must try to facilitate the solution.
Example: vaccination scheduling
Accuracy
Requires integration with the EMR
Requires specific information to be
available (old patient)
Preferably structured data – free text
is hard to process in real time
Alert level depends on what patient is
being treated for
Postural Hypotension – ICU vs.
ambulatory patient
Individual patient variation can
influence accuracy
Example: beta-blocker + calcium
antagonist combination predisposing
to CCF.
Dose dependency
Patient variation – first-pass effects
Pre-existing conditions – low Ejection
Fraction, symptoms suggesting failure
Threshold Considerations
Sensitivity vs. Specificity
Is always a Tradeoff
Example: Hyperkalemia – 5.5 Mmol/L
vs. 6 MMol/L
Alert Escalation based on values
A model of the user
Role-based alerts
Customization of alert volume to user
preferences (not currently available)
Learning from User Actions (ditto)
Done very well by game-playing
software
Lessons from Software History:
The Microsoft Office Assistant
Artificial Imbecility
Obtrusiveness
Failure to Develop a Model of the
User
Incomplete Software Integration
The law of unintended
consequences
Fear of tort liability = more alerts
Removing pointless alerts = more
customization effort
Rule Engines
If condition then (do something)
One rule can activate other rules, and
so on, until a goal is reached, or no
more rules can be activated
Arden Syntax: Motivation and
Design
A programming language for Doctors
Inspired by rules: “medical logic
modules”
Relies on an “event monitor” within
the EMR to activate an MLM
Supposedly system-independent
(system specific logic – e.g., data
access – isolated within curly braces)
Arden Syntax: Limitations
Programming is not an amateur activity –
COBOL, SQL
The logic in the curly braces is more
elaborate than that in the MLM proper.
Event monitors take a lot of work
The Event-driven paradigm is a forced-fit for
batch scenarios
The language lacks essential capabilities
Misfit for most drug-related alerts
Service-Oriented Architectures
Service is a subroutine called over a
network
Web service uses WWW infrastructure
Simple in theory, hard to pull off in
practice
Finding the right task granularity
Identifying reusable functionality
Recycling of existing software is not
easy: assumptions may change
Governance and Internal standards
Guideline Languages
Inspired by workflow languages
Business Process Execution Language / Markup
Notation
Based on XML syntax
Unfortunately, the technology(as of 2010) is
still bleeding-edge
the “standards” are too weak and lobotomized.
XML is not the world’s friendliest
programming language (best used internally)
Graphical Language preferable – but infuriating
for knowledgeable programmers
Guideline Languages - 2
Implementation is hard
Just because you have a syntax that
defines operations doesn’t mean
anything unless you have the language
hooked up to an EMR
Must interface to traditionally developed
program code
Table-driven approaches
Adverse drug-drug interactions,
allergy detection, lab/drug interactions
How they work
Generate all possible drug pairs / table
lookup
Rely on database content: scale well
Essentially each row of data is an
implicit rule.
Fit well with existing software.
The Proteus Guideline Engine
Developed by Hemant Shah and colleagues
at HFHS
A high-level flowcharting style approach
Individual modules can be highly
sophisticated, treated as black boxes
Code/algorithm reuse possible
The task granularity can be left to the
developer
Trivial tasks need not be programmed
graphically
Portability Challenges
HL7 Virtual Medical Record is intended to
address differences in EMR designs
The current standard is under-specified: certain
areas (e.g., administrative schemas) are not
considered.
The supporting controlled vocabularies do not
adequately model enumerations and ordinal
values (e.g., symptom severity/grades).
Programming API issues have not been
considered, only virtual schema.
Thank you
Questions?