You need to change a field on a live trial's data capture system. What evidence does that change have to produce?

What the system is holding

Trial data capture sits under a regulatory regime that is unusual in one specific way: the record is evidence in a submission that decides whether a medicine reaches patients. A site records observations on electronic case report forms in an electronic data capture system, alongside data arriving from participant diaries, devices and central laboratories. That data is cleaned through queries and edit checks, then locked, transformed into the standard submission structures, analysed, and reported.

The governing expectations are that data should be attributable, legible, contemporaneous, original and accurate, with the later additions of complete, consistent, enduring and available; the profession refers to this as ALCOA-plus. The FDA's rule on electronic records and signatures, 21 CFR Part 11, and the EU GMP annex on computerised systems set out what a computerised system must do to make electronic records trustworthy enough to substitute for paper, and ICH's good clinical practice guideline sets the trial-conduct expectations. You do not need to quote any of them to answer well. You need to understand what they are collectively insisting on, which is that a record's history is as important as its current value.

Validation is a body of evidence, not a property of the software

This is the distinction the question is testing. A system is not validated because it works. It is validated because there exists documented, approved evidence that it does what its specified intended use requires, produced by a process that a third party can follow years later.

The shape of that evidence, in the vocabulary the industry uses, runs from user requirements through functional and configuration specifications to qualification: installation qualification confirming the system is installed as specified in the specified environment, operational qualification confirming the functions behave as specified, and performance qualification confirming it performs in the actual business process with real users. A traceability matrix links every requirement to the specification that satisfies it and the test that proves it, which is what makes the package auditable rather than merely voluminous.

Crucially, the effort is risk-scaled. The GAMP 5 approach that most sponsors follow says explicitly that validation rigour should be proportionate to risk and to the novelty and complexity of the software, and that you should leverage supplier evidence rather than retesting what the vendor has already qualified. A configuration change to a standard vendor form is not the same undertaking as a bespoke calculation that derives an eligibility decision. Candidates who describe a single heavyweight process applied identically to everything are describing a compliance theatre that regulators themselves have argued against.

The evidence a live change has to produce

For the specific case, changing a field on a study that is already enrolling, the package has a predictable content. Each item exists to answer a question an inspector will ask.

A change request with a stated reason and requirement. Not "add field", but what is being captured, why, whose decision it supports, and who requested it. This answers "why does this change exist", and a change without a documented origin is the one that gets pursued hardest.

An impact and risk assessment. What else touches this field: edit checks, derivations, the randomisation or eligibility logic, the data transfer specification to the statistical environment, listings, the mapping into the submission datasets, integrations with a laboratory or an ePRO vendor. And the risk question that determines everything else: can this change affect participant safety, or the integrity or interpretation of the primary endpoint data? A change to a safety-relevant field is a different exercise from a change to an administrative one.

Protocol and governance alignment. If the field collects something the protocol does not provide for, the protocol or its data-collection plan changes first, which may need ethics committee review. Amending the system to collect data the approved protocol does not authorise is the wrong order and no amount of test evidence repairs it.

Specification of the change. The field's definition: type, permitted values, units, required or optional, visibility conditions, validation rules, and its coded representation in the study's data standard so that it maps predictably downstream.

Test evidence, executed against the specification, in a controlled environment. Positive cases showing it accepts what it should, negative cases showing it rejects what it should, boundary cases, and regression coverage over the things the impact assessment flagged. Executed by someone competent, with results reviewed and approved, retaining the actual evidence rather than a summary asserting that testing passed. Screenshots or captured output, dated, tied to a test script identifier, tied back through the matrix to the requirement.

A migration decision for data already collected. This is the part most answers omit. Participants have already been entered under the old definition. If the change narrows permitted values, some existing entries may now be invalid. If it splits one field into two, historic values have to be apportioned or explicitly left as-is with the difference documented so the analysis population is not silently mixed. Any correction to existing data goes through the normal data-change route with a reason recorded, never by a direct database update. An untracked bulk edit of clinical data is among the most serious findings available.

An unbroken audit trail. Every subsequent change to a data point must record the old value, the new value, who made it, when, and why, and the trail must be system-generated, must not be alterable, and must not be capable of being switched off by users. The change you are making must not disturb the trail over data captured before it, and if a field is renamed or restructured the historic trail must still resolve to something a reader can interpret. An inspector picking one value in a listing and asking to see its full history is a routine request, and the system either answers it in a minute or the finding writes itself.

Configuration and version control with a released artefact. The study build has a version, the change moves it to a new version, and there is a record of exactly what was deployed and when it became effective in production. Sites need to know which version they were using on which date, because that is how a query about a data point six months from now gets resolved.

Approval and release records, signed by people with defined authority. Signed by the study or data manager for content, quality for compliance, and whoever owns the system technically, with the release authorised by someone other than the person who built and tested it. Segregation of duties here is not bureaucratic decoration; it is the control that makes the other evidence believable.

Training and communication. Sites entering data against a changed form need to know it changed, and training records are inspected. A field that appears without notice produces inconsistent entry across sites.

Afterwards, the change joins the lifecycle: periodic review of the validated state, and re-assessment on the next infrastructure or vendor upgrade, because validation is maintained rather than achieved.

Where engineers reliably get this wrong

An engineer's instinct is that the deliverable is a working change, and the documentation is an administrative tax paid afterwards to satisfy a department. In a regulated environment the working change and the evidence are one deliverable, and the evidence is the part with regulatory standing. A field that behaves perfectly with no approved specification, no test record and no traceable authorisation is, from an inspector's point of view, an uncontrolled change to a system holding submission data, and the honest consequence is that the data collected through it may be questioned. Retrospectively assembling the paperwork does not fix it, because the evidence was supposed to demonstrate control at the time and a document written after the fact cannot demonstrate that.

The corollary is more useful than the warning. Because the evidence is the deliverable, it is worth engineering: templated test scripts, a configuration diff that is human-readable, an environment that produces reviewable execution output, and traceability maintained as the change is built rather than reconstructed. Teams that build the evidence trail into the pipeline ship regulated changes faster than teams that treat it as a gate at the end, and they do it with less risk.

In a validated environment the artefact under control is the record, not the code. If you cannot show who specified a change, who proved it worked, who approved it and what happened to the data already captured, then as far as an inspection is concerned the change was never controlled at all.