Implementing Consent Management in FHIR
- 11 minsBackground: In a recent report for the FHIR At Scale Task Force (FAST), I pointed out “consent management” as one of the areas in which more implementation guidance is needed. This has now led to a new FHIR Consent Management Implementation Guide (IG) Project with the goal of covering some of these gaps. In this post I summarize some of the most important consent management use cases and the kind of guidance expected from a FHIR implementation guide in addressing them. Understandably, not everything covered in this post is within the scope of this project and I am hoping the rest will be covered by other specifications.
Consent management refers to various functions involving collecting, maintaining, and serving consents. As shown in Figure 1, a consent management system serves patients/clients, (internal or external) administrators, external consent consumer systems, and other consent management systems. A FHIR-based consent management system would rely on a FHIR server and FHIR resources to implement the corresponding use cases.
Figure 1. Consent management.
A FHIR IG for consent management should provide guidance on how to map these high-level functions to granular FHIR functions (e.g., creating or updating resources) and introduce profiles and example resources to support them.
Initiate Consent Capture
A provider may initiate capturing a consent by requesting a patient/client’s consent for a particular use case. In some cases, the patient/client initiates filing a consent without an explicit request.
The initiation may be by an administrator (internal or external) through a user interface, or it could be through an API request by an external system where consent is needed. We refer to such systems as consent consumers. This is usually triggered by an event in a workflow within the consumer system; for example, a referral which requires sharing sensitive information pending on the patient’s authorization.
Requesting consent may target one individual patient/client but it may also target a group, for example, a cohort of patients who qualify for participating in a clinical trial.
A mechanism (such as email, text message, or mobile app push notification) is needed for notifying the patient/client that their consent has been requested –if the consent capture is not initiated by the patient/client.
From the FHIR perspective, an IG should specify how to use a resource such as Task to record the request to capture consent from a patient/client.
Initiating a consent may seem to be doable with a single standard FHIR API call to create a new Task assigned to the patient/client. But this is only the case if the local FHIR ID for the patient is known. Since patient identity is often more complicated, initiating a consent capture usually involves multiple FHIR API calls, therefore, it may be worth defining a custom FHIR operation in the form of an OperationDefinition resource to encapsulate all the low-level logic. This also enables consumers to use a single API call to accomplish this.
Guidance on the use of a resource like Group and the nuances of invoking a bulk consent capture for a group are also within the scope of a consent management IG.
Review Consent
Once a consent capture is initiated, the patient/client needs to review the options available in the consent form and make decisions. This requires a user interface, often a web or mobile application, that allows patients/clients to navigate their options.
From the FHIR perspective, the choices given to the patient/client are formulated in a FHIR Questionnaire resource. These are usually based on existing paper forms used to collect consent in manual workflows. The responses from the patient/client are collected in a corresponding QuestionnaireResponse resource. Together with Structured Data Capture (SDC) profile, these resources offer a powerful and flexible mechanism to model consent forms in different configurations for various use cases.
A consent management IG should provide guidance on how to store the state of the consent navigation using Task and QuestionnaireResponse as well as guidance on capturing and storing partial responses from the patient/client, including cases where the response may be provided over multiple sessions.
Sign and Execute Consent
Once patients/clients finish navigating the consent options and finalize their decision, they sign the consent. This usually means that consent rules should be immediately enacted and enforced (unless the start date for the consent is in future). The signature may be electronic (e.g, by printing the name or drawing) or cryptographic (if the infrastructure for that is available).
From the FHIR perspective this event should lead to creating a Consent resource based on the QuestionnaireResponse resource resulting from the interactions of the patient/client with the consent management user interface. The $extract operation defined by the Structured Data Capture (SDC) Implementation Guide together with one of the mechanisms defined in that IG for extracting a resource from a QuestionnaireResponse can be used to accomplish this. A consent management IG should provide the necessary profiles and examples for this.
Figure 2. Capturing consent.
The signature may be stored on either or both of the QuestionnaireResponse and Consent resources. A record of this derivation may be captured either using the sourceReference attribute of the Consent resource or more extensively using a Provenance resource. Providing a profile of the Provenance resource and examples on how to record this is within the scope of a consent management IG.
Signing a consent is an important event and usually means that the consent rules should be enforced. Notifying the consumers of the consent (e.g., the entity that requested the patient/client for this consent) is essential in ensuring a reliable workflow for enforcement can be implemented. Further discussion on notifications will be provided below.
Review Existing Consents
The patient/client, an administrator, an external consent consumer, or an external consent management system, all have reasons to review existing consents for a patient/client. This may happen through a user interface or via an API call.
From the FHIR perspective this corresponds to searching for all of a patient/client’s consents (potentially with additional narrowing criteria such as status or consent type). The issue of identifying the patient, however, may make this a more complicated operation which may deserve defining a custom FHIR operation.
Revoke/Deactivate Consent
As a principle in consent, and as a right guaranteed by most overarching policies, patients/clients may revoke a valid consent whenever they choose.
At first glance, this may seem to be a simple FHIR API call to update and change the status of the respective Consent resource, but the revocation event needs to be memorialized and usually there are legal and policy requirements to retain (in some cases a signed) record of the revocation. So, the revocation may need its own form to sign which is modeled using FHIR Questionnaire and QuestionnaireResponse resources.
Once the revocation is signed and finalized, the state of the Consent resource may be updated to reflect the revocation. A Provenance resource should be used to record the event of revocation and link it to the signed request for revocation in a QuestionnaireResponse resource. Details and examples for the use of these resources in this use case should be provided by a consent management IG.
An administrator with appropriate privileges may deactivate a consent for reasons such as when a consent is entered in error. This is a similar operation even though the policy requirement about retaining the record may be different, so, it should be treated as a separate use case.
Revocation is a major event because it ends the validity of any permissions granted by the consent. Consumers of consent need to be made aware of the revocation in order to terminate any activities authorized by the revoked consent. This is further discussed below. See my previous post on revocation for a more detailed discussion on revocation and notifications.
Note that once signed and finalized, generally a consent should never be updated directly, unless when it is revoked. If the patient/client decides to change the consent, this is done by revoking the old consent and creating a new one and recording the details in a Provenance resource.
Notifications
A notification infrastructure enables the consent management system to initiate call-backs to other entities to alert them about consent events such as signing or revoking a consent. These notifications are important in enabling external systems to incorporate handling of consent events into their workflows.
From the FHIR perspective, SubscriptionTopic and Subscription resources should be used for implementing these use cases. Providing profiles and examples of the use of these resources is a key part of an IG for consent management.
Audit
It is important for patients/clients to see the consequences of their consents as they are enforced. This can give them confidence about the enforcement of the consent (e.g., seeing the actual rejection of a request that was not authorized by the consent), but also provide the feedback that can help them update and adjust their consents (e.g., noticing some rejected request and deciding to change the consent to be more permissive). In some cases, overarching policies and laws may require this as a right for the patient/client to be able to see the record of what has been permitted or declined based on each consent.
From the FHIR perspective, the AuditEvent resource is the right fit for recording the event of permitting or declining an activity based on the consent. A consent management IG should provide profiles and examples to clarify the details.
Since access events may take place in different consent consumer systems, providing a consolidated view of all the activities related to the consent also needs a subscription infrastructure to deliver AuditEvent resources back to the original patient/client-facing consent management system. This requires the use of SubscriptionTopic and Subscription resources. A consent management IG should provide examples and potentially profiles for these resources and how they can be used to set up a reliable infrastructure for collecting all relevant AuditEvents at a consent management system.
Consent Decision
In order to incorporate consent into various workflows, a consent consumer may ask the consent management system for the Consent resource (e.g., using a search based on the patient/client identity). Once the consent is received, the consumer can analyze the rules and determine whether or not an activity in is permitted based on these rules.
This requires the consumer to implement the capabilities to process the consent rules. But it is often more convenient for the consumer to avoid implementing these capabilities (and maintaining them as the details of how consent rules are formulated may change) and instead, directly query a Consent Decision Service whether the consent permits or denies an activity –similar to the way it would query an Access Control Service. This is a major capability implemented by the LEAP Consent project. Even though the Consent Decision Service is logically a distinct service, it can be offered by a Consent Management Service as an additional capability.
From the FHIR perspective, the API and formats for consent decision requests and responses need to be defined. The LEAP Consent Decision Service implements two ways to query for a decision: CDS Hooks (with extensive extensions) and XACML. The IHE Privacy Consent on FHIR (PCF) proposes using OAuth for this purpose but does not define a mechanism for specific queries for a decision (e.g., querying whether an action for a specific purpose of use about a specific patient and on specific data is permitted or denied), so this does not align with how LEAP Consent Decision Service granular queries work. Defining further details about how to query for a specific consent decision is another area where implementation guidance is needed.