一种信息推荐方法、装置、设备及存储介质与流程

1.本技术实施例涉及数据处理技术领域，具体涉及一种信息推荐方法、装置、设备及存储介质。


背景技术：

2.针对不同患者的病情信息，通常需要由医生逐一为各个患者制定适合的治疗方案，并进行计算机系统录入，极大增加了医生工作量，重复的录入工作也占用医生较多时间。而且，相同病情通常会存在相似的处理逻辑。因此，为了提高医生的工作效率，通常会利用信息技术向医生推荐多个较为符合要求的处理指示信息，来辅助医生高效制定实际的治疗指令。
3.目前，对于不同地方、不同专业的医生，通常均会借助已有的基础医学知识库中对于同一病情的相关医学记载，来为同一病情推荐相同的处理逻辑，使得信息推荐存在一定的局限性，无法保证信息推荐的自适应性和精准性。


技术实现要素：

4.本技术提供一种信息推荐方法、装置、设备及存储介质，实现业务执行信息在不同分组下的自适应推荐，提高业务执行信息的推荐准确性和分组适配性。
5.第一方面，本技术实施例提供了一种信息推荐方法，该方法包括：
6.获取用户的分组业务特征；
7.将所述分组业务特征输入到训练好的目标模型中，得到待推荐的业务执行信息；
8.其中，所述目标模型为训练好的状态统计模型和深度预测模型中的其中一个。
9.第二方面，本技术实施例提供了一种信息推荐装置，该装置包括：
10.特征获取模块，用于获取用户的分组业务特征；
11.信息推荐模块，用于将所述分组业务特征输入到训练好的目标模型中，得到待推荐的业务执行信息；
12.其中，所述目标模型为训练好的状态统计模型和深度预测模型中的其中一个。
13.第三方面，本技术实施例提供了一种电子设备，该电子设备包括：
14.处理器和存储器，所述存储器用于存储计算机程序，所述处理器用于调用并运行所述存储器中存储的计算机程序，以执行本技术第一方面中提供的信息推荐方法。
15.第四方面，本技术实施例提供了一种计算机可读存储介质，用于存储计算机程序，所述计算机程序使得计算机执行如本技术第一方面中提供的信息推荐方法。
16.第五方面，本技术实施例提供了一种计算机程序产品，包括计算机程序/指令，其特征在于，该计算机程序/指令被处理器执行时实现如本技术第一方面中提供的信息推荐方法。
17.本技术实施例提供的一种信息推荐方法、装置、设备及存储介质，通过将用户的分组业务特征输入到训练好的状态统计模型和深度预测模型中的其中一个目标模型中，即可
得到待推荐的业务执行信息，从而实现业务执行信息在不同分组下的自适应推荐，保证业务执行信息在不同分组推荐下的适配性，提高业务执行信息的推荐准确性。
附图说明
18.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
19.图1为本技术实施例示出的一种信息推荐的方法的流程图；
20.图2为本技术实施例示出的信息推荐过程的原理示意图；
21.图3为本技术实施例示出的状态统计模型训练过程的方法流程图；
22.图4为本技术实施例示出的深度预测模型训练过程的方法流程图；
23.图5为本技术实施例示出的一种信息推荐装置的原理框图；
24.图6是本技术实施例示出的电子设备的示意性框图。
具体实施方式
25.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本技术保护的范围。
26.需要说明的是，本技术的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本技术的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
27.考虑到借助已有的基础知识库，对不同分组下的业务会推荐相同的处理逻辑，使得信息推荐存在一定的局限性的问题，本技术设计了一种新的信息推荐方案。本技术会预先训练好状态统计模型和深度预测模型这两种类型的模型。然后，可以通过状态统计模型和深度预测模型中的其中一个目标模型，来分析用户在不同分组下的业务特征，即可得到带推荐的业务执行信息，从而实现业务执行信息在不同分组下的自适应推荐。
28.图1为本技术实施例示出的一种信息推荐的方法的流程图。参照图1，该方法具体可以包括如下步骤：
29.s110，获取用户的分组业务特征。
30.应当理解的是，对于同一类型的业务，支持用户在不同平台、或者同一平台的不同组织架构来进行处理。例如、对于患者网上的挂号预约看病业务，支持患者选择不同医院内不同科室中的不同医生进行挂号预约；或者，对于用户存储开户业务，支持用户选择不同银行、不同柜台的营业员进行办理。
31.那么，考虑到不同平台或者同一平台的不同组织架构对于同一类型业务的处理习惯不同，可能导致该业务存在不同的处理流程。因此，为了保证业务处理的准确性，本技术会为用户可处理业务设定不同的分组。在每次接收到用户对于某一业务的处理请求时，首先会判断用户指定的用于处理该业务的业务平台、该平台下的具体某一组织架构和具体管理员等，以此确定对应的分组。
32.其中，用户的分组业务特征可以为用户处理某一业务时所在的具体分组，如用于处理该业务的业务平台、该平台下的具体某一组织架构和具体管理员等，以及在该分组下用户对于该业务的历史执行信息，如在前一阶段的业务执行结果等。
33.需要说明的是，通过获取用户处理某一业务时录入的业务属性信息，即可确定用户指定的用于处理该业务的业务平台、该平台下的具体某一组织架构和具体管理员等。其中，该业务属性信息可以由用户自身录入，也可以由用户指定的管理员录入，对此不作限定。
34.本技术的业务属性信息可以为用户处理某一业务时的业务所属类别和业务已执行阶段等各项业务处理信息，以便于确定用户的分组业务特征。
35.而且，所录入的业务属性信息中还会记录用户对于该业务的当前处理阶段、现阶段状态和前期处理情况等。
36.示例性的，在患者或就诊者在某一科室进行诊疗活动时，可以由该科室内医生在相关诊疗系统上登录对应的科室页面，并录入该患者或就诊者的现阶段病情状态、是否已接受过前期治疗、前期治疗结果等。
37.然后，通过分析用户对于该业务已录入的业务属性信息，来提取出用户的分组业务特征。
38.其中，本技术中的用户为在业务平台内已记录有自身的业务属性信息的人员，与业务平台的操作人员不同，操作人员可以通过在业务平台执行对应的业务操作来查询各个用户的业务属性信息。
39.s120，将分组业务特征输入到训练好的目标模型中，得到待推荐的业务执行信息，目标模型为训练好的状态统计模型和深度预测模型中的其中一个。
40.作为本技术中的一种可选实现方案，考虑到用户对于任一类型的业务，为了保证业务处理的全面准确性，通常会需要提前对该业务进行一系列的特征检验，以便在表面化的初步业务特征基础上，进一步挖掘出一些深度化的业务特征，来更为准确的分析业务的处理流程。然而，对于深度化的业务特征而言，需要经过一段时间才能准确挖掘出结果。因此，本技术中任一类型业务的处理就会包括在深度化的业务特征成功挖掘前后的两个阶段下对应的两种不同处理场景。
41.那么，对于每一种处理场景，均会按照用户在该处理场景已有的历史分组业务特征，来训练出对应的网络模型。在本技术中，会训练好状态统计模型和深度预测模型这两种网络模型来分别适应上述两种处理场景下对于业务执行信息的推荐。
42.考虑到任一业务的整体处理流程可能会包含多个处理阶段，而不同的处理阶段需要执行不同的业务操作。所以，本技术中的业务执行信息可以为在完成当前阶段的业务处理后，向用户推荐的在下一处理阶段所需要执行的各项业务操作信息。
43.其中，本技术中的状态统计模型可以为隐马尔科夫模型(hidden markov model，
简称为hmm)，通过分析业务在不同状态阶段下的处理转移，来确定对应的业务执行信息。深度预测模型可以为采用深度学习算法，利用样本标签和损失函数等训练的网络模型。
44.在本技术中，可以将用户的分组业务特征输入到状态统计模型和深度预测模型这两种网络模型中的其中一个目标模型中，以通过该目标模型内的模型参数和模型结构对该分组业务特征进行相关处理流程的分析，从而得到待推荐的业务执行信息。然后，向用户推荐该业务执行信息，来指示用户对于该业务的后续处理流程。
45.需要说明的是，本技术中目标模型输出的业务执行信息并不唯一，可以包括多个。而且，目标模型可以输出每一业务执行信息的可用概率。然后，在向用户推荐各个业务执行信息时，可以按照可用概率高低来对业务执行信息进行排序，并展示在用户系统内对应的推荐结果栏中，以此辅助用户从所推荐的各个业务执行信息中选用一个适合的业务执行信息，来执行后续的业务处理流程。
46.示例性的，如果用户的分组业务特征为用户在某一医院科室，由某一医生录入的病情诊断信息，那么待推荐的业务执行信息可以为用户病情适合的各个医嘱信息。
47.在一些可实现方式中，如图2所示，考虑到本技术中的状态统计模型和深度预测模型是针对深度化的业务特征是否能够成功挖掘所对应的两种不同处理场景而构建的，也就是状态统计模型和深度预测模型的训练主要在于是否对业务进行一系列的特征检验而挖掘出深度化的业务特征。
48.因此，本技术可以根据分组业务特征中的业务检验特征，从训练好的状态统计模型和深度预测模型中，确定对应的目标模型；将分组业务特征输入到目标模型中，得到待推荐的业务执行信息。其中，业务检验特征为对业务进行一系列额外的特征检验操作，如某一病种下特有的疾病检验项目等，而挖掘出的深度化业务特征。
49.如果分组业务特征中包括业务检验特征，说明需要由利用历史业务检验特征所训练的深度预测模型来分析待推荐的业务执行信息，那么目标模型为深度预测模型，以保证业务执行信息的推荐准确性。如果分组业务特征中不包括业务检验特征，说明需要由利用不同状态转移的业务特征所训练的深度预测模型来分析待推荐的业务执行信息，那么目标模型为状态统计模型，以保证业务执行信息的推荐准确性。
50.此外，考虑到用户执行相应业务时，由于用户自身属性可能会与某一业务操作存在一定对抗性，而导致无法成功执行此类业务操作。因此，对于待推荐的业务执行信息，本技术还可以进一步分析用户的业务抗性特征，以判断出用户无法成功执行的业务操作。进而，在向用户推荐各个业务执行信息时，可以在待推荐的业务执行信息中添加对应的抗性指示信息，该抗性指示信息可以包括与用户自身属性存在对抗性而导致无法成功执行的业务操作。或者，可以按照该抗性指示信息，直接从待推荐的业务执行信息中删除用户无法成功执行的业务操作，然后将剩余的业务执行信息推荐给用户，以保证业务执行信息的成功性。
51.本技术实施例提供的技术方案，通过将用户的分组业务特征输入到训练好的状态统计模型和深度预测模型中的其中一个目标模型中，即可得到待推荐的业务执行信息，从而实现业务执行信息在不同分组下的自适应推荐，保证业务执行信息在不同分组推荐下的适配性，提高业务执行信息的推荐准确性。
52.根据本技术的一个或多个实施例，在通过状态统计模型和深度预测模型中的其中
一个目标模型确定待推荐的业务执行信息之前，首先需要对状态统计模型和深度预测模型进行训练，以确保业务执行信息的推荐准确性。
53.接下来，本技术分别对状态统计模型和深度预测模型的具体训练过程进行详细的说明。
54.图3为本技术实施例示出的状态统计模型训练过程的方法流程图。如图3所示，该方法具体可以包括如下步骤：
55.s310，获取每一分组下的历史业务执行信息和已维护的业务执行组合，以生成该分组下的业务执行序列。
56.由于状态统计模型主要是根据业务在不同状态阶段下的处理流程和业务状态，来判断业务执行信息在不同状态阶段下的具体转移情况，以此判断当前阶段的业务执行信息。所以，状态统计模型的训练首先需要判断大量已完成的业务在不同状态阶段下的业务执行信息，以此作为对应的训练样本。
57.因此，本技术首先会在业务系统中提取大量业务执行情况的业务数据。然后，对该业务数据进行业务处理流程下的分析整理，即可得到表示同一类型业务的整个处理流程的业务执行信息。进而，按照业务执行对象对所提取出的大量业务执行信息进行分组，得到每一分组下对于同一类型业务的业务执行信息。例如，同一医院科室下同一病种的医嘱信息。
58.应当理解的是，对于特定的业务，可能更倾向于采用一套相对固定的业务操作组合来同步执行对应的业务处理流程，以便通过组合后的多种业务操作来综合判断业务处理的准确性。
59.所以，对于常用的业务操作组合，会由业务管理员根据业务执行习惯来提前维护好，也就是本技术中的业务执行组合。
60.对于同一类型业务的处理流程，所执行的各个业务执行信息(也就是业务操作)之间会存在一定的执行顺序。因此，在获取到每一分组下的历史业务执行信息和已维护的业务执行组合之后，本技术可以按照该分组下的具体业务处理流程中的具体执行顺序，对同一分组下的各个历史业务执行信息和业务执行组合进行排序，从而生成该分组下的业务执行序列。其中，该业务执行序列即可包括该分组下的业务在不同状态阶段下的业务执行情况。
61.在一些可实现方式中，本技术的历史业务执行信息中可能会存在隐含的业务执行组合。通过分析每一分组下的历史业务执行信息中频繁同时出现的各个业务操作，即可从该分组下的历史业务执行信息中，挖掘出对应的历史业务执行组合。然后，合并上述获取的历史业务执行组合和已维护的业务执行组合，即可得到同一分组下业务涉及的全部业务执行组合。进而，按照该分组下业务处理流程中的业务执行顺序，对上述全部的业务执行组合进行排序，即可生成对应的业务执行序列。
62.需要说明的是，本技术中的业务执行组合之间存在一定的执行顺序关系，而业务执行组合内部的各个业务执行信息之间不存在顺序关系。
63.应当理解的是，对于每一分组下的历史业务执行信息中的历史业务执行组合，本技术可以采用频繁模式增长(frequent-pattern growth，简称为fp-growth)算法来对历史业务执行信息中频繁同时出现的各个频繁项集进行挖掘，以得到对应的历史业务执行组合。其中，具体挖掘步骤可以包括：根据每一分组下的历史业务执行信息，构建对应的频繁
模式树；根据频繁模式树中频繁项集内的连续子集，确定对应的历史业务执行组合。
64.也就是说，首先统计每一分组下的各个历史业务执行信息在历史处理流程中出现的次数，以计算各个历史业务执行信息的支持度。然后，按照该支持度，对各个历史业务执行信息进行递减排序。进而，按照各个历史业务执行信息的递减顺序，构建fp-growth算法对应的项头表、fp树结构和节点链表。将递减排序的各个历史业务执行信息映射到对应的fp树结构中，得到本技术中的频繁模式树。其中，频繁模式树中的节点即为各个历史业务执行信息中的频繁项集。最后，可以从该频繁模式树中的各个节点信息中，识别出对应的频繁项集。
65.此时，考虑到频繁模式树中的频繁项集不一定是连续频繁的业务执行子集，所以本技术会对各个频繁项集内各个业务执行信息之间的连续性进行判断，以从频繁项集中筛选出频繁出现的连续子集。然后，将各个连续子集内的各个历史业务执行信息，作为对应的历史业务执行组合。后续，将每一分组下的历史业务执行组合和已维护的业务执行组合进行合并，即可该分组下全部的业务执行序列。
66.s320，将每一分组下的业务执行序列作为观测状态序列，训练状态统计模型。
67.本技术中任一业务执行序列可以包括一个业务在整个处理流程的不同状态阶段下的业务执行信息。因此，可以将每一分组下的业务执行序列作为对应的观测状态序列，然后将潜在的业务执行状态视为隐藏状态。业务执行信息主要由业务不同阶段的执行状态来决定，而业务执行状态会遵循一定的规律进行状态转移。
68.所以，在利用每一分组下的业务执行序列给定对应的观测状态序列后，本技术可以采用鲍姆-韦尔奇(baum
–
welch)算法来求解状态统计模型的模型参数，以获得状态统计模型的最优估计，即可训练出最优的状态统计模型。
69.图4为本技术实施例示出的深度预测模型训练过程的方法流程图。如图4所示，该方法具体可以包括如下步骤：
70.s410，从每一分组下的历史业务执行信息中，选取对应的目标业务执行信息。
71.其中，目标业务执行信息按照用户的业务检验特征确定。
72.对于每一分组下的历史业务执行信息，为了保证业务处理的全面准确性，可能会提前对某些业务进行一系列的特征检验，以便在表面化的初步业务特征基础上，进一步挖掘出一些深度化的业务特征，来更为准确的分析业务的处理流程。所以，每一分组下的部分历史业务执行信息中可能会存在相应的业务检验特征。而业务检验特征会直接影响到业务执行信息的准确性。
73.因此，对于每一分组下的各个历史业务执行信息，本技术首先会判断在确定历史业务执行信息时参考的分组业务特征中是否包括业务检验特征，也就是判断在确定历史业务执行信息时，是否对业务执行了相应的检验项目。然后，从每一分组下的各个历史业务执行信息中，选取出由包括业务检验特征的分组业务特征所确定的部分历史业务执行信息，作为本技术中的目标业务执行信息。
74.s420，根据目标业务执行信息和对应的业务检验特征，训练深度预测模型。
75.在模型训练过程中，可以将目标业务执行信息作为样本标签，而将确定该目标业务执行信息时所参考的分组业务特征中的业务检验特征作为对应的训练样本。利用上述训练样本和样本标签，采用深度学习算法来不断训练深度预测模型，直至深度预测模型的输
出达到收敛，即可得到训练好的深度预测模型。
76.本技术实施例提供的技术方案，采用不同算法，在不同业务处理场景下训练不同的模型，通过状态统计模型和深度预测模型来分析不同场景下的分组业务特征，得到待推荐的业务执行信息，保证业务执行信息在不同分组下的自适应推荐，提高业务执行信息的推荐准确性。
77.以下结合医院内不同科室下的不同医生向某一患者推荐相应医嘱的场景，对本技术中的信息推荐方案进行说明：
78.为了对各个患者的就医诊疗情况进行记录，每一医院通常会开发一个记录有各个患者就医信息的医疗业务信息系统。该医疗业务信息系统会按照科室和病种划分出不同的分组。
79.在训练本技术中的状态统计模型和深度预测模型时，首先会遍历医疗业务信息系统内的每一科室相关的医嘱开立数据。而且，在每一科室的遍历过程中，会进一步深入遍历该科室下的每一病种相关的医嘱开立数据。进而，以此作为状态统计模型和深度预测模型的训练样本。
80.针对特定的病种，医生倾向于开立一套相对固定的医嘱组合。例如，对于急性淋巴细胞白血病，医生通常首先会开立一套血常规、生化常规、凝血五项的检验项目，用于观测患者的指标情况。这些医嘱组合经常被一起开立，可以作为一个整体在医生开立的医嘱模式中被识别。医嘱组合内的医嘱顺序是随意的，但医嘱组合和其他医嘱间的开立顺序是有意义的。也就是说，医生为急性淋巴细胞白血病患者开立的血常规、生化常规、凝血五项这三项检验的医嘱前后顺序是可以互相调换的。但之后医生为患者继续开立的化疗类医嘱，就一定是在检验类医嘱的后面。也就是说，医嘱组合之间是有一个顺序关系，组合内部是没有顺序关系。
81.所说义，医嘱组合可以作为本技术中状态统计模型和深度预测模型的训练样本。
82.应当理解的时，识别医嘱组合主要有以下两个来源：
83.1)医生面向每一病种主动维护的个人医嘱组合。医生会把经常使用的医嘱组合提前维护成组套保存起来，这些组套代表了医生的医嘱开立习惯。
84.2)在任一病种的医嘱开立数据中，频繁同时出现的医嘱子集。
85.所以，在每一科室的每一病种下的相关医嘱开立数据中，通过提取本科室范围内面向每一病种而创建的科室和个人组套，即可获得医生自己维护的常用医嘱组合，也就是本技术中已维护的业务执行组合。
86.而且，对于每一病种下还未维护的常用医嘱组合，可以通过对每一科室的每一病种下的相关医嘱开立数据进行统计分析，得到在每一科室的每一病种下已开立的每一条医嘱，作为本技术中每一分组下的历史业务执行信息。
87.根据每一课时的每一病种下的疾病治疗顺序，可以对从上述两个来源下获得的每一病种下已维护的医嘱组合和已开立的每一条医嘱进行排序，得到对应的医嘱序列，也就是本技术中的业务执行序列。
88.对于状态统计模型的训练，本技术可以使用频繁项集挖掘算法(也就是fp-growth算法)，来对在每一科室的每一病种下已开立的每一条医嘱进行挖掘，以提取出医嘱序列中的频繁项集。
89.示例性的，首先统计每一科室的每一病种下的每一条医嘱在在该病种诊疗过程中出现的次数，以计算每一条医嘱的支持度。然后，按照该支持度，对每一条医嘱进行递减排序。进而，按照各个医嘱的递减顺序，构建fp-growth算法对应的项头表、fp树结构和节点链表。将递减排序的每一条医嘱映射到对应的fp树结构中，得到本技术中的频繁模式树。其中，频繁模式树中的节点即为医嘱序列中的频繁项集。最后，可以从该频繁模式树中的各个节点信息中，识别出对应的频繁项集。在此场景下，以一次就诊的医嘱序列为一条记录，一个医嘱为一个项集，通过此算法识别医嘱开立数据中的频繁出现的医嘱组合。
90.在识别出每一病种下常用的医嘱组合后，由于通过fp-growth算法识别出的频繁项集不一定是连续频繁的子集。所以，本技术需要再遍历一遍频繁项集中的每一条医嘱数据，来对各个频繁项集内每一条医嘱之间的连续性进行判断，从而筛选出频繁的连续子集，以构成对应的医嘱组合。而且，未被识别进医嘱组合内的单条医嘱，就以自己单独一条医嘱为单位进行训练。
91.进而，将每一科室的每一病种下识别出的频繁同时出现的医嘱组合和已维护的医嘱组合进行对应的病种诊疗排序，得到该病种下的医嘱组合序列。
92.在模型训练过程中，可以使用hmm模型来模拟医嘱开立的情景。将上述获得的医嘱组合序列作为对应的观测状态序列，而潜在的患者状况或治疗方案的概念视为隐藏状态。开立的医嘱由患者状况或治疗方案决定，而治疗方案遵循一定的规律进行转移，从而通过历史的医嘱组合序列来训练hmm模型。当给定观测状态序列为每一科室的每一病种下获得的医嘱组合序列时，用baum-welch算法即可对hmm模型的参数进行求解，从而获得模型的最优估计，即可训练出最优的状态统计模型。
93.对于深度预测模型的训练，在每一科室的每一病种下，由于医生之前开立的检验项目报告出来之后，主要会根据检验项目指标的结果来决定相应的治疗方案。这种情况下检验项目指标的数值会直接影响医嘱开立的内容。
94.所以，针对在每一科室的每一病种下已开立的每一条医嘱，首先判断每一条医嘱中是否包含有该病种下已开立的相关检验项目的结果报告，以选取出包含有相关检验项目报告的目标医嘱。
95.然后，将使用检验项目报告指标(x)和出检验结果报告之后的目标医嘱(y)来训练深度预测模型。也就是，使用每一科室的每一病种下的相关分组的所有患者历史检验报告数据，遍历每一个检验项目，提取各个指标的检验项目报告中的结果数值作为样本输入。而且，按照检验出报告时间查询此时间后医生为患者开立的第一套医嘱，作为样本标签。因为不同的医嘱之间没有数值关系，所以医嘱标签结果的表示采用one-hot编码的形式。然后，将上述获得的样本输入和样本标签放入深度神经网络模型中进行训练，得到本技术中的深度预测模型。
96.在训练好状态统计模型和深度预测模型后，在某一科室下的医生为任一患者开立相应的医嘱时，医生首先会在医疗业务信息系统中登录患者本次看诊的科室，并为患者录入相应的诊断信息。当为该患者开立第一条医嘱时，使用上述训练好的状态统计模型，来对此科室此类诊断的初始医嘱推荐分布进行预测。并按照所预测医嘱的概率高低排序，向医生推荐对应的医嘱信息，作为该患者第一条医嘱的推荐预测。对于非第一条医嘱的情况，当没有检验报告结果的时候，继续使用上述训练好的状态统计模型来预测医嘱的转移情况，
得到待推荐的医嘱信息。若有检验报告的结果，则选择此检验项目对应训练的深度预测模型，输入该患者本次检验项目报告中的各个指标结果，来判断不同种类医嘱的可能性，得到待推荐的医嘱信息。
97.针对每一患者的诊断信息，医疗业务信息系统中向医生为该患者推荐的医嘱结果并不唯一，而是按照相关模型给出可能出现的医嘱概率由高到低进行排序，默认将推荐的各套医嘱信息展示在医生开立医嘱的下方搜索结果栏中。另外，如果此患者还有录入的过敏史，则需再对患者的过敏史进行校验。如果推荐的医嘱中有患者过敏的药物，则从推荐中删除。
98.图5为本技术实施例示出的一种信息推荐装置的原理框图。如图5所示，该装置500可以包括：
99.特征获取模块510，用于获取用户的分组业务特征；
100.信息推荐模块520，用于将所述分组业务特征输入到训练好的目标模型中，得到待推荐的业务执行信息；
101.其中，所述目标模型为训练好的状态统计模型和深度预测模型中的其中一个。
102.在一些可实现方式中，信息推荐模块520，可以具体用于：
103.根据所述分组业务特征中的业务检验特征，从训练好的状态统计模型和深度预测模型中，确定对应的目标模型；
104.将所述分组业务特征输入到所述目标模型中，得到待推荐的业务执行信息。
105.在一些可实现方式中，如果所述分组业务特征包括业务检验特征，那么所述目标模型为深度预测模型；
106.如果所述分组业务特征不包括业务检验特征，那么所述目标模型为状态统计模型。
107.在一些可实现方式中，信息推荐装置500，还可以包括：
108.第一模型训练模块，用于获取每一分组下的历史业务执行信息和已维护的业务执行组合，以生成该分组下的业务执行序列；将每一分组下的业务执行序列作为观测状态序列，训练所述状态统计模型；
109.第二模型训练模块，用于从每一分组下的历史业务执行信息中，选取对应的目标业务执行信息，所述目标业务执行信息按照用户的业务检验特征确定；根据所述目标业务执行信息和对应的业务检验特征，训练所述深度预测模型。
110.在一些可实现方式中，第一模型训练模块，可以包括：
111.业务挖掘单元，用于从每一分组下的历史业务执行信息中，挖掘对应的历史业务执行组合；
112.执行序列生成单元，用于合并所述历史业务执行组合和已维护的业务执行组合，并按照业务执行顺序，生成对应的业务执行序列。
113.在一些可实现方式中，业务挖掘单元，可以具体用于：
114.根据每一分组下的历史业务执行信息，构建对应的频繁模式树，所述频繁模式树中的节点为所述历史业务执行信息中的频繁项集；
115.根据所述频繁模式树中频繁项集内的连续子集，确定对应的历史业务执行组合。
116.在一些可实现方式中，信息推荐装置500，还可以包括：
117.抗性指示模块，用于根据所述用户的业务抗性特征，在所述业务执行信息中添加对应的抗性指示信息。
118.本技术实施例中，通过将用户的分组业务特征输入到训练好的状态统计模型和深度预测模型中的其中一个目标模型中，即可得到待推荐的业务执行信息，从而实现业务执行信息在不同分组下的自适应推荐，保证业务执行信息在不同分组推荐下的适配性，提高业务执行信息的推荐准确性。
119.应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图5所示的装置500可以执行本技术提供的任一方法实施例，并且装置500中的各个模块的前述和其它操作和/或功能分别为了实现本技术实施例的各个方法中的相应流程，为了简洁，在此不再赘述。
120.上文中结合附图从功能模块的角度描述了本技术实施例的装置500。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本技术实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本技术实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。
121.图6是本技术实施例示出的电子设备的示意性框图。
122.如图6所示，该电子设备600可包括：
123.存储器610和处理器620，该存储器610用于存储计算机程序，并将该程序代码传输给该处理器620。换言之，该处理器620可以从存储器610中调用并运行计算机程序，以实现本技术实施例中的方法。
124.例如，该处理器620可用于根据该计算机程序中的指令执行上述方法实施例。
125.在本技术的一些实施例中，该处理器620可以包括但不限于：
126.通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。
127.在本技术的一些实施例中，该存储器610包括但不限于：
128.易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器(read-only memory，rom)、可编程只读存储器(programmable rom，prom)、可擦除可编程只读存储器(erasable prom，eprom)、电可擦除可编程只读存储器(electrically eprom，eeprom)或闪存。易失性存储器可以是随机存取存储器(random access memory，ram)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的ram可用，例如静态随机存取存储器(static ram，sram)、动态随机存取存储器(dynamic ram，dram)、同步动态随机存取存储器(synchronous dram，sdram)、双倍数据速率同步动态随机存取存储器(double data rate sdram，ddr sdram)、增强型同步动态随机存取存储器(enhanced sdram，esdram)、同步连接动态随机存取存储器(synch link dram，sldram)和直接内存总线随机存取存储器
(direct rambus ram，dr ram)。
129.在本技术的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器610中，并由该处理器620执行，以完成本技术提供的方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该电子设备中的执行过程。
130.如图6所示，该电子设备还可包括：
131.收发器630，该收发器630可连接至该处理器620或存储器610。
132.其中，处理器620可以控制该收发器630与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器630可以包括发射机和接收机。收发器630还可以进一步包括天线，天线的数量可以为一个或多个。
133.应当理解，该电子设备中的各个组件通过总线系统相连，其中，总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。
134.本技术实施例还提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本技术实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。
135.当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本技术实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，dvd))、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
136.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
137.在本技术所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
138.作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本技术各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。
139.以上，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以该权利要求的保护范围为准。