# Sync 2.0 Planning

**URL:** <https://talk.openmrs.org/t/sync-2-0-planning/11799>\
**Category:** Development\
**Tags:** sync2\
**Created:** [June 8, 2017, 2:33pm UTC](https://talk.openmrs.org/t/sync-2-0-planning/11799 "2017-06-08T14:33:04Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![pgesek](https://talk.openmrs.org/user_avatar/talk.openmrs.org/pgesek/32/5053_2.png) [@pgesek](https://talk.openmrs.org/u/pgesek)\
**Post date:** [June 8, 2017, 2:33pm UTC](https://talk.openmrs.org/t/sync-2-0-planning/11799/1 "2017-06-08T14:33:05Z")

</div>

Hello everyone,

@raff and I are happy to announce that SolDevelo will be starting work on the **Sync 2.0** project, which will aim to be a FHIR based replacement for the existing Sync 1.0 module. We are excited and looking forward towards starting work on this project, as it aims to solve real issues that OpenMRS implementations have faced when using the current version of Sync.

We are looking for implementations that are interested in using the new Sync module and willing to commit to early adoption and testing of the module. We are also interested to hear from anyone that has used Sync 1.0 about their workflows and the challenges they faced when using it, so that we can solve these issues with the design for version 2.0. If you are in any way interested in Sync 2.0, feel free to reach out to us in this thread!

## Sync 2.0 Project Description

* * *

**Initial Statement:** Replacement for openmrs sync module based on FHIR (as much as possible) and atom feeds - LOE: 6+ months - Customers: of interest to many existing OpenMRS implementations (many are desperate for a usable & reliable sync solution)

**Specific Project:** Support master-slave synchronization of multiple OpenMRS servers in one enterprise, where most (technical) management is done at a central site, but patients are seen at many clinics in a hospital network.

**Technical Approach:**

- one Master OpenMRS server, and multiple Slave OpenMRS servers.
- Master defines all metadata and configuration (and slaves synchronize this).
- Slaves synchronize a subset of patients with Master (e.g. those in the catchment area of one clinic) and push data on these patients
- Slaves initiate all synchronization, based on:
  - reading an atom feed published by Master, pulling more data for any events of interest
  - pushing data that is entered on the Slave

**Project Breakdown:**

There are several independently-useful parts of this project that can be done before pulling everything together.

1. Publish an event feed from OpenMRS

- can leverage existing ICT4H and Bahmni code for this

1. Update the OpenMRS FHIR module
  - Update from DSTU2 to STU3 (released April 2017)
  - Refactor module to be more extensible \* support for plugging in processors & resources \* use a Strategy Pattern, and extract current hardcoded implementations as “default strategy” \* Ensure we can import/export all relevant OpenMRS transactional data

2. Implement one-way sync of domain objects that can’t be fully represented using FHIR (e.g. some kinds of metadata)
  - ThoughtWorks wrote a module for Bangladesh that synchronizes concepts; may be ready to use as-is

3. Mechanism to define patient subsets / catchment areas for subcenters We already know of some implementation strategies from existing research done by Bahmni More requirements gathering to see if those strategies miss any high-value use case
4. Pull all of this together into the Sync solution

Thanks, Paweł

---

_[View the full topic](https://talk.openmrs.org/t/sync-2-0-planning/11799)._