Transcript Towards a Virtual Medical Record for Guideline

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 casespecific 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
2a
1a
EMR
1b
Guideline
Interpreter
2b
User
Interface
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.
II.
III.
•
Medical Record Schema variation
Terminology (controlled vocabulary/codes) variation
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
Terminology 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
-queries usually generalise
-generalisation reduces mis-mapping
-and copes with system idiosyncrasies
vMR mediation
• 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
EMR
2
Terminology
mediation
EMR
1
Term
mapping kb
vMR
EMR
3
Guideline
interpreter
Schema simplification:
What entities are needed?
12
Caveat: derived from PRODIGY 3 & EON, both 10 care Chronic Disease Management
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
Planned Intervention
e.g. Poorly controlled
hypertension
e.g. Aim to get BP less than
140/85
e.g Exercise ECG on 4th June
Decision
e.g. Start 2nd line HT therapy
Goal
Medical Record extensions
•
Requirement to store coded entities which may not
traditionally be in all medical record systems
i.
ii.
iii.
iv.
•
2 camps of users (Prodigy3 workshops, 2000-2001)
i.
ii.
•
Decisions: Choices from range of guideline recommendations
Goals of treatment e.g. ‘keep BP < 140/85’
Clinical Assessments e.g.‘poorly controlled asthma’
Considered / Planned Interventions
‘over my dead body’ : medico-legal worries?
‘this is great’ : ‘timeline of management thought process’
Terminology doesn’t exist (in current systems)
Terminology simplification:
• UK 10 care standardised on NHS Clinical terms
• Unfortunately many versions, not true for drug codes
• 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
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
2
Terminology
mediation
EMR
1
RIM
EMR
3
1a
Guideline
interpreter
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