一种基于物联网的智慧城市医疗保险数据评估方法和系统

摘要

本说明书实施例提供一种基于物联网的智慧城市医疗保险数据评估方法和系统，该方法由医疗管理平台执行，包括：基于服务平台通过用户平台获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估；基于人口信息平台获取评估对象的关联人；基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征；基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征；基于目标医疗特征和目标投保特征，确定参保风险的评估值；以及基于服务平台通过用户平台将评估值反馈给用户。

说明书

技术领域

本说明书涉及智慧城市领域，特别涉及一种基于物联网的智慧城市医疗保险数据评估方法和系统。

背景技术

现如今保险公司以及商业保险种类越来越多，不同保险公司不同种类保险审核方式也是多种多样。为了进行风险控制，保险公司需要在投保前对投保客户的投保请求信息层层审核。

因此，希望提供一种基于物联网的智慧城市医疗保险数据评估方法和系统，能够对投保客户进行准确有效的审核。

发明内容

本说明书实施例之一提供一种基于物联网的智慧城市医疗保险数据评估方法该由医疗管理平台执行，包括：基于服务平台基于用户平台获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估；基于人口信息平台获取评估对象的关联人；基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征；基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征；基于目标医疗特征和目标投保特征，确定参保风险的评估值；以及基于服务平台通过用户平台将评估值反馈给用户。

本说明书实施例之一提供一种基于物联网的智慧城市医疗保险数据评估系统，包括服务平台和医疗管理平台，医疗管理平台被配置为执行以下操作：通过服务平台基于用户平台获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估；基于人口信息平台获取评估对象的关联人；基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征；基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征；基于目标医疗特征和目标投保特征，确定参保风险的评估值；以及通过服务平台基于用户平台将评估值反馈给用户。

本说明书实施例之一提供一种计算机可读存储介质，所述存储介质存储计算机指令，当计算机读取存储介质中的计算机指令后，计算机执行上述基于物联网的智慧城市医疗保险数据评估方法。

附图说明

本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估系统的应用场景示意图；

图2是根据本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估系统的示例性模块图；

图3是本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估方法的示例性流程图；

图4是根据本说明书一些实施例所示的获取目标医疗特征的示例性示意图；

图5是根据本说明书一些实施例所示的获取目标投保特征的示例性示意图；

图6根据本说明书一些实施例所示的基于协同特征确定参保风险的评估值的示例性流程图；

图7是根据本说明书一些实施例所示的确定参保风险的评估值的示例性示意图。

其中，100、应用场景；110、处理器；120、网络；130、存储器；140、终端；150、云平台；200、基于物联网的智慧城市医疗保险数据评估系统；210、用户平台；220、服务平台；230、医疗管理平台；410、医疗知识图谱；420、评估对象；430、第一关联人；440、第二关联人；430-1、第一医疗特征；440-1、第二医疗特征；420-1、第一医疗特征；420-2、第二医疗特征；450、加权后的第一医疗特征；460、加权后的第二医疗特征；470、目标医疗特征；510、医疗知识图谱；530、第一关联人；540、第二关联人；530-1、第一投保特征；540-1、第二医疗特征；520、评估对象；520-1、第一投保特征；520-2、第二投保特征；550、加权后的第一投保特征；560、加权后的第二投保特征；570、目标投保特征；720、安全计算模型；710-1、目标医疗特征；710-2、目标投保特征；730-1、目标医疗特征向量；730-2、特征向量；740、风险评估模型；750、参保风险的评估值。

具体实施方式

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

如本说明书和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

图1是根据本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估系统的应用场景示意图。

如图1所示，基于物联网的智慧城市医疗保险数据评估系统的应用场景100可以包括处理器110、网络120、存储器130、终端140、网外云平台150。在一些实施例中，应用场景100中的组件可以经由网络120(例如无线连接、有线连接或其组合)，以实现彼此连接和/或通信。例如，处理器110可以通过网络120连接到存储器130。

基于物联网的智慧城市医疗保险数据评估系统可以通过实施本说明书中披露的方法和/或过程来确定评估对象参保风险的评估值。具体的，当评估对象有意愿参保时，保险公司可以请求基于物联网的智慧城市医疗保险数据评估系统基于评估对象和其关联人的医疗特征和投保特征来确定评估对象的参保风险的评估值，以使保险公司能够基于评估值进行后续处理。例如，当评估对象参保风险的评估值较高，保险公司可能会提高保费或者甚至拒绝评估对象参保。

处理器110可以处理与基于物联网的智慧城市医疗保险数据评估系统相关的数据和/或信息。在一些实施例中，处理器110从网外云平台150、存储器130和/或终端140以访问信息和/或数据。例如，处理器110可以从网外云平台150和/或从存储器130获取评估对象和关联人的医疗特征、投保特征、协同特征等。在一些实施例中，处理器110可以处理从网外云平台150和/或存储器130获取的信息和/或数据。例如，处理器110可以对从网外云平台150获取的评估对象和关联人的医疗特征、投保特征进行处理，确定评估对象的参保风险的评估值。在一些实施例中，处理器110可以包括一个或以上处理引擎(例如，单芯片处理引擎或多芯片处理引擎)。仅作为示例，处理器110可以包括中央处理单元(CPU)。处理器110可以处理从其他设备或系统组成部分中获得的数据、信息和/或处理结果，并基于这些数据、信息和/或处理结果执行程序指令，以执行本说明书中描述的一个或以上功能。

网络120可以包括提供能够促进基于物联网的智慧城市医疗保险数据评估系统的应用场景100中各个组件的信息和/或数据交换的任何合适的网络。基于物联网的智慧城市医疗保险数据评估系统的应用场景100中的一个或多个组件(例如，处理器110、存储器130、终端140、网外云平台150)之间可以通过网络120交换信息和/或数据。例如，网络120可以将从网外云平台150获取的评估对象和关联人的医疗特征、投保特征和协同特征发送给处理器110。在一些实施例中，网络120可以是有线网络或无线网络中的任意一种或多种。在一些实施例中，网络120可以包括一个或以上网络接入点。例如，网络120可以包括有线或无线网络接入点。在一些实施例中，网络可以是点对点的、共享的、中心式的等各种拓扑结构或者多种拓扑结构的组合。

存储器130可以用于存储数据、指令和/或任何其他信息。在一些实施例中，存储器130可以存储从例如处理器110、网外云平台150等中获得的数据和/或信息。例如，存储器130可以存储评估对象和关联人的医疗特征、投保特征和协同特征以及医疗知识图谱等。在一些实施例中，存储器130可以设置在处理器110中。在一些实施例中，存储器130可包括大容量存储器、可移除存储器等或其任意组合。

终端140可以指用户所使用的一个或多个终端设备或软件。在一些实施例中，终端140可以是移动设备、平板计算机、笔记本电脑等或其任意组合。在一些实施例中，终端140可以通过网络120与基于物联网的智慧城市医疗保险数据评估系统的应用场景100中的其他组件交互。在一些实施例中，终端140可以是保险人员所使用的终端设备或软件。

网外云平台150可以是与基于物联网的智慧城市医疗保险数据评估系统通讯连接的用于进行数据存储和处理的云计算平台。在一些实施例中，网外云平台150可以包括人口信息平台、医疗信息平台、协同平台等。人口信息平台可以指记录有居民相关信息(如居民身份信息、住址信息等)的云平台或外部数据库。在一些实施例中，处理器110可以基于人口信息平台确定评估对象的关联人。医疗信息平台可以指记录有居民的相关医疗信息(如居民的疾病记录、治疗记录等)的云平台或外部数据库。

在一些实施例中，处理器110可以通过医疗信息平台获取评估对象和关联人的医疗特征和投保特征。协同平台可以指记录有居民相关协同信息的一个或多个云平台或外部数据库。在一些实施例中，处理器110可以通过协同平台获取评估对象和关联人的协同特征。在一些实施例中，网络云平台150可以通过网络120与处理器110存储器130以及终端140通信连接并进行数据交换。例如，网络云平台150可以将获取的评估对象和关联人的医疗特征和投保特征发送至处理器110进行处理。

应当注意基于物联网的智慧城市医疗保险数据评估系统的应用场景100仅仅是为了说明的目的而提供，并不意图限制本说明书的范围。对于本领域的普通技术人员来说，可以根据本说明书的描述，做出多种修改或变化。例如，应用场景还可以包括数据库。又例如，应用场景100可以在其他设备上实现以实现类似或不同的功能。然而，变化和修改不会背离本说明书的范围。

物联网系统是一种包括管理平台、服务平台、用户平台中部分或全部平台的信息处理系统，其中，管理平台可以实现统筹、协调各功能平台之间的联系和协作，管理平台汇聚着物联网运行体系的信息，可以为物联网运行体系提供感知管理和控制管理功能。服务平台指可以为用户提供输入和输出服务的平台。管理平台可以实现统筹、协调各功能平台之间的联系和协作，汇聚着物联网运行体系的信息，可以为物联网运行体系提供感知管理和控制管理功能。用户平台是对感知信息生成和控制信息进行执行的功能平台。

物联网系统中信息的处理可以分为感知信息的处理流程及控制信息的处理流程，控制信息可以是基于感知信息而生成的信息。其中，感知信息的处理是由用户平台获取感知信息，并传递至管理平台。控制信息则是由管理平台下发至用户平台，进而实现对相应用户的控制。

在一些实施例中，将物联网系统应用于城市管理时，可以将其称之为智慧城市物联网系统。

图2是根据本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估系统的示例性示意图。如图2所示，基于物联网的智慧城市医疗保险数据评估系统200包括用户平台210、服务平台220、医疗管理平台230。在一些实施例中，基于物联网的智慧城市医疗保险数据评估系统200可以为处理器110的一部分或由处理器110实现。

用户平台210可以是用于与用户进行交互的平台。在一些实施例中，用户平台可以被配置为终端设备，例如，终端设备可以包括移动设备、平板计算机等或其任意组合。在一些实施例中，用户平台可以用于接收用户输入的请求和/或指令。例如，用户平台可以通过终端(例如，终端140)获取用户的风险查询请求。在一些实施例中，用户平台210可以与服务平台220通信连接(即进行交互)，将输入指令经由服务平台220发送至医疗管理平台230，以及经由服务平台220接收医疗管理平台230中提取的用户平台210所需要的数据和/或信息。

服务平台220可以是用于接收和传输数据和/或信息的平台。例如，医疗保险服务平台220可以从用户平台210获取风险查询请求。再例如，服务平台220可以通过用户平台210将评估对象参保风险的评估值反馈给用户。

医疗管理平台230可以指统筹、协调各功能平台之间的联系和协作，汇聚着基于物联网的智慧城市医疗保险数据评估系统200全部的信息，为基于物联网的智慧城市医疗保险数据评估系统200运行体系提供感知管理和控制管理功能的平台。例如，医疗管理平台230可以通过服务平台220基于用户平台210获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估；基于人口信息平台获取评估对象的关联人；基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征；基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征；基于目标医疗特征和目标投保特征，确定参保风险的评估值；以及通过服务平台220基于用户平台210将评估值反馈给用户。医疗管理平台230可以包括图1中的处理器110以及其他组件。在一些实施例中，医疗管理平台230可以是由管理人员、人工智能、或由预设规则操控的远程平台。

在一些实施例中，医疗管理平台230还可以与网外云平台150(例如，人口信息平台、医疗信息平台、协同平台等)进行通讯，以获取数据和/或信息。关于人口信息平台、医疗信息平台、协同平台可以参见图3-5的相关说明。

在一些实施例中，基于物联网的智慧城市医疗保险数据评估系统200可以应用于医疗保险数据评估的多种场景。例如，新用户投保场景、老用户续保场景等。在一些实施例中，基于物联网的智慧城市医疗保险数据评估系统200可以分别获取多种场景下的评估对象和其关联人医疗特征和投保特征，以得到评估对象的参保风险的评估值，以及进一步确定评估对象的保险策略。

基于物联网的智慧城市医疗保险数据评估系统200的多种场景可以包括新用户投保场景、老用户续保场景等。需要说明的是以上场景仅为示例，并不对基于物联网的智慧城市医疗保险数据评估系统200的具体应用场景起限制作用，本领域技术人员可以在本实施例公开的内容基础上，将基于物联网的智慧城市医疗保险数据评估系统200应用于其他合适的任何场景。

示例性地，在新用户投保场景中，保险公司的相关人员可以对新用户(即评估对象)的参保风险进行评估，并根据评估值确定新用户的投保策略。在对新用户参保风险进行评估的过程中，可以获取新用户的关联人，并根据新用户和其关联人医疗数据(年龄、得病次数、治疗花费等)和投保数据(例如，历史参保的数据)来确定新用户和其关联人的医疗特征和投保特征，并基于医疗特征和投保特征来确定评估对象(即新用户)参保风险的评估值。参保风险的评估值可以用于确定判断评估对象参保后发生意外导致保险公司赔付的风险，若该赔付风险较高，保险公司可能会提高保费、或是拒绝新用户的参保请求。

示例性地，在老用户续投场景中，保险公司的相关人员可以对老用户(即评估对象)的续保风险进行评估，并根据评估值确定老用户的续保策略。在对老用户续保风险进行评估的过程中，可以获取老用户在该保险公司中历史参保的相关数据并进一步获取老用户及其关联人在历史参保期间中的医疗数据和投保数据，以对确定老用户的续保风险的评估值。

在一些实施例中，基于物联网的智慧城市医疗保险数据评估系统200可以由多个医疗保险数据评估子系统构成，每个子系统可以应用于一种场景。基于物联网的智慧城市医疗保险数据评估系统200可以对各个子系统获取的数据、输出的数据进行综合管理与处理，进而得到用于辅助医疗保险数据评估的相关策略或指令。例如，基于物联网的智慧城市医疗保险数据评估系统200可以包括分别应用于新用户投保场景的子系统、应用于老用户续保的子系统。基于物联网的智慧城市医疗保险数据评估系统200作为各个子系统的上级系统。

对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，将系统移用到其他任何合适的场景下。

在一些实施例中，医疗管理平台230可以被配置为：通过服务平台基于用户平台获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估；基于人口信息平台获取评估对象的关联人；基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征；基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征；基于目标医疗特征和目标投保特征，确定参保风险的评估值；以及通过服务平台基于用户平台将评估值反馈给用户。

在一些实施例中，医疗管理平台230可以被配置为进一步执行以下操作：基于医疗平台获取医疗知识图谱；基于医疗知识图谱获取评估对象和关联人的医疗特征和投保特征。关于医疗知识图谱、评估对象和关联人的医疗特征和投保特征的更多细节可参见图3和图4及其相关描述。

在一些实施例中，医疗管理平台230可以被配置为进一步执行以下操作：基于协同平台获取评估对象和关联人的协同特征；基于目标医疗特征、目标投保特征以及协同特征，确定参保风险的评估值。关于评估对象和关联人的协同特征的更多细节可参见图5及其相关描述。

在一些实施例中，医疗管理平台230可以被配置为进一步执行以下操作：基于风险评估模型对目标医疗特征和目标投保特征进行处理，确定参保风险的评估值。关于参保风险的评估值的更多细节可以参见图6及其相关描述。

需要注意的是，以上对于系统及其组成部分的描述，仅为描述方便，并不能把本说明书限制在所举实施例范围之内。可以理解，对于本领域的技术人员来说，在了解该系统的原理后，可能在不背离这一原理的情况下，对各个组成部分进行任意组合，或者构成子系统与其他组成连接。例如，各个组成部分可以共用一个存储设备，各个组成部分也可以分别具有各自的存储设备。诸如此类的变形，均在本说明书的保护范围之内。

图3是根据本说明书一些实施例所示的基于物联网的智慧城市医疗保险数据评估方法的示例性流程图。如图3所示，流程300包括下述步骤。在一些实施例中，流程300可以由医疗管理平台230执行。

步骤310，基于服务平台通过用户平台获取用户的风险查询请求，风险查询请求用于对评估对象的参保风险进行风险评估。

在一些实施例中，用户可以包括保险公司的相关操作人员、已投保或拟投保的相关人员等。

评估对象可以指需要对其参保风险进行评估的人。例如，用户a拟投保重大疾病保险时，可以对用户a的参保风险进行评估，用户a即为评估对象。

参保风险可以是评估对象参保后可能导致保险理赔的风险。在一些实施例中，参保风险可以是评估对象的经济状态不佳而造成的无法支付后续保费的风险等。

风险查询请求可以是用于对评估对象的参保风险进行风险评估的操作指令。在一些实施例中，风险查询请求可以包括评估对象以及评估对象已参保或拟参保的保险类型。例如，风险查询请求可以是对评估对象a参保的重大疾病险进行风险评估。其中，风险查询请求中的评估对象可以通过标识信息标识。例如，风险查询请求可以包括评估对象的身份识别号(Identity Document,ID)、姓名等。

在一些实施例中，用户平台210可以基于用户在用户平台输入的评估对象的标识信息和保险类型生成风险查询请求。在一些实施例中，医疗管理平台230可以经由服务平台220获取用户平台210输入的风险查询请求。例如，保险公司中的相关操作人员可以在用户平台210输入风险查询请求，用户平台210在接收该风险查询请求后，将风险查询请求发送到服务平台220，服务平台220可以对该风险查询请求进行解析发送到医疗管理平台230，以使医疗管理平台230根据风险查询请求执行本说明书提供的基于物联网的智慧城市医疗保险数据评估方法。关于用户平台210、服务平台220以及医疗管理平台230的更多内容可以参见图2及其相关描述。

步骤320，基于人口信息平台获取评估对象的关联人。

人口信息平台可以指记录有居民相关信息(如居民身份信息、住址信息等)的云平台或外部数据库。例如，人口信息平台可以包括公安系统的户籍数据库。

在一些实施例中，医疗管理平台230可以响应于风险查询请求，与人口信息平台通讯并获取评估对象的关联人。

关联人可以指与评估对象存在关联关系的人。在一些实施例中，关联人可以是与评估对象存在亲属关系的人。例如，关联人可以是评估对象的妻子或丈夫、父母、兄弟姐妹等。在一些实施例中，关联人也可以是与评估对象的住址、疾病记录、治疗记录或投保记录等之间存在一定关系的人。例如，关联人可以是与评估对象投保了相同类型保险的人。再例如，关联人可以是与评估对象居住地址相同的人。

在一些实施例中，医疗管理平台230可以通过人口信息平台查询到与评估对象存在亲属关系或与评估对象在住址、疾病记录、治疗记录或投保记录上存在一定关系的人，并将这部分人确定为评估对象的关联人。

在一些实施例中，医疗管理平台230可以根据评估对象的标识信息从人口信息平台调用评估对象的相关信息，并根据评估对象的相关信息确定关联人。例如，可以根据评估对象的居住地址将与评估对象居住地址相同的人作为评估对象的关联人。在一些实施例中，为保证评估对象与关联人的隐私安全，人口信息平台反馈的评估对象与关联人可以通过不暴露隐私信息(如居民ID)的标识信息表征。

步骤330，基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征。

医疗信息平台可以指记录有居民的相关医疗信息的云平台或外部数据库。在一些实施例中，医疗信息平台中可以包括居民的疾病记录、治疗记录、投保记录(包括购买的商业医保的险种情况、理赔情况等)等信息。

医疗特征可以是描述对象(即评估对象以及关联人)健康状况的特征。在一些实施例中，医疗特征可以包括疾病的治疗次数、治疗花费等。在一些实施例中，医疗特征可以包括第一医疗特征和第二医疗特征。其中，第一医疗特征可以是与基因疾病相关(如哮喘、先天心脏病等)的医疗特征，第二医疗特征可以是不良生活方式导致的疾病(如高血压、糖尿病等)相关的医疗特征。在一些实施例中，医疗特征还可以包括与普通疾病(如感冒、发烧等)相关的医疗特征。关于第一医疗特征和第二医疗特征的更多内容参见图4及其相关描述。

投保特征可以是描述对象(如评估对象以及关联人)购买的医疗保险的险种情况及理赔情况的特征。在一些实施例中，投保特征可以包括对象的投保险种、投保次数、总投保保费、理赔次数以及理赔总金额。

在一些实施例中，医疗管理平台230可以向医疗信息平台发出数据调用请求，获取评估对象及关联人的医疗特征和投保特征。其中，数据调用请求中可以包括对象的标识信息(如对象的身份ID)、调用的数据类型(如，医疗特征或投保特征)等。在一些实施例中，医疗信息平台可以解析相应的数据调用请求，确定评估对象以及关联人的身份ID，并根据身份ID调用对应的数据并发送至医疗管理平台230。

在一些实施例中，医疗管理平台230基于医疗信息平台获取评估对象和关联人的医疗特征和投保特征时，可以基于医疗信息平台获取医疗知识图谱，并基于医疗知识图谱获取评估对象和关联人的医疗特征和投保特征。

医疗知识图谱可以指基于居民的医疗数据及保险数据等构建的语义网络，医疗知识图谱可以包括节点数据以及边数据。

节点数据可以包括居民节点和机构节点，其中，居民节点对应于一个居民，居民节点对应的节点属性可以包括该居民的年龄信息、住址信息等；机构节点对应于一个机构，机构节点可以包括医疗机构节点和保险机构节点，机构节点对应的节点属性可以包括机构的名称、地址信息等。

边数据包括边的类型及边的属性，其中，居民节点之间的边的类型可以包括表示存在一代直系亲属关系的边(后续简称为第一类边)、表示住址相同的边(后续简称为第二类边)，居民节点与机构节点之间的边的类型可以包括表示与对应保险机构存在投保关系的边(后续简称为第三类边)、表示与对应医疗机构存在治疗关系的边(后续简称为第四类边)。

第一类边用于表示居民节点对应的居民之间存在一代直系亲属关系，一代直系亲属关系可以包括父子关系、母女关系等。基于第一类边的属性可以确定两个被连接的节点之间具体是什么一代直系亲属关系。

第二类边用于表示居民节点对应的居民住址相同，例如，住在莲花小区的居民对应的居民节点之间存在第二类边。基于第二类边的属性可以确定两个被连接的节点的具体地址信息。

第三类边用于表示居民与保险机构之间存在投保关系，用以反映该居民在该保险机构买过保险。在一些实施例中，第三类边的边属性可以包括该居民的投保次数、总投保保费、理赔次数、理赔总金额。在一些实施例中，第三类边的边属性可以用向量表示，例如第三类边的边属性可以为(a，b，c，d)，其中，a表示投保次数、b表示总投保保费、c表示理赔次数、d表示理赔总金额。

第四类边用于表示居民与医疗机构之间存在治疗关系，用于反映该居民在该医疗机构进行过治疗。在一些实施例中，第四类边的边属性可以包括治疗频率向量、治疗花费向量等。在一些实施例中，治疗频率向量和治疗花费向量可以为三维向量，其三个维度分别与第一医疗特征、第二医疗特征和第三医疗特征有关。例如，居民a与医疗机构b之间存在边，且其中治疗频率向量为(0,0,5)、治疗花费向量为(0,0,500)，表示居民a在医疗机构b进行过5次普通病的治疗，花费为500元。

在一些实施例中，医疗管理平台230可以根据评估对象和关联人的标识信息从医疗知识图谱查找对应的居民节点，并确定与该居民节点相关联的节点和边，根据节点属性和边属性分别确定评估对象和关联人的医疗特征和投保特征。在一些实施例中，可以根据与评估对象对应的居民节点与医疗机构节点之间第三类边的边属性确定评估对象的投保特征。例如，第三类边的边属性可以为(2,6000,1,20000)，则对应确定的投保特征为，投保次数为2次、总投保保费为6000元、理赔次数为1次、理赔总金额为20000元。

在一些实施例中，可以根据评估对象对应的居民节点与医疗机构节点之间的第四类边的边属性确定评估对象的医疗特征。第四类边的边属性可以包括治疗频率向量、治疗花费向量等。在一些实施例中，治疗频率向量和治疗花费向量可以为三维向量，其三个维度分别与第一医疗特征、第二医疗特征和第三医疗特征有关。例如，第四类边的边属性为治疗频率向量(0,0,5)、治疗花费向量(0,0,500)，表示对应居民的医疗特征为在对应医疗机构进行过5次普通病的治疗，花费为500元。在一些实施例中，可以将第四类边的边属性中所包括的治疗频率向量、治疗花费向量确定为评估对象的医疗特征。

在一些实施例中，可以根据评估对象对应的居民节点相连的第一类边和第二类边确定评估对象的关联人，再根据关联人对应的居民节点相连的第三类边、第四类边分别确定关联人的投保特征和医疗特征。类似的，关联人的投保特征和医疗特征的确定方式与评估对象的投保特征和医疗特征的确定方式相同。

在一些实施例中，考虑到医疗特征以及投保特征可能涉及对象的隐私信息，医疗信息平台在将评估对象和关联人的医疗特征和投保特征发送至医疗管理平台230之前，可以通过安全计算模型对医疗特征和投保特征进行加密处理，生成不暴露对象的隐私信息的医疗特征向量和投保特征向量。关于安全计算模型的更多内容可以参见图7及其相关描述。

步骤340，基于评估对象和关联人的医疗特征和投保特征确定目标医疗特征和目标投保特征。

目标医疗特征可以反映关联人对评估对象的医疗特征的影响。在一些实施例中，目标医疗特征可以是评估对象自身的医疗特征和关联人的医疗特征的加权结果。类似的，目标投保特征可以反映关联人对评估对象的投保特征的影响。在一些实施例中，目标投保特征可以是评估对象自身的投保特征和关联人的投保特征的加权结果。

在一些实施例中，医疗管理平台230可以对评估对象的医疗特征以及关联人的医疗特征进行加权处理，确定目标医疗特征；以及对评估对象的投保特征以及关联人的投保特征进行加权处理，确定目标投保特征。

在一些实施例中，医疗管理平台230可以对评估对象的医疗特征和关联人的医疗特征分配不同的权重后进行加权处理，以确定目标医疗特征。例如，可以将评估对象的医疗特征的权重设置为0.8、关联人a的医疗特征的权重设置为0.08、关联人b的医疗特征的权重设置为0.1、关联人c的医疗特征的权重设置为0.02，以确定目标医疗特征。类似的，可以对评估对象的投保特征和关联人的投保特征分配不同的权重后进行加权处理，以确定目标投保特征。

在一些实施例中，医疗管理平台230可以对评估对象的第一医疗特征和关联人的第一医疗特征分配不同的权重后进行加权处理，以确定加权后的第一医疗特征；对评估对象的第二医疗特征和关联人的第二医疗特征分配不同的权重后进行加权处理，以确定加权后的第二医疗特征，最后基于加权后的第一医疗特征和加权后的第二医疗特征确定目标医疗特征。示例性的，可以将关联人的第一医疗特征中治疗次数与花费加权到评估对象的第一医疗特征中；将第二关联人的第二医疗特征中治疗次数及花费加权到评估对象的第二医疗特征中，从而得到评估对象的目标医疗特征。关于加权后的第一医疗特征和加权后的第二医疗特征的更多内容参见图4及其相关描述。

在一些实施例中，权重可以与关联人对应居民节点与评估对象对应的居民节点之间的邻度有关。其中，邻度越小权重越高。邻度与两个节点间最短路径涉及的边的数量相关，邻度为1表示两个节点之间最短路径为一条边。关于邻度的更多内容参见图4及其相关描述。

在一些实施例中，评估对象和关联人的权重可以反映关联人对评估对象的影响力。例如，邻度值越大的亲属，该亲属的基因与关联人基因可能相差较大，则该亲属权重较低。当邻度值较小的亲属患有与基因相关的病时，则评估对象患有该基因相关的病的概率较低。在一些实施例中，评估对象的权重可以大于关联人的权重。在一些实施例中，权重还可以提前预设。例如，邻度为1时权重设置为0.3、邻度为2时权重设置为0.2。

在一些实施例中，医疗管理平台230可以基于医疗知识图谱确定第一关联人和第二关联人，以及确定第一关联人的第一医疗特征和第二关联人的第二医疗特征；对第一关联人的第一医疗特征与评估对象的第一医疗特征进行加权处理，得到加权后的第一医疗特征；对第二关联人的第二医疗特征与评估对象的第二医疗特征进行加权处理，得到加权后的第二医疗特征；最后基于加权后的第一医疗特征和加权后的第二医疗特征，确定目标医疗特征。关于确定目标医疗特征的更多内容参见图4及其相关描述。

在一些实施例中，医疗管理平台230可以基于医疗知识图谱确定第一关联人和第二关联人，以及确定第一关联人的投保特征和第二关联人的投保特征；然后对第一关联人的投保特征、第二关联人的投保特征与评估对象的投保特征进行加权处理，确定目标投保特征。关于确定目标投保特征的更多内容参见图5及其相关描述。

步骤350，基于目标医疗特征和目标投保特征，确定参保风险的评估值。

评估值可以用于表示参保风险的大小。评估值越高，表示评估对象的参保风险越高，对该评估对象进行理赔的机率越高。在一些实施例中，评估值的表现形式可以根据实际需要确定。例如，评估值可以是百分比，也可以是风险等级(如1-3级风险等级，数值越高，风险等级越高)。

在一些实施例中，医疗管理平台230可以基于安全计算模型对所述目标医疗特征和所述目标投保特征进行处理，确定目标医疗特征向量和目标投保特征向量，并基于风险评估模型对目标医疗特征向量和目标投保特征向量进行处理，确定参保风险的评估值。在一些实施例中，安全计算模型和风险评估模型可以通过联合训练得到。关于风险评估模型的更多内容可以参见图7及其相关描述。

考虑到目标医疗特征以及目标投保特征可能涉及对象的隐私信息，医疗管理平台230在从医疗信息平台获取评估对象和关联人的目标医疗特征和目标投保特征之前，可以通过安全计算模型对目标医疗特征和目标投保特征进行加密处理，生成不暴露对象的隐私信息的目标医疗特征向量和目标投保特征向量。关于安全计算模型和风险评估模型的更多内容可以参见图7及其相关描述。

步骤360，基于服务平台通过用户平台将评估值反馈给用户。

在一些实施例中，当医疗管理平台230确定评估值后，可以将该评估值通过服务平台发送到用户平台，通过用户平台将评估值反馈给用户。

在一些实施例中，用户可以基于获取的评估值进行后续处理。在一些实施例中，用户可以基于评估值调整评估对象的参保费用，或拒绝评估对象的参保请求。例如，可以将评估值较高的保险项目的保费增加，或拒绝评估对象参与该保险项目。在一些实施例中，用户可以基于评估值对评估对象安排更详细的检查。例如，保险公司可以进一步安排评估对象去其指定的医疗机构进行体检，从而获取其更详细的医疗数据。

基于本说明书一些实施例提供的基于物联网的智慧城市医疗保险数据评估方法，可以在保证评估对象的隐私信息不外泄的情况下，为用户(例如保险评估人员)提供评估对象的参保风险的评估值，进而可以基于参保风险的评估值调整评估对象的参保策略(例如调整评估对象的参保费用，或拒绝评估对象的参保请求)。同时，可以基于评价对象的关联人相关情况(如投保情况、患病情况)确定评价对象的参保风险，从而合理安排评价对象的保险价格、项目等，进而降低医疗保险的经济成本。

应当注意的是，上述有关流程300的描述仅仅是为了示例和说明，而不限定本说明书的适用范围。对于本领域技术人员来说，在本说明书的指导下可以对流程300进行各种修正和改变。然而，这些修正和改变仍在本说明书的范围之内。例如，上述步骤330、步骤340可以由医疗信息平台或其相关处理设备执行。

图4是根据本说明书一些实施例所示的获取目标医疗特征的示例性示意图。

如图4所示，医疗知识图谱410的节点数据可以包括居民节点A、居民节点B、居民节点C、居民节点D、医疗机构节点A、医疗机构节点B、保险机构节点C等；医疗知识图谱410的边数据包括第一类边a、第一类边b、第二类边a、第四类边a、第四类边b、第四类边c、第三类边d等。关于居民节点、医疗机构节点、第一类边、第二类边、第三类边和第四类边的更多内容参见图3及其相关描述。

在一些实施例中，可以基于医疗知识图谱410确定评估对象420的第一关联人430和第二关联人440，以及确定第一关联人430的第一医疗特征430-1和第二关联人440的第二医疗特征440-1。

第一关联人可以是与评估对象对应的居民节点之间存在第一类边的居民节点对应的人，即第一关联人可以是与评估对象存在直系亲属关系的人。如图4所示，居民节点A与居民节点B之间存在第一类边a，居民节点A对应的居民为评估对象时，居民节点B对应的居民即为该评估对象的第一关联人。

第二关联人可以是与评估对象对应的居民节点之间存在第二类边的居民节点对应的人，即第二关联人可以是与评估对象住址相同的人。如图4所示，居民节点A与居民节点D之间存在第二类边a，居民节点A对应的居民为评估对象时，居民节点D对应的居民即为该评估对象的第二关联人。

在一些实施例中，可以根据预设邻度条件确定评估对象420的第一关联人430。邻度与两个节点间最短路径涉及的边的数量相关，邻度为0表示两个节点之间不存在边，邻度为1表示两个节点之间的最短路径为一条边，邻度为2表示两个节点之间的最短路径为两条边。例如，居民节点A与居民节点B之间通过第一类边a相连，居民节点B与居民节点C之间通过第一类边b相连，即居民节点A与居民节点C之间存在两条第一类边。预设邻度条件可以是两个节点之间的邻度需要满足的条件，例如预设邻度值不超过2。

值得说明的是，在确定第一关联人的实施例中，邻度大于或等于2时，两个节点之间存在的边必须为同一类型。例如，邻度为2时，两个节点之间存在的两条边可以均为第一类边，也可以均为第二类边，但不可以是一条第一类边和一条第二类边。

在一些实施例中，当边类型为第一类边时，可以将与评估对象对应的居民节点之间的邻度满足预设邻度条件的居民节点对应的居民，确定为评估对象的第一关联人。示例性的，预设邻度条件为邻度为2，当评估对象420在医疗知识图谱410中对应的居民节点为居民节点A时，可以将与居民节点A之间存在一条和两条第一类边的居民节点对应的居民确定为评估对象420的第一关联人430，即将与居民节点A之间存在第一类边a的居民节点B、与居民节点B之间存在第一类边b的居民节点C对应的居民确定为第一关联人430。

在一些实施例中，可以将与评估对象对应的居民节点之间存在第二类边的居民节点对应的居民，确定为评估对象的第二关联人。示例性的，当评估对象420在医疗知识图谱410中对应的居民节点为居民节点A时，可以将与居民节点A之间存在第二类边的居民节点对应的居民确定为评估对象420的第二关联人440，即可以将与居民节点A之间存在第二类边a的居民节点D对应的居民确定为第二关联人440。

在一些实施例中，在确定了第一关联人430和第二关联人440后，医疗管理平台230可以根据医疗知识图谱410的边属性确定第一关联人430的第一医疗特征430-1和第二关联人440的第二医疗特征440-1。

在一些实施例中，可以根据第一关联人430和第二关联人440分别对应的居民节点与医疗机构节点之间的第四类边的边属性分别确定第一关联人430的第一医疗特征430-1和第二关联人440的第二医疗特征440-1。例如，可以将第一关联人430的医疗特征中与基因相关的疾病的相关数据确定为第一关联人430的第一医疗特征430-1。又例如，可以将第二关联人440的医疗特征中与不良生活方式导致的疾病的相关数据确定为第二关联人440的第二医疗特征440-1。关于获取医疗特征的更多内容参见步骤330及其相关描述，在此不再赘述。

在一些实施例中，评估对象420的第一医疗特征420-1和第二医疗特征420-2可以根据评估对象420的医疗特征直接确定。例如，可以将评估对象420的医疗特征中与基因相关的疾病的相关数据确定为评估对象420的第一医疗特征420-1，将评估对象420的医疗特征中与不良生活方式导致的疾病的相关数据确定为评估对象420的第二医疗特征420-2。关于获取评估对象的医疗特征的更多内容参见步骤330及其相关描述，在此不再赘述。

在一些实施例中，医疗管理平台230可以对第一关联人430的第一医疗特征430-1与评估对象420的第一医疗特征420-1进行加权处理，得到加权后的第一医疗特征450；以及对第二关联人440的第二医疗特征440-1与评估对象420的第二医疗特征420-2进行加权处理，得到加权后的第二医疗特征460；最后基于加权后的第一医疗特征450和加权后的第二医疗特征460，确定目标医疗特征470。

示例性的，居民节点A对应的居民为评估对象420时，根据居民节点A与医疗机构节点B之间的第四类边c的边属性可以确定评估对象420在医疗机构节点B的医疗特征，即治疗频率向量和治疗花费向量分别为(0,0,10)以及(0,0,5000)，评估对象420对应权重为0.5；根据居民节点B与医疗机构B之间的第四类边b的边属性可以确定对应的第一关联人430的治疗频率向量和治疗花费向量分别为(1,0,0)以及(10000,0,0)，居民节点B对应的第一关联人430对应的权重为0.2，；根据居民节点D与医疗机构B之间的第四类边d的边属性可以确定对应的第二关联人440的治疗频率向量和治疗花费向量分别为(0,2,0)以及(0,20000,0)，居民节点D对应的第二关联人440对应的权重为0.3，居民节点D对应的第二关联人440与医疗机构B之间的治疗频率向量和治疗花费向量分别为(0,0,10)以及(0,0,5000)，权重为0.5，则可以确定评估对象的加权后的医疗特征，即加权后的治疗频率向量和加权治疗花费向量分别为(0.2,0.6,5)以及(2000,6000,2500)，即可以确定加权后的第一医疗特征450为(0.2,2000)，其中0.2表示第一医疗特征的治疗频率、2000表示第一医疗特征的治疗花费；加权后的第二医疗特征460为(0.6,6000)，其中0.6表示第二医疗特征额治疗频率、6000表示第二医疗特征的治疗花费。

本说明书一些实施例提供的目标医疗特征确定方法，通过获取评估对象的医疗特征和关联人的医疗特征的加权结果，可以全面地考虑到家族健康状况、家族遗传病、同住人生活方式对评估对象的参保风险的影响，更准确地对目标对象进行风险评估。

图5是根据本说明书一些实施例所示的获取目标投保特征的示例性示意图。

如图5所示，医疗知识图谱510的节点数据可以包括居民节点A、居民节点B、居民节点C、居民节点D、医疗机构节点A、医疗机构节点B、保险机构节点C等；医疗知识图谱510的边数据包括第一类边a、第一类边b、第二类边a、第三类边a、第三类边b、第三类边c、第四类边d等。关于居民节点、医疗机构节点、第一类边、第二类边、第三类边和第四类边的更多内容参见图3及其相关描述。

如图5所示，居民节点A与居民节点B之间存在第一类边a，居民节点A对应的居民为评估对象时，居民节点B对应的居民即为该评估对象的第一关联人。居民节点A与居民节点D之间存在第二类边a，居民节点A对应的居民为评估对象时，居民节点D对应的居民即为该评估对象的第二关联人。

在一些实施例中，当边类型为第一类边时，可以将与评估对象对应的居民节点之间的邻度满足预设邻度条件的居民节点对应的居民，确定为评估对象的第一关联人。在一些实施例中，可以将与评估对象对应的居民节点之间存在第二类边的居民节点对应的居民，确定为评估对象的第二关联人。关于确定第一关联人和第二关联人的更多内容参见图4及其相关描述。

在一些实施例中，在确定了第一关联人530和第二关联人540后，医疗管理平台230可以根据医疗知识图谱510的边属性确定第一关联人530的投保特征530-1和第二关联人540的投保特征540-1。

在一些实施例中，可以根据第一关联人530和第二关联人540分别对应的居民节点与保险机构节点之间的第三类边的边属性分别确定第一关联人530的投保特征530-1和第二关联人540的投保特征540-1。

在一些实施例中，评估对象520的投保特征520-1和投保特征520-2可以根据评估对象520的投保特征直接确定。投保特征的确定方式类似于第一医疗特征和第二医疗特征的确定方式，更多内容可以参考图4及其相关描述。

在一些实施例中，医疗管理平台230可以对第一关联人530的投保特征530-1、第二关联人540的投保特征540-1与评估对象520的投保特征520-1进行加权处理，得到目标投保特征550。目标投保特征570的确定方式类似于目标医疗特征470的确定方式，更多内容可以参考图4及其相关描述。

本说明书一些实施例提供的目标投保特征确定方法，通过获取评估对象的投保特征和关联人的投保特征的加权结果，可以全面地考虑到其历史购买的商业医保情况及理赔情况，更准确地对目标对象进行风险评估。

图6根据本说明书一些实施例所示的基于协同特征确定参保风险的评估值的示例性流程图。在一些实施例中，流程600可以由医疗管理平台230执行。如图6所示，流程600可以包括如下步骤。

步骤610，基于协同平台获取评估对象的协同特征。

协同特征可以指能够用于确定评估对象的参保风险评估值的其他特征数据。在一些实施例中，协同特征可以包括能反应评估对象资产情况的金融协同特征、反应评估对象申请或享受社会救助情况的社会救助协同特征和反应评估对象的车辆出险情况的车辆出险特征等。

协同平台指记录有居民相关协同信息的一个或多个云平台或外部数据库。在一些实施例中，协同平台可以包括金融平台、社会救助平台、交通管理平台等，其中，金融平台可以指记录有居民的金融信息(如存款情况、贷款情况、信用卡使用情况等)的云平台或外部数据库。例如，金融平台可以包括中央银行的居民数据库。社会救助平台可以指记录有居民的社会救助信息(如救助金申领情况、救助物资申领情况等)的云平台或外部数据库。例如，社会救助平台可以包括民政系统的救助发放数据库。交通管理平台可以指记录有居民的车险出险信息(如车辆保险情况、车辆保险出险情况等)的云平台或外部数据库。例如，交通管理平台可以包括车辆管理系统的车辆数据库。

在一些实施例中，医疗管理平台230可以基于协同平台获取评估对象和关联人的协同特征。例如，医疗管理平台230可以根据评估对象的标识信息(如身份ID)从协同平台调取对应的协同特征。在一些实施例中，考虑到协同特征可能涉及对象的隐私信息，协同平台在将评估对象和关联人的协同特征发送至医疗管理平台230之前，可以通过安全计算模型对协同信息进行加密处理，生成不暴露对象的隐私信息的协同特征。关于安全计算模型的更多内容可以参见图7及其相关描述。

在一些实施例中，医疗管理平台230可以基于金融知识图谱获取评估对象及其关联人的金融特征。

金融特征可以是描述对象(如评估对象以及关联人)金融信息的特征，在一些实施例中，金融特征可以包括对象的信用卡总逾期次数、信用卡逾期总金额等。

金融知识图谱可以指基于居民的金融信息构建的语义网络，包括节点数据以及边数据。

金融知识图谱的节点数据可以包括居民节点和金融机构节点，其中，居民节点对应于一个居民，居民节点对应的节点属性可以包括该居民的年龄信息、住址信息等；金融机构节点对应于一个金融机构，金融机构可以指提供金融服务的机构(如银行)，金融机构节点对应的节点属性可以包括金融机构的地址信息等。

金融知识图谱的边数据包括边的类型及边的属性，其中，居民节点之间的边的类型包括表示居民之间住址相同的边(即第二类边)，居民节点与金融机构节点之间的边的类型包括与对应金融机构存在金融业务的边(后续简称为第五类边)。第五类边用于表示居民在对应金融机构办理的信用卡存在逾期情况。在一些实施例中，第五类边的边属性可以包括信用卡逾期次数、信用卡逾期总金额等。在一些实施例中，在获取金融特征时，与评估对象对应的居民节点之间存在第二类边的居民节点对应的人可以被视为关联人。

在一些实施例中，金融知识图谱可以根据第五类边的边属性确定评估对象的金融特征。例如，可以根据评估对象在各个金融机构的信用卡逾期次数、信用卡逾期金额进行叠加计算确定评估对象的信用卡总逾期次数、信用卡总逾期金额作为评估对象的金融特征。在一些实施例中，可以根据评估对象对应的居民节点确定评估对象的关联人，再确定关联人的金融特征，确定方式与确定评估对象的金融特征类似。

在一些实施例中，金融知识图谱可以对评估对象和关联人的金融特征进行加权处理，得到金融协同信息。例如，可以对评估对象和与评估对象居住在一起的关联人的信用卡总逾期次数、信用卡总逾期金额进行加权处理，确定评估对象的金融协同信息(即信用卡总逾期次数的加权结果、信用卡总逾期金额的加权结果)。

在一些实施例中，金融平台在将金融协同信息发送至医疗管理平台230之前，可以基于安全计算模型对金融协同信息进行处理确定金融协同特征。可以理解，通过安全计算模型可以对金融协同信息进行加密处理，生成不暴露对象的隐私信息的金融协同特征向量(简称为金融协同特征)。关于安全计算模型的更多内容可以参见图7及其相关描述。

基于本说明书一些实施例所示的金融平台作为协同平台，可以使协同特征能反应评价对象的综合金融能力，从而在确定参保风险的评估值时可以进一步考虑到评价对象的保费支付能力，提高确定参保风险的评估值的准确性。

在一些实施例中，医疗管理平台230可以通过社会救助知识图谱确定评估对象及其关联人的社会救助特征。

社会救助特征可以是描述对象(如评估对象以及关联人)社会救助信息的特征，在一些实施例中，社会救助特征可以包括对象的免费食品领取频率或次数、领取食品总价值、救助申请频率或次数、救助申请总金额等。

社会救助知识图谱可以指基于居民的社会救助信息构建的语义网络，包括节点数据以及边数据。

社会救助知识图谱的节点数据可以包括居民节点以及救助机构节点。其中，居民节点对应于一个居民，居民节点对应的节点属性可以包括该居民的年龄信息、住址信息等；救助机构节点对应于一个救助机构，救助机构可以指提供社会救助服务的机构(如免费食物领取点)，救助机构节点对应的节点属性可以包括救助机构的地址信息等。

社会救助知识图谱的边数据包括边的类型及边的属性，其中，居民节点之间的边的类型包括表示居民之间住址相同的边(即第二类边)，居民节点与社会救助机构节点之间的边的类型包括表示在社会救助机构领取过免费食品的边(后续简称为第六类边)、表示在社会救助机构提出过救助申请的边(后续简称为第七类边)。

第六类边用于表示居民在社会救助机构领取过免费食品。在一些实施例中，第六类边的边属性包括免费食品的领取频率(或次数)、领取总价值等。例如，居民A去过免费食物领取点B领取过免费食品，还去过免费食物领取点C领取过免费食品，则A和B、A和C都存在一条第六类边。在一些实施例中，如果某居民节点存在多条第六类边，且对应的免费食品的领取频率超过了一定阈值，则可以说明该居民到处去领取过免费食品，可以将该特征作为该居民节点的社会救助特征。

第七类边用于表示居民在社会救助机构提出过救助申请。在一些实施例中，第七类边的边属性可以包括救助申请的频率(或次数)、总金额等。

在一些实施例中，在获取救助特征时，与评估对象对应的居民节点之间存在第二类边的居民节点对应的人可以被视为关联人。

在一些实施例中，社会救助知识图谱可以根据与评估对象对应的居民节点相连的第六类边的边属性和第七类边的边属性确定评估对象的社会救助特征。例如，可以根据评估对象在各个社会救助机构的免费食品领取频率或次数、领取食品价值、救助申请频率或次数、救助申请金额进行叠加计算确定评估对象的免费食品领取总频率或总次数、领取食品总价值、救助申请总频率或总次数、救助申请总金额作为评估对象的社会救助特征。在一些实施例中，可以根据评估对象对应的居民节点确定评估对象的关联人，再确定关联人的社会救助特征，确定方式与确定评估对象的社会救助特征类似。

在一些实施例中，社会救助知识图谱可以对评估对象和关联人的社会救助特征进行加权处理，得到社会救助协同信息。例如，可以对评估对象和与评估对象居住在一起的关联人的免费食品领取总频率或总次数、领取食品总价值、救助申请总频率或总次数、救助申请总金额进行加权处理，确定评估对象的社会救助协同信息(即免费食品领取频率或次数的加权结果、领取食品价值的加权结果、救助申请频率或次数的加权结果、救助申请金额的加权结果)。

在一些实施例中，社会救助平台在将社会救助协同信息发送至医疗管理平台230之前，可以基于安全计算模型对社会救助协同信息进行处理确定社会救助协同特征。可以理解，通过安全计算模型对社会救助协同信息进行加密处理，可以生成不暴露对象的隐私信息的社会救助协同特征向量(简称为社会救助协同特征)。关于安全计算模型的更多内容可以参见图7及其相关描述。

基于本说明书一些实施例所示的社会救助平台作为协同平台，可以使协同特征能反应评估对象的社会救助情况。从而在确定参保风险的评估值时可以进一步考虑到评估对象的社会救助情况，提高确定其参保风险的评估值的准确性。

在一些实施例中，医疗管理平台230可以通过交通管理平台获取评估对象的车辆出险特征。

车辆出险特征可以是描述对象(如评估对象以及关联人)车辆出险信息的特征，在一些实施例中，车辆出险特征可以包括评估对象的车辆出险次数、平均维修金额、平均理赔金额等。

在一些实施例中，交通管理平台可以根据评估对象的标识信息(如身份ID)调用车辆出险信息。在一些实施例中，交通管理平台在将车辆出险信息发送至医疗管理平台230之前，可以基于安全计算模型对车辆出险信息进行处理确定车辆出险特征。可以理解，通过安全计算模型对车辆出险信息进行加密处理，可以生成不暴露对象的隐私信息的车辆出险特征向量(简称为车辆出险特征)。关于安全计算模型的更多内容可以参见图7及其相关描述。

基于本说明书一些实施例所示的车辆管理平台作为协同平台，车辆出险特征作为协同特征，可以在确定参保风险的评估值时可以进一步考虑到评价对象的其他险种的投保与理赔情况，进而提高参保风险的评估值的准确性。

步骤620，基于目标医疗特征、目标投保特征以及协同特征，确定参保风险的评估值。

在一些实施例中，协同特征可以作为参保风险的评估值的一个确定因素。例如，可以根据金融特征、社会救助特征等协同特征预估评估对象的保险费用支付能力，进而调整参保风险的评估值。再例如，可以根据车辆出现出险预估评估对象的出险后的理赔概率进而参保风险的评估值。

在一些实施例中，医疗管理平台230基于风险评估模型对目标医疗特征、目标投保特征以及协同特征进行处理，确定参保风险的评估值。关于风险评估模型的更多内容可以参见图7及其相关描述。

基于本说明书实施例提供的协同特征，可以进一步反应评估对象的相关信息，从而提高参保风险的评估值的精确度。

图7是根据本说明书一些实施例所示的确定参保风险的评估值的示例性示意图。

在一些实施例中，医疗管理平台230可以通过安全计算模型720对目标医疗特征710-1和目标投保特征710-2进行处理，确定目标医疗特征向量730-1和目标投保特征向量730-2。关于目标医疗特征和目标投保特征的更多内容参见图3-图5及其相关描述。

安全计算模型720可以用于提取目标医疗特征向量730-1和目标投标特征向量730-2。在一些实施例中，安全计算模型720可以是机器学习模型。例如，循环神经网络(RNN)。在一些实施例中，安全计算模型720的输入是可以目标医疗特征710-1和目标投保特征710-2，输出可以是目标医疗特征向量730-1和目标投保特征向量730-2。

值得说明的是，目标医疗特征710-1和目标投保特征710-2中包含有大量的评估对象的隐私数据，考虑到医疗信息平台的数据安全问题，医疗信息平台在接收到医疗管理平台的调用请求后，可以通过安全计算模型720对目标医疗特征710-1和目标投保特征710-2进行多方安全计算处理，处理后的目标医疗特征向量730-1和目标投保特征向量730-2可以通过加密后的数据反应评估对象的目标医疗特征，而不涉及评估对象的具体数据。

多方安全计算可以在无可信第三方的前提下保证参与计算的各方成员输入的信息不暴露，且同时能够获得准确的运算结果。在一些实施例中，医疗信息平台、协同平台、医疗管理平台之间可以通过多方安全计算对各自的数据进行加密处理，例如，医疗信息平台可以通过安全计算模型对目标医疗特征和目标投保特征进行加密处理，协同平台可以通过安全计算模型对金融协同信息、社会救助协同信息和车辆出险信息进行加密处理，然后通过风险评估模型对这些加密数据信息处理，计算出参保风险的评估值。

在一些实施例中，医疗管理平台230可以基于风险评估模型740对目标医疗特征向量730-1和目标投保特征向量730-2进行处理，确定参保风险的评估值750。

风险评估模型740可以用于确定评估对象参保风险的评估值。在一些实施例中，风险评估模型740可以是机器学习模型。例如，深度神经网络(DNN)。在一些实施例中，风险评估模型740的输入可以包括目标医疗特征向量730-1和目标投保特征向量730-2，输出可以是参保风险的评估值750。

在一些实施例中，风险评估模型740的输入还可以包括协同特征，如金融协同特征、社会救助协同特征、车辆出险特征等。关于协同特征的更多内容参见图5及其相关描述。

在一些实施例中，风险评估模型740的输入可以是安全计算模型720的输出，即目标医疗特征向量730-1、目标投标特征向量730-2以及协同特征，输出可以是参保风险的评估值750。

在一些实施例中，安全计算模型720可以与风险评估模型740联合训练得到。例如，可以将训练样本输入安全计算模型中，将安全计算模型的输出作为风险评估模型的输入，并基于风险评估模型的输出和构建损失函数，并基于损失函数同时迭代更新安全计算模型和风险评估模型的参数，直到预设条件被满足训练完成。

在一些实施例中，训练样本可以包括样本评估对象的样本目标医疗特征、样本目标投保特征和样本协同特征，训练样本可以基于历史评估数据获取，历史评估数据可以是对样本评估对象的参保风险进行评估的历史数据，标签为样本评估对象参保风险的评估值。例如，可以选定2020年2月2日之前用户A作为样本评估对象，网外云平台可以获取该用户及其关联人在2020年2月2日之前的历史目标医疗特征、历史目标投保特征和历史协同特征并作为安全计算模型的训练样本，以及根据该用户在2020年2月2日之后的理赔情况(如理赔总金额、理赔次数等)确定该用户的参保风险的历史评估值(如理赔总金额较高对应的评估值较高)，并将历史评估值作为该训练样本对应的标签，以进行模型训练。又例如，还可以通过保险机构的工作人员人工对用户A的职业、家庭收入等因素对用户A的历史评估值进行评估。示例性地，对于公司的普通员工，其实际评估值可以为正常值(如评估值在40-60分之间为正常值)；对于职位较高、居住区域较为富裕的人(健康状况通常较好)，其实际评估值可以较低(如评估值在0-40分之间为较低)；对于明确患有较重疾病的人或是从事特殊工种(例如矿工，可能患有职业病的风险)，其实际评估值可以较高(如评估值在60-100分之间为较高)。

在一些实施例中，安全计算模型720可以与风险评估模型740进行联合训练时，可以通过多平台协同进行训练的方式进行，即网络云平台150中的至少一个平台可以与医疗管理平台230协同进行训练。例如，医疗信息平台和金融平台作为多方中的一方，对安全计算模型720可以与风险评估模型740进行联合训练。在进行训练时，医疗信息平台可以先确定样本评估对象及对应的样本关联人，将样本评估对象和样本关联人的信息发送到网络云平台150中的多个平台，以获取样本评估对象和样本关联人的相关样本特征数据(例如，样本金融特征、样本社会救助特征、样本车辆出险特征等)，并将相关样本特征数据输入安全计算模型720中，将安全计算模型720的输出作为风险评估模型740的输入，并基于风险评估模型740的输出和构建损失函数，并基于损失函数同时迭代更新安全计算模型720和风险评估模型740的参数，直到预设条件被满足训练完成。训练结束后，网络云平台中的一个或多个平台可以得到对应的安全计算模型720，医疗信息平台可以得到对应的风险评估模型740。

在一些实施例中，风险评估模型也可以不和安全计算模型联合训练。例如，风险评估模型可以根据提前获取的样本目标医疗特征向量和样本目标投保特征向量进行训练。再例如，风险评估模型可以基于训练好的安全计算模型进行训练。

本说明书实施例提供的确定参保风险的评估值的方法可以通过风险评估模型对目标医疗特征和目标投保特征进行处理，可以准确快速的确定参保风险的评估值。在一些实施例中，通过加入安全计算模型和风险评估模型联合确定参保风险的评估值可以很好的保护评估对象的隐私。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。