# De-identification of Genomic Data for Sharing: A Decision Framework De-identification of genomic data for sharing means removing or transforming the information that links sequences back to the person, family, or sample they came from, and it differs from controlled sharing in that de-identification changes the data itself while controlled sharing changes who can reach it. The rule of thumb for choosing between options is simple: release the least identifiable data format that still answers the scientific question, and pair whatever format you choose with access control and audit logging, because no transformation on its own makes a genome anonymous. This article lays out the main options, explains how each one works, compares them on the criteria that decide real choices, and walks through worked scenarios so you can match a method to your own situation. ## Why Genomic Data Resists De-identification Most biomedical data can be made anonymous with enough care. Genomic data cannot, and it helps to understand why before choosing a method. First, the sequence itself carries identifying information. Each person carries rare variants that few or no other individuals share, and related individuals share variants in predictable patterns, so a genotype can connect an individual to a family even when every name has been stripped. This is why European data protection frameworks treat genomic data as inherently identifiable rather than as data that could become identifiable if linked carelessly [1]. Second, the identifiability does not require the whole genome. A machine-learning system for livestock breed identification, built as the rPIMS platform, achieved 100 percent classification accuracy across 10 breeds using only 860 SNPs, demonstrating that a small panel of markers is enough to assign an individual to a known population group with high confidence [2]. The same principle applies to human data. Population structure, ancestry inference, and kinship analysis all work from subsets of markers, so an attacker with a reference panel and computing time can infer attributes from data that looks stripped on its face. Third, context multiplies risk. Phenotype data, geographic hints, unusual clinical features, and dates can narrow a cohort to a handful of people. Researchers in African genomics programs have flagged this combination of genotype, phenotype, and pedigree data as requiring careful control specifically to prevent identification of individuals or families, in a setting where the historical one-way flow of samples and data out of the continent has left communities wary of open release [3]. Institutions that inherit that wariness need methods that demonstrably limit what leaves the building. Fourth, individuals increasingly hold their own genomic data and make their own sharing decisions on platforms built around personal control of genotypes and health records. Researchers examining these web-based personal genomic data sharing initiatives found that participants are asked to balance risks and benefits individually, often with limited awareness of what identification actually implies for them and their relatives [4]. If your institution shares data that overlaps with such public uploads, linkage is possible whether or not you planned for it. The practical consequence for bioinformatics [data management](/blog/guides/data-management-basics-principles-processes-and-best-practices): plan de-identification as a layered system, not a single step. ## The Decision Framework at a Glance ![Decision path asking about consent, bulk transfer needs and dual-use risk, ending in a recommended sharing tier.](/article-images/illustrations/de-identification-methods-genomic-data-sharing-tier-choice.webp) Three axes drive the choice. 1. **Identifiability of what leaves your control.** Summary statistics leak less than variant calls, which leak less than raw reads. 2. **Analytical utility.** Every protection you add removes some analysis the recipient could have run. 3. **Control model.** Data can sit open, sit in an archive that screens requesters, stay inside your institution while users come to it, stay at each site while queries travel between sites, or be transformed before release. The table below is the core of the decision framework. Each row is one option, and the columns are the criteria that usually decide which option a project adopts. | Option | What leaves the institution | Re-identification risk | Analytical utility | Main weakness | Best fit | |--|--|--|--|--|--| | Direct identifier removal and generalization | Stripped files and recoded metadata | Moderate, falls with every extra step | High for most standard analyses | Pseudonymized genomes remain inherently identifiable | Any project, as the baseline layer | | Controlled-access sharing | Individual-level data, screened requesters only | Low to moderate, depends on requester vetting | Full, once access is granted | Vetting and agreements slow every request | Human cohort data under restrictive consent | | Federated analysis | Queries and results only, data never moves | Low, no bulk transfer | Moderate, limited to what the federation exposes | Query scope and pipeline harmonization limit discovery | Multisite clinical and rare-disease networks | | Secure enclaves | Nothing, analysts work inside | Low | High, within the enclave | Enclave hardware, audit, and staffing cost | Sensitive clinical and pipeline data at one institution | | Data transformation (read pooling, masking) | Deliberately obfuscated data | Low | Reduced, sample attribution is impaired | Some analyses become impossible | Dual-use or high-sensitivity sequence data | | Access logging and accountability | Nothing, records who did what | None directly | None | Logging is a control, not a release format | Every project, as a companion layer | The next sections explain each option on its own terms. ## Option 1: Direct Identifier Removal and Generalization This is the starting point for every de-identification methods genomic data sharing decision, because every other option assumes it has been done. **Direct identifiers** are fields that name a person or sample outright: name, medical record number, full ZIP code, email address, cell line identifier, accession-linked sample codes. **Quasi-identifiers** are fields that identify in combination: admission date, birth year, sex, diagnosis, sequencing date, even a photograph embedded in metadata. Removing direct identifiers and collapsing or generalizing quasi-identifiers is standard practice in large data management systems. A well-documented example is the Central Data Management system built for a large population-based medical research project, which combined automated extract-transform-load (ETL) integration of heterogeneous data sources with a multi-layered role and rights system for access control and with de-identification of identifying data, handling roughly 5 terabytes of participant-related data over a year and a half without data loss incidents [5]. In practice, the work goes deeper than the metadata table because genomic file formats carry identifiers inside them. - **BAM and CRAM files** contain read group records, written as @RG lines, which typically carry a sample name tag, library name, sequencing platform, and run identifier. Any of these can be a direct identifier. - **VCF and BCF files** carry sample names in the header and in the column structure, and may carry collector, contact, and source metadata in header lines. - **FASTQ files** embed flowcell, lane, and sample identifiers in every read name. - **File paths and archive directory trees** often encode enrollment site, study arm, or collection date. A competent de-identification pass walks every file format in the release, rewrites internal tags, and regenerates file names from the pseudonym scheme rather than renaming the outer file only. **Pseudonymization** means replacing direct identifiers with a code and keeping the linkage key in a separate, restricted location. **Generalization** means coarsening quasi-identifiers, for example collapsing exact ages into decade bands or rounding collection dates to months. A related concept from the data privacy literature, k-anonymity, generalizes quasi-identifiers so that every released record is indistinguishable from at least k-1 others on those fields. These steps materially reduce risk from metadata linkage, and they cost little utility for most downstream work. What this option cannot do is change the sequence itself. After the best identifier scrubbing, the genotype data remain inherently identifiable in principle, which is exactly why the other options exist. ## Option 2: Controlled-Access Sharing ![Flowchart from data submission through access request, agreement and secure delivery, with a rejection branch and audit logging.](/article-images/illustrations/de-identification-methods-genomic-data-sharing-controlled-access-pipeline.webp) Controlled access means the data sit in an archive, and requesters must satisfy defined criteria before they can retrieve anything. The archive substitutes an institutional review of purpose for the individual's loss of control that open release would entail. The mechanics matter more than most projects expect, because the controlled-access process itself is a pipeline. The DS-PACK tool assembly, developed to support controlled access sharing under the EU General Data Protection Regulation, semi-automates the process end to end, from data submission through access requests, agreements, and secure delivery. Its design centralizes access control management while distributing access control enforcement, so each hosting node enforces decisions locally, and it runs in production at the ELIXIR Luxembourg data hosting platform alongside operational roles for legal facilitation and data stewardship [6]. The lesson from that deployment is that controlled access is an operational commitment: someone must run agreements, track approvals, and maintain the enforcement machinery, and institutions that lack resources for that machinery are exactly the ones the middleware was built for. Pros of controlled access: - Retains full analytical utility, since approved users get the real data. - Aligns with restrictive or re-consent-based consent frameworks, which funders and journals in large genomics initiatives commonly expect to be honored through open or controlled data access mechanisms [3]. - Creates an accountability trail, since every release is tied to a named requester and an agreement. Cons: - Latency. Every request is a review cycle. - The archive itself becomes a target, because it concentrates genomes in one place. - Once an approved user has the data, the archive cannot control copying, and re-identification risk shifts to the user's environment. ## Option 3: Federated Analysis Federated models invert the traditional archive. Instead of moving genomes to the question, the question moves to the genomes. Data stay at the producing institution, and a central node supports discovery and coordinates queries against distributed nodes. WiNGS-API is a worked example for rare-disease gene discovery. Deployed across seven centers, the platform manages more than 6,400 samples with single-nucleotide variant (SNV) calls, 1,500 with copy-number variant (CNV) calls, and 500 with [structural variant](/blog/guides/structural-variant) (SV) calls from [long-read sequencing](/knowledge/bioinformatics/long-read-sequencing-technologies-pacbio-and-oxford-nanopore). It supports sample-based variant interpretation and automated trio-based filtering that reduces candidate de novo variants for clinical review. The motivation is explicit: data protection frameworks such as the GDPR treat genomic data as inherently identifiable and impose strict limits on central transfer, so the platform shares variant-level results across institutions without centralizing the underlying data [1]. Federated querying lets partners find additional carriers of a candidate variant and identify likely false positives, outcomes that are difficult to reach when each site sees only its own patients. Pros: - The highest-risk asset, the bulk genome data, never leaves the generating institution. - Each node applies its own access rules and data protection compliance, which fits GDPR-style obligations directly [1]. - Enables pooled discovery across sites for problems, such as rare variant interpretation, that no single site can answer alone [1]. Cons: - The set of analyses is limited to what the federation's query layer exposes. Arbitrary workflows do not run remotely. - Pipeline differences across sites can produce spurious differences between nodes. Harmonizing variant calling is a real prerequisite, and systems such as ONCOLINER exist precisely to monitor and harmonize somatic variant calling across centers, improving recall and precision for SNVs, indels, and structural variants across pipelines before results are compared [7]. - Building and joining a federation is a coordination project, not a software install. ## Option 4: Secure Enclaves and Trusted Research Environments A secure enclave brings the analyst to the data. Compute, storage, and analysis all happen inside a controlled environment, and only reviewed outputs leave. A detailed case is the secure computing environment built at Weill Cornell Medicine, described with respect to user access, data controls, hardware, software, audit, and financial considerations. In its first two and a half years the environment supported more than 200 faculty, staff, and students across nearly 60 research and education projects, covering sensitive electronic health record, claims, and genomic pipeline data [8]. The case report is useful because it treats the enclave as a whole system: controlling what users can bring in and take out, recording what they do, and budgeting for the ongoing cost of running the environment. Pros: - Strong control over both ingress and egress, which is what actually limits re-identification attempts on sensitive data. - Full analytical utility inside the walls, unlike federated query interfaces. - Auditing is natural, since every session is already inside an instrumented environment. Cons: - Real infrastructure cost and staffing. The Weill Cornell case explicitly lists financial considerations among its design factors, and institutions adopting the approach need to budget for hardware, review workflows, and support staff [8]. - Friction for analysts, who must work within enclave rules rather than on their own laptops. - Output review can become a bottleneck if export requests are frequent. Enclaves and controlled-access archives are complements, not substitutes. Many programs place the archive behind enclave-style access, so even approved users never download a copy. ## Option 5: Data Transformation Methods When even controlled release is too much, transform the data before it leaves. Several families of transformation exist, and they trade utility for safety in different places. **Read pooling** is the approach described for dual-use genetic data. The concern there is severe: a pathogen genome sequence can enable malicious genetic engineering or even reconstruction of the organism from synthetic DNA, and standard security controls are difficult to enforce when data move between many institutions internationally. The proposed method obfuscates raw sequence data by pooling reads from multiple samples of the same organism into one shared dataset. The demonstrated result is that full reconstruction of any individual sample is prevented, most genomic information remains available, and individual reads or mutations cannot be attributed to a specific contributing sample [9]. For pathogen surveillance, where lineage-level patterns matter more than any single isolate's complete genome, this is a defensible trade. **Variant-level transformations** include masking specific variant positions, limiting release to summary statistics such as allele counts and aggregate association results, and withholding kinship-informative regions. These are established practice in human genomics and cost utility in ways you can predict: summary-level release supports replication and meta-analysis but not per-sample discovery, and masked regions cannot be interrogated at all. **Generalization to fixed panels**, for example releasing only results from a defined SNP array or a prespecified marker set, bounds what an attacker can learn from the release while keeping the released markers fully interpretable. Pros: - Directly reduces what the data can reveal, rather than relying on requester behavior. - Read pooling works at rest and during transfer, so the protection travels with the file [9]. Cons: - Every transformation is irreversible loss of some analyses. - Sampling-level pooling of pathogen reads assumes contributors are the same organism and comparable sequencing conditions, which limits where the method applies [9]. - Transformation choices are hard to reverse if downstream users later need the withheld detail. ## Option 6: Logging, Audit, and Accountability Audit logging changes nothing about the data, yet it belongs in every option column above, because it is what turns a promise of controlled use into an enforceable record. One line of work tackles a specific weakness of conventional logs: single points of failure. A blockchain-based solution developed for the iDASH secure [genome analysis](/blog/guides/genome-analysis) competition used the MultiChain platform's data streams to record user activity accessing genomic datasets across multiple sites, with a storage protocol built on the stream keys that allowed efficient querying of the resulting log. The solution won its competition category, and the authors note a practical drawback in how the ledger must be accessed [10]. The generalizable point is that tamper-resistant, distributed access logs protect the audit trail itself, which matters when the log is your evidence of compliance. A second accountability angle is understanding downstream use. The Data Citation Explorer, developed for the US Department of Energy Joint Genome Institute, automatically discovers literature that incorporated deposited genomic data even when the data were not formally cited, providing metadata enrichment, documentation of new use cases, and improved credit attribution for data generators, which in turn encourages sharing by making reuse visible [11]. Programs that can show how shared data are being reused have an easier time defending continued investment in sharing infrastructure. ## Comparing the Options on the Criteria That Decide Real Choices The table above summarizes the options. This section works through the trade-offs in words, because the pros and cons interact. ### Re-identification risk Ranking options by residual risk is easiest in two steps. Identifier removal alone leaves the highest residual risk of the active methods, because the sequence data remain inherently identifiable [1] and linkage against other datasets only gets easier over time. Controlled access and secure enclaves reduce risk primarily through behavior control, requester vetting and egress review, which is effective as long as vetting is real. Federated designs reduce risk structurally, since there is no bulk data transfer to intercept or leak, which is the core argument made for the WiNGS-API model under GDPR [1]. Read pooling is the only option that changes the sequence data themselves, and its protection is concrete, blocking full reconstruction of any single sample [9]. One subtlety: risk is not static. A release that seemed low risk ten years ago can be re-identified today against reference panels and public datasets that did not exist when the data were shared. Plan for reassessment. ### Analytical utility Utility is where options separate sharply. Identifier removal and generalization cost almost nothing for standard analyses. Controlled access and enclaves preserve everything for approved users. Federated designs preserve a defined subset, and the ONCOLINER experience shows that cross-center comparisons require active harmonization of [variant calling pipelines](/knowledge/bioinformatics/variant-calling-pipelines-gatk-deepvariant) before they are trustworthy [7]. Read pooling preserves most genomic information while destroying sample attribution, which suits population and surveillance questions and rules out per-sample conclusions [9]. A common planning error is to pick the method first and the analysis second. Work the other direction: enumerate the analyses downstream users must run, then find the least identifiable format that still supports them. ### Consent and legal fit Consent text should drive the option, not trail it. Personal genomic data sharing initiatives show what happens when individuals are left to weigh these trade-offs alone, often with limited grasp of the implications [4]. Institutional data under narrow consent generally require controlled access or federation rather than open release, and funders and journals that require deposition into open or controlled access databases leave the choice of tier to exactly this consent analysis [3]. Governance obligations also reach past the release. Work on benefit sharing for legacy samples from low- and middle-income countries entering high-value translational uses found that sample anonymization itself complicates the delivery of fair benefits to communities, because once individuals cannot be traced, returning value to them becomes harder [12]. Anonymizing data is not governance-neutral, and programs with community commitments should decide how those commitments survive de-identification before the linkage keys are destroyed. ### Operational burden Burden scales differently per option. Identifier removal is engineering work with a clear endpoint. Controlled access requires standing processes for agreements and vetting, which is why reusable middleware such as DS-PACK exists and why it bundles legal facilitation and data stewardship into its operating model [6]. Enclaves require hardware, staff, and a budget line, as the Weill Cornell case documents [8]. Federations require multi-institution coordination and shared pipeline standards [1]. Transformation methods require bioinformatics development per release. Logging requires storage design and retention policy, and blockchain-based designs trade operational simplicity for tamper resistance [10]. ## Worked Scenarios **Scenario 1. A rare-disease consortium across seven clinical centers.** Each center holds paired genome and phenotype data under clinical consent. Centralizing 6,000-plus genomes in one archive is a data protection problem under frameworks that treat genomic data as inherently identifiable. The federation pattern fits: variant-level calls are exposed through a shared interface, data never move from the source institutions, and automated trio-based filtering reduces candidate de novo variants for review across the network [1]. The prerequisite investment is pipeline harmonization so that a variant missed at one center is a real negative and not a pipeline artifact [7]. **Scenario 2. A population cohort with broad consent feeding public archives.** Consent supports open deposit, but the cohort includes rare phenotypes and pedigrees that could identify participants and relatives [3]. The stack looks like this: full identifier scrubbing and internal tag rewriting across every file format, generalization of dates and geography, deposit into a controlled-access tier for individual-level data with an open tier for aggregate results, and pseudonym keys held in a segregated vault modeled on the Central Data Management pattern with role-based access [5]. Audit logging covers every download. **Scenario 3. Pathogen sequencing data with dual-use potential.** An international surveillance network wants raw sequencing data flowing quickly during outbreak response, but full individual sample genomes could enable reconstruction or malicious engineering [9]. The fit is read pooling: reads from multiple samples of the same organism are combined into one shared pool that preserves most genomic information for lineage tracking while preventing reconstruction of any single sample [9]. The network pairs this with tamper-resistant access logging across sites, the property that motivated the blockchain ledger approach [10]. **Scenario 4. A small research group with no dedicated data infrastructure.** The group wants to share human genomic data but cannot staff a full controlled-access operation from scratch. The realistic path is to adopt reusable middleware that semi-automates submission, access requests, agreements, and secure access, on the DS-PACK pattern, rather than hand-building processes, and to lean on the host platform's data stewardship roles for the legal work [6]. ## Storage and Management Practices That Support De-identification De-identification is downstream of good bioinformatics data management. Several practices determine whether any of the options above are even executable. **Separate the identifying vault from the analysis zone.** The Central Data Management model kept identifying data behind a multi-layered role and rights system while analysis data flowed from de-identified pipelines [5]. The key point is physical and logical separation of the linkage key from the data being shared. If the key lives in the same directory tree as the genotypes, one misconfigured sync job defeats everything. **Automate capture and transformation with ETL pipelines.** Manual identifier scrubbing does not scale and does not audit. The documented pattern uses automated ETL software and structured electronic case report forms to integrate decentralized, heterogeneously captured data, with quality assurance checks built into capture and storage [5]. The same automation should apply identifier rewriting at the point data leave the vault, so that de-identification is a pipeline stage rather than a hope. **Build genomics data storage for integrity and reproducibility.** Immutable storage with versioning and checksums for released datasets, stable sample pseudonyms that persist across releases, and metadata that document the de-identification steps applied are the minimum. The Data Citation Explorer illustrates the payoff of good metadata on the consumption side: automated discovery of publications reusing deposited data depends on consistent resource metadata, and it improves credit attribution for data generators [11]. **Harmonize before you share.** Heterogeneous pipelines across centers limit the value of any shared dataset and can even create conflicting metadata. Assessing and aligning variant calling across pipelines before release, as the ONCOLINER approach demonstrates for somatic SNVs, indels, and structural variants, makes the shared data trustworthy and reduces the temptation for recipients to request the raw, more identifiable data instead [7]. ## Common Mistakes and Limitations - **Treating pseudonymization as anonymization.** Replacing names with codes changes nothing about the inherent identifiability of the sequence itself [1]. Pseudonymized genomic data should be handled as personal data. - **Scrubbing only the outer metadata.** Read group tags in BAM headers, sample columns in VCF files, identifiers embedded in FASTQ read names, and file path structures all carry identifiers. A release that rewrote the manifest but not the files is not de-identified. - **Generalizing until the data are useless.** Over-coarsened phenotypes and dates can satisfy a checklist while destroying the scientific value that justified sharing. Define the required analyses first, then generalize to the coarsest level that supports them. - **Sharing under the wrong tier.** Depositing narrowly consented human data into an open archive because deposit was convenient contradicts the consent framework that funders and journals expect to be honored through open or controlled access mechanisms [3]. - **Assuming de-identification is a one-time event.** Re-identification risk grows as reference datasets and linkage tools accumulate. Releases need scheduled risk reassessment, not a single sign-off. - **Destroying the linkage key without thinking through governance.** Anonymization can complicate commitments that depend on tracing data or samples back to communities, including benefit-sharing obligations to the people who contributed them [12]. - **Concentrating risk in a single archive and single log.** A centralized archive with a conventional access log is a single point of failure for both the data and the evidence of who touched them. Distributed access logging addresses the log half of that problem [10]. - **Skipping harmonization and calling it privacy.** Releasing incomparable variant calls across sites is a quality failure masquerading as a data management decision, and it pushes users toward demanding raw data [7]. - **Relying on one layer.** Every option above has a failure mode. Identifier removal cannot anonymize the sequence, access control depends on vetting, federation depends on query design, and transformation depends on the threat model holding steady. Layered controls are the actual best de-identification method for genomic data sharing, not any single technique. ## Frequently Asked Questions ### Can genomic data ever be fully anonymous? No. A genome is inherently identifiable because its rare variants are unique to an individual and shared with relatives in predictable patterns, which is why European data protection frameworks classify genomic data as personal data. Treat every de-identification method as risk reduction, not risk elimination. ### What is the best de-identification method for genomic data sharing? There is no single best method, because the right choice depends on data sensitivity, the analyses downstream users need, and the consent under which the data were collected. The strongest programs layer identifier removal with a controlled or federated access model, appropriate data transformation where needed, and audit logging. ### Is removing names and medical record numbers enough? No. Names and medical record numbers are direct identifiers, but dates, geography, rare phenotypes, and the sequence data itself can still identify a person, especially through linkage with other public datasets. Direct identifier removal is the first step of de-identification, not the last. ### How does federated sharing differ from controlled-access sharing? In controlled-access sharing, vetted users retrieve individual-level data from a central archive. In federated sharing, data stay at each producing institution and queries or variant-level results travel between sites instead. Federated models avoid bulk transfer but limit which analyses a remote user can run. ### Can I share VCF files openly if I strip the sample names? Only if the consent framework and a documented risk assessment both support open release. Sample names are just one identifier, and variant calls can still reveal rare phenotypes, relatedness, and population structure, so open release of individual-level calls should be rare and deliberate. ### Who is responsible if shared genomic data are misused? Responsibility is normally shared among the data producer, the archive or hosting platform, and the approved user, as defined in data use agreements and access policies. Strong access control, tamper-resistant audit logs, and clear terms of use strengthen an institution's position, but no combination of controls eliminates the risk. ## Sources 1. [WiNGS-API: a federated genome/phenome data sharing platform enabling gene discovery and variant classification for rare diseases.](https://pubmed.ncbi.nlm.nih.gov/41888929/) 2. [rPIMS: a ShinyR package for the precision identification and modelling of livestock breeds using genomic data and machine learning approaches.](https://pubmed.ncbi.nlm.nih.gov/40330626/) 3. [Ethical and legal implications of whole genome and whole exome sequencing in African populations.](https://pubmed.ncbi.nlm.nih.gov/23714101/) 4. [Challenges of web-based personal genomic data sharing.](https://pubmed.ncbi.nlm.nih.gov/26085313/) 5. [Efficient data management in a large-scale epidemiology research project.](https://pubmed.ncbi.nlm.nih.gov/21256617/) 6. [DS-PACK: Tool assembly for the end-to-end support of controlled access human data sharing.](https://pubmed.ncbi.nlm.nih.gov/38750048/) 7. [ONCOLINER: A new solution for monitoring, improving, and harmonizing somatic variant calling across genomic oncology centers.](https://pubmed.ncbi.nlm.nih.gov/39216474/) 8. [Design and Implementation of a Secure Computing Environment for Analysis of Sensitive Data at an Academic Medical Center.](https://pubmed.ncbi.nlm.nih.gov/30815128/) 9. [Methods for safely sharing dual-use genetic data.](https://pubmed.ncbi.nlm.nih.gov/41756120/) 10. [Using blockchain to log genome dataset access: efficient storage and query.](https://pubmed.ncbi.nlm.nih.gov/32693796/) 11. [Identifying genomic data use with the Data Citation Explorer.](https://pubmed.ncbi.nlm.nih.gov/39505888/) 12. [From Acceptable Profit to Fair Return: Operational Benefit-Sharing Models for Induced Pluripotent Stem Cell Research Using Legacy Samples from Low- and Middle-Income Countries.](https://pubmed.ncbi.nlm.nih.gov/42620415/)