Pith. sign in

REVIEW 4 major objections 5 minor 52 references

Empower Healthcare through a Self-Sovereign Identity Infrastructure for Secure Electronic Health Data Access

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read A patient-centric health data framework using self-sovereign identity and blockchain, with backup, revocation and emergency functions, but only basic flows are implemented in the proof of concept.

desk verdict A clearly written integration of existing SSI building blocks for healthcare, but the novel functions are specified rather than validated, and the emergency/recovery loop leans on a centralized trust anchor. read the letter →

arxiv 2501.12229 v1 pith:VCLAUBYO submitted 2025-01-21 cs.CR cs.DC

Antonio López Martínez , Montassar Naghmouchi , Maryline Laurent , Joaquin Garcia-Alfaro , Manuel Gil Pérez , Antonio Ruiz Martínez , Pantaleone Nespoli This is my paper · ORCID
classification cs.CRcs.DC
keywords dataframeworkaccesshealthpatientapproachblockchaincases
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Healthcare records are usually held in centralized hospital systems, which become a single target for attackers. This paper describes a framework where patients keep their records as verifiable credentials on their own phone (the edge agent), with a cloud agent acting as a message relay and encrypted backup. A permissioned blockchain, built on Hyperledger Fabric, stores public identifiers and hashes so that credentials can be verified without a central authority. Identity is managed with W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs).

The paper adds four functions beyond basic credential exchange: wallet recovery by splitting a private key between a membership service provider and trusted contacts; revocation of access to data shared with a doctor; revocation of a credential by its issuer using an accumulator registry; and an emergency loop where a doctor can request key shares from the MSP and contacts to read an unconscious patient's data. The authors implement a proof of concept for the basic loop: registration, mutual authentication by QR code and DIDComm, issuing a prescription VC, and verifying it on the blockchain. Performance measurements show operations in the range of 1 to 12 milliseconds on mobile devices, and about 100 milliseconds for blockchain writes.

Only a subset of the design is implemented. The recovery, revocation, and emergency functions are specified but not tested in the PoC. The performance results lack error bars and scale evidence. The paper is best read as a design proposal with an early feasibility check, not as a completed, validated system.

Extended reading notes

Core claim

The paper's central claim is that a complete, open-source, patient-centric SSI framework for electronic health record access is feasible, covering storage on the patient's device, backup recovery, data access revocation, credential revocation, and emergency access, and that the Proof of Concept validates this design (Sections 4 and 5). If the paper is correct, such a framework can be built with Hyperledger Fabric, Veramo, and DIDComm, with sub-100ms latency for typical mobile operations and about 100ms for blockchain writes.

Load-bearing premise

The security model depends on the Certificate Authority and Membership Service Provider being honest (Sections 4.1.2, 4.2.1, 4.3.4): the CA maps DIDs to real identities and the MSP holds half of the patient's backup private key and controls the emergency access loop. The authors acknowledge in Section 7 that a malicious CA or MSP would compromise the whole framework. Because this logical root of trust is centralized inside a nominally decentralized design, the framework's protections are only as strong as that one trusted authority.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes a self-sovereign identity (SSI) framework for electronic health record access, with patient data stored on personal devices, a permissioned Hyperledger Fabric blockchain as a verifiable data registry, and Veramo/DIDComm-based wallets for authentication and credential exchange. Beyond the basic patient-practitioner-laboratory workflow, the design includes four additional functions: wallet recovery, health data access revocation, verifiable credential revocation, and an emergency access loop. A proof of concept (PoC) implements and tests the basic registration, pairwise connection, and verifiable credential exchange flow, and performance measurements of these baseline operations are reported. The authors claim that the PoC validates the feasibility of the overall framework and that the design is more complete than prior work.

Significance. If the design were fully implemented and its trust assumptions made explicit, the paper would make a useful contribution: it assembles relevant standards (W3C DIDs, VCs, DIDComm) into a coherent architecture, provides an open-source code repository [15], gives a structured comparison with related work (Table 1), and reports a reproducible 10,000-operation performance benchmark for the baseline flows. However, the significance as presented is limited because the four claimed novel functions—recovery, data-access revocation, VC revocation, and emergency access—are specified but not implemented or measured, and the security of the recovery/emergency mechanism hinges on a single trusted authority (the MSP) whose compromise is acknowledged in Section 7 to break the whole framework. The paper's central feasibility claim therefore goes beyond what the evidence supports.

major comments (4)
  1. [Sections 5.2 and 8] The PoC implements only registration, pairwise connection, and VC exchange: Section 5.2 explicitly says "These are all the design functionalities that we have implemented and tested," listing no implementation of wallet recovery (§4.3.1), health data access revocation (§4.3.2), VC revocation (§4.3.3), or the emergency loop (§4.3.4). The abstract and Section 8 nevertheless state that the design is validated and that a PoC was used to validate the proposed framework. The feasibility of the complete framework is therefore not established by the reported experiments. The authors should either implement and test the four additional functions or substantially narrow the claims to a design specification with an initial PoC covering only the baseline interaction.
  2. [Sections 4.3.1, 4.3.4, and 7] The recovery and emergency design places the MSP in a position to defeat the stated security goal. In §4.3.1 the patient sends one half of the backup private key to the MSP; in §4.3.4 the same MSP initiates the emergency loop, collects the other half from trusted contacts, decrypts the cloud backup, and writes the audit record that is supposed to deter abuse. A malicious or compromised MSP can request the second half for any patient whose contacts respond, access the decrypted data, and forge or omit the audit entry, since no independent party is specified to verify the "special security channel" record. Section 7 acknowledges that a malicious CA or MSP compromises the whole framework, but this contradicts the Section 1 claim that the framework "requires no central authorities," and it leaves the central feasibility claim dependent on exactly this unvalidated trust anchor. The authors should provide a concrete threat model, state the trust assumptions explicitly, and either redesign the protocol to avoid a single party controlling both a key share and the audit trail or justify why the centralized root of trust is acceptable for the claimed decentralized design.
  3. [Section 4.3.3] The VC revocation mechanism is described only at a high level: the revocation registry is said to be an accumulator, and the text promises "In Section 5, we will explain the technology used to implement this non-revocation proof." Section 5 contains no such explanation and no implementation of a revocation registry. Since VC revocation is one of the four claimed novel functions and is central to the framework's access-control story, the paper should either provide the cryptographic construction and its implementation/test results or explicitly move this function to future work.
  4. [Section 6] The performance evaluation covers only the baseline operations (DID/VC creation, verification, DIDComm messaging, and the DID read/write chaincode). None of the four additional functions is benchmarked, so the concluding statement that the framework "could be used with a high number of users" is not supported for the complete design. In particular, the emergency loop and VC revocation update both involve additional blockchain writes and communication with third parties, which may have substantially different latency profiles than the measured "Write DID" operation. The authors should either benchmark these functions or restrict the scalability claim to the implemented subsystem.
minor comments (5)
  1. [Section 4.1.1] The phrase "as we will present in the following subsections" appears twice; one occurrence is grammatically disconnected and should be revised.
  2. [Section 4.3.4] There is a typo in "monitoring and auditing all actions perfoemd" — it should read "performed."
  3. [Section 7] The word "imprative" should be "imperative."
  4. [Section 5.2] The paragraph beginning "These are all the design functionalities that we have implemented and tested" is in tension with the immediately preceding sentence that the PoC "covers only certain aspects" of the design. The authors should clarify which functionalities were implemented and which were only designed, without mixed wording.
  5. [Figure 11] The figure reports average times without standard deviations or percentile information; adding these would make the performance claims more robust and reproducible.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the framework's feasibility claim rests on an implemented subset and acknowledged trust limitations, but no derivation reduces to its own inputs by construction.

full rationale

This paper is a systems-design and proof-of-concept paper; it contains no mathematical derivation, no fitted parameters, and no prediction of a quantity from data. The central claim is that a patient-centric SSI framework for EHR access is feasible and that a PoC validates the design (Sections 4-5). That claim is supported by assembling documented standards (W3C DIDs, VCs, DIDComm), comparative technology selection (Table 2), and a working mobile/blockchain implementation for registration, connection, and VC exchange. None of these components is defined in terms of the feasibility conclusion, so there is no self-definitional step. The performance numbers in Section 6 are measurements of the implemented PoC, not fitted values used to force a conclusion. The paper's self-citations ([6], [11], [31], [35]) appear in background, related work, and a design suggestion; they do not carry the load of the feasibility argument. Section 5.2 explicitly states: 'While the PoC covers only certain aspects of the comprehensive design framework, it provides a robust foundation and validation of the overarching concept.' This is an acknowledgement that recovery, revocation, and emergency functions were not implemented, which is an evidence gap rather than circularity. Similarly, Section 7 acknowledges that 'we could have a significant security issue if the CA or MSP acts maliciously, as this would compromise the whole framework'; this is an honest limitation statement, not a hidden reuse of the conclusion. The social-recovery and emergency-loop designs are specified but unvalidated, so the paper's strongest feasibility inference is broader than the evidence supports, but that is a support deficit, not a circular reduction. Accordingly, the appropriate circularity score is 0.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper is a systems design with no mathematical free parameters fitted to data. The axioms are the trust assumptions the design relies on: honest CA/MSP, secure patient device, ability to identify an unconscious patient, and standard cryptographic security.

assumptions (4)
  • domain assumption The Certificate Authority and Membership Service Provider are trusted to act honestly; they issue certificates, map DIDs to real identities, and hold half of the patient's backup key.
    Sections 4.1.2 and 4.2.1 establish the CA/MSP as the root of trust; Section 4.3.4 gives the MSP control over the emergency loop and half-key. Section 7 explicitly states that a malicious CA or MSP would compromise the whole framework.
  • domain assumption The patient's personal device (edge agent) securely stores private keys and EHR data, and is not assumed to be compromised by a network attacker.
    Section 4.1.1 places all health data and keys in the local storage and edge agent; no threat model for device theft or malware is presented, and the recovery function only handles loss or damage.
  • domain assumption In an emergency, the unconscious patient can be identified and their trusted contacts can be reached to return the other half-key.
    Section 4.3.4 states 'We assume we can identify the patient through the patient's device or through their available identity documents' and builds the emergency access loop on contact availability.
  • standard math The cryptographic primitives used (digital signatures, hashes, accumulators, DIDComm encryption) are secure according to W3C and DIDComm specifications.
    Section 2 relies on W3C DID and VC standards and DIDComm protocols [18, 12, 47-49] without re-deriving their security.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Empower Healthcare through a Self-Sovereign Identity Infrastructure for Secure Electronic Health Data Access." pith.science (2026). https://pith.science/paper/VCLAUBYO

@misc{pith2026250112229,
  author       = {Pith},
  title        = {Pith review of: Empower Healthcare through a Self-Sovereign Identity Infrastructure for Secure Electronic Health Data Access},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/VCLAUBYO}},
  note         = {Machine review of arXiv:2501.12229}
}
read the original abstract

Health data is one of the most sensitive data for people, which attracts the attention of malicious activities. We propose an open-source health data management framework, that follows a patient-centric approach. The proposed framework implements the Self-Sovereign Identity paradigm with innovative technologies such as Decentralized Identifiers and Verifiable Credentials. The framework uses Blockchain technology to provide immutability, verifiable data registry, and auditability, as well as an agent-based model to provide protection and privacy for the patient data. We also define different use cases regarding the daily patient-practitioner-laboratory interactions and specific functions to cover patient data loss, data access revocation, and emergency cases where patients are unable to give consent and access to their data. To address this design, a proof of concept is created with an interaction between patient and doctor. The most feasible technologies are selected and the created design is validated. We discuss the differences and novelties of this framework, which includes the patient-centric approach also for data storage, the designed recovery and emergency plan, the defined backup procedure, and the selected blockchain platform.

Figures

Figures reproduced from arXiv: 2501.12229 by the authors.

Figure 1
Figure 1. SSI architecture divided into two parts: (1) user wallet, encompassing all the [PITH_FULL_IMAGE:figures/full_fig_p011_1.png] view at source ↗
Figure 2
Figure 2. Creation of a user certificate. the DID document. After this verification, the CA issues an X.509 certifi￾cate (step 3), which is used to authenticate the user as a legitimate user in subsequent user-ledger interactions in the framework. Also, the CA stores a match between the patient’s DID and their real identity to be prepared for an emergency case, as we will present in Section 4.3.4. Finally, the CA sends the X.… view at source ↗
Figure 3
Figure 3. User authorization. 4.2.3. Mutual authentication Mutual authentication involves establishing a mutually authenticated chan￾nel between users, such as patients and doctors. First, both patient and doctor wallets generate a pairwise DID, used to protect the communication between them. For example, the patient starts creating a QR code, and the doctor scans such a code to read the pairwise DID created by the patient. T… view at source ↗
Figures from the paper (8 more)
Figure 4
Figure 4. Figure 4: Information sharing alternatives. After accessing the patient’s health data, the doctor provides a VC con￾taining his diagnosis or the prescription, which can be verified by other enti￾ties. To correctly model a clinical standard use case, this prescription requires th…
Figure 5
Figure 5. Figure 5: Data access revocation workflow. 4.3.3. VC revocation Besides health data access revocation, we may need to revoke a VC. For instance, if a doctor has issued a VC with a wrong prescription or a lab has issued a VC with a patient test results that needs to be repeated. …
Figure 6
Figure 6. Figure 6: VC revocation workflow. Now, if P wants to exchange the VC received from D with L or other entities of the framework, P needs to present a non-revocation proof to L. In Section 5, we will explain the technology used to implement this non￾revocation proof. Finally, if D…
Figure 7
Figure 7. Figure 7: Proof of Concept design [PITH_FULL_IMAGE:figures/full_fig_p024_7.png]
Figure 8
Figure 8. Figure 8: Registration and Home screens. “Patient Alice”. The alias must be unique because it is associated with the DID created. These DIDs are known only to Alice and Bob. Second, one user must create a QR and the other must scan a such QR. This triggers the connection to the …
Figure 9
Figure 9. Figure 9: New connection and Connections screens. that she needs a blood draw, the nurse in charge of such a process should be able to verify that this information is real. However, if we use the pair￾wise DID created for the connection, the nurse would not be able to verify Bob…
Figure 10
Figure 10. Figure 10: Credentials screen and verification process. [PITH_FULL_IMAGE:figures/full_fig_p030_10.png]
Figure 11
Figure 11. Figure 11: Performance tests obtained for the SSI functionalities. [PITH_FULL_IMAGE:figures/full_fig_p031_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 42 canonical work pages

  1. [15]

    URL https://github.com/LopeeezOne/clinical-ssi-project/ tree/main 36

    Antonio L´ opez, Clinical SSI project, Accessed on 21/01/2025 (2024). URL https://github.com/LopeeezOne/clinical-ssi-project/ tree/main 36

    work page 2024

  2. [1]

    URL https://www.deloitte.com/content/dam/assets-shared/ docs/industries/life-sciences-health-care/2024/ gx-hc-outlook-new.pdf

    Deloitte, 2024 global life sciences outlook, accessed on 21/01/2025 (2024). URL https://www.deloitte.com/content/dam/assets-shared/ docs/industries/life-sciences-health-care/2024/ gx-hc-outlook-new.pdf

    work page 2024

  3. [2]

    Union, Proposal for a regulation of the european parliament and of the council on the european health data space, accessed on 21/01/2025 (2022)

    E. Union, Proposal for a regulation of the european parliament and of the council on the european health data space, accessed on 21/01/2025 (2022). URL https://eur-lex.europa.eu/legal-content/EN/TXT/uri= CELEX%3A52022PC0197

    work page 2022

  4. [3]

    Record, Clinical test data of 2.5 million people stolen from biotech company enzo biochem, accessed on 21/01/2025 (2023)

    T. Record, Clinical test data of 2.5 million people stolen from biotech company enzo biochem, accessed on 21/01/2025 (2023). URL https://acortar.link/6LiR9c

    work page 2023

  5. [4]

    URL https://www.checkpoint.com/cyber-hub/ cyber-security/what-is-healthcare-cyber-security/ cyberattacks-on-the-healthcare-sector/

    Check Point, Cyberattacks on the healthcare sector, Accessed on 21/01/2025 (2023). URL https://www.checkpoint.com/cyber-hub/ cyber-security/what-is-healthcare-cyber-security/ cyberattacks-on-the-healthcare-sector/

    work page 2023

  6. [5]

    URL https://www.ibm.com/reports/data-breach

    IBM, Cost of Data Breach Report 2023, Accessed on 21/01/2025 (2023). URL https://www.ibm.com/reports/data-breach

    work page 2023

  7. [6]

    L´ opez Mart ´ ınez, M

    A. L´ opez Mart ´ ınez, M. Gil P´ erez, A. Ruiz-Mart ´ ınez, A Comprehen- sive Review of the State-of-the-Art on Security and Privacy Issues in Healthcare, ACM Computing Surveys 55 (12) (mar 2023). doi: 10.1145/3571156. 35

    doi:10.1145/3571156 2023

  8. [7]

    Soltani, U

    R. Soltani, U. T. Nguyen, A. An, A survey of self-sovereign identity ecosystem, Journal of Applied Technology and Innovation 2021 (2021) 1–26. doi:10.1155/2021/8873429

    work page doi:10.1155/2021/8873429 2021

Show all 52 references
  1. [8]

    Belchior, B

    R. Belchior, B. Putz, G. Pernul, M. Correia, A. Vasconcelos, S. Guer- reiro, Ssibac: Self-sovereign identity based access control, in: 2020 IEEE 19th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 2020, pp. 1935–1943. doi:10...

    2020

  2. [9]

    Yildiz, A

    H. Yildiz, A. K¨ upper, D. Thatmann, S. G¨ ond¨ or, P. Herbke, Toward interoperable self-sovereign identities, IEEE Access 11 (2023) 114080– 114116. doi:10.1109/ACCESS.2023.3313723

    2023

  3. [10]

    Cucko, M

    S. Cucko, M. Turkanovic, Decentralized and self-sovereign identity: Sys- tematic mapping study, IEEE Access 9 (2021) 139009–139027. doi: 10.1109/ACCESS.2021.3117588

    2021

  4. [11]

    Tcholakian, K

    M. Tcholakian, K. Gorna, M. Laurent, H. Kaffel Ben Ayed, M. Nagh- mouchi, Self-sovereign identity for consented and content-based access to medical records using blockchain, Security and Communication Net- works 2023 (2023) 6025789. doi:10.1155/2023/6025789

    2023 doi

  5. [12]

    URL https://www.w3.org/TR/vc-data-model/

    World Wide Web Consortium (W3C), Verifiable Credentials Data Model v1.1, Accessed on 21/01/2025 (2022). URL https://www.w3.org/TR/vc-data-model/

    2022

  6. [13]

    Houtan, A

    B. Houtan, A. S. Hafid, D. Makrakis, A survey on blockchain-based self- sovereign patient identity in healthcare, IEEE Access 8 (2020) 90478– 90494. doi:10.1109/ACCESS.2020.2994090

    2020

  7. [14]

    Union, Regulation (eu) 2023/2854 of the european parliament and of the council, Accessed on 21/01/2025 (2023)

    E. Union, Regulation (eu) 2023/2854 of the european parliament and of the council, Accessed on 21/01/2025 (2023). URL https://eur-lex.europa.eu/eli/reg/2023/2854

    2023

  8. [16]

    Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, Accessed on 21/01/2025 (2008)

    S. Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, Accessed on 21/01/2025 (2008). URL https://bitcoin.org/bitcoin.pdf

    2008

  9. [17]

    H¨ oß, T

    A. H¨ oß, T. Roth, J. e. a. Sedlmeir, With or without blockchain? to- wards a decentralized, ssi-based eroaming architecture, in: Proceed- ings of the 55th Hawaii International Conference on System Sciences (HICSS), 2022. URL https://orbilu.uni.lu/handle/10993/49066

    2022

  10. [18]

    URL https://www.w3.org/TR/did-core/

    World Wide Web Consortium (W3C), Decentralized Identifiers (DIDs) v1.0, Accessed on 21/01/2025 (2022). URL https://www.w3.org/TR/did-core/

    2022

  11. [19]

    URL https://w3c-ccg.github.io/vp-request-spec/

    World Wide Web Consortium (W3C), Verifiable Presentation Request v0.2, Accessed on 21/01/2025 (2023). URL https://w3c-ccg.github.io/vp-request-spec/

    2023

  12. [20]

    Saidi, N

    H. Saidi, N. Labraoui, A. A. Abba Ari, L. A. Maglaras, J. H. M. Emati, DSMAC: Privacy-aware decentralized self-management of data access control based on blockchain for health data, IEEE Access 10 (2022) 101011–101028. doi:10.1109/ACCESS.2022.3207803

    2022

  13. [21]

    P. Bai, S. Kumar, G. Aggarwal, M. Mahmud, O. Kaiwartya, J. Lloret, Self-sovereignty identity management model for smart healthcare sys- tem, Sensors 22 (13) (2022) 4714. doi:10.3390/s22134714

    2022 doi

  14. [22]

    D. T. Harrell, M. Usman, L. Hanson, M. Abdul-Moheeth, I. Desai, J. Shriram, E. de Oliveira, J. R. Bautista, E. T. Meyer, A. Khur- shid, Technical design and development of a self-sovereign identity management platform for patient-centric health care using blockchain technology...

    2022 doi

  15. [23]

    George, A

    M. George, A. M. Chacko, Health passport: A blockchain-based PHR- integrated self-sovereign identity system, Frontiers in Blockchain 6 (2023) 1–15. doi:10.3389/fbloc.2023.1075083

    2023

  16. [24]

    Patil, Security for electronic health record based on attribute using block-chain technology, Journal of Scientific Research and Technology 1 (6) (2023) 145–155

    S. Patil, Security for electronic health record based on attribute using block-chain technology, Journal of Scientific Research and Technology 1 (6) (2023) 145–155. doi:10.5281/zenodo.8330325. 37

    2023 doi

  17. [25]

    Shuaib, S

    M. Shuaib, S. Alam, M. Shabbir Alam, M. Shahnawaz Nasir, Self- sovereign identity for healthcare using blockchain, Materials Today: Pro- ceedings 81 (2023) 203–207, International Virtual Conference on Sus- tainable Materials. doi:https://doi.org/10.1016/j.matpr.2021. 03.083

    2023 doi

  18. [26]

    C. H. Yi, L. K. Keong, N. F. Razali, Blockchain-based medical record management system (BBMRMS), Journal of Applied Technology and Innovation 7 (4) (2023) 1–10

    2023

  19. [27]

    Zhuang, C.-R

    Y. Zhuang, C.-R. Shyu, S. Hong, P. Li, L. Zhang, Self-sovereign identity empowered non-fungible patient tokenization for health information ex- change using blockchain technology, Computers in Biology and Medicine 157 (2023) 106778. doi:https://doi.org/10.1016/j.compbiomed. 20...

    2023

  20. [28]

    S. S. N. Chintapalli, S. Paramesh, G. Nijaguna, J. R. A. Jeyaraj, P. Sub- hash, Controlled blockchain enabled data record security for healthcare applications, Neural Computing and Applications 36 (17) (2024) 9617– 9629

    2024

  21. [29]

    A. Ling, S. Butakov, Trust framework for self-sovereign identity in metaverse healthcare applications, Data Science and Management 7 (4) (2024) 304–313. doi:https://doi.org/10.1016/j.dsm.2024.04.003

    2024 doi

  22. [30]

    George, A

    M. George, A. Mary Chacko, Meditrans—patient-centric interoperabil- ity through blockchain, International Journal of Network Management 32 (3) (2022) e2187

    2022

  23. [31]

    L´ opez Mart ´ ınez, M

    A. L´ opez Mart ´ ınez, M. Gil P´ erez, A. Ruiz-Mart ´ ınez, A comprehensive model for securing sensitive patient data in a clinical scenario, IEEE Access 11 (2023) 137083–137098. doi:10.1109/ACCESS.2023.3338170

    2023

  24. [32]

    C. V. Helliar, L. Crawford, L. Rocca, C. Teodori, M. Veneziani, Permis- sionless and permissioned blockchain diffusion, International Journal of Information Management 54 (2020) 102136

    2020

  25. [33]

    Horandner, C

    F. Horandner, C. Rabensteiner, Horcruxes for everyone – A frame- work for key-loss recovery by splitting trust, in: 2019 18th IEEE In- ternational Conference On Trust, Security And Privacy In Comput- ing And Communications/13th IEEE International Conference On Big 38 Data Scie...

    2019

  26. [34]

    Soltani, U

    R. Soltani, U. T. Nguyen, A. An, Practical key recovery model for self-sovereign identity based digital wallets, in: 2019 IEEE Intl Conf on Dependable, Autonomic and Secure Computing, Intl Conf on Per- vasive Intelligence and Computing, Intl Conf on Cloud and Big Data Computin...

    2019

  27. [35]

    Galv´ an, J

    E. Galv´ an, J. Garcia-Alfaro, G. Navarro-Arribas, V. Torra, Agents in a privacy-preserving world, Transactions on Data Privacy 14 (1) (2021) 53–63

    2021

  28. [36]

    Azkia, N

    H. Azkia, N. Cuppens-Boulahia, F. Cuppens, G. Coatrieux, S. Oul- makhzoune, Deployment of a posteriori access control using IHE ATNA, International Journal of Information Security 14 (2015) 471–483

    2015

  29. [37]

    Merlo, G

    V. Merlo, G. Pio, F. Giusto, M. Bilancia, On the exploitation of the blockchain technology in the healthcare sector: A systematic review, Expert Systems with Applications 213 (2023) 118897. doi:10.1016/j. eswa.2022.118897

    2023

  30. [38]

    Andrew J., D. P. Isravel, K. M. Sagayam, B. Bhushan, Y. Sei, J. Eu- nice, Blockchain for healthcare systems: Architecture, security chal- lenges, trends and future directions, Journal of Network and Computer Applications 215 (2023) 103633. doi:10.1016/j.jnca.2023.103633

    2023

  31. [39]

    Farshidi, S

    S. Farshidi, S. Jansen, S. Espa˜ na, J. Verkleij, Decision support for blockchain platform selection: Three industry case studies, IEEE Trans- actions on Engineering Management 67 (4) (2020) 1109–1128. doi: 10.1109/TEM.2019.2956897

    2020

  32. [40]

    Nanayakkara, M

    S. Nanayakkara, M. Rodrigo, S. Perera, G. Weerasuriya, A. A. Hijazi, A methodology for selection of a blockchain platform to develop an en- terprise system, Journal of Industrial Information Integration 23 (2021) 100215. doi:10.1016/j.jii.2021.100215

    2021

  33. [41]

    Capocasale, D

    V. Capocasale, D. Gotta, G. Perboli, Comparative analysis of permis- sioned blockchain frameworks for industrial applications, Blockchain: 39 Research and Applications 4 (1) (2023) 100113. doi:10.1016/j.bcra. 2022.100113

    2023

  34. [42]

    URL https://www.hyperledger.org/projects/fabric

    Hyperledger Foundation, Hyperledger Fabric, Accessed on 21/01/2025 (2024). URL https://www.hyperledger.org/projects/fabric

    2024

  35. [43]

    URL https://www.hyperledger.org/projects/hyperledger-indy

    Hyperledger Foundation, Hyperledger Indy, Accessed on 21/01/2025 (2024). URL https://www.hyperledger.org/projects/hyperledger-indy

    2024

  36. [44]

    URL https://www.hyperledger.org/projects/aries

    Hyperledger Foundation, Hyperledger Aries, Accessed on 21/01/2025 (2024). URL https://www.hyperledger.org/projects/aries

    2024

  37. [45]

    URL https://veramo.io/

    Pelle Braendgaard, Veramo framework, Accessed on 21/01/2025 (2024). URL https://veramo.io/

    2024

  38. [46]

    URL https://typeorm.io/

    Umed Khudoiberdiev, TypeORM, Accessed on 21/01/2025 (2024). URL https://typeorm.io/

    2024

  39. [47]

    URL https://identity.foundation/peer-did-method-spec/

    Identity Foundation, Peer DID Method Specification, Accessed on 21/01/2025 (2024). URL https://identity.foundation/peer-did-method-spec/

    2024

  40. [48]

    URL https://didcomm.org/coordinate-mediation/3.0/

    DIDComm, Coordinate Mediation, Accessed on 21/01/2025 (2024). URL https://didcomm.org/coordinate-mediation/3.0/

    2024

  41. [49]

    URL https://didcomm.org/messagepickup/3.0/

    DIDComm, Message Pickup, Accessed on 21/01/2025 (2024). URL https://didcomm.org/messagepickup/3.0/

    2024

  42. [50]

    URL https://www.lfdecentralizedtrust.org/projects/caliper

    Hyperledger Foundation, Hyperledger Caliper, Accessed on 21/01/2025 (2024). URL https://www.lfdecentralizedtrust.org/projects/caliper

    2024

  43. [51]

    Fernandez-Tarraga, A.-D

    M. Fernandez-Tarraga, A.-D. Cayuela-Tudela, P. Nespoli, J. Garcia- Alfaro, F. G´ omez M´ armol, Training on Social Media Cybersecurity Skills in the Healthcare Context, in: Secure and Resilient Digital Transforma- tion of Healthcare, Springer Nature Switzerland, 2024, pp. 3–20. 40

    2024

  44. [57]

    doi:10.1109/TrustCom/BigDataSE.2019.00017

    2019

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.