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

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

功能地图

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

1. 范围与权威边界

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

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

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

以上权限于 2026-09-14 确认，完整规则见 权限矩阵。本轮更新 PRD，新增范围仍待代码核查和验收。

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

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

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

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

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 人工证据与测试库存

测试模式保留逐张药师审核、签署版本完整性、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、重签版本规则继续。配置、部署、回滚及执行证据只维护在 测试库存验证记录，STG 实际启用与源码实现分别记录。

4. Cashier 结算与本次价格

结算确认条件以 Cashier 结算功能 为唯一付款规则来源：2026-09-10 已确认患者全额／部分欠款及 CoPay 欠款经显式登记安排可放行备药。药房消费结算结果，不把应收当作实收，不另设患者必须付清的重复门禁。

4.1 一次性结算

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

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

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。

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 当前分阶段工作区

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

实际 Vue 合成预览 复用 DrugDispensingWorkspace，模拟仅在明确 preview 路由生效，不调用真实变更或打印。正常模式 API 失败不能回退假数据。早期交互草案 仅保留评审来源，不作为当前 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 为准。

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

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

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

代码入口：处方服务、队列及药房退回、Cashier／药房事务、库存和最终核对规则、Drug Dispensing 工作台、前端动作门禁。

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

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

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

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

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

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

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

CP 详细规则以 独立 PRD 为准：一个 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 开单及内部执行仍在产品范围，执行组件接入后提供真实入口；移除壳不表示已交付或取消范围。

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、安全及接口规则沿用各自权威规范。