Versions Compared

Key

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

Abstract:

Khi việc thu thập dữ liệu điện tử (EDC) đã trở thành một công cụ phổ biến và được chứng minh cho các thử nghiệm lâm sàng, việc tìm hiểu các nguyên tắc và hướng dẫn sử dụng EDC trở nên quan trọng hơn cho các chuyên gia quản lý dữ liệu lâm sàng (CDM). Chương này xem xét các quy trình và quy định hiện đang áp dụng cho EDC trong quá trình tiến hành nghiên cứu, và nhấn mạnh vai trò của các chuyên gia CDM trong việc duy trì một hệ thống EDC đúng cách trong một nghiên cứu đang được tiến hành.

...

Thông tin rõ ràng và dễ hiểu là một chủ đề cực kỳ quan trọng đối với tất cả các thành viên của nhóm nghiên cứu lâm sàng, bao gồm cả các nhà cung cấp vendor tham gia vào quá trình nghiên cứu. Bất kể giai đoạn hoặc thành phần của một nghiên cứu trong đó một cá nhân được tham gia, tất cả các bên phải tuân theo các nguyên tắc sau:

...

Khi người dùng đăng nhập lần đầu tiên, hệ thống EDC nên nhắc nhở người dùng thay đổi ID đăng nhập và / hoặc mật khẩu ban đầu của họ. Nếu hệ thống không có khả năng bắt buộc người dùng thay đổi mật khẩu của họ vào mục nhập đầu tiên, các giảng viên sẽ cần đảm bảo rằng hoạt động này được thảo luận với tất cả các học viên. Người dùng nên được đào tạo để giữ bí mật và ID của họ. Mỗi ID đăng nhập phải xác định duy nhất người dùng trong audit trails của hệ thống EDC và cho phép theo dõi bất kỳ thông tin nào mà người dùng nhập, sửa đổi hoặc xóa. Ngoài ra, người dùng nên được hướng dẫn để đăng nhập vào tài khoản của họ, hoàn thành nhập dữ liệu và xem lại, và đăng xuất khi hoàn thành đánh giá. Người sử dụng nên được hướng dẫn để đăng xuất khỏi hệ thống EDC khi máy tính cá nhân (PC) sử dụng để truy cập vào hệ thống EDC được để lại không giám sát. Yêu cầu ID đăng nhập và mật khẩu phải bao gồm các hạn chế về việc sử dụng lại các tài khoản và mật khẩu, ID đăng nhập và mật khẩu tối thiểu, tần suất yêu cầu thay đổi mật khẩu và tự động đăng xuất khi máy tính truy cập vào hệ thống EDC vượt quá thời gian không hoạt động .

Managing User Access

Doanh số turnover của các thành viên nhóm nghiên cứu và trang web có thể có doanh số turnover liên quan đến quy mô và thời gian của thử nghiệm. Do đó, quản lý truy cập của người dùng sẽ là một nhiệm vụ đang diễn ra trong suốt quá trình nghiên cứu của EDC.

...

Cũng giống như hỗ trợ nhiều ngôn ngữ, sự trợ giúp của phòng trợ giúp phải được xác định trước khi bắt đầu nghiên cứu. Tuy nhiên, trong quá trình tiến hành nghiên cứu, CDM nên đánh giá phản hồi từ người sử dụng để đảm bảo rằng sự sẵn có của sự hỗ trợ là phù hợp cho nghiên cứu. Báo cáo chi tiết về phản ứng và hiệu quả của hỗ trợ phần mềm nên được xem xét thường xuyên để đảm bảo sự hỗ trợ phần mềm cấp 1 có hiệu quả. Phần mềm hỗ trợ cấp 1 là mức hỗ trợ thấp nhất cần thiết và bao gồm các hoạt động như mở khóa tài khoản người dùng và đặt lại mật khẩu người dùng. Thông tin thu được từ các báo cáo và phản hồi có thể liên quan đến việc đánh giá lại các quyết định ban đầu liên quan đến mức hỗ trợ cần thiết. Ví dụ: nếu hỗ trợ 24x7x365 chưa được thiết lập ban đầu, có thể cần phải xem xét lại. Nếu một nhà cung cấp vendor được ký hợp đồng để cung cấp các dịch vụ trợ giúp, mọi thay đổi đối với hợp đồng sẽ cần phải được xem xét và thương lượng.

...

Xác định nhu cầu đào tạo lại của người dùng là một hoạt động quan trọng của cả thành viên của nhóm hoạt động lâm sàng và CDM, những người thường xuyên tương tác với trang web. CDM cần phải nhận thức được các tình huống tại một địa điểm có thể gây ra những thách thức và nhu cầu đào tạo lại, chẳng hạn như điều phối viên không có kinh nghiệm, sự cô lập, doanh sốturnover, hoặc ưu tiên cạnh tranh. Thông tin hiện có, chẳng hạn như báo cáo trợ giúp, báo cáo tần số truy vấn và báo cáo độ lệch của giao thức, có thể được sử dụng để xác định các tài liệu cần cập nhật hoặc người dùng cần đào tạo mới hoặc bổ sung.

...

Một sự xuất hiện phổ biến trong nghiên cứu lâm sàng là doanh thu turnover của cả site staff và sponsor staff. Nhân viên mới phải nhận được sự huấn luyện cần thiết, và các tài khoản người dùng và sự cho phép trong hệ thống phải được cập nhật để phản ánh những thay đổi của nhân viên. Một kế hoạch cần được thiết lập để người sử dụng mới được đào tạo kịp thời để họ có thể có được quyền truy cập dữ liệu vào hệ thống EDC. Nếu nhân viên trang web mới không được đào tạo và không có quyền truy cập vào hệ thống, họ không thể nhập dữ liệu, và thời hạn nghiên cứu có thể bị ảnh hưởng tiêu cực.

Change Control

Bất kỳ hệ thống EDC nào cũng có thể thay đổi trong quá trình tiến hành nghiên cứu vì những thay đổi trong phần mềm EDC và / hoặc những thay đổi trong bản thân nghiên cứu.

Software Change Control

Bởi vì nhiều thử nghiệm lâm sàng xảy ra trong vài năm, thay đổi phần mềm và nâng cấp chắc chắn sẽ ảnh hưởng đến các nghiên cứu của EDC. Những thay đổi hoặc nâng cấp này không chỉ giới hạn trong phần mềm EDC cốt lõi mà còn có thể bao gồm nâng cấp lên hệ điều hành, phần mềm cơ sở dữ liệu back-end, hoặc bất kỳ phần mềm phụ trợ tích hợp với hệ thống EDC, chẳng hạn như báo cáo hoặc trích xuất phần mềm. Sự khác biệt trong các chiến lược và quy trình kiểm soát thay đổi phụ thuộc vào việc liệu phần mềm được phát triển nội bộ bởi nhà tài trợ hay mua từ vendor.

Nếu phần mềm được mua, nhà tài trợ có thể quyết định dựa vào gói kiểm chứng hệ thống của vendor cho phần mềm, bao gồm tất cả các bản phát hành hoặc nâng cấp, và duy trì hệ thống như một nền tảng "đủ điều kiện" hơn là thực hiện xác nhận hệ thống mỗi khi phát hành. Tuy nhiên, các nền tảng phần mềm "đủ điều kiện" không nên được tùy chỉnh bởi người bảo trợ trừ khi xác nhận của nền tảng tùy chỉnh cũng sẽ được thực hiện.

Controlling Changes to the System by Incorporating Software Development Life Cycle Principles

Before making a decision to implement upgrades to the software system (whether it is a new release or a minor version update), CDM should make a complete assessment of the software changes and obtain input from other areas that may be impacted, including a thorough risk assessment. The first step in performing an assessment is to gain a clear understanding of all changes or additions that will be made to the software. For software purchased from a vendor, this task can be accomplished by ensuring that the software release notes are reviewed and well understood by appropriate staff. Release notes should include documentation of all changes, any known issues in the new release, and instructions for upgrading the software from previous versions.

For software produced internally by the sponsor, a well-developed change control process should be established. This process should include steps for reviewing change requests, grouping multiple change requests together as appropriate, updating requirements and design documentation, build, testing, and implementation.

To determine whether a software system should be upgraded, the sponsor should consider the following issues:

  • Tác động lên dữ liệu (Impact on data) - Đánh giá nếu có bất kỳ thay đổi nào về chức năng phần mềm có thể ảnh hưởng đến tính toàn vẹn dữ liệu. Ví dụ, nếu một số ký tự hoặc chức năng nào đó không còn được hỗ trợ, nhà tài trợ phải đảm bảo tính toàn vẹn dữ liệu sẽ được bảo toàn sau khi nâng cấp phần mềm.
  • Tác động lên mã hiện có (Impact on existing code) - Việc nâng cấp phần mềm có thể yêu cầu bạn thay đổi mã lập trình hiện tại.
  • Các hệ thống phụ trợ (Auxiliary systems) - Nhà tài trợ nên đánh giá các hệ thống hoặc chương trình liên quan sẽ bị ảnh hưởng như thế nào khi nâng cấp phần mềm. Các hệ thống khác có yêu cầu nâng cấp hoặc sửa đổi tương ứng không?
  • Tác động lên các sites (Impact on sites) - Nghiên cứu sẽ không thể truy cập trong quá trình nâng cấp phần mềm? Site có được yêu cầu thực hiện các tác vụ nhất định, chẳng hạn như cài đặt phần mềm trên máy tính địa phương hoặc thay đổi cài đặt trình duyệt? Site có cần đào tạo bổ sung không? Các Sites sẽ được thông báo về tác động như thế nào?
  • So sánh chi phí và giá trị (Comparison of cost and value) - Chi phí thực hiện và xác nhận việc nâng cấp phần mềm phải được so sánh với giá trị kinh doanh cần đạt được.
  • Ảnh hưởng đối với các nghiên cứu đang diễn ra (The impact on ongoing studies) - Xét ảnh hưởng đến cơ sở dữ liệu nghiên cứu và thời gian còn lại, liệu có đáng để nâng cấp phần mềm lên một phiên bản mới? Liệu phần mềm cho các nghiên cứu đang diễn ra cần phải được nâng cấp đồng thời?
  • SOP và các tài liệu đào tạo (SOPs and training materials) - Việc nâng cấp phần mềm cần phải xem xét lại SOP của các nhà tài trợ hoặc các tài liệu đào tạo không?

Đối với phần mềm EDC được sản xuất trong nước hoặc tùy chỉnh, cần tạo tài liệu yêu cầu mới. Nỗ lực này thường do quản lý dữ liệu. Tài liệu yêu cầu phải bao gồm các tính năng và chức năng mới, cũng như các thay đổi đối với các tính năng và chức năng hiện tại. Các yêu cầu tài liệu phục vụ như là cơ sở cho các chi tiết kỹ thuật thiết kế. Tạo các thông số kỹ thuật thiết kế thường được thực hiện bởi nhóm người sẽ lập trình các thay đổi.

Ngoài các yêu cầu tài liệu, quản lý dữ liệu sẽ cần phải phát triển một chiến lược kiểm tra tài liệu kiểm tra và xác nhận yêu cầu cho các phần mềm mới. Tùy thuộc vào loại nâng cấp, việc kiểm tra chuyên sâu không phải lúc nào cũng cần thiết. Các hướng dẫn sau đây có thể được sử dụng để xác định các nỗ lực thử nghiệm bắt buộc:

  • For a minor version (bug fix or upgrade), limited testing is required.
  • For a new release or major version upgrade, moderate to intensive testing is required.

Đối với các hệ thống EDC đã mua, vendor có thể cung cấp và duy trì kế hoạch thử nghiệm và kết quả. Đối với phần mềm EDC được sản xuất nội bộ, các kịch bản thử nghiệm hoặc các trường hợp thử nghiệm dựa trên yêu cầu người dùng mới sẽ được sản xuất. Trước khi thực hiện thay đổi trong môi trường sản xuất, tất cả các thử nghiệm phải được thực hiện trong môi trường thử nghiệm. Các tính năng và chức năng mới được cung cấp bởi bản nâng cấp (cũng như cải tiến các tính năng hoặc chức năng hiện có) cần được kiểm tra. Một bản ghi sự cố hoặc hệ thống theo dõi lỗi dựa trên nền web nên được sử dụng để theo dõi lỗi được tìm thấy trong quá trình kiểm tra, do đó trạng thái của các vấn đề này có thể được theo dõi thông qua giải pháp của họ.

Nếu xác nhận hợp lệ của bản phát hành mới đã được hoàn thành thành công, phiên bản mới hoặc thay đổi có thể được thực hiện trong sản xuất. Vui lòng xem phần "Database Validation, Programming and Standards" của Good Clinical Data Management Practices để biết thêm thông tin về xác nhận hợp lệ, bao gồm các khuyến nghị, tiêu chuẩn tối thiểu và các phương pháp hay nhất.

Đào tạo về phần mềm đã thay đổi

Trong khi nâng cấp nhỏ cho phần mềm dường như không được chú ý bởi người dùng, một bản phát hành mới hoặc nâng cấp lớn cho phần mềm có thể yêu cầu đào tạo bổ sung. Nhà tài trợ nên xác định mức độ đào tạo bắt buộc, mà người sử dụng nên được đào tạo và phương pháp đào tạo.

Thông thường, nhân viên nhà tài trợ (CRAs / CDM) và site staff sẽ cần đào tạo, có thể gửi trực tiếp, từ đĩa CD, sử dụng Web, vv Các bài thuyết trình sử dụng hình ảnh màn hình có thể đặc biệt có ích cho mục đích đào tạo vì chúng có thể được sử dụng lại Cho các buổi tập huấn sau này. Sponsor staff nên được đào tạo trước tiên về chức năng mới hoặc được sửa đổi của phần mềm và sau đó là nhân viên của trang.

Xây dựng Kế hoạch triển khai

Trước khi cung cấp phần mềm mới cho nhân viên, cần phải đánh giá tác động của phần mềm sửa đổi. Ví dụ, nếu sửa đổi phần mềm sẽ yêu cầu sửa đổi các CRF đã được phê duyệt, nhà tài trợ nên xác định các vấn đề của Hội đồng Thẩm định về Thể chế (IRB) để giải quyết (các vấn đề của IRB dường như không áp dụng cho nâng cấp phần mềm nhưng có thể áp dụng cho các bản sửa đổi của CRF). Nhà tài trợ nên xác định liệu phần mềm mới cần được nâng cấp theo từng giai đoạn hoặc cùng một lúc.

Site cần được thông báo về việc triển khai phần mềm mới với đủ thời gian cho những sự chuẩn bị cần thiết. Trong trường hợp nâng cấp không xảy ra như mong đợi, một kế hoạch dự phòng hoặc dự phòng đã được xác định rõ ràng phải được thiết lập trước khi triển khai phần mềm. Đối với nghiên cứu quốc tế, thời gian có sẵn để thực hiện nâng cấp phần mềm có thể bị giới hạn và có thể yêu cầu nâng cấp phải hoàn thành trong giờ làm việc bình thường.

Quản lý Bản phát hành cũ

Software Vendors thường duy trì tất cả các phiên bản phần mềm trong một khoảng thời gian nhất định. Nhà tài trợ nên biết mức độ hỗ trợ được cung cấp bởi vendors. Khi một vendor tung ra một hệ thống mới, họ có thể không tiếp tục cung cấp cùng một mức độ hỗ trợ cho các phiên bản trước của hệ thống phần mềm và cuối cùng có thể retire các phiên bản trước đó. Thông thường, một khi phiên bản đã retired, software vendor không còn hỗ trợ cho phiên bản đó.

Do sự phát triển liên tục của các hệ thống phần mềm nên người bảo trợ nên lên kế hoạch cho những thay đổi trong tương lai và xác định thời điểm thích hợp để nâng cấp hoặc retire một hệ thống hiện có. Một số yếu tố cần xem xét bao gồm:

  • Phần mềm được nâng cấp trong quá trình nghiên cứu - Software upgraded during study conduct
  • Cam kết hỗ trợ của nhà cung cấp cho các phiên bản phần mềm trước - Vendor’s support commitment to previous versions of software
  • Phần mềm hoặc phần cứng trở nên lỗi thời - Software or hardware that becomes obsolete
  • Giảm hiệu năng hệ thống - Decreased system performance
  • Trial timelines

Study-Specific Change Control

Trái ngược với thay đổi phần mềm, thử nghiệm cũng có thể bị ảnh hưởng bởi những thay đổi cụ thể về nghiên cứu, chẳng hạn như sửa đổi giao thức hoặc các vấn đề phát triển. Do đó, có thể cần phải sửa đổi CRF, chỉnh sửa kiểm tra và / hoặc báo cáo. CDM nên đánh giá các thay đổi cần thiết để xác định cách chúng được thực hiện trong hệ thống và triển khai tới các sites.

Changes to CRFs

Phần mềm điều khiển phiên bản nên được sử dụng cho CRF, và các tập tin điện tử nên được tổ chức bằng cách nghiên cứu trong một cấu trúc thư mục có thứ bậc. Đối với mỗi nghiên cứu, việc ban hành ban đầu và những thay đổi tiếp theo đối với CRF cần được chỉ ra bởi các quy ước đặt tên hoặc nhãn. Xác định ngày và giờ mà các tệp tin đã được phát hành, để thời gian phát hành rõ ràng cho mục đích quy định hoặc khắc phục sự cố với CRF. Tất cả các văn bản tiêu chuẩn cài đặt phải được duy trì cho mỗi phiên bản. Một bản ghi xác nhận bản phát hành phiên bản cũng cần được duy trì và ký kết bởi tất cả các bên thích hợp theo yêu cầu và được xác định bởi các thủ tục của nhà tài trợ.

Trước khi đưa ra bản CRF mới, CDM cần đánh giá ai sẽ có những thay đổi. Nếu những thay đổi dẫn đến việc sửa đổi các CRF đã được phê duyệt thì người đánh giá nên xác định xem những thay đổi này có ảnh hưởng đến các sites và IRB hay không và thông báo cho tất cả các thành viên nhóm nghiên cứu và các trang web phù hợp trước. Đối với các nghiên cứu quốc tế, thời gian để triển khai một phiên bản được cập nhật là giới hạn hơn và có thể cần triển khai trong giờ làm việc bình thường.

CDM nên tham khảo với các hoạt động lâm sàng để xác định xem có nên triển khai phiên bản mới theo từng giai đoạn hoặc cùng một lúc. Nếu những thay đổi được triển khai giữa các nghiên cứu, nhóm nghiên cứu trước hết phải được thông báo khi có sự thay đổi và nhóm nghiên cứu sẽ có cơ hội xem xét những thay đổi trước khi triển khai đến các địa điểm. Site staff phải được thông báo về việc đào tạo và triển khai trước khi các thay đổi được đưa ra cho hệ thống sản xuất. 

Khi đã có thay đổi, tất cả các bên phải được thông báo. Để đảm bảo các trang thích hợp được chuyển sang phiên bản mới của CRF, CDM sẽ tạo một bản ghi sẽ theo dõi khi mỗi site được chuyển sang phiên bản CRF mới. Đăng nhập đúng sẽ đảm bảo không có trang web bị bỏ qua trong tiến trình. Không phải tất cả các sites đều có thể yêu cầu phiên bản mới, chẳng hạn như trong trường hợp các thay đổi liên quan đến phụ lục của đề cương. Các ngày mục tiêu nên được thiết lập và theo dõi để nâng cấp các sites vào hệ thống mới, cần được theo dõi chặt chẽ.

Dữ liệu nhập vào trong phiên bản trước của nghiên cứu EDC nên được cung cấp cho các sites và nhóm nghiên cứu. Bất kỳ dữ liệu mới nào chưa được nhập vào phiên bản trước của nghiên cứu EDC phải tuân theo định dạng CRF vừa được phát hành. Nếu sửa đổi kiểm tra đã được sửa đổi, CDM nên xem lại những sai lệch cũ để xác định xem chúng vẫn còn hiệu lực, và nếu có sự khác biệt nào cần phải được đóng lại do những thay đổi.

Mid-study Requests for Patient Data

Yêu cầu giữa nghiên cứu về dữ liệu của các subjects có thể xảy ra vì nhiều lý do, bao gồm nhưng không giới hạn ở đây:

  • Một phân tích thống kê tạm thời theo lịch trình dựa trên thiết kế và nghiên cứu nghiên cứu, thường tập trung vào dữ liệu hiệu quả - A scheduled interim statistical analysis based on study design and protocol, which typically focuses on efficacy data
  • Đánh giá tạm thời dữ liệu tập trung vào dữ liệu an toàn, chẳng hạn như các sự kiện bất lợi và các dữ liệu khác cho thấy các vấn đề về an toàn trong các nghiên cứu trước đó (ví dụ: dữ liệu ECG, bảng phòng thí nghiệm) - An interim review of data focusing on safety data, such as adverse events and other data that indicated safety issues in earlier studies (e.g., ECG data, lab panels)
  • DSMB or Clinical Endpoint Committee (CEC) regularly scheduled meetings
  • A submission package or other type of update (e.g., 120-day safety update) for regulatory purposes
  • Any other planned or unplanned data lock

Một yếu tố chính ảnh hưởng đến việc phân phối các dữ liệu bệnh nhân giữa các bệnh nhân là liệu các dữ liệu được lưu trữ bởi nhà tài trợ hoặc nhà cung cấp. Nếu dữ liệu được lưu trữ bởi nhà tài trợ, dữ liệu cần phải sẵn sàng, do đó giảm chi phí và nguồn lực cần thiết. Nếu sử dụng hệ thống lưu trữ của nhà cung cấp (mô hình cung cấp dịch vụ ứng dụng) (ASP), thời gian và tần suất phân phối sẽ quan trọng hơn và cần có kế hoạch cho thời gian và chi phí bổ sung.

Cho dù sử dụng hệ thống của nhà tài trợ hay nhà cung cấp, dữ liệu bệnh nhân cần phải được xác định rõ ràng. Các ví dụ về xác định điều kiện tiên quyết để export dữ liệu bệnh nhân bao gồm, nhưng không giới hạn ở:

  • Một phân tích tạm thời có kế hoạch xảy ra ở một cột mốc cụ thể (ví dụ, bệnh nhân ngẫu nhiên lần thứ 100) - An interim analysis planned to occur at a particular milestone (e.g., the 100th randomized patient)
  • Đánh giá về an toàn có kế hoạch xảy ra tại một cột mốc cụ thể (ví dụ: 25% bệnh nhân đăng ký, 50% đăng ký) - A safety review planned to occur at a particular milestone (e.g., 25% patients enrolled, 50% enrolled)
  • Một phân tích hiệu quả giữa nghiên cứu, dựa trên thiết kế thống kê của các đề cương - A mid-study efficacy analysis, based on statistical design of the protocol
  • Regularly schedule DSMB/CEC meeting

Ngoài việc xác định những bệnh nhân nào sẽ được đưa vào export, nhà tài trợ nên xác định hồ sơ nào sẽ được đưa vào trong việc phân phối. Giải pháp đơn giản nhất là bao gồm tất cả các dữ liệu nghiên cứu, bất kể tình trạng của nó. Tuy nhiên, việc phân phối có thể bị hạn chế đối với dữ liệu đã được CRA hoặc giám sát xác minh, hoặc để dữ liệu bị khóa (sạch), đòi hỏi phải có sự phối hợp chặt chẽ với CRA để lập kế hoạch  giám sát. Cũng như trường hợp thử nghiệm bằng giấy, nếu dữ liệu được sử dụng để phân tích an toàn tạm thời, việc xem xét các SAE có thể cần chú ý thêm.

Bất kỳ dữ liệu bên ngoài nào phải được tích hợp vào cơ sở dữ liệu trước khi cung cấp bất kỳ dữ liệu subject nào giữa nghiên cứu (ví dụ: dữ liệu trong phòng thí nghiệm hoặc ECG) nên được lên kế hoạch trước tiến độ của nhóm nghiên cứu để báo cáo. Khi cần thiết, cần đảm bảo tính đầy đủ và chính xác của dữ liệu đó bằng cách đối chiếu trước khi phân phối dữ liệu xảy ra.

Những người nhận các dữ liệu nghiên cứu được yêu cầu và tác động đến nghiên cứu blinding cũng phải được xem xét. For interim analyses, SAS datasets are typically provided to a biostatistician or statistical programmer, who subsequently creates tables or listings from the raw data. 

Các định dạng phân phối khác có thể bao gồm Microsoft Access hoặc Excel, nhưng những định dạng này được sử dụng ít thường xuyên hơn và thường ít được ưa thích hơn. Thời gian giao hàng (ví dụ, theo kế hoạch hoặc theo yêu cầu) cũng là một thành phần quan trọng cần xem xét. Nếu yêu cầu cung cấp dữ liệu yêu cầu, các thủ tục cần thiết có thể được lên kế hoạch chi tiết. Tuy nhiên, nếu yêu cầu dữ liệu được yêu cầu đột xuất, quá trình xuất và phân phối dữ liệu phải mạnh mẽ và linh hoạt để đảm bảo phân phối kịp thời. Khi nhận được các yêu cầu, các chương trình nên được kiểm tra và xác nhận để đảm bảo phân phối kịp thời.

Thử nghiệm bao gồm quá trình khai thác và phân phối hoàn chỉnh, bao gồm kiểm tra xem tất cả các biến cần thiết có sẵn trong bộ dữ liệu và được chứa các giá trị dự kiến. Lỗi hoặc thiếu sót được ghi nhận trong quá trình thử nghiệm có thể được sửa chữa cho đến khi xuất dữ liệu hoạt động theo yêu cầu.

Midstudy Requests for Notable Subject CRFs

Cục Quản lý Thực phẩm và Dược phẩm (FDA) yêu cầu CRF từ các đối tượng để đáp ứng các tiêu chí nhất định. Theo yêu cầu của CFR 314.50 (f), đối với bất kỳ đơn thuốc mới nào (NDA - New Drug Application), các CRF cá nhân phải được cung cấp cho bất kỳ đối tượng nào đã rút khỏi nghiên cứu do sự kiện bất lợi hoặc đã chết trong quá trình nghiên cứu. Tùy vào nghiên cứu và Trung tâm FDA, FDA có thể yêu cầu CRF bổ sung để xem xét NDA.

Người bảo trợ cần được chuẩn bị để chuyển CRF vào bất cứ lúc nào trong quá trình nghiên cứu, ví dụ như để cập nhật an toàn định kỳ NDA hoặc tổng hợp an toàn. Một giải pháp có thể là cung cấp các bản sao điện tử của hình ảnh CRF. Nếu CRF được sử dụng trong bài nộp, phần mềm xuất bản được sử dụng để tạo CRF nên được coi là có thể dễ dàng kết hợp các bản sao điện tử. Khi làm việc với một nhà cung cấp, nhà tài trợ nên tính đến quá trình nhận CRF vào thời hạn nghiên cứu và kỳ vọng của hợp đồng (ví dụ: số lượng yêu cầu tối đa). 

Recommended Standard Operating Procedures: 

  • Data Review and Edit Checks for EDC Studies
  • Data Management Plan
  • System Maintenance
  • EDC Training
  • Study/CRF and Edit Check Change Control
  • Software System Change Control
  • User Management and Security

Original Documentation: Click here