Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
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:
Support plugging in resources and processors
Ensure we can import/export all relevant OpenMRS transcational data
Consider updating hapi FHIR version from 2.4 to most recent version 2.5
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.