Healthcare & Life Sciences
Clinical Trial Matching API
Protocol criteria are written for clinicians to read, and patient records are written for other clinicians to read. Matching them is currently a person with two screens open.
- Clinical research organisations
- Site management organisations
- EHR vendors
- Sponsor trial operations teams
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Recruitment is the dominant cause of trial delay, and the bottleneck is rarely a shortage of eligible people. It is that nobody can find them. A phase III protocol carries thirty to sixty inclusion and exclusion criteria referencing lab values, prior lines of therapy, washout periods, comorbidities and concomitant medication. Checking one patient against that takes a research coordinator a meaningful part of an hour.
So screening happens on the patients who happen to be in front of a clinician who happens to remember the study. Eligible patients elsewhere in the same health system are never assessed. Sponsors respond by adding sites, which adds cost without addressing the search problem.
Structured criteria matching is a tractable engineering problem with one hard edge. Protocol criteria are prose, sometimes deliberately vague, and frequently depend on a clinical judgement that no record contains — 'adequate organ function', 'life expectancy greater than twelve weeks', 'no clinically significant cardiac disease'. A system that resolves those to true or false is lying. The useful design treats them as a third state and hands them to a clinician.
Who buys this
Clinical research organisations, Site management organisations, EHR vendors, Sponsor trial operations teams
What the API returns
What comes back
- Ranked candidate shortlists per study, with a match score and criterion count
- Per-criterion evaluation marked met, unmet or undetermined, with the record evidence for each
- Explicit reasons for exclusion, so a near-miss is visible rather than silently dropped
- Undetermined criteria listed as a clinician work list, not resolved by inference
- Structured protocol representation parsed from the criteria text, with the original wording retained
- Reverse matching: studies a given patient may be a candidate for
- Cohort feasibility counts for a draft protocol before it is finalised
- Freshness and completeness flags where the record lacks the data a criterion needs
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/studies/{id}/candidates | Candidate shortlist for one study |
| POST | /v1/patients/{id}/studies | Studies a patient may be a candidate for |
| GET | /v1/candidates/{id}/criteria | Per-criterion evaluation with evidence |
| POST | /v1/protocols/parse | Turn criteria text into structured criteria |
| POST | /v1/feasibility | Cohort counts for draft criteria |
| POST | /v1/candidates/{id}/disposition | Record the coordinator's screening outcome |
Request and response
illustrativeRequest
{
"study_id": "NCT-example-04412",
"cohort": "all_oncology_active",
"max_candidates": 50,
"include_undetermined": true,
"min_criteria_met_ratio": 0.8
}Response
{
"study_id": "NCT-example-04412",
"evaluated_at": "2026-10-22T11:02:00Z",
"patients_evaluated": 8412,
"candidates": [
{
"candidate_id": "cand_0171",
"patient_ref": "pat_44120",
"match_score": 0.88,
"criteria_met": 38,
"criteria_unmet": 0,
"criteria_undetermined": 4,
"status": "for_clinician_review",
"criteria": [
{ "id": "inc_01", "text": "Histologically confirmed stage IIIB or IV NSCLC",
"state": "met", "evidence": "pathology report 2026-05-11" },
{ "id": "inc_07", "text": "ECOG performance status 0-1",
"state": "undetermined", "reason": "No ECOG recorded in last 90 days" },
{ "id": "exc_04", "text": "No clinically significant cardiac disease",
"state": "undetermined",
"reason": "Requires clinical judgement; not derivable from record" },
{ "id": "exc_09", "text": "No systemic therapy within 21 days",
"state": "met", "evidence": "last administration 2026-09-02" }
]
}
],
"note": "Shortlist for clinician review against the protocol. Not an eligibility or enrolment determination."
}Where the data comes from
| Your own patient records | Structured EHR data plus extracted content from notes and pathology reports, read inside your environment under your governance approvals |
| Public trial registries | Protocol criteria text, status and site information from the public registries, which is openly available but inconsistently structured |
| Sponsor protocol documents | Where you hold them, the full criteria carry detail the registry summary omits |
| Clinical terminologies | ICD, SNOMED CT and LOINC to reconcile how a condition or analyte is written in a protocol against how it is coded in the record |
| Medication reference data | Drug class and ingredient mappings, needed because washout and concomitant-medication criteria are written at class level |
| Coordinator screening outcomes | Confirmed eligible and ineligible decisions, which calibrate the ranking and reveal criteria the parser is reading wrongly |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Protocol parsing into a structured criterion tree with logical operators, temporal windows and thresholds preserved
- The original criterion wording returned alongside every evaluation, so a coordinator checks the parse rather than trusting it
- Three-state logic throughout — met, unmet, undetermined — with no default resolution of missing data in either direction
- Criteria requiring clinical judgement classified as such at parse time and never evaluated automatically
- Temporal reasoning for washout periods and prior-therapy lines, which is where most naive implementations go wrong
- Ranking by criteria met and by how cheap the undetermined items are to resolve, so coordinator effort goes where it pays
- Validation against historically screened patients where you have them, measuring both missed candidates and false shortlisting
- Monitoring for protocol amendments, which invalidate every prior evaluation for that study
What it changes for the business
Wider screening reach
Candidate identification runs across the whole eligible population rather than the patients a clinician happened to recall the study for.
Coordinator time redirected
Effort shifts from reading records against criteria to resolving the small number of genuinely undetermined items.
Feasibility before commitment
Draft criteria can be counted against a real population before a protocol is locked and sites are contracted.
Auditable screening trail
Each shortlist decision carries the criterion and the record evidence, which is what a monitoring visit asks for.
How it fits into your product
How it embeds
- Deployed inside your own environment, with patient records never leaving it and only de-identified counts crossing a boundary if you choose
- Batch evaluation across a cohort on a schedule, plus on-demand evaluation for a single patient
- Coordinator work lists delivered into your existing CTMS, or as prebuilt review components with evidence links
- Webhooks when a newly recorded result moves a patient into shortlist range
- Consent and governance gating, so a patient is only evaluated where your approvals permit it
- Protocol versioning, with re-evaluation triggered automatically on amendment
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Does this decide whether a patient is eligible?
No. It produces a candidate shortlist for clinician review against the protocol, and the response says so explicitly. Eligibility and enrolment are clinical and regulatory determinations made by the investigator, with informed consent. We would not build an automated enrolment path and would push back hard on a design that implied one.
What happens to criteria the record cannot answer?
They are returned as undetermined, with the reason. Criteria like 'adequate organ function' or 'no clinically significant cardiac disease' require judgement that no record contains, so the system classifies them as judgement criteria at parse time and never guesses. Treating a missing value as met would create false candidates; treating it as unmet would hide real ones.
How reliable is parsing protocol criteria?
Good on quantitative criteria with explicit thresholds and windows. Weaker on prose criteria with nested conditions, and dependent on the registry text being complete, which it often is not. The original wording is always returned next to the parse for exactly that reason. Where you hold the full protocol document the parse is noticeably better than from a registry summary.
Can patients be contacted automatically?
Not from this service. Approaching a patient about a study is governed by your ethics approvals, consent arrangements and local rules. The API produces a work list for the people who hold those permissions; it has no outbound patient contact and we would not add one.
Does it work across multiple health systems?
Technically yes, operationally rarely. Each system's data sits under its own governance, and a cross-system cohort generally needs either de-identified federated counts or an agreement that does not exist yet. We would scope a single-system deployment first and treat federation as a separate problem.
Related blueprints
Medical Literature Intelligence API
Search, evidence summaries and citation-linked findings across the published literature, embedded in tools clinicians and researchers already use.
Medical Document Extraction API
Structured fields pulled from clinical notes, lab reports and referral letters, returned with per-field confidence for review.
Appointment No-Show Prediction API
Cancellation and no-show probabilities per appointment, built to add capacity through reminders and overbooking rather than to ration care.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.