A Process Reference Model for Blockchain dApp Development for the Health Domain

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

Download PDF

Research Article

A Process Reference Model for Blockchain dApp Development for the Health Domain

https://doi.org/10.21203/rs.3.rs-3449851/v1

This work is licensed under a CC BY 4.0 License

Version 1

posted

You are reading this latest preprint version

Blockchain technology has gained significant attention across various fields in recent years, including its applications in the health domain. Examples of such applications are medicine supply chain management, health record management, clinical trial management, and remote patient monitoring. Although the health domain is highly regulated, there is currently a lack of comprehensive studies presenting the essential blockchain processes, practices, and guides for development teams for ensuring health regulations. To address this gap, this study proposes the Blockchain Health dApp Process Reference Model (BDRM) specifically for developing blockchain dApps in the health domain. The BDRM was developed through a systematic review of formal and gray literature, considering expert opinions to specify the processes and practices, and integrating IEC 82304, IEC 62304, ISO 14971, and ISO/IEC 12207 standards’ requirements to make the reference model regulatory compliant. The model consists of 15 processes and 68 practices associated with these processes. The study also describes the application of design science research during the model's development. The proposed BDRM can benefit developers, researchers, and decision-makers by providing a useful resource for the development of blockchain applications in the health domain.

Blockchain

Health software

Medical software

Process model

Blockchain development

Blockchain is a decentralized and distributed technology that allows multiple parties to record and track transactions securely and transparently. As the technology is tamper-evident and tamper-resistant, it provides a reliable data management system. A blockchain system consists of a network of computers called nodes that validate and record transactions on a public ledger. Each transaction is secured using cryptographic functions and added to a block, which is then linked to the previous blocks, forming a chain of blocks [1].

Decentralized applications (dApps) are distributed open-source software applications that are designed to run on a blockchain or other distributed ledger systems [2]. Blockchain dApps are widely developed across various domains, and their progress continues gradually [3]. They find application areas in various domains, including digital voting [4], supply chain management [5], electronic copyrights [6], banking and financial services [7], and health applications [8]. Among these areas, the health domain holds particular promise for blockchain technology, as it offers to provide data transparency in clinical trials, to monitor data for disease surveillance, to collect and share data produced by biosensors for remote patient monitoring, and to track and verify the authenticity of pharmaceuticals [9].

One particular example of blockchain dApps being adapted in the health domain is the management of electronic health records (EHRs). Such systems enable healthcare providers to store and access data related to patients’ medications, diagnoses, and treatments [10]. In this way, healthcare providers can ensure the integrity and security of shared medical information while concurrently mitigating the potential risks associated with errors in the health record data [11][12].

While the utilization of blockchain holds great promise, it is important to acknowledge and address various challenges and risks that emerge in both technological and domain-specific contexts. Developing blockchain dApps requires establishing decentralized systems that allow multiple parties to access and validate the data, which in itself poses challenges such as testing decentralized systems [13], and achieving interoperability among different blockchain platforms [11][14]. Additionally, in safety-critical systems, the issue of identifying accountable authorities becomes a significant concern [15].

Smart contract vulnerabilities, which involve weaknesses or flaws in the code of smart contracts, can potentially lead to security breaches or the exploitation of blockchain systems [16][17]. To mitigate such vulnerabilities, it is important to follow the best practices for smart contract development and verification. Additionally, scalability and performance issues may arise with increasing transaction volumes, affecting system efficiency and responsiveness. Addressing these challenges requires optimizing the system architecture, selecting appropriate consensus mechanisms, and implementing solutions like sharding. Moreover, blockchain applications in healthcare must adhere to specific regulations to ensure the privacy, security, and integrity of sensitive medical data [18][19].

Therefore, a process reference model that aligns with the relevant health domain standards would provide valuable guidance in achieving regulatory compliance, upholding legal and ethical obligations, and addressing these challenges and risks during the development process. While some of the previous studies [20][21][22][23][24] have explored life cycle models for blockchain dApps, there is no established process reference model specific to blockchain dApps. A process reference model is a framework that aids in the development, management, and maintenance of applications within a particular domain. The maturity of processes often follows the emergence of technology, and therefore, it is crucial to evaluate existing development practices and cohesively present them. Incorporating specific field requirements into reference models facilitates compliance with the inspections of regulatory bodies, particularly in highly regulated domains.

The purpose of this paper is to present the Blockchain Health dApp Process Reference Model (BDRM), including the essential blockchain processes and practices necessary to create blockchain dApps in the health domain. The model aims to provide a common ground for blockchain dApp development by describing the essential processes and practices and considers the requirements set in IEC 82304 Health software – Part 1: General requirements for product safety [25], and IEC 62304 Medical device software – Software life cycle processes [26] for the health domain, and ISO 14971:2019 Medical devices – Application of risk management to medical devices [27].

We also describe how we applied the design science approach while answering the following research questions in developing the model.

What are the core blockchain dApp development processes and practices?
How do blockchain dApp development processes and practices differ from traditional software development?
How could blockchain dApp development processes and practices be specialized to ensure regulatory compliance in the health domain?

To the best of our knowledge, the BDRM is the first model that includes all the processes and practices necessary to create blockchain dApps in the health domain. It can be used independently of any development life cycle approach.

We believe that this study significantly contributes to the literature and practitioners in the following aspects:

The BDRM not only guides the development activities but also ensures adherence to the regulatory health and medical device software development standards, IEC 82304 and IEC 62304, which may usually require significant effort and time to adapt.
The BDRM addresses specific constraints that blockchain introduces to development processes in the health domain.
This study also guides the researchers who would be interested in developing such a model, considering the design science research approach.

The rest of the paper is structured as follows: Section 2 summarizes the existing literature and gives background information on blockchain technology and health domain software development. Section 3 describes the research methodology we followed in developing the BDRM. Section 4 explains the structure of the BDRM and lists the processes and practices of the model. Section 5 presents the discussions. Finally, Section 6 provides the conclusion and future work.

In this section, we first provide background information on blockchain technology and health domain software development standards. Then, we discuss the related literature.

2.1 Background on Blockchain Technology

Blockchain technology was first introduced by Satoshi Nakamoto, who described the design and principles of the Bitcoin cryptocurrency [28]. The launch of the first blockchain network, which serves as the electronic payment system [29], took place in 2009. Following that, many cryptocurrencies have emerged, such as Ethereum. Over time, blockchain technology has evolved significantly, extending its applications beyond cryptocurrencies. However, the underlying technologies have largely remained the same throughout these advancements [1].

Below, we describe the main blockchain system elements, as these terms are frequently used in the BDRM and in the rest of the paper. Figure 1 visually presents these blockchain system components.

Blockchain consists of blocks, transactions, nodes, consensus models, and smart contracts. They use public/private key cryptography, mining, and hashing functions.

Blocks refer to the data structures within a blockchain, where valid transactions are permanently recorded. Cryptographic Hashing is a process used to convert arbitrary-size data into a fixed-size string. Each block in a blockchain has a unique hash. Blocks include the hash of the previous block, thus forming a chain structure. Tampering the data within a block would cause a change in its hash value, which would break the link with the subsequent blocks. Therefore, hashing is essential to ensure the integrity of data in blockchain networks. A Transaction is a recording of an event, such as a transfer of assets between parties or the creation of new assets. Each transaction includes a sender address, a destination address, the amount of assets being transferred, and other metadata (e.g., transaction fees). Nodes are the computers/servers that participate in storing and validating transactions in a blockchain network. They also work together to ensure the consistency, security, and accuracy of a blockchain by verifying new transactions and blocks by participating in consensus mechanisms. Consensus mechanism is a process to achieve agreement within a blockchain system. They establish a shared understanding among nodes related to the network's current state. Mining is the process of solving puzzles within a Proof of Work (PoW) consensus mechanism that is used to add new blocks to the blockchain. A Smart contract is a piece of code and data that is deployed using cryptographically signed transactions on the blockchain network. Smart contracts are executed at the nodes in an automated way when a set of predetermined criteria are met. Public-private key cryptography (a.k.a. asymmetric cryptography) is used to secure communication and authentication between parties. Messages are encrypted using public keys and decrypted using private keys. In blockchain networks, private keys are used to sign transactions and verify asset ownership.

Blockchain networks can be characterized as permissionless, permissioned, or both [1]. Permissionless blockchain networks are decentralized ledger platforms where anyone can publish blocks. However, when a network allows only a selected group of users to publish blocks, it is said to be a permissioned network. We present the blockchain categories and associated types in Fig. 2.

The most common blockchain types are given below:

Public Blockchains allow individuals to participate in the network, submit transactions, and become validators. These blockchains are typically decentralized, implying that there is no central authority governing the network.
Private Blockchains are restricted to a specific group of participants, such as a company or a consortium of businesses. Only the selected nodes are allowed to participate in the private network.
Consortium Blockchains are a hybrid type of public and private blockchains, in which a group of organizations come together to form a network with shared control and governance. Consortium blockchains are often used where multiple entities need collaboration and data sharing.
Hybrid Blockchains combine the elements of both public and private blockchains, allowing the benefits of public blockchains such as decentralization and transparency while maintaining the privacy and control of private blockchains.

2.2 Health Domain Software Overview

As mentioned earlier, in order to adapt the health domain requirements to the BDRM, we used IEC 62304, IEC 82304, and ISO 14971 standards. This section explains health domain software categories and describes the content of the aforementioned standards.

Various regulatory agencies audit health domain applications depending on the region where the product will be marketed. The U.S. Food and Drug Administration (FDA) regulates health domain software [31] in the United States. To ensure that applications are secure and efficient for patient use, the FDA expects software developers to adhere to relevant health domain standards throughout the development process. In the European Union, health domain software is regulated by the Medical Device Regulation (MDR), which replaced the previous Medical Device Directives (MDD) [32]. Compliance with relevant health domain standards is crucial for obtaining the CE mark, which signifies compliance with European regulations and allows the software to be marketed and used in the EU.

Regulatory standards for health domain software vary depending on the software category and its intended use. Software in the health domain can be decomposed into the categories of Health Software and Medical Software. Figure 3, adapted from Heidenreich [33], includes the categories of health domain software in terms of regulatory compliance requirements. Health Software has to comply with the IEC 82304 standard, whereas Medical Software is subject to the IEC 62304 standard. ISO 14971 could be applied to software in the health domain, including both Health Software and Medical Software.

IEC 62304 standard provides guidance on the software development lifecycle processes for medical device software. This standard outlines the activities, documentation, and controls necessary for the development, verification, and validation of medical device software. IEC 82304 standard applies to all software that is used in the context of healthcare. This standard aims to provide a framework for ensuring the safety of health software applications and supporting organizations in developing and maintaining high-quality, safe software in the healthcare domain. Within the IEC 82304 standard, the software life cycle processes title directs users to the IEC 62304 standard and recommends following the steps in that standard. ISO 14971 provides guidelines for risk management in the development and post-market phases of health domain software.

The Health Domain Software categories in Fig. 3 are explained below:

Software as a medical device (SaMD) refers to software applications intended to be used for medical purposes without the need for additional hardware. These applications are considered medical devices on their own. Clinical decision support software, diagnostic software that analyzes medical data to provide diagnostic insights or predictions, software that monitors and tracks physiological parameters (such as heart rate, blood pressure, or glucose levels), and treatment planning and guidance software are examples of SaMDs.
Medical device software (MDS) refers to software that is integrated into a medical device, typically running on the device itself or on a dedicated embedded system. Some examples of MDS are software embedded in implantable medical devices such as defibrillators, pacemakers, neurostimulators, or drug delivery systems, software embedded in infusion pumps, software embedded in systems that continuously monitor glucose levels in patients with diabetes.
Health software covers a wide range of applications related to healthcare and well-being. This category includes software such as fitness tracking, wellness management, telemedicine, and electronic health records (EHR) management applications.

2.3 Related Work

The interest of researchers in blockchain dApps is increasingly growing. However, a study describing all the processes and practices required to develop blockchain dApps is still lacking. In fact, the research conducted so far is mostly focused on identifying the areas in the health domain to which blockchain technology could be applied. Below, we provide the studies relevant to our research from the perspective of blockchain development processes and practices. Table 1 provides a summary of the contributions of previous literature on blockchain dApp development processes.

Table 1

Related Studies
Study Ref	Contribution of the Study	Suggested Processes & Practices
[20]	Revealed the software engineering practices that may be used in blockchain development	Suggested Practices: Code review and unit test Apply community discussion for requirements elicitation Assign tasks to developers on a voluntary basis.
[22]	Provided a guideline for designing and implementing decentralized applications.	Suggested Design Practices: Understand the existing system design and business model Identify potential risks Determine potential tradeoffs Define a Distributed Ledger Technology (DLT) compliant translation of the application design and business model Suggested Implementation Practices: Choose a DLT implementation platform Offer token launch or initial coin List tokens on public exchanges Develop and deploy the decentralized application
[23]	Presented a blockchain software development approach based on Scrum.	Suggested Practices: Define goals Identify actors Define user stories of the system and related UML use cases and class diagrams Define and review actors and user stories Suggested Processes: Design, code, and test smart contracts Design, code, and test user interface Test the integrated system and deploy the complete system
[24]	Introduced dApp development and deployment processes on the Ethereum blockchain to guide practitioners.	Suggested Practices: Develop dApp on test net Deploy smart contract code Approve smart contract creation transactions, Verify, and publish smart contract code Deploy dApp on the main network

The studies listed in Table 1 primarily focus on suggesting practices for blockchain dApp development rather than providing a comprehensive reference model for the entire development process to guide the development of blockchain dApp systematically.

Additionally, while there are other studies addressing the blockchain-oriented development process by focusing on particular stages, they do not discuss or propose processes or practices that are necessary to ensure safety in health domain applications. For instance, Porru et al. [34] suggest improvements in testing and debugging blockchain-oriented software, in increasing collaboration for sustainable development, improving software quality, and the synergy between blockchain developers and communities. Similarly, Vacca et al. [16] propose applying traditional testing techniques to blockchain-oriented software, developing guidelines for developers, identifying patterns and creating a taxonomy for detecting attacks, and building a framework to compare different blockchain platforms.

Moreover, none of the existing studies have addressed the health domain standards. In contrast, the Blockchain Health dApp Process Reference Model (BDRM) presented in this study has been developed in accordance with the IEC 82304 Health software - Part 1: General requirements for product safety [25], and IEC 62304 Medical device software - Software life cycle processes [26] for the health domain.

Design Science Research (DSR) is an approach aiming to guide the creation of new knowledge by designing, developing, and evaluating novel artifacts, processes, or systems. DSR enables the creation and evaluation of new design artifacts, such as software systems, models, and methodologies, that can be used to solve problems or achieve goals in various domains [35][36]. Peffers et al.’s [37]. Design Science Research Methodology (DSRM) provides a framework for implementing DSR in the software engineering domain. The DSRM consists of six stages: S1: Problem identification; S2: Goal formulation; S3: Design and development of the artifact; S4: Evaluation of the artifact; S5: Articulation of the results; S6: Communication of the results.

Throughout this study, we followed the Peffers. et al.’s six-staged DSR methodology in the development of the BDRM. In the next section, we provide the activities we conducted and the corresponding DSRM stages. The letters given in parentheses indicate the matching DSRM stages for each activity.

Activity 1. Problem identification and Goal Formulation (S1 and S2)

First of all, we conducted a systematic literature review (SLR) [38] and a multivocal literature review (MLR) [9] to set the problem properly. In these studies, we explored the challenges and benefits of using blockchain technology in the health domain, the application areas of blockchain technology in the health domain, and existing solutions that could be used for health domain related challenges. We focused on understanding to what degree blockchain could answer the challenges inherited in the health domain and whether blockchain technology may bring new challenges to health application development.

The SLR paper pool consisted of 27 formally published studies [38], and the MLR study [9] included 78 formal literature sources (published journal papers, conference proceedings, and books) and 23 gray literature sources (magazines, white papers, news articles, presentations, Q/A sites such as StackOverflow, Wiki articles, and blogs).

Both the SLR and MLR we performed revealed that numerous studies have been published on blockchain dApps in the health domain, and they have received considerable attention from industry practitioners, academics, and governments. Despite this significant amount of research, few studies have analyzed the development processes of blockchain dApps in the health domain. To bridge this gap, we decided to carry out this study to develop a process reference model including software development processes and practices specific to blockchain applications in the health domain. For this purpose, we have identified the research questions presented in the introduction section of the paper.

Activity 2. Design and Development of the BDRM (S3) and Activity 3. Refinements, and Evaluation of the solution (S4 and S5).

The BDRM was incrementally developed through two iterations. At the end of each iteration, a new version of the model was released. These versions underwent rigorous verification processes to ensure the applicability, completeness, correctness, consistency, understandability, and usability of the model. This process involved receiving feedback from experts in the field and conducting interviews with domain/industry specialists. Through these efforts, the model was refined to ensure its applicability, completeness, correctness, consistency, understandability, and usability, as explained in the subsequent sections.

The final version of the model consists of 68 practices associated with 15 processes, also including special notes from the health domain software development standards. The whole list of the BDRM processes and practices is given in Table 2 in Section 4.

In the 1st iteration, we developed the initial version of the Blockchain Health dApp Process Reference Model (BDRM) and defined 46 practices associated with 13 processes. We specified the initial BDRM process and practices based on the information gathered from the SLR [38] and MLR [9] studies we performed on blockchain dApp development in the health domain. In addition, we have analyzed various sources related to the blockchain dApp processes in the formal literature and gray literature.

Afterward, we sought feedback on the model by sharing the first version of the BDRM with two experts in blockchain development. These experts, holding Ph.D. degrees and possessing a minimum of three years of experience in blockchain technology, also have a substantial publication record in the field.

We shared the first version of the model with the experts and asked them to evaluate the model from a completeness perspective. We obtained nine feedbacks related to the completeness of the model from the experts regarding the BDRM processes and practices. Based on the 1st iteration feedback, we made the following revisions to the model:

Content improvement was made in the following three practices:
- 1.2 Evaluate blockchain suitability – a note is added about supportive studies when assessing suitability,
- 7.6 Decide on block size and the target time span between blocks – a note is added about overcoming scalability problems and increasing performance, and
- 11.2 Verify the blockchain dApp product - a note is added about some notable blockchain testing tools.
The following three practices were found missing and included in the BDRM:
- 5.6 Specify blockchain dApp privacy requirements,
- 7.8 Ensure the security of the system, and
- 7.9 Apply anonymity mechanisms if needed.

In the 2nd iteration, we developed the second version of the BDRM by incorporating the specific health software development practices outlined in [25] and [26], and also considering the expert review results mentioned above.

The second version of the BDRM underwent an additional round of expert review. A total of six experts, including one who provided feedback in the previous review round, as well as five new experts with Ph.D. degrees (three experts affiliated with a university and two experts working for companies specializing in blockchain dApp development), assessed the model. Four of the experts have extensive experience in blockchain technology, the other two experts are experienced in health domain software development processes. This approach allowed us to incorporate a diverse range of perspectives into the BDRM model.

To receive expert feedback, we first shared the model with them and asked them to evaluate the model from the perspectives of applicability, completeness, correctness, consistency, understandability, and usability aspects. During the evaluation of the initial model version, we primarily sought expert opinions regarding its completeness. However, for the purpose of conducting a more thorough verification, this time we asked experts to evaluate the model across all of the six aforementioned aspects. We obtained 78 negative feedback from the experts and associated the feedback with the six aspects. A five point likert scale were created for expert decision: Strongly Agree, Agree, Neutral, Disagree, Strongly Disagree. We present the aspects, their descriptions, and the experts' decisions on aspects in Table 2. The values in parenthesis underneath the decisions indicate the number of feedback received from the experts regarding the aspects.

Table 2

Expert Decisions and Perspectives
Aspect	Description	E1 Decision #negative feedbacks	E2 Decision #negative feedback	E3 Decision #negative feedback	E4 Decision #negative feedback	E5 Decision #negative feedback	E6 Decision #negative feedback
Applicability	Practical applicability of the model in the health domain projects	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)
Completeness	Comprehensive documentation of process IDs, process names, purposes of the processes, practices, and special notes in the model	Neutral (8)	Neutral (12)	Neutral (9)	Neutral (13)	Agree (5)	Strongly Agree (1)
Correctness	The accuracy of the information contained in the model	Agree (3)	Agree (3)	Agree (2)	Neutral (8)	Strongly Agree (0)	Strongly Agree (0)
Consistency	Internal consistency, meaning that its guidelines do not contradict each other	Strongly Agree (1)	Strongly Agree (1)	Strongly Agree (1)	Strongly Agree (1)	Strongly Agree (0)	Strongly Agree (0)
Understandability	Provide clear and comprehensive guidelines and requirements for processes and practices. Unambiguous and easily understandable by all stakeholders	Strongly Agree (1)	Agree (3)	Agree (2)	Agree (3)	Strongly Agree (0)	Strongly Agree (0)
Usability	Usable and practical for developers and project teams Provide guidance that can be readily applied in practice	Strongly Agree (1)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)	Strongly Agree (0)

The following revisions were made in the model according to the received feedback:

Content correctness was made in the six practices:
- 2.6 Decide the need for using digital assets – the term “cryptotoken” is corrected as “digital token”.
- 4.2 Elicit stakeholder requirements - the phrase “identifying project needs as quickly as possible” has been removed,
- 5.2 Identify a consensus mechanism – the consensus algorithm name corrected as Performance Byzantine Fault Tolerance (PBFT) consensus algorithm,
- 6.2 Define risks to the blockchain dApp product – the safety class classification is corrected as [Class B, C],
- 7.1 Define and describe the blockchain dApp architecture - a security-related sentence is made consistent with other security expressions in the model,
- 7.6 Decide on block size and the target time span between blocks – the term “frequency is corrected as “target time span between blocks”.
Content improvement was made in the seven practices:
- 1.3 Evaluate the feasibility of the blockchain dApp project – a note is added about the project's financial feasibility,
- 4.2 Elicit stakeholder requirements – a note is added about the community discussion method,
- 4.3 Review stakeholder requirements – a note is added about example techniques,
- 7.2 Decide on blockchain network type – a note has been added that permissioned networks may be preferred in high performance expectations,
- 7.4 Decide on storage method - hybrid storage method is added,
- 8.2 Design the backend - designing the cryptographic algorithms is added, and
- 8.3 Design the frontend - establishing traceability is added.
The following two processes and 19 practices were found missing and added to the BDRM:
- 3. Blockchain dApp monitoring and control process,
- 13. Blockchain dApp quality assurance,
- 2.1 Create blockchain dApp scope, schedule, budget, and resources management plans,
- 2.2 Create a communication plan,
- 2.3 Create a change management plan,
- 3.1 Monitor the blockchain dApp project against the plan,
- 3.2 Control the blockchain dApp project,
- 3.3 Manage corrective actions to closure,
- 4.4 Agree on requirements,
- 5.3 Include tokenomics in blockchain dApps including digital tokens,
- 5.5 Specify blockchain dApp security requirements,
- 7.7 Decide on incentives if there is a need for a digital asset,
- 11.1 Prepare for verification,
- 11.3 Manage verification results,
- 12.3 Manage validation results,
- 13.1 Specify blockchain dApp product quality requirements,
- 13.2 Assure blockchain dApp product quality,
- 14.3 Deploy the blockchain dApp product on the test network,
- 14.4 Deploy the blockchain dApp product on the main network,
- 15.1 Develop a maintenance plan, and
- 15.4 Retire the blockchain dApp product practices.

Activity 4. Demonstration, and Communication of the solution (S5, S6)

We conducted a detailed face-to-face interview with a system development engineer who has three years of experience in blockchain technology at a company that produces products for highly regulated military domain and identity authentication with its 300 R&D personnel. The purpose of the semi-structured interview session was to explore the fitness of the model in a blockchain-based solution development company. Despite the fact that the company is primarily working in the military domain, we were able to evaluate the suitability of our model by considering that health domain requirements are relevant for safety critical projects. Before the interview session, we provided the engineer with access to the model and explained the interview's objectives. The interview lasted 1.5 hours. We asked the following open-ended questions:

IQ1. Which of the processes and practices in the BDRM are applied in your company?

IQ2. Do you follow any specific processes or practices when developing safety critical blockchain applications that are not covered by the model?

Based on his response, it was discovered that the company applies 12 processes (i.e., planning, requirements analysis, design, implementation, and maintenance) and their associated practices of the BDRM while developing a safety critical blockchain application. However, there were four processes (i.e., project initiation, quality assurance, risk management, and monitoring) and their practices that were not yet implemented in the project. The BDRM helped identify these missing processes and practices within blockchain projects. The company plans to incorporate these processes and practices into future projects.

It was also noted that no additional processes or practices were applied by the company beyond those included in the BDRM. This result suggests that the model is inclusive at a satisfactory level.

The application status of the company's processes in the BDRM has been discovered by going through each process individually with the company. The model emphasizes the process dimension, and the objective of the model does not entail capability assessment. It is possible to use the BDRM in conjunction with the 15504 standard [39] to address the capability dimension.

Blockchain Health dApp Reference Model (BDRM) was developed based on the meta-model of the ISO/IEC 12207 Software Life Cycle Processes standard. The BDRM includes processes and practices. The processes in the model provide a comprehensive framework for managing the software life cycle, from acquisition to maintenance, ensuring the delivery of high-quality software systems. The practices included in the processes focus on activities for developing dApp products to meet the needs of customers and end users. Each process is defined using the following structure in defining the processes.

ID of the Process	Each process is defined with a unique ID
Name of the Process	Each process is defined with a name.
Purpose of the Process	The purpose describes the goals of performing the process.
Outcomes	The outcomes describe the observable results expected from the successful execution of the process.
Base Practices and Special Notes	Each practice has a unique ID. The practices are sets of cohesive tasks of a process. The BDRM is developed in accordance with the ISO/IEC 12207 [40], IEC 82304 [25], IEC 62304 [26], and ISO 14971 [27] for the health domain. The notes are recommendations to ensure Safety Class A-B-C and to support the achievement of blockchain dApp outcomes. Information specific to blockchain development are highlighted in blue, while information related to the health domain are highlighted in green in the BDRM.
Inputs and Outputs	For each process, there are inputs required to execute the process, and there are outputs generated as a result of performing the process activities.

We discuss the answers to the research questions in the following headings.

4.1 What are the core blockchain dApp development processes and practices?

The processes and practices of the BDRM are given in Table 3. In this table, first-level headings in the model are processes and second-level headings are the practices. The model includes 15 processes and 68 practices in total.

Table 3

The BDRM processes and practices
Processes	Practices
1. Blockchain dApp project initiation process	1.1 Identify objectives and key performance indicators 1.2 Evaluate blockchain suitability 1.3 Evaluate the feasibility of the blockchain dApp project
2. Blockchain dApp planning	2.1 Create blockchain dApp project scope, schedule, budget, and resources management plans 2.2 Create a communication plan 2.3 Create a change management plan 2.4 Decide on the blockchain development life cycle model 2.5 Decide on the safety class of the product according to IEC 62304 2.6 Decide on the need for using digital assets
3. Blockchain dApp monitoring and control	3.1 Monitor the blockchain dApp project against the plan 3.2 Control the blockchain dApp project 3.3 Manage corrective actions to closure
4. Blockchain dApp requirements elicitation	4.1 Identify stakeholders 4.2 Elicit stakeholder requirements 4.3 Review stakeholder requirements 4.4 Agree on requirements 4.5 Manage changes made in the stakeholder requirements
5. Blockchain dApp requirements analysis	5.1 Specify blockchain dApp system requirements 5.2 Identify a consensus mechanism 5.3 Include tokenomics in blockchain dApps including digital tokens 5.4 Specify blockchain dApp software requirements 5.5 Specify blockchain dApp security requirements 5.6 Specify blockchain dApp privacy requirements 5.7 Validate the requirements, and update when necessary 5.8 Develop approval criteria for testing
6. Blockchain dApp risk management	6.1 Identify the software that could contribute to a hazardous situation and potential causes 6.2 Define risks to the blockchain dApp product 6.3 Apply risk mitigation plan and risk contingency plan 6.4 Analyze the process and product risks 6.5 Resolve the process and product risks 6.6 Manage the process and product risks that may be raised by changes
7. Blockchain dApp architectural design	7.1 Define and describe the blockchain dApp architecture 7.2 Decide on blockchain network type 7.3 Decide platform use or network creation 7.4 Decide on storage method 7.5 Decide where to deploy the modules of the system 7.6 Decide on block size and the target time span between blocks 7.7 Decide on incentives if there is a need for digital assets 7.8 Ensure the security of the system 7.9 Apply anonymity mechanism if needed 7.10 Verify the architecture
8. Blockchain dApp detailed design	8.1 Prepare for detailed design 8.2 Design the backend 8.3 Design the frontend
9. Blockchain dApp implementation	9.1 Develop unit verification procedures 9.2 Build APIs 9.3 Develop the backend 9.4 Develop the frontend, user interface
10. Blockchain dApp integration	10.1 Integrate the backend and frontend units 10.2 Verify and test the integration
11. Blockchain dApp verification	11.1 Prepare for verification 11.2 Verify the blockchain dApp product 11.3 Manage verification results
12. Blockchain dApp validation	12.1 Prepare for validation 12.2 Validate the blockchain dApp product 12.3 Manage validation results
13. Blockchain dApp quality assurance	13.1 Specify blockchain dApp product quality requirements 13.2 Assure blockchain dApp product quality
14. Blockchain dApp transition	14.1 Develop a transition strategy 14.2 Confirm the blockchain dApp product is ready 14.3 Deploy the blockchain dApp product on the test network 14.4 Deploy the blockchain dApp product on the main network 14.5 Make the blockchain dApp product available to the users 14.6 Manage results of transition
15. Blockchain dApp maintenance	15.1 Develop a maintenance plan 15.2 Analyze, assess, and accept or reject change requests 15.3 Implement, test, and deploy modifications 15.4 Retire the blockchain dApp product

4.2 How do blockchain dApp development processes and practices differ from traditional software development? How could blockchain dApp development processes and practices be specialized to ensure regulatory compliance in the health domain?

In the BDRM, 33 of the 68 practices include information specific to blockchain development. We listed these practices in Table 4. The table also contains 17 practices specific to the health domain requirements. The remaining 27 practices are those that are applicable in traditional software development. We have also presented information on which safety classes the practices are suitable for in the health domain according to the safety class definitions of the IEC 62304 standard [26] in the model. The standard defines three safety classes as follows:

• Safety Class A: the software system can contribute to a hazardous situation or may contribute to a hazardous situation that does not result in an unacceptable risk.
• Safety Class B: the software system can contribute to a hazardous situation resulting in unacceptable risk, but possible harm is not a serious injury.
• Safety Class C: the software system can contribute to a hazardous situation resulting in unacceptable risk, and possible harm is a serious injury or death.

In Table 4, the safety classes for practice are given in brackets, such as [Class A, B], if applicable. Additionally, specific details regarding blockchain development are highlighted in blue, while information related to the health domain is highlighted in green.

Table 4

BDRM processes and practices specific to blockchain development
Process Name	Practice Name	Definition
1. Blockchain dApp project initiation process	1.1 Identify objectives and key performance indicators	Clearly articulate the overarching objectives of the blockchain dApp development project. Define the key performance indicators (KPIs) that will be used to measure the success and effectiveness of the blockchain dApp. NOTE: The metrics may include transaction throughput, response time, system uptime, number of active users, gas fees, or any other relevant performance indicators specific to the dApp.
1. Blockchain dApp project initiation process	1.2. Evaluate blockchain suitability	Determine if blockchain fits the specified domain and whether it is capable of solving the specified problem. NOTE: We recommend leveraging the findings of supportive studies when assessing suitability [1][41]. Which type of blockchain might be appropriate is also identified in one of these supportive studies [41].
1. Blockchain dApp project initiation process	1.3 Evaluate the feasibility of the blockchain dApp project	Evaluate the feasibility of achieving the project goals with available resources and constraints [Class A, B, C]. NOTE: Perform a thorough financial analysis to assess the project's financial feasibility. This includes estimating costs, projecting revenues, and profitability. Cost estimations differ between creating a blockchain system from scratch and using existing platforms. Some of the platforms have transaction fees and execution fees, and some of them have procurement fees. Proof of Concept (POC) could be used to validate the idea and showcase its feasibility. A proof of concept is a theoretical demonstration of an idea's possible production and use. It enables testing a DApp with minimal resources before committing a large amount of time and money to the development process. It should be ensured that the solution offers complete security on the blockchain for the health domain in POC development [42].
2. Blockchain dApp planning	2.4 Decide on the blockchain development life cycle model	Identify a development life cycle [Class A, B, C]. NOTE: Agile or iterative incremental practices could be used, as blockchain dApp development usually deals with the rapid implementation of systems whose requirements are not fully understood at the beginning and tend to change over time [23]. Agile adoption in the health domain is possible to enable continuous safety assessment, continuous traceability establishment, continuous compliance, and better change management.
2. Blockchain dApp planning	2.5 Decide on the safety class according to IEC 62304	Classify the safety class (A, B, or C) of blockchain dApp based on the rules outlined in IEC 62304 standard [26].
2. Blockchain dApp planning	2.6 Decide on the need for using digital asset	Decide whether a digital token in blockchain dApp is needed. NOTE: If the users should have to purchase cryptotokens to use the blockchain dApp, then plan for a utility token. If there is a plan to introduce a cryptotoken with a promise of future profits for end users, then plan for a security token. A security token represents a stake, so investors purchase and hold them with an expectation of future profit.
4. Blockchain dApp requirements elicitation	4.2 Elicit stakeholder requirements	Gather stakeholder needs. Transform the needs into requirements. Maintain traceability of stakeholder needs and requirements. Define requirements considering the safety class [Class A, B, C]. NOTE: Many blockchain software projects are open source. They are developed with community participation, and “Community discussion” is the most preferred method for collecting requirements [20].
5. Blockchain dApp requirements analysis	5.1 Specify blockchain dApp system requirements	Define system requirements [Class A, B, C]. Consider the problems that are planned to be solved, consensus mechanism, cost, scalability, developer requirements, and expected timeline. Define blockchain dApp development platform requirements or define the requirements of creating a new blockchain framework. Maintain traceability between the system and software requirements and the stakeholder requirements.
5. Blockchain dApp requirements analysis	5.2 Identify the consensus mechanism	Determine the consensus mechanism. NOTE: The most popular consensus mechanisms are Proof of Work (PoW), Proof of Stake (POS), Delegated Proof of Stake (DPOS), Practical Byzantine Fault Tolerance (PBFT), Proof of Elapsed-Time (PoET), Proof of Authority (PoA). The consensus algorithms choice affects both computing performance and scalability. For instance, the Performance Byzantine Fault Tolerance (PBFT) consensus algorithm outperforms the Proof of Work (PoW) consensus method in speed despite being less scalable [43][44]. The Delegated Proof of Stake (DPOS) algorithm, which does not involve competition over discovering the blocks and is, therefore, more efficient, could be used in the medical blockchain instead of the Proof of Work (PoW) algorithm to reduce high energy costs [45]. Proof of Authority (PoA) algorithm is more energy efficient than the Proof of Work (PoW) algorithm due to the minimal usage of computational power [46]. If green computing is the focus, energy efficient algorithms should be preferred. If a dApp platform is chosen, the chosen platform has an impact on the consensus mechanism.
5. Blockchain dApp requirements analysis	5.3 Include tokenomics in blockchain dApps including digital tokens.	Plan to investigate tokenomics in blockchain dApps if digital tokens are planned to be included in Practice 2.7. Tokens provide a way to reward and incentivize network participants, customers, and stakeholders. Tokenomics encompasses the concept of the study and implementation of an economic system with tokens [47].
5. Blockchain dApp requirements analysis	5.4 Specify blockchain dApp software requirements	Define software requirements [Class A, B, C]. Define actors and user stories considering those that directly interact with the Smart Contracts/Chaincodes. Identify access rights, permission policies, and obligations. It is necessary to define access rights carefully in the domains where data confidentiality is crucial. NOTE: Smart Contracts/Chaincodes could be specified to regulate data access rights, and permission policies, in health applications [48].
5. Blockchain dApp requirements analysis	5.5. Specify blockchain dApp security requirements	Define security requirements including actions related to the compromise of sensitive information, authorization, authentication, audit trail, system security/malware protection, communication integrity, and anonymity [Class A, B, C]. NOTE: Consider five principles of information security, which are confidentiality, integrity, non-repudiation, accountability, and authenticity [49], while defining requirements.
5. Blockchain dApp requirements analysis	5.6 Specify blockchain dApp privacy requirements	Define privacy requirements considering the sensitivity of the information, privacy laws, policies, and regulations [Class A, B, C].
6. Blockchain dApp risk management	6.1 Identify software that could contribute to a hazardous situation and potential causes	Identify software items that could lead to a hazardous situation identified in ISO 14971 and the potential causes of this contribution. NOTE from 62304: The hazardous situation could be caused directly by a software failure or indirectly by the failure of a risk control measure used in the health dApp product. Document the potential causes [Class B, C].
6. Blockchain dApp risk management	6.2 Define risks to the blockchain dApp product	Define and record risk control measures in compliance with ISO 14971 [Class B, C]. NOTE: We recommend considering the following blockchain-specific risk items: • There are currently no established standards for blockchain and distributed ledger technology due to the field’s continuing rapid technological development. The absence of international standards carries risks related to the lack of interoperability, user lock-in, privacy, and security [50]. • Energy requirements could be high while building consensus for adding a new block if the PoW algorithm is used [50]. • The lack of a centralized authority in blockchain implementation places more responsibility on the user. In the case of loss or stolen private key, there is no organization to contact [51][50]. • The legal and regulatory framework surrounding blockchain is still in its infancy and therefore entails significant risks [50]. • The system is vulnerable to risks from malicious users in pseudonymous systems, or those where disclosing identity is not required, in the absence of third-party identification [50]. Identification of an end user will remain hidden from the system, which poses security risks, particularly regarding Know Your Customer (KYC) standards [50]. • Smart contracts could be subject to poor management and security flaws. To install new or modify existing smart contracts, participant entities or the network administrator will need a robust governance and change control procedure. To recognize and address issues with the operations of smart contracts, they will also require a strong incident management procedure [51]. • Oracles are non-blockchain entities that provide data to the network potentially causing the execution of smart contracts on the network. These oracles may pose the biggest threat to a blockchain framework because they are vulnerable to malicious attacks that aim to tamper with the data given to the blockchain [51]. • If a group has more than 50% of the network's hashing power—the processing power used to solve the cryptographic puzzle—is said to be performing a 51% attack on the blockchain. Then, at a very specific point in the blockchain, this group introduces an altered blockchain to the network, which, in theory, is accepted by the network because the attackers would hold the majority of it [52]. This is a risk, however it is usually not realized due to the expense of obtaining sufficient hashing power.
6. Blockchain dApp risk management	6.4 Analyze the project and product risks	Analyze risks and apply risk measures to determine the priority of where to allocate resources to monitor risks [Class B, C]. NOTE from 62304: Assess the risk control measure to determine whether it might generate a new hazardous situation.
6. Blockchain dApp risk management	6.6 Manage the project and product risks that may arise from changes	Examine the risks that may be raised of changes. NOTE from 62304: Analyze changes to see if any new potential causes are being introduced that could lead to a hazardous situation and whether any additional risk control measures are necessary. [Class A, B, C]
7. Blockchain dApp architectural design	7.1 Define and describe the blockchain dApp architecture	Establish the top-level architecture that identifies elements of hardware, software, and manual operations [Class A, B, C]. Maintain traceability among the architecture, and the requirements. NOTE: Describe the architecture considering the requirements presented below: • Scalability is affected by block size and the target time span between blocks • Fault tolerance and security is affected by consensus protocol • Cost efficiency is affected by the type of blockchain • Performance is affected by the data structure, block size, consensus protocol • Privacy is affected by the type of blockchain One way to improve performance and efficiency on a blockchain is to standardize the data that will be stored and exchanged. Ledgers could define the type, size, and format of data and align it. Access controls on the blockchain network also contribute to data standardization [53]. Blockchain records every action that occurs in the network. There is no chance of data loss in the blockchain; nonetheless, there is a chance of redundant data creation [54]. A distributed, peer-to-peer storage network that inherently supports deduplication is InterPlanetary Filesystem (IPFS) [6]. IPFS and blockchain could be combined to take advantage of IPFS's deduplication capability [55]. We recommend benefiting from reference architectures. For example, Ellervee et al. presented a blockchain reference model from the perspectives of players, services, processes, and data models [56]. There exist reference architecture studies for a variety of blockchain-based applications, such as crowdsourcing [57], government services [58], and healthcare [59].
7. Blockchain dApp architectural design	7.2 Decide on blockchain network type	Depending on the properties of use case actors, decide whether to use public, consortium, or hybrid blockchain types and the permission status. NOTE: Permissioned blockchain networks with trusted nodes may be preferred if high performance is expected from an application. They have much higher execution and processing efficiency (35000 transactions per second) and higher computing power than public blockchain solutions [53].
7. Blockchain dApp architectural design	7.3 Decide platform use or network creation	Decide whether to use a dApp development platform or to create a new blockchain framework. NOTE: There are various platforms for blockchain dApp development. Example platforms are Ethereum [60], Hyperledger Fabric [61], Hyperledger Sawtooth [62], R3 Corda [63], Quorum [64], and RippleNet [65]. Blockchain frameworks need to be developed to comply with existing regulatory frameworks in the health domain. Hyperledger Fabric can be given as an example which was designed to be compliant with HIPAA and GDPR, it has been actively employed in the implementations of blockchain-based systems for healthcare data management.
7. Blockchain dApp architectural design	7.4 Decide on storage method	Decide storage method depending on the data size: on-chain storage, off-chain storage, or hybrid. On-chain storage means that the data is stored on the blockchain network. Off-chain storage, on the other hand, stores data in external storage and its hash in the blockchain [66]. NOTE: When the size of the health data is huge, on-chain storage may result in performance and scalability problems. However, when the data is kept off-chain, there is a risk of deletion. When data hash is stored on-chain, such alterations will be recognized but not prevented. An alternative solution is the roll-up technology. Rollups relocate the computation off-chain while retaining certain information for each transaction. The amount of information published on the chain is the minimum required to locally validate the rollups transaction which also solves the storage issue [67].
7. Blockchain dApp architectural design	7.5 Decide where to deploy the modules of the system	Evaluate the deployment of the dApp blockchain on a cloud or IPFS provided by a third party or the use of a blockchain-as-a-service model directly.
7. Blockchain dApp architectural design	7.6 Decide on block size and the target time span between blocks	Identify block size and the target time span between blocks. NOTE: For permissioned networks, selecting non-default values for the block size and time could contribute to overcoming scalability problems and increasing performance. Throughput and latency are impacted by how these blockchain characteristics are chosen [68].
7. Blockchain dApp architectural design	7.7 Decide on incentives if there is a need for digital assets	Decide incentives such as rewards for generating new blocks and fees associated with transactions to encourage participants to cooperate and create value that will drive the success of the blockchain dApp. Apply this practice if decided as there is a need for digital assets in 2.3 practice.
7. Blockchain dApp architectural design	7.8 Ensure security of the system	Ensure the security of the system. Conduct a thorough threat modeling exercise to identify potential security threats and vulnerabilities. Use secure communication protocols to establish secure connections between blockchain nodes, wallets, or other network participants to protect data integrity and confidentiality. Consider secure coding practices and secure coding standards to mitigate common vulnerabilities. Use zero trust policies in blockchain applications when enhancing overall security is crucial. These policies include data encryption to improve access management and user authentication. NOTE: It is necessary to consider security in applications to be developed in the health domain. The Food and Drug Administration (FDA) [31] and the Medical Device Directives [69] regulate the healthcare applications marketed in the USA and the European Union,
7. Blockchain dApp architectural design	7.9 Apply anonymity mechanism if needed	Decide and apply if there is a need for an anonymity mechanism. NOTE: Different techniques could be used to preserve anonymity on a blockchain. These mechanisms could be preferred due to the sensitivity of health data. A zero knowledge proof construction or mixing services techniques could be used to preserve anonymity on a blockchain. • Using a cryptographic technique called zero-knowledge proof, no information is disclosed during a transaction other than the exchange of a value known by both the prover and the verifiers (the two ends of the process). Zero-knowledge proof is a way for a user to demonstrate to another user that they are aware of an absolute value without disclosing any additional or further information [70]. • By sending payments from a set of input bitcoin addresses to another set of output bitcoin addresses, a bitcoin mixing service offers anonymity. This mechanism makes it difficult to determine which input address paid which output address [71].
7 Blockchain dApp architectural design	7.10 Verify the architecture.	Ensure that the architecture meets all requirements [Class A, B, C]. NOTE from 62304: Traceability analysis of architecture to software requirements could be used in this phase.
8. Blockchain dApp detailed design	8.2 Design the backend	Design the following elements [Class A, B, C]. • Design the Smart Contracts/Chaincodes. • Design the inheritance structure, the usage of interfaces, the connections, the flow of messages, the data structure, the external interface, the events, the internal functions, and the modifiers [21] [23] • Design the cryptographic algorithms (ring signature, group signature, multi-signature). • Design the blockchain oracles which are third-party services that connect blockchains to the outside world and provide smart contracts access to external data. NOTE: Patient mobility necessitates cross-border data transmission, which makes it challenging to adhere to many nations' privacy and data protection standards. It is critical to consider various data privacy, security, and sharing policies considering patient mobility fact [72]. Design a structure that enables each country participating in the network to implement specific policies for the protection and control of health-related data.
8. Blockchain dApp detailed design	8.3 Design the frontend	Design the following elements of the frontend that interact with the blockchain system [Class A, B, C]. • Design the detailed interfaces of the various modules, the module decomposition, the flow of messages, the connections and data flow between participants, and the structure and storage of data [21] [23] • Design the response to the events raised by Smart Contracts/Chaincodes [21] [23] • Design the User Interface Establish traceability between the detailed design elements, the architecture, and the requirements.
9. Blockchain dApp implementation	9.2 Build APIs	Build the APIs that are required for diverse purposes, such as generating key pairs and addresses, smart contracts, data authentication through hashes and digital signatures, storage, and retrieval of data, audit functions, and smart asset lifecycle management [73]. [Class A, B, C].
9. Blockchain dApp implementation	9.3 Develop the backend	Develop the blockchain system. Create a new blockchain network or select one of the existing blockchain platforms [Class A, B, C]. Write the smart contracts/chaincodes using a programming language suitable for the blockchain platform. Implement the required logic, functions, and data structures within the smart contracts. Perform unit testing to ensure it functions as intended. NOTE: Smart contracts need to be tested in a production environment as part of the development process. Testing in the production environment includes an execution fee. This fee varies depending on the operations performed by the smart contract [74]. Smart contract testing is free in test networks. Before deploying smart contracts to the production environment, testing practices need to be applied in the test network to reduce the cost. Optimize the smart contracts for execution and/or transaction fees.
9. Blockchain dApp implementation	9.4 Develop the frontend, user interface	Develop and document the frontend which interacts with the blockchain system [Class A, B, C]. Build a client-side application that will interact with smart contracts. Maintain traceability among the implemented elements, the architecture, the design, and the requirements.
10. Blockchain dApp integration	10.1 Integrate the backend and frontend units	Integrate the blockchain system and frontend units of the blockchain dApp [Class A, B, C]. Maintain traceability among the integrated system elements, the architecture, the design, and the requirements. NOTE: An internal audit could be conducted to review if all requirements and specifications are met. During the audit, tests are also conducted to check how the various parts of the blockchain dApp work together. API testing needs to consider the interaction of applications in and out of the blockchain system.
10. Blockchain dApp integration	10.2 Verify and test the integration	Verify if the software units have been integrated into the software system in line with the integration plan, test the integrated software items and keep records of the results of the verification and testing. Record the test outcome (pass/fail status and a list of anomalies), keep enough records to allow the test to be repeated, and record the tester [Class B, C]. NOTE from IEC 62304: Examples of testing content to be considered are: - specified functioning of internal and external interfaces - testing under abnormal conditions including foreseeable misuse. - implemented risk control measures defined in 6.2.
11. Blockchain dApp verification	11.2 Verify the blockchain dApp product	Create tests for requirements and run a series of tests to show that each requirement is met [Class A, B, C]. Verify that test results fulfill the necessary pass/fail criteria and keep track of the traceability between requirements and tests or other types of verification [Class A, B, C]. NOTE: Example testing types on blockchain applications are listed below [75][76][75][76][77]. • Functional testing: Basic testing of components, systems, and their functionality, such as the addition of a block in the blockchain, block size, chain size, and data transmission [Class A, B, C] • Smart Contract Testing: Testing smart contracts involves thoroughly functionally verifying business logic and procedures. This testing ensures that the smart contracts work as intended. • Security Testing: Test the blockchain application for potential security vulnerabilities. This testing can include penetration testing, vulnerability scanning, and code review [Class B, C]. Ensure that test procedures cover all the security requirements. • Performance Testing: Test the performance of the blockchain application under different load conditions. This testing helps to identify potential bottlenecks and scalability issues. • Node Testing: Consensus across all nodes regarding the sequence in which transactions are added to the network is necessary to sustain a blockchain’s strength. Test the system and check each node to make sure that transactions are recorded in the proper order. • Regression testing: When a change is introduced and when software components are integrated, perform regression testing to demonstrate that defects have not yet been introduced into previously integrated software. [Class B, C] NOTE: Specialized testing methods, procedures, and tools could be beneficial due to the inherent nature of blockchain technology, which comprises distributed systems and anonymous nodes that collaborate in a peer-to-peer setting [13]. Some notable blockchain testing tools are Ethereum Tester (an open-source testing library) [78], Ganache (a widely used library for testing Ethereum contracts locally) [79], Hyperledger Composer (an open-source tool that helps to perform interactive testing, automated unit, and system testing) [80].
12. Blockchain dApp validation	12.2 Validate the blockchain dApp product.	Perform validation in accordance with the validation strategy and capture the obtained results [Class A, B, C]. Validation of blockchain dApps introduces certain unique considerations compared to traditional software validation: • Validating smart contracts involves a thorough review and analysis of their code logic, ensuring that they function as intended and adhere to security best practices. • The validation phase may involve testing and evaluating the chosen consensus mechanism. It may be necessary to assess the resilience, security, and performance characteristics of the consensus mechanism, as it directly impacts the integrity and trustworthiness of the blockchain dApp. • Depending on the nature of the blockchain dApp and the domain it operates in, validation may also encompass ensuring compliance with relevant regulations and standards. This could involve verifying adherence to data privacy regulations, or specific health domain standards.
13. Blockchain dApp quality assurance	13.1 Specify blockchain dApp product quality requirements	ISO/IEC25030,Software Engineering - Software product quality requirements and evaluation (SQuaRE) - Quality requirements [81] can be consulted in specifying software product quality requirements [Class A, B, C] which are usability, reliability, performance efficiency, maintainability, and portability. NOTE: While many of the quality characteristics in ISO/IEC 25030 are applicable to blockchain dApps, the decentralized nature of blockchain technology introduces some unique quality characteristics. Some possible additional quality characteristics specific to blockchain dApps are: • Scalability: Blockchain networks can face scalability challenges as more users and transactions are added to the network. Scalability is a critical quality characteristic for blockchain dApps, and several approaches have been suggested to address this challenge. For example, sharding, sidechains, and layer-two scaling solutions can all be used to increase the scalability of blockchain networks [82]. • Interoperability: Blockchain networks can be siloed, making it difficult for different networks to communicate with each other. Interoperability is an important quality characteristic of blockchain dApps. It enables cross-chain transactions and can create a more connected, decentralized ecosystem. Several approaches have been suggested to enable interoperability, including atomic swaps, cross-chain bridges, and blockchain interoperability protocols [83][84]. • Energy efficiency: Proof of work consensus mechanisms, which are used by many blockchain networks, can consume significant amounts of energy. Energy efficiency is a critical quality characteristic for blockchain dApps, as it can reduce the environmental impact of blockchain networks and increase the sustainability of the technology. Several approaches have been suggested to improve the energy efficiency of blockchain networks, including proof of stake consensus mechanisms, energy-efficient mining algorithms, and off-chain transactions [46].
14. Blockchain dApp transition	14.3 Deploy the blockchain dApp on the test network	Deploy the blockchain dApp product on a test network before launch to ensure that all of its features and capabilities are operating as intended [85]. The aim is to ensure software verification is performed and the results are evaluated before the software is released.
14. Blockchain dApp transition	14.4 Deploy the blockchain dApp on the main network	Deploy the blockchain dApp on the main network and install the Smart Contracts to the blockchain network. Document the deployment procedure [Class A, B, C].
14. Blockchain dApp transition	14.5 Make the blockchain dApp product available to the users	Make the blockchain dApp accessible to the users according to the transition strategy. Document the upgrades of dApp aligned with deployment. The application, configuration items and the documentation should be archived [Class A, B, C].
15. Blockchain dApp maintenance.	15.3 Implement, test, and deploy modifications	After delivery, modify the application to fix bugs, enhance performance or other features, or adapt to a new environment. Implement, evaluate, and record the selected alteration [Class A, B, C]. Analyze the impact of maintenance changes. Examine how maintenance modifications affect data structures, data, software functions, user documentation, and interfaces. NOTE: Blockchain dApps can be more difficult to modify than conventional systems. We have summarized the modification challenges as follows: • Every peer in the network must update their node software when the system needs to be updated. [86]. • As the blockchain platform software is distributed across numerous independently operating nodes, updating that software might be challenging to coordinate both physically and administratively, especially in a system with no single owner [87]. • From the data perspective, as the blockchain ledger is designed to be immutable, it cannot be updated when the system is modified [87]. A fork leads to a split of the blockchain, and two different versions of the network are run separately. Forks can be used to fix serious issues in a blockchain, (e.g. the case with the Bitcoin fork in 2010 [88]), or to undo the consequences of hacking.

The Blockchain Health dApp Process Reference Model (BDRM) is designed to provide a common framework for blockchain dApp development. It incorporates essential processes and practices, utilizing the meta-model of ISO/IEC 12207 [40] and taking into account the requirements outlined in IEC 82304 [25], IEC 62304 [26], and ISO 14971 [27]. The BDRM comprises 15 processes and 68 associated practices. The model presents a comprehensive structure that guides individuals and organizations in developing blockchain dApps in the healthcare domain.

A significant proportion of the practices, 49% (33 of 68), contain information specific to blockchain technology. Additionally, 17 practices include information specific to the healthcare domain. The model also includes information on the safety classes for the practices, as defined by the IEC 62304 standard [26].

The initial version of the model consisted of 13 processes and 46 practices. Following the feedback received from experts, the model was expanded to 15 processes and 68 practices. The model went through eight reviews by experts with experience in blockchain technologies and health domain software. An engineer from a company developing blockchain solutions was interviewed to explore the model's fitness for the organization. The BDRM's processes and practices were presented, and two open-ended questions were asked. No additional processes or practices were applied by the company beyond those included in the BDRM. This result suggests that the model is inclusive at a satisfactory level. Besides, the BDRM raised awareness of the company regarding processes and practices that were not implemented within the blockchain dApp projects. The company plans to apply the lacking processes and practices to subsequent projects.

Besides being a model that defines processes for blockchain dApp development, the BDRM also contributes to addressing the challenges specified in the MLR study [9]. The model contributes to an increase in awareness as it contains information on the prevention of these challenges. The challenges and addressed practices are summarized below:

After being stored in a blockchain, data cannot be changed or removed [89]. However, health data privacy rules require data to be corrected or erased when a patient requests it [90][91][92]. Additionally, the scale of health data can be rather enormous as X-rays, and pictures are often used in the health domain [53][54][93]. The systems also have to cope with storage problems [94][95] and mining expenses [96] as a result of the growth in data size.

To address data removal-on-demand and the challenges caused by data volume, the BDRM includes the practice of "7.4. Decide on storage method" in the Blockchain dApp architectural design process. This practice offers three options: on-chain, hybrid, or off-chain storage (i.e., storing health data in external storage and its hash in the blockchain). Off-chain storage can potentially address challenges related to data removal, alteration, and size.

However, when the data is kept off-chain, it may also pose a risk of deletion and be replaced with the roll-up technology, which relocates computations off-chain while retaining certain information for each transaction, thus addressing storage issues [67]. This note was also given in the BDRM.

The next challenge we address comes from the nature of blockchain networks. There is no chance of data loss in a blockchain, as data is saved in every block. However, this may cause redundant data in the chain [54]. The BDRM suggests the use of IPFS, which is a distributed peer-to-peer storage network that inherently supports deduplication [6], and blockchain combination in the "7.1. Define and describe the blockchain dApp architecture" practice.

Another challenge is the scalability problem of blockchains due to consensus mechanisms and ledger replication across all network participants [97]. This situation also causes significant computational power and storage space requirements on each node [43]. The read latency grows with the size of ledgers, which is a performance issue [98][99]. The BDRM includes the practices of "7.2. Decide on the blockchain network type and 5.2. Identify a consensus mechanism" to address these performance and scalability constraints [100]. The BDRM includes all development stages and guides the creation of blockchain dApps. Therefore, it contributes to the challenge of the proper development of smart contracts, which has a significant impact on the blockchain's efficiency [90].

The next challenge is that the code of a smart contract cannot be changed once it has been added to a network. When a change request is made, a new contract needs to be deployed to upgrade. [100][13]. BDRM includes information about design practices specific to blockchain technology to assist in developing high-quality smart contracts and addresses the challenge of smart contract code changes.

Additionally, the BDRM has an "11. Blockchain dApp verification" process, which includes testing type suggestions. This process also has suggestions for managing smart code execution and transaction fees. A cost (gas price) occurs while testing smart contracts in the Ethereum public blockchain's production environment [74]. Costs can be reduced by applying testing practices to a test network before deploying smart contracts in a production environment [101].

BDRM also has a potential to contribute to the standardization of blockchain technology. The International Organization for Standardization’s Technical Committee 307 [102] and FDA [103] are currently working towards developing standards for blockchain and distributed ledger technologies. Their efforts demonstrate a commitment to advancing the field. A process reference model like the one in this study would be a significant contribution to such standardization initiatives.

In this study, we have presented the Blockchain Health dApp Reference Model (BDRM) developed using the design science research (DSR) approach. The BDRM covers 15 processes and 68 practices required for developing blockchain applications in the healthcare domain. The model was developed in an iterative and incremental manner and built upon two comprehensive SLR and MLR studies. Different versions of the model were rigorously verified by experts to ensure the applicability, completeness, correctness, consistency, understandability, and usability of the model.

The BDRM successfully integrates the requirements of healthcare application development from the IEC 82304 [25], IEC 62304 [26], and ISO 14971 [27] standards with blockchain development processes and practices. It can be employed independently of any specific life cycle development model. By following the BDRM, developers can ensure regulatory compliance when building blockchain-based health applications, which would typically require significant time and effort for adaptation.

Furthermore, the BDRM can serve as a valuable example for researchers seeking to create tailored models for different domains.

Considering the early stages of standardization within the blockchain ecosystem, it is crucial to establish a systematic approach for guiding blockchain application development. To the best of our knowledge, our study pioneers the necessity of a process model in this particular area.

As part of our future work, we plan to conduct multiple case studies with healthcare application development companies to further explore the applicability of the BDRM.

Funding No funding was received for the work presented in this manuscript from any funding agencies.

Availability of data and materials The data utilized in this research are available from all the authors on request. The complete BDRM model is planned to publicly accessible after receving the copyright.

Confict of interest All authors declare that they have no confict of interest.

D. Yaga, P. Mell, N. Roby, and K. Scarfone, “Blockchain Technology Overview - National Institute of Standards and Technology Internal Report 8202,” 2018. doi: 10.6028/NIST.IR.8202.
W. Cai, Z. Wang, J. B. Ernst, Z. Hong, C. Feng, and V. C. M. Leung, “Decentralized Applications: The Blockchain-Empowered Software System,” IEEE Access, vol. 6, pp. 53019–53033, 2018, doi: 10.1109/ACCESS.2018.2870644.
State of the DApps, “DApp Statistics,” 2022. https://www.stateofthedapps.com/stats.
K. M. Khan, J. Arshad, and M. M. Khan, “Secure digital voting system based on blockchain technology,” International Journal of Electronic Government Research, vol. 14, no. 1, pp. 53–62, 2018, doi: 10.4018/IJEGR.2018010103.
A. Kumar, R. Liu, and Z. Shan, “Is Blockchain a Silver Bullet for Supply Chain Management? Technical Challenges and Research Opportunities,” Decision Sciences, vol. 51, no. 1, pp. 8–37, 2020, doi: 10.1111/deci.12396.
I. A. Omar, R. Jayaraman, K. Salah, M. C. E. Simsekler, I. Yaqoob, and S. Ellahham, “Ensuring protocol compliance and data transparency in clinical trials using Blockchain smart contracts,” BMC Medical Research Methodology, vol. 20, no. 1, pp. 1–17, 2020, doi: 10.1186/s12874-020-01109-5.
F. Schär, “Decentralized finance: on blockchain-and smart contract-based financial markets,” Federal Reserve Bank of St. Louis Review, vol. 103, no. 2, pp. 153–174, 2021, doi: 10.20955/r.103.153-74.
M. Hölbl, M. Kompara, A. Kamišalić, and L. N. Zlatolas, “A systematic review of the use of blockchain in healthcare,” Symmetry, vol. 10, no. 10, 2018, doi: 10.3390/sym10100470.
M. V. Baysal, Ö. Özcan-Top, and A. Betin-Can, “Blockchain technology applications in the health domain: a multivocal literature review,” The Journal of Supercomputing, pp. 1–45, 2022, doi: 10.1007/s11227-022-04772-1.
S. Shi, D. He, L. Li, N. Kumar, and M. Khurram, “Applications of blockchain in ensuring the security and privacy of electronic health record systems: A survey,” Computers & Security, vol. 97, no. January, p. 101966, 2020.
K. Fan, S. Wang, Y. Ren, H. Li, and Y. Yang, “MedBlock: Efficient and Secure Medical Data Sharing Via Blockchain,” Journal of Medical Systems, vol. 42, no. 8, pp. 1–11, 2018, doi: 10.1007/s10916-018-0993-7.
G. Tripathi, M. A. Ahad, and S. Paiva, “S2HS- A blockchain based approach for smart healthcare system,” Healthcare, vol. 8, no. 1, p. 100391, 2020, doi: 10.1016/j.hjdsi.2019.100391.
R. Koul, “Blockchain Oriented Software Testing - Challenges and Approaches,” 2018 3rd International Conference for Convergence in Technology, I2CT 2018, pp. 1–6, 2018, doi: 10.1109/I2CT.2018.8529728.
V. K. Chattu, A. Nanda, S. K. Chattu, S. M. Kadri, and A. W. Knight, “The emerging role of blockchain technology applications in routine disease surveillance systems to strengthen global health security,” Big Data and Cognitive Computing, vol. 3, no. 2, pp. 1–10, 2019, doi: 10.3390/bdcc3020025.
Schneier, “Smart Contract Bug Results in $31 Million Loss,” 2021. https://www.schneier.com/blog/archives/2021/12/smart-contract-bug-results-in-31-million-loss.html.
A. Vacca, A. Di Sorbo, C. A. Visaggio, and G. Canfora, “A systematic literature review of blockchain and smart contract development: Techniques, tools, and open challenges,” Journal of Systems and Software, vol. 174, p. 110891, 2021, doi: 10.1016/j.jss.2020.110891.
G. Destefanis, M. Marchesi, M. Ortu, R. Tonelli, A. Bracciali, and R. Hierons, “Smart contracts vulnerabilities: A call for blockchain software engineering?,” in International Workshop on Blockchain Oriented Software Engineering, 2018, pp. 19–25, doi: 10.1109/IWBOSE.2018.8327567.
P. Sylim, F. Liu, A. Marcelo, and P. Fontelo, “Blockchain technology for detecting falsified and substandard drugs in distribution: Pharmaceutical supply chain intervention,” Journal of Medical Internet Research, vol. 20, no. 9, pp. 1–12, 2018, doi: 10.2196/10163.
A. Takyar, “BLOCKCHAIN IN PHARMA SUPPLY CHAIN-REDUCING COUNTERFEIT DRUGS,” 2021. https://www.leewayhertz.com/blockchain-in-pharma-supply-chain/.
P. Chakraborty, R. Shahriyar, A. Iqbal, and A. Bosu, “Understanding the software development practices of blockchain projects: A survey,” in International Symposium on Empirical Software Engineering and Measurement, 2018, pp. 1–10, doi: 10.1145/3239235.3240298.
M. Marchesi, L. Marchesi, and R. Tonelli, “An Agile Software Engineering Method to Design Blockchain Applications,” in Software Engineering Conference Russia, 2018, pp. 1–8, doi: 10.1145/3290621.3290627.
C. Antal, T. Cioara, I. Anghel, M. Antal, and I. Salomie, “Distributed ledger technology review and decentralized applications development guidelines,” Future Internet, vol. 13, no. 3, pp. 1–32, 2021, doi: 10.3390/fi13030062.
L. Marchesi, M. Marchesi, and R. Tonelli, “ABCDE—agile block chain DApp engineering,” Blockchain: Research and Applications, vol. 1, no. 1–2, p. 100002, 2020, doi: 10.1016/j.bcra.2020.100002.
N. Nousias, G. Tsakalidis, S. Petridou, and K. Vergidis, Modelling the Development and Deployment of Decentralized Applications in Ethereum Blockchain: A BPMN-Based Approach, vol. 447 LNBIP. Springer International Publishing, 2022.
IEC 82304, “IEC 82304-1:2016 Health software — Part 1: General requirements for product safety,” 2016. https://www.iso.org/standard/59543.html.
IEC 62304, “IEC 62304:2006 Medical device software — Software life cycle processes,” 2006. https://www.iso.org/standard/38421.html.
“ISO 14971 Medical devices — Application of risk management to medical devices,” 2019.
S. Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008, doi: 10.1007/s10838-008-9062-0.
Bitcoin, “Bitcoin.” https://bitcoin.org.
S. Jha, “The Complete Guide for Types of Blockchain!,” Simplilearn, 2023. https://www.simplilearn.com/tutorials/blockchain-tutorial/types-of-blockchain.
“Food and Drug Administration (FDA).” https://www.fda.gov/home (accessed Dec. 11, 2019).
MDR, “European Commission - Medical Device Regulations,” 2017. https://health.ec.europa.eu/medical-devices-sector/directives_en.
G. Heidenreich, “Scope of IEC Health Software Standards,” 2014.
S. Porru, A. Pinna, M. Marchesi, and R. Tonelli, “Blockchain-oriented software engineering: Challenges and new directions,” Proceedings - 2017 IEEE/ACM 39th International Conference on Software Engineering Companion, ICSE-C 2017, pp. 169–171, 2017, doi: 10.1109/ICSE-C.2017.142.
A. R. Hevner, S. T. March, J. Park, and S. Ram, “Design Science in Information Systems,” MIS Quarterly, vol. 28, no. 1, pp. 75–105, 2004.
A. Hevner and S. Chatterjee, “Design Science Research in Information Systems,” pp. 9–22, 2010, doi: 10.1007/978-1-4419-5653-8_2.
K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A design science research methodology for information systems research,” Journal of Management Information Systems, vol. 24, no. 3, pp. 45–77, 2007, doi: 10.2753/MIS0742-1222240302.
M. V. Baysal, Ö. Özcan-Top, and A. B. Can, “Implications of Blockchain Technology in the Health Domain,” in Advances in Software Engineering, Education, and e-Learning, 2021, pp. 641–656, doi: 10.1007/978-3-030-70873-3_45.
ISO/IEC, “INTERNATIONAL STANDARD ISO / IEC 15504-5 An exemplar Process Assessment Model,” 2012.
ISO/IEC/IEEE 12207, “ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes,” 2017. [Online]. Available: https://www.iso.org/standard/63712.html.
K. Wust and A. Gervais, “Do you need a blockchain?,” Proceedings - 2018 Crypto Valley Conference on Blockchain Technology, CVCBT 2018, no. i, pp. 45–54, 2018, doi: 10.1109/CVCBT.2018.00011.
H. Anwar, “Blockchain Proof Of Concept : Enterprise POC Guide What Is Proof of Concept Blockchain ? Why Do Enterprises Need a Proof of Concept ?,” 2021. https://101blockchains.com/blockchain-proof-of-concept/.
P. Pandey and R. Litoriya, “Implementing healthcare services on a large scale: Challenges and remedies based on blockchain technology,” Health Policy and Technology, vol. 9, no. 1, pp. 69–78, 2020, doi: 10.1016/j.hlpt.2020.01.004.
A. Muniat, P. R. Ullah, and S. Mushsharat, “An Automated Approach towards Smart Healthcare with Blockchain and Smart Contracts,” pp. 250–255, 2021.
Y. Chen, S. Ding, Z. Xu, H. Zheng, S. Yang, and Y. Chen, “Blockchain-Based Medical Records Secure Storage and Medical Service Framework,” no. June 2017, 2019.
A. O. Bada, A. Damianou, C. M. Angelopoulos, and V. Katos, “Towards a Green Blockchain: A Review of Consensus Mechanisms and their Energy Consumption,” Proceedings - 17th Annual International Conference on Distributed Computing in Sensor Systems, DCOS 2021, pp. 503–511, 2021, doi: 10.1109/DCOSS52077.2021.00083.
T. P. Sean Au, Tokenomics: The Crypto Shift of Blockchains, ICOs, and Tokens. 2018.
Y. Zhuang, Y. Chen, Z. Shae, C. Shyu, and P. N. Hall, “Generalizable Layered Blockchain Architecture for Health Care Applications : Development , Case Studies , and Evaluation Corresponding Author :,” vol. 22, pp. 1–13, 2020, doi: 10.2196/19029.
Norwich University Online, “The 5 Pillars of Information Assurance,” 2018. https://online.norwich.edu/academic-programs/resources/the-5-pillars-of-information-assurance.
W. Vota, “10 Blockchain Implementation Risks in International Development,” 2019. https://www.ictworks.org/blockchain-implementation-risks/#.Y6oG13ZBxPY.
Deloitte, “Blockchain risk management Risk functions need to play an active role in shaping blockchain strategy,” 2017. [Online]. Available: https://www2.deloitte.com/content/dam/Deloitte/us/Documents/financial-services/us-fsi-blockchain-risk-management.pdf.
Investopedia, “51% Attack: Definition, Who Is At Risk, Example, and Cost,” Investopedia, 2022. https://www.investopedia.com/terms/1/51-attack.asp#:~:text=our editorial policies-,What Is a 51%25 Attack%3F,power to alter the blockchain.
M. Uddin, “Blockchain Medledger: Hyperledger fabric enabled drug traceability system for counterfeit drugs in pharmaceutical industry,” International Journal of Pharmaceutics, vol. 597, no. November 2020, p. 120235, 2021, doi: 10.1016/j.ijpharm.2021.120235.
H. Kaur, M. A. Alam, R. Jameel, A. K. Mourya, and V. Chang, “A Proposed Solution and Future Direction for Blockchain-Based Heterogeneous Medicare Data in Cloud Environment,” Journal of Medical Systems, vol. 42, no. 8, pp. 1–14, 2018, doi: 10.1007/s10916-018-1007-5.
Q. Zheng, Y. Li, P. Chen, and X. Dong, “An Innovative IPFS-Based Storage Model for Blockchain,” Proceedings - 2018 IEEE/WIC/ACM International Conference on Web Intelligence, WI 2018, pp. 704–708, 2019, doi: 10.1109/WI.2018.000-8.
A. Ellervee, R. Matulevicius, and N. Mayer, “A comprehensive reference model for blockchain-based distributed ledger technology,” CEUR Workshop Proceedings, vol. 1979, pp. 320–333, 2017.
Y. Gong, S. van Engelenburg, and M. Janssen, “A reference architecture for blockchain-based crowdsourcing platforms,” Journal of Theoretical and Applied Electronic Commerce Research, vol. 16, no. 4, pp. 937–958, 2021, doi: 10.3390/jtaer16040053.
A. Alketbi, Q. Nasir, and M. Abu Talib, “Novel blockchain reference model for government services: Dubai government case study,” International Journal of System Assurance Engineering and Management, vol. 11, no. 6, pp. 1170–1191, 2020, doi: 10.1007/s13198-020-00971-2.
G. Leeming, J. Cunningham, and J. Ainsworth, “A Ledger of Me: Personalizing Healthcare Using Blockchain Technology,” Frontiers in Medicine, vol. 6, no. July, pp. 1–10, 2019, doi: 10.3389/fmed.2019.00171.
Ethereum, “Ethereum.” https://ethereum.org/en/what-is-ethereum/.
Hyperledger, “hy.pdf.” https://www.hyperledger.org/blog/2019/12/02/hyperledger-for-healthcare-how-fabric-drives-the-next-generation-pharma-supply-chain.
Hyperledger, “Hyperledger Sawtooth.” https://www.hyperledger.org/use/sawtooth.
R. CORDA, “R3– distributed application platform.” https://r3.com/.
Quorum, “Quorum.” https://www.quorumsoftware.com/.
Ripple, “RippleNet.” https://ripple.com/.
A. Juneja and M. Marefat, “Leveraging blockchain for retraining deep learning architecture in patient-specific arrhythmia classification,” in 2018 IEEE EMBS International Conference on Biomedical and Health Informatics, BHI 2018, 2018, vol. 2018-Janua, no. March, pp. 393–397, doi: 10.1109/BHI.2018.8333451.
Vitalik, “An Incomplete Guide to SEO,” 2021. https://vitalik.ca/general/2021/01/05/rollup.html.
M. Schäffer, M. di Angelo, and G. Salzer, “Performance and Scalability of Private Ethereum Blockchains,” Lecture Notes in Business Information Processing, vol. 361, no. August, pp. 103–118, 2019, doi: 10.1007/978-3-030-30429-4_8.
“The Medical Device Directives,” European Comission. https://ec.europa.eu/growth/sectors/medical-devices/current-directives_en (accessed Dec. 10, 2019).
Leeway Hertz, “What is Zero Knowledge Proof and its role in blockchain?,” 2022. https://www.leewayhertz.com/zero-knowledge-proof-and-blockchain/#What-are-the-advantages-of-Zero-Knowledge-Proof.
E. Heilman, F. Baldimtsi, and S. Goldberg, “Blindly Signed Contracts: Anonymous On-Blockchain and Off-Blockchain Bitcoin Transactions,” in Financial Cryptography and Data Security, 2016, p. pp 43–60, doi: 10.1007/978-3-662-53357-4.
V. Castaldo, Luigi and Cinque, Blockchain-Based Logging for the Cross-Border Exchange of eHealth Data in Europe, vol. 821. Springer International Publishing, 2018.
Xilinx, “The Developer ’ s Guide to Understanding.” https://www.xilinx.com/products/design-tools/resources/the-developers-guide-to-blockchain-development.html.
M. H. Miraz and M. Ali, “Blockchain Enabled Smart Contract Based Applications: Deficiencies with the Software Development Life Cycle Models,” 2020. [Online]. Available: http://arxiv.org/abs/2001.10589.
M. Lahami, A. J. Maalej, M. Krichen, and M. A. Hammami, “A Comprehensive Review of Testing Blockchain Oriented Software,” International Conference on Evaluation of Novel Approaches to Software Engineering, ENASE - Proceedings, no. May, pp. 355–362, 2022, doi: 10.5220/0011042800003176.
B. B. Thompson, “Blockchain Testing Tutorial What is Blockchain ? Features of Blockchain includes Type of Blockchain Public Blockchain :,” 2022. https://www.guru99.com/blockchain-testing.html.
Z. Wu et al., “Kaya: A Testing Framework for Blockchain-based Decentralized Applications,” Proceedings - 2020 IEEE International Conference on Software Maintenance and Evolution, ICSME 2020, pp. 826–829, 2020, doi: 10.1109/ICSME46990.2020.00103.
“Ethereum Tester,” 2022. https://github.com/ethereum/eth-tester.
Trufflesuite, “Ganache: A Tool for Creating a Local Blockchain for Fast Ethereum Development.,” 2021. https://github.com/trufflesuite/ganache.
Hyperledger Composer, “Hyperledger Composer,” 2018. https://github.com/hyperledger/composer/releases.
ISO/IEC, “ISO/IEC 25030, Software Engineering — Software product quality requirements and evaluation (SQuaRE) - Quality requirements,” 2019.
A. Hafid, A. S. Hafid, and M. Samih, “Scaling Blockchains: A Comprehensive Survey,” IEEE Access, vol. 8, pp. 125244–125262, 2020, doi: 10.1109/ACCESS.2020.3007251.
R. Belchior, A. Vasconcelos, S. Guerreiro, and M. Correia, “A Survey on Blockchain Interoperability: Past, Present, and Future Trends,” ACM Computing Surveys, vol. 54, no. 8, 2022, doi: 10.1145/3471140.
S. Khan, M. B. Amin, A. T. Azar, and S. Aslam, “Towards Interoperable Blockchains: A Survey on the Role of Smart Contracts in Blockchain Interoperability,” IEEE Access, vol. 9, 2021, doi: 10.1109/ACCESS.2021.3106384.
Flowdevelopers, “Dapp Deployment Guide,” 2022. https://developers.flow.com/flow/dapp-development/deployment.
N. Prusty, Building Blockchain Projects. Packt Publishing Ltd., 2017.
X. Xu, I. Weber, M. Staples, X. Xu, I. Weber, and M. Staples, “Design Process for Applications on Blockchain,” Architecture for Blockchain Applications, pp. 93–111, 2019, doi: 10.1007/978-3-030-03035-3_6.
K. Sedgwick, “Bitcoin History Part 10: The 184 Billion BTC Bug – Featured Bitcoin News,” 2023. https://news.bitcoin.com/bitcoin-history-part-10-the-184-billion-btc-bug/.
Webmedy, “Advantages of Blockchain Technology for Healthcare.” https://www.youtube.com/watch?v=r5Eqdm9v2_E.
A. Musamih et al., “A blockchain-based approach for drug traceability in healthcare supply chain,” IEEE Access, vol. 9, pp. 9728–9743, 2021, doi: 10.1109/ACCESS.2021.3049920.
C. Esposito, A. De Santis, G. Tortora, H. Chang, and K. K. R. Choo, “Blockchain: A Panacea for Healthcare Cloud-Based Data Security and Privacy?,” IEEE Cloud Computing, vol. 5, no. 1, pp. 31–37, 2018, doi: 10.1109/MCC.2018.011791712.
D. Tith et al., “Patient consent management by a purpose-based consent model for electronic health record based on blockchain technology,” Healthcare Informatics Research, vol. 26, no. 4, pp. 265–273, 2020, doi: 10.4258/hir.2020.26.4.265.
A. Dubovitskaya, Z. Xu, S. Ryu, M. Schumacher, and F. Wang, “Secure and Trustable Electronic Medical Records Sharing using Blockchain,” in Annual Symposium proceedings. AMIA Symposium, 2017, vol. 2017, pp. 650–659.
Q. Lu and X. Xu, “Adaptable Blockchain- Based Systems: A case study for product traceability,” IEEE Software, no. 34(6), pp. 21–27, 2017.
O. Guti, G. Romero, P. Luis, A. Salazar, M. Charris, and P. Wightman, “HealthyBlock : Blockchain-Based IT Architecture for Electronic Medical Records Resilient to Connectivity Failures.”
A. Gharat, P. Aher, P. Chaudhari, and B. Alte, “A Framework for Secure Storage and Sharing of Electronic Health Records using Blockchain Technology,” ITM Web of Conferences, vol. 40, p. 03037, 2021, doi: 10.1051/itmconf/20214003037.
F. Hashim, K. Shuaib, and F. Sallabi, “Medshard: Electronic health record sharing using blockchain sharding,” Sustainability (Switzerland), vol. 13, no. 11, pp. 1–21, 2021, doi: 10.3390/su13115889.
J. Gong and L. Zhao, “Blockchain application in healthcare service mode based on Health Data Bank,” Frontiers of Engineering Management, vol. 7, no. 4, pp. 605–614, 2020, doi: 10.1007/s42524-020-0138-9.
Y. Xiao, B. Xu, W. Jiang, and Y. Wu, “The healthchain blockchain for electronic health records: Development study,” Journal of Medical Internet Research, vol. 23, no. 1, pp. 1–13, 2021, doi: 10.2196/13556.
C. Sillaber and B. Waltl, “Life Cycle of Smart Contracts in Blockchain Ecosystems,” Datenschutz und Datensicherheit - DuD, vol. 41, no. 8, pp. 497–500, 2017, doi: 10.1007/s11623-017-0819-7.
K. REES, “Use These 5 Ethereum Fee Calculators to Reduce Your Gas,” 2022. https://www.makeuseof.com/ethereum-gas-fee-calculators/.
ISO/TC 307 Participation, “ISO/TC 307 Blockchain and distributed ledger technologies Participation.” https://www.iso.org/committee/6266604.html?view=participation.
FDA, “FDA ’ s Technology Modernization Action Plan ( TMAP ),” 2019. https://www.fda.gov/media/130883/download.

No competing interests reported.

Download PDF

Version 1

posted

You are reading this latest preprint version

A Process Reference Model for Blockchain dApp Development for the Health Domain

Status:

Version 1

Abstract

Figures

1 Introduction

2 Background and Related Work

2.1 Background on Blockchain Technology

2.2 Health Domain Software Overview

2.3 Related Work

3 Research Methodology

4 The Blockchain Health dApp Reference Model (BDRM)

4.1 What are the core blockchain dApp development processes and practices?

5 Discussion

6 Conclusion and Future Work

Declarations

References

Additional Declarations

Status:

Version 1