1. Staff 创建机构、部门、用户流程图

画板

创建流程

  1. Staff 登录
  2. 机构管理列表
  3. 新增机构
  4. 填写机构名称、类别、所在地、来源、机构等级
  5. 提交审核
  6. 审核通过

创建部门

  1. 选中机构，新增部门/科室
    a. 科室/部门现存科室列表已存在，勾选科室列表即可
    b. 科室/部门现存科室列表不存在，自定义科室模板（科室模板为二级机构，定义的分类一定要有父类存在，如果是公司=>部门一级机构无法支持）

创建机构用户账号

  1. 填写用户姓名、电话、生日
  2. 选择用户所属的机构、部门

项目授权

  1. 对医生授权
    1. 首先要先对科室进行授权，才能对科室的医生进行授权
  2. 对科室授权
    1. 对科室授权会对科室当前下所有医生授权

医生权限控制

  1. MMC (new_group_role、new_doc_group、z_mmc_new_menu、z_mmc_new_button、z_mmc_new_role_right)
  2. 眼底（yandi_menu_main、yandi_doctor、yandi_report_permit）
  3. 垂体（z_pituitary_doctor、z_pituitary_menu_main）
  4. iHEC（new_doc_group、new_group_role、new_z_pro_menu_main）
  1. 选择医生
  2. 编辑权限
  3. 勾选项目对应的应用及其菜单

项目的应用菜单被分割，每个项目的应用独自存储，意味着每增加加一个项目都得新增一个新的表来扩充设计。没有适用性。（技术上，非业务的不兼容）

不能兼容SaaS业务场景的部分

  1. 医生即便未被授权项目，但是医生授权了项目的菜单权限，就可以登录项目的工作站。删除了科室授权之后，医生授权并未被删除。（功能、实现 bug）
  2. SaaS 设计，对科室/部分授权一个项目的本质是控制项目的数据是否落在部门科室内，也就是控制数据的可见性。对机构单个用户授权一个项目的目的是为了控制医生录入的患者信息和测量信息归属于项目内，不落在科室内。现有设计做不到数据只落到项目，不落到科室中。
  3. 一个机构用户如果没有授权项目，那么他一定不可以被单独授权操作项目的工作台（站），包括登录等。（如果修改，现有的所有 B 端登录场景都需要改，MMC 医护工作站、iHEC pro 站点、MMC-WinApp）。
  4. 除以上列出的业务场景，其他暂未发现不能兼容。

机构、部门、用户账户统一

  1. 存在统一的中心化列表
  2. SaaS 和 之外的系统都统一读写中心化列表
  3. 修改需要直接应用到中心化

结论

  1. B端机构、部门、用户账号统一中心化存储和维护
  2. SaaS 及非 SaaS 通过中心化的接口进行数据的增删改查
  3. ID 一致，其他系统冗余部分信息，冗余部分的信息如有变更，需要中心化系统通知，可以通过消息订阅方式实现，通过查询后比较得知改变然后自我更新。
  4. 业务待修改部分，SaaS 及 MMC、iHEC等注册、修改医生任何相关信息的部分都需要修改。
  5. 都要同步到中心中去。

机构、部门、用户账号打通

打通的本质

  1. SaaS和非SaaS相互同步
  2. 修改相互同步

结论

  1. 2个数据库，相互独立，各自维护。通过接口或消息订阅互相同步数据。
  2. ID 不一致，互相存储和维护各自的 ID。
  3. 业务待修改部分，SaaS 及 MMC、iHEC等注册、修改医生任何相关信息的部分都需要修改。
  4. 要同步到另一个系统中去。

以现有的数据库和服务为中心改造方案

  1. 已现有结构为中心，科室部分数据打标签，仅用于当前系统，以后新增类似于五月血压的科室，在功能上直接打标签。
  2. 同步现有的机构、部门（打标签）、用户到 SaaS，且需要开发对外的同步功能（API或消息系统订阅）
  3. 只有现有系统一个入口管理机构、部门、用户
  4. 现有系统项目和 SaaS 没有任何关系，互不相关。

待解决问题

  1. 短信签名和代码耦合过深，如新增签名，得修改业务代码。
  2. 项目的应用菜单被分割，每个项目的应用独自存储，意味着每增加加一个项目都得新增一个新的表来扩充设计。没有适用性。
  3. 存在的大量使用医生姓名命名的科室，如果要删除，必须要清洗数据。（占比 2600/1200）
  4. 机构的部门，只支持二级结构，一级结构不支持。
  5. 项目对部门和用户的授权，用来控制数据的可见性即数据落在项目中只能被项目方可见，还是数据落在科室被整个科室和项目可见。现在做不到灵活的配置可见性，只能对科室可见。
  6. 有没有菜单权限是严格校验的，而不仅仅是通过前端菜单来控制的。账号是被否授权以及是否有应用的菜单操作权限应该结合起来。
  7. 现在代码逻辑不支持一个医生在两个科室的情况，需要修改业务代码。更详情的无法评估。
  8. 目前存储的密码方案不安全。存在风险。