Sage Journals: Discover world-class research

Abstract

Blockchain technologies have evolved in recent years, as have the use of personal health record (PHR) data. Initially, only the financial domain benefited from Blockchain technologies. Due to efficient distribution format and data integrity security, however, these technologies have demonstrated potential in other areas, such as PHR data in the healthcare domain. Applying Blockchain to PHR data faces different challenges than applying it to financial transactions via crypto-currency. To propose and discuss an architectural model of a Blockchain platform named “OmniPHR Multi-Blockchain” to address key challenges associated with geographical distribution of PHR data. We analyzed the current literature to identify critical barriers faced when applying Blockchain technologies to distribute PHR data. We propose an architecture model and describe a prototype developed to evaluate and address these challenges. The OmniPHR Multi-Blockchain architecture yielded promising results for scenarios involving distributed PHR data. The project demonstrated a viable and beneficial alternative for processing geographically distributed PHR data with performance comparable with conventional methods. Blockchain’s implementation tools have evolved, but the domain of healthcare still faces many challenges concerning distribution and interoperability. This study empirically demonstrates an alternative architecture that enables the distributed processing of PHR data via Blockchain technologies.

Keywords

health record blockchain distributed systems performance health informatics

Introduction

Blockchain technologies emerged from the fintech domain, focusing initially on crypto-currencies like Bitcoin.¹ These technologies have also been applied in other domains areas over the past decade.² In particular, Blockchain has expanded into other fields, such as the healthcare,^3,4 due to the advent of data distribution in peer-to-peer (P2P) networks. The healthcare domain has primarily evaluated the use of Blockchain technologies to integrate patient health record (PHR) data.² Much as chained blocks can store records of transactions with electronic money, chained blocks can also store PHR data.^5,6

Forming a complete, unique, and tamper-aware record of patient medical histories is a key goal of distributing PHR data via Blockchain. This technology is well-suited to meeting this goal since patients are often served by many health providers over their lifetimes.⁷ A data-chained distribution model thus facilitates the application of the Blockchain model to PHR data, thereby forming a unified and consistent view of these data. Another aspect of PHR data that fits well with Blockchain technologies is the fact that health records do not follow a centralized model. PHR can also be divided into parts or datablocks, such as allergy, evolution, family history, genetic information, immunizations, laboratory results, prescriptions, vital signs, among others.^8–10 In particular, health records should belong to the patient to ensure effective and secure personalized care.¹¹ Blockchain technologies can therefore be used to form a patient’s complete medical history, enabling distributed processing of data queries and manipulations. Moreover, Blockchain technologies are inherently resilient since data can be validated across all network nodes and encryption can be applied to ensure confidentiality.¹²

In the last years, Blockchain technologies have been applied to the domain of PHR data, and many initiatives, proposals, and usage models have emerged.¹³ Likewise, various tools have been developed to facilitate the implementation of Blockchain technologies. Despite this progress, however, few projects have actually applied Blockchain to PHR data in production environments.^14,15 In addition, the traditional Blockchain’s replication model causes every node in the network to receive all PHR data,¹⁶ which can degrade response times when performing transactions on the network.¹⁴

Our previous studies^17,18,19 demonstrated how the Chord algorithm alleviated the need to replicate PHR data across all nodes by obviating the need for each node to know all other nodes in the network, that is, each node needs little routing data about other nodes.²⁰ In the earlier work¹⁷ we described how to apply the Chord algorithm to perform scalable data replication for a limited number of nodes in a single Blockchain, instead of replicating data to all nodes (as would be done with conventional Blockchain platforms). Specifically, our previous study on interoperability¹⁸ focused on the OmniPHR model feature based on artificial intelligence through Natural Language Processing (NLP) to convert different health record formats to a unified standard and interoperable, for which we use the openEHR²¹ standard.

Our experience with these previous studies motivated the following research questions that underlie the work reported in this article:

(a) Can Blockchain technologies support various locations of PHR in a geographical and controlled manner, thereby avoiding the overhead of replicating PHR data on a large scale?

(b) In this case, where we could have multiple regional Blockchains, what would be the appropriate mechanisms for communicating PHR data between different Blockchains if the patient moves between them?

The main scientific contributions of this article are described below, where we seek to provide subsidies for research on the integration of various Blockchains and to support distributed PHR data:

(a) The first contribution describes a disruptive business model architecture based on Blockchain technologies to promote the scalable and robust implementation of distributed PHR data.

(b) The second contribution sheds light on the integration of different Blockchain-based architectures—specifically regarding the orchestration of multiple Blockchains—to enable the integration of PHR data in production environments.

The remainder of this article we organized as follows: Section Background and Terminology explores the background and terminology; Section Summary of Methods presents the method applied to our work on the OmniPHR Multi-Blockchain model; Section Related Work compares our approach with related work; Section The OmniPHR Multi-Blockchain Model describes the architecture of our model and its implementation aspects; Section Results presents the results obtained from our experiments; Section Discussion analyses and discuss the results; and Section Concluding Remarks highlights the conclusions and future directions of our work.

Background and terminology

This section presents the background and terminology employed in our article.

Blockchain and smart contracts are related concepts. A Blockchain is a linked list of datablocks chained together by pointers into a distributed ledger.¹ Likewise, a smart contract is a “set of promises, specified in digital form, including protocols within which the parties perform on these promises.”²²

A Personal Health Record (PHR) is an evolution of an Electronic Health Record (EHR). According to ISO/TR 18638:2017,²³ a PHR is a “representation of information regarding or relevant to the health, including wellness, development, and welfare of a subject of care, which may be stand-alone or integrating health information from multiple sources, and for which the individual, or their authorized representative, manages and controls the PHR content and grants permissions for access by and/or sharing with other parties.”

The Internet of Health Things (IoHT), the Internet of Things (IoT) in the domain of healthcare,²⁴ is in synergy with Blockchain technologies to enable scalable composition and distribution of PHR data. IoHT aims to aggregate PHR data in real-time to capture the status and history of patient health, such as data corresponding to the online monitoring of health status. Health Information Systems (HIS) can collect PHR data in several locations and update this data as it is received. This continuous formation of the complete and constant history of PHR data yields new opportunities to analyze these data to enhance wellness and streamline treatment options.²⁵

A key goal of this work is to promote the integration of PHR data throughout a patient’s lifetime. We therefore base our approach on international standards that enable effective and secure structuring and sharing of PHR data. These standards promote the interoperability of PHR data and are essential to ensuring interoperability and a unified view of these data. There are several popular standards for different parts of what can form complete PHR data, including DICOM (Digital Imaging and Communications in Medicine),²⁶ SNOMED-CT (SNOMED Clinical Terms),²⁷ and LOINC (Logical Observation Identifiers Names and Codes),²⁸ among others. Other protocols are broadly applied to standardize the format and high-level structure of PHR data. Two widely recognized international standards used in various countries to structure interoperable PHR data are HL7²⁹ and openEHR.²¹ These standards define a common structural format of PHR data, as well as enable the integration with specific formats, such as the DICOM,²⁶ SNOMED-CT,²⁷ and LOINC²⁸ standards.

Summary of methods

This section explains the methods we applied in our study, which followed the seven steps described below:^30,31

In this stage, we explore the topic at a high level, presenting the problematic and the research questions that underlie the study. We also present the overall methods and selection of related work, as well as the background and terminologies.

In this step, we express the problems identified in the requirements that the solution should meet.

We then model and present the architecture using design-thinking³² techniques.

We next construct the prototype following the requirements specified in the previous steps.

We evaluate the prototype, collecting, and presenting the data obtained.

We explore the analysis of the data concerning the feasibility of the project, discussing and verifying the results regarding the specified requirements, as well as about related work.

Finally, we present conclusions about the actions to address the problematic identified in the first step, the limitations of the solution, and possible future studies.

To select related work in our literature review,³¹ we defined the following search string designed to extract the main studies about the implementation and the challenges faced when applying Blockchain technologies for records of geographically-distributed health systems:

\begin{array}{l} B l o c k c h a i n (s) + ((D i s t r i b u t e d / D e c e n t r a l i z e d) + A r c h i t e c t u r e) \\ + ((H e a l t h (c a r e) / M e d i c a l) + (R e c o r d s / D a t a)) \end{array}

Related work

We executed the search string into eight research databases: CiteSeerX, Cochrane, Google Scholar, PLOS ONE, Pro-Quest, PubMed, ScienceDirect, and Scopus. Our goal was to identify scientific studies in the healthcare domain, recognized by the academic community, without restricting the period. We initially found several hundred related studies, mainly due to the restriction for searching articles that deal exclusively with implementations that refer to Blockchain-distributed architectures. By removing articles that dealt only with systematic reviews, contained only bidders without results, or even did not include the health area, we reduced the scope to less than a hundred articles. We then culled these articles to a subset that had concrete results close to our proposals so that we could compare these proposals and results. We found few articles that deal specifically with multi-blockchain architectures, either in the health field or in other areas. The studies found in general are dedicated to use in some specific contexts, such as: financial transactions, e-commerce and crypto-currencies;³³ IoT with fog computing (fog layer);³⁴ and smart contracts in the supply chain area.³⁵

We, therefore, selected the following recent studies on the topic, according to Table 1. The first column of Table 1 list the names or authors of studies selected as similar to our approach. The selected studies allowed us to discuss the models’ characteristics regarding the architecture, as well as to compare the obtained results. The second column lists health data standards used or cited by the studies for structuring the health records, including openEHR (21) or HL7 FHIR.²⁹ The third column shows the format used in the data, being generally JSON or XML. The fourth column contains the frameworks that served as the basis for proposals, including Ethereum or Hyperledger. Finally, the fifth and sixth columns indicate whether the study dealt with EHR or PHR data. Blanks indicate that the proposals do not mention standards, structures, or types of PHR data.

Table 1.

Related work and its main results.

Model¹	HDS2	Format3	B F4	EHR	PHR
Bismuth³⁶		JSON	E H		
Assist in the transition toward thoughtful and responsible data usage.
SDN³⁷			E		
Performance improved, and the ability to detect real-time attacks.
SingularityNET³⁸		JSON	E
Ability to interface with multiple blockchains.
IoB³⁹			E H
Discuss interledger techniques for enabling industry-scale blockchain.
Sharma et al.⁴⁰				
Resolves hierarchical security requirements with less consumption of energy.
BDKMA³⁴				
Multi-blockchain improves performance and scalability as network increases.
Hawig et al.⁴¹	F	JSON		
Designs presented a suitable performance in enabling interoperability.
HCB-SDPP⁴²			H		
Protects privacy more effectively than the traditional smart home system.
ReviewChain³⁵			E
Proposed smart contracts and notaries allow interfacing two blockchains.

Models in ascending order by year.

HDS: health data standard, where O: openEHR and F: HL7 FHIR.

JSON: javascript object notation; XML: extensible markup language.

BF: blockchain frameworks, where E: Ethereum and H: Hyperledger.

The OmniPHR Multi-Blockchain model

This section examines several views of our OmniPHR Multi-Blockchain model, which addresses critical problems faced in the adoption of Blockchain technologies applied to PHR data. This article describes a novel architecture, called OmniPHR Multi-Blockchain, that follows a different configuration compared to the conventional Blockchain platforms. We remain committed to not replicating all data to all nodes, however, while simultaneously leveraging the distribution and security features of Blockchain technologies, as shown in Figure 1.

Figure 1.

PHR distributed in different blockchains.

This figure shows how PHR data are distributed in different Blockchains (Blockchain #1 and #2), that is, data is automatically replicated between all nodes only within each Blockchain, but not automatically between Blockchains. The Middleware of the OmniPHR Multi-Blockchain model performs the data access mechanism between Blockchains, as can be seen in Figure 2. This ensures data integration and access is maintained without having to replicate all data to all nodes in all Blockchains, as it would in a traditional Blockchain architecture.

Figure 2.

Detailed view of OmniPHR Multi-Blockchain architecture.

Our architecture described in this article integrates multiple Blockchains to support the distribution of PHR data by applying middleware orchestration to the context of distant health providers. This section describes the OmniPHR Multi-Blockchain model, which supports the implementation of Blockchain technologies applied to PHR data in a distinct setup. We first present an overview of OmniPHR’s architectural structure, as shown in Figure 1, and explain the four pillars that form its technological insights and purposes.

Table 2 shows the PHR data format, with health data such as: demographics, hospitalizations, blood pressure, diagnoses, heart rates, and prescriptions. The data format follows the international openEHR¹⁸ data standard. All databases were used with anonymous data, so as not to make it possible to identify any patient during the research.

Table 2.

Patient’s health data format.

Demographic¹
Patient number	Gender	Date of birth
NNNN-NNNN	–	yyyy-mm-dd
Admissions
Admission	Discharge	Description
2100-12-31 00:00	2100-12-31 00:00	Abc. . .
Blood pressure
Date	Diastolic	Systolic
2100-12-31 00:00	NN	NNN
Diagnosis
Code	Description
NNNN	Abcde. . .
Heart rate
Date	Frequency
2100-12-31 00:00	NN
Microbiology
Chart time	Item ID	Description
2100-12-31 00:00	NNNNN	Abc. . .
Prescriptions
Start date	End date	Description
2100-12-31 00:00	2100-12-31 00:00	Abc. . .

All data is anonymized.

Visualizing OmniPHR’s Multi-Blockchain model

Figure 2 visualizes the architecture of OmniPHR’s Multi-Blockchain model, focusing on issues concerning (a) locality, (b) interoperability, (c) volume of data, and (d) security, as described below.

Locality concerns the physical location where the data is stored. A patient will likely visit multiple health providers throughout his or her life. A patient can treat him/herself at home, in different places, in different countries, in different health organizations, and by different professionals, as well as for short or long periods. Ideally, the PHR should collect the formal health records independently of location and timeless. This pillar is one where Blockchain technologies are well suited, as they can promote an independent view of locality that simultaneously links health records through P2P networks. In this context, a Blockchain database of health records can promote a unified and distributed view of the data. This distributed format is a different model from the centralized one, where health records are concentrated in one location only and shared by health organizations. OmniPHR’s Multi-Blockchain model differs from traditional Blockchain models, where all nodes share all data. In the traditional Blockchain model (e.g. applied to Bitcoin cryto-currency) data replication happens on all nodes of the network to keep all nodes up to date.¹⁴ The immutability principle in the Blockchain architecture can cause limitations in terms of computational processing cost and transaction latency. Since each network node maintains a complete history of all data, this improves security on the one hand, but on the other hand can result in high computational costs to maintain replication and data integrity across all network nodes.¹⁵ In contrast, OmniPHR’s Multi-Blockchain middleware, located in SuperChain (as shown in Figure 2), uses Blockchain to store the locations where the patient’s PHR parts are located. Client blockchains thus store the data, and SuperChain is responsible for fetching the regions of the PHR. Compared to traditional Blockchain architecture, OmniPHR’s Multi-Blockchain model takes advantage of the concept of immutability, but in a limited context with less need for replication and integration, as a large Blockchain network is split and orchestrated into smaller networks. This proposal can also collaborate in the formation of the concepts of Smart Hospital and Smart Home System (SHS),⁴² since the goal is to promote the exchange of data in different layers and levels of locality.

Interoperability involves the standardization of the types and contents of the data, that is, it aims at meeting the high variability of types and contents that the patients’ health records can store. Although the problem of data locale and its chaining can be suppressed by using Blockchain, there are still other problems, starting with the nature of the data types in health records. Data entered into patient health records has several types. The types of data that health records contain may vary considerably. Likewise, there may be structured and unstructured data records. International interoperability standards, such as HL7²⁹ and openEHR,²¹ can be integrated into some situations. However, even when these international standards are applied, it is still necessary to convert data to the same protocol since the variability of protocols is extensive, including private standards. In our previous study,¹⁸ we presented an alternative to addressing these situations and converting to the openEHR standard, which is the base standard of the OmniPHR Multi-Blockchain.

Volume addresses another fundamental element that composes a patient’s complete medical history and the corresponding size of these data. Many studies show that data records vary in volume, with multimedia records (such as images and sounds) being responsible for large amounts of data about health records.⁴³ However, we can also have other types of records that demand large volumes of data, such as DNA sequences. This large volume of data may not be a big problem for healthcare architectures that follow conventional centralized models. However, when it comes to a distributed model that supports a replication model for all nodes in the network, then this large volume of data can affect the system performance. In this sense, the OmniPHR Multi-Blockchain model does not replicate the patient’s multimedia data, but maintains the replication of the location where the data are in the local Blockchains.

Security involves several aspects of data security, such as access or privacy permissions, data breaches or corruption, and the veracity or confirmation of responsibility identification for information. The use of Blockchain technologies involves a data security model that, in addition to linking the data blocks, also aims to keep them inviolable.¹⁵ Hence, the focus is on access and responsibility for the inserted data. In this sense, digital signature solutions can bring greater security in the composition of the identification of responsibility for the information entered in the medical record. The OmniPHR Multi-Blockchain model leverages the inherent security features of the Blockchain architecture, such as data block chain encryption and smart contract. However, because the traditional Blockchain architecture replicates all data to all nodes, this may incur a data privacy limitation.¹⁵ To address this limitation, our model architecture divides the network into smaller and controlled contexts. Besides, the model adds the possibility of using access authorization, encryption and digital signature of each data block.

Adoption of the framework

The steps to adopt the OmniPHR Multi-Blockchain framework consist of: (a) installing the basic tools, including the Hyperledger platform on participating healthcare providers and on the SuperChain network nodes (as shown in Figure 2); (b) install the OmniPHR client module on the providers’ blockchains nodes, as well as the OmniPHR middleware on the SuperChain network nodes; (c) setup the SuperChain network nodes, informing the number of participating nodes, the appropriate access permissions and the communication between the nodes; (d) configure the nodes of the OmniPHR client modules to access the middleware on the SuperChain network, and configure the data conversion behavior, depending on the interoperability to the openEHR standard.The source codes of SuperChain and OmniPHR are publicly available in a repository¹.

External and internal views of the OmniPHR’s Multi-Blockchain architecture

Figure 2 depicts how to distribute the Blockchain network as an architectural model, which yields the following two views on PHR distribution: internal and external, as described below.

The internal view composes the internal Blockchain network of the health provider. This internal network distributes the records in internal nodes of the health organization and in the nearby health providers, with all features that Blockchain technology provides in its original proposal, that is, to replicate all data to all nodes of the network. This mechanism facilitates the use of tools that follow the traditional Blockchain model, taking advantage of all P2P features and services. Another goal is to keep the patient’s health records in places close to where he/she circulates, that is, to keep records regionally, where the patient is most frequently, without having to replicate the data to distant locations.

The external view aims to meet the access of a health professional or even the patient himself/herself to PHR data that are in other health providers, as shown in Figure 2. The OmniPHR Multi-Blockchain model serves the data sharing between health organizations and follows a different architectural model from the traditional Blockchain model, where all nodes receive all data. In this context, the external view seeks to assemble the OmniPHR Multi-Blockchain model using technologies that facilitate the integration and replication of data, such as the use of ESB (Enterprise Service Bus) with Publish and Subscribe technique, promoting the interoperability of the model. This feature of the model includes both the attendance of possibly different types of data coming from various organizations, as well as the integration with IoT devices and devices.

OmniPHR’s Multi-Blockchain model leverages characteristics of traditional Blockchain in its internal view, thereby facilitating implementation by health providers, through access to the client module. In contrast, due to the size that a complete medical record can have over a lifetime and its replication, the OmniPHR’s Multi-Blockchain external view (SuperChain) supports more scalable data replication since only replication of the locations of the parts that make up the PHRs is enabled. Healthcare provider applications can fetch this content through the interface with OmniPHR’s middleware module.

Results

To evaluate our model, we performed experiments to assess its efficiency and performance in a context with production data from a database of approximately 40 thousand patients, where 1.08 MB was the average size of each medical record, making a total of approximately 43.3 GB of data. We performed the tests within a week of submissions of inserts and queries of records in the same Blockchain and on another Blockchain through the OmniPHR Multi-Blockchain middleware. We separate these two Blockchains scenarios (a local network and a distant network), to reflect regional compositions of Blockchains, that is, where we have sets of nodes in a local network and other sets of nodes in other networks that are in other locations separated. The intention of these configurations was to verify the solution’s behavior from small geographically separated Blockchain networks.

To assess scalability, representing the use of healthcare providers, we tested the communication between the internal and external Blockchains. In the context of customers (providers) and SuperChain, representing Middleware (for external view), we tested with configurations ranging from 2 to 10 peers in Blockchains. The configuration of each superpeer in the SuperChain context was an Intel(R) Core i5, 3.30 GHz CPU, four cores with 8GB RAM. In the client context, each peer was an Intel(R) Core M, 1.1 GHz CPU, with 8GB RAM. We performed the transactions of insert and query in datablocks, that is, we worked with parts of a PHR, following the model of archetypes of openEHR. We submitted the operations both in the internal view, representing the use within a nearby network of health providers (i.e. the same Blockchain), as well as in the external view, of data sharing between distant health providers (i.e. on another Blockchain).

In Figure 3, we present the average time results for inserting a block into the same Blockchain. Four test scenarios were used in relation to users executing inserts in the same Blockchain, being 1, 100, 500, and 1000 concurrent user sessions. Figure 3 shows the times for the first transaction in the first column and the times for the other transactions in the second column. We can see in the graph that the standard deviation (marking at the top of each column) was very small, demonstrating that the times had no significant variation in the tests. Figure 4 presents the amount of throughput performed per second in the four different scenarios, with concurrent sessions inserting datablocks into the same Blockchain.

Figure 3.

Response time of datablock insert transaction in local Blockchain.

Figure 4.

Throughput of datablock insert transaction in local Blockchain.

Figure 5 presents the average time results to query (fetch) one datablock on the same Blockchain and another Blockchain, with the four concurrent user session scenarios (1, 100, 500, and 1000). The column 1 shows the average times to query a block in the same Blockchain and the column 2 shows the average times to query another Blockchain. Figure 6 presents the number of transactions performed per minute (throughput) to query datablocks in the same Blockchain (column 1) and another Blockchain (column 2), with the four session scenarios.

Figure 5.

Response time of datablock query in local and different Blockchain.

Figure 6.

Throughput of datablock query in local and different Blockchain.

In these results, we can observe that the first executions performed in the same Blockchain and queries executed in another Blockchain with one hop. These results show that in our tests, we perform the operations of inserting records only within the internal Blockchain, as well as queries. In addition, regarding other Blockchains, we only executed queries. These test scenarios represent scenarios where health providers can only enter patient records within the internal Blockchains, never updating or removing record blocks. Similarly, health providers can only query records from other Blockchains, which means that health providers cannot enter or change records in other Blockchains. The key principle is that healthcare professionals insert records in the Blockchains where the patient is close and conduct queries on records on nearby and distant Blockchains networks.

Discussion

This section discuss the experiments that evaluate the efficiency and performance of OmniPHR’s Multi-Blockchain model, analyzes the results, and compares our results with related work answering the research questions that supported this study. The results show that the first executions incur extra time. We observed this time due to the initialization of configurations that the Blockchains network needs to perform, such as the knowledge of the middleware and the other nodes location in the network. For the other executions, we observe that performance improves significantly. We also note that insert operations take a little longer than query-only operations. Moreover, transactions within the internal Blockchain are faster, compared to the hop needed to reach other Blockchains. However, the query times of one block are less than 1 s. In addition, performing batch operations (including 100, 500, and 1000 concurrent transactions) are close, with a slight deterioration of performance.⁴⁴ We can see in the graphs of Figures 3 and 5 that the standard deviation was very small for the configurations we made, demonstrating the scalability of the solution in the tested scenarios.

Comparing our results with related work

Comparing with related works, including works from other areas, we can see some similarities and differences in terms of the proposed architecture and results obtained. The similarities occur mainly in terms of architecture, since, like some related work,^33,35 our model also aims to orchestrate access between Blockchains and uses a bus to carry out replications within Blockchains. On the other hand, in terms of results obtained, by comparing the OmniPHR Multi-Blockchain model and the results described above with the related work shown in Table 1, we identified the following differences:

Health data standard and format. Only Hawig et al.⁴¹ proposes the use of a health data standard, in the case of HL7 FHIR,²⁹ with JSON format. Goertzel et al.³⁸ and Erhardt et al.³⁶ only mention the use of JSON as a format for the data. Other related work does not address/specify interoperability standards for health data. In contrast, our work adopts the use of the openEHR²¹ health data standard, due to its integration with other standards, such as HL7 FHIR,²⁹ DICOM,²⁶ SNOMED-CT,²⁷ and LOINC,²⁸ in addition to the standard blocks through the archetypes format. Our model also supports the HL7 FHIR format since it includes the transformation of this format into openEHR.¹⁸ Like openEHR and HL7 FHIR,²⁹ our model supports JSON and XML. Comparing the JSON and XML schemas in this case, JSON is less verbose to represent the data, while the XML format is more verbose but supports XSD (XML Schema Definition) validation, providing greater guarantee of correctness of the data.

Implementation framework. Some studies propose the use of Ethereum,^35–39 others Hyperledger,^36,39,42 and others do not mention a specific framework. In this case, our proposal is based on the Hyperledger framework to facilitate the implementation of our Multi-Blockchain model. Hyperledger provides important characteristics, such as (a) being an open-source framework, thereby allowing debugging and behavior analysis, (b) works with open and popular programming languages, (c) allows the creation of private Blockchains, which is important to support sensitive health data, and (d) and without binding (charging) with crypto coins for use.⁴⁴ As in Goertzel et al.,³⁸ our model uses RPC (Remote Procedure Call) over TLS (Transport Layer Security) via HTTPS from client modules to invoke our SuperChain Middleware to perform communications between Blockchains.

Type of health data stored in the Blockchain. Some studies mention the use of EHR,^34,40,41 others mention PHR^36,37,42 and the others do not specifically mention some type of health data. OmniPHR aims to attend the patient emphasizing mobility, that is, the possibility of the patient having, in fact, under control of their personal health data, composing the concept of PHR.

Limitations

Our results showed that the insert operations of blocks from the provider performed in the worst cases under 9 s. In the case of queries of data records in the internal Blockchain, the performance was near real-time. The situations in which the performance degraded somewhat stemmed from the search of data (query) in another Blockchain with a hop, but even so in low times compared to the query on the same Blockchain. Our results also highlight limitations with the aspects of the tests that suggest possible technological improvements. These results in turn can help us improve performance, for example, by parallelizing processing, caching database records, and improving initialization operations.⁴⁴ Another limitation was that we tested the performance while the model was responding, that is, without producing timeout or memory overflow errors.

Looking to address the initial research questions, we can see that: (a) we can leverage the traditional Blockchain architecture to orchestrate regionally distributed PHRs without having to replicate data to all nodes; (b) the way we found adequate to support the movement or access to distributed patient data was through the orchestrated middleware developed in our model; (c) finally, by analyzing the empirical results, we have demonstrated the ability of the OmniPHR Multi-Blockchain model to scale PHR via a distributed, interoperable, and standardized architecture.

Concluding remarks

This article focused on evaluating the application of Blockchain technologies to support the distribution of patient health records (PHR). However, traditional Blockchain technologies replicate the data blocks for all nodes, which can be a problem due to the size of medical records in large-scale integrated healthcare systems. To address these concerns, this article described the OmniPHR Multi-Blockchain model, which enhances both related work and our own prior studies.^17,19 We presented the methodology that addressed the challenges with PHR distribution through the innovative OmniPHR Multi-Blockchain model, which is developed atop the Hyperledger framework and the openEHR data standard. We also presented the results of experiments that evaluated OmniPHR empirically using large numbers of patient health records. The following is a summary of the lessons learned conducting this study:

While on the one hand there is interest in using blockchain with PHR, on the other hand there is concern about privacy, interoperability, size, and volume of data.

Data replication to all nodes in the Blockchain network to ensure security and immutability in the traditional model is a key point to address.

Our proposal of private blockchain duly attended the limited contexts; as well as through our middleware proposal, we demonstrated the feasibility of orchestrating multiple blockchains with adequate response times and attention to health data privacy.

The results demonstrated the potential of the OmniPHR Multi-Blockchain model and the need, as future work, for further testing in larger scenarios, as well as in specific contexts such as Wi-Fi, cellular, and Bluetooth networks.

Footnotes

Author contributions

All authors contributed to the conception of the work, revising, and criticizing the content. All authors approved the manuscript for publication.

Declaration of conflicting interest

The authors have no competing interests to declare.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: TThe authors would like to thank the Coordenação de Aperfeiçoamento de Pessoal de Nível Superior—CAPES (Finance Code 001), the Brazilian National Council for Scientific and Technological Development—CNPq (Grant numbers 303640/2017-0 and 309537/2020-7), and the Fundação de Amparo à Pesquisa do Estado do Rio Grande do Sul—FAPERGS (Grant number 21/2551-0000118-6) for supporting this work.

ORCID iD

Cristiano A da Costa

Notes

References

Nakamoto

Bitcoin: A peer-to-peer electronic cash system, Panama, PA: Bitcoin Project. 2008.

McGhin

Choo

KKR

Liu

, et al. Blockchain in healthcare applications: Research challenges and opportunities. J Netw Comput Appl 2019; 135: 62–75.

Kuo

Kim

Gabriel

RA.

Privacy-preserving model learning on a blockchain network-of-networks. J Am Med Inform Assoc 2020; 27(3): 343–354.

Mayer

da Costa

Righi

RdR

. Electronic health records in a blockchain: a systematic review. Health Inform J 2019; 26(2): 1273–1288.

Azaria

Ekblaw

Vieira

, et al. Medrec: using blockchain for medical data access and permission management. In: 2016 2nd International conference on open and big data (OBD), pp.25–30. New York: IEEE.

Patel

A framework for secure and decentralized sharing of medical imaging data via blockchain consensus. Health Inform J 2019; 25(4): 1398–1411.

Chen

Ding

, et al. Blockchain-based medical records secure storage and medical service framework. J Med Syst 2019; 43(1): 5.

Roehrs

Da Costa

da Rosa Righi

, et al. Personal health records: a systematic literature review. J Med Internet Res 2017; 19(1): e13.

Wang

Zhu

, et al. Feature rearrangement based deep learning system for predicting heart failure mortality. Comput Meth Programs Biomed 2020; 191: 105383.

10.

Lin

Kuo

Liu

MY.

A health informatics transformation model based on intelligent cloud computing – exempliﬁed by type 2 diabetes mellitus with related cardiovascular diseases. Comput Meth Programs Biomed 2020; 191: 105409.

11.

Puthal

Malik

Mohanty

, et al. The blockchain as a decentralized security framework [future directions]. IEEE Consumer Electron Magaz 2018; 7(2): 18–21.

12.

Cachin

Vukoli’c

Blockchain consensus protocols in the wild. arXiv preprint arXiv:170701873 2017.

13.

Fan

Wang

Ren

, et al. Medblock: efﬁcient and secure medical data sharing via blockchain. J Med Syst 2018; 42(8): 136.

14.

Park

Lee

, et al. Is blockchain technology suitable for managing personal health records? Mixed-methods study to test feasibility. J Med Internet Res 2019; 21(2): e12533.

15.

Hughes

Dwivedi

Misra

, et al. Blockchain research, practice and policy: applications, beneﬁts, limitations, emerging research themes and research agenda. Int J Inform Manage 2019; 49: 114–129.

16.

Zhu

Shen

, et al. Blockchain-based data preservation system for medical data. J Med Syst 2018; 42(8): 141.

17.

Roehrs

da Costa

da Rosa Righi

Omniphr: a distributed architecture model to integrate personal health records. J Biomed Inform 2017; 71: 70–81.

18.

Roehrs

da Costa

da Rosa Righi

, et al. Toward a model for personal health record interoperability. IEEE J Biomed Health Inform 2018; 23(2): 867–873.

19.

Roehrs

da Costa

da Rosa Righi

, et al. Analyzing the performance of a blockchain-based personal health record implementation. J Biomed Inform 2019; 92: 103140.

20.

Stoica

Morris

Liben-Nowell

, et al. Chord: a scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM Trans Netw 2003; 11(1): 17–32.

21.

Yang

Huang

Discovering clinical information models online to promote interoperability of electronic health records: a feasibility study of openehr. J Med Internet Res 2019; 21(5): e13504.

22.

Szabo

Smart contracts: building blocks for digital markets. EXTROPY J Transhumanist Thought 1996; 16(2): 18.

23.

ISO. Health informatics—guidance on health information privacy education in healthcare organizations. Technical Report 1ISO/TR, ISO - International Standard Organization: Geneva, Switzerland, 18638:2017, 2017. https://www.iso.org/obp/ui/#iso:std:iso:tr:18638:ed-1:v1:en:term:3.20 (accessed 29 January 2021)

24.

da Costa

Pasluosta

Eskoﬁer

, et al. Internet of health things: toward intelligent vital signs monitoring in hospital wards. Artif Intellig Med 2018; 89: 61–69.

25.

Wang

Kung

Byrd

TA.

Big data analytics: understanding its capabilities and potential beneﬁts for healthcare organizations. Technol Forecast Social Change 2018; 126: 3–13.

26.

Gonçalves-Ferreira

Sousa

Bacelar-Silva

, et al. Openehr and general data protection regulation: evaluation of principles and requirements. JMIR Med Inform 2019; 7(1): e9845.

27.

Teodoro

Sundvall

Junior

, et al. Orbda: an openehr benchmark dataset for performance assessment of electronic health record servers. PLoS One 2018; 13(1): e0190028.

28.

Wulff

Haarbrandt

Tute

, et al. An interoperable clinical decision-support system for early detection of sirs in pediatric intensive care using openehr. Artif Intellig Med 2018; 89: 10–23.

29.

Saripalle

Runyan

Russell

Using hl7 fhir to achieve interoperability in patient health record. J Biomed Inform 2019; 94: 103188.

30.

Kothari

CR.

Research methodology: methods and techniques. New Age International: New Delhi, India, 2004.

31.

Baskerville

Pries-Heje

Venable

. Soft design science methodology. In: Proceedings of the 4th international conference on design science research in information systems and technology. ACM: Philadelphia, Pennsylvania, p. 9.

32.

Sohaib

Solanki

Dhaliwa

, et al. Integrating design thinking into extreme programming. J Ambient Intellig Humanized Comput 2019; 10(6): 2485–2492.

33.

Sun

Mao

Bai

, et al. Multi-blockchain model for central bank digital currency. In: 2017 18th International conference on parallel and distributed computing, applications and technologies (PDCAT). pp.360–367. New York: IEEE.

34.

Shi

Privacy-oriented blockchain-based distributed key management architecture for hierarchical access control in the iot scenario. IEEE Access 2019; 7: 34045–34059.

35.

Wang

Zhang

Kim

. Reviewchain: smart contract based review system with multi-blockchain gateway. In: 2018 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (SmartData). pp.1521–1526. New York: IEEE.

36.

Erhardt

KD.

Bismuth: a blockchain-based program for verifying responsible data usage. PhD Thesis, Massachusetts Institute of Technology, 2017.

37.

Sharma

Chen

Park

JH.

A software deﬁned fog node based distributed blockchain cloud architecture for iot. IEEE Access 2017; 6: 115–124.

38.

Goertzel

Giacomelli

Hanson

, et al. Singularitynet: a decentralized, open market and inter-network for AIs, 2017. Thoughts, Theories Stud Artif Intell Res. http://singularitynetagi.com/whitepaper.pdf (accessed in 29 January 2021).

39.

Wang

Karunamoorthy

, et al. Internet of blockchains: techniques and challenges ahead. In: 2018 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (SmartData), pp.1574–1581. New York: IEEE.

40.

Sharma

You

Palmieri

, et al. Secure and energy-efﬁcient handover in fog networks using blockchain-based dmm. IEEE Commun Magaz 2018; 56(5): 22–31.

41.

Hawig

Zhou

Fuhrhop

, et al. Designing a distributed ledger technology system for interoperable and general data protection regulation – compliant health data exchange: a use case in blood glucose data. J Med Internet Res 2019; 21(6): e13665.

42.

She

Lyu

, et al. Homomorphic consortium blockchain for smart home system sensitive data privacy preserving. IEEE Access 2019; 7: 62058–62070.

43.

Kaur

Rani

Managing data in healthcare information systems: many models, one solution. Computer 2015; 48(3): 52–59.

44.

Thakkar

Nathan

Viswanathan

. Performance benchmarking and optimizing hyperledger fabric blockchain platform. In: 2018 IEEE 26th international symposium on modeling, analysis, and simulation of computer and telecommunication systems (MASCOTS). pp.264–276. New York: IEEE.

Integrating multiple blockchains to support distributed personal health records

Abstract

Keywords

Introduction

Background and terminology

Summary of methods

Related work

The OmniPHR Multi-Blockchain model

Visualizing OmniPHR’s Multi-Blockchain model

Adoption of the framework

External and internal views of the OmniPHR’s Multi-Blockchain architecture

Results

Discussion

Comparing our results with related work

Limitations

Concluding remarks

Footnotes

Author contributions

Declaration of conflicting interest

Funding

ORCID iD

Notes

References