这个系统真正难在哪
援助项目表面看是个「申请—审核—发药」的流程，实际做起来，风险和成本几乎全压在三个地方：
一、骗领
一盒肿瘤药动辄几千上万，骗领动机极强。常见手法至少有六种：
- 伪造发票
- 真发票重复使用（同一张票换个人再领）
- 伪造处方或门诊记录
- 用过期处方
- 拿别人的发票代领
- 入组后发现违规行为
系统必须在不增加审核员负担的前提下把这些都挡住。我们的做法是三层：人工审核 + 系统级唯一约束 + 第三方查验接口。其中「发票唯一性约束」是整个防骗体系的地基——一张发票一旦被任一患者核销过，就永久入库，全项目范围判重。
二、破例必须留痕
再严的规则也会遇到需要人工放行的情况。硬性拒绝会误伤真实患者，所以强制放行权限必须给到审核员，而不是只有主管。
但放行本身是审计重点。系统要做的是：默认规则被打破的地方，必须自动记录谁、什么时间、为什么、原发票信息是什么，且不可删除、永久可查。
三、通道分开关停
援助项目有明确的生命周期：启动期、运行期、收缩期、收尾期。
到了收缩期，需要先关入组通道、后关赠药通道——不再进新人，但已入组的患者要按疗程继续领完。这两个通道如果做成一个开关，项目收缩时就会出事：要么停了不该停的，要么该停的停不掉。
系统边界怎么划
我们通常按六个端口来设计，但实现上会合并：
| 端口 | 形态 | 说明 |
|---|---|---|
| 患者端 | 移动端 H5 | 拍照上传发票、处方、诊断证明是刚需 |
| 药房端 | 移动端 H5 | 现场发药需要拍照回传 |
| 运营端 | PC Web 后台 | 审核工作量大，大屏操作效率高 |
| 基金会端 | PC Web 后台 | 项目周期、援助规则、通道开关 |
| 药企端 | PC Web 后台 | 只读报表，不看明细 |
| 公共能力层 | 服务 | 发票查验、判重、留痕、消息、权限 |
运营端、基金会端、药企端在实现上是「一套后台 + 三套角色权限」，不拆成三个物理系统。这样开发和运维成本都可控，但对外描述时按三端分别讲，因为它们的业务复杂度确实不同。
报价怎么算
这类项目的费用由两部分组成，必须分开谈：
产研费（一次性） —— 按功能模块拆人天。核心工作量集中在后端：发票判重引擎、状态机、三方接口对接、审计留痕。这三块的共同特点是 AI 提效有限、返工风险高，报价时要单独立项，不能摊在平均值里。
服务费（按周期） —— 如果包含运营服务，按服务人次阶梯结算。注意一个容易算错的地方：入组 1000 人听起来不多，但每人 24 次赠药循环 + 24 次随访，两年下来是约 5 万人次的服务量。报价口径必须是人次，不能只盯入组人数。
我们的判断
如果你正在评估这类项目，有三个问题建议在签合同前钉死：
- 赠药截止策略（统一截止 / 全部领完 / 按剩余周期折算）—— 由药企定，但系统必须做成可配置，否则策略一调就是二开。
- 发药方式（院内 / 指定药房开端口）—— 决定要不要做独立的药房端。
- 数据合规口径 —— 「身份证脱敏」在法律上是「去标识化」而非「匿名化」，脱敏后仍是个人信息，仍受《个人信息保护法》约束。这条不要向甲方承诺成「全量合规方案」，最终拍板的是甲方的法务或 DPO。