Download luận văn thạc sĩ ngành công nghệ thông tin với đề tài: Phân tích và xây dựng chức năng giám định tự động trong hệ thống giám định bảo hiểm xã hội, cho các bạn làm luận văn tham khảo

1. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
PHAN VĂN NAM
PHÂN TÍCH VÀ XÂY DỰNG
CHỨC NĂNG GIÁM ĐỊNH TỰ ĐỘNG
TRONG HỆ THỐNG GIÁM ĐỊNH BẢO HIỂM XÃ HỘI
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
Hà Nội -2017

2. ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
PHAN VĂN NAM
PHÂN TÍCH VÀ XÂY DỰNG
CHỨC NĂNG GIÁM ĐỊNH TỰ ĐỘNG
TRONG HỆ THỐNG GIÁM ĐỊNH BẢO HIỂM XÃ HỘI
Ngành: Công nghệ Thông tin
Chuyên ngành: Kỹ Thuật Phần Mềm
Mã số: 60.48.01.03
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. NGUYỄN VIỆT ANH
Hà Nội -2017

3. 1
LỜI CAM ĐOAN
Tôi xin cam đoan, đây là công trình nghiên cứu của bản thân, các số liệu các
đoạn mã chương trình của ứng dụng, các kết quả trình bày trong luận văn là trung
thực và chưa từng được ai công bố trong bất kỳ công trình luận văn nào trước đây.
Tác giả luận văn
Phan Văn Nam

4. 2
LỜI CẢM ƠN
Trước tiên tôi xin chân thành cảm ơn đến thầy giáo TS. Nguyễn Việt Anh-
người đã tận tình chỉ bảo và giúp đỡ tôi trong suốt quá trình thực hiện đề tài luận văn
thạc sĩ cho đến khi hoàn thành đề tài.
Tôi xin bày tỏ lòng biết ơn chân thành tới các thầy cô giáo khoa Công nghệ
thông tin, trường Đại học Công nghệ, Đại học Quốc Gia Hà Nội - nơi tôi đã theo học
trong những năm qua. Các thầy cô đã dạy và cung cấp những kiến thức, tạo điều
kiện tốt nhất cho tôi trong suốt quá trình học tập và nghiên cứu tại trường.
Sau cùng tôi xin chân thành cảm ơn những người thân trong gia đình, cảm ơn
bạn bè cùng khóa, đồng nghiệp trong cơ quan đã giúp đỡ tôi trong quá trình học tập
và nghiên cứu thực hiện luận văn này.
Tuy nhiên, trong quá trình làm luận văn tôi cũng đã rất cố gắng nghiên cứu,
tìm hiểu các vấn đề liên quan song luận văn vẫn chưa thực sự được hoàn chỉnh, vẫn
còn những thiếu sót nhất định. Tôi rất mong nhận được những ý kiến đánh giá, góp
ý của các thầy cô giáo, các bạn để luận văn được hoàn thiện hơn.
Hà nội, tháng 11 năm 2017
Học viên
Phan Văn Nam

5. 3
MỤC LỤC
LỜI CAM ĐOAN ......................................................................................................1
LỜI CẢM ƠN ............................................................................................................2
MỤC LỤC..................................................................................................................3
BẢNG CÁC KÝ HIỆU VÀ VIẾT TẮT....................................................................6
DANH MỤC HÌNH VẼ.............................................................................................7
MỞ ĐẦU....................................................................................................................9
CHƯƠNG 1: GIỚI THIỆU BẢO HIỂM Y TẾ VÀ QUY TRÌNH GIÁM ĐỊNH
BẢO HIỂM Y TẾ ....................................................................................................12
1.1. Quá trình hình thành Bảo hiểm y tế ở Việt Nam ........................................12
1.2. Vận hành Bảo hiểm y tế ở Việt Nam ..........................................................12
1.2.1. Về độ bao phủ Bảo hiểm y tế ở Việt Nam............................................12
1.2.2. Thực hiện nguyên lý chia sẻ của BHYT...............................................13
1.2.3. Về quyền lợi bệnh nhân, hiệu quả BHYT.............................................13
1.2.4. Về quản lý quỹ Bảo hiểm y tế...............................................................14
1.3. Quy trình giám định bảo hiểm y tế tại cơ quan bảo hiểm xã hội................15
1.4. Kết luận .......................................................................................................16
CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE -ORIENTED
ARCHITECTURE)..................................................................................................17
2.1. Dịch vụ ........................................................................................................17
2.2. Các đặc điểm chính của dịch vụ..................................................................17
2.2.1. Có ranh giới rõ ràng..............................................................................17
2.2.2. Tính tự trị ..............................................................................................17
2.2.3. Chia sẻ lược đồ......................................................................................17
2.2.4. Tính tương thích của dịch vụ dựa trên chính sách................................18
2.3. Kiến trúc hướng dịch vụ..............................................................................18
2.4. Các tính chất của một hệ thống SOA..........................................................19
2.4.1. Kết nối lỏng lẻo.....................................................................................19

6. 4
2.4.2. Sử dụng lại dịch vụ ...............................................................................19
2.4.3. Sử dụng dịch vụ bất đồng bộ ................................................................19
2.4.4. Quản lý các chính sách..........................................................................20
2.4.5. Khả năng cộng tác.................................................................................20
2.4.6. Tự dò tìm và ràng buộc động................................................................20
2.4.7. Khả năng tự phục hồi............................................................................20
2.5. Kiến trúc phân tầng chi tiết SOA ................................................................20
2.5.1. Tầng kết nối...........................................................................................21
2.5.2. Tầng orchestration.................................................................................22
2.5.3. Tầng ứng dụng tổng hợp.......................................................................22
2.6. Các bước triển khai một ứng dụng theo mô hình SOA...............................22
2.7. Kết luận .......................................................................................................24
CHƯƠNG 3: PHÂN TÍCH VÀ XÂY DỰNG CHỨC NĂNG GIÁM ĐỊNH TỰ
ĐỘNG ......................................................................................................................25
3.1. Giới thiệu hệ thống Giám định bảo hiểm và bài toán giám định tự động...25
3.1.1. Giới thiệu hệ thống giám định ..............................................................25
3.1.2. Bài toán giám định tự động...................................................................27
3.2. Phân tích và xây dựng chức năng giám định tự động.................................28
3.2.1. Giám định hồ sơ....................................................................................30
3.2.2. Giám định danh mục.............................................................................55
3.3. Kết luận .......................................................................................................71
CHƯƠNG 4: CÀI ĐẶT, TRIỂN KHAI VÀ THỰC NGHIỆM GIÁM ĐỊNH TỰ
ĐỘNG ......................................................................................................................72
4.1. Cài đặt..........................................................................................................72
4.1.1. Giám định hồ sơ....................................................................................72
4.1.1.1. GetDataKB.........................................................................................72
4.1.1.2. ProcessDataKB ..................................................................................73
4.1.1.3. SendDataKB ......................................................................................75
4.1.2. Giám định danh mục.............................................................................76

7. 5
4.1.2.1. GetData ..............................................................................................76
4.1.2.2. ProcessData........................................................................................78
4.1.2.3. SendData............................................................................................79
4.2. Triển khai.....................................................................................................80
4.3. Kết quả thực nghiệm ...................................................................................82
4.4. Kết luận .......................................................................................................84
KẾT LUẬN..............................................................................................................85
TÀI LIỆU THAM KHẢO .......................................................................................86
PHỤ LỤC.................................................................................................................87

8. 6
BẢNG CÁC KÝ HIỆU VÀ VIẾT TẮT
STT Thuật ngữ viết tắt Thuật ngữ đầy đủ
1 BHYT Bảo hiểm y tế
2 BHXH Bảo hiểm xã hội
3 CSKCB Cơ sở khám chữa bệnh
4 CSYT Chính sách y tế
5 DVKT Dịch vụ kỹ thuật
6 HĐBT Hội đồng bộ trưởng
7 KCB Khám chữa bệnh
8 VTYT Vật tư y tế

9. 7
DANH MỤC HÌNH VẼ
STT Số hiệu Tên hình vẽ
1 Hình 1.1 Quy trình giám định bảo hiểm y tế
2 Hình 2.1 Sơ đồ cộng tác trong SOA
3 Hình 2.2 Kiến trúc phân tầng của hệ thống SOA
4 Hình 3.1 Hệ thống giám định bảo hiểm xã hội VN
5 Hình 3.2 Biểu đồ usecase các chức năng chính của hệ thống
giám định
6 Hình 3.3 Mô hình cơ sở dữ liệu
7 Hình 3.4 Phân rã domain thành một dãy các vùng chức năng
liên quan
8 Hình 3.5 Biểu đồ tuần tự service GetDataKB
9 Hình 3.6 Biểu đồ tuần tự service ProcessDataKB
10 Hình 3.7 Biểu đồ tuần tự service SendDataKB
11 Hình 3.8 Sơ sồ hoạt động tổng quan của RabbitMQ
12 Hình 3.9 Sơ đồ hoạt động của RabbitMQ về việc phân phối
các bản tin
13 Hình 3.10 Màn hình tổng quan quản lý Rabbit MQ
14 Hình 3.11 Phân rã domain giám định danh mục
15 Hình 3.12 Biểu đồ tuần tự service GetData
16 Hình 3.13 Biểu đồ tuần tự service ProcessData

10. 8
17 Hình 3.14 Biểu đồ tuần tự Service SendData
18 Hình 4.1 Màn hình hiển thị service GetDataKB khi quét trong
Database
19 Hình 4.2 Màn hình hiển thị của Service ProcessDataKB khi
đang giám định hồ sơ

11. 9
MỞ ĐẦU
1. Bài toán
Hiện nay Bảo hiểm y tế đóng vai trò rất quan trọng trong việc an sinh xã hội, tính
đến nay cả nước đã có hơn 80% dân số tham gia bảo hiểm y tế. Cùng theo quá trình
phát triển của đất nước thì càng ngày lượng khám chữa bệnh một ngày tăng, quy
trình thanh toán bảo hiểm theo hồ sơ giấy không thể đáp ứng được nhu cầu, vì vậy
nhu cầu thanh quyết toán điện tử chi phí khám chữa bệnh là cấp thiết. Từ nhu cầu
cấp thiết đó mà hệ thống Giám định bảo hiểm xã hội được hình thành để đáp ứng
quá trình thanh quyết toán chi phí khám chữa bệnh bảo hiểm y tế, phát hiện những
sai phạm, tránh trục lợi trong quá trình thanh quyết toán bảo hiểm y tế. Nhưng với
lượng lượt khám chữa bệnh khổng lồ, để nhằm hỗ trợ, phục vụ các giám định viên
trong quá trình giám định, việc giám định tự động qua các quy tắc có sẵn là điều tất
yếu. Đề tài “Phân tích và xây dựng chức năng giám định tự động trong hệ thống
giám định bảo hiểm xã hội” sẽ tìm hiểu cơ sở lý thuyết kiến trúc hướng dịch vụ
SOA và xây dựng chức năng giám định tự động phát hiện các sai phạm trong quá
trình giám định, hỗ trợ đắc lực cho các giám định viên phát hiện sai phạm, để việc
thanh quyết toán chi phí khám chữa bệnh bảo hiểm y tế được rõ ràng, minh bạch
tránh trục lợi.
2. Mục tiêu
Tìm hiểu cơ sở lý thuyết về kiến trúc hướng dịch vụ SOA và áp dụng xây dựng
chức năng giám định tự động cùng bộ quy tắc giám định để phát hiện sai phạm trong
quá trình thanh quyết toán hồ sơ khám chữa bệnh.
3. Phương pháp nghiên cứu
Tìm hiểu cơ sở lý thuyết về kiến trúc hướng dịch vụ SOA. Các bước xây dựng
một ứng dụng dựa trên kiến trúc hướng dịch vụ.
Áp dụng các bước xây dựng một ứng dụng dựa trên kiến trúc hướng dịch vụ, cụ thể
sẽ là phương pháp top-down để xây dựng chức năng giám định tự động gồm bộ quy
tắc giám định, phân tích xây dựng các bộ service thực hiện quét hồ sơ, tài liệu cần
được giám định. Chức năng sẽ gồm 2 bộ service: Giám định hồ sơ và giám định
danh mục.

12. 10
Giám định hồ sơ sẽ gồm bộ 3 service:
- GetDataKB: có nhiệm vụ quét các hồ sơ cần giám định và đẩy lên một queue
trên RabbitMQ
- ProcessDataKB: có nhiệm vụ lấy hồ sơ trên queue do service GetDataKB đẩy
lên để thực hiện giám định, sau khi giám định sẽ tiến hành đẩy vào một queue
trên RabbitMQ
- SendDataKB: có nhiệm vụ lấy hồ sơ trên queue do service ProcessDataKB
đẩy lên để thực hiện lưu kết quả vào Database.
Giám định danh mục sẽ gồm bộ 3 service:
- GetData: có nhiệm vụ quét các danh mục cần giám định và đẩy lên một queue
trên RabbitMQ
- ProcessData: có nhiệm vụ lấy danh mục cần giám định trên queue do service
GetData đẩy lên, sau đó thực hiện giám định và đẩy lên một queue trên
RabbitMQ
- SendData: có nhiệm vụ lấy danh mục trên queue do service ProcessData đẩy
lên để thực hiện lưu kết quả vào Database.
Áp dụng các công nghệ như RabbitMQ để giao tiếp giữa các bộ service.
4. Kết quả đạt được
Luận văn đã tìm hiểu về kiến trúc hướng dịch vụ SOA, phương pháp xây dựng
một ứng dụng dựa trên kiến trúc hướng dịch vụ. Áp dụng vào bài toán giám định tự
động.
Luận văn đã xây dựng thành công:
- Bộ service giám định hồ sơ: GetDataKB, ProcessDataKB, SendDataKB
- Bộ service giám định danh mục: GetData, ProcessData, SendData
- Bộ quy tắc hồ sơ: Quy tắc thẻ, quy tắc mức hưởng, quy tắc thuốc, quy tắc dịch
vụ kỹ thuật, quy tắc vật tư y tế và các quy tắc khác về máu, thanh toán ngày
giường
- Bộ quy tắc danh mục: Quy tắc thuốc thầu tỉnh, vật tư thầu tỉnh, thuốc bệnh
viện, dịch vụ kỹ thuật bệnh viện, vật tư y tế bệnh viện.

13. 11
Hiện tại trên toàn quốc có khoảng hơn 14 nghìn cơ sở khám chữa bệnh, với trung
bình một tháng khoảng 15 triệu hồ sơ khám chữa bệnh. Bộ service giám định hồ sơ
có thể xử lý được khoảng trên 40 hồ sơ/ giây, đóng vai trò đắc lực hỗ trợ giám định
viên phát hiện xử lý sai phạm trong quá trình thanh quyết toán bảo hiểm y tế, giúp
tiết kiệm ngân sách hàng năm của nhà nước.
5. Bố cục của luận văn
Luận văn được trình bày thành 4 chương chính:
Chương 1: Giới thiệu về bảo hiểm y tế và quy trình giám định bảo hiểm y tế
Chương 2: Kiến trúc hướng dịch vụ SOA
Chương 3: Phân tích và xây dựng chức năng giám định tự động
Chương 4: Cài đặt, triển khai và thực nghiệm giám định tự động
Xin trân trọng cảm ơn
Tác giả: Phan Văn Nam

14. 12
CHƯƠNG 1: GIỚI THIỆU BẢO HIỂM Y TẾ VÀ QUY
TRÌNH GIÁM ĐỊNH BẢO HIỂM Y TẾ
1.1. Quá trình hình thành Bảo hiểm y tế ở Việt Nam
Từ trước những năm 1985, Việt Nam áp dụng mô hình bảo hiểm mà ngân sách
nhà nước cấp cho các bệnh viện để thực hiện khám chữa bệnh để thực hiện khám
chữa bệnh miễn phí cho nhân dân. Sau khi thực hiện chính sách đổi mới, Việt Nam
dần chuyển đổi từ bước từ bao cấp cho các bệnh viện sang cơ chế BHYT. Những
bước đi chập chững BHYT ở Việt Nam là thí điểm các loại quỹ mang tính BHYT
khác nhau ở một số tỉnh như: Quỹ bảo hiểm sức khỏe Hải Phòng, Quỹ KCB nhân
đạo ở Vĩnh Phúc, Quỹ BHYT tự nguyện ở Bến Tre, Quảng Trị, Quỹ khám chữa bệnh
ngành đường sắt,… Cho đến cuối năm 2016 thì đã xây dựng được hệ thống BHYT
từ trung ương đến địa phương, đạt hơn 80% dân số tham gia BHYT.
Trong lịch sử hình thành BHYT ở Việt Nam thì vấn đề vận hành bảo hiểm y tế cũng
như quản lý quỹ luôn là một vấn đề rất nan giải.
1.2. Vận hành Bảo hiểm y tế ở Việt Nam
Sau hơn 20 năm thực hiện BHYT, đặc biệt sau 4 năm thực hiện Luật BHYT, Việt
Nam đã đạt gần 70% dân số tham gia BHYT. Với mức thu nhập chỉ 1750 USD/người
(2012) thì 70% dân số có BHYT, song với mệnh giá 575 ngàn/ thẻ BHYT trong khi
hàng chục ngàn bệnh nhân BHYT được quỹ BHYT chi trả hàng mấy trăm triệu do
sử dụng dịch vụ kỹ thuật y tế hiện đại và một số thuốc mới, đắt tiền. Thực tế cho
thấy bất kỳ một bệnh nhân nào chưa có thẻ BHYT, nếu không may bị bệnh mạn tính,
chuẩn bị đi mổ, phát hiện bị ung thư đều tìm mọi cách mua cho được thẻ BHYT. Do
đó cũng nên công bằng, toàn diện khi đánh giá về BHYT ở Việt Nam.
1.2.1. Về độ bao phủ Bảo hiểm y tế ở Việt Nam
Việc đạt tỷ lệ bao phủ BHYT ở mức được gần 70% là cố gắng lớn của Nhà nước
và mỗi người dân. Dự báo năm 2020 đạt 80% dân số có BHYT, đó là mục tiêu khả
thi và có thể còn đạt tỷ lệ BHYT lên trên 80%, vì các lý do sau:
- Gần 5 năm tham gia BHYT tự nguyên theo cá nhân, đã lộ rõ nhược điểm là
chỉ ai ốm mới mua BHYT. Vì vậy việc sửa đổi quy định thực hiện BHYT theo

15. 13
hộ gia đình sẽ khắc phục tình trạng này. Mặt khác giá dịch vụ y tế được điều
chỉnh theo lộ trình chuyển từ cấp nhân sách cho bệnh viện sang hỗ trợ nhân
dân tham gia BHYT sẽ là áp lực để người dân chủ động tham gia BHYT.
- Sửa đổi Luật BHYT sẽ tăng cường trách nhiệm chính quyền địa phương trong
quản lý quỹ, mở rộng tỷ lệ BHYT, chắc chắn sẽ có nhiều sáng tạo, đổi mới
trong việc phát triển BHYT những năm tới ở các tỉnh.
Nhà nước tiếp tục thực hiện hỗ trợ nhân dân tham gia BHYT, nhất là gia đình chính
sách, đối tượng khó khăn.
1.2.2. Thực hiện nguyên lý chia sẻ của BHYT
Nguyên lý chia sẻ của BHYT là: Đóng theo lương/thu nhập, hưởng theo bệnh.
Hiện nay BHYT thực hiện tốt và rất tốt sự chia sẻ, nhiều người đóng BHYT ở mức
khá cao (4.5% tiền lương) nhưng họ hưởng ít (vì phải cùng chi trả tới 20% chi phí
KCB), trong khi đó nhiều đối tượng chỉ đóng 3% lương tối thiểu nhưng khi đi KCB
lại được miễn, hay cùng chi trả rất ít, chỉ 5%.
Theo nguyên lý BHYT, quỹ BHYT sẽ thúc đẩy sự chia sẻ giúp đỡ của những vùng
giầu cho vùng khó khăn, điều đó mang đậm tính nhân văn. Tuy nhiên hiện nay ở
Việt Nam chưa làm được điều này vì các quỹ BHYT của tỉnh nghèo như Sơn La,
Lạng Sơn, Lao Cai, Kon Tum, Gia Lai kết dư hàng mấy trăm tỷ đồng, trong khi Cần
Thơ, Tây Ninh, Kiên Giang và nhiều tỉnh khác bị hụt quỹ hàng trăm tỷ đồng và triền
miên trong nhiều năm phải nhận sự chia sẻ của các tỉnh miền núi. Sửa Luật BHYT
chắc chắn sẽ khắc phục tình trạng này và thúc đẩy các địa phương có giải pháp hiệu
quả để mở rộng tỷ lệ bao phủ BHYT.
1.2.3. Về quyền lợi bệnh nhân, hiệu quả BHYT
Với điều kiện Kinh Tế- Xã Hội và mức thu nhập 1750 USD/người(2013), quyền
lợi hưởng BHYT khá lớn, trên cả mức dịch vụ y tế cơ bản, cụ thể:
- Danh mục thuốc thiết yếu mà Tổ chức Y tế thế giới cũng như Bộ Y tế quy
định chỉ khoảng hơn 400 loại, nhưng danh mục thuốc BHYT của Việt Nam là
gần 1143 loại. Hiện nay, BHYT Việt Nam chi trả thuốc rất đắt tiền như thuốc
chống ung thư, thải ghép với số tiền mấy trăm triệu. Cố một số bệnh nhân
được chi trả hàng tỷ đồng từ quỹ BHYT, số mấy trăm triệu thì có hàng chục
ngàn người. Vì vậy, 575.000 đồng là mức phí BHYT tự nguyện với quyền lợi
hưởng hàng trăm triệu là quá cao. Ví dụ ở Hàn Quốc, BHYT chỉ trả tiền chữa

16. 14
huyết áp cao, tiểu đường, tim mạch cho 180 ngày/năm, còn ở Việt Nam trả đủ
360 ngày/năm.
- Hiện nay trong quá trình đổi mới cơ chế tài chính y tế, bệnh viện tự chủ nên
các bệnh viện đều sáng tạo trong việc cung ứng các loại dịch vụ kỹ thuật y tế
hiện đại phục vụ bệnh nhân khiến chi phí y tế ngày càng leo thang và đắt đỏ,
gây mất cân bằng quỹ BHYT nếu như không có giải pháp kiểm soát hiệu quả.
1.2.4. Về quản lý quỹ Bảo hiểm y tế
Việt Nam đã gộp chung cả BHYT và BHXH vào một đơn vị do BHXH Việt Nam
điều hành, việc này có thể tiết kiệm được một số biên chế, trụ sở, và có thể hỗ trợ
giữa hai quỹ. Quỹ BHYT quản lý tập trung cả nước nên vai trò của chính quyền
tỉnh/thành phố rất hạn chế để mở rộng BHYT, chống lạm dụng quỹ BHYT, khi quỹ
hụt đã có Trung cấp bù, khi thừa thì chuyển đi tỉnh khác.
Việc quản lý BHYT phức tạp, đòi hỏi sự năng động gấp nhiều lần so với BHXH, vì
BHYT chỉ là quỹ ngắn hạn, phải quản lý chặt chẽ để tránh sự lạm dụng của hàng
trăm ngàn thầy thuốc, hàng ngàn bệnh viện, đòi hỏi tính chuyên nghiệp rất cao mới
sử dụng quỹ BHYT có hiệu quả. Tình trạng bán thẻ BHYT theo hộ khẩu, không tiếp
cận người mua BHYT tại cộng đồng; chỉ giám định chi BHYT của 20% hồ sơ nhưng
phải thanh toán đủ cả 100%; sau thanh kiểm tra, ở nhiều tỉnh quỹ BHYT đã hết bội
chi và có kết dữ quỹ chứng tỏ sự lạm dụng BHYT khá phổ biến ở bệnh viện. Bài
toán phức tạp này chỉ xảy ra riêng với BHYT.

17. 15
1.3. Quy trình giám định bảo hiểm y tế tại cơ quan bảo hiểm xã hội
Hình 1.1. Quy trình giám định bảo hiểm y tế.
Phòng giám định sẽ công bố danh mục thuốc, dịch vụ, vật tư được dùng chung cho
các bệnh viện. Hằng năm khi có kết quả đấu thầu, hoặc có sự thay đổi danh mục, các
cơ sở khám chữa bệnh tiến hành gửi dữ liệu danh mục cũng như hằng ngày, khi có
phát sinh hồ sơ khám chữa bệnh cơ sở sẽ gửi hồ sơ khám chữa bệnh lên để thực hiện
giám định.

18. 16
Hệ thống sẽ kiểm tra tính hợp lệ của dữ liệu cơ sở khám chữa bệnh gửi lên, nếu
không hợp lệ sẽ tiến hành trả lại dữ liệu về cơ sở khám chữa bệnh, để cơ sở thực
hiện sửa chữa và gửi lại.
Thực hiện giám định danh mục thuốc, vật tư y tế: Kiểm tra đối chiếu tên thuốc, hoạt
chất… Kiểm tra sử dụng thuốc phối hợp. Kiểm tra đối chiếu danh mục thuốc phóng
xạ, hợp chất đánh dấu. Kiểm tra đối chiếu danh mục vật tư y tế.
Thực hiện giám định giá thuốc, vật tư y tế: Kiểm tra đối chiếu giá thanh toán với kết
quả thầu. Kiểm tra xác định giá các vị thuốc YHCT có hư hao. Kiểm tra hóa đơn
mua nguyên liệu, phụ liệu bao bì với các thuốc tự bào chế. Kiểm tra đối chiếu hóa
đơn mua VTYT với kết quả thầu.
Thực hiện giám định giá dịch vụ kỹ thuật: kiểm tra xác định tính pháp lý của danh
mục. Kiểm tra đối chiếu bảng giá DVKT so với quy định của BYT.
Sau khi thực hiện giám định nếu không có yêu cầu thẩm định lại thì sẽ tiến hành trả
kết quả giám định cho cơ sở khám chữa bệnh.
1.4. Kết luận
Chương 1 đã giới thiệu về quá trình hình thành bảo hiểm y tế ở việt nam và vận đề
vận hành bảo hiểm y tế từ độ phủ của bảo hiểm y tế, nguyên lý chia sẻ, quyền lợi
của bệnh nhân, hiệu quả của bảo hiểm y tế. Đồng thời cũng giới thiệu tổng quan về
quy trình nghiệp vụ giám định bảo hiểm y tế tại cơ quan bảo hiểm xã hội.

19. 17
CHƯƠNG 2: KIẾN TRÚC HƯỚNG DỊCH VỤ (SERVICE -
ORIENTED ARCHITECTURE)
2.1. Dịch vụ
Dịch vụ (service) về mặt định nghĩa, dịch vụ là một hệ thống có khả năng
nhận một hay nhiều yêu cầu xử lý và sau đó đáp ứng lại bằng cách trả về một hay
nhiều kết quả. Quá trình nhận yêu cầu và trả kết quả về được thực hiện thông qua
các phương thức giao tiếp (interfaces) đã được định nghĩa trước đó.
2.2. Các đặc điểm chính của dịch vụ
2.2.1. Có ranh giới rõ ràng
Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao
tiếp. Thành phần giao tiếp này sẽ quy định về những định dạng thông điệp sử dụng
trong quá trình trao đổi. Và đây chính là cách duy nhất để các đối tượng bên ngoài
có thể truy cập thông tin và chức năng của dịch vụ. Ta chỉ cần gửi các thông điệp
theo các định dạng đã được định nghĩa trước mà không cần phải quan tâm đến cách
xử lý của dịch vụ như thế nào. Điều này đạt được do sự tách biệt giữa thành phần
giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ.
2.2.2. Tính tự trị
Các dịch vụ cần phải được triển khai và hoạt động như những thực thể độc lập
mà không lệ thuộc vào một dịch vụ khác. Dịch vụ phải có tính bền vững cao, nghĩa
là nó sẽ không bị sụp đổ khi có sự cố. Để thực hiện điều này, dịch vụ cần duy trì đầy
đủ thông tin cần thiết cho quá trình hoạt động của mình để có thể tiếp tục hoạt động
trong trường hợp một dịch vụ cộng tác bị hỏng và để tránh các cuộc tấn công từ bên
ngoài bằng cách sử dụng các kỹ thuật về an toàn và bảo mật,…
2.2.3. Chia sẻ lược đồ
Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài,
và hỗ trợ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ liệu
chuẩn. Như thế hệ thống của ta sẽ có tính liên kết và khả năng dễ mở rộng.

20. 18
2.2.4. Tính tương thích của dịch vụ dựa trên chính sách
Một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các
chính sách và yêu cầu của dịch vụ đó như mã hóa, bảo mật… Để thực hiện điều này,
mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó.
2.3. Kiến trúc hướng dịch vụ
Kiến trúc hướng dịch vụ (Service – oriented architecture) là một hướng tiếp
cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng
module, trong đó mỗi module đóng vai trò là một dịch vụ và có khả năng truy cập
thông qua môi trường mạng. Hiểu một cách đơn giản thì một hệ thống SOA là một
tập hợp các dịch vụ được chuẩn hóa trên mạng trao đổi với nhau trong ngữ cảnh một
tiến trình nghiệp vụ.
Trong SOA có 3 đối tượng chính.
Hình 2.1. Sơ đồ cộng tác trong SOA.

21. 19
Nhà cung cấp dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ
lưu trữ thông tin dịch vụ. Người sử dụng thông qua dịch vụ lưu trữ thông tin dịch vụ
để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp
với phía nhà cung cấp.
SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay
như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô
hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là nền tảng cho việc tích
hợp, tại sử dụng lại tài nguyên hiện có.
2.4. Các tính chất của một hệ thống SOA
2.4.1. Kết nối lỏng lẻo
Vấn đề kết nối thể hiện một số ràng buộc giữa các module với nhau. Hầu như
mọi kiến trúc phần mềm đều hướng đến tính kết nối lỏng lẻo giữa các module. Mức
độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống
của chính nó. Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần
chỉnh sửa ở phía dịch vụ mỗi khi có sự thay đổi nào đó xảy ra. Mức độ kết dính tăng
dần khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung
cấp dịch vụ để sử dụng dịch vụ được cung cấp.
2.4.2. Sử dụng lại dịch vụ
Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở nơi lưu
trữ dịch vụ nào đó nên chúng dễ dàng được tìm thấy và tái sử dụng. Nếu một dịch
vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả. Các dịch
vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích
khác nhau.
2.4.3. Sử dụng dịch vụ bất đồng bộ
Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp
với đầy đủ thông tin ngữ cảnh tới bên nhận. Bên nhận xử lí thông tin và trả kết quả
về một kênh thông điệp, bên gọi không phải chờ đến khi thông điệp được xử lí xong.
Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông
điệp, các yêu cầu dịch vụ có thể đưa vào hàng đợi và xử lí với tốc độ tối ưu. Do bên
gọi không phải chờ cho đến khi yêu cầu được xử lí xong và trả về nên không bị ảnh

22. 20
hưởng bởi việc xử lí trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết
một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ.
2.4.4. Quản lý các chính sách
Khi sử dụng chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ có một luật kết hợp
riêng gọi là các chính sách. Các chính sách cần được quản lý các áp dụng cho mỗi
dịch vụ cả khi thiết kế lẫn trong thời gian thực thi.
Việc này tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng. Bởi vì các chính
sách được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi
phần mềm. Nếu không sử dụng các chính sách, các nhân viên phát triển phần mềm,
nhóm điều hành và nhóm hỗ trợ phải làm việc với nhau trong suốt thời gian phát
triển để cài đặt và kiểm tra những chính sách. Ngược lại nếu sử dụng chính sách,
những nhân viên phát triển phần mềm giờ chỉ cần tập trung vào quy trình nghiệp vụ
trong khi nhóm điều hành và hỗ trợ tập trung vào các luật kết hợp.
2.4.5. Khả năng cộng tác
Kiếm trúc hướng dịch vụ hướng nhấn mạnh đến khả năng cộng tác, khả năng
mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác
nhau. Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng
kết nối.
2.4.6. Tự dò tìm và ràng buộc động
SOA hỗ trợ khái niệm truy tìm dịch vụ. Một người sử dụng cần đến một dịch
vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần. Người sử dụng
chỉ cần hỏi một dịch vụ lưu trữ về dịch vụ nào thỏa mãn yêu cầu tìm kiếm.
2.4.7. Khả năng tự phục hồi
Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng
phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng. Một hệ
thống tự phục hồi là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không
cần sự can thiệp của con người.
2.5. Kiến trúc phân tầng chi tiết SOA
Ở tầng thấp nhất, tầng kết nối (connectivity), những dịch vụ được mô hình
hóa dựa trên những ứng dụng enterprise bên dưới. Tầng này chứa các dịch vụ như

23. 21
lấy thông tin cũng như cập nhật dữ liệu. Chúng tương tác trực tiếp với các hệ thống
phi dịch vụ bên dưới. Các dịch vụ này là đặc trưng cho mỗi ứng dụng enterprise.
Phía bên trên tầng kết nối là một dịch vụ orchestration được thêm vào để tạo
ra các dịch vụ thật sự xử lý những chức năng nghiệp vụ độc lập dựa trên những ứng
dụng enterprise bên dưới. Những dịch vụ này còn gọi là những dịch vụ tổng hợp.
Trên cùng của tầng service orchestration là các ứng dụng tổng hợp sử dụng
các service và cung cấp giao diện cụ thể cho người dùng.
Hình 2.2. Kiến trúc phân tầng của hệ thống SOA.
2.5.1. Tầng kết nối
Mục đích của tầng kết nối là kết nối đến các ứng dụng enterprise hoặc tài
nguyên bên dưới và cung cấp chúng thành những dịch vụ. Tầng này là tầng chuyên
giao tiếp với các nhà cung cấp, hoạt động như một bộ chuyển đổi giữa các ứng dụng
phi dịch vụ và mạng các dịch vụ khác.

24. 22
2.5.2. Tầng orchestration
Tầng orchestration chứa các thành phần vừa đóng vai trò là những dịch vụ
vừa là những dịch vụ cung cấp. Những dịch vụ này sử dụng những dịch vụ của tầng
kết nối và các dịch vụ orchestration khác để kết hợp những chức năng cấp thấp hơn
thành những dịch vụ hoạt động ở cấp cao hơn, có hành vi gần với những chức năng
nghiệp vụ thực hơn.
Simple composite service: là những dịch vụ đơn thuần kết hợp những lời triệu gọi
đến các dịch vụ bên dưới, hoạt động như mẫu mặt tiền. Chúng giúp đơn giản hoá
quá trình tương tác với các dịch vụ cấp thấp và che dấu tính phức tạp tới người sử
dụng các dịch vụ ở tầng cao.
Process service: là những dịch vụ định ra một tiến trình kết nối những dịch vụ cấp
thấp hơn. Điều này rất hữu dụng khi thiết kế các dịch vụ kết nối đến nhiều hệ thống
enterprise bên dưới sau đó thực thi như một tiến trình.
Data service: là những dịch vụ cung cấp dữ liệu thu thập từ nhiều nguồn dữ liệu tách
biệt khác nhau. Trong nhiều trường hợp dữ liệu cùng tồn tại trên ứng dụng và cơ sở
dữ liệu khác nhau.
2.5.3. Tầng ứng dụng tổng hợp
Dữ liệu truyền qua lại giữa những dịch vụ cuối cùng cũng định hướng đến
người sử dụng theo nhiều giao diện khác nhau. Tầng này được xem là tầng tích hợp
cuối cùng của quá trình tích hợp.
2.6. Các bước triển khai một ứng dụng theo mô hình SOA
Hai phương pháp cơ bản để xác định các dịch vụ là: phương pháp top-down
(xuất phát từ yêu cầu nghiệp vụ) và phương pháp bottom-up (xuất phát từ thực trạng
của hệ thống hiện có).
Phương pháp top-down: là phương pháp mà điểm xuất phát sẽ là các yêu cầu nghiệp
vụ để xác định các yêu cầu chức năng, các tiến trình và tiến trình con, các trường
hợp sử dụng để tiến hành xác định các thành phần hệ thống, các dịch vụ …
Phương pháp bottom-up: là phương pháp sẽ dựa trên việc phân tích tình trạng, các
tài nguyên của hệ thống hiện có và sẽ tái sử dụng lại những thành phần này trong
việc xây dựng các dịch vụ mới.

25. 23
Trong phương pháp top-down các bước chính để xây dựng hệ thống dựa trên SOA
đó là:
 Phân rã domain: Trong quy trình phát triển ứng dụng theo mô hình SOA.
Bước này dùng để phân rã toàn bộ quy trình nghiệp vụ thành các quy trình
nghiệp vụ con, tiến trình con. Sau khi phân rã domain thành một dãy các vùng
chức năng liên quan, ta tiếp tục phân tích từng vùng chức năng để xác định
các sơ đồ usecase.
 Xây dựng mô hình Goal-service: Mục đích của xây dựng goal-service này là
kiếm tra các mục tiêu trong các mục tiêu trên có thật sự là tốt hay không? Ta
sẽ xuất phát từ mục tiêu chính để xác định các công việc cần làm để đạt được
mục tiêu chính đó là gì (sub-goal). Quá trình phân rã như thế (goal thành các
sub-goal) sẽ được thực hiện cho tới khi nào ta thấy rằng mục tiêu này có thể
được thực hiện bởi một dịch vụ nào đó.
 Phân tích hệ thống con: Trong giai đoạn này các use case nghiệp vụ sẽ để
dùng thiết kế các use case hệ thống. Hệ thống con bao gồm các thành phần
nghiệp vụ.
 Đưa ra các dịch vụ: Các dịch vụ được xác định qua hai giai đoạn là phân rã
domain và xây dựng mô hình goal-service. Trong giai đoạn này chúng ta sẽ
thực hiện đưa các dịch vụ này vào các thành phần. Bước này sẽ cung cấp phần
thực thi và quản lý cho mỗi dịch vụ. Phân bố dịch vụ sẽ thể hiện tính năng
truy vết giữa các dịch vụ và các thành phần chịu trách nhiệm thực thi và quản
lý chúng.
 Đặc tả thành phần: Bước này là đặc tả lại các thành phần sau khi đã thực hiện
các bước trên.
 Cấu trúc thành phần và dịch vụ: Trong giai đoạn này ta sẽ thực hiện đưa các
dịch vụ và các thành phần vào các tầng của SOA. Đây là bước quan trọng vì
sẽ ảnh hưởng đến kiến trúc hệ thống, ảnh hưởng đến công tác xây dựng và
triển khai hệ thống.
 Lựa chọn công nghệ thực hiện: Đây là bước quan trọng để quyết định giải
pháp kỹ thuật ảnh hưởng đến tiến độ và chi phí của dự án như quyết định sử
dụng lại hệ thống cũ với các chức năng đã được thiết kế theo hướng dịch vụ
hay là xây dựng một hệ thống hoàn toàn mới…

26. 24
Để biết chi tiết về các bước xây dựng hệ thống SOA dựa trên phương pháp top-down
thì sẽ ứng dụng trong bài toán giám định tự động trong hệ thống giám định bảo hiểm
xã hội.
2.7. Kết luận
Chương 2 giới thiệu khái niệm về dịch vụ, các đặc điểm chính của dịch vụ. Từ đó
giới thiệu về khái niệm kiến trúc hướng dịch vụ, các tính chất của một hệ thống kiến
trúc hướng dịch vụ. Chương này cũng đưa ra các bước triển khai một ứng dụng theo
kiến trúc hướng dịch vụ, cụ thể là phương pháp top-down.

27. 25
CHƯƠNG 3: PHÂN TÍCH VÀ XÂY DỰNG CHỨC NĂNG
GIÁM ĐỊNH TỰ ĐỘNG
3.1. Giới thiệu hệ thống Giám định bảo hiểm và bài toán giám định tự động
3.1.1. Giới thiệu hệ thống giám định
Hệ thống giám định được xây dựng để phục vụ bài toán thanh quyết toán bảo
hiểm y tế chuyển từ hồ sơ giấy qua thanh toán điện tử.
Hình 3.1. Hệ thống giám định bảo hiểm xã hội VN.
Với những yêu cầu đặt ra phần mềm giám định BHYT phải đáp ứng các yêu cầu:
- Quản lý các danh mục, thông tin
- Tiếp nhận hồ sơ yêu cầu thanh toán

28. 26
- Giám định tự động
- Tạo quy tắc giám định
- Thống kê, phân tích dữ liệu
- Giám định theo tỷ lệ
Biểu đồ ca-sử dụng của hệ thống giám định:
Hình 3.2. Biểu đồ usecase các chức năng chính của hệ thống giám định.
Quản lý các danh mục, thông tin: Quản lý, cập nhật, bổ sung, sửa đổi các danh mục
theo yêu cầu tại Công văn số 1608/BHXH-CSYT ngày 05/5/2015 do Bộ y tế ban
hành và các danh mục của cơ sở khám, chữa bệnh BHYT; quy trình đề xuất, cấp
mới, khóa mã cơ sở khám chữa bệnh.
Tiếp nhận hồ sơ yêu cầu thanh toán: Tiếp nhận dữ liệu từ các phần mềm quản lý
KCB tử cơ sở KCB đã được chuẩn hóa thông tin, định dạng theo Công văn số
2348/BYT –BH ngày 10/04/2015 của Bộ y tế. Tiếp nhận dữ liệu tổng hợp dữ liệu
79a-HD, 80a-HD định dạng theo Công văn 3360/BHXH-CSYT, dữ liệu tương ứng
mẫu 19, 20, 21/BHYT theo Quyết định 1399/QĐ-BHXH. Tiếp nhận thông tin đề
nghị thanh toán trực tiếp từ phần mềm lõi của Ngành BHXH hoặc nhập trực tiếp yêu

29. 27
cầu thanh toán, lập phiếu yêu cầu giám định điện tử kèm theo các tài liệu (file ảnh);
chuyển hồ sơ đề nghị giám định trong hệ thống; trao đổi kết quả giám định và thanh
toán với phần mềm lõi của Ngành BHXH. Giám định và lập phiếu trả lời kết quả
giám định tự động trong hệ thống. Quản lý, tìm kiếm, tra cứu, thống kê hồ sơ thanh
toán trực tiếp.
Giám định tự động: Giám định danh mục, giá thuốc, hóa chất, vật tư y tế, dịch vụ kỹ
thuật. Giám định tự động dữ liệu đề nghị thanh toán từ cơ sở khám chữa bệnh.
Tạo quy tắc giám định: Mục đích để cho người dùng tự định nghĩa các quy tắc giám
định. Phần mềm tự động quét và đánh dấu các bản ghi vi phạm quy tắc theo mức độ
vi phạm, có các chức năng thống kê riêng theo từng quy tắc hoặc nhóm quy tắc do
người dùng lựa chọn.
Thống kê, phân tích dữ liệu: Thống kê kết quả giám định, Thống kê chi phí, Phân
tích chi phí.
Giám định theo tỷ lệ: Nguyên tắc chọn mẫu, phương pháp chọn mẫu
3.1.2. Bài toán giám định tự động
Với lượng hồ sơ khám chữa bệnh ngày càng tăng, cũng như mỗi cơ sở khám chữa
bệnh có những loại thuốc khác nhau, giá thành, thành phẩm khác nhau. Việc giám
định rất khó khăn. Vì vậy cần xây dựng một chức năng có khả năng chạy độc lập với
hệ thống giám định, có khả năng tự trị, hồi phục khi xảy ra lỗi… để thực hiện nghiệp
vụ chạy qua các quy tắc giám định, hỗ trợ các giám định viên phát hiện các sai phạm
một cách hiệu quả trong quá trình giám định.
Chức năng giám định tự động cần dễ triển khai, dễ sử dụng, dễ dàng bảo trì sửa chữa
khi có sự cố. Cũng như có khả năng chịu lỗi cao, trong trường hợp các thành phần
hệ thống gặp sự cố, không hoạt động một thời gian khi các thành phần hoạt động trở
lại thì cần chức năng vẫn hoạt động trở lại bình thường. Riêng với chức năng giám
định hồ sơ thì trung bình hiện tại có khoảng 15 triệu hồ sơ được gửi trong một tháng.
Nghĩa là trung bình một ngày có khoảng 500 nghìn hồ sơ khám chữa bệnh. Một phút
khoảng 350 hồ sơ. Nhưng trong những khoảng thời gian cao điểm nhất định thì lượng
hồ sơ có thể gửi cao hơn rất nhiều. Đây sẽ là bài toán phức tạp trong độ trễ của việc
giám định sau khi gửi hồ sơ giám định.

30. 28
Từ những yêu cầu về tính độc lập, tự trị, khả năng phục hồi khi xảy ra lỗi. Cùng với
đó hiện tại chức năng chưa cần sử dụng lại nhưng trong tương lai sẽ cần sử dụng lại
dịch vụ để thực hiện giám định tự động công khai. Vì vậy từ những tính chất, yêu
cầu của chức năng giám định tự động mà ta sẽ lựa chọn mô hình kiến trúc SOA với
phương pháp top-down (xuất phát từ những yêu cầu nghiệp vụ để xác định các dịch
vụ) để xây dựng giám định tự động.
3.2. Phân tích và xây dựng chức năng giám định tự động
Cơ sở dữ liệu: Với phạm vi luận văn phân tích về chức năng giám định tự động,
luận văn sẽ chỉ đề cập đến những bảng mà chức năng giám định tự động sử dụng
đến:
Hình 3.3. Mô hình cơ sở dữ liệu.

31. 29
Các danh mục dùng chung được BYT ban hành sẽ được thể hiện ở các bảng danh
mục dùng chung như:
- DM_THUOC: Danh mục thuốc được BYT ban hành, có số đăng ký công bố
- DM_THUOC_KK: Danh mục thuốc sau khi nhà sản xuất đăng ký số đăng ký
với cơ quan quản lý dược, kèm theo giá bán.
- DM_HOATCHAT: Theo thông tư 40 của BYT ban hành về hoạt chất của các
thuốc tân dược
- DM_THUOCYHCT: Theo thông tư 05 của BYT ban hành về hoạt chất của
các thuốc y học cổ truyền
- DM_DICHVU_TD: Danh mục dịch vụ kỹ thuật dùng chung được BYT ban
hành
- DM_VATTU: Danh mục vật tư dùng chung được BYT ban hành
- DM_MUCHUONGBHYT: Danh mục mức hưởng của từng loại đối tượng
khám chữa bệnh
- DM_GIAXANG: Danh mục giá xăng do BHXH Việt Nam quản lý
- DM_MAU: Danh mục máu do BHXH Việt Nam quản lý
- DM_COSOKCB: Danh mục cơ sở khám chữa bệnh do BHXH Việt Nam cấp
phát và quản lý
- DM_TYLETRAITUYEN: Danh mục tỷ lệ trái tuyến, với những trường hợp đi
khám trái tuyến, tỷ lệ hưởng sẽ được thể hiện trong bảng
Các danh mục thầu của tỉnh được thể hiện ở các bảng như:
- DM_THUOC_THAU: Danh mục thuốc trúng thầu của tỉnh
- DM_VATTU_THAU: Danh mục vật tư trúng thầu của tỉnh
- DM_GIADICHVU_TINH: Danh mục dịch vụ kỹ thuật trúng thầu của tỉnh
Các danh mục của bệnh viện sử dụng được thể hiện ở các bảng sau:
- DM_THUOC_BV: Danh mục thuốc mà bệnh viện sử dụng
- DM_DICHVU_BV: Danh mục dịch vụ kỹ thuật mà bệnh viện sử dụng
- DM_VATTU_BV: Danh mục vật tư mà bệnh viện sử dụng
Hồ sơ khám chữa bệnh sẽ được thể hiện ở các bảng:

32. 30
- XML1_9324: Thông tin cá nhân, bệnh án, tổng chi phí mà bệnh nhân sử dụng
trong quá trình khám chữa bệnh
- XML2_9324: Thông chi tiết các thuốc mà bệnh nhân sử dụng trong quá trình
khám chữa bệnh
- XML3_9324: Thông tin chi tiết các dịch vụ kỹ thuật, vật tư mà bệnh nhân sử
dụng trong quá trình khám chữa bệnh
- XML4_9324: Thông tin chỉ tiêu chỉ số kết quả cận lâm sàng
- XML5_9324: Thông tin chỉ tiêu theo dõi diễn biến lâm sang
Bảng XML1_9324 sẽ có quan hệ một - nhiều với các bảng XML2_9324,
XML3_9324, XML4_9324, XML5_9324.
Một số bảng khác:
- DM_FUNCTION: danh sách các quy tắc hồ sơ, quy định bật hay tắc các quy
tắc
- DM_FUNCTION_DM: danh sách các quy tắc danh mục, quy định bật hay tắt
các quy tắc
Thông tin chi tiết về các trường của các bảng sẽ được trình bày trong phần phụ lục.
Từ yêu cầu cần giám định hồ sơ khám chữa bệnh, cùng giám định danh mục thì phần
giám định tự động sẽ chia thành hai mục là giám định hồ sơ và giám định danh mục.
3.2.1. Giám định hồ sơ
3.2.1.1. Phân rã domain
Với nghiệp vụ cần thực hiện lấy những hồ sơ mới được gửi lên rồi thực hiện giám
định. Giám định xong cập nhật kết quả giám định vào cơ sở dữ liệu và tính toán các
trường để đẩy dữ liệu lên Solr. Từ các nghiệp vụ như vậy, ta có phân rã domain
thành một dãy các chức năng liên quan.

33. 31
Hình 3.4. Phân rã domain thành một dãy các vùng chức năng liên quan.
Sau khi phân rã domain thành một dãy các vùng chức năng liên quan, ta tiếp tục
phân tích từng vùng chức năng để xác định các sơ đồ sử dụng.
Mô hình usecase:
 Lấy hồ sơ khám chữa bệnh mới
o Mô tả ngắn gọn: use case mô tả cách lấy danh sách hồ sơ khám chữa
bệnh mới được gửi lên, sau đó thực hiện gửi các thông điệp chứa từng
hồ sơ trong danh sách lấy được cho use case xử lý giám định.
o Những luồng sự kiện:
 Luồng cơ bản: tiến hành kiểm tra có hồ sơ mới gửi lên hay
không, nếu có thì tiến hành lấy danh sách hồ sơ mới gửi để thực
hiện gửi các thông điệp chứa từng hồ sơ trong danh sách lấy được
cho use case xử lý giám định.
 Luồng thay thế: trong trường hợp gửi thông điệp lỗi thì tiến hành
cập nhật lại hồ sơ về trạng thái mới gửi và ghi log vào thư mục
thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp.

34. 32
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các hồ sơ mới tiếp theo.
o Điểm mở rộng: không
 Xử lý giám định
o Mô tả ngắn gọn: use case mô tả khi nhận được thông điệp từ use case
lấy hồ sơ khám chữa bệnh mới, sau đó thực hiện kết nối cơ sở dữ liệu,
lấy những quy tắc hồ sơ và thực hiện chạy giám định. Sau khi chạy
giám định cần gửi thông điệp chứa kết quả giám định cho use case cập
nhật kết quả giám định.
o Những luồng sự kiện:
 Luồng cơ bản: khi nhận được thông điệp từ use case lấy hồ sơ
khám chữa bệnh mới, sau đó thực hiện kết nối cơ sở dữ liệu, lấy
những quy tắc hồ sơ và thực hiện chạy giám định. Sau khi chạy
giám định cần gửi thông điệp chứa kết quả giám định cho use
case cập nhật kết quả giám định.
 Luồng thay thế: trong trường hợp gửi thông điệp lỗi thì tiến hành
cập nhật lại hồ sơ về trạng thái mới gửi và ghi log vào thư mục
thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp, phải nhận được thông điệp
từ use case lấy hồ sơ khám chữa bệnh mới.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các thông điệp mới tiếp theo.
o Điểm mở rộng: không
 Cập nhật kết quả giám định
o Mô tả ngắn gọn: use case mô tả khi nhận được thông điệp từ use case
xử lý giám định, sau đó thực hiện kết nối cơ sở dữ liệu, cập nhật kết quả
giám định vào cơ sở dữ liệu.
o Những luồng sự kiện:
 Luồng cơ bản: khi nhận được thông điệp từ use case xử lý giám
định, sau đó thực hiện kết nối cơ sở dữ liệu, cập nhật kết quả
giám định vào cơ sở dữ liệu.

35. 33
 Luồng thay thế: trong trường hợp cập nhật lỗi thì tiến hành cập
nhật lại hồ sơ về trạng thái mới gửi và ghi log vào thư mục thực
thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các hồ sơ mới tiếp theo.
o Điểm mở rộng: không
 Tính toán và đẩy dữ liệu lên Solr
o Mô tả ngắn gọn: sau khi cập nhật kết quả giám định vào cơ sở dữ liệu,
tiến hành tính toán các trường tiền quyết toán, tiền để nghị của báo cáo
và đẩy dữ liệu lên Solr.
o Những luồng sự kiện:
 Luồng cơ bản: sau khi cập nhật kết quả giám định vào cơ sở dữ
liệu, tiến hành tính toán các trường tiền quyết toán, tiền để nghị
của báo cáo và đẩy dữ liệu lên Solr.
 Luồng thay thế: trong trường hợp gửi dữ liệu lên Solr lỗi thì tiến
hành cập nhật lại hồ sơ về trạng thái mới gửi và ghi log vào thư
mục thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu, hệ thống chuyển giao thông điệp, Solr và phải cập nhật kết quả
giám định thành công.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các thông điệp tiếp theo.
o Điểm mở rộng: không
Với những yêu cầu chức năng trên sẽ cần những yêu cầu phi chức năng đi kèm như
sau:
 Khả năng dễ sử dụng
 Khả năng dễ triển khai
 Khả năng dễ bảo trì

36. 34
 Khả năng chịu lỗi cao
 Tính sẵn sàng của hệ thống: hệ thống làm việc 24/24h trừ những khoảng thời
gian bảo trì, nâng cấp.
 Hiệu năng: với trung bình một tháng có 15 triệu hồ sơ được gửi lên, khoảng
350 hồ sơ trung bình một phút, nhưng với những thời điểm cao điểm lượng
hồ sơ tăng gấp nhiều lần. Hệ thống phải đảm bảo xử lý độ trễ các hồ sơ không
quá 1h.
3.2.1.2. Xây dựng mô hình Goal-service
Trong giai đoạn phân rã domain ta đã xác định được các usecase nghiệp vụ, và
đây sẽ là cơ sở chính để ta xác định các dịch vụ.
Có nhiều cách thể hiện mô hình goal-service, ở đây ta sẽ sử dụng một cách đơn
giản đó là dùng danh sách phân cấp để biểu diễn các goal, sub-goal, dịch vụ (goal:
thể hiện bằng font chữ bình thường, dịch vụ: được thể hiện bằng font chữ in nghiêng,
giá trị gia tăng: những dịch vụ cần thiết, nhưng chưa được xác định trong giai đoạn
phân rã domain được thể hiện bằng font chữ in đậm).
 Giám định hồ sơ
o Lấy hồ sơ KCB mới
 Kết nối cơ sở dữ liệu và lấy các bản ghi theo trạng thái mới
 GetXml19324()
 Gửi thông điệp tới các dịch vụ khác
 SendMessage(Message)
 Xử lý và ghi log khi có sự cố
 Xử lý(exeption)
 Ghi log(exeption)
o Xử lý giám định
 Nhận thông điệp từ dịch vụ khác
 GetMessage()
 Giải mã thông điệp
 Giả mã(Message)
 Kết nối cơ sở dữ liệu
 ConnectDB()

37. 35
 Thực hiện giám định
 Lấy các quy tắc giám định đang bật
o GetDmFunction(xml.NgayThanhToan)
 Thực hiện chạy các quy tắc giám định
o Run(xml19324)
 Gửi thông điệp cho dịch vụ khác
 SendMessage(Message)
 Xử lý và ghi log khi có sự cố
 Xử lý()
 Ghi log()
o Cập nhật kết quả giám định
 Nhận thông điệp từ dịch vụ khác
 GetMesssage()
 Giải mã thông điệp
 Giải mã(Message)
 Kết nối cơ sở dữ liệu và cập nhật kết quả
 ConnectDB()
 UpdateSauGD(Xml19324)
 Xử lý và ghi log khi có sự cố
 Xử lý(exeption)
 Ghi log(exeption)
o Tính toán và đẩy dữ liệu lên Solr
 Tính toán theo yêu cầu báo cáo
 Tinhtoan(ref xml19324)
 Chuyển đổi dữ liệu về schema của Solr
 Convert(xml19324)
 Đẩy dữ liệu lên Solr
 SendSolr(Xml19324_Report)
 Xử lý và ghi log khi có sự cố
 Xử lý(exeption)
 Ghi log(exeption)

38. 36
3.2.1.3. Phân tích hệ thống con
Các usecase nghiệp vụ sẽ là cơ sở thiết kế các usecase hệ thống. Trong chức năng
giám định hồ sơ thì sẽ gồm các hệ thống con: Lấy hồ sơ KCB mới, Xử lý giám định,
Cập nhật kết quả giám định, Tính toán và đẩy dữ liệu lên Solr.
3.2.1.4. Đưa ra các dịch vụ
Như vậy với các hệ thống con trong chức năng giám định hồ sơ: Lấy hồ sơ KCB
mới, xử lý giám định, cập nhật kết quả giám định, tính toán và đẩy dữ liệu lên Solr.
Ta sẽ đặt tên cho các hệ thống con để có thể dễ dàng sử dụng, và đưa các dịch vụ
vào các thành phần.
GetDataKB: Lấy hồ sơ KCB mới sẽ gồm các dịch vụ
 GetXml19324(): Lấy những hồ sơ KCB theo trạng thái mới được gửi lên
 SendMessage(Message): Gửi thông điệp cho thành phần khác với thông điệp
dạng đối tượng Message
 Xử lý(exeption): Xử lý khi xảy ra sự cố
 Ghilog(exeption): Ghi log khi xảy ra sự cố
Hình 3.5. Biểu đồ tuần tự service GetDataKB.

39. 37
Bắt đầu service GetDataKB sẽ thực hiện gọi đến phương thức GetXml19324() để
lấy những bản ghi Xml19324 có status = 0, khi có danh sách các bản ghi Xml19324
trả về thì tiến hành gọi đến phương SendMessage(Message) với nội dung thông điệp
là chuỗi json của từng bản ghi Xml1924 lấy được. Nếu gửi thông điệp thành công
thì tiến hành lại nghiệp vụ từ đầu, còn nếu trong trường hợp gửi thông điệp nào bị
lỗi thì tiến hành gọi đến phương thức UpdateXml19324(Xml19324) để cập nhật bản
ghi về trạng thái mới gửi status = 0. Tiến hành ghi log vào thư mục triển khai để
quản trị viên nắm được và khắc phục sự cố.
ProcessDataKB: Xử lý giám định sẽ gồm các dịch vụ
 GetMesssage(): Nhận thông điệp từ dịch vụ khác
 Giải mã(Message): Giải mã thông điệp
 ConnectDB(): Kết nối cơ sở dữ liệu
 GetDmFunction(xml.NgayThanhToan): Lấy những quy tắc đang bật theo
ngày thanh toán của hồ sơ
 Run(Xml19324): Thực hiện chạy các quy tắc giám định hồ sơ
 SendMessage(Messgae): Gửi thông điệp tới dịch vụ khác
 Xử lý(exeption): Xử lý khi xảy ra sự cố
 Ghilog(exeption): Ghi log khi xảy ra sự cố

40. 38
Hình 3.6. Biểu đồ tuần tự service ProcessDataKB.
Bắt đầu service ProcessDataKB sẽ thực hiện lấy thông điệp trên queue với việc gọi
phương thức GetMessage(), phương thức sẽ trả về một thông điệp tồn tại trên queue.
Thông điệp được lấy về sẽ có định dạng là một chuỗi json, vì vậy cần chuyển hóa về
dạng đối tượng với phương thức Giaima(Message). Thực hiện kết nối đến cơ sở dữ
liệu để lấy danh sách các quy tắc theo ngày thanh toán của GetDmFunction(NgayTT)
với các quy tắc hồ sơ lấy được, tiến hành thực hiện nghiệp vụ giám định
Run(Xml19324). Sauk hi giám định thực hiện gửi thông điệp lên queue. Trong
trường hợp gửi thông điệp thất bại, tiến hành cập nhật hồ sơ về trạng thái mới và ghi
log vào thư mục triển khai.
SendDataKB: Cập nhật kết quả giám định và tính toán rồi đẩy dữ liệu lên Solr sẽ
gồm các dịch vụ
 GetMesssage(): Nhận thông điệp từ dịch vụ khác
 Giải mã(Message): Giải mã thông điệp
 ConnectDB(): Kết nối cơ sở dữ liệu

41. 39
 UpdateSGD(Xml19324): Cập nhật kết quả sau giám định
 Tinhtoan(ref Xml19324): Tính toán theo yêu cầu báo cáo
 Convert(Xml19324): Chuyển đổi về schema của Solr
 SendSolr(Xml19324_report): Đẩy dữ liệu lên Solr
 Xử lý(exeption): Xử lý khi xảy ra sự cố
 Ghilog(exeption): Ghi log khi xảy ra sự cố
Hình 3.7. Biểu đồ tuần tự service SendDataKB.
Bắt đầu service SendDataKB sẽ thực hiện lấy thông điệp trên queue với việc sử dụng
phương thức GetMessage(). Phương thức sẽ trả về thông điệp tồn tại trên queue với
định dạng là chuỗi json. Vì vậy cần sử dụng phương thức Giaima(Message) để thực
hiện giải mã thông điệp thành dạng đối tượng. Tiếp theo thực hiện kết nối đến cơ sở
dữ liệu và cập nhật kết quả giám định vào cơ sở dữ liệu UpdateSGD(Xml19324).
Nếu cập nhật dữ liệu thành công sẽ thực hiện tính toán theo nghiệp vụ báo cáo các
trường tiền đề nghị, tiền quyết toán… với phương thức Tinhtoan(Xml19324). Thực
hiện chuyển đổi từ đối tượng Xml19324 sang đối tượng schema của báo cáo
Xml19324_report và thực hiện đẩy dữ liệu lên Solr với phương thức SendSolr().

42. 40
Trong quá trình cập nhật hay đẩy dữ liệu lên Solr có sự cố xảy ra thì tiến hành cập
nhật bản ghi Xml19324 về trạng thái mới và ghi log vào thư mục triển khai.
3.2.1.5. Đặc tả thành phần
Với các dịch vụ GetDataKB, ProcessDataKB, SendDataKB sẽ gửi thông điệp với
nhau qua một hệ thống MessageBroker, với nội dung của thông điệp sẽ là đối tượng
Message sẽ có các trường id, nội dung thông điệp, loại thông điệp. Nội dung của
thông điệp sẽ là chuỗi base64 của đối tượng cần gửi với hàm mã hóa của thư viện
Newtonsoft.Jon.dll. Với dịch vụ gửi dữ liệu lên Solr, Schema của Solr sẽ gồm các
trường nghiệp vụ.
3.2.1.6. Cấu trúc thành phần và dịch vụ
Tiến hành đưa các thành phần và dịch vụ vào các tầng của SOA
3.2.1.7. Lựa chọn công nghệ thực hiện
Với việc xây dựng các bộ dịch vụ: GetDataKB, ProcessDataKB, SendDataKB sẽ
triển khai trên cùng một dải mạng WAN, chạy tự động, độc lập trên windown server,
ta sẽ xây dựng các dịch vụ trên dưới dạng Winservice hoặc Application. Nhưng để
triển khai cũng như quản lý một cách dễ dàng, tăng giảm số luồng, số dịch vụ khi
triển khai thì ta sẽ chọn Application.
Cơ sở dữ liệu: Oracle 11g 64bit
Ngôn ngữ lập trình: C# trên môi trường .Net 4.0, công cụ lập trình Visual Studio 15.
Các thư viện client sử dụng sẽ được trình bày chi tiết hơn ở chương 4.
Vấn đề để các dịch vụ trao đổi thông điệp với nhau, ta cần sử dụng một hệ thống
chuyển giao thông điệp (Message Broker). Một trong những hệ thống message
broker phổ biến cũng như dễ sử dụng hiện nay là RabbitMQ.
RabbitMQ là một hệ thống chuyển giao các bản tin, nó tiếp nhận các bản tin và
chuyển tiếp đến các nơi nhận. RabbitMQ được viết bằng ngôn ngữ Erlang, hỗ trợ
hầu hết các ngôn ngữ hiện nay, giúp mở rộng các hệ thống hay kết nối các hệ thống
với nhau.

43. 41
Hình 3.8. Sơ sồ hoạt động tổng quan của RabbitMQ.
Producer: đóng vai trò là người gửi các bản tin
Consumer: đóng vai trò là người nhận các bản tin
Queue: đóng vai trò là nơi lưu trữ các bản tin được gửi lên
Exchange: đóng vai trò phân phối các bản tin đến queue

44. 42
Hình 3.9. Sơ đồ hoạt động của RabbitMQ về việc phân phối các bản tin.
Khi có bản tin được gửi lên, exchange sẽ thực hiện phân phối các bản ghi tùy thuộc
vào loại phân phối được quy định. Có 3 loại phân phối được quy định là: Direct,
Topic, Fanout.
Direct: sẽ đẩy vào queue nào phụ thuộc vào Binding key, với từng key thì sẽ đẩy vào
queue tương ứng.
Topic: sẽ đẩy vào queue nào phụ thuộc vào Routing partern, với từng partern khác
nhau sẽ đẩy vào queue khác nhau.
Fanout: sẽ đẩy vào tất cả các queue đã cấu hình trước.

45. 43
Hình 3.10. Màn hình tổng quan quản lý Rabbit MQ.
3.2.1.8. Các quy tắc hồ sơ
 Quy tắc thẻ:
- F1_1: Thẻ hết giá trị sử dụng
Kiểm tra thời gian khám chữa bệnh sau khi thẻ hết hạn, xuất toán toàn bộ chi phí
được sử dụng: So sánh ngày vào và giá trị đến của thẻ của hồ sơ, nếu ngày vào hồ
sơ mà lớn hơn giá trị đến của thẻ (xml1.NGAY_VAO > xml1.GT_THE_DEN) thì
vi phạm quy tắc. Tiến hành xuất toán hay cảnh báo tùy thuộc vào điều chỉnh của bảo
hiểm xã hội việt nam.
- F1_2: Khám chữa bệnh khi chưa đến hạn thẻ
Bệnh nhân vào viện trước khi thẻ có giá trị: So sánh giá trị từ của thẻ và ngày ra
của hồ sơ, nếu giá trị từ của thẻ mà lớn hơn ngày ra của hồ sơ (xml1.GT_THE_TU
> xml1.NGAY_RA) thì vi phạm quy tắc. Tiến hành xuất toán hay cảnh báo tùy thuộc
vào điều chỉnh của bảo hiểm xã hội việt nam.
- F1_3: Thẻ hết hạn khi chưa ra viện
Thẻ của bệnh nhân hết hạn khi vẫn đang nằm viện, sẽ xuất toán những chi phí
được sử dụng trong thời gian khi thẻ hết hạn. Nếu ngày ra của hồ sơ mà lớn hơn giá
trị đến của thẻ (xml1.NGAY_RA > xml1.GT_THE_DEN), tiến hành kiểm tra các

46. 44
ngày y lệnh của thuốc, dịch vụ, vật tư trong hồ sơ nếu lớn hơn giá trị thẻ đến của thẻ
(xml2.NGAY_YL, xml3.NGAY_YL > xml1.GT_THE_DEN) thì tiến hành cảnh
báo, xuất toán những chi phí đó.
- F1_4: Thẻ có giá trị sau ngày vào viện
Bệnh nhân vào viện trước thời gian thẻ có giá trị (xml1.NGAY_VAO <
xml.GT_THE_TU), chỉ thanh toán những chi phí trong khoảng thời gian thẻ có giá
trị (xml2.NGAY_YL, xml3.NGAY_YL >= xml1.GT_THE_TU), xuất toán những
chi phí được sử dụng trước khi thẻ có giá trị.
- F1_5: Mã thẻ không có dữ liệu thẻ
Thực hiện kết nối đến hệ thống quản lý sổ thẻ của Bảo Hiểm Xã Hội Việt Nam,
sẽ xuất toán những mã thẻ (xml1.MA_THE) không tồn tại (ngoại trừ trường hợp trẻ
em dưới sáu tuổi được cấp thẻ tạm).
- F1_6: Thẻ sai họ tên
Thực hiện kết nối đến hệ thống quản lý sổ thẻ của Bảo Hiểm Xã Hội Việt Nam,
cảnh báo những mã thẻ nào bị sai họ tên (xml1.HO_TEN != ResponeApi.HO_TEN)
- F1_7: Thẻ sai ngày sinh
Thực hiện kết nối đến hệ thống quản lý sổ thẻ của Bảo Hiểm Xã Hội Việt Nam,
cảnh báo những mã thẻ nào bị sai ngày sinh (xml1.NGAY_SINH !=
ResponeApi.NGAY_SINH)
- F1_8: Thẻ sai giới tính
Thực hiện kết nối đến hệ thống quản lý sổ thẻ của Bảo Hiểm Xã Hội Việt Nam,
cảnh báo những mã thẻ nào bị sai giới tính (xml1.GIOI_TINH !=
ResponeApi.GIOI_TINH)
- F1_9: Thẻ sai nới đăng ký khám chữa bệnh ban đầu
Thực hiện kết nối đến hệ thống quản lý sổ thẻ của Bảo Hiểm Xã Hội Việt Nam,
cảnh báo những mã thẻ nào bị sai nới đăng ký khám chữa bệnh ban đầu
(xml1.MA_DKBD != ResponeApi.MA_DKBD)

47. 45
Căn cứ Quyết định 1351 về việc ban hành mã số ghi trên thẻ bảo hiểm y tế, quy định
các mã đối tượng cùng mức hưởng được hưởng của các mã đối tượng và điều 22
Luật sửa đổi, bổ sung một số điều của Luật bảo hiểm y tế vào ngày 13/06/2014 về
mức hưởng bảo hiểm y tế, bộ quy tắc về mức hưởng được tạo ra.
 Quy tắc mức hưởng:
- F2_10: Đúng tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
mới hoặc cũ) sai mức hưởng
Với trường hợp không có mã khu vực (xml1.MA_KHU_VUC == null), khám
chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), đúng tuyến (khám chữa bệnh
cùng tỉnh hoặc khám chữa bệnh ngoại tỉnh nhưng cơ sở khám chữa bệnh là bệnh
viện thì cũng được coi là thông tuyến) và chi phí khám chữa bệnh lớn hơn hoặc bằng
mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS) thì sẽ được
hưởng theo mức hưởng trên thẻ. Nếu mức hưởng gửi lên lớn hơn sẽ vi phạm.
- F2_11: Trái tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp không có mã khu vực (xml1.MA_KHU_VUC == null), khám
chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), trái tuyến mà chi phí lớn
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS), mức hưởng
sẽ được tính theo tỷ lệ của thẻ (DM_MUCHUONGBHYT.TYLE) nhân với tỷ lệ
thanh toán trái tuyến (DM_TYLETRAITUYEN.TYLE). Nếu mức hưởng gửi lên lớn
hơn sẽ vi phạm.
- F2_12: Đúng tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp không có mã khu vực (xml1.MA_KHU_VUC == null), khám
chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), đúng tuyến mà chi phí nhỏ
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI < 15%LCS) thì sẽ được
hưởng một trăm phần trăm.
- F2_13: Trái tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng

48. 46
Với trường hợp không có mã khu vực (xml1.MA_KHU_VUC == null), khám
chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), trái tuyến mà chi phí nhỏ
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI < 15%LCS) thì sẽ được
hưởng theo tỷ lệ trái tuyến (DM_TYLETRAITUYEN.TYLE).
- F2_14: Trái tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sau mức hưởng.
Với trường hợp mã thẻ có khu vực K1, K2, K3 (xml1.MA_KHU_VUC != null),
khám chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), trái tuyến, mà chi phí
nhỏ hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI < 15%LCS) sẽ được
coi như thông tuyến nên được hưởng một trăm phần trăm.
- F2_15: Trái tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (trên thẻ
có mã khu vực K1, K2, K3) sai mức hưởng
Với trường hợp mã thẻ có khu vực K1, K2, K3 (xml1.MA_KHU_VUC != null),
khám chữa bệnh ở tuyến huyện (COSO_KCB == 3), trái tuyến mà chi phí lớn hơn
mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS) sẽ được coi như
thông tuyến và được hưởng theo tỷ lệ của mã đối tượng trên thẻ
(DM_MUCHUONGBHYT.TYLE).
- F2_17: Đề nghị thanh toán chi phí vận chuyển
Với trường hợp khám chữa bệnh ở tuyến huyện (COSO_KCB.TUYEN == 3), đề
nghị thanh toán chi phí vận chuyển (xml3.THANH_TIEN của xml3.MANHOM ==
12), nếu mã đối tượng không được hưởng vận chuyển thì vi phạm
(DM_MUCHUONGBHYT.VANCHUYEN != 1), còn nếu mã đối tượng được
hưởng vận chuyển thì cần kiểm tra đến giá xăng trong danh mục
(DM_GIAXANG.GIA) , nếu giá xăng cơ sở gửi lên lớn hơn giá xăng trong danh
mục thì vi phạm (xml3.DONGIA > DM_GIAXANG.GIA).
- F2_18: Đúng tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc
trung ương (COSOKCB_TUYEN == 1), nội/ ngoại trú, đúng tuyến mà chi phí lớn

49. 47
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS), thông
tuyến sẽ được hưởng theo mức hưởng của mã đối tượng trên thẻ
(DM_MUCHUONGBHYT.TYLE).
- F2_19: Trái tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc
trung ương (COSO_KCB.TUYEN == 1), nội/ngoại trú, trái tuyến mà chi phí lớn
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS) sẽ được
hưởng theo mức hưởng của mã đối tượng trên thẻ
(DM_MUCHUONGBHYT.TYLE) nhân với tỷ lệ thanh toán trái tuyến
(DM_TYLETRAITUYEN.TYLE) tương ứng.
- F2_20: Đúng tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc
trung ương (COSO_KCB.TUYEN == 1), nội/ngoại trú, đúng tuyến mà chi phí khám
chữa bệnh nhỏ hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI <
15%LCS) sẽ được hưởng một trăm phần trăm.
- F2_21: Trái tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc
trung ương (COSO_KCB.TUYEN == 1), nội/ngoại trú, trái tuyến mà chi phí nhỏ
hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >= 15%LCS) sẽ được
hưởng theo tỷ lệ trái tuyến tương ứng (DM_TYLETRAITUYEN.TYLE).
- F2_22: Trái tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (trên mã
thẻ có mã khu vực K1, K2, K3) sai mức hưởng
Với trường hợp thẻ có mã khu vực K1, K2, K3 (xml1.MA_KHU_VUC != null)
đi khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc trung ương
(COSO_KCB.TUYEN == 1), nội/ngoại trú, trái tuyến mà chi phí nhỏ hơn mười lăm

50. 48
phần trăm lương cơ sở (xml1.T_TONGCHI < 15%LCS) sẽ được coi là thông tuyến,
hưởng một trăm phần trăm.
- F2_23: Trái tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (trên thẻ
có mã khu vực K1, K2, K3) sai mức hưởng
Với trường hợp thẻ có mã khu vực K1, K2, K3 (xml1.MA_KHU_VUC != null)
đi khám chữa bệnh ở tuyến tỉnh (COSO_KCB.TUYEN == 2) hoặc trung ương
(COSO_KCB.TUYEN == 1), nội/ngoại trú trái tuyến, chi phí mà lớn hơn mười lăm
phần trăm lương cơ sở (xm1.T_TONGCHI > 15%LCS) sẽ được coi là thông tuyến,
hưởng theo tỷ lệ của mã đối tượng trên thẻ (DM_MUCHUONGBHYT.TYLE).
- F2_25: Đề nghị thanh toán chi phí vận chuyển
Với trường hợp khám chữa bệnh ở truyến tỉnh (COSO_KCB.TUYEN == 2) hoặc
trung ương (COSO_KCB.TUYEN == 1), nội/ngoại trú đề nghị thanh toán chi phí
vận chuyển (xml3.MANHOM == 12), nếu mã đối tượng không được hưởng vận
chuyển sẽ vi phạm(DM_MUCHUONGBHYT.VANCHUYEN != 1), nếu mã đối
tượng trên thẻ được hưởng vận chuyển thì sẽ kiểm tra trong danh mục giá xăng so
với giá của cơ sở đưa lên (DM_GIAXANG.GIA), nếu giá của cơ sở đưa lên mà cao
hơn trong danh mục giá xăng thì sẽ bị vi phạm (xml3.DONGIA >
DM_GIAXANG.GIA).
- F2_26: Đúng tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến xã (COSO_KCB.TUYEN == 4), đúng
tuyến mà chi phí lớn hơn mười lăm phần trăm (xml1.T_TONGCHI >= 15%LCS) sẽ
được một trăm phần trăm.
- F2_27: Trái tuyến, chi phí lớn hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến xã (COSO_KCB.TUYEN == 4), trái
tuyến mà chi phí khám chữa bệnh lớn hơn mười lăm phần trăm lương cơ sở
(xml1.T_TONGCHI > 15%LCS) sẽ được hưởng theo tỷ lệ của mã đối tượng trên
thẻ (DM_MUCHUONGBHYT.TYLE).

51. 49
- F2_28: Đúng tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến xã (COSO_KCB.TUYEN == 4), đúng
tuyến mà chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI <
15%LCS) sẽ được hưởng một trăm phần trăm.
- F2_30: Trái tuyến, chi phí nhỏ hơn mười lăm phần trăm lương cơ sở (mã thẻ
cũ hoặc mới) sai mức hưởng
Với trường hợp khám chữa bệnh ở tuyến xã (COSO_KCB.TUYEN == 4), trái
tuyến mà chi phí nhở hơn mười lăm phần trăm lương cơ sở (xml1.T_TONGCHI >
15%LCS) thì sẽ được coi là thông tuyến, hưởng một trăm phần trăm.
- F2_31: Trái tuyến chi phí nhỏ hơn mười lăm phần trăm (trên thẻ có mã khu
vực K1, K2, K3) sai mức hưởng
Với thẻ có mã khu vực K1, K2, K3 (xml1.MA_KHU_VUC != null) đi khám ở
tuyến xã (COSO_KCB.TUYEN == 4), trái tuyến mà chi phí nhỏ hơn mười lăm phần
trăm lương cơ sở (xml1.T_TONGCHI < 15%LCS) sẽ được hưởng một trăm phần
trăm.
 Quy tắc thuốc:
- F3_31: Thuốc chưa được kê khai
Khi một thuốc muốn được sử dụng thì phải đăng ký với cục quản lý dược, vì vậy
cần kiểm tra thuốc cơ sở sử dụng đã được kê khai hay chưa (xml2.SO_DANG_KY),
tiến hành tìm kiếm trong danh mục kê khai kê khai lại theo số đăng ký
(DM_THUOC_KK), không tìm thấy thì sẽ cảnh báo.
- F3_32: Giá thuốc thanh toán lớn hơn giá thuốc kê khai, kê khai lại
Tìm trong danh mục kê khai, kê khai lại theo số đăng ký (DM_THUOC_KK),
tìm được thuốc đã được kê khai, tiến hành so sánh giá, nếu giá của cơ sở gửi lên mà
lớn hơn giá của thuốc trong danh mục thuốc kê khai kê khai lại thì xuất toán phần
chênh lệch giá (xml2.DONGIA > DM_THUOC_KK.GIA).
- F3_33: Giá thuốc thanh toán lớn hơn giá thuốc được phê duyệt

52. 50
Mỗi cơ sở sẽ có một danh mục thuốc sử dụng riêng, các cơ sở sẽ gửi danh mục
thuốc lên bảo hiểm, các giám định viên sẽ giám định thuốc và phê duyệt cho cơ sở
sử dụng (DM_THUOC_BV). Nhưng khi khai báo hồ sơ nếu cơ sở gửi lên giá cao
hơn giá trong danh mục đã gửi lên bảo hiểm trước đó (xml2.DONGIA >
DM_THUOC_BV.GIA) thì sẽ bị xuất toán phần chênh lệch giá.
- F3_34: Thuốc ngoài danh mục Thông tư 40, Thông tư 05
Kiểm tra thuốc cơ sở gửi lên có trong Thông tư 40, Thông tư 05 hay không
(DM_HOATCHAT, DM_THUOC_YHCT). Nếu không có thì cảnh báo.
- F4_35: Thuốc ngoài danh mục sử dụng tại bệnh viện
Cơ sở sử dụng thuốc ngoài danh mục thuốc của bệnh viện đã gửi lên bảo hiểm để
giám định (DM_THUOC_BV).
- F4_39: Thuốc sai tên so với danh mục sử dụng tại bệnh viện
So sánh thuốc cơ sở sử dụng với danh mục thuốc sử dụng tại bệnh viện, theo mã
(xml2.MA_THUOC) và số đăng ký (xml2.SO_DANG_KY). Nếu tên thuốc khác
nhau so với danh mục thuốc thì tiến hành cảnh báo (xml2.TEN_THUOC !=
DM_THUOC_BV.TEN).
- F4_40: Thuốc sai đường dùng so với danh mục sử dụng tại bệnh viện
So sánh thuốc cơ sở sử dụng với danh mục thuốc sử dụng tại bệnh viện, theo mã
(xml2.MA_THUOC) và số đăng ký (xml2.SO_DANG_KY). Nếu đường dường
thuốc khác nhau so với danh mục thuốc thì tiến hành cảnh báo
(xml2.DUONG_DUNG != DM_THUOC_BV.DUONG_DUNG).
- F4_42: Thuốc sai hàm lượng so với danh mục sử dụng tại bệnh viện
So sánh thuốc cơ sở sử dụng tại bệnh viện, theo mã (xml2.MA_THUOC) và số
đăng ký (xml2.SO_DANG_KY). Nếu hàm lượng của thuốc cơ sở gửi lên khác so
với hàm lượng của thuốc trong danh mục tại bệnh viện thì cảnh báo
(xml2.HAM_LUONG != DM_THUOC_BV.HAM_LUONG).
- F4_43: Thuốc sai đường dùng so với Thông tư 40, Thông tư 05

53. 51
Tiến hành tìm kiếm hoạt chất trong Thông tư 40, Thông tư 05, nếu đường dùng
của hoạt chất trong Thông tư 40, Thông tư 05 mà khác so với đường dùng của thuốc
cơ sở gửi lên thì tiến hành cảnh báo (xml2.DUONG_DUNG !=
DM_HOATCHAT.DUONG_DUNG hoặc DM_YHCT.DUONG_DUNG).
- F6_43_1: Sử dụng thuốc đã có trong cơ cấu giá dịch vụ kỹ thuật (thuốc tê, mê,
chỉ định cùng thời gian thực hiện phẫu thuật thủ thuật)
Kiểm tra các thuốc cơ sở gửi lên đã có trong cơ cấu giá dịch vụ kỹ thuật nào chưa
(DM_COCAU_GIADV), nếu đã tồn tại trong danh mục cơ cấu giá dịch vụ kỹ thuật
thì xuất toán những thuốc đấy đi (vì đã thanh toán với dịch vụ kỹ thuật cơ cấu).
- F6_44: Sử dụng thuốc thanh toán sai tỷ lệ
Kiểm tra tỷ lệ thanh toán của hoạt chất của thuốc trong Thông tư 40
(DM_HOATCHAT), Thông tư 05 (DM_THUOCYHCT), nếu tỷ lệ thanh toán của
cơ sở gửi lên mà lớn hơn tỷ lệ thanh toán trong Thông tư 40, Thông tư 05 thì tiến
hành xuất toán phần tỷ lệ chênh lệch.
 Quy tắc dịch vụ
- F5_38: Dịch vụ kỹ thuật sai tên so với danh mục thực hiện
Tìm trong danh mục dịch vụ kỹ thuật của bệnh viện theo mã dịch vụ
(DM_DICHVU_BV), so sánh tên dịch vụ của cơ sở gửi lên với tên dịch vụ của danh
mục dịch vụ kỹ thuật (XML3.TEN_DICH_VU != DM_DICHVU_BV.TEN), nếu
khác nhau thì cảnh báo.
- F5_40: Dịch vụ kỹ thuật không nằm trong danh mục được thực hiện
Tìm trong danh mục dịch vụ kỹ thuật của bệnh viện theo mã dịch vụ
(DM_DICHVU_BV), nếu không tìm thấy thì tiến hành xuất toán những dịch vụ kỹ
thuật cơ sở gửi lên.
- F5_41: Dịch vụ kỹ thuật giá cao hơn giá phê duyệt
Tìm trong danh mục dịch vụ kỹ thuật của bệnh viện (DM_DICHVU_BV), so
sánh giá của dịch vụ kỹ thuật cơ sở gửi lên so sánh với giá của dịch vụ kỹ thuật trong
danh mục, nếu giá của dịch vụ kỹ thuật cao hơn thì tiến hành xuất toán phần giá

54. 52
chênh lệch của những dịch vụ kỹ thuật cơ sở gửi lên (XML3.DONGIA >
DM_DICHVU_BV.GIA).
- F5_42: Dịch vụ kỹ thuật có mã không nằm trong danh mục tương đương
Tìm trong danh mục tương đương được bộ y tế ban hành theo mã dịch vụ kỹ thuật
cơ sở gửi lên (DM_DICHVU_TD), nếu không tìm thấy thì cảnh báo.
- F5_43: Dịch vụ kỹ thuật có tên không nằm trong danh mục quy định (Thông
tư 43, Thông tư 50)
Tìm trong danh mục tên dịch vụ (Thông tư 43, Thông tư 50) theo mã dịch vụ kỹ
thuật cơ sở gửi lên (DM_TEN_DICHVU), nếu không tìm thấy thì cảnh báo.
 Quy tắc vật tư y tế
- F4_37: Vật tư y tế không thanh toán riêng (Thông tư 27)
Cơ sở sử dụng vật tư không tồn tại trong danh mục vật tư (Thông tư 27) mà bộ y
tế đã ban hành hoặc có tồn tại trong danh mục vật tư nhưng vật tư này được quy định
không được thanh toán riêng thì cũng xuất toán những vật tư này
(DM_VATTU.KHONGTHANHTOANRIENG == 1).
- F4_38: Vật tư y tế ngoài danh mục sử dụng tại bệnh viện
Mỗi cơ sở cũng sẽ có một danh mục vật tư y tế sử dụng riêng tại bệnh viện, các
cơ sở sẽ gửi danh mục vật tư lên bảo hiểm, các giám định viên sẽ giám định vật tư
và phê duyệt cho cơ sở sử dụng, Nếu cơ sở sử dụng vật tư ngoài danh mục vật tư đã
gửi lên bảo hiểm giám định thì sẽ bị xuất toán những vật tư này (DM_VATTU_BV).
- F6_43_2: Sử dụng vật tư y tế đã có trong cơ cấu giá dịch vụ kỹ thuật (chỉ định
cùng thời gian thực hiện phẫu thuật thủ thuật)
Kiểm tra các vật tư y tế cơ sở gửi lên đã có trong cơ cấu giá dịch vụ kỹ thuật hay
chưa, nếu đã tồn tại trong danh mục cơ cấu giá dịch vụ kỹ thuật thì xuất toán những
vật tư y tế đấy đi (vì đã thanh toán với dịch vụ kỹ thuật cơ cấu)
(DM_COCAUGIADV).
- F6_45: Sử dụng vật tư y tế thanh toán sai tỷ lệ

55. 53
Kiểm tra tỷ lệ thanh toán của vật tư y tế trong danh mục dùng chung được Bộ y
tế ban hành (DM_VATTU), nếu tỷ lệ thanh toán của cơ sở gửi lên mà lớn hơn tỷ lệ
thanh toán trong danh mục dùng chung thì tiến hành xuất toán phần chênh lệch
(XML3.TYLE > DM_VATTU.TYLE).
 Quy tắc khác
- F4_45: Máu có mã sai quy định
Căn cứ vào ngày sử dụng máu, tìm trong danh mục máu theo mã máu được cơ sở
gửi lên, nếu không tìm thấy thì cảnh báo (DM_MAU).
- F4_46: Dịch vụ vận chuyển máu có mã sai quy định
Kiểm tra mã máu cơ sở gửi lên có đúng chuẩn vận chuyển máu, nếu sai chuẩn thì
tiến hành cảnh báo (XML2.MA_THUOC không bắt đầu bằng “VM.”).
- F4_47: Máu vượt giá tối đa
Căn cứ vào ngày sử dụng máu, tìm được máu trong danh mục (DM_MAU), nếu
giá cơ sở gửi lên cao hơn giá trong danh mục tìm được thì tiến hành xuất toán phần
chênh lệch giá (xml2.DONGIA > DM_MAU.GIA).
- F4_49: Xét nghiệm máu có mã không nằm trong phê duyệt của cơ sở cung
cấp máu
Nếu mã máu cơ sở gửi lên có chuẩn theo công văn 510 (xml2.MA_THUOC có
định dạng XX.YYYY.ZZZZ.KAAAAA) thì tiến hành kiểm tra trong danh mục dịch
vụ (DM_DICHVU_BV với MA_CSKCB là AAAAA), nếu không tồn tại dịch vụ
nào có mã bằng mã cơ sở gửi lên thì tiến hành cảnh báo.
- F4_50: Xét nghiệm máu vượt giá phê duyệt của cơ sở cung cấp máu
Nếu mã máu cơ sở gửi lên có chuẩn theo công văn 510 (xml2.MA_THUOC có
định dạng XX.YYYY.ZZZZ.KAAAAA) thì tiến hành kiểm tra trong danh mục dịch
vụ (DM_DICHVU_BV với MA_CSKCB là AAAAA), nếu giá của dịch vụ xét
nghiệm cơ sở gửi lên cao hơn giá dịch vụ xét nghiệm trong danh mục thì tiến hành
xuất toán phần giá chênh lệch (xml2.DONGIA > DM_DICHVU_BV.GIA).

56. 54
- F4_51: Chi phí vật tư gạn tách máu có mã không nằm trong phê duyệt của cơ
sở cung cấp máu
Tìm trong danh mục vật tư của bệnh viện nếu không có vật tư gạn tách máu thì
tiến hành cảnh báo (Với xml2.MA_THUOC sáu kí tự cuối có định dạng KAAAAA
nhưng xml2.MA_THUOC không phải định dạng XX.YYYY.ZZZZ.KAAAAA),
tìm trong DM_VATTU_BV theo sáu kí tự của mã thuốc.
- F4_52: Vật tư máu có giá vượt giá phê duyệt của cơ sở cung cấp máu
Nếu tìm trong danh mục vật tư của bệnh viện mà giá vật tư cơ sở gửi lên cao hơn
thì tiến hành xuất toán phần chênh lệch giá. Với xml2.MA_THUOC sáu kí tự cuối
có định dạng KAAAAA nhưng xml2.MA_THUOC không phải định dạng
XX.YYYY.ZZZZ.KAAAAA), tìm trong DM_VATTU_BV theo sáu kí tự của mã
thuốc, nếu xml2.DONGIA > DM_VATTU_BV.GIA
- F6_48: Thanh toán tiền giường vượt quá số ngày quy định
Kiểm tra ngày vào, ngày ra của bệnh nhân, nếu số lượng ngày giường cơ sở đưa
lên lớn hơn so với thực tế ngày vào, ngày ra của bệnh nhân thì tiến hành xuất toán
chênh lệch ngày giường quá quy định (Tính số ngày nằm viện của bệnh nhân từ
xml1.NGAY_VAO và xml1.NGAY_RA, tính tổng số lượng ngày nằm viện của
bệnh nhân từ chi tiết xml3.SOLUONG với xml3.MA_NHOM = 14 hoặc 15).
- F8_56: Khám bệnh ngày nghỉ, không phải cấp cứu
Kiểm tra bệnh nhân khám chữa bệnh ở cơ sở có được thanh toán ngày nghỉ, cuối
tuần hay không. Nếu cơ sở không được thanh toán khám chữa bệnh ngày nghỉ, nghỉ
lễ không phải cấp cứu thì tiến hành cảnh báo (DM_COSOKCB.KHAMT7 == 1,
DM_COSOKCB.KHAMCN == 1, DM_COSOKCB.KHAM_NGAYLE == 1).

57. 55
3.2.2. Giám định danh mục
3.2.2.1. Phân rã domain
Với nghiệp vụ cần thực hiện lấy những danh mục mới được gửi lên rồi thực hiện
giám định. Giám định xong cập nhật kết quả giám định vào cơ sở dữ liệu và Từ các
nghiệp vụ như vậy, ta có phân rã domain thành một dãy các chức năng liên quan.
Hình 3.11. Phân rã domain giám định danh mục.
Sau khi phân rã domain thành một dãy các vùng chức năng liên quan, ta tiếp tục
phân tích từng vùng chức năng để xác định các sơ đồ sử dụng.
Mô hình usecase:
 Lấy danh mục mới được gửi
o Mô tả ngắn gọn: use case mô tả cách lấy danh sách danh mục mới
được gửi lên, sau đó thực hiện gửi các thông điệp chứa từng danh mục
trong danh sách lấy được cho use case xử lý giám định.
o Những luồng sự kiện:
 Luồng cơ bản: tiến hành kiểm tra có danh mục mới gửi lên hay
không, nếu có thì tiến hành lấy danh sách hồ sơ mới gửi để thực

58. 56
hiện gửi các thông điệp chứa từng danh mục trong danh sách lấy
được cho use case xử lý giám định.
 Luồng thay thế: trong trường hợp gửi thông điệp lỗi thì tiến hành
cập nhật lại danh mục về trạng thái mới gửi và ghi log vào thư
mục thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các danh mục mới tiếp theo.
o Điểm mở rộng: không
 Xử lý giám định
o Mô tả ngắn gọn: use case mô tả khi nhận được thông điệp từ use case
lấy danh mục mới được gửi, sau đó thực hiện kết nối cơ sở dữ liệu, lấy
những quy tắc hồ sơ và thực hiện chạy giám định. Sau khi chạy giám
định cần gửi thông điệp chứa kết quả giám định cho use case cập nhật
kết quả giám định.
o Những luồng sự kiện:
 Luồng cơ bản: khi nhận được thông điệp từ use case lấy danh
mục mới được gửi, sau đó thực hiện kết nối cơ sở dữ liệu, lấy
những quy tắc danh mục và thực hiện chạy giám định. Sau khi
chạy giám định cần gửi thông điệp chứa kết quả giám định cho
use case cập nhật kết quả.
 Luồng thay thế: trong trường hợp gửi thông điệp lỗi thì tiến hành
cập nhật lại danh mục về trạng thái mới gửi và ghi log vào thư
mục thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp, phải nhận được thông điệp
từ use case danh mục mới được gửi.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các thông điệp mới tiếp theo.
o Điểm mở rộng: không

59. 57
 Cập nhật kết quả giám định
o Mô tả ngắn gọn: use case mô tả khi nhận được thông điệp từ use case
xử lý giám định, sau đó thực hiện kết nối cơ sở dữ liệu, cập nhật kết quả
giám định vào cơ sở dữ liệu.
o Những luồng sự kiện:
 Luồng cơ bản: khi nhận được thông điệp từ use case xử lý giám
định, sau đó thực hiện kết nối cơ sở dữ liệu, cập nhật kết quả
giám định vào cơ sở dữ liệu.
 Luồng thay thế: trong trường hợp cập nhật lỗi thì tiến hành cập
nhật lại danh mục về trạng thái mới gửi và ghi log vào thư mục
thực thi.
o Yêu cầu đặc biệt: không
o Tiền điều kiện: hệ thống phải được kết nối được đến hệ thống cơ sở
dữ liệu và hệ thống chuyển giao thông điệp.
o Hậu điều kiện: sau khi thực hiện nghiệp vụ thành công, cần phải quay
vòng xử lý các danh mục tiếp theo.
o Điểm mở rộng: không
Với những yêu cầu chức năng trên sẽ cần những yêu cầu phi chức năng đi kèm như
sau:
 Khả năng dễ sử dụng
 Khả năng dễ triển khai
 Khả năng dễ bảo trì
 Khả năng chịu lỗi cao
 Tính sẵn sàng của hệ thống: hệ thống làm việc 24/24h trừ những khoảng thời
gian bảo trì, nâng cấp.
3.2.2.2. Xây dựng mô hình goal-service
Trong giai đoạn phân rã domain ta đã xác định được các usecase nghiệp vụ, và
đây sẽ là cơ sở chính để ta xác định các dịch vụ.
 Giám định danh mục
o Lấy danh mục mới được gửi

60. 58
 Kết nối cơ sở cơ sở dữ liệu để lấy các danh mục theo trạng thái
mới gửi
 GetListDm()
 Gửi thông điệp tới dịch vụ khác
 SendMessage(Message)
 Xử lý và ghi log khi có sự cố
 Xử lý(exeption)
 Ghi log(exeption)
o Xử lý giám định
 Nhận thông điệp từ dịch vụ khác
 GetMessage()
 Giải mã thông điệp
 Giả mã(Message)
 Kết nối cơ sở dữ liệu
 ConnectDB()
 Thực hiện giám định
 Thực hiện ánh xạ danh mục
o MappingDm(objectDm)
 Lấy các quy tắc giám định đang bật
o GetDmFunctionDm()
 Thực hiện chạy các quy tắc giám định
o Run(objectDm)
 Gửi thông điệp cho dịch vụ khác
 SendMessage(Message)
 Xử lý và ghi log khi có sự cố
 Xử lý()
 Ghi log()
o Cập nhật kết quả
 Nhận thông điệp từ dịch vụ khác
 GetMesssage()
 Giải mã thông điệp
 Giải mã(Message)