Mô hình tự cập nhật: thách thức với khung phê duyệt truyền thống

Khung quản lý thiết bị y tế được xây dựng cho sản phẩm vật lý: một cái máy được phê duyệt, rồi nó giữ nguyên đặc tính cho tới khi có thay đổi thiết kế được đăng ký.

Phần mềm đã làm khung này căng ra. Mô hình có khả năng học tiếp làm nó căng hơn nữa.

Vấn đề

Nếu một mô hình được phê duyệt ở trạng thái A, rồi học tiếp từ dữ liệu mới và trở thành trạng thái B — phê duyệt có còn áp dụng không?

Nếu trả lời "không", thì mọi cập nhật đều cần xin phép lại, và ưu thế của việc học liên tục bị vô hiệu.

Nếu trả lời "có" một cách vô điều kiện, thì phê duyệt mất ý nghĩa vì sản phẩm sau có thể khác hẳn sản phẩm đã được đánh giá.

Cách tiếp cận đang hình thành

Hướng đi chung của các cơ quan quản lý là yêu cầu nhà sản xuất mô tả trước phạm vi thay đổi được phép — thường được gọi là kế hoạch kiểm soát thay đổi được phê duyệt trước.

Nội dung điển hình của một kế hoạch như vậy:

Loại thay đổi được phép

• Huấn luyện lại trên dữ liệu mới cùng loại?
• Điều chỉnh ngưỡng vận hành?
• Thêm loại dữ liệu đầu vào mới?
• Mở rộng sang quần thể mới?

Các loại này có mức rủi ro rất khác nhau. Hai loại đầu thường được phép trong kế hoạch; hai loại sau thường cần đánh giá lại.

Phạm vi thay đổi

Hiệu năng không được giảm quá ngưỡng nào, các đặc tính nào phải giữ nguyên.

Quy trình kiểm chứng

Mỗi phiên bản mới phải qua kiểm định nào trước khi đưa vào sử dụng.

Cơ chế thông báo

Thông báo cho ai, khi nào, với nội dung gì.

Cơ chế quay lui

Nếu phiên bản mới có vấn đề, quay về phiên bản trước thế nào.

Các loại thay đổi và mức rủi ro

Dòng thứ ba đáng chú ý: điều chỉnh ngưỡng nghe như thay đổi nhỏ nhưng nó làm thay đổi trực tiếp số lượng cảnh báo và tỷ lệ bỏ sót — tức thay đổi hành vi thực tế của hệ thống.

Trách nhiệm của cơ sở sử dụng

Đây là phần mà nhiều cơ sở chưa chuẩn bị.

Yêu cầu được thông báo trước

Nên đưa vào hợp đồng: nhà cung cấp phải thông báo trước mọi cập nhật, kèm mô tả nội dung thay đổi và tác động dự kiến.

Cập nhật lặng lẽ là tình huống cần tránh: người dùng thấy hệ thống hành xử khác mà không biết vì sao.

Ghi lại phiên bản

Mọi kết quả do hệ thống tạo ra nên được ghi kèm phiên bản mô hình đang chạy tại thời điểm đó.

Lý do thực tế: khi cần rà soát một quyết định trong quá khứ, phải tái dựng được bối cảnh — hệ thống lúc đó nói gì và dựa trên phiên bản nào.

Đánh giá lại sau cập nhật

Với cập nhật đáng kể, cần có giai đoạn kiểm trên dữ liệu của chính cơ sở trước khi dùng cho quyết định lâm sàng.

Quyền từ chối cập nhật

Cơ sở nên có quyền giữ phiên bản hiện tại trong một khoảng thời gian để đánh giá, thay vì bị buộc cập nhật tự động.

Đây là điểm cần thoả thuận trước — nhiều hợp đồng phần mềm mặc định cập nhật tự động.

Vấn đề học tại chỗ

Một biến thể phức tạp hơn: mô hình học tiếp từ dữ liệu của chính cơ sở đang dùng.

Ưu điểm: thích nghi với quần thể và thiết bị tại chỗ.

Nhưng nó tạo ra tình huống mà mỗi cơ sở có một mô hình khác nhau, và không cơ sở nào giống phiên bản đã được phê duyệt.

Các câu chưa có lời giải gọn:

• Ai chịu trách nhiệm về hiệu năng của phiên bản đã thích nghi?
• Nhà sản xuất còn trách nhiệm tới đâu?
• Nếu dữ liệu tại chỗ có vấn đề, mô hình học phải cái sai thì sao?
• Làm sao phát hiện sự trôi dần khi không có chuẩn so sánh?

Trong thực tế hiện nay, phần lớn triển khai chọn cách an toàn: mô hình cố định, cập nhật theo phiên bản có kiểm soát.

Điều nên đưa vào hợp đồng

• Nghĩa vụ thông báo trước khi cập nhật, kèm nội dung thay đổi.
• Quyền của cơ sở được giữ phiên bản hiện tại trong thời gian đánh giá.
• Cam kết cung cấp dữ liệu hiệu năng của phiên bản mới.
• Cơ chế quay lui phiên bản.
• Nghĩa vụ thông báo khi phát hiện vấn đề ở phiên bản đang dùng.
• Lưu trữ lịch sử phiên bản đủ lâu cho mục đích rà soát.

Mục cuối quan trọng với các tranh chấp có thể phát sinh nhiều năm sau — và nó thường không có trong hợp đồng chuẩn của nhà cung cấp.

Câu hỏi thường gặp