Mỗi bảng XML của Bộ Y tế thực chất là một bảng đặc tả dữ liệu. Muốn đọc đúng XML, trước hết phải hiểu cách đọc từng dòng chỉ tiêu trong bảng.
Các bảng thường có những cột cơ bản như:
STT – Chỉ tiêu – Kiểu dữ liệu – Kích thước tối đa – Diễn giải.
Quyết định 130/QĐ-BYT quy định chi tiết các chỉ tiêu dữ liệu trong từng bảng tại các phụ lục kèm theo.
Có thể hiểu mỗi dòng trong bảng như một “hợp đồng dữ liệu” quy định field đó tên gì, nhận loại dữ liệu nào, dài tối đa bao nhiêu và phải ghi như thế nào.
1. Cột “Chỉ tiêu”: tên của trường dữ liệu
Cột Chỉ tiêu chính là tên field khi biểu diễn trong XML.
Ví dụ:
MA_LK
STT
MA_BN
HO_TENTrong bảng chỉ tiêu, MA_LK được quy định là mã đợt điều trị duy nhất; MA_BN là mã người bệnh; HO_TEN là họ và tên người bệnh.
Khi xuất ra XML, tên chỉ tiêu trở thành tên thẻ:
<MA_LK>...</MA_LK>
<MA_BN>...</MA_BN>
<HO_TEN>...</HO_TEN>Tên field phải được đọc và sử dụng đúng theo chuẩn, không nên tự đổi tên theo cách gọi nội bộ của HIS.
Một điểm dễ nhầm là cột STT ở đầu bảng chỉ đơn thuần là số thứ tự của chỉ tiêu. Trong một số bảng lại có một field tên là STT. Ví dụ trong Bảng 1, chỉ tiêu thứ 2 chính là field STT, có kiểu dữ liệu số và dùng để đánh số thứ tự trong lần gửi dữ liệu.
2. Cột “Kiểu dữ liệu”: field được phép chứa loại dữ liệu gì
Các kiểu thường gặp gồm:
- Chuỗi
- Số
Không nên suy luận kiểu dữ liệu chỉ dựa vào ý nghĩa của field.
Ví dụ một trường biểu diễn ngày giờ vẫn có thể được quy định là Chuỗi. Trường NGAY_YL trong XML3 được quy định kiểu Chuỗi, kích thước 12 và nội dung phải ghi theo cấu trúc yyyymmddHHMM.
Do đó:
Ý nghĩa nghiệp vụ của dữ liệu và kiểu dữ liệu kỹ thuật là hai vấn đề khác nhau.
Một field là ngày tháng không có nghĩa phần mềm được tùy ý lưu dưới kiểu Date hoặc định dạng dd/mm/yyyy khi xuất XML.
3. Cột “Kích thước tối đa”: giới hạn độ dài, không phải độ dài bắt buộc
Nếu bảng quy định:
MA_LK | Chuỗi | 100thì hiểu rằng giá trị của MA_LK có kích thước tối đa 100 ký tự.
Không nên hiểu:
100nghĩa là field phải đủ đúng 100 ký tự.
Tương tự:
HO_TEN | Chuỗi | 255không có nghĩa họ tên phải có 255 ký tự.
Tuy nhiên, nếu phần Diễn giải lại quy định một định dạng có số ký tự cụ thể thì phải tuân theo phần diễn giải đó.
Ví dụ NGAY_YL có kích thước tối đa 12 và đồng thời phần diễn giải quy định thời điểm ra y lệnh gồm 12 ký tự theo cấu trúc yyyymmddHHMM. Trong trường hợp này, định dạng 12 ký tự là yêu cầu nghiệp vụ cụ thể chứ không chỉ là giới hạn kỹ thuật.
Đây là lý do không thể đọc riêng cột “Kích thước tối đa” mà bỏ qua “Diễn giải”.
4. Cột “Diễn giải”: phần quan trọng nhất
Cột Diễn giải cho biết cách sử dụng thực tế của field.
Phần này có thể quy định:
- ý nghĩa của field;
- định dạng giá trị;
- danh mục mã phải sử dụng;
- trường hợp bắt buộc ghi;
- trường hợp được để trống;
- cách ghi khi có nhiều giá trị;
- ngoại lệ;
- mối quan hệ với field khác;
- văn bản chuyên ngành được dẫn chiếu.
Ví dụ, MA_LK không chỉ được mô tả là một chuỗi tối đa 100 ký tự mà còn được xác định là mã đợt điều trị duy nhất, dùng để liên kết XML1 với các bảng còn lại.
Với HO_TEN, phần diễn giải còn quy định cách ghi đối với một số trường hợp trẻ sơ sinh chưa được cấp thẻ BHYT.
Như vậy, chỉ nhìn tên field và kiểu dữ liệu là chưa đủ.
Phần diễn giải mới quyết định field phải được hiểu và ghi nhận như thế nào trong nghiệp vụ.
5. Một field phải được đọc theo cả một dòng
Ví dụ:
MA_LK | Chuỗi | 100 | Mã đợt điều trị duy nhất...Không nên tách thành các thông tin rời rạc.
Cách đọc đúng là:
MA_LKlà một field kiểu Chuỗi, kích thước tối đa 100 ký tự, có ý nghĩa là mã đợt điều trị duy nhất và dùng để liên kết dữ liệu giữa XML1 và các bảng khác trong cùng một lần KCB.
Tương tự:
NGAY_YL | Chuỗi | 12 | Ghi thời điểm ra y lệnh theo yyyymmddHHMMphải được hiểu đồng thời cả bốn thành phần.
6. Không được suy ra “bắt buộc” chỉ từ tên field
Một field xuất hiện trong bảng chỉ tiêu không đồng nghĩa với việc mọi hồ sơ đều bắt buộc phải có giá trị tại field đó.
Điều kiện ghi thường nằm trong phần diễn giải hoặc ghi chú.
Có field chỉ cần ghi khi:
- phát sinh một loại dịch vụ cụ thể;
- có thực hiện phẫu thuật, thủ thuật;
- có chuyển cơ sở;
- có hẹn khám lại;
- có tình huống chuyên biệt.
Do đó, muốn kết luận một field bị “thiếu” phải kiểm tra thêm:
Field đó có bắt buộc trong chính trường hợp này hay không?
Nội dung bắt buộc, bắt buộc có điều kiện, được để trống và không phát sinh sẽ được phân tích riêng tại Bài 1.7.
7. Kiểu dữ liệu, kích thước và diễn giải có thể được sửa đổi
Một field không phải lúc nào cũng giữ nguyên đặc tả qua các phiên bản.
Các văn bản sửa đổi có thể:
- đổi kiểu dữ liệu;
- tăng hoặc giảm kích thước tối đa;
- sửa toàn bộ diễn giải;
- bổ sung lưu ý;
- thay đổi danh mục tham chiếu.
Trong phụ lục sửa đổi của bộ chuẩn có trường hợp một chỉ tiêu được đổi kiểu dữ liệu thành Chuỗi và tăng kích thước tối đa lên 255 ký tự, đồng thời sửa nội dung diễn giải.
Vì vậy khi đọc một bảng chỉ tiêu, không nên chỉ mở bản gốc của Quyết định 130 mà phải đọc cùng các văn bản sửa đổi, bổ sung còn hiệu lực.
Đây chính là nguyên tắc đã nêu ở Bài 1.2:
Field phải được đọc theo đúng phiên bản pháp lý tại thời điểm áp dụng.
8. Cách đọc nhanh một field
Khi gặp một field mới, có thể lần lượt đặt 5 câu hỏi:
- Tên field là gì?
- Kiểu dữ liệu là gì?
- Kích thước tối đa bao nhiêu?
- Diễn giải yêu cầu ghi như thế nào?
- Nội dung này đã bị sửa đổi hoặc bổ sung ở văn bản nào sau đó chưa?
Chỉ sau khi trả lời đủ các câu hỏi trên mới nên kết luận dữ liệu đúng hay sai.
Kết luận
Một dòng chỉ tiêu XML không chỉ là tên một cột dữ liệu.
Có thể ghi nhớ:
Tên trường cho biết “đây là dữ liệu gì”; kiểu dữ liệu cho biết “được biểu diễn bằng dạng nào”; kích thước tối đa cho biết “giới hạn bao nhiêu”; còn diễn giải cho biết “phải ghi như thế nào và trong trường hợp nào”.
Trong đó, Diễn giải là phần cần đọc kỹ nhất, bởi đây thường là nơi chứa điều kiện nghiệp vụ, ngoại lệ, cách mã hóa và các văn bản được dẫn chiếu.
- Đăng nhập để gửi ý kiến
