Phát triển ứng dụng hồ sơ y tế điện tử cho thiết bị di động trên nền điện toán đám mây

Phát triển ứng dụng hồ sơ y tế điện tử cho thiết bị di động trên nền điện toán đám mây Phát triển ứng dụng hồ sơ y tế điện tử cho thiết bị di động trên nền điện toán đám mây Phát triển ứng dụng hồ sơ y tế điện tử cho thiết bị di động trên nền điện toán đám mây luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp luận văn tốt nghiệp,luận văn thạc sĩ, luận văn cao học, luận văn đại học, luận án tiến sĩ, đồ án tốt nghiệp

PHÁT TRIỂN ỨNG DỤNG HỒ SƠ Y TẾ ĐIỆN TỬ CHO THIẾT BỊ DI

ĐỘNG TRÊN NỀN ĐIỆN TOÁN ĐÁM MÂY

LUẬN VĂN THẠC SĨ KỸ THUẬT MẠNG MÁY TÍNH VÀ TRUYỀN THÔNG DỮ LIỆU

Hà Nội – Năm 2019

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

BÙI NGUYÊN TÙNG

PHÁT TRIỂN ỨNG DỤNG HỒ SƠ Y TẾ ĐIỆN TỬ CHO THIẾT BỊ DI ĐỘNG

TRÊN NỀN ĐIỆN TOÁN ĐÁM MÂY

Chuyên ngành : Mạng máy tính và truyền thông dữ liệu

LUẬN VĂN THẠC SĨ KỸ THUẬT MẠNG MÁY TÍNH VÀ TRUYỀN THÔNG DỮ LIỆU

NGƯỜI HƯỚNG DẪN KHOA HỌC :

1 PGS.TS Nguyễn Linh Giang

Hà Nội – Năm 2019

LỜI CAM ĐOAN

Những kiến thức trình bày trong luận văn là do tôi tìm hiểu, nghiên cứu và trình bày theo những kiến thức tổng hợp của cá nhân Kết quả nghiên cứu trong luận văn này chưa từng được công bố tại bất kỳ công trình nào khác Trong quá trình làm luận văn, tôi có tham khảo các tài liệu có liên quan và đã ghi rõ nguồn tài liệu tham khảo Tôi xin cam đoan đây là công trình nghiên cứu của tôi và không sao chép của bất kỳ ai

Tôi xin chịu hoàn toàn trách nhiệm, nếu sai, tôi xin chịu mọi hình thức kỷ luật theo quy định

Hà Nội, ngày 8 tháng 3 năm 2019

Học viên

Bùi Nguyên Tùng

LỜI CẢM ƠN

Trước tiên, tôi xin bày tỏ lòng biết ơn sâu sắc tới PGS.TS Nguyễn Linh Giang

và các thầy cô Viện CNTT-TT, Trường Đại học Bách Khoa Hà Nội đã nhiệt tình đào tạo và hướng dẫn để tạo điều kiện thuận lợi cho tôi nghiên cứu khoa học, và giúp tôi

có thể hoàn thành luận văn một cách tốt nhất

Cuối cùng tôi xin gửi lời cám ơn đến gia đình, bạn bè, những người đã luôn bên tôi, động viên và khuyến khích tôi trong quá trình thực hiện đề tài nghiên cứu của mình

Học viên

Bùi Nguyên Tùng

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP

Luận văn tác giả trình bày nghiên cứu mô hình hồ sơ y tế điện tử cho thiết bị

di động trên nền tàng điện toán đám mây Sau đó áp dụng mô hình đề xuất này phát triển một ứng dụng thử nghiệm trên thiết bị di động chạy hệ điều hành Android

CHƯƠNG 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN Chương này tổng kết các kết quả đạt được trong đồ án và một số hạn chế cần khắc phục, đề xuất hướng nghiên cứu tiếp theo

MỤC LỤC

LỜI CAM ĐOAN 3

LỜI CẢM ƠN 4

TÓM TẮT NỘI DUNG ĐỒ ÁN TỐT NGHIỆP 5

MỤC LỤC 6

DANH MỤC HÌNH VẼ 8

DANH MỤC BẢNG 9

THUẬT NGỮ VÀ TỪ VIẾT TẮT 10

MỞ ĐẦU 12

1 Lý do chọn đề tài 12

2 Mục đích nghiên cứu của luận văn 12

3 Đối tượng, phương pháp và phạm vi nghiên cứu 13

CHƯƠNG 1 TỔNG QUAN 14

1.1 Giới thiệu 14

1.1.1 Khái niệm hồ sơ sức khỏe điện tử 14

1.1.2 Thực trạng hồ sơ sức khỏe điện tử tại Việt Nam 16

1.1.3 Tầm nhìn và thách thức 17

1.2 Xây dựng yêu cầu hệ thống 18

1.2.1 Yêu cầu về cơ sở dữ liệu và truy cập 18

1.2.2 Yêu cầu về tính bảo mật 19

1.2.3 Yêu cầu về tiêu chuẩn CNTT 20

1.3 Tổng quan tiêu chuẩn HL7 21

1.3.1 Khái niệm chuẩn HL7 21

1.3.2 Mục đích của HL7 21

1.3.3 Lịch sử phát triển của HL7 22

CHƯƠNG 2 CHUẨN HL7 TRONG TRAO ĐỔI DỮ LIỆU Y TẾ 25

2.1 Chuẩn trao đổi dữ liệu y tế HL7 25

2.1.1 Nguyên tắc mã hóa trong HL7 26

2.1.2 Các khái niệm cơ sở 27

2.1.3 Môi trường truyền thông 31

2.1.4 Khung bản tin 32

2.1.5 Các ký tự ngăn cách trong bản tin 40

2.1.6 Quy tắc xây dựng bản tin 41

2.2 Các phân đoạn bản tin 45

2.2.1 MSH – Phân đoạn tiêu đề bản tin 46

2.2.2 EVN – Phân đoạn loại sự kiện 49

2.2.3 PID – Phân đoạn định danh nhân thân bệnh nhân 51

2.2.4 NK1 – Phân đoạn thân nhân và các bên liên quan 53

2.2.5 PV1 – Phân đoạn thăm khám bệnh nhân 55

CHƯƠNG 3 MÔ HÌNH ỨNG DỤNG VÀ TRIỂN KHAI 59

3.1 Đề xuất mô hình ứng dụng hồ sơ y tế điện tử 59

3.1.1 Mô hình ứng dụng 60

3.1.2 Chi tiết quy trình trao đổi thông tin hồ sơ y tế 61

3.2 Lựa chọn dịch vụ điện toán đám mây 66

3.2.1 Thiết kế mô hình điện toán đám mây PaaS 66

3.2.2 Giới thiệu nền tảng Google Cloud Platform 67

3.2.3 Lựa chọn dịch vụ Cloud Firestore 68

3.3 Tổng quát về cơ sở dữ liệu 73

3.3.1 Cơ sở dữ liệu NoSQL 73

3.3.2 Cơ sở dữ liệu Firestore 77

3.4 Triển khai mô hình ứng dụng 82

3.4.1 Cấp quyền đăng nhập 82

3.4.2 Tổ chức dữ liệu 83

3.4.3 Cài đặt và chạy chương trình 85

3.4.4 Đánh giá 89

CHƯƠNG 4 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 90

4.1 Kết luận 90

4.2 Hướng phát triển 90

TÀI LIỆU THAM KHẢO 92

PHỤ LỤC 93

PHỤ LỤC A – BẢNG MÃ HL7 93

DANH MỤC HÌNH VẼ

Hình 1 Hồ sơ y tế điện tử sẽ được triển khai rộng rãi 15

Hình 2 Quản lý hồ sơ bệnh án của BV ĐH Y Dược HCM 16

Hình 3 Lịch sử phát triển của các phiên bản HL7 23

Hình 4 Các phần cấu thành nên một bản tin HL7 33

Hình 5 Biểu đồ quy tắc xây dựng một bản tin 44

Hình 6 Một số phân đoạn cấu thành bản tin HL7 45

Hình 7 Mô hình quản lý-chia sẻ hồ sơ y tế điện tử 60

Hình 8 Quy trình đăng nhập và đọc hồ sơ y tế 61

Hình 9 Quy trình trao đổi hồ sơ y tế nội bộ 63

Hình 10 Quy trình trao đổi hồ sơ y tế trên mạng lưới 65

Hình 11 Nền tảng đám mây Google và các dịch vụ lưu trữ 67

Hình 12 Dịch vụ Cloud Firestore của Google 69

Hình 13 Thiết lập quyền truy cập dữ liệu 72

Hình 14 Ví dụ cơ sở dữ liệu NoSQL dạng key-value 76

Hình 15 Ví dụ cơ sở dữ liệu NoSQL dạng document 77

Hình 16 Các thành phần dữ liệu của Firestore 78

Hình 17 Minh họa đường dẫn collection - document 79

Hình 18 Minh họa cây dữ liệu JSON 3 tầng 80

Hình 19 Quản lý tài khoản đăng nhập 83

Hình 20 Cây quản lý dữ liệu bệnh nhân 84

Hình 21 Collection lưu trữ thông tin thăm khám của bệnh nhân 85

Hình 22 Thử nghiệm đăng nhập tài khoản 86

Hình 23 Thử nghiệm đọc dữ liệu từ đám mây 87

Hình 24 Thử nghiệm ghi dữ liệu lên Firestore 88

Hình 25 Thử nghiệm xóa dữ liệu trên Firestore 89

DANH MỤC BẢNG

Bảng 1 Các loại dữ liệu HL7 cơ bản 38

Bảng 2 Bảng các loại tùy chọn 38

Bảng 3 Các thuộc tính lặp lại 39

Bảng 4 Giá trị của các ký tự ngăn cách 41

Bảng 5 Bảng thuộc tính HL7 – MSH – Tiêu đề bản tin 46

Bảng 6 Các loại bản tin 48

Bảng 7 Một số mã phiên bản HL7 49

Bảng 8 Bảng thuộc tính HL7 – EVN – Loại sự kiện 49

Bảng 9 Bảng thuộc tính HL7 – PID – Định danh bệnh nhân 52

Bảng 10 Bảng thuộc tính HL7 – NK1 – Định danh thân nhân 55

Bảng 11 Bảng thuộc tính HL7 – PV1 – Thăm khám bệnh nhân 57

Bảng 12 Mô tả các kiểu dữ liệu của Cloud Firestore 70

Bảng 13 Giá cước sử dụng dịch vụ Cloud Firestore 73

Bảng 14 Ví dụ lưu trữ dữ liệu dưới dạng JSON 75

Bảng 15 Các kiểu tổ chức dữ liệu Firestore 81

Bảng 16 Định dạng tên đăng nhập người dùng của ứng dụng 83

Bảng 17 Phân quyền xử lý dữ liệu 83

THUẬT NGỮ VÀ TỪ VIẾT TẮT

Từ viết tắt Tên tiếng Anh Thuật ngữ tiếng Việt

EMR Electronic Medical Record Bệnh án điện tử

EHR Electronic Health Record Hồ sơ sức khỏe điện tử

HL7 Health Level Seven

CDA Clinical Documents Architecture Kiến trúc tài liệu lâm sàng RIM Reference Information Model Mô hình thông tin tham khảo FHIR Fast Health Interoperable Resource

DICOM Digital Imaging and

Communications in Medicine

Tiêu chuẩn ảnh số và truyền thông trong y tế

OSI Open System Interconnection

ISO International Standards

Organization

Tiêu chuẩn hóa quốc tế

ASCII American Standard Code for

Information Interchange ADT Admit, Discharge, Transfer Sự kiện kích hoạt

MSH Message Header Segment Phân đoạn tiêu đề bản tin

EVN Event Type Segment Phân đoạn loại sự kiện

PID Patient Identity Segment Phân đoạn định danh bệnh nhân

PV1 Patient Visit Information Segment Phân đoạn thăm khám bệnh

nhân

dữ liệu hồ sơ y tế đang bị hạn chế trong phạm vi từng đơn vị bệnh viện do các ràng buộc về cơ sở vật chất và hầu hết không tuân theo một chuẩn chung nào, khiến việc truy xuất dữ liệu giữa các đơn vị trong những tình huống cấp bách còn gặp nhiều khó khăn mà chưa có một hệ thống hỗ trợ tương xứng

Ngày nay, sự bùng nổ cả về số lượng và chất lượng của các thiết bị di động khẳng định vị trí quan trọng của nó trong cuộc sống Việc khai thác các ứng dụng trên thiết bị di động sử dụng nền tảng đám mây đang là một lĩnh vực thời sự với các

ưu điểm vượt trội mà nó cung cấp cho các nhà phát triển nhờ các giải pháp toàn diện với trọng tâm là dễ sử dụng và tốc độ mà không phải bó buộc vào việc quản lý cơ sở

hạ tầng Một câu hỏi là làm thể nào tận dụng được xu hướng này để góp phần nâng

cao chất lượng dịch vụ y tế hiện đại hơn Vì vậy, đồ án “Phát triển ứng dụng hồ sơ y

tế điện tử cho thiết bị di động trên nền điện toán đám mây” – nghiên cứu và đưa ra

một mô hình có thể đáp ứng được những yêu cầu cấp thiết của hồ sơ y tế điện tử một cách hiệu quả và có thể mở rộng dễ dàng

2 Mục đích nghiên cứu của luận văn

Đồ án nghiên cứu chuẩn HL7 dùng trong việc trao đổi dữ liệu điện tử trong môi trường y tế Sau đó tập trung xây dựng một mô hình điện toán cho phép quản trị

và lưu trữ các hồ sơ y tế điện tử trên đám mây đồng thời trao đổi chúng theo chuẩn

HL7 phiên bản 2.8 mà các thao tác tương tác có thể thực hiện hoàn toàn trên các thiết

bị di động một cách đơn giản

Cuối cùng áp dụng mô hình này để triển khai một hệ thống thử nghiệm, cụ thể

tác giả chạy thử nghiệm với ứng dụng trên điện thoại thông minh chạy hệ điều hành

Android kết hợp với nền tảng cơ sở dữ liệu đám mây Google cloud firestore và thực

hiện các thao tác quản trị bệnh nhân cơ bản, ví dụ như truy xuất dữ liệu lịch sử nhập

viện/xuất viện khám chữa bệnh của bệnh nhân

3 Đối tượng, phương pháp và phạm vi nghiên cứu

Đối tượng nghiên cứu đầu tiên là tiêu chuẩn định dạng bản tin HL7 phiên bản

2.8 Nội dung của tiêu chuẩn HL7 là rất rộng bao hàm hết mọi vấn đề liên quan đến

văn bản trong thông tin y tế Phương pháp tiếp cận các tài liệu chính thức về chuẩn

HL7 của Bộ Y tế và tổ chức HL7 quốc tế nhằm tìm hiểu các cơ chế mã hóa và giải

mã dữ liệu y tế trong quá trình trao đổi qua mạng Internet

Đối tượng nghiên cứu thứ hai là Google Cloud Firestore – một dịch vụ của

Google cung cấp cơ sở dữ liệu thời gian thực trên nền tảng đám mây tích hợp các

thao tác xử lý dữ liệu vào lập trình ứng dụng trên thiết bị di động chạy cả hệ điều

hành Android và iOS Firestore là một trong số rất nhiều các dịch vụ trên nền tảng

đám mây mà Google hỗ trợ không những có thể đáp ứng các yêu cầu cao về tính bảo

mật của hồ sơ y tế mà còn có thể kết hợp với các dịch vụ khác thỏa mãn các nhu cầu

xa hơn trong tương lai như xử lý dữ liệu lớn hay là học máy

Do giới hạn về thời gian, luận văn giới hạn nghiên cứu chuẩn HL7 ở hạng mục

cấp thiết nhất là Quản trị bệnh nhân – cấu trúc bản tin Nhập viện/xuất viện của bệnh

nhân Trên cơ sở đó, một chương trình ứng dụng có chức năng tạo một bản tin tuân

theo chuẩn HL7 đã được thiết kế Ứng dụng này có thể tạo, đọc và tìm kiếm danh

sách bệnh nhân theo chuẩn HL7 trên đám mây mà không đòi hỏi một máy chủ vật lý

nào, đồng thời có thể ứng dụng thử nghiệm trong công tác quản lý đầu vào bệnh nhân

tại các cơ sở y tế, tạo nền tảng để phát triển phần mềm tổng quát quản lý bệnh viện

CHƯƠNG 1 TỔNG QUAN

1.1 Giới thiệu

Việc ứng dụng công nghệ thông tin trong quản lý hệ thống dữ liệu y tế, đặc biệt là hồ sơ sức khỏe điện tử đã lan rộng ra toàn mạng lưới cơ sở bệnh viện, phòng khám từ Trung ương tới địa phương Cho đến nay, việc ghi chép thông tin bằng sổ sách hầu như đã được thay thế bằng các hệ thống máy tính đáp ứng nhu cầu ngày càng tăng về lượng thông tin lưu trữ rất lớn, tốc độ truy cập nhanh phục vụ các bác sĩ trong công tác khám chữa bệnh

“Mỗi người dân có một hồ sơ sức khỏe điện tử được theo dõi và lưu trữ suốt đời.” Câu văn được trích ra từ dự thảo Thông tư Quy định thí điểm về bệnh án điện

tử năm 2018 của Bộ Y tế, thể hiện rõ tầm quan trọng của việc áp dụng công nghệ vào việc hiện đại hóa và đồng bộ hóa các dữ liệu y tế nhằm nâng cao chất lượng dịch vụ chăm sóc sức khỏe cho nhân dân

Vậy, hồ sơ sức khỏe điện tử và bệnh án điện tử là gì? Và cụ thể các lợi ích mà chúng đem lại cho cộng đồng như thế nào?

1.1.1 Khái niệm hồ sơ sức khỏe điện tử

Hồ sơ sức khỏe điện tử là nơi lưu trữ, quản lý toàn bộ thông tin khám chữa của bệnh nhân từ khi sinh ra đến khi mất đi và được thống nhất lưu trữ trong hệ thống hồ

sơ sức khỏe điện tử quốc gia Nó giúp bác sỹ cũng như bệnh nhân chủ động hơn trong việc bảo vệ sức khỏe và chẩn đoán điều trị bệnh tại bất kỳ đâu

Về mặt pháp lý, dự thảo Thông tư của Bộ Y tế [2] định nghĩa:

• Bệnh án điện tử (EMR – Electronic Medical Record) là phiên bản số

của hồ sơ bệnh án, được ghi chép, hiển thị và lưu trữ bằng phương tiện điện tử, có cơ sở pháp lý và chức năng tương đương bệnh án giấy quy định tại Luật Khám bệnh, chữa bệnh

• Hồ sơ sức khỏe điện tử (EHR – Electronic Health Record) là phiên bản

số của hồ sơ sức khỏe giấy do Bộ Y tế quy định được ghi chép, hiển thị

và lưu trữ bằng phương tiện điện tử Mỗi người dân có một hồ sơ sức khỏe điện tử được theo dõi và lưu trữ suốt đời

Hình 1 Hồ sơ y tế điện tử sẽ được triển khai rộng rãi

Hồ sơ sức khỏe điện tử được tạo thành từ nhiều nguồn thông tin, dữ liệu khác nhau bao gồm thông tin – dữ liệu từ các bệnh viện, phòng khám, bác sĩ, nhà thuốc, phòng xét nghiệm Hồ sơ này cung cấp thông tin sức khỏe, tiền sử bệnh tật, quá trình khám chữa bệnh của người bệnh cho thầy thuốc nhanh chóng, chính xác, tạo thuận lợi cho việc chẩn đoán và điều trị bệnh Việc tổng hợp phân tích dữ liệu thông tin quản lý sức khỏe cũng giúp ngành y tế có các chỉ đạo kịp thời về phòng chống dịch bệnh, hoạch định chính sách về công tác bảo vệ, chăm sóc và nâng cao sức khỏe người dân tốt hơn vì có những bằng chứng về thực tiễn, có cơ sở khoa học

Khi người dân đến cơ sở y tế, bác sĩ ở bất kỳ đâu trên lãnh thổ Việt Nam, chỉ cần bấm máy tính là sẽ hiện ra đầy đủ thông tin về hiện trạng sức khỏe của người đó Giúp ích rất nhiều cho chẩn đoán và điều trị Hơn nữa, khi thông tin sức khỏe của người bệnh được thông suốt giữa các tuyến sẽ giúp việc phối hợp điều trị tốt hơn

1.1.2 Thực trạng hồ sơ sức khỏe điện tử tại Việt Nam

Theo Tổng cục thống kê, kết quả Tổng điều tra cho thấy cả nước có hơn một nghìn bệnh viện và hàng chục ngàn cơ sở khám chữa bệnh khác thuộc mọi thành phần kinh tế: nhà nước, ngoài nhà nước và đầu tư trực tiếp nước ngoài Phần lớn các bệnh viện đều đã áp dụng CNTT bằng cách liên kết với các đơn vị cung cấp phần mềm để triển khai hệ thống quản lý cho riêng mình Tuy nhiên, các bệnh viện này đều triển khai những hệ thống phần mềm đơn lẻ, theo từng phòng ban, từng nghiệp vụ Do đó

hệ thống hồ sơ y tế điện tử đã được triển khai nhưng thiết kế riêng theo yêu cầu của bác sỹ, bệnh viện mà không có tính thống nhất Điều này dẫn đến thông tin chỉ sử dụng được trong nội bộ của chính bệnh viện đó

Hình 2 Quản lý hồ sơ bệnh án của BV ĐH Y Dược HCM Khi một bệnh nhân vào khám và chữa bệnh trong một bệnh viện, toàn bộ những quy trình từ đăng ký khám chữa, chụp chiếu, chẩn đoán, điều trị được lưu trữ trong cơ sở dữ liệu nội bộ của bệnh viện đó Khi bệnh nhân nhập viện điều trị ở một bệnh viện khác thì toàn bộ những thông tin về lịch sử khám chữa bệnh rất khó để tham khảo mà phải làm lại trên hệ thống mới Trong một vài trường hợp cần cấp cứu, cần thông tin nhanh về nhóm máu để truyền thì lại phải chờ xét nghiệm bởi trên hệ

thống của bệnh viện chưa có bệnh án điện tử của bệnh nhân trên, dẫn đến một số khó khăn cho việc xử lý tức thời của bác sỹ

Ứng dụng công nghệ thông tin trong y tế được Bộ Y tế quan tâm phát triển một cách cấp thiết trong những năm gần đây Tuy nhiên, đến thời điểm hiện nay thì tất cả các đề án triển khai cho một hệ thống dữ liệu y tế thống nhất chỉ dừng lại ở mức thử nghiệm Tại Hà Nội, phường Phúc Đồng (quận Long Biên) và xã Cổ Bi (huyện Gia Lâm) là hai nơi đầu tiên triển khai thí điểm việc lập hồ sơ quản lý sức khỏe điện

tử vào năm 2017 Ngoài các thông tin về tình trạng sức khỏe, dữ liệu lưu trữ thêm nhóm máu, tên bố mẹ người dân, tên người chăm sóc chính, mã số khám chữa bệnh

Bộ Y tế cũng đã lựa chọn thêm 26 trạm y tế xã thuộc 8 tỉnh, thành gồm: Hà Nội, Thành phố Hồ Chí Minh, Lào Cai, Yên Bái, Hà Tĩnh, Khánh Hòa, Lâm Đồng, Long

An tham gia vào đề án Y tế cơ sở, thực hiện mô hình điểm trạm y tế xã phường giai đoạn 2018-2020 Một trong những nhiệm vụ quan trọng của đề án này là xây dựng

hồ sơ sức khỏe điện tử

1.1.3 Tầm nhìn và thách thức

Việc xây dựng hồ sơ sức khỏe điện tử là một trong những mục tiêu quan trong trong Nghị quyết số 20-NQ/TW năm 2017 của Ban Chấp hành Trung ương khóa XII, phấn đấu đến năm 2030 có 95% dân số được quản lý sức khỏe Tầm nhìn của hồ sơ

y tế điện tử là mỗi bệnh nhân phải được truy cập một cách an toàn và không bị ràng buộc vào các trang thông tin sức khỏe của họ

Tuy nhiên để giải quyết vấn đề này hiện đang gặp nhiều thách thức và trở ngại, đặt ra những yêu cầu về hệ thống phải vượt qua như sau:

• Phải khắc phục khó khăn từ sự thiếu thốn cơ sở vật chất trang thiết bị công nghệ như máy tính, máy chủ có khả năng mở rộng, hạ tầng mạng tốc độ cao

• Dễ sử dụng phù hợp với trình độ tin học của đội ngũ nhân viên, y bác

sĩ vốn chưa quen với thao tác trên máy tính

• Lưu trữ thông tin khám nhanh chóng và kịp thời tại mỗi khâu, việc truy

dữ liệu không bị ùn tắc hoặc mất truy cập

• Có khả năng sửa đổi và nhanh chóng cập nhật theo sự thay đổi của cơ chế chính sách của Bảo hiểm Y tế, mẫu giấy tờ

• Cung cấp cho người bệnh lựa chọn tự xem, sao lưu các kết quả, truy vấn thông tin, lịch sử bệnh án được bác sỹ điều trị thông qua hệ thống này tại nhà Hoặc gửi thông tin khám, điều trị, các kết quả cận lâm sàng, chẩn đoán hình ảnh CT, MRI theo định dạng chuẩn cho các bác sỹ ở xa

mà không phụ thuộc vào không gian và thời gian để hội chẩn với nhau qua mạng

Quan trọng hơn hết là làm sao tất cả thông tin về quá trình điều trị bệnh nhân được lưu trữ suốt đời một cách an toàn và bảo mật mà khi cần kiểm tra chỉ cần những thao tác đơn giản, dễ dàng

1.2 Xây dựng yêu cầu hệ thống

Với hạ tầng công nghệ thông tin và viễn thông hiện nay của Việt Nam, ngành

Y tế có thể đồng bộ hóa quản lý ngành bằng hệ thống Y tế điện tử trên các nhóm vấn

đề như: Khám chữa bệnh, Trao đổi giao tiếp giữa các cơ sở y tế và người bệnh, Y tế

dự phòng, Thuốc và vật tư y tế… Trong phạm vi luận văn, tôi chỉ đề cập đến nội dung xây dựng hệ thống Quản lý công tác khám chữa bệnh nhân có thể trao đổi trực tiếp giữa các cơ sở y tế

1.2.1 Yêu cầu về cơ sở dữ liệu và truy cập

Mỗi công dân khi sinh ra hoặc bắt đầu tham gia hệ thống y tế điện tử sẽ được gắn với một chuỗi ký tự để quản lý (nếu có thể dùng ngay mã số định danh cá nhân hoặc số bảo hiểm y tế) Mỗi cán bộ y tế tham gia công tác khám chữa bệnh được cấp

mã số khám chữa bệnh theo ngạch bậc chuyên môn Các chuỗi ký tự để quản lý bệnh nhân và cán bộ Y tế được thống nhất quản lý toàn quốc

Hệ thống phần mềm phải có các phân hệ kiểm soát thông tin bệnh nhân và phân hệ kiểm soát điều trị người bệnh đó Kể từ lần KCB đầu tiên, người bệnh sẽ

được lưu trữ đầy đủ các thông tin y tế cá nhân và lịch sử KCB, cơ sở KCB và bác sỹ điều trị vào cơ sở dữ liệu và từ đó khởi tạo bản ghi đầu tiên về hồ sơ y tế điện tử

Với các cơ sở dữ liệu được đặt trong máy chủ chuyên dụng, rất nhiều tiêu chí

về cơ sở hạ tầng phải được thỏa mãn cơ bản như phòng máy chủ phải có thiết bị phòng chữa cháy; thiết bị theo dõi nhiệt độ, độ ẩm; thiết bị kiểm soát người vào ra; camera an ninh Phần mềm hệ thống như là hệ điều hành hay hệ quản trị cơ sở dữ liệu vẫn còn được hỗ trợ từ nhà sản xuất, phần mềm giám sát mạng… và rất nhiều tiêu chí tốn kém khác

Do đó việc đưa cơ sở dữ liệu lên lưu trữ ở đám mây (cloud storage) đang là một xu hướng tất yếu vì những lợi ích to lớn mà nó mang lại từ việc tiết kiệm chi phí đầu tư, giảm thời gian triển khai, quản lý thông tin dễ dàng, tận dụng được cơ chế bảo mật và sao lưu của nhà cung cấp, cho đến khả năng mở rộng linh hoạt Việc cần phải làm là chọn lựa ra nhà cung cấp dịch vụ uy tín thỏa mãn được các đòi hỏi khắt khe của hệ thống hồ sơ y tế điện tử

Hơn nữa, dịch vụ lưu trữ đám mây phải hỗ trợ truy cập bằng các thiết bị di động thông minh như điện thoại hay máy tính bảng Đây là các thiết bị gần như không thể thiếu trong đời sống con người ngày nay, chúng hỗ trợ một cách đắc lực cho nhu cầu tìm kiếm và truy xuất thông tin mọi lúc mọi nơi, miễn là có kết nối mạng Internet

1.2.2 Yêu cầu về tính bảo mật

Theo chính sách về bảo mật thông tin và quyền riêng tư của người bệnh, dữ liệu y tế luôn phải được bảo mật chống sao chép và rò rỉ ở mức tối đa Hệ thống phải đáp ứng được nhóm tiêu chí bảo mật và an toàn thông tin như sau:

• Kiểm soát người dùng truy cập hệ thống: người dùng phải xác thực đăng nhập hệ thống, phiên đăng nhập đó cũng được quản lý Mỗi người dùng được phân quyền dựa theo chức năng và nhiệm vụ Người quản

lý có thể truy vết và khóa tài khoản nếu phát hiện ra sai phạm

• Tích hợp chữ ký số: hỗ trợ xác thực trong bệnh án điện tử

• Hệ thống sao lưu và phục hồi dữ liệu: Xây dựng phương án sao lưu và khôi phục phù hợp, việc sao lưu phải được thực hiện hàng ngày

• Phương thức mã hóa dữ liệu, thông tin: Các dữ liệu quan trọng, nhạy cảm có thể được mã hóa bằng các kỹ thuật nhằm tránh mất cắp dữ liệu;

hệ thống quản lý có các bộ khóa giải mã dữ liệu, người dùng có thể giải

mã khi có khóa giải mã; mật khẩu của người dùng được mã hóa;

• Có cơ chế bảo vệ dữ liệu khác như phần mềm diệt virus, hệ thống tường lửa chống xâm nhập từ xa, cơ chế chống tấn công DOS, DDOS Ngoài ra, việc thiết kế hệ thống tối thiểu cần thỏa mãn các yêu cầu sau:

• Yêu cầu về độ tin cậy cao (Reliability): Độ tin cậy cao của hệ thống

được hiểu là khả năng giảm thiếu tần suất xảy ra các sự cố, nói cách khác hệ thống có khả năng chịu đựng các sai sót do thao tác hoặc các nguyên nhân khách quan khác

• Yêu cầu về tính sẵn sàng cao (Availability): Các tài nguyên trên mạng

phải luôn sẵn sàng trong khả năng cao nhất để cung cấp và phục vụ các người dùng cuối và giảm thiểu thời gian ngừng hoạt động hệ thống ngoài ý muốn xuống mức thấp nhất

• Yêu cầu về khả năng mở rộng được (Scalability): Hệ thống phải có khả

năng dễ dàng nâng cấp, mở rộng trong tương lai Việc nâng cấp bao gồm tăng số lượng truy cập người dùng, tăng dung lượng cơ sở dữ liệu lưu trữ, tích hợp các cơ sở dữ liệu có sẵn, cũng như thêm các tài nguyên, dịch vụ mới

1.2.3 Yêu cầu về tiêu chuẩn CNTT

Việc cải tiến mọi quy trình và chuẩn hóa toàn bộ dữ liệu y tế đã giúp hình thành nên rất nhiều chuẩn dữ liệu khác nhau với những mục đích khác nhau trong y

tế Về tiêu chuẩn công nghệ thông tin, hồ sơ y tế điện tử phải áp dụng các tiêu chuẩn sau:

• Tiêu chuẩn HL7 gồm bản tin HL7 phiên bản 2.x hoặc bản tin HL7 phiên bản 3, kiến trúc tài liệu lâm sàng HL7 CDA, HL7 FHIR

• Tiêu chuẩn hình ảnh số và truyền tải trong y tế (DICOM)

• Tiêu chuẩn trao đổi và chia sẻ các chỉ số, siêu dữ liệu thống kê trong lĩnh vực y tế (SDMX-HD)

Hiện tại, tiêu chuẩn HL7 đang được một số đơn vị cung cấp giải pháp phần mềm cho các cơ sở y tế áp dụng Tuy nhiên, chưa có một đơn vị nào cung cấp bệnh

án điện tử đầy đủ và được chuẩn hóa theo các chuẩn chung của thế giới Nếu một hệ thống bệnh án điện tử được đồng nhất và triển khai trên phạm vi toàn quốc, nó sẽ mang lại giá trị to lớn cho những người đang phải đấu tranh với bệnh tật và chi phí phát sinh, và cho cả cộng đồng Nội dung của luận văn sẽ đi sâu tìm hiểu áp dụng chuẩn dữ liệu HL7 – là tiêu chuẩn quốc tế cung cấp giao thức về quản lý, trao đổi và tích hợp thông tin y tế điện tử giữa các hệ thống thông tin y tế

1.3 Tổng quan tiêu chuẩn HL7

1.3.1 Khái niệm chuẩn HL7

HL7 (Health Level Seven), là một chuẩn dành cho viêc trao đổi dữ liệu điện

tử trong môi trường y tế, đặc biệt được tăng cường sử dụng trong các cơ sở y tế chăm sóc bệnh nhân nội trú (chẳng hạn như bệnh viện)

1.3.2 Mục đích của HL7

Mục đích ban đầu của HL7 là để phát triển một chuẩn cho việc trao đổi dữ liệu điện tử giữa các phòng ban với nhau dựa trên hệ thống máy tính Ví dụ như việc trao đổi thông tin giữa hệ thống buồng bệnh, hệ thống phòng thí nghiệm, hệ thống quản trị thuốc

Tiếp theo đó, HL7 tập trung vào cung cấp các tiêu chuẩn dành cho việc trao đổi dữ liệu giữa các ứng dụng máy tính trong lĩnh vực chăm sóc sức khỏe nhằm loại

bỏ hoặc giảm thiểu tối đa việc duy trì chương trình và tùy chỉnh các cổng kết nối nếu không được yêu cầu, tạo điều kiện thuận lợi nhất cho việc kết nối giao tiếp trong các

cơ sở y tế

1.3.3 Lịch sử phát triển của HL7

Đối với con người hay máy tính để có thể chia sẻ dữ liệu với nhau, phải có:

• Các chức năng để có thể giao tiếp vật lý, ví dụ như nghe và nói, gửi và

nhận tài liệu Được gọi là “functional interoperability” – khả năng

tương tác giữa các thành phần chức năng

• Nói một ngôn ngữ chung, ví dụ như ngữ âm, từ vựng và cấu trúc ngữ

pháp Được gọi là “semantic interoperability” – khả năng tương tác ngữ

bộ mã chủ yếu của dữ liệu giữa các hệ thống ứng dụng máy tính trong lĩnh vực chăm sóc sức khỏe

Hiện nay HL7 trở thành chuẩn được công nhận trên toàn cầu, không chỉ phổ biến trong các tiểu bang của Mỹ, mà nó còn được chấp nhận sử dụng trong trao đổi thông tin dạng văn bản trong y tế ở nhiều quốc gia có nền y học và chăm sóc sức khỏe phát triển khác như Úc, Nhật Bản, Hàn Quốc, Trung Quốc, Singapore, Anh, Đức, Hà Lan, Canada…

Hình 3 Lịch sử phát triển của các phiên bản HL7

HL7 được thiết kế để phù hợp với các đòi hỏi của tiêu chuẩn ANSI (American

National Standards Institute – Viện tiêu chuẩn Quốc gia Hoa Kỳ) Hiện tại chuẩn

HL7 v2 vẫn đang thịnh hành phổ biến nhiều nhất trên thế giới Phiên bản HL7 v2.8 được công nhận chính thức tháng 2 năm 2014, nó được dịch ra tiếng Việt và công bố chính thức trên Website của Cục công nghệ thông tin – Bộ Y tế [1]

Năm 2006, HL7 xuất bản chính thức phiên bản HL7 v3.0 Đây là một phiên bản mới của HL7 được bổ sung thêm nhiều phần, ví dụ như phần Kiến trúc tài liệu

lâm sàng (Clinical Documents Architecture - CDA), Mô hình thông tin tham khảo (Reference Information Model – RIM) dùng trong hệ thống thông tin y tế bao gồm:

Đặc điểm loại dữ liệu, định dạng dữ liệu XML, các Từ khóa điều khiển

Năm 2017, FHIR (Fast Health Interoperable Resource) được công bố là một

framework thế hệ mới tổng hợp tất cả các ưu điểm của HL7 v2, HL7 v3 và HL7 CDA đồng thời tận dụng được sự phát triển của công nghệ Web (các RESTful web service)

Trong tương lai không xa, người ta sẽ dần chuyển sang các chuẩn HL7 thế hệ mới hơn

“Level Seven” ý nói đến tầng ứng dụng - tầng cao nhất của mô hình kết nối hệ thống mở (OSI – Open System Interconnection) của Tổ chức các tiêu chuẩn quốc tế (ISO – International Standards Organization) HL7 chủ yếu tập trung vào các vấn đề

xảy ra ở tầng ứng dụng – đây là định nghĩa dữ liệu được trao đổi, thời gian của viêc trao đổi và truyền thông của các lỗi ứng dụng đặc thù giữa các ứng dụng

Vậy, tiêu chuẩn HL7 bao gồm những nội dung gì? Nguyên tắc mã hóa như thế nào? Cấu tạo các bản tin ra sao? Và ý nghĩa cụ thể của từng bản tin như thế nào? Chương tiếp theo sẽ trình bày các kiến thức lý thuyết nền tảng của chuẩn HL7

CHƯƠNG 2 CHUẨN HL7 TRONG TRAO ĐỔI DỮ LIỆU Y TẾ

2.1 Chuẩn trao đổi dữ liệu y tế HL7

Phiên bản HL7 2.8 được xuất bản năm 2014 là bản sửa đổi bổ sung sau quá trình xem xét lại tổng thể phiên bản 2.7, điều chỉnh và cập nhật các bản tin hiện có và thêm vào những bản tin mới và các lĩnh vực dựa trên các đề xuất đã được gửi đến tổ chức HL7 và được chấp thuận bởi các thành viên Phiên bản 2.8 đã được Bộ Y tế dịch

ra tiếng Việt và công bố chính thức trên trang mạng của Cục Công nghệ thông tin [1] cũng như trên trang chủ của tổ chức HL7 Vì lẽ đó, các kiến thức liên qua tới chuẩn HL7 trong luận văn được tham khảo và trích dẫn dựa trên phiên bản 2.8

Nội dung của chuẩn HL7 bao gồm:

• Cấu trúc tổng thể của tất cả giao diện bao gồm giao diện truy vấn chung

• Quản trị bệnh nhân (nhập viện, ra viện, chuyển tuyến)

• Danh mục chỉ định

• Hệ thống tính viện phí

• Dữ liệu theo dõi lâm sàng

• Một giao diện tổng quát cho việc đồng bộ hóa các tập tin tham khảo chung (tập tin chủ)

• Quản trị thông tin y khoa

• Danh mục bệnh nhân, danh mục tài nguyên

• Các bản tin tham khảo của bệnh nhân dùng cho hội chẩn giữa 2 viện khác nhau

• Các bản tin chăm sóc bệnh nhân hỗ trợ cho việc thông tin về các chứng bệnh nan y, và cung cấp chức năng cách thức thực thi lâm sàng trong

hệ thống vi tính

Do nội dung của tiêu chuẩn rất rộng và nhiều chi tiết phức hợp từ thông tin văn bản về lý lịch bệnh nhân cho đến những thông tin liên kết quản lý hình ảnh trong việc khám chẩn đoán lam sàng, liên kết với cơ sở dữ liệu về quản lý tài chính, bảo

hiểm xã hội…, luận văn chỉ giới hạn nghiên cứu chuẩn HL7 từ các kiến thức cơ sở

và tập trung vào nội dung cấp thiết nhất là các bản tin liên quan tới danh mục Quản trị bệnh nhân Tiêu chuẩn HL7 có nguyên tắc mã hóa như thế nào?

2.1.1 Nguyên tắc mã hóa trong HL7

➢ Các trường dữ liệu được kết hợp lại thành các nhóm logic được gọi là các đoạn Các đoạn được ngăn cách bởi ký tự phân đoạn

➢ Mỗi đoạn bắt đầu bởi một giá trị chữ 3 ký tự (ví dụ MSH, EVN, PID…), giá trị này được nhận dạng trong một bản tin

Bộ ký tự hiển thị mã ASCII là bộ ký tự mặc định trừ khi có sự thay đổi trong đoạn tiêu đề MSH (Message Header Segment – trình bày ở mục 2.2.1)

➢ Ký tự ngăn cách trường phải được chọn từ sự thiết lập ký tự hiển thị mã ASCII

➢ Ký tự phân đoạn là ký tự mã ASCII Carriage Return (ký tự xuống dòng)

2 – Đoạn loại sự kiện

EVN|01|199801181005||<CR>

3 – Đoạn xác nhận bệnh nhân

PID|||PATID1234567||Doe^John^B^II||19470701|M||C|371 MAINAVE^SAN FRANCISCO^CA^94122-0619||45-681-2888| | | | | | | |<CR>

4 – Đoạn thân nhân bệnh nhân

NK1||Doe^Linda^E||wife|<CR>

5 – Đoạn thông tin nhập viện

PV1|1|I|100^345^01||||00135^SMITH^WILLIAM^K|||SUR|ADM|<CR> Lần lượt giải mã từng đoạn trong bản tin, sau đó kết hợp lại ta thu được những thông tin sau: “Bệnh nhân John B Doe, II, có mã bệnh nhân là 1234567, nam giới,

da trắng, sinh ngày 1 tháng 7 năm 1947, sống tại 371 Avenue-Sanfrancisco, nhập viện ngày 18 tháng 1 năm 1998 hồi 10 giờ 05 phút sáng, được bác sỹ William K.Smith xét nghiệm và điều trị Bệnh nhân được chỉ định nằm viện tại giường số 01, phòng 345,

tổ chăm sóc 100 Phần thân nhân có vợ là Linda E.Doe, bản tin được gửi từ Mission tới Mine sau khi bệnh nhân nhập viện 2 phút.”

2.1.2 Các khái niệm cơ sở

2.1.2.1 Sự kiện kích hoạt (trigger event)

HL7 giả định rằng một sự kiện y tế diễn ra trong thế giới thực tạo ra sự cần thiết cho luồng dữ liệu giữa các hệ thống Các sự kiện diễn ra trong thế giới thực được gọi là sự kiện kích hoạt Ví dụ, sự kiện kích hoạt “một bệnh nhân vào viện” có thể là nguyên nhân dẫn đến nhu cầu về dữ liệu bệnh nhân đó được gửi đến một số hệ thống thông tin khác Sự kiện kích hoạt, kết quả quan sát (ví dụ, kết quả xét nghiệm viêm gan B) cho một bệnh nhân tồn tại trên hệ thống, có thể là nguyên nhân gây ra nhu cầu gửi dữ liệu/thông tin kết quả xét nghiệm tới một số hệ thống thông tin khác Khi việc chuyển giao hoặc trao đổi thông tin được kích hoạt bởi các sự kiện kích hoạt từ các phần mềm ứng dụng CNTT, những bản tin trao đổi này được gọi là bản tin cập nhật

không mong muốn (đây là những bản tin cập nhật thông tin một cách hoàn toàn tự động)

Chú ý: Không có giả thiết được đưa ra về các thiết kế, kiến trúc của ứng dụng/hệ thống tạo ra các bản tin cập nhật không mong muốn Phạm vi của HL7 được giới hạn trong các đặc điểm kỹ thuật của những bản tin trao đổi giữa các ứng dụng/hệ thống thông tin và các sự kiện kích hoạt chúng

HL7 cho phép việc sử dụng các sự kiện kích hoạt ở các cấp độ khác nhau về mức độ chi tiết và mối quan hệ bên trong của dữ liệu Ví dụ, hầu hết các sự kiện kích hoạt quản lý bệnh nhân (ADT) liên quan đến đối tượng đơn lẻ duy nhất (chẳng hạn như sự kiện vào viện khởi tạo một bản tin chứa dữ liệu về một người và/hoạt tài khoản duy nhất) Sự kiện kích hoạt ADT khác liên quan đến mối quan hệ giữa nhiều đối tượng (ví dụ, các sự kiện hợp nhất, trong đó quy định việc sáp nhập thông tin bệnh nhân hoặc tài khoản) Một số sự kiện kích hoạt ADT liên quan đến việc thu thập các đối tượng liên quan bao gồm các đối tượng không quan trọng (ví dụ, việc truy vấn các bản ghi liên quan dựa theo vị trí, mà thông tin phản hồi sẽ chứa toàn bộ dữ liệu liên quan đến bệnh nhân nội trú mang tính tạm thời, theo vị trí địa lý)

2.1.2.2 Phản hồi báo nhận (acknowledgment): Phương thức cơ bản

Khi bản tin cập nhật tự động gửi đi từ một hệ thống đến một hệ thống khác, chế độ phản hồi này xác định rằng bản tin được thừa nhận ở mức ứng dụng Lý do là chế độ này không có đủ cơ sở để nhận biết rằng việc các hệ thống thông tin liên lạc được đảm bảo trong quá trình truyền bản tin Nó cũng cần biết rằng ứng dụng nhận

xử lý dữ liệu thành công ở mức độ ứng dụng logic

Việc báo nhận có thể chứa dữ liệu liên quan đến hệ thống khởi tạo quá trình trao đổi Ví dụ, nếu một hệ thống chăm sóc bệnh nhân đã xử lý các sự kiện kích hoạt chỉ định xét nghiệm cho một bệnh nhân, hệ thống này có thể gửi một bản tin cập nhật

tự động đến hệ thống thông tin phòng xét nghiệm nhằm xác định bệnh nhân, chỉ định xét nghiệm và các thông tin khác nhau liên quan đến chỉ định xét nghiệm Các hệ thống phụ trợ sẽ phản hồi báo nhận chỉ định khi nó đã xử lý các thông tin thành công

Tiêu chuẩn HL7 không xây dựng quy định về quyền sở hữu dữ liệu Tiêu chuẩn cũng không xây dựng những yêu cầu riêng về các hành động tiếp theo của đối tượng nhận dữ liệu, cũng như không xây dựng bất kỳ quy định về thiết kế, kiến trúc của các

hệ thống ứng dụng nhận thông tin Phạm vi của tiêu chuẩn HL7 được giới hạn trong các đặc điểm kỹ thuật của các bản tin trao đổi giữa các phần mềm ứng dụng và các

sự kiện kích hoạt chúng

Tiêu chuẩn HL7 không quy định các chức năng cần thiết trong một hệ thống thông tin nhằm xử lý dữ liệu từ một bản tin và lưu trữ dữ liệu vào cơ sở dữ liệu (CSDL) trước khi thừa nhận chúng Tất cả những gì được yêu cầu là hệ thống tiếp nhận hoàn toàn chịu trách nhiệm về dữ liệu, cung cấp các cơ chế hoặc chức năng để kiểm tra tính toàn vẹn của dữ liệu từ bất cứ nguồn nào Để tiếp tục ví dụ trước, các

hệ thống thông tin phụ trợ có thể báo nhận chỉ định sau khi đặt chỉ định trong một hàng đợi đầu vào, những chỉ định này chờ đợi để được xử lý theo đúng trình tự và lưu trữ vào cơ sở dữ liệu tại một thời điểm trong tương lai Giả định rằng hàng đợi đầu vào được duy trì ở cùng một mức độ toàn vẹn như CSDL Những thực thể của bản tin tạm thời không được chấp thuận bởi đối tượng gửi và/hoặc đối tượng nhận sau khi báo nhận

2.1.2.3 Phản hồi báo nhận: Phương thức tăng cường

Mô hình phản hồi HL7 đã được mở rộng để phân biệt cả hai việc phản hồi chấp nhận và phản hồi ứng dụng, cũng như các điều kiện theo mỗi yêu cầu Với một phản hồi chấp thuận tích cực, hệ thống tiếp nhận và lưu giữ bản tin vào bộ lưu trữ an toàn theo cách thức phát hành của hệ thống gửi, trong trường hợp cần thiết hệ thống gửi sẽ gửi lại bản tin Sau khi bản tin đã được xử lý bởi hệ thống tiếp nhận, một phản hồi ứng dụng có thể được sử dụng để thông báo trạng thái kết quả cho hệ thống gửi

2.1.2.4 Các truy vấn

Một trao đổi dữ liệu khác xảy ra khi một hệ thống gởi một truy vấn đến hệ thống khác Ví dụ, trong ứng dụng thông tin, có thể có một sự kiện kích hoạt “một thủ tục được lên lịch” cho bệnh nhân người chưa đăng ký sẵn trong cơ sở dữ liệu của ứng dụng thông tin Ứng dụng có thể gởi một bản tin yêu cầu chứa mã ID của bệnh

nhân đến hệ thống quản trị và nhận một đáp ứng chứa dữ liệu cần thiết để cho phép

xử lý yêu cầu Giao dịch gởi yêu cầu này là một truy vấn Thông tin chảy giữa các hệ thống được chứa trong đáp ứng Bản thân đáp ứng không nhận một bản tin thứ 3

Trong tất cả trường hợp, chuẩn HL7 gồm một trao đổi đơn giản bản tin giữa một cặp ứng dụng: sự cập nhật tự động và sự nhận của nó hoặc truy vấn và đáp ứng của nó Mô hình hoạt động lớp dưới là mô hình của máy khách và máy chủ Một ứng dụng tương tác với ứng dụng khác dùng một mã sự kiện mà xác định giao dịch Ứng dụng khác đáp ứng với một bản tin mà gồm dữ liệu hoặc một biểu thị lỗi Ứng dụng khởi tạo có thể nhận một trạng thái đẩy ra từ ứng dụng khác hoặc từ phần mềm cấp thấp chỉ ra rằng bản tin của nó không được nhận đúng

Truy vấn HL7 có thể được đặt công thức dùng một trong vài phương pháp sau:

1 “Bộ lọc truy vấn” HL7, định nghĩa thông qua đoạn QRD và QRF Những

bộ lọc này hỗ trợ như trong các ấn bản trước của HL7, và được tham khảo theo truy vấn “phương thức cơ bản”

2 Ngôn ngữ truy vấn nhúng chọn câu lệnh, mà ngôn ngữ đó làm cho hệ thống truy vấn có thể định dạng yêu cầu như là một câu lệnh truy vấn dạng tự do (free-form), sử dụng ngôn ngữ truy vấn của sự chọn lựa (VD, SQL)

3 Bảng yêu cầu ảo, có chức năng tương tự bản tin Ngôn ngữ truy vấn nhúng, nhưng định dạng nghiêm ngặt hơn với các phân cách

4 Các yêu cầu thủ tục lưu trữ, mã đơn vị của chương trình trên hệ thống đáp ứng mà được xây dựng để thỏa mãn một truy vấn chỉ định (VD, định nghĩa trước các truy vấn, thủ tục lưu trữ SQL)

Do các truy vấn định nghĩa trước hỗ trợ bởi HL7 bị giới hạn về số lượng và định nghĩa chính xác, mỗi truy vấn có một tên thủ tục lưu trữ tương ứng và danh sách thông số liên đới với nó

5 Các truy vấn lặp lại sự kiện, là yêu cầu cho dữ liệu định dạng như là bản tin

sự kiện HL7 bao gồm các câu lệnh lựa chọn SQL như một phương tiện thay thế tiêu chuẩn lựa chọn truy vấn mã hóa Sự thay thế này được đề nghị như là một quy ước

cho các phần thực thi, và không có ngụ ý hệ thống máy chủ phải hỗ trợ SQL chung hoặc phải dựa trên kỹ thuật cơ sở dữ liệu có liên quan

2.1.3 Môi trường truyền thông

Chuẩn HL7 định nghĩa bản tin khi chúng được trao đổi giữa thực thể ứng dụng

và thủ tục dùng để trao đổi chúng Như là nó hoạt động một cách khái niệm ở cấp 7 của mô hình ISO cho Hệ thống mở kết nối trung gian (Open System Interconnection – OSI) Nó có liên quan chính với nội dung dữ liệu và mối tương quan của bản tin và với việc truyền thông các cấp ứng dụng trong điều kiện lỗi

Do tài nguyên OSI không thực thi toàn bộ, nhóm làm việc HL7 quan tâm đến cung cấp chuẩn mà sẽ hữu dụng trong thời gian tới HL7 cũng nhận ra rằng hiện tại

và sẽ tiếp tục quan tâm đến truyền thông dữ liệu chăm sóc sức khỏe giữa các hệ thống hoạt động trong môi trường truyền thông mà cung cấp một cấp độ cao về chức năng, nhưng sử dụng tài nguyên khác hơn là ISO OSI Toàn bộ môi trường quan tâm của HL7 gồm:

❖ Các môi trường không dự tính trước mà không cung cấp ngay cả sự ổn định vận chuyển cơ bản Các môi trường đó bao gồm liên kết điểm đến điểm RS-

232, modem, và ngay cả LAN, nếu sự nối kết với máy chủ của chúng được làm qua giao tiếp RS-232 Cho đến khi chuẩn cấp cao OSI trở thành thực sự phổ biến, nhiều giao diện của chăm sóc sức khỏe sẽ thực thi trên các kết nối

đó Trong một môi trường như vậy, tài nguyên cấp thấp hơn HL7 (Lower Level Protocols – LLP) có thể được dùng giữa các hệ thống để tăng khả năng của môi trường truyền thông Tài nguyên cấp thấp hơn HL7 được định nghĩa trong hướng dẫn thực thi HL7, không phải là một phần chính thức của chuẩn

❖ Các môi trường mà hỗ trợ một cấp vận chuyển mạnh mẽ, nhưng không phù hợp với yêu cầu mức cao Điều này bao gồm các môi trường như là TCP/IP, DECNET, và SNA

❖ ISO và tính sở hữu công việc mạng mà thực thi đến một dịch vụ trình diễn và dịch vụ cấp cao khác IBM’s SNA LU6.2 và SUN Microsystem’s NFS là các

ví dụ về tính sở hữu công việc mạng hoàn chỉnh

❖ Hai hay nhiều ứng dụng đang chạy trên cùng một máy vật lý và/hoặc máy luận

lý mà không tích hợp chặt Trong những môi trường này, khả năng bản tin có thể được cung cấp bởi một dịch vụ truyền thông xử lý trung gian (VD, các ống (pipelines) trong hệ thống UNIX)

Chuẩn HL7 giả định rằng môi trường truyền thông sẽ cung cấp các khả năng sau:

➢ Sự truyền không lỗi Các ứng dụng có thể giả định rằng chúng nhận

chính xác tất cả byte truyền trong cách chính xác mà chúng được gửi

đi Điều này ngầm định rằng việc kiểm tra lỗi được làm ở mức thấp hơn.Tuy nhiên ứng dụng gửi có thể không giả định rằng bản tin được nhận thực sự không nhận một bản tin nhận

➢ Sự chuyển đổi ký tự Nếu hai máy trao đổi dữ liệu dùng các đặc trưng

khác nhau của cùng một tập ký tự, môi trường truyền thông sẽ chuyển

dữ liệu từ một đặc trưng này đến đặc trưng khác

➢ Chiều dài bản tin HL7 không giới hạn về kích cỡ tối đa của bản tin

HL7 Chuẩn giả định rằng môi trường truyền thông có thể vận chuyển bản tin của bất kỳ chiều dài nào mà có thể cần thiết Thực tế, các bên

có thể đồng ý đặt vài giới hạn trên cho kích thước bản tin và có thể dùng tài nguyên bản tin liên tục cho bản tin vượt quá giới hạn trên

Chú ý: Chỉ khi HL7 không làm giả định về thiết kế hoặc kiến trúc của hệ thống ứng dụng gửi và nhận bản tin HL7, nó không giả định về môi trường truyền thông đến những điều kể trên Ngoài ra, từ những giả định trên, môi trường truyền thông, gồm kiến trúc của nó, thiết kế và thực thi là ngoài vùng của HL7

2.1.4 Khung bản tin

Mục này sẽ xác định các thành phần của bản tin, đồng thời cung cấp các phương pháp luận để định nghĩa các bản tin lý thuyết được sử dụng trong các chương sau

2.1.4.1 Bản tin

Một bản tin là một đơn vị cơ sở của trao đổi dữ liệu giữa các hệ thống Nó gồm một nhóm đoạn trong một trình tự đã định nghĩa Mỗi bản tin có một loại bản tin dùng định nghĩa mục đích của nó Ví dụ loại bản tin ADT được dùng để truyền các phần của dữ liệu quản trị bệnh nhân (ADT – Patient Administration) từ hệ thống này đến hệ thống khác Mã 3 ký tự chứa bên trong mỗi bản tin xác định loại của nó

Những mã này được liệt kê trong bảng Loại bản tin [1]

Các sự kiện xảy ra trong thế giới thực sẽ khởi tạo hoặc kích hoạt cho một phiên trao đổi bản tin được gọi là một sự kiện kích hoạt Các mã này sẽ đại diện cho các giá trị hay mục tiêu của sự kiện chẳng hạn như sự kiện bệnh nhân nhập viện hay sự kiện chỉ định Mối quan hệ một-nhiều giữa kiểu (loại) bản tin và mã sự kiện kích hoạt Một mã sự kiện kích hoạt không thể kết hợp với nhiều loại bản tin; ngược lại một loại bản tin cũng có thể kết hợp với nhiều mã sự kiện kích hoạt

Tất cả các mã loại bản tin và mã sự kiện kích hoạt bắt đầu với ký tự “Z” đều

là loại bản tin và sự kiện được định nghĩa theo vùng địa phương (do nhu cầu người

sử dụng) Mã Z SẼ KHÔNG được định nghĩa trong tiêu chuẩn HL7

Hình 4 Các phần cấu thành nên một bản tin HL7

2.1.4.2 Phân đoạn và nhóm phân đoạn

Một phân đoạn dữ liệu (phân đoạn) là một nhóm bao gồm các trường dữ liệu được sắp xếp theo một trật tự nhất định Phân đoạn dữ liệu của một bản tin có thể được quy định là bắt buộc hoặc tùy chọn (không bắt buộc) Chúng có thể xuất hiện một lần hoặc xuất hiện lặp đi lặp lại nhiều lẩn trong một bản tin Mỗi một phân đoạn

dữ liệu đều có một tên riêng duy nhất Ví dụ, phân đoạn tiêu đề bản tin (MSH), phân đoạn loại sự kiện (EVN), phân đoạn định danh bệnh nhân (PID), phân đoạn bệnh nhân thăm khám (PV1)

Ví dụ, bản tin ADT có thể chứa các đoạn sau: đoạn tiêu đề (MSH – message header segment), đoạn loại sự kiện (EVN – event typesegment), đoạn mã bệnh nhân (PID – patient identify segment), và đoạn thân nhân bệnh nhân (NK1 – next of kin segment)

Mỗi một phân đoạn được định danh bởi một bộ bao gồm 3 ký tự duy nhất, bộ

ba ký tự này được gọi là mã định danh phân đoạn (ID phân đoạn)

Tất cả các mã định danh phân đoạn bắt đầu bằng ký tự Z được định nghĩa theo mục đích sử dụng của vùng địa phương (do người sử dụng tự định nghĩa) Các mã Z

SẼ KHÔNG được quy định trong tiêu chuẩn HL7

Hai hoặc nhiều phân đoạn được sắp xếp theo thứ tự được gọi là một nhóm phân đoạn Một nhóm phân đoạn được quy định có thể là bắt buộc, tùy chọn và lặp lại, tức là nhóm phân đoạn có thể xuất hiện một lần hoặc lặp đi lặp lại nhiều lần, hoặc không xuất hiện Một nhóm phân đoạn được án một tên đại diện duy nhất không đổi

2.1.4.3 Trường

Một trường là một chuỗi ký tự Khi trường được truyền đi, chúng được gởi như là các chuỗi ký tự Ngoại trừ nơi nào có ghi chú, trường dữ liệu HL7 có thể chứa giá trị rỗng Việc gửi giá trị rỗng, mà được truyền trong dấu (“”), thì khác với việc bỏ sót một trường dữ liệu tùy chọn Sự khác biệt này xảy ra khi nội dung của bản tin sẽ được dùng để cập nhật một bộ dữ liệu trong cơ sở dữ liệu hơn là tạo ra một bộ dữ liệu mới

Nếu không có giá trị nào được gửi, (ngoại trừ bị bỏ quên) giá trị cũ nên giữ không đổi Nếu giá trị rỗng được gửi đi, giá trị cũ nên được đổi thành giá trị rỗng Các chương khác nhau của chuẩn chứa bảng thuộc tính đoạn Những bảng này liệt kê

và mô tả các trường dữ liệu trong đoạn và đặc điểm cách dùng của chúng Trong việc định nghĩa đoạn, thông tin sau được quy định cụ thể về mỗi một trường dữ liệu:

➢ SEQ: Vị trí hoặc số thứ tự

➢ LEN: Kích thước dữ liệu hoặc chiều dài của chuỗi theo quy chuẩn

➢ C.LEN: Kích thước dữ liệu phù hợp

➢ DT: Loại dữ liệu

➢ OPT: Tùy chọn

➢ RP/#: Số lần lặp lại

➢ TBL#: Mã số định danh bảng tham chiếu

➢ ITEM#: Số ID định danh trường dữ liệu

➢ Element Name: Tên trường dữ liệu

a/ Vị trí (Thứ tự trong một đoạn)

Thứ tự thông thường của trường dữ liệu trong đoạn Con số này được dùng để tham khảo đến nơi trường dữ liệu được ghi Trong bảng thuộc tính đoạn, thông tin

này được cung cấp trong cột có nhãn SEQ

b/ Chiều dài tối đa

Số ký tự tối đa mà trường dữ liệu có thể có Chiều dài tối đa không phải là khái niệm quan trọng trong bản tin tóm tắt hoặc quy tắc mã hóa HL7 Chiều dài của một trường mang tính quy chuẩn Tuy nhiên trong thực tế nhìn chung nó thường được dàn xếp trên một nền cơ bản đã chỉ định Nó được tính toán để bao gồm các ký hiệu phân tách thành phần và thành phần con Bởi vì chiều dài tối đa là chiều dài của một

sự kiện duy nhất, ký hiệu phân cách sự lặp lại ( \ ) không chứa trong phần tính toán chiều dài tối đa Trong bảng thuộc tính trường thông tin này chứa trong cột có nhãn

là LEN

thay đổi loại dữ liệu, cột DT sẽ được ký hiệu là “varies”

Loại dữ liệu có thể là loại dữ liệu cơ bản hoặc loại dữ liệu phức hợp

➢ Loại dữ liệu cơ bản (Primitive) bao gồm một chuỗi các ký tự xác định

rõ nội dung của loại dữ liệu

➢ Loại dữ liệu phức hợp (Composite) được cấu thành bởi các thành phần

dữ liệu, mỗi một thành phần là một loại dữ liệu, thành phần dữ liệu có thể là loại dữ liệu cơ bản hoặc loại dữ liệu phức hợp Những thành phần

dữ liệu con là thành phần có loại dữ liệu cơ bản

Lưu ý: Loại dữ liệu không xác định hoặc cho biết phương thức lưu trữ dữ liệu của các ứng dụng Khi trường dữ liệu truyền tải dữ liệu, chúng sẽ truyền tải chuỗi các

ký tự xác định rõ loại dữ liệu

Loại dữ

liệu

Tên loại dữ liệu Ghi chú/Định dạng

Kiểu vừa chữ vừa số

<số lượng (NM)>^<đơn vị (CE)>

MO Tiền tệ (Money)

Kiểu nhận dạng (Identifier – ID)

ID Mã hóa các giá trị

cho bảng HL7

IS Mã hóa các giá trị

cho bảng do người dùng định nghĩa

RP Điểm tham khảo

(Reference

pointer)

<Chỉ điểm (ST) >^<ID ứng dụng (HD)>^<loại

dữ liệu (ID)>^<loại con (ID)>

PT Loại xử lý

(Processing type)

<ID xử lý (ID)>^<chế độ xử lý (ID)>

Kiểu ngày giờ (Date/Time)

TM Thời gian (Time) HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]

TS Dấu thời gian

(Timestamp)

YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]][+/- ZZZZ]^<độ chính xác>

Nhân khẩu học

AD Địa chỉ (Address) <Địa chỉ đường (ST)>^< sự thiết kế khác

(ST)>^<thành phố (ST)>^<tiểu bang hoặc tỉnh (ST)>^<mã tỉnh hoặc mã bưu điện (ST)>^<đất nước (ID)>^<loại dữ liệu (ID)>^<tên địa lý khác (ST)>

PN Tên người

(Person name)

<tên gia đình (ST)>^<tên được đặt (ST)>^<tên đệm hoặc tên (ST)>^<hậu tố (VD, JR hoặc III) (ST)>^<tiền tố (VD, DR) (ST)>^<cấp độ (VD, MD) (ST)>

TN Số điện thoại

(Telephone

number)

[NN] [(999)]999-9999[X99999][B99999][C văn bản bất kỳ]

Bảng 1 Các loại dữ liệu HL7 cơ bản

RE Bắt buộc nhưng có thể trống (không có dữ liệu)

O Tùy chọn (không bắt buộc)

C (a/b) Điều kiện dựa trên sự kiện kích hoạt hoặc trường dữ liệu khác Những

định nghĩa trường dữ liệu theo bảng thuộc tính của phân đoạn nên xác định rõ thuật toán định nghĩa cho trường dữ liệu này

X Không sử dụng cùng với sự kiện kích hoạt này

B Tương thích ngược với phiên bản trước của HL7 Định nghĩa trường dữ

liệu này trong bảng thuộc tính của phân đoạn sẽ được ký hiệu là tùy chọn cho phiên bản tiêu chuẩn trước đây

Bảng 2 Bảng các loại tùy chọn

e/ Sự lặp lại

Trong trường hợp trường dữ liệu lặp lại Giá trị xuất hiện ở cột lặp lại là một

số tự nhiên cho biết số lần tối đa mà trường dữ liệu này có thể xuất hiện trong phân đoạn, ví dụ: giá trị ‘3’ có nghĩa là trường dữ liệu có thể xuất hiện tối đa 3 lần; nếu cột lặp lại không xác định rõ giá trị hoặc không có giá trị, trường dữ liệu có thể xuất hiện một lần, có nghĩa là trường dữ liệu không lặp lại

Trong bảng thuộc tính phân đoạn, thông tin lặp lại này được cung cấp ở cột có

tên RP#

N Không lặp lại

Y Trường có thể lặp lại một số lần không xác định

(integer) Trường có thể lặp lại trên số lần xác định bởi số integer

Vẫn còn có các trường khác chứa giá trị được mã hóa bằng cách tham khảo đến các tài liệu chuẩn khác VD trường mã hóa cho các thủ tục của thư viện được định nghĩa bởi chuẩn ASTM E1238-94 Loại dữ liệu CE được dùng để mã hóa các giá trị cho những trường này

Cuối cùng, có vài bảng người dùng định nghĩa chứa giá trị có thể được chuẩn hóa qua các cơ quan nhưng không thể áp dụng chuẩn văn phòng tồn tại cho các cơ quan đó Những giá trị đề nghị xuất hiện trong văn bản dưới định dạng không hộp tiêu chuẩn (standard non-boxformat) Người ta mong chờ rằng những giá trị này sẽ được sử dụng nơi mà khả năng ứng dụng trong một cơ quan và dùng như một cơ sở cho sự mở rộng khi có yêu cầu Ủy ban chức năng thích hợp trong HL7 thu hút các

đề nghị cho các giá trị thêm từ các cơ quan áp dụng chuẩn

Các loại dữ liệu HL7 khác nhau (AD, CD, CE, CF, CK, CM, CN, CP, CQ,CX, DLN, ED, EI, FC, ID, IS, JCC, MO, HD, PL, PPN, PT, QSC, RI, RP, SCV, TQ, VH, XAD, XCN, XON, XPN, và XTN) được dùng để vận chuyển các giá trị xếp thành bảng, hoặc có một thành phần chứa các giá trị xếp thành bảng Trong bảng thuộc tính đoạn, thông tin này được cung cấp trong cột có nhãn là TBL# Ngoại trừ duy nhất là loại dữ liệu CE và CF, chứa định danh bảng là một phần của định nghĩa loại dữ liệu

2.1.5 Các ký tự ngăn cách trong bản tin

Trong quá trình xây dựng bản tin, các ký tự đặc biệt được sử dụng Chúng là

bộ các ký tự đặc biệt nhằm báo hiệu sự chấm dứt của một phân đoạn, ngăn cách giữa các trường dữ liệu, ngăn cách giữa các thành phần dữ liệu, ngăn cách giữa các thành phần dữ liệu con, ngăn cách giữa các dữ liệu lặp lại, ký tự escape ‘\’ và ký tự rút gọn

Ký tự báo hiệu chấm dứt hoặc ngăn cách giữa các phân đoạn luôn luôn là ký tự xuống dòng và bắt đầu một dòng mới (trong bảng mã ASCII, ký tự này có mã là 0D theo hệ thập lục phân)

Những ký tự ngăn cách khác được định nghĩa trong phân đoạn tiêu đề MSH của bản tin, trường dữ liệu này quy định bốn vị trí theo thứ tự đã được định nghĩa sẵn, trường dữ liệu này được gọi là trường dữ liệu mã hóa, vị trí của trường dữ liệu này là

vị trí đầu tiên trong phân đoạn MSH đứng sau mã định danh của phân đoạn MSH Bộ

ký tự ngăn cách được xác định trong phân đoạn tiêu đề MSH là các ký tự ngăn cách được sử dụng xuyên suốt trong toàn bộ bản tin Trong trường hợp không có những