Access control

Access control is naturally a part of any system's security. For Agni, access control also has a utilitarian aspect: users needs access to relevant data, quickly. By partitioning data based on a user's role, security and utility goals are realized in tandem.

This section explains how data partitioning works.

Geographic partitions for community-based and facility-based services

To define geographic partitions, we follow a tree-like hierarchy. In the Indian context, this consists of villages, blocks, sub-districts, districts, and states. The depth of this tree can be configured while setting up Agni; the only constraint is that one child node (such as a block) can only have one parent node (such as a sub-district).

We assume that villages represent the smallest population aggregate overseen by a community-based healthcare professional, i.e. a frontline health worker (FLHW). Further, we assume that the mapping of villages to FLHWs does not follow administrative boundaries — FLHW catchment areas can have villages from different blocks, and even different districts.

Next, we assume that nurses and medical officers (MOs) are affiliated with health facilities (HFs), and the pool of patients served by facility-based healthcare professionals is defined by the catchment areas of the HF. Since HFs serve a larger population than FLHWs, we assume that HF catchment is mapped to , not villages. As is the case for FLHWs, we assume that the catchment area for an HF can cross district boundaries.

Managing catchment areas

Mapping FLHWs and HFs to their catchment areas is a critical step in configuring the system. A master list of all villages, blocks, sub-districts and districts has to be first uploaded to the Agni web portal. System administrators (SysAdmins) can update this master data. Logical checks ensure that master data remains coherent and well-structured.

Once the master data is available, the SysAdmin can define and save catchment areas, so that it is easy to allocate FLHWs and HFs to them. Consider an FLHW who handles 12 villages across two neighboring blocks. If this catchment area has to be transferred to another FLHW, then bulk-transfer, instead of item-by-item transfer, makes the process quick and error-free. To complement this functionality, the web portal also provides views and reports that show the staffing status of all catchment areas.

Finally, we anticipate that FLHWs will be connected to specific HF. The portal shall allow this connection to be established, and enable the SysAdmin to check for “unallocated” FLHWs. It shall also prevent the same FLHW to be allocated to two HFs.

Access control using partitions

Access to data is controlled based on two key dimensions:

1. Catchment area to which the user is mapped

2. Role of the user: FLHW, Nurse or MO (and more roles, such as pharmacist and lab technican, can be added)

Thus, access is governed by two of the user's attributes. This approach is called fine-grained access control (FGAC), which enables tigher access control than traditional role-based access control (RBAC).

FGAC is implemented using FHIR data structures. Specifically, we use the PractitionerRole Resource to map users to a combination of their roles and the organization node to which they belong.

By limiting access based on geographic partitions, we limit the risk of data exposure by design. This complements standard data security practices of encrypted storage and transmission.

Utility: improved offline search

FLHWs and HF users can search their respective catchment areas when offline, and add healthcare records without worrying about connectivity.

When they are online, they can switch from local search to global search, to search for patients who are from outside their catchment area. Once a particular user adds data for a patient, that patient's records become locally available.