Authorization through FHIR Consent

This article belongs to a series dedicated to Healthcare IT platforms. The following aims to describe 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.

Several concepts mentioned here are related with those mentioned in the previous article “The Efferent Healthcare Platform”.

All references to FHIR are for STU3, 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.

This generic statement is followed by a practical one:

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 individual users or to groups of them. In summary, each resource is associated to 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, where 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/UMAor 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. It supports a wide range of scenarios over intricate relationships. The picture below reflects those relationships, but not necessarily all of them.

Being 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 kind of resource or ‘data’. There can be more than one reference. Besides these explicit references, others policies may implicitly allow actors to access resources associated to 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 Except structure.

Besides the fact that a Consent may refer multiple actors, data entries and exceptions, there can be more than one Consent record associated to 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 the Consent record.
  • period – Indicates the period of applicability of the Consent.
  • action – Allowed actions to be performed over a resource (collect, access, use, disclose, correct).
  • securityLabel – A set of security labels for determining the resources controlled by the Consent.
  • dataPeriod – Period of time that certain data belong to the Consent.
  • actor.role – Indicates how the actor participates in the Consent process.
  • data.meaning – Establishes the scope of the Consent regarding other resources related to the data resources.

Notes to Release 4 Candidate

FHIR Release 4 Candidate changes the structure of the Consent resource. The most relevant change is the usage of the Provision element for specifying positive or negative exceptions upon the base policy. An exception may include lists of data objects, authors, recipients, organizations, purposes of use and date ranges.

More details at https://build.fhir.org/consent.html

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 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 sub-set 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, an 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 at server side considering all the possible variables.

However, as any performance analysis, it depends on the use case: It is not expected for a Practitioner to open much 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 users accesses the protected information recurrently during a determined timespan. A reasonable expiration time would be few hours, but it depends on the organization policies.

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

Certain conditions would difficult the pre-processing of authorization rules, specially 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 am to 5pm).

Concrete authorization implementation

The FHIR standard doesn’t enforce any authorization mechanism but rather provides several recommendations for protecting the information with an 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 that may be generated at 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 reduces the overall complexity of the client implementation, offers better security for “keeping the secret” and simplifies 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 it is 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 list of resources

When accessing list of resources (i.e. a list of recent Imaging Study resources), we may get into troubles when applying Consent rules to each record of the list, in order 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 he/she is 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 needs 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 that is authorized to access each individual resource, rather than evaluating the accessibility on each operation. This is similar to a technique called Access Control List and has been applied effectively for file system security, but working only at 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 whilst the second one can be more granular, based on certain conditions or attributes. ABAC seems to fit better the FHIR’s Consent paradigm.

For all the mentioned access-control types, storing per-user access tokens would accelerate the authorization evaluation but will bloat the authorization database significantly. On the 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 applying 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 market at summary reveal sensitive information, like the example below:

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

A software system still have 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.

A good read about this topic is the draft “Use Cases for FHIR Security Authorization with Patient Consent” (2016) by the Veterans Health Administration. The document explains with high 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 consents: 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 non verbose, and hasn’t improved for FHIR Release 4 Candidate.

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

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

Logging

The “Consent engine” may be a good source of logging for audit/HIPAA purposes. Despite of the fact that a consent may not be used at all or its related operation may be cancelled and rolled back, it expresses the intent of an actor for accessing resources for read or write purposes.

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

So far we haven’t found an explicit mention to consents in the FHIR AuditEvent resource type, either version 3 or 4. However, the AuditEvent is broad enough for holding a reference or ID of a Consent object.

Conclusions

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

For accessing resources in a one-by-one basis, the evaluation delay may not be critical. 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, in a similar way as the _summary search parameter.

Jaime Olivares
Chief Technology Officer
Efferent Health, LLC

 

Leave a Reply

Your email address will not be published. Required fields are marked *