FHIR DSTU3 will be the primary method of data transfer between the slave and master nodes in a Sync network. Wherever possible we should default to using FHIR representations and rely on other methods only if OpenMRS objects cannot be represented using FHIR resources. Atom feeds used by Sync should point to FHIR urls for resources that are transmitted using FHIR.
The OpenMRS FHIR module will be extended to server both as a client and server that will be leveraged by Sync to create and read FHIR representations that will be used in pushing or pulling data. The FHIR services from the module will also be used by Sync to persist FHIR representations it retrieves from master. Overall the module will be used in 3 ways in Sync:
1) On the master - as the server that receives data pushed from slaves
2) As a client - on slaves to both retrieve data from events published on master, but also in their own atom feed. It will also be used to push data to master.
3) As services to persist FHIR representations - on slaves that retrieve FHIR resources from master and need to persist them in OpenMRS.
This is a list of domain objects that implement BaseOpenmrsData that we want to synchronize between OpenMRS servers. While we want to use FHIR as much as we can, it might come up that for some objects we will have to implement a different Sync protocol.
|No||OpenMRS Entity||FHIR Resource||FHIR Maturity|
|4||Visit||List of encounters can be considered: https://www.hl7.org/fhir/list.html|
|10||Order||FHIR Nutrition Order and MedicationRequest can be considered, but orders have a broader sense in OpenMRS.|