Mã thuốc, tên thuốc, đơn vị tính, hàm lượng, đường dùng và dạng bào chế

Trong XML2, một thuốc không được nhận diện chỉ bằng tên. Bộ dữ liệu sử dụng đồng thời nhiều thuộc tính để mô tả thuốc nào đang được sử dụng và đang được đề nghị thanh toán.

Sáu trường cốt lõi gồm:

Các trường này được quy định trong Bảng 2 và phải được đọc cùng các sửa đổi, bổ sung của bộ chuẩn.

Có thể ghi nhớ:

MA_THUOC cho biết thuốc được mã hóa như thế nào; TEN_THUOC cho biết tên gì; HAM_LUONG cho biết mạnh bao nhiêu; DON_VI_TINH cho biết đang tính theo đơn vị nào; DUONG_DUNG cho biết sử dụng bằng đường nào; DANG_BAO_CHE cho biết thuốc tồn tại dưới dạng gì.

1. MA_THUOC — không đơn giản là “mã sản phẩm thuốc”

Bảng 2 quy định MA_THUOC ghi mã hoạt chất theo Bộ mã danh mục dùng chung của Bộ Y tế.

Điều này rất quan trọng vì MA_THUOC không nên được hiểu mặc nhiên là:

mã nội bộ của bệnh viện,

hay:

mã hàng trong phần mềm kho dược.

HIS có thể có một mã nội bộ riêng, nhưng khi xuất XML phải ánh xạ sang mã được bộ chuẩn yêu cầu.

Đối với thuốc do cơ sở KBCB tự bào chế, pha chế, các hoạt chất hoặc thành phần được ghi nối bằng dấu +. Sau sửa đổi tại Quyết định 3176, thành phần nằm ngoài danh mục thuộc phạm vi thanh toán BHYT được mã hóa theo cấu trúc được quy định thay vì cách mã tạm thời trước đó. Với thuốc thành phẩm không thuộc phạm vi chi trả của quỹ BHYT, hướng dẫn cập nhật cho phép để trống MA_THUOC.

Vì vậy rule kiểu:

MA_THUOC rỗng → lỗi

sẽ không chính xác nếu không xét loại thuốc và phạm vi thanh toán.

2. MA_THUOC có nhiều trường hợp mã hóa đặc biệt

Bảng 2 còn có hướng dẫn riêng đối với:

• khí oxy;
• khí nitric oxide;
• máu và chế phẩm máu;
• các khoản liên quan đến xét nghiệm bổ sung đối với máu;
• chi phí vận chuyển máu;
• bao bì thuốc thang;
• thuốc tự bào chế, pha chế.

Điều này cho thấy không thể kiểm tra MA_THUOC chỉ bằng một regex duy nhất.

Logic đúng hơn là:

Xác định loại thuốc/khoản chi
        ↓
Xác định quy tắc mã hóa áp dụng
        ↓
Tra danh mục đúng phiên bản
        ↓
Kiểm tra MA_THUOC

Đây là trường rất phù hợp với catalog_lookup kết hợp conditional_constraint.

3. TEN_THUOC — tên thuốc

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

Bảng 2 yêu cầu ghi tên thuốc theo đúng tên được cơ quan quản lý có thẩm quyền cấp đăng ký; trường hợp thuốc do cơ sở KBCB tự bào chế, chế biến thì sử dụng tên theo hồ sơ đã được người đứng đầu cơ sở phê duyệt.

Như vậy:

MA_THUOC

và:

TEN_THUOC

không phải hai cách ghi cùng một thông tin.

MA_THUOC phục vụ mã hóa và đối chiếu danh mục.

TEN_THUOC phục vụ mô tả tên thuốc cụ thể.

Một bất thường thường gặp là mã hoạt chất thuộc thuốc này nhưng tên thuốc lại thuộc thuốc khác. Vì vậy hai trường cần được kiểm tra quan hệ với nhau thông qua danh mục thuốc của cơ sở và dữ liệu danh mục chuẩn.

4. DON_VI_TINH — đơn vị dùng để tính số lượng

DON_VI_TINH không đơn giản là đơn vị đóng gói của nhà sản xuất.

Bảng 2 quy định đây là đơn vị tính nhỏ nhất, tương ứng với thuốc thực tế sử dụng cho người bệnh.

Đặc biệt, trường hợp thuốc được đóng chai, lọ, túi hoặc ống nhưng khi sử dụng được chia nhỏ theo:

UI

hoặc:

ml

thì đơn vị tính phải được ghi theo đơn vị thực tế đó.

Ví dụ:

Thuốc mua: 1 lọ 10 ml
Thực tế sử dụng: 2 ml

thì dữ liệu chi phí phải được tổ chức sao cho:

DON_VI_TINH
SO_LUONG
DON_GIA

cùng phản ánh một đơn vị quy đổi thống nhất.

Nếu:

DON_VI_TINH = ml

nhưng:

DON_GIA = giá cả lọ

thì dù từng field riêng lẻ có vẻ hợp lệ, THANH_TIEN_BV vẫn có thể sai.

Do đó:

Đơn vị tính là một thành phần trực tiếp của công thức thanh toán, không chỉ là thông tin mô tả thuốc.

5. HAM_LUONG — hàm lượng thuốc

HAM_LUONG được ghi theo thông tin thuốc tương ứng với kết quả trúng thầu, giấy đăng ký lưu hành, nội dung điều chỉnh hợp pháp hoặc hồ sơ thuốc do cơ sở tự bào chế.

Nếu thuốc có nhiều hoạt chất/thành phần, các hàm lượng được phân cách bằng dấu +. Đối với một số thuốc YHCT, quy định còn yêu cầu thể hiện khối lượng từng dược liệu/thành phần.

Ví dụ về cấu trúc:

MA_THUOC
A + B

HAM_LUONG
500mg + 125mg

Về quản trị dữ liệu, cần bảo đảm việc ghép nhiều thành phần không làm mất quan hệ giữa hoạt chất và hàm lượng tương ứng.

Một điểm rất quan trọng từ sửa đổi tại Quyết định 3176 là một số đối tượng được phép để trống HAM_LUONG, gồm khí y tế, máu và chế phẩm máu, vị thuốc cổ truyền.

Vì vậy:

HAM_LUONG rỗng không phải lúc nào cũng là thiếu dữ liệu.

6. DUONG_DUNG — đây là mã đường dùng

DUONG_DUNG có kích thước tối đa 4 ký tự trong Bảng 2.

Trường này ghi mã đường dùng, tương ứng với đường dùng của thuốc theo thông tin đăng ký hoặc hồ sơ được phê duyệt đối với thuốc cơ sở tự bào chế, chế biến.

Điểm cần nhấn mạnh là:

DUONG_DUNG không phải trường văn bản tự do để nhập “uống”, “tiêm”, “truyền” tùy ý.

Nó phải được đối chiếu với danh mục mã đường dùng áp dụng.

Ví dụ về logic kiểm tra:

MA_THUOC
    ↓
thuốc cụ thể
    ↓
đường dùng được phép
    ↓
DUONG_DUNG

Nếu danh mục thuốc xác định một chế phẩm chỉ dùng ngoài nhưng XML lại mang mã đường tiêm, đây là bất thường rất đáng cảnh báo.

7. DANG_BAO_CHE — dạng bào chế hoặc chế biến

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

Đối với thuốc hóa dược, trường này ghi dạng bào chế.

Đối với thuốc cổ truyền và thuốc dược liệu, trường có thể phản ánh dạng bào chế hoặc chế biến theo hồ sơ tương ứng.

Thuốc do cơ sở KBCB tự bào chế, chế biến phải ghi theo hồ sơ đã được người đứng đầu cơ sở phê duyệt.

Ví dụ:

Viên nén
Viên nang cứng
Dung dịch tiêm
Bột pha tiêm
Dung dịch uống
Thuốc mỡ
...

DANG_BAO_CHE cần được đọc cùng DUONG_DUNG.

Ví dụ:

DANG_BAO_CHE = Thuốc mỡ
DUONG_DUNG   = mã tiêm tĩnh mạch

là tổ hợp bất thường rõ ràng cần kiểm tra.

8. Sáu trường phải được xem như một “bộ nhận diện”

Sai lầm thường gặp là kiểm tra:

MA_THUOC có trong danh mục?

nếu có thì cho rằng thuốc đã hợp lệ.

Trên thực tế nên kiểm tra tổ hợp:

MA_THUOC
     ↕
TEN_THUOC
     ↕
HAM_LUONG
     ↕
DON_VI_TINH
     ↕
DUONG_DUNG
     ↕
DANG_BAO_CHE

Ví dụ một mã hoạt chất có thể xuất hiện ở nhiều thuốc:

cùng hoạt chất
│
├── 5 mg
├── 10 mg
├── viên uống
├── dung dịch
└── dạng tiêm

Do đó, xác nhận MA_THUOC đúng mới chỉ là bước đầu tiên.

9. Chưa đủ để nhận diện chính xác một sản phẩm thuốc thanh toán

Ngay cả sáu field của bài này vẫn chưa phải toàn bộ căn cứ nhận diện một thuốc cụ thể trong thanh toán.

Còn phải xem thêm:

SO_DANG_KY
TT_THAU
MA_CSKCB_THUOC
PHAM_VI
DON_GIA

Ví dụ hai thuốc có thể cùng:

MA_THUOC
HAM_LUONG
DUONG_DUNG
DANG_BAO_CHE

nhưng khác:

SO_DANG_KY
TT_THAU
DON_GIA

Do đó trong hệ thống tiền giám định, cần phân biệt:

nhận diện hoạt chất/đặc tính thuốc

với:

nhận diện chính xác mặt hàng thuốc có căn cứ pháp lý và giá thanh toán.

Phần đăng ký, nhập khẩu và thông tin thầu sẽ được trình bày riêng ở Bài 1.16.

10. Nguồn dữ liệu trong bệnh viện

Sáu trường này thường không nên để bác sĩ nhập lại thủ công toàn bộ trên từng y lệnh.

Luồng dữ liệu tốt hơn là:

Danh mục thuốc bệnh viện
        ↓
đã ánh xạ với danh mục chuẩn
        ↓
bác sĩ chọn thuốc
        ↓
HIS lấy tự động:
MA_THUOC
TEN_THUOC
DON_VI_TINH
HAM_LUONG
DUONG_DUNG
DANG_BAO_CHE
        ↓
XML2

Bác sĩ lựa chọn thuốc và chỉ định sử dụng; còn các thuộc tính chuẩn của mặt hàng nên được lấy từ master data đã kiểm soát.

Nếu cho phép nhập tự do, rất dễ xuất hiện:

một thuốc
→ nhiều cách viết tên
→ nhiều hàm lượng
→ nhiều đường dùng
→ nhiều dạng bào chế

dẫn tới bất nhất XML.

11. Các kiểm tra rất phù hợp để tự động hóa

Đây là nhóm field rất phù hợp với cơ chế catalog-driven.

Thay vì viết:

Nếu MA_THUOC = X
thì HAM_LUONG phải = Y

cho từng thuốc, nên có danh mục kiểm tra, chẳng hạn:

dr5_drug
dr5_drug_active_ingredient
dr5_drug_route
dr5_drug_dosage_form
dr5_drug_unit
dr5_drug_mapping

Mỗi record có thể chứa:

ma_thuoc
ten_thuoc
ham_luong
don_vi_tinh
duong_dung
dang_bao_che
so_dang_ky
effective_from
effective_to
legal_basis

Rule engine chỉ thực hiện logic chung:

Tìm thuốc trong danh mục
        ↓
lấy candidate phù hợp ngày KCB
        ↓
đối chiếu các thuộc tính
        ↓
không khớp → cảnh báo

Như vậy khi danh mục thuốc thay đổi, hệ thống chủ yếu cập nhật dr5_..., không phải sửa code.

12. Cần phân biệt mức độ cảnh báo

Không phải mọi khác biệt tên thuốc hoặc cách viết đều là căn cứ từ chối thanh toán.

Ví dụ:

Lỗi kỹ thuật/danh mục mạnh: DUONG_DUNG chứa mã không tồn tại.

Bất nhất dữ liệu: MA_THUOC và HAM_LUONG không phù hợp với mặt hàng đã ánh xạ.

Cần rà soát: tên thuốc khác cách viết trong danh mục nhưng các thuộc tính khác vẫn xác định được cùng một thuốc.

Nguy cơ thanh toán: thuốc không phù hợp danh mục, phạm vi, điều kiện hoặc căn cứ pháp lý áp dụng.

Hệ thống nên tách các mức này thay vì gắn mọi khác biệt là “xuất toán”.

Kết luận

Một dòng thuốc trong XML2 không được nhận diện bởi một field duy nhất.

Có thể ghi nhớ:

MA_THUOC = mã hóa
TEN_THUOC = tên
HAM_LUONG = hàm lượng
DON_VI_TINH = đơn vị tính thực tế
DUONG_DUNG = mã đường sử dụng
DANG_BAO_CHE = dạng của thuốc

Sáu trường này phải phù hợp với nhau và phù hợp với danh mục thuốc có hiệu lực tại thời điểm KCB.

Đây là nguyên tắc quan trọng để tránh tình trạng XML có “mã thuốc đúng” nhưng thực tế lại đang mô tả một mặt hàng, hàm lượng, đường dùng hoặc dạng bào chế khác.