Clinical Research Site Management Software Problems: The 7 That Cost a Network Real Revenue

Why does the budget grid get flattened into one number per visit?

Because that is the shape every system offers, and because the source document invites it. The budget arrives as an appendix in a portable document format file or a spreadsheet, and someone under time pressure at study start-up reads the visit schedule, adds up the procedure lines under each visit, and enters a single figure. The study goes live, coordinators start booking patients, and nobody notices anything is missing because the visits that do occur bill correctly.

What has been deleted is the conditional half of the contract. Screen failure reimbursement at a fraction of the screening visit. Institutional review board fees, pharmacy set-up, records storage and archiving as pass-throughs. Invoiceables that trigger on an event rather than a date. In our delivery experience these are frequently the best paying items per unit of coordinator effort in the whole agreement, and they are exactly the ones summarisation removes.

The fix is structural and it has to be enforced at scoping. The budget grid is a first class object: protocol version, visit definitions, procedure lines with amounts, conditional invoiceables with their trigger conditions, pass-throughs, holdback terms and the payment schedule. When a coordinator confirms that the electrocardiogram and the pharmacokinetic draw happened at visit four, the system generates precisely the lines that contract permits. When a required procedure has no completion record, it says so before the visit closes rather than after the payment cycle. Insist that the first release models your ten highest revenue protocols in full, including the awkward clauses, rather than twenty protocols at summary level.

What goes wrong when protocols and visit history come across from the old system?

Two things, and the second one is worse. The first is that your existing system holds a summarised grid, so migrating it faithfully migrates the problem. Whatever the old CTMS says a visit is worth is the number that was already generating your under-billing, and importing it gives the new system a plausible looking financial history that is quietly wrong.

The second is versioning. Studies are amended mid-flight, sometimes several times, and most spreadsheets and many systems hold only the current grid. Historical visits are therefore valued at today's rates rather than at the rates in force on the visit date. When you reconcile an amended study retrospectively, expected revenue and received payments diverge for reasons that have nothing to do with the sponsor, and a fortnight disappears into explaining a discrepancy the migration created.

Do it the other way round. Re-abstract the grids for the protocols that matter from the executed agreements and their amendments, not from the old system, and record each version with its effective date range. Migrate historical visits with the version that applied on the visit date attached. Then reconcile the migrated history against payments you actually received before anyone relies on the new numbers. That reconciliation is unglamorous and it is where networks find their first genuine recovery, because the differences it exposes are real rather than artefacts.

Why do the payment, EDC and CTMS integrations break after launch?

Because the connections that matter in a site network are with organisations that owe you nothing and change without telling you. A sponsor moves to a different payment vendor between studies and the remittance layout changes overnight. A study team switches electronic data capture platforms mid-programme. A sponsor portal adds a login step that breaks an automated download. None of these are your engineering team's mistakes and all of them stop your reconciliation dead.

The failure is made worse by architecture. Builds that hard-code a parser per sponsor need a developer for every new layout, so the queue of unparsed remittances grows and someone starts opening them in Excel again, which is the exact state you were trying to leave. Builds that treat extraction as a general capability with a correction interface degrade gracefully instead: an unfamiliar layout produces low confidence lines rather than nothing, a person corrects them in minutes, and the corrections improve the next batch.

On the clinical side, be deliberate about direction. The sponsor's electronic data capture system is theirs and is not a source you can depend on. Read-only extracts where they are offered, and manual entry where they are not, is honest and cheap. Bidirectional sync with a sponsor system is expensive, fragile and rarely worth it. Where you keep an incumbent CTMS underneath, decide once which system owns the visit record and never let both write it, because dual ownership of the visit is the fastest route to two different answers about whether a procedure happened.

What happens when deviations, screen failures and holdbacks are not covered?

These three are the standing edge cases of site finance, and every off-the-shelf tool treats them as exceptions to be handled by a human. In a network running twenty five or more concurrent protocols, exceptions at that rate are not exceptions, they are a job.

Screen failures are money. The contract usually reimburses them at a stated fraction, often with a cap on the number reimbursed per site, and if the system does not count against that cap you will either miss revenue you are owed or bill past a limit you agreed to. Protocol deviations affect payability in ways the agreement specifies and the calendar does not: a procedure performed outside its window may or may not be reimbursable, and the determination has to be recorded at the time with a reason, because reconstructing it a year later is impossible.

Holdbacks are the quietest loss in the category. A percentage is retained pending close-out, close-out happens, everyone moves on to the next protocol, and nobody chases the retained amount because no object in any system is responsible for it. Model the holdback as a receivable created at contract execution with its own release conditions and its own owner, so it appears on an ageing report rather than in nobody's memory. A network that has never chased holdbacks systematically usually finds several studies' worth outstanding on the first pass.

Should you build custom or configure RealTime-CTMS or Clinical Conductor?

If you are a single site running under about ten concurrent protocols, buy. RealTime-CTMS is genuinely site-first, with strong electronic source and payment handling, and Advarra Clinical Conductor covers site financials capably. Both will do more for you sooner than anything custom, and your reconciliation problem is small enough that a monthly workbook is not a real risk. Buy also if your studies come overwhelmingly from one or two sponsors on standard grids, because the parsing and matching problem that justifies a build barely exists for you.

Before commissioning anything, check whether your incumbent is actually configured. A large share of the pain we are asked to fix turns out to be a system where budgets were entered at summary level because start-up was rushed, not a system incapable of holding the detail. Re-entering your top ten protocols properly in the tool you already pay for costs a fortnight of one person's time and sometimes recovers more than the first phase of a build would.

Build when several of these hold together: more than roughly twenty five concurrent protocols across two or more sites, receivables reconciled by one person with a workbook who is your operational single point of failure, unbilled invoiceables found more than once with no confidence you have found them all, many sponsors with materially different contract structures, or an acquisition strategy that keeps delivering sites with different systems and different definitions of a visit.

How do hidden costs get into the quote?

Five items account for most of the overrun here, and each is knowable in advance.

• Grid abstraction hours. Reading executed agreements and turning them into structured rules is your cost, not the developer's, and it needs someone senior enough to interpret a clause. The first few protocols take real hours.
• Sponsor remittance variety. Each layout is its own shape. Ten sponsors is a different project from forty, and the estimate should say how many are in scope for the first release.
• Patient stipends and travel. Rules vary per protocol and per visit, accrual has to be right for both patient satisfaction and tax reporting, and card issuance is a payments project rather than a feature. Phase it after billing is trusted.
• Multi-entity accounting. If your sites are separate legal entities with their own books, intercompany treatment and per-entity trust of the numbers is real work that never appears in a demo.
• Parallel running. One full payment cycle comparing generated invoiceables against what the old process produced is the only way to earn confidence, and it consumes hours from the person who is already the bottleneck.

Regulatory document tracking and study start-up workflow belong on the same list if you want them. They are worth having and they are not billing, so scope them separately rather than letting them absorb the first release.

What separates a build that works from one that fails here?

The builds that work give coordinators something before asking for anything. A coordinator already lives in the sponsor's electronic data capture system, an interactive response technology, an electronic regulatory binder and the hospital record. A sixth login that only feeds finance will be completed on Friday afternoon from memory, and financial data reconstructed from memory is worth nothing. Lead with the visit work list ordered by window risk, laboratory kit expiry warnings and stipend reminders, then collect the billing data as a by-product of work people already do.

They also treat the unmatched remittance queue as the product rather than as a defect. Matched payments need no attention. The value is a short, current list of short-paid and never-paid lines with reasons attached, delivered while the contractual timeline to dispute is still open. A system that reports ninety per cent matched and hides the rest has inverted the point.

The builds that fail start with a dashboard for the site director, model twenty protocols at summary level, and treat deviations and screen failures as manual exceptions. Settle ownership before kickoff, in writing: the repository, the cloud accounts, and the right to hire another firm. At Digital Heroes the client owns all of it from the first commit. The structured grid library and the payment matching history become the most valuable operational asset in the network, and neither belongs in someone else's account.