Fine control over upload resources

[joiskash]

Is your feature request related to a problem? Please describe. The download manager allows you to pick and choose what you want to download. The uploader creates a bundle with all the local changes. We would like to have control over which resources get uploaded. Some of the use cases could be :

1. Uploading a patient resource + the references related to it .
2. Breaking up the bulk upload bundle and limiting it to a certain size.

Both these use case are related to the offline use of the app. We have noticed that a 1555477 Bytes bundle takes around 44341ms. This includes 50 Patient resources and 10 to 15 resources per patient. So if this doubles it will be very close to the server time out. Which will result in sync failures. Any subsequent sync will fail.

Describe the solution you'd like Have more control over the resources that are being uploaded.

cc: @jingtang10

[jingtang10]

cc @omarismail94 @aditya-07

[Itskiprotich]

Similar to this, I have a scenario where I'm pulling resources. I.e Encounters referencing other encounters using the Encounter.partOf. The challenge comes in when only the observations for the parent Encounter are pulled while the other Encounters have blank observations. Any workaround on this? Thanks

[kumaakh]

I think the idea of bundle comes because of referntial integrity, the server would reject resources which refer non-existing reseources, putting them in a bundle makes it a all-or-none approach. So what is required is an ability to create smaller bundles, as small as containing single resource.

For upload sync, we should provide a way for application to sync resources by walking a reference tree, the most independent resources should be synced first and dependent once later, with the finer control we will not be hitting server timeouts in LMIC context

[kumaakh]

@jjtswan

[joiskash]

Update on sync -

• We have an app running fhir engine with a feature to create fake patients with fake resources. Each fake patient creation, through pre filled questionnaires and extraction results in one Patient resource and 46 other related resources.

• We came across an OOM while uploading many unsynced resources . Approx 300 patients = 300 * 46 = 13800 FHIR resources. The OOM occurs when parsing json payload.

• We modified upload to group together 10 resources at a time for upload.

[aditya-07]

Based on the discussion between @jingtang10 @joiskash @aditya-07, providing a way for the application to specify the number of resources in each Bundle would solve the problem.