Developing openEHR EHRs - core functionalities

Pablo Pazos Gutiérrez 2014 1

Developing openEHR systemscore functionalities & other interesting stuff

Arctic Conference on Dual-Model based Clinical Decision Support and Knowledge Management

May 27th 2014, Tromsø, Norway


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

http://www.cabolabs.com/

http://tinyurl.com/ye9zhrw


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


Store openEHR data


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?


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!)


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


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!


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/

https://grails.org/


openEHR EHR System Architecture (evolution)


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)


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


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, …)


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– …


UI generation and data entry


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)


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!


UI generation and data entry• Multi-level modeling methodology

– dual model as basis

– model based system auto-generation (by clinicians!)



EHRGen: https://code.google.com/p/open-ehr-gen-framework/

https://code.google.com/p/open-ehr-gen-framework/


Archetype-based data entry validation


Archetype-based data entry validation

Don’t write validation rules in your software, use archetypes!

path will get a constraint from templateconstraint will be evaluated against the data


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.



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

https://www.youtube.com/watch?v=D-hs-Ofb8SY



blood pressure and heart ratepaths inside the vital signsarchetype

output format XML or JSONweb friendly

data grouping: “by path” allowsretrieving temporal series of thesame kinds of data, easy to chart!

test your query!



JSON dataclient apps will get the same datasupporting JSON and XML

Grouped by pathsystolic BP, diastolic BP and heart rate

Query one EHR



Automatic data chart if possible.Tabular view simple to create using composition grouping.


The Big PictureThe openEHR INFOstructure


openEHR INFOstructure


openEHR in LATAMan 8 year journey


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


openEHR in LATAM

openEHR online course2011 – 2014 (4 editions)


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

• …


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


Conclusions


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


Conclusions

• Go for it, try it, integrate it into your technology stack, and make healthcare compute!


Thanks!

w: www.CaboLabs.comt: @ppazos

e: [email protected]: http://tinyurl.com/ye9zhrw

http://www.cabolabs.com/

http://tinyurl.com/ye9zhrw

Developing openEHR EHRs - core functionalities

Health & Medicine

Transcript of Developing openEHR EHRs - core functionalities