先说结论
患者援助项目（PAP）的系统设计里，最难的部分不是功能实现，是防骗模型和审计证据链。
一个买赠型项目，患者买一个疗程、凭发票和处方申请赠药，累计服务量可能到几万人次。这个规模下，靠人工审核必然出漏洞，而且漏洞事后查不出来。系统要解决的是两件事：不该给的拦住，该给的漏不掉，每一次破例都能查。
骗领的三种形态
实际项目里遇到的，基本逃不出这三类：
假发票 —— 票面信息伪造，查验接口能拦住。这类最容易处理。
真票重复用 —— 同一张发票在不同患者、不同周期重复提交。这是最隐蔽的一类，因为单张票在查验接口那里是「真」的。
他人发票代领 —— 拿家属或他人的真实发票来申请。票是真的，人不对。
第二类是设计重点。它的本质是：发票在整个项目里必须是唯一的，不是每次提交时唯一。
三层防伪，逐层收口
第一层是人工审核。这一层不能省，因为材料合规性判断（处方有效期、抬头、诊断匹配）机器做不可靠。但人工审核不能作为唯一防线，审核员会疲劳、会看漏。
第二层是系统级唯一约束。这层是硬约束，不是提示：
发票代码 + 发票号码 组合唯一
金额作为辅助校验
一张票全项目只能核销一次，跨患者、跨周期、跨项目判重
关键在于「跨患者判重」必须在数据库层面做，而不是应用层查一次再插入。并发提交的情况下，应用层查重会出现两人同时通过的情况，数据库唯一索引不会。
第三层是对接第三方发票查验接口，验证票面真实性。这一层解决假发票问题。
三层的关系是：第三层保证票是真的，第二层保证票没被用过，第一层保证材料和人匹配。任何一层单独存在都有漏洞。
强制放行为什么必须留痕
现实里总有必须放行的情况：患者发票抬头开错了、处方日期差一天、系统判重但确实是不同疗程。
设计上要不要允许 override？必须允许，但必须留痕。
不留痕的后果是，审计时你只能看到「这张票被核销了」，看不到「是谁在什么情况下决定放行的」。药企合规审查和基金会审计恰恰最爱查这类点——破例的记录比正常的记录更值得看。
所以强制放行必须记录四个字段：谁、什么时候、为什么、依据什么材料。这四个字段不是可选字段，是必填。
通道分离：应对项目收缩
这是实际运营中容易忽略的设计。
援助项目有明确的生命周期。项目进入收缩期时，通常不是一刀切停掉，而是：先停新入组，已入组的患者继续领完。
如果系统只有一个总开关，执行层会很难做。正确的做法是入组通道与赠药通道分开：
- 收缩期第一段：关闭入组通道，赠药通道正常
- 收缩期第二段：入组通道关闭，赠药通道也开始逐批关闭
这个设计在方案阶段就要定，后补会很麻烦——因为赠药流程依赖入组状态，两个开关的依赖关系需要提前想清楚。
患者端不暴露黑名单
这一条是运营经验，不是技术问题。
判重拦截后，患者端不应该显示「你的发票被判定为重复使用」。这会把审核对抗化——患者会开始研究怎么绕过判重。
用中性话术：「材料需要补充」「该材料暂不符合项目要求，请联系客服」。审核细节留在后台，患者端只给下一步动作。
小结
如果只记一句话：PAP 系统的核心不是功能清单，是状态机和判重引擎的设计。这两处返工成本最高，方案阶段没拆清楚，后期改一处会牵动全流程。