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
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
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
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
Idea to create this open platform where everyone can use to create their own app or system.
get full clinical documents or data points
choose semantic identifiers to define criteria or projections
for criteria, define the logic operator
save and execute! test UI or from the REST API