A technical overview of MedCredits’ decentralized and encrypted EMR

MedCredits is the first truly decentralized healthcare platform that unifies medical services and storage of medical records. This post will describe how this is accomplished. The Hippocrates teledermatology dapp will be used as the framework for this discussion, but the proposed solution will be available as an open-source API for development of any 3rd party healthcare dapp.

MedCredits uses Swarm for the decentralized storage of healthcare data. When a document is uploaded to Swarm, a unique hash is provided by the Swarm API. This hash is then used to retrieve the document from Swarm. To associate this hash with a patient-doctor transaction, this hash is stored on the blockchain and used to reference the associated document. When using this strategy to store healthcare data there are several considerations:

• Data stored on the Blockchain is public and immutable.
• Data stored in decentralized storage is public.
• The only way to secure sensitive data in such systems is using encryption.
• Every time data is added to a medical record a separate encryption key should be used to minimize risks.
• By principle, patients must control access to their healthcare data.

It is quite straightforward to encrypt data. In the Hippocrates dapp, data for each case is encrypted with a unique encryption key using symmetric encryption. In symmetric encryption, the same key is used to encrypt and decrypt data. The encryption key is randomly generated using the AES algorithm the moment a patient submits a case to the system. The AES algorithm is one of the most widely used symmetric algorithms and does not have any known vulnerabilities.

The dilemma is as follows: initially the encryption key is only available to the patient but the encryption key needs to be shared with a physician so that she may review the case. However, the patient does not know in advance who this doctor will be and all data on the blockchain is publicly available. For this reason, the encryption key itself must be encrypted initially in a manner that only the patient can decrypt it, but ultimately in a manner that allows the treating physician to decrypt it. This requires asymmetric encryption, or public-key cryptography. Asymmetric encryption is a form of encryption where keys come in pairs. What one key encrypts (public), only the other can decrypt (private). Fortunately, every ethereum user already has a set of public and private keys in order to interact with the blockchain. Ethereum uses elliptic curve cryptography with the secp256k1 curve. The same keys can be used for asymmetric encryption of patients’ healthcare data.

Accounts in ethereum smart contracts are identified by address and not public key. For a smart contract to know the public key, a current transaction must be sent by that account. For that reason, public keys of the patients and doctors are recorded in MedCredits smart contracts when users register for the system. Doctors’ public keys will be housed in a unique physician registry contract (more to come on that in future posts).

Following registration, patients will submit cases for physicians to review. Documents will need to be stored at various points throughout the patient-doctor interaction. These documents will consist of serialized data (JSON) and images. The Hippocrates UX provides the user a means to input this data. Hippocrates will generate an encryption key and the data will be encrypted using the AES algorithm. The encrypted data is uploaded to Swarm and Swarm will return a hash. Finally, the encryption key itself is encrypted by the patient’s public key and both the encrypted key and the hash are stored on-chain. The patient case is now posted in the queue of active cases pending physician review.

Following case submission, a doctor will request access and review the case. The smart contract can recognize a doctor because all doctors’ public keys are stored in the unique physician registry contract. Once a doctor requests access, the patient knows who the treating doctor will be and the patient will decrypt the encryption key with their private key and encrypt it with the doctor’s public key. Note that for the sake of expediency, in Hippocrates, every case request by a physician is automatically granted access to the case details. In many other applications, the patient will prefer to manually give permission to a requesting physician to view his healthcare data (e.g. prior to an upcoming outpatient appointment with a new specialist).

Once the doctor has reviewed the case details she will submit a diagnosis. This will be added to the case details and a new submission will be sent to Swarm encrypted with the patient’s public key. Note that data has now been added to the patient’s case files and this is recognized by the issuance of a new hash.

As an abstraction, a patient’s healthcare data can be continually aggregated with each additional healthcare transaction. Since all MedCredits data is modeled on HL7/FHIR open standards, this data management strategy ultimately yields a comprehensive universally interoperable medical record. The most recent hash references the up-to-date medical record and is only available to the patient.

Finally, the patient retrieves their diagnosis from Swarm and decrypts it using his private key. Because the most recent hash on-chain reflects the up-to-date medical record, if a patient attempts to re-write his own medical data, it will be readily apparent. Additionally, because the physician registry contract contains the public keys of all registered physicians, any hash generated in a transaction that does not involve one of these public keys is very clearly a nefarious attempt to re-write medical records. This fool-proof system prevents patients from writing to their own medical records in an environment where they control access to the data.

In conclusion, MedCredits uses Swarm for decentralized healthcare data storage. MedCredits has designed an open-source key-exchange API that ensures patient data is encrypted and secure while still allowing patients to share this data with designated physicians. This can be abstracted so that healthcare data is aggregated with each healthcare encounter ultimately coalescing into a comprehensive and universally interoperable medical record.