**5.2 When the BET-LPHR owner cannot directly authorize the access to the third party**

"In general, the BET-LPHR owner can grant permission to a legitimate third party, for instance a specialty doctor he or she will visit during a referral encounter. There are situations such as emergency departments visit, where BET-LPHR access is desired by the ER physicians to make better decision of a care plan by using the patient's BET-LPHR information such as medications taken, allergy conditions, recent doctors' visits, chronic diseases, and recent laboratory test results [29]. However, as a limitation that the patient need to directly grant the permission of BET-LPHR to the doctors in ER, it is not uncommon that the patient is unconscious and cannot authorize the access of his or her BET-LPHR to the doctors in ER facility" [3].

We propose a viable solution using BeNGAC RBAC and Discretionary Access Control (DAC) policies with obligations in the following example (**Figure 5**):

In this scenario, an object attribute Joyce\_Taylor\_SharedWith\_ER\_Doctor is created during user profile initialization. A user attribute ER\_Doctor is also configured with read only permission on Joyce\_Taylor\_SharedWith\_ER\_Doctor. The patient's subset of BET-LPHR that are required during an emergency department visit are assigned to the object attribute Joyce\_Taylor\_SharedWith\_ER\_Doctor. The information includes the current medications taken, patient's chronic allergy conditions, doctors' visits in the past 3 months, patient's chronic diseases information, and laboratory test results in the past 90 days. The information is automatically assigned to the Joyce\_Taylor\_SharedWith\_ER\_Doctor when a new BET-LPHR record is added either by the encounter during doctor's visit in VistA\_EHR\_A or when patient records a new self-generated health record to the BET-LPHR. Additionally, a retrospective process can run on demand to assign or unassign patient's BET-LPHR to the Joyce\_Taylor\_- SharedWith\_ER\_Doctor.

When the patient is in an emergency department and lost consciousness, the ER physician can send a request to the patient's BET-LPHR administrator along with doctor's identification for a temporary account in patient's BET-LPHR. The doctor (Edward) with this account is assigned to the ER\_Doctor role. The account will be disabled after 72 hours of account creation. The following obligation rules are reinforced:

*Perspective Chapter: Blockchain-Enabled Trusted Longitudinal Personal Health Record DOI: http://dx.doi.org/10.5772/intechopen.106454*

#### **Figure 5.**

*Indirectly authorize BET-LPHR access to ER physicians.*


### **5.3 Comparison with prior work**

## *5.3.1 HealthChain*

Hylock & Zeng presented HealthChain [30], a proof-of-concept study of patientcentric health record management framework based on blockchain technology. The authors argued patients' health information in current tethered EHRs are inclined to fragmentation due to distributedness of patient records, which leads to poor care coordination. Hylock & Zeng pointed out ONC information blocking discouraged patients' engagement. Therefore, the authors proposed a mixed-block permissioned blockchain solution coupled with FHIR, the interoperability standard. The mixedblock blockchain consists of immutable logs blocks and editable patient blocks, while large size multimedia data are kept off chain at EHR's silos and only reference pointers are stored in patient blocks. HealthChain acts as "an interface between patients and providers or payers" [30]. The authors claimed security was ensured by implementing permissioned blockchain, and only trusted parties including patients could make changes. The privacy or confidentiality was protected by smart contract and 2-party proxy re-encryption decryption.

In HealthChain, the patient data are on the blockchain, which motivated the authors to redesign the data allocation strategy with patient block data consolidation for a certain patient via Chameleon hashing [31]. The blockchain patient block is redactable (or editable). On one hand, Hylock & Zeng regarded consensus and immutability, which are the core properties of blockchain technology, as shortcomings of computing performance and cost barrier when data blocks are being modified [30]. The authors argued modifications to existing patient blocks could avoid costly consensus. On the other hand, the authors stated using blockchain and smart contacts in HealthChain could meet the HIPAA privacy and security rules requirements. Therefore, if core features of blockchain technology, consensus and immutability, were identified as roadblocks to HealthChain sketch, the applicability of blockchain technology to such a design should be reconsidered. Furthermore, keeping patients' data on-chain is not practical at enterprise level. This design could not scale when number of patients and providers are increasing.

Compared with HealthChain, BET-LPHR patient data is off-chain in a "private database while the audit logs are on-chain" [3]. BET-LPHR is enterprise scalable. BET-LPHR provides privacy and confidentiality protection via BeNGAC.

#### *5.3.2 MedRec*

In August 2016, Ekblaw, Azaria, Halamka, & Lippman prototyped an Ethereum blockchain based MedRec 1.0 [32, 33] for EHR and medical research data to engage patients as agencies to their own health records. MedRec acts as an interface between providers' EHRs and patients. The patients EHRs data are siloed at providers' data centers, while patients are presented a local cached database to patients' records. Through MedRec patient-provider relationship (PPR) smart contract, a certain degree of fine granular access control to patients' health records is achieved by checking on or off fields of medical records steered by patients via a graphical application portal. The MedRec Summary Smart Contract (SSC) weaves PPR smart contracts together to form a holistic view of a patient's medical records from all providers by integrating the reference points to PPRs. The SSC is persistent on the blockchain, which offers flexibility to patients or providers to re-join the network and recover from a system disaster. The MedRec Registrar Smart Contract (RSC) links a patient's existing EHR participant ID to an Ethereum cryptographic public key identifier. The identification registration process is controlled by limited authorization institutions. In MedRec, any changes to a patient's records on a provider's EHR requires an acknowledgment of acceptance or rejection from patient's client. In MedRec, the authors argued the authentication, confidentiality, and data sharing accountability are managed by blockchain smart contracts.

There are few drawbacks in MedRec design. Firstly, when creating a new medical record in provider's EHR, MedRec requires the provider to compose a query string that retrieves that part of data and associate a hash of the query output to guarantee data integrity. However, before a patient accepts this new change, this new record is not in patient's holistic view nor treated as patient's genuine data by the patient. At this point, a hacker (either internal or external) can disclose this new record to a third party without notifying the patient, which violates privacy and confidentiality of the patient record. Secondly, since any change to a patient's records on provider's side

*Perspective Chapter: Blockchain-Enabled Trusted Longitudinal Personal Health Record DOI: http://dx.doi.org/10.5772/intechopen.106454*

requires patient's communication to accept or deny the change, if for some reason, the patient cannot respond to the communication, the authors did not explain the results of those affected records. Thirdly, Proof-of-Work (PoW) was implemented as a mining approach, which consumes excessive computing energy.

In 2019, Nchinda, Cameron, Retzepi, & Lippman introduced a new architectural design of MedRec 2.0 [34]. The MedRec 2.0 replaced PoW with computing cost saving Proof-of-Authority (PoA) based on the trusted participants of EHR data providers on the blockchain network. The MedRec 2.0 is an open-source solution, claimed by authors to be a robust approach with small system resource consumption overhead to the existing EHRs. However, the scalability needs to be tested when more health care community users adopt the solution.

In contrast to MedRec, BET-LPHR does not require the patient to confirm denying or accepting changes when adding a health record. Furthermore, BET-LPHR uses HF consensus so it eliminated the consensus overhead of PoW or PoA.
