Developing openEHR EHRs - core functionalities
Download as PPT, PDF7 likes3,369 views
Pablo Pazos Gutiérrez gave a talk on developing openEHR systems. He discussed storing openEHR data using different database types, openEHR system architectures that have evolved to be more distributed and service-oriented, generating user interfaces from archetypes and templates, performing archetype-based validation on entered data, querying and visualizing openEHR data, and implementing openEHR over the past 8 years in Latin America.
Developing openEHR EHRs - core functionalities
- 1. Pablo Pazos Gutiérrez 2014 1 Developing openEHR systems core functionalities & other interesting stuff Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management May 27th 2014, Tromsø, Norway
- 2. Pablo Pazos Gutiérrez 2014 2 Who am I? What I do? • Working with openEHR since 2006 – And HL7, CDA, DICOM, CCR, … – Java/Groovy/Grails, .Net, PHP, HAPI, Mirth, … • Computer Eng. – Software Architect – Interoperability Expert – Teacher & Researcher • Living in Uruguay – Working globally • helping companies implement eHealth standards and EHR systems – w: www.CaboLabs.com – t: @ppazos – LinkedIn: http://tinyurl.com/ye9zhrw
- 3. Pablo Pazos Gutiérrez 2014 3 Talking about cool stuff • Store openEHR data • openEHR EHR System Architecture (evolution) • UI generation and data entry • Archetype based data entry processing and validation • openEHR data query and visualization • The big picture • openEHR in LATAM • Conclusions
- 4. Pablo Pazos Gutiérrez 2014 4 Store openEHR data
- 5. Pablo Pazos Gutiérrez 2014 5 Store openEHR data • First problem every developer has to face • openEHR – doesn’t define how to store data physically – defines a logical Information Model • Good: – freedom – technology agnostic • Bad: – learning curve – more work?
- 6. Pablo Pazos Gutiérrez 2014 6 Store openEHR data • Understand the nature of clinical information – Highly hierarchical (ehr, folder, document, section, …) – Complex structures (clinical documents) – Highly variable structures (medical specialty, department) – Big # of data types (date, number, code, range, …) • openEHR Information Model – Represents the clinical record hierarchy really well – Generic (any level of complexity and variability) – Small and stable (good for our software!)
- 7. Pablo Pazos Gutiérrez 2014 7 Store openEHR data • Usage considerations (our requirements!) – Operational CDR (apps, clinical sessions, transactions with users) – Shared CDR (EHR, events, persistent, versioning, transactions with systems) – Documental (episodes, folder organization, IHE XDS) – Temporal series / Real time (devices, monitors, wearables, …) – Analysis (research, data mining, knowledge discovery, AI, statistic studies, …) – Datawarehouse (data visualization, aggregations, metrics, reports, …) • Database types – Relational (tables, records, constraints, SQL) – Documental (JSON, XML, noSQL) – Object Oriented (integrated with the OO programming language) – Multidimensional (native storage for DW) – Graph – Key/Value, E/A/V – File based – Hybrid
- 8. Pablo Pazos Gutiérrez 2014 8 Store openEHR data • Lessons learned – There is no “one fits all” solution • Don’t use ONE solution to solve different problems – different DB types as solution to different usage requirements – yes! we might end with duplicated data, no problem. – Find specific problems for your system, then • improve current (performance tweaks can be done anytime) • change DB type if needed – Starting with relational DB is easy • openEHR IM + Relational databases – Design the DB schema and the mapping between OO and ER, or… – Use an ORM tool to automate schema generation and tweak it!
- 9. Pablo Pazos Gutiérrez 2014 9 Store openEHR data • Most modern technologies are OO and support ORM – Schema auto-generation for openEHR IM • Less specifications (we need to maintain those in time), less errors, consistency, quicker time to market, … • openEHR IM is small, stable and flexible the DB schema will not change and can store any data structure! • Specific data structures (current & future) should be defined by archetypes and OPTs (standardized & compatible with our DB schema) – ORM tools provide APIs to store and query data • Simpler than SQL, maintainable, testable, query results are objects! and… also support SQL :) • Java developers? – Try Grails and it’s GORM: https://grails.org/
- 10. Pablo Pazos Gutiérrez 2014 10 openEHR EHR System Architecture (evolution)
- 11. Pablo Pazos Gutiérrez 2014 11 openEHR EHR system architecture • Mono – The data entry application is the same that maintains the EHR data – Centralized approach – Should handle operative CDR and shared EHR functionalities – Scalability problems (more specialties, more patients, more devices)
- 12. Pablo Pazos Gutiérrez 2014 12 openEHR EHR system architecture • Front and Backend – More flexible data entry • UI layer is separated from the the one that maintains the EHR data – Little communication protocol / API between UI and backend – Light client, logic and persistence is centralized in the backend – Difficult to integrate with 3rd party systems, API limited to UI, scalability limited by UI capabilities and centralized backend
- 13. Pablo Pazos Gutiérrez 2014 13 openEHR EHR system architecture • SOA based / Cloud & Mobile friendly – Data entry application is a full app • each app has all 3 layers + communication layer • manages operative / transactional data – Backend maintains shared EHR and provides data services • Is not centralized, distributable by design (multi-instance + sync services) • Nice features you get because of redundancy + SOA + Cloud – Backup + fault tolerance + reliability + disaster recovery + H.A. + less response time … – Robust API to integrate client apps with the shared EHR backend • commit: service to feed data to the EHR of a patient • query: get data from the EHR of a patient – Backend can scale horizontally, provide H.A., elasticity (grow under demand), separation of concerns, standardized way to integrate 3rd party apps (not only for data entry!: data visualization, CDS, …)
- 14. Pablo Pazos Gutiérrez 2014 14 openEHR EHR system architecture
- 15. Pablo Pazos Gutiérrez 2014 15 openEHR EHR system architecture
- 16. Pablo Pazos Gutiérrez 2014 16 openEHR EHR system architecture • For any openEHR based system architecture, we also need the metadata repositories: – Archetypes – Operational Templates (OPT) – Terminologies (classifications, codes, catalogs, dictionaries, …) – UI Templates – Rules (CDS, alerts, recommendations, reminders, …) – Guidelines – Workflows – …
- 17. Pablo Pazos Gutiérrez 2014 17 UI generation and data entry
- 18. Pablo Pazos Gutiérrez 2014 18 UI generation and data entry • Creating UI by hand takes a lot of time, and more time is needed to maintain that UI • Creating an automatic UI generator for data entry is tempting, but not easy to do (at least one that’s generic enough to be used with many technologies and generating different kinds of structures for data entry) • Good: – less time required, consistent UI, less errors, less tests needed, rapid prototyping and requirement validation, support for many technologies/devices • Bad: – not so flexible/customized UI (but “tweakable”), specify metadata to tell the generator how to generate the UI (once specified, auto-generation is instantaneous), may need some integration work (wiring generated UI and app logic)
- 19. Pablo Pazos Gutiérrez 2014 19 UI generation and data entry • Metadata for UI auto-generation? – Archetypes define data structures, don’t include how those structures will be displayed to the user (UI) • We need more metadata to define UI • That will (re)use archetypes! – After 5 years of R&D, we designed a multilevel methodology for UI generation • UI Template model to define UIs • UI Template XML format as declarative specification • Prototype of a universal UI generator – Web XHTML, HTML5 – .Net Desktop and Web – Java Desktop Swing – can be extended to support other technologies!
- 20. Pablo Pazos Gutiérrez 2014 20 UI generation and data entry
- 21. Pablo Pazos Gutiérrez 2014 21 UI generation and data entry • Multi-level modeling methodology – dual model as basis – model based system auto-generation (by clinicians!)
- 22. Pablo Pazos Gutiérrez 2014 22 UI generation and data entry EHRGen: https://code.google.com/p/open-ehr-gen-framework/
- 23. Pablo Pazos Gutiérrez 2014 23 UI generation and data entry
- 24. Pablo Pazos Gutiérrez 2014 24 Archetype-based data entry validation
- 25. Pablo Pazos Gutiérrez 2014 25 Archetype-based data entry validation Don’t write validation rules in your software, use archetypes! path will get a constraint from template constraint will be evaluated against the data
- 26. Pablo Pazos Gutiérrez 2014 26 openEHR data query and visualization
- 27. Pablo Pazos Gutiérrez 2014 27 openEHR data query and visualization • Once data is sent from data entry apps to the EHR – Data is processed and made available for querying. – Let’s say we have “vital signs” data. • All data is defined by Archetypes & OPTs. • Data queries – Archetype-based • do not depend on the technical infrastructure – Clinical query builder (UI based) • No need of changing the source code to add more queries • Better than technology dependent queries (SQL) – openEHR proposal for an Archetype-based EHR query language: AQL • EHRServer will support AQL as a query exporting & share format.
- 28. Pablo Pazos Gutiérrez 2014 28 openEHR data query and visualization I want vital signs (archetype id) blood pressure and heart rate query name and type EHRServer online demo: https://www.youtube.com/watch?v=D-hs-Ofb8SY Creating a query
- 29. Pablo Pazos Gutiérrez 2014 29 openEHR data query and visualization blood pressure and heart rate paths inside the vital signs archetype output format XML or JSON web friendly data grouping: “by path” allows retrieving temporal series of the same kinds of data, easy to chart! test your query!
- 30. Pablo Pazos Gutiérrez 2014 30 openEHR data query and visualization JSON data client apps will get the same data supporting JSON and XML Grouped by path systolic BP, diastolic BP and heart rate Query one EHR
- 31. Pablo Pazos Gutiérrez 2014 31 openEHR data query and visualization Automatic data chart if possible. Tabular view simple to create using composition grouping.
- 32. Pablo Pazos Gutiérrez 2014 32 The Big Picture The openEHR INFOstructure
- 33. Pablo Pazos Gutiérrez 2014 33 openEHR INFOstructure
- 34. Pablo Pazos Gutiérrez 2014 34 openEHR in LATAM an 8 year journey
- 35. Pablo Pazos Gutiérrez 2014 35 openEHR in Uruguay • 2006–2007 first openEHR project in Uruguay – ICU EHR, I+D project – Actively involved in the community – Help improving the openEHR Java Reference Implementation • 2007–2014 research, publications, presentations and workshops in congresses and other events • 2008–2014 giving talks about eHealth and openEHR for several universities & courses – Uruguay, Argentina, Chile, Portugal, Colombia, Venezuela, … • 2009–2010 degree thesis – EHRGen: first openEHR framework that generates UI automatically from archetypes + automatic data validation + automatic data persistence • 2009–2011 nationwide EHR project – openEHR concepts applied – request for proposals including openEHR concepts • 2011–2014 first 100% openEHR online course (Spanish) – We generated awareness – Now individuals and companies want to implement the standard • 2010–2011 ECLAC, UN, publication mentioning openEHR for interoperability – “Estándares e interoperabilidad en salud electrónica: Requisitos para una gestión sanitaria efectiva y eficiente” • 2014 national EHR (Uruguay) – request for proposals includes on item exclusively about
- 36. Pablo Pazos Gutiérrez 2014 36 openEHR in LATAM openEHR online course 2011 – 2014 (4 editions)
- 37. Pablo Pazos Gutiérrez 2014 37 openEHR in LATAM • Brazil – Providers implement openEHR – Included by the Ministry of Health as standard – Local openEHR community • Argentina – Companies interested in developing openEHR soft – Included in postgraduate courses as topic – Implementing an EHR for a paperless hospital • Venezuela – Implemented a system based on EHRGen for pregnancy & labor care • Colombia – Included in postgraduate courses as topic • Chile – Companies interested in developing openEHR soft • Spain – Providers implement openEHR – Included in postgraduate courses as topic • Portugal – Included in postgraduate courses as topic – Local community • Mexico – Implemented a system based on EHRGen for cancer care • …
- 38. Pablo Pazos Gutiérrez 2014 38 openEHR in LATAM • Gaining interest in other countries – After 4 years with the openEHR course awareness & interest stages are done – Consideration is the current stage – Next is intent & evaluation (some are here) • Back in the day – Nobody knew about openEHR – Now is just another requirement
- 39. Pablo Pazos Gutiérrez 2014 39 Conclusions
- 40. Pablo Pazos Gutiérrez 2014 40 Conclusions • openEHR is gaining momentum • Growing community, industry & govt. more involved • There is no other open standard / technology agnostic alternative for future interoperable & proof systems on the market • HL7 understood that openEHR is complementary, not an alternative • Open source openEHR software is improving day by day • openEHR is a good & elegant solution, no one proved otherwise since 2002
- 41. Pablo Pazos Gutiérrez 2014 41 Conclusions • Go for it, try it, integrate it into your technology stack, and make healthcare compute!
- 42. Pablo Pazos Gutiérrez 2014 42 Thanks! w: www.CaboLabs.com t: @ppazos e: pablo.pazos@cabolabs.com LinkedIn: http://tinyurl.com/ye9zhrw
Editor's Notes
- #12: TODO> diagramas de las 3 arquitecturas openEHR
- #34: We’ll have tools for clinical roles to define all the metadata. Software components will be “programmed” by the metadata, changing behavior and user experience. Providing services to app developers, using the info-structure leading to standardized information and interoperable future-proof systems.
- #36: nobody to talk about openEHR…