Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Data Requesting

[dubdabasoduba]

How will FHIR Core fetch data from the remote server?

Context

• For the Permission and RBAC(Role Based Access Control) pieces to kick in FHIR Core needs to request for data from the
  remote server.
• Currently, FHIR Core hits each endpoint for each resource type defined on the sync_config.json
• FHIR Core has 2 types of data sets. These are
  • Non-Patient based data sets
  • Patient-based data sets.

Data fetch mechanism

Non-Patient based data sets

• This is data used by the application for configuration and other kinds of display purposes.
• The configuration pieces of the data are handled by the Composition Resource. The data is referenced in the section
  key of the Composition Resource.
• Data required for other display purposes is not tagged by the user assignments. This means the user assignment data
  filtering workflow would not work. Here we will use the nested section key of the Composition Resource. E.g

{
  "title": "Commodity List",
  "mode": "working",
  "section": [
    {
      "title": "Commodity One",
      "focus": {
        "reference": "Group/11111115"
      }
    }
  ]
}

Patient-based data sets

• This is patient-related data. This data is used to provide the patient medical history & the scheduled episodes of care.

Requesting the data by ResourceType.

• This method requires FHIR Core to always know all the resource types used on the application. We have 2 options to achieve this
  • Have the resources defined on the application_config.json file. This would be achieved by:
    • Adding a key on the application_config.json called resourceTypesToSync.
    • This would be a string JSON array of FHIR resource types needed by the app.
    • NB: We will not go with this option because it means giving the user the burden to decide what resources are synced down.
  • Define the resources used in the application by traversing the
    measure_reports, register & profile configs.
    • The resources reference on the register and profile would use the baseResource & relatedResource keys on the configs.
    • This process might be resource intensive during the initial setup, but we could save the resource types array on the shared
      preferences and use them for subsequent calls.
      • We can run the service to find the used resource types after every username/password login. This would help us account for new resource types that have been added to the configs
• FHIR Core would then request the resources one by one during sync. The server would then perform the Permissions and
  Data Access check for the logged-in user as defined here
  • Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Permission Checker #1603
  • Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Data Access Filter #1604
• The GET ALL requests would then just use the resource types list generated from the different configs.
  • e.g GET /Patient, GET /Task, GET /Group, GET /CarePlan

Questions for the Google team.

• How does the Proxy server handle pagination. Does just use the FHIR store pagination?
  • This is for instances where it has to combine multiple results for multiple API calls

[pld]

For the non-patient data, why can't that be sections in the composition / what data would the new list resource reference?

Doing anything one-by-one sounds bad, in terms of performance, which I assume is the highest priority here.

[dubdabasoduba]

Other considered options

1. Requesting the patient data and using the $everything operation to get all the related resources.

• $everything helps fetch all the resources that directly reference the resource in question. E.g $everything on the patient resource will fetch all the resources that reference the Patient resource in question.
  • The $everything operation is only available on the Patient, Group, Encounter and MedicinalProductDefinition resources.
• This method has one disadvantage, the $everything operation only allows GET ALL calls for the Patient and
  MedicalProductDefinition
  • Documentation on this can be found here.
• The above disadvantage means if we have other resources representing patient data e.g the Groups resource then we
  perform 2 calls. One for the patient and one for the Groups resource.
  • We would then have to perform a $everything search on each group to get the bundle of resources related to the
    group.

Implementation workflow

• FHIR Core will request for the Patient and Group resources in separate API calls.
• The server then will perform the Permissions and Data Access check for the logged-in user as defined here
  • Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Permission Checker #1603
  • Implementing API RBAC (Role Based Access Control) & Remote Sync ( from the server) for FHIR Core -- Data Access Filter #1604
• This would be the final step of the Data Access workflow.
• The GET ALL Patient call would include the $everything operation and the parameter _tag=<assignment> to filter the
  resources by the user assignment.
  • e.g GET /Patient/$everything?_tag=1234
• The GET ALL Group call would have the parameter _tag=<assignment> to filter the resources by the user assignment.
  • For each Group return the server will perform a $everything operation on the GET Group resource.
  • e.g GET /Group/1234/$everything?_tag=1234

[pld]

lgtm!