Age, diagnoses, medications, labs and procedures run as SQL queries across every patient in seconds.
Criteria documented in prose are answered from the notes of the filtered population, each answer tied to its source.
Coordinators review the evidence for each candidate and choose who to approach.
Every patient is checked, not just the charts someone had time to open.
Each criterion is evaluated across the full record, with the source for every answer.
Candidates surface in minutes instead of weeks of chart review.
Reviewers focus on candidates and unresolved criteria only.
Every screening result traces back to its supporting evidence.
Save candidates as cohorts for export, curation or registries.
Import eligibility criteria from ClinicalTrials.gov or paste protocol text.
Evaluate available structured data and relevant clinical notes.
Inspect supporting evidence and identify remaining review needs.
Diagnoses, medications, procedures, labs and demographics run as SQL against your OMOP records. Criteria are checked across the whole population in seconds.
Learn more →Standard SQL against OMOP CDM tables: de-identified, conflict-resolved, scored.
Learn more →Thresholds on derived values such as eGFR or BMI are evaluated on values computed from the patient record, within the time window the protocol sets.
Learn more →Willingness, consent, literacy or transport cannot be answered from records. These criteria are named on the candidate list for the study team to confirm.
Learn more →The available data supports an assessment. The result is shown with the codes, values or note passages behind it.
The record does not hold enough evidence to assess the criterion. The patient stays on the list, flagged, rather than being excluded.
The criterion can only be assessed by the study team, such as consent, willingness or ability to attend visits.
Data handling meets the HIPAA Privacy and Security Rules and GDPR Article 25. Field-level RBAC scopes what each role sees.
Data governance →Original eligibility text, parsed criteria, per-criterion counts and generated SQL are all open to review.
AI governance →We screen your own patients inside your environment. Your team reviews the candidate list against the linked evidence, criterion by criterion.
No. Search recruiting and not-yet-recruiting US trials by disease area, intervention or sponsor, or enter an NCT ID if you have one.
Yes. Paste the eligibility criteria text directly when creating the job. That covers local protocols, investigator-initiated studies, and amendments not yet published to the registry. Include both the inclusion and exclusion sections so the parser preserves the protocol's intended structure.
Criteria that live in narrative text, such as performance status, biomarker results or prior lines of therapy, are resolved by prompting over the notes of patients who already passed the OMOP filtering criteria. Each answer links back to the note it came from, and a patient whose notes do not cover the criterion is reported as unknown rather than excluded.
They are never dropped. Criteria such as willingness to comply or access to transport are labelled for manual screening and listed alongside each candidate. Where your data holds nothing for a criterion, the count says so and shows how many candidates had data for it.
No. It produces a screened candidate list with the evidence behind each criterion attached. Final eligibility requires protocol review and site-specific clinical validation, and the decision to approach a patient rests with the study team and the treating clinician.
Cached reuse is right for a repeated feasibility question against unchanged data. Use Run Fresh when patient data has been reloaded, when the protocol has been amended, or when the matching logic has changed. The job detail page shows a banner whenever results were reused.
No. Matching runs entirely inside your deployment, including air-gapped environments. Trial metadata is retrieved from ClinicalTrials.gov, a public registry containing no patient information. In an air-gapped deployment, protocol text is pasted in rather than fetched.
Demos
