Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Clinician-led eHealth records


Published on

A knowledge enabled approach to sharing health information

Published in: Technology
  • Be the first to comment

Clinician-led eHealth records

  1. 1. Clinician-led eHealth records<br />A knowledge-enabled approach to the sharing of health information <br />Dr Heather Leslie<br />
  2. 2. An ongoing issue<br />“ In attempting to arrive at the truth, I have applied everywhere for information but in scarcely an instance have I been able to obtain hospital records fit for any purpose of comparison.”<br />“If they could be obtained, they would enable us to decide many other questions besides the one alluded to. They would show subscribers how their money was being spent, what amount of good was really being done with it or whether the money was not doing mischief rather than good.” <br />Florence Nightingale, 1863<br />
  3. 3. Why is sharing health information so difficult?<br /><ul><li>Complex & dynamic clinical domain
  4. 4. Lifelong records
  5. 5. Requirements for clinical diversity
  6. 6. Privacy & Security
  7. 7. Increasing health costs
  8. 8. Safety & Prevention
  9. 9. Mobile population
  10. 10. Mobile providers
  11. 11. ...</li></ul>“If the banks can do it, why can’t health?”<br />CLINICAL DATA is key<br />
  12. 12. Health Knowledge Complexity<br />Both the total number of concepts and the rate of change is high <br />SNOMED medical terminology >400,000 atomic concepts and over 1 million relationships<br />Not only is health care big, it is open-ended:<br />In breadth, because new information is always being discovered or becoming relevant<br />In depth, because finer-grained detail is always being discovered or becoming relevant<br />In complexity, because new relationships are always being discovered or becoming relevant<br />
  13. 13. Complexity: Medication timing<br />
  14. 14. Complexity: Medication timing<br />
  15. 15. Complexity: Medication timing<br />
  16. 16. Complexity: Medication timing<br />
  17. 17. Complexity: Medication timing<br />
  18. 18. Clinical diversity<br /><ul><li>Variety of data represented
  19. 19. Free-text vs Structured
  20. 20. Normal statements
  21. 21. “Nil significant”, “NAD”
  22. 22. Graphical
  23. 23. Fractal nature of medicine
  24. 24. Different clinicians:
  25. 25. Prefer different approaches
  26. 26. Need different levels of detail
  27. 27. Need to record/exchange information on a per patient basis
  28. 28. MYTH: “One size fits all”
  29. 29. Image – eg homunculus
  30. 30. Multimedia
  31. 31. eg video, ECG wave format
  32. 32. Questionnaires, checklists etc</li></li></ul><li>Dynamic knowledge & traditional software<br />CLINICAL<br />(dynamic)<br />TECHNICAL<br />
  33. 33. Lifelong health records?<br />© Ocean Informatics 2008<br />
  34. 34. EHR ‘bubbles’  message ‘patches’<br />
  35. 35. EHR ‘bubbles’  message ‘patches’<br />INCREMENTAL EVOLUTION<br /> How far can we push it? <br />
  36. 36. ‘Tail wagging the dog’?<br />
  37. 37. Ideal solution...<br />Data independentof technology & applications<br />“Universal health record” – data driven EHR<br />Lifelong health information<br />Caters for clinical diversity<br />Caters for dynamic knowledge <br />Supports data liquidity/exchange<br />Enables re-use of health information<br />Multilingual solution<br />Terminology agnostic<br />
  38. 38. Knowledge-driven EHRs<br />ORTHOGONAL APPROACH<br /> Longer-term viewpoint<br />Standardised clinical content definitions<br />
  39. 39. Knowledge-driven EHRs<br />Standardised clinical content definitions<br />Computable, standardised clinical data definitions/models<br />Reference Model<br />
  40. 40. Knowledge-driven EHRs<br />Code Skeletons<br />UI Forms<br />Decision-Support<br />Data Sets<br />Standardised clinical content definitions<br />Computable, standardised clinical data definitions/models<br />Reference Model<br />XML Schemas<br />Messages<br />Semantic Queries<br />Terminology Mappings/ Subsets<br />HTML Display<br />
  41. 41. Knowledge-based clinical models <br />Are ‘agents for change’<br />Require a change of mindset<br />Require upfront planning & coordination<br />Not more time<br />REQUIRE CLINICIAN LEADERSHIP & ENGAGEMENT<br />Ensure quality of clinical data<br />Warrant data is safe & ‘fit for purpose’<br />Fulfils quality remit for professional clinical colleges<br />
  42. 42. Semantic interoperability<br />Walker et al, 2005<br />Level 1: Non-electronic data. Examples include paper, mail, and phone call.<br />Level 2: Machine transportable data. Examples include fax, email, and unindexed documents.<br />Level 3: Machine organisable dataie structured messages, unstructured content Examples include indexed (labeled) documents, images, and objects.<br />Level 4:Machine interpretable data (structured messages, standardised content)Examples include the automated transfer from an external lab of coded results into a provider’s EHR. Data can be transmitted (or accessed without transmission) by health IT systems without need for further semantic interpretation or translation.<br />Walker et al, 2005<br />
  43. 43. openEHR artefact ecosystem<br />Code Skeletons<br />UI Forms<br />Decision-Support<br />openEHR Clinical content models<br />Data Sets<br />Archetypes<br />Templates<br />Reference Model<br />XML Schemas<br />Messages<br />Semantic Queries<br />Terminology Mappings/ Subsets<br />HTML Display<br />
  44. 44. What is openEHR?<br /><ul><li>The openEHR Foundation is a non-profit established in 2001 –
  45. 45. Open source specifications for a logical EHR architecture</li></ul>Based on 18+ years of international implementation experience including Good European Health Record Project<br />Superset of ISO/CEN 13606 EHR standard<br /><ul><li>Engineering paradigm
  46. 46. Separation of clinical and technical concerns</li></ul>International Community<br />
  47. 47. openEHR knowledge artefacts<br />Archetype<br />Template<br />Foundation building blocks for semantic interoperability<br />= Structured, computable specification for one single clinical concept<br />Fix the absolute limits of what can be recorded <br />Maximal data set<br />Universal use-case<br />Design once, re-use over & over<br />The broader the agreement & governance, the greater the potential for interoperability<br />Terminology: usually universal bindings to data elements<br />Computable specification for a specific purpose:<br />Message, Document, Clinical consultation or Report<br />Aggregate archetypes; multiple concepts<br />Constrain to express what is sensible for the specific use-case<br />Can be governed & shared OR <br />Can be unique & use-case driven<br />Terminology: usually expresses context-appropriate value sets<br />
  48. 48. openEHR Reference Model<br />Underpins the archetypes & templates<br />Handles all the generic processes associated with operation of an EHR <br />Structure<br />Security<br />Versioning<br />People, Dates, Times, Data types<br />Expressed, but hidden, in the tooling<br />NO CONTENT<br />
  49. 49. ALL THE CONTENT(not restricted to clinical content)<br />openEHR content models<br />Archetypes + Templates (+ Terminology)<br />Domain experts model their domain<br />
  50. 50. Two level modelling<br />Templates<br />Archetypes<br />Archetypes<br />Archetypes<br />CLINICAL<br />TECHNICAL<br />Software is built independently of the content<br />
  51. 51. Clinicians driving EHRs!<br />
  52. 52. Archetype class  Process<br />1<br />Observations<br />Published evidence base<br />Domain Expert<br />Subject<br />4<br />Personal knowledge base<br />Actions<br />2<br />Evaluation<br />3<br />Investigator’s agents<br />Instructions<br />Compositions<br />Sections<br />Entries<br />measurable or observable<br />5<br />Admin Entry<br />Recording data for each activity <br />order or initiation of a workflow process<br />clinically interpreted findings<br />
  53. 53. openEHR Archetypes<br />Focus: Single clinical concepts<br />Basis for a coherent and consistent approach to clinical knowledge management<br />Capture, display, querying<br />Simplify messaging/exchange<br />Multilingual; no language primacy<br />Terminology independent<br />Tightly governed<br />
  54. 54. openEHR Archetypes 2<br />Provide a ‘glide path’ to knowledge-level interoperability of health information:<br />Bootstrap new application development<br />Provide a forward ‘roadmap’ for existing applications<br />Support data integration<br />Enable data aggregation & comparative analysis<br />Enable knowledge-based activities<br />
  55. 55. openEHR Templates<br />Focus: Use cases, multiple concepts<br />“Archetypes get all the glory; Templates do all the work!”<br />Allows tight governance of forms, messaging, reporting formats etc<br />MORE IMPORTANTLY... <br />Allows flexible expression of clinical & domain requirements <br />no need for ‘one size fits all’ approach if based on tightly governed building blocks - archetypes<br />
  56. 56. Clinical knowledge ecosystem<br />Clinical Knowledge Manager (CKM):<br />Online Repository – ‘one stop shop’<br />openEHR Archetypes & Templates, <br />Terminology subsets, including SNOMED CT, ICD, LOINC<br />?Other knowledge artefacts<br />Manage Publication process<br />Web 2.0 approach - harness online community collective knowledge and resources; avoid physical meetings<br />Peer Review and publication of Content, Translations & Terminology binding<br />Govern knowledge artefacts via digital asset management system<br />Provenance, audit trails, validation checking <br />Release sets for implementation<br />
  57. 57. Semantic architecture<br />Semantic reference<br />
  58. 58. Achievable?<br />̴ 10-20 archetypes  core clinical information to ‘save a life’<br />̴ 100 archetypes  primary care EHR<br />̴ 2000 archetypes  hospital EHR<br />[compared to >400,000 concepts in SNOMED]<br />Because openEHR combines:<br />Structure of archetypes/templates<br />Terminology codes/value sets<br />
  59. 59. Achievable? 2<br />Initial core clinical content is common to all disciplines and will be re-used by other specialist colleges and groups<br />Online archetype consensus in CKM:<br />Achieved in weeks/archetype<br />Minimises need for F2F meetings<br />Multiple archetype reviews run in parallel<br />Leverage existing and ongoing international work<br />
  60. 60. Can clinicians agree?<br />“What is a heart attack?”<br />“5 clinicians, 6 answers” – probably accurate!<br />“What is an issue vs problem vs diagnosis?”<br />No consensus in HL7 for years<br />BUT<br />There is generally agreement on the structure and concepts – ‘first principles’<br />HUMAN PROBLEM<br />Terms, value sets<br /><ul><li> Problem/Diagnosis name
  61. 61. Status
  62. 62. Date of initial onset
  63. 63. Age at initial onset
  64. 64. Severity
  65. 65. Clinical description
  66. 66. Date clinically recognised
  67. 67. Anatomical location
  68. 68. Aetiology
  69. 69. Occurrences
  70. 70. Exacerbations
  71. 71. Related problems
  72. 72. Date of Resolution
  73. 73. Age at resolution
  74. 74. Diagnostic criteria</li></li></ul><li>Core clinical content<br />openEHR Top 10 – ‘archetypes to save a life’<br />Emergency summary<br />Any health summary<br />Discharge Summary<br />Consultation records<br />Many communications<br />eReferral<br />
  75. 75. Lifelong health records<br />© Ocean Informatics 2008<br />
  76. 76. openEHR... <br />Data independentof technology & applications<br />Basis for potential “Universal health record”<br />Enables lifelong health information<br />Caters for clinical diversity<br />Caters for dynamic knowledge <br />Supports data liquidity/exchange<br />Enables re-use of health information<br />Multilingual solution<br />Terminology agnostic<br /> ;-)<br />
  77. 77. openEHR brings<br />A comprehensive semantic framework:<br />Based on a quality logical EHR<br />Clear separation of clinical and technical domains<br />Engagement of clinicians/domain experts<br />Quality and safety; ‘Fit for purpose’<br />Independent of communication formats or implementations<br />Consistent /coherent definition of clinical data, documents and messages<br />Data liquidity – create the data once, re-use when and where required<br />
  78. 78. Ocean Informatics?<br />Australian Company<br />Offices in London, Chile<br />Co-founder of openEHR Foundation<br />Executives<br />Clinician informaticians, Software engineers<br />Primary authors of openEHR specification<br />Tools<br />OceanEHR Platform<br />Enterprise-scale EHR server, EHR application components<br />Clinical Modeling Studio<br />Archetypes, Templates, Terminology Server, Clinical Knowledge Manager<br />EhrAdapter integration framework<br />HL7 V2, HL7 CDA, XML etc<br />
  79. 79. Where is Ocean working?<br />National Health Programs<br />Sweden<br />United Kingdom NHS<br />Australia <br />Singapore<br />Kazakhstan<br />Brazil<br />Vendors<br />Slovakia<br />Netherlands<br />Research projects<br />United Kingdom<br />Australia<br />Relationships<br />Open Health Tools<br />Microsoft<br />Professional Colleges<br /><ul><li>American College of Rheumatologists
  80. 80. Royal College of Pathologists of Australasia</li></ul>Interest:<br /><ul><li>Australian College of GPs (RACGP)
  81. 81. Australian Rheumatologists
  82. 82. College of Family Physicians of Canada
  83. 83. Royal Australian & New Zealand College of Obstetricians & Gynaecologists
  84. 84. International Council of Nurses</li></li></ul><li>Tooling Demonstration <br />Clinical Knowledge Manager<br />Archetype Editor<br />Template Designer<br />Terminology Query Editor<br />