多业态养老机构在一套平台里分权限，核心是按“组织—角色—数据范围”三层建模：组织树表达业态和层级，角色绑定岗位，数据范围决定能看到哪些老人和业务单据。

为什么多业态不能靠“多建几套系统”来分权限？

集团下面同时有机构住养、居家上门、社区站点、医养结合，甚至还有政府监管报送，很多单位的第一反应是每个业态上一套系统。短期看边界清楚，长期看问题都集中在两边：老人从机构转居家、从社区转住养时档案要重录；集团想看整体服务量、护理工作量、补贴相关数据，只能靠人工合并表格；同一批护理员在两个业态之间调动，账号和权限要重新开一遍。

一套平台分权限的思路完全不同——系统只有一套，业态差异通过组织树和数据域表达。集团是根节点，下面按区域或业态分院区、站点、班组，权限挂在节点上，而不是挂在某一套系统上。

权限到底要分哪几层？

只做菜单权限是不够的。多业态场景下，权限至少要拆到五层，缺一层就会在实施阶段返工：

  • 组织层：集团—区域/业态—院区/站点—部门/班组，这是所有权限的骨架。
  • 角色层：院长、护理主管、护理员、护士、医生、评估师、助老员、财务、集团管理员，不同业态岗位名称不同，但角色可以复用。
  • 数据范围层：本人、本班组、本院区、本业态、全集团，这一层决定越权与否。
  • 功能层：菜单和操作按钮，比如能不能审批护理计划、能不能修改评估结论。
  • 字段层：身份证号、补贴相关字段等敏感信息单独授权，避免一线岗位看到不该看的。

同一老人在机构住养、又在居家接受服务，权限怎么划？

这是多业态项目里最容易出问题的地方。做法是“一老人一档案、业务数据按归属授权”：老人档案全集团唯一，但护理记录归属院区、上门工单归属服务站、评估结论归属评估部门。跨业态调阅要有明确授权动作，并留下查看痕迹。

反过来，如果为了省事把老人档案按机构复制多份，后面做服务过程监管、做补贴数据统计时对不上账，清理成本比重新设计权限高得多。

多业态项目里最常见的权限坑有哪些？

  • 只配了菜单权限，没配数据范围，一线人员能翻到其他院区的老人信息。
  • 为了安全做物理隔离，结果集团管理层看不到跨院区汇总，报表还得手工汇总。
  • 角色直接照抄单业态模板，助老员和护理员混用一套权限，工单和护理记录互相串。
  • 上线后才补数据域，历史数据要重新挂组织节点，工期和风险都翻倍。
  • 忽略代班、交接班场景，护理员临时顶岗时要么没权限，要么拿到过多权限。

落地时先定什么、后配什么？

顺序建议是：先画组织树和数据域，再定角色矩阵，最后才配功能和按钮。组织树没定清楚就急着配菜单，几乎是多业态项目的通病。

r>
顺序要定的事判断标准
第一步组织树与业态归属每个院区、站点、班组都有唯一上级，老人和员工都能落到节点上
第二步数据范围规则任何角色都能回答“他应该看到哪些老人”
第三步角色矩阵同类岗位跨业态复用，特殊岗位单独设
第四步功能与字段授权审批、导出、敏感字段单独控制

这套东西做完，最好形成一张权限矩阵表交给业务方签字确认，后面实施和验收都按这张表走。

软件层面靠什么支撑？

杰佳通智慧养老平台在居家养老、社区养老、机构养老、医养结合、民政养老监管等场景共用一套组织与权限体系，按组织节点授权、按角色分配数据范围，项目可以按业态组合部署，不用为每类业务单独维护一套账号。

给同行一条实际建议：多业态项目在签合同前就把组织树和数据域画出来，让业务方确认一次，比上线后再改权限省事得多。