Sau khi xác định được thuốc nào ở Bài 1.15, bước tiếp theo là xác định thuốc đó có căn cứ pháp lý và căn cứ cung ứng nào để xuất hiện trong XML2.

Ba trường đặc biệt quan trọng là:

Ngoài ra, chính MA_THUOC cũng có nhiều quy ước mã hóa đặc thù đối với thuốc tự bào chế, khí y tế, máu, chế phẩm máu và một số khoản chi liên quan.

Điểm cần nhớ là:

Một thuốc có tên và hoạt chất đúng chưa đủ. XML2 còn phải phản ánh đúng căn cứ lưu hành, nhập khẩu, mua sắm và nguồn cung ứng tương ứng với thuốc thực tế đã sử dụng.

1. SO_DANG_KY — số đăng ký không phải lúc nào cũng là một số đăng ký lưu hành thông thường

SO_DANG_KY là trường Chuỗi, kích thước tối đa 255 ký tự.

Theo Bảng 2, trường hợp thông thường ghi số đăng ký lưu hành của thuốc do cơ quan quản lý dược có thẩm quyền cấp và không chèn khoảng trắng giữa các ký tự. Tuy nhiên, chuẩn còn quy định nhiều trường hợp đặc thù.

Có thể hiểu theo logic:

Thuốc có số đăng ký lưu hành?
        │
        ├── Có → ghi số đăng ký
        │
        └── Không
             ↓
      Có thuộc trường hợp đặc biệt?
             ↓
      áp dụng quy tắc mã hóa tương ứng

Do đó không nên viết rule:

SO_DANG_KY rỗng → lỗi

cho tất cả các dòng XML2.

2. Những trường hợp không bắt buộc có SO_DANG_KY

Bảng 2 nêu một số trường hợp trường này không bắt buộc, như:

• khí oxy;
• khí nitric oxide;
• máu và chế phẩm máu;
• thuốc thang;
• thuốc phóng xạ chưa thuộc trường hợp được cấp đăng ký lưu hành.

Ngoài ra còn có hướng dẫn riêng đối với dược liệu, vị thuốc cổ truyền, thuốc cổ truyền và thuốc do cơ sở KBCB tự bào chế, pha chế hoặc chế biến.

Đây tiếp tục là ví dụ của nguyên tắc:

Cùng một field nhưng yêu cầu ghi dữ liệu phụ thuộc vào loại thuốc.

3. Thuốc chưa có đăng ký lưu hành nhưng có giấy phép nhập khẩu

Quyết định 3176 bổ sung trường hợp thuốc chưa được cấp giấy phép đăng ký lưu hành nhưng được cơ quan quản lý dược cấp giấy phép nhập khẩu.

Khi đó SO_DANG_KY được mã hóa theo cấu trúc:

KD.YYYY.X.S

Trong đó:

KD   = ký hiệu trường hợp nhập khẩu
YYYY = năm cấp giấy phép
X    = số giấy phép nhập khẩu
S    = số thứ tự thuốc trong giấy phép

Như vậy đây không phải số đăng ký lưu hành theo nghĩa thông thường mà là mã dữ liệu được xây dựng từ giấy phép nhập khẩu.

Ví dụ minh họa giả định:

KD.2026.123.05

Không nên tạo chuỗi này từ dữ liệu nhập tay tùy ý. HIS hoặc phần mềm dược cần lấy các thành phần từ hồ sơ pháp lý đã được quản lý trong danh mục thuốc.

4. Thuốc hiếm được cấp phép nhập khẩu ở cấp tỉnh

Trong bảng tổng hợp chuẩn dữ liệu đang sử dụng của dự án có ghi nhận cập nhật theo Quyết định 1931/QĐ-BYT ngày 29/6/2026: trường hợp thuốc hiếm được UBND cấp tỉnh cấp phép đơn hàng nhập khẩu, SO_DANG_KY được mã hóa:

UBND.YYYY.X.S

với:

YYYY = năm cấp phép
X    = số văn bản cấp phép nhập khẩu
S    = số thứ tự thuốc trong văn bản

Về quản trị rule, đây là ví dụ rõ ràng cho yêu cầu version-aware. Không thể sử dụng một regex duy nhất cho SO_DANG_KY ở mọi thời kỳ.

Lưu ý về nguồn: nội dung cập nhật sau 3176 này đang được thể hiện trong bảng tổng hợp đối chiếu của dự án; khi sử dụng làm căn cứ pháp lý chính thức trong rule thanh toán, nên gắn trực tiếp văn bản Quyết định 1931 tương ứng vào dr5_legal_basis.

5. Thuốc tự bào chế, pha chế và dược liệu

Ở chuẩn gốc có quy ước mã hóa thuốc tự bào chế, pha chế, chế biến theo các tiền tố như:

HD
CP
VT

kết hợp mã cơ sở KBCB, năm và số thứ tự thuốc trong danh mục được cơ sở phê duyệt.

Ví dụ cấu trúc:

CP.<MA_CSKCB>.<YY>.<STT>

Bên cạnh đó, phần sửa đổi sau này còn quy định riêng trường hợp thuốc do cơ sở KBCB tự bào chế, pha chế từ nguyên liệu làm thuốc thì ghi số đăng ký của nguyên liệu làm thuốc; đối với dược liệu có hướng dẫn mã hóa riêng.

Điều này cho thấy phải xác định trước:

Thuốc thành phẩm?
Thuốc nhập khẩu?
Thuốc tự bào chế?
Nguyên liệu làm thuốc?
Dược liệu?
Vị thuốc?

rồi mới chọn quy tắc SO_DANG_KY.

Không nên lấy một quy tắc của nhóm này áp sang nhóm khác.

6. TT_THAU — thông tin thầu là một cấu trúc, không phải văn bản tự do

TT_THAU có kích thước tối đa 50 ký tự.

Cấu trúc cơ bản gồm:

Số quyết định;
Mã gói thầu;
Mã nhóm thầu;
Năm ban hành

Các thành phần được phân cách bằng dấu chấm phẩy ;.

Ví dụ minh họa:

123/QD-ABC;G1;N2;2026

Đây chỉ là ví dụ cấu trúc, không phải dữ liệu của một thuốc thực tế.

Ý nghĩa quan trọng của TT_THAU là giúp truy ngược dòng thuốc đến căn cứ mua sắm tương ứng với mặt hàng và đơn giá.

7. Khi có nhiều nhà thầu cùng trúng một thuốc

Chuẩn quy định thêm thành phần để phân biệt nhà thầu trong trường hợp cùng một thuốc có nhiều nhà thầu trúng thầu.

Cấu trúc bổ sung có dạng:

Gi.YY

và được đặt sau các thành phần thông tin thầu cơ bản.

Ví dụ dạng:

...;G2.01
...;G2.02

để phân biệt các nhà thầu tương ứng.

Điều này đặc biệt quan trọng bởi hai mặt hàng có thể:

cùng hoạt chất
cùng hàm lượng
cùng dạng bào chế

nhưng thuộc nhà thầu hoặc giá trúng thầu khác nhau.

Nếu HIS chỉ lưu một mã thuốc chung mà không giữ được lô/căn cứ thầu thực tế, dữ liệu XML rất dễ ánh xạ sai TT_THAU và DON_GIA.

8. Trường hợp áp thầu

Khi áp dụng kết quả lựa chọn nhà thầu của đơn vị khác, chuẩn yêu cầu bổ sung mã đơn vị ban hành quyết định.

Ví dụ về nguyên tắc:

TTMSTT quốc gia → 00

đấu thầu tập trung địa phương
→ mã tỉnh/thành phố

quyết định của cơ sở KBCB
→ mã cơ sở KBCB

Như vậy:

Cùng một số quyết định thầu nhưng thiếu phần xác định đơn vị áp thầu có thể không đủ để nhận diện đúng căn cứ mua sắm.

9. Thuốc tự bào chế và TT_THAU

Thuốc tự bào chế, pha chế hoặc chế biến không nhất thiết có một kết quả đấu thầu giống thuốc mua ngoài.

Bảng 2 hướng dẫn trường hợp này ghi:

Số văn bản;Năm

theo văn bản của cơ sở gửi cơ quan BHXH.

Đây là lý do không thể áp rule:

TT_THAU phải luôn có 4 thành phần

cho toàn bộ XML2.

Rule phải biết loại thuốc và cách hình thành nguồn thuốc trước.

10. Thuốc đàm phán giá

Phần bổ sung tại Quyết định 4750 nêu trường hợp thuốc đàm phán giá thì bổ sung mã đơn vị thực hiện đàm phán giá; Trung tâm mua sắm tập trung thuốc quốc gia sử dụng mã 00.

Đây cũng là một ví dụ cho thấy TT_THAU phải được giải mã theo hình thức mua sắm thực tế, chứ không chỉ kiểm tra độ dài chuỗi.

11. MA_CSKCB_THUOC — mã hóa nguồn/cơ sở liên quan đến thuốc

Đây là trường chỉ phát sinh trong những tình huống đặc biệt.

Một số quy ước được chuẩn mô tả gồm:

Trong đó XXXXX là mã cơ sở KBCB tương ứng.

Đáng chú ý, Quyết định 4750 từng bổ sung cấu trúc HC.XXXXX cho hội chẩn từ xa; phần sửa đổi tại 3176 chuyển sang hướng dẫn H.XXXXX và bãi bỏ hướng dẫn bổ sung đó của Quyết định 4750.

Đây là một ví dụ rất rõ:

Mã đúng ở phiên bản cũ có thể trở thành mã không còn đúng ở phiên bản mới.

12. Các quy ước đặc thù ngay trong MA_THUOC

MA_THUOC cũng không phải lúc nào chỉ là một mã hoạt chất đơn.

Chuẩn có các hướng dẫn như:

40.17   → khí oxy
40.573  → khí NO

và với máu/chế phẩm máu có thể xuất hiện phần bổ sung:

.KT
.NAT
.KTNAT

tùy tình huống.

Ngoài ra còn có các cấu trúc:

VM.XXXXX

cho chi phí vận chuyển máu và:

BB.XXXXX

cho chi phí bao bì thuốc thang theo hướng dẫn của Bảng 2.

Quyết định 3176 cũng thay đổi cách xử lý hoạt chất ngoài danh mục đối với thuốc tự bào chế, pha chế: thay vì tiếp tục dùng mã tạm thời 00.0000, sử dụng cấu trúc dựa trên năm và số đăng ký nguyên liệu theo hướng dẫn mới.

Do đó rule không được chỉ kiểm tra:

MA_THUOC có trong một danh mục duy nhất?

mà phải hiểu các namespace/quy tắc mã hóa đặc biệt được chuẩn cho phép.

13. Quan hệ giữa SO_DANG_KY, TT_THAU và mặt hàng thuốc

Ba lớp thông tin cần khớp:

MA_THUOC
TEN_THUOC
HAM_LUONG
DANG_BAO_CHE
        ↓
SO_DANG_KY
        ↓
TT_THAU
        ↓
DON_GIA

Ví dụ, một bất thường rất đáng kiểm tra là:

SO_DANG_KY thuộc mặt hàng A
TT_THAU thuộc mặt hàng B
DON_GIA thuộc mặt hàng C

trong khi XML vẫn ghi cùng MA_THUOC.

Nếu chỉ kiểm tra mã hoạt chất, lỗi này có thể hoàn toàn bị bỏ sót.

Vì vậy đối tượng cần đối chiếu trong tiền giám định không chỉ là hoạt chất, mà là mặt hàng thuốc pháp lý – mua sắm – giá.

14. Những lỗi dữ liệu thường gặp

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

• SO_DANG_KY không đúng với thuốc thực tế;
• sử dụng số đăng ký đã hết hoặc không phù hợp thời điểm hồ sơ;
• thuốc nhập khẩu theo giấy phép nhưng XML lại ghi như thuốc đã có đăng ký lưu hành;
• cấu trúc KD.YYYY.X.S không khớp hồ sơ giấy phép;
• sử dụng cấu trúc đặc thù nhưng không thuộc trường hợp được phép;
• TT_THAU thiếu gói, nhóm, năm hoặc đơn vị áp thầu;
• TT_THAU không tương ứng với mặt hàng và đơn giá;
• dùng thông tin thầu cũ khi đã chuyển sang kết quả mua sắm khác;
• MA_CSKCB_THUOC sử dụng quy ước của phiên bản pháp lý cũ;
• thuốc chuyển từ cơ sở khác nhưng nguồn thuốc và thông tin thầu không thống nhất.

Các trường hợp trên trước hết là bất thường dữ liệu/căn cứ pháp lý cần kiểm tra. Không nên tự động đồng nhất tất cả với một khoản xuất toán nếu chưa xác định điều kiện thanh toán và chứng cứ thực tế.

15. Cách thiết kế tiền giám định

Đây là nhóm không nên hard-code hàng trăm cấu trúc trực tiếp trong source code.

Phù hợp hơn là đưa các quy tắc vào hệ thống danh mục:

dr5_xml_field
        ↓
field nào, kiểu nào, điều kiện nào

dr5_catalog_binding
        ↓
MA_THUOC ↔ SO_DANG_KY ↔ TT_THAU ↔ mặt hàng

dr5_payment_condition
        ↓
điều kiện phạm vi và thanh toán

dr5_legal_basis
        ↓
văn bản + phiên bản + ngày hiệu lực

Ví dụ rule engine chỉ cần thực hiện:

Xác định loại thuốc/tình huống
        ↓
Xác định ngày KCB
        ↓
chọn quy tắc có hiệu lực
        ↓
kiểm tra SO_DANG_KY
        ↓
kiểm tra TT_THAU
        ↓
kiểm tra mặt hàng + DON_GIA
        ↓
đối chiếu chứng cứ nếu bất thường

Khi có quy định mới về nhập khẩu hoặc mã hóa, chủ yếu cập nhật danh mục kiểm tra, không phải viết lại toàn bộ rule.

Kết luận

Ở XML2, SO_DANG_KY và TT_THAU là hai lớp dữ liệu giúp trả lời:

Thuốc này được phép lưu hành/nhập khẩu trên căn cứ nào?
Thuốc này được cơ sở có được và tính giá trên căn cứ mua sắm nào?

Trong khi MA_CSKCB_THUOC và các quy ước đặc biệt của MA_THUOC xử lý những tình huống không thể mô tả bằng mã thuốc thông thường.

Có thể tóm tắt:

Nhận diện thuốc → căn cứ pháp lý → nguồn cung ứng → thông tin thầu → đơn giá → thanh toán.

Một dòng XML2 chỉ thực sự đáng tin cậy khi chuỗi này liên tục và truy ngược được đến dữ liệu nguồn.