PMS Việt Nam – Máy đếm tiểu phân & phòng sạch GMP | Sao Nam
Ma trận truy xuất yêu cầu cho thẩm định FMS: nối yêu cầu với bằng chứng
-
Hãng sản xuất: Model: Document: -
Liên hệ
Ma trận truy xuất yêu cầu cho hệ giám sát môi trường FMS theo EU GMP Annex 11
Ma trận truy xuất yêu cầu (Requirements Traceability Matrix – RTM) là bảng nối từng yêu cầu người dùng của hệ giám sát môi trường (Facility Monitoring System – FMS) với rủi ro, biện pháp kiểm soát, phép thử và bằng chứng đã thực hiện. QA dùng ma trận này để trả lời nhanh ba câu hỏi: yêu cầu nào đã được chứng minh, bằng chứng nằm ở đâu, và ngoại lệ nào chưa đóng.
Giá trị của ma trận nằm ở các liên kết truy xuất được, không nằm ở số trang hồ sơ.
Hotline/Zalo: 0903 938 641 Liên hệ tư vấnĐiểm quan trọng cần hiểu
- Annex 11 (bản 2011) mục 4.4 yêu cầu đặc tả yêu cầu người dùng (URS) dựa trên đánh giá rủi ro, và yêu cầu phải truy xuất được suốt vòng đời hệ thống. Annex 11 không quy định một mẫu ma trận cụ thể; ma trận là cách làm phổ biến để chứng minh khả năng truy xuất đó.
- Mỗi dòng ma trận phải dẫn đến bằng chứng đã thực hiện, không dừng ở kế hoạch thử.
- Một dấu "Đạt" chung không thay được kết luận cho từng yêu cầu.
- Ma trận chỉ còn giá trị khi được cập nhật qua kiểm soát thay đổi và đánh giá định kỳ sau khi đưa hệ thống vào sử dụng.
URS
Đặc tả yêu cầu người dùng: hệ thống phải làm gì, trong điều kiện nào.
Rủi ro
Điều gì xảy ra với dữ liệu GMP nếu yêu cầu không được đáp ứng.
Phép thử
Kịch bản có tiêu chí chấp nhận rõ, gồm cả tình huống lỗi.
Bằng chứng
Biên bản đã ký, có phiên bản, tìm và đọc được khi thanh tra.
Căn cứ quy định và phạm vi áp dụng
FMS là hệ thống máy tính hóa (computerised system) tạo ra dữ liệu GMP, nên thuộc phạm vi EU GMP Annex 11. Ngoài mục 4.4 về URS và truy xuất yêu cầu, các mục sau ảnh hưởng trực tiếp đến nội dung ma trận:
| Mục Annex 11 (2011) | Nội dung tóm lược | Ý nghĩa với ma trận FMS |
|---|---|---|
| 1 – Quản lý rủi ro | Phạm vi thẩm định và kiểm soát toàn vẹn dữ liệu dựa trên đánh giá rủi ro có tài liệu. | Mỗi yêu cầu cần mức rủi ro để biện minh độ sâu của phép thử. |
| 4.4 – URS | URS mô tả chức năng cần có, dựa trên rủi ro và tác động GMP; yêu cầu phải truy xuất được suốt vòng đời. | Gốc của mọi dòng ma trận; mỗi yêu cầu cần mã riêng. |
| 4.7 – Phương pháp thử | Phải chứng minh phương pháp và kịch bản thử phù hợp, xét giới hạn thông số, giới hạn dữ liệu và xử lý lỗi. | Ma trận cần có phép thử tình huống lỗi, không chỉ phép thử chức năng bình thường. |
| 7 – Lưu trữ dữ liệu | Sao lưu định kỳ; khả năng khôi phục được kiểm tra khi thẩm định và theo dõi định kỳ. | Yêu cầu backup/restore phải dẫn đến biên bản khôi phục thực tế. |
| 9 – Audit trail | Dựa trên rủi ro, hệ thống ghi lại thay đổi/xóa dữ liệu GMP kèm lý do; audit trail được xem xét định kỳ. | Cần phép thử tạo – sửa – xóa và kiểm tra bản ghi audit trail tương ứng. |
| 10, 11 – Thay đổi và đánh giá định kỳ | Thay đổi phải theo quy trình; hệ thống được đánh giá định kỳ để xác nhận vẫn ở trạng thái thẩm định. | Ma trận được rà lại sau mỗi thay đổi và trong mỗi kỳ đánh giá. |
Lưu ý phiên bản: Ủy ban châu Âu và PIC/S đã công bố dự thảo sửa đổi Annex 11 để tham vấn vào ngày 7/7/2025. Tại thời điểm rà soát bài này (10/2026), bản 2011 vẫn là bản đang áp dụng. Cần kiểm tra trang EudraLex Volume 4 trước khi trích dẫn số mục trong hồ sơ, vì cấu trúc mục của bản mới khác bản 2011.
Bước 1: Tách yêu cầu thành điều kiện kiểm tra được
Vấn đề
Nhiều URS viết theo kiểu mong muốn chung như "hệ thống phải ổn định" hoặc "dữ liệu phải an toàn". Những câu này không thể thử, nên dòng ma trận tương ứng chỉ có thể đánh "Đạt" theo cảm tính.
Cách áp dụng
Viết lại mỗi yêu cầu thành tình huống cụ thể: điều kiện xảy ra, kết quả mong đợi, cách nhận biết và người xử lý. Gán mã riêng cho từng yêu cầu và ghi rõ ranh giới giữa cảm biến, bộ xử lý, mạng, máy chủ, phần mềm và thao tác người dùng. Mỗi yêu cầu chỉ nên chứa một điều cần chứng minh.
| Cách viết mơ hồ | Cách viết kiểm tra được (ví dụ minh họa) |
|---|---|
| Hệ thống phải ổn định. | Khi mất kết nối mạng giữa bộ xử lý và máy chủ trong khoảng thời gian do cơ sở xác định, dữ liệu đếm hạt vẫn được giữ lại và chuyển về máy chủ sau khi kết nối phục hồi; khoảng mất kết nối được ghi thành sự kiện. |
| Có cảnh báo khi vượt giới hạn. | Khi số đếm tại một điểm vượt giới hạn hành động đã cấu hình, hệ thống tạo alarm trên màn hình, ghi sự kiện có thời gian, điểm đo, giá trị, và chỉ người dùng có quyền được xác nhận alarm kèm lý do. |
| Dữ liệu được bảo vệ. | Người dùng vai trò "vận hành" không sửa được giới hạn cảnh báo; mọi thay đổi giới hạn bởi quản trị viên tạo bản ghi audit trail có giá trị cũ, giá trị mới, người thực hiện, thời gian và lý do. |
Giới hạn kết luận: các giá trị như thời gian mất kết nối cho phép hay thời gian lưu đệm phải lấy từ tài liệu đúng phiên bản của hãng và quyết định của cơ sở, không lấy từ ví dụ trong bài. Đọc thêm về cách chốt URS và kịch bản nghiệm thu trong bài FacilityPro: tổ chức dữ liệu giám sát phòng sạch và yêu cầu nghiệm thu.
Bước 2: Nối rủi ro, biện pháp kiểm soát và phép thử
Một dòng ma trận tối thiểu nên có: mã yêu cầu, nguy cơ, biện pháp kiểm soát, mã phép thử, vị trí bằng chứng và trạng thái. Biện pháp kiểm soát có thể là chức năng phần mềm, cấu hình, hoặc thủ tục (SOP). Ghi rõ loại biện pháp để người rà soát biết cần loại bằng chứng nào.
Bảng dưới là ví dụ minh họa cấu trúc, không phải ma trận của một nhà máy thật.
| Mã YC | Yêu cầu | Nguy cơ | Biện pháp | Phép thử | Bằng chứng | Trạng thái |
|---|---|---|---|---|---|---|
| URS-012 | Giữ dữ liệu khi mất mạng | Khoảng trống dữ liệu Grade A | Chức năng lưu đệm tại bộ xử lý | OQ-07 | Biên bản OQ-07 rev.1, trang 4–6 | Đạt sau thử lại (DEV-03) |
| URS-018 | Audit trail khi sửa giới hạn | Thay đổi không truy được người thực hiện | Audit trail hệ thống + phân quyền | OQ-11 | Biên bản OQ-11, bản in audit trail | Đạt |
| URS-021 | Khôi phục từ bản sao lưu | Mất dữ liệu lịch sử | Quy trình backup + SOP khôi phục | OQ-14 | Chưa có biên bản thực hiện | Mở |
| URS-030 | Cảm biến còn hạn hiệu chuẩn | Số đếm không tin cậy | Chương trình hiệu chuẩn (thủ tục) | IQ-05 | Danh sách serial + chứng chỉ hiệu chuẩn | Đạt |
Nếu một phép thử phục vụ nhiều yêu cầu, biên bản phải mô tả kết quả nào chứng minh yêu cầu nào. Với yêu cầu về audit trail, nên thử cả ở cấp phần mềm FMS và ở thiết bị di động dùng song song; tham khảo hướng dẫn chức năng Audit Trail trên máy đếm tiểu phân Lasair Pro để biết các loại sự kiện thiết bị ghi lại. Với dòng hiệu chuẩn, bằng chứng thường là chứng chỉ theo từng số serial từ dịch vụ hiệu chuẩn thiết bị PMS hoặc đơn vị hiệu chuẩn mà cơ sở đã đánh giá.
Bước 3: Phân định bằng chứng của nhà cung cấp và của cơ sở
Annex 11 mục 3.3 yêu cầu người dùng xem xét tài liệu đi kèm sản phẩm thương mại có sẵn để kiểm tra yêu cầu người dùng được đáp ứng. Nghĩa là tài liệu của hãng có thể được dẫn trong ma trận, nhưng cơ sở vẫn phải kết luận nó có đủ cho yêu cầu cụ thể của mình hay không.
| Lớp hệ thống | Bằng chứng có thể từ hãng/nhà cung cấp | Bằng chứng cơ sở thường phải tự tạo |
|---|---|---|
| Cảm biến tiểu phân, vi sinh | Datasheet, chứng chỉ hiệu chuẩn, protocol IQ/OQ mẫu | Vị trí lắp đặt, cấu hình điểm đo, kết quả thực hiện tại chỗ |
| Bộ xử lý và mạng | Mô tả kiến trúc, chức năng lưu đệm theo tài liệu hãng | Sơ đồ mạng thực tế, phép thử mất kết nối trên hạ tầng của cơ sở |
| Phần mềm FMS | Tài liệu chức năng, thông tin phát hành phiên bản | Cấu hình vai trò người dùng, giới hạn cảnh báo, mẫu báo cáo, phép thử audit trail |
| Máy chủ, sao lưu | Khuyến nghị cấu hình | Biên bản khôi phục thực tế, SOP sao lưu, phân công IT |
| Thao tác người dùng | Tài liệu đào tạo | SOP, hồ sơ đào tạo, rà soát audit trail định kỳ |
Với hệ dùng phần mềm FacilityPro Pharmaceutical Net Pro 7.0.0, phạm vi chức năng thực tế phụ thuộc phiên bản, gói đăng ký và cấu hình dự án. Ma trận nên ghi rõ phiên bản phần mềm đã thử để tránh dùng bằng chứng của phiên bản cũ cho phiên bản mới.
Bước 4: Đóng khoảng trống trước khi phê duyệt
Annex 11 mục 4.2 yêu cầu hồ sơ thẩm định gồm cả báo cáo sai lệch phát sinh trong quá trình thẩm định. Vì vậy, một dòng ma trận có sai lệch phải dẫn tiếp đến điều tra, sửa đổi và kết quả thử lại, không được xóa dấu vết lần thử thất bại.
Tình huống vận hành (ví dụ giả định)
Trong OQ, nhóm thẩm định ngắt mạng giữa bộ xử lý và máy chủ. Sau khi kết nối phục hồi, dữ liệu của một điểm đo không được chuyển đầy đủ. Kết quả lần đầu là Không đạt.
- Mở sai lệch DEV-03, liên kết vào dòng URS-012.
- Điều tra nguyên nhân (ví dụ: cấu hình đồng bộ thời gian trên bộ xử lý chưa đúng).
- Sửa cấu hình qua kiểm soát thay đổi, ghi phiên bản cấu hình mới.
- Thử lại OQ-07 rev.1 và đính kèm cả hai biên bản.
- Cập nhật trạng thái dòng URS-012: "Đạt sau thử lại", dẫn chiếu DEV-03.
Nếu cơ sở quyết định phê duyệt hệ thống khi vẫn còn dòng "Mở", quyết định đó cần đánh giá rủi ro, biện pháp tạm thời và thời hạn đóng, do người có thẩm quyền trong hệ thống chất lượng ký duyệt.
Bước 5: Giữ ma trận "sống" sau khi đưa vào sử dụng
Truy xuất "suốt vòng đời" có nghĩa ma trận phải được rà lại mỗi khi hệ thống thay đổi. Các thay đổi thường gặp với FMS:
- Thêm hoặc dời cảm biến: rà các dòng về điểm đo, cảnh báo và báo cáo. Quy trình đánh giá thiết bị mới trước khi đưa vào khu vực sạch được trình bày trong bài đưa thiết bị giám sát mới vào phòng sạch dược GMP.
- Sửa mẫu báo cáo hoặc giới hạn cảnh báo: rà các dòng về báo cáo lô, phân quyền và audit trail.
- Nâng cấp phần mềm hoặc thay hệ: Annex 11 mục 4.8 yêu cầu kiểm tra dữ liệu không bị thay đổi giá trị hoặc ý nghĩa khi chuyển sang định dạng hay hệ thống khác. Xem thêm kinh nghiệm di trú dữ liệu lịch sử khi thay hệ phần mềm giám sát môi trường.
- Đánh giá định kỳ: đối chiếu ma trận với hồ sơ sai lệch, sự cố, lịch sử nâng cấp và báo cáo trạng thái thẩm định.
Bảng kiểm trước khi kết luận ma trận
| Câu hỏi kiểm tra | Dấu hiệu chưa đạt |
|---|---|
| Mỗi yêu cầu có mã riêng và phiên bản URS rõ ràng? | Yêu cầu gộp nhiều ý; không biết đang dùng URS phiên bản nào. |
| Mỗi yêu cầu có ít nhất một bằng chứng đã thực hiện? | Cột bằng chứng chỉ ghi tên protocol, chưa có biên bản đã ký. |
| Có phép thử tình huống lỗi (mất mạng, mất nguồn, sai quyền)? | Chỉ có phép thử chức năng trong điều kiện bình thường. |
| Sai lệch và lần thử lại được liên kết trước kết luận? | Biên bản thất bại bị thay bằng biên bản đạt, không có dẫn chiếu. |
| Bằng chứng có thể tìm và đọc trong vài phút khi thanh tra? | Vị trí ghi chung chung như "hồ sơ thẩm định". |
| Có quy định khi nào phải rà lại ma trận? | Ma trận chỉ tồn tại ở thời điểm phê duyệt ban đầu. |
Những lỗi dễ gặp và cách tránh
- Dùng một dấu "Đạt" cho cả nhóm yêu cầu: tách kết luận theo từng mã yêu cầu.
- Coi SOP là bằng chứng cho chức năng phần mềm: SOP chỉ chứng minh biện pháp thủ tục; chức năng phần mềm cần kết quả thử.
- Dẫn chiếu tài liệu hãng mà không đánh giá: ghi rõ cơ sở đã xem xét tài liệu nào và kết luận gì.
- Bỏ quên lớp hạ tầng: mạng, đồng bộ thời gian và sao lưu thường là nơi phát sinh khoảng trống dữ liệu.
- Không cập nhật sau thay đổi: gắn việc rà ma trận vào biểu mẫu kiểm soát thay đổi.
Các nguyên tắc kiểm soát người dùng, audit trail và sao lưu được tổng hợp thêm trong trang giải pháp PMS về tính toàn vẹn dữ liệu (Data Integrity).
Thiết bị và phần mềm PMS hỗ trợ gì, không thay thế gì
Hỗ trợ: thiết bị và phần mềm PMS cung cấp các chức năng (như audit trail, phân quyền, cảnh báo, lưu đệm dữ liệu tùy kiến trúc) và tài liệu kỹ thuật để cơ sở dùng làm đầu vào cho URS và phép thử.
Không thay thế: việc lập URS, đánh giá rủi ro, thực hiện thẩm định, phê duyệt ma trận và quyết định đưa hệ thống vào sử dụng. Những việc này thuộc hệ thống quản lý chất lượng của cơ sở. Một tính năng hãng công bố không tự động đồng nghĩa với việc mọi cấu hình đã được thẩm định.
Câu hỏi thường gặp
Annex 11 có bắt buộc phải có ma trận truy xuất không?
Annex 11 bản 2011 yêu cầu yêu cầu người dùng phải truy xuất được suốt vòng đời, nhưng không quy định hình thức. Ma trận là cách phổ biến và dễ kiểm tra nhất để chứng minh điều đó.
Một SOP có thể làm bằng chứng không?
Có, khi biện pháp kiểm soát của yêu cầu đó là thủ tục. SOP không thay kết quả thử khi yêu cầu cần chứng minh chức năng phần mềm, ví dụ audit trail hay phân quyền.
Một phép thử có thể dùng cho nhiều yêu cầu không?
Có, nếu biên bản ghi rõ bước và kết quả nào chứng minh yêu cầu nào. Tránh dẫn chiếu cả biên bản dài cho một yêu cầu nhỏ mà không chỉ ra trang hoặc bước cụ thể.
Có được phê duyệt hệ thống khi ma trận còn dòng "Mở"?
Chỉ khi có đánh giá rủi ro, biện pháp tạm thời, thời hạn đóng và phê duyệt của người có thẩm quyền theo hệ thống chất lượng của cơ sở.
Khi nào cần rà lại ma trận?
Sau mỗi thay đổi qua kiểm soát thay đổi (thêm cảm biến, sửa báo cáo, nâng cấp phần mềm, đổi hạ tầng) và trong mỗi kỳ đánh giá định kỳ hệ thống.
Tài liệu IQ/OQ của hãng có thay được ma trận của nhà máy không?
Không. Tài liệu của hãng là đầu vào hữu ích, nhưng URS, cấu hình và rủi ro là của từng cơ sở, nên ma trận phải phản ánh yêu cầu và bằng chứng của chính cơ sở đó.
Cần trao đổi phạm vi hỗ trợ cho hệ FMS của nhà máy?
Chuẩn bị mô tả hệ thống, danh sách yêu cầu và những chức năng khó nghiệm thu, rồi gửi cho SAO NAM – Authorized Sales and Service Center for PMS tại Việt Nam. Quyết định chất lượng và phê duyệt sử dụng thuộc hệ thống quản lý của cơ sở.
Gọi/Zalo: 0903 938 641 Liên hệ tư vấnEmail: info@saonamchem.com · Website: saonamchem.com
Nguồn đối chiếu
- European Commission – EudraLex Volume 4, Annex 11: Computerised Systems (revision 1, hiệu lực 30/6/2011) – các mục 1, 3.3, 4.2, 4.4, 4.7, 4.8, 7, 9, 10, 11.
- Particle Measuring Systems – FacilityPro cleanroom software for pharmaceuticals – mô tả sản phẩm của hãng.
- Dự thảo sửa đổi EU GMP Annex 11 (EC/PIC/S, công bố tham vấn 7/7/2025) – cần kiểm tra trạng thái ban hành trên trang EudraLex Volume 4 trước khi trích dẫn.
Các liên kết saonamchem.com trong bài là nguồn đọc thêm về giải pháp và ứng dụng, không dùng thay cho căn cứ quy phạm.
Technical Overview: Requirements Traceability Matrix for Pharmaceutical Facility Monitoring Systems
A requirements traceability matrix (RTM) links each user requirement of a facility monitoring system (FMS) to its risk, control measure, test case, executed evidence and current status. EU GMP Annex 11 (revision 1, 2011), clause 4.4, expects User Requirements Specifications to be risk-based and requirements to remain traceable throughout the life-cycle. Annex 11 does not prescribe a matrix format; the RTM is the common industry way to demonstrate that traceability.
Write testable requirements. Replace statements such as "the system shall be stable" with defined conditions and outcomes, for example retention of particle data during a network outage and recording of the outage as an event. Assign a unique ID to each requirement and define boundaries between sensors, processors, network, server, software and user actions.
Connect risk, control and test. Annex 11 clause 4.7 asks for appropriate test scenarios covering parameter limits, data limits and error handling. Each row should point to executed, signed evidence rather than a test plan. When one test covers several requirements, the record should show which result supports which requirement. Procedural controls (SOPs) can support procedural requirements but do not replace functional testing of software features such as audit trail (clause 9) or backup and restore (clause 7.2).
Separate supplier and site evidence. Under clause 3.3, documentation supplied with commercial products should be reviewed by the regulated user against its own requirements. Supplier datasheets, calibration certificates and IQ/OQ templates are useful inputs, but site configuration, network behaviour and restore tests must be evidenced locally. Record the exact software version tested.
Close gaps before approval and keep the matrix alive. Deviations observed during validation belong in the validation record (clause 4.2), so failed tests should remain linked to investigation, correction and retest. After go-live, the matrix should be reviewed through change control (clause 10), data migration checks (clause 4.8) and periodic evaluation (clause 11), for example when sensors are added, reports are modified or software is upgraded.
Regulatory status. A revised draft of Annex 11 was released for consultation by the European Commission and PIC/S on 7 July 2025. At the time of this review (October 2026), the 2011 text remains the version in force; verify the current EudraLex Volume 4 publication before citing clause numbers.
PMS instruments and software provide functions and documentation that feed into the URS and test design, but they do not replace the site's URS, risk assessment, validation execution or quality approval. SAO NAM – Authorized Sales and Service Center for PMS in Vietnam supports FMS scope discussions, calibration and qualification support. Contact: +84 903 938 641 · info@saonamchem.com · saonamchem.com/lien-he.
Rà soát ngày 15/10/2026. Bảng ma trận và tình huống trong bài là ví dụ minh họa, không phản ánh hồ sơ của một cơ sở cụ thể. Phạm vi, tiêu chí và tần suất áp dụng cần đối chiếu tài liệu đúng phiên bản, URS, kế hoạch thẩm định và quy trình đã phê duyệt tại cơ sở.
- Cam kết chất lượng
- Bảo hành chính hãng
- Giao hàng tận nơi
- DỊCH VỤ 24/7
Có thể bạn thích
-
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng -
Liên hệThêm vào giỏ hàng
.png)
