Towards a Virtual Medical Record for Guideline-Based Decision Support

Towards a Virtual Medical Record for Guideline-Based

Decision Support

Peter Johnson & Neill Jones

Sowerby Centre for Health Informatics in Newcastle University of Newcastle, UK

Samson Tu

Stanford Medical InformaticsStanford University School of Medicine, USA

HL7 International Affiliates Conference Reading UK, 31/8/01

Clinical Decision Support System

• Definition – Active knowledge systems which use two or

more items of patient data to generate case-specific advice (Wyatt and Spiegelhalter)

• Function broader than just decision support– Assist in information management– Assist in workflow management– Assist in quality assurance

Guideline-Based Decision SupportEvaluation, Evidence

• Effective (Grimshaw and Russell, Lancet 1993)

Improvement in process of care Improvement in outcomes

• Meta-analysis of randomized controlled trials of physician reminders: (Johnson, Langton et al. Ann Int Med 1994)

• Most effective when recommendations are…• patient-specific• delivered at point-of-care• require a response

Characteristics of Guidelines

• Expensive to create, expensive to maintain• Globally reusable (with localisation)

Raise standard of care process and outcome Remove inexplicable variations in quality and

cost of prescribing$17 billion pa Primary care drug bill … 10% NHS budget

Minute changes = large benefits

Clinical Computing in UK Primary Care

• 98% penetration• Most use for prescribing• 80% keep full clinical record• Clinical record coded (NHS Clinical terms)• Interactive use during office visits• Encounter time very short – 7 minutes

• Good platform for therapeutic/management decision support…

Motivation for close coupling to patient health record

• …which use two or more items of patient data…• …patient-specific…• …delivered at point-of-care…

• Early DSS systems required interactive data-entry• Cost-benefit ratio too high for users, so not used

– Too much time doing data entry in consultation– Disruption of patient-clinician interaction

• Maximal benefit if majority of required data can be assimilated from existing medical record.

Medical Record / DSS coupling1. Interface between medical records and guideline

systems.a. Queries on medical records data flow backb. Writing new data to medical records

2. Interface for user interaction with guideline systems

a. Guideline recommendations, information to display, b. User actions, choices

EMR Guideline Interpreter

User Interface

1a

1b

2a

2b

Medical Record – DSS examples

a. Queries on medical records data flow back

Need to satisfy logical expressions, e.g.“does patient have Hypertension AND Diabetes AND is

on one anti-hypertensive agent AND NOT on an ACE inhibitor”

Translated into a set of SQL queries for sets of coded terms

a. Writing new data to medical records“10 year Cardiovascular Event Risk = 26%”

A new data item, inferred from information in record and from user, needs to be written into medical record

Problems with record couplingI. Medical Record Schema variationII. Terminology (controlled vocabulary/codes) variationIII. Physical Quantity Units variation• So far this has meant reengineering guideline systems for each

clinical system

– To add to a new system– Need new software using that system’s patient record schema– Need revised guideline knowledge using the right terminology codes

• Too expensive, maintenance nightmare• What we need are standards to enable reuse

Current status of UK primary care medical records

• All clinical system vendors have proprietary database schema

• Although now only 3 main suppliers, at least 10 database schemata in use

• Schemata can be hugely complex• Fundamental differences, even in clinical data

• Realistically impossible to impose one standard EMR schema

Example of complexity : Relational tables in one UK clinical system (145; 3-20 fields each)

motivation for virtual Medical Record (vMR):

• To provide safe mediation between many disparate clinical systems and one decision support system

– DSS only needs a simplified view of a real medical record – and that we can standardise

Schema simplification-only distinctions important to DSS-drop administrative, audit trail data-generalise to basic EMR entities -minimum number of record types-minimum number of attributes

Terminology simplification-queries usually generalise-generalisation reduces mis-mapping -and copes with system idiosyncrasies

vMR mediation

EMR3

EMR2

EMR 1

vMR

Guidelineinterpreter

Terminologymediation

Term mapping kb

• Mimimise expense in area most resource intensive:– guideline creation, maintenance, verification– guideline interpreter software, testing

• Additional requirement (less resource)– Term and schema mapping knowledge and components

Schema simplification:What entities are needed?

Caveat: derived from PRODIGY 3 & EON, both 10 care Chronic Disease Management

12

Entities in vMR (1)

Patient Demographics

Care Provider Role, permissions

Encounter Who, where, when

Qualitative Observation e.g. Symptoms, signs

Quantitative Observation e.g. Height 1.78m, Hb

Medication Authorisation e.g. Atenolol 100mg one a day, 28 days

Procedure (done) e.g. Pancreatectomy

Entities in vMR (2)

Allergy state e.g. Sensitive to Penicillin

Clinical Assessment e.g. Poorly controlled hypertension

Goal e.g. Aim to get BP less than 140/85

Planned Intervention e.g Exercise ECG on 4th June

Decision e.g. Start 2nd line HT therapy

Medical Record extensions

• Requirement to store coded entities which may not traditionally be in all medical record systems

i. Decisions: Choices from range of guideline recommendations ii. Goals of treatment e.g. ‘keep BP < 140/85’iii. Clinical Assessments e.g.‘poorly controlled asthma’iv. Considered / Planned Interventions

• 2 camps of users (Prodigy3 workshops, 2000-2001)i. ‘over my dead body’ : medico-legal worries?ii. ‘this is great’ : ‘timeline of management thought process’

• Terminology doesn’t exist (in current systems)

Terminology simplification:

• Non drug information– v1-4 byte

– v2-5 byte

– version 3

– soon to be Snomed CT

• Drug coding – Read codes – Multilex/FDB– BNF – PPA– EMIS

• UK 10 care standardised on NHS Clinical terms• Unfortunately many versions, not true for drug codes

Terminology mediation

• Queries written in generalised terms– e.g. ‘patient on an ACE inhibitor’

• Record has specific e.g. Capoten 12.5mg tablet one bd• Need for ‘abstraction’ or generalisation services –

– many terms in EMR vocabulary satisfy query– Need for terminology mapping/category knowledge

• Integrates well with generalisation of vMR– Mapping narrow to broader terms safer than vice-versa– Safely gloss over slight differences in semantics on that system– Mapping can take in to account system idiosyncrasies

Why isn’t vMR = HL7 RIM?(Reference Information Model)

EMR3

EMR2

EMR 1

RIMGuidelineinterpreter

Terminologymediation

1a

1b

But RIM entities too low level, too generalised on their ownNot the purpose of the RIMNeed entities contextually relevant to DSS – named entities that can be used in query/expression languages etc

vMR as R-MIMs(Refined message information model)

• R-MIM builds a task-specific model on top of the RIM • Represent vMR constructs for DSS context• This (higher level) model is created using RIM acts,

participations, roles, with mood codes, type codes.• Then create HMD’s for each of the record types

(Hierarchical message definition)• Each vMR record entity becomes an HL7 message

derived from the R-MIM• Any HL7 v3 compliant system should be able to

generate vMR messages

Pharmacy super R-MIM

HL7 Clinical Guideline SIG• Undertaken to propose a vMR, May 2001

– Analysed requirements from Prodigy 3 project (UK) and from EON/Athena (Stanford, USA)

– Input from European pre-standard ENV13606 for “communicating part or whole of an electronic healthcare record” while preserving content and context

– Encouraging that all vMR entities exist in ENV13606– Useful cross validation exercise

• Electronic Health Care Records SIG– Proposed new SIG, under Clinical Decision Support TC– Aims to produce R-MIMs & HMDs to represent

communication view of health care records– Should be synergy between these two SIGs’ work.

vMR Benefits vs. Costs• Benefits:

– Most expensive parts of DSS get reused• Guideline Interpreter software component• Guideline Knowledge base

– Decoupling these from terminology/schema changes– Rapid deployment on new clinical systems

• Costs– Need to provide/maintain terminology mapping knowledge– Need to provide terminology mapping software components– System vendor has to use these to map their system into vMR

format – should be creating HL7 messages

Summary• vMR aims to be a guideline-based DSS specific

patient-data model conformant to the HL7 RIM • Reuse of guideline-based DSS in legacy clinical

systems then becomes:– how the legacy systems can export their data in standard

HL7 vMR messages

– how a guideline-based decision-support system can process patient data encoded as HL7 vMR messages.

Future work• More requirements analysis with Clinical Guideline SIG

– What extra is needed when extended to• Secondary care? Distributed workflow support? Clinical trials?

• Work with EHCR SIG on unified vMR– Develop R-MIMs etc.

– Where is the line drawn between extra vMR complexity vs. more use of composition in the controlled vocabulary?

– Syntactical and semantic mediation is a general problem of any communication between health care agents

• Use existing DSS (Prodigy?) as test platform– An exacting test of health care record communication, because

DSS are very dumb agents, intolerant of ambiguity