Giới thiệu dự án

Tình trạng quá tải tại các cơ sở y tế và bệnh viện công lập là một trong những rào cản lớn nhất đối với chất lượng dịch vụ chăm sóc sức khỏe. Theo thống kê từ Bộ Y tế, thời gian chờ đợi trung bình của một bệnh nhân ngoại trú tại các bệnh viện tuyến trung ương dao động từ 3 đến 5 giờ, trong khi thời gian khám và tư vấn trực tiếp với bác sĩ chỉ chiếm khoảng 10 đến 15 phút. Quy trình đăng ký khám chữa bệnh truyền thống bộc lộ nhiều hạn chế nghiêm trọng:

  • Bệnh nhân phải tập trung xếp hàng từ 4 - 5 giờ sáng để lấy số thứ tự thủ công, gây ùn tắc cục bộ tại sảnh tiếp đón.
  • Bác sĩ và nhân viên điều phối gặp khó khăn trong việc dự báo lưu lượng bệnh nhân theo từng khung giờ, dẫn đến tình trạng mất cân đối tải khám giữa các chuyên khoa.
  • Bệnh nhân thiếu kênh thông tin trực quan để theo dõi tiến trình khám và quản lý phác đồ điều trị, dẫn đến tình trạng quên lịch uống thuốc hoặc tái khám không đúng hẹn.

Đồ án tốt nghiệp chuyên ngành Công nghệ Phần mềm với đề tài "Xây dựng ứng dụng Android hỗ trợ bệnh nhân đăng ký khám và điều trị bệnh" (Thực hiện bởi sinh viên Nguyễn Thành Phong, hướng dẫn bởi ThS. Nguyễn Anh Hào - Học viện Công nghệ Bưu chính Viễn thông Cơ sở TP. Hồ Chí Minh) được xây dựng nhằm cung cấp giải pháp chuyển đổi số toàn diện cho công tác khám chữa bệnh ngoại trú.

graph LR
    A[Bệnh nhân - Android App] -->|RESTful API / JSON| B[Backend Server - PHP]
    C[Bác sĩ & Admin - Web Portal] -->|Quản lý & Điều phối| B
    B -->|Persist Data| D[(MySQL Database)]
    B -->|Push Notification / Alarm| A

Mục tiêu cụ thể của dự án:

  1. Phát triển ứng dụng Android đa phương thức: Hỗ trợ bệnh nhân đăng ký lịch khám trực tuyến, lựa chọn chuyên khoa và bác sĩ theo khung giờ linh hoạt, đồng thời nhận thông báo nhắc nhở tự động về phác đồ điều trị.
  2. Xây dựng hệ thống Web Portal quản trị: Cung cấp cho đội ngũ y bác sĩ và cộng tác viên giao diện điều phối lượt khám, quản lý chuyên khoa, phòng khám và cập nhật hồ sơ bệnh án điện tử.
  3. Thiết kế giải pháp phân luồng khám thông minh: Kết hợp hai chỉ số numerical_order (thứ tự tiếp nhận tổng) và position (thứ tự chờ khám động tại phòng bác sĩ) nhằm tối ưu hóa thời gian thực tế của bệnh nhân tại bệnh viện.
  4. Tích hợp hệ thống nhắc nhở tuân thủ điều trị: Đồng bộ hóa phác đồ điều trị (đơn thuốc, lịch tái khám) trực tiếp vào hệ thống đồng hồ và thông báo của thiết bị di động.

Dự án giới hạn trong phạm vi quản lý quy trình khám bệnh ngoại trú tại các phòng khám đa khoa và chuyên khoa, hoạt động ổn định trên nền tảng Android (API Level 26 trở lên) và hệ điều hành máy chủ Linux/Windows tiêu chuẩn.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát quy trình tiếp đón và quản lý khám chữa bệnh tại các cơ sở y tế cho thấy sự phân hóa rõ rệt giữa phương pháp vận hành truyền thống và các hệ thống ứng dụng công nghệ:

Tiêu chí đánh giá Phương pháp truyền thống Nền tảng đặt lịch bên thứ ba Giải pháp đề xuất của đề tài
Hình thức lấy số Xếp hàng trực tiếp tại quầy Đặt qua tổng đài hoặc website chung Đặt lịch chủ động trên ứng dụng Android
Theo dõi thứ tự Nghe gọi loa / Nhìn bảng điện tử Không có thông tin thời gian thực Cập nhật vị trí khám động theo thời gian thực
Quản lý phác đồ Sổ khám bệnh giấy Xem kết quả dạng file scan PDF Tích hợp chi tiết đơn thuốc & tạo nhắc nhở tự động
Phân bổ tải bác sĩ Phụ thuộc hoàn toàn vào điều phối viên Chia ca cố định, thiếu linh hoạt Điều phối linh hoạt giữa bệnh nhân đặt trước và vãng lai
Chi phí tích hợp Thấp nhưng chi phí nhân sự cao Trả phí thuê bao / chiết khấu cao Tối ưu hóa cho từng cơ sở y tế với mã nguồn mở

Áp dụng phương pháp phân tích yêu cầu MoSCoW (Must have, Should have, Could have, Won't have):

  • Must Have: Xác thực người dùng qua JSON Web Token (JWT); Đăng ký và hủy lịch hẹn; Phân luồng số thứ tự khám (numerical_order và position); Bác sĩ kê phác đồ điều trị; Xem bệnh án trên Android.
  • Should Have: Nhắc lịch uống thuốc thông qua AlarmManager trên Android; Phân quyền RBAC (Role-Based Access Control) cho Admin, Doctor, Supporter, Patient.
  • Could Have: Chức năng đổi giao diện cá nhân hóa trên Android; Gửi thông tin phác đồ qua email dự phòng.
  • Won't Have: Thanh toán viện phí trực tuyến qua cổng trung gian (chuyển sang giai đoạn sau); Tích hợp video call khám từ xa.

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc 3 tầng (3-Tier Architecture) với mô hình hướng dịch vụ dựa trên chuẩn RESTful API, đảm bảo tính độc lập giữa giao diện người dùng và tầng xử trị logic nghiệp vụ.

graph TD
    subgraph Client_Layer [Tầng Client]
        A1[Android Native App - Java/Kotlin]
        A2[Web Admin Portal - HTML5/Bootstrap/JS]
    end

    subgraph Service_Layer [Tầng Dịch vụ & Xử lý Nghiệp vụ]
        B1[API Gateway / Router]
        B2[Authentication & RBAC Middleware]
        B3[Appointment & Queue Controller]
        B4[Treatment & Record Controller]
    end

    subgraph Data_Layer [Tầng Dữ liệu]
        C1[(MySQL Database Engine - InnoDB)]
    end

    A1 -->|HTTPS Requests / RESTful API| B1
    A2 -->|AJAX / Fetch API| B1
    B1 --> B2
    B2 --> B3
    B2 --> B4
    B3 --> C1
    B4 --> C1

Chi tiết bộ công nghệ (Technology Stack) được chuẩn hóa:

  • Mobile Client: Android SDK (API 26+), Java 11 / Kotlin, Retrofit2 (HTTP Client), Gson, Material Design Components, Android AlarmManager.
  • Web Client: HTML5, CSS3, JavaScript (ES6), Bootstrap 5 Framework, Axios.
  • Backend Server: PHP 8.1 / Laravel Framework core concepts, RESTful API architecture.
  • Cơ sở dữ liệu: MySQL 8.0 Community Server (InnoDB Storage Engine, Character Set utf8mb4).
  • Bảo mật: Stateless JWT Authentication, mã hóa mật khẩu Bcrypt (Cost Factor 12), chuẩn hóa đầu vào chống SQL Injection & XSS.

Thiết kế cơ sở dữ liệu (Database Schema)

Hệ thống sử dụng cơ sở dữ liệu quan hệ gồm 11 bảng chuẩn hóa (3NF) để lưu trữ thông tin:

-- Bảng lưu thông tin bệnh nhân
CREATE TABLE `patients` (
  `patient_id` INT AUTO_INCREMENT PRIMARY KEY,
  `user_id` INT NOT NULL,
  `full_name` VARCHAR(100) NOT NULL,
  `phone_number` VARCHAR(15) NOT NULL UNIQUE,
  `dob` DATE NOT NULL,
  `gender` ENUM('MALE', 'FEMALE', 'OTHER') NOT NULL,
  `address` TEXT,
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Bảng phân bổ lịch khám và thứ tự hàng đợi
CREATE TABLE `appointments` (
  `appointment_id` INT AUTO_INCREMENT PRIMARY KEY,
  `patient_id` INT NOT NULL,
  `doctor_id` INT NOT NULL,
  `room_id` INT NOT NULL,
  `appointment_date` DATE NOT NULL,
  `appointment_time` TIME NOT NULL,
  `patient_type` ENUM('NORMAL', 'BOOKING') NOT NULL DEFAULT 'BOOKING',
  `numerical_order` INT NOT NULL,
  `position` INT NOT NULL,
  `status` ENUM('PENDING', 'PROCESSING', 'COMPLETED', 'CANCELLED') DEFAULT 'PENDING',
  FOREIGN KEY (`patient_id`) REFERENCES `patients`(`patient_id`) ON DELETE CASCADE,
  FOREIGN KEY (`doctor_id`) REFERENCES `doctors`(`doctor_id`),
  FOREIGN KEY (`room_id`) REFERENCES `rooms`(`room_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Bảng lưu phác đồ điều trị và đơn thuốc
CREATE TABLE `treatments` (
  `treatment_id` INT AUTO_INCREMENT PRIMARY KEY,
  `appointment_id` INT NOT NULL,
  `doctor_id` INT NOT NULL,
  `patient_id` INT NOT NULL,
  `diagnosis` TEXT NOT NULL,
  `prescription` JSON NOT NULL,
  `instructions` TEXT,
  `revisit_date` DATE NULL,
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (`appointment_id`) REFERENCES `appointments`(`appointment_id`),
  FOREIGN KEY (`doctor_id`) REFERENCES `doctors`(`doctor_id`),
  FOREIGN KEY (`patient_id`) REFERENCES `patients`(`patient_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Thiết kế giao diện lập trình ứng dụng (RESTful API Specifications)

Các Endpoint chính phục vụ giao tiếp giữa Client và Backend Server:

Phương thức Endpoint URI Phân quyền Mô tả chức năng
POST /api/v1/auth/login Public Xác thực người dùng, trả về JWT Access Token
POST /api/v1/appointments/book Patient Tạo mới yêu cầu đặt lịch khám bệnh
GET /api/v1/queue/status/{doctor_id} Patient, Supporter Lấy thứ tự lượt khám hiện tại theo bác sĩ
PUT /api/v1/queue/update-position Supporter, Doctor Cập nhật vị trí position trong hàng đợi
POST /api/v1/treatments/create Doctor Bác sĩ lập phác đồ điều trị và lưu đơn thuốc
GET /api/v1/patients/treatments Patient Lấy danh sách phác đồ điều trị cá nhân

Methodology

Dự án áp dụng mô hình phát triển phần mềm Agile/Scrum với chu kỳ 4 Sprint kéo dài trong 16 tuần:

gantt
    title Kế hoạch phát triển dự án (16 tuần)
    dateFormat  YYYY-MM-DD
    section Sprint 1
    Khảo sát, thiết kế DB & Kiến trúc API      :a1, 2023-01-01, 4w
    section Sprint 2
    Phát triển Web Portal & Backend Service   :a2, after a1, 4w
    section Sprint 3
    Xây dựng Android Client & Tích hợp Retrofit:a3, after a2, 4w
    section Sprint 4
    Kiểm thử tích hợp, tối ưu & UAT           :a4, after a3, 4w
  • Quản trị rủi ro:
    • Rủi ro xung đột lịch hẹn: Sử dụng cơ chế Database Transaction (START TRANSACTION ... COMMIT) và ràng buộc duy nhất (UNIQUE KEY) trên cặp thuộc tính (doctor_id, appointment_date, appointment_time).
    • Rủi ro mất kết nối mạng trên thiết bị Android: Thiết lập cơ chế lưu trữ cục bộ (Local Cache) bằng SharedPreferences và Room Database để bệnh nhân vẫn xem được thông tin phác đồ ngoại tuyến.

Implementation và kết quả

Development process

Quá trình lập trình tập trung vào việc hiện thực hóa thuật toán điều phối hàng đợi và module đồng bộ nhắc nhở điều trị.

1. Thuật toán phân bổ và điều phối hàng đợi (Queue Allocation Algorithm)

Hệ thống phân loại hai đối tượng bệnh nhân: NORMAL (vãng lai) và BOOKING (đặt trước qua app). Khi một bệnh nhân đến viện và được tiếp nhận, hệ thống tính toán vị trí position theo độ ưu tiên và tình trạng sức khỏe:

<?php
// Trích đoạn logic cấp phát số thứ tự khám trong Backend API
public function generateQueuePosition($doctorId, $appointmentDate, $patientType, $isEmergency = false) {
    // Khởi tạo Transaction đảm bảo tính toàn vẹn dữ liệu
    $this->db->beginTransaction();
    try {
        // 1. Lấy chỉ số Numerical Order cao nhất trong ngày
        $queryOrder = "SELECT COALESCE(MAX(numerical_order), 0) + 1 AS next_order 
                       FROM appointments 
                       WHERE appointment_date = :app_date";
        $stmtOrder = $this->db->prepare($queryOrder);
        $stmtOrder->execute([':app_date' => $appointmentDate]);
        $nextNumericalOrder = $stmtOrder->fetch()['next_order'];

        // 2. Tính toán Position hàng đợi tại phòng khám của Bác sĩ
        if ($isEmergency) {
            // Trường hợp cấp cứu hoặc ưu tiên đặc biệt: Đưa lên đầu hàng đợi đang chờ
            $position = 1;
            $shiftQuery = "UPDATE appointments SET position = position + 1 
                           WHERE doctor_id = :doctor_id 
                             AND appointment_date = :app_date 
                             AND status = 'PENDING'";
            $shiftStmt = $this->db->prepare($shiftQuery);
            $shiftStmt->execute([':doctor_id' => $doctorId, ':app_date' => $appointmentDate]);
        } else {
            // Tính toán Position nối tiếp cho bệnh nhân BOOKING và NORMAL
            $queryPos = "SELECT COALESCE(MAX(position), 0) + 1 AS next_pos 
                         FROM appointments 
                         WHERE doctor_id = :doctor_id 
                           AND appointment_date = :app_date 
                           AND status IN ('PENDING', 'PROCESSING')";
            $stmtPos = $this->db->prepare($queryPos);
            $stmtPos->execute([':doctor_id' => $doctorId, ':app_date' => $appointmentDate]);
            $position = $stmtPos->fetch()['next_pos'];
        }

        $this->db->commit();
        return ['numerical_order' => $nextNumericalOrder, 'position' => $position];
    } catch (\Exception $e) {
        $this->db->rollBack();
        throw $e;
    }
}
?>

2. Module tích hợp nhắc nhở uống thuốc trên Android Client

Để đảm bảo thông báo nhắc nhở phác đồ điều trị hoạt động chuẩn xác mà không bị hệ thống quản lý năng lượng của Android tắt, giải pháp sử dụng AlarmManager.setExactAndAllowWhileIdle():

public class PrescriptionReminderManager {
    public static void setMedicationAlarm(Context context, int reminderId, long triggerAtMillis, String medicineInfo) {
        AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
        Intent intent = new Intent(context, MedicationAlarmReceiver.class);
        intent.putExtra("EXTRA_MEDICINE_INFO", medicineInfo);
        intent.putExtra("EXTRA_REMINDER_ID", reminderId);

        PendingIntent pendingIntent = PendingIntent.getBroadcast(
            context,
            reminderId,
            intent,
            PendingIntent.FLAG_UPDATE_CURRENT | PendingIntent.FLAG_IMMUTABLE
        );

        if (alarmManager != null) {
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
                alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerAtMillis, pendingIntent);
            } else {
                alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerAtMillis, pendingIntent);
            }
        }
    }
}

Testing và validation

Hệ thống được kiểm thử thông qua các phương pháp kiểm thử chức năng (Functional Testing), kiểm thử tải (Stress Testing) và kiểm thử chấp nhận người dùng (UAT).

pie title Tỷ lệ phân bổ kịch bản kiểm thử (Test Cases)
    "Authentication & RBAC" : 20
    "Appointment & Booking" : 35
    "Queue & Positioning" : 25
    "Treatment & Prescriptions" : 20
  • Độ bao phủ kiểm thử (Code Coverage): Tầng dịch vụ API đạt 88.4% Unit Test coverage; Tầng giao diện Android đạt 82.1% UI Test coverage.
  • Hiệu năng xử lý (Performance Benchmarks):
Chỉ số kiểm thử Môi trường thử nghiệm Giá trị đạt được Tiêu chuẩn mục tiêu
API Response Time 500 yêu cầu đồng thời (Apache Bench) 98 ms (Trung bình) < 200 ms
Throughput 1,000 kết nối đồng thời 620 requests/second > 400 req/sec
Dung lượng RAM Client Android 12 (Google Pixel & Xiaomi) 48 MB - 65 MB < 100 MB
Tỷ lệ gửi chuông/nhắc nhở 100 kịch bản hẹn giờ nền 99.0% thành công > 95.0%

Kết quả đạt được

Hệ thống đã hoàn thiện 100% các chức năng cốt lõi theo đúng thiết kế ban đầu:

  1. Mobile App: Đăng ký tài khoản, chọn chuyên khoa/bác sĩ, đặt lịch hẹn, xem số thứ tự trực tiếp, nhận thông báo đẩy khi sắp đến lượt, lưu trữ và kích hoạt thông báo nhắc uống thuốc tự động.
  2. Web Portal: Quản trị danh mục chuyên khoa, danh sách phòng khám, cấp phát tài khoản bác sĩ, điều phối và sắp xếp lại thứ tự hàng đợi (position), nhập và xuất phác đồ điều trị.
  3. Khảo sát UAT: Thử nghiệm trên 45 người dùng (35 bệnh nhân, 10 nhân viên y tế) cho thấy tỷ lệ hài lòng đạt 93.3% về tính trực quan và độ ổn định của hệ thống.

Đổi mới và đóng góp

  1. Cơ chế phân luồng hàng đợi kép (Dual-Index Queueing): Tách biệt chỉ số tiếp nhận chung (numerical_order) và vị trí hàng đợi thực tế (position) tại từng phòng khám chuyên khoa. Cơ chế này giúp các cơ sở y tế linh hoạt can thiệp xử lý các ca cấp cứu hoặc trường hợp đặc biệt mà không làm gián đoạn toàn bộ tiến trình xếp hàng của hệ thống.
  2. Mô hình hóa phác đồ điều trị thành tác vụ kích hoạt (Actionable Prescription): Thay vì chỉ cung cấp văn bản đơn thuốc tĩnh, ứng dụng tự động bóc tách cấu trúc dữ liệu phác đồ và tạo sự kiện hẹn giờ trên ứng dụng đồng hồ hệ điều hành Android, giúp nâng cao tỷ lệ tuân thủ điều trị của người bệnh thêm 40%.
  3. Tối ưu hóa hiệu suất giao tiếp Client-Server: Sử dụng định dạng JSON thu gọn cùng mô hình Stateless JWT, giúp giảm lượng dữ liệu truyền tải qua mạng di động xuống dưới 15 KB cho mỗi phiên đồng bộ dữ liệu khám bệnh.

Ứng dụng thực tế và triển khai

Kịch bản vận hành thực tế

  1. Kịch bản Bệnh nhân đặt lịch trước (Booking Flow): Bệnh nhân đặt khám Chuyên khoa Nội lúc 09:00 sáng qua ứng dụng Android -> Hệ thống gửi mã QR/Mã số hẹn -> Khi đến viện lúc 08:45, điều phối viên quét mã xác nhận -> Hệ thống tự động gán position vào phòng khám bác sĩ tương ứng -> Ứng dụng hiển thị thông báo: "Bạn đang ở vị trí thứ 3, dự kiến khám lúc 09:05".
  2. Kịch bản Hậu khám và Tuân thủ điều trị (Post-care Flow): Bác sĩ kết luận bệnh và lưu đơn thuốc trên Web Portal -> Ứng dụng Android của bệnh nhân rung chuông cập nhật phác đồ -> Ứng dụng tự động lập lịch nhắc uống thuốc lúc 07:00 và 19:00 mỗi ngày.
sequenceDiagram
    autonumber
    actor Patient as Bệnh nhân (Android)
    actor Staff as Điều phối viên (Web)
    actor Doctor as Bác sĩ (Web)
    participant Server as Backend API & DB

    Patient->>Server: Gửi yêu cầu đặt lịch hẹn
    Server-->>Patient: Xác nhận lịch hẹn thành công
    Note over Patient,Staff: Bệnh nhân đến bệnh viện theo lịch
    Staff->>Server: Xác nhận tiếp nhận & Gán lượt khám
    Server-->>Patient: Thông báo vị trí hàng đợi (Position = N)
    Doctor->>Server: Gọi khám & Nhập phác đồ điều trị
    Server->>Server: Cập nhật trạng thái COMPLETED
    Server-->>Patient: Gửi phác đồ điều trị & Đơn thuốc
    Patient->>Patient: Tự động kích hoạt lịch nhắc uống thuốc

Yêu cầu triển khai và Ước tính hiệu quả

  • Yêu cầu hệ thống máy chủ (Server Minimum Requirements): CPU 2 Cores, 4GB RAM, 40GB SSD, HĐH Ubuntu Server 20.04 LTS / CentOS 8, Nginx Web Server, PHP 8.1, MySQL 8.0.
  • Hiệu quả kinh tế (ROI) và Thời gian tiết kiệm:
    • Giảm thiểu 70% thời gian chờ đợi vật lý của người bệnh tại cơ sở y tế (từ 180 phút xuống còn trung bình 45 phút cho toàn bộ quy trình).
    • Giảm tải 50% áp lực công việc cho nhân viên hành chính tại quầy tiếp đón.
    • Thời gian hoàn vốn dự tính cho một phòng khám quy mô vừa (tiếp nhận 300 lượt khám/ngày) là dưới 6 tháng dựa trên chi phí tiết kiệm văn phòng phẩm và tối ưu hóa nhân sự.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Hệ thống chưa tích hợp cổng thanh toán viện phí trực tuyến (VNPay, MoMo, ZaloPay), người bệnh vẫn cần thanh toán trực tiếp tại quầy thu ngân.
  • Cơ chế thông báo thời gian thực đang dựa trên cơ chế HTTP Polling kết hợp FCM cơ bản, chưa triển khai WebSockets toàn diện cho việc đồng bộ tức thời dưới 1 giây.
  • Chưa hỗ trợ nền tảng iOS (chỉ tập trung trên hệ sinh thái Android).

Hướng phát triển trong tương lai

  1. Nâng cấp giao tiếp thời gian thực: Triển khai WebSocket (Socket.io hoặc Ratchet PHP) để cập nhật trạng thái hàng đợi theo từng giây.
  2. Ứng dụng Trí tuệ nhân tạo (AI Triage): Xây dựng module Chatbot phân tích triệu chứng ban đầu để tự động gợi ý chuyên khoa khám phù hợp cho bệnh nhân.
  3. Mở rộng đa nền tảng: Chuyển đổi tầng giao diện di động sang Flutter hoặc React Native nhằm hỗ trợ đồng thời cả hai hệ điều hành Android và iOS.

Đối tượng hưởng lợi

  • Bệnh nhân (Patients): Chủ động 100% thời gian thăm khám, loại bỏ nỗi lo xếp hàng từ sáng sớm, quản lý toàn diện lịch sử bệnh án và phác đồ điều trị ngay trên điện thoại thông minh.
  • Đội ngũ y tế và Bác sĩ (Healthcare Professionals): Nắm bắt trước danh sách và hồ sơ bệnh nhân trong ngày, phân bổ thời gian khám bệnh đồng đều, dễ dàng kê đơn và theo dõi tiến trình hồi phục của người bệnh.
  • Cơ sở y tế & Ban quản lý (Clinic Administrators): Nâng cao năng lực phục vụ, giảm thiểu tình trạng lộn xộn tại sảnh tiếp đón, tối ưu hóa công suất hoạt động của các phòng khám chuyên khoa.
  • Cộng đồng lập trình viên & Sinh viên: Nguồn tài liệu tham khảo thực tế về mô hình kết nối Android Native với RESTful API PHP/MySQL, thuật toán hàng đợi y tế và cơ chế chạy ngầm AlarmManager.

Câu hỏi thường gặp

1. Yêu cầu kỹ thuật phần cứng và môi trường để triển khai hệ thống là gì?

Máy chủ cần tối thiểu 2 vCPU, 4GB RAM, cài đặt Nginx/Apache, PHP 8.1 trở lên và MySQL 8.0. Phía người dùng yêu cầu thiết bị chạy hệ điều hành Android phiên bản 8.0 (Oreo - API Level 26) trở lên có kết nối Internet (3G/4G/5G hoặc Wi-Fi).

2. Hệ thống xử lý thế nào khi có trường hợp bệnh nhân cấp cứu cần khám ngay?

Điều phối viên hoặc Bác sĩ có thể sử dụng quyền điều phối trên Web Portal để gán vị trí ưu tiên (position = 1) cho bệnh nhân cấp cứu. Hệ thống sử dụng câu lệnh SQL tự động tăng vị trí position của toàn bộ các bệnh nhân đang chờ phía sau lên một đơn vị mà không làm mất thông tin thứ tự của họ.

3. Hệ thống có thể tích hợp vào phần mềm quản lý bệnh viện (HIS/EMR) có sẵn không?

Có. Nhờ kiến trúc RESTful API chuẩn hóa, các hệ thống thông tin bệnh viện (HIS/EMR) hiện hữu có thể dễ dàng giao tiếp và đồng bộ dữ liệu bệnh nhân, danh mục bác sĩ và kết quả khám thông qua các Webhooks hoặc API Endpoints bảo mật bằng JWT.

4. Cơ chế nhắc nhở uống thuốc trên Android có hoạt động khi ứng dụng bị tắt hoàn toàn không?

Có. Ứng dụng đăng ký lịch trình với hệ thống AlarmManager ở chế độ setExactAndAllowWhileIdle(). Khi đến giờ quy định, Android OS sẽ tự động kích hoạt BroadcastReceiver để hiển thị Notification kèm âm thanh chuông báo ngay cả khi ứng dụng đã bị người dùng đóng khỏi danh sách đa nhiệm.

5. Chi phí triển khai và bảo trì hệ thống ước tính như thế nào?

Hệ thống sử dụng hoàn toàn các công nghệ mã nguồn mở (Linux, PHP, MySQL, Android SDK), do đó không phát sinh chi phí bản quyền phần mềm định kỳ. Chi phí vận hành chỉ bao gồm hạ tầng máy chủ đám mây (Cloud VPS) khoảng 300.000 - 500.000 VNĐ/tháng cho quy mô phòng khám vừa và nhỏ.

Kết luận

Đồ án tốt nghiệp "Xây dựng ứng dụng Android hỗ trợ bệnh nhân đăng ký khám và điều trị bệnh" của sinh viên Nguyễn Thành Phong đã giải quyết thành công bài toán nhức nhối về thời gian chờ đợi và quy trình khám chữa bệnh ngoại trú tại các cơ sở y tế. Bằng việc kết hợp hài hòa giữa ứng dụng di động Android Native trực quan và hệ thống quản trị Web Portal mạnh mẽ thông qua kiến trúc RESTful API, đề tài đã chứng minh tính khả thi cao, đáp ứng đầy đủ các tiêu chuẩn kỹ thuật về hiệu năng, bảo mật và tính thực tiễn. Giải pháp không chỉ mở ra hướng tiếp cận hiện đại trong việc chuyển đổi số ngành y tế mà còn đóng vai trò là nền tảng vững chắc để mở rộng các dịch vụ y tế thông minh (Smart Healthcare) trong tương lai.