Consents Revocation and Redisclosure
- 16 minsRevocation 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:
- A patient consents to releasing their protected information in custody of
OrgA
for TPO purposes. - This information is disclosed by
OrgA
toOrgB
. - Based on the overarching policy,
OrgB
can re-disclose this information toOrgC
(for TPO purposes) without the need to obtain further consent from the patient.
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.
Poll for Consent Decision
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.
This is inherently a poll model that only works if all custodians can either:
- access the Consent Store (CS) where the original consent is stored and maintained to get the latest status of the consent, or
- can query a Consent Decision Service (ConDS) capable of producing a decision in accordance with the latest status of the consent**.
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:
- The Consent Decision Service (ConDS) and every Consent Store (ConS) have a general revocation subscription in place so that the ConDS receives revocation notices for all consents.
- After authorizing a disclosure, the ConDS sets up a subscription for the requesting actor to ensure that the actor will receive follow-up notices of revocation for any consent based on which a permission for disclosure was granted.
- The disclosing actor (e.g.,
OrgA
) sets up a subscription to ensure that it will relay any notice of revocation down the chain to any other actor (e.g.,OrgB
) to whom the protected information is redisclosed.
The following diagram depicts a sample propagation of notices of revocation into the network following the patient’s decision to revoke a consent:
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.