“If the banks can do it, why can’t health?” is the classic statement made by health ministers under pressure to deliver – demonstrating that they don’t understand the issues. Health is at the opposite end of the continuum to financial data... See the following slides.
... And more
... And more
... And more
Need for clinical diversity is underrated. EHR systems corral clinicians into certain types of recording etc, but for safety we need more diverse ways for clinicians to record what they need for patient care, and also to ensure that what is exchanged is appropriate for the patient and their circumstances. A ‘one size fits all’ coument approach to emergency summaries or messages can be potientially unsafe. Elderly, pregnancy, chronic disease, paediatrics are extremely common examples where there are specific additional requirements needed to summary data sets
Client’s slide demonstrating his reality – entire EHR data migration from one outdated system to a new one every 7-10 years – with inherent risk to data in the process. Not supporting an ongoing lifelong health record
Bubbles or silos of information – all different.Or same application, different configuration.Effectively prevent information being shared.
Messaging paradigm to patch between disparate systems. Often not a natural flow of data.Can take months to years to develop a standard message, then vendors often tweak them, so no longer standardised.‘n’ to ‘n’ messaging paradigm can be useful for a set number of messages or documents, but if need to exchange more flexible content, gets unsustainable very quickly. Incremental evolution process – it has just happened without a specific design strategy over time, in order to utilise what we have as best we can.It is providing limited success! Is it sustainable? How far can we push it?Intermountain Health have 30 full time employees devoted to managing messages alone in their multiple systems across multiple hospitals.
Normally the dog is in control of his tail.In health IT it feels like the tail is wagging the dog, that we have things the wrong way around.
What if approach the problem from a different direction, where we make the focus of EHR development the clinical knowledge, the clinical content of an EHR?
Underpin the clinical content with a Reference Model to create computable clinical data models.
Output of computable models are numerous, generated from the same source knowledge models. Includes ability for message content to be drawn directly from the EHR data etc.
Time will be required to develop the core content models in the first instance, but not more than is required for each current message negotiation, and when these models are increasingly re-used, they will accelerate modelling of complex model such as templates for clinical use cases
In the openEHR space, the knowledge models are archetypes and templates.
Terminology is utilised within the openEHR clinical models to model clinical content.Domain experts esp clinicians are responsible for the model development, independent of software development.
Separation of the clinical and technical concerns – archetypes & templates are built by clinicians independently of the software. Engineers can build the software without need for upfront understanding the content that will be contained within the EHR.
Bootstrap new application development – single source of clinical content, avoid re-inventing the wheelProvide a forward ‘roadmap’ for existing applications – support gradual transition to common data representationsSupport data integration – means to migrate valuable silos of legacy data to a common, re-usable representationEnable data aggregation & comparative analysis – basis for ensuring ‘apples’ are ‘apples’, not ‘oranges’Simplify messaging – keep message content consistent with EHR content; generic wrappers for contentEnable knowledge-based activities eg CDSS – consistent & coherent; create once, re-use in all systems
Have your cake & eat it too!
Clinicians notoriously argue about definitions etc. EHRs won’t change this ongoing issue. This is inherently a human problem.However clinicians can achieve agreement about the structure of concepts.
The openEHR community voted on the Top 10 archetypes – ‘to save a life’. These are the current focus of work in CKM, and will be core content for most common and critical documents and messages needing to be shared.
Client’s view of the benefits of openEHR ie creation of a single data platform a la iPod – ‘plug & play’ with applications into pool of standardised dataNo data conversions required.It. Is. All. About. The. Data.
1. Clinician-led eHealth records<br />A knowledge-enabled approach to the sharing of health information <br />Dr Heather Leslie<br />
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. Why is sharing health information so difficult?<br /><ul><li>Complex & dynamic clinical domain
4. Lifelong records
5. Requirements for clinical diversity
6. Privacy & Security
7. Increasing health costs
8. Safety & Prevention
9. Mobile population
10. Mobile providers
11. ...</li></ul>“If the banks can do it, why can’t health?”<br />CLINICAL DATA is key<br />
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. Complexity: Medication timing<br />
14. Complexity: Medication timing<br />
15. Complexity: Medication timing<br />
16. Complexity: Medication timing<br />
17. Complexity: Medication timing<br />
18. Clinical diversity<br /><ul><li>Variety of data represented
19. Free-text vs Structured
20. Normal statements
21. “Nil significant”, “NAD”
23. Fractal nature of medicine
24. Different clinicians:
25. Prefer different approaches
26. Need different levels of detail
27. Need to record/exchange information on a per patient basis
35. EHR ‘bubbles’ message ‘patches’<br />INCREMENTAL EVOLUTION<br /> How far can we push it? <br />
36. ‘Tail wagging the dog’?<br />
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 />
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. 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 />
44. What is openEHR?<br /><ul><li>The openEHR Foundation is a non-profit established in 2001 – www.openEHR.org
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. Separation of clinical and technical concerns</li></ul>International Community<br />
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. 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. ALL THE CONTENT(not restricted to clinical content)<br />openEHR content models<br />Archetypes + Templates (+ Terminology)<br />Domain experts model their domain<br />
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. Clinicians driving EHRs!<br />
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. 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. 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. 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. Clinical knowledge ecosystem<br />Clinical Knowledge Manager (CKM): www.openEHR.org/knowledge<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 />
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. 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. 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
62. Date of initial onset
63. Age at initial onset
65. Clinical description
66. Date clinically recognised
67. Anatomical location
71. Related problems
72. Date of Resolution
73. Age at resolution
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 />
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. 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. 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. 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. Royal College of Pathologists of Australasia</li></ul>Interest:<br /><ul><li>Australian College of GPs (RACGP)
81. Australian Rheumatologists
82. College of Family Physicians of Canada
83. Royal Australian & New Zealand College of Obstetricians & Gynaecologists
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 />