Building a Patient Database for Clinical Trial Feasibility

The patient population section is arguably the part of a feasibility questionnaire sponsors scrutinize hardest, and it is the one sites most often answer weakly. "We see a lot of diabetes" is not an answer. "Approximately 1,400 patients with type 2 diabetes seen in the last 12 months, of whom roughly 300 would meet typical HbA1c and medication criteria, based on an EMR query run on October 1" is — and it's the difference between being shortlisted and being politely declined.

This article is about building that answer once: a feasibility patient database, meaning an aggregate, non-identifying picture of who your site actually treats, kept current and ready to cite. It sits inside the broader site feasibility process and feeds the population questions on every feasibility questionnaire.

What "patient database" means here — and what it doesn't

For feasibility purposes, the database is counts, not records. At the feasibility stage, sponsors are asking for counts, not names, charts, or identifiers — and your answer should never include any. They want to know how many patients with a condition you can reach, broken down in ways that map to protocol criteria. Everything below works on aggregate numbers: "412 patients with COPD, 180 of them aged 40–75" — never a list of who those patients are.

That distinction matters beyond etiquette. Aggregate counts are what feasibility needs, and keeping individual patient data out of the business-development process keeps the privacy questions you have to answer narrower. (This is a design principle, not legal advice; your practice's own privacy and compliance policies govern what you query and share.)

Step 1: Pull counts by condition from your EMR

Start with the conditions your site treats most and the ones sponsors in your specialties recruit for. For each, run an EMR query for active patients with the diagnosis — many systems can report counts by ICD-10 code or problem-list entry — over a defined window, typically the last 12 to 24 months. Record three things for every count: the number, the query definition (which codes, which window), and the date you ran it.

A few practical points sites learn the hard way:

• Active patients, not lifetime. A patient last seen four years ago is not reachable for a trial. Pick a window and state it.
• Code carefully. "Diabetes" might mean E11.x only, or E10–E13; a sponsor's protocol will care which. Note what you included.
• Count patients, not visits. EMR reports sometimes default to encounters.

If your EMR can't produce this easily, a one-time report from your vendor or a billing-system export usually can; many sites keep a simple spreadsheet of condition → count → query date → notes.

Step 2: Build the inclusion funnel

The raw count is the top of a funnel. Most protocols then filter by age, disease severity or a lab marker, treatment history, and exclusions like competing conditions or medications. You won't know a specific protocol's criteria in advance, but common criteria for an indication are predictable, and sponsors tend to respond well to a site that has already thought in funnel terms:

1. Patients with the diagnosis (your EMR count)
2. Within the usual age range for trials in the indication
3. Meeting a typical severity or lab threshold where one exists
4. Not excluded by common comorbidities or medications
5. Realistically consentable — live near enough, engaged with the practice, likely to say yes

Each step cuts the number, often substantially. A site that reports "1,400 with the diagnosis, roughly 300 likely protocol-eligible, and we'd expect to consent a fraction of those" is giving a sponsor exactly the shape they'll use in their own analysis. A site that reports "1,400" is handing the sponsor a number they'll discount by their own guess — often a harsher one than yours.

Where age and sex distributions are easy to pull, include them; they map directly onto the age bands most questionnaires ask for.

Step 3: Keep it current

A feasibility database decays. Patients move, diagnoses change, the practice grows. A count with a query date more than a year old reads as stale, and a sponsor may ask you to re-run it anyway. Set a refresh cadence — quarterly is a reasonable default — and re-run the same queries so the numbers are comparable over time. Note the date on every refresh; the date is part of the answer.

This is also the moment to record anything that changed: a new provider who brought a patient panel, a new location, a condition you've started treating. Each one is a new line in the database and potentially a new category of study you can compete for.

Step 4: Decide how you'll show it

Sponsors see the numbers in three places: the feasibility questionnaire, your site profile or capability packet, and the qualification visit, where the CRA may ask how you arrived at them. Make the numbers consistent across all three — same counts, same query dates — and be ready to explain the query. "Here's the EMR report, run on this date, with these codes" is a sentence that ends the discussion in your favor.

A sponsor-ready site profile typically presents population as a short table: condition, approximate active count, notable sub-populations, last reviewed. That table is most of the population section on any questionnaire you'll receive.

How sponsors check

Sponsors rarely verify counts directly at the feasibility stage, but they can sanity-check them: against what similar practices report, against your enrollment history if you have one, and against what they see and hear at the qualification visit. A number that is far above the pattern for a practice your size invites questions; a number with a clear query behind it doesn't. Over the longer run, actual enrollment against what you reported becomes your track record — which is why the honest funnel, not the round number, is the one that earns the next study.

What TrialWave stores

TrialWave's patient population feature holds this database the way sponsors need it: aggregate counts per condition with an age range, a last-reviewed date, and notes on how the count was derived — and nothing identifying any patient. The same numbers feed the study finder's fit scoring, the site profile, and the Feasibility Answer Bank (on the Site plan), so the population answer is written once and reused on every questionnaire. The population profile is part of the free plan; the Get Site-Ready checklist walks through building it.

---

This is general information, not legal, privacy, or regulatory advice. Follow your practice's own policies for querying and sharing patient data.