Từ file dữ liệu đến từng bảng và từng trường thông tin

Dữ liệu XML là phương thức chuẩn hóa và trao đổi dữ liệu điện tử giữa cơ sở khám chữa bệnh và cơ quan bảo hiểm xã hội. Theo Thông tư 48/2017/TT-BYT, dữ liệu được định dạng bằng XML, sử dụng UTF-8; một file XML có thể chứa một hoặc nhiều hồ sơ khám chữa bệnh BHYT, trong đó mỗi hồ sơ tương ứng với một đợt khám chữa bệnh của người bệnh. 48_2017_TT-BYT_m_371261

Về cấu trúc, có thể hiểu đơn giản theo các tầng:

File XML → Hồ sơ/đợt khám chữa bệnh → Bảng dữ liệu → Bản ghi → Trường thông tin (field).

Trong một đợt khám chữa bệnh, thông tin không nằm trong một bảng duy nhất mà được phân chia thành nhiều bảng theo từng nhóm dữ liệu. Quyết định 130/QĐ-BYT quy định các bảng về trạng thái khám chữa bệnh, thông tin tổng hợp, thuốc, dịch vụ kỹ thuật và vật tư y tế, cận lâm sàng, diễn biến lâm sàng, hồ sơ HIV/AIDS và các chứng từ liên quan. Các chỉ tiêu trong từng bảng được quy định cụ thể về tên trường, kiểu dữ liệu, kích thước tối đa và cách ghi nhận. 130_QD-BYT_m_551553

Trong đó, XML1 đến XML5 là nhóm dữ liệu đặc biệt quan trọng đối với hoạt động khám chữa bệnh BHYT: từ thông tin tổng hợp của đợt điều trị đến thuốc, dịch vụ kỹ thuật, vật tư, kết quả cận lâm sàng và diễn biến lâm sàng. Quyết định 130 xác định các bảng này được sử dụng để cung cấp dữ liệu chi tiết phục vụ quản lý, giám định, thanh toán và quyết toán chi phí KCB BHYT. 130_QD-BYT_m_551553

Các bảng XML liên kết với nhau thông qua những trường dữ liệu chung, đặc biệt là MA_LK - mã liên kết của đợt khám chữa bệnh. Nhờ đó, có thể xác định thuốc nào, dịch vụ nào, kết quả nào và diễn biến nào thuộc cùng một hồ sơ.

Tuy nhiên, không phải hồ sơ nào cũng phải có đầy đủ tất cả các bảng. Việc phát sinh bảng dữ liệu phụ thuộc vào loại hình khám chữa bệnh và các hoạt động thực tế của người bệnh. Đồng thời, mỗi bảng cũng có mục đích khác nhau. Ví dụ, Bảng check-in dùng để thông báo trạng thái khám chữa bệnh và không được sử dụng làm căn cứ giám định, thanh toán, quyết toán chi phí BHYT. 4750_QD-BYT_593340

Một điểm quan trọng khác là cấu trúc XML không cố định theo thời gian. Quyết định 4750/QĐ-BYT và Quyết định 3176/QĐ-BYT đã tiếp tục sửa đổi, bổ sung chuẩn dữ liệu của Quyết định 130. Vì vậy, khi đọc hoặc kiểm tra một field phải luôn xác định đúng phiên bản quy định và thời điểm áp dụng. 4750_QD-BYT_593340 3176_QD-BYT_629410

Trong các bài tiếp theo của loạt “Cấu trúc XML”, chúng ta sẽ lần lượt đi sâu vào từng bảng và từng trường dữ liệu: ý nghĩa, kiểu dữ liệu, điều kiện ghi nhận, danh mục tham chiếu, mối liên hệ với các field khác và những điểm cần lưu ý khi kiểm tra.

Mục tiêu cuối cùng là giúp người đọc có thể đi từ:

“biết XML là gì” → “đọc được XML” → “hiểu được dữ liệu” → “phát hiện được bất thường trước khi gửi hồ sơ thanh toán”.

* Bạn cũng có thể đọc nhanh về XML ngay dưới đây nếu chưa có thời gian đi vào từng bài cụ thể.

Khi nói đến “XML BHYT”, nhiều người thường hình dung đơn giản đó là một file được phần mềm HIS xuất ra rồi gửi lên Cổng tiếp nhận dữ liệu của cơ quan BHXH. Nhưng bên trong một file XML là cả một hệ thống dữ liệu có cấu trúc: hồ sơ khám chữa bệnh → các bảng dữ liệu → các bản ghi → từng trường thông tin.

Hiểu được cấu trúc này là bước đầu tiên để đọc XML, kiểm tra lỗi, đối chiếu hồ sơ bệnh án, phân tích chuyên môn và nhận diện nguy cơ bị từ chối thanh toán.

Thông tư số 48/2017/TT-BYT xác định XML là eXtensible Markup Language - ngôn ngữ đánh dấu mở rộng dùng để chia sẻ dữ liệu điện tử giữa các hệ thống công nghệ thông tin khác nhau. Dữ liệu được biểu diễn bằng XML, sử dụng UTF-8; một file XML có thể chứa một hoặc nhiều hồ sơ khám chữa bệnh BHYT, trong đó mỗi hồ sơ chứa thông tin của một đợt khám chữa bệnh của người bệnh. 48_2017_TT-BYT_m_371261

Vì vậy, để đọc đúng XML BHYT, cần đi lần lượt từ ngoài vào trong.

1. Có thể hình dung cấu trúc XML BHYT theo 5 tầng

Ở mức đơn giản nhất:

FILE XML
   │
   ├── Hồ sơ khám chữa bệnh 1
   │      │
   │      ├── Bảng/XML1
   │      ├── Bảng/XML2
   │      ├── Bảng/XML3
   │      ├── Bảng/XML4
   │      └── ...
   │
   ├── Hồ sơ khám chữa bệnh 2
   │      └── ...
   │
   └── Hồ sơ khám chữa bệnh n

Trong mỗi bảng:
   │
   ├── Bản ghi 1
   │      ├── Field A
   │      ├── Field B
   │      └── Field C
   │
   ├── Bản ghi 2
   └── ...

Có thể hiểu tương ứng:

File XML → Hồ sơ/đợt KCB → Bảng dữ liệu → Bản ghi → Trường dữ liệu (field).

Đây là cấu trúc nền tảng cần ghi nhớ. Rất nhiều lỗi XML thực chất xuất hiện ở một trong năm tầng này.

2. Tầng thứ nhất: File XML

File XML là “vỏ chứa” dữ liệu được phần mềm tạo ra để truyền giữa các hệ thống.

Theo Thông tư 48/2017/TT-BYT, một file XML có thể chứa một hoặc nhiều hồ sơ khám chữa bệnh BHYT. Mỗi hồ sơ tương ứng với một đợt khám chữa bệnh của người bệnh. 48_2017_TT-BYT_m_371261

Vì vậy:

• một file không nhất thiết chỉ chứa một người bệnh;
• một người bệnh có nhiều đợt khám chữa bệnh khác nhau thì có thể tạo thành nhiều hồ sơ;
• việc kiểm tra không nên chỉ dừng ở câu hỏi “file có mở được không?”, mà phải đi sâu đến từng hồ sơ bên trong.

Ở tầng này, các lỗi thường mang tính kỹ thuật như file không đúng định dạng, dữ liệu XML không hợp lệ, lỗi mã hóa ký tự hoặc cấu trúc không đáp ứng chuẩn.

Nhưng file đúng cấu trúc mới chỉ là cửa kiểm tra đầu tiên.

3. Tầng thứ hai: Một hồ sơ tương ứng với một đợt khám chữa bệnh

Trong logic dữ liệu BHYT, đơn vị quan trọng hơn file chính là đợt khám chữa bệnh.

Một người bệnh có thể:

• khám ngoại trú nhiều lần;
• điều trị ngoại trú;
• điều trị nội trú;
• tái khám;
• chuyển cơ sở;
• sử dụng thuốc;
• thực hiện nhiều dịch vụ kỹ thuật;
• có nhiều kết quả xét nghiệm.

Những dữ liệu phát sinh trong cùng một đợt phải được liên kết lại thành một hồ sơ logic thống nhất.

Một trường đặc biệt quan trọng trong việc này là MA_LK.

Trong các bảng chỉ tiêu, MA_LK được mô tả là mã đợt điều trị duy nhất, dùng để liên kết Bảng tổng hợp với các bảng dữ liệu khác trong cùng một lần khám chữa bệnh. 130_QD-BYT_m_551553

Có thể hình dung:

MA_LK = ABC001

XML1 ────────────────┐
XML2 - thuốc         │
XML3 - DVKT/VTYT     ├── cùng một đợt KCB ABC001
XML4 - CLS           │
XML5 - diễn biến     │
...                  │
─────────────────────┘

Như vậy, MA_LK không đơn thuần là một chuỗi ký tự.

Nó chính là một khóa liên kết quan trọng giữa các bảng.

Nếu cùng một đợt điều trị nhưng MA_LK giữa XML1 và XML2 hoặc XML3 không thống nhất, hệ thống có thể không còn hiểu những dòng thuốc hoặc dịch vụ đó thuộc hồ sơ nào.

4. Tầng thứ ba: Các bảng XML

Quyết định số 130/QĐ-BYT ban đầu quy định Bảng check-in và các Bảng 1 đến 12. Các bảng sử dụng UTF-8 và được mô tả theo định dạng XML; chi tiết từng chỉ tiêu nằm trong các phụ lục của Quyết định. 130_QD-BYT_m_551553

Trong thực tế thường gọi ngắn:

Bảng 1 → XML1; Bảng 2 → XML2; Bảng 3 → XML3...

Mỗi bảng có chức năng khác nhau.

Quyết định 3176/QĐ-BYT đã bổ sung các bảng dữ liệu mới; trong phụ lục có Bảng 13 về giấy chuyển tuyến/chuyển cơ sở KBCB BHYT, Bảng 14 về giấy hẹn khám lại và Bảng 15 về quản lý điều trị bệnh lao. Bang chi tieu 3176_QD-BYT_629410 Bang chi tieu 3176_QD-BYT_629410 Bang chi tieu 3176_QD-BYT_629410

Một lưu ý rất quan trọng về XML9

Danh sách trên cần được hiểu theo lịch sử cấu trúc, không có nghĩa tất cả các bảng đang giữ nguyên như Quyết định 130 ban đầu.

Từ ngày 01/10/2025, Quyết định 2919/QĐ-BYT đã bãi bỏ Bảng 9 - Chỉ tiêu dữ liệu Giấy chứng sinh của Quyết định 130 và ban hành chuẩn, định dạng dữ liệu điện tử giấy chứng sinh riêng. 2919_QD-BYT_m_672764

Đây là ví dụ điển hình cho nguyên tắc:

Đọc XML phải gắn với phiên bản pháp lý và thời điểm phát sinh dữ liệu.

Không thể lấy cấu trúc của một năm để mặc định kiểm tra cho tất cả hồ sơ ở những thời điểm khác.

5. Không phải hồ sơ nào cũng phải có tất cả các bảng

Đây là điều rất dễ hiểu nhầm.

Một hồ sơ khám ngoại trú đơn giản không nhất thiết có đầy đủ XML1 đến XML15.

Quyết định 130 quy định đối với các bảng từ Bảng 1 đến Bảng 11, tùy đối tượng và mục đích của người bệnh trong đợt khám chữa bệnh, cơ sở KBCB gửi các bảng dữ liệu liên quan. 130_QD-BYT_m_551553

Ví dụ về mặt logic:

• có sử dụng thuốc → có dữ liệu thuốc;
• có thực hiện xét nghiệm → có dữ liệu cận lâm sàng;
• có giấy hẹn khám lại → phát sinh dữ liệu giấy hẹn;
• có chuyển cơ sở KCB → phát sinh dữ liệu liên quan chuyển cơ sở;
• không phát sinh nội dung tương ứng thì không thể mặc định rằng phải có bảng đó.

Vì vậy khi kiểm tra XML, câu hỏi đúng không phải là:

“Thiếu XML nào?”

mà là:

“Với loại hồ sơ và các hoạt động thực tế đã phát sinh, những bảng nào bắt buộc hoặc cần phải có?”

6. Các bảng cũng không có cùng giá trị pháp lý trong thanh toán

Một ví dụ quan trọng là Bảng check-in.

Quyết định 4750/QĐ-BYT quy định Bảng check-in dùng để cung cấp thông tin phục vụ thông báo trạng thái khám chữa bệnh của người bệnh trên Cổng tiếp nhận và không dùng dữ liệu của bảng này làm căn cứ giám định, thanh toán, quyết toán chi phí KCB BHYT. 4750_QD-BYT_593340

Trong khi đó, Quyết định 130 xác định Bảng 1 đến Bảng 5 cung cấp thông tin chi tiết phục vụ quản lý và giám định, thanh toán, quyết toán chi phí KCB BHYT. 130_QD-BYT_m_551553

Do đó, khi đánh giá một lỗi dữ liệu phải biết lỗi nằm ở bảng nào và bảng đó phục vụ mục đích gì.

Không thể đánh đồng mọi lỗi XML với một nguy cơ thanh toán giống nhau.

7. Tầng thứ tư: Một bảng có thể có một hoặc nhiều bản ghi

Sau khi hiểu bảng, cần đi thêm một tầng nữa: bản ghi.

XML1 mang tính tổng hợp của một đợt KCB.

Trong khi đó, các bảng chi tiết có thể chứa rất nhiều dòng.

Ví dụ một người bệnh được sử dụng:

• 5 loại thuốc;
• 8 dịch vụ kỹ thuật;
• 20 chỉ số xét nghiệm.

Về mặt dữ liệu, các nội dung đó không phải một giá trị duy nhất mà được biểu diễn thành nhiều record.

Có thể hình dung XML2:

XML2 - Thuốc
│
├── Dòng 1: Thuốc A
├── Dòng 2: Thuốc B
├── Dòng 3: Thuốc C
└── ...

Và XML3:

XML3 - DVKT/VTYT
│
├── Dòng 1: Xét nghiệm/DVKT A
├── Dòng 2: Siêu âm B
├── Dòng 3: Vật tư C
└── ...

Điều này rất quan trọng trong kiểm tra xuất toán.

Một hồ sơ có thể hoàn toàn hợp lệ về tổng thể nhưng chỉ một dòng thuốc hoặc một dòng dịch vụ có vấn đề.

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

lỗi hồ sơ và lỗi từng record chi phí.

8. Tầng thứ năm: Field - đơn vị nhỏ nhất nhưng lại quyết định rất nhiều

Bên trong mỗi record là các trường dữ liệu, thường được gọi là field.

Ví dụ trong XML2 có thể gặp các trường như:

MA_LK
STT
MA_THUOC
TEN_THUOC
HAM_LUONG
DUONG_DUNG
SO_LUONG
DON_GIA
...

Mỗi field không chỉ có một cái tên.

Trong phụ lục chuẩn dữ liệu, một chỉ tiêu thường được quy định ít nhất theo các thành phần:

Tên chỉ tiêu → Kiểu dữ liệu → Kích thước tối đa → Diễn giải.

Ví dụ, trong Bảng 4, MA_LK là chuỗi và được mô tả là mã đợt điều trị dùng để liên kết Bảng 1 với các bảng còn lại; MA_DICH_VU là mã dịch vụ kỹ thuật cận lâm sàng; GIA_TRI dùng ghi giá trị kết quả. 130_QD-BYT_m_551553

Vì vậy, khi nói một field “đúng”, cần kiểm tra nhiều lớp chứ không chỉ xem nó có giá trị hay không.

9. Một field cần được đọc theo ít nhất 8 câu hỏi

Khi phân tích từng trường trong các bài tiếp theo của chuyên đề, chúng ta sẽ lần lượt trả lời:

1. Field này tên gì?

Ví dụ:

MA_LK, MA_BENH_CHINH, MA_THUOC, MA_DICH_VU, NGAY_YL...

2. Thuộc bảng nào?

Cùng một khái niệm có thể xuất hiện ở nhiều bảng nhưng có mục đích hoặc cách sử dụng khác nhau.

3. Kiểu dữ liệu là gì?

Có thể là:

• chuỗi;
• số;
• dữ liệu ngày giờ;
• hoặc dạng khác theo đặc tả.

4. Kích thước tối đa bao nhiêu?

“50 ký tự” hoặc “255 ký tự” thường là kích thước tối đa, không mặc nhiên có nghĩa phải đủ chính xác từng ấy ký tự.

5. Field dùng để biểu diễn điều gì?

Đây là phần diễn giải nghiệp vụ.

6. Khi nào phải có?

Một trường có thể:

• luôn phải có;
• chỉ bắt buộc trong một điều kiện;
• được để trống trong một số trường hợp;
• hoặc không phát sinh.

7. Giá trị lấy theo danh mục nào?

Đây là lớp rất quan trọng.

Một giá trị có thể đúng cú pháp nhưng không thuộc danh mục đang có hiệu lực.

8. Field này phải phù hợp với những field nào khác?

Đây chính là kiểm tra quan hệ liên trường và liên bảng.

10. Cùng một field có thể đúng về cú pháp nhưng sai về nghiệp vụ

Giả sử một trường mã khoa chứa giá trị:

K13

Hệ thống có thể thấy:

• đây là chuỗi;
• độ dài hợp lệ;
• không chứa ký tự bất thường.

Như vậy field có thể đúng về mặt kỹ thuật.

Nhưng còn phải kiểm tra:

• mã K13 có tồn tại trong danh mục áp dụng hay không;
• có đúng khoa thực tế điều trị không;
• danh mục đó đã có hiệu lực tại thời điểm hồ sơ chưa;
• hoạt động chuyên môn có phù hợp với khoa đó không.

Tương tự với mã thuốc hoặc dịch vụ:

“Có mã” không đồng nghĩa với “đúng mã”; “đúng mã” cũng chưa đồng nghĩa với “đủ điều kiện thanh toán”.

Đây chính là lý do tiền giám định phải đi xa hơn kiểm tra cú pháp XML.

11. Quan hệ giữa XML1 và các bảng chi tiết

Có thể coi XML1 là bản tổng hợp trung tâm của một đợt KCB.

Các bảng còn lại bổ sung chi tiết cho những nội dung đã phát sinh.

Một mô hình đơn giản:

                         ┌── XML2: Thuốc
                         │
                         ├── XML3: DVKT - VTYT
                         │
XML1: Tổng hợp hồ sơ ────┼── XML4: Cận lâm sàng
                         │
                         ├── XML5: Diễn biến
                         │
                         ├── XML7/8: Hồ sơ, chứng từ
                         │
                         └── XML13/14/... khi có phát sinh

MA_LK giúp nối các nhánh dữ liệu này về cùng một đợt KCB.

Từ đó có thể thực hiện nhiều kiểm tra rất quan trọng, chẳng hạn:

• thuốc ở XML2 có thuộc đúng hồ sơ XML1 hay không;
• dịch vụ ở XML3 có phù hợp với chẩn đoán của hồ sơ hay không;
• kết quả ở XML4 có tương ứng dịch vụ đã ghi nhận hay không;
• thời điểm chỉ định, thực hiện và diễn biến có hợp lý hay không;
• tổng tiền ở XML1 có khớp với dữ liệu chi tiết hay không.

Đây chính là bước chuyển từ kiểm tra từng field riêng lẻ sang kiểm tra toàn bộ hồ sơ như một hệ thống dữ liệu.

12. Ba dạng quan hệ cần đặc biệt chú ý

Khi học cấu trúc XML, có thể chia quan hệ dữ liệu thành ba nhóm.

Quan hệ trong cùng một record

Ví dụ:

SO_LUONG × DON_GIA → THANH_TIEN

Các giá trị trong cùng dòng phải hợp lý với nhau.

Quan hệ giữa nhiều record trong cùng một bảng

Ví dụ:

• cùng một dịch vụ có bị ghi trùng không;
• số lần thực hiện có vượt điều kiện hay tần suất cho phép không;
• thuốc có nhiều dòng sử dụng theo thời gian.

Quan hệ giữa nhiều bảng

Ví dụ:

XML1 chẩn đoán
       ↓
XML3 dịch vụ
       ↓
XML4 kết quả

hoặc:

XML1 loại hình điều trị
       ↓
XML3 ngày giường
       ↓
thời gian vào - ra viện

Nhóm thứ ba chính là nơi rất nhiều quy tắc tiền giám định có giá trị.

13. Cấu trúc XML thay đổi theo thời gian

Một trong những nguyên tắc quan trọng nhất khi xây dựng phần mềm kiểm tra dữ liệu BHYT là không coi cấu trúc XML là bất biến.

Quyết định 4750/QĐ-BYT sửa đổi, bổ sung Quyết định 130 và đồng thời quy định những nội dung không được sửa đổi thì tiếp tục giữ nguyên theo Quyết định 130. 4750_QD-BYT_593340

Quyết định 3176/QĐ-BYT tiếp tục sửa đổi, bổ sung các bảng chỉ tiêu; những nội dung không được sửa đổi vẫn giữ nguyên theo Quyết định 4750 và Quyết định 130. 3176_QD-BYT_629410

Sau đó vẫn có thể tiếp tục xuất hiện:

• thay đổi diễn giải của field;
• thay đổi kiểu dữ liệu;
• tăng kích thước;
• thay đổi danh mục;
• bổ sung giá trị;
• bãi bỏ bảng;
• bổ sung bảng mới.

Vì vậy, một rule kiểm tra tốt phải trả lời được:

Hồ sơ phát sinh ngày nào?

Tại thời điểm đó phiên bản chuẩn nào đang áp dụng?

Danh mục nào đang có hiệu lực?

14. Vì sao cần hiểu cấu trúc trước khi nói đến xuất toán?

Khi BHXH cảnh báo một hồ sơ, chỉ biết “XML lỗi” là chưa đủ.

Cần xác định lỗi nằm ở đâu trong cấu trúc:

FILE
 ↓
HỒ SƠ
 ↓
BẢNG
 ↓
RECORD
 ↓
FIELD

Sau đó mới xác định bản chất:

Sai cú pháp?
      ↓
Sai danh mục?
      ↓
Sai quan hệ dữ liệu?
      ↓
Không khớp hồ sơ bệnh án?
      ↓
Không đáp ứng điều kiện thanh toán?

Đây là hai chuỗi hoàn toàn khác nhau.

Một lỗi field có thể chỉ cần hiệu chỉnh dữ liệu.

Nhưng cũng có trường hợp field đó phản ánh một vấn đề thực sự trong hoạt động chuyên môn hoặc điều kiện thanh toán.

Do đó:

Tìm được field sai chưa phải là kết thúc kiểm tra; đó chỉ là điểm bắt đầu để tìm nguyên nhân.

15. Cách chuyên đề này sẽ đi sâu vào từng XML

Sau bài tổng quan này, phần “Cấu trúc XML” sẽ không dừng ở việc liệt kê tên các bảng.

Mỗi XML sẽ được phân tích theo hai lớp.

Lớp 1 - Tổng quan bảng

Với mỗi bảng sẽ làm rõ:

• mục đích;
• trường hợp phát sinh;
• quan hệ với các bảng khác;
• nguồn dữ liệu trong HIS/EMR;
• những nhóm field chính;
• nhóm lỗi thường gặp;
• ý nghĩa đối với giám định, thanh toán.

Lớp 2 - Từ điển từng field

Mỗi field sẽ được phân tích thống nhất theo cấu trúc:

Tên trường → căn cứ pháp lý → kiểu dữ liệu → kích thước → ý nghĩa → điều kiện ghi → danh mục tham chiếu → nguồn dữ liệu → quan hệ với field khác → nguy cơ sai sót → lịch sử thay đổi.

Nhờ đó, người đọc có thể sử dụng chuyên đề theo hai cách:

đọc để hiểu hệ thống, hoặc tra cứu nhanh một field cụ thể khi phát hiện lỗi.

16. Điều quan trọng nhất cần ghi nhớ

Cấu trúc XML BHYT có thể được cô đọng thành một nguyên tắc:

Một đợt khám chữa bệnh được biểu diễn bằng nhiều bảng; mỗi bảng gồm các bản ghi; mỗi bản ghi gồm nhiều trường; các trường và các bảng phải liên kết, thống nhất và phản ánh đúng thực tế khám chữa bệnh.

Vì vậy, kiểm tra XML không nên chỉ là:

“Field này có trống không?”

mà phải tiến tới:

“Giá trị này có đúng không → có đúng danh mục không → đúng thời điểm không → có phù hợp các field khác không → có khớp hồ sơ bệnh án không → và cuối cùng có đáp ứng điều kiện thanh toán hay không?”

Đó chính là nền tảng để từ việc đọc XML tiến tới tiền giám định XML, và xa hơn là cảnh báo nguy cơ trước khi hồ sơ được gửi đề nghị thanh toán.