| Literature DB >> 31952172 |
Mohammed Amine Bouras1, Qinghua Lu2, Fan Zhang1, Yueliang Wan3,4, Tao Zhang5, Huansheng Ning1,4.
Abstract
Electronic healthcare (eHealth) identity management (IdM) is a pivotal feature in the eHealth system. Distributed ledger technology (DLT) is an emerging technology that can achieve agreements of transactional data states in a decentralized way. Building identity management systems using Blockchain can enable patients to fully control their own identity and provide increased confidence in data immutability and availability. This paper presents the state of the art of decentralized identity management using Blockchain and highlights the possible opportunities for adopting the decentralized identity management approaches for future health identity systems. First, we summarize eHealth identity management scenarios. Furthermore, we investigate the existing decentralized identity management solutions and present decentralized identity models. In addition, we discuss the current decentralized identity projects and identify new challenges based on the existing solutions and the limitations when applying it to healthcare as a particular use case.Entities:
Keywords: blockchain; digital identity; distributed ledger technology; eHealth; identity management
Year: 2020 PMID: 31952172 PMCID: PMC7013398 DOI: 10.3390/s20020483
Source DB: PubMed Journal: Sensors (Basel) ISSN: 1424-8220 Impact factor: 3.576
The seven criteria of identity management.
| Principles | Abstract |
|---|---|
| Autonomy | Is the individual independent from identity vendors? Individuals must be independent of any identity provider or a central governor. |
| Authority | Can the individual have full control of his identity? Individuals must have complete power to manage their identities. |
| Availability | Can an individual have full access to his own data? Individuals must have full permission to gain access to their own data anytime anywhere. |
| Approval | Can the individual voluntary approve the use of his identity? Individuals must voluntary agree and approve requests before using their identity. |
| Confidentiality | Can the individual provide his identity with minimal disclosure of data? Individuals should share only the needed credentials with a minimal disclosure |
| Tenacity | Can the identity live with the individual as long as possible? Individuals identities must be persistent as long as possible |
| Interoperability | Can the individual identity exchange data with any system or service globally? Individual Identities should be universal and widely used by any entities |
Identity management (IdM) models comparison.
| Principles | Centralized Models | Decentralized Models | ||
|---|---|---|---|---|
| Centralized Identity | Federated Identity | User Centric Identity | ||
| Autonomy | No | No | No | Yes |
| Authority | Low | Low | Medium | High |
| Availability | Low | Medium | Medium | High |
| Approval | No | No | Yes | Yes |
| Confidentiality | Low | Low | Medium | High |
| Tenacity | No | No | No | Yes |
| Interoperability | No | Yes | Yes | Yes |
Key players’ roles and tasks.
| Key Players | User Roles | Role Definition |
|---|---|---|
| Healthcare regulators | Issuer | Regulators can create claims about the authorized clinics, hospitals, and care providers. |
| Inspector | Regulators can verify the care providers’ certificates and patients’ assurance validity. | |
| Holder | Regulators can control and hold different claim about the other key players. | |
| Industry representatives | Issuer | They can create claims about their own products and services to care providers or consumers. |
| Inspector | They can verify claims coming from healthcare providers and consumers about particular products. | |
| Holder | They can control and hold claims about operations and product selling records. | |
| Healthcare providers | Issuer | Care providers can create claims about healthcare consumers and it can be stored as healthcare records. |
| Inspector | Care providers can inspect and verify claims of their own patients and industry representative. | |
| Holder | Care providers can control and hold claims like working certificate. | |
| Healthcare consumers | Issuer | Consumers can create claims about their own health condition using devices and gadgets. |
| Inspector | Consumers can verify claims coming from care provider for example in a case of telemedicine and remote care. | |
| Holder | Consumers can control and hold claims such as medical records. |
The subject role is not presented in the table as we consider the holder is the subject. There are few use cases where the subject can be different from the holder, for example a kid can be the subject of the claim but the holder of the claim should be his parents. A holder is typically the controller of the claims.
The healthcare identity scenarios.
| Name | Scenario | Key Players | Requirements |
|---|---|---|---|
| Healthcare data exchange | Visiting a different health clinic in a different stat after feeling sick when traveling for a vacation or business. The patient will aim to provide only the requested and required information that verifies his identity by delivering an identity credential without disclosing other information like social security number or marital status, besides he wants to revoke the access to his information after a set of time | -Consumers | Interoperability is the main aspect to exchange data between different healthcare institutions in different states and countries. |
| Online pharmacy | An online pharmacy may receive a patient prescription from a local clinic. The pharmacy needs to verify the identity of the physician and his ability to write a prescription, as well as the identity of the patient and his insurance coverage before picking up his medication | -Consumers | |
| Payment | A company started an employee assistance program with the aim of providing health insurance and treatment coverage to all employees where the company has branches. This health plan requires access to the employees’ medical records who received a treatment, which will be delivered from the healthcare providers in different locations in order to calculate the budget of the services provided. | -Consumers | Data standard is mandatory for exchanging the information between the key players. |
| Research project | A research project on children is being conducted in a double-blind study and needs access to new data sets for children younger than the age of 13. After authorizing the access to the data, the IRB will review the project and apply research protocols at the medical center where the investigation is located. The research lab asked the principals if they can have access to the data for another 6 months and use the data collected for another study purpose which is not related to the research protocol reviewed in the beginning. | -Consumers | Anonymity is the key feature to share the data of a group of consumers without disclosing their identity. |
Figure 1Decentralized identity models.
Figure 2Identity solutions-based distributed ledger technology (DLT) models.
Decentralized identity management solutions.
| Identity Project | DLT Model | DLT Platform | Identity Model | Launch Date | Open Source | Consensus Algorithm | Industry Target |
|---|---|---|---|---|---|---|---|
| uPort [ | Public Permissionless | Ethereum | Self-sovereign | January 2017 | Yes | PoW (Ethash) | - |
| Sovrin [ | Public Permissioned | Hyperledger Indy | Self-sovereign | July 2017 | Yes | Redundant Byzantine Fault Tolerance (RBFT) | - |
| Identity.com [ | Public Permissionless | Ethereum | Decentralized Trusted Identity | Later | Yes | PoW (Ethash) | - |
| Evernym [ | Public Permissionless | IOTA | Self-sovereign | Later | Yes | Consensus achieved by Confirmation confidence | Finance, Education, Healthcare, Commerce, Travel |
| Blockstack [ | Public Permissionless | Bitcoin | Self-sovereign | 2013 | Yes | PoW (Proof-of-Work) | Software |
| Thekey [ | Public Permissioned | NEO | - | November 2014 | No | Delegated Byzantine Fault Tolerance (dBFT) | Software |
| Selfkey [ | Public Permissionless | Ethereum | Self-sovereign | 2016 | Yes | PoW (Ethash) | Financial services |
| Uniquid [ | Public Permissionless | Bitcoin | - | October 2015 | Yes | PoW (Ethash) | IoT |
| ShoCard [ | Can support all DLT models | - | Decentralized Trusted Identity | May 2015 | No | Not specified | Enterprises, financial institutions, airlines, website and app login |
| Sovrin [ | Public Permissioned | Hyperledger Indy | Self-sovereign | July 2017 | Yes | Redundant Byzantine Fault Tolerance (RBFT) | - |
| verified.me [ | Private Permissioned | Hyperledger Fabric | Self-sovereign | Late 2017 | No | Byzantine fault tolerance (BFT) | Banking |
| Trust ID Network | Private Permissioned | R3 Corda | Self-sovereign | September 2018 | No | Consensus over state validity and uniqueness | Banking and financial institutions |
| DIF [ | Can support all DLT models | - | Self-sovereign | Later | Yes | Not specified | All industries |
| Cambridge blockchain LLC [ | Private Permissioned | - | Decentralized Trusted Identity | 2015 | No | - | Financial institutions |
Blockchain-based identity management systems metrics.
| Metrics | Explanation |
|---|---|
| Time spent provisioning and de-provisioning users | Provision and de-provisioning is the core functionality of any identity systems, managing the user accounts from registration to authentication and updates in a short time is a mandatory metric for mature identity management systems. Delays of those operations or failed Logins may lead to a failure of the solution [ |
| Unique accounts per user | The more s user creates several accounts the more he is to forget about the credentials. A user may create more than one account for different purpose especially when the process of recovering the username or the password is hard. Single Sign-On (SSO) platforms are mainly to solve this problem [ |
| Password reset volume per month | Many companies and applications require changing their password periodically to ensure strong security systems. A mature IdM should answer to the requirement and makes it easy for users to change their password is a fast and secure ways [ |
| Number of uncorrelated accounts | Many accounts may not have owners due to changing accounts, upgrading the system, or a user may leave his account open without using it. This situation may lead to a security threat. A mature system my monitor such accounts to reduce the unnecessary risks [ |
| Read latency | Reading from the ledger is the most performed action in blockchain networks which is the time between sending the reading request until the replay is received. Improving the reading latency will help to optimize the authentication time [ |
| Read throughput | The metric of defining how many reading operations are performed in a period of time. This metric is not really relevant for blockchain network but important for blockchain-based identity solution as most solutions relay to blockchain performance, not to the identity system needed [ |
| Transaction latency | Blockchain transactions are time-consuming as the consensus process is used to make the transaction valid across the network. Transaction with long delays may cause a system failure as is not providing a good user experience [ |
| Transaction throughput | It’s the rate of valid transaction committed in a set of time. Mainly this metric is performed in every node of the blockchain network to have accurate results and to identify the issues if any. In the blockchain-based identity system transaction throughput is connected to provisioning and de-provisioning operations [ |
| Actual production usage | Knowing the real system usage will help to specify the metrics. For instance, in the identity management systems, provisioning and authentication are the most performed operations that it matches in the blockchain the reading and the transaction requests. The more we understand the system the more we easily and accurately identify the metrics and perform evaluations [ |