1. Introduction
Healthcare games have seen a rapid growth [
1,
2,
3,
4,
5,
6] in building viable digital treatments for different medical conditions. In 2018, Boston Children’s hospital raised USD 2.4 Million in seed funding [
7] to develop Mightier, a biofeedback game intending to help children manage their emotions through gameplay as a prescription. The healthcare scene has pivoted its focus to attempt offering more scalable therapy solutions for elders at home. Healthcare games are increasingly recognized as a viable solution to treat many aging-related problems where no effective medication is available [
8]. The healthcare game industry is projected to continue expanding at an accelerated rate, with the expected global market reaching USD 9 Billion by 2031 [
9]. Educational purpose software including games is different from healthcare games that involve patient safety. Medical treatments such as medication, therapeutic intervention, etc., [
10] will be prohibited from being marketed for medical use before FDA approval. Any claims of medical benefits must be evaluated and approved by the FDA [
11]. As a new or complimentary treatment, serious games are increasingly used in healthcare, apparently the evaluation will be of great importance. In 2021, FDA approved its first healthcare game EndeavorRX, a tablet video game as a non-drug prescription treatment for children aged 8–12 years old diagnosed with Attention Deficit /Hyperactive Disorder (ADHD) [
12,
13].
The FDA approval process for healthcare games is complex and long drawn, of which various phases of clinical trials are necessary. In the case of EndeavorRX, it took 2.5 years to review clinical trials data from more than 600 patients [
14]. Clinical data was collected by each patient playing 25 min per day, 5 days per week for nearly a month. It was very important that clinical efficacy data from five clinical trials were examined on safety, efficacy, and clinical benefits to patients in the novel FDA process [
13]. Research data from multiple studies were evaluated to demonstrate the improvements in each participant after the gameplays along with certain time spans using various assessment tools, before securing the FDA approval. It sought approval clearance through FDA’s de novo pathway [
15], which is a regulatory process for new medical devices deemed to have low-to-moderate risk. The success of EndeavorRX in obtaining FDA approval and marketing as a digital therapy solution opens a new regulatory pathway for other healthcare therapy game developers. This sets a precedent for future healthcare games to go through the same vetting process to offer evidence-based treatment for patients [
14]. However, the long time required for the FDA approval of healthcare games is a significant hurdle for game developers. The data transparency and data integrity of the clinical efficacy data for the healthcare games are also very important in the FDA approval process.
Concurrently, blockchain technology [
16,
17,
18,
19,
20] has seen more applications to integrate record transactions or supply chain tracking over the last decade in industries like real estate, automobile, financial sector, and pharmaceutical, etc. Multi-stakeholder data could be transformed and shared by blockchain networks, with its abilities of delivering fully transparent ledgers. In the healthcare industry, there has been growing research interest to utilize blockchain technology for privacy-preserving data sharing [
21], security issues [
22], and decentralized data storage [
23,
24]. Healthcare data remains one of the most crucial data, since it handles private medical information and other records. Secure infrastructures would be required to ensure that the data does not get exposed to malicious actors. It requires high security measures to protect them. However, data breaches by cyberattacks have been witnessed in various countries. In 2018, SingHealth system in Singapore experienced its worst cyberattack, with up to 1.5 million patients having their personal information and the outpatient prescription records of nearly 160,000 patients leaked in this data breach [
25]. Globally, this is a crisis that affects numerous countries, and in research conducted by Fortified Health Security, the American healthcare sector alone suffered about 337 breached in just the first half of 2022, with more than 19 million records implicated in the data breach [
26]. Protecting patient data and ensuring strong security when handling such sensitive information is very important to the digitalization of healthcare industry.
This research will focus on resolving such challenges and providing possible solutions using emerging technology. Blockchain technology is first identified as a possible solution that can offer a secure, immutable, and anonymous solution to share private patient data and provide data security. Next, this research is to address the possible market gap leveraging on the decentralized ledger of blockchain networks for healthcare applications: (1) Healthcare games deposition; (2) Healthcare game data collection and storage; (3) Data analytics for clinical trials and treatment monitoring; and (4) A secure form of data transparency among different stakeholders. This research is suggesting to use the blockchain technology for the purpose of healthcare games evaluation and to take advantage of its decentralization, transparency, and other benefits. Different stakeholders of healthcare games including developers, healthcare professionals, volunteers, patients, etc., can keep their data and information with the proposed framework called Healthcare Game Blockchain (HGB). The entire process can provide an alternative solution of evaluation and approval for healthcare games. A simple use case is further presented in this research with a proof-of-concept (PoC) application developed to illustrate the proposed HGB framework. HGB is a common platform built on top of blockchain community with four different types of users: (1) Healthcare game developers; (2) Clinical trials authority; (3) Healthcare providers; and (4) Patients.
Hyperledger is an open-source distributed ledger technology solution and one of the prominent mechanisms, providing a permissioned ledger that supports smart contracts written in various programming languages like Python, Java, Node JS, etc. Hyperledger is a pluggable framework built for cross-industry purposes and does not rely on a native token. This provides the necessary flexibility for our use case. In this research, an PoC example of HGB is developed on the Hyperledger Sawtooth blockchain [
27,
28]. It is selected to experiment on due to its viable mechanism to increase the pace of development, without learning a new programming language. Hyperledger has a Sawtooth branch, which separates the application layers from the core system layer. It allows developers to build applications using development languages of their choice and to define their own custom transaction families for the specific requirements of the applications. The PoC will demonstrate how clinical trial authority can pull trial data from healthcare games deposited on HGB by healthcare game developers, and how patients can seamlessly contribute their data following the instruction of healthcare professional by playing the healthcare games stored on HGB. Personal health information is encrypted and stored securely and can only be decrypted by patients themselves. While game data can be shared seamlessly on the immutable ledger to provide legitimate research data for clinical trial authority.
2. Background Knowledge and Related Work
Hyperledger uses the permissioned ledger that supports smart contracts written in various programming languages like Python, Java, Node JS, etc. Corda is another example of permissioned blockchains. Hyperledger has a Sawtooth branch, which separates the application designed by developers from the system cores. It allows developers to build applications using programming languages of their choice. Each application would define their own customized transaction families for specific requirements.
Combining with Internet of Things sensors, robotic process automation, and machine learning or artificial intelligence, blockchain technologies are able to track and catalogue the status of supply chains with data analytics capabilities [
29]. Data transparency of supply chains could improve decision-making process. For example, Walmart collaborated with IBM to improve its food supply ecosystem using blockchain technology, Hyperledger Fabric system [
30]. There are more than 1500 active cryptocurrencies using different consensus algorithms to weed out unreliable nodes for maintaining the reliability. There are three mostly used consensus mechanisms: Proof of Work (PoW), Proof of Stake (PoS), and hybrid consensus strategies such as Proof of Authority (PoA) [
31,
32].
In 2018, the Blockchain Game Alliance was established to explore more benefits that blockchain technologies can bring to traditional video games. Blockchain games can be categorized as three main types according to benefits brought by blockchain mechanisms [
33]: (1) Rule transparency: game rules can be audited by third parties, as they are no longer hidden in centralized servers like traditional games, which enhances the trust by players and third-party auditors; (2) Asset ownership: blockchain games can enable players to own digital assets in-game independent of game operators, which stimulates players to engage with game economy, while offering monetization business models for game operators when the values of their issued tokens rises; and (3) Asset reusability: as blockchain game assets are owned by players themselves, it allows players to reuse their assets and in-game characters in other games on the same blockchain. It greatly expands the capabilities of games that a single developer can create.
Traditional video games typically have game servers and clients. Games are operating on remote servers to render game scenes streamed real-time to players through internet connections. Players access the games interactively on their light-weight digital devices. With high-speed internet and cloud computing, online games are also hosted on cloud servers in data centers [
34]. Different from traditional video games, blockchain games require game players to register themselves with an address in the blockchain, before playing games. The registered address can be accessed by a blockchain wallet that serves as a unique identity of the player. It is also utilized to collect virtual game assets belonging to the players. Core functions such as virtual game asset manipulation or game rules enforcement can be automated as smart contracts on the blockchain, keeping these items transparent and immutable.
The game server thus offers an additional important role in the blockchain games architecture. On top of acting as a game service provider, it also holds the smart contracts guiding the blockchain games with any blockchain data stored immutably on its digital ledger. Game clients would retrieve any game data from the blockchain, by leveraging on the search and authentication capabilities of the game server [
35].
3. Healthcare Game Blockchain
The goal of this research is to create a blockchain where different participants are able to view immutable information on the secure platform. Only game players or game developers can add more data blocks to the blockchain. In this case, the permissioned blockchains would be the most ideal type for this research, where different participants are granted different access rights based on their identity verification outcomes. Hyperledger Sawtooth blockchain is a suitable candidate, as it supports various programming languages. The PoA consensus mechanism is selected for this research, due to its scalability and emphasis on identity verification.
HGB to be developed allows different stakeholders having different access rights to game data stored, to ensure a secure protection of sensitive information, while with transparent access to game data. The Unified Modeling Language (UML) use case diagram is created as shown in
Figure 1.
Four key stakeholders are identified for HGB: game developers, healthcare providers (e.g., doctors or medical specialists), patients (i.e., game players), and approving agencies like FDA (or healthcare researchers).
Game developers release their games onto the blockchain for patients to play games. Game developers have access rights to game data. But they can only see encrypted keys of patients on the blockchain and are unable to decrypt patient information.
Healthcare providers can recommend healthcare games as a prescription to patients. They will create medical records for patients stored on the blockchain. Both healthcare providers and patients hold a decryption key to their medical records. Patients would play these games that automatically upload gameplay data onto the blockchain. Healthcare providers can retrieve these game data from the blockchain for the analytics.
Patients are able to access healthcare games. A user key and a decryption key will be provided for them to access their encrypted information. Patients can view their own personal information, game data, and post-game scores stored on the blockchain.
Approving agencies or healthcare researchers are interested in data gathered by patients. They can use these in-game data for approval or research purposes. They will only have access rights to in-game data and post-game scores but cannot decrypt player profiles to identify the individuals.
The UML activity diagram shown in
Figure 2 illustrates a scenario involving different stakeholders. Patients would visit their medical specialists for medical conditions. Gamified prescription methods are available as an alternative to oral medications. Once prescribed, the medical specialists will create accounts for the patients on blockchain, containing their medical records. New patient credentials will be authenticated to access the blockchain. The medical specialists and patients can view the medical records and gameplay therapy logs to check the patients’ progress and monitor for improvements in their behaviors. During follow-up medical consultations, medical specialists can retrieve patients’ gameplay results and track the frequency of self-administration of the gamified prescriptions. It can happen over an extended period as the patients undergo treatments. The data will be stored permanently and immutably on the digital ledger. Externally, approving agencies like the FDA or healthcare researchers may want to access these gameplay data to observe positive trends in patients undergoing such treatments, without revealing individual patients’ identities for privacy concerns.
With different activities and tasks being involved with these stakeholders, the overall proposed design flowchart of the HGB is shown in
Figure 3. It illustrates the procedure of healthcare games from the development stages and the gameplay by patients to the game data being stored in the blockchain of the HGB system. Unity3D design tool is commonly used in the game development industry. Healthcare games are developed in Unity3D that can be released and added in the HGB, for patients or volunteers to play with. Relevant game data, players info, and timestamps will be created and hashed as transaction blocks in the blockchain by smart contracts that are built using the ThirdWeb SDK [
36] and stored in blockchain using unique block addresses. The smart contracts that guide the blockchain of the healthcare games store and retrieve the blockchain data immutably on its digital ledger. The design of HGB ensures the data integrity where medical records and profile of patients are kept immutably on the platform. The information of any change history by anyone for an individual data will also be recorded permanently. It provides an additional level of security and reassurance to prevent information tampering for all parties. It is capable of illustrating the clinical efficacy data being reliable and trustable in the various clinical trial stages and is quite important for the approving agencies or healthcare researchers for clinical evaluations or outcomes analysis. Specifically, they may also access specific gameplay sessions if there are any anomalies spotted, for a deeper understanding of the reasons that contributed to such behaviors.
There are two design approaches that can be leveraged on when building a PoC blockchain. As one design approach, a blockchain mechanism is built from scratch using Python language by leveraging on the Flask web development framework. We will illustrate how a blockchain can be developed with hashing to encrypt each block, using a PoW consensus mechanism to chain new blocks. As the other design approach, we build it with Hyperledger Sawtooth and REST API architecture for simplicity, to show how simple games can be implemented on a blockchain. Encryptions of patients and players data are conducted in the chain. In this research, both design approaches are attempted in order to identify which is more suitable for this use case.
3.1. First Design Approach—Starting from Scratch
We use Python and Flask to build a simple blockchain from scratch, with the SHA256 encryption algorithm. The block is defined as containing five properties: index (patient ID), proof, previous block hash, transaction data to be stored, and timestamp. Each block is generated in a similar way, except for the first block, i.e., genesis block. For the genesis block, the input values of proof and previous_hash are set to integer 0, as it is the first block in the chain.
Next, a get_block_hash (index, proof, previous_hash, transactions, and timestamp) function creates the hash with SHA256 algorithm by taking in the inputs from each block. where one single hash value is derived for each block. Embedding the previous block’s hash increases the integrity of the chain. The chain of hashes thus becomes the cryptographic proof to ensure that existing blocks cannot be easily replaced or removed. Changing even one property within the block would completely change the output of the hash function.
To make new transactions for blocks, the create_new_transaction (sender, recipient, and amount) function passes three parameters: sender address, recipient address, and the amount to be sent. These transactions are appended to the node_transactions list. The node_transactions list will be assigned when a new block is mined. The list gets reset when the new block is mined successfully. Authenticating the validity of new transactions using private keys will be conducted to prevent forgeries. It ensures that the transactions are actually sent from a verified and authentic node. Private keys ensure that a node can produce its own digital signature, as a form of identity verification that cannot be replicated by other nodes.
We rely on a PoW system to implement a digital ledger that preserves the chronological history of the blocks in the chain based on the transaction time. If someone modifies an existing block in the chain, they have to redo the work for all blocks. We created a simple consensus function where we assume that the longest chain in the blockchain is the most accurate. In reality, it is hardly ever the case. But for the sake of the simple PoC demonstration, we will use this assumption as our means of verification. Thus, in the consensus function, if there are longer chains found, then the existing chain will be updated to be the same as the longest chain.
This simple PoC allows us to understand how we can build a blockchain mechanism from scratch using common development packages like Python. This provides a lot of potential for future work to integrate more use cases, such as the logging and sharing of healthcare data. In this POC, a simplified version for the capabilities of building a blockchain from scratch using Python and Flask. The downside of this approach is that more development efforts and time are required to build the blockchain from scratch.
3.2. Second Design Approach—Using Hyperledger Sawtooth
To illustrate the possibility of building a PoC prototype of the HGB in quicker yet safe ways without coding from scratch, we leverage the unique features of Hyperledger blockchain in the second design approach that uses Hyperledger Sawtooth, an existing pluggable framework for blockchain development. Users are onboarded with invitation-only basis who have to go through an identity verification process for the blockchain. Different types of user permissions could be granted to different users of the blockchain, based on their verification outcome. Hyperledger Sawtooth requires a local Sawtooth node to be set. The architecture of a node is shown in
Figure 4, consisting of the REST API, validator, consensus engine, and three transaction processors [
37]. With the IntegerKey transaction processor, users can set and change the value of entries. The settings transaction processor enables storing on-chain configurations. The XO transaction processor allows playing various simple board games. We will be using Docker containers for the clients to run Sawtooth commands of the nodes.
Proof-of-concept shows how simple games can be implemented on a blockchain. In this research, a PoC blockchain is built with Hyperledger Sawtooth nodes to play a simple game of tic-tac-toe, where two players will take turns to mark their moves on a 3 × 3 grid. Two players will mark their space with X and O, respectively, to represent their moves. The game is won by marking three spaces adjacent to each other, in vertical, horizontal, or diagonal row faster than the opponent. A tied game is also possible if all spaces on the grid have been filled but no player has won.
For this implementation, a backend server is used to host the game. This server communicates directly with a blockchain node using the Transmission Control Protocol (TCP). It does not use any traditional database storage since there is minimal data to store. This server exposes several endpoints where game clients can create, view, and play this game.
Clients communicate with the transaction processors through the REST API at the TCP port 8008. In this work, two players named Jack and Jill involve the gameplay as an example. The transaction log records every single transaction. Each command sent by players is individual transactions on the blockchain. Each successful transaction would update the global state consisting of five elements: game-name, player 1-key, player 2-key, game-state, and board-state.
When a player takes a turn to select a position on the game board, the transaction processors will verify that the username of the player matches the expected name of the player in turn. It verifies that no player will skip a turn ahead. After each turn the transaction processors check the board-state for a win or tie. If neither occurs, then the game continues. Otherwise, no further actions can be taken by the players, as the game is considered ended.
First, the player Jack creates a new game called “my-game” on the blockchain. A single game with an empty game board exists on the server. Its transaction log is shown in
Figure 5a. When Jack takes a place on the game board, the REST API calls the XO game processor in the backend. Jack is allocated as Player 1 and his profile is shown in-game as an encrypted key. The transaction logs are shown in
Figure 5b.
A second player, Jill joins the game using the same TCP port: 8008, and she is allocated as Player 2. She takes a position on the game board. Her profile is displayed as an encrypted hash as shown in
Figure 5c. The two players can continue taking turns to make movements on the board according to game rules, until a win or draw is achieved, as shown in
Figure 5d.
The Hyperledger Sawtooth allows us to integrate games onto the blockchain. The game data and gameplay commands create blockchain transactions that are stored immutably on the blockchain in the encrypted way. This can be useful for authority approval and research purposes with keeping track of players performance especially for healthcare games. The data capturing process and auditing also offers capabilities for automation of clinical trials.
3.3. User Interface and User Experience Design
For the prototype of the HGB, a user interface and dashboard are required for all stakeholders to login. Since the blockchain platform is used collaboratively by different stakeholders, depending on which profile logs into the network, they will see different views to their specific use cases. To better understand information that is required by each stakeholder upon log in,
Table 1 shows a breakdown of expected user actions.
The user interface has been designed for the HGB. User accounts can be created using unique email addresses. In the login page, users do not need to indicate user types, such as medical practitioners, patients, or researchers, as the backend of HGB will assign a user type to them during account creations.
After logging in HGB, medical practitioners can click on the “Add a Patient” button to create a new patient profile. The medical practitioners’ view can check any new patient sessions that have been completed since their last login, shown in
Figure 6a. This allows them to stay updated with their patients’ progress and monitor any follow-up sessions. The medical practitioners’ view can also access patients’ medical records and therapy session records in detail.
Once a medical profile is created, the patient will receive instructions sent by email. Patients’ medical profiles will be stored in the HGB as immutable data. Should the medical practitioners edit patient profiles next, the edit history will also be permanently stored on the blockchain.
An example dashboard for the patients’ view is also designed, shown in
Figure 6b. But for the complete system implementation, the dashboard should be able to show the target metrics that clinical trials are trying to achieve and the actual current scoring of patients.
4. Discussion and Conclusions
This paper highlights a potential application of blockchain technology in healthcare games to provide a more secure, encrypted, automated, and reliable source of truth. It can find various use cases, to help to audit healthcare games, aid clinical trials, and authority approvals.
To use healthcare games as alternative medical treatments, game prescriptions require constant auditing to ensure that the games bring positive results for the corresponding conditions. It is important to check for unintended side effects periodically, just like any other newly released pharmaceutical medications. For healthcare games, the audits can enable game developers to improve their games iteratively based on gameplay feedback. The characteristics of HGB can enable it efficiently or even automatically. With the immutability of blockchain ledgers, we can ensure that data pulled from games are not manipulated or modified. Smart contracts in blockchains can be built to automatically retrieve and store game data as transactions in blocks. It could accelerate the development of the healthcare game industry by automating many menial tasks that currently rely on manual labor.
Newly developed healthcare games would be subject to evaluation and approval by overseeing authorities before mass production. Currently, this authorization process is manual with extremely long timelines. Blockchain platforms offer a possible way for verification and authentication of game data legitimacy. Sensitive information can be hashed and hidden from unauthorized access, while patients or medical practitioners holding the private keys will be able to decrypt the information stored on the HGB. This provides peace of mind to patients as their private information will be less likely revealed to unauthorized parties during clinical trials.
This paper discusses two different methods to illustrate the mechanisms to build a HGB platform for our intended use case: one is to completely code it from scratch and the other is to leverage on existing frameworks like Hyperledger Sawtooth for faster development. But it is necessary to have reliable security and consensus checking algorithms in the self-built blockchain for the first method.
As part of the limitations, this paper only provides a foundational PoC discovery on the potential of blockchain technology for healthcare games. But building an HGB to integrate complex healthcare video games is a complicated task. Healthcare games for augmented reality or virtual reality are usually developed on Unity, and the game data may be much more complex. Future research will be conducted on how to store such complex data on the HGB efficiently.
Handling sensitive medical data would require the utmost responsibility and security to ensure that the data does not fall into the wrong hands. Future research will be also performed to ensure the high security and reliability levels to properly integrate complicated healthcare video games into the HGB.