...

• sync operates on a spoke and hub model (parent server with children)
  • each child needs to initiated with a copy of the parent server's DB
    • this was done through database dumping
    • an alternate option to consider is to copy the mysql files instead of importing/exporting the DB, in order to save import/export time
  • any way to not start out with clones and have some kind of merge done?
    • short answer is no since the records would need to be reconciled
    • the key to doing that successfully is to be able to match up UUIDs, which is a non-trivial task
  • registration is done between the child to parent and parent to children
    • parent server and child servers have a static IP
      • it may be possible to use a dynamic DNS (DDNS) service (e.g. no-ip.org, dyndns.com) to get around this
  • sync process always runs on the child; configured to contact the parent server on a regular basis
    • can we use the parent server as the operational server?
      • yes, this is how it is currently used in PIH Rwanda
      • is there a performance impact?
        • none observed so far
• configurable settings
  • the amount of time when the child contacts the parent
  • timeout for when the child should stop contacting the parent
  • maximum number of tries for the child to reach the parent
  • whether sync'ed data is compressed or not (which is run through the openmrs configuration which can optionally be gzip)
  • the class of data to be sync'ed
  • at the technical level, it is sync'ing at the level of db tables
    • not able to sync subsets of patients, but this is a feature we'd like to implement in the future
• prerequisites
  • did we need to beef up our servers for the sync?
    • no, we have our servers running on off the shelf laptops with 3GB of RAM
  • had issues with the servers not being on proper UPS (we used laptops)
    • mysql databases can get corrupted if power is lost in the middle of a transaction
  • what about network firewall considerations?
    • this is done via HTTP post, so either port 80 (HTTP) or 443 (HTTPS)

...

• • bandwidth
    • our sites are on VSAT and performance has been fine even with all of the outages that we have. sometimes the bandwidth is 1kbps or less.
      • how long do we need to have something up and running in order for the sync'ing to work?
        • dependent on bandwidth, but from our experience, sending 200 records at a time, it takes about 5 minutes to sync
      • this can even be sync'ed via USB key
        • and there won't be duplicates even if it is manually sync'ed by USB and afterwards, the network is restored
      • we will be piloting this on GPRS modems; the issue is not bandwidth, but rather having fixed IP addresses on the children (that are using the modem)
        • however, this may be overcome by using a DDNS service (see above)

functional questions

• still able to do updates on both the parent and the child?_
  • yes
• what is the format of what is being sent?
  • xml (serialized java objects)
    • can the XML be consumed by other services?
      • probably possible
• is it possible to have grandparents? i.e. multiple layers of syncing between children and the parent?
  • theoretically it could be possible
  • sync was built to be a child to parent relationship, where each node will communicate to a parent (if it exists) and its children (if they exist); children don't know about each other.
  • is there any thought about doing a peer-to-peer relationship rather than a hierarchical relationship?
    • this might be something to consider in the future
    • (a concern was raised by an audience member): not sure if this should be perceived as a solution for a national reporting system built off of (child) districts and (grandchild) clinics because of data access/privacy concerns; DIHS should be used instead
    • filtering might help to alleviate this challenge
• complex obs files able to be sync'ed?
  • may not be possible to do at the current time since it would require so much bandwidth to do
• 2 vs. 1 way sync
  • it is possible to use the sync module as an info path alternative (in a one directional way)

...