Bắt buộc, bắt buộc có điều kiện, được để trống và không phát sinh
Một lỗi thường gặp khi kiểm tra XML là áp dụng nguyên tắc quá đơn giản:
“Field có trong chuẩn thì hồ sơ nào cũng phải có dữ liệu.”
Cách hiểu này không đúng.
Trong bộ chuẩn XML BHYT, việc một bảng có phải gửi hay không và một field có phải có giá trị hay không phụ thuộc vào loại hồ sơ, hoạt động thực tế đã phát sinh và điều kiện được quy định trong phần diễn giải của từng chỉ tiêu.
Vì vậy, trước khi kết luận “thiếu dữ liệu”, cần phân biệt ít nhất bốn trạng thái: bắt buộc → bắt buộc có điều kiện → được để trống → không phát sinh.
1. Trước hết phải xác định bảng có cần gửi hay không
Quyết định 130/QĐ-BYT quy định đối với các Bảng 1 đến Bảng 11, tùy vào đối tượng và mục đích của người bệnh trong đợt KCB, cơ sở KBCB gửi dữ liệu của các bảng liên quan.
Như vậy, không thể lấy danh sách XML1 đến XML15 rồi yêu cầu mọi hồ sơ đều phải có đủ tất cả các bảng.
Ví dụ, Bảng 4 về dữ liệu cận lâm sàng chỉ được gửi khi người bệnh có thực hiện dịch vụ cận lâm sàng.
Bảng 5 về diễn biến lâm sàng cũng chỉ được gửi trong những loại hình điều trị được quy định, như điều trị ngoại trú, nội trú, nội trú ban ngày, điều trị lưu tại trạm y tế/phòng khám khu vực hoặc nội trú dưới 4 giờ.
Đối với Bảng 14, quy định ghi rõ chỉ trích chuyển khi có hẹn khám lại cho người bệnh.
Do đó, bước kiểm tra đầu tiên phải là:
Với đợt KCB này, bảng dữ liệu đó có thuộc phạm vi phải phát sinh hay không?
Chỉ khi câu trả lời là “có” mới tiếp tục kiểm tra các field bên trong.
2. Field bắt buộc
Một field được coi là bắt buộc khi, trong phạm vi áp dụng của bảng và tình huống cụ thể, quy định yêu cầu phải có thông tin và không có ngoại lệ cho phép bỏ trống.
Không nên chỉ nhìn thấy một field trong bảng rồi mặc nhiên gắn nhãn “required”.
Phải đọc đầy đủ:
- diễn giải của field;
- ghi chú cuối bảng;
- các điều kiện liên quan;
- các sửa đổi, bổ sung;
- thời điểm áp dụng.
Đặc biệt, từ “Ghi...” trong phần diễn giải cho biết cách ghi dữ liệu, nhưng muốn kết luận field bắt buộc trong mọi trường hợp vẫn cần xem toàn bộ điều kiện của chỉ tiêu đó.
Đây là điểm rất quan trọng khi xây dựng phần mềm kiểm tra, vì nếu gắn nhầm một field là bắt buộc tuyệt đối sẽ tạo ra rất nhiều cảnh báo giả.
3. Bắt buộc có điều kiện
Đây là nhóm xuất hiện rất nhiều trong XML BHYT.
Field chỉ phải ghi khi một điều kiện nhất định xảy ra.
Ví dụ trong Bảng 12, trường DANG_KHUYETTAT chỉ ghi khi thực hiện khám giám định người khuyết tật; trường TONG_TYLE_TTCT chỉ ghi trong một số hình thức giám định nhất định.
Hay trong XML3, quy định có thể nêu một field không bắt buộc trong trường hợp chuyển gửi xét nghiệm cận lâm sàng.
Logic kiểm tra khi đó phải là:
Nếu điều kiện A xảy ra
↓
field X phải có dữ liệu
Nếu điều kiện A không xảy ra
↓
không được kết luận thiếu field XĐây chính là khái niệm conditional required - bắt buộc có điều kiện.
4. Field được phép để trống
Một trường hợp khác là bảng vẫn phải gửi, field vẫn nằm trong cấu trúc, nhưng quy định cho phép giá trị của field để trống.
Ví dụ Bảng 4 quy định:
DON_VI_DO: nếu chỉ số không có đơn vị đo thì để trống;MO_TA: trường hợp không có kết quả thì để trống;KET_LUAN: trong những trường hợp được quy định có thể để trống;GIA_TRI,NGAY_KQ: có tình huống người bệnh đã kết thúc đợt KCB nhưng kết quả chưa có tại thời điểm gửi dữ liệu ban đầu, được để trống và bổ sung sau theo quy định.
Tương tự, với một số thông tin hành chính, nếu người bệnh không cung cấp hoặc tình huống không áp dụng thì quy định cho phép để trống. Ví dụ số điện thoại chỉ ghi khi người bệnh cung cấp; mã thẻ BHYT được để trống đối với người bệnh không KCB BHYT.
Do đó:
Field rỗng không mặc nhiên là lỗi.
Phải biết tại sao field rỗng và quy định có cho phép rỗng trong trường hợp đó hay không.
5. “Để trống” khác với “không phát sinh”
Hai khái niệm này cần phân biệt rõ.
Để trống
Field thuộc bảng đang phát sinh, nhưng trong tình huống cụ thể không có giá trị cần ghi.
Ví dụ:
<DON_VI_DO />Bảng 4 vẫn tồn tại, dòng kết quả vẫn tồn tại, chỉ riêng DON_VI_DO không có giá trị vì chỉ số đó không có đơn vị đo.
Không phát sinh
Bản thân bảng hoặc dòng dữ liệu không có lý do để tồn tại.
Ví dụ:
- không thực hiện CLS → không phát sinh Bảng 4;
- không hẹn khám lại → không phát sinh Bảng 14;
- không điều trị bệnh lao → không phát sinh dữ liệu Bảng 15 theo phạm vi tương ứng. Quy định của Bảng 15 gắn việc gửi bảng với trường hợp có điều trị người bệnh lao.
Như vậy:
Không phát sinh không phải là một field rỗng; đó là không có record hoặc không có bảng tương ứng.
6. Cũng phải phân biệt “rỗng” với “thiếu field”
Về mặt kỹ thuật, ba trạng thái sau không hoàn toàn giống nhau:
<MA_KHU_VUC />là field có tồn tại nhưng giá trị rỗng.
Trong khi:
Không có thẻ <MA_KHU_VUC> trong recordlà field bị thiếu khỏi cấu trúc.
Còn:
Không có record hoặc không có bảng tương ứnglà không phát sinh dữ liệu ở cấp cao hơn.
Việc ba cách biểu diễn này có được chấp nhận hay không phải căn cứ vào chuẩn kỹ thuật và diễn giải của từng bảng/field.
Không nên tự động coi chúng là tương đương.
7. Không có dữ liệu cũng không đồng nghĩa với giá trị bằng 0
Đây là một nguyên tắc quan trọng khi kiểm tra dữ liệu.
Ví dụ:
field rỗngkhác với:
field = 00 là một giá trị cụ thể.
Rỗng có thể mang ý nghĩa:
- chưa có thông tin;
- không áp dụng;
- không phát sinh;
- được phép bổ sung sau;
- hoặc dữ liệu bị thiếu.
Ý nghĩa nào đúng phải căn cứ vào diễn giải của field.
Do đó, phần mềm không nên tự động thay tất cả giá trị rỗng bằng 0 để “đủ dữ liệu”.
8. Cách kiểm tra đúng phải theo thứ tự
Khi kiểm tra một field, thứ tự hợp lý là:
Bước 1: Bảng này có phải phát sinh không?
Bước 2: Record này có phải phát sinh không?
Bước 3: Field này có áp dụng cho record đó không?
Bước 4: Nếu áp dụng, field có bắt buộc có giá trị không?
Bước 5: Nếu được để trống, điều kiện cho phép để trống có thực sự thỏa mãn không?
Bước 6: Nếu có giá trị, mới tiếp tục kiểm tra kiểu dữ liệu, định dạng, danh mục và logic.
Tức là không nên kiểm tra theo kiểu:
field rỗng
↓
báo lỗimà phải là:
Xác định phạm vi áp dụng
↓
Xác định điều kiện
↓
Xác định yêu cầu có dữ liệu
↓
Kiểm tra giá trị9. Ý nghĩa đối với tiền giám định bằng CNTT
Đây là một trong những nội dung rất quan trọng khi xây dựng rule.
Không nên viết hàng nghìn rule kiểu:
Nếu FIELD_X rỗng → cảnh báoThay vào đó nên tách logic kiểm tra khỏi danh mục điều kiện.
Ví dụ về nguyên tắc:
TABLE_APPLICABLE?
↓
FIELD_APPLICABLE?
↓
FIELD_REQUIRED?
↓
FIELD_VALUE_VALID?Các thông tin như:
- bảng nào áp dụng cho loại hồ sơ nào;
- field nào bắt buộc;
- field nào bắt buộc có điều kiện;
- trường hợp nào được để trống;
- thời điểm hiệu lực;
nên được quản lý trong các danh mục kiểm tra dr5_....
Khi Bộ Y tế thay đổi diễn giải của một field, hệ thống chủ yếu cập nhật danh mục điều kiện và phiên bản hiệu lực, thay vì sửa lại toàn bộ code.
Kết luận
Khi nhìn thấy một field không có dữ liệu, câu hỏi đầu tiên không nên là:
“Tại sao thiếu?”
mà nên là:
“Trong trường hợp này, field đó có thực sự phải có dữ liệu không?”
Có thể ghi nhớ bốn trạng thái:
Bắt buộc: phải có.
Bắt buộc có điều kiện: chỉ phải có khi điều kiện xảy ra.
Được để trống: field áp dụng nhưng quy định cho phép không có giá trị.
Không phát sinh: bảng, record hoặc field không thuộc tình huống thực tế.
Phân biệt đúng bốn trạng thái này giúp tránh cả hai sai lầm: bỏ sót dữ liệu thực sự bắt buộc và cảnh báo sai đối với dữ liệu vốn được phép không có.
Đây cũng là nguyên tắc nền tảng để xây dựng hệ thống kiểm tra XML có độ chính xác cao và hạn chế cảnh báo giả.
- Đăng nhập để gửi ý kiến
