Kết quả nhiệm vụ nghiên cứu khoa học và công nghệ hệ thống hỗ trợ thu thập và trực quan hóa thông tin sức khỏe ứng dụng giám sát thai phụ đái tháo đường thai kỳ

ỦY BAN NHÂN DÂN BỘ CÔNG THƯƠNG THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP SỞ KHOA HỌC VÀ CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH CHƯƠNG TRÌNH KHOA HỌC VÀ CÔNG NGHỆ CẤP THÀNH PHỐ BÁO CÁO TỔNG HỢP KẾT QUẢ[.]

ỦY BAN NHÂN DÂN BỘ CÔNG THƯƠNG

THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP

SỞ KHOA HỌC VÀ CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH

CHƯƠNG TRÌNH KHOA HỌC VÀ CÔNG NGHỆ CẤP THÀNH PHỐ

BÁO CÁO TỔNG HỢP

KẾT QUẢ NHIỆM VỤ NGHIÊN CỨU KHOA HỌC VÀ CÔNG NGHỆ

HỆ THỐNG HỖ TRỢ THU THẬP VÀ TRỰC QUAN HÓA THÔNG TIN SỨC KHỎE: ỨNG DỤNG GIÁM SÁT THAI PHỤ ĐÁI THÁO

ĐƯỜNG THAI KỲ

Cơ quan chủ trì nhiệm vụ: Trường Đại Học Công Nghiệp

Thành Phố Hồ Chí Minh Chủ nhiệm nhiệm vụ: PGS.TS Huỳnh Trung Hiếu

ThS.BS Phạm Ngọc Đoan Trang

Thành phố Hồ Chí Minh – 12/2020

ỦY BAN NHÂN DÂN BỘ CÔNG THƯƠNG

THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHIỆP

SỞ KHOA HỌC VÀ CÔNG NGHỆ THÀNH PHỐ HỒ CHÍ MINH

CHƯƠNG TRÌNH KHOA HỌC VÀ CÔNG NGHỆ CẤP THÀNH PHỐ

BÁO CÁO TỔNG HỢP KẾT QUẢ NHIỆM VỤ NGHIÊN CỨU KHOA HỌC VÀ CÔNG NGHỆ

HỆ THỐNG HỖ TRỢ THU THẬP VÀ TRỰC QUAN HÓA THÔNG TIN SỨC KHỎE: ỨNG DỤNG GIÁM SÁT THAI PHỤ

ĐÁI THÁO ĐƯỜNG THAI KỲ (Đã chỉnh sửa theo kết luận của Hội đồng nghiệm thu ngày 26.11.20)

Chủ nhiệm nhiệm vụ:

PGS.TS Huỳnh Trung Hiếu ThS.BS Phạm Ngọc Đoan Trang

Cơ quan quản lý Cơ quan chủ trì nhiệm vụ

TS Phan Hồng Hải

Thành phố Hồ Chí Minh- 12/2020

Thành phố Hồ Chí Minh, ngày tháng năm 2020

BÁO CÁO THỐNG KÊ KẾT QUẢ THỰC HIỆN NHIỆM VỤ NGHIÊN CỨU KH&CN

I THÔNG TIN CHUNG

1 Tên nhiệm vụ: Hệ thống hỗ trợ thu thập và trực quan hóa thông tin sức khỏe: ứng dụng giám sát thai phụ đái tháo đường thai kỳ

Thuộc: Chương trình/lĩnh vực (tên chương trình/lĩnh vực): Công Nghệ Thông Tin

2 Chủ nhiệm nhiệm vụ:

Họ và tên: Huỳnh Trung Hiếu

Ngày, tháng, năm sinh: 20/07/1975 Nam/ Nữ: Nam

Học hàm, học vị: PGS.TS

Chức danh khoa học: Chức vụ: Trưởng khoa

Điện thoại: Tổ chức: 0283.8940 390 Nhà riêng: Mobile: 0942682608 Fax: 0283.9940 954 E-mail: hthieu@ieee.org

Tên tổ chức đang công tác: Trường Đại học Công Nghiệp Thành phố Hồ Chí Minh Địa chỉ tổ chức: 12 Nguyễn Văn Bảo, Q Gò Vấp, TP HCM

Địa chỉ nhà riêng: 290/30/9 HT17, P Hiệp Thành, Q 12, Tp HCM

Địa chỉ: 12 Nguyễn Văn Bảo, Q Gò Vấp, TP HCM

Họ và tên thủ trưởng tổ chức: TS Phan Hồng Hải

Số tài khoản: 3713.0.1056923

Kho bạc: Kho bạc Nhà Nước Gò vấp

Tên cơ quan chủ quản đề tài: Trường Đại học Công Nghiệp Thành phố Hồ Chí Minh

II TÌNH HÌNH THỰC HIỆN

1 Thời gian thực hiện nhiệm vụ:

- Theo Hợp đồng đã ký kết: từ tháng 11 năm 2018 đến tháng 5 năm 2020

- Thực tế thực hiện: từ tháng 11 năm 2018 đến tháng 11 năm 2020

- Được gia hạn (nếu có):

- Lần 1 từ tháng 6 năm 2020 đến tháng 11 năm 2020

2 Kinh phí và sử dụng kinh phí:

a) Tổng số kinh phí thực hiện: 1.200 tr.đ, trong đó:

Thời gian

(Tháng, năm)

Kinh phí (Tr.đ)

Thời gian (Tháng, năm)

Kinh phí (Tr.đ)

c) Kết quả sử dụng kinh phí theo các khoản chi:

Đối với đề tài:

- Lý do thay đổi (nếu có):

3 Các văn bản hành chính trong quá trình thực hiện đề tài/dự án:

(Liệt kê các quyết định, văn bản của cơ quan quản lý từ công đoạn xét duyệt, phê duyệt kinh phí, hợp đồng, điều chỉnh (thời gian, nội dung, kinh phí thực hiện nếu có); văn bản của tổ chức chủ trì nhiệm

vụ (đơn, kiến nghị điều chỉnh nếu có)

Số

TT

Số, thời gian ban hành

Nội dung tham gia chủ yếu

Sản phẩm chủ yếu đạt

1 Bệnh viện Hùng Vương Bệnh viện Hùng Vương Triển khai thử nghiệm hệ

thống

Báo cáo đánh giá

2

- Lý do thay đổi (nếu có):

5 Cá nhân tham gia thực hiện nhiệm vụ:

(Người tham gia thực hiện đề tài thuộc tổ chức chủ trì và cơ quan phối hợp, không quá 10 người

Nội dung tham gia chính

Sản phẩm chủ yếu đạt được

Ghi chú*

1 PGS.TS Huỳnh Trung Hiếu PGS.TS Huỳnh Trung Hiếu Tất cả Báo cáo

2 ThS.BS Phạm Ngọc Đoan

Trang

ThS.BS Phạm Ngọc Đoan Trang Tất cả Báo cáo

3 ThS Lê Trọng Ngọc ThS Lê Trọng Ngọc Tất cả Báo cáo

5 BS.CK1.Ngô Thanh Hà BS.CK1.Ngô Thanh Hà 3,4 Báo cáo

6 ThS Hồ Đắc Quán ThS Hồ Đắc Quán 1,2 Module phần mềm

7 TS Phạm Thị Thiết TS Phạm Thị Thiết 1, 2 Module phần mềm

8 ThS Nguyễn Thị Phi Loan ThS Nguyễn Thị Phi Loan 1, 2, 3 Module phần mềm

9 ThS Võ Quang Hoàng Khang ThS Võ Quang Hoàng Khang 2, 3 Module phần mềm

10 KS Nguyễn Thành Danh KS Nguyễn Thành Danh 3, 4 Báo cáo

11 Thanh Hồng KS Bùi Thị KS Bùi Thị Thanh Hồng 3, 4 Báo cáo

- Lý do thay đổi ( nếu có):

- Lý do thay đổi (nếu có):

7 Tình hình tổ chức hội thảo, hội nghị:

- Lý do thay đổi (nếu có):

8 Tóm tắt các nội dung, công việc chủ yếu:

(Nêu tại mục 15 của thuyết minh, không bao gồm: Hội thảo khoa học, điều tra khảo sát trong nước và nước ngoài)

Theo kế hoạch Thực tế đạt được

1 Khảo sát các hệ thống hỗ trợ thu thập và trực quan hóa dữ liệu

trong y tế

11-12/2018 11-12/2018 Hiếu, Đoan Trang, Trọng

Ngọc, Khánh

Trang, Quán, Thiết, Phi Loan

2

Thiết kế và hiện thực hệ thống hỗ

trợ thu thập thông tin y tế và trực

quan hóa dữ liệu thu thập

10/2019

12/2018- 8/2019

11/2018-Hiếu, Đoan Trang, Trọng Ngọc, Quán, Thiết, Phi Loan, Hoàng Khang

3

Triển khai hệ thống thu thập dữ

liệu đối với bệnh nhân đái tháo

đường thai kỳ

3/2020 11/2019-9/2020

11/2019-Hiếu, Đoan Trang, Trọng Ngọc, Khánh Trang, Thanh

Hà, Hồng, Danh, Phi Loan, Khang

4 Đánh giá mức độ tuân thủ chỉ định của bệnh nhân 2-4/2020 2-9/2020

Hiếu, Đoan Trang, Trọng Ngọc, Khánh Trang, Thanh

Hà, Hồng, Danh

5 Báo cáo, chỉnh sửa lỗi 3-4/2020 9-10/2020 Hiếu, Đoan Trang, Trọng

Ngọc

- Lý do thay đổi (nếu có):

III SẢN PHẨM KH&CN CỦA NHIỆM VỤ

1 Sản phẩm KH&CN đã tạo ra:

1 Tài liệu kỹ thuật Chi tiết, rõ ràng Chi tiết, rõ ràng

2 Tài liệu hướng dẫn sử dụng và khai thác hệ thống Chi tiết, rõ ràng Chi tiết, rõ ràng

3 Hệ thống phần mềm

Đầy đủ các nội dung thể hiện được các mục tiêu mà đề tài đã

đặt ra

Đầy đủ các nội dung thể hiện được các mục tiêu mà đề tài đã

đặt ra

4 Báo cáo kết quả triển khai tại Chi tiết, rõ ràng Chi tiết, rõ ràng

một bệnh viện hoặc cơ sở y

Yêu cầu khoa học

2

- Lý do thay đổi (nếu có):

d) Kết quả đào tạo:

Theo kế hoạch Thực tế đạt

được

- Lý do thay đổi (nếu có):

đ) Tình hình đăng ký bảo hộ quyền sở hữu công nghiệp:

Theo

kế hoạch đạt được Thực tế

2

- Lý do thay đổi (nếu có):

e) Thống kê danh mục sản phẩm KHCN đã được ứng dụng vào thực tế

2 Đánh giá về hiệu quả do nhiệm vụ mang lại:

a) Hiệu quả về khoa học và công nghệ:

(Nêu rõ danh mục công nghệ và mức độ nắm vững, làm chủ, so sánh với trình độ công nghệ

so với khu vực và thế giới…)

Lĩnh vực khoa học và công nghệ liên quan đến đề tài là ứng dụng Công nghệ thông tin trong y khoa Hiện nay, nghiên cứu và phát triển ứng dụng CNTT vào y tế đang là một thách thức được đầu tư bởi nhiều nhà nghiên cứu trong và ngoài nước

Việc nghiên cứu đề tài này cũng sẽ làm nền tảng để phát triển các nghiên cứu tiếp theo trong y tế nhằm nâng cao hiệu quả chẩn đoán và điều trị, đáp ứng nhu cầu phát triển các dịch

vụ CNTT cho thành phố, hướng tới xây dựng một thành phố thông minh

So với các sản phẩm tương tự, sản phẩm đề tài đã khai thác những điểm mạnh của các công nghệ hiện đại, bao gồm kubernetes, microservice, Json, trực quan hóa trên nền Web, Oauthen2, v.v Điều này tăng khả năng tích hợp, mở rộng, bảo mật, xác thực, phân quyền Tăng khả năng mở rộng triển khai, ứng dụng ở các đơn vị khác

b) Hiệu quả về kinh tế xã hội:

(Nêu rõ hiệu quả làm lợi tính bằng tiền dự kiến do nhiệm vụ tạo ra so với các sản phẩm cùng loại trên thị trường…)

Những thành tựu về ứng dụng CNTT đã và đang có những đóng góp to lớn cho sự phát triển của nhiều lĩnh vực khác nhau trong đó bao gồm cả giáo dục và y tế, phục vụ cho thành phố, hướng tới xây dựng thành phố thông minh

Hiện tại có một số sản phẩm hỗ trợ việc thu thập dữ liệu, tuy nhiên với nhu cầu số hóa dữ liệu, thu thập và phân tích dữ liệu trong các môi trường, ứng dụng khác nhau, các hệ thống hiện tại vẫn còn những hạn chế nhất định

Sản phẩm khi hoàn thành sẽ giúp các chuyên gia thực hiện các dự án nghiên cứu có yêu cầu thu thập, phân tích và theo dõi diễn tiến thay đổi của các chỉ số sức khỏe ở các dạng trực quan khác nhau

3 Tình hình thực hiện chế độ báo cáo, kiểm tra của nhiệm vụ:

I Báo cáo tiến độ

Lần 2 20/04/2020 Đồng ý cho gia hạn đề hoàn thành hướng dẫn xong Thạc

Mục lục

Mục lục 1

Danh mục các ký hiệu, các chữ viết tắt 5

Danh mục các bảng 6

Danh mục các hình vẽ, đồ thị 7

MỞ ĐẦU 10

1 Mục tiêu nghiên cứu 10

2 Tính cấp thiết và Tình hình nghiên cứu 10

Hệ thống Catalyst: 12

OpenClinica: 13

REDCap: 15

3 Các kiến trúc và công nghệ chính sẽ được sử dụng 16

3.1 Microservices 16

3.2 gRPC 17

3.3 Kiến trúc củ hành (Go-Kit) 19

3.4 Kubernetes 19

3.5 NodeJS 21

3.6 Angular 22

3.7 ChartJS 23

3.8 Một số công nghệ khác 23

Chương 1 TỔNG QUAN HỆ THỐNG 25

1.1 SƠ LƯỢC HỆ THỐNG ĐỀ XUẤT 25

1.2 CÁC YÊU CẦU HỆ THỐNG 26

1.2.1 Yêu cầu chức năng 26

1.2.2 Yêu cầu phi cức năng 27

1.3 SƠ ĐỒ TỔNG QUÁT HỆ THỐNG 28

1.4 MỘT SỐ CHỨC NĂNG CƠ BẢN 32

1.5 TỔ CHỨC CƠ SỞ DỮ LIỆU CỦA HỆ THỐNG 35

Chương 2 THIẾT KẾ PHÍA FRONT-END 40

2.1 TỔNG QUAN HỆ THỐNG 40

2.2 MỘT SỐ TÍNH NĂNG LIÊN QUAN ĐẾN DỰ ÁN 42

2.1.1 Tạo dự án 42

2.1.2 Quản lý thông tin dự án 43

2.1.3 Thêm site từ hệ thống vào dự án 44

2.1.4 Thêm site mới vào dự án 45

2.2 CẤU HÌNH THU THẬP DỮ LIỆU 47

2.2.1 Yêu cầu 47

2.2.2 Chức năng liên quan đến Form 48

2.2.3 Chức năng liên quan đến Section 51

2.2.4 Chức năng liên quan đến Field 53

2.2.5 Logic branching 54

2.2.6 Các model dữ liệu hỗ trợ cấu hình 55

2.2.7 Các component tạo cấu trúc form 60

2.2.8 Tạo cấu hình Section 63

2.3 TRỰC QUAN HÓA DỮ LIỆU 63

2.3.1 Yêu cầu 63

2.3.2 Use case và các sơ đồ cấu hình trực quan hóa 65

2.3.2 Sơ đồ lớp 75

2.3.2 Load dữ liệu cho các Chart 77

2.4 CẤU HÌNH THU THẬP QUA SMS 87

2.5 CẤU HÌNH REMINDER 87

2.5.1 Template reminder 89

2.5.2 Nhắc nhở cá nhân (Personal reminder hay Reminder) 94

2.6 QUẢN TRỊ NHÓM VÀ THÔNG TIN CÁ NHÂN 99

2.7 XỬ LÝ RECORD 100

2.7.1 Nhập dữ liệu qua web/internet/SMS 100

2.7.2 Import dữ liệu từ file 103

2.7.3 View và export dữ liệu 107

Chương 3 THIẾT KẾ PHÍA BACK-END 112

3.1 Tổng quan kiến trúc 112

3.2 Collector Service 114

3.2.1 Các chức năng chính 114

3.2.2 Các sơ đồ Sequence 115

3.2.3 Sơ đồ Cơ sở dữ liệu 119

3.3 Identity service 122

3.4 SMS service 123

3.4.1 Tổng quan 123

3.4.2 Các sơ đồ chức năng 124

Chương 4 XÁC THỰC, PHÂN QUYỀN VÀ QUẢN LÝ ĐỊNH DANH 126

4.1 Tổng quan 126

4.2 Các luồng chính được sử dụng trong IoH 128

4.3 Access token 131

4.3.1 Authorization code và yêu cầu access token 131

4.3.2 Access token response 133

4.3.3 Self-encoded tokens 134

4.3.4 Access token lifetime 135

4.3.5 Refreshing access token 137

4.4 Quản lý định danh 137

4.4.1 Tổng quan 137

4.4.2 Mã hóa và giải mã định danh 138

4.4.3 Chacha20-Poly1305 139

Chương 5 MỘT SỐ TÍNH NĂNG MỞ RỘNG 144

5.1 Đọc chỉ số đường huyết từ bản viết tay 144

5.1.1 Mô tả hệ thống 144

5.1.2 Đánh giá kết quả 147

5.2 Hệ thống hỗ trợ ước lượng khẩu phần ăn (cho bệnh nhân đái tháo đường) 148

5.2.1 Mô tả hệ thống 148

5.2.2 Đánh giá kết quả 150

Chương 6 TRIỂN KHAI HỆ THỐNG VÀ KẾT QUẢ ĐẠT ĐƯỢC 152

6.1 Kiến trúc hệ thống được triển khai 152

6.2 Theo dõi tình trạng thai phụ đái tháo đường thai kỳ 155

a) Bối cảnh lâm sàng 155

b) Khả năng áp dụng hệ thống 158

6.3 Triển khai qui trình lâm sàng có sử dụng IoH 160

6.4 Kết quả triển khai tại đơn vị 162

6.4.1 Đánh giá về mức độ tuân thủ chỉ định 162

6.4.2 Đánh về sử dụng dịch vụ SMS 165

6.4.3 Đánh giá về tính khả dụng của hệ thống IoH 166

6.5 Tác động của sản phẩm 171

a Đối với người dân 171

b Nhân viên y tế 171

c Đối với người nghiên cứu 172

KẾT LUẬN VÀ KIẾN NGHỊ 173

TÀI LIỆU THAM KHẢO 175

PHỤ LỤC Error! Bookmark not defined.

Danh mục các ký hiệu, các chữ viết tắt

16 CTPN Connectionist Text Proposal Network

Danh mục các bảng

Bảng 2 1 API load dữ liệu cho biểu đồ 79

Bảng 2 2 Chức năng các field trong lớp quản lý Chart 82

Bảng 6 1 Tỉ lệ có và không có dữ liệu theo mục đích theo dõi đường huyết hoặc liều thuốc 163

Bảng 6 2 Trung bình (độ lệch chuẩn) số ngày và số lần nhập liệu theo dõi đường huyết ở bệnh nhân có và không có chỉ định nhập dữ liệu theo dõi đường huyết hoặc thuốc ^Chỉ định theo dõi đường huyết hoặc liều thuốc *Khác biệt trung bình giữa 2 nhóm có và không có chỉ định theo dõi có ý nghĩa thống kê (p<0.0001) 164

Bảng 6 3 Trung bình tỉ lệ nhập liệu thực tế so với dự kiến 164

Bảng 6 4 Kết quả đánh giá từ bệnh nhân cho từng câu hỏi 168

Bảng 6 5 Đánh giá của bệnh nhân về tính khả dụng và thao tác (mức 6,7) 168

Bảng 6 6 Kết quả khảo sát từ nhân viên Y tế 170 Bảng 6 7 Đánh giá của nhân viên y tế về tính khả dụng và thao tác (mức 5, 6,7) 170

Danh mục các hình vẽ, đồ thị

Hình 0 1 Hệ thống Catalyst được phát triển bởi đại học Washington 13

Hình 0 2 Đánh giá định tính của hệ thống Catalyst 13

Hình 0 3 Hệ thống hỗ trợ thu thập dữ liệu OpenClinica 14

Hình 0 4 Đánh giá định tính của hệ thống OpenClinica 14

Hình 0 5 Hệ thống hỗ trợ thu thập dữ liệu REDCap 15

Hình 0 6 Đánh giá định tính của hệ thống REDCap 16

Hình 0 7 Minh họa cho kiến trúc microservices (nguồn Internet) 16

Hình 0 8 Kiến trúc lục giác (nguồn Internet) 17

Hình 0 9 Kiến trúc gRPC 18

Hình 0 10 Mô hình containerization (nguồn Internet) 20

Hình 0 11 Luồng xử lý trong NodeJS 22

Hình 0 12 Mô hình binding dữ liệu của AngularJS 22

Hình 0 13 Mô hình tổ chức lớp điều khiển của AngularJS 23

Hình 1 1 Sơ đồ Use case tổng quát 27

Hình 1 2 Các thành phần chính của hệ thống 28

Hình 1 3 Các thành phần hệ thống được nhìn từ phía front-end 29

Hình 1 4 Các thành phần chính của hệ thống 30

Hình 1 5 Chức năng đăng nhập 30

Hình 1 6 Chức năng đăng ký 31

Hình 1 7 Tạo thông tin người dùng trong hệ thống 33

Hình 1 8 Mã hóa thông tin người dùng 33

Hình 1 9 Giải mã thông tin người dùng 34

Hình 1 10 Kiểm tra sự tồn tại email 34

Hình 1 11 Khởi tạo ORM 35

Hình 2 1 Lược đồ Sequence trong Tạo dự án 43

Hình 2 2 Quản lý thông tin dự án 43

Hình 2 3 Use-case tổng quát trong xử lý Form nhập liệu 48

Hình 2 4 Luồng dữ liệu tổng quát 64

Hình 2 5 Use-case tổng quát quá trình cấu hình trực quan hóa 64

Hình 2 6 Sơ đồ lớp 76

Hình 2 7 Data flow diagram 77

Hình 2 8 Render biểu đồ theo cấu hình 78

Hình 2 9 Lọc và merge các record 81

Hình 2 10 Mô hình lớp tương thích với ChartJS 83

Hình 2 11 Cấu hình trục hoành 84

Hình 2 12 Khởi tạo Chart model 85

Hình 2 13 Cấu hình Option 86

Hình 2 14 Use case quản lý template reminder 89

Hình 2 15 Quản lý nhắc nhở cá nhân 95

Hình 2 16 Quản lý nhóm user 99

Hình 2 17 Quản trị thông tin cá nhân 100

Hình 2 18 Import dữ liệu từ file 103

Hình 3 1 Một số đặc tính của Microservice 112

Hình 3 2 Luồng xác thực, phân quyền cho Collector service 115

Hình 3 3 Luồng POST dữ liệu 116

Hình 3 4 Lưu đổ GET dữ liệu 117

Hình 3 5 Lưu đồ PUT dữ liệu 117

Hình 3 6 Lưu đồ delete dữ liệu 118

Hình 3 7 Sơ đồ CSDL 120

Hình 3 8 Lưu trữ định danh người dùng trong Identity service 121

Hình 3 9 Giải mã để lấy thông tin người dùng 122

Hình 3 10 Tìm kiếm một trường dữ liệu định danh 123

Hình 3 11 Sơ đồ tổng quát việc gởi tinn qua SMS 124

Hình 3 12 Sơ đồ xác thực, phân quyền trong việc gởi/nhận SMS 124

Hình 3 13 Gởi SMS 125

Hình 3 14 Nhận SMS 125

Hình 4 1 Các OAuth2 flow và các dịch vụ sử dụng 126

Hình 4 2 Sơ đồ tổng quát 128

Hình 4 3 Luồng xác thực PKCE 129

Hình 4 4 Luồng xác thực Client Credential 130

Hình 4 5 Implicit Flow 131

Hình 4 6 Quản lý định danh người dùng 138

Hình 4 7 Sơ đồ mã hóa dữ liệu 138

Hình 4 8 Sơ đồ giải mã dữ liệu 139

Hình 4 9 Sơ đồ mã hóa dữ liệu ChaCha20-Poly1305 139

Hình 4 10 Mã hóa Payload 140

Hình 4 11 Tạo gói dữ liệu xuất 140

Hình 4 12 Hoạt động ChaCha20 141

Hình 4 13 Tổ chức của Input Words 142

Hình 4 14 Lưu đồ thực hiện của Poly 1305 142

Hình 5 1 Mô hình kiến trúc hỗ trợ thu thập chỉ số đường huyết huyết 144

Hình 5 2 Mẫu ghi chỉ số đường huyết hàng ngày 145

Hình 5 3 Sơ đồ hoạt động 146

Hình 5 4 Chuyển đổi hình ảnh chữ số viết tay và tính Contour 147

Hình 5 5 Mô hình tổng quát xác định khẩu phần ăn 148

Hình 5 6 Kiến trúc mạng trong ước lượng mức năng lượng tiêu thụ 149

Hình 5 7 Quan hệ giữa giá trị đo và giá trị tham khảo 150

Hình 6 1 Các thành phần chính của hệ thống 152

Hình 6 2 Mô hình tổ chức dịch vụ SMS 152

Hình 6 3 Mô hình kết nối các thành phần 153

Hình 6 4 Kiến trúc hệ thống VDAT cluster để vận hành hệ thống IoH 154

Hình 6 5 Kiến trúc VDAT cluster hỗ trợ vận hành IoH 154

Hình 6 6 Lưu đồ theo dõi tình trạng đái tháo đường thai kỳ 156

Hình 6 7 Theo dõi chỉ số đường huyết bệnh nhân 159

Hình 6 8 Qui trình theo dõi đường huyết của bệnh nhân nội trú hiện tại 160

Hình 6 9 Qui trình triển khai cho bệnh nhân sử dụng IoH 160

MỞ ĐẦU

1 Mục tiêu nghiên cứu

Mục tiêu của đề tài là xây dựng hệ thống hỗ trợ thu thập và trực quan hóa thông tin y

tế, giúp theo dõi tình trạng bệnh, nâng cao hiệu quả chẩn đoán và điều trị Để đạt được mục tiêu tổng quát trên, đề tài cần đạt được các mục tiêu cụ thể sau:

- Xây dựng hệ thống hỗ trợ thu thập thông tin y tế và trực quan hóa dữ liêu thu

thập Hệ thống cho phép cấu hình linh động các form nhập liệu với các hình thức khác nhau Đồng thời cấu hình linh động các dạng trực quan hóa cho trường dữ liệu thu thập, quản lý việc nhập liệu và xuất dữ liệu sử dụng trong nghiên cứu khoa học

- Ứng dụng thu thập chỉ số đường huyết đối với bệnh nhân đái tháo đường thai

kỳ Hệ thống cho phép thai phụ nhập chỉ số đường huyết, có hoặc không có tin nhắn SMS nhắc nhở hoặc ghi nhận thông tin đường huyết của người bệnh tại bệnh viện bằng các hình thức tin nhắn SMS hoặc ứng dụng Web Bác sĩ có thể theo dõi, trực quan hóa các chỉ số cần giám sát, thiết lập mẫu tin nhắn nhắc nhở hoặc câu hỏi nghiên cứu trên SMS Hệ thống sẽ giúp tiết kiệm thời gian

và chi phí đi lại của bệnh nhân, đồng thời giúp cho bác sĩ dễ dàng theo dõi, giám sát tình trạng của bệnh nhân, nâng cao hiệu quả trong chẩn đoán và điều trị

- Đánh giá mức độ tuân thủ chỉ định theo dõi đường huyết qua ứng dụng của

bệnh nhân Phát triển hệ thống phục vụ các nhóm người dùng chính bao gồm (1) chủ nhiệm đề tài/dự án (PI), bác sĩ, nhà nghiên cứu, và người tham gia bình thường/bệnh nhân Dựa vào phân quyền, chủ nhiệm dự án, bác sĩ, và các nhà nghiên cứu có thể theo dõi tình trạng tuân thủ chỉ định của các bệnh nhân mà mình giám sát Ngoài ra, hệ thống cho phép cấu hình nhắn tin nhắc bệnh nhân thực hiện các thao tác theo các chỉ định

2 Tính cấp thiết và Tình hình nghiên cứu

Thành phố thông minh đang là một trong những định hướng được quan tâm đầu

tư bởi lãnh đạo, cơ quan, đơn vị, cũng như các tổ chức khác nhau UBND TP Hồ Chí Minh cũng đã công bố đề án “Xây dựng TPHCM trở thành đô thị thông minh giai

đoạn 2017 - 2020, tầm nhìn đến 2025” [1] Việc xây dựng đô thị thông minh cũng đã được UBND Thành phố ký kết hợp tác với các tập đoàn/công ty có uy tín trong và ngoài nước như VNPT [2], Viettel [3], Dell [4], v.v Với thành phố thông minh, người dân có thể thụ hưởng nhiều tiện ích khác nhau bao gồm năng lượng với chi phí thấp, giao thông với chất lượng cao, thực phẩm an toàn, an ninh trật tự được đảm bảo, các dịch vụ công thuận lợi, v.v Đặc biệt trong y tế, nó sẽ giúp cho việc lưu trữ, chia sẻ thông tin được dễ dàng hơn, nâng cao hiệu quả chẩn đoán và điều trị

Mặc dù y học ngày nay đã có những thành tựu nổi bật, tuy nhiên với mật độ dân

số đông và yêu cầu chăm sóc sức khỏe ngày càng cao, việc phát triển các hệ thống chăm sóc y tế với các công nghệ hiện đại cũng đóng vai trò rất quan trọng, đặc biệt

là đối với các thành phố thông minh Nhiều giải pháp đã được đề xuất [5-8], Ghulam

M và các cộng sự [5] đã đề xuất tiếp cận nhận dạng khuôn mặt để suy đoán tình trạng sức khỏe của bệnh nhân M S Hossain [6] phát triển hệ thống nhận tín hiệu giọng nói và video sau đó xử lý trên đám mây để nhận dạng tình trạng bệnh nhân bao gồm đau, căng thẳng, hay bình thường Tuy vậy, nhiều thách thức đối với các hệ thống y

tế thông minh đã được đưa ra [9-11], bao gồm số bệnh nhân mắc bệnh mãn tính ngày càng tăng [9], yêu cầu kết nối nhiều thiết bị khác nhau, đo nhiều thông số khác nhau, v.v

Một trong các điểm cốt lõi đối với các hệ thống thông tin y tế là thu thập và phân tích dữ liệu Đối với việc thu thập dữ liệu, nhiều nhóm đã phát triển các giải pháp bao gồm IoT (Internet of Things) và mạng cảm biến (sensor) [7-8] Hệ thống giám sát tình trạng bệnh nhân sử dụng smartphone để thu thập tín hiệu giọng nói và electroencephalogram được đề xuất bởi Hossian [7] Lee và Chung [12] đã thiết kế

áo mặc kết hợp với mạng BAS (Body Area Sensor) cho mục đích giám sát tình trạng sức khỏe Virone và cộng sự [13] đề xuất giải pháp sử dụng mạng cảm biến cơ thể (Body Sensor Network) để theo dõi các dấu hiệu sinh tồn của bệnh nhân và sử dụng WSN (Wireless Sensor Network) để giám sát điều kiện môi trường Kiến trúc hệ thống dựa trên WSN giúp theo dõi tình trạng sức khỏe từ xa được đề xuất bởi Otto

và cộng sự [14] Nhiều cơ hội và thách thức của các hệ thống giám sát tình trạng sức khỏe dựa trên WSN cũng đã được nghiên cứu [15-17] Bên cạnh việc phát triển các thiết bị đầu cuối (bao gồm các thiết bị IoT) để thu nhận và số hóa tín hiệu, việc phát triển các hệ thống hỗ trợ việc thu thập, lưu trữ và phân tích dữ liệu y tế vẫn còn nhiều

trở ngại do sự không đồng nhất về mặt cấu trúc và nhiều nguồn khác nhau Công trình nghiên cứu của Rachel L Richesson [18] cũng chỉ ra rằng việc thu thập cũng như chia sẻ dữ liệu giữa môi trường nghiên cứu và điều trị vẫn còn nhiều hạn chế Ngoài

ra, việc phát triển các hệ thống cũng như các công cụ hỗ trợ các bác sĩ cũng như các chuyên gia y tế không ngừng được quan tâm với yêu cầu ngày càng cao, bao gồm (1) đòi hỏi khả năng cấu hình linh động trong thu thập, (2) quản lý và phân tích dữ liệu phục vụ cho điều trị người bệnh cũng như các hoạt động nghiên cứu, (3) đáp ứng yêu cầu hạn chế về mặt thời gian và kinh phí Đây cũng đang là một trong những thách thức đối với ngành công nghệ thông tin Việc phát triển các hệ thống hỗ trợ trực quan hóa dữ liệu cũng được quan tâm, tuy nhiên ứng dụng trong tế cũng còn hạn chế [19] Trên môi trường Web, hiện nay cũng một sệ thống hỗ trợ thu thập dữ liệu khá phổ biến bao gồm Catalyst[20], OpenClinica [21], và RedCap [22]

Hệ thống Catalyst:

Catalyst là một hệ thống ứng dụng mã nguồn mở, được phát triển bởi trường Đại học Washington (University of Washington - UW), chủ yếu để hỗ trợ việc nghiên cứu và giảy dạy nội bộ Chức năng chính của hệ thống bao gồm thu thập (survey), quản lý file an toàn, quản lý nội dung, quản lý dự án Ưu điểm lớn nhất của hệ thống này là nó được ưu tiên sử dụng bởi các nhà nghiên cứu và IRB (Institutional Review Board) nội bộ của trường Washington cũng như các đối tác của nó Hệ thống này cũng được hỗ trợ về mặt tài chính và kỹ thuật bởi Biomedical Informatics Core (BMI) thuộc Institute of Translational Health Sciences (ITHS) Hàng ngàn subjects (800 subjects tính đến năm 2011) trong nghiên cứu lâm sàng đã được thực hiện bởi các nhà nghiên cứu của trường với hỗ trợ của BMI; dữ liệu bao gồm thông tin cơ bản của

dự án, các tài liệu và protocol của study, các form, cũng như danh sách các thành viên tham gia dự án Các điều phối viên (coordinator) hỗ trợ thực hiện các nghiên cứu tại đại học Washington quen sử dụng hệ thống Catalyst, do đó nó được ưu tiên sử dụng tại đây Tuy nhiên, hệ thống Catalyst có những hạn chế trong việc thu thập dữ liệu với nhiều đặc trưng khác nhau trong nghiên cứu lâm sàng, không hỗ trợ việc lập lịch, việc thu thập dữ liệu có thể thực hiện trên nhiều forms nhưng hạn chế trong việc liên kết nó lại với nhau Hệ thống cũng hạn chế trong vấn đề che giấu thông tin PHI (protected health information), hệ thống cũng hạn chế trong việc thu thập dữ liệu từ

nhiều đơn vị khác nhau Mặc dù hệ thống cho phép trích xuất (export) dữ liệu nhưng vẫn còn rất nhiều hạn chế, đặc biệt là đòi hỏi nhiều thao tác thủ công Đối với việc import dữ liệu, hệ thống yêu cầu phát triển script để nạp dữ liệu vào hệ thống Catalyst Đánh giá định tính của hệ thống được tóm tắt trong Hình 0.2

Hình 0 1 Hệ thống Catalyst được phát triển bởi đại học Washington [20]

Hình 0 2 Đánh giá định tính của hệ thống Catalyst [23, 24]

OpenClinica:

OpenClinica là hệ thống EDC (Electronic Data Capture) mã nguồn mở được phát triển bởi Akaza research Hệ thống cho phép hỗ trợ thu thập các CRF (case report form) phức tạp Tuy nhiên, hệ thống này yêu cầu khá phức tạp khi thiết kế một dự án nghiên cứu, không phù hợp cho các dự án nhỏ Việc nghiên cứu để thiết kế các CRF cũng là một trở ngại đáng kể, nhiều field bắt buộc phải có nhưng lại không cần thiết OpenClinica cung cấp template dạng file Excel, nó thường bao gồm các sheet như

revision notes, sections and groups, các câu hỏi và labels OpenClinica cũng hỗ trợ việc liên kết dữ liệu các dạng thăm khám (visits) của đối tượng, bao gồm có kế hoạch

và không có kế hoạch, nó cung cấp bảng hay còn gọi là Subject matrix để thấy rõ trạng thái đối tượng một cách dễ dàng bao gồm đã hoàn thành, đang xử lý, hoặc chưa

có kế hoạch, đồng thời nó cũng chỉ ra các CRF nào đã được hoàn thành hoặc chưa hoàn thành Hệ thống cũng cho phép quản lý site bao gồm thông tin contact chi tiết, các version của CRF tại từng site, nó cho phép phân quyền dựa trên user role và che giấu PHI đối với các user không được phân quyền trong khi cho phép truy cập đến môt số dữ liệu nghiên cứu khác

Hình 0 3 Hệ thống hỗ trợ thu thập dữ liệu OpenClinica [21]

Hình 0 4 Đánh giá định tính của hệ thống OpenClinica [23, 24]

Tuy nhiên, hệ thống này không có tính năng nhắc tự động Việc export dữ liệu yêu cầu quá trình phức tạp bao gồm tạo cơ sở dữ liệu cho các sự kiện và CRF, thiết lập các thông số Đánh giá định tính của hệ thống OpenClinica được tóm tắt trong Hình 0.4

Hình 0 5 Hệ thống hỗ trợ thu thập dữ liệu REDCap [22]

REDCap:

REDCap (Research Electronic Data CAPture) của Vanderbilt University là một

hệ thống EDC có thể được sử dụng miễn phí cho mục đích giáo dục, nhưng nó không phải là mã nguồn mở Hệ thống cho phép các nhóm tham gia từ nhiều đơn vị khác nhau Điểm mạnh của REDCap là sự phong phú của tài liệu, bao gồm webminars và tài liệu online; hầu hết được tích hợp vào phần mềm Cơ sở dữ liệu Demo cũng bao gồm các form thể hiện các chức năng có thể có Các dự án bắt đầu ở trạng thái

“Development” sẽ cho phép thay đổi forms và các events, tuy nhiên khi chuyển sang trạng thái “Production” thì bất kỳ sự thay đổi nào cần có sự chấp nhận của quản trị REDCap Nó cũng hỗ trợ “skip logic” tuy nhiên cũng có rất nhiều hạn chế, chẳng hạn không thể ẩn CRF REDCap hỗ trợ việc lập lịch thăm khám, tuy nhiên nó không có chức năng nhắc nhở, thông báo cho người dùng (thành viên trong nhóm nghiên cứu) tham gia dự án thực hiện các nhiệm vụ theo lịch đã được thiết lập Cơ chế phân quyền dựa trên vai trò của user hoặc group cũng được phát triển trong REDCap Việc trích xuất dữ liệu (export) cũng khá dễ dàng bằng cách chọn cơ sở dữ liệu, chọn các field, nhiều chọn lựa cho de-identification cũng được hỗ trợ, bao gồm xóa những trường được đánh dấu là PHI Việc import dữ liệu được thực hiện dựa trên template CSV Đánh giá định tính của hệ thống OpenClinica được tóm tắt trong Hình 0.6

Hình 0 6 Đánh giá định tính của hệ thống REDCap [23, 24]

3 Các kiến trúc và công nghệ chính sẽ được sử dụng

Các công nghệ và framework được sử dụng trong nghiên cứu này được chia làm

2 nhóm là (1) Backend and (2) Frontend

phức tạp, nó có tính module hóa, độ tin cậy và khả năng mở rộng cao; khả năng bảo trì và triển khai được thuận lợi hơn Kiến trúc microservice giúp phân tách chức năng của ứng dụng thành một tập các dịch vụ (service) (nó cũng có thể được xem như là một module) Mỗi dịch vụ sẽ có một bộ API dùng giao tiếp, từ đó giúp dễ dàng giữ tính module của ứng dụng theo thời gian, đồng thời giúp khả năng triển khai và mở rộng dễ dàng Mỗi service có kiến trúc Logical View riêng biệt, thường là kiến trúc lục giác (Hexagonal architecture) Một ví dụ minh họa cho kiến trúc microservices được mô tả trong Hình 0.7

Kiến trúc lục giác là một kiến trúc thay thế cho kiến trúc phân lớp (Hình 0.8) Kiến trúc này tổ chức Logical View theo cách đặt Business logic layer (chứa các nghiệp vụ) làm trung tâm, thay vì Presentation layer, dịch vụ có một hoặc nhiều inbound adapter xử lý request từ bên ngoài gọi Business logic Tương tự, thay vì sử dụng một Persistence layer, dịch vụ có một hoặc nhiều outbound adapter được gọi bởi Business logic tới các dịch vụ bên ngoài Một điểm mạnh của kiểu kiến trúc này

là Business logic không vụ thuộc vào các adpater mà ngược lại các adapter phục thuộc trên nó

Hình 0 8 Kiến trúc lục giác (nguồn Internet)

3.2 gRPC

gRPC, được phát triển bởi Google, là một RPC (Remote Procedure Call) framework hiệu suất cao, mã nguồn mở, có thể chạy trên nhiều môi trường Nó có thể kết nối hiệu quả các dịch vụ bên trong và trên các cơ sở dữ liệu khác nhau, có thể

hỗ trợ cân bằng tải, theo dõi, health check và xác thực Nó cũng có thể được áp dụng trong các hệ thống phân tán để kết nối các thiết bị, ứng dụng di động và trình duyệt với các dịch vụ phụ trợ Đặc biệt là kiến trúc Microservices

Trong kiến trúc Microservices, số lần giao tiếp giữa các service là rất lớn, vấn đề hiệu năng trong việc trao đổi dữ liệu giữa các service rất được quan tâm Với chuẩn giao thức HTTP/1.1, dữ liệu trao đổi phải được mã hóa từ JSON, XML, v.v phía nhận cũng phải thực hiện công việc ngược lại là phải giải mã dữ liệu nhận được gây tốn kém nhiều tài nguyên để xử lý Để giải quyết vấn đề này gRPC kết hợp Protocol Buffers và HTTP/2.0 để thực hiện việc truyền dữ liệu Với sự kết hợp này, gRPC có

ưu điểm nhẹ hơn, nhanh hơn và cung cấp hiệu năng tốt hơn, có khả năng mở rộng tốt, thích hợp cho việc phát triển các hệ thống phân tán

gRPC cho phép định nghĩa cấu trúc dữ liệu dưới dạng file protoc và nó tự động tạo ra các file sử dụng để giao tiếp với ngôn ngữ mà chúng ta sử dụng gRPC hỗ trợ

đa dạng các ngôn ngữ như C++, Java, Python, Go, Ruby, C#, Node.js, Android Java, Objective-C,v.v Với lợi thế này, khối lượng công việc so với việc cấu hình thủ công được giảm thiểu, việc tự động hóa được thực hiện ở mức cao hơn

Hình 0 9 Kiến trúc gRPC

Kiến trúc gRPC được hiện thực ở server bằng ngôn ngữ Node.js, phía client được hiện thực trên nền tảng Web và Mobile đã được chỉ ra trong Hình 0.9

3.3 Kiến trúc củ hành (Go-Kit)

Go-Kit là một tiếp cận phát triển ứng dụng rất hiệu quả theo mô hình microservice Microservice dựa trên go-kit giống như “củ hành” với nhiều lớp (layer), các layer sẽ được chia thành 3 nhóm chính: Dịch vụ (service), Endpoint, và Transport Minh họa kiến trúc “củ hành” này được chỉ ra trong Hình 0.10

- Tầng dịch vụ: nhóm này đảm nhận các nghiệp vụ chính, tất cả các logic nghiệp

vụ được hiện thực ở đây

- Tầng Enpoint: thông điệp chính trong Go-kit được truyền dạng RPC, một

endpoint biểu diễn một phương thức RPC, mỗi phương thức của dịch vụ cần được đóng gói trong một endpoint

- Nhóm Transport: các dịch vụ khác nhau thường giao tiếp với nhau thông qua

các giao thức truyền thống như HTTP, gRPC, hay hệ thống pub/sub giống NATS Go-kit hỗ trợ một loạt dạng bao gồm HTTP, gRPC, NATS, AMQP, v.v Nhóm service không cần quan tâm giao thức được sử dụng cho giao tiếp

ở Transport

Hình 0 10 Kiến trúc củ hành này giúp phát triển các ứng dụng dễ dàng mở rộng,

bảo trì, và kiểm thử (nguồn Internet)

Một điểm khá thú vị khác của Go-kit là khả năng phân tách các lớp, nó cho phép sử dụng các Middleware pattern Các middleware có thể bao bọc các endpoint hay dịch

vụ để bổ sung các tính năng như là logging, rate limiting, load balancing, hoặc tracing

3.4 Kubernetes

Khởi đầu, mô hình máy chủ thường bao gồm máy chủ vật lý, hệ điều hành (OS)

và các ứng dụng (application) Tuy nhiên, mô hình này có thể gây lãng phí tài nguyên; một máy chủ chỉ có thể vận hành một OS tại một thời điểm, không thể tận dụng tối

ưu hết tài nguyên Một trong các giải pháp để hạn chế tình trạng này là sử dụng công nghệ ảo hóa (Virtualization)

Công nghệ ảo hóa (nổi bật là các nền tảng: Virtualbox,VMware, KVM, v.v.) cho phép trên một máy chủ vật lý chúng ta có thể tạo được nhiều OS Tuy nhiên, nó vẫn còn nhiều hạn chế như: việc phải ảo hóa từ phần cứng đến nguyên cả hệ điều hành làm tiêu tốn tài nguyên khá lớn, nặng, thời gian khởi động lâu Containerization được

ra đời như là một giải pháp hoàn hảo để chạy các dịch vụ trên máy ảo mà tiêu tốn tài nguyên ít nhất, hiệu năng tốt nhất

Containerization (hay còn được gọi là operating system virtualization), công nghệ này không ảo hóa phần cứng, hệ điều hành nữa mà nó ảo hóa môi trường Các dịch

vụ trong Container vẫn chạy chung hệ điều hành (Host OS), chung nhân (Kernel) nhưng môi trường chạy của các dịch vụ thì luôn độc lập với nhau Minh họa mô hình Containerization được chỉ ra ở Hình 0.11

Hình 0 11 Mô hình containerization (nguồn Internet)

Containerization có nhiều ưu điểm, bao gồm (1) Tạo và triển khai ứng dụng nhanh chóng, (2) Môi trường thực thi nhẹ và độc lập, (3) Tính di động và mở rộng, (4) Hiệu năng cao, (5) Quản lý phiên bản tốt, (6) Tích hợp kiểm thử và triển khai tự động (CI-CD), (7) Tách biệt giữa phát triển và vận hành

Trong những năm gần đây, các ứng dụng thực tế sẽ gồm nhiều containers Các containers đó phải được triển khai trên nhiều server host và thực hiện Container hóa bằng cách sử dụng docker Trên thực tế trong môi trường production, việc cấu trúc

hệ thống chạy bằng container chỉ sử dụng docker là rất khó khăn Vì vậy cần phải có

1 nền tảng điều phối Container giúp việc triển khai và quản lý các container dễ dàng

hơn Một trong các giải pháp hiệu quả là Kubernetes cung cấp khả năng phối hợp và quản lý cần thiết để triển khai các containers theo quy mô cho các hệ thống đó Kubernetes (viết tắt K8S )1 là một nền tảng mã nguồn mở dùng để tự động hóa việc quản lý, scaling và triển khai ứng dụng dưới dạng Container hoá Nó giúp loại

bỏ rất nhiều các quy trình thủ công liên quan đến việc triển khai và mở rộng các ứng dụng đã đóng gói (containerized applications) Nói cách khác, chúng ta có thể tập hợp các nhóm máy chủ chạy các Linux containers và Kubernetes giúp quản lý dễ dàng và hiệu quả các cụm đó Kubernetes cũng có thể được coi như là (1) container platform, (2) microservice platform, và (3) portable cloud platform Kubernetes cung cấp một môi trường quản lý trung tâm container Nó phối hợp cơ sở hạ tầng điện toán, mạng

và lưu trữ thay cho khối lượng công việc của người dùng Điều này cung cấp phần lớn tính đơn giản của Platform as a Service (PaaS) với tính linh hoạt của Infrastructure

as a Service (IaaS) và cho phép tính di động giữa các nhà cung cấp cơ sở hạ tầng Một số ưu điểm của Kubernetes bao gồm: (1) Dàn xếp vùng chứa trên nhiều máy chủ, (2) Cung cấp cho việc xây dựng và triển khai images container đáng tin cậy và thường xuyên một cách nhanh chóng và có thể dễ dàng rollback, (3) Tận dụng tốt hơn phần cứng để tối đa hóa tài nguyên cần thiết để chạy các ứng dụng doanh nghiệp, (4) Kiểm soát, tự động triển khai và cập nhật ứng dụng, (5) Thay đổi quy mô các ứng dụng được container và tài nguyên khi đang hoạt động, (6) Quản lý các dịch vụ, đảm bảo các ứng dụng được triển khai luôn chạy, (7) Health-check và self-heal các ứng dụng bằng tính năng tự động phát hiện, tự động sửa lỗi, tự động dò tìm và tự động mở rộng

3.5 NodeJS

Là một bộ JavaScript runtime bất đồng bộ hướng sự kiện, Node được thiết kế để xây dựng các ứng dụng mạng Trái ngược với mô hình xử lý đồng thời (concurrency model), nơi sử dụng các luồng (thread) (ứng dụng kết nối dựa trên luồng tương đối không hiệu quả và khó sử dụng), người dùng Node không phải lo lắng về khóa chết (dead-locking) của tiến trình vì Node không sử dụng cơ chế chờ (non-blocking) Hầu như các chức năng trong Node không trực tiếp thực hiện các thao tác I/O, do đó tiến trình không bao giờ bị chặn Vì không có tính block (khóa) nên các hệ thống hướng đến khả năng mở rộng sẽ rất phù hợp để xây dựng bằng Node

1 https://kubernetes.io/docs/concepts/overview/

Hình 0 12 Luồng xử lý trong NodeJS

3.6 Angular

Angular là một framework về cấu trúc cho ứng dụng web động Nó cho phép sử dụng HTML làm ngôn ngữ mẫu và cho phép mở rộng cú pháp HTML để thể hiện các thành phần ứng dụng một cách rõ ràng và ngắn gọn Kỹ thuật “data binding” và

“dependency injection” của AngularJS giúp giảm đi phần lớn lượng mã phải viết Và tất cả mọi thứ đều được xử lý trong trình duyệt, làm cho nó trở thành một đối tác lý tưởng với bất kỳ công nghệ máy chủ nào AngularJS giảm thiểu sự không phù hợp giữa các tài liệu HTML và những gì một ứng dụng cần bằng cách tạo các cấu trúc HTML mới AngularJS dạy cho trình duyệt các cú pháp mới thông qua cấu trúc được gọi là directives và component Một số mô hình của AngularJS được chỉ ra trong các Hình 0.13 và 0.14

Hình 0 13 Mô hình binding dữ liệu của AngularJS

Hình 0 14 Mô hình tổ chức lớp điều khiển của AngularJS

3.7 ChartJS

ChartJS là một thư viện vẽ biểu đồ đơn giản bằng JavaScript nhưng không kém phần linh hoạt cao cho nhà thiết kế và lập trình Thư viện hỗ trợ trực quan hóa dữ liệu qua nhiều loại biểu đồ khác nhau, mỗi loại biểu đồ có những hiệu ứng chuyển động riêng và luôn có tính tùy chỉnh cao Với việc sử dụng HTML5 Canvas, nó có thể mang lại hiệu xuất rendering tốt trên mọi nền tảng trình duyệt hiện đại (IE11 trở lên nếu canvas được vẽ trên trình duyệt Internet Explorer), đồng thời nó cũng thể hiện khả năng responsive tốt trong bối cảnh cần vẽ lại biểu đồ nếu kích thước cửa sổ làm việc thay đổi

Với đặc điểm mã nguồn mở, ChartJS luôn được cộng đồng lập trình viên liên tục hoàn thiện (báo cáo và sửa lỗi, hỗ trợ người dùng mới, bổ sung thêm các plugin nhằm tùy chỉnh tối đa biểu đồ)

3.8 Một số công nghệ khác

- JSON: là một định dạng hoán vị dữ liệu nhanh Chúng dễ dàng cho chúng ta

đọc và viết Dễ dàng cho thiết bị phân tích và phát sinh Chúng là cơ sở dựa trên tập hợp của Ngôn Ngữ Lập Trình JavaScript, tiêu chuẩn ECMA-262 phiên bản 3 - tháng 12 năm 1999 JSON là 1 định dạng kiểu text mà hoàn toàn độc lập với các ngôn ngữ hoàn chỉnh, thuộc họ hàng với các ngôn ngữ C, gồm có

C, C++, C#, Java, JavaScript, Perl, Python, và nhiều ngôn ngữ khác Những đặc tính đó đã tạo nên JSON một ngôn ngữ hoán vị dữ liệu lý tưởng

- Angular UI Grid 2: Thư viện cho phép hiển thị dữ liệu dưới dạng bảng, thích hợp với việc tạo các cột dữ liệu một cách linh động (không có định số lượng

và nội dung từng cột) và thao tác tốt đối với tập dữ liệu lớn

- AlaSQL3: cho phép hiện thực một hệ cơ sở dữ liệu dựa trên JavaScript SQL trên nền trình duyệt Cho phép tạo mối quan hệ giữa các bảng Lưu trữ và xuất

dữ liệu ở localStorage, IndexedDB hoặc Excel

- PouchDB: đây là API cơ sở dữ liệu mã nguồn mở được phát triển từ CouchDB,

cơ sở dữ liệu NoSQL API này cho phép phát triển các ứng dụng hoạt động cả offline và online Khi ứng dụng ở dạng offline, dữ liệu được chứa cục bộ trong browser sử dụng WebSQL và IndexedDB Khi ứng dụng ở dạng online, nó được đồng bộ về server

2 "Angular UI Grid." http://ui-grid.info/ Ngày truy cập 4 thg 5 2019

3 "AlaSQL." http://alasql.org/ Ngày truy cập 4 thg 5 2019

Chương 1 TỔNG QUAN HỆ THỐNG

1.1 SƠ LƯỢC HỆ THỐNG ĐỀ XUẤT

Hệ thống IoH (Information of Health) cung cấp nền tảng hỗ trợ thu thập, xử lý, phân tích và trực quan hóa dữ liệu Trong hệ thống này có 3 nhóm vai trò chính:

- PI (Principal Investigator): là người có vai trò chủ trì thu thập dữ liệu, thực

hiện các công việc:

x Thiết kế nghiên cứu hoặc dự án;

x Quản lý và điều hành nghiên cứu (managing & administering)

- Data Entry: là các người dùng như bệnh nhân, người tham gia dự án với vai

trò cung cấp dữ liệu, xem dữ liệu; là đối tượng nghiên cứu của dự án đối với loại dự án nghiên cứu dữ liệu con người

- Coodinator: người làm nhiệm vụ điều phối, hỗ trợ thu thập dữ liệu như:

x Thu thập dữ liệu

x Tạo dữ liệu

x Xử lý dữ liệu

x Phân tích dữ liệu

x Đối chiếu hoặc xử lý

Hệ thống hỗ trợ thực hiện quy trình thu thập dữ liệu (Data Collection) gồm các giai đoạn như sau:

- Giai đoạn 1: Thiết kế dự án thu thập dữ liệu, ở giai đoạn này PI là người khởi

tạo dữ án gồm các bước sau:

x Tạo dự án gồm các thông tin như: Tên dự án, loại dữ án, mã số IRB, v.v

x Thiết kế mẫu thu thập dữ liệu

x Mời người tham gia (gồm nhà nghiên cứu, và đối tượng nghiên cứu đối với

dự án thu thập dữ liệu con người)

x Thiết kế các mẫu trực quan hóa dữ liệu

- Giai đoạn 2: Thu thập dữ liệu

x Người tham gia nhập dữ liệu lên hệ thống;

x Researcher hỗ trợ quy trình thu thập dữ liệu;

x Xem dữ liệu thu thập;

x Điều chỉnh cấu hình trong phạm vi cho phép;

x PI sẽ là người giám sát việc thu thập dữ liệu trong giai đoạn này;

x Trích xuất dữ liệu trung gian

- Giai đoạn 3: Kết thúc dự án

x PI có thể thực hiện thống kê, tổng kết dữ liệu nghiên cứu;

x Xuất dữ liệu nghiên cứu

1.2 CÁC YÊU CẦU HỆ THỐNG

1.2.1 Yêu cầu chức năng

- Chức năng đăng ký: Người dùng đăng ký tài khoản sử dụng hệ thống trực tuyến

Người dùng điển đẩy đủ thông tin của mình vào trang đăng ký trực tuyến và chọn đăng ký Hệ thống sẽ tạo tài khoán với thông tin email và mật khẩu và người dùng cung cấp

- Chức năng đăng nhập: Chức năng này hỗ trợ định danh người dùng, cung cấp

giao diện để người dùng truy cập, người dùng cần nhập thông tin email và mật khẩu để truy cập và sử dụng hệ thống Tính năng này được hiện thực với một cổng đăng nhập (SSO) hỗ trợ người dùng có thể truy cập từ nhiều thiết bị hỗ trợ trình duyệt web Các ứng dụng di động và ứng dụng desktop trong hệ thống đều

có thể sử dụng lại giao diện này

- Chức năng thu thập dữ liệu: Chức năng này hỗ trợ việc thu thập dữ liệu từ nhiều

nguồn khác nhau

- Chức năng quản lý dự án: Cho phép quản lý, cấu hình, các thông tin liên quan

đến dự án

- Chức năng mô hình hóa dữ liệu thành biểu đồ: Cho phép chuyển đổi dữ liệu

để hỗ trợ việc trực quan hóa sử dụng các biểu đồ

- Chức năng nhắc lịch: Cho phép nhắc lịch, hoặc gởi tin đến đối tượng data entry

- Chức năng import dữ liệu: Import dữ liệu có sẳn vào hệ thống

- Chức năng export dữ liệu: Export dữ liệu sang các dạng dữ liệu khác

- Chức năng hỗ trợ phân tích mở rộng: Cho phép hỗ trợ phân tích dữ liệu, tích

hợp với các hệ thống khác

1.2.2 Yêu cầu phi cức năng

- Yêu cầu vận hành:

9 Hệ thống nên hoạt động trên các loại trình duyệt Web

9 Hệ thống có khả năng tích hợp với các hệ thống thu thập dữ liệu có sẵn như: REDCap, DHIS2, I2B2

9 Hệ thống tự động sao lưu dữ liệu hàng ngày

Hình 1.1 Sơ đồ Use case tổng quát

- Yêu cầu hiệu năng:

9 Mọi tương tác giữ người dùng và hệ thống nên được xử lý nhanh (không quá

2 giây)

9 Hệ thống đảm bảo phục vụ cho ít nhất 10.000 người dùng tại một thời điểm

9 Hệ thống luôn đảm bảo vận hành suốt 24 giờ mỗi ngày

- Yêu cầu bảo mật:

9 Hệ thống chỉ cho phép truy cập bởi người dùng đã được xác thực

9 Chỉ có PI được xem dữ liệu cá nhân của bệnh nhân tham gia

9 Chỉ có các sĩ phụ trách được nhập dữ liệu cho bệnh nhân, hoặc bệnh nhân tự nhập dữ liệu cho mình

9 Bệnh nhân chỉ được xem dữ liệu của chính mình

9 Dữ liệu bệnh nhân chỉ được xem bởi những có thẩm quyền

9 Dữ liệu định danh của bệnh nhân không được phép xem bởi người quản trị cơ

sở dữ liệu

- Yêu cầu về văn hóa, chính sách:

9 Hệ thống hỗ trợ đa ngôn ngữ

9 Hệ thống tuân thủ các tiêu chuẩn trong lĩnh vực y tế

9 Hệ thống không có các nội dung gây bất đồng tôn giáo, dân tộc

Hình 1 2 Các thành phần chính của hệ thống

1.3 SƠ ĐỒ TỔNG QUÁT HỆ THỐNG

Sơ đồ Use-case tổng quát được chỉ ra trong Hình 1 1 Sơ đồ các thành phần chính của hệ thống được chỉ ra trong Hình 1.2 Hệ thống được thiết kế bao gồm các thành phần chính: (1) Collector service, (2) IoH Chart module, (3) SMS service, (4) IAM

(Identity & access management) service, (5) Identity service, và (6) Encryption

service Collector service hỗ trợ việc cấu hình và thu thập dữ liệu bao gồm trên nền

Web, mobile app, và SMS Ngoài ra nó cũng hỗ trợ việc cấu hình và trực quan hóa

dữ liệu với sự kết nối của IoH Chart module SMS service hỗ trợ việc thu thập dữ liệu

thông qua SMS, đồng thời nó cũng hỗ trợ tính năng nhắc lịch Dịch vụ IAM hỗ trợ

việc xác thực và phân quyền, việc xác thực dựa trên sự kết hợp của tiếp cận OAuthen2

và Login & Consent Dịch vụ Identity hỗ trợ việc lưu trữ thông tin định danh Cuối

cùng là dịch vụ Encryption hỗ trợ việc mã hóa và giải mã thông tin định danh

Hình 1 3 Các thành phần hệ thống được nhìn từ phía front-end

Hình 1 4 Liên kết các thành phần chính của hệ thống Nếu nhìn từ phía Front-end, hệ thống có thể được mô tả như trong Hình 1.3 Ở đây, các dịch vụ (service) của hệ thống có thể gom nhóm lại: (1) các service thuộc VDAT system, tuy nhiên trong VDAT thành phần SMS Gateway và GSM modem nằm ngoài cluster để dễ dàng kiểm soát việc gởi tin (không bị trùng lắp tin); (2) các dịch vụ EVH (external web hosting) phần lớn được hỗ trợ từ phía Front-end Sự giao tiếp của các thành phần được chỉ ra trong Hình 1.4

Hình 1 5 Chức năng đăng nhập

Hình 1 6 Chức năng đăng ký

Từ phía backend, hệ thống cung cấp 5 bộ API bao gồm: Nhóm thực hiện chức

năng xác thực và phân quyền Các API này được cung cấp bởi dịch vụ IAM (Identity

and Access management) Tùy theo yêu cầu, liên quan đến thông tin định danh nói

riêng và thông tin nhạy cảm nói chung, dữ liệu sẽ được xử lý bởi dịch vụ Identity và

Encryption Nhóm API thực hiện chức năng hỗ trợ xử lý gởi và nhận tin nắn được