Virtual Medical Record HL7 UK 2003 Peter Johnson

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

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

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

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

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

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

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

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

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

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

Highlight additions

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

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

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

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

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

Highlight additions

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…’

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?

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