Finely-grained authorization

[wardle]

In the legacy rsdb, authorisation was finely-grained and relatively straightforward to implement as there was a single route (essentially) to access a patient record. That meant patient data might have been made available in other contexts such as a list of encounters, but that list was only accessible through authorized access.

For the graph API, things are slightly more complex as it is based on attributes and a graph. As such, client applications should query for an authorisation property which will provide information about whether a user is authorized or not, informing the use of the results from other properties.

For example, we need to make authorisation a first-class property for most entities. For example, resolving attributes for a given patient is subject to authorisation; any client requesting those attributes may not get results or only partial results. As such, an attribute :t_patient/authorization will provide information about whether the current session's user is authorized to access data. For a patient, there will need to be support for 'break-glass functionality so that the workflow of the legacy pc3 is replicated: patient access is attempted, the client shows a patient banner [ie some patient data will have to be returned for most use-cases if a user is permitted to 'break-glass' - ie clinical users], and the client displays an appropriate user interface to allow the user to 'break-glass'. This action adds the patient to the session's break glass list (or singleton), with the client reloading the page.

To support such a workflow, each entity should support an :authorization attribute when appropriate. Some attributes will be redacted if there is no access (e.g. a patient's diagnoses or clinical information).

[wardle]

See souenzzo/eql-style-guide#4

[wardle]

Done