Although I am a relatively healthy person. Few times a year, I go to see my doctor for my annual physical check required by my employer. They take all my vitals, they have my multiple medical history surveys, insurance information, records of my illness, any medicine prescribed, my blood types, my medical procedures, and what not.
Being a software engineer and a cyber security professional, every time I visit the clinic or doctor’s office, I watch the nurse and doctors key in those information in the relatively old computers. I kind of glance at the unimpressive front end of the software they are using (for years) and start pondering what the backend of those systems might look like.
I always have more questions than answers.
- How is this information stored in the database?
- Is there even a database?
- If there is one, is the data properly encrypted?
- Who has access to view my medical records?
- How many people have viewed my records?
- Have they sold my health records?
- Have they transmitted my health records to other doctors, institutions and government agencies with or without my permission?
- Is my data a part of someone else’s research?
- Was my health data part of some hacks and leaked on the web including dark web?
I have answers to none. Because there is no transparency. Although it’s my data, my private data, someone owns it and they decide what to do with it, sometimes under the legal provisions, sometimes under gray areas and many times they sell it (in the name of anonymized metadata) and make money out of a leaving breathing product, me.
Doo I want to control my data? Of course I do. But do I or hospitals have tools and processes currently to allow patients to take control of their own data? Definitely not.
This is a big problem for millions of people. Their personal health record is not transparently stored and transmitted and there is always a chance that data can be stolen and misused.
Let’s Define a Problem
Storage and Usage of Personal Medical records is non-transparent, potentially insecure and is prone to misuse and hack. Before we delve into the solution, let’s list out some of the problems or opportunities we saw earlier in more or less of a requirements format for easy understanding.
- User needs to own the data. So the data needs to be stored in a decentralized mechanism.
- The system needs to support data storage in multiple formats. These could be PDFs, Images, Excel Sheets, XMLs, JSONs and more.
- The stored data needs to be safe and secure.
- User needs to control the access to the data. They need to be the owner and operator of the data.
- User needs to make sure that no authorized person can access it.
- User needs to have an immutable record of who accessed the data historically.
- User needs the ability to allow storage of new data to the data store.
How could we solve it?
Based on this requirements, there are a few areas that require a solution –
- Decentralized Storage of documents in an encrypted format
- Establishment of identity verification system
- Authorization of the access
The decentralization today is not a problem, there are a lot of blockchains providing data storage in the blockchain. The data is immutable, can be owned by a wallet. However, we need to ensure the data is protected. We need to make sure the blockchain solution, especially the encryption portion of it is un-hackable, non-irreversible without a key. So either ONINO can partner with any third party file storage blockchain or they can create one themselves. For a long term non-constrained solution creating your own Blockchain is advantageous.
What about the identity portion? Well today there are a lot of digital identity verification systems & services and are used by banks and other institutions all the time for KYC (Know Your Customer) and AML (Anti Money Laundering). However the problem with them is they are heavily centralized. That causes an identity verification system clunky, prone to single point of failure and unreliable in addition to the chances that those service might stop providing data to you, might block you or they might themselves be censored causing the identity on blockchain based on off-chain data and service unreliable.
The identification and authorization of the correct person to connect, access and forward the data is necessary for various operations. E.g. The patient might want to forward a MRI record to a new doctor or at least allow the doctor to access it for certain duration and remove the access after the doctor has looked at the MRI. Here, we need to make sure the user is the right person to own the data. So we need to identify the real owner of the data. In real world, there are identification cards such as Driver’s license, Passport, State issue Documents, Birth Certificates etc. that proves the person is who he is. Of course, there will be third parties involved who will look at the document and try to match the photo with the real in-person face of a person who is trying to gain the access.
So a solution would be to establish an identity verification and storage system on chain. Of course the real time data needs to come from the real world. So a blockchain oracle could be created in between which would then obtain the data from multiple sources and decentralize the data. However once verified, the identification data could live in a secure and encrypted blockchain.
How about authorization? The patients could authorize a doctor or a hospital. We can assume not only doctors, even the hospitals can have their own identifications stored in this blockchain. So providers of a service could request access to certain medical records and the owner of the wallet holding those records could authorize the doctor or hospital to view their data. And they can exactly choose what assets or documents to provide access to. It would even be helpful if a system could be built where these authorizations would time out e.g. after 24 hours. And if the doctors need the access, patient would have to provide them again.
Problems caused by our Solution
I love it when we get into different problem, when we are trying to solve another. In our solution above, we are expecting the patient to own and control the digital identity.
What happens if a patient is incapacitated and cannot operate his wallet?
But what if the patient is incapacitated? An unconscious person won’t be able to sign into the wallet and provide authorization to a doctor. So the patient needs someone other than him to be custodial authorizer for him. Could be their friends, could be their family, whoever the patient chooses and authorizes in advance could operate on his wallet. Of course, there lies more responsibility on us when we task ourselves with owning our own data. So we do need to timely verify the add-on users are still valid. Maybe you don’t want your Ex-Wife to have access to your medical records. Again problems as such can be solved if though early in design of the application.
Another scenario is what if the patient is a child, infant, new born? They can’t operate create and operate on their own data. They are too little. So a custodial access is important. But at the same time, when the child grows and can handle his own wallet, he should be able to kick out his parents from operating as his custodial person.
Lets talk about the potential users
So if we were to develop a decentralized application as such, it is important to think about the users. In this particular use case of Medical health records on secure blockchain, I see a co-operation between the following parties.
- The patient:
- He is the first and foremost important party because he is going to be the owner, operator and controller of his data. He is going to decide what to keep on blockchain, who to authorize, for ow long etc.
- The Doctors, Nurses and other Health professionals:
These users need to do two major operations.
- Push new medical records to a blockchain. The solution could be trustless, where they can upload any number of records or trust based where the patient needs to approve the records being associated with his identity on the chain.
- Request and retrieve patient information from the blockchain for serving the patient well, looking into their medical history, prescription history etc.
- Hospitals and Clinics:
- Since the health professionals are usually associated with hospitals and clinics and they use the front ends provided by these institutes, it is very important to bring on board these institutes. In fact I recommend to broaden the definition of Digital Identity from applying to just people to Internet of Things.
Role ONINO project could play
The vision of ONINO is amazingly simple yet powerful. Visit their website for understanding their vision or read this 40 something page Litepaper. The dual layer solution where the sensitive data is protected in a separate blockchain and less sensitive data is protected in another, there is the isolation of data. This prevents potential hacks, intrusions, and leaks of personal privacy. It also makes the solution tamper proof. No one can insert the Medical Record without user permission and Nobody can edit what is already added.
So apparently ONINO could provide the secure document storage blockchain and then provide the digital identity and authorization process which could be integrated to wide variety of wallets and websites. They could also be the blockchain oracles aggregating and providing KYC information and other identification in the Decentralized form.
They could also develop the concept of more than one user having access to digital identification wallet as an added user but authorized by the primary user. This helps solve the problems of incapacitated user or Children who are not familiar with using their own wallet let alone provide identification and authorization.
The use case obviously needs a handshake between a lot of partners specially the hospital, clinics, medical institutes and potentially other software development companies working with those institutes (for developing front ends), but ONINO could play a major role in establishing the product and guidelines around integrating with it.
How do we make money, again?
So does ONINO as an organization make money from implementing this use case? There are multiple avenues for monetization.
- Hospitals would be required to pay gas fees / transaction fees to upload the document.
- Patient/Hospitals could be charged for storage fee.
- Patient needs to pay gas fees / transaction fees to approve the upload and associate with his account.
- Patient needs to pay gas fee / transaction fee for accessing and allowing doctors to view their records.
- Insurance could be introduced in insuring the data stored in blockchain is kept secure. So the patient might have to pay for the nominal insurance fee (Added feature)
- Custodial accounts would need to pay fee to add/remove/authorize other users.
Apparently money earned is directly proportional to the number of transaction. Making a killer product that is mass adopted and main stream can easily increase the number of transaction, just ensuring a proper monetization.
Why would centralized institutions adopt this?
Hospitals, Clinics and other Health institutes are the major key players in making this use case adoption a success. They are the creators and updaters of those medical records. Why would they want to go this route of blockchain to adopt a solution rather than using a centralized solution?
The major incentive is the security. Every year, thousands of medical records are stolen, misused, accidentally deleted, lost, hacked and sold on dark web. This is a bigger headache for the institutes. In many cases it involves lawsuits and fines from the government or other legal bodies.
Blockchain based solution would provide a security, auto backup because of decentralized nature, scalability and more over transparency. This will offload their work of managing those documents by simply delegating to a secure decentralized solution.
This article was written and submitted as a use case to ONINO project. I am not directly affiliated to the ONINO project other than being a potential investor. If you would like to learn more about the project, please use the following contacts: