When the Client Has the Patient's Consent
- 6 minsCo-Authored with Kathleen Connor
(also posted here).
Summary: When the client has a copy of the patient consent, it should communicate it as an attribute assertion/claim to the authorization server, unless there is no support for dynamic per-transaction assertions in which case using the X-Consent header could be justified.
Use-Case
There is an exchange use-case where a requesting client has a copy of the patient’s consent which it believes to be more recent than what the server may have. For example, when a patient present at a healthcare facility signs a consent form authorizing the exchange of her information from another provider to the careteam in that facility. To avoid a possible rejection based on an old consent –or lack of consent altogether– the client needs a mechanism to tell the provider about the existence of the more recent consent and probably provide a copy of this consent so that the server can consider it and make the right decision. This is important in preventing an outdated consents from disrupting the exchange when quick access to patients’ information is crucial
One variation of this use-case is when the provider organization can trust the requesting client’s mere claim that there is adequate consent on file, without actually receiving a copy of the consent and processing it, or agreeing to receive a copy later. This is particularly helpful when the new consent is not in a readily-consumable format, e.g. when a paper form, audio recording, or unstructured text is used, and enables the parties to quickly proceed with the exchange without having to deal with the consent format and communication, which is of secondary importance when the client can be trusted.
Implementation
For the majority of systems where there is an authorization service with extensive capabilities, this use-case can be easily covered by defining an attribute assertion/claim for communicating the consent to the authorization service. The fact that the client has a consent on file, or the link to such a consent, is simply another attribute like the client organization ID, purpose of use, or confidentiality clearance which is considered by the authorization server. As an example, see the list of such attributes as defined in the draft for XSPA SAML profile which includes an attribute for referencing a patient’s consent.
Note that processing the patient’s consent and a client’s claim about having a consent on file is part of the authorization logic and is almost always intertwined with the rest of the authorization logic since patient consent is only one of the many policies that ultimately determine whether, and to what extent, access is granted. Broader authorization policies need to be checked to determine whether the patient’s consent is required to begin with. A consent decision point, which is part of the broader policy decision point, examines the consent to see whether it permits the requested access. Moreover, overarching authorization policies determine whether a client’s mere claim about having a consent on file can be trusted as sufficient without receiving a copy of the consent since this level of trust may only be granted to certain clients and not others. Overall, processing the consent, or a claim to have a consent on file, can hardly be separated from the rest of the authorization logic. Authorization service is where that information can be meaningfully processed and be of consequence, and therefore, the client needs to submit this information to the authorization service.
When Do We Need an X-Consent Header?
There has been some conversations in the FHIR community about defining an HTTP header (X-Consent) to address this use-case. The idea is for the client to use this header in its request and include a link to the consent, or perhaps a special value asserting that there is sufficient consent on file.
Based on the above, I think the client should avoid using the X-Consent and rely on submitting the consent claim to an authorization server. There are, however, cases where the client is granted blanket access based on a static set of attributes (often the client ID or the client organization ID) backed by a pre-existing trust relationship. These attributes remain the same across different transactions and, therefore, there is no way for the client to assert more dynamic attributes/claims which only apply to a particular transaction, such as the client’s copy of the patient’s consent.
For example, consider the case where the authorization service simply relies on matching the client identity with a static list of trusted parties. In such a case, the client may be authenticated using a simple password, a fixed API key tied to its identity, or an X509 certificate used in the TLS layer. The authorization attributes available in such a process are all static and there is no per-transaction exchange of dynamic attribute assertions/claims. In such cases, it makes sense for the client to use the X-Consent header to communicate its version of the patient consent to the authorization service since there is no other way to convey such information.
An alternative in this case is to grant the client the permissions to push the new consent to the server (or the consent management server if it is different from the provider’s FHIR server), before requesting access. This adds an additional step to the initial transaction, but it facilitates subsequent interactions of the client with server.
Using X-Consent Header in the Server’s Response
When used by the server, the X-Consent header can address a different use-case. It can hold a link to the patient consent based on which the server decided to release the resources in the response content. This provides a mechanism for referencing the consent for accountability and traceability purposes and the client can also use this information for its own accounting and traceability.
Moreover, it also enables the client to compare the cited consent with its own latest copy and take necessary steps to update the server if the server’s copy is outdated. This can be particularly useful if the client suspects that the server had sent a restricted response based on an outdated consent and considering the new consent can lead to a different, less restricted, response from the server.
There are inference-related privacy concerns around this approach since in certain cases, the existence of a consent by the patient (especially in opt-out scenarios) can be indicative of the existence of sensitive information. So, a privacy risk assessment is necessary before using this header to ensure that it would not lead to a significant inference risk of divulging patients’ sensitive health information.