Consents Revocation and Redisclosure

- 16 mins

Revocation is a fundamental right for the patient that ensures the continuity of consent: enabling patients to change their minds and revoke a consent ensures that the consent remains valid only as long as the patient continues to agree with its terms.

Revocation is tied to an opaque decision by the patient, so, it is distinct from expiration, which is tied to an event or a date that automatically causes a consent to cease being valid. For example, a consent may expire after 2 years or a patient may choose to set the consent for enrollment into a clinical trial to expire upon the completion of their treatment at a facility. But a patient can choose to revoke a given consent at any time.

Despite the conceptual difference, expiration and revocation have a similar effect: once expired or revoked, a consent is no longer valid and any activity authorized by the consent has to stop.

Revocation and Redisclosure

The issue of revocation becomes more interesting when the overarching policies allow redisclosures based on a single consent, because the information subject to the consent rules may be dispersed due to redisclosures.

For example, in the U.S., the CARES Act (enacted in March 2020) and the subsequent imminent update to substance use treatment rules (42 CFR Part 2) stipulate a model in which a single consent by the patient can authorize custodians to disclose and re-disclose protected substance use information for the purposes of treatment, payment, or healthcare operations (TPO).

Consider the following example:

Note that at this point copies of the patient’s protected information reside with OrgA, OrgB, and OrgC. Based on the initial consent and the overarching policy, each of these custodians can also redisclose this information which can ultimately lead to several copies of the protected information with different custodians.

Now, what happens if the patient revokes the consent or when the consent expires?

A minimal expectation is that no further redisclosures should take place once the consent is expired or revoked. Any redisclosure would need to be backed by a valid consent which no longer exists.

A more strict expectation, however, is that custodians who have received the protected information based on the initial consent, no longer have the right to hold on to this information and therefore should immediately delete it from their servers. The argument is that the consent that authorized these custodians to have a copy of the information is no longer valid, therefore, the use of the information should immediately cease.

The current Notice of Proposed Rulemaking (NPRM) for updating the regulations for substance use confidentiality in the U.S. seems to lean towards the former, less strict interpretation and only prohibits further and future disclosures after the revocation.

A simple model for enforcing revocation is to require that custodians query the status of the consent before each redisclosure. For example, before OrgB discloses the patient’s protected information to OrgC, it must check whether the redisclosure is permitted, i.e. whether the consent is still valid.

When the patient revokes the consent through a Consent Management System (ConMS), the revocation is recorded by changing the status of the consent*. This will cause the Consent Decision Service (ConDS) to deny future requests for authorization since the consent is no longer valid.

PatientConMSConSOrgAConDSrevoke consentupdate consent statusredisclose?query parametersconsentevaluate consentdenyPatientConMSConSOrgAConDS

This is inherently a poll model that only works if all custodians can either:

These assumptions may not be realistic in some use cases where the connectivity between these actors is not strong.

This model becomes even more problematic in the case of further disclosures within an organization because the polling could cause a significant overhead (for querying an external ConDS) before every instance of access to the protected information within the organization.

Propagating Revocation

If we can ensure that the custodian will receive updates about the authorizing consent, it no longer needs to check the consent status before every disclosure. At the time of a new disclosure, if there has not been a revocation notice, the custodian can safely assume that the consent is still valid and redisclosure is authorized.

Note that this model can also support the more strict expectation where the custodian would cease using the protected information completely by deleting it in response to the revocation notice.

A revocation propagation network relies on subscriptions (e.g., FHIR Subscriptions or similar mechanisms) to ensure that every actor that implicitly or explicitly authorizes a disclosure, commits to following it up by sending a revocation notice in case the initial authorizing consent is revoked. Chaining the revocation notices can deliver the event to any custodian that has received the protected information.

Note that this model requires less connectivity in the network because in order to receive revocation notices, every actor only needs to rely on connecting to the same actor that sent it the protected information in the first place.

The following diagram shows a sample set-up for revocation subscriptions:

ConSConDSOrgAOrgBrevocation subscriptiondisclose?fetch consentconsentpermitrevocation subscription for OrgArequest to discloseprotected informationrevocation subscription for OrgBConSConDSOrgAOrgB

The following diagram depicts a sample propagation of notices of revocation into the network following the patient’s decision to revoke a consent:

PatientConMSConSConDSOrgAOrgBrevoke consentupdate consentprocess eventrevocation noticeprocess eventrevocation noticeprocess eventrevocation noticePatientConMSConSConDSOrgAOrgB

Summary and Conclusions:

A revocation propagation model works more efficiently and with less connectivity assumptions compared to the polling model, but this comes at the cost of additional complexity. Implementing subscriptions require dedicating further resources in each system and mechanisms for security and robustness that can lead to a more complex implementation.

This is also relevant to the interpretation of how a revocation must be enforced. Overarching policies often refrain from requirements that are perceived to be technologically infeasible; I think a more strict interpretation of revocation (compared to what the current rules in the U.S. require) is technologically feasible albeit with a slightly more complex implementation.

(*) In the U.S., the rules require the revocation to be written and signed or recorded as an oral revocation. This means that further documentation needs to be recorded in order to back up the revocation of the consent –more than simply updating the consent status. In FHIR, these artifacts can be linked to the Consent resource using the Provenance resource. The details of how to do this is the subject of a future post.

(**) This is an abridged diagram to focus on the revocation flow. For a more detailed diagram see this post.

rss facebook twitter github youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora