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

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?