Critical Dimensions of Blockchain Technology Implementation in the Healthcare Industry: An Integrated Systems Management Approach

Abstract

In the digital era, almost every system is connected to a digital platform to enhance efficiency. Although life is thus improved, security issues remain important, especially in the healthcare sector. The privacy and security of healthcare records is paramount; data leakage is socially unacceptable. Therefore, technology that protects data but does not compromise efficiency is essential. Blockchain technology has gained increasing attention as it ensures transparency, trust, privacy, and security. However, the critical factors affecting efficiency require further study. Here, we define the critical factors that affect blockchain implementation in the healthcare industry. We extracted such factors from the literature and from experts, then used interpretive structural modeling to define the interrelationships among these factors and classify them according to driving and dependence forces. This identified key drivers of the desired objectives. Regulatory clarity and governance (F2), immature technology (F3), high investment cost (F6), blockchain developers (F9), and trust among stakeholders (F12) are key factors to consider when seeking to implement blockchain technology in healthcare. Our analysis will allow managers to understand the requirements for successful implementation.

1. Introduction

Recently, blockchain (BC) technology has attracted increasing attention from industry and academia. BC technology allows users to preserve, certify, and synchronize the contents of a transaction ledger, which are available to multiple users. Transactions are decentralized; the data are not controlled by a third party. Within the system, transactions are timestamped in a ledger; data modifications/alterations are generally impossible without changing the ledger. Figure 1 shows the key components of a BC.

Figure 1. Components of a BC.

BC technology ensures that trust and security are maintained during any transaction [1,2]. The healthcare, financial, and educational industries perceive the advantages afforded. Figure 2 describes the working principles of a BC.

Figure 2. Principles of a BC: a step-by-step flowchart.

As BC technology reduces fraudulent activity and protects privacy, healthcare providers would like to implement it [3]. Breaches of healthcare data are increasing rapidly; in 2017, the number of people affected exceeded 300 records; from 2010 to 2017, this number rose to 37 million records [4,5]. There are growing concerns regarding healthcare data sharing, secure data storage, and data ownership, as digitization becomes the norm [3]. A BC ensures transparency, security, and speed during data storage and distribution; it also solves the security, privacy, and integrity issues that arise in the field of healthcare technology [6,7,8,9]. A BC is decentralized, thus eliminating the accuracy and security concerns associated with dependence on a central authority. BC technology is inter-operator-based, ensuring a high standard of data exchange among healthcare associates. This boosts innovation, coordination among associates, market competition, and care quality [10,11,12,13].

In the past (when no BC was available), healthcare data interoperability among different institutions was categorized as push, pull, and view. In the push model, data transfer is possible between two providers; no third provider has access. For example, data transfer is possible between departments within the same hospital; however, data cannot be accessed by a different hospital, regardless of patient transfer to the other hospital. In the push model, it is very difficult to ensure data integrity during transfer. During a pull, one provider informally seeks data from another provider; there is no standardized audit trail. For example, an orthopedic surgeon can informally ask a cardiologist for information. During a view, one provider sees the record of another provider. For example, a surgeon can access an X-ray taken in the emergency department. The security approaches are not based on the relationship that exists between a patient and a provider; thus, they are largely ad hoc. The relevant policies are also subject to the laws of the local and federal governments.

A BC-based model for a healthcare market creates a new dimension by considering the safety of data integrity and the use of standardized formal contracts for data accession. When an electronic health record (EHR) (which stores data from multiple workers) is accessed, it is difficult to determine the identity of the person who performed a task and when the work was performed. BC timestamps all work and identify the worker; the data are also distributed to all participating nodes. If a modification or update appears in any node, this is distributed to all nodes and is thus visible systemwide. Data integrity is maintained without the need for human intervention [14]. Although BC affords many benefits, it has never been implemented in real-time healthcare. Adoption is inevitable.

Our literature review revealed only limited empirical evidence for BC use, despite its many possible benefits [15]. Very few studies have investigated the benefits, deficits, and functionalities of BC technology [16,17,18,19]. Most studies have sought to explain how BC works and to determine its current real-world implementation status [20]. However, critical factors affecting BC implementation in healthcare have not been addressed; knowledge of these factors is essential. Thus, we sought to identify these factors. Our findings can remove the confusion associated with real-time BC implementation. We offer a better understanding of the challenges imposed by implementation of BC technology in healthcare and the factors affecting such implementation. Our objectives are:

(1)

To identify factors that critically impact the implementation of BC technology in the healthcare industry;

(2)

To build a structured framework that depicts the interrelationships among such factors;

(3)

To define the motivation and reliance powers of such factors.

Based on past works and the opinions of experts in BC technology, we define 13 factors that greatly affect the implementation of such technology in healthcare. We used interpretive structural modeling (ISM) to explore the relationships among such factors. We performed Matrice d’Impact Croise’s Multiplication Appliquée a UN Classement (MICMAC) analysis to define the motivation and reliance powers of the factors. We sought to encourage industries that wish to implement BC technology.

The remainder of this paper is organized as follows. The literature regarding applications of BC technology in healthcare is reviewed in Section 2. Section 3 describes the methods used to achieve our research objectives. The research approach is discussed in Section 4. Managerial implications are discussed in Section 5. Practical implications are discussed in Section 6. The outcomes are summarized and conclusions are drawn in Section 7.

2. Related Works

This section is divided into two subsections. Past works regarding applications of BC in healthcare are covered in the first subsection. The second subsection discusses critical factors influencing BC implementation in healthcare.

2.1. Past Studies Regarding Applications of BC in Healthcare

BC use in healthcare scenarios has focused on smart healthcare management, user-oriented medical research, and prevention of drug counterfeiting. In terms of healthcare management, health networks allow medical experts to obtain detailed information regarding current patient status (described in the reports of physicians or healthcare centers, as well as various studies). Analysis of medical records creates an ecosystem that transparently reduces the merit costs of patient records. Moreover, medical experts can monitor the treatment activities of stakeholders, such as physicians and healthcare centers. These systems facilitate insurance claim settling if insurance companies are permitted (by patients) to access data. As healthcare records are increasingly stored digitally, security elements must be incorporated in such digital systems. Any digital platform must be scalable and adaptable, thus capable of handling large numbers of records and adaptable to many types of changes [21]. One practical solution is Live Interactive FramE (LIFE), which ensures that all media streaming in a healthcare domain are appropriately secured with minimal video quality loss during immersive applications [22].

In the context of user-oriented medical research, several authors have focused on the workings and structures of health banks; these studies have led to major breakthroughs in medical research. A company may accumulate data from wearable devices and may provide a user platform for data storage and management. The stored medical data facilitate high-quality research by trusted organizations. Patients are not financially compensated for their data.

In terms of preventing drug counterfeiting, various authors have shown that the typical counterfeiting level today ranges from approximately 10% to 30% in developed countries. Counterfeiting is not confined to lifestyle medicines or drugs; it can include drugs that treat major medical issues, such as cardiovascular diseases. Recently, the Hyperledger research network described how drug counterfeiting could be reduced by timestamping. This problem could be addressed using a BC: all data have an address based on the stored information, thereby preventing drug counterfeiting [23].

Other authors [24] identified a simple but very robust BC system for patient data storage by the healthcare sector. The system encourages the storage of all data (beginning at birth), including lipid profile data yielded by wearable devices and magnetic resonance imaging information. All information is stored in a data lake, which facilitates simple querying, advanced analytics, and machine learning. This is a simple form of data warehousing; the stored materials include documents, images, .pdf files, and key values. The BC of each user serves as an index catalog containing a unique identification number, an encrypted link to the health record stored in the lake, and a timestamp that shows all data modifications. The user enjoys robust access control and can allow or restrict access using an audit log that shows every visit to the data repository. Such systems will greatly aid medical professionals (ranging from students to doctors) and governmental agencies. The data shared from the lake are tagged with the unique patient identification numbers, are up-to-date and accurate, and can be used for longitudinal healthcare research.

Electronic records contain data from wearable devices, medical records, and/or medical imaging; all are private. Cloud storage in a central regulatory database may be associated with data leakage; unauthorized data transfer can be avoided by enabling a BC architecture wherein a user or a patient has full control over data access by third parties (expert consultants or medical researchers). BC use in healthcare will aid in the development of a consensus system that verifies the appropriateness of prescribed medication [25].

As healthcare data are very sensitive, the type of BC to be used is critical. One report [26] discussed the various types of BC available, their bases, and their uses in terms of maintenance, validation, and storage of medical data. Out-of-the-box consortium BCs were considered optimal; both the node owner and miners control access. A consensus can be determined regarding the optimal number of validations imparted by a healthcare provider, a clinic, or an insurance company; the stored data are thus very accurate.

Although BC implementation in the healthcare sector is vital, this has not yet happened. It is essential to define factors that would aid implementation. This is the topic of the next subsection.

2.2. Crucial Factors Affecting Implementation of BC in Healthcare

Here, we review works regarding crucial factors that affect BC implementation in healthcare. Ekblaw et al. [14] regarded data security and privacy assurance as a major concern. Although BC data are safely stored, Shi et al. [27] presumed that healthcare data in a public database would be vulnerable to statistical attack. Thus, frequent encryption key changes would be required, increasing key storage costs. To address this problem, Zhao et al. [28] developed a smart key recovery scheme based on a body sensor network. In this system, there is no need for a stored encryption key. If a key must be recovered, it is retrieved by the body sensor network.

Khan et al. [29] stated that medical data interoperability was another key barrier; medical data must be communicated, shared, and used by employing various information communication technologies. Although creation of data interoperability has been discussed by several authors [11,30], its implementation remains a major concern.

Agarwal and Prabakaran [31] presumed that data fragmentation could compromise EHRs. Thus, there is a need to meticulously maintain EHRs [32]. Errors compromise diagnosis and patient safety [33]. Data unavailability is unacceptable, thus posing a problem when implementing BC technology. The compatibility of existing information with BC technology is also critical; incompatibility reduces system performance. Incompatible information technology interfaces [23] greatly slow the system. The deployment and maintenance of dedicated technology are essential components [34].

Regulation plays a major role in healthcare; lives are at stake [1]. Schwerin [35] questioned the compatibility of BC with general data protection regulations. BC must protect consumer rights according to law [36]. Trust is a critical consideration when using BC; data are decentralized, transparent, and uploaded [37]. Illegal bitcoin activities have compromised trust in the technology [38]. However, in the healthcare sector, the technology can never be completely trusted due to the demand for healthcare data privacy [39,40,41,42]. Regulators have stated that a key issue preventing large-scale implementation of BC technology is the lack of standardization. Only a few well-known infrastructures are available [38]. Different countries seek to apply BC in various manners. For example, Estonia wishes to use BC to award e-residency to new citizens [43]. Other countries seek to use BC for transparent taxation and other social needs [44]. Standardization is urgently required [45].

The creativity and intricacy of BC increase adoption costs. Furthermore, there are few service providers, which leads to increasing costs [38]. As BC implementation reduces transaction costs [46], the initial costs may be worthwhile. However, the technology may not be suitable for small- and medium-size industries that lack workers with skills to manage the system [38]. There is a need for more skilled operators.

BC became well-known due to bitcoin, but disagreements are increasing in the bitcoin community due to frequent code forking, supporting the notion that the technology is immature [47]. Many technical limitations remain [38].

Scalability is essential for robust system performance. In its present form, the network of a public BC is comparatively expensive and slow and thus difficult to adopt at a large scale. However, new scaling techniques such as plasma chains, lightning networks, zk-snarks, and state channels enhance performance and scalability (both in and out of the healthcare context) [1].

Although BC is newer than the Internet of Things (IoT), cloud computing, and artificial intelligence (AI), the IoT exhibits many security issues. BC has greatly improved IoT applications, restoring trust [48]. The use of AI in healthcare affords excellent accuracy and precision, facilitating rapid decision-making. In the current coronavirus disease 2019 era, AI-based decisions categorize patients within a few minutes, greatly aiding clinicians. However, privacy remains important; patients fear that their data may be misplaced during AI analysis in the cloud. Prior to BC, cloud security was enhanced using specific applications [49,50,51]. After BC integration, data can be stored securely. As each transaction is recorded, patients can easily identify where the data are used. All involved groups experience benefits [52]. The integration of BC into the cloud resolves issues regarding location-based storage and analysis, while guaranteeing security [53]. BC must be integrated with more recent cutting-edge technologies. All industries accept that modern technology will render them smarter, but safety concerns remain. BC is already safe; the addition of other technologies can render it safer, faster, energy-saving, and cheaper [54,55,56].

3. Solutions

We first identified critical factors affecting BC introduction; we reviewed past works and sought 15 expert opinions (inputs to structured self-interaction matrices (SSIMs)). These opinions were collected during a workshop concerning digital technology in the healthcare sector held at KIIT University, Bhubaneswar, India, in 2020. The 15 experts included nine senior medical practitioners with at least 10 years of experience in reputable hospitals with digital platforms hosting patient records and managing medicine supplies, as well as six academics with at least 10 years of research experience in BC (all academics were at or above professor/associate professor level in their medical colleges/universities). There was no limit on the number of experts that had completed S exploring remanufacturing and green campus operations (Singhal et al., 2020 [57], Gholami et al., 2020 [58]); 10 had completed SIMs concerning researcher selection (Nilashi et al., 2019 [59]). Our 15 experts were thus adequate. Next, ISM was used to develop a baseline model of associations among critical factors, and MICMAC analysis was performed to group the factors. ISM seeks to determine relationships among factors identified through literature review or expert opinion as an issue or a problem (Jharkharia and Shankar 2005 [60], Ravi and Shankar 2005 [61], Raj and Attri 2011 [62]). ISM techniques include brainstorming, nominal group techniques, and face-to-face interviews, yielding expert views regarding how to develop a contextual relationship among selected key factors (Ravi et al., 2005 [63], Barve et al., 2007 [64], Hasan et al., 2007 [65], Raj et al., 2007 [66]). Here, we addressed the complex barriers to BC implementation in healthcare. Factors determined through a literature review were reviewed by experts. No limit was imposed on the number of factors (Singhal et al., 2020 [57], Nayak et al., 2019 [67]). Table 1 lists the 13 factors identified and Table 2 lists the ISM steps. The flowchart of the solution (i.e., research framework and sequential steps) is shown in Figure 3. The critical dimensions of BC in healthcare commences with SIM completion and concludes with MICMAC policy recommendations. A strong correlation is evident between the ISM model and the critical factors identified.

Table 1. Numbers of factors evaluated in various reports.

Source	No. of Factors Used	Research Objective
Singhal et al. 2020 [57]	15	Factors affecting electronic remanufacturing
Nayak et al. 2019 [67]	14	Factors affecting rail safety performance
Ahmed et al. 2019 [68]	15	Benchmarking of significant factors in seismic soil liquefaction
Nayak et al., 2018 [69]	17	Factors affecting nontechnical human skills in engineering
Aich and Tripathy, 2014 [70]	13	Factors affecting green supply chain management
Tripathy et al., 2013 [71]	14	Factors affecting manufacturing R&D

Table 2. ISM steps.

Steps	Focus
1: Establishment of a structural self-interaction matrix (SSIM)	Define pairwise relationships among identified critical dimensions of healthcare BC technology
2: Create a reachability matrix	Determine driving and dependent factors
3: Level partitioning	Define structural levels (factor level partitioning)
4: ISM modeling	Develop an ISM model using a reachability matrix and level partitioning
5: MICMAC analysis	Classify critical dimensions of healthcare BC technology into four categories (drivers, dependents, autonomous factors, and linked factors) via MICMAC analysis

Figure 3. Flowchart of solution methodology.

3.1. Data Collection

We reviewed all BC papers in Web of Science and Scopus in terms of critical factors influencing the adoption of BC in healthcare. With assistance from experts, we selected the 13 factors listed in Table 3.

Table 3. Factors affecting the implementation of BC in healthcare.

Code	Factor	References
F1	Data unavailability (DU)	[33,34,36]
F2	Regulatory clarity and governance (RCG)	[38,39,40]
F3	Immature technology (IMT)	[42,51]
F4	Safer and smarter organization (SSO)	[52,53,54,55,56,57]
F5	Compatibility with other IT systems (CIT)	[36,37]
F6	High investment cost (HIC)	[42,50]
F7	Privacy and security of stored data (PSD)	[27,28,29]
F8	Scalability and accessibility (SA)	[1,42]
F9	Blockchain developers (BD)	[42]
F10	Interoperability of electronic health records (IEH)	[30,32,34]
F11	Data standardization (DS)	[42,47,48,49]
F12	Trust among stakeholders (TAS)	[41,42,43,44,45,46]
F13	Encouragement of integration (EI)	[50,53,54,55,56,57]

3.2. ISM

ISM is old and widely used by researchers in knowledge management, energy conservation, supplier selection, and green supply chain management; it is also used by strategic decisionmakers in various organizations [72,73,74]. ISM seeks to recognize/construct associations between factors affecting decision-making when a particular problem arises, then to solve the problem by considering the driving and dependency powers of each factor [75]. The framework features associations among factors, as identified by experts [76]. Fewer experts are required, compared with structural equation modeling or the Delphi method. ISM nonetheless builds models that solve decision-making problems [77,78]. Table 4 lists the various applications of ISM. Modeling proceeds as follows: (1) recognition of relevant factors based on past studies and expert opinion; (2) development of an SSIM and then a reachability matrix; (3) creation of a partition level table using a reachability matrix; (4) characterization of relationships among various factors; and (5) identification of uncertainties and consequent modifications.

Table 4. Applications of ISM.

Techniques	Application
ISM	Adoption of IoT services [70]
ISM	Challenges posed by BC adoption within the Indian public sector [79]
ISM	BC as a disruptive technology in the construction industry [80]
ISM and DEMATEL	Modeling BC-enabled traceability in an agriculture supply chain [81]
ISM	Factors influencing lean implementation in healthcare organizations [82]

3.2.1. The SSIM

The SSIMs completed by experts served as the ISM inputs. The contextual relationships among the 13 factors were determined by the majority opinions of the 15 experts expressed in a brainstorming session conducted during a 2020 workshop. The contextual relationships were finalized after considering the nature of each problem, the objective, and the majority opinion concerning the relationships between factors. The contextual association between two elements (i and j) is represented in one of four manners: (a) if i influences j, this is represented by “V”; (b) if j influences i, this is represented by “A”; (c) if i and j influence each other, this is represented by “X”; and (d) if i and j are independent, this is represented by “O”. For example, the interoperability of electronic health records F10 (IEH) influences the BC developers F9 (BD); the symbol used is V. Compatibility with other IT systems F5 (CIT) influences high investment cost F6 (HIC); the symbol used is A. The interoperability of electronic health records F10 (IEH) and privacy and security of storage data F7 (PSD) interact; the symbol used is X. Scalability and accessibility F8 (SA) has no relationship with data unavailability F1 (DU); the symbol used is O. The SSIM summary is presented in Table 5. The reachability matrix associated with the SSIMs is addressed below.

Table 5. SSIM summary.

	F1	F2	F3	F4	F5	F6	F7	F8	F9	F10	F11	F12	F13
F1		A	A	V	O	A	V	O	A	V	O	A	V
F2			V	V	V	V	V	V	V	V	V	V	V
F3				V	V	A	V	V	A	V	V	A	V
F4					A	A	A	A	A	A	A	A	A
F5						A	V	O	A	V	O	A	V
F6							V	V	O	V	V	X	V
F7								A	A	X	A	A	X
F8									A	V	O	A	V
F9										V	V	O	V
F10											A	A	X
F11												A	V
F12													V

3.2.2. Reachability Matrix

The four SSIM representations, V, A, X, and O, were replaced by 1 or 0 in a reachability matrix, as follows: (a) the symbol “V” in the (i, j) position of the SSIM matrix is substituted by 1 and 0 in the (i, j) and (j, i) positions of the reachability matrix; (b) the symbol “A” in the (i, j) position of the SSIM matrix is substituted by 0 and 1 in the (i, j) and (j, i) positions of the reachability matrix; (c) the symbol “X” in the (i, j) position of the SSIM matrix is substituted by 1 in both the (i, j) and (j, i) positions of the reachability matrix; and (d) the symbol “O” in the (i, j) position in the SSIM matrix is substituted by 0 in both the (i, j) and (j, i) positions of the reachability matrix. Next, the transitivity of the reachability matrix was checked. Transitivity means that if factor F1 influences F2 and F2 influences F3, then F1 impacts F3. If the position (i, j) of F1 impacts F3, the value becomes 1. The driving power (DVP) of a factor is calculated by adding all values in the accommodating row and the dependence power (DNP) is calculated by adding all values in the accommodating column. After considering transitivity, the final version of the reachability matrix is shown in Table 6. The subsequent step (i.e., partition of different levels) uses the reachability matrix.

Table 6. Reachability matrix.

	F1	F2	F3	F4	F5	F6	F7	F8	F9	F10	F11	F12	F13	DVP
F1	1	0	0	1	1	0	1	0	0	1	0	0	1	5
F2	1	1	1	1	1	1	1	1	1	1	1	1	1	13
F3	1	0	1	1	1	0	1	1	0	1	1	0	1	9
F4	0	0	0	1	0	0	0	0	0	0	0	0	0	1
F5	0	0	0	1	1	0	1	0	0	1	0	0	1	5
F6	1	0	1	1	0	1	1	1	0	1	1	1	1	11
F7	0	0	0	1	1	0	1	0	0	1	0	0	1	4
F8	0	0	0	1	1	0	1	1	0	1	0	0	1	5
F9	1	0	1	1	1	0	1	1	1	1	1	0	1	10
F10	0	0	0	1	1	0	1	0	0	1	0	0	1	4
F11	0	0	0	1	0	0	1	0	0	1	1	0	1	5
F12	1	0	1	1	1	1	1	1	0	1	1	1	1	11
F13	0	0	0	1	0	0	1	0	0	1	0	0	1	4
DNP	6	1	5	13	6	3	12	6	2	12	6	3	12	1

3.2.3. Level Partition

The antecedent and reachability sets for each element were developed based on the reachability matrix [83]. The reachability set contains the factors themselves and factors impacted by other factors, and the antecedent set consists of the factors themselves and factors impacting those factors. The intersection set is the group of elements common to the antecedent and reachability sets. The procedure was iterated; when the antecedent and reachability sets were equal, the top factor was identified. For example, level I is occupied by F13 due to the equality of the antecedent and reachability sets. Five iterations were performed when identifying the level of a factor. The level partition is shown in Table 7. All 13 factors are split into six levels. F2 occupies the sixth level and F13 occupies the first level; the other factors lie between these levels.

Table 7. Level partition.

Factors	Reachability Set	Antecedent Set	Intersection Set	Level
F1	1,4,7,10,13	1,2,3,6,9,12	1	III
F2	1,2,3,4,5,6,7,8,9,10,11,12,13	2	2	VI
F3	1,3,4,5,7,8,10,11,13	2,3,6,9,12	3	IV
F4	4	1,2,3,4,5,6,7,8,9,10,11,12,13	4	I
F5	4,5,7,10,13	2,3,5,6,9,12	5	III
F6	1,3,4,5,6,7,8,10,11,12,13	2,6,12	6,12	V
F7	4,7,10,13	1,2,3,5,6,7,8,9,10,11,12,13	7,10,13	II
F8	4,7,8,10,13	2,3,6,8,9,12	8	III
F9	1,3,4,5,7,8,9,10,11,13	2,9	9	V
F10	4,7,10,13	1,2,3,5,6,7,8,9,10,11,12,13	7,10,13	II
F11	4,7,10,11,13	2,3,6,9,11,12	11	III
F12	1,3,4,5,6,7,8,10,11,12,13	2,6,12	6,12	V
F13	4,7,10,13	1,2,3,5,6,7,8,9,10,11,12,13	7,10,13	II

3.2.4. ISM

The ISM of Figure 4 was developed based on the digraph and level partition table. A digraph exemplifies the interrelationships among elements at edges and nodes. Digraphs remove the transitive relationships between elements. The ISM is extracted from the combinative information of the digraph [84].

Figure 4. The ISM.

3.3. MICMAC Analysis

MICMAC requires factor dependence and driving powers as inputs [85] and then categorizes the factors into four types (Figure 5). Autonomous variables (factors with weak dependence and driving powers) are shown in the first quadrant. Dependent variables (factors with strong dependence but weak driving powers) are shown in the second quadrant. Linkage variables (factors with strong dependence and driving powers) are shown in the third quadrant. Driving variables (factors with weak dependence powers but strong driving powers) appear in the fourth quadrant [66].

Figure 5. MICMAC analysis.

4. Results and Discussion

We systematically analyzed and constructed the relationships among factors affecting the adoption of BC in healthcare. We derived factor dependence and driving powers through MICMAC analysis. We first identified 13 critical factors affecting the adoption of BC in healthcare (Table 1). Experts from academia and industry chose these factors. We used ISM to construct the model. The ISM split all factors into six levels. Regulatory clarity and governance (F2) (at the bottom of the hierarchy) was the key driver of BC adoption in healthcare. Daluwathumullagamage and Sims found that BC would ensure better corporate governance if development was accompanied by changes in regulatory frameworks [86]. Healthcare industries must encourage governments to regulate appropriately; BC use is essential. Level IV included trust among stakeholders (F12), high investment cost (F6), and BC developers (F9); all were strong drivers of adoption. Senior healthcare managers must enthusiastically adopt BC and consumers must understand the great benefits afforded by BC use. Gomez-Trujillo et al. emphasized that BC guarantees trust and transparency; if all individuals, industries, and other stakeholders maintain confidence in BC, long-term success is ensured [87]. Koster and Borgman found that BC adoption required the support of senior authorities and trust among partners [88]. Level IV contained only immature technology (F3), which strongly influenced BC adoption. BC is new, not standardized, and has seldom been implemented in governmental agencies. Compatibility issues affecting performance may arise [48,89]. Level III included data standardization (F11), compatibility with other IT systems (F5), data unavailability (F1), and scalability and accessibility (SA); all strongly influenced BC adoption. The technology remains immature, and therefore the above factors must all be upgraded to enhance performance in the healthcare sector [90]. Level II comprises interoperability of electronic health records (F10), privacy and security of storage (F7), and encouragement of integration (F13); all dynamically influence adoption. Finally, the factor at level I is affected by all other factors and thus exhibits the highest dependence power. Encouragement of integration is the key driver; BC can be combined with many cutting-edge technologies that render organizations more efficient and smarter [51,52,53]. Secure data storage makes organizations safer; this is one of our long-term healthcare objectives.

After MICMAC analysis, quadrant 4 hosted five factors with strong driving powers and quadrant 2 hosted four factors with strong dependence powers. Quadrant 3 was empty; there was no linkage variable. Quadrant 1 hosted four autonomous variables. Dependent variables comprised privacy and security of storage data (F7), interoperability of EHRs (F10), encouragement of integration (F13), and safer and smarter organizations (F4). MICMAC analysis revealed that regulatory clarity and governance (F2), immature technology (F3), high investment cost (F6), BC developers (F9), and trust among stakeholders (F12) exhibited strong driving powers and were thus the most important factors in terms of BC adoption in healthcare. Data unavailability (F1), compatibility with other IT systems (F5), scalability and accessibility (F8), and data standardization (F11) (autonomous variables) exhibited weaker dependences and driver powers, suggesting that they were less important than other factors. However, all identified factors affect the adoption of BC in healthcare.

We shared our analysis with stakeholders in healthcare industries. Surprisingly, many managers were unaware of many factors. We hope that our analysis will help them to prepare for successful BC adoption.

5. Managerial Implications

Our work will allow regulators, policymakers, governments, healthcare industrialists, and consumers to recognize the critical factors that affect BC incorporation in healthcare. Managers and decisionmakers should focus on the inputs and outputs of the ISM model. The inputs were based on a literature review and expert opinions. The outputs identify the interdependencies and the short- and long-term importances of various factors. The model will be implemented and tested in a cross-sectional manner in multiple industries.

Managers will be interested in the outcomes; they should prepare the resources for successful implementation. Managers must offer staff workshops and training regarding BC and its benefits. Existing educational institutes and special training schools may be involved. Managers must be careful when sharing information; a competitive advantage must not be lost. Petersson and Baur [91] emphasized that an organization is not required to reorganize its business model during BC integration. Furthermore, BC is possible in a traditional system; a new system is unnecessary. During organizational preparation, knowledge of the technical aspects will be helpful.

All organizations must now adopt cutting-edge BC technology. Its basic features include smart contracts, privacy, and data security; it is easy to switch to new (improved) future platforms. Existing open-source platforms are expensive if they are expected to serve as proprietorial infrastructure [92]. Organizations should implement BC technology immediately; the “wait-and-see” period is over. Early acceptance of the technology will afford competitive advantages [93].

6. Practical Implications

Healthcare decisionmakers must implement BC to protect the privacy of healthcare data. Such privacy supports the implementation of AI and federated learning, which enhance organizational efficiency. Kumar et al. [52] used BC technology for data authentication, allowing efficient use of AI and federated learning. In the era of coronavirus disease 2019, cutting-edge AI can rapidly identify an infection and is applicable worldwide; this could be combined with BC technology. With increasing data digitization, the need for privacy increases, along with the desire for societal betterment. BC technology can serve as the foundation of the required systems.

7. Conclusions

In our digital age, it is essential to protect healthcare data, but appropriate technology is lacking. BC technology can achieve the desired objectives. AI and federated learning enhance efficiency. BC systems would improve greatly if organizations were to successfully implement the technology. Large organizations (e.g., NVIDIA) have commenced research regarding AI and federated learning, motivated by societal betterment.

Here, we recognized 13 factors that influence successful BC implementation in the healthcare industry. We used ISM to divide these 13 factors into six levels. An inappropriate regulatory environment greatly hinders BC adoption in the healthcare industry. Firms are reluctant to adopt this intricate and immature technology. Compatibility, investment cost, and security concerns are equally important. Our work has the following strengths. First, no similar formal study has appeared. Second, we have highlighted the key obstacles hindering the implementation of BC technology and have proposed methods to eliminate them. We offer useful tips for specialists in cutting-edge technology. BC will greatly advance organization in our digital era. Nonetheless, this study had the following limitations. First, we evaluated only a few critical factors emphasized in the literature. Second, as this technology is emerging, there are few skilled experts; we canvassed only 15.

In the future, we plan to validate the results obtained after implementing BC technology and to combine the findings with AI and federated learning to create a useful, real-time generalized model. As previously suggested, and as reinforced by current demand, reliable security solutions must be integrated into all digital platforms and must be capable of adaptation to new environments [94,95]. We will seek BC technology that is secure across all applications. We will share the corresponding implementations in future articles. We will also perform cross-sectional studies to identify factors that can enhance the impact (i.e., strength) of BC implementation. Finally, we suggest that others could implement our approach in their diverse sectors by combining longitudinal and cross-sectional studies. We hope that our work may serve as a reference. It should be shared and may aid other industries.