AWS Public Sector Blog
How AWS and blockchain make it possible to meet the challenges of interoperability in healthcare
Health information is generally disorganized, unstructured, and stored in various formats, making it impractical to trace patient history and promote the exchange of information on a national scale with other health professionals.
A solution to this issue is the creation of a unique patient registry, which can be defined as a repository of retrospective, current, and prospective information of the patient in digital format. The main objective of this registry is to promote integrated, continuous, efficient, quality health care. In addition, the registry needs to be accessible and available to different health institutions. When building these registries, it’s necessary to use standards to define not only how the information is structured, but also how it can be retrieved and shared among the different Health Information Systems (HIS) in a safe, scalable, cost-efficient way. This can be done using blockchain.
MBAMobi, an AWS customer in the public sector, has implemented a single patient registration using blockchain Hyperledger Fabric version 1.4.1. Learn how this is being implemented:
Blockchain is a distributed registry, also called ledger, that records information in a distributed way. Someone needs to be responsible to decide which of the distributed nodes of the chain has the correct information to be stored. In blockchain, this decision process is called consensus.
Consensus is established when all nodes involved in an operation are in agreement with the transaction to be executed.
When choosing the consensus algorithm, some factors need to be considered, such as:
- Computers fail, and the system needs to be prepared for this.
- Packets and messages are lost.
- There may be entities in the chain that purposely want to tamper with the process of validating an operation.
For this blockchain solution, the consensus algorithm called RAFT is used, which is simpler and consumes less resources than other algorithms. RAFT can guarantee fault tolerance, which is expected from a consensus algorithm.
FHIR and smart contract
Smart contract is the business logic that defines the way entities in the blockchain chain communicate with each other. The contract defines rules, concepts, operations, and data formats accepted within the chain.
There are many standards in the health area for sharing clinical data, but when faced with the challenge of interoperability, a light and flexible protocol can enable projects on a national scale, and perhaps worldwide, in a more feasible way. The same information in reduced format generates less expenses with storage, processing, and network traffic.
For this reason, HL7’s Fast Healthcare Interoperability Resources (FHIR) standard was chosen for this solution with its inherent flexibility and its easy way of RESTful access. Therefore, the smart contract for this solution is based on it.
Other standards, such as OpenEHR or HL7 v3 may be accepted, but they need to be converted to FHIR to ensure compatibility with smart contract.
Distribution and scalability with Hyperledger Fabric
Due to the complexity and variability of health data, and also the scale that a project like this can achieve, having a scalable and distributed architecture, in which data is stored safely and replicated, is critical to the long-term success of the project.
In the traditional blockchain model, processing is performed on all nodes in an orderly and sequential manner, which limits scalability.
On the other hand, HyperLedger Fabric is based on an architecture called execute-order-validate, which allows actions to be first executed—which can be done in parallel—before the blockchain applies consensus on the correct place for this operation in the chain. This strategy allows for greater scalability to the solution.
Security and privacy
With Bitcoin, anyone interested can participate in the blockchain chain and contribute to it, which is why it is called public and permissionless.
Hyperledger Fabric is part of the private category and permissioned—that is, to participate in it you must have permission. There is an authentication and authorization layer that controls all access and operations that each member can perform in the chain. For this control to be done, all participants in the chain must have a certificate, which is issued by the Membership Service Provider (MSP).
Within the blockchain, each participating health unit is represented by an organization. Each organization is part of one or more channels.
Channels allow organizations to communicate privately and confidentially with each other. Each transaction is executed within a channel, and everyone on that channel must be authenticated and authorized to operate there.
The solution allows the exchange of confidential information between two or more health units, without the other units being able to see the content of the transaction. For this, the Private Data Collection mechanism is used. This mechanism allows sensitive data from patients’ medical records to be sent privately to a set of participants. Participants who are not part of the transaction have only the transaction hash. Thus, although they cannot see the content of the transaction, they can validate it, if necessary.
In addition to these, another security measure is adopted: the disks of the virtual machines hosting the blockchain are encrypted using the managed encryption service from Amazon Web Services (AWS). This way, the data is encrypted both in transit between the virtual machine and disk, and at rest.
Making patient history immutable is an important part of using blockchain.
In the blockchain, ledger is the component responsible for storing the current state of a record and also everything that has happened to it so far. Each item in a record’s history is linked to its predecessor and indicates the state of the record at the time the operation took place.
The fact that all the records are interconnected guarantees the immutability of the blockchain, since the hash referring to the data of the previous block is present in the successor block and, for some block to be changed, it would be necessary to change the entire chain, by at least 51 percent of the nodes where this data is replicated, which would be impractical.
The architecture in Figure 1 is a high-level representation of the solution deployed on AWS:
In blockchain performance tests conducted by the client, AWS had 42 percent more transactions per second, 60 percent lower CPU usage, 33 percent less memory consumption, and 25 percent more storage throughput.
The use of blockchain to store and share medical data, and subsequently promote health interoperability, is now a reality. Implemented with full support of data and infrastructure security on AWS, strong architectural practices, and cost efficiency, this solution has enabled the healthcare provider to implement a secure and cost effective distributed health record system. Patients can share their health data with peace of mind, enabling patient care with less waste and with greater visibility of the past and current state of their health.
Learn more about FHIR Works on AWS and public sector healthcare. And check out these ebooks on healthcare interoperability: “Healthcare interoperability: Creating a clearer view of patients” and “Keeping the patient at the center of healthcare with interoperability.”