How do you get alerted when a ClinicalTrials.gov record changes?

What does ClinicalTrials.gov itself offer?

RSS feeds and saved searches, and nothing by email. For any search you define, the registry offers two feed types, in its own words: “New studies first posted in the last 14 days” and “New and existing studies added or modified in the last 14 days”. Each feed entry carries the study record with its first posted and last update posted dates. The site’s documented alternative to RSS is bookmarking your search results page and revisiting it.

This is genuinely useful and free, and worth setting up for any therapeutic area you follow loosely. Its two limits are structural. The feed tells you that a record was updated and when; identifying which fieldchanged, and from what value, is left to you, because the registry does not publish a record’s history. And the feed is search-shaped: it watches a query window, not a portfolio, so an update to a specific trial you care about arrives mixed into every other record their search matched that fortnight.

What about generic page watchers?

Tools like Visualping, PageCrawl and Distill watch any web page and tell you when its rendered content changes. Pointed at a trial record, they will catch that something on the page is different, often with a visual highlight of the changed region, on whatever polling schedule you pay for.

Their strength is generality; their limit here is that they watch pages, not fields. A page-level watcher does not know that an enrollment figure labelled estimated becoming one labelled actual is a completion event rather than a revision, or that a layout tweak is nothing. Per-page pricing also scales linearly, which is workable for five trials and not for a portfolio. For one or two records you check occasionally, they are a perfectly reasonable answer.

What does building it yourself involve?

Four pieces, none exotic: a daily pull of your trials from the registry’s v2 API, storage of each day’s copy, a field-level comparison against yesterday’s, and routing of the differences to wherever your team looks. The API is free and well documented. The essential constraint is that it returns current state only: the history you diff against exists solely in the copies you keep, from the day you start keeping them.

The honest cost is not the build but the operation: the pipeline that breaks silently the week something important moves, and the daily triage of which differences deserve a human. Our own archive says forecast completion dates move 93.5% one way and 82% of enrollment changes are finalisations rather than revisions; without that kind of base rate encoded, a raw diff feed becomes a noise channel people learn to ignore. If your team has an engineer with standing time and a real need to own the pipeline, it is a legitimate choice.

What does a purpose-built monitor add?

The interpretation layer: the part that knows what a change is, not just that one happened. ComplyRx watches ClinicalTrials.gov for the drugs you track and reports status flips, completion date moves and enrollment changes as the registry recorded them, labelled estimated or actual, fresh or a stale record catching up. DataLookout, self-serve like us, watches by sponsor and disease. The enterprise intelligence platforms document alerting too, as part of much larger curated products; our comparison page covers who sells what and who publishes a price.

What you are paying any of these for is the same three things: the kept history, the field-level diff, and a judgement about which differences matter, maintained by someone whose whole product fails if it goes quiet.

Which option fits which job?

The one wrong answer is the default one: assuming the registry will tell you. It records everything and announces nothing, and every option above exists to close exactly that gap.