EMR-Chain: Decentralized Electronic Medical Record Exchange System

Abstract

Current systems for exchanging medical records struggle with efficiency and privacy issues. While establishing the Electronic Medical Record Exchange Center (EEC) in 2012 was intended to alleviate these issues, its centralized structure has brought about new attack vectors, such as performance bottlenecks, single points of failure, and an absence of patient consent over their data. Methods: This paper describes a novel EMR Gateway system that uses blockchain technology to exchange electronic medical records electronically, overcome the limitations of current centralized systems for sharing EMR, and leverage decentralization to enhance resilience, data privacy, and patient autonomy. Our proposed system is built on two interconnected blockchains: a Decentralized Identity Blockchain (DID-Chain) based on Ethereum for managing user identities via smart contracts, and an Electronic Medical Record Blockchain (EMR-Chain) implemented on Hyperledger Fabric to handle medical record indexes and fine-grained access control. To address the dual requirements of cross-platform data exchange and patient privacy, the system was developed based on the Fast Healthcare Interoperability Resources (FHIR) standard, incorporating stringent de-identification protocols. Our system is built using the FHIR standard. Think of it as a common language that lets different healthcare systems talk to each other without confusion. Plus, we are very serious about patient privacy and remove all personal details from the data to keep it confidential. When we tested its performance, the system handled things well. It can take in about 40 transactions every second and pull out data faster, at around 49 per second. To give you some perspective, this is far more than what the average hospital in Taiwan dealt with back in 2018. This shows our system is very solid and more than ready to handle even bigger workloads in the future.

1. Introduction

Taiwan handles nearly 1.2 million patient referrals annually, with each case involving a transferring and a receiving hospital. According to a National Health Insurance Administration report [1], the receiving hospital often requires the patient’s medical records from the transferring facility for an accurate diagnosis.

Historically, this process was challenging. Patients were required to obtain and physically deliver printed copies of their medical records, a practice that was inefficient, wasteful, and costly. Taiwan launched the Electronic Medical Record Exchange Center (EEC) to address these issues in 2012. The EEC enables doctors to access a patient’s medical records from the past six months, provided they have the patient’s authorization. This system has significantly reduced resource waste and financial burdens.

Figure 1 shows that the EEC’s architecture requires participating hospitals to establish a dedicated gateway [2,3]. As described by Li et al., this gateway operates independently from the hospital’s internal systems and databases. Hospitals upload designated medical records to the gateway, and the EEC server indexes these records across all participating facilities.

The EEC server creates a comprehensive index of all medical records in the gateways and provides search and retrieval services to hospitals. For a doctor to access a patient’s records, the patient must insert their National Health Insurance IC card, and the doctor must use their medical certificate IC card. After the patient submits a consent form, the hospital connects to the EEC server via its gateway. The EEC server then provides the index for the requested medical records and facilitates retrieval by connecting to the hospital’s gateway for holding the records.

This current system architecture, however, faces several challenges. First, each medical record review relies on an index provided by the centralized EEC server, making it a potential performance bottleneck. Second, with nearly 1.2 million referrals annually (averaging about 2.28 referrals per minute), hospitals must store records in two locations—their internal database and the EEC gateway—which leads to significant storage inefficiencies. Furthermore, the system limits patients’ ability to manage access to their medical records. Once a patient submits a consent form, doctors access all of the patient’s records from the past six months. This all-or-nothing approach deprives patients of the ability to share records selectively and falls short of modern data access control standards, such as those found in GDPR [4].

To address these issues, this study proposes a decentralized electronic medical record exchange system that leverages two blockchains and medical record databases maintained by individual hospitals. The first blockchain, the Decentralized Identity Blockchain (DID-Chain), provides users with a decentralized identity, allowing them to manage their data across various applications. The second blockchain, the Electronic Medical Record Blockchain (EMR-Chain), records relevant medical data and indexes. During record retrieval, the EMR-Chain provides the corresponding index and enforces access controls via smart contracts, which authorize doctors to access records based on patient-defined permissions. Readers can refer to Appendix B for detailed explanations of key technical terms.

The EMR-Chain incorporates a regional identity management system to facilitate the involvement of various roles in the medical record exchange process. The system ensures data privacy and strengthens on-chain data protection in multi-role scenarios by employing role-based access regulations through smart contracts. Furthermore, the EMR-Chain provides an audit trail function, enabling patients to monitor access logs for their medical records at any time.

This decentralized system resolves existing challenges by eliminating the centralized bottleneck of the EEC server, reducing storage redundancies, and enabling patients to grant selective access to their medical records. Integrating enhanced access controls through smart contracts significantly improves the privacy and security of medical records. In contrast, providing access logs ensures transparency and facilitates investigations in disputes.

This paper is structured as follows. Section 2 reviews the current state of electronic medical record exchange, sharing, authorization, and blockchain-based access control. Section 3 introduces the proposed system model. Section 4 describes the system implementation and demonstration, while Section 5 presents the evaluation results. Finally, Section 6 concludes the study and discusses directions for future work.

2. Background and Related Works

This section comprehensively reviews two pivotal technological domains pertinent to the present investigation: the historical trajectory and contemporary significance of Electronic Medical Records (EMRs) within modern healthcare ecosystems, and the transformative potential inherent in blockchain technology for ameliorating the intrinsic challenges pervasive in extant EMR infrastructures.

2.1. The Evolution and Current State of Electronic Medical Records (EMR)

EMRs have undergone a transformative journey, evolving from a foundational concept into a critical infrastructure within contemporary healthcare settings.

This is not just about new tech; it is also tied to significant changes in how we think about medical safety and the rules around it. We can split their development into three main phases based on the tech’s maturity and what drove the changes.

The first phase, from the 1960s to the 1980s, was about getting started and trying things out. Back then, universities mostly pushed EMRs to see if computers could help manage medical records. We saw some groundbreaking systems pop up, like the Problem-Oriented Medical Information System (PROMIS) from the University of Vermont. This one was a game-changer because it introduced a problem-oriented way of recording things, shaping how medical records were designed later [5]. Other notable systems included COSTAR, developed at Massachusetts General Hospital, which focused on outpatient medical records, and the HELP system at LDS Hospital, recognized for its early implementation of clinical decision support for physicians. However, these early systems were expensive, hard to use, and the tech was not ready for prime time. They mostly stayed in academic labs and did not make it into everyday clinical use.

The second phase, the 1990s, was a turning point with major tech breakthroughs and many more practical uses. The explosion of personal computers (PCs), user-friendly Graphical User Interfaces (GUIs), and the internet taking off were huge factors in making EMRs work in the real world. The HealthConnect project was a big win during this time, a joint effort between IBM and Kaiser Permanente. They digitized medical records on a massive scale across a huge healthcare network [6]. This project proved, without a doubt, that EMRs were possible and beneficial in actual clinical settings, moving them from theory to practice.

From the early 2000s until now, we have been in the third phase, which is all about policies pushing things forward, a strong focus on safety, and EMRs becoming super common. A serious look at medical safety drove development in this phase. The super important 1999 report from the Institute of Medicine (IOM), called “To Err Is Human,” showed how many people died each year from preventable medical errors. It also highlighted how bad traditional paper records were regarding accuracy and information sharing [7]. This report completely changed how we viewed EMRs—they were not just about making things efficient anymore; they became crucial for patient safety. Because of this, the U.S. government passed the Health Information Technology for Economic and Clinical Health (HITECH) Act in 2009. Through its “Meaningful Use” program, this act poured billions of dollars into encouraging EMR adoption, which sped up their spread across the United States [8]. Today, EMRs are the go-to information hubs in modern healthcare. Nevertheless, it is important to acknowledge that these systems also present several significant challenges, particularly in terms of system interoperability, data security, and data ownership. These issues have become increasingly prominent and critical in recent years.

2.2. The Application and Potential of Blockchain Technology in EMR Systems

The EIP solution provider for blockchain networks, introducing a decentralized NoSQL database integration, recently built an enterprise data solution that extends beyond transactional and information management to rich-client communication, rating services, and resource scheduling across firewall boundaries. It has been widely acknowledged that the transformative power of blockchain springs from its intrinsic properties, such as decentralization, cryptographic security, and immutability, many of which serve to be alternative robust architectural solutions for these critical limitations. While not a direct competitor to existing EMRs, it is better viewed as an additional layer of decentralized trust that works in tandem with them. At its core, we have identified its principal offers:

2.2.1. Patient-Centric Data Governance and Autonomy

Blockchain Architectures: Enabling a Revolution Around Data Ownership. Blockchain architectures facilitate an illustrious modification in conventional practices, allowing patients to manage their medical records. Patients control access permissions on-chain using private keys, while primary clinical data remains securely off-chain. Using smart contracts, granular access rules defined by the patient execute and provide a hitherto unseen level of control over personal health information.

2.2.2. Immutable Auditability and Data Provenance

It delivers a transparent, non-repudiable audit trail. Even the most sensitive steps of data access and modification that require authorizing rights are timestamped as an immutable transaction and stored forever.

2.2.3. A Shared Metadata Layer for Interoperability

Blockchain can serve as a universal, shared index of medical record metadata, connecting disparate healthcare institutions without mandating an overhaul of their internal systems. By registering pointers to records on the blockchain, providers can utilize it as a trusted medium to verify identity and confirm access rights before initiating a secure, peer-to-peer data exchange with the source institution, thus reducing friction and integration costs.

2.2.4. Real-World Implementations and Future Outlook

The feasibility of these applications is supported by global pilot projects, such as MIT’s MedRec and Estonia’s national health record system secured by KSI blockchain technology. While significant barriers related to scalability, legacy system integration, and regulatory clarity must still be overcome, the potential of blockchain to re-engineer trust and collaboration within the healthcare ecosystem is widely acknowledged by researchers and industry practitioners.

2.3. Related Research

The issue of medical record standards is a critical area of research, with [6] highlighting the importance of unified standards, such as Fast Health Interoperability Resources (FHIR), for achieving robust interoperability. Accessibility is another crucial aspect, as discussed in [9], which examines how systems regulate access to electronic health records (EHRs) through access control rules and patient authorizations. Building on these principles, Rosar and Chuang [10] proposed an EMR exchange system that leverages FHIR for enhanced interoperability.

Smart contracts offer an innovative approach to managing EMR systems, as proposed by Mishra et al. [11]. These contracts automatically execute when predetermined conditions are met, ensuring transparency and reducing administrative overhead for authorizations. Furthermore, smart contracts facilitate collaboration among participants within the EMR system. For instance, Lax et al. [12] introduces a blockchain-based architecture where patients maintain full control over authorizations. In this model, medical records are stored off-chain, with their storage addresses indexed on the blockchain. An Identity Provider (IdP) verifies patient identities and issues assertions for authorization, which requesters can use to access the medical records.

To address data ownership and control, Bach et al. [13] employed multi-signature contracts. This method requires the patient and the hospital to use their private keys to sign a transaction for authentication. While this prevents the patient from unilaterally altering a record, it ensures that the patient retains control over who can access their data.

Several hybrid approaches combining cryptographic mechanisms with smart contracts have been proposed to enhance security. For instance, Yang et al. [14] introduced a system that leverages proxy re-encryption (PRE), enabling authorized physicians to access electronic medical records (EMRs) with their private keys. This method mitigates the risks associated with private key leakage and reduces computational overhead.

Alternative cryptographic strategies have also been explored. Velmurugan et al. [15] proposed a method using Modified Key-Policy Attribute-Based Encryption (MKP-ABE) to secure EMRs stored in cloud databases, requiring a Hashed Access Code for retrieval. Their experimental analysis demonstrated that MKP-ABE provides superior security to conventional algorithms such as KP-ABE, ECC, RSA, and AES.

Vidhya and Kalaivani [16] also designed a framework utilizing multiple Certificate Authorities (CAs) to address vulnerabilities associated with single points of failure in trust management. By requiring each organization to maintain one or two intermediate CAs, this model ensures operational continuity even if a single CA is compromised, underscoring the enhanced security afforded by a decentralized trust architecture.

Privacy-preserving EMR management was explored by Jakhar et al. [17], which incorporates role-based access control to maintain privacy and security within a multi-participant blockchain network. Fine-grained access control was further achieved by Kaur et al. [18] and Cui and Chen [19] through Ciphertext Policy Attribute-Based Encryption (CP-ABE). This method shifts from a role-based to an attribute-based access model, requiring requesters to meet specific attributes defined by data owners to access records, thereby significantly enhancing access granularity.

In summary, blockchain-based EMR architectures typically store records externally while using the blockchain as an indexing server to maintain data integrity via hash values. Access control mechanisms vary from encryption algorithms to token- or assertion-based authorizations. While identity management is crucial for system access and key pair generation, few studies explore its integration with smart contracts for fine-grained access control. Furthermore, the concept of sub-authorization remains underexplored, and a unified data-sharing format is rarely emphasized. Incorporating sub-authorization could significantly enhance patient privacy, while unified standards would improve hospital interoperability.

Table 1. Summary of related work of HER/EMR systems.

Author	IM	SE	Aut.	Int.	Pri.	S-Aut.	SC.-AC.	St.-For.
M. Rosar and K.-T. Chuang [10]	X	V	V	V	V	X	X	V
A. K. Mishra et al. [11]	Cen.	X	V	V	X	X	X	V
G. Lax et al. [12]	Cen.	V	V	V	V	X	X	V
T. Bach et al. [13]	Dcen.	V	X	V	V	X	X	V
X. Yang et al. [14]	Dcen.	V	V	V	V	X	V	V
Velmurugan et al. [15]	Dcen.	V	V	V	V	X	X	V
S. Vidhya and V. Kalaivani [16]	Dcen.	V	V	V	V	X	V	V
A. K. Jakhar et al. [17]	Cen.	V	V	V	V	X	V	V
J. Kaur et al. [18]	Cen.	V	V	V	V	X	X	V
Our Research	Dcen.	V	V	V	V	V	V	V

compares the features of our proposed research with related works, with a V denoting clearly stated properties and an X indicating properties that are not explicitly mentioned in the literature. The interoperability (Int.) and privacy (Pri.) features are critical for modern EMR systems (see Appendix C for abbreviation definitions).

3. System Design

This paper introduces an improved electronic medical record (EMR) exchange system, specifically designed to tackle the shortcomings of Taiwan’s current setup. Our system uses a layered architecture with three main parts: a decentralized identity blockchain (DID-chain), an application blockchain (EMR-chain), and distributed FHIR servers at each hospital. This design is all about giving patients more control over their data, making sure different systems can talk smoothly, and boosting the security of the whole exchange process.

3.1. High-Level System

The system’s architecture, illustrated in Figure 2, is composed of the following key elements:

• Decentralized Identity (DID) Chain: Adapted from the architecture presented by Hsieh et al. [20], the DID-chain provides a self-sovereign identity management system. It operates independently of any central authority, granting users complete control over their personal identity data and mitigating the risks of centralized data breaches.
• Application (EMR) Chain: This Hyperledger Fabric-based blockchain governs access control, data authorization, and maintains an immutable audit trail of all transactions. Any personally identifiable information on the EMR-chain undergoes de-identification to protect user privacy.
• Hospital FHIR Servers: Each participating hospital operates its own FHIR server, a distributed, interoperable repository for patient medical records. Adherence to the FHIR standard ensures a unified data exchange format across disparate healthcare institutions.

The subsequent sections provide a detailed exposition of each component.

3.2. DID-Chain: A Global Identity Management System

The DID-chain (Figure 3) is the system’s global identity layer. It is implemented on the Ethereum blockchain to leverage its mature ecosystem of digital wallets. Identities on this chain, termed “Main Identities,” are managed by two core smart contracts:

IdentityManager: This contract is responsible for creating and managing user identities after verification by a trusted authority (e.g., a government agency).

Personal: A dedicated contract created for each user that serves as a secure, user-controlled vault for personal information, such as encrypted private keys for other application chains.

This architecture facilitates a global identity system where a single, government-endorsed Main Identity can be used to authenticate and interact with multiple, independent application networks.

The DID-chain serves as the system’s global identity layer, implemented on the Ethereum blockchain to leverage its mature ecosystem of digital wallets. On this chain, user identities are called ‘Main Identities’ and are primarily managed by two core smart contracts: IdentityManager and Personal. The IdentityManager contract is responsible for creating and managing user identities after verification by a trusted authority, such as a government agency. Conversely, the Personal contract is a dedicated contract created for each user, serving as a secure, user-controlled vault for personal information, such as encrypted private keys for other application chains. For a detailed design of the IdentityManager and Personal smart contracts, including their pseudocode and functional descriptions, please refer to Appendix A.1.

3.3. EMR-Chain: The Application-Specific Governance Layer

The EMR-chain is implemented on Hyperledger Fabric and was selected for its permissioned nature, multi-channel capabilities, and superior transactional throughput compared to public blockchains. It segregates functionalities into three distinct channels to enforce modularity and granular control.

3.3.1. The IdentityManagement Channel

This channel (Figure 4) establishes an application-specific identity system on top of the global DID-chain. It manages roles within the EMR ecosystem, which is essential for enforcing fine-grained access control.

Role Management: The channel supports three primary roles: Patient, Doctor, and Supervisor. Users onboarded by participating hospitals are initially assigned the Patient role. The Healthcare Certificate Authority (HCA) and the Ministry of Health and Welfare (MOHW) verify credentials and elevate users to Doctor and Supervisor roles, respectively.

Accountability Link: To ensure accountability while preserving privacy through on-chain de-identification, this channel records a mapping between a user’s EMR-chain identity and their Main Identity’s public key. This link allows for unambiguous user identification in disputes or security incidents.

3.3.2. The AccessControl Channel

This channel manages permissions for accessing medical records. A distinct data instance is created on this channel for each patient-hospital relationship. Each instance contains three key components:

Access Control List (ACL): Defines the rules governing access to the EMRs stored at that hospital. The default ACL implements a hierarchical policy based on Taiwan’s graded medical care system [21], permitting access only by hospitals of an equal or higher level. This policy is adjustable by the patient, who can grant more lenient permissions as needed.

Hash Value: The cryptographic hash of the off-chain medical record, serving as an immutable reference to ensure data integrity.

Address: The network location of the off-chain FHIR resource, enabling retrieval after successful authorization.

The smart contract on this channel provides the following core functions:

Authorization (): Evaluates access requests against the patient’s ACL and, if approved, generates a time-limited JSON Web Token (JWT) for the Data Requester.

updateInstance()/updateHash(): Allows a user with the Doctor role to upload a new instance or update the hash value of an existing record.

consentAccess()/revokeAccess(): Enables a user with the Patient role to dynamically modify the ACL rules for their records at a specific hospital.

validateHash(): A provider can compare a locally held hash against the on-chain hash to detect if a record is outdated.

3.3.3. The TransactionRecord Channel

This channel (Figure 5) provides an immutable and non-repudiable audit trail of all data access requests.

Purpose: Its primary functions are to allow patients to monitor access to their records and to serve as conclusive evidence in the event of a dispute.

Security and Scalability: To ensure the integrity of the audit logs, write access is restricted to identities with the Supervisor role. Older logs are periodically archived to external storage to maintain node performance, with their collective hash value recorded on-chain to preserve the integrity of the complete audit history.

3.4. FHIR Server: The Interoperable Data Layer

To ensure interoperability and align with Taiwan’s national healthcare strategy, the system mandates that each participating hospital operate a server compliant with the Fast Healthcare Interoperability Resources (FHIR) standard [22]. These servers act as the distributed, off-chain repositories for EMR data, utilizing a “resource”-based data model for granular and standardized data exchange.

Two primary mechanisms fortify the security of these servers:

• Read-Only Access: The FHIR server endpoints are configured for read-only operations to prevent any unauthorized modification of the source medical records.
• Token-Based Authentication: A mandatory Token Validator module is integrated into the server’s access layer. This module intercepts every request to validate the associated JSON Web Token (JWT), confirming its signature, expiration, and the holder’s authorization. Access to medical records is granted only upon successful validation; all other requests are denied.

This two-tiered security model ensures that data is accessed only by authenticated and authorized parties in a secure, non-destructive manner.

3.5. Smart Contract Design

The system’s core logic and governance are implemented through smart contracts and chaincodes distributed across the DID-chain and the EMR-chain. This section provides an overview of their design and core responsibilities.

3.5.1. Smart Contracts on the DID-Chain

The DID-chain’s architecture (Figure 6) is composed of two primary smart contracts that work in tandem to manage global identities:

• IdentityManager Contract: This contract functions as a public, on-chain registry. Its primary responsibilities are to record verified Main Identities and to provide a universal authentication interface for external applications.
• Personal Contract: In contrast, the Personal Contract serves as a private, user-specific data vault. It is programmatically linked to the user’s primary identity but remains under their exclusive control. It is used for storing sensitive information such as encrypted private keys for other applications.

For a comprehensive breakdown of the detailed design and pseudocode for both the IdentityManager and Personal smart contracts, please refer to Appendix A.1.

3.5.2. Chaincodes on the EMR-Chain

The EMR-chain’s governance is implemented through three distinct chaincodes deployed on a dedicated channel to ensure functional segregation and modularity (Figure 7).

• IDM Chaincode: Governs application-specific identity and role management.
• ACL Chaincode: Manages fine-grained access control policies for medical records.
• TSR Chaincode: Maintains a non-repudiable audit trail of all access events.

The specific functions and operations of these chaincodes are detailed in the subsequent sections.

3.6. Role-to-Function Permission Mapping

The system’s security model is enforced through a strict Role-Based Access Control (RBAC) mechanism.

Table 2. This table presents the function list of the DID-Chain smart contract.

Function	Description	Permitted Roles
IdentityManager— addUser()	A unique Main Identity is generated using the hash of the user’s national identification number.	Government Agency: Upon successful verification of the user’s identity, the government agency initiates a request to generate the Main Identity.
IdentityManager— bindWallet()	The user’s digital wallet is linked to their Main Identity, and a Personal contract is created accordingly.	Government Agency: After the user submits their wallet address along with the unique identifier of their Main Identity to the appropriate government agency, the agency proceeds to issue a binding request.
IdentityManager— authentication()	Enables application providers to verify the user’s digital signature as part of the authentication process.	Application providers, such as EMR-Chain service providers or affiliated hospitals.
IdentityManager— getId()	Extract the user’s Decentralized Identifier (DID).	Any entity requiring verification or query of the DID, such as application providers and end users through the dashboard interface.
IdentityManager—getUserType()	Extract the type of the user’s identity.	Any entity requiring verification or query of the user’s identity type.
IdentityManager—getPersonalAddress()	Extract the address of the user’s Personal smart contract.	Any entity requiring access to the Personal contract address, such as application providers and end users through the dashboard interface.
Personal—set-app-private()	Enables users to securely store their application chain private key or other personal information within the Personal contract, with all data encrypted prior to upload.	Patient/Data Owner: As an integral part of their decentralized identity, the patient retains full control over this contract.
Personal—get-app-private()	Enables users to retrieve encrypted information stored within their Personal contract.	Patient/Data Owner

,

Table 3. This table outlines the functions provided by the EMR-Chain Identity Management chaincode.

Function	Description	Permitted Roles
IDM—beforeTransaction()	Executed prior to any function invocation, this is used to enforce access control for the chaincode functions.	System-internal mechanism: Automatically triggered by the chaincode.
IDM—verify_role()	Retrieves the role of the transaction submitter.	System internal mechanism: Frequently utilized by the AccessControl and TransactionRecord chaincodes to check if the submitter possesses the necessary authorization.
IDM—create_identity()	Generate an EMR-chain identity for the user and store their encrypted X.509 certificate.	Service Provider (Hospital): Upon the user’s application, the service provider verifies the DID-Chain identity and subsequently registers the identity with the MOHW’s Certificate Authority (CA).
IDM—consent_doc_role()/consent_sup_role()	Modify the roles of medical service providers and hospital administrative units within the IdentityManagement channel to either “Doctor” or “Supervisor”.	Healthcare Certification Authority (HCA): Responsible for validating medical personnel licenses and assigning the role of “Doctor.” Ministry of Health and Welfare (MOHW): Responsible for validating hospital licenses and assigning the role of “Supervisor.”
IDM—revoke_doc_role()/revoke_sup_role()	Enables HCA and MOHW to revoke the roles assigned to medical service providers and hospital administrative units.	HCA (Healthcare Certification Authority): Revokes the role of medical personnel. MOHW (Ministry of Health and Welfare): Revokes the role of administrative staff.
IDM—authenticate_identity()	Perform the digital signature verification procedure to validate that the signature is from the asserted identity and verify that the identity’s role is either “Doctor” or “Patient.”	System internal mechanism: Mainly called by other chaincodes, such as the authorization() function of the ACL chaincode, to authenticate identities involved in the medical record exchange process.
IDM—login()	Verify that the submitted signature corresponds to the caller’s identity and confirm that the identity is enrolled in the EMR-chain.	User (submits the digital signature through the web service provided by the service provider or hospital).

,

Table 4. This table outlines the functions provided by the EMR-Chain ACL (Access Control) chaincode.

Function	Description	Permitted Roles
ACL—beforeTransaction()	As with the IDM chaincode, this mechanism is executed prior to any function invocation to enforce access control and validate the permissions of the caller.	System internal mechanism: Automatically triggered by the chaincode.
ACL— create_patient_instance()	Activated upon a user’s initial enrollment in the EMR-chain, creating a blank instance for that user.	Service Provider (Hospital): Responsible for creating an instance for the patient upon completion of identity registration.
ACL—update_instance()/update_hash()	Function used for uploading new medical record instances or their hash values to the ledger.	Doctor: Access to this function is limited exclusively to users with the “Doctor” role.
ACL—consent_access()/ revoke_access()	Enable patients to modify the Access Control List (ACL) of their medical records at a specific hospital. Patients can grant or revoke access permissions.	Patients: This functionality is restricted to users with the ‘Patient’ role only.
ACL—validate_hash()	Compare the hash value held by the healthcare provider with the hash value recorded on the blockchain.	Data requester (healthcare provider).
ACL—authorization()	Assess whether access authorization should be granted. If approved, generate a JWT and return it along with the data address to the data requester. This process requires verification of the identities and roles of both the data owner and the data requester.	Data requester (healthcare provider) and data owner (patient): The data requester initiates the request, and the patient provides a digital signature to indicate consent.

and

Table 5. This table outlines the functions provided by the EMR-Chain TSR (TransactionRecord) chaincode.

Function	Description	Permitted Roles
TSR—beforeTransaction()	Similarly to ACL smart contracts, it is used to verify whether a user has permission to access specific functionalities.	Internal system mechanism: automatically executed by the chaincode.
TSR—record()	Log the access requests.	Hospital administration unit: Only hospital administrative personnel with the ‘Supervisor’ role are authorized to perform this operation.

delineate this model by providing a detailed permissions matrix that explicitly maps the smart contract functions each defined role is authorized to execute.

4. Implementation and Demonstration

4.1. DID-Chain Network

4.1.1. MainIdentity Create

Figure 8 illustrates creating a MainIdentity, while Figure 9 shows the enrollment page. As previously mentioned, the MainIdentity is endorsed by the government. Therefore, users are required to upload their identification numbers and personal information to the relevant government department. After verifying the user’s identification number and personal details, the government department will use its authority to submit a request to the IdentityManager contract to create a MainIdentity for the user. The IdentityManager contract will create a MainIdentity and use the hashed identification number as the unique identifier for the MainIdentity. Once the transaction is completed, the DID-chain will return the hash value of the transaction, and the government department will return the hashed identification number to the user. Below is a demonstration of the MainIdentity creation process.

4.1.2. Binding Wallet to MainIdentity

Figure 10 illustrates the BindingWallet process. After creating the MainIdentity, it is necessary to bind the user’s digital wallet to the MainIdentity to enable the management of the MainIdentity through the wallet. To do this, users must submit their wallet address along with the unique identifier of their MainIdentity to the relevant government department. The government department will then send a binding request to the IdentityManager contract. The IdentityManager contract will bind the wallet to the user’s MainIdentity and create a new Personal contract for the user, allowing them to interact with the Personal contract. Below is a demonstration of the wallet binding process.

After binding is complete, users can obtain information related to their MainIdentity and the address of their Personal contract through the dashboard page. Figure 11 shows the dashboard page.

4.1.3. App-Chain Private Key Upload

After binding the digital wallet to the MainIdentity, users can interact with the Personal contract via the wallet. Figure 12 illustrates the storage of the app-chain’s private key in the personal contract. Initially, the user joins any desired App-chain. Upon joining, the user is provided with the private key for that application. This private key is essential for signing transactions on the App-chain, indicating endorsement of the transaction. To protect the private key from unauthorized access, the user must encrypt it before uploading it to the Personal contract. When needed, the user can retrieve the encrypted key from the Personal contract, decrypt it, and use it to sign transactions.

4.2. EMR-Chain Network

4.2.1. EMR-Chain Network Architecture

We have constructed the architecture of the EMR-chain network based on the three functions it provides. As illustrated in Figure 13, the network consists of three entities: the Ministry of Health and Welfare (MOHW), the Healthcare Certification Authority (HCA), and the Ordering Service organization. Each entity will have its own Certificate Authority to issue certificates, enabling users to access the respective channels they manage.

The AccessControl channel is represented by c1, the TransactionRecord channel by c2, and the IdentityManagement channel by c3.

We have designed the network so that each hospital is a peer under the MOHW. All hospitals participating in the EMR-chain network will jointly maintain the AccessControl and TransactionRecord channels. The IdentityManagement channel, which involves various identity management functions, will be jointly maintained by MOHW and HCA. As a result, hospitals will maintain ledgers and smart contracts for all three channels, while HCA peers will only maintain the ledger and smart contracts for the IdentityManagement channel.

Figure 13. EMR-chain Network. The detailed color specifications for the nodes and lines are provided in Table 6.

Figure 13. EMR-chain Network. The detailed color specifications for the nodes and lines are provided in Table 6.

Table 6. Detailed Color Table for EMR-chain Network.

Color/Shape	Element Type	Meaning/Label Example
Blue oval/rectangle	Channel	AccessControl channel (c1, cc1)
Red oval/rectangle	Channel	TransactionRecord channel (c2, cc2)
Green oval/rectangle	Channel	IdentityManagement channel (c3, cc3)
Yellow square	Organization	org1
Blue square	Organization	org2(Healthcare Certification Authority)
Green square	Organization	org3
Orange square	Certificate Authority	CA1, CA2, CA3
Light orange rectangle	HCA Peer	p1, p2
Gray square	Ordering Service	O
Small red rectangle	Smart Contract	SC
Small green rectangle	Ledger	L1, L2, L3
Beige rectangle	Application	A1, A2
Gray rectangle (bottom)	Legend block	Used for symbol explanation

Table 6. Detailed Color Table for EMR-chain Network.

Color/Shape	Element Type	Meaning/Label Example
Blue oval/rectangle	Channel	AccessControl channel (c1, cc1)
Red oval/rectangle	Channel	TransactionRecord channel (c2, cc2)
Green oval/rectangle	Channel	IdentityManagement channel (c3, cc3)
Yellow square	Organization	org1
Blue square	Organization	org2(Healthcare Certification Authority)
Green square	Organization	org3
Orange square	Certificate Authority	CA1, CA2, CA3
Light orange rectangle	HCA Peer	p1, p2
Gray square	Ordering Service	O
Small red rectangle	Smart Contract	SC
Small green rectangle	Ledger	L1, L2, L3
Beige rectangle	Application	A1, A2
Gray rectangle (bottom)	Legend block	Used for symbol explanation

4.2.2. EMR-Chain Identity Create and ACL Instance Create

Figure 14 illustrates the process of creating an EMR-chain identity and instance. Users apply for EMR-chain identity registration by submitting their signature, wallet address, and hashed ID to the service provider. The service provider verifies the user’s identity through the digital signature verification function on the DID-chain. Once the verification is successful, indicating that the government endorses the user’s identity, the service provider registers the identity with the MOHW’s Certificate Authority (CA).

Since Hyperledger Fabric is a permissioned blockchain, any transaction submitter must include a signature and an X.509 certificate when submitting a transaction. This demonstrates that the organization’s CA authorizes them to join the blockchain network. In the context of EMR exchange systems, patients may use EMR exchange services at different hospitals. This necessitates allowing patients to log in and access the EMR exchange services across multiple hospitals.

To address this, the service provider will encrypt the private key and X.509 certificate (collectively referred to as X.509 identity) required for transaction submission using a user-defined key. While creating the identity for the patient in the IdentityManagement channel, the service provider will store the encrypted X.509 identity in a designated field of the patient’s identity information within the IdentityManagement channel. This enables patients to retrieve their X.509 identity using their user-defined key when interacting with the IdentityManagement channel, allowing them to commit transactions to the EMR-chain.

After the identity registration, the service provider will create an instance for the patient in the AccessControl channel.

4.2.3. EMR-Chain Login and Logout Process

Figure 15 illustrates the login process for users at various hospitals. Users submit their signature to log in, and the login() function on the IdentityManagement channel verifies if the claimed role of the user is registered and whether the user holds the claimed identity through signature verification. Upon successful verification, the IdentityManagement channel returns the user’s encrypted X.509 Identity, indicating a successful login.

Due to browser compatibility issues, the Hyperledger Fabric SDK does not currently support running in a browser. Users rely on service providers to set up the SDK environment and provide web services for users to submit transactions. In this EMR exchange system, each hospital will also act as a service provider. We trust hospitals as reliable organizations, so users can input the user-defined key and signature to log in at each hospital. After the signature is successfully verified, the encrypted X.509 identity is returned and decrypted using the user-defined key. The decrypted X.509 identity will be temporarily stored with the service provider, allowing users to submit transaction requests through the web services provided.

Upon receiving a request, the service provider will submit the transaction using the user’s X.509 identity. After completing the transaction submission, a logout will be performed. The user will be logged out, and the service provider will ensure the deletion of the user’s X.509 identity. This guarantees that no transactions occur without the user’s consent. The logout process is illustrated in Figure 16.

4.2.4. Consent/Revoke Identity

Figure 17 illustrates the process for healthcare providers and hospital administrative units to obtain the “doctor” or “supervisor” roles. Healthcare providers and hospital administrative units submit credentials that can verify their identities to the respective authorities (HCA or MOHW). The authorities will update the applicants’ roles in the IdentityManagement channel after verifying the valid credentials.

4.2.5. Transaction Submission

Figure 18 illustrates the process of users submitting transactions. This includes operations like patients modifying the ACL (consent/revoke access), healthcare providers uploading patient instances or updating medical record hash values (upload instance/hash), and healthcare providers comparing held medical record hash values with on-chain hash values (validate hash). All types of users submit transaction requests through the web services provided by the service provider. Before submitting transactions, users must log in to ensure the service provider can submit transactions using the user’s X.509 identity.

As mentioned earlier, to enhance the access control of smart contracts, after a transaction is submitted, the AccessControl channel first verifies the submitter’s role through the IdentityManagement channel before executing the transaction. Only after confirming that the submitter’s role meets the access control requirements for the called function will the AccessControl channel execute the submitted transaction.

In this context, update_instance() and validate_hash() serve as representatives of transaction submissions. Figure 19, Figure 20, Figure 21 and Figure 22 show the web page interfaces for healthcare providers performing update_instance() and validate_hash().

4.2.6. Authorization

Figure 23 illustrates how a Data Requester obtains authorization from a Data Owner to access medical records. The Data Requester must submit a signature to verify their identity as a healthcare provider, while the patient also submits their signature. The patient’s signature verifies their identity and signifies consent for the Data Requester to access their electronic medical records.

After submitting the request to the AccessControl channel, the authenticate_identity() function on the IdentityManagement channel first verifies the signatures and roles of both the Data Owner and the Data Requester. It then checks if the Data Requester meets the ACL access rules. Upon successful verification, the smart contract randomly generates a token key pair and uses the private key of the token key pair to create a JWT. The public key of the token key pair is recorded in the ledger to help the Data Controller verify the JWT. The token and the address of the electronic medical records are then returned to the Data Requester, indicating successful authorization.

4.2.7. Authorization Verification and Audit Logging

Figure 24 illustrates the process of verification and audit logging by the Data Controller after receiving an access request. Upon receiving a token from the Data Requester, the Data Controller first uses the Token Validator to verify the token’s validity.

To verify the token, the Token Validator retrieves the public key of the token key pair from the AccessControl channel. It is used to decrypt the signature part of the token. Once decrypted, it compares the decrypted Signature with the hash value of the Header and Payload parts of the JWT to ensure that the token has not been tampered with after issuance.

Next, the Token Validator checks the expiration time, token holder, and token issuer in the Payload part to ensure the token is within its valid period and that the holder and issuer match the Data Requester and the EMR exchange system, respectively. Regardless of whether the token verification is successful, the access request is recorded in the TransactionRecord channel.

If the verification is successful, the Data Controller returns the requested medical records to the Data Requester. In this study, the “FHIR Taiwan Public Test Server” [23] is used as the FHIR server acting as the Data Controller. Any request to access medical data is first sent to the implemented Token Validator, and only requests that successfully pass verification are forwarded to the FHIR Taiwan Public Test Server.

5. Experimental Evaluations

5.1. Environment Setup

The experimental environment consisted of two distinct blockchain networks. The DID-chain was implemented on an Ethereum-based blockchain simulated using Ganache, with its network configuration detailed in

Table 7. System Deployment Environment Specifications.

Parameter	Description
CPU	Intel(R) Core(TM) i5-8400 CPU @ 2.80 GHz
Cores	6
RAM	48 GB
OS	Ubuntu 20.04

. The EMR-chain was built on Hyperledger Fabric, provisioned using Fablo [24], and its network configuration is outlined in

Table 8. Ethereum Network Settings.

Parameter	Description
Number of nodes	1
Number of miners	1
State datebase	LevelDB
Consensus algorithm	PoA
Block time	0.5 s

. The overall system setup is summarized in

Table 9. Hyperledger Fabric Network Settings.

Parameter	Description
Consensue algorithm	Solo
Database	CouchDB
Number of channels and peer nodes	3 channels, 2 nodes in AccessControl channel and TransactionRecord channel, 4 nodes in IdentityManagement channel

. The complete source code is available in the Supplementary Materials.

System performance, specifically throughput, was quantified using Apache JMeter [25]. For the Ethereum-based DID-chain, transaction costs (gas fees) associated with smart contract deployment and function execution were measured using the Truffle suite [26].

5.2. Gas Fee Consumption

Figure 25 analyzes the gas fees required for key contract functions. The deployment of the IdentityManager contract incurred the highest gas cost. This is attributable to the contract’s complexity, which includes extensive data structures and functions required for robust identity management. However, as this contract is deployed only once during the initial setup of the DID-chain, this one-time cost is amortized over the system’s lifecycle.

Among transactional functions, bindWallet() exhibited significant gas consumption. This is because the function triggers the on-chain creation of a new Personal contract for the user, which is a resource-intensive operation. The gas cost of the set_app_private() function was observed to be directly proportional to the size of the input data, as larger encrypted payloads require more on-chain storage.

5.3. Function Throughput

To validate the system’s real-world viability, we benchmarked its performance against Taiwan’s national EMR exchange statistics (2018–2020), as detailed in Table 9. Our evaluation utilized the peak recorded figures to establish a conservative performance baseline.

As illustrated in Figure 26, the throughput of all tested functions increases with the client send rate until reaching a saturation point, beyond which performance stabilizes. Functions performing read-only operations, such as login(), getACL(), and validateHash(), demonstrated superior throughput. The computational overhead of digital signature verification in the login() function was found to have a negligible impact on its overall performance.

Figure 26. Function Throughput. Since the trend lines in this figure are too close to each other, the corresponding data are instead presented in Table 10 for clarity.

Figure 26. Function Throughput. Since the trend lines in this figure are too close to each other, the corresponding data are instead presented in Table 10 for clarity.

Table 10. Detailed Data Table for Function Throughput.

Send Rate (Requests/Sec)	Login	Validate Hash	Update Instance	Validate Hash	Authorization
10	10	9.9	9.9	9.9	10
15	14.6	14.3	14.3	14.6	14.4
20	19.2	19	18.9	19.8	19.4
25	24.1	23.9	23.7	24	24.4

Table 10. Detailed Data Table for Function Throughput.

Send Rate (Requests/Sec)	Login	Validate Hash	Update Instance	Validate Hash	Authorization
10	10	9.9	9.9	9.9	10
15	14.6	14.3	14.3	14.6	14.4
20	19.2	19	18.9	19.8	19.4
25	24.1	23.9	23.7	24	24.4

To validate the system’s real-world viability, we benchmarked its performance against Taiwan’s national EMR exchange statistics (2018–2020), as detailed in

Table 11. EMR System Workload Statistics.

Year	2018	2019	2020
Upload Medical Record Index	211,438,234	190,340,272	179,737,101
Query History Count	2,465,295	1,771,995	1,714,692

. Our evaluation utilized the peak recorded figures to establish a conservative performance baseline.

As illustrated in Figure 26, the throughput of all tested functions increases with the client send rate until reaching a saturation point, beyond which performance stabilizes. Functions performing read-only operations, such as login(), getACL(), and validateHash(), demonstrated superior throughput. The computational overhead of digital signature verification in the login() function was found to have a negligible impact on its overall performance.

Index Upload Performance: The highest recorded national load was 211,438,234 index uploads in 2018, averaging a continuous load of approximately 6.7 transactions per second (TPS). As shown in Figure 26, our system’s updateInstance() function achieved a stable throughput of approximately 40 TPS (at a send rate of 50). This demonstrates a capacity nearly six times greater than the required peak load.

Medical Record Query Performance: The peak national query load was 2,465,295 in 2018, averaging approximately 4.7 queries per minute, or 0.08 TPS. The authorization() function, which orchestrates the query process, sustained a throughput of approximately 49 TPS (at a send rate 50). This performance exceeds the required real-world demand by several orders of magnitude, confirming the system’s capability to handle query loads with substantial headroom.

5.4. Security Analysis

This section analyzes the security posture of the EMR-Chain system against key attack vectors, including Distributed Denial-of-Service (DDoS) attacks, 51% attacks, smart contract vulnerabilities, and time-based manipulation.

5.4.1. Distributed Denial-of-Service (DDoS) Attack

Centralized architectures, such as traditional Electronic Exchange Centers (EECs), present a single point of failure, rendering them highly susceptible to DDoS attacks. The decentralized architecture of the EMR-Chain inherently mitigates this vulnerability. By distributing data processing and transaction validation across numerous participating nodes (hospitals and authorities), the system eliminates the central chokepoint that is the primary target of DDoS attacks. This distribution of workload and responsibility ensures that the failure or compromise of a single node does not disrupt the entire network, significantly enhancing system resilience and robustness.

5.4.2. 51% Attack

The threat of a 51% attack, common in public, proof-of-work blockchains, is fundamentally neutralized by the EMR-Chain’s design as a permissioned network on Hyperledger Fabric. In this model, network participants are not anonymous miners but known, credentialed entities (e.g., Ministry of Health and Welfare (MOHW), Healthcare Certificate Authority (HCA), and hospitals).

Consensus is achieved not through a hash rate majority but through an endorsement policy requiring agreement among these trusted institutions. The IdentityManagement channel, for instance, is jointly governed by the MOHW and HCA, while the collective of participating hospitals maintains the AccessControl and TransactionRecord channels. Consequently, a successful attack would require the collusion or compromise of most of these legally and operationally distinct organizations, a threat model considered practically infeasible.

5.4.3. Smart Contract Vulnerabilities

To fortify the system against smart contract vulnerabilities, a multi-layered security strategy is implemented:

Role-Based Access Control (RBAC): The system enforces strict RBAC via its smart contracts. For example, the update_instance() function can only be executed by an identity with the “doctor” role, while consent_access() is restricted to the “patient” role. This principle of least privilege ensures that the potential impact of a compromised account is confined to its designated permissions.

Mandatory Identity Authentication: No function can be executed without prior identity and role verification. The authenticate_identity() function validates a user’s digital signature against their on-chain public key and confirms their role, preventing unauthorized or anonymous interactions with the smart contracts.

Data Confidentiality Measures: User privacy is protected through de-identifying on-chain data, and client-side encryption of sensitive information (e.g., application private keys) is required before it is stored in the Personal contract. This ensures that even on-chain data remains confidential.

Data Integrity Assurance: The immutability of the blockchain is leveraged to guarantee data integrity. The validate_hash() function allows a data requester to verify the hash of a medical record against its on-chain counterpart, enabling the detection of any unauthorized modifications and preventing undetected data tampering.

Immutable Audit Trail: The dedicated TransactionRecord channel provides an immutable and non-repudiable audit trail of all query requests. Access to write to this log is restricted to “supervisor” roles, ensuring the integrity of the audit data, which can serve as conclusive evidence in the event of a dispute.

5.4.4. Defense Against Token Replay and Time-Based Attacks

The system mitigates time-based attacks, such as token replay, using short-lived JSON Web Tokens (JWTs) with embedded expiration timestamps. When a data exchange is authorized, the authorization function generates a JWT valid for a limited period.

The Token Validator module, which processes incoming requests, is responsible for rigorously validating each token’s signature, issuer, holder, and, critically, its exp (expiration) claim before granting access. This mechanism ensures that even if a token is compromised, its utility is strictly time-bound, rendering it useless after expiration and effectively neutralizing this attack vector. Furthermore, all access attempts, whether successful or failed, are logged, providing an additional layer of security monitoring.

5.5. Detailed Performance Evaluation Table

To assess the practical viability of the EMR-Chain, we benchmarked the throughput of its two core smart contract functions against peak real-world usage data from Taiwan’s national EMR system (2018). The evaluation was performed under a simulated load of 50 requests per second (rps) to test the system’s performance under stress (see

Table 12. Summary of Performance Evaluation Results.

Category	Function Tested	Performance Metric (Throughput)	Comparison with 2018 Taiwan Average Demand
Execution Speed	Medical Record Index Upload updateInstance()	Approx. 40 TPS (at a 50 rps request rate)	Significantly Higher than the average of 6.7 requests per second.
Execution Speed	Medical Record Query authorization()	Approx. 49 TPS (at a 50 rps request rate)	Achieved a throughput of 49 TPS. This figure is substantially higher than Taiwan’s 2018 average demand of approximately 4.7 query requests per minute (or 0.08 TPS).

, Summary of Performance Evaluation Results).

• Index Upload Throughput (updateInstance()): The function responsible for medical record index uploads sustained a stable throughput of approximately 40 transactions per second (TPS). When compared against the peak national demand of 6.7 TPS, our system demonstrates a capacity that exceeds the required benchmark by a factor of nearly six. This confirms its capability to handle high-volume index uploads with significant headroom.
• Query Authorization Throughput (authorization()): The authorization() function, which orchestrates the complex process of medical record queries, achieved an even higher throughput of approximately 49 TPS. This performance was benchmarked against the national peak query load of 4.7 requests per minute (≈0.08 TPS). The system’s query-handling capacity is therefore several orders of magnitude greater than the observed real-world requirement. This substantial performance margin ensures high responsiveness and low latency, even during periods of high concurrency.

In conclusion, the empirical results validate that the EMR-Chain’s architecture not only meets but substantially exceeds the performance demands of a national-scale electronic medical record exchange system. This confirms the system’s scalability and readiness for practical, real-world deployment. However, in practical applications, there have not yet been cases of large hospitals exchanging data with multiple medical centers. Therefore, we look forward to further testing the system’s performance and stability in a real-world environment in future research.

5.6. Practical Significance and Impact of Numerical Results

The numerical results of the EMR-Chain, a decentralized electronic medical record exchange system proposed in the manuscript, are primarily demonstrated in terms of Throughput and Gas Fee Consumption.

1. Throughput:

Practical Significance: Throughput is a key metric for measuring the number of transactions or requests a system can process per unit of time. The manuscript benchmarks its system’s performance against real-world statistics from Taiwan’s national electronic medical record exchange (2018–2020), using the highest recorded data from 2018 as a conservative performance baseline.

Medical Record Index Upload (updateInstance()) Performance: The highest national record in 2018 was approximately 6.7 transactions per second (TPS). The EMR-Chain’s updateInstance() function achieved a stable throughput of about 40 TPS.

Medical Record Query (authorization()) Performance: The highest national query volume in 2018 was approximately 0.08 TPS. The EMR-Chain’s authorization() function achieved a throughput of about 49 TPS.

Impact on Users and Industry Stakeholders:

Significantly Exceeds Current Demand: The system’s throughput for uploads is nearly six times the highest national demand (40 TPS vs. 6.7 TPS), and its query throughput surpasses it by several orders of magnitude (49 TPS vs. 0.08 TPS). This indicates that the system’s performance far exceeds the practical needs of the current national electronic medical record exchange, demonstrating extremely high processing capacity and stability.

High Responsiveness and Low Latency: The excellent throughput ensures that the system maintains high responsiveness and low latency, even under high concurrency. This means doctors can access patient records faster, and patients can grant authorization and query records more quickly, significantly improving the efficiency of medical services and the user experience.

Prepared for Future Expansion: The system’s robust performance proves its capability to handle much larger future workloads, providing a solid technical foundation for the scalability and practical deployment of national-level EMR exchange systems in Taiwan and other regions. This is a significant promise for industry stakeholders looking to introduce blockchain technology to enhance the reliability and efficiency of medical information systems.

Enhanced System Resilience: High throughput also indirectly enhances the system’s resistance to Distributed Denial of Service (DDoS) attacks, as the decentralized architecture distributes data processing and transaction validation across multiple nodes, eliminating single points of failure.

2. Gas Fee Consumption:

Practical Significance: The gas fee is a metric for measuring the transaction cost required to deploy smart contracts and execute functions on the Ethereum-based decentralized identity blockchain (DID-Chain).

The deployment cost of the IdentityManager contract is the highest, but this is a one-time fee that is amortized over the system’s lifecycle.

The bindWallet() function has significant gas consumption because it triggers the on-chain creation of a new Personal contract for the user, which is a resource-intensive operation.

The gas cost of the set_app_private() function is proportional to the size of the input data, as larger encrypted data requires more on-chain storage space.

Impact on Users and Industry Stakeholders:

Cost–Benefit Analysis: Although certain operations (like contract deployment and wallet binding) incur higher initial or specific costs, these costs are acceptable when weighed against the core values the system provides, such as decentralization, high security, and privacy protection. The one-time deployment cost is negligible over time, while the costs of specific resource-intensive operations reflect the inherent overhead of on-chain operations.

Encourages Efficient Design: The transparency of gas fees incentivizes developers to consider efficiency when designing smart contracts, minimizing unnecessary on-chain storage and computation to reduce user costs.

Long-Term Stability: Compared to centralized systems that may face single points of failure and data breach risks, blockchain, despite its inherent transaction costs, offers greater value and long-term stability through its immutability and transparent audit trails, which are crucial for highly sensitive information like medical data.

6. Conclusions and Future Work

6.1. Conclusions

The decentralized electronic medical record (EMR) exchange system we have put together in this study offers a solid answer to some challenging healthcare problems. With a decentralized setup, we sidestepped those annoying performance bottlenecks that often pop up. At the same time, we seriously beefed up data privacy and who gets to see what. How did we do it? It is all thanks to de-identification tricks and building a special identity management system for secure EMR sharing.

The system is designed to enhance patient autonomy, giving individuals the liberty and agency to make informed decisions about their own medical treatment. They get precise control over their data, which means their privacy is locked down. Plus, using a standardized EMR exchange format makes it easier for different healthcare providers to share information smoothly. Moreover, here is a crucial point: this system is designed to play by the rules, fully complying with all the current Taiwanese regulations governing EMR exchange.

Looking ahead, our vision for this system is to hook it up with global decentralized identity (DID) management frameworks. This would open up a new world of possibilities, letting it work in other areas like financial services, managing physiological data, or even keeping track of learning histories. Imagine users using their DIDs across many different services—that would expand what this system can do and how much impact it can have across various fields.

6.2. Future Work

For our next steps, we will focus on making the EMR-chain system even better by adding more fine-grained authorization controls. It is mostly about hospital-level permissions, but we want to go way beyond that. The goal is to give patients more precise control over their medical data and improve privacy protection. The following provides an overview of the improvements we are planning and the hurdles we expect to face.

Proposed Enhancements for Fine-Grained Authorization:

1. Department-Specific Access Control: We want patients to be able to set different access permissions for various medical departments within the same hospital. So, for example, a cardiologist would only see heart-related records, while an orthopedist would stick to musculoskeletal data. This approach boosts patient autonomy by ensuring that only the relevant specialists within a hospital can access specific data.

2. Resource Type-Based Authorization: This idea is about getting super granular access based on specific FHIR resource types, like DiagnosticReport, MedicationRequest, or Observation. Hospitals could decide which types of resources are available for exchange. Then patients could permit specific categories of their medical data—say, lab results or surgical notes—while keeping others private. This offers a much more nuanced way to share data.

Challenges in Implementation:

1. Lack of Standardization in Department Classification: This presents a practical challenge: there is no standard for classifying medical departments across different healthcare institutions. If one hospital calls something “Cardiology” and another has a slightly different definition or scope, it will make enforcing consistent access policies a significant challenge. This lack of standardization could easily confuse patients when setting permissions and lead to system errors when interpreting access rules across different organizational structures.

2. Data Overlap in FHIR: Applying authorization at the FHIR resource level becomes complex because data often overlaps between different resources. For instance, a diagnosis in a Condition resource might also be hinted at in a MedicationRequest or ServiceRequest. This overlap makes it extremely difficult to separate data segments cleanly. You have not stopped the information from leaking if you deny access to a MedicationRequest, but the underlying diagnosis is still visible through the Condition resource. This means we will need seriously smart policy enforcement to manage these data dependencies and prevent accidental disclosures.

Overcoming these complexities will take a concerted effort, with industry-wide standardization being key, along with developing sophisticated models for data dependencies. However, getting past these challenges is vital to unlock the full potential of fine-grained access control. Ultimately, it is all about maximizing patient privacy while ensuring that necessary medical information can be exchanged smoothly and securely.