1 / 42

What if We Really Had a Silver Bullet to Deal with Health Information ?

What if We Really Had a Silver Bullet to Deal with Health Information ?. 1 Dec 2011, COMPASS Seminar Koray Atalag, MD, PhD, FACHI. What’s the Problem with Health Information?. We capture heaps of data - sit in silos  Partly structured and coded eg ICD10, ICD-O, READ, LOINC etc.

dusty
Download Presentation

What if We Really Had a Silver Bullet to Deal with Health Information ?

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. What if We Really Had a Silver Bullet to Deal with Health Information? 1 Dec 2011, COMPASS Seminar Koray Atalag, MD, PhD, FACHI

  2. What’s the Problem with Health Information? • We capture heaps of data - sit in silos  • Partly structured and coded • eg ICD10, ICD-O, READ, LOINC etc. • Coding is not easy / expensive • Depends on context, purpose, or just coder’s mood! • Automated coding is not reliable • Difficult to code from free text after capturing • Usually context is lost • Best at the time and place of data capture • Still wealth of valuable information in free text • We cannot link, aggregate and reuse!

  3. What are the Implications? • Apart from: • Safety, quality, effectiveness and equity in healthcare • New knowledge discovery and advances in Science • Cost of not sharing health information: • In US could sum up to a net value of $77.8 billion/yr(Walker J. The Value Of Health Care Information Exchange And Interoperability. Health Affairs 2005 Jan) • In Australia well over AUD 2 billion(Sprivulis, P., Walker, J., Johnston, D. et al., "The Economic Benefits of Health Information Exchange Interoperability for Australia," Australian Health Review, Nov. 2007 31(4):531–39.)

  4. If the Banks Can Do It, Why Can’t Health? • Clinical data is wicked: • Breadth, depth and complexity • >600,000 concepts, 1.2m relationships in SNOMED • Variability of practice • Diversity in concepts and language • Conflicting evidence • Long term coverage • Links to others (e.g. family) • Peculiarities in privacy and security • Medico-legal issues • It IS critical…

  5. Wickedness: Medication timing Acknowledgement: Sam Heard

  6. Wickedness: Medication timing Acknowledgement: Sam Heard

  7. Wickedness: Medication timing Acknowledgement: Sam Heard

  8. Wickedness: Medication timing Acknowledgement: Sam Heard

  9. Wickedness: Medication timing Acknowledgement: Sam Heard

  10. How Do We Model Now?Complex techy stuff

  11. A New Approach: • Open source specifications for representing health information and person-centric records • Based on 20+ years of international experience including Good European Health Record Project • Superset of ISO/CEN 13606 EHR standard • Not-for-profit organisation - established in 2001 www.openEHR.org • Separation of clinical and technical worlds* • Big international community and research

  12. Clinicians in the Driver’s Seat!

  13. Key Innovation “Multi-level Modelling” separation of health information representation into layers 1) Reference Model: Technical building blocks (generic) 2) Content Model: Archetypes (domain-specific) 3) Terminology: ICD, CDISC/CDASH, SNOMED etc. • Data exchange and software development based on first layer • Archetypes provide ‘semantics’ + behaviour and GUI • Terminology provides linkage to knowledge sources (e.g. Publications, knowledge bases, ontologies)

  14. Multi-Level Modelling in openEHR

  15. Date and Time Handling in openEHR

  16. Archetypes: Models of Health Information • Puts together RM building blocks to define clinically meaningful information (e.g. Blood pressure) • Configures RM blocks • Structural constraints (List, table, tree) • What labels can be used • What data types can be used • What values are allowed for these data types • How many times a data item can exist? • Whether a particular data item is mandatory • Whether a selection is involved from a number of items/values • They are maximal datasets–contain every possible item • Modelled by domain experts using visual tools

  17. Content Example:Blood Pressure Measurement

  18. Blood Pressure MeasurementMeta-Data

  19. Blood Pressure MeasurementData

  20. Blood Pressure MeasurementPatient State

  21. Blood Pressure MeasurementProtocol

  22. Open Source Archetype Editor

  23. Content Modelling in Action Back in 2009 – GP view of BPWHAT HAVE WE MISSED? Acknowledgement: Heather Leslie & Ian McNicoll

  24. Blood pressure: CKM review Acknowledgement: Heather Leslie & Ian McNicoll

  25. Blood pressure: CKM review Acknowledgement: Heather Leslie & Ian McNicoll

  26. Blood Pressure v2 …additional input from other clinical settings Acknowledgement: Heather Leslie & Ian McNicoll

  27. Blood Pressure v3 …and researchers Acknowledgement: Heather Leslie & Ian McNicoll

  28. CKM: Versioning Acknowledgement: Heather Leslie & Ian McNicoll

  29. CKM: Discussions

  30. Blood Pressure: Translation Acknowledgement: Heather Leslie & Ian McNicoll

  31. How Do They All Fit Together? • Common RM blocks ensure data compatibility • No need for type conversions, enumerations, coding etc. • Common Archetypes ensure semantic consistency • when a data exchange contains blood pressure measurement data or lab result etc. it is guaranteed to mean the same thing. • Additional consistency through terminology linkage • Common health information patterns and organisation provide a ‘canonical’ representation • All similar bits of information go into right buckets • Easy & accurate querying + aggregation for secondary use • Addresses provenance and medico-legal issues

  32. EHR Folders Compositions Sections Entries Clusters Elements Data values A Simple Health InformationOrganisation

  33. Patterns in Health Information Observations Clinician measurable or observable Published evidence base Subject Actions Personal knowledge Administrative Entry Recording data for each activity Evaluation clinically interpreted findings Investigator’s agents (e.g. Nurses, technicians, other physicians or automated devices) Instructions order or initiation of a workflow process

  34. Specialisation of Archetypes • Data conforms %100 to parent archetype • International -> national -> regional -> local • Generalist -> specialist -> subspecialist Problem Diagnosis • Text or Term • Clinical description • Date of onset • Date of resolution • Side • No of occurrences Diabetesdiagnosis • Term • + • Grading • Diagnostic criteria • Stage • Term • + • Diagnostic criteria • Fasting > 6.1 • GTT 2hr > 11.1 • Random > 11.1

  35. Providing a Canonical Representation Shared Archetypes etc. etc. etc. Medications Clinical Encounter Vital Signs Diagnoses Diagnostic Tests Family History Life Style Demographics Physical Exam Genetics Interventions Past History NZ Address Ethicity1,2. Whanau GP visit Flu-like PHO enrolm. BP 130/90 HR 90 T: 38.5 C Dx 1 Dx 2 etc. Rx A Dispense Administer Routine Blood Urine X-Ray Subject A Rx N/A N/A Routine N/A N/A Diabetes Dx -Type -Severity -Course etc. USAddress State Next of kin Hospital adm. Diabetes Priv insurance Specific blood test Urine culture Genomic assay Retinography Fluid Tx Insulineinj Infection Tx Psychologic BP 120/70 (24 hour avg) HR 70 T: 37 C Rx B Dispense Administer Detailed Foot and eyes DNA Seq. Assays Low sugar Exercise Pedigree Chronic Subject B Each finding usually depends on other – clinical context matters! Person-Centric Record Organisation

  36. Can Clinicians Agree on Single Definitions of Concepts? • “What is a heart attack?” • 5 clinicians: ~2-3 answers – probably more! • “What is an issue vs. problem vs. diagnosis?” • No consensus for conceptual definition for years! BUT • There is generally agreement on the structure and attributes of information to be captured • Problem/Diagnosis name • Status • Date of initial onset • Age at initial onset • Severity • Clinical description • Date clinically recognised • Anatomical location • Aetiology • Occurrences • Exacerbations • Related problems • Date of Resolution • Age at resolution • Diagnostic criteria Acknowledgement: Sam Heard

  37. Achievable? • ̴ 10-20 archetypes  core clinical information to ‘save a life’ • ̴ 100 archetypes  primary care • ̴ 2000 archetypes  secondary care • [compared to >600,000 concepts in SNOMED]

  38. Achievable? – cont. • Initial core clinical content is common to all disciplines and will be re-used by other specialist colleges and groups • Online archetype consensus in CKM • Achieved in weeks/archetype • Minimises need for F2F meetings • Multiple archetype reviews run in parallel • Leverage existing and ongoing international work Acknowledgement: Sam Heard

  39. NZ Interoperability Architectureis underpinned by openEHR

  40. Thanks...Questions? Visit: www.openehr.org Not a silver bullet, but definitely a good shot! k.atalag@auckland.ac.nz

More Related