# AI-CLIP Phase 0 全板块业务 PRD

2026-09-10 功能方案整理版 · 唯一领域正文、测试与实施附录；旧下载地址兼容保留



---

# AI-CLIP Phase 0 业务 PRD

版本：功能方案整理版 · 更新：2026-09-14 · 面向：业务、产品、开发与测试

本 PRD 说明一次门诊如何从患者登记、预约和到诊，经过医生问诊，进入药房、检查、收费及诊后处理。先阅读本篇了解完整流程和岗位分工，再进入对应模块查看操作步骤、业务规则和例外情况。

各项需求保留原编号，方便开发和测试对照。[业务测试用例](https://virtus-patient-emr-prd.vercel.app/acceptance.html)说明如何验收，[实现与待确认事项](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)说明当前进度及缺口。

## 按板块阅读

先按下表找到功能领域；需要理解跨模块关系时读本文第 2～5 节。各领域先列功能地图，再将字段、规则、界面和异常放进对应功能。实现差距与执行证据有独立入口，不按日期补记推断当前产品方案。

| PRD | 覆盖内容 |
|---|---|
| [患者、预约、到诊与护理](https://virtus-patient-emr-prd.vercel.app/frontoffice.html) | 患者主档／eMR、H5 与审核、预约／资源、Check-in、护理和队列 |
| [问诊、处方与临床完成](https://virtus-patient-emr-prd.vercel.app/consultation.html) | 五模块实际操作、保存、AI Scribe、Service、完成门禁及当前设计差距 |
| [Clinical Documents 与模板](https://virtus-patient-emr-prd.vercel.app/documents.html) | 内嵌／独立入口、自动保存、版本、文档生命周期与模板 |
| [Pharmacy、库存与 V-Lab](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html) | 处方审核、付款后备药、退回与结账阻断、修订、库存／套餐、内部／外部检查 |
| [Cashier、保险回款与诊后](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html) | 收费、付款、退款、AR、回款分配、复诊和任务 |
| [Central Pharmacy 内部管理](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html) | 采购审批、收货、诊所申领／自采、库存、退换、单位及数量对账；保留独立范围边界 |
| [Catalogue、优惠与保险计划](https://virtus-patient-emr-prd.vercel.app/catalogue.html) | 服务／产品／检查、价格与成本、卡种／Policy、Coupon、导入 |
| [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html) | AI／知识库、用户组织、Consent、审计、集成、迁移和移动边界 |

## 产品功能架构

```mermaid
flowchart TD
  A[患者与护理：主档、自填、预约、到诊] --> B[临床工作：Note、处方、检查、文档、完成]
  B --> C[药房执行：审方、备药、复核、发药]
  B --> D[V-Lab 执行：承接、结果、医生确认]
  B --> E[收费与诊后：发票、付款、应收、日报、跟进]
  C --> E
  F[共享目录：服务、价格、计划、套餐与优惠] --> A
  F --> B
  F --> E
  G[CP 供应：采购、分发、库存与耗用] --> C
  H[共同能力：组织、角色、数据权限、审计、AI、平台] -.约束及支持.-> A
  H -.约束及支持.-> B
  H -.约束及支持.-> C
  H -.约束及支持.-> D
  H -.约束及支持.-> E
```

功能架构说明各领域如何协作；实际动作先后以门诊流程和各功能门禁为准。CP 的内部设计、应用部署与原合同范围分别记录。

| 阅读维度 | 文档应回答的问题 | 如何使用 |
|---|---|---|
| 功能目的 | 用户要完成什么、最终产生什么 | 每篇功能地图及各功能起始说明 |
| 人员与对象 | 谁使用、处理哪一份记录、属于哪个范围 | 角色／对象表与关系图 |
| 操作方案 | 从哪个入口、按什么顺序、保存后发生什么 | 功能内的流程、字段与页面规则 |
| 权限与异常 | 什么条件允许，失败／撤销／更正怎么处理 | 功能内门禁及跨模块权威链接 |
| 实现边界 | 已有基础、部分实现、待开发、待业务确认 | 各功能差距及统一交付说明；不能等同 UAT |
| 验收依据 | 如何证明规则成立 | 用例定义与实际执行记录分别维护 |

## 1. 产品目标与范围

让前台、护士（含收费操作）、医生、药房及检查人员，在**同一患者、同一诊所、同一次就诊** 上连续完成工作。上一岗位完成后，下一岗位能看到准确的任务、资料和状态；失败、退回和更正都有明确去向。

### 1.1 本期需要完成的业务

| 业务段 | 用户要完成的事 | 完成后的业务结果 |
|---|---|---|
| 建档与预约 | 识别患者，维护资料，预约医生及服务 | 一份可复用的患者档案、一条明确的预约 |
| 到诊与准备 | 核对身份，签到，完成要求的护理准备 | 一次关联预约的就诊，进入正确工作队列 |
| 医生问诊 | 查看历史，写病历，确认诊断，开药、开检查、出文档 | 已签署的临床记录及明确的后续交接 |
| 药房 | 审方、标签、配药、复核、发药或退回医生 | 处方版本与实际发药结果对应 |
| V-Lab / Imaging | 内部接单、执行、发布结果、医生确认 | 检查从开单到结果处理可追踪 |
| 收费及诊后 | 核对费用，开票，记付款，安排复诊和后续任务 | 当场结账、未结应收和最终关闭各有记录 |
| 共同能力 | 权限、版本、审计、历史资料、辅助 AI | 不串患者、不丢记录、不把草稿当正式结果 |

本期不交付完整 WDL 采购与复杂库存、保险自动核赔、支付终端直连、经营看板、现金盘点关账／Period Close、原生移动 App、自动批量消息。复杂 Benefit Contracts 管理界面本期隐藏；已存在的企业／员工合同仍可作为卡种来源。2026-09-08 明确纳入诊所／医生 Day-end Revenue Report，仅统计新 Cashier 账本，chit 仅作收入凭据下钻；详见 Cashier §6.1。详细排期、报价和开发日志不属于本文。

### 1.2 怎样判断整个流程成立

1. 跨岗位使用同一个就诊编号，处方、检查、文档、账单均能追溯至本次就诊。
2. 每次交接可以回答：谁已完成、谁待处理、下一步是什么、为什么不能继续。
3. 重复点击、刷新、失败重试不会重复签到、重复开药、重复开票或重复收款。
4. 付款、临床签署、发药、检查出结果和最终关闭分别按自己的规则完成。

## 2. 角色与业务数据归属

### 2.1 角色负责什么

| 角色 | 主要入口与操作 | 责任边界 |
|---|---|---|
| Customer Service / 前台 | Patient & eMR 基础资料、Appointment；预约及基础信息建档／修改／确认 | 维护受诊所资格与字段权限限制；不签到、不维护医疗／安全、保险计划或附件，不执行付款 |
| 护士 | Registration、护理准备、Service Queue、Cashier | 当前 Clinic 的有效服务医生范围内处理日程、签到、本次附件及付款；受限问诊记录和历史附件另需医生授权 |
| 医生 | Consultation Queue / Workspace | 临床记录、诊断、处方、医嘱、临床文档及临床修订 |
| 配药人员 | Drug Dispensing | 审核、标签、备药及异常评论；不能修改或取消医生处方 |
| 药师 / Final Checker | Drug Dispensing | 最终复核及发药；需满足付款和人员分工要求 |
| V-Lab / Imaging 人员 | 内部检查工作台 | 核对医嘱、承接、执行和结果发布，不代替医生作临床确认 |
| Finance／Billing & Insurance 后台人员 | 获授权的应收、保险回款、对账及报告 | 保留独立后台财务职责；Cashier 是护士操作功能，不另设 Cashier 角色，不重写临床记录 |
| 获授权管理员 | Catalogue、计划／优惠 App、资源与权限设置 | 管目录、价格、卡种和授权；登录账号不等于可预约资源 |

表内描述职责，不自动授予全部权限。已确认的[组织与对象关系](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#domain-relationships)、[查看／编辑矩阵](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)和[授权流程及例子](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#clinical-grants)集中在权限功能中；尚未确认的个别范围另行标注，不再笼统称整套权限矩阵待定。

### 2.2 哪一份记录是准的

| 对象 | 记录什么 | 与其他对象的关系 |
|---|---|---|
| Patient 患者主档 | 身份、联系方式、过敏／ADR、持卡及诊所关系 | 基础信息归集团、查询按角色授权；修改／确认保留诊所资格；公共医疗信息另按角色授权，改主档不覆盖历史快照 |
| Appointment 预约 | 医生、诊所、时间、就诊类型、资源、本次保障资料 | 表示预约安排；保存或确认不代表已到诊 |
| Encounter / Visit 就诊 | 本次到诊、准备、问诊、结账及关闭 | 到诊后业务主线；Registration 是操作视图，不另建一套患者或就诊记录 |
| Prescription / Order / Clinical Document | 医生在本次就诊产生的处方、检查和正式临床文档 | 必须关联 Patient + Encounter；各自有版本与状态 |
| Pharmacy Handoff | 某个签署处方版本的药房交接 | 同时展示备药状态与付款状态；两者独立 |
| Invoice / Payment / AR | 应收明细、实收记录和未结应收 | 开票不等于付款；财务记录不覆盖临床记录 |
| Card Programme / 患者持卡 / Visit eligibility | 卡种规则来源／患者卡号／本次核验结果 | 三者不可混用；有卡不等于本次费用已获承保 |

患者级 Consultation History、Medication History、Vaccine History、Vital Trends 和 Attachments 都是原始就诊记录的检索视图。不能在这些历史视图中生成第二份脱离就诊的临床事实。

## 3. 一次普通门诊如何流转

以下为**存在收费项目的普通门诊** 。特殊类型见第 5 节；完全无收费来源的情况见 Consultation PRD 的当前实现与差距。

```mermaid
flowchart TD
  A[预约 / 到诊 / 护理准备] --> B[医生 Consultation]
  B --> C[Review & Complete 签署并交接]
  C --> D[有处方：药房逐项审核，整单预留库存]
  C --> E[Cashier 预核对其他费用；不能提前收款]
  D --> F{审核与预留全部通过?}
  F -->|否| G[药房退回整张处方；立即阻断结账]
  G --> N[护士在 Cashier 手动确认退回问诊]
  N --> B
  F -->|是| H[Cashier 统一结算确认]
  E --> H
  H --> I[待备药 → 备药中 → 待复核 → 待发药]
  I --> J[整张一次现场交付]
  H --> K[当场结账与离院安排]
  J --> L[满足全部关闭条件且首次签署满24小时：Closed]
  K --> L
  C --> M[有检查：独立 V-Lab 执行与结果闭环]
```

**阅读重点：** 医生签署后，Cashier 费用预核对与药房审核并行，实际收款必须等待药房整张审核及预留通过；Cashier 统一结算确认后才开始备药。审核退回按药房 PRD先建立 Cashier 阻断，护士在 Cashier 明确确认后才恢复 In Consultation；重新签署后仍需药房再次审核通过才解锁。内部检查也有自己的执行状态；不应因为患者结账而自动写成检查完成。图中各分支只在本次确有相应处方或医嘱时产生。

### 3.1 每次交接交出什么

| 上一岗位 → 下一岗位 | 触发动作 | 必须交出的资料 | 接收方应看到 |
|---|---|---|---|
| 前台 → Registration | 预约 Confirmed，且在当日 | 患者、医生、预约时间、类型、保障快照、Remark | Awaiting check-in；不是 Checked in |
| 护士 → 医生 | Preparation 全部必要项完成 | 同一 Visit、已核对身份、必要 Vitals、护理备注、保障准备结果 | Ready for consultation，可开始问诊 |
| 医生 → Cashier | 最终阶段完成，收费交接成功 | 已签署收费来源、数量、价格、折扣来源和版本 | Ready for Cashier，尚未付款 |
| 医生 → Pharmacy | 处方签署 | 处方版本、药品用法数量、过敏／风险及付款状态 | 待审方；可先审核，未取得有效结算确认不能开始备药 |
| 医生 → V-Lab | 确认内部检查医嘱 | 项目、患者／Visit、样本或部位、准备要求、优先级 | Ordered，等待承接 |
| Cashier → Pharmacy | 本次结算满足 Cashier 唯一契约并经显式确认 | 当前有效处方及费用版本对应的结算确认及其方式；[付款／欠款契约](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#cashier-settlement) | 审核及库存通过则解锁开始备药；不自动代替实物操作或发药 |
| V-Lab → 医生 | 结果 Released | 结果版本、来源、异常标志、原医嘱 | 待 Doctor Acknowledgement；不自动等于已阅读 |

## 4. 状态与允许操作

### 4.1 预约及到诊准备

| 当前状态 | 谁执行什么 | 前提与结果 | 不允许的行为 |
|---|---|---|---|
| Unconfirmed | 前台 Confirm | 进入 Confirmed；当日记录出现在 Registration | 未确认就当成已签到 |
| Confirmed | 前台退回未确认／改约／取消 | 保留原值、操作者与原因；改至其他日或取消后离开当日 Registration | 取消后删除历史或继续占用有效时段 |
| Awaiting check-in | 关联护士核对后 Check-in | 建立或复用唯一 Visit，预约成为 Checked-in，Visit 为 Arrived | Calendar 快捷按钮未核对就写入签到成功 |
| Checked in | 关联护士 Continue to preparation | 同一 Visit 进入 Preparation | 重建患者或第二次 Visit |
| Preparation | 护士 Ready for consultation | 身份、保障及被要求的准备项齐全；进入医生或服务队列 | 忽略缺失的必要项目直接送诊 |
| Ready for consultation | 医生 Start；或授权人员 Previous stage | Start 后 In Consultation；回退须填原因，回到 Preparation 并从医生队列移除 | 前台直接编辑／取消处于 Ready 的预约 |
| Preparation | 授权人员 Previous stage | 填原因后回到 Checked in，保留 Vitals、附件及同一 Visit | 清除已记录资料、自动退回 Unconfirmed |

Ready 后，预约与登记核心编辑锁定；Visit 附件入口按当前权限可保留至 In Consultation，不用“锁定”一词误判所有附件操作都应消失。In Consultation 与 Ready for Cashier 在 Registration 中属于末尾的运营追踪记录。

### 4.2 问诊、结账和关闭

本表说明业务目标及合法流转。当前普通门诊完成使用原子事务，失败全部回滚；Handoff failed 中间态与完整自动关闭仍有缺口；药房退回／Cashier 阻断已有实现，其范围见药房和 Cashier PRD，详见 Consultation PRD 和实现附录。

| 状态 / 事件 | 业务含义 | 合法后续 |
|---|---|---|
| In Consultation | 医生正在处理本次就诊 | 保存草稿、开药开单、Review & Complete；签署不等于收款 |
| Clinical signed / Handoff failed（待实现设计） | 临床已签，但必要收费交接失败 | 主状态保持 In Consultation，签署内容只读；重试交接，不能重复签署 |
| Ready for Cashier | 当前最终临床阶段已完成且收费交接成功 | 无临床阻断时 Cashier 复核／开票／记付款；药房审核退回先在本状态建立结算阻断，护士确认后才恢复 In Consultation |
| Checkout Completed | 当场结账及离院安排已完成 | 在受控条件下处理更正；不是永久锁定，不要求保险已实际回款 |
| Financial Completed | 全部付款方应收、退款或调整已结清 | 本期预留完整财务状态机；不能据此推断已发药或检查完成 |
| Closed | 本次就诊不可逆锁定 | 只读查询；后续结果、更正、退款用关联事件处理 |

**关闭规则 CL-01：** 临床已签署、Checkout 和付款／应收安排已记录、即时药房／V-Lab 交接已接收，且无患者安全或收费阻断时，系统在首次临床签署满 24 小时后自动关闭。待发药未实际交付或人工处理完结，属于最终关闭阻断。若满 24 小时时仍有阻断，应保持未关闭，待阻断解除后满足条件再由系统关闭。付款或修订不重新起算计时；没有人工 Close 按钮。

保险未回款或已有安排的患者欠款留在 AR，不阻止 Closed；长期待出的检查结果可作为关联 Result Event 回传。**已确认付款安排可满足备药条件，但未领取的药品会阻止最终 Closed。** 非医生服务及无收费分支的关账／关闭触发仍需补充确认，不能套用不存在的临床签署时间。

### 4.3 已签署记录怎么修订

**CL-02：** 从首次 Review & Complete 起算，24 小时内仅原签署医生可发起 Controlled Amendment，必须填原因并形成新版本；超过 24 小时但尚未 Closed，需 Medical Director 或获授权 Clinical Administrator 批准。前台、护士及 Cashier 不能直接改临床内容。

药房审核退回按[药房 PRD](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html)走处方修订：无付款／结算历史、未 Closed 且未最终发药时，药房先退回整张处方并阻断 Cashier；护士在 Cashier 确认后才把 Encounter 回到 In Consultation。保留原病历与历史签署，不重建整次就诊。Closed 后一律不得重开、覆盖或直接修订原记录；关联更正必须保留原事实和关联关系。

## 5. 七类就诊如何分流

Appointment 只使用下面七类 Consultation Type。Lab / Imaging 是开单及执行子流程；Tele-Medicine、PPP、CRC、Normal 和 Out Reach 不构成本期另一套预约分类。

| 类型 | Preparation 后去哪里 | 医生阶段后的流程 | 功能边界 |
|---|---|---|---|
| Consultation | 医生队列 | 普通问诊 → Pharmacy／检查／Cashier | 标准主流程 |
| Prescription-only | 医生队列 | 医生签署 → 审方与库存预留 → 统一结算 → 备药 | 不能让药房代开处方，不能因只取药而跳过医生 |
| No Consultation | 护士／Service Queue | 执行获授权服务 → 按实际收费交接 | 唯一不进入医生 Consultation Queue 的类型 |
| Day Procedure | 医生队列 | 术前评估 → Procedure Consent → Preparation → In Procedure → Recovery / Observation → Procedure Completed → 最终收费 | 不能从签到准备直接跳过医生术前评估；恢复／观察未完成不能提前作为最终完成 |
| Physical Examination | 医生队列 | 检查计划 → 结构化检查／Tests → Results → Examination Report → 最终收费判断 | 报告签署人、等待结果条件等见待确认项 |
| Vaccination | 医生队列 | 复用问诊主干并应用已批准的接种差异要求 | 不因历史页有记录就认定接种执行已完成 |
| Hospital Appointment | 医生队列 | 复用问诊主干并应用已批准差异要求 | 外部医院执行不由本系统自动推断 |

除 No Consultation 外，共用医生队列、身份核验、病历、保存、签署、异常及复诊主干。差异仅来自获批准的类型规则；缺少规则时不得声称特殊业务已经完整交付。Walk-in 是到诊来源，不是第八种就诊类型，也不是付款方式。

## 6. 功能规则的唯一维护位置

本页只维护跨岗位数据归属、交接和状态。具体字段、按钮、异常和版本规则在对应板块更新，不再复制整套功能表。既有编号保留用于测试追溯。

| 既有规则编号 | 唯一业务正文 | 配套工程细节 |
|---|---|---|
| PT-01～06、AP-01～05、RG-01～04 | [患者、预约、到诊与护理](https://virtus-patient-emr-prd.vercel.app/frontoffice.html) | [Patient 字段、取数与 API](https://virtus-patient-emr-prd.vercel.app/patient-reference.html) |
| DR-01～07、RX-01～04 | [Consultation](https://virtus-patient-emr-prd.vercel.app/consultation.html) | [问诊工程规格](https://virtus-patient-emr-prd.vercel.app/consultation-reference.html)；当前实现与目标差距分列 |
| CD-01～05、CC-01～05 | [Clinical Documents 与模板](https://virtus-patient-emr-prd.vercel.app/documents.html) | [内嵌工作台](https://virtus-patient-emr-prd.vercel.app/documents-reference.html)、[模板内容模型](https://virtus-patient-emr-prd.vercel.app/templates-reference.html) |
| PH、RXPH-FR、LB-01～04、IN-01～04 系列 | [Drug Dispensing、库存与 V-Lab](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html) | 同页保存药房 API、阶段与代码边界；不再维护第二篇处方交接 PRD |
| BL、FU 系列 | [Cashier 与诊后](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html) | Cashier 执行证据（仓库资料：../test_cases/cashier/README.md） |
| MD-01～07 | [目录与价格](https://virtus-patient-emr-prd.vercel.app/catalogue.html)、[组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html) | [目录底表适配台账](https://virtus-patient-emr-prd.vercel.app/catalogue-contracts.html) |
| AI-01～03、平台治理 | [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html) | 领域接口与迁移文档经仓库索引（仓库资料：../README.md）进入 |

旧编号继续用于历史测试追溯：DR-01→问诊§2（CQ）、DR-02→§2／§8（上下文与Reference）、DR-03→§3（CN）、DR-04→§1／§2（草稿与患者切换）、DR-05／06→§7（CB，含无收费目标差距）、DR-07→§7.3（复诊当前行为与目标差距）；RX-01→问诊§4.1（CP，处方字段）、RX-02→问诊§4.3（签署交接）、RX-03→问诊§4.3及药房§5（修订）、RX-04→药房§5.3／§6（实物返工与受控更正）。具体规则只在对应章节维护。

工程文档保留字段映射、接口、迁移约束和独有验收细节；发生冲突时先区分已确认业务目标与代码事实，不以较旧工程段落覆盖后续明确决策。

## 7. 跨模块共同控制

| 编号 | 触发情况 | 预期行为 |
|---|---|---|
| CT-01 | 角色／诊所／患者关系不满足授权 | 拒绝读取或写入；不能只隐藏按钮而允许后台请求；不泄露无权访问的患者信息；已确认同集团公共读取按其独立规则执行 |
| CT-02 | 重复点击／网络超时重试 | 复用原业务操作，显示真实结果；不得重复生成记录或收款 |
| CT-03 | 保存失败或版本过期 | 保留输入并说明失败；刷新后状态仍是服务端真实状态，不能先显示“已完成” |
| CT-04 | 临床签署、回退、更正、取消、折扣、付款、导出 | 记录谁、何时、对哪次就诊做什么、原因及前后版本；可从业务记录追溯 |
| CT-05 | 历史迁移记录／Closed | 默认只读，显示真实来源；不进入当天可写 Active 队列；晚到结果用关联事件 |
| CT-06 | 无数据、无权限、接口错误、仅预览能力 | 显示各自明确状态；不能用演示患者、示例卡片、假药品或本地成功替代真实响应 |

## 8. 测试与交付证据

先使用[业务测试用例](https://virtus-patient-emr-prd.vercel.app/acceptance.html)的 E2E-01 普通门诊闭环，再执行对应功能与异常用例。用例定义预期；实际结果与测试版本在测试证据索引（仓库资料：../test_cases/README.md）记录为 Pass、Fail、Blocked 或 Not run。

测试使用同一 Patient、Clinic、Encounter 及合成数据，并分别验证前台、护士、医生、药房、Checker 和 Cashier 的授权。一个管理员账号、静态页面或 CI 通过不能替代各岗位完整链路验证。

实现缺口与待决定事项集中到[交付状态](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)。本地完整部署、开发分支发布、Vercel App、PRD 发布、STG 联调和 UAT 分别计证；本轮文档治理不改变业务验收状态。


---

# 患者、预约、到诊与护理 PRD

更新：2026-09-14 · 责任：Line A · 配套：[业务总流程](https://virtus-patient-emr-prd.vercel.app/index.html)／[测试用例](https://virtus-patient-emr-prd.vercel.app/acceptance.html)

本篇说明患者从资料登记、预约到实际到诊的工作流程。前台负责预约和基础资料维护，护士按所在诊所及服务医生关系完成签到和护理准备。各入口共用同一份患者资料，访问范围见 [权限方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。

本次权限调整已写入需求，仍待对应实现和验证。此前回归及发布记录见权限验证（仓库资料：../test_cases/access_control/README.md）。

## 功能地图

按患者建档、预约、实际到诊三个业务对象组织；界面、字段与异常放在所属功能内。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 患者资料与历史 | 前台／护士／医生 · Patient | §2：识别、建档、资料更正、计划维护、历史及附件 |
| 患者自填与审核 | 患者／护士 · Intake Draft | §3：专属链接、身份确认、提交、审核与修正 |
| 预约安排 | 前台／护士／医生 · Appointment | §4：日历、时段资源、变更、本次计划及人工核验 |
| 到诊与护理交接 | 关联护士 · Visit | §5：签到、准备、队列、回退与 Walk-in |

## 1. 三个入口如何协作

Patient & eMR 管一个人的长期资料，Appointment 管某次预约安排，Registration 管当天到诊和准备。三者共用患者主档和同一预约／Visit 关联。患者从哪个入口来，不应决定他有几份档案。

| 入口 | 首屏任务 | 详情／编辑 | 离开后的结果 |
|---|---|---|---|
| Patient & eMR | 同集团获角色查询权限者可检索患者基础资料；自助登记审核待办仅对具审核资格者展示 | Overview、Consultation History、Medication History、Vaccine History、Vital Trends、Attachments、Communication History 各自检查数据权限 | 获授权后保存主档或查看原记录；可带患者进入预约，搜索结果不解锁病历 |
| Appointment Calendar | 左侧日历、右侧所选日期 Grid／List；筛选医生、类型及状态 | 统一预约表单、Block-out、改约和历史 | 保存预约，不自动签到 |
| Reception / Registration | 当日待签到／准备／Ready 工作及下游追踪 | Check-in、Preparation、附件、修改预约、相邻回退 | 同一 Visit 进入医生或护士服务队列 |

旧设计的“只保留 Overview／Timeline”不覆盖后来确认的患者级历史 Tab。页面数量也不构成业务验收指标。

## 2. Patient & eMR

Patient & eMR 保存患者的长期资料，也是查询历次就诊的入口。工作人员先搜索患者，核对身份后打开已有档案；确实没有记录时，再按建档权限新建，避免重复登记。

前台可以维护基础信息；护士和医生按各自权限维护其他资料。患者可以关联多家诊所，查询基础信息、修改主档和查看完整病历分别判断。保存后的主档由各业务入口共同使用，历次就诊仍引用原记录。

### 2.1 字段定义

| 资料组 | 字段 | 必填／来源／维护规则 |
|---|---|---|
| 身份 | 姓名、主手机号、HKID／护照号 | 新建三项必填；登记与预约新增共用；患者主档 HKID／护照号最多 32 字符，创建、身份编辑及到诊回填均拒绝超长值且不截断、不部分保存；预约自身证件号仍可保存最多 64 字符，转入患者主档前须符合 32 字符限制；Patient No. 由系统产生 |
| 补充人口资料 | 中文／英文名、生日、性别、证件类型／国家 | 一般员工建档其他项可后补；H5 提交要求见第 3 节；未知不自动存默认值 |
| 联系 | 备用电话、Email、WhatsApp、地址、语言、紧急联系人 | 可选；联系号码相同不必然是重复患者 |
| 通信偏好 | Receive clinic messages | Yes／No／Not recorded；不等于治疗或共享资料 Consent |
| 安全资料 | Allergy、ADR、Alert；物质／反应／严重程度／核实状态／备注 | 三种语义分开；保存修改原因、作者和时间；未记录不是“无” |
| 持卡 | 目录卡种、Member／Policy No.、有效期、主卡、备注 | 患者实例，不复制合同规则，不保存上次就诊 eligibility 为永久事实 |
| 诊所关系 | 诊所、状态、建立来源和时间 | 首次注册来源及有效 Visit 形成所属诊所；预约仅是运营关联，不能单独产生维护资格；不维护 Primary Clinic |
| 历史 | Consultation、药品、疫苗、Vitals、附件、通信 | 从原始记录读取，保留就诊／诊所／日期／来源，不另建临床事实 |

**患者卡片的诊所标识：** 只展示患者资料返回的有效诊所关联名称；多个诊所并列，不建立单一 Primary Clinic。没有诊所名称时，只有后端明确标记与当前诊所有关联，才可显示当前诊所名称并标明关联；其他诊所显示 Other clinic，关联未知则显示未记录。当前岗位、Nurse／Doctor 角色和工作场景不能填入患者卡片，也不能因患者可被搜索就将其归到当前诊所；当前操作者身份仍可在工作台顶部显示。此展示修正不扩大历史读取或护理授权。

### 2.2 创建、重复校验与修正

**PT-01～PT-04：** 先搜索再创建；证件完全匹配或规范化姓名＋主手机号同时匹配时阻止重复保存，显示命中依据，允许打开已有患者或返回修正。单姓名或单电话相同只提示候选。本期不自动合并患者；治理人员处理误匹配／确需合并的操作规程仍待确认。

保存后各获授权业务入口读取同一最新主档。修改需要原因及新版本；恢复旧内容也应形成新版本，不销毁后续历史。同集团具角色查询权限的人员均可搜索和查看患者基础信息，不受当前诊所关联限制；修改、确认与临床历史分别校验。前台可新建、修正和确认基础信息，不能维护医疗／安全资料或保险计划。护士创建或管理预约仍限当前 Clinic 的有效服务医生范围。预约可以保留运营关联，但不产生患者资料维护资格；有效首次建档来源、既往 Visit 或另行批准的接收资格按 [患者资料维护规则](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#patient-profile-access) 判断，也不开放他医 Note／处方。搜索精确字段和脱敏默认见 [组织、数据权限与授权方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。此规则取代旧的 Patient & eMR 一律仅显示当前诊所患者口径。

**患者资料保存边界：** 基础资料查询按集团及角色授权返回，敏感字段默认隐藏；申请查看须提示操作审计并经独立字段权限判断，详见 Platform §3.2。有维护动作权限，且当前诊所为患者所属诊所或已取得转诊／推荐／另行批准的新预约资格时，才能维护相应患者资料；普通登记 link 和预约 Confirmed 不代替批准。编辑页只提交实际修改的可维护字段，未返回的病史或保险数据不视为空值。最小安全摘要的更正另需选择本人负责的 Visit，并保留原详细备注；身份版本与安全摘要版本分开分类。

**保险资料独立保存：** 保险卡按当前诊所运营权限单独加载与保存，不随患者资料版本隐式覆盖或删除。保存前校验整组待修改卡片，仅可删除本次确实加载过的卡片；新增、修改及删除记录实际操作者和变更原因。若多卡保存部分成功，必须重新读取当前记录再继续，不能将保险保存结果描述为患者资料版本已整体保存。

### 2.3 历史查看与附件

疫苗为同集团公共记录，获独立公共医疗信息角色读取授权的医生与护士跨诊所读取无需原医生逐记录批准，旧记录缺少 Visit 来源不影响读取；写入仍保留原医生权限及修改审计。其余信息按 [数据分类与读写矩阵](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix) 逐项判断：同集团公共医疗摘要、生命体征等共享资料仍需角色级读取授权，不因来源医生不同逐记录审批；完整 Note、诊断详情、检查结果、正式临床文档、历史附件及处方按来源医生授权判断，药房执行读取另按对应诊所范围，隐私字段独立检查；当前患者可搜索或本次已预约，不表示全部历史可读。受限时提供共用申请入口，不返回正文后再遮罩，也不显示为“无病史”。

| 历史视图 | 主要内容 | 核心验收 |
|---|---|---|
| Consultation History | 原问诊、病历、诊断、药品、服务、文档和附件 | 同一次就诊聚合；迁移与原生来源分清 |
| Medication History | 原处方日期、医生、药品、SIG、数量、疗程、执行结果 | 不重复复制诊断作为新数据；开药与实际发药可区分 |
| Vaccine History | 已返回的接种服务名称、日期、来源、状态和 Remark | 未返回批号／厂家／剂次等不能补造；空白不代表从未接种 |
| Vital Trends | BP、体重、脉搏、体温、SpO₂、BMI 及原始测量表 | 每点可追溯原测量；纠正回原记录；BMI 推算标清来源 |
| Attachments | 当前／历史原文件、分类、日期及来源；OCR 预览 | 查看授权文件，OCR 可核对但不覆盖原件；不可访问显示错误而非空文件 |
| Communication History | 真实回访／通信记录或明确空态 | 没有渠道／历史接入时不显示示例沟通、已送达或统计数字 |


<a id="2026-09-08-当次问诊附件上传与识别"></a>


<a id="44-patient--emr-计划维护对齐2026-09-07-确认"></a>

### 2.4 患者持有的保险与企业计划

患者资料编辑的 Insurance cards 页签、共享维护组件及 Overview 汇总统一为 **Insurance & Benefit Programmes**。Add programme 从一个共享目录选择保险、企业计划、员工福利；保留真实类型和 Policy／Benefit Contract 来源，不合并成 insurance 类型。空记录不代表 Self-pay。

- 保险字段为 Insurer、Member no.、Policy no.；企业为 Organisation、Member / employee no.、Programme no.；员工为 Organisation、Employee no.、Programme no.。有效期与患者计划备注一并维护。
- Primary 文案改为 Patient default，表达患者档案偏好；它只用于展示排序，不替患者选择本次付款安排。
- 更换目录计划时保留患者持有记录及默认标记，但清空旧个人编号、有效期、资格和备注，防止将旧计划资料套入新计划；重复选择同一计划保留已填信息。
- 患者计划维护及预约选择共用类型语义；读回时保留元数据中的企业／员工来源，维护无目录 ID 的旧计划亦不得丢失已记录的类型。修改患者主档不自动重写预约／Visit 的历史快照。
- 公开预览仅使用显式 preview 路由的合成患者及目录；资料编辑可应用到页面会话，刷新重置，不调用真实主档保存接口，也不模拟正式版本审计完成。

### 2.5 附件上传与识别

**本次附件由关联护士管理。** 护士在当前诊所服务本次负责医生，并具有附件操作权限时，可以上传、查看和删除本次问诊附件，无需额外申请临床记录授权。前台不管理附件。

查看历史附件时，应检查原记录授权；当前服务关系或将文件复制到本次，都不能代替批准。删除操作保留来源和审计，保护已签版本及引用证据。附件管理也不授予正式临床文档撤销权，详见 [权限方案 §3.5](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#operational-access)。

- 每个附件最大 10 MB（10 × 1024 × 1024 字节），允许等于上限；多选时逐个文件上传，不把多个文件合并计算。超限在选择时明确提示；服务端仍独立校验。该上限用于统一文件接口，不改变 Excel 导入或录音专用接口的独立规则。
- 选择文件后的状态是「Ready to upload」，必须点击 Save attachments 才写入。发送时显示 Uploading，失败显示 Upload failed 及可重试错误；每个成功文件立即显示 Uploaded 并关联 Patient＋Visit，后续文件失败不反转已成功结果、不重复上传成功文件。
- 文件保存与 OCR 是两个独立结果：识别尚未完成／失败不使已保存附件变成 Pending。识别失败保留原件；同内容文件在另一 Patient／Visit／Clinic 必须分别建关联，不能按文件内容直接复用别的问诊附件。
- 当前改动待本轮专项验证；Git、预览发布、STG 配置生效和业务 UAT 分别记录，执行证据见 `agent_docs/test_cases/attachments/validation-20260908.md`。

## 3. H5 自助填报与审核

**功能目的：** 减少重复录入，由患者确认信息、护士审核后写入正式资料。

**使用者与对象：** 患者处理专属填报草稿，获授权护士发码与审核。

**操作与结果：** 预填发码 → 患者填写并确认身份关联 → 提交 → 护士核对／修正 → 批准或退回澄清。

**关键边界：** 提交不直接覆盖主档；身份修正或旧确认缺失由护士核实处理，修正、核实依据与患者原始 Consent 分开留痕。

**2026-09-07 用户确认（取代旧的提交后常规重复患者核验）：** 在患者填写后的核对确认环节完成匹配；患者确认本人信息一致后关联已有患者。护士审核页展示已确认结果，不常驻疑似重复提示或再次要求关联同一患者。

**PT-06 状态：** Intake Draft → 有效患者专属链接 → 身份匹配／患者确认关联或新患者 → Submitted → Awaiting review／Needs clarification → Approved 或 Rejected。身份更正导致确认失效时保留待审核，由护士核实后继续；链接 Expired 由服务端控制，不使已提交资料必须重填。

| 阶段 | 谁操作与字段 | 结果／边界 |
|---|---|---|
| 预填与发码 | 护士：姓名、主手机、证件号 | 先有草稿再发 48 小时令牌；二维码不直带身份资料，无 OTP |
| 基础资料 | 患者：核对预填，补英文姓名、手机、生日、性别、证件类型和号码 | 基础项必填；原值保留 |
| 额外资料 | 中文名、Email、地址、联系人、语言、协助需要 | 可逐项填或整体跳过 |
| 保障选择 | 患者：搜索共享卡种目录，选择 Insurance／Corporate／Staff 计划，填写个人卡号／会员／员工号、可选保单／企业计划号及生效／到期日 | 无保障可跳过；选卡后个人编号必填。切换卡种清除上张卡的个人编号和日期，避免错误继承 |
| 核对与关联 | 系统在有效令牌范围内匹配；患者确认脱敏候选是本人，或确认新患者资料 | 只返回与此草稿相关的最小候选与不透明确认凭据；不得提供公开全集团患者搜索。患者未确认、信息不一致、请求失败或身份修改后不得按已关联直接提交 |
| 提交与同意 | 核对完整基础／额外／保障内容；患者身份确认、个人资料 Consent、可选通信同意分开 | 提交保留确认凭据；已有患者关联稳定 ID，但仍不自动覆盖主档。正式新建仍由获授权人员批准和服务端事务处理 |
| 护士审核 | 展示关联编号／新患者结果及各项资料；卡号／保单号等敏感值默认隐藏，独立申请查看获准后才显示 | 正常审核页不重复显示 Possible match／重复对比；护士可编辑、保存修正、待澄清、批准或拒绝 |
| 修正与历史 | 每次真实修改必填原因；保存原始提交、每次字段前后值、操作者／角色、诊所、时间 | 修改身份匹配字段使原确认失效，护士核对并记录依据后由服务端重新匹配；不得提交任意 Patient ID 强行关联或代替患者修改 Consent。核实通过后才能批准。待澄清和拒绝也必须有原因 |

**界面：** 审核时收起非当前任务的患者搜索栏和重复待办横幅；主区使用全部可用宽高。列表与详情随 App 容器宽度改变，760px 以下变为横向选择列表＋纵向详情，480px 以下详情字段单列。正文滚动、主要动作保持可达。Pending／Clarification／Reviewed 可切换；历史及原始提交在处理后仍可查看。编辑中取消须确认丢弃。

**审核权限与归属：** 正式审核由获授权护士按当前有效 Clinic 任职及生效权限执行；前台的基础字段维护权不包含整份 H5 提交批准：查看需要 `patient.read`，修正、批准、拒绝、待澄清及重发需要 `patient.write`。填报草稿绑定发码时的集团与 Clinic；有预约关联时必须与该 Clinic 和患者一致，不能凭患者姓名、预约地点或 `Confirmed` 状态自动跨诊所转移草稿。护理的 Provider 服务范围与患者基本资料登记分别管控，审核不授予完整 Note／历史处方权限。

审核中的保障卡选择使用患者登记所需的最小有效卡种目录，不额外要求保险合同管理权限，也不开放合同配置或图片管理接口。首次队列加载失败必须明确显示错误及重试入口，不能显示为没有待审核资料；保存过程中禁止继续修改字段，避免提交后遗漏修改。

**批准与资料写入：** 审核使用服务端保存的患者确认或护士核实结果，界面不能提交另一个 Patient ID 强行关联。已有患者仍必须满足当前 Clinic 的主档维护资格；仅有普通预约不绕过该资格。新患者在批准事务中完成重复身份检查、建档及注册来源 Clinic 归属；批准失败不留下半条患者或保障记录。提交、修正和最终批准保留原始提交、当前版本、操作原因和实际操作者，批准同时校验填报版本和已有主档版本；另一人已处理或主档发生变化时必须刷新核对，不能用旧画面覆盖新资料。

**护士核实与异常处理（2026-09-14 用户确认，取代默认退回病人重新确认）：** 正常自填审核由护士处理。非身份修正保存后可继续批准；身份字段实质变化、旧记录缺少可信身份确认凭据，均显示「待护士核实身份」，不自动退回病人。当前 Clinic 下具 `patient.write` 的有效 Nurse 可在审核页记录核实依据并执行「护士核实身份」。服务端依据当前提交重新匹配，返回已匹配病人编号或新病人结果；护士核对该结果后批准。患者原始提交及 Consent 保持不变，护士核实单独记录来源、操作者、诊所、时间、依据及草稿版本，不伪装为患者重新确认。

护士核实不能绕过已有病人的主档维护资格、预约病人一致性、重复身份检查或并发版本控制。匹配冲突时护士应核对修正资料或按现有主档流程解决冲突；系统不允许任选其他病人或强行新建。已提交资料即使旧链接过期、已经重发或处于待澄清，也可由护士核实后继续审核；没有提交内容的空草稿不能核实，已批准／拒绝／撤销／旧版 reviewed 不可重开批准。

仅在护士无法解决的信息疑问、确实需要病人补充时才使用待澄清及可选重发链接；重发的 48 小时有效期、旧链接失效和历史保留规则继续适用。护士不能代填个人资料 Consent 或通信同意；缺少必要 Consent 的记录仍需补齐真实患者同意，不得通过身份核实动作自动生成。旧版 `reviewed` 仍仅表示旧版已审核，新 `approved` 才表示本流程事务写入成功。

**实现边界：** 已有正式令牌／提交服务；本轮接通真实审核页面与审核状态、原始提交／修正历史、版本校验、患者确认及事务写入。独立预览仍只使用合成数据，不充当保存结果。2026-09-14 护士核实改动及本轮验证／发布状态见护士核实执行证据（仓库资料：../test_cases/patient_self_entry/nurse-verification-20260914.md）；此前流程验证见原执行证据（仓库资料：../test_cases/patient_self_entry/live-review-20260911.md）；本段不声明目标环境已发布或 UAT 已通过。

## 4. 预约与资源日历

**功能目的：** 把患者、医生／资源、时间和本次付款安排组成可执行的预约。

**使用者与对象：** 前台／护士及获授权医生；对象为 Appointment、Provider 和 Resource。

**操作与结果：** 选择患者和有效时段 → 填写预约与付款安排 → 保存／确认 → 到诊时进入 Registration。

**关键边界：** 保存预约不等于签到，不赋予跨诊所资料编辑或他医病历权限。

### 4.1 新建及编辑字段

| 字段 | 业务规则 |
|---|---|
| Patient | 同集团按角色查询；选定后核验身份。新增／改基础信息进入共享表单并检查诊所资格；前台仅可维护基础字段，其他数据依对应权限处理后返回 |
| Assigned Provider | 有医生参与的预约使用稳定 Provider，不能按同名首项匹配；Provider、资源与登录用户分开。No Consultation 的资源／护理语义见 Platform 待确认项，不对全部历史预约强制补造医生 |
| 日期、开始时间、时长／结束时间 | 必须有效；保存时重查排班、Block-out 与资源条件 |
| Consultation Type | 七项固定分类；不能把 Lab／Imaging 另列为第八项 |
| Service / Resource | 对应诊所服务、房间及设备；完整多 Assignment 为目标需求 |
| Payment Arrangement | 待确认／Self-pay／Insurance & Benefit Programme 三个入口；保险、企业、员工计划在一个已持有计划列表中选择，保存本次具体来源 |
| Case No.／Eligibility／Notes | 本次预约独有；换卡时处理不兼容上下文，新预约不继承上次结论 |
| Remark | 预约及护理交接说明；日程摘要直接显示，不伪装安全警示 |

### 4.2 操作、状态和异常

**AP-05 未指定医生：** 先记录诉求、症状及必要背景，按专科、诊所、排班、语言和付款限制提供候选医生及理由，由患者或授权人员最终确认。信息不足或无匹配转人工；推荐不构成诊断，也不自动保存预约。该推荐闭环仍是目标，不能以固定医生列表或专科字段代表已实现。


**AP-01～AP-04：** 新增、日历空格、Reception、患者档案与复诊共用同一预约入口；一般保存状态按明确选择，Reception 新增默认 Confirmed。Unconfirmed 可确认或由 Confirmed 退回；改约与换医生走 Reschedule。取消保留记录并释放有效时段，当日取消排在有效日程之后。

**日历布局：** 左侧日历与右侧所选日期 Grid 使用同一时间比例，卡片位置及高度反映实际开始时间和时长；短预约不能因文字或按钮的最小高度而覆盖相邻预约。左侧优先显示时间与患者姓名，再按可用高度逐层显示预约类型、医生及状态；右侧短卡及重叠列使用紧凑内容，较长卡片才展开补充资料。完整姓名、医生、类型、状态及预约备注可通过悬浮或键盘聚焦提示查看，不把被省略的内容画到卡片背景外。Grid 保留 Detail 与 More 两个紧凑入口，确认／退回未确认、Check-in、打印标签、提醒、历史及取消仍通过原权限与状态校验后操作；不足以容纳按钮的极短预约使用整个事件条打开完整详情及全部操作。More 可用键盘打开、遍历并以 Escape 关闭。List 保留现有资料列与操作排列。

**预约范围（2026-09-08 用户确认）：** 护士可查询同集团各诊所预约并创建预约；跨诊所总览不提供直接改期／取消。只有原本具目标诊所维护权，切换到该诊所作为当前工作诊所后才能修改；无维护权不允许靠切换或修改请求参数取得。医生的有医生参与预约按本人或有效显式授权过滤，列表、日期统计、医生选项和直接详情一致，完整关系规则见 [组织、数据权限与授权方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。Calendar 显示当前操作诊所与记录来源；切换后清除失效编辑表单并丢弃旧请求。

新预约仅提供本次业务资料。医生需要其他医生既往记录时，从患者详情的共用申请抽屉发起申请，不因为预约成功或恢复诊所关系而直接开放历史。申请流程不阻塞已获授权的身份核验和预约工作。

仅关联护士可使用 Calendar 的 Check-in 跳转 Registration，跳转不提前签到；前台不显示签到入口且直接接口拒绝。Ready 后须带原因回 Preparation 才允许修改或取消；已 In Consultation 的患者不能从前台取消。已到诊记录的回退／取消由获授权关联护士按状态处理；涉及 Appointment 与 Visit 时同一事务提交，失败整体回滚，前台不能借取消预约操作改变签到／护理状态。

Doctor Block-out 填医生、日期、开始／结束、原因及备注。普通问诊与 Prescription-only 不能落入 Block-out；No Consultation 只按护士服务例外处理，仍需检查资源。已有预约不能因新增 Block-out 被悄悄删除或改期。

完整资源需要稳定 Resource ID、诊所、能力、容量、开放时间、Block-out、启停及权限；同预约多个 Assignment 共享主预约。容量冲突、多资源改约、资源停用影响分析仍为待开发设计。

No-show 宽限时间、迟到优先级及收费、资源冲突允许的例外尚待确认；没有确定参数就不预设“迟到多少分钟自动取消”。


<a id="43-本次付款安排2026-09-07-确认"></a>

### 4.3 本次付款安排

New / Edit Appointment 与 Registration 共用 Payment Arrangement 组件。它选择本次主要付款／保障安排；Cash／Credit Card 等实际收款方式及金额仍由 Cashier 确认。

- 上层仅三项：To be confirmed、Self-pay、Insurance & Benefit Programme。保险／Corporate／Staff 共用一个可搜索的患者已持有计划列表，小标签说明类型，不要求用户先区分合同来源。选择一个具体计划后，系统保留 insurance／corporate_membership／staff_benefit 的真实类型。
- 新预约初始为待确认。患者主卡／默认计划只决定展示优先级，不自动成为本次选择；无卡也不自动意味着自费。待确认可以保存及签到，但必须在完成 Preparation 前明确。
- 选了计划入口但没有选具体计划时不得保存，应选择计划或改为待确认。资格有效日期按预约／Visit 日期判断；选计划不等于已核验，更不等于已获全额支付保证。
- 自费只显示本次自付说明，不显示保险卡、资格或 Case 字段。计划显示机构、个人编号、保单／计划号、有效期与本次 Reference／人工计划审核／Coverage notes；企业与员工不叫 Insurer／Policy。
- 编辑和重新打开必须恢复本次已保存的选择与 Snapshot，不按患者当前默认计划或数组第一项重新选。患者主档后续修改不覆盖历史预约／Visit 的付款快照；同一已选计划重复点击保留本次填写内容。
- 更换患者、类型或具体计划，清除原计划的 Case、资格及备注；换后重新录入的本次信息明确绑定当前选择，不继承旧核验结论。患者个人主档不会被预约修改。
- 计划来自患者自己的已持有记录。后端验证患者归属和类型并生成 Snapshot，不信任客户端伪造的计划详情。保险引用 Policy；企业／员工引用对应 Benefit Contract，继续沿用现有主档。
- 预约保存至既有 `clinic_appointments.metadata.payment_arrangement`，包含版本、类型、持有记录 ID 和来源／基本资料 Snapshot；兼容旧 insurance_* 字段，保留其他 metadata。Check-in 传入 Visit 的 payer_snapshot，登记准备可保存本次安排并同步原预约；本次修改记录审计。
- 已进入 Ready／问诊后的安排变更需先按现有流程回 Preparation；存在账单时拒绝通过预约／登记直接更换，走 Cashier 调整。不会重写原发票、付款金额或临床签署记录。
- 企业／员工计划可能仅提供协议价或福利；不能仅凭选中计划建立企业应收或假定企业付款。后续保险全额／CoPay、实际收款及欠款确认统一进入 [Cashier 付款责任](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#cashier-payer-arrangement)，本次选择和人工核验只作为该步骤输入。
- 旧预约按其自身保存信息兼容读取，明确旧 Self-pay 保留自费，已有保险 Snapshot 保留保险，空值为待确认；无法可靠辨认的旧企业记录不按名称猜测类型，需重新选明确计划。旧 Visit 无新版付款快照时继续原有准备契约。
- 查询失败保留已保存选择并显示重试；搜索无结果与患者无计划分别显示空状态。选择器支持键盘焦点，所有新／编辑预约入口继续共享实现。

代码、本地浏览器、隔离 API／CI、预览发布与正式后台／UAT分别记录于 `agent_docs/test_cases/appointment_payment/validation-20260907.md`。


<a id="45-本次计划人工审核2026-09-07-确认"></a>

### 4.4 本次计划人工审核

Appointment 与 Check-in／Preparation 的计划板块统一提供 **Review and confirm manually（人工审核确认）**。展开后逐项确认：已核对患者卡及所选计划、已核对计划或个人资料变化、已核对本次日期的有效期；另分别记录资格结果和预先申请结果。此入口不调用旧保险 Check／Benefit QR 校验，不将本地资料比对表示为保险公司实时答复。

- 资格结果：Eligible（人工确认）、Not eligible、Awaiting confirmation。预先申请：确认不需要、需要且已获批、申请／批核待处理、尚待确认；选择已获批时必须填批核凭据编号。审核备注可记录确认方式、变化、限制及跟进事项。
- **Confirm manual review** 记录本次表单审核；保存预约／登记后，服务端记录实际登录审核人、UTC 时间、上述核对项及结果，绑定本次计划快照和就诊日期，并随 Appointment → Visit 保存。界面显示明确的人工审核结果；单独提交旧 `Checked` 或伪造嵌套审核人／时间不能建立审核证据。
- 待确认、不合资格、申请待批可以保存、签到或继续 Preparation，但不能完成准备交接。只有三项核对完成、人工确认合资格、无需预先申请或已获批，且计划在就诊日期有效，才能完成准备。自费继续不需要计划审核。
- 相同计划和日期再次保存保留审核人、时间和结果；更换计划／患者或就诊日期后重新审核。旧计划 Snapshot 的历史内容不由患者主档更新自动覆盖。已进入临床阶段或已有账单的变更继续沿用 §4.3 限制。
- 人工确认不是付款保证；第三方责任、自付金额、最终收费复核和实际收款仍由 Cashier 处理。旧 Visit 无新版付款快照的兼容契约不在本次进行历史数据迁移。

代码与验证证据见 `agent_docs/test_cases/appointment_payment/manual-review-validation-20260907.md`；公开预览使用合成记录及 Preview staff，真实审核人由后端认证上下文写入。正式后台部署、端到端联调与业务 UAT 单独验收。

## 5. Registration 与护理

**功能目的：** 把实际到诊患者完成必要准备后交给正确的医生或服务队列。

**使用者与对象：** 当前 Clinic 与负责医生有有效服务关系的护士；对象为同一 Appointment 关联的 Visit 及准备记录。前台无签到及护理执行权。

**操作与结果：** Check-in → Preparation → Ready；回退到相邻阶段保留同一 Visit、已填资料和原因。

**关键边界：** 准备未完成不交接；已经问诊的患者不从前台直接取消。

**RG-01：** 当日 Confirmed 进入 Awaiting check-in；未确认只留 Calendar。核对真实到诊后，写入一次关联 Visit、付款保障快照与到达记录。Check-in 读当前主档，仅回写员工实际修改字段，自动带值不能触发无意覆盖。

**RG-02：** Checked in → Preparation → Ready for consultation 必须逐步推进。身份三项齐全，本次付款安排已明确；选择计划时本次资格核验和有效期准备完成；被要求的 Vitals／Doctor pre-check 真实填写。页面自动读取核验结果，不新增几套重复“已核验”勾选。

**RG-03 队列排序目标：** 默认按实际到达时间优先，无到达时间才用预约时间；人工排序限同一运营分组。下游追踪记录不混入待处理队列；共享排序持久化未完成前，不声称跨终端已同步。

**RG-03～RG-04：** 护士成功后留在 Registration；Visit 同时出现在正确队列。No Consultation 到护士／服务队列，其余医生参与类型目标进入医生队列。Ready → Preparation 需原因且从医生队列移除；Preparation → Checked in 保留同一 Visit 和已录资料。

Walk-in 无预先预约也必须建立可追踪 Visit，来源标清。具体是否强制先建即时 Appointment 仍需确认，不能允许后续临床记录没有 Visit。

## 6. 测试入口与已知缺口

PT、AP、RG 用例检验正常流程、重复患者、跨诊所关系、取消／回退及幂等。H5 服务端、完整资源、共享队列排序、可配置准备门禁及特殊类型分流必须按[实现记录](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)标为部分实现／待开发；不能因页面可以点过就记 Pass。
## 全局主体切换与 Registration 范围（已确认）

Registration 只使用全局 Context Selector 的当前 Clinic／主体，不提供 App 内跨诊所混合筛选。Reception/Nurse 只能读取当前主体授权范围内的登记、到诊、候诊队列和患者基础资料；Nurse 还必须满足本人有效服务关系及医生授权。切换到另一有效主体后，重新获取 `auth context/ui_access` 并加载该主体数据；切换清空旧患者、队列、历史、角标、未保存表单及进行中请求，迟到响应不得回写新主体。列表、详情、签到、准备、回退和队列动作均由服务端再次校验主体、对象关系、状态和 capability。

### Appointment Calendar 的受控跨诊所日程视图（已确认）

Calendar 可提供“我的有效诊所”汇总视图，但只展示当前用户在各有效 Clinic 的日程元数据；Doctor 仅展示本人 Provider，Nurse 仅展示本人有效岗位／服务关系覆盖的诊所日程。该汇总视图不得展开跨主体患者、当前问诊、历史记录或附件；跳转其他 App 前，目标按全局当前主体重新校验，查看另一诊所必须先通过全局 Context Selector 切换主体。


---

# Consultation 业务与功能 PRD

更新：2026-09-14 · 业务角色：医生及获授权临床支持人员 · 实施状态见 WS2（仓库资料：../../dev_working/workstreams/phase_0/p0_ws2_consultation_patient_record_ai.md）

本文覆盖从队列进入、五个临床模块、辅助资料到完成问诊。**“当前行为”用于版本回归，“待实现设计”用于需求验收；两者不能互相代替。** 此前医生跨诊所本人记录、护士授权协作及统一历史边界按 [组织、数据权限与授权方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix) 完成实现及本地完整服务回归；本文不把本地验证、开发或预览发布当作 STG／UAT 已通过。2026-09-14 的数据分类、角色共享读取、本次附件和岗位边界为新确认契约，本轮只更新 PRD，不能沿用旧验证认定已实现。

## 功能地图

每个临床功能按操作目的、数据对象和处理结果展开；代码现状用于说明差距，不替代已确认产品目标。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 进入与恢复问诊 | 医生／护士 · Visit | §1–2：队列、上下文、开始／恢复及协作资格 |
| 病历与诊断 | 医生／获准护士 · Note | §3：模板、诊断、转写与保存 |
| 处方与修订 | 医生 · Prescription | §4：开药、提示、签署、退回和 Amendment |
| 检查项目 | 医生／获准护士 · Selection | §5：选项目、复制、推荐、保存与正式开单边界 |
| 临床文档 | 医生／获准护士 · Document | §6：内嵌文档与独立 PRD 交接 |
| 临床完成与收费交接 | 医生 · 签署版本 | §7：收费、检查清单、事务结果与复诊差距 |
| 临床参考 | 医生／护士 · 历史与附件 | §8：公共摘要、受限详情、OCR、Anatomy 与布局 |

## 1. 页面职责及入口

医生在本次 Encounter 内完成临床记录、结构化诊断、处方、检查选择、临床文档及收费交接。Patient & eMR 是患者主档与历史查询入口；关联护士在 Cashier 实际收款；Pharmacy 实际配药和发药。问诊工作台不替下游完成这些动作。

入口为 Consultation Queue；也可从携带患者／Visit 的授权业务入口进入。初始未选患者，只显示队列。选中后同一 Patient + Visit + Clinic 贯穿所有模块；不能仅按患者姓名建立问诊。

队列只承接身份、来源诊所、预约／到达／等待时间、流程状态和当前可执行动作，不预载每人的完整病史、订单、附件与账单。Active 保留授权范围内当天及跨日未处理记录；History 承接只读记录，状态口径见 §2.1。打开记录时重新取得该 Visit 的权限与完整详情；队列可见不代替详情授权，撤权后旧队列行不能继续打开病历。

### 1.1 当前界面结构

| 区域 | 当前内容 | 操作效果 |
|---|---|---|
| Queue / Workspace | 全宽队列与选定患者工作区切换 | Start、Resume、只读打开或返回 Queue |
| 安全栏 | 姓名、生日／年龄／性别、状态／计时、Allergy／ADR 及真实护理交接 | 保持患者上下文；返回、布局和 Clinical Reference 工具在此 |
| 左侧模块栏 | Consultation Note、Prescriptions、Service、Clinical Documents；具备签署能力者显示 Billing & Finish，获授权协作护士显示 Nursing handoff | 按服务端逐项能力及记录状态决定读写；展开显示名称，状态点表示未保存或阻断 |
| Clinical Reference | Patient 360、Records、Attachments、Anatomy、More | 查阅历史或打开工具，不能修改当前患者选择 |
| 布局 | 预设、区域宽度／位置／密度、显示切换及 Reset | 按用户与诊所保存非临床偏好；不保存病历或患者身份 |

没有全局 Save Draft、Pause Consultation 或底部常驻操作栏。Review & Complete 位于 Billing & Finish 末尾。Clinical Documents 内嵌实例自动保存；模板编辑仍有 Save。

离开已成功读取的 Prescriptions／Service 时，首次尚未保存的空集合也须自动保存为“本次没有项目”的草稿结果；只有保存成功才标为就绪。正在加载、加载失败或上下文已改变时，不能将默认空列表写回服务器。保存失败保留未就绪状态和重试路径，不代替医生最终确认或签署。

## 2. 队列与患者进入

| 编号 | 当前功能及条件 | 操作结果 | 不能据此声称 |
|---|---|---|---|
| CQ-01 | Active 显示同集团内本人负责或明确获准读取的原生 Ready for consultation／In consultation／Procedure consent Visit，保留来源诊所 | 以实际到达时间展示；搜索和刷新作用于队列，Start／Resume／只读打开另按动作能力判断 | 可见行均属于当前诊所，或读取授权自动包含编辑／签署 |
| CQ-02 | 原生跨日未结束 Visit | 放在 Carry-over，不计作今日等待 | 跨日记录已完成或已自动关闭 |
| CQ-03 | History 按本轮候选规则提供本人对应诊所的本人记录及已明确获批的原生／迁移只读记录 | 保留来源诊所，先检查原记录权限再按日期、排序和分页返回；最终验收另行记录 | 只因同一患者或新预约便读取其他医生历史，或打开历史就重开问诊 |
| CQ-04 | 等待中的合法行 Start；进行中的行 Resume | Start 请求服务端转换状态；Resume 读取最新 Visit；成功后各模块绑定同一 Visit | 当前已具备额外的双标识人工确认弹窗 |
| CQ-05 | 首次进入失败或切换失败 | 首次失败停留队列；已有工作区时保留原患者，不跳入错误 Visit | 失败仍能写新患者数据 |
| CQ-06 | Return to Queue 或选择另一 Visit | 暂停当前 Note 录音，保护草稿并启动后台保存，再切换；返回来源 eMR 有上下文 | 后台保存失败必须把医生锁在原页面 |

**当前重要差距：** 代码以 Ready／In Consultation 等上游状态推断 Patient and encounter verified，尚无独立的首次开始／跨 Encounter 双标识主动核验流程。首次医生接诊是否复用护士核验仍有已记录的来源冲突，须业务定案；当前回归记录实际行为，不能把进入成功当成已完成独立核验。2026-09-08 恢复服务端稳定医生归属校验；沿用已有显式代诊授权记录，不表示完整 Delegation 管理流程已交付。


### 2.1 医生工作队列与跨诊所历史

**2026-09-13 权限补充：** 医生的 Calendar、Active Consultation Queue 和 History 均按本人稳定 Provider、当前有效 Clinic 归属及记录来源返回。医生不能无授权查看其他医生的日程、当前问诊病人或受限历史记录；明确记录读取授权仍保留，但不开放日程管理或代诊动作；同一患者、同集团、姓名筛选、直接 Visit ID、旧链接和只读模式都不能绕过该边界。护士在当前 Clinic context 下按服务关系处理日程、签到、本次附件及付款，受限问诊正文和历史附件再检查医生明确授权、数据类别及状态条件；只有切换到本人另一个有效 Clinic 归属后，才重新加载该诊所对应数据。Clinic/Provider 切换必须清除旧患者、队列、历史抽屉、角标和迟到响应，服务端详情接口再次校验来源与授权。

医生的 Active 与 History 只按全局 Context Selector 当前主体返回；查看另一诊所必须先切换到本人有效主体。Calendar 的跨诊所模式仅允许排班元数据，不得扩展到 Active、History 或患者详情。记录始终保留来源诊所，读取、编辑和代诊职责分别检查；不能用只读模式跳过批准，也不能把来源诊所改成当前工作诊所。本人跨有效诊所历史读取能力保留；业务页面按当前有效主体加载，查看另一诊所先切换主体，不混合未授权来源。最终验收另行记录。

- Active、Carry-over、相应 Workspace 侧栏及 Consultation 角标使用当前主体授权范围；History 按当前主体及日期过滤后排序、分页。Calendar 汇总视图不得复用这些详情数据。
- History 包含 Consultation completed、Ready for billing、Ready for cashier、Checkout completed、Completed、Closed，以及获授权的迁移只读记录；状态的大小写、下划线、连字符和多余空白写法按同一口径识别。队列统一显示 Completed，原流程状态保持不变，不能据此认定已收款或财务关账。
- 原生 Visit 经 Cashier 退回 In consultation 后重新进入 Active，不因保留旧签署版本而同时进入 History。History 行只读打开，不自动重开问诊；受控更正仍按现有独立流程处理。
- 后端按稳定 User / Provider 归属判断，不以医生姓名、浏览器筛选参数或宽泛临床权限判断。缺少绑定或归属不明时返回空队列并拒绝详情访问；明确主诊 User 优先于冲突的 Provider 记录。
- Workspace 直接链接、跨应用跳转、Patient eMR 问诊历史及各模块适用同一对象边界和各自动作权限；护士协作按下节改造，不再以既有全诊所临床读取作为目标。
- 功能测试模拟 Doctor 必须使用选定的真实 Provider；“无限制功能测试”不再放宽医生数据归属。保留真实操作者审计身份。
- 医生界面显示 My patients，不提供 All doctors。切换医生、模拟对象、角色或诊所时清空旧工作区、历史和角标，同步关闭患者资料编辑器、历史抽屉和修订弹窗，清除其中的旧输入，并丢弃旧请求的迟到响应；真实医生的空队列或请求失败不自动变成合成患者。
- “姓名可选筛选”和“历史无视负责医生只读打开”均不能作为授权。代码完成、自动回归、应用部署和 UAT 必须分别记录。

### 2.2 护士获授权的临床协作

问诊记录由负责医生管理，包括本次和历史问诊笔记、诊断详情、检查结果及正式临床文档。护士获得医生授权后，可以进入相应记录协作；诊断和药物等公共摘要则按角色读取权限提供。

尚未取得临床查看权时，护士仍可处理本人有权限的预约和护理工作。队列只显示必要的工作信息；点击临床记录后打开申请窗口，默认申请当前选定的就诊，不提前加载正文或代选患者的旧记录。

医生在 Settings 管理护士授权。查看与编辑分别申请，批准后系统重新读取权限，页面显示“只读”或“可编辑”、允许模块、实际操作者及授权状态。服务关系、固定记录、持续覆盖、有效期和撤销统一见 [权限方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#clinical-grants)。

本轮联动范围为：具备本 Visit 草稿编辑授权的护士可修改医生已初始化的 Consultation Note／已保存模板快照、Service Selection、护理交接及已有临床文档。护理交接只保存 procedure note，不覆盖保险或收费行。处方可按读取权限查阅，药品新增／修改、检查最终开单、Billing & Finish 和 Review & Complete 均按独立医生能力控制；护士不请求医生专用 Billing Draft 或私人模板库。

护理交接资料成功加载后才开放获授权的编辑与保存；加载失败显示原因和重试入口，不能将空白默认值保存为已有内容。较早的读取响应不得覆盖后续编辑；切换 Visit 后不得将前次读取或保存结果写入新 Visit 的界面。

首次 Start、建立临床生命周期及选择私人模板仍由医生完成。尚无 Consultation 或可用 Note／Document 快照时，界面指引医生先开始问诊、选模板或创建文档；不会替护士创建私人模板，也不会因一项草稿授权开放全页面写入。已有不可编辑版本、迁移记录和 Closed 状态继续独立生效。医生复核护士实际保存的版本并最终签署，保留双方真实操作记录。

活动 Visit 当前仅有临床读取权时，患者锁定页头下方显示只读授权状态条，提供 **Request editing** 和 **Check approval status**。操作留在正常页面布局中，不浮盖录音、SOAP 或其他模块编辑区。本人或已获授权可编辑的记录不显示这组操作；预览、History 及已由临床状态锁定的记录也不显示，完成态继续使用既有只读／受控更正规则。检查授权状态由使用者手动触发，先暂停当前 Note 采集，再重新读取该 Visit 的服务端能力；不自动轮询、不重新生成 SOAP，也不把检查结果直接当作批准。获批后按实际能力开放编辑；读取权失效时撤下内容并转到队列或申请入口。

授权、账号或服务关系失效后，后续服务端请求拒绝旧权限。切换账号、角色、诊所或有效身份清除旧临床草稿和窗口上下文，旧请求、录音与 AI 的迟到结果不能重新出现。跨诊所读取始终保留来源 Visit，不修改当前工作诊所或原作者；患者安全资料编辑携带选定 Visit，仍由服务端检查其是否为合格来源。既有合法保存及真实作者保留。本轮申请、批准、临床入口、草稿保存及撤销已在真实角色浏览器通过；医生完成问诊后可从 History 只读打开。具体覆盖及发布见权限验证（仓库资料：../test_cases/access_control/README.md），不代表正式 UAT。

## 3. Consultation Note

**功能目的：** 形成可签署的本次病历及诊断。

**使用者与对象：** 负责医生、获准草稿协作的护士；Note、诊断与模板快照。

**操作与结果：** 选用模板 → 书写或使用转写草稿 → 人工核对 → 保存版本与诊断。

**关键边界：** AI 输出不自动成为正式事实；护士协作不包括最终签署。

### 3.1 病历、模板与诊断

| 编号 | 功能 | 当前规则 | 预期结果 |
|---|---|---|---|
| CN-01 | 选择病历模板并编辑字段 | 模板定义字段；保存模板快照与字段内容。默认 SOAP 和个人模板分开；新医生首次并发读取也只创建一份包含完整初始字段的私有默认 SOAP，不覆盖医生后续修改；不能只按旧 PRD 假设始终四个固定文本框 | 换患者后恢复该 Visit 的模板及内容，不套错模板 |
| CN-02 | 保存 Note | 保存当前 Note、结构化诊断与版本；当前完成检查要求 Note 已保存且无本地变化 | 保存后可重新读取；失败保留本地内容并提示 |
| CN-03 | 新增／修改个人模板 | 名称及字段 key、label、description；字段可排序，当前界面至少 1 项、最多 20 项 | 保存后更新可选模板；默认 SOAP 可 Restore，不能普通删除 |
| CN-04 | ICD 建议和手工搜索 | AI／ICD 结果为候选；医生选择正式诊断并设 Main／次诊断；完成时必须恰好一个已保存 Main | 没有 Main 或多个 Main 都不能完成问诊 |
| CN-05 | 历史病历及转换 | 迁移来源只读；合法转换不得把历史原记录覆盖 | 原记录及新内容的来源可区分，不把迁移患者送进当天 Active |

### 3.2 AI Scribe 与 Transcript

**CN-06 当前顺序：** 选择识别语言和麦克风 → 启动录音前读取本 Visit 的 AI Scribe Consent → 缺少同意时医生明确确认并保存 → 申请麦克风及启动 → 暂停／查看和修正 Transcript → 生成当前模板的 Draft → 医生检查、修改及保存。

- 支持 English (HK)、English (US)、廣東話、普通話输入选项；界面语言与识别语言不同。
- 同意查询失败不启动录音／AI；取消同意弹窗不写同意、不申请麦克风、不调用模型。
- 生成草稿要求有 Transcript、已选模板且不处于录音中；生成结果不直接签署。
- 预览患者录音入口禁用；真实服务配置、麦克风权限及网络是执行此项的前提。
- 模型响应或保存失败要保留医生已有文字；切换 Visit 停止上一位患者的录音和临时状态。

**文档差异：** 旧设计写过“不新增 AI Scribe Consent 阻断”，但当前代码明确存在上述门禁。本版如实记录当前行为；是否保留这一产品门禁需业务／临床确认，不能由本次文档整理擅自移除。

## 4. Prescriptions

**功能目的：** 形成明确药品、用法与数量的处方并交药房执行。

**使用者与对象：** 医生；Prescription 草稿、签署版本及 Pharmacy Handoff。

**操作与结果：** 选药填用法 → 保存草稿 → 医生签署 → 药房审核；更正从原处方发起 Amendment。

**关键边界：** 药房不改临床处方；历史结算后的改方与差额须走受控更正。

### 4.1 开药与字段

**CP-01：** 按药名搜索或 BNF 层级选择当前诊所可用药品。被选药品保存稳定药品引用与名称来源快照；不能从历史自由文字拼出一条可签药品。

| 字段 | 用途与规则 |
|---|---|
| Drug | 目录药品、名称／规格及来源；选定后才录入处方明细 |
| Dose / Unit | 单次剂量及单位；不能把总发药量当单次剂量 |
| Route / Frequency | 用药途径及频率；频率选项来自可维护的 Prescription Frequency Dictionary，默认包含 OD、BD、TDS、SOS；当前新行 Route 默认 oral，必须按实际用法核对 |
| Duration | 固定疗程数值与单位或适用的其他疗程模式 |
| Calculated quantity / Dispense quantity | 显示计算建议和医生最终确认数量，两者不混写 |
| Patient instruction | 给患者的用药说明；用于患者方向的输出 |
| Line Remark / Prescription Remark | 行级和整张处方内部备注，各最多 2,000 字符；传药房但不当患者说明打印 |
| Start / End date | 适用时记录起止；仍须与本次药品用法一致 |

**CP-02：** 新增、编辑、删除草稿药品后保存当前处方；空处方也须保存为“本次没有药品”的明确模块结果。已有本地变更未同步时，Review & Complete 被阻断。签署后不可原位修改，只能从原 Prescriptions 发起 Amendment。

### 4.2 eMMS 的实际边界

**CP-03：** 连接状态与临床建议分开。每次进入模块检查连接；药品变化后保存／检查当前快照，旧响应不得覆盖新药单。显示重复、相互作用、Allergy／ADR 或映射覆盖信息时，医生仍负责判断。

**当前代码中 eMMS 和 Allergy／ADR 均是非阻断建议。** 连接不可用、未检查或警示不会单独阻止处方保存或最终签署；保存失败、陈旧版本与本地未同步会阻止完成。测试必须分别记录这两类结果。严重警示、Override、覆盖率及临床正式放行政策尚待确认，不能把现状描述为已通过医疗安全验收。

### 4.3 签署与药房修订

**CP-04 当前代码：** 普通门诊 Review & Complete 在签署处方的同时建立 Pharmacy Handoff。2026-09-06 最终规则为付款前仅审核、审核通过且 Cashier 确认结算后才备药；药房退回整张处方时先建立 Pharmacy exception 并阻断结算，Encounter 暂留 Ready for Cashier。护士在 Cashier 明确确认 Return to Consultation 后才恢复 In Consultation；重新签署后仍须药房对当前新版本再次审核通过才解锁。Cashier 手动回退和基础服务端发票／收款门禁已开发，库存预留等完整目标待联调，详见药房 PRD。

**CP-05：** Amend Prescription 记录原因并签署新版本。有药品生成 Cancel/Replace，无药品生成医生授权 Cancel；旧版本 Superseded。已付款后的新版本进入 Payment exception，不能继承 Paid。已发药后的退换和价格差额处理不能按普通草稿修改测试。


<a id="2026-09-06-cashier-退回后的医生处理"></a>

### 4.4 收费退回后的处方修订

- 护士从 Cashier 发起的退回保存原处方版本、原因、护士身份和独立审计事件；仅修改 Visit metadata 或主流程状态不能伪造这次授权。
- 医生在原 Consultation 的 Prescriptions 使用 **Amend Prescription**。该按钮在已签署但已退回 `In Consultation` 的就诊中可用；非医生、迁移只读记录和 `Closed` 不显示此操作，服务端另行验证权限与 Closed 不可修改规则。
- 医生保存 Amendment 时签署新的不可变处方版本。系统检查退回审计和被替换版本一致，核对原 Note、Service Selection 和 Clinical Documents 的签署及版本未变，并验证新药品的数量和权威价格。全部成功后，原子将本次就诊送回 `Ready for Cashier`，界面更新为当前状态；无需第二次对原临床文档执行完整 Review & Complete。
- 原 Signed Charge Snapshot、签署记录、Invoice 和实际付款不覆盖。Cashier 以原非药品收费及当前签署药品版本形成当前费用核对依据；旧付款不能自动授权新处方备药。有药新版本仍须药房重新审核；医生取消全部药品时旧药单标记已取消，无需药房重审，Cashier 核对剩余费用。
- 若患者返回后还修改了 Note、Service Selection 或 Clinical Documents，Prescription Amendment 不能代签这些变化；系统保留原记录并提示需要相应受控临床更正。此处仅交付处方退回及重签闭环，不声称原有完整临床重开与第二次全模块签署已完成。
- 本轮提供独立规则测试和可在隔离 PostgreSQL 执行的公开 API 测试。自动化结果、真实后端部署、库存／打印等外部联调和 UAT 必须分别登记，详见Cashier 隔离集成验证（仓库资料：../test_cases/cashier/README.md）。

- 上述护士操作用于将完整 Encounter 退回 `In Consultation`；尚无任何结算／实收历史时，医生仍可独立修订已签署处方，不必为了处方子流程更正先退回整个 Encounter。直接修订保留主流程状态，有药的新版本仍须药房重新审核及有效预留；已有未付款发票若费用版本变化，必须先处理旧单再继续结算。
- 一旦该 Encounter 曾确认过任何结算（含零额、第三方安排，及后来撤销的结算），或曾记录实际付款，普通 Prescription Amendment 在修改前即被阻断；退款、净实收归零或撤销结算不清除这一历史边界。停药、改方及差额处理仍需另行受控临床／财务更正，本轮不提供这一完整流程。

## 5. Service

**功能目的：** 选择本次检查项目并形成后续执行及收费来源。

**使用者与对象：** 医生及获准的草稿协作者；Service Selection 与正式 Order。

**操作与结果：** 检索／参考推荐／复制历史项目 → 确认当前可用项 → 保存 → 医生最终确认。

**关键边界：** 选择或签署不代表 V-Lab 已接单、执行或出结果。

当前 Service 是本次 Consultation 的 Lab／Imaging 项目选择。它不等于 V-Lab 已接单或已执行。

| 编号 | 功能及前提 | 当前行为与结果 |
|---|---|---|
| CS-01 | 进入 Service 前已有保存的 Note／Consultation | 读取项目目录、当前 Selection 与建议；缺少已保存 Note 时提示先保存 |
| CS-02 | 搜索与筛选、添加／移除 | 按项目身份去重；记录 searched／recommended／copied 等来源；手工不能把 Vendor 或 Price 当权威事实写回 |
| CS-03 | Recommended Services | 根据已保存 Note 请求建议，人工点选才加入；Unavailable 时仍可搜索、复制、保存和签署 |
| CS-04 | Copy Previous | 查看上次项目，选择当前仍可复制项；失效或不满足条件的项目不能盲目复制 | 
| CS-05 | 保存 Selection，包括空集合 | 保存项目、来源及版本；本地未保存时不允许完成问诊 |
| CS-06 | 签署前服务或价格变化 | 服务端重检；价格变化需重新核对，Vendor 改变或 Offering 不可用需重选，不能默换 |

签署 Selection 只是临床选择与收费来源的固定版本。完整样本／侧别、内部承接、结果、危急值和医生结果确认按照 V-Lab 需求另行验收。

## 6. Clinical Documents

**功能目的：** 在当前就诊内生成和保存多份临床文档。

**使用者与对象：** 医生与获授权协作者；Document、模板快照与版本。

**操作与结果：** 使用默认集或新增文档 → 编辑 → 保存／打印 → 完成时签署。

**关键边界：** 独立文档的生命周期和模板管理由 Clinical Documents PRD 统一定义。

**CC-01：** 内嵌模块用多文档页签，默认集按医生保存、最多六项。同模板可开多份独立文档；新增不是立刻创建正式已签文档。正文、Recipient、AI 输入和版本按页签隔离。

**CC-02：** 离开模块保存所有仍存在页签，Print 只保存当前文档；普通文档页签切换只保护浏览器草稿。未变化内容不新增版本，首次成功保存才建立 Document ID。

**CC-03：** 当前模板有 AI 区域时可打开 AI 卡片，医生输入需求并复核输出；Recipient／正文缺失只提示，不代造事实。身份／权限、安全内容、未持久化和不可编辑状态仍阻断相应动作。

**CC-04：** 关闭未保存页签直接移除，关闭已保存 Draft 需确认并软删除；签署／已完成文档只读。新活动工作台获得编辑权后旧工作台只读。

**CC-05：** 自动保存最终失败不阻断导航，但保留草稿并阻止最终完成；Print 必须先保存当前版本，不能打印后假称已签发。独立 App 仍有显式保存且保留它自己的 Recipient 校验。详细文档规则见[Clinical Documents PRD](https://virtus-patient-emr-prd.vercel.app/documents.html)。

**CC-06 本轮权限联动：** 获本 Visit 草稿授权的协作者仅编辑已有文档所保存的模板快照；不读取医生私人模板库，不新增无医生快照的文档。AI 请求携带既有 Document ID 并复用该快照，打印／版本读取继续校验确切 Visit 的读取权，最终签署仍由医生完成。文档窗口在身份、授权或来源 Visit 改变时丢弃旧响应；临床授权和文档自身只读／编辑租约分别校验。 已持有编辑租约的员工被撤销相应授权后，续租返回不可编辑状态并终止该员工／工作台自己的租约；页面停止续租、保留只读状态提示，不把正常撤权显示为系统加载错误。新的租约申请、实际保存及完整病历读取仍执行各自授权检查，不允许释放他人的租约；迟到的续租响应不得影响另一个 Visit。当前接线与自动化验证进行中，尚未完成跨角色浏览器验收。

## 7. Billing & Finish

**功能目的：** 完成临床复核并把一致的签署版本交给收费与药房。

**使用者与对象：** 负责医生；当前 Visit、各模块版本及 Charge Snapshot。

**操作与结果：** 核对收费与复诊 → Review & Complete 检查 → 原子签署与交接 → 返回队列。

**关键边界：** 任何版本或保存检查失败均不完成；护士不执行最终确认。

### 7.1 当前可执行条件

当前新流程只接受**普通 Consultation**，并要求真实医生角色、当前诊所、本人的稳定 User／Provider 归属、活动 Provider 及登记编号、Visit 为 In Consultation。旧 Visit coverage 和他人记录只读授权均不授予临床完成权。护士即使获准编辑草稿，也不能执行最终临床确认、开单或签署；医生应复核所签版本中的协作修改。跨诊所本人历史读取不取消本次完成操作的条件。申请、批准和撤销沿用 Platform 的固定 Visit 授权模型。

**签署身份预检：** 打开 Review & Complete 时按当前有效医生身份检查 Provider 状态和注册号；缺身份、已停用、缺号或检查失败分别显示可操作原因，完成按钮保持禁用，补录后可重新检查。该检查不读取全量历史权限，不增加本次 Visit 首屏历史加载。最终提交仍在事务中重检，防止预检通过后资料被停用或改动；Assume Doctor 使用目标医生身份。独立处方及旧问诊最终签署遵循相同条件，草稿保存不因单纯缺注册号受阻。


**CB-01：** 每次进入同步收费来源和权威价格；缺价显示 Price unavailable。来源、数量、gross、discount、net 和版本形成 Billing Draft；草稿可保存但缺价不能完成。

**CB-01a 默认问诊费（2026-09-08 确认）：** 普通 Consultation 未绑定专属 Consultation Service Offering 时，服务端采用 **HKD 1,000.00**，收费行显示 `Default consultation price`。有效绑定价优先，明确为零的价格保持零；已绑定但失效、跨诊所或非 HKD 的价格继续要求修正。默认价不适用于药品、检查或其他服务的缺价，也不扩大当前支持的 Consultation Type 范围。

默认价与专属价采用相同的 Billing Draft、医生折扣、签署快照及 Cashier 交接流程，保留 `DEFAULT-CONSULT` 来源和价格版本。旧活动缺价草稿在重新读取时自动恢复为默认价并递增版本；之后绑定专属价需重新确认。已签署／已完成收费不因默认价或目录变更重新计价。医生标准价及 Policy／Clinic 例外维护仍以 Catalogue 后端适配进度为准。

**CB-02：** 负责医生可按行做 Percentage 或 Fixed Amount 折扣；百分比 0–100，固定减额不超过该行 gross；要求原因并保存医生、时间和原价。清除／修改折扣后旧收费确认失效。

### 7.2 当前 Review & Complete 检查清单

| 检查 | 通过条件 | 失败时去哪里 |
|---|---|---|
| Patient and encounter verified | 当前代码认为是可信上游交接状态 | Note／上下文；主动双标识仍为差距 |
| Note and diagnoses saved | Note 已保存且无本地变化 | Consultation Note |
| Exactly one main diagnosis | 恰好一个已保存 Main | Consultation Note |
| Prescriptions saved | 已保存且无本地变化，包括空处方 | Prescriptions |
| Service Selection saved | 已保存且无本地变化，包括空集合 | Service |
| Required clinical documents completed | 当前文档无待保存变化，服务端版本可签 | Clinical Documents |
| Authoritative pricing available | 所有收费行已有权威价格且查询结束 | Billing & Finish |
| Follow-up confirmed | 明确 No follow-up 或日期＋原因 | Billing & Finish |
| Billing confirmed | 当前收费草稿有效并同步完成 | Billing & Finish |
| AI content reviewed | 使用过 AI 内容时已复核 | Consultation Note |

**CB-03 当前操作：** 点击 Review & Complete 先打开清单并保存 Billing Draft；有失败项仍可打开清单，通过 Go to section 修正。后台保存 pending／failed 时不能确认完成。

**CB-04 当前成功结果：** 在同一个事务中验证各模块版本、签署 Note／Prescription／Service／Clinical Documents、保存签署收费快照、处理复诊记录、创建药房交接并把 Visit 置为 Ready for Cashier，然后返回 Queue。重复请求不重复生成业务记录；任一步失败整体回滚。

这与旧目标“临床签署成功但收费 Handoff 失败时保留半成功状态”不同：**当前原子完成流程是全部成功或全部回滚。** 失败后按当前状态重试，不能期待代码产生尚未实现的 Handoff failed 中间态。

### 7.3 当前复诊行为与设计差距

**CB-05：** No follow-up 不建预约。Book follow-up 要求日期与原因，当前后端会在完成事务里创建一条 Booked 复诊预约，固定为所选日期的 **09:00、30 分钟** ，记录原 Visit 来源；前端随后返回 Queue。

目标设计是完成后打开统一预约流程，再选择真实可用时段与资源。两者存在实质差异。当前回归要检查重复完成不重复建复诊，同时将固定时段及缺少人工时段确认登记为待修差距；不能把 09:00 当正式业务默认值。

## 8. Clinical Reference 与布局

**功能目的：** 在不丢失本次工作上下文的情况下查阅历史和辅助资料。

**使用者与对象：** 已获相应资料权限的医生／护士；公共摘要、历史详情、附件及临时工具。

**操作与结果：** 按需打开参考资料 → 校验具体内容权限 → 查阅或显式保存工具结果 → 返回本次工作。

**关键边界：** 公共摘要不等于完整 Note；未保存的 Anatomy 内容不进入病历。

| 编号 | 入口 | 能做什么 | 不能做什么 |
|---|---|---|---|
| CR-01 | Patient 360 | 看当前患者摘要及已有资料，打开 Full eMR 后返回原任务 | 创建另一份患者或丢失当前 Visit |
| CR-02 | Records | 查 Consultation、Medication、Vaccine、Vitals 等原始历史 | 将历史行改成当前正式记录，或把空数据理解成无病史 |
| CR-03 | Attachments | This Chit 由当前 Clinic／Provider 关联护士按权限上传、查看、删除；Past services 按原记录医生授权读取；统一查看器保留来源 | 无授权读历史、借本次权限删除历史或将 OCR 自动当正式病历 |
| CR-04 | Anatomy | 打开独立人体结构教学画布，查看器官与临时标注 | 当患者特异影像或诊断结果；未保存标注切患者／关窗口清除，显式截图可保存至当前就诊附件 |
| CR-05 | More | 当前 Chit activity；Copilot 配置未就绪时明确 Disabled | 用示例事件或未批准的 AI 服务冒充真实结果 |
| CR-06 | 布局及响应式 | 调整布局与密度、重置；空间不足时辅助资料用 Overlay | 隐藏必需安全信息、把患者／草稿写入布局偏好 |

上述入口、Copy Previous、历史版本和 AI 上下文均按资料类别检查权限；本次 Visit 可访问不自动开放详细历史。最小安全摘要共享及疫苗公共读取按 [组织、数据权限与授权方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix) 的已确认规则处理：同集团且具有独立公共医疗信息角色读取授权的医生／护士可跨诊所读取疫苗，包括尚无来源 Visit 的旧记录；疫苗写入仍检查来源医生权限。受限 Note、诊断详情、检查结果、正式临床文档和完整处方按来源医生或明确记录授权读取，患者详情确认及审计不代替授权。关联护士按本次附件操作权限上传、查看、删除；历史附件须有效原记录授权，不能因处方可读而放开附件。来源缺失或冲突保留待修复标记，不能把未获权限展示为无病史。


<a id="2026-09-05-anatomy-截图保存"></a>

### 8.1 Anatomy 标注与截图

Anatomy 新增 Screenshot 和 Library（弹窗标题 Anatomy Library）。截图含当前模型视图与手绘标注，先预览，再由用户点击 Save to this encounter 保存到当前患者／就诊附件；在 Anatomy 或 Patient & eMR 附件中查看，支持复制 PNG 图片与下载。复制不删除记录；通用解剖参考属性及来源许可保留在图片中。

保存必须验证当前患者、就诊、诊所与上传权限；只读就诊按既有重开／修订流程处理，不绕过关闭规则。没有就诊上下文只可预览／复制／下载。切患者清理未保存内容；已保存附件保留在原记录。错误时保留草稿重试。接口、数据范围和验收详见 Consultation Workspace PRD 的 2026-09-05 章节；当前仅本地验证，不等于真实后端联调或 UAT。

- 2026-09-05 文本标注：Explain 增加 Text，点击模型位置后键入多行中英文，支持再次编辑、撤销和取消；文字随截图进入原就诊附件，并在 Library 查看或复制。未保存文字仍在切换患者／就诊或关闭窗口时清除。


<a id="2026-09-08-附件与-ocr-展示补齐"></a>

### 8.2 附件查阅与 OCR

- 医生工作台 Attachments → This Chit 展示当前 Visit 的已保存附件；面板打开时和停留期间重新读取当前问诊附件，护士随后上传的文件无需重新开始问诊即可出现。读取仅更新附件，不覆盖医生未保存的临床草稿。
- 点开附件时读取完整 OCR 详情；原件使用受鉴权的统一文件地址。授权 PDF 支持在本系统同源窗口内嵌预览，包括浏览器分段读取；禁止其他站点嵌入。预览仍执行原文访问权限，强制下载与其他响应不放开嵌入。Header fields、置信度、Tables 和可复制文本来自同一附件的最新有效识别记录，列表字段数来自服务端汇总。
- 原文、OCR 详情及识别重试按 Platform 的来源记录与动作权限校验；本人跨诊所读取与护士授权已接入统一来源门禁，实际回归及发布范围见权限验证（仓库资料：../test_cases/access_control/README.md）。已知附件 ID、下载地址或原上传者身份不构成绕过授权的例外。
- 识别中自动刷新详情；失败／配置缺失／任务中断明确显示。持有原有上传权限的角色可 Retry recognition，重用同一原件与附件关联；不新增临床记录，不自动采纳 OCR 到已签署内容。
- 同一附件重复请求不能并发创建多个有效识别任务；超过三分钟无终态的任务显示中断并允许重试，旧任务迟到结果不能覆盖新任务。切换患者、就诊或身份、关闭窗口后取消旧响应展示和轮询。
- 本轮代码、专项验证、预览发布及 STG/UAT 分开记录：`agent_docs/test_cases/attachments/validation-20260908.md`。

## 9. 本版必须明确的待实现设计

| 目标 | 当前证据与验收处理 |
|---|---|
| 主动双标识核验 | 当前由上游状态推断；安全验收 Blocked，不能按旧文档记 Pass |
| 六类医生流程共用类型差异规则 | 当前原子 Billing & Finish 仅普通 Consultation；其他类型返回不支持，不自动降级为普通门诊 |
| No Cashier Required | 当前完成服务统一写 Ready for Cashier；完全无 Charge Event 分支尚未交付 |
| 药房退回后的 Consultation／Cashier | 药房整单退回先保持 Ready for Cashier 并建立异常阻断；护士在 Cashier 手动确认后才回 In Consultation；医生在 Prescriptions 签署 Amendment 后经原临床签署版本校验原子送回 Cashier；有药新版本仍需重审，全部取消只核对剩余费用。应用已开发；真实数据联调／UAT 分别记录 |
| Handoff 部分成功恢复态 | 当前为原子回滚；目标若保留需单独设计与实现 |
| 完成后统一预约选择 | 当前直接建 09:00／30 分钟 Booked 预约；需改为已确认目标 |
| 24 小时自动关闭与超时审批 | Closed 拒绝重开已见代码；完整计时、审批和自动关闭未证明可运行 |
| eMMS 高风险放行规则 | 当前非阻断建议；临床正式门禁／Override 政策未定 |
| AI Scribe Consent | 当前有门禁，与部分旧需求相反，需确认保留口径 |

## 10. 测试使用方式

按[测试用例](https://virtus-patient-emr-prd.vercel.app/acceptance.html)中 CQ、CN、CP、CS、CC、CB、CR 用例回归当前行为；按本节待实现清单验收目标差距。执行前提供普通门诊测试 Visit、授权医生、有效 Provider 登记信息、至少一套可保存 Note 模板、药品与 Service 目录及权威价格。界面成功提示之后还要重新读取记录检查版本与状态。

源代码定位与核对日期集中在[实现记录](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)，正文不要求业务或测试人员阅读源文件。
## 当前主体、Provider 与护理授权门禁（已确认）

Consultation、Clinical Documents、患者历史和问诊队列只读取全局 Context Selector 当前主体，App 内不提供跨诊所混合筛选。Doctor 仅可查看当前主体中本人 Provider 的日程、当前问诊患者和历史问诊记录；Nurse 按当前 Clinic 与医生服务关系读取运营队列并处理本次附件；受限记录和临床协作再检查有效医生授权。主体切换后重新请求授权上下文并重新加载数据，同时清理旧患者、队列、历史、角标、未保存草稿及迟到请求。详情、附件、保存、完成和签署均由服务端再次校验主体、Provider／服务关系、授权期限和 Visit 状态。


---

# Clinical Documents 与模板 PRD

更新：2026-09-14 · 责任：Line B · 相关功能编号：CD-01～CD-05、CC-01～CC-05

## 功能地图

文档实例记录一次就诊的内容；模板提供可复用结构；打印是输出动作，不能替代签署或交付。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 创建与编辑文档 | 医生／获准协作者 · Document | §1–3：入口、字段、默认集、新增、AI 候选与移除 |
| 可靠保存与输出 | 当前编辑者 · Document Version | §4–5：版本、重试、编辑租约、打印与阻断 |
| 签署与交付 | 具相应资格的人员 · 生命周期 | §6：签署、签发、作废／重发和 Worklist 目标 |
| 模板与个人默认集 | 医生／模板管理者 · Template | §7：系统蓝本、个人版本、恢复默认与历史快照 |

## 1. 业务对象与两个入口

Clinical Document 是医生基于模板生成的证明、病假纸、转介信、入院信、医疗／保险报告、用药摘要或患者说明。每份必须属于一个 Patient + Encounter。文件类型选择当前已启用的模板目录，不承诺所有家族已配齐正式内容。

| 入口 | 谁使用 | 当前工作方式 | 共同数据 |
|---|---|---|---|
| Consultation 内嵌 | 当前就诊获授权医生 | 多文档页签、默认打开集、自动保存 | 模板、Document ID、版本、AI 与打印服务 |
| 独立 Clinical Document App | 需查看／处理特定就诊文档的授权人员 | 先选择 Encounter，保留当前布局和显式保存；Recipient 仍按该入口现有规则校验 | 不新建一份脱离 Encounter 的副本 |
| 跨就诊 Worklist 目标 | 文档处理岗位 | 待处理／待签发／历史筛选、按状态处理 | 只引用原文档；完整工作清单与签发链仍待实现 |

正式临床文档由负责医生管理。护士要查看文档，需要在来源诊所服务该位医生，并取得有效查看授权；编辑草稿还需单独的编辑授权。其他医生可以申请查看指定记录，签署及正式修订则由合资格医生执行，详见 [权限矩阵](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。

上传附件和生成正式临床文档是两种工作。Attachment Management 用于上传、分类、预览文件和读取 OCR 结果；本篇负责模板、文档正文及签署。护士的本次附件管理权，不会开放正式文档正文，也不允许删除或撤销已签文档。历史文档即使在本次问诊中打开或复制，仍检查原记录授权。

以上权限范围于 2026-09-14 确认。本轮修改的是 PRD，尚未实施或验收对应权限代码。

## 2. 文档与模板字段

| 对象 | 字段 | 维护规则 |
|---|---|---|
| 文档实例 | 文档类型、Template 及快照、Patient／Encounter、Recipient、正文、Letterhead、Page size、版本、状态、作者 | 身份由当前上下文绑定；正文可编辑，状态转换不由打印推断 |
| 模板 | 模板名称、Family／Type、普通正文、Merge Fields、命名 AI Areas、版式 | 保存可复用结构，不保存某患者实际内容；临床事实来自文档实例 |
| 默认打开集 | 医生、最多六个不重复模板、有序列表 | 跨设备偏好，只影响新 Encounter；变更不增删当前文档 |
| 历史版本 | 上一版本、正文快照、模板快照、作者和时间 | 已保存修改追加后继版本，不原位覆盖；无变化重试不增版本 |

模板中的 Merge Field 从真实患者／Encounter 填值，缺值不编造；AI Area 只为命名区域生成文本；整篇 Improve draft 为独立候选，须明确确认后才替换编辑器正文，生成本身不保存。确认后的全文替换须能通过普通 Undo 恢复确认前正文；无法建立可撤销编辑时保留候选并明确报错，不能仍提示应用成功。模板已停用或无权限时不能用于新建，但历史快照保留。

## 3. 内嵌文档工作流程

**功能目的：** 让医生在本次问诊中完成一份或多份可追溯文档。

**使用者与对象：** 医生使用本人模板，获授权护士协作已有快照；每份文档绑定 Patient＋Encounter。

**操作与结果：** 恢复既有文档或打开默认集 → 编辑／核对 AI 候选 → 保存版本 → 打印或在临床完成时签署。

**关键边界：** 新建资格、编辑资格、打印及签署分别检查；文档缺值提示与保存失败分开。

**2026-09-09 本地反馈修正：** 文档区读取和创建资格必须与服务端既有规则一致。真实 Doctor 使用本人模板；服务端已确认的 Unrestricted Functional Test Doctor 会话，须显式选定有效目标 Provider，使用该目标医生模板。其他模拟模式不开放个人模板；真实操作者和目标医生分开留痕，不由 Doctor 标签自动授予资格。此前前端一律拒绝模拟身份，导致已获支持的功能测试医生也不加载默认文档；本轮修正这处前后端不一致，未新增服务端权限或改变签署规则。

已授权护士读取／编辑当前 Visit 已保存的文档快照，不能因为有草稿编辑授权便创建医生模板。没有已保存文档时说明实际原因，并提供 Refresh documents；只有能创建文档时才提示新增并提供对应按钮。加载中、无文档、读取失败、无模板资格和只读状态分别呈现；已有正文时保存／AI／打印错误也必须在页面可见，不能只写屏幕阅读器文本或控制台。获取编辑租约失败要显示实际原因并提供 Retry editing access，未成功前保持只读；不能把接口或锁等待错误误报为另一个工作台已接管。无维护权的模板设置齿轮隐藏，不能提供点击无效的入口。相关本地验证见 导航与文档回归（仓库资料：../test_cases/app_navigation/README.md）。


1. 第一次进入新 Encounter，打开医生默认集；有既有文档时恢复原文档，不重复创建。
2. 点击 `+` 搜索／按 Family 选择已启用模板，可用同一模板开多份独立文档。
3. 编辑当前文档正文、Recipient 与版式；AI 卡片只处理当前页签。
4. 切换文档页签保护当前浏览器草稿；离开整个模块保存所有仍存在页签。
5. Print 先持久化当前文档，再输出该版本；不能顺带打印或改变其他文档。
6. Review & Complete 检查文档可靠保存并签署相应当前版本；Signed／Completed 后只读。

没有文档时显示新增入口；最后一页删掉后不自动恢复默认文档。关闭 `X` 表示从本次就诊移除文档：尚未建立 Document ID 直接移除，已保存 Draft 需确认后软删除；已签署／已完成无 X。

## 4. 保存、失败及多窗口

| 场景 | 应如何处理 | 验收预期（非执行结果） |
|---|---|---|
| 首次保存 | 建 Document ID 与 Version 1 | 刷新可读同一文档 |
| 有变化再次保存 | 追加后继版本 | 旧正文仍可追溯 |
| 无变化或同请求重试 | 复用原结果 | 不重复建文档／版本 |
| 离开模块保存失败 | 保留当前标签页草稿，退避重试；最终失败标记错误并允许导航 | 不能最终完成问诊；恢复成功后清除错误 |
| Print 保存失败 | 说明无法可靠保存／打印 | 不宣称已打印该正式版本，不伪造成功审计 |
| 新工作台取得编辑权 | 旧工作台转只读，不让医生手工合并 | 同一 Encounter 不发生两处同时成功覆盖 |
| 关闭浏览器 | 只承诺当前浏览器存储能力范围内的恢复 | 不承诺关闭时异步保存一定完成或跨设备恢复本地草稿 |

## 5. 内容提示和真正阻断

内嵌工作台的 Recipient、正文、AI 区域或 Merge Field 不完整只提示，不阻断保存、AI、打印或完成问诊；医生承担内容、披露范围和临床事实责任。系统保存真实缺值，不制造机构、诊断或用药。

以下仍阻断：Patient／Encounter／Clinic／Doctor 不匹配、无权限、不是活动编辑者、已签署或不可编辑状态、安全 HTML／容量校验失败、当前内容未可靠保存，以及无法记录必要打印披露证据。内容不完整与保存失败必须用不同反馈。

## 6. 文档生命周期及跨就诊 Worklist

设计生命周期：Draft → Reviewed／Approved（按类型）→ Signed → Issued；需要纠正时 Voided 或 Reissued，保留旧版本及原因。当前代码已有草稿版本、原子完成时的签署与打印基础，完整独立审批／签发／作废／重发仍不能宣称完成。

Worklist 目标应能按患者、日期、文档类型、负责医生、状态和来源就诊筛选；详情显示文档版本、当前待处理动作、操作者及交付记录。Print／PDF 只是输出，实际发送／交付需单独记录接收方、方式、时间及结果；没有通信接口时记录人工交付，不能自动生成 Delivered。

具体哪些文档需要审批、谁可签发、签发时限、重发编号和披露审批仍待临床与营运确认。对应场景先标 Blocked，不临时设计成所有角色都可签发。

**STG 与权限集成：** 区域生成、整篇改善、确认／取消／撤回均复核具体 Visit 草稿权限、工作台租约及授权文档快照。护士只可操作医生已建立并授权的文档，不能因 AI 新接口绕过模板创建资格；模型返回后再次检查权限、租约、模板／文档版本，撤权或基线变化的迟到结果不得应用。候选或仍在生成的区域必须先明确处理，随后才可保存、打印、切换或 Review & Complete。无结构化主诊断的确认属于可签署医生的决策，不阻止只读或护士协作者浏览页签。

```mermaid
flowchart LR
  A[系统基础蓝本] --> B[医生个人模板版本]
  B --> C[本次文档的模板快照]
  C --> D[文档正文与后继版本]
  D --> E[签署版本]
  D --> F[当前已保存版本的打印]
```

修改个人模板只影响后续生成；原文档保留生成时快照。打印成功不自动改变签署／签发状态。

## 7. 模板管理

**基础与个性化（2026-09-09 用户确认）：** 系统 default 蓝本提供基础模板兜底。首次使用、没有个人配置或缺少基础模板时，服务端按稳定蓝本键幂等补齐；医生编辑的是自己的模板副本并追加版本，只对本人有效，不修改系统蓝本或其他医生配置。Restore default 从系统蓝本恢复，基础模板不可删除。已保存文档继续使用生成时的模板快照，不随个人模板改动。Personal Settings 和文档内嵌设置读取同一份医生默认集合；加载中或加载失败必须明确显示状态并禁用保存，失败提供重试，不能把尚未加载解释成空集合或覆盖已有配置。默认打开页签是另外一层有序偏好：未配置时初始化常用文档；主动保存空页签集合不删除基础模板库，仍可通过 + 使用基础模板。

Personal Settings → Document Templates 或文档页内的同一设置编辑器维护医生默认集、搜索模板、新建／编辑模板。默认模板使用 Restore／Preview／Save；个人模板使用 Delete／Preview／Save。模板管理可以在 Completed Consultation 中继续使用，但不能改当前已签文档。

个人模板所有权须基于稳定用户身份；历史仅按医生名字过滤的路径不能视为权限隔离已通过。正式 Letterhead、签名、打印机及文档内容批准另有上线依赖；预览版面不代表正式临床签发资格。


---

# Drug Dispensing、诊所库存与 V-Lab PRD

更新：2026-09-14 · 代码核对基线：`d69b45b` · 责任：Line C，衔接 Line B／Line A；实施映射：WS4／WS3／WS5

## 功能地图

临床发药与内部检查分为两个功能域；库存供应的详细设计进入 CP PRD，付款规则进入 Cashier PRD。§8 保留需求编号映射，§9 只说明实现差距。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 处方接收与审方 | 药房人员 · 当前签署处方 | §2–3：整张审核、库存证据、预留及超时 |
| 结算交接与价格 | 药房／Cashier · 费用版本 | §4：统一结算门禁与本次改价 |
| 异常退回与更正 | 药房／护士／医生 · 原版本 | §5：临床异常、拒药、返工及已结算保护 |
| 备药、复核与领取 | 药房人员／最终核对者 · 整张处方 | §6：实物准备、不同人复核、一次领取与关闭 |
| 工作队列与显示 | 药房人员 · 待办／历史 | §7：筛选、签署快照、阶段操作和刷新 |
| 药品与库存交接 | Pharmacy／CP · 药品及数量 | §10：目录来源、库存流水与套餐边界 |
| 内部检查执行 | V-Lab／医生 · Order／Result | §11：承接、执行、发布与医生确认；外部 Vendor 仅人工收件 |

## 1. 范围与权威边界

Drug Dispensing 承接医生已签署的处方，完成审方、备药和发药；关联护士在 Cashier 确认结算。三个工作台使用同一患者、就诊和有效处方版本，费用版本也必须一致。本篇是药房交接的唯一业务规范。

**谁可以操作。** 药房人员需要在处方所属诊所有有效岗位，并具备相应药房权限，才能查看和执行该诊所的处方，无需另行申请医生的临床记录授权。同集团关系不开放其他诊所处方；队列、直接链接和操作接口都检查来源诊所。

**医生、护士和药房的分工。** 医生负责开立、修改、取消及签署临床处方，护士按医生授权查看。药房依据签署版本审方、备药、复核和发药，不能代医生改方，也不能代护士收款。药房获得的是本诊所处方执行信息及必要安全资料，不是完整问诊记录。

以上权限于 2026-09-14 确认，完整规则见 [权限矩阵](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。本轮更新 PRD，新增范围仍待代码核查和验收。

业务要求见 §2–8，当前代码与缺口统一见 §9；规则已确认不等于已实现。诊所库存／套餐边界见 §10，V-Lab 见 §11。Central Pharmacy 的采购、收发、回收、主数据和 Finance 协作只在 [Central Pharmacy PRD](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html) 维护；不在本文重复其历史讨论。

Drug Dispensing 是诊所临床发药的唯一执行入口。重复 Pharmacy Drug Order 壳已移出目录；CP Warehouse、Pharmacy (WDL) 和重复库存入口归并为 Central Pharmacy。CP 供应诊所与诊所向患者发药分别负责，Samuel 主责 Central Pharmacy／WDL，NeosAI 支持；本次文档合并不改变合同或报价范围。

## 2. 签署、审核与结算主流程

医生 Review & Complete 签署当前有效处方后立即建立版本化 Pharmacy Handoff；不消费草稿。药房可以在患者付款前查看并审核，Cashier 同时核对其他费用。**整张审方及有效库存确认通过后，Cashier 才能一次性结算；结算确认后才开始标签及备药。**

```mermaid
flowchart TD
  A[医生签署当前处方并交接] --> B[药房核对全部药品、供应数量及药费]
  A --> C[Cashier 核对其他费用；暂不收费]
  B --> D{整张通过且库存有效?}
  D -->|否：临床或供应问题| E[整张异常；医生任务；立即阻断结账]
  E --> F[护士在 Cashier 确认原因并退回 In Consultation]
  F --> G[医生修订并重新签署]
  G --> B
  D -->|是| H[等待 Cashier 统一结算]
  C --> H
  H -->|未结算预留到期| I[释放；恢复等待药房确认；阻断收款]
  I --> B
  H -->|实收、零额或付款安排已确认| J[待备药 → 备药中 → 待复核]
  J --> K{全部实物复核通过?}
  K -->|否：备药错误| J
  K -->|是| L[待发药]
  L --> M[整张一次性交付；已发药]
  L --> N[未领取持续保留；阻止最终 Closed]
```

收款门禁同时校验当前处方有效、整张审核通过、库存有效、药费与 Cashier 确认版本一致且没有其他阻断。任何单一条件都不能单独放行；付款或打印成功不自动记录已备药／已发药。

## 3. 审方、库存与计时

**功能目的：** 决定当前整张处方是否可以进入统一结算。

**使用者与对象：** 药房人员；签署处方、逐项审核与整单库存证据。

**操作与结果：** 核对每种药品及供应量／药费 → 整张提交审核 → 预留有效库存 → 等待结算。

**关键边界：** 审核通过、库存预留、实物备药分别记录；测试库存不代表真实余额。

### 3.1 整张审核

- 逐药品核对用药、全部供应数量和药费，任意一项未完成不可整张通过。已确认目标是逐项勾选、整张提交；当前整体确认控件的实现边界见 §9。
- 医生可见库存是业务要求。预留时仍须再次校验真实可用量，防止并发超占；库存不足按整张审核失败，不建立常规“等待补货”分支。
- 除纯价格问题外，任意一项失败整张退回医生。药房不能改药品、剂量或处方数量；供应替代及数量调整由医生签署新版本。
- 审核、整张库存确认及结账解锁必须一致提交，不能部分预留成功就把整单标为可收费。签署快照、备注和逐行来源见 §7.2。

### 3.2 预留、暂停与释放

审核通过即预留整张所需数量。预留不等于实物备药、出库或扣减。从每次预留成功时间开始，超过 24 小时仍未确认结算须自动释放，恢复“等待药房确认”并阻断收费；重新审核及预留后才能继续。重复审核、退回、释放或到期任务不得重复占用／释放数量。

未结算处方 Hold 必填原因、停止整张执行并释放当前库存证据；恢复时重新整张审核与确认库存。Cashier 因患者拒药退回时也立即停止旧版本并释放。实际库存分配器和后台到期释放尚未接通；当前代码仅在读取或操作时以 `valid_until > NOW()` 判断有效，达到 24 小时到期点即失效，不能把证据表当真实库存台账。该精确边界与业务表述“超过 24 小时”须在库存实施验收时对齐。

已确认结算的库存不再受未结算 24 小时规则释放。退款或撤销当前结算也不抹去历史；已结算后保护、后续备药阻断和受控更正见 §5.4。测试证据关闭后失效的规则仍优先适用。

### 3.3 人工证据与测试库存

| 模式 | 允许条件与留痕 | 边界 |
|---|---|---|
| 正式库存集成 | 权威可用量校验、整张预留、释放及扣减关联当前处方版本 | 目标待实施，当前没有自动分配器 |
| 人工库存证据 | 明确启用独立配置；药师确认整张库存并填写来源／凭据，保存版本、人员、时间及有效期 | 默认关闭；记录人工依据，不自动分配或扣库存；正式采用方式仍待业务确认 |
| 测试库存 | 仅显式启用的 staging／隔离 test；当前已配置药品的库存项按测试通过 | 不适用于 UAT、生产、未知或缺省环境；不批量批准处方、不生成虚构实存或库存流水 |

测试模式保留逐张药师审核、签署版本完整性、Cashier 结算、标签、真实备药记录及不同人最终复核。页面持续显示 `Test stock enabled`，Review 显示 `Test stock confirmed`，Cashier 显示 `Test confirmed`；审核弹窗免填人工库存凭据，但整张确认仍必填。

后端复用 `clinic_pharmacy_stock_confirmations`，保存 `metadata.test_only=true`、TEST ONLY 依据、药品及执行行 ID、当前签署版本、认证操作者和时间；`reservation_status=test_confirmed` 与 `reservation_source=test` 区分来源。前端参数不能启用模式。库中不存在的药品、药品／数量与签署行不符或不完整的整张快照均拒绝。

关闭配置后，既有测试记录保留审计但不再支持结算、备药或发药，即使曾经测试结算也无效。原有效期、退回／Hold、重签版本规则继续。配置、部署、回滚及执行证据只维护在 测试库存验证记录（仓库资料：../test_cases/cashier/test-stock-20260908.md），STG 实际启用与源码实现分别记录。

## 4. Cashier 结算与本次价格

结算确认条件以 [Cashier 结算功能](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#cashier-settlement) 为唯一付款规则来源：2026-09-10 已确认患者全额／部分欠款及 CoPay 欠款经显式登记安排可放行备药。药房消费结算结果，不把应收当作实收，不另设患者必须付清的重复门禁。


### 4.1 一次性结算

审方期间药费显示“等待药房确认”，可核对问诊及检查等费用，但不能先收其他费用或拆开收药费。整张审核与库存通过后统一结算；同一结算可以有多种实际付款方式，不能借拆分付款绕过整次收费门禁。Cashier 展示审核、库存、费用版本及最新总额，旧页面不能按旧金额收款。

| 服务端结算类型 | 药房读取含义 |
|---|---|
| `paid` | Cashier 已确认患者实际收款结算 |
| `zero_amount` | Cashier 已确认整单零金额结算 |
| `payment_arrangement` | Cashier 已按付款责任与欠款规则确认安排；不表示应收已到账 |

药房只消费当前 Visit／Prescription Version 的 `settlement_status`／`settlement_confirmed`，同时检查当前审方、有效库存和签署版本。不能仅以 `payment_status=paid` 判断，零额或付款安排的兼容付款状态仍可能为 `payment_pending`。患者是否已付清、欠款原因／确认及第三方责任由 [Cashier 唯一契约](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#cashier-payer-arrangement)校验，药房不再维护另一套付款表单或余额门禁。

### 4.2 药房直接改价规则

仅药价有误且临床处方正确时暂停收费，由药房改价并重新核对，不退医生、不要求临床重签。所有有权操作 Drug Dispensing 的人员可调整本次单项**单价**，不另设改价权限或逐次管理审批；不扩大到无药房操作权限的账户。

- 仅在从未发生付款／结算历史时直接编辑；结算后更正保留原单，走受控差额／退款流程，不能退款后重新开放普通改价。
- 必填原因，允许 0，正常收费单价不得为负。不改药品、临床数量、后台标准价、其他处方或历史账单。
- 自动计算单价 × 处方数量及整单金额；保存原价、新价、原因、操作者、时间、处方／药品行及价格版本。Cashier 获取最新金额重新核对，旧价格页不得收款。
- 每条记录交管理角色逐条处理并记录结论，如“仅本次例外”或“已更新标准价”；管理处理不阻断本次收费。标准价维护是独立受审计操作，不回写已确认收费快照。

药房独立改价入口及管理待办仍待开发。Cashier 当前已实现的 Visit 单价调整是另一入口，保留其未付款旧票作废、费用版本和历史保护规则；不能据此宣称药房改价已实现。管理记录放在价格维护内属于布局建议。

## 5. 退回、取消与历史保护

**功能目的：** 让临床问题、患者拒药、价格问题和备药错误各回到正确岗位处理。

**使用者与对象：** 药房、护士、医生和 Cashier；原处方版本、异常与受控更正。

**操作与结果：** 明确原因 → 阻断受影响动作 → 责任岗位处理 → 按新版本重新校验。

**关键边界：** 药房退回不直接重开 Visit；已发生结算／付款的历史不被退款或撤销抹去。

### 5.1 药房退回与护士手动回退

药房记录异常类别、评论及逐药品意见要求，整张标记待医生处理、建立原医生 Amendment 任务并立即阻断 Cashier。类别为临床澄清、剂量／用法、供应／替代、患者安全或其他；纯价格问题按 §4.2 处理。当前界面及接口采用整张类别／评论，逐药品结构化意见仍待补齐。

药房动作不改变 Encounter；它先保留 `Ready for Cashier`。护士在 Cashier 必须看到原因和阻断，发票生成、过账、收款及 Checkout 均不得继续。护士明确执行 Return to Consultation 后才改为 `In consultation`；两次动作分别保存角色、操作者、原因、时间、Visit 和处方版本审计。

医生继续在原 Consultation → Prescriptions 修订并重新签署；旧版本保留，新版本重新 Handoff，Encounter 再次 Ready for Cashier。重签本身不解锁结账，新版本还须重新整张审核与库存确认。旧页面、旧审核、旧版本或迟到事件不能放行。

### 5.2 患者拒药与医生取消

Cashier 的患者拒药由护士确认 `patient_request` 退回，立即停止旧版本、释放库存并阻断收费；药房显示“已撤回，待医生处理”，不把护士退回当临床取消。没有付款历史的旧草稿／已过账发票在回退事务中保留并受控作废，原因和审计不丢失。

医生签署取消全部药品时，药房接收取消结果，无需再次审核；Cashier 核对剩余费用，剩余为 0 仍须显式零额结算。部分取消生成仍含药的新版本，必须重审及重新确认库存。已撤回、医生已取消、旧版本已替代分别显示，历史不可删除。

### 5.3 备药错误及发药后退换

药品／数量／标签准备错误而临床处方正确时，目标是退回备药中，必填原因，修正后重新逐项实物复核；不退医生、不重收费。当前常规状态 API 没有该返工路径，不能以未结算 Hold 代替付款后的返工。

已发药后退换本期人工处理，记录异常和结果，不自动退库／退款，不抹去原处方或付款。Closed 的原 Encounter 不重开；临床更正、退款和库存处置分别留痕，不增加“付款后常规重新审方”状态。

### 5.4 已付款／结算历史不可清除

发生过实收或结算（含零额、第三方安排）后，普通审方、Hold、药房退回、护士回退和直接改价不能绕过受控临床／财务更正。退款、贷项或撤销结算不把 Visit 还原为“从未付款”。

撤销当前结算会阻断后续备药／发药，但不重启原库存的未结算 24 小时到期时钟，也不释放已保护库存。Checkout Completed 后在原历史账单补足患者金额，可显式重新确认相同处方、费用版本、第三方安排及有效库存；重新确认不新增付款、不自动发药、不改 Encounter。Closed 不可重新放行。需要停药、改方或释放已结算库存时仍须另行受控处理，完整差额改方闭环尚待实现。

## 6. 备药、双人复核、领取与关闭

**功能目的：** 把已经允许执行的处方落实为可追溯的实物交付。

**使用者与对象：** 备药人员、最终核对者及领取人；药品、标签、核对与领取记录。

**操作与结果：** 结算确认 → 标签及备药 → 不同人复核 → 整张现场交付 → 保存领取结果。

**关键边界：** 打印或付款不等于实物完成；未领取继续阻止最终 Closed。

### 6.1 业务状态与实物记录

已确认目标为 **待备药 → 备药中 → 待复核 → 待发药 → 已发药**，与当前四类工作区及 API 枚举的映射见 §9。

| 阶段 | 完成条件 |
|---|---|
| 待备药 | 当前处方整张审核、有效库存和 Cashier 结算均通过 |
| 备药中 | 打印并核对标签，记录真实批次／效期、准确备药量及操作者；药品、规格、SIG 和应备量来自签署快照且只读 |
| 待复核 | 逐药核对实物药品、数量、标签、批次效期及患者身份，整张提交；不重复临床审方 |
| 待发药 | 全部实物核对完成，待身份核验、用药交代及实际交付；未领取持续保留 |
| 已发药 | 全部药品一次性交付给本人或代领人，记录实际交付人员和时间，不允许分批领取 |

Label 是面向患者的输出，必须带出药名规格、Dose、Route／使用方式、Frequency、Duration、Patient instruction／How to take、Quantity、安全提示和患者／医生／诊所上下文。行级及整张内部 Remark 不自动打印。打印请求不证明打印机成功，操作人必须确认实物标签已打印并检查。

批次、效期和实际数量由药房录入，不能自动伪造。现有服务端拒绝缺批次、过期／无效日期或与处方不等的数量，并记录认证备药人；Final 要求身份、过敏、药品、数量、批次及用药指导六项核对完成，全部执行行已 packed 后一次更新整张为 dispensed。标签、备药历史及原批次数据保留。

### 6.2 人员分工与领取

Review／Label／Pack 可由同一获授权 Dispenser 完成。实物 Verify／Final Dispense 正常由另一 Pharmacist／Final Checker 完成。普通药品单人例外的已确认目标要求药师重新认证及原因；高警示／受管制／严重警示不能使用普通例外，紧急例外需既有主管批准。**当前真实重新认证／审批路径尚未建设，所有单人／紧急例外均不可用。**

当前 Final 强制实际认证 `pharmacy` 角色，且其用户 ID 不得等于任何药品的备药人；角色模拟、客户端 actor 字段或显示姓名不能绕过。药房改价免审批不取消实物复核职责。

仅现场领取，允许本人或代领，无配送。代领只保留一条记录信息及操作人／时间，不新增姓名、关系或电话等结构化必填表单。全部药品备齐并复核通过才能整张一次交付；已结算未领取不自动取消或释放。

### 6.3 Encounter Closed

已结算未领取的有效处方阻止最终 Closed，直到实际发药或有权限的人工处理完结；人工例外仍须原因和审计。首次临床签署满 24 小时及其他关闭条件继续适用，不从发药重新计时。第三方未到账 AR 独立跟进，不阻止已满足其余条件的 Encounter 关闭。

库存时钟从每次预留成功开始且只约束未结算；关闭时钟从首次临床签署开始且要求全部关闭前置条件。自动 Closed 调度及完整未领取门禁尚缺完整运行证据，不能以 Checkout Completed 当最终 Closed 验收。

## 7. 队列、签署内容与界面

### 7.1 队列与诊所筛选

目标是一张处方一条队列记录，同患者多处方分开并保留版本；默认全部未完成处方不限当天，已发药／已取消／已替代放只读 History。当前仍是一药品执行行一条记录，显示整张签署内容及整张审核／交付并不代表队列已聚合。

Clinic 下拉筛选位于标题工具栏右上角，与 Refresh 同排；显示 All clinics、完整诊所名及当前 Active／History 数量，支持键盘选择。按 Visit 的稳定 `operating_unit_id` 过滤，并返回 code／name 用于展示，不从姓名推断诊所。切换后队列、计数及可操作详情一致，原记录不在范围内即不可继续操作。

**当前队列 API 只返回会话获授权的单个 Operating Unit／Medical Group，并已移除旧 90 天／80 条限制。** All clinics 指前端已获授权返回集合；合成预览展示多个 clinic 不证明后端具备跨诊所聚合授权。新增真实跨诊所访问仍需明确数据范围并验证。

每条摘要仅显示患者姓名、开方医生、诊所、药品行数和工作／结算 Tag；姓名保留 eMR 入口。药品数取完整签署快照的行数，缺快照隐藏，不取分页行数或猜成一种。编号、日期、具体药名和完整身份放详情。付款 Tag 使用 Paid／Zero amount／Payment arranged 等简短文本，详情分开显示完整结算与库存。关键词可搜患者、诊所、医生及药品；筛选无结果清空详情。

### 7.2 完整签署快照与备注层级

队列及详情承接当前已签版本的完整 `prescription_lines`、SIG（Dose／Unit／Route／Frequency／Duration）、Dispense quantity、Patient instruction、警示、签署版本、开方医生和诊所，不重新录临床处方。`prescription_lines` 直接来自所属 `clinic_prescription_versions.snapshot.lines` 并保持原序，不从筛选后队列拼接，不混用其他版本或当前目录修改。

Review 结构与 Consultation 一致：整张 Prescription → 各药品卡片 → 各自可选 Medication remark（签署行 `internal_note`）。整张 Prescription remark 来自签署快照 `remark`，独立位于药品列表外，只显示一次。空备注隐藏，父级备注不复制到各药品；Patient instruction 与两级内部备注分开。缺完整快照时明确只显示当前药品，不能声称完整处方。

药师可定向打开当前患者／Encounter 的 Consultation result 并定位 Prescriptions，不经 Consultation Queue、不触发开始／恢复问诊；普通药房查看只读，医生 Amendment 仍在原工作台。eMMS 入口使用签署药品的稳定 ID 和结构化用法；真实权限及 eMMS 联调单独验收。过敏信息缺失显示中性“未记录”，不能自动显示安全结论。

### 7.3 当前分阶段工作区

| 工作区 | 显示内容与操作 |
|---|---|
| Review | 完整签署处方、用法数量、两级备注、安全信息及版本；整张确认或带原因退回 |
| Label | 患者用药标签预览／打印；确认已打印检查，未结算不可开始 |
| Preparation | 只读签署药品与应备量；填写批次、效期、实际数量及必要备注 |
| Final check & handover | 六项实物／患者核对、用药交代及领取记录，整张交付 |

共享工作台主题、Element Plus、AppDialog、Tailwind 和 Iconify 遵循 [桌面 UI 规范](https://virtus-patient-emr-prd.vercel.app/desktop-ui-design-system.html)。紧凑标题、状态筛选、患者栏、分区表单和固定底部动作区只呈现当前所需任务；进度带只读，不能跳步。确认框绑定当前订单／状态／版本，展示患者和“当前状态 → 下一状态”；提交中防重复，接口失败保留状态并显示错误。异常或 Hold 不显示为完成，历史不可写。

[实际 Vue 合成预览](https://virtus-ai-clip-preview.vercel.app/preview/patient-emr?app=drug-dispensing) 复用 DrugDispensingWorkspace，模拟仅在明确 preview 路由生效，不调用真实变更或打印。正常模式 API 失败不能回退假数据。[早期交互草案](https://virtus-patient-emr-prd.vercel.app/assets/pharmacy_dispensing_20260903/workspace.html) 仅保留评审来源，不作为当前 UI 或实现依据。

### 7.4 每 30 秒刷新

打开立即加载，可见时每 30 秒主动查询新处方与 Cashier 结算；保留手动 Refresh、频率、刷新中反馈及最近成功更新时间（含秒）。复用授权队列 API，不另设付款来源。

普通刷新保留 Clinic、Active／History、状态、搜索、当前选择，以及同版本同阶段的备药输入、核对、退回理由和弹窗；新记录不抢选择，诊所暂空仍保留筛选。选中记录移出结果、阶段或签署版本改变时关闭旧确认并提示重新核对。

请求进行中不重复查询；写操作忽略此前查询的迟到响应，完成后再拉取。失败保留上次数据及成功时间，提示未更新并继续重试。页面隐藏暂停、恢复立即刷新、工作台关闭清理定时器及迟到响应。

## 8. 稳定功能契约

旧主线编号保留用于测试追溯：PH-01（交接后的整单审方、预留及备药）→§2／§3／§4／§6.1；PH-02（Final Dispense）→§6；PH-03（最终核对及人员分工）→§6.2；PH-04（异常退回、医生任务及Cashier阻断）→§5。T40–T43、T73等旧用例按此映射读取本篇规则。


以下编号供验收及其他文档引用，编号不因本次合并改变；它们表示要求，实现状态以 §9 为准。

| 编号 | 契约 |
|---|---|
| RXPH-FR-001 | 当前签署版本幂等交接，不消费草稿 |
| RXPH-FR-002 | 审核、库存、费用版本及结算分别保存 |
| RXPH-FR-003 | 实收／零额／第三方及患者欠款安排分别记录，共同计算备药条件 |
| RXPH-FR-004 | 未审核不收款，未结算不备药，服务端阻断绕过 |
| RXPH-FR-005 | 药房不取消临床处方、不改药品／剂量／数量 |
| RXPH-FR-006 | 整单退回必填异常原因，保留逐行意见并建立医生任务 |
| RXPH-FR-007 | 药房退回立即阻断；护士单独确认回退 Visit；分别审计 |
| RXPH-FR-008 | 队列及详情显示独立药房／结算／库存状态和阻断原因 |
| RXPH-FR-009 | 区分审方退回、患者拒药、价格修正及实物返工 |
| RXPH-FR-010 | 医生在原 Consultation 修订签署，无第二套临床编辑器 |
| RXPH-FR-011 | 全部取消不送审；有药新版本重审；旧版本不可执行 |
| RXPH-FR-012 | 未结算预留到期释放、恢复待确认并阻断 Cashier；重复不多释放 |
| RXPH-FR-013 | 单次改价审计、Cashier 费用版本及管理处理可靠关联 |
| RXPH-FR-014 | 结算历史禁止直接改价；未结算允许零价，原因必填，不改标准价 |
| RXPH-FR-015 | 审核／复核逐药检查、整单提交；付款与打印不自动完成实物步骤 |
| RXPH-FR-016 | 整张现场领取、代领一条记录、发药后人工退换留痕 |
| RXPH-FR-017 | 新版本重审通过才解锁；旧页、旧版本、迟到事件无效 |
| RXPH-FR-018 | 未领取阻止 Closed；人工结案／例外需权限、原因及审计 |

并发库存、改价与结算、到期与结算、退回与结账均校验同一 Visit／处方／费用版本；冲突重新读取，不静默使用旧金额或失效证据。当前相关写路径使用 Visit 锁，但该锁不证明外部库存事务已完成。落账记录保留，不重复收费，任何实施不得直接改写不可变签署或账单历史。

## 9. 当前实现、差距与验收证据

下表按 `d69b45b` 代码核对，取代旧稿中“零额／第三方结算、整单门禁、双人复核全部待开发”和“整单已经全部完成”两类过时表述。

| 能力 | 当前代码事实 | 未完成或待验证 |
|---|---|---|
| 签署交接／重新签署 | 版本化 Handoff、单药品执行行、整张异常／任务及旧版本停止已有代码 | 外部交接事件传输及真实业务 UAT |
| 审核与收费门禁 | 整张确认 `whole_prescription_reviewed`；当前版本／库存证据／费用检查；护士显式回退 | 逐药独立审核勾选及逐行意见未完成；正式库存政策未确定 |
| 结算与实物交付 | 三种结算、历史保护、Label／Pack 门禁、认证不同人整张交付已有代码和隔离验证 | 真实付款渠道／打印机及临床 UAT；付款不代表已发药 |
| 库存 | 人工证据默认关闭；显式测试模式、版本校验、读取时到期失效及结算后保护已有代码 | 权威库存可用量、原子预留／释放／扣减、批次／FEFO、后台到期任务 |
| 执行状态 | `rx_review → reviewed → label_ready → packed → dispensed`；前端对应 Review／Label／Preparation／Final | 独立待复核／待发药及备药返工尚无完整状态路径 |
| 操作粒度 | Review／Hold／退回／最终 Dispense 按当前处方整张处理；Label／Pack 仍逐药品行 | 一处方一条队列及完整处方级执行体验 |
| 价格 | Cashier 可调整当前 Visit 的有效单价，药房读取有效价 | 药房独立改价 UI／管理逐条处理队列；已付改方差额闭环 |
| 人员例外 | Final 拒绝模拟身份、同一备药人、缺失备药人及非 Pharmacy 角色 | 单人重新认证和紧急主管批准路径 |
| 队列／内容／刷新 | 完整签署快照、备注层级、Clinic 下拉、精简摘要及 30 秒刷新已有代码 | 服务端跨诊所聚合授权及真实多诊所验证；队列仍逐药品行 |
| Encounter／V-Lab | 已 Closed 记录禁止常规重开；Lab／Imaging 开单基础存在 | 自动 Closed／未领取完整门禁、内部执行到医生确认的结果闭环 |

代码入口：处方服务（仓库资料：../../varclip_flask/src/services/prescriptions.py）、队列及药房退回（仓库资料：../../varclip_flask/src/services/clinic_workflow.py）、Cashier／药房事务（仓库资料：../../varclip_flask/src/services/cashier_workflow.py）、库存和最终核对规则（仓库资料：../../varclip_flask/src/services/cashier_rules.py）、Drug Dispensing 工作台（仓库资料：../../varclip_vue/src/components/desktop/apps/DrugDispensingWorkspace.vue）、前端动作门禁（仓库资料：../../varclip_vue/src/utils/pharmacyWorkflowRules.mjs）。

业务用例在 [统一验收清单](https://virtus-patient-emr-prd.vercel.app/acceptance.html) 维护，包含原 RXPH-FR、T97／T111–T113／T125 和 PH-TEST-STOCK-01–04 的相关场景。最低覆盖：审核前收款拒绝、24 小时边界、零额及第三方安排、重签重新审核、全部／部分取消、整张领取、不同人复核、测试关闭失效及未领取 Closed 阻断。用例已编写不等于已通过。

已有 Cashier／药房隔离验证（仓库资料：../test_cases/cashier/validation-20260906.md） 记录使用真实 Vue／Flask／可丢弃 PostgreSQL，在隔离测试中显式启用人工库存证据后跑通审核→结算→标签→配药→不同药房用户整单发药；医生重签等额外场景由后端测试覆盖。后续 价格验证（仓库资料：../test_cases/cashier/validation-20260907.md） 与 测试库存验证（仓库资料：../test_cases/cashier/test-stock-20260908.md） 分别记录自己的版本和范围。旧 App 验证（仓库资料：assets/pharmacy_dispensing_20260903/app-validation.md） 是当时前端证据，不是当前完整业务验收。

本轮是文档合并与代码事实核对，没有新增功能或 UAT 结果。代码存在、局部／隔离测试、本地完整部署、开发发布、Vercel App／PRD 发布、STG 实际配置、外部系统联调和业务 UAT 分别计证；既有预览不能代替真实库存、打印机、安全政策或角色验收。实施进展只更新 WS4（仓库资料：../../dev_working/workstreams/phase_0/p0_ws4_pharmacy_inventory_packages.md） 及其验证记录，不在本文追加重复发布流水。

现有 `prescriptions.amend_prescription` 在无付款／结算历史且其他医生归属、签署与权限校验通过时，仍可直接发起处方 Amendment，不强制先由护士回退，也不自动改变 Encounter。这是现行兼容行为，与§5的护士确认退回主流程分开记录。

## 10. 药品目录、诊所库存、CP 与套餐

旧主线IN-01～IN-04对应本节IV-01～IV-04，原编号仅用于历史测试追溯。

**IV-01 药品来源：** 集团 CP 药品按稳定来源身份同步，诊所继承有效可供应项，可有名称／可见性覆盖及诊所直接供应项。覆盖不改集团原药品，也不复制无来源 Drug Master。停用／删除来源不得用于新选择，历史处方保留当时药名、来源与版本。同步失败及来源时间必须如实显示。

| 编号 | 业务对象与目标 | 当前边界 |
|---|---|---|
| IV-02 | 按诊所／药品查询可用量、预留量，适用时显示批次与效期 | 有目录及库存字段，尚无处方权威库存闭环 |
| IV-03 | 出入库／调整记录数量、批次、原因、源单据与操作者；纠正使用反向记录 | 批次、盘点、FEFO 与临床发药联调待完成 |
| IV-04 | 最终发药关联处方版本、真实数量及单一库存变动，重复不重复扣减 | Dispense API 更新状态不证明库存扣减 |

CP 详细规则以 [独立 PRD](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html) 为准：一个 CP 主存货点、多个内部 clinic，Orders／Inventory／Master Data 三模块，人工收发及统一耗用，正常退药关联原实收明细，缺单先例外审批。CP 部分供货／欠货不改变患者处方整张审核与整张领取。Finance 的现行后台场景、供应商 PO 业务审批与 PIC 代码的差异也只在该 PRD 维护。

NetSuite 本期仅预留接口及数据映射，不实施连接、同步、回执重试或自动对账；CP 保留业务单据、数量、批次和必要商业数据，不因此接管完整财务核算。货权、会计及未确认 Finance 规则仍待确认。完整 WDL 采购、供应商、复杂库存等后续设计不自动纳入原 Phase 0 合同或改变既有报价。

**PK-01 Service Package：** 主档定义服务，患者 Wallet 记录购买、有效权益、预留、消耗、冲回、余额和台账；执行／扣减关联原服务或 Invoice，重复不重复扣减。目录和权益台账已有基础，完整 Cashier 对接尚待完成。到期、延长、转让、退款、套餐／Benefit／自付优先次序及收入确认仍待 Finance／营运确认，不以显示余额认定完整套餐或财务收入已实现。

## 11. V-Lab／Imaging 执行

**功能目的：** 将医生医嘱推进到结果发布和医生确认。

**使用者与对象：** 内部 V-Lab／Imaging 与原医生；Order、执行记录和 Result 版本。

**操作与结果：** 接单 → 执行 → 输入／核验／发布结果 → 医生确认；异常记录原因并回告。

**关键边界：** 内部需独立执行工作台；外部 Vendor 不建设执行账号，危急值参数仍待确认。

内部 V-Lab 必须有独立承接工作台；外部 Vendor 不建设执行工作台。Lab Service Order／Imaging Service Order 的独立规划壳已移出目录，Consultation Service 开单及内部执行仍在产品范围，执行组件接入后提供真实入口；移除壳不表示已交付或取消范围。

| 区域 | 必需信息与用途 |
|---|---|
| Order Queue | 患者、Visit、医生、项目、内部单位、优先级、状态及时间，区分待承接／执行／结果核验 |
| 医嘱详情 | 项目代码名称、样本／部位／侧别、准备、Consent 与临床说明；执行人不改写医生已签医嘱 |
| 执行记录 | 承接者、采样／检查时间、必要样本标识、执行人、结果或失败原因 |
| 结果 | 正文／文件、来源、异常标记、版本、核验人及发布时间，发布后交医生确认 |

**LB-01：** Ordered → Accepted → In Progress → Result Entered → Verified → Released → Doctor Acknowledged；Lab 可增加 Specimen Collected，Imaging 可增加 Scheduled／Scan Completed。始终关联原 Order／结果版本，不新建脱离就诊的第二张单。

**LB-02：** Rejected／Cancelled／Unable to Perform 必填原因并告知原医生，评估费用更正。异常／危急结果保留责任人及处理记录；阈值、时限及升级对象待临床确认。

**LB-03：** Closed 后收到结果建立关联 Result Event 及医生确认，不重开 Encounter；查看、上传成功和 Doctor Acknowledged 是不同事实。

**LB-04：** 外部 Vendor 本期只做目录／机构选择、开单转介、费用及人工收件。外部轨迹为 Sent、Awaiting、Result Received、Doctor Acknowledged，不提供外部执行账号、自动状态或自动结果接口。

当前开单有代码基础，完整内部执行、危急值处理及结果确认闭环仍待实现／联调。最小 V-Lab 验收必须从医生开单走到医生结果确认，不能只测医嘱创建；相关临床目录、Consent、安全及接口规则沿用各自权威规范。


---

# Cashier、保险回款、套餐与诊后任务 PRD

更新：2026-09-14 · 责任：Line A；涉及 Pharmacy、医生及 Finance 交接


**2026-09-09 导航归属：** Cashier 置于 Business Operations；Insurance & Benefit Programmes 独立维护共享保险／企业／员工计划，Packages & Coupons 集中现有套餐和优惠活动。持卡、Visit 付款安排、账单核验与回款仍在各业务记录处理。套餐现有支付链路、Coupon 核销及叠加的未完成项不因入口合并升级为已完成。票据模板的日常入口唯一放在 Cashier 右上角齿轮，使用 `billing.documents.read` 查看／打印，使用 `billing.documents.manage` 编辑；System Settings 不再向普通护士或医生提供重复卡片。模板更改不重写历史账单。完整目录与配置范围见[App 与配置层级](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#app-configuration)。
## 功能地图

围绕一次结账及其后续账务组织功能。待办、历史和日报是工作入口；费用、付款和票据是各自业务对象。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 工作入口与待办 | Cashier · 待结账 Visit | §1–2：Checkout Queue、Billing History、Day-end Report 与票据 Settings |
| 费用与发票 | Cashier · Charge／Invoice | §3：复核、折扣、单价调整及 Post |
| 收款与结算确认 | Cashier／Pharmacy · Payment／AR | §4：实收、零额、保险和欠款安排、票据及重试 |
| 保障与回款 | Billing & Insurance · Payer／Remittance | §5：计划承接、CoPay 与到账分配 |
| 纠正与离院关闭 | Cashier · 原交易／Visit | §6：退款、冲正、离院与 Closed 条件 |
| 收入报告 | 获授权员工 · 诊所／医生／业务日 | §6.1：新账本收入来源、实收、下钻和导出 |
| 诊后任务 | 业务责任人 · Task | §7：回访、结果跟进、转派与完成 |

## 1. 一次结账处理什么

Cashier 用于完成本次就诊的结账，由护士操作，不单独设置收银角色。护士需要在当前诊所服务对应医生，并具有相关财务操作权限；处理付款无需另行取得医生的临床记录查看授权。

护士先核对费用、分摊和折扣，再将发票过账（Post Invoice）、登记实际收款并出具收据（Receipt）。系统分别检查开票、结算、收款、付款安排、退款和退回问诊的权限及财务状态。

Checkout Completed 表示现场结账和离院安排完成。尚未收回的款项保留在应收账（AR），后续到账、退款和调整都记录在原业务上，不重写临床记录。

前台不执行这些付款操作。医生的只读入口及后台财务职责仍按各自授权范围处理，完整分工见 [权限方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix)。该规则于 2026-09-14 确认，角色模板、队列、接口及存量账号仍待对应实施核验。

### 1.1 团队与工作场景

2026-09-07 已确认：**Billing & Insurance 是同一个团队／角色入口**，账单、保险核验、付款责任和回款作为团队内部工作组织。后台岗位在后台处理获授权的原 Clinic／Visit／Invoice 业务；现场 Cashier 操作由当前 Clinic 与负责医生有有效服务关系、且具相应财务动作权限的护士执行；前台保留预约及基础资料维护，不能签到或执行 Cashier，不因共用能力而把后台团队混入 Clinic 角色列表。

Finance 保留为唯一后台财务角色，在后台处理获授权的 Clinic 与 WDL／CP 财务业务，具备价格查看／维护、病人附件查询／查看、每日日结报告查看的目标权限。角色归属、数据范围、历史快照及报告只读边界统一见 [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html)。本节是新确认的产品规则；团队入口、有效权限合并与后台场景已按平台实施边界章节 实现；旧账号保留来源诊所范围，完整后台跨诊所授权与权限细分尚待实施。

## 2. 页面功能与字段

Cashier 顶部保留三个日常工作入口；票据模板属于配置，从右上角 Settings 进入，不作为平级 Tab：

**角色入口边界（2026-09-12）：** 医生可进入 Cashier App 的 `Checkout Queue`、`Billing History` 和 `Day-end Report`，三者均只返回本人责任医生范围的数据；医生不能维护票据模板，且结算、收款、退款、Void 等写操作仍由 Cashier 写权限控制。`billing.day_end.read` 与只读 Cashier 数据权限独立于 Packages & Coupons，后者可见不代表获得 Cashier 操作权限。

| 页面 | 主要对象与操作 |
|---|---|
| Checkout Queue | 当前诊所中与当前护士所服务医生关联的待结账 Visit；医生可查看本人关联记录，跨日分页、搜索及医生／状态组合筛选；选择一条 Visit 后复核费用与付款责任、Post Invoice、记录实际收款／欠款并确认结算；确认后统一选择 Invoice 模板并打印，实收 Receipt 独立，最后确认离院交接 |
| Billing History | 搜索原 Invoice／Receipt／患者／Visit，查看费用、逐笔付款、剩余应收与纠正；从具体 Invoice 补收，从具体 Payment 重印 Receipt 或记录退款，符合条件时 Void |
| Day-end Report | 医生仅查看本人报告；Clinic Operations／Finance 按授权范围查看诊所报告；护士不显示该入口。报告按日期生成收入来源、实收／退款及账单 chit 下钻，支持导出／打印。仅统计新 Cashier 账本，不按患者生成报告 |

**票据设置（2026-09-08 确认）：** 右上角使用轻量齿轮入口，悬停或键盘聚焦显示 Settings 提示，打开 Invoice & receipt templates 配置页；明确显示 Back to Cashier，返回打开设置前的工作页并保留其条件与工作内容。现有标准详细发票、分类汇总发票、付款收据及诊所自定义版式继续复用；可配置 A4／A5、英文／繁体／双语、列、页尾及默认模板，不能改写收费金额。进入或离开设置时，未保存内容须先继续编辑或明确放弃；保存中禁止切换。旧模板 Tab 的已保存启动目标兼容转入设置，不恢复为主导航。

本次只迁移维护入口，沿用已有模板、版本、默认状态及票据快照，不新建底表、不迁移或重置现有模板数据。列表／保存继续使用原 API 与诊所范围；可读但没有 `admin.workflow.configure` 的账号保持只读，设置入口不授予维护权限。底表来源与字段关系见 Cashier 工程参考；正式票据快照规则见 §4.1。

Payment Collection、Invoice Builder、Receipt History、Outstanding、Refund／Void 是上述对象内部的操作，不再独立占据 Cashier 顶部 Tab。2026-09-08 明确恢复诊所／医生 Day-end Revenue Report，取代此前将收入报表随 Daily Closing 一并排除的解释；现金盘点关账／Period Close 本期不建设。


<a id="21-2026-09-07-界面修订"></a>

### 2.1 待结账队列与医生筛选

医生下拉与患者搜索、Checkout 状态共同限定队列。数据范围始终是当前真实会话的 Medical Group／Clinic 下全部 `Ready for Cashier` Visit，包含跨日待办。医生选项由这份完整待办集合独立生成，不随搜索词、状态、所选医生或当前页缩减；选项只返回医生标识和显示名，不夹带患者资料。

| 记录中的医生信息 | 稳定筛选值与匹配规则 | 显示规则 |
|---|---|---|
| 有 `doctor_user_id` | `user:<id>`；同一 ID 的就诊归为同一选项，不因显示名变化拆分，也不按重名合并不同 ID | 取该 ID 在待办中的一个非空姓名；全部缺名时显示 `Doctor #<id>` |
| 无 ID，但有旧 `doctor_name` | `name:<去除首尾空白的姓名>`；仅匹配没有 ID 的旧记录 | 显示去除首尾空白的原姓名 |
| ID 与非空姓名均无 | `unassigned` | `Unassigned doctor` |

空值表示 All doctors。格式合法但当前没有匹配记录的值返回空队列；无效的筛选键明确拒绝，不退回全部记录。医生条件在服务端统计及分页前应用，与 `q`／`status` 取交集；就绪／阻断状态仍依据当前真实收费与药房门禁计算。返回的 `total` 为组合条件下的记录数，不能只筛选当前页。

更换或清除医生条件、改变状态或提交搜索时回到第 1 页。清除医生恢复 All doctors，保留其他搜索／状态条件。已选医生最后一条待办离开队列时，界面仍明确保留当前选中条件，允许用户清除，不自动扩大查询范围。筛选不改变费用、发票、结算或临床记录。


<a id="23-cashier-与-pharmacy-的工作台边界2026-09-07"></a>

### 2.2 收费与药房的岗位边界

Cashier 只查看本次处方的药房审核、预留、结算交接及阻断原因。移除 **Open Pharmacy** 等直接启动 Drug Dispensing 的跨岗位按钮；收银人员通过状态判断是否可结账，不能从 Cashier 进入审方、打印药签、备药或发药操作。护士原有明确 Return to Consultation 动作继续保留，不等同于药房审核退回。

Nurse／Reception 的桌面目录不显示 Drug Dispensing，保存布局不恢复该窗口，缓存 App 对象或 App ID 启动请求也不能打开。由药房身份切换到这些角色时移除原药房窗口，保留仍有权使用的 Cashier 及其他窗口。Pharmacy 和其他既有获授权角色继续通过各自工作台入口承接药房工作。

本轮收敛的是**前端工作台入口与窗口边界**，未迁移后端历史 `pharmacy.dispense` 权限，也不能据此宣称 Nurse／Reception 的所有药房 API 已被撤权；真实服务端权限迁移需另行核对角色矩阵与历史调用。医生筛选、桌面入口及跨角色交接已在精确提交 `a8e8b802d3738f1e6ce025af9b3a274a2814ab94` 完成隔离回归：[CI 34091809502](https://github.com/virtus-medical-internal-private/ai-clip-cms/actions/runs/34091809502) 的后端、前端、浏览器与清理检查全部通过。真实后端部署和业务 UAT 仍未完成。


```mermaid
flowchart LR
  V[Visit 本次计划快照] --> R[核对费用与付款责任]
  S[签署收费来源] --> R
  R --> I[Post Invoice 冻结账单]
  I --> P[记录实际 Payment]
  I --> A[明确患者或第三方 AR]
  P --> C[显式确认结算]
  A --> C
  C --> D[药房进入待备药]
  P --> T[Receipt 实收凭据]
  C --> F[Print invoice 统一入口]
  A --> L[后续补收或回款分配]
```

图中结算须同时满足整张审方、有效库存及当前费用版本；未付款欠款必须显式登记，不能仅凭存在 AR 自动放行。

## 3. 费用复核与开票

**功能目的：** 把本次有效收费来源形成可追溯的发票。

**使用者与对象：** 有结账权限的现场员工；Charge、Payer Split、Invoice。

**操作与结果：** 复核来源／数量／价格 → 必要时带原因改价 → 核对付款责任 → 显式 Post。

**关键边界：** 草稿、已 Post 发票、实际收款是不同对象；历史账单不随目录价格变化。

**BL-01：** 只汇总真实有效来源。医生的 Billing Draft、签署 Charge Snapshot 与 Cashier Invoice 是不同对象；不能重复把同一处方或服务加两次。上游已取消／替换版本必须标清影响，不能继续收旧版本价。

**BL-02：** 折扣来源分 Coupon、Insurance／Benefit Contract、Doctor Adjustment、Package／Membership、Manual Exception。自动规则记录来源 ID／版本；医生调整与人工例外必须说明。百分比与固定减额不能导致负净额；医生行折扣界限见 Consultation PRD。

**BL-03：** Post 前复核数量、权威价格、折扣、付款方及本次保障异常。Invoice 冻结项目、适用价格和规则快照。缺价不自动补 0；100% 折扣或套餐扣减后净额为 0 仍是有收费来源，不自动等于 No Cashier Required。

目录新价格、患者卡有效期或合同后来改变，不改已 Post Invoice；更正需独立记录。复杂折扣叠加和套餐扣减顺序需已批准规则，不能测试人员自行猜定。

### 3.1 当前就诊单价编辑

2026-09-07 用户明确要求 Cashier 费用明细支持自主改价。本轮入口覆盖当前 Visit 的有效收费行，按现有 `billing.checkout` 权限及来源 Clinic 校验；不增加审批等待，也不把 Finance 新工作场景的待实施权限视作已经生效。

- 只修改本次收费单价，保留数量、原签署内容和目录标准价。每项变更必填原因，记录原价、新价、操作者、时间、稳定来源及临床／收费版本；同一操作重试不重复留账。
- 金额允许 0，必须为非负、有限且精确到分。原医生折扣规则独立保留：百分比按新 gross 重算，固定减额保留，固定净额仍遵守原目标；若新价格与原规则冲突导致负数或折扣超过 gross，拒绝并说明冲突，不悄悄抹除医生折扣。
- 只允许 `Ready for Cashier` 且从未发生付款或结算的 Visit；零额结算、第三方安排、后来退款／撤销结算均计入历史。已发生这些事实后，直接改价不可用，继续通过原交易的受控纠正处理。
- 若存在尚未付款／结算的草稿或已 Post 发票，保存改价时同一事务作废该旧票，保留原票、金额、版式快照和作废原因。新的费用需重新选择／核对付款责任并明确 Post；不自动签发替代票，不覆写旧 Invoice。
- 服务端核对调用方看到的费用版本；旧窗口改价、旧金额开票或收款均拒绝。价格调整绑定其原始收费依据；医生重签、更换药品或数量后不自动挪用旧版本的人工价。
- 改价不代表药房审核或预留完成；开票和结算继续检查整张当前处方／库存门禁。本轮 Cashier 入口与药房独立改价入口、管理人员事后处理队列分别计实现状态。

<a id="cashier-settlement"></a>

## 4. 一次性结算与药房联动

**功能目的：** 确认患者本次付款或欠款安排，向药房发出可备药结果。

**使用者与对象：** Cashier；当前 Invoice、Payment、患者／第三方 AR 与结算记录。

**操作与结果：** 审核与库存通过 → 记录实际收款或明确欠款安排 → 确认结算 → 药房备药；结算后统一打印 Invoice。

**关键边界：** 结算确认不等于全部到账；Receipt 仅对应真实付款，已登记欠款保留应收。

**BL-04：** 药房审核期间只可先核对其他费用，药费显示等待药房确认；不先收其他费用。全部药品审核／库存预留通过后，核对有效价格版本，统一结算全部费用。未通过、退回、价格待核对或预留释放时服务端阻断收款。

**BL-05：** 药房所需条件是 Cashier“结算已确认”：普通自费收妥全部本次款项；整次应收 0 时显式确认零金额结算；存在第三方责任时须明确确认，且患者自付已结清或全部余款已明确登记欠款，再确认付款安排。2026-09-10 用户明确确认“登记欠款安排后即可放行备药”，覆盖此前患者自付必须全部结清的限制。Cashier 可登记患者本次全额欠款、部分付款后的余款或保险 CoPay 欠款，不增加本轮未要求的额外审批。实际收款、零金额确认、患者与第三方应收分别记录，不把未到账应收伪装成 Paid。整张当前处方审方、有效库存及费用版本门禁仍须通过；结算确认不自动写为已备药／已发药。

**BL-06：** Receipt 关联真实收款；零金额结算留确认记录但不生成实际收款流水。重复提交、重印均不增加付款。现有多笔付款数据基础保留，但不得把原“先收服务费／后收药费”或跨阶段部分收费当作本期正常药房流程。

**BL-09：** 药房审核退回整张处方时立即建立 Cashier 阻断，但 Encounter 暂留 Ready for Cashier。护士进入 Cashier 时看到阻断提示和药房原因，只有护士明确确认 Return to Consultation 后才恢复 In Consultation；药房退回与护士回退分别审计。医生重签后仍阻断，当前新版本再次审核／预留通过才解锁。患者不要药由 Cashier 退回并立即释放预留；医生取消全部药品后不再送审，核对剩余费用；部分取消需重新药房审核。回退保留首次签署及原快照。未发生实收／结算的发票可在同一回退事务内按明确原因作废；已发生付款或结算后不可直接回退，需受控差额更正流程。当前完整实现与验证状态见交付说明。

本次药品改价只影响当前处方收费，改价必填原因、允许零价，所有 Drug Dispensing 操作人员可在未结算时直接操作；管理人员事后处理改价记录，不审批本次改价。Cashier 必须使用新费用版本；不覆盖已签署临床记录、已 Post Invoice 或历史付款。重新形成费用／账单快照的服务端方案需按现有表和审计能力设计。

| 场景 | 结果 |
|---|---|
| 审核未通过，但问诊费已核对 | 仍不能先收问诊费，药费等待确认 |
| 审核／预留通过，总额 HK$920 | 统一收取 920 后确认结算，药房进入待备药 |
| 整次应收 0 | Cashier 确认零金额结算，放行备药，无虚假付款 |
| 自付 100、已确认保险承担 820 | 收妥自付并确认付款安排后可备药；820 保留应收 |
| 自付 100、保险承担 820，本次实收 40，余款 60 登记欠款 | 明确确认付款安排后可备药；患者 AR 60、第三方 AR 820，实收仅 40 |
| 自费 920，本次不付款 | 明确登记并确认患者欠款 920 后可备药；无实际 Payment／Receipt |
| 旧页面按改价前金额提交 | 拒绝并重新核对当前费用版本 |

金额为合成测试数据。

<a id="cashier-document-snapshots"></a>

### 4.1 票据与重试

发票正式 Post 时固定当时有效默认模板版本和患者／诊所／医生显示快照；付款登记时固定 Receipt 模板。更改默认模板仅影响未来签发。旧数据缺少历史快照时，首次重印明确保存其补录来源，不能声称还原历史模板。草稿有 DRAFT 标识，作废发票显示 VOIDED，退款后重印显示已退款金额；Credit Note 与调整后金额单独显示，原发票总额不改写。

2026-09-10 票据入口收敛后，Post 使用有效默认 Invoice 模板，模板选择移至结算后的统一打印入口。用户可为当前这次 Invoice 打印选择有权使用的有效版式；打印事件单独冻结该版式／版本，原签发模板、费用和身份快照保持原值。未明确选择其他模板的重印仍使用原签发版式。此改动不移除既有历史／草稿文档 API，不把界面简化解释为额外的历史查看权限限制。

每一笔实际付款记录明确方式、金额和外部凭据；付款方式不得自动推断。拆分支付在同一结算事务中全部成功，或全部拒绝。失败重试使用同一请求标识；改动金额或方式后生成新标识。零额结算不生成虚假 Receipt，打印请求不新增收款，也不等于打印机已成功出纸。

### 4.2 历史纠正

尚未完成 Checkout 的就诊，若结算被退款更正撤销，剩余款项必须回原 Checkout 复核当前费用及药房状态后统一结算。Billing History 显示原因及 **Open checkout** 入口，不提供会被后端拒绝的独立补收按钮。仍有效的付款安排可以从原 Invoice 登记患者补缴或第三方回款，即使当场 Checkout 尚未完成；Checkout Completed／Closed 后的历史应收继续在 History 办理。患者金额已补足时，Checkout 明确提示重新确认原结算，不再要求新增付款或误称第三方安排。退款更正撤销结算时，原欠款记录保留但不自动重新授权放行；回 Checkout 重新安排欠款须再次明确确认。History 的既有重新确认路径仍要求先补足患者责任。

历史应收保留原 Visit 关联，即使 Visit 已 Closed 仍可登记实际到账；不重开临床记录。Checkout Completed 后、取药前如付款纠正撤销了结算，补足患者责任后可从原账单明确重新确认结算；必须仍是同一处方／费用版本及有效预留，不新增付款、不改变 Checkout 状态。Closed 不允许此药房重新放行，只可处理历史财务应收。每项付款方的补收不超过其剩余责任，第三方应收不显示为已到账。Void 仅适用于无付款的草稿／已过账发票，退款不通过删除或改写 Payment 完成。

已在外部完成的退款，必须记录原 Payment、金额、原因和凭据。`Payment correction` 保留原收费，退款金额重新成为应收并撤销原结算放行；`Service refund` 生成独立 Credit Note 冲减应收，原 Invoice 金额不变。当前服务退款只支持患者责任部分；第三方 Credit 分摊、正式审批流与在线退钱仍待实现。有未完成或已供药品时须同时留下人工药房／库存处理记录；Credit Note 必须明确确认签署处方仍有效，不能以财务冲减代替取消药品，系统不会自动退库。药房最终交付仍要求有真实授权的另一位 Pharmacy Checker 完成实物复核；单人／紧急例外在重新认证及审批流程完善前不可使用。


<a id="21-当前结账的界面与操作顺序"></a>

<a id="cashier-checkout-ui"></a>

### 4.3 结账界面：阶段、金额与票据入口

**信息承接与票据入口：** 费用、Visit 本次计划、已核对付款责任、实际收款和欠款沿用同一上下文，阶段变化不重新填写同一信息；确认失效及草稿保留见 [IN-05–07](#cashier-payer-arrangement)。结算前集中复核费用、责任与本次付款／欠款，不重复展示 Invoice 模板、预览或打印区。结算已确认后提供一个 **Print invoice** 入口，在共享弹窗中选择模板并打印；实收结清、零金额、保险及患者欠款安排确认均适用，不要求全部应收到账。Receipt 仍关联真实付款；模板／账务快照和每次打印记录的唯一规则见 [票据与重试](#cashier-document-snapshots)。历史操作及模板管理仍在 Billing History 和 Settings，不在当前 Checkout 复制。

三个工作入口采用紧凑的顶部切换，移除旧式常驻左侧模块栏；使用与 Consultation 一致的页面标题、搜索工具栏、患者／Visit 信息层级、状态标签及表格密度。收费明细占用可用宽度，数量、单价、折扣和净额对齐；1280px 和 1366×768 下关键金额及主要操作必须可见。表格和录入仍复用 Element Plus 与桌面共享组件，不复制 Consultation 中尚未迁移的旧原生控件。

Cashier 对齐 Drug Dispensing 的视觉层级：患者／历史发票使用共享深蓝信息栏；主要分区复用带中性图标的 `WorkspaceSectionHeader`，白色内容区配合清楚的分隔、18px 标题及14px 表格内容；顶部入口使用紧凑的选中态。Checkout、Billing History、票据版式编辑及弹窗保持一致，次级字段与说明不与主标题争夺注意力。费用／付款状态、金额和单一主要操作仍遵循下表。

进入一条 Checkout 后直接显示本次费用，可在 Charge review 选择 **Edit prices**。编辑态显示单价输入、改价原因和重算后的金额；保存前明确列出改价及旧票作废影响。取消保留原价；有未保存改价时，返回队列、切换工作入口或其他 Visit 必须先保留或明确放弃编辑。

结算详情的信息与操作顺序：结算详情底部固定展示**当前关键金额及一个主要下一步操作**，不随收费明细滚动消失；1280／1366×768 下金额和按钮均应在可视范围内。患者身份简化，费用来源与药房交接保留为辅助信息，付款方式在发票 Post 后成为当前操作区域。

| 当前阶段 | 主要展示 | 主要操作与限制 |
|---|---|---|
| 费用／付款责任复核 | 患者本次应付；费用总额、折扣与已确认第三方责任为次级信息 | Review & post invoice；未开票金额明确为草稿费用 |
| 正在改价 | 未保存的新费用总额及原总额；无效输入不显示为0或继续沿用旧总价 | Review price changes；保存前不提供开票／收款主操作 |
| 已开票、待收款／安排欠款 | 患者剩余应付、本次实收及本次后剩余欠款分别展示 | 全付时 Collect & confirm settlement；有患者余款时须明确登记 Outstanding Payment 并确认，不能默许差额 |
| 零额或付款安排 | 区分整单零额、第三方应收和已安排患者欠款 | 显式确认对应结算；保险承担及患者欠款均不得显示为实收 |
| 已确认结算 | Settlement confirmed；实际收款与未到账第三方应收分别呈现 | Complete checkout；完成状态不以醒目的0金额误导为免费 |

患者已付使用患者实际付款口径，不将保险／企业到账混入患者余额计算；发生 Credit 时原 Invoice 总额保留，调整后金额作为当前费用口径并解释差额。确认开票／收款弹窗也应突出待确认金额、患者及付款责任，不能把关键金额埋在长段落中。


| 区域 | 字段／操作 | 业务结果 |
|---|---|---|
| 待收费队列 | 患者、Visit、医生、交接时间、收费／付款状态、异常 | 选择正确就诊；姓名进入 eMR 时不误触发收费行选择 |
| Charge Review | 来源类型／原对象／版本、描述、数量、单价、gross、discount、net | 能解释每一笔费用从哪里来 |
| Payer Split | 自付、保险／企业应收、适用规则与本次核验 | 分摊总额与 Invoice 净额一致，不将估算当实际回款 |
| Invoice | 草稿、Post、历史、Void／受控更正 | 固定账单版本；不能用后改目录重算已 Post 事实 |
| Payment | 方式、金额、时间、参考凭据、分配账单、余额 | 本次费用统一结算，实际到账与第三方应收清楚 |
| Receipt | 对应付款、打印／重印和历史 | 重印不新增付款 |
| Outstanding / Remittance | 未结余额、第三方到账、分配、未分配金额 | 应收与实际收款单独追踪 |
| Corrections | 原记录、原因、调整／退款／冲正、批准信息 | 保留原记录并创建关联纠正 |


<a id="22-checkout-queue-医生筛选2026-09-07"></a>

## 5. 保险与企业计划

**功能目的：** 将本次保障资料转为明确付款责任，并追踪后续回款。

**使用者与对象：** Billing & Insurance／Cashier；Visit 计划快照、付款分摊及 Remittance。

**操作与结果：** 承接人工核验 → 复核责任与 CoPay → 开票结算 → 实际到账后分配并冲抵对应应收。

**关键边界：** 有卡、人工资格确认、第三方责任和实际到账分别记录，不互相替代。

<a id="cashier-payer-arrangement"></a>

### 5.0 本次付款责任、CoPay 与 Outstanding Payment

来源：2026-09-10 用户要求保险卡全额／CoPay 与其他付款方式连贯，并支持当次不付款、部分付款及后续补缴；同轮确认登记欠款安排即可放行备药。本节为已确认需求及具体交互契约，实现、测试、部署状态另见 WS5 与测试记录。

**IN-05 连贯选择：** Checkout 从 Visit 的本次 Payment Arrangement 带出保险／企业／员工计划及已有审核信息；患者持有保险卡本身不等于本次保险付款。保留计划名称和原 Policy／Benefit Contract 来源，保险与企业计划不改成现金付款方式。Cashier 明确复核付款方名称、责任金额及确认结果；不得仅因选择过保险卡自动认定全额保障或保险承诺到账。开票后在付款区保留原 Invoice 编号和冻结付款责任，不按后来主档变更重算；编号为只读信息，不新增开票／打印操作。已有人工资格核验、预批核及参考编号以只读摘要承接；页面刷新收到新发票、责任金额、实收余额或结算状态时，旧确认及待提交确认框失效，需复核新状态；账务状态未变时保留未提交付款凭据和欠款说明。

| 责任方式 | 当次录入与展示 | 患者付款区域 |
|---|---|---|
| Self-pay | 患者承担当前账单费用 | 本次全付、部分付款＋余款欠款、全部 Outstanding Payment |
| Insurance / Benefit programme · Full coverage | 明确第三方承担全额，患者责任为 0；仍须确认责任 | 无患者付款行；明确第三方待收，不生成零元收款 |
| Insurance / Benefit programme · CoPay | 明确患者自付及第三方责任，两者相加等于当前费用总额 | 患者可用一种或多种实际方式支付；也可将全部／部分 CoPay 登记欠款 |

**IN-06 实际方式：** Cash／Card／FPS／Bank transfer 等实际付款方式只用于真实已收款。每笔输入金额、付款方与必要凭据；Other 必须留下可追踪说明。`Outstanding Payment` 是患者欠款安排，不能作为一笔付款方式伪造实收或 Receipt。一次确认可原子保存多笔实收与余款安排；任何失败全部回滚，同一请求重试不重复收款或登记。

**IN-07 欠款确认：** 选择 Outstanding 后明确显示原患者应付、本次实收、剩余患者欠款及第三方待收。填写欠款原因，可填写约定付款日期，并主动确认患者欠款安排；服务端根据当前账本和本次真实付款计算欠款金额，记录确认人、时间及原始安排。全额不付时不要求建立零元付款行。不得超收患者或第三方各自剩余责任，也不能以一方的到账掩盖另一方欠款。未输入完整确认／原因时保留编辑并说明阻断原因。确认后修改、增加或删除本次收款行，会取消原欠款确认，必须按新的剩余欠款重新确认。

**IN-08 后续补缴：** 使用 Billing History 的 Outstanding 筛选定位原 Invoice，显示患者欠款和第三方待收两个余额；从原账单 **Record payment** 选择付款方、实际方式、金额与凭据，允许分次补缴。每次只冲抵所选付款方剩余责任，产生对应实际 Payment／Receipt，保留原安排和所有历史；患者付清不等于第三方到账，账单所有应收结清后才显示 Paid。Closed Visit 也可补缴，不重开临床或重发药。欠款确认本身不进入日报实收；补缴按实际发生日进入收款，不能再次累计原开票收入。

**页面结构：** 采用[统一指南 §8.3](https://virtus-patient-emr-prd.vercel.app/desktop-ui-design-system.html#quick-start)的全宽对象工作区。开票前顺序为费用复核与付款责任，Post 后将患者付款／欠款录入放在主要可见区域，责任快照仍可查；底部固定一个当前主要操作，金额分层显示。本次全付、部分付、全部欠款使用同一组 Element Plus 选择及表单控件；确认对话框复用 AppDialog。保留三个主入口和右上角 Settings，不把 Outstanding 或付款方式新增为主 Tab。


<a id="2026-09-07-预约付款安排交接"></a>

<a id="2026-09-07-人工计划审核交接"></a>

### 5.1 预约计划及人工审核结果

Checkout 患者上下文只读展示 Visit 保存的 Payment Arrangement 与计划名称。Insurance、企业或员工计划不自动设置第三方责任或金额；Cashier继续分别确认患者自付、第三方责任和实际收款方式。已有账单的 Visit 不允许从 Appointment／Registration 改写付款来源，需使用收费调整流程。未新增自动赔付／应收或资金通道。完整前置规则见 Frontoffice §4.3。


#### 人工核验结果如何承接

本期 Appointment／Registration 使用人工审核确认按钮记录计划、资料变化、有效期、资格和预先申请结果，并由服务器记录审核人、时间与本次计划／日期范围。待核实、不合资格、申请待批阻断准备交接；旧 Checked 文案不构成通过证据。Cashier 仍需复核本次保障及付款责任，不将“人工确认”自动转换为保险公司承诺或企业应收；完整输入和状态规则见 Frontoffice §4.4。

<a id="51-资料和核验分工"></a>

### 5.2 资料和核验分工

| 资料 | 权威维护人／入口 | Cashier 如何使用 |
|---|---|---|
| Card Programme | Finance／Benefits Admin，Insurance Cards | 读取类型、来源与卡面，不复制成新目录 |
| Policy／Benefit Contract | 各自权威来源 | Insurance 与企业／员工计划来源分开；复杂合同后台本期隐藏 |
| 患者持卡 | Patient & eMR | 个人卡号、有效期、主卡及备注不是核赔结果 |
| 本次 eligibility | Registration 人工审核确认（Frontoffice §4.4） | 开票前检查是否过期、变更、未确认；保存当时证据快照 |

**IN-01／IN-02：** 本期可人工核验并记录方式、人员、时间、结果和证据，不伪装保险公司实时答复。没有资料时不能默认成功，不能将上次预约 Case／Eligibility 自动复制成这次结论。

<a id="52-回款分配"></a>

### 5.3 回款分配

**IN-03：** 登记保险实际到账金额及参考资料，选择一项或多项 Claim／Invoice 分配；允许部分分配并保留未分配余额。分配总额不得超过可分配到账额或对应可冲抵余额。误分配先撤销该分配，再建立正确分配，原 Invoice 和到账事实保留。

回款记录不等于电子 Claim、自动 Adjudication 或自动核赔。本期实现仍不完整，需单独端到端验收。

**IN-04 已确认：** 第三方未到账保留为该付款方的 AR；其回款等待不阻塞已按 [BL-05](#cashier-settlement)确认的备药交接。结算条件只维护在 BL-05，患者欠款及补缴规则见 [IN-05–08](#cashier-payer-arrangement)。

## 6. 退款、更正与关闭

**BL-07：** Invoice Void、退款及冲正需要原交易关联、权限、原因和审计。已付款或已发药的纠正需同时检查 Pharmacy、库存、Benefit／Package 的影响；不能删付款行或直接改签署处方掩盖事实。具体退款审批及差额执行沿用受控财务流程；本期已发药退换在药房人工处理并记录异常及结果，不自动退库或退款。

**BL-08／CL-01：** 完成当场结账并确认患者取药、检查、文档和后续安排后，才表示 Checkout Completed。满足临床签署、Checkout、付款／应收安排、即时 Handoff 接收及无阻断条件后，首次签署满 24 小时且不存在未完结待发药记录才自动 Closed；每晚必须在 System Settings 配置的 Nightly close window 内完成结算和报表准备，逾期进入异常清单但不改变 24 小时生命周期；待领取会暂缓关闭，AR 不阻塞，原记录不可重开。

现金盘点关账、Period Close、经营看板和完整财务核算不属于本期验收。诊所／医生 Day-end Revenue Report 按下节 2026-09-08 的明确要求实施。

### 6.1 Day-end Revenue Report

**DE-01 目标与主体：** 用户于 2026-09-08 明确要求诊所及医生层级的每日收入报告，查看总收入、收入来源及对应 chit；随后确认先依据底表代码构建，只保留新的数据，报表主体与病人无关。报表按当前诊所＋香港业务日期生成，可限定一位医生；不设置患者报表或患者筛选。chit 仅作为收入凭据的次级下钻。

**DE-02 数据与范围：** 读取新 Cashier 的正式发票、冻结费用行、逐笔 Payment、Refund 和 Credit Note，复用关联 Visit／Operating Unit 的真实会话范围校验。旧 MyPlatform 的 `chic_chit`、历史 eMR／Consultation metadata 账务不展示、不汇总，不建设旧新账本合并。All doctors 只表示当前有效诊所内全部医生；跨诊所需要切换已有授权上下文，不能用查询参数扩大权限。不同币种分别统计，不换汇混加。

**DE-03 收入与收款：** 当日净收入＝当日过账发票金额－当日 Credit－当日已过账发票 Void。原过账金额保留，之后才发生的 Void 不从原报表日期抹除；草稿及从未过账的 Void 不算收入。Credit／Void 是独立调整，不虚构分摊到具体费用行。按冻结行的真实业务类别展示问诊、药品、检查／服务等开票来源；底表未区分的检查与服务继续合并，不猜分类。付款方式和付款方解释资金来源；Payment 按 `paid_at`、Refund 按发生日归入香港业务日。前日发票今日到账只增加今日实收，不再次增加今日开票额；零额结算、第三方安排、未到账 AR 不算实际收到的钱。净收款＝当日实收－当日退款，允许负数；一次 Service refund 同时产生退款现金事件和 Credit 收入事件，两者各计一次。当前调整后金额／未收余额必须标为 Current，不能冒充所选日期的历史日终余额。

**DE-04 日期与医生：** 数据库账务时间当前采用 Asia/Hong_Kong 本地 TIMESTAMP，业务日按 `[00:00, 次日00:00)` 查询，不再次加八小时。开票快照保存 Doctor ID 与姓名，后续 Visit 改派不改变原发票和关联收款／更正的收入归属；本轮之前缺 Doctor ID 快照的新系统账单回退当前 Visit 归属，不能声称已还原历史身份。Doctor ID 是稳定分组键，同名不同 ID 分开；无 ID 的姓名分组和 Unassigned 必须可解释。非法日期、医生或币种拒绝，合法无数据条件显示空结果。

**DE-05 界面与追溯：** 先显示报表主体、日期、币种、生成时间及收入／资金汇总，再显示业务来源和医生分组；底部账单记录是可展开的凭据，不把患者数量或患者列表作为报表重点。下钻复用新 Invoice、Visit、费用行及付款关联。Visit ID 与真实 Chit No. 分开，不用 `V-<id>` 冒充旧系统 Chit No.；本轮不显示旧系统历史报表。显示字段优先使用票据冻结快照，缺值不伪造。

**DE-06 导出与安全：** CSV 与打印来自当前已生成报告，保留筛选、生成时间及金额口径。修改日期／医生／诊所或角色后旧结果失效，禁止以旧数据导出新条件报表；异步旧请求不能覆盖新范围。CSV 正确转义逗号、引号、换行和公式起始字符，打印转义自由文本。真实后端失败不得自动用预览样例替代；公开预览使用明确标注的独立合成报告。

**DE-07 权限与边界：** 本轮复用 `billing.checkout` 和当前来源诊所范围，生成报告只读、禁用缓存，不执行日结关账、修改账务或新增 Finance 全集团权限。后台 Finance 独立最小报表权限与完整跨诊所授权按平台权限实施，不因报告界面出现而默认完成。

**DE-08 验证：** 至少覆盖多医生／同名医生、多收费行、拆分付款、零额／草稿／Void、跨日到账及退款、更正日期、币种隔离、香港日界、医生筛选、空结果、范围隔离及导出打印勾稽。底表与历史入口调查见 `agent_docs/test_cases/cashier/day-end-source-readback-20260908.md`；实际部署、测试及发布证据见 `agent_docs/test_cases/cashier/day-end-validation-20260908.md`。规则已确认，本轮实现与验证状态分别记录，不代表 STG／UAT 已验收。

## 7. Tasks & Follow-up

### 7.1 任务解决什么问题

患者离开或跨团队交接后仍有未完成工作：回访、Recall、转介、结果确认、文档交付、药房问题及后续咨询。任务引用原患者／Encounter／来源对象，不能建立第二份处方、结果或账单。

**FU-01 已确认最低内容：** 患者、来源就诊、任务内容、负责人、状态、处理结果和必要关联；完成需留下结果，复诊创建新预约，不重开原 Closed Encounter。实际消息渠道未接入时仅记录人工联系，不能标系统自动送达。

### 7.2 已有设计，待统一实现／确认

| 编号 | 功能设计 | 规则与结果 | 状态 |
|---|---|---|---|
| TK-01 | My Work／Team／Completed 列表 | 按当前用户、团队、诊所、类型、负责人和状态筛选；同一任务不因切视图复制 | 统一工作台待完善 |
| TK-02 | Create／Assign／Reassign | 记录患者／Visit、来源、说明、Owner／Team、Due date、Priority；转派留原因与历史 | 通用模型及细分角色待确认 |
| TK-03 | Start／Record communication／Complete | 通信记录渠道、对象、结果、摘要；完成写处理结果及后续动作 | 完成口径、通信写入待统一 |
| TK-04 | Snooze／Escalate | 暂缓写新日期和原因，升级写接收人和问题，不能悄悄消失 | 通用 SLA／自动升级本轮延期，不设默认时限 |
| TK-05 | Open source／Book follow-up | 回原医生／药房／检查／收费入口；带来源上下文，回来保留原任务 | 医生处方 Amendment 已有专用任务基础；其他来源待接通 |

建议的通用任务状态为 Open／Assigned → In Progress → Completed 或 Cancelled，Snoozed／Escalated 为待细化处理方式；这是待确认设计，不作为当前服务端既有状态代码。Doctor Acknowledgement 和处方修订仍由各领域权威动作完成，普通“Complete task”不能代签临床结果。

## 8. 验收方式

BL／IN／FU 用例覆盖来源收费、审核门禁、统一结算及药房同步、历史快照、回款错配及诊后任务；尚未完成的退款、回款、套餐及统一任务链记 Blocked。不能以 Invoice 页面能打开作为 Cashier 整体通过。


---

# Catalogue、优惠与保险计划业务 PRD

更新：2026-09-10 · 责任：运营／Finance／保险管理／平台 · 详细底表设计保留在原 Catalogue 技术规格中

**2026-09-07 角色与价格维护确认：** Finance 需要查看并维护获授权的价格资料；Clinic 与 CP 的财务价格工作统一在后台 Finance 完成，不切换成 Clinic 角色。复用本 PRD 与 CP 各自的权威价格记录、生效及版本规则，不反写历史账单或采购快照；维护权限不能只配置为读取，也不自动扩大为所有主档或发布审批权限。Insurance 与 Billing 合并为 Billing & Insurance 团队入口。统一场景及权限契约见 [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html)。当前 Finance 的目录初始化仅授予 `catalogue.read`／`coupon.read`，价格写权限仍待实施；场景入口已按平台实施边界章节 实现，不能以入口可见视作价格维护权限已交付。

## 功能地图

先区分“共享定义”“患者持有”“本次使用”“实际资金”四层，再阅读各主数据功能。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 服务与非药品 | 目录维护者 · Item／Product | §3：共享售价、成本和可用诊所 |
| 检查目录及供应商成本 | 目录维护者／Finance · Test | §4：统一项目、Vendor 映射及分层成本 |
| 医生问诊定价 | 获授权价格维护者 · Pricing | §5：标准价、Policy／Clinic 例外及解析优先级 |
| 保险与企业计划 | 计划维护者 · Programme | §6：目录、Policy／Contract 来源、卡面与权益说明 |
| 套餐与优惠 | 运营 · Package／Campaign | §7：共享定义、患者权益及核销边界 |
| 导入、发布与变更 | 获授权维护者 · Draft／Version | §2、8–9：校验、发布、停用、历史与配置归属 |

## 1. 管理边界与导航

本 PRD 维护相关主数据的既有唯一业务规范；对外入口分属 **Catalogue**、**Insurance & Benefit Programmes** 和 **Packages & Coupons** 三个 App，均属于 Business Operations。2026-09-09 用户确认：保险／企业／员工计划独立，不放 Catalogue；Coupon 与 Service Packages 放同一 App。

Catalogue 固定导航为 Service Items、Lab & Imaging、Products、Consultation Pricing、Change History & Controls；只维护共享服务、检查、非药品项目、价格及成本。打开即进入实际列表，不另设说明性 Overview，不嵌套保险、套餐、优惠或 Other Settings。患者个人卡号在 Patient & eMR，药品临床属性及库存由 Pharmacy／CP 对应工作台承接。

Insurance & Benefit Programmes 承接 §6；Packages & Coupons 承接 §7。复杂 Benefit Contracts 后台仍不开放；既有有效企业／员工合同可作为卡种来源。入口及全局／个人／页面设置范围见[App 与配置层级](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#app-configuration)。

```mermaid
flowchart LR
  A[Programme 共享计划目录] --> B[Patient 患者持卡及个人编号]
  B --> C[Appointment 或 Visit 本次选择与核验]
  C --> D[Cashier 付款责任与应收]
  D --> E[Payment 实际到账与分配]
  P[Policy 或 Benefit Contract] --> A
```

目录更新影响后续选用；患者默认计划不自动成为本次选择，本次人工核验也不代表实际收款。各层保留自己的来源与历史快照。

## 2. 共用规则

**MD-06：** 新记录 Draft → 发布后 Active → 停用 Inactive。发布、停用及价格变更要求相应权限、原因和审计；本期不强制第二人审批。已用于交易的记录不物理删除；签署处方／医嘱、套餐购买、报价及 Invoice 保存当时项目与适用价格／规则快照。

**List Price** 是对患者的参考售价，**Cost** 是内部成本，不能用同一个字段混写。主数据更新只影响后续按规则取价，不自动改历史交易。

## 3. Service Items 与 Products

| 内容 | Service Items | Products |
|---|---|---|
| 列表字段 | Code、Name、Category、List Price、Cost、Available Clinics、Status | SKU／Code、Name、Category、List Price、Cost、Available Clinics、Inventory Tracking、Status |
| 搜索筛选 | Code／Name、Category、Clinic、Status | 同左，另有 Inventory Tracking |
| 编辑补充字段 | Description、生命周期信息 | Barcode、Unit of measure、Description |
| 价格规则 MD-01 | 所有诊所共用同一 List Price 与 Cost | 同左；药品不在普通 Product 内维护 |
| 可用诊所 | 新建默认 All Clinics；可搜索多选、全选或清空 | 明确空选表示所有诊所不可用，不自动恢复 All Clinics |

Clinic 只控制能否选用，不能覆盖 Service／Product 的 List Price 或 Cost。Quantity、Lot、入库、出库和采购不在产品主档页处理。

## 4. Lab & Imaging

**MD-02：** 一个 Test Catalogue，不再拆四个平行页面。一条规范 Test Item 显示 Unique Code、Name、Category、Lab／Imaging、List Price、Vendor 覆盖、Cost 覆盖与状态；可按名称／代码、类型、Vendor、Category、Status 筛选。Test Item 对所有诊所可用，无 Available Clinics 字段。

点击项目打开详情：基本资料 → Vendor & Code Mapping → Clinic／Doctor Cost Schedule。

| 资料层 | 字段 | 定义 |
|---|---|---|
| Test Item | 唯一代码、名称、分类、类型、List Price | 患者售价统一，不随 Vendor／Clinic／Doctor 改变 |
| Vendor mapping | Vendor、Vendor Item Name、Vendor Code、Vendor Default Cost、生效信息 | 同一项目可有多个 Vendor；代码与默认成本属于该 Vendor |
| Cost schedule | Test Item、Vendor、Clinic、可选 Doctor、Cost、生效信息 | Doctor + Clinic + Vendor → Clinic + Vendor → Vendor Default → Cost unavailable |

Request Form Mapping 已从当前管理界面移除；旧四页结构和 Group Default Cost 不再作为验收标准。Vendor 映射、成本明细持久化及解析仍待后端，界面可编辑不等于落库成功。

## 5. Consultation Pricing

**MD-03：** 每位医生一套 Standard Consultation Price，适用于各就诊类型与诊所，可有诊所例外。Insurance Rate 按 Doctor + Card／Policy 定义，默认全诊所适用，也可另设诊所例外。

取价优先级固定为：**Doctor + Policy + Clinic → Doctor + Policy → Doctor + Clinic → Doctor Standard → Price unavailable** 。

列表显示 Doctor、Standard Price、Clinic Exceptions、Insurance Rates、Status；详情维护基础价与例外、生效信息。不得再按 Doctor + Clinic + Consultation Type 建另一套基础价。当前新模型及 Billing Resolver 未落地，不能以旧 Offering 返回了价格认定该规则通过。

## 6. Insurance & Benefit Programmes

独立 App 管理 Insurance、Corporate membership 和 Staff benefit 目录。这些是保险／合作保障安排，不是折扣券；患者持有资料及本次付款安排仍分别归 Patient／Visit。

### 6.1 卡种字段与来源

| 字段 | 要求 |
|---|---|
| Programme Type | Insurance、Corporate membership 或 Staff benefit |
| Provider／Sponsor、Card Name、Plan Name、Card Class、Status | 使用业务名称展示；不是患者个人实例 |
| Linked Policy | 只用于 Insurance，引用现有 Policy |
| Linked Benefit Contract | Corporate membership／Staff benefit 必填，且必须与合同类型匹配；Promotion／Insurance 类型 Benefit Contract 不可选 |
| Front／Back card face | 官方 JPEG／PNG／WebP，单张不超过 5 MB；可上传、预览、替换或移除，使用私有文件访问 |

**MD-04：** 类型切换清除不兼容来源，互斥保存。历史未标类型的卡兼容为 Insurance。卡种只存来源身份，不复制合同 Plan、Rule、额度、Pricing、Eligibility 或 Utilization。

保险卡页为卡面网格，支持类型／提供方／状态和关键词筛选；零数据仍有 New Card 入口，缺图明确显示，不能用示意卡冒充。患者持卡、预约和登记统一读取此目录。

### 6.2 简单 Policy 管理

Manage Policies 在保险页内打开侧边编辑，维护 Policy No.／Name、有效期、Holder Type、Contract／Insurance Type 与 Billing 可见性。没有独立顶层 Policy 页。企业合作计划不得写入 Policy 假冒保险合同。


<a id="2026-09-05--insurance--benefit-programmes界面已确认"></a>

### 6.3 计划详情与双语权益说明

- 统一独立桌面 App、页面标题及 Patient & eMR 的目录引用名称为 **Insurance & Benefit Programmes**。覆盖 Insurance policy、Corporate membership、Staff benefit；稳定 app ID、API 路径及既有底表保持不变。企业 / 员工计划仍引用同类型 Benefit Contract，保险仍引用 Policy。
- 卡片的 **View details** 和既有卡片编辑抽屉增加 **Benefits & policy information** 只读区。权威数据来自 `policy_card_info.card_id → policy_card.id`，逐条显示 `title_cn`、`title_en`、`msg_cn`、`msg_en`；保留多条记录、全文、换行、列表、强调和安全链接，在一个详情区域内按每条记录中文在前、英文在后连续展示，不分栏、不显示语言标签或选择器；空标题、空正文及全空记录自动隐藏，不自动翻译或补造业务规则。
- 说明按需从 `GET /api/insurance-card-programmes/{id}/information` 读取，沿用 `benefits.read` 权限，响应禁止缓存；不添加到共享目录、患者 H5、自助登记或患者主档快照。排除软删除说明及已删除卡片。加载中、无记录、读取失败和重试有独立界面状态，切换卡片后不显示上一个请求的内容。
- 原始 HTML 必须净化后渲染，保留文本强调、颜色及列表；移除脚本、事件处理器、表单、嵌入内容、图片及不安全链接 / 样式。JSON 附件含业务说明与门户凭证，本轮不导入附件、不将其内容写入 Git 或预览。公开／本地演示均使用合成数据。
- 用户提供的 JSON 是按名称导出的示例，缺少 `card_id`、`id`、`type`、`clazz_id`。不按名称自动建立数据库关联，不推测 `clazz_id` 的适用范围；上线前须用目标环境数据核对直接关联覆盖率。这是说明展示能力，不是自动保险资格核验、费率解析、Claim 或预批核执行能力。
- 验收：保险和企业计划入口使用统一名称；一张卡的多条双语说明在单一区域内完整显示，无语言选择器；纯文本、富文本、单语言空值、无记录、失败重试、跨卡切换和恶意 HTML 均有对应验证。底表无 schema 变更、无说明写入，本轮不扩展编辑或批量导入。
当前代码与合成预览已有该展示链路。目标后端部署、真实关联数据与业务 UAT 单独验收；发布记录在变更日志与测试材料中维护，不在本页逐轮追加。详情抽屉不显示 Source preview；卡片编辑保留来源选择，展示区仅使用真实双语业务说明。

## 7. Packages & Coupons

**MD-05：** Coupon 字段包括名称／Code、折扣类型与值、最低消费、可选最高减免、有效日期、次数限制、适用对象、描述及 Stackable。默认不与 Contract／Benefit 叠加，只有明确 Stackable 才允许。

同一 App 内保留 Service Packages 与 Coupons 两个业务区。Packages 沿用现有 Setup、Sale、Wallet、Consumption、Liability 和 Lab 协作；Coupons 独立读取 Campaign、编辑并按权限发布，不再为了打开优惠页读取 Catalogue 全套底表。

Campaign 管理不代表 Cashier 已能核销；优惠与套餐的读取、维护、发布权限独立。套餐现有购买／支付链路不因导航合并改成统一 Cashier；实际核销必须保存 Campaign／版本与撤销历史，跨套餐与优惠叠加仍需对应后端实现。套餐核销、退款与财务规则见 Cashier／Pharmacy 文档。

## 8. 批量导入

支持的主数据用同一流程：Bulk import → 下载模块专用模板 → 上传 Excel／CSV → 全文件预校验 → Pass／Warning／Error 逐行预览 → 选择获支持的重复处理策略 → 确认导入 → 行级结果／错误下载及审计。

- 导入仅产生 Draft，不绕过发布权限，不把警告或错误隐藏成全成功。
- Service、Test Item、Product、Coupon、Policy 可复用现有导入基础；每种字段仍按本域验证。
- Insurance Card 逐卡维护，**不提供 Excel 批量新增** 。
- Clinic Availability、Vendor／Cost Schedule、Consultation Pricing 及 Package Component 的正确底表未完成前，不开放模拟成功导入。

## 9. 变更控制与配置归属

Catalogue 移除 Other Settings。共享系统资源归 System Settings，组织／账号／权限归 Organization & Access，个人模板／布局归 Personal Settings；药品及库存仍归所属业务 App。Change History & Controls 显示本模块谁改了什么、原因、版本、发布／停用结果，不是经营报表。

验收重点：字段含义、可用范围、价格优先级、失效与历史快照、互斥来源、导入前校验、实际持久化。每个尚缺底表的功能在[实现记录](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)标 Pending，不能因前端预览完成而关闭需求。


---

<a id="ai平台设置权限审计与集成边界-prd"></a>

# 组织、权限、平台与 AI 产品方案

更新：2026-09-14 · 责任：权限与平台为 WS6／WS7，覆盖 Line A–D；AI 与集成为 Line D

本方案说明集团内各类人员如何使用患者资料，以及管理员如何配置岗位、权限和审批。阅读时可以先了解数据归属和人员分工，再查看具体资料的访问规则，最后了解配置、授权和审计流程。

正文描述产品要求。已经实现到哪一步、哪些内容仍待确认，集中见第 11 节；相关验证记录从该节查阅。


<a id="1-各板块服务谁"></a>

## 1. 功能地图与阅读顺序

| 功能 | 解决的问题 | 使用者与入口 | 说明位置 |
|---|---|---|---|
| 组织与对象模型 | 集团、诊所、医生、护士、患者和病历是什么关系 | 管理员配置；所有模块共用 | §2 关系图和对象定义 |
| 数据查看与编辑 | 某人对某类资料究竟能做什么 | 业务页面及服务端统一判断 | §3 权限矩阵与患者资格 |
| 用户、岗位与角色配置 | 为员工配置有效岗位和服务范围，并解释结果 | Organization & Access | §4 账号、岗位、角色模板与概览 |
| 临床授权与交接 | 护士或其他医生怎样申请、批准、续期和撤销 | Consultation／Requests & Approvals | §5 授权流程、范围及例子 |
| 桌面与设置 | 功能放在哪里，入口和设置如何一致 | 桌面／业务 App／Settings | §6 目录、配置归属与入口规则 |
| 审计与异常复核 | 追溯实际访问和变更，处理异常 | Audit & Review | §7 日志、规则与复核 |
| AI 与知识库 | 提供转写、提取、草稿和参考 | 业务内 AI／Clinical Copilot | §8 输入输出与人工确认 |
| 外部集成与平台准备 | 明确接口、迁移、恢复和移动端边界 | 业务岗位／平台人员 | §9–10 |
| 待确认与实施差距 | 区分方案与尚未交付的能力 | 产品、开发、测试 | §11 |

阅读权限部分时，先看第 2 节的人员和数据关系，再看第 3 节的访问规则。需要配置账号或处理授权申请时，分别进入第 4、5 节。

角色说明一个人可以做哪些工作；诊所、服务医生和记录授权进一步确定他可以处理哪些资料。例如，护士服务某位医生，可以处理相应的护理工作，但查看医生的完整问诊记录仍需授权。

<a id="domain-relationships"></a>


<a id="41-组织患者与记录的归属"></a>

## 2. 集团、人员、患者与记录的关系

### 2.1 组织与人员：岗位连接人和工作单位

```mermaid
flowchart TD
  G[Medical Group 集团] --> C[Clinic 诊所 A 或 B]
  G --> O[Back Office 后台]
  G --> W[WDL / Central Pharmacy]
  U[User 同一真实员工] --> M[Membership 岗位：主体、有效期]
  C --> M
  O --> M
  W --> M
  U --> R[Role 用户唯一角色]
  R --> M
  U --> P[Provider 稳定医生身份]
  P --> D[该医生在某 Clinic 的有效关系]
  C --> D
  M --> N[护士在某 Clinic 的有效岗位]
  N --> S[服务关系：护士 + Clinic + Provider]
  D --> S
  S --> A[医生另行授权：记录、查看或编辑、期限]
```

集团下可以有诊所、后台和中央药房等工作单位。员工通过岗位与工作单位建立关系，同一个人可以在多个单位任职，但当前业务角色保持一致。

医生在不同诊所出诊时，沿用同一个医生身份。护士可以服务多位医生，每条关系都要说明所属诊所。图中的关联不会自动授予其他资料权限。房间、设备等预约资源单独管理，不使用共享医生账号。

| 对象 | 它回答什么 | 关联与边界 |
|---|---|---|
| Group 集团 | 属于哪个组织及共享边界 | 本文共享规则限同集团，不外推跨集团 |
| Clinic／Operating Unit | 工作或业务发生在哪个单位 | Clinic、Back Office、WDL 场景分开；当前工作单位不改写业务来源 |
| User 员工与账号 | 实际是谁、是否可登录 | 当前角色唯一；姓名不作为稳定身份；停用不删除历史作者 |
| Provider 医生身份 | 哪位医生负责临床记录 | 与 User 稳定关联；跨诊所不重复造医生身份，不按同名匹配 |
| Membership 岗位 | 此人在这个主体担任什么角色、何时有效 | 继承用户唯一角色，各主体范围分别计算；不能以新增岗位赋予第二个角色 |
| Role 角色 | 可以执行哪些类型的动作 | 如读取、维护、申请、签署；仍须匹配数据范围和记录状态 |
| Nurse service scope 护士服务范围 | 在哪个 Clinic 服务哪些 Provider | 可以显式整诊所或指定医生；不等于医生已开放完整病历 |
| Grant 授权记录 | 谁批准此人对哪些记录做什么、何时有效 | 与服务关系分开；护士临床授权不能越过来源 Clinic 的有效归属 |

<a id="user-single-role"></a>

#### 用户角色唯一性（2026-09-10 用户确认）

一个账号只有一个当前业务角色。员工可以在多个工作单位以同一角色任职，但不能在 A 诊所是医生、在 B 诊所是护士。新增岗位只增加工作范围，不增加第二个角色。（2026-09-10 用户确认）

Cashier 是护士使用的收费功能，不单独设置业务角色。前台保留预约及患者基础信息维护，护士按所在诊所和服务医生关系处理护理及付款。具体资料范围见第 3 节。后台 Finance、Billing & Insurance，以及医生获授权的只读报告入口，继续按各自职责使用。

Staff／External 只是人员分类，不是业务角色。管理员测试功能时，应模拟另一个真实用户，不给自己的账号叠加角色。系统仅开放明确授予的权限，未写明允许的操作不自动放行。

CP Staff 可以保留本人角色，在获授权诊所代办采购；采购授权不包含患者发药，也不需要增配 Clinic Pharmacy 角色。详细规则见 [CP 采购代办](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html#cp-clinic-procurement-delegation)。这项能力仍需按 CP PRD 的实施状态判断。

### 2.2 患者与病历：同一人，多次就诊，多份来源记录

```mermaid
flowchart TD
  P[Patient 同集团共享患者主档] --> A[Appointment 某次预约]
  P --> V[Encounter / Visit 某次就诊]
  A -.到诊关联.-> V
  C[来源 Clinic] --> V
  D[负责 Provider：适用时明确] --> V
  V --> N[Consultation Note 完整病历]
  V --> RX[Prescription 处方]
  V --> X[生命体征、服务、检查及附件]
  P --> S[公共医疗摘要与历史索引]
  N -.生成有限摘要.-> S
  RX -.生成有限摘要.-> S
  P --> L[患者关联多个 Clinic]
  F[首次建档来源和有效历史 Visit] --> L
```

患者主档由集团共享。同一位患者可以在多家诊所就诊，也可以由不同医生接诊；每次就诊记录分别保留来源诊所、负责医生、实际作者和版本。

因此，找到一位患者，并不意味着可以读取其全部病历。系统根据正在查看的资料类别，分别判断是否允许访问。

本文把患者资料分为基础信息、公共医疗摘要、完整问诊记录、处方和附件。一次就诊（Visit／Encounter）将相关记录联系起来，但这些记录各有访问规则。敏感字段还需要单独处理，详见下一节。

<a id="access-matrix"></a>

<a id="4-consent-与数据访问"></a>

## 3. 查看与编辑权限如何匹配

权限设计围绕三件事展开：集团共享患者基础资料，医生负责问诊记录，护士和药房按照各自职责处理本次就诊。共享到什么程度、谁可以修改，需要分别说明。

患者基础信息可以在集团内查询，修改和确认仍由与患者有关联的诊所按权限处理。公共医疗摘要也在集团内共享，但需要单独授予角色读取权限。完整问诊记录由负责医生管理，其他医生和护士需要获得相应授权。

护士与医生的服务关系按诊所维护。护士日常处理日程、签到、本次附件和付款，不需要为这些工作逐次申请临床记录授权；查看完整问诊记录或历史附件时，再检查医生授权。药房人员则按处方所属诊所承接审方和发药。

<a id="31-先匹配动作再匹配数据及状态"></a>

**通用规则（AC-02）：** 以上权限都以有效账号和岗位为前提。系统还会检查角色允许的操作、资料所属范围、授权期限、记录状态，以及适用的患者同意。能够查看一份资料，并不代表可以修改、导出或签署它。

### 3.1 医生、护士的日程与问诊记录范围

**医生主要处理本人负责的日程和问诊。** 系统根据医生身份和有效诊所任职，显示其工作范围。查看其他医生的完整记录，需要明确的记录授权；这类授权只开放获批资料，不同时授予日程管理、代诊或签署权。集团基础资料查询和获授权的公共医疗摘要，不受医生本人问诊名单限制。

**护士的工作范围是“在某家诊所服务哪些医生”。** 例如，医生甲同时在 A、B 两家诊所出诊，可以分别由不同护士支持。A 诊所的护士只能根据 A 诊所的服务关系处理工作；即使服务的是同一位医生，也不能因此处理 B 诊所的日程、签到、附件和付款。

护士如需在另一诊所工作，应先切换到本人有效的该诊所岗位。系统随后重新加载该诊所的服务医生和授权记录，并清除旧患者、队列、历史列表及提醒数量。切换前尚未完成的请求，即使稍后返回，也不能把旧资料带回页面。

列表、搜索、详情、下载和保存使用同一套权限规则。直接输入记录编号或打开旧链接，也要经过检查。缺少必要的诊所或医生关系时，系统提示原因，不改为显示全诊所资料；跨集团访问不在本共享范围内。

### 3.2 数据类别 × 查看 × 编辑

下表用于快速比较各类资料。具体申请方式和例外见后续小节。

| 资料或工作 | 谁可以查看 | 谁可以维护或执行 |
|---|---|---|
| 患者基础信息 | 同集团内具有基础资料查询权限的人员；敏感字段先隐藏 | 与患者有关联或获准接收的诊所内，具有相应维护权限的人员；前台只维护基础字段 |
| 公共医疗信息 | 同集团内，角色被授予公共医疗信息读取权限的人员 | 按对应业务模块的修改权限处理，共享读取不附带修改权 |
| 完整问诊记录 | 负责医生，以及获得相应记录授权的其他医生或护士 | 负责医生；获准护士可以协作编辑允许的草稿，不能最终签署 |
| 日程、签到和付款 | 当前诊所内，服务对应医生且具有相关功能权限的护士 | 关联护士按流程操作；前台保留预约操作，不签到或收款 |
| 本次问诊附件 | 负责医生及具有附件权限的关联护士 | 关联护士可上传、查看、删除，操作须留审计 |
| 历史问诊附件 | 负责医生，或取得原记录查看授权的人员 | 本次附件管理权不包含历史附件修改、删除权 |
| 处方和药房执行信息 | 负责医生、获医生授权的护士或其他医生，以及处方对应诊所的获授权药房人员 | 医生开立、修改和签署处方；药房审方、备药、复核、发药，并处理本域允许的价格操作 |
| 敏感字段 | 独立查看授权生效后，按批准范围显示 | 另需字段维护权限、诊所资格和版本检查 |
| 权限及审计记录 | 具有相应管理或审计权限的人员 | 只执行获授的管理、审批或复核操作 |

**完整问诊记录包括什么。** 本文所指的受限记录包括完整问诊笔记（Note）、诊断详情、检查结果和正式临床文档。护士读取这些内容时，需要在记录所属诊所有有效岗位、服务该位医生，并取得仍有效的查看授权。查看和编辑草稿分别授权，具体方式见第 5 节。

公共医疗信息读取应在角色模板中单独配置，并清楚显示是否已授予。拥有基础查询权限，或角色名称是 Doctor、Nurse，都不能代替这项配置。药房安全资料、V-Lab 执行资料及后台财务资料，继续按各自岗位的必要业务范围和既有权限提供。

**旧资料如何处理。** 已明确分类为公共资料的旧记录，可以按集团及角色权限只读查看。归属不清的完整病历、结果、正式文档和历史附件，应先核对来源与授权；缺少负责医生不能成为公开正文的理由。系统保留来源质量标记，不根据姓名猜填医生，也不允许借来源修复改写历史。

管理人员可以查看获授权的配置和审计信息，但管理身份本身不开放患者或临床正文。护士目前已有的草稿协作范围及处方草稿的实施差距，统一见 §11.2。

#### 敏感字段的查看流程

敏感字段在搜索、列表、患者详情、审核页和历史快照中默认隐藏。系统只在查看获准后返回明文，不提前把完整值发到页面再遮盖。

1. 用户点击“申请查看”。页面提示：“本次敏感信息查看将记录操作者、患者、查看字段、时间、用途及结果，供操作审计。”
2. 系统按独立字段权限和适用审批规则处理，并显示申请状态。确认审计提示不等于申请获批。
3. 授权生效后，用户可以查看批准范围内的字段。未授权、待批准、到期或撤销时，字段继续隐藏。

系统记录访问结果和授权依据，审计日志不复制敏感值。修改或确认其他基础资料时，不会自动显示原敏感值；未读取、未修改的隐藏字段也不能被空值覆盖。

现有敏感字段分类继续适用。完整字段清单，以及现有机制尚未覆盖的审批人和有效期配置，仍需在实施前细化；本次确认没有授予无限期访问。

<a id="patient-profile-access"></a>

### 3.3 患者资料修改与确认：诊所资格与集团查询分开

患者基础资料归集团管理，包括姓名、性别、出生日期、证件资料、联系方式和地址等。集团内有查询权限的人员可以检索和查看这些资料，不必先在当前诊所为患者建立一次就诊。敏感字段仍按上一节的流程处理。

**修改和确认资料，需要诊所与患者有关联。** 前台可以新建、修改和确认获准范围内的基础信息；医疗及安全资料、保险计划和整份 H5 提交审核，由具备相应权限的岗位处理。

| 患者情况 | 诊所如何取得维护资格 |
|---|---|
| 新建患者 | 系统记录首次建档的诊所，作为维护资格来源。只关联本次注册诊所，不关联创建人员任职的全部诊所；前台只录入基础信息 |
| 患者曾在 A、B 两家诊所就诊 | 两家诊所均可依据有效就诊记录取得关联。各诊所人员仍按角色和字段权限维护，不另设唯一的 Primary Clinic |
| 接收诊所尚无既往就诊记录 | 通过有效转诊、推荐或另行批准的新预约，取得该患者在接收诊所的维护资格。批准以患者和诊所为单位，无需逐人申请 |
| 只有普通预约或技术关联 | 可以处理获授权的预约，但预约确认（Confirmed）和技术关联本身不产生资料维护资格 |
| 旧患者没有注册来源，也没有有效就诊记录 | 同集团有维护权限的护士可以填写原因并“接收登记”。系统锁定并复查来源后，将患者登记到当前诊所；如已有历史但来源缺失或冲突，应先核对资料 |

需要申请接收资格时，工作人员从患者页为当前诊所提交申请。原诊所有审批权限的人员或指定负责人，在 Requests & Approvals 处理。批准后，接收诊所内的有效前台、医生和护士，按照各自的维护动作和字段范围使用资料。

待批、拒绝或取消的申请不提供维护资格。批准到期或撤销后，这项资格停止；如果诊所已有独立的有效就诊关联，仍按该关联判断。通过预约取得的接收批准必须关联同一患者、同一诊所的有效预约，预约取消或改诊所后不再继续放行。

患者卡片显示真实关联诊所，不将操作者当前岗位写成患者归属。历史关联只依据可核实的建档审计恢复。接收批准开放的是资料维护资格，其他医生的完整记录和敏感字段仍按各自授权处理。

### 3.4 公共摘要、历史详情与附件如何呈现

**先让工作人员了解病史概况，再按权限打开详情（AC-10）。** 具有公共医疗信息读取权限的人员，可以查看集团内的就诊次数、最近日期、诊所和医生，以及诊断摘要、药物摘要、生命体征、安全摘要、疫苗等非受限医疗资料。打开历史页时先加载这些索引，无需逐条检查全部历史正文授权。

当前 Patient 360 候选展示最近记录中的诊断和药名，各最多十项，并标明最近日期。历史药名不能直接当作医生已核实的当前用药。摘要也不能包含整篇正文、完整 SIG 或给药指示，搜索不能利用未授权正文泄露内容。

没有详情权限时，页面仍显示用户有权查看的摘要，并提供申请入口；应说明“需要授权”，而不是显示“没有病史”。其他医生要读取完整处方、问诊正文、诊断详情、检查结果或正式临床文档，须取得原医生或指定负责人的记录授权。确认患者详情或阅读审计提示，不能代替这项批准。历史附件、版本和 AI 上下文同样按来源授权处理。

**不同类型的历史资料按以下方式处理：**

- 疫苗旧记录即使缺少可靠的就诊关联，也可供同集团且具有公共医疗读取权限的医生、护士查看。新增、更改和撤销仍检查来源医生的写入权限。
- 安全备注及核实日期属于公共资料。更正备注需要维护权限、获准写入的有效就诊记录和版本校验；省略备注保留原值，明确提交空值才清除。系统不恢复未分类的旧完整病历快照，核实及创建时间由服务端维护。
- Service Selection 和既往服务项目索引按公共医疗读取权限显示。历史只取本次就诊之前、同一患者且来源一致的有效记录。完整检查结果和报告正文仍需临床授权。
- 查看公共资料不会触发空草稿保存或 Note 推荐。护士编辑需要有效草稿授权，推荐及最终确认继续检查医生权限。
- Vital Trends 翻页失败时保留已加载曲线；切换患者或身份时清空旧资料并取消旧请求。只有真实迁移记录显示迁移提示，已删除或患者、诊所来源冲突的记录不进入索引。

系统在返回公共资料前核对患者和集团来源。撤销 Note 查看权，不影响另有权限的公共资料；补齐原本缺失的负责医生后，详情和返回前检查应使用新的归属规则。某份处方可以查看，也不代表同次就诊下的独立报告或附件都已开放。

安全资料修改的现有代码限制，以及旧接口和附件分类的验证进度，见 §11.2。

<a id="42-医生护士与运营访问"></a>

<a id="operational-access"></a>

### 3.5 预约、护理与患者资料使用不同范围

**护士负责所服务医生在当前诊所的日常工作。** 有效服务关系配合相应功能权限，允许护士处理日历、预约创建和变更、签到、本次附件及 Cashier。护士可以服务“本诊所全部医生”，也可以服务“指定医生”；前一种配置只扩大服务范围，不自动取得医生的临床记录授权。

服务医生清空、关系结束或授权失效后，系统显示无有效服务范围，不恢复为全诊所。跨诊所总览同样不授予现场操作权限。

**前台保留预约和患者基础资料维护。** 前台可以在授权范围内查询、创建、确认、改期或取消预约，也可以检索、新建、修改和确认患者基础信息。写入资料时检查维护权限及当前诊所的患者关联或接收资格；共用表单只向前台开放基础字段。

前台不执行签到、护理、附件管理或付款，也不维护医疗、安全和保险计划资料，不审核整份 H5 提交。这些限制同时适用于页面和直接接口。预约阶段记录付款安排，仅用于预约信息交接，不代表已经收款或结算。

**本次附件和历史附件分开处理（AC-08）。** 关联护士无需另获临床记录授权，就可以管理本次问诊附件，包括上传的检查报告等文件。不过，这项权限不包括系统生成的正式临床文档或结构化临床记录。

删除本次附件时，系统保留文件标识、来源、操作者、时间及删除记录，并保护已签临床版本和引用证据。历史附件不能按本次权限删除；查看时仍检查原就诊、诊所和医生授权。打开旧就诊，或把旧文件复制关联到本次，都不会使它自动变成可自由访问的本次附件。已关闭（Closed）的就诊也不能因此重新打开。

新预约、签到、付款及服务关系本身，不开放完整问诊记录或历史附件。其他医生的记录查看与临时代诊职责分别授权。对于没有负责医生的 No Consultation 服务，资源及护理分工仍待确认，不能默认交给全诊所护士处理或收费。

<a id="44-一致拒绝撤权与临床版本"></a>

### 3.6 Consent、撤权与版本控制

**患者同意应按用途管理。** 建档、通信、跨诊所共享、程序或手术、AI、资料发送是不同用途，不能用一次勾选代替所有同意。现有系统已有部分就诊纸质 Consent；患者级版本、撤回、监护人（Guardian）、用途绑定及共享细则仍是部分实现或待确认。AI Scribe 沿用 Consultation 已有的同意检查。

**授权变化后，后续操作按新权限执行。** 账号停用、服务关系结束、授权撤销，或用户切换角色、诊所、患者时，系统清理不再允许显示的内容和缓存。切换前的迟到响应不得恢复旧正文。如果撤权先于保存提交，保存应被拒绝；此前已经合法提交的内容保留作者和版本。

护士保存的草稿记录其本人身份，医生复核该版本后再签署。授权不允许直接覆盖已签历史、药房交接或收费快照；已关闭的就诊不可重开。查看权限也不自动包含导出、复制为新记录或编辑。

收紧权限时，应同时提供可用的申请和审批入口。系统不能为兼容旧宽权限而补造医生批准。页面应分别说明加载失败、没有数据、无权限、待审批和记录状态不允许修改，帮助用户判断下一步操作。

<a id="user-access-design"></a>


<a id="3-admin--configuration"></a>


<a id="94-用户配置与医生护士授权界面方案"></a>

## 4. 用户、岗位与角色配置

管理员在用户详情中维护员工资料、配置岗位和服务医生，并查看最终生效的权限。组织、角色模板和审批记录各自在对应入口维护；用户详情引用这些配置，不再维护另一份副本。医生另在个人设置中管理护士的临床授权。


<a id="32-工作场景角色与业务来源2026-09-08-更新"></a>

### 4.1 工作场景与角色

工作场景按岗位职责组织。后台角色即使可以查看、维护或处理诊所业务，也在后台场景完成对应操作；不能因为业务记录来自某个 Clinic，就把该后台角色列在 Clinic 下或要求切换成诊所角色。CP 的仓库执行和现场管理工作在 WDL 场景完成；相关财务工作统一进入后台 Finance，即使任务与问诊、处方或结算关联，也不因此归入 Clinic。

| 工作场景 | 角色归属与承接 |
|---|---|
| Clinic | 诊所现场岗位与其获授权操作。现场收费由同 Clinic／Provider 关联护士按动作权限承接，前台处理预约和基础资料维护；不能以需要收款为由加入后台角色 |
| 后台（Back Office） | Finance 及其他后台岗位，在后台查询、维护和处理获授权的业务；以来源 Clinic／WDL 单位及业务类型作为筛选和对象上下文 |
| WDL／Central Pharmacy | CP Staff／PIC 的仓库执行与现场管理；Finance 不在此场景另设入口；CP 在 WDL 处理供货与仓库任务，保留源 Clinic 和单据关联；患者发药在 Clinic Drug Dispensing。Staff 保持原角色，仅按另行授予的目标诊所采购动作代办，具体范围见 CP §4.1 |

**AC-04：** 同时区分当前工作场景／Operating Unit、有效角色、获授权的数据范围、业务记录的来源 Clinic。后台或 WDL 操作不修改原业务归属，也不复制第二份 Invoice、处方、附件或库存记录。列表按获授权的来源 Clinic 筛选；进入详情继续校验对象、动作和版本。审计同时记录真实操作者、工作场景、有效角色及源业务对象／Clinic。

**AC-05：** Finance 统一属于后台（Back Office），Clinic 和 WDL 均不提供 Finance 角色入口。财务在同一后台 Finance 中处理获授权的 Clinic 与 WDL／CP 价格、采购财务、附件查询和报告工作，按来源单位／业务类型筛选；进入关联记录后保持后台 Finance 身份。复用原权威记录、状态和版本，不复制单据或通过角色切换扩大权限。本条取代 2026-09-07 的后台与 WDL 双场景规则。

**AC-06：** Insurance 和 Billing 是同一个团队，角色入口合并为 **Billing & Insurance**；保险核验、账单、付款责任和回款是同一团队内部的工作。团队作为后台岗位工作时使用后台场景，不为处理某诊所的账单切换为 Clinic 角色。现场岗位的 Cashier 能力与后台团队入口分开配置；团队合并不自动赋予 Finance、采购审批或临床签署权限。旧 `billing-team`／`insurance-team` 账号关系与审计需要在实施时兼容迁移，不能只改显示名后声称已经合并。


<a id="33-finance-的业务权限2026-09-07-已确认"></a>

### 4.2 Finance 的业务动作

| 权限 | 入口与行为 | 数据及操作边界 |
|---|---|---|
| 价格查看、维护 | 后台 Finance 维护获授权的 Clinic／CP 价格，引用各自权威价格记录 | 包含写操作，不能只提供只读；遵守已有版本、生效和审计规则，不反写已签署处方、已 Post Invoice 或历史采购快照。各价格域的发布／审批仍沿用其产品规则 |
| 病人附件查询、查看 | 在后台 Finance 按患者及获授权的 Clinic／WDL 关联业务查询、打开原附件 | 受患者／来源 Clinic 数据范围及适用 Consent 控制。附件只读不自动授予完整临床正文或附件新增、修改、删除权限；记录实际访问 |
| 每日日结报告查看 | 后台报告入口按获授权的诊所和日期查看真实报告及其状态 | 报告只读，不自动授予执行日结、重新开账或修改结果权限；无报告显示未生成／不可用，不生成假报告 |
| CP 财务工作 | Finance 在后台查看、处理来源 WDL／CP 的采购及价格业务 | 供应商 PO 财务审批的既有业务要求继续；当前 PIC 实现与 Finance 目标之间的迁移、发送和审批分工差异见 CP PRD，不因角色可见自动授予全部仓库操作 |

2026-09-08 用户明确要求构建诊所／医生 Day-end Revenue Report，仅统计新 Cashier 账本，收入报表按 Cashier §6.1 实施；现金盘点关账／Period Close 继续排除。角色场景归属和上述权限是目标产品契约；角色入口及有效会话分类已有基础；完整后台数据范围及权限细分仍待实施。


<a id="36-组织权限与审计工作台"></a>


<a id="941-目标与信息架构"></a>


<a id="942-用户列表和基本资料"></a>

### 4.3 管理入口与用户资料

普通管理员应能在一个用户上下文内完成资料、任职和服务范围配置，并解释为什么该用户可以或不可以访问某类资料。医生在 Settings 中管理关联护士授权。共享角色模板、组织主档和审批记录保留各自唯一来源。

| 一级入口 | 页面内容与默认行为 |
|---|---|
| Users／用户 | 默认进入；搜索人员、维护资料与岗位／服务范围、查看实际权限和医生授权 |
| Organization／组织 | 集团、Clinic、Back Office、WDL 主档；有资格者在组织详情维护管理／审批职责；医生目录只汇总并链接同一用户详情 |
| Roles & Permissions／角色与权限 | 展示全部基础业务角色及实际生效动作；Doctor、Nurse、Master 支持集团配置，其余基础角色只读解释。编辑、预览及发布复用同一集团版本 |
| Requests & Approvals／申请与审批 | 按申请类型区分临床记录授权、患者资料接收批准；查看待办、结果和历史，显示各自受益主体与审批依据 |

角色目录的“业务操作数”统计当前有效 permission，不表示可见菜单、App 或 Tab 数量。三角色集团模板只覆盖 Doctor、Nurse、Master；其他受支持角色读取既有有效底表授权，并保留已有角色权限上限，不得因未纳入模板或发布三角色模板被清空。CP Staff／PIC 应显示实际 CP 动作；Finance 保留获授的 CP 只读入口，不因此获得审批或仓库写权限。Billing／Insurance 旧别名使用同一边界。未知／停用角色仍不可用。当前页面未提供菜单 → App → Tab 的可配置树；入口可见性仍按角色、场景及实际动作权限计算，不能把本轮零权限修复记为界面权限编辑器已实现。


Audit & Review 继续独立。医生护士授权位于 Settings（Personal Settings）内，不要求医生打开管理员 App。个人偏好和系统共享设置维持既定入口。

用户详情只保留“基本资料”“岗位与服务范围”“权限概览”三个页签。原 Service Scopes & Approvers 不再承接日常人员配置：护士服务范围迁入岗位详情，负责人指定迁入组织／人员的职责区域。旧入口保留定向跳转及筛选上下文，不维护第二份配置。2026-09-10 用户补充：仍展示多人关系记录的列表提供 Element Plus 用户搜索，可按姓名、用户编号或邮箱查找；服务端在分页前匹配，包含有效及历史记录，清空后恢复当前权限内全部结果。

#### 用户列表与资料查看

用户列表以姓名和邮箱为主，分别显示 Account type、唯一业务角色、工作单位及账号状态；User code 保留搜索及详情只读，不作为首列。Account type 只解释账号分类，正常值显示 Staff／External，不再混入 Permanent／Locum 等雇佣类型。Employment type 不在用户列表、新建或日常资料编辑中展示，未修改的存量值原样保留。旧 human／未知分类显示 Needs classification，不能根据雇佣类型推断 Staff／External；受授权搜索中的旧 service 显示 Service account (legacy)，不自动转换或新增此类型。

默认展示人员，技术服务账号保留受授权搜索和历史兼容；支持姓名／用户编号／邮箱搜索、主体／角色／状态筛选。点击进入用户详情，返回时保留原筛选和滚动位置。

详情、组织配置和角色配置使用 App 内右侧栏，窄窗口占满 App 内容区域；列表筛选及滚动位置保留。遮罩不关闭，未保存变更须确认放弃，提交期间阻止重复操作及关闭；页头与主要保存操作固定，内容内部滚动。

2026-09-11 用户确认：Organization & Access 采用 Catalogue 的页面结构与视觉层级：带 App 图标及当前角色的侧栏、统一选中态，白色页头承接标题和刷新／新增操作，搜索与筛选放入列表卡片。Users、Organization、Roles & Permissions 和 Requests & Approvals 使用一致的留白、表头、按钮高度及侧栏配置方式；窄 App 窗口保留可滚动表格和完整内容，不因浏览器宽度掩盖窗口溢出。控件继续复用 Element Plus，不照搬旧页面的原生表单或过小字号。

详情顶部固定显示姓名、账号状态、返回入口；内部页签切换保留同一用户。顶部账号状态只表示登录资格，不把账号 Active 解释为所有岗位及授权均生效。

| 区域 | 字段与操作 |
|---|---|
| 基本资料 | 姓名、邮箱、电话、Account type（Staff／External）；日常编辑移除 Employment type 和自由文本组织／部门／专科。旧 human／service／雇佣字段保留兼容，不批量改写；账号分类不产生角色或权限 |
| 医生资料 | 具 Doctor 身份时显示稳定 Provider 标识、执业注册资料、共享专科目录关联及执业状态；姓名复用人员资料。专科更正同步旧文书／目录使用的当前专科字段，不改历史文书快照 |
| 账号控制 | 启用／停用、SSO 关联状态；既有账号访问窗口放入高级设置并继续执行。新账号编码自动生成且只读，默认不设账号到期日 |
| 配置摘要 | 用一句摘要和链接说明有效岗位与异常，不重复另一张可编辑岗位列表。账号停用前展示影响到的岗位、服务关系及授权 |

**停用账号的查找与恢复（2026-09-10 用户反馈）：** 停用不删除账号，Users 默认包含全部状态，可通过 Inactive 和姓名／编号查找。诊所／角色筛选对停用账号保留历史岗位关联，仍受管理员所属集团边界限制。状态变更后保留当前详情，并解除会隐藏该账号的相反状态筛选；无结果时提供清除筛选入口。重新启用恢复账号状态，不自动启用已停用岗位，也不恢复已终止的护理服务关系或临床授权；后两者需分别配置／重新批准。

**Provider 注册资料（2026-09-10 用户确认）：** 新建界面明确标为 Doctor registration number，并说明系统 User code 在建账号时自动生成、与执业注册号分开；复用已有 Doctor 身份时只读带出其注册号，旧缺号明确显示 Not recorded。 首次配置 Doctor 岗位并创建 Provider 时，必须填写非空执业注册号（最多 120 字符）；资料不完整时整次岗位创建不生效，不留下半成品医生身份。已有 Provider 跨诊所复用稳定身份与注册号，新增岗位不得覆盖注册号或自动重新启用停用身份。管理员通过用户基本资料 → Doctor identity → Configure identity 补录或更正，保留变更原因及版本校验。旧记录不自动生成或猜填注册号；缺号影响最终临床签署，不单独取消现有草稿保存资格。旧缺号身份仍可停用，重新启用前必须补齐；停用不删除原记录、不自动恢复历史授权。

#### 新建账号与配置岗位

新建账号分为三步：填写人员资料并确定唯一角色；配置同角色的工作单位；最后核对并保存。管理集团只有一个可选项时自动带入，多个可选项才由管理员选择。新建审计原因默认“New user initial configuration”，备注选填；给既有用户新增工作单位仍需原因。

进入 Work scope 前校验姓名／邮箱、真实管理集团及该集团内可分配的业务角色；进入 Review 前校验至少一个匹配工作单位、新医生执业注册号及日期顺序。角色与工作单位使用同一次集团引用数据，切换集团清除旧单位，失效角色不能沿用。Working units 区分加载中、加载失败可重试、无匹配角色单位和搜索无结果，保留人员输入；无合适单位时提示返回选择集团／角色或在 Organization 配置。仅建账号通过 Person 的 Review account only 显式进入复核，仍校验人员及集团，保存不创建 Provider 或岗位。本轮以原子 onboarding 实现完整创建，Users 与 Doctor directory 的 Add doctor 复用同一流程；既有用户复用其身份。重复提交同一请求返回完整原结果，任一步失败全部回滚。

**暂不配置岗位时：** 允许保存尚未配置岗位的账号，但必须先明确真实管理集团，并标为“未配置岗位／暂不能进入业务”。

#### 管理集团与跨集团任职

管理集团关系不授予临床或业务权限；Master 固定当前集团；Super Admin 只有一个可管理集团时自动带入，多个可选集团时明确选择。岗位主体只列当前管理员有权管理且账号已关联集团内的有效组织；跨集团任职需 Super Admin 先显式关联接收集团并填写原因，不能通过空组织或自由文本扩大候选范围。

共享账号全局资料由 Super Admin 维护，各集团 Master 只维护允许的本集团岗位。旧数据仅根据已有岗位和可核实建档来源回填集团，真正无来源的账号保持待关联，不猜测归属。

**页面提示：** 已关联的管理集团明确显示 Linked；Super Admin 的集团下拉保留已关联项并标为不可重复选择。没有可关联集团时显示明确状态，不展示空下拉；搜索无匹配和全部已关联分别解释。Master 及不具备关联资格的上下文只读展示，不提供失效的关联操作。选择集团及填写原因属于未保存变更，切换用户／工作单位配置／关闭侧栏时沿用放弃确认。

#### 用户资料字段与填写要求

以下字段要求于 2026-09-10 确认。

| 字段 | 必填／默认 | 填写与保存限制 |
|---|---|---|
| User code | 系统生成，只读 | 不由用户填写或随资料编辑更改 |
| Display name | 必填 | 去首尾空格，1–180 字符，不接收控制字符 |
| Email | 新建必填 | 有效邮箱格式、最多 180 字符；规范化后检查重复 |
| Management group | 新建必填 | 真实集团 ID；Master 自动固定；仅一个可管理集团自动带入，多集团时明确选择 |
| Account type | 新建默认 Staff，可选 External | 仅账号分类；存量 human／service 不自动转换；未修改分类时省略提交，保留原值；不扩大权限 |
| Employment type | 不在列表、新建或日常编辑中展示 | 存量值保留，不再默认 Permanent，不参与授权 |
| Department | 基本资料 → 更多资料中的行政部门（选填） | 集团内目录，可选所属工作单位；与工作任职独立、同集团验证、变更保留历史；旧自由文本明确标为未映射 |
| Specialty | 可选专业信息 | 共享专业目录，仅平台管理员维护目录；医生关联目录项，保留旧消费者兼容；不决定角色或数据范围 |
| Phone | 可选 | 最多 80 字符，保留国际号码／分机，禁止控制字符 |
| 资料变更原因 | 可选 | 最多 500 字符 |
| 工作单位、角色、原因 | 单位必选，角色继承 | 真实有效 ID、允许角色组合；新建用户默认初始配置原因，其余任职变更原因 1–500 字符 |
| 岗位起止日期 | 可选 | 空起始即立即、空截止即无到期；截止不得早于起始 |
| Provider 注册号 | 首次创建医生身份必填 | 1–120 字符；已有身份复用，最终签署另查当前有效性 |

前端与接口使用同一字段含义：日期只用 `YYYY-MM-DD`，时间戳携带时区；布尔值只能为 true／false；省略字段表示保留，显式 null 才清除允许为空的字段。新增和修改执行同等格式校验，不静默截断、吞掉拼错字段或把缺失值改成今天。错误定位到字段，保留输入并允许修正；旧资料中未修改的空值或退役选项不阻断无关资料更新。新建重试复用同一请求标识，不重复创建账号；搜索或列表迟到响应不得清空已打开的详情或服务范围编辑弹窗。


<a id="943-岗位与服务范围"></a>

行政部门只在基本资料的“更多资料”内选填，未配置显示“未填写”，不阻断账号创建和工作范围配置。它不从工作单位自动推断，也不删除旧资料。部门目录属于当前管理集团；可关联真实工作单位，但不会创建或改写 Membership。原有 Operating Unit 的 department 类型仍表示旧后台工作场景，不转换成新的资料部门。Specialty 是医生专业目录，不是组织层级。目录停用阻止新选择，保留现有引用、历史和显示；改名保留 ID。无来源的 SSO／导入账号显示未配置，需要管理员明确关联集团和角色，不能自动取得业务入口。

**基础资料下拉规则（2026-09-14 用户确认）：** 管理集团、工作单位／诊所、行政部门和医生专科必须选择权威目录条目并保存稳定 ID，不在用户配置中以自由文字创建同名机构。集团和工作单位由组织管理维护，部门及专科在“组织 → 部门及专科”维护；共享专科由平台管理员维护。选项必须按当前管理权限、集团及有效状态过滤，服务医生进一步限定当前诊所。名称变更不改变引用 ID；停用条目禁止新选，保留既有引用与历史显示。无可选资料时先维护基础资料；行政部门可留空，必需的集团／工作单位不能用手填名称绕过。旧文字资料保留为未映射，不按名称自动赋予组织关系或权限。姓名、注册号和备注等自然文本仍按各字段规则填写。


### 4.4 岗位与护士服务范围

一条配置对应一个主体，继承用户唯一角色（见[角色唯一性](#user-single-role)），不能逐行选择不同角色；Clinic、Back Office、WDL 分别使用真实主体。页面默认显示当前及待生效任职；已停用、已到期及旧角色记录折叠到“历史任职（N）”，不加载历史护士服务表单。仍有效的异角色记录明确警示角色冲突，不通过隐藏或自动改写解决。点击“添加工作单位”或某行“编辑”才展开表单。护士的日常配置在同一行／详情中完成：

| 字段 | 联动与含义 |
|---|---|
| 所属主体／工作单位 | 必选；新增仅列管理员可分配的有效主体。护士归属 Clinic 是本项临床服务授权的范围上限 |
| 角色 | 显示用户唯一角色；主体必须支持该角色，否则禁止分配。变更角色走明确的用户角色变更，不在添加岗位时覆盖；角色说明可查看但不重写共享模板 |
| 岗位有效期 | 默认显示“立即生效 · 长期有效”，点击“设置生效时间”才展开日期。空起始即立即、空截止即长期；已有期限编辑时自动展开并保留，不因折叠清除。仅填开始为该日起长期，仅填结束为立即至该日；最终受账号和主体状态限制 |
| 服务医生（护士专属） | 本诊所全部医生／指定医生。新增有效护士岗位沿用显式整诊所默认；选指定医生时支持一次多选本 Clinic 有效 Provider，不逐个重复添加表单 |
| 服务有效期 | 默认跟随岗位有效期，只有需要更短期限才展开设置；子范围不能超出上层期限 |
| 默认登录岗位 | 单工作单位自动确定，多单位可明确选择，未另选时为首个所选单位；只决定登录入口，不扩大权限 |
| 特殊职责 | 有对应权限且需要时显示管理／审批职责，复用组织端相同关系；不向普通护士展示无关配置 |

**角色及恢复限制（2026-09-14 用户确认）：** 工作单位继承用户唯一业务角色，候选角色及前后端保存均须一致。Doctor 只配置出诊诊所，复用本人 Provider；只有当前有效 Nurse 任职展示可操作的服务医生配置。旧角色任职只读保留，不可直接启用；角色变更使用独立流程。同单位重复新增拒绝并提示编辑既有任职，不能暗中覆盖日期或默认登录设置。已到期的 active 任职引导调整有效期；已停用且过期的任职引导重新配置，不允许仅切换 active 状态造成假恢复。停用但尚未过期且角色一致的记录可填写原因恢复，已终止的服务关系和临床授权不自动恢复。

操作步骤见[用户与工作单位操作手册](https://virtus-patient-emr-prd.vercel.app/user-organization-guide.html)，手册引用本节规则，不维护第二套权限定义。

从岗位配置服务医生时，Clinic 自动带入并以文本显示，不再重新选择 Source clinic。医生候选按该 Clinic 联动；增设 B 诊所服务必须先有 B 的有效归属。护士只有 A 归属时，即使管理员可以管理 A／B，也不能在 A 岗位直接保存 B 服务关系。

整诊所模式和指定医生模式互斥。整诊所模式后续纳入本诊所新有效 Provider 只增加服务关系，不产生该医生的临床授权。指定范围被清空、到期、撤销后显示“无有效服务医生”，不能回退整诊所。切换模式前展示新增／移除医生及受影响授权；后端按同一变更提交并留证。

界面可以提出未来生效的调整，但保存时不能立即结束今天仍有效的旧范围。预约调整应明确生效时点和转换结果；如果尚未具备定时切换能力，则该阶段只支持明确立即生效，不能接收未来日期却提前撤权。


<a id="944-权限概览"></a>

### 4.5 有效权限概览

概览是同一套服务端规则的只读解释，不是新的一套 Allow／Deny 配置。先选择具体主体／岗位，避免把多个岗位的动作并集误显示成当前诊所可用权限。

| 展示项 | 用户应能读懂的结果 |
|---|---|
| 功能 | 按患者、预约、问诊协作等业务分组，说明允许的动作；技术 permission code 放在详情中 |
| 主体及服务范围 | 显示该岗位的 Clinic、整诊所／指定 Provider、有效期限和限制原因 |
| 医生授权 | 显示医生、Clinic、护士、查看／编辑、实际记录范围、有效期、授权人及最近变更；可打开授权历史 |
| 其他特定权限 | 临床固定记录授权、患者资料接收批准、公共医疗信息角色读取权限、敏感字段独立查看权限分别说明，不互相替代 |
| 实际结果及原因 | 可查看／可编辑草稿／未获医生授权／主体失效／关联失效／已到期／记录状态不允许编辑等，错误加载不能显示为无权限或无数据 |

管理员看到授权元数据，不因此看到临床正文；默认不能代医生开启这项个人授权。既有被指定负责人的其他审批职责继续按原权限处理，也不能制造医生本人授权。医生和护士详情可从两个方向读取同一授权记录。由用户详情进入申请中心时带入人员／主体筛选，页面明确当前筛选且可清除。

新概览必须解决当前护士权限列表仍出现 pharmacy 动作而 App 不可用的差异，逐项核对前端入口与服务端有效动作，不将原始角色代码清单直接命名为最终可操作权限。此为实施核查项，尚未证明所有相关 API 存在越权。


<a id="37-master-与审批负责人"></a>

权限概览按具体工作任职及其集团当前生效策略解释，不能把跨集团权限并集作为某个诊所的实际权限。`clinical.write` 包含到诊、护理评估、候诊准备和付款安排等现有工作动作，不等同于临床签署或处方权。患者自填审核按当前 Clinic、patient.write、主档维护资格及患者确认结果逐项判断；正式接入与版本／审计契约见 [Frontoffice §3](https://virtus-patient-emr-prd.vercel.app/frontoffice.html#3-h5-自助填报与审核)，不能以扩大护士权限替代业务校验。患者、预约、问诊／临床文档、收费、CP 与 V-Lab 各模块保留自身对象范围、动作和状态检查；入口可见与操作获准分别验证。

### 4.6 Master、负责人及角色模板

**AC-07（用户确认）：** Master 在获授管理范围内维护权限并指定负责人；Master 身份本身不等于全部病历读取权或审批权。只有被指定为相应范围负责人时，才可以承担该范围的病历访问审批；同诊所与跨诊所审批都适用。原医生或指定负责人只批准自己有权处理的记录和动作，不得自批、给自己扩权或批准超出申请的目标。

护士 Consultation 的医生授权依据仍须明确保存，不能仅从 Master 管理操作推导已获医生批准。任何管理／访问审批均不替代负责医生对临床内容、处方、检查开单及最终签署的确认。负责关系失效后停止接受其新审批；既有授权还须继续满足受益人的服务关系、账号及其他生效条件。

Roles & Permissions 按有效业务角色目录展示；Cashier 是功能、不作为独立可分配角色，历史 Cashier 角色引用须保留来源并另行迁移，不能静默改绑账号。其余有效基础角色完整展示，不依赖是否已有集团模板历史；每项明确实际生效动作数量及来源（系统默认或集团配置）。角色目录和模板历史分别加载：历史读取失败时保留已验证的角色目录与动作，明确提示历史暂不可用，并禁用依赖版本的编辑／发布；角色目录本身失败则显示加载错误，不编造角色或权限。切换集团／身份时清除旧上下文结果，不将过期响应用于新集团。集团角色模板维护动作清单、草稿、变更影响预览及发布版本；只配置获授范围，不改变其他集团。模板不能解除医生签署资格、来源关系、隐私规则或 Closed 限制。当前支持编辑哪些角色必须明确展示。新增岗位不扩大既有临床授权；停用和升级不恢复已撤销账号、服务关系或管理者调整过的权限。


<a id="31-真实身份角色模拟与授权"></a>

### 4.7 登录、模拟与退出

**登录状态检查：** 登录页检查已有会话时，未登录响应表示继续展示登录入口，不弹出“unauthorized”错误。该响应仍不得建立会话或取得业务权限；实际服务器错误、网络失败以及其他接口的权限拒绝继续显式提示，保留既有日志和会话过期处理。 测试环境角色登录（2026-09-10 用户确认）不调用真实 SSO，沿用原壁纸和圆角角色按钮。选项来自后端配置的真实测试账号及有效岗位，选择后建立完整登录会话；Doctor 沿用该账号的 Provider 关联。登出后保持角色选择页，刷新不能进入虚拟 Super Admin；只有真实会话可自动返回桌面。角色入口及操作权限都按所选岗位计算。STG 可显式开启测试角色登录，UAT／生产不启用此入口。

**AC-01（2026-09-09 用户确认）：** 默认角色切换采用完整功能测试，选择目标真实员工在该诊所／主体的有效岗位；Doctor 同时绑定稳定 Provider。Assume 的数据和操作权限与该目标真实登录一致，不因模拟身份额外禁止患者维护、Reception、本人问诊、授权申请或管理。权限取目标岗位的当前模板、服务关系及已批准记录，不继承 Super Admin 的范围；管理员登录身份与目标员工身份分别保留。只读预览须显式选择并明确标识；仅角色模板预览没有真实受益人，不冒充个人临床授权。目标人员／任职失效时停止该模拟，不能自动转绑另一任职。 非患者个人文件的所有者、列表、上传去重、下载及删除资格同样按目标员工判断；实际管理员身份仍保留在访问审计中。退出模拟后恢复原人员的文件范围，不把模拟期间上传的文件归到管理员，也不迁移已有文件的所有者。患者文件仍独立按资料分类、来源和临床／隐私权限判断。

**退出模拟：** 退出本人有效角色模拟会话须验证真实登录、CSRF 和模拟会话归属；Doctor／Nurse 的目标角色动作上限不能阻止此退出动作。End 结束该模拟并恢复原有效上下文，不为目标角色增授管理或临床权限，既有退出安全审计保留。未修改身份的迟到请求只能续期，不能覆盖已开始或已结束的模拟会话，也不能复活已登出的会话。本人明确退出后，仍持有该旧模拟快照的请求不再具备业务权限，也不能清空刚恢复的有效岗位或覆盖随后开始的新模拟。会话或任职已经失效时继续沿用现有 401／409 处理，要求重新登录或选择有效上下文；本次不扩大失效会话的可操作范围。 等待选择岗位时发出的旧请求不得清除随后成功选择的新岗位，也不能执行业务动作；后续请求使用新有效上下文，已到期或撤销岗位仍按原规则失效。

旧 Visit coverage 仅作为医生读取指定记录的兼容依据，继续检查医生身份、来源和有效期；它不授予草稿编辑、开单或签署权限。签署另行检查医生资格、具体签署动作及记录状态，不因能读取记录而放行。本轮固定记录的申请、审批及撤销按 §3–5 实施，本地验证边界见文末测试入口。模拟本身不会生成护理服务关系或医生授权；完整模拟中的申请、批准、撤销、保存和签署仍通过相同真实业务流程，固定记录目标及状态检查不变。业务责任字段引用所选真实人员，审计同时保留实际管理员、目标人员、登录和模拟会话；不把护士草稿保存记为医生签署。急诊例外仍待确认，未确认前不提供自动越权入口。

<a id="clinical-grants"></a>


<a id="43-申请固定记录授权与交接"></a>

## 5. 临床记录授权、续期与撤销

医生可以授权护士协作处理自己的问诊记录，也可以按申请开放指定记录给其他医生。本节说明授权前需要具备的关系、如何选择记录范围，以及授权何时生效或失效。

申请人从可识别的患者和既有就诊列表中选择记录，无需手工输入记录 ID。申请未获批准并生效前，页面不加载受限正文。

### 5.1 护士授权的匹配键与范围上限

**护士获得临床授权前，需要先在记录所属诊所任职，并与负责医生建立服务关系。** 例如，护士在 A 诊所服务医生甲，医生甲给她的授权只能覆盖相应的 A 诊所记录。即使医生甲也在 B 诊所出诊，也不能直接把 B 诊所记录加入这份授权。

如需在 B 诊所协作，管理员应先为护士建立 B 诊所的有效岗位，再关联该诊所的医生。医生的授权页面不能代替管理员增加护士所属诊所。

系统检查以下条件，全部满足后才开放记录（AC-09）：

1. 护士账号、角色操作权限和来源诊所岗位有效。
2. 护士在该诊所与负责医生的服务关系有效。
3. 医生批准的范围包含本次请求的记录和操作。
4. 授权尚在有效期内，记录状态也允许该操作。

新护士岗位没有指定医生时，系统应明确保存“本诊所全部医生”的默认服务范围。以后清空指定范围、撤销关系或关系到期，则显示“无有效服务医生”，不能恢复为全部医生。整诊所服务关系本身不开放完整病历。

账号、单位、岗位、医生身份或服务关系失效后，相应临床授权停止提供访问。历史记录保留，恢复关系不会自动恢复已撤销或结束的授权。

### 5.2 从申请到生效

```mermaid
flowchart LR
  S[选择既有记录、动作、用途、期限] --> Q[按原医生拆分申请]
  Q --> A{原医生或指定负责人复核}
  A -->|拒绝| R[保存原因，不产生访问权]
  A -->|全部或子集批准| G[保存明确授权集合]
  G --> T{开始时间与全部关系有效?}
  T -->|未到开始时间| W[待生效]
  T -->|全部满足| E[生效中]
  E --> X[到期、撤销、账号或关系失效]
```

#### 申请和批准

申请人选择记录、操作、用途和期限后，由原医生或有资格的指定负责人处理。记录来自不同医生时，系统分别建立申请，不要求无关医生共同签批。

审批人可以批准全部或部分记录，也可以拒绝。部分批准只开放列明的记录，其余部分需要另行申请。医生可以主动为关联护士建立申请并亲自批准，但任何人都不能批准自己的申请，或批准超出本人职责和申请范围的内容。护士临床访问的医生授权依据必须真实保存，管理员不能代填医生身份。

申请状态和授权状态分别展示。申请可以是待审批、已批准、部分批准、已拒绝或已取消；获批授权则可能尚未开始、正在生效、已到期、被撤销或因关系失效而停止。Access Center 提供“我的申请”“待我审批”“有效授权”和历史记录，逐条显示结果。

#### 选择记录范围

授权时需要分别选择“覆盖哪些记录”和“有效多久”。没有到期日，不表示未来新增记录也自动纳入授权。医生可以选择以下两种模式（2026-09-10 确认）：

| 模式 | 适用范围 | 新增就诊如何处理 |
|---|---|---|
| 固定记录 | 批准时明确选择的既有就诊 | 不自动加入，仍需另行授权 |
| 持续覆盖 | 指定医生在指定诊所内，符合条件的既有及未来就诊 | 每次访问重新检查范围、服务关系、角色权限、有效期及记录状态 |

保存持续授权前，页面应明确显示医生、诊所、当前可识别范围、允许操作和起止时间，并说明同时包含既有及未来记录。系统按规则判断新记录是否纳入，不复制病历。

查看和草稿编辑各自保存范围、模式、期限及批准人。编辑范围不能超过有效查看范围，因此不能只授予几条固定记录的查看权，却授予更广的持续编辑权。编辑仍限于已允许协作的草稿；不能创建护士无权创建的医生模板、修改正式处方或代签。医生尚未初始化可编辑内容时，授权不会自动建立记录。

#### 生效、续期和范围变更

到了开始时间，而且各项关系仍有效，授权才开始生效。来源就诊后来变更负责医生或诊所时，系统按新归属判断后续访问。账号、岗位、医生或服务关系失效时，持续授权也停止，恢复关系不自动恢复已终止的授权。

旧固定授权继续按原范围使用。医生要改成持续覆盖，应明确保存新版本，系统保留旧依据。续期只延长时间，不改变覆盖模式、记录集合、医生、诊所、服务关系或审批依据；原关系已结束的，应重新申请。

护士切换到另一个有效诊所岗位，不会改变已有固定授权的受益人和原绑定关系。系统仍重查原关系，日常日历则按当前岗位显示。每次访问记录实际操作者、记录、授权编号和版本、覆盖模式，便于追溯。

**实施状态：** 固定记录授权已有基础；持续覆盖仍待开发和验证。未支持的模式应明确显示尚不可用，不把批量选择记录或设置无到期日显示为持续授权成功。

<a id="945-医生端护士授权"></a>

### 5.3 医生端“我的护士授权”

医生从个人设置（Personal Settings）进入“护士授权”，无需先打开患者或问诊页面。页面默认显示当前诊所，也可以选择本人其他有效诊所，并始终显示正在管理哪家诊所的授权。

这里选择诊所，只改变授权管理范围，不切换正在处理的患者或诊疗工作。按照 2026-09-10 确认的安排，授权统一在 Settings 维护，不向 Consultation 增加额外操作。

| 主表列 | 内容 |
|---|---|
| 护士 | 姓名及可区分人员的标识，只列该 Clinic 下有效关联到当前医生 Provider 的护士 |
| Clinic | 当前授权来源诊所；同一护士跨两诊所时分别设置、分别展示 |
| 查看 | 是否获准查看该医生在该 Clinic 下、已批准记录范围内的受限临床资料 |
| 编辑 | 是否获准编辑同一范围内允许协作的草稿；与查看独立记录，以查看为前提 |
| 授权期限 | 无固定截止／指定期限；显示实际受上层约束的有效期 |
| 状态／操作 | 未授权、生效中、待生效、到期、撤销、关系失效；设置授权、撤销、查看历史 |

**先选关系，再设操作。** 表单固定护士、诊所和医生，不能在授权时换成无关联人员或增加所属诊所。查看和编辑两个选项作用于已经选择的临床记录，不在初始界面增加大量模块开关。

选择编辑时，系统同时选择查看并提示用户。在这个统一设置中关闭查看，会在保存时一并结束依赖它的编辑授权；以后重新开启查看，不会恢复已结束的编辑。

调整选项时先保留为页面草稿，点击“保存授权”后才生效。保存前列出记录范围、期限和变更结果；取消则保留原授权。

授权记录覆盖边界必须明确呈现。固定模式选择可识别的既有 Visit，不要求手输 ID；持续模式明确显示所选医生、Clinic、既有及未来覆盖、动作和有效期，保存前确认影响。两种模式按 §5.2 实施；旧授权默认仍是固定记录，持续功能未开发时不能提供假成功。

护士可以对医生 A 是仅查看，对医生 B 是查看＋编辑；医生 A 在 Clinic A 的授权不包含本人 Clinic B 的记录。医生授权只覆盖自己负责的受限临床资料，不扩展到同患者他医或其他 Clinic 的完整记录。

**查看范围**包括获批记录中的完整问诊正文、诊断详情、检查结果、正式临床文档、处方和历史附件。公共摘要和本次附件另按第 3 节处理。

**编辑范围**限于允许协作的病历或问诊草稿。处方草稿协作仍是待细化、待实施的方案，现有 `clinical.draft.write` 不代表护士已经可以选药或改药。最终开单、签署、正式修订及结算后的更正，仍由医生按原流程处理；系统保留护士实际编辑的记录。


<a id="946-权限决策与异常处理"></a>

### 5.4 查看与编辑匹配示例

以下为说明规则的合成人员和记录，不代表已执行测试。假设医生甲在 Clinic A／B 有有效岗位，医生乙在 A；护士小林只属于 A，并在 A 关联甲和乙。小林获甲的 V1 查看授权、乙的 V2 查看＋草稿编辑授权。患者 P 的 V1 属 A／甲、V2 属 A／乙、V3 属 B／甲。

| 小林请求 | 查看 | 编辑 | 为什么 |
|---|---|---|---|
| P 的同集团公共诊断／药名摘要 | 按独立公共医疗信息角色读取权限允许 | 不从读取权推导 | 公共摘要不走原医生授权 |
| P 的患者基础主档 | 同集团及角色查询权限即可；敏感字段先隐藏 | 另需 A 的患者关联／接收资格和维护动作，确认同样检查 | 集团可查不代表可改或能读取问诊正文 |
| V1 的完整 Note | 可，其他条件有效时 | 不可 | 甲只授予查看 |
| V2 允许协作的 Note 草稿 | 可 | 角色有编辑动作且状态允许时可 | A 归属、A＋乙服务关系、V2 动作全部匹配 |
| V2 已签署正文 | 可 | 不可直接修改 | 编辑授权不能解除签署状态 |
| V3 的完整 Note | 不可 | 不可 | 小林无 B 归属；甲在 A 的授权不覆盖 B |
| 甲在 A 新增 V4 的完整 Note | 原固定授权不自动允许 | 原固定授权不自动允许 | 若甲另行明确授予仍有效的 A＋甲持续查看／草稿编辑，则分别按实际动作和状态判定；不能套用固定 V1 授权 |
| 任一受限记录的最终签署 | 不适用 | 护士不可签署 | 签署是独立医生资格与动作 |
| P 的独立隐私字段 | 默认隐藏；申请查看、提示审计并依独立隐私授权另判 | 依隐私维护动作另判 | 不由上述甲／乙病历授权决定 |

若小林后来加入 B，但只关联 A 的甲，V3 仍不开放；建立 B＋甲服务关系后还须取得 V3 对应医生授权。患者同一、医生同一、护士同一，均不能抹去来源 Clinic 和记录集合的区别。

### 5.5 撤销、人员调动及正式交接

医生设置的授权和旧固定记录授权，按同一护士、诊所和医生统一展示。撤销查看权后，依赖该范围的编辑立即不可用，历史操作记录仍保留。其他诊所、医生和公共资料的独立权限不受连带影响。

两种撤销方式需要分别处理：

- 在 Settings 中关闭查看并保存，按 §5.3 同时结束依赖的编辑授权。以后开启查看，不自动恢复已结束的编辑。
- 单独撤销一条查看授权时，独立编辑授权保留记录，但暂不可用。只有重新取得相应查看权，而且编辑授权本身仍有效，才可以继续编辑；已结束或撤销的编辑权不能恢复。

旧授权记录或其他入口不能绕过撤权。修改岗位、服务关系或有效期前，应显示受影响的授权；保存和后续访问再次校验。授权期限不能超过所属岗位或服务关系的期限，不一致时提示并拒绝保存。

普通入职：建账号 → 添加 Clinic 的 Nurse 岗位 → 配置整诊所／指定医生 → 查看结果 → 医生按需授权。人员调动：结束旧主体／关联并确认影响 → 建立新主体／关联 → 新来源医生按需授权。旧作者、历史记录及合法提交不迁移或重写。

访问授权只开放批准资料；临时代诊需明确临床职责并由有资格医生执行；正式交接保留原作者／签署者与版本。正式交接是否覆盖持续照护及未来预约仍待确认，不能自动开放接收方全部后续记录。

失败应明确说明“护士未归属该 Clinic”“请先关联该医生”“未获得编辑授权”或“记录已签署”等实际原因；只披露请求者有权知道的对象信息。撤权与编辑并发按“Consent、撤权与版本控制”处理。


<a id="947-操作流程与视觉约定"></a>

### 5.6 授权界面的显示与操作

用户详情、医生授权和申请中心读取同源结果；角色、主体、服务关系、授权状态分别显示。用户／多人关系列表支持按姓名、用户编号、邮箱搜索，在分页前匹配有效与历史结果。进入申请页可带筛选，必须明确且可清除。

主列表用表格，表单按需展开；固定标题与操作区，中间正文滚动，窄屏仍可完成全部输入。长岗位名、日期和记录清单不能撑出弹窗；蒙版不能关闭未保存表单，切换用户／Clinic 保护未保存内容。查看／编辑变更只有保存后才生效。表单、搜索多选、日期时间、日历、按钮统一复用 Element Plus 与项目封装，详细组件表只维护于[页面设计指南](https://virtus-patient-emr-prd.vercel.app/desktop-ui-design-system.html)。


<a id="app-configuration"></a>


<a id="9-app-目录与配置层级2026-09-09-用户确认"></a>

## 6. 桌面入口与配置管理


<a id="91-类目子-app-与功能"></a>

### 6.1 App 目录

桌面、Start 菜单、搜索和移动端共享以下目录；角色只过滤可见 App／功能，不改变它的所属类目。个人设置作为额外全局工具入口。下表列出现有代码承接，不把入口整合视作每项业务均已完成或验收。

| 类目 | 子 App | 对应功能与现状边界 |
|---|---|---|
| Clinical | Appointment Calendar | 预约日历、医生／资源排程、创建与改期、预约准备；Front Office 不再另设类目 |
| Clinical | Registration | 到诊、候诊及护理操作、队列和就诊状态；权限与状态仍逐项校验 |
| Clinical | Patient & eMR | 患者主档、个人持有保险／计划资料、历史就诊及获授权记录；不维护共享计划目录 |
| Clinical | Consultation | 医生队列、临床记录、处方、Service 开单、完成／签署及个人工作台布局 |
| Clinical | Clinical Documents | 文档创建／编辑／输出、医生个人模板和默认文档集合 |
| Clinical | Tasks & Follow-up | 既有任务、处理状态和诊后跟进入口；完整跨模块闭环仍按 Cashier PRD 分项验收 |
| Clinical | ICD Mapping | 诊断编码检索及既有映射／辅助能力 |
| Clinical | Clinical AI Copilot | 已接入的临床 AI 工具；模型结果仍由医生确认 |
| Pharmacy | Drug Dispensing | 审方、预留、Cashier 结算门禁、备药、复核及发药 |
| Pharmacy | eMMS | 用药相关审查与提示的现有工作台；从 Administration 移入 Pharmacy，不增加临床阻断承诺 |
| Pharmacy | Central Pharmacy | 既有 CP 药品、价格、库存／预留、采购订单及相关查询；WDL Staff／PIC 权限及未完成的库存能力保持各自边界 |
| Business Operations | Cashier | Checkout Queue、Billing History、Day-end Revenue Report；Invoice／Receipt 模板从标题区右上角齿轮进入，作为 Cashier 内的唯一日常入口 |
| Business Operations | Catalogue | Service Items、Lab & Imaging、Products、Consultation Pricing、Change History & Controls，以及获支持的导入／发布。只管理共享项目、价格与成本；新定价／成本模型的未实现项仍以 Catalogue PRD 为准 |
| Business Operations | Insurance & Benefit Programmes | 保险、企业会员及员工计划目录、卡面／说明、简单 Policy；企业／员工计划引用同类型既有 Benefit Contract，不是 Coupon，也不新造复杂合同后台 |
| Business Operations | Packages & Coupons | Service Packages 保留 Setup、Sale、Wallet、Consumption、Liability 及已有 Lab 协作；Coupons 维护 Campaign、适用对象／折扣、有效期、限制、叠加、草稿及发布。Coupon 核销、套餐统一 Cashier 结账仍按现有实现边界另验 |
| Administration | Organization & Access | Users（基本资料、岗位与服务范围、权限概览）、Organization、Role Templates、Requests & Approvals；旧入口定向至同源配置 |
| Administration | Audit & Review | Access & Permission Audit、Operation Logs、Account & Sign-in History、Alerts & Reviews；只显示当前实际获授权的页签 |
| Administration | System Settings | Rooms & Equipment、Pharmacy Configuration；仅具备共享配置 capability 的管理员／运营角色可见。Cashier Documents 的日常入口唯一放在 Cashier 齿轮，复用同一组件、API 与底表 |
| 全局工具 | Personal Settings | Display & Appearance、Desktop Layouts；有相应能力者可进入 Consultation Layout、Letterhead & Writing、Nurse authorizations、Document Templates。从 Start 全局操作与移动首页进入，不放业务类目或 Administration 的 App 网格 |

V-Lab 的独立执行工作台仍为已确认待接入需求，未接入时不恢复说明性 App。未实现的通用 Workflow、Security、Numbering、Integration 等配置不新增假保存页，后续实际接入时归 System Settings 或各自业务 App。

**账号管理收敛（2026-09-09 用户反馈）：** User Accounts 是唯一以人为中心的账号维护入口，详情内包含 Profile & Access Window、Roles & Subjects、Effective Permissions；基本资料、所属主体、唯一用户角色、任职生效／失效日期与账号访问窗口在同一用户上下文管理；Roles & Subjects 不表示允许一个用户拥有多个角色，目标规则以[角色唯一性](#user-single-role)为准。新建账号默认 Staff，允许显式选择 External；新结构化部门、专科及历史资料的保存边界统一见 §4.3，不再提供并行的自由文本编辑。只修改资料不得重置任职，单独修改访问窗口不得清空本次未修改的既有资料。Staff Directory、Role Assignments、Temporary Access 和 Effective Permissions 不再作为重复的平级目录；旧链接进入该用户维护入口及对应详情。Roles & Permissions 单独维护共享角色模板。临床记录的特殊访问通过 Requests & Grants 进入既定申请／审批／撤销流程，不能由账号编辑直接越权。Effective Permissions 是有效结果的只读解释；通用的单用户功能权限 Allow／Deny 例外尚未建立独立模型，本轮不将该查看页冒充例外编辑器。 2026-09-10 用户确认：新增账号的 User code 由服务器生成且后续只读，不接受客户端自定义编号。Department、Specialty 按 §4.3 使用各自目录和关联模型，保留旧值兼容，不将资料字段当作岗位授权。新增用户默认无账号到期日；日常期限配置位于岗位及具体数据授权，账号仍可停用。旧账号已设置的访问窗口保留并继续生效，不能因界面收敛恢复已失效账号。


<a id="92-全局管控个人偏好与页面配置"></a>

### 6.2 共享配置与个人偏好

“集中入口”描述管理归属；“生效范围”由真实账户、集团／单位及业务对象决定，不表示每项都是全集团配置。

| 配置类型 | 唯一维护归属 | 生效范围／存储 | 页面级操作 |
|---|---|---|---|
| 组织、实体、账户、任职、角色模板及授权规则 | Organization & Access | 服务端当前集团及获授权单位；服务关系、记录授权有自己的范围和有效期 | 对象页面显示有效结果，申请／授权抽屉可作为上下文快捷入口，不另存权限副本 |
| 房间／设备；药品可见性、诊所显示名与默认标签等 | System Settings | 服务端当前 Clinic 共享资源或覆盖项；仍要求相应读取及配置权限 | 预约选择资源、处方／药房读取有效配置；不从页面筛选反写共享规则 |
| Invoice／Receipt 模板 | Cashier 齿轮（唯一日常入口） | `billing.documents.read/manage` 分离控制读取、打印与维护 | 复用相同编辑组件及权威底表，修改影响后续输出，不改历史账单；System Settings 不再提供重复卡片 |
| 服务、检查、非药品及价格／成本 | Catalogue；CP 药品／采购价格仍归 CP | 服务端本域主数据与版本；具体 Clinic／Doctor 例外见各业务规范 | 本次交易数量、获授权价格调整及临床选择属于本次对象，不覆盖主档 |
| 保险／企业／员工计划；套餐与优惠活动 | 各独立业务 App | 服务端共享计划或活动定义；患者 Wallet／持卡实例分别保存 | Patient 持有资料、Visit 付款安排、Cashier 责任／核销结果是各自业务记录 |
| 主题、壁纸、动作展示、信头和默认写作块 | Personal Settings | 现有浏览器本地偏好；不是跨设备同步账号配置，勿写入患者正文 | 页面可用快捷设置调用同一偏好；切换浏览器不保证迁移 |
| 桌面窗口布局、问诊面板顺序／宽度／密度 | Personal Settings | 现有服务端账户＋集团＋工作单位／诊所布局；本地缓存与同步失败状态沿用原机制 | 桌面布局面板及 Consultation 布局齿轮为同一编辑入口；未打开患者也能编辑问诊布局 |
| 医生对关联护士的临床授权 | Personal Settings → Nurse authorizations | 服务端固定记录权限；真实医生本人、同 Clinic／Provider 有效服务关系、查看／编辑分开且受护士主体上限约束 | 管理员在用户权限概览读取同一授权元数据；不增加 Consultation 操作 |
| 医生个人文档模板和默认文档集合 | Personal Settings → Document Templates | 现有服务端医生模板／偏好；真实医生或服务端确认且已选目标 Provider 的 Doctor 功能测试会话，仍须实际模板动作权限 | Clinical Documents 编辑器复用同一模板，当前文档内容／本次打开页签不直接改变默认集合 |
| 搜索、日期、筛选、当前页签、排序、行选择与临时展开 | 当前业务页面 | 页面状态；已有个人视图持久化按原规则，不新增全局配置 | 立即影响当前视图，不更改业务规则、权限或其他用户设置 |

Master 不因管理身份获得 Cashier／诊所配置或病历权限；WDL 仍仅显示自身业务 App 及个人设置。管理入口按具体会话模式与服务端能力过滤；完整真实目标模拟不继承原管理员范围，审计读取继续执行真实非模拟身份要求。App 内所有写动作继续服务端独立校验。


<a id="93-旧入口与目录管理"></a>

### 6.3 启动、旧入口及权限变化

共享 `appDirectory.mjs` 维护类目、顺序及归属，`virtusOsApps.js` 维护稳定 App ID、组件与角色范围，`managementNavigation.mjs` 维护管理子页所需能力。增加入口时必须同时具备实际组件、归属及入口权限；各客户端不得独立复制类目。旧 `settings` 管理子页转到 Organization & Access／Audit & Review／System Settings；旧 Catalogue 的 packages／coupons／contracts 转到对应独立 App；旧 `admin-units`／`admin-audit-trail` 分别归组织／审计。转换后按目标 App／页签重新授权，保留上下文但不恢复无权限组件。已撤出的通用占位配置最多回实际 System Settings 首页，不冒充完成的配置项。

用户要求直接清理重复与无用入口，取代 2026-08-27 的“所有 Shell 保持可见”策略。一个业务目的保留一个实际工作台入口；专用组件只表示已有基础，不等于完整实现或验收。真实会话的桌面、任务栏快捷入口、开始菜单／搜索、移动目录、直接链接和保存布局使用同一授权 App 目录：当前工作场景及角色允许该 App，并具备该 App 入口所需的有效权限，才显示且允许打开。无入口读取权限时隐藏图标，不先显示再等用户点击后报无权限；新 App 未配置入口规则时默认不显示。App 内具体写动作和业务对象访问继续由服务器分别校验，显示入口不自动授予写入或跨患者／单位访问。

**队列角标的后台轮询（本地验证通过）：** 只在真实会话及当前业务任职已就绪、具备队列所需读取权限时运行；Master、Super Admin、未选岗位、会话切换期间及合成静态预览不自动请求该业务队列。切换身份／诊所后取消旧请求并清空旧角标，迟到响应不得恢复上一身份的数据；同一身份不重叠发出轮询。服务端拒绝当前身份后停止该身份的重复请求，待有效上下文刷新后重新判断。此限制只约束业务队列角标，不关闭系统健康检查，也不替代服务器对统计范围与临床权限的校验。

**2026-09-08 用户确认：** Doctor 不应看到无权进入的 Central Pharmacy。角色模拟及 unrestricted functional test 也按所选岗位筛选 App，不将“功能测试”变成全 App 目录或把后台组件冒充 Super Admin。已保存布局、旧 CP 别名、缓存 App 对象及手机本地角色选择均不能恢复无权入口；角色／权限变化后撤下图标及不再授权的窗口，保留仍获授权窗口。未取得真实会话或未选角色时不以本地存储的 Super Admin 兜底。

只有明确的合成开发预览可展示全部已实现 App；预览不是账号授权证据。用户配置、角色模板、授权及审计已有实现基础，实际覆盖以对应记录为准，正式业务 UAT 尚未完成。Organization & Access、Audit & Review 与 System Settings 的子入口都按当前有效能力过滤；Personal Settings 是全局个人入口。 2026-09-10 用户确认：Clinical 默认以 Patient & eMR 为首个 App，其后为 Appointment Calendar 和 Reception；排序不改变角色可见性或访问权限。

| 原入口 | 当前处理 | 功能边界与承接 |
|---|---|---|
| Inventory（stock） | 移除独立占位入口 | 原页面只有需求列表，无库存动作 |
| Inventory（operations-inventory） | 合入 Central Pharmacy | 原查询仅为 CP 同步药品和库存字段，与 CP 工作台同源，不能称诊所库存 |
| CP Warehouse、Pharmacy (WDL) | 统一为 Central Pharmacy | 原本使用同一个 CPWarehouseWorkspace；保留现有采购、Stock catalogue、价格、预留和相关查询 |
| WDL 的 13 个专属入口 | 不再各占一个 App | Inventory、Stock-Take、Stock-In、Stock-Out、Client Orders、Supplier PO、PO Approval、Clients、Suppliers、Price Rules、Reporting、Product Master、Location Setup 原来全是计划壳；两个 WDL 角色现在进入实际 Central Pharmacy。完整三模块仍按 CP 设计稿后续实施 |
| Pharmacy Drug Order | 移除重复壳 | 开处方仍在 Consultation，审方配药发药仍在 Drug Dispensing；旧无患者上下文入口不自动发起开药 |
| Lab Service Order、Imaging Service Order | 暂移出日常目录 | 当前独立 App 均无执行组件。Consultation Service 开单不变，V-Lab 独立执行工作台需求继续，待真实接入后加入目录 |
| AI Assistant | 移除通用计划壳 | 保留 Clinical AI Copilot、ICD Mapping、eMMS 与业务内 AI 工具 |
| Connect / eHealth、Apps Marketplace | 移出未实现入口 | 集成和 Marketplace 不因图标存在变成可用功能 |
| Insights、Report、Finance、Announcement、Audit Trail、List of Units 的独立规划入口 | 移出日常目录 | 报表仅有局部只读试验，其余为规划；本轮组织管理与审计由实际 Organization & Access、Audit & Review 承接；原纯规划壳不恢复。后台审计和组织／权限服务不删除 |

旧 CP／库存 App ID 统一为 `central-pharmacy-warehouse`，保存布局按 canonical ID 去重，并继续检查目标角色是否拥有入口。被撤出的无替代壳不恢复成窗口，移动旧路径回目录。原需求仍可由仓库和 PRD 追溯，不能从 More 或搜索重新出现。

CP 操作根据服务器会话的 `cp.warehouse.read`、`cp.po.read/create/submit/approve/send` 判断，不依据图标或角色名称授权。现有代码中 Staff 可创建／提交，PIC 可审批／发送，PIC 不继承 Staff 写权限；目标采购的 PIC → Finance 两级审批及三人分离以 CP 功能方案为准，不能把旧动作映射当作新流程已完成。Restricted support 禁止写操作；无 PO read 不发请求，失败明确报错，不伪装为空单。公开静态预览没有真实 CP 会话时显示访问不可用，不注入模拟库存或自动取得权限。

此前桌面收敛只完成其记录中的入口及权限呈现；本轮权限改造也不代表独立 CP 原型、跨地点库存流水、诊所库存或业务 UAT 已完成。


<a id="35-cashierpharmacy-桌面边界2026-09-07"></a>

### 6.4 收费与药房入口分工

Cashier 展示本次药房进度及阻断原因，供关联护士判断开票／结算条件；不提供启动 Drug Dispensing 的跨岗位入口。药房人员从自己的获授权工作台完成审核、标签、备药和最终交付，护士在 Cashier 的显式 Return to Consultation 仍是独立就诊回退动作。

| 当前角色／入口情况 | 本轮桌面行为 |
|---|---|
| Nurse／Reception | App 目录及分组搜索不显示 Drug Dispensing；旧保存布局不恢复该 App，按 App ID 或缓存 App 对象发起的启动同样拒绝 |
| 药房窗口已打开后切为 Nurse／Reception | 移除不再允许的药房窗口，修正当前活动窗口；仅保留当前角色仍获授权的窗口；Reception 不保留 Cashier 或附件管理窗口，Nurse 仍按本诊所服务关系判断，不因恢复旧角色而自动重开药房 |
| Pharmacy 及其他既有获授权角色 | 保留既有 Drug Dispensing 入口及角色范围，不把本轮收敛误做成全局移除药房 App |

启动及布局恢复都以当前角色的有效 App 目录重新核对，缓存中的旧组件、旧角色或显示属性不成为授权依据。通用 App 预览的可见性不代表 Nurse／Reception 的真实目录获得权限。

**实现边界：** 本轮只调整前端 App 呈现、启动与窗口恢复，未迁移后端历史 `pharmacy.dispense` 授权或角色种子数据。不能把前端不可打开表述为这些角色的药房 API 已统一禁止，也不扩张真实药房或其他角色的后台权限。真实数据库／浏览器交接使用分别登录的 Nurse、隔离数据库内合成 Pharmacy 操作员及另一位实际 Pharmacy Checker，避免以一个护士会话冒充跨岗位验证。

目录、缓存启动、角色切换清理、医生筛选及跨角色交接已在精确提交 `a8e8b802d3738f1e6ce025af9b3a274a2814ab94` 完成隔离回归：[CI 34091809502](https://github.com/virtus-medical-internal-private/ai-clip-cms/actions/runs/34091809502) 的后端、前端、浏览器与清理检查全部通过。本条不代表生产权限迁移；真实后端部署与业务 UAT 仍未完成。

### 6.5 桌面恢复与共享配置对象

**桌面启动恢复：** 初次读取已保存布局期间，用户新打开、关闭、聚焦或调整过的窗口优先于旧布局；迟到的恢复结果不得关闭或替换这些窗口及其输入。会话与初始布局处理完毕后，桌面进入 Ready，随后继续保存当前布局。此行为已有代码与独立浏览器回归场景，运行证据须以对应 CI 结果为准。

**返回患者目录：** 从问诊队列打开 Patient & eMR 后，返回搜索须同时清除当前患者和窗口保存的来源记录上下文；恢复窗口或重新打开目录不得再次选中旧患者。返回后迟到的患者资料响应不得重新打开该记录。

| 编号 | 配置域 | 输入／维护动作 | 对业务的影响及边界 |
|---|---|---|---|
| AD-01 | Organization／Operating Unit | Code、Name、Type、Parent、Status 及获批准组织关系 | 决定当前诊所与数据范围；组织修改不迁移／删除历史就诊 |
| AD-02 | Users／Membership／服务关系 | 真实用户、账号／SSO 身份、状态、诊所、角色、有效关系及护士服务范围 | 同一医生可对应多诊所；护士关系明确到诊所及医生范围。配置关系与医生批准分开；停用不删除作者历史 |
| AD-03 | Roles／Permissions | 角色动作、数据类别、范围、策略版本与有效权限 | 前台预约及基础资料维护、护士护理及 Cashier、医生临床、药房执行分责；模板发布可预览影响，不能从页面可见推断写入许可；保护最后一名管理员等现有控制 |
| AD-04 | Service Resources | 诊所、资源类型、能力、容量、开放时间、Block-out 与状态 | 预约引用稳定资源；房间／设备不创建共享医生登录；完整实现见资源缺口 |
| AD-05 | Drug／Catalogue／Pricing | 复用各权威主档 | 不在 Settings 再维护一套卡种、药品、价格或规则 |
| AD-06 | Templates／Letterhead | 临床 Note、Document、Label、Receipt 模板及适用版式 | 修改模板不改历史文档；正式模板审批／签署规则依业务类型确认 |
| AD-07 | Workflow／Security／Numbering | 允许状态、操作角色、原因要求、编号、期限和规则版本 | 配置不能让 Closed 重开；Nightly close window、跨诊所授权期限和频次字典通过 System Settings 统一维护，并保留版本与审计 |

配置归属及影响范围以 §6.2 为准：Organization & Access 维护主体及授权，System Settings 维护跨页面共享配置，Personal Settings 汇总个人偏好，业务主数据在所属 App 维护。个人布局／密度只保存非临床参数。Provider、员工 User、Service Resource、Room／Equipment 分开；同名医生不能成为身份关联依据。

<a id="audit-review"></a>


<a id="5-audit--review"></a>

## 7. 审计查询与异常复核

**功能目的：** 让获授权人员知道谁以什么身份访问或修改了什么，并处理需要解释的异常。访问审计、操作日志、账号历史和异常复核各有自己的动作及数据范围，均不授予临床正文权限。

**操作顺序：** 查询事件 → 查看来源和授权依据 → 必要时认领异常 → 记录说明及结论 → 关闭；原事件不可由复核改写，系统不把异常标记直接认定为违规。


<a id="51-事件查询"></a>

### 7.1 事件查询

**AU-01：** 按时间、当前授权范围内的 Clinic、Actor、动作、对象、结果或来源筛选；详情包含真实操作者、有效身份／角色、当前工作场景、来源 Clinic、患者／Encounter／业务对象、时间、原因、前后值／版本及结果。权限相关访问同时保留 session／request、策略版本、授权与服务关系依据；跨角色和跨诊所会话仍能归并到同一真实人员。敏感字段按查看权限脱敏，审计不复制完整临床正文。

需要覆盖登录／权限变更、人员服务范围、负责人指定、申请／审批／续期／撤销、身份搜索、病历与附件实际读取、拒绝尝试、下载／导出、患者更正、Consent、问诊签署与修订、处方／Order、文档输出、价格／折扣、Invoice／Payment／退款、主数据发布及适用 AI 调用。成功读取、被拒绝、搜索和输出分开计量；当前 Chit activity 只显示本次就诊事件，不代替系统级审计。

审计开启时，访问元数据独立持久保存实际操作者与有效身份、来源／当前诊所、动作／结果、患者与资源引用及授权依据。Access Audit 工作台可按实际人员、结果及已识别患者过滤并查看详情，实际人员／结果筛选与事件详情已通过本地浏览器验证。临床正文不进入事件载荷；未知、不存在或跨集团拒绝目标不伪造资源外键，保留安全的动作／原因信息。事件落库或同步检测失败时返回明确失败，不发送资料；审计期间账号、任职、服务关系或授权失效也须在发送前拒绝。版本差异完整展示、审计导出治理和其余业务入口仍须各自核验，不以本轮钩子覆盖全部未来模块。

有效的仅角色模拟可以没有目标医生／人员：审计保留真实管理员、模拟角色、原登录及模拟会话，目标人员字段保持空值。写入前须核对完整、仍有效的会话绑定；不能为补齐审计字段把管理员当作病历责任医生，也不能因未选择目标人员而阻断原本获允许的运营查询。选择了具体医生时仍记录该目标，病历归属和动作资格继续独立检查。

**测试阶段开关（2026-09-09 用户确认，已实现并完成本地自动验证）：** 服务端环境配置 `VAI_ACCESS_AUDIT_ENABLED` 默认开启。只有 `VAI_ENV` 明确为 `local`、`development`、`dev`、`test` 或 `preview` 时允许设为 `false`；其他环境，包括 STG、UAT、production 以及缺失或未知环境名，均保持开启，非法开关值也保持开启。通过服务端 `.env`／部署配置控制，启动时对实际关闭状态记录 warning；`GET /api/auth/mode` 返回 `access_audit_enabled` 供核对，不新增用户界面或客户端切换入口。

允许关闭时，跳过新增访问事件采集、持久化及该层同步异常计算，也跳过 HTTP 审计层的附加来源／引用校验和返回前重复复核；业务处理返回原响应内容及状态，不因这层审计失败阻断测试。医生／护士在业务服务中的真实身份、集团与资源范围、服务关系、固定 Visit 授权、签署资格、版本及事务校验仍执行。登录与模拟退出、授权管理、病历签署、财务变更等既有安全／业务审计仍保留；开关不删除旧事件、授权决定或业务记录。默认开启模式继续执行前述失败拒绝契约，关闭模式的通过结果不能作为严格审计及异常检测验收。

**Operation Logs（本轮本地实现）：** 独立于 Access & Permission Audit 列表，读取现有持久化安全／业务审计和已记录的业务操作日志，可选择来源、刷新及向前翻页。展示时间、操作、结果、记录操作者、岗位、对象引用、来源单位及请求引用；不返回请求正文、自由文本原因、前后值或加密临床载荷。现有操作日志未完整记录模拟身份时不推断真实操作者；旧日志无可验证来源单位时不向前端返回，不按用户当前任职反推历史来源。两类日志是既有覆盖范围，不能声称覆盖全部业务动作。

该读取入口要求真实非模拟身份、`access.audit.read`、有效任职及当前集团／来源诊所审计范围，与 Access Audit 共用范围策略。Account & Sign-in History 沿用现有 `admin.users.read` 查询权限；这是现有账户历史能力，不等于其持有者获得操作或病历访问审计权。Alerts & Reviews 继续要求 `access.anomaly.manage`。系统集中审计不替代 Catalogue、Cashier 等对象页内的业务变更历史。


<a id="52-复核与导出设计"></a>

### 7.2 复核与导出设计

| 编号 | 功能 | 设计规则 | 当前状态 |
|---|---|---|---|
| AU-02 | Before／After 对比 | 展示与该事件有关的字段差异及版本，不暴露无权查看的临床正文 | 事件／版本基础存在，完整展示需核验 |
| AU-03 | Access Review Case | 保存范围、实际操作人、认领人、不可变来源事件及结论；待认领 → 已认领／待说明／复核中 → 合理使用／确认问题／已记录处置 → 关闭 | 服务已通过专项数据库测试；真实 Master 在本地浏览器完成查看触发证据、认领、合理使用复核及关闭，原始审计与不可变证据保留。升级分派、自动处置及正式复核责任政策仍未作为已完成能力 |
| AU-04 | 审计导出 | 指定用途、范围、脱敏和适用审批，记录导出人／时间 | 保留期限、审批与交付方式待安全／隐私确认；不默认允许全量导出 |

查阅审计不应更改原业务记录；发现问题应回到相应更正流程。错误或空结果不显示样本审计事件。


<a id="53-可配置异常识别与复核"></a>

### 7.3 可配置异常识别与复核

**AU-05（用户确认）：** 对同一护士频繁访问大量患者资料的情况进行异常标记，判断规则可配置。以真实人员跨会话的实际行为和不同患者数量统计；一个患者的多 Tab、刷新或重复请求不等于访问了多个患者。搜索、临床读取、附件下载／导出及被拒绝尝试分别计量；规则不能只依靠账号上的一个异常布尔值。

| 配置项 | 当前明确实现机制与边界 |
|---|---|
| 适用范围 | 同集团、可选来源诊所与访问时岗位，动作从服务器已接入目录选择；管理责任和数据读取权限分别校验，Master 不因此获得临床正文 |
| 判断依据 | 显式填写时间窗口、不同患者阈值及不同“患者＋动作”组合数，两项阈值同时满足才命中；按真实人员跨会话汇总。同患者同动作的多 Tab／刷新在窗口中只计一次；访问审计开启时原始访问仍全部保存 |
| 版本 | 先保存草稿，再填写理由发布；同代码和来源范围的新版本发布时退休前版。当前仅即时发布，发布前的旧访问不追溯命中；定时生效与常驻回溯扫描尚未实现 |
| 例外 | 可排除明确实际人员、来源诊所或访问依据，须填写理由；仅影响统计，不获得额外访问权。例外随其规则版本生效／退休；独立例外有效期尚未实现 |
| 事件证据 | 保存命中人员、窗口、去重计数、原规则版本与触发访问引用；每个实际人员、规则版本及配置窗口对应的时间分段只产生一个不可变快照，同分段内刷新不重复告警 |
| 复核与处置 | 获相应管理权限与范围的实际人员认领，不能复核自己的行为；只由认领人记录说明／复核／合理使用／确认问题并关闭。每步需理由和当前版本，保留实际操作者及变更历史；“已记录处置”不表示系统自动停用账号 |

访问审计开启时，检测随真实访问事件落库同步执行，以当前已发布版本计算，**没有后台常驻检测器，也不从内存计数推导完成。** 首批异常计数只包括实际允许且暴露患者信息的事件；拒绝／失败尝试保留原始审计，但独立拒绝频率、无工作关系指标和导出频率组合规则仍待扩展。规则窗口从其发布时刻开始，之后按滚动窗口计算。单个告警的触发证据和计数不因后续刷新改变；同一时间分段关闭后再访问不会产生第二个告警，下一分段的新事件会重新计算。更精细的连续异常合并／重开政策尚未确认，不能宣称实时追踪一个持续更新的异常案例。

按 §7.1 在测试环境关闭访问审计期间，不产生新的访问事件或由其触发的异常。已有事件、规则及异常仍按管理权限查询和复核；恢复开启不会补造关闭期间的记录。该时段没有告警不代表没有异常，也不能用于评估正式阈值或检测完整性。

具体数值阈值、复核责任人与可采取的限制措施仍待业务配置／确认。表单不预填时间窗口和计数阈值，草稿不参与检测，只有经有权人员明确发布的版本才启用。**建议默认只标记和发起复核，不自动中断当前临床工作；** 自动暂停、重新验证或紧急例外须另外明确规则。未配置有效规则时不能把无告警当作已证明无异常；合成演示或测试阈值不作为正式业务值。修改规则保留旧版本和原命中依据，复核无权改写原病历或删除访问事实。


<a id="2-ai-能力与工作流程"></a>

## 8. AI 辅助与知识库

| 编号 | 能力 | 输入 → 输出 | 谁确认与如何失败回退 |
|---|---|---|---|
| AI-01a | ASR／AI Scribe | 获准音频 → Transcript → 当前模板 Draft | 医生修正／保存；失败可手工书写；当前 Consent 门禁见 Consultation |
| AI-01b | AI Note／Clinical Copilot | 授权 Patient／Encounter 最小上下文与问题 → 草稿／建议 | 医生显式采纳，回原模块保存；不能自动诊断／处方／签署 |
| AI-01c | ICD 辅助 | 已保存或指定病历文本 → ICD 候选 | 医生选择 Main／次诊断；不可自动认为候选正确 |
| AI-01d | eMMS | 当前药品快照及必要患者安全资料 → 用药提示与覆盖信息 | 当前代码非阻断；规则治理未完成不能宣称临床安全已获批准 |
| AI-01e | OCR | 原文件 → 提取字段／正文与来源 | 人工核对、修正后采用；保留原件，不覆盖原文件 |
| AI-01f | Clinical Document AI | 当前文档模板的命名 AI 区域与医生指令 → 区域草稿 | 医生核对；部分成功不覆盖未成功区域或较新输入 |

**AI-02：** 未获批准的服务／缺配置／不可用时明确 Disabled 或 Error；不填示例结果。请求和响应绑定患者、Encounter 与输入版本；切换患者后旧结果不得写入新记录。普通 AI Assistant 默认无患者上下文，也不能写临床数据。


<a id="21-knowledge-library"></a>

### 8.1 Knowledge Library

**AI-03：** 仅 AI Governance Admin 可提交获批准的非患者资料；维护来源、版本、Owner、生效／失效日期与审批人，经 Clinical Governance 审核发布后供检索。失效资料不能继续冒充最新规则。患者原始资料不作为普通知识库资料上传。

AI 服务提供方、用途、数据类别、区域、保留期限与生产批准仍需真实配置与治理证据；界面不显示密钥，不把模型输出或服务账号转化为用户资产承诺。


<a id="prd-rag-assistant"></a>

### 8.2 PRD 问答助手

2026-09-10 用户要求：在既有 PRD 网站增加基于当前 PRD 的 RAG 问答机器人；入口选定为 PRD 网站，生成服务选用独立 OpenAI 兼容接口。它用于解释产品需求，不是 Clinical Copilot，也不继承患者或临床系统权限。

| 编号 | 规则 |
|---|---|
| QA-01 | 网站各篇提供唯一“PRD 问答”入口。用户输入问题，可继续追问或开启新对话；回答与原文章节链接同时展示。 |
| QA-02 | 知识范围为当前发布的业务主线、七个模块、Central Pharmacy、设计规范、验收用例和实现／待确认事项，共 12 份。构建时自动分段和重建版本化索引；历史版、工程参考副本、对话、患者数据和外部网页不进入索引。 |
| QA-03 | 先中英文检索，再仅以检索章节生成答案。回答优先简洁，保留会改变结论的前提，避免重复和未被询问的扩展；每段事实附有效来源；文档未说明、证据不足或互相矛盾时明确指出，不自行补造规则。需求、当前实现、验收定义与实际验收结果分别说明。 |
| QA-04 | 模型未配置或失败时保留真实原文检索，明确“未生成回答”；不得用演示文字冒充模型输出。引用不存在或格式不合法时拒绝该回答。 |
| QA-05 | Base URL、模型和密钥由服务端配置；浏览器不保存密钥。仅发送用户问题、最近至多四个用户问题及检索片段；普通成功问答仅在当前页面内存保留，刷新或新对话清除；未能回答的问题及用户提交的点踩反馈按 QA-07–09 单独留存。无患者上下文、不支持上传、不写业务数据。问题中不应输入患者个人资料。 |
| QA-06 | 当前发布页面的访问范围保持不变。请求长度、超时与实例内并发／频率有界；实例限流不是跨实例计费硬上限。独立模型的可用性、配额及服务提供方数据保留政策需按实际配置核验。模型输出只作为阅读辅助，原文仍是规范入口。 |

2026-09-10 用户要求增加点踩及未回答问题留存，帮助补充和完善 PRD：

| 编号 | 反馈与维护规则 |
|---|---|
| QA-07 | 每次回答可点踩并选择原因、补充说明。证据不足、模型调用失败和模型未配置的问题自动留存，分别归类；服务失败不自动认定为 PRD 缺失。保存成功后明确提示；保存失败显示未留存并可重试，不显示假成功。 |
| QA-08 | 私有保存服务器确认过的原问题、最近两条追问上下文、原回答、引用章节标识、PRD 版本、时间及反馈原因。普通成功且未点踩的问答不持久化。无需采集提问者姓名、患者资料、IP 或密钥；同一回答重复提交不重复建项。留存内容不进入公开文档下载或 RAG 索引。 |
| QA-09 | 维护者通过受保护的反馈清单查看、分页加载、按已加载记录筛选和导出；标记“待处理／处理中／已补充 PRD／无需修改”，保留说明及处理历史。“已补充 PRD”必须填写现行 PRD 章节链接，但标记本身不修改文档或证明验收。并发更改检查版本，防止覆盖他人的处理记录。 |
| QA-10 | 页面明确告知问题留存用途。反馈仅是待核实输入，由维护者判断是否补充规则、修正文档、改进检索或处理服务问题；确认后仍按既有 canonical PRD 修改、构建、发布流程实施。重新发布和浏览器刷新不会清空持久化记录。 |

实施与配置、检索质量和真实模型联调结果见 PRD 站点说明（仓库资料：prd_preview/README.md），不得将无模型检索或模拟接口测试写成在线生成已通过。


<a id="6-integration-monitor-与外部服务"></a>

## 9. 外部集成与人工承接

已有设计包含 Connections／Messages、状态查询、消息详情、失败重试、人工兜底及审计。**2026-08-27 已明确延期 Integration Worklist、失败状态、SLA 与重试责任，本版不将旧设计升级为本期确认需求。**

| 外部能力 | 本期可承诺的业务边界 |
|---|---|
| 支付 | 员工记录外部付款结果，不直连终端 |
| 保险 | 人工核验与回款记录方向，不承诺自动 eligibility／Claim／核赔 |
| Vendor | 配置、选择、开单、人工收件，不建设外部执行工作台 |
| WhatsApp／消息 | 可人工辅助跳转和记录，不承诺自动批量发送／送达 |
| AI／ASR／OCR | 经批准的服务集成及明确失败反馈；各领域决定后续动作 |
| NetSuite／eHealth／政府接口 | 保留集成方向；范围、映射和验收需单独确认，不按入口可见计交付 |

Line D 提供连接能力，业务状态仍归 Line A／B／C。连接显示成功不代表已收款、已发药、已出结果或已获临床确认。


<a id="7-迁移部署与移动访问"></a>

## 10. 历史迁移、环境与移动访问

本地合成登录配置只辅助测试，不授予权限，不进入应用或 PRD 发布产物。配置损坏须明确报错，不悄悄换成另一组账号；详细生成、构建过滤与已执行验证见实施参考（仓库资料：../workflows/context/prd-structure/implementation-reference.md）。


**PL-01 历史迁移：** 保留旧患者／Chit 标识、来源、日期和附件关系，校验患者、Encounter、处方、费用及附件关联；失败记录可追溯和重跑。旧记录默认只读，空白不能解释成患者从未有相关病史。记录数／抽样阈值及切换时数据权威仍需确认。

**PL-02 附件与恢复：** 私有文件按授权短期访问；上传成功不代表 NAS→OSS 全量迁移完成。备份恢复、切换与回滚要有实测记录，不能用操作文档替代演练。

**PL-03 环境：** 代码实现、本地验证、文档发布、应用部署、端到端联调、UAT 分别记录。预览合成患者与真实业务明确区分；正式空数据或接口失败不回填演示业务数据。

**PL-04 移动 Web：** 方向为获授权只读患者摘要、用药及相关工具；精确字段、遮罩、会话、安全及性能仍待确认。不把 H5 患者填报视作已完成员工移动临床工作台。

<a id="implementation-boundaries"></a>


<a id="8-本期排除与待确认"></a>

## 11. 待确认事项与实施边界


<a id="45-尚待细化及保守实施默认"></a>

### 11.1 尚待业务确认

以下默认是实施建议，不冒充已确认业务决定；依赖未决规则的能力标为待确认，明确部分可继续实施。

| 待确认内容 | 暂定实施默认／配置边界 |
|---|---|
| 患者搜索的精确身份字段与脱敏 | 默认只返回身份匹配、预约所需最小字段；不带临床摘要、全部保险明细或历史统计；本轮限定同集团 |
| No Consultation 的资源预订及护理执行语义 | 默认不进入医生问诊队列，不因类型例外放开其他医生预约；保留护士／服务流程及资源冲突检查，不强制所有历史预约绑定医生 |
| 旧患者级详细资源的可靠来源与修复 | 公共医疗信息、独立隐私字段、受限问诊记录／处方及历史附件按 §3.2–3.4 分类；旧附件分类及患者／集团来源需核对，不能仅按附件容器、文件名或新 Visit 猜造权限。已明确归类为公共的资料不因缺少 Provider 阻断共享；归属不明的受限正文不得自动降级为公共资料 |
| 护士协作草稿的后续模块扩展 | 本轮实施范围为医生已初始化的 Note、Service Selection、护理交接和已有临床文档快照；权限与临床状态分别检查。首次开始问诊、选取私人模板、处方／检查最终确认、临床完成及签署保留给医生；Cashier 结算与收款由关联护士按财务动作执行。临床队列申请、只读／草稿门禁及护理交接保存回读已有本地浏览器通过证据，其他模块仍按各自用例验收；新增模块不默认开放所有 clinical.write |
| 正式交接是否覆盖持续照护及未来预约 | 默认只处理列明既有记录／本次职责；未来范围不自动继承，待另行确认 |
| 异常阈值、复核负责人及限制动作 | 按 §7.3 可配置；未批准阈值不宣称检测已启用，默认不自动封停临床工作 |


<a id="948-待确认和实施边界"></a>

### 11.2 用户配置与授权的当前边界

**本次权限规则的来源。** 2026-09-14 用户确认了集团基础资料共享、修改和确认保留诊所关联、敏感字段查看审计提示、公共医疗信息角色授权、按诊所维护护士与医生关系，以及问诊记录、附件和处方的访问范围。随后明确前台保留预约和基础信息维护，但不能签到。这取代此前基础详情读取也受诊所关联限制、仅 Note／历史处方受限，以及前台可签到或收费的表述。规则见第 3 节，本轮修改不代表应用已经实施或验收。

**单角色配置的已有基础。** 全局角色 authority、数据库约束及显式角色转换已有代码和本地定向完整链路验证，发布与业务验收另有记录。当前和未来岗位都继承同一业务角色；新增或恢复岗位不能取得第二个角色。存量冲突显式列出，保留原有有效操作和历史记录，不在启动时自动选择角色。

角色转换先预览旧岗位、护理关系、记录授权、临时代诊和会话的影响，再凭预览结果提交。相关条件发生变化时重新预览。仍承担审批职责的人员须先移交职责，才能完成转换。旧岗位结束后新建岗位，不复用原 ID；医生身份和历史作者保持不变。

**安全资料的现有写入限制。** 当前代码只允许拥有来源就诊的医生更正安全资料。同诊所、有患者维护权限的护士可以修正姓名、手机和地址，但已有 Allergy／ADR／Alert 及备注仍只读，草稿协作授权不开放这项修改。护士安全资料更正尚未实现。核实及创建时间由服务端维护，省略备注保留原值，显式空值才清除；不恢复未分类旧完整病历快照。旧接口和附件分类改造仍需逐项验证。

**2026-09-14 已确认、待实施核验：** §3 权限分类及最新前台边界已更新；本轮不修改应用代码或角色种子。源码中患者身份投影仍包含 `hkid` 等字段，公共疫苗读取仍复用 `patient.read`，不能据此认定敏感信息默认隐藏或独立公共医疗读取能力已落地。基础字段限制、当前／历史附件分流、Cashier 护士操作范围和完整问诊类别需后续逐接口对照；证据与发布状态见本轮 PRD 修订记录（仓库资料：../workflows/context/access-control/prd-permissions-20260914.md）。

1. **持续记录覆盖已确认、待实施：** 2026-09-10 本轮评审允许医生明确选择持续覆盖，查看及草稿编辑分别授权。具体模式、旧授权兼容、关系失效和权限上限统一见 §5.2；现有固定 Visit 实现不作为持续范围已生效的证据。
2. **处方编辑实施需细化：** 本方案建议允许已授权的处方草稿协作，具体可改字段及创建／删除草稿能力需在实施前形成模块契约；最终开单／签署仍由医生，历史正式处方不可直接改写。
3. **本轮实施边界：** 已实现四入口、三页签、按需展开岗位表单、护士范围原子多选与立即生效、医生固定记录授权入口及管理员同源只读记录。新关系跟随岗位上限，保留未修改关系的既有更短期限；本轮不提供未来自动切换或新建更短服务期限。

已落地的主体检查同时作用于服务配置、医生授权及临床读写决策；旧跨主体记录保留历史，但不再作为有效授权依据，可在该护士岗位的范围编辑中修正。角色动作按岗位展示，医生授权显示同源记录和失效状态；完整逐项权限诊断、角色动作与 App 可用性的统一解释仍需继续核对，不能把角色动作清单视为每个模块均可操作。处方草稿协作仍待模块契约。验收案例见[业务测试用例](https://virtus-patient-emr-prd.vercel.app/acceptance.html#user-access-design-cases)；实际验证及发布另外计证。


<a id="34-既有实现与本轮兼容范围"></a>

### 11.3 范围与证据入口

经营看板、通用 Report／Insights、现金盘点关账、自定义／定时报表、App Marketplace、完整 WDL 和复杂 Benefit 后台不属于本期完整验收；已确认的 Day-end Revenue Report 按 Cashier PRD 承接，不在通用报表排除项内。权限、临床协作与异常监测的未决细化见 §11.1／§7.3。页面保留策略与功能范围独立；2026-09-06 用户明确要求清理重复及无实际用途的 App，当前策略见桌面入口章节。撤出占位入口不取消已确认需求，也不新增 WDL／集成 SLA 承诺。

权限及会话的历史实现、兼容迁移和已执行验证见实施参考（仓库资料：../workflows/context/access-control/product-restructure-evidence.md）、WS6（仓库资料：../../dev_working/workstreams/phase_0/p0_ws6_identity_access_consent_audit.md）、权限测试（仓库资料：../test_cases/access_control/README.md）及导航测试（仓库资料：../test_cases/app_navigation/README.md）。本轮整理以当前开发分支及项目索引指定的本地候选为来源；不新增应用完成或 UAT 结论。已确认业务与候选代码不一致时继续记录差距。
## 全局主体上下文与数据范围（已确认）

用户通过全局 Context Selector 切换本人有效的 Clinic／业务主体；各 App 不再自行提供跨诊所筛选。任一 App、Tab、列表、详情与动作只使用当前主体，并由服务端重新计算 `auth context` 与 `ui_access`。Doctor 在当前主体只能查看本人 Provider 的日程、当前问诊患者及历史问诊记录；Nurse 只能查看当前 Clinic 内且满足本人有效服务关系及医生授权的日程、队列和记录。切换到另一有效 Clinic 后才可加载对应数据。主体切换清空旧患者、队列、历史、角标、未保存内容和进行中请求；迟到响应不得写回新主体。列表、详情和动作接口均再次校验主体与对象授权，缺少主体或投影时默认拒绝。


---

# AI-CLIP 业务测试用例

更新：2026-09-14 · 配套：[业务主线 PRD](https://virtus-patient-emr-prd.vercel.app/index.html)／[Consultation 当前行为](https://virtus-patient-emr-prd.vercel.app/consultation.html)／[实现与待确认事项](https://virtus-patient-emr-prd.vercel.app/delivery-notes.html)

本文是可执行的用例，不是已执行结果。**当前版本回归** 检查代码的实际行为；**目标验收** 检查已确认产品需求。已知不支持的目标先记 Blocked，不能降格为 Pass；业务未确认的事项先确认，不能由测试人员猜预期。

## 1. 测试准备

只使用合成数据。准备授权 Clinic A／Clinic B、前台、护士、负责医生 D1、非负责医生 D2、Dispenser、另一位 Checker、具有 Cashier 动作的关联护士、后台 Finance、管理员账号；需要真实服务的用例使用测试配置，不使用真实患者资料。

| 编号 | 测试数据 | 要求 |
|---|---|---|
| P1 | Clinic A 新合成患者 | 唯一姓名、电话、合成证件号；无既有卡，建档后记录系统 Patient No. |
| P2 | 同集团仅关联 Clinic B 的合成患者 | 用于跨诊所查询／预约关联测试 |
| P3 | 与 P1 完全相同证件／另一组合为同规范姓名＋电话 | 两种重复校验分开运行，不能只是同姓名 |
| V1 | Clinic A 普通 Consultation、负责医生 D1 | 当日 Confirmed；支持有效 Provider 登记、模板、药品及权威价格 |
| V2 | 另一位患者的可写 Visit | 用于跨患者草稿／迟到 AI 响应隔离 |
| R1 | 普通测试药品与有效价格 | 不含真实用药建议；库存与终端操作只在测试环境 |
| S1 | 可选的有效 Lab／Imaging 项目与价格 | 能作为 Service Selection 保存；内部执行用例需另具备 V-Lab 环境 |
| C1 | 有效 Insurance Card，另有过期卡与企业／员工合同 | 卡种为后台测试数据，能检验来源互斥与类型匹配 |
| H1 | Completed／Closed／迁移历史各一条 | 只读及不可重开验证，保留初始内容快照 |

用例前记录环境 URL、版本、角色、诊所及原始状态；遇到缺账号、缺价格、没有后台功能或规则未定，填写具体 Blocked 原因，不改业务规则求通过。

## 2. E2E-01：普通门诊、处方与收款闭环

类型：目标闭环＋已实现片段回归。前提：V1、有效药品 R1、医生权限、可靠存储与付款服务；固定选择 No follow-up，排除当前复诊固定时段差距。用一名患者贯穿全部步骤，不中途换成另一个 Demo。

| 步骤 | 谁／在哪操作 | 操作 | 预期可观察结果 |
|---|---|---|---|
| 1 | 前台／Patient & eMR | 搜索后新建 P1 | 一条患者记录，三项必填完整；记下 Patient No. |
| 2 | 前台／Reception | Add appointment，选择普通 Consultation、D1、当日有效时间 | Confirmed、Awaiting check-in；尚无签到 Visit |
| 3 | 关联护士／Registration | 核对身份并 Check-in；刷新后再请求一次 | 一条关联 Visit；预约 Checked-in／Visit Arrived；重复请求不新增 Visit |
| 4 | 护士／Preparation | Self-pay，完成本次要求的准备；Ready | Ready for consultation，出现在医生队列；护士仍留 Registration |
| 5 | 医生／Queue | 打开同一 Visit | Start 后 In Consultation；当前若无主动双标识弹窗，单记已知安全缺口，不视为该项通过 |
| 6 | 医生／Note | 手工填写模板、选择一个 Main Diagnosis；离开模块并等待后台保存完成 | Note 与诊断已保存，重新进入内容仍在 |
| 7 | 医生／Prescriptions | 加测试药 R1，填完整用法／数量，保存 | 当前药单版本保存，费用来源正确 |
| 8 | 医生／Service | 本例不加检查，保存空 Selection | 空集合也为已保存模块，不留下未同步阻断 |
| 9 | 医生／Documents | 不创建文档；若默认集已有文档，则保存全部剩余 Draft | 无未持久化文档，不伪造“无需”跳过已有脏数据 |
| 10 | 医生／Billing & Finish | 核对真实权威金额，No follow-up，Review & Complete 并确认 | 所有检查通过；同一事务签署并进入 Ready for Cashier，返回 Queue；仍未 Paid |
| 11 | Cashier | 药房尚未审核时核对其他费用，尝试收款 | 药费等待药房确认；拒绝任何提前收款 |
| 12 | 配药人员／Drug Dispensing；Cashier | 逐项核对并整张 Review、预留；尝试未结算备药；Cashier 核对整次金额 | 审核及预留后允许统一结算；结算确认前仍拒绝实物备药，旧代码不符记待开发 |
| 13 | Cashier | 一次结清全部费用 | Cashier 确认结算，药房进入待备药但不是已发药 |
| 14 | Dispenser／Checker／Drug Dispensing | 结算确认后开始备药，标签／批次／效期完整后提交复核，另一 Checker 逐项核对后整张发药 | 待备药 → 备药中 → 待复核 → 待发药 → 已发药；核对者及交付时间可追踪；缺失实现记 Blocked |
| 15 | Cashier／患者历史 | 打印 Receipt，完成当场离院安排，查看历史 | 收据关联实收；Patient／Visit／处方／Invoice 对应；Checkout 不能伪造检查结果或财务全清 |
| 16 | 测试负责人 | 查状态／版本／审计并对照初始编号 | 全程同一 Visit，无重复患者、处方、账单、收款；自动 Closed 单独按 CL 用例验证 |

第 10 步服务端失败，应整体回滚当前原子完成动作，不能期待“签了一半”的完成结果。该行为以 Consultation 当前 PRD 为准。

## 3. 患者、预约及护理

| 用例／需求 | 前置条件 | 执行步骤 | 预期结果 |
|---|---|---|---|
| T01 · PT-02 | 未建档 | 分别缺姓名、电话、证件保存 | 每次显示缺项且不新建；三项齐全才重复校验 |
| T02 · PT-02 | 已有 P1 | 同证件建档；再用不同证件但同规范姓名＋电话；最后仅同姓名 | 前两种阻止重复并说明依据；仅同姓名不能自动视作同一患者 |
| T03 · PT-03 | P1 已有历史 Visit | 修改联系方式／安全资料并填原因，重读当前和历史 | 主档新版本生效，历史快照保留；不输入默认“无过敏” |
| T04 · PT-01／PT-04 | P2 仅关联 Clinic B | 在 A 的 eMR 搜索；预约搜索并查看后取消；再核验并保存预约 | 按护士同集团身份查询资格可找到患者；普通预约保存只形成运营关联，Confirmed 不授予 A 诊所资料维护权；首次注册、有效 Visit 或另行批准接收按 Platform 分别判定 |
| T05 · PT-05 | 多次历史、Vitals、附件 | 从 Registration 点患者姓名，浏览历史／附件后返回 | 仍回原任务；不启动问诊；各历史数据可追溯来源，空疫苗不表示从未接种 |
| T06 · PT-06 | 有测试 Intake Draft | 扫码核对预填，改一个字段，补基础资料，跳过额外／保障后提交 | 只有待审核提交；主档不变，保留原值与修改值；后端缺失则 Blocked |
| T07 · PT-06 | 令牌服务可测 | 在 48 小时边界前后打开／保存／提交；改客户端时间重试 | 服务端到期判定有效，过期拒绝；无 OTP；不能靠前端时间绕过 |
| T08 · PT-06 | 已在患者确认阶段关联／确认新患者的 Submitted | 护士审核确认结果；修改身份后尝试批准；另测待澄清、拒绝和新建批准 | 正常审核不重新要求匹配；身份修正使原确认失效，护士核实并记录依据前不能批准；不得用审核请求直接改关联；拒绝不写主档，合法批准不重复建患者；缺失链路记 Blocked |
| T09 · AP-01／AP-02 | 有 P1 | 从 Reception 建预约；逐项漏患者、医生、日期、时间、类型；完整保存 | 缺项拒绝；完整默认 Confirmed／Awaiting check-in，无 Visit，无自动 Check-in |
| T10 · AP-03 | 当日 Confirmed | 退回 Unconfirmed、再确认、改约至明日 | 当日 Registration 可见性对应变化，原预约历史保留 |
| T11 · AP-03／RG-04 | Preparation 中已有 Visit | 填原因取消；模拟其中一项更新失败 | 成功同时取消 Appointment／Visit；失败整体不改变；日历保留取消历史 |
| T12 · AP-04 | 已有医生 Block-out | 普通门诊与 Prescription-only 预约重叠；另测 No Consultation | 前两者拒绝；护士服务按例外提示并校验资源；不能自动删原预约 |
| T13 · AP-04／MD-07 | 完整多资源功能部署 | 两用户争同容量；改约一条多资源预约 | 不超容量；所有 Assignment 同步、不一部分改约成功；未实现记 Blocked |
| T14 · RG-01 | V1 Confirmed | 两用户同时 Check-in／超时重试 | 唯一 Visit，Appointment／Visit／状态事件对应；不能只用页面数量判断 |
| T15 · RG-02 | Preparation | 缺必需身份／非自费核验／被要求 Vitals 各测试一次 | 具体缺项阻止 Ready；未要求 Vitals 不强制填写；记录前端与服务端门禁差别 |
| T16 · RG-03／RG-04 | Ready Visit | 尝试直接编辑／取消，再填原因 Previous stage；再从 Preparation 回 Checked in | 直接操作拒绝；逐级回退，医生队列移除，同一 Visit／Vitals 保留 |
| T17 · 第5节类型分流 | 七种类型各一条 | Preparation 完成后查下游；继续医生／服务阶段 | 目标仅 No Consultation 去服务队列；Day Procedure 先医生评估；当前差距逐类 Blocked |

## 4. Consultation 当前版本回归

| 用例／需求 | 前置条件 | 执行步骤 | 当前预期结果 |
|---|---|---|---|
| T18 · CQ-01～CQ-03 | 当日、跨日、迁移、Completed、Closed 多记录 | 切 Active／History、日期、医生筛选、Load more | 当日原生 Active；Carry-over 不计今日等待；History 只读，按 50 条增量加载 |
| T19 · CQ-04／DR-01 | Ready Visit | Start 并检查是否出现主动双标识核验 | 当前按上游状态推断，若无弹窗登记已知设计缺口；不能给双标识安全项 Pass |
| T20 · CQ-05／CQ-06／DR-04 | V1 有未保存 Note，V2 可打开 | 模拟后台保存失败，切 V2，再回 V1 | 录音停止；导航可继续；草稿隔离保留，失败有反馈；不丢 V1、不串 V2 |
| T21 · CN-01～CN-03 | 可用模板 | 编辑不同字段、保存、重读；新增个人模板、字段排序、Restore 默认 | 内容与模板快照恢复；默认不能删除，个人模板按权限；不假设固定四字段 |
| T22 · CN-04 | Note 已保存 | 无 Main、一个 Main、两个 Main 分别尝试完成 | 只有恰好一个已保存 Main 符合完成条件 |
| T23 · CN-06 | 无 AI Scribe Consent | 启动录音／生成 Draft，先取消再确认；另测 Consent 查询失败 | 取消不录音／不写同意；确认保存后才启动；查询失败保持阻断 |
| T24 · CN-06／AI-02 | 有 Transcript 及模板 | 生成 Draft，改字后制造迟到响应，切患者 | 候选可编辑且不自动签署；旧响应不覆盖新输入／新患者；服务未配置记 Blocked |
| T25 · CP-01／CP-02 | R1 药品目录 | 添加剂量／途径／频率／疗程／数量，保存；重读并删除后保存空集合 | 用法与实际数量保存；空处方也是明确保存状态，未同步不能完成 |
| T26 · CP-03 | eMMS 不可用或产生警示 | 保持其他完成条件满足，保存处方并查看 Review 检查 | 当前 eMMS／Allergy／ADR 不独立阻断；如实记录，不能宣称临床治理已通过 |
| T27 · CP-01 | 各有行及整单内部 Remark | 填内部备注和不同 Patient instruction，保存、看药房及标签 | 内部备注传药房、各不超 2,000 字符；不当患者说明打印 |
| T28 · CS-01～CS-05 | 有已保存 Note | 搜索／建议加入同项目，Copy Previous，保存；另测建议不可用 | 同项目不重复；失效项不能复制；建议不可用仍可手工操作；空集合可保存 |
| T29 · CS-06 | 已保存 Selection | 签署前更改测试 Offering 价格／Vendor／有效状态 | 价格需重新核对，Vendor／停用需重选，不能静默替换或使用陈旧版本 |
| T30 · CB-01／CB-02 | Billing Draft | 分别输入 101% 折扣、超过 gross 固定折扣、缺原因；再输入合法折扣 | 非法拒绝；合法保存原价、原因、类型、医生、net；变动使旧确认失效 |
| T31 · CB-03 | 一个模块未保存或缺价格 | 点击 Review & Complete，Go to section，修正再开 | 清单始终能打开；具体定位失败项；未同步／缺价不允许确认完成 |
| T32 · CB-04／CT-02 | 普通门诊条件齐全 | 完成时制造数据库失败；恢复后同请求重试 | 当前事务全回滚；成功只签一次／建一次快照与 Handoff，Ready for Cashier |
| T33 · CB-04 | D2 无覆盖／护士／特殊类型 Visit | 调用当前 Billing & Finish 完成操作 | 非负责无覆盖／非医生拒绝；特殊类型明确不支持，不能作为普通门诊完成 |
| T34 · CB-05 | 普通门诊选择 Book follow-up | 填日期与原因完成，再查预约并重试完成请求 | 当前创建 Booked 09:00／30 分钟且不重复；登记与“统一预约选择时段”目标不符 |
| T35 · CC-01／CC-02 | 文档默认集及多页签 | 同模板开两份、分别编辑，切页签，再离开模块 | 内容互不覆盖；切页签不造服务端版本，离模块保存全部；默认最多六项 |
| T36 · CC-02／CC-05 | 两份文档，一份脏 | 打印当前页签，再改内容并模拟保存失败 | 只保存／打印当前页；失败保留草稿，导航可继续，但最终完成阻断 |
| T37 · CC-03／CC-04 | Draft 文档 | 缺 Recipient／正文尝试保存、AI、Print；另一窗口取得租约 | 内容缺失只提示；身份／编辑权失败硬阻断；旧工作台只读 |
| T38 · CC-04／CD-03 | 未保存、已保存 Draft、Signed 各一份 | 点 X，刷新；打印 Signed | 未保存直接移除；Draft 确认软删；Signed 无删除，打印不自动 Issued |
| T39 · CR-01～CR-06 | V1 活动问诊及历史 | 切 Reference 五入口、开 eMR 返回、Anatomy 标注后换患者、调整／重置布局 | 不改 Visit；历史可追溯；未保存标注清除；显式截图保存至原就诊附件，跨患者隔离、失败重试及图片复制；布局仅非临床偏好 |

## 5. 药房、检查与财务

| 用例／需求 | 前置条件 | 执行步骤 | 预期结果 |
|---|---|---|---|
| T40 · RX-02／PH-01 | 处方签署，尚未 Invoice／付款 | 在药房查队列并 Review；尝试 Label／Pack | 立即有当前 Handoff，Payment pending 允许审核，拒绝开始备药；旧代码不符记录待开发 |
| T41 · PH-02 | 注入异常旧状态：已备药但未获 Cashier 结算确认 | 前端点击和直接请求 Dispense | 两端都拒绝；无实际发药状态／库存变动；正常流程在更早的开始备药环节已阻断 |
| T42 · PH-03 | 普通药与高警示药各一单 | 同人配药／最终核对，测试授权单人例外及紧急审批 | 正常需另 Checker；普通例外需再认证／原因，高风险不得套普通例外；Paid 不豁免 |
| T43 · PH-04 | Ready for Cashier，药房有问题 | 空评论退回，再填类别与评论退回；尝试 Pharmacy Cancel | 空评论拒绝；正确退回整张处方并建立医生任务及 Cashier 阻断，Encounter 暂留 Ready for Cashier；护士在 Cashier 手动确认后才回 In Consultation；两步分别审计；Pharmacy Cancel 拒绝 |
| T44 · RX-03／CP-05 | Doctor review required | 医生 Amend 改药签署；再测试清空全部药 | 旧队列 Superseded；有药新版本签署后再次 Ready for Cashier 但仍阻断，重新审核及预留通过才解锁；全部药品经医生签署取消则无须重审，Cashier 核对剩余费用 |
| T45 · RX-04 | 历史／异常数据：收款后另行受控修订（非正常审方链路） | 新版本尝试继承旧付款直接发药 | 拒绝旧付款直接放行，不删原交易、不自动重复收费；特殊调整 SOP 另行定义，不作为正常流程入口 |
| T46 · IV-04 | 权威库存已接入 | 发药同请求重试，模拟库存处理失败 | 不重复扣减；能对账处方版本与变动；未接通不能从 Dispensed 推断库存正确 |
| T47 · LB-01 | 内部工作台已具备 | 医生开单，承接、执行、录结果、核验、发布、医生确认 | 同一 Order 全链；Released 不自动 Doctor Acknowledged；缺环节记 Blocked |
| T48 · LB-02／LB-03 | 内部 Order；另有 Closed 来源 | 不能执行填原因；Closed 后上传晚到结果 | 原因／医生处理及费用影响有记录；晚结果是关联事件，原 Encounter 不重开 |
| T49 · LB-04 | 外部 Vendor Order | 记录转介 Sent、等待、人工收件及医生确认 | 不出现虚构外部执行工作台／自动采样进度；不要求自动回传 |
| T50 · BL-01～BL-03 | 医生收费交接完成 | 重取来源、变更目录价，再看已 Post Invoice | 不重复费用；已 Post 仍保留旧快照，草稿价格变化明确可查 |
| T51 · BL-04～BL-06 | Invoice 920 | 审核前尝试收 600；审核及预留通过后统一收 920，重复请求／重印 | 前者拒绝，后者一次结算；不重复付款，重印不记收入 |
| T52 · IN-01／IN-02 | 患者旧卡与上次 eligibility | 新预约选卡、换卡；过期卡到 Cashier | 不继承上次 Case／核验；过期／变更需复核；显示真实人工来源 |
| T53 · IN-03 | 两个未结 Invoice；实际保险到账 | 部分分配、跨账单分配、超额分配、撤销错配再分配 | 余额可解释；不得超可分配金额；原 Invoice／到账事实保留；未实现记 Blocked |
| T54 · IN-04 | 患者自付已付但第三方未到账 | 尝试最终发药 | 自付结清、第三方责任确认且 Cashier 确认安排后可备药；第三方余额保留 AR，不虚记已收款 |
| T55 · BL-07／CL-01 | 已付款／Closed | 发起获授权退款或冲正 | 原交易保留、关联更正有原因和审计；Closed 不重开；流程未实现记 Blocked |
| T56 · CL-01／CL-02 | 可控制签署时钟的测试环境 | 24小时前／后，分别有无阻断；原医生／其他医生请求 Amendment | 只原医生在窗内可直接修订；超窗未 Closed 需批准；有阻断不自动关，Closed 永不可重开 |
| T57 · PK-01／IV-01～IV-03 | 套餐／药品库存测试数据 | 权益预留消耗冲回重试；停用药品、看历史与新选择 | 台账不重复扣减、历史保留，新选择不含失效药；未完成链路标 Blocked |
| T58 · FU-01／TK-01～TK-05 | 有来源的回访／结果／文档任务 | 分派、记录联系、结果完成；Open source／Book follow-up | 源记录和负责人可追溯；普通任务完成不代医生签署；无消息渠道不标送达 |


### 5.1 药房最新规则的交叉验证

以下用例对应 2026-09-03 最新确认，当前旧代码不能作为通过依据。

| 用例／需求 | 前置条件 | 执行步骤 | 预期结果 |
|---|---|---|---|
| T72 · PH-01／PH-06 | 注入异常旧数据：已 Paid、未完成当前版本审核（非正常业务路径） | 尝试 Label／Pack／Verify，再审核通过 | 审核前拒绝实物执行；正常收款接口本身也必须拒绝审核前收款，不能把此用例当作允许先付款的流程 |
| T73 · PH-04／BL-09 | Cashier 旧页面已打开，处方尚未发药 | 药房退回成功；旧页面分别提交开票／过账／收款／Checkout | 服务端全拒绝，显示原因与当前版本；可读原记录 |
| T74 · PH-04／RX-03／BL-09 | 已退回，医生已重新签署新版本 | 先尝试 Cashier；再让药房审核当前版本通过并尝试 Cashier | 首次仍阻断；当前版本通过后仅解除临床阻断，不自动 Paid／Checkout |
| T75 · RX-03／BL-09 | 新版本待审核、旧版本 Superseded | 送旧版审核通过事件、重复回调；新版审核失败 | 旧事件不解锁，新版失败再次退回医生并保持阻断 |
| T76 · PH-04／BL-09 | Ready for Cashier | 模拟退回中任务／状态／阻断任一步失败，再重试退回 | 失败整体回滚，不出现药房已退回但收银可收款；成功任务不重复 |
| T77 · RX-04／BL-09 | 收款与审核退回并发 | 分别让退回先成功、付款先成功 | 前者后续收款拒绝；后者保留真实付款，修订后财务复核，不删除或重复收款 |
| T78 · PH-04／CL-01 | 已 Dispensed 或 Closed | 普通 Comment & return 请求重开 | 拒绝普通退回重开；需独立更正／退药／退款流程，未确认流程记 Blocked |
| T79 · RX-03／BL-01 | 退回及重新签署已成功 | 重发退回、签署及交接请求；查询费用／任务／Invoice | 不重复任务、费用、账单或付款；历史完整，旧版本不可继续执行 |

### 5.2 Cashier 保险 CoPay、患者欠款与补缴

依据 [Cashier 保险、CoPay 与欠款功能](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#cashier-payer-arrangement) 的 2026-09-10 确认；下表是验收定义，实际执行和环境见 Cashier 测试记录（仓库资料：../test_cases/cashier/copay-outstanding-20260910.md）。

| 编号 | 场景 | 预期 |
|---|---|---|
| CASH-AR-01 | Visit 已选择保险／企业计划后进入 Checkout | 自动承接本次来源和已有资料，不默认确认全额保障；明确选择全额／CoPay 及付款责任后才可开票；已 Post 读取冻结责任；晚到的新账单或余额／结算变化撤销旧确认，同一账务状态刷新保留未提交草稿 |
| CASH-AR-02 | 保险全额承担，本次无实际到账 | 无患者付款行；确认付款安排，保留第三方 AR，无 Payment／Receipt；药房继续检查当前审核／库存 |
| CASH-AR-03 | 保险＋CoPay，患者 Cash＋FPS 分拆实收 | 患者实收等于 CoPay，第三方承担不算实收；两笔实际付款各有 Receipt，拆分同一事务生效 |
| CASH-AR-04 | 自费全部欠款，或 CoPay／自费部分实收、其余欠款 | 显式欠款原因／确认不可缺，日期合法；仅真实付款有流水；服务端计算患者余额并登记确认人／时间；已确认安排后允许真实药房备药及正常独立复核，不自动发药；修改本次付款金额后须重新确认欠款安排 |
| CASH-AR-05 | Billing History 先补缴患者余款，再收保险回款 | 同一原 Invoice 分别减少对应责任余额，允许分次；患者付清不代表全单已收齐；所有责任结清才 Paid；不改变原发票金额、原结算／临床版本或已发药状态 |
| CASH-AR-06 | 无原因／未确认、负数／非数、超收、无非现金凭据、非法日期、旧版本／越权提交 | 服务端拒绝，原子事务无部分付款或虚假收据；相同请求重试只计一次，金额／原因变化后的新操作使用新请求标识 |
| CASH-AR-07 | 欠款结算后退款更正，或源 Visit 已 Closed 后补缴 | 退款更正撤销放行，历史欠款不自动再授权；未完成 Checkout 可重新明确登记，已完成 Checkout 走补足患者余额后原结算重新确认；Closed 只处理账务、不重开临床 |
| CASH-AR-08 | 当日欠款登记、次日真实到账并生成日报 | 欠款确认不算实收；到账按收款发生日计算，不重复累计原开票收入；患者和第三方账务分别勾稽 |
| CASH-AR-09 | 1366×768 与 1920×1080 完成付款／欠款并打印 | 关键金额和唯一主动作可见；结算前不重复展示 Invoice 模板／打印，结算确认后只有一个 Invoice 模板选择＋打印入口；打印所选布局不改变原账务／身份快照，历史打印事件保留版本；实收 Receipt 独立 |

## 6. 主数据、AI 与平台

| 用例／需求 | 前置条件 | 执行步骤 | 预期结果 |
|---|---|---|---|
| T59 · MD-01 | Service／Product 主档 | All Clinics、仅 A、明确清空；在两诊所查看价格与可用性 | 售价／成本统一，诊所只管可用；清空不是全部可用；缺底表标 Blocked |
| T60 · MD-02 | 一个项目、两 Vendor、诊所／医生 Cost | 逐层移除覆盖并查询 Cost 与售价 | Cost 按指定优先级 fallback，售价不变；不能退到已废弃 Group Default |
| T61 · MD-03 | 医生／Policy／Clinic 四层价格 | 依次移除特例到无价格 | 依正确优先级取价，最后 Price unavailable；旧 Offering 不算新 Resolver 通过 |
| T62 · MD-04 | 卡种与合同测试数据 | Insurance 切 Corporate／Staff；选错类型／空合同／正确合同 | 不兼容来源清除；错误拒绝，正确互斥保存；患者实例不复制合同规则 |
| T63 · MD-04 | 有权限及无权限用户 | 上传合规卡图，再测超 5 MB、错误格式与未授权读取 | 合规可用，错误拒绝；私有卡图不能凭地址绕权限；空目录无 Demo 卡 |
| T64 · MD-05／MD-06 | 导入模板与有错数据 | 上传重复／错字段、查看预校验、导入 Draft、发布／停用 | 逐行错误可知；不自动发布；无底表不模拟成功；保险卡无批量导入 |
| T65 · MD-05 | Coupon／Contract 有效 | 默认叠加，再设明确 Stackable 并按规则使用 | 默认不叠加；核销／撤销须真实联动，否则 Blocked |
| T66 · AI-01／AI-02 | AI 测试 Provider | 超时、失败、无权限、切患者、候选采纳 | 人工输入保留、不伪造成功；只有明确采纳才写原模块；无上下文不发送患者数据 |
| T67 · AI-03 | 已批准与未批准知识资料 | 非管理员上传；管理员提交未发布；治理发布／停用 | 非授权拒绝，未发布不用于正式检索；来源版本可追踪 |
| T68 · AD-01～AD-03／AC-01～AC-03 | 同角色多诊所、不同单角色用户 | 同角色用户换 Clinic／Membership；分别登录护士（含 Cashier 操作）、医生、药房与后台 Finance 用户访问／写入 | 符合真实权限；只读模拟明确，不能据此误判真实角色；不默认恢复 Delegation |
| T69 · AU-01～AU-04／CT-04 | 已产生更正／付款／签署事件 | 查 actor／reason／前后版本；尝试越权读差异与导出 | 可追溯且按权限脱敏；导出审批未定则 Blocked，不默认全量可导 |
| T70 · PL-01～PL-03／CT-05～CT-06 | 原生／迁移及接口错误 | 看迁移标识／附件来源，断接口、空目录，读 Closed | 无示例 fallback，错误不同于无记录；Closed 只读；迁移完整度另核对 |
| T71 · AD-04～AD-07／PL-04 | 配置／移动入口 | 更新模板／资源，查看历史；打开移动只读目标 | 历史不被覆盖；未实现配置／移动功能标 Blocked；不能把 H5 当员工移动工作台 |

Integration SLA／Retry Worklist、完整 WDL、Period Close／经营报表及复杂 Benefit 管理界面为延期或排除，不要求测试人员补出“通过”；只检查入口与边界是否误导。

<a id="user-access-design-cases"></a>

### 6.1 用户配置与医生护士授权

依据 [用户配置与医生护士授权](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#user-access-design) 的整合设计；用户详情、主体上限、服务关系、固定记录授权及搜索已完成本地自动验证，具体覆盖见执行记录（仓库资料：../test_cases/access_control/user-configuration-20260910.md），不代表以下全部业务用例均已验收。未实现项记录 Not run 或 Blocked，UAT 另计。持续覆盖规则已于本轮评审确认，新增模式待开发；不沿用旧固定 Visit 的通过结果。

| 编号 | 场景 | 预期 |
|---|---|---|
| UA-CONT-01 | 医生选择固定记录／持续覆盖，分别设置查看和草稿编辑 | 固定模式不扩展到新增Visit；明确持续模式按Provider＋Clinic与关系匹配新增记录，未实现时记Blocked，不伪造生效 |
| UA-CONT-02 | 固定查看配持续编辑；跨Clinic／Provider；签署后尝试护士编辑 | 拒绝超出查看范围的编辑，拒绝跨来源扩权，护士始终不能最终签署或修改已签内容 |
| UA-CONT-03 | 旧固定授权、变更模式、撤权／调动后恢复、旧响应返回 | 旧授权不自动升级；范围变更保留新版本，失效关系和已终止授权不复活，旧响应不恢复无权正文 |
| CP-DELEGATE-01 | Staff获A诊所采购代办权，无B授权，也无患者发药权 | 保持Staff角色可执行获授A采购动作；B列表／详情／提交拒绝，患者审方／备药／发药拒绝，下单不自动获得收货权；新授权模型待开发 |
| CP-DELEGATE-02 | 代办授权到期、代办人与审批人为同一真实人员、旧窗口提交 | 失效后新操作拒绝，不能自批；历史单据和实际作者保留，不增配Pharmacy第二角色 |
| UA-01 | 新建护士账号并配置 A 岗位；选择本诊所指定多位医生 | 用户编码自动生成、账号默认无截止；岗位和服务范围在同一用户上下文保存，Clinic 自动带入，无重复 Source clinic 输入；不自动生成临床批准 |
| UA-02 | 医生 D 属于 A／B，护士只属于 A；从 UI 及直接 API 设置 B 服务／授权 | 候选不提供 B，服务端拒绝；管理员覆盖两诊所也不能代替护士主体归属 |
| UA-03 | 护士属于 A／B，只关联 A 下的 D；同患者有两诊所记录 | 只允许授权 A＋D；B 及他医受限正文不开放，公共资料按自身规则读取 |
| UA-04 | D 给护士查看，E 给同一护士查看＋编辑；角色移除编辑功能 | D／E 授权互不串用；编辑依赖查看；失去角色动作后编辑被拒绝，概览显示真实原因 |
| UA-05 | 医生保存授权；管理员从医生和护士两个详情查看 | 两处读取同一授权及历史，显示 Clinic、动作、记录范围和期限；管理员查看配置不获取临床正文，不可冒充医生开启授权 |
| UA-06 | 任职／主体／Provider／服务关系到期、撤销后恢复 | 对应受限授权停止；旧会话、固定记录授权及缓存不能绕过，已结束／撤销授权不自动复活 |
| UA-07 | 整诊所切指定医生，或设置未来切换；撤销最后一位医生 | 影响预览准确；未来生效不提前结束旧范围，未实现定时能力时不提供假支持；空范围不恢复整诊所 |
| UA-08 | 护士编辑草稿、已签署及 Closed 记录，尝试最终开单／签署 | 仅支持且获批的草稿动作可保存，实际编辑者保留；正式记录、签署、最终开单继续按医生及状态规则拒绝 |
| UA-09 | 从指定用户进入申请中心；切用户／Clinic 时有未保存输入及迟到响应 | 携带并展示筛选，保护未保存内容；旧响应不能恢复旧人／旧范围；清除筛选需显式操作 |
| UA-10 | 桌面宽／窄视窗打开表单、日期／时间选择和 Action 按钮，键盘完成操作 | 使用现有 Element Plus 及 AppDialog，主题一致，弹层无遮挡，错误关联字段，loading 防重复提交；蒙版不丢弃草稿 |
| UA-11 | 固定既有记录授权后新增 Visit，或从旧入口重新请求 | 固定授权不自动纳入新记录；持续覆盖须另行明确选择并有效实施；新旧入口遵守同一主体与撤权边界 |
| UA-12 | 主体／权限撤销与编辑保存并发，上层截止早于子授权截止 | 事务复核并留证，撤权先提交则拒绝保存；不合法时间窗拒绝保存，概览给出期限限制来源 |
| UA-13 | 多人服务／审批范围列表输入姓名、用户编号或邮箱，继续分页，再清空搜索 | 分页前按当前权限匹配人员，包含有效和历史范围；搜索不扩大数据权限，不因只过滤已加载记录漏项；无匹配有明确空态，清空恢复列表 |

### 6.2 数据分类与岗位边界验收

依据 [Platform §3](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix) 的 2026-09-14 用户确认及后续前台修正。以下是新增验收定义，**尚未执行**；旧用例／历史通过记录不证明新权限已生效。正向与拒绝场景均检查列表、直接 API、搜索、缓存及实际持久化结果。

| 编号 | 场景 | 预期 |
|---|---|---|
| PERM-01 | 同集团但与患者无关联 Clinic 的账号，分别具备／不具备基础查询权；再换另一集团 | 同集团具查询权可检索并查看非敏感基础字段，无需 Visit／接收批准；无权限与跨集团均拒绝 |
| PERM-02 | 前台有基础维护动作，在关联诊所修改姓名／联系方式并确认；在无关联诊所重复，随后取得有效接收批准 | 关联／有效接收范围可修改确认并留版本；无资格拒绝，普通预约 Confirmed 不代替批准；前台仅能维护基础字段 |
| PERM-03 | 搜索、患者详情、审核、历史中查看敏感字段，申请／取消／待批／获准／到期／撤销及旧响应 | 默认不返回明文；申请时提示操作者、患者、字段、时间、用途和结果将留审计；确认提示不自动获批；仅有效独立授权可读，取消和失效保持隐藏；保存其他字段不清空隐藏值 |
| PERM-04 | 同一 Doctor／Nurse 先只有基础查询权，再由角色模板授予公共医疗读取，随后撤销 | 仅获独立角色能力时显示公共索引、诊断／药物摘要、安全资料、疫苗及生命体征；不需原医生逐记录审批，不开放完整正文；撤权后新请求和迟到响应均不泄露 |
| PERM-05 | 医生 D 在 A／B，各有不同护士；A 护士有服务关系但无临床授权 | 可按动作管理 A＋D 日程、签到、本次附件和付款；不能处理 B＋D、A 内未服务医生或其受限正文；清空服务关系不能回退全诊所 |
| PERM-06 | 护士对本次及历史 Note、诊断详情、检查结果、正式临床文档分别无授权／查看授权／草稿编辑授权 | 无授权拒绝正文；查看仅对应批准范围；编辑另需角色动作和医生编辑授权且模块及状态允许；护士不能最终签署或直接改已签版本 |
| PERM-07 | 固定记录授权与持续覆盖授权、新增 Visit、医生／Clinic 变更、关系撤销后恢复 | 固定范围不自动新增；明确持续范围按来源和关系动态判断；失效即停止，已结束／撤销授权不自动恢复；未实施模式不伪造成功 |
| PERM-08 | 关联护士无临床授权上传、查看、删除本次附件；访问历史附件、复制历史关联及已签引用 | 本次允许并保留删除审计；历史须原记录有效授权，复制不绕过；不能删除历史、已签版本或正式临床文档；前台拒绝附件操作 |
| PERM-09 | A 诊所药房读取与执行 A／B 处方，尝试修改临床药物与签署；护士查看处方 | A 的药房动作按权限和流程状态允许，B 拒绝；药房不能开立／修改／签署临床处方；护士按医生授权查看，医生保留处方职责 |
| PERM-10 | 前台创建／确认预约及基础资料；直接请求签到、护理、医疗／安全或保险计划写入、附件和 Cashier | 授权范围内预约与基础资料操作允许；其他动作拒绝，隐藏入口和 API 一致；整体 H5 审核不能由基础资料维护权取得 |
| PERM-11 | 配置角色和恢复旧布局，关联护士、无服务关系护士、前台及只读医生使用 Cashier | Cashier 不作为独立可分配角色；现场财务写入仅关联护士及有效动作允许；其他身份不能借历史模板／链接写入；后台财务职责与只读报告保持各自范围 |
| PERM-12 | D2 仅确认患者详情或敏感审计提示后读取 D1 的完整处方／问诊记录，再取得明确记录授权 | 前者拒绝，提示与审计不替代授权；获批仅可读取明确范围，不产生 D1 日程、代诊或签署权；公共摘要继续单独判断 |

## 7. 结果记录与判定

| Run ID | 用例 | 环境／版本 | 角色／诊所 | Patient／Visit／业务编号 | 实际结果 | Pass／Fail／Blocked／Not run | 证据／缺陷／责任人 |
|---|---|---|---|---|---|---|---|
| 执行时填写 | 例如 T43 | 执行时填写 | 执行时填写 | 合成数据编号 | 不预填成功 | Not run | 执行后补 |

- **Pass：** 所列步骤和预期均有证据；涉及持久化、权限或跨岗位的用例必须查真实保存及下一岗位结果。
- **Fail：** 功能已可执行，但观察与该版本适用规则不符，附复现步骤和影响。
- **Blocked：** 缺环境／配置／实现／权限／规则，写清缺什么及谁处理；不是 Pass。
- **Not run：** 未执行，不能根据源码或页面截图填通过。

对 Consultation 已明确的当前实现差异，同时保留“当前回归结果”和“目标需求缺口”；不要用回归符合现状抹掉目标缺陷。

## 2026-09-03 药房最终确认补充用例

以下为待执行验收规范，不是本轮已执行的应用测试。

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T80 | 首次审核前尝试只收问诊费 | 允许预核对，禁止提前收款；药费等待药房确认 |
| T81 | 多药任一项未勾选或供应不足 | 不通过整张审核，不部分预留成功并放行收费；问题整单退回医生 |
| T82 | 预留满24小时、再超过24小时，均未结算 | 满24小时不提前释放；超过后释放、恢复待药房确认并阻断收费；重复任务幂等 |
| T83 | 已结算后超过24小时未领取 | 不自动释放／取消；继续待发药，Encounter 不得 Closed |
| T84 | Cashier 因患者不要药退回 | 立即停止执行并释放全部预留；显示撤回待医生，不能伪造临床取消 |
| T85 | 医生全部取消；另一例仅取消一项 | 全部取消无药房重审，Cashier 核对剩余费用；部分取消新版本重审／预留通过再恢复结账 |
| T86 | 所有药房操作人员未结算改某行单价，空原因、零价、负数分别提交 | 原因必填；零价允许；负数拒绝；自动重算当前处方，不改数量、标准价或他单 |
| T87 | 同一行连续改价，管理人员逐条处理 | 每次保留前后价格、原因、用户、时间和版本；管理有处理结论，无前置审批 |
| T88 | 已结算后直接改价、改价后旧 Cashier 页面收款 | 前者拒绝；后者要求读取并确认新费用版本，不用旧价落账 |
| T89 | 整次应收0，Cashier尚未确认／确认零额结算 | 前者不可备药；确认后放行，无实际收款流水 |
| T90 | 自付已结清，第三方责任未确认／已确认并由 Cashier 确认安排 | 前者不可备药；后者可备药，第三方未到账保持 AR |
| T91 | 逐项实物复核发现装药或标签错误 | 回备药中，记录原因并重新复核；不退医生或重收费用 |
| T92 | 仅部分药品备好／复核；另例全部完成后代领 | 部分不可整单交付；全部完成允许代领，仅一条代领记录及操作人／时间 |
| T93 | 查看跨日未完成、已取消、已发和Superseded记录 | 前者默认持续可见，后三类在历史；一处方一条队列 |
| T94 | 待发药跨过首次签署24小时，然后实际发药且其他条件满足 | 之前不Closed；之后按原时钟及其他条件关闭，不从发药重新计24小时 |
| T95 | 已发药后的退换请求 | 人工处理，保存异常及结果；不自动退库、退款、删付款或重开Closed |
| T96 | 预留释放与结算、改价与结算并发 | 仅与有效处方／费用／预留一致的操作成功，不超占、不按旧金额收费 |
| T97 | 多诊所各有不同医生开具的待办与历史订单；切换 All clinics／单一诊所并搜索诊所或医生 | 右上角 Clinic 下拉选项数量随 Active／History 范围正确，不占独立诊所行；键盘可切换；队列和详情明确显示处方所属诊所与开方医生；切换后旧诊所订单不可继续操作；诊所以 Visit Operating Unit ID 筛选，不按重名文本误归类 |
| T98 | 药师从一张待审订单打开 Consultation result，并从同一订单打开 eMMS | Consultation 直接读取该 Visit 的完成结果并定位 Prescriptions，不进入或启动 Consultation Queue；普通药房只读；eMMS 收到当前签署版本的稳定药品标识、Dose、Route、Frequency、Duration 和数量 |
| T99 | 同一处方依次进入 Review、Label、Preparation、Final check & handover | Review 只审已签署处方并仅有 Approve／Return；Label 完整打印 Dose、Route、Frequency、Duration、How to take 和 Quantity；Preparation 自动带入签署资料且只要求批次、效期和实际数量等实物记录；Final 展示患者用药指导和交付核对，不在各阶段混入其他阶段表单 |
| T100 | 药房审核不通过并填写原因后退回整张处方；护士随后在 Cashier 处理 | 药房动作把当前整张处方置为异常并立即阻断发票生成、过账、收款及 Checkout，但 Visit 暂留 Ready for Cashier；Cashier 打开时弹出原因和阻断提示；只有护士明确点击 Return to Consultation 后 Visit 才进入 In consultation；两次动作分别留审计；医生重签后仍须新版本药房审核通过才解锁 |
| T101 | Review 打开三药处方，A／C 有不同药品备注、B 无备注，另有整张处方备注；再切换到无备注处方 | 按同一签署快照展示三药及各自用法／数量；A／C 的备注仅在各自卡片内，B 无备注区域；整张 Prescription remark 在药品列表外只出现一次；空备注隐藏，切换不残留；队列过滤不能截断快照药品列表，旧接口缺快照时明确说明只展示选中药品 |


## 2026-09-06 桌面 App 清理与 CP 权限用例

| 用例 | 操作 | 预期 |
|---|---|---|
| T102 | 分别打开通用预览、WDL Staff、WDL PIC 和诊所角色目录；搜索旧 Inventory／WDL；恢复含多个旧 CP ID 的布局 | 明确的合成预览只出现一个 Central Pharmacy；WDL Staff／PIC 和后台 Finance 仅在具备 CP 入口读取权限时显示并进入；Doctor（含 unrestricted 模拟）不显示 CP；缺权限、失去权限、无会话时桌面／搜索／移动直接链接／旧布局不能恢复入口；旧 CP ID 归一并去重；已移除壳不在 More、搜索、移动目录或快捷操作恢复。保留 Consultation、Drug Dispensing、Cashier 等现有流程 |
| T103 | 使用不同真实会话权限进入 CP；分别尝试读、创建、提交、审批和发送；取消发送提示；模拟 PO 读取失败并切换身份 | 按 cp.* 有效权限请求及执行；PIC 不隐含创建权限；受限支持不可写；取消发送不调用 API；无 PO read 不读取；读取失败明确提示而非空单；身份变化清除旧记录且旧异步读结果不回填。公开无会话预览提示访问不可用 |

T102–T103 覆盖入口与既有动作授权，不能证明 2026-09-09 新确认的 CP 流程已经通过。完整目标断言统一见 [CP PRD §8](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html)：含两级审批、批次／效期、单位换算、来源库存、收发／回收、数量对账及并发更正；09-09反例复核补充取消释放分配、盘亏侵入预留、整包装不足、多批次发药、付款后来源恢复、往返退供应商及对账唯一归属。Clinic Pharmacy 读取本诊所及 CP 数量的受限视图，不改变 T102 的 CP 管理 App 角色边界；其他诊所分项／合计、占用对象、采购资料、直链及导出越权均按 CP PRD §10.2 验证。09-09新增诊所自采目标同见CP PRD §8：先PIC单审后发送／自行收货、所属clinic与单位／批次校验、批准版本及改价新单、直接来源排除CP结算、另行退CP例外和拒收回流不误作CP再供；采购快照按本单授权可见，不改变CP只读数量投影的商业资料隔离。以上新增目标尚未执行应用验收。

上述为验收设计。定向前端测试与静态预览验证应单独记录，不代替真实角色会话、后台集成或 UAT。


## 2026-09-06 Cashier 三页与交易回归用例

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T104 | Checkout Queue 搜索跨日待办、分页、选择 Visit、Post、刷新恢复、拆分实收 | 费用绑定同一来源版本；恢复原发票；拆分合计一次性结清，重复请求不多收 |
| T105 | 药房未审／退回／Hold／预留到期／更换版本时用旧 Cashier 页面收款 | 服务端拒绝；不出现部分付款；护士退回独立审计，原医生重签后当前新版本仍须审核 |
| T106 | 实收、零额和第三方安排三类结算后分别尝试药房备药 | 三类明确确认后放行；零额无虚假 Payment，第三方 AR 保留；未确认及旧版本拒绝 |
| T107 | 历史按患者／Invoice／Receipt／日期搜索，Closed Visit 补收应收 | 仅当前诊所可见，补收不超过各付款方责任；不重开临床记录 |
| T108 | 重复退款、超额退款、无权限、服务退款和付款纠正 | 原收款保留；重复只一次、超额及越权拒绝；服务退款另建 Credit Note，付款纠正重新形成欠款并阻止未完成药房执行 |
| T109 | 从 Cashier 右上角 Settings 进入票据配置，读取既有模板并复制修改；返回原工作页、重印旧发票及 Receipt | 主导航不含模板 Tab；返回保留原条件，双向切换保护未保存内容／保存中状态，旧模板启动目标转入设置。复用既有表与记录、标准只读、按原维护权限保存新版本；旧票据快照不变，重印无新收款、草稿与Void明确、退款与Credit可追溯 |
| T110 | 无真实库存接口、未启用人工证据配置、伪造已审核标记 | 不因页面状态放行；只有经授权启用且完整当前版本证据可进入合成测试流程，不能宣称自动库存已打通 |

以上为验收规范；执行版本、环境及结果单独记录。日结、自动库存与生产UAT不在合成回归通过范围内。


## 2026-09-06 药房队列主动刷新

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T111 | 打开 Drug Dispensing，医生新增处方／Cashier 确认支付后保持页面可见；再点击 Refresh | 打开即加载，此后每 30 秒更新队列和支付／结算状态；手动立即触发，显示刷新中和最近成功时间；请求不重叠 |
| T112 | 保持诊所／状态／搜索筛选和选中订单，录入备药信息或退回说明后自动／手动刷新 | 普通刷新不清空输入或抢占选择；当前诊所无单保留其筛选选项；阶段／签署版本改变则关闭过时确认并提示重新核对 |
| T113 | 刷新断网、恢复；查询进行中提交审核／退回；隐藏／恢复页面并关闭工作台 | 失败保留旧数据和成功时间、提示并重试；旧查询不覆盖新状态；隐藏暂停、恢复立即查询、关闭后无轮询及迟到响应应用 |

前端模拟接口、组件与浏览器验证范围见本轮发布记录；不视为真实临床后台 UAT。


## 2026-09-07 角色场景、统一 Billing & Insurance 与 Finance 权限

以下为新确认规则的验收设计，尚未执行；不得用旧角色或公开无会话预览宣称通过。

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T114 | 后台角色从后台打开 Clinic A 的账单／业务任务；CP 在 WDL 处理该诊所供货单；CP Staff 保持 Staff 角色，按限定采购授权替 Clinic A 提交诊所 PO，尝试未授权 Clinic B；从 WDL 尝试直接执行患者发药 | 后台财务与 WDL 仓库任务保持各自场景及源单据关系；诊所 PO 归获授权目标 Clinic，代办不增配 Pharmacy 角色、不授患者发药；采购动作与诊所范围分别限制，未授权 Clinic B 拒绝；患者发药在诊所 Drug Dispensing；审计保留真实登录人、有效角色／单位及来源对象。09-10 评审更新代办目标，新授权模型待开发，旧切角色回归不证明通过 |
| T115 | 查看角色列表，以迁移后的原 Billing 和 Insurance 账号进入同一团队工作；恢复旧布局并查看旧审计 | 统一显示 Billing & Insurance；后台岗位保持后台场景；旧账号关系、任务与审计可追溯，无孤立账户、重复权限或因合并获得 Finance／临床签署权限 |
| T116 | Finance 在后台查看、维护获授权的 Clinic 与 WDL／CP 价格，再重印历史账单／查看既有采购快照 | 维护可实际保存授权的价格变更，遵守生效、版本与审计；历史快照不改写；越权价格域与无权操作拒绝；Clinic 不列后台 Finance |
| T117 | Finance 从后台关联的 Clinic 与 WDL／CP 业务中查找患者附件，尝试另一未授权患者附件链接和附件修改 | 授权附件可查询／打开，复用原文件且保留来源关系与访问审计；未授权文件及未获准的附件修改拒绝；不为附件查询开放完整临床正文 |
| T118 | Finance 按日期／授权诊所查看真实日结报告，遇到未生成报告，再尝试执行日结或修改结果 | 查看真实报告与状态；未生成／不可用明确显示；仅查看权限不能关账、重开或改结果。新 Cashier 的诊所／医生报表按 Cashier §6.1 及本页 Day-end 用例验证；Finance 独立最小报表权限与完整跨诊所授权仍待实施，不能以复用现有 billing.checkout 视为本条全部通过 |

## 2026-09-07 Cashier 界面与单价编辑

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T119 | 在 1280px、1366×768 打开 Cashier 队列、Visit、历史、Day-end 及右上角票据设置 | 三个日常入口使用紧凑顶部切换，Settings 独立靠右；无旧常驻模块侧栏。配置页有明确返回操作；表格、患者和状态层级与 Consultation 一致；关键费用列可见；详情初始及滚动到底部后，当前阶段的关键金额和唯一主操作仍在可视范围内；开票／收款确认金额突出 |
| T120 | 修改有效收费行单价为 420.25，填写原因，取消／保存后刷新；编辑中切换 Visit 或 Tab | 取消不改数据；保存后新总额持久化且保留原价、原因和操作者；未保存编辑受到保护；二次改价失焦、Keep editing 和 Review/back 后输入与重算金额一致；固定金额区显示未保存新旧总额，开票／收款动作暂停；数量、签署快照和目录标准价不变 |
| T121 | 已 Post 但无付款／结算的 Invoice 再改价，然后开新票并收款 | 保存前明确旧票作废；旧 Invoice 和金额快照保留，重新 Post 才可按新版本收款；没有自动重开票或重复付款 |
| T122 | 改为 0、负数、超精度、空值；存在百分比、固定减额或固定净额折扣 | 零价可用于无冲突规则的收费行；负数／空值／超精度拒绝；保留并正确重算原折扣规则，冲突明确拒绝而非暗中清除折扣 |
| T123 | 两窗口同时改价，重试同一请求；跨诊所、无权限、已实收／零额结算／已退款撤销后请求改价 | 过时版本、越权与已有财务历史均拒绝；重复请求只生效一次；已签署临床记录、历史票据和原交易保持不变 |
| T124 | 药品改价后医生重签／更改药品或数量，再使用旧页面；在药房未审或预留无效时改价／收款 | 人工价不转移到不同临床收费依据；旧版本被拒绝，纯改价不绕过药房开票／结算门禁；当前发票、付款和药房费用显示使用同一有效金额 |

本节是验收规范；实际执行环境、覆盖情况及结果另见 Cashier 验证记录。


## 2026-09-07 药房紧凑布局

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T125 | 药房右上角 Clinic 下拉切换／键盘恢复 All clinics；查看三药处方与无完整快照订单 | 不再显示独立诊所 Tab 行；选项名称／数量及筛选正确；队列仅姓名、医生、诊所、药品数和状态，三药显示 3 medicines，缺少完整快照时不伪造数量；完整药品信息在详情保留 |


## 2026-09-07 自填审核补充场景

| ID | 场景 | 预期 |
|---|---|---|
| T126 | 1920／1366×768／1280 及 App 窗口缩至 720／480px | 审核填满可用区，列表／详情重排，正文和固定动作可达，无整页横向裁剪 |
| T127 | 患者核对已有记录／新患者／匹配失败，确认后再改证件 | 未确认不能提交；已确认关联只显示一次；身份实质变化使凭据失效；匹配失败不可冒充新患者通过 |
| T128 | 自填保险／企业／Staff 个人卡号、保单号和日期，或跳过 | 患者核对页和审核完整展示；选择计划后编号必填，日期不能倒置；空目录不回填样例 |
| T129 | 护士修改 Email／卡号，空原因保存，取消，保存后关闭再开审核 | 空原因拒绝；取消需确认且不写；保存有原值／新值、原因、操作者／诊所／时间，原始提交不改 |
| T130 | 修改证件后批准；待澄清／拒绝无原因；批准后再次编辑 | 不得任意指定关联；护士核实并记录依据，系统重新匹配后才可批准；异常原因必填；已处理只读，历史仍可查 |

本组用例是产品验收规范。合成前端本地检查、CI 构建、预览发布和真实后端／UAT 分别记录，不因用例存在而视为通过。

## 2026-09-07 Cashier 医生筛选与药房工作台分责

| 编号 | 场景／动作 | 预期 |
|---|---|---|
| T131 | 当前诊所有超过一页的待 Checkout Visit，医生分布在不同页；组合医生、患者搜索、Ready／Blocked 状态并翻页 | 医生选项始终来自当前 Medical Group／Clinic 全部跨日待办，独立于搜索／状态／所选医生／页码；组合条件在统计和分页前应用，total 与所有匹配记录一致；选项不含患者资料，不泄露其他诊所或已完成记录 |
| T132 | 同一医生 ID 对应不同姓名、重名不同 ID、无 ID 的旧姓名、空姓名；选择并清除医生，提交无匹配及非法筛选键 | 优先按稳定 ID 分组与匹配，无 ID 才按去除首尾空白的旧姓名匹配；无 ID／姓名单列 Unassigned doctor，有 ID 缺名显示 Doctor #id；合法无匹配为空队列，非法值明确拒绝；选择／清除医生、改变状态及提交搜索回到第 1 页，清除医生保留其他条件，不自动扩大仍选中的空结果筛选 |
| T133 | 具有效服务关系与收费权限的 Nurse 在 Cashier 查看待审、审核通过、药房退回及已确认结算的 Visit | 药房状态、原因和收费门禁清楚；没有 Open Pharmacy 或其他启动 Drug Dispensing 的跨岗位按钮；Cashier 不执行审方、药签、备药或发药；护士已有 Return to Consultation 保留且单独记录 |
| T134 | Nurse／Reception 搜索 App、恢复含 Drug Dispensing 的旧布局、以缓存 App 对象／ID 启动；另从 Pharmacy 切为 Nurse／Reception | 药房 App 不显示、不恢复、不启动；切换后原药房窗口移除，仍获授权的窗口保留且焦点有效；Pharmacy 及其他既有获授权角色入口保留。此次只验证前端工作台边界，不能据此断言后端历史 pharmacy.dispense 权限已迁移 |
| T135 | 使用独立真实会话：护士处理 Cashier，隔离数据库合成 Pharmacy 操作员审核／记录预留／打印药签／备药，另一位 PHARM-CHLOE 最终复核交付；另例药房退回后护士回退 Consultation | 各动作由其工作台和实际登录身份完成，护士不借药房窗口代办；Cashier 的结算结果被药房读取，备药与最终复核人员不同，实际操作人审计可查；药房退回立即阻断收费，护士显式回退独立发生；合成身份不扩张真实种子用户权限 |

验证状态：本轮医生筛选、桌面目录／启动／角色切换及跨角色交接已在精确提交 `a8e8b802d3738f1e6ce025af9b3a274a2814ab94` 完成隔离回归；[CI 34091809502](https://github.com/virtus-medical-internal-private/ai-clip-cms/actions/runs/34091809502) 的后端、前端、浏览器与清理检查全部通过。T131–T135 以该运行的实际覆盖及环境作为回归证据，不能据此宣称生产权限迁移或业务验收完成；真实后端部署与业务 UAT 仍未完成。


## 2026-09-07 Payment Arrangement（T136–T141）

| 编号 | 验收场景 | 预期 |
|---|---|---|
| T136 | 新预约有默认保险／没有计划 | 均先待确认；上层仅待确认、自费、保险及福利计划三个选择 |
| T137 | 一个列表选保险／企业／员工计划 | 展示对应类型及个人信息，后端保存正确类型和来源；他人计划／错误类型拒绝 |
| T138 | 保存、重开、重复点击、换计划 | 本次选择与信息准确恢复；重复点击保留，换计划清旧信息；新录入信息绑定当前计划 |
| T139 | 待确认签到及准备 | 可以签到／保存准备，Ready 被前后端阻断；确认自费或有效且已核验的计划后可继续 |
| T140 | 取消确认、变更安排、再次签到 | 重用原 Visit 并更新当前付款快照；不显示旧方式，不丢失历史审计 |
| T141 | 已 Ready／问诊／存在账单 | 普通预约／登记付款变更被拒绝；Cashier只读交接，不自动改变患者／第三方金额 |


## 2026-09-07 患者计划维护对齐（T142–T143）

| 编号 | 场景 | 预期 |
|---|---|---|
| T142 | 打开患者资料维护及 Overview，分别查看保险、企业和员工计划 | 统一 Insurance & Benefit Programmes；类型标签正确；机构、个人编号及保单／计划号按类型命名；Patient default 不成为预约自动选择 |
| T143 | 切换计划、重复选择、保存再读回 | 新计划清旧个人编号／日期／备注；同计划保留；企业／员工类型及来源保留，包括旧无目录 ID 的持有记录；历史预约快照不被覆盖 |


## 2026-09-07 人工计划审核（T144–T147）

| 编号 | 场景 | 预期 |
|---|---|---|
| T144 | Appointment／Check-in 打开人工审核；不勾选完整核对项或未选择资格／申请结果即确认 | 明确提示；旧自动 Check 入口移除；Checked 字符串不能放行准备 |
| T145 | 人工核对完整但资格待确认／不合资格，或申请待批／未确认 | 可以保存及签到，重开保留结果和备注；准备交接被前后端阻断 |
| T146 | 人工确认合资格且无需申请，或已获批并提供凭据；保存、签到、重开 | 保存认证审核人及时间，绑定计划和日期；已获批缺凭据拒绝；有效记录随 Appointment → Visit 传递并允许准备交接；不能伪造审核人／时间，不自动产生财务责任 |
| T147 | 审核后更换患者／计划或就诊日期；重复保存同一范围 | 变更后重新审核，旧审核不能套用；同范围保留原审核；Visit 使用服务器就诊日期，客户端伪造日期拒绝 |


## 2026-09-08 默认问诊费（T148–T150）

| 编号 | 场景 | 预期结果 |
|---|---|---|
| T148 | 普通 Consultation 未绑定收费项目；打开 Billing、保存临床资料并完成交接 | 显示 Default consultation price HKD 1,000.00；保存来源版本并进入 Ready for Cashier，签署快照与交接金额一致；其他临床门禁仍执行 |
| T149 | 已有有效 HKD 480 或明确 HKD 0；或绑定失效／外币项目；另有缺价药品／检查 | 有效价格原样优先；错误绑定及其他收费缺价仍阻断，不能被 HKD 1,000 掩盖 |
| T150 | 旧活动缺价草稿重新读取；随后绑定专属价；签署后更改目录 | 旧草稿恢复默认价且递增版本；专属价变化使旧确认失效；已签署金额及来源版本不被重算 |

## 2026-09-08 医生问诊归属补充验收

| 编号 | 操作 | 预期 |
|---|---|---|
| CQ-ACCESS-01 | 同诊所 D1、D2 使用相同显示名称，分别登录 | 各自只见自己的 Active / Carry-over / History；更改或省略 doctor_name 不扩大范围 |
| CQ-ACCESS-02 | D1 未获 D2 受限记录授权，分别请求完整 Note／Prescription、公共 Service Selection 及 Start／签署 | 受限正文与无权动作拒绝；公共项目按同集团及独立角色读取授权返回，不因来源医生不同一律403。其他业务对象按各自权限，不能因公共读取取得写权 |
| CQ-ACCESS-03 | 从 Patient eMR 查询包含 D1/D2 问诊的患者历史 | 公共索引、诊断／药名摘要按集团范围及独立公共医疗信息角色授权返回；无授权的 D2 完整正文不返回。公共统计不只计算本人病历，也不从无权正文搜索泄露内容 |
| CQ-ACCESS-04 | 模拟 Doctor 选择 D1，打开患者资料或历史抽屉，再切换到 D2 | 按选定 Provider 限制范围；清空旧工作区和人数，关闭旧资料编辑器、历史抽屉及修订弹窗并清除旧输入；旧队列、保存或修订响应不得恢复旧患者 |
| CQ-ACCESS-05 | Provider 缺失、患者未分配、归属字段冲突或授权过期 | 不按姓名猜测，不返回全诊所或合成队列；拒绝无权详情 |
| CQ-ACCESS-06 | D1 获得 D2 Visit 的正式限时代诊授权 | 有效期内可见及打开；授权到期后队列排除并拒绝重新访问 |
| CQ-ACCESS-07 | 护士具有A／B有效岗位、对应服务关系及授权，打开队列、公共摘要和受限病历 | 运营队列、集团公共资料和受限正文分别按范围判定；有B有效关系及授权可读相应B记录，无授权不可读，不用一律禁止跨诊所替代分类权限 |

自动验证证据另见 `agent_docs/test_cases/consultation/doctor-access-20260908.md`；上述用例定义不代表已部署或 UAT 通过。


## 2026-09-08 药房测试库存

| 编号 | 操作 | 预期 |
|---|---|---|
| PH-TEST-STOCK-01 | STG 显式启用测试库存并打开配置药品处方 | 显示测试确认，药师必须审核整张处方；免填人工库存依据，保存当前版本、药品、操作者、时间与测试来源 |
| PH-TEST-STOCK-02 | 审核后尚未结算即尝试 Label／Prepare／Handover | 继续阻断；仍须 Cashier 一次性确认结算与原实物检查 |
| PH-TEST-STOCK-03 | 缺省、关闭开关、生产／UAT，或请求伪造测试启用 | 拒绝测试确认；已有测试证据不被当作正式库存，即使曾测试结算也失效 |
| PH-TEST-STOCK-04 | 使用缺失药品主档、不同签署版本／药品／数量，或等待超 24 小时后未结算 | 拒绝缺失／不一致药品，过期需要重新审核；退回、暂缓和重签仍释放／隔离原记录 |


## 2026-09-07 工作场景角色入口

| ID | 场景 | 预期 |
|---|---|---|
| ROLE-01 | 用户选择唯一角色；添加不兼容该角色的主体 | 主体必须支持用户唯一角色；不得为添加主体另选角色或静默替换用户角色；后台合并 Billing & Insurance，WDL 仅 Staff／PIC，Finance 只在后台；提交接口同样拒绝非法组合（用户级一致性待实施） |
| ROLE-02 | 旧 Insurance／Billing 账号查看身份和权限；旧 Clinic 绑定后台账号登录 | 统一团队显示及有效权限，保留历史角色／Membership ID 和来源诊所范围，工作场景显示 Back Office，不扩大对象数据范围 |
| ROLE-03 | Finance 在后台查看 WDL／CP 价格／PO，再尝试库存写入、价格快照或 PO 审批／发送 | 查询按已有权限，所有未授权写操作拒绝；Staff／PIC 原有授权保持；restricted 模拟不能写仓库 |

本组为验收规范；实际自动化覆盖、执行环境和发布结果见角色场景验证记录。


## 2026-09-08 Finance 统一后台

| 编号 | 操作 | 预期 |
|---|---|---|
| FIN-BO-01 | 在 Clinic／WDL／后台选择 Finance，或直接构造 WDL＋Finance 请求 | 仅后台可选 Finance；新建／模拟 WDL＋Finance 拒绝；WDL 仅 Staff／PIC |
| FIN-BO-02 | 旧 WDL Finance Membership 登录并打开关联 CP 查询 | 显示 Back Office，原 Membership／WDL 业务范围不迁移、不扩大；仍按服务端权限处理 |
| FIN-BO-03 | 后台 Finance 查看 Clinic 和 WDL／CP 财务记录并打开详情 | 保持后台身份，保留原单据／版本／来源；拒绝越权对象和未授权动作。完整跨单位授权待后端联调 |


## 诊所／医生 Day-end Revenue Report

2026-09-08 确认。只统计新 Cashier 账本，不按患者生成报表。规范及 DE-01–08 条件见 [Cashier §6.1](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#61-day-end-revenue-report)。

| 编号 | 场景 | 预期 |
|---|---|---|
| DE-AC-01 | 同诊所多医生、多行、拆分付款与不同币种 | 诊所、医生、来源和账单金额勾稽，收费不随付款笔数重复，币种独立 |
| DE-AC-02 | 草稿、零额、跨日到账／退款、Credit／Void | 草稿非收入；零额不造流水；资金及更正按事件日计，不重写原始账单事实 |
| DE-AC-03 | 无数据、无医生、同名医生、非法条件、伪造诊所 | 空结果明确，同名 ID 分开，越权和非法条件拒绝，不扩大范围 |
| DE-AC-04 | 改条件／角色／诊所时旧请求完成；导出及打印 | 旧结果不覆盖新范围，导出／打印与已生成报告一致，特殊文本安全 |

执行证据单独记录在 `agent_docs/test_cases/cashier/day-end-validation-20260908.md`；本表不是通过声明。

### 用户唯一角色回归（2026-09-10）

规则以 [Platform 用户角色唯一性](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#user-single-role) 为准；以下为目标验收，不能沿用旧测试通过结论。

| 编号 | 场景 | 预期／状态 |
|---|---|---|
| ROLE-04 | 同一用户在同一或不同 OU 同时配置 Doctor 和 Nurse | 均拒绝第二角色；不得借添加岗位静默替换。跨 OU 全局约束待实施 |
| ROLE-05 | 同一 Doctor 用户分配 A、B 两诊所 | 允许合法主体内同角色任职，各诊所数据范围独立；存量冲突不自动删历史 |
| ROLE-06 | 问答：给 user 授权时，Operating unit 一样，role 不一样，可以吗 | 明确不允许；引用唯一角色规则，区分目标规则与当前实现缺口，不以未禁止推断允许 |


### 护士核实自填身份（2026-09-14）

- 旧提交缺少身份确认、护士修正身份资料、待澄清及旧链接过期：由护士记录依据并核实，显示匹配结果后批准，全程无需患者重新提交。
- 核实历史显示真实护士、时间、依据及 Clinic，原始提交和患者 Consent 不变；空依据、无护士任职、跨 Clinic、无 patient.write、无主档维护资格、重复身份冲突及旧版本必须拒绝。
- 新／已有患者正常提交可直接审核；患者确实需补充时仍可澄清重发；终态不可重开，未提交空草稿不可核实。


---

# 实现状态、待确认事项与需求来源

更新：2026-09-14 · 本次权限修订仅更新 PRD；此前 09-10 PRD 评审核对开发分支 `69dd540` 与STG `4808516`；历史证据按各自版本理解。本轮仅文档评审及规则修订，未运行业务UAT。

本页服务于开发和测试准备。业务主线及各板块正文只保留功能、流程和判断条件，代码位置、实现差距及历史冲突集中在这里。

## 1. 文档覆盖范围

| 当前已设计板块 | 本轮 PRD 落点 | 覆盖内容 |
|---|---|---|
| 患者主档与纵向 eMR | 前台 PRD | 身份、安全、持卡、诊所关系、历史、附件与返回 |
| 患者 H5 与人工审核 | 前台 PRD | 预填、48 小时令牌、六步填报、保障、重复匹配与批准 |
| 预约、医生排班与资源 | 前台 PRD／目录及平台 PRD | 新建、确认、改约、取消、Block-out、多资源与冲突目标 |
| 到诊与护理 | 前台 PRD | Check-in、准备门禁、队列、回退及服务分流 |
| Consultation | Consultation PRD | 当前代码五模块、Note／AI Scribe、诊断、药品、Service、文档、收费／完成 |
| Clinical Reference／Anatomy | Consultation PRD | 患者资料、历史、附件、教学画布、Chit activity、布局 |
| Clinical Documents／独立 Worklist／模板 | 文档 PRD | 内嵌与独立入口、自动／显式保存、版本、签署、签发目标、模板 |
| Pharmacy | Pharmacy／V-Lab PRD | 签署即审核，整张审核及预留后才能统一结算；Cashier 确认后备药、实物复核和整单领取；退回／重审门禁 |
| 诊所库存、CP 药品与 WDL 边界 | Pharmacy／V-Lab PRD；[Central Pharmacy PRD](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html) | Pharmacy 维护临床交接；CP 维护采购、数量／单位、收发回收与权限设计，不改变原合同范围 |
| V-Lab／Imaging／外部 Vendor | Pharmacy／V-Lab PRD | 开单、承接、执行、结果、医生确认、人工外部收件 |
| Cashier／AR／保险回款 | Cashier／诊后 PRD | 费用、折扣、分摊、开票、付款、收据、冲正、回款分配、关闭 |
| Service Packages／Wallet | Pharmacy／V-Lab 及 Cashier PRD | 权益、预留／扣减／冲回、下游顺序及未决事项 |
| Tasks／Follow-up／Communication | Cashier／诊后 PRD | 回访、复诊、来源任务、负责人、结果及延期 SLA |
| Catalogue／价格／Coupon／Insurance Card | Catalogue PRD | 三个 App 的功能归属、价格与成本、来源互斥、批量导入与发布 |
| AI／知识库 | 平台与 AI PRD | 辅助输出、人工确认、失败、来源与治理 |
| 用户／组织／配置／Consent | 平台与 AI PRD | 上下文、职责、模拟、资源、模板、已确认的数据类别／读写矩阵及个别未决边界 |
| Audit／Access Review | 平台与 AI PRD | 事件、前后版本、复核与导出设计 |
| Integration Monitor／移动／迁移 | 平台与 AI PRD | 已有设计及延期界限、外部服务、历史只读与上线验证 |

2026-08-09 的 13 App 是旧信息架构建议，不作为当前 App 数量或所有功能已交付的证据。后续七种类型、患者级历史 Tab、Catalogue 独立管理与延期决策已纳入本版。

## 2. 当前实现分类

“已有基础”表示存在可核对代码；“部分实现”表示一部分目标缺失；“待开发”表示完整链路尚不足；“待业务确认”表示不能先定测试通过口径。所有分类均不表示已部署或 UAT。

| 范围 | 当前分类 | 测试可做什么／缺什么 |
|---|---|---|
| 患者搜索／三项建档／重复校验 | 已有基础 | 可安排 API 与业务回归；完整误匹配／合并 SOP 未定 |
| 主档修正／历史／诊所关系 | 已有基础＋部分实现 | 自动关系／版本有基础；手工关系治理、跨诊所矩阵与迁移完整度待验 |
| H5／审核 | 已有前后端基础，完整契约待验证 | 当前已有令牌、公开提交、员工审核及关联患者写入服务；重新确认／拒绝／待澄清、新建批准、Patient ID一致性及并发仍需专项核对，不能整体标为纯前端，也不能因此升级为闭环已验收 |
| Appointment／Check-in／回退 | 已有基础 | 需目标库迁移、并发与跨岗位实测 |
| 完整资源／多 Assignment／容量 | 部分实现／待开发 | 不能用 Room 名称多选代表完整资源模型 |
| 准备门禁／共享队列顺序 | 部分实现 | 身份门禁有基础；可配置准备项、跨终端手工顺序未完成 |
| Consultation 五模块／草稿／Note 版本 | 已有基础 | 当前源代码具备模块保存／后台保存与专用 Note 聚合；旧 WS2“缺持久化草稿”不宜再笼统套用全部 Note |
| 双标识主动核验／完整类型差异 | 部分实现／待开发 | 当前 trusted handoff 推断；原子完成只普通门诊 |
| Prescription／Pharmacy Handoff／Settlement | 已有基础＋部分实现 | 当前已有整张审核、库存证据、结算门禁及护士确认退回；真实库存分配、完整五阶段、逐药品审方与自动释放仍有缺口，见[药房实现矩阵](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html) |
| Pharmacy 角色分离／库存扣减 | 部分实现 | Checker 例外、权威库存／FEFO 与联动未完整验证 |
| Central Pharmacy 采购／库存／数量对账 | 部分基础；完整目标待开发 | 现有药品目录、PO 单级审批和查询不等于真实库存闭环；PIC → Finance、强制批次／效期、单位换算、来源层台账及收发回收、受限诊所数量视图、Finance 数量确认均见 [CP PRD §8／§12](https://virtus-patient-emr-prd.vercel.app/central-pharmacy.html)。09-09另补诊所自采PIC单审→直接采购→本诊所自行入库及后续独立退CP例外，设计已确认、尚待开发；全内部范围召回／冻结权限暂缓，基础召回及其余规则见CP PRD §6／§9；SOP、数据核对及代码实施仍待完成 |
| Service Selection | 已有基础 | 搜索、建议、复制、保存／签署；不代表内部检查执行 |
| V-Lab 结果闭环 | 待开发／未充分实现 | 完整接单→医生确认不可按已完成验收 |
| Clinical Documents | 已有基础＋部分实现 | 多页签、自动版本、草稿租约与原子签署路径；完整签发／作废／重发未完成 |
| Billing & Finish | 普通门诊已有基础 | 医生／Provider／coverage、版本、价格及事务校验；特殊类型、无收费跳过与目标复诊流程缺失 |
| Invoice／多笔付款 | 已有基础 | 实付余额及 Paid 更新可回归；跨模块联调待验 |
| 退款／Remittance／Allocation | 部分实现／待开发 | 完整财务更正、到账分配及审批待验／待定 |
| Catalogue／Insurance Card | 已有基础＋部分实现 | 现有表卡种与 Policy 可核对；新资源可用范围／Cost／Consultation Pricing 底表及 Resolver 待开发 |
| Package／统一任务 | 部分实现 | 有权益台账与专用任务基础，完整 Checkout／通用任务与通信待接通 |
| AI／权限／审计 | 部分实现；09-14 分类与岗位契约已确认、待实施核验 | 基础身份投影仍含敏感字段、公共疫苗读取仍复用 patient.read；新字段隐藏／申请审计、独立公共医疗角色授权、前台基础字段限制、本次／历史附件及护士 Cashier 范围需逐接口对照。见 [权限正文](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#access-matrix) 与 修订证据（仓库资料：../workflows/context/access-control/prd-permissions-20260914.md）；本轮未运行应用验收 |
| 用户配置与医生护士授权整合 | 已实现并通过本地定向集成验证；UAT 待验 | [用户配置与医生护士授权](https://virtus-patient-emr-prd.vercel.app/platform-ai.html#user-access-design)：用户详情、主体上限、护士医生关联原子保存、医生独立授权、管理员只读及 Element Plus／用户搜索已实现；完整权限诊断和处方草稿协作仍保留边界；持续记录覆盖已确认、待实施，见Platform §5.2，应用发布与 UAT 另计 |
| 自动 Closed／超时审批 | 待开发／未证明可运行 | Closed 拒绝重开有代码；不能据此声称定时关闭／24小时完整策略已通过 |
| Integration SLA／复杂 WDL／看板／现金盘点关账 | 延期／排除 | 不作为本期新交付承诺 |
| 诊所／医生 Day-end Revenue Report | 已实现，完整本地服务验证通过 | 规范见 [Cashier §6.1](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html#61-day-end-revenue-report)；部署、验证与发布见 执行记录（仓库资料：../test_cases/cashier/day-end-validation-20260908.md） |

## 3. Consultation 逐项代码依据

以下位置均相对于代码仓库；用于研发复核，不要求业务人员阅读。

| 结论 | 代码证据 |
|---|---|
| 五模块、后台保存、Review 清单 | `varclip_vue/src/components/desktop/apps/ConsultationFormPanel.vue`：`tabs`、`saveBeforeLeaving`、`selectTab`、`openReviewAndSign`、`confirmClinicalSignOff` |
| 当前以可信上游代替主动核验 | `ClinicalWorkspaceApp.vue`：`requestOpenVisit`／`enterVisit`；`utils/clinicalWorkspaceRules.mjs`：`isTrustedConsultationHandoff` |
| Note 模板、服务端保存与 Consent 门禁 | `consultation-workspace/ConsultationNotePanel.vue`：`saveNote`、`runWithAiScribeConsent`、`startRecording`、`generateDraft` |
| eMMS 非阻断、空处方／空 Selection 必须保存 | `utils/clinicalWorkspaceRules.mjs`：`buildSignOffChecks`；`services/billing_finish.py`：`_lock_prescription`、`_lock_service_selection` |
| 药品字段／Remark／修改版本 | `consultation-workspace/PrescriptionPanel.vue`；`varclip_flask/src/services/prescriptions.py` |
| Service 搜索／建议／复制／版本 | `consultation-workspace/ServiceSelectionPanel.vue`；`varclip_flask/src/services/service_selections.py` |
| 文档自动保存／活动工作台 | `ClinicalDocumentWorkspace.vue`；`clinical-documents-embedded-tab-workspace-refactor-prd_20260901.md` 及其 ADR |
| 普通类型与医生／Provider／coverage 门禁 | `varclip_flask/src/services/billing_finish.py`：`SUPPORTED_CONSULTATION_TYPES`、`_doctor_context`、`_visit_context`、`_active_provider_snapshot` |
| 同事务完成／固定复诊时间 | 同上：`review_complete`、`_create_follow_up`（09:00，30 分钟，Booked）；前端成功后 `return-to-queue` |
| 未确认结算／旧版本禁止发药 | `varclip_flask/src/services/clinic_workflow.py`：dispensing 状态变更检查；`prescriptions.py`：Payment exception／Superseded |
| Reference 与 Anatomy | `consultation-workspace/ConsultationInsightRail.vue`；`ClinicalWorkspaceApp.vue` |

## 4. 冲突收口

| 旧说法／历史资料 | 本版如何处理 |
|---|---|
| 付款前可 Label／Pack／Verify、药房退回 Encounter 不回退 | 2026-09-06 最终确认覆盖：先整单审方并预留，才能统一结算；Cashier 确认后才开始备药；药房退回先阻断 Cashier，护士在 Cashier 手动恢复 In Consultation，重新签署后再次审核及预留通过才解锁；局部门禁已开发，完整流程待联调 |
| 四类流程含 Telemedicine；Day Procedure 直接术前流程 | 使用七类 Type 与医生共享主干目标；当前特殊类型差距另标 |
| 新患者只需姓名和电话 | 当前基线／代码要求姓名＋主手机＋证件三项 |
| 统一诊所静态 QR | 2026-09-03 源 PRD 与 WS1 为预填 Intake Draft 绑定的患者专属48小时令牌，无 OTP；长期记忆旧条目不覆盖它 |
| 离开模块必须停住等待保存 | 当前 Consultation 非文档模块保护草稿并后台保存，不因失败阻断导航；最终完成仍检查同步 |
| eMMS 警示自动阻断完成 | 当前代码非阻断，临床安全规则需确认；不自动认定代码现状为已批准政策 |
| 不新增 AI Scribe Consent 门禁 | 当前存在显式门禁；如实记录，保留待确认决定 |
| Handoff 失败保留临床已签状态 | 当前原子 Review Complete 全部回滚；目标中间态未实现 |
| 完成后打开复诊表单 | 当前原子流程自动建 09:00／30 分钟 Booked 预约；明确登记与目标不符 |
| 已具备 Provider Delegation／一键 STG Test Run | 相关增量已回滚；不作为当前功能说明 |
| Lab 四页、Doctor + Clinic + Type 定价、Group Default Cost | 使用最新单页 Test Catalogue 与两套明确价格／成本优先级 |
| 保险未回款不能 Closed | 已确认 AR 独立，Cashier 可确认付款安排后放行备药；未领取仍阻止 Closed，其他条件满足后按首次签署 24 小时时钟关闭 |

## 5. 真正还需要决定的问题

| 编号 | 待确认内容 | 负责人角色 | 影响／确认前怎么测 |
|---|---|---|---|
| Q01 | 保留或修改当前 AI Scribe Consent 门禁 | 产品／临床／隐私 | 当前回归按代码；新政策验收 Blocked |
| Q02 | eMMS 严重程度、非阻断边界、Override 与数据覆盖 | 临床／药房 | 验证实际非阻断；临床放行验收 Blocked |
| Q03 | 已付后更正／差额执行与底层库存适配 | 医生／药房／Finance | 普通状态不增加付款后审方；已发后退换人工记录。全部取消免重审、部分取消重审、整单领取、代领备注及无配送已确认 |
| Q04 · 已确认 | 第三方责任存在时明确确认；患者自付已结清或全部余款已登记欠款，再由 Cashier 显式确认结算后备药 | Finance／药房 | 患者与第三方 AR 分开；零额结算亦需 Cashier 确认，不虚记实际到账；源码、完整本地验证及发布见 Cashier 本轮记录（仓库资料：../test_cases/cashier/copay-outstanding-20260910.md），目标环境与 UAT 独立验收 |
| Q05 | 无 Charge Event、No Consultation 的 Checkout／自动关闭触发 | 产品／营运／临床 | 不使用不存在的临床签署时间；对应闭环 Blocked |
| Q06 | 体检报告签署人、结果等待与异常转诊；各 Type delta | 临床／体检营运 | 特殊类型逐类验收，不能都用普通 Consultation |
| Q07 | V-Lab 首项检查、必要字段、危急阈值及责任时限 | V-Lab／医生 | 普通状态链可设计，阈值／SLA 不编造 |
| Q08 | 迟到／No-show、Walk-in 链接、资源容量与例外 | 前台／营运 | 不设自动取消分钟数；无资源后台不报通过 |
| Q09 | 退款／冲正审批、套餐／Benefit／自付应用顺序 | Finance／营运 | 基础记账可回归；复杂结算 Blocked |
| Q10 | 单角色整改、临时代诊职责、Consent 撤回及审计导出剩余边界 | 临床／业务／隐私 | 按现有授权回归，最终矩阵单独验收 |
| Q11 | 文档审批／签发／作废／重发与正式模板 | 临床／营运 | 草稿／打印／当前签署可回归，完整签发 Blocked |
| Q12 | 统一任务 Owner、完成口径和消息记录 | 营运／各 Line | 引用源对象；通用 SLA 按已决定延期 |
| Q13 · 已确认 | Staff保持唯一角色，按限定诊所采购动作代办；不授患者发药权 | Line C／WS6 | 目标见CP §4.1，新授权和入口待开发，不沿用旧切角色验收 |
| Q14 · 已确认 | 医生明确选择持续覆盖本人指定诊所新增记录，查看和草稿编辑分别授权 | Line B／WS6 | 固定及持续模式见Platform §5.2；旧固定授权不自动升级，新模式待开发 |

Q 项不是要求本轮用户逐一回答。它们使测试可以继续执行已明确部分，并将无法判定的场景准确交给相应负责人。

## 6. 来源与维护方式

业务规范来自已确认项目基线及领域PRD；代码与实际执行证据按领域核对，不再用单个旧提交代表所有当前功能。旧 `agent_docs/p0_mvp_workstream/` 已迁移至 `dev_working/workstreams/phase_0/`。当前职责、字段及规则在对应领域就地维护；历史决策与测试分别经仓库入口（仓库资料：../README.md）和执行证据（仓库资料：../test_cases/README.md）追溯。

## 7. Cashier 与 Pharmacy 实现边界

本节保留影响跨模块集成的工程边界；完整产品规则在 Cashier／Pharmacy PRD 维护。

| 范围 | 当前实现与边界 |
|---|---|
| 日常导航、票据设置与单次 Checkout | Checkout Queue、Billing History、Day-end Report 为日常入口；模板维护移至右上角 Settings，复用现有存储及权限，规则见 Cashier §2。队列按诊所分页，不再限当天／40条；Invoice 与 Payment 均从原 Visit 进入，收入报表见 Cashier §6.1 |
| 费用与结算 | 使用首次签署非药品收费快照及当前签署处方／药房价格版本；服务器核对版本、整单审核、预留证据与余额，原子处理拆分实收、零额确认、第三方责任安排 |
| 票据 | 新增诊所模板、版本及打印请求审计；Post／Payment 冻结模板；旧票据首次快照注明来源；配置不会改金额。打印机出纸、税务正式版式和外部支付通道未验证 |
| 历史／AR／纠正 | 关联原交易补收、退款记录、Credit Note、无实收 Void；跨诊所与权限检查；原临床 Closed 保持不可重开。第三方批量 Remittance／Allocation、第三方 Credit、正式退款审批尚不完整 |
| Consultation 回退 | 只有护士明确确认可退回；无实收发票受控作废；原签署快照保留。原医生处理处方 Amendment 后重新送审核。完整五模块重开、已付款处方差额变更尚未实现 |
| Pharmacy 交接 | 新审核版本、失败／Hold／到期阻断收款；结算确认才 Label／Pack，整单备好及实物核对后整单交付。成功收银不会自动标为已发药 |
| 库存 | 当前无与诊所处方对应的自动库存分配／扣减台账。人工预留证据能力仅供明确启用的场景；默认关闭，生产采用方式待用户确认。测试中的人工预留是合成事实，不证明实际库存被预留 |
| Package／Coupon／Eligibility | 本次读取已有权益资料；Cashier 核销、预留／扣减／冲回及复杂优惠叠加仍未形成完整事务，不以支付方式伪造兑换；第三方责任确认不是保险实时核赔 |
| 收尾 | 用户明确确认 Checkout Completed；自动满24小时 Closed 调度和后续任务仍有缺口。现金盘点关账／Period Close 继续排除；收入报告见 Cashier §6.1 |

真实 PostgreSQL／Flask 与浏览器脚本已纳入隔离测试流水线；实际执行结果写入 `agent_docs/test_cases/cashier/`，不能以已编写脚本或合成界面等同于通过。应用预览发布、后台环境部署、集成测试和业务 UAT 分别记录。


## 8. 近期变化的验证入口

| 范围 | 当前判断 | 详细证据 |
|---|---|---|
| Cashier 界面与本次改价 | 单次价格调整、作废未付款旧票再Post已有实现；不代表药房独立改价／管理队列已交付 | Cashier验证（仓库资料：../test_cases/cashier/validation-20260907.md） |
| Patient自填审核 | 响应式审核、患者确认关联、完整保障字段及带原因护士修正已有界面；当前已有正式令牌／提交／审核服务基础；完整重新确认及持久审计覆盖需按最新代码逐项验证 | Patient验证（仓库资料：../test_cases/patient_self_entry/validation-20260907.md） |
| Clinic与后台Finance | Clinic六现场角色、后台Finance、WDL Staff/PIC及旧membership兼容已有本地完整服务验证；价格写入、独立附件最小权限及完整跨单位授权仍有缺口 | 角色验证（仓库资料：../test_cases/role_workspaces/validation-20260908.md）；[组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html) |
| 默认问诊费 | 后端默认HKD1,000且保留有效已有价（包括零）和签署历史 | 收费验证（仓库资料：../test_cases/cashier/default-consultation-price-20260908.md） |
| 医生访问 | 查询与操作均校验当前Visit医生归属；正式限时代诊授权边界保留 | 访问验证（仓库资料：../test_cases/consultation/doctor-access-20260908.md） |
| 附件与OCR | 10MiB逐文件上传、保存与识别分开、完整结果及重试已有本地完整链路；外部OCR服务验收独立 | 附件验证（仓库资料：../test_cases/attachments/validation-20260908.md） |

以上不提升STG部署或UAT状态。文档治理规则和恢复来源见维护规则（仓库资料：../documentation_governance.md）。


---

# Central Pharmacy 内部管理产品设计

更新：2026-09-10 · 版本：v1.1 · 状态：已补齐诊所自采的 PIC 审批、直接采购与自行入库设计；全内部范围召回权限暂缓；SOP／数据核对与业务实施仍待完成。

责任：Line C / WS4；Central Pharmacy、WDL 采购、供应商和复杂库存由 Samuel 主责，NeosAI 支持；Finance、WS3、WS5、WS6、WS7 协同。

依据：`AI-CLIP_CP_WDL_Requirements2Sep2026.pdf` 调研、用户补充的 PO 说明、09-05/06 范围收敛，以及本次逐项确认。附件是业务来源，不自动构成交付或法规合规承诺。09-09 明确决定优先于旧文档及旧代码；本文不调整合同、报价或排期。

**本版取代旧稿的单层审批、批准后原 PO 改药改价、缺批次效期仍可验收，以及 CP 保持 WDL 身份处理患者发药的口径。** CP 自身供应商 PO 为 Staff → PIC → Finance；09-09新增确认的诊所自采只需 CP PIC 审批，获批后由诊所直接向供应商下单及自行入库；患者发药在 Clinic Drug Dispensing。旧 [v0.3 交互原型](https://virtus-patient-emr-prd.vercel.app/assets/central_pharmacy_20260906/index.html)仅保留历史演示与验证证据，不是本版流程的可执行实现。

## 功能地图

Orders 管单据，Inventory 管数量与实际移动，Master Data 管可复用定义。下列功能按这一架构展开，后半部分是页面与实施参考，不另设业务规则。

| 功能 | 使用者／业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 采购与收货 | Staff → PIC → Finance · Supplier PO | §3：三人分离、两级审批、人工发送、分批验收入库 |
| 诊所申领与自采 | Clinic Pharmacy／CP · Clinic PO | §4：向 CP 申领；自采由 PIC 单审后直接采购 |
| 库存与数量对账 | Staff／PIC／Finance · Movement | §5：余额、来源、耗用、结算纳入、盘点与开账 |
| 退换与召回 | Staff／PIC · Return／Recall | §6：原单上限、接收结果、例外审批及批次召回 |
| 药品单位 | 主数据维护者 · Conversion | §7：基本单位、录入换算、精度与历史快照 |
| 岗位、页面与数据追溯 | 各岗位 · 同一业务单据 | §10–14：权限、工作页、来源链；实施差距单独标注 |

## 1. 目标、范围和已确认决定

一个 CP 主存货地点向内部诊所供货。系统管理“申请多少、实际收到多少、存在哪里、还能使用多少、实际耗用多少、退回多少”，由人工决定与录入实际结果，系统计算数量并保留依据。

| 范围 | 已确认规则 |
|---|---|
| 组织 | 一个主要 CP 库存地点，其他为内部 clinic；不建设本期多仓库、多经营主体或外部客户供货流程 |
| CP 供应商采购 | Staff根据库存与申请建PO，PIC审核后Finance最终审批；提交人、PIC审核人、Finance审批人须为三位不同人员，双方通过后才可人工发送 |
| 发送登记 | 只录实际发送时间和收件人；不要求发送参考号、沟通附件或其他手工发送字段，不自动发送邮件 |
| CP 采购收货 | CP 人员选 PO，在同一任务中录入实收、现场验收与放行；**批次、效期必须明确才能验收** |
| 诊所向 CP 申领 | 诊所 Pharmacy 提交 PO；CP Staff 保持 Staff 角色，按明确授予的目标诊所采购动作代办提交，该单归目标诊所；不获得患者发药权限 |
| 诊所自采 | 09-09新增确认：诊所先提交自采 PO，经 CP PIC 单独审批同意后，诊所才能直接向供应商下单，并自行验收、入本诊所库存；不经过 Finance 采购审批；后续仍可按第三方退药例外交回 CP |
| 分发与实收 | CP 人员决定数量、批次、部分供应及余量，人工登记 clinic 实收；不强制在线签收或上传签收件 |
| 消耗与结算 | 发药与实际浪费／废弃共用耗用记录，Finance核对数量；09-09复核确认：诊所直接第三方采购并在诊所耗用的量单列、不计CP结算；CP赠品及第三方经CP再供后的耗用计入；患者实际回收扣减、再销毁计入；付款仍走现有财务流程 |
| 回收退换 | 09-09复核确认：接收方接受退药才算成功，实物移动独立登记；正常退药关联原实收。无CP原实收依据或诊所第三方采购退回，均由Staff申请例外、PIC审批后办理 |
| 盘点与召回 | Staff登记盘点数和原因，PIC批准后调账；PIC在已授权范围发起召回，Staff联系跟进并记录回收结果；09-09明确全内部范围召回／冻结权限先不考虑 |
| 开账 | 导入 CP 与 clinic 现有库存，由 CP Staff 核对确认；此后依业务流水计算余额 |
| 库存可见性 | Clinic Pharmacy 可看本诊所及 CP 的库存数量，不可看其他诊所库存数量；数量查看不附带 CP 管理或采购价格权限 |
| 主资料与接口 | 复用现有药品、机构、单位及供应来源；NetSuite 只预留接口与映射，不做实际同步、重试或自动对账 |

不增加独立经营看板、自动采购预测、复杂赠品计算引擎、自动付款或患者在 CP 取药流程。具体单位映射由底表和代码核对，不要求业务逐种回答包装换算。库存统一不等于所有用途按同一单价收费。

## 2. 功能架构和上下游全流程

保留一个 **Central Pharmacy** App，三个一级入口 **Orders / Inventory / Master Data**。Inventory 是库存业务的操作入口，Warehouse 是 CP 仓储工作的旧命名，不再建立第二套库存 App 或余额。Clinic Pharmacy 从自己的工作场景提交申请、查看授权数量；Finance 从后台处理同一张采购单及数量对账单。

```mermaid
flowchart TD
  M[共享药品、单位、供应商] --> P[CP 创建供应商 PO]
  P --> A[PIC 审核 → Finance 审批]
  A --> S[人工发送并登记时间、收件人]
  S --> R[分批收货：明确批次与效期]
  R --> C[CP 来源批次库存]
  Q[Clinic 向 CP 申领] --> D[CP 分配与实际发出]
  C --> D
  D --> T[在途]
  T --> K[CP 登记 Clinic 实收]
  K --> I[Clinic 来源批次库存]
  M --> DP[Clinic 创建自采 PO]
  DP --> DA[CP PIC 单级审批]
  DA --> DS[Clinic 人工向供应商下单并登记发送]
  DS --> DR[Clinic 自行验收：批次、效期、实收]
  DR --> DI[Clinic 第三方来源库存]
  DI --> U
  DI --> EX[单独退药例外：Staff → PIC]
  EX --> RT
  I --> U[Clinic 发药／实际废弃]
  U --> F[统一耗用 → 按来源纳入或排除 → Finance 数量确认]
  I --> RT[Clinic 退回：原实收或已批例外]
  RT --> C
  C --> SR[实际退供应商]
  C --> RC[PIC 批次召回／盘点审批]
  RC --> I
```

| 一级入口 | 二级工作对象 | 核心内容 |
|---|---|---|
| Orders | Supplier POs | CP 自身采购：下单、逐级审批、人工发送登记、多次收货、结束余量、作废及关联新单 |
| Orders | Clinic requests | 承接诊所 PO，查看申请、分配、发出、实收、在途差异和未满足量；Staff 代办按 §4.1 的明确范围进入，不以 WDL 身份自动取得所有诊所操作权 |
| Orders | Approvals | 按任务分采购 PIC 审核、采购 Finance 审批、诊所自采 PIC 审批、退药例外、盘点差异；审批同一业务对象，库存不因审批直接移动 |
| Inventory | Stock / Movements | 地点、药品、批次、来源层余额，可用／预留／不可用、在途、流水及耗用明细 |
| Inventory | Returns / Recalls / Stock counts | 退换实际结果、例外关联、批次冻结及回收跟进、盘点和调整 |
| Inventory | Consumption reconciliation | 按诊所、药品和期间生成数量对账，Finance 从后台查看同一记录并确认 |
| Master Data | Drugs / Suppliers | 共享药品与供应商管理；药品详情内维护库存单位、包装换算与来源映射，不新建独立 Unit App |

开账导入属于库存的授权初始化工具。日常导出放对应列表；单位映射维护在药品详情，不能把实收现场变成自由编辑主数据的表单。待处理数量作为状态筛选显示，不另设大号统计卡或第四个主模块。


<a id="111-orders全宽列表--全宽单据工作页"></a>

### 2.1 Orders 单据列表与工作页

```text
Central Pharmacy        Orders | Inventory | Master Data
Supplier POs | Clinic requests | Approvals              New PO
状态＋待处理数量 → Search / Supplier或Clinic / Date → 全宽表格
打开单据：Back → 单号／对象／状态／版本 → 明细 → 关联记录／时间线
固定任务底栏：本次处理数量或阻断原因                当前唯一主动作
```

Supplier POs 列表显示单号、供应商、日期、状态／当前审核层、提交人及未收行数；不同药品／单位不硬加一个总数量。详情逐行显示普通原订购／已收／未收、赠品已收、原单位、基本数量、计价单位／价格；审批时完整展示药品、数量、价格和交付信息，不从列表摘要直接点 Approve。

审批视图按任务类型和当前层级筛选：CP 采购 PIC 待审、CP 采购 Finance 待审、Clinic direct purchase、退药例外（含自采药退CP）及盘点差异。自采任务显示申请诊所、供应商、申请人及版本，打开完整明细后审批；单级通过后回到诊所待发送，不生成Finance待办。Finance 在后台打开同一 PO 提交版本；Staff按已授权CP单位／运营任务查看单据及过程，“本人提交”是列表筛选，不阻断同单位已授权人员换班接手；审核写权仍只归当前节点。批准／驳回后展示真实节点记录，不能由后一步状态倒推之前已通过。

Send record 是短表单，仅时间、收件人；操作人自动取会话。Receive goods 是单一宽任务弹窗：上方 PO 上下文，中部按批次的可编辑收货表，右侧／下方显示单位转换与本次影响，固定底栏确认。缺批次／效期／转换的行就地提示；不要用另一质量审批页面代替同屏验收。

Clinic request 详情分申请、来源分配、发出、实收／差异和记录；CP 来源批次选择器显示基本单位可用量及效期，保留人工决定。Clinic侧复用已有Drug Dispensing App容器，设计独立的 **Patient dispensing / Clinic orders / Stock** 工作区；订单和库存页不依赖打开某患者。Clinic orders分 **Request from CP / Direct purchase** 两种类型，各有列表→详情→新建：前者显示供货／分发进度，后者显示PIC审批→发送→供应商实收；表格和详情共享组件但不同类型不能混用状态按钮。Stock固定My clinic／CP范围，可从药品进入对应订单创建。Clinic Pharmacy 创建入口明确当前所属诊所，不出现其他诊所选择列表；Staff 代办入口仅列已明确授权的目标诊所，保持 Staff 身份；不恢复重复Inventory App，不把患者上下文带到采购申请。该入口为本稿前端方案，患者页面的现有权限和门禁继续生效。

自采详情固定显示所属诊所和“Clinic direct purchase”，明细列药品、普通／赠品、原单位和基本单位换算、价格及累计已收／未收；页内关联PIC审批、发送和历次收货。主动作随状态为 Submit for PIC approval／Record sent／Receive goods，Returned显示原因和修订／新单入口，未批不出现可执行的收货按钮。Receive goods复用宽收货表单，标题明确“Receive into [本诊所]”，按本次批次与效期校验，确认摘要只增加本诊所来源库存。已收来源的 Return to CP 带出原自采单／实收行，诊所提供来源与原因并向CP发起退回请求；由CP Staff打开同一例外单、正式提交PIC审批及按既有授权办理。Clinic页面查看关联进度，不因这个入口取得CP例外提交或执行权；办理后能回到该来源，不复制新库存记录。

## 3. CP 供应商采购、审批与收货

**功能目的：** 形成获批采购并将真实验收数量记入 CP 库存。

**使用者与对象：** Staff、PIC、后台 Finance；同一 Supplier PO 和收货批次。

**操作与结果：** 建单提交 → PIC 审核 → Finance 审批 → 人工发送 → 分批验收与入库。

**关键边界：** 提交与两级审批三人分离；实际收货必须明确批次与效期。

### 3.1 PO 内容与两级审批

本节仅定义 CP 向供应商采购。按调研说明，同一 CP 供应商 PO 承载 WDL Written Order 的业务信息，不复制一份独立书面订单。保存供应商、稳定药品 ID、原订购数量／单位、计价单位及单价、赠品条款、配送信息；价格、单位和药品信息按提交版本留快照。

| 状态／动作 | 操作者 | 规则 |
|---|---|---|
| Draft → Pending PIC | Staff 提交 | 校验明细、可选单位及换算，生成锁定的提交版本 |
| Pending PIC → Pending Finance | PIC 审核通过 | 记录本级审核人、时间、版本；尚不可发送 |
| Pending Finance → Approved | Finance 最终通过 | 两级均通过同一版本，才完成批准 |
| 任一级 → Returned | 当前审核人驳回 | 理由必填；整单退给 Staff，改后重新提交，从 PIC 开始，不沿用任何旧通过结果 |
| Approved → Sent | CP 人员登记人工发送 | 仅填实际发送时间、收件人；系统自动保留操作人、录入时间、批准版本 |
| Sent → Partially received → Completed | Staff 收货 | 状态由普通订购量的有效实收计算；赠品不抵扣普通未收量 |
| 未履行余量 → Closed remainder | CP 人员结束余量 | 理由及关闭量保留，已收不回滚，未收不伪装收齐 |

提交者和各审核节点保存真实用户ID与有效角色／单位。09-09用户确认：**同一PO提交版本的PIC审核人与Finance审批人必须是不同人员，两人也都不能是提交人**；即提交、PIC审核、Finance审批由三位不同人员完成。服务端按真实人员身份核对，不能以切换角色、显示名或模拟身份满足人员分离。Finance审批时同时校验本版本提交人和PIC审核人；同一人员即使在历史配置中曾有不同角色，也不能完成两级；现行一个 User 一个角色的约束继续适用。没有符合条件的审核人时保留待审状态，由有权负责人安排合资格人员，不自动跳过节点或放行发送。具体权限点须在后端实现，现有`cp.po.approve`不能直接表示两个节点都完成。

Draft尚未提交时可编辑；首次提交后内容锁定。Returned仅允许对未改变药品／价格、未追加采购量的其他内容修订后提交新版本；驳回理由是药品或价格错误时同样遵守下述新PO规则，不因Returned而获得覆盖原药品／价格的例外。**更换药品或改价应作废前一份 PO，关联新 PO 并重新走 PIC → Finance**，不能在原批准单上覆盖。已部分收货时，保留旧单已收、库存与审计，只结束未履行部分并新建关联 PO。普通追加采购数量另建补充 PO，保留原单不变；不能把追加采购写成赠品绕开审批。旧单作废／终止的原因、替代单和保留的已履行量清楚展示。

补齐终止操作的设计如下；历史版本保留，所有动作需在当前状态及版本下校验。

| 所处阶段 | 授权CP运营操作 | 结果与后续 |
|---|---|---|
| Draft／Returned | 取消草稿或本次申请，记录原因 | Cancelled，不产生库存；首次提交后的药品／价格变更仍走关联新单 |
| Pending PIC／Pending Finance | 撤回本次提交 | 回到Returned待处理，当前审批任务结束；重提从PIC开始 |
| Approved、尚未发送 | 作废本次批准单 | 旧审批留痕，不可再登记发送或收货；继续采购需新单审批 |
| 已发送／部分实收 | 终止未履行量及未收赠品任务，记录原因 | 已收保留；内部关闭不等于供应商已经获知或停止配送，人员线下协调 |
| 已关闭后仍到货 | 登记未过账到货异常 | 拒收或关联新的已批准并完成发送登记的PO验收；不能偷偷重开旧单或借赠品入口收普通货 |

审批／撤回、收货／关闭并发时以先成功提交的状态版本为准，后提交者刷新后重新处理；已经收到的实物不因关闭消失。关闭数量覆盖明确普通余量，赠品任务独立结束，避免旧单Completed仍遗留可收入口。

### 3.2 同屏验收与分批入库

从 PO 详情打开 Receive goods，带出各行原订购、普通已收、普通未收、已赠送量及单位。按本次到货分批次录入：正常数量、另加赠品数量、各自录入单位、**批次、效期**、放行结果和备注；展示换算依据及本次增加的库存基本单位数量。

- 批次或效期不明可以保留未过账草稿，但不能验收、确认入库或采用“先入不可用库存后补字段”绕过。不是所有缺值都可填备注。
- 一张 PO 可多次收货，同一行可分多个批次。正常接收量不能超过该行未履行量；超出的普通货需另走 PO。拒收／本次未接收量不增加库存、不减少原未履行量，处置备注留在收货草稿／异常记录。
- 批次效期已知但损坏、失效等货物，由人员决定拒收或接收为不可用；不可用实物接收和可用放行分别记录。过期库存不得进入可用量；具体剩余效期门槛不在本稿虚构。
- 同药赠品作为收货行的独立数量组成部分，转换后与正常数量相加一次；合计只读，避免“总量已含赠品”再加一遍。其他药品赠品是已审批PO中的独立药品行及单位，不能合并到正品数量；批准单中没有该药品时，关联新PO并审批，不临时改变原批准药品范围。
- 普通货收齐与赠品接收分开：普通履行显示Completed后，仍可在原批准药品范围内用“Receive bonus”登记后到的实际赠品，普通实收必须为0，照常填批次、效期及单位；不重开普通未收量。已知赠品待收任务单列，可记录原因后结束；作废／已关闭接收的单据不继续收货。赠品条款不自动产生库存或复杂计算。
- 09-09用户确认：**原PO已批准的同一种药，未约定或超约定的实际赠品允许Staff直接登记验收**，不重新审批；批次、效期及换算照常必填。界面显示约定赠品、累计实收、约定未收和超约定实收量；超约定提示是差异说明，不阻止该授权接收，也不把原条款改写成新承诺。保存本次实际赠品及原PO关联，按收货事件防重复入库；普通追加采购不能改填赠品，未批准的其他药品仍走新PO。原单关闭接收后不借此权限重开。
- Receive & confirm 只为本次选定且校验通过的行过账；未完成的行留草稿。确认前摘要清楚显示本次接受量、可用／不可用量及未接收部分。
- 每次收货生成独立收货单／行及库存来源层。保存、刷新、网络重试或重复点击不重复入库。纸质发票、PO 状态、批准事件均不直接增加库存。

## 4. Clinic 订单：向 CP 申领与向供应商自采

**功能目的：** 区分内部申领和诊所直接采购，保留各自来源。

**使用者与对象：** Clinic Pharmacy、CP Staff／PIC；Clinic PO、分发和实收。

**操作与结果：** 内部申领由 CP 分配、发出和登记实收；自采先 PIC 批准，再由诊所直接下单验收入库。

**关键边界：** 自采不经过 Finance 采购审批；WDL Staff 代申领保持唯一 Staff 角色，按目标诊所及具体采购动作另行授权，不取得患者发药权。

两类订单共享药品、单位和库存服务，但保留明确的订单类型、供货方、收货诊所与审批路径。向 CP 申领走分配／分发；诊所自采走 PIC 采购同意／供应商直接交货，不能因界面复用混用状态或权限。

### 4.1 向 CP 申领、分发与接收

诊所 Pharmacy 创建本诊所申请，保存药品、数量、单位、申请日期和备注。CP Staff 按下述限定采购授权代办，保持 Staff 角色；记录真实登录人、有效角色和目标诊所，不自动获得所有 clinic 的权限。CP 承接仍引用同一申请。

<a id="cp-clinic-procurement-delegation"></a>

**限定诊所采购代办（2026-09-10 本轮 PRD 评审确认）：** 保留 Staff 代办，以角色动作＋目标诊所授权实现，取代旧稿要求同一 User 切换 Clinic Pharmacy 角色的规则。目标诊所是单据来源／受益单位，不是给 Staff 增配第二角色。

授权应明确 Staff、可代办诊所、允许的采购动作、有效期及授予依据；入口只列有效授权诊所，保存和每次后续操作独立重验。创建／编辑草稿／提交、发送登记及收货分别检查，不能因为获准下单就自动取得收货、库存调整、临床审方、标签、备药、复核、患者发药或病历读取权限。审批职责仍按原采购链和真实人员分离执行，代办不包含自批。原账号、Staff 岗位或采购授权失效后停止新操作，既有单据及作者保留，由仍有权限人员按原单接手。

界面明确显示“代 [诊所] 办理采购”、当前 Staff 身份及允许动作；订单保存目标 Clinic、实际代办人和授权依据，列表、详情、导出与提交使用同一范围。不得借患者 Drug Dispensing 页面或模拟他人身份办理采购。

**实施状态：已确认目标，限定采购授权及 Staff 入口待开发／验证。** 原 Clinic Pharmacy 自行下单路径保留；存量 Staff＋Pharmacy 双角色配置须结合单角色整改核对，不能直接删岗位、改历史作者或以旧切角色测试证明新方案通过。

Clinic requests 展示原申请量、未满足量、已分配未发量、累计发出、累计实收、在途、差异、已结束余量，各数量统一到该药品基本单位，原录入数量／单位同时可查。

1. CP 人员选申请和来源批次，决定本次供应量。系统可按有效期先后建议候选，人员最终选定；不可用／召回／已过期或已被其他任务预留的量不可发出。
2. 形成分配时仅预留 CP 现存量，不减现存。实际发出时扣 CP 对应来源层并释放本次预留，转入该分发行在途量。
3. CP 人员录入 clinic 实收，按同一分发来源增加 clinic 库存、减少在途。一次可以同时登记发出与实收，仍保留两条关联数量变化。在途期间过期、召回或发现损坏的实物仍可登记真实接收，但进入不可用量并继承冻结／失效原因；不能因到达新地点恢复可用。
4. 实收不得超过该分发行剩余在途；发 10 收 9 时，1 保留在途差异。经核实再登记补收、原货退回 CP 或实际运输损耗；补发是新的发货，不能用补发抹掉原来的在途 1。
5. 申请部分满足后可继续供应或记录结束未发余量，理由必填。结束申请不自动结束在途、撤销实收或取消已耗用记录。后续退药／换货关联原履行记录，不自动重开原已结束申请。

未满足量＝原申请量－有效累计发出量－已结束未发余量；已分配未发量属于其中一部分，不再次相减。**本次可新增分配≤未满足量－其他有效未发分配，实际发出≤本次有效分配**，两项与来源可用量在同一事务校验。实收差异另按分发行处理，防止混成“申请还欠多少”。源记录已发生更正时从有效流水重算，不手工覆盖累计数。

申请状态与实物履行分别展示：Draft → Submitted → Partially fulfilled → Fulfilled／Closed remainder；Draft可编辑或取消。提交后药品及原申请量保留，追加需求另建关联申请。Clinic提出减量／取消剩余需求，由CP在同一申请确认关闭未发量；该确认与分发互斥校验，并同时释放所关闭部分的分配。尚待CP确认时明确显示“取消待处理”，不能假装已取消。全部未发且全量关闭显示Cancelled；部分已发只关闭未发余量，旧在途和实收任务继续。返回的货和替换发货各走关联记录，不抵消原发货事实。

Fulfilled表示申请量已全部实际发出，不表示clinic收齐；实收进度及在途差异继续单列。例：申请20、已分配15未发，CP确认全部取消后释放15、关闭20，不产生库存移动；若已实际发出5，最多关闭剩余15，已发5继续实收／差异处理。该操作是供货安排，不增设采购审批。

### 4.2 诊所自采：PIC 同意后直接采购、自行验收入库

**09-09用户新增确认：诊所自采必须先获得 CP 同意，审批由 CP PIC 单独完成即可；通过后由诊所直接向供应商发起采购，自行收货入库，之后也可能退回 CP。** Finance 不增加采购审批节点；§3 的 CP 自身两级审批不变。本节是新交易流程，既有第三方历史库存仍按开账／来源核对处理，不伪造历史审批。

采用同一张 **Clinic direct purchase PO** 贯穿申请、PIC 审批、供应商发送和收货，不让人员再抄一份独立采购申请。保存所属诊所、供应商、药品、普通数量／单位、计价单位／单价、赠品条款、交货信息及申请备注。审批的是本单提交版本，不是对该诊所／药品的长期无限采购许可；供应商及价格为本单授权人员可见的业务快照，不因使用共享目录开放其他单位商业资料。

| 状态／动作 | 操作者 | 产品规则 |
|---|---|---|
| Draft → Pending PIC | 当前诊所 Pharmacy | 校验本诊所、供应商、药品、单位及数量／价格，锁定提交版本，送 CP PIC 审批 |
| Pending PIC → Approved／Returned | 获授权的 CP PIC | 查看完整提交版本，通过或填写驳回理由；只需本节点，不生成 Finance 待办；提交人与审核人按真实用户分离，不能切角色自批 |
| Approved → Sent | 当前诊所 Pharmacy | 获批后人工向供应商下单，系统仅要求登记实际发送时间与收件人，自动记录操作者和录入时间；未批准不能执行发送登记或收货过账 |
| Sent → Partially received → Completed | 当前诊所 Pharmacy | 从本单选择行，自行登记实际正常量及批准范围内赠品、批次、效期和验收结果；按本次实际接受量入本诊所库存，普通履行与赠品分别显示 |
| 尚有未收量 → Closed remainder | 当前诊所 Pharmacy | 记录关闭原因及余量；原已收、来源和耗用均保留，不把关闭量当作实收；线下协调供应商停止剩余交货 |

复用 §3 的版本、驳回／撤回、终止及关联新单原则，但审核链固定为 **PIC 单级**，操作归所属诊所。Draft 可改；Pending 可撤回，当前审批任务结束。首次提交后更换供应商、药品或改价时终止旧单未履行部分，关联新 PO 重走 PIC；普通追加采购另建补充 PO，不能改写已批上限。其他允许修订的新版本也重新送 PIC，不沿用旧批准。批准未发送的单可作废；关闭后到货保留未过账异常，拒收或关联新的已批并登记发送的有效单，不重开旧批准额度。审批、撤回、接收和关闭按同一状态版本互斥校验。

诊所自行收货是本次新增的明确职责：不再要求 CP 人员代录这一采购支线的实收。每次确认都生成本诊所独立收货行及第三方采购来源层，关联原自采 PO 行、批准版本和供应商。一单可多次收货、一行可分多个批次；复用 §3.2 的批次／效期强制校验、正常量不得超未履行量、可用／不可用判断、普通／赠品分列及 §7 单位转换，不继承 CP Staff 专属的额外赠品接收权限。缺批次／效期或转换依据只能留未过账草稿；批准、发送或纸质发票均不增加库存。没有有效批准却已到货同样保留异常，不用手工调账或历史导入绕过本流程。

库存按 **供应商 → 本诊所** 直接增加，无 CP 出库、CP 分配或内部在途；采购未交货量仅是 PO 待收，不计内部现存。收货单位绑定订单所属诊所，服务端不得接受任意目标地点。实际货在错误地点时保留异常，不先记到原诊所再虚构调拨。CP Staff 只有获得该诊所对应采购及收货动作授权后，才可保持 Staff 角色执行获授动作；下单授权本身不包含收货，真实用户与目标诊所分别留痕，见 §4.1。

自采直接在诊所发药、浪费／销毁进入统一库存与耗用流水，按 §5.3 单列并排除 CP 结算。后续交回 CP，选择本自采实收行发起第三方退药流程，由 Staff 另提本次例外、PIC 单独批准，再登记实物移动和接受结果；**采购批准不等于退药批准，不保证 CP 将来接受退药**。已经纳管的自采库存必须从诊所对应来源扣减，不能当成无记录外部货只给 CP 加库。CP 接受后再实际供给诊所，才对对应再次供货后的耗用生成 CP 结算资格；待处理／拒绝后原物退回原诊所保留原自采性质，不冒充再次供货。

## 5. 库存完整逻辑：数量、状态、来源及结算

**功能目的：** 由同一数量流水解释余额及可结算耗用。

**使用者与对象：** Staff／PIC／Finance；地点、药品、批次、来源及 Movement。

**操作与结果：** 业务确认产生数量变动 → 查询余额及来源 → 汇总实际耗用 → Finance 数量核对。

**关键边界：** 审批不直接移动库存；诊所第三方直接自购耗用与经 CP 供货耗用分别计算。

### 5.1 一个余额来源，保留四个维度

库存基本对象为 **药品＋地点＋批次＋来源实收层**，数量统一为该药品基本库存单位。内部转移新建目标地点实收层并保留父来源层、原供应商实收根和来源性质；退回也保留新的实际接收事实，不删除来回路径。相同批次从两张 PO 收到，可以按批次汇总展示，但退药额度、耗用与转移必须仍能分到原实收层；名称或自由文本单号不足以追溯。

| 维度 | 定义／展示 |
|---|---|
| 实际位置 | CP、指定 clinic 或某笔业务的在途；供应商和患者不计作内部库存地点 |
| 现存 H | 当前实际地点的已登记实物，含可用、预留和不可用；不含已发出的在途 |
| 可用 A | 可继续分配／发出的量；A＝H－R－B |
| 有效预留 R | 仍有效且尚未实际发出的任务占用；和不可用 B 不重复计数 |
| 不可用 B | 失效、损坏、召回冻结等不可正常供应的实物并集，同一数量多个原因不叠加扣减 |
| 在途 T | 实际已离开发出地、尚未完成目标接收／回退／损耗处理的数量，按业务分发行保留 |

每一来源层的 H＝A＋R＋B，均不得为负。库存状态改变不等于实物增减；批次、效期不是药品主档的单一日期。页面允许同药跨批次汇总，不能把不同药品的 TAB、ML 或 BOX 相加成“库存总数量”。

有效预留遭遇过期／召回时，对应实物转不可用，原任务标记需重新分配并保留失效的预留历史；该数量不能同时算进 R 和 B。过期检查须在查询和实际分配／发药确认时生效，不能只依赖一个可能延迟的后台任务。人工判断可以选择可用来源，不能把系统已知过期或冻结数量当作可用发出。

### 5.2 何时增减：所有确认动作进入同一流水

表内 Q 均为转换后的基本单位量；“确认”指实际业务确认及服务端成功过账，不是仅保存表单。

| 事件 | 现存变化 | 在途／预留／其他影响 |
|---|---|---|
| 开账确认 Q | 指定地点 +Q | 标注期初与原始导入来源，仅一次 |
| CP 采购供应商实收 Q（含赠品） | CP +Q | 形成来源层，按验收结果进入 A 或 B |
| 诊所自采供应商实收 Q（含赠品） | 订单所属 clinic +Q | 关联有效自采 PO／PIC 批准及实收行，形成第三方来源层；CP 与内部 T 不变 |
| 保存 PO／提交／审批／发送 | 不变 | 都不是库存事件 |
| 分配 Q／释放分配 Q | H 不变 | A 与 R 对应转移，不能双占 |
| CP 向 clinic 发出 Q | CP −Q | 本分发 T +Q，释放对应 R |
| Clinic 接收 CP 分发 Q | 该 clinic +Q | 本分发 T −Q，不重复扣 CP |
| Clinic 实际发药 Q | 该 clinic −Q | 消费匹配的预留／来源分摊；一笔耗用，不因发药历史及库存回调再扣一次 |
| Clinic 确认患者实物退回 Q | 该 clinic +Q | 关联原发药分摊及实际回收，未完成质量判断不恢复可用；不删除原发药，退款不触发本事件；相应CP结算耗用量扣减 |
| 指定地点实际浪费／废弃 Q | 该地点 −Q | 记实际用途；从对应 A 或 B 扣一次，有关联预留则一并处理冲突 |
| 失效／损坏／召回冻结 Q | H 不变 | 可用转不可用，不当作已销毁或已耗用 |
| Clinic 实物退回 CP Q | clinic −Q、CP +Q | 按实际离开／到达登记，中间使用退单在途；各侧只过账一次，处理成功／失败不替代实物事件 |
| CP 实际退供应商 Q | CP −Q | 已有出库时不再扣；供应商处理失败不自动加回 CP |
| 实物实际从供应商退回 CP Q | CP +Q | 必须登记真实接收，关联原退单；不是改失败状态自动恢复 |
| 在途差异实际损耗 Q | 地点 H 不再扣 | 对应 T −Q，保留真实损耗事件及原因，不冒充 clinic 已收到再耗用 |
| 盘点差异已批准 Δ | 指定来源层 +Δ 或 −Δ | 生成调整流水，不能覆盖余额；盘点本身不自动计为诊所耗用 |
| 退药失败／Finance 对账确认 | 不变 | 业务结果／财务核对结果，不是库存事件 |

内部转移满足 `CP 现存＋各 clinic 现存＋内部在途` 守恒。外部采购／外部来源首次纳管／外部换货实收、实际耗用／损耗、外部退货及盘点调整分别解释总量变化。供应商退换过程中若已记出库，后续处理结果不得再次减量；实际回货才增加。

### 5.3 统一耗用与数量对账

患者实际发药在 Clinic Drug Dispensing 完成；库存使用其**实际发出数量与单位**，不使用医嘱剂量或仅已备药状态。库存服务需接受统一来源键（来源类型、来源记录、版本、行及动作），无论从业务接口还是人工补录进入，同一事实只计一次。

一个药品执行行可有多条实际批次／来源分摊，各子行保存原数量、单位、换算及基本量；子行基本量之和须等于签署的实际应发基本量。最终仍按处方整单领取，各来源同一确认事件只扣一次；改变已备药分摊需重新实物核对。付款后原批次过期／召回／盘亏导致预留失效时，药房可按授权进行同药同量的来源重分配，重新备药和复核；处方与价格未变不重收费，无有效替代来源保持阻断。完整操作门禁见[Pharmacy／V-Lab](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html)。

人工补录历史发药必须在 clinic 的授权流程关联来源；CP 的耗用页面可查看、登记真实废弃及处理经授权的补记，不提供绕开药房门禁的患者发药按钮。已由其他模块过账的记录只展示；取消未发药只释放预留，已发药后的患者退药／退款遵循药房与 Cashier 原流程，不等同于 clinic 向 CP 退库存。

数量对账按 clinic、药品、期间生成，列示发药量、实际浪费／废弃量、患者实际回收量、错误更正量和净耗用量，单位为基本单位，能下钻每笔来源。CP 自身损耗、运输损耗、地点转移、失效标记和未分类盘点差异不直接记成 clinic 发药或 clinic 耗用。

Finance 查看授权范围的同一对账单，核对后登记确认／退回及备注；记录操作者、时间、汇总版本及所含流水。确认不再扣库存、不自动收款、不生成患者发票或擅定收费价格。确认后发现补录／纠错，保留原版并生成明确取代旧版的新版本待重核，不静默重写已确认结果。具体结算期间由筛选选择，不预设必须月结。

**查询与正式确认分开。** 任意日期范围可查询；正式确认单按真实耗用来源分摊纳入明细，同一分摊只能归属一个有效确认结果。重叠查询可以展示已确认量，但生成待确认单时必须排除或明确引用已归属明细；不能因换一个期间筛选又确认一次。期间以经营单位配置时区的实际业务发生时间计算，使用起点包含、终点不包含的边界，同时保留登记／过账时间。

本稿采用可追溯的**替代版本**设计：确认后补录或纠错，生成待核新版本，展示与旧版差异；Finance确认后新版本显式取代旧版，旧版仅作历史。不得同时另生成一份独立差额单重复归属。纠错沿用原分摊的确认单归属；尚无归属的新迟录事实先进入未确认明细，由人员选定唯一符合诊所／业务日期范围的确认单接收并生成替代版本，或纳入独立待确认单。多个重叠期间均符合时不能自动同时吸收。迟录事实保留真实发生日期，不为方便改成登记日耗用。并发生成／确认／替代须校验明细归属和版本，已经更正的源事实不能继续按旧快照新确认。这里只替代数量核对结果，不自动逆转财务系统的付款。

**一套库存事实，保留结算来源。** 所有耗用按实际来源分摊，至少区分CP普通供货、CP赠品、诊所第三方自购、第三方经CP接收后再供货、历史来源待核。同一药品混合来源必须拆分；目录的CP／clinic_direct优选、当前药品价格或零单价不能代替实际来源。09-09用户逐项确认的结算归属如下；这些是数量口径，不自动确定采购成本、结算单价或患者退款金额。未知来源单列待核，不能默认按普通CP供货确认，也不影响来源已明确的正常库存登记。

| 实际耗用来源 | 是否计入CP结算数量 | 必须保留的依据 |
|---|---|---|
| CP普通供货 | 计入 | 原采购及实际供货／clinic实收分摊 |
| 供应商赠品经CP供应clinic | 计入 | 赠品标识及实际供货来源；零采购价不使实际耗用数量归零 |
| Clinic第三方自购并直接在clinic耗用 | 不计入，单独列示 | 新交易引用自采PO／PIC采购批准／供应商实收；已核实历史自采引用开账来源，不补造审批；两者均关联本诊所实际耗用，获批自采不改为CP供货 |
| 第三方自购药例外交CP，再由CP供应clinic | 计入 | 原第三方采购根、例外审批、CP实际接收及再次供货路径；只纳入再次供货之后的耗用，不追溯改写此前直接自购耗用 |
| 来源未核实 | 待核 | 不以目录优选、当前价格或手填标签猜测归属 |

患者实际退回由Clinic Drug Dispensing受理。目标库存接口须关联原发药及来源分摊，记录真实接收的数量、单位和当前处置状态；保留原发药事实，不能把真实退回当作原发药错误直接删除。每个原发药分摊的累计有效回收不得超过其原实际发出量，含不同退单、在办占用及回收更正，并发在提交点校验；不能借其他批次的发药量或把不明来源硬挂已发记录。未能确认药品／批次等来源时保留待核记录，不能伪造来源入库。退款不移动库存，后续实际销毁再关联该回收实物扣一次。可否重新放行遵循药房质量规则，不能默认恢复可用。

09-09用户确认：患者实际回收时扣减对应CP结算耗用量，后续实际销毁再计入；例如CP来源发药10、实际回收3、再销毁3，累计结算耗用量为10−3＋3＝10。结算资格继承原发药的实际来源，第三方直接自购且原本排除CP结算的回收／销毁，在未发生后续CP实际接收再供之前继续排除，不产生无依据的CP结算负数；若之后走完CP接收再供，新的耗用按该次供货来源计入，此前排除记录不追改。仅申请退药、退款或标记失效均不触发该数量变化。

真实回收和之后销毁按各自实际发生日期进入相应期间；它们不是原发药录错，不改原发药日期或旧事实。跨期回收可使当期净结算数量为负，清楚显示并交Finance核对，不能强行归零、与另一药品抵消或自动退钱。原事件确属录错时才按前述归属及替代版本规则更正。

### 5.4 盘点、开账与更正

- **盘点：** Staff 按地点、药品、批次登记实盘数和差异原因；PIC 审批前库存不变。保存盘点时的账面版本、时间和范围；期间发生收发时需重新核对并更新差异基准，不能拿旧差额直接覆盖新余额。批次跨多个来源层时明确差异分摊，无法确定的历史来源保留例外来源层，不能伪造普通可退额度。确认同时核对A／R／B及包装实物分段；盘亏侵入有效预留时，列出受影响任务，原子释放／失效不足的预留并要求重新分配，不能一律从A扣成负数。不可用量同样按真实实物核对，调账不自动解冻剩余实物。
- **开账：** 采用预览 → 校验 → Staff 核对确认。行保存原始来源标识、源数量／单位、基本单位量、地点、批次、效期及可用性。以“药品＋地点”为一个开账范围，导入行可分批补齐，但范围内全部已知批次与数量核对完整后才一次确认并切换；不同完整范围可分别确认。身份／单位／批次／效期未明的范围显示“期初待完成”，不将部分数值或未知伪装成完整库存／零余额。已有有效账本的范围不再次开账；晚发现的漏项通过带原因的盘点调整及PIC审批处理。
- **切换权威来源：** 按地点和药品记录完整开账集合及启用流水的切换时点；切换中的交易先核对到同一时点，不能同时进入期初和新流水。未切换范围不得在新账本过账或展示可供量。期初覆盖切换前存量，之后所有业务按流水入账。同步／Excel 导入可继续维护允许的主档字段，不能覆盖已启用账本的 H、R、批次或单位。切换前的历史发药不能再作为切换后新耗用扣一次。
- **更正：** 已生效库存记录不删除、不改原数量；使用原业务关联的反向／补充流水，保存原因和前后关系。存在后续发出／耗用的收货不能直接整笔撤销，先校验实际来源余量并处理下游影响。普通录入差异回到原业务更正，盘盈亏走 PIC 审批，不提供一个任意改余额的通用入口。
- **幂等与并发：** 状态版本、来源余额、换算、授权和剩余额度在提交时再次校验；业务单、流水、余额、预留和审计在同一事务生效。超量或冲突整体失败并保留输入，重试同一确认请求只返回既有结果。


<a id="112-inventory库存来源与每笔增减互相可追溯"></a>

### 5.5 库存查询与操作界面

Stock 表按授权地点显示药品、基本单位、现存、可用、有效预留、不可用；在途独立，不混在现存。批次详情显示批号、效期、来源性质（CP供货／诊所自采／CP再供）、来源收货、各状态量、已占用任务及已发未收记录。物理数量和状态用文字区分，不只用颜色。

Movements 显示业务日期、登记时间、类型、来源／目标、原数量单位、换算摘要、基本数量、关联单据和操作者。查看详情可回到同一收货／分发／耗用／退药对象，不创建第二张同义操作单。更正展示原记录与反向记录，不修改历史明细。

Returns 先选方向及来源实收；可退量为零的行说明原因。第三方／缺原 CP 实收切换为 Request exception，批准前不能 Confirm return。详情显示原单或批准版本、原始／基本数量、成功／失败、实际位置、库存影响和剩余替换额度。

Recalls 以批次任务为对象：原因与冻结范围 → 各地点影响／在途／已耗用 → Staff 联系与回收结果。PIC 发起操作与 Staff 跟进操作分开；数量回收打开同一退药表单，不能点“联系完成”自动移库。

Stock counts显示盘点基准、当前账面、实盘、差异、包装状态及原因；PIC看到期间变化和受影响预留任务并重核后批准，不能只审一个总差额。Opening import 复用授权导入框架，只在初始化工具显示；逐行预览单位解析、批次、来源及可确认／待补原因。

Consumption reconciliation显示诊所、期间、药品基本单位、各用途数量、来源分类、总耗用、可结算数量、排除／待核数量及Finance状态；提供查询报表／正式确认单区分、已归属明细提示和替代版本差异，下钻来源而非手改总量。只提供当前明确范围的导出，不加入付款、成本或 NetSuite 状态控件。

## 6. 回收退换、例外与批次召回

**功能目的：** 记录退药依据、接收决定和真实移动，并追踪批次问题。

**使用者与对象：** Staff／PIC 及接收方；原实收、Return、Exception、Recall。

**操作与结果：** 关联原单或先批例外 → 接收方决定 → 登记实际移动／替换 → 保留后续处置。

**关键边界：** 接收方接受才算成功；全内部范围召回／冻结权限暂缓。

### 6.1 正常退药的来源和上限

退药申请／审批状态与实际成功／失败结果分开。备注可以描述拆封、近效期、错订、损坏等原因，但不能代替药品、数量、单位、批次、效期和有效实收关联。

| 方向 | 正常来源依据 | 实物移动影响（独立于处理结果） |
|---|---|---|
| Clinic → CP | 原 clinic PO → 分发行 → clinic 已确认实收行 → 来源批次层 | 实际回到 CP 的 Q，clinic −Q、CP +Q |
| CP → Supplier | 原供应商 PO 行 → CP 已确认收货行 → 来源批次层 | CP 实际转出 Q；不把供应商作为内部库存地点 |

可退上限＝`min(原实收量－该来源累计成功退量，当前地点该来源批次可转出实物量)`。实存已扣过耗用，不再次减耗用；未实收的 PO 量不能退。不可用实物可按实际退回，但不得占用其他有效预留、借另一 PO 的来源层或用例外绕开已知数量上限。已有待办理退单须占用本次额度，取消／失败释放业务申请额度；但实物已送出则仍须真正收回后才能再次转出，不能把额度释放当成实存恢复。退药处理还须锁定对应实物分段，避免同一批可用或不可用实物同时被另一退单／供应任务占用；不可用退药占用不伪装成可正常供应的R。

内部往返保持采购根来源：供应商实收S10 → clinic实收C10 → 实际退CP4生成返回层R4，R保留C及S。之后向原供应商退这4时，按S的采购根核算额度、从CP当前R层扣实物。Clinic→CP与CP→供应商的退药额度分方向计算，前者的成功4不扣掉后者的可退采购量。既不能丢失新返回事实，也不能凭返回层重新生成一份独立采购额度。

### 6.2 成功、失败与替换货

09-09用户确认：**接收方（CP或供应商）接受退药才算成功**，仅已发出／送到不能自动成功或生成替换额度；被拒绝则按拒绝量失败。实际转出、接收、退药结果三者独立留痕，已登记对应出库／入库的环节不重复执行。成功退回CP的失效药保留实物数量但不增加可用量。失败不自动加回、扣除、销毁或恢复有效；“不支持退换”与“药品已失效”分开记录。

部分处理按数量分段，例如申请 10、成功 6、失败 4；终局仍为成功／失败，未处理量单列。失败量不占原实收的累计成功退量；实际销毁另登记耗用。实物已经在 CP 或供应商处时，失败结果必须显示真实位置与后续任务，不能按状态猜测位置。

成功量需有对应实际交付和接收方接受事实；提前同意办理属于待执行，不能凭口头同意先产生替换额度。申请量＝成功量＋失败量＋未处理量，已移动量另行展示，不与三者重复相加。实物已到CP但尚待判断或被拒绝的部分保留在不可用／待处理状态；后续实际退回clinic同样登记对应移动，不虚构“未收到”。原物退回发送诊所与CP实际再次供货分别保存移动目的；前者保留原来源结算性质，不能因药物经过CP地点便改记CP供货。

替换货单独关联原成功退单，记录新的实收／发出／clinic 实收和新批次，不以净额覆盖旧退药。同药换货的数量上限为成功退量－有效累计替换量；它不是对方已承诺换货，必须由人员选择本次办理换货并登记实际结果。clinic 换货发出时占额度，实收不再占一次；供应商换货在替换货实收时占额度。对同药、已验证可换算单位，按基本单位比对；不同药品不能按数量等价替换，改药／改价按 §3 新 PO 或关联新 clinic 申请办理，已实际履行部分保留。

### 6.3 缺 CP 原实收、历史来源和第三方采购例外

**Staff 提交 → PIC 单独审批 → Staff 登记实际结果**，不经过 Finance。诊所向第三方采购的药品交回 CP 必须走此例外，即使有第三方 PO，也不能当作原 CP 供货。§4.2的自采采购批准与本次退回例外分别保存；前者不代替后者，也不预先保证退药成功。新自采交易已有完整实收来源，例外仍需引用它，不能把“没有 CP 原单”误当成“没有任何库存记录”。

例外绑定方向、来源／目标单位、稳定药品 ID、录入单位与基本单位、批次／效期、数量上限、原因、第三方／历史来源、系统是否已跟踪该来源余额。Submitted 锁定版本；Approved／Rejected 保留审核人和原因；关键对象或上限变化重新申请。审批不移动库存。

批准只供本次不超过上限的实际处理一次，部分执行后的剩余授权结束；不得跨药品、跨诊所或重复套用。系统已跟踪的第三方clinic库存，按实际离开clinic／到达CP分别登记；在CP待处理或被拒绝但仍由CP保管的实物保留为不可用，结果不控制移动。未纳管的历史来源只记录外部来源首次进入CP，不制造虚假的clinic负库存。必须区分“没有跟踪来源”和“已跟踪但不足”，后者不能用例外跳过数量控制。

“一次”指批准绑定一个实际退药处理对象及其确认办理量，不是只允许一个按钮调用。该对象的发出、在途、分次实收、成功／失败及失败后真实回流可继续完成，各动作不重复消耗例外额度；不得另开第二张退单套用剩余授权。

### 6.4 批次召回

PIC选择稳定药品、受影响批次和已知供应来源，在已授权操作范围内填写原因、范围并发起。09-09用户决定：**PIC覆盖CP、所有内部clinic及在途的全范围召回／冻结权限先不考虑，作为后续扩展暂缓**；本期不新增全范围冻结开关、权限申请或跨范围自动审批／任务编排。此前已确认的基础召回、人工跟进和实物回收设计保留。

页面只呈现获授权资料，并明确本次实际可执行范围；权限外情况不能显示为零影响，也不能把局部处理标为“全集团已冻结／已回收”。范围外协调仍由人员线下处理，系统不自动越权写入或开放病历／其他业务资料。已按业务规则及授权标记的不可用状态仍按§5控制，不因暂缓扩展而清除。

冻结使受影响现存不可用并阻止继续分配／发药；保留受影响预留任务，提示重新分配。系统按来源与流水列出 CP 现存、各 clinic 实存、在途、已耗用及已回收量；只有真实收到才计为回收，不把联系成功当回收成功。

Staff 人工联系诊所、记录进展、实际回收成功／失败数量和原因；实物回收复用退药与库存路径，不建立第二个扣减接口。有原实收走正常关联，无原 CP 实收／第三方来源仍遵守例外审批。已被患者领走的药仅交由 clinic Drug Dispensing／临床团队后续处理，CP 不因此新增患者发药或跨诊所病历访问权限。

召回任务可结束跟进，但未回收量及原因必须保留；结束任务不自动解除冻结、恢复失效药或冲销库存。误选范围的更正由 PIC 留痕处理；是否可重新放行依实际质量判断，不把“已关闭召回”作为恢复依据。

## 7. 单位转换与登记契约

### 7.1 一个药品一个基本库存单位，多种可录入单位

**基本库存单位**是该药品在 CP 与 clinic 间共同记账的单位，不强制所有药品用片或盒。**录入单位**是本次下单、收货、发出、实收、耗用或退药使用的单位。**剂量单位**和药品含量属于临床语义，不能直接替代库存计数。

| 数据 | 设计规则 | 示例（合成说明，非真实药品换算） |
|---|---|---|
| 基本库存单位 | 依据已有主档及有效映射确认，每个可互换库存药品一个标准 | 某药为 TAB；另一药为 ML；也可为 CAP、VIAL、BOT、G、BOX |
| 允许录入单位 | 只显示该药品已验证的单位关系；单位字典名称不自动构成关系 | 某药 1 BOX＝3 STRIP、1 STRIP＝10 TAB |
| 商品级换算 | 保存 from/to 单位、正数精确比例、商品／包装、有效版本及来源 | 该药 1 BOX＝30 TAB；另一药的 BOX 不能沿用 30 |
| 原始输入与快照 | 单据行同时存原数量、原单位、当时比例／版本、基本数量及单位 | 2 BOX → 60 TAB，不只保存 60 |
| 计价单位 | 单价对应的单位明确，与库存量和剂量分开 | 每 BOX 的采购价不能误当每 TAB 的价格 |
| 最小计量步长 | 每药品明确可计数精度；数字字段有小数不代表任何药都可拆分 | TAB 默认完整片；允许半片必须有该药明确依据；ML 可按已配置步长 |

换算公式：`基本数量＝录入数量 × 比例分子 ÷ 比例分母`。多层包装解析为一个直接到基本单位的有效比例，禁止循环或同一版本存在冲突结果；只改展示单位时余额不变。原始单位代码与规范名称都保留，UUID／`unit` 未解析时显示待补映射，不能悄悄按片处理。

同一药品在 CP 用 BOX、clinic 用 TAB 时，先验证药品身份和包装关系再统一记账；未明确前不能把两个单位的数量直接相加。不同规格／含量／不可互换包装应保留独立库存商品身份，不只凭相同成分或名称合并。批次内可有不同来源的包装快照，来源分摊不丢失。

### 7.2 每次登记的交互

1. 选药品后带出基本单位和允许单位；优先选择来源单据单位，不再默认所有药品 `box`。
2. 输入本次实际数量，旁边即时显示“2 BOX × 30＝60 TAB”及来源／版本。正常量、赠品量分别转换，基本量合计只读。
3. 每个批次单独填实际数量和效期；表格列出原输入、换算后的库存量、可处理余量及确认后的增减摘要。
4. 缺关系时阻止该行按未知单位过账，提示主档维护人员补映射；若基本单位已可靠确定，可让人员直接按实物确认后的基本单位录入，保留原包装描述为备注，不伪装已存在自动换算。其他已验证药品不受影响。
5. 退药／更正从来源单据取得历史换算快照及当时基本量；不能用今天的包装比例重新计算过去一盒的数量。任何从既有库存发出／耗用的交易均按实际所选来源包装转换；旧30片盒与新28片盒可同时存在。新包装的采购／收货采用其有效映射，已提交PO保留对应版本；不是所有今天新建的交易都套今天最新比例。混合来源包装分别拆行，或按已核实基本单位录入。

**拆包不是新增库存。** 账上 60 TAB 的两盒拆开后仍是 60 TAB，登记拆封状态及需要的实际信息；发出 7 TAB 后才余 53 TAB。混合包装录入可表达 1 BOX＋7 TAB＝37 TAB，但不得把 37 TAB 默认显示为完整未拆封的一盒加七片而丢失实际包装状态。

来源层下至少区分未拆整包装数与已拆基本单位量；拆包按实际数量将一个完整包装转成已拆数量分段，基本总量不变。只有未拆包装实物足够，才能承诺按整包装发出；基本量除以换算系数只是等值量，不是完整包装数量。两瓶100 ML均拆封且各剩60 ML时，共120 ML但完整瓶为0，不能以足够100 ML就发出“1未拆BOT”。不默认建立逐瓶序列号；须按实际包装状态及适用质量期限区分必要分段，避免将不同有效期的已拆量混合。

对于液体，若药品已验证 1 BOT＝100 ML，则收到 2 BOT 入 200 ML、实际发出 15 ML 后余 185 ML；没有该商品容积依据，BOT 与 ML 不可互换。mg／dose 与 TAB／ML 的临床转换不是通用库存换算；库存接收药房已经确定的实际发药数量，不按处方剂量自动推导。

### 7.3 精度、变更与价格

- 产品设计以现有库存 **4 位小数的数量精度**为统一起点，采购、发药、收发、预留、退换、导入及接口全链无损。金额独立采用其价格／金额精度，不能用金额四舍五入函数处理数量。
- 比例使用精确十进制或分数，服务端 Decimal／数据库 NUMERIC 为最终结果；API 传递十进制字符串避免浏览器浮点误差。结果超过允许精度／范围或不符合商品步长时明确拒绝并要求有效单位／准确数量，不静默截断、凑整或记隐藏尾差。实际底表需要更多精度时，应统一扩展链路再纳入该商品，不由某一页面单独放宽。
- 已有交易／存量后不允许直接覆盖基本单位。名称标准化不改数量；包装比例变更形成新版本，只影响之后的交易。基本单位确需变更时走受控资料迁移和库存核对，不能用主档 Edit 触发隐含全账重算。
- PO服务端先计算`计价数量＝普通订购基本数量÷每计价单位的基本数量`，再按有效价格精度计算`行金额＝计价数量×单价`，汇总为单据金额。客户端金额只作比对，不能成为权威；审批和人工发送展示同一提交版本计算值。例2 BOX、30 TAB/BOX、10/ TAB应为600，不能直接用2×10得20。不同单位或货币不可直接混算，同一PO金额采用明确单一币种，不默认为跨币种自动换汇。PO按明确计价单位核算采购金额；库存增加实际正常量＋赠品量。零价格赠品仍有库存数量，不由金额除以单价倒推数量；本稿不定义加权成本、赠品成本摊销或 clinic 自动结算价格。

### 7.4 底表证据的使用边界

09-06 读取仓库 `scripts/sql/2026-08-31-182736-database-postgres-backup.sql`：CP 972 条、19 种单位，TAB 371、ML 116、CAP 102、VIAL 97、BOT 53、G 44、SYG 37、BOX 33、其余 119；clinic 15,782 条中 7,450 个单位值为 UUID、4,738 为 `unit`。单位字典及旧 `from_unit_id/to_unit/to_qty` 路径存在，但没有完整转换入账链。

这是历史导出，不是当前库存。CP 全部最后同步于 2026-07-28，971 条库存为 0，仅 5 条有有效期；当时未取得实时库存。PO、行及审批事件在该导出为 0 行，不提供真实交易样本。无专用赠品数量／关联字段的发现也限定于当时核对范围。本次代码证据见 §12，不能把历史样例比例、库存数或日期用于生产默认值。


<a id="113-master-data药品中的单位配置"></a>

### 7.5 药品单位配置界面

Drugs 复用 canonical 药品和 CP／clinic 来源映射，展示编码、名称、规格、基本单位及状态；详情分基本资料、允许单位／包装、来源映射和历史版本。单位行显示“1 BOX＝30 TAB”、来源、有效版本和步长；冲突标为不可用于新交易，不以猜测默认值填平。

Suppliers 维护稳定供应商身份、名称、联系人、订购联系资料和启用状态。现有供应商文字字段／performance 报表不能代替这一主档。新药品经基本单位与必要映射验证后方可用于交易；停用停止新选择，已发生的单据和库存仍可追溯处理，不清零历史。

共享价格维护回到权威 Catalogue／价格入口，PO 保留交易快照；CP不另建第二份集团价格。低频设置入口位于标题右侧，只有有真实配置对象及权限才显示，不放占位齿轮。

## 8. 设计验算与后续验收场景

以下为合成场景和目标断言，**未执行的应用验收清单**；旧 v0.3 演示通过不表示本版已实现。

| 场景 | 必须得到的结果 |
|---|---|
| CP 双级审批 | Staff 提交后仅 PIC 当前节点可审；PIC 通过仍不可发；Finance 通过同版本后才可登记发送；任一级驳回重走全链 |
| 审批人员分离 | A提交、B以PIC通过后，B切Finance仍被拒绝，A也不能审批；不同的获授权C以Finance通过同一版本才可发送；拒绝不改变待审节点或伪造通过记录 |
| 诊所自采单级审批 | 诊所A提交后未批发送／收货均拒绝；CP PIC通过本版本后可由A登记发送及自行收货，无Finance待办；提交人不能切PIC自批，普通CP采购仍须Finance |
| 自采单位及分批实收 | 批准2 BOX、每BOX30 TAB，A先收1再收1，A来源库存累计+60 TAB、CP不变、内部在途不变；缺批次／效期不得过账，同次重试不重复增加 |
| 自采范围及关闭 | B不能替A收货；已收1 BOX后余1改价须结束旧余量并新单PIC审批，保留原30 TAB；不得利用已批原单超收普通量或批准后改收货诊所 |
| 自采退回独立审批 | 自采已获PIC批准仍不得直接用采购批准完成退CP；新例外通过后实际转出／接收各记一次，CP接受才成功；拒绝后的原物回诊所仍属自采，不计CP供货 |
| 发送字段 | 只填实际时间及收件人可完成登记；无 reference／附件仍有效；显示“登记已发送”，不声称系统发邮件 |
| 分批收货及赠品 | PO 普通 10 BOX，先普通 6 后 4，另赠 2 BOX；若 1 BOX＝30 TAB，普通收到 300 TAB、赠品 60 TAB、库存共 360 TAB，原订购仍 10 BOX |
| 批次／效期缺失 | 任一必填缺失，该行不能验收入库；通过的其他行可明确分批确认，不能全部显示成功 |
| 包装拆分 | 初始 60 TAB，拆两盒不增减；发 7 TAB 后 53 TAB；1 BOX＋7 TAB 的合计为 37 TAB而非8或67 |
| 历史比例 | 原收货 1 BOX＝30 TAB，主档后改为新包装28；退原收货或从旧库存新发1 BOX仍按30 TAB；对应新包装入库用28，历史不重算 |
| 后到赠品 | 普通货全部收齐后可关联原批准药品登记后到赠品，普通量0；只增加本次赠品基本量，不重开已履行普通量或绕过新药审批 |
| 超约定同药赠品 | 原PO批准药品的约定赠品2、本次实际赠品3，Staff可直接验收3并展示超约定1，批次效期必填；不重审、不覆盖原条款，普通追加和未批准新药仍须新PO |
| 精度与剂量 | 0.0125 ML 全链保持0.0125；不变0.01；500 mg强度不扣500 TAB；无法精确转换的行阻止过账 |
| CP／clinic 转移 | CP100、发20→CP80＋在途20；收19→clinic19＋在途1，总量仍100；补发不得清掉原在途1 |
| 预留、冻结与消耗 | H100、R20、B10则A70；预留中5被召回后H100、R15、B15、A70，并阻断对应旧任务，不能双扣5 |
| 耗用与数量对账 | clinic20，发药3、废弃2→余15，净耗用5；对账确认不再扣；仅标失效4仍余15、不可用4，未实际废弃不得计入耗用 |
| 普通成功／失败退药 | clinic15成功回CP4→clinic11、CP+4；失败4不自动增减；返回失效药只加CP现存不加可用；实际废弃再扣一次 |
| 同批不同原单 | 原单A剩3、B剩7；选择A不能退5，不能借B补足；已有其他待办占用须扣可办理量 |
| 第三方／无原单 | 有第三方PO也先Staff例外→PIConly；批准不动库；未纳管来源实际入CP5不造clinic−5；已跟踪但不足不得绕过 |
| 换货额度 | 成功退6、替换已发4，再次最多2；clinic实收前次4不再占额度；新批次与原退单同时可追溯 |
| PO 改价与加量 | 收过6的PO10改价，保留原6及库存，仅结束余4并新PO审批；普通另加2为新补充PO，不修改原10或称赠品 |
| 盘点并发 | 账100，实盘98待批期间发10，不能直接把当前90覆盖98；需重核时点／差额后PIC批准一次调整 |
| 开账与重试 | 同来源导入批次重试不二次开账；切换后Excel／同步不覆盖流水余额；切换前耗用不再次扣减 |
| 召回 | PIC在已授权范围冻结批次后，阻止正常供货／发药；已冻结的在途实物可接收为不可用或登记原货回退，冻结不消失；Staff回收5仅移库5；未回收量保留，关闭任务不自动解冻；不以此断言全内部范围权限已实现 |
| Clinic 可见数量 | A clinic看到自身及CP数值＋单位，查不到B库存、其他clinic汇总或占用对象；伪造单位／详情ID／导出仍拒绝 |
| 身份与最小授权 | CP Staff保持Staff角色，仅能按授权诊所和采购动作代办PO，不得取得患者发药权限，真实登录人不丢；Finance审批不获得仓库写权限；restricted支持所有写入口被拒绝 |
| 幂等与更正 | 相同来源重复确认仅一次；两个并发出库不能超同来源可用量；更正保留原事实和关联反向记录，对账已确认版本不被静默改写 |
| 取消申请释放分配 | 申请20、分配15未发，CP确认全取消后R释放15、关闭20；已发5时最多关15，在途5仍须实收／处理差异 |
| 盘亏侵入预留 | H100/R90/B10/A0实盘80，必须明确实际缺少分段并使不足预留失效；不得出现负A或继续持有90的有效预留 |
| 整包装不足 | 两瓶各余60 ML且均拆封：H120 ML、未拆BOT为0；按整瓶供应1 BOT必须阻断，不能仅凭换算后的100 ML放行 |
| 跨单位核价 | 2 BOX×30 TAB/BOX、10/TAB得600；客户端传行额1不能覆盖服务端结果，批准和发送版本金额一致 |
| 多批次整单发药 | 应发30 TAB，来源A20+B10合计30；最终各扣一次，仍是整单领取；分摊变更必须重新备药复核 |
| 已付款来源失效 | 原批次冻结后阻断原领取；同药同量新来源重分配并重新备药复核后可恢复，不重走收费，无来源继续阻断 |
| 退药被拒的实物 | CP发出10、供应商拒绝，退药失败10但CP不自动+10，也不产生替换额度；实际收回时才+10 |
| 往返后退供应商 | S采购10→clinic10→退CP4，CP返回层保留S根；可从返回层向S供应商退4，clinic成功退4不占供应商方向额度 |
| 重叠期间确认 | 1–15日100已确认，1–30日220的查询显示总220；新确认不能另归属全部220并累计成320 |
| 补录及替代版本 | 原确认后补录一笔归属原期间的耗用，只生成待核替代版本；通过后取代旧版，不与差额单再计一次 |
| 第三方直接耗用 | 同药耗用10，其中CP普通2、clinic自购8：库存扣10、总耗用10，CP结算量2、第三方排除量8 |
| 赠品耗用结算 | CP普通来源耗用2＋CP赠品来源耗用3，CP结算量5，保留两类来源；不据零采购价排除赠品数量 |
| 第三方经CP再供 | Clinic第三方自购直接耗用4排除；剩余6经例外实际交CP、再供另一clinic后耗用2，后者CP结算量2，不把之前4改成CP耗用 |
| 患者回收实物及结算 | CP来源发药10后实际回收3，库存+3、累计结算量7；再实际销毁3，库存−3、累计结算量10；退款按钮不动库存 |
| 跨期回收 | 前期CP来源发药10已确认，本期实际回收3且无其他耗用：本期数量−3，原发药事实仍为10；后续销毁3再按实际日期＋3，不重复更正原发药 |

后续应用验收按项目规定使用本地完整服务链、Docker 内 Playwright 与官方完整 Chrome，保留实际版本、截图／录像／trace、控制台和接口错误证据。文档构建、交互演示、真实账本联调、部署及 UAT 分开计证。

## 9. 设计状态和本期边界

主流程、审批归属、必填收货信息、召回责任、数量对账及权限可见范围已经确认；09-09随后新增确认诊所自采须先由CP PIC单级同意、诊所直接下单并自行入库，已补入§4.2和对应界面／库存契约。这项采购批准不替代未来退药例外。上述业务决定不再放入“待用户确认”清单。09-09反例检视及随后逐项确认：第三方直接自购耗用排除CP结算，CP赠品和第三方经CP再供后的耗用计入；患者实际回收扣减、之后销毁计入；接收方接受退药才成功；原批准药品的额外赠品可由Staff直接验收；CP采购PO提交人、PIC审核人及Finance审批人必须三人分离。§3–§7、§10–§13的状态恢复、来源层、事务、精度、版本、入口和字段契约，是为实现这些决定提出的产品／工程设计，不宣称用户逐个确认了字段名或实际代码已有功能。

本轮复核提出的六项业务取舍已完成处理：耗用归属、患者实际回收、额外赠品接收及审批人员分离的确认已归入正文；最后一项全内部范围召回／冻结权限由用户明确暂缓，见§6.4，不再列为本期阻塞问题或继续追问。暂缓不代表已授权，也不删除已确认的基础召回设计。

本次直接补齐的逻辑包括：PO撤回／终止和关闭后到货出口、clinic取消释放分配、按单位接手、盘亏处理预留、采购根来源往返、整包装校验、跨单位核价、多批次发药及付款后来源恢复、对账唯一归属与更正版本。它们是设计闭合，不是新增已上线功能。

本稿完善产品方案与页面定义，不修改业务代码、真实角色授权或库存数据。仍有少量 SOP／资料待补：供应商资格资料、COA／冷链证明的适用条件与必填范围；最低剩余效期、拆封后的质量处理规则；实际销毁的留证及操作要求。这些没有已确认数值，不预设附件必传、自动放行或额外审批人；按当前严格的批次／效期及不可用控制设计，实施前由业务提供适用标准。

真实药品转换、机构映射、期初批次完整性属于实施数据核对工作，不再要求用户逐药解释；未明行显式阻断，其余可继续。NetSuite 实际打通、OCR 自动过账、自动补货、复杂财务成本与多仓库仍不在本版设计范围。

## 10. 角色、可见范围和动作权限

### 10.1 目标操作矩阵

现有角色沿用 `wdl-pharmacy-staff`、`wdl-pharmacist-pic`、后台 Finance 和 Clinic Pharmacy；具体动作授权须按此目标补齐，不能仅靠 App 可见性。

| 动作 | WDL Staff | WDL PIC | 后台 Finance | Clinic Pharmacy |
|---|---|---|---|---|
| CP 供应商 PO 创建／修订／提交 | 是 | 不自动继承 Staff 创建权 | 否 | 否 |
| CP 采购审批 | 否 | 第一级 | 第二级，待PIC通过 | 否 |
| 人工发送登记、收发、实收及退药执行 | CP 运营动作 | 按实际仓库执行授权；审核角色不自动包含全部动作 | 否 | 不获得 CP 动作 |
| 诊所自采 PO 创建、提交、发送登记及自行收货 | 保持Staff角色，按目标诊所分别授权采购／发送／收货动作；无隐式全权 | 无隐式诊所执行权 | 不自动获得操作权 | 在当前获授权clinic执行，不动CP库存 |
| 诊所自采采购同意 | 否 | 单级审批当前版本，不可审批本人提交 | 无本流程审批节点 | 无自批权 |
| 缺单／第三方退药例外 | 申请及办理 | 审批 | 否 | 可提供申请来源，不绕过CP例外流程 |
| 盘点 | 录入实盘与原因 | 审批差异 | 否 | 不因数量查询获得调整权限 |
| 召回 | 联系、跟进与记录结果 | 已授权范围内发起和管理；全内部范围权限暂缓 | 否 | 查看自身相关任务，患者处理遵循临床权限 |
| 药品／供应商／单位关系维护 | 查询选择 | 管理；沿用共享主档授权 | 价格维护遵循独立授权 | 只看授权业务资料 |
| 向 CP 申领 PO 提交 | 保持Staff角色，仅获授权目标clinic及采购动作 | 无隐式代下单权 | 否 | 提交当前clinic的PO |
| 患者实际发药 | WDL无此动作 | WDL无此动作 | 否 | 在Drug Dispensing按实际授权执行 |
| 数量对账 | 查询／生成授权范围记录 | 查询检查 | 核对并登记确认结果 | 只查自身获授权记录 |
| 覆盖余额／删除已生效流水 | 否 | 否 | 否 | 否 |

普通CP收发及有原单退药不额外插入采购审批；PIC、Finance的采购决策与退药例外／盘点审批是不同任务。所有审核必须校验当前节点、版本及真实审核用户。CP自身采购PO按§3.1校验提交人、PIC和Finance三人分离，不能用切角色绕过；诊所自采按§4.2仅PIC单审，普通收货／分发不增加三人审批流程。CP PIC可查看被路由到其授权任务范围的诊所自采单据和采购快照，不由此获得诊所患者资料或自行修改收货权。

### 10.2 Clinic 库存数量展示

Clinic Pharmacy 的库存视图固定显示 **My clinic** 和 **Central Pharmacy** 两个范围，CP 展示实际数值、明确单位与更新时间，建议并列 On hand／Available，避免把预留和不可用数当作可供量。不得退化为只有“有货／无货”。本诊所可下钻获授权来源与自身流水；CP 数量是用于申领的只读供货信息。

CP 数量接口只返回许可的药品和数量投影，不返回其他诊所分项、其他诊所库存合计、占用者／患者、采购价格、供应商合同或他所流水。搜索建议、筛选计数、导出、直链和接口也遵守相同范围；不能先把全量数据传到浏览器再隐藏列。查询失败／尚未建立账本显示未知和原因，不显示为零。

WDL 人员按获授权内部供货范围看 CP 及相关 clinic 库存；Finance 只看其已授权来源范围的 PO／对账。库存读取不是患者资料访问许可，也不是扩大后台到全集团范围的理由。

### 10.3 会话和只读

工作区持续显示有效单位与角色；切换清除旧范围数据、选择和未授权动作，保护未保存输入。所有详情、选择器、写入及导出在服务端用真实会话检查集团／单位和动作，不能相信请求中的 `operating_unit_id` 或客户端筛选。

Restricted support 优先禁止业务写入，包括已打开表单、价格快照写入、导入、审批及库存动作。`read_only_clinical` 不是 CP 全只读；unrestricted 功能测试的成功不能当作真实 Staff／PIC 权限证据。旧独立原型的角色开关仅为演示，不接入生产权限。历史 Membership 的后台兼容与账户治理遵循平台规范，不在 CP 另建账号体系。


<a id="11-前端页面与关键交互"></a>

## 11. 共用交互与反馈

<a id="114-共用反馈与显示"></a>

### 11.1 共用反馈与显示

遵循 [Desktop UI Design System](https://virtus-patient-emr-prd.vercel.app/desktop-ui-design-system.html) §4、§8、§9：复用 AppWindow、Element Plus 表格／表单、AppDialog、Iconify、Tailwind 和共享主题；文案默认英文，正文14px、数量右对齐且单位清楚。白底紧凑标题和工作面板，6／8／12px语义圆角，不复制旧 CP 的局部装饰样式。

状态筛选与搜索紧邻列表；New 在标题动作区，Save／Confirm 在所属任务底栏，一个区域一个主动作。长药名、单位、效期和确认按钮在1280px、1366×768及窄窗口可读可达；表头／底栏固定时只滚主体。错误、未知、无权、无匹配和真实零库存分别显示。

前端预测数量不代替服务端结果。提交前摘要、冲突原因、输入保留、未保存保护、键盘焦点和完成后的来源记录均需具备；权限或版本变化后禁止使用旧表单继续写入。

## 12. 结合当前代码结构的实施差距

代码核对：2026-09-09已fetch `origin/dev/theron-li`与`origin/stg`；本稿业务代码基线为`8080158`，包含当时STG `b01f6fc`。本次另只读复核最新STG `99421d2`，本次新增自采所依赖的CP采购服务、Clinic目录来源及API相关语义相对`8080158`未变；`clinic_direct`仍是目录优选，尚无采购／收货流程。下表其他库存链差距沿用此前`af72fb2`只读核对证据，引用行号仍基于`8080158`（最新STG的db_init后段+32、clinic_workflow相关段+144）。下列为代码事实，非实时数据库、部署或UAT证明；不宣称本工作树已合入后续STG。

### 12.1 能复用什么、缺什么

| 领域 | 已有代码基础 | 与本版目标的差距 |
|---|---|---|
| 药品／来源 | `db_init.py:4754` canonical 药品、CP映射与 `clinic_drug_supply_listings`；`clinic_workflow.py:6381` 选择本诊所／CP供应来源 | 目录选择不等于真实库存数量授权；同品、包装与来源关系须核验 |
| CP 库存查询 | `cp_warehouse.py:86/142` 返回 `dispense_unit`、stock、lock及差量；`db_init.py:2727` 数量4位 | 不是地点／批次／来源实收台账；stock−lock未扣质量不可用，不能直接标本版Available |
| 单位解析 | `sync_analytics_cp_drugs.py:66/93` 解析旧单位候选、`pack_unit`文本已有 | 没有商品级精确系数、基本数量、转换版本、步长；剂量字段兜底不构成库存单位依据 |
| 诊所自采 | `db_init.py:4775–4795`和`clinic_workflow.py:6411–6437`为`clinic_direct`目录及优选；`clinic/routes.py:3270/3330/3380`只有相关查询／策略；不是实际采购批准或收货事实 | 缺诊所自采PO类型／所属单位、PIC单级任务、诊所发送／分批实收API与页面；不可把现有CP PO单审或stock导入直接当作该流程完成 |
| PO 服务与页面 | `cp_warehouse.py:776–1080` 创建、修改、提交、审批、驳回和发送；`CPWarehouseWorkspace.vue` 已有列表／创建及状态动作 | 单层PIC路径；无PIC→Finance链、完整提交快照、新旧PO替代链和收货闭环；已有详情API不等于完整单据详情页 |
| PO 行与数量 | `db_init.py:4200/4208` PO行；`cp_warehouse.py:779`以金额函数处理数量，`:773/781`接受客户端line_total或直接数量×单价，`:930`删除后重插行；Vue默认box／自由文本unit | 数量仅2位，跨计价单位核价不完整且金额可由客户端决定；缺稳定药品FK、跨版本行身份、普通／赠品实收、转换快照；接入前须修正 |
| 发送记录 | `cp_warehouse.py:1075` 存server `sent_at`和`send_reference`，并不发送邮件 | 须改为用户输入实际发送时间＋recipient，另保留系统登记时间；不强制旧reference |
| 药房数量链 | `db_init.py:4934` dispense_qty4位，`:2276` medication quantity2位；`prescriptions.py:565–586` 传入执行单 | 处方→执行→耗用均须无损；unit缺失时dose_unit兜底不可用于库存过账 |
| 审方／发药 | `cashier_workflow.py:934/974/1000`审方库存证据、单批次配药及最终历史；`:896–913`付款后阻止常规Review／Hold；`cashier_rules.py:28`非自动分配 | 缺多批次真实分摊、同药同量换来源恢复与最终库存事务；manual／test证据不是真实预留，目录优选也不是真实耗用来源 |
| 预留／欠货 | `db_init.py:2866` 与 `cp_warehouse.py:589/611` 记录及查询基础 | 文字原单／分发reference、样例数据不是申请→实际分发→实收FK闭环；真实写入、并发分配和在途待补 |
| 库存导入／同步 | `import_exports/callbacks/pharmacy_stock.py:54` upsert覆盖数量／单位；`sync_analytics_cp_drugs.py:117/167` 同样覆盖stock／lock／unit | 现状有直接库存写入，但缺统一过账；开账后两条路径都需改为受控资料更新／核对。导入schema按drug code去重、callback按legacy ID冲突，身份需统一 |
| 角色／范围 | `route_permissions.py`、`cpWarehouseAccess.mjs` 已控制部分PO及warehouse动作；Finance现有读取，Staff创建提交，PIC审批发送 | 新双审、例外、盘点、召回、数量对账、Clinic数量投影及所有对象scope需补；已有动作检查不证明服务按每条单据限制单位 |
| 实收／退换等 | CP Blueprint现有采购与查询；未发现本版独立收货／退药例外／盘点审批／召回事务实体与完整写API | 全部保持待开发；同一来源层余额、过账幂等、差异处理、来源上限和全链测试须一起落地 |

初始化权限只是代码默认，部署数据库可能有历史／人工授权，必须用实际会话验证。现有价格 `approval-records`、临床 `return-to-doctor` 都不能当作本版实物退药例外审批。临床批号文本和效期记录也不等于已经关联真实批次库存。

### 12.2 按现有分层落地

- **Vue：** 保留 `CPWarehouseWorkspace.vue` 作为 App 入口，将本版三个工作区拆成业务组件；API 继续通过 `varclip_vue/src/api/cpWarehouse.js`，按钮读取真实会话权限与任务状态。复用单一数量／单位输入组件与来源批次选择器，前端不独立维护权威余额。
- **Flask：** 沿用 `blueprints/central_pharmacy/routes.py` 注册路由、service承接校验和事务；采购审批、库存过账、单位解析／快照和查询投影分清责任。CP采购与诊所自采的类型、审批链和收货单位由服务端确定；单级旧API不可让客户端任选审批链绕过CP Finance。创建／读取／写入均校验当前业务单位，不只在列表使用客户端过滤条件。
- **数据库：** 在 `db_init.py` 补bootstrap定义，并提供既有数据的可重复执行迁移／校验；不能只有新库schema。保留canonical映射、来源稳定ID、PO原行与版本，新增实体按§13关联，不删除被引用历史行。
- **跨模块：** 药房执行把实际数量与来源键交统一库存服务；Finance查询同一版本对账／PO；主档同步有字段白名单与账本切换控制。跨服务消息需有持久的去重与失败状态，不能“发药成功但库存失败”静默丢单或重复补扣。
- **实施顺序：** 先稳定药品／来源／单位及精度，再开账与统一过账；并行补PO双审和单据详情；然后接CP收货→分发→clinic实收及诊所自采PIC审批→本诊所直接实收，两条来源再汇合真实耗用，再完成退换／召回／盘点／数量核对及范围验证。任何尚未接入真实台账的页面继续明确数据来源，不将旧stock查询伪装成新账本。

## 13. 数据对象、来源链与历史依据

以下为需要满足的逻辑契约，字段名及表名由工程在既有结构中实现，非已经存在的完整schema。

| 对象 | 必须保存的关联和关键事实 |
|---|---|
| 商品／供应来源／机构 | canonical drug、CP本地ID、supply listing、legacy来源、有效集团／unit；供应商稳定身份；名称只是显示快照 |
| 单位关系版本 | 商品／具体包装、from单位、base单位、精确比例、步长、适用条件、生效版本、来源及维护人 |
| Supplier PO／行／提交版本 | 明确CP采购／诊所自采类型与采购及收货单位、对应审批链；稳定PO和行身份、supplier／drug／unit／price快照、原订购、赠品条款；新旧PO关联及已履行保留量 |
| 审批事件 | 对象＋版本＋节点、提交／通过／驳回、真实用户、角色、单位、时间和理由；CP采购Finance不替代PIC事件，自采单只生成PIC任务；采购批准不与退药例外互换 |
| 发送记录 | PO批准版本、实际发送时间、收件人；登记人／系统时间自动审计，无其他必填手工发送资料 |
| 收货／行／来源层 | PO行或明确的开账／例外／换货来源，父来源与采购根、直接自购／CP再供性质、批次效期、普通／赠品、原数量单位与换算、base量、包装分段、可用性及实收时间 |
| Clinic request／分配／dispatch／receipt | 原申请量、分配的来源层、实际OUT、逐分发行在途、实际IN、差异和关闭原因；所有明细有稳定ID |
| 余额／预留／流水 | drug＋地点＋批次＋来源层、A/R/B、源和目标、供货／退回发送方等移动目的、精确base增减、业务时间和过账时间、来源事件、版本、幂等键、更正关联 |
| 退药／例外／替换 | 原实收或已批准例外版本、方向、成功／失败分量、已实际执行各侧、实物位置、来源额度及替换额度；外部交付状态不当作内部现存 |
| 盘点／召回 | 时点与范围、基准／实盘／差异、PIC审批；召回批次范围、冻结、受影响来源、联系记录、回收和未回收原因 |
| 耗用／数量对账 | 发药／废弃／患者实际回收及错误更正分别关联，真实来源分摊及性质、用途、地点、base量；实际日期与登记时间、期间时区、所含分摊唯一归属、替代版本、纳入／排除／待核分量及Finance历史 |
| 通用审计 | 真实登录用户、有效角色／单位、业务对象和版本、业务时间、系统时间、原因；可追溯且不开放临床资料给无权角色 |

OUT／IN或调用重试共享业务关联，但每个合法动作有各自唯一过账标识。原请求相同内容重试返回既有结果；同一幂等键换内容应拒绝。导入来源行ID、正常实收来源和例外首次纳管来源分开，不能为了建立FK伪造一张历史采购单。

### 13.1 已核对的历史药品与机构样本


以下仅为09-06核对的历史导出和原型取材证据，不是本次实时库；数值ID不跨环境硬编码。

药品业务身份以 `cp_drug_master.id` 为 CP 本地键，保留 `legacy_drug_id`、`drug_master_id` 和供应目录映射；`clinic_drug_code` 是展示／来源编码。972 条均有关联映射，但名称存在重名，不能用名称 join，也不能把页面显示码当作所有环境中的全局 ID。

| CP 主档 ID → canonical drug ID | 展示编码 | 主档名称 | 库存单位 |
|---|---|---|---|
| 941 → 16836 | TABBR052 | BRUFEN (NUROFEN) &lt;Ibuprofen&gt; SC TAB 200MG {12'S} [G.E] | TAB |
| 795 → 16260 | TABSE079 | SEVEN SEAS JOINTCARE ADVANCED CAP {30'S} | CAP |
| 661 → 14741 | EXCMU011 | MUSTELA STELATOPIA CLEANSING CREAM {500ML} | ML |
| 226 → 3854 | TABRE080 | REVLIMID &lt;Lenalidomide&gt; CAP 15MG {21'S} | BOX |

名称含 CAP、mg、500ML 或 21'S 不构成换算规则。最后一项按 BOX 计数；第三项按 ML 计数。库存录入支持源数据的小数精度，显示明确单位；赠品按§3、§7独立记录并转换到对应商品的基本单位。实际生产实现应统一数量精度，不以前端浮点运算作为账务最终依据。

机构来源为 `clinic_operating_units`：快照共 25 条，含 23 个 clinic、一个 CP、一个 Group Admin。原型选择下列真实机构样本，不使用无主档依据的“Kowloon Clinic”。

| 快照 ID | unit_code | 名称 | 业务范围 |
|---:|---|---|---|
| 3 | CENTRAL_PHARMACY | Virtus Central Pharmacy (WDL) | `wdl_pharmacy`；唯一 CP 主存货地点 |
| 5 | CLINIC_C28CC4F0 | Virtus Orthopaedic Centre | 内部 clinic |
| 6 | CLINIC_D32F8143 | The Heart Clinic Central | 内部 clinic |
| 8 | CLINIC_018FD875 | Virtus Children at 818 | 可扩展的内部 clinic 样本 |

单据保存集团与 `operating_unit_id`，选择器只显示当前有权操作的内部机构，不让管理员机构进入临床收货目的地。跨环境迁移使用集团＋unit_code 或经核对的 legacy UUID 映射；ID 数值和名称均不能跨环境直接假定一致。CP 同步源 UUID 与 OperatingUnit 的 legacy 字段尚无直接对应证据，不假装已有自动 join。


## 14. 单据关联与端到端核对

```mermaid
flowchart TD
  P[CP供应商 PO 稳定行＋版本] --> A[PIC事件＋Finance事件]
  A --> S[人工发送记录]
  S --> R[CP实收行＋单位快照]
  R --> C[CP来源批次层]
  Q[Clinic申请行] --> D[实际分发行]
  C --> D
  D --> I[Clinic实际实收行]
  I --> K[Clinic来源批次层]
  DP[诊所自采PO行＋版本] --> PA[PIC单级采购批准]
  PA --> PS[诊所人工发送记录]
  PS --> PR[本诊所供应商实收行＋单位快照]
  PR --> DK[诊所第三方来源层]
  DK --> U
  PR --> X
  K --> U[实际发药／废弃来源分摊]
  U --> F[数量对账版本＋Finance确认]
  I --> T[Clinic退药行]
  R --> TS[供应商退药行]
  E[无CP原实收／第三方来源] --> X[Staff例外版本 → PIC审批]
  X --> T
  X --> TS
  T --> L[关联库存流水]
  TS --> L
  L --> H[余额、在途与审计]
```

订单详情的 Create return 和 Inventory → Returns 打开同一张表单；更改机构、药品或单位关系时，清除不再匹配的来源选择。只有有效实收及尚可办理来源可选，文本单号不替代关联。审批完成返回原单；实际办理后显示过账结果与可追溯记录。

核对的重点是原数量和实际结果能否一路追溯：CP PO原行 → 实收 → CP来源 → 分发／clinic实收 → 耗用或退药；另一条为自采PO行 → PIC批准 → 供应商发送 → 本诊所直接实收 → 自采耗用或单独例外退CP。每笔都保留实际来源及审批用途。任意环节出现重复来源、未知单位、变更版本或过期授权，均在提交点阻断并解释恢复步骤。

## 15. 文档、原型与验收的边界

本文件是唯一CP日常产品规范。代码／底表精确位置以本稿§12所注明提交为准；后续实施需重新fetch核对。领域之外的权限、临床门禁、财务工作台和共享UI通过链接引用，不逐轮复制完整正文。

历史原型及说明（仓库资料：assets/central_pharmacy_20260906/README.md）保留v0.3当时的模拟资料、演示步骤和实际验证。它仅在浏览器会话内算数，不读写真实库存、不发邮件、不连接NetSuite；旧CP自身采购PIC单审、旧权限演示及部分交互不符合本版全部要求。旧验证结果不重写成本版已通过。

本轮仅文档构建／链接及规则一致性核对；应用开发、完整本地链路测试、开发分支发布、App预览、PRD发布、STG／UAT分别记录。发布方法见 PRD preview README（仓库资料：prd_preview/README.md）。本稿不以文档发布证明收货、来源台账或Finance双审已经上线。

## 16. App入口收敛及现有工作台边界

09-06已按用户要求，将CP Warehouse、Pharmacy (WDL)、重复Inventory及WDL规划壳收敛为 **Central Pharmacy**，沿用canonical ID `central-pharmacy-warehouse`；旧布局迁移到同一入口。后续桌面分类以 [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html) 为准，不恢复重复App。

现有 `CPWarehouseWorkspace` 的 Stock catalogue 是CP同步目录和汇总字段查询；其他查询／采购标签不等于本版 Orders／Inventory／Master Data 已完整落地。Staff／PIC读取当前会话动作权限、没有权限不请求数据及清除旧角色数据属于已有基础；新的细粒度操作与数量视图仍需后端验证。

Drug Dispensing保留患者药房工作区，并以独立Clinic orders／Stock标签承接§11.1的诊所供货需求；Clinic只查看CP数量不会获得Central Pharmacy管理入口，也不新增另一个Inventory维护同一余额。

## 17. WDL、Clinic Pharmacy、Finance与其他领域交接

WDL承载CP仓储、自身供应商采购及供货执行，并由PIC审批获授权的诊所自采申请；Clinic Pharmacy承载本诊所向CP申领、获批后向供应商自采／自行收货和患者药房工作。CP Staff代诊所提交PO时保持Staff角色，按§4.1明确的目标诊所及采购动作授权执行；不获得患者发药权限，真实登录身份始终保留。这取代旧稿“业务来自clinic也始终留WDL操作患者处方”的泛化规则，不改变WDL仓储归属。

Finance仍统一在后台，按授权来源打开CP自身采购PO的第二级审批和耗用数量对账；诊所自采PIC通过后即可执行，不纳入该第二级审批，价格维护遵循共享Catalogue授权。Finance不会自动继承收发、盘点、召回或临床写权限；完整双审动作与数量对账界面属于本版待实现目标。患者附件、Day-end Revenue Report及后台Membership兼容采用其canonical规则，本稿不重定义其范围。

- [Pharmacy／V-Lab](https://virtus-patient-emr-prd.vercel.app/pharmacy-vlab.html)：审方、真实库存预留、结算门禁、备药复核、患者发药与取消／退回；CP供货及数量服务接入同一来源。
- [Catalogue](https://virtus-patient-emr-prd.vercel.app/catalogue.html)：稳定药品／商品与价格权威；CP记录实际库存和单位版本，不建第二套价格主档。
- [Cashier](https://virtus-patient-emr-prd.vercel.app/cashier-followup.html)：患者收费／付款和已确认收入报告；CP数量对账不自动产生这些财务动作。
- [组织与权限产品方案](https://virtus-patient-emr-prd.vercel.app/platform-ai.html)：单位／角色／动作、患者与商业资料最小授权和审计；供应目录可见不能替代库存数量权限。
- NetSuite仅保留稳定业务ID、来源和未来映射所需的接口边界，不展示虚构的连接成功、同步状态或本期自动对账按钮。