A working reference for biostatisticians and statistical programmers

GxP is shorthand for the family of regulations and quality guidelines that apply to any work that touches a regulated medicinal product. The G stands for Good, the x is a placeholder for the discipline (Clinical, Laboratory, Manufacturing, Pharmacovigilance, Distribution), and the P stands for Practice. For a biostatistician or statistical programmer, GxP is the framework that decides whether the analysis you ran on Tuesday can be trusted by an FDA reviewer two years later.

This piece keeps the survey of GLP, GMP, and 21 CFR Part 11 short, and spends most of its weight on Good Clinical Practice, which is the GxP that statistical programming actually lives inside. Examples are given in SAS, R, and Python because submission shops increasingly run on all three.

The GxP family

Table 1. The GxP family at a glance, with the regulator references a programmer is most likely to encounter on a global submission.

Good Laboratory Practice

GLP governs how non-clinical safety studies (tox, carcinogenicity, reproductive, safety pharmacology) are planned, performed, monitored, recorded, archived and reported. It is the oldest formal GxP, born from the 1976 Industrial BioTest Labs scandal and codified in 21 CFR Part 58 in 1979. The OECD Principles of GLP are the international counterpart and are mutually accepted across most ICH regions.

For a programmer the GLP touchpoints are narrow but real. Datasets coming out of a GLP-compliant tox lab carry a Quality Assurance Unit (QAU) signature. If your team does PK/PD or tox-table programming on top of those data, the source data, derivation specifications, and final outputs need to be traceable to that QAU-released source. Mixing GLP source with non-GLP data in the same dataset without flagging it is a finding waiting to happen.

Good Manufacturing Practice

GMP applies to the drug substance and drug product itself, not the analyses around them. FDA codifies it in 21 CFR 210 and 211; the EU codifies it in EudraLex Volume 4. A statistical programmer rarely writes GMP-relevant code, but stability analysis, content uniformity, and batch-release decisions are statistical activities, and the data systems that hold them are GMP-validated. If you are pulled into CMC, expect tighter change control, a formal validated environment, and a different SOP set than the one you use for clinical work.

21 CFR Part 11 and EU Annex 11

Part 11 is the FDA rule that defines when an electronic record or electronic signature is acceptable as the equivalent of paper. EU Annex 11 covers the same ground for computerised systems used in any GxP activity in the EU. Part 11 is the rule that makes a SAS or R script production-grade, because it is what forces validated environments, audit trails, role-based access, and qualified backups.

Table 2. How Part 11 / Annex 11 expectations land on the day-to-day work of a statistical programming team.

Good Clinical Practice — the programmer's core competency

GCP is an international ethical and scientific quality standard for designing, conducting, recording and reporting trials that involve human subjects. The current global anchor is ICH E6(R3), adopted by ICH in January 2025. FDA implemented the previous revision (R2) through 21 CFR 312 and the 2018 guidance, and is moving toward harmonisation with R3. EMA implements GCP through Directive 2001/20/EC and the Clinical Trials Regulation (EU) No 536/2014, with the EMA/INS/GCP inspection procedures supplying enforcement detail.

ICH E6 is not the only guideline that matters for a programmer. The bundle that actually drives day-to-day work is the table below.

Table 3. ICH guidelines and CDISC standards a stat programmer touches on a typical NDA, BLA, or MAA.

What changed with ICH E6(R3)

R3 is the first GCP revision built around fit-for-purpose quality and computerised systems rather than the paper-trial model E6(R2) inherited. Three shifts matter for programmers. First, Annex 1 (interventional trials) carries an explicit set of expectations for computerised systems used to generate or hold trial data, formalising what most sponsors had already pulled from EMA's Notice to Sponsors and FDA's 2007 Computerised Systems guidance. Second, the principle of proportionate quality means a SAP risk assessment is no longer an internal nicety, it is the basis for what gets validated and how heavily. Third, sponsor oversight of vendors (CRO, EDC, central lab, IRT, ePRO) is sharpened, which directly affects the audit trails and dataset provenance a programmer has to be able to defend.

What is programmer's role in the GCP lifecycle

The flow below is the practical version of what E6(R3) calls the data lifecycle. Every box has a GCP control around it. If you can name the SOP, the validated tool, the approver, and the audit trail for each box on your own study, you are GCP-ready.

Figure 1. The clinical data lifecycle viewed from the programmer's chair, with the GCP and regional regulatory hook for each stage.

Practical compliance: what GCP looks like in code

Three habits separate a GCP-ready programming team from a team that will fail a sponsor audit. The first is independent verification, usually called double programming. The second is full traceability, source data through to displayed result. The third is a clean, reviewable log for every production run.

Independent verification (double programming)

ICH E6 does not literally say "double programme your tables", but it requires that data are recorded, handled and stored in a way that allows accurate reporting, interpretation and verification. Sponsors operationalise this through a producer/QC workflow on every key derivation and every primary efficacy / safety output. In SAS the comparison is conventionally PROC COMPARE; in R it is most often diffdf or arsenal::compare; in Python it is pandas.testing.assert_frame_equal.

R and Python equivalents

Traceability and the audit trail

Define-XML is the artefact that carries traceability into the submission. Inside the team, the same idea has to live in the program headers, the spec, and the reviewer's guide. A compliant header tells an inspector who wrote the program, when, against which spec version, and what input data it consumed. Anything the inspector cannot reconstruct from your archive is, for GCP purposes, not reproducible.

Log review and the "clean log" rule

An auditor will not read your code first, they will read your log. A production run that emits WARNING, ERROR, uninitialized, or NOTE: MERGE statement has more than one... is, by sponsor SOP, a failed run. Most shops automate a log scrubber that fails the job if forbidden strings are found, and stores the scrubbed log alongside the dataset and the lst output.

Inspection readiness for the programming team

An FDA BIMO inspection or an EMA GCP inspection rarely starts in the statistics function, but if the inspector has questions about how a primary efficacy result was derived, statistics is where they end. Three artefacts are normally requested: the locked SAP, the reviewer's guides (cSDRG and ADRG), and the program-plus-log archive that produced the result. If those three line up, the conversation is short.

Common findings the programming team owns

Table 4. The findings that, in the author's submission experience across NDA, BLA, and MAA filings, recur most often in the statistical programming function.

Closing the loop

GxP is not paperwork bolted onto the analysis after the fact. It is the set of habits that make the analysis defensible: a signed SAP before the lock, an ADaM that traces cleanly to SDTM, a production run with a clean log, an independent QC that compared equal, and an archive an auditor can open three years from now and re-run. Build the habits into the project plan and the inspection looks after itself.

A pre-lock checklist for the programming team

The questions below are the ones a sponsor lead programmer should be able to answer yes to on the morning of database lock. They are stitched together from the GCP, Part 11, and CDISC requirements covered above, and from the recurring findings in Table 4.

Table 5. Six questions to clear before any GCP-regulated database lock.

References:

ICH E6(R3) Good Clinical Practice (Step 4, January 2025); ICH E8(R1) General Considerations for Clinical Studies (2021); ICH E9 Statistical Principles for Clinical Trials and ICH E9(R1) Estimands; FDA 21 CFR Parts 11, 50, 54, 56, 312, 314; FDA Study Data Technical Conformance Guide (current version); EU Clinical Trials Regulation (EU) No 536/2014; EMA Annex 11 to EU GMP; CDISC SDTM IG, ADaM IG, Define-XML 2.1, Dataset-JSON 1.1; PMDA Notification 0427001 on Electronic Study Data Submission. For working examples and CDISC tooling, see clinstandards.org.