Bài 1.25. XML5 — Chỉ tiêu chi tiết diễn biến lâm sàng: cấu trúc và diễn giải từng trường

XML5 là Bảng 5 – Chỉ tiêu chi tiết diễn biến lâm sàng. Khác XML2–XML3 tập trung vào thuốc, dịch vụ, vật tư và chi phí, XML5 phản ánh diễn biến chuyên môn của người bệnh theo thời gian: tình trạng lâm sàng, giai đoạn bệnh, hội chẩn, phẫu thuật/thủ thuật, thời điểm ghi nhận và người thực hiện ghi chép.

XML5 vì vậy có giá trị đặc biệt khi cần trả lời:

Tại thời điểm một thuốc hoặc DVKT được chỉ định, hồ sơ điện tử có diễn biến lâm sàng nào giải thích cho quyết định chuyên môn đó hay không?

Tuy nhiên, XML5 không phải toàn bộ bệnh án điện tử và không nên được xem là nguồn chứng cứ duy nhất để kết luận một dịch vụ có hợp lý hoặc được thanh toán hay không.

1. Cấu trúc đầy đủ XML5

XML5 gồm 9 trường dữ liệu:

Bảng 5 cũng quy định phạm vi gửi riêng, không phải mọi hồ sơ KCB đều mặc nhiên phải có XML5. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

2. Khi nào phải gửi XML5?

Ghi chú của Bảng 5 quy định cơ sở KCB chỉ gửi bảng này trong các trường hợp người bệnh:

• điều trị ngoại trú với MA_LOAI_KCB thuộc các mã được nêu là 02, 05, 08;
• điều trị nội trú;
• điều trị nội trú ban ngày;
• điều trị lưu tại trạm y tế tuyến xã hoặc phòng khám đa khoa khu vực;
• điều trị nội trú dưới 4 giờ. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Điều này dẫn tới một nguyên tắc tiền giám định quan trọng:

Không thấy XML5 không đồng nghĩa hồ sơ thiếu dữ liệu trong mọi trường hợp. Trước hết phải xác định loại hình KCB có thuộc phạm vi phải gửi Bảng 5 hay không.

Khi các danh mục MA_LOAI_KCB thay đổi theo thời gian, rule cũng phải sử dụng đúng phiên bản danh mục có hiệu lực tại ngày KCB.

3. MA_LK, STT và tính chất chuỗi thời gian của XML5

MA_LK dùng để nối toàn bộ các dòng XML5 với đợt KCB tương ứng.

STT là số thứ tự tăng từ 1 đến hết trong lần gửi dữ liệu. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Không nên hiểu rằng một đợt KCB chỉ có một dòng XML5.

Ngược lại, diễn biến bệnh thường thay đổi theo thời gian, nên một hồ sơ có thể có nhiều dòng:

thời điểm 1 → diễn biến 1

thời điểm 2 → diễn biến 2

thời điểm 3 → hội chẩn hoặc thay đổi điều trị

thời điểm 4 → phẫu thuật/thủ thuật

XML5 vì vậy nên được nhìn như một clinical timeline, chứ không phải một bản tóm tắt duy nhất của toàn bộ quá trình điều trị.

4. DIEN_BIEN_LS — trường trung tâm của XML5

DIEN_BIEN_LS ghi diễn biến lâm sàng của người bệnh trong lần khám và/hoặc nội dung chăm sóc của nhân viên y tế. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Theo phần bổ sung trước đó, nếu trong diễn biến có đo các chỉ số sinh tồn thì có quy ước thể hiện các thông tin như:

• mạch;
• nhiệt độ;
• huyết áp;
• nhịp thở;
• SpO₂;
• chế độ hộ lý.

Các giá trị này có thể được ghi trong chuỗi diễn biến theo quy ước của chuẩn. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Điểm quan trọng là DIEN_BIEN_LS có bản chất văn bản lâm sàng có cấu trúc một phần.

Nó có thể cung cấp căn cứ rất hữu ích để đối chiếu:

triệu chứng → chẩn đoán → chỉ định thuốc/DVKT → đáp ứng điều trị.

Nhưng không nên biến toàn bộ nội dung tự do của trường này thành các rule từ khóa cứng. Cùng một tình trạng lâm sàng có thể được mô tả bằng nhiều cách khác nhau.

5. GIAI_DOAN_BENH, HOI_CHAN, PHAU_THUAT — các trường có điều kiện

Ba field này không phải lúc nào cũng phải có giá trị.

GIAI_DOAN_BENH

Chỉ ghi khi cơ sở KBCB đã xác định giai đoạn bệnh. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Vì vậy:

GIAI_DOAN_BENH rỗng không tự động là lỗi.

Chỉ nên yêu cầu khi bệnh hoặc quy trình chuyên môn thực sự có thông tin giai đoạn cần ghi nhận.

HOI_CHAN

Ghi kết quả hội chẩn nếu có. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Do đó cần phân biệt:

không có hội chẩn

với

có hội chẩn nhưng XML không phản ánh.

Muốn xác định trường hợp thứ hai phải dựa thêm vào dữ liệu bệnh án hoặc quy trình hội chẩn, không thể suy ra chỉ từ XML.

PHAU_THUAT

Ghi mô tả cách thức phẫu thuật hoặc thủ thuật nếu có. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Đây là trường rất hữu ích để đối chiếu với XML3 khi có một DVKT phẫu thuật/thủ thuật được đề nghị thanh toán.

Tuy nhiên, việc XML3 có mã PTTT nhưng một dòng XML5 cụ thể không chứa PHAU_THUAT chưa đủ để tự động kết luận dịch vụ không thực hiện. Cần xem toàn bộ chuỗi XML5 và bệnh án nguồn.

6. THOI_DIEM_DBLS — trục thời gian để nối lâm sàng với chỉ định

THOI_DIEM_DBLS gồm 12 ký tự theo cấu trúc:

yyyymmddHHMM

và phản ánh thời điểm diễn biến lâm sàng được ghi nhận. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Đây là field làm cho XML5 trở nên đặc biệt hữu ích khi đối chiếu với XML2 và XML3.

Có thể xây dựng timeline:

XML5.THOI_DIEM_DBLS

→ tình trạng người bệnh

→ XML2.NGAY_YL của thuốc

→ XML3.NGAY_YL của DVKT

→ thực hiện điều trị/DVKT

→ diễn biến tiếp theo trong XML5.

Ví dụ, một dịch vụ được chỉ định ở thời điểm 14:00 có thể được rà soát xem trước đó có diễn biến lâm sàng nào làm xuất hiện nhu cầu chỉ định hay không.

Nhưng đây nên là kiểm tra tính hợp lý theo thời gian, không phải yêu cầu máy móc rằng phải có một dòng XML5 ngay trước mọi y lệnh.

7. NGUOI_THUC_HIEN — ai ghi nhận diễn biến?

Ban đầu trường này sử dụng mã định danh y tế của nhân viên ghi chép.

Quyết định 3176 sửa toàn bộ diễn giải theo hướng:

• người ghi chép là nhân viên y tế phải đăng ký hành nghề: ghi theo số GPHN;
• nếu nhân viên y tế thuộc trường hợp không phải đăng ký hành nghề: ghi CCCD hoặc số định danh cá nhân;
• nếu nhiều người cùng thực hiện ghi chép, người thực hiện chính được ghi trước, các người còn lại phân cách bằng dấu chấm phẩy. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Do đó NGUOI_THUC_HIEN XML5 có ý nghĩa khác với cùng tên field ở XML3.

Trong XML3:

NGUOI_THUC_HIEN = người thực hiện DVKT.

Trong XML5:

NGUOI_THUC_HIEN = người thực hiện ghi chép diễn biến lâm sàng.

Không nên mặc định hai giá trị phải giống nhau.

8. XML5 nên được đối chiếu với XML1, XML2 và XML3 như thế nào?

XML5 có giá trị nhất khi được đặt vào toàn bộ hồ sơ.

XML1 cung cấp chẩn đoán, loại hình KCB, thời gian vào–ra viện và kết quả điều trị.

XML2 cung cấp thuốc, liều dùng, thời điểm y lệnh và thực hiện.

XML3 cung cấp DVKT, người chỉ định, thời điểm chỉ định/thực hiện/kết quả.

XML5 cung cấp bối cảnh lâm sàng giải thích cho những quyết định đó.

Ví dụ về các quan hệ cần rà soát:

Những quan hệ này rất hữu ích cho tiền giám định chuyên môn, nhưng thường thuộc nhóm WARN_REVIEW hơn là lỗi kỹ thuật chắc chắn.

9. Không nên dùng XML5 để “giám định bằng từ khóa”

Một nguy cơ lớn khi tự động hóa là tạo rule như:

Không thấy chữ “đau” → không được chỉ định thuốc giảm đau.

hoặc:

Không thấy tên một bệnh trong DIEN_BIEN_LS → dịch vụ liên quan bệnh đó không hợp lý.

Cách này rất dễ tạo cảnh báo sai.

Thông tin chuyên môn có thể nằm ở:

• chẩn đoán XML1/XML3;
• diễn biến XML5;
• phiếu chỉ định;
• kết quả CLS;
• biên bản hội chẩn;
• tường trình PTTT;
• bệnh án gốc.

Vì vậy XML5 nên được xem là một lớp chứng cứ, không phải toàn bộ chứng cứ.

10. Thiết kế tiền giám định Dr5-XML

Không cần tạo engine riêng cho XML5. Có thể tiếp tục sử dụng sáu danh mục chuẩn:

Đặc biệt, điều kiện gửi XML5 nên là một rule applicability độc lập:

loại hình KCB → Bảng 5 có áp dụng hay không → nếu áp dụng mới kiểm tra nội dung.

Điều này tránh lỗi phổ biến “không có XML5 = sai” cho tất cả hồ sơ.

Kết luận

XML5 có thể được hiểu theo chuỗi:

Thời điểm → diễn biến lâm sàng → giai đoạn bệnh/hội chẩn/PTTT nếu có → người ghi nhận.

Ba nguyên tắc quan trọng nhất là:

XML5 là dòng thời gian lâm sàng, không phải bảng chi phí.

GIAI_DOAN_BENH, HOI_CHAN, PHAU_THUAT là các trường có điều kiện, không phải mọi dòng đều phải có.

Giá trị lớn nhất của XML5 nằm ở việc đối chiếu diễn biến lâm sàng với thuốc, DVKT và các mốc thời gian ở XML2–XML3; nhưng sự không tương thích thường cần rà soát chuyên môn trước khi kết luận ảnh hưởng thanh toán.

Vì vậy XML5 là một nguồn dữ liệu quan trọng để Dr5-XML chuyển từ kiểm tra cú pháp sang tiền giám định có ngữ cảnh lâm sàng, đồng thời vẫn phải giữ ranh giới rõ giữa cảnh báo dữ liệu, cảnh báo chuyên môn và kết luận xuất toán.