Sync 2.0

Subpages:

• Adding event handler step by step
• Atomfeed for Sync 2.0
• Auditing and error handling
• Catchment Strategies
• Changes to the FHIR module
• Conflict detection and resolution
• FHIR Resource List for Sync
• Implementing communication client step by step
• Manual synchronization of selected records
• Non-FHIR resource list for Sync
• Sync 2.0 - Observations' synchronization (supported fields)
• Sync 2.0 - Relationship mapping (supported fields)
• Sync 2.0 - supporting 1.x versions of the OpenMRS platform
• Sync 2.0 - The Location's synchronization
• Sync 2.0 - The Patient's synchronization (supported fields)
• Sync 2.0 - The Person's synchronization (supported fields)
• Sync 2.0 - The Provider's synchronization (supported fields)
• Sync 2.0 Architecture Overview
• Sync 2.0 configuration variables
• Sync 2.0 Demo Environment
• Sync 2.0 Roadmap
• Sync 2.0 user manual

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 parent-child 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 Parent OpenMRS server, and multiple Child OpenMRS servers.
• Parent defines all metadata and configuration (and children synchronize this).
• Children synchronize a subset of patients with Parent (e.g. those in the catchment area of one clinic) and push data on these patients
• Children initiate all synchronization, based on:
  • reading an atom feed published by Parent, pulling more data for any events of interest
  • pushing data that is entered on the Child

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
2. 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
3. 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
4. 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
5. Pull all of this together into the Sync solution

Short term goals:

1. FHIR/Sync module extensions to support additional entities
2. More control over the synchronization process, manual synchronization
3. Conflict resolution
4. Support for OpenMRS 1.X
5. Extensibility support to work with central repositories that are not OpenMRS - a MasterPatient Index, an SHR server and so on
6. Deploy Sync 2.0with partner implementations for beta testing and react to their feedback - fix bugs, extend features,make sure Sync 2.0 is ready for a production environment

More details you can find in Scope of Work

Milestone progress:

1. FHIR/Sync module extensions to support additional entities
2. More control over the synchronization process, manual synchronization
3. Conflict resolution
4. Support for OpenMRS 1.X
5. Extensibility support to work with central repositories that are not OpenMRS - a MasterPatient Index, an SHR server and so on

Team :

Digital Square and Soldevelo :

1. Amanda BenDor (abendor@path.org) - Product Owner
2.  Solomon Simba (sSimba@path.org) - QA
3. Kamil Madej - Technical Leader
4. Arkadiusz Lalo - Developer
5. Wojciech Buława - Developer
6. Rafał Stencel - Developer
7. Tomasz Mueller - QA

Demo servers:

• https://sync1.openmrs.org/openmrs

• https://sync2.openmrs.org/openmrs

• https://sync3.openmrs.org/openmrs

• https://sync4.openmrs.org/openmrs

Legacy OpenMRS demo servers: 

• https://sync-legacy1.openmrs.org/openmrs
• https://sync-legacy2.openmrs.org/openmrs

Github repositories:

• https://github.com/openmrs/openmrs-module-sync2

• https://github.com/openmrs/openmrs-module-atomfeed

• https://github.com/openmrs/openmrs-module-fhir

Tracking progress:

1. JIRA reports
2.  Scope of releases
3.  Active sprint
4. Releases
5. Showcase videos
6. Sprint announcements
7. Sprint reviews

Sync 2.0 will use atom feeds for notifications on what needs to be synchronized. More on the approach: Atomfeed for Sync 2.0

Changes required to the FHIR module: Changes to the FHIR module

Architecture of the module is available here: Sync 2.0 Architecture Overview

Dealing with errors and keeping an audit log: Auditing and error handling

Methods of transferring objects: FHIR Resource List for Sync, Non-FHIR resource list for Sync

Conflict detection and resolution: Conflict detection

Catchment strategies: Catchment strategies

Manual synchronization of selected records: Manual synchronization of selected records