Clinical Trial Site Software Problems: The 6 That Cause Protocol Deviations, and How to Avoid Them

Why does the schedule of assessments get scoped as a calendar?

Because at study startup it looks like one. Day 1, Day 28, Day 90, each with a window. Anyone can put that in a calendar, and the first version of almost every site tool does exactly that.

What a calendar cannot express is the thing that makes this domain hard. A visit is anchored to an event, and the event differs by protocol: first dose for one, randomisation for another, prior visit for a third. Counting from the wrong anchor is the single most common cause of an out of window visit, and it happens to experienced coordinators because the arithmetic is done in a head that is also holding four other protocols. Windows may be calendar days or business days. Procedures within a visit have their own requirements: equipment, staff role, a pharmacokinetic series that occupies a room for two hours.

Then the amendment arrives. Amendment 3 moves the Week 12 window, adds an unscheduled draw, and applies only to subjects who re consent. A calendar has no concept of a version, so the site either re enters everything by hand or, more honestly, relies on the lead coordinator remembering which subjects are on which version.

The fix is a protocol version object holding a schedule of assessments, with each visit carrying an anchor event, an offset, a window and its required procedures, and each subject carrying a pointer to the consent version they are on. When an amendment lands you create a version, mark who re consented and when, and forward windows recompute only for those subjects. Every recomputation is logged with who, when and why, because a monitor will ask. Sort the coordinator view by days to window close rather than by date, so the thing closing on Thursday sits at the top regardless of which protocol it belongs to.

What goes wrong when you migrate paper source and legacy subject records?

The instinct is to digitise the binders. It is almost always the wrong instinct and it is where these projects lose their budget.

Retroactive digitisation of closed subject records buys nothing and creates risk. A scanned worksheet is not eSource, it is an image of source, and if it is entered into a system as structured data by someone transcribing months later, you have created a second version of the record that can disagree with the original. Now a monitor has two artefacts and a question about which one is certified. Leave closed studies on paper, let existing binders age out with their protocols, and run new protocols on the new system. That single decision typically removes a quarter of the proposed scope.

What does need migrating is the operational data: the subject roster, consent versions and dates, visit history sufficient to compute forward windows, and the enrolment funnel if it exists anywhere structured. The funnel is usually the surprise. It lives in one coordinator's pre screening spreadsheet with free text screen failure reasons, and converting free text failure reasons into coded ones is a judgement exercise a coordinator has to do, not a mapping a developer can write. Budget it as staffed work.

The third trap is the source worksheet templates themselves. Each sponsor sends a Word document, and rebuilding each one as a form is a two week job per protocol, which is exactly why sites abandon generic eSource products by protocol four. Extracting field labels, units and ranges from the sponsor document into a draft form definition that a coordinator corrects in about twenty minutes is the one place in this category where document models pay for themselves cleanly, because the input is a structured document, the output is reviewed before it touches subject data, and a human approves the schema.

Why do EHR and sponsor EDC integrations break after launch?

The electronic health record integration rarely breaks technically. It breaks on governance and it breaks before it starts. A read only cohort query through a vendor's app review process runs on your health system's calendar and can take months of approval before any code is written, and a nightly extract negotiated directly with your own information technology group is often faster and cheaper for the same result. Decide which path you are on before scoping, because the difference swings the schedule by a quarter. After launch, the failure is drift: the extract's field set changes when the health system upgrades, the cohort query silently returns fewer patients because a code set moved, and nobody notices because the pre screening list still looks plausible. Reconcile counts on a schedule and alarm on a sudden change in volume.

The sponsor electronic data capture system is the opposite problem. It does not break, it multiplies. Sponsors mandate their own system per study, so building push integrations to Medidata Rave, Veeva CDMS, Oracle Clinical One and Medrio means maintaining four connectors for a population that changes with every new protocol. Most sites should not build electronic data capture push at all in a first release. Build reconciliation instead: a view that compares what your source says against what was entered downstream, so a coordinator finds the mismatch rather than a monitor finding it. That gives you most of the value with none of the connector maintenance.

The third integration people forget is the central laboratory. Kit inventory, requisition numbers and result returns arrive in formats that change without notice, and an expired kit drawn at a visit is a deviation that nobody catches until the laboratory rejects the sample.

What happens when Part 11 and monitor access are not covered?

21 CFR Part 11 is not a feature added at the end. It shapes the data model from the first commit, because an append only audit trail with reason for change capture cannot be retrofitted onto tables that have been overwriting rows. Retrofitting means restating history, and restated history is the exact thing a sponsor auditor is looking for.

The specific requirements that get missed are consistent. Every save writes an audit row with user, timestamp, old value, new value and reason for change. Electronic signature on the investigator review step, bound to the record it signs. Account controls that mean a shared login is impossible, which matters because shared logins are how busy sites actually work. And a certified copy export that a monitor can take away, which is a defined artefact rather than a screenshot.

Monitor access is the operational half and it is routinely absent. A clinical research associate arrives for two days and needs to see only their assigned subjects, only the fields changed since the last visit, and needs to raise queries without editing anything. Sites that did not build this end up granting a coordinator login to a monitor, which is both a control failure and an unpleasant conversation. Build the monitoring view: scoped to assignment, read only, showing changes since last visit, with a query thread attached to the field rather than to the subject. Sites that have this cut source verification preparation from days to under an hour, and the reason is not the software being clever, it is that the monitor stops asking a coordinator to fetch binders.

Should you build custom or configure what you already own?

If you are a single site running fewer than about eight concurrent protocols with two or three coordinators, do not build. Clinical Conductor or RealTime CTMS plus disciplined paper source will hold you, and the subscription costs less than any custom project. Configure what you have properly first: most sites are using a fraction of their clinical trial management system, and the contract, budget and payment side of those products is genuinely capable.

Keep the clinical trial management system regardless. Rebuilding contracts, budgets and payments is wasted money, and sites that build usually end up running both, with the custom system as the daily operational driver and the packaged product as the financial system of record.

Build the operational layer when the signals cluster. Three or more sites, or one site past about fifteen concurrent protocols. A deviation log where more than a third of deviations are visit window or missing source, which means the problem is operational rather than clinical. Someone whose job has quietly become being a human integration layer between a whiteboard, a clinical trial management system and nine sponsor portals. A study lost because you could not evidence enrolment history. And the tell that ends the argument: your best coordinator maintains a personal spreadsheet the whole site depends on. That spreadsheet is your requirements document.

How do hidden costs get into the quote?

Validation is the first and the largest. A validation plan, installation, operational and performance qualification documentation, and a requirements traceability matrix are real deliverables, and in our delivery experience they add fifteen to twenty five percent to the engineering line. If you enrol subjects in the European Union you inherit further obligations and that percentage moves.

The health record integration path is the second, and the honest question is not whether the developer can do it but whose approval queue you are in and how long that queue is.

Electronic data capture connectors are the third, and the trap is that one is scoped work and five is a platform. Central laboratory interfaces are the fourth, since each laboratory has its own formats and changes them without telling you.

Protocol onboarding is the fifth and it is ongoing rather than one off: every new study needs its schedule of assessments and source forms configured, and somebody at the site has to own that permanently. Budget the role, not just the build. And the sixth is your own staff time during validation, because user acceptance testing under a validation plan is documented, evidenced work rather than a quick look.

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

Make the first release narrow enough to be in coordinators' hands inside a quarter. The window engine plus eSource for two or three protocols, live in fourteen weeks, is worth more than a complete platform that arrives after your best research coordinator has already resigned.

Design for the visit, not the desk. Coordinators complete source at the bedside on a tablet, sometimes with a subject waiting and sometimes with no network, and anything requiring a return to a workstation will be done on paper first and transcribed later, which reintroduces the problem you paid to remove.

Type the fields. Units and normal ranges on every numeric field so an out of range value flags at entry rather than at query, and required procedures derived from the schedule of assessments rather than from a coordinator's memory. Most operational deviations are caught here or not at all.

Decide Part 11 architecture in week one. Append only storage, reason for change, signature binding. It is cheaper by an order of magnitude at the start than at any later point.

Finally, settle code ownership and source escrow in writing before kickoff, including repository access from the first commit. At Digital Heroes the client owns the code from the first commit. For a regulated system the validation documentation and traceability matrix are part of the deliverable, and a sponsor auditor may ask to see them, which is a poor moment to discover they belong to a vendor.