Clinical trial software testing services

What actually breaks in a clinical trial system?

Nothing you can see on the day. Software in this class holds a record whose purpose is to be read years later by somebody reconstructing what happened, so the expensive defects are the ones that leave a working screen behind: a value filed under the wrong visit, an audit entry written under the integration account, a query closed with no trace of who resolved it or on what basis.

The systems fail in different ways because they carry different halves of the record. An electronic data capture system takes what a site coordinator types and has to hold it against a protocol that was written before the software was configured, so its characteristic defect is a configuration defect: an edit check that fires on the wrong unit, a visit window that accepts a date outside it, a derived field that recalculates when a source value is corrected and leaves the earlier derivation unrecorded. Each of those is a study-specific build sitting on a platform that was validated in general and configured in particular, and the second half is where the study lives.

Randomisation and trial supply management fails in a way the rest of the estate does not, because the action cannot be taken back. A subject assigned to the wrong arm, a kit dispensed against an assignment that was later corrected, an emergency code break performed without a record of who broke it: each of those is an event in the study, and no rerun restores the position. Testing here is about refusal. The interesting cases are the ones where the system is asked to do something the protocol forbids and has to say no, in the right order, with a record of the attempt.

Patient-reported outcome systems concentrate their defects in time. An entry made on a handset with no signal and uploaded the next morning has two timestamps and only one of them is the answer, and the device clock belongs to the participant. A completion window that closes at midnight closes in some time zone, and which zone is a configuration line nobody tested against a travelling subject. The trial master file fails more quietly still: a document filed against the wrong site or the wrong version, and found during an inspection, months after the release that misfiled it.

Which rules reach the software that holds a trial record?

21 CFR Part 11 is the spine, and it never acts alone. The part sets conditions under which an electronic record and an electronic signature count in place of paper; some other requirement decides that the record has to exist at all. Which of your systems carries those conditions, and which sections apply once they do, is set out in 21 CFR Part 11 validation testing.

One FDA guidance sits between the part and a study. It is titled "Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers", it has been final since October 2024 under docket FDA-2017-D-1105, and it addresses sponsors, CROs, clinical investigators and IRBs, whom it calls regulated entities. Its definition of validation is the sentence that reshapes a test plan: "a process to establish and document that the specified requirements of a computerized system can be consistently fulfilled from design until decommissioning of the system or transitioning to a new system". The retirement of the system is inside the scope of its own validation, and that is where this class of product parts company with the rest of your estate.

The same guidance sets three factors for how much validation a system gets: its intended use; the purpose and importance of the data or records it holds; and its potential to affect the rights, safety and welfare of participants or the reliability of trial results. The third factor has no counterpart outside a study, and it is why a randomisation service and a document repository are not tested to the same depth.

HIPAA reaches this class unevenly, and the definitions decide where. 45 CFR 160.103 defines a covered entity as a health plan, a health care clearinghouse, or a health care provider who transmits health information electronically in connection with a covered transaction. An investigator site that transmits a covered transaction electronically is inside; one that does not is not, and a sponsor holding coded trial data is often none of the three. The consequence for a test programme is that the same dataset can be protected health information at one end of a transfer and something else at the other, and the controls that follow it have to be agreed in writing. Which regime a given transfer lands under decides what a test team may be given, so settle it before the first extract is cut.

Why does the record have to outlive the system that produced it?

Because the reader arrives after the software has gone. A study closes, the platform contract ends, the vendor sunsets the product, and the obligation to produce the record continues on a clock set by the predicate rule. That makes export fidelity, audit trail completeness and record retrieval part of the product being tested, sitting in the same release as the features.

Three sections of Part 11 carry the weight, and each one is a different assertion. 21 CFR 11.10(b) asks for the ability to generate accurate and complete copies of records "in both human readable and electronic form suitable for inspection, review, and copying by the agency". section 11.10(c) asks for protection of records "to enable their accurate and ready retrieval throughout the records retention period". section 11.10(e) puts the audit trail documentation on the retention clock of the records it describes and makes it available for agency review and copying. FDA placed all three under enforcement discretion in 2003, and the obligation each describes then comes from the predicate rule; the sections still say what a copy and a trail have to be, which is what makes them testable.

FDA's 2003 guidance adds a condition on copies that an export test has to check separately. It recommends using established automated conversion or export methods to produce copies in a common format, naming PDF, XML and SGML, and it adds that where you have the ability to search, sort or trend Part 11 records, the copies given to the agency "should provide the same capability if reasonable and technically feasible". A trial export that arrives as a flat table has lost the query thread, the signature meanings and the sequence of changes, which is most of what an inspector opens the file to read.

Test assertions for each element of a clinical trial record export, checking that the 21 CFR Part 11 copy keeps what the live system held.

What is exported	What the test asserts about the copy
Subject data	Every value carries its visit, its entry time and the identity of the person who entered it, in both the human readable and the electronic copy
Corrections	The previous value is readable in the copy, in sequence, with the reason recorded against it
Queries	The question, the answer and the closing decision travel together, and a closed query in the export names who closed it
Signatures	The printed name, the date and time of signing, and the meaning of the signing all appear in the human readable form
Audit trail	The exported trail covers the same period as the exported records, and its retention setting matches the record retention rule instead of a database default
Search and sort	A field that could be sorted or filtered in the live system can still be sorted or filtered in the copy

The 2003 guidance also says FDA does not intend to object where required records are archived to a standard electronic file format, or to non-electronic media, and the electronic version is deleted, provided the predicate rule requirements are fully satisfied and the content and meaning of the records are preserved. That allowance is where a retirement plan usually goes wrong. Content survives a format conversion easily; meaning does not, because meaning lives in the relationships between the value, the person and the moment, and a conversion that flattens them produces a file that is complete and unreadable.

Question 8 of the same 2024 guidance names the standard the archive is judged against. It asks about the procedures that keep the data and records required to reconstruct the clinical investigation unaltered in value or meaning, "including during the transfer of data to durable electronic data repositories". Reconstruction is the test, and it is testable today: take a locked study, export it, load it somewhere that has never seen the platform, and answer an inspector's question from the copy alone. The mechanics of comparing two systems while both still answer, and of what happens to the one you switch off, are covered in healthcare data migration testing.

Who is allowed to see which value, and when?

The protocol decides, and the software enforces it. Blinding is a scientific constraint expressed as an access rule, so the question "who may see the treatment assignment" has a different status here from any other access question in health software. Where the protocol treats an unblinding as a deviation, the leak is recorded there as well as in the defect tracker.

That reframes the access control testing. 21 CFR 11.10(d) requires system access to be limited to authorised individuals, and section 11.10(g) requires authority checks over five separate privileges: use the system, electronically sign a record, access the operation or the computer system input or output device, alter a record, and perform the operation at hand. On a trial system those five split further, because the privilege that matters is scoped to a value rather than to a screen. A monitor may open a subject's record and must not see the arm. A pharmacist may see the kit and must not see what is in it. An investigator may break the blind for one subject in an emergency and must leave a record that the break happened, without that record itself becoming a channel.

section 11.10(f) adds ordering, through operational system checks that enforce permitted sequencing of steps and events where that is appropriate. In a trial that is the sequence a general suite has no reason to invent: randomisation precedes dispensing, and the study lock precedes the export. A test that walks each of those backwards and expects a refusal is the cheapest evidence in the programme, and it is usually missing because the forward path was the requirement.

Access has a second clock that a general suite never checks: revocation. FDA's 2024 guidance, in the section on inspecting a clinical investigator, looks for evidence that sponsors are told when trial personnel change so that access rights can be revoked. Site staff turnover is normal and continuous, which makes the revocation path a recurring behaviour, exercised every time somebody leaves. It is testable by asking what a departed coordinator's credential still reaches.

De-identification is the third route, and the HIPAA methods do not fit trial data cleanly. The safe harbor at 45 CFR 164.514(b)(2) removes eighteen categories of identifier, and category (C) covers all elements of dates except year for dates directly related to an individual. Visit dates are the structure a trial dataset is analysed on, so a safe harbor dataset cannot exercise a visit window, a washout period or an overdue visit alert at all. The limited data set at 45 CFR 164.514(e) keeps dates, excludes sixteen direct identifiers, remains protected health information, requires a data use agreement, and may be used only for research, public health or health care operations. 45 CFR 164.514(c) then permits a re-identification code provided it is not derived from information about the individual and the mechanism is not disclosed, which is the rule a subject numbering scheme has to be checked against before it is reused as a test key. Building a de-identified test environment sets out how each of those routes is verified.

What does a trial system have to prove about its signatures and its lock?

That a named person stood behind each entry at a stated moment, and that the database stopped accepting writes when it was declared closed. Six paths carry that proof, and none of them arrives as a feature request, because the person who will need them is an inspector reading the study after everyone involved has moved on.

Steps 1 to 3 are the signature block. Each one is a Part 11 obligation before it is a trial problem, and electronic signature testing under Part 11 covers the section behind each step and the cases that test it.

What does a trial platform actually connect to?

Fewer healthcare interoperability protocols than its neighbours, and more scheduled file transfer than anyone plans for. The traffic that carries most of a study is a set of per-study transfers between the sponsor, the CRO, the central laboratory and the vendor systems, defined in a data transfer specification written for that study and agreed by two parties. No published standard governs it, which means there is no external artefact to test the file against and the specification itself becomes the oracle. A test programme that does not hold that document is comparing the file to whatever the sender sent.

Three real protocols appear, and each one carries a specific trap.

Imaging endpoints arrive as DICOM, and the modules that identify a study are optional in the standard. PS3.3 Table A.3-1, the CT Image IOD module table, marks Clinical Trial Subject C.7.1.3, Clinical Trial Study C.7.2.3 and Clinical Trial Series C.7.3.2 all with usage U, which is user optional, against Patient C.7.1.1 and General Study C.7.2.1 marked M for mandatory. Nothing in DICOM obliges a scanner at a site to populate the attributes that tie an image to your protocol, so the linkage is site configuration and it is verified per site at activation. De-identification for a blinded read has its own artefact in PS3.15 Annex E, and that annex warns in its own text that the attributes it lists may not be sufficient, because identifying information can sit in private attributes, new and retired standard attributes, and standard attributes absent from the composite IODs. What a conformance claim is worth and how it is read is covered in DICOM conformance testing requirements.

Data pulled from an electronic health record into a study arrives as FHIR, and the version question is sharper here than in a live clinical integration because a trial outlives releases. The specification names three ways to pin which version applies: the fhirVersion element in the applicable CapabilityStatement, StructureDefinition or ImplementationGuide; the fhirVersion parameter on the MIME type; and a version specific profile in Resource.meta. Which of the three your transfer uses belongs in the data transfer specification, because the specification also states that content with a status of Draft or Trial Use "can change, including Breaking Changes, from version to version" with no rules maintaining compatibility. A resource that was Trial Use when the study opened can move underneath a study that is still enrolling.

Central laboratory results still arrive over HL7 v2. The trial-specific defect there is a unit that differs between two laboratories in the same protocol, which the protocol's own unit rule has to catch before the value reaches the field a statistician analyses.

Where does clinical trial software testing go wrong?

• The platform is validated and the study build is not, so every edit check and visit window that encodes the protocol reaches production untested.
• The audit trail is checked for existence and never for retention, against an 11.10(e) obligation that is measured against the retention period of the records themselves.
• Export is tested by confirming the file opens, so the loss of the query history and the signature meanings is discovered when the file is read back.
• Test datasets carry treatment assignments, and they are copied between environments by people the study's access model does not cover.
• Access control is tested per screen, while the privilege that has to hold is per value, and 11.10(g) names five separate privileges of which login is one.
• Nothing exercises the sequence rules, so a system that permits dispensing before randomisation passes every forward-path test in the suite.
• Signature meaning is stored as a role name, so the human readable copy shows who signed with no meaning attached to the signing.
• Database lock is enforced in the application while the integration path still accepts writes.
• The DICOM clinical trial modules are assumed to be populated because they were populated at the first site.
• Decommissioning is treated as an operations task, so the first full export of a closed study is attempted when the contract has already ended.

What do we run against a clinical trial platform?

Work starts from the record and from who may see it: which records a predicate rule requires, which system holds each of them, and what evidence each action leaves behind. That map produces two test programmes that are usually run as one and should not be. The platform programme covers the product as shipped. The study programme covers the configuration that encodes this protocol, and it repeats per study because the protocol does.

Blinding is settled before any environment is built, because it decides what the test data may contain. The default fixture carries no treatment assignment. Where the protocol needs an unblinded path exercised, the study team decides who holds that fixture and under which access list, and its use is recorded. Where subject data from a live study is involved at all, the route is decided in advance under the de-identification rules above, and it is written down before an environment exists.

The retirement question is asked at the start. A study that will be read after the platform is gone needs its export exercised against a locked database, read back where the platform has never run, and checked for the meanings a flat file drops. Whether the record set is adequate is decided by the sponsor who holds it and by the inspector who reads it. What the testing supplies is the material under that decision: protocols and executed runs through FDA software validation, and the retained record set through validation documentation.

What this page is built on: 21 CFR Part 11 as it stands in the eCFR on 31 August 2026; FDA's 2003 guidance "Part 11, Electronic Records; Electronic Signatures: Scope and Application"; FDA's October 2024 guidance "Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers"; 45 CFR 160.103 and 164.514; DICOM PS3.3 and PS3.15; and FHIR R4. ICH GCP E6, 21 CFR parts 312, 812, 50 and 56, EU 536/2014 and the CDISC standards were not read, and nothing on this page describes their content.