Concord

Concord's home page: turn a trial protocol into a budget the hospital and sponsor can both check, priced from public Medicare rates.
Protocol to terms: pick a trial, and Concord reads its visits and procedures, then walks through coverage, budget, comparison and terms.
Portfolio overlap: each cell counts the U.S. sites two Regeneron lung trials share. Two fianlimab trials shared 16.
Every number has a public source or an "assumption" label: CMS 2026 fee schedules, Medicare coverage policy, ClinicalTrials.gov.
One trial's procedures priced in all 109 Medicare regions: $1,034 to $1,580 per participant. Our two demo sites sit near opposite ends.
Why one protocol's budget is $375 higher at NYU than Hattiesburg: mostly Manhattan practice costs, from Medicare's public adjustments.
Share of each budget set by public Medicare rates (blue) before negotiating: about a fifth. The rest is labelled proposal and overhead.
Coordinating sites across trials looked 1.42x faster on training data (orange) but only 1.05x on unseen trials (blue). We dropped it.
Our first model assumed competing trials fully slow a hospital (orange line, 1.0). Measured every way, the real effect is near zero.
Each dot is a trial. If site scores predicted enrollment perfectly, dots would follow the orange line. The real trend (blue) is flatter.
Sites with 1-2 past trials are capped (orange) so one lucky trial can't inflate them. Less history means wider uncertainty (right).

Inspiration

Before a clinical trial can enroll its first patient, each hospital and the sponsor have to agree on a budget. In WCG's 2025 survey, 73% of 611 research sites named budgets and contracts among their top contributors to study start-up delays. The two sides often negotiate from numbers the other side cannot reproduce: sponsors use proprietary benchmarks, while sites work from their own charges and coverage analysis.

We wanted to give both sides a shared starting point: a budget where someone can open a line, understand the calculation, and check the source themselves.

We started somewhere else. Our first idea was a "clearing house" that would allocate sites across a sponsor's concurrent trials so they stop competing for the same patients. We tested it on 7,221 non-small cell lung cancer trials from ClinicalTrials.gov, and the results weakened our original thesis. In our research comparisons, modeled coordination gains fell from 1.42× in sample to about 1.05× held out. Our estimated within-site congestion effect was 0.09, against the 1.0 we had assumed. Public registry data also supported site-performance prediction only weakly. These exploratory findings did not establish a validated enrollment forecast.

That changed what we built. We focused Concord on the part of the problem public data could support: making trial budgets understandable, reproducible, and easier to review.

What it does

Protocol to terms turns a trial's schedule of assessments into a budget both sides can check:

Coverage analysis. Each visit and procedure receives a draft classification informed by Medicare's clinical-trial policy, NCD 310.1. Concord shows the rule and allows reviewer overrides. A draft routine-care classification is not a coverage or payment guarantee.
Procedure pricing. Supported coded procedures use the CMS 2026 physician fee schedule at the site's Medicare locality; supported laboratory procedures use the clinical laboratory fee schedule. Each priced line exposes its source and calculation. Missing prices stay unpriced.
Anchored share. Concord separates public benchmarks, proposed fee standards, and assumptions. In our illustrative Regeneron fianlimab budget at NYU Langone, approximately 20% of the per-participant sponsor budget comes from public CMS rates, 60% from a labeled proposed standard for non-procedure fees, and 20% from assumed overhead. This is our constructed example, not an observed negotiated trial budget.
Two-site comparison. Reviewers can inspect how Medicare's geographic adjustments contribute to a price difference and compare the site's benchmark with 109 Medicare localities.
Site proposal check. Upload a proposed budget as CSV. Coded lines are flagged above, below, or inside a user-selected range around the Medicare benchmark; other fees require itemized justification. The result exports as a counter-proposal with its supporting sources. Our demonstration proposal is explicitly synthetic.
Trial import. Add a trial by NCT ID to retrieve its registry record and U.S. sites. Upload a schedule as CSV, or review a registry-derived draft with cited items. Registry information does not replace the full protocol or professional review.

Portfolio overlap shows shared registered sites across a sponsor's trials. Our Regeneron example identified 16 shared registered U.S. sites between two fianlimab trials. The NSCLC eligibility-overlap analysis uses a synthetic population; breast-cancer coverage is limited to shared-site counts. Shared sites alone do not establish recruitment competition.

Findings publishes the research that led us to change direction, including the results that weakened our first idea.

Concord also preserves a separate, explicitly synthetic planning demonstration. Its seeded optimization compares allocations under entered budget and capacity assumptions and exports the evidence behind the calculation. Those modeled differences are not observed clinical outcomes or demonstrated trial acceleration.

How we built it

We built a data pipeline, calculation layer, and review interface around the same principle: preserve the path from an input to the number shown on screen.

Public data pipeline: A ClinicalTrials.gov API v2 crawler builds a SQLite database of NSCLC trials and registered sites, with site de-duplication and handling for anonymized site records.
Pricing engine: The rate card loads CMS physician relative value units, geographic practice cost indices, the conversion factor, and laboratory fee schedules. Public benchmarks remain separate from authored non-procedure fees and overhead assumptions.
Backend: Python, FastAPI, Pydantic, NumPy, and SciPy support coverage rules, pricing, proposal checks, financial accounting, bounded allocation, and evidence exports.
Research: We explored Poisson-gamma site-enrollment models, site fixed effects, clustered standard errors, held-out comparisons, and checks against observed trial-level enrollment. We retained the limitations and negative findings alongside the product.
Frontend: React, TypeScript, and Vite provide Simple and Detailed views, light and dark themes, and expandable explanations. Reviewers can start with the main decision and inspect the calculation when needed.
Reproducibility: Planning calculations record inputs, seeds, source hashes, and result identities. Saved evidence is explicitly labeled replay; a failed backend request cannot silently become a successful prerecorded result.

Sponsor integrations

We added a sponsor integration lab around the existing calculation services:

Photon 2.0: Bounded planning commands and an operator-authorized API path for sending a computed reply to a configured space. Local previews send no message, and API acceptance is tracked separately from delivery.
Chalk: A versioned 15-case acceptance suite checks budget and capacity constraints, financial conservation, unsupported clinical changes, stale inputs, and failure handling. An optional Chalk Compute path packages the actual task and scorer, runs the evaluation, and inspects remote result rows.
Factory Droid SDK: An optional streamed SDK session proposes bounded operational changes through restricted Concord tools. The original engine independently evaluates the proposals and can reject a change that produces no benefit. Clinical criteria remain immutable.

The provider paths are implemented with explicit authorization gates. At our verified submission revision, live provider completion remained unverified: Photon API access/configuration, Chalk compute-environment setup, and Factory catalog authentication still needed resolution. We report local execution, provider readiness, and authentic remote receipts separately.

Challenges we ran into

Changing direction after the evidence changed. Our initial idea was more ambitious than the public data could support. Publishing the negative results meant rebuilding the product around a narrower problem with a clearer evidence base.

Making a budget understandable without overstating it. A public reimbursement benchmark, an assumed operating cost, and a negotiated trial price have different meanings. We had to carry those distinctions through calculations, charts, exports, and explanations—not just place a disclaimer at the bottom.

Working with incomplete public data. Some sponsors anonymize sites. Registry records do not directly supply Medicare localities, detailed operating capacity, or site-level enrollment. Some procedure codes have no usable Medicare amount. We preserved missing and unknown values instead of turning them into zero costs or affirmative capabilities.

Keeping the demonstration reproducible. A working screen was not enough. We tested the real frontend-to-backend workflow, exported evidence, stopped the backend to inspect failure behavior, and verified that opening saved evidence clearly changes the execution label to replay.

Integrating external tools honestly. Installed SDKs and configured credentials did not establish successful provider execution. We had to distinguish a local test from a remote run, a completed evaluation from a passing evaluation, and an accepted message from a delivered message.

Accomplishments that we're proud of

A reviewable protocol-to-budget workflow with sources, assumptions, and unpriced items visible at the line level.
Exportable term sheets and counter-proposals that preserve the reasoning behind the numbers.
A published negative research result that directly shaped the product we chose to build.
Trial import beyond the hand-authored demonstration examples.
A separate synthetic planning workflow with reproducible inputs and evidence, without presenting its outputs as clinical forecasts.
At the latest verified integrated revision, 618 backend tests and 55 frontend tests passed, alongside type checking, production build, lint, and GitHub CI. Another 102 data-dependent backend tests were skipped and reported because optional datasets were unavailable. Actual browser interactions also verified the local sponsor workflow, all six planning-demo scenes, and explicit failure/replay behavior.

What we learned

The missing data defines the question you can answer. Trial-level enrollment totals cannot establish how each individual site performed. Credible site-selection evaluation needs more granular, time-appropriate evidence than our public dataset supplied.

Showing the limits of a benchmark can be useful. Public CMS rates anchor only about a fifth of our illustrative budget. Exposing that share helps reviewers see which lines have a common reference and which still need discussion and justification.

Explainability belongs in the data model. Sources, assumptions, overrides, and unknown values need to travel with a calculation into its comparison and export. Adding an explanation afterward is much harder to keep consistent.

Verification includes the failure path. A reproducible result needs recorded inputs and a clear execution mode. A visible error is more trustworthy than a polished screen that quietly substitutes old output.

A rejected recommendation can be a successful result. When extra outreach spending had no supported modeled effect, the evaluator retained the baseline. That helped us build tools that can report no benefit without inventing an improvement for the demonstration.

What's next

Extract schedules of assessments from full protocol documents, with citations and human review of ambiguous items.
Support pricing additional sites by ZIP code, with explicit Medicare-locality mapping.
Validate the budget-review workflow with research coordinators, coverage analysts, and sponsor budgeting teams, measuring review effort and agreement rather than assuming faster trial activation.
Complete provider configuration and collect authentic Photon, Chalk, and Factory execution receipts before claiming live integration success.
With appropriately authorized, time-versioned site-level enrollment data, revisit whether site-selection recommendations hold up prospectively.

Our next step is to test whether a shared, inspectable budget helps sites and sponsors resolve disagreements more efficiently. That is the practical question Concord is built to investigate.

Built With

clinicaltrials.gov-api
cms-clinical-laboratory-fee-schedule
cms-physician-fee-schedule
fastapi
ffmpeg
leaflet.js
numpy
puppeteer
pydantic
pytest
python
react
scipy
sqlite
typescript
uvicorn
vite

Submitted to

HackHarvard2026: Hack to the Moon

Created by

I helped get our idea validated and gathered feedback from mentors after we pivoted twice from different parts in the clinical trial process. I evaluated different ideas and directions, worked on the write-up and pitch, helped with design decisions, and helped integrate the sponsor tracks.

Akshat Singhania
I designed and built Concord end to end, from the ClinicalTrials.gov crawler and database of 7,221 NSCLC trials to the enrollment models, congestion regressions, and held-out tests. I built Protocol to Terms with Medicare coverage and locality-specific pricing, site comparisons, proposal checks, counter-proposals, and NCT import. I also developed Portfolio Overlap, Site Scores, Findings, and Research, along with the FastAPI backend, React frontend, tests, competitor analysis, demo, and documentation.

Michael Zhou
I helped drive Concord’s two major pivots: from clinical trial site allocation toward financial coordination among pharmaceutical sponsors, hospitals, and insurers, and then toward a transparent protocol-to-budget workflow.
I explored how insurance coverage, routine-care costs, and sponsor-funded research expenses could fit into trial budgeting. I also investigated whether potential savings could be reinvested in recruitment and portfolio efficiency, helping distinguish promising hypotheses from claims our data could support.
I evaluated alternative product directions, gathered mentor feedback, and helped translate that feedback into product and technical priorities. I coordinated development and independent verification, contributed to interface and product design decisions, and helped shape the project write-up and pitch. I also helped coordinate the integration of the Photon, Chalk, and Factory sponsor challenges into Concord.

kevinsrun