2.2. Kiến trúc xử lý — pipeline 6 bước (LangGraph)

Tài liệu đầu vào được trích xuất qua 4 pipeline theo định dạng (PDF text bằng pypdf + regex xác định, ảnh scan bằng vision LLM, JSON theo chuẩn FHIR-like, CSV sinh hiệu), sau đó đi qua một StateGraph gồm 6 node xử lý tuần tự:

1. Identity Matcher — đối chiếu tên (đã chuẩn hoá tiếng Việt, bỏ dấu), năm sinh, giới tính giữa các tài liệu và hồ sơ ca bệnh. Nếu lệch → dừng cứng (hard-stop) ngay lập tức, không xử lý tiếp. Đây là cơ chế ngăn chặn rủi ro nghiêm trọng nhất: trộn nhầm hồ sơ hai bệnh nhân khác nhau.
2. Fact Extractor — gom dữ kiện lâm sàng (chẩn đoán, thuốc, dị ứng, dặn dò) từ kết quả trích xuất, mỗi dữ kiện gắn kèm citation trỏ về tài liệu và trích đoạn gốc.
3. Conflict Checker — 5 lớp kiểm tra: xung đột dị ứng với thuốc (mức ưu tiên cao nhất), mâu thuẫn tiến triển chẩn đoán giữa các lần khám, cảnh báo thuốc đối với bệnh, đối chiếu đơn thuốc giữa các nguồn khác nhau, và gắn cờ thông tin còn thiếu.
4. Summary Composer — tổng hợp dữ kiện đã kiểm chứng thành bản tóm tắt có cấu trúc gồm 4 mục cố định: vấn đề chính hiện tại, bệnh nền, thuốc/kế hoạch điều trị đang dùng, và mục xung đột/thiếu thông tin.
5. Policy Verifier — một bước kiểm tra độc lập với bước soạn thảo: xác nhận mọi thông tin quan trọng đều có ít nhất một trích dẫn hợp lệ (có trích đoạn và tên tài liệu cụ thể) trước khi cho phép trình lên bác sĩ; tính toán tỷ lệ grounding của toàn bộ bản tóm tắt.
6. Finalizer — quyết định trạng thái cuối cùng của ca: bị chặn do lệch danh tính, cần bác sĩ xử lý thêm (còn cảnh báo mở), hoặc sẵn sàng để bác sĩ rà soát.

2.3. Cổng an toàn trước khi được phép duyệt (Approval Gate)

Trước khi một bản tóm tắt được coi là "Đã duyệt" và được phép xuất file, hệ thống thực hiện 7 lớp kiểm tra bắt buộc: ca bệnh phải tồn tại và không bị chặn; bác sĩ phải xác nhận đã đọc disclaimer; bản đang duyệt phải là bản mới nhất; kiểm tra concurrency để tránh duyệt nhầm phiên bản cũ; bước Policy Verifier phải đạt; và không còn bất kỳ cảnh báo an toàn nào (kể cả mức P1) đang ở trạng thái mở. Chỉ khi vượt qua toàn bộ 7 lớp này, file PDF/JSON có watermark mới được phép xuất ra.

2.4. Nền tảng kỹ thuật đã triển khai

• Backend: Python 3.11, FastAPI, LangGraph + LangChain điều phối pipeline, SQLAlchemy 2.0.
• Trích xuất tài liệu: pypdf cho PDF văn bản; GPT-4o-mini (vision) cho ảnh scan đơn thuốc, prompt tiếng Việt trả về JSON có cấu trúc.
• Bảo mật & phân quyền: Xác thực JWT, mật khẩu băm bằng Argon2id, hai vai trò Doctor/Admin, phân quyền truy cập theo ca bệnh đã được phân công cho từng bác sĩ (case assignment), admin không được tự nâng quyền cho chính mình.
• Truy vết & tuân thủ: Audit log append-only (không thể sửa/xoá) ghi lại mọi thao tác Edit/Resolve/Approve/Reject kèm actor, thời điểm và phiên bản.
• Frontend: React 19 trên nền vinext/Vite, Tailwind CSS, giao diện xem tóm tắt kèm panel nguồn gốc tương tác.
• Hạ tầng: Docker (multi-stage, non-root user), CI/CD tự động qua GitHub Actions (lint + test trên mọi thay đổi mã nguồn).

3. Tính khả thi

MediSum không dừng lại ở ý tưởng, MediSum đã được xây dựng, kiểm thử và triển khai thật.

3.1. Chất lượng kỹ thuật đã được xác thực

• Toàn bộ vòng đời một ca bệnh (tạo ca → upload → trích xuất → tổng hợp → duyệt → xuất file → audit trail) được kiểm thử tự động đầu-cuối (end-to-end test).
• Pipeline CI/CD (GitHub Actions) chạy lint và test tự động trên mọi thay đổi mã nguồn được đẩy lên nhánh chính.
• Hệ thống đã được triển khai và đang chạy trực tuyến, có thể truy cập và trải nghiệm ngay mà không cần cài đặt.
• Đội ngũ 4 thành viên đã bám sát đúng tiến độ đề ra trong charter dự án: hoàn thành 100% yêu cầu MVP "Cơ bản" đúng hạn tuần 4, và đã triển khai một phần lớn các tính năng "Nâng cao" (phát hiện xung đột, luồng HITL edit/approve, xuất PDF, audit log) sớm hơn kế hoạch.

3.2. Giới hạn hiện tại — minh bạch để đánh giá đúng phạm vi

Là một sản phẩm ở giai đoạn MVP của một đồ án 6 tuần, MediSum còn một số giới hạn được ghi nhận rõ ràng thay vì che giấu: xác thực hiện ở phạm vi một tổ chức (chưa tích hợp SSO/OIDC của bệnh viện), một số màn hình frontend phụ chưa nối đầy đủ với dữ liệu thật, và việc đối chiếu mâu thuẫn thuốc hiện chưa bao gồm kiểm tra tương tác thuốc-thuốc (drug-drug interaction) đầy đủ. Đây chính là các hạng mục được ưu tiên ở phần định hướng phát triển tiếp theo.

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

4.1. Ngắn hạn (đã lên kế hoạch, 1–2 tuần tới)

• Nối toàn bộ màn hình review chính với dữ liệu thật cho mọi ca bệnh, thay vì chỉ ca mẫu như hiện tại.
• Cấu trúc hoá dữ liệu xét nghiệm và sinh hiệu vào kho dữ kiện lâm sàng để hiển thị xu hướng chỉ số theo thời gian thực trên timeline.
• Mở rộng bộ kiểm tra xung đột: phát hiện lệch liều lượng thuốc giữa các nguồn (không chỉ có/không có), bổ sung kiểm tra tương tác thuốc-thuốc thật (DDI) và phát hiện chồng nhóm thuốc nguy hiểm (ví dụ nhiều thuốc nhóm opioid cùng lúc).

4.2. Trung hạn (mở rộng cùng đối tác triển khai)

• Tích hợp xác thực OIDC/SSO với hệ thống định danh sẵn có của bệnh viện đối tác, hỗ trợ vận hành đa tổ chức (multi-organization) thay vì một tổ chức đơn lẻ như hiện tại.
• Nâng cấp hạ tầng lưu trữ (PostgreSQL/pgvector) khi quy mô dữ liệu đòi hỏi tìm kiếm ngữ nghĩa (semantic search) thay vì truy vấn trực tiếp như hiện tại.
• Bổ sung cơ chế thu hồi phiên đăng nhập (session revocation) ở tầng cơ sở dữ liệu để đáp ứng yêu cầu bảo mật vận hành thực tế ở quy mô bệnh viện.

4.3. Dài hạn (định hướng sản phẩm)

• Kết nối trực tiếp với hệ thống HIS/EHR của bệnh viện đối tác, thay vì dữ liệu mô phỏng như trong giai đoạn đồ án hiện tại.
• Mở rộng phạm vi từ tổng hợp một ca khám sang theo dõi diễn tiến bệnh nhân xuyên suốt nhiều lần khám (patient memory), với cùng nguyên tắc an toàn: mọi thông tin phải có trích dẫn, mọi xung đột phải được gắn cờ, và bác sĩ luôn là người ra quyết định cuối cùng.