It is short by design: one meeting, one checklist, and targeted fixes. When teams keep it lean, PQR becomes routine and reliable.

PQR is anchored in public expectations. For placement and packaging rules, keep EMA eSubmission close. For U.S. pharmaceutical quality language and common CMC expectations, see FDA pharmaceutical quality. For Japan procedures and local naming, use PMDA. PQR does not copy these pages into the file; it checks that the submission follows them.

Scope, Definitions, and Roles: Who Owns What in the PQR

Scope. PQR covers the complete eCTD sequence that is about to be dispatched: Modules 1–5, the cover letter, and any indices. It confirms identity parity (product name, dosage form, strengths, route, container-closure, storage sentence) across Module 1, Module 3, labeling, and summaries; traceability from claims to tables/figures; and technical integrity (bookmarks, links, fonts, file sizes, lifecycle). It also verifies that administrative items (forms, fees, authorizations) are in the correct nodes and signed when required.

Definitions. The PQR checklist is the short, version-controlled list of items that must be verified for every sequence. The link-test log records three tested links per major PDF (source → target → pass/fail). The identity sheet contains approved strings for product, strengths, route, container-closure, storage, and site names/addresses. The defect list is a dated table of findings with an owner and deadline for each fix. The readiness note is the one-page sign-off by the PQR lead and functional owners.

Roles and ownership (simple RACI).

• PQR Lead (Regulatory Operations or Publishing). Runs the review, maintains the checklist, confirms validation readiness, and issues the readiness note. Accountable.
• Regulatory CMC/Clinical Authors. Verify numbers, captions, labels, and cross-references; fix content defects; confirm that every claim has a module/table anchor. Responsible.
• Quality/QA. Checks signatures, controlled document status, and parity between quality statements and Module 3 tables; verifies that evidence is traceable to approved reports. Responsible.
• Labeling Lead. Confirms exact match between labeling text and Module 3 stability/shelf-life and identity strings; checks Clean/Redline/SPL or SmPC clean/tracked pairs. Responsible.
• Admin/Module 1 Owner. Confirms forms, fees, identity numbers (DUNS/FEI/OMS), agent/representation letters, LOAs; verifies correct nodes and titles. Responsible.
• RIM/IT. Ensures IDs and metadata sync with master data and that the sequence banner, lifecycle, and indexes are aligned. Consulted.
• Program Lead. Approves go/no-go; escalates resource needs for urgent fixes. Informed/Approver.

Evidence. PQR accepts only recorded evidence: checklist with initials and timestamps; link-test log; validator report; parity screenshots or excerpts; and a defect list with closure notes. If it is not recorded, it did not happen. Keep evidence in the submission record for inspection readiness.

Step-by-Step Workflow with Owners: From T-15 to Dispatch

T-15 to T-10 (Planning and freeze). The PQR Lead schedules the review and circulates the latest checklist, identity sheet, and style guide for leaf titles and bookmarks. Authors declare content “frozen for PQR” (no scope changes; only defect fixes allowed). The Admin Owner freezes Module 1 forms and fee receipts. The Labeling Lead freezes Clean/Redline/SPL (or SmPC clean/tracked).

T-9 to T-6 (Self-checks and sampling). Authors run a self-check against the checklist, focusing on parity and traceability: each numeric claim has an exact module/table anchor; captions and units are consistent; shelf-life text is identical across Module 3 and labeling; device statements (if any) match performance tables. Publishing compiles PDFs with fonts embedded and initial bookmarks. The RIM/IT team prepares the lifecycle plan (new/replace/delete) per node and a sequence banner listing contents by module.

T-5 (PQR session, 60–90 minutes). The team walks the package in this order: (1) Module 1 admin pack; (2) Module 2 overviews/summaries; (3) Module 3 specifications, stability, and key validations; (4) Module 5 CSRs and integrated summaries if applicable; (5) Labeling files. For each section, the owner shows proof of parity and traceability using short excerpts and the identity sheet. The PQR Lead records defects in the list with owner and due date. No live rewriting; only decisions and assignments.

T-4 to T-2 (Fix and verify). Owners correct defects. Publishing rebuilds affected PDFs, updates bookmarks, and runs the link-test log (three links per major PDF: one section, one table, one cross-PDF). QA or a peer reviewer re-checks parity items and initials the checklist. The PQR Lead updates lifecycle if file splits/merges changed nodes.

T-1 (Validation and final QC). Run validator; resolve warnings or document a reason for any accepted warning. Confirm file sizes, page numbering, and that no PDF security blocks copy/paste. Re-run a small link-test on files touched after validation. Admin Owner confirms fee proof and signatures. Labeling Lead reconfirms Clean/Redline/SPL or SmPC pair integrity. Program Lead reviews the defect list: all items must be closed or explicitly waived with rationale.

T-0 (Readiness note and dispatch). PQR Lead issues the readiness note with checklist, link-test log, validator report, parity excerpts, and the final defect list. Program Lead signs go/no-go. Publishing builds the sequence with agreed lifecycle and submits through the regional portal, then archives gateway acknowledgments with the PQR evidence.

Checklists, Tools, and Templates: Make Quality the Default

PQR checklist (short and reusable). Keep it to one page so teams use it every time. Recommended lines: (1) Identity parity across M1/M3/labeling; (2) Traceability—every key claim has a module/table anchor; (3) Specifications—units/limits/decimals consistent; (4) Stability—shelf-life sentence identical; (5) Labeling—Clean/Redline pair and SPL (US) or SmPC clean/tracked (EU/UK); (6) Bookmarks—two-level tree for major PDFs; (7) Hyperlinks—link-test log complete; (8) Leaf titles—human-readable, no internal filenames; (9) Lifecycle—new/replace/delete per node; (10) Validator—warnings resolved or justified; (11) Forms/fees—proof attached and correct; (12) Contact mailbox—monitored group address present in cover letter/forms.

Templates and masters. Use an identity sheet as the single source for product strings, storage, and site names/addresses (with DUNS/FEI/OMS where applicable). Use a spec master for tests, methods, units, and limits to prevent retyping. Keep a validation matrix listing method IDs and claims. Maintain a small leaf-title style guide and a bookmark skeleton for QOS, specifications, stability, CSRs, and integrated summaries.

Evidence capture. The PQR folder should contain: the signed checklist; link-test log; validator report; parity screenshots (e.g., shelf-life sentence in P.8.3 and in labeling); the sequence banner; and gateway acknowledgments after dispatch. Store it with the submission record for inspection readiness and future learning.

Metrics dashboard. Track three simple KPIs: (1) Admin/technical findings per sequence (target → downward trend); (2) First-time-right (no PQR-preventable questions); (3) Cycle time from “content freeze” to dispatch. Display by product and by function (authoring, publishing, admin) to focus training.

Anchors to public guidance. Keep one internal reference page with links to EMA eSubmission, FDA pharmaceutical quality, and PMDA. Use these to settle placement or naming questions; do not paste long guidance text into the dossier.

Common Issues and Practical Fixes: What PQR Catches in Minutes

Problem: Shelf-life text differs between Module 3 and labeling. Fix: keep a single source sentence in the identity sheet or stability panel; copy it character-for-character into P.8.3 and labeling. PQR must compare the exact strings side by side and record parity.

Problem: Numeric drift across modules. Authors retype tables and create small rounding or unit errors. Fix: render or copy from spec master and approved tables; include a note in the checklist that decimals and units were matched for assay, impurities, dissolution, and content uniformity.

Problem: Missing or weak cross-references. Reviewers see claims without coordinates. Fix: enforce a simple rule: any decision-relevant sentence ends with “see [module path], Table/Figure [ID].” PQR checks five random claims per major section.

Problem: Broken links and poor bookmarks. Hyperlinks fail after stamping or merging; bookmarks land on the wrong pages. Fix: link by named destination, not page number; run the link-test log after final assembly; keep two-level bookmarks that match headings and key tables only.

Problem: Lifecycle operators wrong. Files marked “new” instead of “replace” break history. Fix: PQR validates lifecycle per node against the sequence banner; publishing corrects operators before build. Treat “delete” as exceptional and document the reason.

Problem: Forms/fees in the wrong node or with mismatched identifiers. Fix: Admin Owner verifies legal entity, DUNS/FEI/OMS, and payer names against the identity sheet; places receipts and waivers adjacent; standardizes leaf titles (“Proof of Payment — [Reference]”).

Problem: Device or combination product misalignment. Device performance statements do not match Module 3 tests or labeling. Fix: Labeling and CMC owners review a one-row device performance panel and confirm identical units, tolerances, and acceptance criteria across modules.

Problem: Oversized PDFs and scanned images. Files exceed portal limits or are not searchable. Fix: compress images losslessly; avoid image-only tables; embed fonts; re-export scans to text-searchable PDFs. PQR rejects image-only critical tables.

Latest Updates and Strategic Insights: Keep PQR Lean, Predictable, and Measurable

Lean by design. The most effective PQRs avoid long meetings. They rely on a stable checklist, short proof snippets, and a clear defect list. If PQR sessions expand beyond 90 minutes, move background debates upstream into authoring reviews and keep PQR focused on verification, not discussion.

Standardize across regions. Keep one core checklist with small regional annexes. For U.S., include SPL and U.S. administrative forms language; for EU/UK, include eAF and SPOR/OMS checks; for Japan, include local naming and form placement. Content and numbers remain identical; only wrappers change.

Automate the stable parts. Many RIM and publishing tools can inject standard bookmarks, generate leaf titles from controlled lists, and run basic link checks. Automation helps only if the style guide is simple and enforced. Keep free-text fields to a minimum and lock identity strings.

Use sampling wisely. PQR cannot re-review every line. Use risk-based sampling: check all identity and labeling items; sample the highest-impact tables (specifications, stability), the latest changes since the prior sequence, and any sections with new authors. Record the sampling plan in the checklist footer.

Close the loop. After approval or the first Agency questions, tag any issues that PQR should have caught (e.g., numeric mismatch, broken link). Update the checklist to prevent recurrence. Add a short “PQR lessons” note to the submission record so new staff learn from real cases.

Make metrics visible. Share the KPI dashboard monthly. Highlight trends by function and by product. Celebrate zero-defect sequences and first-time-right outcomes. Visible metrics keep teams engaged and drive steady improvement without heavy oversight.

PQR is a simple gate with a big effect. With one page of checks, a small set of masters, and clear ownership, teams reduce avoidable questions, pass technical acceptance cleanly, and give reviewers a dossier that is easy to verify. Keep the process lean, the evidence recorded, and the numbers identical wherever they appear.