Website được thiết kế tối ưu cho thành viên chính thức. Hãy Đăng nhập hoặc Đăng ký để truy cập đầy đủ nội dung và chức năng. Nội dung bạn cần không thấy trên website, có thể do bạn chưa đăng nhập. Nếu là thành viên của website, bạn cũng có thể yêu cầu trong nhóm Zalo "BHYT" các nội dung bạn quan tâm.

Bài 1.13. XML1 — Nhóm trường tổng hợp chi phí và quan hệ với XML2, XML3

XML

Chi phí bệnh viện, chi phí BHYT, các bên chi trả và nguồn khác

Nhóm trường chi phí của XML1 là phần tổng hợp tài chính của toàn bộ đợt KCB. Các con số này không nên được tạo độc lập tại XML1 mà phải có khả năng đối chiếu ngược xuống từng dòng thuốc trong XML2 và từng dòng dịch vụ kỹ thuật, vật tư y tế trong XML3.

Có thể hình dung theo nguyên tắc:

XML2 + XML3 tính chi tiết từng khoản → XML1 tổng hợp toàn bộ đợt KCB.

Đây là một trong những nhóm dữ liệu có thể kiểm tra tự động rất hiệu quả vì phần lớn quan hệ là tổng hợp, công thức và đối chiếu chéo giữa các bảng.


1. Các trường tổng hợp chi phí trong XML1

STT XML1TrườngÝ nghĩa chính
45T_THUOCTổng thành tiền thuốc và các khoản liên quan thuộc XML2
46T_VTYTTổng thành tiền vật tư y tế trong XML3
47T_TONGCHI_BVTổng chi phí theo giá bệnh viện
48T_TONGCHI_BHTổng chi phí trong phạm vi quỹ BHYT thanh toán
49T_BNTTTổng số tiền người bệnh tự trả ngoài phạm vi BHYT
50T_BNCCTTổng số tiền người bệnh cùng chi trả
51T_BHTTTổng số tiền cơ sở đề nghị BHXH thanh toán
52T_NGUONKHACTổng số tiền do các nguồn khác chi trả
53T_BHTT_GDVPhần quỹ BHYT thanh toán thuộc nhóm phí dịch vụ theo quy định

Bảng 1 quy định các trường trên ở dạng số, kích thước tối đa 15 ký tự và xác định phần lớn giá trị bằng cách tổng hợp dữ liệu chi tiết từ XML2 và XML3.


2. Trước hết phải phân biệt “chi phí bệnh viện” và “chi phí BHYT”

Đây là hai khái niệm rất dễ bị nhầm.

THANH_TIEN_BV

Ở cấp từng dòng chi phí, đây là số tiền tính theo giá của cơ sở KBCB.

Ví dụ trong XML3:

THANH_TIEN_BV
=
SO_LUONG × DON_GIA_BV

Trong khi THANH_TIEN_BH được xác định từ số lượng, đơn giá BHYT và tỷ lệ thanh toán; với một số trường hợp còn có tỷ lệ thanh toán dịch vụ riêng.

Vì vậy:

Chi phí bệnh viện không đồng nghĩa với số tiền quỹ BHYT phải trả.


THANH_TIEN_BH

Đây là phần giá trị của dòng chi phí nằm trong phạm vi và tỷ lệ thanh toán của BHYT theo quy định.

Ở XML2, công thức cơ bản là:

THANH_TIEN_BH
=
SO_LUONG × DON_GIA × TYLE_TT_BH / 100

Trong XML3, nguyên tắc tương tự nhưng sử dụng DON_GIA_BH; một số DVKT còn phải tính thêm TYLE_TT_DV.

Do đó:

THANH_TIEN_BH là cơ sở chi phí thuộc phạm vi BHYT, chưa đồng nghĩa với số tiền cuối cùng BHXH thanh toán.

Để biết BHXH đề nghị thanh toán bao nhiêu còn phải xét MUC_HUONG và các nguồn chi trả khác.


3. Ba tầng tiền cần phân biệt

Một cách dễ hiểu:

THANH_TIEN_BV
      ↓
Toàn bộ giá trị của khoản chi
      │
      ├── ngoài phạm vi BHYT → T_BNTT
      │
      └── trong phạm vi BHYT → THANH_TIEN_BH
                                  │
                                  ├── người bệnh cùng trả → T_BNCCT
                                  │
                                  └── BHYT đề nghị trả → T_BHTT

Nếu có nguồn tài chính khác:

T_NGUONKHAC

thì việc phân bổ giữa các bên còn phải điều chỉnh theo quy định của trường này.

Đây là lý do không nên chỉ nhìn một con số T_BHTT để hiểu toàn bộ cấu trúc thanh toán.


4. T_THUOC — tổng chi phí thuốc

T_THUOC không phải là tổng T_BHTT của thuốc.

Bảng 1 quy định T_THUOC là tổng THANH_TIEN_BV của các khoản thuộc XML2, bao gồm thuốc và các khoản được quy định như oxy, dịch truyền, máu, chế phẩm máu và một số chi phí liên quan.

Có thể hiểu:

T_THUOC
=
Σ THANH_TIEN_BV của XML2

trong phạm vi các khoản được quy định tại bảng thuốc.

Nếu XML2 có 20 dòng thì XML1 không cần mang 20 khoản chi tiết mà chỉ chứa giá trị tổng hợp.


5. T_VTYT — tổng chi phí vật tư y tế

T_VTYT là tổng THANH_TIEN_BV của các vật tư y tế trong XML3.

Cần lưu ý:

XML3 chứa cả DVKT và VTYT, nhưng T_VTYT chỉ tổng hợp phần vật tư y tế.

Do đó không được tính:

T_VTYT
=
tổng toàn bộ XML3

vì XML3 còn có tiền khám, DVKT, giường và các khoản khác tùy loại bản ghi.


6. T_TONGCHI_BV — tổng chi phí theo giá bệnh viện

Bảng 1 quy định:

T_TONGCHI_BV
=
Σ THANH_TIEN_BV của XML2
+
Σ THANH_TIEN_BV của XML3

Đây chính là tổng giá trị chi phí của lần khám hoặc đợt điều trị theo dữ liệu chi tiết.

Vì vậy, một phép kiểm tra rất mạnh là:

XML1.T_TONGCHI_BV
        ?=
SUM(XML2.THANH_TIEN_BV)
+
SUM(XML3.THANH_TIEN_BV)

Nếu không khớp, trước hết đây là lỗi tính toán hoặc bất nhất giữa bảng tổng hợp và bảng chi tiết cần được xử lý trước khi gửi hồ sơ.


7. T_TONGCHI_BH — tổng chi phí trong phạm vi BHYT

Tương tự:

T_TONGCHI_BH
=
Σ XML2.THANH_TIEN_BH
+
Σ XML3.THANH_TIEN_BH

Bảng 1 xác định đây là tổng chi phí trong phạm vi quỹ BHYT thanh toán của lần khám hoặc đợt điều trị.

Điểm rất quan trọng:

T_TONGCHI_BH không phải là số tiền cuối cùng BHXH thanh toán.

Ví dụ một khoản chi nằm trong phạm vi BHYT 1.000.000 đồng nhưng người bệnh có mức hưởng 80% thì:

THANH_TIEN_BH = 1.000.000

T_BHTT       = 800.000
T_BNCCT      = 200.000

Trong ví dụ này, cả 1 triệu đồng đều nằm trong phạm vi BHYT, nhưng quỹ chỉ chịu phần tương ứng với mức hưởng.


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

T_BNTT là phần chi phí ngoài phạm vi chi trả của quỹ BHYT.

XML1 lấy tổng trường T_BNTT từ các dòng XML2 và XML3.

Ở cấp chi tiết, nguyên tắc cơ bản có thể được hiểu:

Chi phí theo bệnh viện
       -
phần thuộc phạm vi BHYT
       =
phần người bệnh tự trả

Đối với XML3, diễn giải cập nhật xác định:

T_BNTT
=
THANH_TIEN_BV - THANH_TIEN_BH

khi không phải xử lý thêm nguồn khác.

Điểm cần phân biệt:

T_BNTT không phải là “cùng chi trả”.

Đây là phần ngoài phạm vi BHYT.


9. T_BNCCT — người bệnh cùng chi trả

T_BNCCT là số tiền người bệnh cùng chi trả trong phạm vi quyền lợi BHYT.

Ví dụ:

THANH_TIEN_BH = 1.000.000
MUC_HUONG     = 80%

trong trường hợp đơn giản:

T_BHTT  = 800.000
T_BNCCT = 200.000

Theo diễn giải cập nhật của XML3:

T_BNCCT
=
THANH_TIEN_BH - T_BHTT

nếu không có điều chỉnh bởi nguồn khác.

Như vậy cần phân biệt rõ:

T_BNTT
= tự trả ngoài phạm vi BHYT

T_BNCCT
= cùng chi trả trong phạm vi BHYT

Hai trường này có ý nghĩa pháp lý và tài chính khác nhau.


10. T_BHTT — số tiền đề nghị quỹ BHYT thanh toán

Ở cấp dòng chi tiết, công thức cơ bản sau Quyết định 3176 là:

T_BHTT
=
THANH_TIEN_BH × MUC_HUONG / 100

trước khi xử lý trường hợp có T_NGUONKHAC.

Trong XML1, T_BHTT là tổng số tiền đề nghị cơ quan BHXH thanh toán; Bảng 1 đồng thời ghi công thức tổng hợp:

T_BHTT
=
T_TONGCHI_BH - T_BNCCT

Với trường hợp thông thường không có nguồn khác, hai cách nhìn này tương thích:

Σ T_BHTT từng dòng
=
T_TONGCHI_BH - T_BNCCT

Tuy nhiên khi có T_NGUONKHAC, không nên chỉ áp dụng máy móc một công thức tổng ở XML1 mà phải đối chiếu cách phân bổ ở từng dòng XML2/XML3 theo phiên bản quy định đang áp dụng.


11. T_NGUONKHAC — tiền do nguồn khác chi trả

Ở XML2 và XML3, nguồn khác được chi tiết thành các nhóm như:

T_NGUONKHAC_NSNN
T_NGUONKHAC_VTNN
T_NGUONKHAC_VTTN
T_NGUONKHAC_CL

sau đó tổng thành:

T_NGUONKHAC

Quyết định 3176 sửa diễn giải theo hướng: khi T_NGUONKHAC > 0, số tiền nguồn khác được giảm trừ lần lượt vào T_BNTT, T_BNCCT, rồi T_BHTT cho đến khi hết số tiền nguồn khác.

Đây là điểm rất quan trọng.

Không nên hiểu:

T_NGUONKHAC
= một khoản cộng thêm vào tổng chi phí

mà đây là một nguồn thanh toán khác cho chính chi phí KCB, làm thay đổi số tiền cuối cùng do người bệnh và quỹ BHYT phải chịu.

Ở XML1:

T_NGUONKHAC
=
Σ T_NGUONKHAC của XML2
+
Σ T_NGUONKHAC của XML3

theo diễn giải của Bảng 1.


12. T_BHTT_GDV — phần thanh toán theo phí dịch vụ

Bảng 1 quy định T_BHTT_GDV là phần tiền quỹ BHYT thanh toán đối với các khoản chi ngoài định suất hoặc ngoài DRG theo quy định, được xác định từ các khoản T_BHTT trong XML2 và XML3 có:

MA_PTTT = 1

tức nhóm phí dịch vụ.

Do đó:

T_BHTT_GDV là một phân nhóm của chi phí thanh toán theo phương thức, không phải một khoản tiền cộng thêm ngoài T_BHTT.

Trong kiểm tra dữ liệu cần tránh cộng:

T_BHTT + T_BHTT_GDV

để tính số tiền đề nghị thanh toán, vì sẽ có nguy cơ tính trùng.


13. Ví dụ đơn giản không có nguồn khác

Giả sử một hồ sơ có:

Dòng chi phíTHANH_TIEN_BVTHANH_TIEN_BHMức hưởng
Thuốc XML21.000.000800.00080%
DVKT XML3500.000500.00080%
VTYT XML3300.000240.00080%

Khi đó:

T_THUOC = 1.000.000

T_VTYT = 300.000

T_TONGCHI_BV
= 1.000.000 + 500.000 + 300.000
= 1.800.000

T_TONGCHI_BH
= 800.000 + 500.000 + 240.000
= 1.540.000

Phân bổ:

T_BNTT
= 200.000 + 0 + 60.000
= 260.000
T_BHTT
= 640.000 + 400.000 + 192.000
= 1.232.000
T_BNCCT
= 160.000 + 100.000 + 48.000
= 308.000

Ta có:

T_TONGCHI_BH
=
T_BHTT + T_BNCCT

1.540.000
=
1.232.000 + 308.000

và trong trường hợp đơn giản này:

T_TONGCHI_BV
=
T_BNTT + T_BNCCT + T_BHTT

1.800.000
=
260.000 + 308.000 + 1.232.000

Nếu xuất hiện T_NGUONKHAC, việc phân bổ phải tính lại theo quy định tương ứng.


14. Quan hệ XML1 ↔ XML2 ↔ XML3 cần kiểm tra

Đây là nhóm rất phù hợp cho kiểm tra tự động:

XML2.T_THUOC_DETAIL
       │
       └─ Σ THANH_TIEN_BV
                  ↓
             XML1.T_THUOC
XML3 các dòng VTYT
       │
       └─ Σ THANH_TIEN_BV
                  ↓
             XML1.T_VTYT
XML2 + XML3
Σ THANH_TIEN_BV
        ↓
XML1.T_TONGCHI_BV
XML2 + XML3
Σ THANH_TIEN_BH
        ↓
XML1.T_TONGCHI_BH

và tương tự:

Σ T_BNTT       → XML1.T_BNTT
Σ T_BNCCT      → XML1.T_BNCCT
Σ T_BHTT       → đối chiếu XML1.T_BHTT
Σ T_NGUONKHAC  → XML1.T_NGUONKHAC

Đây là các rule aggregate constraint điển hình.


15. Không chỉ kiểm tra tổng tiền, còn phải kiểm tra nguồn tạo ra tổng tiền

Một hồ sơ có thể có:

T_TONGCHI_BV = đúng

nhưng bên trong vẫn sai.

Ví dụ:

  • một dòng thuốc có sai số lượng;
  • đơn giá sai;
  • TYLE_TT_BH sai;
  • MUC_HUONG sai;
  • dịch vụ không thuộc phạm vi thanh toán nhưng vẫn tính THANH_TIEN_BH;
  • một dòng bị tính hai lần;
  • nguồn khác được phân bổ sai.

Các sai số có thể bù trừ nhau khiến tổng cuối cùng vẫn “khớp”.

Do đó tiền giám định cần hai tầng:

Tầng 1
Kiểm tra công thức từng dòng XML2/XML3
        ↓
Tầng 2
Kiểm tra tổng hợp lên XML1

Không nên chỉ kiểm tra tầng 2.


16. Các bất thường thường gặp

Một số dạng cần cảnh báo:

Sai tổng hợp

XML1.T_TONGCHI_BV
≠
SUM(XML2 + XML3.THANH_TIEN_BV)

Sai phạm vi BHYT

T_TONGCHI_BH > T_TONGCHI_BV

trong tình huống không có căn cứ đặc thù giải thích.

Sai phân bổ

T_BHTT + T_BNCCT
≠
T_TONGCHI_BH

trong trường hợp đơn giản không có nguồn khác.

Sai nguồn khác

T_NGUONKHAC ở XML1 không bằng tổng các dòng chi tiết hoặc nguồn khác không được giảm trừ theo đúng thứ tự quy định.

Sai tiền thuốc/vật tư

T_THUOC hoặc T_VTYT không khớp các dòng tương ứng ở XML2/XML3.

Những bất thường này thường là lỗi dữ liệu hoặc lỗi tính toán có thể phát hiện trước khi gửi, nhưng vẫn phải phân biệt với kết luận cuối cùng về thanh toán.


17. Ý nghĩa đối với Dr5-XML

Nhóm chi phí này nên được xây chủ yếu bằng các generic rule:

row_formula_constraint
        ↓
aggregate_constraint
        ↓
cross_table_consistency
        ↓
conditional_formula

Thay vì hard-code từng field vào code, các công thức và điều kiện nên được cấu hình thông qua các danh mục dr5_..., ví dụ:

dr5_cost_field
dr5_cost_formula
dr5_cost_aggregate
dr5_payment_allocation
dr5_payment_method
dr5_effective_rule

Mỗi cấu hình cần gắn:

table
field
formula
condition
rounding
effective_from
effective_to
legal_basis

Như vậy khi cách tính hoặc diễn giải của Bộ Y tế thay đổi, có thể ưu tiên cập nhật danh mục kiểm tra thay vì sửa logic engine.


Kết luận

Có thể ghi nhớ cấu trúc tài chính của XML theo ba tầng:

Tầng 1 — Chi phí phát sinh: THANH_TIEN_BV
Tầng 2 — Phần thuộc phạm vi BHYT: THANH_TIEN_BH
Tầng 3 — Phân bổ người trả: T_BNTT, T_BNCCT, T_BHTT, T_NGUONKHAC

Sau đó XML1 tổng hợp các giá trị này từ XML2 và XML3 cho toàn bộ đợt KCB.

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

XML1 không nên tự sinh ra một bộ số tiền độc lập. Mọi tổng chi phí phải truy ngược được đến các dòng chi tiết tạo ra nó.

Chính quan hệ dòng chi phí → công thức → bên chi trả → tổng hợp XML1 là một trong những khu vực có giá trị nhất để tự động hóa tiền giám định và phát hiện sai lệch trước khi gửi dữ liệu.