GAMP 5

Chủ đề này là một phần của... SG Systems Global Thư viện hướng dẫn về quy định và vận hành.

GAMP 5: quy trình xác thực dựa trên rủi ro, chứng minh mục đích sử dụng, bảo vệ hồ sơ điện tử và có khả năng mở rộng quy mô cho hoạt động thực tế.

Cập nhật tháng 1 năm 2026 • GAMP 5, CSV, kiểm thử dựa trên rủi ro, sự tham gia của nhà cung cấp, xác thực vòng đời sản phẩm, Phần 11, Phụ lục 11 • Liên ngành

GAMP 5 (Thực hành sản xuất tự động tốt, ấn bản thứ 5) là khuôn khổ được sử dụng phổ biến nhất trong ngành để áp dụng tư duy dựa trên rủi ro vào việc xác thực hệ thống máy tính (CSV) . Nói một cách đơn giản, đó là cách các tổ chức được quản lý chứng minh một hệ thống máy tính phù hợp với mục đích sử dụng mà không cần tốn hàng tháng trời "kiểm tra mọi thứ", và cách họ duy trì bằng chứng có giá trị trong các cuộc kiểm toán, điều tra, sai lệch và các sự kiện về chất lượng sản phẩm.

GAMP 5 rất quan trọng vì sản xuất hiện đại vận hành dựa trên phần mềm. Công thức chính là một đối tượng cấu hình. Một "báo cáo" có thể dẫn đến quyết định phát hành. Một quy trình làm việc xác định xem một ngoại lệ có được ghi nhận hay bị bỏ qua một cách âm thầm. Vai trò truy cập có thể quyết định liệu một người có thể tự phê duyệt hay không. Nếu các biện pháp kiểm soát đó yếu – hoặc nếu chúng thay đổi mà không có quy trình kiểm soát thay đổi – bạn không chỉ đối mặt với nguy cơ gián đoạn hoạt động. Bạn còn đối mặt với nguy cơ đưa ra các quyết định sản phẩm không đáng tin cậy và các bản ghi không đáng tin cậy.

Đó là lý do tại sao GAMP 5 không thể tách rời khỏi tính toàn vẹn dữ liệu . Lời hứa cốt lõi của một hệ thống được xác thực không phải là “hệ thống không bao giờ gặp lỗi”. Lời hứa là: khi hệ thống được sử dụng đúng mục đích, nó sẽ tạo ra kết quả đáng tin cậy và bằng chứng đáng tin cậy—được hỗ trợ bởi nhật ký kiểm toán , quyền truy cập được kiểm soát và các bản ghi có thể bảo vệ và xem xét được.

“Việc thẩm định không phải là để chứng minh phần mềm hoàn hảo. Mà là để chứng minh việc sử dụng phần mềm của bạn được kiểm soát.”

1) GAMP 5 thực sự có nghĩa là gì

Về bản chất, GAMP 5 là một giải pháp thực tiễn cho một vấn đề thực tiễn: các hệ thống máy tính quá phức tạp để có thể kiểm định bằng phương pháp thử và sai. Câu hỏi đúng không phải là “chúng ta đã kiểm tra mọi tính năng chưa?” mà là “chúng ta đã kiểm tra những gì chúng ta dựa vào chưa, và chúng ta đã chứng minh được các biện pháp kiểm soát bảo vệ chất lượng và bằng chứng chưa?”

GAMP 5 định nghĩa lại quá trình xác thực như một quy trình vòng đời . Xác thực không phải là một sự kiện diễn ra một lần duy nhất khi triển khai hệ thống. Nó bắt đầu khi bạn xác định các yêu cầu và tiếp tục xuyên suốt quá trình cấu hình, thử nghiệm, phát hành, vận hành và cuối cùng là ngừng hoạt động. Đó là lý do tại sao nó kết hợp một cách tự nhiên với Kế hoạch Tổng thể Xác thực (VMP) : bạn cần một chiến lược được xác định rõ ràng và các quy tắc mở rộng quy mô, chứ không phải một loạt các giao thức và phê duyệt rời rạc.

Nó cũng đối xử với phần mềm khác nhau tùy thuộc vào loại phần mềm đó. Một thành phần cơ sở hạ tầng tiêu chuẩn không được kiểm định giống như một quy trình làm việc MES được cấu hình cao, và cũng không được kiểm định giống như mã ứng dụng tùy chỉnh. Đây là nguyên tắc “mở rộng nỗ lực theo rủi ro và độ phức tạp”, được áp dụng một cách rõ ràng.

Cuối cùng, tiêu chuẩn này nhận ra rằng bạn hiếm khi tự mình xây dựng mọi thứ. Các nhà cung cấp và đơn vị tích hợp đóng vai trò quan trọng. GAMP 5 khuyến khích bạn tận dụng tài liệu và các bài kiểm tra của nhà cung cấp khi thích hợp—đồng thời đảm bảo bạn vẫn chịu trách nhiệm về mục đích sử dụng, các quyết định rủi ro và việc chấp nhận hệ thống trong môi trường của mình.

2) Tại sao GAMP 5 là không thể thương lượng

GAMP 5 không phổ biến vì tính học thuật của nó. Nó phổ biến vì nó phù hợp với cách thức hoạt động thực tế của công việc được quản lý: hệ thống thay đổi, sự tích hợp lệch hướng, con người ứng biến và bằng chứng được xem xét kỹ lưỡng sau khi sự việc đã xảy ra. Một hệ thống có thể "hoạt động" về mặt vận hành nhưng vẫn không đáp ứng được thực tế quản lý vì hồ sơ của nó không đầy đủ, không thể xác định nguồn gốc hoặc không thể khôi phục lại.

Bốn yếu tố tác động khiến phương pháp tiếp cận kiểu GAMP trở nên không thể tránh khỏi:

Nếu không có khuôn khổ dựa trên rủi ro, các nhóm thường chọn một trong hai thái cực tồi tệ: hoặc một gói xác thực khổng lồ tốn rất nhiều thời gian mà vẫn bỏ sót các đường dẫn kiểm soát quan trọng, hoặc một gói tối thiểu trông có vẻ ổn trên giấy tờ nhưng lại sụp đổ khi được kiểm tra kỹ lưỡng. GAMP 5 là cách để bạn tránh cả hai thái cực đó.

3) GAMP 5 so với CSV so với Phần 11 / Phụ lục 11

Các thuật ngữ này thường bị lẫn lộn, và sự nhầm lẫn đó gây lãng phí thời gian. Dưới đây là một sơ đồ hướng dẫn thực tế:

GAMP 5 không phải là một quy định. Nó là một phương pháp giúp bạn đáp ứng các kỳ vọng của cơ quan quản lý. Bạn có thể thực hiện CSV mà không cần gọi đó là GAMP, nhưng nếu bạn bỏ qua các nguyên tắc dựa trên rủi ro, bạn gần như chắc chắn sẽ rơi vào tình trạng kiểm tra quá mức hoặc kiểm soát không đầy đủ.

4) Các nguyên tắc cốt lõi định hướng cách tiếp cận

GAMP 5 có thể được tóm gọn thành một vài nguyên tắc hoạt động. Khi các nhóm "thực hiện GAMP đúng cách", họ thường làm những điều này một cách nhất quán:

• Mục đích sử dụng được ưu tiên hàng đầu: Xác định rõ hệ thống cần thực hiện những gì trong quy trình của bạn, với người dùng của bạn. URS không phải là hoạt động tiếp thị; nó là cơ sở để xác thực.
• Tư duy dựa trên rủi ro: Đánh giá những rủi ro có thể xảy ra và những vấn đề quan trọng; tập trung xác minh vào các chế độ lỗi gây ảnh hưởng lớn.
• Kiểm soát vòng đời: Quá trình thẩm định bắt đầu trước khi đưa vào vận hành chính thức và tiếp tục trong suốt quá trình vận hành cho đến khi ngừng hoạt động.
• Tận dụng nguồn cung ứng từ nhà cung cấp: Hãy sử dụng tài liệu của nhà cung cấp và bằng chứng kiểm thử, nhưng hãy xác minh những gì quan trọng trong cấu hình sử dụng của bạn.
• Truy xuất nguồn gốc: Thể hiện mối liên hệ rõ ràng từ yêu cầu đến kiểm thử và kết quả. Nếu một yêu cầu không có kiểm thử, nó chưa được chứng minh. Nếu một bài kiểm thử không có yêu cầu, nó chỉ là nhiễu.
• Tích hợp hệ thống chất lượng: Kết nối xác thực với kiểm soát tài liệu, kiểm soát sửa đổivà thay đổi kiểm soát.

5) Phân loại hệ thống và những thay đổi mà nó mang lại

Một trong những ý tưởng thực tiễn nhất của GAMP là bạn không cần phải xác thực tất cả phần mềm theo cùng một cách. "Danh mục" giúp bạn quyết định mức độ đặc tả và kiểm thử nào là phù hợp, và bằng chứng từ nhà cung cấp có thể được tận dụng hiệu quả nhất ở đâu.

Một cách đơn giản để truyền đạt việc phân loại là sử dụng bảng liệt kê các loại hệ thống, ví dụ và tư thế xác thực điển hình:

Phân loại không phải là về tính nghiêm ngặt trong trò chơi. Đó là về việc sử dụng bằng chứng phù hợp. Đối với một hệ thống đã được cấu hình, rủi ro lớn nhất của bạn thường là sự sai lệch cấu hình và hành vi quy trình làm việc bị hiểu sai. Đối với mã tùy chỉnh, rủi ro lớn nhất của bạn là các lỗi ẩn và những thay đổi không được kiểm soát. Đối với cơ sở hạ tầng, rủi ro lớn nhất của bạn là tính khả dụng, bảo mật và khả năng phục hồi. Tư thế xác thực cần phải phù hợp với thực tế đó.

6) Các sản phẩm bàn giao trong suốt vòng đời và khả năng truy xuất nguồn gốc

Một lỗi thường gặp là coi các sản phẩm đầu ra xác thực như một danh sách kiểm tra mẫu hơn là một câu chuyện mạch lạc. GAMP 5 khuyến khích một câu chuyện đơn giản: chúng ta đã xác định những gì chúng ta cần, chúng ta đã thiết kế/cấu hình để đáp ứng điều đó, chúng ta đã kiểm tra những gì quan trọng và chúng ta kiểm soát sự thay đổi để đảm bảo tính nhất quán.

Trên thực tế, vòng đời được hỗ trợ bởi một tập hợp nhỏ các thành phần quan trọng. Tổ chức của bạn có thể đặt tên chúng khác nhau, nhưng mục đích thì nhất quán:

• Chiến lược VMP / xác thực: cách tiếp cận cấp cao, vai trò và quy tắc mở rộng quy mô (VMP).
• URS: mục đích sử dụng và các yêu cầu cấp cao (URS).
• Đánh giá rủi ro: Điều gì có thể thất bại và điều gì thực sự quan trọng; thường được tóm tắt bằng một Ma trận rủi ro.
• Thông số cấu hình/thiết kế: Hệ thống sẽ được thiết lập như thế nào để đáp ứng các yêu cầu, bao gồm mô hình truy cập, quy trình làm việc và các phép tính quan trọng.
• Chiến lược kiểm thử: Các bài kiểm tra hiện có là gì, tại sao, và tiêu chí chấp nhận; bao gồm phạm vi hồi quy cho các thay đổi trong tương lai.
• Bằng chứng thi hành án: Hồ sơ thử nghiệm, sai lệch, giải pháp và phê duyệt với trách nhiệm giải trình rõ ràng.
• Phát hành và kiểm soát hoạt động: Quyết định triển khai, bằng chứng đào tạo, quy trình vận hành tiêu chuẩn (SOP), sao lưu/phục hồi và hỗ trợ.

Ngôn ngữ chứng nhận thường giúp cấu trúc bằng chứng. Nhiều nhóm liên kết các bước kiểm tra với IQ (đã cài đặt đúng cách) và OQ (hoạt động như dự định), sau đó xác thực mục đích sử dụng bằng UAT hoặc các bài kiểm tra tập trung vào quy trình. Việc đặt tên ít quan trọng hơn mục đích: chứng minh bản dựng chính xác, chứng minh chức năng chính xác và chứng minh việc sử dụng chính xác trong quy trình của bạn.

Khả năng truy xuất nguồn gốc là yếu tố then chốt. Một ma trận truy xuất nguồn gốc thực tế không cần phải phức tạp. Nó chỉ cần cho phép người dùng theo dõi: Yêu cầu URS → yếu tố thiết kế/cấu hình → trường hợp thử nghiệm → kết quả → bất kỳ sai lệch nào và cách giải quyết chúng. Nếu không thể truy xuất nguồn gốc, bạn không thể chứng minh.

7) Kiểm thử dựa trên rủi ro: cần kiểm thử cái gì và tại sao

Kiểm thử dựa trên rủi ro là nơi GAMP 5 giúp tiết kiệm thời gian và nâng cao chất lượng. Mục tiêu không phải là giảm số lượng bài kiểm tra. Mục tiêu là thực hiện đúng các bài kiểm tra: những bài kiểm tra chứng minh hệ thống kiểm soát được quy trình và bảo vệ bằng chứng.

Một chiến lược thực tiễn tập trung vào “các đường dẫn kiểm soát”. Các đường dẫn kiểm soát là các quy trình làm việc mà nếu sai sót sẽ tạo ra sản phẩm hoặc hồ sơ không chính xác. Ví dụ bao gồm: quyết định phát hành, xử lý ngoại lệ, tính toán quan trọng, thực thi vai trò bảo mật và ghi lại nhật ký kiểm toán.

Để biến “dựa trên rủi ro” thành hiện thực (thay vì chỉ là khẩu hiệu), hãy gắn việc đánh giá với quy trình. Bắt đầu với các quyết định được quy định mà hệ thống hỗ trợ: phát hành, giữ lại, xử lý, tính toán và tạo hoặc sửa đổi các bản ghi được kiểm soát. Sau đó, hãy đặt ba câu hỏi thẳng thắn: (1) nếu điều này thất bại, tác động đến chất lượng sản phẩm hoặc sự an toàn của bệnh nhân/khách hàng là gì, (2) liệu chúng ta có phát hiện ra lỗi trước khi sản phẩm rời khỏi sự kiểm soát hay không, và (3) liệu chúng ta có thể tái tạo lại những gì đã xảy ra chỉ từ các bản ghi của hệ thống hay không? Câu trả lời sẽ thúc đẩy độ sâu thử nghiệm tốt hơn nhiều so với việc đoán dựa trên tên mô-đun.

Khi các nhóm gặp khó khăn, thường là do việc đánh giá rủi ro không được kết nối với các biện pháp kiểm soát bằng chứng. Một bảng mục tiêu kiểm soát đơn giản sẽ giúp việc đánh giá được thực hiện một cách chắc chắn và làm rõ những thử nghiệm nào bạn không được bỏ qua:

Mức độ chi tiết sẽ tăng lên tùy thuộc vào rủi ro. Nếu hệ thống tạo ra các bản ghi lô điện tử (EBR) hoặc bản ghi thiết bị như eDHR , bạn phải kiểm tra vòng đời của bản ghi và quy trình xem xét, chứ không chỉ là "nhập dữ liệu". Nếu hệ thống hỗ trợ việc xử lý dữ liệu, bạn phải kiểm tra các biện pháp kiểm soát việc xử lý. Nếu báo cáo được sử dụng cho các quyết định phát hành hoặc tuân thủ, bạn phải kiểm tra logic báo cáo, bộ lọc và các biện pháp kiểm soát thay đổi (bao gồm cả việc ai có thể chỉnh sửa tham số và cách theo dõi các chỉnh sửa).

8) Sự tham gia của nhà cung cấp mà không làm mất quyền kiểm soát

Sự tham gia của nhà cung cấp là một điểm mạnh của GAMP 5, nhưng nó cũng là một hiểu lầm phổ biến. Việc tận dụng bằng chứng từ nhà cung cấp không có nghĩa là chuyển giao trách nhiệm cho bên thứ ba. Tổ chức của bạn vẫn chịu trách nhiệm về mục đích sử dụng, các quyết định cấu hình và việc chấp nhận hệ thống trong bối cảnh được quy định của bạn.

Việc tận dụng hiệu quả nguồn cung ứng từ nhà cung cấp bao gồm:

• Đánh giá nhà cung cấp: Đánh giá quy trình phát triển và chất lượng của nhà cung cấp; mở rộng phạm vi rủi ro.
• Sử dụng tài liệu: Sử dụng thông số kỹ thuật của nhà cung cấp, ghi chú phát hành và tóm tắt kết quả thử nghiệm làm bằng chứng hỗ trợ.
• Kiểm tra từ nhà cung cấp: Tận dụng việc thử nghiệm tại nhà máy khi có thể; không nên chạy lại các bài kiểm tra có rủi ro thấp giống hệt nhau.
• Hợp đồng rõ ràng: Xác định trách nhiệm đối với các lỗi, hỗ trợ, bảo mật và thông báo về các thay đổi.

Bằng chứng từ nhà cung cấp trở nên đặc biệt quan trọng đối với các hệ thống SaaS và hệ thống được lưu trữ, nơi bạn có thể không kiểm soát được cơ sở hạ tầng bên dưới. Trong những trường hợp đó, sự kiểm soát đúng đắn thường bao gồm: chứng nhận nhà cung cấp + cam kết hợp đồng + xác minh mục đích sử dụng của chính bạn + các kênh truyền thông thay đổi mạnh mẽ. Nếu nhà cung cấp có thể cập nhật hệ thống sản xuất mà bạn không biết, trạng thái đã được xác thực của bạn sẽ không ổn định.

9) Quản lý các bản vá lỗi, nâng cấp và sự thay đổi cấu hình

Quá trình xác thực không kết thúc khi hệ thống chính thức đi vào hoạt động. Thực tế bao gồm các bản vá lỗi, sửa lỗi bảo mật, điều chỉnh quy trình làm việc, báo cáo mới và thay đổi tích hợp. Một chương trình GAMP 5 vượt qua được thực tế bằng cách coi sự thay đổi là một phần của vòng đời, chứ không phải là ngoại lệ.

Ba yếu tố kiểm soát giúp duy trì trạng thái đã được xác thực ổn định:

• Thay đổi kiểm soát: Các thay đổi được đánh giá, phê duyệt, thử nghiệm và ghi chép lại trước khi thực hiện.
• Kiểm soát sửa đổi: Các phiên bản cơ bản của cấu hình, tập lệnh và thông số kỹ thuật chính được lưu trữ và có thể truy xuất.
• Chiến lược hồi quy: Mỗi thay đổi đều có phạm vi ảnh hưởng xác định; việc nói "chúng tôi không nghĩ nó sẽ ảnh hưởng đến điều đó" không phải là lời bào chữa.

Một bộ quy tắc đơn giản sẽ hữu ích: nếu một thay đổi ảnh hưởng đến quy trình làm việc được quy định, các phép tính quan trọng, vai trò truy cập, cài đặt nhật ký kiểm toán, giao diện hoặc báo cáo được sử dụng để phát hành, hãy coi đó là sự thay đổi cần xác thực lại. Nếu đó chỉ là thay đổi mang tính thẩm mỹ hoặc không tuân thủ GxP, hãy ghi lại lý do và giới hạn việc kiểm thử cho phù hợp dựa trên rủi ro.

Đối với các hệ thống như MES và các hoạt động kết nối, việc vá lỗi và cập nhật an ninh mạng là cần thiết. Nhưng một chương trình vá lỗi thiếu kỷ luật xác thực sẽ trở thành một cỗ máy hoạt động hỗn loạn: các bản cập nhật được đưa vào sử dụng, các lỗi hồi quy không mong muốn xuất hiện, và người dùng mất niềm tin. Một chương trình hoàn thiện sẽ liên kết việc vá lỗi với việc kiểm thử hồi quy dựa trên rủi ro, tích hợp với quản lý môi trường và lưu giữ hồ sơ chứng cứ có thể được trình bày nhanh chóng trong các cuộc kiểm toán.

10) Tính toàn vẹn dữ liệu, nhật ký kiểm toán và chữ ký điện tử

Việc xác thực dựa trên rủi ro sẽ thất bại nếu bỏ qua các biện pháp kiểm soát bằng chứng. Trong môi trường được quản lý chặt chẽ, "sản phẩm" chính của hệ thống có thể là hồ sơ. Đó là lý do tại sao việc xác thực theo GAMP 5 cần kiểm tra rõ ràng các thuộc tính về tính toàn vẹn dữ liệu và các biện pháp kiểm soát hồ sơ điện tử.

Các bước kiểm tra tính toàn vẹn có giá trị cao bao gồm:

• Ghi nhận: Các hành động được liên kết với người dùng riêng biệt; tài khoản dùng chung bị cấm hoặc được kiểm soát chặt chẽ.
• Tính đầy đủ của nhật ký kiểm toán: Hệ thống ghi lại các sự kiện tạo/sửa đổi/xóa quan trọng và có thể tạo ra chúng theo yêu cầu (dấu vết kiểm toán).
• Kiểm soát thời gian: Dấu thời gian được nhất quán và bảo vệ; các thay đổi về thời gian được kiểm soát và ghi lại.
• Ý nghĩa chữ ký: chữ ký điện tử Gắn liền với hành động và giữ nguyên ý nghĩa theo thời gian.
• Lưu trữ và truy xuất hồ sơ: Hồ sơ vẫn có thể truy cập và đọc được trong thời gian lưu giữ theo quy định.
• Tính toàn vẹn của dữ liệu xuất khẩu: Dữ liệu xuất ra là đầy đủ và không bị lọc chọn lọc mà không có khả năng truy vết.

Các biện pháp kiểm soát này hỗ trợ những kỳ vọng thường thấy liên quan đến 21 CFR Phần 11 và Phụ lục 11 , nhưng điểm mấu chốt còn lớn hơn cả việc tuân thủ. Điểm mấu chốt là: khi có sự cố xảy ra, bạn có thể khôi phục lại sự thật mà không cần dựa vào trí nhớ hoặc các bảng tính không chính thức.

Hầu hết các tổ chức cũng dựa trên tư duy liêm chính vào các nguyên tắc như ALCOA . Nếu hệ thống làm suy yếu các yếu tố “có thể quy kết”, “đồng thời” hoặc “nguyên bản”, thì dù nó vẫn hoạt động được nhưng không thể biện minh được.

11) Các mô hình phân phối linh hoạt, điện toán đám mây, SaaS và hiện đại

GAMP 5 đôi khi bị hiểu nhầm là “phương pháp kiểm định thác nước”. Đó là một sự hiểu lầm. Khung phương pháp này tương thích với các phương pháp phát triển phần mềm linh hoạt và hiện đại nếu bạn giữ nguyên các nguyên tắc: xác định yêu cầu, kiểm thử dựa trên rủi ro, phát hành có kiểm soát và bằng chứng có thể truy vết.

Những giải pháp thích ứng thực tế hiệu quả:

• URS lặp lại: Xác định mục đích sử dụng ngay từ đầu và tinh chỉnh bằng các bản sửa đổi có kiểm soát; giữ mức cơ sở dưới mức kiểm soát sửa đổi.
• Bằng chứng kiểm nghiệm liên tục: Hãy sử dụng bằng chứng từ các bài kiểm thử tự động khi chúng đáng tin cậy, nhưng cần đảm bảo chúng có thể được xem xét lại và liên kết với các yêu cầu.
• Xác thực dựa trên bản phát hành: Hãy xem mỗi bản phát hành là một thay đổi có kiểm soát; chạy thử nghiệm hồi quy dựa trên rủi ro trước khi đưa vào sử dụng chính thức.
• Phân định trách nhiệm trên nền tảng đám mây: Xác định rõ những gì nhà cung cấp kiểm soát và những gì bạn kiểm soát; kiểm tra tính xác thực của các bộ phận mà bạn phụ thuộc vào.

Đối với các công cụ mã thấp và bảng tính, rủi ro không nằm ở công nghệ mà là ở việc thiếu các biện pháp kiểm soát. Một bảng tính được sử dụng để tính toán kết quả phát hành là một hệ thống được quản lý trên thực tế, ngay cả khi bộ phận CNTT chưa bao giờ phê duyệt nó. Hãy áp dụng cùng một logic GAMP: mục đích sử dụng, đánh giá rủi ro, kiểm soát phiên bản, kiểm soát truy cập và xác minh công thức. Nếu bạn không thể kiểm soát nó, bạn không nên dựa vào nó để đưa ra quyết định.

12) Rủi ro giao diện và tích hợp

Giao diện là nơi mà các hệ thống đã được kiểm định thường âm thầm gặp lỗi. Ứng dụng cốt lõi có thể đã được kiểm định, nhưng lớp tích hợp lại sao chép các giao dịch, làm mất thông báo hoặc sắp xếp lại các sự kiện theo cách làm sai lệch tính xác thực. Trong các hoạt động kết nối, giao diện là một phần của chức năng đã được kiểm định.

Các trường hợp tích hợp có rủi ro cao thường gặp bao gồm:

• ERP: Đơn đặt hàng, xác nhận, theo dõi biến động hàng tồn kho, trạng thái lô hàng và các bút toán tài chính.
• LIMS: Kết quả, thông số kỹ thuật, liên kết COA và các yếu tố ảnh hưởng đến quyết định.
• eQMS: Các sai lệch, điều tra, phê duyệt, nhiệm vụ CAPA và quy trình thay đổi.
• Kết nối MES và dây chuyền sản xuất: Các cổng tích hợp, liên kết PLC và các bộ điều phối thông điệp điều khiển hành vi thực thi.

Việc xác thực giao diện cần kiểm tra rõ ràng các yếu tố sau: khả năng chống trùng lặp (tính bất biến), các giả định về trình tự và thời gian, số lượng đối chiếu giữa các hệ thống và khả năng kiểm toán các hành động trên giao diện. Nếu không thể đối chiếu, bạn không thể chứng minh tính đầy đủ của bản ghi.

13) Nghỉ hưu, di cư và giữ chân nhân viên

GAMP 5 là tiêu chuẩn xác thực vòng đời, bao gồm cả giai đoạn kết thúc vòng đời. Việc ngừng hoạt động hệ thống là một sự kiện có rủi ro cao vì nó thường làm gián đoạn việc truy cập dữ liệu. Nếu bạn ngừng hoạt động một hệ thống và sau đó không thể truy xuất dữ liệu để phục vụ điều tra, bạn đã tạo ra một lỗi vi phạm quy định sau khi sự việc đã xảy ra.

Việc ngừng hoạt động hệ thống cũ cần được quản lý như một quá trình thay đổi: xác định những hồ sơ nào cần được lưu giữ, cách thức truy cập chúng và cách chứng minh tính đầy đủ của chúng. Điều này liên quan đến việc lưu trữ dữ liệu và các thực tiễn bảo quản dữ liệu . Kết quả đúng đắn không phải là "hệ thống cũ đã bị tắt". Kết quả đúng đắn là "các hồ sơ vẫn có thể truy cập, đọc được và theo dõi được trong toàn bộ thời gian lưu giữ, với cùng ý nghĩa như khi chúng được tạo ra".

Đối với các dự án di chuyển dữ liệu, hãy coi việc ánh xạ và chuyển đổi dữ liệu là một phần của phạm vi được xác thực. Di chuyển dữ liệu không chỉ đơn thuần là sao chép các bảng; nó còn là việc bảo toàn ý nghĩa. Nếu một bản ghi thay đổi hình thức, bạn phải chứng minh rằng ý nghĩa và khả năng kiểm toán đã được bảo toàn, và bản thân quá trình di chuyển đã được kiểm soát thông qua quản trị thay đổi.

14) Các chỉ số KPI và nhịp độ hoạt động

Một chương trình GAMP 5 cần phải đo lường được. Nếu không đo lường được, nó có xu hướng trở nên quan liêu hoặc bị bỏ bê. Một bộ KPI nhỏ giúp giữ cho chương trình hoạt động minh bạch.

Tần suất rất quan trọng. Môi trường thay đổi nhanh cần xem xét tình trạng xác thực thường xuyên hơn so với môi trường ổn định. Mục đích là để phát hiện khi nào quá trình xác thực không theo kịp thực tế — bởi vì thực tế sẽ không chờ đến lần đánh giá hàng năm tiếp theo của bạn.

15) Danh sách kiểm tra “thử nghiệm khối” GAMP 5

Nếu bạn muốn kiểm tra nhanh chóng và triệt để xem chương trình của mình có thực sự hiệu quả hay không, hãy sử dụng kiểm thử khối (block test). Phương pháp này tập trung vào các hành vi gây ra hầu hết các lỗi xác thực: thay đổi không kiểm soát, khả năng truy vết yếu và bỏ qua các biện pháp kiểm soát bằng chứng.

Nếu danh sách kiểm tra này thất bại, hãy coi đó là một thất bại về quản trị. Xác thực là một biện pháp kiểm soát. Các biện pháp kiểm soát không hoạt động như mong muốn là các vấn đề về chất lượng.

16) Các kiểu lỗi thường gặp

• Kiểm tra giao diện người dùng thay vì các nút điều khiển: Hàng trăm lần kiểm tra màn hình, nhưng không có nhật ký kiểm toán hoặc kiểm tra vai trò.
• URS được ghi sau khi cấu hình: Các yêu cầu trở thành tài liệu biện minh, chứ không phải là cơ sở ban đầu.
• Bằng chứng từ nhà cung cấp bị bỏ qua: Các nhóm kiểm tra lại các chức năng có rủi ro thấp và hết thời gian để kiểm tra các chức năng có rủi ro cao.
• Bằng chứng từ nhà cung cấp được tôn sùng: Các nhóm chấp nhận việc thử nghiệm từ nhà cung cấp mà không cần xác minh mục đích sử dụng và cấu hình dự định.
• Quy trình kiểm soát thay đổi còn yếu kém: Những "điều chỉnh nhỏ" tích lũy dần cho đến khi tiêu chuẩn cơ bản được xác nhận trở nên phi thực tế.
• Giao diện được coi như hệ thống đường ống dẫn nước của CNTT: Các lỗi tích hợp làm hỏng dữ liệu và quá trình đối chiếu.
• Việc nghỉ hưu không được quản lý: Hệ thống bị tắt và quyền truy cập hồ sơ biến mất.

17) Ví dụ từ nhiều ngành khác nhau

GAMP 5 được sử dụng ở bất cứ nơi nào phần mềm đóng góp vào bằng chứng được quy định. Chi tiết có thể khác nhau, nhưng mục đích kiểm soát là nhất quán: chứng minh mục đích sử dụng và bảo vệ tính toàn vẹn của hồ sơ.

• Sản xuất dược phẩm: Hệ thống MES/EBR và hệ thống phòng thí nghiệm phải lưu giữ nhật ký kiểm toán và bằng chứng công bố; quá trình xác thực phải chịu được sự thay đổi thường xuyên và các cuộc điều tra (xem GMP và ICH Q10 định nghĩa bài văn).
• Các thiết bị y tế: Các hệ thống sản xuất và chất lượng hỗ trợ khả năng truy xuất nguồn gốc xuyên suốt vòng đời của các sản phẩm, chẳng hạn như... DMR và DHR; những thay đổi giao nhau với SXHD và các biện pháp kiểm soát hệ thống chất lượng như ISO 13485 Sự phù hợp giữa các quy trình và quản lý rủi ro.
• Thực phẩm và sản phẩm tiêu dùng: Các hoạt động quy mô lớn cần thay đổi nhanh chóng; xác thực dựa trên rủi ro ngăn chặn "tốc độ" biến thành sự trôi dạt không kiểm soát (xem HACCP (Tư duy theo phong cách khi thích hợp).
• Các nhà máy có mức độ tự động hóa cao: Các lớp tích hợp và logic thực thi phải được xác thực như một phần của mục đích sử dụng dự định, chứ không phải là một suy nghĩ sau đó; điều đó bao gồm cả luồng dữ liệu thúc đẩy các quyết định và trạng thái giữ/giải phóng.

Bài học chung: Một hệ thống đã được kiểm định chỉ đáng tin cậy khi các biện pháp kiểm soát xung quanh nó cũng đáng tin cậy—đặc biệt là kiểm soát thay đổi và tính toàn vẹn của bằng chứng.

18) Câu hỏi thường gặp mở rộng

Câu 1. GAMP 5 là gì?
GAMP 5 là một khuôn khổ dựa trên rủi ro để xác thực các hệ thống máy tính trong suốt vòng đời của chúng, thường được sử dụng để thực hiện... CSV một cách hiệu quả và có thể bảo vệ được.

Câu 2. GAMP 5 có phải là một quy định không?
Không. Đó là hướng dẫn của ngành. Các cơ quan quản lý mong muốn các hệ thống được xác thực; GAMP 5 là một phương pháp thực tiễn mà nhiều tổ chức sử dụng để đáp ứng những kỳ vọng đó với sự chặt chẽ dựa trên rủi ro.

Câu 3. Thuật ngữ “dựa trên rủi ro” trong thẩm định có nghĩa là gì?
Điều đó có nghĩa là bạn tập trung vào việc lập đặc tả kỹ thuật và thử nghiệm các chức năng mà sự cố của chúng có thể gây hại đến chất lượng sản phẩm, sự an toàn của bệnh nhân/khách hàng hoặc tính toàn vẹn của hồ sơ. Các chức năng rủi ro thấp sẽ được kiểm tra và đánh giá sơ bộ hơn; các chức năng rủi ro cao sẽ được kiểm tra và xem xét kỹ lưỡng hơn.

Câu 4. Chúng ta có cần kiểm tra mọi tính năng không?
Không. Bạn cần kiểm tra xem điều gì hỗ trợ mục đích sử dụng dự định và điều gì bảo vệ bằng chứng. Việc kiểm tra quá mức các tính năng rủi ro thấp thường khiến các nhóm kiểm tra không đầy đủ các đường dẫn điều khiển thực tế.

Câu 5. Chúng ta có thể dựa vào việc kiểm thử của nhà cung cấp không?
Bạn có thể tận dụng bằng chứng từ nhà cung cấp, nhưng bạn vẫn phải xác minh mục đích sử dụng, cấu hình và các biện pháp kiểm soát rủi ro của mình—đặc biệt là về nhật ký kiểm toán, bảo mật và giao diện.

Câu 6. GAMP 5 có liên quan như thế nào đến Phần 11 và Phụ lục 11?
GAMP 5 là một phương pháp xác thực; Phần 11 và Phụ lục 11 Những kỳ vọng về hồ sơ điện tử là rất quan trọng. Một cách tiếp cận GAMP 5 hiệu quả bao gồm việc xác minh nhật ký kiểm toán, kiểm soát truy cập, chữ ký điện tử và thời gian lưu trữ hồ sơ để bảo vệ niềm tin vào bằng chứng điện tử.

Câu 7. Lỗi thường gặp nhất trong GAMP 5 là gì?
Coi việc xác thực như một tập hợp tài liệu thay vì một biện pháp kiểm soát. Nếu việc kiểm soát thay đổi yếu kém, cấu hình thay đổi liên tục và các biện pháp kiểm soát bằng chứng không được kiểm tra, thì "trạng thái đã được xác thực" sẽ trở thành hư cấu.

Đọc liên quan
• Lõi xác thực: CSV | VMP | URS | IQ | OQ | UAT
• Quản trị: Thay đổi kiểm soát | Bộ Xây dựng | Kiểm soát tài liệu | Kiểm soát sửa đổi
• Tính chính trực + Bằng chứng: Toàn vẹn dữ liệu | ALCOA | Nhật ký kiểm toán (GxP) | Chữ ký điện tử
• Bối cảnh hồ sơ điện tử: 21 CFR Phần 11 | Phụ lục 11 | Quy tắc vị ngữ
• Bối cảnh hệ thống: MES | EBR | LIMS | eQMS