Thẻ dữ liệu, UTF-8, ký tự đặc biệt, CDATA và Base64
Để đọc được XML BHYT, ngoài việc hiểu ý nghĩa nghiệp vụ của từng field, cần nắm một số khái niệm kỹ thuật cơ bản. Đây là những thành phần giúp hệ thống đóng gói, biểu diễn và truyền dữ liệu đúng cấu trúc.
Thông tư 48/2017/TT-BYT quy định sử dụng ngôn ngữ XML để định dạng dữ liệu điện tử và UTF-8 để biểu diễn ký tự Unicode.
Có thể bắt đầu từ một ví dụ đơn giản:
<MA_LK>000001813969</MA_LK>
<HO_TEN><![CDATA[NGUYỄN VĂN A]]></HO_TEN>
<MA_BENH_CHINH>L40.0</MA_BENH_CHINH>1. Thẻ dữ liệu XML
XML biểu diễn dữ liệu bằng các thẻ mở và thẻ đóng.
Ví dụ:
<MA_BENH_CHINH>L40.0</MA_BENH_CHINH>Trong đó:
<MA_BENH_CHINH>là thẻ mở;L40.0là giá trị;</MA_BENH_CHINH>là thẻ đóng.
Tên thẻ tương ứng với tên field trong bảng chỉ tiêu của Bộ Y tế.
Một trường không có giá trị có thể được biểu diễn dạng:
<MA_KHU_VUC />hoặc về mặt XML tương đương:
<MA_KHU_VUC></MA_KHU_VUC>Tuy nhiên, field rỗng có được phép hay không lại là vấn đề nghiệp vụ, phải đối chiếu diễn giải của từng chỉ tiêu chứ không thể chỉ dựa vào cú pháp XML.
2. Các thẻ được tổ chức theo cấu trúc lồng nhau
XML không chỉ là danh sách các field đứng riêng lẻ. Các thẻ có thể chứa các thẻ con để tạo thành cấu trúc.
Ví dụ một bảng thuốc có thể được tổ chức dạng:
<CHITIEU_CHITIET_THUOC>
<DSACH_CHI_TIET_THUOC>
<CHI_TIET_THUOC>
<MA_LK>...</MA_LK>
<STT>1</STT>
<MA_THUOC>...</MA_THUOC>
...
</CHI_TIET_THUOC>
</DSACH_CHI_TIET_THUOC>
</CHITIEU_CHITIET_THUOC>Trong các gói XML thực tế được cung cấp, có thể thấy cấu trúc ngoài chứa thông tin đơn vị, hồ sơ và các FILEHOSO; từng FILEHOSO lại xác định LOAIHOSO như XML1, XML2, XML3...
Do đó, khi XML lỗi đóng/mở thẻ hoặc sai cấu trúc lồng nhau, hệ thống có thể không đọc được dữ liệu dù giá trị bên trong từng field là đúng.
3. UTF-8: để tiếng Việt được biểu diễn đúng
Thông tư 48 quy định dữ liệu XML sử dụng bảng mã UTF-8.
Điều này đặc biệt quan trọng với tiếng Việt.
Ví dụ:
<HO_TEN>Nguyễn Văn An</HO_TEN>Nếu phần mềm tạo file hoặc đọc file sử dụng sai bảng mã, dữ liệu có thể bị biến thành ký tự lỗi, mất dấu hoặc không được hệ thống tiếp nhận đúng.
Ở đầu file XML thường gặp khai báo:
<?xml version="1.0" encoding="utf-8"?>File XML thực tế trong bộ dữ liệu cũng sử dụng khai báo encoding="utf-8".
4. Ký tự đặc biệt trong XML
Một số ký tự có ý nghĩa riêng đối với cú pháp XML nên không thể luôn ghi trực tiếp trong nội dung.
Các ký tự thường gặp gồm:
< > & " 'Đặc biệt:
<được dùng để bắt đầu thẻ;>kết thúc phần tên thẻ;&bắt đầu một thực thể XML.
Ví dụ nếu nội dung thực tế là:
A & Bthì khi ghi trực tiếp trong XML thông thường, dấu & cần được mã hóa phù hợp, chẳng hạn:
<TEN_DICH_VU>A & B</TEN_DICH_VU>Tương tự, ký tự < trong nội dung có thể được biểu diễn bằng:
<Đây là vấn đề cú pháp XML, khác với các ký hiệu < hoặc > mà Bộ Y tế có thể sử dụng trong phần diễn giải nghiệp vụ của bảng chỉ tiêu. Quyết định 130, chẳng hạn, có ghi chú riêng về ý nghĩa của các ký hiệu *, > và < trong bảng.
5. CDATA: giữ nguyên một đoạn văn bản
Khi một field chứa nội dung văn bản dài hoặc có các ký tự dễ xung đột với cú pháp XML, có thể gặp cấu trúc:
<![CDATA[
Nội dung văn bản
]]>Ví dụ:
<HO_TEN><![CDATA[TRẦN MINH XUYÊN]]></HO_TEN>hoặc:
<DIEN_BIEN_LS><![CDATA[
Người bệnh tỉnh, tiếp xúc tốt...
]]></DIEN_BIEN_LS>Các file XML thực tế được cung cấp có sử dụng CDATA trong các trường như họ tên, chẩn đoán và diễn biến lâm sàng.
CDATA có thể hiểu đơn giản là:
“Hãy coi phần bên trong là nội dung văn bản, không diễn giải các ký tự XML thông thường bên trong nó.”
CDATA đặc biệt hữu ích với các trường có nội dung tự do như:
- diễn biến lâm sàng;
- chẩn đoán;
- phương pháp điều trị;
- ghi chú;
- tên hoặc mô tả có ký tự đặc biệt.
Nhưng CDATA không làm thay đổi ý nghĩa nghiệp vụ của dữ liệu. Sau khi đọc XML, hệ thống vẫn phải lấy nội dung thật bên trong field để kiểm tra.
6. Base64: mã hóa dữ liệu để đưa vào gói XML
Trong gói XML thực tế, nội dung của từng XML1, XML2, XML3... có thể không xuất hiện trực tiếp dưới dạng XML dễ đọc mà nằm trong trường:
<NOIDUNGFILE>...</NOIDUNGFILE>với nội dung dạng:
77u/PD94bWwgdmVyc2lvbj0iMS4wIi...Đây là dạng Base64. Sau khi giải mã, chuỗi đó trở lại nội dung XML thực sự của XML1, XML2... Gói dữ liệu thực tế được cung cấp thể hiện rõ LOAIHOSO đi cùng NOIDUNGFILE chứa dữ liệu được mã hóa theo cách này.
Có thể hình dung:
XML1 gốc
↓
mã hóa Base64
↓
NOIDUNGFILE
↓
gửi trong gói XML
↓
giải mã Base64
↓
XML1 để xử lýBase64 không phải là mã hóa bảo mật và không làm dữ liệu trở thành bí mật. Đây chủ yếu là cách biến nội dung thành chuỗi ký tự thuận tiện để đóng gói và truyền trong một cấu trúc khác.
7. Không được nhầm các lớp dữ liệu
Khi xem file bằng trình soạn thảo văn bản, có thể thấy một chuỗi Base64 rất dài và tưởng rằng dữ liệu XML bị “mã hóa không đọc được”.
Thực tế có thể đang có nhiều lớp:
GÓI XML
│
└── FILEHOSO
│
├── LOAIHOSO = XML2
│
└── NOIDUNGFILE = Base64
│
↓ giải mã
XML2 thực sự
│
├── thẻ XML
├── field
└── CDATA...Vì vậy, khi xây dựng công cụ đọc XML cần thực hiện đúng thứ tự:
đọc gói → xác định loại hồ sơ → lấy nội dung → giải mã Base64 nếu có → parse XML bên trong → đọc từng record và field.
8. Ý nghĩa đối với kiểm tra dữ liệu
Các thành phần kỹ thuật trên tạo thành tầng kiểm tra đầu tiên:
- XML có parse được không?
- encoding có đúng UTF-8 không?
- thẻ mở/đóng có đúng không?
- ký tự đặc biệt có làm hỏng cấu trúc không?
- CDATA có hợp lệ không?
- Base64 có giải mã được không?
- nội dung sau giải mã có phải XML hợp lệ không?
Chỉ sau khi vượt qua tầng này mới có thể tiếp tục kiểm tra: field → danh mục → quan hệ dữ liệu → điều kiện nghiệp vụ → điều kiện thanh toán.
Kết luận
Có thể ghi nhớ ngắn gọn:
Thẻ XML tạo cấu trúc; UTF-8 bảo đảm biểu diễn ký tự; escape xử lý ký tự đặc biệt; CDATA bảo vệ nội dung văn bản; Base64 giúp đóng gói nội dung để truyền.
Đây đều là vấn đề kỹ thuật biểu diễn dữ liệu. Một file có thể hoàn toàn đúng ở tầng này nhưng dữ liệu nghiệp vụ bên trong vẫn sai.
Vì vậy, trong hệ thống tiền giám định cần tách rõ:
Lỗi kỹ thuật XML ≠ lỗi nghiệp vụ ≠ chi phí không đủ điều kiện thanh toán.
- Đăng nhập để gửi ý kiến
