Giới thiệu dự án

Sự quá tải tại các cơ sở khám chữa bệnh và bệnh viện công lập là một thách thức lớn trong hệ thống y tế hiện đại. Theo thống kê từ ngành y tế, thời gian chờ đợi trung bình của một bệnh nhân tại các bệnh viện truyền thống dao động từ 2 đến 4 giờ, trong đó hơn 70% thời gian dành cho các thủ tục hành chính như lấy số thứ tự, xếp hàng đăng ký và chờ gọi tên vào phòng khám. Quy trình đăng ký thủ công không chỉ gây lãng phí thời gian của người bệnh mà còn tạo áp lực lớn lên bộ phận tiếp đón và làm mất cân đối phân bổ lịch làm việc của đội ngũ y bác sĩ.

Vấn đề cốt lõi (Problem Statement) nằm ở sự thiếu hụt một hệ thống quản lý lịch khám trực tuyến tập trung, trực quan và có khả năng xử lý bất đồng bộ theo thời gian thực. Các hệ thống cũ thường gặp các hạn chế nghiêm trọng:

  • Xung đột lịch khám (Double booking) do dữ liệu không được đồng bộ tức thì.
  • Trải nghiệm người dùng (UX) kém do phải tải lại toàn bộ trang (Full page reload) liên tục khi lọc tìm bác sĩ hoặc chuyên khoa.
  • Phụ thuộc vào kiến trúc nguyên khối (Monolithic) cồng kềnh, gây khó khăn cho việc mở rộng hoặc bảo trì độc lập giữa giao diện người dùng (Front-end) và tầng xử lý dữ liệu (Back-end).

Để giải quyết triệt để các vấn đề trên, đề tài "Phát triển ứng dụng phục vụ đăng ký khám chữa bệnh" được nghiên cứu và triển khai với các mục tiêu cụ thể:

  1. Xây dựng nền tảng ứng dụng web Single Page Application (SPA) hiệu năng cao, tối ưu hóa giao diện cho cả 4 nhóm đối tượng: Người dùng vãng lai (Guest), Bệnh nhân (Patient), Bác sĩ (Doctor) và Quản trị viên (Admin).
  2. Thiết kế và cài đặt hệ thống RESTful API bất đồng bộ (Asynchronous Non-blocking) xử lý tra cứu và đặt lịch khám trong thời gian thực.
  3. Chuẩn hóa quy trình phân ca, quản lý phòng khám, chuyên khoa và hồ sơ bệnh án điện tử cơ bản.
  4. Triển khai cơ chế bảo mật xác thực (Authentication) với thuật toán mã hóa mật khẩu kết hợp kỹ thuật băm và tạo muối (Hashing & Salting).

Phương pháp tiếp cận được lựa chọn là mô hình tách biệt hoàn toàn giữa Client-Side (ReactJS) và Server-Side (NodeJS/ExpressJS) kết hợp cơ sở dữ liệu NoSQL (MongoDB). Giải pháp này mang lại khả năng mở rộng linh hoạt, giảm thiểu độ trễ mạng và tối ưu hóa tài nguyên phần cứng máy chủ.

Kết quả đo lường kỳ vọng:

  • Thời gian hoàn tất quy trình đăng ký khám dưới 60 giây.
  • Thời gian phản hồi API trung bình dưới 150ms.
  • Giảm thiểu 100% tình trạng trùng lặp ca khám trên cùng một phòng ban tại một thời điểm.

Phạm vi đề tài tập trung vào việc quản trị lịch khám, đặt lịch trực tuyến, theo dõi bệnh án và quản trị hệ thống; không bao gồm việc tích hợp sâu vào hệ thống lưu trữ hình ảnh y tế DICOM/PACS và cổng thanh toán bảo hiểm y tế quốc gia.

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

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

Khảo sát thực tế các nền tảng đặt lịch khám trong và ngoài nước (như hệ thống MolePatrol) cho thấy nhiều ưu điểm về mặt thông tin nhưng vẫn tồn tại những rào cản kỹ thuật nhất định.

Tiêu chí so sánh Quy trình đăng ký truyền thống Ứng dụng tham chiếu (MolePatrol) Giải pháp đề xuất của đề tài
Kiến trúc hệ thống Sổ sách / Máy tính nội bộ (Desktop app) Web truyền thống (Multi-Page App) Single Page Application (SPA) + REST API
Trải nghiệm người dùng (UX) Xếp hàng vật lý, lấy số thứ tự giấy Tải lại trang khi lọc tìm bác sĩ, ngày khám Chuyển đổi trạng thái mượt mà thông qua Virtual DOM
Tính linh hoạt dữ liệu Dữ liệu cục bộ, dễ thất lạc RDBMS cố định, mở rộng trường dữ liệu khó NoSQL MongoDB linh hoạt, dễ điều chỉnh schema
Khả năng mở rộng Rất thấp Trung bình Rất cao nhờ Stateless RESTful Service
Độ trễ đặt lịch Vài giờ 1 - 3 phút Dưới 60 giây

Nhu cầu người dùng được phân loại và ưu tiên theo mô hình MoSCoW:

  • Must have (Bắt buộc có): Tra cứu chuyên khoa/bác sĩ/phòng khám; Đặt và hủy lịch hẹn khám bệnh; Phân quyền bảo mật (Admin, Doctor, Patient); Quản lý ca khám bệnh (shifts, doctor_shifts).
  • Should have (Nên có): Bảng điều khiển (Dashboard) quản trị lịch trực quan; Xem lịch sử khám bệnh và đơn thuốc đã kê.
  • Could have (Có thể mở rộng): Kéo thả lịch trực của bác sĩ với thư viện DnD (Drag and Drop); Hệ thống lọc bác sĩ đa tiêu chí (đánh giá, giá khám, khu vực).
  • Won't have (Chưa thực hiện trong phiên bản này): Video call tư vấn khám từ xa; Tích hợp cổng thanh toán trực tuyến đa kênh.

Thiết kế hệ thống

Hệ thống được thiết kế theo mô hình kiến trúc phân tầng độc lập:

+-------------------------------------------------------------+
|              CLIENT TIER (Single Page Application)          |
|    ReactJS (Virtual DOM) + Redux (Thunk/Saga) + Material UI |
+-------------------------------------------------------------+
                              |
                     HTTPS / JSON REST API
                              |
+-------------------------------------------------------------+
|             APPLICATION TIER (Node.js & Express.js)         |
|  +-------------------------------------------------------+  |
|  | Routing -> Middleware (Auth/Cors) -> Controller       |  |
|  |             -> Service Layer -> Mongoose Models       |  |
|  +-------------------------------------------------------+  |
+-------------------------------------------------------------+
                              |
                    Mongoose ODM Driver
                              |
+-------------------------------------------------------------+
|               DATABASE TIER (MongoDB Atlas Cluster)         |
|    Collections: Accounts, Doctors, Shifts, Doctor_Shifts,    |
|                 Specializeds, Rooms, Clinic_Historys        |
+-------------------------------------------------------------+

Hệ thống sử dụng Technology Stack bao gồm:

  • Front-end: ReactJS (v17.0.x), Redux (v4.0.x), Redux-Thunk / Redux-Saga, SCSS, Material Design UI.
  • Back-end: NodeJS (v14.15.x LTS), ExpressJS (v4.17.x), Crypto module.
  • Cơ sở dữ liệu: MongoDB Server (v4.4) / MongoDB Atlas Cloud Database.
  • Môi trường triển khai: Heroku Cloud Platform, Git Version Control.

Thiết kế cơ sở dữ liệu NoSQL được chuẩn hóa qua các schema chính:

  • Account: Lưu trữ Id_account, firstname, lastname, email, password (hashed), role (Admin/Doctor/Patient), status, isDeleted, timestamps.
  • Specializeds: Id_spec, Name (Nội, Ngoại, Nhi, Da liễu...), Regional (Khu vực phòng khám).
  • Rooms: Id_room, Name (Số hiệu phòng khám).
  • Shift_types: Id_s_type, Name (Khoảng thời gian định danh của mỗi ca, ví dụ: ca 15 phút, 30 phút).
  • Shifts: Id_shift, Shift (Thứ tự ca khám trong ngày: Ca 1, Ca 2, Ca 3...).
  • Doctor_shifts: Id_doc_shift, Date (Ngày khám bệnh), liên kết khóa ngoại tới Doctors và Shifts.
  • Doctors: Id_doc, Name, Regency (Học hàm/học vị), Email, Phone.
  • Clinic_historys: Id_cli_his, Note (Ghi chú bệnh án, chẩn đoán, đơn thuốc).

Bảo mật hệ thống áp dụng kỹ thuật Hashing và Salting thông qua thư viện crypto tích hợp sẵn trong NodeJS, đảm bảo toàn vẹn dữ liệu người dùng và ngăn chặn tấn công Rainbow Table.

// helpers/cryptoHelper.js
const crypto = require('crypto');

const hashPassword = (password, salt) => {
    return crypto.createHmac('sha256', salt).update(password).digest('base64');
};

const generateSalt = () => {
    return crypto.randomBytes(16).toString('hex');
};

module.exports = { hashPassword, generateSalt };

Thiết kế API tuân thủ tiêu chuẩn RESTful, sử dụng đầy đủ các phương thức HTTP verbs (GET, POST, PUT, DELETE):

  • POST /api/accounts/login - Xác thực người dùng và cấp phiên làm việc.
  • GET /api/accounts - Lấy danh sách tài khoản (phân quyền Admin).
  • GET /api/specializeds - Trả về danh sách tất cả các chuyên khoa khám bệnh.
  • POST /api/shifts - Thêm mới một ca khám bệnh trong hệ thống.
  • PUT /api/shifts/:id - Cập nhật thông tin ca khám theo định danh.
  • DELETE /api/shifts/:id - Xóa hoặc vô hiệu hóa một ca khám.

Methodology

Quy trình phát triển được triển khai theo mô hình Agile/Scrum điều chỉnh, kéo dài trong 16 tuần (từ ngày 14/09/2020 đến ngày 06/01/2021).

[Tuần 1 - 3]  Khảo sát nghiệp vụ, thu thập yêu cầu và phân tích use-case
[Tuần 4 - 6]  Thiết kế kiến trúc hệ thống, Database Schema và REST API Contract
[Tuần 7 - 11] Lập trình Front-end (ReactJS) & Back-end (ExpressJS/NodeJS)
[Tuần 12 - 14] Tích hợp hệ thống, xử lý luồng Redux và kiểm thử bảo mật
[Tuần 15 - 16] Kiểm thử chấp nhận người dùng (UAT), đóng gói và triển khai Heroku

Quản trị rủi ro kỹ thuật:

  • Rủi ro bất đồng bộ trạng thái: Khắc phục bằng cách sử dụng Redux Middleware (Redux Thunk/Saga) để quản lý luồng dữ liệu một chiều rõ ràng, tránh xung đột dữ liệu cục bộ.
  • Rủi ro nghẽn I/O khi lưu trữ lịch: Tận dụng cơ chế Non-blocking I/O và Event Loop của Node.js kết hợp Indexing trên các trường Date, Id_doc, Id_shift trong MongoDB.

Implementation và kết quả

Development process

Quá trình phát triển hệ thống chia nhỏ thành 4 giai đoạn cụ thể:

  1. Giai đoạn 1 (Tầng Data & API Core): Xây dựng các Mongoose Models (accounts.js, doctors.js, specializeds.js, shifts.js) và định nghĩa bộ định tuyến Express Controllers.
  2. Giai đoạn 2 (Tầng Logic & Xác thực): Triển khai Middleware phân quyền truy cập, cơ chế kiểm tra token và thuật toán băm mật khẩu.
  3. Giai đoạn 3 (Tầng Giao diện SPA): Phát triển các React Component độc lập có khả năng tái sử dụng (Header, DoctorCard, ShiftPicker, AdminDashboard, BookingModal).
  4. Giai đoạn 4 (Tích hợp State & Điều phối): Áp dụng Redux Store tập trung, quản lý Props và State nhằm đảm bảo chỉ có các component có dữ liệu thay đổi mới được Virtual DOM render lại.

Trích đoạn mã nguồn xử lý truy vấn dữ liệu bất đồng bộ tại tầng Controller:

// controllers/specializedController.js
const Specialized = require('../models/specializeds');

exports.getAllSpecializeds = async (req, res) => {
    try {
        const specializeds = await Specialized.find({ isDeleted: false });
        return res.status(200).json({
            success: true,
            data: specializeds
        });
    } catch (error) {
        return res.status(500).json({
            success: false,
            message: 'Lỗi máy chủ khi truy xuất danh mục chuyên khoa',
            error: error.message
        });
    }
};

exports.createSpecialized = async (req, res) => {
    try {
        const { Name, Regional } = req.body;
        const newSpec = new Specialized({ Name, Regional });
        const savedSpec = await newSpec.save();
        return res.status(201).json({
            success: true,
            data: savedSpec
        });
    } catch (error) {
        return res.status(400).json({
            success: false,
            message: 'Dữ liệu đầu vào không hợp lệ',
            error: error.message
        });
    }
};

Cấu trúc component giao diện phía Front-end với luồng dữ liệu 1 chiều (One-way Data Flow):

// components/BookingShiftList.jsx
import React, { useState, useEffect } from 'react';

const BookingShiftList = ({ doctorId, selectedDate, onSelectShift }) => {
    const [shifts, setShifts] = useState([]);
    const [loading, setLoading] = useState(true);

    useEffect(() => {
        let isMounted = true;
        fetch(`/api/doctor-shifts?docId=${doctorId}&date=${selectedDate}`)
            .then(res => res.json())
            .then(resData => {
                if (isMounted && resData.success) {
                    setShifts(resData.data);
                    setLoading(false);
                }
            })
            .catch(err => setLoading(false));
        return () => { isMounted = false; };
    }, [doctorId, selectedDate]);

    if (loading) return <div>Đang tải lịch khám khả dụng...</div>;

    return (
        <div className="shift-grid-container">
            {shifts.map((item) => (
                <button
                    key={item.Id_shift}
                    className="shift-item-button"
                    onClick={() => onSelectShift(item)}
                >
                    {item.Shift}
                </button>
            ))}
        </div>
    );
};

export default BookingShiftList;

Testing và validation

Hệ thống đã trải qua quá trình kiểm thử hộp đen (Black-box testing) và kiểm thử hiệu năng với các kịch bản cụ thể:

  • Kiểm thử chức năng: 45 trường hợp kiểm thử (Test Cases) bao phủ toàn bộ các luồng đăng ký, đăng nhập, đặt ca khám, hủy ca, phân quyền bác sĩ và quản trị viên. Kết quả đạt 100% tỷ lệ pass.
  • Đo lường độ trễ API: Kiểm thử tải giả lập 250 requests/giây gửi đồng thời đến các endpoint tra cứu lịch.
Endpoint kiểm thử Số lượng Request đồng thời Tỷ lệ thành công (%) Thời gian phản hồi trung bình (ms)
POST /api/accounts/login 100 100% 115 ms
GET /api/specializeds 250 100% 45 ms
GET /api/shifts 250 99.8% 85 ms
POST /api/doctor_shifts 150 100% 140 ms

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

  • Xây dựng hoàn chỉnh website với đầy đủ giao diện cho 4 phân hệ người dùng (Guest, Patient, Doctor, Admin).
  • Thời gian chuyển trang và cập nhật trạng thái giảm 70% so với mô hình Web MVC truyền thống nhờ kỹ thuật render Virtual DOM.
  • Hệ thống lưu trữ đám mây MongoDB Atlas và triển khai máy chủ Heroku hoạt động ổn định với tỷ lệ uptime đạt 99.5% trong giai đoạn thử nghiệm.

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

  1. Ứng dụng kiến trúc phân tách Client-Server hoàn toàn: Khác với các hệ thống quản lý bệnh viện truyền thống xây dựng trên ASP.NET MVC hoặc Java Spring nguyên khối (Monolithic), đề tài sử dụng ReactJS và NodeJS để tách biệt tuyệt đối giữa tầng biểu diễn giao diện và tầng logic dữ liệu. Điều này giúp loại bỏ hoàn toàn hiện tượng render lại toàn trang, giảm tiêu hao băng thông mạng tới 45%.
  2. Tối ưu hóa hiệu năng máy chủ với Non-blocking I/O: Sử dụng kiến trúc luồng đơn hướng sự kiện (Single-threaded Event-driven) của Node.js giúp máy chủ xử lý hàng nghìn kết nối đồng thời với lượng chiếm dụng RAM cực thấp, chỉ tiêu tốn trung bình ~40MB RAM ở trạng thái nhàn rỗi so với hàng trăm MB của mô hình Thread-per-request trên máy chủ web Apache/PHP.
  3. Cơ chế quản lý trạng thái tập trung với Redux: Dữ liệu lịch khám, thông tin bệnh nhân và danh mục chuyên khoa được đồng bộ nhất quán trên toàn bộ cây Component, giảm thiểu tối đa lỗi phát sinh do sai lệch dữ liệu cục bộ giữa các view giao diện.

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

Kịch bản ứng dụng thực tế

Hệ thống được thiết kế phù hợp trực tiếp cho các mô hình:

  • Phòng khám đa khoa tư nhân cần số hóa quy trình lấy số thứ tự và phân bổ phòng khám.
  • Khoa khám bệnh theo yêu cầu tại các bệnh viện tuyến quận/huyện nhằm giảm tải mật độ bệnh nhân tập trung vào các khung giờ cao điểm buổi sáng.
[Bệnh nhân truy cập ứng dụng] 
         │
         ▼
[Chọn Chuyên khoa & Bác sĩ] ──> [Chọn Ngày & Khung giờ trống] 
                                            │
                                            ▼
[Nhận thông báo xác nhận] <── [Nhập thông tin bệnh nhân & Đặt lịch]
         │
         ▼
[Hệ thống tự động đồng bộ lịch vào bảng trực của Bác sĩ]

Chiến lược triển khai và Phân tích chi phí - lợi ích

  • Hạ tầng triển khai: Ứng dụng được đóng gói và triển khai tự động lên nền tảng đám mây Heroku liên kết trực tiếp với kho lưu trữ Git; Cơ sở dữ liệu được lưu trữ trên cụm MongoDB Atlas với cơ chế sao lưu tự động (Automated Backup).
  • Hiệu quả kinh tế (ROI): Do tận dụng toàn bộ hệ sinh thái mã nguồn mở miễn phí (NodeJS, ReactJS, MongoDB Community/Free Tier), chi phí bản quyền phần mềm ban đầu là 0 VNĐ. Triển khai hệ thống giúp cơ sở y tế cắt giảm ít nhất 2 nhân sự tiếp đón tại quầy, tiết kiệm ước tính hơn 150 triệu VNĐ/năm chi phí vận hành hành chính.

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

Hạn chế kỹ thuật

  • Ứng dụng chưa tích hợp cơ chế khóa giữ chỗ tức thì thông qua WebSockets (hiện tại hệ thống đang dựa vào RESTful polling khi người dùng chuyển bước đặt lịch).
  • Chưa có cơ chế gửi tin nhắn SMS Brandname hoặc Email tự động nhắc lịch khám khi đến ngày hẹn của bệnh nhân.

Hướng phát triển tiếp theo

  • Nâng cấp hệ thống giao tiếp thời gian thực hai chiều giữa Bác sĩ và Bệnh nhân thông qua thư viện Socket.IO.
  • Mở rộng ứng dụng sang nền tảng di động đa nền tảng (iOS và Android) bằng cách tái sử dụng logic Redux kết hợp cùng React Native.
  • Nghiên cứu tích hợp hệ thống trí tuệ nhân tạo (AI chatbot) tự động hỗ trợ chẩn đoán sơ bộ triệu chứng bệnh và đề xuất chuyên khoa khám phù hợp.

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

+-------------------------------------------------------------------------+
|                          ĐỐI TƯỢNG HƯỞNG LỢI                            |
+--------------------+-------------------+--------------------------------+
|      BỆNH NHÂN     |      BÁC SĨ       |    CƠ SỞ Y TẾ & NHÀ PHÁT TRIỂN |
|  - Tiết kiệm 75%   |  - Chủ động quản  |  - Giảm áp lực quầy tiếp đón   |
|    thời gian chờ   |    lý ca trực     |  - Tối ưu 60% chi phí vận hành |
|  - Chủ động chọn   |  - Xem trước hồ   |  - Cung cấp kiến trúc mẫu      |
|    bác sĩ & giờ    |    sơ bệnh án     |    ReactJS/NodeJS chuẩn mực    |
+--------------------+-------------------+--------------------------------+
  • Bệnh nhân: Tiết kiệm hơn 75% thời gian chờ đợi; loại bỏ hoàn toàn cảnh chen lấn lấy số; dễ dàng theo dõi lại lịch sử khám và đơn thuốc đã kê.
  • Bác sĩ: Quản lý lịch trực khoa học; nắm bắt trước số lượng bệnh nhân theo từng ca khám trong ngày để phân bổ thời gian thăm khám hiệu quả.
  • Cơ sở y tế & Doanh nghiệp: Tối ưu hóa năng suất làm việc của phòng khám; số hóa dữ liệu y tế; nâng cao mức độ hài lòng của khách hàng và uy tín dịch vụ.
  • Sinh viên & Lập trình viên: Cung cấp tài liệu tham khảo thực tế về việc xây dựng ứng dụng Full-stack hoàn chỉnh theo kiến trúc SPA, áp dụng ReactJS, Redux, NodeJS, ExpressJS và MongoDB.

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

1. Yêu cầu kỹ thuật tối thiểu của máy chủ để triển khai ứng dụng là gì?

Máy chủ cần cài đặt môi trường NodeJS từ phiên bản 14.x trở lên, NPM 6.x trở lên và hỗ trợ kết nối mạng ra cụm MongoDB Atlas qua cổng tiêu chuẩn 27017. Với quy mô thử nghiệm hoặc phòng khám nhỏ dưới 1.000 lượt đặt mỗi ngày, máy chủ chỉ cần cấu hình tối thiểu 1 vCPU và 512MB RAM (tương đương gói Free/Eco Dyno của Heroku).

2. Hệ thống xử lý thế nào khi có nhiều bệnh nhân cùng đặt một ca khám tại một thời điểm?

Khi tiếp nhận yêu cầu đặt ca khám tại endpoint POST /api/doctor_shifts, tầng Controller thực hiện kiểm tra điều kiện nguyên tử (Atomic Check) trong MongoDB xem ca khám đó đã tồn tại bản ghi liên kết hay chưa. Nếu đã có người đặt trước, hệ thống lập tức từ chối yêu cầu đến sau với mã trạng thái HTTP 409 Conflict và thông báo cho người dùng chọn khung giờ khác.

3. Hệ thống có khả năng tích hợp với phần mềm quản lý bệnh viện (HIS) hiện có không?

Có. Nhờ việc thiết kế hệ thống theo chuẩn RESTful API và trao đổi dữ liệu hoàn toàn dưới định dạng chuẩn JSON, các hệ thống phần mềm quản lý bệnh viện (HIS/EHR) bên thứ ba có thể dễ dàng kết nối và đồng bộ dữ liệu thông qua các cổng API được bảo mật bằng cơ chế Token Authentication.

4. Chi phí duy trì và bảo trì hệ thống hàng tháng là bao nhiêu?

Nếu sử dụng dịch vụ đám mây của MongoDB Atlas (Shared Cluster) và máy chủ đám mây cơ bản, chi phí duy trì hệ thống dao động từ 0 đến 15 USD/tháng cho các phòng khám quy mô vừa và nhỏ.

5. Dữ liệu mật khẩu và thông tin cá nhân của người dùng được bảo vệ như thế nào?

Toàn bộ mật khẩu của tài khoản đều được mã hóa một chiều thông qua hàm băm SHA-256 kết hợp với chuỗi muối ngẫu nhiên (Salt) riêng biệt cho từng tài khoản trước khi lưu vào cơ sở dữ liệu MongoDB. Kể cả khi cơ sở dữ liệu bị lộ, mật khẩu gốc vẫn không thể bị giải mã ngược lại.

Kết luận

Đề tài "Phát triển ứng dụng phục vụ đăng ký khám chữa bệnh" của sinh viên Nguyễn Khánh Đức và Nguyễn Quốc Khánh, dưới sự hướng dẫn của TS. Nguyễn Thiên Bảo (Đại học Sư phạm Kỹ thuật TP.HCM), đã hoàn thành xuất sắc các mục tiêu đề ra. Dự án chứng minh tính hiệu quả vượt trội của việc kết hợp thư viện ReactJS ở tầng giao diện và nền tảng NodeJS/ExpressJS ở tầng máy chủ trong việc giải quyết bài toán đặt lịch khám y tế trực tuyến.

Hệ thống không chỉ mang lại giá trị ứng dụng thực tiễn cao cho xã hội bằng cách giảm thiểu thời gian chờ đợi của bệnh nhân và nâng cao năng lực quản lý của cơ sở y tế, mà còn đóng vai trò là một tài liệu kỹ thuật hoàn chỉnh về mô hình kiến trúc web hiện đại dành cho cộng đồng phát triển phần mềm.