Metadata that cannot be mapped to FHIR resources will have to be pushed/pulled using other means - rest representations. Sync 2.0 slaves will transmit these instances using the OpenMRS REST API.
Sync will need a separate client for sending the metadata - the default will be the client using the REST API. However it should be possible for implementers to inject their own implementation of the interface that will use different protocols.
Based on the data Sync wishes to push/retrieve, it should have an instance of the appropriate client (FHIR/REST). A facade should should be added that is responsible for figuring out the client to use and then using it to retrieve or push the object.
REST Client
The Sync module will maintain a REST client, which will be responsible for converting objects to their OpenMRS representations
Metadata resource list
| No | Entity | Notes | Not required to Sync |
|---|---|---|---|
| 1 | Alert | ||
| 2 | CareSettings | ||
| 3 | Concept (and related classes) | ||
| 4 | GlobalProperty | ||
| 5 | HL7 metadata | ||
| 6 | Order (and related classes) | Although it can be mapped to multiple different FHIR resources, the OpenMRS meaning of the class might be too wide for using FHIR. | |
| 7 | Program | ||
| 8 | Privilege | ||
| 9 | Role | ||
| 10 | User | ||
| 11 | VisitType |