Giới thiệu dự án

Đại dịch COVID-19 bùng phát đã tạo ra áp lực chưa từng có lên hệ thống y tế toàn cầu cũng như tại Việt Nam. Theo thống kê từ Bộ Y tế trong các đợt cao điểm dịch bệnh, hơn 80% ca nhiễm F0 không có triệu chứng hoặc triệu chứng nhẹ được chỉ định cách ly và điều trị tại nhà. Tuy nhiên, việc quản lý bệnh nhân F0 tại nhà theo phương thức truyền thống bộc lộ nhiều lỗ hổng nghiêm trọng: dữ liệu sức khỏe phân tán, liên lạc qua các nhóm chat thông thường (Zalo, Viber) dễ bị trôi tin nhắn, bác sĩ không thể theo dõi sát sao diễn biến lâm sàng của hàng trăm bệnh nhân cùng lúc, và đặc biệt là sự chậm trễ trong việc tiếp nhận tín hiệu cấp cứu khi bệnh nhân trở nặng (suy hô hấp cấp, tụt chỉ số SpO2).

Trước thực trạng đó, đồ án tốt nghiệp ngành Công nghệ Thông tin tại Trường Đại học Thăng Long với đề tài "Xây dựng phần mềm chăm sóc F0 tại nhà" (ComMCare) do sinh viên Nguyễn Văn Lực và Nguyễn Thái Dương thực hiện dưới sự hướng dẫn của TS. Trần Đức Minh đã giải quyết trọn vẹn bài toán quản lý và chăm sóc y tế từ xa.

+-------------------------------------------------------------------------+
|                           HỆ THỐNG COMMCARE                             |
+-------------------------------------------------------------------------+
|  [Bệnh nhân / Người phụ thuộc] <---> [Tình nguyện viên] <---> [Bác sĩ]  |
|         |                                                        |      |
|         +--> [React Native Mobile] / [Blazor WebAssembly] <------+      |
|                                |                                        |
|                                v                                        |
|             [ASP.NET Core 6 / IdentityServer4 / gRPC]                   |
|                                |                                        |
|              +-----------------+-----------------+                      |
|              v                                   v                      |
|      [SQL Server (Auth)]               [MongoDB (EHR & Tasks)]          |
+-------------------------------------------------------------------------+

Mục tiêu dự án

  1. Xây dựng nền tảng đa kênh tích hợp: Phát triển ứng dụng di động đa nền tảng (iOS/Android) cho bệnh nhân, tình nguyện viên và ứng dụng web quản trị cho bác sĩ, quản trị viên.
  2. Chuẩn hóa quy trình theo dõi y tế: Số hóa 100% quy trình khám bệnh hàng ngày, chỉ định nhiệm vụ (đo thân nhiệt, SpO2, bài tập thở), quản lý đơn thuốc và báo cáo xét nghiệm.
  3. Cơ chế phản ứng khẩn cấp thời gian thực: Tích hợp tính năng SOS khẩn cấp qua giao thức thời gian thực, đảm bảo thời gian phản hồi dưới 500ms khi người bệnh gặp nguy kịch.
  4. Kiến trúc hệ thống phân tán, chuẩn công nghiệp: Áp dụng mô hình Domain-Driven Design (DDD), Clean Architecture, CQRS và gRPC để đảm bảo khả năng mở rộng (scalability) và tính bảo mật cao.

Phạm vi và giới hạn hệ thống

  • Phạm vi: Quản lý F0 điều trị ngoại trú, hỗ trợ bác sĩ kê đơn, phân quyền theo nhóm hỗ trợ, điều phối tình nguyện viên, kết nối cơ sở cung cấp thuốc/vật tư y tế.
  • Giới hạn: Hệ thống không thay thế các thiết bị can thiệp y tế chuyên sâu tại phòng cấp cứu ICU và không xử lý thanh toán viện phí trực tuyến trong phiên bản hiện tại.

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

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

Tại thời điểm bùng phát dịch, phần lớn các giải pháp hỗ trợ F0 mang tính chắp vá. Bảng so sánh dưới đây làm rõ sự khác biệt giữa các giải pháp truyền thống và hệ thống ComMCare:

Tiêu chí đánh giá Quản lý thủ công qua Zalo/Viber Hệ thống EMR/HIS bệnh viện truyền thống Hệ thống Telehealth ComMCare
Cấu trúc dữ liệu y tế Phi cấu trúc, tin nhắn rời rạc, dễ thất lạc Rất chặt chẽ nhưng cồng kềnh, khó dùng cho F0 Bán cấu trúc tối ưu (JSON Documents), chuẩn hóa theo nghiệp vụ F0
Cảnh báo khẩn cấp (SOS) Không có luồng ưu tiên, phụ thuộc vào việc đọc tin nhắn Không hỗ trợ người dùng ngoại trú Kênh riêng biệt qua SignalR & Push Notification độ trễ < 500ms
Giao diện người dùng Giao diện chat thông thường Web portal phức tạp, chỉ dành cho nhân viên y tế Ứng dụng di động tối giản cho bệnh nhân; Web Dashboard trực quan cho bác sĩ
Khả năng mở rộng Không thể quản lý tập trung trên 1.000 bệnh nhân Chi phí vận hành máy chủ và bản quyền rất cao Kiến trúc hướng dịch vụ, cơ chế scale độc lập theo module

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

  • Must have (Bắt buộc): Xác thực đa quyền (IdentityServer4), Tạo và giao chỉ định hàng ngày, Kê đơn thuốc điện tử, Gửi cảnh báo SOS khẩn cấp, Quản lý hồ sơ bệnh nhân và F0 phụ thuộc.
  • Should have (Nên có): Nhóm chat thời gian thực (Bác sĩ - Bệnh nhân - Tình nguyện viên), Quản lý nhãn phân loại mức độ bệnh (Triage tags), Thống kê biểu đồ diễn tiến sức khỏe.
  • Could have (Có thể mở rộng): Gọi thoại/video trực tiếp qua WebRTC, Tích hợp cổng tra cứu nhà thuốc theo định vị GPS.
  • Won't have (Chưa thực hiện): Thanh toán đơn thuốc trực tuyến, Tích hợp tự động máy thở IoT.

Thiết kế hệ thống

Hệ thống được thiết kế theo nguyên lý Clean Architecture kết hợp phương pháp luận Domain-Driven Design (DDD), chia thành 4 tầng ranh giới rõ ràng:

+-------------------------------------------------------------+
|                     PRESENTATION LAYER                      |
|       Blazor WebAssembly (Web Admin) | React Native (App)   |
|                             |                               |
|                             v                               |
|                     APPLICATION LAYER                       |
|           CQRS (Commands / Queries) | MediatR Bus           |
|                             |                               |
|                             v                               |
|                       DOMAIN LAYER                          |
|         Entities | Value Objects | Aggregate Roots          |
|                             ^                               |
|                             |                               |
|                    INFRASTRUCTURE LAYER                     |
|      MongoDB Context | EF Core SQL Server | gRPC Clients    |
+-------------------------------------------------------------+

Technology Stack và phiên bản cụ thể

  • Backend Services: ASP.NET Core 6.0 Web API, C# 10.
  • Microservices Communication: gRPC.Net 2.40 (truyền tải dữ liệu nhị phân qua HTTP/2 giữa Identity Service và Patient Service).
  • Kiến trúc điều hướng & CQRS: MediatR 10.0, FluentValidation.
  • Xác thực & Phân quyền: IdentityServer4 v4.1.2 (OAuth 2.0 / OpenID Connect với JSON Web Token - JWT).
  • Giao tiếp thời gian thực: ASP.NET Core SignalR 6.0, Firebase Cloud Messaging (FCM).
  • Cơ sở dữ liệu:
    • Relational Database: Microsoft SQL Server 2019 (quản lý phân quyền Identity, Roles, Clients).
    • NoSQL Document Database: MongoDB 5.0 (lưu trữ hồ sơ lâm sàng, đơn thuốc, chỉ định task, tin nhắn).
  • Object-Relational Mapping: Entity Framework Core 6.0, MongoDB C# Official Driver 2.15.
  • Frontend Web: Blazor WebAssembly .NET 6.0 kết hợp MudBlazor Component Library.
  • Frontend Mobile: React Native 0.68, Redux-Saga 1.1, React Hooks, Axios.
  • Giám sát hệ thống: Seq Server 2021 (Structured Logging qua Serilog).

Database Design: Polyglot Persistence

Hệ thống sử dụng chiến lược lưu trữ dữ liệu đa mô hình (Polyglot Persistence):

  1. MSSQL Server (IdentityDb): Lưu trữ các bảng AspNetUsers, AspNetRoles, Clients, IdentityResources, ApiScopes phục vụ bảo mật tuyệt đối.
  2. MongoDB (PatientDb): Lưu trữ các Collections linh hoạt:
    • Patients: Chứa thông tin hành chính, mã CMND/CCCD, danh sách người phụ thuộc (Dependents), nhãn bệnh lý (Tags).
    • DailyTasks: Chứa chỉ định đo nhiệt độ, SpO2, trạng thái hoàn thành (IsCompleted), timestamp.
    • Prescriptions: Chứa danh sách thuốc, liều lượng, số lần lặp, ghi chú của bác sĩ.
    • SOSAlarms: Lưu trữ tọa độ, trạng thái tiếp nhận, timestamp của tín hiệu khẩn cấp.
    • Conversations & Messages: Lưu trữ tin nhắn nhóm chat và file đính kèm.

Methodology

  • Phương pháp phát triển: Agile/Scrum với các chu kỳ Sprint 2 tuần.
  • Kế hoạch thực hiện: 6 Sprint (12 tuần) bao gồm: Khảo sát nghiệp vụ -> Thiết kế kiến trúc & Database -> Xây dựng Service Identity & Patient API -> Xây dựng Mobile App & Blazor Web -> Tích hợp Real-time SignalR/Firebase -> Testing & UAT.
  • Đánh giá rủi ro & giải pháp:
    • Rủi ro nghẽn cổ chai khi tải lượng request tăng đột biến: Tách riêng Read/Write database thông qua mô hình CQRS; tối ưu hóa MongoDB index cho các trường truy vấn thường xuyên (PatientId, CreatedAt).
    • Rủi ro mất kết nối mạng di động: Áp dụng cơ chế Redux-Saga queue và local caching để lưu tạm dữ liệu chỉ định trước khi đồng bộ về server.

Implementation và kết quả

Development process

Quá trình phát triển áp dụng chặt chẽ kiến trúc Clean Architecture. Tất cả các luồng xử lý dữ liệu ở tầng Application được đóng gói dưới dạng Command hoặc Query thông qua Mediator Pattern.

1. Cấu trúc CQRS Command và Handler xử lý dữ liệu (ASP.NET Core C#)

Đoạn mã sau minh họa cách triển khai CreateDailyTaskCommandCommandHandler tương ứng để tạo chỉ định cho bệnh nhân F0:

// Application Layer: Command Definition
public class CreateDailyTaskCommand : IRequest<Result<string>>
{
    public string PatientId { get; set; }
    public string DoctorId { get; set; }
    public string Title { get; set; }
    public string Description { get; set; }
    public TaskType Type { get; set; }
    public DateTime DueDate { get; set; }
}

// Application Layer: Command Handler
public class CreateDailyTaskCommandHandler : IRequestHandler<CreateDailyTaskCommand, Result<string>>
{
    private readonly IPatientRepository _patientRepository;
    private readonly IHubContext<NotificationHub> _hubContext;

    public CreateDailyTaskCommandHandler(
        IPatientRepository patientRepository, 
        IHubContext<NotificationHub> hubContext)
    {
        _patientRepository = patientRepository;
        _hubContext = hubContext;
    }

    public async Task<Result<string>> Handle(CreateDailyTaskCommand request, CancellationToken cancellationToken)
    {
        var patient = await _patientRepository.GetByIdAsync(request.PatientId);
        if (patient == null)
            return Result<string>.Failure("Bệnh nhân không tồn tại trên hệ thống.");

        var dailyTask = new DailyTask(
            Guid.NewGuid().ToString(),
            request.PatientId,
            request.Title,
            request.Description,
            request.Type,
            request.DueDate
        );

        await _patientRepository.AddDailyTaskAsync(dailyTask);

        // Gửi thông báo thời gian thực đến Client Mobile của F0 qua SignalR
        await _hubContext.Clients.User(request.PatientId)
            .SendAsync("ReceiveNewTask", dailyTask.Title, cancellationToken);

        return Result<string>.Success(dailyTask.Id);
    }
}

2. Xử lý Side Effect với Redux-Saga trên ứng dụng di động (React Native)

Để xử lý việc phát tín hiệu SOS khẩn cấp từ bệnh nhân mà không gây block giao diện, ứng dụng di động sử dụng redux-saga:

import { takeLatest, call, put } from 'redux-saga/effects';
import axios from 'axios';
import { SOS_TRIGGER_REQUEST, sosSuccess, sosFailure } from '../actions/sosActions';

function callSosApi(payload) {
  return axios.post('https://api.commcare.vn/api/v1/sos/send-alarm', {
    patientId: payload.patientId,
    latitude: payload.coords.latitude,
    longitude: payload.coords.longitude,
    symptoms: payload.symptoms,
    timestamp: new Date().toISOString()
  });
}

export function* handleTriggerSos(action) {
  try {
    const response = yield call(callSosApi, action.payload);
    yield put(sosSuccess(response.data));
  } catch (error) {
    yield put(sosFailure(error.response ? error.response.data.message : 'Mất kết nối server'));
  }
}

export function* watchSosSaga() {
  yield takeLatest(SOS_TRIGGER_REQUEST, handleTriggerSos);
}

3. Định nghĩa dịch vụ giao tiếp nội bộ qua gRPC (Protocol Buffers)

Dịch vụ PatientService gọi IdentityService để xác thực và lấy thông tin chi tiết của người dùng qua giao thức nhị phân siêu tốc:

syntax = "proto3";

option csharp_namespace = "ComMCare.Identity.Grpc";

package identity;

service UserGrpcService {
  rpc GetUserDetail (UserLookupRequest) returns (UserModelResponse);
}

message UserLookupRequest {
  string userId = 1;
}

message UserModelResponse {
  string id = 1;
  string fullName = 2;
  string phoneNumber = 3;
  string identityCard = 4;
  string role = 5;
}

Testing và validation

Hệ thống đã trải qua các đợt kiểm thử tự động và kiểm thử tải trọng nghiêm ngặt:

  • Unit Testing & Integration Testing: Sử dụng xUnit và Moq kiểm thử các tầng Domain và Application Logic, đạt độ bao phủ code (Code Coverage) là 86.4%.
  • Kiểm thử hiệu năng tải (Load Testing với Apache JMeter):
    • Giả lập 1.200 người dùng đồng thời (Concurrent Users - CCU) truy cập và gửi báo cáo sức khỏe.
    • Tỉ lệ lỗi phản hồi (Error Rate): 0.02%.
    • Độ trễ trung bình của REST API: 142ms (P95 đạt 210ms).
    • Tốc độ truyền tin gRPC nhanh gấp 6.8 lần so với REST JSON tiêu chuẩn khi truyền tải các gói dữ liệu đối tượng lớn.
    • Thời gian xử lý và phân phối cảnh báo SOS từ ứng dụng bệnh nhân đến máy tính bác sĩ trực: 318ms.
+-----------------------------------------------------------------------+
|                 KẾT QUẢ LOAD TESTING (1.200 CONCURRENT USERS)         |
+-----------------------------------------------------------------------+
| Metric                 | Target             | Achieved Value          |
+------------------------+--------------------+-------------------------+
| Latency P95 (REST API) | < 300ms            | 210ms                   |
| SOS Alert Dispatch     | < 500ms            | 318ms                   |
| Error Rate             | < 0.5%             | 0.02%                   |
| Code Coverage          | > 80%              | 86.4%                   |
+-----------------------------------------------------------------------+

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

Hệ thống đã hoàn thiện đầy đủ 18 Use Case cốt lõi theo đúng đặc tả:

  • Phân quyền chính xác 5 tác nhân: ADMIN, Bác sĩ, Tình nguyện viên, Bệnh nhân F0 và Người phụ thuộc (không cần số điện thoại riêng).
  • Khả năng đồng bộ tin nhắn và chỉ định task theo thời gian thực 100% qua SignalR Hub.
  • Đạt mức độ hài lòng người dùng trong đợt thử nghiệm cục bộ (UAT) với 15 bác sĩ và 250 bệnh nhân mô phỏng đạt 4.85/5.0 điểm.

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

  1. Ứng dụng triệt để kiến trúc Clean Architecture & DDD vào Y tế: Việc phân tách nghiệp vụ y tế thành các Core Domain và Aggregate Root giúp phần mềm không bị phụ thuộc vào bất kỳ framework bên ngoài nào, dễ dàng bảo trì và bổ sung các tính năng dịch tễ phức tạp.
  2. Kiến trúc kết hợp Hybrid Database (SQL Server & MongoDB): Tối ưu hóa được tính toàn vẹn dữ liệu cho tầng phân quyền (ACID) đồng thời khai thác tối đa tốc độ đọc/ghi dữ liệu lịch sử đo SpO2, chỉ số sinh tồn và tin nhắn theo mô hình Document NoSQL.
  3. Mô hình tương tác 3 chiều (Bác sĩ - Tình nguyện viên - Bệnh nhân): Giảm tải trực tiếp hơn 70% khối lượng công việc hành chính cho đội ngũ y bác sĩ nhờ sự san sẻ nhiệm vụ của các tình nguyện viên thông qua module "Quản lý yêu cầu".
  4. Giải pháp hỗ trợ Người phụ thuộc (Dependents): Cho phép người già, trẻ em không có CCCD hoặc smartphone vẫn được chăm sóc chu đáo dưới sự quản lý của tài khoản F0 chính.

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

Kịch bản triển khai thực tế

+------------------+         +------------------+         +------------------+
|   BỆNH NHÂN F0   |         |    COMMCARE      |         |  BÁC SĨ / TRẠM   |
+------------------+         +------------------+         +------------------+
         |                            |                            |
         | --- (1) Nhấn nút SOS ----> |                            |
         |     (Tọa độ + SpO2 < 90%)  |                            |
         |                            | --- (2) Bắn SignalR Alert->| (Chuông hú &
         |                            |     + Push Notification    |  Popup đỏ)
         |                            |                            |
         |                            | <---(3) Điều phối cấp cứu- |
         |                            |     + Chỉ định trạm y tế   |
         | <---(4) Nhận thông báo ----|                            |
         |     "Xe đang đến"          |                            |
  1. Tình huống phát hiện chuyển nặng: Bệnh nhân F0 chỉ định đo SpO2 thấy giảm dưới 90%, lập tức bấm nút SOS.
  2. Phản ứng hệ thống: Hệ thống tự động thu thập vị trí GPS, thông tin liên lạc và tiền sử bệnh lý, gửi tín hiệu ưu tiên cao nhất về Dashboard của Bác sĩ trực qua WebSocket.
  3. Xử lý y tế: Bác sĩ nhận cảnh báo bằng chuông và popup trực quan, ấn tiếp nhận cuộc gọi, kê đơn thuốc khẩn cấp và điều phối xe cấp cứu từ bệnh viện liên kết gần nhất.

Chiến lược triển khai (Deployment Strategy)

  • Containerization: Đóng gói các dịch vụ Backend thành Docker Containers chạy trên môi trường Linux Ubuntu Server.
  • Reverse Proxy & Load Balancing: Sử dụng Nginx làm API Gateway điều phối lưu lượng truy cập và thiết lập chứng chỉ SSL/TLS Let's Encrypt.
  • Giám sát tập trung: Tích hợp Seq Log để truy vết lỗi và cảnh báo bất thường trong runtime.

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

  • Hạn chế kỹ thuật hiện tại: Ứng dụng chưa tích hợp sẵn thuật toán AI để tự động phân tích đơn thuốc trùng lặp hoặc tự động đọc chỉ số SpO2 thông qua camera điện thoại.
  • Hướng phát triển tương lai:
    • Tích hợp mô hình Học máy (Machine Learning) để dự đoán nguy cơ chuyển nặng của F0 dựa trên dữ liệu chuỗi thời gian của các chỉ số sinh tồn.
    • Mở rộng chuẩn giao tiếp y tế quốc tế HL7/FHIR để sẵn sàng liên thông dữ liệu với hệ thống bệnh án điện tử quốc gia.
    • Tích hợp gọi video trực tiếp chất lượng cao dựa trên nền tảng WebRTC mã hóa đầu cuối.

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

  • Sinh viên & Học viên CNTT: Nguồn tài liệu tham khảo chất lượng cao về cách ứng dụng Domain-Driven Design, Clean Architecture, CQRS và gRPC trong các dự án phần mềm thực chiến bằng .NET Core và React Native.
  • Lập trình viên (Developers): Nắm bắt mô hình triển khai Polyglot Persistence (kết hợp SQL Server và MongoDB), cách viết code bất đồng bộ với Redux-Saga và quản trị bảo mật với IdentityServer4.
  • Cơ sở y tế & Doanh nghiệp: Nền tảng tham khảo để xây dựng các giải pháp Telehealth quản lý bệnh nhân ngoại trú cho các bệnh mãn tính khác (tiểu đường, tim mạch, huyết áp).
  • Cộng đồng y bác sĩ & Người bệnh: Giải pháp giúp tối ưu hóa nguồn lực y tế, giảm thiểu tỉ lệ tử vong do phát hiện muộn các biến chứng nguy hiểm.

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

1. Yêu cầu cấu hình hệ thống tối thiểu để triển khai ComMCare là gì?

  • Máy chủ Backend: 02 vCPU, 4GB RAM, 50GB SSD chạy Docker trên Linux Ubuntu 20.04 LTS trở lên.
  • Môi trường Client: Trình duyệt hiện đại hỗ trợ WebAssembly (Chrome, Edge, Firefox) cho Web Admin; Thiết bị di động chạy Android 8.0 hoặc iOS 12.0 trở lên.

2. Làm thế nào hệ thống đảm bảo tính chịu tải khi lượng F0 tăng vọt?

Nhờ áp dụng mô hình CQRS, hệ thống tách biệt luồng Đọc (Read - tối ưu qua MongoDB Read Queries) và luồng Ghi (Write - kiểm soát qua Commands và Transaction). Khi quá tải, các service có thể scale ngang (Horizontal Scaling) độc lập thông qua Docker Swarm hoặc Kubernetes mà không gây xung đột dữ liệu.

3. Hệ thống có thể liên kết với các phần mềm quản lý bệnh viện (HIS) hiện có không?

Có. Nhờ thiết kế theo kiến trúc hướng dịch vụ với chuẩn giao tiếp RESTful API và gRPC, ComMCare dễ dàng xây dựng các adapter để kết nối và trao đổi dữ liệu với các hệ thống HIS/LIS của bệnh viện thông qua các API an toàn được cấp phép bởi IdentityServer4.

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

Hệ thống sử dụng phần lớn các công nghệ mã nguồn mở (ASP.NET Core, MongoDB Community, React Native, Linux, Docker, Nginx). Do đó, chi phí bản quyền phần mềm bằng 0 VNĐ. Chi phí duy nhất là thuê hạ tầng Cloud/VPS (ước tính chỉ từ 500.000 - 1.500.000 VNĐ/tháng cho quy mô quản lý 5.000 bệnh nhân).

5. Dữ liệu y tế của bệnh nhân được bảo mật như thế nào?

Hệ thống sử dụng chuẩn xác thực OpenID Connect & OAuth 2.0 thông qua IdentityServer4. Toàn bộ thông tin đường truyền được mã hóa qua HTTPS/TLS 1.3. Mật khẩu được băm (hash) bằng thuật toán PBKDF2 với Salt. Quyền truy cập bệnh án được kiểm soát nghiêm ngặt theo mô hình RBAC (Role-Based Access Control) đảm bảo chỉ bác sĩ phụ trách mới có quyền xem thông tin chi tiết của bệnh nhân đó.


Kết luận

Đề tài khóa luận tốt nghiệp "Xây dựng phần mềm chăm sóc F0 tại nhà" của nhóm sinh viên Trường Đại học Thăng Long là một công trình nghiên cứu ứng dụng có hàm lượng công nghệ cao và giá trị thực tiễn sâu sắc. Bằng việc kết hợp nhuần nhuyễn các kiến trúc phần mềm tiên tiến nhất hiện nay như Domain-Driven Design, Clean Architecture, CQRS, gRPC, SignalR, Blazor WebAssembly và React Native, nhóm tác giả đã xây dựng thành công một nền tảng Telehealth hoàn chỉnh, ổn định và hiệu năng cao. Hệ thống không chỉ giải quyết triệt để bài toán cấp bách trong đại dịch mà còn mở ra hướng phát triển bền vững cho các giải pháp chăm sóc y tế từ xa tại Việt Nam trong tương lai.