ClinicalTrials.gov Change Monitor — New Trials, Status Flips, New Sites

Docs & recipes: pricing math, use-case playbooks and copy-paste API/MCP snippets

Monitor ClinicalTrials.gov and get only what changed. Point it at a therapeutic area, a sponsor, or a country; schedule it daily; each run delivers field-level diffs like this — the money record, a status flip (illustrative example):

{
  "change": "status_change",
  "nct_id": "NCT00000001",
  "url": "https://clinicaltrials.gov/study/NCT00000001",
  "brief_title": "A Phase 2 Study of ...",
  "lead_sponsor": "Example Pharma",
  "previous_status": "RECRUITING",
  "new_status": "ACTIVE_NOT_RECRUITING",
  "still_in_tracked_statuses": false,
  "why_stopped": null,
  "phases": ["PHASE2"],
  "conditions": ["Non-Small Cell Lung Cancer"],
  "enrollment_count": 120,
  "enrollment_type": "ESTIMATED",
  "num_sites": 34,
  "countries": ["United States", "Germany"],
  "last_update_post_date": "2026-08-05",
  "primary_completion_date": "2027-06-30",
  "observed_at": "2026-08-06T22:34:59+00:00"
}

The change types

change	What it means	Who cares
new_trial	A study matching your filters was just registered / entered your funnel	CI teams: a competitor just started a program
status_change	Recruiting → Active / Terminated / Completed / Suspended… (with previous_status, new_status, why_stopped)	CRO BD: enrollment closing = rescue/next-phase conversations; termination = white space
sites_added	New facilities joined an existing trial — facility name, city, state, country, site status, and PI name exactly as published by CT.gov	Site-selection intel, KOL mapping, "who is expanding where"
enrollment_change	Target/actual enrollment moved (previous_enrollment, new_enrollment, enrollment_delta)	Enrollment trouble (cuts) or confidence (raises) — both are signals
baseline	First delta run only — seeds the tracked universe, flagged is_baseline: true	Your starting book of record
snapshot	Snapshot mode rows (no diffing, no state)	One-off pulls, backfills

This is not another snapshot scraper. Snapshot actors re-dump the same thousands of rows every run and leave the diffing to you — and they structurally cannot catch the most valuable event: a study whose status flips out of your filter (Recruiting → Terminated) simply vanishes from a snapshot. This actor persists a fingerprint of every tracked study in a key-value store and re-checks tracked studies by NCT ID with no status filter, so the flip itself is delivered as a record.

Why not the free CT.gov email alerts?

ClinicalTrials.gov's own "saved search" emails are fine for a patient tracking one disease. They are not a BD tool:

	Free CT.gov email alerts	This actor
Format	HTML email, one study per blob	Structured JSON records, stable schema
What changed	"This study was updated" — go click and guess	Field-level diff: exact status flip, enrollment delta, the specific new sites
Site-level detail	No	Facility + city/state/country + site status + PI name (as published)
Multi-filter portfolios	One saved search per email	Any number of watchlists via stateKey, one per schedule
Automation	Copy-paste from your inbox	Dataset → API/webhooks/Zapier/Sheets; schedulable; callable from AI agents via MCP
Sponsor watch	Weak	Lead-sponsor filter (sponsor: "Merck Sharp & Dohme")

And why not Citeline/TrialTrove? Five figures a year. A daily watch here costs pennies (pricing below).

Input (everything optional — an empty {} input is a valid run)

{
  "condition": "non-small cell lung cancer",
  "sponsor": "AstraZeneca",
  "phases": ["PHASE2", "PHASE3"],
  "statuses": ["RECRUITING"],
  "countries": ["United States", "Germany"],
  "mode": "delta",
  "daysBack": 7,
  "stateKey": "nsclc-az"
}

Defaults: condition: "oncology", phases 2–3, RECRUITING, worldwide, mode: "delta", 7-day baseline window. An empty {} input is a valid run (live-tested: ~450 baseline studies).

• condition takes full CT.gov Essie syntax ("multiple myeloma" OR "plasma cell myeloma").
• statuses defines which studies enter tracking. Once tracked, a flip to any status is still reported — that's the product.
• daysBack bounds only the first (baseline) run and snapshot mode: "studies updated in the last N days". Subsequent delta runs automatically use the time since the previous run (+3-day safety margin). Set daysBack: 3650 to baseline the entire matching universe at once.
• stateKey: one independent watchlist per key. Changing filters on an existing key is detected (fingerprint) and safely re-baselines instead of emitting a garbage diff.

Output fields

Every record carries the study snapshot plus the change annotation:

Field	Type	Meaning
change	string	new_trial | status_change | enrollment_change | sites_added | baseline | snapshot
nct_id / url	string	Study identity and CT.gov link
brief_title / lead_sponsor	string	Study title and lead sponsor (not collaborators)
overall_status	string	Current CT.gov status
why_stopped	string | null	CT.gov's stated reason on suspended/terminated/withdrawn studies
phases / conditions	array	Trial phases and condition terms
enrollment_count / enrollment_type	number / string	Target or actual enrollment (ESTIMATED/ACTUAL)
study_first_post_date / last_update_post_date / start_date / primary_completion_date	date	Study timeline
num_sites / countries	number / array	Site footprint
sites	array	Full site list on new_trial/baseline/snapshot: {facility, city, state, country, site_status, pi_name}
observed_at	ISO date	When this actor observed the change

Change-specific extras: status_change adds previous_status, new_status, still_in_tracked_statuses; enrollment_change adds previous_enrollment, new_enrollment, enrollment_delta; sites_added adds new_sites (just the additions) and sites_added_count; baseline adds is_baseline: true. Fields not published by CT.gov are null, never missing. See sample_output.json for real live-run output.

Use cases

• CRO business development — schedule one run per therapeutic area every morning. status_change to ACTIVE_NOT_RECRUITING means enrollment just closed (time the next-phase pitch); TERMINATED with why_stopped is a displacement opening; sites_added in your geography is a warm site-network lead.
• Pharma competitive intelligence — one stateKey per competitor via the sponsor filter: every new program, phase population, enrollment cut, and geographic expansion, as JSON, the day CT.gov posts it.
• Site selection / KOL mapping — sites_added with facility, city, state, and PI name (only as published professionally by CT.gov).
• Investors / biotech analysts — enrollment cuts and quiet terminations often front-run press releases.

Delta mode details

State lives in the named key-value store clinicaltrials-change-monitor-state under your stateKey. Each run: (1) fetches studies matching your filters updated since the last run, (2) re-checks tracked NCT IDs missing from that fetch — with no status filter — so out-of-filter flips are caught, (3) diffs, pushes only changes, and updates state. Studies not updated at all are carried forward silently at zero cost. A study that leaves your filter set is reported once (status_change with still_in_tracked_statuses: false, or left_filter) and then dropped; if it later re-enters, it shows up as new_trial.

Using from Claude / MCP

Once published, call it through the Apify MCP server (https://mcp.apify.com):

{
  "tool": "your-username/clinicaltrials-change-monitor",
  "input": { "sponsor": "Pfizer", "condition": "", "stateKey": "pfizer-watch" }
}

Ask your agent: "What changed in Pfizer's trial portfolio this week?" — that's one delta run.

Pricing

$0.01 per change record. Worked math:

• Daily delta watch on a whole therapeutic area (defaults): typically a handful to a few dozen records — $0.05–$0.50/day.
• Single-sponsor watch: usually under $0.10/day.
• One-time baseline on default filters: ~450 records ≈ $4.50 (bound it with daysBack/maxStudies for a cheaper start).
• Snapshot mode is priced the same per row — control row counts with daysBack and maxStudies.

Honest limits

• Diffs are computed against this actor's own previous run — the first run on a stateKey is a baseline, not a diff.
• Change detection covers status, enrollment, and site additions; other field edits (e.g. endpoint changes) don't emit records.
• CT.gov itself posts updates with registry lag; you see changes when CT.gov publishes them, not when the sponsor decides them.

Fair use & data notes

Data comes from the official, free, keyless ClinicalTrials.gov v2 API (data.gov terms), fetched politely: capped page sizes, inter-page pauses, exponential backoff honoring Retry-After. Records are public regulatory disclosures. Person names (site PIs/contacts) are included only exactly as published professionally by ClinicalTrials.gov, and only in their professional capacity; no other personal data is collected or enriched.