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