search

opensrp / fhircore

FHIR Core / OpenSRP 2 is a Kotlin application for delivering offline-capable, mobile-first healthcare project implementations from local community to national and international scale using FHIR and WHO Smart Guidelines on Android.
https://smartregister.org
Apache License 2.0
50 stars 39 forks source link

CHW/ANC - Allow for P2P Sync #281

Closed f-odhiambo closed 2 years ago

f-odhiambo commented 3 years ago

P2P sync is an essential component of the Liberia CHW app. Given that CHWs are always offline, P2P sync is the only way to get data to the server. There is no viable solution in that environment without functional P2P sync.

The P2P sync is primarily used on the monthly supervision visits conducted by the CHW supervisors (CHSSs). The CHSS is tasked with visiting each of their CHWs once a month. During this visit, they will bump all data off of their CHW’s device onto their own. Then, once a month, the CHSS will bump data to a district health officer (DHO) for them to sync to the server.

  1. CHW syncs data to their CHSS (CHSS has full permissions to view)
  2. CHSS syncs data to a DHO (DHO has full permissions to view)
  3. CHW syncs data to another CHW (CHW cannot view data)
  4. CHW syncs their data + another CHW’s data to their shared CHSS (CHSS has full permissions to view)
  5. At the moment there is no real use case to sync data back down the chain of supervision

In our current implementation, we also allow CHWs to bump data between devices because there are use cases where one may not be able to reach a CHSS as reliably. In this case, a CHW will store that data on their device but not be able to interact with it (as the patients are not a part of their catchment).

These workflows introduce some complexity in terms of permissions and editing. For example, in Liberia, we consider the data on the CHW’s device to be the source of truth. Therefore, CHSS’s, though they can access all patient data, are not to edit those records. And if they do, at sync, the CHW’s record will trump. We may explore solutions upstream via restrictions in the app, but it is important to note the potential impact of P2P sync on sync.

Some tasks

Acceptance Criteria This should cover cases such as

bausmeier commented 2 years ago

Based on the approach outlined in the related discussion and doc, this is the set of tasks which Trevor and I will be working on:

bausmeier commented 2 years ago

Collating some of the relevant links:

GitHub issues and discussions:

Android FHIR SDK server sync implementation:

OpenSRP Android P2P Sync:

GSoC findings and demos:

Past meeting notes:

bausmeier commented 2 years ago

@f-odhiambo On one of the calls the other day we talked about how the permissions part of this issue is a large and complex piece of work which should rather be tackled on its own. Could we split that part out into a new issue so that this one focuses only on the P2P sync part? Or maybe we could just note in the description that it's out of scope for this piece?

f-odhiambo commented 2 years ago

@f-odhiambo On one of the calls the other day we talked about how the permissions part of this issue is a large and complex piece of work which should rather be tackled on its own. Could we split that part out into a new issue so that this one focuses only on the P2P sync part? Or maybe we could just note in the description that it's out of scope for this piece?

@bausmeier I think I can note andalso create a Discussion board around it . Ill follow up on this

pld commented 2 years ago

For the UI components, let's discuss w/Roger before we start any work on this, I think we'll want to have him design it out a bit first

bausmeier commented 2 years ago

Will do. I think we'll need input from some others on the UI aspect, and how best to implement it to. I'm planning on setting up some time to chat about this.

jingtang10 commented 2 years ago

Discussed with @bausmeier + @trevorgowing this morning and drew this diagram to represent the data flow:

Screen Shot 2021-11-29 at 13 03 55

@f-odhiambo @pld does this represent the use case correctly?

pld commented 2 years ago

My understanding is that this represents the most complex scenario we've encountered so far. We also have cases with no DHO, i.e. the CHSSs have connectivity and connect directly to the server.

@AnnieMungai what types of configurations do you think we'll see in the Liberia project?

@rowo does this cover the campaigns use-case, or are there other use-cases we'll need to support in the next year you can think of that this does not cover?

jingtang10 commented 2 years ago

Thanks @pld. The most important thing for the SDK support here is that there will be 2 types of nodes

  1. CHWs and CHSSs where all changes are synced via P2P
  2. DHOs (or the CHSSs when there is no DHOs) where it has P2P with downstream nodes but also uses FHIR RESTful API to sync with server
AnnieMungai commented 2 years ago

@pld currently any user can be able to sync data from any other user as above mentioned and also be able to sync data online.

  1. CHA >> CHA >> CHSS >> DHO >> Server
  2. CHA >> CHSS >> DHO >> Server
  3. CHA >> CHSS >> CHSS>> Server
  4. CHSS >> CHSS >> Server
  5. CHSS >> Server
  6. CHA >> Server (this is rare but happens for users who have a rare connection to the internet) cc @dubdabasoduba @paulinembabu

(edit: Numbered the configurations for easier referencing)

bausmeier commented 2 years ago

@jingtang10 Does any user being able to sync to the server invalidate the approach we had in mind? I think that 1-5 should still be workable individually, but the combination of CHAs being able to sync with one another (1) and also being able to sync to the server (6) might be a problem. I can imagine that CHSS >> CHSS could also complicate things quite a lot.

pld commented 2 years ago

mvp complete, closing