How the FAST Clinical Trial Finder works

1. Overview

The FAST Clinical Trial Finder is a curated view of Angelman syndrome research. It sits between the raw public registry and the families who need to understand it. Registry records are complete but dense; our goal is to keep the authoritative data intact while adding the context that helps a caregiver judge whether a study is relevant to them.

Three principles govern the system: source data is never edited, editorial content is stored separately from it, and nothing reaches the public site without a human review step.

2. Data sources

The single external source is ClinicalTrials.gov, accessed through its public API. From each study record we retain the registry identifier (NCT number), official and brief titles, recruitment status, study type and phase, conditions and interventions, eligibility criteria including age bounds, sponsor, locations, and key dates.

Sponsors are responsible for keeping their registry entries current. Where a record is sparse or out of date at the source, that limitation carries through to what we can display.

3. How data is pulled in

Retrieval is deliberate rather than automatic-and-invisible. Administrators maintain named search configurations — rule sets describing the conditions, interventions, statuses and other criteria that define what counts as an Angelman syndrome study. Each configuration is compiled into a registry query and shown back in plain English, so the rules stay auditable.

1. Fetch

   A run executes the compiled query against the registry API and records how many studies came back.

2. Normalize

   Raw responses are mapped into a consistent shape — ages converted to comparable units, locations and statuses standardized.

3. Compare

   Each study is checked against what we already store to determine whether it is new, unchanged, or modified.

4. Score

   A match-quality signal indicates how closely a study fits the search intent, helping reviewers triage.

5. Queue

   Results land in a review queue. Nothing is published by the pipeline itself.

4. Editorial review & amendments

Amendments are additive. When the team enriches a trial, the edits are written to a separate editorial layer keyed to the study — the registry fields underneath are left untouched. If a plain-language title or summary exists, the public page shows it; otherwise the registry text is displayed as a fallback.

• Plain-language title and summary written for families rather than researchers.
• Taxonomy tags such as genotype focus, program approach and dosing frequency.
• Display controls: featuring a study, or pinning it to a fixed position in the results.
• Workflow decisions — publish, hold for review, or set aside with a recorded reason.

Studies that are set aside are not deleted. The decision and its rationale are preserved, so a later fetch does not silently re-surface something the team already assessed, and a past decision can be revisited deliberately.

5. Change detection & versioning

Registry records change: a study opens recruitment, adds a site, revises eligibility, or completes. On every fetch run we snapshot the source version of each study and compare it to the previous snapshot. Differences are surfaced field by field rather than applied silently.

A changed study is flagged for review, and a reviewer decides whether the editorial layer needs updating alongside the new source data. This keeps published plain-language summaries from drifting out of sync with the study they describe.

6. Quality & limitations

• Coverage is bounded by the registry. Studies that are never registered cannot appear here.
• Accuracy depends on sponsors updating their own records.
• Between fetch runs, a status shown here may lag the official record.
• Search rules encode a judgment about relevance; a reasonable rule can still miss an edge case.
• Plain-language summaries are simplifications and omit detail found in the full protocol.

7. Disclaimers

8. Frequently asked questions

Ready to look at studies? Open the trial finder.