## 5 Results and Discussion
### System Implementation Details
#### 5.4.3 Environment Setup  
After all the pre-requested development tools are installed, the system will start a test network with the following:  
* One orderer;
* Four organizations with one peer per organization;
* One CouchDB instance per peer;
* CA server for the peers and orderer;
* One chaincode per organization.  
The Hyperledger Fabric framework was installed and configured on the Ubuntu operating system. Figure 6 shows the installation of the Hyperledger, and Figure 7 shows the installed Docker containers. Docker containers simplify the running and deployment of  
Figure 5: System implementation process.  
Hyperledger Fabric's different tools. After the installation process, the network and consensus protocol configurations are followed by channel creation, as shown in Figure 8. The third part is the Hyperledger Fabric system's SDK, as explained in the high- and low-level architectures and scenarios. This part deals with the execution of the chaincode through which the transactions of the PHR system are operated and then stored in the ledger.  
**Implementation Overview**  
The PHR system was developed for mobile applications to ensure that it can be with patients who are on the go. For decentralization, our scheme stores medical data using CouchDB rather than a semi-honest and curious cloud server; this further protects the privacy of the medical data. In addition, the IPFS allocates a unique hash for each file.  
**PHR**  
As mentioned earlier, a vital requirement of the blockchain-based PHR is the provision of different levels of control to different types of users, which means that participants can be restricted to reading, creating, updating, and/or deleting rights. With the different  
Figure 8: Chaincode deployment in channel and policy.  
Figure 6: Hyperledger Fabric binaries.  
Figure 7: List of installed Hyperledger Fabric tools in Docker containers.  
permissions and roles, the number of users accessing the patients' data is significantly reduced, reducing the risk of a data breach [30]. The healthcare center is authorized to add physicians and patients to the system. The network administrator has full permission over the network, i.e., is allowed to add organizations and view all participants. They also manage researchers, check their identity, and approve them. Figure 9 illustrates the administrator page to approve or add a researcher.  
Figure 10 illustrates a PHR profile, which includes a patient's details, wallet, and the option for whether they would like to appear to researchers for the sharing of their data. Another requirement is access control; Figure 11 shows the access control, where patients can approve or deny access to PHRs. In addition, there is a place for appointment reservations where patients can reserve appointments with a physician, a laboratory, etc. As shown in Figure 12. Relatives' access is restricted to a specific period of time, and the patient's relatives need to approve the request, which is shown in the profile, as illustrated in Figure 13. Once approved, the relatives will appear in the patient profile. For emergency access, the patient will appear in the emergency section. Patients determine whether physicians can access basic information, allergies, or full details, as shown in Figure 14. Moreover, access to the patient's profile is restricted according to an amount of time that is determined by the patient, as shown in Figure 15.  
Figure 10: Patient profile.  
Figure 9: Administrator page.  
Figure 11: Access control.  
Figure 12: Appointment reservation.  
Figure 14: Emergency access.  
Figure 13: Relatives’ Access.