Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.





Abstract

Thành công của bất kỳ nghiên cứu lâm sàng nào cũng phụ thuộc vào chất lượng và tính toàn vẹn của cơ sở dữ liệu cuối cùng. validation hệ thống phần mềm và cơ sở dữ liệu được sử dụng cho nghiên cứu là các quy trình chất lượng quan trọng nhằm đảm bảo chất lượng và tính toàn vẹn. Chương này thảo luận các nguyên tắc và loại validation, cũng như các rủi ro validation chung. Mặc dù thảo luận về vấn đề validation hệ thống, nhưng trọng tâm chính của chương này là việc validation cụ thể về nghiên cứu, có tác động trực tiếp hơn đến các nhà quản lý dữ liệu lâm sàng.

Introduction

Hệ thống quản lý dữ liệu lâm sàng (CDMS) dùng để tiến hành nghiên cứu lâm sàng "... nên được thiết kế để ... ngăn ngừa sai sót trong việc tạo, sửa đổi, bảo trì, lưu trữ, truy xuất hoặc truyền tải dữ liệu ..." Theo yêu cầu của 21 CFR Part 11 và (các) quy tắc có thể áp dụng cho thuốc, thiết bị hoặc sinh học đang phát triển, tài liệu kỹ thuật phải có ở tất cả các cấp của việc thu thập và quản lý dữ liệu lâm sàng. Với các trách nhiệm đa dạng của CDMS, quá trình validation là cần thiết, liên tục và thường phức tạp.

Thuật ngữ "validation" có thể đề cập đến việc validation tính chính xác của CDMS hoặc validation các chương trình liên quan đến sự phát triển cơ sở dữ liệu nghiên cứu hoặc đề cương. Mặc dù cả hai loại validation là rất quan trọng đối với sự thành công của một nghiên cứu, chi tiết về việc validation CDMS có xu hướng là trách nhiệm của các lập trình viên hoặc nhân viên công nghệ thông tin, mặc dù các nhân viên quản lý dữ liệu lâm sàng (CDM) có trách nhiệm xác minh CDMS đã được validation đúng và phù hợp với mục đích đã định.

Scope

Chương này đề cập đến các hoạt động CDM validation cần kèm theo việc cài đặt một CDMS và các bản vá lỗi hoặc các nâng cấp, cũng như việc kiểm tra và validation hợp lệ cần thiết khi thiết kế các cơ sở dữ liệu cụ thể cho nghiên cứu trên hệ thống đó. Mặc dù chương này ngắn gọn thảo luận về validation hợp lệ liên quan đến phát triển ứng dụng phần mềm, nhưng mô tả đầy đủ về validation phát triển phần mềm nằm ngoài phạm vi Good Clinical Data Management Practices. Các biện pháp validation cần thiết cho phát triển phần mềm và thiết kế hệ thống độc quyền là rất khác nhau và phức tạp hơn quá trình validation các ứng dụng cụ thể cho nghiên cứu. Chương này cũng không xác định tính hợp lệ của dữ liệu bên ngoài như dữ liệu trong phòng thí nghiệm. Các đề xuất để validation hợp lệ các dữ liệu này được đề cập trong chương "Laboratory Data Handling."

The software development life cycle (SDLC) validation approach advocated in the device and Good Laboratory Practice regulations is also appropriate for application development. The same general principles offer guidelines on the setup of individual protocols within a validated CDMS, although direct application may not always be appropriate or practical.

Mặc dù một số chủ đề cụ thể được giải quyết bởi chương này có thể không phải là trách nhiệm trực tiếp của nhân viên CDM, CDM phải có nhận thức liên tục về các yêu cầu và đảm bảo các nhiệm vụ này đã được hoàn thành theo các nguyên tắc và tiêu chuẩn của tổ chức, cơ quan quản lý và GCP.

Minimum Standards

  • Tạo ra một kế hoạch validation xác định phương pháp thử, phạm vi, báo cáo vấn đề và độ phân giải, dữ liệu thử nghiệm, tiêu chí chấp nhận và các thành viên của nhóm đánh giá. - Generate a validation plan defining the testing methodology, scope, problem reporting and resolution, test data, acceptance criterion and members of the validation team.
  • Đảm bảo CDMS đáp ứng các yêu cầu của người sử dụng / chức năng và quy định và tiếp tục đáp ứng các yêu cầu này trong quá trình sử dụng. - Ensure the CDMS meets user/functional and regulatory requirements and continues to meet these requirements through the course of its use.
  • Thực hiện CDMS một cách cẩn thận, kiểm tra theo các thông số kỹ thuật, ghi lại tất cả các thử nghiệm và các vấn đề, và đảm bảo các bằng chứng khách quan của thử nghiệm được tạo ra. - Implement the CDMS carefully, testing according to specifications, documenting all testing and issues, and ensuring objective evidence of testing is generated.
  • Xác định các quy trình xử lý các vấn đề kiểm soát thay đổi, với xác định rõ ràng khi nào cần phải thông báo lại do thay đổi. - Define processes for handling change control issues, with a clear determination of when revalidation will be required due to changes.
  • Tài liệu tất cả các chi tiết validation trước khi thực hiện trong một tài liệu tóm tắt (ví dụ: báo cáo validation), bao gồm tất cả các chữ ký duyệt và phê duyệt thích hợp. - Document all validation details prior to implementation in a summary document (e.g., validation report), including all applicable review and approval signatures.
  • Đảm bảo tài liệu còn đầy đủ và hiện tại. - Ensure documentation remains complete and current.
  • Đảm bảo rằng chỉ có nhân viên có trình độ phát triển, duy trì và sử dụng hệ thống. - Ensure that only qualified staff develop, maintain and use the system.
  • Phê duyệt kế hoạch validation và các kết quả được ghi nhận từ một mức độ thích hợp của (các) nguồn chất lượng độc lập. - Approval of validation plan and documented results from an appropriate level of independent quality resource(s).

Best Practices

  • Xác định tất cả các yêu cầu của người sử dụng theo yêu cầu cụ thể của chương trình nghiên cứu. - Identify all intended user requirements of study-specific programming.
  • Sử dụng các tiêu chuẩn tổ chức, nếu có, để chuẩn bị chi tiết chương trinh nghiên cứu. - Use organization standards, as available, to prepare study-specific programming.
  • Sử dụng các tiêu chuẩn tổ chức cho các chương trình tài liệu. - Use organization standards to document programs.
  • Sử dụng thư viện mã khi có thể. - Use code libraries wherever possible.
  • validation rằng ứng dụng lập trình cụ thể dành cho nghiên cứu thực hiện theo dự định dựa trên yêu cầu của người dùng (yêu cầu về kế hoạch quản lý dữ liệu, yêu cầu CRF, đặc tả cơ sở dữ liệu, kiểm tra kiểm tra, kế hoạch validation, vv). - Confirm that study-specific programming applications perform as intended based on the user requirements (data management plan requirements, CRF requirements, database specifications, edit check specifications, validation plan, etc.).
  • Document performance during validation.
  • Đảm bảo tài liệu vẫn đầy đủ và hiện tại để sử dụng trực tiếp và được lập chỉ mục cho việc thu hồi sẵn khi nó được giải phóng hoặc lưu trữ. - Ensure documentation remains complete and current for live use, and is indexed for ready retrieval when it is retired or archived.
  • validation tính chính xác, độ tin cậy, hiệu suất, sự nhất quán trong xử lý và khả năng xác định hồ sơ không hợp lệ hoặc bị thay đổi. validation thông qua kiểm tra và tài liệu. - Confirm accuracy, reliability, performance, consistency of processing and the ability to identify invalid or altered records. Confirm through testing and document.
  • Đảm bảo hệ thống có ma trận truy xuất phù hợp liên kết các trường hợp thử nghiệm với các yêu cầu. - Ensure the system has an appropriate traceability matrix linking test cases to requirements.
  • validation rằng ứng dụng nghiên cứu cụ thể đã được cấu hình đúng. - Confirm that the study-specific application has been configured properly.

Validation

"Validation" là một thuật ngữ được áp dụng cho các quy trình khác nhau và đôi khi bị lạm dụng hoặc sử dụng trong một ngữ cảnh có thể không phải lúc nào cũng rõ ràng. Ngay cả khi thuật ngữ "validation" được sử dụng rõ ràng và chính xác, vẫn có sự phân biệt rõ ràng giữa validation các hệ thống, quy trình và bối cảnh khác nhau. Các mô tả sau đây phân biệt giữa các loại validation khác nhau và các quy trình liên quan đến validation.

  • Validation versus user acceptance testing (UAT) - In Guidance for Industry: Computerized Systems Used in Clinical Investigations: FDA đã xác định xác nhận phần mềm là "Xác nhận bằng cách kiểm tra và cung cấp bằng chứng khách quan rằng các đặc tả phần mềm phù hợp với nhu cầu của người sử dụng và mục đích sử dụng và các yêu cầu cụ thể được thực hiện thông qua phần mềm có thể được thực hiện đầy đủ" UAT là một phần của cuộc kiểm tra và kết quả UAT cho thấy là một thành phần của "bằng chứng khách quan" hỗ trợ quá trình xác nhận. UAT được thực hiện bởi người dùng cơ sở dữ liệu hoặc CDMS và nên kiểm tra cả kết quả false positive và false negative trong tất cả các lĩnh vực và chức năng. UAT không phải là sự xác nhận bởi chính nó; Các yếu tố xác nhận khác bao gồm, nhưng không giới hạn, kế hoạch xác nhận, các yêu cầu kỹ thuật, ma trận truy xuất nguồn gốc, bản tóm tắt UAT và bản tóm lược xác nhận.
  • Core CDMS validation - Người dùng cuối CDMS phải xác nhận rằng hệ thống đã được xác nhận hợp lệ trước khi phát hành để sử dụng (ví dụ: tạo các nghiên cứu riêng lẻ). Sự xác nhận này được tiến hành sử dụng phương pháp luận SDLC và thường là sự hợp tác giữa CNTT, đảm bảo chất lượng (QA) và người sử dụng cuối cùng. Chức năng hệ thống mong muốn sẽ được xác định trong một tài liệu đặc tả yêu cầu hệ thống (SRS) mô tả các quy trình tiếp theo và thử nghiệm thực hiện để đảm bảo sản phẩm cài đặt theo cách mà nhà sản xuất dự định (đôi khi được gọi là chứng chỉ lắp đặt hoặc IQ). Hệ thống được thiết kế theo Thông số kỹ thuật thiết kế của nhà sản xuất (đôi khi được gọi là tiêu chuẩn hoạt động hoặc OQ) và hệ thống hoạt động theo các yêu cầu đã nêu và việc sử dụng theo mục đích của hệ thống (đôi khi được gọi là chứng chỉ trình độ hoặc PQ). Những người sử dụng hệ thống sơ cấp cần xem lại các kết quả của cuộc kiểm tra này để xác định xem thử nghiệm đã chứng minh đầy đủ tính hợp lệ của hệ thống hay không. Các mô tả về các loại chứng nhận CDMS phổ biến hơn được cung cấp dưới đây: 
    • Commercial off-the-shelf (COTS) products - Hầu hết các nhà phát triển phần mềm không trực tiếp chịu trách nhiệm tuân thủ các cơ quan quản lý, để lại nhà tài trợ với trách nhiệm cuối cùng cho sự tuân thủ này. Người dùng cuối nên điều tra và đảm bảo rằng nhà cung cấp phần mềm đã phát triển và duy trì CDMS sử dụng phương pháp SDLC, bao gồm kiểm tra mức thiết kế. Sự đảm bảo này thường có thể được cung cấp bằng cách tiến hành kiểm toán sự xác nhận mức độ phát triển và cấp phát của nhà cung cấp phần mềm.
    • Internally developed CDMS validation - Sự khác biệt cơ bản cho CDMS phát triển nội bộ là nhân viên nội bộ chịu trách nhiệm phát triển và duy trì CDMS. Những nhân viên phát triển CDMS nên theo phương pháp SDLC và được tổ chức theo các tiêu chuẩn giống như bất kỳ nhà cung cấp nào cung cấp CDMS. Người dùng cuối nên thực hiện cùng một hoạt động UAT và xác nhận được mô tả trong chương này.
    • Prospective CDMS validation - Theo FDA, "Xác nhận triển vọng được tiến hành trước khi sản phẩm mới được phát hành để phân phối hoặc, nếu những sửa đổi có thể ảnh hưởng đến đặc tính của sản phẩm, trước khi một sản phẩm được sản xuất theo một quy trình sản xuất sửa đổi được phát hành để phân phối." Đây là loại CDMS Xác nhận thực hiện thường xuyên nhất.
    • Retrospective CDMS validation - Theo FDA, "Xác nhận hồi cứu là xác nhận của một quá trình dựa trên việc sản xuất, kiểm tra, kiểm soát và các thông tin khác đã tích luỹ cho một sản phẩm đã có trong sản xuất và phân phối. This type of validation makes use of historical data and information which may be found in batch records, production log books, lot records, control charts, test and inspection results, customer complaints or lack of complaints, field failure reports, service reports, and audit reports. Historical data must contain enough information to provide an in- depth picture of how the process has been operating and whether the product has consistently met its specifications. Retrospective validation may not be feasible if all the appropriate data was not collected, or appropriate data was not collected in a manner which allows adequate analysis.” Any time a CDMS must be validated while in active use, validation will be more difficult and the validation plan will be more detailed than expected for prospective validation.
    • Legacy CDMS validation - Mặc dù không có định nghĩa được chấp nhận chính thức cho một hệ thống kế thừa nhưng thuật ngữ này thường được sử dụng để chỉ một CDMS hiện đang hoạt động nhưng không tuân thủ các quy định hiện hành. Một số có thể xem xét một hệ thống kế thừa đã hoạt động trước khi phát hành 21 CFR Part 11. Bước đầu tiên để xác nhận một hệ thống kế thừa là đánh giá chi tiết các rủi ro và khoảng cách giữa hệ thống và các quy định hiện hành. Sau khi tiến hành đánh giá này, nhân viên CDM có thể tìm thấy giải pháp tốt nhất là chuyển sang một CDMS khác. Nếu quyết định được đưa ra để xác nhận tính hợp lệ của hệ thống kế thừa thì việc xác nhận hợp lệ phải tuân thủ các quy trình và thủ tục tương tự như việc xác nhận hồi tố.
    • Validation of an externally hosted CDMS - Mặc dù rất giống với việc xác nhận một CDMS thương mại, việc xác nhận một CDMS lưu trữ bên ngoài khác với các tài liệu của nhà cung cấp cũng bao gồm các thông tin liên quan đến chứng nhận cơ sở hạ tầng, mạng lưới, bảo trì của máy chủ và các biện pháp an ninh hợp lý / vật lý.
  • Study-specific validation - Sau khi một CDMS được xác nhận, cần phải thực hiện xác nhận cụ thể cho nghiên cứu để chứng minh rằng các yêu cầu cho việc thực hiện một nghiên cứu nhất định sử dụng CDMS đã được xây dựng, thử nghiệm và ghi thành công. FDA tuyên bố rằng "đề cương nên xác định từng bước mà hệ thống máy tính sẽ được sử dụng để tạo ra, sửa đổi, duy trì, lưu trữ, truy xuất hoặc chuyển dữ liệu nguồn". Các quy trình liên quan đến việc xác nhận cụ thể về nghiên cứu sẽ được thảo luận nhiều hơn Chi tiết sau trong chương này.

Important of Validation to CDM

CDM đóng một vai trò quan trọng trong việc cung cấp cơ sở dữ liệu có chất lượng cao đáp ứng được cả các yêu cầu về lâm sàng và quy định. Vì các dữ liệu lâm sàng được quản lý thông qua CDMS là cơ sở cho việc tiếp thị thông qua các loại thuốc, thiết bị và sinh học mới, điều bắt buộc là các công ty muốn tiếp thị sản phẩm của họ có thể chứng minh chất lượng, độ tin cậy, khả năng tái sản xuất và tính toàn vẹn của dữ liệu được quản lý trong Tiến hành một nghiên cứu lâm sàng. Xác nhận cung cấp bằng chứng cho thấy hệ thống quản lý dữ liệu hoặc cơ sở dữ liệu nghiên cứu cụ thể đáp ứng các yêu cầu của nó và do đó phù hợp với mục đích dự định của nó. 

Mục tiêu của người quản lý dữ liệu lâm sàng là hoàn thành nghiên cứu với cơ sở dữ liệu chính xác, an toàn, đáng tin cậy và sẵn sàng để phân tích. Bất kỳ sai sót dẫn đến đánh giá dữ liệu không chính xác có thể gây ảnh hưởng xấu đến sự tự tin của kết quả nghiên cứu và kết luận. Theo FDA, "Hệ thống máy vi tính nên được thiết kế để ... ngăn ngừa sai sót trong việc tạo, sửa đổi, bảo trì, lưu trữ, truy xuất hoặc truyền tải dữ liệu ..."

SDLC and Validation

Nguyên tắc của SDLC áp dụng cho tất cả các loại xác nhận. Có thể mong đợi rằng các chi tiết của mỗi bước sẽ khác nhau giữa các nghiên cứu khả thi, truy cập thương mại, phát triển nội bộ, CDMS và xác nhận cụ thể cho nghiên cứu, mặc dù có thể áp dụng cùng một nguyên tắc chung cho mỗi bước. Sau đây là các giai đoạn của SDLC và cách chúng có thể áp dụng để xác nhận trong một nghiên cứu lâm sàng.

System User/Functional Requirements

Trước khi CDMS được thiết kế hoặc mua, yêu cầu của hệ thống cần được xác định rõ ràng. Mọi tổ chức tiến hành nghiên cứu lâm sàng phải có một mẫu SRS liệt kê các yêu cầu IQ, OQ và PQ, cũng như các yêu cầu về hệ thống liên quan đến hồ sơ điện tử và chữ ký điện tử theo 21 CFR Part 11. 

Design and Build

Đối với CDMS hoặc thiết kế cơ sở dữ liệu dành riêng cho nghiên cứu, quá trình này bắt đầu với một thiết kế của chương trình hoặc cơ sở dữ liệu, có thể được trình bày dưới dạng sơ đồ. Phải có tài liệu hướng dẫn chi tiết về những gì CDMS hoặc cơ sở dữ liệu muốn đạt được và nó sẽ đạt được như thế nào. Tất cả các thuật toán và mã lập trình cũng cần được ghi lại rõ ràng.

Testing

Giai đoạn thử nghiệm của SDLC là giai đoạn thường được coi là xác nhận, mặc dù mỗi giai đoạn rất quan trọng để đảm bảo kiểm tra là đầy đủ và hiệu quả. Việc kiểm tra phải được thực hiện ở từng bước phát triển và phải thực hiện kiểm tra tổng hợp để đảm bảo tất cả các bộ phận hoạt động cùng nhau một cách chính xác khi cơ sở dữ liệu hoặc CDMS hoàn thành. Một ma trận truy xuất nguồn gốc nên được sử dụng để ghi lại các bài kiểm tra tương ứng với mỗi SRS và để ghi lại khi mỗi bài kiểm tra hoàn tất.

Implementation

Một cơ sở dữ liệu hoặc CDMS nên được đưa vào sản xuất chỉ sau khi tất cả các hoạt động xác nhận đã được hoàn thành và tài liệu đầy đủ. Sau khi hoàn thành xác nhận, báo cáo tóm tắt cuối cùng phải được các bên có trách nhiệm tạo ra và ký tên.

Operation and Maintenance 

Sau khi thực hiện, CDM cần đảm bảo rằng hệ thống tiếp tục thực hiện những gì dự kiến sẽ làm. Điều này có thể được thực hiện bằng cách duy trì các tài liệu liên quan đến đào tạo, kiểm soát thay đổi / revalidations, bảo vệ các chương trình và dữ liệu, khả năng thu hồi, đánh giá sử dụng và hiệu suất của hệ thống, vv

Validation Standards

Các tiêu chuẩn xác nhận đảm bảo tái sản xuất các kết quả xác nhận, nâng cao độ tin cậy của hệ thống, và cuối cùng là nâng cao chất lượng. Các tiêu chuẩn xác nhận có thể đơn giản hóa việc thực hiện quá trình xác nhận bằng cách đảm bảo tính chính xác, đầy đủ và độ tin cậy của CDMS hoặc cơ sở dữ liệu nghiên cứu cụ thể. Các tiêu chuẩn xác nhận đảm bảo rằng mỗi lần lặp lại quá trình xác nhận được thực hiện một cách nhất quán, do đó đảm bảo cùng một mức độ tin cậy đối với việc thực hiện và tính toàn vẹn của CDMS hoặc cơ sở dữ liệu cụ thể. Mặc dù các tiêu chuẩn khác nhau giữa các tổ chức, nhưng các tiêu chuẩn đã công bố từ các tổ chức như International Organization for Standardization (ISO) và Good Automated Manufacturing Practice (GAMP) có thể cung cấp nền tảng cho việc phát triển các tiêu chuẩn xác nhận của tổ chức. Mặc dù có nhiều tiêu chuẩn xác nhận quyền lợi, nhưng chúng nên được sử dụng cùng với việc đánh giá rủi ro toàn diện. Các tiêu chuẩn xác nhận có thể trở nên phức tạp và khó thực hiện nếu chúng được tập trung hoặc thu hẹp một cách không thích đáng, tuy nhiên một đánh giá rủi ro có thể giúp ngăn ngừa CDM làm việc nhiều hơn mức cần thiết.

Validation Plan

Một kế hoạch xác nhận cho một tổng quan về toàn bộ dự án xác nhận, mô tả phạm vi công việc sẽ được thực hiện và các quy trình và thủ tục kiểm tra sẽ được sử dụng. Kế hoạch cũng mô tả trách nhiệm của các thành viên khác nhau của nhóm đánh giá, thường bao gồm các thành viên của các phòng ban khác nhau, bao gồm CNTT, QA và CDM. Ngoài kế hoạch xác nhận, có thể cần phải có một giao thức xác nhận, nó sẽ được sử dụng để cập nhật bản vá phần mềm, sửa đổi phần mềm nhỏ hoặc các gói phần mềm nhỏ không đảm bảo kế hoạch xác nhận đầy đủ. Một giao thức xác thực thường sẽ kết hợp các tính năng của một kế hoạch xác nhận, IQ, OQ, PQ và một ma trận truy xuất hiển thị các bước kiểm tra để xác nhận tính hợp lệ của từng chức năng cụ thể.

How to Develope a Validation Plan

Kế hoạch xác nhận rõ ràng mô tả tất cả các hoạt động xác nhận theo cách thức để làm sáng tỏ sự tuân thủ của kế hoạch đối với các tiêu chuẩn của công ty, ngành và tiêu chuẩn. Một số yếu tố cơ bản cần được giải quyết bao gồm tổng quan về kế hoạch, phê duyệt tài liệu, lịch sử tài liệu, mô tả hệ thống, vai trò / trách nhiệm, chiến lược và phương pháp xác nhận hợp lệ, thực tiễn về tài liệu, các dạng sai lệch / phản ứng, các nhật ký và báo cáo khác nhau, ma trận truy nguyên, nhật ký lỗi tập lệnh và tài liệu tham khảo.