Self-sovereign management scheme of personal health record with personal data store and decentralized identifier

Abstract

Conventional personal health record (PHR) management systems are centralized, making them vulnerable to privacy breaches and single points of failure. Despite progress in standardizing healthcare data with the FHIR format, hospitals often lack efficient platforms for transferring PHRs, leading to redundant tests and delayed treatments. To address these challenges, we propose a decentralized PHR management system leveraging Personal Data Stores (PDS) and Decentralized Identifiers (DIDs) in line with the Web 3.0 model. Our system features secure interoperability and personal identification masking. Interoperability is achieved through DID digital certificates for verifying PDS addresses and a dynamic access key (AK) system to minimize credential exposure. Data de-identification, including anonymization and encryption, ensures privacy and prevents unauthorized access. We developed a prototype using the Solid open-source library and Hyperledger Aries protocol. Testing showed efficient performance, with DID validations and AK generation under one second, and data operations for 500 MB-sized PHRs completing in two seconds. De-identification processes were both effective and timely. The system demonstrated the ability to manage PHRs securely, empower users with control over their healthcare data, facilitate seamless and secure data transfer between patients and medical entities, and prevent exposure of sensitive information. This approach advances decentralized PHR management, supporting improved healthcare outcomes and patient experiences in the digital era.

Graphical abstract

1. Introduction

In conventional personal health record (PHR) management systems, individual health and medical records are centralized and managed primarily by large hospitals or central servers. These systems predominantly rely on centralized structures for the authentication and storage of data. While such centralized approaches facilitate ease of use and integration, they also present significant security and privacy vulnerabilities [1]. Centralized systems are susceptible to single point of failure and are attractive targets for hackers, resulting in potential widespread data breaches [2]. Concentrating personal information with central authorities also raises concerns regarding surveillance and control, with the possibility of governmental or institutional entities having unrestricted access to sensitive individual data [3]. Additionally, conventional PHR management systems face significant obstacles in swiftly transmitting PHR to the servers of other healthcare entities. To the best of our knowledge, there is no actively running PHR system to support the online exchange of PHRs between medical entities in the US and South Korea [4], [5], but a test project to collect all PHRs in a center for data exchange, called MyData Healthway project, is underway in South Korea [5]. Delays or barriers in PHR transfer can result in redundant testing, leading to inefficiencies in both cost and time. In urgent situations where prompt medical intervention is critical, such delays could lead to missed critical treatment opportunities. To facilitate privacy-preserving management of PHR and easy transmission between healthcare entities, this study proposes a decentralized PHR management system that collects PHRs of each individual at his/her private PHR management system and controls privacy-protected PHR transmission at his/her will.

Personal Data Store (PDS) [6] has gained traction to mitigate the challenges of centralized PHR systems. PDS redistributes PHR management from central systems to personal stores, thus empowering individuals to control their data. This approach facilitates PHR’s rapid and effortless transfer to other medical organizations. PDS is pivotal in transitioning from conventional centralized Web 1.0 and 2.0 architectures to a decentralized Web 3.0 model [6]. Web 3.0, a proposed next-generation internet framework, addresses issues where digital information concentration within a few major internet companies led to an unequal distribution of internet information exchange benefits. In this model, PHR sovereignty is wholly returned to data owners, permitting controlled access where only authorized information is shared, thus restoring the advantages of digital information exchange to individuals.

Decentralized identifiers (DIDs) also offer a compelling solution to the inherent vulnerabilities found within conventional PHR management systems [7]. DIDs can be a transformative technology, fundamentally redefining how identity verification and data storage are managed. DIDs facilitate a decentralized architecture that distributes control away from single, centralized entities, thereby enhancing security and privacy [8]. By allowing individuals to govern their personal information autonomously, DIDs mitigate the risk of unwarranted surveillance and ensure data access is conducted on a need-to-know basis [9]. Furthermore, the decentralized nature of DIDs enables seamless and swift exchange of PHR across diverse healthcare systems, thereby eliminating delays, enhancing interoperability, and improving patient outcomes in urgent medical situations [10]. This approach reinforces data privacy and security and promotes a more efficient and responsive healthcare system [11].

The interoperability benefits of PDS and DID address longstanding issues related to divergent identity verification systems, presenting an opportunity to harmonize identity management through seamless integration across various platforms and minimizing cross-border authentication challenges. These decentralized systems empower individuals with greater control over their personal information, allowing them to disclose necessary data and thereby enhance privacy selectively. In the healthcare domain, ensuring the authenticity and integrity of PHR is critical, and the combination of PDS and DID provides advanced capabilities to protect sensitive medical and identity data against tampering, ensuring the security and trustworthiness of such information. Despite these technologies’ profound advantages, particularly concerning PHR systems, their application in healthcare remains underexplored, highlighting the potential for future advancements and implementations.

Our research addresses the gap in current PHR management systems by proposing a self-sovereign PHR management system that concurrently utilizes DID and PDS technologies, capitalizing on their security and privacy advantages while ensuring operations are executed within acceptable timeframes. The proposed system is aligned with the decentralized Web 3.0 internet architecture, storing PHR in a decentralized PDS and empowering individuals to independently manage external access authorizations to their data. We have developed a prototype to demonstrate the feasibility of our system, showcasing that critical tasks can be performed promptly and effectively. Furthermore, our system distinctively offers two critical functionalities compared to existing PDS-based information management systems [12], [13]. The first is an interoperability feature that enables safe and effortless transfer of PHR between medical corporation servers and PDSes, and the second is the ability to fundamentally block the exposure of personal identification information due to careless management within the PDS. This work not only underscores the potential of DID and PDS in revolutionizing healthcare data management but also sets a precedent for future applications in other domains where security and privacy are paramount.

The contributions of this paper can be summarized as follows: The first is to propose a decentralized PHR management system that distributes PHR data in private storages of individuals, called PDS, and fully empowers individuals with control over their healthcare data. PHR data in a medicare entity are transferred to data owners and are easily re-transferred to other medicare entities. The second is to propose a decentralized security mechanism for safe PHR transmission between individuals and medicare entities. Whereas previous centralized security mechanisms suffer from a single point of failure, inherent weakness of internal attacks by an employee, and hegemony burden of preventing a single organization from dominating all security information among many organizations in different countries, the proposed decentralized mechanism removes a single point of failure by duplicated managing security-related data in multiple storages, has no internal human employee by adopting an automatic data management system, called blockchain system, and replaces the single organization dominating security information with the blockchain system. The third is to propose automatic de-identification mechanisms specialized for PHR. In the decentralized PHR system, PHR might be disclosed unintendedly by mistakes due to unskilled management of individuals. To prevent exposure of personal identity information even when mistakes disclose PHR, the proposed de-identification mechanisms search and hide all personal identity information before allowing their read access from external entities. The fourth and last step is to implement all proposed mechanisms on a prototype system and verify its operational validity in real life.

The rest of this paper is organized as follows. In Section 2, background knowledge and existing studies are reviewed. Section 3 describes the proposed method’s system structure and detailed interworking process. In Section 4, the prototype implementation and operational performance results of the proposed system are discussed. Lastly, 5, 6 summarize the study and discuss future research directions. Section 5 discusses the limitations and practical issues of the proposed system, and Section 6 summarizes this study with future research directions.

2. Background and related works

2.1. Background knowledge

The blockchain is a digital ledger system duplicated and distributed across the network of computer systems [14]. The blockchain system has characteristics of immutability, permanent record, transparency, and decentralized autonomous organization(DAO). Smart contract is a digital contract made by programming codes and permanently recorded in the blockchain, which is an immutable contract among multiple participants.

A DID is a decentralized identity authentication technology that substitutes for centralized identity authentication technologies. Whereas the centralized authentication mechanism manages identity verification data non-duplicated and mutably in a single central database, the DID mechanism manages identity verification data duplicated and immutably in the blockchain system [7], [8], [9]. The DID mechanism issues a digital certificate for identity authentication and stores its validity verification data in the blockchain in an encrypted format. A smart contract program on the blockchain system checks whether a digital certificate is valid. The DID mechanism provides zero-knowledge proof, which checks whether a given statement is true without revealing irrelevant information. For example, without revealing the real age, check the statement where the age in the DID digital certificate is older than 40 and younger than 60.

Data sovereignty on the Internet is a system design principle that gives the authority and right to control their data and hands over the benefits of their data usage to individuals [15], [16], [17]. In traditional Internet systems, Internet data of individuals are dominated by a few platform companies such as google and meta, and they monopolize the benefits of data usage. The Web 3.0 Internet infrastructure accommodating data sovereignty was addressed in the studies [6], [18], [19], [20]. Web 3.0 transfers access, ownership, and governance from big Internet platform companies to every user [6]. Web 3.0 differs from conventional Web 1.0 and 2.0 in that Web 1.0 is a “read operation” based communication infrastructure, and Web 2.0 is a “read and write operations” based communication infrastructure. The Web 3.0 Internet is a “read, write and own operations” based communication infrastructure [18]. The demand features of the Web 3.0 Internet Infrastructure are decentralization of data control governance, immutability with the blockchain system, transparency of data management, self-sovereign ownership of user data, digital user identification, privacy-preservation, and interoperability between different protocol networks [19], [20].

2.2. Related works

Table 1 shows the summary of related works. The last column, ‘Enhancement of this study’ explains the enhancement factors of this study compared to the corresponding related works.

Table 1.

Summary of related works.

References	Research contributions	Enhancements of this study
[21], [22]	Efficient data collection in healthcare domains	Design of electric PHR transmission system between different medicare entities based on well-refined PHR data
[23], [24]	Data transforming and quality enhancement for interoperable PHR	Design of online PHR transmission system between different medicare entities based on interoperable PHR data
[25], [26]	Harmonization and standardization of heterogenous healthcare data	Design of online PHR transmission system between different medicare entities based on PHR standardization
[27], [28], [29], [30], [31]	Design of a centralized PHR management system	Design of decentralized PHR management system and design of online PHR transmission system between decentralized PHR systems
[12], [13], [32], [33], [34], [35], [36]	Design of a centralized PHR management system with blockchain-based security functions	Design of decentralized PHR management system and design of online PHR transmission system between decentralized PHR systems
[8], [37], [38], [39], [40], [41]	Design of PDS system without consideration of PHR management and transmission	Design of PDS system specialized for PHR management and transmission

The previous studies [21], [22] investigated the pre-processing procedure to check the quality and reliability of collected data in medicare domains. The previous studies [23], [24], [42] investigated the procedure to transform heterogeneous medicare data into an interoperable format. The previous studies [25], [26], [43] dealt with harmonizing and standardizing medicare data with the HL7 FHIR format. This study assumes that all PHR data are prepared in the interoperable standard form FHIR and focuses on a decentralized PHR management system and online PHR transmission between different medicare entites.

The previous studies [27], [28], [29], [30], [31] investigated the design of a centralized PHR management system with traditional centralized security functions. The previous studies [12], [13], [32], [33], [34], [35], [36] proposed a centralized PHR management system with blockchain-based security functions. Compared to previous studies, our study proposes a decentralized PHR management system with the benefits of data sovereignty and easy transmission between different medicare entities.

The previous studies [8], [37], [38], [39], [40], [41] proposed a decentralized storage system called PDS. These systems are designed without consideration of PHR management. Thus, they suffer from a potential increase of responsibility for individuals to manage and control their data, disclosure of sensitive personal data caused by unskilled management, and data availability and accessibility of local-based PDS platforms. This study proposes a PDS system specialized for PHR management that overcomes the drawbacks of existing PDS platforms: easy management of individual data, automatic protection of sensitive personal identifying information, and data availability and accessibility from remote organizations.

3. Materials and methods

In the proposed PHR management system, individuals’ medical-related data is managed in a decentralized manner using PDS DID technologies. Applying a decentralized PDS storage structure necessitates individuals with low technical skills to manage their storage directly. Therefore, the PDS Access Agent server is designed to provide functionalities for creating PDS storage, managing internal data, and establishing communication connections with external entities (Fig. 1). The PDS Access Agent offers a Graphical User Interface (GUI) to facilitate the creation operation for the user during the PDS storage generation process and performs operations to generate both the PDS storage and AKs. Additionally, it provides a GUI for medical corporations to perform operations for sending and receiving PHR with the individual’s PDS storage. A medical corporation server distributes PHR data to multiple PDS storages according to the data ownership.

Fig. 1.

The workflow of the proposed PHR management system utilizing a PDS Access Agent.

The PDS storage is created at the specified location, and the PDS storage management software executes AK generation and validity verification of received AKs. Through the PDS Access Agent, each individual can create their PDS storage and provide the address of the created PDS storage to a medical corporation. The medical corporation can transmit or receive PHR from the given PDS storage address.

To elaborate further, the user accesses the URL of the PDS Access Agent server through a web-based GUI developed in this study to request the build of PDS storage (Fig. 1(a)). Upon receiving the request, the PDS Access Agent creates the user’s PDS storage in the location specified by the user (Fig. 1(b)). Subsequently, the URL and AK of the created PDS are generated and sent to the user (Fig. 1(c)). The user then selects the medical corporation to be linked and forwards their PDS URL and AK (Fig. 1(d)). Upon receiving the user’s PDS URL and AK, the medical corporation uses this information to request the PDS Access Agent to initiate the transmission or reception of PHR to or from the user’s PDS storage (Fig. 1(e)). The PDS Access Agent verifies the validity of the PDS URL and AK. Upon successful verification, the PDS Access Agent proceeds with PHR’s requested transmission or reception (Fig. 1(f)).

In PHR, many highly sensitive data related to an individual’s privacy must not be exposed to others besides the involved parties. Therefore, the system proposed in this paper employs the following three techniques to prevent exposing PHR to unauthorized individuals. The first technique is the verification method of the PDS repository URL based on the DID digital certificate to prevent legitimate medical corporations from transmitting PHR to incorrect PDS repository URL addresses, which is elaborated in Section 3.1. The second technique is the PDS repository AK management method to block unauthorized medical corporations from accessing the PDS repository without permission from the repository’s owner, explained in detail in Section 3.2. The third technique involves automatically de-identifying personally identifiable information from PHR within the PDS repository to prevent the exposure of information unrelated to medical treatment during the process of accessing PHR from the PDS repository in authorized medical corporations, detailed in Section 3.3.

3.1. Verification of PDS address with DID digital certificate

To prevent PHR from being incorrectly forwarded to unintended recipients due to man-in-the-middle attacks [44] by malicious actors before a medical corporation delivers PHR to an individual, it is necessary to verify the authenticity of the recipient’s PDS repository URL address information. Existing PDS repository management studies have focused on facilitating the creation of PDS repositories [37], [39], [40], [41], neglecting secure methods for transmitting the generated PDS repository addresses to information exchange parties. In the proposed method, medical corporations utilize digital certificates to verify the authenticity of PDS repository URL addresses. As explained in Fig. 1, with the assistance of the PDS Access Agent, individuals create the PDS repository and obtain the URL address of the repository. Subsequently, individuals generate a digital certificate containing the created PDS URL address and transmit it to the medical corporation. The medical corporation then verifies the authenticity of the digital certificate to confirm the legitimacy of the PDS URL address within the certificate. Appendix A.1 explains the operational differences between the conventional and proposed PDS address delivery methods.

Fig. 2 depicts the protocol flowchart for the authenticity verification process of the PDS URL address within the DID digital certificate. When an individual requests PDS repository creation to the PDS Access Agent server, the PDS Access Agent creates the individual’s PDS repository and responds with the PDS repository URL address. Upon the individual requesting the generation of a DID digital certificate from the DID certificate management software along with the received PDS repository URL address, the DID certificate management software verifies the individual’s identity and responds with the digital certificate containing the received PDS repository URL address. Before issuing the DID digital certificate, methods for verifying the individual’s identity include confirming the match of real-time authentication codes sent to the individual’s verified phone or sending a picture taken with an ID card via email for verification. The proposed system adopts the method of verifying the authentication code sent to the individual’s verified phone. The proof information of the generated digital certificate is stored in the blockchain. The proof information stored in the blockchain typically utilizes the public key of asymmetric cryptography algorithms [45], using the private key corresponding to this public key for the DID digital certificate file. Applying the private and public key values of the DID digital certificate file to the asymmetric cryptography algorithm makes it possible to verify if the DID digital certificate file has been tampered with. The DID certificate management software is responsible for verifying the authenticity and integrity of the digital certificate based on the public and private keys. Upon receiving the DID digital certificate, the individual presents it to a medical corporation, which verifies the authenticity of the digital certificate with the DID certificate management software. The DID certificate management software takes charge of the blockchain-related operations supported by the open-source library [46]. Once the authenticity of the digital certificate is confirmed, the medical corporation retrieves the PDS repository URL address field within the digital certificate, enabling the transmission or reception of the individual’s PHR to or from the PDS Access Agent along with the corresponding PDS repository URL information.

Fig. 2.

Flowchart of PDS URL verification with DID digital certificate.

3.2. PDS access control with dynamic key

In the proposed system, an AK is issued to authorized parties to determine the authorization for entities accessing the PDS repository [47]. As depicted in Fig. 1, upon receiving the PDS repository URL address and AK, the medical corporation utilizes API functionalities provided by the PDS Access Agent to request communication with the PDS repository management software. The PDS repository management software verifies if the requesting corporation is an approved entity by comparing the transmitted AK with the issued AK before proceeding with the requested read, write, or modify operations.

In the proposed PDS repository, specific access approval maximum counts are designated for each authorized corporation, deducting these counts upon successful access and utilizing the remainder as the remaining allowed attempts. The access functionalities are segmented into read, write, and modify operations as follows:

• -Read operation: Read contents of files or subdirectories within the repository directory.
• -Write operation: Store new files (or subdirectories) in the repository directory. Deletion or modification of existing file content is not allowed.
• -Modify operation: Delete or modify existing files in the repository directory or store new files (or subdirectories).

The proposed method specifies the maximum allowed counts for read, write, and modify during initial AK creation. With each approved access, the count is decremented by one. Once the count reaches zero, the corresponding operation is no longer authorized. To increase the count after it reaches zero, the AK creation process must be repeated to redefine the maximum allowed count.

Each medical corporation’s access to the PDS repository results in a dynamically changing AK in the proposed approach. By generating the AK based on the maximum allowed counts for PDS repository access, the dynamically created AK changes for each access, considering the adjusted count on each access attempt. The AK value consists of three inputs - the corporation’s authentication information, access maximum allowed counts, and the timestamp, used by a hashing function.

The following outlines an illustrative operational scenario of the proposed method:

• 1.After completing the PDS repository creation, the individual provides the authentication information of the targeted medical corporation (e.g., medical corporation DID digital certificate) to the PDS repository management software.
• 2.The PDS management software conveys the access maximum allowed count information set by the owner individual (e.g., r3w2m1: read three times & write two times & modify one time) and the current time value to the receiving medical corporation.
• 3.The medical corporation calculates the hash value by inputting the received access maximum allowed count information r3w2m1, time information, and authentication information into a hash function (e.g., sha256 [48]).
• 4.The medical corporation requests a “write access” from the PDS management software using the calculated hash value as the AK.
• 5.The PDS management software computes the hash value using the counterpart’s authentication information, the maximum allowed counts information and time information, and if the calculated hash value matches the received hash value, it approves the write request.
• 6.After completing one write request, for the subsequent request, the medical corporation and PDS management software recalculated the hash value with the access maximum allowed information changed to r3w1m1 instead of r3w2m1.

The proposed dynamic AK generation method ensures mutual confirmation regarding the remaining allowed access counts. With the remaining access count information used as input during AK generation, an AK mismatch occurs if the remaining access authorization information is incorrect, preventing unauthorized access. This process allows for detecting traces of illegal usage by others. In cases where unauthorized changes occur in the remaining access counts due to illicit usage, obtaining a new AK through DID mutual authentication ensures that any previously exposed AKs become invalid due to changes in the creation time information used in generating the AK. Moreover, by requiring counterpart authentication information in the AK generation process, the proposed method mitigates the risk of internal personnel transferring remaining access permissions to other institutions without the consent of the PDS repository owner, thus reducing the potential exposure to sensitive authentication information and the associated risks of misuse and loss.

3.3. Automatic concealment of sensitive personal identifying information within PDS

Individuals managing PHR within the PDS repository are not data management experts, which could potentially lead to inadvertent errors resulting in the exposure of PHR unrelated to treatment. Therefore, in the proposed method, even if PHR within the PDS repository is exposed externally, it is designed to prevent inference of the individual’s identity based on this exposed data. Before exposing PHR externally, the proposed method ensures mandatory pre-processing of PHR for de-identification automatically. In the proposed PDS repository, as shown in Fig. 4, input-exclusive and output-exclusive folders are separated to prevent direct data transfer from the input folder to the output folder. The de-identification process software module only allows data transfer from the input and output folders. The de-identification process software module checks if personal identifying information stored in the PHR folder exists within the data in the input folder. If relevant information is found, the module performs de-identification operations on the data to mask it and then transfers it to the output folder. The input folder only permits write or modify operations and does not allow read operations, while the output folder only permits read operations and does not allow write or modify operations.

Fig. 4.

PDS Management SW in PDS Access Agent.

The proposed method applies four de-identification techniques: anonymization, pseudonymization, encryption, and concealment. Depending on the applied anonymization method, data moves to sub-folders within the output folder, as shown in Fig. 3. Anonymization involves removing all personal identifying information from the data in the input folder, making it impossible for anyone to trace back the modified data to its original owner once anonymization is completed. Pseudonymization substitutes personal identifying information with different identifiers. Once pseudonymization is completed, only the original data owner can confirm that the replaced identifier corresponds to their data, thereby preserving anonymity. Encryption involves encrypting all data within the input folder. Upon completion of encryption, only individuals who know the secret key used in the encryption process can access personal identifying information within the data. Concealment hides located personal identifying information among other data. Access to personal identifying information within the data is only possible for those aware of the restoration process specific to the obscured information. In Appendix A.2, operation examples of the four de-identification operations are illustrated.

Fig. 3.

Input and output folder structure within PDS.

4. Results

To verify the operation feasibility of the proposed self-sovereign PHR management system, we implemented the design structure described in Section 3 into an actual prototype system and validated the operational results. Section 4.1 elaborates on the detailed implementation specifics of the prototype system, while Section 4.2 discusses the operational performance of the implemented prototype system.

4.1. Implementation of prototype system

To begin with, we utilized the open-source library [49] provided by Solid to create the PDS repository. The existing Solid library allows for granting read, write, and modify permissions for containers named folders but does not offer functionality for limiting maximum access counts. Therefore, to implement the proposed technique described in Section 3, separate from the Solid library’s functionalities, we added JavaScript code to provide access count settings for read, write, and modify operations for each folder. Other implementation environments are explained in Appendix A.3. Detailed implementation outputs can be found in Appendix A.4.

Fig. 6 depicts the operational interface of the PDS repository management software provided by the PDS Access Agent server implemented in JavaScript. At the top of the figure, the value displayed as “https://13.125.207.117” under “URL of PDS Access Agent” represents the pre-specified URL address of the PDS Access Agent, allowing access to the PDS repository management software via this address. Through the “Login” button, users can create accounts and generate new PDS repositories. The section labeled “URL of User PDS” displays the URL of the PDS repository for the individual user James Bond as “https://210.121.139.90/PDS-Document.” In the bottom left corner, under “Folder Configuration,” the basic Input and Output folders provided by the PDS repository are represented. The Input folder has one sub-folder, and the Output folder has sub-folders for anonymized, pseudonymized, encrypted, and hidden data. By selecting specific sub-folders or choosing “all,” users can designate the folders for data transfer.

Fig. 6.

Lossless image steganography into JPEG image file structure.

The section labeled “ACL (Access Control List)” in the bottom center of the figure allows users to set access permissions for the specified sub-folder. Users can grant access permission, e.g., to the medical corporation with the ID’ hospital02,’ allowing read access up to three times for the four sub-folders within the Output folder. The “Granted ACL List” section on the bottom right displays the granted access permissions. For the medical corporation’ hospital01,’ the write function is permitted up to three times, and the modification function is allowed once for the Input folder sub-folder ‘input.’ For ‘hospital02,’ read access is allowed up to three times for the four sub-folders within the Output folder.

In order to implement the functionality of verifying the PDS repository URL address based on the DID digital certificate, we utilized the ARIES protocol provided by the Hyperledger Foundation [46]. Additionally, we implemented the creation and verification procedures of the DID digital certificate based on the open-source library “ACA-Py” supporting the DID ARIES protocol from the Hyperledger Foundation [50]. The functionality supporting blockchain storage and management of verification information for the DID digital certificates was implemented based on the open-source code “Verifiable Organization Network (VON)” provided by the province of British Columbia [51]. The message flow control for interconnecting the software of medical corporations, personal certificate management, PDS management, and DID management depicted in Fig. 2 was implemented using the Spring framework tool in the Java programming language. The read, write, and modify operations of the PDS repository are provided in RESTful API format based on the PDS repository’s URL address (e.g., the RESTful API for the read operation is provided with the URI “https://13.125.207.117/read”).

The process of searching for and de-identifying personal identifying information in the data of the Input-exclusive folder within the PDS repository when transitioning PHR to the Output-exclusive folder, as explained in Section 3.3, was implemented as a module in the PDS repository management software using the Java language. The prototype system utilized FHIR text data for PHRs and jpg files to store X-ray images. Only the individual’s name and date of birth information were used as personal identifying information, assuming that the names and dates of birth were embedded in the filenames of the X-ray image files, as depicted in Figs 4(c) and (d).

Fig. 5 illustrates the de-identified results of an individual’s name and date of birth from the FHIR text file containing the person’s PHR. Fig. 5(a) shows the result of anonymization, while Fig. 5(b) displays the result of pseudonymization. For the encryption-based de-identification process, the implemented prototype system applied the AES block encryption algorithm [52] based on symmetric key encryption. To implement the concealment-based de-identification process outlined in Fig. 4(d), a lossless image steganography method [53] was employed. Unlike lossy image steganography, which hides information in areas that are difficult to distinguish visually, lossless steganography allows for hiding and retrieving information relatively quickly without losing image data.

Fig. 5.

(a) Anonymization and (b) Pseudonymization results of FHIR record.

Fig. 6 illustrates the process of performing lossless image steganography used in the prototype system. When personal identifying information such as the individual’s name and date of birth are present in the title of a JPEG image file, this information is concealed within the JPEG image file, and the title of the JPEG image file is changed to a timestamped title after the concealment process is applied (e.g., from ‘JamesBond_09081998′ to ‘hidden_06302024.jpg’). The individual’s name and date of birth information are stored in the additional extension areas of the JPEG file, as shown in the left area of Fig. 6.

The JPEG image file format typically starts with a 2-byte start marker, ‘0xFFD8,’ and contains file size information [54]. Based on the file size information, the endpoint of the image pixel information in the Data Area can be determined. The end marker ‘0xFFD9′ also signifies the endpoint where image data is read. Therefore, by adding an arbitrary area beyond the end marker, based on file size information, the image file’s size can be extended without affecting the image’s rendering. Leveraging this characteristic, the concealed personal identifying information is added after the end marker of the original image file.

The right image in Fig. 6 demonstrates the steganography (i.e., concealment) process of attaching the file owner’s name and date of birth information to the additional extension area. In this example, assuming the file owner’s name is ‘JamesBond’ and the date of birth is September 8, 1998, the owner’s name is converted to ASCII digital codes, with each character stored sequentially in 1 byte. The date of birth is separated into two-digit integers and stored sequentially in 1 byte each. A control character ‘NULL’ with an ASCII digital code of ‘00′ is added as a separator between the owner’s name and date of birth. A byte with hexadecimal ‘FF’ is added to signify the end. To hide the added information, ‘plus 2′ operations are performed on the owner’s name and date of birth information. Conversely, to restore the hidden information, ‘minus 2′ operations are performed, and the owner’s name and date of birth information are extracted based on the separator ‘00′ and end marker ‘FF’.

4.2. Performance

In Section 4.1, the implemented PDS repository management software and DID digital certificate verification software were deployed on local servers and cloud servers to measure their execution times. Table 2 presents the execution times of the software for validating the PDS URL within the DID digital certificate and generating the AK for accessing the PDS repository. The local server setup involved running the PDS management software and the medical corporation access software on a single laptop, while the cloud server setup involved deploying the PDS management software on an AWS cloud server and running the medical corporation access software on a laptop. Table 1 displays the mean and variance values of 1000 execution results. URL address validation took approximately 0.6 s in the local server environment, and AK generation took about 0.5 s. URL address validation in the cloud server environment required around 0.8 s, and AK generation took approximately 0.8 s. The local server used in the experiment featured an Intel Core i7–1065G7 CPU, 16 GB of memory, and a 64-bit Windows 10 operating system, while the cloud server utilized an AWS-provided EC2-light CPU with 4 GB of memory and Linux 22.04 version.

Table 2.

Execution time of PDS URL Verification and AK Generation (ms).

	URL Verification		Key Generation
	Local	Cloud	Local	Cloud
Mean (ms)	648	808	557	795
Variance (ms)	3.8	5.1	2.1	2.3

Table 3. shows the local and the cloud server’s execution time based on the data size applied during the PDS repository’s read, write, and modify operations. The results represent the average results of 1000 executions. The results of the local server show that the PDS repository management software and the medical corporation access software are running on a single laptop. In contrast, the results of the cloud server show the outcome of running the PDS management software on an AWS cloud server and the medical corporation access software on a laptop. The cloud server’s execution times are slightly higher than the local server’s. In both cases, read, write, and modify operations took approximately 2 s for data sizes up to 500 MB.

Table 3.

The execution time of local and cloud servers for PDS repository’s read, write and modify operations by data transfer amount.

		Data Transfer Amount (Mbytes)
		1	10	20	40	80	100	200	300	400	500
Read	Local (ms)	22	40	82	107	187	308	479	694	921	1224
	Cloud (ms)	57	68	93	127	215	340	516	745	1021	1324
Write	Local (ms)	32	52	92	158	293	360	598	766	1047	1318
	Cloud (ms)	64	78	106	176	307	375	606	873	1152	1495
Modify	Local (ms)	48	87	117	217	358	497	719	872	1216	1426
	Cloud (ms)	72	104	131	220	393	525	696	998	1294	1666

To compare the execution time of the proposed system with that of the conventional system, we implement the simplified central PHR system where a Mysql database management system plays a role of the PHR management system. Fig. 7 shows the total execution times of read operations with authentication procedure in the previous central PHR system, decentralized PHR system with traditional authentication mechanism, and decentralized PHR system with proposed dynamic access key mechanism. White boxes marked with ‘id/passwd + centralDB’ denote results of the previous central PHR system, where MySQL database system manages PHR and the authentication procedure works with traditional ID and password information. Gray boxes marked with ‘id/passwd + PDS’ denote the results of the decentralized PDS system where the authentication procedure works with traditional id and password information. Black boxes marked with ‘dynamic AK + PDS’ denote the results of the decentralized PDS system where the authentication procedure works with the proposed dynamic access key. Boxes represent the pure execution time of the read operation, and the line above each box represents the additional execution time required for the authentication procedure. The pure execution times of read operation in the centralized PHR are approximately half those in the decentralized PDS system, but their time difference is less than one second in all cases. The additional execution times of the authentication procedure with traditional ID and password information are about 0.2 s, almost equal to those with dynamic access keys. Please note that the manual typing time of ID and password information is not measured, whereas the dynamic access key does not require manual typing. These results imply that the proposed mechanism's actual authentication time is smaller than that of the previous mechanism with typing ID/password information. Although the read times of the proposed decentralized PHR system are larger than those of the centralized PHR system, the difference within one second might not be critical.

Fig. 7.

Execution time comparison of conventional and proposed mechanisms.

Table 4, Table 5 display the time taken for the de-identification process within the Input-exclusive folder when transitioning to the Output-exclusive folder in the PDS repository. The time taken for the process increases proportionally with the size of the files being processed. It is observed that the processing time increases with increasing file sizes. The anonymization and pseudonymization operations for a 500 Kbyte text file took approximately 0.2 s, while encryption for a 20 Mbyte image file required around 2 s, and concealment took about 1 s

Table 4.

Execution time of anonymization and pseudonymization operations on text file.

	Text File Size (Kbytes)
	1	10	50	100	200	300	400	500
Anonymization (ms)	11	16	33	54	74	92	111	134
Pseudonymization (ms)	61	62	88	107	128	146	167	185

Table 5.

Execution time of steganography and encryption operations on image file.

	Image File Size (Kbytes)
	200	300	400	500	1000	5000	10000	20000
Steganography (ms)	869	884	901	922	940	987	1011	1054
Encryption (ms)	423	517	683	812	1097	1512	1737	1957

4.3. Comparison of security issues

Table 6 compares the security analysis results of previous and proposed systems. Regarding the single point of system failure, the proposed mechanism is not affected due to redundant data management on distributed multiple systems. In contrast, the previous centralized system needs to prepare a backup system and requires time-consuming replacement with the backup system. The proposed DID mechanism uses an unmodifiable common digital certificate file to manage the burden of authentication information. In contrast, the previous authentication mechanism based on ID and password requires memorization of different authentication information at each central system, and this authentication information is vulnerable to attacker modifications. Regarding PDS address tampering, the proposed DID mechanism can check whether the PDS address in the DID digital certificate is modified, whereas the previous mechanism cannot. Regarding the exposure risk of access to the PHR system, the proposed dynamic access key mechanism is not affected by exposure of the previously used access key. In contrast, the previous access control mechanism does not operate correctly if the previously used access key is exposed to other legitimate parties. Regarding the exposure risk of personal identity information in PHR, the proposed de-identification mechanism systematically prevents exposure of personal identity information by hiding it before allowing the external connection, whereas the previous PHR management system does not support any solution.

Table 6.

Security analysis comparison of previous and proposed systems.

Comparison factor	Previous mechanism	Proposed mechanism
Single point of system failure	Preparing a backup system and requiring time-consuming replacement	No damage
Management burden of authentication information	Modifiable different authentication information at each central PHR system	Unmodifiable common digital certificate
Tampering weakness of PDS address	Possible tampering of PDS address	Impossible tampering of PDS address
Exposure risk of access key	Possible reuse of static access key	Impossible reuse of dynamic access key
Exposure risk of personal identity info. in PHR data	No solution	Systematic exposure prevention of personal identity info. In PHR data

5. Limitations and practical issues

Conventional centralized PHR systems have consistently faced challenges, particularly in transferring critical health data rapidly across institutions. This inefficiency can lead to redundant medical testing and significant delays, which are especially detrimental during emergencies. The transition from conventional centralized PHR management systems to decentralized frameworks, as explored in this paper, offers vast potential to revolutionize the way healthcare data is managed and exchanged.

However, the proposed system design needs more development of new functionalities and feasibility testing in real-world medicare domains. The limitations of this study are as follows: The proposed system works only with perfectly interoperable PHR data because it does not support the transformation of non-standard PHR data into the standard format. The proposed system needs an additional functionality of PHR data integrity verification, especially for PHR data modified by the proposed de-identification procedure. Medicare specialists need the integrity verification process to determine whether the PHR data obtained from the proposed system have been modified. Also, there are many implementation issues for easy and safe usages of the decentralized PHR system, such as interoperability between heterogenous PDS platforms, interoperability between PDS platform and legacy healthcare management systems, simplified operation design working with fewer human actions, and achieving fast execution time close to conventional PHR systems. Because the decentralized PHR management system with decentralized and dynamic authentication mechanisms handled in this article is the first study, other technical obstacles or practical issues not mentioned above might remain. Policy-based, security, and privacy risks need to be examined in more detail in further studies.

6. Conclusions

This paper proposes a self-sovereign PHR management system structure that manages PHR in a decentralized form. The proposed system structure utilizes PDS distributed storage technology to manage individual PHRs separately in personal repositories rather than scattered across various medical corporations, providing a self-control feature for external access approval to PHRs. Additionally, it is designed to facilitate the quick and easy transfer of PHR to other medical corporations. The system is also designed to provide interoperability features for secure and seamless transfer of PHR between individual PDS storage and medical corporation servers, as well as a function to prevent exposure of personal identity information due to management negligence within the PDS storage. We constructed the proposed system design into an actual prototype system to confirm the operational validity of the proposed system, ensuring that the computations constituting the PHR management system are completed within 2 s each. This method is significant as it is the first to address convenient and secure interoperability between medical corporations and decentralized PDS, as well as providing a function to prevent exposure of personal identity information.

Expected benefits of the proposed system are cheaper medicare costs by eliminating redundant medical tests, faster medical treatment of doctors with fast collection of medicare data, and more accurate medical treatment with transfer of more medical data than verbal provisioning of patients. This approach designed for the medical domain can apply to other domains such as consulting, personal insurance, job recruiting, and international school entrance.

As discussed in Section 5, many unsolved limitations and practical issues remain in the real-world medical domain. The representative technical limitation of this study is the absence of a guarantee mechanism that the medical data in the proposed systems is true except for the hiding of personally identifiable information. Also, the interopausal between heterogeneous PDS platforms and the interoperability against legacy healthcare management systems are absent. In our next research, we will investigate solutions for these technical limitations. After solving major technical limitations, we will deal with practical issues in real-world medical environments.

Funding

This research was supported by a grant of the Korea Health Technology R&D Project through the Korea Health Industry Development Institute (KHIDI), funded by the Ministry of Health & Welfare, Republic of Korea (grant number: RS-2023-KH134423, RS-2023-KH134396) and by the National Research Foundation of Korea (NRF) grant funded by the Korea government(MSIT) (No. 2022R1C1C2002987) and by the Basic Medical Science Facilitation Program through the Catholic Medical Center of the Catholic University of Korea, funded by the Catholic Education Foundation.

CRediT authorship contribution statement

Hyung Goo Paek: Writing – review & editing, Software, Resources. Byoung Woo Hwang: Writing – review & editing, Software, Resources. Taehoon Ko: Writing – review & editing, Supervision, Project administration, Funding acquisition. Tong Min Kim: Writing – original draft, Visualization, Project administration, Methodology, Investigation, Funding acquisition, Conceptualization. Wan Yeon Lee: Writing – review & editing, Validation, Software, Methodology, Formal analysis, Data curation, Conceptualization.

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

Appendix

Difference between conventional and proposed PDS address delivery

Fig. 8 illustrates the operational differences between the conventional (Fig. 8(a)) and proposed (Fig. 8(b)) PDS address delivery method, where DID-CMS denotes DID certificate management software. In the conventional address delivery method depicted in Fig. 8(a), individuals complete personal authentication using an ID and password and then transmit the PDS URL address [55]. In the conventional method, there is a risk of transmitting fake PDS URL addresses if the ID and password information managed by the individual is compromised. Furthermore, there is a risk of fake PDS URL addresses being substituted and transmitted by a man-in-the-middle attack while completing personal authentication and delivering the PDS URL address. In the proposed method shown in Fig. 8(b), digital certificates managed in encrypted files are utilized. Even if the digital certificate is lost and manipulated by a third party to alter the PDS URL address, the digitally signed certificate containing the manipulated PDS URL address will fail authenticity verification due to inconsistencies with the verification information stored in the blockchain system. The proposed method adopts DID digital certificate technology for PDS URL address verification. Compared to conventional centralized digital certificate methods, DID digital certificate methods [8] provide increased reliability through the redundancy of validation information in distributed systems like blockchains, enhancing irreversibility to offer higher trustworthiness.

Fig. 8.

PDS address delivery methods: (a) Conventional and (b) Proposed.

Examples of four de-identification operations

Fig. 9 illustrates the operational examples of the four de-identification operations. For data within the input folder, personal identity information like individual names, date of birth, residential address, phone numbers, and medical visit dates - unrelated to medical procedures - are detected and subjected to de-identification operations to move to the output folder. Fig. 9(a) demonstrates the anonymization operation, wherein information irrelevant to medical statistics, such as individual names, phone numbers, and medical visit dates, is deleted. In contrast, general information like city-level residential addresses, birth years within 10-year ranges, and medical visit months are retained. The anonymized information makes it unfeasible for the original data owner to verify if the anonymized information pertains to them. Fig. 9(b) illustrates the pseudonymization operation. Unique identifiers and pseudo-phone numbers, which may be utilized for personal identification, are added. The pseudo phone number can be matched with an actual phone number through a third party for call connections. Data owners can decide whether to block or receive calls through a third party without revealing their phone number. Fig. 9(c) depicts the encryption operation. Personal medical image files are encrypted using a secret key, and the text containing personal identifying information in the file name is also encrypted. The encrypted information can only be utilized by the original data owners and some authorized institutions that possess the secret key information for decryption. Fig. 9(d) shows the concealment operation, technically called steganography [53], where personal identifying information embedded in the name of personal medical image files is hidden by modifying the image files to conceal the information. The concealed information can only be verified by the data owner and selected institutions aware of the concealment restoration process. The concealment operation distinguishes where medical-related data is exposed, unlike the encrypted information in Fig. 9(c), which hides medical-related data and personal identifying information.

Fig. 9.

Four de-identification procedures: (a) Anonymization, (b) Pseudonymization, (c) encryption, and (d) Concealment.

Implementation environments

The solid open-source library was selected because it is the most popular with the longest developing time and the most stable with fewer bugs among open-source libraries. The Hyperledger Aries protocol was selected because no open-source library supports DID technology.

The local server used for this experiment is the laptop network with i7–1065G7 CPU, 16Gbytes memory, and 64-bit Windows OS. Remote cloud servers are Amazon Elastic Compute Cloud (AWS EC2) of the t2.small option with 2 Gbytes memory. One local server and five remote cloud servers are used. The network is 100 Mbps Ethernet. Input data for performance evaluation are FHIR text data from a GitHub site [56] and X-ray images from the Catholic University of Korea. The used database management system is MySQL.

To support the irreversibility trust of the system by redundantly storing the authenticity information, we construct the blockchain system with four AWS EC2 servers labeled as node 1, node 2, node 3, and node 4 [57]. The number of duplicate storage servers for the blockchain system can be adjusted by modifying the parameters in the VON open-source code [28]. Importantly, all information related to the DID digital certificates is stored in an encrypted state within the blockchain system. Therefore, unauthorized parties cannot access information related to DID digital certificates, ensuring data security and privacy.

Detailed implementation outputs

The image in Fig. 10(a) displays the screen of running API functions provided by the ACA-Py open-source library through docker processes. The image in Fig. 10(b) shows the result screen of creating a single DID digital certificate using the API functions of ACA-Py provided by docker, consisting of the ‘name,’ ‘birth,’ and ‘pdsURL’ fields.

Fig. 10.

(a) Docker with ACA-Py API, (b) creation result of the DID digital certificate, and (c) verification of PDS URL in DID certificate.

The image in Fig. 10(c) displays the screen where a medical corporation queries the DID digital certificate management software about the stored items within the DID digital certificate, as described in Section 3.1, to verify the authenticity of the content. The queried digital certificate contains the ‘name’ field with the information “JamesBond,” the ‘birth’ field indicating September 8, 1998, and the ‘pdsURL’ field displaying ‘210.121.139.90/PDS-Document.’ The screen confirms this information by checking the blockchain. In the implemented prototype system, the ‘pdsURL’ field information is transformed into the PDS URL address by adding “https://” at the beginning as “https://210.121.139.90/PDS-Document.”