The flood of valuable data that health tracking devices offer has highlighted the importance of patient consent and privacy. This is while patients and caregivers aim at safely incorporating data from more sources into their care plans.

As we know, factors like data consent and conformance play a key role in data utilization.the integration of Google Cloud Platform Consent Management API with the GCP FHIR service. It allows us to take care of these and present more formatted data to businesses.

With that in mind, I have written this blog that will give you an overview of this crucial architectural component that provides scalable and secure management of your user’s consent and ensures data conformance with privacy via data residing in the GCP FHIR service.

The blog will walk you through:

• Architecture of GCP Consent Management API
• Workflow
• GCP account/service setup
• Integration of WebApp with GCP services (Consent Management & FHIR services)
• Reference code/ Accelerator
• Business outcomes

Let’s jump right into the prerequisites of integrating GCP’s Consent Management API with the FHIR service. Here is a list to help you.

• Overview of Google Cloud Platform and IAM roles
• Healthcare APIs that are enabled on GCP account

1. FHIR guide
2. Consent management guide

Now, let’s focus on the architecture.

Architecture of GCP Consent Management API

Fig 1: Architecture of GCP Consent Management API

Note: FRONT END & BACK-END block in the above diagram is our custom web app that is consuming GCP Consent Management APIs and GCP FHIR services.

Now that you are familiar with the architecture, let’s turn to the workflow.

Workflow

1. WebApp gives the option for the caregiver/practitioner to view patient data if active consent is there else it gives option to request for consent from patient.
2. When the practitioner requests for consent, the patient gets an option to approve or reject the consent.
3. On consent approval from the patient, WebApp creates an active consent with the help of Consent Management API by setting proper resource access policy and consent expiry.
4. When the caregiver/practitioner tries to view the data, Consent Management API validates the consent and retrieves available resources/patient data from the FHIR store if active consent is found. Else it gives a consent expired error wherein the caregiver/practitioner can request for consent again.

Now let’s look at the GCP setup.

GCP Setup / Operations

1. Google Cloud Login:

While using the local machine, you need to make sure that you are logged in to the GCP gcloud CLI with our user account by executing gcloud auth login commands or by using Cloud Shell as per the official Google document.

2. Dataset creation:

The creation of a dataset is the first step while making use of most features in the Cloud Healthcare API.

For our example, we created a dataset named ‘FHIR_dummy_one’ under project ‘graphical-fort-306505′ within location ‘us’.

3. FHIR store creation:

A FHIR store is a data store in the Cloud Healthcare API that holds FHIR resources. FHIR stores can be created.

Created FHIR store ‘store_second’ under the dataset ‘FHIR_dummy_one’.

4. Loading FHIR resources into FHIR data store:

Multiple data resources like Patient, Encounter, Observation and AllergyIntolerance in the FHIR store can be loaded.

5. Consent store creation:

You can use the Consent Store to save the metadata of all the configurations and operations that you will use. For example: mapping between users and their data, policies which will be used to access the data, consent statuses, and signatures throughout the Consent Management process, which can be created as per steps provided officially.

6. Configure consent policies using attributes:

Consent policies are the building blocks of consent resources and can be applied by updating our values to the existing document published by google.

RESOURCE attributes:

• An attribute the value of which is defined by the properties of the data or action. For example, whether data is de-identified or identifiable.
• Send POST request using curl that creates attribute named data_identifiable_1 with resource values like identifiable, de-identified, patient, encounter etc.

REQUEST attributes:

• An attribute the value of which is defined by the requester’s identity or purpose. For instance, professions that are consented for use, like researchers or care providers.
• Send a POST request using curl that creates a REQUEST attribute named requester_identity.

7. Creating consent artifacts:

A consent artifact stores sensitive data pertaining to a user’s consent and can include a user’s contact information, signature timestamps, and images of signatures or other documents that act as “proof” of consent.

Create a consent artifact using the steps on replacing with your values.

8. Creating a consent:

A consent refers to an opaque user ID, the consent policies allowed by the user, as well as the status of those consent policies. Consent can have various states, like ACTIVE, DRAFT or REVOKED.

We can create a consent using the references on replacing with our values.

9. User data mappings:

Meta data between the relationship of user and the actual data for user is stored as a user data mapping.

The ‘DATA_ID’ will be the data that the user data mapping resource refers to. As an example for our integration, we have taken this ‘DATA_ID’ as FHIR store resources.

• We can define data mappings on replacing with our values to register data with the Consent Management API and connected to consents.
• Here ‘DATA_ID’ will be the data that the user data mapping resource refers to e,g for FHIR resource, BigQuery, etc.

Below, we’ve defined mapping for patient resource. Similarly, we need to define mappings for all the resources we need to access from FHIR Store.

10. Access determinations:

Under this, our application can request access determinations from the Consent Management API for a specific data element, for all data elements associated with a user, or for the whole data store.

In the image below, we checked access determination of Clinical admin role for patient resource. Similarly, we can check for all the other roles we need to check for.

11. Fetching data from FHIR store:

We can fetch the FHIR resources data from FHIR store and get it displayed over the UI application side only if active consent is found at the Consent Management API or when patient approves the new consent. We can modify the official reference document commands like we did for our implementation.

• RESOURCE level like Patient, Encounter, Observation, etc

• All RESOURCES associated with a particular patient’s data

Web App/ UI Integration with GCP Setup

Web App provides an interface for the caregiver/practitioner and the patient to consume GCP Consent Management APIs and FHIR store APIs.

• Interface for Caregiver/Practitioner: Practitioners can request consent to view patient data based on their role.

• Interface for Patient: Patients can provide consent to the practitioner by approving the requested consent with the desired visibility time limit.

• Checking consent:

• Requesting consent if no active consent for given role and patient ID:

Requested consent goes into pending state until approved by the patient.

• Consent approval by patient: Patients can see requested consents listed and can approve/reject them along with time limit for data visibility.

• Viewing patient data based on approved consent:

Patient’s data is visible based on practitioner’s role and the approved timeline.

Once the time limit has elapsed, patient data is no longer visible.

On trying to view data again after time limit expiry, a ‘consent expired’ error is shown to practitioner indicating that a new consent needs to be requested to view data.

• Role based resource access: The following image indicates that based on role of practitioner/caregiver e.g., clinical_admin, a different set of resources are accessible which can be in the form of patient data, encounter details, observation guide, or allergy-related stuff.

Reference Code / Accelerator:

You can refer to this link for details about the reference code: GCP FHIR Consent Management using Django – Accelerator

Now, let’s consider the business outcomes of the integration.

Business Outcomes

Take a look at the business outcomes of GCP consent management and FHIR integration:

• With this use case implementation, we can present a proper integration of data from multiple electronic health records using proper user consent management and FHIR service on GCP with Google’s enhanced data security, availability, and privacy.
• The data being presented is in accordance with the compliance support of HIPAA, PIPEDA, and various other global privacy standards that this integration takes care of.
• The GCP Consent Management and FHIR solution implemented allows hospital systems to analyze governed results on FHIR, then send them anywhere: to dashboards in Looker, other BI tools, embedded applications, mobile apps and query the data as per wish on where it resides – in a secure data warehouse like BigQuery.
• Authority to clients/patients for granting temporary access of their data to authorized healthcare professionals with specific roles. The system enforces data access restrictions based on the client’s preferences for different roles like internal researcher, external researcher, or clinical admins.

Well, it’s time for me to wrap up my ideas.

In the world of health data management, the integration of GCP Consent Management API with the GCP FHIR service certainly goes a long way in helping us format data in a better manner. After all, scalable and safe management of your user’s consent as well as data conformance with privacy are important aims.

Mail us with your thoughts about this and visit us at Nitor Infotech to learn about our vision of data.