Households without members are not synced down (from the server) correctly

[dubdabasoduba]

Problem Description

We currently use the sync_config.json file to define how search is done when querying the server for data. We have three ways of defining the household search, but all three have risks of not syncing down data.
For example,

Option 1

{"resource":{"resourceType":"SearchParameter","name":"organization","code":"managing-entity.patient.organization","base":["Group"],"type":"token","expression":"#organization"}}

• This will fail if the HH has no assigned HH Head.

Option 2,

{"resource":{"resourceType":"SearchParameter","name":"organization","code":"managing-entity","base":["Group"],"type":"token","expression":"#organization"}}

• This will fail if the HH head is assigned

Option 3

{"resource":{"resourceType":"SearchParameter","name":"organization","code":"member.organization","base":["Group"],"type":"token","expression":"#organization"}}

• This will fail if the HH does not have HH members added.

Additionally, we cannot define all three options at the same time because the definition is executed as an AND instead of an OR.

Risks

The risks posed by this problem include the possibility that some required data is not synced to the app, and the introduction of a new point of data duplication. Since some HHs are not synced down, users may end up creating new HHs to add their members, which means the server will have multiple Group resources representing the same HH. This problem will manifest while writing reports that require checking for active Group resources representing HHs.

Possible Solutions

Option A

Wait for the Gateway server to be fully tested and switch the apps to that.

Pros

• We don't need to change anything on the apps since the Gateway sync depends on a different attribute.

Cons

• Project releases are at risk if the Gateway server is delayed by bug fixes from QA.

Option B

Update how we reference the HH head on the Group resource by adding the reference to the Group.Characteristics and leaving the managingEntity for the Practitioner Organization Reference. This means we also have to update some code that supports the Change HH Head functionality. Update the sync_config.json to use Option 2 on the sync types.

Pros

• We do not lose or duplicate data in case we don't use the Gateway for the deployments.

Cons

• We have to redo some work on the apps and run QA after the changes.

[pld]

I edited the solutions to be labelled by letters so they don't conflict w/the problem description options

[dubdabasoduba]

We decided to use Option 3 for search parameters and communicate to the QA and external teams that every HH will need at least 1 HH member otherwise the risks above apply.