2.3. Yêu cầu nghiệp vụ

Hệ thống cần giải quyết đồng thời bốn yêu cầu:

1. Thu thập dữ liệu có cấu trúc: bản ghi phải có giá trị, đơn vị, thời gian và bối cảnh; dữ liệu sai định dạng, ở tương lai hoặc vượt giới hạn hợp lệ phải được phát hiện.
2. Theo dõi và cảnh báo an toàn: cảnh báo nguy hiểm phải hoạt động độc lập với LLM; quyết định của bác sĩ và ngưỡng an toàn luôn có mức ưu tiên cao nhất.
3. Hỗ trợ bằng AI có căn cứ: câu trả lời y khoa phải dựa trên kho tri thức được kiểm duyệt, có trích dẫn và biết từ chối khi vượt phạm vi.
4. Hỗ trợ bác sĩ, không thay thế bác sĩ: AI chỉ tổng hợp dữ liệu, chỉ ra xu hướng và gợi ý vấn đề cần xem xét; mọi quyết định điều trị vẫn thuộc về bác sĩ.

2.4. Mục tiêu của hệ thống

• Tăng tỷ lệ ghi nhận đầy đủ các lần đo theo kế hoạch.
• Giúp bệnh nhân hiểu xu hướng và biết khi nào cần liên hệ nhân viên y tế.
• Phát hiện đầy đủ các giá trị chạm ngưỡng cảnh báo đã cấu hình.
• Cung cấp nội dung tư vấn lối sống có nguồn và không vượt phạm vi an toàn.
• Giảm thời gian bác sĩ tổng hợp lịch sử và xác định bệnh nhân cần ưu tiên.
• Xây dựng một nền tảng có thể mở rộng từ pilot quy mô nhỏ sang triển khai thực tế sau khi được thẩm định lâm sàng.

3. Giải pháp kỹ thuật

3.1. Kiến trúc tổng thể

VDiab sử dụng kiến trúc modular monolith: các miền nghiệp vụ được tách thành module rõ ràng nhưng cùng chạy trong một backend FastAPI. Cách tiếp cận này phù hợp với giai đoạn MVP vì dễ triển khai, kiểm thử và truy vết giao dịch, đồng thời vẫn cho phép tách thành dịch vụ độc lập khi tải hệ thống tăng.

flowchart LR
    U[Patient / Doctor / Admin] --> FE[Next.js Web App]
    FE -->|HTTPS + JWT| API[FastAPI Backend]

    API --> AUTH[Auth & RBAC]
    API --> HEALTH[Health Records]
    API --> MED[Medication & Care Plan]
    API --> APPT[Appointments]
    API --> NOTI[Notifications]
    API --> AGENT[LangGraph AI Agent]

    HEALTH --> RULE[Danger Rules]
    HEALTH --> WATCH[Personalized WATCH Model]
    RULE --> DB[(PostgreSQL)]
    WATCH --> DB
    NOTI --> ZALO[Zalo Bot]

    AGENT --> DB
    AGENT --> RAG[ChromaDB / Approved Knowledge]
    AGENT --> LLM[OpenAI LLM]

3.2. Giao diện người dùng

Frontend được xây dựng bằng Next.js 16, React 19, TypeScript, Tailwind CSS và Ant Design. Giao diện được phân theo vai trò:

• Dashboard bệnh nhân hiển thị chỉ số gần đây, biểu đồ xu hướng và thông báo.
• Các màn hình riêng cho sức khỏe, bữa ăn, thuốc, lịch hẹn và trợ lý AI.
• Dashboard bác sĩ hiển thị danh sách bệnh nhân, trang chi tiết, ghi chú lâm sàng, mục tiêu chăm sóc, insight và AI Summary.
• Dashboard quản trị hỗ trợ quản lý người dùng và phân công bác sĩ–bệnh nhân.
• Thành phần giọng nói hỗ trợ nhập câu hỏi bằng STT và đọc phản hồi bằng TTS, giúp tăng khả năng tiếp cận cho người dùng lớn tuổi hoặc ít quen thao tác bàn phím.

3.3. Backend và dữ liệu nghiệp vụ

Backend sử dụng FastAPI, SQLModel và PostgreSQL 16. API được tổ chức theo các module:

Dữ liệu sức khỏe được kiểm tra ngay tại schema và service. Ví dụ, bản ghi đường huyết hỗ trợ mg/dL và mmol/L, kiểm tra thời gian tương lai, giá trị âm, đơn vị sai và giới hạn sinh lý bất hợp lệ. Quan hệ phân công được kiểm tra trước khi bác sĩ truy cập dữ liệu bệnh nhân.

3.4. Cơ chế cảnh báo hai tầng

VDiab tách cảnh báo khỏi LLM để tránh việc một lỗi AI làm mất cảnh báo y tế:

1. Tầng DANGER: luật cứng dựa trên ngưỡng do bác sĩ phê duyệt. Tầng này luôn được thực thi trước và luôn thắng kết quả ML.
2. Tầng WATCH: mô hình học máy ước lượng dải cảnh báo sớm cá nhân từ chuỗi glucose, bối cảnh bữa ăn và đặc trưng lâm sàng như tuổi, BMI, HbA1c, glucose đói và nhóm rủi ro.
3. Tầng NORMAL: chỉ được trả về khi số đo không chạm DANGER và không vượt dải WATCH.

Mô hình WATCH hiện sử dụng hướng tiếp cận dữ liệu bảng với HistGradientBoosting, có Logistic Regression làm baseline đối chiếu. Lựa chọn này phù hợp hơn deep learning trong bối cảnh số bệnh nhân còn nhỏ và nhãn WATCH được tạo từ luật. Hệ thống lưu ngưỡng dự đoán thấp/cao cùng phiên bản mô hình để truy vết.

Khi một bản ghi được đánh giá là WATCH, hệ thống tạo thông báo trong ứng dụng theo khóa idempotent để tránh gửi trùng. Nếu bệnh nhân đã liên kết Zalo và bật nhận tin, thông báo được đẩy qua Zalo theo cơ chế best-effort; lỗi Zalo không làm rollback bản ghi sức khỏe chính. Hệ thống cũng giới hạn số cảnh báo mỗi ngày nhằm giảm mệt mỏi vì thông báo.

3.5. Trợ lý AI và RAG

Một AI Agent duy nhất được xây dựng bằng LangGraph/LangChain để phục vụ hai luồng:

• AI Consultation: trả lời câu hỏi về lối sống, tự theo dõi và kiến thức đái tháo đường bằng tiếng Việt.
• AI Summary: tổng hợp dữ liệu bệnh nhân trong khoảng thời gian được chọn cho bác sĩ, nêu xu hướng, mức độ đầy đủ của dữ liệu và điểm cần xem xét.

Luồng xử lý được kiểm soát theo graph:

flowchart TD
    A[Request] --> B[Resolve identity and patient access]
    B --> C[Classify intent and plan response]
    C -->|Jailbreak| D[Refuse safely]
    C -->|High risk| E[Return emergency guidance]
    C -->|Out of scope| F[Decline and hand off]
    C -->|Summary / Personal data| G[Fetch authorized patient data]
    C -->|Knowledge question| H[Retrieve approved knowledge]
    G --> I[Check data quality]
    H --> I
    I --> J[Synthesize grounded answer]
    J --> K[Verify citations]
    K --> L[Output guardrail]
    L --> M[Response + sources + limitations]

Các lớp bảo vệ chính gồm:

• Kiểm tra quyền truy cập bệnh nhân trước khi lấy dữ liệu.
• Nhận diện jailbreak, tình huống nguy cơ cao và yêu cầu thay đổi điều trị trước khi gọi LLM.
• Chỉ đưa dữ liệu từ tool và đoạn tri thức truy xuất được vào bước tổng hợp.
• Xác minh lại trích dẫn sau khi sinh câu trả lời.
• Quét đầu ra để ngăn nội dung vượt phạm vi hoặc làm lộ chỉ dẫn hệ thống.
• Trả về data_used, sources và limitations để tăng khả năng giải thích.

3.6. Kho tri thức và pipeline RAG

Kho tri thức được lưu trong ChromaDB và tạo từ các tài liệu chuyên môn đã chọn, gồm hướng dẫn của Bộ Y tế, bệnh viện và nguồn quốc tế. Pipeline ingestion chia tài liệu thành đoạn, gắn metadata như tên tài liệu, tổ chức, mục/section, trang, URL nguồn, phiên bản corpus và hash nội dung.

Thiết kế hai tầng giúp cân bằng độ tin cậy và độ phủ:

• Tầng 1: các nội dung đã được tuyển chọn, tóm tắt và gắn vị trí trích dẫn cụ thể.
• Tầng 2: nội dung rộng hơn từ tài liệu gốc, được chunk theo cấu trúc heading, trang và đoạn văn.

Hash nội dung và manifest giúp ingestion có tính idempotent, hỗ trợ cập nhật tài liệu mà không tạo vector trùng. Khi các nguồn mâu thuẫn, hệ thống ưu tiên thể hiện sự khác biệt và chuyển cho người có chuyên môn xem xét thay vì tự lựa chọn một kết luận y khoa.

3.7. Bảo mật và an toàn

• Xác thực bằng JWT và mật khẩu băm bằng bcrypt.
• Phân quyền theo vai trò và kiểm tra quan hệ bác sĩ–bệnh nhân ở lớp service/dependency.
• Middleware phát hiện mẫu SQL injection; truy vấn dữ liệu sử dụng ORM/tham số hóa.
• Giới hạn CORS theo cấu hình môi trường; bí mật được truyền qua biến môi trường.
• Ghi log lỗi và hỗ trợ LangSmith tracing cho luồng AI.
• Tách rule cảnh báo khỏi LLM; timeout hoặc lỗi AI không làm mất luồng ghi nhận và cảnh báo chính.
• Duy trì lịch sử thuốc, mục tiêu chăm sóc và nguồn dữ liệu phục vụ audit.

Để triển khai với dữ liệu bệnh nhân thật, hệ thống vẫn cần hoàn thiện consent, mã hóa dữ liệu lưu trữ và truyền tải, quản lý vòng đời dữ liệu, nhật ký audit bất biến, quy trình phản ứng sự cố và đánh giá tuân thủ pháp luật về dữ liệu sức khỏe.

3.8. Triển khai và vận hành

Hệ thống hỗ trợ Docker/Docker Compose:

• Frontend Next.js.
• Backend FastAPI chạy trên Uvicorn.
• PostgreSQL lưu dữ liệu giao dịch.
• ChromaDB lưu vector cục bộ qua volume.
• STT và TTS có thể chạy như dịch vụ riêng tùy cấu hình phần cứng.

GitHub Actions, pytest, coverage và bộ evaluation riêng hỗ trợ kiểm soát chất lượng. Kiến trúc hiện tại đủ đơn giản để chạy pilot trên một máy chủ, nhưng vẫn có đường tách worker nền, vector database và dịch vụ AI khi quy mô tăng.

4. Tính khả thi

4.1. Khả thi về công nghệ

Mức khả thi kỹ thuật của MVP là cao vì các thành phần cốt lõi đã có mã triển khai và dùng công nghệ phổ biến:

• FastAPI, PostgreSQL và Next.js có hệ sinh thái trưởng thành, dễ đóng gói và triển khai.
• LangGraph phù hợp với luồng AI nhiều bước cần kiểm soát, retry và guardrail.
• RAG cho phép dùng tài liệu được duyệt thay vì phụ thuộc hoàn toàn vào kiến thức sẵn có của LLM.
• Rule engine độc lập và nguyên tắc DANGER ưu tiên giúp giảm rủi ro từ mô hình xác suất.
• ChromaDB embedded và modular monolith tiết kiệm chi phí vận hành ở quy mô pilot.
• STT/TTS được tách dịch vụ nên có thể bật hoặc tắt mà không ảnh hưởng chức năng cốt lõi.

4.2. Khả thi về dữ liệu

Repo có bộ dữ liệu demo được xây dựng từ NHANES và dữ liệu mô phỏng 60 ngày. Pipeline WATCH ghi nhận 489 bệnh nhân đái tháo đường típ 2 và 100.470 phép đo glucose synthetic, đủ để xây dựng prototype, kiểm tra pipeline và mô phỏng cảnh báo.

Tuy nhiên, dữ liệu này không phải dữ liệu lâm sàng thực tế tại Việt Nam. Nhãn WATCH phần lớn là weak label sinh từ luật; một số đặc trưng tĩnh chỉ có một snapshot; dữ liệu tự đo khoảng 3,4 lần/ngày không tương đương CGM liên tục. Vì vậy mô hình hiện phù hợp cho nghiên cứu, demo và shadow mode, chưa đủ bằng chứng để tự động tác động đến điều trị thực tế.

4.3. Khả thi về kiểm thử

Bằng chứng gần nhất được lưu trong repo ngày 27/08/2026 ghi nhận:

• 462 test passed, 0 failed.
• 90,2% line coverage và 73,2% branch coverage.
• Retrieval exact-hit/context recall khoảng 0,679.
• Guardrail so với nhãn kỳ vọng đạt 1,000; LLM judge so với kỳ vọng đạt 0,812.
• Agent trajectory/routing đạt 10/10.
• Personal-data faithfulness đạt 4/4 sau khi sửa regression.
• Agent E2E qua HTTP đạt 25/38; 13 trường hợp còn lại liên quan đến trích dẫn lệch nguồn đã biết.
• Độ trễ AI trung bình khoảng 6 giây, nhưng p95 13,6–16,1 giây, chưa đạt mục tiêu PRD là không quá 10 giây.

Cần lưu ý artifact evaluation tổng hợp ngày 27/08 vẫn ghi F2 production rule engine là chưa triển khai, trong khi mã nguồn hiện tại đã có threshold_service, đánh giá WATCH/DANGER và test tương ứng. Đây là dấu hiệu artifact đánh giá chưa được tái sinh sau thay đổi mã nguồn, không nên dùng artifact cũ để tuyên bố nghiệm thu F2. Trước khi demo hoặc phát hành, cần chạy lại toàn bộ test/evaluation và tạo báo cáo thống nhất từ cùng một commit.

4.4. Khả thi về vận hành và chi phí

Pilot 5–10 bệnh nhân và 1–2 bác sĩ có thể vận hành với một backend, một PostgreSQL và vector store cục bộ. Chi phí biến đổi chủ yếu đến từ:

• Lượt gọi LLM và embedding.
• Hạ tầng chạy backend/database.
• Máy chủ GPU nếu tự host STT/TTS chất lượng cao.
• Chi phí và hạn mức gửi tin của kênh Zalo.
• Nhân lực kiểm duyệt tài liệu, đánh giá câu trả lời và hỗ trợ người dùng.

Có thể kiểm soát chi phí bằng cache, giới hạn context, chỉ gọi LLM khi cần, dùng rule deterministic cho tình huống an toàn và tách STT/TTS thành tính năng tùy chọn.

4.5. Khả thi về nghiệp vụ và pháp lý

Giải pháp phù hợp để pilot có giám sát, nhưng chưa nên triển khai đại trà như một công cụ y tế đã được xác nhận. Các điều kiện tối thiểu trước pilot gồm:

1. Phỏng vấn và kiểm chứng nhu cầu với bệnh nhân, người chăm sóc và bác sĩ nội tiết.
2. Bác sĩ duyệt bộ ngưỡng, nội dung hành động, corpus RAG và bộ tình huống đánh giá.
3. Có quy trình consent, phân quyền, thu hồi quyền, lưu vết và xử lý sự cố dữ liệu.
4. Làm rõ trách nhiệm khi cảnh báo bị bỏ lỡ, kênh liên hệ và thông điệp “không giám sát 24/7”.
5. Chạy shadow mode trước khi WATCH ảnh hưởng tới người dùng thật.
6. Thực hiện đánh giá bảo mật và đánh giá tác động bảo vệ dữ liệu cá nhân.

4.6. Kết luận khả thi

5. Hướng phát triển

5.1. Ngắn hạn — hoàn thiện MVP và pilot

• Chạy lại toàn bộ test, WATCH gate, agent E2E và RAGAS trên cùng commit; sinh lại evaluation evidence.
• Sửa các trường hợp trích dẫn lệch nguồn, nâng citation coverage và retrieval recall.
• Giảm độ trễ p95 của AI bằng cache retrieval, tối ưu prompt/context, chạy song song các tool độc lập và đặt timeout/fallback rõ ràng.
• Hoàn thiện giao diện bác sĩ để tạo, duyệt và version hóa ngưỡng/care plan thay vì chỉ backfill bằng script.
• Bổ sung audit log đầy đủ cho việc xem và sửa dữ liệu nhạy cảm.
• Hoàn thiện consent, chính sách lưu/xóa dữ liệu và quy trình liên kết/hủy liên kết Zalo.
• Tổ chức clinician review cho câu trả lời AI, cảnh báo và AI Summary.

5.2. Trung hạn — tăng độ tin cậy và cá nhân hóa

• Chạy WATCH ở shadow mode trên dữ liệu thực, so sánh với đánh giá bác sĩ trước khi gửi cảnh báo cho bệnh nhân.
• Thu thập phản hồi trên từng cảnh báo để đo false positive, false negative và alert fatigue.
• Hiệu chỉnh mô hình theo nhóm tuổi, mức HbA1c, nguy cơ hạ đường huyết và chất lượng dữ liệu.
• Bổ sung cờ thiếu dữ liệu và cơ chế fallback an toàn cho bệnh nhân mới chưa có đủ lịch sử.
• Version hóa snapshot lâm sàng và care plan theo thời gian để tránh dùng thông tin tương lai hoặc dữ liệu hết hiệu lực.
• Xây dựng quy trình quản trị mô hình: model registry, phê duyệt, canary/shadow deployment, drift monitoring và rollback.
• Mở rộng corpus, theo dõi ngày hiệu lực và tự động đánh dấu tài liệu cần chuyên gia duyệt lại.

5.3. Dài hạn — mở rộng nền tảng

• Tích hợp máy đo đường huyết, CGM và thiết bị đeo qua chuẩn API phù hợp; phân biệt rõ SMBG rời rạc với dữ liệu CGM liên tục.
• Bổ sung vai trò người chăm sóc với consent chi tiết và quyền truy cập có thời hạn.
• Xây dựng hàng đợi sự kiện và worker nền cho cảnh báo, nhắc lịch, ingestion và tác vụ AI dài.
• Tách vector database, notification service và AI worker khi lưu lượng tăng; sử dụng Redis/queue cho cache và retry.
• Hỗ trợ báo cáo PDF, dashboard quần thể và theo dõi kết quả pilot theo cohort.
• Nghiên cứu dự báo xu hướng, nhưng chỉ đưa vào sử dụng sau khi có dữ liệu dọc thực tế và đánh giá lâm sàng.
• Tích hợp với hệ thống bệnh viện/EHR bằng chuẩn trao đổi dữ liệu y tế phù hợp khi có thỏa thuận và cơ sở pháp lý.

5.4. Lộ trình đề xuất

6. Giá trị nổi bật của giải pháp

Điểm khác biệt của VDiab không nằm ở việc thêm một chatbot vào ứng dụng sức khỏe, mà ở cách kết hợp bốn lớp thành một luồng thống nhất:

1. Dữ liệu sức khỏe có cấu trúc và có ngữ cảnh.
2. Cảnh báo deterministic và ML cá nhân hóa nhưng không ghi đè quyết định bác sĩ.
3. AI Agent có RAG, phân quyền, trích dẫn và guardrail.
4. Dashboard hỗ trợ bác sĩ theo dõi liên tục giữa các kỳ tái khám.

Nhờ đó, hệ thống có thể tạo giá trị ngay ở quy mô MVP, đồng thời duy trì ranh giới an toàn cần thiết cho một sản phẩm xử lý dữ liệu sức khỏe. Hướng đi phù hợp nhất là triển khai pilot có giám sát, đo lường bằng dữ liệu thực và chỉ mở rộng các chức năng dự báo hoặc tự động hóa sau khi có đủ bằng chứng lâm sàng, bảo mật và pháp lý.