Implementing Clinical Decision Support: Strategies and Challenges

1. Implementing Clinical Decision Support: Strategies and Challenges Prakash M. Nadkarni

2. Classification of Decision Support • Tactical / Single Patient • Strategic / Sets of Patients • Single-Patient Support Logic • Simple Logic • Complex Logic

3. 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

4. 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.

5. 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

6. 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

7. 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

8. Threshold Considerations • Sensitivity vs. Specificity • Is always a Tradeoff • Example: Hyperkalemia – 5.5 Mmol/L vs. 6 MMol/L • Alert Escalation based on values

9. 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

10. Lessons from Software History: The Microsoft Office Assistant • Artificial Imbecility • Obtrusiveness • Failure to Develop a Model of the User • Incomplete Software Integration

11. The law of unintended consequences • Fear of tort liability = more alerts • Removing pointless alerts = more customization effort

12. 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

13. 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)

14. 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

15. 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

16. 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

17. 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

18. 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.

19. 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

20. 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.

21. Thank you • Questions?