ICH Q7 clause 19: APIs for use in clinical trials

Clinical trial APIs go through phases with increasing GMP rigor: Phase I (small-scale, flexible), Phase II (more structured), Phase III (near-commercial), registration (essentially commercial). Phase I APIs have the most flexibility — laboratory notebooks instead of formal batch records, development data supporting release, no requirement for process validation. As development progresses, controls tighten to prepare for commercial launch.

For early clinical trial APIs, laboratory notebooks are acceptable documentation — a significant difference from commercial batch records. Notebooks must be: bound (no loose pages), dated, signed, stored securely, retained for the development lifecycle. Development reports summarize the process and data. As development advances, documentation becomes more structured (formal batch records, SOPs, specifications) approaching commercial documentation.

Core GMP principles still apply to clinical trial APIs, but with flexibility on how they're implemented. Scientifically sound test methods are required (not necessarily fully validated compendial methods). Cross-contamination controls are required (but may not need dedicated facilities for early development). Identification and traceability are required. Manufacturing history reconstruction must be possible even if through lab notebooks rather than batch records.

QU independence is non-negotiable even in development. In small companies, this may be a single QA person or a designated reviewer who is organizationally separate from production. The reviewer examines: batch records (or notebook entries), test results, any deviations, documentation completeness. Release decisions are documented and the released material is tracked separately from unreleased.

Release testing evolves through development. Phase I: tests to confirm structure and approximate purity. Phase II-III: more comprehensive testing approaching commercial scope. Registration: full release panel. Specifications also tighten over time — early development uses broad specs reflecting variability, commercial products have tight specs based on established process capability. Methods become more fully validated as the product advances.

Stability testing starts early — even Phase I batches should go on stability. Initial testing may be shorter duration and fewer time points than commercial stability, but data is still generated. As development progresses, stability studies become more comprehensive to support eventual commercial labeling. Early stability data also identifies any stability concerns before commercial investment. Ongoing stability studies during clinical development build the database for registration.

Conservative initial expiry dates are appropriate when stability data is limited. Typical initial expiry: 6-12 months. As stability data accumulates (typically quarterly in early development), expiry may be extended. Each extension is supported by actual stability data — not extrapolation. Clinical trial APIs often have shorter campaigns than commercial products, so shorter expiry is acceptable. The goal is ensuring quality during clinical use.

In early development, pharmacopeial reference standards may not exist for new APIs. In-house standards are used, characterized for identity and purity by available analytical methods. Characterization depth increases as development progresses — early development may use single-method characterization, later development uses multi-method orthogonal characterization. The standard must be suitable for its analytical purpose (e.g., suitable for HPLC assay if used as an assay standard).

Clinical trial APIs typically use smaller-scale equipment (kilo lab, pilot plant) rather than full commercial equipment. This equipment is often more flexible — can manufacture multiple products. Qualification is less formal but still required — equipment must be fit for purpose. As development advances, equipment may transition to commercial-scale equipment with commercial qualification levels.

Clinical trial API facilities are often multi-product — different clinical candidates share equipment and facilities. This requires rigorous cleaning validation between products. For highly potent products or sensitizers (beta-lactams, cytotoxics), dedicated facilities are required even for clinical trial material. Facility qualification level may be less formal in early development but should still address key GMP areas.

Raw material control for clinical trial APIs is scaled appropriately. Specifications focus on critical attributes affecting the API. Identity testing on every lot is still required (per clause 7.30). Supplier qualification may be based on CoA review rather than full audits for early development. As development advances, specifications tighten and supplier qualification becomes more formal.

Simplified testing is acceptable in early development but identity is always required. Examples of simplification: fewer quantitative tests, skip testing based on supplier CoA (with supplier qualification), reduced sampling plans. However, critical materials (those directly becoming part of the API structure) should receive more extensive testing. The testing approach should be documented and justified.

Laboratory notebooks are a hallmark of clinical trial API manufacturing — especially in early development. Requirements mirror formal batch records in key ways: contemporaneous entries, attribution, dated, sufficient detail for reconstruction. Transition to formal batch records typically occurs around Phase II-III as the process stabilizes. Notebooks must be controlled: bound, sequentially numbered, retained. Electronic notebooks (ELN) are common in modern development.

Development processes often have variable yields as the process is being optimized. Rigid yield expectations are inappropriate. However, yields should still be recorded and compared to expectations. Yield deviations, especially low yields, may indicate: process issues (incomplete reactions), analytical issues (losses), operator errors, equipment issues. Investigation in development builds process understanding that supports commercial scale-up.

Process validation is not required for early clinical trial APIs — the process is still evolving and not ready for validation. Development data (process development reports, scale-up studies, characterization batches) provides evidence of process understanding. Formal validation occurs pre-commercial launch when the process is established. Intermediate phases (late Phase II, Phase III) may have partial validation activities as the process stabilizes.

The transition from clinical trial to commercial manufacturing is a major validation milestone. Validation activities include: process qualification runs on commercial equipment, cleaning validation, analytical method validation, computerized systems validation. All earlier development data supports but does not replace commercial-scale validation. The regulatory submission typically requires validation data with registration.

Development is characterized by process changes — optimization, scale-up, route changes, supplier changes. All these must be documented even though formal commercial change control may not apply. Documentation supports: regulatory submissions (showing process evolution), investigation of quality issues (what changed when), knowledge management (institutional memory). Simpler change control for development may use development reports with change summaries rather than formal change control forms.

Analytical methods evolve with development — from early research methods to fully validated commercial methods. Suitability assessment considers: method performance for the analytical purpose, sufficient specificity for the matrix, appropriate accuracy and precision. Full validation per ICH Q2 is not required for early phases. Methods mature through development: pre-clinical → Phase I → Phase II → Phase III → registration. Each phase adds validation rigor.

Clinical trial samples are retained beyond standard commercial retention because they support: regulatory review during marketing application review (can take years), investigation of any issues discovered post-approval, comparison to commercial batches for consistency assessment. Typical retention: throughout clinical development plus several years post-approval, often 10+ years total. Samples must remain stable throughout retention — proper storage is critical.

Simplified stability for clinical APIs includes: fewer time points than commercial stability protocols, fewer batches on stability initially, shorter initial studies with data collection continuing throughout development. Expiry dates are assigned conservatively at first and extended as data accumulates. The goal is sufficient stability assurance for clinical use while avoiding unnecessary commercial-level complexity early in development.

Clinical development generates significant data that must be retrievable throughout the product lifecycle. Key data: synthesis procedures, batch records or notebooks, test results, deviations, investigations, stability data, supplier information. The retrieval system may be paper-based (document management), electronic (database, ELN), or hybrid. Regulatory inspectors during marketing application reviews may request data from years earlier — the system must support this.

Laboratory notebooks are the traditional development documentation and remain acceptable. Modern approaches use electronic lab notebooks (ELNs) providing: version control, audit trails, searchability, backup, collaboration. Paper notebooks still work but must be physically controlled. Requirements in both cases: controlled issuance, sequential numbering (page and notebook), signatures, dates, corrections per GDP, secure retention, and accessibility throughout the required retention period.

Batch numbers provide identification throughout the product lifecycle. Development batch numbers often use prefixes (DEV-), clinical trial numbers may use project codes, commercial batches use different formats. The key requirements: unique identification (no duplicates), traceability (batch records retrievable by number), appropriate format for intended use. Some organizations use one system throughout development; others transition formats at commercial launch.