员工账号停用后，未完成随访任务不应自动消失，也不能继续静默挂在无人登录的账号下。合格的患者管理工具应同时完成四件事：立即阻断访问、撤销已有会话、把待办转入受控交接队列、保留原负责人和变更轨迹。只测试“旧密码不能登录”远远不够，真正风险往往藏在手机会话、批量任务和历史责任链里。
为什么账号停用不等于业务交接完成
账号属于访问控制，随访任务属于业务连续性。前者解决“谁还能进入系统”，后者解决“谁继续服务居民”。如果系统把两件事绑定得过死，停用账号可能导致任务查询不到；如果绑定得过松，原账号的会话或接口凭证又可能继续访问。验收时需要把权限和任务分开测试，再检查它们的联动。
第一道关：旧账号与所有会话是否真正失效
先在浏览器登录旧账号，再在另一设备执行停用。随后刷新页面、重新请求数据、尝试导出和打开直接链接。安全结果应是已有会话同步失效，而不是只有下次重新登录才受限。若系统提供移动端、第三方接口或长期令牌，也要分别验证撤销情况。
测试数据应使用专门的虚拟记录，不要拿真实患者信息做权限试验。结果要记录停用时间、失效时间和受影响入口，以便判断是否存在延迟窗口。
第二道关：未完成任务是否进入可见交接队列
检查今日待办、未来计划、逾期任务、批量生成任务和暂存草稿。它们不能因为负责人停用而从团队视图消失。更稳妥的设计是自动进入“待交接”队列，由主管按服务区域、病种能力和工作量重新分配。
重新分配时要保留原负责人，记录新负责人、操作人、变更时间和原因。不要直接覆盖负责人字段而不留历史，否则后续无法解释某次联系发生在离职前还是交接后。
第三道关：自动提醒与外部通道是否同步改写
不少系统的任务负责人已经变更，但短信审核人、电话外呼队列、消息签名或异常接收人仍指向旧账号。验收时应创建一条低风险测试任务，观察提醒由谁接收、失败告警发给谁、居民回复回到哪个队列。
如果外部服务不能实时同步，系统应明确显示待处理状态，并阻止继续以旧人员身份发送。不能用“后台稍后会同步”替代可核验的状态和责任人。
第四道关：历史记录能否完整追溯
停用账号后，历史随访记录、备注、附件和操作日志仍应可按权限查看，并明确显示当时的执行人员。人员姓名或账号标识不应变成空白，也不应因为重新分配而把过去记录全部显示为新负责人。
审计日志至少要回答：谁停用了账号、何时生效、哪些会话被撤销、哪些任务被转移、由谁接收、是否有失败项。日志本身应防止普通用户随意修改。
一套可重复的验收步骤
准备一个测试账号和四类测试任务；分别在网页和移动端保持登录；停用账号后验证会话；查询团队待办确认任务没有丢失；由主管完成分配；触发一条测试提醒检查外部通道；最后导出审计记录，对照任务前后负责人。测试通过后再把流程纳入真实离职清单。
机构还应约定紧急离职、正常离职和临时停职的不同处理时限。工具可以提供自动化，但最终责任人、复核人和例外处理仍需由机构制度明确。
可结合工具推荐栏目中的权限与任务测试方法完善验收表，也可在常见问题栏目了解患者管理系统的基础配置边界。
常见问题
账号停用后，任务直接分给主管可以吗？
可以作为临时兜底，但应进入明确队列并记录原因，避免主管账号长期堆积大量无人处理任务。
历史记录里的离职员工姓名要删除吗？
一般不应为了界面整洁破坏责任追溯。具体展示和留存应遵循机构制度、授权范围及适用法规。
只测试网页登录失败是否足够？
不够。还要检查已有会话、移动端、接口令牌、导出权限、外部通道和未完成任务的归属。