Một bản tin HL7 v2 trông như thế nào? Giải thích MSH, PID, PV1, ORC, OBR, OBX

Ở bài trước, chúng ta đã biết HL7 v2 giúp HIS, EMR, LIS, RIS và các hệ thống y tế trao đổi dữ liệu bằng các bản tin có cấu trúc.

Nhưng khi mở một bản tin HL7 thực tế, bạn có thể bắt gặp những dòng như:

Nhìn qua, dữ liệu này khá giống một chuỗi ký tự khó đọc. Tuy nhiên, một bản tin HL7 v2 không phải dữ liệu hỗn độn. Nó giống một câu chuyện về người bệnh, được chia thành từng đoạn. Mỗi đoạn cung cấp một nhóm thông tin riêng.

Cấu trúc thường gặp có thể được hình dung như sau:

Hay ghi nhớ bằng ngôn ngữ nghiệp vụ:

Bản tin HL7 v2 là gì?

Bản tin HL7 v2 là một gói dữ liệu được tạo ra để truyền thông tin giữa các hệ thống y tế.

Trong một quy trình xét nghiệm, LIS có thể gửi bản tin về HIS hoặc EMR để thông báo rằng kết quả đã sẵn sàng. Bản tin có thể bao gồm:

• Thông tin hệ thống gửi và nhận.

• Người bệnh.

• Lượt khám hoặc đợt điều trị.

• Mã chỉ định.

• Tên xét nghiệm.

• Kết quả.

• Đơn vị đo.

• Khoảng tham chiếu.

• Trạng thái xác nhận.

HL7 v2 tổ chức bản tin thành các Segment. Mỗi Segment bắt đầu bằng mã ba ký tự, chẳng hạn MSH, PID, PV1, OBR hoặc OBX. Mỗi Segment lại gồm nhiều Field được phân tách bằng ký tự định nghĩa trong bản tin.hl7-definition.caristix

MSH – Message Header

“Ai đang gửi thông tin cho ai?”

MSH thường là Segment đầu tiên của mọi bản tin HL7 v2. Đây là phần mô tả cách bản tin được tạo, gửi và xử lý.

Có thể hình dung MSH giống như thông tin bên ngoài một phong bì:

• Ai gửi?

• Gửi cho ai?

• Gửi lúc nào?

• Đây là loại thông tin gì?

• Bản tin thuộc phiên bản HL7 nào?

• Mã kiểm soát của bản tin là gì?

Ví dụ:

Một số thành phần đáng chú ý:

• LIS: ứng dụng gửi.

• BENH_VIEN: cơ sở gửi.

• HIS_EMR: ứng dụng nhận.

• 202609120900: thời điểm gửi.

• ORU^R01: loại bản tin và sự kiện.

• MSG123: mã kiểm soát bản tin.

• P: chế độ xử lý thực tế.

• 2.5: phiên bản HL7.

MSH còn giúp hệ thống nhận biết cách phân tích các Segment và Field tiếp theo. Vì vậy, lỗi ở MSH có thể khiến toàn bộ bản tin bị từ chối hoặc đọc sai.

PID – Patient Identification

“Dữ liệu này thuộc về người bệnh nào?”

PID chứa thông tin nhận dạng người bệnh. Đây là một Segment đặc biệt quan trọng trong mọi luồng liên thông y tế.

Ví dụ:

Thông tin có thể bao gồm:

• Mã người bệnh hoặc MRN.

• Họ và tên.

• Ngày sinh.

• Giới tính.

• Địa chỉ.

• Số điện thoại.

• Các mã định danh khác.

Trong ví dụ trên:

• 12345 là mã người bệnh.

• NGUYEN^VAN^AN là thông tin họ tên được chia thành các thành phần.

• 19800101 là ngày sinh theo định dạng của bản tin.

• M là giới tính nam.

Trong triển khai thực tế, PID không chỉ là một phần dữ liệu hành chính. Đây là điểm liên kết để kết quả xét nghiệm, báo cáo chẩn đoán hình ảnh hoặc thông tin điều trị được gắn đúng hồ sơ.

Nếu mã người bệnh bị sai, kết quả có thể được đưa vào nhầm hồ sơ. Vì vậy, việc kiểm tra PID cần được thực hiện nghiêm túc trong cả kiểm thử kỹ thuật và kiểm thử nghiệp vụ.

PV1 – Patient Visit

“Người bệnh đang khám hoặc điều trị trong hoàn cảnh nào?”

PV1 mô tả thông tin của lượt khám hoặc đợt điều trị.

Ví dụ:

Một số thông tin thường liên quan đến PV1 gồm:

• Số thứ tự Segment.

• Loại người bệnh.

• Nội trú, ngoại trú hoặc cấp cứu.

• Khoa hoặc phòng.

• Vị trí điều trị.

• Bác sĩ phụ trách.

• Mã lượt khám hoặc thông tin đợt điều trị.

Có thể ghi nhớ:

• PID trả lời câu hỏi: Người bệnh là ai?

• PV1 trả lời câu hỏi: Người bệnh đang thuộc lượt khám nào?

Một người bệnh có thể đến bệnh viện nhiều lần. Thậm chí trong một lần đến, người bệnh có thể đi qua nhiều khoa. Vì vậy, chỉ biết mã người bệnh là chưa đủ. Hệ thống còn cần nhận diện đúng encounter hoặc visit.

ORC – Common Order

“Chỉ định này được quản lý như thế nào?”

ORC chứa thông tin điều khiển chung của một chỉ định.

Ví dụ:

Trong đó:

• NW thường biểu thị yêu cầu tạo mới.

• ORD12345 là mã chỉ định hoặc mã order.

Tùy cấu hình, ORC có thể chứa thêm:

• Trạng thái chỉ định.

• Mã order của hệ thống đặt yêu cầu.

• Mã order của hệ thống thực hiện.

• Người chỉ định.

• Thời gian tạo hoặc cập nhật.

• Thông tin cơ sở thực hiện.

Có thể hiểu ORC trả lời câu hỏi:

Đây là chỉ định nào và hệ thống cần thực hiện thao tác gì với chỉ định đó?

 

 

ORC thường đóng vai trò điều khiển vòng đời của order, chẳng hạn tạo mới, thay đổi, hủy hoặc hoàn tất.

OBR – Observation Request

“Cụ thể cần thực hiện xét nghiệm hoặc thủ thuật gì?”

OBR mô tả nội dung xét nghiệm, thủ thuật hoặc yêu cầu quan sát.

Ví dụ:

Dòng này cho biết chỉ định liên quan đến xét nghiệm công thức máu, với mã CBC.

OBR có thể chứa những thông tin như:

• Số thứ tự yêu cầu.

• Mã chỉ định.

• Mã dịch vụ.

• Tên xét nghiệm hoặc thủ thuật.

• Thời gian lấy mẫu.

• Thời gian thực hiện.

• Người chỉ định.

• Trạng thái báo cáo.

Sự khác nhau giữa ORC và OBR có thể hiểu đơn giản:

• ORC: quản lý chỉ định.

• OBR: mô tả nội dung cần làm.

Trong bản tin kết quả ORU, OBR thường đóng vai trò tiêu đề cho một nhóm kết quả. Các Segment OBX phía sau sẽ chứa từng chỉ số hoặc quan sát cụ thể thuộc nhóm đó.hl7

OBX – Observation/Result

“Kết quả là gì?”

OBX chứa một giá trị quan sát hoặc kết quả xét nghiệm.

Ví dụ:

Có thể đọc bản tin này theo cách đơn giản:

• 1: số thứ tự kết quả.

• NM: kiểu dữ liệu số.

• HGB^HEMOGLOBIN: mã và tên chỉ số.

• 13.2: giá trị kết quả.

• g/dL: đơn vị đo.

• 12.0-16.0: khoảng tham chiếu.

• N: trạng thái đánh giá bình thường.

OBX không chỉ chứa con số. Tùy loại kết quả, Segment này có thể truyền:

• Giá trị số.

• Chuỗi văn bản.

• Mã kết quả.

• Đơn vị đo.

• Khoảng tham chiếu.

• Cờ bất thường.

• Trạng thái kết quả.

• Thời điểm quan sát hoặc phân tích.

• Thông tin thiết bị hoặc người xác nhận.

Trong một báo cáo xét nghiệm có nhiều chỉ số, một OBR có thể đi kèm nhiều OBX. Mỗi OBX đại diện cho một kết quả hoặc một thành phần nhỏ trong báo cáo.dhhs.ne

Đọc một bản tin HL7 v2 thực tế

Giả sử LIS vừa có kết quả xét nghiệm và cần gửi về HIS/EMR:

Không nên cố đọc toàn bộ ký tự cùng một lúc. Hãy đọc theo từng Segment.

MSH

LIS đang gửi một bản tin kết quả xét nghiệm ORU^R01 cho HIS/EMR.

PID

Kết quả thuộc người bệnh Nguyễn Văn An, mã người bệnh 12345.

PV1

Người bệnh thuộc một lượt khám ngoại trú tại khoa khám.

ORC

Bản tin xác định chỉ định có mã ORD12345 và đang được xử lý theo trạng thái tương ứng.

OBR

Chỉ định là xét nghiệm công thức máu, mã CBC.

OBX

Kết quả Hemoglobin là 13.2 g/dL, với khoảng tham chiếu 12.0–16.0.

Toàn bộ bản tin đang kể một câu chuyện:

LIS gửi cho HIS/EMR kết quả xét nghiệm công thức máu của người bệnh Nguyễn Văn An, thuộc lượt khám ngoại trú, trong đó Hemoglobin có giá trị 13.2 g/dL.

 

 

Luồng dữ liệu từ LIS về HIS/EMR

Trong vận hành thực tế, bản tin thường đi theo một chuỗi như sau:

Ở phía kỹ thuật, hệ thống tích hợp có thể kiểm tra:

• Mã người bệnh có tồn tại không.

• Mã lượt khám có khớp không.

• Mã order có đúng không.

• Mã xét nghiệm có nằm trong danh mục không.

• Kiểu dữ liệu của OBX có phù hợp không.

• Kết quả đã được xác nhận hay chưa.

• Bản tin có được hệ thống nhận trả ACK không.

Điểm quan trọng là bản tin phải đúng cả về kỹ thuật lẫn nghiệp vụ. Một bản tin đúng cú pháp nhưng gắn sai người bệnh vẫn là một bản tin không đạt yêu cầu.

Cách nhớ nhanh cấu trúc HL7

Có thể ghi nhớ theo sáu câu hỏi:

Hoặc sử dụng chuỗi tiếng Anh:

Tương ứng:

Những lưu ý khi phân tích bản tin HL7

Không mặc định mọi hệ thống dùng cùng profile

Hai hệ thống cùng tuyên bố hỗ trợ HL7 v2 chưa chắc sử dụng hoàn toàn giống nhau. Có thể khác về phiên bản, trường bắt buộc, mã cục bộ hoặc quy tắc xử lý.

Vì vậy, khi triển khai cần có:

• Tài liệu interface specification.

• Message profile.

• Bảng ánh xạ dữ liệu.

• Danh mục mã dùng chung.

• Bộ dữ liệu kiểm thử.

• Quy tắc ACK và xử lý lỗi.

Không chỉ kiểm tra bản tin có truyền được hay không

Cần kiểm tra cả kết quả cuối cùng:

• Dữ liệu có đến đúng hệ thống không?

• Có gắn đúng người bệnh không?

• Có gắn đúng lượt khám không?

• Có hiển thị đúng xét nghiệm không?

• Đơn vị và khoảng tham chiếu có chính xác không?

• Kết quả có được lưu vào hồ sơ chính thức không?

Phân biệt dữ liệu kỹ thuật và ý nghĩa lâm sàng

HL7 chỉ giúp truyền dữ liệu theo cấu trúc. Việc diễn giải kết quả và đưa ra quyết định lâm sàng vẫn thuộc về người có chuyên môn.

Trong bài viết này, giá trị Hemoglobin chỉ được dùng để minh họa cách đọc bản tin, không phải hướng dẫn chẩn đoán hoặc đánh giá sức khỏe.

Kết luận

Bản tin HL7 v2 không phải là một chuỗi ký tự hỗn độn. Đó là dữ liệu y tế được tổ chức thành các Segment có vai trò riêng.

Khi đọc theo trình tự:

chúng ta có thể hiểu được:

• Hệ thống nào gửi dữ liệu.

• Dữ liệu thuộc người bệnh nào.

• Người bệnh thuộc lượt khám nào.

• Chỉ định nào đang được xử lý.

• Cần thực hiện xét nghiệm gì.

• Kết quả thu được là gì.

Nắm được cấu trúc này là bước đầu quan trọng khi làm việc với tích hợp HIS, LIS, RIS, PACS và EMR. Tuy nhiên, trong dự án thực tế, cần đọc thêm message profile, bảng mã và quy tắc triển khai của từng hệ thống.

Ở bài tiếp theo, chúng ta sẽ đi sâu hơn vào cấu trúc:

và giải thích ý nghĩa của các ký tự |, ^, ~, \, & trong HL7 v2.

Theo dõi chuỗi “HL7 từ cơ bản đến ứng dụng thực tế” của SAVINA ONE.

#HL7 #HL7v2 #HealthcareIntegration #Interoperability #HIS #EMR #LIS #RIS #PACS #FHIR #DICOM #HealthcareIT #DigitalHealth #HealthInformatics #SAVINAONE