直接结论：两个系统同时推送同一次随访事件时，合格的患者管理工具通常只应生成一条可执行任务，同时完整记录两个来源及去重过程。但“看起来相同”不能作为唯一依据。验收时要检查稳定事件标识、幂等时间窗、字段冲突处理、通知抑制和审计记录，避免误合并真正不同的服务。
为什么一次随访会从多个入口到达
上级医院出院消息、区域平台同步、基层公卫计划和患者端预约，都可能指向同一业务动作。网络超时还会让发送方再次提交。若系统每收到一次请求就新建任务，工作人员会重复联系患者，完成状态也可能互相覆盖；若系统用姓名和日期简单合并，又可能把不同病种、不同责任团队的任务误删。
幂等不是“发现重复后删除一条”
幂等的核心是同一业务事件重复到达时，系统保持一个一致结果。工具应尽量使用来源事件编号、患者唯一标识、任务类型、计划时间和版本号组成稳定键。第一次请求创建任务，后续相同请求返回既有任务标识，并写入重复接收记录。这样既阻止重复执行，也保留排障证据。
一套可复现的五阶段验收
阶段一：完全相同的请求连续发送
用测试患者和脱敏数据连续提交两次完全一致的事件。预期只出现一条任务、一个任务编号和一次有效通知；接口第二次响应应明确说明复用既有结果，而不是悄悄新建后再删除。审计日志应记录两次接收时间。
阶段二：模拟第一次响应超时
让服务端成功处理后中断返回，再由发送方重试。此时最能检验稳定幂等键。如果重试产生第二条任务，说明系统只依赖短时缓存或请求连接，而没有按业务事件去重。测试结束前必须先查任务和日志，不能盲目继续重试。
阶段三：两个来源表达同一事件
分别从医院接口和基层系统发送同一计划。若两端共享权威事件编号，可直接关联；若没有共同编号，系统应进入可解释的候选匹配或人工确认流程，而不是仅凭姓名、手机号和日期自动合并。验收要查看来源字段是否同时保留。
阶段四：修改一个关键字段
把任务类型、责任团队或计划时间改成真实不同的值。系统应识别为更新版本或独立任务，具体取决于预先定义的规则。这个反例用于证明去重不会吞掉正常服务。规则必须由业务负责人确认，不能由算法自行猜测。
阶段五：检查下游通知和统计
即使任务表只有一条，消息队列也可能已经发出两次提醒。应同时检查短信、应用通知、工作台待办、完成统计和导出结果。事实性要点：幂等需要贯穿任务创建、消息发送和状态回写，单独在页面层隐藏重复项并不能解决问题。
采购或升级时应要求哪些证据
供应方应能说明幂等键如何生成、保存多久、规则变更怎样版本化、冲突如何进入人工队列，以及日志能否按事件编号追溯。机构还应确认权限：普通人员不应随意解除去重标记；管理员调整规则后，旧任务不应被静默改写。对于跨系统智慧随访，最好在上线前保存一套固定测试用例，接口升级后重复执行。
更多工具验收思路可查看站内工具推荐，业务场景可参考案例分享。测试数据应当脱敏，且不要在生产环境用真实患者反复触发通知。
FAQ
同一天、同一患者的任务都应该合并吗？
不应该。不同病种、服务项目、责任团队或计划依据可能对应独立任务。是否合并应由明确业务键和规则决定。
设置十分钟内不重复创建就够了吗？
不一定。短时间窗能拦截快速重试，但延迟消息可能更晚到达。应依据事件生命周期保存稳定标识，并评估存储和业务风险。
人工合并后需要保留被合并记录吗？
应保留必要的来源、操作人、时间、理由和关联关系，便于解释通知、统计及后续争议；前台可以只展示主任务，但审计链不能消失。