Authorization through FHIR Consent

The following article describes the complexities of implementing the authorization behaviors for a multi-tenant healthcare platform based on the FHIR’s Consent resource in lay terms. It doesn’t intend to describe a full implementation.

All references to FHIR are for version R4 unless specified.

Authorization basics

Authorization is a key concept among other important related to security like identification and authentication. According to RFC 2196 section 4.4:

Authorization refers to the process of granting privileges to processes and, ultimately, users.

A practical one follows this generic statement:

Explicitly listing the authorized activities of each user with respect to all resources is impossible in a reasonable system. In a real system certain techniques are used to simplify the process of granting and checking authorizations.

Most computer systems represent physical security policies as a collection of permissions that can be assigned to individual users or groups of them. In summary, each resource is associated with an explicit list of granted entities.

This authorization scheme works well for homogeneous resources like files and folders or database entities with a uniform schema. The consent policies can be expressed explicitly in a list of grantees. However, medical records are more diverse and may have implicit relationships.

The Consent resource

The FHIR Consent resource covers several use cases related to authorization. As described in the specification:

Privacy Consent Directive: Agreement to collect, access, use, or disclose (share) information.
Medical Treatment Consent Directive: Consent to undergo a specific treatment (or record of refusal to consent).
Research Consent Directive: Consent to participate in research protocol and information sharing required.
Advance Care Directives: Consent to instructions for potentially needed medical treatment.

We are focusing here specifically on the first use case.

The FHIR Consent resource is not tied to any particular security scheme, like OAuth/UMA or similar, a particular policy kind, or a particular architecture or implementation of it.

That’s why the Consent resource offers a very flexible mechanism for representing authorizations or ‘provisions.’ It supports a wide range of scenarios over intricate relationships. The picture below reflects their multiplicity.

Being the concrete users the final grantees (or ‘actors’) of authorizations, there are some implicit authorizations granted to other entities that they belong to, especially in the case of Practitioners, who can be part of a granted Group, Organization, or Care Team.

A single Consent can refer explicitly to any type of resource or ‘data.’ There can be more than one ‘provision.’ Besides these explicit references, other policies may implicitly allow actors to access resources associated with a granted patient. These policies may belong to the Organization and government regulations (local or federal).

All that web of relationships comprises positive consents, and a similar one can be defined to express negative consents (or No Consents) via the exception provisions.

Besides the fact that a single Consent resource may refer to multiple actors, data entries, and exceptions, there can be more than one Consent record associated with a specific resource (i.e., a particular Imaging Study record).

Extended complexity

Certain attributes can increase the complexity of a Consent, as highlighted in the following UML diagram:

status – Indicates the availability of the Consent record
policy – Policies covered by this consent
verification – Consent verified by patient or family
provision – Constraints to the Consent
provision.type – Either deny or permit
provision.period – Indicates the period of applicability of the Consent.
provision.action – Allowed actions to be performed over a resource (collect, access, use, disclose, correct).
provision.securityLabel – A set of security labels for determining the resources controlled by the Consent.
provision.period – Period of time that certain data belong to the Consent.
provision.actor – Who or what is controlled by this rule and how is involved.
provision.data – Data controlled by this rule.

Consent in the field

We have learned the Consent resource specification is vast and comprehensive but still clear enough for enacting it in a medical platform by retrieving all the Consent records related to a specific Patient, data resource (i.e., Procedure), and actor (i.e., Practitioner).

Although there are several hints in the FHIR specification and related standards about how to proceed on each modifier, it is the responsibility of the software application to execute the Consent in a specific way, especially in concordance with the Organization’s Policy.

Organizations building a healthcare application tend to take a specific subset of rules and match them with a concrete access control model like role-based or attribute-based. On the other hand, when building a broad multi-tenant platform, a heuristic approach shall be taken into account based on all the Consent specification edges.

Individual resource access

From a database perspective, retrieving all the Consent records and all their related resources may involve several operations or queries. After that, processing all those records can be a costly operation on the server-side, considering all the possible variables.

However, as with any performance analysis, it depends on the use case: It is not expected for a Practitioner to open many medical records in a short period of time (let’s say, a few within an hour). We can say we are safe regarding server overloading.

An approach that prevents processing the same Consent multiple times is to create temporal tokens for a particular user. This way, once a user gains authorization for a specific resource, the authorization server won’t be forced to reevaluate the Consent for each access when the user accesses the protected information recurrently during a determined time span. A reasonable expiration time would be a few hours, but it depends on the organization’s policies.

Other processing techniques may pre-process a Consent record once it is registered. Using an intermediate access control policy language like XACMLmay help optimize the processing. However, this standard has been criticized for its weak support for multi-server authorization scenarios.

Certain conditions would make the pre-processing of authorization rules difficult, especially those related to time. Those constraints need to be evaluated constantly as the rules can change based on the operation time:

Whenever a consent or part of it has an expiration date.
Whenever a consent element is restricted to a specific time range (like. 9 a.m. to 5 p.m.).

Concrete authorization implementation

The FHIR standard doesn’t enforce any authorization mechanism but provides several recommendations for protecting the information with a heuristic approach (see “FHIR Security”).

The de-facto standard for authorization nowadays is OAuth 2.0. It is being used in many FHIR implementations, including Smart on FHIR. OAuth 2.0 enacts the authorization by using tokens generated at the client or server-side (self-encoded).

Self-encoded tokens may be difficult to revoke, and for that reason, it is suggested to give them a short expiration time. On the other hand, server-side tokens reduce the overall complexity of the client implementation, offer better security for “keeping the secret,” and simplify the revocation of tokens (see “Revoking Access” at oauth.com).

The authorization management can be totally removed from the client application. It can happen at the backend only, whether processed in one or multiple servers. Servers just need to return HTTP Status 403 “Forbidden” whenever a resource cannot be accessed rather than involving a resource authorization token for each operation. In that case, the backend can persist “internal” tokens somewhere and not expose them to the client.

Access to the list of resources

When accessing the list of resources (i.e., a list of recent Imaging Study resources), we may get into trouble when applying Consent rules to each record of the list to exclude unauthorized ones.

Pagination doesn’t help too much, as in the following hypothetical case: A Practitioner requests to see the last 20 Imaging Study records that they are authorized to read. There is only one valid record per day, and the total records surrounding those 20 are 350.

In this case, the applications need to traverse 350 records and apply the Consent-based discrimination logic to each one before reaching the 20th authorized record. This may involve thousands of individual records and the call to a Stored Procedure for each one or, even worse, a local procedure for running the Consent logic for each of the 350 records.

All this sounds like a very costly operation, just for showing 20 records.

A brute-force approach may be to maintain a table of each individual actor authorized to access each individual resource rather than evaluating the accessibility of each operation. This is similar to a technique called Access Control List and has been applied effectively for file system security, but it works only at the per-user level rather than per-group.

A couple of higher-level approaches are Role-based Access Control (RBAC) and Attribute-based Access Control (ABAC). The first one heavily relies on pre-defined user roles, while the second can be more granular, based on certain conditions or attributes. ABAC seems to fit better with the FHIR’s Consent paradigm.

For all the mentioned access-control types, storing per-user access tokens would accelerate the authorization evaluation but would significantly bloat the authorization database. On top of that, it will be crucial to synchronize any change in the Consent record with the table of authorized users, including expiration, which may require a permanent monitoring process or ‘daemon.’

Do-not-evaluate-lists approach

All that said (costly processing versus database bloating and complex processing), one can conclude that it is not convenient to apply Consent rules to lists of resources. It may be more efficient to show lists with non-sensible information and perform the rule analysis when opening a specific record—the same for the referenced resources.

A practical approach would be to use the _summary=true parameter in the FHIR search URL. It will return limited information regarding each resource participant in the bundle or list, with a caveat: the _summary parameter is oriented to reduce the element count in a response message, specifically those marked with attribute IsSummary=true, but unfortunately, several parameters marked as summary (∑) reveal sensitive information, like the example Patient resource below:

The chart depicts all the summary fields. It can be noticed that address, telecom, and DOB are exposed. Depending on the privacy policy of a medical practice, that can be considered sensitive information and shall not be shown in a generic list.

A software system still has a couple of possibilities for overcoming this situation: either maintain an extra list of sensitive elements, to be removed from summary messages or build a privacy list from the ground up. In both cases, a security layer must traverse all the resources contained in a FHIR message and remove the sensitive elements.

Multiple authorization servers

This article focuses on the FHIR Consent resource and intentionally omits multiple access server processing. However, it is worth mentioning it for distributed authorization scenarios.

The draft “Use Cases for FHIR Security Authorization with Patient Consent”(2016) by the Veterans Health Administration is a good read about this topic. The document explains with great detail how to implement authorization by cascading multiple OAuth 2.0 authorization servers of three categories:

Custodian Organization Authorization Server (CO AS)
Custodian Organization Patient Consent Authorization Server (CPC AS)
Third-Party Patient Consent Authorization Server (TPPC AS)

The Contract resource

FHIR specifies another resource type related to consent: Contract. According to the specification, a contract may be related to financial (e.g., Insurance policies), business arrangements (e.g., supply contracts), and privacy and security (e.g., Consents). The documentation about this resource is still incipient and nonverbose and hasn’t improved for the FHIR Release 4 Candidate.

A contract may specify the details of an Organization-Patient agreement, including custom codes for constraining consents and verbal explanations of the same, in layman and legal terms.

As contracts are particular to organizations, they may be difficult to process in a multi-tenant implementation, as it would require custom logic for processing the allow/deny codes.

Logging

The “Consent engine” may be a good logging source for audit/HIPAA purposes. Although consent may not be used at all or its related operation may be canceled and rolled back, it expresses the intent of an actor for accessing resources for reading or writing purposes.

The log records can be stored in pairs or joined entities: the consent granted by the access server and the operation requested by the resource servers. They reflect intent and action.

So far, we haven’t found an explicit mention of consent in the FHIR AuditEventresource type, either version 3 or 4. However, the AuditEvent is broad enough to hold a consent object’s reference or ID.

Conclusions

The Consent resource is a complex piece of the FHIR specification. As it allows several scenarios, it is costly to evaluate the Consent rules for each element accessed in a medical application.

The evaluation delay may not be critical for accessing resources on a one-by-one basis. Processing recurrent individual resource consents may be prevented by using short-lived tokens.

It may be costly to evaluate each element in a list of resources. A more practical approach for lists may be to restrict the specific elements shown per resource type similarly to the _summary search parameter.