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 Informatics Stanford 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 Support Evaluation, 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 coupling 1.Interface between medical records and guideline systems. a.Queries on medical records  data flow back b.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 coupling I.Medical Record Schema variation II.Terminology (controlled vocabulary/codes) variation III.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 EMR 3 EMR 2 EMR 1 vMR Guideline interpreter Terminology mediation 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 1 0 care Chronic Disease Management 12

Entities in vMR (1) PatientDemographics Care ProviderRole, permissions EncounterWho, where, when Qualitative Observatione.g. Symptoms, signs Quantitative Observatione.g. Height 1.78m, Hb Medication Authorisatione.g. Atenolol 100mg one a day, 28 days Procedure (done)e.g. Pancreatectomy

Entities in vMR (2) Allergy statee.g. Sensitive to Penicillin Clinical Assessmente.g. Poorly controlled hypertension Goale.g. Aim to get BP less than 140/85 Planned Interventione.g Exercise ECG on 4 th June Decisione.g. Start 2 nd 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, ) 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 1 0 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) EMR 3 EMR 2 EMR 1 RIM Guideline interpreter Terminology mediation 1a 1b But RIM entities too low level, too generalised on their own Not the purpose of the RIM Need 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