Building a Patient Registry That's Usable Two Years From Now

Most sites have a registry. Fewer sites have a registry that produces enrollments. The difference is rarely size — it's structure, consent scope, and whether anyone touches the list between studies.

A registry is a database plus a maintenance habit

The common failure pattern: a site collects names for two years, lands a study, queries the registry, and discovers half the phone numbers are dead and nobody can remember which people agreed to be contacted for what. The list technically exists. It's just not usable.

Treat the registry as an operational asset with an owner, a refresh cadence, and a defined minimum data set. Without those three things, you have a spreadsheet of regret.

Get the consent scope right at intake

This is where most registries are permanently limited. If your consent language only authorizes contact about one study, you cannot repurpose those records later. Work with your IRB on a standalone registry consent or HIPAA authorization that covers:

• Contact for future studies across therapeutic areas, not a single indication
• Storage of basic health information volunteered by the patient
• Duration of the authorization and how someone withdraws
• Whether you may re-contact by text and email, not just phone

The texting permission matters more than people expect. Phone-only registries age badly because call answer rates for unknown numbers are low in most site datasets.

Collect fields you will actually screen on

Resist the urge to build a 40-field intake form. Long forms depress completion and the extra fields go stale anyway. A workable minimum:

1. Identity and contact — name, two contact methods, preferred method, preferred time
2. Demographics — date of birth, sex, ZIP code, language
3. Condition and status — primary diagnosis, approximate diagnosis date, current treatments
4. Hard disqualifiers — the two or three things that exclude people from most protocols in your therapeutic areas
5. Research history — prior participation, current enrollment elsewhere

That set lets you answer the only question that matters when a protocol lands: who is plausibly eligible, and can we reach them today?

Build the refresh into normal work

Registry decay is predictable. Contact information goes bad, conditions progress, people move. Pick a cadence and protect it.

• Quarterly touch on a rotating segment, so the whole list gets contacted at least annually
• Value-first outreach — a short condition update, a newsletter, a note about trials you've opened — rather than only reaching out when you need something
• Flag and retire records after two or three failed contact attempts, instead of leaving dead rows in queries forever
• Update at every visit — coordinators confirm phone and email during routine study visits for anyone also in the registry

Segment before you need to

A registry you can only query as a single blob is slow to use. Tag records by condition, by prior screen-fail reason, and by responsiveness. Screen-fail reasons are especially valuable: someone excluded for an A1c cutoff on one protocol may be squarely eligible for the next one with a wider range.

Measure the registry like a channel

Track how many candidates each query produces, how many consent, and how many randomize. Compare that against paid advertising and referrals. In most site datasets, registry contacts convert better per outreach than cold channels — but only when the maintenance work has been done. If your numbers don't show that, the registry isn't broken; the habit is.