1 / 21

Implementing Clinical Decision Support: Strategies and Challenges

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.

coyne
Download Presentation

Implementing Clinical Decision Support: Strategies and Challenges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related