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.

1 3 introduction to open_ehr

60 views

Published on

This presentation provides an introduction to the concepts and principles of openEHR.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

1 3 introduction to open_ehr

  1. 1. Dr Ian McNicoll What is openEHR
  2. 2. What is openEHR? An open specification for a health information model capable of supporting an open platform ecosystem vendor neutral technology neutral licensed to allow open and closed source business models openehr.org
  3. 3. openEHR - Specifications Normal technical specifications with UML diagrams etc openEHR Reference model how the health data is represented in a patient record openEHR Archetype object model how the clinical content definitions are represented separately from the Reference model
  4. 4. Two-level modelling Low-level ‘stable’ reference model (RM) Basic classes, structures, datatypes Version control, auditing Separate ‘clinical modelling’ layer which is applied as a ‘constraint’ on the RM Clinical content is defined and managed separately but is always conformant to the RM and can always be consumed by the RM
  5. 5. Two-level modelling
  6. 6. openEHR: Archetypes open source computable models of discrete clinical concepts Familiar components of a health record Blood pressure, Body weight Medication order, Family history Urea, Creatinine results ‘Maximal dataset’ Capture as many clinical perspectives as possible
  7. 7. openEHR: Templates Templates deliver the datasets by aggregating archetypes together Key clinical endpoint and start point for generation of technical artefacts i.e. openEHR archetypes and 
 templates can be used directly Class libraries, Message schema GUI skeletons, API Profiles
  8. 8. AQL: Information-model querying Information model querying, independent of the actual database querying vendor/technology neutral querying
 To query an openEHR system you only have to know which archetypes are in use.
  9. 9. Vendor-neutral querying
  10. 10. life-long record:clinicians in control Archetypes consumed automatically by an openEHR system Out-of-the-box interoperability through archetype sharing No transforms or other processing required when moving data to other vendors Third-party apps Vendor-neutral Information model Technology-neutral datastore (CDR)
  11. 11. However …. Building an openEHR back-end is easy just follow the specifications BUT
 
 building a high-quality openEHR back-end is hard must understand archetypes must support information-model querying must be fast and flexible This is not a trivial engineering exercise
  12. 12. Technical approaches Normalised RDBMS hard to respond to content changes O-R mapping such as Hibernate does not scale well NoSQL solutions seemingly a good fit but not much real-world experience Mumps implementation MongoDB, Neo4J used in academic projects Commercial offerings RDBMS + indexed binary blobs Postgres, Oracle, SQL Server Minimal normalisation
  13. 13. open source implementations ADOC EtherCis https://github.com/ethercis
 Cabolabs EhrServer https://github.com/ppazos/cabolabs-ehrserver http://www.slideshare.net/pablitox/design-and- implementation-of-clinical-databases-using- openehr
  14. 14. The good news… You do not have to build your own openEHR back-end ‘CDR’… over 10 providers of openEHR CDR services the APIs are compact and easy to use once you understand the basic concepts
  15. 15. Database Vendor-neutral AQL GDL support open source Separate product Think!EHR Oracle / SQL Server / PostgreSQL Yes Yes Yes Yes OceanEHR SQL server Yes Yes Yes Yes DipsEHR SQL Server Yes Yes Yes Yes EtherCIS PostgreSQL Yes Yes In dev Yes Yes Base24 PostgreSQL Yes In dev In dev Yes Cabolabs Any SQL Yes In dev Nn dev Yes Yes Privantis PostgreSQL Yes In dev In dev In dev Ehr.care GraphDBs/Postgres Yes Yes In dev Yes Clever CDR Various Yes Yes In dev Yes openEHR CDR market
  16. 16. open platform architecture Third-party apps Technology-neutral datastore (CDR) Vendor-neutral Information model
  17. 17. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  18. 18. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  19. 19. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  20. 20. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  21. 21. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  22. 22. open platform architecture Third-party apps Technology-neutral datastore (CDR) openEHR Rest API + AQL
  23. 23. eHealth'('City'of'Moscow'' Reproduced'with'permission' 'h9p://bit.ly/1w9wZQy'' Does it scale?
  24. 24. App development
  25. 25. App development
  26. 26. App development
  27. 27. App development
  28. 28. The ‘bi-modal’ EHR? Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed. open Platform + Legacy EPR User interface Information model Database Third-party apps Vendor-neutral Information model Technology-neutral datastore (CDR)
  29. 29. Registries
  30. 30. ‘Feral’ apps
  31. 31. health platform as a service
  32. 32. National ‘standards’ development
  33. 33. National ‘standards’ development
  34. 34. National ‘standards’ development
  35. 35. National ‘standards’ development
  36. 36. Web-based ‘democratised’ collaborative review
  37. 37. Web-based ‘democratised’ collaborative review
  38. 38. Evolutionary standardisation
 ‘distributed Governance’ Implementers Secondary endorsement
  39. 39. Evolutionary standardisation
 ‘distributed Governance’ Implementers Secondary endorsement
  40. 40. Local asset governance In any software development environment version control is vital
 Clinical systems are continually changing Models have multiple co-dependencies Changing one will have an impact on another Changes to models and software must be carefully managed To prevent technical incompatibilities To prevent clinical safety problems
  41. 41. Package management
  42. 42. Managing Version control Authoring phase during the authoring phase frequent version/revision changes are inevitable Loose control is necessary Operational phase It is critical that new Versions or Revisions are not introduced inadvertently May break queries May introduce clinical safety problems Tight control is essential
  43. 43. Staging Vendor authoring repository Working copies Ian Olga Hildi openEHR CKM Vendor software development repository Vendor operational repository commit update comment, review, request, endorse GIT GIT GIT
  44. 44. openEHR summary Designed for storing and querying rich clinical datasets
 New content defined directly
 by clinicians and immediately uploaded into the CDR Vendor-neutral data Technology-neutral data GDPR-ready!!

×