Your SlideShare is downloading. ×
  • Like
#Uncomplexication of clinical infostructure - a clinical modelling odyssey
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

#Uncomplexication of clinical infostructure - a clinical modelling odyssey

  • 652 views
Published

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

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
652
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
9
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined.
    Every step forward has revealed more complexity rather than less
    Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability
    Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined.
    Every step forward has revealed more complexity rather than less
    Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability
    Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined.
    Every step forward has revealed more complexity rather than less
    Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability
    Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined.
    Every step forward has revealed more complexity rather than less
    Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability
    Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc
  • Creating and managing a cohesive set of clinical knowledge artefact is far more complex than we ever imagined.
    Every step forward has revealed more complexity rather than less
    Collaboration is at the core of interoperability – the more collaboration, the greater the potential interoperability
    Multifocal governance – involves reconciling and collaborating across multiple instance and versions etc
  • Standardisation of Information Models often missing in any typical SDO conversations

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