Building Immune Authorization: AppSec in Healthcare Apps

Application security in healthcare 

Protecting the personal information of our users is always a top priority in application development. However, when it comes to healthcare applications, the stakes are higher than ever. Safeguarding patient data and ensuring strict regulatory compliance, such as adhering to HIPAA, are not just important – they're vital (Get it?).

Considering the enormous sensitivity of the data in the context of healthcare, HIPPA places very strict requirements on the protection of sensitive medical information, and for good reason - 

In their September report, the HHS stated that Unauthorized Access/Disclosure is a growing concern among data breaches in healthcare, making solid security measures absolutely essential for healthcare applications.

In this blog post, we'll delve into the critical role of application-level authorization within the realm of healthcare applications. We'll explore various authorization models, with a special focus on Relationship-Based Access Control (ReBAC), and how these models provide the versatility and security required to meet healthcare's unique challenges. 

Authorization in healthcare applications

Authorization is a challenge that every app developer has to face. It plays the crucial role of ensuring that the right people and services have the right access to the right resources. 

In the context of a healthcare application, the different users of your app (Like doctors, patients, caretakers, etc.) need to have the appropriate level of access to the data within your system (Like patient files, test results, or even something as simple as a user profile).

It's important to distinguish between Authorization and Authentication: Authentication handles who can log in to your application, while authorization handles what they can do once they are inside. 

The complexity of Authorization in a healthcare application is never as straightforward as “Check if this user is an admin or not, and grant them access accordingly”, as might be the case with simple apps. 

// Gather all the needed objects for the permission check
// Complete user object from DB (based on session object, only 3 DB queries...)
const user = new HealthcareProfessional(session);
const patientRecord = new PatientRecord(undefined, undefined, session.url);
// The home-brewed auth-z layer someone wrote 3 years ago
AllowedRecordType allowedRecordTypes = new AllowedRecordType(user.role);



if (user.role == DOCTOR ||
   (user.specialization == "CARDIOLOGY" &&
    allowedRecordTypes.includes(patientRecord.type) &&
    (user.role == NURSE || user.role == MEDICAL_ASSISTANT))){
    // allow access
}

How not to do authorization for a medical app

Authorization policies in this space tend to look more like: “Allow doctors to access the medical records of patients who are currently being treated by them, limited to working hours” or “Allow a 

caretaker to view test results for a patient under their care”. 

Policies such as these require a much higher level of granularity and depend on multiple factors, including various role types, specific attributes, team affiliations, hierarchical structures, and more. 

It’s also important to note that when it comes to healthcare applications, most data breaches tend to come from within the organization itself, as wrong access privileges are given to the wrong users.

This is where different authorization models come into play.

Authorization models

Let's take a closer look at three prominent models: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC). 

While each model has its pros and cons, ReBAC is the backbone of any healthcare application authorization, offering unique capabilities that perfectly align with the intricate nature of healthcare scenarios. Let’s see how - 

Role-Based Access Control (RBAC)

RBAC assigns roles to users and defines permissions based on these roles. It simplifies access management by grouping users with similar responsibilities.

Example: In a healthcare app, you might have roles like "Doctor," "Nurse," and "Administrator," with corresponding permissions. Doctors can access patient records, Nurses have access to specific patient data, and Administrators manage user accounts.

Attribute-Based Access Control (ABAC)

ABAC uses attributes (characteristics) to make access decisions. It evaluates user attributes, resource attributes, and environmental factors to determine access.

Example: ABAC might restrict access based on attributes like a doctor's specialty, patient age, or the location of a medical facility. For instance, only pediatricians can access the records of child patients.

Relationship-Based Access Control (ReBAC)

ReBAC focuses on managing access based on relationships and hierarchies between users and resources. It enables the creation of user and resource groups, a crucial aspect of healthcare application modeling.

Example: In a healthcare app, ReBAC allows you to establish relationships between doctors, patients, and caretakers. A doctor can access the medical records of patients under their care, and caretakers can view specific patient information.

Why ReBAC is Crucial in Healthcare

In healthcare applications, the ability to manage authorization based on relationships is essential. ReBAC’s ability to derive authorization policies from existing application-level relationships allows us to create policies based on user and resource groups, hierarchies, and ownership. 

If you want to learn more about how ReBAC works, check out this detailed guide. 

Let’s take a look at the way that ReBAC expands the traditional role-based model to allow our dynamic roles and relationships:

Roles, Actions, and Resources

As we covered previously, in a role-based policy, access control is determined based on roles. Each role has a set of resource types assigned to it (Test Result / Patient File / Insurance Statement). Each resource type has a list of actions (Like Read / Write / Edit / Delete) one is able to perform on them. 

This means we can build a policy like: “Doctors can Read and Edit Patient Files”. 

This type of policy covers the very basics - but it strongly lacks the more nuanced roles to be used in an actual real-life scenario. That’s where ReBAC comes in - 

Role Derivations and Resource Relations

Using ReBAC, we are able to build policies that fit the needs of healthcare applications by utilizing the concept of Role Derivation -

Role Derivation - 

Through ReBAC, we can derive authorization policies based on existing application-level relationships. Put in the simplest way, it allows us to create a policy like this:

A user who is assigned the role of an Owner on a folder will also get the Owner role on every file within that folder. 

Creating policies based on relationships rather than roles or attributes saves us from having to create authorization policies on a per-instance basis. 

You can probably see how this is crucial for an application in the medical field. It allows us to create a policy like: 

“A user who is assigned the role of Attending Physician on a Patient Profile automatically receives the Attending Physician role for all sub-folders and documents within that patient's record, including test results, treatment plans, and medical history. 

Resource Roles - 

To create ReBAC policies, we need to create roles specific to a given resource. This means that the role, and the permissions it carries, are only relevant in the context of that specific resource. A resource role is formatted as Resource#Role. 

In the context of our previous example, “A user who is assigned the role of an Owner on a folder” will look like this: Folder#Owner.

The combination of Resource Roles and Role Derivations allows us to derive much more complex and granular roles that are perfectly tailored to handle hierarchies.

With role derivation, we can construct authorization policies that are far more efficient for hierarchies than RBAC and easier to manage than with ABAC. In RBAC, we would have to assign the attending physician a role that grants them direct access to each document within the patient’s record. 

In ABAC, we would add an attribute to each of the files and folders and grant the attending physician a role that allows them to access all files and folders in which the attribute references the attending physician’s ID.

Permission Scoping

Besides understanding the complexity of the various permission models, there are more features that are usually mandatory to provide healthcare app users with an efficient way of managing their own permissions in a scoped manner.

For example,  we might want to enable a Caregiver to give a Doctor access to specific parts of a Patient’s Medical Records within Certain Dates.

This scoping brings some new challenges to the table:

• Dynamic models: Unlike some other application types where roles and policies are set by an app admin, healthcare applications usually require policies to be set by the end users themselves.

• Data scopes: Even when users are allowed to define application policies themselves, this allowance needs to be scoped into a very limited set of policies, with developers being able to define this scope in a reliable way. 

• Combination of models: While ReBAC addresses complex policies at a higher level, situations may arise requiring a mix of attribute-based and static role-based policies. For example, users may need to specify active dates for their self-configured policies.

• Approval flows:  Healthcare's hierarchical structure and multiple roles mean that granting permissions often involves asynchronous processes among users. For example, a doctor may request permission from a caregiver, who then awaits confirmation from a family member.

As we can see, navigating permission scoping in healthcare applications presents unique challenges. Now that we have a better understanding of these challenges, let’s talk solutions! 

Demo Application - Galactic Health Group

To help you understand better the implementation of authorization in healthcare, we created a demo application that demonstrates how to model and implement RBAC, ABAC, and ReBAC into any application. The demo application users Permit.io, which allows you to implement these complex concepts with relative ease - using only very few lines of code and an intuitive UI.

The application demonstrates an example healthcare application based on the Rick and Morty universe that fills every checkbox when it comes to advanced authorization features. 

Interested? The demo app blog will be available here tomorrow

What Next?

In a world where healthcare applications are entrusted with the most sensitive and vital information, robust security measures are not just a priority but a necessity. The healthcare industry demands a level of complexity and precision in authorization that goes beyond traditional access control models.

In this blog post, we've explored the critical role of application-level authorization in healthcare applications and how it aligns with the intricate nature of healthcare scenarios. We've delved into three prominent authorization models—Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC)—with a special emphasis on ReBAC, a cornerstone of healthcare application authorization. 

Our next article in this series will provide you with an example of a demo application that brings all of these concepts together in one ready-to-use healthcare app built using Permit.io. Try it for yourself here!

Want to learn more about Authorization? Join our Slack community, where there are hundreds of devs building and implementing authorization.