The Jury is Still Out: Blockchain in Healthcare

Zach Gardner Blockchain, Hyperledger, Opinion Leave a Comment

Attention: The following article was published over 4 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.


Blockchain has gotten the software world buzzing about its potential applications in different business areas. With the US spending 17.9% of its GDP on healthcare in 2017 per CMS, many companies are considering how to enter into a market that has such potential for growth as well as the potential to positively affect patient’s lives.

Keyhole Software stays ahead of the curve by investigating new trends in software so that when clients come to us asking for advice we can provide an informed opinion. We do not want our clients to be guinea pigs, and we help provide guidance so that the solution they choose is the best one regardless of the trends of the day.

Blockchain is something we feel could be a good fit for the right use case, which we’ve elaborated on in our Blockchain Case Study. It is, at the end of the day, just a tool, and should only be used when it is beneficial to do so. Healthcare is an incredibly complex industry, so it is important to understand what Blockchain is, what it is not, and what needs to be considered before using the technology.

The purpose of this blog post is to think through how Blockchain can be applied to healthcare software applications. This blog post does not dive into the technical implementation of Blockchain, only its application in healthcare. A technical deep dive into Blockchain can be found in our Blockchain White Paper.

Primary Disruption: An ETL to End All ETLs

Three things are guaranteed in life: death, taxes, and that there will be at least two ETL projects in development by a hospital’s IT staff at any given time. ETL (Extract, Transform, Load) is the most common way to move healthcare data from a source to its destination. The business model for entire companies rests upon building software to help make healthcare ETLs easier to develop and manage.

This is because healthcare data is stored where the patient interacts with the provider, such as an acute care facility (e.g. hospitals) or outpatient practice (e.g. urgent care). In HIPAA parlance, these are known as a Covered Entity.

The data doesn’t do much good residing with the Covered Entities. A patient may go to a hospital in another city or even another state. When they walk into an urgent care, they don’t want to fill out paperwork detailing their complete medical history, especially if they’ve done the same thing recently. Patients want their data to be shared with the healthcare providers they interact with, and they want their medical data to be private.

In order to provide that level of secure data sharing, healthcare companies rely upon ETLs to migrate the data from the source to an HIE (Health Information Exchange) edge.

The HIE allows for aggregation of data across different providers. So, in this case, a hospital or urgent care that participates in the HIE can access the patient’s data known to any of the other participants of the HIE.

There are even HIEs of HIEs, known as RHIOs (Regional Health Information Organization), that allow data to flow between HIEs. HIPAA BAAs (Business Associate Agreements) are needed to ensure every party treats a patient’s medical data in a way that is compliant with HIPAA, and consent needs to be recorded to ensure that patients allow their data to be shared in such a way. The benefit to patients and providers for participating in a RHIO — having access to your complete medical data wherever you go — can have a profound impact on patient care.

The primary drawback to this architecture is that each edge only knows about the data for the facility it is tied to. This data is already local if the patient visits a facility they’ve already been to. The power comes from being able to access data that was collected at other facilities in a performant manner. Seconds can mean a difference in the care for a patient, so needing to gather data from the edges of other facilities can be a nontrivial cost.

This is where the disruption can take place. ETLs, HIEs, and RHIOs would be unnecessary if there existed a Blockchain of medical records which any healthcare provider could access. The model of storing data at the edges gets turned on its head with the decentralized data model that Blockchain provides. The need still exists for BAAs to sign and consent to be collected. But the idea of being able to share medical records has already been proven through existing RHIOs.

So all it takes is one Blockchain to disrupt the market. All of the data would be inherently local as each edge has a copy of the entire data set, making data access fast and efficient.

Issue 1: Patient Identity

A problem that HIEs and RHIOs will have today to the end of time is how to effectively determine, and keep updated, a patient’s identity. Having access to data from every hospital in the US means nothing to a patient if there is no way to ensure that the records you’re pulling up truly belong to that patient.

Having their name, gender, and DOB won’t be enough. Plenty of people named James go by Jim, errors can happen when entering in DOB, and other oddities of demographic data will always exist. Even CMS is getting away from using SSNs.

Until there is a universally-unique identifier for every human that is known, consistent, and correct across all healthcare facilities, patient identity will always be an art rather than a science.

Current HIEs use patient identity heuristics to determine which medical records should be linked together to constitute a patient’s medical history. These are based on weighted demographics to establish soft links that can link or unlink as new demographic data comes in.

This same strategy will need to be used if medical records are put on a Blockchain. Some aspects to this linkage would be easier on a Blockchain, namely the entire linking and unlinking history would be available due to the immutability of the technology.

Other aspects of it will be harder, such as needing to compare demographics against all previous candidate demographics. Only time will tell how this issue plays out, though it will be easily one of the first and most formidable challenges facing participants of a healthcare Blockchain.

Issue 2: Immutability

The HIPAA Privacy rule ensures that only the patient or a legally authorized representative, can request that a medical record be changed. Acknowledging that mistakes in medical records happen, the traditional approach to issuing corrections to medical records is to create a new revision of the record in question with the corrections applied to it. A specific category of messages, such as the ADT A13 Cancel Discharge, exist to denote a change to a previous transactional event.

The same strategy would need to take place in a Blockchain of medical records. This may even be easier with a Blockchain as the data is naturally processed in reverse chronological order, with the most recent data being processed first.

The benefit provided by Blockchain’s inherent immutability poses challenges when the legal need arises to purge parts of the medical record. The EU’s GDPR allows for the ability of EU citizens to request certain medical records be removed. This may be possible in a relational database like Microsoft SQL Server or Oracle, but it goes against the fundamental principles of Blockchain.

The conflicting requirements posed by HIPAA and GDPR should be evaluated by a BAA’s legal department and HIPAA officer prior to joining a Blockchain.

Issue 3: Ransomware

Another issue that keeps the CIO of every hospital system awake at night is the potential that their systems will be compromised, and medical data will be encrypted and held for ransom by bad actors. This has the potential to be fatal in some cases if healthcare providers are unable to access medical data for patients in acute facilities.

One of the benefits commonly found on healthcare Blockchain articles is that ransomware will be a thing of the past once the storage of medical records becomes decentralized. It is by the nature of the Covered Entity that medical data is stored in individual data centers, so these articles assert that decentralizing the data makes it more difficult to hold hostage.

Upon closer examination, it is easy to see the opposite is true. Once an organization signs a BAA and is approved for access to a Blockchain containing medical records, a certificate is issued that allows the organization to implement their participation in the Blockchain. If that certificate is ever compromised, the bad actors have access to the data across the Blockchain.

Thankfully, there is already a pattern in implementations like Hyperledger which allow for certificates to be revoked, stopping the potential for damage in its tracks. This still places the organization of the compromised certificate at an exponentially higher degree of risk with all of the medical records that a bad actor has access to.

Just like the other issues discussed, there seems to be no silver bullet to mitigate this issue. A company’s legal counsel and HIPAA officer need to carefully understand the implications of joining a Blockchain. The Information Security team also plays a key role in ensuring that the right decision is made for the organization as well as for the patients it serves.

Issue 4: Content

The discussion prior to this point has centered around the Blockchain itself. Once those concerns are understood, the question then becomes: what actually goes in the Blockchain?

The answer of “medical records” may be two words, but can mean hundreds of different things. There is no one standard for what a medical record looks like. FHIR (Fast Healthcare Interoperability Resources) is an answer that is, pun intended, picking up steam. Though which version of FHIR should be used is open for debate. FHIR is also a constantly evolving standard and does not yet cover everything which could be considered a medical record.

HL7 3 has been deprecated in favor of FHIR and is not used by many healthcare providers. HL7 2 is potentially an option. It has been in the industry for such a long time that it is understood by pretty much any healthcare software application. It has, however, also been deprecated in favor of FHIR.

It is perhaps the wrong way to think of answering the question, trying to find a standard that will never change. It is possible that FHIR is the answer, but it would be up to the Covered Entities to translate any non-FHIR messages produced by their EMRs to FHIR when publishing the data to the Blockchain. This would require a significant investment by the software firms that produce the EMRs, and the cost/benefit may not be there for legacy applications.

This, like all of the other issues, has no one good answer but several possibly acceptable ones.


The jury is still out on how Blockchain can be used in healthcare. There is a major potential for disruption when it comes to allowing patients to access their medical records from any healthcare provider in the country.

The issues of patient identity (which medical records are yours?), immutability (can you amend or remove medical records?), ransomware (is the healthcare provider safe from attack?), and content (what format are your medical records in?) all play a part in considering if Blockchain is right for healthcare.

Blockchain as a whole is definitely going to play a major role in the future of managing data. It is just a question of which use cases make sense for how it can be effectively used.

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments