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

[dubdabasoduba]

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

Context

• FHIR Core is a health workflow-oriented app. This means it collects & stores health data which is sensitive in nature. Due to this reason, data should only be accessible to the users with correct permissions.
• This documentation is to highlight the approach we would be taking to secure the HAPI API & filter the data a user has access to based on their user assignments.
• This will piece of work will involve the following systems.
  • Keycloak -- The authentication and Authorization server used by FHIR Core
  • FHIR Proxy server -- This is a middleware to provide authentication & authorization services between a FHIR Store and Authentication providers
  • HAPI FHIR -- This is the FHIR store of choice for FHIR Core.

Data filtering based on User Assignments (DataAccessChecker)

Context

• This is the next stage after the Permission Checker allows the request to go through after successful permissions check.
• Users in FHIR Core will be assigned to three levels.
  • Location Assignments -- This is the catchment area the user is designated to work in.
  • Organization (Team) Assignments -- This is the team within the given catchment area the user is assigned to.
  • CareTeam Assignments -- This is the care team within the given team the user is assigned to.
• All the data created by FHIR Core has a tag of all these three levels. This makes it possible for us to identify the
  data created by a user based on their assignments.
  • We will then target these tags to filter the data a user has access to.

Sample tags on the meta key of a resource.

{
  "meta": {
    "tag": [
      {
        "system": "https://smartregister.org/",
        "code": "140735",
        "display": "Practitioner CareTeam"
      },
      {
        "system": "https://smartregister.org/",
        "code": "105",
        "display": "Practitioner Organization"
      },
      {
        "system": "https://smartregister.org/",
        "code": "304",
        "display": "Practitioner Location"
      },
      {
        "system": "https://smartregister.org/",
        "code": "b87ff3c2-cbc6-43e6-b753-a9620756f9e4",
        "display": "Practitioner"
      }
    ]
  }
}

Implementation

• The implementation is broken down into 3 categories.
  • How to identify the app & the app sync strategy data?
  • How to identify the user's assignments?
  • How to filter the data based on the user's assignments?

How to identify the app & the app sync strategy data?

• This is dependent on a couple of items used to define the FHIR Core application configs. These items include.
  • App ID -- This is the unique identifier of the app requesting the data.
  • Composition Resource -- This is a FHIR resource used to define all the Application configs.
  • Application Config -- This is the config used to define how the application behaves. The point of interest here is the
    syncStrategy key.
• All the users will have an attribute that holds the Application ID attached to them. This attribute will help identify
  the app that the user belongs to during syncing data from the server.
• This will be found on the fhir_core_app_id key. Here is a sample for the key data "fhir_core_app_id": "ecbis-saa".
• We will then use the Application ID to search and fetch the Composition resource used to define all the application
  configurations. The Application ID is the official identifier for the Composition resource. Here is an example

  {
    "identifier": {
      "use": "official",
      "value": "ecbis-saa"
    }
  }

• In the section key of the Composition look for the entry with the identifier.value = application. This is the binary resource that holds the application settings.
• This Binary will have a syncStrategy key. This will hold the strategy to the application will sync by. This
  strategies represent the 3 assignment levels.
  • Here is a sample of the sync strategy configuration "syncStrategy": ["Organization","Location","CareTeam"]

How to identify the user's assignments?

• We will reuse the functionality we built to fetch the patient details.
  • This is documented here.

How to filter the data based on the user's assignments?

Sync by Location

• Sync by Location means getting all the records that have a location tag that's equal to the Location Id for the logged-in user and all the child locations under it.
• We can find the child's Location Ids from the parentChildren key of the hierarchy returned by the Practitioner details
  endpoint (sample) we have the child location Ids saved.
• We would then fetch the requested resource for each location i.e the parent and children locations.

  {
    "parentChildren": [
      {
        "identifier": "Location/109211",
        "childIdentifiers": [
          "Location/136256"
        ]
      },
      {
        "identifier": "Location/136256",
        "childIdentifiers": [
          "Location/137151"
        ]
      },
      {
        "identifier": "Location/137151",
        "childIdentifiers": [
          "Location/138395"
        ]
      }
    ]
  }

Sync by Team (Organization)

• Sync by Team (Organization) means getting all the records that have an organization tag equal to the Team (Organization)
  Id for the logged-in user.
• In addition to this, we would get all the data tagged by the CareTeam(s) IDs for the CareTeam(s) assigned to the
  Team (Organization) in question.
  • E.g if we have 1 Organization with 2 CareTeams then we would have 3 calls to fetch the patient data from the 3 points.
    • A patient call to get all the Patient resources tagged by the Team (Organization) if any.
    • 2 Calls to get patient resources tagged by either of the CareTeam(s)
• If the user is assigned to 2 Team(s) (Organization) the time it takes to fetch and filter the data increases.

Sync by CareTeam

• Sync by CareTeam means getting all the records that have a CareTeam tag equal to the CareTeam Id for the logged-in user.
  • E.G if a user is assigned 3 CareTeam(s) and wants to Query the Patient Resource then we will fetch the data from all
    3 CareTeams.

[pld]

Can you add a systems diagram please? I don't understand how Redis fits into this

[pld]

Lgtm, but as discussed let's move out the Optimizing the app and app sync strategy section into a new discussion called

"FHIR Server Read Optimization" w/three sections 1) HTTP Caching 2) DB Indexing 3) Memoization, and put that section under (3)