When the Systems Belong to the Sponsor

The view a site does not have

Most sites are in one of two situations. Either they have no site systems of their own and work entirely in the ones each sponsor provides, or they have a CTMS with some of their studies in it and work in a sponsor’s systems for the rest. In both, ask a coordinator what is happening on Thursday and the answer does not come from a system. At best it comes from a document they keep themselves and have kept current. Otherwise it comes from opening each study’s system in turn and adding it up, or from memory, or from asking whoever knows. The question spans studies, and no system they use does.

This is not a gap in any one product. Systems are selected per study, sensibly enough, and the consequence at the site is that a coordinator on four studies works in four sets of systems, each of which knows about one quarter of their week.

A site CTMS is a good answer for the studies it holds, and that is the limit of it: it holds the ones the site put in. Studies where the sponsor’s system is the system of record, and studies onboarded before the CTMS arrived, are each a hole in the same picture — and a CTMS with most of your studies in it still cannot tell you what Thursday looks like.

With no site systems at all there is not even a partial view to fall back on: everything is somebody else’s system, one per study, and the only place the studies meet is a spreadsheet on the shared drive.

What is actually missing

It is worth being precise, because “we need one system” is the wrong conclusion and sites have bought that mistake before.

The calendar. Not each study’s visit schedule, which the sponsor’s system holds well enough. The site’s own week: every patient from every study, in the rooms and chairs the site actually has, staffed by people who are certified on some instruments and not others. Two studies can each be scheduled correctly and still put both dosing visits in the only infusion chair on Tuesday morning.

The patients. A coordinator does not carry a caseload per study. They carry the patients they are responsible for, and those patients are scattered across systems that never mention each other. Which of mine are due this week, which are overdue, which are waiting on something.

What is outstanding. Every study leaves work behind after a visit, and each system knows only about its own share. Nothing puts the unfinished work from four studies into one list, so it lives in a person’s head or on paper.

The people. Staffing is a site-level problem — who is delegated for what, who is certified on which instrument, who is already committed on Thursday afternoon. It is answered per study by systems that cannot see each other’s bookings.

Each of these is a site-level question. All of them are asked of study-level systems, which is why the answer always comes from a document somebody maintains by hand.

The Layer Nobody Owns sets out why that document exists at every site, whatever systems it owns. This article is about what happens to it when the systems belong to sponsors.

Why owning fewer systems makes it worse

The obvious reading is that a site with sponsor systems is simply behind a site with its own. That is not quite it. The site with its own CTMS and eSource has the same missing view; it just has more of the raw material in one place.

Two things get harder when the systems are not yours.

You cannot configure your way to it. A site that owns its CTMS can at least add fields, adjust a report, get closer to the picture it wants. A site working in a sponsor’s system configures nothing. The system serves the study it was bought for.

Nothing accumulates. Studies end and access is withdrawn. Whatever the site learned about running that protocol — the sequence that works, the sponsor’s reading of a criterion, the lab’s actual cutoff — was either written down somewhere the site controls, or it left with the login.

So the site that owns least has the most to keep by hand, and the least to show for it afterwards.

What would fix it

A layer above the systems, holding the site’s own view, and not a replacement for any of them.

It has to be one place for every study, whether the study runs in the site’s systems, a sponsor’s, or none. A view that covers most of the studies is the problem restated.

It has to hold what the site knows, not just what the systems hold. The order that works, the sponsor’s reading of a criterion, the courier’s real cutoff: this is the material that has no home in a study-level system and disappears when the study does.

It has to schedule against what the site has — rooms, equipment, certified staff — because that is where studies collide and no study-level system can see the collision.

And it has to reach the systems rather than replace them. The clinical record belongs where it is. What the site needs is not a copy but a way in: from the patient in front of them to that patient’s record in whichever system holds it.

That last requirement is the one that decides whether any of this is usable, and it is worth taking on its own.

Getting to the patient, not just the system

A unified view that makes you go and find the right system, log in, and search for the subject has not saved anyone anything. It has added a screen.

Most software offers a link to the system itself, which leaves the coordinator on a home page navigating to the patient — on every system, for every patient, every time. That is exactly the work the unified view was supposed to remove.

What a site actually needs is to get from the patient in front of them to that patient’s page in the sponsor’s EDC, in the IRT, in the lab portal. Not the system. The page.

The obstacle is that every system addresses its pages differently, and nobody publishes how. So a link that goes to the right place has to be worked out system by system, and no vendor can ship it in advance.

How CRC-Hub does it

One hub, across every study. CRC-Hub holds the site’s whole operation, not one study’s: the calendar with every patient on it, the people and rooms and equipment each visit competes for, and the open items from all of them in a single list. Studies that run in the site’s own systems and studies that run in a sponsor’s sit in the same view, because CRC-Hub is not the system of record for either. It holds how the work is run, and links out for everything else.

Smart Links. This is the part that makes the view usable rather than decorative. CRC-Hub includes a framework that learns a system’s URL structure from an example. A coordinator opens the sponsor’s EDC on one patient, drags that link into CRC-Hub, and the framework works out the pattern: which part of the URL identifies the subject, which part identifies the study, what stays fixed. From then on, that system’s link on any patient’s checklist goes to that patient’s page.

The cost is one drag per system, done once by whoever sets the study up. What the site gets back is that every step naming a system carries a way into it — positioned where the work is, on the patient it concerns.

That is what makes it a hub rather than a directory. The site’s own view of its week, and from any point in it, one step into whichever system owns that piece of the work — whether the site bought that system or a sponsor did.

Two companion articles cover the rest of the case: The Layer Nobody Owns for why this layer is missing at every site, and Running on Paper Is Not the Problem for what changes when the source is captured on paper.

The fastest way to judge it is against your own operation. Tell us how many studies you run and how many of their systems you own, and we will show you the week: CRCHub@triradial.com.