## 6 Discussion  
The main contribution of this paper is a modular architecture for EHRS. The core of this architecture is Hyperledger Indy, which is specially designed for the self-sovereign identity (SSI), where individuals have full control of their digital identities (a set of attributes that includes medical ones). Indy intrinsically provides many interesting features for EHR management, such as the following:  
* No one can access to healthcare attributes without the consent of their owners. * Patients can remotely prove that they are the owners of their EHRs. * Patients can remotely prove, using zero-knowledge proof (ZKP), that a part of their healthcare attributes respects some properties without revealing their values (e.g., blood pressure is less than 130 mm Hg). * Patients can hide some attributes in an EHR while revealing others. In addition, the initial architecture is upgraded with Fabric to allow access control delegation. This second Hyperledger is used for the storage of the patient's access control policies specified in the ABAC style. The delegation usually simplifies the access control by reducing the intervention of patients. Using Fabric as a generic Hyperledger provides the availability, the integrity and the traceability of access control policies. Finally, we upgraded the architecture by adding IPFS that can play the role of wallets for the patients and increase the availability, the integrity and the traceability of the patients' EHRs. Table 13 evaluates the proposed approach and other related works according to the previous criteria, including anonymous healthcare service, availability, integrity, confidentiality, access control delegation, zero-knowledge proof (ZKP), emergency access to EHRS, scalability, interoperability, and remote health service. * Full patient control over their EHRs: Any access to any EHR attribute by the doctor at step 10 of Figure 4 requires prior patient delegation in step 5. * Anonymous Healthcare Service: Patients can register anonymously using DIDs and later prove ownership of any DID attached to their EHR. * EHR-Availability: EHRs are stored in IPFS which inherently ensures availability since data are duplicated and decentralized. * EHR-Confidentiality: EHRs are encrypted in step 4 of Figure 4 using public keys of authorized third parties only. * EHR-Integrity: Since EHRs are stored in IPFS which addresses files by their hashes, any modification in a file renders the hash invalid. * EHR-Access Control Delegation: Step 2 in Figure 4 allows patients to delegate any attribute of their EHRs to any third party
* EHR-Zero-Knowledge Proof: This feature is inherently provided by the Hyperledger Indy. Doctors cannot reveal any other information relating to the patients, except for the attributes that have been deliberately provided to them. * EHR-Emergency Access: Examples of techniques that can be used to manage access to EHRs in an emergency were discussed in Section 4.5. * Scalability: The most important characteristics affecting the scalability of the proposed architecture are storage and transaction speed. Transaction speed is usually addressed by selecting a Hyperledger using a fast consensus algorithm. Fabric uses the KAFKA-consensus algorithm [34] while Indy uses Byzantine Redundant Fault Tolerance (RBFT) [35]. As noted in [36], both are based on authorized voting and offer good speed. For example, according to the Fabric official website [25], the supported transaction speed is 3000 transactions per second. It is a fast blockchain compared to Bitcoin (maximum of 7 transactions per second) or Ethereum (45 transactions per second). For comparison, according to [37], Visa handles 1700 transactions per second. Regarding Indy, the supported transaction speed, according to [38], is 100 transactions per second. To address the storage scalability issue, most blockchain and Hyperledger use both online and offline storage. Transactions are stored offline, where their hashes are stored online and shared among peers.