Grouping products, review periods and timing: getting the PQR out before it is late

A late PQR is the easiest deficiency an inspector can write, and one of the most common. The regulation says the review should be conducted annually. It does not say how long after the period ends the report must be signed; your procedure does, and inspectors hold you to your procedure. This guide is about the decisions that determine whether the report is on time: the period, the grouping, the cut-off, and the plan for pulling the data.

Choosing the review period

EU GMP 1.10 allows 'periodic or rolling' reviews conducted 'normally' annually. Three models are in common use. Calendar year for every product, which is simple to administer but means all reviews fall due in the same quarter and QA is overwhelmed from January to April. Staggered twelve-month periods, with each product assigned a period end spread through the year, which levels the workload and is the model most large sites end up with. Rolling reviews, where data is evaluated continuously and a report is generated at a fixed interval; this is closest to the ongoing process verification model in EU GMP Annex 15, section 5.28 onwards, and it works only when the trending is genuinely automated and reviewed.

Whichever you choose, the period must be defined in the procedure, must be contiguous with the previous review's period (no gaps, no overlaps), and must be stated on the first page of the report. A common finding is a product whose period was changed without documenting why, leaving three months that no review covers.

Setting and meeting the deadline

Sites typically require the approved report within three to six months of period end, and some MAH agreements require it sooner. Whatever the number is, it is the number you are inspected against. If a report will be late, raise a deviation or a documented extension before the due date, with the reason and a new date. A late report with a documented, approved extension is a weakness. A late report with nothing is a finding about the quality system, because it shows nobody was tracking it.

• Publish a PQR schedule for the year with period end, data request date, draft date, review date and approval date for every product or group.
• Track it in the quality management review or a monthly QA meeting; a schedule nobody looks at is not a control.
• Define the data cut-off: data available up to a stated date is included, anything later goes into the next review and is not chased.
• Assign a named author and named data owners for each section before the period ends, not after.

Grouping products: when it is justified

Paragraph 1.11 permits grouping 'by product type, e.g. solid dosage forms, liquid dosage forms, sterile products etc. where scientifically justified'. The justification is the point. Grouping is defensible when the products share a process, equipment train, critical parameters and specifications closely enough that a trend in one is meaningful for the others. Ten strengths of the same tablet from a common blend qualify. Twenty unrelated solid dosage products made on the same site do not, even though they are all 'solid dosage forms'.

Even within a group, product-specific data must remain visible. Grouped reviews that pool results across strengths and lose the ability to see that one strength is drifting defeat the purpose. The defensible pattern is a group report with a common section for shared elements (equipment qualification, utilities, contractual arrangements, shared changes) and a product-specific section for results, deviations, complaints and stability. Write the grouping rationale into the procedure and repeat it on the report.

The data collection plan

Most delay is data delay. Results sit in LIMS, deviations in the QMS, changes in a separate module, complaints in a spreadsheet, stability in a third system, variations with regulatory affairs, qualification with engineering, and agreements with the contracts file. A review that starts by asking each of these owners for 'the data' in week one after period end will receive it in week ten.

1. Build a data request pack per product: for each of the twelve items, the source system, the report or query that extracts it, the owner and the date it is due.
2. Pull batch results and in-process data monthly or quarterly into the trending workbook throughout the period, so that at period end only the last quarter is new.
3. Pre-agree the list of critical parameters to be trended and the format, so the data does not arrive as forty different spreadsheets.
4. Request regulatory and MAH-held data (variations, commitments, complaints received by the MAH) through the route the technical agreement defines, with a due date.
5. Reconcile counts: the number of batches in LIMS, in the batch register and in the release log should agree, and the report should say they were reconciled.

Cut-off discipline

The period ends on a date. Deviations opened in the period but closed after it are reported as open, with a note, and are followed up in the next review. Stability time points pulled in the period are included; time points pulled a week after the cut-off are not, even if the result is now available. Chasing late data extends the review indefinitely and blurs the period boundary. State the cut-off on the report and apply it.

Module 3 of the course provides the schedule template, the data request pack and the reconciliation checklist, and works through a grouping justification for a multi-strength product.