How we validate eligibility logic before go-live

Why validate at all?

Eligibility criteria are written for humans. A line like "no myocardial infarction within the past three months" assumes a reader who can find a discharge summary, read a date, and decide whether a troponin bump in an emergency note counts. When software makes that decision, someone has to check that it makes it the way the study team would. Bond does that before go-live, on the site's own records, with the site's own coordinators, so that the first live match list is one the team already trusts.^⁠[1]

How are criteria turned into checks?

Each criterion in the protocol is broken into the clinical concepts it refers to, the evidence that could establish it, and the time window that applies. The Identify stage links those concepts to Bond's terminology graph so that the many ways a chart can say the same thing, a diagnosis code, a medication, a phrase in a note, all resolve to one check.^⁠[2]

1. 1

   Read the protocol with the study team

   Ambiguous criteria are flagged and resolved with the coordinator or PI before anything is configured. "Adequate organ function" gets the lab thresholds the sponsor actually uses.

2. 2

   Map each criterion to evidence types

   Structured fields such as problem lists, labs and medications are the first source. Notes, pathology and imaging reports are the second. Each criterion records which sources can satisfy it and which can only suggest it.

3. 3

   Set time windows and precedence

   A resolved diagnosis, a discontinued drug, or a lab from two years ago should not count. Each check carries the window from the protocol and a rule for conflicting evidence.

4. 4

   Decide what needs a human

   Some criteria cannot be settled from the chart, for example willingness to use contraception. Those are marked for the pre-screening call rather than the screening pass.

How is the configuration tested against real records?

Once criteria are configured, Bond runs them against a sample of the site's records under the site's business associate agreement and its IRB or privacy board determination for preparatory-to-research review. The output is not a list of eligible patients. It is a list of decisions, one per criterion per patient, each with the evidence the system relied on and a link back to where in the chart it found it.^⁠[1]

• Coordinators review a stratified sample: clear matches, clear exclusions, and the uncertain middle where most errors live.
• Every disagreement is logged with the reason: wrong evidence, right evidence but wrong interpretation, missing evidence, or a criterion the team decided to change.
• Criteria are adjusted and the sample is re-run until agreement meets the study's threshold. Changes are versioned so a monitor can see what was live on any date.

This is the same loop a good coordinator runs in their head when they train a new colleague. Making it explicit is what lets the site sign off on the logic rather than on a demo.

What happens after go-live?

Validation does not stop at launch. Each match the coordinator accepts or rejects in the dashboard feeds back into the study's accuracy report. When the protocol is amended, the affected criteria go through the same configure and test loop before the new version screens anyone. Screen failures at the site are reviewed against the pre-screening decision to catch causes the chart could have predicted.^⁠[1]