Towards a Virtual Medical Record for Guideline-Based Decision Support

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