FHIR for OpenMRSHow What and Why
Suranga Nath Kasthurirathne
Problem
• We need standards to exchange data
• V2 works (?), but is old
• V3 is new, but very hard
• Everyone has their own solution
– We have so many different modules !!!
– Standards shouldn't’t be an add-on. They should be a fundamental feature
Solutions
• Think beyond of V2 and V3
• Don’t build just another module
• Build features that can be supported
• Think core – not extended
• Build only what we need
Advantages of FHIR
• Supports JSON
• Is developer oriented
• Aims to simplify
• Has rapidly won over the HI world
• Is very open
• Is willing to listen to us
Our Aim
• Build an OpenMRS FHIR module
• Define OpenMRS to FHIR mappings
• Use module to exchange data with external app
• Expand the OpenMRS Core API to move towards a standardized API
Our Scope
• Ability to Import and export data
• Support the interoperability paradigms REST, Documents, Messages, Services
• Support Tags, bundles, resources
• Well…. We can use XDS…
• Lets implement all FHIR resources !
• Enable search for resource by parameters X,Y,Z only what we need
• Snapshot or other more sophisticated data exchanges
• RSS and Atomfeed
Results
• Built a module
• Support export of several FHIR resources
• Support different FHIR search / read queries
• Connected OpenMRS to a (3rd party) SMART application
qa01.openmrs.org
‘Cause It Looks So Cool…
Doing Right Now
• Modeling OpenMRS encounters as FHIR resources
• Expanding on the OpenMRS core API
• Supporting different versions of the OMRS data model
Take Away these…
• FHIR is awesome
• OpenMRS will soon support FHIR data export
• OpenMRS is building a FHIR Based Core API
• You don’t have to learn the OpenMRS API to use it any more !!!
FHIR is not just another standard for OpenMRS