1

The openEHR Developers workshop

Pablo Pazos Gutiérrezpablo.pazos@cabolabs.com

Experiences on developing software with openEHR

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

Open EHR Platform

reusing components and servicesto build you own apps and systems

4

EHRServer

Service-oriented clinical data repository for shared

EHRs, based on the openEHR standard.

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

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

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

EHRServer Query Builder

9

Query testing before creating

10

Test it yourself!

https://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list

11

EHRGen

EHR Generator Framework

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

EHRGen’s archetype-based queries

SELECT

RESULTS

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

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

XML Rule Engine

Rules and Clinical Decision Support: (re)using clinical data to

help clinicians

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

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

• 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

Muito Obrigado

pablo.pazos@cabolabs.com @ppazosgithub.com/ppazos