1. Virtual Medical Record
HL7 UK 2003
Peter Johnson

2. What is a vMR? It’s a standard INTERFACE
Safe mediation interface between HL7 compliant clinical systems and decision support systems
Purpose is DSS task-specific communication
NOT a persistent record – on the fly translation
NOT an EHR standard
Standard names for categories of things found in records (medical record classes) – e.g. “Investigation”
NOT a vocabulary – it has < 20 classes
In HL7 form a set of messages from a DMIM
Performance guarantees - QoS

3. vMR definition
define a shared model of "what structures are possible to query" in a way that abstract away from idiosyncrasies of a particular institution's or vendor's EHR
plus the messages/events to facilitate that

4. API or messages - using VMR objects/attributes/terms
DSS KB
Uses VMR terms
CDSS engine
Queries
Writes/updates
Action requests
Events
API or messages - using VMR objects/attributes/terms
Terminology
Mediation Server
VMR <> host
Clinical system adaptor
Clinical
System

5. Why do we need one? Expense of DSS; maximise reuse
No human in the loop
Impedance mismatch
One to Many systems interface issue
Performance guarantees

6. Why? – Expense of DSS
DSS Knowledge base production very resource intensive, therefore expensive
Much of the resource use is in creating logical expressions about the patient
e.g. “if diabetic or hasLVF and systolicBP > 135 or disatolicBP > 85 then…”
Need to standardise the way these are written
Write once, reuse on all systems

7. Why? – No humans Machine to machine communication here
No intelligence in AI
Can’t fudge issues expecting a human to resolve them
Everything explicit, minimise ambiguity

8. Why? - Impedance mismatch problem
DSS to Care Record System has impedance mismatch
Record structure mismatch
Complexity vs. Simplicity
Terminology mismatch
Specific vs. General

9. Why? - differing systems problem
One DSS system >> many clinical systems
Differing underlying medical record models
Differing terminology
Surely HL7 messages makes this go away?
Subtle problems remain – differing institutions use same records/terms to mean different things

10. Differing medical record models
Many different schemata in vendor medical records
Most of their distinctions not relevant to clinical DSS
Drop administrative, audit trail, security distinctions
Define a simplified schemata – a ‘view’
vMR contains a standard simplification of record data-model
Only distinctions important to clinical decision support
Minimum number of patient-data classes for this task
Minimum number of attributes for this task
Surprising success across domains and countries
UK primary care
US ambulatory care
US secondary care
Based on real experience on real systems
UK implementation on Torex; US on VA systems

11. List of relational tables in
one UK clinical system (145; 3-20 fields)

12. Highlight additions

13. Terminology problem Problem 1. Level of specificity
DSS KB mainly written in generalised/abstraction of term found in record
Coded records may be very specific, e.g. ‘prolonged ST interval on ECG’
DSS may need only more general ‘risk of heart block’ – satisfiable by presence of hundreds of coded entries.
Mapping from specific -> general
Lessens risk of changed meaning
vMR defines messages to Terminology Server for these services
Problem 2. Blurred/variable boundary between vocab and medical record structure
e.g. Blood pressure. Is it 3 distinct records with relationships, each with terms, or is it one term with parts and values
Other problems e.g. physical units mismatch etc

14. Why? -performance problem
Interactive DSS requires sub second responses
Prodigy guideline system can generate several hundred queries to bring up one set of choices between actions – need to be sub-second
Exacting and technically hard to achieve, and has to influence the approach taken
Will HL7 v3 messages work?
Even harder in WAN environment
Differences between close-coupled and loosely-coupled systems
Quality of Service guarantees required

15. vMR Aims: Unambiguous communication between DSS and EHR by:
Standard model of record classes
Standard names of record classes
Standard attribute names
Allow reusable logical expressions to be written
‘…observation.code == ‘SBP’ AND observation.value > 140 AND … assessment.code == ‘Diabetes’ OR assessment.code == ‘LVF’ OR…’
Standard set of messages/functions
Standard process achieving terminology mediation
Performance/QoS guarantees

16. Work in HL7
Most work so far on standardising the simplified record model for queries
Similarities with GP2GP EHRStatement noted
Effort at convergence with GP2GP
While the models may be very similar; vMR != GP2GP
Messages different
QoS guarantees

17. API - uses VMR objects/attributes/terms
DSS KB
Uses VMR terms
CDSS module
Queries
Writes/updates
Action requests
Events
API - uses VMR objects/attributes/terms
Terminology
Mediation KB
VMR <> host
Clinical system adaptor
Clinical
System

18. Highlight additions

19. Assessment
Intervention
Plan
Observation
Assessment(DSS)
Goal
In a hypertensive patient
on no antihypertensive medication
initiate antihypertensive treatment
at BP > 140/85
if diagnosis of diabetes
OR diagnosis of LVF
OR 10 year CHD risk > 30%.
OR CVS complications present
Aim to keep BP < 130/85.
i.e.‘…observation.code == ‘SBP’ AND observation.value > 140 AND … assessment.code == ‘Diabetes’ OR assessment.code == ‘LVF’ OR…’

21. Latest HL7 work
Reformulating same approach but based on other TC’s existing messages rather than G2GP (although this was already occurring)
Agreement to release as DSTU - draft standards for trial use rather than to ballot
But: vMR more than just the model
Terminology mediation, QoS standards
Where is the EHR framework in HL7? “rim light”
Where is the boundary between model and terminology?

22. Wider application
Problems with DSS and vMR are a microcosm of any (machine) agent to agent communication – this is just one early example
More exacting requirements than most of HL7 contributors appear used to:
Document, human centric view of records
vs. machine to machine, no human interaction
where machines may be in different cultures