Lab · 检验执行、报告与试剂库存 PRD

更新：2026-10-20 · 责任：Line C，衔接 Line B／Line A；实施映射：WS3／WS4，依赖 WS5／WS6。

文档状态：业务规则已确认，2026-09-23 已补齐本期 P1–P5 内部流程代码，待运行验证；完整验收尚未完成。 本篇是 Lab 的唯一日常产品规范，由原 Pharmacy／V-Lab §11 拆出。用户明确要求 Lab 独立板块，并统一将实验室系统称为 LIS；本轮集中设计 AI-CLIP，自身流程不再以 LIS 接口澄清为前置条件。本期允许内部服务契约、来源及外部关联结构预留；LIS 真实连接、供应商字段映射实现、编号互认、网络协议实施、联调及自动状态同步留待后续。

2026-09-22 需求研讨，2026-09-23 实施： 用户再次确认本期只完成 AI-CLIP 内部流程，预留 LIS 接口。PW LIS API v1.19 仅用于核对未来适配边界，本期不实施真实对接；用户另确认优先级标识、采样身份核对及诊所／Lab 采集职责，见 §1.2、§1.3、§3、§6。实施前差距、实际落点与接口预留见本轮实施方案，各包状态和未执行的验证见实施交接 §8。

2026-10-20 工作台改版： 按用户参考图重组任务视图、紧凑筛选、五列工作队列和右侧只读详情。用户明确要求加急单排最前，取代此前“加急仅标识、不改变顺序”的决定及参考图中的对应说明；同优先级内继续按既有等待／历史排序。源码已接入，完成静态解析及人工链路核对，未运行测试、构建或浏览器业务验收。

来源：用户附件 AI-CLIP_VLab_System_Requirements.pdf、2026-09-14 16:32 会议及后续需求讨论。来源与时间定位见会议证据索引。当前明确决定优先于会议措辞和历史方案。下文“已确认”只指用户明确回复；“设计方案”是为实现这些目标提出的具体页面、状态和处理方式，不表示用户已逐项批准，更不表示代码已完成。

界面交互方案图提供页面布局和动作说明；它是可点击的设计说明，不连接临床／财务数据，不执行收费或报告发布。后续模型从完整交接文档开始；内部模块与服务职责见Lab 工程方案，实际执行记录与 PRD 分开维护。

功能地图

1. 范围、分工与已确认规则

1.1 系统与业务边界

AI-CLIP 负责医生开单、检验结算交接、样本记录、工作队列、正式报告的归属／人工发布、月报和试剂库存。LIS 继续承担实验室检测、仪器连接、结果核验授权及正式报告生成；AI-CLIP 不新增检验结果专业核验界面，不以“发布报告”替代实验室授权。

界面 App 名为 Lab，默认内部执行实验室实体为 V-Lab。内部／外部实验室是执行去向，不按其是否使用第三方软件判断。采集人员与收银护士可以是不同人员；本方案不新增开单／提交审批，不假定每位护士均有采集操作资格。

Lab 独立执行工作台属于本期范围。旧 lip-lab-service-order 是已退出日常目录的规划壳，不能视为已有执行能力；新工作台按本篇重新定义四个业务入口，不恢复旧壳全部 Tab。应用目录与权限实现须按 Platform 注册；本次文档拆分不修改真实账号授权。

2026-11-02 用户确认的护理检测分组预约与提醒见 Frontoffice §4.7.3：V-Lab 组由护士确认后建立／关联正式预约，精确来源的预约时间自动呈现在获授权 Lab 请求及执行详情；第三方时间由人员记录。正式检验交接仍受原签署及结算门禁约束，预约不代表已执行、已采样或已联系。Imaging 的检查执行、影像报告及第三方自行开单／Excel 批量导入，不因这项护理预约安排而新增范围。PIC／Director 跨实验室总览属于后续方向，不新增跨诊所全量临床读取权限。

1.2 用户已确认的基础规则

1.3 Lab 岗位与报告阅读

现行角色目标以 Platform 的 13 角色模型 为准。 唯一化验角色 Laboratory Manager 属 Back Office，只读获配 Lab 的原始 request 及 request details，用于核对实验室外部系统资料；Lab 必须有明确 vendor 映射，缺少映射拒绝访问。该角色不提供内部样本处理、报告发布或库存操作，不能因能打开 Lab 或阅读 request 而取得本篇执行动作。

未完成 cutover 的 legacy 实现另行保留： 2026-09-23 内部流程及当前兼容代码仍包含 Lab PIC／Lab Staff、原 lab-bu，以及诊所采集／外部报告专用岗位。其历史职责为：Staff 在所属 Lab 登记样本、登记／更正及人工发布报告，处理入库、开封、耗用和报废；PIC 另可撤回报告及调整库存；双方可查所属 Lab 完成量月报。这些是旧模型的权限边界和实现来源，不是 13 角色目录的新任职规则，也不证明任何环境已完成迁移或当前账号仍有这些权限。旧角色不会自动获得其他诊所完整病历、跨 Lab 总览或 Laboratory Manager 身份。

医生／诊所人员读取已发布 Lab 报告，沿用现有病人／来源就诊的归属、护理服务及有效临床访问关系，不增加单独的 Lab 阅读分配，也不逐份申请报告授权。只有基础患者查询资格并不等于完整临床资料阅读资格。草稿及未发布报告仍限执行人员；可阅读不意味着可登记、发布、撤回或调整库存。

新增任职、停用旧岗位及迁移按 Platform 的显式 cutover 流程执行；没有批准映射的有效旧岗位持有人必须停止迁移并报告，不能自动转成 Laboratory Manager、PIC 或其他岗位。历史任职、作者和审计快照保留。本文的内部执行流程约束既有获授权路径；其在 13 角色模型中的人员承接不能从旧种子或界面入口推定。

采集职责（2026-09-22 用户确认）： 来源诊所获授权采集人员可处理自己有权诊所的已放行检验采集任务；V-Lab 人员可处理所属 Lab 职责内的采集任务。入口与 API 必须同时校验采集动作资格、来源／执行单位范围及有效结算。采集权限仅提供完成当前任务必要的身份、项目和样本资料，不自动包含未发布报告、报告发布、其他 Lab 订单或库存权限。2026-09-23 已通过旧模型专用岗位和来源诊所动作范围接入代码；该实现不代表已完成 13 角色承接，人员分配及各环境多角色运行验证须分别留证。

1.4 Lab 组织配置与人员承接

Organization → Labs 是内部实验室的独立组织入口，显示当前集团的 Lab 单位及启用状态；无记录时引导管理员新增。Add Lab 默认 Lab 类型，Working units 的新增表单也可选择 Lab。单位需明确名称、集团内唯一代码及配置原因，初始启用，不作为 Clinic 或患者就诊地点。

创建单位不自动创建用户或授予岗位。13 角色目标下，人员由 Users 按 Platform 配置 Laboratory Manager 的 Back Office 任职、获配 Lab 及必要 vendor 映射。旧模型曾以 Lab PIC／Lab Staff 绑定 Lab，并在 Assume role 的 Lab 场景预览；这只描述 legacy 配置路径，不是要求恢复旧角色。实际人员模式始终需要有效任职和对象授权，角色模板预览不能替代真实人员授权；组织保存或预览可见均不表示角色 cutover 已完成。

已有环境由管理员显式创建或复用 V-Lab 单位；启动时不自动生成、重新启用或跨集团复制组织。角色目录存在不代表组织已配置，组织已创建也不代表已完成人员分配或 STG 验收。

2. 页面架构与完整业务流程

2.1 从哪里进入

flowchart LR
  C[Consultation · Service 检验开单] --> B[Cashier · Laboratory 费用组]
  B --> W[Lab · Worklist]
  W --> D[执行单详情 · 采集与交接]
  D --> R[Lab · Reports]
  R --> V[原 Consultation · Results]
  R --> M[Lab · Monthly Report]
  I[Lab · Inventory] --> H[物料详情 · 批次与流水]
  S[Lab · Settings] --> K[Catalogue 同一项目和价格编辑器]

既有内部执行工作台的四个入口： Worklist、Reports、Inventory、Monthly Report，按当前有效动作显示可访问项；具 Worklist 权限时首次进入默认 Worklist。Settings 是右上角轻量入口，只提供有权限访问的 Catalogue／物料维护入口，不再建立第二套 Test Master 或价格表。此导航描述 legacy 执行能力，不授予 Laboratory Manager 报告、样本或库存动作；该角色只读 request 的目标范围见 §1.3。医生和护士继续使用原 Consultation／Cashier，不为了检验重复创建患者或 Visit。

页面沿用已落地 Consultation／Cashier／Catalogue 的共享组件、视觉层级和导航方式；跨 App 交接携带稳定 Patient／Visit／Order 标识，返回保留来源筛选及当前工作，不复制独立目录或收银界面。

2026-10-15 界面改造参考 9 月 25 日前的 Consultation 工作台，统一磨砂导航与筛选、白色任务分区、患者身份摘要、报告并排预览及库存证据层级；操作和选中颜色跟随系统主题。具体发现、实施范围及浏览器验收限制见界面审计记录，不改变本 PRD 的权限、状态、校验与业务规则。

列表用全宽表格；点击患者或检验单在右侧查看只读详情，处理动作进入既有全宽对象工作区或登记表单，返回恢复原筛选、分页及滚动位置。报告处理使用订单摘要与文件预览并列布局，窄窗口改上下。库存和月报是独立页面，不混入患者采样步骤。

2.2 主流程及各步结果

flowchart TD
  A[医生保存并签署检验申请] --> B[护士独立确认检验结算]
  B --> C[系统按实验室生成或放行执行单]
  C --> D{执行去向}
  D -->|内部 V-Lab| E[确认患者和样本，登记采集]
  E --> F[样本待取件，记录实际交运]
  F --> L[所属实验室登记实物收样]
  E -->|同 Lab 现场采集| L
  L --> G[等待正式报告]
  D -->|外部实验室| X[转介并人工收取报告]
  G --> H[我方登记正式报告，关联原订单项目]
  X --> H
  H --> I[V-Lab 或相应获授权人员人工发布]
  I --> J[医生在原就诊查看，复诊可引用]
  I --> K[按已完成项目进入月报]

图示表达典型实物及报告链路，同 Lab 现场采集无需补造交运；实物收样记录不新增 §7 以外的报告发布门禁。“等待正式报告”期间不提供伪造检测进度的按钮。报告登记采用 §7 的我方入口设计，LIS 如何传输文件暂不展开。现行报告不直接自动发给患者，医生按临床安排解释／打印／跟进。

2.3 业务对象与归属

3. 医生开单与目录衔接

Consultation review 范围（2026-10-27 用户澄清）： 护士弹窗只保存同一次 Consultation 的 Service、供应商和本次价格。本次不修改 Lab 的业务逻辑、来源模型、结算门禁、交接触发、执行状态或与其他模块的流转关系；不直接创建或重建执行单。后续沿用现有流程读取 Consultation 数据，既有执行保护继续适用；本领域只做兼容性回归，不能由此新增 Lab 改造任务。

目的与使用者： 医生在原 Consultation → Service 选择本次检测，不进入 Lab 工作台再次开单。项目／vendor 两条入口、AI 仅推荐项目、V-Lab 优先展示、多项目覆盖和价格比较的唯一交互规则见 Consultation §5。2026-11-05 用户确认取代自动默认 V-Lab 与整份申请统一优先级的旧呈现。

逐项加急不自动产生额外收费或推定处置时限；外部 vendor 仍不建设内部执行工作台。Imaging 的优先级保存在临床来源中，不因此新增 Lab 执行单。执行排序沿 §5，同单保留明细区别。

4. 检验结算与执行单放行

LB-01（已确认）： 以当前检查申请和有效检验费用组的 Settlement confirmed 放行执行。实收、零额和已明确确认的保险／欠款安排可满足；仅开票、打印或存在应收记录不能放行。药品审方／库存门禁不阻断检验独立结算，检验结算也不解锁药房。

采样前必须先放行检验结算。 这不等于“患者必须先用现金全额付清”：实收、零额结算，或 Cashier 已按付款责任明确确认的保险／欠款安排，都可产生 Settlement confirmed。在此之前可在医生／Cashier 查看待结算申请，但不生成／放行可采样执行单，不进入可采样 Worklist，也不能以“先采后补”绕过结算门禁。紧急医疗例外尚无已确认契约，不由界面或 PRD 助手自行推定。

Cashier 界面按选中费用组显示金额、付款责任、收款及主动作，细节唯一见 Cashier 检验费用组交互。Lab 只读显示结算结果及来源，不复制收款功能。未结算申请在医生／Cashier 中显示待结算，默认不混入可采样 Worklist；已撤销或失效的结算在原执行单显示阻断及待处理原因。

设计方案： 结算与待执行交接记录同一事务保存，提交后以申请版本和实验室为稳定来源幂等生成执行单。用户只做一次确认，无需再次新建 Lab Order。结算成功、交接失败时显示 Lab settlement confirmed · Handoff pending；重试交接复用原结算，不重新收款、不重复创建执行单。多实验室分流逐单记录结果，部分交接失败不能掩盖成功部分。

已结算不等于已采样，检验已结算不等于整次 Checkout Completed；长期等报告不阻断原就诊依照既有规则关闭。财务撤销、项目取消及实物处置分别记录，不能以退款推定检测取消。后端服务仍须检查当前有效申请、结算版本和动作资格，不能只依靠按钮隐藏。仅检验已结算不能阻止尚未结算药品的普通审方；药品需要退回改方时按药品子对象处理，保留已结算检验记录，具体结算历史保护见 Pharmacy §5.4。

5. Worklist 与执行单详情

5.1 工作队列

Lab 请求列表／详情及获授权工作队列／执行详情接入全部有效患者标签，包含来源诊所的 VIP／有未付；默认三个，其余通过「+N」浮窗查看。只读范围、排序及财务明细边界统一见 Frontoffice §2.7（2026-11-03 用户确认），不改变当前岗位的请求／执行权限及结算门禁。

目的与使用者： 采集及 V-Lab 人员快速找到当前可执行的任务、缺失的结果和异常。查询仅覆盖有权处理的来源诊所／执行单位，默认跨日保留未完成任务。

Awaiting report 是已开始执行且仍有项目未得到已发布正式报告的聚合视图；可与已交运事实同时成立。Collected 面向仍待交接的样本。同一订单跨视图出现时复用一条执行单，不重复创建任务。界面主状态按 §12 汇总，不依次要求点击两个没有真实事件的状态。

展示粒度与计数口径： Worklist 一张执行单一行，多项目和样本在详情展开，按稳定 Order ID 去重；报告列表一份报告记录一行，版本与撤回关系可追溯。同单可以命中多个待办阶段，各阶段数字不可相加作为待处理总数。阶段计数使用授权、来源、日期、搜索、优先级和当前关注开关；关注按钮数字统计当前阶段中需关注的独立订单数，开关前后保持同一基数。Urgent 订单同样命中 Attention；与异常或结算关注重叠时只计一次。已结束的加急单可在全部／对应结束阶段被关注筛选命中，但不会仅因加急重新进入待处理。

正式排序要求（2026-10-20 用户更新）： 所有工作队列视图先将 Urgent 加急单置顶；同优先级内，待处理／待采集／已采集／待报告按当前仍未解决的待办进入时间从早到晚，等待更久者在前，时间相同按 Order ID 升序，缺失时间置于同优先级末尾。排序在服务端对全部命中结果执行后再分页，不能只重排当前页。异常通过关注开关叠加筛选及行内提示显现，本身不额外改变顺序。阶段时间继续使用真实事件：待采集从结算放行并生成可执行待办开始，待报告从实际进入该阶段开始；不能统一拿订单创建、患者签到或最近更新时间替代。

同单有多个未完成项目时，采用当前筛选阶段下最早仍未解决的有效待办进入时间；其他项目完成不重置它。确实退回／补采并重新进入阶段时建立新事件，保留前次等待与原因，不用旧事件伪装本轮等待。关注筛选保留原阶段和加急优先规则。全部／已完成／已取消／异常结束视图在加急分组内按订单创建时间及 Order ID 降序；Reports 列表继续按报告登记时间降序。默认跨日未完成的范围继续有效，全部及结束结果须显式选择。结算撤销的原执行单保留阻断，不能当作无待办消失。其余行为遵循共同列表契约。

等待列显示相对时长及真实开始时间，完整时间也可在侧栏查看；历史缺失时标未知，部分待办时间缺失时明确已知等待下限，不自动判定超时。主状态只显示一次，同单其他待办阶段另列简要项目数。异常原因紧跟阶段，使用警示图标及细琥珀色行边标记；结算失效提示去 Cashier 覆核，不掩盖阻断。

5.2 执行单详情

2026-10-20 用户确认加急置顶，取代 2026-09-22 的仅标识／筛选规则，正式排序口径见 §5.1。侧栏查看完整姓名、病历号、出生日期、单号、来源、检验项目、样本、异常及待办时间；有权限时保留既有 Patient & eMR 入口。侧栏异步读取重新核验授权，切换或关闭后丢弃迟到响应，错误可就地重试；窄窗口贴右展开且保留队列挂载及滚动位置。

顶部保留 Back to worklist。紧凑白底身份栏显示 Patient、MRN、DOB、Order no.、原 Visit、Clinic、Ordering doctor；结算只读状态靠右。患者姓名通过既有 Patient & eMR 链接打开，不触发订单操作，访问仍受原权限限制。

正文分为 Tests、Specimens、Reports、Activity：

• Tests：项目名称、项目代码、实验室、执行结果；不允许实验室人员直接改医生已签署项目。
• Specimens：每份样本的内部编号、类型／容器、覆盖项目、采集和交接事实；当前操作在对应样本附近。
• Reports：已登记和已发布报告，显示报告日期、覆盖项目及版本状态；发布动作进入 Reports 的同一记录。
• Activity：默认折叠，记录操作人、时间、原因和变更来源；出现当前异常时相关原因直接在正文展示。报告草稿保存、登记、更正登记、发布及撤回，以及项目取消／无法完成，读取既有成功审计展示操作、覆盖项目、文件与原因摘要；登记文件优先使用该次审计中的文件引用，避免后续替换草稿后改写历史显示。采集岗位不因此取得内部报告读取权限。

长任务在所属工作区底部固定一个主动作，内容区单独滚动。查看历史／已完成记录为只读；不把低频设置、成本、接口日志或大块无行动价值的统计卡放在详情首页。

6. 样本采集与交接

6.1 采样交互

身份核对（2026-09-22 用户确认）： 采样时必须填写身份核对结果，不增加单独的“采集中心接单”状态或按钮。具体核对方法沿用诊所／V-Lab 现场现行规范，本期记录按现行规范核对通过及方式、核对人和时间，不固定要求系统选择的两个身份标识。未核对或核对失败不能确认采样；记录与本次采样关联留痕，旧样本不得补造“已核对通过”的记录。

点击 Collect sample 打开采样工作区：首先显示当前患者及执行项目，再配置／选择本次实际样本和覆盖项目，最后 Confirm collection。采样可以只涵盖本次已采的样本；剩余项目保留待采集，这是本轮应对多样本的设计默认。

订单与实物样本分别存储，同一项目可关联多份样本，一份样本可覆盖同一执行单的多个项目。补采建立新样本并关联原样本及原因，不覆盖原采集失败／拒收记录。跨实验室共用样本与自动判断样本相容性不作为本轮自动能力。

6.2 暂存与交接

样本区按用户参考图采用“当前标本三列＋折叠历史”：标题显示当前及历史数量，右上仅保留登记采集；当前区固定为标本／检验项目、当前进度、下一步三列。第一列显示内部标本号、覆盖项目及可点击的采集核对摘要；第二列显示状态标签、采集／交运／收样的紧凑行内进度和最近实物事件时间；第三列突出当前有权执行的推进主动作，其他可用操作收入更多菜单；无额外操作时隐藏省略号，样本记录详情保留相应入口。现场采集直接收样作为主动作下方的次要文字入口，不要求补造交运。登记动作继续复用原分批表单并预选当前标本，用户仍可选择本次实际处理的多份标本。只有已被补采替代的旧标本进入可折叠历史，显示编号、项目、采集时间及查看记录；未替代的异常标本和已收样标本留在当前区。当前及历史共用只读记录弹窗，展示完整事件时间、类型／容器、核对方法／人员／时间、补采来源与备注，并保留有权执行的打印及异常入口；切换订单时关闭旧详情。异常、已被替代或无待处理项目的标本不提供交运／收样快捷动作，未登记事件不得推定完成，当前进度与查看者是否有登记权限分开表达。界面沿用现有应用语言、共享组件及个人主题色；窄窗口复用公共表格横向滚动。原动作权限、时间校验、并发和幂等规则保持不变。 标签另含患者电话（缺失标为未记录），入口统一为 Print label；沿用原打印资格、内部样本号和打印审计，通用规则见 Frontoffice 患者标签。

已采样后显示 Collected · Awaiting pickup；实际取件时执行 Record dispatch，选择本次交接的样本，录入时间、交接／取件参考与必要备注，保存交接记录。页面区分部分交接和全部交接，不把订单下所有样本一并推为已交运。

当前标本列表仅在存在实际额外操作时显示省略号，不能整体移除菜单。菜单按钮可见性与内容共用当前标本的实际操作数组，数组为空时不渲染按钮；操作资格须同时结合订单权限与当前标本状态，不能把订单级打印／异常权限直接套到全部标本。异常待补采或已被替代的标本仅保留查看记录，不再提供打印及重复异常登记；有效标本的打印沿用服务端资格，异常还须已有真实采集事实且有关联待处理项目。有效已收样本仍可在原资格内重打标签，不以没有推进动作推定没有其他操作。没有推进主动作时直接显示 View record，菜单不重复列出查看记录；有推进主动作时查看记录收入菜单。详情中的打印及异常按钮与菜单共用同一资格，忙碌或未知提交期间禁用业务动作，继续保留原权限、版本及幂等规则。下拉触发器使用具有真实按钮根节点的框架按钮，避免带提示浮层的非元素根组件阻断触发指令。

实验室实物收样（2026-09-22 用户确认）： 本期提供人工 Record lab receipt，由所属实验室获授权人员选择实际收到的样本，记录操作人、实际收样时间及必要备注。只推进所选样本，保留部分收样、拒收或异常事实；后续 LIS 接入可复用这一事实模型并标明来源。收样与电子订单已送达、样本已采集／已交运、已开始检测分别保存，不能互相推定。

设计建议：来源诊所查看收样结果，由实际接收 Lab 人员登记；同一 Lab 现场采集可直接登记实物收样，不补造跨单位交运。收样时间不得早于已有有效采集／交运时间，不接受未来时间，补录保留原因。重复提交不产生第二次收样，补采使用新的样本。收样不重置其他项目等待时间，报告发布条件仍依 §7，不能把实物收样当作检测授权。

样本保存要求由实际项目／实验室规范决定，会议中的冷藏不是所有样本的通用默认。AI-CLIP 记录操作事实，不在本篇定义检验方法、保存温度、采样医疗规则或运输合规规则。本轮不提供“正在检测／检测完成”的人工模拟按钮，不由我方收样记录推断 LIS 状态。

6.3 无法完成与补采

LB-02： Rejected／Cancelled／Unable to Perform 保留原因并在相关医生／诊所的任务视图显示，不能静默消失。当前动作失败保留输入及可恢复路径；已经存在的真实采样和交接记录不能通过删除申请清除。

执行单的 end-items（结束所选未完成项目）须选择结束结果及一个原因类别：Patient declined、No longer needed、Specimen unavailable、Service unavailable 或 Other。前四类的 Note 可选；Other 必须填写实际说明。说明最多 2,000 字符，类别和说明分别保存、回读及显示，不能把类别名称伪造成操作人填写的说明。现有项目、权限、结算历史、版本及幂等门禁不变；仅处理所选可结束项目，不关闭其他待办或自动退款。历史纯文本原因保持原文，类别留空；兼容旧请求时仍要求原有文本原因，不补猜类别。

原 Consultation 的 Service 检验结果区及历史就诊的检验报告页同时显示这些结束操作，包括覆盖项目、执行单、实验室、操作人、时间、原因类别和说明。即使从未上传／发布报告，取消记录也可见；同一桌面执行操作后通知原就诊重新走临床授权接口读取，再次进入 Service 也刷新。该记录不恢复已签署项目、不改临床草稿、不推定退款。

上述可选 Note 仅适用于 end-items 的明确类别。样本异常、补采、解除 Needs attention、报告撤回以及库存操作原来要求的原因继续必填，不因结束项目的交互简化而放宽。

设计默认：未执行且未发生结算的申请使用现行临床修订；已结算或已有实物事件的取消／换项目进入受控异常记录，普通队列不提供一键退款／抹除历史。补采不自动新增患者收费，收费变更通过 Cashier 显式处理。此设计限定我方操作，不推断外部检测能否停止。

7. Reports：报告登记、预览与人工发布

报告列表作为所属 Consultation 检验／服务面板的内嵌内容，随面板切换隐藏，不挂载到全局页面底部，不覆盖 Patient & eMR 或其他应用。当前就诊没有报告及已引用报告时，不显示报告表头或空报告表；也没有可引用历史报告时，整个报告区隐藏，有可引用历史报告的可编辑就诊保留引用入口。2026-10-21 用户明确将检验执行记录统一归入 Services，项目取消／无法完成不再作为报告区显示条件，其查看入口见 §8；读取失败明确提示错误，不当作无报告。切换就诊立即清空旧报告和预览，防止旧数据残留。

7.1 报告登记与列表

目的与使用者： V-Lab 人员把已存在的正式报告准确归属到原患者和执行单，再发布给医生。已确认保留人工发布，不设计专业核验内容和检查清单。

本轮入口设计： 提供 Register report 人工登记正式文件，以便独立完成我方功能设计和合成场景验证。它不是用户已确认替换自动回传的决定，也不阻止未来使用相同内部报告服务接收文件；LIS 如何接入暂不设计。

未关联或冲突的文件进入 Needs attention，不让工作人员从混杂患者列表一键发布。报告可以覆盖多个项目；每份报告明确列出本次完成的项目，避免一份 PDF 使整单所有项目自动完成。结构化数值／趋势与 OCR 识别不作为这版报告入口的必备功能。

7.2 报告处理页

底部操作栏（2026-10-22）： 报告正文及 PDF 位于独立滚动区，返回、撤回、更正、草稿、登记及发布操作栏常驻面板底部；窄窗口保留按钮换行与安全区内边距。原权限、并发及未保存保护不变。已修改布局代码，未进行浏览器验收。

桌面左侧为紧凑的患者／订单、覆盖项目和报告资料，右侧为主要 PDF 预览区；复用公共阅读器的加载、失败反馈、分页、缩放、全屏和打印，窄窗口改上下，保持文件可读。顶栏返回原报告列表，底部保留 Save draft／Back 与主动作 Publish report；缺少必要资料时就地提示，发布按钮不可执行。发布及撤回确认保留患者与文件摘要、明确关闭入口；文件名只显示末尾名称，不展示服务器目录。

2026-10-20 上传反馈修复： 上传文件及登记／保存等命令执行期间，报告处理区显示带文字的加载遮罩，与既有按钮禁用和防重复提交保持一致。选中文件后，PDF 区显示加载提示，持续至首屏实际渲染完成，不能在文件解析完成但尚未显示时提前结束；加载期间禁用阅读器分页及缩放等工具，其他报告资料仍可填写，返回继续遵守未保存确认。下载、解析或页面渲染失败会结束加载并显示既有失败反馈。代码已修复，完成静态检查，未进行浏览器业务验收。

2026-10-20 预览修复： 新选文件、已保存报告及再次打开报告都使用同一公共 PDF 阅读器。预览区约束画布高度，分页、左右旋转、复原、缩放、全屏及打印工具固定保留在阅读器内；换文件重置第一页和旧页数，分页范围以本次 PDF 加载事件提供的真实页数为准，支持上一页／下一页及直接跳页，拒绝零页和越界页。代码完成静态解析及组件事件契约核对，未进行浏览器业务验收。

发布前使用简短确认对话框，显示“哪位患者、哪张执行单、哪些项目、哪份文件将对医生可见”。这是结果提交确认，不是人工检查清单。成功后显示 Published、发布人和时间，出现 Open in original visit；失败则保留待发布记录，允许重试。

发布在同一逻辑事务内产生报告发布事实、原就诊结果事件和已完成项目事件。重复点击、刷新或重试不会发布多份相同版本，也不重复计算完成量。工作人员不能在发布按钮上标记“医生已读”。

7.3 更正与撤回

本轮设计默认：已发布文件不可原位覆盖；Add corrected report 创建新版本，显示替代关系，经过同样的人工发布。本期更正版继承原报告的同一覆盖项目集合，不能以仅覆盖 A 的文件整体替代原来覆盖 A／B 的报告；覆盖集合变更进入显式异常更正。旧版本保留历史标识；医生默认看到当前有效版本，并能查到已被替代的记录。更正不重复增加原项目完成量。

确需撤回时必须有原因、操作资格和审计记录；已发布版本显示 Withdrawn，不静默删除医生此前可见的事实。撤回的月报影响通过 §10 的调整记录呈现，不用新版本日期偷偷改变原月归属。部分报告、补采和更正的细节属于设计方案，可独立评审，不重新变成阻断本轮设计的问题列表。

8. 医生结果查看与复诊引用

LB-03： 报告归原 Patient、原检查申请及原 Visit／Chit。Closed 后通过专门的 Result Event 追加关联，不重开就诊、不覆盖已签署 Note／处方、不调用只能编辑临床草稿的普通附件写入路径。

原 Consultation 的 Results 区按执行单／报告显示项目、实验室、报告日期、发布时间和当前版本，点击预览正式文件。仅登记但未发布的内部草稿不作为正式结果展示。医生查看／确认是独立事实，不作为实验室报告发布或执行单 Completed 的必经步骤。

历史就诊详情提供独立 Laboratory reports（检验报告）页签，按原 Visit 实时读取已发布报告，包含就诊结束后的发布结果；复用公共 PDF 查看器，保留更正链、撤回提示及已被取代版本入口。空态、加载及失败可重试分别展示，刷新仍保留原就诊和页签；不重新开始问诊，不提供只读记录的新增引用动作。

检验执行记录归属（2026-10-21 用户确认）： 本次 Service 对应 Lab 的所有已记录状态变化统一显示在当前 Services 及历史记录的 Services & Procedures，而非 Laboratory reports。按原检验单／实验室展示项目当前状态及完整历程，涵盖建单、项目等待阶段、身份核验通过／失败、采集与补采、交运／收样、异常、标签打印、转介、关注解除、项目取消／无法完成和报告草稿／登记／发布／更正／撤回。仅投影既有事实与成功审计，保留覆盖项目、标本及补采关系、真实发生时间、操作人、原因与参考编号；没有正式报告也可查阅。失败核验没有标本，其项目关联仅从同事务原单审计取得，缺失时显示未记录，不默认覆盖全单。报告阶段摘要不开放未发布原件、文件名或完整审计请求；正式文件继续使用原报告门禁。只读取已通过原就诊临床权限核验的患者／Visit／集团，不引入引用报告来源就诊的执行记录；切入 Services、手动刷新及同桌面对象通知时重新读取，切换上下文或离开模块废弃旧响应。只读展示不重开就诊、不改写 Selection、不恢复取消执行、不自动退款。本轮已完成代码、静态解析及只读 SQL 规划核对，未执行测试、构建或浏览器业务验收，无 Schema 变更。

Lab 正式 PDF 上传持久化后触发 OCR，失败不阻断文件登记或人工发布；去重上传复用同一文件版本的结果或有效任务。问诊及历史就诊阅读器按原文件版本读取识别状态、Header fields、Tables 和置信度，识别中自动刷新；已有未识别或失败报告可由具备文件上传权限且可读取原报告的人员重试，无需重新上传。OCR 仅追加派生数据，支持已关闭原就诊，不将报告改成普通附件，不改写原文件名、发布状态、报告更正链或已签署病历；报告草稿和正式版本继续执行原有读取门禁。本轮为代码及本地 Schema 增量实施，实际 OCR 服务联调与业务验收尚未执行。

后续真实就诊通过 Reference previous report 选择已有访问权限的原报告，保留原日期、实验室及来源就诊链接。引用不复制或搬走文件，不增加一次虚拟就诊，也不扩大访问权限；原报告有更正／撤回时，历史引用仍能指出被引用版本及当前有效状态。

报告不自动发送患者。临床沟通、医生结果确认及危急结果处理沿用临床责任路径，本轮不定义新的通知时限或自动升级算法，也不将报告正常推断为无需跟进。

9. 外部实验室转介

LB-04（已确认）： 外部实验室本期只做目录选择、开单转介、费用及人工报告收件；不提供外部执行账号，不建设外部执行工作台或自动结果／状态接口。

设计采用同一执行单来源，按 Laboratory 区分内部和外部。外部详情显示项目、机构、原申请及转介凭据，日常动作是 Record referral、Register report 和查看结果；不强制走内部 V-Lab 采样步骤，不显示仪器或检测按钮。

既有外部轨迹 Sent、Awaiting、Result Received、Doctor Acknowledged 保留语义；报告是否收到、是否正式可见、医生是否确认分别记录。本轮方案中，内部报告由 V-Lab 获授权人员登记／发布，外部报告由来源诊所具有相应报告动作资格的人员登记／发布，允许同一人完成两步，不强制经内部 V-Lab。共享报告对象不共享角色授权，普通附件上传权限不自动授予正式发布。收件和发布使用同一报告对象与归档规则，相关诊所只看自身可访问记录。外部执行单不自动混入内部 V-Lab 完成量月报。

10. Monthly Report：检验完成量

已确认： 按正式报告人工发布的月份，按原开单医生／诊所统计已完成检验项目数量；订单数与项目数区分，只做完成量月报，不生成实验室对诊所应付结算单，不以收款日期替代完成日期。

本轮统计设计： 以原申请项目行的首次有效人工发布记录建立完成事件；分批报告仅完成被覆盖项目。同一项目复测、重传或更正不重复计数。跨月更正保留首次完成月份。撤回后仅在该项目已没有其他有效已发布完成报告时，才以显式调整从原月份的当前有效完成量中扣除；恢复有效报告时撤销该扣除，仍归原月份，不生成第二次首发。订单取消本身不自动减少仍有有效已发布报告的项目；统计调整由上述报告事件派生，不新增手工修改统计数量入口。报表按查询时有效事实展示完成量及可下钻的调整提示，导出注明生成时间；调整有操作时间和原因，不抹去原发布事实。此为本轮设计规则，不引入财务关账。

默认统计本单位 V-Lab 实际承接项目，外部转介不混入；医生／诊所按原开单快照，人员后来调动不改变历史归属。不新增周报、财务 Period Close 或采购结算。

11. Inventory：简单人工试剂与 QC 库存

已确认： 人工登记入库、开封、领用／消耗及报废；不按检验订单自动扣料，不同步 LIS 库存，不做采购／PO。试剂及 QC 物料不是药房药品，不套用处方审核与患者结账门禁。

11.1 列表与物料资料

Inventory 显示 Item、Stock unit、Unopened quantity、Opened remaining、Nearest expiry 和需处理状态，按名称／代码、Reagent／QC、有效状态及库存异常筛选。点击进入物料详情。本期不另建库存预警配置；不从临床订单推算用量。

资料维护字段：物料代码、名称、Reagent／QC 类型、库存基础单位、包装单位及换算量、是否跟踪开封、开封单位（例如瓶）、开封后有效期（按物料资料配置）。包装和基础单位同时标明，禁止把盒、瓶、mL 或测试份数直接相加。单位与包装换算有存量后受控更正，不追改历史流水。

11.2 物料详情与操作

物料详情以可用库存为主要判断依据，摘要依次显示可用库存、账面库存、已过期库存，切换下方页签时保留摘要及页面主要操作。标题用“物料已启用／已停用”表达档案状态，与批次／容器是否过期分别呈现。全部或部分库存过期时显示文字提醒，入口定位并展开相关批次，同时筛选失效容器，可返回全部库存；过期提醒本身不产生数量流水。

详情分为“当前库存、库存流水、物料信息、物料变更”四个页签。当前库存展示批次原始有效期、未开封余量及入库时的单位／容器／开封期限快照；有开封容器时分别显示所属批次、实际开封时间、服务器已记录的开封有效截止日期、初始量与剩余量，不在前端另算截止时间。没有开封记录时压缩为“已开封容器 0 · 暂无开封记录”，不展示空表头。物料信息集中展示当前类型、启用状态、库存单位、包装及容器换算和开封期限，历史快照不跟随当前资料修改。

页面主要操作为“登记入库”和“记录使用”；批次展开详情提供开封或不跟踪开封物料的使用入口，以及登记损耗，容器行提供该容器的使用和损耗入口，自动带入所属批次及容器。库存调整和编辑物料归入更多操作，资料页也提供编辑入口。常规使用／开封依据现有权限、启用状态、对象有效性及余量禁用并说明原因；有未开封可用量但无可用容器时提示先开封。历史补录、并发、幂等及最终时间／数量校验沿用既有业务规则，不新增例外权限。入库数量旁显示基础单位换算量及物料总账面预计前后值，并将所选批次／容器余额单独呈现；开封仅转移库存，总账面数量不变。

库存流水主表保留实际发生时间、动作、关联批次、账面净变化和记录人，展开查看录入数量、录入时间、所选批次或容器的前后余额、容器编号、实盘数量、完整原因与来源引用；开封流水明确说明账面净变化为零，余额属于新容器。物料变更按登记录入时间展示创建／修改、记录人及原因，展开逐字段查看变更前后资料。两类时间与两类余额均明确区分，原说明和证据完整保留，最新 200 条流水及 100 条资料变更的接口上限明确标示。

所有数量动作在提交前显示本次变动和变动后余额，提交期间禁止重复；并发扣量以服务器最新库存校验。库存为零仍保留历史。物料停用不删除已有批次和记录。

效期设计： 原效期、开封日期、开封后期限分别记录；有两项限制时有效截止取较早者，缺少依据不自动套用会议举例的 10／30 天。过期／失效存量单独提示，不能作为正常可用余量；实际报废由工作人员登记，不因跨过午夜自动扣账。本篇不定义 QC 专业判定或临床使用规范。

12. 状态、异常与共同控制

12.1 分开保存，按待办汇总

当前阻断优先显示 Needs attention，作为标识保留原阶段；正常详情同时显示实际样本及报告事实。只要仍有 Pending 项目，就不结束整单；全部项目 Completed 才显示 Completed，全部 Cancelled 显示 Cancelled，其余全部已有结束结果的组合显示 Closed with exceptions。筛选中的 Completed 只查成功完成，All 可查全部结束结果。取消和 Unable to perform 按 §6.3 保留原因类别及适用说明，历史文本仍可追溯，不计入成功完成项目。已结束订单仍可因报告更正／撤回产生需处理事项，不能禁止后续合法更正。完成条件与月报去重是本轮设计默认。

12.2 恢复路径

12.3 权限与审计

复用 Platform 查看／编辑与临床授权；读、采集、交接、报告登记、发布、库存写入及导出分别检查当前动作资格和数据范围。页面入口可见不等于可以写入；跨诊所链接、直接 API、导出和文件下载均按原对象权限校验。开单权限不重新讨论，角色粒度不由本篇自动扩权。

记录对象、操作人、服务器时间、原状态／新事实及必要原因；财务分配、报告发布和库存变化具备幂等与并发校验。技术审计数据放 Activity／后台，界面只突出当前人员做判断需要的信息，不散布数据库 ID、接口日志或实现版本号。

13. 界面交付规范

沿用桌面设计规范：AppWindow 外壳、WorkspaceSectionHeader、PatientEmrLink、Element Plus 表格／表单／按钮、AppDialog 及共享 Iconify 图标。页面文案默认英文，PRD 与互动说明可用中文。正文 14px、辅助 12px、控件 36px、主动作 40px，圆角引用现有 6／8／12px 语义值，不新增一套视觉组件。

工作队列采用列表＋右侧只读详情，复杂处理进入现有全宽工作区；报告页采用摘要＋预览范式；物料维护采用列表＋详情／抽屉范式。表格遵循当前桌面 UI 规范，采用中性浅色表头、白色数据区，层级用字重、分隔和留白表达；状态标签使用文字及项目语义颜色。保留蓝绿色 Lab 识别，交互色继续跟随个人主题；患者身份采用紧凑白底结构，表格不能逐行卡片化。

表单关闭与恢复： 样本／订单动作和 Inventory 表单在默认值及编辑对象完整载入后建立初始快照，仅比较本次可编辑的业务字段。仅打开表单、载入既有值、请求键或版本变化不算修改；改变后恢复原值应回到无修改状态。项目／样本选择、数量、时间、原因、物料配置，以及尚未确认的扫码输入均按其实际业务含义参与比较。提交中状态独立于未保存修改，禁止重复提交或直接丢弃正在处理的请求。

明确保存失败保留输入并提供修正／重试。请求已发出但因断网、超时或服务错误无法确认结果时，明确显示结果未知，冻结该次请求及编辑输入；Retry same request 使用同一对象、原提交内容和幂等键，不以新请求重复执行。结果未知时禁止关闭、Cancel 和 Discard，保留原命令直至同一请求取得明确结果；已经打开的放弃确认也不得在提交中或结果未知时清除请求。关闭本地输入不能撤回服务端可能已完成的操作。报告编辑器继续按其既有资料／文件未保存保护处理，不以动作表单关闭替代报告保存或发布。

互动方案图是用于讨论的页面区域／动作说明，使用静态文档导航，不作为生产组件代码、可用后台或已验收截图。实现时仍必须使用上述共享 Vue 组件；不会把说明图中的静态标记当成业务处理接口。

14. 验收定义与实施顺序

14.1 场景与预期（尚未执行）

以上是验收定义，不是通过记录。应用开发后按项目规则部署本地完整服务链，使用 Docker 内官方完整 Chrome、隔离合成数据、截图／视频／trace和控制台／接口检查；文档构建或互动方案验证不能替代这些步骤。

14.2 实施拆分与现有基础

具体对象与服务边界见工程方案。bb47e930 是 2026-09-15 历史核查基线，2026-09-22 基于 9d3936ba 的源码盘点及 2026-09-23 实施记录见本轮实施方案；已有路径不等于目标环境已验收。LIS 真实接入单独作为未来集成工作包，本轮只预留内部契约及来源关联，不提供模拟接入成功状态或承诺联调日期。工作队列／采样／标签、报告上传及人工发布／PDF 预览、Cashier 费用组衔接的历史专项 Chrome 通过记录，以及发布前后文件权限、重复有效报告阻断、检验已付后药品退回改方保护的历史 API 记录，见实现与验证。这些记录不覆盖后续新增规则。真实字段未保存判断、未知结果保护及结束项目的类别／说明已接入当前源码；本次文档同步不声明本地完整服务链、浏览器、应用部署或 UAT 已通过。外部诊所报告专用岗位及动作范围属于 legacy 源码基础，实际人员授权、数据库初始化、13 角色 cutover 及运行验证仍需各环境证据；不能据旧角色种子或历史记录宣称当前路径已可用或已迁移。