Bài 1.18. XML2 — Đơn giá, tỷ lệ thanh toán, mức hưởng, thành tiền và phân bổ nguồn chi trả

Sau khi đã xác định thuốc gì, dùng như thế nào và căn cứ cung ứng nào, XML2 tiếp tục trả lời câu hỏi tài chính quan trọng nhất:

Dòng thuốc này có giá bao nhiêu, phần nào thuộc phạm vi BHYT, quỹ BHYT thanh toán bao nhiêu, người bệnh chịu bao nhiêu và có nguồn tài chính nào khác cùng chi trả hay không?

Đây là nhóm field có khả năng kiểm tra tự động rất cao vì giữa các trường tồn tại nhiều công thức và quan hệ số học trực tiếp.

1. Các trường tài chính chính của một dòng XML2

Các trường từ PHAM_VI đến T_BHTT được Bảng 2 quy định liên tiếp và có nhiều công thức tính trực tiếp. QUYẾT ĐỊNH 3176.

2. PHAM_VI — trước hết phải xác định thuốc thuộc phạm vi nào

Sau sửa đổi tại Quyết định 3176, PHAM_VI được diễn giải:

Nội dung sửa đổi này thay thế cách diễn giải trước đó tại Quyết định 130 và phần đính chính tại Quyết định 4750.

PHAM_VI vì vậy là một field định hướng cho các bước tính sau. Một thuốc được ghi PHAM_VI = 2 nhưng đồng thời lại tính đầy đủ phần quỹ BHYT thanh toán là tổ hợp cần được kiểm tra.

3. TYLE_TT_BH — tỷ lệ thanh toán của chính thuốc

TYLE_TT_BH không phải là mức hưởng thẻ BHYT của người bệnh.

Đây là tỷ lệ thanh toán BHYT áp dụng cho thuốc.

Ví dụ:

TYLE_TT_BH = 50

nghĩa là thuốc chỉ được tính 50% theo quy định áp dụng cho thuốc đó.

Nếu thuốc không có quy định tỷ lệ giới hạn thì ghi 100; nếu không thuộc phạm vi thanh toán của quỹ BHYT thì ghi 0. QUYẾT ĐỊNH 3176.

Phải phân biệt rõ:

TYLE_TT_BH
= tỷ lệ thanh toán của thuốc

MUC_HUONG
= mức hưởng BHYT của người bệnh đối với dòng chi phí

Hai tỷ lệ này có thể đồng thời tác động đến số tiền BHXH thanh toán.

4. DON_GIA — giá phải cùng đơn vị với SO_LUONG

DON_GIA là đơn giá thuốc, làm tròn tối đa 3 chữ số thập phân. Bảng 2 mô tả đây là giá theo hóa đơn mua vào của cơ sở KBCB và có quy định riêng đối với thuốc tự bào chế, thuốc cổ truyền, thuốc phóng xạ và các trường hợp đặc thù. QUYẾT ĐỊNH 3176.

Một nguyên tắc rất quan trọng là:

Đơn giá phải tương ứng với đúng DON_VI_TINH và SO_LUONG.

Nếu thuốc mua theo lọ nhưng thực tế sử dụng và khai báo theo ml hoặc UI, bảng chỉ tiêu yêu cầu đơn giá phải được chia nhỏ tương ứng với đơn vị sử dụng. QUYẾT ĐỊNH 3176.

Do đó, một trong những lỗi nguy hiểm là:

SO_LUONG tính theo ml
nhưng
DON_GIA lại là giá cả lọ

Khi đó mọi công thức phía sau đều sai dù XML vẫn hợp lệ về kỹ thuật.

5. THANH_TIEN_BV — giá trị toàn bộ dòng thuốc

Công thức trực tiếp:

THANH_TIEN_BV
=
SO_LUONG × DON_GIA

và làm tròn đến 2 chữ số thập phân. QUYẾT ĐỊNH 3176.

Ví dụ:

SO_LUONG = 10
DON_GIA  = 5.000

THANH_TIEN_BV = 50.000

Đây là giá trị của dòng thuốc theo giá bệnh viện, chưa phải số tiền BHYT sẽ thanh toán.

6. THANH_TIEN_BH — phần giá trị thuộc phạm vi BHYT

Công thức:

THANH_TIEN_BH
=
SO_LUONG × DON_GIA × TYLE_TT_BH / 100

QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Ví dụ:

THANH_TIEN_BV = 100.000
TYLE_TT_BH    = 50

thì:

THANH_TIEN_BH = 50.000

Phần còn lại 50.000 đồng nằm ngoài tỷ lệ thanh toán của quỹ đối với thuốc đó.

Điểm cần ghi nhớ:

THANH_TIEN_BH vẫn chưa phải T_BHTT.

Còn phải áp dụng MUC_HUONG của người bệnh và xử lý T_NGUONKHAC nếu có.

7. MUC_HUONG — mức hưởng của người bệnh ở dòng chi phí

MUC_HUONG mô tả mức hưởng BHYT áp dụng cho từng dòng chi phí.

Bảng chỉ tiêu ban đầu đưa ra các mức và ví dụ theo quy định BHYT tương ứng thời kỳ ban hành; bảng đối chiếu của dự án hiện còn ghi nhận cập nhật năm 2026 tăng kích thước tối đa của field này lên 4 ký tự. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Về nguyên tắc dữ liệu, phải phân biệt:

TYLE_TT_BH
→ thuốc được tính bao nhiêu %

MUC_HUONG
→ trong phần được tính đó,
  người bệnh được quỹ hưởng bao nhiêu %

Khi xây rule cho hồ sơ thực tế năm 2026, MUC_HUONG phải được xác định theo quy định BHYT có hiệu lực tại ngày KCB, không nên hard-code toàn bộ ví dụ lịch sử trong Quyết định 130 vào engine.

8. T_BHTT — số tiền đề nghị BHXH thanh toán

Theo diễn giải sửa đổi tại Quyết định 3176:

T_BHTT
=
THANH_TIEN_BV
× TYLE_TT_BH / 100
× MUC_HUONG / 100

QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Do:

THANH_TIEN_BH
=
THANH_TIEN_BV × TYLE_TT_BH / 100

nên trong trường hợp chưa có nguồn khác:

T_BHTT
=
THANH_TIEN_BH × MUC_HUONG / 100

Ví dụ:

THANH_TIEN_BV = 1.000.000
TYLE_TT_BH    = 50
MUC_HUONG     = 80

thì:

THANH_TIEN_BH = 500.000
T_BHTT         = 400.000

Quỹ BHYT được đề nghị thanh toán 400.000 đồng, không phải 800.000 đồng và cũng không phải toàn bộ 1.000.000 đồng.

9. T_BNTT — người bệnh tự trả ngoài phạm vi BHYT

Theo diễn giải sửa đổi:

T_BNTT
=
THANH_TIEN_BV × (1 - TYLE_TT_BH / 100)

khi chưa xét nguồn khác. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Trong ví dụ trên:

THANH_TIEN_BV = 1.000.000
TYLE_TT_BH    = 50

thì:

T_BNTT = 500.000

Đây là phần ngoài phạm vi thanh toán của quỹ.

Không được nhầm T_BNTT với T_BNCCT.

10. T_BNCCT — người bệnh cùng chi trả trong phạm vi BHYT

Theo diễn giải sửa đổi tại Bảng 2:

T_BNCCT
=
THANH_TIEN_BV
- T_BHTT
- T_BNTT

trong trường hợp chưa phải điều chỉnh bởi T_NGUONKHAC. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Tiếp tục ví dụ:

THANH_TIEN_BV = 1.000.000
T_BNTT         = 500.000
T_BHTT         = 400.000

thì:

T_BNCCT = 100.000

Ta có:

1.000.000
=
500.000 T_BNTT
+ 100.000 T_BNCCT
+ 400.000 T_BHTT

Đây là một kiểm tra số học rất hữu ích.

11. T_NGUONKHAC — nguồn tài chính khác làm thay đổi phân bổ

XML2 chia nguồn khác thành bốn trường:

Tổng:

T_NGUONKHAC
=
T_NGUONKHAC_NSNN
+ T_NGUONKHAC_VTNN
+ T_NGUONKHAC_VTTN
+ T_NGUONKHAC_CL

QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Quyết định 3176 đã đơn giản hóa nguyên tắc phân bổ: khi T_NGUONKHAC > 0, số tiền này được giảm trừ lần lượt vào:

T_BNTT
→ T_BNCCT
→ T_BHTT

cho đến khi hết nguồn khác. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Đây là điểm cực kỳ quan trọng khi kiểm tra công thức.

Không nên tính:

T_BHTT + T_BNCCT + T_BNTT

theo công thức thông thường rồi bỏ qua T_NGUONKHAC.

12. Ví dụ có nguồn khác

Giả sử trước khi giảm trừ:

THANH_TIEN_BV = 1.000.000
TYLE_TT_BH    = 50
MUC_HUONG     = 80

T_BNTT        = 500.000
T_BNCCT       = 100.000
T_BHTT        = 400.000

Nếu:

T_NGUONKHAC = 550.000

thì theo thứ tự giảm trừ:

500.000
→ giảm hết T_BNTT

còn nguồn khác 50.000
→ giảm tiếp T_BNCCT

kết quả:

T_BNTT  = 0
T_BNCCT = 50.000
T_BHTT  = 400.000

Nếu nguồn khác tiếp tục lớn hơn, phần còn lại mới giảm vào T_BHTT.

Đây là lý do các rule thanh toán phải xử lý T_NGUONKHAC sau khi tính giá trị cơ sở, không thể chỉ dùng một phương trình duy nhất cho mọi record.

13. NGUON_CTRA không phải là T_NGUONKHAC

Hai khái niệm này rất dễ nhầm.

NGUON_CTRA là mã phân loại nguồn thuốc chi trả, gồm quỹ BHYT, dự án/viện trợ, chương trình mục tiêu quốc gia hoặc nguồn khác.

Trong khi:

T_NGUONKHAC là số tiền cụ thể do nguồn tài chính khác chi trả.

Bảng 2 quy định NGUON_CTRA bằng mã 1–4 tùy nguồn. QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Do đó:

NGUON_CTRA
= phân loại nguồn

T_NGUONKHAC
= giá trị tiền

Hai field cần được kiểm tra quan hệ với nhau, nhưng không đồng nghĩa.

14. MA_PTTT cũng là một khái niệm khác

MA_PTTT không nói ai trả tiền, mà nói phương thức thanh toán:

1 = Phí dịch vụ
2 = Định suất
3 = Trường hợp bệnh (DRG)

QUYẾT ĐỊNH 3176. CHUẨN DƯ…

Như vậy cần phân biệt ba chiều:

PHAM_VI
→ thuốc có thuộc phạm vi BHYT?

NGUON_CTRA
→ nguồn nào chi trả?

MA_PTTT
→ thanh toán theo phương thức nào?

Đây là ba thuộc tính khác nhau.

15. Chuỗi tính toán của một dòng thuốc

Có thể hình dung toàn bộ logic:

SO_LUONG
   ×
DON_GIA
   ↓
THANH_TIEN_BV
   ×
TYLE_TT_BH
   ↓
THANH_TIEN_BH
   ×
MUC_HUONG
   ↓
T_BHTT tạm tính

Song song:

THANH_TIEN_BV
-
THANH_TIEN_BH
↓
T_BNTT

và phần còn lại trong phạm vi BHYT:

T_BNCCT

Sau đó:

T_NGUONKHAC
↓
giảm T_BNTT
↓
giảm T_BNCCT
↓
giảm T_BHTT

Đây là chuỗi phù hợp để tiền giám định thực hiện theo từng bước.

16. Những lỗi đặc biệt phù hợp để phát hiện tự động

Nhóm này nên được kiểm tra ở cả cấp dòng và cấp tổng hợp.

Ở cấp dòng XML2, có thể kiểm tra công thức SO_LUONG × DON_GIA, TYLE_TT_BH, MUC_HUONG, phân bổ T_BNTT/T_BNCCT/T_BHTT, tổng các nguồn khác và logic PHAM_VI.

Sau đó ở cấp hồ sơ:

Σ XML2.THANH_TIEN_BV
↔ XML1.T_THUOC / T_TONGCHI_BV

và:

Σ XML2.T_BHTT
↔ phần tổng hợp tương ứng ở XML1

Nếu dòng chi tiết sai nhưng tổng XML1 tình cờ vẫn khớp do các sai lệch bù trừ, chỉ kiểm tra tổng sẽ không phát hiện được.

17. Thiết kế rule cho Dr5-XML

Nhóm này rất phù hợp với generic rule thay vì code từng trường riêng.

Nên tách:

dr5_cost_formula
dr5_payment_scope
dr5_bhyt_rate
dr5_benefit_rule
dr5_other_funding_rule
dr5_payment_method
dr5_payment_source
dr5_legal_basis

Rule engine chỉ cần thực hiện quy trình:

Xác định ngày KCB
        ↓
lấy rule có hiệu lực
        ↓
xác định PHAM_VI
        ↓
kiểm tra TYLE_TT_BH
        ↓
kiểm tra DON_GIA
        ↓
tính THANH_TIEN_BV
        ↓
tính phần BHYT
        ↓
áp MUC_HUONG
        ↓
áp T_NGUONKHAC
        ↓
đối chiếu T_BNTT / T_BNCCT / T_BHTT

Cách này đặc biệt quan trọng với MUC_HUONG, tỷ lệ thanh toán và các điều kiện BHYT vì đây là các nội dung có thể thay đổi theo thời gian.

Kết luận

Một dòng thuốc XML2 có thể được hiểu theo bốn tầng tài chính:

Giá trị phát sinh: SO_LUONG × DON_GIA = THANH_TIEN_BV
Phạm vi BHYT: TYLE_TT_BH → THANH_TIEN_BH
Quyền lợi người bệnh: MUC_HUONG → T_BHTT, T_BNCCT, T_BNTT
Nguồn khác: T_NGUONKHAC tiếp tục điều chỉnh phân bổ cuối cùng.

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

TYLE_TT_BH và MUC_HUONG là hai tỷ lệ khác nhau; T_BNTT và T_BNCCT là hai khoản khác nhau; NGUON_CTRA, T_NGUONKHAC và MA_PTTT cũng là ba khái niệm khác nhau.

Khi các khái niệm này được tách đúng, việc kiểm tra công thức XML2 có thể tự động hóa ở mức rất cao và trở thành một trong những lớp tiền giám định hiệu quả nhất.