The Story of Medblocks

It is not uncommon for a startup to build a product that focuses more on the solution rather than the problem. About five years ago, I made a prototype application that stores medical records on the blockchain and called it Medblocks. It was aimed at solving interoperability challenges with sensitive healthcare data. The title of my introductory blog post was: Introducing MedBlocks — Storing Medical Records Securely on the Interplanetary File System using Blockchain technology.

You can see immediately, how I was focused on the terms like “Blockchain” and “Interplanetary File System”. However, at that time, it did work to my advantage, since people were ready to shell out funding for anything to do with “blockchain technology”. And somehow, for a barely working prototype with no business model in mind, I got an offer of $1 million (USD) from a company that was planning on launching an ICO (Initial Coin Offering) to base their product on the prototype.

I refused.

The reason was I didn’t quite understand what I had built, and how we were going to really sell this.

Looking back, it looks like the right decision. I’ve now had enough time to study the market and its needs and my views have changed a lot. And that’s one of the perks of not raising money too early. You are not pressured into delivering a product prematurely. Instead, you have time to think more about the problem and you can switch between ideas.

So let me break down the core ideas I have discovered on my journey into the healthcare data space into the why, what and how.

The Why

I’ve always been interested in computers. I learnt a lot from free online courses like Coursera and Udacity about programming and data science. I had already taken part in a few Kaggle competitions, only to realise that other competitors were way out of my league.

When it was time for me to choose a college, I didn’t feel like going to any. Something about going to an Engineering college and listening to an hour-long lecture on data structures and algorithms didn’t quite capture my imagination on what I wanted to do with my time. I would rather just sit at home and take more online courses and practice my python skills in Kaggle. My parents were both doctors, and they “suggested” that I join a college. So I ended up joining a medical college.

Upon studying the medical subjects in college, I realised how most of what we are being taught to become doctors, are just facts we know about what works and what doesn’t. And they were a lot of facts! Of course, experience comes from dealing with actual patients and looking at and observing diseases, but the difference between a specialty doctor and the general physician is usually the depth of knowledge they know about a certain topic.

I soon started working on machine learning algorithms for medical imaging. Wrote papers on if neural networks can help us find new patterns in diseases given a huge corpus of data. It was interesting, but then the real problem hit me.

In a country like India, there are not enough doctors to treat everyone. Most doctors need to specialize to make a decent living. And what we end up with is a system that is top heavy with too many specialty doctors and not enough doctors at the grassroots level. Most people suffer from common conditions that can be solved by a general practitioner with simple medication. But our system is not designed to handle this. We have very few really good doctors competing in cities and almost no one to cover 70% of the rural population. And not surprisingly, they resort to traditional medicine, homoeopathy and Ayurveda. Not that there’s anything wrong with it, but for many acute conditions, modern medicine works wonders. And for age-related conditions like cataract that causes most blindness worldwide, there is no treatment available from alternative medicine.

With this motivation, I started my work on trying to automate medical diagnosis for very simple conditions. Something like a symptom checker. It soon got overwhelming. It will not be easy to make a heuristic system that can deal with even common conditions. Because the breadth of the symptoms is huge. That brought me to the next logical conclusion: Machine learning on healthcare data.

And that brought me to the chaotic realm of healthcare data systems. Every single hospital that used electronic medical records, built their own version of it. They were tied down by laws not to share this data, but this data was barely being protected. Any student in my college can access the medical record of any patient including other students with the click of a button on a hospital computer. Yet, when you want to obtain this data to do some sort of data mining, you have to go through innumerable steps of ethical clearance and approval that can take months.

Healthcare data is very different from, for example, the data that internet companies generate. First, every single point of healthcare data generated for a patient costs money. A doctor’s opinion: ₹200. An X-ray: ₹800. An MRI: ₹8,000. The patient pays for each data point that is collected. Compare this to the data collected from your mouse movements by a company like Google or Facebook — the user pays nothing. Second, healthcare data is rich in information. Every single data point is representative of a disease and a patient. It is very easy to profile and learn from disease patterns given a diagnosis. And third, the payoff for utilizing data-driven decisions in healthcare is immense. It could mean a better outcome and a longer life span for a person.

While companies like Google collect and store details about your every mouse movement, to increase their advertisement revenue, hospitals that can save lives by utilizing data, mostly just write this down on paper in illegible handwriting.

Think about this. While companies like Google collect and store details about your every mouse movement, to increase their advertisement revenue, hospitals that can save lives by utilizing data, mostly just write this down on paper in illegible handwriting. And every time a patient goes to another hospital, most of the data collected about them from the previous one is thrown out except for the discharge summary, which usually misses a lot of vital information and is written by an overworked intern in a hurry. And the patient now has to pay for all this data to be collected all over again.

So it makes sense for a system where healthcare data can be reused. And it should belong to the patient because they pay for it, and are the common point. Apart from what is mentioned above, such a system can lead to new and interesting possibilities. Insurance claims can be settled in seconds, and not days. The patient can learn more about their health condition and be more proactive about its management. They can sometimes even spot errors in the doctor’s notes.

They can have a personalized app looking over their shoulder and suggesting to them what they can do with the data that it has received: Drug prescription? Get it delivered to your doorsteps on time by an online service every month. Another drug prescription? This drug looks unnecessarily costly, try out the generic version instead. Another one? Alert: This drug has side effects with your other drug that you’re already taking! Spectacle prescriptions? Get it delivered!

It is not just the patients getting the benefits. For doctors, it means much less paperwork for insurances. They can train decision support systems and senior doctors can set alerts for junior doctors and nurses in their set up when certain conditions are met. For an extreme example, verify that the patient posted for an emergency C-section is female and alert if that’s not the case!

It will be even more useful for overworked doctors to have a system that verifies if what they are doing is in line with legal regulations and the state-of-the-art for that particular condition and patient and suggests them the next best course of action. And this algorithm is trained on data from the outcome of millions of other patients, something that one doctor could never see in a lifetime.

The What

To make health care data truly interoperable there are three distinct stages required.

Stage 1: Format

We don’t want one hospital passing out handwritten notes and another emailing word documents with prescriptions (Yes. This really happens). Instead, we want everyone to use the same format to read and write medical data.

Stage 2: Terminology

The same medical concept can be represented by two doctors in different ways. Even the essentially same diagnosis is called different things — a patient may have COPD (Chronic Obstructive Pulmonary Disease) but also Emphysema (a type of COPD). Similarly, the generic drug Paracetamol can be prescribed as Dolo or Crocin.

It should be easily inferable that Emphysema is a type of COPD which is a type of lung disease and that Dolo is a prescription of Paracetamol, the chemical composition of which is N-acetyl-para-aminophenol.

Stage 3: Consent and Transmission

Institutions should use the same form of communication and access control to transmit medical information to requesting third parties. This part needs to involve the consent of the patient at its core, and the patient should be the owner of the data.

The How

Luckily, the first two stages of interoperability have a really good solution that is about 10 years old. Refer to this blog post on that for more details.

Stage 1

openEHR for clinical data, FHIR for demographics, and logistical data. Still very new and not widely adopted, but is a good starting point. openEHR helps model the complex data, while FHIR represents data as simple resources and stores it in a RESTful server, and transmits it through its RESTful interface. Hospitals should be equipped with electronic health record systems speaking openEHR and FHIR.

Stage 2

SNOMED and LOINC for terminology. Pretty much any condition or medication can be represented by these two together. For those that cannot be, you can create new terms and get the approval of the respective committees relatively easily. Now the real problem is getting practitioners and nurses to use it. Providing a drop-down menu for a list of conditions is not exactly appealing to a busy doctor. So something like a voice assistant system that can convert speech to the appropriate terminology would be required for widespread adoption. Considering the cost of healthcare data, it is in the realm of possibility to assign an operator sitting at a call center to a doctor to transcribe medical notes.

Stage 3

This is the part for which the original Medblocks article provided one solution for using blockchain technology and encryption. That is ONE solution, but there are others. The main problem with trying to encrypt everything and putting it in one ledger is that the nature of healthcare data is not distributed. Hospitals, Labs, and Insurance companies generate a lot of this data and would have a copy on their server anyway. The SMART framework is working on making FHIR servers communicate directly with 3rd party applications.

It uses an open standard technology like OAuth2 to request permission of the patient or the doctor, then allows the application access to the data. This is the same technology behind the “Sign in with Google/Facebook” button. The same mechanism can be extended to also include openEHR and other APIs.

Conclusion

The solution we are building at Medblocks today may not be the right set of solutions. We can only figure out if they are right in retrospect. But they are potential solutions. And it doesn’t matter if they are right. Because I am sure that to create a better healthcare system the “why” will remain the same. So even if the “what” and “how” keep changing I am confident that one day we will figure this out.