1 / 22

Virtual Medical Record

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

camdyn
Download Presentation

Virtual Medical Record

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. 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. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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. Assessment Intervention Plan Observation Assessment Assessment Assessment(DSS) Assessment Goal • i.e.‘…observation.code == ‘SBP’ AND observation.value > 140 AND … assessment.code == ‘Diabetes’ OR assessment.code == ‘LVF’ OR…’

  18. 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?

  19. 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

More Related