EmeraldMedic aspires to define a protocol for reading and writing to the patient medical records, regardless of their in-house IT infrastructure. For that, we've decided to use the Ethereum blockchain as a mechanism to enforce adherence to the protocol rules and as a tool to verify the authenticity of information that is received from external source. To achieve that we'll have a system in which each patient will have its unbalanced Merkel tree. Each new data entry to that tree will be a leaf at height n+1, that leaf will be hashed against the root of the previous data entries at height n. That way each data entry can be verified both individually and as part of the complete set of data entries. This gives the data verification process the quality of soundness, that is, you can only positively prove the existing of data that is part of the system, and nothing else. For write functions, the system will use a series of smart contracts that will execute the following general logic:
Fig 1. Submitting a message
- 1. The doctor creates a data entry in accordance to one of the existing data markups such as FHIR HL7 and/or CDISC
- 2. Smart contracts are validating the data entry to make sure it contains all the necessary information and indeed adheres to the desired markup.
- 3. Identity specific fields such as the identity of the patient and role of a required member of staff will be managed by our identity system, described here.
- 4. Once the data entry is validated for its correctness a process of signing and hashing of the information is taking place:
- 4.1 A timestamp and a nonce are inserted into the data entry plain text.
- 4.2 The doctor signs the plain text version of the data entry (with the nonce and the timestamp) and provide the signed document with the signature of the patient.
- 4.3 The patient then signs the plain text with the doctor signature, the time stamp, and the nonce.
- 4.4 The entire document is then hashed multiple times (The functions and methods will be defined soon - it's likely that we'll use the multihash format for each hash iteration) All of the processes described in step 4 are done using a local call on the EVM - no information is available to the Ethereum network yet.
Fig 2. The Patient Merkle Tree
- 5. The doctor will sign an Ethereum transaction calling a function on the patient smart contract - the function will hash the data entry and find the new root of the patient Merkel tree. The function will not update the Merkle tree yet!
- 6. The patient will be required to take a copy of the plaintext data entry with the signatures (both of the doctor and the patient) the nonce and the times
- 7. The patient will use their EVM to verify the correctness of the information and will match the final result to the one the doctor wishes to insert to the patient Merkle tree. Also, the doctor signature can be matched to the msg.sender of the transaction
- 8. If both are the same, the patient Merkle tree is then update