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 XML1 | Trường | Ý nghĩa chính |
|---|---|---|
| 45 | T_THUOC | Tổng thành tiền thuốc và các khoản liên quan thuộc XML2 |
| 46 | T_VTYT | Tổng thành tiền vật tư y tế trong XML3 |
| 47 | T_TONGCHI_BV | Tổng chi phí theo giá bệnh viện |
| 48 | T_TONGCHI_BH | Tổng chi phí trong phạm vi quỹ BHYT thanh toán |
| 49 | T_BNTT | Tổng số tiền người bệnh tự trả ngoài phạm vi BHYT |
| 50 | T_BNCCT | Tổng số tiền người bệnh cùng chi trả |
| 51 | T_BHTT | Tổng số tiền cơ sở đề nghị BHXH thanh toán |
| 52 | T_NGUONKHAC | Tổng số tiền do các nguồn khác chi trả |
| 53 | T_BHTT_GDV | Phầ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_BVTrong 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 / 100Trong 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_BHlà 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_BHTTNếu có nguồn tài chính khác:
T_NGUONKHACthì 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 XML2trong 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_VTYTchỉ tổng hợp phần vật tư y tế.
Do đó không được tính:
T_VTYT
=
tổng toàn bộ XML3vì 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_BHBả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_BHkhô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.000Trong 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_BHkhi không phải xử lý thêm nguồn khác.
Điểm cần phân biệt:
T_BNTTkhô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.000Theo diễn giải cập nhật của XML3:
T_BNCCT
=
THANH_TIEN_BH - T_BHTTnế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 BHYTHai 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 / 100trướ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_BNCCTVớ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_BNCCTTuy 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_CLsau đó tổng thành:
T_NGUONKHACQuyế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 XML3theo 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 = 1tức nhóm phí dịch vụ.
Do đó:
T_BHTT_GDVlà 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àiT_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_BV | THANH_TIEN_BH | Mức hưởng |
|---|---|---|---|
| Thuốc XML2 | 1.000.000 | 800.000 | 80% |
| DVKT XML3 | 500.000 | 500.000 | 80% |
| VTYT XML3 | 300.000 | 240.000 | 80% |
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.000Phân bổ:
T_BNTT
= 200.000 + 0 + 60.000
= 260.000T_BHTT
= 640.000 + 400.000 + 192.000
= 1.232.000T_BNCCT
= 160.000 + 100.000 + 48.000
= 308.000Ta có:
T_TONGCHI_BH
=
T_BHTT + T_BNCCT
1.540.000
=
1.232.000 + 308.000và 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.000Nế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_THUOCXML3 các dòng VTYT
│
└─ Σ THANH_TIEN_BV
↓
XML1.T_VTYTXML2 + XML3
Σ THANH_TIEN_BV
↓
XML1.T_TONGCHI_BVXML2 + XML3
Σ THANH_TIEN_BH
↓
XML1.T_TONGCHI_BHvà 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 = đúngnhư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_BHsai;MUC_HUONGsai;- 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 XML1Khô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_BVtrong 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_BHtrong 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_formulaThay 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_ruleMỗi cấu hình cần gắn:
table
field
formula
condition
rounding
effective_from
effective_to
legal_basisNhư 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.
- Đăng nhập để gửi ý kiến