The healthcare industry has long been touted as one of the most ripe industries to be disrupted by the advent of blockchain technology. Historically, the digitization of health records has long been a priority for the governments and private sector bodies of many countries. However, this digitiza- tion progressed slower than expected or did not occur at all. One of the main reasons for this is the lack of a secure and standardized medium for the exchange of health data. Just like personal financial data, personal health data is very sensitive information (if not even more sensitive than financial information). Nonetheless, there are far fewer options to share ones medical data than are there for financial data. Whereas financial data is always relayed and handled by secure payment gateways using privacy-protecting protocols, there is no standardized and interoperable solution for healthcare.
Furthermore, just replicating the kinds of models used in the financial services industry is not sufficient for the healthcare industry. The sharing of healthcare data requires its own standards for privacy, security, and data integrity. While a system meeting these standards could be built using traditional technology, the availability of blockchain technology would render this exercise wasteful. Blockchains are a technology built for private and secure sharing of control over data. We propose a system to digitize electronic medical records (EMRs) in India using blockchain technology.
2 Current Electronic Health Record Scenario
The current health care systems throughout the world face a vexing problem which is how to share medical data with more stakeholders for more purposes, all while ensuring data integrity and pro- tecting patient privacy.
For instance, in the first week of December 2016, it was reported that the electronic medical records (EMR) of over 35,000 patients held by a Maharashtra-based pathology lab were leaked, pointing to the lack of availability of adequate safeguards for protecting such sensitive information. Such instances, however, are not uncommon. Globally, the medical industry is extremely susceptible to data breaches. The Office of Civil Rights under the US Department of Health and Human Services estimated that in 2015 alone, over 100 million records were breached, with most cases being linked to IT crimes and hacking.
Hospitals in India are increasingly using EMRs as the preferred method of storing patient informa- tion. In fact, the rules of Clinical Establishments (Registration and Regulation) Act 2010, notified
1
on May 23, 2012, mandate the maintenance and provision of EMR or EHR However, there are three main issues with EMRs today. These issues are best understood through user stories – in order to illustrate the issues, the following fictional characters will be used:
The three main issues with EMRs are as follows:
2.1 Insecure communications channels:
Imagine that Patient Sam needs an electronic copy of his blood test reports from a pathology lab. The lab technician sends Patient Sam the reports as a PDF attachment to his email account. This approach of sharing EMRs via email, although fairly common, is hugely problematic. Not only can many email servers read your email contents, but third-party browser and inbox extensions can do so too. For instance, what if Patient Sams computer subscribes to some third party applications which can read and manage his email? It is unlikely that anybody would be OK with unauthorized third parties gaining access to personal medical data.
2.2 Weak consent controls:
To build upon the example above, imagine that when the pathology lab technician sends Sam his report via email, he also copies Doctor A on the email. While the patient may actually desire his reports to be conveniently shared with his doctor, he still lacks adequate consent control in this situation. The lab technician is in control of Sams data and can easily and freely share it if he so wishes. Even if the lab technician is not acting maliciously, the lack of consent controls can still be detrimental to Sam. For instance, imagine that Sam was a patient of Doctor A up until recently and now sees Doctor B. Imagine that the lab technician does not know this and is in the habit of copying Doctor A on all of Sams EMRs. In this case, the technician would unknowingly share the EMR with somebody the patient has not authorized.
2.3 Absence of data integrity protocols:
The lack of data integrity for medical reports is a problem which can have serious consequences for both patient care and industry-wide fraud and malpractice. Suppose that Sam is applying for medical insurance and he needs to prove that his blood reports have been above average over a period of time. The original blood reports lie with the pathology lab, who exercise complete control over this data. If Sam was to forward his EMRs to the health insurer, he could easily doctor the reports to his advantage. Similarly, if the insurer was to cross check this with the lab, the reports could be changed on the labs end as well (either by design or by accident). While this example highlights the potential to abuse the digital nature of EMRs for fraudulent financial purposes, the other misuses of EMRs can be far worse. Fortunately, there is a simple way to prevent EMRs from being tampered or altered in any unauthorized way.
3 Alternative Blockchain Based System
In order to create a system that would provide an alternative to todays suboptimal EMR manage- ment softwares, it is important to create something with the following properties:
• Scalable and easily adoptable: It is paramount that the solution should be easily accessible to large swathes of the population.
2
• Interoperable and extensible: The solution should be easy to introduce for patients, hospitals, doctors, labs, and any other kind of healthcare providers.
• Consent-driven: The sharing of EMRs should only occur with the explicit consent of the patient.
• Secure: As far as possible, only the patient should be able to view their own medical data. The data should be resistant to tampering and forgery.
Given these criteria, it makes complete sense to build any prospective EMR system on top of existing solutions like Aadhaar and DigiLocker. The UIDAI already provides a unique digital ID service to 99% of the adult population; similarly, DigiLocker already provides a secure file system accessible to both individuals and businesses.
Nonetheless, for the purposes of this report, we will consider our solution in light of a generic ID system and a generic file server.
4 Network Configuration
A design for a blockchain-secured EMR management system could have a network configuration similar to the one depicted in this diagram:
The three components would be:
1. A user management system built with public key infrastructure (PKI): PKI is necessary to enable encryption snd sharing of sensitive data. The user management solution should have
3
sound key management and password/privatekey failover and recovery protocols; the solution should also ideally map well to real world identities.
2. A secure file system to store documents: A secure file system is required to be associated with each user account so that the EMRs have a place they can be stored and interacted with.
3. A public blockchain network: A public blockchain network is integral to the mission of en- suring secure sharing of and data integrity of EMRs. There needs to be one source of truth which records in detail all of the health data being generated and exchanged throughout the system. This blockchain should be made open to the public to promote trust in the system and increase network resilience/security – this is possible as there is no sensitive or large data being shared on the blockchain. In our proposal, we refer to this blockchain as MediChain.
For each of the components, here are the prerequisites that would be required:
1. ID system: A central ID issuing authority would be needed to store all of the mappings of public keys to real world identities. This database should be secure to protect privacy.
2. File system: The interface governing the ID system and attached file system should be lightweight, mobile-friendly, and extensible for third-party providers (such as conversion APIs or data forwarding schemes). The file system should also have the capacity to stream data.
3. Medichain: The entire Medichain network can be run on a handful of commodity hardware machines with low computational intensity. The chain should come with a block explorer interface that can be used to audit and traverse the transactions. Furthermore, the chain would have to be able to converse with the ID/file system interface.
4.1 Process flows and walkthroughs
In the proposed Medichain system, we focus on two main use cases:
1.
2.
4.1.1
Generation of EMRs: This is the process that occurs when health records and first generated by the healthcare provider (abbreviated to HP). The HP can be anything from a doctor, hospital, or lab.
Secure sharing of EMRs: This is the process by which patients can share their medical records with others for advice and consultation. In our example we focus upon sharing of EMRs with HPs.
The process flows for the operations are shown below:
Generation of EMRs
The steps for the generation of EMRs are as follows:
1. The healthcare provider generates an EMR using his existing technology. This could be a PDF, a Word document, an X-Ray image, or any other kind of digital file.
2. The HP logs into the ID/file portal.
3. Through the portal, the HP uploads the EMR to a custom API
4
4. The API takes the EMR and hashes it, thereby creating a tamper-evident fingerprint of the digital file.
5. This hash of the EMR is stored on the public medichain blockchain along with the following information: public key of the HP generating the document, public key of the recipient, and a time stamp.
6. Immediately after storing the hash of the EMR on the Medichain, the custom API will encrypt the EMR. In order to securely encrypt the file, a random session key will first be generated. This session key will then be used to encrypt the document. Next, the session key will be encrypted with the public key of the recipient user.
7. Theencrypteddocumentwillbestoredintheusersfilesystemtobedecryptedandviewed/saved whenever desired.
8. The user can access their EMR at their leisure through the file system. When the EMR is decrypted, it is hashed and compared with the Medichain hash to flag any discrepancies.
9. Observer nodes connected to Medichain can view the transactions on Medichain which detail the creation of EMRs. If there is a dispute over the authenticity of an EMR, recourse can always be made to the hash stored on Medichain.
10. The healthcare providers must ensure to destroy/delete their patients EMRs stored on their own machines; this can be done in accordance with the prevailing laws to protect customer privacy.
4.1.2 Secure sharing of EMRs
The steps for the sharing of EMRs are as follows:
1. The user logs into their file portal interface and selects the document they wish to share. The user also inputs the public key of the person they wish to share the document with.
5
5
2.
3. 4.
5.
6.
7.
8.
The document is replicated in the file system. A new session key is generated and used to encrypt the EMR. The session key is then encrypted with the public key of the intended recipient.
The original EMR is also hashed to preserve data integrity.
The file portal interface will publish a transaction onto the Medichain ledger. This transaction will contain the following: the public key of the sender, the recipient, a hash of the EMR being shared, terms for the sharing of the EMR (eg. duration, number of viewings etc.), and a timestamp.
The Medichain/file-system will be built in such a way as to listen for incoming events. For instance, if the Medichain recognizes that user X is the intended recipient of an EMR, it generates a notification informing user X to check his file portal interface.
Using his private key, the intended recipient decrypts the EMR and consumes it. The EMR can be shared or consumed in many ways: for example, it can be sent directly as an encrypted file to the file system of the recipient or it can be streamed for a limited period of time from the sender to the recipient.
The healthcare provider or intended recipient can access the documents when they wish. At the time that the document is decrypted and accessed, it can be hashed and verified against the Medichain hash to ensure that there are no discrepancies in the data.
Observer nodes can vet and track all transactions on the Medichain network
Benefits of Medichain
At the outset of this document, we argued that there were three fundamental problems with elec- tronic medical records today: insecure communications channels, weak consent controls, and a lack
6
of data integrity enforcement.
In the ensuing section, we evaluate the proposed Medichain solution according to these three criteria:
5.1 Secure communications channels:
In the proposed system, EMRs are only communicated in encrypted format. The double- layer asymmetric-encryption proposed in this system will help prevent EMRs from falling into the wrong hands. For additional security, the pipes through which the EMRs are uploaded and transported can be audited or open-sourced to ensure that they are secure.
5.2 Strong consent controls:
In the proposed system, EMRs can only be shared after publishing public intent to share a particular document with a particular recipient. The recipients access to the document can be controlled by the sender and limited according to duration of sharing, number of views, etc. It must be conceded that this system can still be circumvented by malicious actors wishing to break the law. For example, healthcare providers can always duplicate the EMR before uploading it to the users file system; similarly, malicious actors can screenshot, download or visually copy and share EMRs illicit. Despite these anomalies, the new Medichain system still represents an improvement over the previous paradigm of sharing EMRs via email and similar insecure channels.
For increased security, it could be mandated that anybody found to be in possession/ awareness of another persons health records be punished unless they are able to prove via Medichain that the sender has authorized them to access their EMRs.
5.3 Data integrity protocols:
In the proposed system, an EMR is hashed and recorded on the blockchain anytime it is generated or shared. This creates a public, immutable time capsule to view and cross- check the integrity of medical records. In the previous system, the only way to investigate forged medical documents would be to track down the issuing healthcare provider and forensically examine all their systems. In the new system, even the tiniest alteration in a medical document will be immediately detectable in an investigation.
When evaluated against these criteria, Medichain offers substantial improvements over todays med- ical record infrastructure. As time passes, the benefits of an extensible, blockchain-based system will only increase.
For instance, consider a future in which a woman can send her medical records to third party providers who will digitally transcribe a scanned copy of her written doctors note. This digital transcription can be approved or attested by the patient, anonymized by removing her personal information, and shared across a wide network.
By sharing this sort of anonymised medical data with researchers, insurers, hospitals, or others, patients may be able to monetize their own data while simultaneously allowing scientists to benefit from a larger data set of authenticated information.
This is just one of the possibilities for extending the Medichain system to add further utility; other
7
such possibilities are manifold and out of the scope of this document.