Bài 1.17. XML2 — Liều dùng, cách dùng, số lượng, thời gian và thông tin chỉ định

Nếu Bài 1.15 trả lời “thuốc gì?” và Bài 1.16 trả lời “thuốc đó có căn cứ pháp lý, mua sắm nào?”, thì nhóm trường của bài này trả lời:

Thuốc được chỉ định như thế nào, cho bao nhiêu, tại khoa nào, do ai chỉ định, khi nào ra y lệnh và khi nào thực hiện?

Đây là nhóm dữ liệu rất quan trọng để nối danh mục thuốc với thực hành điều trị thực tế.

1. LIEU_DUNG — mô tả chế độ dùng thuốc

LIEU_DUNG không chỉ ghi một con số như “2 viên”. Bảng 2 yêu cầu thể hiện liều theo một cấu trúc có ngữ cảnh điều trị.

Đối với ngoại trú, liều được mô tả theo nguyên tắc:

số lượng/lần × số lần/ngày × số ngày
[tổng số thuốc/ngày]

Đối với nội trú, cấu trúc cơ bản là:

số lượng/lần × số lần/ngày × 01 ngày
[tổng số thuốc/ngày]

Nếu liều thay đổi giữa các lần trong ngày hoặc thay đổi theo từng ngày thì phải thể hiện chi tiết. Với thuốc thang YHCT có hướng dẫn riêng; đối với thuốc dùng ngoài như nhỏ giọt, bôi mà không xác định chính xác lượng mỗi lần, phần diễn giải cập nhật cho phép ghi số lần sử dụng trong ngày và số ngày sử dụng.

Do đó:

LIEU_DUNG là thông tin về chế độ điều trị, không phải trường để sao chép SO_LUONG.

2. CACH_DUNG — lời dặn hoặc hướng dẫn sử dụng

CACH_DUNG có kích thước tối đa 1024 ký tự và được quy định là lời dặn của thầy thuốc trên đơn thuốc hoặc y lệnh.

Hai trường cần phân biệt:

LIEU_DUNG
→ dùng bao nhiêu, bao nhiêu lần, bao lâu

CACH_DUNG
→ sử dụng như thế nào

Ví dụ tổng quát:

LIEU_DUNG:
1 viên/lần × 2 lần/ngày × 5 ngày

CACH_DUNG:
Uống sau ăn sáng và tối

Nếu HIS chỉ lưu một chuỗi chung cho cả hai rồi xuất cùng nội dung vào hai field, XML có thể đúng cú pháp nhưng chất lượng dữ liệu thấp.

3. SO_LUONG — số lượng thực tế sử dụng

SO_LUONG là trường số, kích thước tối đa 10, ghi số lượng thuốc thực tế sử dụng cho người bệnh, được làm tròn đến tối đa 3 chữ số thập phân và dùng dấu chấm làm dấu phân cách thập phân.

Điểm quan trọng là phải đọc SO_LUONG cùng:

DON_VI_TINH
LIEU_DUNG
CACH_DUNG
NGAY_YL
NGAY_TH_YL

Ví dụ nếu:

DON_VI_TINH = viên
SO_LUONG    = 10

thì số lượng này phải được hiểu là 10 viên, không phải 10 hộp hay 10 vỉ.

Vì vậy, trước khi kiểm tra số lượng bất thường phải bảo đảm đơn vị tính đã được chuẩn hóa đúng như Bài 1.15.

4. Không nên dùng một công thức đơn giản để suy ra mọi SO_LUONG

Trong một số đơn thuốc ngoại trú, có thể dễ dàng kiểm tra:

liều/lần × số lần/ngày × số ngày
        ↕
SO_LUONG

Nhưng không nên biến quan hệ này thành một quy tắc tuyệt đối cho mọi thuốc.

Các trường hợp nội trú, thay đổi liều, thuốc tiêm truyền, thuốc dùng ngoài, thuốc thang hoặc những tình huống chuyên môn đặc thù có thể cần logic riêng.

Do đó một hệ thống tốt nên:

tính được số lượng kỳ vọng khi đủ dữ kiện; nếu chưa đủ dữ kiện thì cảnh báo rà soát thay vì kết luận sai.

5. MA_KHOA — thuốc được chỉ định tại khoa nào?

MA_KHOA ghi mã khoa nơi người bệnh được chỉ định sử dụng thuốc. Trong bảng đối chiếu hiện hành, kích thước trường đã được cập nhật lên tối đa 50 ký tự và có ghi nhận việc áp dụng danh mục khoa theo cập nhật năm 2026.

Trường này tạo ra một quan hệ rất hữu ích:

XML1.MA_KHOA
       ↕
XML2.MA_KHOA
       ↕
khoa thực tế ra y lệnh

Không phải lúc nào XML2.MA_KHOA cũng nhất thiết giống khoa tổng hợp ở XML1, vì một đợt điều trị có thể đi qua nhiều khoa. Điều cần kiểm tra là:

Tại thời điểm thuốc được chỉ định, người bệnh có thực sự thuộc khoa hoặc bối cảnh chuyên môn tương ứng hay không?

Đây là kiểm tra theo timeline, không phải kiểm tra bằng nhau đơn thuần.

6. MA_BAC_SI — ai chỉ định thuốc?

Đây là một trong những field quan trọng nhất để kiểm tra phạm vi hành nghề và trách nhiệm chỉ định.

Theo phần diễn giải sửa đổi tại Quyết định 3176, MA_BAC_SI ghi mã bác sĩ khám, chỉ định thuốc dựa trên số Giấy phép hành nghề hoặc Chứng chỉ hành nghề còn hiệu lực theo trường hợp áp dụng.

Chuẩn còn quy định các tình huống đặc biệt như KCB từ xa/hỗ trợ KCB từ xa, bác sĩ đang trong thời gian thực hành và người hành nghề được huy động, điều động; mỗi tình huống có quy tắc mã hóa riêng.

Do đó rule không nên chỉ hỏi:

MA_BAC_SI có rỗng không?

mà phải kiểm tra sâu hơn:

Mã có tồn tại?
        ↓
GPHN/CCHN có phù hợp thời điểm?
        ↓
người chỉ định có thuộc cơ sở/khoa phù hợp?
        ↓
tình huống đặc biệt có được mã hóa đúng?

7. MA_DICH_VU — nối thuốc với dịch vụ kỹ thuật

MA_DICH_VU là field bắt buộc có điều kiện, không phải dòng thuốc nào cũng phải có.

Bảng 2 yêu cầu ghi mã DVKT trong những trường hợp như thuốc được sử dụng để thực hiện DVKT và được thanh toán riêng do chưa cấu thành trong giá dịch vụ; một số xét nghiệm liên quan máu/chế phẩm máu; thuốc thanh toán ngoài giá dịch vụ cận lâm sàng thực hiện ở cơ sở khác; cùng các tình huống kỹ thuật có quy ước mã hóa đặc thù.

Như vậy:

XML2.MA_DICH_VU
        ↕
XML3.MA_DICH_VU

là một mối quan hệ rất quan trọng.

Ví dụ, nếu thuốc cản quang được đề nghị thanh toán riêng cho một DVKT nhưng không tìm thấy dịch vụ tương ứng trong XML3, hệ thống nên cảnh báo để kiểm tra.

Ngược lại, thuốc uống điều trị thông thường không gắn với một DVKT cụ thể thì không nên ép MA_DICH_VU phải có giá trị.

8. NGAY_YL — thời điểm ra y lệnh

NGAY_YL có 12 ký tự theo cấu trúc:

yyyymmddHHmm

Ví dụ:

202610131430

tương ứng 14 giờ 30 phút ngày 13/10/2026.

Bảng 2 xác định đây là thời điểm ra y lệnh thuốc. Phần hướng dẫn gốc còn có quy định liên quan y lệnh vào ngày nghỉ, lễ, Tết; nội dung bổ sung trước đây về hội chẩn từ xa tại Quyết định 4750 đã được Quyết định 3176 bãi bỏ.

Điểm quan trọng là NGAY_YL phải nằm trong dòng thời gian hợp lý của đợt KCB.

Ví dụ về quan hệ cần kiểm tra:

XML1.NGAY_VAO
       ≤
XML2.NGAY_YL
       ≤
XML1.NGAY_RA

nhưng khi triển khai rule vẫn cần xét đúng loại hình KCB, thuốc kê mang về và các tình huống được quy định.

9. NGAY_TH_YL — thời điểm thực hiện y lệnh

NGAY_TH_YL cũng có 12 ký tự:

yyyymmddHHMM

và phản ánh thời điểm thực hiện y lệnh thuốc.

Điểm rất quan trọng trong sửa đổi tại Quyết định 3176 là:

Trường này chỉ bắt buộc khi thuốc được sử dụng tại cơ sở KBCB.

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

Thuốc sử dụng tại bệnh viện
→ cần NGAY_TH_YL theo điều kiện áp dụng

với:

Thuốc kê/cấp để người bệnh sử dụng ngoài cơ sở
→ không thể mặc định yêu cầu NGAY_TH_YL giống thuốc dùng tại viện

Đây là một ví dụ rất rõ của required-if.

10. Quan hệ NGAY_YL và NGAY_TH_YL

Trong tình huống thuốc sử dụng tại cơ sở, quan hệ cơ bản là:

NGAY_YL
   ↓
ra y lệnh
   ↓
NGAY_TH_YL
thực hiện y lệnh

Thông thường cần kiểm tra:

NGAY_TH_YL >= NGAY_YL

Nếu thời điểm thực hiện lại trước thời điểm ra y lệnh, đây là một bất thường dữ liệu mạnh cần rà soát.

Tuy nhiên trước khi kết luận cần xem dữ liệu nguồn, cách HIS ghi nhận y lệnh và các tình huống hiệu chỉnh hợp lệ.

11. Một dòng thuốc nên được đọc như một sự kiện điều trị

Các field của bài này không nên được xem rời rạc.

Một dòng XML2 có thể được hiểu:

MA_BAC_SI
    ↓
ai chỉ định?

MA_KHOA
    ↓
ở đâu?

NGAY_YL
    ↓
khi nào ra y lệnh?

LIEU_DUNG + CACH_DUNG
    ↓
dùng như thế nào?

SO_LUONG
    ↓
bao nhiêu?

NGAY_TH_YL
    ↓
khi nào thực hiện?

MA_DICH_VU
    ↓
có gắn với DVKT nào không?

Đây chính là một medication event trong dòng thời gian điều trị.

12. Những quan hệ rất phù hợp cho tiền giám định

Thay vì chỉ kiểm tra field rỗng, Dr5-XML nên kiểm tra các quan hệ:

LIEU_DUNG
+ CACH_DUNG
+ DON_VI_TINH
↔ SO_LUONG

MA_KHOA
↔ khoa điều trị tại thời điểm y lệnh

MA_BAC_SI
↔ danh mục nhân viên + GPHN + thời gian hành nghề

NGAY_YL
↔ NGAY_VAO / NGAY_RA

NGAY_TH_YL
↔ NGAY_YL

MA_DICH_VU
↔ XML3.MA_DICH_VU

Trong thiết kế catalog-first, các metadata và điều kiện nên nằm ở những danh mục như:

dr5_xml_required
dr5_staff_license
dr5_department
dr5_drug_dose_rule
dr5_time_relation
dr5_drug_service_relation

Rule engine xử lý logic chung; khi danh mục khoa, nhân viên, điều kiện field hoặc quy định thay đổi thì cập nhật danh mục thay vì sửa hàng loạt code.

Kết luận

Nhóm trường này biến một mặt hàng thuốc thành một sự kiện sử dụng thuốc thực tế:

ai chỉ định → tại khoa nào → lúc nào → liều bao nhiêu → dùng thế nào → số lượng bao nhiêu → lúc nào thực hiện → có liên quan DVKT nào.

Điểm quan trọng nhất là:

Không nên kiểm tra LIEU_DUNG, SO_LUONG, MA_BAC_SI, NGAY_YL hay NGAY_TH_YL độc lập. Giá trị của chúng nằm ở mối quan hệ với nhau và với dòng thời gian của đợt KCB.

Đây cũng là nhóm dữ liệu rất phù hợp để phát triển cảnh báo ngay tại thời điểm kê đơn/y lệnh, trước khi sai sót đi đến bước trích chuyển XML.