How do we build an app from the Single APK approach

[f-odhiambo]

For the Single APK approach, assuming we would want to produce an app for the different clients/products that we are building i.e. G6PD, mADX, Covax, ANC. Do we either

• Have a single code repo with multiple code branches that will reproduce the different applications
• Have multiple repositories for different projects
• Have the configuration for the product flavours synced from the build Gradle e.g https://github.com/opensrp/opensrp-client-chw/blob/master/opensrp-chw/build.gradle
• Have Server side config synced and loaded to the app upon login and generate the different UI/Workflows
  cc. @pld

[pld]

The last option, single apk, single app -- configs determine the product

[f-odhiambo]

Some notes here:

1. The base app should be a skeleton that will be receiving configs synced from the server ( HAPI FHIR server? Could be the Workflow server API on SDK? ) that will be used to reproduce the different workflows for a specific use case e.g. ANC
2. What does the base app contain?

Configurable

• Login/Logout
• Register
• Patient list
• Patient profile
• Sync

3. What will be the structure of the configuration and the sync mechanism to load them to the application?
4. What functionality will be needed to be built to be able to perform a configuration task?
5. How do we perform styling changes on the app? XML <-> JSON update and sync from serverside for minor/major customizations

[pld]

For (3) the immediate option I see is tying these to the users role and syncing on login. If I'm a user with a covax role on first login it syncs down the fhir configurations for the roles I'm assigned, so the vax user profile view, the vax list view -- then it syncs the patients in my catchment area.

I feel pretty strongly we should push ALL configuration into FHIR files so that we can use it for syncing, including feature flags. I don't see the benefit of a separate configuration method that requires us to do another sync. If this means we have to use resources in unintended ways, like serialize a config, load it into a library resource and deserialize it on download, that is fine, we can built custom/unballoted resources overtime to move towards standard for all this later.

[ndegwamartin]

@pld @f-odhiambo i've enabled Discussions for fhir core. We can explore using it for discussions and only create Github issues when we have tasks. Let me know what you think

[ndegwamartin]

P.S. discussions can be converted to issues and vice versa

[ndegwamartin]

Maybe we can investigate using the HL7 FHIR - Basic Resource for the various types of configurations we want to sync

[f-odhiambo]

Some input from a discussion held 28th June 2021

1. What will be the structure of the Configuration files? HL7 FHIR - Basic Resource?
2. What FHIR resources do we need to work with to achieve this
3. WHO Smartguildlines workflow API being worked on on the SDK.
4. Configurable views
5. RBAC based on Facility worker creds
6. Test implementation for Covax as a POC

Action points

1. @f-odhiambo to create a doc and share with @pld for further edits and then organise the bigger discussions with the entire group

[owais-vd]

As I understood we will be using the file system in a private context to save all the configurations and files and if so then what about the validity of configs like when User A will try to login then all the config and files will be downloaded during the authentication but what happens of the User A config and files when user try to logout or some other type of user will try to login. will we delete the configs and files of the previous user?

[f-odhiambo]

I think we envision a scenario where we just need to look at your credentials and load the workflow as defined in your profile and once you log out we need not care/store the workflow. One insight here though is that as we switch context we need to make sure any unsynced data is stored or synced regardless of the person using the app. Looking forward to some thoughts on this :)

[owais-vd]

load the workflow as defined in your profile could you elaborate some more detail about what is and what kind of workflows.

One insight here though is that as we switch context we need to make sure any unsynced data is stored or synced regardless of the person using the app. is that something like user can't be able to logout until he synced all the data to server.

[f-odhiambo]

On the 1st query, If facility worker at Covid vaccination centre, the app should be able to configure the app to use the coax registration questionnaire, configure the list view to have patient data and record vaccine, in the profile view show registration details and vaccination history. In the case of ANC, Enroll the head of household plus family members, for profile view show family details etc.

On the 2nd query, I think any unsynced data should be persisted, give notification to currently logged user.
Based on the current OpenSRP apps, they will still be able to log out. However, for projects such as reveal, we have set indicators that show when there is unsynced data. There is a red bubble that appears on the app.

[f-odhiambo]

@syed It's also noteworthy that, in the current OpenSRP use cease, If the user is in the same team, the data will remain on the device. However, for a user from a different team logs in the data is cleated and unsynced data will be lost. Users are educated to always sync before logging out. I don't think we want the same approach in FHIRCore unless advised other wise

[pld]

On sync, if we're encrypting it, can we safely keep it on the device?

Avoiding data loss needs to be a key feature, if logging out result in data loss we need to let the user know this before hand and get confirmation they want to proceed

[owais-vd]

@f-odhiambo correct me if I'm wrong. The configuration syncing process will look like something below steps.

1. User A being authenticated to their credentials.
2. If the authenticated user has a different team then all the data will be cleared from the DB.
3. We will use access_token to get the list of Basic Resource as configuration from the server. The list could be a JSON array
4. We will use the subject to get the resource URL in the basic resource as we have a list of basic resources.
5. Then download all the resource files from the server separately.
6. Save all the download resource files as JSON in the app-specific private folder.
7. Finally the user will be moved to PatientListActivity

[f-odhiambo]

Looks ok to me at a first glance. On 2, I think the data being cleared is the configuration but not patient-specific data. We can chat more about the reminder of the implementation

[pld]

On (3) I'm not convinced this should be via Basic resources

[pld]

Also I don't agree w/4-6, why do we need a separate sync process? Can't we use the built-in sync?

[pld]

To reiterate the idea is that these are all FHIR resources, and we already have a method to sync FHIR resources, so let's use that not a separate sync process

[pld]

Also note that we'll want to be able to do some configuration before the user logs in. We'll want to be able to vary the logo and name on the login screen through pre-login config and asset downloads

[pld]

We'll also want to set the URI for the remote HAPI FHIR server