Sync 2.0 aims to use FHIR to achieve synchronization between a network of nodes. It assumes one Parent node and multiple Child nodes connected to the Parent. Each child can also act as a Parent, which allows a multi-level Sync network. In this topology, the synchronization can be done in two directions: Parent to Child and Child to Parent. Sync 2.0 will support both independently, as one-way sync is being used in the field currently by implementations adopting Sync 1.0. In both models the methods of communication will be generally the same - an atom feed will be read, then data will be retrieved and pushed, preferably using FHIR. If FHIR representations are not available for resources being transmitted, we will fall back to OpenMRS REST representations.
All synchronization will be initiated by the Childre, independent from the direction that data is transmitted.
...
Children will be reading the feed exposed by their Parent, event by event. The Parent will expose a complete feed of events - Children will be in charge of filtering and pulling only the resources they are interested in. When they come across an event that they interpret as requiring synchronization, they will trigger retrieval of the object using the client facaderesource manager, which will deal with retrieving the object using the correct method of transmission based on the data type - either by delegating to a FHIR client, a REST client or a different client injected by implementation.
The data retrieved through FHIR, will then have to be passed to the FHIR module for saving. FHIR services from the module (example https://github.com/openmrs/openmrs-module-fhir/blob/master/api/src/main/java/org/openmrs/module/fhir/api/impl/PatientServiceImpl.java) will be capable of saving FHIR representations in OpenMRS, so Sync will only need to make use of these services and won't have to convert FHIR to OpenMRS on its own.
...
The diagram below illustrates a general overview of the Sync module architecture. Note that components might be simplified and in the real implementation split into multiple pieces. It is shown from the more interesting perspective of a Child. Note that each Child can also act as a Sync Parent.
- Architecture of pull workflow
| Gliffy | ||||
|---|---|---|---|---|
|
- Architecture of push workflow
| Gliffy | ||||
|---|---|---|---|---|
|
Things to note:
- Each Child can also act as a Parent
- A sync module has two feed reader instances - the local feed reader and the Parent feed reader. The local feed reader is reading the local feed and triggers a push to Parent. The Parent feed reader reads the Parent feed and triggers a pull from Parent.
- SyncPushService and SyncPullService put together the business logic for pushing and pulling
- The SyncAuditLogger is responsible for maintaining an audit of Sync operations in the database
- The ClientFacade SyncResourceManager delegates to either the FHIR client or a REST client, based on the data type and whether a FHIR method is possible. The underlying transfer operation should be transparent to clients.
- SyncPullService uses either FHIR services from the FHIR module or database persistence to save the data locally
...