CAPA GMP theo ICH Q10: RCA hệ thống và effectiveness check

CAPA in GMP with Root Cause Analysis and Effectiveness Check explains how corrective actions should prevent recurrence, not just close deviations.

• CAPA quality depends on problem statement, root-cause method, risk assessment, action ownership and due-date discipline.
• ICH Q10 links CAPA to pharmaceutical quality system performance, management review and continual improvement.
• The article gives practical checks for CAPA evidence that auditors can trace from event to effectiveness verification.

Đọc theo cụm: QMS GMP dược phẩm: kiến trúc ICH Q10 cho CAPA, deviation, change control

CAPA GMP không phải là form đóng sự kiện. Nó là feedback loop để tìm root cause, thiết kế action có closure criteria và kiểm tra hiệu quả thực tế.

Warning letter Medline 2026 cho thấy CAPA có thể tồn tại trên giấy nhưng fail trong thực hành. Điểm gãy xuất hiện khi VOE vượt threshold mà SOP chỉ nói “may” thay vì “shall”.

Bài này hệ thống hóa CAPA theo ICH Q10, EU GMP Chapter 1 và inspection pattern. Trọng tâm là input, trigger, RCA, action design, effectiveness check và điểm yếu thường gặp tại nhà máy chuyển đổi EU-GMP.

CAPA trong ICH Q10: Định nghĩa Chính xác và Phân biệt Corrective vs. Preventive Action

Căn cứ quy định: Các nhận định GMP trong bài được đối chiếu trực tiếp theo ICH Q10 §3.2.2 (Step 4, 2008, vẫn hiện hành), 21 CFR 211.192, 21 CFR 211.22 và EU GMP Chapter 1 §1.4(xiv) (Revision 3, 2013, vẫn hiện hành).

Trả lời ngắn: CAPA trong GMP là hệ thống hành động khắc phục (Corrective Action) và phòng ngừa (Preventive Action) nhằm loại bỏ nguyên nhân gốc rễ của sự cố, sai lệch hoặc khiếu nại chất lượng. Theo ICH Q10 §3.2.2, CAPA là một trong bốn PQS elements cốt lõi và đòi hỏi quy trình điều tra có cấu trúc để xác định root cause.

• Corrective Action: loại bỏ nguyên nhân gốc của sự cố đã xảy ra để ngăn tái diễn.
• Preventive Action: loại bỏ nguyên nhân của sự cố tiềm ẩn trước khi xuất hiện.
• Trigger: deviation, complaint, product rejection, non-conformance, recall, audit, inspection finding và trend từ process monitoring.
• Khi root cause thật không xác định được: EU GMP Chapter 1 §1.4(xiv) yêu cầu xem xét “most likely root cause” (EudraLex Vol.4 Ch.1).

ICH Q10 (Step 4, 2008, hiện hành) Section 3.2.2 định nghĩa CAPA là một trong bốn PQS elements cốt lõi, cùng với Process Performance & Product Quality Monitoring (3.2.1), Change Management (3.2.3), và Management Review (3.2.4).

Guideline quy định rõ: CAPA phải xuất phát từ điều tra có cấu trúc với mục tiêu xác định root cause, và “level of effort, formality, and documentation of the investigation should be commensurate with the level of risk, in line with ICH Q9.” Đây là nền tảng pháp lý quan trọng: không phải mọi sự kiện đều cần cùng một mức độ điều tra, nhưng mọi sự kiện có risk cao đều cần investigation đủ sâu để justify decision.

Nền tảng risk-based này được chuẩn hóa trong ICH Q9 — nếu cần khung đầy đủ trước khi áp vào CAPA, xem quản lý rủi ro chất lượng (QRM) theo ICH Q9 là gì.

EU GMP Chapter 1 (Revision 3, 2013, vẫn hiện hành) Section 1.4(xiv) bổ sung yêu cầu quan trọng mà nhiều nhà máy bỏ qua: khi root cause thực sự không xác định được, nhà sản xuất phải xác định “most likely root cause” và có biện pháp xử lý nguyên nhân đó.

Guideline cũng nêu rõ: khi human error bị suspect hoặc identified, điều này “should be justified having taken care to ensure that process, procedural or system-based errors or problems have not been overlooked.” Đây chính là nền tảng pháp lý cho nguyên tắc RCA không được dừng ở “operator error.”

Corrective Action vs. Preventive Action — Hai Vế Khác Biệt Hoàn Toàn

Hai vế của CAPA có bản chất hoàn toàn khác nhau và phải được document riêng biệt. Corrective Action — theo định nghĩa ISO 9000:2005 (đã được ISO 9000:2015 thay thế; định nghĩa vẫn được Glossary của ICH Q10 dẫn chiếu) — là “action to eliminate the cause of a detected non-conformity or other undesirable situation,” với mục tiêu prevent recurrence của sự kiện đã xảy ra.

Preventive Action là “action to eliminate the cause of a potential non-conformity or other undesirable potential situation,” với mục tiêu prevent occurrence của sự kiện chưa xảy ra nhưng có nguy cơ.

Việc gộp hai vế này thành một response duy nhất là sai về cấu trúc — và là một trong những điểm FDA inspector đánh giá khi review CAPA system.

Tình huống minh họa: Nhà máy thuốc tiêm vô trùng phát hiện alarm chênh áp phòng sạch bị bypass trong giờ cao điểm. Inspector hỏi: “Preventive action nào ngăn lỗi này tái diễn ở khu vực khác?” Gap phát hiện: action chỉ sửa phòng A, chưa đánh giá cùng logic alarm tại các phòng Grade B. Evidence đã đóng gap: CAPA action plan CAPA-IR-018, impact assessment toàn site, change control CC-EMS-022, QA phê duyệt và lưu theo vòng đời hệ thống.

Nguồn Input và Trigger Criteria: Quyết định Toàn bộ CAPA System

ICH Q10 Section 3.2.2 liệt kê rõ các nguồn input bắt buộc phải được định nghĩa trong SOP: complaints, product rejections, non-conformances, recalls, deviations, audits, regulatory inspections and findings, và trends từ process performance monitoring. Trong thực tiễn GMP, OOS/OOT results từ QC lab, stability failures, và customer complaints là các trigger bổ sung quan trọng.

Classification Matrix: Critical, Major, Minor

Bước phân loại mức độ nghiêm trọng là quyết định đầu tiên và quyết định toàn bộ scope của investigation. Một sự kiện ở mức Critical — có khả năng ảnh hưởng đến patient safety, sterility, hoặc identity/strength/purity của sản phẩm — yêu cầu escalate lên Quality Director ngay lập tức và mở CAPA trong vòng 24 giờ.

Sự kiện ở mức Major — vi phạm quy trình với potential impact đến product quality nhưng không đe dọa patient safety trực tiếp — cần CAPA được mở trong 3–5 ngày làm việc.

Sự kiện ở mức Minor — lệch nhỏ khỏi SOP không có impact đến product quality — có thể được xử lý bằng correction đơn giản mà không cần full CAPA cycle. Các mốc thời gian trên là thông lệ thực hành ngành dựa trên nguyên tắc quản lý rủi ro của ICH Q9 và ICH Q10 §3.2.2, không phải thời hạn cứng trong luật.

Classification matrix này — thông lệ ngành dựa trên nguyên tắc rủi ro của ICH Q9/Q10 — phải được định nghĩa trong SOP với ví dụ cụ thể để đảm bảo consistency. Trigger criteria không được để phụ thuộc vào judgment cá nhân — điều này là một trong những điểm yếu nhất quan sát được trong nhà máy chuyển đổi từ WHO-GMP lên EU-GMP.

Root Cause Analysis: Nguyên tắc “System Level” và Bốn Công cụ Thực tiễn

RCA là bước quyết định thành công hay thất bại của toàn bộ CAPA. FDA inspection không fail công ty vì thiếu corrective action — mà fail vì corrective action không address đúng root cause.

Glenmark Pharmaceuticals (WL 708270-07/11/2025, FEI 3008565058) là case điển hình: sau nhiều dissolution failures lặp lại cho potassium chloride ER capsules và phải recall toàn bộ batch trong expiry từ US market tháng 6/2024, FDA cite rằng “investigation was not sufficient to adequately determine root cause(s) of your repeated dissolution failures during long-term stability testing.” Cụ thể, Glenmark đã bỏ qua một process change từ 2017 liên quan đến thay đổi thiết bị và parameters sản xuất — mặc dù change này có potential impact đến dissolution profile.

FDA yêu cầu “comprehensive, independent assessment of your overall system for investigating deviations, discrepancies, complaints, OOS results, and failures” — ngôn ngữ FDA dùng khi RCA được xem là systemic failure (FDA — Warning Letter 708270 to Glenmark Pharmaceuticals, 11/07/2025).

Bốn Công cụ RCA Phổ biến trong Pharmaceutical GMP

Bốn công cụ RCA phổ biến nhất phục vụ cho các loại vấn đề khác nhau và không nên dùng thay thế nhau một cách tùy tiện. 5-Why Analysis phù hợp nhất với vấn đề có chuỗi nhân quả tuyến tính — hỏi “tại sao?” liên tục cho đến khi đến được nguyên nhân ở cấp system, thường sau 4–6 iterations.

Fishbone Diagram (Ishikawa) phù hợp với vấn đề phức tạp có nhiều contributing factors, phân tích theo sáu nhóm: Machine, Method, Material, Man, Measurement, Environment.

Fault Tree Analysis là công cụ top-down phù hợp với hệ thống kỹ thuật phức tạp như SCADA hay automated manufacturing systems. FMEA là công cụ proactive nhất, thích hợp để prevent failures trước khi chúng xảy ra — đặc biệt quan trọng trong product/process design review.

Trong thực tiễn, kết hợp 5-Why và Fishbone thường cho kết quả tốt nhất: Fishbone mở rộng không gian tìm kiếm để không bỏ sót contributing factors, 5-Why đào sâu vào nguyên nhân được chọn để đến được system root cause. Nguyên tắc cốt lõi: “analyst error” hay “operator error” không phải là root cause có thể đứng độc lập — đây chỉ là symptom.

Root cause thực sự thường là training program không verify effectiveness, SOP không đủ rõ ràng, workload dẫn đến systematic skip steps, hoặc process design thiếu adequate error-proofing.

Tình huống minh họa: Nhà máy thuốc viên có ba deviation lặp lại về độ ẩm hạt sau sấy. Inspector hỏi: “Root cause nào chứng minh đây không chỉ là lỗi vận hành?” Gap phát hiện: CAPA chỉ ghi “đào tạo lại” nhưng không có trend theo lot, ca vận hành và trạng thái sensor. Evidence đã đóng gap: RCA report RCA-CAPA-041, trend chart 12 tháng, biên bản QA/QC/Engineering ký, lưu 5 năm sau hết hạn lô cuối.

Thiết kế Corrective và Preventive Action: Bốn Thành phần Không thể Thiếu

Sau khi xác định root cause, hai nhóm action được thiết kế với mục tiêu khác nhau và phải được document riêng biệt. Corrective Actions nhắm vào vấn đề đã xảy ra: cô lập và disposition batch bị ảnh hưởng, sửa chữa nguyên nhân trực tiếp, cập nhật SOP, retrain nhân viên liên quan.

Preventive Actions nhắm vào hệ thống rộng hơn: implement error-proofing, thêm automated checks trong process, và review tất cả quy trình tương tự để xác định xem cùng root cause có tiềm ẩn ở nơi khác không (xem thêm: Change Control GMP: Phân loại, Impact Assessment và Quyết định Revalidation theo ICH Q10).

Bốn Thành phần Bắt buộc cho Mỗi Action

Mỗi action — cả CA lẫn PA — phải có đủ bốn thành phần sau để được coi là adequately defined. Thứ nhất là mô tả rõ ràng action cần thực hiện — không phải mô tả vague như “improve training” mà phải là “revise SOP-XYZ section 4.3 để thêm mandatory double-check step cho parameter Y, complete by [date].” Thứ hai là owner cụ thể chịu trách nhiệm hoàn thành.

Thứ ba là deadline xác định và realistic — không phải “ASAP.” Thứ tư và quan trọng nhất: closure criteria — tiêu chí định nghĩa rõ khi nào action được xem là hoàn thành.

Nếu closure criteria không được định nghĩa ngay khi mở CAPA, closure sẽ dựa trên judgment chủ quan và CAPA sẽ bị đóng khi action completed, không phải khi problem resolved — đây là ranh giới giữa CAPA system functional và CAPA system chỉ tồn tại trên giấy.

Effectiveness Check: Yếu tố Phân biệt CAPA Trưởng thành và CAPA trên Giấy

Effectiveness Check (EC), hay Verification of Effectiveness (VOE), là bước verify rằng CAPA đã thực sự giải quyết root cause và vấn đề không tái phát trong một khoảng thời gian nhất định.

Case Medline Industries (WL 723866-03/25/2026) minh họa trực tiếp điều gì xảy ra khi VOE plan tồn tại về mặt cấu trúc nhưng thiếu enforcement mechanism: công ty có threshold rõ ràng (15.98 CPM), có dữ liệu monitoring, nhưng khi Q1, Q2, và Q3/2025 đều vượt threshold, SOP dùng ngôn ngữ “may be routed back” — không phải “shall” — khiến CAPA Review Board không có obligation bắt buộc phải hành động.

FDA kết luận công ty “failed to implement section 5.19” của chính SOP CAPA nội bộ — “Your firm did not execute any of the above actions for CAPA-01872” (FDA — Warning Letter 723866 to Medline Industries, 25/03/2026).

Thiết kế EC: Predefined Criteria và “Shall” Language

EC phải được lên kế hoạch ngay từ lúc mở CAPA với ba thành phần bắt buộc. Thứ nhất: thời điểm thực hiện, thường 30–90 ngày sau khi implement action tùy risk level. Thứ hai: số lượng batches hoặc monitoring cycles cần quan sát để có statistical significance. Thứ ba: objective criteria để pass hoặc fail được biểu đạt bằng ngôn ngữ đo lường được.

Các mốc thời gian 30–90 ngày trên là thông lệ thực hành ngành, không phải thời hạn cứng trong luật. Nếu EC cho thấy vấn đề tái diễn, CAPA phải được re-opened và RCA phải được thực hiện sâu hơn.

Quy tắc quan trọng rút ra từ Medline case: từ ngữ trong EC criteria phải là “shall” không phải “may” — permissive language làm vô hiệu hóa toàn bộ feedback loop.

Tình huống minh họa: Nhà máy nang mềm đóng CAPA sau khi đổi SOP vệ sinh nhưng OOS vi sinh tái xuất hiện sau 2 tháng. Inspector hỏi: “Effectiveness check dựa trên tiêu chí định lượng nào?” Gap phát hiện: CAPA đóng bằng training record, không có tiêu chí pass/fail theo trend vi sinh. Evidence đã đóng gap: effectiveness protocol EFF-CAPA-014, ba kỳ monitoring liên tiếp đạt giới hạn, Quality Head ký, lưu 1 năm sau expiry batch liên quan.

So sánh CAPA System theo Tiêu chí FDA Inspection

CAPA Owner là ai: vai trò và ranh giới với Quality Unit

Không regulation nào đặt tên vai trò “CAPA owner” — đây là cấu trúc nội bộ mà SOP của site phải gán. ICH Q10 §3.2.2 chỉ yêu cầu doanh nghiệp có “a system for implementing corrective actions and preventive actions resulting from the investigation of complaints, product rejections, non-conformances, recalls, deviations, audits, regulatory inspections and findings, and trends from process performance and product quality monitoring” (ICH Q10 Guideline). Hệ thống đó trong thực hành gồm ba vai trò phải tách rời.

• Originator: người phát hiện mở CAPA — có thể là operator, QA hoặc audit team; ghi nhận vấn đề và evidence ban đầu.
• CAPA owner: người chịu trách nhiệm hoàn thành action — thường là trưởng bộ phận nơi root cause nằm (Production, Engineering, QC). Owner ký action completion, không ký closure.
• Quality Unit: review độc lập và phê duyệt closure. Phạm vi điều khoản cần đọc đúng: 21 CFR 211.22(a) giao “the responsibility and authority to approve or reject all components, drug product containers, closures, in-process materials, packaging material, labeling, and drug products” — tức toàn bộ vật tư, bao bì đóng gói, nhãn và sản phẩm — cùng “the authority to review production records” để bảo đảm errors “have been fully investigated”.

Việc Quality Unit phê duyệt đóng CAPA — và việc cấm CAPA owner tự đóng record của chính mình — là thông lệ thực hành ngành suy ra từ trách nhiệm nói trên; 21 CFR 211.22(a) không viết chữ “CAPA”, điều khoản quy định quyền phê duyệt vật tư–bao bì–sản phẩm và quyền xem hồ sơ sản xuất. Trên thực tiễn đó, ranh giới phân vai là: CAPA owner thực thi action nhưng Quality Unit giữ quyền đóng. CAPA owner tự đóng record của chính mình phá vỡ segregation of duties — cùng nguyên tắc phân quyền trong access control và segregation of duties GMP áp cho hệ thống máy tính. Với CAPA sinh từ deviation, owner thường là bộ phận nơi deviation xảy ra; trong MES dược phẩm hoặc eQMS, workflow ép segregation này bằng role-based approval — owner không thể ký closure trên record của mình.

CAPA tại Nhà máy Việt Nam Chuyển đổi từ WHO-GMP lên EU-GMP

Trong bối cảnh các nhà máy Việt Nam nâng cấp lên EU-GMP, điểm yếu trong CAPA system thường không nằm ở sự thiếu vắng của quy trình mà ở hai chỗ cụ thể nhất quán với regulatory enforcement data 2025–2026.

Thứ nhất, RCA dừng ở “operator/analyst error” mà không đi đến system root cause — vi phạm trực tiếp yêu cầu EU GMP Chapter 1 Section 1.4(xiv) về việc không được bỏ qua “process, procedural or system-based errors.” Thứ hai, Effectiveness Check không có predefined criteria và không được lên kế hoạch từ khi mở CAPA — dẫn đến feedback loop tồn tại trên giấy nhưng không được thực thi trong practice, đúng như pattern FDA cite trong Medline case.

Lưu ý minh bạch: nhận xét về pattern tại nhà máy Việt Nam dựa trên đặc điểm chuyển đổi WHO-GMP sang EU-GMP được ghi nhận trong regulatory literature; không có khảo sát thống kê được công bố chính thức về tần suất của các lỗi cụ thể này tại Việt Nam. (xem thêm: APQR Pharmaceutical: Xây dựng Annual Product Quality Review Đúng Chuẩn FDA và EU GMP)

Tình huống minh họa: Nhà máy vaccine có nhiều CAPA quá hạn trong cùng nhóm thiết bị HVAC. Inspector hỏi: “Management review đã nhận diện rủi ro hệ thống chưa?” Gap phát hiện: từng CAPA được xem riêng lẻ, không có heatmap theo equipment family. Evidence đã đóng gap: Quality Council minutes QC-2026-05, CAPA aging dashboard, quyết định tăng PM frequency, Site Head và QA Director ký, lưu 10 năm.

Decision Moment — 3 Câu hỏi trước khi Chuẩn hóa CAPA System

Trước khi áp dụng các nội dung trong bài, QA, Engineering và owner hệ thống nên khóa ba quyết định sau để tránh biến insight kỹ thuật thành checklist chung chung không tạo thay đổi vận hành.

1. Ranh giới hệ thống hoặc quy trình nào trong CAPA GMP phải được định nghĩa lại trước khi audit tiếp theo — đặc biệt trigger criteria và EC language?
2. Bằng chứng GMP nào cần được tạo tự động (automated monitoring dashboard) thay vì dựa vào giải thích thủ công sau khi threshold bị vượt?
3. Ai là owner chịu trách nhiệm cập nhật SOP, training record và EC criteria sau khi các insight trong bài này được áp dụng?

Để chuyển các khuyến nghị trong bài thành kế hoạch triển khai khả thi, xem thêm tại nampham.net.

FAQ về CAPA GMP

Ghi Chú Minh Bạch