Usually, behavioral data is collected by tracking users of applications, tools, and websites. Even though the user has to opt-in and consent to share their data, this is usually the only option to access the selected service or system. This approach cannot be applied in medical research due to data sensitivity and not at least data privacy/protection laws (e.g., GDPR). Patients have no benefit from sharing their data, and even with the motivation of sharing for the greater good, there is no technical solution to do so [1].
New medical informatics trends such as precision medicine or clinical decision support systems heavily depend on health data's amount, quality, access, and availability. At the same time, the volume of health data generated and collected through various stakeholders and systems is increasing rapidly. Hospital information systems collect digitized data on patients' diseases and treatments, while wearables generate longitudinal data such as the patient's heart rate, sleeping rhythm, or eating habits [2].
The identified research gap shows a lack of secure and fast connection options between data creators, data owners (patients), and potential beneficiaries (researchers), that are peer-to-peer based. Despite the growing importance of real-world data (RWD), and unsolved challenges and risks [3] there is still a shortage of solutions that allow patients to voluntarily share their data without being dependent on a single, potentially commercial platform provider. Therefore, it is crucial to explore possible solutions where patients can share their data directly with specific research organizations without relying on storing their raw data on a platform outside of their control. This research focuses mainly on investigating how patients can consent to share data with researchers using for example the dHealth network, while respecting the needs of the involved stakeholders. The dHealth network was selected as ecosystem for the prototype due to its open-source nature, tailored design for healthcarerelated transactions, and its extensive toolbox, which provided a flexible foundation for developing the required features and functionalities.
Stakeholders have different requirements for health data based on their needs and position along the care journey. Besides the general data security attributes such as integrity, confidentiality, and availability there are specific requirements on patient and research side of the sharing process [4]. Patient-oriented sharing solutions must prioritize in addition to traditional data security attributes data privacy and transparency, ensuring rigorous protection of personal health information and adherence to data protection laws [4]. These systems should be in addition highly usable, catering to a diverse user base, and emphasizing ease of use and perceived usefulness to promote widespread adoption [5].
Researchers on the receiving side of data sharing rely on high-quality data for their studies. With the integration of patient data, ensuring data integrity and verification becomes paramount. One approach is distinguishing patient-generated data, acknowledging its potential variability, and considering third-party validation, such as involving general practitioners in the data validation process [6]. Data quality also hinges on maintaining data integrity to prevent unauthorized modifications, which is crucial when accommodating patient-initiated data changes [4]. Moreover, researchers emphasize system availability to access data promptly, ensuring data preservation and appropriate removal. Efficient performance, characterized by fast data access, transmission, and retrieval, further enhances the usability of data sharing for research purposes [4].
The research followed the Design Science Research (DSR) principles outlined by Peffers et al. [7]. A prototype solution was created to address specific challenges in healthcare research, such as data integrity or other defined security attributes. The prototype is designed to simulate the functionality of allowing patients to choose the designated research purpose for their data. This aspect showcases the prototype's potential to support different research objectives and enhance patient engagement in the research process. The DSR approach emphasizes iterative design and evaluation cycles. By following DSR principles, this research aims to advance healthcare research by providing an applicable solution that addresses the requirements and complexities of data management, achieving specific security attributes for data, and research purposes in the healthcare domain. In summary, a technical proof-of-concept prototype is programmed using blood sample data. The prototype is validated based on a blend of authors' objectives and derived requirements from existing frameworks.
Two key concerns arise from the perspective of data privacy. Firstly, patients should be able to determine which individuals or entities can access their data. Additionally, they need to have confidence in the system's ability to uphold these preferences. Leveraging blockchain technology as a facilitator for these transactions ensures a very high level of transparency. Given that all transactions are visible to the public, patients can always ascertain who their data has been shared with and verify that their privacy settings have been respected. The prototype does not store information in pdf format but adheres to the HL7 standard, an international standard used to store machine-readable health data. Consequently, the data processed in Figure 1 and Figure 2 becomes machine-readable and easily transferable between systems or users. This characteristic enables the solution's scalability, accommodating additional stakeholders, such as insurance companies, entering the process. These stakeholders would require an interface compatible with one widely adopted standard.
From a patient or data sender perspective, the main requirement is to ensure data privacy. Since the patient initiates the data sharing, complying with the needs and requirements of patients is most important to ensure sufficient participation. On the other end of the sharing process are researchers, who need the data shared by patients. However, the data will be useless if the shared data sets do not underline standardization and regulation.
Therefore, data quality is the second main requirement to ensure the usability of the shared data. If the first two requirements are fulfilled, but the solution's usability is not guaranteed due to a lack of performance, neither side will use it. Hence, the third requirement focuses on performance. Based on the literature, these requirements can be translated into the objectives in Table 1.
Prototype objectives
This study builds a proof-of-concept emphasizing security, efficiency, and decentralization. Blockchain technology forms the foundation of this architecture, renowned for its secure and decentralized data storage capabilities. Utilizing cryptography to link data blocks, blockchain technology is exceptionally suitable for handling sensitive health data, providing a tamper-proof environment and ensuring data integrity [23]- [26]. The blockchain utilized is the Decentralized Health (dHealth) Network. This blockchain network, designed explicitly for healthcare data, employs a Proof-of-Stake Plus (PoS+) consensus mechanism. It facilitates secure, efficient health data transactions and incentivizes participation through its digital currency, DHP, making it a valuable tool for healthcare data management [27].
The InterPlanetary File System (IPFS) plays a crucial role in the stack. IPFS revolutionizes data storage and retrieval by shifting from traditional location-based addressing to content-based addressing. This method enhances data integrity and efficiency, employing unique hashes for data, thus avoiding redundancy and ensuring easy access to information [28].
Health Level Seven (HL7) is incorporated for structured data exchange in healthcare. HL7 standardizes the messaging format, streamlining the communication of patient details, test results, and other crucial health data, facilitating effective and standardized data exchange within the healthcare domain [29], [30].
The development environment includes TypeScript for the backend and React.js for the frontend. The prototype leverages the existing dHealth SDK2 for account management, transaction creation, and signing, and Node.js serves as the run-time environment. To ensure data privacy, the prototype encrypts HL7 files using an AES-256 encryption algorithm and uploads them to the decentralized IPFS network. This approach ensures data redundancy, availability, and resilience against single points of failure.
Literature (1) The patient can see where their data has been sent.
[8]- [10] (2) The patient can control whom they share their data with.
[9], [11], [12] (3) The data needs to be in a machine-readable format.
[13], [14] (3.1) Meta-data is available:
• When and where data was created 3 shows the sender's perspective. The prototype prompts the end-user to select a research organization as the data recipient (1). The prototype allows a selection between academic and commercial research. The sender authenticates themselves with the private key (2). The file gets encrypted with the chosen encryption key (3). The encrypted file is then uploaded to IPFS (4). IPFS returns a Content Identifier (CID), which acts as an address to the file. The CID is added to the transaction as an encrypted message along with the encryption key.
sender's private key is used for authentication and signing the transaction before it is broadcasted to the dHealth network using the SDK. As soon as the transaction is confirmed, it is publicly visible in the dHealth explorer 3 and can be found through the transaction hash, the sender's address, or the recipient's address.
On the recipient's side (Figure 4), the prototype enables data retrieval by entering the transaction hash and providing the recipient's private key (1). Therefore, the recipient needs to notice an incoming transaction by monitoring their account in the explorer or enabling notifications in the dHealth wallet, where the transaction hash can be identified. The sender's public and recipient's private keys are used to decrypt the attached message, containing the IPFS Content Identifier (CID) and file encryption key. The retrieval and decryption of the encrypted message are done using the SDK (3). Due to the message encryption being part of the dHealth functionality, only the recipient's account can decrypt it, allowing access to the file location and its decryption key. The decrypted HL7 file is stored locally on the recipient's machine.
Overall, the architecture leverages the dHealth network, IPFS, the React.js frontend, and the provided SDK functions to ensure secure data transmission, privacy, and interoperability in the healthcare domain.
The objectives in Table 1 are derived from stakeholder requirements, encompassing data privacy and patient transparency, data quality for research, and performance measures. Data privacy and quality objectives are assessed separately from performance objectives because privacy and quality are assessed qualitatively while performance is assessed quantitatively.
The evaluation of the first four objectives of Table 1 has been conducted systematically in a binary manner, employing a checkbox-like assessment approach. The objectives are considered achieved when they apply to the prototype, thus highlighting the successful fulfillment of the corresponding criteria. This methodical evaluation ensures a comprehensive appraisal of the prototype's adherence to the established objectives.
The transparency provided by the applied blockchain technology allows patients to trace and verify the journey of their data. They can view the transaction history and track which research organizations or recipients have accessed their data. 2. The patient can control whom they share their data with: The prototype includes a user interface that enables patients to select the desired research organization as the recipient of their data. This control empowers patients to decide whom to share their health data with, ensuring privacy and consent. 3. The data is in a machine-readable format: HL7 format ensures that the health data is structured and machine-readable, meeting the requirement of data accessibility and interoperability. 3.1. Meta-data is available: The HL7 format includes meta-data such as information on when and where the data was created and the clinical setting, providing additional context and details about the health data. 4. Performance: The validation of the performance was very complex within the scope of the study and is therefore described in the following section.
The prototype underwent rigorous examination regarding its performance within a controlled local environment, executed through command-line interfaces. A dedicated script systematically evaluated the prototype's performance across various file sizes. This method allowed for meticulous measurement of processing times, enabling a comprehensive analysis of system behavior and responsiveness under varying workloads. The performance evaluation involved measuring the loading time and execution time of the prototype. Loading time was measured as the duration from the initial launch of the application to the point where it became responsive to user input. This metric determined how quickly users could access and interact with the system. Execution time refers to the interval from the last user input to the completion of all processing steps within the application. This metric helped assess the efficiency of the prototype in handling user requests. A range of test scenarios were executed to ensure a comprehensive evaluation. One hundred test runs were conducted, each with different file sizes. These scenarios included:
• A regular blood test HL7 file with a size of 3KB.
• An HL7 file of larger dimensions, measuring 1024KB (1MB).
• An even larger HL7 file of 30720KB (30MB). This allowed a thorough assessment of the prototype's performance across a spectrum of data sizes, providing insights into its scalability and efficiency under varying conditions. The main components were programmed using TypeScript and Node.js in Visual Studio Code. The file format was HL7, using AES-256 encryption algorithm. The dHealth network served as blockchain for the data exchange, while the IPFS network provided distributed data storage. For the regular-sized HL7 file, the average loading time for the patient application over 100 runs was 2.21 seconds, while the research application had an average loading time of only one millisecond. The execution time for both applications averaged around 0.25-0.27 seconds. As shown in Table 2, the larger file sizes mainly impacted the execution time for all stakeholders. The maximum transaction fee of 0.05 DHP was identified as a good balance between approval time and cost. The dHealth network has a maximum transaction throughput of 200 transactions per second, with each transaction having a fixed size of 82 bytes. The application prototype itself did not impose any limitations regarding potential bottlenecks as it ran locally and independently. The main potential bottleneck could be the IPFS network, but no specific upload limits regarding speed or size were found. The limitations would depend on the hardware specifications of the IPFS node. The prototype currently utilizes an API (Application Programming Interface) limited to 60 transactions per second.
The prototype successfully addresses the objectives of patient visibility in data usage and control over transaction recipients, having machine-readable data and available meta-data. In addition, the evaluation demonstrates that the prototype, in terms of performance, effectively achieves the requirement of fast data access with a transaction throughput above 60 TPS and acceptable performance with an average loading time below 4 seconds.
One of the prototype's main limitations is the data deletion challenge. As blockchain and IPFS are immutable technologies, once data is stored on these platforms, it becomes difficult to delete or modify it. This limitation arises from the inherent design principles of these technologies, which prioritize data immutability and integrity. Deleting sensitive patient data in healthcare is crucial to comply with data privacy regulations and individual preferences. However, due to the nature of blockchain and IPFS, achieving complete data deletion is challenging. It requires additional mechanisms and considerations beyond the scope of this prototype. Addressing the limitation of data deletion would necessitate exploring alternative approaches, such as implementing privacyenhancing techniques like zero-knowledge proofs or utilizing off-chain storage solutions with more flexible data management capabilities. These approaches could provide more comprehensive control over data retention and deletion while maintaining the desired level of security and privacy.
This study explores the feasibility of a blockchain-based platform for sharing health data between patients and researchers. The prototype application demonstrates that combining blockchain technology and distributed file storage, specifically the IPFS network, enables secure and efficient data transfer. Patients can select recipients, encrypt files, and upload them to IPFS, sharing the encrypted IPFS Content Identifier (CID) and encryption key with the recipient. Researchers can retrieve and decrypt the files, enhancing data value for research projects. Patient autonomy and compliance with data protection/privacy regulations are emphasized. In order to ensure continuous quality, (external) audits are recommended. Overall, the study extends existing research by including research organizations in the data exchange process, affirming the suitability of distributed ledger and storage systems for healthcare applications.
The technical feasibility of a blockchain-based platform for health data sharing is confirmed through the prototype and its evaluation. Future should explore blockchain options, encryption methods, and economic considerations while ensuring compliance with evolving privacy regulations.