My presentation about projects and ideas for EHR development using the openEHR standard

1. 1
The openEHR Developers
workshop
Pablo Pazos Gutiérrez
pablo.pazos@cabolabs.com
Experiences on developing software with openEHR

2. 2
We've worked on interesting topics
• Clinical Databases / Clinical Data Repositories
• Web Services / REST APIs
• GUI Auto-generation
• Rules for Clinical Decision Support
• An Open EHR Platform (combination of ^)
• Open Source Software
• All based on

3. 3
Open EHR Platform
reusing components and services
to build you own apps and systems

4. 4
EHRServer
Service-oriented clinical data
repository for shared EHRs, based
on the openEHR standard.

5. 5
EHRServer
• Services
– commit
• feed data to the EHR of a patient
• openEHR XML documents
• validates against the openEHR XSD
• versioned data (no physical delete or modification of data)
– query
• clinical documents by complex criteria
• data points with different groupings
– sync (TBD)
• scaling EHRServers
• enable high availability
– other
• get patients, ehrs, clinical documents, queries, ...

6. 6
EHRServer
• Features
– REST API (SOAP will be enabled soon)
– Multi-format query results (XML, JSON, need more?)
– Versioned data
– EHR audit
• All modifications of an EHR are recorded
• Who, when, what, from where, ...
– Admin GUI
• Query building and testing (archetype-based queries)
• EHR Audit
• Organization of clinical records in folders
• Adding templates
– Adds support for new clinical records
– Without changing source code or database schema

7. 7
EHRServer
• Technologies
– Java / Groovy
– Grails Framework
– MySQL (can be replaced)
• Out of scope
– No GUI for clinical records (that's on client apps)
• Open Source
– EHRServer
• https://github.com/ppazos/cabolabs-ehrserver
– Sample client apps
• https://github.com/ppazos/cabolabs-emrapp
• https://github.com/ppazos/EHRCommitter
• https://github.com/ppazos/EHRClientPHP
– Javascript connector
• https://github.com/ppazos/cabolabs-ehrserver-js

8. 8
EHRServer Query Builder

9. 9
Query testing before creating

10. 10
Test it yourself!
https://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list

11. 11
EHRGen
EHR Generator Framework

12. 12
EHRGen
• Features
– Load archetypes and UI templates (T)
with references to archetypes
– Associate (T) with workflows (WF) 
– UIs are auto-generated from (T)
– Menus are auto-generated from (WF)
– Data validation using archetypes
– Generic data storage (any openEHR
data structure)
– No need to change the source code or
database schema to add more types of
clinical records
• just add archetypes and UI templates
• EHRGen will do the rest :D
• TODO:
– Use Operational Templates (OPT)
instead of archetypes
– Commit data to the EHRServer
• Test it:
– http://ehrgen-ehrserver.rhcloud.com/ehrgen-1.4-0.8b3

13. 13
EHRGen’s archetype-based queries
SELECT
RESULTS

14. 14
UI Generation / Current Work
• Generalization to generate UIs for any technology / device
– ... that has a declarative UI language / syntax
• Generic UI Template Model
– References openEHR archetypes / operational templates
– XML expression of UI Template
• UI Generator maps UI Templates to declarative UIs in any technology
– XAML, SwiXML, HTML5, XHTML, Android XML Layouts, ...
– Using mappings from the canonical UI Template to each declarative UI syntax
• Use cases:
– accelerate openEHR app development
– fast prototyping and user validation
• Soon:
– full spec on for openEHR UI Templates

15. 15
UI Template Model (simplified)
organization of
sections in the
screen
references to openEHR
archetypes / templates
view = screen / form
form controls (fields) and
labels on screen for
archetype nodes

16. 16
XML Rule Engine
Rules and Clinical Decision Support:
(re)using clinical data to help clinicians

17. 17
XML Rule Engine for CDS
• Requirement:
– Women should have a PAP
test once a year.
• Rule:
– If last PAP test of a patient
was done more than a year
ago, then send an alert.
• Clinical information (tests)
can be pulled from different
systems
– EHRServer using semantic
queries (path-based).
– Different data sources can
be combined in the same
rule.
• Rule is evaluated using a
REST Web Service
– patient id is an input
parameter
<xrl:unit xmlns:xrl="http://openehr.org.es/rules">
<header>
<id>gine_alerts.v1</id>
</header>
<rules>
<rule>
<id>pap_test_alert.v1</id>
<name>alerta para recordatorio de test de papanicolaou</name>
<definitions>
<var name="last_pap_test_date" type="date">
<resolutor type="http">
<locator url="http://localhost/gine_tests.xml" />
<extractor path="tests.test.time" />
<aggregator type="last" />
<param name="patient_id" />
</resolutor>
</var>
<var name="ret_alert" value="alert" type="string" />
<var name="ret_ok" value="ok" type="string" />
<var name="days_from_last_pap" type="integer">
<resolutor type="action">
<action type="dateDiff" in1="last_pap_test_date" in2="$now" units="days" />
</resolutor>
</var>
</definitions>
<logic>
<if>
<gt in1="days_from_last_pap" inc2="365" />
<do>
<action type="..." params="..."></action>
<return name="last_pap_test_date" />
<return name="days_from_last_pap" />
<return name="ret_alert" />
</do>
</if>
<else>
<do><return name="ret_ok" /></do>
</else>
</logic>
</rule>
</rules>
</xrl:unit>

18. 18
XML Rule Engine for CDS
• Results on screen:
– For each patient
– Alerts showing the result of evaluating the pap rule
– Can add a sex check in the rule to see if the rule applies (for females only)
– Rules results can be integrated in any system

19. 19
• We wouldn't build any of those without
– open specifications
– open source reference implementations (Java, Ruby, .Net, Python)
– awesome community!
• Thanks to that, we have:
– very flexible and generic software,
– maintainable without changing source code or database schemas,
– standardized clinical data,
– consistent ways of querying and share clinical data
– bindings to standard terminologies (SNOMED CT, ICD-10, CIAP-2, LOINC, ...)
– compatible with technical data transfer standards (HL7 v2.x, HL7 v3, CDA, FHIR,
DICOM, ...)
• Our software is all open source, main application (today) is training.
– Please join our projects to help us build the Open EHR Platform!
Conclusion

20. 20
Muito Obrigado
pablo.pazos@cabolabs.com
@ppazos
github.com/ppazos