Consent in TEFCA
- 9 mins(This post is based on my talk at the 2024 Annual Civitas Networks for Health Conference in Detroit.)
In technical discussions around consent management and enforcement, usually a simple transaction context is assumed: the custodian of the data wants to share it with a recipient and consent needs to be honored and enforced. This is reflected in the architecture proposed by the LEAP Consent project as well as the model in IHE PCF.
In this simple architecture, there are only two entities: the custodian and the recipient. Consent enforcement takes place as part of the general access control where overarching policies determine that in the context of a particular transaction, the decision whether to permit access (and to what extent) hinges on the patient’s preferences, captured by the consent.
In this scenario, it is often assumed that the custodian is in charge of enforcing the consent and either directly owns the consent decision and management services or has a direct integration with a partner entity that readily provides these services.
From a more general perspective, however, exchange transactions may be far more complex and involve other intermediaries. I use TEFCA as an example of a this more general model where multiple intermediaries may be involved in a workflow to fulfill an exchange transaction. Note that this is also a simplified model of TEFCA.
(adapted from the TEFCA Qualified Health Information Network (QHIN) Technical Framework (QTF))
In this simplified model, the recipient’s request for data exchange goes through the recipient’s Qualified Health Information Network® (QHIN) which effectively acts as a hub for the recipient’s community and a router for this transaction. Similarly, there is a QHIN in the custodian community with the similar role.
There are three major questions regarding the consent in this architecture as I will discuss in this post. Determining the answer to these questions depends on both policy and technical factors. Note that these models are not mutually exclusive and different combinations of these models can coexist within an ecosystem and be applied in processing different transactions.
Who manages the consent?
There needs to be an entity that handles the interactions with patients to collect and maintain consents. Consent management may be implemented by one of the entities directly involved in the transaction workflow shown above, or by a third-party (or third parties) with direct relationship with one or more of these entities. There are initiatives to standardize the functions of a consent management system (such as FHIR at Scale Taskforce (FAST) Scalable Consent Management Implementation Guide) in order to establish scalable mechanisms for these functions to be implemented by different entities. This also enables consent management to be handled as a third-party service by a community of vendors competing and innovating on the proprietary aspects of user experience and user interface, while relying on a standard specification to guarantee interoperable interfaces. I have discussed this in a previous post and will discuss further in future posts.
Who provides the consent?
One of the entities involved in the transaction must retrieve the consent and add it to the context of the transaction for enforcement. This could be either the raw consent object, or a consent decision obtained for the particular transaction context based on the consent. In order to retrieve the consent, this entity should either directly own consent management or be integrated with consent management services that collect and maintain consents.
It also need to align the identity of the patient in the context of the transaction with the digital identity of the patient as known to these consent management systems to ensure the correct consent is retrieves (for more on this see my previous post about consent and identity).
Recipient
In some cases, the recipient initiating the request already has the consent and can include it in the transaction context as part of the request. For example, in a referral workflow, when the recipient needs the patient’s record, if the recipient already has a relationship with the patient it can collect the consent from the patient and provide it as part of the request for data.
The question of patient identity is easier to resolve in this case because the recipient directly knows the patient and can retrieve (or collect) the consent from that very patient. Matching the identity of the patient with the identity of the patient as known to the custodian is still an issue but it is handled by the broader workflow, in this case, TEFCA’s patient discovery.
If the enforcer of the consent can trust this adjudication of identity then the enforcement of the consent also becomes easier and essentially boils down to verifying that the consent rules indeed permit the transaction to proceed and any additional obligations that must be applied.
Recipient QHIN
This is the case where the consent is managed at the community level on the recipient’s side. Once the request reaches the recipient’s QHIN, it retrieves and adds the consent to the transaction context. The QHIN needs to resolve the patient identity to ensure that the consent retrieved belongs to the same patient whose information is the subject of the transaction.
Custodian QHIN
In this case, consent is manages at the community level on the custodian’s side. When the request is received by the QHIN, it resolves the patient identity and retrieves the consent from the consent management system and adds it to the context of the transaction.
Note that in cases where there are many consent management systems, the QHINs as community hubs have the ability to use a discovery mechanism (similar to patient discovery) to find and retrieve any potentially applicable consent from the network.
Custodian
This is similar to the simple exchange use case in which it is up to the custodian to retrieve or collect the consent.
Who enforces the consent?
One of the entities involved in the transaction should enforce the consent rules either based on the consent object or by consuming the consent decision previously generated based on the consent. In the context of the transaction workflow, this entity should either be the same as the one who provides the consent, or an entity activated after the consent is added to the context of the transaction so that at the time of enforcement, the consent (or the consent decision) is already available.
There are usually two components to consent enforcement: (a) permitting or denying the transaction altogether based on the consent decision, and (b) applying obligations that may modify the data. For example, if the consent does not permit sharing a subset of the data, that subset can be removed (redacted) from the outgoing bundle.
Note that for the purpose of audit (and also as required by some overarching policies) the enforcer of the consent sometimes needs to log the consent that was used as the basis of the enforcement. So, if a consent decision is used (instead of the raw consent object), the consent that was the basis of the decision is often included in the decision metadata (as a link or an attachment).
Aside from the technical aspect, the decision of who enforces the consent is a policy question as it depends on who is trusted to control the flow of information based on the consent rules and to what point the overarching policies allow the information to flow. For example, if the overarching policies hold the custodian responsible for enforcing consent and do not allow the custodian to outsource this responsibility to the local QHIN, the custodian will have to be the point of enforcement.
Custodian
In this case, the custodian enforces the consent policy by either rejecting the transaction or modifying the data according to the obligations derived from the consent. In order for the custodian to be able to enforce the consent, the consent must be retrieved either directly by the custodian through an integration with the consent management system, or be provided at an earlier point in the workflow, by the recipient or one of the intermediary QHINs.
Custodian QHIN
If the overarching policies allow the data to flow from custodian to the custodian QHIN without consent, the custodian is able to rely on the community QHIN to enforce the consent for the rest of the workflow.
The QHIN may block the transaction or modify the outgoing bundle according to the consent policies. In order for this to be possible, either the QHIN needs to retrieve the consent directly or one of the other entities (the recipient, the recipient QHIN, or the custodian) should retrieve the consent and add it to the context of the transaction beforehand.
If the QHIN is acting as an aggregator, collecting data from multiple custodians, it is in a better position to enforce the consent by having a more complete picture of all the outgoing data.
Recipient QHIN
In this case, the overarching policies allow the data to flow from the custodian to the custodian QHIN and from the custodian QHIN to the recipient QHIN. For example, if overarching policies allow the flow of information within the jurisdiction and all of these entities are in the same jurisdiction (while the recipient is outside of the jurisdiction), the enforcement can be carried out by the last intermediary that resides within the jurisdiction, before the data leaves that jurisdiction. There must be trust that the recipient QHIN will enforce the consent and honor its rules. The recipient QHIN either retrieves the consent directly or relies on a consent already added to the context of the transaction prior to that point by one of the other entities.
Recipient
In this case, consent enforcement is left to the recipient. In essence, consent is not enforced on the transaction throughout the workflow, and instead the recipient is trusted to enforce the rules of the consent in its own domain in further service-to-service or end user data access. This is a rare case that is included here only for a more complete discussion; in most common use cases, consent has to be enforced before the data is given to the recipient.