Patient Consent Management by a Purpose-Based Consent Model for Electronic Health Record Based on Blockchain Technology.

OBJECTIVES: Currently, patients' consent is essential to use their medical records for various purposes; however, most people give their consent using paper forms and have no control over it. Healthcare organizations also have difficulties in dealing with patient consent. The objective of this research is to develop a system for patients to manage their consent flexibly and for healthcare organizations to obtain patient consent efficiently for a variety of purposes.
METHODS: We introduce a new e-consent model, which uses a purpose-based access control scheme; it is implemented by a blockchain system using Hyperledger Fabric. All metadata of patient records, consents, and data access are written immutably on the blockchain and shared among participant organizations. We also created a blockchain chaincode that performs business logic managing patient consent.
RESULTS: We developed a prototype and checked business logics with the chaincode by validating doctors' data access with purpose-based consent of patients stored in the blockchain. The results demonstrate that our system provides a fine-grained way of handling medical staff 's access requests with diverse intended purposes for accessing data. In addition, patients can create, update, and withdraw their consents in the blockchain.
CONCLUSIONS: Our consent model is a solution for consent management both for patients and healthcare organizations. Our system, as a blockchain-based solution that provides high reliability and availability with transparency and traceability, is expected to be used not only for patient data sharing in hospitals, but also for data donation for biobank research purposes.

I. Introduction

For the last decade, digital transformation has been an important development in all industries, and it is also happening rapidly in the healthcare field, bringing positive changes. Patient records are now more efficiently stored and transmitted. They can be effectively shared among hospitals where patient visits are logged through Electronic Health Record (EHR) systems, thus reducing the inconvenience and burden for patients. Stored patient data may be collected with the patient’s permission to make a big data, which enables healthcare providers to analyze it and to offer personalized services. It is also expected to contribute to medical and pharmaceutical research. However, before the sharing and use of patient data, it is mandatory to obtain patient consent.

In the context of healthcare information, consent [1] refers to patients’ granting requestors access to their records stored in the health record system. Furthermore, in the context of healthcare professional and patient interaction, informed consent [2] refers to the voluntary agreement given by the patient before having a medical treatment. In any case, a patient’s consent is essential, and traditionally, it has been given using paper-based [3-5] forms with the patient signature at the end. Once submitted, it is difficult for patients to change their decisions, which makes them cautious in signing papers, and they tend to be reluctant to share their data with others.

To address the above problem, various types of e-consent [6,7] have been introduced that allow patients to give consent electronically with their digital signatures and to withdraw it later if necessary. So far, most e-consent models are based on a centralized architecture, and some are built with trusted third-party delegation to evaluate patient consent and guarantee it [8]. There are also decentralized models that employ blockchain technology [9,10]. Among them, the Dwarna project [11] provides a well-designed web portal for dynamic consent that harnesses the blockchain ledger, which acts as a hub connecting participants in the biobank project.

Meanwhile, we introduce an important aspect of a data access control model, so-called purpose-based access control, which confines the usage of a patient’s data to the prior intended purpose designated by the patient. Byun and his colleagues [12,13] proposed a model for relational databases, in which purpose information associated with the given data specifies the intended use of the data. Their proposed solution relies on the well-known role-based access-control (RBAC) model, in which data access permissions are assigned to functional roles within an organization that has a role hierarchy. Later, Kabir et al. [14] improved the model by suggesting conditional purpose-based access control for dynamic roles.

In this paper, we propose an e-consent system that has a fully decentralized architecture based on the blockchain. We adopt a purpose-based access control scheme adapted from RBAC model. The system enables patients to give their consent flexibly. In this work, there are two main contributions for the management of patient consent across different organizations: (1) allowing patients to manage their consent specifically by assigning their intended purpose of the use to each piece of data and (2) allowing healthcare organizations and research institutions to obtain patient records for future needs based on patients’ consents.

We use a consortium blockchain platform, Hyperledger Fabric (HLF) [15,16], to build a secure channel in a network among participant healthcare organizations. Patient consent is written on the ledger of the blockchain along with the address of the patient’s record, its metadata, as well as hash values of all the data, whereas patient records are stored off-chain in the relevant EHRs. However, the patient consent also can be stored off-chain along with the patient records. Malicious modification of the data on the blockchain is practically impossible, and the data integrity is preserved by comparing the hash value on the blockchain with that of the received one.

II. Methods

In this section, we explain the purpose-based access control scheme and how it is adapted for our patient consent model, including the way a data request is made in the model. Then, we briefly present blockchain and HLF, followed by our system concept and how it works.

1. Definition of Purpose

A purpose is defined as the reason for data collection and use [12]. It is the main keyword of a patient’s consent, because the patient decides to confine the collection and use of their data within a certain range of a specified purpose. In that respect, purpose has its scope of coverage, narrow and wide, and it can be organized in a hierarchical tree structure, a so-called purpose-tree, as shown in Figure 1. The top node of the tree is the general purpose, which has the widest scope containing its descendant purpose nodes. Each connection line from one node to another represents their relationship in the purpose-tree. The purpose-tree represents the common goal of the organizations for exchanging data with each other. The purpose-tree is so closely related with the privacy policy that member organizations need to agree on its structure and attributes.

Figure 1

Example purpose-tree.

The purpose associated with data, regulating access to the data, is referred to as the “intended purpose”, and the purpose for accessing data is referred to as the “access purpose” [12,13]. Usually, intended purpose is described in a patient consent in advance; it states the purpose for which the data can be accessed. Thus, when a requestor asks for access to data, they should clarify the access purpose, which is checked against the intended purpose of the data written in the patient consent. If the two purposes match, the system allows the requestor to access the data. The matching rule is provided by the consent model, which stipulates how the patient consent describes the intended-purpose and how a requestor prescribes an access request with the access purpose. In a general consent model, for instance, when a patient chose “MedicalTreatment” as the intended purpose for a data access, the system only allows requestors to access the data when their access-purpose matches with the intended-purpose, “MedicalTreatment” or its descendants in the purpose-tree. Figure 2 shows the purpose-tree of Figure 1 converted to a JSON array type stored in the blockchain.

Figure 2

JSON array-type of the purpose-tree of Figure 1.

2. Consent Model and Consent List

As previously mentioned, when a patient gives consent to usage of his or her data, it is confined within the specified intended purpose. In addition, patients usually give healthcare professionals different levels of permission according to their roles. In the RBAC model [14,17], the role represents the job function or job title in the organization, and it is defined in the role hierarchy. Access privilege is given based on the job title. It eases data owners to allow requestors data access based on the requestor’s role rather than pointing to the user in the organization.

In our consent model, we adapt the purpose-based access control scheme and RBAC’s concept. The patient consent in our model contains the intended-purpose of data access and the specific user’s role. However, we do not use role hierarchy; rather, we make our model as simple and clear as possible with a generally acceptable structure. We modified the intended-purpose-based model of Byun and his colleagues [12,13].

The data access control in our consent model adopts basically whitelisting with an exception that the patient can make some designated blacklists within a whitelist. The consent model and rules are presented in Table 1.

Table 1

Consent model and its rules

Consent model

Rules

Each consent consists of four main tuples expressed as follows:<Role; AdmitteeIds; Action; Intended-Purpose> - Role: Job title or job function of requestor who has their specific eID (it is id of Enrolment certificate and explained in section 5). Examples are Cardiologist, Physician, etc. - DoctorID: Patient can add some designated doctors or healthcare professionals such as family doctor or medical specialist etc., who are allowed to access to the patient data. Their eIDs are listed here, or this element may remain blank. - Action: The activity on the data. Examples are Copy, Read, etc. Actions can have access privilege levels, so that the privilege of Copy includes that of Read, and the opposite is not allowed, i.e., Copy ⊃ Read. - Intended-Purpose: This element consists of two tuples as follows: <AIP; PDP> where AIP is Allowed Intended Purpose and PDP is Prohibited Descendant Purpose. AIP contains PDP, as the former is the ancestor of the latter.

Role and DoctorID are basic qualifiers necessary to specify requestor’s legitimacy. One of these two and the other two tuples should be simultaneously complied by the requestor, i.e., (Role ⋁ DoctorID) ⋀ Action ⋀ IntendedPurposeA data access is allowed only for the AIP that are explicitly written in a patient consent for the data, making all the other purposes implicitly prohibited one.Multiple AIPs constitutes a whitelist, for which data access is allowed.If an AIP has descendant purposes in the purpose-tree, then all of the descendants are also allowed purposes, belonging to the whitelist except some specific ones.Some of descendants of an AIP can be as PDP, for which data access is not allowed, such that, ∃ PDP ∈ AIP.Multiple PDPs under an AIP constitutes a blacklist (BlackList), consisting of a subset of the ancestor AIP, such that, ∀ PDP ∈ BlackList ⊂ AIP.If a PDP has descendant purposes, then all of the descendants are also prohibited purposes without any exception, belonging to the BlackList, equally saying that there is no AIP that is a descendant of PDP, such that, ∀ AIP ∉ PDP ⊂ AIP. This rule brings about simplicity in our model.

To respond to various demands for data access from diverse requestors, a patient can make a list of consents for the data. The patient consent list is made by binding together multiple consents in combination with a variety of roles and intended purposes. If an access request matches one of the consents in the list, the data access is allowed. Figure 3 shows a simple example. In our system, a consent is stored in a blockchain with its hash value and the metadata of the relevant patient records. However, it also can be stored off-chain along with the patient records.

Figure 3

Simple example of a patient’s consent for a specific data in the state database.

3. Access Request

When a requestor asks for data access, he or she must possess proper qualification and must state an appropriate purpose for the access. After the requestor’s role and the access purpose are validated successfully, the system allows the access within the designated activity on the data.

Actually, when a requestor tries to obtain some patient data for any purpose, he or she sends the system a query having data attributes for a data search together with the access request and additional helpful keywords. The data attributes and the keywords include patient-related information, hospital, department, doctor, disease, time and date, demography, and so forth. After obtaining the target list, the system starts to validate the access request with the patient consent pertaining to each of the candidates. Table 2 shows the access request and validation rules.

Table 2

Access request model and validation rules

Access request model

Validation rules

In our system, the access request has simply two tuples<Access-Purpose; Action> - Access-Purpose: The data requestor’s purpose of using the data - Action: The activity on the data. Examples are Copy, Read, etc., having access privilege levels the same as in the patient consent.

Whether a data access is allowed or not depends on the relationship between requestor’s Access Purpose (AP) and Intended- Purpose in the patient consent. The following is basic compliance rule to which access request is subject. - If AP is included in Prohibited Descendant Purposes (PDP), the access request is rejected at all, i.e., AP ∉ PDP - Any of consent, which has Allowed Intended-Purposes (AIP) that is ancestor of AP, allows the access requests excluding PDP in the AIP, i.e. AP ∈ AIP and AP ∉ PDP ⊂ AIP

Among the four main tuples in patient consent of our model, the requestor’s role and eID are usually invariable, and they are registered in the system or the organization to which they belong. Thus, the access request contains only variable elements, access purpose and action. The requestor is authenticated by the system using the eID, and the requestor’s role is also identified by the system, which can consult participant organizations if necessary.

Figure 4 shows a case in which a nurse wants to read a patient’s data, and submits an access request with data attributes and keywords for the query. The system produces a resultant list of data and then checks the patient consent pertaining to each piece of data in the list. If the access request matches with the patient consent, then the requestor can have access to the data and take action on the data. In this case, she can read data for general purposes, except education and mental illness-related purposes.

Figure 4

Validation of requestor’s access request with patient’s consent list.

4. Blockchain Platform and System Conceptual Design

A blockchain is a group of blocks containing all the transactions in a designated network and shared among participants of the network. Each block is linked [18,19] to the next by its hash value stored in the next block as shown in Figure 5. This structure makes the blockchain immutable; if someone tries to alter certain data in a block, they must recalculate hash of the block with the forged data, continuing to the last block, and replace the blockchains of all other nodes with the forged one.

Figure 5

Typical structure of a blockchain.

Blockchains are widely categorized into two types, public and private, the latter usually subdivided into consortium and private according to the purpose of use and features of members of the systems [20].

As the blockchain platform, we use HLF [16], which is a consortium blockchain in that all the participants are identified in the network of a consortium. The ledger of HLF consists of a world state database and a blockchain. The former contains the final state of variables of the program, so-called chaincodes, while the latter consists of all transactions that cannot be altered once written. HLF provides a membership service provider (MSP), which offers membership operations providing all cryptographic mechanisms and protocols behind issuing and validating enrolment certificates (ECerts and its ID called eID) of users and user authentication with the local certificate authority (CA). HLF also provides three main user roles, client, endorser, and orderer. Each endorser invokes the chaincode to endorse a tentative transaction, a so-called proposal, after validating it. An orderer wraps endorsed proposals into a block and distributes it among peers to append in the blockchain [16].

We adapt the same system design to our previous research [21] as shown in Figure 6. It has a channel that is built for exchanging patient records among participant hospitals, which are connected to independent EHR systems. Each member must have an ECert issued by the membership service provider, and its ID is used as the member’s ID in the system, which stores the user’s role. If not, it can consult the participant hospitals. Each proxy of a hospital communicates with other hospitals and is involved in proxy re-encryption to protect patient data.

Figure 6

Channel of hospitals for exchanging patient records in an Electronic Health Record (EHR) system.

5. Procedure of Chaincode

A chaincode is a program that performs business logic agreed by members of the network; it works in the same way as a smart contract in Ethereum. It is run by endorsers to access a blockchain through transactions [16]. We created a chaincode to handle patient consent. The following describes the chaincode’s operations.

1) Consent management

This function manages patient consent, allowing a patient to make a query for past records, review the consent and update it in a blockchain as shown in Figure 7. First, it checks the validity of the proposal’s format and intended purpose with the purpose-tree. Then, it queries for the consent policies and medical record transactions in the blockchain based on the patient’s eID. The patient can update his or her consents by appending new ones to the relevant medical record transactions.

Figure 7

Pseudocode of a part of a chaincode for patient consent management.

2) Consent check

This function checks a requestor’s access request with the patient’s consent stored in the blockchain as shown in Figure 8. After extracting the proposal, it checks the validity of the proposal’s format and the requestor’s role in the organization. Then, it queries for transactions in the blockchain based on searching keywords in the proposal. After querying successfully, the chaincode compares entities of access request in the proposal with attributes of the patient’s consent in the transactions. Finally, the chaincode only sends transactions for which the patient’s consents match the access request. As previously mentioned, transactions in a blockchain contain records’ URLs in EHR systems, which are used to identify the location of patient medical data.

Figure 8

Pseudocode of a part of a chaincode for patient consent check.

III. Results

1. Prototype System

We built a prototype system in a local network with four Linux PCs to provide a user interface to patients and doctors who made and sent requests to the blockchain system. Four endorser peers were made in the PCs, which invoked chain-codes in the Docker (https://www.docker.com/), where the HLF platform was installed. In addition, MSPs of HLF were installed in two of the PCs separately.

2. Prototype Analysis

We evaluated the prototype system with the following targets: (1) to check the integrity of data of history, which included creating, withdrawing, and updating patient consent; (2) to check the chaincode’s function of validation of the provided intended purpose and access-purpose with the purpose-tree; and (3) to investigate whether the chaincode worked correctly in validating the access request of a doctor with the patient’s consent for data access.

We could identify a peer that had a wrong blockchain because it was intentionally provided with wrong query results. During the process of building a block, the consensus protocol of HLF can check it by comparing results from all endorser peers. The processing time required to validate an access request depended on the complexity and length of the purpose-tree and the consent list in the individual transaction. Simultaneously, the speed of validating the proposal is based on the privacy policies and the legal requirements set by the consortium.

IV. Discussion

The patient’s consent plays a crucial role in preserving the patient’s privacy in healthcare data sharing. If restrictively given, it would cause inconvenience in dealing with the data, while indulgently given, patients would be exposed to the risk of privacy disclosure. Accordingly, patients want to monitor how their data is used based on their consent. Without appropriate measures, they tend to be inactive in data sharing and even reluctant to provide data for research purposes.

In this paper, we proposed a new type of e-consent system for patients to manage consent elaborately in dealing with their data. We adopted the purpose-based access control scheme from the RBAC model of a relational database [12-14]. Our system also has a hierarchical structure of the user’s intended purposes, but it does not have a hierarchical structure for user roles; combining both hierarchical structures makes consent too complicated for patient to understand when they apply it to their data. RBAC, from its name, is role-based and hospital-centric, whereas our concept is patient-centric.

Our system is different from most purpose-based centralized systems, in that ours is a fully decentralized blockchain approach. The Dwarna project [11] also provides a blockchain solution for dynamic consent in biobanking; however, they use boolean-based consent to allow requestors to access data because the purpose is very simple in their research.

To share data among multiple organizations, participants must reach an agreement with a common privacy policy that might compromise each member’s unique feature in their own policy. It may be desirable for the purpose-tree to cover all participants’ usable purposes with plenty of branches in each node; however, it leads to complexity and reduction of data usability. To address these discrepancies, we tried to make the rules of our model simple and generally acceptable.

In reality, the purpose-tree could be updated by the agreement of participant organizations for some reason, such as when their privacy policy is updated or a new member organization is added. In such a case, it would be difficult to interpret patient’s consent based on the new purpose-tree, so all the organizations would need to get new patient consents again. However, the contract with a patient can prepare in advance a description of how to deal with this kind of situation.

The European General Data Protection Regulation (GDPR) [22,23] states that data subjects, i.e., patients, have the right to request the erasure of personal data related to them, the so-called right of erasure. Apparently, this is considered incompatible with the blockchain’s immutability, so it is a big challenge for all blockchain-based systems to comply with this type of request. To address this difficult problem, our system stores patient records off-chain in EHRs. In addition, it makes each transaction on-chain have a unique hash number of the patient’s eID with a random number, a so-called salt [21,24], to thoroughly pseudonymize the data owner, even though this sacrifices data searching performance. The link that connects the randomized patient eID to off-chain records resides in the off-chain database [11], and in case a patient asks for his or her data to be erased, the system removes the link and off-chain record. The URL written in the transaction, which is the address of the data site in the EHR, might be a clue to specify the patient; however, it is very difficult to do that because the URL is shared with many other patients. The patient consent may be stored off-chain along with the patient record, and the hash remains on-chain to maintain the integrity.

Our system has high reliability and availability as well as transparency and traceability, which are common prominent features of the blockchain system. Transparency and trace-ability are considered especially important in dealing with patient consent to ensure that patient data is shared properly. We expect that our system can be used as a solution not only in patient data sharing between hospitals, but also in data donation for research purposes in biobanking.