Introduction

Patient imaging records are increasingly being stored piecemeal with different parties as modern information systems in healthcare trend towards control by multiple entities. This reliance on multiple parties to host and share protected data, especially in emerging fields, including computer-assisted spinal surgery, increases the opportunity for security [1–3] and transparency [4–7] issues. Further, due to the concern of time-sensitive data not being available when necessary, healthcare data is often stored in permission databases with multiple levels. The concerns warrant the exploration of novel solutions, such as the utilization of blockchain technology.

A blockchain is a distributed, decentralized ledger similar to a digital append-only list constituting ordered sequences of grouped entries, named “blocks”. These blocks are ordered in a sequence ordered through the storage of a cryptographic hash of the proceeding block in the following one (Figure 1). Notably, the deterministic and irreversible nature of these hash functions permits the blocks of data to be “chained” together. Further, since the alteration of any record alters the hash of the current block in addition to any subsequent blocks thereafter, this paradigm ensures data stored within the system is immutable. The blockchain is shared amongst “nodes”, or computers without previous relationships linked via peer-to-peer networks. Significantly, no individual node can control the data. The nature of this distributed architecture permits decentralization and precludes a central point of failure. Moreover, the blockchain is fully transparent with each transaction being transmitted to all nodes and users, who can verify the transactions.

Display full size

Figure 1. 

Detailed overview of the Ethereum blockchain

Note. Adapted from “Using ethereum smart contracts to store and share COVID-19 patient data,” by Batchu S, Patel K, Henry OS, Mohamed A, Agarwal AA, Hundal H, et al. Cureus. 2022;14:e21378 (https://www.cureus.com/articles/72568-using-ethereum-smart-contracts-to-store-and-share-covid-19-patient-data#!/). CC BY.

Theoretically, blockchain architecture serves as an immutable ledger for any form of data, even medical records. Currently, blockchain is most thought of in the context of Bitcoin, which uses blockchain to record transactions of digital currency [8]. Following this, blockchain technology has become increasingly popular and has since been utilized with the new digital currency, Ethereum. Ethereum is distinct from other blockchains in that it combines the benefits of blockchain technology with software applications as open-source, international. This quality permits developers to generate programs that execute only when specific conditions are met, a concept known as smart contracts [9]. The Ethereum platform can be applied to additional use cases requiring strong security and flexibility, such as preserving medical records, as it permits code to be performed with specific logic and offers data storage not limited to Bitcoin transactions. Although existing illustrations of the potential of the Ethereum blockchain integrating medical data are limited, the early findings are encouraging. One demonstration of this is Gürsoy et al. [10] use of the Ethereum blockchain to handle pharmacogenomics data composed of gene-variant-drug combinations. However, no research has yet investigated the use of the Ethereum blockchain to store and query imaging data.

Currently, computer-assisted spine surgery data is transported among healthcare professionals via a physical device [e.g., compact disc (CD), digital video disk (DVD), universal serial bus (USB)]. Image Share Network (ISN) was developed as an alternative to cumbersome physical transport. The ISN stores medical photos in a third-party clearinghouse searchable with a hash of a secret token. Within an established period, the token disclosed by the patient can be used to reproduce the unique hash and download the data [11]. ISN is just one of a few existing cloud-based commercial systems in current use [12–14]. While these platforms circumvent physical media transfer, their designs create concerns over the participation of third parties and the centralization of the framework.

In the field of spine surgery, the emerging use of intraoperative three-dimensional (3D) imagery with a navigation system has been introduced to lower the rate of surgical screw malposition. Further, 3D augmented reality surgical navigation (ARSN) has emerged as a way to utilize optical video cameras displaying 3D intraoperative images and a navigation path for screws. However, this novel technology requires significant collaboration between healthcare professionals as well as their secure and immaculate handling of data which can be facilitated by the Ethereum blockchain platform.

Therefore, this study illustrates the viability of a smart contract to incorporate ARSN data into the Ethereum blockchain platform, thereby enhancing patient privacy, data security, and record immutability. The price of storage is a disadvantage of keeping image files on Ethereum [9, 15]. To avoid this, the peer-to- peer distributed interplanetary file system (IPFS) was employed to save the imaging outside of the chain. Concurrently, the associated has was stored on Ethereum. Consequently, IPFS was used to maintain the data image while Ethereum housed the unchangeable history of hash references 3D cone-beam computed tomography (CT) scans from a robot-assisted, guided pedicle screw positioning system were utilized to provide proof of concept. Nonetheless, the given framework is adaptable to any form of spine surgery data.

Materials and methods

Insertion

Iteration would be necessary to obtain observations from data stored in an array. Instead, mappings— which are comparable to hash maps—were used to store the data, enabling faster key-value lookups. Four storage mappings were applied using Solidity’s mapping type. Each observation was put into its own struct, a special type that allows the grouping of various variables of various types. Patient information, including the IPFS hash, is included in one mapping. Associated diagnosis (e.g., spondylolisthesis), patient identification, Gertzbein grade, and the other three mappings serve as keys to a variety of counter identity documents (IDs). The counter ID is a global variable that gives each entered observation a distinct index. Consequently, retrieving the patient observation from the database using the specified counter IDs is possible by querying with any of the three keys (Figure 2). For effective querying, this insertion mechanism enables non-iterative lookup.

Display full size

Figure 2. 

Smart contract architecture. Insertion and retrieval mapping exemplified with mock ARSN input to IPFS

Note. Adapted from “Using ethereum smart contracts to store and share COVID-19 patient data,” by Batchu S, Patel K, Henry OS, Mohamed A, Agarwal AA, Hundal H, et al. Cureus. 2022;14:e21378 (https://www.cureus.com/articles/72568-using-ethereum-smart-contracts-to-store-and-share-covid-19-patient-data#!/). CC BY.

A single patient record was added using the insertion function for a specific diagnosis, patient ID, and Gertzbein grade (Figure 3). Patient identification, primary diagnosis, screw diameter, Gertzbein grade (reflecting the deviation of the screw from the ideal interpedicular trajectory), and 3D cone-beam CT image identifier hash were all included in the patient record. The insertion function then, if necessary, transforms the patient data to the desired storage type after it has been supplied. The disease-patient identifier-Gertzbein grade combination is added to an array if it does not already exist. The pedicle screw diameter, the patient’s unique identity, and the primary diagnosis are then entered into respective mappings. The value array receives the counter ID in addition. The counter ID variable is then changed after inserting the observation struct and key-value pair (made of the counter ID and patient data struct) into the database.

Display full size

Figure 3. 

Pseudocode for algorithmic insertion of an example observation

Note. Adapted from “Using ethereum smart contracts to store and share COVID-19 patient data,” by Batchu S, Patel K, Henry OS, Mohamed A, Agarwal AA, Hundal H, et al. Cureus. 2022;14:e21378 (https://www.cureus.com/articles/72568-using-ethereum-smart-contracts-to-store-and-share-covid-19-patient-data#!/). CC BY.

In comparison to strings, which are dynamically sized types, storage of strings as bytes32 types—fixed- size byte arrays which consume less gas and are optimized for EVM is more economical. However, to save the IPFS hash in its alphanumeric Base58 encoding, 46 bytes are needed. Even though the hash is just 34 bytes when represented in hexadecimal form, it still exceeds the required 32 bytes. However, as previously mentioned, the IPFS identifier is also a multihash. The first two bytes can be removed because they specify the hash algorithm and length, which are universally utilized by default for the relevant present IPFS processes. This enables the storage of the hexadecimal IPFS hash as a bytes32 type (Figure 2). Data is accessible from the contract through the JavaScript console or other scripts. This allows the concatenation of the two bytes and encoding back to Base58 straightforward.

Bytes32 variables were used to hold the disease, disease grade if applicable, patient identifier, Karnofsky score, and identifier hash. Another type in Solidity is addresses, which are used to store user or contract addresses on the Ethereum blockchain.

Query

In addition to wildcards, the query tool allows you to search using up to three fields (primary diagnosis, patient ID, and Gertzbein grade). The function initially verifies which fields were queried. The corresponding values are then retrieved from the counter ID mapping using those fields as keys. All counter IDs are retrieved if wildcards are used. The minimal length counter ID array is looped through for every record to see if the counter ID matches the counter ID in the outer loop. The struct value from the database mapping is then retrieved using the matching ID (Figure 4).

Display full size

Figure 4. 

Pseudocode for algorithmic querying of an example observation

Note. Adapted from “Using ethereum smart contracts to store and share COVID-19 patient data,” by Batchu S, Patel K, Henry OS, Mohamed A, Agarwal AA, Hundal H, et al. Cureus. 2022;14:e21378 (https://www.cureus.com/articles/72568-using-ethereum-smart-contracts-to-store-and-share-covid-19-patient-data#!/). CC BY.

Results

With the help of JavaScript console external scripts, the smart contract was tested. Manually checking 50 random queries against the fields utilized in the queries yielded accurate results in every instance. Time and memory were also evaluated for the insertion and querying of observations in order to further analyze contract performance (Figure 5). Only 990 Megabyte (MB) of memory per insertion was required to insert 350 patient records, while retrieval required 1,026 MB. It was discovered that it took 276 milliseconds to insert 50 records and 713 milliseconds to insert 350 records. Inserting 50 records required 934 MB of memory per insertion with patient data and imaging, while inserting 350 records required almost the same amount of memory per insertion (Figure 5A). In a database of 350 records, the retrieval function needs about 1,026 MB to query a record with all three fields left blank, but only 970 MB to obtain the same observation from a database of 50 records (Figure 5B).

Display full size

Figure 5. 

Smart contract performance, tested with 0, 50, 100, 150, 200, 250, 300, and 350-record inputs. (A) Insertion time and memory usage, (B) retrieval time and memory usage

Note. Adapted from “Using ethereum smart contracts to store and share COVID-19 patient data,” by Batchu S, Patel K, Henry OS, Mohamed A, Agarwal AA, Hundal H, et al. Cureus. 2022;14:e21378 (https://www.cureus.com/articles/72568-using-ethereum-smart-contracts-to-store-and-share-covid-19-patient-data#!/). CC BY.

Discussion

Secure data preservation is essential within the context of ARSN as damaged data can result in medical errors. We purposed blockchain-based solutions, such as smart contracts implemented on the Ethereum platform. Such decentralized ARSN data would avoid situations in which there is a single point of failure, and create an irreversible ledger, preventing purposeful or unintentional corruption. While previous studies have demonstrated the use of this technology in healthcare [20–22], this study exemplified a smart contract integrating ARSN data. In particular, the IPFS was employed to store imaging effectively off-chain while the Ethereum blockchain was used for contract deployment. This revealed an effective way to store ARSN data while also allowing for quick storage and retrieval of observations.

However, there are limitations to implementing smart contracts as the Ethereum project is still in its early stages. For instance, building a smart contract necessitates familiarity with the Solidity programming language, which has various quirks, including the number of local variables allowed in functions and the “gas” restriction. It also requires prior platform knowledge to deploy smart contracts and set up a private Ethereum blockchain. To reduce the level of skill needed to deploy the contracts, the procedure might be written in an external script. However, there could still be challenges when communicating with the Ethereum software, such as the web3.js JavaScript application programming interface (API). The promise of adopting smart contracts for medical ARSN still exists despite these restrictions, which highlight the need for a more reliable platform. Increased patient privacy, data security, and record immutability are made possible by the integration of medical ARSN into the Ethereum blockchain platform using smart contracts.