# UniProt Disease Annotation Records - Target Map (`nexgensignal/uniprot-disease-annotation-records`) Actor

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.

- **URL**: https://apify.com/nexgensignal/uniprot-disease-annotation-records.md
- **Developed by:** [NexGen Signal](https://apify.com/nexgensignal) (community)
- **Categories:** Business, Developer tools
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $33.50 / 1,000 disease annotation records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## UniProt Disease Annotation Records - Target Map

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](https://api.apify.com/v2/key-value-stores/IXCaMKjxSmUTLHhmq/records/uniprot-disease-annotation-records.png)

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

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

```json
{
  "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.

# Actor input Schema

## `maxRecords` (type: `integer`):

Maximum records delivered and billed. You are billed only for records actually delivered. Raise it to pull the full set.

## Actor input object example

```json
{
  "maxRecords": 500
}
```

# Actor output Schema

## `results` (type: `string`):

The delivered UniProt disease annotation record.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "maxRecords": 500
};

// Run the Actor and wait for it to finish
const run = await client.actor("nexgensignal/uniprot-disease-annotation-records").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "maxRecords": 500 }

# Run the Actor and wait for it to finish
run = client.actor("nexgensignal/uniprot-disease-annotation-records").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "maxRecords": 500
}' |
apify call nexgensignal/uniprot-disease-annotation-records --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,nexgensignal/uniprot-disease-annotation-records"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/iFcGjn3EawanwTM39/builds/3igetpEi6mcn7NxAU/openapi.json