# Reproducible Research with Proprietary Data

By the end of this guide you will be able to take data that arrives locked inside a vendor format, a clinical information system, or a licensed platform and build a fully reproducible analysis around it. You will export raw files into open formats, put every transformation under version control, pin your software in a container, de-identify sensitive fields inside the pipeline, benchmark your open workflow against a known reference, and write the reproducibility statement that journals and reviewers increasingly expect.

You need Python 3.10 or newer, R 4.x, Git, and Docker Desktop installed (Apptainer works on high-performance computing clusters). You also need read access to your raw instrument or system exports, a place to store one secret string for de-identification, and about a day of setup time. Every command below runs in a macOS, Linux, or Windows Subsystem for Linux terminal.

Reproducible research means that another person, or you in two years, can rerun the analysis on the same inputs and obtain the same numbers. Replication, meaning a fresh study that tests whether the finding holds in new data, is a separate goal. This guide targets computational reproducibility and treats proprietary data as an engineering constraint rather than a barrier.

Proprietary data is any input you cannot legally or technically redistribute. Common forms include binary instrument files from mass spectrometers and sequencers, licensed databases, clinical records held in a patient [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices) system (PDMS), the software that charts bedside measurements in intensive care, and telemetry, meaning internal motion and event data, from closed hardware. Reproducible research with proprietary data is achievable because reproducibility lives in the pipeline, not in the data files. The eight-step walkthrough below shows exactly how.

## Why Proprietary Data Undermines Reproducible Research

Three failure modes recur across the life sciences.

First, the toolchain is fragmented across closed components. Targeted liquid chromatography-tandem mass spectrometry (LC-MS/MS) phenotyping typically chains proprietary vendor formats, manual peak integration, and ad hoc quality-control scripts, which introduces user- and laboratory-level variation that undermines reproducibility and confounds comparison between laboratories [1]. Solid-state NMR, a technique that probes molecular structure in non-liquid samples, faces the same problem in pharmaceutical settings, where workflows rely on multiple proprietary software packages that limit accessibility, throughput, and consistency [2].

Second, results depend on which implementation you used, and closed implementations cannot be inspected. In 16S rRNA gene microbiome research (the 16S gene being the standard marker for bacterial identification) on the Ion Torrent platform, researchers benchmarked the proprietary Ion Reporter software against eight open-source pipelines built on QIIME2 and the SILVA reference database. The choice of denoising algorithm, the step that infers true sequences and removes sequencing errors (DADA2 versus Deblur), significantly affected alpha diversity, the diversity of species within a single sample [3]. The proprietary and open workflows also differed in which taxonomic levels they resolved best. An analysis that exists only inside a closed tool cannot be checked, rerun, or corrected by anyone else.

Third, software goes unreported. An analysis of 1,740 biomedical and health science articles found that proprietary packages such as IBM SPSS still dominate [statistical analysis](/blog/guides/statistical-analysis), and a surprising number of articles did not report the software used at all [4]. If readers do not know what ran, they cannot reproduce it.

## The Four-Layer Strategy for Reproducibility with Proprietary Data

Reproducibility with proprietary data rests on four layers. Each layer compensates for a specific property of closed systems.

**Layer 1, open formats at the boundary.** Convert once, at ingestion, from the vendor binary into a community-maintained open format such as mzML (the open XML standard for mass spectrometry data) or FASTQ (the plain-text standard for raw sequencing reads). Choose targets that several independent tools can read, and archive the original raw file untouched as permanent evidence.

**Layer 2, scripted analysis.** Every transformation is code in a version-controlled repository, with no click-only steps. The ABCD Study, the largest longitudinal study of child brain development in the United States, replaced rigid scoring through REDCap and ad hoc external scripts with an open R package so that summary scores are computed transparently and consistently across its large multimodal dataset [5].

**Layer 3, pinned environments.** A container bundles the operating system libraries, tools, and dependencies at exact versions into one portable image. MStargetR, a containerized R workflow for targeted mass spectrometry, pins its third-party tools in version-controlled Docker images and supports Apptainer, the container runtime common on high-performance computing clusters [1].

**Layer 4, documented provenance.** Audit logs, checksums, and a data availability statement connect every published number back to a raw file and a code commit.

The table summarizes where common proprietary data types lock you in, the open-format target, and a published open workflow that demonstrates the escape route.

| Proprietary data type | Typical lock-in | Open-format target | Published open workflow |
|--|--|--|--|
| LC-MS/MS vendor raw files | Binary formats and manual peak integration | mzML via msConvert | MStargetR modules in R [1] |
| 16S [amplicon sequencing](/blog/guides/amplicon-sequencing) runs | Platform-specific analysis software | Demultiplexed FASTQ | QIIME2 pipelines with SILVA [3] |
| Clinical PDMS records | Transactional proprietary database | Typed, analysis-ready tables | Modular Python ETL with audit logging [6] |
| Solid-state NMR free induction decays | Multiple proprietary packages | Standardized spectral exports | Cloud-based SNAP platform [2] |
| Multiplex immunofluorescence images | Proprietary analysis software or hardware | QuPath projects and batch scripts | Semi-automated QuPath protocol [7] |
| UV-visible spectra | Vendor acquisition and post-processing software | Open Python workflow | PySpecTrace GUI [8] |
| Surgical robot telemetry | Closed proprietary interfaces | External synchronized acquisition | MiDAS open acquisition system [9] |

Three entries deserve a note. QuPath brings machine-learning-based cell segmentation, object and pixel classification, and batch scripting to multiplex immunofluorescence analysis that historically required proprietary tools [7]. MiDAS takes the opposite approach to closed telemetry: rather than extracting data from the proprietary robot interface, it records time-synchronized hand tracking, foot pedal signals, and video from external sensors, matching the gesture recognition performance of proprietary telemetry without touching the closed system [9]. PySpecTrace applies the same open principle to UV-visible spectroscopy, unifying acquisition, [preprocessing](/blog/data-analysis/what-is-data-preprocessing), and feature extraction in one Python interface [8].

## Step-by-Step: Reproducible Research with Proprietary Data

The walkthrough uses a targeted metabolomics project with human plasma samples as the running example. Every step transfers to sequencing, imaging, or clinical data. Follow the steps in order the first time, then adapt.

### Step 1. Export the rawest data you are allowed to keep

Ask the instrument operator for the raw acquisition files, not just the processed export shown on screen. For mass spectrometry, convert to mzML with ProteoWizard's msconvert:

```
msconvert RUN2024_017.raw --mzML -o converted/
ls converted/
```

Expected output:

```
RUN2024_017.mzML
```

The `-mzML` parameter selects the open XML target format and `-o` sets the output folder. For sequencing, request demultiplexed FASTQ plus the sample sheet. Keep the original raw file read-only in an archive folder and record its checksum, a short fingerprint computed from the file's bytes so any later change is detectable:

```
md5sum RAW/RUN2024_017.raw > logs/raw_checksums.txt
cat logs/raw_checksums.txt
```

Expected output:

```
7f3a91c2e8b40d55aa1c6f0b2e9d8471  RAW/RUN2024_017.raw
```

Building the conversion into the scripted pipeline, rather than running it by hand, is the pattern used by MStargetR, whose msConvertR module wraps vendor-to-mzML conversion inside the workflow [1].

Common error: `msconvert: command not found`. The ProteoWizard binary is not on your PATH. Fix by adding the installation's bin folder to PATH, or run msconvert inside the container built in Step 3 so the tool is pinned for everyone.

Check: open the mzML in any standards-compliant viewer and confirm that the scan count and acquisition timestamps match the vendor software's own summary for the same run.

### Step 2. Put the project under version control

Create a fixed folder structure and initialize Git:

```
mkdir -p myproject/RAW myproject/converted myproject/code myproject/logs myproject/results
cd myproject
git init
echo "RAW/" >> .gitignore
git add code/ .gitignore
git commit -m "Pin initial analysis scripts"
```

Expected output:

```
Initialized empty Git repository in /home/you/myproject/.git/
[main (root-commit) 3f9c1d2] Pin initial analysis scripts
 2 files changed, 12 insertions(+)
```

Commit code, small metadata files, and documentation. Never commit raw patient data or large binaries, which is what the `.gitignore` line prevents. Tag each release so results can be tied to an exact code state:

```
git tag v1.0.0
```

Common error: `fatal: not a git repository (or any of the parent directories): .git`. You ran a git command outside the repository folder, or before `git init`. Fix by moving to the project root and initializing first.

### Step 3. Pin the software environment in a container

A container turns "it worked on my machine" into a fixed artifact that others can pull and run. Create a `requirements.txt` with exact versions:

```
pandas==2.2.2
pydantic==2.7.1
scikit-learn==1.4.2
```

Create a `Dockerfile`:

```dockerfile
FROM python:3.11-slim
WORKDIR /pipeline
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY code/ ./code/
```

Build and run:

```
docker build -t myproject:1.0.0 .
docker run -v "$PWD":/work myproject:1.0.0 python /pipeline/code/run_analysis.py
```

Expected output:

```
=> naming to docker.io/library/myproject:1.0.0
Loaded 96 records from converted/vitals_export.csv
Wrote results/summary.csv
```

The `-t` flag names and versions the image, and `-v "$PWD":/work` mounts your current folder into the container so results land on your own disk. This is the discipline MStargetR applies: its modules wrap msConvert for conversion and Skyline for peak integration, all pinned in version-controlled Docker images, and the workflow processed a published lipidomics dataset of 128 human plasma samples covering 1,161 lipid species end to end [1].

Common error: `docker: permission denied while trying to connect to the Docker daemon socket`. Your account lacks Docker access. Fix by asking your administrator to add your account to the docker group, or use Apptainer on your cluster, which runs without root.

Check: run the container a second time into a different output folder and compare:

```
diff -q results/run1.csv results/run2.csv
```

No output means the files are identical, which is what reproducibility looks like at the file level.

### Step 4. Script every transformation and validate the schema

Replace each GUI step with code, and make the code reject malformed input instead of passing it downstream. The modular Python ETL (extract, transform, load) framework developed for intensive-care PDMS data shows the pattern: dedicated typed models enforce consistent output schemas, type constraints, and automated plausibility checks, while an integrated audit logger records extraction parameters, transformations, and derived fields for full traceability [6].

A minimal schema check in Python:

```python
from pydantic import BaseModel, field_validator
import pandas as pd

class VitalsRecord(BaseModel):
    patient_id: str
    heart_rate_bpm: float
    timestamp: str

    @field_validator("heart_rate_bpm")
    @classmethod
    def plausible_hr(cls, v):
        if not 0 < v < 300:
            raise ValueError(f"heart rate out of range: {v}")
        return v

df = pd.read_csv("converted/vitals_export.csv")
records = [VitalsRecord(**row) for row in df.to_dict("records")]
print(f"validated {len(records)} records")
```

Expected output on clean data:

```
validated 96 records
```

On corrupted data the pipeline stops with:

```
ValueError: heart rate out of range: 940.0
```

That failure is the feature. A silent implausible value in an analysis-ready table costs far more than a loud crash. The same principle, moving opaque manual scoring into transparent versioned code, motivated the ABCD Study's open scoring package [5].

### Step 5. De-identify inside the pipeline

![Diagram of a record passing through salt lookup, a check that the salt is set, SHA-256 hashing, and an analysis-ready table with no identifiers.](/article-images/illustrations/reproducible-research-with-proprietary-data-deidentification-pipeline.webp)

If the proprietary data contains patient identifiers, de-identification must happen in code, before any file leaves the secure environment. The intensive-care ETL framework embeds salted, irreversible pseudonymization directly in the pipeline, so exported analysis-ready tables never carry identifiers [6]. A salt is a secret random string stored outside the repository. Combining it with the identifier before hashing prevents anyone from reversing the mapping or precomputing a lookup table.

```python
import hashlib, os

SALT = os.environ["STUDY_SALT"]  # stored in a secrets manager, never in Git

def pseudonymize(mrn: str) -> str:
    return hashlib.sha256((SALT + mrn).encode()).hexdigest()

print(pseudonymize("MRN-048821"))
```

Expected output:

```
9b74c98a1c0f4d2e8b6a35f0c7d1e9a4b2c8f6d0e3a5b7c9d1e2f4a6b8c0d2e4
```

The exact value depends on your salt, which is the point. Set the variable before running:

```
export STUDY_SALT="a-long-random-string-from-your-secrets-manager"
python code/pseudonymize.py
```

Common error: `KeyError: 'STUDY_SALT'`. The environment variable is not set in this shell. Fix by exporting it, or run inside the container with the secret injected through your secrets manager.

Dataset builders apply the same discipline at release time. The Bangla-MedER medical entity recognition dataset removed personally identifiable information and proprietary brand names from its text before publication, while still providing the raw transcribed text so others can reproduce and verify the annotation work [10].

### Step 6. Benchmark against a reference standard

When you replace a proprietary workflow with an open one, demonstrate that the open pipeline gives defensible results. The microbiome benchmark in [3] offers the template. The researchers ran a commercial fecal reference material (ZymoBIOMICS D6323) whose composition had been characterized by shotgun sequencing, which reads all DNA in a sample rather than one marker gene, and treated that profile as the reference standard. Scoring each pipeline against the reference let them move beyond "our pipeline differs" to "our pipeline is closer to the truth."

Translate the template to any field:

1. Obtain reference material with a known answer: a certified standard, a spike-in with known quantities added, or a published dataset with established values.
2. Run your open pipeline and the incumbent proprietary workflow on the same reference.
3. Record agreement and divergence in the methods section, naming the reference explicitly.

Design choices matter as much as software. In the same benchmark, library preparation with two primer sets yielded about 30 percent lower expected read counts than a single primer set (incidence rate ratio 0.6986, p < 0.001) [3]. Report such choices explicitly, because a reader cannot reproduce results from an undescribed library design.

### Step 7. Capture software and AI provenance

Record every version automatically, not from memory:

```r
writeLines(capture.output(sessionInfo()), "logs/sessionInfo_R.txt")
```

Expected output (excerpt):

```
R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
attached base packages:
[3] stats  graphics  grDevices  utils  datasets  methods  base
```

For Python:

```
pip freeze > logs/requirements_freeze.txt
```

In R, the renv package can additionally lock package versions into a commit-able lockfile. If any step used a large language model (LLM), log the model family, the version or access date, the full prompts, and the inference settings. A scoping review of rheumatology LLM studies found that 79.4 percent used closed proprietary models and that reporting was heterogeneous, with the interaction language unreported in about two thirds of the 63 studies [11]. Bibliometric auditing of secondary analyses of large health databases now checks articles for reported R versions, code and data availability, and declarations of generative AI use [12]. Write your methods section to survive exactly that audit, and name every package and version, including the closed ones, because unreported software is a flagged gap in large-scale article audits [4].

### Step 8. Decide what to release, and document the rest

![Decision path asking whether de-identification and licensing allow sharing, leading to one of three release tiers.](/article-images/illustrations/reproducible-research-with-proprietary-data-release-tier-decision.webp)

Choose one of three release tiers.

**Tier 1, release everything.** When de-identification and licensing allow, publish the dataset itself. Published examples include an open multimodal uveal melanoma imaging dataset pairing ultra-widefield fundus photographs and B-scan ultrasonography for 645 eyes with structured clinical annotations [13], the Bangla-MedER annotated text corpus [10], and the MiDAS system released with annotated multimodal surgical datasets [9].

**Tier 2, release code and methods, describe data access.** When the data cannot move because it contains protected health information (PHI) or the license forbids redistribution, publish the container, the scripts, the audit log format, and a data availability statement naming the source system, the extraction script, and the controlled-access route.

**Tier 3, release derived results with full provenance.** When even derived data is restricted, publish summary results together with the container and code so the path from raw inputs to published numbers remains auditable.

For all three tiers, the audit log from Step 4 and the container from Step 3 are what make the release trustworthy rather than decorative.

Three practical tips keep this workflow alive after publication. First, register the code repository and container image with a service that issues [persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow) so reviewers can cite exact versions. Second, schedule a dry run in which a colleague reruns the pipeline from the repository alone, and fix whatever blocks them. Third, revisit the release tier whenever the underlying agreements change.

## A Reproducibility Checklist You Can Reuse

Run this reproducibility checklist before submission and store the completed copy with your results.

1. Raw proprietary files archived read-only with recorded checksums.
2. One documented conversion step into open formats (mzML, FASTQ, CSV, or Parquet).
3. All analysis steps exist as scripts in a version-controlled repository.
4. No manual GUI steps remain in the final path, or each is exported as a saved script or session file and versioned.
5. Environment pinned in a Docker or Apptainer image with exact versions.
6. Random seeds set and recorded wherever randomness exists.
7. Schemas and plausibility checks enforced in code.
8. De-identification performed inside the pipeline with the salt stored externally.
9. Benchmark against reference material or the incumbent workflow recorded in the methods.
10. sessionInfo or pip freeze output stored alongside results.
11. AI assistance documented with model, version or access date, prompts, and settings.
12. Data availability statement distinguishes shared, controlled-access, and restricted data.
13. Methods section names every software package and version, proprietary or open.

## Common Mistakes and Limitations

**Treating the proprietary tool's output as the only truth.** Implementation choice measurably changes results, so a single closed workflow deserves benchmarking against a reference rather than automatic deference [3].

**Leaving manual click-through steps in the final path.** Manual integration and ad hoc quality-control scripts introduce user- and laboratory-level variation that undermines reproducibility [1]. If a GUI step is unavoidable, save its session file or generated script and commit it.

**Omitting software from the methods.** Unreported software makes an analysis unverifiable, and the gap is common enough that large-scale article audits flag it explicitly [4].

**Leaving AI steps unlogged.** The rheumatology review shows what missing reporting looks like in practice: closed models used widely, with versions, prompts, and settings rarely documented [11]. An unlogged AI step is a step nobody can rerun.

**De-identifying as an afterthought.** Copying identifiable data between laptops and drives before cleaning multiplies leak risk. Pseudonymization belongs inside the pipeline, as the intensive-care framework implements [6].

**Confusing proprietary data with unreproducible analysis.** The pipeline can be fully open even when the data cannot be shared. The reverse also holds: open data analyzed through undocumented clicks is still not reproducible.

**Skipping the raw archive.** Converting to open formats without keeping the original raw file destroys your ability to reconvert when standards change or conversion bugs surface.

**Mining databases through templated shortcuts.** Rapid secondary analyses of large public health databases, accelerated by templated workflows and AI tools, have raised documented quality concerns [12]. The same discipline that governs proprietary data applies to public databases: report versions, code, and data sources.

One limitation bounds all of the above. The release tier and de-identification depth that fit your project depend on your data use agreement, your institution's privacy office, and applicable law such as HIPAA for protected health information in the United States, so confirm those specifics with the responsible office before sharing anything.

## Frequently Asked Questions

### Can research be reproducible if the data can never be shared?
Yes. Reproducibility of the analysis and public availability of the data are separate properties. You can release the code, the container, the parameter files, and a precise data availability statement, so others can rerun the pipeline on data they obtain through the same controlled route.

### What is the difference between reproducibility and replication?
Reproducibility means the same code and data produce the same result. Replication means a new study with new data reaches the same conclusion. A pipeline can be perfectly reproducible and still fail to replicate, which is why benchmarking against reference standards matters alongside clean engineering.

### How do I convert proprietary instrument files into open formats?
Use the vendor's exporter or a community converter such as ProteoWizard's msconvert, which writes mass spectrometry data to mzML. Keep the original raw file untouched, record its checksum, and place the conversion command inside your scripted pipeline rather than performing it by hand.

### Do I have to stop using proprietary software like SPSS?
No. Proprietary tools can sit inside a reproducible workflow if you report the exact name and version, script whatever can be scripted, and archive the outputs. Document the choice deliberately, because proprietary and open implementations can produce different results, and benchmark where feasible.

### How do I make AI-assisted analysis steps reproducible?
Log the model name, the version or access date, the complete prompts, and the inference settings, then store that log with the code. These details are the most commonly missing pieces, and without them no one, including you, can rerun the step as it was originally executed.

### What belongs in a reproducibility checklist?
At minimum: archived raw data with checksums, an open-format conversion step, version-controlled scripts, a pinned container, recorded seeds, schema validation, in-pipeline de-identification, software and AI provenance, and a data availability statement. The thirteen-item checklist in this article turns each into a pass or fail test.

### How much provenance detail should I keep?
Enough to reconstruct every derived field. An audit log that records extraction parameters, transformations, and derived fields lets a reviewer trace any value in your analysis-ready tables back to its source record.

### Can I publish a dataset built from a proprietary clinical system?
Often yes, after de-identification and with institutional approval. Published examples include annotated imaging datasets and curated text corpora that removed identifiers and proprietary brand names before release. Route the decision through your privacy office and data use agreement before planning the release.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Can research be reproducible if the data can never be shared?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Reproducibility of the analysis and public availability of the data are separate properties. You can release the code, the container, the parameter files, and a precise data availability statement, so others can rerun the pipeline on data they obtain through the same controlled route."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between reproducibility and replication?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Reproducibility means the same code and data produce the same result. Replication means a new study with new data reaches the same conclusion. A pipeline can be perfectly reproducible and still fail to replicate, which is why benchmarking against reference standards matters alongside clean engineering."
      }
    },
    {
      "@type": "Question",
      "name": "How do I convert proprietary instrument files into open formats?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use the vendor's exporter or a community converter such as ProteoWizard's msconvert, which writes mass spectrometry data to mzML. Keep the original raw file untouched, record its checksum, and place the conversion command inside your scripted pipeline rather than performing it by hand."
      }
    },
    {
      "@type": "Question",
      "name": "Do I have to stop using proprietary software like SPSS?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Proprietary tools can sit inside a reproducible workflow if you report the exact name and version, script whatever can be scripted, and archive the outputs. Document the choice deliberately, because proprietary and open implementations can produce different results, and benchmark where feasible."
      }
    },
    {
      "@type": "Question",
      "name": "How do I make AI-assisted analysis steps reproducible?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Log the model name, the version or access date, the complete prompts, and the inference settings, then store that log with the code. These details are the most commonly missing pieces, and without them no one, including you, can rerun the step as it was originally executed."
      }
    },
    {
      "@type": "Question",
      "name": "What belongs in a reproducibility checklist?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "At minimum: archived raw data with checksums, an open-format conversion step, version-controlled scripts, a pinned container, recorded seeds, schema validation, in-pipeline de-identification, software and AI provenance, and a data availability statement. The thirteen-item checklist in this article turns each into a pass or fail test."
      }
    },
    {
      "@type": "Question",
      "name": "How much provenance detail should I keep?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Enough to reconstruct every derived field. An audit log that records extraction parameters, transformations, and derived fields lets a reviewer trace any value in your analysis-ready tables back to its source record."
      }
    },
    {
      "@type": "Question",
      "name": "Can I publish a dataset built from a proprietary clinical system?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Often yes, after de-identification and with institutional approval. Published examples include annotated imaging datasets and curated text corpora that removed identifiers and proprietary brand names before release. Route the decision through your privacy office and data use agreement before planning the release."
      }
    }
  ]
}
</script>

## Sources

1. [MStargetR: a reproducible, containerised workflow for end-to-end targeted (MRM/SRM) mass spectrometry data processing in R.](https://pubmed.ncbi.nlm.nih.gov/42791429/)
2. [Cloud based solid state NMR automated processing (SNAP): A digital solution to enable efficient and robust data analysis.](https://pubmed.ncbi.nlm.nih.gov/42914776/)
3. [Evaluating 16S metagenomics data analysis pipelines using an Ion Torrent sequencer for human gut microbiome research.](https://pubmed.ncbi.nlm.nih.gov/42919172/)
4. [Using LLM-generated tools to extract information about reporting statistical software in biomedical and health science research articles.](https://pubmed.ncbi.nlm.nih.gov/42365353/)
5. [ABCDscores: an R package for computing summary scores in the ABCD Study®.](https://pubmed.ncbi.nlm.nih.gov/42666405/)
6. [Extraction and processing of intensive care chart data from a patient data management system.](https://pubmed.ncbi.nlm.nih.gov/41938603/)
7. [An Open-Source Workflow for Semi-Automated Spatial Profiling of Multiplex Immunofluorescent Images.](https://pubmed.ncbi.nlm.nih.gov/41848572/)
8. [PySpecTrace: A Python-based Graphical User Interface for Real-Time Spectroscopy Analysis and Data Analysis.](https://pubmed.ncbi.nlm.nih.gov/42935482/)
9. [MiDAS: A Multimodal Data Acquisition System and Dataset for Robot-Assisted Minimally Invasive Surgery.](https://pubmed.ncbi.nlm.nih.gov/42626778/)
10. [Bangla-MedER: An annotated Bangla dataset for multi-type medical entity recognition from medical text.](https://pubmed.ncbi.nlm.nih.gov/41952846/)
11. [Large language models in rheumatology-centered research: A scoping review of model openness and reporting practices.](https://pubmed.ncbi.nlm.nih.gov/42156255/)
12. [Paper mill or paper mine? A tentative answer to the sharp increase in research papers based on the Global Burden of Disease database.](https://pubmed.ncbi.nlm.nih.gov/42624337/)
13. [Open-Source Multimodal Imaging and Clinical Data Set for Uveal Melanoma.](https://pubmed.ncbi.nlm.nih.gov/42997692/)