Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

openEHR Developers Workshop at #MedInfo2015

1,331 views

Published on

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

Published in: Healthcare
  • Be the first to comment

openEHR Developers Workshop at #MedInfo2015

  1. 1. 1 The openEHR Developers workshop Pablo Pazos Gutiérrez pablo.pazos@cabolabs.com Experiences on developing software with openEHR
  2. 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. 3 Open EHR Platform reusing components and services to build you own apps and systems
  4. 4. 4 EHRServer Service-oriented clinical data repository for shared EHRs, based on the openEHR standard.
  5. 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. 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. 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. 8 EHRServer Query Builder
  9. 9. 9 Query testing before creating
  10. 10. 10 Test it yourself! https://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list
  11. 11. 11 EHRGen EHR Generator Framework
  12. 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. 13 EHRGen’s archetype-based queries SELECT RESULTS
  14. 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. 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. 16 XML Rule Engine Rules and Clinical Decision Support: (re)using clinical data to help clinicians
  17. 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. 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. 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. 20 Muito Obrigado pablo.pazos@cabolabs.com @ppazos github.com/ppazos

×