(Wyclif this is in fact the same talk thread that you linked to.)
I’m going to make an executive decision on these points. Since there is no continuity of the codebase or design, and no intention for compatibility between this and the old sync:
New repository (or repositories) for this codebase
New JIRA project (or projects)
Note that the design envisions multiple collaborating components, that may also be reused outside of Sync, so I would expect that we’ll actually create multiple repositories, and multiple JIRA projects. (I do expect that there will be at least an openmrs-module-sync2 repo and a “Sync 2” JIRA project, and you might be able to build a sprint board within this JIRA project. Though I expect you will need to base the sprint board on a “sync2” label because you’re going to have tickets in multiple JIRA projects.)
Currently, we’re still preparing the environment for Sync 2.0 module. More precisely, we need Atomfeed and FHIR module. Our first step is to make these modules to be more generic, fix and implement some part of FHIR logic. Next, we’re going to start to implement Sync 2.0 logic. At first, this module will support only 2.0.X OpenMRS version.
We’ll have asked about some OpenMRS -> FHIR mappings in next week because not all exist and we’ll like to implement them.
When we’ll start implementing concrete Sync logic, it would be great if any org that use OpenMRS 2.0.X+ will be interested to use Sync 2.0 and giving us feedback about this. This should help us focus our results and meet user expectations.
It looks like the Parent-Child relationship would assume that there is only one server that a child would sync from? What about the case of an independent Client Registry that is FHIR compliant? Would you sync the non-patient resources with the parent and then (for both the parent and children) sync patient resources with the Client Registry? (Same question for a Facility Registry or Health Worker Registry using mCSD). tl;dr you may want to have the option to have multiple FHIR servers for syncing different resources.
As an FYI, there is an OpenHIM FHIR sync meditator (STU3) for practitioners https://github.com/openhie/openhim-mediator-fhir-sync which maybe could be extended to help manage your FHIR sync process(es) by providing a nice UI for periodicity of syncs and providing audit logs (e.g. ATNA). Not sure if @rcrichton knows of any similar mediators already in existence.
@raff@dkayiwa Yes we are looking to be able to bring data from different facility level installations together in a single location, hence keeping an eye on this project. Initially we tried Sync 1.0 which did not work too well
@raff yes I would like a working sync module on 2.x, I’m currently stuck on 1.9.8 as it is the last version the sync module works without major problems, and will not update to more recent versions as they don’t support it, and it is critical to my implementations.
@aramirez would you be able to test out this new Sync 2.0 work, over the course of the next 2 months, and provide feedback?
This doesn’t have to be on production data (obviously it wouldn’t be as you can’t upgrade until you have a working sync on 2.x) but you and/or your team would need to spend the time/resources to test out the new sync modules against an upgraded copy of your implementation.
@ssmusoke, @slubwama, @jmpango, are you in a position to test out this new sync code across a small number of facilities, and provide feedback and/or bug reports?
And could you do this within the next couple months?