HealthyBlock: Blockchain-Based IT Architecture for Electronic Medical Records Resilient to Connectivity Failures
Abstract
:1. Introduction
2. Literature Review
2.1. Background
2.1.1. Electronic Medical Records (EMRs)
2.1.2. International Standards for EMRs
2.1.3. Blockchain
- Public or permissionless blockchain: public blockchain networks are those to which anyone has access [38].
- Private or permissioned blockchain: private blockchain networks are those where control is reduced to a single entity, responsible for maintaining the chain, giving permissions to the users that want to participate, proposing transactions, and accepting the blocks. A mining process does not exist [38].
- Hybrid or consortium blockchain: hybrid blockchains are not open to public participation, but a certain number of organizations, entities, or companies are responsible for managing the network as a whole and keeping synchronized copies of the registry [38].
2.1.4. Smart Contract
2.1.5. Consensus Algorithms
2.1.6. Connectivity Failure
2.2. Related Work
- They are implemented to unite a set of geographically dispersed clinical providers.
- In some cases, these systems communicate with the existing EMR systems in clinical providers, especially with their local databases, and, in other cases, the proposed architecture completely replaces them.
- In most of the designs, blockchain is used as a repository of cryptographic hashes that act as pointers to indicate the place where medical records are stored in local databases; in other cases, EMRs are stored entirely on the blockchain.
- All systems propose strategies to guarantee the security and privacy of medical records, which is understandable given the sensitivity of clinical information.
- Generally, private blockchains are used, but some proposals also use public blockchains.
- Different consensus algorithms are used to mine or store transactions on the blockchain, the most widely used being proof of work (PoW).
- In each clinical provider, there is a blockchain node, which has a copy of the chain and, in order to improve efficiency, this node is a blockchain miner.
- The first scenario occurs if the blockchain node that was disconnected is a mining node. In this case, the node acts as a fork of a single node of the blockchain; therefore, when receiving transactions, it proceeds to mine them on the local copy of the blockchain. Once this node reconnects with the blockchain network, the copy of the chain that it contains and that was used to store the transactions will not be valid for the rest of the blockchain network. This occurs because the remaining nodes of the chain act as the majority, and they have a different version of the blockchain than the one at the node; thus, the blockchain will proceed to synchronize and send the valid copy of the blockchain, overwriting the previous one. This will result in the loss of the last transactions created in the node of the clinical provider, which will lead to a failure in the integrity of the data between the blockchain and the node’s local database.
- The second problem occurs when the node that loses connectivity is a non-mining node. According to the operation of blockchains in general, the transactions received by a node, during the time it is not connected to the blockchain network, are stored by it and, once the node reconnects, it will proceed to send the transactions for mining. When contrasting this general operation of the blockchain with the analysis of the workflows of the EMR systems found in the literature, it can be observed that many of them need to receive confirmation from the blockchain nodes related to the mining of the transactions; however, as the node is disconnected, this confirmation cannot be generated and, therefore, the workflows will be interrupted.
3. Proposed Architecture
3.1. Preliminaries
3.1.1. Software Components
3.1.2. Information Technology (IT) Architecture
3.1.3. Archimate Modeling Language
3.1.4. CRU (Create, Read, Update) Operations
3.2. Architecture Overview
- The owner of the electronic medical records is the patient.
- The internal and external system actors are enrolled in the system by an administrative authority, which is designated by the participating entities of the system and is in charge of verifying the suitability of the enrollment of the actors who request it.
- When a patient enters the system, a family doctor is assigned. This doctor becomes a custodian and has full access to that patient’s electronic medical records.
- A patient may have an additional custodian of their EMRs, especially in cases when the patient is a minor or for emergencies.
- A patient’s medical records have an access control policy that can only be changed by the patient or the data custodians. This policy is recorded in the blockchain, as are the changes made to it and the author of the changes. In this way, the traceability of who had access to the data is ensured.
- Case 1. Patient or family doctor creates or updates access levels. This case starts when a patient or family doctor receives a request for access or wishes to give access to some actor in the system of their clinical data or those of their patient. To do this, the user enters the system, which asks for access data. The system verifies, according to the credentials, if the user has permission for the action to be performed; if so, it grants permission, and the patient, custodian or family doctor proceeds to make changes in the access levels, which are stored in the local database. Then, the synchronizer, if there is a connection to the network, proceeds to send the transactions to the blockchain; otherwise, it marks them as not sent before proceeding to send them as soon as there is a connection to the blockchain. In case of not having the required permissions, the system sends a request for authorization to the managing authority.
- Case 2. Patient or family doctor consults EMR. This case starts when the electronic medical records of a patient are going to be consulted by the patient herself or by its family doctor. To do this, the user enters the system to request the access data. After that, the system verifies the permissions for the action to be carried out; if permitted, the synchronizer proceeds to extract the EMRs from the local database and proceeds to update them with those stored in the blockchain, as long as there is no connectivity failure. In the case of a connectivity failure, it shows the latest update of the EMRs stored in the local database. If the actor does not have the required permissions, they can make a request to the administrative authority to enable permissions.
- Case 3. Attention to the patient in a health institution. This case begins when a patient attends a medical visit to a health provider, which may be their daily provider or a new one. There, the patient is cared for by the medical staff, who, if they have the appropriate permissions, and, according to approved clinical practices, start by consulting the patient’s medical records. For this, the synchronizer extracts the existing EMRs from the local data of the hospital and then proceeds to update them with those stored in the blockchain, as long as there is connectivity. In case of a connectivity failure, the system shows the latest update of the EMRs stored in the local database. Next, the medical staff performs the patient care and generates a series of medical records that are stored by the synchronizer: first, in the local database of the health provider, and then, if there is a connection to the network, it proceeds to send the transactions to the blockchain. If there is no connection, the synchronizer marks the new records as not sent and waist until there is a connection to send them to the blockchain, thus making them available for all the nodes of the system. In case of not having the required permissions, a request is made to the patient or the family doctor for access.
- Case 4. Consultation with an external provider. This case begins when a patient attends a consultation with an external doctor or a laboratory. In this appointment, the doctor accesses the patient’s data through a web interface; however, generally, this external provider has limited access to the patient’s EMRs. At the end of the session and if the doctor has the appropriate permissions, they can enter the new records into the patient’s medical record on the blockchain. In the case of not having the required permits, a request is made to the patient or family doctor.
3.3. Design of the Architecture
3.3.1. Technology Layer
- Web servers (hardware): these elements host part of the system for encryption, obfuscation, and synchronization of electronic medical records. These servers are configured with the operating system and the web server (software) chosen to host the applications.
- Local database servers (hardware): these servers are configured with the operating system and the chosen database server (software) to store the clinical information of the patients locally. Hospitals may have their own information systems, but they must provide a two-way communication channel with the HealthyBlock system, which allows obtaining local data to be published on the blockchain and made available to all actors, and receiving patient data, which should be included in the patient’s local medical history.
- Servers (hardware) to host the nodes of the blockchain network: these servers are configured with the operating system, the blockchain on which the smart contracts will run, and a blockchain client in charge of providing the configuration interface for the nodes and managing the connection with other nodes to create the blockchain network. An important element when configuring the blockchain node is the choice of the consensus algorithm, for which the proof of authority (POA) algorithm is recommended given its advantages for private blockchain networks. It is also suggested that health institutions have a blockchain server to support network maintenance and guarantee access to the most up-to-date synchronized information even under a disconnection scenario.
3.3.2. Technology Services Layer
3.3.3. Application Components Layer
EMR Component
- EMR manager: This component is in charge of managing the data structure of the records, including the different sections and fields that the records have. It works in conjunction with the synchronizer component to which it sends the captured EMR information.
- HL7 component: For the construction, storage, and transmission of the records, according to the Health Level Seven International (HL7) clinical standard. This component oversees formatting the EMR data such that they comply with the rules established in HL7.
- Obfuscation component: Obfuscation consists of replacing or altering the existing real data to hide details and protect either the identity or the sensitive characteristics of the information of a user. Ideally, the technique should resist reverse engineering attacks [59]; however, at the same time, it should not alter the data in excess, so that it remains useful for some level of decision-making. Data obfuscation techniques have three main properties: reversibility, specification, and change [60]. In accordance with these concepts, the proposed obfuscator alters the clinical data of the patients in order to be able to carry out trend analysis on them, but without being able to identify the real data or its owner. This component performs the obfuscation process on the basis of the access levels proposed in [61] and defined in the role manager component described below.
Security Component
- Roles component: This component is in charge of managing the roles assigned to each user within the system. Each user who is registered in the system is assigned a role (patient, doctor, laboratory, administrative, etc.), which in turn has a defined series of differential accesses which refer to the assignment of a set of predetermined permissions, in order to reduce the complexity of establishing a user access to clinical information for a user/patient. The proposed access levels in Figure 7 are based on those defined in [61]: (i) no access, where no information is revealed from the patient; (ii) information, where just basic descriptors of the general behavior of the data are shared but no specific data are revealed (range, trend, statistical distribution); (iii) sample, where the shared information is restricted in quantity or quality of the data (last data, every two data points, truncated or obfuscated data); (iv) full access, where the entire dataset is shared without alteration.
- Requests component: This component is in charge of managing requests for access to a patient’s clinical data. These requests can be issued by a doctor or by an entity and must be approved by the patient or the family doctor. In case they are approved, this component creates a relationship of the patient’s records with the user to whom the request was approved, as well as the type of role that is granted in the system.
- Keys component: This component is in charge of generating and managing user accounts with which you can interact and carry out transactions on the blockchain. While, in a conventional system, a user/password pair is used to authenticate, in the blockchain, accounts whose access credentials are a cryptographic pair are used, which, for security, must be made up of a public key and a private key, which can be seen as the username and password of the blockchain. As can be deduced from the above, these accounts are necessary for interaction with the blockchain; therefore, each user in the system must be associated with an account on the blockchain, with their public key and private key being the access credentials. Likewise, the keys component generates the public and private keys used by the encryption component to carry out the encryption processes; the generation, management, and correct validation of these keys are of utmost importance, in order to carry out a correct encryption of the EMR.
- Authentication and registration component: This component is in charge of registering and authenticating the different actors that have access to the system, such as the administrative authority, doctors, hospitals, clinical centers, and patients. At the time of registration, the user is assigned a name, a password, a role, and an access level that, by default, is without access. Likewise, the keys component generates the public and private key for access to the blockchain, and the public and private keys of the blockchain are stored in the user’s account of the system to facilitate later access. Later, public and private keys are generated for the encryption processes; the public key is stored in the blockchain so that it can be used by all the actors in the system who want to communicate with the user, while the private key is delivered to the user for custody. At the time of access to the system, the user uses the username, password, and private encryption key that was assigned. If the authentication process is correct, this component allows access to the system and, in collaboration with the roles component, grants the user the access levels assigned to them for CRU operations on the EMR system. This authentication component is also responsible for generating the log of the transactions carried out by users on the system, in order to carry out audit processes of visualizations, additions, or modifications to the electronic medical records (EMRs).
Encryption and Synchronization Component
- Encryption component: Cryptography is an encryption technique that disorganizes information in a particular way so that only the user can read and process it [62]; there are two types of cryptography techniques: secret key cryptography and public key cryptography. In secret key cryptography, a single key is used with which both the sender and the receiver encrypt and decrypt the data; this is also known as symmetric encryption. Public key cryptography is made up of two encryption systems that give rise to a public key that is shared with all those to whom it wants to communicate and a private key that is secret [63]. In the proposed HealthyBlock architecture, public key cryptography is suggested, since it offers greater security, and special care must be given to the delivery of the private key to system users.
- Synchronizer component: This component is in charge of creating the bridge between the blockchain network and the internal databases of the medical centers. The structure of the module can be seen it Figure 9, and the main functions of the synchronizer are as follows:
- ○
- Detect system connection failures to the blockchain network, through a connection sentinel.
- ○
- Store transactions (including user information, permissions, and the medical records of a patient) in the local database of the medical provider to later send them to the blockchain.
- ○
- Manage the transmission of transactions to the blockchain, implementing a buffer to avoid errors in the block creation of a disconnected node. The intermediate buffer can be implemented using a queue management algorithm or other existing techniques for managing buffers available in the literature.
- ○
- Download the information of users and patients from the blockchain when it is requested by medical staff and it is not stored in the local database; this means that the synchronizer works on demand, which reduces the work load of the component and reduces the amount of information stored on the local database. For example, if a patient has an appointment at a new health provider, the patient’s EMRs are downloaded from the blockchain and saved in the local database. If the hospital is experiencing a connectivity failure, the synchronizer updates the information in the local database from the latest version of the local blockchain node; thus, the system guarantees access to the latest data on the blockchain before the failure. Once the connection is re-established, even during patient care, the synchronizer notifies the doctor if there are new records on the updated blockchain.
- ○
- Guarantee the resilience in the integrity of the architecture data, since, in the event of a connectivity failure of a clinical provider’s node, the synchronizer, during the disconnection period, stops sending transactions to the blockchain and only stores them in the local databases of the providers, marking them as not sent in said database. Once the synchronizer detects that the provider’s connection has returned, it proceeds to send the unsent transactions that were generated during the disconnection period, so that they can be included in the blockchain.
- ○
- Execute algorithms of record searching when inserting transactions to the blockchain and when downloading information from it. It must be programmed with efficient search algorithms, in order to improve the access speeds of the required information.
3.3.4. Application Services Layer
3.3.5. Processes Layer
- User processes: This process begins with a CRU request by an actor before an administrative authority of the system (Figure 10); then, an authentication process is performed by the administrative authority. For this, the system relies on the service authentication that is provided by the authentication, keys, and roles components. Then, it is validated whether the request is a creation or not. In the case of a creation request, the user data are registered, supported by the data registration service provided by the authentication component. The system then generates the public and private keys for the blockchain and the public and private keys for the user, while the user’s private key is delivered to them for safekeeping. Next, according to the role and type of user, the access level for the requesting user is created, supported by the access service that is provided by the roles component. Finally, the transaction is concluded, and the system, by means of the application services encryption and synchronization, which is provided by the encryption and synchronization component, takes the data of the transaction, encrypts them, and saves them on the blockchain. If it is not a creation request, but rather a read, update, or delete request, the data of the requesting user are verified, relying on the data registration service, which is provided by the authentication component, and then the request is processed. request required. Finally, the transaction and the system are concluded by means of the application services encryption and synchronization, which is provided by the encryption and synchronization component, which takes the transaction data, encrypts them, and saves them in the local database and the blockchain.
- Permits processes: This process begins with a request for permission to access a patient’s electronic medical records by an actor, generally a hospital or a doctor (Figure 11). The patient or authorized guardian then authenticates themself in the system, through the authentication service that is provided by the authentication, keys, and roles components. Next, the patient performs the CRU operation; that is, it allows access to new users, and modifies or updates access to their medical records, relying on the system access service, which is provided by the roles component. Finally, the transaction is concluded and the system, by means of the application services encryption and synchronization, takes the data of the transaction made, encrypts them, and saves them in the local database and blockchain.
- EMR processes: This process usually begins with a patient’s consultation with a medical provider (Figure 12). Next, the medical provider authenticates themself in the system through the authentication service, which is provided by the authentication, keys, and roles components. The system then verifies if the provider has sufficient permissions to view, create, or update the medical records; if so, it gives access to the EMRs and the medical provider proceeds to perform the necessary CRU operations on the patient’s EMRs, using the application services EMR, provided by the obfuscator and HL7 components, and the application services encryption and synchronization, using the encryption and synchronizer components. If the medical provider does not have access to the patient’s records, the system gives them the option to make a request to access the EMR; this access request is supported by the system access service which is provided by the roles component. In the two ways previously described, the transaction and the system are concluded by means of the application services encryption and synchronization, which takes the data of the transaction made, encrypts them, and saves them in the local database and blockchain.
3.3.6. Processes Services Layer
3.3.7. Presentation Layer
4. Developed Prototype
5. Evaluation
5.1. Testing Environment
5.2. Performance Indicators
- Latency: measure of responsiveness that represents the time it takes to complete the execution of a request.
- Transaction throughput: the number of successful transactions that the prototype can process per second.
- Resource utilization: utilization of resources while processing requests and responses of transactions. Resource utilization can be measured by checking the resources used by the prototype in the CPU, memory, network, and I/O in a defined period of time.
5.3. Performance Results
5.4. Functionality and Usability Evaluation
6. Discussion
7. Conclusions
- Patients should be able to download their records on portable media, such as cryptographically signed flash cards or cell phone APIs, in such a way that patients, when making a visit to a clinical provider, and in case the system of this provider is faced with a connection failure, can perform a wired or wireless synchronization between the most up-to-date version of the EMRs that they have and the provider’s local databases.
- Integrate clinical decision support services (CDSS) to assist physicians in making decisions about the diagnosis of their patients.
- Support patients in their health routines such as medicine schedules, medical appointment reminders, etc.
Author Contributions
Funding
Acknowledgments
Conflicts of Interest
Appendix A. Description of the Prototype
Appendix A.1. Client
Appendix A.1.1. Operating System
Appendix A.1.2. Web Client
Appendix A.2. Server
Appendix A.2.1. Operating System
Appendix A.2.2. Blockchain Client
Appendix A.2.3. Blockchain
Appendix A.2.4. Database Server
Appendix A.2.5. Web Server
Appendix A.2.6. HealthyBlock Architecture Components
Structure ORU-R01 |
---|
MSH Message Header (General information about the message) |
PID Patient Identification (Patient information) |
[ |
OBR Observation Requests (Type of request observation) |
{ |
OBX Observation Results (Results of the requested observation) |
} |
] |
[ |
{ |
PV1 Patient Visit (Information about the patient’s visit) |
NTE Notes and Comments (General information about the visit) |
} |
] |
- EMR manager: The smart contract that develops this component is called MedicalHistory.sol. This contract is in charge of managing the fields that have the EMRs that, for the developed prototype, were name, address, telephone number, the patient’s hemoglobin records, and patient queries.
- Roles: The smart contract developed by this component is called Agent.sol. This contract allows the definition of roles and, therefore, the different levels of access of an actor to the records of a patient. As previously indicated, the accesses are based on [61] and, in order to manage better functionality in the prototype, the following access levels were implemented: no access, range, trend, partial list, full altered list, and full access. Patients are a special agent as they are the owners of their medical history and, thus, must have this additional attribute; therefore, an additional smart contract was used that extends from Agent.sol.
- Authentication and registration: The smart contract developed by this component is called Platform.sol. This contract has the agents or actors of the system such as patients, doctors, laboratories, and the relationships between them; this is why this contract is considered of utmost importance, since it allows a relationship between the different system contracts.
Appendix A.3. Network Devices
Appendix A.3.1. LAN Devices
Appendix A.3.2. WAN Devices
Appendix A.4. Description of the Prototype
Appendix A.4.1. User Processes
Appendix A.4.2. Permission Process
Appendix A.4.3. EMR Processes
Appendix B. Functionality and Usability Survey
- Patient: the surveyed individual answered requests from laboratory and medical users for access to their medical history and assigned a level of access to each one if they accepted the request.
- Doctor: in the search module, the surveyed individual searched for a patient and asked them for access to the medical history. Depending on the level of access, if this user could modify the patient’s medical history, they proceeded with the respective test.
- Laboratory: the surveyed individual carried out the search for patients and requested their medical history. Once the request was answered and an access level was assigned, the surveyed individual added data to the patient’s medical record.
- Administrator: the surveyed individual was in charge of assigning a patient to a family/personal doctor, who could be any medical-type user registered in the system.
- Family/personal physician: the surveyed individual had the same functionalities as a normal physician, but also could manage the access permissions to medical records of their patients assigned by an administrator.
Activity | Duration | Type of Interaction |
---|---|---|
Interaction with web platform | 20 min | Use the web platform, assuming a certain role: doctor, laboratory, patient |
Usability survey | 5 min | Answer the survey |
Functionality survey | 5 min | Answer the survey |
No. | Questions | Strongly Agree | Agree | Neither Agree nor Disagree | Disagree | Strongly Disagree |
---|---|---|---|---|---|---|
1 | It was easy to learn how to use the system. | 10 | 10 | 7 | 5 | 0 |
2 | The information provided by the system is easy to understand. | 12 | 14 | 6 | 0 | 0 |
3 | The system has all the functionalities and tools that you expected it to have. | 12 | 15 | 5 | 0 | 0 |
4 | The organization of the information on the screen is clear. | 13 | 14 | 5 | 0 | 0 |
5 | Overall, I am satisfied with how easy the system was to use. | 10 | 11 | 7 | 4 | 0 |
6 | The system interface is nice. | 13 | 13 | 6 | 0 | 0 |
7 | I like to use the system interface. | 14 | 13 | 5 | 0 | 0 |
8 | I can effectively perform operations using the system. | 13 | 14 | 5 | 0 | 0 |
9 | Finding information or functionality of the system was easy. | 13 | 14 | 5 | 0 | 0 |
Total (N) | 110 | 118 | 51 | 9 | 0 | |
Percentage (%) | 38 | 41 | 18 | 3 | 0 |
No. | Questions | Strongly Agree | Agree | Neither Agree nor Disagree | Disagree | Strongly Disagree |
---|---|---|---|---|---|---|
1 | User registration is easy to perform and runs smoothly. | 10 | 9 | 9 | 4 | 0 |
2 | It is easy to log in to the website. | 6 | 10 | 7 | 9 | 0 |
3 | The user can see the access control relationships they are in (users with access to the medical record) and these are easily accessible in the interface. | 16 | 12 | 4 | 0 | 0 |
4 | The patient can modify permissions to decide who can see and/or modify their medical history in a satisfactory way. | 16 | 11 | 5 | 0 | 0 |
5 | The patient can activate the access requests of other users to their medical history (set status on). | 16 | 12 | 4 | 0 | 0 |
6 | The patient can view their medical history without problems. | 14 | 14 | 4 | 0 | 0 |
7 | The process of using the tool to interact with the system is easy and understandable. | 10 | 6 | 7 | 9 | 0 |
8 | The doctor can perform successful patient searches on the system. | 15 | 13 | 4 | 0 | 0 |
9 | The doctor can request a medical history from the patient. | 14 | 13 | 5 | 0 | 0 |
10 | The doctor can see the list of patient medical records to which they have access. | 11 | 16 | 5 | 0 | 0 |
11 | The doctor can see the medical records of the patients according to the level of access they have. | 16 | 12 | 4 | 0 | 0 |
12 | The family doctor can see and/or modify the medical history of their patients. | 12 | 15 | 5 | 0 | 0 |
13 | The family doctor can manage the medical history of their patients. (change access, change status) | 12 | 14 | 6 | 0 | 0 |
14 | The laboratory can perform satisfactory patient searches on the system. | 12 | 16 | 4 | 0 | 0 |
15 | The laboratory can make a request for clinical history to the patient. | 14 | 14 | 4 | 0 | 0 |
16 | The laboratory can view the list of patient medical records to which it has access. | 13 | 15 | 4 | 0 | 0 |
17 | The laboratory with full access can add records to the clinical history of its patients. | 13 | 14 | 5 | 0 | 0 |
18 | The laboratory can view patient records on the basis of the level of access it has. | 13 | 15 | 4 | 0 | 0 |
Total (N) | 233 | 231 | 90 | 22 | 0 | |
Percentage (%) | 40 | 40 | 16 | 4 | 0 |
References
- World Health Organization. Official Records of the World Health Organization. In Proceedings of the International Health Conference, New York, NY, USA, 19 June–22 July 1946; Volume 2, p. 100. [Google Scholar]
- World Health Organization. Report of the Third Global Survey on eHealth Global; WHO: Geneva, Switzerland, 2016. [Google Scholar]
- ISO/TR 20514: 2005(en) Health Informatics—Electronic Health Record—Definition, Scope and Context. Available online: https://www.iso.org/obp/ui/#iso:std:iso:tr:20514:ed-1:v1:en (accessed on 1 March 2020).
- Kahn, S.; Sheshadri, V. Medical record privacy and security in a digital environment. IT Prof. 2008, 10, 46–52. [Google Scholar] [CrossRef]
- OCR. Summary of the HIPAA Privacy Rule. HIPAA Compliance Assistance; OCR: Washington, DC, USA, 2003. [Google Scholar]
- UE. REGULATION (EU) 2016/679 of the European Parliament and of the Council. Available online: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02016R0679-20160504 (accessed on 19 May 2020).
- Davis Giardina, T.; Menon, S.; Parrish, D.E.; Sittig, D.F.; Singh, H. Patient access to medical records and healthcare outcomes: A systematic review. J. Am. Med. Inform. Assoc. 2013, 21, 737–741. [Google Scholar] [CrossRef] [PubMed]
- Odutola, A.B. Developing Countries Must Invest in Access to Information for Health Improvements. J. Med. Internet Res. 2003, 5, e5. [Google Scholar] [CrossRef]
- Daglish, D.; Archer, N. Electronic personal health record systems: A brief review of privacy, security, and architectural issues. In Proceedings of the World Congress on Privacy, Security, Trust and the Management of e-Business, Saint John, NB, Canada, 25–27 August 2009. [Google Scholar]
- Pussewalage, H.S.G.; Oleshchuk, V. A Patient-Centric Attribute Based Access Control Scheme for Secure Sharing of Personal Health Records Using Cloud Computing. In Proceedings of the IEEE 2nd International Conference on Collaboration and Internet Computing (CIC), Pittsburgh, PA, USA, 1–3 November 2016; pp. 46–53. [Google Scholar]
- Røstad, L. An Initial Model and a Discussion of Access Control in Patient Controlled Health Records. In Proceedings of the 3rd International Conference on Availability, Reliability and Security, Barcelona, Spain, 4–7 March 2008; pp. 935–942. [Google Scholar]
- Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Available online: www.bitcoin.org/bitcoin.pdf (accessed on 12 March 2020).
- Gupta, M. Blockchain for Dummies, IBM Limited Edition; John Wiley & Sons: Hoboken, NJ, USA, 2017. [Google Scholar]
- Javed, M.U.; Rehman, M.; Javaid, N.; Aldegheishem, A.; Alrajeh, N.; Tahir, M. Blockchain-Based Secure Data Storage for Distributed Vehicular Networks. Appl. Sci. 2020, 10, 2011. [Google Scholar] [CrossRef] [Green Version]
- Daraghmi, E.-Y.; Daraghmi, Y.-A.; Yuan, S.-M. UniChain: A Design of Blockchain-Based System for Electronic Academic Records Access and Permissions Management. Appl. Sci. 2019, 9, 4966. [Google Scholar] [CrossRef] [Green Version]
- Alsayed Kassem, J.; Sayeed, S.; Marco-Gisbert, H.; Pervez, Z.; Dahal, K. DNS-IdM: A Blockchain Identity Management System to Secure Personal Data Sharing in a Network. Appl. Sci. 2019, 9, 2953. [Google Scholar] [CrossRef] [Green Version]
- Figorilli, S.; Antonucci, F.; Costa, C.; Pallottino, F.; Raso, L.; Castiglione, M.; Pinci, E.; Del Vecchio, D.; Colle, G.; Proto, A.R.; et al. A Blockchain Implementation Prototype for the Electronic Open Source Traceability of Wood along the Whole Supply Chain. Sensors 2018, 18, 3133. [Google Scholar] [CrossRef] [Green Version]
- Satamraju, K.P.; Malarkodi, B. Proof of Concept of Scalable Integration of Internet of Things and Blockchain in Healthcare. Sensors 2020, 20, 1389. [Google Scholar] [CrossRef] [Green Version]
- Mettler, M. Blockchain technology in healthcare: The revolution starts here. In Proceedings of the IEEE 18th International Conference on e-Health Networking, Applications and Services (Healthcom), Munich, Germany, 14–16 September 2016. [Google Scholar]
- Hang, L.; Choi, E.; Kim, D.-H. A Novel EMR Integrity Management Based on a Medical Blockchain Platform in Hospital. Electronics 2019, 8, 467. [Google Scholar] [CrossRef] [Green Version]
- Kamau, G.; Boore, C.; Maina, E.; Njenga, S. Blockchain Technology: Is this the Solution to EMR Interoperability and Security Issues in Developing Countries? In Proceedings of the IST-Africa Week Conference (IST-Africa), Gaborone, Botswana, 9–11 May 2018; pp. 1–8. [Google Scholar]
- Azaria, A.; Ekblaw, A.; Vieira, T.; Lippman, A. MedRec: Using Blockchain for Medical Data Access and Permission Management. In Proceedings of the 2016 2nd International Conference on Open and Big Data (OBD), Vienna, Austria, 22–24 August 2016; pp. 25–30. [Google Scholar]
- Shen, B.; Guo, J.; Yang, Y. MedChain: Efficient Healthcare Data Sharing via Blockchain. Appl. Sci. 2019, 9, 1207. [Google Scholar] [CrossRef] [Green Version]
- Mcfarlane, C.; Beer, M.; Brown, J.; Prendergast, N. Patientory: A Healthcare Peer-to-Peer EMR Storage Network. Available online: https://www.patientory.com/wp-content/uploads/2017/04/Patientory_Whitepaper-1.pdf (accessed on 5 April 2020).
- Dubovitskaya, A.; Xu, Z.; Ryu, S.; Schumacher, M.; Wang, F. Secure and Trustable Electronic Medical Records Sharing using Blockchain. AMIA Annu. Symp. Proc. AMIA Symp. 2017, 2018, 650–659. [Google Scholar]
- Dagher, G.G.; Mohler, J.; Milojkovic, M.; Marella, P.B. Ancile: Privacy-preserving framework for access control and interoperability of electronic health records using blockchain technology. Sustain. Cities Soc. 2018, 39, 283–297. [Google Scholar] [CrossRef]
- Xia, Q.; Sifah, E.B.; Asamoah, K.O.; Gao, J.; Du, X.; Guizani, M. MeDShare: Trust-Less Medical Data Sharing Among Cloud Service Providers via Blockchain. IEEE Access 2017, 5, 14757–14767. [Google Scholar] [CrossRef]
- Roehrs, A.; da Costa, C.A.; da Rosa Righi, R. OmniPHR: A distributed architecture model to integrate personal health records. J. Biomed. Inform. 2017, 71, 70–81. [Google Scholar] [CrossRef] [PubMed]
- Schumann, R.; Kende, M. Lifting Barriers to Internet Development in Africa: Suggestions for Improving Connectivity; Analysys Mason Limited: London, UK, 2013; Volume 9, pp. 26–43. [Google Scholar]
- ArchiMate® 3.1 Specification. Available online: https://pubs.opengroup.org/architecture/archimate3-doc/ (accessed on 14 March 2020).
- Ethereum Foundation Home | Ethereum. Available online: https://ethereum.org/ (accessed on 15 May 2020).
- React—A JavaScript Library for Building User Interfaces. Available online: https://reactjs.org/ (accessed on 1 September 2019).
- PostgreSQL: The World’s Most Advanced Open Source Database. Available online: https://www.postgresql.org/ (accessed on 24 June 2020).
- Health Level Seven International-Homepage | HL7 International. Available online: http://www.hl7.org/ (accessed on 12 March 2020).
- ISO 18308:2011(en), Health Informatics—Requirements for an Electronic Health Record Architecture. Available online: https://www.iso.org/obp/ui/#iso:std:iso:18308:ed-1:v1:en (accessed on 12 March 2020).
- ASPE Secretary, Office Of The Assistant Evaluation, F.P.A.E. Health Insurance Portability and Accountability Act of 1996 | ASPE. Available online: https://aspe.hhs.gov/report/health-insurance-portability-and-accountability-act-1996 (accessed on 12 March 2020).
- Prusty, N. Building Blockchain Projects, 1st ed.; Packt Publishing Ltd.: Birmingham, UK, 2017; pp. 14–16. [Google Scholar]
- Lin, I.C.; Liao, T.C. A survey of blockchain security issues and challenges. Int. J. Netw. Secur. 2017. [Google Scholar] [CrossRef]
- Mohanta, B.K.; Panda, S.S.; Jena, D. An Overview of Smart Contract and Use Cases in Blockchain Technology. In Proceedings of the 9th International Conference on Computing, Communication and Networking Technologies (ICCCNT), Bangalore, India, 10–12 July 2018; pp. 1–4. [Google Scholar]
- ¿Qué son los Smart Contracts o Contratos Inteligentes? Available online: https://www.miethereum.com/smart-contracts/#toc2 (accessed on 12 March 2020).
- Zheng, Z.; Xie, S.; Dai, H.; Chen, X.; Wang, H. An Overview of Blockchain Technology: Architecture, Consensus, and Future Trends. In Proceedings of the IEEE 6th International Congress on Big Data—BigData Congress, Honolulu, HI, USA, 25–30 June 2017. [Google Scholar]
- Agbo, C.; Mahmoud, Q.; Eklund, J. Blockchain Technology in Healthcare: A Systematic Review. Healthcare 2019, 7, 56. [Google Scholar] [CrossRef] [Green Version]
- Cash, M.; Bassiouni, M. Two-Tier Permission-ed and Permission-Less Blockchain for Secure Data Sharing. In Proceedings of the IEEE International Conference on Smart Cloud (SmartCloud), New York, NY, USA, 21–23 September 2018; pp. 138–144. [Google Scholar]
- Wood, G. PoA Private Chains. Available online: https://github.com/ethereum/guide/blob/master/poa.md (accessed on 18 December 2019).
- King, S.; Nadal, S. PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake. Available online: https://decred.org/research/king2012.pdf (accessed on 18 May 2020).
- Castro, M.; Research, M.; Liskov, B. Practical Byzantine Fault Tolerance and Proactive Recovery. ACM Trans. Comput. Syst. 2002, 20, 398–461. [Google Scholar] [CrossRef]
- Hylock, R.H.; Zeng, X. A Blockchain Framework for Patient-Centered Health Records and Exchange (HealthChain): Evaluation and Proof-of-Concept Study. J. Med. Internet Res. 2019, 21, e13592. [Google Scholar] [CrossRef] [Green Version]
- Fan, K.; Wang, S.; Ren, Y.; Li, H.; Yang, Y. MedBlock: Efficient and Secure Medical Data Sharing Via Blockchain. J. Med. Syst. 2018, 42, 136. [Google Scholar] [CrossRef]
- Fu, J.; Wang, N.; Cai, Y. Privacy-Preserving in Healthcare Blockchain Systems Based on Lightweight Message Sharing. Sensors 2020, 20, 1898. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Quaini, T.; Roehrs, A.; André Da Costa, C.; Da, R.; Righi, R. A model for blockchain-based distributed electronic health records. IADIS Int. J. WWW Internet 2018, 16, 66–79. [Google Scholar] [CrossRef]
- Carrión Señor, I.; Fernández Alemán, J.L.; Toval, A. Gestión del control de acceso en historiales clínicos electrónicos: Revisión sistemática de la literatura. Gac. Sanit. 2012, 26, 463–468. [Google Scholar] [CrossRef] [PubMed] [Green Version]
- Blobel, B. Authorisation and access control for electronic health record systems. Int. J. Med. Inform. 2004, 73, 251–257. [Google Scholar] [CrossRef] [PubMed]
- Van Der Linden, H.; Kalra, D.; Hasman, A.; Talmon, J. Inter-organizational future proof EHR systems: A review of the security and privacy related issues. Int. J. Med. Inform. 2009, 78, 141–160. [Google Scholar] [CrossRef]
- Jafari, M.; Safavi-Naini, R.; Saunders, C.; Sheppard, N.P. Using digital rights management for securing data in a medical research environment. In Proceedings of the ACM Conference on Computer and Communications Security, Chicago, IL, USA, 4–8 October 2010; pp. 55–60. [Google Scholar]
- Michalas, A.; Dowsley, R. Towards Trusted eHealth Services in the Cloud. In Proceedings of the IIEEE/ACM 8th International Conference on Utility and Cloud Computing (UCC), Limassol, Cyprus, 7–10 December 2015; pp. 618–623. [Google Scholar]
- Pressman, R.S. Ingenieria del Software—Un Enfoque Practico, 7th ed.; McGraw Hill: Mexico City, Mexico, 2010; pp. 28–40. [Google Scholar]
- Clements, P.C. Coming attractions in software architecture. In Proceedings of the 5th International Workshop on Parallel and Distributed Real-Time Systems (WPDRTS) and the 3rd Workshop on Object-Oriented Real-Time Systems (OORTS), Geneva, Switzerland, 3 April 1997; pp. 2–9. [Google Scholar]
- De la Torre, C.; Zorrilla, U.; Ramos, M.A.; Calvarro, J. Guía de Arquitectura N-Capas orientada al Dominio con.NET 4.0; Krasis Press: Madrid, Spain, 2011. [Google Scholar]
- Kumar, A. How to Protect Sensitive Data and Limit Risk of Data Exposure or Leaks? Available online: https://www.csoonline.com/article/3114735/data-protection/how-to-protect-sensitive-data-and-limit-risk-of-data-exposure-or-leaks.html (accessed on 22 February 2020).
- Bakken, D.E.; Rarameswaran, R.; Blough, D.M.; Franz, A.A.; Palmer, T.J. Data obfuscation: Anonymity and desensitization of usable data sets. IEEE Secur. Priv. 2004, 2, 34–41. [Google Scholar] [CrossRef]
- Gutierrez, O.; Saavedra, J.J.; Zurbaran, M.; Salazar, A.; Wightman, P.M. User-Centered Differential Privacy Mechanisms for Electronic Medical Records. In Proceedings of the International Carnahan Conference on Security Technology (ICCST), Montreal, QC, Canada, 22–25 October 2018; pp. 1–5. [Google Scholar]
- Rashmi, N.; Jyothi, K. An improved method for reversible data hiding steganography combined with cryptography. In Proceedings of the 2nd International Conference on Inventive Systems and Control (ICISC), Coimbatore, India, 19–20 January 2018; pp. 81–84. [Google Scholar]
- Dhanalaxmi, B.; Tadisetty, S. Multimedia cryptography—A review. In Proceedings of the IEEE International Conference on Power, Control, Signals and Instrumentation Engineering (ICPCSI), Chennai, India, 21–22 September 2017; pp. 764–766. [Google Scholar]
- MisterGroup System Explorer—Keep Your System Under Control. Available online: http://systemexplorer.net/ (accessed on 13 June 2020).
- Apache Software Foundation Apache JMeter—Apache JMeterTM. Available online: https://jmeter.apache.org/ (accessed on 5 June 2020).
- Meier, J.D.; Farre, C.; Bansode, P.; Barber, S.; Rea, D. Performance Testing Guidance for Web Applications: Patterns & Practices, 1st ed.; Microsoft Press: Redmond, WA, USA, 2007; pp. 28–40. [Google Scholar]
- Molyneaux, I. The Art of Application Performance Testing; O’Reilly Media: Sebastopol, CA, USA, 2009; pp. 11–50. [Google Scholar]
- HealthyBlock Repository. Available online: https://github.com/giordyrp/healthy-block (accessed on 25 July 2020).
- Microsoft Explora el SO Windows 10. Available online: https://www.microsoft.com/es-co/windows/ (accessed on 9 April 2020).
- Navegador web Google Chrome. Available online: https://www.google.com/intl/es-419/chrome/ (accessed on 8 April 2020).
- Go-Ethereum Geth (v1.9.14). Available online: https://geth.ethereum.org/downloads/ (accessed on 3 June 2020).
- Sinha, P.K. Remote Procedure Calls. In Distributed Operating Systems: Concepts and Design; IEEE: New York, NY, USA, 1997; pp. 167–230. [Google Scholar]
- Singh, G.; Supriya, S. A Study of Encryption Algorithms (RSA, DES, 3DES and AES) for Information Security. Int. J. Comput. Appl. 2013, 67, 33–38. [Google Scholar] [CrossRef]
- OpenVPN. Available online: https://openvpn.net/ (accessed on 5 June 2020).
Variable | Levels |
---|---|
Number of threads (users) | 50, 100, 200, 500, 1000 |
Ramp-up period (seconds) | 60 |
Same user on each iteration | Yes |
Duration (seconds) | 300 |
© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
Share and Cite
Gutiérrez, O.; Romero, G.; Pérez, L.; Salazar, A.; Charris, M.; Wightman, P. HealthyBlock: Blockchain-Based IT Architecture for Electronic Medical Records Resilient to Connectivity Failures. Int. J. Environ. Res. Public Health 2020, 17, 7132. https://doi.org/10.3390/ijerph17197132
Gutiérrez O, Romero G, Pérez L, Salazar A, Charris M, Wightman P. HealthyBlock: Blockchain-Based IT Architecture for Electronic Medical Records Resilient to Connectivity Failures. International Journal of Environmental Research and Public Health. 2020; 17(19):7132. https://doi.org/10.3390/ijerph17197132
Chicago/Turabian StyleGutiérrez, Omar, Giordy Romero, Luis Pérez, Augusto Salazar, Marina Charris, and Pedro Wightman. 2020. "HealthyBlock: Blockchain-Based IT Architecture for Electronic Medical Records Resilient to Connectivity Failures" International Journal of Environmental Research and Public Health 17, no. 19: 7132. https://doi.org/10.3390/ijerph17197132