# EU Clinical Trials (CTIS) - Trial Registry, Per Trial (`nexgensignal/eu-clinical-trial-ctis-records`) Actor

EU CTIS (EMA) clinical trials as clean per-trial records - EU CT number, title, status, sponsor org, phase, member states, condition and decision date. Registry metadata only; no contacts or narrative. $0.05 per record.

- **URL**: https://apify.com/nexgensignal/eu-clinical-trial-ctis-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 ctis trial 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?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
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.
Actors are written with capital "A".

## 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.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## EU Clinical Trials (CTIS) - Trial Registry, Per Trial

Every clinical trial in the EU's **Clinical Trials Information System (CTIS)** as one clean, flat record -
EU CT number, title, status, sponsor organisation, phase, member states, condition, therapeutic areas,
demographics and decision date. Registry metadata only: **no sponsor contacts, no investigator names, no
narrative free-text.**

### What one record represents

The source is **EU CTIS** (`euclinicaltrials.eu`), the European Medicines Agency's clinical-trials registry,
read from its keyless public search endpoint. Each record is **one trial**: its EU CT number, full and short
title, status, sponsor organisation and sponsor type, trial phase, the member states involved, the medical
condition studied, MedDRA therapeutic areas, eligible age group and sex, planned enrolment, and the
authorisation decision date(s).

### Coverage and volume

The registry holds **12,353** trials - measured live at build time from the search endpoint's `totalRecords`.

**Sol's Wave-4 index put this door at 12,353 EXACT; measured live at build time the endpoint reports 12,353 -
matching the index.**

The Actor pages the search endpoint 100 trials at a time and stops as soon as your **Maximum records** cap is
met.

### Licence and attribution — third-party content

This is the defining compliance point. Per the EMA legal notice, reproduction is authorised, **including for
commercial purposes, provided the source is acknowledged** - but that permission does **not** extend to
third-party content. The EMA notice states, verbatim:

> The above-mentioned permissions do not apply to content supplied by third parties. Therefore, for documents where the copyright vests in a third party, permission for reproduction must be obtained from the copyright holder. (EMA legal notice)

To honour that clause, this Actor emits **only EMA-generated structured registry metadata** at the trial grain.
The sponsor-authored narrative and free-text fields (endpoint descriptions, eligibility criteria) - the content
most likely to carry third-party copyright - are **structurally excluded**: they are never requested and never
delivered. The per-trial detail endpoint, which carries sponsor and site contact persons, is never fetched. A
per-record assertion rejects any narrative, endpoint, contact or person field (verified with a planted-field
test). The result is the factual registry record - the same class of trial-registry fields published for every
trial - with no third-party documents and no personal data.

### Person-data policy

No sponsor contact, no principal-investigator or site-contact name, and no narrative field is ever in the query
or the output. The sponsor is delivered as an **organisation** (e.g. "LYSARC"), not a person. No natural-person
data is processed.

### Distinctness from ClinicalTrials.gov

About **40%** of CTIS trials are also registered on ClinicalTrials.gov (the research seat's estimate), but the
two are distinct products: this cell carries the **EU registry identity** - the EU CT number, EU member states
and EU authorisation decision dates - which the US registry does not hold. The fleet's ClinicalTrials.gov
tracker is the US-registry view; use the EU CT number here to join or de-duplicate against it.

### Interpretation caveat

One record per EU clinical trial in CTIS: EU CT number, title, status, sponsor organisation, phase, member states, condition, therapeutic areas, demographics and decision date - EMA registry metadata from the public search endpoint. Sponsor-contact, PI/site-contact names and narrative free-text (endpoints, eligibility) are never in the query and never delivered; the detail endpoint is never fetched.

Values are reproduced verbatim from the API; the Actor never rewrites a field. Status and region codes are
delivered as strings; dates are the registry's own per-country strings (e.g. "FR: 02/09/2026").

### Provenance and compliance

Every run reads the door host's `robots.txt` at runtime; the gate result (URL, status, byte length and, where a
policy is served, its SHA-256) is written to the run's `RUN_RECEIPT`. Where the host serves no robots.txt, the
gate records that fact (flagged) and proceeds on the licence, which expressly grants re-use. The endpoint is
keyless. The Actor never bypasses a block or fetches through a mirror.

### Data quality and freshness

Boolean columns are delivered as real booleans and numeric columns as real numbers. Delivery is keyed on a
stable id, so the dataset is safe to diff, deduplicate or upsert. Every run re-reads the live door, so the data
is as fresh as the source publishes, and each record's `observed_at` stamp dates the snapshot. The run's
`RUN_RECEIPT` records the source URL and how many records were delivered and charged, and confirms
`charge_equals_delivered`.

### Billing and delivery

Pricing is per record: you are billed only for records the Actor actually delivers, with the charge raised
after each record is pushed (push-then-charge), so a failed or empty run costs nothing. The **Maximum records**
cap bounds every run, so you control spend precisely - sample cheaply, then raise it. Because delivery is keyed
on a stable id, re-running and upserting keeps a downstream table current without re-paying for rows you already
hold; only new and changed records add cost, and every receipt reconciles delivered against charged.

### Schema, typing and joins

Every record is a flat object with a fixed, typed schema: strings stay strings, numbers are parsed to real
numbers, and booleans to real booleans, so the data loads into a warehouse or a dataframe without a cleaning
pass. The `record_id` is a stable composite key, which means the dataset is safe to diff between runs, to
deduplicate, and to upsert into a table you maintain over time. Because the identifiers the source uses are
preserved verbatim, the dataset joins cleanly onto other sources keyed on the same identifier, and a scheduled
run keeps the downstream copy current with no manual reconciliation - the new and changed rows simply upsert
over the old ones, and the `observed_at` stamp on every record tells you when each was last seen live.

### Inputs

- **Maximum records** (`maxRecords`) - hard cap on trial 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 surfaces CT number, title, status, sponsor, phase, member states and decision date.

### Fields in detail

The record leads with `ct_number`, `ct_title`, `short_title`, `ct_status`, `sponsor`, `sponsor_type`,
`trial_phase`, `trial_countries`, `trial_region`, `conditions`, `therapeutic_areas`, `age_group`, `gender`,
`total_enrolled`, and the date fields (`decision_date`, `decision_date_overall`, `results_first_received`,
`last_updated`, `last_publication_update`). The provenance block closes every record.

### Typical uses

Pharma and CRO competitive-intelligence and site-selection teams use this cell to map the EU trial landscape -
which sponsors are running which phases in which member states, and when each was authorised - as a flat,
queryable table keyed on the EU CT number. Because the sponsor, phase and countries are first-class fields, a
group-by gives the competitive picture per indication or per sponsor without cleaning, and the EU CT number
joins to the ClinicalTrials.gov view for a global picture. A scheduled run keeps the landscape current as CTIS
publishes.

### Why the list endpoint, not the detail

CTIS exposes a public search endpoint that returns the trial-level registry facts, and per-trial detail pages
that carry the full submission including sponsor and site contact persons and the sponsor-authored documents.
This cell reads **only the search endpoint**. That is what makes the dataset clean to redistribute: the search
layer gives every trial, keyed on the EU CT number, with no contact persons and none of the third-party
documents the EMA notice protects. If a user needs a specific trial's full detail, the EU CT number takes them
to the CTIS public portal, where EMA publishes it under its own terms; the Actor does not aggregate it.

### Reading the registry fields

`ct_status` is the trial's lifecycle state; `trial_phase` its clinical phase; `trial_countries` the member
states with their part counts; `therapeutic_areas` the MedDRA areas; and the decision-date fields the
authorisation dates per country and overall. Together these let a competitive-intelligence team slice the EU
landscape precisely - open Phase III trials in a given therapeutic area authorised this year, say - because
every dimension is a first-class field on the record rather than buried in a document.

### Sibling Actors

It sits beside the fleet's ClinicalTrials.gov trials tracker (the US-registry view; ~40% of trials dual-registered, joined on the EU CT number) and the fleet's ChEMBL clinical-stage screen. It shares its engineering - the runtime robots gate, paging, push-then-charge billing and verbatim-value discipline - with the fleet's other records Actors.

# 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 EU CTIS clinical trial 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/eu-clinical-trial-ctis-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/eu-clinical-trial-ctis-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/eu-clinical-trial-ctis-records --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,nexgensignal/eu-clinical-trial-ctis-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/ZMUN2HIpcvI9vhIsm/builds/dNgXq8fgEDTLAR1U5/openapi.json