Security in Care needs to support a wild array of use-cases, the old implementation relied on fix roles and used roles to check for permissions a user has, access to resources was done through custom business logic combined with roles.
To create a better and extensible security system in care, which is robust enough to support specific permissions and business logic while keeping it abstract to allow plugs to redesign them requires a complete ground up rebuild of the entire system. This document tries to describe the new system and how it works.
Permission
It is the ability to perform an action, this could be view, create, delete, manage or specific like “Discharge patient” etc.. Permission can be very descriptive or very abstract. It is usually of the format “Action on Resource” , like “Read on Patient” .
Role
Role is a collection of permissions, Note that Role is only a collection of permissions, it is not linked to any resources, Roles could be “Read Only View”, “Manager” etc ..
ResourceRole
Roles can be allocated for any resource, ie “User A” has “Read Only Role” to “Patient X” , This means that the user A has assigned the read only role to patient X. Roles can be created and assigned to resources on the fly. Instead of assigning permissions one by one, patients can also be assigned to a location and the user be given permission to the location instead.
Organization
Instead of assigning the resource permission to each resource, the permission can be assigned to a group and then all the group’s users would share the same permission. ie an Organization called “Cardiology” could have read access to all patients in Cardiology and then we can create a Doctors Organization inside cardiology with permissions to write to patients within cardiology, you can create a nurse organization with limited permissions and so on..
Action Permission
The act of viewing a patient might involve multiple permission checks and a combination of business logic, like “Are we a super admin” , “Do we have access to the patient through the patient’s location, if so do we have the required permission to view the patient? ” , “Are we the assigned doctor?” etc. Action Permission is just an abstracted piece of logic that checks if the permission for that action can be granted.
Security Abstractions will also allow other features to use security features without worrying about its implementation ie, providing access to a patient for a consult, this will create an exception entry in the permission store to allow the patient to be accessed via the mentioned role.
Organizations are assigned permissions to patients/encounters via roles, the permissions flow will be as follows