Platform Overview

Purpose-built for clinical enrollment operations

Three interdependent components handle what coordinators currently do by hand: parsing protocol I/E criteria into machine-readable logic, querying your EHR population through FHIR R4 APIs, and returning ranked candidates with criterion-level explanations and a full audit trail. Patientrig is not a CTMS and does not replace your EHR — it is the matching layer between them.

PLATFORM WORKFLOW

Protocol Ingestion
PDF, Veeva Vault, manual entry
Criteria NLP Parser
I/E criteria → structured queries
EHR Query Engine
FHIR R4 API, real-time population
Ranked Shortlist → CTMS
Scored candidates with explanations

Core Capabilities

Three pillars, end to end

Criteria parsing, EHR matching, and enrollment analytics — each component is built for the specific data structure and failure mode of that step in the identification workflow.

Criteria Parsing Engine

Protocol PDFs are ingested and I/E criteria are parsed into machine-readable logic trees. The parser handles temporal constraints ("eGFR ≥60 within 90 days"), compound exclusions with AND/OR branching, ontology references (SNOMED CT, ICD-10, RxNorm, LOINC), nested conditionals, CTCAE toxicity grade thresholds, and prior-treatment lookback windows. Ambiguous criteria — "recent MI" without a defined lookback — are flagged for coordinator review rather than silently resolved.

EHR Matching & Eligibility Scoring

Parsed criteria are translated to FHIR R4 queries against your EHR — targeting Observation resources for lab values (HbA1c, eGFR, BMI), Condition for ICD-10 diagnoses, MedicationRequest and MedicationStatement for drug history, and AllergyIntolerance for exclusion checks. Each patient receives an eligibility confidence score (0–100) reflecting how completely available EHR data confirms the protocol, alongside a data completeness signal identifying which criteria had missing or stale source data.

Enrollment Funnel Analytics

Per-protocol dashboards show candidate pool size, screening yield (candidates contacted vs. consented), screen failure rate by criterion, and days-to-first-patient projection based on current outreach pace. Coordinators track where patients drop out of the funnel and which criteria account for the most screen failures — the data that supports protocol amendment discussions with the sponsor.

Criterion-Level Explanations

Every patient card shows which criteria were confirmed by EHR data, which had missing or outdated source values, and which require manual coordinator review. No opaque scores — the reasoning behind each eligibility confidence number is visible and auditable before the coordinator picks up the phone.

Protocol Amendment Handling

When a protocol amendment modifies I/E criteria — a common event in Phase II adaptive designs — Patientrig re-parses the updated criteria and re-scores the candidate pool. Coordinators see a diff view: who became eligible, who fell out, which specific criteria changed and how that affected each patient's score.

Immutable Audit Log

Every query run, score generated, and coordinator action is recorded with timestamp, user identity, and action type. Logs are append-only, exportable as CSV or JSON, and designed to support GCP documentation requirements for sponsor audits. Electronic signature fields are available for pre-screen confirmation in 21 CFR Part 11 aware environments.

API-first Design

Query your trial population programmatically

Patientrig exposes a REST API for sites that want to integrate candidate data into existing dashboards, trigger notifications on new matches, or pull ranked lists into custom CTMS workflows.

  • JSON responses with criterion-level match detail per patient
  • Webhook notifications on new high-score candidates
  • API keys scoped per protocol — no cross-trial data leakage

See it in action

A 30-minute demo with your own protocol data.

Bring a recent protocol. We'll show you a ranked candidate list built against your site's EHR population before the session ends.