Doctor 專案改進建議 — 基於 7 個同領域專案的綜合比較分析

本文基於 8 個 GitHub 專案的完整教學分析，提出 Doctor 專案的系統性改進方案。

1. 現狀診斷：Doctor 的定位與核心問題

1.1 Doctor 做了什麼

Doctor 是一個 Streamlit + Google Gemini 的醫病角色扮演模擬器。核心概念：

• 9 步 system prompt (系統提示詞) 驅動的「臨床博弈引擎」
• 心理防禦指標（SAI 主導權感知、MF 面具疲勞度、B-D 邊界防禦）
• <clinical_engine> 內部推演 + <doctor_output> 外部演繹的雙層輸出

1.2 核心問題（5 大缺失）

1.3 Doctor 的亮點（值得保留）

• ✅ Doubt-Driven 懷疑度標籤化：每個診斷標籤綁定 0-100% 懷疑度，概念有價值
• ✅ 反向鑑別搜索：當懷疑度 > 60% 時強制啟動互斥搜索，防止 confirmation bias (確認偏誤)
• ✅ 心理防禦指標儀表板：SAI/MF/B-D 三維度即時監控，UX 設計有特色
• ✅ 對話節奏控制：一次只問一個問題、一次只提一項檢查的限制合理
• ✅ 雙層輸出結構：<clinical_engine> 內部推演 + <doctor_output> 外部呈現的分離

2. 七個對照專案的關鍵啟示

2.1 專案對照矩陣

2.2 每個專案教會我們的一件事

3. 改進方案：從 Prompt Engine 到 Clinical Intelligence Platform

3.1 改進架構總覽

graph TB
    subgraph "Layer 1: 使用者介面"
        UI[Streamlit UI
保留 Doctor 的儀表板設計]
        DICOM[DICOM Viewer
影像檢視]
    end

    subgraph "Layer 2: Agent 編排 (LangGraph)"
        Router[Router Agent
分診路由]
        Intake[Intake Agent
問診採集]
        Diagnosis[Diagnosis Agent
鑑別診斷]
        Treatment[Treatment Agent
治療方案]
        Audit[Audit Agent
安全審核]
        Psychology[Psychology Agent
保留 Doctor 的 SAI/MF/B-D]
    end

    subgraph "Layer 3: 知識工具層"
        PubMed[PubMed API
文獻檢索]
        DrugDB[DrugBank/RxNorm
藥物資料庫]
        Guidelines[臨床指引 RAG
UpToDate/急診教科書]
        DDI[DDI Checker
藥物交互作用]
        Lab[Lab Reference
檢驗參考值]
        FHIR[FHIR R4
EHR 介面]
    end

    subgraph "Layer 4: 資料與記憶"
        VectorDB[ChromaDB/FAISS
向量資料庫]
        SQLite[SQLite
病歷記憶]
        KG[Knowledge Graph
Neo4j 醫學圖譜]
    end

    UI --> Router
    DICOM --> Router
    Router --> Intake
    Router --> Diagnosis
    Router --> Treatment
    Router --> Psychology
    Intake --> Diagnosis
    Diagnosis --> Treatment
    Treatment --> Audit
    Diagnosis --> PubMed
    Diagnosis --> Guidelines
    Treatment --> DrugDB
    Treatment --> DDI
    Treatment --> Lab
    Audit --> FHIR
    Guidelines --> VectorDB
    Psychology --> SQLite
    KG --> Diagnosis

3.2 六大改進模組

模組 A：醫療知識工具層（最高優先）

解決問題： Doctor 完全沒有醫療資料庫整合

關鍵設計原則（借鑑 HealthRex/CDSS + Drug-Interaction 教訓）：

• 結構化資料庫查詢 > LLM 猜測（DDI、藥物劑量、檢驗正常值必須用 DB）
• LLM 只做自然語言合成和推理，不做資料查找
• 每個推薦必須附帶來源引用（PubMed ID / 指引章節）

模組 B：Multi-Agent 架構（借鑑 MediGenius + multi-agent-system）

解決問題： Doctor 的 9 步推演壓在一個 system prompt 裡

 1現在（Doctor）:
 2  User Input → [1 個巨大 System Prompt, 9 步推演] → Output
 3
 4改進後:
 5  User Input → Router Agent
 6    ├→ Intake Agent (問診採集, 結構化症狀)
 7    ├→ Diagnosis Agent (鑑別診斷 + 知識工具查詢)
 8    ├→ Treatment Agent (治療方案 + DDI 檢查 + 指引依據)
 9    ├→ Psychology Agent (SAI/MF/B-D, 保留 Doctor 特色)
10    └→ Audit Agent (安全審核 + HIPAA 合規)

技術選型： LangGraph（借鑑 MediGenius 和 multi-agent-system 的驗證）

模組 C：臨床知識 RAG（借鑑 MediGenius）

解決問題： 無急診教科書、疾病教科書資料

Embedding 策略（借鑑 MediGenius）：

• Chunk size: 512 tokens, overlap: 128
• Embedding model: text-embedding-3-small 或 pubmedbert
• Vector store: ChromaDB（本地優先，隱私考量）

模組 D：感染 + 即時處置判斷（借鑑 MIMIC_RL_COACH）

解決問題： 無法做敗血症等感染的即時處置判斷

模組 E：持久化病歷管理（借鑑 MediGenius + MedAgentBench）

解決問題： Doctor 的 session_state 重開就消失

 1# 借鑑 MediGenius 的 SQLite 記憶
 2class PatientMemory:
 3    def __init__(self, db_path="patient_records.db"):
 4        self.conn = sqlite3.connect(db_path)
 5        self.create_tables()
 6
 7    def save_encounter(self, patient_id, encounter_data):
 8        # SOAP note 結構化存儲
 9        # S: Subjective (主訴)
10        # O: Objective (理學檢查 + 檢驗數據)
11        # A: Assessment (評估 + 鑑別診斷)
12        # P: Plan (治療計畫)
13        ...

模組 F：安全合規層（借鑑 multi-agent-system + MedAgentBench）

4. 實施路線圖

Phase 1：基礎強化（1-2 週）

Phase 2：知識 RAG（2-4 週）

Phase 3：進階功能（4-8 週）

5. 保留 Doctor 的核心特色

改進不是拋棄 Doctor 的設計——以下特色值得保留並強化：

6. 技術選型建議

7. 總結：從玩具到工具的三步跨越

1Step 1: 加入知識工具層（PubMed + DrugBank + DDI + 指引 RAG）
2        → 從「LLM 猜測」升級為「查詢 + 推理」
3
4Step 2: 拆成多 Agent（LangGraph pipeline: 問診 → 診斷 → 治療 → 審核）
5        → 從「一個大 prompt」升級為「專責分工」
6
7Step 3: 加入真實資料（FHIR EHR + 知識圖譜 + 感染即時處置）
8        → 從「模擬器」升級為「臨床決策支援系統」

Doctor 的 Doubt-Driven 概念和心理防禦指標是有特色的創新設計。問題不在概念，而在缺乏支撐這些概念的資料基礎設施。加上知識工具層和多 agent 架構後，這個專案有潛力成為一個真正實用的臨床決策支援系統。