Changes to the FHIR module

Owned by Paweł Gesek
Last updated: Jan 18, 2019 by Tomasz Mueller
3 min read

As part of the effort to develop Sync 2.0, several enhancements will have to be made to the OpenMRS FHIR module in order to create a fully functional sync solution that is based on FHIR.

Update from DSTU 2 to STU 3

 

Implement strategy pattern in the FHIR module:

  • FHIR Strategy Pattern
  • Currently the strategy pattern is implemented for Allergies, Appointments, Conditions, Encounters, Groups, Locations, Medications, MedicationRequests, Obs, Patients, Persons, PlanDefinitions, Practitioners, ProcedureRequests, RelatedPersons
  • Follow the existing code patterns when extending other resources to support the strategy pattern
  • Is the org.openmrs.module.fhir.strategy package used, or legacy and for removal?


Support plugging in resources and processors

  • FHIRRESTServer should be extended with a mechanism to pull in additional FHIR resource providers
  • Potential solution: the FHIR module can expose a service that will allow registration and deregistration of resource providers (should we allow to deregister the default ones?)
    • This service should also allow for registering Interceptors, Narrative Generators (others?) with the server
    • The service should allow listing the currently configured providers, interceptors, etc.
  • Currently it is possible to configure a Thymeleaf based narrative generator provided  by HAPI through OpenMRS global properties

 

Ensure we can import/export all relevant OpenMRS transcational data

 

Consider updating hapi FHIR version from 2.4 to most recent version 2.5


FHIR client

Sync will need to read the feed and use a FHIR client for reading the objects which are posted as events in the feed. A FHIR client implementation capable of sending and retrieving data will have to be added

to the OpenMRS fhir module. Creating a FHIR client using the HAPI library is described here: http://hapifhir.io/doc_rest_client.html

 

There already exists a simple implementation of the FHIR client in the OpenMRS module, however it is fairly limited current and does not do any mapping to OpenMRS classes. It will have to be extended or an additional client class should be added.


The FHIR client will interface with the FHIR server running on the Parent node. The client, same as the server, should be extensible through a strategy pattern - the client should use the same strategies the server uses to map FHIR object to OpenMRS

classes and vice-versa (although it should be possible to override by setting custom strategy implementation on the object).

 

The FHIR module should expose a factory for building client instances - this should allow retrieving a client that uses the server-wide strategies and then replacing them based on usage. These client instances could then be used against different servers.


It is worth noting that Sync Children will be reading  their own feed and 'retrieving' data from themselves using FHIR. This data should be fetched from services in the FHIR module (since these services will now be used in different contexts, renaming them with the FHIR prefix should be considered). The representations returned by the services will then be forwarded to FHIR server on a Parent.


Integration testing

Since Sync will be using both the FHIR client and the FHIR server, it is crucial that these elements remain functional and compatible. Integrations tests should be added that execute the FHIR endpoints using the FHIR client. This should give us confidence in the FHIR module and should emulate how it is being used by the Sync module.