Audit Trail GMP: cấu hình review đúng chuẩn

Audit Trail Configuration for GMP, 21 CFR Part 11 and EU GMP Annex 11 explains how to configure logs so they become reviewable quality evidence.

• Audit trails must capture who changed what, when, why and whether the change affected a GxP decision.
• Part 11 and Annex 11 expectations require secure, computer-generated, time-stamped records with controlled access.
• The article focuses on preventing warning-letter patterns caused by disabled logs, shared accounts or unreadable review reports.

Audit trail GMP không thất bại vào ngày thanh tra bước vào phòng họp. Nó thường thất bại sớm hơn nhiều — một tài khoản dùng chung được tạo để “cho tiện”, QA không có màn hình filter để review trước batch release, hoặc admin có thể tắt audit trail mà không tạo dấu vết.

Ngày 24 tháng 2 năm 2025, FDA gửi warning letter đến Aspen Pharmacare Holdings Limited. Cơ sở không ghi nhận và không in các kết quả filter integrity âm tính; chỉ kết quả đạt được in ra. FDA cũng ghi nhận audit trail tồn tại nhưng không được Production và Quality Unit review thường xuyên.

Đây là tình huống audit trail GMP có tồn tại về mặt phần mềm, nhưng thất bại về mặt kiểm soát GMP — vì review tạo action chứ không chỉ ký “đã review.” )

Vấn đề không phải là thiếu phần mềm. Hầu hết hệ thống SCADA, MES, LIMS và EMS hiện đại đều có audit trail được bật mặc định. Vấn đề là nhà máy hiếm khi thiết kế review workflow — ai review, khi nào review, review bao nhiêu record, và khi phát hiện exception thì escalate theo quy trình nào — trước khi audit trail đó bị thanh tra kiểm tra.

Bài này tập trung vào đúng gap đó: từ audit trail có tồn tại đến audit trail có kiểm soát và có thể defend trước inspector.

Nếu đội QA đang cần framework kiểm tra theo PI 041-1 với evidence map cụ thể, xem thêm PIC/S data integrity checklist Việt Nam.

Regulatory baseline cho audit trail GMP cần giữ đúng

Phần này tóm tắt chuẩn tham chiếu để QA biết khung kiểm tra chi phối nội dung phía dưới.

Regulatory baseline: Các nhận định GMP trong bài được đối chiếu trực tiếp theo 21 CFR Part 11.

Audit trail GMP có ba lớp nguồn cần phân biệt rõ. Với thị trường Mỹ, yêu cầu nền tảng là 21 CFR Part 11 §11.10(e). Hệ thống phải có audit trail bảo mật, do máy tính tạo, có timestamp. Audit trail phải ghi độc lập thời điểm operator tạo, sửa hoặc xóa electronic record. Record change không được che khuất thông tin đã ghi trước đó. — https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11/subpart-B/section-11.10

Với thị trường EU, EU GMP Annex 11 revision January 2011 vẫn là phiên bản hiện hành trên EudraLex Volume 4 tính đến ngày 9 tháng 5 năm 2026. Clause 9 yêu cầu cân nhắc xây dựng audit trail theo risk assessment cho việc thay đổi và xóa dữ liệu GMP-relevant. )

EU GMP Annex 11 Draft 2025 là bản consultation, đã đóng góp ý ngày 7 tháng 10 năm 2025, chưa phải yêu cầu hiện hành. Tuy vậy, Section 12 của draft là benchmark rất mạnh cho gap analysis vì mô tả rõ hơn về reason for change, independent review và audit trail review trước batch release. )

Điểm không được nhầm khi viện dẫn quy chuẩn kỹ thuật

Không nên viết rằng Annex 11 Draft 2025 “đã bắt buộc” nhà máy Việt Nam phải review audit trail theo Section 12.8. Cách viết defend được hơn là: “Draft 2025 tạo kỳ vọng mới; nhà máy nên dùng như benchmark cho remediation plan, trong khi baseline pháp lý hiện hành vẫn là Annex 11 revision 2011 và luật GMP áp dụng theo thị trường.”

FDA CSA Guidance February 2026 cũng không phải yêu cầu trực tiếp cho drug CGMP factory. Guidance này áp dụng cho medical device production và quality management system software, do CDRH và CBER ban hành. Với nhà máy thuốc, CSA nên được dùng như benchmark cho critical thinking và risk-based assurance, không thay thế 21 CFR Part 11 hoặc 21 CFR Part 211. )

Bản chất của bằng chứng điện tử và ranh giới với System Log

Phần này làm rõ control GMP và dấu vết evidence cần chứng minh khi bị audit.

Audit trail GMP là bản ghi kỹ thuật cho phép tái dựng lại một sự kiện dữ liệu GxP: ai làm, làm lúc nào, thay đổi cái gì, giá trị trước/sau là gì, và vì sao thay đổi. Với dữ liệu điện tử, audit trail là lớp bằng chứng thay cho trí nhớ con người.

Trong khung nguyên tắc ALCOA+ trong GMP, audit trail GMP hỗ trợ trực tiếp hai thuộc tính dễ bị phá vỡ nhất: Attributable và Original. Nếu cần định nghĩa nhanh trước khi đi vào audit trail, xem thêm ALCOA là gì trong data integrity GMP. Attributable yêu cầu dữ liệu gắn được với cá nhân cụ thể. Original yêu cầu bản ghi gốc và mọi thay đổi sau đó không bị che khuất.

FDA Data Integrity Guidance 2018 định nghĩa audit trail là metadata bảo mật, do máy tính tạo, có timestamp, cho phép tái dựng quá trình tạo, sửa hoặc xóa record. theo FDA, Data Integrity and Compliance With Drug CGMP Questions and Answers, December 2018.)

Phân biệt System Log của hệ thống IT và bằng chứng điện tử của QA

System log có thể ghi login, logout, lỗi dịch vụ hoặc thay đổi cấu hình hệ điều hành. Nó hữu ích cho IT, nhưng không đủ để chứng minh tính toàn vẹn của dữ liệu GMP.

Audit trail GMP phải đi vào dữ liệu ứng dụng. Ví dụ: kết quả assay HPLC đổi từ 98.5% xuống 97.8%; setpoint nhiệt độ trong MES đổi từ 60°C sang 62°C; trạng thái batch record đổi từ “reviewed” về “in progress”. Nếu log chỉ nói “user updated record” mà không có giá trị trước/sau, QA không thể đánh giá tác động GMP.

Bốn trường dữ liệu bắt buộc (Who, When, What, Why) để bảo vệ quyết định chất lượng

Một audit trail GMP defend tốt cần trả lời bốn câu hỏi:

Trong 21 CFR Part 11, trường Why không được viết trực tiếp như một yêu cầu kỹ thuật riêng trong §11.10(e). Nhưng với Data Integrity hiện đại, reason for change là điều kiện để QA đánh giá tính hợp lý của thay đổi. Annex 11 Draft 2025 Section 12.2 đưa Why thành kỳ vọng kỹ thuật rõ hơn: hệ thống phải prompt và register reason khi thay đổi. Đây là điểm nên đưa vào URS cho hệ thống mới.

Khi nào nhật ký điện tử trở thành rủi ro lớn nhất trong ngày thanh tra?

Phần này biến khái niệm thành tình huống thực tế để đội vận hành tự soi gap.

Audit trail GMP trở thành rủi ro cao khi nó không đi cùng review process. Thanh tra hiếm khi dừng lại ở câu hỏi “hệ thống có audit trail không?”. Câu hỏi thật là “ai review, review khi nào, review bằng filter nào, và phát hiện bất thường được xử lý ra sao?”.

Lỗi thứ nhất — Ghi quá nhiều dẫn đến review by exception thất bại

Một số dự án chọn “log everything” để cảm thấy an toàn. Kết quả là QA nhận hàng trăm nghìn dòng log, gồm cả thao tác mở màn hình, timeout, hoặc refresh dashboard. Noise quá lớn làm review mất giá trị.

Cách đúng là xác định Critical Data Elements theo risk assessment. Với LIMS, dữ liệu critical thường là kết quả kiểm nghiệm, specification limit, phương pháp phân tích, trạng thái phê duyệt và OOS/OOT decision. Với MES, dữ liệu critical là recipe step, CPP, alarm override, e-signature và batch status. Electronic Batch Record (eBR) trong GMP: Triển khai từ Master Recipe đến Batch Release theo GAMP 5 và FDA CSA

Lỗi thứ hai — Dùng chung tài khoản (Shared Account) phá hủy thuộc tính Attributable

Nếu ba analyst cùng dùng tài khoản “QC01”, phần mềm không còn chứng minh được ai làm. Shared account biến một bằng chứng kỹ thuật thành một record mơ hồ.

Đặc biệt tại nhiều nhà máy dược phẩm, lỗi phổ biến không chỉ nằm ở hệ thống phức tạp như MES hay LIMS, mà nằm ở các thiết bị độc lập (standalone) trong phòng QC như máy đo pH, cân phân tích hay máy quang phổ. Theo kinh nghiệm triển khai và audit của tôi, các thiết bị này thường là điểm bị hỏi sâu nhất: chúng thường được dùng chung một tài khoản operator mặc định, không ghi nhận dấu vết khi một cá nhân đổi giờ hệ thống (system time) để lùi ngày phân tích, hoặc dữ liệu in nhiệt bị phai mờ không thể truy xuất giá trị trước/sau. Việc thiết lập phân quyền người dùng và kiểm soát quyền admin trên thiết bị standalone là bước đầu tiên để đáp ứng tính Attributable.

Annex 11 Draft 2025 Section 11.1 dùng ngôn ngữ rất mạnh khi nói shared account, trừ quyền read-only, là vi phạm data integrity. Vì đây là draft, nên không viết như yêu cầu hiện hành. Nhưng xét theo ALCOA+, shared account luôn là rủi ro không thể defend. Access Control và Segregation of Duties trong GMP: Phân quyền đúng để bảo vệ Data Integrity

Lỗi thứ ba — Quyền Admin không được kiểm soát (Admin Bypass)

Một hệ thống cho phép admin chỉnh database, xóa log, sửa timestamp hoặc tắt audit trail mà không tạo audit entry là hệ thống có lỗ hổng trọng yếu. Vấn đề không nằm ở việc admin “có làm hay không”. Vấn đề là regulated user không chứng minh được rằng điều đó không thể xảy ra.

Trong URS và OQ, cần test tối thiểu ba điểm: user thường không thấy chức năng tắt audit trail; admin action tạo log riêng; và thay đổi system time bị chặn hoặc tạo record rõ ràng. Đây là test critical function, không nên bỏ qua dù áp dụng CSA hay GAMP 5 risk-based.

Thiết kế quy trình kiểm tra (Review) trước khi phê duyệt lô xuất xưởng (Batch Release)

Phần này làm rõ control GMP và dấu vết evidence cần chứng minh khi bị audit.

Một thực tế trong các đợt thanh tra tại nhà máy là SOP (Quy trình thao tác chuẩn) review thường được viết quá chung chung, ví dụ “QA review dữ liệu điện tử hàng tháng”. Theo kinh nghiệm triển khai và audit của tôi, thanh tra thường yêu cầu QA chỉ rõ: review bằng chức năng filter nào trên phần mềm, tìm kiếm những từ khóa nào (như ‘deleted’, ‘overridden’, ‘aborted’, ‘modified’), và biểu mẫu (form) lưu kết quả review có phần đánh giá tác động đến lô đang sản xuất hay không. Nếu hệ thống không hỗ trợ filter và QA phải kéo xem thủ công hàng ngàn dòng sự kiện, hệ thống thường bị đánh giá là không hiệu quả (ineffective) và gây nghi ngờ cho quyết định xuất xưởng lô.

Việc review nên được thiết kế như một hoạt động chất lượng định lượng được, không phải phụ lục IT. SOP cần nêu scope, trigger, tần suất, reviewer độc lập, filter dùng để review, cách ghi kết quả “no exception”, và cách chuyển exception sang deviation/CAPA.

Phân tầng tần suất theo rủi ro

Không phải hệ thống nào cũng cần review cùng tần suất. Hệ thống tác động trực tiếp batch release như MES, LIMS, CDS, eBR và eQMS cần review trước release hoặc theo từng batch khi dữ liệu của hệ thống là bằng chứng release. Hệ thống hỗ trợ như EMS, WMS hoặc SCADA có thể review định kỳ theo risk, nhưng các event ảnh hưởng CPP/CQA phải có trigger riêng.

Một ví dụ số: nếu một batch sterile có 42 thay đổi setpoint, 7 alarm override và 3 thay đổi kết quả IPC, QA không nên review ngẫu nhiên 52 dòng. QA cần filter theo event critical, user ngoài ca, repeated changes và action sau khi record đã được review. Đây là review by exception đúng nghĩa.

Checklist kiểm tra ngoại lệ (Exception) tối thiểu dành cho QA

Kết quả review phải ghi nhận cả khi không phát hiện bất thường. “No exception observed” vẫn là một record GMP và cần được ký bởi reviewer có thẩm quyền.

Validation — test đúng chỗ, không test mọi chỗ

Phần này nối yêu cầu validation với evidence cần giữ trong hồ sơ thẩm định.

Validation audit trail GMP không phải là chạy mọi nút trong phần mềm. Mục tiêu là chứng minh các chức năng có tác động Data Integrity hoạt động đúng, không bị bypass, và tạo bằng chứng đọc được trong thời gian lưu trữ.

Những Test Case kiểm soát truy cập và dấu vết thay đổi không được phép bỏ qua

Các test tối thiểu nên gồm: tạo record mới; sửa dữ liệu critical; xóa hoặc hủy record nếu hệ thống cho phép; thay đổi trạng thái phê duyệt; thao tác e-signature; thay đổi quyền user; thay đổi cấu hình audit trail; và thử truy cập audit trail bằng user không đủ quyền.

Với mỗi test, expected result phải nêu rõ entry audit trail cần có Who, When, What, Why, old value/new value, và timestamp do hệ thống tạo. Nếu OQ chỉ test “audit trail created successfully” mà không kiểm tra nội dung entry, test đó chưa đủ sức defend.

CSA dùng để giảm giấy tờ, không giảm control

FDA CSA February 2026 khuyến khích tập trung assurance vào intended use và risk của software. Nhưng audit trail, access control, calculation logic, electronic signature và data export thường là critical functions. Nói cách khác, CSA giúp bỏ bớt test script ít giá trị, không cho phép bỏ test audit trail.

Annex 11 vs 21 CFR Part 11: So sánh toàn diện hai tiêu chuẩn vàng về hệ thống máy tính GMP năm 2025 để map các yêu cầu Part 11 và Annex 11 vào validation strategy song hành.

EBR Recipe: Master Recipe vs Control Recipe theo ISA-88

Phần này mở rộng bối cảnh audit trail sang lớp recipe trong hệ thống Electronic Batch Record, nơi mọi thay đổi parameter đều tạo dấu vết GMP.

Theo mô hình phân tầng recipe của chuẩn batch control ISA-88 (IEC 61512), recipe là tập hợp các chỉ dẫn xác định nguyên liệu, thiết bị, thông số và trình tự cần thiết để sản xuất một lô sản phẩm. Chuẩn này phân biệt rõ hai cấp độ recipe có ý nghĩa khác nhau đối với QA và kỹ sư validation: master recipe và control recipe.

Master recipe là công thức tổng thể đã được phê duyệt, định nghĩa quy trình sản xuất cho một sản phẩm cụ thể trên một dây chuyền hoặc thiết bị cụ thể. Nó bao gồm danh sách nguyên liệu với định lượng, các phase hoặc step theo trình tự, các critical process parameters (CPP) như nhiệt độ, áp suất, thời gian khuấy, và các tolerance cho phép. Master recipe là tài liệu tham chiếu — nó không trực tiếp điều khiển sản xuất mà đóng vai trò template cho mọi lô chạy sau này.

Control recipe được tạo ra từ master recipe khi một lô sản xuất cụ thể được khởi tạo. Control recipe mang toàn bộ thông tin của master recipe cộng thêm các dữ liệu riêng cho lô đó: mã lô, quy mô thực tế, thiết bị được gán, thời gian bắt đầu dự kiến. Khi hệ thống MES hoặc EBR thực thi control recipe, mọi giá trị thực tế — actual value so với target value, operator thực hiện, timestamp từng step — đều được ghi vào batch record điện tử. Bất kỳ sai lệch nào giữa parameter trong control recipe và giá trị thực tế vận hành đều kích hoạt audit trail entry, và nếu vượt tolerance, hệ thống có thể block bước tiếp theo hoặc yêu cầu QA intervention.

Recipe management trong hệ thống EBR xoay quanh ba trụ cột chính. Thứ nhất là versioning: mỗi lần sửa đổi master recipe — thay đổi CPP, điều chỉnh tolerance, thêm hoặc bớt step — hệ thống tạo phiên bản mới và lưu giữ toàn bộ lịch sử phiên bản. Phiên bản cũ không bị xóa mà được giữ lại để truy xuất, phục vụ both cho tra cứu lô lịch sử và cho thanh tra. Thứ hai là approval workflow: master recipe phải đi qua các trạng thái draft, reviewed, approved trước khi được phép dùng để tạo control recipe. Thông thường, Production soạn thảo, QA review và phê duyệt cuối cùng. Role-based access control đảm bảo người soạn không tự approve recipe của mình — đây chính là segregation of duties áp dụng ở lớp recipe. Thứ ba là parameter set: mỗi recipe chứa một bộ thông số có cấu trúc, và hệ thống EBR cần enforce rằng chỉ parameter set từ master recipe đã approved mới được push xuống thiết bị sản xuất.

Mối liên hệ giữa recipe management và batch record điện tử là mối liên hệ nhân quả: eBR của mỗi lô chính là bản ghi thực thi của control recipe tương ứng, mà control recipe lại là snapshot của master recipe tại thời điểm lô được tạo. Khi thanh tra yêu cầu xem lại lịch sử recipe của một lô, hệ thống EBR phải cung cấp được: phiên bản master recipe nào đã dùng, ai phê duyệt, khi nào phê duyệt, và có sự khác biệt nào giữa phiên bản đó với phiên bản hiện hành. Đây cũng là lý do audit trail cho recipe change cần đầy đủ bốn trường Who, When, What, Why — giống như audit trail cho bất kỳ GMP data element nào khác đã mô tả ở các phần trên. Với kỹ sư validation, điều này có nghĩa là OQ của hệ thống EBR cần bao gồm test case cho: tạo và approve master recipe mới; generate control recipe từ master recipe đã approved; thay đổi parameter và verify audit trail ghi nhận đúng before/after value; và confirm rằng hệ thống từ chối tạo control recipe từ master recipe chưa approved hoặc đã obsolete.

Decision Moment

Nếu chỉ được hỏi ba câu trước khi audit hệ thống, hãy hỏi:

1. Audit trail GMP của hệ thống có chứng minh được Who, When, What và Why cho mọi dữ liệu ảnh hưởng batch release không?
2. QA có review được exception trong vòng vài phút bằng filter, hay phải đọc log thủ công hàng nghìn dòng?
3. Admin có thể tắt, sửa hoặc xóa audit trail mà không tạo dấu vết độc lập không?

Để chuyển checklist này thành URS, SOP review và test case OQ thực tế, xem thêm tại nampham.net.

FAQ

Phần này gom các câu hỏi giúp QA tự kiểm tra nhanh trước khi audit.

Ghi Chú Minh Bạch

Phần này làm rõ nguồn tham chiếu và ranh giới áp dụng của bài viết.