TrialDelta — Clinical Trial Competitor Monitor

Monitor competitor clinical trials with structured data from ClinicalTrials.gov. TrialDelta turns a recurring registry query into a change-detection workflow for biotech, pharmaceutical, CRO, investor-relations, and clinical-development teams.

Instead of repeatedly reviewing the same search results, TrialDelta stores a compact baseline and reports what changed between runs. It identifies newly discovered studies, meaningful updates to previously observed studies, and studies that no longer match the monitored query.

TrialDelta is a monitoring and research-support tool. It does not provide medical advice, regulatory advice, investment advice, or a substitute for professional due diligence.

Why use TrialDelta?

Clinical-trial intelligence is most useful when it is timely, structured, and comparable over time. TrialDelta is designed for teams that need a lightweight way to monitor an indication, mechanism, intervention, sponsor, or competitor program without building a registry-integration service from scratch.

The Actor is suitable for recurring scheduled runs, API-triggered workflows, downstream data pipelines, and alerting systems. Its JSON output can be stored in a Dataset, forwarded through a webhook, or consumed by another automation step.

Key capabilities

Capability	What TrialDelta does
Query monitoring	Searches ClinicalTrials.gov using one or more watch terms.
Baseline snapshots	Stores the latest observed result set for comparison in later runs.
New-study detection	Emits NEW events when a study appears for the first time.
Study-change detection	Emits UPDATED events when monitored study fields change.
Disappearance detection	Emits NO_LONGER_MATCHES_QUERY when a previous study is no longer returned by the query.
Run accounting	Emits a RUN_SUMMARY record with fetch, baseline, and delta counts.
Safe execution	Uses bounded request behavior and a configurable Actor timeout.
Structured output	Produces consistent JSON records for datasets, APIs, webhooks, and downstream analysis.

Input

TrialDelta accepts a JSON object with the following fields:

Field	Type	Required	Default	Description
watchTerms	Array of strings	Yes	["melanoma"]	Terms to monitor. These may be conditions, mechanisms, products, sponsors, intervention names, or other ClinicalTrials.gov search terms.
pageSize	Integer	No	25	Maximum number of studies to retrieve in a run. Valid range: 1–100.
resetBaseline	Boolean	No	false	When enabled, treats the current results as a new baseline instead of reporting them as changes. Use this when starting a new monitoring program or changing the query substantially.

Example input

{
  "watchTerms": ["melanoma", "nivolumab"],
  "pageSize": 25,
  "resetBaseline": false
}

Input guidance

Use specific and stable watch terms where possible. A condition such as melanoma is useful for indication-level monitoring, while a sponsor, drug, mechanism, or product name is better for competitor-program monitoring. Multiple terms may be supplied when a single run should cover a small monitoring set.

When changing from one monitoring program to another, set resetBaseline to true for the first run of the new query. Otherwise, the Actor may correctly interpret the new result set as a large group of changes relative to the previous query.

Output

Each Dataset item represents either a study-level delta event or a run-level summary.

Field	Type	Meaning
eventType	String	One of NEW, UPDATED, NO_LONGER_MATCHES_QUERY, or RUN_SUMMARY.
runId	String	Apify run identifier associated with the event.
watchTerms	Array of strings	Terms used for the run, when available.
nctId	String or null	ClinicalTrials.gov NCT identifier for a study-level event.
title	String or null	Study title.
status	String or null	Current recruitment or study status returned by the registry.
phase	String or null	Study phase, when available.
sponsor	String or null	Lead sponsor or responsible organization, when available.
conditions	Array of strings	Conditions associated with the study.
interventions	Array of strings	Interventions reported for the study.
enrollment	Integer or null	Reported enrollment count, when available.
lastUpdatePostDate	String or null	Registry update-posting date, when available.
studyUrl	String or null	Direct ClinicalTrials.gov study URL.
changes	Array of strings	Fields identified as changed for an UPDATED event.
fetched	Integer or null	Number of studies fetched in the run summary.
previous	Integer or null	Number of studies in the previous baseline.
deltas	Integer or null	Number of delta events generated for the run.
timestamp	String	ISO 8601 event timestamp.

Example NEW event

{
  "eventType": "NEW",
  "runId": "example-run-id",
  "watchTerms": ["melanoma"],
  "nctId": "NCT01234567",
  "title": "Example melanoma clinical study",
  "status": "RECRUITING",
  "phase": "PHASE2",
  "sponsor": "Example Biopharma",
  "conditions": ["Melanoma"],
  "interventions": ["Example intervention"],
  "enrollment": 120,
  "lastUpdatePostDate": "2026-01-15",
  "studyUrl": "https://clinicaltrials.gov/study/NCT01234567",
  "changes": [],
  "timestamp": "2026-08-25T00:00:00.000Z"
}

Example RUN_SUMMARY event

{
  "eventType": "RUN_SUMMARY",
  "runId": "example-run-id",
  "watchTerms": ["melanoma"],
  "fetched": 25,
  "previous": 25,
  "deltas": 2,
  "timestamp": "2026-08-25T00:00:00.000Z"
}

How change detection works

On the first successful run, TrialDelta retrieves the matching studies and stores them as the baseline. The study records discovered on that first run are emitted as NEW events so that the initial state is visible in the Dataset.

On subsequent runs, the current result set is compared with the stored baseline. A study that was not present in the baseline is emitted as NEW. A study that remains in the result set but has changed monitored fields is emitted as UPDATED, together with the names of the changed fields. A study that was present previously but is not returned by the current query is emitted as NO_LONGER_MATCHES_QUERY.

A missing study does not necessarily mean that the study was deleted from the registry. It may have been affected by query ranking, pagination, registry changes, or a change in the search terms. Treat disappearance events as review signals rather than definitive evidence of study termination.

Recommended operating model

For continuous monitoring, create a recurring Apify schedule using the same input and allow the baseline to persist between runs. A daily schedule is appropriate for most competitive-intelligence use cases; higher-frequency monitoring should be reserved for high-priority programs and tested against the registry’s operational behavior.

For a new query, run once with resetBaseline: true, review the initial result set, and then return the flag to false. Connect the Dataset or run events to a webhook or downstream workflow if your team needs email, Slack, CRM, or internal-dashboard notifications.

API example

The following example starts the Actor through the Apify API. Replace YOUR_APIFY_TOKEN and YOUR_ACTOR_ID with your credentials and Actor identifier.

curl -X POST \
  "https://api.apify.com/v2/acts/YOUR_ACTOR_ID/runs?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "watchTerms": ["melanoma", "nivolumab"],
    "pageSize": 25,
    "resetBaseline": false
  }'

Do not hard-code an Apify token in a public repository, client-side application, or shared document. Store credentials in a secure secret manager or the relevant Apify integration configuration.

Data source and attribution

TrialDelta uses the public ClinicalTrials.gov API and presents registry-derived information for research and monitoring purposes. ClinicalTrials.gov records can change, may contain incomplete information, and should be checked directly before making operational decisions. Visit the source record through the studyUrl field for the authoritative current registry view.

Limitations

TrialDelta is intentionally an MVP monitoring layer rather than a complete clinical-intelligence platform. It does not guarantee that every relevant study is returned, does not replace manual review, and does not infer causality or business significance from a registry change. Pagination, search semantics, study updates, and registry availability can affect results.

The Actor compares the fields available in its stored records. A change is technically detectable only when it is represented in the returned registry data and included in the Actor’s comparison record. The UPDATED event is therefore a change signal, not a medical, regulatory, legal, or investment conclusion.

Privacy and security

The Actor is designed to query public registry data and does not require personal health information. Do not place confidential company information, patient information, credentials, or regulated data in watchTerms or other run inputs.

Troubleshooting

If a run times out, reduce pageSize, use a narrower watchTerms query, and retry. If a run produces many NEW events unexpectedly, confirm that the query has not changed and that the baseline was not reset. If the input form displays generic fields such as helloWorld, rebuild the Actor after confirming that the formal schema is saved and linked in actor.json.

If a study appears to have disappeared, open the ClinicalTrials.gov search directly and verify whether the record remains available, whether its data changed, or whether the query and pagination have altered the returned set.

Version and support

TrialDelta is maintained as a focused clinical-trial change-monitoring Actor. Improvements may add additional registry fields, richer comparison rules, notification integrations, and broader source coverage. Users should pin a tested build in production workflows and review changes before switching to a new build.

References

1. ClinicalTrials.gov — public clinical-study registry.

2. [ClinicalTrials.gov API documentation](https://clinicaltrials.gov/data-api/api end points ) — API access and endpoint guidance.

3. Apify Actor input schema documentation — configuring user-facing Actor inputs.

4. Apify Actor publishing documentation — marketplace publication guidance.

---

TrialDelta helps teams move from periodic manual searches to repeatable, structured clinical-trial monitoring.