Sync 2.0 Planning

(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:

  1. New repository (or repositories) for this codebase
  2. 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.)

Here is how you request a JIRA project: https://help.openmrs.org/customer/en/portal/articles/1439079-requesting-a-jira-project

For requesting a new code repository under the OpenMRS org, see https://wiki.openmrs.org/display/docs/Code+Repositories (the short answer is that you should write a new post in the #dev:repo-management category saying specifically what you want).

(If you’re new to this project and not 100% sure what details to put in, I can help figure that out.)

1 Like

PS- Welcome @pkornowski, @alalo, and @dserkowski, and thanks as always to SolDevelo!

This project is going to be very valuable, and I’m really looking forward to seeing it happen.

Hi,

we asked for repositories for Sync2 and atomfeed. Do we need to create a separate project on JIRA for the atomfeed repo or use the only Sync2?

Best regards, Przemyslaw

I would say have them separate

Okay, so I will create a new help desk case for this project, thank you for the reply.

Hi Everyone, we’ve started with implementation. Referring to this, we have one question.

Would be nice to do so

@pkornowski is there anything else that we need? Are there any blockers for the development?

@jslawinski

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.

  1. We’ll have asked about some OpenMRS -> FHIR mappings in next week because not all exist and we’ll like to implement them.

  2. 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.

Best regards,

Przemyslaw

@pkornowski @raff @burke It is crucial to find an interested orgs rather sooner than later.

A few thoughts/questions:

  • some of the sync resources (Location, Provider) are covered by mCSD (an IHE profile of FHIR being supported by OpenHIE). See https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mCSD.pdf
  • 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.

Cheers,

-carl

@litlfred thank you!

@pgesek @pkornowski it is worth to see Carl’s thoughts/questions.

@mksd, @ssmusoke, @aramirez, @acano15 would any of you be interested in a sync solution running on openmrs-platform 2.x+?

@raff Yes, the latest version of UgandaEMR is now running on Platform 2.0.5+, so any work with sync will be on 2.x

@ssmusoke he is asking for real commitment to dedicate resources to try and roll it out. :slight_smile:

Putting it in other words, the Soldevelo team likes to work on something that real implementations are going to actually use in real life.

@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

@slubwama and @jmpango do add your voice here

@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?

@darius Yes we are willing to test it out during the following months.