UniProt Disease Annotation Records - Target Map avatar

UniProt Disease Annotation Records - Target Map

Pricing

from $33.50 / 1,000 disease annotation records

Go to Apify Store
UniProt Disease Annotation Records - Target Map

UniProt Disease Annotation Records - Target Map

UniProtKB disease annotations (cc_disease) as clean per-association records - accession x disease accession/name/MIM id/description, with gene, protein and organism. Disease block is the core. No author fields. CC BY 4.0, $0.05 per record.

Pricing

from $33.50 / 1,000 disease annotation records

Rating

0.0

(0)

Developer

NexGen Signal

NexGen Signal

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

11 hours ago

Last modified

Share

UniProt's disease annotations as a clean, per-association reference - one record per protein-disease link. Every UniProtKB entry that carries a disease annotation is expanded so each linked disease is its own row, with the disease block (UniProt disease accession, name, acronym, description, cross-reference and involvement note) as the emitted core, joined to the protein's accession, gene and organism.

What one record represents

The source is UniProt (the UniProtKB REST API), filtered to cc_disease:* - entries with a disease involvement annotation. A single protein can be linked to several diseases, so this Actor emits one record per protein-disease association: the protein's accession, entry name, protein and gene names, organism and review status, then the disease itself - UniProt disease accession (DI-...), disease name, acronym, description, the cross-reference (typically the OMIM/MIM id) and the involvement note.

This is a disease-target mapping, and it is deliberately a different grain and a different core from the fleet's other UniProt cells, which emit one row per protein and carry no disease fields.

Sample output

Sample output — UniProt Disease Annotation Records - Target Map

Real rows from a live run of this actor (first 5 rows, selected columns).

One full record from the same run, exactly as delivered:

{
"accession": "A0A1B0GTW7",
"entry_name": "CIROP_HUMAN",
"protein_name": "Ciliated left-right organizer metallopeptidase",
"gene_names": "CIROP",
"organism": "Homo sapiens",
"organism_id": 9606,
"reviewed": true,
"protein_existence": "1: Evidence at protein level",
"disease_accession": "DI-06243",
"disease_name": "Heterotaxy, visceral, 12, autosomal",
"disease_acronym": "HTX12",
"disease_description": "A form of visceral heterotaxy, a complex disorder due to disruption of the normal left-right asymmetry of the thoracoabdominal organs. Visceral heterotaxy or situs ambiguus results in randomization of the placement of visceral organs, including the heart, lungs, liver, spleen, and stomach. The organs are oriented randomly with respect to the left-right axis and with respect to one another. It can be associated with a variety of congenital defects including cardiac malformations. Early death may occur. HTX12 inheritance is autosomal recessive.",
"disease_cross_ref_db": "MIM",
"disease_cross_ref_id": "619702",
"disease_note": "The disease is caused by variants affecting the gene represented in this entry",
"record_id": "A0A1B0GTW7:DI-06243",
"source": "UniProt (UniProtKB)",
"source_query": "cc_disease:* (UniProtKB entries with a disease annotation)",
"licence": "UniProt (UniProtKB), CC BY 4.0. Attribution required; reproduced from the UniProt REST API, values unmodified. No literature-author, submitter or contact field is read.",
"attribution": "UniProt Consortium (https://www.uniprot.org)",
"caveat": "One record per protein-disease association: a UniProtKB entry with a disease annotation, expanded so each linked disease is its own row (accession x disease). The disease block - UniProt disease accession, name, acronym, description, cross-reference (e.g. MIM) and involvement note - is the emitted core. All cc_disease entries are reviewed (Swiss-Prot), so these accessions are a subset of the reviewed-protein cell; distinctness is the disease annotation block and the per-disease grain, which no other UniProt cell carries.",
"observed_at": "2026-09-25T17:27:07Z"
}

Coverage and volume

The live cc_disease:* set is 5,881 UniProtKB entries (measured at build time from the API's x-total-results), which expand into a larger number of protein-disease association records because many proteins are linked to more than one disease. Every one of these entries is reviewed (Swiss-Prot); the annotation is manually curated.

Sol's Wave-3 index put this door at about 5,870 records; measured live at build time the cc_disease:* set is 5,881 entries - the live figure is what this listing quotes.

The Actor pages the UniProt REST API using its cursor (the Link header's rel="next"), 500 entries at a time, and stops as soon as your Maximum records cap is met.

Distinctness from the other UniProt cells

This is the key point, stated plainly. Because every disease-annotated entry is reviewed, the accessions here are a subset of the reviewed-protein cell (all 5,881 are reviewed); about 5,341 are human (and so also appear in the human-proteome cell) and about 1,852 carry an EC number (and so also appear in the enzyme cell). What makes this a distinct product is not the set of proteins but the disease annotation block - disease accession, name, MIM cross-reference and involvement note - which none of the other UniProt cells emit, and the per-disease grain: one row per protein-disease link rather than one row per protein. If you want the disease-to-target mapping, this is the only cell that carries it; if you want the protein records themselves, use the reviewed, human or enzyme cells. Stating the overlap on the record means you can combine the cells without double-counting.

Licence and attribution

UniProt data is released under Creative Commons Attribution 4.0 (CC BY 4.0) - free to use and redistribute with attribution. The full notice travels on every record:

UniProt (UniProtKB), CC BY 4.0. Attribution required; reproduced from the UniProt REST API, values unmodified. No literature-author, submitter or contact field is read.

The required attribution - UniProt Consortium (https://www.uniprot.org) - is present on every record.

Person-data policy

This Actor requests only protein, gene, organism and disease-annotation fields. The disease description is a clinical description of the disease, not of any individual. UniProt's literature-references section with author and submitter names is never requested and never delivered, and a per-record assertion rejects any author, submitter, contact or patient field (verified with a planted-field test). No natural-person data is processed.

Interpretation caveat

One record per protein-disease association: a UniProtKB entry with a disease annotation, expanded so each linked disease is its own row. The disease block (UniProt disease accession, name, acronym, description, MIM cross-reference, involvement note) is the emitted core. All cc_disease entries are reviewed, so these accessions are a subset of the reviewed-protein cell; distinctness is the disease block and the per-disease grain.

Values are reproduced verbatim from the API; the Actor never rewrites a field. The disease cross-reference is usually the OMIM (MIM) identifier, which lets you join onto disease ontologies and clinical databases. A protein with no disease name but a disease accession leaves disease_name null, which is faithful to the source.

Data quality and freshness

reviewed is a real boolean and organism_id a real number. The record_id composes the accession and the disease accession, so every association is uniquely keyed and the dataset is safe to diff, deduplicate or upsert. Every run re-reads the live API, so the data is as fresh as UniProt publishes, and each record's observed_at stamp dates the snapshot. The run's RUN_RECEIPT records the total entry count alongside how many association records were delivered and charged.

Provenance and compliance

Every run reads rest.uniprot.org/robots.txt at runtime; the gate result (URL, status, byte length, SHA-256 of the policy) is written to the run's RUN_RECEIPT, and the search path is confirmed crawlable before any data request. The API is keyless. The Actor never bypasses a block or fetches through a mirror.

Inputs

  • Maximum records (maxRecords) - hard cap on disease-association records delivered and billed.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview view surfaces accession, disease name, acronym, MIM id, protein name, gene and organism.

Fields in detail

The record leads with accession and entry_name, the protein context (protein_name, gene_names, organism, organism_id, reviewed, protein_existence), then the disease core - disease_accession, disease_name, disease_acronym, disease_description, disease_cross_ref_db, disease_cross_ref_id, disease_note. The provenance block closes every record. Because the accession is UniProt's stable primary key and the disease carries its MIM id, the dataset joins cleanly onto both protein systems and disease ontologies.

Typical uses

Drug-discovery and translational-research teams use this cell to build a disease-to-target table - which proteins are implicated in a given disease, with the OMIM id to join onto clinical genetics, and the involvement note to read the mechanism. Because the grain is the association, a single group-by on disease_cross_ref_id collects every protein linked to a disease, and a group-by on accession collects every disease linked to a protein. A scheduled run keeps the mapping current with UniProt's curation, and the composite key makes it safe to upsert.

Scaling and limits

Set Maximum records low to sample cheaply or high to pull the full mapping. The Actor pages the API with its cursor and delivers incrementally, so memory stays flat and you are billed only for what is delivered. The set is small and fully curated, so a single run captures the whole disease-target map; re-run to pick up new annotations.

How to read the disease block

Each record's disease block is self-contained. disease_name and disease_acronym are UniProt's own labels; disease_accession (the DI-... id) is UniProt's stable disease key, so two proteins linked to the same disease share it and group cleanly. disease_cross_ref_db/disease_cross_ref_id is almost always the OMIM (MIM) entry - the bridge to clinical-genetics resources. disease_description is the curated clinical description of the disorder, and disease_note records how this specific protein is involved (loss of function, a causative variant, a susceptibility factor). Reading the two together tells you both what the disease is and why this protein matters to it - the substance a bare protein record cannot give you. Because a protein often carries several disease annotations, the association grain keeps each link clean rather than cramming multiple diseases into one cell.

Sibling Actors

It sits beside the fleet's UniProt reviewed-protein, human-proteome and enzyme records - the same door at different grains. It shares its engineering - the runtime robots gate, cursor paging, push-then-charge billing and verbatim-value discipline - with the fleet's other UniProt records Actors, from which it stays distinct by leading with the disease annotation and the protein-disease grain rather than the protein summary.