Date post: | 23-Dec-2015 |
Category: |
Documents |
Upload: | cordelia-amelia-bruce |
View: | 217 times |
Download: | 0 times |
Implementing Clinical Decision Support: Strategies and Challenges
Prakash M. Nadkarni
Classification of Decision Support
Tactical / Single Patient
Strategic / Sets of Patients
Single-Patient Support LogicSimple 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
RemindersAccess 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 usefulHigh 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 LanguagesInspired 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 hardJust 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 workGenerate 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 ChallengesHL7 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?