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
与配置层级。
功能地图
围绕一次结账及其后续账务组织功能。待办、历史和日报是工作入口;费用、付款和票据是各自业务对象。
| 功能 | 使用者/业务对象 | 产品方案与阅读位置 |
|---|---|---|
| 工作入口与待办 | 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),后续到账、退款和调整都记录在原业务上,不重写临床记录。
前台不执行这些付款操作。医生的只读入口及后台财务职责仍按各自授权范围处理,完整分工见 权限方案。该规则于 2026-09-14 确认,角色模板、队列、接口及存量账号仍待对应实施核验。
1.1 团队与工作场景
2026-09-07 已确认:Billing & Insurance 是同一个团队/角色入口,账单、保险核验、付款责任和回款作为团队内部工作组织。后台岗位在后台处理获授权的原 Clinic/Visit/Invoice 业务;现场 Cashier 操作由当前 Clinic 与负责医生有有效服务关系、且具相应财务动作权限的护士执行;前台保留预约及基础资料维护,不能签到或执行 Cashier,不因共用能力而把后台团队混入 Clinic 角色列表。
Finance 保留为唯一后台财务角色,在后台处理获授权的 Clinic 与 WDL/CP 财务业务,具备价格查看/维护、病人附件查询/查看、每日日结报告查看的目标权限。角色归属、数据范围、历史快照及报告只读边界统一见 组织与权限产品方案。本节是新确认的产品规则;团队入口、有效权限合并与后台场景已按平台实施边界章节 实现;旧账号保留来源诊所范围,完整后台跨诊所授权与权限细分尚待实施。
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 本期不建设。
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,保留其他搜索/状态条件。已选医生最后一条待办离开队列时,界面仍明确保留当前选中条件,允许用户清除,不自动扩大查询范围。筛选不改变费用、发票、结算或临床记录。
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
的后端、前端、浏览器与清理检查全部通过。真实后端部署和业务 UAT
仍未完成。
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 入口与药房独立改价入口、管理人员事后处理队列分别计实现状态。
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 |
| 旧页面按改价前金额提交 | 拒绝并重新核对当前费用版本 |
金额为合成测试数据。
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
完成实物复核;单人/紧急例外在重新认证及审批流程完善前不可使用。
4.3 结账界面:阶段、金额与票据入口
信息承接与票据入口: 费用、Visit 本次计划、已核对付款责任、实际收款和欠款沿用同一上下文,阶段变化不重新填写同一信息;确认失效及草稿保留见 IN-05–07。结算前集中复核费用、责任与本次付款/欠款,不重复展示 Invoice 模板、预览或打印区。结算已确认后提供一个 Print invoice 入口,在共享弹窗中选择模板并打印;实收结清、零金额、保险及患者欠款安排确认均适用,不要求全部应收到账。Receipt 仍关联真实付款;模板/账务快照和每次打印记录的唯一规则见 票据与重试。历史操作及模板管理仍在 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 | 原记录、原因、调整/退款/冲正、批准信息 | 保留原记录并创建关联纠正 |
5. 保险与企业计划
功能目的: 将本次保障资料转为明确付款责任,并追踪后续回款。
使用者与对象: Billing & Insurance/Cashier;Visit 计划快照、付款分摊及 Remittance。
操作与结果: 承接人工核验 → 复核责任与 CoPay → 开票结算 → 实际到账后分配并冲抵对应应收。
关键边界: 有卡、人工资格确认、第三方责任和实际到账分别记录,不互相替代。
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的全宽对象工作区。开票前顺序为费用复核与付款责任,Post 后将患者付款/欠款录入放在主要可见区域,责任快照仍可查;底部固定一个当前主要操作,金额分层显示。本次全付、部分付、全部欠款使用同一组 Element Plus 选择及表单控件;确认对话框复用 AppDialog。保留三个主入口和右上角 Settings,不把 Outstanding 或付款方式新增为主 Tab。
5.1 预约计划及人工审核结果
Checkout 患者上下文只读展示 Visit 保存的 Payment Arrangement 与计划名称。Insurance、企业或员工计划不自动设置第三方责任或金额;Cashier继续分别确认患者自付、第三方责任和实际收款方式。已有账单的 Visit 不允许从 Appointment/Registration 改写付款来源,需使用收费调整流程。未新增自动赔付/应收或资金通道。完整前置规则见 Frontoffice §4.3。
人工核验结果如何承接
本期 Appointment/Registration 使用人工审核确认按钮记录计划、资料变化、有效期、资格和预先申请结果,并由服务器记录审核人、时间与本次计划/日期范围。待核实、不合资格、申请待批阻断准备交接;旧 Checked 文案不构成通过证据。Cashier 仍需复核本次保障及付款责任,不将“人工确认”自动转换为保险公司承诺或企业应收;完整输入和状态规则见 Frontoffice §4.4。
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 自动复制成这次结论。
5.3 回款分配
IN-03: 登记保险实际到账金额及参考资料,选择一项或多项 Claim/Invoice 分配;允许部分分配并保留未分配余额。分配总额不得超过可分配到账额或对应可冲抵余额。误分配先撤销该分配,再建立正确分配,原 Invoice 和到账事实保留。
回款记录不等于电子 Claim、自动 Adjudication 或自动核赔。本期实现仍不完整,需单独端到端验收。
IN-04 已确认: 第三方未到账保留为该付款方的 AR;其回款等待不阻塞已按 BL-05确认的备药交接。结算条件只维护在 BL-05,患者欠款及补缴规则见 IN-05–08。
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 整体通过。