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
- Differences between the releases: https://www.hl7.org/fhir/diff.html
- Transforms between DSTU 2 and STU 3 (in FHIR mapping language): https://www.hl7.org/fhir/r2maps.html
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?)
- 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
- Changing to STU3 is a good opportunity to update the lib version
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.
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.