Writing the CTD Module 2.3 Quality Overall Summary for Kenya PPB submissions

The Quality Overall Summary in CTD Module 2.3 is a critical summary of the quality information contained in Module 3. Its purpose is to provide the evaluator with a concise narrative that integrates the quality data across drug substance, drug product, and excipient documentation, without reproducing the full content of Module 3 in detail. The PPB expects the QOS to be written at a level of technical precision that allows an evaluator to follow the development logic of the product without referring back to Module 3 for every factual statement.

In practice, the QOS is where cross-document consistency failures become most visible. If the release specification limits stated in the QOS narrative differ from the values in the finished product specification in 3.2.P.5, or if the stability conclusions in the QOS are not supported by the data presented in 3.2.P.8.3, an evaluator will flag both documents. Writing the QOS as an afterthought, by summarising individual Module 3 sections in isolation, makes these inconsistencies more likely, not less.

The PPB's guidance on QOS content follows the ICH CTD Q document structure and expectation. Each major section of 3.2.P must have a corresponding narrative in the QOS that accurately reflects the approved specifications, validated methods, manufacturing process description, and container closure system. The QOS must also cover the drug substance in 2.3.S with the same level of integration.

The most frequent QOS deficiency observed in PPB evaluations is the disconnect between the specification limits stated in the QOS narrative and the registered specification in Module 3. This typically happens when the QOS is written against a draft version of the specification that is subsequently updated during compilation, and the QOS is not revised to reflect the change. It can also happen when the QOS is prepared by a different team member than the person managing the specification document, with no formal cross-check step built into the compilation workflow.

A second common deficiency involves the process description in 2.3.P.3.3. The QOS must include a brief but accurate process description that corresponds to the manufacturing process validation data in 3.2.P.3.5. When the QOS process narrative is taken from an earlier development report rather than the validated commercial process, the description may reference batch sizes, equipment types, or critical process parameters that no longer apply. Evaluators notice when the QOS process description and the process validation protocol do not describe the same process.

The stability conclusions section of the QOS is another area where imprecision creates queries. The QOS must state the proposed shelf life and storage condition, explain the basis for the shelf life determination, and confirm that the proposed conditions align with the stability study design. If the QOS states a 24-month shelf life under 25°C but the submitted stability data only covers 12 months at 30°C/75% RH, the evaluator will request either the missing data or a revised shelf life that is supported by the available evidence.

The most reliable way to produce a QOS that passes screening without consistency queries is to write it after all Module 3 sections are finalised and to perform a systematic cross-check between the QOS narrative and the Module 3 source documents before submission. This cross-check should confirm that specification limits, method references, batch numbers, stability timepoints, and storage conditions are identical across all documents that reference the same data point.

For teams using structured document management, this cross-check can be partially automated. The relevant data points, including specification limits, shelf life, storage conditions, manufacturing site addresses, and GMP certificate validity dates, can be extracted from Module 3 documents and compared against their corresponding entries in the QOS. Any discrepancy surfaces before the dossier is submitted, not after a query arrives.

Dossierly's cross-document review feature is designed for this exact workflow. By uploading the QOS alongside the finished product specification, stability documentation, and Module 3 supporting files, teams can identify value mismatches before submission. For QOS drafting, Dossierly also supports a draft generation feature that produces a structured QOS narrative from the source documents already loaded into the project, providing a starting point that is inherently consistent with the uploaded evidence.