OpenMRS FHIR Module Development: Phase 01 (Outdated)

Table of Contents

Abstract

The aim of this project is to build an OpenMRS module that allows users to export selected OpenMRS data in the form of FHIR resources. Listed below are the goals, deliverables, project timelines and proposed design for our efforts.

Scope

The scope of phase 01 is limited to the release of v 1.0 of the module, which supports the export of OpenMRS data based on a subset of FHIR resources listed in the deliverables section shown below.

Deliverables

Release of v 1.0 of the OpenMRS FHIR module which supports the following,

1) Export of the following FHIR resources /objects

• Location

• Patient

• Observation

• Composition

• Encounter

• Practitioner

• AllergyIntolerance
  
  Ensure that the FHIR resources are fully valid, and are a complete representation of the associated OpenMRS model objects
  Ensure that the populated FHIR resources are fully validated, as per the DSTU specification
  Based on the search parameters used, the user will be able to export either a single resource, OR a bundle of resources
  
  
  

2) Enable users to search for the aforementioned resources using the following search parameters

• Location ( _id)

• Patient ( _id)

• Observation ( _id)

• Practitioner ( _id)

• Encounter (_id)
  
  
  

3) Expand upon a strategy pattern (already developed) so that users can benefit from semantic information introduced via OpenMRS 2.0 and greater.

The OpenMRS data model is known to be highly generic. Traditionally, allergies, conditions, diagnosis etc. were all stored in the OpenMRS database as observations. However, OpenMRS 2.0 has seen the introduction of more semantically relevant information such as these.

In the event that the FHIR module is used by an OpenMRS application that supports such resources, we need to allow it to leverage from these. However, if it is being used by an pre-OMRS 2.0 version, the legacy approach for retrieving data must be followed.

A strategy pattern will be used for the FHIR module to identify what resources are available to it, and make maximum use of this data.

To demonstrate the success of this effort, we will implement support for the allergy resource, and demonstrate that it can use the OpenMRS 2.0 based allergy api module or (if lesser version) generic obs to populate FHIR resources.

As seen above, the FHIR module may support multiple types of semantic resources such as allergy, condition and diagnosis. Each of these MAY evolve to be represented in multiple ways across different OpenMRS versions. 

At module startup, we will determine the version of the OpenMRS application, identify the relevant OpenMRS strategy for each, and assign it to the FHIR service. This strategy will be used thereon for generating allergy / condition / diagnosis resources for FHIR based export.

4) Export of OpenMRS encounters in the form of FHIR composition resources as follows,

Following a Design call held on the 1st October, it was decide to adopt a bundle based model designed by the TW team to export OpenMRS encounter data in FHIR format. 

This design models an encounter as a bundle of resources. One of these resources is a composition which explains the other resources persisted as part of the bundle.

It was decided to adopt this approach instead of the one proposed earlier, as this approach was self explanatory, and allowed users to understand resource content based on the resources themselves.

A abstract representation of this design would be as follows,

FHIR Representation of an OpenMRS Encounter

FHIR Representation of an OpenMRS Encounter

The above (highly abbreviated) message is a FHIR bundle. It contains (a) a composition resource and (b) other fhir resources that are part of this bundle.

The composition can be considered as a title of contents, and explains what resources the bundle contains.

The above bundle represents an encounter that consists of three observations, a patient, provider and a location resource.

Milestones

Work undertaken as part of phase no. 01 will be broken down into three separate goals. Tasks to be completed under each of these phases are as follows,

• Goal no. 01

Implement the following FHIR resources to export OpenMRS data 

• Location

• Patient

• Observation

• Practitioner

• Encounter

Implement standardized URL's to search for and retrieve one or many of these resources

It is important to understand that the OpenMRS encounter is not similar to the FHIR encounter. The FHIR encounter s designed to represent encounters, visits, episodes of care as well as the duality of clinical vs. technical transactions. And so, its important to determine how OpenMRS reacts to different requests, and what is returned when someone who is not familiar with OpenMRS requests fhir encounter with UUID x.

• Goal no. 02

Integrate these resources together to be able to export OpenMRS data as encounters. This includes the modeling of the encounter resource, bundles and compositions to represent OpenMRS data (as shown above)

Following the implementation of this phase, users will be able to search or / retrieve encounters using specific search parameters, and obtain said result in the form of an OpenMRS Encounter FHIR bundle, as shown above.

• Goal no. 03

1) Implement the FHIR AllergyIntolerance resource, and query parameters to search for and obtain said resources.

Expand upon the strategy pattern for users to follow, and implement support for exporting AllergyIntolerance resources based on this feature.

This includes using the strategy pattern to export OpenMRS data using the legacy allergy pattern and the OpenMRS 2.0 based 

2) Implement authorization / access control for accessing data via FHIR

Timeline

The entire project is estimated to take a total of four months to complete. We breakdown the time considerations for completing each goal as follows,

• Goal no 01 (1.5 months from 1st Dec. to 15th Jan)

• Goal no 02 (1.5 months from 16th Jan to 1st March)

• Goal no 03 (1 month from 1st March to 1st April)