#Uncomplexication of clinical infostructure - a clinical modelling odyssey
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

#Uncomplexication of clinical infostructure - a clinical modelling odyssey

on

  • 709 views

Remote presentation delivered to the Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management on May 28, 2014

Remote presentation delivered to the Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management on May 28, 2014

Statistics

Views

Total Views
709
Views on SlideShare
296
Embed Views
413

Actions

Likes
0
Downloads
9
Comments
0

3 Embeds 413

http://omowizard.wordpress.com 396
https://twitter.com 16
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined. <br /> Every step forward has revealed more complexity rather than less <br /> Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability <br /> Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc <br />
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined. <br /> Every step forward has revealed more complexity rather than less <br /> Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability <br /> Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc <br />
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined. <br /> Every step forward has revealed more complexity rather than less <br /> Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability <br /> Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc <br />
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined. <br /> Every step forward has revealed more complexity rather than less <br /> Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability <br /> Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc <br />
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined. <br /> Every step forward has revealed more complexity rather than less <br /> Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability <br /> Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc <br />
  • Standardisation of Information Models often missing in any typical SDO conversations

#Uncomplexication of clinical infostructure - a clinical modelling odyssey Presentation Transcript

  • 1. #UNCOMPLEXICATION OF CLINICAL INFOSTRUCTURE AKA ‘a clinical modelling odyssey’ Dr Heather Leslie
  • 2. Healthcare's Big Problem With Little Data  Gartner’s hype cycle: “Big Data” heading toward the “Peak of Inflated Expectations”  “In the meantime, however, ”little data” in healthcare continues to give us all peptic ulcers”  “Clinical data at the unit level is chaotic and dysfunctional because it’s not easily transferable or usable outside of the system that first created it. In a world of competing financial interests and an increasingly mobile population – every patient encounter represents an opportunity for technology vendors to lock-in providers.”  “Historically, the crutch that many software vendors have relied on is the format of the data itself.”  http://www.forbes.com/sites/danmunro/2013/04/28/big-problem-with- little-data/ - April 28, 2013
  • 3. The odyssey?  2004 – the ‘sneak preview’
  • 4. The odyssey?  2004 – the ‘sneak preview’  2007 – initial modelling for NHS  210 archetypes/49 templates  2 people/3 weeks – simple, pragmatic, no review, no metadata  Antenatal, Emergency  Demonstrated capacity for:  Rapid development  Archetype re-use  Need for CLUSTER archetypes identified
  • 5. The odyssey?  2004 – the ‘sneak preview’  2007 – initial modelling for NHS
  • 6. The odyssey?  2004 – the ‘sneak preview’  2007 – initial modelling for NHS  2007 – ongoing NHS internal modelling  691 archetypes; 60 templates  Observations:  Lack of openEHR skills  Technical modellers; lack of domain experts  Lack of common methodology; coordination  Not a specific NHS issue, but reflects the human experience >> Identified need for Collaborative/Governance tool
  • 7. Initial Team Modelling - analysis  Naming inconsistency  Wrong class  Modelling design  Lack of training  Technical modeler  Inconsistent patterns  Content scope, context and intent unclear  Granularity:  Make into a template, OR  Need to divide into multiple smaller archetypes  Minimal content change resulting in specialisation, but effectively just renaming.  Multiple versions of same concept  Need to model generic concept comprehensively first, then specialise  Need to re-use existing archetypes  Zero content change but created as new version
  • 8. The odyssey?  2004 – the ‘sneak preview’  2007 – initial modelling for NHS  2007 – ongoing NHS internal modelling  2008 – CKM development commences…  Late 2008: Initial openEHR CKM deployment –  250 archetypes, largely from the initial NHS modelling work
  • 9. CKM distribution openEHR international CKM… plus
  • 10. openEHR modelling activity  openEHR Foundation  ?Argentina/Uruguay  Australia  NEHTA – national program  NorthernTerritory  Ocean  Brasil  National program/Uni. Brasilia  Unimed  Minas Gerais  Federal University of São Paulo  New Zealand  University of Auckland  Norway  Uni Tromso  DIPS/HelseBergen  Portugal  University of Porto  Critical  Russia  City of Moscow  Slovenia  Marand  Ministry of Health  Sweden  Cambio  UK  GP2GP  Leeds Care Record Service  SCIMP  RCP Headings project
  • 11. Modelling momentum…  Fragmented, piece-meal, spurts or activity  Zero-resources  ?Largely driven by Ocean projects/apps/collabs  Passive openEHR community… Happily, this is changing…  Industry Group -> $$ for archetype devt/pub  More CKM instances with collaborative mindset  Norway, Slovenia, ?Brasil  Platform -> applications -> demand for archetypes
  • 12. Lessons: Collaboration  Major strength: Underpins the openEHR methodology
  • 13. Lessons: Collaboration  Major strength: Underpins the openEHR methodology  Collaboration >> interoperability  Multiple sub-domains/projects in a single instance  Multi-instance cooperation  International instance
  • 14. Lessons: Collaboration  Major strength: Underpins the openEHR methodology  Collaboration >> interoperability  Multiple sub-domains/projects in a single instance  Multi-instance cooperation  International instance  Tension in international CKM  support localisation vs common requirements  opportunities for all to ‘play’
  • 15. Lessons: Collaboration  Major strength: Underpins the openEHR methodology  Collaboration >> interoperability  Multiple sub-domains/projects in a single instance  Multi-instance cooperation  International instance  Tension in international CKM  support localisation vs common requirements  opportunities for all to ‘play’  ‘Top down’ vs ‘bottom up’  Volunteering archetypes  Online vs F2F Meetings
  • 16. Lessons: Archetype creation  Value of ENTRY classes Actions Published evidence base Personal knowledge base Evaluation 2 Observations Subject Instructions Investigator’s agents 4 3 1 Domain Expert
  • 17. Lessons: Archetype creation  Value of ENTRY classes  Clinical informatician or technical modeller or…? v
  • 18. Lessons: Archetype creation  Value of ENTRY classes  Clinical informatician or technical modeller or…?  Pragmatic ‘Maximal dataset/Universal use case’
  • 19. Lessons: Archetype creation  Value of ENTRY classes  Clinical informatician or technical modeller or…?  Pragmatic ‘Maximal dataset/Universal use case’  Pattern evolution  Academic/intellectual/practical starting point  Iterative: refined after template design or implementation  Examples  WYSIWYG – many OBS,CLUSTER, EVAL  Frameworks – Procedure ACTIONs, complex Lab/imaging OBS  Physical Examination – fractal CLUSTERs within OBS.exam  Minimising Specialisation – useful for localisation
  • 20. Lessons: Template creation  Embodiment of the 2 level modelling ‘magic’
  • 21. Lessons: Template creation  Embodiment of the 2 level modelling ‘magic’  ‘Light’Training  Decentralised development  Meet local requirements
  • 22. Lessons: Template creation  Embodiment of the 2 level modelling ‘magic’  ‘Light’Training  Decentralised development  Meet local requirements  Enables clinician diversity
  • 23. Lessons: Template creation  Embodiment of the 2 level modelling ‘magic’  ‘Light’Training  Decentralised development  Meet local requirements  Enables clinician diversity  Power of archetype re-use Re-use of existing 16 50% re-used, no changes 59% re- use Modify existing – minor 2 9% re-used with some enhancements from newly identified requirements Modify existing – major 1 New development 13 41% new
  • 24. Lessons: Template creation  Embodiment of the 2 level modelling ‘magic’  ‘Light’Training  Decentralised development  Meet local requirements  Enables clinician diversity  Power of archetype re-use  Potential for multiple outputs  Clinician friendly UX -> engagement  Technical artefact generation  Documentation generation
  • 25. Lessons: Artefact governance  Govern archetypes tightly  Templates can be governed, if required; otherwise kickstart others
  • 26. Lessons: Artefact governance  Govern archetypes tightly  Templates can be governed, if required; otherwise kickstart others  Artefact identification  ‘Wild’ vs governed  Artefact versions/revisions/builds vs publication status
  • 27. Lessons: Artefact governance  Govern archetypes tightly  Templates can be governed, if required; otherwise kickstart others  Artefact identification  ‘Wild’ vs governed  Artefact versions/revisions/builds vs publication status  ‘Folders’  Governed: Subdomains & Projects  Ungoverned: Incubators - public or private
  • 28. Lessons: Artefact governance  Govern archetypes tightly  Templates can be governed, if required; otherwise kickstart others  Artefact identification  ‘Wild’ vs governed  Artefact versions/revisions/builds vs publication status  ‘Folders’  Governed: Subdomains & Projects  Ungoverned: Incubators - public or private  Management of groups of artefacts  Templates – archetypes + ref sets; all with IDs, versions etc  Release Sets  Remote Subdomain – referenced artefacts from another instance
  • 29. Lessons: Artefact governance  Govern archetypes tightly  Templates can be governed, if required; otherwise kickstart others  Artefact identification  ‘Wild’ vs governed  Artefact versions/revisions/builds vs publication status  ‘Folders’  Governed: Subdomains & Projects  Ungoverned: Incubators - public or private  Management of groups of artefacts  Templates – archetypes + ref sets; all with IDs, versions etc  Release Sets  Remote Subdomain – referenced artefacts from another instance  Single instance vs Multiple instances
  • 30. Lessons: CKM personpower  Single, standalone instance [vs shared instance]  2-3 Clinical KnowledgeAdministrators (CKA)  Oversight & responsibility for all of the clinical knowledge artefacts  Core team of skilled ‘archetype wranglers’ (4-8)  Cohesive pool of archetypes  Common mechanism for engagement with terminology  Multidisciplinary team – informaticians, domain experts, engineers, terminologists  Editorial leadership  Content,Terminology,Translation  DistributedTemplate Authors  ‘Light’ training, local needs  Broad online community of reviewers
  • 31. Into the future…  Focused, coordinated and resourced activities  Artefact development  Publication  Governance  SDO collaboration  CIMI  FHIR  CDISC?  IHTSDO?  Secondary Use  Research/Registries/Epidemiology
  • 32. Into the future…  Inter-CKM collaborative community  Modelling Documentation  Training  Variety – F2F, online etc  Accreditation