Deriving Key Architectural Features of FHIR-BlockChain Integration through the Qualitative Content Analysis

doi:10.21203/rs.3.rs-936437/v1

Background: The blockchain has been highlighted its possibility as a technology to ensure immutability, transparency, and decentralization of data in information systems in various industries. Amongst the possibility of blockchain in the healthcare industry, one of the informatics areas that can leverage the benefits of using blockchain is healthcare information exchange while it is combined with the use of fast healthcare interoperability resources (FHIR).

Objective: To investigate the key architectural features of FHIR and blockchain integration that provides the benefits of immutability of transaction data for a decentralized and secured healthcare information exchange framework.

Materials and Methods: We conducted an in-depth, individual, semi-structured interview with four domain knowledge experts in the area of FHIR and medical blockchain. Our interview plan were qualified by the COREQ criteria (Consolidated Criteria for Reporting Qualitative Research), which is an analysis method the qualitative content analysis. We conducted the interview based on seven key questions and additional open discussion of technical, business, and legal aspects of the FHIR-blockchain implementations. The results of the interviews were recorded, summarized, and codified in a structured way.

Results: The qualitative content analysis revealed the four types of FHIR-blockchain architectures for storing FHIR data and/or transaction and integrating FHIR and blockchain. The four FHIR-blockchain architectures compose of 1) the types of on-chain information from FHIR transactions to be stored inside blocks and 2) the features of the architectures and their possible use case scenarios. In addition to the characterization of the four FHIR-blockchain architectures, we discussed the topics; 1) potential legal issues, 2) justification of using blockchain in healthcare information exchange, and 3) practical implications and guideline of the architectures for implementation.

Conclusion: Although FHIR-blockchain integration has been considered as a promising tool for decentralized and secured healthcare information exchange, it should be clarified as to how it aligned with business requirements. A detailed and/or tailored guidelines of implementation in the architectural, functional, and legal perspectives may need to be demonstrated by the benefits of using FHIR-blockchain integration.

Scientific Communication

Biomedical Engineering

Health Economics & Outcomes Research

FHIR

blockchain

interoperability

healthcare information exchange

Over the last years, blockchain has been highlighted by its possibility as a technology to ensure immutability, transparency, and decentralization of data in information systems in various industries. Although Bitcoin is the first and most well-known success of blockchain adoption in the field of cryptocurrency [1], the use of blockchain is not limited to it but accounting, finance, e-commerce and others need data transparency and security. Adoption of blockchain in the healthcare industry is also promising, since it requires high level of security and privacy of patient data and blockchain can certainly contribute to enhance it [2].

Implementations in the area have focused on using blockchain to validate and guarantee integrity of data when storing and sharing institutional medical data between electronic health record (EHR) systems [3-8]. As the scope of healthcare data expands outside clinical settings, blockchain has been also implemented for sharing and storing patient-generated data from personal health records (PHRs) [9-13] and clinical trials [14,15]. Most of these works proposed a well-organized architecture or frameworks and a few demonstrated the performance of the prototype developed in the study [16].

Amongst the possibility of blockchain in the healthcare industry, one of the areas that informatics can leverage benefits of using blockchain is healthcare information exchange while it is combined with use of fast healthcare interoperability resources (FHIR). FHIR a standard describing data formats, elements, and an application programming interfaces (APIs) for exchanging clinical data and was developed by health level 7 (HL7) which is a non-profit organization that encourages development and adoption of healthcare data standards. Since FHIR provides a standard based data model of transactions between healthcare systems and applications, use of predefined data elements and architectures of FHIR will leverage benefits of blockchain technology. A small number of studies demonstrated proof-of-concept of the FHIR-blockchain architecture, and its architectural and functional feasibility by the integration [4,17].

Despite the early studies, two important questions have not yet addressed. First is to understand on-chain information in FHIR-blockchain, which refers to the types of FHIR data and/or transactions to be stored inside blockchain. Since on-chain data in blocks is part of blockchain networks, it is theoretically non-changeable, traceable, and transparent. Only a few previous studies shortly described that they used hash, transaction metadata, signature, FHIR profiles as the on-chain information [17]. The other question is architectural features of FHIR-blockchain that leverage the integration. FHIR can be implemented and integrated with a variety of clinical information systems, and the usefulness of blockchain may differ by that. The previous studies have limitations by presenting their implementation only at a conceptual level but lack of business aspects and real world use cases.

To address the gap, we conducted a study to investigate the architectural features of blockchain-FHIR integration to answer the questions. Since there are a very small number of data and references related to the topic of FHIR-blockchain, we approached the qualitative content analysis based on in-depth (individual) / semi-structured interview with informatics experts in academia and industry. All the interviews were recorded, summarized, and analyzed in a structured way. We codified the interview results and derived findings and discussions. As a result, we characterized 1) the types of healthcare data as on-chain data, 2) the architectural features and possible use cases, and additionally discussed legal and busines perspectives of the findings.

In this study, we tried to address the two research questions as below.

What are FHIR information to be stored as on-chain to facilitate benefits of using blockchain in healthcare information exchange?

What are the architectural features and possible business use cases to leverage the benefits of adopting FHIR-blockchain integration and explain the reason why?

Healthcare blockchain is relatively a new technology and the subject of FHIR-blockchain integration only has a few references, which most of them are not real-world implementation but proof-of-concepts. Due to the limitation of lack of data, we decided to try an approach of the qualitative content analysis, that is based on in-depth (individual) and semi-structured interview with interviewees in the diversity of background.

Similar to the limitation of literatures and case studies, there was lack of available expertise to be qualified as an interviewee for the study. Although there were some numbers of researchers / practitioners / system architects having expertise in the areas of either FHIR or healthcare blockchain, but we could find only four domain experts having both. We reached out to the four experts and all of the accepted the interview. Features of the experts are described in Table 1.

Table 1

Interviewee characteristics
Interviewee	Academic background	Position	Year of experience
Interviewee #1	Medical doctor / Radiologist PhD of medical informatics	CEO of a healthcare blockchain company	8 year
Interviewee #2	Computer science / Database manager PhD of computer science	Director of big data center in a research institute	15 year
Interviewee #3	Computer science / Artificial intelligence PhD of computer science	Professor of biomedical informatics	17 year
Interviewee #4	Computer science / SW engineering PhD of medical informatics	Professor of digital healthcare	10 year

Interviewers consist of two researchers: first/corresponding authors of this manuscript and behold backgrounds of medical informatics and medical law and ethics. The interview was designed to perform an hour for each interviewee and consisted of predefined key questions and answers, followed by discussions. The design was validated and qualified by the COREQ (Consolidated Criteria for Reporting Qualitative Research) criteria shown as Table 2.

Table 2

COREQ criteria questions
Domain 1: Research team and reflexivity
Criteria	Question	Answer
Interviewer/facilitator	Which author/s conducted the interview or focus group?	Jaehoon Lee, Sangsook Beck
Credentials	What were the researcher's credentials?	PhD
Occupation	What was their occupation at the time of the study?	Medical informaticist Research professor
Gender	Was the researcher male or female?	One male and one female
Experience and training	What experience or training did the researcher have?	Conducting research on healthcare information
Relationship established	Was a relationship established prior to study commencement?	Yes
Participant knowledge of the interviewer	What did the participants know about the researcher?	Reasons for doing the research
Interviewer characteristics	What characteristics were reported about the interviewer/facilitator?	Background and research interest
Domain 2: study design Theoretical framework
Methodological orientation and Theory	What methodological orientation was stated to underpin the study?	Participant selection
Sampling	How were participants selected?	Purposive
Method of approach	How were participants approached?	Online meetings with Cisco Webex
Sample size	How many participants were in the study?	4
Non-participation	How many people refused to participate or dropped out? Reasons?	None
Setting of data collection	Where was the data collected? e.g. home, clinic,	Workplace (telecommuting operation)
Presence of non-participants	Was anyone else present besides the participants and researchers?	Two recorders (transcript) attended
Description of sample	What are the important characteristics of the sample?	N/A
Data collection Interview guide	Were questions, prompts, guides provided by the authors? Was it pilot tested?	Provided by authors No prior test
Repeat interviews	Were repeat interviews carried out? If yes, how many?	No
Audio/visual recording	Did the research use audio or visual recording to collect the data?	Audio and Visual
Field notes	Were field notes made during and/or after the interview or focus group?	No
Duration	What was the duration of the interviews or focus group?	Approximately an hour
Data saturation	Was data saturation discussed?	No, it was pilot test
Transcripts returned	Were transcripts returned to participants for comment and/or correction?	Yes
Domain 3: analysis and findings
Number of data coders	How many data coders coded the data?	1
Description of the coding tree	Did authors provide a description of the coding tree?	No
Derivation of themes	Were themes identified in advance or derived from the data?	No
Software	What software, if applicable, was used to manage the data?	No
Participant checking	Did participants provide feedback on the findings?	Yes Reporting
Quotations presented	Were participant quotations presented to illustrate the themes / findings? Was each quotation identified? e.g. participant number	No
Data and findings consistent	Was there consistency between the data presented and the findings?	Yes
Clarity of major themes	Were major themes clearly presented in the findings?	Yes
Clarity of minor themes	Is there a description of diverse cases or discussion of minor themes?	Yes

Each interview was performed for an hour and consisted of 1) pre-requisite questions: interviewee’s background, experience, period, in the area of healthcare blockchain, healthcare information exchange, and FHIR, 2) key questions and answers, and 3) brainstorming styled discussion about potential legal and/or business issues. The key questions were designed to identify the minimally required on-chain information and derive appropriate FHIR-blockchain architectures with their use cases. The questions consisted of as following.

What are the baseline information to be stored on-chain to ensure integrity of FHIR based healthcare information exchange?

Amongst the potential data types to be stored on-chain, what can be requested by data ownership (patient) to be removed afterward?

What are legally arguable data types to be stored on-chain?

What are data types impossible to be stored as on-chain?

What is the maximum size of a FHIR transaction while maintaining appropriate performance of blockchain?

Amongst the potential on-chain information, what are required of real-timeliness and what’s the case?

The interviews with four interviewees were conducted in Aug 2020. Explorative content analysis was performed to capture the opinions and perspectives on FHIR blockchain architecture. All interviews were recorded and analyzed in a structured way by two researchers who had been researching FHIR and blockchain technology for more than 1 year, who crosschecked each other’s work to produce the final transcript for analysis. Each researcher repeatedly read and coded the transcription in the in-depth interview, using a bottom-up coding method by grouping a list of similar codes into higher categories. The structuring results of each checked by another [19]. Both researchers then went through categorization comparison and refined of categories. Dominant themes were identified within each category by sorting the statements for each category based on their semantic similarity [19]. The final analyses and interpretation were drawn after reviewing and agreeing upon the interview details. This study was approved by the institutional review board of Severance Hospital [4-2020-0631]) and was carries out in accordance with the Declaration of Helsinki. All participants provided written informed consent after the study procedures, and its potential risks and benefits were fully explained.

Overall response for questions on FHIR Blockchain

An overview of the responses of questions is provided in Table 3. All participants have conducted research related to blockchain or FHIR and have at least 8 years of research experience in the field of medical informatics. The six key questions for identifying the feasibility of the minimally necessary on-chain information and deriving an appropriate FHIR blockchain architecture can be broadly divided into three areas: 1) storage and deletion issues, 2) legal or systematic impossibility issue for registration and 3) technical issues. Further discussions were conducted on the integration of FHIR Blockchain from all participants.

Table 3

Summary of the interviews for each question for deriving an appropriate FHIR blockchain architecture.
Category		Common opinion	Minor opinion
Storage and deletion issues	Baseline information to be stored on-chain	When a blockchain is used for the purpose of checking the integrity of data, the writer, hash, and timestamp are basically saved as baseline information.	The level of stored baseline information is a matter of legal or privacy issues patient rather than size or data type.
	Data types that may be requested to be deleted	If information is stored in the blockchain, it cannot be deleted, so only the minimum amount of information must be uploaded. Medical information, which is the patient's sensitive personal information, must be deleted when requested to be deleted.	It depends on what purpose the blockchain is used for, but in terms of verifying the integrity of the data, I think that the data uploaded on the blockchain cannot be requested to be deleted.
Legal or systematic impossibility issue for registration	Legally arguable data types	It is not appropriate to post information on the blockchain that can track diseases and treatments of specific patients.	All information can be stored except for personal identification numbers (e.g., social security numbers).
	Data types impossible to be stored	Personal identifiable information should be excluded. It is not suitable to register all data collected in the clinical field on the blockchain.	Without blockchain technical limitations, all data can store in blockchain.
Technical issues	Maximum size of a FHIR transaction (with appropriate performance)	Considering the purpose of combining the blockchain and FHIR (integrity and verification of information in transactions) and system cost efficiency, the maximum size is determined at a certain level.	Instead of discussion about the maximum size, we need to think about the direction in which transactions can be made with the smallest possible size.
	What is required of real-time synchronization and what’s the case?	The identifier that verifies the integrity of the data must maintain real-time.	There are no cases where real-time synchronization is required (If real-time synchronization is needed, it can be sufficiently implemented with other methods such as DB or API).
Further discussion on the FHIR blockchain	Architecture and scenario	Blockchain is a technology, and it seems that there are various features depending on the applied domain or FHIR scenario. Detail architecture and scenario for FHIR blockchain is required.	There are cases in which the technology provided by the blockchain and legal provisions (for example, the right to be forgotten) conflict. Therefore, the blockchain FHIR architecture can be determined according to the selection of an appropriate medical area.

In the blockchain storage and deletion issue, all participants had the common opinion that writer, hash, and timestamp must be recorded as the baseline information to be stored on-chain. As a minor opinion, baseline information should be defined in terms of legal or privacy issues of the patient not technical issues of blockchain or FHIR. Among the items registered in the blockchain, there were two common opinions on items that could be requested to be deleted. First, because it cannot be deleted due to blockchain technology, the minimum information must be registered from the beginning. Secondly, sensitive personal information should be deleted upon request. As a minor opinion, if the purpose of using the blockchain is to verify the integrity of medical data (document or transaction), it should not be deleted even if there is a request for deletion.

In the impossibility issue for registration of blockchain, all participants agreed that it is legally and systematically difficult to register patient identifiable information on the blockchain. Or there was a minor opinion that only the minimum amount of information should be registered on FHIR Blockchain architecture as it is impossible to delete it after registration.

In the technical issues, when asked about the maximum size of transaction information that can be stored, the main opinion was that it should be calculated according to the purpose of use rather than the answer to the technical size. In the question of the type of data that should be guaranteed for real-time synchronization, most participants agreed with the identifier that supports connectivity with other data. Conversely, one participant argued that none of the data types in the blockchain require real-time synchronization due to the nature of the blockchain, which is a shared ledger.

In Further discussion on the FHIR blockchain, although all participants are positive about the architecture for integration of the blockchain and FHIR, they argued that the architecture should be configured differently depending on which medical domain will be used. For example, it can be applied in various domain such as EMR, cancer registration, and data exchange, but the functions or system configurations required for each area will be different. There was a minor opinion that the blockchain technology itself could conflict with the current legal provisions.

On-chain information in FHIR Blockchain

We categorized on-chain information in FHIR blockchain to the three levels: basic, advance, and ideal environments (Table 4). The basic level is literally a justification of “why use blockchain?”, as opposed to the ideal environment where “can do anything” based on the assumption that legal and technical constraint do not exist. Therefore, a real world FHIR-blockchain implementation may find an optimized level of on-chain information depending on its project purpose, restrictions, and trade-off amongst variables. All the interviewees agreed that the minimum information to identify a FHIR transaction should consists of hash which is the key identifier of all transactions, a writer who has the authority to record the blockchain, and a time stamp to record when the information is stored in blocks. The data types in the ideal environment may include several parts of the exchanged information, but even in that case it doesn’t necessarily have to store all the contents in the transactions, that will result in waste of bandwidth and blockchain performance.

Table 4

On-chain information type for storing the blockchain with FHIR transaction
Level	Data type	Feature
Basic information type for FHIR transaction	hash: a key identifier of transaction Writer: an entity has right to write on blocks Time stamp	Minimum set of information to identify a FHIR transaction
Advance information types for FHIR transaction with appropriate performance of blockchain	All of the above AND Reference pointer (location to physical address of transaction data) Message header (Request / Response) Receiver’s signature Receiver’s log of message read	Basic information of a FHIR transaction to verify and trace senders, receivers, and location of data
Ideally useful information type without appropriate performance of blockchain	All of the above AND Metadata of transaction: FHIR resource ID, part of FHIR Resource instance, size of transaction / message, FHIR profile	Include part of FHIR message that can identify and reproduce transactions

Architectures for FHIR-blockchain integration

The qualitative content analysis revealed the four architectures of FHIR-blockchain integration shown as Figure 1. The architectures commonly assume existence of multiple EHRs that provide clinical data to transform to FHIR transactions and be consumed by client applications (e.g. mobile application, web site, etc.). Depending on the architecture, FHIR servers may or not be integrated with EHRs and employ its own data storage for FHIR message instances. In the middle of the figure describes potential on-chain data types from FHIR transactions. Details of the architectures and on-chain information are described in Table 5.

Table 5

Feature of FHIR-Blockchain architectures
Architecture	Feature	Use case
#1	A FHIR server runs on each EMR system, doesn’t have own data storage, and handles mapping and conversion of FHIR messages from EMR data.	A common architecture for implementing open FHIR APIs for healthcare information exchange and application development in hospitals
#2	A FHIR server runs on each EMR system, has its own data storage. Data may be prepopulated and preprocessed inside the FHIR databases (i.e. caching) Real-time processing of services to read/write EMR data Data freshness is not guaranteed due to latency between EMR and FHIR databases	When need of certain preprocessing or conversion of data before transaction Latency is allowed to some level (near real-time)
#3	A FHIR server functions as hub and performs mapping from multiple EMRs (may need a lot of bandwidth) A FHIR server doesn’t employ a data storage and intermediates real time processing of services for read/write of EMR data	Real time services such as CDS (Clinical Decision Support) Hooks In case storing data outside healthcare institute is legally infeasible
#4	A FHIR server functions as a hub and performs mapping data from multiple EMRs. A FHIR server employs a storage and data may be prepopulated and preprocessed in the FHIR databases.	Service allowed of data latency (e.g. document retrieval service)

Principal findings

This study was conducted with medical informatics experts with extensive research experience in the field, and we analyzed the various expectations and concerns with FHIR Blockchain integration. This study is the first study to derive an architecture and scenario for the integration of FHIR Blockchain by interviewing and analyzing the expert opinion.

Architectural feasibility

The interviewers and interviewees discussed the architectural feasibility and possible use cases of the proposed FHIR-blockchain architectures. Major use cases of the architectures discussed included a nationwide patient registration (identifier) service, healthcare information exchange between hospitals, infectious disease control, PHRs, and secondary use of clinical data. Even though it wasn’t included in the proposed four architectures, an architecture with three stakeholders (information sender, receiver, and consent provider) would be also feasible if aligned with FHIR-blockchain integration.

Architecture #1 and #3 may be appropriate when implemented in applications of PHRs, as the nature of them is decentralized data. Architecture #4 may be efficient when it is implemented in the applications such as the registered patient management at national level, infectious disease control, and secondary data use. A centralized information system employing its own internal databases may need the use cases such as management of cancer, rare disease, organ donation and transplant, and end-stage renal disease. Architecture #2 is appropriate for data exchange between entities, including patient record and document exchange between hospitals, peer to peer (P2P), and patient transfer request/response.

Legal issue

The interviewees agreed that possibility of on-chain data types will be limited by not technical constraints but privacy law and regulations. Legally speaking a patient health data belongs to the patient, and the data must be removed from any system if requested by the patient. This means we must not store any patient data as on-chain, simply because once it is stored it can’t be removed due to the nature of blockchain. Therefore, the potential on-chain data types will be limited as key information of FHIR transaction besides patient data, that includes hash, senders and receivers, signature, timestamp, etc.

Controversy about blockchain

Although blockchain has been validated of its functional feasibility to store and maintain data in a secured, distributed, and unchangeable way, the interviewees appealed common concerns about justification of using blockchain in the same context of the hope or hype question about blockchain in healthcare [18]. Blockchain is known as a costly technology; it consumes huge computing power and network bandwidths to maintain its unique features. Investing same amount of computing resources into the traditional securities may outperform that of blockchain, yet it hasn’t been clearly investigated as a comparative analysis. Usefulness of blockchain has to be thoroughly analyzed before adoption, since use cases and requirements in the healthcare domain is diverse and complicated in nature.

Promising area

Considering one of the successes of using blockchain was in the area needed “trust” such as cryptocurrency and smart contract, it is predictable that FHIR-blockchain would be useful in the use cases required of higher trust in transactions. The interviewees mentioned possible use cases including infectious disease control, psychoactive drug management, information exchange required of receiver’s confirmation, patient consent management (clinical trials, etc.), advance directive, life sustaining treatment, and payment system.

Our qualitative content analysis based study well derived the architectural features of FHIR-blockchain, their potential issues, and additionally discussed consideration in the legal perspectives. Although FHIR-blockchain has been considered a promising solution to support healthcare information exchange, it should be clarified as to how it aligned with business requirements. A detailed and/or tailored guidelines of implementation may be needed to validate the proposed benefits of using the FHIR-blockchain architecture.

Conflict of Interest

No conflict of interest to disclose

Wright CS. Bitcoin: A Peer-to-Peer Electronic Cash System. SSRN 2019 Oct 19:1-10 [FREE Full text] [doi:10.2139/ssrn.3440802]
Liu H, Crespo RG, Martínez OS. Enhancing Privacy and Data Security across Healthcare Applications Using Blockchain and Distributed Ledger Concepts. Healthcare (Basel). 2020 Jul 29;8(3):E243.
Patel V. A framework for secure and decentralized sharing of medical imaging data via blockchain consensus. Health Informatics J 2019 Dec 25;25(4):1398-1411.
McFarlane C, Beer M, Brown J, Prendergast N. Patientory: A Healthcare Peer-to-Peer EMR Storage Network v1. Entrust Inc. 2017 Apr. URL: https://patientory.com/wp-content/uploads/2017/04/Final-Patientory_Whitepaper.pdf [accessed 2020-07-30]
Li H, Zhu L, Shen M, Gao F, Tao X, Liu S. Blockchain-Based Data Preservation System for Medical Data. J Med Syst 2018 Jun 28;42(8):141-112.
Zhang P, White J, Schmidt D, et al. FHIRChain: Applying Blockchain to Securely and Scalably Share Clinical Data. Comput Struct Biotechnol J 2018;16:267-278.
Hylock RH, Zeng X. A Blockchain Framework for Patient-Centered Health Records and Exchange (HealthChain): Evaluation and Proof-of-Concept Study. J Med Internet Res. 2019 Aug 31;21(8):e13592.
Esmaeilzadeh P, Mirzaei T. The Potential of Blockchain Technology for Health Information Exchange: Experimental Study From Patients' Perspectives. J Med Internet Res. 2019;21(6):e14184.
Rahmadika S, Rhee K. Blockchain technology for providing an architecture model of decentralized personal health information. Int J Engin Bus Manage 2018 Aug;10.
Roehrs A, da Costa CA, da Rosa Righi R. OmniPHR: A distributed architecture model to integrate personal health records. J Biomed Inform 2017 Jul;71:70-81.
Roehrs A, da Costa CA, da Rosa Righi R, et al. Analyzing the performance of a blockchain-based personal health record implementation. J Biomed Inform 2019 Apr;92:103140.
Park YR, Lee E, Na W, 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
Sung M, Park S, Jung S, et al. Developing a Mobile App for Monitoring Medical Record Changes Using Blockchain: Development and Usability Study. J Med Internet Res. 2020;22(8):e19657.
Maslove DM, Klein J, Brohman K, et al. Using Blockchain Technology to Manage Clinical Trials Data: A Proof-of-Concept Study. JMIR Med Inform 2018 Dec 21;6(4):e11949
Wong DR, Bhattacharya S, Butte AJ. Prototype of running clinical trials in an untrustworthy environment using blockchain. Nat Commun 2019 Feb 22;10(1):917.
Kuo TT, Kim HE, Ohno-Machado L. Blockchain distributed ledger technologies for biomedical and health care applications. J Am Med Inform Assoc. 2017 Nov 1;24(6):1211-1220.
Lee AR, Kim MG, Kim IK. SHAREChain: Healthcare data sharing framework using Blockchain-registry and FHIR. 2019 IEEE BIBM, San Diego, CA, USA, 2019, 1087-1090.
El-Gazzar R, Stendal K. Blockchain in Health Care: Hope or Hype?. J Med Internet Res. 2020;22(7):e17199.
SCHILLING, Jan. On the pragmatics of qualitative assessment: Designing the process for content analysis. European journal of psychological assessment, 2006, 22.1: 28.

No competing interests reported.

Deriving Key Architectural Features of FHIR-BlockChain Integration through the Qualitative Content Analysis

Status:

Version 1

Abstract

Figures

Introduction

Method

Result

Overall response for questions on FHIR Blockchain

On-chain information in FHIR Blockchain

Architectures for FHIR-blockchain integration

Discussion

Principal findings

Architectural feasibility

Legal issue

Controversy about blockchain

Promising area

Conclusion

Declarations

Conflict of Interest

references

Additional Declarations

Status:

Version 1