# eHealth Integrity Model Based on Permissioned Blockchain +
## 4 Conclusions and Future Works  
A module implementing the proposed model could easily be integrated in eHealth systems based on a service-oriented architecture. Only interfaces that provide data to the module must be added. The module does not require the change of an eHealth system's internal structure. The execution time of the integrity-verification time, as the test has shown, is short. Hence, the model is suitable for practical implementation.  
Security issues related to cryptocurrencies and PoA properties mean that, in practice, only PBFT blockchains (e.g., Hyperledger Fabric v0.6) can be used to secure eHealth systems. Another security aspect of blockchain usage is the privacy of the stored data. Privacy is ensured by using an encrypted transaction body and a covert identifier. A verifier must have access to all transactions in a blockchain related to a specified identifier, when they want to detect missing documents or logs. The map of covert identifiers to real identifiers is only available to entities that have an access right to the user's EHR. As long as the covert identifiers are kept secret (they should be secured using the same security mechanisms that are used to secure access to the EHR), an adversary can only obtain general anonymous statistical data.  
The main novelty of the paper is the solution to the problem of transactional transparency based on a blockchain with the option to remove documents or logs. The model contains two transaction types: 'add' (Type \(a\)) and'remove' (Type \(b\)). This mechanism allows the removal of any record, because only security-related metadata are stored in a blockchain. The only trace of a deleted record is two transactions with no information about the content or the origin of that document.  
Of course, authorised nodes should accept the removal of a type of transaction from the blockchain after verifying an authorized removal order. The structure of the removal order depends on system policy, but it is usually a digitally signed hash of a transaction. The removal order should be automatically countersigned by the system (probably transparently to a user in some cases) or by an authorized supervisor. Such an approach eliminates the possibility to use this as a standard option instead of submitting a new version of a record and keeping the old one for a reference. The order is not itself stored in the blockchain.  
It should be mentioned that the implementation of such a solution without a blockchain is a difficult task. The main problem solved by the blockchain is the creation of a single history of documentation that can be simultaneously created in many nodes in a distributed environment. An alternative solution based on timestamps from trusted third parties requires no more than a few central nodes. When the number of nodes rises, a synchronization protocol is required, and that leads to the introduction of the blockchain.  
Future work can include implementing a proof of concept for the model, and its testing in a laboratory environment. The test has shown that the verification algorithm is suitable for practical purposes, but it is not entirely certain how the number of nodes, the latency between nodes, and different attacks impact overall node performance. The test will be carried out to verify the impact of these factors.  
Conceptualization, T.H.; methodology, T.H. and J.P.; software T.H. and J.P.; investigation, T.H. and J.P.; validation, T.H. and J.P.; project administration, T.H.; writing--original draft preparation, T.H.; writing--review and editing, T.H. and J.P.  
This research received no external funding.  
The authors declare no conflict of interest.