Over the past decade, hospitals and doctors have successfully migrated from paper- to electronic-based record-keeping. Over the next decade, I expect their focus will be on the exploration of the new capabilities that ubiquitous electronic patient data makes possible.

One of the most exciting new opportunities this exploration suggests is the ability to put patients in control of their health records and successfully create a high-quality personal health record (PHR) where past attempts have failed.

Enter blockchain technology. Businesses in every industry are exploring ways this technology—a distributed database that maintains a secured, continuously growing list of records, called “blocks”—can help transform their business.

Might this promising new innovation be the fabled missing piece that the healthcare industry has long sought in its effort to create a widely adopted PHR?

Maybe.

A Practical First Step

It’s naïve to believe that the healthcare industry will discard today’s solutions and re-implement its record-keeping systems on a blockchain architecture. Healthcare is a risk-averse industry, fraught with a great deal of inertia and investment in the status quo; it’s unlikely the industry will accept the time and cost required to shift to a new and unproven technology. For one thing, to achieve high rates of EHR adoption, the Centres for Medicare & Medicaid Services (CMS) has spent over $30 billion since 2011, which means that a new approach to record-keeping will need to respect this investment and work alongside the existing EHR infrastructure, not supplant it. Further, the institutions that are maintaining healthcare data in centralised systems perceive patient data as a valuable asset, and changing their way of thinking will be difficult.

So, while a blockchain-based solution may be an option in the long-term, the near-term needs a bridge solution. The following proposal describes the creation of a new facility for storing clinical data that is based on blockchain technology, yet continues to use today’s EHR systems—and other systems—to capture and store patient data. This approach benefits from many of the advantages of the blockchain solution while leveraging current healthcare IT investments (i.e., to create a blockchain-based PHR, existing standards and policies provide the framework for copying data from traditional systems into the new, blockchain-based system).

My proposed solution begins with today’s health IT systems (primarily EHRs), but may also include laboratory information systems, radiology systems, payer databases, medical devices, and consumer devices. These systems will continue to operate as they do today, storing data in their proprietary databases. But in addition to storing their own copy of the data, each system will also transmit a copy to the blockchain-based PHR.

But keep in mind that all EHR systems that are Meaningful Use compliant must provide the ability for patients to view, download, and transmit their health information in a human-readable format as well as a machine-readable, XML format: in this case, C-CDA. By applying a style sheet to the C-CDA document, it becomes an HTML file that can be read by a human using a web browser. Many health systems satisfy this view/download/transmit criterion by making C-CDA documents available to the patient on a patient portal. (And, in fact, some EHR systems also offer other methods of transmission that do not require a patient portal.) From there, the patient can download or forward the document to the destination of their choice.

The Options

Before reviewing the options for connecting an EHR’s view/download/transmit function to a blockchain-based PHR, it might be helpful to review a description of the architecture and data flow for the EHR with a built-in blockchain client, which will relate directly to Option 1:

  1. Upon completing an encounter, the EHR saves data locally, prepares a C-CDA version of the encounter data, and transfers it to the built-in blockchain client. 
  2. The built-in blockchain client encrypts the document using the patient’s public key and connects to the blockchain to transmit the document. 
  3. The C-CDA document, along with metadata about the document’s source and subject, is committed as a transaction to the blockchain. The nodes of the blockchain network use a consensus algorithm to determine the transaction’s validity, and when a quorum of nodes agrees to the change, it is permanently committed to the public ledger.
  4. The blockchain stores all documents for all patients.
  5. The PHR client connects to the blockchain and downloads all documents for the patient. The documents are decrypted using the patient’s private key.
  6. The patient views the documents and shares them with other providers. 

Next, with that architecture/data-flow description in mind, consider this first option for connecting an EHR’s view/download/transmit function to a blockchain-based PHR.

OPTION 1: EHR vendors implement a blockchain client within their EHR softwarethat communicates health information directly and automatically to the blockchain-based PHR (per the architecture/data-flow description above). This would be the preferred option, but it requires effort and cooperation on the part of EHR vendors and is unlikely to occur without regulation or incentives.

After that, consider these additional options:

OPTION 2: EHR vendors use existing protocols—such as REST, SOAP, or direct messaging—to send health information to a blockchain-based PHR, which is equipped to receive data according to these standards. This would mean that the blockchain-based PHR would need to be (1) able to handle these communication protocols and (2) configured to receive documents from various sources. Such functionality is somewhat heavyweight for a blockchain-based system, which is conceived as a simple electronic transaction ledger.

OPTION 3: Patients continue to receive their health information through existing patient portals and then forward or upload the documents to the blockchain-based PHR. This “lowest common denominator” method will work in all cases, but it relies on the extra, manual step of the patient acting as an intermediary. In a worst-case scenario, this will result in incomplete records if the patient does not complete that manual step.

This last option is the simplest scenario and the easiest to implement. The feasibility of the other two options depends on the willingness of EHR vendors. For systems other than EHRs, the situation is somewhat less clear. Conceptually, there are ways to split the stream of data coming out of these systems and send a copy to the blockchain-based PHR. However, the economics and regulatory issues involved may complicate and delay the implementation of those efforts.

Finally, and for simplicity’s sake, please note that the architecture/data-flow description above imagines the PHR as storing data in a blockchain. However, it should be noted that a real-world implementation would not actually store patient data in quite that manner.

One reason is that blockchain implementations are optimised for small transactions, not the large healthcare documents a PHR needs to store. More importantly, even today’s strongest encryption will be vulnerable to future attacks as computer processing power increases over time, meaning it shouldn’t be used to permanently store patient information.

Simply put, the actual implementation would be somewhat more complex than what’s described in this blog post, storing only anonymous pointers in the blockchain while the patient data remains securely stored off-chain.

Blockchain provides the potential for patients to easily aggregate their healthcare records from multiple sources and ensure the security and provenance of the data, which is an important feature of a successful PHR.

However, it is not to be mistaken as a solution just yet. Only time will tell if blockchain is the missing piece of the PHR puzzle.

Read another one of our blogs about Blockchain and the future of healthcare. Click the button below!

Go to Blog