面向医疗群体智能的协同诊疗与群体决策支持系统（上）

---

2 面向医疗群体智能的完整编程实现路径

2.1 系统总体目标

本系统旨在构建一个面向医疗群体的智能协同决策平台，通过整合医生群体、患者信息、医学知识库、人工智能模型和群体决策算法，实现医疗场景中的多主体协同诊断、治疗建议聚合、群体智慧提取和人机协作辅助。

系统重点服务四类智能机制：

智能类型	编程实现目标	核心功能
CI，Collective Intelligence	实现医生群体协同诊疗	多医生会诊、讨论、共识生成
SI，Swarm Intelligence	实现医疗资源与流程自组织优化	分诊、排班、路径优化、资源调度
WC，Wisdom of Crowds	实现独立诊断意见聚合	多医生独立判断、加权投票、诊断排序
CrI，Collaborative Intelligence	实现人类医生与 AI 协同	AI 辅助诊断、解释生成、风险提示、人机反馈

---

2.2 最新技术栈选择

医疗智能系统不能只追求"最新"，还要兼顾稳定性、生态成熟度、安全性和可维护性。因此建议采用"Python + TypeScript + Rust + PostgreSQL + FHIR"的组合。

截至 2026 年 5 月，Python 官网下载页显示 Python 3.14.4 已于 2026 年 4 月 7 日发布，可作为后端 AI 与算法开发的主语言。(Python.org) TypeScript 6.0 是面向 TypeScript 7.0 的过渡版本，官方说明其正在为未来基于 Go 的新编译器和语言服务做准备。(Microsoft for Developers) Rust 1.95.0 于 2026 年 4 月发布，适合用于高性能调度、并发计算和安全敏感模块。(Rust 编程语言博客) PostgreSQL 官方信息显示当前支持版本包括 PostgreSQL 18.3、17.9、16.13 等，适合作为医疗业务数据和结构化病例数据的核心数据库。(PostgreSQL)

推荐技术栈如下：

层级	推荐语言 / 框架	作用
前端交互层	TypeScript 6 + Next.js 16	医生端、患者端、管理端界面
后端服务层	Python 3.14 + FastAPI	API 服务、业务逻辑、模型调用
算法计算层	Python 3.14 / Rust 1.95	群体决策算法、资源优化算法
AI 模型层	Python + PyTorch / Transformers / LangChain / vLLM	医学文本理解、RAG、辅助诊断
数据存储层	PostgreSQL 18 + pgvector + Redis	病例数据、诊断意见、向量检索、缓存
医疗标准层	HL7 FHIR R5 + SMART on FHIR	医疗数据交换与电子病历集成
部署层	Docker + Kubernetes + Nginx	容器化部署、扩展、负载均衡
安全层	OAuth2 / OpenID Connect / RBAC	医生权限、患者隐私、访问控制

FastAPI 适合本系统的原因是它基于 Python 类型提示构建 API，并且官方文档明确支持 OpenAPI 和 JSON Schema 标准，适合构建医疗场景中需要清晰接口规范的后端服务。(FastAPI) FHIR 是 HL7 发布的医疗数据交换标准，可用于患者、诊断、观察指标、用药、影像报告等结构化医疗数据交换。(FHIR) SMART on FHIR 则可用于把应用接入电子病历工作流，支持基于 FHIR、OAuth2、OpenID Connect 的医疗应用集成。(智能健康IT文档)

---

2.3 系统总体架构

系统可以采用"前后端分离 + 微服务 + AI 服务独立部署"的架构。

用户层
├── 医生端 Web
├── 专家端 Web
├── 患者端小程序 / App
└── 医疗管理端后台

业务服务层
├── 用户与权限服务
├── 病例管理服务
├── 群体诊断服务
├── 医生协同服务
├── AI 辅助诊断服务
├── 医疗资源调度服务
└── 审计与日志服务

智能算法层
├── CI 协同决策模块
├── WC 群体智慧聚合模块
├── SI 自组织调度优化模块
├── CrI 人机协作模块
└── 模型评估与反馈模块

数据层
├── PostgreSQL：病例、用户、诊断意见
├── Redis：缓存、会话、任务队列
├── MinIO：影像、报告、附件
├── Vector DB：医学知识向量库
└── FHIR Server：标准化医疗数据接口

---

2.4 核心功能模块设计

2.4.1 病例数据采集模块

该模块负责采集患者的基础信息、主诉、现病史、既往史、检查结果、影像报告、用药记录和初步诊断。

主要功能包括：

1. 新建病例
2. 上传检查报告
3. 结构化录入症状
4. 接入电子病历系统
5. 使用 FHIR 标准转换数据
6. 对敏感信息进行脱敏处理

核心数据结构可以设计为：

from pydantic import BaseModel
from typing import list, optional
from datetime import datetime

class PatientCase(BaseModel):
    case_id: str
    patient_id: str
    age: int
    gender: str
    chief_complaint: str
    present_illness: str
    medical_history: str | None = None
    lab_results: list[dict] = []
    imaging_reports: list[str] = []
    created_at: datetime

---

2.4.2 CI 群体协同诊疗模块

CI 模块重点实现医生之间的合作行为。系统应支持多名医生围绕同一病例进行独立判断、讨论、修正和最终共识生成。

实现流程：

病例发布
↓
系统邀请相关医生
↓
医生独立提交诊断意见
↓
系统隐藏其他医生意见，避免从众偏差
↓
第一轮意见聚合
↓
开放讨论区
↓
医生补充证据和修改意见
↓
形成最终群体诊断结果

核心表设计：

CREATE TABLE doctor_opinion (
    opinion_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    doctor_id UUID NOT NULL,
    diagnosis TEXT NOT NULL,
    confidence FLOAT CHECK (confidence >= 0 AND confidence <= 1),
    evidence TEXT,
    submitted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    is_final BOOLEAN DEFAULT FALSE
);

---

2.4.3 WC 群体智慧聚合模块

WC 模块的核心是"多个独立判断的聚合"。可以实现三类算法：

1. 多数投票法

适合简单诊断任务。

from collections import Counter

def majority_vote(diagnoses: list[str]) -> str:
    counter = Counter(diagnoses)
    return counter.most_common(1)[0][0]

2. 置信度加权法

适合医生提交诊断时同时给出置信度的情况。

from collections import defaultdict

def confidence_weighted_vote(opinions: list[dict]) -> list[tuple[str, float]]:
    scores = defaultdict(float)

    for item in opinions:
        diagnosis = item["diagnosis"]
        confidence = item["confidence"]
        scores[diagnosis] += confidence

    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

3. 专业能力加权法

适合不同医生资历、专科背景和历史准确率不同的场景。

def expert_weighted_vote(opinions: list[dict]) -> list[tuple[str, float]]:
    scores = defaultdict(float)

    for item in opinions:
        diagnosis = item["diagnosis"]
        confidence = item["confidence"]
        expertise_weight = item["expertise_weight"]
        historical_accuracy = item["historical_accuracy"]

        final_weight = confidence * expertise_weight * historical_accuracy
        scores[diagnosis] += final_weight

    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

聚合结果不应只输出一个结论，而应输出：

1. 最高可能诊断
2. 候选诊断排序
3. 群体一致性程度
4. 分歧点
5. 支撑证据
6. 需要进一步检查的项目

---

2.4.4 SI 医疗自组织调度模块

SI 模块主要用于医疗资源优化，例如分诊、床位调度、医生排班、急诊路径规划、检查设备分配等。

可采用的算法包括：

1. 蚁群算法：适合路径优化和检查流程优化
2. 粒子群算法：适合资源分配和参数优化
3. 遗传算法：适合医生排班和床位调度
4. 多智能体系统：适合医院内部动态协同

示例目标函数：

Minimize:
    患者等待时间
    医生工作负载不均衡
    设备空闲率
    急诊响应时间

Subject to:
    医生专业匹配
    检查设备可用
    床位容量限制
    患者病情优先级

伪代码如下：

def optimize_resource_allocation(patients, doctors, devices):
    population = initialize_solutions(patients, doctors, devices)

    for generation in range(100):
        fitness_scores = evaluate(population)
        selected = select_best(population, fitness_scores)
        crossed = crossover(selected)
        mutated = mutate(crossed)
        population = mutated

    return best_solution(population)

---

2.4.5 CrI 人机协作智能模块

CrI 模块用于实现医生与 AI 的协同，而不是让 AI 直接替代医生。

推荐采用 RAG，即 Retrieval-Augmented Generation，检索增强生成架构。

实现流程：

医生输入病例
↓
系统提取症状、检查指标、病史
↓
向量数据库检索相关医学指南、病例、文献
↓
大语言模型生成候选诊断
↓
系统给出解释、证据和风险提示
↓
医生确认、修改或拒绝 AI 建议
↓
系统记录反馈，用于持续优化

AI 输出格式应严格结构化：

{
  "possible_diagnoses": [
    {
      "name": "肺炎",
      "probability": 0.72,
      "supporting_evidence": ["发热", "咳嗽", "影像提示感染"],
      "recommended_tests": ["血常规", "CRP", "胸部CT"],
      "risk_level": "medium"
    }
  ],
  "warning": "该结果仅作为辅助参考，最终诊断需由医生确认。"
}

---

2.5 后端 API 实现路径

建议使用 Python 3.14 + FastAPI 构建后端。

项目结构：

medical_collective_intelligence/
├── app/
│   ├── main.py
│   ├── api/
│   │   ├── case_api.py
│   │   ├── opinion_api.py
│   │   ├── aggregation_api.py
│   │   └── ai_api.py
│   ├── models/
│   │   ├── case.py
│   │   ├── opinion.py
│   │   └── user.py
│   ├── services/
│   │   ├── case_service.py
│   │   ├── aggregation_service.py
│   │   ├── ai_service.py
│   │   └── scheduling_service.py
│   ├── algorithms/
│   │   ├── majority_vote.py
│   │   ├── weighted_vote.py
│   │   ├── consensus_score.py
│   │   └── swarm_optimization.py
│   └── database/
│       ├── connection.py
│       └── migrations/
├── tests/
├── docker-compose.yml
└── pyproject.toml

FastAPI 主入口：

from fastapi import FastAPI
from app.api.case_api import router as case_router
from app.api.opinion_api import router as opinion_router
from app.api.aggregation_api import router as aggregation_router

app = FastAPI(
    title="Medical Collective Intelligence System",
    version="1.0.0"
)

app.include_router(case_router, prefix="/cases", tags=["Cases"])
app.include_router(opinion_router, prefix="/opinions", tags=["Opinions"])
app.include_router(aggregation_router, prefix="/aggregation", tags=["Aggregation"])

@app.get("/health")
def health_check():
    return {"status": "ok"}

诊断意见聚合接口：

from fastapi import APIRouter
from app.services.aggregation_service import aggregate_case_opinions

router = APIRouter()

@router.get("/{case_id}")
def get_aggregation_result(case_id: str):
    result = aggregate_case_opinions(case_id)
    return {
        "case_id": case_id,
        "aggregation_result": result
    }

---

2.6 前端实现路径

前端建议使用 TypeScript 6 + Next.js 16。

核心页面包括：

1. 登录页面
2. 病例列表页面
3. 病例详情页面
4. 独立诊断提交页面
5. 群体诊断结果页面
6. 医生讨论区
7. AI 辅助建议页面
8. 管理后台与统计分析页面

前端页面结构：

frontend/
├── app/
│   ├── login/
│   ├── cases/
│   │   ├── page.tsx
│   │   └── [caseId]/page.tsx
│   ├── dashboard/
│   └── admin/
├── components/
│   ├── CaseCard.tsx
│   ├── DiagnosisForm.tsx
│   ├── ConsensusPanel.tsx
│   ├── AIAssistantPanel.tsx
│   └── DiscussionBoard.tsx
├── lib/
│   ├── api.ts
│   └── auth.ts
└── types/
    ├── case.ts
    └── opinion.ts

前端核心数据类型：

export interface DoctorOpinion {
  opinionId: string;
  caseId: string;
  doctorId: string;
  diagnosis: string;
  confidence: number;
  evidence: string;
  submittedAt: string;
}

export interface AggregationResult {
  topDiagnosis: string;
  rankedDiagnoses: {
    name: string;
    score: number;
  }[];
  consensusScore: number;
  disagreementPoints: string[];
}

---

2.7 数据库设计路径

核心数据库建议使用 PostgreSQL。

主要数据表包括：

user：医生、专家、管理员、患者
patient_case：病例信息
doctor_opinion：医生诊断意见
aggregation_result：群体聚合结果
ai_suggestion：AI 辅助建议
discussion_message：医生讨论记录
audit_log：审计日志
medical_resource：医疗资源
schedule_task：调度任务

示例：

CREATE TABLE aggregation_result (
    result_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    top_diagnosis TEXT NOT NULL,
    ranked_diagnoses JSONB NOT NULL,
    consensus_score FLOAT,
    disagreement_points JSONB,
    generated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

---

2.8 系统开发阶段安排

第一阶段：需求分析与场景建模

明确系统服务对象：

1. 医生
2. 专科专家
3. 患者
4. 医院管理者
5. AI 辅助系统

明确主要业务场景：

1. 疑难病例会诊
2. 多医生独立诊断
3. 群体诊断聚合
4. AI 辅助诊断
5. 医疗资源调度
6. 医生协同讨论

---

第二阶段：数据标准化

医疗数据必须优先标准化，否则后续 AI 和群体算法很难稳定运行。

应完成：

1. 建立病例数据结构
2. 建立症状编码体系
3. 建立诊断术语库
4. 接入 ICD / SNOMED / FHIR
5. 完成患者隐私脱敏
6. 建立数据访问权限

---

第三阶段：后端服务开发

优先开发基础服务：

1. 用户登录与权限管理
2. 病例创建与查询
3. 医生意见提交
4. 群体意见聚合
5. AI 建议生成
6. 审计日志记录

后端接口示例：

POST /cases
GET /cases/{case_id}
POST /opinions
GET /aggregation/{case_id}
POST /ai/diagnosis
GET /audit/{case_id}

---

第四阶段：群体智能算法开发

重点实现四类算法模块：

1. 多数投票算法
2. 置信度加权算法
3. 专家权重算法
4. 群体一致性评分算法

群体一致性评分可以这样设计：

def calculate_consensus_score(opinions: list[dict]) -> float:
    total = len(opinions)
    if total == 0:
        return 0.0

    diagnosis_count = {}

    for opinion in opinions:
        diagnosis = opinion["diagnosis"]
        diagnosis_count[diagnosis] = diagnosis_count.get(diagnosis, 0) + 1

    max_count = max(diagnosis_count.values())
    return max_count / total

输出解释：

consensus_score 接近 1，说明医生群体高度一致；
consensus_score 接近 0.5，说明存在明显分歧；
consensus_score 较低，说明需要继续讨论或补充检查。

---

第五阶段：AI 辅助模块开发

AI 模块不能直接给出最终诊断，应定位为"辅助建议"。

开发内容包括：

1. 医学知识库构建
2. 病例文本向量化
3. 相关指南检索
4. 候选诊断生成
5. 解释与证据输出
6. 医生反馈收集

安全规则：

1. AI 输出必须标注"辅助参考"
2. AI 不得自动替代医生最终诊断
3. 所有 AI 建议必须留痕
4. 高风险建议必须触发人工复核
5. 医生可以接受、修改或拒绝 AI 建议

---

第六阶段：前端界面开发

医生端重点不是炫酷，而是清晰、低负担、符合临床工作流。

页面逻辑：

病例列表
↓
病例详情
↓
提交独立诊断
↓
查看群体聚合结果
↓
查看 AI 辅助建议
↓
参与讨论
↓
形成最终诊断

---

第七阶段：实验验证与系统评估

论文中可以从以下指标评估系统：

评估类别	指标
诊断准确性	Top-1 Accuracy、Top-3 Accuracy
群体效果	个体医生准确率 vs 群体聚合准确率
一致性	Consensus Score、Kappa 系数
效率	平均诊断时间、会诊完成时间
AI 辅助效果	有 AI vs 无 AI 的准确率差异
安全性	错误建议率、高风险误判率
用户体验	医生满意度、系统可用性评分

---

第八阶段：部署与安全合规

部署架构：

Nginx
↓
Frontend Container
↓
Backend API Container
↓
AI Model Service
↓
PostgreSQL / Redis / Vector DB
↓
Audit Log / Monitoring

安全措施：

1. HTTPS 加密
2. JWT / OAuth2 登录
3. RBAC 角色权限控制
4. 患者数据脱敏
5. 操作日志不可篡改
6. 模型输出审计
7. 数据备份与恢复

---

2.9 最终系统实现路径总结

可以将完整编程实现路径概括为：

需求分析
↓
医疗数据标准化
↓
系统架构设计
↓
数据库建模
↓
后端 API 开发
↓
前端交互开发
↓
群体智能算法实现
↓
AI 辅助诊断模块开发
↓
医生协同模块开发
↓
医疗资源调度模块开发
↓
系统安全与权限控制
↓
实验验证
↓
部署上线
↓
持续优化

---

2.10 可写入论文的表述版本

本研究拟基于现代软件工程方法构建面向医疗群体智能的协同决策支持系统。系统采用 Python、TypeScript、Rust 等现代编程语言进行模块化开发，其中 Python 主要承担后端业务逻辑、医学人工智能模型调用和群体决策算法实现，TypeScript 主要承担医生端、患者端与管理端的交互界面开发，Rust 主要用于高性能医疗资源调度和并发计算模块。数据库层采用 PostgreSQL 存储结构化病例数据、医生诊断意见和群体聚合结果，并结合向量数据库实现医学知识检索。系统同时引入 HL7 FHIR 标准以提升医疗数据交换能力，并通过 OAuth2、OpenID Connect 和角色权限控制机制保障数据访问安全。

在功能实现方面，系统围绕 CI、SI、WC 和 CrI 四类医疗群体智能范式进行设计。CI 模块用于支持多医生协同会诊和共识生成；SI 模块用于实现医疗资源的自组织调度与流程优化；WC 模块用于对多个医生的独立诊断意见进行多数投票、置信度加权和专家权重聚合；CrI 模块则通过医学知识库检索和大语言模型生成辅助诊断建议，实现医生与人工智能系统之间的协作。系统最终输出不仅包括候选诊断结果，还包括群体一致性评分、诊断分歧点、支撑证据和进一步检查建议，从而提升医疗决策的透明度、可解释性和可靠性。

该实现路径能够将医疗群体智能理论转化为可运行、可验证、可扩展的软件系统，为后续开展实验评估、临床模拟和真实医疗场景应用提供技术基础。

---

你现在这部分可以继续扩展成论文的第 2 章或第 3 章，标题可以写成：

"面向医疗群体智能的系统设计与编程实现路径"。

当然可以。你前面的方向已经很完整了，下面继续把"完整编程实现路径 "扩展成更像论文正文的内容，重点补充：业务流程、数据流、核心算法、前后端交互、AI 模块、系统安全、测试部署和论文实验设计。

---

2.11 系统业务流程设计

面向医疗群体智能的系统并不是一个单纯的在线问诊平台，而是一个以"病例"为核心，以"多主体协同决策"为主线，以"群体智能算法和 AI 辅助模型"为支撑的综合系统。

系统完整业务流程可以设计如下：

患者病例创建
↓
病例数据结构化
↓
系统进行病例分类和风险分级
↓
匹配相关医生或专家群体
↓
医生独立提交诊断意见
↓
系统进行群体意见聚合
↓
AI 辅助模块生成参考建议
↓
系统比较医生群体意见与 AI 建议
↓
开放医生讨论和二次修正
↓
生成最终群体诊断结果
↓
输出诊疗建议、风险提示和后续检查方案
↓
记录医生反馈和系统决策过程
↓
进入持续学习与质量评估模块

这个流程体现了医疗群体智能系统的核心逻辑：
先保持独立判断，再进行群体聚合，最后通过协作讨论和 AI 辅助形成更可靠的医疗决策。

---

2.12 系统用户角色设计

系统中至少应包含五类用户角色。

2.12.1 患者角色

患者主要负责提交基础信息、症状描述、既往病史和检查资料。

主要功能包括：

1. 填写基本信息
2. 提交主诉和症状
3. 上传检验报告、影像报告、病历资料
4. 查看医生群体诊断结果
5. 查看后续检查建议
6. 参与医患共享决策

2.12.2 普通医生角色

普通医生是系统中最核心的判断主体，负责独立诊断和参与协作讨论。

主要功能包括：

1. 查看被分配病例
2. 独立提交初步诊断意见
3. 标注诊断置信度
4. 提供诊断依据
5. 查看群体聚合结果
6. 参与病例讨论
7. 确认或修正最终诊断

2.12.3 专科专家角色

专科专家主要参与复杂病例、疑难病例和高风险病例的复核。

主要功能包括：

1. 查看高风险病例
2. 提供专科诊断意见
3. 对群体诊断结果进行复核
4. 给出治疗建议
5. 标注关键风险点

2.12.4 医疗管理者角色

医疗管理者主要关注系统运行效率、医生协作质量和医疗资源调度。

主要功能包括：

1. 查看病例处理进度
2. 查看医生工作量
3. 分析群体诊断准确率
4. 监测高风险病例
5. 管理医生权限
6. 审计系统操作日志

2.12.5 AI 辅助系统角色

AI 系统不是最终决策者，而是辅助信息提供者。

主要功能包括：

1. 提取病例关键信息
2. 检索相关医学知识
3. 生成候选诊断
4. 解释诊断依据
5. 提示潜在风险
6. 推荐进一步检查项目
7. 接收医生反馈并优化输出

---

2.13 系统数据流设计

医疗群体智能系统的数据流可以分为五个阶段。

2.13.1 数据输入阶段

输入数据主要包括：

1. 患者人口学信息
2. 主诉信息
3. 现病史
4. 既往史
5. 检查检验结果
6. 影像报告
7. 医生诊断意见
8. AI 生成建议
9. 群体讨论记录

数据输入后，系统需要完成格式转换、字段校验和隐私脱敏。

例如患者原始输入为：

患者，男，58 岁，咳嗽发热 5 天，伴胸闷，既往有糖尿病史。

系统应结构化为：

{
  "age": 58,
  "gender": "male",
  "chief_complaint": "咳嗽发热 5 天，伴胸闷",
  "medical_history": ["糖尿病"],
  "symptoms": ["咳嗽", "发热", "胸闷"],
  "duration": "5 天"
}

2.13.2 数据预处理阶段

数据预处理包括：

1. 缺失值检查
2. 异常值检测
3. 医学术语标准化
4. 症状实体识别
5. 检验指标单位统一
6. 患者身份信息脱敏

例如：

"血糖偏高" → 标准化为 "血糖异常升高"
"胸片显示感染" → 标准化为 "肺部感染影像学表现"

2.13.3 群体判断阶段

医生独立提交意见，系统记录以下信息：

1. 医生编号
2. 专业方向
3. 初步诊断
4. 候选诊断列表
5. 诊断置信度
6. 诊断依据
7. 建议检查
8. 提交时间

2.13.4 智能计算阶段

系统调用群体智能算法和 AI 模型进行计算：

1. 多数投票
2. 置信度加权
3. 专家能力加权
4. 群体一致性评分
5. 医生意见分歧分析
6. AI 候选诊断生成
7. 人机结果对比

2.13.5 结果输出阶段

最终输出不是单一诊断，而是综合性诊断报告。

报告内容包括：

1. 群体最可能诊断
2. 候选诊断排序
3. 医生群体一致性
4. 主要分歧点
5. AI 辅助建议
6. 高风险提示
7. 推荐进一步检查
8. 最终确认医生
9. 审计记录

---

2.14 数据库实体关系设计

系统数据库应围绕"病例---医生---意见---聚合结果---AI 建议---讨论记录"展开。

核心实体关系如下：

Patient 1 ------ N PatientCase
PatientCase 1 ------ N DoctorOpinion
PatientCase 1 ------ 1 AggregationResult
PatientCase 1 ------ N AISuggestion
PatientCase 1 ------ N DiscussionMessage
Doctor 1 ------ N DoctorOpinion
Doctor 1 ------ N DiscussionMessage

可以设计为以下核心表。

---

2.14.1 患者表 patient

CREATE TABLE patient (
    patient_id UUID PRIMARY KEY,
    name_hash TEXT NOT NULL,
    gender VARCHAR(20),
    age INT,
    phone_hash TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

这里不直接保存患者真实姓名和手机号，而是保存哈希值，目的是降低隐私泄露风险。

---

2.14.2 病例表 patient_case

CREATE TABLE patient_case (
    case_id UUID PRIMARY KEY,
    patient_id UUID NOT NULL,
    chief_complaint TEXT NOT NULL,
    present_illness TEXT,
    medical_history TEXT,
    allergy_history TEXT,
    family_history TEXT,
    risk_level VARCHAR(20),
    case_status VARCHAR(30),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

其中 case_status 可以包括：

created：病例已创建
assigned：已分配医生
opinion_collecting：正在收集医生意见
aggregated：已完成群体聚合
discussion：正在讨论
finalized：已形成最终结果
archived：已归档

---

2.14.3 医生表 doctor

CREATE TABLE doctor (
    doctor_id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    department TEXT,
    specialty TEXT,
    title TEXT,
    years_of_experience INT,
    historical_accuracy FLOAT DEFAULT 0.5,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

historical_accuracy 可根据医生过往诊断与最终结果的一致性动态更新，但在实际医疗应用中必须谨慎使用，避免简单量化医生能力造成不公平评价。

---

2.14.4 医生意见表 doctor_opinion

CREATE TABLE doctor_opinion (
    opinion_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    doctor_id UUID NOT NULL,
    primary_diagnosis TEXT NOT NULL,
    differential_diagnoses JSONB,
    confidence FLOAT CHECK (confidence >= 0 AND confidence <= 1),
    evidence TEXT,
    recommended_tests JSONB,
    submitted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    revised_at TIMESTAMP
);

---

2.14.5 群体聚合结果表 aggregation_result

CREATE TABLE aggregation_result (
    result_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    top_diagnosis TEXT NOT NULL,
    ranked_diagnoses JSONB NOT NULL,
    consensus_score FLOAT,
    disagreement_points JSONB,
    aggregation_method VARCHAR(50),
    generated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

---

2.14.6 AI 建议表 ai_suggestion

CREATE TABLE ai_suggestion (
    suggestion_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    model_name TEXT,
    possible_diagnoses JSONB,
    supporting_evidence JSONB,
    risk_warnings JSONB,
    recommended_tests JSONB,
    generated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    doctor_feedback TEXT
);

---

2.14.7 讨论记录表 discussion_message

CREATE TABLE discussion_message (
    message_id UUID PRIMARY KEY,
    case_id UUID NOT NULL,
    doctor_id UUID NOT NULL,
    message TEXT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

---