Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 24 Next »

Phạm vi

Chương này cung cấp thông tin về các khái niệm và hoạt động start-up liên quan đến các hệ thống EDC cho các công ty đang cân nhắc chuyển một vài hoặc tất cả các quá trình từ thu thập dữ liệu giấy truyền thống đến EDC. Nó tập trung về việc thiết lập một môi trường thuận lợi cho việc kết hợp các công nghệ EDC vào quá trình thử nghiệm lâm sàng từ khía cạnh của quản lý dữ liệu.Thực hành,thủ tục và khuyến nghị được đề xuất cho các nhà quản lý dữ liệu để chuẩn bị và bắt đầu một hệ thống EDC sẽ sắp xếp đúng dữ liệu điện tử nắm bắt công nghệ để hỗ trợ các nhu cầu nghiên cứu thống kê và y tế. Ngoài ra cũng so sánh giữa nhập liệu bằng giấy và online.Sẽ chủ yếu xoáy vào các hoạt động start-up để hỗ trợ EDC cho việc nhập CRFs điện tử (hay còn gọi là eCRFs mặc dù thuật ngữ này ít sử dụng trong doc này) và cách kết hợp dl với dl non_CRF 

Differences Between EDC and Paper-based Studies

Bốn lĩnh vực quan trọng khác nhau giữa EDC và các nghiên cứu trên giấy là cách thu thập dữ liệu, thời gian cần thiết để chuẩn bị cho nghiên cứu, cách thu thập dữ liệu sẽ được xác minh, và kế hoạch phục hồi thảm họa

Offline vs. Online vs. Hybrid Studies

Có 3 cách chính trong việc thu thập dl là:

    • Offline : cách truyền thống là pp thu thập tt trên giấy, gửi và so sánh hoặc là hệ thống EDC làm việc mà không có internet
    • Online: sử dụng nguồn internet để ghi dữ liệu trong form điện tử cái mà đc lưu trữ ở trong máy chủ location
    • Hybird: kết hợp online và offline. sử dụng hệ thống giấy và dùng EDC để quản lý một số khía cạnh trong quá trình thu thập dl hoặc là sử dụng cả 2 cách.

Cách được chọn thường phụ thuộc vào khả năng và giới hạn của nhà đầu tư và phần mềm EDC cũng như việc site nào sẽ tham dự vào study này. Ngoài ra kế hoạch và phân thích cũng rất quan trọng để tính toán xem cách nào đc sử dụng vào study

Study Development and Start-up Timelines

Bởi vì cơ sở dữ liệu của nghiên cứu phải linh động khi đăng ký bệnh nhân đầu tiên,nên các hoạt động khởi đầu của nghiên cứu là rất quan trọng cho các nghiên cứu EDC. Đối với những người làm việc tại cơ sở tài trợ, nhiều hoạt động khởi động chỉ có thể được thực hiện khi EDC ban đầu được thông qua.Nhiều hoạt động khởi động CDM điển hình cho cả hai nghiên cứu trên giấy và nghiên cứu EDC bao gồm: phê duyệt protocol, thiết kế CRF, CRFChú thích,đặc tả CRF, người dùng chấp nhận thử nghiệm (UAT), và chuẩn bị tài liệu. Sự khác biệt về thời gian khởi động của CDM đối với các nghiên cứu EDC chủ yếu dựa vào số lượng các nhiệm vụ phải tăng lên hoàn thành trước khi nghiên cứu có thể bắt đầu.Thêm vào các hoạt động thông thường của start up, một số hoạt động bổ sung có thể cần được xem xét cho EDC rằng có thể ảnh hưởng đến sự phát triển của nghiên cứu và thời hạn khởi động, bao gồm:


  • Rà soát SOP để hỗ trợ quá trình EDC (tài liệuChuẩn bị). Đối với các nhà tài trợ hoạt động này có thể được thực hiện một lần, trong khi đối với CRO điều này có thể xảy ra với mỗi nhà tài trợ mà họ ký hợp đồng.
  • Xác định vai trò và quyền truy cập dữ liệu của nhà tài trợ và nhân viên ở site
  • Quản lý tài khoản người dùng, có thể bao gồm các bản ghi kiểm soát truy cập và tài liệu quản lý tài khoản
  • Định nghĩa và tạo ra các mẫu thu thập dữ liệu tiêu chuẩn mới hoặc sửa đổi
  • Lập trình thử nghiệm cụ thể và UAT (ví dụ: chỉnh sửa kiểm tra, thiết kế màn hình)
  • Chuẩn bị từ điển và quy trình mã hoá khi cần thiết
  • Thiết kế, lập trình, và test các báo cáo. Thiết lập báo cáo chuẩn có thể được tái sử dụng trên các hợp chất.
  • Báo cáo tình trạng của tình trạng xét xử theo thời gian
  • Xác định và yêu cầu thử nghiệm cho truyền dữ liệu và tích hợp với các hệ thống khác hoặc dữ liệu của bên thứ ba. Sử dụng các tiêu chuẩn ngành nếu có thể(ODM, LAB, v.v ...)
  • Lựa chọn ứng dụng cụ thể cho tác vụ (ví dụ: một hệ thống thanh toán viện trợ)Có thể cần phải được tích hợp với hệ thống EDC
  • Đánh giá site về khả năng sử dụng EDC
  • Hệ thống EDC và đào tạo chuyên biệt cho các thử nghiệm
  • Hỗ trợ trợ giúp cho người sử dụng
  • Lập kế hoạch khôi phục thảm họa


Với các hoạt động start_up CDM này, nó rất quan trọng để nhớ rằng những hoạt động này có tính xuyên chức năng rất cao

Source Document Verification (SDV) 
FDA đã phát hành các yêu cầu cho các bản ghi và chữ ký điện tử cho 21 CFR part 11. Yêu cầu đó cung cấp các tiêu chí để xem xét các bản ghi điện tử tương đương với bản giấy và chữ ký điện tử so với ký tay. Xác định mức độ và số lượng của SDV không trong phạm vi DM, tuy nhiên, nó rất quan trọng để xác định liệu rằng quá trình SDV có ảnh hưởng đến database dưới bất kỳ hình thức nào ko. Về nguyên tắc, tiến hành xác minh dữ liệu nguồn ở các bản ghi điện tử phải chính xác, nguyên gốc, rõ ràng,attributable, đồng thời.Nó rất quan trọng để xác định quá trình SDV sẽ hoạt động như thế nào trước khi khởi động một nghiên cứu EDC vì thế dl có thể được cấu hình để hỗ trợ truy cập, luồng công việc và báo cáo yêu cầu.Xác nhận của các hệ thống máy tính là hoàn toàn khác nhau nhưng rất quan trọng về mặt các bản ghi điện thử phải được điền thông tin. Một số hệ thống cho phép các chiến lược SDV khác nhau và một số thì không. Điều đó cần phải được thông qua trước bất kỳ cấu hình xác định của study nào đó được yêu cầu. ( This needs to be agreed upon up front in case any study specific configuration is required_dịch lại)

The ICH Harmonised Tripartite Guidelines for Good Clinical Practice, the WHO Guidelines for Good Clinical Practice for Trials on Pharmaceutical Products, and the Code of Federal Regulations yêu cầu SDV phải được xuất hiện trong cất cả các giai đoạn của nghiên cứu I-IV. Một đánh giá về sự phù hợp của dl trong CRFs với dl nguồn, SDV được tiến hành để chắc chắn rằng dl được thu thập là tin tưởng và cho phép xây dựng và đánh giá lại nghiên cứu.Nhiệm vụ của  principal investigator, subinvestigator, study coordinator, monitor, quality assurance auditor, and the clinical trial manager phải được làm rõ ở giai đoạn đầu của nghiên cứu và cần được đào tạo đầy đủ.Vì thế không có chuyện hiểu lầm hay mặc lỗi khi tiến hành SDV...(đoạn này nói rằng người SDV rất quan trọng và phải làm tốt nhất có thể, ko sai sót)

Trong quá trình SDV, thông tin investigator thông báo phải được so sánh với bản gốc để chắc chắn rằng nó đã được hoàn thành, chính xác và hợp lệ. Nói nghiêm túc, tất cả các phần dl trong CRF phải được lưu giữ ở đâu đó để xác minh, xem lại và xây dựng lại. Mục đích chính của SDV là khẳng định những thông tin thu thập trong suốt quá trình nghiên cứu là hoàn thành, chính xác đang tin và được xác thực để nhà tài trợ tự tin và các nhà chức trách sử dụng các thông tin này trong thị trường. SDV cũng yêu cầu để cung cấp thông tin tin cậy vd như nó đc thông báo trong các hội nghị khoa học. Nếu không có SDV hoặc là các phương pháp thu thập thông tin điện tử thì không một nhà khoa học nào có thể tự tin về các dữ liệu hiện có và đưa ra kết luận.

Tất cả các dl dưới đây đều được xem như dl chính trong SDV và bất kỳ 1 sai sót sơ đẳng nào cũng sẽ gây hại cho các nhà khoa học và đạo đức nghiên cứu lâm sàn

    • Primary efficacy data
    • Inclusion/exclusion criteria
    • Medical and medication history Physical examination and vital signs
    • Visit dates
    • Adverse events
    • Concomitant medication
    • A record that the patient has entered a clinical study and the date of
    • informed consent

Disaster Recovery and Business Continuity Planning → nói về các thiên tai rủi ro thì ta sẽ phải làm gì? tìm hiểu phần này sau

EDC Deployment Considerations (Xem xét về việc triển khai EDC)

Xem xét về việc triển khai hệ thống EDC là của các nhà lãnh đạo, họ phải tìm hiểu, phỏng vấn và tiếp xúc với các nhà cung cấp EDC. Bao gồm ba bước sau:

  • Hiểu các CN phần mềm(pdf-based, XMLbased, etc) 
  • Hiểu khả năng của các hệ thống EDC
  • Nghiên cứu các thông tin cơ bản về các nhà cung cấp

Thin Client and Thick Client Technology Comparison

Có một số vấn đề cần xem xét khi lựa chọn nhà cung cấp EDC và ứng dụng client server cho một thử nghiệm lâm sàng.Key để quyết định là liệu phần lớn khối lượng công việc sẽ được thực hiện trên máy tính của client (bên giám sát) hoặc trên server. Quyết định này có thể xác định chi phí của client và server, độ mạnh và bảo mật của ứng dụng, tính linh hoạt của thiết kế cho các thông tin chỉnh sửa.

Thick client (hay còn gọi là "fat client" hay là "rich client") là phầm mềm thực hiện 1 gói các hoạt động xử lý dl và không cần hỗ trợ của server. VD cài đặt ctrinh xử lý văn bản trong máy tính cá nhân.Tất cả các tài liệu và lưu trữ trong PC mà không liên quan đến server. Đối với các bên cùng tham gia để nhập thông tin. thick client yêu cầu download phần mềm về máy ở bên site giám sát. 

Bất tiện của thick client là: trong bệnh viện thì vấn đề về bảo mật và riêng tư phải được xem xét. Người dùng không có quyền để cài đặt phần mềm và firewall có sẵn trong máy có thể block các liên lạc với server. Một thick client có thể yêu cầu 1 internet chuyên biệt và dưới sự giám sát của IT. Mỗi thay đổi của client software phải yêu cầu xác minh tương ứng với 21 CRF part 11. Thick client có thể gặp phải vấn đề về nâng cấp, người dùng phải kết nối với remote server để nhận bản nâng cấp và các bản ghi chính xác phải được giữ để chắc chắn tất cả user đang sử dụng phiên bản hiện thời ...Thêm vào nữa là khi người dùng phải đồng bộ dl client với máy chủ trung tâm để submit dl, contact có thể bị mất trước khi đồng bộ được hoàn thành vì thế kết quả là không nhất quán.

Tiện ích của thick client: 

  • Xử lý ở local: kiểm tra những logic phức tạp và có thể coding ngay và luôn
  • Giảm tải gánh nặng cho máy chủ: bởi vì thick client quản lý rất nhiều xử lý ứng dụng và một thick client có mức độ cao như một máy chủ. Việc sử dụng thick client giảm độ chịu tải của server bằng cách sử dụng client machine cho các task nặng như báo cáo và phân tích
  • Hiệu năng đa phương tiện tốt hơn: Thick clients have advantages in multimedia-rich applications, which are bandwidth intensive when delivered over a thin client.
  • Linh hoạt: trong một vài hệ thống, một số sản phẩm được thiết kế cho PCs có thể có nguồn dl ở trong máy. chạy những phần mềm này giống như thin client là có thể khó khăn
  • Thick client cho phép sites với băng thông thấp thì vẫn duy trì đc việc chuyển dl 


    Thin client có rất nhiều ưu điểm và nó phải phụ thuộc và server. Người tham gia nhập liệu không phải nhập liệu trên 1 máy được chỉ định sẵn nữa mà 
  • Giá thuê quản trị viên rẻ hơn: các clients được quản lý hoàn toàn bởi server và phần cứng ít khi có lỗi. Môi trường local bị giới hạn rất cao vì tăng tăng bảo vệ từ các phần mềm có hại
  • Dễ để bảo mật hơn: các client có thể được thiết kế vì thế các ứng dụng dl chỉ đc xem trong browser nhưng không bao giờ được lưu trong PC dưới bky hình thức nào.
  • Giá hardware rẻ hơn: phần cứng cho thin client không bao gồm đĩa, bộ nhớ hoặc bộ xử lý mạnh và có thể share memory. Túm lại là thin client chỉ cần yếu hơn thick client
  • Cần ít băng thông hơn: bởi vì  terminal server(máy chủ đầu cuối) cùng một mạng network chính với tốc độ cao nhưng server file, hầu hết các mạng lưới network đều bị hạn chế trong phòng server. Khi một thick client được sử dụng. một số lượng lớn các file được truy cập có thể được chuyển hay là in thì thick client chuyển toàn bộ file qua network. Nếu sites mà bị giới hạn bandwidth, thì quá trình này có vẻ ko hiệu quả. Nếu mà thin client được sử dụng, chỉ một cú chuyển chuột hay phím tắt là màn hình sẽ được thay đổi và đc chuyển giữa server và end user vì thế có thể chuyển ` lượng file lớn để được truy cập với băng thông ít
  • Hiệu quả hơn khi sử dụng các nguồn: Mô hình thick-client được thiết kế để tối đa hóa nhu cầu của  người sử dụng. Tuy nhiên những thiết kế như vầy có thể ko hiệu quả khi phân bổ nguồn xử lý không được sử dụng hết.Trái ngược với nó thì thin clients được thiết kế để sử dụng khối lượng tài nguyên được yêu cầu cho nhiệm vụ hiện tại
  • Dễ dàng nâng cấp hardware: theo mô hình thin-client, nếu việc sử dụng tài resource ở mức cao nhất mà vẫn cao hơn giới hạn định nghĩa thì việc tăng cường resource là đơn giản (Vd có thể thêm 1 rack vào blade server) và những đơn vị cũ vẫn đc duy trì cùng với cái mới. Tuy nhiên trong thick client, để giải quyết vấn đề này cần yêu cầu toàn bộ PC phải đc thay thế, và kết quả là mất thời gian của người dùng và liên quan đến vấn về bảo mật của các vđ cũ.

Application Service Provider (ASP) vs. Technology Transfer Các nhà cung cấp dịch vụ ứng dụng và chuyển giao công nghệ

Quyết định sử dụng mô hình ASP hoặc chuyển giao công nghệ cho EDC phụ thuộc phần lớn vào chiến lược dài hạn của nhà tài trợ. Các yếu tố quyết địnhThường dựa trên tần suất sử dụng phần mềm (ví dụ: bao nhiêu Nghiên cứu mà nó sẽ được sử dụng) so với chi phí mua vàDuy trì phần mềm.

Application Service Provider

Bản chất ASP là một công ty cung cấp phần mềm của nó cho công ty khác sử dụng có tính phí. Phần mềm đó không được mua mà chỉ có cơ hội được sử dụng nó. Nhà cung cấp  giữ quyền sở hữu phần mềmvà khách hàng phải trả cho nó "per use". Khi một tổ chức sử dụng phần mềm EDC theo mô hình ASP, phần mềm nó sẽ nằm trên phần cứng của nhà cung cấp và dưới thẩm quyển của nhà cung cấp. Khách hàng sẽ truy cập thông qua browser hoặc là phầm mềm khách hàng khác do nhà cung cấp đưa.

Khuyến khích sponsor áp dụng hệ thống EDC sử dụng mô hình ASP, cái mà triển khai, lưu trữ và xác minh phần mềm cũng như nâng cấp hay bảo trì hoặc là hỗ trợ là do nhà cung cấp làm. Một cách tiếp cận dựa trên rủi ro nên được sử dụng để xác định phạm vi vàĐộ sâu của bất kỳ xác nhận phần mềm tài trợ bổ sung để được thực hiện. Cấu trúc về giá của ASP được tính trên tất cả các issues phải được xem xét và bởi vì giá của ASP trên mỗi nghiên cứu thường cao hơn việc chuyển giao một công nghệ hoặc hiểu biết về hệ thống




  • No labels