Giới thiệu dự án

Trong bối cảnh chuyển đổi số ngành y tế đang diễn ra mạnh mẽ, việc tối ưu hóa quy trình tiếp đón, khám chữa bệnh và quản trị vận hành tại các cơ sở y tế tư nhân trở thành yêu cầu cấp thiết. Theo các khảo sát thực tế tại các phòng khám vừa và nhỏ, thời gian chờ đợi trung bình của bệnh nhân thường dao động từ 45 đến 60 phút, trong đó hơn 60% thời gian tiêu tốn vào các khâu thủ công như đăng ký thông tin, tra cứu hồ sơ giấy và thanh toán viện phí. Tỷ lệ sai sót thông tin trong hồ sơ bệnh án truyền thống ghi nhận ở mức 10-15%, gây ảnh hưởng trực tiếp đến chất lượng chẩn đoán và hiệu suất làm việc của đội ngũ y bác sĩ.

Đồ án "Phân Tích Thiết Kế Hệ Thống Phòng Khám" do nhóm nghiên cứu sinh viên (Võ Đình Trường, Võ Văn Thần Thái, Phạm Quốc Huy) dưới sự hướng dẫn của ThS. Nguyễn Tấn Khoa tại Khoa Công nghệ Thông tin – Trường Đại học Ngoại ngữ - Tin học TP.HCM (HUFLIT) thực hiện, tập trung giải quyết triệt để bài toán tin học hóa quy trình quản lý phòng khám đa khoa. Dự án thiết lập nền tảng phân tích thiết kế phần mềm hướng đối tượng chuẩn mực, chuẩn hóa luồng nghiệp vụ từ tiếp nhận bệnh nhân, điều phối lịch hẹn, thực hiện cận lâm sàng, kê đơn thuốc cho đến quản trị nhân sự và tài chính.

+-----------------------------------------------------------------------------------+
|                        MÔ HÌNH TỔNG QUAN HỆ THỐNG PHÒNG KHÁM                      |
+-----------------------------------------------------------------------------------+
|  [Khách hàng / Bệnh nhân] ---> Đăng ký / Đổi lịch / Xem hồ sơ / Đánh giá         |
|  [Nhân viên tư vấn]       ---> Tiếp nhận đa kênh / Điều phối lịch hẹn             |
|  [Bác sĩ]                 ---> Khám bệnh / Chỉ định CLS / Kê đơn thuốc            |
|  [Kế toán]                ---> Thu viện phí / Quản lý lương / Xuất hóa đơn        |
|  [Quản trị viên (Admin)]  ---> Quản lý người dùng / Danh mục / Phân quyền RBAC    |
+-----------------------------------------------------------------------------------+

Mục tiêu dự án

  1. Chuẩn hóa quy trình nghiệp vụ: Xây dựng ma trận phân quyền Role-Based Access Control (RBAC) cho 5 tác nhân chính (Admin, Bác sĩ, Khách hàng, Kế toán, Nhân viên tư vấn).
  2. Thiết kế hệ thống Use Case toàn diện: Đặc tả chi tiết 20 Use Cases (từ UC01 đến UC20) bao gồm luồng chính (Standard Flow), luồng thay thế (Alternative Flow) và kịch bản lỗi (Exception Flow).
  3. Mô hình hóa hành vi và cấu trúc: Xây dựng hoàn chỉnh hệ thống sơ đồ UML 2.5 (Use Case Diagram, Sequence Diagram, Activity Diagram, Class Diagram).
  4. Trực quan hóa trải nghiệm người dùng: Thiết kế nguyên mẫu giao diện (UI Mockup) bám sát trải nghiệm thực tế của từng nhóm người dùng.

Phạm vi và giới hạn

  • Phạm vi: Tập trung vào giai đoạn phân tích và thiết kế phần mềm (Analysis and Design Phase) theo chuẩn công nghệ phần mềm hiện đại, áp dụng cho các cơ sở phòng khám quy mô vừa và nhỏ (từ 5 đến 30 bàn khám).
  • Giới hạn: Đồ án chưa triển khai tích hợp giao thức truyền thông hình ảnh y tế PACS/DICOM phức tạp và chưa liên thông cổng bảo hiểm y tế quốc gia (BHYT).

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 quản lý truyền thống cho thấy nhiều điểm nghẽn nghiêm trọng: sự thiếu đồng bộ dữ liệu giữa bộ phận lễ tân, phòng khám và thu ngân dẫn đến tình trạng chồng chéo lịch khám, thất lạc lịch sử điều trị và kéo dài thời gian đối soát công nợ cuối ngày.

Tiêu chí Quản lý truyền thống (Sổ sách / Excel) Phần mềm quản trị phòng khám đề xuất
Tốc độ tiếp nhận 5 - 10 phút/bệnh nhân 30 - 60 giây (quét mã / tra cứu trực tuyến)
Quản lý lịch hẹn Dễ trùng lặp (Double-booking), khó theo dõi Tự động kiểm tra xung đột thời gian thực
Tra cứu bệnh án Tra cứu thủ công, nguy cơ mất mát dữ liệu Truy xuất lịch sử điều trị chỉ với 1-click
Bảo mật & Phân quyền Thấp, dễ rò rỉ dữ liệu y tế nhạy cảm Phân quyền RBAC nghiêm ngặt theo vai trò
Đối soát tài chính Tốn 2 - 3 giờ đối soát sổ sách thủ công Tự động tổng hợp doanh thu và xuất hóa đơn

So sánh với các giải pháp trên thị trường

                      SO SÁNH CÁC GIẢI PHÁP HIỆN HÀNH
  +----------------------+--------------------+---------------------+
  |   eHospital (FPT)    |    Medpro / VNPT   |   Hệ thống đề xuất  |
  +----------------------+--------------------+---------------------+
  | Phù hợp BV hạng I-II | Đặt lịch trực tuyến| Tối ưu PK đa khoa   |
  | Chi phí triển khai cao| Nghiệp vụ hẹp      | Chi phí hợp lý      |
  | Triển khai phức tạp  | Phụ thuộc nền tảng | Đầy đủ luồng nội bộ |
  +----------------------+--------------------+---------------------+

Phân loại yêu cầu theo mô hình MoSCoW

  • Must-have (Bắt buộc): Đăng ký lịch khám (UC08), Quản lý lịch làm việc bác sĩ (UC02), Xem lịch sử khám bệnh (UC06), Thu tiền (UC19), Xuất hóa đơn (UC20), Quản trị người dùng & phân quyền (UC15 - UC18).
  • Should-have (Nên có): Thay đổi/Hủy lịch hẹn (UC04, UC05, UC11, UC13), Yêu cầu chỉ định cận lâm sàng (UC07), Quản lý doanh thu phòng khám.
  • Could-have (Có thể có): Đánh giá chất lượng dịch vụ (UC12), Gọi đường dây nóng hỗ trợ trực tiếp (UC14).
  • Won't-have (Chưa thực hiện): Hệ thống hội chẩn từ xa Telemedicine thời gian thực, AI phân tích hình ảnh X-quang tự động.

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc 3 tầng (Three-Tier Architecture), tách biệt giữa tầng trình diễn (Presentation Layer), tầng xử lý nghiệp vụ (Business Logic Layer) và tầng truy cập dữ liệu (Data Access Layer).

+---------------------------------------------------------------------------+
|                          KIẾN TRÚC HỆ THỐNG 3 TẦNG                        |
+---------------------------------------------------------------------------+
| [TẦNG CLIENT / PRESENTATION]                                             |
|   - Web App / Mobile Mockup (React 18.2 / TailwindCSS)                    |
|   - Bác sĩ Portal | Bệnh nhân Portal | Kế toán & Admin Dashboard          |
+---------------------------------------------------------------------------+
                                   | (HTTPS / RESTful APIs / JSON)
+---------------------------------------------------------------------------+
| [TẦNG NGHIỆP VỤ / BUSINESS LOGIC]                                         |
|   - API Gateway / Auth Service (JWT Authentication & RBAC Middleware)     |
|   - Appointment Management Module (Thuật toán kiểm tra lịch trống)        |
|   - Clinical & EMR Module (Quản lý hồ sơ bệnh án & Chỉ định xét nghiệm)   |
|   - Billing & Finance Module (Tính toán chi phí & Xuất hóa đơn điện tử)   |
+---------------------------------------------------------------------------+
                                   | (ORM / Connection Pooling)
+---------------------------------------------------------------------------+
| [TẦNG CƠ SỞ DỮ LIỆU / DATA LAYER]                                         |
|   - Relational Database (MySQL 8.0 / PostgreSQL 15)                       |
|   - In-memory Caching (Redis 7.0 - Quản lý Session & Caching lịch khám)   |
+---------------------------------------------------------------------------+

Ma trận Phân quyền Actor - Use Case

Mã Use Case Tên Use Case Bác sĩ Khách hàng Admin Kế toán NV Tư vấn
UC01 Cập nhật thông tin cá nhân X X X X X
UC02 Cập nhật lịch làm việc X X
UC03 Xem thông tin bệnh nhân X X X
UC04 Thay đổi lịch hẹn X X X
UC05 Hủy lịch hẹn X X X
UC06 Xem lịch sử khám bệnh X X
UC07 Yêu cầu sử dụng dịch vụ (CLS) X
UC08 Đăng ký lịch khám X X
UC09 Xem thông tin phòng khám X
UC10 Tạo tài khoản X
UC11 Hủy lịch hẹn (Bệnh nhân) X
UC12 Đánh giá dịch vụ X
UC13 Thay đổi lịch khám (Bệnh nhân) X
UC14 Gọi đường dây nóng X
UC15 Quản lý thông tin nhân viên X
UC16 Quản lý bác sĩ X
UC17 Quản lý bệnh nhân X
UC18 Quản lý tài khoản X
UC19 Thu tiền X
UC20 Xuất hóa đơn X

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

Cấu trúc quan hệ thực thể ánh xạ từ Class Diagram quản lý phòng khám được hiện thực hóa qua lược đồ dữ liệu chuẩn:

-- Bảng Người Dùng & Tài Khoản (Phân quyền RBAC)
CREATE TABLE Users (
    user_id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    role ENUM('ADMIN', 'DOCTOR', 'PATIENT', 'ACCOUNTANT', 'CONSULTANT') NOT NULL,
    full_name VARCHAR(100) NOT NULL,
    phone VARCHAR(15) UNIQUE NOT NULL,
    email VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Bảng Hồ Sơ Bác Sĩ
CREATE TABLE Doctors (
    doctor_id INT PRIMARY KEY,
    specialty VARCHAR(100) NOT NULL,
    room_number VARCHAR(20) NOT NULL,
    FOREIGN KEY (doctor_id) REFERENCES Users(user_id) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Bảng Lịch Khám (Appointments)
CREATE TABLE Appointments (
    appointment_id INT AUTO_INCREMENT PRIMARY KEY,
    patient_id INT NOT NULL,
    doctor_id INT NOT NULL,
    appointment_date DATE NOT NULL,
    start_time TIME NOT NULL,
    end_time TIME NOT NULL,
    status ENUM('PENDING', 'CONFIRMED', 'COMPLETED', 'CANCELLED') DEFAULT 'PENDING',
    reason TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (patient_id) REFERENCES Users(user_id),
    FOREIGN KEY (doctor_id) REFERENCES Doctors(doctor_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- Bảng Hóa Đơn & Thanh Toán
CREATE TABLE Invoices (
    invoice_id INT AUTO_INCREMENT PRIMARY KEY,
    appointment_id INT UNIQUE NOT NULL,
    accountant_id INT NOT NULL,
    total_amount DECIMAL(12, 2) NOT NULL,
    payment_method ENUM('CASH', 'CREDIT_CARD', 'BANK_TRANSFER') NOT NULL,
    payment_status ENUM('PAID', 'UNPAID') DEFAULT 'PAID',
    issued_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (appointment_id) REFERENCES Appointments(appointment_id),
    FOREIGN KEY (accountant_id) REFERENCES Users(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

Thiết kế RESTful API Specifications

### API Đặt lịch khám mới (UC08)
POST /api/v1/appointments
Content-Type: application/json
Authorization: Bearer <JWT_TOKEN>

{
  "patient_id": 1042,
  "doctor_id": 15,
  "appointment_date": "2026-09-15",
  "start_time": "09:00:00",
  "reason": "Khám tổng quát định kỳ"
}

### Response: 201 Created
{
  "status": "success",
  "code": 201,
  "data": {
    "appointment_id": 5081,
    "status": "CONFIRMED",
    "message": "Đăng ký lịch khám thành công."
  }
}

### API Lấy lịch sử bệnh án (UC06)
GET /api/v1/patients/1042/medical-history
Authorization: Bearer <JWT_TOKEN>

### Response: 200 OK
{
  "patient_id": 1042,
  "records": [
    {
      "appointment_id": 4820,
      "date": "2026-03-10",
      "doctor_name": "BS. Nguyễn Văn A",
      "diagnosis": "Viêm họng cấp",
      "services": ["Nội soi tai mũi họng"],
      "prescription": ["Amoxicillin 500mg", "Paracetamol 500mg"]
    }
  ]
}

Phương pháp nghiên cứu và phát triển (Methodology)

Dự án áp dụng mô hình phân tích thiết kế hướng đối tượng (OOAD) kết hợp quy trình phát triển lặp Scrum Framework:

  • Giai đoạn 1 (Tuần 1 - 2): Thu thập và phân tích yêu cầu nghiệp vụ thực tế từ phòng khám.
  • Giai đoạn 2 (Tuần 3 - 5): Xây dựng sơ đồ Use Case và ma trận phân quyền Actor - Use Case.
  • Giai đoạn 3 (Tuần 6 - 9): Đặc tả chi tiết 20 Use Cases; thiết kế Sequence Diagrams và Activity Diagrams cho từng quy trình.
  • Giai đoạn 4 (Tuần 10 - 12): Tổng hợp Class Diagram quản lý phòng khám và thiết kế Mockup giao diện chi tiết.

Implementation và kết quả

Development Process & Thuật toán cốt lõi

Trong quá trình phân tích thiết kế hệ thống, một trong những thuật toán cốt lõi là Thuật toán kiểm tra và giải quyết xung đột lịch hẹn (Conflict Resolution Algorithm) nhằm đảm bảo không xảy ra hiện tượng đặt trùng ca khám:

def check_appointment_availability(doctor_id, requested_date, start_time, duration_minutes=30):
    """
    Kiểm tra tính khả dụng của khung giờ khám bác sĩ.
    Độ phức tạp thời gian: O(log N) với Index (doctor_id, appointment_date)
    """
    end_time = calculate_end_time(start_time, duration_minutes)
    
    # 1. Kiểm tra lịch làm việc của bác sĩ trong ngày
    work_schedule = get_doctor_schedule(doctor_id, requested_date)
    if not is_within_working_hours(work_schedule, start_time, end_time):
        return {"available": False, "error": "Khung giờ nằm ngoài lịch làm việc của Bác sĩ"}
    
    # 2. Truy vấn các lịch khám đã được xác nhận (CONFIRMED/PENDING)
    conflicting_appointments = db.query(Appointments).filter(
        Appointments.doctor_id == doctor_id,
        Appointments.appointment_date == requested_date,
        Appointments.status.in_(['CONFIRMED', 'PENDING']),
        Appointments.start_time < end_time,
        Appointments.end_time > start_time
    ).all()
    
    if conflicting_appointments:
        return {"available": False, "error": "Bác sĩ đã có lịch hẹn trong khoảng thời gian này"}
        
    return {"available": True, "slot": {"start": start_time, "end": end_time}}

Kiểm thử và Đánh giá thiết kế (Validation & Verification)

Nhóm đã xây dựng ma trận kiểm thử chất lượng cho toàn bộ tài liệu đặc tả:

  • 100% Use Case Coverage: Tất cả 20 Use Case đều được kiểm tra tính đầy đủ về Trigger, Pre-conditions, Post-conditions và Exception handling.
  • Consistency Verification: Đối soát chéo giữa Use Case Diagram, Sequence Diagram và Class Diagram để đảm bảo không có thực thể "mồ côi" hoặc thông điệp không khớp phương thức.
+---------------------------------------------------------------------------+
|                     KẾT QUẢ ĐẠT ĐƯỢC CỦA ĐỒ ÁN                            |
+---------------------------------------------------------------------------+
|  [Hạng mục thiết kế]          | [Mục tiêu đề ra]   | [Kết quả thực tế]    |
+---------------------------------------------------------------------------+
|  Use Case Đặc tả chi tiết     | 20 Use Cases       | 20/20 Use Cases      |
|  Use Case Diagrams (Phân hệ)  | 5 Sơ đồ chính      | 5 Sơ đồ hoàn chỉnh   |
|  Sequence Diagrams            | >= 5 Sơ đồ tương tác| 6 Sơ đồ chi tiết     |
|  Activity Diagrams            | >= 8 Sơ đồ luồng   | 10 Sơ đồ luồng       |
|  Class Diagram                | 1 Mô hình dữ liệu  | 1 Class Diagram      |
|  UI Mockup Modules            | 2 Phân hệ chính    | Hoàn thành 100%      |
+---------------------------------------------------------------------------+

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

  1. Chuẩn hóa quy trình tiếp nhận đa kênh linh hoạt: Hệ thống cho phép đăng ký lịch khám song song qua hai kênh: Khách hàng chủ động thao tác trực tuyến (UC08) hoặc Nhân viên tư vấn điều phối trực tiếp (UC04, UC08). Thiết kế này giải quyết triệt để rào cản công nghệ đối với bệnh nhân lớn tuổi.
  2. Quy trình khép kín giữa Chẩn đoán và Cận lâm sàng: Thiết kế luồng Use Case UC07 (Yêu cầu sử dụng dịch vụ) cho phép Bác sĩ chỉ định trực tiếp các dịch vụ xét nghiệm, chẩn đoán hình ảnh trên phần mềm. Kết quả được số hóa và liên kết trực tiếp vào hồ sơ bệnh án (UC06), loại bỏ hoàn toàn việc vận chuyển phiếu chỉ định giấy.
  3. Mô hình hóa tài chính minh bạch: Phân hệ Kế toán (UC19 Thu tiền, UC20 Xuất hóa đơn) kết nối trực tiếp với kết quả khám và đơn thuốc, tự động tổng hợp chi phí chính xác tuyệt đối, ngăn ngừa thất thoát tài chính.

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

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

+-------------------------------------------------------------------------------+
|                       KỊCH BẢN KHÁM BỆNH VẬN HÀNH THỰC TẾ                     |
+-------------------------------------------------------------------------------+
| Bước 1: Bệnh nhân đăng ký lịch khám trực tuyến qua Web/Mobile (UC08).        |
| Bước 2: Hệ thống gửi thông báo xác nhận; Bác sĩ tiếp nhận danh sách (UC02).   |
| Bước 3: Bác sĩ tra cứu bệnh sử (UC06), khám và chỉ định xét nghiệm (UC07).    |
| Bước 4: Kế toán nhận dữ liệu chỉ định, thực hiện thu tiền & in hóa đơn (UC20).|
| Bước 5: Bác sĩ đọc kết quả xét nghiệm, kê đơn thuốc và hoàn tất ca khám.      |
| Bước 6: Bệnh nhân nhận đơn thuốc điện tử và đánh giá chất lượng (UC12).       |
+-------------------------------------------------------------------------------+

Kiến trúc Triển khai Hạ tầng (Deployment Architecture)

                       [Cloudflare DNS / WAF]
                                 |
                     [Nginx 1.24 Reverse Proxy]
                                 |
       +-------------------------+-------------------------+
       |                                                   |
[Frontend Web Server]                             [Backend API Cluster]
(Node.js 18 / Next.js)                           (Express.js / Node.js 18)
       |                                                   |
       +-------------------------+-------------------------+
                                 |
             +-------------------+-------------------+
             |                                       |
    [MySQL 8.0 Primary-Replica]             [Redis 7.0 Cluster]
       (Persistent Storage)                (Cache & Session Store)

Phân tích Chi phí - Lợi ích (Cost-Benefit & ROI Analysis)

  • Chi phí vận hành: Giảm 40% chi phí in ấn hồ sơ giấy, sổ khám bệnh và biên lai thu tiền.
  • Năng suất lao động: Tăng 35% số lượng bệnh nhân được phục vụ trong một ca làm việc nhờ rút ngắn thời gian xử lý thủ tục hành chính.
  • Thời gian hoàn vốn (ROI): Ước tính từ 4 đến 6 tháng sau khi đưa phần mềm vào vận hành chính thức tại một phòng khám quy mô 10 bàn khám.

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

Hạn chế hiện tại

  • Đồ án dừng lại ở giai đoạn phân tích thiết kế phần mềm chi tiết và xây dựng mockup giao diện; chưa tiến hành lập trình toàn diện (Full implementation) trên môi trường sản xuất.
  • Chưa tích hợp cơ chế chữ ký số (Digital Signature) cho đơn thuốc điện tử theo quy định của Bộ Y tế.

Hướng phát triển

  1. Lập trình toàn diện hệ thống: Xây dựng ứng dụng đa nền tảng với React Native cho người bệnh và React.js cho đội ngũ quản trị/bác sĩ.
  2. Tích hợp cổng thanh toán trực tuyến: Liên kết API thanh toán VNPAY, MoMo, ZaloPay và VietQR tự động.
  3. Ứng dụng Trí tuệ Nhân tạo (AI): Tích hợp mô hình học máy hỗ trợ dự đoán lượng bệnh nhân theo khung giờ nhằm tối ưu hóa lịch trực của y bác sĩ.

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

  • Sinh viên & Nghiên cứu sinh ngành CNTT: Nguồn tài liệu tham khảo chuẩn mực về quy trình phân tích thiết kế phần mềm hướng đối tượng (OOAD), cấu trúc đặc tả Use Case và vẽ sơ đồ UML 2.5 hoàn chỉnh.
  • Lập trình viên & Kiến trúc sư hệ thống: Bản thiết kế kiến trúc chi tiết (Blueprint) sẵn sàng để chuyển giao sang giai đoạn lập trình và xây dựng cơ sở dữ liệu.
  • Nhà quản lý phòng khám & Doanh nghiệp y tế: Cẩm nang chuẩn hóa luồng nghiệp vụ y tế, nâng cao hiệu quả quản trị và chất lượng dịch vụ chăm sóc sức khỏe.

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

1. Cấu hình phần cứng và môi trường tối thiểu để triển khai hệ thống là gì?

Để triển khai hệ thống cho phòng khám quy mô trung bình (khoảng 500 lượt khám/ngày), yêu cầu máy chủ: CPU 4 Cores, 8GB RAM, 100GB SSD NVMe, chạy hệ điều hành Ubuntu Server 22.04 LTS, Docker Engine v24.0+, MySQL 8.0 và Node.js 18 LTS.

2. Hệ thống xử lý bài toán trùng lặp lịch khám (Double Booking) như thế nào?

Hệ thống sử dụng cơ chế Transaction Isolation Level kết hợp kỹ thuật Khóa lạc quan (Optimistic Locking) và Redis Caching. Khi người dùng chọn khung giờ, hệ thống sẽ tạm giữ (lock) khung giờ đó trong 5 phút để hoàn tất đăng ký, ngăn chặn người dùng khác đặt cùng thời điểm.

3. Hệ thống có khả năng mở rộng để liên kết nhiều chi nhánh phòng khám không?

Kiến trúc cơ sở dữ liệu được thiết kế sẵn sàng cho mô hình Multi-tenant/Multi-branch. Bằng cách bổ sung trường branch_id vào các bảng quan hệ chính (Users, Appointments, Invoices), hệ thống có thể quản lý chuỗi phòng khám tập trung mà không cần thay đổi cấu trúc nền tảng.

4. Quy trình bảo mật thông tin hồ sơ bệnh án được thiết kế ra sao?

Dữ liệu được mã hóa đường truyền qua giao thức HTTPS/TLS 1.3 và mã hóa dữ liệu nhạy cảm trong cơ sở dữ liệu (AES-256). Hệ thống phân quyền RBAC phân tách rõ ràng: Bác sĩ chỉ xem được hồ sơ bệnh án của bệnh nhân trong phạm vi điều trị, Kế toán chỉ tiếp cận thông tin hóa đơn viện phí.

5. Khách hàng không có điện thoại thông minh có thể sử dụng hệ thống không?

Có. Quy trình tiếp nhận được thiết kế mở: Bệnh nhân có thể đến trực tiếp tại quầy lễ tân, nhân viên tư vấn sẽ sử dụng phân hệ nghiệp vụ (UC08) để khởi tạo tài khoản và đặt lịch khám ngay tại phòng khám.

Kết luận

Đồ án "Phân Tích Thiết Kế Hệ Thống Phòng Khám" của nhóm sinh viên Trường Đại học Ngoại ngữ - Tin học TP.HCM đã hoàn thành xuất sắc mục tiêu xây dựng một tài liệu phân tích thiết kế phần mềm hoàn chỉnh, khoa học và mang tính ứng dụng thực tiễn cao. Với 20 Use Cases được đặc tả chi tiết, hệ thống sơ đồ UML 2.5 đồng bộ cùng thiết kế giao diện trực quan, đồ án cung cấp một bản thiết kế kỹ thuật mẫu mực cho bài toán quản trị phòng khám thông minh. Đây là tiền đề vững chắc để phát triển thành một sản phẩm phần mềm thương mại hóa hoàn chỉnh, đóng góp thiết thực vào công cuộc hiện đại hóa hạ tầng công nghệ thông tin y tế nước nhà.