TrialBridge

Inspiration

I (Vilay) started my career as a Clinical Research Coordinator at Stanford Cancer Center. Still the most formative experience working with patients at the end of their lives. I have since built award winning Palliative programs, but keep coming back to the same problem - how do we meet needs of patients who have exhausted all available FDA approved therapies. At that point, what most patients want is not survival for its sake, but to make it to an important life event - son's graduation, daughter's quincenera, or an anniversary. For these patients, clinical trials can be the only pathway that might increase their lifespan through a therapy that won't be on the market for years.

Yet, the access is gatekept - geographically limited around academic medical centers who run the trials, or knowledge and bandwidth of community oncologists - all buried in CT.gov, a clunky government database that is difficult to navigate. Meanwhile clinical trials regularly shut down due to low enrollment. Patients who could have qualified never find a trial, and trials that can help many never fill and reach their endpoints.

We built TrialBridge to close the gap on both directions. This is also the first project built together by us three brothers working across three different time zones and bringing experience from three very different fields:

I, Vilay, am a healthcare executive with background in population health, high risk patient management and healthcare strategy and operations. He lived and breathed clinical trials for good portion of his career and brought the vision.
Shobhit, based in India, conceived and created the application, designed the patient-facing workflow and built the WebMCP tools that connect an AI agent with TrialBridge.
Harshit, based in New York and the most deeply technical member of the team, helped shape the application’s technical architecture, implementation and engineering reliability.

TrialBridge emerged from the intersection of healthcare, technology and patient advocacy—and from three brothers wanting to build something useful together.

What it does

TrialBridge helps patients and caregivers discover clinical trials that may be worth discussing with their doctors. A patient can describe their situation to an AI agent in ordinary language—for example:

“I have stage IV neuroendocrine cancer. I’m 58, live in Chicago, can travel 150 miles, and previously received Afinitor.” Through WebMCP, the agent can then interact with TrialBridge using structured tools registered directly by the webpage. The patient does not need to manually complete every field or navigate multiple filtering menus. However, the profile remains visible and editable, allowing the patient to inspect and correct what the agent entered.

TrialBridge can:

Convert a patient’s plain-language description into a structured search profile;
Resolve supported medication brand names to their generic equivalents, such as Afinitor to everolimus;
Search currently recruiting studies using the live ClinicalTrials.gov API;
Distinguish the number of registry records checked from the number of trials eventually shown;
Explain which records were filtered out and why;
Show whether the search reached the end of the available registry results or stopped at an application limit;
Compare age, location and supported prior-treatment information against published study details;
Display what appears consistent, what appears inconsistent and what remains unknown;
Allow the agent to shortlist potentially relevant studies with factual reasons;
Open a full side-by-side comparison of shortlisted trials; and
Support preliminary pre-screening against published inclusion and exclusion criteria.

Importantly, TrialBridge preserves uncertainty.

If a patient does not know their ECOG performance status or cannot answer another medical question, the application records that information as unresolved. It does not silently convert an unknown answer into a pass or a failure.

TrialBridge does not determine eligibility, diagnose a condition, recommend treatment or provide medical advice. Only a clinical-trial study team can determine eligibility after medical screening.

How we built it

We began by developing the domain layer required to understand cancer terminology, treatment names and clinical-trial records. This included a curated cancer and treatment catalogue built from publicly available clinical sources and open clinical terminology, supported medication mappings, and brand-to-generic drug-name resolution. ClinicalTrials.gov API v2 provides the live public trial data used by the search.

We then built TrialBridge using:

Next.js
React
TypeScript
ClinicalTrials.gov API v2
WebMCP
Declared tool schemas and application-level input validation
Browser-stored patient profile and pre-screening state
Replit deployment

The webpage registers ten structured tools using the current WebMCP imperative API: document.modelContext.registerTool()

Each tool has:

A defined name and description;
A declared input schema;
Structured parameters;
Application-level validation before state changes are applied;
A specific application action; and
A visible result in the same interface used by a human.

This means an AI agent does not have to scrape the page, interpret screenshots or guess which element to click. Instead, the webpage acts as an in-page tool server, allowing the agent to invoke capabilities that the application has explicitly exposed.

Different tools handle different parts of the workflow, including:

Reading and updating the patient profile;
Searching conditions and trials;
Retrieving trial details;
Managing the shortlist;
Opening comparisons;
Starting pre-screening; and
Recording preliminary criterion responses.

Search and trial-data operations use the live ClinicalTrials.gov API. Patient profile, shortlist and pre-screening information are maintained within the browser so the patient can see and control the state being used.

The agent and the patient share the same screen: when the agent changes something, the patient can see it immediately.

Challenges we ran into

Working with an emerging browser proposal WebMCP is still an emerging proposal, and its API, browser support and testing workflows continue to evolve. We had to ensure that TrialBridge could register its tools using the current API, expose understandable schemas and produce visible changes that both the agent and the user could verify.

ClinicalTrials.gov API and browser restrictions Direct browser requests introduced CORS and preflight limitations. We addressed this through a server-side proxy while preserving live ClinicalTrials.gov data and transparent source attribution.

Separating records checked from trials shown Registry metadata can be misleading if the application presents only the final number of displayed trials. We implemented explicit accounting for:

Records returned and checked;
Trials shown;
Trials filtered out;
Reasons for filtering;
Pages retrieved; and
Whether pagination reached the end.

Translating complex eligibility language Clinical-trial inclusion and exclusion criteria are often long, inconsistent and written differently across studies. We needed to present them without pretending that TrialBridge could replace clinical judgment.

Our solution was to treat the comparison as preliminary and preserve three distinct outcomes:

Appears consistent;
Apparent mismatch; and
Still unknown.

Preventing AI-generated certainty One of our most important challenges was ensuring that an agent could not guess an answer when medical information was unavailable. Unknown information remains unresolved, and malformed or unsupported responses are rejected rather than being forced into a pass-or-fail result.

Protecting patient privacy We designed the demonstration so that it does not require a patient’s name, email address or date of birth. Search details and pre-screening responses remain visible and controllable in the browser.

Accomplishments that we’re proud of

Building our first project together as three brothers across three time zones and three industries: healthcare, technology and law;
Creating a working clinical-trial discovery engine—not merely a static prototype;
Compressing a process that can require hours of manual searching into a structured conversational workflow;
Successfully connecting the application to an AI agent through ten WebMCP tools;
Allowing the agent to operate the same visible interface that a patient can inspect and correct;
Searching live, currently recruiting studies from ClinicalTrials.gov;
Distinguishing records checked from trials shown and explaining why records were filtered;
Supporting brand-to-generic medication resolution;
Building a real preliminary comparison workflow for published inclusion and exclusion criteria rather than relying solely on keyword matching;
Preserving unknown medical information as unresolved instead of allowing the agent to guess; and
Keeping eligibility decisions where they belong—with the clinical-trial investigators.

Most importantly, the tool works. TrialBridge demonstrates that an AI agent can help a patient move from an ordinary-language description to a transparent, reviewable set of potentially relevant trials without concealing uncertainty.

What we learned

WebMCP does not replace application logic WebMCP gives an agent a precise way to use a website, but the usefulness of those tools still depends on the quality of the application underneath them. Clinical terminology, filtering rules, medication mappings, pagination, privacy and safety states all had to be built into TrialBridge itself.

Shared visual state matters A purely conversational response can conceal errors. In TrialBridge, every agent action updates the same interface the patient sees. This makes the interaction inspectable and correctable.

“Unknown” is a valuable result In healthcare, uncertainty should not be treated as failure—and it must never be silently converted into certainty. Preserving unresolved information became one of the most important design principles of TrialBridge.

Live data needs transparent accounting A useful search should explain not only what it found, but also what it checked, what it removed, why it removed it, and whether it reached the end of the available results.

Clinical-trial matching requires restraint A software tool can identify potentially relevant studies and help organize published criteria. It cannot decide whether a patient qualifies. Responsible design requires that distinction to remain visible throughout the product.

What’s next for TrialBridge

Our next steps include:

Expanding support across additional cancer types and subtypes;
Building deeper, clinically reviewed treatment and line-of-therapy mappings using appropriately licensed or openly available clinical references;
Improving biomarker, treatment-history and disease-setting comparisons;
Working with clinical research coordinators, oncologists and patient advocates to validate the workflow;
Making trial criteria easier for patients and caregivers to understand without changing their meaning;
Supporting direct, consent-based sharing of shortlisted trials with doctors and study teams;
Exploring the creation of a 501(c)(3) nonprofit organisation so that TrialBridge can remain freely accessible to patients;
Partnering with patient-advocacy groups and cancer organisations to make the tool available to the communities that need it;
Exploring transparent, patient-first collaborations with research sponsors and pharmaceutical companies, while protecting patient privacy and preserving TrialBridge’s independence; and
Measuring whether TrialBridge can meaningfully reduce the time between a patient beginning a search and contacting an appropriate study team.

TrialBridge is not intended to replace doctors, coordinators or clinical-trial investigators.

It is intended to build a bridge—to the trials worth discovering, the criteria worth understanding and the conversations worth having.