Reusable Knowledge for Best Clinical Practices:

Why We Have Difficulty Sharing – And What We Can Do about It

Panel Presenters:

Robert A. Greenes, MD, PhD Mor Peleg, PhDArizona State Univ & Mayo Clinic, USA Univ of Haifa, Israel

Alan Rector, MD, PhD Jerome A. Osheroff, MDUniv of Manchester, UK TMIT Consulting & Univ. of Penn, USA

Organization of the Panel

• Short presentations by each of us (50-55 min)– To lay out key issues– To describe a particular position or perspective

• Audience participation (35-40 min)– Questions to individual presenters– Responses to provocative position statements

by presenters– Open discussion

The Problem of CDS Knowledge Sharing

An Approach and a Proposal

Robert A. Greenes, MD, PhD ASU / Mayo Clinic

greenes@asu.edu

The current state

• Rationale and need for sharing CDS best practices growing– Knowledge growth, time pressures, patient

demand, quality measurement & reporting, value tied to reimbursement,

– …• Yet 4 main obstacles

– No agreed format– Limited content– Lack of an “implementation science”– Limited tools

Status of sharing efforts

• Collections– Cochrane, EPC Centers, guidelines.gov, NICE– Not computable

• Standards– Arden Syntax, GELLO, Infobuttons, VMR, DSS service model– Limited convergence

• Commercial offerings– Order sets, drug interaction tables, infobuttons– Limited rules sharing

• Multi-stakeholder collaborations– CDS Consortium, Morningside Initiative/SHARPc Project 2B, HL7

CDS Working Group, Structured Care Recommednations, ONC Health eDecisions Initiative

– Beginning to lead to models but no true content sharing– No sustainability so far

Primary Gaps

• Limited availability of rules knowledge– Usually just within vendor/user group– Or only at the generic level– Not very sharable at implementation level

• Proprietary or incompatible KRs and data models• Workflow adaptations limit reusability

– Knowledge management and update difficult– Particular difficulty in smaller practices and

hospitals without IT staff

Example of difficulty in sharing

• Simple medical rules, e.g., – If Diabetic, then check HbA1c every 6 months– If HbA1c > 6.5% then Notify

• Multiple translations– Based on how triggered, how/when interact,

what thresholds set, how notify– Actual form incorporates site-specific

thresholds, modes of interaction, and workflow• e.g., Mayo Clinic has some 10-15 variations of these

rules!

Setting-specific factors (SSFs)

• Triggering/identification modes– On chart open, on lab test result , on provider login, …– Registry, periodic panel search, patient list for day, …

• Inclusions, exclusions• Interaction modes, users, settings• Timing considerations

– Advance, late, due now, …• Data availability/ sources/ entry requirements• Thresholds, constraints• Actions/notifications

– Message, pop-up, to do list, order, schedule, notation in chart, requirement for acknowledgment, escalation, alternate. …

• Exceptions– Refusal, lost to follow up, …

Workflow adaptation – the missing link

• Estimated that adaptation can take 50-90% of effort

• Adapted artifacts not very sharable• But principles of how done (SSF types) might

be more so– e.g., how a screening reminder is triggered, who sees patient

first, who should be recipient, how timing done– Can create KR with meta-tags for domain, type of rule, SSF

selections– Can model a new rule on a paradigm (set of choices) similar

to one that was successful (sort of QBE)• Hypothesis: repositories are more

sharable/reusable at this abstracted level of workflow adaptation– More transparent to SMEs, users– Could lead to development of an experience base and

implementation science

“Implementation science”

• Workflow adaptation support• KM support

– Versioning, update, lifecycle of refinements and adaptations

• Interoperability of data and information models

• Integration into EHR environments– Service model– Incorporation directly into internal knowledge

repositories

Life Cycle of Rule Refinement

Start with EBM statement

Stage

1. Identify key elements and logic – who, when, what to be done

– Structured headers, unstructured content

– Medically specific

2. Formalize definitions and logic conditions

– Structured headers, structured content (terms, code sets, etc.)

– Medically specific

3. Specify adaptations for execution

– Ontology of SSFs

– Selected SSFs for particular sites

– Authoring to support incremental adaptation

4. Convert to target representation, platform, for particular

implementation

– Host language (Drools, Java, Arden Syntax, …)

– Host architecture: rules engine, SOA, other

– Ready for execution

Implem

entation

science focus

The Health eDecisions (HeD) Initiative

• Part of the US ONC’s Standards and Interoperability Framework– http://wiki.siframework.org/Health+eDecisions+

Homepage

• Two main use cases:1.CDS Artifact Sharing

• Computable representations for rules, order sets, and documentation templates

2.CDS Guidance Service• Service model for delivery of CDS

Our goals for HeD use case 1

• Create (with working group) a model-driven CDS authoring tool– Based on the HeD standard– Having a unified model supporting different views– Supporting different levels of abstraction/granularity

• Views for SME vs. KE

– Adopted as HL7 standard

• Provide compatibility with existing standards– Reference state-of-the-art data models and terminology

systems– Convertible to existing CDS languages and data models

• Provide open-source authoring/editing tool– Aimed at stage 2 artifact interchange

HeD Semantic Model

• Companion to the HeD schema– Abstracts the content delivered by the syntax

– HeD schema available at https://code.google.com/p/health-e-decisions/

• Defined using a modular OWL ontology for events, conditions, actions, data elements– Standards-based

– Set in the context of well-known upper ontologies

– Mirrors the HeD schema modules

Goals – Beyond HeD• Explore use for enterprise KM

– Built on Morningside Initiative and SHARPc 2b work on SSFs

– To provide palettes of SSFs & primitive clause types• to facilitate event selection, logic customization, and action

specification for rules– To provide meta-level tagging

• to enable artifacts to be linked to knowledge sources, versions, and adaptation types

– To support authoring and editing by SMEs– To provide (semi-) automated translation into host

executable form– To facilitate construction of other artifacts such as order

sets and documentation templates• To provide support for smaller practices and

hospitals– Feasible if community including vendors support the

above

A proposed approach1. Community endorse a comprehensive model-

based framework2. National and specialty organizations agree to

require distribution in this format– e.g., proposed US Meaningful Use Stage 3 to require import of

knowledge in HeD format3. Increased focus on implementation enablers

– This area has been neglected– Need to make a science out of it

4. Form open collaborative project for tools development– Knowledge authoring/editing– Knowledge management– Workflow adaptation – Better support of SME– Tying KR to evaluation & tracking metrics

– …

Challenge statements• Subject matter experts must engage more

directly in knowledge authoring and adaptation• New approaches needed to knowledge modeling

– Top-down comprehensive development does not work - alternatives required

– Representation must be factored– No fixed terminology will ever fit needs of all decision support

statements• Knowledge sharing standards will not have broad

impact unless:– they have full engagement of a critical mass of key

stakeholders (e.g., implementers, EHR vendors)– they are driven by the realities/needs faced by those working

to transform care delivery• Sharing effective CDS strategies must accompany

sharing of CDS content in order to broadly improve outcomes– but who and how to organize, support, and sustain?