# eHealth Integrity Model Based on Permissioned Blockchain +
## 2 Blockchain Based eHealth Integrity Model
### Verification  
The first step in a verification procedure is to select transactions \(T\) that have specified covert ID from blockchain \(B\). Then, a verifier decrypts these transactions. In all cases, a verifier must have access rights to user's decryption key. The Figure 3 shows different cases of integrity verification. On the left side are visible records from a user's EHR. The middle part contains information if a hash from a  
Figure 2: Illustration of adding Subtype \(b\)–_remove_ transactions.  
given record match a hash stored in blockchain \(B\) and information in which \(j\) transaction in \(B\) the hash of the record is stored. On the left side are depicted verification results. In BEIM it is possible to verify:  
The first step in a verification procedure is to select transactions \(T\) that have specified a covert ID from blockchain \(B\). Then, a verifier decrypts these transactions. In all cases, a verifier must have access rights to a user's decryption key. Figure 3 shows different cases of integrity verification. On the left side are visible records from a user's EHR. The middle part contains information when a hash from a given record matches a hash stored in blockchain \(B\), and information in which \(j\) transaction in \(B\), the record hash, is stored. On the left side, verification results are depicted. In the BEIM, it is possible to verify:  
1. proof of existence of a record (transaction Type 1) or an entry (transaction Types 2 and 3). A verifier calculates a hash from a record; when a blockchain contains a transaction with that hash and the transaction creation time matches the record creation time, verification is positive;
2. EHR integrity, access-rights entries, or log-entry integrity; in this case, a verifier: 1. selects all entries (records) (Types 1, 2, or 3) in the EHR that have the same public ID and calculates their hashes H; 2. for every hash \(h\) from \(H\) and related entry number \(j\), a verifier tries to find transaction \(t\) containing hash \(h^{\prime}=h\) in transaction set \(T\). \(T\) contains selected transactions from blockchain \(B\) where the cover ID corresponds to the public ID; the following situations might occur (compare with Figure 3): 1. an item that the blockchain contains is a Type \(a\) transaction with hash \(h^{\prime}=h\); the blockchain does not contain Type \(b\) transactions with \(h^{\prime}=h\) (Figure 3, Case 1); 2. the blockchain does not contain Type a transactions with hash \(h^{\prime}=h\), but contains Type \(a\) transactions with number \(j^{\prime}=j\) (Figure 3, Case 2); 3. the blockchain does not contain Type \(a\) transactions with hash \(h^{\prime}=h\) and entry number \(j^{\prime}=j\) (Figure 3, Case 3); 4. the blockchain contains Type \(a\) and \(b\) transactions with hash \(h^{\prime}=h\) (Figure 3, Case 4). 3. When a transaction \(t\) from \(T\) is not matched in Step 2b, the following situations might occur: 1. the blockchain contains Type \(a\) and \(b\) transactions with the same hash \(h^{\prime}\), but hash \(h=h^{\prime}\) is not present in \(H\) (Figure 3, Case 5); 2. the blockchain contains Type \(a\) transaction \(t\) with \(h^{\prime}\) and \(j^{\prime}\), but there is no entry with number \(j=j^{\prime}\) and \(h=h^{\prime}\) (Figure 3, Case 6); 4. verifier returns _true_ when only Situations 2(b)i and 2(c)i occur; otherwise, a verifier returns _false_. When 2(b)ii is met, it means that entry \(j\) was modified. When 2(c)ii is met, entry \(j\) was not added to a blockchain, and when 2(c)ii is met, entry \(j\) is missing. Additionally, when 2(b)iv is met, it means that entry \(j\) was not removed as declared, which invades privacy and means that a node misbehaves.