The Layer Nobody Owns

Why your coordinators still run on spreadsheets, and what it's costing you

The argument, in five sentences

  1. Your coordinators run the day out of a spreadsheet they built themselves, and that has been true across two decades and every generation of software you could have bought.
  2. A visit is a long sequence of steps involving eSource, the IRT, the CTMS and other systems, with many landing in no system at all — and nothing you own holds the whole of it, so somebody at the site writes it down, and nothing versions what they wrote.
  3. That isn’t a defect anyone can patch: a system of record has to be structured, audit-trailed and deliberately hard to change, and daily work needs the opposite.
  4. The gap costs you in work you never billed, small missed steps with large consequences, capacity you’re paying for and can’t see, and know-how that leaves with the person.
  5. Closing it means a layer above the systems you already have, holding what none of them holds and replacing none of them.

The paradox

You bought a good CTMS. You may have bought eSource too. Both work, and both do what they were sold to do.

And your coordinators still run their day out of a spreadsheet.

If you’ve assumed that’s a training problem, a discipline problem, or a sign you picked the wrong vendor, it isn’t. It happens at sites with well-implemented, well-liked systems, and it has persisted for two decades across every product generation. That’s the clue: something structural is going on, and no amount of pressure on your staff will change it.

A coordinator’s day

The first thing your coordinator opens is not the CTMS. It’s their tracker: a spreadsheet spanning the four studies they’re on. Some of its columns are copied out of systems you own. Many exist nowhere else.

The morning’s work comes out of it: chase the records for Thursday’s screen, confirm Mrs. R still has a ride, find out whether the amendment came back from the IRB.

The first visit is a Cycle 3 dosing day, and it runs to dozens of discrete steps. The clinical observations go into eSource, the dispense into the IRT, the visit record into the CTMS. Several other systems take a piece, and many steps land in no system at all. Each system does its own part correctly, and none knows about the rest of the steps, or the constraints between them: the courier collects at 15:00, and the ECG has to come before the PK draw.

The only thing that holds the visit end to end is a worksheet somebody at the site wrote, assembled out of the protocol, the manuals, your SOPs and a sponsor’s emails. Nothing owns that worksheet and nothing versions it: the copy in use still says pharmacy needs 24 hours’ notice, which changed to 48 in March.

The same gap catches patients. Ten minutes before he arrives, the coordinator remembers that this one is still on the old consent form and will have to reconsent before anything else happens. Your CTMS may well hold his consent version. Nothing put it in front of the person about to see him.

Mid-morning, the afternoon’s rating visit turns out to need a rater who is at another site today. Nothing anywhere shows where the raters are committed. That visit moves to Thursday, though whether Thursday can take it is a guess, and two other patients get called and rescheduled to make room for it.

By the end of the day, three completed visits from earlier in the week still aren’t entered, because nothing anywhere rolls up what’s unfinished.

Nobody was careless. The stale worksheet, the near-miss on consent, the double-booked rater, the unentered visits all have the same cause: nothing holds the whole of what a day requires.

The tracker and the worksheet

So your coordinators build the two things they work from, and maintain them by hand.

1. The patient tracker

It spans every study the coordinator is on. Many of its columns are copied straight out of systems you already own: subject ID, status, consent version, next visit due. The rest hold what’s outstanding — the reminder call due the day before, the diary to check at mid-cycle — plus the things about a patient that no system stores: who drives them in, that they work nights, that their veins are difficult. Almost none of it has a home anywhere.

It’s the copied ones that are worth noticing. Those columns aren’t copied because your systems lack them. They’re copied because a coordinator can’t put their own columns beside them.

So the tracker isn’t a CTMS replacement. It’s the only place where your systems’ data and a coordinator’s own notes sit together, which is why “just use the CTMS” has never worked. Working in the CTMS gives you those columns back and takes away everything that sat next to them.

2. The visit worksheet

A Word document or a spreadsheet, written once per visit type and reused for every patient who reaches that visit. Usually a separate file from the tracker, with no link between the two: a coordinator carries information from one to the other by hand.

Worked example

Cycle 3 Day 1, as filled in for one patient (window 28 Jul – 1 Aug)

StepWhere it happens
BeforeLabs resulted and reviewed by PI — dosing eligibility confirmedEHR
Kit 4B pulled; expiry ≥ visit datenothing
Pharmacy notified 24h ahead; 45-min thawnothing
Infusion chair booked · rater booked (must be scale-certified)nothing
Consent v4.0 — subject on v3.0, reconsent firsteReg / CTMS
Courier pickup booked — last collection 15:00nothing
DuringVitals, pre-doseeSource
ECG before PK draw — order matterseSource
Dose administered; dispense recordedIRT
PK draw at 30 min post-dose (±2 min)eSource
Rating scale — delegated raters onlyeSource
AfterSamples processed within 30 min; manifest printednothing
Drug accountability updatedIRT / pharmacy
Visit recorded as complete — this is what generates the invoiceCTMS
eCRF enteredEDC
Next visit booked inside windowCTMS
Stipend issuedpayment platform

That is what a thorough worksheet looks like. Plenty of them cover the procedures and little else, and the rest — the preparation, the logistics, the order things have to happen in — is held by whoever has run the visit before and pulled together each time from notes and emails. Whatever the worksheet leaves out lives in someone’s head, and heads have bad days. It is also attention spent on recall at the moments a visit most needs judgment.

The worksheet does not hold still. Protocol amendments change it. Sponsor clarifications change it. So does everything the site learns over the course of the trial: the courier cutoff moved to 14:00; that instrument needs a second rater after all. A careful site may version the worksheet by hand, but even then nothing records which version a given visit was actually run under, and nobody can tell whether the copy they opened this morning is the current one.

The gap

None of your systems is failing; each does its job well. Here is what none of them holds:

  • An end-to-end list of what a visit takes. One sequence per visit type holding everything: the steps that land in a system, the manual work that lands in none, the ordering and timing constraints between them, and the site know-how attached to each, such as how this sponsor reads eligibility criterion 7.
  • A record of what changed, and who is on what. Amendments, sponsor clarifications and everything the site learns all rewrite that sequence. Nothing versions the worksheet, and nothing brings a patient’s current version to the visit about to run.
  • A calendar that books against roles and resources. Not a list of visit due dates: the day itself, where each visit carries what it needs — room, equipment, a rater certified on that instrument, staff delegated for each task, and for how long — so a clash surfaces at booking rather than on the morning. It has to hold coverage too: who is covering whom when somebody is out, and how staff working across more than one site are committed. One view per coordinator, spanning all their studies and the weeks ahead; one for the team, showing who is committed and where the risk sits.
  • The open-items list. Three kinds, none with a home. Visit steps never finished: the CTMS entry that generates the invoice, still unticked three days after the patient went home. Work somebody has to do: the call to make, the records to chase, the reconsent due before the next visit. Things waiting on someone else: an IRB approval, a sponsor query, a pre-authorization. Every one has a deadline and an owner, and nothing anywhere adds them up.

Pieces of all four exist across your systems, none of them whole, none of them anywhere a coordinator can work from. That is what the tracker and the worksheet are for.

Why the gap is structural

Two reasons, and they compound.

A CTMS has to be validated, audit-trailed, structured, and deliberately hard to change, which is exactly what makes it trustworthy for invoicing and inspection. eSource is source data: monitored, verified, inspectable. Both are built for correctness and reconstruction. The work your coordinators do all day needs the opposite properties: fast, flexible, tolerant of half-known answers, changeable this afternoon. A system optimized for auditability cannot simultaneously be optimized for velocity. Your CTMS is a poor daily tool precisely because it is a good system of record.

The second reason is narrower. A CTMS models the visit as a billable event: which procedures are due, whether each was done, what each is worth. That is right for invoicing and reporting, and it is not a model of the work that makes those procedures happen. Preparation, logistics, sequencing, resources, closeout across other systems: none of it is a procedure, so none of it is there, which is most of what a visit takes, and everything between visits.

So the gap isn’t a defect in anything you bought, and no amount of configuring those systems reaches it. No software category was ever built for this job — not CTMS, not eSource, not EDC — which is why two decades of products have left it exactly where it was, and why it has fallen to your coordinators to solve in Word and Excel. It is a missing layer — a work layer, sitting between the systems of record and the coordinator’s day, and no vendor owns it.

What the gap costs you

Money you earned and never billed. There’s no reliable way to tell when a visit is actually finished. The last steps run on after the patient leaves, in several different places, and nothing brings them back together. One of those steps is recording the visit in the CTMS, which is what triggers the invoice. So a visit that never quite gets closed never gets billed.

An amendment fee or a screen failure is just as billable, but it isn’t attached to a visit, so nothing schedules it, nobody is assigned to it, and no checklist mentions it. There is no route from the event to the invoice.

In both cases the billing itself works. Your CTMS will invoice whatever it’s told. What fails is knowing there is something to bill.

A missed step costs more than the step. Miss the courier and the samples don’t ship, so the visit is wasted and the timepoint can’t be repeated. Miss a window and it’s a deviation to write up, explain to the sponsor, and answer for at the next monitoring visit. The steps behind both are small. The consequences aren’t.

Capacity you’re paying for and not using. Some days coordinators are idle, other days everyone is underwater, and specialist staff don’t know where they’re needed. The imbalance is predictable weeks in advance. But your CTMS is built around subject visits. It may let you name a role or a person against one; what it doesn’t hold is everything a visit competes for — rooms, equipment, certifications, who is delegated for what — or how long each one takes. It can tell you twelve visits are due on Tuesday, but not whether Tuesday can run them — and not that an audit or a monitoring visit is booked the same week, taking the same people off study work. The flexibility that would fix it goes unused too, because visit windows allow days of movement but there is no calendar of work and staff to move against.

Turnover costs more than it should. An experienced coordinator is faster because they know what each visit actually takes and where it can go wrong. Some of that is in the worksheet, but the worksheet is incomplete and unversioned, so a replacement inherits a document they can’t rely on and works the rest out again themselves. That knowledge should be an asset of the site; today it leaves with the person. In a role with the turnover this one has, you pay that repeatedly.

What closing the gap actually looks like

This isn’t a case for replacing your CTMS, which should stay exactly where it is. The work layer sits above the systems you already have, and there are five tests it has to pass.

  1. It holds the whole sequence. Every step, including the ones that land in no system, the constraints between them, and the site knowledge attached to each. A checklist assembled only from what other systems already know rebuilds the problem in a new place.
  2. It changes as the trial changes, and records that it did. Amendments, sponsor clarifications, and what the site learns all rewrite the sequence. Which version a given visit was run under has to be a fact, not a recollection.
  3. It books against roles and resources, not just names and times, so a clash surfaces when the visit is scheduled rather than on the morning.
  4. It holds the open items, however they arise. Running a visit leaves work behind — steps still unticked after the patient has gone home. Other work no sequence predicts: the call to make, the records to chase, the query waiting on the sponsor. Each one has an owner and a date, and all of it has to reach one list a coordinator can work from.
  5. It duplicates nothing. The clinical record stays in eSource, the financial record in the CTMS, and the layer links out to both. The moment it becomes a second place to type the same fact, you’ve bought another system rather than closed a gap.

Those five describe the layer. There is a condition on all of them: somebody has to build those sequences, once per visit type, for every protocol. Your coordinators already assemble a rough version by hand, and on a complex protocol that is days of work before a patient is seen. A complete, versioned one is more work than that, not less, and it has to be redone every time an amendment lands. If it falls to the same people who are already the constraint, the bottleneck has moved rather than gone. So the condition is about the building itself: putting a protocol’s sequences in place has to be fast enough that it actually gets done, and changing them afterwards has to be just as fast.

Ask one of your coordinators whether they could answer what do I need to do today? from the systems you own, without opening a spreadsheet of their own. Then ask how they’d know if the worksheet they used this morning was out of date. The answers tell you how much of this applies to you.

The product behind this paper

CRC-Hub

CRC-Hub is built to be this layer, and only this layer. Against the five tests above, in order:

It holds the whole sequence. The per-visit list is derived from your protocol, the manuals, your SOPs and your training material, including the steps that live in no system today, the ordering and timing constraints between them, and the site knowledge attached to each.

It changes as the trial changes, and records that it did. Amendments publish as controlled major versions with per-patient migration; day-to-day site refinements apply immediately; every visit records exactly which version it was run under, and every version is kept in full.

It books against roles and resources. Fifteen-minute scheduling against the staff, rooms and equipment a visit actually requires, with the option to constrain who can be assigned by your delegation of authority, so an undelegated task is caught at booking rather than at a monitoring visit.

It holds the open items, however they arise. Everything the sequence generates stays live until it’s done, with an owner and a date, whether the visit has happened or not. Anything else is added in a line — a call, a chase, a reconsent due before the next visit, an approval waiting on the IRB — and attaches wherever it belongs: to a single step, a visit, a patient, a study, or to nothing at all. It all reaches the same list, on the day it matters.

It duplicates nothing. It links out to your CTMS, eSource, EDC, IRT and sponsor portals. Your systems of record stay exactly where they are, and identifying information stays in them: subjects are carried by study ID and initials.

And getting it in place is fast. The sequences are generated from your documents rather than authored from scratch, so the site’s job is review and correction. After that, changing a schedule or a checklist is something a coordinator or a manager does directly, in minutes, without a configuration request.

A companion piece, Experience Is Not Enough, shows what one of these sequences looks like in the product. If your site still captures much of its source on paper — as most do — Running on Paper Is Not the Problem covers why that is often the right call, and what this layer has to do to support it.

Run the checks on your own site first. If the answers aren’t what you’d want, we would like to be measured against those five tests: CRCHub@triradial.com.

Get your site on CRC-Hub

A short call to understand how your site runs, then you're set up with full access to build your first study.

Back to the overview

CRC-Hub Making the CRC's job suck less.
Contact TriRadial