Avatars, apps, and agents of interconnected patient Avatars, physician apps, and intelligent agents represent patients, physicians, and third-party digital health care service providers, respectively. HAP has no central health data storage and performs decentralized data management (Figure 1). Patient data from many electronic health record systems are extracted, transformed via metadata validations, loaded onto a gateway XNetHub, and then synchronized with physician apps. Relevant personal health data are pushed from physician apps to patient Avatars, permitting an institutional data policy to be implemented. Smartphone-enabled patient Avatars are at the center of patient-centered data integration by collecting and integrating fragmented health data from multiple health care institutions. Patients can also generate patient-reported outcome measures that can be stored and sent to appropriate physician apps. Intelligent agents can request that physician apps or patient Avatars transmit health data via HAP RESTful APIs to provide digital health care services that are certified by and registered to the platform. Agents’ recommendations and analysis results can also be sent to Avatars and XNets. The HAP server authenticates and authorizes instances of data access and transmission by Avatars, apps, and agents (or interconnected patient Avatars, physician apps, and intelligent agents) via smart contracts.

Fully decentralized health data management enabling strong data privacy is the hallmark of the HAP and interconnected patient avatar, physician app, and intelligent agent system. Each data element resides in its proper location (ie, a patient’s data in the corresponding patient Avatar, a physician’s data in the physician app, and a service provider’s data in a third-party agent). Data redundancy is inevitable when a patient sends a copy of their patient-reported outcome measure to a physician and when a physician sends a copy of electronic health record data such as laboratory results and medications, to a patient. Intelligent agents can also receive health data and send (expert system) recommendations for clinical decision support to physicians as well as directly to patients. Previously, provenances of redundant decentralized health data were managed by a legacy HAP system. Introducing a hash chain for each data transaction among interconnected patient Avatar, physician app, and intelligent agent entities ensures better data provenance.

HAP provides a mobile platform for highly interconnected personal health records connecting many health care institutions, patients, and decentralized artificial intelligence agents. Semantic interoperability during data exchanges is achieved by fully curated and registered clinical common data elements supporting the ISO/IEC 11179 Metadata Registry standard. Electronic health record data are automatically transformed into common data elements at the time of extraction, transformation, and loading into the XNetHub metadata registry server. The metadata registry documents the standardization and registration of metadata to make the data understandable and shareable. HL7 FHIR, HL7 Continuity of Care Document, and ASTM Continuity of Care Record standards are supported (Multimedia Appendix 1) and semantically enriched at each common data element level by the metadata registry server for each of the specific apps. HAP has been used by 2 real-world practices in Korea—DialysisNet for chronic kidney disease and RehabilitationNet for neuromusculoskeletal disability management.

Though HAP has already been used for decentralized health data management in clinical practices, it is challenging for the legacy HAP system to verify whether or not the data on a terminal device such as a patient’s smartphone have been compromised. We implemented an Ethereum-based hash chain as a tamper-proof and traceable modular storage approach to guarantee data integrity among terminal devices by storing a hash for each data transmission and applying them to verify data authenticity between originals and the copies of transmitted data. Thus, all data that have ever been transmitted through HAP can be correctly verified by HAP hash audits without risk to privacy (such as those that arise from capturing sensitive health data in a central storage). A patient’s own patient-reported outcome measures from wearable devices or self-reporting forms can be verified for data provenance when patients send these records to themselves for digital signing or to another entity through hash auditing.

Health data are stored and managed off-chain in a decentralized fashion. The platform serves as a relay server that only stores the hash values on-chain of all data transactions for verification, data provenance, and auditing for tamper-proof data privacy. Two modules, called Blockchain Monitor and Node Manager, were newly added to the legacy HAP for creating block data in Ethereum (Multimedia Appendix 2). Introducing a blockchain technology to a legacy health care information system requires careful consideration, even with a popular and technically mature solution [35]. While Bitcoin is considered to be the most secure and representative platform, Ethereum is one of the most popular and robust platforms (1) allowing smart contract to be executed on-chain, (2) providing both permissioned and permission-less blockchain network, and (3) supporting a protocol-based crypto-economy environment, which is essential in incentivizing highly regulated but heterogeneous interactions [36,37]. The Ethereum network’s proof-of-authority consensus algorithm was used [38]. Unlike a permission-less blockchain, the proof-of-authority algorithm can manage participants in the blockchain network. This algorithm also allows participants or initial nodes in the blockchain network to act as block generators for nodes that are new in the network. Because health-related information can be categorized as sensitive personal information, unauthorized access by other users should be prevented. If the permission-less blockchain approach is applied to a mobile health system, patient information is bound to be passed on to unreliable anonymous nodes. The application of permissioned blockchain is more appropriate to curb the potential for the occurrence one such breach. In this study, this permissioned blockchain was designed to allow only preconsulted care providers or health organizations to participate as nodes. Additionally, proof-of-authority Ethereum can create blocks more rapidly than permission-less blockchain networks method such as proof of work [12,39].

To capture transaction hash logs in the blockchain, smart contracts that can be executed on an Ethereum virtual machine are required. Table 1 summarizes the parameters that can be extracted from data communications for each step. We designed smart contracts based on these investigated parameters. By designing these contracts, we intended to manage transaction metadata on the blockchain for data provenance while also managing patients’ health data off-chain safely in their proper locations(ie, patient smartphones, physicians’ smart pads, and agents' servers) for strong privacy protection. In addition, it is necessary to design a process that executes additionally implemented contracts in the legacy data communication process and delivers the required parameters; therefore, we compared different blockchain architectures (Multimedia Appendix 3).

We implemented Go-Ethereum blockchain with the smart contracts (Table 1) on CentOS (version 7.2; Linux) along with initial 3 proof-of-authority blockchain nodes of DialysisNet on HAP. We set the block generation cycle of the nodes to 5 seconds. For the purpose of performance evaluation, we tested the use case scenarios using sample data sets including data elements for simulated hemodialysis patients’ vital signs, laboratory results, and medications.

Each Ethereum node stores and manages transaction metadata during the course of all data exchanges on the HAP interconnected patient Avatars, physician apps, and intelligent agents. SC-1, as the health data transaction manager, stores senderAddr (the account address of the sender of the data segment), receiverAddr (the account address of the receiver), HashedDS (the hash value of the data segment through the Secure Hash Algorithm-256 function), and HashSeq (a unique key for the transaction), which can also be used as a foreign key between contracts. SC-2, as the health data transaction status manager, manages the status of data transactions to be saved by SC-1. Finally, SC-3, as the HAP API transaction manager, was developed to manage information related to an agent's personal health record data requests. SC-3 manages the hash value of the requested API (Table 2).

Patient data are located in their smartphones (Avatar), physician’s data for their patients are located in their smart Pads (XNet), agent’s data for its customer are located in its server, and the health care institution’s data are located in its electronic health record or other production servers. Thus, data are primarily stored and managed off-chain. All data transmission logs to proper receivers are on-chain through the HAP hash-and-relay server with a proper rationale and at a proper time (Figure 1). Node Manager manages information about each node that makes up the blockchain network. Information on personal health record data transactions are transmitted or requested to be traced to Blockchain Monitor (Multimedia Appendix 2). Blockchain verifies personal health record data managed off-chain in HAP or stores transaction metadata for verification. All transaction can be properly incentivized.

A data segment has one or more data elements with values (sample data sets can be found in Multimedia Appendix 3:Figures S1-S3). When a physician app initiates a data transmission of vital signs (or laboratory results or medications) to a patient Avatar, the HAP relay server saves the time-stamped logs of the sender, recipient, and file name, sorts the data elements in the data segment, and extracts HashedDS from the data segment via Secure Hash Algorithm-256 (Figure 2a). HAP then transfers the extracted HashedDS and blockchain account addresses of the sender and receiver to smart contract SC-1 health data transaction manager for execution (Figure 2b). The blockchain node creates transaction metadata as block data with SC-1 health data transaction manager executed. By executing SC-2 health data transaction status manager, block data are created and tagged with the “waiting” status for the relevant data transaction. If block creation is successful, a HashSeq value is created by the blockchain and SC-1 returns this HashSeq. HashSeq is a sequence number created by SC-1 health data transaction manager to serve as a unique identifier corresponding to the HashedDS value. Through SC-1 health data transaction manager, HashedDS is mapped to this HashSeq and stored in the blockchain. Because HashSeq can function as a foreign key in the 3 smart contracts, the metadata for the exchanged data segment can be managed by normalizing relative to each contract.

When HashSeq is returned from the blockchain, the patient Avatar is enabled by the server with a push message to receive the data segment and HashSeq. The patient Avatar stores all records included in the downloaded data segment file in the personal health record database. These records are tagged with HashSeq and updated in the personal health record (or the patient Avatar database). When the personal health record update process is completed, the patient Avatar transmits its status information to HAP, indicating that data downloading is complete. The HAP server then updates the status information of the data segment to “complete” through SC-2 health data transaction status manager to record the completion of the patient's health data transmission and the personal health record update on the blockchain. Until the data transmission process is completed, metadata pertaining to the 3 data segments transmitted are maintained in blockchain storage (Figure 2).

The HAP server relays the request (Figure 3) through the proper API to the patient Avatar (Multimedia Appendix 4: Figure S4). After authorization and authentication, the Avatar responds to a proper and trustworthy request by returning 2 types of data segments: data segments for the response (DSR) and data segments for validation (DSV), as the query response for the API request and the query result for data segment validation, respectively. Data segment validation is a process that checks whether there is a modulated record in the data segment before returning the query result to the requester. An example transaction scenario (Figure 3) is an intelligent agent requesting a patient Avatar for personal health record data including “dry weight,” “weight after hemodialysis,” and “weight before hemodialysis” through open API complying with the HAP RESTful API syntax. The “/api/vitalSigns/” part of the API syntax refers to the database table VitalSigns, and the part next to q is the query string. The query string requests the dry weight measurement of “2019-09-25,” weight after hemodialysis of “2019-09-27,” and weight before hemodialysis of “2019-09-30.” After performing authentication and authorization for the requesting agent, HAP transmits the data request to the corresponding patient Avatar. In response to the request, the patient's Avatar queries 2 types of data segments: DSV and DSR. First, DSR is extracted from the patient Avatar’s personal health record database. Avatars' personal health record tables are devised on a data model that conforms to ASTM Continuity of Care Record and HL7 Continuity of Care Document standards. Health records previously delivered in the same data segment are tagged with the same HashSeq but are separately stored in 3 different tables (Figure 2b and Figure 3b) according to the data model. The corresponding data segments are pulled and processed to compile the query result for the requested API syntax and then returned to the requester.

Data segment validation, a process of verifying whether or not the transmitted DSR has been tampered with, is performed before the queried DSR is returned to the agent. A query using HashSeq included in the DSR is executed in the Avatar, resulting in a list of DSVs. Each DSV is bound to the HashSeq and regenerates HashedDS by sorting and hashing the records (or data elements) included in each DSV. If all regenerated HashedDSs are successfully retrieved from the blockchain, the DSV corresponding to the HashedDS has not been compromised. This also means that the records included in DSR have not been modified. Upon successful validation, information about the agent's data request by API is inserted into the block by the SC-3 HAP API transaction manager. This creates a block to update the status of the personal health record transaction to “complete” through the SC-2 health data transaction status manager. When transaction data generated by the agent API are created as block data, the server returns the DSR to the requesting agent. It was demonstrated that a smart contract in collaboration with data elements provided by metadata registry enable detailed data element–level query and access control beyond the resource-level query enabled by HL7 FHIR and other messaging standards. An authorized agent can provide highly personalized health care services without requesting an unnecessary amount of data beyond its declared capability and beyond what is authorization by HAP.

For the purpose of strong data privacy protection, HAP does not store any health data that are transmitted through the server; however, data backups are necessary for many purposes under strict patient control (Figure 4, Multimedia Appendix 4: Figure S5). When a patient initiates the backup process, the patient Avatar queries all personal health record data except for the patient identifier and transmits it to the HAP API with a backup request. The API allows one to output the data set grouped by HashSeq. Data segments transmitted through HAP will be hashed, and each HashedDS is created for validation. If validated passes, it means that the data segments to be backed up have not been altered and they are sent to the backup storage. Before the data segments are saved into backup storage, the verified segments are integrated into a data segment file. Using the patient's public key, the file is encrypted by the RSA (Rivest–Shamir–Adleman [40]) method and stored in the backup storage. When the encrypted file is stored in storage, the server creates HashedDS after hashing the integrated data segment of the file. To record the completion of the transaction in storage, the HashedDS “2sdf4asfas5a6dd48dd...” is connected to HashSeq 75 and stored. The blockchain stores the status of the transaction as “backup.”

The legacy HAP successfully performed decentralized health data management. From a data management perspective, decentralized management of personal health record with a patient's smartphone app is less efficient than a centralized approach; however, in terms of privacy protection and patient empowerment, decentralization is better for creating a highly interconnected mobile health ecosystem. We built a decentralized system and performed real-world clinical-practice validation with DialysisNet and RehabilitationNet. The platform successfully prevented data reuse and personal information leakages based on the trust of the system. The introduction of the blockchain and smart contracts significantly improved the efficiency and effectiveness of our decentralized health data management method. The adoption of blockchain to the legacy HAP system inevitably incurs overhead (Multimedia Appendix 5); however, we observed that the overhead, 32.58 ms on average, added to the legacy system was minimized by introducing asynchronous blockchain connection. The platform demonstrated that blockchain is a suitable software tool that safely and efficiently performs the required data verification and decentralized data backup processes.

HAP provides semantic interoperability for all data exchanges in the system. ASTM Continuity of Care Record and HL7 Continuity of Care Document standards were applied as a syntactic backbone required for HAP data management; however, syntactic standards alone are insufficient for a unified specification (eg, data type, format) for all data exchanges on the platform. Thus, we installed XNetHub in each health care institution (Figure 1) and metadata registry to ensure semantic interoperability among different electronic health records. HAP XNetHub supports HL7 FHIR, allowing resource-level health data queries. HAP treats a message (or a health record) as a collection of data segments composed of data elements, which are defined and managed by a metadata server in compliance with ISO/IEC 11179 metadata registry standards and provide thousands of expert curated common data elements required for hemodialysis patient management. One unique advantage of our work is that the blockchain-enabled HAP allows data segment–/data element–level querying and health data processing that are fully authenticated and audit trailed by the enabling technologies such as the immutable hash and sub–hash management schemes (Figures 2-4) with smart contracts (Table 2). In contrast, HL7 FHIR’s resource level data management does not allow granularity that is fine enough for health data querying or processing.

The introduction of metadata registry on top of these syntactic standards with predefined, preregistered, and postexpandable common data elements, highly enriched in semantics by means of standard vocabulary and ontology mappings, further improves semantic queries to each data element value level. Furthermore, we demonstrated that data segment– and data element–level data verifications were enabled by this architecture. A metadata registry improves the semantic interoperability of health data exchanges [8,41,42]. The semantic layer allows patients to integrate their health records from multiple health care institutions. Physicians can consolidate the health records of patients from different institutions. Moreover, third parties can have an integrated view of patients' health records through HAP RESTful APIs.

Blockchain and smart contract technologies were used in this platform to enhance the security of patient-centered personal health record transactions and the efficiency of decentralized data management. Additionally, for exchanges of patient data that may occur on the platform, HAP can provide incentives for data sharing to parties with whom the data are being exchanged. Many health care systems adopting fee-for-service reimbursement mechanism mainly reward highly materialized clinical services, such as medications, laboratory testing, or interventions, but lack sufficient reward systems for education, exercise, prevention, or long-term management that are more relevant for chronic conditions, which are ever increasing. Given all of these advantages, the HAP interconnected patient Avatars, physician apps, and intelligent agents system can become an ecosystem that promotes the reliable sharing of health data performed with patient empowerment.

Due to the features of the proof-of-authority consensus algorithm, a delay during block generation equal to the setting in the genesis block occurs; however, in this prototype system, the block data are generated through an asynchronous on-chain process apart from off-chain transactions for health data, meaning that there are no delays in off-chain data transactions. Another challenge arises when verifying the patient Avatar's personal health record data (through data backup or data query processes)—when a large message is exchanged, the speed of data verification and the return of the verification result may be slower. Accordingly, it may be necessary in the future to calculate the data alignment method included in the DSV and the appropriate time required during the process of hashing the data segment. For this process, a trade-off study on the time required for data processing and the size of the transmitted data segment may be required.

We designed and built an ecosystem that provides efficient and effective decentralized health data management and exchange operations by applying a prototype blockchain and smart contract to a patient device–based personal health record system. It was demonstrated that health data access control and authenticity verification of personal health record data are enabled not only at the overall personal health record or resource level but also at granular data element and data value levels.