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