## 3 Related Work
### Working Procedure  
The client must by registered on the home station (HS) to be eligible to receive the services of the system. Algorithm 1 shows the working procedure for the registration of a client on the HS, in the case in which a patient traveled to a remote station (RS) and required their medical history from their home station. The client needs to open the interface provided by the identity provider corresponding to the HS through a web application, arranged by the patient's own country. Due to the security and sensitivity of healthcare data, the HS does not deliver sensitive information to a non-approved user; however, the HS asks the login credentials to be entered; the system then follows the procedure for authentication as shown in Algorithm 2. It first checks if the client has blockchain network access, and then asks for the client's login credentials. After a successful login, all of the relevant IdPs are displayed, which are authenticated by the HS.  
```
Input: BlockchainAddress Ba, Timestamp Ts, HomeStation Hs, Client Ct, Terms&Conditions Tc Output: Bool
1:if Ct exist then
2:return false
3:else if Ct agrees on Tc then
4: mapping Ct to Ba
5: add it to ledger of Hs with Ts
6:return true
```  
**Algorithm 1: Create_Contract:** Algorithm that create a smart contract in blockchain network  
A blockchain intermediary node is used to save the transactions on the blockchain network. The correspondence between the remote station and the home station is transmitted through this node, which is also associated with the blockchain through Hyperledger Composer. Figure 6 shows the complete working process in a sequence diagram. The Shibboleth identity provider provides the complete list of IdPs for their roles. This is also provided to all of the registered home stations, and these IDs are shared through a signed XML document for security purposes. The HS diverts the solicitations to the Shibboleth for approval of the mentioned job. The web application demands credentials, which are given by the respective IdP, and the HS requires the IdPs to be approved, regardless of their actions or their designation. All of the authentication and security are maintained by the IdP, and the service provider then diverts the resources to the HS, in addition to the approval tokens delivered by the IdP.  
```
Input: BlockchainAddress Ba, Client Ct, Credentials Cd Output: Bool
1:if Ct is not Ba then
2:throw;
3:end
4:if Cd \(\geq\) Approved then
5:return true
6:else
7:return false
```  
**Algorithm 2**Access_Request:** Algorithm shows how a client access its data on network The HS approves the metadata, utilizing the protocols related to the security of the system, and delivers the clinical data in normalized form. The proposed design is based on the HL7 standards, which are presently used in numerous countries, because very little effort is required for their integration into the system. The proposed strategy safeguards the privacy of the entities utilizing the clinical data. It also recognizes the privilege of the patient to acquire the information about these elements, and makes it feasible and scalable for the HS. The distributed deployment and modular architecture lower the deployment burden for all parties involved in the process, and results in a steady change to the new system.  
Algorithm 3 shows how patients and health personnel access the network. The access given to the user (patients) depends on their registration on the network, whereas the heath personnel access is subject to the person's role and the time required to access a document. Creating transactions in the network is restricted only to the specific authorized health personnel, and each access to the network by authorized personnel is stored, such as in a log book in the blockchain.