Clinical trial software and the regulator's calendar

Software teams are used to owning their release calendar. Life sciences programmes do not work that way. A submission goes in on a date set by the regulator's process, the trial's enrolment and sometimes a competitor's filing. None of it is negotiable by the people writing the software, and every engineering decision downstream inherits that.

We supply regulatory specialists, biostatisticians and trial managers to pharmaceutical companies that need the expertise without a permanent hiring commitment. The engineering lesson that comes out of that work has little to do with the science. The build calendar has to be designed backwards from a date nobody in the room controls.

Freeze windows are the real constraint

There are periods in a trial when the system cannot change. Database lock. The weeks either side of an interim analysis. Any window in which an inspector might arrive. During those, a fix that would take an afternoon takes a change control board, a revalidation and a written justification, assuming it is permitted at all.

The release plan is therefore a set of gaps between immovable objects rather than a steady cadence. We map the freeze calendar before the sprint plan, and we treat the last release before a lock the way most teams treat a launch: full regression, everyone available, nothing clever going in.

Validation is a cost per change, and it prices the architecture

Computerised system validation means that changing a component obliges the team to demonstrate, in documents, that the change broke nothing the regulator cares about. The cost scales with how far a change can reach. In a system where every deployment revalidates everything, small improvements become uneconomic, so people stop making them, and the platform ossifies about eighteen months before anyone will say so out loud.

The architecture argument in life sciences turns on blast radius rather than scale. Keep the regulated core small, well bounded and rarely touched. Push reporting, scheduling, dashboards and site-facing convenience features into components outside the validated boundary, where they can be released in an ordinary week by an ordinary process.

The audit trail is a feature with requirements

Logging and an audit trail are different objects. An audit trail records who changed what, when, from which value to which value, and why, in a form that outlives the application. It cannot be editable by an administrator. It has to be readable years later by somebody with no access to the codebase and no one left to ask. Teams that treat it as an implementation detail find out during an inspection that a log rotation policy deleted the answer eleven months ago.

Recruitment is the schedule risk software can actually move

Trial timelines slip on enrolment more than on anything else. Site staff who can screen a candidate in four minutes rather than twenty will screen more of them. A protocol amendment that reaches every site on the day it is approved, rather than the week after, saves days at every site at once. Specialist trial managers spend much of their time on protocol and recruitment design, and it is the part of a programme where ordinary software craft has the largest effect on a date.

The habit worth building is to hold the date fixed and let everything else be the variable. Scope, sequencing, the size of the validated core and the order in which sites go live are all negotiable. The submission is not. Teams that work this out in the final quarter spend that quarter writing documents instead of software, and the documents are worse for having been written against a clock.