One source of truth for pre-screening: why double entry between your tracker and the sponsor system creates errors

By Julio G. Martinez-Clark, Chief Executive Officer (CEO) of Amavita Research Services

At Amavita Research Services, our Miami cardiovascular trial site, we work from a database of more than 18,000 active cardiology patients, and we have maintained zero Food and Drug Administration (FDA) Form 483 findings — the form the FDA issues when an inspection finds conditions that may violate its requirements. I am also CEO of bioaccess, a first-in-human contract research organization (CRO). In both roles, I see the same pattern: most pre-screening errors are systems errors, created by asking good people to maintain the same facts in two places.

Double entry looks safe. It is not.

Double entry starts with a reasonable intention. The sponsor system feels slow, so someone builds a tracker. Soon it holds medications, diagnoses, procedures, allergies, and notes copied from the electronic health record (EHR), the system hospitals and clinics use to store patient care records. Then a coordinator enters the same information into the sponsor's electronic data capture (EDC) system, its database for trial data.

First, the two records drift. A dose is updated in one system on Tuesday and in the other on Thursday. A stopped medication is removed from the sponsor system but stays in the tracker. When the principal investigator (PI), the physician responsible for the trial at the site, reviews eligibility, the team stops asking which record is right and starts wasting time reconciling records that should never have competed.

Second, every extra copy is extra PHI risk. A tracker on a shared drive or attached to an email is harder to control than a validated system with defined access. The more places clinical detail lives, the more places you must secure, audit, and explain.

Third, screen failures get documented late. When a coordinator must finish one system before updating the other, the sponsor system — the one the sponsor actually reads — falls behind, and reasons get written from memory days later, in free text. You still need an internal tool. It just has to stop pretending to be a clinical record.

Decide what the record of truth is

Start with a simple rule, and write it into your standard operating procedure (SOP), the written procedure your team follows for a defined task:

Clinical data lives in the sponsor system. Operational data lives in the internal tracker.

Clinical data includes medications, medical history, diagnoses, laboratory results, procedures, and anything you use to judge an inclusion or exclusion criterion. Enter it once, directly into the sponsor system, where it is subject to the sponsor's edit checks, audit trail, and query process.

When a question arises — is this dose current, was that procedure before the cutoff date — the sponsor system wins. The tracker is never evidence of a clinical fact. If a fact is wrong there, correct it there, through the query and audit process — not quietly in the tracker.

What a minimal internal tracker should — and should not — hold

A minimal tracker has four fields, and restraint is the point.

1. Identifier. A study-specific screening identifier, not a full name combined with clinical detail. Keep the link between the identifier and the person in the system your site already controls for that purpose.
2. Status. A short, defined list only: identified, contact attempted, pre-screening in progress, pending PI review, screen failed, or ready to consent. No improvised statuses.
3. Next action. One action, in plain language: call patient, request records, PI to review, enter outstanding sponsor-system items. If there are three next actions, the true next action is unclear.
4. Date. The date the status changed, and where useful, the date the next action is due.

That is enough to see the whole pipeline in two minutes. What it should not hold matters just as much: no medication lists, no medical history, no diagnosis narratives, no laboratory values, no copied EHR notes. If a field would let someone re-judge eligibility without opening the sponsor system, it does not belong there. Once the tracker can answer a clinical question, people will use it that way — and you are back to two sources of truth.

Prepare for sponsor calls from the sponsor system, not a rebuilt spreadsheet. A pipeline count comes from the tracker. A clinical answer comes from the record of truth.

Build a one-page field map

Rules fail when they stay abstract. Convert yours into a one-page field map before your next study starts, and review it at the site initiation visit, when the sponsor trains the site and confirms readiness.

The map has three columns: field, system of record, and who enters it. List the fields your team touches most — medications, allergies, diagnoses, procedures, identifier, status, screen-failure reason — and give each a single home. If a field appears in both systems, you have not made a decision yet.

Keep it to one page. No one consults a nine-page document at 4:30 in the afternoon when deciding where to type something. Post the map where the team works, attach it to the SOP, and review it when the protocol is amended, the sponsor system changes, or a new coordinator joins. Most double entry is not defiance — it is a new team member copying an inherited habit.

Give status changes a single owner

Statuses go stale when everyone can change them and no one owns them. Assign one owner per study — usually the lead coordinator.

Others can flag a change. The owner makes it, once, on the day the event happens. That reliable date is what lets you spot bottlenecks: how long patients sit at pending PI review, or how long record requests stay open.

Single ownership also prevents a common error: a patient marked screen failed in the tracker while the sponsor system still shows pre-screening in progress. If only the owner closes a status, as one task — sponsor system first, tracker second — pipeline and record stay aligned, and the PI can trust the tracker without asking for clinical detail to double-check it.

Document screen failures once, and code the reasons

Screen failures are data, not disappointment. Sponsors use them to judge whether criteria are realistic and timelines credible — but only if failures are documented once, promptly, in the system of record, with reasons coded consistently.

Enter the failure in the sponsor system on the day the decision is made. Select the coded reason that matches — a specific exclusion criterion, a washout the patient cannot complete, a laboratory value outside range, or patient declined — rather than writing new free text each time. Keep any note factual and brief, and keep detail in the source documents.

Consistent coding pays you back. After twenty failures, you can count how many trace to one criterion and raise that pattern with the sponsor with evidence, not an impression, and separate causes you control — slow record retrieval, late PI review — from eligibility causes you do not. Do not maintain a second failure log. Tracker status and date are sufficient. The reason lives once, coded, in the sponsor system.

What to do this week

You do not need a new platform. You need four decisions, written down. First, declare the sponsor system the record of truth for clinical data, in your SOP. Second, strip the tracker back to identifier, status, next action, and date — remove the clinical fields, do not just ask people not to use them. Third, draft the one-page field map. Fourth, name one owner for status changes and one rule for screen failures: once, on the day, coded, in the sponsor system.

Do that, and pre-screening gets quieter in the best way: fewer discrepancies, less PHI where it never needed to be, a PI review from one trusted record, and a screen-failure picture the sponsor can actually use.