TỔNG QUAN
TÌNH HÌNH NGHIÊN CỨU TRONG VÀ NGOÀI NƯỚC
Nhiều bệnh viện hiện nay đang phải đối mặt với những vấn đề như "quá tải", "mất thời gian" và "mệt mỏi", phản ánh những hạn chế trong quy trình đăng ký và khám chữa bệnh tại các cơ sở y tế ở nước ta.
Hình 1.1 Thực trạng chờ khám hiện nay tại bệnh viện
Trong bối cảnh công nghệ phát triển, nhiều bệnh viện tại Việt Nam vẫn áp dụng các thủ tục khám chữa bệnh lạc hậu, gây khó khăn cho bác sĩ và bệnh nhân Để khắc phục tình trạng này, dự án “My Hospital” được thực hiện nhằm giảm tải số lượng bệnh nhân chờ khám và rút ngắn thời gian chờ đợi cho bệnh nhân.
1.1.2 Tính cấp thiết của đề tài
Hình 1.2 Ứng dụng Lucky Telecom Hình 1.3 Ứng dụng UMC
Tại thời điểm hiện tại, một số công ty như “Lucky Telecom” và “UMC-Datkham” đã ra mắt ứng dụng đặt số khám bệnh từ xa tại các bệnh viện, tuy nhiên hiệu quả áp dụng vẫn chưa đạt yêu cầu “Lucky Telecom” cho phép đặt số qua SMS nhưng ứng dụng di động chưa hoàn thiện, trong khi “UMC-Datkham” cung cấp nhiều tính năng tốt nhưng người dùng vẫn còn thụ động Nhận thấy những hạn chế này, nhóm nghiên cứu đã phát triển ứng dụng Android “My Hospital” với tính năng chính là “đặt số khám bệnh” Ứng dụng này không chỉ giúp người bệnh chủ động hơn thông qua màn hình “theo dõi trạng thái khám” mà còn dự đoán thời điểm khám bệnh một cách chính xác Thêm vào đó, ứng dụng còn hỗ trợ đăng ký, đăng nhập và quản lý thông tin cũng như bệnh án của người dùng.
Mỗi bệnh nhân sẽ nhận được một mã QR khi đăng ký, thay thế cho thẻ từ trước đây Ứng dụng hiển thị lịch khám cho hôm nay và các ngày sắp tới, đồng thời hỗ trợ ba đối tượng sử dụng: bệnh nhân, bác sĩ và quản trị viên.
MỤC TIÊU ĐỀ TÀI
Với dự án “My Hospital”, nhóm đặt mục tiêu giảm thời gian chờ đợi khám và tạo sự thân thiện cho bệnh nhân trong quá trình khám chữa bệnh tại các cơ sở y tế Để đạt được mục tiêu này, nhóm đã đề xuất các giải pháp cụ thể nhằm cải thiện trải nghiệm của bệnh nhân và nâng cao hiệu quả dịch vụ y tế.
▪ Lấy số khám bệnh thông qua ứng dụng My Hospital
▪ Theo dõi trạng thái của các phòng khám
▪ Tính toán thời gian khám bệnh của bệnh nhân
▪ Hiển thị lịch khám hôm nay và các ngày trong tương lai
▪ Đảm bảo tính Realtime của ứng dụng
Bên cạnh đó, “Quản lý thông tin bệnh nhân” cũng là mục tiêu mà nhóm phải thực hiện thông qua:
▪ Đăng ký/Đăng nhập thành viên
▪ Tạo mã QR cho người dùng khi đăng ký để truy xuất thông tin người dùng
▪ Lưu kết quả chuẩn đoán, toa thuốc của mỗi lần khám
▪ Lịch sử đăng ký khám.
ĐỐI TƯỢNG VÀ PHẠM VI NGHIÊN CỨU
“My Hospital” sẽ bao gồm cả phần cứng lẫn phần mềm
Bộ phần cứng cho đề tài bao gồm các nút nhấn "Next" trong phòng khám và nút cấp số khám tại bệnh viện Nhóm đã chọn NodeMCU làm bộ xử lý trung tâm, do đó, nghiên cứu hoạt động của kit phát triển này là nhiệm vụ quan trọng mà nhóm cần thực hiện.
Phần mềm nhóm thực hiện là một ứng dụng di động Android được phát triển bằng ngôn ngữ lập trình JAVA Trong quá trình xây dựng ứng dụng, nhóm cần tìm hiểu sâu về JAVA và các kỹ thuật cần thiết để triển khai một ứng dụng Android hiệu quả.
Firebase là một đối tượng nghiên cứu quan trọng trong đề tài "My Hospital", vì nó được triển khai trên cả phần cứng và phần mềm, đóng vai trò then chốt trong việc phát triển ứng dụng này.
PHƯƠNG PHÁP NGHIÊN CỨU
Để tiếp cận hiệu quả với các đối tượng như Firebase và lập trình ứng dụng Android, nhóm đã ưu tiên tìm hiểu qua video từ các trang web hướng dẫn lập trình như Howkteam và ThangCoder Bên cạnh đó, nhóm cũng tham khảo tài liệu hướng dẫn từ các nguồn chính thống như developer.android.com và tài liệu Firebase của Google.
BỐ CỤC ĐỒ ÁN
Bố cục đồ án bao gồm 5 chương chính:
Chương 1: Tổng quan về thực trạng đăng ký khám bệnh tại các bệnh viện hiện nay sẽ được nhóm trình bày, đồng thời xác định mục tiêu và phạm vi nghiên cứu của đề tài.
Chương 2: Cơ sở lý thuyết sẽ trình bày một cái nhìn tổng quan về các lý thuyết cơ bản liên quan đến các thành phần trong hệ thống Nhóm nghiên cứu sẽ phân tích và giải thích các khái niệm cốt lõi, nhằm cung cấp nền tảng vững chắc cho việc hiểu và áp dụng các thành phần này trong thực tiễn.
Chương 3: Thiết kế và xây dựng hệ thống sẽ trình bày quy trình thiết kế và tính toán nhằm thực hiện chức năng của các thành phần trong hệ thống Nội dung bao gồm thiết kế và tính toán phần cứng, phần mềm, cũng như xây dựng cơ sở dữ liệu.
- Chương 4: Kết quả và thực nghiệm: Trong chương này, nhóm sẽ đưa ra kết quả mà nhóm đã đạt được, hình ảnh của hệ thống sau khi thi công
- Chương 5: Kết luận và hướng phát triển: Trong chương này, nhóm sẽ đưa ra kết luận, những điểm mạnh và điểm yếu và hướng phát triển của đề tài
CƠ SỞ LÝ THUYẾT
MÃ QR (QUICK RESPONSE CODE)
Mã QR, được phát triển bởi Denso Wave (công ty con của Toyota) vào năm 1994, có hình dạng đặc trưng với các điểm đen và ô vuông nằm trong một ô vuông mẫu trên nền trắng So với mã vạch truyền thống, mã QR cho phép đọc nhanh hơn, tiết kiệm thời gian và không gian lưu trữ.
Mã QR có khả năng lưu trữ nhiều loại thông tin như địa chỉ web (URL), thời gian sự kiện, thông tin liên hệ, địa chỉ Email, tin nhắn SMS, nội dung văn bản, và thông tin vị trí địa lý Khi người dùng quét mã QR bằng thiết bị của mình, họ có thể được dẫn đến trang web, gọi điện thoại, hoặc xem tin nhắn tương ứng.
QR code tương tự như mã vạch truyền thống, thường được sử dụng trên thùng hàng và sản phẩm để giúp người bán lẻ theo dõi, quản lý kho hàng và giá cả Tuy nhiên, điểm khác biệt lớn giữa QR code và mã vạch truyền thống là khả năng lưu trữ và chia sẻ lượng dữ liệu phong phú hơn của QR code.
Mã vạch truyền thống chỉ có thể lưu trữ 20 chữ số với các đường vạch thẳng hàng một chiều, trong khi mã QR hai chiều có khả năng chứa hàng ngàn ký tự Với khả năng lưu trữ thông tin vượt trội và tính tiện dụng, mã QR mang lại lợi ích đáng kể cho doanh nghiệp nhỏ.
Dung lượng lưu trữ của mã QR:
Bảng 2.1 Khả năng lưu trữ của QR Code
Số Tối đa 7.089 ký tự
Chữ số Tối đa 4.296 ký tự
FIREBASE
Firebase là dịch vụ backend do Google cung cấp, giúp rút ngắn thời gian phát triển và triển khai ứng dụng di động trên cả hai nền tảng Android và iOS Với tính năng mạnh mẽ, đa năng và bảo mật, Firebase là lựa chọn thiết yếu cho việc xây dựng ứng dụng phục vụ hàng triệu người dùng Sử dụng Firebase, người dùng sẽ nhận được nhiều lợi ích đáng kể.
Firebase cho phép xây dựng ứng dụng nhanh chóng mà không cần tốn thời gian và nhân lực cho việc quản lý hệ thống và cơ sở hạ tầng Với các tính năng như phân tích, cơ sở dữ liệu, báo cáo hoạt động và báo cáo sự cố lỗi, Firebase giúp bạn dễ dàng phát triển ứng dụng, định hướng đến người dùng và mang lại trải nghiệm tốt nhất cho họ.
Firebase, được Google hỗ trợ, đảm bảo uy tín và chất lượng với hạ tầng phần cứng toàn cầu, được tin dùng bởi nhiều tập đoàn lớn và ứng dụng có hàng triệu người sử dụng.
Quản lý cấu hình và trải nghiệm ứng dụng Firebase được tối ưu hóa qua một giao diện website đơn giản, cho phép các ứng dụng hoạt động độc lập trong khi vẫn kết nối chặt chẽ với dữ liệu phân tích.
Các dịch vụ của Firebase được sử dụng trong My Hospital:
Firebase's Realtime Database utilizes a NoSQL cloud storage system, where data is organized in a JSON tree format This allows users to easily store and synchronize their data in real-time.
Các nhà phát triển có thể quản lý các node JSON theo thời gian thực, cho phép họ thực hiện các thay đổi ngay lập tức cho người dùng mà không cần cập nhật ứng dụng di động hoặc web.
Để đáp ứng yêu cầu về tính Realtime, nhóm đã quyết định lựa chọn cơ sở dữ liệu NoSQL Ứng dụng cần nhiều tính năng như Đăng ký/Đăng nhập, quản lý người dùng, lưu trữ thông tin và hình ảnh mã QR Vì vậy, Firebase của Google được xem là lựa chọn tối ưu về cả chức năng lẫn thời gian thực hiện, dẫn đến quyết định sử dụng Firebase cho đề tài này.
Firebase Authentication cung cấp giải pháp quản lý người dùng đơn giản và an toàn, hỗ trợ nhiều phương pháp xác thực như email và mật khẩu Ngoài ra, nó cho phép tích hợp với các nhà cung cấp bên thứ ba như Google và Facebook, sử dụng tài khoản hiện có của người dùng Người dùng có thể xây dựng giao diện tùy chỉnh hoặc tận dụng mã nguồn mở để tạo ra trải nghiệm người dùng hoàn hảo.
Cloud Storage cho phép người dùng lưu trữ và chia sẻ nội dung như hình ảnh, âm thanh và video với giải pháp lưu trữ đối tượng mạnh mẽ, đơn giản và tiết kiệm chi phí từ Google Firebase SDK cho Cloud Storage cung cấp tính năng bảo mật của Google, giúp người dùng tải lên và tải tệp cho các ứng dụng Firebase một cách dễ dàng, bất kể chất lượng mạng.
WIFI
Wifi, viết tắt từ Wireless Fidelity hay mạng 802.11, là hệ thống mạng không dây sử dụng sóng vô tuyến, tương tự như điện thoại di động, truyền hình và radio Kết nối wifi được nhiều người ưa chuộng nhờ tính tiện lợi và kinh tế, đặc biệt trong các mô hình mạng LAN với phạm vi địa lý hạn chế.
Ngày nay, hầu hết các thiết bị điện tử như máy tính, laptop, điện thoại và máy tính bảng đều hỗ trợ kết nối WiFi WiFi hoạt động bằng cách chuyển đổi mã nhị phân 1 và 0 thành sóng vô tuyến và ngược lại Điểm khác biệt của sóng WiFi so với các sóng vô tuyến khác là nó truyền và phát tín hiệu ở tần số 2.4 GHz hoặc 5 GHz, cao hơn so với tần số sử dụng cho điện thoại di động, thiết bị cầm tay và truyền hình Tần số cao này cho phép tín hiệu mang theo nhiều dữ liệu hơn.
Sóng Wifi sử dụng chuẩn kết nối 802.11 theo thư viện IEEE, với hầu hết các thiết bị hiện nay tuân theo chuẩn 802.11n Chuẩn này hoạt động ở tần số 2.4Ghz và có khả năng đạt tốc độ xử lý tối đa lên đến 300 Megabit/giây.
Nhóm chọn Wifi vì việc sử dụng Database RealTime từ Firebase, kết hợp với sự phổ biến rộng rãi của Wifi hiện nay, giúp việc triển khai trở nên dễ dàng hơn.
Hình 2.6 Các thiết bị kết nối wifi để truy cập internet
NODE MCU
Kít ESP8266 là một bộ phát triển dựa trên chip Wifi SoC ESP8266, thiết kế thân thiện với người dùng nhờ vào việc tích hợp mạch nạp CP2102 trên board Với lõi vi xử lý có sẵn, người dùng có thể lập trình trực tiếp cho ESP8266 mà không cần sử dụng thêm vi xử lý khác Hiện nay, ESP8266 có thể được lập trình bằng hai ngôn ngữ: thông qua phần mềm IDE của Arduino với bộ thư viện riêng hoặc sử dụng phần mềm NodeMCU.
Về phần cứng, nhóm lựa chọn Node MCU làm bộ xử lý trung tâm cho các bộ cấp số và gọi số trong đề tài này, nhờ vào khả năng kết nối wifi, hỗ trợ database realtime và thực hiện các tác vụ tính toán xử lý dữ liệu đơn giản.
Bảng 2.2 Thông số kỹ thuật NodeMCU
WIFI 2.4GHz hỗ trợ chuẩn 802.11 b/g/n Điện áp hoạt động 3.3V Điện áp vào 5V thông qua cổng USB
Số chân Analog Input 1 (điện áp vào tối đa 3.3v)
Giao tiếp Cable Micro USB
Hỗ trợ bảo mật WPA/WPA2
Giao thức tích hợp TCP/IP
Lập trình trên các ngôn ngữ C/C++, Micropython,…
Hình 2.8 Sơ đồ chân NodeMCU
NÚT NHẤN
Linh kiện dùng để đóng ngắt, có thể có 2 chân hoặc 4 chân Với phần cứng được thực hiện cho đề tài này, nhóm sử dụng nút nhấn 2 chân
Khi không có tác động đến nút nhấn, mạch để hở:
Khi không có tác động đến nút nhấn, mạch kín:
BUZZER
Linh kiện điều khiển phát ra tín hiệu âm thanh, giúp đánh dấu các quy trình vận hành trong hệ thống.
THIẾT KẾ VÀ XÂY DỰNG HỆ THỐNG
SƠ ĐỒ KHỐI HỆ THỐNG
▪ Ứng dụng di động và phần cứng NodeMCU phải đáp ứng được yêu cầu về thời gian thực của hệ thống
Ứng dụng di động cần hỗ trợ chức năng đăng ký và đăng nhập cho ba đối tượng chính: bệnh nhân, bác sĩ và quản trị viên Ngoài ra, ứng dụng cũng phải có khả năng cấp phát và quét mã QR đã được cung cấp cho bệnh nhân.
▪ Ứng dụng di động phải có khả năng truy xuất Firebase trong việc đọc và ghi dữ liệu
▪ Phần cứng Nút lấy số do NodeMCU điều khiển phải có khả năng đọc và ghi dữ liệu lên Firebase
Hình 3.1 Sơ đồ khồi hệ thống
3.1.3 Chức năng của từng khối
▪ Hỗ trợ việc lưu trữ dữ liệu người dùng, bác sĩ, admin
▪ Hỗ trợ việc tạo thêm User bằng Email và Password
▪ Cho phép lưu trữ hình ảnh: mã QR của bệnh nhân
▪ Cập nhât Realtime các thay đổi dữ liệu tại các Node JSON cho người dùng ỨNG DỤNG ANDROID
▪ Cho phép người bệnh có thể chủ động xem lịch khám bệnh, lấy số khám và xem trạng thái khám bệnh tại bênh viện
▪ Ước lượng thời gian vào khám của bệnh nhân
▪ Cho phép bác sĩ có thể scan mã QR của bệnh nhân để xem bệnh án và ghi bệnh án cho bệnh nhân
Người quản trị có khả năng quản lý hiệu quả các phòng khám và bác sĩ thông qua việc chỉnh sửa lịch làm việc của phòng khám, cũng như tạo thêm tài khoản cho bác sĩ và các quản trị viên đồng cấp.
▪ Cập nhật lịch khám của các bệnh nhân đã đặt trước cho mỗi ngày
▪ Truy cập Database để lấy dữ liệu cần thiết, xử lý và cập nhật dữ liệu
▪ Nút nhấn để bác sĩ gọi số thứ tự kế tiếp vào phòng
▪ Nút nhấn để nhân viên bệnh viện cấp số khám cho các bệnh nhân không sử dụng ứng dụng “My Hospital” ở các phòng khám mong muốn
NGUỒN: Cấp nguồn để phần cứng hỗ trợ hoạt động.
THIẾT KẾ VÀ TÍNH TOÁN HỆ THỐNG
3.2.1 FireBase a Quản lý User thông qua Firebase Authentication
Để thay thế sổ khám bệnh, mỗi bệnh nhân cần tạo một tài khoản riêng trên ứng dụng "My Hospital" Việc này giúp quản lý thông tin khám chữa bệnh một cách hiệu quả và thuận tiện hơn.
15 đăng nhập và xác minh là hết sức cần thiết Firebase Authentication hỗ trợ việc quản lý người dùng hết sức hiệu quả
Firebase Authentication hỗ trợ tạo tài khoản mới qua nhiều phương thức như Facebook, Google, SMS, và Email Trong ứng dụng "My Hospital", người dùng thực hiện đăng ký và đăng nhập bằng email cá nhân Để kích hoạt tính năng Authentication, bạn cần vào mục Sign-In Method và bật tính năng cho phương thức email.
Hình 3.3 Màn hình cho phép đăng nhập bằng email
Sau khi kích hoạt, dựa vào hàm Sign in được cung cấp bởi Firebase và truyền vào hai đối tượng là email và password để có thể lưu lại
Hình 3.4 Màn hình danh sách các tài khoản đã được tạo
Ngoài các chức năng cơ bản, nhóm còn tích hợp thêm các tính năng mở rộng của Firebase Authentication để nâng cao tính ứng dụng.
▪ Cho phép đổi mật khẩu khi người dùng quên mật khẩu thông qua email (Reset password)
▪ Lấy thông tin người dùng hiện tại đang nhập để xử lý các tác vụ khác( Get User’s Information)
▪ Xác thực tài khoản email khi đăng kí để tránh trường hợp email dùng đăng kí là một email không tồn tại (Verify Email)
Chức năng reset password được triển khai để người dùng có thể khôi phục mật khẩu qua email đã đăng ký Firebase hỗ trợ các hàm cần thiết cho thao tác này, yêu cầu người dùng cung cấp email của mình để thực hiện.
Để thu thập thông tin người dùng, cần thực hiện một số thao tác để xác định địa chỉ email của họ và trạng thái xác thực của email đó.
17 nhóm sử dụng một chức năng khác của Authentication là Get User Password, kết quả nhận được sẽ là tên, email, trạng thái xác thực , của tài khoản
Xác thực email là một giải pháp hiệu quả nhằm ngăn chặn việc người dùng tạo nhiều tài khoản từ các email ảo hoặc không còn sử dụng Khi bắt đầu tạo tài khoản, hệ thống sẽ gửi một email đến địa chỉ đã đăng ký để xác nhận Email xác nhận chỉ có hiệu lực trong một khoảng thời gian nhất định; sau thời gian này, việc nhấp vào liên kết trong email sẽ không còn tác dụng Người dùng có thể yêu cầu xác thực email thông qua ứng dụng di động “My Hospital”.
Nếu email đăng ký đã được xác nhận, người dùng sẽ có toàn quyền thực hiện các thao tác trên ứng dụng Ngược lại, nếu email chưa được xác nhận, họ sẽ không thể đặt trước số khám bệnh.
Hình 3.5 Nội dung mail xác nhận tài khoản b Lưu trữ thông tin bằng Database:
Các thông tin của người dùng là hết sức cần thiết vì nó liên quan mật thiết đến các tác vụ của ứng dụng
Cấu trúc lưu trữ đơn giản của Realtime Database, với dạng cây JSON, cho phép lưu trữ và truy xuất dữ liệu nhanh chóng, đồng thời đáp ứng hiệu quả yêu cầu về tính thời gian thực của ứng dụng.
Hình trên là cấu trúc thu gọn của Database của ứng dụng “My Hospital” Database được xây dựng với các Node dữ liệu chính dưới đây:
▪ ROOM: Node lưu trữ thông tin về các phòng khám
Thông tin từ ROOM sẽ được sử dụng để thực hiện nhiều chức năng, bao gồm việc lấy dữ liệu Realtime nhằm hiển thị trạng thái các phòng khám trong Tab My Hospital và ước lượng thời gian khám của bệnh nhân khi họ lấy số khám qua ứng dụng.
Node SCHEDULE lưu trữ thông tin về danh sách bệnh nhân đã đặt lịch khám Dữ liệu trong SCHEDULE được sử dụng để cập nhật số lượng khám đã được đặt cho từng ngày tại các phòng khám.
▪ USERS: Node lưu trữ các thông tin của bệnh nhân
Node "USER" chứa dữ liệu của ba đối tượng: bác sĩ, bệnh nhân và quản trị viên Thông tin trong "USER" được sử dụng cho nhiều chức năng của ứng dụng, bao gồm việc truy xuất thông tin bệnh án, kiểm tra lịch khám và ước lượng thời gian khám.
▪ date: node dữ liệu hiển thị ngày hiện tại
Hệ thống bao gồm ứng dụng My Hospital và bộ cấp số, sử dụng dữ liệu để kiểm tra ngày tháng hiện tại và cập nhật thông tin đặt khám tới node “ROOM”, hiển thị kết quả trên ứng dụng và bộ cấp số.
▪ specialist: Node lưu trữ thông tin về các phòng khám chuyên khoa
Tương tự như “ROOM” nhưng node “specialist” lưu dữ liệu khám của các phòng chuyên khoa
Các Node chứa dữ liệu cho từng phòng khám, trong đó node "nextroom" cho biết bệnh nhân lấy số kế tiếp sẽ được cấp số ở phòng số 1 Thông tin về "soluong" cho biết số lượng phòng khám hiện có.
Node 1 bao gồm các thông tin quan trọng như check_number, đại diện cho số thứ tự khám bệnh; doctor, tên bác sĩ làm việc tại phòng số 1; và flag, cờ báo hiệu sự thay đổi dữ liệu, được sử dụng để ước lượng thời gian khám (ULTGK) Ngoài ra, n là số lượng bệnh nhân có thời gian khám hợp lệ.
ULTGK) sophong: số phòng total_number: tổng số bệnh nhân đăng kí khám ở phòng
1 w_checknum: số thứ tự dùng làm mốc tính toán
(ULTGK) w_hour: mốc thời gian – giờ (ULTGK) w_minute: mốc thời gian – phút (ULTGK) w_wait: thời gian khám trung bình cho 1 bệnh nhân
Mở rộng Node SHEDULE: soluong: số lượng ngày có bệnh nhân lấy số khám bằng My Hospital
Các Node lại lưu trữ dữ liệu về lịch khám của bệnh nhân trong các ngày
Vào ngày 8-5-2019, bệnh nhân sẽ được khám tại phòng khám được chỉ định, nơi mà số khám sẽ được cấp phát cho bệnh nhân tiếp theo Hiện tại, có một số lượng phòng khám đang có bệnh nhân lấy số khám.
Các node còn lại là danh sách các phòng khám có bệnh nhân lấy số khám
Mở rộng Node 1: total_number : tổng số bệnh nhân đã lấy số khám cho phòng số 1 vào ngày đó
(47,48,49,51): số khám của các bệnh nhân đã lấy số bằng app My Hospital Thông tin của các node này là email của bệnh nhân đã lấy số
Các Node bên dưới là danh sách các người dùng đã đăng ký với ứng dụng
Người dùng gồm 3 đối tượng là Bác sĩ,
Bệnh nhân và Quản trị Ba đối tượng được phân biệt với nhau bằng thông tin
Mở rộng Node dinhzahuan5035gmail: ĐÂY LÀ QUẢN TRỊ VIÊN – quyen:
LƯU ĐỒ GIẢI THUẬT
3.3.1 Ước lượng thời gian khám
Thời gian ước lượng dựa trên các dữ liệu cần thiết và các sự kiện đặc biệt
▪ flag: dữ liệu báo hiệu cần cập nhật mốc thời gian
▪ w_hour: mốc thời gian (giờ)
▪ w_minute: mốc thời gian (phút)
▪ w_checknum: số thứ tự mốc
Nếu thời gian khám của bệnh nhân A không nằm trong khoảng quy định từ 4 đến 8 phút, hệ thống sẽ cần điều chỉnh lại thời gian khám dự kiến cho các bệnh nhân khác.
53 nhân được xác định dựa trên thời gian ngay sau khi bệnh nhân A rời khỏi phòng khám, cùng với khoảng cách giữa số lần khám của bệnh nhân này và bệnh nhân A.
▪ n: Số lượng bệnh nhân đã khám
▪ denta: Khoảng thời gian khám cho bệnh nhân
▪ w_wait: Khoảng thời gian khám trung bình giành cho 1 bệnh nhân
▪ estimate: Khoảng thời gian đợi cho tới lúc bệnh nhân được khám
▪ check_time: Thời gian khám dự tính của bệnh nhân
Việc ước lượng thời gian sẽ có ba trường hợp xảy ra:
Tính toán và ước lượng thời gian dựa trên mốc thời gian cũ (w_hour, w_minute)
Tính w_wait, estimate, check_time w_wait = (w_wait∗𝑛)+𝑑𝑒𝑛𝑡𝑎
𝑛+1 , n = n+1 estimate = w_wait *(số thứ tự - w_checknum) check_time { ℎ𝑜𝑢𝑟 = 𝑤_ℎ𝑜𝑢𝑟 + ℎ𝑜𝑢𝑟/60
Trường hợp thời gian khám vượt quá thời gian quy định
Xảy ra khi thời gian khám cho 1 bệnh nhân không nằm trong khoảng
[ 4:8 ] phút Hoặc bác sĩ check in phòng khám
Cập nhật lại mốc thời gian mới là thời gian hiện tại và ước lượng lại
Cập nhật lại w_hour và w_minute là thời gian hiện tại và w_checknum
Tính toán ước lượng dựa trên thời gian chờ (w_wait) trước đó và khoảng cách giữa số lần khám của bệnh nhân với số khám hiện tại Các biến được sử dụng bao gồm: w_hour (giờ hiện tại), w_minute (phút hiện tại) và w_checknum (số thứ tự khám tiếp theo, được tính bằng số thứ tự vừa khám xong cộng thêm 1).
Trường hợp thời gian ước lượng khám vượt quá giờ nghỉ trưa
Nếu quá 11h30: tính toán khoảng thời gian cách biệt và cộng khoảng thời gian ấy với 13h
Nếu quá 17h30: Hệ thống không nhận đặt số
Tính khoảng thời gian quá giờ, cộng khoảng thời gian đó với 13h
Ví dụ: bệnh nhân A có số khám thứ 26 tại phòng số 1 có các thông số:
• mốc thời gian w_hour = 6 và w_minute = 30
Giả sử thời gian khám cho bệnh nhân mới nhất là 7.2 phút w_wait = 6.57; estimate = 171 phút → 2 tiếng 51 phút time_check = 8 giờ 81 phút → 9 giờ 21 phút
Giả sử thời gian khám cho bệnh nhân số 12 là 10 phút, điều này vượt quá thời gian quy định Tại thời điểm đó, thời gian chờ (w_wait) là 6.67 phút, do đó cần cập nhật lại các thông số w_hour, w_minute và w_checknum.
Thời gian ra khỏi phòng khám của số 12 là 7h59p w_checknum = 13; w_hour = 7; w_minute = 59;
➔ Tính lại estimate cho bệnh nhân A estimate = 6.67*(26 - 13) = 87 phút → 1 tiếng 27 phút check_time = 8 giờ 86 phút → 9 giờ 26 phút
Giả sử bệnh nhân B có số khám là 59
Giữ lại các thông số như ở trường hợp 2 để tính toán thử estimate = 6.67*(59-13)= 307 phút → 5 tiếng 7 phút check_time = (7+5) giờ (59+7) phút = 12 giờ 66 phút
Thời gian quá giờ = (12 - 11) tiếng (66 - 30) phút = 1 tiếng 36 phút check_time = (13 + 1) giờ (0 + 36) phút → 14 giờ 36 phút
Thời gian khám được ước lượng thông qua sự hợp tác giữa Bác sĩ và Bệnh nhân, với sự hỗ trợ của Realtime Database, giúp việc lấy và cập nhật dữ liệu trở nên dễ dàng hơn Ứng dụng sử dụng hai phương thức lấy dữ liệu của Firebase là SingleValue và EvenValue.
▪ SingleValue: dữ liệu sẽ chỉ được get một lần khi gọi
▪ EvenValue: dữ liệu được get khi gọi ban đầu, sau đó, nếu có sự thay đổi dữ liệu ở RealTime Database, dữ liệu sẽ được get lại
Lưu đồ thể hiện rằng, ở ứng dụng của bác sĩ, dữ liệu w_wait được get theo kiểu
EvenValue, còn ở phía bệnh nhân, flag được get theo kiểu EvenValue Các dữ liệu còn lại được get theo kiểu SingleValue
Lưu đồ dưới đây minh họa quy trình tương tác giữa bác sĩ, bệnh nhân và cơ sở dữ liệu trong việc ước lượng thời gian khám Lưu ý rằng các dữ liệu hiển thị chỉ là những thông tin cần thiết cho việc ước lượng, không phải toàn bộ dữ liệu có trong cơ sở dữ liệu.
Hình 3.37 Lưu đồ ước lượng thời gian khám của bệnh nhân
Việc ước lượng thời gian khám bệnh được thực hiện đồng thời giữa bệnh nhân và bác sĩ, đồng thời kết hợp với việc truy xuất dữ liệu từ cơ sở dữ liệu.
Hình 3.38 Lưu đồ ước lượng thời gian khám của bệnh nhân được thực hiện bởi bác sĩ và bệnh nhân
3.3.2 Cấp số khám cho bệnh nhân
Việc cấp số khám cho bệnh nhân sẽ được sẽ khác nhau với hai kiểu phòng khám: Phòng tiếp nhận và phòng khám chuyên khoa
Phòng tiếp nhận sẽ phân bổ số khám cho bệnh nhân một cách đồng đều giữa các phòng, nhằm tránh tình trạng mất cân bằng lượng bệnh nhân Để thực hiện điều này, việc tính toán cần dựa trên dữ liệu lưu trữ trong cơ sở dữ liệu (Database).
✓ soluong: Tổng số phòng tiếp nhận hiện có tại bệnh viện
✓ nextroom: Số phòng mà bệnh nhân kế tiếp sẽ được cấp số
✓ total_number: Tổng số bệnh nhân đã đăng ký khám với phòng đó
Số khám sẽ được cấp dựa trên tổng số bệnh nhân đã nhận số tại phòng khám, tăng thêm 1 Giá trị nextroom sẽ được tính bằng số phòng hiện tại cộng với 1, và lần cấp số khám tiếp theo sẽ thuộc về phòng có số tương ứng với next.
Phòng chuyên khoa: việc cấp số đơn giản hơn, việc cấp số chỉ dựa trên tổng số bệnh nhân đã được cấp số cho phòng đó – total_number
Hình 3.39 Lưu đồ thực hiện cấp phát số khám cho bệnh nhân ở các phòng tiếp nhận
Hình 3.40 Lưu đồ cấp số khám cho bệnh nhân tại phòng Chuyên Khoa
3.3.3 Cập nhật lịch khám khi khởi động
Việc cập nhật lịch khám tại ứng dụng My Hospital sẽ dựa trên node "date" và node "SCHEDULE" trong cơ sở dữ liệu, với sự hỗ trợ từ phần cứng liên quan.
Để cập nhật lịch khám, trước tiên cần so sánh ngày-tháng-năm với dữ liệu tại node "date" Nếu dữ liệu trùng khớp, quá trình sẽ kết thúc Ngược lại, nếu không trùng khớp, hãy truy cập node "SCHEDULE" để kiểm tra xem có tồn tại node dữ liệu mang tên "ngày-tháng-năm" hay không.
Nếu có bệnh nhân đặt khám trong ngày, ứng dụng cần cập nhật tổng số phiếu tại các phòng và các dữ liệu cần thiết.
Nếu không tức là chưa có bệnh nhân nào đặt số khám cho hôm nay và ứng dụng sẽ cập nhật các dữ liệu theo giá trị mặc định
Các dữ liệu cần cập nhật ở Database:
Bảng 3.8 Giá trị cập nhật mỗi ngày tới Database
TÊN DỮ LIỆU GIÁ TRỊ CẬP
Doctor “No doctor in the room”
Tên bác sĩ check_number 0 Số thứ tự hiện tại total_numer 0 Tổng số bệnh nhân đã lấy số khám tại phòng
Flag 0 Cờ báo có thay đổi mốc thời gian w_checknum 0 Số thứ tự của mốc thời gian w_hour 6 Mốc thời gian – giờ w-minute 0 Mốc thời gian- phút
Date Ngày-tháng-năm hiện tại
Ngày tháng năm hiện tại
Nextroom 1 Phòng khám kế tiếp sẽ cấp số khám cho bệnh nhân
Hình 3.41 Lưu đồ giải thuật cập nhật lịch khám cho ngày hiện tại ở các phòng khám
Hình 3.42 Lưu đồ giải thuật cập nhật lịch khám tại các phòng
KẾT QUẢ VÀ THỰC NGHIỆM
KẾT QUẢ
Sau khi thực hiện các thao tác trên, nhóm đã hoàn thành các khối trên:
✓ Ứng dụng Android My Hospital
Hệ thống hiện tại đã đáp ứng 85% các yêu cầu ban đầu, tuy nhiên cần cải thiện một số điểm như tăng tốc độ hoạt động và sắp xếp thông tin hiển thị một cách rõ ràng hơn.
Clip mô phỏng hoạt đoạt của sản nhóm có đăng lên Youtube, mong thầy xem qua:
Link: https://www.youtube.com/watch?v=-8jxJrpwXqc
Hình 4.1 Bộ cấp số khám
Hình 4.2 Bộ tăng số thứ tự
Hình 4.3 Cây JSON của FireBase
Hình 4.4 Ứng dụng My Hospital
THỰC NGHIỆM
Bảng 4 1 Thực nghiệm phần mềm
Màn hình theo dõi trạng thái khám bệnh tại các phòng trong bệnh viện, bao gồm:
- Tổng số bệnh nhân đã đăng kí ở phòng đó
- Số thứ tự đang được khám
Danh sách lịch khám sắp tới sẽ hiển thị cho bệnh nhân những cuộc hẹn đã đặt, đồng thời cho phép bệnh nhân lấy số tiếp cho ngày khác Hệ thống cũng ước lượng thời gian khám của bệnh nhân một cách chính xác.
Hiển thị bệnh án của bệnh nhân
Giao diện làm việc của bác sĩ ở các phòng tiếp nhận
Sau khi check in tại phòng khám, các thông tin của phòng khám sẽ được hiển thị ở giao diện làm việc
Giao diện của bác sĩ khi làm việc tại các phòng khám chuyên khoa
Giao diện của quản trị viên sau khi đăng nhập với tài khoản quản trị
Bảng 4 2 Thực nghiệm phần cứng
Màn hình LCD hiển thị lời chào sau khi phần cứng khởi động và cập nhật dữ liệu với Database
LCD hiển thị số được cấp cho bệnh nhân tại phòng tiếp nhận khi nhấn nút cấp số
LCD hiển thị số được cấp tại phòng Siêu Âm sau khi nhấn nút chuyển phòng và nhấn nút cấp số Đánh giá:
• Phần mềm: Hoạt động ổn định, đáp ứng đúng yêu cầu về mặt dữ liệu và tính toán
• Phần cứng: Đáp ứng tốt các yêu cầu chức năng tuy nhiên độ ổn định chỉ ở mức khá do phụ thuộc nhiều vào chất lượng của Wifi
