Thanks @pgesek I was just wondering whether there was an update on this. 
Comments about “Atomfeed for Sync 2.0”:
- If we’re going to refactor this, maybe we can move away from having a lot of global properties, and instead just have a single feed config that an implementation can specify with a json or yaml file
- I like the idea of using an event-based hibernate interceptor instead of an advice class for every OpenMRS class
- “Change the default urls to point to FHIR resources” => I would hope that Sync 2.0 can also be run with Bahmni, so I hope there’s a way that a single set of feeds can work for both master-slave sync, and Bahmni’s MRS/ERP/LIS communication. Maybe we can introduce a new format where we provide multiple possible links to the event, e.g. both the FHIR one and the REST one.
Comments about “Auditing and error handling”:
- I wonder if this is going to be an excessive amount of data to be storing
- It feels more natural to log this to a file (at least for successful sync) rather than to a DB table
- PIH Rwanda found that for admin/management purposes it’s really valuable to synchronize status data about each slave up to the master, so that some level of system debugging can be done centrally
“Catchment Strategies”:
- I guess we should get some feedback from potential implementations about what are the right strategies to focus on
“FHIR Resource List for Sync”
- Naively I would think Drug => Medication (instead of Substance)
- Some of these may be very imperfect matches, and after analysis we might end up wanting to do some of these via OpenMRS REST representations.
- There’s definitely a prioritization to be done here. E.g. some implementation might start using sync with just
patient. Others would use it if you add visit, encounter, and obs. Etc.
(I will try to comment on the rest of the pages tomorrow, but I’ll post this now, in case I get delayed on the rest.)