一、9.2.1 管的是账号生命周期，不是简单“开个账号”
医疗场景下的重点：医院人员结构复杂，除了正式员工，还包括进修、轮转、规培、实习、返聘、外包、厂商驻场、科研合作和短期项目成员。账号如果只围绕“正式员工入离职”设计，天然会漏掉大量高风险人群。
9.2.1 最容易被误解成一条非常基础的 IT 条款，仿佛只要信息科有一个开账号流程就算完成。实际上，这条要求的是“谁进入组织的数字身份体系、何时进入、谁批准进入、什么时候必须退出”这一整条链路都要受控。对医疗机构来说，这个链路尤其重要，因为患者信息系统的入口往往就是账号。入口控制一旦松散，后面再谈最小权限、访问限制、日志审查都会变成被动补救。
医院最典型的问题，是很多账号不是通过正式的身份管理流程产生的，而是通过临床急需、教学安排、厂商配合、项目联调等场景临时出现。最开始只是“先给开一个，回头补手续”，后来就沉淀成无人认领的长期账号。几年之后，组织只知道系统里有一批还在用的用户名，却不知道它们最初是谁申请的、对应哪类人员、为什么还保留着。9.2.1 要解决的，正是这种入口层面的失真。
二、医院账号注册为什么比普通企业难得多
| 人员类型 | 入场特点 | 退出特点 | 容易出问题的点 |
|---|---|---|---|
| 正式医护人员 | 入职手续相对规范 | 调岗、借调、停职比离职更常见 | 岗位变了但原账号未同步调整 |
| 规培、进修、实习人员 | 批量进入，时间集中 | 结束时间明确但常被延迟或续期 | 旧账号复用、新老批次混淆 |
| 返聘及临时专家 | 身份特殊、权限诉求高 | 合作结束不一定经过常规人事流程 | 账号长期保留、审批记录不全 |
| 厂商驻场和运维人员 | 常由项目或设备需求触发 | 撤场时间由合同和现场安排共同决定 | 人走了，账号和远程入口还在 |
| 科研与合作项目成员 | 可能不在医院正式编制中 | 项目结束、延期或换人频繁 | 身份关系难以通过单一系统识别 |
医院账号管理之所以复杂，是因为人员“进入医院系统”的方式并不只有人事入职一种。医务、护理、教学、科研、设备、项目管理、采购和外包合同都可能成为账号注册的触发源。如果组织没有把这些触发源统一接入账号生命周期管理，就会出现正式员工管得比较严、其他人员靠 Excel 表和微信群沟通的情况。认证检查时，问题最常出在后者。
更现实的一点是，医院很多人员并不是在“彻底离开组织”时才需要注销账号，而是在轮转结束、支援结束、值班关系变化、项目停用、厂商撤场时就应该收回一部分或全部访问权。也就是说，用户注销在医疗机构里经常表现为停用、冻结、转移、降级，而不是单纯删除账号。这一复杂性决定了流程不能太粗。
三、注册流程如果不做身份核验，后面所有权限都站不住
用户注册的第一步不是填权限申请，而是确认身份事实。这个人到底属于哪一类人员，由哪个部门或项目负责，对医院承担什么职责，有没有对应的工号、学号、项目编号或合同编号，有没有明确的结束日期，是否需要使用正式临床账号还是仅需只读或辅助账号。没有这些基础信息，后面的授权根本无从谈起。
医疗机构里最常见的偷懒方式，是让业务部门直接发来一张名单，信息科按名单批量建号。名单里可能只有姓名和科室，没有身份证明、任期、岗位性质和责任人。这样做上线很快，但事后几乎无法解释账号是否合法存在。发布级的做法应是：每个账号都能追溯到明确的身份来源和业务责任主体，而不是一张谁都说不清出处的表。
此外，账号标识也要有规则。不能今天用姓名拼音，明天用工号，后天再因为重名临时加后缀。统一的命名、主数据来源和唯一标识机制，是后续审计、日志分析和跨系统同步的基础。否则同一个人在不同系统里看起来像不同身份，注销时也更容易遗漏。
四、注销流程真正难的是“及时感知退出事件”
很多机构并非没有“离职停用账号”这条规定，而是组织根本不能及时知道哪些人该退出。实习生结束轮转时，教学部门未必会主动通知信息科；外包工程师撤场时，项目负责人可能只知道门禁卡收回了，却没意识到 VPN 和系统账号仍然有效；临时支援医生返回原单位后，原授权如果没有到期机制，就会继续保留。9.2.1 的落地重点，恰恰在于让退出事件能够稳定触发账号停用。
因此，注销流程不应完全依赖人工提醒。更稳妥的做法是把人事、教学、项目、合同和厂商管理中的关键状态同步给身份管理流程，例如任期结束、合同到期、培训批次结束、借调结束、设备维护完成等事件都可触发自动预警。业务负责人确认后，账号进入冻结、降权或删除流程。这样做比年底集中清理有效得多。
五、一个可执行的 9.2.1 流程应该具备哪些特征
- 用户注册必须以经过核验的身份来源为前提，不能凭口头指令或临时名单直接建号。
- 不同人员类别应有不同的账号模板和有效期要求，不能把正式员工、实习生和厂商统一按永久账号处理。
- 注册流程应记录责任人、审批人、岗位用途、起止日期和系统范围，保证账号存在有据可查。
- 注销或冻结流程应与人事、教学、项目、外包和合同结束事件联动，不能只靠 IT 定期人工清理。
- 对超期未注销、长期未使用和责任人已变更的账号，应设置预警和强制复核机制。
这些要求看似管理性很强，实际上与系统实现密切相关。若医院已有统一身份目录或 IAM 平台，应尽量把账号申请和停用接入统一流程；如果暂时没有，也至少要把关键系统的注册注销规则做成一致标准，避免不同系统各自凭经验处理。
六、审核这条时，最容易暴露问题的不是制度，而是抽样
审核人员通常会直接抽几类边缘人员：规培医生、进修护士、外包工程师、科研项目成员、返聘专家、近期调岗人员。因为这些对象最能说明账号生命周期管理是否只覆盖正式员工。如果机构对正式员工说得很清楚，对这些群体却只能回答“由业务部门通知我们开通或停用”，那就说明流程并未真正闭环。
成熟机构能做到：随机给出一个账号，就能追溯到其身份来源、责任部门、开通时间、批准依据、有效期和最近状态变化；随机给出一个已结束的项目或轮转批次，也能说明对应账号是如何冻结、降权或删除的。能做到这一点，9.2.1 才不只是“系统里有建号功能”这么简单。
七、结语
用户注册和注销是访问控制最前面的一道门，也是最容易被低估的一道门。医院一旦让不清不楚的身份进入系统，或者让已经离场的人继续保有账号，后续所有访问控制都只能在错误基础上继续堆叠。
所以，9.2.1 真正考验的不是信息科建号速度，而是组织能否把人员进入和退出医院数字环境这件事做成正式流程、可追溯记录和持续联动机制。只有入口和出口都稳住，患者信息的访问控制才有起点。