The Medical Mining Database

• 

  Title

• 

  Interaction Diagram

_ (College/Professional) _

The Medical Mining Database

Healthcare providers need to be able to enter and share medical record data and patients need to be able to read medical record data, and all of this needs to exist within HIPAA compliance.

We're going to do that by combining blockchain and Gnu Privacy Guard technologies. Our solution is called:

The Medical Miner Database (MMDB)

MMDB is a modification of the open source ethereum blockchain software to include multiple parallel blockchains, called recordchains.

Addressing the processing requirements of Ethereum, which uses the hashcash method for proof of work, since this method of proof of work involves brute force guessing of numbers, it requires immense processing power and time in order to participate. This could get expensive over time, as healthcare providers continually spend income on expensive, non-healthcare related computing hardware updates to waste time guessing inconsequential numbers. Considering that a limited number of healthcare providers with existing expenses can modify a recordchain, the proof of work need not require expensive hardware or constant hardware updates to facilitate additions to the recordchain. In MMDB the proof of work required to make a change will be limited to an encrypted challenge using a listed public key, which is also known as “Proof of Stake.”

Since the database consists of multiple recordchains, a participant healthcare provider could choose to only store the recordchains for which it needs access. We need to discourage this behavior in order to retain the distributed nature of the MMDB, so a challenge will be provided from the receiving node to verify that the sending node contains a representative portion of the database. Random hashes from a minority of records will be requested from the sender and if a majority do not match, the transaction is rejected. Only a majority must match in case the records have been updated at the receiver before the sender has updated.

Each block in a recordchain, the record, will be encrypted using the public keys of all listed healthcare providers who have been granted access by a listed healthcare provider. The list of public keys is accessed by requesting the public key from an MMDB Key Registry server with the same nonce handshake as used between nodes. The patient is not listed in the MMDB Key Registry. Only a publicly listed healthcare provider can add to or modify the distributed recordchains, because a listed public key is required. This also means that only healthcare providers can process additions and modifications to the MMDB. If the address provided by the change requester is not listed, the process ends immediately. If it is listed, a nonce handshake is initiated using the listed public key to verify that the requester actually controls the private key. If successful, the process continues. If all of the above is satisfied and the previous record’s hash contained in the record matches the actual hash of the previous record, then the record is added to the recordchain and the node passes the change on to the next node. Deconfliction is handled purely by datetimestamp.

The patient's public key is part of the record for identification purposes. No personally identifiable information is stored in the recordchain. Since the patient creates the recordchain through the healthcare provider who is adding the recordchain, the patient's client software will be adding the patient's unlisted public key to the record for the healthcare providers to automatically include when encrypting so that the patient's access can never be removed without intentionally modifying the patient public key entry. If the patient's private key is compromised, a new recordchain will be created and the old will be defunct. It is suggested that healthcare providers keep a hard copy only record matching their recordchains with patients, however, recordchain identification will be a task for the healthcare provider’s system or client software.

For information hidden from the patient, such as psychiatric evaluations, two entries in the record will be an entry encrypted by only the healthcare providers' public keys and an entry containing a hash of the decrypted closed record. The entry containing the closed record data will not be included in the record's hash, because its hash will be included and changes would be opaque otherwise. The closed record data will not be acknowledged by the patient’s client software.

Each record will be linked to the previous using the standard Ethereum method of storing the previous record’s hash. Each recordchain's change status will be signified by each record's hash, which will be stored along with the encrypted block and the encryption method in the record update. Since the privacy and security of the records are of paramount importance to HIPAA regulations, the encryption level must withstand improvements in technology for the longest length of time possible. As such, the highest available key size for the encryption method used must be maintained, and rekeyed, as higher key sizes or more secure encryption methods become available or in cases where a private key has been compromised.

When designing secure encryption software, the design should be as perfect as possible before ever committing a single keystroke to code. Given that nugget of wisdom, we were not able to spend enough time coding to complete a working demonstration. But I can answer questions.

Built With

• blood
• c++
• elbow-grease
• ethereum
• gpgme
• sweat
• tears
• the-power-of-the-sun