TỔNG QUAN
TỔNG QUAN BỆNH ÁN ĐIỆN TỬ
Sự bùng nổ công nghệ thông tin trong những năm gần đây đã ảnh hưởng mạnh mẽ đến lĩnh vực y tế, đặc biệt là trong việc quản lý hồ sơ y lý Nhiều cơ sở y tế trên toàn quốc đã bắt đầu áp dụng bệnh án điện tử, mang lại lợi ích cho nhân viên y tế trong việc ghi chép hồ sơ, đồng thời tăng tính minh bạch cho bệnh nhân Việc này cũng hỗ trợ hiệu quả trong công tác kê đơn, cấp phát thuốc, thống kê, sao lục bệnh án, và thanh quyết toán viện phí.
Bệnh án điện tử hiện nay chủ yếu chỉ áp dụng ở quy mô nhỏ như phòng khám và quầy thuốc, với rất ít cơ sở y tế triển khai trên quy mô tổng thể của bệnh viện hoặc liên viện Mặc dù có một số kết quả tích cực, bệnh án điện tử vẫn chưa được phát triển rộng rãi để phục vụ lợi ích cộng đồng Trong tương lai, hy vọng rằng các bệnh viện tại Việt Nam sẽ sử dụng 100% bệnh án điện tử đạt chuẩn quốc tế, từ đó nâng cao chất lượng khám chữa bệnh và mang lại lợi ích toàn cầu cho người bệnh.
Vậy, bệnh án điện tử là gì? Lịch sử và lợi ích của nó mang lại cho cộng đồng ra sao?
Bệnh án điện tử mang nhiều ý nghĩa khác nhau và đã ghi nhận nhiều lợi ích ban đầu trong việc truyền tải dấu hiệu sinh tồn lên các nền tảng lưu trữ thông tin sức khỏe như Google Health và Microsoft Health Vault Tuy nhiên, thuật ngữ "bệnh án điện tử" cũng gây ra nhiều tranh cãi, dẫn đến việc các chuyên gia trong lĩnh vực này sử dụng các tên gọi khác như diễn đàn sức khỏe cá nhân, trình ứng dụng sức khỏe cá nhân, và hệ thống hồ sơ sức khỏe có sự kiểm soát cá nhân.
Bệnh án điện tử là một nền tảng kết nối dữ liệu người bệnh từ nhiều nguồn khác nhau, nhằm cung cấp thông tin giúp bệnh nhân hiểu rõ và cải thiện sức khỏe của mình Đồng thời, nó hỗ trợ bác sĩ trong việc theo dõi thông tin bệnh nhân một cách nhanh chóng và tham khảo lịch sử chẩn đoán, điều trị từ các bác sĩ khác để đưa ra quyết định chính xác Hơn nữa, bệnh án điện tử còn giúp truy cứu trách nhiệm khi phát sinh vấn đề liên quan đến quá trình điều trị.
Bệnh án điện tử là hệ thống lưu trữ và quản lý thông tin khám chữa bệnh của bệnh nhân từ khi sinh ra cho đến khi qua đời Hệ thống này không chỉ giúp bác sĩ mà còn hỗ trợ bệnh nhân trong việc chủ động bảo vệ sức khỏe và thực hiện chẩn đoán, điều trị mọi lúc, mọi nơi.
1.1.2 Lịch sử phát triển và lợi ích
Nhu cầu kết nối dữ liệu bệnh nhân từ nhiều nguồn và phát triển các ứng dụng hỗ trợ người bệnh hiểu rõ và cải thiện sức khỏe đã thúc đẩy sự hình thành một diễn đàn chuyên biệt Mặc dù chưa có định nghĩa rõ ràng về bệnh án điện tử, nhưng nhiều tính năng và chức năng của nó đã xuất hiện, biến bệnh án điện tử thành công cụ quan trọng giúp người bệnh tham gia và quyết định về sức khỏe của chính mình.
Bệnh án hay hồ sơ y khoa có lịch sử lâu đời, gắn liền với việc chữa bệnh và thực hành y khoa Ban đầu, bệnh án được thiết lập và duy trì dưới dạng giấy bởi các bác sĩ, nhằm phục vụ nhu cầu của nhà cung cấp dịch vụ y tế dựa trên thông tin mà họ cho là quan trọng cho quy trình lâm sàng, như lịch sử bệnh, tình trạng bệnh lý và việc sử dụng thuốc Vào cuối những năm 1990 và đầu những năm 2000, với sự phát triển của khoa học máy tính, nhiều nhà cung cấp dịch vụ y tế đã chuyển đổi từ bệnh án giấy sang hồ sơ y khoa điện tử (EMRs).
Hồ sơ y khoa điện tử là phiên bản số hóa của bệnh án giấy, được tạo ra bởi bác sỹ, điều dưỡng và nhân viên bệnh viện Quan trọng hơn, hồ sơ này cho phép người bệnh dễ dàng truy cập thông tin sức khỏe của mình qua các cổng website trực tuyến Những cổng này, mặc dù có những giới hạn, đã mở ra cơ hội cho người bệnh tham gia vào việc quản lý hồ sơ y tế cá nhân Thông qua việc truy cập dữ liệu, người bệnh nhận thấy lợi ích từ việc hiểu biết thông tin trong bệnh án, từ đó góp phần vào các quyết định chăm sóc sức khỏe của bác sỹ.
Sự chuyển đổi từ bệnh án giấy sang bệnh án điện tử không phải là động lực duy nhất cho sự phát triển của hệ thống này Người bệnh đang yêu cầu quyền truy cập và kiểm tra thông tin sức khỏe một cách đơn giản và nhanh chóng Ở những nơi mà hệ thống y tế hoạt động chậm chạp, các thiết bị điện tử sẽ ra đời để phục vụ nhóm "bệnh nhân-khách hàng" mới, những người muốn theo dõi thông tin sức khỏe cá nhân như mức đường huyết, khẩu phần ăn và thói quen tập luyện Thế hệ bệnh án điện tử đầu tiên chưa thu hút được sự quan tâm rộng rãi do sự tương tác hạn chế với các hệ thống y tế và thị trường khách hàng còn nhỏ Tuy nhiên, mong muốn có những thiết bị và ứng dụng giúp người bệnh dễ dàng tiếp cận thông tin sức khỏe đã đóng vai trò quan trọng trong sự tiến triển của bệnh án điện tử.
Những tiến bộ trong hệ thống cung ứng dịch vụ sức khỏe và nhu cầu ngày càng cao của bệnh nhân về việc nắm giữ hồ sơ sức khỏe cá nhân đã dẫn đến sự phát triển đồng thời của bệnh án điện tử tại các cơ sở y tế và bệnh án điện tử độc lập Sự phát triển này đã tạo ra một số chủ đề chung, trong đó có sự thỏa thuận về những tính chất, chức năng và giới hạn cơ bản của bệnh án điện tử Một trong những tính chất nổi bật của bệnh án điện tử là việc đặt người bệnh ở vị trí trung tâm, cho phép họ truy cập vào thông tin sức khỏe của mình Trong khi bác sĩ vẫn là người viết toa thuốc và chỉ định xét nghiệm, bệnh án điện tử giúp giảm thiểu sự mất cân đối thông tin giữa bác sĩ và bệnh nhân Với kiến thức về dữ liệu cá nhân, bệnh nhân có thể trở thành người quản lý chủ động, đồng chủ sở hữu sức khỏe của mình Bệnh án điện tử không chỉ biến bệnh nhân thành người sở hữu dữ liệu sức khỏe mà còn trao quyền cho họ trong việc quản lý dịch vụ chăm sóc sức khỏe, đánh dấu sự chuyển biến từ việc giao phó hoàn toàn cho bác sĩ sang việc chia sẻ trách nhiệm chăm sóc sức khỏe.
Khi bệnh án điện tử ra đời, nhiều phiên bản khác nhau đã xuất hiện để đáp ứng nhu cầu đa dạng của bệnh nhân Phiên bản tiên tiến cho phép người bệnh truy cập hồ sơ sức khỏe, tương tác với bác sĩ và quản lý việc dùng thuốc Các phiên bản đầu tiên còn cho phép bệnh nhân nhập và tra cứu số liệu cholesterol, nhận thông báo về kỹ thuật tầm soát bệnh và ghi chép nhật ký cơn đau hay trạng thái tâm lý Tuy nhiên, những hạn chế của thế hệ đầu tiên ngày càng rõ ràng, chủ yếu do thiếu sự hỗ trợ liên tục từ bác sĩ, khiến các ứng dụng này không thể cung cấp tiện ích tức thì cho bệnh nhân Dù bệnh nhân có thể nhập liệu thông tin sức khỏe của mình, nhưng việc thiếu kết nối với nhà cung cấp dịch vụ y tế đã hạn chế hiệu quả của bệnh án điện tử.
Bệnh án điện tử, mặc dù được tích hợp với hệ thống cung cấp dịch vụ sức khỏe, vẫn có những giới hạn đáng kể Người bệnh có thể truy cập hồ sơ sức khỏe của mình qua cổng website hoặc ứng dụng nhắn tin an toàn, nhưng giá trị của bệnh án điện tử chỉ được phát huy khi thông tin được theo dõi xuyên suốt trong tất cả các dịch vụ y tế mà họ sử dụng Ví dụ, một bệnh nhân tiểu đường không thể tận dụng hiệu quả kho công nghệ thông tin nếu không có sự kết nối liên tục với nhà thuốc và các nhà cung cấp dịch vụ khác Thực tế, một bệnh nhân có thể sở hữu nhiều bệnh án điện tử mà không có sự tương tác giữa chúng, tạo ra sự phức tạp trong quản lý thông tin sức khỏe Để phát huy tối đa tiềm năng, các hệ thống bệnh án điện tử cần có khả năng trao đổi thông tin hai chiều và kết nối với nhiều nguồn dữ liệu sức khỏe khác nhau trong hệ thống chăm sóc sức khỏe hiện tại.
Các chính sách chia sẻ thông tin điện tử đã nhấn mạnh sự phát triển ấn tượng của bệnh án điện tử trong 10 năm qua Những báo cáo này chỉ ra những thỏa thuận thực hành về chức năng và giới hạn của bệnh án điện tử, đặc biệt trong bối cảnh các thỏa thuận này đang được xây dựng Mặc dù bệnh án điện tử đã thay đổi nhanh chóng, việc phác thảo một bức tranh hoàn hảo về sự phát triển của nó vẫn gặp khó khăn, đồng thời cho thấy rằng quá trình chuyển đổi này vẫn còn nhiều điều cần hoàn thiện.
Một trong những thách thức lớn của bệnh án điện tử là việc xử lý thông tin có thể dẫn đến kiện tụng, khi phải đối mặt với khối lượng dữ liệu lộn xộn trong các tệp tin điện tử Bệnh án điện tử không chỉ cần thu thập và lưu trữ dữ liệu, mà còn phải đồng bộ với các công cụ phức tạp để tổ chức thông tin, phát hiện xu hướng và cung cấp phản hồi hữu ích.
Tầm nhìn của bệnh án điện tử là đảm bảo mỗi bệnh nhân có quyền truy cập an toàn vào thông tin sức khỏe của mình, kèm theo các công cụ đơn giản để dễ dàng đọc và xử lý thông tin, từ đó nâng cao chất lượng cuộc sống Mục tiêu là cải thiện dịch vụ y tế và sức khỏe toàn cầu Tuy nhiên, việc hiện thực hóa tầm nhìn này đang gặp nhiều thách thức và trở ngại từ nhiều phía.
TỔNG QUAN CÁC CHUẨN DỮ LIỆU TRONG Y TẾ
Hiện nay, sự phát triển mạnh mẽ của công nghệ thông tin và chăm sóc sức khỏe đã dẫn đến việc chuẩn hóa dữ liệu y tế với nhiều chuẩn khác nhau Các chuẩn như DICOM giúp chuẩn hóa hình ảnh, HL7 phục vụ cho chuẩn hóa bản tin chăm sóc sức khỏe, cùng với các chuẩn khác như E2184-02 và E1384-02 (EHR) Bài viết này sẽ cung cấp cái nhìn tổng quan về các chuẩn dữ liệu trong y tế.
1.2.1Tổng quan chuẩn dữ liệu DICOM 1.2.1.1 Khái niệm
DICOM (Digital Imaging and Communications in Medicine) is a standardized protocol for transmitting medical imaging data, ensuring seamless communication between various devices regardless of the manufacturer.
1.2.1.2 Lịch sử phát triển của DICOM
Với sự phát triển của CT (computed tomography) và các phương pháp hình ảnh chẩn đoán số trong thập niên 70, nhu cầu sử dụng máy tính trong ứng dụng lâm sàng gia tăng Hiệp hội Radiology tại Mỹ (ACR) và Hiệp hội các nhà sản xuất điện quốc gia (NEMA) nhận thấy cần thiết phải có một phương thức chuẩn để truyền tải hình ảnh và thông tin liên quan giữa các thiết bị của các nhà cung cấp khác nhau, do các thiết bị này sản xuất ra các định dạng ảnh số khác nhau.
Trường đại học Radiology tại Mỹ (ACR) và National Electrical Manufacturers Association (NEMA) thiết lập một hội đồng về lĩnh vực này vào năm 1983 để phát triển chuẩn nhằm:
Phát triển sự truyền đạt thông tin ảnh số (digital image information) mà không cần quan tâm đến nhà sản xuất thiết bị
Tạo điều kiện thuận lợi cho việc phát triển và mở rộng hệ thống lưu trữ hình ảnh cũng như các hệ thống truyền thông PACS, đồng thời đảm bảo khả năng tương tác hiệu quả với các hệ thống thông tin khác trong bệnh viện.
Cho phép xây dựng các cơ sở dữ liệu thông tin chẩn đoán có thể được truy cập từ nhiều thiết bị khác nhau trên quy mô rộng, bao gồm cả khía cạnh địa lý.
Chuẩn ACR-NEMA số 300-1985, được công bố vào năm 1985, đã được định nghĩa trong phiên bản 1.0 Chuẩn này đã trải qua hai lần hiệu chỉnh, với ấn bản 1 phát hành vào tháng 10 năm 1986 và ấn bản 2 phát hành vào tháng 1 năm sau đó.
Các chuẩn ACR-NEMA số 300-1988 được công bố vào 1988 được định rõ trong phiên bản 2.0 Nó bao gồm cả phiên bản 1.0, công bố bản hiệu chỉnh
Bài viết đã cập nhật các tài liệu mới, cung cấp lệnh hỗ trợ cho thiết bị trình bày, giới thiệu hệ thống phân tầng mới để nhận dạng hình ảnh, và bổ sung các yếu tố dữ liệu nhằm tăng cường đặc trưng trong việc mô tả hình ảnh.
Các công bố chuẩn (Standards Publications) được thiết lập trên ổ cứng, bao gồm tập hợp các lệnh phần mềm tối thiểu và bộ định dạng dữ liệu nhất quán.
DICOM, được ra đời từ những năm 70, đã sớm được công nhận tầm quan trọng và trải qua một quá trình phát triển lịch sử lâu dài trên toàn cầu.
Hầu hết các thiết bị chẩn đoán hình ảnh hiện nay đều sử dụng chuẩn DICOM, nhưng việc tìm hiểu về nó vẫn còn mới mẻ ở Việt Nam Mục tiêu không chỉ dừng lại ở việc hiểu và áp dụng DICOM một cách hiệu quả, mà còn cần phát triển và tích hợp nó vào các hệ thống tiên tiến, phù hợp với nhu cầu thực tiễn của đất nước.
Chuẩn DICOM đang trở thành một vấn đề quan trọng trong lĩnh vực y tế toàn cầu, thể hiện sự phát triển và hội nhập của công nghệ y tế trên thế giới.
1.2.1.4Mục đích của chuẩn DICOM
Chuẩn DICOM làm cho các thiết bị đòi hỏi quy chuẩn tương tác dễ dàng
Các thiết bị tương tác cần tuân thủ các chuẩn để kết hợp lệnh và dữ liệu, đảm bảo không chỉ thông tin mà còn khả năng truyền tải giữa các thiết bị.
Gửi các ngữ nghĩa của dịch vụ tập tin, định dạng ảnh và thư mục thông tin là cần thiết cho việc giao tiếp độc lập hiệu quả.
Trong việc xác định các yêu cầu quy chuẩn cho các hình thức thực thi, một phát biểu quy chuẩn (Conformance Statement) cần cung cấp thông tin đầy đủ để xác định các hàm tương tác dự kiến với các thiết bị khác có yêu cầu quy chuẩn.
Hoạt động dễ dàng trong môi trường mạng
Cấu trúc này giúp giới thiệu các dịch vụ mới, từ đó hỗ trợ hiệu quả cho các ứng dụng ảnh y khoa trong tương lai.
1.2.2Tổng quan chuẩn dữ liệu HL7 1.2.2.1 Khái niệm
TỔNG QUAN THỰC TRẠNG BỆNH ÁN ĐIỆN TỬ TẠI VIỆT
Hiện nay, Việt Nam có hơn 1,500 cơ sở y tế, trong đó hầu hết các bệnh viện đã áp dụng công nghệ thông tin (CNTT) để cải thiện quy trình làm việc Các bệnh viện thường hợp tác với các đơn vị cung cấp phần mềm để triển khai hệ thống CNTT riêng, nhưng vẫn chủ yếu sử dụng các phần mềm độc lập theo từng phòng ban mà không có sự đồng nhất Mặc dù bệnh án điện tử đã được triển khai, nhưng chúng thường được thiết kế riêng theo yêu cầu của từng bác sĩ và bệnh viện, dẫn đến việc thông tin không thể chia sẻ giữa các cơ sở y tế Khi bệnh nhân chuyển viện, toàn bộ quy trình khám chữa bệnh phải thực hiện lại từ đầu, gây khó khăn và tiềm ẩn nguy cơ trong trường hợp cấp cứu, khi thông tin như nhóm máu không được lưu trữ kịp thời, ảnh hưởng đến việc điều trị khẩn cấp.
Chưa có đơn vị nào cung cấp bệnh án điện tử đầy đủ và chuẩn hóa theo tiêu chuẩn quốc tế, điều này gây khó khăn cho bệnh nhân trong việc quản lý chi phí khám chữa bệnh Việc triển khai hệ thống bệnh án điện tử chuẩn hóa sẽ mang lại lợi ích thiết thực cho bệnh nhân và cộng đồng, đồng thời thúc đẩy sự phát triển của ngành y tế toàn cầu.
TỔNG QUAN MÔ HÌNH TRIỂN KHAI CÁC CHUẨN DỮ LIỆU Y TẾ
Hiện nay, việc triển khai các chuẩn dữ liệu y tế tại Việt Nam còn nhiều hạn chế, thiếu sự đầu tư bài bản và khoa học để xây dựng hệ thống theo tiêu chuẩn y tế toàn cầu Các đơn vị y tế thường sử dụng phần mềm riêng lẻ, được phát triển theo hợp đồng với các công ty phần mềm, dẫn đến sự không đồng nhất trong quản lý thông tin bệnh nhân Ví dụ, có nơi giới hạn tên bệnh nhân chỉ 50 ký tự, trong khi nơi khác cho phép lên đến 2000 ký tự Thực trạng này phản ánh sự thiếu nhất quán trong toàn bộ hệ thống y tế.
Gần đây, Bộ Y Tế đã ban hành các thông tư yêu cầu áp dụng chuẩn y tế quốc tế vào hệ thống bệnh viện trên toàn quốc Tuy nhiên, việc triển khai vẫn chưa đạt được thành công như mong đợi Một số đơn vị độc lập đã thực hiện nhưng chỉ ở quy mô nhỏ lẻ, chưa áp dụng toàn diện vào quản lý bệnh viện và quản lý bệnh nhân.
Vì lý do đó, việc xây dựng một hệ thống bệnh án điện tử chuẩn mực, sử dụng đồng bộ trên toàn quốc và có khả năng giao tiếp với các cơ sở y tế quốc tế là rất cần thiết và cần được triển khai ngay lập tức.
CÁC CHUẨN TRAO ĐỔI DỮ LIỆU Y TẾ
CHUẨN DỮ LIỆU DICOM
Vào năm 1983, ACR (American College of Radiology) và NEMA (National Electrical Manufacturers Association) đã thành lập một ủy ban nhằm tạo ra một cấu trúc mở cho phép các thiết bị tạo ảnh từ các nhà sản xuất khác nhau kết nối và chia sẻ thông tin trong môi trường y tế, đặc biệt là trong hệ thống PACS Mục tiêu của ủy ban này là thống nhất và xây dựng một chuẩn riêng cho việc lưu trữ và trao đổi hình ảnh.
Phiên bản đầu tiên là chuẩn ACR-NEMA được công bố năm 1985 xác định việc truyền bản tin từ điểm tới điểm, xác định khuôn dạng dữ liệu
Phiên bản thứ hai của DICOM ra đời vào năm 1988, bổ sung thêm định nghĩa về phần cứng, giao thức phần mềm và từ điển dữ liệu chuẩn Tuy nhiên, vấn đề kết nối mạng vẫn chưa được giải quyết rõ ràng trong hai phiên bản trước Do đó, phiên bản thứ ba được phát triển và chính thức mang tên DICOM, viết tắt của Digital Imaging and Communication in Medicine.
Chuẩn DICOM là tiêu chuẩn quy định định dạng và trao đổi hình ảnh y tế cùng các thông tin liên quan, tạo ra một "ngôn ngữ" chung cho phép các thiết bị và hệ thống trong mạng thông tin y tế giao tiếp hiệu quả với nhau.
Chuẩn DICOM ra đời có ý nghĩa quan trọng trong việc bắt tay, lưu trữ, in ấn và thu nhận hình ảnh y tế Tiêu chuẩn này định nghĩa cấu trúc tập tin và giao thức truyền thông thông tin, sử dụng nền tảng TCP/IP, cho phép các tập tin DICOM trao đổi lẫn nhau giữa các hệ thống Hiện nay, chuẩn DICOM đã phát triển ổn định và được hầu hết các công ty sản xuất thiết bị tạo ảnh y khoa hỗ trợ, do đó, các hệ thống PACS cần tuân thủ chuẩn này.
2.1.1 Phạm vi và trường ứng dụng của DICOM
Chuẩn DICOM định ra sự trao đổi thông tin giữa các thiết bị tạo ảnh và hệ thống mạng thông tin Chuẩn DICOM có mục đích:
(1) Định ra bộ giao thức ứng dụng trong truyền tin qua mạng (mà các thiết bịphải tuân theo)
(2) Định ra cú pháp và ngữ nghĩa của lệnh; các thông tin liên quan được trao đổisử dụng các giao thức này
Để cải thiện khả năng truy cập thông tin lưu trữ, cần thiết lập các dịch vụ lưu trữ trung gian, xác định khuôn dạng file và cấu trúc thư mục y tế Những biện pháp này sẽ tạo điều kiện thuận lợi cho việc truyền tải thông tin qua các phương tiện trung gian.
(4) Định ra thông tin nào được sử dụng chuẩn Tuy nhiên chuẩn này lại không quy định mức độ thích nghingoại trừ một sốphần dành riêng cho việc này
2.1.2 Trao đổi thông tin trong DICOM
Tiêu chuẩn DICOM 3.0 bao gồm hai lớp thông tin chính: lớp đối tượng và lớp dịch vụ Lớp đối tượng xác định các thành phần như bệnh nhân, thiết bị hình ảnh và thông tin xét nghiệm, trong khi lớp dịch vụ quy định các chức năng như lưu trữ, in ấn, chất vấn và truy vấn Mỗi lớp đều đi kèm với một từ điển để định nghĩa các thuộc tính, nhằm đảm bảo việc mã hóa dữ liệu một cách chính xác.
Các lớp đối tượng DICOM được chia thành lớp tiêu chuẩn và lớp tổ hợp Mỗi lớp tiêu chuẩn chứa các đặc tính cơ bản của thực thể trong thế giới thực.
Thông tin ngày xét nghiệm và thời điểm tạo ảnh là đặc tính quan trọng của lớp xét nghiệm, trong khi thông tin tên bệnh nhân là đặc tính của lớp bệnh nhân Việc sử dụng các lớp đối tượng giúp cải thiện độ chính xác và hiệu quả trong xử lý ảnh y tế Do đó, chuẩn DICOM 3.0 đã định nghĩa các lớp đối tượng một cách rất rõ ràng.
Lớp tổ hợp được định nghĩa bởi ACR-NEMA từ thông tin tổ hợp của các thiết bị ảnh khác nhau DICOM 3.0, là phiên bản phát triển từ tiêu chuẩn ACR-NEMA, cần thích ứng với chuẩn này, do đó vẫn bao hàm các lớp tổ hợp Tuy nhiên, cần lưu ý rằng định nghĩa lớp tổ hợp không hoàn toàn chính xác như lớp tiêu chuẩn.
Bảng 2-1 Bảng các lớp đối tượng DICOM
Bệnh nhân Xét nghiệm Nguồn lưu trữ Chú giải ảnh
Lớp tổ hợp Ảnh CR Ảnh CT Ảnh số hóa Film Ảnh MR Ảnh y học hạt nhân Đồ họa Đồ hình
Dịch vụ DICOM được sử dụng để truyền tải dữ liệu giữa các thiết bị y tế, cho phép các thiết bị thực hiện các chức năng như lưu trữ và hiển thị hình ảnh y khoa.
Bảng 2-2 Bảng các lớp dịch vụ
Lớp dịch vụ Miêu tả
Dịch vụ lưu trữ ảnh cung cấp khả năng lưu trữ các tập dữ liệu hiệu quả Bên cạnh đó, dịch vụ chất vấn cho phép người dùng truy cập và tìm kiếm thông tin từ các tập dữ liệu Cuối cùng, việc truy vấn ảnh giúp người dùng dễ dàng tìm kiếm hình ảnh từ thiết bị hiển thị của họ.
In ảnh Cung cấp in ấn ảnh
Xét nghiệm Cung cấp việc quản lý xét nghiệm
DIMSE là một lớp dịch vụ được xây dựng trên các phần tử dịch vụ truyền thông DICOM, với hai loại DIMSE: một cho đối tượng tổ hợp và một cho đối tượng tiêu chuẩn Mỗi DIMSE tổ hợp kết nối một thiết bị gửi yêu cầu với một thiết bị nhận yêu cầu đó Trong môi trường hướng đối tượng, dịch vụ DICOM được xem như các lớp dịch vụ, trong đó thiết bị cung cấp dịch vụ được gọi là SCP (Service Class Provider) và thiết bị sử dụng dịch vụ là SCU (Service Class User) Ví dụ, đĩa từ hoạt động như SCP để lưu trữ dữ liệu cho PACS controller, trong khi CT scanner là SCU khi gửi ảnh đến đĩa từ Một thiết bị cũng có thể vừa là SCP vừa là SCU, như trường hợp PACS controller gửi ảnh đến trạm hiển thị (SCU) và nhận ảnh từ các máy scanner (SCP).
Bảng 2-3 Bảng DIMSE tổ hợp
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 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ị, cần có giao thức truyền DICOM áp dụng các chuẩn của mạng thông tin hiện tại theo mô hình 7 lớp OSI Chẳng hạn, để truyền ảnh từ máy CT scanner tới trạm hiển thị qua giao thức DICOM, quá trình sẽ trải qua nhiều bước cụ thể.
- 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-1 Quá trình truyền ảnh từ CT scanner tới trạm hiển thị
CHUẨN DỮ LIỆU HL7
Trong phiên bản 2.3.1, tổ chức HL7 đã xác định 92 loại bản tin và hơn 300 loại sự kiện Mỗi bản tin bao gồm các đoạn bản tin hoặc nhóm đoạn bản tin, trong đó mỗi đoạn bản tin được cấu thành từ nhiều trường khác nhau Dưới đây là chi tiết về các thành phần trong phiên bản 2.3.1.
2.2.1 Nguyên tắc mã hóa trong HL7 2.2.1.1 Nguyên tắc
Bản tin theo quy định của HL7 được cấu trúc từ các trường dữ liệu có độ dài thay đổi, được phân cách bởi ký tự ngăn cách Nguyên tắc mã hóa cho từng kiểu dữ liệu trong các trường được quy định riêng biệt Các trường dữ liệu được tổ chức thành các nhóm logic gọi là đoạn, được phân tách bởi ký tự phân đoạn Mỗi đoạn bắt đầu bằng một mã 3 ký tự, giúp nhận diện trong bản tin Các đoạn có thể được xác định là yêu cầu hoặc tùy chọn và có khả năng lặp lại Vị trí của các trường dữ liệu trong các đoạn kết hợp giúp xác định chúng trong bản tin.
Tất cả dữ liệu được biểu diễn như các ký tự hiển thị từ một ký tự đã chọn.Bộ kýtự hiển thị mã ASCII (American Standard Code for
Ký tự mặc định trong Information Interchange là bộ ký tự được sử dụng trừ khi có thay đổi trong tiêu đề MSH (Message Header Segment) Ký tự ngăn cách trường cần được chọn từ cài đặt ký tự hiển thị mã ASCII, trong khi tất cả các dấu ngăn cách và ký tự đặc biệt khác cũng thuộc loại ký tự hiển thị, ngoại trừ ký tự phân đoạn, là ký tự mã ASCII Carriage Return (ký tự xuống dòng).
2.2.1.2 Ví dụ về mã hóa và giải mã một bản tin HL7 Để hiểu hơn về cấu trúc của một bản tin HL7, chúng ta nghiên cứu một bản tin HL7 điển hình như việc 1 bệnh nhân nhập viện sẽ bao gồm các đoạn thông tin chính sau:
Bản tin: Nhập viện, chuyển viện, xuất viện
MSH Đoạn Header của bản tin
EVN Đoạn loại sự kiện
[PD1] Thông tin bổ xung
[ { NK1 } ] Đoạn thông tin về thân nhân PV1 Đoạn thông tin về khám bệnh [ PV2 ] Đoạn thông tin về khám bệnh (bổ xung) [ { DB1 } ] Thông tin bệnh tật
[ { OBX } ] Thông tin về kết quả / theo dõi bệnh [ { AL1 } ] Thông tin về dị ứng
[ { DG1 } ] Thông tin chẩn đoán [ DRG ] Thông tin liên quan tới chẩn đoán [ { PR1 }] Đoạn thủ tục hành chính
[ IN2 ] Thông tin bổ xung về bảo hiểm
[ {IN3} ] Thông tin bổ xung về bảo hiểm
[ ACC ] Thông tin về tai biến
[ UB1 ] Thanh toán hóa đơn
1 Đoạn mào đầu bản tin:
MSH||STORE|MISSION|MINE|LAUREL|199801181007|security|ADT|
3 Đoạn xác nhận bệnh nhân:
PID|||PATID1234567||Doe^John^B^II||19470701|M||C|371MAN
AVE^SAN FRANCISCO^CA^94122-0619||45-681-2888||||||||
4 Đoạn thân nhân bệnh nhân:
NK1||Doe^Linda^E||wife|
5 Đoạn thông tin nhập viện:
PV1|1|I|100^345^01||||00135^SMITH^WILLIAM^K|||SUR|AD|
Bản tin mã hóa theo tiêu chuẩn HL7 cung cấp thông tin chi tiết về bệnh nhân John B Doe, II, mã bệnh nhân 1234567 Ông là nam giới, da trắng, sinh ngày 1 tháng 7 năm 1947, hiện cư trú tại 371 Avenue-Sanfrancisco Bệnh nhân nhập viện vào lúc 10 giờ ngày 18 tháng 1 năm 1998.
Vào lúc 05 phút sáng, bác sĩ William K Smith đã tiến hành xét nghiệm và điều trị cho bệnh nhân Bệnh nhân được chỉ định nằm viện tại giường số 01, phòng 345, thuộc tổ chăm sóc 100 Thân nhân của bệnh nhân là vợ, Linda E Doe, đã nhận được bản tin từ Mission gửi đến Mine ngay sau khi bệnh nhân nhập viện 2 phút.
Dấu “|” dùng để phân cách giữa các trường dữ liệu, nếu không có trường dữ liệu nó được coi như là trường trống
2.2.2 Các khái niệm cơ sở trong cấu trúc HL7 2.2.2.1 Sự kiện kích khởi
HL7 định nghĩa rằng một sự kiện trong chăm sóc sức khỏe, gọi là sự kiện kích khởi (trigger event), tạo ra nhu cầu truyền dữ liệu giữa các hệ thống Ví dụ, khi một bệnh nhân được nhập viện, sự kiện này có thể yêu cầu gửi dữ liệu liên quan đến bệnh nhân đến các hệ thống khác Ngoài ra, một sự theo dõi, như kết quả xét nghiệm, cũng có thể kích thích nhu cầu truyền dữ liệu tương tự Khi hệ thống ứng dụng khởi tạo việc truyền tin dựa trên sự kiện kích khởi, phiên giao dịch này được gọi là unsolicited update (cập nhật tự gởi đi).
Lưu ý rằng không có giả thiết nào liên quan đến thiết kế hoặc kiến trúc của hệ thống ứng dụng tạo ra “cập nhật không yêu cầu” Phạm vi của HL7 chỉ được xác định bởi các đặc điểm của bản tin giữa các hệ thống ứng dụng và các sự kiện kích hoạt chúng.
HL7 cho phép sử dụng sự kiện kích hoạt ở nhiều cấp độ khác nhau của dữ liệu, phản ánh tính chất hột (data granularity) và các mối quan hệ giữa chúng Chẳng hạn, nhiều sự kiện kích hoạt Quản trị bệnh nhân (ADT) liên quan đến một đối tượng đơn lẻ, như sự kiện nhận bệnh nhân, tạo ra bản tin chứa dữ liệu về một bệnh nhân hoặc tài khoản đơn Ngoài ra, có những sự kiện ADT khác liên quan đến mối quan hệ giữa nhiều đối tượng, ví dụ như sự kiện hợp bệnh nhân chỉ định hoặc hợp tài khoản Một số sự kiện ADT cũng gắn liền với tập hợp đối tượng mà không có mối quan hệ trung gian lớn, như một truy vấn địa phương cung cấp dữ liệu về một nhóm bệnh nhân nội trú chỉ liên quan tạm thời theo cấu trúc địa phương.
2.2.2.2 Sự nhận - chế độ nguyên thủy:
Khi một hệ thống gửi cập nhật tự động đến một hệ thống khác, chế độ nhận cho thấy rằng thông tin được tiếp nhận ở cấp ứng dụng Điều này là cần thiết vì việc đảm bảo phân phát bản tin chỉ từ hệ thống truyền thông lớp dưới là không đủ Hệ thống cần xác nhận rằng ứng dụng nhận đã xử lý dữ liệu thành công ở mức ứng dụng địa phương.
Sự nhận có thể chứa dữ liệu quan tâm đến hệ thống khởi tạo việc trao đổi
Hệ thống chăm sóc bệnh nhân có khả năng tự động gửi cập nhật đến ứng dụng xét nghiệm khi nhận được sự kiện kích khởi "một xét nghiệm được yêu cầu cho một bệnh nhân" Cập nhật này bao gồm thông tin về bệnh nhân, yêu cầu xét nghiệm và các thông tin liên quan khác Hệ thống phụ thuộc sẽ xác nhận yêu cầu xét nghiệm khi quá trình xử lý diễn ra thành công.
Chuẩn HL7 không quy định quyền sở hữu dữ liệu và không yêu cầu quyền sở hữu đối với các hoạt động tiếp theo của dữ liệu nhận Nó cũng không đưa ra giả định về thiết kế hoặc kiến trúc của hệ thống ứng dụng nhận Phạm vi của HL7 chỉ giới hạn ở các đặc trưng kỹ thuật của bản tin giữa các hệ thống nhận và các sự kiện kích hoạt chúng.
Chuẩn HL7 không giải thích yêu cầu của hệ thống trong việc truyền dữ liệu đến cơ sở dữ liệu trước khi nhận Hệ thống nhận chịu trách nhiệm cho dữ liệu và thực hiện kiểm tra toàn vẹn từ mọi nguồn Ví dụ, hệ thống phụ thuộc có thể nhận yêu cầu xét nghiệm sau khi đã được đưa vào trình tự đầu vào, với giả thiết rằng trình tự này duy trì mức độ toàn vẹn tương tự như cơ sở dữ liệu.
2.2.2.3 Sự nhận - chế độ tăng cường:
Mô hình nhận HL7 đã được cải tiến để phân biệt giữa sự nhận ứng dụng và sự chấp nhận, với các điều kiện cần thiết cho mỗi loại Khi có sự chấp nhận dương, hệ thống sẽ truyền bản tin đến nơi lưu trữ an toàn, giúp giải phóng hệ thống gửi khỏi nhu cầu gửi lại bản tin Sau khi bản tin được xử lý, sự nhận ứng dụng sẽ được sử dụng để hoàn trả trạng thái kết quả cho hệ thống gửi.
Một trao đổi dữ liệu diễn ra khi một hệ thống gửi truy vấn đến hệ thống khác, như trong ứng dụng thông tin, nơi có thể xảy ra sự kiện kích khởi “một thủ tục được lên lịch” cho bệnh nhân chưa đăng ký trong cơ sở dữ liệu Ứng dụng gửi yêu cầu chứa mã ID của bệnh nhân đến hệ thống quản trị và nhận phản hồi với dữ liệu cần thiết để xử lý yêu cầu Giao dịch gửi yêu cầu này được gọi là truy vấn, và thông tin chảy giữa các hệ thống được chứa trong phản hồi, mà không nhận một bản tin thứ ba.
ĐỀ XUẤT GIẢI PHÁP CHUẨN HÓA BỆNH ÁN ĐIÊN TỬ THEO CHUẨN HL7
Mô hình ứng dụng
Mạng lưới cơ sở y tế tại Việt Nam được phân cấp rõ rệt, 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 Mỗi năm, hệ thống này phục vụ hàng triệu lượt bệnh nhân, đảm bảo chăm sóc sức khỏe cho người dân trên toàn quốc.
150 triệu lượt khám bệnh dẫn đến tình tra ̣ng hẹ ̂ thống bệnh viện nước ta luôn trong tình tra ̣ng bi ̣ quá tải
Hình 3-1 Mô hình thống kê cơ sở y tế ở Việt Nam
Theo thống kê, hàng năm Bệnh viện Việt Đức ghi nhận khoảng 1.000 trường hợp bệnh nhân tử vong trong quá trình chuyển đến bệnh viện Trong số này, nhiều trường hợp nếu được xử lý ban đầu tốt có thể được cứu sống.
Trước thực trạng ứng dụng công nghệ thông tin (CNTT) trong quản lý bệnh viện, Bộ y tế và các bệnh viện đang nỗ lực triển khai với nhiều mức độ khác nhau Một số bệnh viện chỉ dừng lại ở việc quản lý thông tin bệnh nhân trên máy tính, trong khi những bệnh viện khác đã thực hiện trao đổi hồ sơ bệnh án, chẩn đoán từ xa và hội chẩn từ xa Dù quy mô ứng dụng lớn hay nhỏ, Bộ y tế vẫn hướng tới xây dựng hệ thống quản lý theo chuẩn quốc tế, chủ yếu là chuẩn HL7 cho hệ thống quản lý bệnh viện (HIS) và chuẩn DICOM cho quản lý hình ảnh (RIS & PACS) Để đảm bảo việc trao đổi thông tin y tế giữa các bệnh viện, cần giải quyết ba bài toán cơ bản: thứ nhất là bài toán liên tác về ngữ nghĩa, thứ hai là bài toán liên tác về cú pháp, và thứ ba là bài toán về mô hình truyền - nhận.
Trong bối cảnh bệnh án điện tử tại Việt Nam còn thiếu chuẩn mực và được triển khai riêng lẻ tại các cơ sở y tế, việc xây dựng một hệ thống bệnh án chuẩn và khả năng trao đổi dữ liệu giữa các bệnh viện là vô cùng cần thiết Đề xuất của tôi trong bài viết này là cấu trúc thông tin của hồ sơ bệnh án điện tử theo chuẩn HL7, nhằm tạo điều kiện thuận lợi cho việc trao đổi dữ liệu giữa các hệ thống ứng dụng CNTT trong lĩnh vực y tế Chương này sẽ tập trung vào việc mô tả chi tiết mô hình và phương pháp chuẩn hóa dữ liệu, cũng như quy trình trao đổi dữ liệu trong hệ thống bệnh án điện tử theo tiêu chuẩn đã đề ra.
Sau đây là mô hình tổng thể về trao đổi thông tin:
Hình 3-2 Mô hình trao đổi thông tin tổng thể hệ thống HL7 CORE
Hệ thống HL7 CORE bao gồm ba thành phần chính: HL7 CORE Bệnh viện, HL7 CORE INTERFACE ENGINE và HL7 CORE GATEWAY Các thành phần này tương tác với hệ thống thông tin bệnh viện (HIS) và các hệ thống khác, đóng vai trò quan trọng trong việc trao đổi Hồ sơ bệnh án (HSBA) giữa các bệnh viện.
Mô hình trong Hình 3-2 minh họa mối quan hệ trao đổi thông tin giữa các thành phần trong hệ thống HL7 CORE, đặc biệt là giữa hai Bệnh viện A và B khi chia sẻ thông tin về hồ sơ bệnh án (HSBA) cùng các thông tin liên quan khác.
Thông tin trao đổi 2 chiều trong hệ thống HL7 CORE cho phép các bệnh viện gửi và nhận hồ sơ bệnh án (HSBA) từ nhau Danh mục thông tin trao đổi giữa hệ thống thông tin bệnh viện (HIS) và HL7 CORE được quản lý tập trung, đảm bảo tính chuẩn mực Hệ thống HL7 CORE GATEWAY sẽ luôn được cập nhật và đồng bộ hóa thông qua bảng ánh xạ với danh mục riêng của từng bệnh viện.
Thành phần HL7 CORE INTERFACE ENGINE đóng vai trò quan trọng và được tích hợp trong hệ thống HL7 CORE Bệnh viện và HL7 CORE GATEWAY Nó cung cấp các thư viện và hàm dưới dạng API hoặc services để chuyển đổi thông tin hồ sơ bệnh án (HSBA) thành định dạng HL7 message, đồng thời thực hiện mã hóa và giải mã Thành phần này hỗ trợ các tiêu chuẩn CDA, CCD, DICOM, X12 dưới dạng XML và các công cụ hỗ trợ khác, đảm bảo tính chính xác và toàn vẹn dữ liệu khi trao đổi HSBA.
Mô hình triển khai hệ thống HL7 CORE Bệnh viện sẽ được cài đặt tại từng hệ thống thông tin của các bệnh viện, nhằm đảm bảo kết nối nội bộ với hệ thống thông tin bệnh viện (HIS) Các hệ thống HL7 CORE Bệnh viện sẽ kết nối với HL7 CORE GATEWAY qua mạng Internet, đảm bảo bảo mật bằng cách sử dụng các phần mềm hoặc thư viện như OpenSSL theo giao thức SSL Toàn bộ dữ liệu sẽ được mã hóa trong quá trình truyền tải.
Thông tin hồ sơ bệnh án (HSBA) được quản lý trong hệ thống thông tin bệnh viện (HIS) và được chuyển tới hệ thống HL7 CORE Tại đây, thông tin được chuẩn hóa, chuyển đổi sang định dạng HL7 và mã hóa Dữ liệu được lưu trữ trước tiên trong cơ sở dữ liệu (CSDL) trung gian, sau đó được chuyển đến CSDL chính thức để truyền tải 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ình3-3: Mô hình trao đổi thông tin trong nội bộ hệ thống thông tin bệnh viện
(HIS) và hệ thống HL7 CORE Bệnh viện
Các hệ thống HIS hiện tại sẽ được nâng cấp để đảm bảo khả năng truyền và nhận dữ liệu với hệ thống HL7 CORE Việc nâng cấp này là yêu cầu bắt buộc, trong đó các hệ thống HIS sẽ 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 thông tin đầy đủ Sau khi dự án triển khai thành công tại các bệnh viện, cần ban hành tiêu chuẩn về hệ thống HIS để hỗ trợ việc trao đổi hồ sơ bệnh án với hệ thống HL7 CORE.
Thuyết minh chi tiết các bước trao đổi thông tin như sau:
Hệ thống HIS Bệnh viện liên tục 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 để tương tác với hệ thống HL7 CORE Những bảng dữ liệu trung gian này có thể được lưu trữ trong CSDL logic của hệ thống HIS Dữ liệu sau đó được chuyển đến CSDL Trung gian của hệ thống HL7 CORE Bệnh viện Để trao đổi thông tin, có hai phương án: 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 sử dụng các hàm thư viện trong HL7 CORE INTERFACE ENGINE để chuyển đổi dữ liệu HSBA thành các thông điệp HL7, gửi đến cơ sở dữ liệu chính thức của HL7 CORE Bệnh viện Dữ liệu được lưu trữ và quản lý trong hàng đợi, đồng thời hệ thống ghi lại tất cả các sự kiện và giao dịch liên quan đến các thao tác này Thông tin được truyền tải dưới dạng các bản tin đã được mã hóa.
Danh mục chuẩn trong CSDL HL7 CORE Bệnh viện luôn được cập nhật mới nhất từ HL7 CORE GATEWAY Danh mục này giúp chuẩn hóa dữ liệu trong CSDL trung gian của HL7 CORE Bệnh viện bằng cách tạo bản sao danh mục chuẩn Giải pháp trao đổi dữ liệu là kết nối trực tiếp giữa hai CSDL logic: CSDL trung gian và CSDL HL7 CORE Bệnh viện.
Bước (5) và (6) liên quan đến việc truyền danh mục chuẩn mới nhất từ CSDL trung gian của HL7 CORE Bệnh viện tới hệ thống HIS, giúp cập nhật các danh mục theo quy định mới nhất CSDL trung gian cũng lưu trữ bản sao 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 để chuẩn hóa các HL7 message, phục vụ cho việc trao đổi thông tin giữa các hệ thống HIS Giải pháp trao đổi thông tin được thực hiện qua web services.
Chi tiết quy trình trao đổi thông tin HSBA
Giao tiếp giữa HL7 CORE Bệnh viện và HL7 CORE Gateway
3.3.1.1 Cấu trúc cơ bản của bản tin HL7
Mỗi thông điệp HL7 là một bản tin văn bản được cấu trúc thành các segment thông tin, trong đó mỗi segment chứa các trường thông tin được phân tách bởi kí tự đặc biệt (thường là |) Số lượng segment và thông tin trong mỗi loại thông điệp có thể khác nhau tùy thuộc vào loại thông điệp cụ thể.
Bảng 3-9: Các segment thông tin của một thông điệp HL7
STT Mã Name Ý nghĩa sử dụng
1 MSH Message Header Thông tin header của bản tin
2 SFT Software Segment Thông tin về phần mềm
3 EVN Event Type Thông tin về sự kiện
4 PID Patient Identification Thông tin về bệnh nhân
Patient Additional Demographic Thêm thông tin về bệnh nhân
Thông tin về người vài trò với bệnh nhân
7 MRG Merge patient Hợp nhất thông tin bệnh nhân information segment
Associated Parties Thông tin về thân nhân bệnh nhân trong xã hội
Thông tin về đợt điều trị (patient visit)
Patient Visit - Additional Information Thêm thông tin về đợt điều trị
11 DB1 Disability Thông tin về khuyết tật
12 OBR Observation request Thông tin về yêu cầu xét nghiệm
13 OBX Observation/Result Thông tin về kết quả xét nghiệm
Information Thông tin về dị ứng
15 DG1 Diagnosis Thông tin chẩn đoán
Thông tin về chẩn đoán nhóm liên quan
Thông tin về người bảo lãnh trả viện phí
Thông tin vụ tai nạn mà bệnh nhân đã tham gia
Thông tin dữ liệu cần thiết về bệnh nhân để hoàn thành luật UB82
Thông tin dữ liệu cần thiết về bệnh nhân để hoàn thành luật UB92
Thông tin về khám nghiệm tử thi khi bệnh nhân chết
Thông tin về bệnh nhân phản ứng bất lợi về nó
Thông tin trạng thái giường ngủ cập nhật
24 IN1 Insurance Thông tin về bảo hiểm
25 IN2 Insurance additional information segment Bổ sung thông tin bảo hiểm
Insurance additional information, certification segment
Bổ sung thông tin bảo hiểm, có chứng nhận
Financial transaction segment Thông tin giao dịch tài chính
28 PR1 Procedures segment Thông tin về phẫu thuật/thủ thuật
MSH là phần quan trọng nhất trong mỗi bản tin, giúp xác định cấu trúc và kiểu bản tin được áp dụng Thông qua MSH, chúng ta có thể nhận diện đầy đủ thông tin về nơi gửi, nơi nhận và ý nghĩa của thông điệp trong quá trình giao dịch giữa hai hệ thống thông tin.
Bảng 3-10: Các trường thông tin trong MSH
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
1 ST R Field Separator Kí tự phân tách |
2 ST R Encoding Characters 4 ký tự mã hóa phân tách thông tin
3 HD O Sending Application Ứng dụng gửi thông điệp
4 HD O Sending Facility Nơi gửi thông điệp
6 HD O Receiving Facility Nơi nhận
Message Thời gian tạo bản tin
9 CM R Message Type Loại bản tin
10 ST R Message Control ID Mã điều khiển bản tin
11 PT R Processing ID Mã tiến trình
12 ID R Version ID Phiên bản
13 NM O Sequence Number Chuỗi nhiều sự kiện
14 ST O Continuation Pointer Điểm tiếp tục
Acknowledgment Type Kiểu xác nhận chấp nhận
Acknowledgment Type Kiểu xác nhận loại ứng dụng
17 ID O Country Code Mã nước
18 ID O Character Set Bộ kí tự mã hóa
Trong bản tin, ngôn ngữ sử dụng cần chú ý đến thông điệp chứa thông tin về bệnh nhân Để tóm tắt các thông tin chính về bệnh nhân và đợt thăm khám, cần sử dụng các segment PID và PV1.
Bảng 3-11: Các trường thông tin cơ bản về bệnh nhân (PID)
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
1 SI O Set ID - Patient ID Thiết lập ID
ID bệnh nhân(ID bên ngoài)
ID) ID bệnh nhân(ID bên trong)
PID ID khác của bệnh nhân
5 XPN R Patient Name Tên bệnh nhân
Name Tên mẹ bệnh nhân
7 TS O Date/Time of Birth Ngày sinh
9 XPN O Patient Alias Bí danh
10 IS O Race Chủng tộc, tổ tiên
11 XAD O Patient Address Địa chỉ bệnh nhân
Bảng 3-12: Các trường thông tin về đợt điều trị tại bệnh viện (PV1)
1 SI O Set ID - PV1 Thiết lập ID
2 IS R Patient Class Phân loại bệnh nhân: Điều trị nội trú, ngoại trú…
Location Nơi phòng khám bệnh nhân cần xét nghiệm
4 IS O Admission Type Loại bệnh nhân nhập viện: Tai nạn, khẩn cấp, thuyền xuyên,lao động
5 CX O Preadmit Number Số tài khoản của bệnh nhân trước khi được nhập viện
Location Nơi trước khi bệnh nhân đến
7 XCN O Attending Doctor Bác sỹ chăm sóc, phục vụ
8 XCN O Referring Doctor Bác sỹ chuyển đến
Doctor Bác sỹ cố vấn
10 IS O Hospital Service Dịch vụ bệnh viện
Location Nơi ở tạm thời của bệnh nhân
Indicator Chỉ số kiểm tra trước khi được nhập viện
Chỉ số bệnh nhân được nhận trở lại
14 IS O Admit Source Nguồn nhận vào
Trạng thái khuyết tật vĩnh viến hay tạm thời
16 IS O VIP Indicator Chỉ số VIP
17 XCN O Admitting Doctor Bác sỹ nhận hồ sơ
18 IS O Patient Type Loại bệnh nhân
19 CX O Visit Number Số đợt điều trị
20 CM O Financial Class Nguồn tài chính của bệnh nhân
Indicator Chỉ số giá phí chi trả của bệnh nhân
22 IS O Courtesy Code Mã ưu đãi
23 IS O Credit Rating Thẻ tín dụng
24 IS O Contract Code Mã hợp đồng
Effective Date Hợp đồng hiệu lực ngày
26 NM O Contract Amount Số tiền hợp đồng
27 NM O Contract Period Thời gian hợp đồng
28 IS O Interest Code Mã quan tâm
Debt Code Mã chuyển sang nợ xấu
Debt Date Ngày chuyển sang nợ xấu
Code Mã cơ quan có thể chuyển sang nợ xấu
Transfer Amount Số tiền chuyển sang nợ xấu
Số tiền có thể đòi lại từ bên bảo lãnh
Indicator Chỉ số xóa tài khoản
Date Ngày xóa tài khoản
Sắp xếp bệnh nhân khi kết thúc khám
Location Nơi bệnh nhân kết thúc khám
38 IS O Diet Type Loại chế độ ăn kiêng
39 IS O Servicing Facility Bệnh nhân sử dụng dịch vụ gì
40 IS B Bed Status Trạng thái giường của bệnh nhân
41 IS O Account Status Trạng thái tài khoản của bệnh nhân
42 PL O Pending Location Nơi bệnh nhân gửi
Location Nơi trước khi tạm thời của bệnh nhân
44 TS O Admit Date/Time Thời gian vào viện
Date/Time Thời gian ra viện
3.3.1.2 Cấu trúc thông đệp gửi nhận (MDM-ACK)
Cấu trúc thông điệp MDM-AKC (Quản lý tài liệu y tế - Xác nhận) được sử dụng để gửi và nhận thông tin tài liệu Thông điệp này bao gồm các segment TXA và OBX để thể hiện thông tin của tệp dữ liệu kèm theo Dữ liệu của tệp kèm theo thường được biểu diễn dưới dạng MIME, tương tự như các tệp đính kèm trong email.
Bảng 3-13: Các trường thông tin cơ bản TXA
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
1 SI R Set ID- Document Thiết lập ID
Bảng 3-14: Các trường thông tin trong OBX
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
1 SI O Set ID – OBX ID của OBX
2 ID C Value Type Kiểu giá trị
3 CE R Observation Identifier Định danh của Observation
4 ST C Observation Sub-ID Dùng để phân biệt các đoạn
5 ST C Observation Value Gía trị của Observation
6 CE O Units Các đơn vị của 1 kiểu dự liệu CE
7 ST O References Range Phạm vi tham chiếu
8 ID O Abnormal Flags Các cờ bất thường
10 ID O Nature of Abnormal Kiểm tra các bất thường
11 ID R Observ Result Status Trạng thái của Observation
Dưới đây là ví dụ về cấu trúc thông điệp HL7, được áp dụng để gửi một bộ tài liệu bao gồm CDA và các tài liệu đính kèm dưới dạng MIME Type trong hệ thống HL7 CORE.
MSH|^~\&|||||||MDM^T02^MDM_T02||P|2.5.1
PID|||^^^||^
PV1|||||||||||||||||||||||||||||||||||||||||||||
TXA|1||multipart|||||||||||||LA
The article discusses the structure of a consent document for patients, formatted in HL7 CDA level three It highlights the use of multipart MIME types and Base64 encoding for data transfer The content is organized with specific boundaries to separate different sections, ensuring clarity and compliance with healthcare data standards.
Thông điệp để trả lời là loại ACK với các segment MSA và ERR được sử dụng như sau
Bảng 3-15: Các trường thông tin MSA
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
2 ST R Message Control ID Mã kiểm soát thông điệp
3 ST O Text Message Thông báo đính kèm
Number Số trao đổi tiếp theo
Type Kiểu phản hồi trễ
6 CE O Error Condition Tình trạng lỗi
Bảng 3-16: Các trường thông tin ERR
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
8 TX O User Message Sau đây là ví dụ được sử dụng cho một cấu trúc thông điệp HL7 loại ACK
MSH|^~\&|||||||ACK^T02^ACK||P|2.5.1
MSA|||
ERR||||E|||
3.3.1.3 Cấu trúc thông điệp truy vấn dữu liệu (VQQ-TBR) Để trao đổi dữ liệu danh mục trong hệ thống HL7 CORE, HL7 v2.5 cung cấp cấu trúc thông điệp dạng VQQ-TBR (Virtual Table Query – Tabular Data Response) Theo đó, ứng dụng client phải gửi thông điệp truy vấn dữ liệu có cấu trúc VQQ và ứng dụng server trả về kết quả qua thông điệp có cấu trúc TBR Những thông điệp này sẽ cần sử dụng các segment VTQ (Virtual Table Query), QAK (Query Acknowlegment), RDF (Table Row Definition) và RDF (Table Row Data) dưới đây để biểu diễn thông tin
Bảng 3-17: Các trường thông tin VTQ
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
Bảng 3-18: Các trường thông tin QAK
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
Bảng 3-19: Các trường thông tin RDF
SEQ DT OPT ELEMENT NAME Ý nghĩa sử dụng
1 NM R Number of Columns per Row
Bảng 3-20 Các trường thông tin RDT
Ví dụ thông điệp truy vấn dữ liệu
MSH|^~\&|||||||VQQ^Q07||P|2.5.1
VTQ||T||
Ví dụ thông điệp trả lời câu hỏi truy vấn
MSH|^~\&|||||||TBR^R08|MSG-20140929-174014-0248|P|2.5.1
MSA|||
QAK||||
RDF||^^|
RDT|||
RDT|||
3.3.2 Quy trình trao đổi thông tin trong hệ thống HL7 CORE 3.3.2.1 Trao đổi dữ liệu HSBA dạng CDA
Quá trình trao đổi HSBA giữa các ứng dụng trong hệ thống HL7 CORE được triển khai bằng cách sử dụng 3 thông điệp HL7 là MDM, ACK1 và ACK2
MDM là thông điệp dùng để truyền tải toàn bộ Hồ sơ bệnh án (HSBA), bao gồm các tệp CDA và tệp đính kèm theo định dạng MIME Trường MSH trong thông điệp cần chứa thông tin của bệnh viện gửi và bệnh viện nhận HSBA Thông điệp này được ứng dụng gửi (HL7 CORE Bệnh viện) chuyển qua Gateway trước khi được chuyển tiếp đến ứng dụng đích.
ACK1 là phản hồi từ ứng dụng Gateway liên quan đến việc gửi hồ sơ bệnh án (HSBA) nhằm thông báo kết quả phân tích và thực hiện chuyển tiếp MDM đến ứng dụng đích Gateway có thể trả về các lỗi, bao gồm lý do như cấu trúc thông điệp không hợp lệ hoặc bệnh viện đích không tồn tại.
ACK2 là thông điệp phản hồi từ ứng dụng đích gửi về ứng dụng gửi để thông báo kết quả nhận hồ sơ bệnh án (HSBA) Thông điệp ACK2 được chuyển tiếp qua Gateway Một hồ sơ bệnh án chỉ được coi là đã đến đích khi ứng dụng gửi nhận được ACK2 từ ứng dụng đích.
3.3.2.2Trao đổi dữ liệu danh mục
Quá trình trao đổi dữ liệu danh mục giữa ứng dụng HL7 CORE Bệnh viện và ứng dụng HL7 CORE Gateway diễn ra qua hai pha Trong pha đầu tiên, HL7 CORE Bệnh viện truy vấn thông tin metadata về tất cả các bộ dữ liệu danh mục đang được sử dụng Dựa trên thông tin metadata nhận được, ứng dụng có thể xác định các phiên bản cập nhật mới nhất Ở pha thứ hai, HL7 CORE Bệnh viện thực hiện truy vấn và cập nhật dữ liệu của các bộ danh mục đã được xác định có sự thay đổi sau khi phân tích ở pha một Bảng dưới đây mô tả cấu trúc thông tin của các câu truy vấn và phản hồi cho hai giai đoạn này.
Bảng 3-21: Cấu trúc thông tin của thông điệp truy vấn và trả lời
1 Metadata AllDataset Danh sách các dataset với các thông tin gồm mã danh mục, phiên bản sử dụng, ngày cập nhật cuối cùng,…
2 Dataset Cấu trúc dữ liệu bảng danh mục tương ứng với
Dựa trên những nghiên cứu đã thực hiện, tôi tin rằng việc triển khai hệ thống chuyển đổi dữ liệu chưa chuẩn hóa sẽ trở nên dễ dàng hơn Đồng thời, chúng ta có thể xây dựng một hệ thống bện án điện tử đạt tiêu chuẩn, phục vụ cho nhiều mục đích khác nhau trong tương lai.