**4. BET-LPHR**

The BET-LPHR consists of two partitions of data: 1) patient self-generated PHR such as data from personal wearable devices; 2) PHR data replicated from the EHRs the patient has visited.

**Figure 2** illustrates the BET-LPHR model. VistA\_EHR\_A and VistA\_EHR\_B represent the EHR providers that the patient has visited. The patient, VistA\_EHR\_A, and VistA\_EHR\_B form a trusted network and are connected by HF BeNGAC policy secure channel. The patient (considered as one organization in this setting) and the two EHR organizations share the same access control policies. "The patient has full

**Figure 2.** *BET-LPHR model.*

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

control of granular permissions on his or her own LPHR" [3] using the shared access control policies that are realized via a Web-based interface presented to the patients. "The blockchain based peer-to-peer BeNGAC database avoids racing condition during policy reinforcement" [3]. The data sharing operates on a different type of HF communication channel, HF data secure channel. The patient and VistA\_EHR\_A constitute a trusted HF data secure channel. The patient's PHR data in VistA\_EHR\_A (triangle shape) is copied (disclosed) to the patient's BET-LPHR. Similarly, BET-LPHR has a PHR copy (square shape) from VistA\_EHR\_B on a different HF data secure channel. BET-LPHR is distributed to three organizations. Among the trusted HF data sharing channel, BET-LPHR is decentralized (or peer-to-peer).

At a high level, BET-LPHR data flow is summarized in **Figure 3**. The patient and the EHR organizations are communicated via Fast Healthcare Interoperability Resources (FHIR) interface to ensure interoperability. "Digital certificate guarded secure authentication and BeNGAC policies meet the LPHR security and privacy requirements" [3]. Both NGAC and HF are enterprise scalable, so BET-LPHR is enterprise scalable to meet LPHR scalability requirement. The authentication to BET-LPHR relies on asymmetric cryptography private keys. Data in transit is encrypted by the public key and protected by transport layer security (TLS). Data at rest in EHR's silos are protected by the encryption methods the EHR organizations freely choose.

BET-LPHR offers unique event processing capabilities, such as prohibition or obligation, that is inherited from BeNGAC. This fills a gap in traditional access control model when handling insider threat. For example, in RBAC, a doctor is authorized to read a patient's record, but a nurse is not. The RBAC does not prohibit the doctor copy and paste a record to a file that the nurse has permission to read. In BET-LPHR, this is remediated by the prohibition policy as the following [3]:

"Configuration Rule 1: When process *p* performs ð Þ *r*, *o* where *o* ! *med*\_*rec* do create *u*\_*deny p*ð Þ , f g *w* , ¬*o :* Configuration Rule 2: When process *p* performs ð Þ *copy*, *o* do create *u*\_*deny p*ð Þ , f g *w* , ¬*o* "

The doctor authenticates with a user session and the session launched a read (*r*) process (*p*). When the process *p* performs a *read* or *copy* operation on an object which is assigned to the patient's medical record (med\_red) attribute, it triggers a prohibition condition to deny writing to an object that is not the object being read.

The LPHR requirements are fulfilled by the BET-LPHR design and are summarized in **Table 2**.

**Figure 3.** *BET-LPHR architecture.*

#### *Blockchain Applications – Transforming Industries, Enhancing Security, and Addressing Ethical...*


#### **Table 2.**

*BET-LPHR requirements fulfillment.*
