This module provides a mechanism for filtering persistent data on a configurable and customisable basis. In a nutshell it enforces metadata-based access to users and/or roles.
For instance, out of the box, the module supports location-based and privilege-based access control to patient records and their clinical data. The initial implementation for those two use cases is restricted to the patients and their visits, encounters and observations.
The data model has been kept simple deliberately such that only two concepts matter: 1) which entity is being restricted by the filtering and 2) on what basis does this filtering restriction operate?
- The basis is the metadata on which the data access is based.
Programfor program-based access,
Locationfor location-based access, ... etc.
- The entity is what is authorised to access the data.
Let us go through a couple of filters that are baked into the module. This will help highlight how much of the design of filters follows systematic rules, and how much of it is implementation-specific.
1. Location-based access
When this filter is enabled, users are prevented access to data based on their login location. In this case
- the basis is
- and the entity is
This raises a first question: how do we determine which locations a user has access to?
This is handled natively through the
EntityBasisMap, users are mapped with their basis through this built-in table of Data Filter.
Of course every user can be mapped to multiple locations, it does not have to be just one. Those will be the only locations that user will get to see, and log into, those will be the user bases.
Then a second question: how do we associate the data to a location so that the filter knows, when it is looking at some data, to which location it pertains?
This type of assumption is implementation-specific and in the case of the location-based filter that is bundled with the module, the assumption is that this is made at the patient level. There is therefore a need to associate a patient with a location, and this is done through a specific person attribute type. This person attribute type points to a location that marks the "patient's location".
Best is to look at one of the filter's conditions, see here:
The condition reads "include the data for patients that have a specific attribute type whose value is either of the bases (locations)".
The logic here is that every piece of data (whether visit, encounter, observation or patient itself) link to a
patiend_id that is subject to the above filter condition.