Vì vậy, VMEC-05 không giao quyết định về trạng thái Critical cho LLM.

3. Giải pháp

LumiLab được thiết kế theo nguyên tắc:

The LLM explains. The system decides.

Hệ thống tách rõ những phần cần tính tất định khỏi những phần phù hợp với mô hình ngôn ngữ.

3.1. Phần hệ thống quyết định

Các tác vụ có yêu cầu tính ổn định và khả năng kiểm chứng được xử lý bằng logic deterministic:

• chuẩn hóa tên chỉ số;
• xử lý alias;
• chuẩn hóa đơn vị;
• chọn khoảng tham chiếu;
• phân loại LOW / NORMAL / HIGH;
• phát hiện giá trị Critical;
• fail-closed với dữ liệu không được hỗ trợ.

3.2. Phần AI đảm nhiệm

LLM chủ yếu chịu trách nhiệm:

• diễn giải kết quả bằng ngôn ngữ dễ hiểu;
• tổng hợp thông tin theo ngữ cảnh;
• trình bày kết quả dưới dạng hội thoại;
• hỗ trợ tạo câu hỏi gợi ý để bệnh nhân trao đổi với bác sĩ.

LLM không sở hữu quyết định về ngưỡng Critical và không được tự thay đổi các trạng thái do deterministic engine tạo ra.

4. Kiến trúc xử lý

VMEC-05 không hoạt động theo mô hình đơn giản:

Prompt → LLM → Response

Thay vào đó, hệ thống sử dụng một pipeline có kiểm soát:

Lab Report / Manual Input
        │
        ▼
OCR / Parser
        │
        ▼
Human Review Gate
        │
        ▼
Canonicalization + Unit Handling
        │
        ├──────────────┐
        ▼              ▼
Reference Range     Critical
Checker             Detector
        │              │
        └──────┬───────┘
               ▼
         Structured Facts
               │
               ▼
          RAG Retrieval
               │
               ▼
          LLM Analyzer
               │
               ▼
      Generate Doctor Questions
               │
               ▼
      Medical Safety Guardrail
               │
               ▼
         Structured Output

5. Các lớp chính của hệ thống

5.1. Input & OCR

Người dùng có thể nhập dữ liệu xét nghiệm hoặc sử dụng ảnh phiếu xét nghiệm.

Khi OCR được sử dụng, hệ thống không tự động đưa dữ liệu OCR thẳng vào bước phân tích.

Luồng xử lý gồm:

1. đọc ảnh;
2. trích xuất dữ liệu;
3. đưa kết quả OCR về giao diện review;
4. yêu cầu người dùng xác nhận;
5. chỉ sau khi xác nhận mới tiếp tục pipeline.

Đây là cơ chế Human-in-the-Loop nhằm giảm rủi ro từ lỗi đọc ảnh.

5.2. Canonicalization & Unit Handling

Tên xét nghiệm trong thực tế có thể xuất hiện dưới nhiều dạng khác nhau.

Ví dụ:

• tên đầy đủ;
• tên viết tắt;
• alias;
• ký hiệu thường dùng trên phiếu xét nghiệm.

Hệ thống canonicalize các tên này về một định danh chuẩn trước khi xử lý tiếp.

Đơn vị đo cũng được chuẩn hóa để tránh việc so sánh trực tiếp giữa những giá trị không cùng đơn vị.

Nếu không xác định được mapping an toàn, hệ thống ưu tiên fail-closed thay vì suy đoán.

5.3. Reference Range Checker

Reference Range Checker chịu trách nhiệm phân loại trạng thái tham chiếu.

Kết quả chính:

LOW
NORMAL
HIGH
UNKNOWN / UNSUPPORTED

Checker xử lý các yếu tố như:

• giới tính;
• độ tuổi;
• đơn vị;
• alias;
• boundary semantics;
• các rule có điều kiện;
• trường hợp thiếu dữ liệu.

Đây là deterministic component, không sử dụng LLM để quyết định trạng thái.

5.4. Critical Detector

Critical Detector được tách riêng khỏi Reference Range Checker.

Lý do:

Abnormal ≠ Critical

Critical Detector chỉ kích hoạt khi:

• analyte nằm trong phạm vi được hỗ trợ;
• có critical rule đang active;
• dữ liệu đủ để áp dụng rule;
• đơn vị có thể xử lý an toàn;
• điều kiện ngưỡng được thỏa mãn.

Nếu không có rule phù hợp, hệ thống không tự lấy threshold từ nguồn khác để lấp khoảng trống.

VMEC-05 áp dụng nguyên tắc:

Không có authority phù hợp → không kích hoạt Critical rule.

6. Medical Knowledge Base và RAG

LumiLab sử dụng một lớp tri thức y khoa riêng để hỗ trợ phần diễn giải.

Knowledge layer bao gồm:

• curated medical content;
• metadata;
• chunked knowledge;
• vector retrieval;
• fallback đã được kiểm soát.

RAG được sử dụng để cung cấp context cho LLM trước khi sinh nội dung giải thích.

Điều quan trọng là:

RAG không biến LLM thành một hệ thống deterministic.

Do đó, output của LLM vẫn được đưa qua các lớp kiểm soát độc lập sau khi sinh.

7. LLM Analyzer

LLM Analyzer nhận:

• trạng thái đã được hệ thống xác định;
• dữ liệu xét nghiệm đã chuẩn hóa;
• context y khoa được truy xuất;
• các constraint an toàn.

LLM được sử dụng để biến dữ liệu kỹ thuật thành lời giải thích thân thiện hơn với bệnh nhân.

Ví dụ về vai trò phù hợp của LLM:

• giải thích WBC là gì;
• giải thích vì sao một chỉ số đang ngoài khoảng tham chiếu;
• diễn đạt lại thông tin y khoa bằng tiếng Việt dễ hiểu;
• tổng hợp một nhóm kết quả;
• giải thích xu hướng khi có đủ dữ liệu lịch sử.

LLM không được sử dụng để tự quyết định:

• bệnh nhân mắc bệnh gì;
• nguyên nhân cá nhân của kết quả bất thường;
• thuốc cần dùng;
• điều trị cần thực hiện;
• một giá trị có phải Critical hay không.

8. Doctor Questions Generator

Sau khi phân tích kết quả, hệ thống có thể tạo các câu hỏi gợi ý để bệnh nhân trao đổi với bác sĩ.

Mục tiêu không phải đưa ra lời khuyên điều trị, mà giúp bệnh nhân chuyển từ:

“Bác sĩ ơi, kết quả này có sao không?”

sang các câu hỏi cụ thể hơn như:

• Chỉ số này cần được theo dõi lại khi nào?
• Có cần kiểm tra thêm xét nghiệm nào không?
• Sự thay đổi này có đáng chú ý khi so với kết quả trước không?
• Tôi cần cung cấp thêm thông tin nào để bác sĩ đánh giá kết quả tốt hơn?

9. Conversational Orchestrator

VMEC-05 sử dụng Orchestrator để điều phối hội thoại và quyết định luồng xử lý phù hợp.

Các loại tác vụ có thể bao gồm:

• giải thích một chỉ số;
• tóm tắt toàn bộ phiếu xét nghiệm;
• xem lịch sử;
• phân tích xu hướng;
• trả lời câu hỏi trong phạm vi hỗ trợ;
• từ chối hoặc chuyển hướng các yêu cầu vượt giới hạn.

Output cuối cùng không chỉ là một đoạn text tự do.

Một phần cấu trúc phản hồi được server kiểm soát để giữ ranh giới giữa:

• dữ liệu;
• trạng thái;
• intent;
• suggested actions;
• nội dung ngôn ngữ do LLM tạo ra.

10. Safety by Design

Một trong những thay đổi quan trọng nhất của dự án đến từ quá trình kiểm thử V0.1.

Ban đầu, nhóm sử dụng prompt để yêu cầu model:

• không chẩn đoán;
• không kê đơn;
• không suy đoán nguyên nhân;
• không vượt phạm vi giáo dục sức khỏe.

Tuy nhiên, quá trình kiểm thử cho thấy prompt-level safety một mình không đủ.

LLM vẫn có thể tạo ra các dạng output vượt khỏi boundary mong muốn.

Điều này dẫn đến một thay đổi kiến trúc quan trọng:

Prompt-based Safety
        ↓
Observed Failures
        ↓
Root-cause Analysis
        ↓
Independent Validator
        ↓
Server-controlled Contract
        ↓
Regression Testing

Các lớp safety hiện tại

Layer 1 — Prompt Contract

Định nghĩa rõ phạm vi được phép của LLM.

Layer 2 — Deterministic Medical Rules

Các quyết định quan trọng như classification và Critical Detection không phụ thuộc LLM.

Layer 3 — Medical Safety Validator

Output được kiểm tra độc lập nhằm phát hiện các dạng nội dung bị cấm hoặc vượt boundary.

Layer 4 — Server / UI Control

Các phần quan trọng của response contract được hệ thống kiểm soát trước khi hiển thị cho bệnh nhân.

11. Fail-Closed Behavior

Fail-closed là nguyên tắc xuyên suốt của VMEC-05.

Khi hệ thống không đủ thông tin để đưa ra một quyết định an toàn, hệ thống không cố “đoán”.

Ví dụ:

• analyte chưa được approve;
• không có reference rule phù hợp;
• không có critical rule phù hợp;
• đơn vị không thể normalize an toàn;
• tên chỉ số không thể canonicalize chắc chắn;
• dữ liệu OCR chưa được người dùng xác nhận.

Trong những trường hợp đó, hệ thống ưu tiên:

UNKNOWN
UNSUPPORTED
NEED_REVIEW

thay vì đưa ra kết luận không có authority.

12. Phạm vi dữ liệu hiện tại

VMEC-05 quản lý các lớp coverage độc lập thay vì dùng một con số chung để mô tả toàn bộ khả năng hệ thống.

Runtime Catalog

Các analyte được phép đi qua runtime được quản lý bằng trạng thái rõ ràng như:

APPROVED
UNSUPPORTED
HOLD

Medical Knowledge Base

Knowledge Base có phạm vi rộng hơn runtime catalog vì một analyte có thể đã có nội dung giải thích nhưng chưa được phép tham gia toàn bộ deterministic pipeline.

Critical Rules

Critical rule là một phạm vi độc lập khác.

Một analyte có mặt trong knowledge base hoặc reference catalog không có nghĩa rằng nó tự động có critical threshold đang hoạt động.

Cách tổ chức này giúp tránh việc đánh đồng:

Có knowledge
≠
Được runtime hỗ trợ
≠
Có critical rule

13. History và Trend Analysis

Ngoài việc phân tích một phiếu xét nghiệm đơn lẻ, hệ thống còn hỗ trợ theo dõi dữ liệu theo thời gian.

History

Bệnh nhân có thể xem lại các kết quả trước đó thay vì mỗi lần phân tích lại từ đầu.

Trend Analysis

Khi có đủ dữ liệu lịch sử, hệ thống có thể:

• xác định chiều hướng thay đổi;
• đặt giá trị hiện tại trong bối cảnh các lần trước;
• giải thích xu hướng bằng ngôn ngữ dễ hiểu;
• hỗ trợ xem từng chỉ số;
• hỗ trợ xem các chỉ số trong cùng nhóm chức năng.

Mục tiêu của tính năng trend không phải dự đoán bệnh, mà giúp bệnh nhân hiểu:

Chỉ số đang thay đổi như thế nào theo thời gian?

14. Trải nghiệm người dùng

Luồng trải nghiệm chính của bệnh nhân:

Nhận phiếu xét nghiệm
        ↓
Nhập dữ liệu / tải ảnh
        ↓
Xác nhận dữ liệu OCR
        ↓
Nhận classification
        ↓
Nhận cảnh báo Critical nếu có
        ↓
Đọc giải thích
        ↓
Xem nguồn / context
        ↓
Nhận câu hỏi gợi ý
        ↓
Trao đổi với bác sĩ

Ngoài luồng phân tích chính, giao diện bệnh nhân còn hướng đến các nhóm chức năng như:

• phân tích kết quả xét nghiệm;
• lịch sử kết quả;
• xu hướng chỉ số;
• hồ sơ cá nhân.

15. Công nghệ

Frontend

• Next.js
• React
• TypeScript
• Tailwind CSS
• Recharts

Backend

• FastAPI
• Python
• Pydantic
• LangGraph

AI / Retrieval

• LLM Analyzer
• Vision OCR
• Embedding model
• ChromaDB
• RAG
• Curated fallback

Data & Infrastructure

• relational database;
• authentication;
• Docker;
• frontend deployment;
• backend deployment.

Kiến trúc được tổ chức để các layer có thể thay đổi độc lập mà không làm mất boundary giữa deterministic logic và generative AI.

16. Quá trình phát triển

VMEC-05 không được xây dựng theo hướng “làm xong một lần rồi demo”.

Quá trình phát triển diễn ra theo vòng lặp:

Build
  ↓
Test
  ↓
Break
  ↓
Trace Failure
  ↓
Root-cause Analysis
  ↓
Fix Architecture / Contract
  ↓
Regression Test
  ↓
Refine

Một số thay đổi quan trọng xuất phát trực tiếp từ quá trình kiểm thử:

• tách Critical Detector khỏi logic abnormal;
• tăng cường unit handling;
• canonicalize aliases;
• áp dụng fail-closed;
• thêm Human-in-the-Loop cho OCR;
• bổ sung safety validator độc lập;
• siết response contract;
• cải thiện conversational orchestration;
• xử lý các soft failure trong response composition;
• mở rộng history và trend analysis.

Do đó, nhiều thành phần hiện tại không xuất hiện vì “kiến trúc đẹp hơn”, mà vì một failure thực tế đã chứng minh chúng cần tồn tại.

17. Kiểm thử

VMEC-05 được kiểm tra ở nhiều lớp thay vì chỉ thử một vài giá trị LOW / NORMAL / HIGH.

Reference Range Checker

Các nhóm kiểm thử bao gồm:

• classification;
• boundary semantics;
• demographic selection;
• unit handling;
• canonicalization;
• alias safety;
• fail-closed behavior.

Critical Detector

Các nhóm kiểm thử tập trung vào:

• critical threshold;
• comparison operators;
• unit conversion;
• distinction giữa abnormal và critical;
• inactive rule behavior;
• fail-closed;
• unsupported analytes.

Orchestrator

Kiểm tra:

• intent routing;
• safety boundary;
• history;
• trend;
• unsupported capabilities;
• response composition.

Safety

Safety evaluation được thực hiện độc lập với quality evaluation.

Hệ thống kiểm tra các dạng vi phạm như:

• diagnosis;
• treatment recommendation;
• causal assertion;
• hallucinated patient facts;
• unsafe escalation;
• vượt phạm vi hỗ trợ.

Response Quality

Ngoài safety, nhóm còn đánh giá riêng chất lượng câu trả lời để phát hiện:

• phản hồi quá chung chung;
• thiếu grounding;
• conversational depth chưa đủ;
• placeholder response;
• thiếu câu hỏi bác sĩ;
• giải thích chưa đủ ngữ cảnh.

Điểm quan trọng là:

Một response có thể an toàn nhưng vẫn chưa đủ tốt.

Vì vậy safety và response quality được theo dõi bằng hai nhóm evaluation riêng.

18. Giá trị đối với bệnh nhân

Trước LumiLab

Phiếu xét nghiệm
    ↓
Các con số và ký hiệu
    ↓
Thiếu ngữ cảnh
    ↓
Tự tìm kiếm thông tin
    ↓
Không biết điều gì cần ưu tiên

Với LumiLab

Phiếu xét nghiệm
    ↓
Dữ liệu được chuẩn hóa
    ↓
Phân loại có cấu trúc
    ↓
Giải thích có ngữ cảnh
    ↓
Nhận biết điều cần chú ý
    ↓
Chuẩn bị câu hỏi cho bác sĩ

19. Giá trị đối với bác sĩ

LumiLab không cố thay thế quá trình đánh giá lâm sàng.

Mục tiêu của hệ thống là hỗ trợ giai đoạn trước cuộc trao đổi chuyên môn.

Bệnh nhân có thể đến buổi tư vấn với:

• hiểu biết cơ bản về chỉ số;
• nhận thức rõ hơn về mức độ ưu tiên;
• lịch sử dữ liệu có cấu trúc;
• xu hướng được trình bày rõ hơn;
• câu hỏi cụ thể hơn.

Quyết định chẩn đoán và điều trị vẫn thuộc về bác sĩ.

20. Ranh giới sản phẩm

VMEC-05 được định vị là:

Health Education & Decision-Support Preparation Tool

không phải:

• AI doctor;
• hệ thống chẩn đoán tự động;
• công cụ kê đơn;
• clinical decision engine thay thế bác sĩ.

Các boundary chính:

Không chẩn đoán
Không kê đơn
Không suy đoán nguyên nhân cá nhân
Không tự tạo critical threshold
Không vượt qua unsupported scope
Không bỏ qua Human Review khi OCR cần xác nhận

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

Các bước tiếp theo tập trung vào việc cải thiện những gap được phát hiện trong quá trình evaluation và sử dụng thực tế.

Các hướng chính gồm:

• cải thiện response composition;
• tăng conversational depth;
• tăng chất lượng grounding;
• làm rõ citation và provenance;
• mở rộng analyte catalog theo quy trình review;
• tiếp tục cải thiện OCR trên dữ liệu thực tế;
• tăng khả năng phân tích longitudinal;
• hoàn thiện experience cho history và trend;
• mở rộng workflow cho bác sĩ khi authorization model đủ rõ;
• tiếp tục regression testing sau mọi thay đổi safety.

Nguyên tắc mở rộng vẫn giữ nguyên:

Không mở rộng capability nếu boundary và authority chưa được xác định rõ.

22. Kết luận

LumiLab không thay thế bác sĩ.

LumiLab được xây dựng để lấp khoảng trống giữa:

“Bệnh nhân nhận được kết quả”

và:

“Bệnh nhân hiểu điều gì đáng chú ý trước khi gặp bác sĩ”

Giá trị cốt lõi của VMEC-05 không nằm ở việc đưa thêm AI vào một phiếu xét nghiệm.

Giá trị nằm ở việc xác định rõ:

• phần nào cần deterministic;
• phần nào cần retrieval;
• phần nào AI được phép diễn giải;
• phần nào phải bị chặn;
• và khi nào hệ thống phải thừa nhận rằng mình không biết.

Understand the numbers.
Recognize what matters.
Ask better questions.