Google Cloud Healthcare Consent Management API

In the recent past, we have seen the Healthcare industry grow at a drastic rate. Times like these have motivated customers to strive for new solutions that will enable them to avail virtual care, and even nudged healthcare providers to run clinical trials remotely.

Now, in order to facilitate this, healthcare companies will need massive amounts of data. Naturally, we’re seeing an increase in the number of tools created to help healthcare application developers and researchers which enable them to easily manage and secure patient consent for their data that will aid in this medical care and research.

Further, the explosion of rich data generated by health tracking devices has emphasized the importance of patient consent and privacy, as patients and caregivers look to safely incorporate data from more sources into their care plans.

We know that security plays a key role in this data utilization and I have found the Consent Management API to be extremely helpful in enhancing security.

With that in mind, I have penned down a blog that will give you a comprehensive overview of this crucial architectural component that provides scalable and secure management of your user’s consent and ensures data privacy.

So, what does a Consent Management API do? Simply put, a Consent Management API stores the consent information you receive from users, keeps track of what data is permitted for each use case, and helps your application utilize data only as directed by your users.

It is a tool that records user consents, manages actions based on these consents, and maintains associated documentation and records.

It is important to keep in mind that the organization using the Consent Management API is responsible for obtaining and maintaining the required consents necessary to permit the processing of any data through the Consent Management API.

Now that we have that out of the way, let’s jump right into the prerequisites of Consent Management API. Here is a list that should help you

1. Healthcare APIs that are enabled on GCP account
2. Patient Data stored in FHIR, GCS or BigQuery
3. Consent Store
4. Configured consent policies
5. Consent artifacts
6. Registered user data mappings

Let’s move forward and take a look at the solution approach for deploying a Consent Management API.

1. Consent Management APIs can be integrated with any applications that deal with sensitive patient data and require approval from patient.
2. A request for a given patient will be sent to Consent Management API to check if there is any active consent present for requested policy by a particular patient.
3. Consent Management then checks the consent store and returns with the status of existing consents.
4. Based on step 3 there are two possible approaches –
   1. If active consent is found then corresponding data can be retrieved from the Data Source.
   2. If consent is not found, a request to patient can be sent for consent.
5. Upon approval of patient a consent is created and stored in consent store.
   1. Once the consent is created it can be used to allow access to the requested data.

We can now take a look at Consent Management API operations.

1. Create Consent Store

Consent Store is used to store metadata of all the configurations and operations that will be performed and used, like mapping between users and their data, policies which will be used to access the data, consent statuses, and signatures throughout the Consent Management process.

Here are the steps to create a consent store in the Cloud Console:

1. In the Cloud Console, go to the Datasets page.
2. Open the dataset where you want to create a consent store.
3. Click Create Data Store.
4. Select Consent as the data store type.
5. In the ID field, enter a name of your choice that’s unique in your dataset. If the name is not unique, the store creation fails.
6. Click Add label to define optional key and value labels to organize your Google Cloud resources.
7. In Consent Store Configuration select one of the following options to determine when consents in your store expire:
   1. No default expiration time – by default, consents do not expire.
   2. Default expiration time – by default, consents expire after the number of days defined in the Expiration time field.
8. Click Create.

We have created a consent store with the following details –

1. Location: austrailia-southeast1
2. Dataset Name: dataset-1
3. Consent Store Name: consent-store-001

You can get the list of consent stores with API as shown below

2. Create Consent Policies

Consent policies are used by the Consent Management API to represent consent granted by an end-user or through an organizational guideline. They are the building blocks of consent resources. Each consent resource can contain up to 10 consent policies.

A consent policy consists of:

RESOURCE attributes

• Resource attributes describe what the policy applies to
• Whose value is determined by the properties of the data or action
• For example, whether data is de-identified or identifiable
• This type of attribute is used to describe what a consent policy applies to, to describe data registered with user data mappings

REQUEST attributes

• Define an authorization rule that determines under what conditions the policy is valid
• Determined by requester’s identity or purpose
• For example, professions that are consented for use, such as researchers or care providers

3. Create Consent Artifacts

The Consent Management API stores sensitive data pertaining to a user’s consent as a ConsentArtifact.

Consent Artifact works as a signature of a patient, that act as “proof” of consent provided by patient or user.

Consent Artifact could be –

– user’s contact information

– signature timestamps

– images of signatures or other documents

We can register consent artifacts as shown in the below example –

4. Creating a Consent

A Consent includes an opaque user ID, the consent policies granted by the user, and the status of the consent policies.

It is a record that states who are allowed to access which data, and for which users. We can configure when a consent expires and is no longer valid. Consent can have various states, like ACTIVE or REVOKED.

We can create consent as shown below –

5. User Data Mappings

User data mapping stores the meta data between the relationship of user and the actual data for user. We also need to provide the resource attributes, which help us know what kind of data is being mapped. In our example, we have created a resource attribute, data identifiable, and we can select values for this attribute.

We can register user data mapping as shown –

6. Access Determination

Access determination requests always ignore consents that are expired, revoked, or rejected.

A. Check Data Access

Allows you to request an access determination for a specific data.

For example, you can pass request attribute, in our case, requester identity

== external-researcher along with the data, we want to query for, in return

we’ll know if there is an active consent present to access this data for

given resource attribute.

B. Evaluate User Consents

Allows you to request an access determination for all data elements associated with a user.

For example, you can pass request attribute and resource attribute, in our case, in return we’ll get the list of all data ids that have active consent present for the given combination of resource and request attribute.

C. Query Accessible Data

Allows you to request an access determination for an entire consent store. This method returns all data elements within a consent store that have valid consent. We need to pass cloud storage destination where the list of results is saved. For example, you can pass request attribute and resource attribute, and in return we will get the list of all data ids that have active consent present for the given combination of resource and request attribute.

We will also get the operation Id which is a process of saving the result on the destination.

We can track the status of operation using below API –

Custom Web Application Implementation

1. Application Requests for Patient Data

On this screen a user with clinical-admin is requesting for patient data with user id 1001.

2. Message for Missing Consents

On this screen a message is displayed as there are no active consents provided by the patient.

3. Request for Consent from Patient

On the same screen user can request for consent from the patient to view data.

4. Patient Approves Consent

A request is sent to user for approval of consent to allow access to its data.

5. App Displays Data

Once the consent is approved, this patient data is available for the app to use. The time to go live for this consent is set to two mins which means that the data becomes accessible for the next two mins.

And there you have it! You have successfully implemented Consent Management API for your application. With this, you can ensure enhanced data security and maintain privacy for your patients. Reach out to us at Nitor Infotech to learn more about Consent Management API and read our whitepaper on API developer portal that will facilitate greater flexibility, improved turn-around time, and provide a seamless developer experience.