1 / 26

Towards a Virtual Medical Record for Guideline-Based Decision Support

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.

Download Presentation

Towards a Virtual Medical Record for Guideline-Based Decision Support

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. 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 InformaticsStanford University School of Medicine, USA HL7 International Affiliates Conference Reading UK, 31/8/01

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

  3. Guideline-Based Decision SupportEvaluation, 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

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

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

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

  7. Medical Record / DSS coupling • Interface between medical records and guideline systems. • Queries on medical records  data flow back • Writing new data to medical records • Interface for user interaction with guideline systems • Guideline recommendations, information to display, • User actions, choices 2a 1a EMR User Interface Guideline Interpreter 1b 2b

  8. Medical Record – DSS examples • 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 • 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

  9. Problems with record coupling • 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

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

  11. Example of complexity : Relational tables in one UK clinical system (145; 3-20 fields each)

  12. 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 Terminology simplification -queries usually generalise -generalisation reduces mis-mapping -and copes with system idiosyncrasies 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

  13. Term mapping kb 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 1 Terminology mediation vMR EMR 2 Guideline interpreter EMR 3

  14. Schema simplification:What entities are needed? 12 Caveat: derived from PRODIGY 3 & EON, both 10 care Chronic Disease Management

  15. Entities in vMR (1)

  16. Entities in vMR (2)

  17. Medical Record extensions • Requirement to store coded entities which may not traditionally be in all medical record systems • 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 • 2 camps of users (Prodigy3 workshops, 2000-2001) • ‘over my dead body’ : medico-legal worries? • ‘this is great’ : ‘timeline of management thought process’ • Terminology doesn’t exist (in current systems)

  18. 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 simplification: • UK 10 care standardised on NHS Clinical terms • Unfortunately many versions, not true for drug codes

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

  20. Why isn’t vMR = HL7 RIM?(Reference Information Model) EMR 1 RIM Terminology mediation EMR 2 1a Guideline interpreter EMR 3 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

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

  22. Pharmacy super R-MIM

  23. 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”whilepreserving 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.

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

  25. Summary • vMR aims to be a guideline-based DSS specific patient-data model conformant to the HL7 RIM • Reuse of guideline-based DSS in legacyclinicalsystemsthen 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.

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

More Related