AI-CLIP Phase 0 业务 PRD

Workflow 与系统架构：从当前代码理解跨模块交接、技术分层、AI／外部服务和部署边界。

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

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

各项需求保留原编号，方便开发和测试对照。业务测试用例说明如何验收，实现与待确认事项说明当前进度及缺口。

按板块阅读

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

产品功能架构

flowchart TD
  A[患者与护理：主档、自填、预约、到诊] --> B[临床工作：Note、处方、检查、文档、完成]
  B --> C[药房执行：审方、备药、复核、发药]
  E --> D[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 的内部设计、应用部署与原合同范围分别记录。

列表与工作队列的基础交互契约

本节是各模块必须补齐的共同规则。各模块决定具体排序事件，不能将所有工作队列一律解释成预约顺序；Reception 的已确认签到顺序见 Frontoffice §5.1。以下是本轮补充的产品设计与验收要求，实现状态另查交付说明。

适用范围包括患者及 H5 审核、预约、Registration、Consultation、Cashier、Pharmacy、Lab，以及文档、目录、审批和库存列表。审批优先级、任务 SLA、医疗紧急优先等不能用通用交互约定代替业务决定。新增或调整列表时，缺少上述任一适用项及对应反例验收，不应认定 PRD 已完整。

表单、详情和操作结果的共同细节

这些要求与列表检查项一起纳入模块设计及验收；具体医疗、财务、权限的业务例外仍以各 canonical 章节为准。

1. 产品目标与范围

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

1.1 本期需要完成的业务

本期不交付完整 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 角色负责什么

表内描述职责，不自动授予全部权限。已确认的组织与对象关系、查看／编辑矩阵和授权流程及例子集中在权限功能中；尚未确认的个别范围另行标注，不再笼统称整套权限矩阵待定。

2.2 哪一份记录是准的

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

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

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

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 --> Q[有检验：Cashier 独立确认检验费用组]
  Q --> M[Lab 按实验室承接、采样与正式报告发布]
  Q --> K

阅读重点： 医生签署后，检验可在 Cashier 独立结算并放行 Lab，药品仍等整张审方与有效预留后结算，随后备药。药房退回阻断的是药品费用组，护士按既有流程处理临床退回；不撤销已经成立的检验结算或实物记录。整次离院仍需满足全部适用条件，不能由单组结算提前完成。检验结算不等于采样或报告完成；图中分支仅在本次有相应医嘱时产生。详细独立结算见 Cashier，检验执行见 Lab PRD。

3.1 每次交接交出什么

4. 状态与允许操作

4.1 预约及到诊准备

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

4.2 问诊、结账和关闭

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

关闭规则 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走处方修订：无付款／结算历史、未 Closed 且未最终发药时，药房先退回整张处方并阻断 Cashier；护士在 Cashier 确认后才把 Encounter 回到 In Consultation。保留原病历与历史签署，不重建整次就诊。Closed 后一律不得重开、覆盖或直接修订原记录；关联更正必须保留原事实和关联关系。

5. 七类就诊如何分流

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

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

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

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

旧编号继续用于历史测试追溯：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. 跨模块共同控制

8. 测试与交付证据

先使用业务测试用例的 E2E-01 普通门诊闭环，再执行对应功能与异常用例。用例定义预期；实际结果与测试版本在测试证据索引记录为 Pass、Fail、Blocked 或 Not run。

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

实现缺口与待决定事项集中到交付状态。本地完整部署、开发分支发布、Vercel App、PRD 发布、STG 联调和 UAT 分别计证；修改文档本身不改变业务验收状态。