A Blockchain-Based Model for Managing Infectious Disease Data

Abstract

Infectious disease outbreaks continue to pose a significant threat to global health, underscoring the importance of timely detection and reliable reporting for effective interventions. Traditional reporting systems often rely on hierarchical data flows, which introduce delays, inconsistencies, and vulnerabilities, as highlighted during the COVID-19 pandemic. Blockchain, a disruptive technology, offers a promising solution. This study proposes a blockchain-based infectious disease reporting system built on Hyperledger Fabric that supports multi-level reporting and governance across national health systems. The architecture preserves hierarchical structures while enabling real-time reporting across authorized health stakeholders. It separates public test results from sensitive patient information, with private data secured via Private Data Collections and anchored using cryptographic hashes. Smart contracts enforce role-based access and validation, ensuring data integrity and controlled oversight. The system prototype was deployed within Docker containers and evaluated using illustrative COVID-19 case data. Network performance was benchmarked using Hyperledger Caliper, measuring throughput, latency, and resource utilization. The results demonstrate proper system functioning and stable transaction processing under the tested experimental conditions, supporting the feasibility of the proposed architecture for privacy-preserving multi-level infectious disease reporting systems.

1. Introduction

Infectious diseases have recurrently shaped human history, causing profound public health crises, social disruption, and economic instability across the globe. From historic outbreaks such as the 1918 influenza pandemic to more recent threats including SARS, H1N1 [1], MERS [2], Ebola [3], and, most notably, the COVID-19 pandemic [4], these events underscore the persistent and evolving challenges posed by emerging and re-emerging pathogens. The rapid spread of COVID-19, accelerated by unprecedented global mobility and urbanization, exemplified how swiftly a novel pathogen can traverse continents, overwhelm healthcare systems, and disrupt societies within weeks.

Early and accurate testing is the cornerstone of infectious disease outbreak control [5]. It enables timely clinical intervention, effective contact tracing, and the rapid implementation of containment measures [6]. Beyond immediate patient care, testing generates crucial data that support real-time surveillance and an effective public health response [7]. However, traditional reporting systems, which rely on hierarchical data flows from local facilities to regional authorities and onward to national agencies, often hinder these objectives [8,9]. The tiered structure introduces delays, omissions, and inconsistencies that prevent rapid detection, timely reporting, and coordinated response, as starkly revealed during the COVID-19 pandemic. Blockchain, an emerging disruptive technology, offers a transformative solution to these challenges [10]. Its decentralized architecture, tamper-resistant ledger, and cryptographic time stamping ensure that any added record becomes immutable and transparently verifiable [11]. Blockchain enables diagnostic centers, hospitals, and public health authorities to log and access test results in real time, eliminating the delays and inconsistencies inherent in hierarchical data flows. Its traceability also enhances accountability and trust [12], positioning blockchain as a powerful tool for secure data storage, root source tracing, and strengthened responsiveness of infectious disease surveillance systems.

Recent research has applied blockchain to infectious disease data management, but existing approaches vary widely in goals, data architectures, and deployment models. Yakubu et al. [13] proposed PatCen, a patient-centric system built on the Ethereum blockchain that enables fine-grained, time-bound access to infectious disease test records. Their model strengthens patient data sovereignty but does not address the hierarchical, multi-level reporting workflows used in national surveillance systems. Hasan et al. [14] developed Ethereum smart contracts and IPFS storage to issue digital medical passports and immunity certificates. While effective for verifiable credential management, this work targets personal identity verification rather than structured disease reporting between healthcare institutions and government agencies.

Other studies examine traceability and reporting workflows, but with limitations relative to practical surveillance systems. Capece and Passiatore [15] outlined a conceptual architecture for securing COVID-19 notification flows and supply chain transactions; however, their work remains high-level and does not provide a platform-specific implementation, privacy-preserving storage design, or validation across hierarchical health institutions. Zhu and colleagues [16] designed a PBFT-based traceability model with role-based access control evaluated through simulation. Although their architecture reflects multi-party reporting, their blockchain implementation represents these hierarchical workflows within a generic PBFT consensus simulation, capturing role-based interactions and information-flow logic. Lee et al. [17] implemented a PoA-based case-tracking system that stores IPS indexes on-chain and IPS records off-chain. However, the system is designed for global case exchange and international interoperability rather than national-level, multi-tier supervisory reporting. Khan et al. [18] used Ethereum smart contracts and oracles for outbreak tracking, aggregating statistical information directly on-chain. This design is unsuitable for managing sensitive patient-level data and is incompatible with privacy and governance requirements in regulated health reporting environments.

Although previous studies have highlighted the potential of blockchain for infectious disease data management, most have focused on patient-centric access and public blockchain platforms that face significant scalability, privacy, and governance challenges in healthcare. To address these gaps, this study introduces a permissioned blockchain–based infectious-disease reporting system designed for direct hierarchical reporting workflows in national health systems. The key architectural contributions of the proposed system are as follows:

• A dual-layer data model that separates public test results from sensitive patient information, leveraging Private Data Collections (PDCs) to preserve data privacy while anchoring integrity through on-chain cryptographic hash commitments.
• Multi-level, role-based governance embedded in smart contracts, enabling institution-specific oversight and controlled interactions among network stakeholders.
• Disease-specific channels that isolate data by pathogen and enforce fine-grained access control policies.
• A fully implemented prototype using Hyperledger Fabric (version 3.1), Docker (version 26.1.3), CouchDB (version 3.3.3), and Go (version 1.22.0), validated with illustrative COVID-19 case data, demonstrating improved timeliness, traceability, and data integrity in multi-tier reporting workflows. Performance benchmarking further confirms the system’s scalability and efficiency under varying transaction workloads.

The remainder of this paper is organized as follows. Section 2 presents background on blockchain technology and the Hyperledger Fabric framework. Section 3 describes the proposed blockchain-based solution. Section 4 introduces a COVID-19 case study, including the system architecture, implementation, experimental results, and performance evaluation. Section 5 discusses practical deployment challenges, limitations, and future research directions. Finally, Section 6 concludes the paper.

2. Background

2.1. Blockchain Technology

Blockchain is a decentralized, cryptography-enabled distributed ledger technology that provides a secure, transparent, and tamper-resistant framework for recording and sharing data among mutually untrusted network participants [19]. Each block in the blockchain contains a timestamp, transaction data, and a cryptographic link to the previous block, forming an immutable chain that ensures data integrity and verifiability. Transactions are validated through consensus mechanisms such as Proof of Work (PoW) [20], Proof of Stake (PoS) [20], or Practical Byzantine Fault Tolerance (PBFT) [21], depending on the blockchain type (public, private, or consortium), thereby eliminating reliance on centralized authorities and intermediaries. While blockchain gained initial prominence through cryptocurrencies like Bitcoin [22] and Ethereum [23], it has increasingly attracted attention in healthcare and public health applications [6,24]. By leveraging decentralization, immutability, and data reliability, blockchain provides a tamper-proof ledger for recording epidemiological data across distributed nodes, ensuring accurate traceability and strengthening public health response.

2.2. Hyperledger Fabric

Hyperledger Fabric [25] is an open-source, enterprise-grade, permissioned blockchain framework that restricts participation and data access to authorized entities, ensuring confidentiality and trust. Its modular architecture allows customization of consensus protocols, membership services, and transaction flows, supporting scalability and flexibility. Transactions follow an execute-order-validate model with cryptographic integrity ensured by the SHA-256 algorithm. Business logic is implemented through chaincode, smart contracts written in Go, Java, or JavaScript, allowing integration with existing systems. Key components include certificate authorities (CAs) and membership service providers (MSPs) for identity management, peer nodes hosting ledgers and smart contracts, channels for private communication, an ordering service for ledger consistency, and a dual-layer ledger combining an immutable blockchain with an updatable world state for efficient queries. Taken as a whole, these elements enable secure, transparent, and tamper-evident collaboration within a consortium.

This study selected Hyperledger Fabric for its modular, permissioned design, which provides fine-grained access control, strong identity verification, and channel-based private sub-networks for secure communication. Its chaincode supports custom logic for processing and validating health records, while preconfigured Docker images simplify deployment and enhance scalability, making Fabric a robust platform for building a secure and efficient infectious disease reporting system.

3. Proposed Blockchain-Based Solution

3.1. System Description

Traditional infectious disease reporting systems typically follow a hierarchical communication structure, where case data flow upward from local hospitals, clinics, and laboratories to regional public health authorities and ultimately to national public health agencies [8,16]. Although this structure allows centralized oversight, it introduces critical reporting delays and inefficiencies, especially during rapidly evolving outbreaks [7]. These delays can impede timely interventions, while the fragmented and often insecure communication channels, such as phone calls, emails, or siloed platforms, increase the risks of data loss, inconsistencies, or cyberattacks. Furthermore, reliance on centralized servers [11] creates single points of failure and exposes systems to potential data tampering, thereby undermining information integrity and public trust.

To overcome these challenges, the proposed solution integrates a permissioned blockchain into the existing infectious disease reporting structure, creating a hierarchical yet interconnected network of trusted entities (Figure 1). The system preserves the hierarchical structure required for oversight while enabling direct, real-time, and tamper-resistant reporting among authorized participants. Rather than replacing institutional roles, the system redefines their interactions through a decentralized architecture governed by cryptographic validation and role-based access control policies. The consensus mechanism ensures that recorded data remain immutable, verifiable, and instantly accessible to authorized nodes, thereby enhancing the timeliness, accuracy, and reliability of disease surveillance and response.

3.1.1. On-Chain Participating Entities

The proposed blockchain-based reporting system consists of three principal stakeholders operating under clearly defined roles:

• Infectious Disease Test Centers (IDTCs): IDTCs include hospital laboratories, certified diagnostic centers, and authorized research institutions that conduct tests for notifiable infectious diseases. As the primary data originators, they are responsible for the clinical confirmation of diagnostic results and the initial entry of epidemiological data into the distributed ledger.
• Ministry of Health (MoH): The MoH, typically represented by a national public health agency, acts as the consortium administrator and governance authority of the blockchain network. It defines network policies, approves eligible IDTCs, and integrates them into the blockchain as active participants. The MoH may also revoke participation and remove previously approved IDTCs when necessary. Similarly, it grants Regional Health Directorates (RHDs) access to the network and may withdraw that access if required. In addition, the MoH oversees regulatory compliance, monitors the reporting process, and ensures the system’s integrity and proper functioning.
• Regional Health Directorates (RHDs): RHDs are regional public health authorities operating under the supervision of the MoH. They participate in the network to monitor infectious disease reporting and support regional epidemiological surveillance. This participation enables them to analyze infection trends and contribute to evidence-based public health decision-making.

Together, these entities operate within a unified, tamper-resistant infrastructure that enhances trust and operational efficiency, transforming infectious disease reporting into a faster, more reliable, and secure process.

3.1.2. System Workflow

As shown in Figure 2, data collection in the proposed system begins at the IDTC level, where diagnostic tests for notifiable infectious diseases are conducted [7]. When a diagnostic outcome is positive, the IDTC generates a patient record containing the test result and associated patient information and submits it as a transaction proposal through the client application to authorized organizations within the network. Once node consensus is achieved and the data are validated, the patient record is committed to the infectious disease blockchain ledger. The patient records support traceability, epidemiological analyses, early warning generation, and information queries by authorized participants. These records can subsequently be retrieved and viewed through the client application interface. As patient records are chronologically recorded on the blockchain ledger, they provide tamper resistance and traceability.

3.2. Data Structure

The proposed system employs a dual-layer data structure that separates public and private components of each patient record (Figure 3) to achieve an optimal balance between privacy, performance, and security. This architecture minimizes on-chain storage overhead, ensures compliance with data protection regulations, and supports secure data provenance and controlled access [11].

The public component (test result) is stored directly on the blockchain ledger and accessible to all authorized nodes (IDTCs, MoH, and RHDs) for surveillance and coordination. It consists of non-identifiable epidemiological data:

• PatientID: A pseudonymous identifier derived using privacy-preserving techniques (e.g., salted cryptographic hashing) to prevent linkage to real-world identities.
• TestResult: The diagnostic outcome, represented as a string (e.g., “Positive”).
• TestType: The specific infectious disease test performed.
• TestDate: The timestamp of when the test was administered.
• TestCenter: The unique identifier of the reporting facility.

The private component contains sensitive Personally Identifiable Information (PII) necessary for contact tracing and clinical follow-up, including National Identity Number (NIN), Name, DateOfBirth, Gender, PhoneNumber, and Address. To ensure confidentiality, these attributes are stored off-chain in Private Data Collections (PDCs) [26].

Within this framework, only authorized peers from the IDTCs and the MoH maintain the private state. Conversely, RHDs interact exclusively with the public state. To preserve data integrity and provenance, a cryptographic SHA-256 hash of the private data is committed to the public ledger. This creates a verifiable, immutable linkage between the two layers, allowing any participant to detect tampering without having access to the sensitive underlying content.

3.3. Network Management and Access Control

The MoH serves as the central administrative authority and consortium leader, overseeing the configuration and governance of the blockchain network. To enable granular, disease-specific oversight, dedicated channels are established for each infectious disease, isolating data and ensuring sensitive information is shared only with relevant stakeholders.

Each participating organization operates a Certificate Authority (CA) and a Membership Service Provider (MSP), cryptographically linking peers, orderers, and users to their institutional domain. Administrators enrolled through their CA manage network identities. An IDTC administrator registers healthcare professionals within their facility, whereas the MoH administrator oversees organizational participation through consortium policies and channel configurations. Once registered, users receive X.509 digital certificates and private keys, enabling secure, identity-based authentication and interaction within the network.

Access control is enforced through endorsement policies and Access Control Lists (ACLs), which define role-based permissions of network participants. The specific authorization scopes for each role are summarized in

Table 1. Participant’s permissions.

Role	Access Level	Permissions
IDTC users	Read/Write/Update	Create and update epidemiological records; view full records (public and private).
MoH users	Read/Audit/Governance	View full records (public and private); verify data integrity; manage consortium policies and channel configurations without modifying patient records.
RHD users	Read-only	Access non-identifiable epidemiological data for regional surveillance, trend analysis, and public health decision-making.

.

All transactions are digitally signed with users’ private keys and verified against the MSP before commitment, ensuring non-repudiation and accountability. The respective CAs handle certificate issuance, renewal, and revocation to ensure a secure and trustworthy network environment.

3.4. Chaincode Design

Chaincode implements the programmable logic governing the lifecycle of infectious disease test records within the proposed permissioned blockchain network. Developed in Go and deployed on endorsing peers, it enforces identity validation, role-based authorization, and controlled interaction between the public ledger state and PDCs. All state transitions are executed subject to endorsement policies and cryptographic verification. The core chaincode functions are summarized below:

• CreateRecord(): Creates a new infectious disease test record. Public attributes are written to the world state and recorded on the ledger upon commitment, while sensitive patient information is stored in a designated Private Data Collection. A cryptographic hash of the private data is included in the transaction’s write set and thereby anchored to the public ledger, ensuring integrity verification.
• ReadRecord(): Retrieves public test data associated with a given PatientID.
• ReadPatientPersonalData(): Retrieves private patient information from the authorized PDC, subject to collection access policy.
• UpdateTestResult(): Updates the diagnostic result of an existing record while preserving transaction traceability and recording the identity of the test center performing the update, along with the update timestamp.
• UpdatePhoneNumber()/UpdateAddress(): Modify specific private attributes within the PDC, ensuring access control and audit logging.
• DeleteRecord(): Removes private personal data associated with a given patient ID after authorization validation, supporting regulatory compliance and lifecycle control.
• GetRecordHistory(): Returns the immutable transaction history associated with a given patient ID, supporting auditing and provenance verification.

Among the implemented functions, Algorithm 1 and Algorithm 2 describe the procedures for creating a test record and updating a test result, respectively.

Algorithm 1. CreateRecord()—Chaincode Function

Algorithm 2. UpdateTestResult—Chaincode Function

4. A Case Study of COVID-19

This case study illustrates the proposed blockchain system’s application for securely recording and exchanging COVID-19 test results and patient information within a simulated healthcare network.

4.1. System Architecture in Hyperledger Fabric

Figure 4 illustrates the overall system architecture for managing COVID-19 test records using Hyperledger Fabric. The architecture involves a single communication channel, covid19-test-channel, one ordering service, and three participating organizations: a COVID-19 test center, the Ministry of Health, and a regional health directorate. These organizations form a consortium within the network and are all associated with the domain name covid19-records.com, which is used for MSP configuration and digital certificate generation.

Each organization operates two peer nodes, a CA, and an MSP. The ordering service is implemented using a single RAFT-based orderer node, which ensures consensus and transaction ordering across the network. Every peer node maintains a full copy of the distributed ledger and hosts an instance of the deployed chaincode. CouchDB serves as the state database, enabling efficient storage and retrieval of structured data. This design ensures data consistency, fault tolerance, and secure access across all stakeholders.

4.2. System Implementation

We created the blockchain network using the Hyperledger Fabric framework version 3.1, running on Docker containers. We first generated the cryptographic material (X.509 certificates) for all entities, the Ministry of Health, the COVID-19 test center, the regional health directorate, and the ordering service, using Fabric CA (version 1.5.15). Then, using the configtx.yaml file as input to the Fabric configtxgen tool, we created the genesis block for “covid19-test-channel”, which initializes the ordering service and stores the network configuration information, including channel policies, and membership details. The genesis block serves as the foundation for the channel and enables its initialization. We launched the network utilizing Docker Compose with CouchDB as the state database. The network contains 17 containers, including six for peer organizations, six for CouchDB (one per peer), four for certificate authorities, and one for the ordering service. Figure 5 displays Docker containers of the proposed COVID-19 records network with container IDs, image names, container names, and status. Once the network was up, we joined the Ordering Service Node (OSN), a single RAFT orderer node, to the “covid19-test-channel”, allowing it to register its presence, adopt the defined configuration, and activate the channel. The next step involved joining all peer nodes from participating organizations into the channel, ensuring that only authorized entities could participate in network operations. Finally, anchor peers were assigned to each peer organization to facilitate inter-organizational communication. This enabled efficient data synchronization through gossip-based discovery.

The network was implemented in a virtualized environment on a Windows 11 Pro 64-bit host system running on an ASUS Computer (Shanghai) Co., Ltd., Shanghai, China, equipped with an AMD Ryzen 9 7940HS processor (16 CPUs, 4.0 GHz) and 32 GB of RAM. A virtual machine was created using VirtualBox, running Ubuntu 20.04 LTS with 4 allocated CPUs and 8 GB of RAM. The network deployment took place entirely within this Ubuntu virtual machine. The development stack included Docker version 26.1.3, Docker Compose version 1.25.0, CouchDB version 3.3.3, and Go version 1.22.0 for smart contract implementation and execution.

4.3. Results

This section presents the results of implementing a Hyperledger Fabric-based network to manage COVID-19 test records. After network initialization, the chaincode was deployed to manage transaction execution, and users were registered and enrolled via the Fabric CA client and CLI, enabling authenticated, role-based interactions with the system.

The operational workflow is initiated when an authorized user from a COVID-19 test center invokes the CreateRecord() function within the chaincode (Figure 6). While public attributes are passed as standard function arguments, sensitive personal information, encapsulated in the PATIENT_PERSONAL_DATA variable, is passed via the transient data map to ensure confidentiality. Upon successful endorsement and validation, the transaction is committed to the distributed ledger, permanently recording the new patient record. Figure 5, Figure 6, Figure 7 and Figure 8 illustrate how the network records and manages COVID-19 test results and related patient information. Detailed examples of public data records, private data entries, and corresponding cryptographic hash representations are provided in the Supplementary Materials (Figures S1–S3) to illustrate the internal data structures stored on the distributed ledger and private data collections.

Figure 7 presents the CouchDB dashboard interface for the peer0 nodes of all participating organizations. Each peer maintains an instance of the ledger database, enabling decentralized data storage and transaction validation. The covid19-test-channel_private database (blue rectangles) represents the world state, which contains public data entries that each peer node replicates to ensure consistent visibility of test result data among all consortium members. In contrast, the database covid19-test-channel_private$$hpersonal$data$collection (purple rectangles) stores cryptographic hashes of private data, which are visible to all organizations in the network for verification purposes. The database covid19-test-channel_private$$ppersonal$data$collection (green rectangles), on the other hand, contains sensitive personal information accessible only to authorized organizations, specifically the MoH and designated COVID-19 test centers.

Figure 8 demonstrates the enforcement of the system’s access control policies. While a registered and enrolled user from the RHD organization is authorized to query public test results, any attempt by the same user to access patient information stored in the private data collection (personalDataCollection) is denied. This result validates that the collection-level access policies defined in the chaincode effectively safeguard sensitive information against unauthorized retrieval.

Figure 9 illustrates the transaction history of a patient record, highlighting the system’s capacity for comprehensive traceability via the blockchain’s immutable ledger. The history query retrieves the chronological sequence of state transitions, identifying the specific client identities responsible for each modification. In this instance, a test center client (TC_client) initially created the record with a positive status, which was subsequently updated by TC_client_2 to reflect a negative outcome following a follow-up test.

For demonstration purposes, the presented database views correspond to the peer0 node of each participating organization. Since peer0 and peer1 within the same organization maintain synchronized ledger states, the stored data remains consistent across organizational replicas.

4.4. Performance Evaluation

To evaluate the performance of the proposed Fabric-based infectious-disease reporting system, we utilized Hyperledger Caliper [27]. Caliper is a blockchain benchmarking tool that provides a consistent abstraction layer, allowing seamless integration with multiple existing blockchain platforms. It enables systematic assessment of blockchain network performance by executing predefined or custom workloads and generating quantitative reports on key performance metrics. These metrics include success rate, transaction throughput, transaction latency, and resource utilization.

Building on this benchmarking framework, we designed three experiments by varying key workload parameters: the transaction submission rate, the total number of transactions, and the number of transaction submitting clients. Performance was evaluated for both CreateRecord (write) and ReadRecord (read) transactions using a network topology consisting of three organizations and six peer nodes, reflecting the intended deployment scenario. The resulting measurements were recorded and analyzed primarily in terms of throughput and latency.

4.4.1. Experiment 1: Transaction Rate

This experiment evaluates how different transaction submission rates affect blockchain performance. We vary the transaction rate across three levels, 75, 150, and 250 tps, while keeping the total number of transactions fixed at 1000 and the number of transaction-submitting clients constant at five.

• CreateRecord:

  Table 2. Performance metrics for CreateRecord transactions in experiment 1.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	75.0	0.11
  150	1000	5	149.9	0.11
  250	1000	5	178.5	0.42

  shows that the network handles 75 and 150 tps efficiently, with throughput matching the submitted rate and latency remaining stable at 0.11 s. The 150 tps configuration represents the optimal operating range. At 250 tps, throughput no longer scales proportionally and latency rises sharply to 0.42 s, indicating that the network is approaching saturation.
• ReadRecord:

  Table 3. Performance metrics for ReadRecord transactions in experiment 1.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	52.1	0.012
  150	1000	5	53.8	0.012
  250	1000	5	54.2	0.012

  shows that varying the transaction rate has a minimal effect on ReadRecord operations. Throughput remains nearly constant (≈52–54 tps), and latency stays extremely low at around 0.012 s across all rates. These results indicate that read-only queries impose very little overhead, suggesting that the system did not reach its capacity limit within the tested range.

4.4.2. Experiment 2: Number of Transactions

This experiment examines how increasing the total number of transactions affects blockchain performance, particularly throughput and latency. We evaluate three workload sizes, 1000, 5000, and 15,000 transactions, while keeping the number of transaction-submitting clients fixed at five. The transaction submission rate is held constant at 75 tps.

• CreateRecord:

  Table 4. Performance metrics for CreateRecord transactions in experiment 2.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	75.0	0.11
  75	5000	5	75.0	0.11
  75	15,000	5	75.1	0.13

  shows that throughput remains constant at approximately 75 tps across all workloads, matching the transaction submission rate. Latency remains stable at 0.11 s for 1000 and 5000 transactions and increases slightly to 0.13 s at 15,000 transactions. This marginal increase of 0.02 s indicates a minor overhead at higher transaction volumes, while overall write performance remains stable.
• ReadRecord: As seen in

  Table 5. Performance metrics for ReadRecord transactions in experiment 2.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	51.1	0.012
  75	5000	5	51.1	0.012
  75	15,000	5	51.1	0.012

  , increasing the number of transactions has no measurable impact on ReadRecord performance. Throughput remains constant at 51.1 tps, and latency stays unchanged at 0.012 s across all workloads, confirming that read operations scale efficiently with minimal overhead.

4.4.3. Experiment 3: Number of Transaction-Submitting Clients

This experiment evaluates how increasing the number of transaction-submitting clients, representing COVID-19 test centers (IDTCs), affects system performance. We test three configurations: 5, 25, and 50 concurrent clients. For each configuration, 1000 transactions are submitted at a fixed rate of 75 tps.

• CreateRecord:

  Table 6. Performance metrics for CreateRecord transactions in experiment 3.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	75.0	0.11
  75	1000	25	75.5	0.13
  75	1000	50	75.3	0.82

  shows that increasing the number of transaction-submitting clients from 5 to 25 and 50 has little impact on throughput, which remains close to the fixed rate of 75 tps. In contrast, latency increases from 0.11 s at 5 clients to 0.13 s at 25 clients and rises sharply to 0.82 s at 50 clients, indicating increased contention and queuing under high concurrency despite sustained throughput.
• ReadRecord: As seen in

  Table 7. Performance metrics for ReadRecord transactions in experiment 3.

  Transaction Rate (tps)	Number of Transactions	Number of Clients	Throughput (tps)	Latency (s)
  75	1000	5	51.1	0.012
  75	1000	25	51.9	0.013
  75	1000	50	52.1	0.018

  , ReadRecord transactions exhibit stable performance across all client configurations. Throughput increases marginally from 51.1 to 52.1 tps, while latency remains low, rising only slightly from 0.012 s to 0.018 s as the number of clients increases to 50. These results indicate that read-only operations scale well with increasing concurrency and impose minimal additional overhead.

4.4.4. Resource Utilization Analysis

In addition to throughput and latency, resource utilization was monitored during benchmarking to assess the network’s computational overhead. CPU usage and memory consumption, both maximum and average, were measured across all peer and orderer nodes, as shown in

Table 8. Resource utilization analysis of the proposed system.

Name	CPU (Max)	CPU (Avg)	Memory (Max)	Memory (Avg)
peer0.testcenter.covid19-records.com	29.01%	23.2%	620 MB	465 MB
peer1.testcenter.covid19-records.com	27.22%	21.8%	580 MB	435 MB
peer0.ministryofhealth.covid19-records.com	30.13%	24.1%	660 MB	495 MB
peer1.ministryofhealth.covid19-records.com	25.44%	20.4%	560 MB	420 MB
peer0.regionalhealthdirectorate.covid19-records.com	20.26%	16.2%	520 MB	390 MB
peer1.regionalhealthdirectorate.covid19-records.com	15.77%	12.6%	500 MB	375 MB
orderer.covid19-records.com	10.31%	6.7%	280 MB	210 MB

.

The average CPU utilization remains below 25% for all peer nodes and below 7% for the orderer, while peak CPU usage does not exceed 31%. Memory consumption is similarly stable, with average usage ranging from 375 MB to 495 MB for peers and approximately 210 MB for the orderer. These results confirm that the system operates efficiently under the evaluated workload and can support higher transaction loads without significant computational overhead.

5. Discussion

The results indicate that the proposed Hyperledger Fabric architecture effectively supports hierarchical infectious-disease reporting by enforcing secure, role-based data submission at the IDTC level. The system maintains a clear separation between public test results and private patient information. Public test results are consistently replicated across all peers, ensuring shared situational awareness, while private patient attributes remain restricted to MoH and authorized IDTCs through PDC policies. The denial of private-data queries from an RHD user confirms correct enforcement of collection-level access controls, and the availability of cryptographic hashes to all peers enables integrity verification without exposing confidential data. Additionally, the immutable transaction history demonstrates robust traceability of record updates, supporting auditability and accountability. Experimental evaluation further shows that throughput scales with the transaction submission rate up to an optimal range, beyond which latency increases, and throughput saturates. Similarly, increasing the number of transaction-submitting clients preserves throughput while increasing latency due to contention. Read operations remain largely unaffected across all workloads, reflecting their low computational overhead. Overall, these findings demonstrate that the system satisfies key requirements for secure, privacy-preserving, verifiable, and efficient hierarchical disease reporting. However, higher load levels necessitate careful configuration to ensure scalability.

5.1. Practical Deployment Challenges

A primary challenge for real-world deployment is achieving seamless integration with existing clinical and surveillance infrastructures. While the prototype demonstrates the blockchain workflow using illustrative input, operational systems require secure and automated data acquisition from established hospital information systems and laboratory platforms. This integration is complicated by fragmented Electronic Health Record (EHR) infrastructures, inconsistent data standards, and the lack of unified patient identifiers, all of which impede interoperability. In practice, an event-driven integration layer based on modern interoperability standards such as FHIR offers the most viable approach for interfacing with Laboratory Information Management Systems (LIMS) and EHR platforms, rather than attempting direct communication with IoT laboratory devices.

Beyond interoperability, deployment requires well-defined governance structures and role-based access policies that comply with region-specific regulatory frameworks, including GDPR [28], HIPAA [29], and applicable national laws. Ensuring compliance may necessitate adaptations to access control rules, audit mechanisms, and data-retention policies. Further, sustaining a multi-organization blockchain network demands ongoing technical expertise in network administration, chaincode lifecycle management, and consensus operations. Resource-limited healthcare institutions may struggle to maintain these capabilities without dedicated operational support.

5.2. Limitations and Future Research

Several limitations of the current system warrant acknowledgment. First, the security analysis assumes a secure underlying PKI and trusted CAs. In practice, the system remains vulnerable to conventional cybersecurity threats, including the compromise of an authorized peer’s private key or a CA breach that enables fraudulent certificate issuance. Although external to the chaincode logic, such threats require mitigation measures, including the use of Hardware Security Modules (HSMs), multi-factor authentication, strict certificate-revocation procedures, and continuous monitoring of certificate activity.

A second limitation concerns the reliance on Hyperledger Fabric’s Private Data Collections, which provide confidentiality only at the organization level. Private records are disseminated solely to authorized peers through the gossip protocol and stored in off-chain state databases, while on-chain entries contain only hash commitments. Although this safeguards against unauthorized access within the consortium, protection of private databases depends on conventional security controls, including encryption at rest and secure peer infrastructure. Furthermore, predictable data fields [26] may expose the system to brute-force inference attacks against on-chain hashes, so client-side salting and encryption before data submission through the transient map are necessary to strengthen end-to-end privacy.

A third limitation relates to the ordering service configuration. The prototype employs a single RAFT orderer node for simplicity, thereby creating a single point of failure and failing to provide the availability guarantees expected in a production health-surveillance system. A resilient deployment requires a distributed RAFT ordering service cluster composed of multiple consenters to maintain quorum and preserve network liveness in the event of node failures.

A fourth limitation is the absence of analysis regarding network topology and its influence on system performance. Testing within a single local environment does not capture the wide-area network (WAN) latency expected when peers operate across geographically distributed test centers, regional directorates, and national authorities. Given that Hyperledger Fabric’s gossip protocol is sensitive to latency and bandwidth constraints, realistic deployments may experience slower block dissemination, delayed peer synchronization, and reduced ledger consistency. A production-scale evaluation should incorporate network simulations that emulate geographically dispersed topologies and associated latency conditions.

Another limitation is that the current implementation offers only basic chaincode functionality and lacks more advanced smart capabilities. Functions such as CreateRecord and UpdatePhoneNumber perform essential operations but do not incorporate automated analytics or AI-driven decision-making. Future development will embed smart logic directly into the chaincode, enabling automatic alert triggering for potential infection clusters based on spatial and temporal data. By incorporating simple analytical logic, the system could transition from a passive reporting platform to an active surveillance tool, notifying public health authorities immediately upon meeting predefined outbreak criteria.

Finally, although the prototype relies on illustrative data, the integrity-guaranteed design of the blockchain network provides a secure and auditable foundation that could support advanced mathematical epidemic modeling and prediction using verified datasets. Once deployed with real-world data, the system could supply high-quality inputs that reduce uncertainty in parameter estimation and prediction [30], thereby enabling the realization of the potential for advanced modeling and strengthening public health intelligence.

5.3. Threats to Validity

Threats to validity arise from various evaluation constraints. The prototype was evaluated in a controlled Docker-based environment, with all nodes running locally (e.g., on the same Docker host or local network), which may not fully represent the operational healthcare infrastructure. Consequently, performance measurements do not reflect WAN latency or the challenges associated with geographically distributed peers. Moreover, the evaluation used a single RAFT ordering node rather than a distributed ordering service cluster. Finally, the experiments relied on illustrative COVID-19 case data rather than live clinical data streams. These factors limit the direct generalization of performance results to large-scale, real-world deployments.

5.4. Security Analysis

Because the proposed system manages sensitive infectious disease data within a permissioned blockchain environment, its security and privacy properties require structured analysis. The adversarial threat model considers three primary threat categories: (i) identity compromise, in which an attacker breaches a Certificate Authority (CA) to obtain fraudulent credentials; (ii) data inference, where predictable attributes may enable brute-force attacks against on-chain hash commitments; and (iii) infrastructure breach, involving malicious insiders or compromised peer nodes targeting off-chain private state databases. These threats are evaluated in the context of privacy-preserving data sharing among authorized healthcare organizations operating under regulated governance frameworks.

These threats are mitigated through architectural controls implemented in the system. Identity-based access control restricts transaction submission to authenticated consortium members, while Private Data Collections (PDCs) ensure that sensitive patient data are disseminated only to authorized organizations. Private data is replicated across multiple authorized peers via the gossip protocol; therefore, PDCs do not constitute a single point of failure. Consequently, the failure of an individual peer does not compromise data availability, provided that other peers maintain the private state. However, availability depends on properly configured replication policies and the participation of multiple organizations within each collection. Sensitive data are transmitted via the transient data map and stored exclusively in the private state databases of authorized peers, whereas the shared ledger records only cryptographic hash commitments for integrity verification. To mitigate potential linkage and inference attacks, identifiers recorded on the public ledger are pseudonymized using salted hashing before submission, ensuring that they cannot be used to reconstruct or infer sensitive patient information stored in Private Data Collections. This design limits data exposure, enforces controlled disclosure, and preserves auditability while maintaining the confidentiality of patient information.

Despite these controls, certain residual risks remain that necessitate high-level operational safeguards. While PDCs enforce confidentiality at the organizational level, the protection of the underlying peer infrastructure remains a conventional security responsibility. Consequently, the use of Hardware Security Modules (HSMs) for key management and encryption-at-rest for CouchDB state databases is essential to prevent unauthorized data extraction from a compromised node. Furthermore, to strengthen end-to-end privacy against sophisticated inference attacks, applying client-side salting to data before hashing is recommended.

From a regulatory perspective, the architecture is designed to align with key requirements of the GDPR. By leveraging Fabric’s private-data purging capability, the system supports responses to the “right to erasure.” Specifically, using the PurgePrivateData API [26], sensitive records stored in off-chain private state databases can be permanently removed from authorized peers, including historical versions. The corresponding cryptographic hash commitments on the shared ledger remain immutable, preserving an auditable evidence trail for public health oversight while the personal data itself is removed from peer storage. This dual-layer design addresses the inherent tension between blockchain immutability and the GDPR “right to erasure.” It enables the removal of personal data when legally required while maintaining system integrity in a transparent and verifiable manner.

6. Conclusions

This study presents a permissioned blockchain architecture for hierarchical infectious disease reporting, designed to enhance data integrity, traceability, timeliness, and privacy preservation within multi-level public health surveillance systems. By leveraging Hyperledger Fabric, the proposed framework enables controlled data sharing among authorized healthcare organizations through identity-based access control, Private Data Collections (PDCs), and hash-based integrity verification while preserving institutional oversight over sensitive health records. Experimental validation within a containerized environment using illustrative COVID-19 case data provides empirical evidence that this decentralized approach is both architecturally feasible and capable of eliminating traditional single points of failure in health informatics. Performance evaluation results obtained with Hyperledger Caliper further showed that the system achieved efficient throughput and acceptable latency across varying transaction workloads, confirming its suitability for real-time surveillance applications. Overall, this study offers a technically secure and privacy-preserving foundation for modernizing the post-pandemic smart health infrastructure.