Nền tảng quản lý dữ liệu sức khỏe tổng hợp dữ liệu thế nào?

Điểm quan trọng là “tổng hợp” không đồng nghĩa với cộng tất cả dữ liệu vào một cơ sở dữ liệu. Một bản ghi nhịp tim từ đồng hồ, một giá trị cân nặng từ cân thông minh và một kết quả xét nghiệm từ bệnh viện khác nhau về nguồn, độ chính xác, đơn vị, tần suất và mức độ tin cậy. Vì vậy, nền tảng cần cả lớp kết nối, lớp chuẩn hóa, cơ chế đồng bộ, quản lý danh tính, kiểm soát chất lượng và quản trị quyền truy cập.

Dữ liệu từ nhiều thiết bị đi vào nền tảng qua những đường nào?

Dữ liệu sức khỏe có thể đến nền tảng qua nhiều tầng trung gian. Với thiết bị đeo hoặc cảm biến gần người dùng, thiết bị thường truyền dữ liệu đến điện thoại hoặc một gateway bằng kết nối không dây như Bluetooth Low Energy. Ứng dụng trên điện thoại nhận dữ liệu, bổ sung thông tin thiết bị và thời gian rồi đồng bộ tiếp lên dịch vụ đám mây.

Một mô hình khác là thiết bị đồng bộ với máy chủ của chính nhà sản xuất. Khi đó nền tảng quản lý dữ liệu sức khỏe không cần kết nối trực tiếp tới thiết bị mà tích hợp với API của nhà cung cấp. Sau khi người dùng cấp quyền, nền tảng lấy các bản ghi cần thiết từ dịch vụ đó theo phạm vi cho phép.

Điện thoại cũng có thể đóng vai trò trung tâm trung gian. Các ứng dụng và thiết bị tương thích có thể ghi dữ liệu vào kho sức khỏe của hệ điều hành, chẳng hạn HealthKit trong hệ sinh thái Apple hoặc Health Connect trên Android. Một ứng dụng được cấp quyền phù hợp có thể đọc các loại dữ liệu được phép thay vì phải xây dựng kết nối riêng với từng thiết bị.

Trong môi trường chăm sóc y tế, một đường dữ liệu khác xuất phát từ hồ sơ sức khỏe điện tử, phòng xét nghiệm hoặc hệ thống bệnh viện. Lớp tích hợp có thể sử dụng các API và mô hình trao đổi dữ liệu y tế như HL7 FHIR. FHIR phù hợp với việc biểu diễn và trao đổi những đối tượng như Patient, Observation, Device hay Provenance; nó không phải giao thức thay thế Bluetooth dùng để lấy tín hiệu trực tiếp từ cảm biến.

Vì vậy, một nền tảng có thể đồng thời duy trì nhiều connector: connector cho thiết bị, connector cho kho sức khỏe của điện thoại, connector cho API nhà sản xuất và connector cho hệ thống y tế. Các connector khác nhau ở cách lấy dữ liệu nhưng đều phải chuyển dữ liệu về một quy trình xử lý thống nhất phía sau.

Nền tảng chuẩn hóa dữ liệu khác định dạng ra sao?

Nhận được dữ liệu mới chỉ giải quyết vấn đề kết nối. Nếu lưu nguyên trạng mọi bản ghi, nền tảng vẫn có một tập dữ liệu phân mảnh vì cùng một chỉ số có thể được các nguồn đặt tên, định dạng hoặc biểu diễn khác nhau.

Lớp chuẩn hóa trước hết phải xác định bản ghi đại diện cho khái niệm nào. “Heart rate”, “pulse” hoặc một mã riêng của nhà sản xuất có thể cùng chỉ một loại quan sát nhịp tim. Hệ thống ánh xạ những cách biểu diễn này sang mô hình dữ liệu nội bộ hoặc một thuật ngữ chuẩn để các ứng dụng phía sau hiểu chúng theo cùng một nghĩa.

Đơn vị cũng phải được xử lý độc lập với giá trị. Đường huyết chẳng hạn có thể được biểu diễn bằng mg/dL hoặc mmol/L. Nếu hai bản ghi được đưa vào cùng chuỗi dữ liệu mà không kèm đơn vị hoặc không chuyển đổi đúng, phép so sánh sẽ sai dù từng giá trị ban đầu đều hợp lệ. Các hệ thống y tế có thể sử dụng hệ thống đơn vị như UCUM để biểu diễn đơn vị theo cách máy có thể xử lý nhất quán.

Thời gian là một lớp chuẩn hóa khác. Nền tảng thường cần phân biệt thời điểm sự kiện thực sự diễn ra với thời điểm bản ghi được thiết bị lưu, gửi hoặc được máy chủ tiếp nhận. Điều này đặc biệt quan trọng khi thiết bị hoạt động ngoại tuyến rồi đồng bộ hàng loạt vài giờ sau. Nếu chỉ dùng thời gian máy chủ nhận dữ liệu, toàn bộ chuỗi thời gian có thể bị đặt sai vị trí.

Sau chuẩn hóa, một bản ghi không chỉ còn là một cặp “chỉ số – giá trị”. Nó thường cần chứa loại dữ liệu, giá trị, đơn vị, thời điểm quan sát, người sở hữu, thiết bị hoặc ứng dụng nguồn và thông tin cần thiết để truy vết bản ghi.

Hệ thống biết dữ liệu nào thuộc cùng một người và tránh ghi trùng thế nào?

Tổng hợp dữ liệu chỉ có ý nghĩa khi nền tảng xác định đúng bản ghi thuộc về ai. Một người có thể đăng nhập một ứng dụng bằng tài khoản riêng, dùng đồng hồ với tài khoản của nhà sản xuất và đồng thời có mã bệnh nhân trong bệnh viện. Những định danh này không tự nhiên giống nhau.

Lớp quản lý danh tính phải thiết lập quan hệ giữa tài khoản trên nền tảng và các nguồn đã được người dùng liên kết. Trong tích hợp với hệ thống lâm sàng, quá trình đối sánh còn phải thận trọng hơn vì gắn dữ liệu của hai người khác nhau vào cùng hồ sơ là lỗi nghiêm trọng hơn việc tạm thời giữ chúng tách biệt.

Một vấn đề khác là cùng một sự kiện có thể đến qua nhiều đường. Ví dụ, đồng hồ gửi dữ liệu cho ứng dụng của nhà sản xuất; ứng dụng ghi dữ liệu đó vào kho sức khỏe trên điện thoại; nền tảng lại kết nối cả API của nhà sản xuất lẫn kho sức khỏe. Nếu coi hai bản ghi là hai phép đo độc lập, hệ thống có thể đếm cùng dữ liệu hai lần.

Do đó, nền tảng cần giữ provenance, tức thông tin về nguồn gốc dữ liệu, cùng các định danh nguồn, thời điểm và thuộc tính liên quan. Cơ chế chống trùng có thể đối chiếu ID bản ghi của nguồn hoặc một tập thuộc tính đủ mạnh để nhận ra lần đồng bộ tiếp theo chỉ là bản ghi đã tồn tại.

Không phải mọi giá trị giống nhau đều được phép gộp. Hai thiết bị có thể thực sự ghi nhận cùng một chỉ số vào cùng thời điểm. Vì vậy deduplication phải dựa vào nguồn gốc và danh tính bản ghi chứ không chỉ dựa vào việc giá trị bằng nhau. Khi dữ liệu xung đột, nền tảng cũng không nên tùy ý chọn số “đẹp hơn”; quy tắc ưu tiên phải dựa trên loại dữ liệu, nguồn, thời điểm, trạng thái bản ghi và mục đích sử dụng.

Đồng bộ dữ liệu mới và dữ liệu cũ được kiểm soát như thế nào?

Các nguồn sức khỏe hiếm khi đồng bộ với cùng nhịp. Một cảm biến có thể gửi liên tục, một ứng dụng chỉ đồng bộ khi được mở, còn API đám mây có thể cung cấp dữ liệu theo từng khoảng thời gian. Vì vậy nền tảng phải xử lý cả dữ liệu thời gian gần thực và dữ liệu đến muộn.

Thay vì tải lại toàn bộ lịch sử sau mỗi lần kết nối, hệ thống thường cần lưu trạng thái đồng bộ cho từng nguồn. Lần tiếp theo, connector chỉ yêu cầu những dữ liệu mới hoặc những bản ghi đã thay đổi kể từ mốc trước đó. Nếu nguồn hỗ trợ webhook hoặc cơ chế thông báo thay đổi, nền tảng có thể nhận tín hiệu để lấy dữ liệu sớm hơn thay vì liên tục truy vấn.

Quá trình ghi dữ liệu cũng cần có tính idempotent: cùng một sự kiện được gửi lại nhiều lần không được tự động tạo thành nhiều bản ghi tương đương. Đây là yêu cầu thực tế vì mạng có thể gián đoạn, ứng dụng có thể gửi lại request và các job đồng bộ có thể được chạy lại sau lỗi.

Dữ liệu đến muộn còn đặt ra yêu cầu đối với thứ tự thời gian. Một phép đo thực hiện lúc 08:00 nhưng được đồng bộ lúc 12:00 phải được đặt vào chuỗi quan sát theo thời điểm 08:00 nếu đó là thời điểm đo có giá trị chuyên môn. Thời điểm 12:00 vẫn hữu ích nhưng mang ý nghĩa về quá trình tiếp nhận, không thay thế thời điểm sự kiện.

Nhờ tách hai khái niệm này, nền tảng có thể xây dựng lịch sử sức khỏe theo diễn biến thực tế thay vì theo thứ tự các máy chủ tình cờ nhận dữ liệu.

Quyền truy cập và bảo mật được đặt ở đâu trong quá trình tổng hợp?

Nền tảng không nên xem quyền truy cập là bước kiểm tra sau khi dữ liệu đã được gom về. Quyền phải được áp dụng ngay từ lúc kết nối nguồn: ứng dụng nào được đọc loại dữ liệu nào, trong khoảng quyền nào và dưới danh tính nào.

Với dịch vụ bên ngoài, cơ chế cấp quyền thường cho phép người dùng ủy quyền mà không phải cung cấp mật khẩu của dịch vụ nguồn cho nền tảng tích hợp. Các giao thức như OAuth 2.0 được dùng phổ biến cho mô hình ủy quyền này; trong các kiến trúc cần xác thực danh tính, OpenID Connect có thể bổ sung lớp nhận dạng trên nền OAuth.

Bên trong hệ thống, kiểm soát tiếp tục ở cấp lưu trữ và sử dụng. Dữ liệu nhạy cảm cần được bảo vệ khi truyền và khi lưu, quyền đọc hoặc chỉnh sửa phải giới hạn theo vai trò và mục đích, còn những thao tác quan trọng cần có audit trail để truy vết ai đã truy cập hoặc thay đổi dữ liệu.

Provenance và audit trail phục vụ hai mục đích khác nhau. Provenance trả lời “bản ghi này đến từ đâu và được tạo như thế nào”, trong khi audit trail trả lời “ai hoặc hệ thống nào đã thực hiện hành động gì đối với dữ liệu”. Một nền tảng tổng hợp nhiều nguồn cần cả hai nếu muốn duy trì khả năng truy vết từ dữ liệu đã chuẩn hóa về nguồn ban đầu.

Việc dữ liệu đã nằm trong cùng một nền tảng cũng không có nghĩa mọi ứng dụng được phép nhìn thấy toàn bộ hồ sơ. Phạm vi quyền vẫn phải được áp dụng theo từng loại dữ liệu và mục đích sử dụng.

Khi nào dữ liệu từ nhiều nguồn thực sự trở thành một hồ sơ thống nhất?

Một kho dữ liệu lớn chưa chắc đã là hồ sơ sức khỏe thống nhất. Dữ liệu chỉ thực sự có thể được sử dụng chung khi hệ thống giữ được ít nhất bốn quan hệ: bản ghi thuộc người nào, biểu diễn chỉ số gì, xảy ra khi nào và đến từ nguồn nào.

Trên nền đó, hệ thống mới có thể xây dựng một dòng thời gian trong đó dữ liệu từ đồng hồ, cân, ứng dụng hoặc hệ thống y tế được truy vấn bằng cùng mô hình. Ứng dụng phía trên không cần biết từng nhà sản xuất đã đặt tên trường dữ liệu như thế nào; nó làm việc với lớp dữ liệu đã được chuẩn hóa và vẫn có thể truy ngược về nguồn khi cần.

Chất lượng của hồ sơ vì thế phụ thuộc không chỉ vào số lượng connector mà còn vào độ đầy đủ, độ mới, tính nhất quán và provenance của dữ liệu. Một nguồn ngừng đồng bộ có thể tạo khoảng trống. Một thiết bị bị tháo khỏi người dùng có thể tạo dữ liệu không đại diện cho trạng thái sức khỏe. Một chỉ số do thiết bị tiêu dùng đo cũng không mặc nhiên tương đương kết quả từ thiết bị y tế hoặc xét nghiệm lâm sàng chỉ vì chúng được hiển thị cạnh nhau.

Đây là giới hạn quan trọng của quá trình tổng hợp: chuẩn hóa định dạng giúp các hệ thống trao đổi và xử lý dữ liệu nhất quán, nhưng không tự động làm cho mọi nguồn có cùng độ chính xác hoặc cùng giá trị lâm sàng. Nền tảng cần giữ metadata về nguồn và điều kiện đo để ứng dụng sử dụng dữ liệu theo đúng ngữ cảnh.

Một nền tảng quản lý dữ liệu sức khỏe tổng hợp nhiều thiết bị bằng cách xây dựng một chuỗi xử lý thay vì một kết nối duy nhất: tiếp nhận dữ liệu từ thiết bị, ứng dụng, dịch vụ đám mây hoặc hệ thống y tế; chuẩn hóa khái niệm, đơn vị và thời gian; gắn dữ liệu với đúng người; giữ nguồn gốc; loại bản ghi trùng; đồng bộ thay đổi; rồi áp dụng quyền truy cập và kiểm soát bảo mật.

Giá trị của nền tảng nằm ở khả năng biến nhiều nguồn không đồng nhất thành một hồ sơ có thể truy vấn thống nhất mà vẫn bảo toàn provenance. Khi lớp nguồn gốc, danh tính hoặc ngữ cảnh đo bị mất, dữ liệu có thể trông “đã được hợp nhất” trên giao diện nhưng chưa đủ đáng tin cậy để được diễn giải như một chuỗi sức khỏe duy nhất.

:::