新一代医院信息系统（NGHIS）设计（2）——基础集成平台(I)
一、背景介绍
基础集成平台是信息系统的基础设施环境，为各应用系统提供公共基础设施（如ESB、消息中间件等），将各系统的通用基础服务功能（如用户管理、授权管理、配置管理等）从业务系统剥离出来，使得业务系统聚焦于业务流程和业务功能，实现更好的可管理性和用户体验。
在新一代医院信息系统（NGHIS）中，基础集成平台是医院内部各业务系统赖以运行的基础环境，没有基础集成平台，应用系统将无法完成用户身份认证和资源访问控制。基础集成平台向应用系统开放用户认证、资源访问授权等服务接口，也可以通过医院服务总线与各业务系统之间保持松耦合关系；健康医疗云平台也需要通过基础集成平台实现统一用户认证、统一授权管理和统一配置管理。
二、系统结构设计
（一）NGHIS总体结构
基础集成平台是医院基础信息平台和健康医疗云平台的重要基础设施，无论是医院端的应用系统还是云端的互联网平台，都需要基础集成平台提供用户认证、授权管理等基础服务。医院端应用主要存在三种形态：第一种是在院内安装部署数据库的松耦合系统（NGHIS，Next Generation HIS），完全基于院内局域网处理所有业务；第二种采用云+端结合的方式，在医院内部部署的简洁型HIS（CHIS，Compact HIS）作为应急系统，与云端服务协同配合使用，当广域网故障无法访问云端时，应急系统仍然可以满足医院的应急业务应用需要（包括挂号、收费、发药、医嘱处方处理、病历书写打印等）；第三种是完全使用瘦客户端访问云端应用服务及数据的轻便型HIS（PHIS，PortableHIS），云端不可访问时暂停所有系统操作。
图1 新一代医院信息系统总体结构
（二）基础集成平台架构
基础集成平台是不区分行业特性的通用应用软件基础设施，主要包括统一认证授权（UAA）、统一配置管理（UCM）、统一消息管理（UMM）、统一用户中心（UCM）和单点登录（SSO），基础集成平台单点登录推荐使用耶鲁大学的开源CAS，也可以使用其他第三方SSO系统。基于统一认证的用户账户信息，对外提供符合OpenID规范的用户认证服务（OpenID Provider），并分别针对C/S和B/S应用封装用户认证及权限管理的开发库（AA-Lib），统一认证中心的用户账户信息，通过用户账户复制（UAR）系统实现与外部第三方用户数据库（包括微软AD域用户和LDAP用户）的用户数据同步。社会组织模型管理提供一个简约的社会组织关系数据维护，主要包括法人及其组织架构、自然人、网格化社会组织结构等基础数据的管理与维护。
图2 基础集成平台系统结构
三、系统功能设计
（一）统一认证授权(UAA)
统一认证授权系统负责企业信息化应用的组织架构、用户账户、应用系统、用户授权等基础管理功能。
统一认证授权系统设置系统管理员、机构管理员、应用管理员、授权管理员、客服员等用户角色。系统管理员负责平台全局性的基础数据维护，包括岗位信息维护、应用信息维护、顶级机构创建等。机构管理员负责下级机构创建、机构岗位设置（包括机构岗位目录、岗位员额编制、岗位权限等）、机构用户管理（包括用户创建、用户冻结、用户权限设置）等。应用管理员负责其所管辖应用系统的数据初始化（资源维护、角色维护、角色可访问资源设置等）、应用权限分配（机构应用角色、机构岗位角色、用户组角色）、应用授权查询（查询特定应用资源的权限分配情况，包括什么角色能够访问该资源、哪些机构具有该资源的访问权限、哪些机构岗位拥有该资源的访问权限、哪些用户拥有该资源的访问权限）等。授权管理员负责其所辖机构的权限分配管理工作，包括为机构岗位分配应用角色和对机构所属用户进行权限管理。客服员负责系统日常使用的用户授权运维，包括重置用户密码、用户权限查询、用户账户冻结及冻结用户重新激活等操作。
1、系统管理
系统管理是系统管理员用于维护平台公共基础信息的功能，主要包括岗位维护、机构维护和应用维护。
图3 系统管理功能结构
（1）岗位维护
岗位是全系统共享的全局岗位，各机构只能从全局岗位中选取本机构启用的岗位，不能自行增加岗位名称，以保持岗位名称的一致性。
岗位维护功能包括岗位的新增、修改，岗位名称一旦增加，就不允许删除，可以设置为禁用状态，禁用状态的岗位，不能被机构选取，但不影响已经启用该岗位的机构正常使用。
（2）机构维护
系统管理员的机构及机构岗位维护功能，包括新增顶级机构、机构信息修改和机构岗位设置，子机构的创建一般由机构管理员负责，系统管理员也可以通过组织管理功能创建子机构。
创建顶级机构时，需要同步创建或指定一个机构管理员，由该机构管理员通过使用组织管理功能维护该顶级机构的下属机构维护和用户管理。
（3）应用维护
维护各应用系统的基本信息及其对应的应用管理员，应用管理员负责其所管理应用的基础数据维护和应用授权管理。
2、组织管理
组织管理是机构管理员用于对其所属机构的组织机构和用户进行管理的主要界面，功能包括子机构创建、机构信息修改、机构岗位设置以及用户管理。机构管理员只能管理其所属机构及下属机构的机构信息及用户信息。
图4 组织管理功能结构
（1）机构维护
机构维护包括子机构新增、机构信息修改以及机构岗位管理。机构管理员只能维护其所属机构及下属机构的机构信息。
l 子机构新增：机构管理员可以其所属机构的任意节点创建子机构，机构信息原则上不允许删除，不再启用的机构可以设置为禁用状态。
l 机构信息修改：修改机构的基本信息。
l 机构岗位设置：设置管辖机构启用哪些岗位，启用岗位的编制数量等，并维护各岗位的权限，当用户启用企业级授权体系时，用户所拥有的应用操作权限，将取决于该用户所处的岗位，用户的权限将随着岗位的变动而自然变动，减轻IT运维的权限管理工作。需要特别授予或特别限制的权限，由授权管理员针对用户进行个别设置。
（2）用户管理
用户管理功能主要用于管理用户账户及其权限，包括创建用户、用户冻结、用户激活、重置密码、用户权限设置等。
l 用户账户新增：为尚未创建用户的员工创建用于身份认证的账户。机构管理员无权增加员工信息，员工信息需要统一用户中心或者人力资源管理系统进行维护。
l 用户密码重置：重置某一用户的登录密码，用户密码被重置后，系统向用户发送一个随机的验证授权码，用户使用该验证授权码重新设置其登录密码。
l 用户冻结：将正常的账号设置为冻结状态，被冻结的用户将不允许登录，冻结的用户被激活以后可以正常使用系统。
l 用户激活：对被冻结的用户进行激活，以便该用户可以重新登录系统。
l 用户权限设置：根据用户采用的授权体系，进入配套的界面对用户的权限进行维护设置。
3、应用管理
应用管理功能是应用管理员维护应用信息和分配应用权限的主要操作功能界面。当部署的应用系统数量较多时，一个应用管理员难以管理所有的应用系统，因此系统管理员在注册登记应用系统时，为应用系统指派了应用管理员。应用管理员通过应用管理功能，只能看到系统管理员为其分配的应用，并对这些应用系统的基础信息（包括应用资源、角色、角色可访问资源等）和应用权限分配进行管理。应用管理员无权注册应用，只能对系统管理员为其指派的应用进行管理。
图5 应用管理功能结构
（1）应用修改
修改应用系统的基本信息（如版本信息、部署时间、运行状态等）。
（2）资源维护
维护应用系统的资源，包括新增、删除、修改等。
（3）角色维护
维护应用系统的角色信息，以及角色可访问的应用资源。
（4）应用授权
将应用系统的角色授予机构、机构岗位或用户组。应用管理员可以直接将应用角色授予各机构岗位及用户组，也可以只将应用角色分配到机构，再由机构管理员或授权管理员将机构所拥有的应用权限授权到岗位、用户组或用户。
（5）授权查询
对应用资源或角色的授权情况进行查询，便于了解应用是否存在授权安全风险，如敏感资源访问权限是否约束度不高的岗位、用户组或用户。
4、授权管理
授权管理是授权管理员日常授权管理工作的主要功能界面，包括设置或调整岗位权限和用户授权工作。授权管理员无权创建用户，只能对所属机构及其下属机构的用户进行权限管理。
图6 授权管理功能结构
（1）岗位权限管理
维护授权管理员所属机构及其下属机构的岗位权限信息，为机构岗位增加授予应用角色，可供选择的应用角色来源于应用管理员给该机构授予的应用角色，或者撤销某一机构岗位已经拥有的应用角色。
（2）用户授权管理
根据用户账户信息中设定的授权体系，调出相应的授权管理功能，完成用户权限设定。
l 企业授权体系：企业授权体系采用岗位授权方案，对机构岗位的权限进行统一设定以后，调入相关岗位的人员自然拥有相应岗位的权限，岗位变动时，权限亦随之变动。为了增加灵活性，可以对用户单独进行特例授权或特殊限权，被特例授权的用户，除了拥有岗位的所有权限外，还额外增加特例授权的权限；被特殊限权的用户，将失去指定限制的权限，哪怕其岗位拥有该权限或者特例授权该权限。当组织规模较大，或者组织比较健全时，适合采用企业授权体系。
l 标准授权体系：标准授权体系采用用户组授权方案，对用户组统一进行授权后，将用户归入一个或多个用户组，让用户具有其所属用户组的所有操作权限。标准授权体系适用于能够将用户归类到数量不多的分组的应用场景，且只能有一个系统维护人员，若需要将系统管理任务逐级分解到不同的人员，也建议使用企业授权体系。当用户分类特别复杂时，建议采用企业授权体系。
l 简易授权体系：简易授权体系直接对每个用户授予应用角色，适用于系统维护人员单一，用户数量较少的场合，如员工数量很少的组织。
5、用户服务
服务人员为了解答信息系统使用者日常操作过程中出现的与授权相关问题，需要使用该功能获取必要的数据支撑，并协助用户进行一些不影响系统安全的操作（如用户密码重置）。
图7 用户服务功能结构
（1）用户权限查询
查询用户所拥有的权限，包括授权权限、委托权限、受托权限，以及当使用企业授权管理体系时的特例授权和特殊限权。
（2）应用授权查询
对应用资源或角色的授权情况进行查询，便于了解应用是否存在授权安全风险，如敏感资源访问权限是否约束度不高的岗位、用户组或用户。
（3）用户密码重置
重置某一用户的登录密码，用户密码被重置后，系统向用户发送一个随机的验证授权码，用户使用该验证授权码重新设置其登录密码。
（4）用户账户冻结
将正常的账号设置为冻结状态，被冻结的用户将不允许登录，冻结的用户被激活以后可以正常使用系统。
（5）冻结账户激活
对被冻结的用户进行激活，以便该用户可以重新登录系统。
6、个人中心
个人中心是面向已经通过认证的登录人提供的针对其个人账户的信息维护及常用操作，包括重置密码、修改登录密码、个人外部账号维护、个人联系信息维护、值班签到签退、权限委托等。
图8 个人中心功能结构
（1）登录密码重置
由于忘记密码，个人申请密码重置。系统向该账户的密码保护手机或邮箱发送验证码，用户通过特定的密码重置界面，输入新的登录密码和验证码，若验证码验证有效，则将该用户的登录密码设置为新密码。密码重置申请也可以由管理员或客服人员发起，由用户在有效期内进行重置。
（2）修改登录密码
为了提高账户的安全性，建议定期修改账户的登录密码。修改登录密码需要验证当前密码，只有当前登录密码验证通过后，才能将该用户的登录密码修改为新密码。
（3）个人外部账户
维护登录账户对应的员工的外部账户信息，如远程医疗账户、电视电话会议账户等。
（4）个人联系信息
维护登录账户对应的员工的联系信息。
（5）值班签到
签到到选定的轮值岗位，将个人设置为该岗位的在岗值班人员。
（6）值班签退
从在岗的轮值岗位签退。
（7）权限委托
将个人所拥有的部分或全部权限，委托给其他人员，在委托有效期内，受委托人将具有委托人授予的委托权限，以便在委托人不在岗时，受委托人可以处理本该由委托人处理的事务，避免业务因委托人的不在岗而受到耽误。
（8）受托权限
查询个人所拥有的受委托权限。
（二）统一配置管理（UCM）
统一配置管理系统用于统一对各应用系统的可配置参数进行集中管理，以便通过单一功能入口管理各类应用系统的可配置参数。应用的可配置参数项，采用键值对存储，同一配置参数项的值，可以在应用（全局）级、机构级和个人（用户）级进行设置，个人配置值优先于机构配置值，机构配置值优先于应用（全局）配置值。也就是说，如果某个配置参数在个人配置项下有定义，则优先取个人配置项的值，否则如果机构配置项下有定义，则取机构配置项的值，最后再取应用配置项下的值，如果都没有定义，则取默认值。
应用可配置参数采用类似于Windows注册表的结构存储，具体实现可以采用网络文件、数据库、LDAP等多种形式。
图9 统一配置管理需求用例
1.配置服务管理
设置应用系统存取配置参数的服务地址。应用系统启动时，或运行过程中，将从配置的服务地址存取配置参数。
2.配置导入导出
将配置服务中各配置项下的参数值导出到文件，或从文件导入到配置服务中。导出、导入时，应该让用户选择导入导出的机构及个人。
3.应用配置详情
显示应用的可配置参数列表详情，以及机构配置项、个人配置项下的各参数设定值。
（三）统一用户中心（UUC）
统一用户中心为基础集成平台的员工管理中心，通过统一用户中心集中管理组织架构和职员。一般作为尚未部署人力资源管理系统的机构进行人力资源管理的工具，主要功能包括员工管理和值班管理等。
1.员工管理
员工管理功能包括岗位编制维护、员工账户管理、员工信息维护、员工岗位设置和人事异动业务。
图10 员工管理功能结构
（1）岗位编制维护
设置各机构岗位的编制数量，维护岗位职责和岗位技能要求。
（2）员工账户管理
为尚未创建用户账户的员工创建用于信息系统进行用户身份认证的用户账户，设置用户账户的基本信息（如用户授权体系、是否默认账户、是否自动同步岗位信息等），或者冻结用户账户、激活已冻结账户、重置用户密码等。
（3）员工信息维护
维护员工信息，包括从人力资源系统同步员工信息或者从外部文件导入员工信息、员工信息新增、基本信息修改、联系信息维护、外部账号维护等。
l 人力资源同步：采用信息接口的方式，从人力资源系统获取用户信息，用户刷新本平台的用户信息，对于已从人力资源系统消失的员工，标志为禁用（离职）而不作删除。
l 员工信息新增：手工录入新员工的信息，创建员工基本档案，以便为员工创建其认证账户，只有系统管理员和机构管理员才能通过组织管理凭空（即没有员工资料档案）创建认证用户账户，员工管理员创建的用户认证账户，前提是存着该账户对应的员工。
l 基本信息修改：修改员工的基本信息，包括姓名、性别、身份证件信息等。
l 联系信息维护：维护员工的各种方式的联系信息，如手机、座机、办公电话、电子邮箱、即时消息号码等。
l 外部账号维护：维护员工使用的外部账户，如电视电话会议账号及其他第三方平台的账号。
（4）员工岗位设置
维护员工的工作岗位，当员工的工作岗位发生变化时，若其认证账户设置了自动同步岗位，则该认证账户的岗位将与员工的岗位保持同步。这样，如果该用户使用企业授权体系，那么其权限自然随着人事岗位的变动而自然变动，不再需要IT运维部门参与人事变动的信息维护，减少IT运维工作量。
（5）人事异动业务
人事异动业务实现简单的可追溯的员工信息动向，包括员工入职、员工离职和员工调岗等。通过人事异动业务驱动员工信息、员工状态的变化，避免直接使用系统维护功能维护员工岗位。人事异动业务建议采用制单-审核分离原则，形成相互监督制约的机制，防范员工授权错误的风险。
2.值班管理
在一些行业（尤其是医疗服务行业、安全保卫部门等）中，存在值班制度，在非工作时间及节假日安排人员轮流履行特定岗位职责。为了在外部业务协同中让对方更容易寻址、定位到相关岗位的值班人员（尤其使用网络视频呼叫、电话呼叫等方式），将值班岗位设置为特殊的人员，为其设置固定的呼叫联络方式，这样不管如何安排轮值，外部都可以轻易地与其取得联系。
图11 值班管理功能结构
（1）轮值岗位维护
维护组织机构的值班岗位及其相关联系信息、外部账户信息等，功能类似员工信息维护。
（2）值班签到签退
当值班人员不通过个人中心进行值班签到、签退时，通过此功能集中设置组织机构各轮值岗位的人员在岗及离岗状态及时间。
（3）值班岗位查询
查询各轮值岗位的在岗情况及值班人员信息。
（四）统一消息管理（UMM）
统一消息管理为认证用户提供统一消息收发接口，支持手机短消息、即时消息、电子邮件等消息类型，并可以支持多个消息网关，系统根据消息接收人的目标地址，自动选择最优的目标消息网关发送。
图12 统一消息系统需求用例
1.消息系统控制台
消息控制台是消息管理员用户配置消息系统、监控系统消息收发情况的主要功能界面。
（1）消息接口配置
配置消息系统的消息网关及其路由规则。
（2）收发消息查询
查询、监控消息系统的消息收发情况，能够根据特定条件（如发生人、接受人、时间段、内容等）查询消息收发记录。
2.系统收发统计
统计消息系统的消息收发情况，包括全系统和特定用户在指定时间段的统计数据。
3.个人消息
个人消息是登录人个人消息及消息业务的总入口，对个人消息进行归类，系统默认将已经编制但尚未发出的消息归入草稿箱，将收到的消息归入收件箱，将已经发出的消息归入发件箱，已经删除的消息归入垃圾箱（回收站），允许用户自行创建新的归类，并自由将消息在不同分类之间（草稿箱除外）移动。
（1）草稿箱
用户编写的消息，在尚未发送之前，默认存储在草稿箱中。通过草稿箱可以调出消息，继续修改，直至发送或删除。
（2）收件箱
用户收到的所有各类消息，自动保存到收件箱。
（3）发件箱
已经成功发送的消息，自动保存到发件箱。
（4）垃圾箱
删除的消息，保存在垃圾箱。系统在个人消息存储容量不足时，将自动清理垃圾箱，将消息彻底删除以便释放其占用的存储空间；系统也会定时清理垃圾箱，哪怕存储空间充足，消息在垃圾箱中存储一定时间后也被彻底删除以释放空间。
（五）用户账户复制（UAR）
为了更好地兼容多种应用环境，统一用户认证（UAA）中心的用户账户信息，可以与第三方账户数据库实施自动同步。在UAA和第三方账户数据系统分别安装部署账户同步器，将其中一边设置成源账户中心，另一边设置为目标账户中心。账户同步器将订阅源账户中心的账户变动事件，或者定期查询源账户中心的变动账户信息，并将这些账户变动事件发送给目标账户中心的同步器。目标账户中心的账户同步器收到源账户中心发送的消息后，将对本地的目标账户中心相关账户信息进行设置，保持目标账户中心的账户信息与源账户中心同步。目标账户中心同步器也可以主动向源账户中心的同步器发送账户查询请求，获取源账户中心的账户信息并同步到本地目标账户中心。
第三方用户账户中心类型主要考虑支持常见的微软AD域用户数据库和LDAP用户数据库，其他类型的用户账户中心，根据需要进行定制化接口开发。
图13 用户账户复制需求用例
（六）单点登录系统（SSO）
单点登录（SSO）系统允许用户只登录一次，就可以在不同的应用系统之间实现免重复登录的用户身份识别，基础集成平台使用耶鲁大学开发的中央认证系统CAS（Central Authentication System）作为单点登录系统。
在CAS系统中，用户使用身份证明（Credential，比如用户名密码、个人数字证书等）在CAS登录，CAS生成用户总票据（TGT，TicketGranting Ticket），用户拥有这个TGT就可以证明其已经在CAS登录过。
当用户访问某个受保护的应用资源时，在B/S应用中，这个访问请求被应用服务器的过滤器拦截，用来判断该Session是否有用户信息或者有CAS颁发的访问该资源的授权（即服务票据ST, Service Ticket）。如果Session中已经有用户信息，则表明用户已经通过该应用的身份认证而允许其访问；如果Session中没有用户信息，但是有服务票据ST，则拦截器（调用CAS Client）向CAS申请对ST进行验证，如果ST验证有效，就返回用户信息并记录在Session中，实现用户在该应用的身份认证。如果既没有用户信息，也没有服务票据ST，表明用户尚未登录，拦截器将浏览器重定向到CAS的登录页面进行用户登录，登录成功后，CAS生成用户总票据TGT，并使用TGT和原访问的目标应用生成针对目标应用的服务票据（ST），再将用户浏览器重定向到原访问的目标资源，同时将ST作为参数传递给应用服务，应用服务器的过滤器再次拦截请求，此时发现有了ST，即向CAS申请对ST进行验证，完成应用的用户认证，并在Session中记录用户信息。
C/S应用系统的客户端由于无法像B/S应用的Web端那样嵌入拦截过滤器实现单点登录，这就要求C/S应用程序在启动时接收服务票据ST，并主动向CAS申请对ST进行验证，验证通过返回登录的用户信息，完成对用户的身份认证。
如果C/S应用程序在启动时，没有接收到服务票据ST，应从命令行参数获取用户身份证明（用户名密码、数字证书等），或者打开用户身份证明输入窗口，通过用户身份证明向CAS申请认证，或者打开CAS的登录页面实现用户登录。C/S应用的用户登录完成后，应通过服务接口向CAS申请获取用户总票据TGT，以便能够让C/S应用程序使用TGT向CAS申请访问其他应用程序的服务票据ST，将ST作为参数传递给其他兼容CAS单点登录的应用，实现C/S应用程序之间以及C/S与B/S应用程序之间的单点登录。
（七）统一认证授权编程接口（AA-Lib）
为了方便应用程序身份认证的功能开发，需要向开发人员提供基础集成平台的用户认证编程接口。编程接口主要提供Windows环境的DLL和Java、Php等编程语言的开发包。编程接口主要包括用户认证、用户信息获取、用户角色获取、用户资源获取和用户权限判定等，同时也提供用于向基础集成平台更新应用资源及角色的工具类接口，包括更新应用资源、更新应用角色和更新角色资源。
在统一认证授权管理方案中，应用程序要在一些对用户权限敏感的功能点，对当前用户是否拥有特定权限进行判定检查，检查当前用户是否有权访问特定资源，或者检查用户是否拥有特定角色，所需的资源或角色可以编码在用户程序代码或界面资源中，如果用户拥有相应的角色，或者被授予访问该资源，就允许用户继续访问，否则拒绝用户访问。
1.身份认证
根据用户身份证明向基础集成平台申请用户身份认证，认证成功则返回用户总票据（TGT）以及简要的用户信息（用户ID、用户名称、真实名称、员工ID、所属机构等），输入参数包括：用户身份证明、认证服务器地址、特殊附加信息等。
2.票据验证
验证TGT或者ST的有效性，如果验证有效，则返回用户授权Token以及简要的用户信息（用户ID、用户名称、真实名称、员工ID、机构ID等），输入参数包括：票据、AppID。
3.用户信息
根据用户授权Token获得用户信息（如机构信息、岗位信息等），或者查询一些不常使用的用户信息项，输入参数包括：Token、机构ID、选项。
4.用户角色
根据用户授权Token获得用户的角色列表，输入参数包括：Token、AppID。
5.用户资源
根据用户授权Token获得用户可访问的资源列表，输入参数包括：Token、机构ID、AppID。
6.角色判定
根据用户授权Token判定用户是否拥有某几种角色，输入参数包括：Token、机构ID、AppID、角色集合。
7.资源判定
根据用户授权Token判定用户是否拥有某几个资源的访问权限，输入参数包括：Token、机构ID、AppID、资源集合。
8.应用资源更新
更新应用系统在基础集成平台注册登记的资源，输入参数包括：AppID、AppSecret、资源列表。
9.应用角色更新
更新应用系统在基础集成平台注册登记的角色，输入参数包括：AppID、AppSecret、角色列表。
10.角色资源更新
更新应用系统在基础集成平台注册登记的角色授权，输入参数包括：AppID、AppSecret、角色资源关系列表。
（八）OpenID认证服务
基于OpenID的标准规范，实现OpenID Provider服务，使得基础集成平台的用户账户，可以被遵循OpenID标准的外部应用或网站用于用户认证。
建议新开发的应用程序遵循OpenID的用户认证标准，这样即便不考虑单点登录，也更有利于实现多个系统之间的集中用户管理和授权，使得应用程序可以在用户部署环境下灵活选择不同的认证服务器（需要认证服务器支持OpenID）。
（九）社会组织模型管理（SOM）
社会组织模型管理主要为网格化社会管理提供基础数据维护功能，主要包括社会网格化属性（行政区划、乡镇街道、社区商圈、村屯组小区等）、社会基本单元（基本物业单元、家庭等）、社会资产资源（地表地貌地物、水系、交通道路、地下管网、空间轨道等）、自然人信息和法人信息等数据库。通过自然人信息库、法人信息库和社会资产资源信息库的建设，实现更好的社会资源信息共享，以便更好地支持跨政府部门、跨行业的基础数据资源共享。
图14 社会组织模型需求用例
1.自然人信息库
自然人是家庭成员、法人机构员工和社会人群管理的基础数据。通过自然人信息数据库，建立贯穿个人一生的人员主索引。
2.法人信息库
管理法人机构的基本信息及其分支机构（部门）、员工等数据的维护。
3.资产资源信息库
各类社会资产资源的基本信息及空间信息，主要包括地表地貌地物、水系、交通道路、地下管网、建筑物、设施设备等。
4.社会网格化信息
社会网格化信息主要包括行政区划（县区级）、乡镇街道及社区商圈、村屯组小区（道路）等社会网格关系以及基本物业单元（栋、层、单元、门号）和家庭等社会基本单元信息。
四、数据库设计
在数据库模型中，背景为绿色的实体，表示表的数据一旦初始化后便极少新增或修改，如代码表；背景为粉色的实体，表示表的数据会因机构规模增长或时间流逝，缓慢增长的表，这类表的数据一般与业务量没有关系，数据增长缓慢，数据变更频率低；背景为黄色的实体，表示数据会随着业务量的增长而增长，此类表数据增长速度较快，需要定期进行重建索引、分区存储等优化；背景为蓝色的实体，表示表的数据为临时数据，其中的记录最终会被删除，因此存储容量基本不会太大，但由于频繁进行删除操作，也需要定期关注存储空间碎片问题。
（作者已经针对常用的Oracle、SQLServer、MySQL等数据库生成了数据库建表脚本，并提供数据字典文档，需要的同学请从下载资源处搜索“基础集成平台”下载或向作者索取）
（一）组织机构
图15 组织机构实体关系模型
组织机构采用树形结构表示，每个顶级机构形成一个独立的体系，具有类似租户的特性。机构的岗位从全局的岗位名称表中选取，并根据机构规模设定岗位的人员编制熟练。各机构岗位的权限（即角色）由本机构具有管理权限的人员（机构管理员、应用管理员、授权管理员等）进行管理。用户归属某一机构，该机构为其默认的机构，即用户信息表中的机构ID。用户登录系统后，默认使用其所属机构，但可以根据从其用户岗位表中选择其他机构，切换成当前应用系统的工作机构。
（二）用户与职员信息
图16 用户与职员实体关系模型
基础集成平台进行身份认证的主体信息是用户，大部分用户指代某个职员，部分用户可能是指代某个系统或设备甚至指代特殊的人群（如超级用户）。当用户信息中具有职员ID，表明该用户代表该职员。由于用户认证已经独立于应用系统，应用系统不再维护用户信息，甚至用户信息对应用系统不可见，但是职员信息是对业务系统可见的，因此，当业务系统产生的业务数据需要记录相关责任人时，应当使用其对应的职员信息，而不是用户信息。
用户账户可以绑定手机号码、电子邮件或登录名，通过手机号码、电子邮件或登录名对用户账户进行唯一索引（数据结构参见互联网注册用户）。
员工在系统内部用员工ID唯一标识，在外部表现上一般采用工号，员工工号在一定时间内具有唯一性，但是工号可能会被回收重复使用，比如有些单位领导的工号，一直使用固定的001、002或者666、888等特殊工号，当领导更换时，新任领导继续沿用该特殊工号。
职员信息表中，有一类特殊的“轮值人员”，其本身不是员工，而是需要排班轮值的岗位，该岗位具有固定的联系方式和外部账户信息。引入轮值人员的概念，是为了便于外部协同单位或人员联系到当班人员，不因排班或换班而受到影响。
（三）互联网注册用户
图17 互联网注册用户实体关系模型
基础集成平台支持互联网用户的注册、认证和授权管理。互联网注册的用户不属于任何机构，因此不存在与之对应的员工信息，但通过组织机构员工创建的用户账户，依然以作为互联网用户登录互联网平台。
第三方用户是指微信、支付宝、钉钉等第三方应用平台的用户，通过OAuth授权访问本平台，此时需要将第三方用户与本地用户账户进行绑定，使用本地账户的授权访问本地应用。
新注册的互联网用户，默认使用标准权限体系，即基于用户组的权限分配。
（四）应用信息
图18 应用信息实体关系模型
应用信息表的内容包含用于授权管理的应用和用于单点登录的应用，仅用于单点登录的应用不需要维护其资源和角色，只需要维护其访问入口、认证方式、启动方式等基本内容。
（五）社会组织模型
社会组织模型的数据结构及系统功能，放在医疗健康云平台中设计，目前基础集成平台暂不包含社会组织模型管理。
（六）企业授权体系
图19 企业授权体系实体关系模型
企业授权体系下的用户权限，由用户岗位表关联到机构岗位角色表，得到用户岗位对应的角色，再加上用户受托权限表拥有的有效期内的角色和用户独立授权表的角色，最后排除用户独立限权表的角色，就是该用户所拥有的全部角色。
给用户授权，主要通过设置用户岗位实现，若用户具有特殊性，可以通过用户独立授权表为用户额外增加授权，通过用户独立限权表为用户排除某些权限的应用。
用户将其拥有的部分或全部权限委托给受委托人时，同时在用户委托权限表和用户受托权限表产生数据，其中用户委托权限表中的用户ID为委托人的ID，受托权限表中的用户ID为受托人的ID。
用户所拥有的全部应用角色可以访问的应用资源，就是该用户有权访问的资源（开放授权的资源所用用户都可访问）。
（七）标准及简易授权体系
图20 标准及简易授权体系实体关系模型
标准权限体系使用用户组权限，先对用户组设置该组具有的应用角色（即用户组应用角色表），然后再将用户组授予用户，用户便具有所属用户组的相应应用角色。一个用户可以隶属于多个用户组。
简易授权体系不采用用户组，直接对用户授予应用角色（即用户授权角色表），判断用户权限时，直接从用户授权角色表中查询该用户的应用角色。
用户所拥有的全部应用角色可以访问的应用资源，就是该用户有权访问的资源（开放授权的资源所用用户都可访问）。
（八）用户单点登录配置
图21 用户应用配置实体关系模型
单点登录集成用户桌面环境（SSO-UIDE），使用用户应用配置表获取用户配置的常用应用及其认证方式和启动参数，实现集成用户桌面环境的配置漫游。用户应用配置表的应用信息，可以是应用信息表中注册的应用（即应用ID非空的记录），也可以是用户独立配置的应用（即在应用ID为空的记录），当应用ID非空时，应用类型、认证方式、网页启动URL、本地启动命令行、自动填表配置文件等字段内容，如果用户应用配置表中为空值，则取应用信息表中的相应字段值。