## 4 Proposed Framework
### Module I: Increase Integrity, Availability and Confidentiality by Using IPFS and Fabric  
In the previous solution, the EHRs records were stored in the healthcare provider's local database. This means that the integrity, confidentiality, and availability of these EHRs depend on the provider side's security level, who is continuously under cyberattack. To improve the protection of EHRs, healthcare providers can save them in a distributed database, such as the Interplanetary File System (IPFS) as shown in Table 5. EHRs provided by a laboratory with a public key \(k_{l}\) are saved in IPFS as a file \(F\) containing \(\{EHR\}_{k},\{k\}_{k_{l}}\), where \(k\) is a random symmetric key. If we also want to give access to users with public keys \(pk_{1},\ldots,pk_{n}\), then we save a file \(F\) containing \(\{EHR\}_{k},\{k\}_{k_{l}},\{k\}_{pk_{1}},\ldots,\{k\}_{pk_{n}}\). This transparent protection technique gives us more confidence that the EHR confidentiality is appropriately protected. Additionally, IPFS provides good availability since it is a distributed database with sufficient redundancy, allowing access to files even if some storage nodes become offline. Moreover, to avoid the doctor having to directly contact the laboratory to obtain the address of the file \(F\) containing the EHRs of a patient identified by \(DID\), we save \((DID,H(F))\) in Hyperledger Fabric. Using Fabric for this purpose, we increase the integrity of \(F\) and its availability. The new architecture is as shown in Figure 4. \begin{table}
\begin{tabular}{|p{56.9 pt}|p{56.9 pt}|p{56.9 pt}|p{56.9 pt}|p{56.9 pt}|p{56.9 pt}|p{56.9 pt}|} \hline \multicolumn{1}{|c|}{\begin{tabular}{c} During transmission \\ Provider to Patient \\ \end{tabular} } & \multicolumn{1}{p{56.9 pt}|}{\begin{tabular}{c} \multirow{2}{*}{\begin{tabular}{c} \multirow{2}{*}{\
\begin{tabular}{c} \multirow{2}{*}{
\begin{tabular}{c} During transmission \\ Patient to Consumer \\ \end{tabular} \\ \end{tabular} } \\ \end{tabular} } } \\ \hline EHR protection & public key of Patient & public key of Patient & public key of Consumer \\ \hline \end{tabular}
\end{table} 
Table 8: EHR protection. More precisely, the new solution works as follows:  
1. First, the patient visits a laboratory and receives some service that creates new healthcare attributes, \(at_{1},\ldots,\ldots,at_{n}\). At any moment later, he can send a request to associate a \(DID\) to any parts of his attributes. He can also, at the same time or any moment later, send a delegation \(\{EHR\}_{k},\{k\}_{k},\{k\}_{pk_{1}},\ldots,\{k\}_{pk_{n}}\) to the laboratory. If the patient wants to give new principal access in the future, he can send a new delegation to the laboratory, and a new entry will be added in the IPFS, or we update the previous one. Notice also that we can handle the delegation as in the previous architecture, but with IPFS, we can immediately concretize it by giving access to the keys protecting the EHRs to all the authorized principals. 2. The laboratory checks the patient's identity and verifies that he owns the public key \(kb\) associated with the \(DID\). 3. The laboratory adds to Indy a certificate linking \(DID\) to \(kb\). 4. The laboratory creates the file \(F\) containing the requested attributes encrypted with its key and all the keys given within the delegation and saves it in the IPFS. 5. The laboratory adds to Fabric a certificate linking \(DID\) to \(H(F)\) (\(H(F)\) is the address of \(F\) in the IPFS). 6. The patient contacts the doctor [PERSON] and asks for a healthcare service and provides the \(DID\) associated with his attributes that he wants to share with her. 7. [PERSON] obtains the public key \(kb\) associated with \(DID\) from Hyperledger Indy. 8. The doctor asks the patient to prove that he owns the public key \(kb\). 9. The doctor obtains \(H(F)\) associated with \(DID\) from Hyperledger Fabric. 10. The doctor obtains the file \(F\) with the address \(H(F)\) from IPFS. 11. The doctor uses her public key to decrypt the EHRs of the patient.