Trao đổi hồ sơ bệnh án điện tử giữa các bệnh viện theo chuẩn quốc tế HL7

Lịch sử chuẩn HL7 message Với mục đích cung cấp một quy định chuẩn chung cho việc trao đổi, quản lý và tổng hợp dữ liệu y tế, quản lý các dịch vụ chăm sóc sức khỏe, bằng cách định nghĩa

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

HÀ NỘI - 2015

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

LỜI CẢM ƠN

Trước tiên, tôi xin gửi lời cảm ơn chân thành nhất tới cô giáo TS Nguyễn Thị

Huyền Châu, giảng viên Bộ môn Công Nghệ Phần Mềm – Khoa Công Nghệ Thông Tin

– Trường Đại Học Công Nghệ -ĐHQGHN Trong thời gian học và làm luận văn tốt nghiệp, cô đã dành nhiều thời gian quý báu và tận tình chỉ bảo, hướng dẫn tôi trong việc nghiên cứu, thực hiện luận văn

Tôi xin bày tỏ lòng biết ơn tới các thầy cô và các bạn học viên cùng học tập, nghiên cứu tại khoa Công Nghệ Thông Tin, trường Đại Học Công Nghệ, ĐHQGHN đã tạo mọi điều kiện để tôi có kết quả học tập tốt nhất trong suốt quá trình học tập

Luận văn này có được một số kết quả nhất định đang đi vào thực tế một số bệnh viện (hiện đang ở mức kiểm thử phòng lap), tuy nhiên không thể tránh khỏi sai sót và hạn chế Kính mong được sự cảm thông và đóng góp ý kiến của các thầy giáo, cô giáo và các bạn học viên

Cuối cùng và cũng là quan trọng nhất, tôi xin gửi lời cảm ơn tới gia đình Nếu không

có tình yêu, sự ủng hộ và động viên từ gia đình tôi sẽ không thể hoàn thành khoá luận và

có được những kết quả như ngày hôm này

Hà Nội, Ngày 02 Tháng 12 Năm 2015

Dương Đình Toan

LỜI CAM ĐOAN

Tôi xin cam đoan rằng, đây là kết quả nghiên cứu của tôi trong đó có sự giúp đỡ rất lớn của thầy hướng dẫn và các đồng nghiệp ở cơ quan Các nội dung nghiên cứu và kết quả trong đề tài này hoàn toàn trung thực

Trong luận văn, tôi có tham khảo đến một số tài liệu của một số tác giả đã được liệt kê tại phần tài liệu tham khảo ở cuối luận văn

Hà nội, tháng 12 năm 2015 Học viên thực hiện

Dương Đình Toan

DANH MỤC HÌNH VẼ

Hình 1.1: Lịch sử phát triển HL7 [3] 4

Hình 1.2: Kiến trúc HL7 message 6

Hình 1.3: Kiến trúc HL7 – CDA [7] 8

Hình 1.4: Các nơi trên thế giới sử dụng OpenMRS, dữ liệu năm 2011 12

Hình 1.5: Chương trình Mirch connect 14

Hình 1.6: Tiện ích phần mềm MDHT [9] 16

Hình 2.1: Tổng quan kiến trúc hệ thống 20

Hình 2.2: Dịch vụ hệ thống 23

Hình 2.3: Mô hình trao đổi tổng thể HL7 Core 25

Hình 2.4: Mô hình trao đổi HSBA giữa HIS – HL7 Core 26

Hình 2.5: Mô hình trao đổi HSBA giữa HL7 Core – HL7 Gateway 28

Hình 3.1: Biểu đồ Use Case của HL7 Core 34

Hình 3.2: Biểu đồ Use case của HL7 Gateway 35

Hình 3.3: Biểu đồ tuần tự tổng quan 36

Hình 3.4: Biểu đồ tuần tự khi login 37

Hình 3.5: Biểu đồ tuần tự xem danh mục 37

Hình 3.6: Biểu đồ tuần tự thêm, sửa, xóa danh mục 38

Hình 3.7: Biểu đồ tuần tự xem HSBA 38

Hình 3.8: Biểu đồ tuần tự thêm, sửa, xóa HSBA 39

Hình 3.9: Biểu đồ tuần tự thêm, sửa, xóa người dùng 39

Hình 3.10: Biểu đồ tuần tự gửi HSBA 40

Hình 3.11: Biểu đồ tuần tự nhận HSBA 41

Hình 3.12: Biểu đồ lớp chương trình 41

Hình 4.1: Chức năng login 59

Hình 4.2: Màn hình chính 59

Hình 4.3: Demo chức năng chưa xử lý 60

Hình 4.4: Demo chức năng đã xử lý 60

Hình 4.5: Demo chức năng gửi HSBA 61

Hình 4.6: Demo chức năng chờ nhận HSBA 61

Hình 4.7: Demo chức năng đã nhận HSBA 62

Hình 4.8: Demo chức năng xem vết trao đổi HSBA 62

Hình 4.9: Demo chức năng xem chi tiết vết trao đổi HSBA 63

BẢNG CHỮ CÁI VIẾT TẮT

CDA Chuẩn tài liệu cấu trúc - Clinical

Document Architecture XML Ngôn ngữ đánh dấu mở rộng - Extensible

Markup Language

UML Ngôn ngữ mô hình hóa thống nhất -

Unified Modeling Language

OOAD Mô hình phân tích nghiệp vụ hướng đối

tượng - Object Oriented Analysis and Design

ANSI Viện tiêu chuẩn quốc gia Hoa Kỳ -

American National Standards Institute

MỤC LỤC

LỜI CẢM ƠN i

LỜI CAM ĐOAN ii

DANH MỤC HÌNH VẼ iii

BẢNG CHỮ CÁI VIẾT TẮT iii

MỤC LỤC vi

MỞ ĐẦU 1

Đặt vấn đề 1

Tóm tắt chương 2

Chương 1: CƠ SỞ LÝ THUYẾT 3

1.1 Giới thiệu chung 3

1.2 Chuẩn HL7 3

1.2.1 Lịch sử chuẩn HL7 3

1.2.2 Kiến trúc chuẩn HL7 message 5

1.2.3 Kiến trúc chuẩn HL7 CDA 8

1.3 Công nghệ hỗ trợ 11

1.3.1 Phần mềm OpenMRS 12

1.3.2 Phần mềm Mirth connect: 13

1.3.3 Phần mềm Zip4j 15

1.3.4 Phần mềm MDHT (Model driven health Tools) 15

1.3.5 Phần mềm Hapi 17

1.4 Tổng kết chương 17

Chương 2: PHÂN TÍCH HỆ THỐNG 19

2.1 Tổng quan bài toán 19

2.1.1 Yêu cầu chức năng 19

2.1.2 Yêu cầu phi chức năng 19

2.1.3 Tổng quan kiến trúc 20

2.2 Phân tích yêu cầu 21

2.2.1 Tầng người dùng hệ thống 21

2.2.2 Tầng truy cập hệ thống 22

2.2.3 Tầng ứng dụng hệ thống 22

2.3 Yêu cầu hệ thống 23

2.3.1 Dịch vụ thệ thống 23

2.3.2 Yêu cầu chức năng và phi chức năng 24

2.4 Tổng kết chương 2 30

Chương 3: THIẾT KẾ HỆ THỐNG 31

3.1 Biểu đồ Use Case 31

3.1.1 Xác định các tác nhân 31

3.1.2 Xác định các Use Case sử dụng nghiệp vụ 32

3.1.3 Biểu đồ Use Case 33

3.2 Biểu đồ tuần tự (Sequence Diagram) 36

3.2.1 Biểu đồ tuần tự tổng quan 36

3.2.2 Biểu đồ tuần tự các ca sử dụng 37

3.3 Biểu đồ lớp (Class Diagram) 41

3.3.1 Giới thiệu 41

3.3.2 Xác định các lớp 41

3.3.3 Xác định các thuộc tính 44

3.3.4 Mô hình lớp 56

3.4 Tổng kết chương 3 57

Chương 4: CÀI ĐẶT HỆ THỐNG 58

4.1 Giới thiệu 58

4.1 Môi trường cài đặt 58

4.2 Demo chương trình 58

4.2.1 Gửi HSBA 58

4.2.1 Nhận HSBA 61

4.2.3 Kiểm tra vết trao đổi của HSBA 62

4.3 Tổng kết chương 4 63

TỔNG KẾT 63

TÀI LIỆU THAM KHẢO 65

Mạng lưới y tế từ Trung ương đến tận xã ngày càng được củng cố và hoàn thiện với 1.062 bệnh viện công lập, với 165.000 giường bệnh (theo kế hoạch) nhằm đáp ứng nhu cầu cơ bản về khám, chữa bệnh của nhân dân Mỗi năm hàng trăm triệu lượt bệnh nhân điều trị ngoại trú và hàng chục triệu lượt bệnh nhân điều trị nội trú, và số lượng bệnh nhân có xu hướng tăng theo từng năm Các trung tâm y tế chuyên sâu ở Hà Nội, Huế - Đà Nẵng, Tp Hồ Chí Minh được tập trung đầu tư phát triển về cơ sở hạ tầng, trang thiết bị, từng bước xây dựng và bồi dưỡng đội ngũ cán bộ y tế có trình độ chuyên môn tay nghề giỏi có thể triển khai thực hiện được nhiều kỹ thuật cao ngang tầm các nước trong khu vực như ghép tạng, phẫu thuật hở tim, can thiệp tim mạch, tách dính, hỗ trợ sinh sản, chẩn đoán hình ảnh, vv Các bệnh viện tỉnh cũng được đầu tư hiện đại hóa giúp người dân được hưởng dịch vụ chất lượng cao ngay tại địa phương Khuyến khích phát triển mạng lưới bệnh viện tư nhân hiện đại cung cấp nhiều loại hình dịch vụ chất lượng, đối tượng và quyền lợi của người bệnh có thẻ BHYT cũng được mở rộng Công tác khám chữa bệnh cho trẻ em dưới 6 tuổi, người bệnh nghèo, đối tượng chính sách ngày càng được quan tâm, cải thiện, tạo được sự công bằng trong chăm sóc sức khỏe nhân dân

Tuy nhiên, bên cạnh những thành tích đã đạt được, ngành y tế nói chung và mạng lưới khám chữa bệnh nói riêng đang phải đối mặt với nhiều khó khăn thách thức và một

số hạn chế Đầu tư cho y tế có tăng, nhưng chưa xứng đáng với nhu cầu khám chữa bệnh của người dân, năng lực y tế tuyến cơ sở còn hạn chế, cơ sở hạ tầng và trang thiết

bị của nhiều bệnh viện đã xuống cấp Hiện tượng quá tải, người bệnh nằm ghép, ghép

ba tại các tuyến Trung ương như Bạch Mai, Bệnh viện Chợ Rẫy, Bệnh viện Nhi Trung ương, …, là khá phổ biến, và kéo dài nhiều năm gây ảnh hưởng tới chất lượng điều trị

và chăm sóc người bệnh

Hầu hết các cơ sở y tế đã đưa vào sử dụng các phần ứng dụng như: quản lý nhân

sự, vật tư – tài chính, quản lý công văn… Do tính cấp bách của ứng dụng CNTT y tế

nên ngành đã chủ động tổ chức, hỗ trợ để các nhà cung cấp dịch vụ tin học xây dựng các phần mềm chuyên biệt trong một số lĩnh vực như quản lý bệnh viện, quản lý trang thiết bị… Bộ y tế đã cho sử dụng một số chuẩn quốc tế làm cơ sở xây dựng phần mềm ứng dụng…

Tuy nhiên, việc đầu tư cho CNTT y tế còn manh mún, dàn trải, thiếu các dự án độc lập; Thiết kế tổng thể ứng dụng CNTT của các cơ sở y tế còn thiếu và hoặc chất lượng không cao; Nhân lực chuyên môn về CNTT tại các cơ sở y tế và các đơn vị y tế còn thiếu, mất cân đối, tự phát Đây được coi là điểm yếu rất cơ bản, cần sớm khắc phục…

Thực trạng hiện nay sự phát triển và ứng dụng tin học trong y tế nước ta vẫn còn thấp so với mặt bằng chung của thế giới và trong khu vực Việc ứng dụng tin học tại các bệnh viện vẫn mang tính tự phát, manh mún, chưa có hệ thống, tính đồng bộ Số lượng các đơn vị bệnh viện ứng dụng tin học thành công trong công tác quản lý và khám chữa bệnh vẫn còn rất ít Thường tập trung ở các bệnh viện lớn hoặc bệnh viện tư nhân Bên cạnh đó, do sự phát triển thiếu đồng bộ và thiếu sự quan tâm đến các tiêu chuẩn, nên hệ thống phần mềm của các bệnh viện vẫn chưa kết nối, và chia sẻ dữ liệu/thông tin được với nhau

Do vậy, vấn đề đặt ra hang đầu hiện nay với ngành y tế tại Việt Nam là vấn đề chuẩn hóa hệ thống thông tin y tế, đặc biệt trong công tác quản lý và khám chữa bệnh Với hiện trạng phân tích như trên, luận văn thấy từ thực tiễn bản thân, trực tiếp làm tin học trong ngành y tế, Tôi đưa ra đề tài luận văn: “Trao đổi Hồ Sơ Bệnh Án giữa các bệnh viện theo chuẩn quốc tế HL7”

Chương 1: CƠ SỞ LÝ THUYẾT

1.1 Giới thiệu chung

Hệ thống là một hệ thống lớn kết hợp giữa các bệnh viện với nhau, liết kết với nhau theo thông qua HSBA định dạng theo chuẩn HL7 Vì vậy, hệ thống là sự liên kết giữa các chương trình với nhau đặt cài đặt tại mỗi bệnh viện Do đó, để xây dựng nên chương trình này tôi đã áp dụng các vấn đề đề sau:

 Cơ sở lý thuyết: đó là chuẩn quốc tế HL7, chuẩn quốc tế về y tế cho các Hồ

1.2.1 Lịch sử chuẩn HL7

1.2.1.1 Lịch sử chuẩn HL7 message

Với mục đích cung cấp một quy định chuẩn chung cho việc trao đổi, quản lý

và tổng hợp dữ liệu y tế, quản lý các dịch vụ chăm sóc sức khỏe, bằng cách định nghĩa

ra một giao thức giữa các hệ thống thông tin y tế khác nhau, tháng 10 năm 1987,

tổ chức Health Level 7 đã xây dựng nên một chuẩn riêng cho hệ thống thông tin bệnh viện và trở thành phiên bản đầu tiên Tới năm 1994, chuẩn này đã được ANSI chính thức công nhận [http://en.wikipedia.org/wiki/HL7] Cũng từ đó, các phiên bản HL7 v.2 và v.3 lần lượt ra đời, được cập nhật và phát triển rộng khắp

Phiên bản 2.x:

Nguyên mẫu của phiên bản 2 được chuẩn bị từ sau phiên bản 1.0 và được giới thiệu lần đầu tiên năm 1988, gồm các phiên bản 2.0 (năm 1988), 2.1 (năm1990), 2.2 (năm 1994), 2.3 (năm 1997), 2.3.1 (năm 1999), 2.4 (năm 2001) và 2.5 (năm 2003)

Phiên bản HL7 v2.x khá đơn giản và thuần túy là chuẩn trao đổi bản tin: bản tin ADT; văn bản quản trị bệnh nhân; báo cáo y tế; tài chính, dịch vụ chăm sóc bệnh nhân,… HL7 v2.5 có thêm những nâng cấp để hỗ trợ tính pháp lý, các cải tiến cho phép liên kết quốc tế để tận dụng hết thế mạnh của chuẩn giao tiếp

1.2.1.2 Lịch sử chuẩn HL7 CDA

Chuẩn tài liệu lâm sàng - HL7 CDA là chuẩn tài liệu có cấu trúc Thông qua chuẩn tài liệu này, sẽ chỉ rõ cho cơ quan quản lý, các cơ sở y tế, các nhà thiết kế phần mềm, phần cứng về tính cấu trúc "Structure" và tính ngữ nghĩa "Semantic" của một tài liệu lâm sàng Với mục đích hỗ trợ việc trao đổi thông tin giữa các cơ sở y tế, các tổ chức cơ quan liên quan được thuận tiện và chính xác trên môi trường truyền thông rất đa dạng và phong phú hiện nay Phiên bản CDA Release 1 hay còn gọi (ANSI/HL7 CDA R1.0), được thông qua

và công nhận là chuẩn Quốc tế vào tháng 11 năm 2000 Phiên bản CDA Release 2 (CDA R2) được thông qua tháng 05 năm 2005 bởi American National Standards Institute/ Health Level Seven International (ANSI/HL7) Với sự tân tiến về thiết kế của phiên bản CDA R2, cùng với việc cập nhật các kiểu dữ liệu (Data type), loại bỏ, bổ sung một số thuộc tính (Header Attribute và Section Attribute), sự gắn kết chặt chẽ với mô hình HL7 Reference Information Model (RIM) trong quá trình phát sinh và hình thành tài liệu, sự cho phép tham chiếu và sử dụng các bộ mã tương thích với chuẩn của HL7 (như: chuẩn LOINC, chuẩn SMOMED-CT và ICD 10), sự thay đổi các từ vựng trong nhóm CNE (Code No Extended) và việc bổ sung nhóm từ vựng trong CNE từ nhóm CWE (Code With Extended) đã làm cho CDA R2 có những tính năng mạnh hơn rất nhiều so với phiên bản trước và đồng thời tính ngữ nghĩa trong tài liệu lâm sàng đã được thể hiện một cách rõ nét hơn Trong khuôn khổ cuốn sách này chúng tôi sẽ tập trung giới thiệu về chuẩn tài liệu lâm sàng CDA R2 và trong phần trình bày chúng tôi sử dụng thuật ngữ CDA để chỉ tài liệu CDA R2 thay cho việc ghi đầy đủ tên tài liệu Bên cạnh đó các kiến thức được đề cập có

sẽ liên quan tới: tài liệu XML, thiết kế Style Sheet, chuẩn LOINC, chuẩn mã định danh OIDs, chuẩn SNOMED CT, chuẩn ICD 10, chuẩn giao thức truyền tin LLP (Lower Layer Protocol) và các kỹ thuật lập trình JAVA hỗ trợ xử lý tài liệu XML nói chung và kỹ thuật

xử lý cho tài liệu CDA nói riêng

1.2.2 Kiến trúc chuẩn HL7 message

Từ giới thiệu về chuẩn HL7 trên, thì tổ chức HL7 đã định nghĩa ra 92 loại bản tin

và khoảng hơn 300 loại sự kiện, mỗi bản tin gồm các đoạn bản tin hoặc nhóm đoạn bản tin tạo thành, đoạn bản tin lại được cấu thành từ các trường Có thể tóm lược như trên hình dưới:

BẢN TIN(Ví dụ: ADT,CRM,OML…)

CÁC NHÓM ĐOẠN TIN

ĐOẠN TIN(Ví dụ: MSH, PID EVN…)

LOẠI DỮ LIỆU ( Ví dụ:ST,EI, CQ…)

CÁC THÀNH PHẦN CON

Hình 1.2: Kiến trúc HL7 message 1.2.2.1 Đặc tả chi tiết

Từ hình vẽ trên, ta đặc tả như sau:

Bản tin: Mỗi bản tin bao gồm một nhóm các đoạn bản tin được xắp xếp

theo thứ tự đã định nghĩa bởi tổ chức HL7 Ví dụ, ADT – là bản tin về thông tin

bệnh nhân; PRE – là bản tin liên quan đến thuốc và mã hóa thuốc; BRA – là bản tin liên quan đến tài chính

Đoạn bản tin: Mỗi segment trong bản tin là một nhóm logic các trường

dữ liệu Trong bản tin HL7 có những đoạn bắt buộc và có những đoạn tùy chọn Mỗi segment sẽ được đặt tên và xác định bằng ID của segment đó Ví

dụ, bản tin ADT chứa các đoạn: MSH – đoạn header (xác định địa chỉ nguồn, địa chỉ đích và những thông tin liên quan tới bản tin); EVN – đoạn loại sự kiện (xác định loại sự kiện là nhập viện, chuyển viện hay xuất viện, thanh toán tài chính,…); PID – đoạn mã bệnh nhân

Các trường: Mỗi trường là một chuỗi các ký tự và nó được xác định bằng

đoạn mà nó nằm trong đó và vị trí của nó trong đoạn Ví dụ, PID-5 là trường thứ 5 trong đoạn mã bệnh nhân; mỗi trường lại chứa các thành phần con

Loại dữ liệu: Loại dữ liệu giới hạn nội dung và định dạng của trường

dữ liệu, một số loại dữ liệu là mã hoặc là kết hợp của các loại dữ liệu khác

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

Khuôn dạng bản tin quy định theo nguyên tắc mã hóa của HL7 gồm các trường dữ liệu, các trường này có độ dài thay đổi và được ngăn cách bởi một ký tự ngăn cách trường Các nguyên tắc mô tả cách mã hóa của các kiểu dữ liệu trong một trường được quy định riêng 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 các ký tự phân đoạn Mỗi đoạn bắt đầu với một giá trị chữ 3 ký tự, giá trị này được nhận dạng trong một bản tin Các đoạn có thể là bắt buộc phải có, hoặc tùy chọn, hoặc lặp lại tùy thuộc vào cấu trúc bản tin

Bộ ký tự hiển thị mã ASCII (gồm các giá trị hexa trong khoảng 20 đến 7E) là bộ

ký tự mặc định để biểu diễn các bản tin HL7

Sự kiện A01 được dùng trong trường hợp bệnh nhân nhập viện Sự kiện này được nhập từ hệ thống nhập viện và được gửi tới các khoa/phòngliên quan như: khoa dược, phòng y tá, phòng tài chính, khoa xét nghiệm, khoa chẩn đoán… Với bản tin này, cấu trúc của nó cơ bản như sau (chú ý là không bắt buộc tất cả các thành phần của trường đều phải có

Ví dụ: bản tin mã hóa theo chuẩn HL7 v2.5 (sự kiện ADT^A01 – bệnh nhân nhập viện) như sau:

Bản tin được dịch là: Bệnh nhân John B Doe, II, 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 lúc 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 Ứng dụng gửi là Store, bản tin được gửi từ Mission tới ứng dụng nhận

là Mine sau khi bệnh nhân nhập viện 2 phút

1.2.3 Kiến trúc chuẩn HL7 CDA

1.2.3.1 Tổng quan về kiến trúc HL7 CDA

Trong hệ thống HL7, sử dụng CDA (Clinical Document Architecture) là cấu trúc để trao đổi HSBA Sau đây là cấu trúc chung của CDA:

Hình 1.3: Kiến trúc HL7 – CDA [7]

CDA được tổ chức dưới dạng file XML Được trích xuất từ mô hình HL7's central Reference Information Model (RIM), do vậy có khả năng sử dụng lại dữ liệu đối với các labo, nhà thuốc … Đặc tả CDA rất trực quan và có khả năng linh hoạt cao giúp dễ dàng hiện thực hóa đối với các hệ thống phần mềm

Về cơ bản, các thành phần chính của một tài liệu CDA bao gồm:phần Header và Body Trong đó phần Body chứa các Sections thông tin riêng biệt Một section chứa một khối diễn giải và từ 0 đến nhiều các Entry (Entry: chứa nội dung hồ sơ y tế)

1.2.3.2 Cấu trúc Header

Phần header của tài liệu được dùng để lưu trữ các thông tin phục vụ việc trao đổi tài liệu lâm sàng giữa các cơ quan tổ chức, ngoài ra thông tin trong phần này còn được dùng phục vụ trong công tác quản lý hồ sơ tài liệu CDA và được dùng để làm căn cứ cập nhật thông tin cho hồ sơ bệnh án điện tử suốt đời cho một bệnh nhân Một tài liệu CDA được đặt trong tag gốc <ClinicalDocument> và </ClinicalDocument>, khi đó phần Header được định làm phần nằm giữa từ tag <ClinicalDocument> và tag <structuredBody>, phần thể hiện cấu trúc body của tài liệu được xác định làm phần còn lại của tài liệu (từ tag

<structuredBody> đến </ClinicalDocument>)

Các thuộc tính trong Header:

S

TT

1 ClinicalDocument.id Lưu mã (ID) tài liệu

2 ClinicalDocument.code Lưu mã loại tài liệu cần trao đổi – mã

này được xác định qua chuẩn LOINC

3 ClinicalDocument.title Tiêu đề của tài liệu

4 ClinicalDocument.effectiveTime Thời gian tạo tài liệu

5 ClinicalDocument.ConfidentialityCode Xác định tính bảo mật tài liệu, tính chất

này được thể hiện qua 3 mức:

- N (normal) (codeSystem 2.16.840.1.113883.5.25);

- R (restricted) (codeSystem 2.16.840.1.113883.5.25);

- V (very restricted) (codeSystem 2.16.840.1.113883.5.25)

6 ClinicalDocument.languageCode Mã ngôn ngữ được thể hiện trên Web

browser, mã này được quy định qua chuẩn: IETF (Internet Engineering Task Force) RFC 3066

7 ClinicalDocument.setId Lưu mã tài liệu trong quá trình trao đổi,

nếu cùng một tài liệu nếu nội dung có thay đổi như: cập nhật, sử đổi thì mã này sẽ được sinh mới

8 ClinicalDocument.versionNumber Lưu phiên bản của tài liệu – là số

1.2.3.3 Cấu trúc Body

Với CDA body, ta có thể tùy chọn 1 trong 2 cách để triển khai biểu diễn thông tin: thông tin không cấu trúc (NonXMLBody) và thông tin có cấu trúc (StructuredBody) Mỗi tài liệu CDA sẽ có duy nhất một Body, liên kết với ClinicalDocument class thông qua liên kết component, chức năng của 2 class được diễn giải như sau:

S

TT

1 NonXMLBody Mô tả các dạng thông tin trong body,

được trình bày bởi các định dạng ngoài định dạng XML

2 StructuredBody Mô tả thông tin trong phần body, bao gồm

những thông tin được trình bày bởi 1 hay nhiều section, có cấu trúc Các thông tin này được mô tả thông qua ngôn ngữ XML

Các thuộc tính thành phần section:

S

TT

1 Section.id Thông tin dùng để phân biệt giữa các

phần trong tài liệu

2 Section.code Mã dùng để phân biệt giữa các nội dung

trong từng section trong tài liệu

Dùng mà LOINC

3 Section.title Lưu phần thông chung cho section

4 Section.text Lưu trữ thông tin sẽ được chuyển tải tới

người nhận dưới dạng văn bản text

Trường này có thể dùng để lưu thông tin khi hỏi và thăm khám người bệnh

hàng ngày hoặc kết quả hội chẩn

 Phần mềm OpenMRS: nền tảng xây dựng chương trình trao đổi HSBA điện tử theo chuẩn HL7

 Phần mềm Mirth connect: Dùng để vận chuyển HSBA giữa các bệnh viện với nhau

 Phần mềm Zip4j: Dùng để nén HSBA và các file đính kèm như file ảnh xét nghiệm.thành một file nén

 Phần mềm MDHT: Chứa thư viện hỗ trợ HSBA tạo ra định dạng HL7 – CDA

 Phần mền Hapy: Chứa thư viện hỗ trợ HSBA tạo ra định dạng HL7 – Message

1.3.1 Phần mềm OpenMRS

Hình 1.4: Các nơi trên thế giới sử dụng OpenMRS, dữ liệu năm 2011

OpenMRS là một hệ thống hồ sơ y tế điện tử, được thiết kế sử dụng trên thế giới và được thiết lập lần đầu năm 2004 Ngày ngay, hệ thống được phát triển thành một nền tảng tin học y tế sử dụng mọi lục địa hỗ trợ chăm sóc sức khỏe và nghiên cứu trong rất nhiều hoàn cảnh khác nhau

Ban đầu, OpenMRS có nền tảng là các nguyên tắc mở và chia sẻ ý tưởng, phần mềm, chiến lược cho việc triển khai và sử dụng Hệ thống được thiết kế và sử dụng trong các môi trường thiếu tài nguyên và có thể được điều chỉnh bằng việc thêm các mục dữ liệu mới, biểu mẫu, báo cáo mà không cần viết mã ứng dụng phức tạp Nó phát triển như một nền tảng cho các tổ chức sử dụng và điều chỉnh, tránh việc phải xây dựng hệ thống từ đầu

OpenMRS ngày nay đang được dùng tại nhiều nước trên thế giới như Argentina, Ấn

Độ, Indonesia, Hoa Kỳ, Zanzibar…

Nhận xét về OpenMRS:

Với hệ thống này, tôi sử dụng phần mềm OpenMRS với lý do sau:

 OpenMRS là chương trình mã nguồn mở, được sử dụng rất nhiều nơi trên thế giới đã giúp cho hệ thống trong vấn đề chi phí xây dựng hệ thống, dễ tích hợp với các hệ thống trên thế giới đã sử dụng OpenMRS

 OpenMRS là một chương trình y tế vê Web đã tích hợp rất nhiều nghiệp vụ về

y tế, chuẩn HL7, các vấn đề công nghệ khác

1.3.2 Phần mềm Mirth connect

Mirth Connect là bộ công cụ tích hợp trong các hệ thống thông tin y tế, được đặc biệt thiết kế cho việc tích hợp tin nhắn HL7 Nó cung cấp các bộ công cụ cần thiết cho việc thiết lập, kiểm tra, triển khai và giám sát các giao diện Và vì là nguồn mở, người

sử dụng có thể có tất cả các những lợi thế về việc hỗ trợ từ cộng đồng người dùng rộng lớn với chất lượng như một sản phẩm thương mại

1.3.2.1 Tiện ích phần mềm Mirth Connect

Phần mềm Mirth Connect có khả năng sau:

Mirth connect hỗ trợ nhiều giao thức chuyển gói tin sử dụng trong lĩnh vực y tế như: TCP/IP, HTTP, dịch vụ web (SOAP), cơ sở dữ liệu, hệ thống tập tin, email, FTP, DICOM, PDF, RTF

Mirth connect hỗ trợ nhiều định dạng dữ liệu và các tiêu chuẩn quốc tế HL7 như HL7 version 2.x, HL7 version 3, CDA, CCD, XML, CCR, NCPDP, DICOM

Mẫu của Mirth Connect hướng theo phương pháp tiếp cận tạo giao diện, nó cho phép xác định loại thông điệp người sử dụng sẽ nhận hay gửi và sau đó tạo các ánh xạ

và chuyển đổi dùng phương pháp kéo thả qua ứng dụng

Hình 1.5: Chương trình Mirch connect

Mirth Connect bao gồm các cơ sở dữ liệu đã nhúng và cho phép người sử dụng tải lên và chạy nhanh hơn Khi đã sẵn sàng sản xuất, người sử dụng có thể lưu các cấu hình và dữ liệu thông điệp trong PostgreSQL, Microsoft SQL Server, Oracle hay MySQL

 Mirth connect là phần mềm đơn giản cho người phát triển, giúp người phát triển không mất nhiều thời gian tìm hiểu nghiên cứu, dễ cài đặt

1.3.3 Phần mềm Zip4j

Zip4j là một thư viện phần mềm mã nguồn mở cung cấp các tính năng quản lý và nén các tệp tin cho nền tảng công nghệ Java

1.3.3.1 Tiện ích phần mềm

Zip4j có các tính năng sau:

- Tạo, thêm, Trích xuất, cập nhật, loại bỏ các tập tin từ một tập tin Zip

- Đọc, tạo các tệp tin nén được bảo vệ bằng mật khẩu

- Hỗ trợ chuẩn mã hoá AES 128/256

- Hỗ trợ chuẩn mã hoá Zip

- Hỗ trợ định dạng Zip64

- Hỗ trợ Store (không nén) và phương pháp nén Deflate

- Tạo hoặc trích xuất các tập tin từ các tập tin ZipSplit (Ví dụ: Z01,zip)

- Hộ trợ các tên tệp Unicode

1.3.3.2 Nhận xét về phần mềm

Zip4j là bộ gói thư viện mã nguồn mở trong nền tảng java, giúp ta nén lại dữ liệu file của HSBA trước khi được chuyển đi Cụ thể trong hệ thống này, zip4j giúp hệ thống nến gói file trong việc trao đổi HSBA như HSBA, file ảnh xét nghiệm, file DICOM

1.3.4 Phần mềm MDHT (Model driven health Tools)

Công cụ Y tế Mở MDHT là kết quả của việc sử dụng rộng rãi phần mềm nguồn

mở để thúc đẩy khả năng tương tác trong hạ tầng y tế Dự án khuyến khích chia sẻ các tài liệu thuyết minh giữa các tổ chức phát triển tiêu chuẩn và các tiêu chuẩn y tế liên quan, xây dựng các thông số kỹ thuật nội bộ MDHT cũng cung cấp một khung mô hình phổ biến và các công cụ hỗ trợ việc tích hợp liên tục các thiết kế, xuất bản và tạo thời gian chạy tài liệu thuyết minh

Hình 1.6: Tiện ích phần mềm MDHT [9]

1.3.4.1 Tiện ích phần mềm

MDHT cho phép tạo các mô hình tính toán của mẫu CDA trong UML Các mô hình này có thể được dùng để cung cấp:

- Các thông số kỹ thuật mẫu (DITA, XHTML, PDF, khác)

- Các công cụ đủ tiêu chuẩn/xác thực

- Schematron (làm việc theo tiến trình)

Đề tài đã xây dựng các mô hình từ các thông số kỹ thuật sau:

- Tài liệu chăm sóc sức khỏe liên tục HL7 (HL 7 Continuity of Care Document)

- Các hạng mục và đầu vào HITSP C83

- Khung kỹ thuật phối hợp chăm sóc sức khỏe bệnh nhân IHE

- Các loại tài liệu phổ thông HL7

- CDA hợp nhất HL7 (DSTU 12/2011)

- HL7 CDA IG: Báo cáo các trường hợp y tế công cộng (khu vực Hoa Kỳ)

- HL7 CDA IG: Báo cáo giám sát y tế cá nhân (PHMR)

- Bộ phân tích = chuyển nội dung tin nhắn thành đối tượng tin nhắn

- Mã hóa = chuyển đối tượng tin nhắn thành nội dung tin nhắn

Cả hai hành động trên được thực hiện bằng bộ phân tích ca.uhn.hl7v2.parser

1.3.5.2 Nhận xét phần mềm

Hapi là thư viện mã nguồn mở hỗ trợ chuẩn HL7 version 2.x, giúp ta xây dựng trong viện chuyển đổi HSBA sang dữ liệu chuẩn HL7 version 2.x Cụ thể trong hệ thống này, tôi đã chuyển đổi sang dạng dữ liệu HL7 version 2.5

1.4 Tổng kết chương

Như vậy, chương này tôi đã khái quát các vấn đề cơ sở lý thuyết bao gồm các cơ

sở lý thuyết chuẩn HL7, các công nghệ hỗ trợ xây dựng lên chương trình

 Cơ sở lý thuyế chuẩn HL7:

o Chuẩn HL7 Message: Chuẩn về việc định dạng HSBA dưới dạng các bản tin text

o Chuẩn HL7 – CDA: Chuẩn về việc định dạng HSBA dưới dạng tài liệu cấu trúc theo XML

 Công nghệ hỗ trợ:

o Phần mềm OpenMRS: Phần mềm mã nguồn mở, giúp ta xây dựng chương trình trong hệ thống

o Phần mềm Mirth Connect: Phần mềm giúp ta vận chuyển HSBA giữa các bệnh viện với nhau

o Phần mềm Zip4j: Giúp ta nén file gồm HSBA, các file liên quan đến HSBA thành một file nén

o Phần mềm MDHT: Cung cấp gói thư viện hỗ trợ ta trong việc chuyển dữ liệu HSBA dưới định dạng chuẩn HL7 CDA

o Phần mềm Hapy: Cung cấp gói thư viện hỗ trợ ta trong việc chuyển dữ liệu HSBA dưới định dạng chuẩn HL7 Message

Chương tiếp theo, tôi đi sâu vào các vấn đề làm sao để xây dựng chương trình của hệ thống trao đổi HSBA theo chuẩn quốc tế HL7

Chương 2: PHÂN TÍCH HỆ THỐNG

2.1 Tổng quan bài toán

Hệ thống là một nền tảng Middleware vì thế cần được xây dựng như một nền tảng

đa năng và linh hoạt để đảm bảo đáp ứng sự thay đổi của các thành phần xung quanh như HIS, hồ sơ bệnh án cá nhân, … Chính vì thế tôi chọn xây dựng hệ thống HL7 CORE theo phương pháp phát triển nhanh các nền tảng Middleware có khả năng tùy biến kết hợp với Kiến trúc tổng thể trong đó hệ thống Middleware được xây dựng vừa có khả năng tùy biến vừa phải có khả năng truy soát các giao dịch

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

Hệ thống xây dựng phải đáp ứng các dịch vụ cốt lõi sau:

- Dịch vụ định danh xác thực

- Dịch vụ quản lý cấu hình

- Dịch vụ dữ liệu

- Dịch vụ giao tiêp truyền tin

- Dịch vụ HL7 CORE INTERFACE ENGINE

Ngoài ra hệ thống HL7 CORE còn yêu cầu các ứng dụng hướng đến người dùng Thay vì phát triển các ứng dụng này một cách riêng rẽ đơn lẻ, chúng tôi chọn một bộ các ứng dụng nền tảng có đầy đủ các chức năng tổng quát làm nền tảng để phát triển các ứng dụng cụ thể, các ứng dụng lõi này bao gồm:

- Quản lý nội dung

- Quản lý bản ghi

- Quản lý bản tin

- Làm việc cộng tác

2.1.2 Yêu cầu phi chức năng

Hệ thống thực hiện dựa trên các nguyên lý sau:

- Yêu cầu của HL7 CORE phải được phân tích trong một bối cảnh của kiến trúc tổng thể toàn hệ thống để tạo ra kiến trúc nghiệp vụ phù hợp;

- Kiến trúc thông tin – kiến trúc quan trọng nhất của HL7 CORE cần được xây dựng trên nền tảng Metadata và XML;

- Kiến trúc ứng dụng của HL7 CORE phải dựa trên kiến trúc hướng dịch vụ (SOA);

- Kiến trúc công nghệ của HL7 CORE phải dựa trên hạ tầng chia sẻ, với các công nghệ điện toán đám mây và các công nghệ bảo mật, an toàn thông tin tiên tiến;

- Kiến trúc nghiệp vụ và kiến trúc thông tin của HL7 CORE được xây dựng dựa trên mô hình phân tích nghiệp vụ hướng đối tượng (OOAD) và được thể hiện bằng ngôn ngữ UML

Ngoài ra hệ thống phải đáp ứng các vấn đề sau:

- Hệ thống phải đáp ứng dược trao đổi dữ liệu chứa các file như text, ảnh xét nghiệm, DCOM tối đa 50GB

- Thời gian time out hệ thống như mất mạng, kết nối database sau 30 giây

- Trong một thời gian đáp ứng được khoảng 50 người thực hiện cùng 1 lúc

2.1.3 Tổng quan kiến trúc

Dựa vào việc phân tích trên thì tôi đưa ra kiến trúc tổng quan hệ thống:

Hình 2.1: Tổng quan kiến trúc hệ thống

Kiến trúc tổng thể được chia thành các tầng, mỗi tầng gộp nhóm đối tượng sử dụng hoặc các thành phần chức năng với cùng một tiêu chí phân loại

2.2 Phân tích yêu cầu

Từ hình vẽ về kiến trúc tổng hệ thống trên, ta có thể đặc tả hệ thống như sau:

Với đặc điểm trên, các đối tượng người dùng khác nhau sẽ sử dụng như sau:

- Cán bộ y tế: Các cán bộ Y tế tại từng bệnh viện triển khai kết nối với hệ thống

HL7 CORE sẽ thực hiện việc quyết định chuyển HSBA điện tử tới các bệnh viện khác khi bệnh nhân chuyển viện Về kỹ thuật, cán bộ y tế sẽ sử dụng các công cụ được cung cấp bởi HL7 CORE Bệnh viện để chuyển dữ liệu HSBA tới HL7 CORE Bệnh viện của bệnh viện đích thông qua HL7 CORE GATEWAY Cán bộ y tế cũng sử dụng các chức năng của hệ thống HL7 CORE Bệnh viện để đề xuất, đăng ký các dữ liệu danh mục của bệnh viện mình vào dữ liệu danh mục dùng chung và tiến hành ánh xạ các giá trị dữ liệu của danh mục dùng riêng với danh mục dùng chung Hệ thống HL7 CORE Bệnh viện cũng cung cấp chức năng để cán bộ y tế cập nhật các báo cáo thống kê Y tế gửi cho Bộ Y tế tại HL7 CORE GATEWAY.Việc thực hiện các chức năng trên phải theo quy trình được xây dựng chặt chẽ và theo phân quyền truy cập của từng cán bộ y

tế

- Cán bộ quản lý: Các cán bộ quản lý khai thác dữ liệu tại Cổng thông tin của

HL7 CORE GATEWAY bao gồm thống kê danh mục các HSBA đã được thực hiện truyền dữ liệu giữa các bệnh viện và tình trạng thực hiện Các cán bộ quản lý cũng khai thác các thông tin báo cáo tổng hợp từ Cổng này

- Quản trị hệ thống: Quản trị hệ thống sử dụng các công cụ quản trị, theo dõi

tình trạng hệ thống để đảm bảo HL7 CORE hoạt động ổn định và chính xác Quản trị hệ thống cũng có trách nhiệm cấp quyền truy cập và cấu hình hệ thống bằng các công cụ được cung cấp bởi tầng quản lý cấu hình theo mức độ sử dụng của hệ thống để đảm bảo bảo mật, an toàn dữ liệu và hiệu năng đáp ứng

- Bệnh nhân: Các bệnh nhân có quyền khai thác dữ liệu HSBA của chính mình

khi có yêu cầu và được các cán bộ y tế cung cấp theo quy định

Đối với các hệ thống thông tin truy cập, khai thác trực tiếp vào các thành phần được cung cấp bởi nền tảng tích hợp hệ thống thông tin y tế Người sử dụng cuối sử dụng hệ thống thông qua kênh truy cập (trình duyệt web) và sử dụng các ứng dụng ở tầng Ứng dụng của hệ thống HL7 CORE

2.3 Yêu cầu hệ thống

2.3.1 Dịch vụ thệ thống

Dựa vào việc phân tích kiến trúc yêu cầu chức năng hệ thống đáp ứng Thì ta đưa ra

mô hình kiến trúc tổng quan phần mềm hệ thống như sau:

Hình 2.2: Dịch vụ hệ thống

Từ hình vẽ trên, ta thấy:

 Hệ thống HL7 CORE Bệnh Viện: được phòng kế hoạch tổng hợp (KHTH) và Bác

sĩ khai thác, tham gia và sử dụng hệ thống

 Hệ thống HL7 CORE GATEWATE: được cán bộ của Bộ y tế khai thác

Từ đó ta cũng đưa ra hệ thống trao đổi HSBA theo chuẩn HL7 có các chức năng chính như sau:

2.3.1.1 Hệ thống HL7 CORE Bệnh Viện

 Quản lý danh mục: Thêm, xóa, sửa, tra cứu, đề xuất danh mục

 Quản lý HSBA: Thêm, xóa, sửa, tra cứu, gửi và nhận HSBA

 Quản lý vết trao đổi HSBA: Quản lý vết của HSBA đã được gửi và nhận trong hệ thống

 Báo cáo tổng hợp: Dùng để báo cáo số lượng HSBA của mỗi bệnh viện gửi đến bệnh viện mình

2.3.1.2 Hệ thống HL7 CORE GATEWAY:

 Quản lý danh mục: thêm, xóa, sửa, tra cứu, đồng bộ danh mục

 Quản lý vết trao đổi HSBA giữa các bệnh viện: Quản lý vết của HSBA đã qua Gateway

 Báo cáo tổng hợp: Dùng để tổng hợp HSBA của mỗi bệnh viện đã gửi và nhận qua Gateway

2.3.2 Yêu cầu chức năng và phi chức năng

Dựa vào phần tích trên, ta cũng đưa ra mô hình trao đổi HSBA tổng quan giữa các bệnh viện như sau:

Hình 2.3: Mô hình trao đổi tổng thể HL7 Core

Mô hình được mô tả ở trên thể hiện mối quan hệ về trao đổi thông tin giữa các thành phần trong hệ thống HL7 CORE với trường hợp hai Bệnh viện A và B gửi thông tin về HSBA và các thông tin khác với nhau Các thông tin trao đổi được chia thành 2 loại là thông tin trao đổi 2 chiều và thông tin trao đổi 1 chiều

Thông tin trao đổi 2 chiều bao gồm các trường hợp trao đổi thông tin về HSBA, trong đó các Bệnh viện tham gia hệ thống có thể gửi và nhận HSBA từ các bệnh viện khác thông qua hệ thống HL7 CORE Thông tin danh mục trao đổi giữa hệ thống thông tin bệnh viện (HIS) và hệ thống HL7 CORE Bệnh viện cũng là dạng thông tin trao đổi 2 chiều đảm bảo danh mục dùng chung được quản lý tập trung và được coi là danh mục chuẩn từ hệ thống HL7 CORE GATEWAY sẽ luôn luôn được cập nhật, đồng bộ thông qua bảng ánh xạ (mapping table) với hệ thống danh mục dùng riêng theo đặc thù của từng bệnh viện

2.3.2.1 Trao đổi thông tin nội bộ

Thông tin HSBA được quản lý tại các hệ thống thông tin bệnh viện (HIS) và được chuyển tới hệ thống HL7 CORE Bệnh viện Ở đây thông tin được chuẩn hóa, chuyển đổi sang dạng HL7 và mã hóa Các dữ liệu được lưu trước hết trong CSDL trung gian và chuyển sang CSDL chính thức để truyền dữ liệu tới bệnh viện đích thông qua HL7 CORE GATEWAY

Mô hình trao đổi thông tin HSBA trong nội bộ hệ thống thông tin bệnh viện được

mô tả như hình sau:

Hình 2.4: Mô hình trao đổi HSBA giữa HIS – HL7 Core

Các hệ thống HIS trong phạm vi thực hiện của hệ thống đã được nâng cấp đảm bảo khả năng truyền, nhận dữ liệu với hệ thống HL7 CORE trong hệ thống Trong đó, quan trọng nhất là các hệ thống HIS đã kết xuất dữ liệu trực tiếp từ CSDL tác nghiệp sang các bảng dữ liệu trung gian, đảm bảo danh mục thông tin đầy đủ như mô tả ở Hình 16 Việc nâng cấp các hệ thống HIS là yêu cầu bắt buộc khi kết nối với hệ thống HL7 CORE Sau khi hệ thống đã triển khai thành công ở các bệnh viện trong phạm vi triển khai, cần ban hành tiêu chuẩn về hệ thống HIS để có khả năng trao đổi HSBA với hệ thống HL7 CORE

Thuyết minh chi tiết các bước trao đổi thông tin như sau:

Bước (1) và (2): Hệ thống HIS bệnh viện luôn cập nhật và đồng bộ dữ liệu từ

CSDL tác nghiệp vào các bảng dữ liệu trung gian nhằm trao đổi với hệ thống HL7 CORE Các bảng dữ liệu trung gian này có thể lưu trữ trong cùng CSDL logic của

hệ thống HIS Các dữ liệu này được chuyển tới CSDL Trung gian của hệ thống HL7 CORE bệnh viện Cấu trúc của dữ liệu được quy định bao gồm các thành phần như hình

16 Để trao đổi thông tin có hai phương án: cung cấp kết nối trực tiếp tới CSDL hoặc thông qua web services

Bước (3): Sau khi các dữ liệu HSBA được lưu trong CSDL trung gian của HL7

CORE bệnh viện, hệ thống sẽ sử dụng các hàm thư viện được cung cấp trong HL7 CORE INTERFACE ENGINE để chuyển đổi dữ liệu HSBA sang HL7 message để

chuyển cho CSDL chính thức của HL7 CORE bệnh viện Các dữ liệu được lưu và quản

lý trong hàng đợi (queue) và hệ thống ghi lại tất cả các sự kiện và các giao dịch cho tất

cả các thao tác được mô tả như trên Các dữ liệu được truyền dưới dạng các bản tin

đã được mã hóa

Bước (4): Danh mục chuẩn trong CSDL HL7 CORE bệnh viện luôn luôn được

cập nhật bản mới nhất từ phía HL7 CORE GATEWAY Danh mục này có thể được sử dụng để chuẩn hóa các dữ liệu có trong CSDL trung gian của HL7 CORE bệnh viện bằng cách tạo một bản sao danh mục chuẩn trong CSDL trung gian, giải pháp trao đổi là kết nối trực tiếp 2 CSDL logic là CSDL trung gian và CSDL HL7 CORE bệnh viện

Bước (5) và (6): Danh mục chuẩn mới nhất có trong CSDL trung gian của HL7

CORE bệnh viện có thể được truyền tới hệ thống HIS để tại hệ thống HIS có thể cập nhật các danh mục theo quy định mới nhất Đồng thời, trong CSDL trung gian của HL7 CORE Bệnh viện cũng lưu bản sao của danh mục dùng riêng của từng bệnh viện.Hệ thống cung cấp công cụ bảng ánh xạ giữa hai hệ thống danh mục dùng riêng và danh mục chuẩn để có thể chuẩn hóa các HL7 message theo đúng danh mục chuẩn phục vụ trao đổi thông tin giữa các hệ thống HIS Giải pháp trao đổi là sử dụng web services

Trên đây là mô tả các luồng thông tin phục vụ việc trao đổi HSBA trong nội

bộ hệ thống HIS và HL7 CORE bệnh viện

2.3.2.2 Trao đổi HL7 Core bệnh viện và HL7 Core Gateway

Các hệ thống HL7 CORE bệnh viện sẽ trao đổi thông tin HSBA từ bệnh viện gửi tới bệnh viện đích theo mô hình được mô tả ở hình dưới đây:

Hình 2.5: Mô hình trao đổi HSBA giữa HL7 Core – HL7 Gateway

Các thông tin trao đổi giữa hệ thống HL7 CORE Bệnh viện và HL7 CORE GATEWAY bao gồm 4 loại: hồ sơ bệnh án, thông tin báo cáo, thông tin trao đổi (dạng text, files,

âm thanh, video) và trao đổi danh mục dùng chung

Các bước trao đổi thông tin và cấu trúc sử dụng để trao đổi thông tin như sau:

Đối với trao đổi thông tin hồ sơ bệnh án:

Bước 1: Sau khi nhận được từ hệ thống HIS của bệnh viện gửi, dữ liệu được lưu

trong CSDL trung gian sau khi được chuyển đổi sang HL7 CDA, mã hóa và đóng gói bằng thư viện được cung cấp bởi HL7 CORE INTERFACE ENGINE được chuyển sang CSDL chính thức của HL7 CORE bệnh viện

Bước 2: Dữ liệu HSBA được bổ sung các thông tin về nơi nhận, thời gian tồn tại và

các thông tin phục vụ quá trình truyền dữ liệu được lưu vào hàng đợi theo nguyên tắc FIFO (First In, First Out) và mã hóa trước khi truyền tới HL7 CORE GATEWAY

Bước 3: Dữ liệu HSBA trong hàng đợi được chuyển đến HL7 CORE GATEWAY và

lưu vết trong hệ thống HL7 CORE bệnh viện Dữ liệu sau khi được HL7 CORE GATEWAY nhận được sẽ kiểm tra về tính toàn vẹn, mức độ chính xác và đầy đủ thông tin theo HL7 CDA Nếu đạt yêu cầu bản tin HSBA sẽ được lưu vào hàng đợi, nếu không đạt yêu cầu sẽ gửi thông báo lỗi tới HL7 CORE Bệnh viện nơi gửi để tiến hành truyền lại

Bước 4: Theo địa chỉ nơi đến của dữ liệu và lấy thông số trong cấu hình hệ thống

(bao gồm các chế độ tự động chuyển đi, chế độ chuyển theo yêu cầu của quản trị hoặc chuyển theo lịch), hệ thống HL7 CORE GATEWAY sẽ chuyển dữ liệu tới hệ thống HL7 CORE Bệnh viện tại bệnh viện đích, hệ thống lưu lại vết của việc truyền dữ liệu cho từng bản tin

Bước 5: Hệ thống HL7 CORE bệnh viện tại bệnh viện đích kiểm tra tính toàn vẹn,

mức độ chính xác và đầy đủ thông tin theo HL7 CDA Nếu đạt yêu cầu sẽ được lưu vào CSDL chính thức của HL7 CORE bệnh viện, nếu không đạt yêu cầu sẽ gửi thông báo lỗi tới HL7 CORE GATEWAY để tiến hành truyền lại, hệ thống lưu lại vết của việc truyền

dữ liệu cho từng bản tin

Bước 6: Nếu dữ liệu HSBA đã được lưu thành công tại CSDL chính thức của hệ

thống HL7 CORE bệnh viện đích, hệ thống sẽ chuyển dữ liệu vào CSDL trung gian của HL7 CORE bệnh viện đích, hệ thống lưu lại vết của việc truyền dữ liệu cho từng bản tin

Bước 7: HL7 CORE Bệnh viện đích sử dụng các thư viện được cung cấp bởi HL7

CORE INTERFACE ENGINE để giải mã, chuyển đổi các dữ liệu HSBA vào đúng khuôn dạng của hệ thống HL7 CORE và chuyển đổi dữ liệu danh mục (nếu cần) theo danh mục dùng riêng của từng bệnh viện

Bước 8: Hệ thống HIS tiếp nhận thông tin HSBA từ CSDL trung gian của HL7

CORE Bệnh viện và ghi vào CSDL của hệ thống HIS

Toàn bộ các bước trên đều được lưu vết trong hệ thống Hệ thống được cấu hình thông số thời gian sống của dữ liệu (time to live) của bản tin HL7 trên HL7 CORE GATEWAY Trong trường hợp truyền dữ liệu từ HL7 CORE GATEWAY tới HL7 CORE bệnh viện đích không thành công và quá thời gian được quy định bằng thông số thời gian sống của dữ liệu (do các lý do đường truyền, lỗi phần mềm hoặc các lý do khác), hệ thống sẽ tự động hủy bỏ nội dung HSBA trong CSDL HL7 CORE GATEWAY và thông báo lỗi tới hệ thống HL7 CORE bệnh viện gửi

Toàn bộ việc gửi, nhận các HSBA điện tử được thực hiện trên môi trường mạng Internet, sử dụng các giao thức bảo mật như OpenSSL, dữ liệu được nén, mã hóa và truyền trên mạng dưới dạng các gói tin