Enhancing Clinical Data Management Through Barcode Integration and Research Electronic Data Capture: Scalable and Adaptable Implementation Study

Introduction

In the digital age, operations across various fields are transforming, and digital pathology is revolutionizing traditional histopathological diagnosis by replacing microscopes and glass slides with virtual microscopy on computers [1,2]. Digital pathology has evolved into an exceptionally powerful and precise tool for the diagnosis and prognosis of a wide range of diseases [3-5]. However, hardware and software issues can greatly affect costs and slow down the implementation of clinical data management workflows [6]. Efficiently collecting and using data can be a significant challenge in clinical research due to the complexity and diversity of data types, the need for precise tracking and storage, and the potential for errors and inefficiencies in manual data handling. Therefore, an advanced informatics system for data management is essential and in high demand for ensuring precise and efficient usage of clinical research data [1,7-9]. Integrating tools like barcoding, specimen tracking, and digital dictation enhances the safety, quality, and efficiency of clinical research workflows [10]. Despite the clear potential improvements with a fully digital approach, only a small number of clinical research laboratories have transitioned to such workflows [11].

Clinical studies usually have complex and diverse data management needs that require tailored solutions depending on the nature and objectives of each study. For instance, some studies may need to collect samples from different organs or regions of the body to analyze specific diseases or conditions. Nourani et al [12] assessed various clinical data management systems by analyzing databases such as Web of Science, Scopus, Science Direct, ProQuest, Ovid Medline, and PubMed. Their study concluded that none of the systems comprehensively addressed all data management aspects in clinical trials. Therefore, it is often necessary to create customized data management systems tailored to specific needs. Without robust data management systems, researchers face challenges like data loss, sample tracking errors, and inefficiencies in data retrieval and analysis that compromise study quality and reliability and pose health risks or legal challenges for clinicians [9].

One widely used tool for managing clinical research data is REDCap (Research Electronic Data Capture), a web-based application developed by Vanderbilt University Medical Center [13,14]. REDCap offers a user-friendly interface for validated data entry, audit trails for tracking, and automated data exports for statistical analysis, making it a popular choice among academic, nonprofit, and government institutions worldwide [15-17,18,19]. Building on the capabilities of REDCap, Bao et al [20] designed a cross-platform informatics system with two key features: (1) a digitalized and human-readable barcode for sample tracking using a cost-effective printer, and (2) longitudinal archive storage in REDCap. After identifying several real-life bottlenecks, which are introduced below, we extended this system to more clinical studies over the past 5 years, including Crohn disease Gut Cell Atlas, Translational Impact of Electrophile Adducts in Colorectal Cancer. The project includes normal control, ulcerative colitis, Crohn disease, and colorectal cancer. It also includes surgical resections from the Cooperative Human Tissue Network in addition to colonoscopy biopsies. Helicobacter pylori (H. pylori)-associated gastric inflammation and disease progression, and gut–microbiome-related gastrointestinal and liver diseases, demonstrating significant improvements in data handling efficiency.

The challenges identified from real-life usage were: (1) barcode robustness, (2) detailed organ-specific data storage, and (3) system performance under increased data volume that could be further improved from the published system as shown in Figure 1. To elaborate on these challenges, first, barcodes are printed at a small size of 0.92″×0.54″ using a Dymo printer with 300 dpi resolution, often becoming blurred due to accidental touch, leading to scanner recognition errors and inefficiencies in sample tracking. A more robust barcode technology is needed for better recognition by current equipment even when blurred. Second, the need to record precise sample collection locations has increased as the studies now involve collecting samples from multiple specific regions, which the previous REDCap table design does not support. Enhancing the database structure to include organ-specific fields and a flexible data entry system would improve utility in diverse studies [20]. Third, system performance degrades significantly when the REDCap record count exceeds 100, affecting data entry, query, and retrieval efficiency. Implementing database optimization techniques, such as reducing interaction times with REDCap or refining query algorithms, could maintain optimal performance as the database grows.

‎

To address the identified issues, we propose three main design criteria for enhancing our system: (1) improving barcode robustness by updating the system with the most durable barcode technology available, (2) incorporating a dynamic organ-specific archive in the REDCap table design to support detailed anatomical data, and (3) optimizing system throughput to efficiently manage increased data volumes. Our methods include evaluating various barcode technologies under blurring conditions, implementing a dynamic organ-specific archive in REDCap, and using Docker for containerizing software clusters. In addition, we developed a local cache system to reduce interaction times with REDCap. Experimental setups involve testing barcode recognition accuracy and comparing system performance across different implementations. The results demonstrate significant improvements in barcode recognition, data granularity, and system throughput, thereby enhancing overall data management efficiency in clinical studies.

Methods

Overview

In this section, we detail the development and evaluation processes designed to meet the 3 proposed design criteria: improving barcode robustness, incorporating a dynamic organ-specific archive, and optimizing system throughput. Each methodology and experimental setup ensures the solutions are effective and practical for real-life clinical settings.

Data Management Workflows Overview

The data management workflow for 2 Python-based applications from [20], the Printer app and the Data entry app, which are integral components of our biopsy management with REDCap, is presented in Figure 2(A-B).

‎

Briefly, the Printer app workflow begins by entering the patient ID, which autofills the patient group based on control or study or disease-related subgroups. Next, the clinician ID is selected, and a print option is chosen, ranging from default to including extra frozen biopsies. The “Barcode Printing” step, highlighted in a green box in Figure 2, was identified as a bottleneck due to limitations in printer quality and previously selected barcode design. Finally, print events are synced to REDCap, ensuring all printed barcodes are recorded in the system.

The data entry app workflow starts by scanning the barcode and selecting the clinician ID. If samples are collected, the user enters the sample location information and selects the organ information, both highlighted in yellow boxes in Figure 2. The previous system could only handle one static organ selection, which was a limitation given the diverse clinical studies we manage. If samples are not collected, the barcode is marked as not collected, and the relevant REDCap field is removed. Syncing sample archive information to REDCap, highlighted in a red box in Figure 2, is where the interaction bottleneck was found, which is critical for optimizing system throughput.

Next, we introduce design criteria based on the 3 identified bottlenecks in detail.

Design Criteria 1. Evaluation-Driven Barcode Robustness Improvement

To address the issue of barcode robustness, a series of validations (Figure 3) was conducted to assess various barcode technologies and printing methods for decoding 8-digit numerical data [20] (necessitated by the limitations of printer quality and the tiny barcode size). The experiment included evaluating the following barcode types discussed in the literature [21,22]: (1) Code 39; (2) EAN-8; (3) ITF (Interleaved 2 of 5); (4) QR Code; and (5) DataMatrix. They were chosen for their simplicity, ease of printing, and reliability in a small size.

‎

One hundred unique 8-digit numbers were randomly generated for each of the 5 barcode types, and 5 rounds of testing were conducted. Each round applied a Gaussian blur with radii of 0, 0.5, 1, 1.5, and 2 pixels, corresponding to 0, 0.00167, 0.00333, 0.005, and 0.00667 inches, respectively. Although Gaussian blur was used as a proxy for image degradation, it does not fully capture the characteristics of printer smearing, which typically occurs in a single direction and is better modeled as motion blur. In practice, motion blur results in a point spread function resembling a rectangular function in image space and a sinc function in Fourier space. Despite this simplification, the barcodes were printed at a size of 0.94″ x0.52″, consistent with typical hospital settings. These barcodes were then scanned using the hospital’s standard scanner. The Adesso NuScan 5200TR is a 2.4GHz wireless barcode scanner (Adesso, Inc), and recognition accuracy was calculated for each barcode type and blur level. Gaussian blur was selected to systematically simulate image degradation under controlled and reproducible conditions for comparing barcode types. While this does not fully capture directional distortions such as motion blur, it enables consistent evaluation across barcodes within our experimental framework.

Design Criteria 2. Dynamic Organ-Specific Archive Implementation

As shown in Figure 4, the number of actions recorded in REDCap escalates rapidly with increasing patient sample collection. The design of the longitudinal tuple table was originally introduced in our previous work [20] and is briefly summarized here for completeness. In REDCap, an “arm” is a project structure that groups records either in fixed or longitudinal formats. While static arms are used for one-time data capture, longitudinal arms allow sequential event tracking over time. The longitudinal tuple table is implemented as an individual REDCap arm that flexibly records all operational actions associated with each barcode. These barcode actions include activities such as printing, scanning, storing, distributing, and destroying samples and are recorded without the need for predefined time points. This structure supports real-time, event-driven tracking and is well-suited for unpredictable and repeated operations in clinical workflows.

‎

Previously, the system focused on biopsies collected from the ascending colon and terminal ileum [20]. In this study, we have extended the longitudinal tuple table to accommodate broader organ involvement by incorporating an organ archive, which documents the specific organ region associated with each recorded action. This enhancement allows for precise tracking of sample origins across diverse clinical protocols, particularly in studies requiring detailed anatomical localization.

The tuple table is exported in JSON format and processed using Python’s pandas library, enabling efficient filtering, querying, and consistency checks. This flexible and scalable schema aligns with REDCap’s best practices for longitudinal study designs. Further technical details can be found in our earlier conference publication [20].

In our clinical setting, the application is deployed on dedicated laboratory workstations within a controlled network. Source code is version-controlled and maintained in the MASILab GitHub group repository, which is accessible only to authorized lab members.

We use Docker to containerize three clusters of software tailored for different types of studies, including normal control, Crohn disease, colorectal cancer, ulcerative colitis, colonoscopy, and H. pylori-associated gastric inflammation biopsies. This containerization ensures easy deployment and consistent programming environments for each study, streamlining the process for researchers and minimizing setup complexities. To showcase the effectiveness of these updates, we provide data summaries for different projects that use the enhanced design and containerized method. We release the data dictionary design for each clinical study in the data storage section and make the relevant applications available on GitHub [23].

Design Criteria 3. System Throughput Optimization With Refined REDCap Interaction

The throughput issue arises from continuous interactions with REDCap to download and update information. In the naïve system (Figure 5A), each sample is handled individually, performing one query and one update operation on REDCap for every sample scanned. This frequent interaction, involving verification and recording of each sample, significantly slows down the system as the number of patients and samples increases. To mitigate these interactions, we propose two approaches:

1. Bulk update action system: In this approach, the system can still perform frequent queries to REDCap but consolidates updates into a single bulk action. This method reduces the number of update operations, alleviating the bottleneck caused by frequent updates.
2. Local cache system: As illustrated in Figure 5B, a local cache method further optimizes throughput. Upon system initialization, REDCap records are downloaded into the local cache. Subsequent actions interact with the local cache instead of directly with REDCap. Once all actions are completed, the local cache is synchronized with REDCap, ensuring data integrity while minimizing interaction frequency.

‎

To validate optimization, we designed a controlled experiment involving 500 simulated patients, each requiring 10 distinct actions to be recorded. We measured the processing time per patient sequentially, from the first to the last, and compared system performance across three different implementation designs as the number of actions increased: (1) the naïve system, (2) the bulk update action system, and (3) the local cache system.

In the naïve system, each patient’s workflow triggered 10 REDCap export application programming interface (API) calls and 10 REDCap import API calls. The bulk update action system reduced the overhead by performing 10 REDCap exports but consolidating the imports into a single REDCap import API call per patient. The local cache system further optimized the process by requiring only one REDCap export and one REDCap import API call per patient.

The purpose of this validation experiment was to provide proof-of-concept evidence that reducing the number of REDCap API calls can substantially decrease processing overhead and improve overall system throughput. This experimental setup offers a robust, systematic evaluation of how API call optimization impacts real-time data processing performance. The experiments were conducted on a workstation equipped with a 1 Gbps network connection. For each test case, we performed 5-fold evaluations and reported both the average and cumulative results with 95% CIs.

Ethical Considerations

This project involves the use of fully de-identified data obtained from Vanderbilt University Medical Center (VUMC) under Institutional Review Board (IRB) approvals Vanderbilt IRB #191738 and #191777. While the original studies were classified as human participants research, this work is a secondary analysis focused solely on barcode system methodology and does not involve any access to protected health information (PHI) or patient identifiers by our research team. Therefore, this study does not qualify as human participants research under current regulations.

Informed consent was obtained for the primary studies at the time of patient recruitment and sample collection. The IRB approvals for these studies permit secondary analysis of deidentified data without additional consent. All data used in this study were deidentified before our analysis, ensuring that no personal health information or identifiable participant data were accessible to the study team. In addition, the barcode system uses a customized codebook that encrypts barcode information. The barcode content is only translatable within the custom-built application and cannot be independently decoded, adding an additional layer of privacy protection. No compensation was provided to participants for the studies described. No images in this manuscript or supplementary materials contain identifiable individual participants.

Results

Barcode Robustness Evaluation

The Barcode Robustness Evaluation aims to determine which barcode technology is reliable under different blurring conditions. The experimental design, illustrated in (Figure 6A), involves subjecting each barcode type to 5 rounds of Gaussian blurring. The blur radii tested were 0, 0.5, 1, 1.5, and 2 pixels, equivalent to 0, 0.00167, 0.00333, 0.005, and 0.00667 inches, respectively. As blurring increases with each round, we tested the readability of the barcodes using a standard scanner.

‎

The results, presented in (Figure 6B), indicate that by the fourth round, only the DataMatrix barcode remained consistently recognizable by the scanner. In contrast, the other barcode types (Code 39, EAN-8, ITF, and QR Code) failed to be accurately scanned under the same conditions. The results demonstrate that the DataMatrix barcode maintained its readability even in the final round of testing. Therefore, based on our equipment and experimental setup, we conclude that the DataMatrix barcode demonstrates the highest robustness and is the most suitable for use in our clinical environment.

Dynamic Organ-Specific Archive Showcase

To enhance the REDCap database, we updated the table design to store organ-specific information for each action taken on a sample. This allows for precise tracking of the origin of each sample, which is essential for studies requiring detailed anatomical data.

Demonstration of System Effectiveness Through Patient Demographics and Action Management

Following the evaluation of the 3 system designs, we present 2 tables that demonstrate the effectiveness and extensive application of our system in clinical studies. Table 1 summarizes the 4 clinical studies on recruitment procedures, target population and disease focus, recruitment locations, and recruitment time frame. For clarity, the corresponding acronyms are: CMA (Targeting Gut-Microbiome in Veterans Deployment-Related Gastrointestinal and Liver Diseases), EGD (Esophagogastroduodenoscopy project for VA_Dysregulated Polyamine), GCA (Gut Cell Atlas), and DoD (Translational Impact of Electrophile Adducts in Colorectal Cancer). As noted, the names of both CMA and DoD are not derived from the initials of their project titles but are designations aligned with clinical data collection documentation for consistency.

Together, our system covers 3 study types across 4 clinical studies:

1. CMA: Data are collected without knowing which organ is involved.
2. EGD: Data are collected from one organ, known before esophagogastroduodenoscopy. Tissues are always acquired from the gastric antrum and gastric corpus.
3. GCA: Data are collected only from the AC and TI.
4. DoD: Data are collected from one organ, known before colonoscopy.

Table 2 demonstrates the demographic range handled by the system in terms of age, race, and gender. Summarized by Table 3, the whole studies collectively handled a total of 38,819 actions, with the GCA study alone accounting for 16,911 actions. These actions include scanning, printing, destroying, distributing, and storing samples, showcasing the system’s extensive operational capabilities. The sample types managed include fresh, fixed, and frozen tissue; serum; stool; and DNA samples for Crohn disease and ulcerative colitis. The diverse sample types and the large, significant number of actions performed—such as 5106 prints, 4092 scans, 2113 destructions, 565 distributions, and 1360 storages in the nonsurgical CD case of the GCA study—highlight the system’s flexibility and efficiency in managing different biological materials and operational tasks.

System Throughput Optimization With Refined REDCap Interaction

The system throughput evaluation demonstrated consistent performance differences across the 3 implementations. Pairwise 2-tailed t tests were conducted, demonstrating that the performance differences between test cases were statistically significant (P<.001). As shown in Figure 7, the naïve system’s per-patient processing time steadily increased with the number of patients, largely due to the accumulation of overhead from multiple REDCap API calls (10 export and 10 import calls per patient). The bulk import system effectively reduced this overhead by consolidating import operations, resulting in a lower and more stable per-patient processing time. The local cache system exhibited the most efficient performance, maintaining minimal and stable processing times across all patient counts by further reducing the API call frequency to one export and one import per patient.

‎

The cumulative processing time, presented in Figure 8, further underscores the efficiency gains of the optimized systems. The naïve system displayed the steepest cumulative growth, reflecting its scalability limitations. In contrast, the bulk import system achieved moderate improvement, and the local cache system substantially minimized cumulative processing time, demonstrating superior scalability and throughput. These results validate the hypothesis that reducing the number of REDCap API calls is critical for improving system efficiency and highlight the robustness of the local cache approach for large-scale clinical workflows.

‎

Discussion

Overview

In this study, we aimed to enhance clinical data management by improving barcode robustness, increasing data granularity, and optimizing system throughput to better support real-world clinical workflows. Our results demonstrated that the DataMatrix barcode provided superior recognition accuracy under blurred conditions, addressing barcode robustness issues identified in previous work. By incorporating a dynamic organ-specific archive within REDCap, we enabled precise tracking of sample origins, supporting studies with complex and evolving anatomical requirements. In addition, system throughput was significantly improved through the introduction of a local cache mechanism, reducing REDCap API interaction overhead and increasing processing efficiency. Together, these enhancements address key bottlenecks in barcode informatics systems and validate the effectiveness of the proposed design criteria across diverse gastrointestinal clinical studies. In the following subsections, we provide a detailed discussion of these findings, including comparisons to previous work and an evaluation of system limitations.

Principal Results

The enhancements proposed and tested in this study significantly improve the efficiency and robustness of the cross-platform informatics system initially developed by Bao et al [20]. By addressing key issues such as barcode robustness, detailed data archiving, and system throughput, we have demonstrated tangible benefits in managing clinical data. The DataMatrix barcode was identified as the most reliable under various blurring conditions, ensuring accurate sample tracking even in suboptimal environments.

Although both QR Code and DataMatrix barcodes demonstrated high resilience under blurring, our final selection of the DataMatrix barcode was driven by the practical constraints of our clinical workflow. Specifically, the DYMO LabelWriter 450 printer (~US$200) used in our system could not consistently produce QR codes with sufficient resolution on the Diversified Biotech DTCR-6000 Direct Thermal Cryo-Tags (Sigma-Aldrich; 5″×1.5″, US$45.50 per roll of 500), which are required to fit 1.5 mL cryovials. DataMatrix barcodes are more space-efficient and less sensitive to printer resolution, enabling reliable scanning at this small label size. The Adesso NuScan 5200TR scanner (~US$200) used in our system was capable of scanning both barcode types robustly, confirming that scanner limitations were not the primary issue.

The implementation of a dynamic organ-specific archive in REDCap allows for precise tracking of sample origins, enhancing data granularity and usability. Organ selection within our system is guided by the clinical protocols of each study, which define the sampling regions in advance. Given that each project may target different anatomical sites, the system allows flexibility in specifying the organ for each action. In cases where ambiguous or overlapping anatomical regions arise, both the printer app, data entry app, and the REDCap schema include dedicated comment fields that enable clinicians to record relevant details or uncertainties. It is important to note that the barcode system serves as a tracking mechanism and does not resolve anatomical ambiguities; instead, such contextual details are manually documented to ensure clinical accuracy.

In clinical practice, evolving study protocols and mid-study changes in data collection requirements are common. Our system is designed to accommodate some of these changes, such as adding new label types or supporting additional sample collection strategies (eg, switching to frozen biopsies when fresh samples are unavailable) without disrupting the existing workflow. More substantial protocol changes, such as significant modifications in label design or data entry workflows, may require the deployment of new application versions. Our framework supports this by allowing distinct study cases with customized printing and data entry workflows. One key lesson learned is the value of improving label printing flexibility to enable on-the-fly adaptations in future versions of the system.

REDCap’s built-in caching mechanisms, such as project dashboard caching, are designed to improve web interface performance by temporarily storing data in the browser when records remain unchanged. These optimizations do not apply to API-based workflows or external applications that require real-time, high-frequency interactions, such as barcode scanning and sample tracking. Our system introduces a local cache layer that supports customized, app-integrated workflows, significantly reducing the need for repetitive API calls and improving throughput during barcode-driven operations, ensuring smooth operation even with large patient datasets. These improvements collectively enhance the system’s ability to support complex and large-scale clinical studies, thereby contributing to more reliable and efficient data management practices.

Comparison With Previous Work

Our work builds on the foundation established by previous work Bao et al [20], introducing significant improvements in barcode technology, data granularity, and system throughput.

The system incorporates practical error-handling mechanisms for both barcode scanning and REDCap database accessibility. In early versions [20], we observed occasional scanning failures with the EAN-8 barcode format, which led us to adopt the more robust DataMatrix format in the current system. No barcode scanning failures have been observed since this transition. In addition, the application supports manual barcode entry to handle any potential scanner-related issues.

While the original system provided a complete framework for clinical data management, our enhancements address specific bottlenecks identified in real-world usage. Previous studies have highlighted the importance of reliable barcode tracking and data entry consistency in clinical settings, but our study uniquely combines these aspects with a comprehensive approach to system optimization, demonstrating substantial performance gains. The scalability evaluation using 500 patients and 10 actions per patient was designed as a proof-of-concept to assess system performance under moderate workload conditions. The primary performance constraint arises from the frequency and volume of REDCap API interactions, which are tightly coupled with system throughput. While the current local cache mechanism significantly reduces API traffic, scaling the system to support significantly larger datasets would require further architectural optimization, including improved cache synchronization, enhanced concurrency handling, and more systematic pressure testing to assess system robustness at scale. Exploring these enhancements will be essential to support high-volume clinical studies in future deployments.

Limitations

Our barcode robustness assessment did not directly incorporate motion blur or real-world scanner variability. Future studies should address these factors to further validate barcode performance in practical clinical environments. In addition, the evaluation of barcode robustness was conducted under controlled conditions, which may not fully capture the broader variability of real-world clinical environments. The system’s performance and usability could also benefit from further enhancements to the user interface to better accommodate a wider range of clinical study applications.

In cases where the REDCap database becomes temporarily inaccessible, the system either prevents application launch (as a REDCap record export is required during initialization) or triggers a warning message if a connection failure occurs during active operation. While these mechanisms provide basic error notifications, further improvements in offline operation support and automatic recovery strategies will be considered in future work.

Despite these, the local cache mechanism, while effective, is currently designed for use by a single operator at a time. This may limit its applicability in larger research settings where multiple operators need to work simultaneously. Specifically, the system supports a text-based flag to prevent simultaneous access by multiple users on the same workstation; this feature is not enabled in the production environment. In clinical practice, strict single-user operation per workstation is enforced to maintain data integrity and simplify workflow management. Multi-user concurrency across different workstations is not supported in the current system. Supporting such functionality would require robust cross-machine locking, cache synchronization, and efficient REDCap API management, which remains an important area for future development.

Furthermore, data integrity between the local cache and REDCap is safeguarded by ensuring that the local cache is updated only after a successful sync process is completed. If the system fails to retrieve updated REDCap records, a warning message is triggered to alert the user of the issue. However, this safeguard has not been systematically validated under high-volume or failure-prone conditions. Future work will focus on more rigorous testing of the sync process, including controlled failure scenarios and large-scale data loads, to ensure cache consistency and system resilience.

Finally, Docker containers in this work are provided to support users who wish to test the system or replicate the design criteria but are not the primary security mechanism. Future work will explore strategies for securely deploying this system across multiple research teams and sites.

Conclusions

The proposed enhancements significantly improve barcode robustness, data granularity, and system throughput in our informatics system, enabling more efficient and reliable clinical data management. These optimizations not only support diverse clinical research workflows but also demonstrate a scalable framework that can be adapted for complex, multiorgan studies across different institutions. Beyond the immediate performance gains, this work highlights the importance of system design strategies that minimize external API dependencies to achieve throughput improvements in high-volume clinical settings. Looking forward, future enhancements will focus on developing synchronization capabilities to support simultaneous multioperator use and creating a more versatile user interface to accommodate a broader range of study designs. These advances will further expand the system’s applicability and promote its integration into larger, multisite research environments.