Clinical AI · Bệnh viện Y học Cổ truyền TP.HCM
AI có thể suy luận. Nhưng không được tự trở thành nguồn sự thật.
Đây là bản giải thích tiếng Việt, tập trung vào câu hỏi mà manager, bác sĩ hoặc technical reviewer thường cần biết: hệ thống giữ authority ở đâu, LLM được phép làm gì, bằng chứng đi qua những bước nào, dữ liệu nào là canonical, multi-turn thất bại ra sao và khi nào một thay đổi đủ điều kiện để đưa lại cho bác sĩ kiểm thử.
Đọc trang này như thế nào
Đủ sâu để hiểu kiến trúc, không sâu đến mức lộ blueprint vận hành.
Atlas kỹ thuật nội bộ có nhiều góc nhìn và receipt kiểm chứng chi tiết hơn. Bản public này cố ý loại bỏ topology, tên máy, runbook, private corpus và implementation detail nhạy cảm. Những gì giữ lại là phần có giá trị nhất về mặt kiến trúc: authority, state, evidence, failure semantics và delivery boundary.
Bốn nguyên tắc nền
Tách reasoning khỏi truth, state và permission.
Nếu một hệ thống clinical AI không nói rõ bốn điều này, model rất dễ trở thành nơi “ôm” cả hiểu câu hỏi, business logic, source of truth và failure handling.
LLM không phải nguồn sự thật
Mô hình ngôn ngữ được dùng để hiểu câu hỏi và tổng hợp câu trả lời. Quyền quyết định dữ kiện lâm sàng, bằng chứng, quyền truy cập và trạng thái ứng dụng vẫn thuộc hệ thống.
Clinical logic phải kiểm chứng được
Những kiểm tra có tính quy tắc như tương tác thuốc, rà soát đơn và các clinical facts quan trọng được giữ trong các thành phần deterministic, thay vì giao cho model tự “suy đoán”.
Evidence đi cùng câu trả lời
Retrieval chỉ là bước lấy ứng viên. Trước khi phát hành câu trả lời, hệ thống còn phải giữ source scope, provenance, sufficiency và ràng buộc quyền truy cập.
Failure phải hiện đúng bản chất
Provider timeout, thiếu bằng chứng, lỗi quyền truy cập hay trạng thái chưa chắc chắn không được biến thành một câu trả lời trôi chảy nhưng sai ngữ nghĩa.
Public system cut
Một request đi qua các responsibility boundary, không đi thẳng vào model.
Sơ đồ dưới đây chỉ dùng tên trách nhiệm, không dùng tên service/package/vendor nội bộ.
- 01Clinician workspace
Câu hỏi, đơn thuốc, thảo dược, follow-up context và trạng thái hiển thị cho bác sĩ.
- 02Authenticated application boundary
Identity, permission, durable request/result state, idempotency và failure envelope.
- 03Clinical reasoning runtime
Hiểu mục tiêu, lập kế hoạch bounded và quyết định khi nào gọi clinical tool hay evidence research.
- 04Deterministic clinical tools
Tương tác thuốc, rà soát đơn và clinical facts có quy tắc được giữ ngoài LLM.
- 05Governed evidence layer
Source scope, provenance, retrieval candidates, sufficiency và conflict được chuẩn hóa trước synthesis.
- 06Grounded synthesis + publication gate
Model diễn đạt trên evidence đã được cho phép; verifier/policy quyết định có thể phát hành hay phải fail closed.
10 góc nhìn kiến trúc
Mỗi góc nhìn trả lời một câu hỏi quản lý khác nhau.
Đây là phần giải thích tương ứng với atlas kỹ thuật, nhưng đã được sanitize để public.
Tổng quan hệ thống
Từ câu hỏi của bác sĩ đến câu trả lời cuối cùng đi qua những lớp nào?
Clinician workspace gửi yêu cầu vào application boundary có xác thực. Runtime phân tích mục tiêu, gọi các công cụ lâm sàng hoặc research bị giới hạn, gom evidence, kiểm tra điều kiện phát hành rồi mới tổng hợp câu trả lời. Audit và trạng thái bền vững nằm ngoài model call.
Frontend / clinician workspace
UI có chỉ là một chat box không?
Không. UI phải giữ identity, conversation/task context, trạng thái đang xử lý, lỗi có kiểu rõ ràng, retry semantics và các dấu hiệu evidence cần cho bác sĩ. Mục tiêu là một workspace lâm sàng có thể hiểu được, không phải một cửa sổ chat “best effort”.
Backend contracts
Backend ngăn model “nuốt” hết business logic bằng cách nào?
Backend tách authority thành các contract: application state, access control, clinical tools, research/evidence, synthesis và publication gate. Model chỉ hoạt động qua các cổng đã định nghĩa; nó không tự ghi lại sự thật, tự bỏ qua quyền hay tự đánh dấu một turn là thành công.
Clinical AI reasoning
AI được linh hoạt ở đâu và bị khóa ở đâu?
AI được linh hoạt khi hiểu ý định, lập kế hoạch tìm kiếm và diễn đạt. Khi chạm đến clinical truth, deterministic checks, named evidence, quyền truy cập hoặc release policy, hệ thống chuyển sang contract chặt hơn. Nếu bằng chứng chưa đủ, hệ thống phải giữ được trạng thái “chưa đủ” thay vì bịa cho tròn câu.
Data governance
Dữ liệu nào là nguồn chuẩn, dữ liệu nào chỉ là bản dẫn xuất?
Durable application state và metadata được coi là canonical. Search index/vector representation chỉ là derived state để tăng tốc retrieval và phải có khả năng rebuild. Source objects, publication status và provenance được quản lý tách biệt để một index nhanh không vô tình trở thành nguồn sự thật.
Runtime / on-premise boundary
Thiết kế có phụ thuộc một nhà cung cấp model hay cloud cụ thể không?
Production boundary được thiết kế theo hướng local/on-premise và provider-portable. AI endpoints có thể thay đổi, nhưng application authority, clinical tools, evidence contract, state và audit không đổi theo model. Startup/health dependency cũng phải fail rõ ràng trước khi nhận workload.
Security & observability
Làm sao biết ai được xem gì và lỗi xảy ra ở đâu?
Identity và authorization được xử lý trước retrieval. Evidence scope phải tôn trọng quyền. Telemetry phân biệt provider failure, retrieval insufficiency, policy rejection và application error để vận hành không phải đoán từ một lỗi 500 chung chung.
Quality & release
Khi nào một thay đổi được coi là đủ an toàn để bác sĩ thử lại?
Một release cần đi qua test theo contract, clinical correctness checks, evidence/provenance checks và protected UAT. “Build xanh” chưa đủ nếu exact behavior ở clinician flow chưa được quan sát. Release acceptance phải gắn với bằng chứng kiểm thử cụ thể, không chỉ với việc deploy thành công.
Multi-turn resilience
Vì sao chat nhiều vòng dễ hỏng hơn một câu hỏi đơn?
Multi-turn kéo theo lineage, context projection, idempotency, timeout budget và replay semantics. Nếu những phần này không có authority rõ, một turn mới có thể dùng nhầm context, chạy lại side effect hoặc báo lỗi trong khi backend đã commit kết quả. Thiết kế vì vậy tách “attempt” khỏi “durable result”.
Turn lifecycle
Một turn tốt cần những trạng thái nào?
Nhận yêu cầu → xác thực và bind context → hiểu mục tiêu → chạy clinical/research tools có giới hạn → đánh giá evidence → synthesize → verify/publication gate → commit result và provenance. Nếu fail ở bất kỳ bước nào, failure identity phải còn nguyên để UI và operator biết chính xác điều gì xảy ra.
Turn lifecycle
Một câu trả lời tốt là kết quả của một chuỗi kiểm soát, không phải một model call.
Điểm quan trọng nhất: từng stage có semantics riêng. Retry ở transport không được làm clinical tool chạy lặp; provider timeout không được xóa durable result; thiếu evidence không được giả thành “model không biết”.
- 1Bind identity & context
Xác thực người dùng, workspace và task/conversation lineage trước khi reasoning.
- 2Understand the clinical intent
Phân loại mục tiêu và xác định câu hỏi cần clinical tool, research hay cả hai.
- 3Run bounded tools
Clinical logic deterministic và retrieval/research chạy qua contract có giới hạn.
- 4Build an evidence pack
Gom nguồn, provenance, scope, thiếu hụt và xung đột thay vì đưa raw search thẳng cho model.
- 5Synthesize with constraints
Model diễn đạt trên evidence đã được phép; không tự nâng derived state thành clinical truth.
- 6Verify before publish
Kiểm tra deterministic facts, evidence binding, policy và failure state trước khi phát hành.
- 7Commit durable result
Lưu trạng thái kết quả/provenance để retry hoặc reconnect không làm thay đổi semantics của turn đã hoàn tất.
Canonical vs derived
Search index giúp tìm nhanh. Nó không được quyền trở thành source of truth.
Canonical state là những gì hệ thống phải giữ bền vững và có thể audit: identity-scoped application state, publication metadata, task/conversation lineage và provenance.
Derived state là những representation phục vụ tìm kiếm hoặc tăng tốc. Chúng có thể rebuild từ nguồn đã quản trị. Nếu derived state mất hoặc lệch, hệ thống phải ưu tiên tính đúng của authority trước tốc độ retrieval.
Cách phân chia này giúp thay đổi embedding/model/index mà không làm thay đổi định nghĩa “dữ kiện nào là thật” trong application.
Failure semantics
Trong clinical AI, “không chắc chuyện gì vừa xảy ra” là một trạng thái cần thiết kế.
Timeout hoặc upstream error giữ nguyên identity thay vì bị biến thành câu trả lời rỗng hoặc success giả.
Không đủ nguồn hoặc có xung đột phải được phản ánh trong result, không được lấp bằng fluent synthesis.
Không có quyền truy cập không phải là “không tìm thấy dữ liệu”. Hai failure class phải tách biệt.
Nếu client mất kết nối gần lúc commit, retry phải tra durable result trước khi quyết định chạy lại.
Không công bố
Chi tiết nhạy cảm được giữ ngoài portfolio public.
- Dữ liệu bệnh nhân, bác sĩ hoặc corpus nội bộ.
- Prompt/system instruction và schema nội bộ chi tiết.
- Hostname, IP, port, network layout, machine identity hoặc runbook vận hành.
- Credential, secret, token, provider account state hoặc private release receipt.
- Raw architecture HTML/JSON có thể biến thành implementation blueprint.
Model có thể sở hữu phần diễn đạt. Nó không được âm thầm sở hữu truth, permission, evidence hay durable state.
Đó là nguyên tắc có thể tái sử dụng cho mọi hệ thống AI có hậu quả cao: clinical, finance, compliance hoặc enterprise operations.
Liên hệ / bản tiếng Anh