BGPT: Paper Review: The Breast Cancer Information Core: Database design, structure, and scope

Explore by Goal

Quick Explanation Copied

BIC (1995–2000) as a blueprint for locus-specific mutation databases

This paper documents the Breast Cancer Information Core (BIC): an open-access (to registered members) web mutation database focused on BRCA1/BRCA2, including mutation catalogs, recommended primers/protocols, and visualization + curated data-entry workflows. The design explicitly addresses nomenclature discrepancies and “distinct mutation” counting to reduce overcounting from inconsistent repeat-region labeling and ambiguous STR deletions .

Main limitations: the paper states curator-only manual checking, incomplete metadata fields, lack of formal journal scanning (potential lag), and difficulty avoiding bias/duplication unless contributor identifiers are consistently provided .

Long Explanation

Paper Review — The Breast Cancer Information Core: Database design, structure, and scope

Source: Human Mutation paper describing BIC’s database architecture, data model, curation workflow, and visualization tooling (accepted revised manuscript 21 Apr 2000; “BIC established in 1995”) .

What this paper is really about (data systems, not biology experiments)

BIC is presented as a mutation + polymorphism repository for breast cancer susceptibility genes (especially BRCA1/BRCA2), combining:

Cataloging of genetic variants from breast/ovary cancer patients (germline and somatic included) .
Technical support (mutation detection protocols, recommended primers, and reagent access) .
Curation + validation using redundancy at nucleotide and amino-acid descriptor level, but (at the time) manual checks by a curator .
Visualization of mutation distributions across sequence coordinates with click-to-zoom behavior .

Key quantitative snapshot (reported as of April 2000)

The paper reports 3,416 BRCA1 variant entries and 2,292 BRCA2 variant entries, along with intronic sequence compilations, PCR primers, and eight mutation detection protocols .

Data access model & governance

Password-protected membership is used to ensure registrants accept guidelines on participation, data entry, confidentiality, data use, and acknowledgement; importantly, the authors state this requirement is uncommon among locus-specific databases and is used to protect contributors of unpublished information while emphasizing research-only use (not for clinical decision making) .

For reproducibility in the computational sense, the paper also clarifies that scripts/software technical details are not included but can be provided on request .

Core data model: structure & fields

The paper describes separate mutation databases for BRCA1 and BRCA2, each depicted as a gene image with exon-specific hyperlinks into mutation records. Mutation records are flat files with 24 fields per entry .

Field group (as described)	Examples from Table 1 (verbatim concepts)
Identifiers	Accession number; unique identifier generated at entry time; creation date .
Variant coordinates	Exon; cDNA nucleotide (# with gene reference sequences); gDNA nucleotide (# with BRCA1 genomic reference); codon number (ATG=+1) .
Change consequences	Base change; amino acid change; mutation designation; mutation type/effect categories .
Provenance	Depositor; literature reference; contact person (email); patient sample source; patient ID number .
Phenotypic/experimental context	Proband tumor type; germline vs somatic; detection method; chromosomes screened; ethnicity/nationality; frequency of polymorphism if known .
Mutation interpretation metadata	Notes; ‘Mutation designation’ retained even when nomenclature standard changes for common repeat-region mutations .

Nomenclature issues: the paper’s most “scientifically critical” design section

The paper explicitly uses HUGO nomenclature recommendations for mutation designation but documents a key departure: BIC’s cDNA numbering starts at nucleotide #1 being the first nucleotide of the GenBank entry (not at the “A” of the ATG start codon as in the HUGO system) .

For repeat-region indels (STRs), the paper identifies STR unit ambiguity (which specific repeat was deleted) as a major source of discrepancies and gives the BRCA1 185delAG vs 187delAG example while stating that consequences at the amino-acid level are the same (frameshift/truncation) .

It then defines “distinct mutation” to avoid conflating recurrent-by-state vs founder-by-descent issues: two entries are “distinct” if they differ in key fields, which is framed as a practical solution for counting distinct alterations in exon summaries .

Importantly, it warns that accurate distinct-counting depends on consistent nomenclature for identical nucleotide-level mutations, but notes earlier identifications predate current guidelines, so some common mutations have ambiguous nomenclature that is retained to avoid confusion in literature .

Bias & blind spots explicitly acknowledged (and the practical impact)

Sampling/ascertainment bias: The paper states that because only probands/tumor samples where mutations have been identified are recorded, the database cannot determine what proportion of high-risk families or tumor samples are attributable to mutations in either gene .

Completeness bias: Contributor-requested fields include proband tumor type, chromosomes screened, and ethnicity/nationality, but the paper says these are “frequently incomplete,” limiting downstream analyses .

Lag / coverage bias: There is no formal journal scanning system; the paper predicts a lag behind literature growth and suggests submission around acceptance plus editor alerts .

Redundancy/duplication bias: The paper emphasizes the need to link each mutation to a unique individual/sample identifier because the data is culled from several sources (literature + direct submissions) .

Systems engineering critique (skeptical review)

Strength: explicit nomenclature strategy. The paper’s accounting for HUGO departure and STR ambiguity is a major design win because it anticipates a common failure mode in mutation databases: coordinate-system drift and repeat labeling inconsistencies .
Strength: “distinct mutation” as a pragmatic counting formalism. While not a substitute for genotyping provenance (founder vs recurrent), defining “distinct” via key-field differences is an attempt to make summary counts more robust to nomenclature ambiguity .
Red flag: manual validation and manual scheduling. The database initially uses a curator’s manual checks; it also processes updates in bulk every other month (with some entries appearing within days and others >1 month). This creates variable latency and potential inconsistency in quality control .
Red flag: reproducibility constraints. The authors do not include technical details about scripts/software in the manuscript, although they may be provided on request. For computational reproducibility, this is a weakness because pipeline details can affect derived summaries and graphics .
Potential blind spot: conditional comparability across time. As nomenclature guidelines evolve, earlier common mutations retain older labels to avoid confusion. That is pragmatic for interpretability for humans, but it can complicate computational harmonization unless crosswalk fields exist (the paper mentions adding a future field for equivalent HUGO designations) .

What a user should do with this database design (practical use)

If you are using BIC for downstream mutation distribution analyses, the paper implies you should:

Track coordinate systems. BIC cDNA numbering deviates from standard HUGO start-codon-based numbering .
Use “distinct mutation” summaries carefully. Distinct counts are defined by key-field differences rather than an explicit founder-vs-recurrent decomposition .
Assess metadata completeness. Missing ethnicity/tumor-type/chromosomes-screened fields can silently limit stratified conclusions .

Optional visual: field categories map (conceptual)

The paper’s Table 1 can be treated as a structured schema for mutation records. The map below groups table entries into coordinate, identity, effect, provenance, and experimental/clinical context as described .

Note: the slice sizes are schematic (conceptual grouping of described field types), not a claim about counts of actual rows beyond what is explicitly listed in Table 1 .

Future prospects noted by authors (as of this 2000 design paper)

They mention expansion plans for additional breast cancer susceptibility genes (e.g., p53, ATM, PTEN databases and links via HGMD) . It also describes a planned haplotype database structure for founder mutations, allowing incorporation of microsatellite and SNP marker data .

What would falsify (or materially change) this paper’s implications?

Since this is a database-design/scope paper rather than a hypothesis-testing study, the “falsification” targets are operational claims:

If the database’s nomenclature handling failed to reduce discrepancies across repeat regions (e.g., producing inconsistent exon-level “distinct” counts), then the claimed robustness of summaries would be weakened .
If curator-only manual checking produced systematic errors (or failed to validate redundant descriptors), then the practical value of the “built-in redundancies” validation workflow would be undermined .

Go deeper on BGPT (author reviews)

Feedback:

Updated: March 22, 2026