接诊台当前医助数据契约

审查范围：只读静态代码；未连接生产数据，未修改业务代码。仓库 .trellis/ 不存在。

结论

接诊台头部应显示聚合详情的 detail.appointment.assistant_name。它的业务来源是当前诊单 tcm_diagnosis.assistant_id → admin.name，与“通知医助”的实际接收人一致。detail.appointment.assistant_id 也已由服务端覆盖为当前诊单医助 ID。

不要回退到历史挂号 doctor_appointment.assistant_id / appointment_assistant_id、指派日志前任医助、处方医助、doctor_name 或当前登录人姓名。成功加载详情后，空的当前医助字段应保持空态，不应再从旧队列记录补出姓名。

请求与结构

桌面端真实方法名是 RemoteDoctorRepository.get_reception(appointment_id)，不是 get_reception_detail；GET doctor.appointment/reception，参数 {id: appointment_id}，返回映射原样保留。见 repository.py:1102。remote_repository.py 只是重导出模块。
服务端返回 {appointment, diagnosis, doctor_notes, tracking_notes}，见 AppointmentLogic.php:722。桌面端兼容外层 {data: ...}，见 reception.py:7392。
关联关系特别注意：appointment.patient_id == tcm_diagnosis.id，不是基础患者表 ID；诊单另有自己的 patient_id。见 AppointmentLogic.php:678。

{
  "appointment": {
    "id": 123,
    "patient_id": 456,
    "assistant_id": 2001,
    "assistant_name": "某医助",
    "doctor_name": "某医生"
  },
  "diagnosis": {"id": 456, "assistant_id": 2001},
  "doctor_notes": [],
  "tracking_notes": []
}

以上仅是字段结构示例，不是线上数据。

服务端字段语义及通知一致性

位置	确切行为
AppointmentLogic.php:489 `detail()`	选择 `a.*` 并关联患者姓名、电话、`ad.name as doctor_name`；本身不补医助姓名，原始 `a.assistant_id` 属于挂号记录。
AppointmentLogic.php:687 `reception()`	按 `diagnosis.assistant_id` 查 Admin，再写入 `appointment.assistant_name`；`appointment.assistant_id = diagnosis.assistant_id ?? 0`。这一覆盖使聚合 appointment 的医助变为当前诊单口径。
AppointmentLogic.php:887 `notifyAssistant()`	按挂号 `patient_id` 找诊单，再读诊单当前 `assistant_id`，查 Admin 的 `work_wechat_userid` 发送通知。桌面端仅 POST `{id: appointment_id}`，见 repository.py:1164。
AppointmentLists.php:241 队列列表	`u.assistant_id as assistant_id`、`asst.name as assistant_name` 来自当前诊单；另外保留 `a.assistant_id as appointment_assistant_id`，两者语义不同。

未分配时，聚合详情姓名为 ""，ID 为诊单原有空值（缺少时 0）；notifyAssistant() 对 assistant_id <= 0 返回“该患者尚未指派医助”。若 ID 存在但 Admin 查不到/姓名为空，显示姓名同样为空；不能仅根据姓名为空断言未分配。通知另会返回“医助账号不存在”或未绑定企业微信的具体错误。UI 可用“未分配”表示明确的无 ID 状态，有 ID 无姓名可显示“—”或“医助 #ID”。

管理端与桌面端现状

管理端患者信息卡没有多级姓名回退：apt = detail.appointment，显示 apt.assistant_name || '—'（当前文案为“客服”）；见 index.vue:271、PatientInfoCard.vue:19。队列也显示 row.assistant_name || '—'，见 index.vue:72。
Appointment 模型已有 assistant_id: int | None、assistant_name: str，from_dict 直接读取同名键，默认 None / ""；见 models.py:195、models.py:233。Consultation 也有同名字段，未把医生姓名作为医助别名。接诊聚合没有专用 dataclass，直接用 dict。
桌面端详情已把聚合 appointment 传入身份/预约渲染；见 reception.py:7661。兼容字段 appointment_labels['assistant'] 已读取 appointment.assistant_name，见 reception.py:7888；但其所在 appointment_card 被移到隐藏兼容容器，见 reception.py:4740。因此修复可以在头部直接复用现有详情字段，无须新增 API 或修改 core model。

建议展示优先级：已成功取得接诊聚合详情时，以其 appointment.assistant_name 为准；加载前可使用当前选中队列的同口径姓名作临时展示。切换患者、取消选择、详情失败时按当前患者生命周期清空/重置，避免沿用上一位患者的名字。

实施与验证

已在“通知医助”按钮上方增加独立的“当前医助：姓名”文本，读取已核实的聚合详情字段。无医助 ID 时显示未分配；有 ID 但无姓名时显示姓名暂缺；加载与失败状态会清空上一位患者姓名。未修改 API、通知收件人或服务端代码。

离屏验证 816、1080、1340 三种页面宽度，文字与通知按钮不重叠且不产生横向滚动；检查了姓名、未分配、姓名暂缺、未知、患者切换和详情失败。截图：头部预览，其中姓名来自本地示例数据。

现有检查：蓝色布局 15 项通过；单独运行接诊与刷新模块 77 passed in 11.92s；结束问诊按钮 3 项通过；Ruff 和 git diff --check 通过。

组合运行全局主题布局模块与接诊模块时，原有 AI 放大按钮尺寸断言出现 28 × 36 对 28 × 28 的差异。恢复 Git HEAD 接诊模块后，在同一主题条件下仍复现该断言失败；接诊模块单独运行全部通过。该问题未在本次姓名显示修改中扩展处理。

6.6 KiB Raw Blame History Unescape Escape

接诊台当前医助数据契约

结论

请求与结构

服务端字段语义及通知一致性

管理端与桌面端现状

实施与验证

6.6 KiB

Raw Blame History