Decentralization in blockchain refers to the situation where the ledger can be maintained without the need for any regulator (in the public blockchain context) and without the need for any trusted third-party arbitrator (in the private blockchain context) [35,36]. Ideally, the public blockchain is peer-to-peer and censorship-resistant. As the public blockchain can be operated without the need for any centralized authority, any person, with the help of web-based or mobile-based technologies, can join the blockchain as a user. A person or organization can participate in the public blockchain as a full node, which means they can keep a copy of the entire blockchain and take part in making the entire system fully decentralized across the globe. A private blockchain’s decentralization is mainly for running intraorganizational or interorganizational processes without the need for a third-party intermediary. Business processes can be operated in the form of smart contracts in the blockchain that require the participating departments or organizations to set the terms and conditions upfront. Private blockchain ledgers can be stored within the organization or across multiple organizations to provide a higher level of trust in the transactions.

A consensus mechanism is basically a way to mitigate the double-spending problem and to create a single truth among all the participating nodes or organizations of the blockchain [35-37]. The consensus mechanism helps the blockchain to remain decentralized across the participating entities. The main benefit of such a mechanism is that it makes sure the current state of the blockchain is the same for all participants, each of the blocks in the blockchain is properly linked with the previous block, and all participating entities can verify the block. Popular consensus mechanisms are Proof of Work, Proof of Stake, Round Robin, etc. In the private blockchain, the consensus mechanism largely depends on the participating organizations. As the private blockchain is mainly useful to store information about operations that can impact multiple organizations, the consensus can also be based on a defined contract.

The data stored in the blockchain are tamper-proof and immutable [35,37]. With the help of the consensus mechanism, the blockchain creates a single truth across all the nodes, and thus, it is computationally impossible and infeasible to alter the data that have already been stored in the earlier blocks. Each block contains some transactions, and based on those transactions, a cryptographic hash is created. That cryptographic hash is used to connect the block with the most recently verified block. When a piece of data on a block is altered, the hash gets changed and the block containing the altered data gets isolated from the blockchain. The tamper-proof and immutable feature of the blockchain can be found in both public and private blockchain-based solutions. This benefit of the blockchain increases the security of the data and digital assets on the ledger.

Following the modeling design process theory [42], the overall design cycle adopted in this paper starts with problem awareness and scope, followed by suggestions from both academic and industrial practices (Figure 2). Considering the user-centric design paradigm, more than purely technical factors, this paper adds a new dimension in the second stage, which is user requirement collection. Following that, we have developed innovative IT artifacts to provide the functions and platform implementation. As such, we have presented overall DSR outcomes and contributions as follows, which distinguish this paper from previous work.

While there are applications available to support telehealth services, there are few guidelines for decentralized implementation. Based on blockchain characteristics and the needs associated with telehealth services, we have proposed a set of smart contract–driven telehealth DPs from the design requirements collected from user experiments and academic or industrial initiatives.

We have designed and presented 2 artifacts that can facilitate both user end (frontend) and backend system integration with blockchain technology, namely, the user credential management function and the access control function, which can be driven by underlying smart contracts. The proof-of-concept project demonstrates the feasibility and verifies the usable potential of the proposed concept and design theory. We have followed the reporting guidelines suggested by [43] and have provided a checklist in Multimedia Appendix 2.

From the design of the artifacts, we have presented a reflection of the design and performed an evaluation of the proposed design in terms of security properties and functionality performances, followed by a summary of the lessons learned and contributions to DSR theories.

In our examination of the current landscape of telehealth, we analyzed both academic literature and practical applications across the industry. Our findings indicate that the telehealth sector is in the early stages of both development and adoption. A range of functionalities have been explored in prior research, including access to medical data, processing of medical services, video conferencing capabilities, epidemiological reporting, support for diagnostics and treatment, aggregation of patient data, scheduling of visits, ordering of medications, and integration of payment and fundraising systems [44]. This study focuses on the identity management and communication aspects of telehealth services.

This study selected 2 features, which patients care the most about according to our user study related to security and privacy, including the user credential management functionality and access control functionality. The user credential management functionality has a design that incorporates user motivation as well as the ability to adapt to new technologies or platforms. Meanwhile, the access control functionality follows the principle that users are respected in terms of their privacy and data security.

There are 2 categories of participants interviewed during the design requirement collection process, namely, general users (patient side) and subject matter expert users (health provider side). The research included data from 20 general users and 5 expert users within the United States and Europe, and the demographic characteristics of these respondents are shown in Multimedia Appendix 3. On average, the interview with general users took 71.06 minutes and that with expert users took 66 minutes.

From the design of the artifacts, we have presented a reflection of the design and performed an evaluation of the proposed design in terms of security properties and functionality performances, followed by a summary of the lessons learned and contributions to DSR theories. Specifically, we have assessed performance metrics, such as transaction throughput, smart contract execution time, and block generation time. Our security analysis evaluated the resilience of the system against common attacks prevalent in telehealth systems.

We have adopted a user-centric design approach and have started with user requirement collection. We have used the information in the report by Chanson et al [45] for developing the requirements. With the analysis of the collected data, we have moved forward to design the system functionalities that can facilitate user requirements, thus promoting user behaviors toward the telehealth platform. The purpose of the interview study is to inform the design process in terms of user requirements from both general users and expert users for a privacy-preserving telehealth solution. The interview questions are related to prior experience of use or potential functionality expectations from a telehealth artifact.

In the development of design requirements, we have employed qualitative methods to analyze responses from our interviewees. We have used a thematic analysis approach to interpret the interview data. Our first step involved transcribing the interviews and reading the transcripts multiple times to gain a deep understanding of the content. We performed initial coding in an inductive manner, where codes were generated from the data without trying to fit them into a pre-existing coding frame. This allowed emerging themes to be grounded directly in the interview data. After coding, we grouped related codes into potential themes. These themes were continually reviewed and refined to ensure they accurately represented the data. This part of the analysis was iterative, as themes were defined and redefined through discussions among the research team members. Each theme was then reviewed in the context of the coded extracts and the entire data set. This was to ensure that themes were coherent, consistent, and distinct. We finalized themes by defining and refining their specifics and how they are related to the user requirements in telehealth. This step involved a detailed analysis of each user requirement captured.

In the system implementation section, following the design evaluation guidelines proposed in [30], we have evaluated our artifacts using both the descriptive evaluation method and analytical evaluation method for the security domain, and the experimental evaluation method for the performance domain.

From the patient or user-centric standpoint, we retrieved the following 4 features from the survey as design requirements: data ownership, data sharing, self-sovereign identity (SSI) capability, and system monitoring with user notifications (Figure 3).

For system functions in the telehealth scenario, we have considered 4 aspects, including architecture, data operation, integration, and interoperation among systems, which will be improved for the adoption of the blockchain component. Moreover, for the security of user accounts and access management, the system functions will include authentication and access control. Detailed descriptions of each function are presented below (Figure 4).

Physicians can use this application to manage their physician credentials (Figure 7). Patients can use the application to manage their telehealth functions such as appointment booking and prescription handling (Figure 8). An SSI-based identity wallet has been implemented to capture or verify user identity proofs. It stores user data on the blockchain platform by using SSI proofs. All services are dockerized and available to deploy with Kubernetes [55]. The Dokka platform is built on the microservice architecture [56] to support high scalability and high transaction load following the single responsibility principle. To cope with high transaction loads and back-pressure [57] operations in practical systems, we have followed a reactive stream–based approach in the implementation process. All microservice communications are handled via the Apache Kafka message broker. The functionalities of the blockchain have been implemented with Aplos smart contracts. There are 3 main smart contracts: account contracts, device contracts, and credentialing contracts. The Dokka mobile wallet is the client application on the Dokka platform. The functions implemented in the blockchain smart contracts will be invoked by mobile clients. The requests generated from mobile apps will be directed to blockchain smart contracts via the Dokka gateway service. There is a peer-to-peer communication channel between Dokka mobile wallets to exchange credential data.

A missing design component in existing studies is the access control mechanism in telehealth platforms. This project adopts token-based access control to secure personal health data access and exposure. The access control policies are enforced by blockchain smart contracts in a decentralized way to ensure integrity and remove the necessity of a trusted third party. Various stakeholders can request data access from the data owner, that is, the registered user in the system. Users have the option to grant, deny, and revoke access from other participants. User registration is based on U-Prove technology [58], which includes 3 entities, namely, issuer, prover, and verifier. In our implementation, the issuer and verifier represent the same entity. Parameter definitions for both the prover and issuer in the token generation phase are listed in Table 2.

With the above information provided, we have used issuance protocol version number 0x01 and the user platform identification key to generate a private key in the token generation protocol (Figure 9). For each telehealth request, the user will generate an access token for the requester. The algorithm supports the generation of multiple keys for a single user for better performance. The Dokka platform nodes issue tokens to users with a digital signature. For privacy concerns, the application attributes are hashed for the generation of U-Prove–based tokens. During certain circumstances, the issuer can generate multiple tokens at one time for better performance.

From the analytical perspective, our security design is baked into the overall telehealth architecture. Based on the attack surface analysis of the telehealth platform, we have considered the authentication, communication, and auditing processes. According to the design blueprint for a large-scale telehealth platform [53], 5 layers are taken into account. Using smart contract–driven methodology, this paper improves the security level for each layer, including user authentication, user credential verification, access control, data protection, and auditing (layers 1-5). Users interact with layer 1 directly, and this is the initial step for the telehealth service. During this phase, users are authenticated by the blockchain network via an SSI-enabled identity verification process. Layer 2 determines the appropriate access control policy, and the tokens are issued in this step for both patients and stakeholders. Specifically, the tokens are periodically refreshed to defend against replay attacks, man-in-the-middle attacks, stolen verifier attacks, and impersonation attacks [34]. Layer 3 functions on top of the issuance of the tokens, and access is granted automatically via smart contracts. Users can perform data-sharing operations with other parties in layer 4 with appropriate cryptographic settings. The auditing process in layer 5 monitors all the activities in this process and automatically generates alerts once a malicious behavior is detected. The auditing process is captured by smart contracts so that the log is tamper-resistant.

As pointed out in [53], the user registration and identification verification layer is the frontend layer, which is a representative artifact of user-centered design. Thus, we have analyzed the security properties provided by the user registration and identification verification process here from a descriptive perspective. The critical identity information could be accessed by attackers via technical approaches such as key compromise and identity theft. Impersonation attacks are typical cases of identity manipulation attacks, which can be launched via identity theft or credential compromise. If attackers get access to previous account tokens, they could recognize or identify a pattern from these tokens, and thus, valid tokens could be compromised eventually.

For the token-based access control component, there are potential attacks such as replay attacks. Smart contracts will provide preventive measures against token-related attacks by the enforcement of automatic program execution and peer validation of tokens. In this way, the replay attack will fail due to unauthorized access and the consensus protocols designed for peer validation. For the video conferencing component, there are potential attacks, such as man-in-the-middle attacks and impersonation attacks, but the peer-to-peer communication process is well protected by the underlying smart contracts and cryptographic algorithms.

In summary, the proposed design provides resistance against common attacks targeting general user communication processes with multiple stakeholders involved. Specifically, the design provides resistance against replay attacks, collusion attacks, man-in-the-middle attacks, stolen verifier attacks, and impersonation attacks [34].

Technically, the blockchain can support telehealth platform functionalities; however, previous studies have mentioned that the blockchain’s scalability is currently limited [59]. We evaluated the performance in terms of transaction throughput, smart contract execution time, and block generation time. Besides, the scalability and throughput of blockchain transactions have always been concerns and bottlenecks for system processing capability. In the following experiments, we will investigate these different aspects of system performance and compare them with existing solutions. There are 3 Kafka broker nodes for consensus management, with 3 Zookeeper nodes representing service providers in Dokka with multiple Rahasak blockchain clusters in AWS 2xlarge instances (16 GB RAM and 8 CPUs). The simulation platform uses Apache Cassandra as the state database and is implemented with Scala functional programming and the actor-based Aplos smart contract platform. The evaluation results are obtained with a varying number of blockchain peers in different evaluations.

For transaction throughput, we recorded the number of digital identity proof create transactions and digital identity proof query transactions that can be executed in each peer in the Dokka platform. Digital identity proof query transactions and invoke transactions generate transaction records that update the status of the ledger, while query transactions only perform search operations without updating the existing transactions. We obtained consistent throughput in each peer on the Dokka platform, flooded with concurrent transaction load (Figure 10). Similarly, we recorded the time cost to execute and validate different sets of transactions (Figure 11), which indicates an acceptable and linear time overhead.

Figure 12 shows the transaction scalability aspect. As the number of nodes in the cluster increases, the transaction throughput increases linearly. Query transactions have higher scalability than invoke transactions since the query operation avoids ledger status updates. To evaluate the transaction execution rate, we captured the number of transactions executed using different numbers of blockchain peers. Figure 13 shows that when the number of peers increases, the transaction execution rate increases proportionally.

Figure 14 shows the transaction execution rate and transaction submission rate in a single peer. The results are satisfying with regard to the stable performance over time. Moreover, the average time to generate new blocks is recorded against the number of transactions in a block. Block generation time depends on the message propagation time, block hash time, and transaction verification time. When the number of transactions increases in a single block, these factors will increase. Therefore, when the number of transactions increases, block generation time also increases correspondingly. As shown in Multimedia Appendix 4, it takes 8 seconds on average to create a block with 10,000 transactions.

Try to focus on the human experience and consider the actions and needs of patients who will use the portal and not just focus on the technical aspects of the system design. Recognize the importance of collaboration with patients to ultimately deliver an impactful experience. User-centric design will benefit every stage of the research, from testing and validation to solutions, in order to meet user needs. Consumer preferences will play an important role in the transition from the pandemic period to the postpandemic period [60]. The blockchain integration process is hidden from users, and most of the time, users are not required or not aware of their actions to interact with blockchain networks. Thus, when designing smart contracts, try to optimize the workflow with user-centered principles and provide maximized simplicity.

Business processes are not standalone; thus, it is very important to reuse the components of blockchain integration and share the common design artifacts across the system development lifecycle. For health care providers, there is always a need to minimize costs without reducing the quality of the services provided to customers [61].

Security design should be baked into the entire lifecycle of telehealth design. Specifically, data management and access control policies should be enforced across the system components involved in patient data operations. Along with deployability, scalability, reliability, and ease of use, patient trust should be taken care of so that users are motivated to adopt the telehealth platform at their comfort level. Do not oversimplify the process, and try to understand the business value up front and focus on long-term benefits.

End users can provide feedback about the current iteration of the portal to inform future improvements that will meet their needs. Considering complicated patient demographics and enabling various functionalities in multiple rounds of iterations will boost patient enrollment and engagement [62]. Evaluate different platform options and product features to best suit the business use cases for telehealth innovations.