1. 医疗SaaS身份与租户治理全景

医疗SaaS与普通企业SaaS最大的区别，不在于功能多少，而在于它同时承载三类强约束：多租户隔离、统一身份与医疗合规。这三者彼此牵制——租户要隔离，但医生又可能跨机构执业；身份要统一，但患者隐私数据不能越界；合规要求可审计，但审计本身又需要跨系统关联日志。理解这套张力，是后续所有工程决策的起点。

一、多租户架构：隔离的粒度决定治理的难度

医疗SaaS的租户通常不是单一主体，而是“机构—院区—科室—人员”的嵌套结构。例如一家连锁体检集团（租户A）下辖3个院区，每个院区有独立检验科和影像科；另一家三甲医院（租户B）则按临床科室划分数据边界。租户模型一旦确定，身份体系就必须与之对齐。

常见的隔离策略有三种，其取舍直接影响身份治理复杂度：

• 共享库共享表（tenant_id 区分）：成本最低，但任何一次查询遗漏 tenant_id 条件都可能造成跨租户泄露，对身份上下文传递要求极高。
• 共享库独立 Schema：隔离性提升，适合租户数量中等、合规要求较高的场景，但跨租户统计与统一登录需要额外映射层。
• 独立数据库/独立部署：隔离最强，适合大型三甲或区域医疗平台，但统一身份需要依赖联邦或令牌交换，运维成本显著上升。

关键认知是：隔离粒度不是越细越好，而是要与租户的真实数据边界和合规责任一致。把两个法律上独立的医疗机构塞进同一 Schema，即使代码正确，合规审计也难以通过。

二、统一身份目标：从“能登录”到“可治理”

统一身份（Identity）在医疗SaaS中要达成四个层次的目标，而不是简单做一个单点登录：

1. 统一认证：医生、护士、技师、患者、管理员通过统一入口认证，支持账号密码、短信、OIDC、企业微信/钉钉、医院CA证书等多种方式。
2. 统一授权：权限模型要能表达“某医生在租户A的影像科拥有报告书写权，但在租户B只有查看权”这类跨租户、跨角色的细粒度关系。
3. 统一会话与上下文：一次登录后，用户在多个子系统间切换时，租户上下文（tenant_id、院区、科室）必须随令牌稳定传递，不能靠前端参数临时拼接。
4. 统一审计：谁、在哪个租户、什么时间、访问了哪条患者数据，必须可追溯、可关联、可导出。

这四层目标对应到工程上，就是身份提供方（IdP）、令牌、权限决策点（PDP）、审计日志四类组件的协同。下图展示了医疗SaaS中身份与租户治理的整体关系：

三、合规约束：不是附加项，而是设计输入

医疗行业的合规要求会直接改变身份系统的设计。以《个人信息保护法》和等保2.0三级为例，几个硬性约束必须前置考虑：

• 最小必要：令牌中不应携带超出当前操作所需的患者信息。例如影像科医生调阅报告时，令牌只需包含患者ID和检查号，不应包含完整身份证号。
• 数据分级：患者身份信息、诊断信息、影像数据属于不同级别，访问控制策略要按级别区分，而不是统一一个“医生”角色。
• 审计留存：登录、授权、数据访问、导出等关键操作日志需保留不少于6个月，且能按租户、按患者、按操作人三个维度检索。
• 患者授权：患者本人对其数据的访问授权应可撤回、可追溯，这要求身份系统支持患者侧的身份与授权管理，而非仅面向医护人员。

四、工程挑战：三个最容易出问题的环节

在真实项目中，以下三类问题反复出现，值得在架构评审时重点检查：

1. 跨租户身份映射。一位医生可能在租户A和租户B都有执业资格，但两边的工号、科室、角色不同。如果身份系统只用一个全局用户ID，权限就会串。正确做法是“全局身份 + 租户内身份档案”两层模型：全局身份负责认证，租户内档案负责授权。令牌中应同时携带全局 sub 和当前 tenant_id，PDP 依据两者共同决策。

2. 令牌上下文一致性。用户从租户A切换到租户B时，如果前端只改了页面参数而没有重新获取令牌，后端仍会按租户A的上下文执行，造成越权。工程上应强制“切换租户即重新签发令牌”，并在网关层校验令牌中的 tenant_id 与请求路径中的租户标识一致。

3. 权限缓存与失效。为提升性能，PDP 常缓存角色和权限。但当管理员在租户A中撤销某医生权限时，缓存若未及时失效，该医生仍可访问。建议采用“短TTL + 事件驱动失效”组合：普通权限缓存TTL不超过5分钟，关键权限变更通过消息通知各节点主动清除。

五、一个可参考的治理检查清单

在项目启动阶段，可以用下面这份清单快速判断身份与租户治理是否具备基础：