权限控制方法和装置与流程

1.本发明涉及互联网医疗技术领域，尤其涉及一种权限控制方法和装置。


背景技术：

2.现有技术中，通常采用基于角色的权限控制方式。将角色与权限进行关联，一个用户拥有若干角色，每一个角色拥有若干权限，构造成“用户-角色-权限”的授权模型。权限包括：菜单权限、资源操作权限等。授权模型的相关数据采用数据关系集中管理，一般存储于数据库中。每次用户请求页面，加载数据关系，获取该用户的可用权限。
3.随着互联网医院业务的快速发展，角色、问诊类型、业务功能等维度都在不断增长。例如：互联网医院应用通常需支持医生、护士、医助等多种角色，兼职医生兼职医助、兼职医生全职医助等多种医生间合作关系，图文、电话等多种服务类型。
4.互联网医院应用中，在问诊核心流程上设置有多个功能，每个功能需要根据角色、合作关系及服务类型等维度进行权限控制。由于上述维度均具有多种取值，权限控制逻辑变得非常复杂。
5.现有的基于“用户-角色-权限”的授权模型，权限控制维度单一，只能通过角色维度进行权限校验，无法灵活地适用于互联网医疗场景下的各种应用场景。


技术实现要素：

6.有鉴于此，本发明实施例提供一种权限控制方法和装置，能够灵活地适用于互联网医疗场景下的各种应用场景。
7.第一方面，本发明实施例提供了一种权限控制方法，包括：
8.确定当前用户对应的目标资源码，所述目标资源码对应于目标业务功能；
9.确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，所述当前场景为所述当前用户所处的应用场景；
10.在所述第一特征信息与所述通用业务规则匹配的情况下，确定是否存在与所述目标资源码对应的个性化业务规则，得到确定结果；
11.根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
12.可选地，所述通用业务规则对应于至少一个业务资源组；
13.所述确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，包括：
14.确定所述通用业务规则对应的各业务资源组是否均与所述第一特征信息匹配；
15.在各所述业务资源组均与所述第一特征信息匹配的情况下，确定所述第一特征信息与所述通用业务规则匹配。
16.可选地，所述确定所述通用业务规则对应的各业务资源组是否均与所述第一特征信息匹配，包括：
17.确定当前业务资源组，所述当前业务资源组中包括：业务标识、业务值及名单类
型；
18.在所述名单类型对应于白名单的情况下，确定所述第一特征信息中所述业务标识的对应值，确定所述对应值是否与所述业务值匹配；在所述对应值与所述业务值匹配的情况下，确定所述当前业务资源组与所述第一特征信息匹配；
19.在所述名单类型对应于黑名单的情况下，确定所述第一特征信息中所述业务标识的对应值，确定所述对应值是否与所述业务值匹配；在所述对应值与所述业务值不匹配的情况下，确定所述当前业务资源组与所述第一特征信息匹配。
20.可选地，所述根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限，包括：
21.在所述确定结果表征不存在所述个性化业务规则的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
22.在所述确定结果表征存在所述个性化业务规则的情况下，确定所述当前场景对应的第二特征信息与所述个性化业务规则是否匹配，以得到匹配结果；根据所述匹配结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
23.可选地，所述个性化业务规则对应于认证服务；
24.所述确定所述当前场景对应的第二特征信息与所述个性化业务规则是否匹配，以得到匹配结果，包括：
25.确定所述第二特征信息是否通过所述个性规则对应的认证服务的校验，以得到匹配结果；
26.所述根据所述匹配结果，确定所述当前用户是否具有所述目标业务功能的使用权限，包括：
27.在所述匹配结果表征所述第二特征信息通过所述认证服务的校验的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
28.在所述匹配结果表征所述第二特征信息未通过所述认证服务的校验的情况下，确定所述当前用户不具有所述目标业务功能的使用权限。
29.可选地，所述确定当前用户对应的目标资源码，包括：
30.确定所述当前用户对应的目标角色；
31.确定所述目标角色对应的业务资源集合，从所述业务资源集合中确定出所述目标资源码。
32.可选地，所述方法应用于互联网医院应用中；
33.所述确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，包括：
34.获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；
35.从所述互联网医院应用中获取所述通用业务规则，并确定所述第一特征信息与所述通用业务规则是否匹配；
36.所述确定是否存在与所述目标资源码对应的个性化业务规则，包括：
37.确定是否存在来自于第三方系统的所述个性化业务规则，所述第三方系统用于提供所述目标业务功能。
38.可选地，所述方法应用于互联网医院应用中；
39.所述确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，包括：
40.获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；
41.确定所述第一特征信息与所述通用业务规则是否匹配，所述通用业务规则用于确定所述目标业务应用是否为所述目标用户的授权应用；
42.所述确定是否存在与所述目标资源码对应的个性化业务规则，包括：
43.确定是否存在与所述目标资源码对应的个性化业务规则，所述个性化业务规则用于确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用。
44.可选地，所述根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限，包括：
45.在所述确定结果表征存在所述个性化业务规则的情况下，根据所述当前场景对应的第二特征信息及所述个性化业务规则，确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用；
46.在所述目标用户未使用过所述目标业务应用的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
47.在所述目标用户已使用过所述目标业务应用的情况下，确定所述当前用户不具有所述目标业务功能的使用权限。
48.第二方面，本发明实施例提供了一种权限控制装置，包括：
49.资源码确定模块，用于确定当前用户对应的目标资源码，所述目标资源码对应于目标业务功能；
50.规则匹配模块，用于确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，所述当前场景为所述当前用户所处的应用场景；
51.结果确定模块，用于在所述第一特征信息与所述通用业务规则匹配的情况下，确定是否存在与所述目标资源码对应的个性化业务规则，得到确定结果；
52.权限确定模块，用于根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
53.第三方面，本发明实施例提供了一种电子设备，包括：
54.一个或多个处理器；
55.存储装置，用于存储一个或多个程序，
56.当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现上述任一实施例所述的方法。
57.第四方面，本发明实施例提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一实施例所述的方法。
58.上述发明中的一个实施例具有如下优点或有益效果：针对目标业务功能，可设置该目标业务功能对应的通用业务规则，也可设置该目标业务功能对应的通用业务规则及个性化业务规则，并根据当前场景的特征信息与通用业务规则及个性化业务规则的匹配情况，控制当前用户对目标业务功能的使用权限。可以根据不同维度的权限控制逻辑，分别设
置通用业务规则及个性化业务规则，使权限控制维度多样化，以适用于互联网医疗场景下的各种应用场景。
59.此外，本发明实施例提供的权限控制方案具有更好的灵活性，适用范围更广泛。考虑如下三种情形：
60.情形一，通用业务规则及个性化业务规则的来源可能不同。例如：通用业务规则可来自于本地，个性化业务规则可来自于第三方系统。通用业务规则及个性化业务规则也可分别来自于不同的第三方系统等。
61.情形二，可确定出多个业务功能的共用校验逻辑，并将共用校验逻辑封装到通用业务规则中。再确定出各业务功能的个性化校验逻辑，生成该业务功能的个性化业务规则。以细粒度的开发逻辑处理各业务功能的校验规则，减少代码冗余及运维难度。
62.情形三，用户所处的应用场景是会变化的，用户对目标业务功能的使用权限也可能发生变化。可以将场景中固定的特征信息的校验逻辑封装到通用业务规则中，再将可能变动的特征信息的校验逻辑封装到个性化业务规则中，使得能够根据应用场景的当前特征信息，准确确定出用户的当前权限。
63.应用现有技术中的“用户-角色-权限”的授权模型，是无法灵活地实现上述三种情形中的权限控制的。因此，本发明实施例的方案具有更好的灵活性，适用范围更广泛。
64.上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。
附图说明
65.附图用于更好地理解本发明，不构成对本发明的不当限定。其中：
66.图1是本发明的一个实施例提供的一种权限控制方法的流程的示意图；
67.图2是本发明的一个实施例提供的另一种权限控制方法的流程的示意图；
68.图3是本发明的一个实施例提供的又一种权限控制方法的流程的示意图；
69.图4为本发明实施例提供的一个通用业务规则对应于三个业务资源组的结构示意图；
70.图5为本发明实施例提供的一种个性化业务规则校验的流程示意图；
71.图6是本发明的一个实施例提供的一种权限控制装置的结构示意图；
72.图7是适于用来实现本发明实施例的终端设备或服务器的计算机系统的结构示意图。
具体实施方式
73.以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
74.另外，值得说明的是，本技术对用户及医疗等信息的处理，是在用户、医院等各方知情且同意的情况下进行的，对数据的应用和处理符合相关的法规政策要求。
75.图1是本发明的一个实施例提供的一种权限控制方法的流程的示意图。如图1所
示，该方法包括：
76.步骤101：确定当前用户对应的目标资源码，目标资源码对应于目标业务功能。
77.本发明实施例的方法用于对目标系统中的用户进行权限控制。当前用户为登录目标系统的用户。
78.业务功能为目标系统能够提供的功能。可以为不同的业务功能设置不同的资源码，资源码用于唯一标识业务功能。
79.步骤102：确定当前场景对应的第一特征信息与目标资源码对应的通用业务规则是否匹配，当前场景为当前用户所处的应用场景。
80.当前场景为当前用户在目标系统中所处的应用场景。举例来说，本发明实施例的方案可应用于互联网医院应用中，则目标用户可对应于医生、医助或护士等。当前场景可对应于目标用户操作目标问诊单，当前场景也可对应于目标用户操作患者的病历等。
81.具体地，根据通用业务规则，抽取当前场景对应的第一特征信息。第一特征信息可包括：服务类型、问诊类型、问诊来源、问诊渠道、业务场景、医生科室、医生职业等。
82.通用业务规则为用于对当前场景校验的规则。通用业务规则可通过校验代码、校验规则及校验服务等方式来实现。可调用本地的服务或来自第三方系统的服务来实现通用业务规则的校验。
83.步骤103：在第一特征信息与通用业务规则匹配的情况下，确定是否存在与目标资源码对应的个性化业务规则，得到确定结果。
84.个性化业务规则为用于对当前场景校验的规则。个性化业务规则可通过校验代码、校验规则及校验服务等方式实现。可调用本地的服务或来自第三方系统的服务来实现个性化业务规则的校验。
85.具体地，根据通用业务规则，抽取当前场景对应的第二特征信息。第二特征信息可包括：医生所属机构、问诊单保险标记等。
86.通用业务规则与个性化业务规则都用于对当前场景校验的规则。可根据具体需求，设定通用业务规则与个性化业务规则。例如，通用业务规则与个性化业务规则可用于在不同的维度上限制功能权限。通用业务规则与个性化业务规则可对应于不同的实现方式。通用业务规则与个性化业务规则可对应于不同的来源。通用业务规则与个性化业务规则可以以较细粒度地实现校验规则等。
87.在第一特征信息与通用业务规则匹配的情况下，如果存在与目标资源码对应的个性化业务规则，则需要进一步判断当前场景是否与个性化业务规则相匹配。如果不存在与目标资源码对应的个性化业务规则，则可直接确定当前用户具有目标业务功能的使用权限。
88.在第一特征信息与通用业务规则不匹配的情况下，直接确定当前用户不具有目标业务功能的使用权限。
89.步骤104：根据确定结果，确定当前用户是否具有目标业务功能的使用权限。
90.在本发明实施例中，针对目标业务功能，可设置该目标业务功能对应的通用业务规则，也可设置该目标业务功能对应的通用业务规则及个性化业务规则，并根据当前场景的特征信息与通用业务规则及个性化业务规则的匹配情况，控制当前用户对目标业务功能的使用权限。这种权限控制方案能够灵活地适用于各种应用场景中。考虑如下三种情形：
91.情形一，通用业务规则及个性化业务规则的来源可能不同。例如：通用业务规则可来自于本地，个性化业务规则可来自于第三方系统。通用业务规则及个性化业务规则可分别来自于不同的第三方系统等。
92.情形二，可确定出多个业务功能的共用校验逻辑，并将共用校验逻辑封装到通用业务规则中。再确定出各业务功能的个性化校验逻辑，生成该业务功能的个性化业务规则。以细粒度的开发逻辑处理各业务功能的校验规则，减少代码冗余及运维难度。
93.情形三，用户所处的应用场景是会变化的，用户对目标业务功能的使用权限也可能发生变化。可以将目标业务功能固定的特征信息的校验逻辑封装到通用业务规则中，再将目标业务功能变动的特征信息的校验逻辑封装到个性化业务规则中，使得能够根据应用场景的当前特征信息准确确定出用户的当前权限。
94.举例来说，如果将本发明实施例的方案应用于互联网医院应用中。业务功能包括：开具处方、开检验单、拨打视频等业务等。用户对上述业务功能的使用权限是会发生变化。
95.比如，该问诊单中医生是否已经开具过处方，开过了就不能再开了，这时医生在该问诊单下就不再有开具处方的权限了。再比如问诊单在问诊中状态医生有拨打视频的权限，当在问诊结束后，医生不再具有拨打视频权限。
96.通用业务规则会从问诊类型的维度上限制服务类型、问诊类型等，个性业务校验是因为以上的功能都是有独立的业务模块，提供问诊单维度的校验，根据问诊单当前状态时医生能否使用该功能。
97.综上，应用现有技术中的“用户-角色-权限”的授权模型，是无法灵活地实现上述三种情形中的权限控制的。因此，本发明实施例的方案具有更好的灵活性，适用范围更广泛。
98.图2是本发明的一个实施例提供的另一种权限控制方法的流程的示意图。如图2所示，该方法包括：
99.步骤201：确定当前用户对应的目标资源码，目标资源码对应于目标业务功能。
100.步骤202：确定当前场景对应的第一特征信息与目标资源码对应的通用业务规则是否匹配，当前场景为当前用户所处的应用场景。
101.在第一特征信息与通用业务规则匹配的情况下，执行步骤203。在第一特征信息与通用业务规则不匹配的情况下，执行步骤206。
102.步骤203：确定是否存在与目标资源码对应的个性化业务规则，得到确定结果。
103.在确定结果表征存在个性化业务规则的情况下，执行步骤204。在确定结果表征不存在个性化业务规则的情况下，执行步骤205。
104.步骤204：确定当前场景对应的第二特征信息与个性化业务规则是否匹配，以得到匹配结果。
105.在匹配结果表征第二特征信息与个性化业务规则匹配的情况下，执行步骤205。在匹配结果表征第二特征信息与个性化业务不规则匹配的情况下，执行步骤206。
106.步骤205：确定当前用户具有目标业务功能的使用权限。
107.步骤206：确定当前用户不具有目标业务功能的使用权限。
108.通用业务规则与个性化业务规则都用于对当前场景校验的规则。可根据具体需求，设定通用业务规则与个性化业务规则。例如，通用业务规则与个性化业务规则可用于在
不同的维度上限制功能权限。通用业务规则与个性化业务规则可对应于不同的实现方式。通用业务规则与个性化业务规则可对应于不同的来源等。本发明实施例中，通过构建针对目标资源码的通用业务规则与个性化业务规则，实现针对业务功能的灵活的权限控制。
109.在本发明的一个实施例中，通用业务规则对应于至少一个业务资源组；确定当前场景对应的第一特征信息与目标资源码对应的通用业务规则是否匹配，包括：确定通用业务规则对应的各业务资源组是否均与第一特征信息匹配；在各业务资源组均与第一特征信息匹配的情况下，确定第一特征信息与通用业务规则匹配。
110.可通过如下方式，确定通用业务规则对应的业务资源组是否与第一特征信息匹配：确定当前业务资源组，当前业务资源组中包括：业务标识、业务值及名单类型；在名单类型对应于白名单的情况下，确定第一特征信息中业务标识的对应值，确定对应值是否与业务值匹配；在对应值与业务值匹配的情况下，确定当前业务资源组与第一特征信息匹配；在名单类型对应于黑名单的情况下，确定第一特征信息中业务标识的对应值，确定对应值是否与业务值匹配；在对应值与业务值不匹配的情况下，确定当前业务资源组与第一特征信息匹配。
111.在通用业务规则对应的各业务资源组均与第一特征信息匹配的情况下，才确定第一特征信息与通用业务规则匹配。
112.举例来说，开具处方的资源码对应于三个业务资源组。第一个业务资源组中的业务标识对应于问诊类型；业务值包括：图文问诊、电话问诊；名单类型为白名单。第二个业务资源组中的业务标识对应于业务场景；业务值包括：海外问诊、体检报告解读；名单类型为黑名单。第三个业务资源组中的业务标识对应于医生职业；业务值包括：医生；名单类型为白名单。在问诊类型为图文问诊或电话问诊，业务场景不为海外问诊及体检报告解读，职业为医生的情况下，当前用户通过开具处方的通用业务规则。其它情况下，当前用户均无法通过开具处方的通用业务规则。
113.在本发明的一个实施例中，个性化业务规则对应于认证服务；确定当前场景对应的第二特征信息与个性化业务规则是否匹配，以得到匹配结果，包括：确定第二特征信息是否通过个性规则对应的认证服务的校验，以得到匹配结果；根据匹配结果，确定当前用户是否具有目标业务功能的使用权限，包括：在匹配结果表征第二特征信息通过认证服务的校验的情况下，确定当前用户具有目标业务功能的使用权限；在匹配结果表征第二特征信息未通过认证服务的校验的情况下，确定当前用户不具有目标业务功能的使用权限。
114.个性化业务规则对应的认证服务可来源于目标系统，也可来源于外部的第三方系统。
115.图3是本发明的一个实施例提供的又一种权限控制方法的流程的示意图。如图3所示，该方法包括：
116.步骤301：确定当前用户对应的目标角色。
117.步骤302：确定目标角色对应的业务资源集合，从业务资源集合中确定出目标资源码。
118.步骤303：确定当前场景对应的第一特征信息与目标资源码对应的通用业务规则是否匹配，当前场景为当前用户所处的应用场景。
119.步骤304：在第一特征信息与通用业务规则匹配的情况下，确定是否存在与目标资
源码对应的个性化业务规则，得到确定结果。
120.步骤305：根据确定结果，确定当前用户是否具有目标业务功能的使用权限。
121.在本发明实施例中，可先针对各角色，构建角色对应的业务资源集合。业务资源集合中包括至少一个资源码。业务资源集合为该角色可以使用的业务功能对应的资源码的集合。在从目标角色对应的业务资源集合中确定出目标资源码，进行验证。
122.本发明实施例的方案可应用于互联网医院应用中。在本发明的一个实施例中，所述确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，包括：获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；从所述互联网医院应用中获取所述通用业务规则，并确定所述第一特征信息与所述通用业务规则是否匹配；所述确定是否存在与所述目标资源码对应的个性化业务规则，包括：确定是否存在来自于第三方系统的所述个性化业务规则，所述第三方系统用于提供所述目标业务功能。
123.目标用户对应的目标角色包括：医生、医助或护士等。当前场景对应于目标用户操作目标问诊单。第一特征信息包括以下至少之一：服务类型、问诊类型、问诊来源、问诊渠道、业务场景、医生科室、医生职业。目标业务功能由第三方系统提供。互联网医院应用和第三方系统，都需要对当前场景进行校验。先由互联网医院应用提供的通用业务规则，对当前场景信息进行校验；再由第三方系统提供的个性化业务规则进行校验，对当前场景信息进行校验。
124.在本发明的一个实施例中，所述确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，包括：获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；确定所述第一特征信息与所述通用业务规则是否匹配，所述通用业务规则用于确定所述目标业务应用是否为所述目标用户的授权应用；所述确定是否存在与所述目标资源码对应的个性化业务规则，包括：确定是否存在与所述目标资源码对应的个性化业务规则，所述个性化业务规则用于确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用。
125.在存在个性化业务规则的情况下，根据所述当前场景对应的第二特征信息及所述个性化业务规则，确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用；在所述目标用户未使用过所述目标业务应用的情况下，确定所述当前用户具有所述目标业务功能的使用权限；在所述目标用户已使用过所述目标业务应用的情况下，确定所述当前用户不具有所述目标业务功能的使用权限。
126.第一特征信息可以包括：服务类型、问诊类型、问诊来源、问诊渠道、业务场景、医生科室、医生职业等。通用业务规则，用于确定当前用户是否能够使用目标业务应用。个性化业务规则，用于确定目标用户针对目标问诊单是否已使用过目标业务应用。如果未使用过，则用户针对目标问诊单，具有该业务应用的使用权限；如果已使用过，则用户针对目标问诊单，不具有该业务应用的使用权限。
127.例如，医生针对目标问诊单能够开具处方，个性化业务规则用于确定医生针对该问诊单是否已经开具过处方，如果已开具处方，则该医生不具有开具处方的使用权限了。再比如，医生针对目标问诊单能够拨打视频，个性化业务规则用于确定医生针对该问诊单是否已经拨打过视频，在拨打结束后医生不再有拨打视频的权限。
128.为使本发明实施例的方案便于理解，下面将本发明实施例的方案应用于互联网应用中为示例，进行详细阐述。通用业务规则采用rbca(基于角色的访问控制，role-based access control)的模式来实现，个性化业务规则采用isv(独立软件开发商，independent software vendors)模式来实现。本发明实施例提供了一种基于rbca和isv模式的动态权限系统方案。基于rbca模式完成通用功能校验，实现多维度复杂功能配置化校验。基于isv模式实现可插拔式业务校验，实现动态支持第三方系统功能校验。实现了医生服务端零开发，支持业务功能变更和扩展。降本增效，同时提高系统稳定性和风险预警能力。
129.医生端服务承接各医生业务功能的接入，既能支持医生端功能复杂业务逻辑控制，又能做到医生端服务和前端零开发，支持业务功能的新增和变更。本发明实施例的方案包括如下步骤：
130.步骤s01：业务功能资源编码。对每个业务功能设置唯一的资源码。
131.步骤s02：提取特征信息。医生每次打开问诊单im页时，系统从医生、问诊单等多维度信息中，提取完备的特征信息，判断在问诊单下能为该医生提供哪些功能按钮。
132.步骤s03：特征信息分类。对步骤s02中提取的特征信息进行分类，分为通用特征和业务个性特征。例如，医生职业类型、医生科室信息、问诊单服务类型、问诊单业务类型等，任何一个医生，任何一个问诊单都具备此项特征，即可抽象成通用特征。而医生所属机构、问诊单保险标记等只在特定医生、特定问诊单下才有此项特征，作为业务个性特征。
133.步骤s04：配置资源码对应的通用业务规则。基于pbca模式实现通用业务规则的特征配置化。在本发明实施例中，借鉴rbca的模式，并非只通过医生角色进行权限控制，而是把医生角色在内的一组信息进行逐一校验。具体操作是，基于以上配置产生的资源码和特征值，使每个资源码对应一组配置项。校验一个功能医生能否使用时，即校验一个资源码下，所有配置项能否验证通过。
134.步骤s05：配置资源码对应的个性化业务规则。个性化业务规则采用第三方业务系统校验。从医生和问诊单提取的信息只能满足部分按钮的检验逻辑，像【开具处方】【书写病例】等功能按钮依赖处方系统、病例系统等，需要根据相关业务规则校验在该问诊单下该医生是否可用此功能。
135.步骤s06：对步骤s02中分离出来的业务个性特征，对这部分的校验应用步骤s05中的第三方业务系统校验。
136.步骤s07：个性化业务规则基于isv模式实现，支持第三方系统校验可通过配置实现热插拔部署。具体操作是每个资源码对应一个业务系统配置，校验一个功能医生能否使用时，即发现是否存在对应资源码的第三方系统并调用。
137.步骤s08：各通用业务规则及个性化业务规则的校验风险隔离、自动报警。各项功能权限校验独立进行，互不影响。每个功能校验异常，可自动报警。
138.在步骤s01中，要将每项业务功能抽象成资源码。在通用业务规则配置校验阶段，资源码用在两个方面，第一，根据角色配置业务资源码池，业务资源码池也可被称为业务资源集合。不同的资源码池对应不同的资源码集合。第二，每个资源码对应一组通用业务配置集合。可以由业务抽象成的多个资源码，每个角色使用其中的多种功能不等，使用资源码池划分不同角色的业务资源能力集合。医生角色对应的业务资源码池中可包括：开具处方对应的资源码、开检验单对应的资源码、专家会诊对应的资源码、转诊对应的资源码及结束问
诊对应的资源码等。医助角色对应的业务资源码池中可包括：开具处方对应的资源码、转诊对应的资源码、随访计划对应的资源码及结束问诊对应的资源码等。护士角色对应的业务资源码池中可包括：邀请医生对应的资源码、转诊对应的资源码、健康计划对应的资源码、控糖方案对应的资源码及结束问诊对应的资源码等。
139.资源码池中的各资源码还包括：资源码标识、启动版本号、展示名称、展示区域等信息。资源码标识为功能逻辑全生命周期的唯一标识。展示区域用于控制功能按钮在前端页面中的展示区域。
140.每一个资源码可以配置对应的通用业务规则，每个通用业务规则对应至少一个业务资源组。业务资源组以资源码命名，每组业务资源信息包含业务标识、业务值等信息。
141.图4为本发明实施例提供的一个通用业务规则对应于三个业务资源组的结构示意图。如图4所示，开具处方的资源码对应于三个业务资源组。第一个业务资源组中的业务标识对应于问诊类型；业务值包括：10001图文问诊、20001电话问诊；名单类型为白名单。第二个业务资源组中的业务标识对应于业务场景；业务值包括：s101海外问诊、103体检报告解读；名单类型为黑名单。第三个业务资源组中的业务标识对应于医生职业；业务值包括：001医生；名单类型为白名单。在问诊类型为图文问诊或电话问诊，业务场景不为海外问诊及体检报告解读，职业为医生的情况下，当前用户通过开具处方的通用业务规则。
142.医生权限校验分为两个步骤：一是通用业务规则校验，二是个性化业务规则校验。两个步骤都是可选的。在使用顺序上，由于通用业务规则配置校验是加载本地缓存进行校验的，而个性化业务规则校验需要调用第三方接口，增加一次rpc耗时，所以优先使用通用业务规则进行校验，再使用个性化业务规则进行校验。这样通用业务规则校验不通过，直接返回无该资源码使用权限，无需在调用第三方系统进行个性化业务的校验减少一次rpc(远程过程调用协议，remote procedure call protocol)调用耗时。下面分别对通用业务规则校验及个性化业务规则校验的具体实现原理进行阐述。
143.通用业务规则校验包括如下步骤：
144.步骤s11：根据当前用户身份，加载对应资源码池中的全部资源码。
145.步骤s12：根据第一步获取到的所以资源码，获取所有资源码对应的业务资源组。
146.步骤s13：构建特征信息，并发处理所有资源码，去匹配每一组业务资源信息，只要有一组业务资源不匹配，则停止当前校验，校验不通过。
147.图5为本发明实施例提供的一种个性化业务规则校验的流程示意图。如图5所示，个性化业务规则校验包括如下步骤：
148.步骤s21：根据业务资源授权的结果，获得所有通过业务资源校验的资源码。
149.步骤s22：基于isv模式，由医生端服务提供通用按钮校验接口，不同的第三方业务系统实现此接口，并将实现注册到资源码-服务映射表。
150.步骤s23：根据资源码-服务映射表，获取所有资源码映射的服务。
151.步骤s24：确定当前资源码，确定是否存在当前资源码对应的认证服务。如果存在认证服务，利用该认证服务对当前用户进行校验；如果不存在认证服务，确定当前用户具有该当前资源码对应的业务功能的使用权限。
152.本发明实施例的方案在权限控制精度方面，对每一个功能的每一项业务特征实现精准控制。在开发成本方面，在新增功能时，如果通用配置项可满足功能校验条件，只通过
资源码配置，即可实现新功能下发；如果需要第三方系统个性化校验，只需第三方系统实现医生端服务的按钮校验接口，并注册到资源码-服务映射关系表中，即可完成第三方业务系统对权限校验的支持。在系统维护方面，每个功能资源码的配置信息，和认证服务管理，都是独立实现，风险隔离，一个资源编码对应的业务功能授权或认证服务有异常，不会影响其他业务功能的权限管理。
153.图6是本发明的一个实施例提供的一种权限控制装置的结构示意图。如图6所示，该装置包括：
154.资源码确定模块601，用于确定当前用户对应的目标资源码，所述目标资源码对应于目标业务功能；
155.规则匹配模块602，用于确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，所述当前场景为所述当前用户所处的应用场景；
156.结果确定模块603，用于在所述第一特征信息与所述通用业务规则匹配的情况下，确定是否存在与所述目标资源码对应的个性化业务规则，得到确定结果；
157.权限确定模块604，用于根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
158.可选地，所述通用业务规则对应于至少一个业务资源组；
159.所述规则匹配模块602具体用于：
160.确定所述通用业务规则对应的各业务资源组是否均与所述第一特征信息匹配；
161.在各所述业务资源组均与所述第一特征信息匹配的情况下，确定所述第一特征信息与所述通用业务规则匹配。
162.可选地，所述规则匹配模块602具体用于：
163.确定当前业务资源组，所述当前业务资源组中包括：业务标识、业务值及名单类型；
164.在所述名单类型对应于白名单的情况下，确定所述第一特征信息中所述业务标识的对应值，确定所述对应值是否与所述业务值匹配；在所述对应值与所述业务值匹配的情况下，确定所述当前业务资源组与所述第一特征信息匹配；
165.在所述名单类型对应于黑名单的情况下，确定所述第一特征信息中所述业务标识的对应值，确定所述对应值是否与所述业务值匹配；在所述对应值与所述业务值不匹配的情况下，确定所述当前业务资源组与所述第一特征信息匹配。
166.可选地，所述权限确定模块604具体用于：
167.在所述确定结果表征不存在所述个性化业务规则的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
168.在所述确定结果表征存在所述个性化业务规则的情况下，确定所述当前场景对应的第二特征信息与所述个性化业务规则是否匹配，以得到匹配结果；根据所述匹配结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
169.可选地，所述个性化业务规则对应于认证服务；
170.所述权限确定模块604具体用于：
171.确定所述第二特征信息是否通过所述个性规则对应的认证服务的校验，以得到匹配结果；
172.所述权限确定模块604具体用于：
173.在所述匹配结果表征所述第二特征信息通过所述认证服务的校验的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
174.在所述匹配结果表征所述第二特征信息未通过所述认证服务的校验的情况下，确定所述当前用户不具有所述目标业务功能的使用权限。
175.可选地，所述资源码确定模块601具体用于：
176.确定所述当前用户对应的目标角色；
177.确定所述目标角色对应的业务资源集合，从所述业务资源集合中确定出所述目标资源码。
178.可选地，所述方法应用于互联网医院应用中；所述目标用户对应的目标角色包括：医生、医助或护士；
179.所述规则匹配模块602具体用于：
180.获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；
181.从所述互联网医院应用中获取所述通用业务规则，并确定所述第一特征信息与所述通用业务规则是否匹配；
182.所述结果确定模块603具体用于：
183.确定是否存在来自于第三方系统的所述个性化业务规则，所述第三方系统用于提供所述目标业务功能。
184.可选地，所述方法应用于互联网医院应用中；
185.所述规则匹配模块602具体用于：
186.获取所述当前场景对应的第一特征信息，所述当前场景对应于所述目标用户操作目标问诊单；
187.确定所述第一特征信息与所述通用业务规则是否匹配，所述通用业务规则用于确定所述目标业务应用是否为所述目标用户的授权应用；
188.所述结果确定模块603具体用于：
189.确定是否存在与所述目标资源码对应的个性化业务规则，所述个性化业务规则用于确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用。
190.可选地，所述权限确定模块604具体用于：
191.在所述确定结果表征存在所述个性化业务规则的情况下，根据所述当前场景对应的第二特征信息及所述个性化业务规则，确定所述目标用户针对所述目标问诊单是否已使用过所述目标业务应用；
192.在所述目标用户未使用过所述目标业务应用的情况下，确定所述当前用户具有所述目标业务功能的使用权限；
193.在所述目标用户已使用过所述目标业务应用的情况下，确定所述当前用户不具有所述目标业务功能的使用权限。
194.本发明实施例提供了一种电子设备，包括：
195.一个或多个处理器；
196.存储装置，用于存储一个或多个程序，
197.当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现上述任一实施例的方法。
198.下面参考图7，其示出了适于用来实现本发明实施例的终端设备的计算机系统700的结构示意图。图7示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
199.如图7所示，计算机系统700包括中央处理单元(cpu)701，其可以根据存储在只读存储器(rom)702中的程序或者从存储部分708加载到随机访问存储器(ram)703中的程序而执行各种适当的动作和处理。在ram 703中，还存储有系统700操作所需的各种程序和数据。cpu 701、rom 702以及ram 703通过总线704彼此相连。输入/输出(i/o)接口705也连接至总线704。
200.以下部件连接至i/o接口705：包括键盘、鼠标等的输入部分706；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分707；包括硬盘等的存储部分708；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分709。通信部分709经由诸如因特网的网络执行通信处理。驱动器710也根据需要连接至i/o接口705。可拆卸介质711，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器710上，以便于从其上读出的计算机程序根据需要被安装入存储部分708。
201.特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分709从网络上被下载和安装，和/或从可拆卸介质711被安装。在该计算机程序被中央处理单元(cpu)701执行时，执行本发明的系统中限定的上述功能。
202.需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
203.附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代
表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
204.描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：资源码确定模块、规则匹配模块、结果确定模块及权限确定模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，资源码确定模块还可以被描述为“确定当前用户对应的目标资源码，所述目标资源码对应于目标业务功能的模块”。
205.作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：
206.确定当前用户对应的目标资源码，所述目标资源码对应于目标业务功能；
207.确定当前场景对应的第一特征信息与所述目标资源码对应的通用业务规则是否匹配，所述当前场景为所述当前用户所处的应用场景；
208.在所述第一特征信息与所述通用业务规则匹配的情况下，确定是否存在与所述目标资源码对应的个性化业务规则，得到确定结果；
209.根据所述确定结果，确定所述当前用户是否具有所述目标业务功能的使用权限。
210.根据本发明实施例的技术方案，针对目标业务功能，可设置该目标业务功能对应的通用业务规则，也可设置该目标业务功能对应的通用业务规则及个性化业务规则，并根据当前场景的特征信息与通用业务规则及个性化业务规则的匹配情况，控制当前用户对目标业务功能的使用权限。可以根据不同维度的权限控制逻辑，分别设置通用业务规则及个性化业务规则，使权限控制维度多样化，以适用于互联网医疗场景下的各种应用场景。本发明实施例的方案具有更好的灵活性，适用范围更广泛。
211.上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。