28
Blockchain-Based Medical Records Storage.
I have noted that because my thesis (or my thesis video exposition) is not in English people do not read it, so, I decided translate this summary article of my thesis.
Abstract: Cuban health care system work with physical health records, some efforts for digitize health records has been realized but using centralized databases. In this paper we analyzed blockchain technology and a functional prototype for electronic health record storage using Hyerledger Fabric is proposed. This system is a solution baseline for the electronic health record storage problem in Cuba. The final solution will be a national blockchain network with encrypted data for privacy.
Table of content:
Introduction
-
1.1. How blockchain work?
1.1.1. The header of a block
1.1.2. Block body
1.1.3. How the blockchain works
-
Some most used blockchain platforms
2.1. Ethereum
2.2. Hyperledger Fabric
2.2.1. Public Key Infrastructure
2.2.2. Signature and channel policy
2.2.3. The ordering service
2.2.4. Chain code
-
System design and implementation
4.1. Structure, design and programming of the smart contract
4.2. Structure, design and programming of the application
4.2.1. Web application
4.2.2. Server
4.3. Structure, design and programming of the block-chain network
The medical records have evolved, it is no longer the typical paper that must be filed and transferred between hospitals to keep the patient's history. Today we have established international standards on what data a medical record should have and the communication protocols used to share medical records between digital systems. Complex database systems are used today for the maintenance of medical records, making medical records digital. However, there is no single standard communication protocol and no single storage standard, this means that interoperability between the digital health record systems of multiples institutions is difficult to achieve. In addition, in the case of centralized systems there is a risk of losing information in the event of a server failure. Also, because most systems use databases, this allows records to be modified without tracking these modifications, if an attacker takes control of one of these systems, information changes and data leaks will occur.
In Cuba, the Ministry of Public Health proposed several years ago a strategy for the computerization of the health sector, this strategy is under development. In Cuba medical records are stored in physical format and filed in hospitals, which translates into deterioration, space requirement for files, problems related to the transfer, possibility of alteration of the information, among others. Although progress is being made towards digitization in hospitals, the techniques used for this are supported by centralized databases, that bring the problems previously explained. Using blockchain technology it is possible to create a medical record registry that is distributed and therefore it would not be a problem for any of the nodes will disconnect, with immutable data and easily auditable knowing which user added data. If the system is at the national level, the problems of data portability between hospitals is resolved, if data is encrypted privacy is provided.
We experiments with a functional prototype which provide the characteristics mentioned previously. This prototype can be used as a base for a national health care system using blockchain technology. In Cuba, blockchain technology has not yet been applied to any sector. Our country continues to research this technology and the creation of an application of this type, no matter how small, can be seen as a novelty.
The first implementation of blockchain technology was Bitcoin [19]. In traditional banking systems the accounting book is centralized in the same bank, these banks store and control transactions. Blockchain technology works as a decentralized and public ledger, blockchain technology can be applied to sectors other than financial, such as: medicine, health, transportation, tourism, etc. With these features, blockchain can save costs and improve efficiency in a large number of areas, mainly the economic one.
A blockchain is a distributed system which has a data structure, the blockchain, and a consensus algorithm to ensure that the data structure is the same in all the nodes. The blockchain is a sequence of blocks that maintain a list of transactions, acting as a public ledger record. The block contains information on the transactions, and in the transactions you can find when it was carried out, what was the date and time and the data stored, as well as the interacting parties. Next we will see part of the structure of the blocks in Bitcoin, note that on other platforms of blockchain other fields can be used, however, for being the initial implementation, the most generalized and the best known, the Bitcoin blockchain is used to explain this technology.
The block header data allows maintaining the integrity of the blockchain and the chronological order of transactions, ensuring that the chain is immutable. The header of a block according to [23] has, among other fields:
- Merkle tree root hash: a binary tree whose leaves are the hashes of the transactions in the block and each parent node is the hash of its two children. This structure provides integrity to all transactions in the same block, including the order of the transactions.
- Nonce: a 4-byte field. It is used as a fundamental part of the consensus algorithm in Bitcoin.
- Parent block hash: ensures that the block has only one parent. It is the result of applying the hash to the parameters of the header of the parent block.
The body of the block is made up of the transaction counter and the transactions. The maximum number of transactions that a block can contain depends on the size of the block and the size of each transaction, the block cannot be empty and the minimum size can be the size of a transaction. Blockchain technology uses asymmetric cryptography to validate the authenticity of transactions [23]. Each user has a pair of keys, one private and one public. The private key is used to sign the transaction. The signed transaction is sent to all nodes on the network.
To add a block to the blockchain the following must be met [19]:
- A transaction must be made.
- The transaction must be saved in a block. Once the nodes have reached a consensus, the block is sent to all the nodes of the network. Note that the minimum time it takes for the block to be issued is the time it takes to establish consensus.
- The block is added to the blockchain if all the transactions in it are valid, it must be verified for each transaction, the time of the transaction, the amount transferred, the users involved, the digital signatures, etc.
- Once the block has been added to the blockchain, it can be seen by all nodes on the network and the transaction is confirmed in the system.
Blockchains can be divided into three types: public, private and consortium (permissioned, federated). In the first type, all transactions are readable and visible to each node of the network, any node can take part in the consensus process. In a private blockchain, only certain nodes, designated by a specific organization, are those that participate in the consensus deciding the order of the blocks in the blockchain and if the blocks that are published are valid or not, in addition, the transactions and data only are visible to these nodes. In consortium blockchains, only predefined groups can participate in the consensus process, and data, even if it has to be recorded through some mechanism, can be visible only to specific groups. In consortium blockchains, the permission of some of the organizations that make it up is required in order to become part of the system. In this way, blockchain technology can be used without sacrificing the authoritarian aspect of centralized systems, guaranteeing the ownership of the system by the owners. An permissioned blockchain is more efficient than a public one, since participation is restricted, weaker consensus algorithms can be used, that is, they do not need to work in environments where there may be rogue nodes that act maliciously. They also have a well-established governance structure, that is, a set of organizations charged with dictating the rules of the system.
Ethereum is a public blockchain platform that includes support for smart contracts, code that can be embedded and run on the blockchain. This allows including the code of the system itself in the same blockchain and developing decentralized applications. To guarantee a correct functioning of smart contracts and that they do not carry out malicious actions, they are executed in an environment that limits their computational power and storage [14]. One of the features that Ethereum offers, in addition to smart contracts, is the creation of custom tokens, that is, it provides standards for the creation of tokens, this is an achievement with respect to other technologies, since we can not only use the blockchain to account for cryptocurrencies, but also any object that has the characteristics of the standards that are defined.
Hyperledger Fabric (Fabric) is an open source permissioned blockchain designed for business use with some differences from other blockchain platforms. Fabric is established under the Linux Foundation which has a long history of open source projects with a fairly strong community. This platform is highly modular and configurable, allowing its adaptability to a wide number of use cases, it also supports smart contracts written in general-purpose programming languages such as Java, Go (Golang) and Node.js [10]. To understand Fabric, you must first understand the different components that make it up separately and then see the relationship between them. Fabric is one of the most complex blockchains that exist due to the amount of components and options it offers, it is also one of the most powerful thanks to its flexibility derived from the modular design with which it is built.
One of the fundamental components of Fabric is the Public Key Infrastructure (PKI) [8], from it the necessary certificates are issued to authenticate each entity in the system and take any policy with the same. One of the fundamental components of Fabric is the Public Key Infrastructure (PKI) [8], since it is from this that the necessary certificates are issued to authenticate each entity in the system and take any policy with it. The public key infrastructure is made up of Fabric's own certificate authorities (CAs) [8]. It is possible and should be used professional CAs in production networks, this means that the use of the CA that comes by default is not mandatory, a sample of the modular capabilities of this powerful blockchain that allows modification and adaptation to the use case of practically any of its components [8].
This blockchain does not require a native cryptocurrency. The introduced transaction architecture follows the execute, order and validate model unlike most of the existing blockchains whose model is order and execute. In the case of Fabric, the transaction is executed, it is verified that it is correct and it is signed, it is ordered following a consensus protocol and then it is validated following a specific signature policy before being added to the chain [5]. A signature policy in Fabric specifies which or how many nodes (peers) need to verify the correct execution of the contract and then sign the result, this allows parallel execution increasing scalability and speed, the first phase eliminates any type of non-determinism and the inconsistent results can be filtered before the ordering of transactions in the block. Confidentiality is achieved in Fabric through channel architecture, the participants in a network can establish channels (blockchains) between the subset of participants that must have visibility on a particular set of transactions, in this way only the nodes that participate in the same channel can access to contracts and data in the channel, a way to maintain privacy.
The ordering of the transactions is delegated to a modular consensus component which is decoupled from the nodes that execute the transactions and maintain the blockchain [5], in this case the ordering service, a set of special nodes in charge of this task called orderers. The assets in Fabric can range from tangible to intangible such as contracts or intellectual property, it is possible to modify the assets using chain code (we will see this concept later, suffice to say that they are the contracts of this blockchain), the assets are represented as a collection of key-values whose states change and are stored in the chain of some channel [8].
In Fabric, the term chain code (chaincode) is used instead of smart contract. A contract defines the logic of the transaction, controlling the life cycle of the objects in the network, these contracts are packaged within a chain code, which is deployed in the blockchain network [5]. The chain code is nothing more than a Docker container [9], which guarantees isolation, ease of copying and execution, among other benefits. The contracts can execute other contracts both inside and outside the chain code and inside or outside the channel, this depending on the permissions given in the network. The signature policies are what differentiate Fabric from other blockchain platforms, on other platforms any node can generate valid transactions, in Fabric the transactions must be validated by trusted organizations on the network, creating a more realistic model [5].
Figure 1: Hyperledger Fabric network.
Among the blockchain implementations applied to digital medical records is MedRec [12], which has a modular design. This system encourages the medical community to take part in the verification of transactions, doing proof of work (Proof of Work, PoW, Bitcoin consensus algorithm) [19]. In [12] Ethereum is used to perform access control and permission management to patient data. In each block, the permissions that different entities have in the network on the digital medical records of the patients are saved, however, these are stored by providers in centralized databases. Ethereum smart contracts are used to modify the permissions on digital medical records. Something to highlight is that granular access is guaranteed, that is, patients can give access only to specific parts of their data, so a permission in a block of [12] is represented as an SQL query that can be executed in a database. Patients are informed at all times of any change or access to their digital medical record and can accept or reject it.
In [15] we find another proposal for a system for digital medical records based on blockchain, in this case it makes use of two cryptographic algorithms that are not generally used in the works found and thus allows us to analyze the advantages of new cryptographic algorithms applied to the blockchain technology and digital medical records. One of them is the chameleon hash [16], this allows creating collisions if you have a private key, if you do not have such a key it works like any other hash function, the usefulness of this function is evident, it allows the owner of the private key, without having to modify the hash, being able to modify the data. The other technique mentioned is re-encryption with a proxy (re-encryption of the proxy) [17, 20], in this case the owner of the data, with the data encrypted, without the need to decrypt the data, allows a requestor of the data to receive them and being able to decrypt them, keep in mind that this allows you to save encrypted data and avoids the need to decrypt and re-encrypt it for sharing.
In [15] there are two types of blocks in the blockchain, the registry block (logs) and the patient block, in the case of patient blocks these are mutable, that is, the information that is in them is modifiable, in the case of register blocks these are immutable. The blockchain used in [15] is permissioned (consortium), it also follows a mixing scheme, in the same blockchain these two blocks coexist. As already said, the registry blocks are immutable and store information about the operations that are carried out in the blockchain, such as adding patients, modifying the patient block metadata, creating and executing smart contracts, among others, the normal hash function is used for this type of block and its data is not encrypted. In the case of patient blocks, these consist of plain text metadata, encrypted patient data and smart contracts, using chameleon hash.
The experiment carried out uses Fabric as a blockchain platform. This platform was selected since it is a consortium blockchain, so it allows to relax certain characteristics such as the consensus algorithm, which is much faster than that of most public blockchains. In addition, because smart contracts must be created by trusted entities, they do not have the high restrictions of computing power, memory and times that it can be executed (in a certain time interval) than in other platforms such as, for example, Ethereum. For the creation of the smart contract, Convector [2, 3] was used, a framework that uses the Model-Controller scheme where the models define the structure of the data that will be stored in the blockchain and the controller the logic that manipulates the models or instances of a model, objects that have the structure of the model. We will use the term model instance to disambiguate when it refers to the object that presents the model structure and not to the structure itself. To interact with the system a web application is used, giving the possibility of access through the browser. The server of this application is in charge of converting user requests into transactions sent to the blockchain.
As previously explained, the contract was developed using Convector so it is divided into models and a controller, the models follow the OMOP standard (Observational Medical Outcomes Partnership), guiding us by what is suggested in [21] and for its simplicity, this standard was selected. The OMOP standard is one of the simplest standards, it represents using a tabular model the relationships between data relevant to the patient and those of other entities related to this [21]. One of the strengths of this standard is that it allows the data to be converted into observational databases (which store information about observational clinical studies) in a standard format and evidence of this process can be record using analytical tools that are also standardized.
In the same way as in [22] we will not use all the tables or all the fields of the OMOP standard. In this case, only the Drug_Exposure, Note and Person tables were used (which has been renamed to Pacient in the contract code), in figure 2 you can see these tables with all the fields.
Figure 2: Tables used from the OMOP standard, all their fields are shown.
In figure 3 you can see on the left the selected fields of the Person table, on the right you can see the model derived from this table. Note the similarity between the names of the properties of the model and the names of the fields in the table. It must be taken into account, both for this model and for the others, that the properties do not save the values that are expected to be stored by the fields of the tables, since not all the tables are used, some properties do not save the true ones standard values. The string data type refers to the character string and the int data type refers to the integer.
Figure 3: Structure of the Person table and its corresponding model.
In the case of the Person table, a model Pacient is created, which has among its properties pacientIdentifier, number with the patient's unique identifier, dayOfBirth, number with the patient's day of birth, monthOfBirth, a number with month of birth, yearOfBirth, number year of birth, ethnicity, character string belonging to race, gender, character string belonging to to sex.
Figure 4. Structure of the Drug_Exposure table and its model.
DrugExposure (right), which is derived from the Drug_Exposure table (left), both in Figure 4 with the fields that were selected. This contains the properties (attributes), drugId, a number that would be the unique identifier of the drug, pacientIdentifier, a number that is the unique identifier of the patient to whom the drug is administered, startDate and endDate, a string of characters that are related to the fields drug_exposure_start_date and drug_exposure_end_date, start and end of the drug administration time, drugType, character string that stores the type of drug, stopReason, character string that stores the reason for drug suspension, daysSupply, number with the number of days administration of the drug and lotNumber, number to store the batch of the drug.
The selected fields from the Notes table can be seen in Figure 5, again on the left and the corresponding model on the right. The properties of the model fields are, noteId with the unique identifier of the note, a number, pacientIdentifier, again, the identifier of the patient to which said note belongs, noteDate, a string of characters, storing the date the note was created, noteTitle, string of characters with the title of the note, noteText, string of characters to store the text of the note.
Figure 5. Structure of the Note table and its model.
Two other models were added, not related to the standard, to also store their information, these are Admin and Doctor (administrator and doctor respectively, figure 6), the actors of the system and therefore they will be the ones who manipulate it taking into account account for the necessary authentication and permission management performed on the server.
Figure 6. Structure of the Admin and Doctor models.
In this way, the Admin model is made up of the attributes (properties) identifier, which serves as a unique identifier of the system administrator, a number, firstName, a character string containing the administrator's first name, email, character string, hashedPassword , character string containing the hash of the administrator password. The Doctor model contains the same fields (attributes) mentioned in the case of the administrator, but in addition, it also has secondName, a string of characters that contains the second name, if it exists, firstLastName, a string of characters that contains the first surname, secondLastName, similar to the previous one but stores the second surname, specialty, stores the specialty of the doctor.
The controller defines in its methods the logic to manipulate the instances of the models, some of these methods will be the transactions. If a method is considered a transaction, a client of the system can request its execution and obtain the result of the same or manipulate the chain of blocks. Among the methods that are treated as transactions are:
- Methods to create instances of each of the models, these methods receive as parameters the data of the instances to be created (the properties previously seen in the models) and if it is not found in the blockchain, the object is created and stored.
- Methods in which the exact instance of a model is obtained through its identifier.
- Methods that return the administrator or the doctor given their email, the latter used for user authentication at the time of logging in (see figure 9).
- Method to obtain all the instances of a specific model, this returns a list with all the objects and if there are none of the requested type, it will be empty.
It should be noted that no transactions were added to update or remove instances of the model, this because it was explicitly requested as a system requirement, however, it does not imply any complexity to add them in case of a modification to the contract in the future.
The application is divided into two parts, server (backend) and web application (frontend), the server is responsible for listening to requests from the web application and communicating with the blockchain if necessary.
When accessing the URL (Uniform Resource Locator) of the application site (in our scenario, port 8080 of the machine where the system is running) it is redirected to an authentication page, in which we are asked to enter the email and password, if the user (doctor or administrator) is registered in the blockchain, they will be able to access the system by entering their data. In figure 7 you can see the scheme of possible actions for doctors and administrators. In case of being an administrator once authenticated, you will have the right to see the lists of doctors and administrators, having permission to add both the first and the second, as well as see the data (properties, attributes, fields) of the doctor or administrator that you want . In case of authenticating as a doctor, you will be able to see the lists of patients, notes and drug exposures, you will be able to see all the data related to each of the stored instances of these models and add any type of them to the system.
The server was made using AdminBro [ 1 ], a framework that allows us to automatically generate the website used from the simple definition of a configuration.
Figure 7. Possible actions for system administrators and doctors.
This tool (AdminBro) is extremely flexible despite its potential, since being open source allows the modification of its components, this flexibility can be used in future works that require adding functionalities or modifying existing ones. The server waits for the requests (operations performed) from the browser and sends the corresponding transactions to the blockchain. For example, if a user logs in, the server sends a transaction to verify that the user is stored in the blockchain, the same happens if you want to add an instance of a model, the user enters the data of the instance to create in the browser form, the browser sends this data to the server and the latter will send a transaction to the blockchain to create the requested instance with the received data. Server tasks include authenticating responses from the node and other entities on the network and working with the digital certificates and private keys required to perform transactions. These last tasks would be too complicated for users to perform from the browser since they involve the storage of this data that must be well protected.
The network structure used consists of an organization with a node, a CA and an orderer node. Note that no more than one node is needed because the network is a virtual test network that will run on one computer, so no failures are expected to occur except for the computer where the network is running, on which in case the entire network would fail, in the same way it is not necessary more than one computer, for the same reason, it is not necessary more than one organization, since it is the private network, which was a requirement, however, taking into account considering the characteristics of the Cuban health system, centralized, unique, where there are no separate institutions that must have their own characteristics, an organization is recommended. In the case of the production network, it would be necessary to have several nodes, probably one per hospital, several orderer nodes and several CAs to guarantee, in addition to the certificates of the different entities, the TLS (Transport Layer Security) certificates.
Figure 8. Architecture of the network used.
In figure 9 you can see the flow diagram (simplified) of a typical user session. Once the user accesses the URL of the web application, the authentication page is displayed and they must enter their email and password, data that was stored in the blockchain by a system administrator when the user's account was created. Once the authentication data has been entered, you can follow the diagram from first step and see how the server interacts with the node to obtain the instance of the model corresponding to the user and verify their password. In Fabric there are two types of transactions, query and the normal ones. The query transactions, as their name indicates, are only to consult the blockchain and obtain information stored in it, these transactions are not stored in the blockchain, their use can be seen in steps 2, 8 and 23. In step 2 the query transaction is performed by the server to obtain the instance of the model that contains the user's information (step 3 and 4) to authenticate the user and allow him to log in (step 5 and 6), this after the browser has sent the email and password of the user that were entered by the user on the authentication page. The transaction in step 8 is the result that, once the user has logged in, they decide to list all the instances of the same model type on the web page (step 7), for example the user may want to see the list of all the notes stored in the system (if you are logged in as a doctor) or view all the doctors (if you are logged in as an administrator). Step 22 occurs once the user on the web page wants to see the data for a specific model instance, as a result, the server sends the query transaction in step 23.
Figure 9. Flowchart of a typical user session.
Normal transactions are stored in blocks that will be added later to the blockchain, an example can be seen in step 13. As with most blockchains, the blocks must be issued for a certain period of time (time it takes for the nodes to reach a consensus, see section 1.1.3, not be empty and have a certain size. In the case of the platform used, this must be fulfilled, so it is possible for a block to have only one transaction if only this has been carried out during the time interval in which the block must be issued. You can see how the transaction used in step 13 follows a different flow than the others, in this case, the user creates a new instance of a model by entering their data in the form on the web page, the browser sends this information (step 12), the server creates the transaction and sends it to the node (step 13), the node consults the blockchain to obtain the instances that will be updated (step 14), if there are no such instances, it continues in the same way, the node executes the smart contract and signs the result, which is sent back to the server (step 15). The server, the only client on the network, receives the response signed by the node, in this case the instance of the model that will be added to the blockchain, sends the response to the orderer (step 16), the orderer enters the response in a block (step 17) to be delivered to the node (step 18). Upon receiving a block from the orderer, the node adds it to its copy of the blockchain (step 19) and emits an event informing the client that the result of its transaction has been stored (step 20), later the server can send it the data of the model instance to the browser so you can see them (step 21). Note that these normal transactions follow a different design, as mentioned in section 2.2.2, in this case the execution, order and validation design.
To run the system, a Lenovo IdeaPad Z510 laptop with an Intel i7 processor, 8 gigabyte of RAM (Random Access Memory), Ubuntu 18.04 as the operating system was used in addition to Docker for the execution of the virtual network and Node.js with TypeScript [11] for the development of the smart contract with Convector. The blockchain network was created using Hurley [6, 7], a tool from the Convector suite that allows the creation of simple networks. Hurley has a configuration file for the creation of a single node network, then the chain code is installed using the install command, to know a little more it is suggested [6]. Hurley does not include any abstraction, that is, it only runs automatically and sequentially the tools that Fabric provides for networking. The server, also developed with Node.js and TypeScript, uses the Fabric SDK (Software Development Kit) to communicate with the node and send transactions and receive its responses.
The server has a default administrator account, which is created when it is run for the first time. With the administrator account, operations were carried out to add administrators and doctors, as well as to list or view their data, this was also done for the models of notes, patients and drug exposures through a doctor account. It was possible to verify that the system responds immediately to requests (maximum response time of 2 seconds), although it must be taken into account that when running in a virtual network on a machine this is not an indicator of real behavior in a cluster whose components could be in different provinces of the country and therefore sending the information through the network may take some time. However, taking into account that the entire system ran satisfactorily, the low demand it makes on the resources of a computer is evident, that is, although it is expected that the machines of a future cluster will have sufficient storage capacity through hard disks (to save the blockchain) do not need to have a lot of computing power (through fast processors and a lot of RAM). This last result is important, due to the particular conditions that we have in our country and the difficulty of having access to high-performance machines, given the high costs in the market, it is expected that it will be possible to work with machines of medium or low performance, which also translates into electricity savings. We can see the same results as in [18], in where the low cost of a fabric network is appreciated. In the negative side, we can highlight the need for an Internet connection (more precisely to a Node Package Manager repository) for the installation of the chain code. This is a requirement of version 1.4 (one of the most recent) of Fabric for the verification of the different dependencies of the smart contract code, however, as of version 2 this is unnecessary [4]. Unfortunately, version 2 has been released a few months after the experiment in this article was created, but is expected to be used for the next stages of the project.
Due to time and resource constraints, this work has experimented with the creation of a blockchain network prototype, demonstrating that this technology is feasible to solve the problem of storing medical records. Due to time and resource constraints, this work has experimented with the creation of a blockchain network prototype, demonstrating that this technology is feasible to solve the problem of storing medical records. Although it is evident that the prototype presented may not be better than a database, it is expected that this will not be used as a final solution but will be part of a set of systems that will be carried out incrementally until a final system is obtained, a blockchain network at the national level that will be a solution to the problem of storing the country's medical history. A database was not used due to the need to carry out the first practical tests with a technology that has not yet been used in our country, and thus be able to obtain a better knowledge of it. In addition, directing these tests to the use case we are dealing with (storage of digital medical records) gives us the advantage of, as already explained, having a base from which the system can continue to be developed and improved. The present experiment of the blockchain network has authentication and permission management on the server side, communication with the blockchain that is used as a data layer, storing both the medical records and the authors of the system using the certificate of the only user registered in the system. In this work, the most used and important transactions were created, a website is created and it can be reused and adapted even for the following phases of the project. The fundamental features of Fabric were learned and shown to have the adaptability to create the desired system. The theory of blockchain technology was explained and works of application of this technology were presented. In addition, the Adminbro framework was also introduced, which can be easily adapted to solve any problem based on data manipulation in a system. This framework can be used at any stage of the system since it can be modified at will, this is an advance since it allows us to have a server with its web application prepared in a simple way without having to carry out a new project.
Blockchain technology could help the Cuban planned economic model by allowing greater control and surveillance over the processes that are carried out through these systems, improving decision-making and security. The platforms that are most adapted to our country are, as seen above, the permissioned and the private, the former can be used mainly between government or business institutions, while the latter could be applied within the institutions themselves. One possible use could be for notarial records. A blockchain system applied to notarial records would allow knowing all the history of changes that have been made, as well as who made them, this would be done safely, that is, the immutability feature of the blockchain would guarantee that this information cannot be altered. In addition, the distribution characteristic guarantees the resistance to system failures. Another immediate use could be the creation of a Cuban cryptocurrency, backed by some good that our country has such as nickel or cobalt and that can be exchanged for other more used cryptocurrencies such as Bitcoin, this would be an advantage that would allow to overcome the obstacles financially existing. Additionally, the agricultural sector could benefit from allowing food traceability using blockchain. Definitely in our country there are scenarios that would benefit from blockchain technology, many of these scenarios may be the same as in the rest of the world, however, it is also possible that given the characteristics of Cuba and the obstacles it faces, new fields of application may emerge.
One of the most complex parts of the system is the network creation, due to the large number of parameters required to the connection on the platform used, in addition to the large amount of requirements such as certificates, membership services and their synchronization, certification authorities, channel configuration, etc. The final stage of the system is expected to provide security through the encryption of the stories, traceability of data modifications, not having points of failure, immutability, authentication and permission management (in the blockchain), of the different authors of the system, among other advantages.
To ensure the privacy of medical records and that they are not compromised in the node's file systems, the medical records must be encrypted. A simple method to achieve this goal is classic symmetric encryption. For this, the records would be encrypted with a randomly generated key or created by the doctor who created the medical record, this key would be encrypted with the public key of each doctor, to revoke access the key is changed and the new key is delivered to whom they have access (encrypted with their public key). Thanks to the ability to execute code in the browser, this method can be exploited to increase security, so that some operations such as decryption or encryption of the medical record can be performed in the same browser. Another work that should be left for the future is the storage of large files such as photos and videos, this must be done in distributed databases or similar such as IPFS (InterPlanetary File System) [13], the best method is yet to be studied since each type of storage has its advantages and disadvantages. In this way, only the hash of the medical record would be stored on the blockchain.
Note: this article was translated with Google translate help.
28