Nhóm trường này mô tả dòng thời gian của một đợt khám chữa bệnh, cách xác định số ngày điều trị, tình trạng người bệnh khi kết thúc đợt KCB và thời điểm chi phí được đưa vào kỳ đề nghị thanh toán.

Đây là nhóm dữ liệu đặc biệt quan trọng để kiểm tra tính hợp lý của hồ sơ, vì nhiều bất thường chỉ xuất hiện khi đặt các mốc thời gian cạnh nhau:

đến KCB → vào điều trị → thực hiện dịch vụ → kết thúc KCB → thanh toán → đưa vào kỳ quyết toán.

Một thời điểm riêng lẻ có thể hoàn toàn hợp lệ về định dạng nhưng vẫn sai khi so với các mốc còn lại.

1. Các trường chính của nhóm

Các trường này được quy định trong Bảng 1 và có nhiều nội dung đã được sửa đổi, bổ sung qua các phiên bản sau Quyết định 130.

2. NGAY_VAO — thời điểm người bệnh đến KCB

NGAY_VAO là Chuỗi 12 ký tự, theo định dạng:

yyyymmddHHMM

Ví dụ:

202610110830

nghĩa là người bệnh đến KCB lúc 08 giờ 30 phút ngày 11/10/2026.

Bảng chỉ tiêu xác định đây là thời điểm người bệnh đến KCB, không phải mặc nhiên là thời điểm nhập khoa nội trú.

Đây là điểm cần phân biệt rõ với NGAY_VAO_NOI_TRU.

3. NGAY_VAO_NOI_TRU — thời điểm vào điều trị

Theo diễn giải cập nhật trong bảng đối chiếu, NGAY_VAO_NOI_TRU ghi thời điểm người bệnh vào điều trị nội trú hoặc điều trị ban ngày, cũng theo định dạng yyyymmddHHMM.

Ví dụ:

NGAY_VAO          = 202610110800
NGAY_VAO_NOI_TRU  = 202610111030

có thể phản ánh:

08:00  người bệnh đến bệnh viện
       ↓
khám, đánh giá
       ↓
10:30  vào điều trị

Do đó:

NGAY_VAO và NGAY_VAO_NOI_TRU không phải lúc nào cũng giống nhau.

Một rule yêu cầu hai thời điểm phải bằng nhau sẽ tạo cảnh báo sai.

Quan hệ cần kiểm tra hợp lý hơn là:

NGAY_VAO
   ≤
NGAY_VAO_NOI_TRU
   ≤
NGAY_RA

khi loại hình KCB thực sự có phát sinh điều trị nội trú hoặc ban ngày.

4. NGAY_RA — thời điểm kết thúc lần KCB hoặc đợt điều trị

NGAY_RA không nên hiểu đơn giản là “ngày người bệnh bước ra khỏi bệnh viện”.

Theo diễn giải cập nhật, đây là thời điểm kết thúc lần khám bệnh hoặc đợt điều trị tại cơ sở KBCB, gồm 12 ký tự theo định dạng yyyymmddHHMM. Với điều trị ngoại trú, phần diễn giải xác định là thời điểm kết thúc việc khám, chỉ định điều trị.

Như vậy ý nghĩa của NGAY_RA phụ thuộc vào MA_LOAI_KCB.

Ví dụ:

MA_LOAI_KCB = 01
→ NGAY_RA là thời điểm kết thúc lần khám

MA_LOAI_KCB = 03
→ NGAY_RA là thời điểm kết thúc đợt điều trị nội trú

Do đó một rule kiểm tra thời gian luôn phải biết loại hình KCB của hồ sơ.

5. Ba mốc thời gian không được kiểm tra độc lập

Quan hệ cơ bản:

NGAY_VAO
    ↓
NGAY_VAO_NOI_TRU
    ↓
NGAY_RA

nhưng không phải hồ sơ nào cũng cần đủ cả ba.

Ví dụ khám bệnh thông thường có thể không phát sinh NGAY_VAO_NOI_TRU.

Vì vậy logic đúng phải là:

MA_LOAI_KCB
      ↓
xác định mốc thời gian nào áp dụng
      ↓
kiểm tra thứ tự thời gian

chứ không phải:

NGAY_VAO_NOI_TRU rỗng
→ lỗi

6. SO_NGAY_DTRI — số ngày điều trị

SO_NGAY_DTRI là trường số, kích thước tối đa 3.

Theo diễn giải cập nhật trong bảng đối chiếu, cách ghi phụ thuộc vào MA_LOAI_KCB. Nguyên tắc chung có công thức:

SO_NGAY_DTRI
=
NGAY_RA - NGAY_VAO + 1

nhưng có các trường hợp đặc thù:

• MA_LOAI_KCB = 02 hoặc 08: ghi số ngày có thực hiện DVKT trong đợt điều trị ngoại trú;
• MA_LOAI_KCB = 05 hoặc 07: ghi số ngày sử dụng thuốc dài nhất;
• MA_LOAI_KCB = 09: ghi 0;
• trường hợp người bệnh đến khám rồi được hẹn vào nội trú, thời gian chờ theo hẹn không tính vào số ngày điều trị.

Đây là lý do SO_NGAY_DTRI không thể được kiểm tra bằng duy nhất một công thức cho mọi hồ sơ.

7. Sự thay đổi của MA_LOAI_KCB ảnh hưởng trực tiếp đến kiểm tra ngày điều trị

Từ ngày 01/8/2026, Quyết định 1804/QĐ-BYT áp dụng danh mục mã loại hình KCB mới để mã hóa và gửi dữ liệu chi phí BHYT.

Một số phân biệt rất quan trọng gồm:

• 03: điều trị nội trú; nếu dưới 4 giờ thì sử dụng 09;
• 04: điều trị ban ngày;
• 05: điều trị ngoại trú bệnh cần chữa trị dài ngày, có khám và lĩnh thuốc; nếu có thực hiện DVKT thì sử dụng 08;
• 08: điều trị ngoại trú bệnh dài ngày có thực hiện DVKT và/hoặc sử dụng thuốc;
• 09: điều trị nội trú dưới 4 giờ.

Do đó:

Rule tính số ngày phải biết phiên bản danh mục MA_LOAI_KCB đang áp dụng tại ngày hồ sơ phát sinh.

8. PP_DIEU_TRI — phương pháp điều trị

PP_DIEU_TRI là trường Chuỗi, dùng để mô tả phương pháp điều trị.

Theo diễn giải cập nhật, có thể ghi các phương pháp như:

Nội khoa
Ngoại khoa
Xạ trị
Hóa trị
Xạ trị + nội khoa
...

Field này không chỉ mang tính mô tả.

Nó có thể được đối chiếu với:

PP_DIEU_TRI
     ↕
CHAN_DOAN_RV
     ↕
XML3 - DVKT
     ↕
XML5 - diễn biến lâm sàng

Ví dụ hồ sơ ghi phương pháp điều trị ngoại khoa nhưng toàn bộ dữ liệu không có dấu hiệu của can thiệp ngoại khoa thì đây là trường hợp cần kiểm tra.

Tuy nhiên, kết quả nên là cảnh báo bất nhất, chưa đủ để tự động kết luận chi phí không được thanh toán.

9. KET_QUA_DTRI — kết quả điều trị

Bảng chỉ tiêu mã hóa kết quả điều trị bằng một ký tự số.

Các giá trị gồm:

Quyết định 4750 đã bổ sung mã 8; phần diễn giải sau đó làm rõ mã 5 là tử vong tại cơ sở KBCB.

KET_QUA_DTRI nên được đối chiếu với:

CHAN_DOAN_RV
MA_LOAI_RV
NGAY_RA
GHI_CHU
XML5

Ví dụ:

KET_QUA_DTRI = 5

nhưng:

MA_LOAI_RV = 1
GHI_CHU = tái khám sau 7 ngày

là một tổ hợp cần được rà soát vì có dấu hiệu không nhất quán.

10. MA_LOAI_RV — cách thức kết thúc đợt điều trị

MA_LOAI_RV phản ánh hình thức người bệnh kết thúc đợt điều trị hoặc rời cơ sở.

Các mã được quy định:

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

KET_QUA_DTRI và MA_LOAI_RV trả lời hai câu hỏi khác nhau.

KET_QUA_DTRI:

Người bệnh kết thúc với tình trạng chuyên môn như thế nào?

MA_LOAI_RV:

Người bệnh kết thúc đợt KCB theo cách nào?

Ví dụ một người bệnh có thể:

KET_QUA_DTRI = 2   → Đỡ
MA_LOAI_RV   = 2   → Chuyển cơ sở theo yêu cầu chuyên môn

Hai giá trị này hoàn toàn có thể cùng tồn tại.

11. Quan hệ giữa ra viện và chuyển cơ sở

Khi:

MA_LOAI_RV = 2 hoặc 5

thì cần kiểm tra thêm các thông tin đã trình bày ở Bài 1.11 như:

MA_NOI_DEN
GIAY_CHUYEN_TUYEN
XML13 nếu thuộc phạm vi phát sinh

Điều này cho thấy một rule mạnh thường không kiểm tra một field đơn lẻ mà kiểm tra một chuỗi sự kiện.

Ví dụ:

MA_LOAI_RV = chuyển cơ sở
         ↓
MA_NOI_DEN có phù hợp?
         ↓
giấy chuyển có phát sinh?
         ↓
thời điểm chuyển có phù hợp NGAY_RA?

12. GHI_CHU — lời dặn khi kết thúc KCB

GHI_CHU dùng để ghi lời dặn của bác sĩ hoặc nhân viên y tế đối với người bệnh sau khi kết thúc lần KCB.

Đây không phải field chỉ để “ghi thêm cho đủ”.

Trong một số tình huống, nội dung này có thể hỗ trợ kiểm tra:

• tái khám;
• theo dõi;
• tiếp tục dùng thuốc;
• chăm sóc sau ra viện;
• chuyển cơ sở;
• các hướng dẫn sau điều trị.

Tuy nhiên không nên suy ra rằng mọi hồ sơ đều phải có một nội dung GHI_CHU giống nhau.

13. NGAY_TTOAN — thời điểm thanh toán

NGAY_TTOAN là Chuỗi 12 ký tự:

yyyymmddHHMM

và ghi thời điểm người bệnh thanh toán chi phí KCB.

Một chi tiết rất quan trọng trong Bảng 1 là:

Nếu người bệnh đã ra viện nhưng chưa thanh toán, trường này có thể để trống tại thời điểm chuyển dữ liệu lên Cổng tiếp nhận; khi hoàn tất thủ tục thanh toán, cơ sở KBCB phải bổ sung thông tin theo quy định.

Do đó:

NGAY_TTOAN rỗng

không phải lúc nào cũng là lỗi.

Phải xác định hồ sơ đang ở giai đoạn nào trong vòng đời dữ liệu.

14. NGAY_RA không đồng nghĩa NGAY_TTOAN

Hai field rất dễ bị nhầm:

NGAY_RA

là thời điểm kết thúc lần KCB/đợt điều trị.

NGAY_TTOAN

là thời điểm hoàn tất thủ tục thanh toán chi phí.

Ví dụ hoàn toàn có thể có:

NGAY_RA    = 202610101000
NGAY_TTOAN = 202610101145

hoặc việc thanh toán được hoàn tất sau đó.

Do đó, không nên thiết kế rule:

NGAY_RA phải bằng NGAY_TTOAN

mà nên kiểm tra tính hợp lý theo quy trình thực tế.

15. NAM_QT và THANG_QT — kỳ đề nghị thanh toán

Ở phần cuối nhóm chi phí của XML1 có:

NAM_QT
THANG_QT

NAM_QT là năm mà cơ sở KBCB đề nghị cơ quan BHXH thanh toán.

THANG_QT là tháng mà cơ sở KBCB đề nghị thanh toán.

Hai field này không đơn thuần là sao chép tháng và năm của NGAY_RA.

Chúng phản ánh kỳ mà cơ sở đưa hồ sơ vào đề nghị thanh toán.

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

Ngày KCB
≠
Ngày kết thúc KCB
≠
Ngày thanh toán
≠
Kỳ đề nghị thanh toán

Trong nhiều hồ sơ các thời điểm có thể cùng tháng, nhưng về bản chất chúng là những khái niệm khác nhau.

16. Dòng thời gian của một hồ sơ XML1

Có thể hình dung:

NGAY_VAO
   │
   ├── khám, đánh giá
   │
NGAY_VAO_NOI_TRU        nếu áp dụng
   │
   ├── điều trị
   │
   ├── thuốc / DVKT / VTYT
   │
NGAY_RA
   │
   ├── KET_QUA_DTRI
   ├── MA_LOAI_RV
   └── GHI_CHU
   │
NGAY_TTOAN
   │
   ↓
NAM_QT + THANG_QT

Đây chính là một trong những trục kiểm tra quan trọng nhất của XML.

17. Một số bất thường thời gian thường cần rà soát

Các tình huống đáng cảnh báo gồm:

• NGAY_RA < NGAY_VAO;
• NGAY_VAO_NOI_TRU < NGAY_VAO nhưng không có lý do dữ liệu hợp lệ;
• DVKT hoặc thuốc phát sinh ngoài khoảng thời gian đợt KCB;
• kết quả CLS có thời điểm không phù hợp với thời điểm chỉ định/thực hiện;
• số ngày điều trị không phù hợp với MA_LOAI_KCB;
• hồ sơ mã 09 nhưng số ngày điều trị khác 0;
• MA_LOAI_RV là chuyển cơ sở nhưng thiếu các thông tin chuyển tương ứng;
• KET_QUA_DTRI và MA_LOAI_RV mâu thuẫn rõ ràng;
• NGAY_TTOAN hoặc kỳ quyết toán bất thường so với vòng đời hồ sơ.

Những trường hợp này nên được coi là dấu hiệu cần kiểm tra. Không phải mọi bất thường thời gian đều tự động đồng nghĩa với xuất toán.

18. Kiểm tra thời gian phải đi xuống các XML chi tiết

XML1 chỉ cung cấp khung thời gian tổng quát.

Muốn kiểm tra sâu hơn phải đối chiếu:

XML1
NGAY_VAO
NGAY_RA
        ↓
XML2
thời điểm dùng thuốc/y lệnh
        ↓
XML3
thời điểm chỉ định/thực hiện DVKT
        ↓
XML4
thời điểm kết quả CLS
        ↓
XML5
thời điểm diễn biến lâm sàng

Như vậy có thể phát hiện các trường hợp:

dịch vụ xảy ra trước khi người bệnh đến;

thuốc được ghi sử dụng sau khi đợt KCB đã kết thúc;

kết quả xuất hiện trước thời điểm thực hiện;

diễn biến lâm sàng nằm ngoài khoảng điều trị.

Đây là nhóm rule cross-record/cross-table rất có giá trị trong tiền giám định.

19. Ý nghĩa đối với thiết kế rule Dr5-XML

Nhóm này không nên được xây bằng những điều kiện hard-code rời rạc.

Nên tách thành các lớp:

1. Parse thời gian
        ↓
2. Xác định MA_LOAI_KCB
        ↓
3. Tra danh mục/quy tắc có hiệu lực
        ↓
4. Xác định mốc thời gian bắt buộc
        ↓
5. Kiểm tra trình tự
        ↓
6. Tính SO_NGAY_DTRI
        ↓
7. Đối chiếu XML2/3/4/5
        ↓
8. Kiểm tra KET_QUA_DTRI + MA_LOAI_RV
        ↓
9. Kiểm tra NGAY_TTOAN + kỳ quyết toán

Các quy tắc phụ thuộc danh mục nên sử dụng các bảng dr5_..., chẳng hạn:

dr5_kcb_type
dr5_treatment_day_rule
dr5_time_relation
dr5_discharge_result
dr5_discharge_type
dr5_settlement_period_rule

với effective_from, effective_to, phiên bản và căn cứ pháp lý.

Như vậy khi Bộ Y tế thay đổi loại hình KCB hoặc cách tính ngày điều trị, phần lớn hệ thống chỉ cần cập nhật danh mục kiểm tra, thay vì sửa lại rule engine.

Kết luận

Nhóm trường thời gian của XML1 không đơn thuần ghi “ngày vào, ngày ra”.

Nó mô tả cả vòng đời của đợt KCB:

đến cơ sở → vào điều trị → điều trị bao lâu → kết thúc với kết quả gì → ra viện theo hình thức nào → thanh toán khi nào → đưa vào kỳ đề nghị thanh toán nào.

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

Thời gian phải được kiểm tra như một chuỗi sự kiện, không phải từng field độc lập.

Và khi phát hiện bất thường, cần tiếp tục đối chiếu hồ sơ bệnh án và XML2–XML5 trước khi đi đến kết luận về khả năng thanh toán.