AI for Clinical Trials: Patient Selection and Monitoring

Why AI in clinical trials stalls at patient selection

Inclusion and exclusion criteria number in the dozens, and they don't live in one place. Some are defined structurally: diagnosis codes, lab values, age, disease stage.

Some exist only in the textual descriptions of the protocol, where a phrase like "absence of clinically significant concomitant pathology" requires reading the entire medical history.

The data itself, meanwhile, is scattered across the laboratory system, medical records, hospitalization registries, and screening examinations.

That's where the most expensive part begins. Pre-screening is done manually: a single site means dozens of hours of chart review, and the result depends on who is doing the looking.

Two coordinators working from the same dataset produce different lists, and repeating the selection a month later under the same criteria doesn't work — people, data extracts, and reading rules change.

Some patients are lost not because they don't qualify, but because an eligible case simply never came into view.

The hidden cost isn't just hours.

As long as selection isn't reproducible, you can't prove the criteria were applied equally to everyone: an audit question requires re-reading the source documents, and discrepancies between lists call into question the data quality of the entire study. Losing patients stretches recruitment and shifts timelines across the whole protocol.

We break down how this bottleneck gets closed: how to turn textual criteria into verifiable queries against the data, bring scattered sources into a single layer, and make selection repeatable.

The effect of implementation: recruitment speed and data completeness

We measure the effect by before-and-after metrics on the same patient flow: how much time pre-screening took, what share of invited patients passed the inclusion criteria, how many manual cross-checks the coordinator performed per participant.

This shows what changed because of the model rather than seasonality — and where recruitment speed was hitting the manual step.

Reducing pre-screening time

The model reviews electronic records and ranks candidates against the inclusion and exclusion criteria; the coordinator gets a short list with a rationale for each item.

Pre-screening shrinks from days to hours, and the share of eligible patients found grows: the rules are checked against the entire dataset, not just those who happened to come into view.

The effect on screen-outs is visible separately: a patient who drops out during criteria checking no longer consumes a visit slot. Two classes of error disappear — the missed eligible patient and the invited ineligible one.

A single patient profile instead of manual cross-checks

Data from medical history, labs, and diaries are consolidated into a single profile per the CDISC standard — with source and timestamp indicated for each field. The number of manual cross-checks falls: discrepancies between systems are caught by a rule, not a person.

Profile completeness becomes measurable — the share of filled mandatory fields is visible on a control dashboard, and gaps are closed before the visit.

Reproducibility rests on locked-down selection and data-quality rules with a version log: a repeat run on the same dataset yields the same candidate list, and every decision is explainable to an auditor.

Comparing approaches: rules, model, hybrid

Rules, a model, and their combination solve one task — does the patient fit the protocol — but they fail in different ways.

Rules give a reproducible answer and a clear reason; the model catches non-obvious combinations of features but requires data and an explanation of its decision.

The choice depends on data maturity and how formalized the protocol is. Below are the options people actually choose between.

Where rules are more reliable than the model

When inclusion and exclusion criteria are written unambiguously, rules win: the result doesn't change between runs, and a patient's rejection is explained by a protocol item. The audit sees conditions and thresholds, not model weights.

Where the model outperforms rules

If there are dozens of overlapping criteria, the rules conflict with each other, and thresholds screen out patients the protocol allows. The model ranks the flow by likelihood of matching — borderline cases go to manual review by a specialist.

How implementation of an AI model into the patient flow is built

Implementing a model into the patient flow is not installing an off-the-shelf product but a sequence of engineering work where each step builds on the result of the previous one.

The order matters: skip the audit of selection criteria and the model will train on a biased sample, leaving you to chase the error in a live recruitment process.

Data and criteria audit

1. We break down the sources: where patient data lives, how diagnoses and lab results are coded, which inclusion criteria are applied in practice and where they diverge from the protocol.

2. We agree on the data schema: which fields the model receives as input, how often, who is responsible for completeness, and how missing and stale records are handled.

3. We prepare labeling and train the model on investigators' decisions, checking which features it uses — this is a sanity check, not just quality numbers.

4. We assemble the integration scheme with production systems: extracts or an API, request logging, role-based access control.

Validation on historical data

• We run the model over closed studies: how many eligible patients it found, how many it missed, and what share were false positives.

• We lock down the maintenance procedure: when we retrain on a protocol change, at which thresholds the model stops and hands the decision to the investigator.

• We hand the client's team documentation, specialist training, and incident-response procedures.

Project artifacts: access rules, data schemas, procedures

A patient selection project ends not with a presentation but with a set of working documents the research team uses to continue without us.

Everything describing the selection logic, data access, and model maintenance is handed over as current configurations and procedures — they can be re-read, modified, and passed to another vendor.

Access rules and role separation

• Data schema: entities for studies, visits, inclusion criteria, and lab values, their relationships, and the de-identification rules applied before feeding the model.
• Role matrix: which investigators, coordinators, and data specialists see personal data and which see only de-identified extracts.
• The procedure for granting and revoking access, including actions when an employee leaves the team.
• Logging of data access: it records who extracted a sample and when, and who changed the selection rules.

Maintenance and update procedures

• Selection rules with an edit history: you can see which change produced which result on the validation sample.
• The procedure for validating the model on new data and the thresholds at which it goes back for rebuilding.
• Instructions for the research team: how to prepare an extract, how to read the candidate report, where to report discrepancies.
• An update plan for protocol changes — what gets rebuilt and what gets reconfigured.

Case study: reduced patient screen-outs at pre-screening

We worked with a network of research sites: several active protocols at once, hundreds of candidate charts per week. Selection was run by a coordinator, and the bulk of the time and candidates was lost precisely at pre-screening.

The original selection scheme

Inclusion and exclusion criteria were written into a spreadsheet, then manually cross-checked against the charts — structured fields, prescriptions, free-text conclusions.

A single protocol took hours, roughly a third of the initial sample reached screening, and some eligible patients were screened out before ever contacting a physician.

False positives hit separately — candidates who passed the filter formally but didn't fit on clinical details. Re-checking them consumed up to a quarter of the physician's time.

The result after implementation

We described the protocol criteria in machine-readable form and built a pipeline: feature extraction from fields and text, matching against the criteria, ranking of candidates.

Constraints on lab thresholds, dates, and concomitant therapy are checked before a chart reaches a human. Registries like ClinicalTrials.gov are parsed into the same rule set, so a new recruitment drive launches without manual rework.

Pre-screening time for one protocol dropped from hours to tens of minutes, the share reaching screening more than doubled, and manual cross-checks per candidate fell severalfold. The false-positive rate fell from a quarter to a few percent.

Every decision is explainable: you can see which criterion triggered, so the coordinator reviews the disputed fragment rather than the whole chart. This closes the main risk — silently missing an eligible patient.

What to do when patient data lives in different systems?

Identical systems are almost never found at a clinical site: the lab delivers results through its own extracts, the front desk keeps the schedule separately, the pharmacy and the patient chart live in their own environments.

Stitching this together manually by surname means losing hours per candidate and still not having a reproducible picture.

Integration with systems starts not with files but with a key registry: which identifiers exist in each source, which one is stable, and what to do when a field is empty.

The single patient profile is assembled in two passes. First deterministic matching by national ID and protocol number, then probabilistic — by date of birth, sex, a match on the start of the full name, and contact.

The threshold is configurable: below it a record goes into quarantine with a flag rather than dissolving into the model as a "near match."

Then come the mandatory cross-checks. The visit date is checked against the collection date, values against the source's units of measure, and concomitant therapy against the screening window.

A discrepancy in an inclusion criterion or a lab value is critical: such records are not averaged and the "latest is not simply taken" — the conflict is recorded and sent for manual validation.

Labeling relies on that same profile: the annotator sees the full chronology, and each label carries a reference to the source and record version. If a discrepancy still leaks into training, the model reproduces it as a pattern.

That's why only the confirmed version of the profile enters the sample — with a log of who verified it and when. When sources deliver data in the HL7 FHIR standard, matching gets simpler, but conflict checking remains mandatory.

Technical concerns: labeling, privacy, false positives

Concerns at this stage are usually not about what the model can do but about how it behaves on live data: how many false positives will reach the coordinator, what happens to a patient's personal data, who is responsible for labeling quality. We answer each area separately.

How is the personal data issue handled?

Direct identifiers never leave the client's environment: only de-identified records go into the model, and matching against the medical history is performed on the clinic's side.

Access is role-based, data access is written to an immutable log, and retention periods and deletion rules are fixed in a policy rather than in verbal agreements.

Who is responsible for labeling quality and reproducibility?

Labeling follows a single instruction with double review of disputed cases and inter-annotator agreement calculation: a discrepancy is a reason to rewrite the rule, not to "patch" it by voting.

The composition of the training and validation sets is fixed, so the result is reproducible: the same configuration on the same data yields the same metric, not an "approximately similar" one.

What happens to the model after handover?

We hand over not only the model but also a reproducible training pipeline, validation sets, and a maintenance procedure: monitoring input-data drift, scheduled retraining, analysis of every failure with additions to the regression set.

Without this, the metric silently degrades, and rolling back to a previous version becomes impossible.

Let's discuss your task and come back with an estimate and work plan

So that the pilot launch rests on real data rather than assumptions, we'll gather the inputs for your task in advance.

Below is what we need from you to start: without these items, the project estimate turns into a "from-to" range, and timelines shift at the very first stage.

• The study protocol and inclusion and exclusion criteria — we use these to configure candidate selection and prioritization rules.
• A list of sources: electronic medical record, lab systems, patient registries, recruitment databases — what is actually available.
• A de-identified extract for a period — we'll check field completeness, missing-value frequency, and data suitability for model training.
• Requirements for personal data processing and hosting: on-premises environment, isolated segment, access control.
• A responsible clinical expert on the client's side — they confirm labeling and assess selection quality on disputed cases.
• Target metrics: what share of screenings you want to filter out automatically and how much to cut the time to close recruitment.
• The window for the pilot launch and timeline constraints — this determines what we can validate before full implementation.

Describe your task in free form — we'll come back with an estimate and a work plan: pilot launch stages, timelines for each, team composition, and acceptance criteria.

We'll ask clarifying questions before the estimate so the numbers in the plan are workable rather than indicative.