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.
Introduction
Blockchain technologies emerged from the fintech domain, focusing initially on crypto-currencies like Bitcoin. 1 These technologies have also been applied in other domains areas over the past decade. 2 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. 2 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. 7 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. 11 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. 12
In the last years, Blockchain technologies have been applied to the domain of PHR data, and many initiatives, proposals, and usage models have emerged. 13 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, 16 which can degrade response times when performing transactions on the network. 14
Our previous studies17,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. 20 In the earlier work 17 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 18 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 21 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?
(c) What response time and throughput improvements could be obtained with such an optimized solution?
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. 1 Likewise, a smart contract is a “set of promises, specified in digital form, including protocols within which the parties perform on these promises.” 22
A Personal Health Record (PHR) is an evolution of an Electronic Health Record (EHR). According to ISO/TR 18638:2017, 23 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, 24 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. 25
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), 26 SNOMED-CT (SNOMED Clinical Terms), 27 and LOINC (Logical Observation Identifiers Names and Codes), 28 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 HL729 and openEHR. 21 These standards define a common structural format of PHR data, as well as enable the integration with specific formats, such as the DICOM, 26 SNOMED-CT, 27 and LOINC 28 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 32 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, 31 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:
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; 33 IoT with fog computing (fog layer); 34 and smart contracts in the supply chain area. 35
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. 29 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.
Related work and its main results.
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.
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.
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 18 data standard. All databases were used with anonymous data, so as not to make it possible to identify any patient during the research.
Patient’s health data format.
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. 14 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. 15 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), 42 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 HL729 and openEHR, 21 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, 18 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. 43 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. 15 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. 15 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 1 .
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
The
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.
Response time of datablock insert transaction in local Blockchain.
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.
Response time of datablock query in local and different Blockchain.
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. 44 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:
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. 44 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.
