Nowadays businesses often need a system-of-record platform with auditing capability to keep track of critical data such as internal compliance, regulatory data (e.g., GDPR) or complete history of assets. For this kind of use cases, blockchain technology offers many advantages compared to traditional database systems. Blockchain based systems provide their consumers with trust in the integrity and validity of the data stored thanks to its immutability properties and consensus mechanisms (to learn more about Blockchain and its basic concepts we recommend reading our Basic Concepts article, and to get acquaintance with Hyperledger Fabric Concepts that will be heavily used through this article).

Particularly, and in several scenarios, the HealthCare Industry seems to have issues regarding the cooperation between different organizations in terms of client privacy and sensitive data which is heavily regulated.

We strongly believe that this case is a perfect fit for Smart Contracts, as they allow all parties involved to agree on the implementation of a system that guarantees that required regulations are followed while information exchange protocols can be agreed on top of this technology. During this article we focus on describing a scenario with a custom solution using blockchain technology.

Before we get into the thing, I don’t want to skip mentioning the great team of software engineers that contributed and provided feedback into putting this together: Matias Diaz, Luciano Pereira & Emanuel Vecchio— thank you guys, you made it happen!

‍

Our Scenario

What we will show you ahead consists of a system of record implementation that allows different Medical Provider organizations to store their patient’s Electronic Medical Records[1] (EMRs) and share them between each other as needed.

Each medical provider[2] has three type of actors, each one playing a different role in the network:

1. Healthcenter: The Medical provider employee in charge of the patient admission process.
2. Physician[3]: The medical practitioner working for a medical provider. This actor will treat patients.
3. Patient: The person that is admitted to a medical provider for a medical treatment or consultation.

Regarding smart contracts implementation, we conceptually divide them by actors in the network.

1. Healthcenter: This will contain the operations needed to create a patient’s EMR and to authorize the sharing of an EMR to a different Medical provider.
2. Physician: This actor will be able to access the EMRs that belong to the medical provider they work for. Additionally, they will be able to append additional information to the EMRs about a medical visit.
3. Patient: This actor will be able to download his EMR and allow a medical provider to access his EMR stored at a different medical provider.

‍

‍

Medical Record Workflows

As we have already defined the different entities and their roles in our scenario, we now want to detail the 2 workflows we chose to implement for our medical records business. Our record system has two workflows: “Managing an EMR” and “Sharing and EMR”.

‍

Managing an EMR

This one is the main workflow. It involves EMR’s creation and edition process. Each entity is in charge of specific operations to create or update an EMR as is showing in the following flow:

‍

‍

1. A patient arrives to a Medical Provider for the first time.
2. The Medical Provider’s administration signs up the patient and creates their EMR. The Medical Provider becomes the owner of that EMR.
3. The patient visits a Medical Provider’s Physician.
4. The Physician reads the Patient’s EMR before attending the patient.
5. After the consultation, the Physician adds a new medical note to the EMR.
6. Finally, the Patient can download their updated EMR.

‍

Sharing an EMR

This is a workflow between Medical Providers. It allows EMRs to be shared from one Medical Provider to another, after the patient’s authorization:

‍

‍

1. A Medical Provider tries to get an EMR belonging to another Medical Provider.
2. The Requesting Medical Provider cannot read the external EMR because it does not have permission on that EMR.
3. The Medical Provider requests permission on that EMR.
4. The owner Medical Provider approves the request.
5. The owner Patient approves the request.
6. A Medical Provider tries to get the EMR.
7. The Requesting Medical Provider reads the external EMR.

‍

The Solution — High-level Architecture

Overview

We implemented our solution using the Hyperledger Fabric platform. We think this platform is the most fitting for our scenario since it was originally designed for enterprise use and it focus on permissioned systems.

For the smart contract development, Hyperledger Fabric offers three different programming languages: Golang, Java, and Node.js. We decided to use Node.js for our reference implementation since it is the most widely used language between the three.

We also created shell scripts that utilize Docker-Compose and the Hyperledger Fabric binaries and Docker images to easily create and manage a Blockchain network where medical provider organizations can be added as members. These scripts also provide the entry point that allow medical providers to interact with the network and execute its smart contracts.

‍

‍

Managing an EMR

EMR managing process consist of one Health Provider organization creating patient’s EMR (at first visit, if does not exist before). Later, physicians from that Medical Provider are allowed to read and append medical entries to patient’s EMR — this process create the history captured within the EMR. That instance of the EMR belongs to the Medical Provider which creates the record and cannot be accessed nor read by any other institution in the network.

‍

‍

The diagram above shows the following:

1. A Medical Provider 1 administration employee uses their signed certificate to communicate with the organization’s peer node as an authenticated health center user. They ask the peer to invoke the EMR creation operation installed in the peer’s chaincode. This operation is endorsed by all other Medical Provider peers and in case it is successful, the new EMR gets stored in the peers’ ledgers (although it is only accessible by users belonging to the Medical Provider 1 organization).
2. A Medical Provider 1 physician uses their signed certificate to invoke the chaincode operation to add a note to the patient’s EMR. If the operation is successfully endorsed by all Medical Providers, the updated EMR gets stored in the peers’ ledgers.
3. A Medical Provider 1 patient uses their signed certificate to invoke the chaincode operation that retrieves their own EMR.
4. A Medical Provider 2 physician uses their certificate to communicate with the organization’s peer node and tries to read an EMR from a patient belonging to the Medical Provider 1 organization. The chaincode itself uses the physician’s certificate to determine the organization they belong to and restrict they access to the EMR.

‍

Sharing an EMR

EMR sharing process consist of one Health Provider organization giving another organization access to read one of their patient’s EMRs (with patient consent). As stated before, organizations own the EMRs, but once shared (for reading purposes as they still control appending operations) they do not control what recipients do with this information. Additionally, when sharing an EMR with another organization in the network, it allows that organization’s physicians to access it.

Since patient’s EMRs are often updated with information about new medical appointments and treatments, when sharing an EMR between organizations we evaluated two alternatives. The first one was to give full access to the EMR, allowing the recipient to access the latest EMR version and see updates in real time. The second one was to provide the recipient with a current snapshot of the EMR, requiring the process to be repeated if the receiver organization needs new information.

We decided to go with the second option and share an EMR snapshot since it gives the sharer organization more control over the information being shared, allowing for more privacy.

‍

‍

The diagram above shows the following:

1. A Medical Provider 1 administration employee uses their signed certificate to invoke a chaincode operation that signals that the organization gives the Medical Provider 2 organization permission to read an EMR belonging to a specific patient (the permissions are stored in the ledger).
2. A Medical Provider 1 patient uses their signed certificate to invoke a chaincode operation that signals that they give the Medical Provider 2 organization permission to read their EMR (which is owned by the Medical Provider 1).
3. A Medical Provider 2 physician uses their certificate to communicate with the organization’s peer node and tries to read an EMR from a patient belonging to the Medical Provider 1 organization. The chaincode retrieves the permissions from the peer’s ledger. Since both the health center user and the patient user have given the physician’s organization permission to read the EMR, the physician can access it.

‍

Network Components & Entities

We created the following diagram in order to give you an idea of the high-level picture of the different actors (virtual or human) that interact with each other within the platform (it has all components and entities structured as a hierarchy of relations):

‍

‍

Implemented Operations

Our solution’s chaincode is composed of different methods or “smart contracts” that manipulate the ledger’s data.

The Hyperledger Fabric response objects contain a JSON object, together with a status field that follows the HTTP status codes. For more information you can check the Fabric SDK documentation.

‍

Healthcenter

These operations can only be executed by an authenticated healthcenter user:

• CreateEmr: Creates a EMR for a specific patient and stores it in the ledger.
• CheckIsPatientRegistered: Checks if a patient is already registered in the organization.
• AuthorizeEmrReading: Authorizes another Health Provider to read the current version of a specific patient’s EMR.

‍

Physician

These operations can only be executed by an authenticated physician user:

• ReadEmr: Retrieves an EMR by id.
• GetEmrByPatientId: Retrieves an EMR by its patient id.
• AddEmrNote: Adds a note to an existing EMR.
• GetSharedEMR: Retrieves an EMR belonging to a patient from another organization only if the owner organization and the patient have given access permission.

‍

Patient

These operations can only be executed by an authenticated patient user:

• GetOwnEMr: Retrieves the patient’s own EMR. The chaincode gets the patient id from the user’s certificate.
• GetMedicalVisitCount: Returns the number of times the patient has visited a specific Health Provider.
• ApproveEmrSharing: Authorizes another Health Provider to read the patient’s current EMR version.
• RemoveEmrSharing: Removes authorization for a Health Provider to read the patient’s EMR.

‍

Summary

As we have seen through this article Blockchain technology can be applied to many different scenarios and industries and not only be tied to crypto-currencies (as most of people think).

Blockchains, as distributed ledger technology, offering transparency to network members as well as immutability of the data being recorded within them are a perfect fit for several domains. In addition, different flavors of them which add different layers of security and privacy of transactions are the perfect fit and way to cover a wide set of use cases and requirements (from business solution & compliance to technical perspective).

In this case, the Health Industry can leverage this technology to handle sensitive medical data & records of their customers with highest levels of confidentiality, resiliency, flexibility, and scalability, while being compliant with most regulations in the sector. The scenario described in the article is just a glimpse of what it can be achieved with these amazing technologies.

We hope you liked it! Don’t forget to visit our reference implementation if you are curious into technical details or just want to dig deeper into decisions being made during the construction of this sample.

‍

Glossary

[1] Electronic Medical Record: (aka EMR) A digital medical record[4] maintained by a specific medical provider.

[2] Medical Provider: A medical institution that is responsible for creating and maintaining an Electronic Medical Record.

[3] Physician: A health-care professional licensed to practice medicine.

[4] Medical Record: Documentation of a single patient’s medical history and care across time within one medical provider’s jurisdiction.

‍

Originally published by Mauro Krikorian for SOUTHWORKS on Medium 05 April 2021

‍