Creating a Healthcare Blockchain– Opportunities and Challenges.


Last week at Kare4U, we had a major milestone. We announced the launch of HealthPro, our mobile app on Blockchain (BC). Owing to the sensitive nature of Health-records, we are finalizing our tie-ups with major hospitals and insurance companies and on-board key stakeholders to the platform. There was a press release and since then there has been numerous queries and interest in knowing the next level of details. The current write-up addresses some key principles and design decisions that has been taken to leverage Blockchain at Kare4U. (Note: Since this article goes about discussing the practical implementation, there might be some un-intended plugs about the company ??). This write-up is also not a deep dive into BC concepts. List of useful links would be mentioned at the end should the reader be interested in knowing nitty-gritties.

Why Blockchain?

Blockchain in healthcare addresses the critical issue of health-record sharing in a transparent way which is difficult to manipulate by any solution provider. As it stands today, the healthcare standards like HIPPA are in place to address the security concerns. However, it's left to the system developers to adhere to the standards. The end user really doesn't have any idea as to how records are stored and shared with other parties interested. Countries in India have a compounding problem. Though vendors claim to be HIPPA compliant, in practice this is hardly used. Research companies struggle to get anonymized data for analysis. So, do other doctors in case of referrals. Compounding the issue is, we have seen close to 75% of hospitals and doctors use a hand-written form of prescription.

At the same time for a BC network to be successful, it must be profitable and have multiple DAOs participate proactively in the eco-system enhancement. As such people should be rewarded to create value on the platform and there should be participants willing to pay for the value.

Whereas in the current state, we are far-off from having pure DAO [1] companies, smart contracts have started to replace part of Organization's mundane activities.

Stakeholders and incentives

Following are some key stakeholders in the healthcare domain

Let’s understand each one the involved entities and their interests:


The key player in the BC network; they control what can be done with their health-record and by whom; They can receive incentives should some participant use their records based on the smart contract


Create Health Records for Customers; the doctors again could be receiving incentives should a record generate business down the line (like lab tests)


Apart from Doctors entering health records, selective In-Patient Information can be uploaded regarding Patients bill and other health information


Pick-up records from the BC network by paying a price and bid to get their tests done; Pay to the network

Insurance companies

Should the Patients have insurance, the relevant insurance companies do an instant approval of any IP procedure and at the same time can settle insurance claims with Hospitals automatically; Pay/receive to the network


Can bid to supply medicines to the Patients; Pay to the network

Healthcare Analytics companies

Get anonymized data from the system in blocks and pay for the information. This is shared across the Patients and Record creator (flexible as per the smart contract); Pay to the network

Current Design

The health-record that would be stored in the BC network can either be purely digital (should the doctors use our system to enter EHR) or in form of scanned images (for those who don't enter the EHR but rely on Pen and paper).

One thing that has come out clearly in our research is that Health records and other information cannot be stored in a BC network. As the size of Data increases, accessing them would be cost-prohibitive. Add to that, because of scanned images of the health-record and other PACS system, the idealistic on-chain solution is ruled out. As such our design relies on an off-chain and on-chain capabilities. Specific care has been taken to ensure that the off-chain information [2] is stored in an encrypted format which can only be decrypted by Private key stored in the BC network.

Following is a sample run-down of a typical use case of record creation and future edits:

Step 1: User is created in the BC network with his/her public/private key for Health Record (different than the Private key of the network)

Step 2: Record created by Doctor; The record is hashed and stored in the BC. At the same time, using the Public key the record is encrypted and stored in Kare4U system against the user. Even if the record is compromised at the off-chain network, the user will get a garbled set of byte arrays. One important thing to note is the creation of blocks. The details of creating and mining blocks will be discussed in a future post. We are experimenting with Proof of Stake and Proof of Authority [3] for our use case currently. (If readers have any opinion, they may please leave a comment)

Step 3: For any record to be accessed, there must be a smart contract governing the access mechanism. Once the conditions of the smart contract are met it automatically executes without the need of any manual intervention. Here are some examples of Smart Contracts in the system:

Only if the owner of the record gives consent, then only another doctor can see the health record

If the patient is rewarded with certain points, the recommended tests would be visible to the Labs DAOs; At the same time the Labs will have a smart contract to bid for record access amounting to a maximum of say 20 points

The Pharma companies can view the medication requirement if they pay to the BC system like the Labs in the above scenario

Step 4: Once the smart contract is triggered, the record is accessed using the private key of the health-record. The authenticity of the document is again checked by comparing the hashes of the document stored and the hash stored in the BC network.

Moving to IPFS

Keen readers might argue that having a centralized storage for health records goes against the principle of an Ideal BC network. As of the current writing, we haven't found a better way. We are actively pursuing IPFS (inter planetary file system) which is similar to BitTorrent. The records are stored

in an encrypted manner in individual machines in parts. It's like a Merkle tree [4] and very interestingly they are not accessed by any http protocol. It's identified purely by file name in the BC network. Apart from being distributed, it's almost always available and consumes much less bandwidth since it's served from the nearest location.

Conclusion and Challenges

As the reader can probably imagine, the possibilities are limitless, and the value of the network significantly increases with each addition of participants. We are in the process of tying up with Hospitals, clinics and Insurance companies to start with. With more and more health records and stakeholders into the system, the value of the network increases exponentially. Having said that, on-boarding the initial set of customers and healthcare entities is no mean task. It's a gradual process until the tipping point is arrived. The on-boarded stakeholders have given a good thumbs-up and we see a massive opportunity in streamlining healthcare domain on Blockchain.




3. https://cointelegraph.com/news/why-blockchain-needs-proof-of-authority-instead-of-proof-of-stake

4. https://en.wikipedia.org/wiki/Merkle_tree

5. https://hackernoon.com/a-beginners-guide-to-ipfs-20673fedd3f