Luận văn Hệ thống thông tin y tế và tình hình ứng dụng tại Việt Nam

Bảng 2.2 Các lớp đối tượng DICOM Lớp tiêu chuẩn hoá Bệnh nhân Xét nghiệm - 38 - Nguồn lưu trữ Chú giải ảnh Lớp tổ hợp ảnh CR ảnh CT ảnh số hoá film ảnh MR ảnh y học hạt nhân Đồ hoạ Đồ hình Lớp dịch vụ DICOM Các dịch vụ DICOM được sử dụng để truyền đối tượng bên trong thiết bị, và cho thiết bị thực hiện một dịch vụ cho đối tượng (ví dụ lưu, hiển thị...). Bảng 2.3 Các lớp dịch vụ Lớp dịch vụ Miêu tả Lưu ảnh Cung cấp dịch vụ lưu trữ các tập dữ liệu Chất vấn Cung cấp việc chất vấn về tập dữ liệu Truy vấn ảnh Cung cấp việc tìm ảnh từ thiết bị hiển thị In ảnh Cung cấp in ấn ảnh Xét nghiệm Cung cấp việc quản lý xét nghiệm Tài nguyên lưu trữ Cung cấp quản lý tài nguyên lưu trữ dữ liệu Một lớp dịch vụ được xây dựng trên một tập “các phần tử dịch vụ truyền thông DICOM” được gọi là DIMSE. Các DIMSE là các chương trình phần mềm để thực hiện chức năng xác định. Có 2 loại DIMSE, một cho đối tượng tổ hợp, một cho đối tượng tiêu chuẩn (bảng 3.4 và 3.5). Mỗi DIMSE tổ hợp được cặp đôi mà một thiết bị đưa ra yêu cầu và một thiết bị nhận đáp ứng yêu cầu đó. Vì trong môi - 39 - trường hướng đối tượng thì các dịch vụ của DICOM được coi là các lớp dịch vụ. Nếu một thiết bị cung cấp một dịch vụ thì nó được gọi là SCP (Service Class Provider). Và thiết bị sử dụng dịch vụ được gọi là SCU (Service Class User). Chẳng hạn, đĩa từ là SCP để cho PACS controller lưu trữ dữ liệu, và CT scanner là SCU cho đĩa từ trong PACS conntroller lưu trữ ảnh. Có thể một thiết bị vừa là SCP và SCU như: PACS controller gửi ảnh tới trạm hiển thị bằng cách đưa ra các yêu cầu dịch vụ thì PACS controller là SCU. Nếu PACS controller nhận ảnh từ các máy scanner bằng cách cung cấp cung cấp dịch vụ lưu trữ cho các ảnh này thì nó là SCP. Bảng 3.4 DIMSE tổ hợp Lệnh Chức năng C-ECHO Xác định kết nối C-STORE Truyền dẫn đối tượng thông tin C-FIND Tìm kiếm đối tượng thông tin C-GET Truyền dẫn đối tượng thông tin có xử lý và điều khiển C-MOVE Tương tự như C-GET nhưng không có khởi tạo lệnh Bảng 3.5 DIMSE đối tượng tiêu chuẩn Lệnh Chức năng N-EVENT-REPORT Khai báo sự kiện liên quan tới đối tượng thông tin N-GET Tìm giá trị thuộc tính của đối tượng thông tin N-ACTION Xác định hoạt động có liên quan tới đối tượng thông tin N-SET Xác định giá trị thuộc tính của đối tượng thông tin N-CREATE Tạo đối tượng thông tin N-DELETE Xoá đối tượng thông tin Khi thông tin được truyền giữa hai thiết bị thì tiến trình này yêu cầu phải có giao thức truyền. DICOM sử dụng các chuẩn của mạng thông tin hiện tại dựa trên - 40 - mô hình 7 lớp OSI. Ví dụ, để truyền ảnh từ máy CT scanner tới trạm hiển thị với giao thức truyền là DICOM, quá trình gồm các bước như sau: - Máy CT scanner mã hóa tất cả các ảnh cần truyền sang đối tượng DICOM. - Máy CT scanner sử dụng các DIMSE để chuyển các đối tượng từ một lớp dịch vụ nào đó xuống lớp vật lý trong mô hình OSI. - Trạm hiển thị sử dụng các DIMSE để nhận các đối tượng thông qua lớp vật lý và chuyển chúng tới lớp dịch vụ xác định. - Trạm hiển thị giải mã các đối tượng DICOM nhận được. Hình 2.3. Quá trình truyền ảnh từ CT scanner tới trạm hiển thị CT scanner mã hóa các ảnh thành đối tượng DICOM Trạm hiển thị giải mã đối tượng DICOM sang ảnh để hiện thị Các DIMSE gửi Các DIMSE nhận Dịch vụ DICOM Dịch vụ DICOM TCP/IP Kết nối mạng Bên gửi Bên nhận - 41 - CHƯƠNG III. TÌNH HÌNH ỨNG DỤNG HỆ THỐNG THÔNG TIN Y TẾ TẠI VIỆT NAM; CÁC ĐỀ XUẤT GIẢI PHÁP KỸ THUẬT XÂY DỰNG HỆ THỐNG 3.1. Thực trạng y tế Việt Nam Mang lưới cơ sở y tế tại Việt Nam được phân cấp như trên hình 3.1 có quy mô khác biệt rõ rệt giữa các tuyến. Với khoảng 30 bệnh viện tuyến trung ương và 300 bệnh viện đa khoa, chuyên khoa tuyến tỉnh trong khi mỗi năm có tới hơn 150 triệu lượt khám bệnh dẫn đến tình trạng hệ thống bệnh viện nước ta luôn trong tình trạng bị quá tải. Hình 3.1. Mạng lưới bệnh viện và các cơ sở y tế khác ở Việt Nam và phân tuyến kỹ thuật ¾ 9 Đa khoa TW ¾ 21 Chuyên khoa TW ¾ 542 Bệnh viện tuyến huyện ¾ 37 Bệnh viện thị xã Tuyến cuối Tuyến hai Tuyến tiếp nhận đầu tiên BỘ Y TẾ SỞ Y TẾ TRUNG TÂM Y TẾ TUYẾN HUYỆN Y TẾ CƠ SỞ ¾ 107 Đa khoa truyến Tỉnh ¾ 197 Chuyên khoa tuyến tỉnh ¾ 64 Trung tâm y học dự phòng Tuyến ba ¾ 9806 Trung tâm y tế xã ¾ Y tế thôn bản - 42 - Theo thống kê, hàng năm Bệnh viện Việt Đức có khoảng 1.000 trường hợp bênh nhân bị tử vong trên đường chuyển đến bệnh viện. Trong số đó, có không ít trường hợp nếu được xử lý ban đầu tốt thì hoàn toàn có thể có cơ hội cứu sống được những bệnh nhân này. Trước thực trạng này, Bộ y tế và các bệnh viện đang gấp rút triển khai việc ứng dụng công nghệ thông tin trong quản lý bệnh viện với từng mức độ ứng dụng khác nhau, đối với một số bệnh viện có thể mới chỉ dừng lại ở mức độ quản lý trên máy tính, lưu trữ đầy đủ thông tin cần thiết về bệnh nhân, có thể xa hơn nữa là trao đổi hồ sơ bệnh án giữa các bệnh viện, chẩn đoán từ xa, hội chẩn từ xa,... Dù ở mức độ ứng dụng quy mô lớn hay nhỏ, nhưng Bộ y tế vẫn luôn hướng tới một tiêu chí chung là xây dựng hệ quản lý theo chuẩn quốc tế, mà chủ yếu là chuẩn HL7 trong hệ thống quản lý bệnh viện (HIS) và chuẩn DICOM trong quản lý hình ảnh (RIS & PACS). Có thể đưa ra một số dự án lớn đã được triển khai như: (1) Đề tài "Nghiên cứu triển khai thử nghiệm Mạng y tế từ xa" với việc truyền hình ảnh, các dữ liệu y tế giữa các bệnh viện để tư vấn và chẩn đoán bệnh, bước đầu là tư vấn hội chẩn siêu âm tim mạch từ xa được thực hiện bởi Viện Khoa học kỹ thuật bưu điện (Học viện Công nghệ bưu chính viễn thông) kết hợp với các Viện, gồm: Viện Tim mạch Bạch Mai, Viện Nhi, Bệnh viện Bưu điện, Bệnh viện Đa khoa Bắc Giang và Bệnh viện Đa khoa Lạng Sơn. Siêu âm tim mạch được chọn để triển khai thử, do tính đồng bộ và khả năng kết nối về thiết bị và do bệnh lý về tim mạch trong thực tế cũng chiếm tỷ lệ cao, hơn nữa, ảnh siêu âm tim mạch đòi hỏi chất lượng cao nên nếu truyền ảnh đạt yêu cầu thì hoàn toàn có thể triển khai cho nội soi và chụp cắt lớp. Kết quả thử nghiệm: Mạng đã kết nối thành công, toàn bộ các hình ảnh (gồm: hình ảnh bệnh nhân, thao tác của bác sĩ siêu âm) và dữ liệu siêu âm tim mạch cần thiết giữa các điểm mạng được truyền trực tiếp về Viện Tim mạch; đồng thời thực hiện nối đối thoại hình và ảnh giữa Trung tâm và hai bệnh viện tuyến tỉnh để phục vụ việc phân tích và hội chẩn. - 43 - Hình 3.2. Mô hình mạng y tế từ xa Hệ thống bắt ảnh và ghép nối từ siêu âm ra máy tính được triển khai tại mỗi điểm mạng, đảm bảo được yêu cầu chất lượng ảnh cho tư vấn và chẩn đoán, với thời gian truyền từ 1-3 phút tùy theo tuyến nội hạt hay liên tỉnh. Kết quả được các chuyên gia y tế chấp nhận. Theo các chuyên gia viễn thông, giải pháp mạng kết nối, bắt và nén ảnh bảo đảm chất lượng y tế với thời gian truyền ảnh 1 phút là khả thi về mặt kỹ thuật. (2) Dự án Bệnh viện vệ tinh: được phối hợp tổ chức bởi Bộ Y tế và Bộ Bưu chính Viễn thông (đơn vị trực tiếp thực hiện là Tổng công ty Bưu chính Viễn thông Việt Nam - VNPT). Bước đầu, dự án đang được triển khai thử nghiệm tại Bệnh vện Việt Đức và sáu bệnh viện tỉnh phía Bắc gồm: Bệnh viện đa khoa tỉnh Bắc Ninh, Bệnh viện đa khoa Việt Tiệp-Hải Phòng, bệnh viện đa khoa tỉnh Phú Thọ, bệnh viện - 44 - đa khoa khu vực Sơn Tây, bệnh viện đa khoa tỉnh Thanh Hóa, và bệnh viện đa khoa tỉnh Nam Định. Ca tư vấn phẫu thuật trực tuyến qua cầu truyền hình đầu tiên được thực hiện giữa Bệnh viện Việt Đức và Bệnh viện Việt Tiệp Hải Phòng đã thành công sau hơn 30 phút. Một bệnh nhân 57 tuổi ở Hải Phòng bị viêm túi mật do sỏi đã được 2 bệnh viện hội chẩn và tiến hành mổ cắt bỏ túi mật đã bị viêm bằng phương pháp nội soi. Trong suốt quá trình này, kíp mổ của Bệnh viện Việt Tiệp Hải Phòng đã được các giáo sư, bác sỹ ở Bệnh viện Việt Đức theo dõi và chỉ đạo sát sao đến từng thao tác bóc, tách, cắt, đốt và gắp bỏ bệnh phẩm ra ngoài ổ bụng bệnh nhân. Theo nghiên cứu, nhờ có hệ thống tư vấn từ xa trong dự án Bệnh viện vệ tinh này sẽ góp phần giảm tới 50% những trường hợp bệnh nhân không cần thiết phải chuyển lên tuyến trên và không được chữa trị kịp thời; giảm từ 70-80% những trường hợp bệnh nhân điều trị sai bệnh ở các bệnh viện tuyến dưới. Kết quả sau khi dự án triển khai giai đoạn I, tại BV đa khoa Thanh Hóa số lượng ca phẫu thuật đã tăng từ 2838 ca (2003) lên 7432 ca (9 tháng đầu năm 2006); Năm 2004, có hơn 2.800 bệnh nhân từ Phú Thọ chuyển lên Hà Nội thì đến năm 2006 chỉ còn 2.100 ca phải lên tuyến trung ương, số bệnh nhân phẫu thuật năm 2004 là 3.224 bệnh nhân, 9 tháng năm 2006 đã tăng lên 5.432 bệnh nhân, số ca tử vong ở BV Phú Thọ cũng giảm từ 105 trường hợp (năm 2003) xuống 70 trường hợp (năm 2006). Tại bệnh viện đa khoa khu vực Sơn Tây: số bệnh nhân phẫu thuật 9 tháng năm 2006 tăng gần gấp đôi so với năm 2004, với 1.642 bệnh nhân. l - 45 - Dự kiến BV vệ tinh sẽ được mở rộng triển khai tiếp tại sáu BV đa khoa các tỉnh Thái Bình, Hoà Bình, Lạng Sơn, Quảng Ninh, Ninh Bình và BV Đa khoa trung ương Thái Nguyên. (3) Dự án "Y học từ xa" của Bộ Quốc phòng giai đoạn mở đầu thực hiện vào nǎm 2000 cũng là một nỗ lực đáp ứng nhu cầu y tế từ xa của nước ta. Các thành viên tham gia dự án: bệnh viện Trung ương quân đội 108 (Hà Nội) và Quân y viện 175 (Tp. Hồ chí Minh). Tại mỗi bệnh viện đều thiết lập một mạng LAN kết nối 2 máy chẩn đoán hình ảnh chủ yếu là CT và Siêu âm. Dùng 3 máy tính bình thường làm 3 trạm làm việc: 1 ở máy CT, 1 ở máy Siêu âm và 1 ở phòng giao ban. Nhờ một card mạng và phần mềm tương ứng, hình ảnh số hoá được lấy ra từ thiết bị sinh hình và chuyển sang mạng. Các trạm làm việc vừa đảm bảo xem hình, vừa thực hiện chức nǎng hậu xử lý (postprocessing): thay đổi độ rộng cửa sổ, mức cửa sổ; đảo hình, xoay hình; khuếch đại soi kính (Magnifying Glass); phóng đại hình theo các hệ số hay vùng yêu cầu; đo khoảng cách và đo góc; đo tỷ trọng cho từng điểm; chú thích trên hình và có thể thao tác xem từng hình hay nhiều hình đồng thời. Hình ảnh lưu chuyển trên mạng theo chuẩn DICOM, giao thức TCP/IP. Khi cần thiết, có thể ghép TCP/IP vào mạng máy Laser Camera theo chuẩn DICOM và từ đó có thể in phim trên mạng, tiết kiệm được máy in ở các thiết bị sinh hình (trước đây mỗi thiết bị sinh hình đều có một máy in, sau khi có mạng chỉ cần sử dụng một máy in phim dùng chung cho tất cả các thiết bị sinh hình). Thông qua một máy chủ truyền thông, toàn bộ hình ảnh cần thiết cho chẩn đoán có thể truyền từ Bệnh viện Trung ương quân đội 108 vào QY viện 175 và ngược lại, đồng thời hình ảnh cũng có thể được tổ chức lại, được lưu trữ và khi cần có thể tìm lại và cho tái hiện nhanh chóng, góp phần nâng cao chất lượng chẩn đoán. Cũng từ đó sẽ hình thành một ngân hàng dữ liệu về hình ảnh và tạo tiền đề cho công tác nghiên cứu, đào tạo nhằm nâng cao chuyên môn. Những năm gần đây, các bệnh viện đã dần chuyển sang hình thức quản lý bệnh viện điện tử bằng cách triển khai các phần mềm HIS do một số công ty phần - 46 - mềm Việt Nam cung cấp. Với cách thức này, việc quản lý đã trở nên khả quan hơn, song nếu nhìn một cách vĩ mô ta sẽ thấy có nhiều điều bất cập. 3.2. Các đề xuất giải pháp kỹ thuật xây dựng mạng thông tin y tế Việt Nam Để có thể trao đổi thông tin y tế giữa các bệnh viện thì phải giải quyết được ba bài toán cơ bản: Thứ nhất là bài toán liên tác về ngữ nghĩa, nghĩa là bên gửi và bên nhận phải diễn giải giống nhau về các thông tin được trao đổi. Bài toán thứ hai là bài toán liên tác về cú pháp, nghĩa là bên gửi và bên nhận phải thống nhất với nhau về quy trình trao đổi thông tin. Bài toán thứ ba là bài toán về mô hình truyền - nhận. 3.2.1. Các mô hình truyền nhận dữ liệu có thể ứng dụng ở Việt Nam 3.2.1.1. Mô hình dữ liệu file-server Khái niệm: Trong mô hình cơ sở dữ liệu theo kiểu file - server các thành phần ứng dụng hay các phần mềm cơ sở dữ liệu sẽ ở trên một hệ thống máy tính và các file vật lý tạo nên cơ sở dữ liệu sẽ nằm trên hệ thống máy tính khác. Một cấu hình như vậy thường được dùng trong môi trường cục bộ, trong đó một hoặc nhiều hệ thống máy tính đóng vai trò của server, lưu trữ các file dữ liệu cho hệ thống máy tính khác thâm nhập tới. Trong môi trường file - server, thông qua phần mềm mạng, các phần mềm ứng dụng cũng như phần mềm cơ sở dữ liệu chạy trên hệ thống của người dùng cuối sẽ coi các file hoặc cơ sở dữ liệu trên file server thực sự như là trên máy tính của người chính họ. Mô hình file server rất giống với mô hình tập trung. Tuy nhiên nó phức tạp hơn mô hình tập trung bởi vì phần mềm mạng có thể phải thực hiện cơ chế đồng thời cho phép nhiều người dùng cuối có thể truy nhập vào cùng cơ sở dữ liệu. Đây là mô hình mạng đang được ứng dụng trong các bệnh viện tại Việt Nam. Với mô hình file - server, thông tin gắn với sự truy nhập cơ sở dữ liệu vật lý phải chạy trên toàn mạng. Một giao tác yêu cầu nhiều sự truy nhập dữ liệu có thể gây ra tắc nghẽn lưu lượng truyền trên mạng. - 47 - Giả sử một người dùng cuối tạo ra một vấn tin để lấy dữ liệu tổng số, yêu cầu đòi hỏi lấy dữ liệu từ 1000 bản ghi, với cách tiếp cận file - server nội dung của tất cả 1000 bản ghi phải đưa lên mạng, vì phần mềm cơ sở dữ liệu chạy trên máy của người sử dụng phải truy nhập từng bản ghi để thoả mãn yêu cầu của người sử dụng. Áp dụng mô hình trong y tế: Hình 3.4. Mô hình hệ thống trong mạng diện rộng Khi áp dụng mô hình này để giải quyết bài toán truyền dữ liệu y tế trên mạng diện rộng sẽ gặp phải những yếu điểm sau: - Thứ nhất, có thể đảm bảo được tốc độ truyền / nhận dữ liệu qua mạng cục bộ của một bệnh viện, nhưng để truyền / nhận giữa các bệnh viện với nhau thì yêu cầu phải xây dựng một mạng diện rộng với lưu lượng truyền lớn, vì vậy để có một mạng hoạt động tốt thì chi phí dành cho nó cũng rất tốn kém. - Thứ hai, với mô hình này yêu cầu về tập cơ sở dữ liệu phải hoàn toàn tương đồng mới có thể thực hiện truyền / nhận thông tin. Ví dụ, muốn chuyển một hồ sơ bệnh án của bệnh nhân từ bệnh viện đa khoa tỉnh Bắc Giang tới bệnh viện Việt Đức, thực hiện truyền qua server đặt tại Bộ y tế, thì phần mềm cơ sở dữ liệu của hai bệnh viện phải hoàn toàn giống nhau. Đây là yêu cầu không khả thi vì mỗi bệnh viện mang một đặc thù riêng nên dữ liệu của bệnh viện cũng có tính đặc thù. Chính vì vậy, các - 48 - bệnh viện tại Việt Nam dù đã thực hiện quản lý bệnh viện bằng hệ thống HIS nhưng vẫn chưa thể kết nối được các bệnh viện với nhau. 3.2.1.2. Mô hình dữ liệu client/server Khái niệm: Trong mô hình cơ sở dữ liệu Client/Server, cơ sở dữ liệu nằm trên một máy khác với các máy có thành phần xử lý ứng dụng. Nhưng phần mềm cơ sở dữ liệu được tách ra giữa hệ thống Client chạy các chương trình ứng dụng và hệ thống Server lưu trữ cơ sở dữ liệu. Trong mô hình này, các thành phần xử lý ứng dụng trên hệ thống Client đưa ra yêu cầu cho phần mềm cơ sở dữ liệu trên máy client, phần mềm này sẽ kết nối với phần mềm cơ sở dữ liệu chạy trên Server. Phần mềm cơ sở dữ liệu trên Server sẽ truy nhập vào cơ sở dữ liệu và gửi trả kết quả cho máy Client. Mới nhìn, mô hình cơ sở dữ liệu Client/Server có vẻ giống như mô hình file - server, tuy nhiên mô hình Client/Server có rất nhiều thuận lợi hơn mô hình file - server. Giả sử một người dùng cuối tạo ra một vấn tin để lấy dữ liệu tổng số, yêu cầu đòi hỏi lấy dữ liệu từ 1000 bản ghi, với cách tiếp cận cơ sở dữ liệu Client/Server, chỉ có lời vấn tin khởi động ban đầu và kết quả cuối cùng cần đưa lên mạng, phần mềm cơ sở dữ liệu chạy trên máy lưu giữ cơ sở dữ liệu sẽ truy nhập các bản ghi cần thiết, xử lý chúng và gọi các thủ tục cần thiết để đưa ra kết quả cuối cùng. 3.2.1.3. Mô hình dữ liệu phân tán Cả hai mô hình File - Server và Client/Server đều giả định là dữ liệu nằm trên một bộ xử lý và chương trình ứng dụng truy nhập dữ liệu nằm trên một bộ xử lý khác, còn mô hình cơ sở dữ liệu phân tán lại giả định bản thân cơ sở dữ liệu có ở trên nhiều máy khác nhau. Giới thiệu một mô hình dữ liệu phân tán đã ứng dụng ở Việt Nam Mô hình kiến trúc yHealth và các dòng sản phẩm của nó (đang sắp được triển khai tại bệnh viện chợ Rẫy) đã giải quyết được hai bài toán đầu tiên (3.2) (bài toán - 49 - liên tác về ngữ nghĩa và bài toán liên tác về cú pháp). Kiến trúc yHealth là một kiến trúc phân tán cho phép nhiều hệ thống con (hay phân hệ) hoạt động độc lập (hay tự trị) nhưng vẫn có thể liên tác và hiệp đồng hoạt động với nhau dù ở cách xa nhau về mặt địa lý. Để liên tác được với các phân hệ của mình cũng như với các hệ thống khác, yHealth đã xây dựng nên một hệ thống giao tiếp riêng – được thiết kế giống như một hệ trung gian để tiếp nhận và xử lý các bản tin gửi/nhận theo chuẩn. Muốn vậy, các hệ thống với kiến trúc yHealth nhất thiết phải hỗ trợ các chuẩn mở trong công nghệ thông tin cũng như công nghệ thông tin y tế, bao gồm: các chuẩn và giao thức chuẩn về mạng (ví dụ: TCP/IP), các giao thức chuẩn trao đổi thông tin trên internet (HTTP, FTP), các chuẩn trao đổi dữ liệu y tế (DICOM, HL7). Kiến trúc yHealth được phân thành 3 tầng hoạt động theo mô hình Client- Server và được xây dựng theo kiến trúc SOA (Service-Oriented Architecture): tầng INTERN, tầng EXTERN và tầng GUI. Tầng INTERN: Tầng INTERN cấu tạo bởi các đơn vị cấu thành (element unit) dưới dạng các module hoạt động tương đối độc lập cung cấp các dịch vụ cho tầng EXTERN thông qua các giao diện (interface) với các phương thức mà bên yêu cầu dịch vụ có thể gọi trực tiếp. Để bảo đảm tính độc lập và linh hoạt của môđun, các môđun được thiết kế chỉ để cung cấp dịch vụ mà không sử dụng dịch vụ; nghĩa là các môđun không trao đổi trực tiếp với nhau. Theo cách này, các môđun có thể hoạt động như bộ phận quản lý dữ liệu đơn thuần. Tầng EXTERN Bao quát bên trên tầng INTERN (các môđun) là tầng EXTERN chịu trách nhiệm giao tiếp với tầng GUI và với các hệ thống khác. Về mặt chức năng, tầng EXTERN là bên cung cấp các dịch vụ đáp ứng các yêu cầu nghiệp vụ (business logic) mà ở đây là nghiệp vụ y tế. Được xây dựng theo kiến trúc SOA, tầng EXTERN được thiết kế sao cho có thể điều chỉnh linh hoạt, phù hợp với các quy trình nghiệp vụ y tế của từng cơ sở y tế. - 50 - • Đối với tầng GUI, tầng EXTERN cung cấp các dịch vụ thông qua các giao diện, tương tự như tầng INTERN cung cấp dịch vụ cho tầng EXTERN. • Đối với các hệ thống khác, tầng EXTERN cung cấp dịch vụ thông qua các thông điệp theo đúng chuẩn thông điệp (bản tin) của HL7 và DICOM. Tầng INTERN và EXTERN được triển khai chung với nhau tạo thành bên cung cấp dịch vụ server). Tầng GUI: Tầng GUI là tầng giao diện người sử dụng, cho phép người sử dụng có thể đưa ra các yêu cầu của mình thông qua giao diện hình ảnh. Ngoài phần giao diện hình ảnh dùng để giao tiếp với người sử dụng, tầng GUI cần được thiết kế để duy trì một số dữ liệu thường dùng và ít thay đổi nhằm giảm bớt khối lượng dữ liệu truyền qua mạng. Tầng GUI cũng có thể được triển khai dưới dạng ứng dụng Web. Khi đó, tầng GUI sẽ không giao tiếp trực tiếp với tầng EXTERN mà sẽ trao đổi gián tiếp thông qua một Web server. Khi đó, Web server sẽ giao tiếp trực tiếp với tầng EXTERN. 3.2.2. Vấn đề liên tác về ngữ nghĩa và cú pháp: Với yêu cầu quản lý ở bệnh viện Việt Nam gồm: (1) Quản lý phòng khám (tiếp đón bệnh nhân, quản lý nhập xuất phòng khám, yêu cầu cận lâm sàng phòng khám, xem kết quả cận lâm sàng trên mạng, quản lý thuốc, quản lý khoa khám dịch vụ, vật tư tiêu hao tại các phòng khám,...) (2) Quản lý bệnh nhân nội trú (nhập viện, xuất viện, dự trù thuốc cho bệnh nhân nội trú, dự trù vật tư tiêu hao, quản lý phẫu thuật thủ thuật nội trú, yêu cầu cận lâm sàng, tổng hợp báo cáo…) (3) Quản lý bệnh nhân ngoại trú (nhập viện, xuất viện, dự trù thuốc cho bệnh nhân ngoại trú, dự trù vật tư tiêu hao, quản lý phẫu thuật thủ thuật ngoại trú, yêu cầu cận lâm sàng, quản lý thuốc, tổng hợp báo cáo…) (4) Quản lý phòng mổ (quản lý phẫu thuật - thủ thuật bệnh nhân ngoại ,nội trú; quản lý lịch phẫu thuật - thủ thuật; quản lý tường trình phẫu thuật - thủ thuật; quản - 51 - lý danh sách bệnh nhân phẫu thuật – thủ thuật; quản lý các tủ thuốc, vật tư tiêu hao tại các phòng mổ; tổng hợp báo cáo…) (5) Quản lý xét nghiệm (xét nghiệm huyết học, sinh hoá, vi sinh, miễn dịch, quản lý vật tư hóa chất xét nghiệm, quản lý lấy mẫu thử, trả lời kết quả xét nghiệm, kết nối máy xét nghiệm với hệ thống tổng hợp báo cáo…) (7) Quản lý viện phí bệnh nhân nội, ngoại trú. (8) Quản lý dược. (9) Quản lý vật tư. (10) Quản lý nhân sự. (11) Báo cáo tổng hợp tình hình chung cho Ban giám đốc. Chuẩn HL7 do tổ chức HL7 đưa ra với 92 loại bản tin và hơn 200 loại sự kiện đã bao chùm toàn bộ nội dung quản lý trên. Do vậy đối với Việt Nam, khi mới đi vào triển khai phần mềm theo chuẩn này có thể sử dụng một số bản tin điển hình do HL7 định nghĩa ra. Với quy mô của một bệnh viện là rất lớn với nhiều mô đun phân khoa khác nhau mang những đặc trưng riêng nên trong luận văn này tôi chỉ dừng lại ở việc đưa ra mô hình quản lý tại khu khám bệnh và ứng dụng từng loại bản tin mà chuẩn HL7 quy định để thông tin được đảm bảo là tuân thủ đúng chuẩn quốc tế và phù hợp với yêu cầu của Việt Nam. Mô hình khu khám bệnh được xây dựng như trong hình 3.5. Để xây dựng một phần mềm quản lý bệnh viện hoàn chỉnh đảm bảo tuân theo đúng chuẩn quốc tế phục vụ yêu cầu lưu trữ, truyền/nhận thông tin giữa các cơ sở, giữa các quốc gia phải yêu cầu sự chuẩn hóa nghiêm ngặt từ những mô đun thành phần. Với mô đun quản lý phòng khám tại khu tiếp đón bệnh nhân đã xây dựng trên hình 3.5, để xác định được đúng loại bản tin cần phải nắm được quy trình và nhiệm vụ của từng thành phần cấu thành nên mô đun đó. - 52 - Với mô hình này, việc quản lý chủ yếu liên quan tới các quy trình sau: I. Tại các quầy tiếp đón bệnh nhân 1. Quầy tiếp đón bệnh nhân có bảo hiểm, bệnh nhân thuộc diện chính sách và trẻ em dưới 6 tuổi: - Tạo mới phiếu khám bệnh; - Nhập chính xác và lưu lại tất cả các thông tin về hành chính cũng như các loại thẻ (BHYT, Trẻ em, Người nghèo) cũng như các giấy tờ cần thiết; - In ra phiếu khám bệnh đưa cho bệnh nhân; - Lên số liệu báo cáo hàng ngày. BỆNH NHÂN ĐẾN KHÁM BỆNH Khu tiếp đón bệnh nhân có bảo hiểm, trẻ em Khu tiếp đón bệnh nhân dịch vụ Đối tượng chính sách, bảo hiểm, trẻ em Đối tượng khám dịch vụ CÁC PHÒNG KHÁM Quầy duyệt bảo hiểm, chính sách Nơi làm bệnh án nhập viện Quầy duyệt thuốc dịch vụ Quầy thu tiền phí cận lâm sàng, phẫu thuật, thủ thuật Quầy thuốc dịch vụ Nơi cấp thuốc bảo hiểm, chính sách khám dịch vụ khám dịch vụ Bảo hiểm, chính sách khám dịch vụ khám dịch vụ Bảo hiểm, chính sách Hình 3.5. Sơ đồ hoạt động khu khám bệnh - 53 - 2. Quầy tiếp đón bệnh nhân khám dịch vụ: - Tạo mới phiếu khám bệnh; - Nhập chính xác và đầy đủ các thông tin về hành chính của bệnh nhân; - Lưu lại phiếu khám; - In phiếu khám và đưa cho bệnh nhân; - Lên số liệu báo cáo hàng ngày. Yêu cầu xử lý được các tình huống xảy ra: - Tại quầy tiếp đón bệnh nhân sẽ có các trường hợp xảy ra liên quan đến công việc hàng ngày như: + Tiếp đón cho bệnh nhân khám nhiều phòng + Tiếp đón bệnh nhân đến khám lại: Nhập vào mã số bệnh nhân (hoặc số hồ sơ bệnh án) ghi trên sổ khám bệnh của bệnh nhân + Sửa thông tin hành chính của bệnh nhân: tên, tuổi, giới tính, địa chỉ… + Cập nhật thông tin về đối tượng bệnh nhân, thẻ khám chữa bệnh (thẻ bảo hiểm y tế, thẻ miễn phí trẻ em, thẻ người nghèo...) + Cập nhật các thông tin về phòng khám, kiểu khám + Cập nhật các thông tin chuyển tuyến của bệnh nhân >> Việc chỉnh sửa, cập nhật các thông tin tại quầy tiếp đón bệnh nhân có vai trò rất quan trọng vì nó đảm bảo cho các thông tin liên quan đến bệnh nhân tại phòng khám, viện phí và dược được đầy đủ và chính xác. II. Tại các buồng khám bệnh - Gọi bệnh nhân vào khám bệnh theo số phiếu tiếp đón - Tạo phiếu khám nhập đầy đủ các thông tin cần thiết trên phiếu khám - Chỉ định các xét nghiệm cận lâm sàng, các thủ thuật đầy đủ và chính xác. Sau khi đã chỉ định thì phải gửi các phiếu đó sang trạng thái S. Trong trường hợp bệnh nhân không làm các xét nghệm cận lâm sàng hay các thủ thuật thì phải huỷ bỏ yêu cầu đã gửi đi về trạng thái O. Sau đó xoá phiếu đó đi - 54 - - Khi có kết quả các xét nghiệm cận lâm sàng trả về, phải nhập đầy các kết quả vào mục kết quả cận lâm sàng. - Đơn thuốc khi kê phải chính xác về tên thuốc cũng như số lượng và cách chỉ định dùng thuốc. Khi kê đơn thuốc xong phải gửi yêu cầu để trạng thái = S - Phải “Cập nhật hồ sơ khám” của bệnh nhân sau khi lần khám đó đã kết thúc (trường hợp BN khám nhiều phòng, được nhiều BS khám, sẽ có nhiều phiếu khám khác nhau và nhiều kết luận bệnh khác nhau nhưng chỉ có một bệnh chính được kết luận theo chuẩn mã hóa bệnh tật quốc tế ICD 10) - Khi bệnh nhân được gửi đi làm cận lâm sàng hoặc hẹn chờ mổ, Cần “Cập nhật hồ sơ khám”, trong phần hướng điều trị phải chọn mã điều trị là J – hẹn khám lại, khám chờ mổ. Công việc này đảm bảo lần sau bệnh nhân đến khám lại,chương trình không tạo ra hồ sơ mới mà chỉ tạo ra một phiếu khám mới. Yêu cầu xử lý được các tình huống xảy ra: - Đổi phòng khám: Tác vụ này được sử dụng để chuyển hồ sơ khám bệnh của BN từ phòng khám A sang phòng khám B (hồ sơ khám tại phòng khám A sẽ không còn nữa) - Chuyển khám tiếp: Khi cần cho bệnh nhân khám tại một số phòng khám khác ta dùng chức năng chuyển khám tiếp. Trước khi chuyển khám tiếp, cần có chẩn đoán sơ bộ và kết luận bệnh tại phòng đã khám để phiếu khám có trạng thái “P”. Bác sĩ khám tại phòng khám cuối cùng cho bệnh nhân sẽ là người đưa ra kết luận cuối cùng về bệnh chính của bệnh nhân và đưa ra hướng điều trị tiếp theo - Trường hợp kê đơn thuốc nhưng thuốc tại kho trong máy đã hết cần phối hợp với khoa Dược để có thuốc đầy đủ kê đơn cho bệnh nhân - Phối hợp với bộ phận viện phí, tiếp đón để cập nhật các thông tin về cận lâm sàng, phẫu thuật, thủ thuật, thông tin tiếp đón khi cần thiết - 55 - III. Tại các quầy thu viện phí - Dựa vào mã số Hồ sơ của bệnh nhân để tìm hồ sơ phí; - Kiểm tra các mục phí cần thu đã đủ và đúng chưa. Nếu các mục phí chưa đúng thì phải phản hồi lại với nhân viên Buồng khám đó để kịp thời chỉnh sửa; - In phiếu thu; - Lên số liệu báo cáo hàng ngày. IV. Tại quầy duyệt BHYT - Tìm hồ sơ phí của bệnh nhân theo mã số hồ sơ; - Kiểm tra đối tượng bệnh nhân; - Kiểm tra hồ sơ các chi phí của bệnh nhân đã đủ hoặc thiếu không. Nếu có sai sót thì phản hồi lại ngay với nhân viên tại Buống khám đó, để kịp chỉnh sửa khắc phụ sai sót; - Duyệt các chi phí và đơn thuốc; - In đơn thuốc và phiếu lĩnh thuốc; - In phiếu khám bệnh cho bệnh nhân; - In ra tờ chi phí khám bệnh (Bảng kê chi tiết phí). V. Tại quầy duyệt thuốc bệnh nhân dịch vụ 1. Bệnh nhân mua thuốc a. Bệnh nhân mua đủ số lượng thuốc - “Duyệt đơn thuốc” để số lượng được trừ trong kho; - Bệnh nhân mua đủ số lượng trong đơn thì in đơn thuốc + phiếu mua thuốc và phiếu khám bệnh. b. Bệnh nhân không mua đủ số lượng trong đơn thuốc - Sửa số lượng thuốc trong đơn theo sự thỏa thuận với bệnh nhân; - Khi bệnh nhân đồng ý mua thuốc Duyệt đơn thuốc; - In đơn thuốc và phiếu mua thuốc; - In phiếu khám bệnh. - 56 - 2. Bệnh nhân không mua thuốc - Nếu bệnh nhân không mua thuốc. Phải “huỷ yêu cầu” để trạng thái của đơn thuốc chuyển từ “S” sang “C” 3. Bệnh nhân sau 1 thời gian quay lại mua thuốc Trong trường hợp bệnh nhân sau 1 thời gian quay lại mua thuốc, yêu cầu: - Tìm lại bệnh án của bệnh nhân; - “Tính lại yêu cầu” của đơn thuốc để trạng thái của đơn thuốc chuyển từ “C” sang “S”; - “Duyệt đơn thuốc”; - In đơn thuốc và phiếu mua thuốc; - In phiếu khám bệnh. VI. Tại quầy làm bệnh án vào viện - Mở chương trình quản lý khám bệnh; - Tạo bệnh án vào viện cho bệnh nhân; - In bệnh án vào viện. Với các tác nghiệp trên, các bản tin HL7 cần được sử dụng để thống nhất về mặt cấu trúc cho tập cơ sở dữ liệu gồm: (1) Bản tin ADT^A01 (Bản tin nhập viện) với cấu trúc: ADT ADT Message MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics [ { NK1 } ] Next of Kin /Associated Parties PV1 Patient Visit [ PV2 ] Patient Visit - Additional Info. [ { DB1 } ] Disability Information [ { OBX } ] Observation/Result [ { AL1 } ] Allergy Information [ { DG1 } ] Diagnosis Information [ DRG ] Diagnosis Related Group - 57 - [ { PR1 Procedures [{ROL}] Role }] [ { GT1 } ] Guarantor [ { IN1 Insurance [ IN2 ] Insurance Additional Info. [ {IN3} ] Insurance Add’l Info - Cert. } ] [ ACC ] Accident Information [ UB1 ] Universal Bill Information [ UB2 ] Universal Bill 92 Information (2) Bản tin ADT^A08 (Bản tin cập nhật thêm thông tin bệnh nhân) với cấu trúc: ADT ADT Message MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics [ { NK1 } ] Next of Kin /Associated Parties PV1 Patient Visit [ PV2 ] Patient Visit - Additional Info. [ { DB1 } ] Disability Information [ { OBX } ] Observation/Result [ { AL1 } ] Allergy Information [ { DG1 } ] Diagnosis Information [ DRG ] Diagnosis Related Group [ { PR1 Procedures [{ROL}] Role }] [ { GT1 } ] Guarantor [ { IN1 Insurance - 58 - [ IN2 ] Insurance Additional Info. [ {IN3} ] Insurance Add’l Info - Cert. } ] [ ACC ] Accident Information [ UB1 ] Universal Bill Information [ UB2 ] Universal Bill 92 Information (3) Bản tin QRY/ADR^A19 (Bản tin tạo truy vấn) có cấu trúc: QRY Patient Query MSH Message Header QRD Query Definition [ QRF ] Query Filter (4) Bản tin ADT^A20 (cập nhật thông tin giường bệnh) có cấu trúc: ADT ADT Message MSH Message Header EVN Event Type NPU Non-Patient Update (5) BAR/ACK^P01 – Thông tin tài chính bệnh nhân, có cấu trúc: BAR Add Billing Account MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics { [ PV1 ] Patient Visit [ PV2 ] Patient Visit - Additional Info [{DB1}] Disability Information [{ OBX }] Observation/Result [{ AL1 }] Allergy Information [{ DG1 }] Diagnosis - 59 - [ DRG ] Diagnosis Related Group [{ PR1 Procedures [{ ROL }] Role }] [{ GT1 }] Guarantor [{ NK1 }] Next of Kin/Associated Parties [ { IN1 Insurance [ IN2 ] Insurance - Additional Info. [{IN3}] Insurance - Add'l Info. - Cert. } ] [ACC] Accident Information [UB1] Universal Bill Information [UB2] Universal Bill 92 Information } (6) BAR/ACK^P05 (Cập nhật tài khoản của bệnh nhân), có cấu trúc: BAR Update Billing Account MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics { [ PV1 ] Patient Visit [ PV2 ] Patient Visit - Additional Info [{DB1}] Disability Information [{ OBX }] Observation/Result [{ AL1 }] Allergy Information [{ DG1 }] Diagnosis [ DRG ] Diagnosis Related Group [{ PR1 Procedures [{ ROL }] Role }] [{ GT1 }] Guarantor - 60 - [{ NK1 }] Next of Kin/Associated Parties [ { IN1 Insurance [ IN2 ] Insurance - Additional Info. [{IN3}] Insurance - Add'l Info. - Cert. } ] [ACC] Accident Information [UB1] Universal Bill Information [UB2] Universal Bill 92 Information } (7) ADT/ACK^A51 – Bản tin thay đổi số khám bệnh ADT ADT Message MSH Message Header EVN Event Type PID Patient Identification [PD1] Additional Demographics MRG Merge Information PV1 Patient Visit ACK General Acknowledgment MSH Message Header MSA Message Acknowledgment [ ERR ] Error (8) C01 CRM (Bản tin đăng ký bệnh nhân khám lâm sàng) CRM Clinical Study Registration Message MSH Message Header {PID Patient Identification [PV1] Patient Visit CSR Clinical Study Registration {[CSP]} Clinical Study Phase } Ngoài ra cần sử dụng các bản tin: - 61 - TT Ký hiệu Tên bản tin 1 C01 CRM Cập nhật thông tin bệnh nhân khám lâm sàng 2 I07 PIN/ACK Thông tin bảo hiểm 3 C09 CSU Tự động tạo báo cáo C12 CSU Cập nhật thông tin kết quả/đề nghị của bệnh nhân I04 RQD/RPI Yêu cầu thông tin về thân nhân bệnh nhân S01 SRM/SRR Đặt lịch hẹn mới S02 SRM/SRR Yêu cầu lịch hẹn S03 SRM/SRR Điều chỉnh lịch hẹn S04 SRM/SRR Hủy bỏ lịch hẹn S05 SRM/SRR Tạm dừng lịch hẹn S06 SRM/SRR Xóa lịch hẹn S07 SRM/SRR Yêu cầu thêm các dịch vụ trong lịch hẹn S08 SRM/SRR Yêu cầu chỉnh sửa dịch vụ trong lịch hẹn S09 SRM/SRR Yêu cầu hủy bỏ dịch vụ trong lịch hẹn S10 SRM/SRR Yêu cầu tạm dừng dịch vụ trong lịch hẹn S11 SRM/SRR Yêu cầu xóa dịch vụ trong lịch hẹn S12 SIU/ACK Thông báo mới về cuộc hẹn, phòng hẹn S13 SIU/ACK Thông báo lịch biểu hẹn khám lại S14 SIU/ACK Thông báo chỉnh sửa lịch biểu hẹn khám lại S15 SIU/ACK Thông báo hủy bỏ lịch biểu hẹn khám lại S16 SIU/ACK Thông báo tạm dừng lịch biểu hẹn khám lại S17 SIU/ACK Thông báo xóa lịch biểu hẹn khám lại S18 SIU/ACK Thông báo bổ xung dịch vụ trong lịch hẹn S19 SIU/ACK Thông báo hiệu chỉnh thông tin bổ xung dịch vụ trong lịch hẹn S20 SIU/ACK Thông báo hủy bỏ bổ xung dịch vụ trong lịch hẹn S21 SIU/ACK Thông báo tạm dừng bổ xung dịch vụ trong lịch hẹn S22 SIU/ACK Thông báo xóa thông tin bổ xung dịch vụ trong lịch hẹn - 62 - Với mô hình phân tán và tập cơ sở dữ liệu đều được chuẩn hóa theo HL7 như đã trình bày trong phần 3.2 thì việc trao đổi thông tin giữa các hệ thống bệnh viện sẽ thực hiện được. Dưới đây là hai mô hình tôi đề xuất để giải quyết, dựa trên cơ sở lý thuyết đã trình bày: 3.2.3. mô hình 1: - Bên A sẽ lấy cơ sở dữ liệu của mình, từng field rồi mã hóa thành từng field tương ứng của bản tin HL7. - Thực hiện truyền bản tin HL7 thông qua giao thức HTTP có hỗ trợ kèm file - Bên B sẽ nhận dữ liệu (là file bản tin HL7 do bên A gửi), sau đó phân giải từng phần, giải mã từng field của bản tin rồi cập nhật vào cơ sở dữ liệu của mình. Ưu điểm: Mô hình dễ thực hiện, chỉ cần gọi file HL7 đính kèm rồi giải mã theo chuẩn HL7 quy định. Nhược điểm: Dung lượng bị hạn chế, tốc độ truyền không đảm bảo (đối với những dữ liệu lớn như hình ảnh, dữ liệu thoại,…) CSDL Bản tin HL7 Mã hóa Lớp ứng dụng Bệnh viện A CSDL Bản tin HL7 Giải mã Lớp ứng dụng Bệnh viện B Giao thức HTTP (kèm file) Hình 3.5. Mô hình 1 - 63 - 3.2.4. Mô hình 2: - Bên A sẽ lấy cơ sở dữ liệu của mình, từng field rồi mã hóa thành từng field tương ứng của bản tin HL7 (quá trình này được thực hiện tại tầng ứng dụng). Dữ liệu sau đó được đưa xuống tầng vật lý và gửi sang bên B thông qua giao thức TCP/IP. - Bên B sẽ nhận dữ liệu từ tầng vật lý, sau đó phân giải từng phần (giải mã từng field của bản tin HL7) rồi cập nhật vào cơ sở dữ liệu của mình. CSDL Bản tin HL7 Mã hóa Lớp ứng dụng Lớp vật lý Bệnh viện A CSDL Bản tin HL7 Giải mã Lớp ứng dụng Lớp vật lý Bệnh viện B Giao thức TCP/IP Hình 3.5. Mô hình 2 - 64 - KẾT LUẬN Qua thời gian học tập và nghiên cứu về lĩnh vực ứng dụng công nghệ thông tin trong quản lý bệnh viện; qua các đợt đi thực tế tại Bệnh viện 108, Bệnh viện Hữu nghị, Bệnh viện Quân y, Bệnh viện Đa khoa tỉnh Bắc Giang; dưới sự định hướng, chỉ bảo nhiệt tình của Thầy PGS. TS. Đặng Văn Chuyết và sự giúp đỡ nhiệt tình của Thầy Huỳnh Lương Nghĩa – PGS. TS. Chủ nhiệm Bộ môn Điện tử Y sinh – Học viện Kỹ thuật Quân sự, Thầy Phạm Đức Hiền – PGĐ Bệnh viện Hữu Nghị, tôi đã hoàn thành luận văn của mình với đề tài “Hệ thống thông tin y tế và tình hình ứng dụng tại Việt Nam”. Trong đó đã trình bày tổng quan về hệ thống thông tin y tế, tình hình ứng dụng tại Việt Nam và đưa ra một số giải pháp xây dựng hệ thống phù hợp với điều kiện nước ta. Tôi xin chân thành cảm ơn các Thầy cô, các anh/chị đã định hướng và giúp đỡ tôi hoàn thành luận văn này. Hà nội, ngày 07 tháng 11 năm 2008 Tác giả Nguyễn Thu Trang - 65 - TÀI LIỆU THAM KHẢO 1. BS. Hà Thái Sơn, “Hệ thống thông tin bệnh viện”, Vụ điều trị - Bộ y tế, 2. PGS. TS. Nguyễn Đức Thuận, ThS. Vũ Duy Hải, ThS. Trần Anh Vũ, Hệ thống thông tin y tế, Nhà xuất bản Bách khoa Hà Nội, 2006. 3. Nguyễn Hoàng Phương, Phí Văn Thâm, Nguyễn Tuấn Khoa, Kỷ yếu hội thảo khoa học: Ứng dụng công nghệ thông tin trong quản lý bệnh viện, Trung tâm tin học, Bộ y tế, 2008. 4. Vũ Công Lập, Hà Đắc Biên, Nguyễn Tuấn Khoa, Phí Vǎn Thâm, “Y học từ xa: Đại cương và những bước khởi đầu”. 5. Dr. Kai U. Heitmann, Concepts & Implementations in Health Information Projects, University of Cologne (Germany), Institute for Medical Statistics, Informatics und Epidemiology, 2003. 6. 7. - 66 - PHỤ LỤC A Bảng 1. Các loại bản tin thuộc chuẩn HL7 v2.3.1 A01 ADT/ACK - Khai báo nhập viện A02 ADT/ACK – Chuyển viện A03 ADT/ACK – Bản tin về thủ tục xuất viện A04 ADT/ACK – Bản tin về thủ tục nhập viện A05 ADT/ACK – Bản tin về thủ tục trước khi nhập viện A06 ADT/ACK – Bản tin chuyển bệnh nhân ngoại trú thành bệnh nhân nội trú A07 ADT/ACK - Bản tin chuyển bệnh nhân nội trú thành bệnh nhân ngoại trú A08 ADT/ACK – Cập nhật thông tin bệnh nhân A09 ADT/ACK – Bản tin theo dõi – chuyển viện A10 ADT/ACK – Bản tin theo dõi bệnh nhân chuyển viện tới A11 ADT/ACK – Hủy bỏ thông tin nhập viện của bệnh nhân A12 ADT/ACK – Hủy bỏ chuyển viện A13 ADT/ACK – Hủy bỏ ra viện A14 ADT/ACK – Chờ nhập viện A15 ADT/ACK – Chờ chuyển viện A16 ADT/ACK – Chờ ra viện A17 ADT/ACK – Trao đổi bệnh nhân A18 ADT/ACK – Thông tin bệnh nhân hợp nhất A19 QRY/ADR – Truy vấn bệnh nhân (tìm kiếm bệnh nhân) A20 ADT/ACK – Cập nhật giường bệnh A21 ADT/ACK – Bản tin dành cho bệnh nhận được phép vắng mặt A22 ADT/ACK – Bản tin dành cho bệnh nhân được phép vắng mặt A23 ADT/ACK – Xóa báo cáo (bệnh án) của bệnh nhân A24 ADT/ACK – Bản tin có liên quan tới thông tin bệnh nhân A25 ADT/ACK – Hủy bỏ chờ ra viện A26 ADT/ACK – Hủy bỏ chờ chuyển viện A27 ADT/ACK – Hủy bỏ chờ nhập viện - 67 - A28 ADT/ACK – Thêm thông tin bệnh nhân A29 ADT/ACK – Xóa thông tin bệnh nhân A32 ADT/ACK – Hủy bỏ bản theo dõi bệnh nhân chuyển viện tới A33 ADT/ACK - Hủy bỏ bản theo dõi bệnh nhân chuyển đi A38 ADT/ACK – Hủy bỏ “bản tin trước khi nhập viện” A43 ADT/ACK – Chuyển thông tin bệnh nhân khỏi danh sách bệnh nhân A44 ADT/ACK – Chuyển thông tin tài chính – số tài khoản của bệnh nhân A45 ADT/ACK – Chuyển thông tin khám bệnh – số khám bệnh A46 ADT/ACK – Thay đổi mã bệnh nhân A47 ADT/ACK – Thay đổi danh sách bệnh nhân A48 ADT/ACK - Thay đổi danh sách bệnh nhân A49 ADT/ACK – Thay đổi số tài khoản của bệnh nhân A50 ADT/ACK - Thay đổi số khám bệnh A51 ADT/ACK - Thay đổi số khám bệnh Thông tin khám lâm sàng: C01 CRM – Đăng ký bệnh nhân khám lâm sàng C02 CRM – Hủy bỏ bệnh nhân khám lâm sàng C03 CRM – Cập nhật thông tin đăng ký C04 CRM – Bệnh nhân bỏ khám lâm sàng C05 CRM – Thông tin bỏ khám lâm sàng C06 CRM – Hủy bỏ thông tin sai C09 CSU – Tự động tạo báo cáo C10 CSU – Hoàn tất khám lâm sàng C12 CSU – Cập nhật thông tin kết quả / đề nghị của bệnh nhân Bảo hiểm: I01 RQI/RPI – Yêu cầu thông tin bảo hiểm I02 RQI/RPL – Gửi / nhận danh sách hiển thị lựa chọn bệnh nhân I03 RQI/RPR - Gửi / nhận danh sách lựa chọn bệnh nhân I04 RQD/RPI – Yêu cầu dữ liệu về thân nhân bệnh nhân - 68 - I05 RQC/RCI – Yêu cầu thông tin về bệnh án của bệnh nhân I06 RQC/RCL – Gửi / nhận danh sách thông tin lâm sàng I07 PIN/ACK – Thông tin bảo hiểm I08 RQA/RPA – Thông tin cho phép điều trị I09 RQA/RPA – Hiệu chỉnh thông tin cho phép điều trị I10 RQA/RPA – Yêu cầu làm lại kế hoạch cho phép điều trị I11 RQA/RPA – Hủy bỏ kế hoạch cho phép điều trị I12 REF/RRI – Các thông tin tham khảo về bệnh nhân I13 REF/RRI – Chỉnh sửa các thông tin tham khảo về bệnh nhân I14 REF/RRI – Hủy bỏ các thông tin tham khảo về bệnh nhân I15 REF/RRI – Yêu cầu về thông tin tham khảo P01 BAR/ACK – Thêm thông tin tài khoản bệnh nhân P02 BAR/ACK - Purge patient accounts P03 DFT/ACK – Bổ xung chi tiết về thanh toán tài chính P04 QRY/DSP - Tạo hóa đơn P05 BAR/ACK – Cập nhật tài khoản Q01 QRY/DSR – Bản tin truy vấn Q02 QRY/QCK – Bản tin truy vấn Q03 DSR/ACK - Bản tin truy vấn Q06 OSQ/OSR – Truy vấn cho trường hợp được yêu cầu Q08 SPQ – Yêu cầu thủ tục lưu trữ Q09 RQQ - Sự kiện trả lời truy vấn R01 ORU/ACK – Truyền thông tin theo dõi R02 QRY – Bản tin truy vấn R03 QRY/DSR - Hiển thị hướng tới kết quả / truy vấn R04 ORF – Đáp ứng truy vấn R05 QRY/DSR – Truy vấn để hiển thị kết quả R06 UDM – Các kết quả hiển thị / cập nhật không mong muốn R09 ERP - Sự kiện xem lại thông tin trả lời truy vấn - 69 - RAR RAR – Trả lời truy vấn về thông tin dược phẩm RDR RDR - Trả lời truy vấn về thông tin phân phối dược phẩm RER RER - Trả lời truy vấn về thông tin mã hóa dược phẩm RGR RGR - Trả lời truy vấn về thông tin liều lược của dược phẩm R0R R0R – Trả lời truy vấn về đơn thuốc S01 SRM/SRR – Đặt lịch hẹn mới S02 SRM/SRR – Yêu cầu lịch hẹn S03 SRM/SRR – Điều chỉnh lịch hẹn S04 SRM/SRR – Hủy bỏ lịch hẹn S05 SRM/SRR – Tạm dừng lịch hẹn S06 SRM/SRR – Xóa lịch hẹn S07 SRM/SRR – Yêu cầu thêm các dịch vụ trong lịch hẹn S08 SRM/SRR - Yêu cầu chỉnh sửa dịch vụ trong lịch hẹn S09 SRM/SRR - Yêu cầu hủy bỏ dịch vụ trong lịch hẹn S10 SRM/SRR - Yêu cầu tạm dừng dịch vụ trong lịch hẹn S11 SRM/SRR - Yêu cầu xóa dịch vụ trong lịch hẹn S12 SIU/ACK – Thông báo mới về cuộc hẹn, phòng hẹn S13 SIU/ACK – Thông báo lịch biểu hẹn khám lại S14 SIU/ACK - Thông báo chỉnh sửa lịch biểu hẹn khám lại S15 SIU/ACK - Thông báo hủy bỏ lịch biểu hẹn khám lại S16 SIU/ACK - Thông báo tạm dừng lịch biểu hẹn khám lại S17 SIU/ACK - Thông báo xóa lịch biểu hẹn khám lại S18 SIU/ACK - Thông báo bổ xung dịch vụ trong lịch hẹn S19 SIU/ACK - Thông báo hiệu chỉnh thông tin bổ xung dịch vụ trong lịch hẹn S20 SIU/ACK - Thông báo hủy bỏ bổ xung dịch vụ trong lịch hẹn S21 SIU/ACK - Thông báo tạm dừng bổ xung dịch vụ trong lịch hẹn S22 SIU/ACK - Thông báo xóa thông tin bổ xung dịch vụ trong lịch hẹn T01 MDM/ACK – Chứng từ gốc T02 MDM/ACK – Chi tiết chứng từ gốc - 70 - T03 MDM/ACK – Thông báo thay đổi tình trạng hồ sơ T04 MDM/ACK - Thông báo thay đổi tình trạng hồ sơ và nội dung T05 MDM/ACK – Thông báo phụ lục hồ sơ T06 MDM/ACK - Thông báo phụ lục Hồ sơ và nội dung T07 MDM/ACK - Thông báo chỉnh sửa hồ sơ T08 MDM/ACK – Nội dung và thông báo chỉnh sửa hồ sơ T09 MDM/ACK – Thông báo thay thế hồ sơ T10 MDM/ACK – Nội dung và thông báo thay thế hồ sơ T11 MDM/ACK – Thông báo hủy bỏ hồ sơ T12 QRY/DOC – Truy vấn (tìm kiếm) hồ sơ V01 VXQ – Truy vấn (tìm kiếm) báo cáo về tiêm chủng V02 VXX – Trả lời truy vấn tiêm chủng V03 VXR – Trả lời báo cáo tiêm chủng V04 VXU – Cập nhật báo cáo tiêm chủng - 71 - Bảng 2. BỘ KÝ HIỆU CÁC ĐOẠN TRONG CẤU TRÚC BẢN TIN HL7 ADD – Thông tin bổ xung AIG – Thông tin bổ xung AIL – Thông tin bổ xung – địa điểm AIP - Thông tin bổ xung – con người AIS - Thông tin bổ xung – thiết bị AL1 – Thông tin dị ứng thuốc của bệnh nhân ARQ – Yêu cầu bổ xung AUT – Thông tin cho phép / được cấp phép BLG- Thanh toán CSR – Đăng ký nghiên cứu lâm sàng CTI – Các định nghĩa khám bệnh lâm sàng CTD – Thông tin liên hệ DB1 – Thông tin bệnh tật DG1 – Thông tin chẩn đoán DRG – Nhóm thông tin có quan hệ với chẩn đoán bệnh DSC – Thông tin thêm DSP – Dữ liệu hiển thị EQL – Ngôn ngữ truy vấn được nhúng ERQ – Truy vấn sự kiện ERR – Thông báo lỗi EVN – Loại sự kiện FT1 – Giao dịch tài chính GT1 – Người bảo lãnh IN1 – Bảo hiểm IN2 – Thông tin thêm về bảo hiểm IN3 – Giấy chứng nhận bảo hiểm MSH – Đoạn header của bản tin NK1 – Thông tin về quan hệ họ hàng (thân nhân bệnh nhân) - 72 - NPU – Cập nhật tình trạng giường bệnh NTE – Các chú ý và chỉ dẫn OBR – Yêu cầu theo dõi bệnh nhân OBX – Kết quả theo dõi ODS – Yêu cầu về chế độ ăn của bệnh nhân ODT- Các thông tin hướng dẫn về chế độ cho bệnh nhân OM1 – Thông tin theo dõi chung OM2 – Thông tin theo dõi bệnh nhân (tiếp) OM4 – Theo dõi mẫu xét nghiệm yêu cầu ORC – Các yêu cầu khác PCR – Các mối quan hệ khác PD1 – Các mối quan hệ khác về thân nhân của bệnh nhân PID – Thông tin bệnh nhân PR1 – Quy trình PRA – Thông tin về bác sỹ PRC – Thông tin giá cả PRD – Dữ liệu nhà cung cấp PV1 – Thông tin khám bệnh của bệnh nhân PV2 – Thông tin thêm về khám bệnh của bệnh nhân QRD – Định nghĩa các truy vấn RF1 – Thông tin tham chiếu RXA – Quản lý dược RXC – Các thành phần thuốc RXD- Phân phát thuốc RXE- Mã hóa thuốc RXG – Cấp thuốc RXO – Đơn thuốc đề nghị RXR – Chuyển thuốc STF – Nhận dạng nhân viên - 73 - - 74 - Bảng 3. Các kiểu dữ liệu dùng trong bản tin HL7 Data Type Category/ Data type Data Type Name Notes/Format Alphanumeric ST String TX Text data FT Formatted text Numerical CQ Composite quantity with units ^ MO Money ^ NM Numeric SI Sequence ID SN Structured numeric ^ ^ ^ Identifier ID Coded values for HL7 tables IS Coded value for user-defined tables VID Version identifier ^ ^ <international version ID (CE) HD Hierarchic designator ^ ^ Used only as part of EI and other data types. EI Entity identifier ^ ^ ^ RP Reference pointer ^ ^ ^ <subtype (ID)> PL Person location ^ ^ ^ ^ < location status (IS )> ^ ^ ^ ^ PT Processing type ^ Date/Time DT Date YYYY[MM[DD]] TM Time HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ] TS Time stamp YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] ^ Code Values CE Coded element ^ ^ ^ ^ ^ <name of alternate coding system (ST)> CNE Coded with no exceptions ^ ^ ^ ^ ^ <name of alternate coding system (ST)> ^ ^ alternate coding system version ID (ST)> ^ CWE Coded with exceptions ^ ^ ^ ^ ^ <name of alternate coding system (ST)> ^ ^ alternate coding system version ID (ST)> ^ CF Coded element with formatted values ^ ^ ^ ^ ^ <name of alternate coding system (ST)> CK Composite ID with check digit ^ ^ <code identifying the check digit scheme employed (ID)> ^ CN Composite ID number and name ^ ^ ^ <middle initial or name (ST)> ^ ^ <prefix (e.g., DR) (ST)> ^ ^ ^ <assigning authority (HD)> CX Extended composite ^ ^ <code identifying the check digit scheme - 75 - ID with check digit employed (ID)> ^ ^ ^ < assigning facility (HD) XCN Extended composite ID number and name In Version 2.3, use instead of the CN data type. ^ & ^ ^ ^ <prefix (e.g., DR) (ST)> ^ ^ ^ ^ ^ <identifier check digit (ST)> ^ ^ ^ ^ <name representation code (ID)> Generic CM Composite No new CM’s are allowed after HL7 Version 2.2. Hence there are no new CM’s in Version 2.3. Demographics AD Address ^ ^ ^ <state or province (ST)> ^ ^ ^ <address type (ID)> ^ PN Person name ^ ^ ^ ^ ^ <degree (e.g., MD) (ST)> TN Telephone number [NN] [(999)]999-9999[X99999][B99999][C any text] XAD Extended address In Version 2.3, replaces the AD data type. ^ <other designation (ST)> ^ ^ ^ <zip or postal code (ST)> ^ ^ ^ <other geographic designation (ST)> ^ ^ ^ XPN Extended person name In Version 2.3, replaces the PN data type. ^ <given name (ST)> & ^ ^ ^ ^ <degree (e.g., MD) (IS)> ^ ^ XON Extended composite name and ID number for organizations ^ ^ <ID number (NM)> ^ ^ <code identifying the check digit scheme employed (ID)> ^ ^ <identifier type code (IS)> ^ ^ <name representation code (ID)> XTN Extended telecommunications number In Version 2.3, replaces the TN data type. [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ ^ ^ ^ ^ ^ ^ ^ Specialty/Chapter Specific Waveform CD Channel definition For waveform data only, see Chapter 7, Section 7.15.3. <channel identifier (*)> ^ & ^ ^ ^ <calibration parameters (*)> ^ ^ <minimum/maximum data values (*)> MA Multiplexed array For waveform data only, see Chapter 7, Section 7.15.2. <sample 1 from channel 1 (NM)> ^ ^ <sample 1 from channel 3 (NM)> ...~ ^ <sample 2 from channel 2 (NM)> ^ ...~ NA Numeric array For waveform data only, see Chapter 7, Section 7.15.1. ^ ^ ^ ^ ... ED Encapsulated data Supports ASCII MIME-encoding of binary data. <source application (HD) > ^ ^ ^ ^ <data (ST)> Price Data CP Composite price In Version 2.3, replaces the MO data type. ^ <price type (ID)> ^ ^ ^ ^ Patient Administration /Financial Information FC Financial class ^ - 76 - Extended Queries QSC Query selection criteria ^ ^ ^ QIP Query input parameter list ^ RCD Row column definition ^ ^ <maximum column width (NM)> Master Files DLN Driver’s license number ^ ^ <expiration date (DT) JCC Job code/class ^ VH Visiting hours ^ ^ ^ Medical Records/Information Management PPN Performing person time stamp ^ ^ & ^ ^ ^ <suffix (e.g., JR or III) (ST)> ^ ^ ^ <source table (IS)> ^ ^ ^ ^ <code identifying the check digit scheme employed (ID )> ^ ^ ^ ^ Time Series: DR Date/time range Scheduling Chapter Only: ^ RI Repeat interval Scheduling Chapter Only: ^ SCV Scheduling class value pair Scheduling Chapter Only: ^ TQ Timing/quantity For timing/quantity specifications for orders, see Chapter 4, Section 4.4. ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ <performance duration (CE)> ^