Find the Version That Changed in a ClinicalTrials.gov Record

Signals to watch

• A screenshot claims that a study status or milestone changed but omits the NCT number
• The current page is cited without the earlier and later version dates
• A visible change is interpreted as an error, delay or buying request without source evidence

To find what changed in a ClinicalTrials.gov record, start with the exact NCT number, open the study’s History tab, select the earlier and later versions that bracket the claim, and compare the named module and field. Then use the ClinicalTrials.gov application programming interface (API) to confirm the current machine-readable value. This proves what the public versions show; it does not prove who made the change or why.

The task belongs to a life-sciences sales-research coordinator watching authorised sponsor, registry-operations and vendor Telegram groups. A one-day delay can leave a useful registry-support request with another supplier. A fast but unsupported note such as “sponsor corrected a late study” can be worse: the public history may show a field change while saying nothing about the editor, source data, compliance judgement or buyer.

Start with the NCT number, not the screenshot

An NCT number is the stable identifier assigned to a ClinicalTrials.gov study record. A cropped screenshot, study acronym or sponsor name can refer to multiple records or omit the field label. Before comparing anything, capture:

• the NCT number and exact study URL;
• the field named in the group claim;
• the date and time the current page was observed;
• the screenshot or quoted wording as a separate artefact; and
• the group source and access context.

If the NCT number is missing, search can help find candidates, but the result remains unresolved until the message and exact record are joined. Do not choose a record because its title merely looks similar.

Top Prospect can preserve and rank matching fragments from Telegram sources a user deliberately connects, is authorised to access and has enabled. Its current production matching-target interface saves configurations but does not automatically produce new candidates. It cannot open unauthorised sources, identify a record editor, determine why a field changed or contact a group member. The source-review product workflow keeps those human decisions outside the score.

Open History and choose a meaningful pair

The study page’s History view lists submitted versions in submitted-date order. Opening a submitted date shows that version; selecting two versions and choosing Compare produces a field-level comparison. The useful comparison is rarely “first version versus latest version.” Choose the pair that surrounds the claim:

1. the last public version before the alleged change; and
2. the first public version after it.

If a message posted on 12 August says “completion moved to December,” a version from March is too remote unless no closer version exists. Record the two version dates and the changed module before opening the field comparison. This limits the review to the change that could have been visible when the message appeared.

History is public evidence of versions, not an internal audit trail. It should not be described as identifying the individual editor, the organisation’s approver, Protocol Registration and Results System access, the source document or the reason a value changed.

Name the field in the later version

Use the Protocol Registration Data Element Definitions to translate a visible label into the official data object. “The study date changed” is ambiguous. Start Date, Primary Completion Date, Study Completion Date, Overall Recruitment Status and Study Status Verification Date answer different questions.

Write the observation as a labelled source note: NCT identifier and exact record URL; earlier and later submitted-version dates; named module; exact field; old value and type; new value and type. End with: “Reason, editor and source record are not established by the public history.” This is a copyable field list, not an unfinished claim.

Keep estimated and actual date types attached to the value. A change from estimated to actual is not the same observation as moving an estimated date by three months. A status change and a date change should remain separate rows even when they appeared in the same version.

Confirm the current value through the API

ClinicalTrials.gov’s About the API and API version 2 documentation describe programmatic access to study records. For the current record, the study endpoint uses the NCT identifier, for example:

https://clinicaltrials.gov/api/v2/studies/NCT00010010

The returned JavaScript Object Notation (JSON) document organises current data into named modules and fields. For a completion-date question, a reviewer can locate the status module and preserve the current date plus its estimated or actual type. For a status question, preserve the exact current status value and the relevant verification or posting dates.

The API check has a narrow role: it confirms the current structured value and reduces errors caused by copying display text. It does not replace the public version comparison, and it does not explain the change. Do not use an undocumented internal endpoint as durable evidence when the public History interface and documented API can answer the navigation task.

Example: a changed date is an observation, not a diagnosis

Consider this illustrative composite exchange, not a real study, sponsor or customer request:

ctgov date changed again overnight. looks like disclosure slipped. anyone know the sponsor team?

A reply adds:

screenshot only, NCT ends 87 maybe. can check later

The coordinator cannot yet locate one exact record. Even after recovering the NCT number, a changed completion date would not establish that disclosure slipped. Possible explanations include a forecast update, later participant follow-up, correction of an earlier entry or another protocol change. The public versions may distinguish the field values, but they do not confirm those explanations.

The output after source recovery should be a version note, not a motive:

• exact NCT record found;
• message time and source preserved;
• earlier and later public versions selected;
• exact changed field and date type recorded;
• current API value captured; and
• reason, source data, editor, authority and service need marked unknown.

This is enough for the coordinator to ask a registry specialist whether the change matters. It is not enough to label the sponsor late, the record wrong or the poster a buyer.

The reproducible path in six checks

• The NCT number anchors a version comparison to one study record.
• The History tab exposes public versions and changed modules.
• Compare the nearest versions before and after the claim, not arbitrary endpoints.
• The documented v2 API provides the current machine-readable study record.
• Public history does not establish the individual editor, source data, reason or commercial intent.
• A reproducible version note records exact values, dates, URLs and unresolved questions.

Complete the navigation check

The task is complete when another reviewer can open the same NCT record, choose the same two versions, find the same field difference and reproduce the current API value. Save the URLs, observation date and literal values. If the relevant version is unavailable or the record cannot be identified, record that failure instead of substituting a screenshot inference.

For the meaning of two often-confused date fields, read Primary Completion Date versus Study Completion Date. The ClinicalTrials.gov disclosure evidence map separates a visible field change from record ownership, results modules and reporting applicability. The official-source ladder helps when a group repost cites an unnamed policy.

Frequently asked questions

Where is the change history for a ClinicalTrials.gov study?

Open the exact NCT study page and select the History tab. Use the displayed versions and dates to choose the records you need to compare.

Does record history identify the person who edited a field?

The public history helps show submitted versions and changed modules. It should not be treated as proof of an individual editor, internal approval path or reason for the change.

What does the ClinicalTrials.gov API add?

The v2 API provides the current study record in machine-readable form, including named modules and fields. It is useful for confirming the current value, not for inventing the reason behind a historical change.

Does a changed date prove a disclosure-services need?

No. The change can justify review, but the applicable requirement, record owner, source data, requester and purchasing authority still need verification.

Sources and further reading

• ClinicalTrials.gov: NCT00010010 Record History interface, accessed 24 August 2026↗
• ClinicalTrials.gov: How to Download Study Records, modified 17 July 2025, accessed 24 August 2026↗
• ClinicalTrials.gov: About the API, accessed 24 August 2026↗
• ClinicalTrials.gov: API Version 2 documentation, accessed 24 August 2026↗
• ClinicalTrials.gov: Protocol Registration Data Element Definitions, accessed 24 August 2026↗

RESEARCH & DEFINITIONS

How a Signal worth attention is found

See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.

Open the methodology and core definitions →