基于人工智能的居民呼吸道传染病监测预警系统及方法

1.本发明涉及智能监测技术领域，具体涉及一种基于人工智能的居民呼吸道传染病监测预警系统及方法。


背景技术：

2.知识图谱最先在2012年由google提出，用以描述其搜索引擎从不同来源获得的信息结果。如图2所示，这些信息的结果本质是一个多关系图(multi-relational graph)，由不同的信息(节点) 关系 (边)构成。
3.知识图谱在逻辑上分为数据层和模式层，数据层用来存储真实的数据。模式层在数据层之上，是知识图谱的核心，存储经过提炼的知识。构建知识图谱是一个迭代更新的过程，根据知识获取的逻辑，每一轮迭代包含三个阶段：信息抽取，从各种类型的数据源中提取出实体、属性以及实体间的相互关系，在此基础上形成本体化的知识表达；知识融合，在获得新知识之后，需要对其进行整合，以消除矛盾和歧义，比如某些实体可能有多种表达，某个特定称谓也许对应于多个不同的实体等；知识加工，对于经过融合的新知识，需要经过质量评估之后(部分需要人工参与甄别)，才能将合格的部分加入到知识库中，以确保知识库的质量。
4.现有技术无法解决对于社区特定人群的信息填报内容不全面，工作成本高、效率低，未能提高社区早期监测预警能力的问题。
5.因此本文提供一种基于人工智能的居民呼吸道传染病监测预警系统及方法。


技术实现要素：

6.针对现有技术的不足，本发明公开了一种基于人工智能的居民呼吸道传染病监测预警系统及方法，用于解决对于社区需重点监测人群的信息填报内容不全面，工作成本高、效率低，未能提高社区早期监测预警能力的问题。
7.本发明通过以下技术方案予以实现：
8.第一方面，本发明提供了一种基于人工智能的居民呼吸道传染病监测预警系统，包括
9.交互层，用于接收用户输入的数据、显示查询结果诊断数据和启动数据服务层，实现与群体监测系统的交互；
10.数据服务层，用于提供查询服务，根据存储的真实数据进行提炼得到知识图谱，同时接收数据输入，解释业务规则，并根据业务规则作出业务决策；
11.基础资源层，用于数据加密服务和隐私数据分级保护，同时提供 mysql数据库；
12.源数据层，用于填报数据，为所述数据服务层提供基础数据支撑。
13.更进一步的，所述数据服务层进行实体抽取时，从原始数据语料中自动识别出命名实体，其中实体抽取的方法包括基于百科站点或垂直站点提取、基于规则与词典的方法、基于统计机器学习的方法以及面向开放域的抽取方法。
14.更进一步的，所述基于百科站点或垂直站点提取则是常规基本的提取方法；
15.所述基于规则的方法通常需要为目标实体编写模板，然后在原始语料中进行匹配；
16.所述基于统计机器学习的方法主要是通过机器学习的方法对原始语料进行训练，然后再利用训练好的模型去识别实体；
17.所述面向开放域的抽取方法是面向海量的web语料。
18.更进一步的，所述数据服务层进行语义类抽取时，从文本中自动抽取信息来构造语义类并建立实体和语义类的关联,作为实体层面上的规整和抽象；
19.所述数据服务层进行属性和属性值抽取时，为每个本体语义类构造属性列表，而属性值提取则为一个语义类的实体附加属性值；
20.所述数据服务层进行关系抽取时，目标是解决实体语义链接的问题。
21.更进一步的，所述知识图谱知识表示学习的代表模型包括距离模型、单层神经网络模型、双线性模型、神经张量模型、矩阵分解模型和翻译模型；
22.其中，距离模型，首先将实体用向量进行表示，然后通过关系矩阵将实体投影到与实体关系对的向量空间中，最后通过计算投影向量之间的距离来判断实体间已存在的关系的置信度；
23.双线性模型是通过基于实体间关系的双线性变换来刻画实体在关系下的语义相关性；
24.神经张量模型是在不同的维度下，将实体联系起来，表示实体间复杂的语义联系；
25.transe模型是将知识库中实体之间的关系看成是从实体间的某种平移，并用向量表示。
26.更进一步的，所述知识图谱进行知识融合时包括
27.初步筛选，用于初步筛选融合标识符相同的实体数据；
28.判断属性相似度，用于配置相似属性和相似度函数，并判断数据之间的属性相似度；
29.融合知识：对属性相似度均达到阈值条件的数据进行融合；
30.数据质量的挑战，包括命名模糊、数据输入错误、数据丢失、数据格式不一致和缩写；
31.数据规模的挑战，包括数据量大、数据种类多样性、多种关系、更多链接、不能仅仅通过名字匹配；
32.实体相似度，根据属性相似度向量得到实体的相似度。
33.更进一步的，实体相似度的计算，假设两个实体的记录x和y，x 和y在第i个属性上的值是xi,yi，那么需要通过以下计算：
34.属性相似度：综合单个属性相似度得到属性相似度向量 [sim(x1,y1),sim(x2,y2),
…
,sim(xn,yn)]；
[0035]
其中，属性相似度的计算包括编辑距离、集合相似度和向量相似度；
[0036]
实体相似度的计算包括聚合、聚类和表示学习；
[0037]
其中，聚合，通过对属性相似度向量进行加权平均(w1* sim(x1，y1)
…
wn*sim(xn，yn))得到实体相似度，或者通过手动制定规则的方式(sim(x1，y1)＞t1and(or)
…
sim
(xn，yn)＞ti)；
[0038]
聚类，先将实体聚类成簇，然后计算簇类实体之间的相似度，而不用两两计算相似度；
[0039]
分类，人工标注一批实体match or not的训练数据，然后训练二分类模型。
[0040]
表示学习，利用transe模型将知识图谱中的实体和关系都映射到低维稠密空间向量，然后计算实体相似度。
[0041]
更进一步的，所述知识图谱的存储包括基于表结构的存储和基于图结构的存储；
[0042]
其中，基于表结构的存储，利用二维的数据表对知识图谱中的数据进行存储，包括三元组表、类型表、关系数据库。
[0043]
基于图结构的存储，利用图的方式对知识图谱中的数据进行存储，包括图数据库。
[0044]
更进一步的，所述数据服务层设有规则引擎，所述规则引擎包括
[0045]
正向链接，基于插入的fact对象和fact对象的更新，利用可用的fact推理规则来提取出更多的fact对象，直到计算出最终目标，最终会有一个或多个规则被匹配，并计划执行；
[0046]
反向链接，从规则引擎假设的结论开始，如果不能够直接满足这些假设，则搜索可满足假设的子目标。
[0047]
第二方面，本发明提供了一种基于人工智能的居民呼吸道传染病监测预警方法，包括以下步骤：
[0048]
用户进入社区微信公众号，在手机端登录基于人工智能的居民呼吸道传染病监测预警系统；
[0049]
进入移动端填报界面后，按照界面显示的个人信息、流调史信息以及症状信息等依次填报；
[0050]
针对社区居民填报的多类别症状信息，通过规则引擎及知识图谱进行运算分析，给出初步诊断结果；
[0051]
依据诊断结果给用户返回一个建议反馈信息，用户社区居民会在第一时间看到自己的信息反馈，作出相应的防护措施。
[0052]
本发明的有益效果为：
[0053]
本发明解决了对于社区需重点监测人群的信息填报内容不全面，工作成本高、效率低，未能提高社区早期监测预警能力的问题。同时解决了对社区已知和未知发热伴呼吸道传染病的监测预警问题。
[0054]
本发明通过移动端实现对社区相关人员、社区健康监测人群和重点监测行业工作人员基本信息的自行填报，包括人员的基础信息、基础疾病、流行病学史、症状等信息。信息填报完成提交后，系统依据知识图谱及规则引擎诊断，自动反馈诊疗建议及防护建议。
附图说明
[0055]
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0056]
图1是本发明的系统结构原理图；
[0057]
图2是本发明背景技术一种多关系图；
[0058]
图3是本发明实施例知识图谱的体系架构图；
[0059]
图4是本发明实施例的知识融合图；
[0060]
图5是本发明实施例知识图谱的检索图。
具体实施方式
[0061]
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0062]
实施例1
[0063]
参照图1所示，本实施例提供了一种基于人工智能的居民呼吸道传染病监测预警系统，包括
[0064]
交互层，用于接收用户输入的数据、显示查询结果诊断数据和启动数据服务层，实现与群体监测系统的交互；
[0065]
数据服务层，用于提供查询服务，根据存储的真实数据进行提炼得到知识图谱，同时接收数据输入，解释业务规则，并根据业务规则作出业务决策；
[0066]
基础资源层，用于数据加密服务和隐私数据分级保护，同时提供 mysql数据库；
[0067]
源数据层，用于填报数据，为所述数据服务层提供基础数据支撑。
[0068]
本实施例系统将知识图谱及规则引擎诊断应用到呼吸道传染病智能预警和监测领域，尤其是流感以及未知的呼吸道传染病等疾病方面。
[0069]
本实施例通过部署在社区的本系统移动端应用程序，可以快速地向社区及居民预警可能出现呼吸道传染病，并进行防护。
[0070]
实施例2
[0071]
在实施1的基础上，参照图3所示，本实施例提供一种知识图谱其中虚线框内的部分为知识图谱的构建过程，也包含知识图谱的更新过程。
[0072]
本实施例大规模知识库的构建与应用需要多种技术的支持。通过知识提取技术，可以从一些公开的半结构化、非结构化和第三方结构化数据库的数据中提取出实体、关系、属性等知识要素。
[0073]
本实施例知识表示则通过一定有效手段对知识要素表示，便于进一步处理使用。然后通过知识融合，可消除实体、关系、属性等指称项与事实对象之间的歧义，形成高质量的知识库。
[0074]
本实施例知识推理则是在已有的知识库基础上进一步挖掘隐含的知识，从而丰富、扩展知识库。分布式的知识表示形成的综合向量对知识库的构建、推理、融合以及应用均具有重要的意义。
[0075]
本实施例知识抽取主要是面向开放的链接数据，通常典型的输入是自然语言文本或者多媒体内容文档(图像或者视频)等。然后通过自动化或者半自动化的技术抽取出可用的知识单元，知识单元主要包括实体(概念的外延)、关系以及属性3个知识要素，并以此为
基础，形成一系列高质量的事实表达，为上层模式层的构建奠定基础。
[0076]
本实施例实体抽取也称为命名实体学习(named entity learning) 或命名实体识别(named entity recognition)，指的是从原始数据语料中自动识别出命名实体。由于实体是知识图谱中的最基本元素，其抽取的完整性、准确率、召回率等将直接影响到知识图谱构建的质量。因此，实体抽取是知识抽取中最为基础与关键的一步。
[0077]
本实施例可以将实体抽取的方法分为4种：基于百科站点或垂直站点提取、基于规则与词典的方法、基于统计机器学习的方法以及面向开放域的抽取方法。基于百科站点或垂直站点提取则是一种很常规基本的提取方法；基于规则的方法通常需要为目标实体编写模板，然后在原始语料中进行匹配；基于统计机器学习的方法主要是通过机器学习的方法对原始语料进行训练，然后再利用训练好的模型去识别实体；面向开放域的抽取将是面向海量的web语料。
[0078]
本实施例语义类抽取是指从文本中自动抽取信息来构造语义类并建立实体和语义类的关联,作为实体层面上的规整和抽象。以下介绍一种行之有效的语义类抽取方法，包含三个模块：并列度相似计算、上下位关系提取以及语义类生成。
[0079]
本实施例属性提取的任务是为每个本体语义类构造属性列表，而属性值提取则为一个语义类的实体附加属性值。属性和属性值的抽取能够形成完整的实体概念的知识图谱维度。常见的属性和属性值抽取方法包括从百科类站点中提取，从垂直网站中进行包装器归纳，从网页表格中提取，以及利用手工定义或自动生成的模式从句子和查询日志中提取。
[0080]
本实施例关系抽取的目标是解决实体语义链接的问题。关系的基本信息包括参数类型、满足此关系的元组模式等。
[0081]
本实施例传统的知识表示方法主要是以rdf(resource deionframework资源描述框架)的三元组spo(subject,property,object)来符号性描述实体之间的关系。这种表示方法通用简单，受到广泛认可，但是其在计算效率、数据稀疏性等方面面临诸多问题。
[0082]
本实施例知识表示学习的代表模型有距离模型、单层神经网络模型、双线性模型、神经张量模型、矩阵分解模型、翻译模型等。
[0083]
本实施例距离模型提出了知识库中实体以及关系的结构化表示方法(structured embedding，se)，其基本思想是：首先将实体用向量进行表示，然后通过关系矩阵将实体投影到与实体关系对的向量空间中，最后通过计算投影向量之间的距离来判断实体间已存在的关系的置信度。由于距离模型中的关系矩阵是两个不同的矩阵，使得协同性较差。针对上述提到的距离模型中的缺陷，提出了采用单层神经网络的非线性模型(single layer model，slm)。
[0084]
本实施例双线性模型主要是通过基于实体间关系的双线性变换来刻画实体在关系下的语义相关性。模型不仅形式简单、易于计算，而且还能够有效刻画实体间的协同性。
[0085]
本实施例神经张量模型，其基本思想是：在不同的维度下，将实体联系起来，表示实体间复杂的语义联系。神经张量模型在构建实体的向量表示时，是将该实体中的所有单词的向量取平均值，这样一方面可以重复使用单词向量构建实体，另一方面将有利于增强低维向量的稠密程度以及实体与关系的语义计算。
[0086]
本实施例通过矩阵分解的方式可得到低维的向量表示，故不少研究者提出可采用该方式进行知识表示学习，其中的典型代表是resacl 模型。在rescal模型中，知识库中的
三元组集合被表示为一个三阶张量，如果该三元组存在，张量中对应位置的元素被置1，否则置为0。通过张量分解算法，可将张量中每个三元组(h,r,t)对应的张量值解为双线性模型中的知识表示形式lh的t次幂
×
mr
×
lt并使|xhrt-lh 的t次幂
×
mr
×
l|尽量小。
[0087]
本实施例transe模型，即将知识库中实体之间的关系看成是从实体间的某种平移，并用向量表示。transe模型在大规模稀疏知识库上也同样具有较好的性能和可扩展性。
[0088]
参照图4所示，本实施例知识融合，即合并两个知识图谱(本体)，基本的问题都是研究怎样将来自多个来源的关于同一个实体或概念的描述信息融合起来。由于知识图谱中的知识来源广泛，存在知识质量良莠不齐、来自不同数据源的知识重复、知识间的关联不够明确等问题，所以需要进行知识的融合。
[0089]
本实施例知识融合是高层次的知识组织，使来自不同的知识源的知识在同一框架规范下进行异构数据整合、消歧、加工、推理验证、更新等步骤，达到数据、信息、方法、经验以及人的思想的融合，形成高质量的知识库。
[0090]
本实施例初步筛选：知识融合需要初步筛选融合标识符相同的实体数据。
[0091]
本实施例判断属性相似度：初步筛选融合标识符相同的数据后，需要配置相似属性和相似度函数，并判断数据之间的属性相似度。
[0092]
本实施例融合知识：对属性相似度均达到阈值条件的数据进行融合。
[0093]
本实施例不同知识图谱间的实体对齐是kg融合的主要工作。在不同文献中，知识融合有不同的叫法，如本体对齐、本体匹配、recordlinkage、entity resolution、实体对齐等。
[0094]
本实施例知识融合的主要技术挑战为两点：
[0095]
数据质量的挑战：如命名模糊、数据输入错误、数据丢失、数据格式不一致、缩写等。
[0096]
数据规模的挑战：数据量大(并行计算)、数据种类多样性、多种关系、更多链接、不能仅仅通过名字匹配。
[0097]
本实施例中，实体对齐必然涉及到实体相似度的计算，假设两个实体的记录x和y，x和y在第i个属性上的值是xi,yi，那么需要通过两步计算：
[0098]
属性相似度：综合单个属性相似度得到属性相似度向量 [sim(x1,y1),sim(x2,y2),
…
,sim(xn,yn)]。
[0099]
实体相似度：根据属性相似度向量得到实体的相似度。
[0100]
本实施例中，属性相似度的计算有多种方法，常用的有编辑距离、集合相似度(jaccard系数、dice)、向量相似度(余弦相似度、欧氏距离)等。
[0101]
本实施例中，实体相似度的计算有多种方法，比如聚合、聚类、表示学习等。
[0102]
聚合：可以通过对属性相似度向量进行加权平均(w1* sim(x1，y1)
…
wn*sim(xn，yn))得到实体相似度，或者通过手动制定规则的方式(sim(x1，y1)＞t1 and(or)
…
sim(xn，yn)＞ti)。
[0103]
聚类：即先将实体聚类成簇，然后计算簇类实体之间的相似度，而不用两两计算相似度。
[0104]
分类：人工标注一批实体match or not的训练数据，然后训练二分类模型。
[0105]
表示学习：利用transe模型将知识图谱中的实体和关系都映射到低维稠密空间向
量，然后计算实体相似度
[0106]
本实施例知识推理，就是利用图谱中现有的知识(三元组)，得到一些新的实体间的关系或者实体的属性(三元组)。
[0107]
本实施例中，实际构建的知识图谱，通常存在不完备的问题，即部分关系或属性会缺失。知识补全，就是通过算法，补全知识图谱中缺失的属性或者关系。
[0108]
本实施例中，实际构建的知识图谱还可能存在错误知识。其中，实体的类型、实体间的关系、实体属性值均可能存在错误。知识图谱的纠错是一个极具挑战的任务。这些错误会影响知识图谱质量，进而影响基于知识图谱的应用。我们可以通过推理进行知识图谱纠错。
[0109]
本实施例中，基于知识图谱的推理问答也是知识图谱推理的典型应用。基于知识图谱的问答，一般简称为kbqa。与传统的信息检索式问答相比，kbqa可以具备一定的推理能力，这是它的优势。基于知识图谱的推理问答，通常应用于涉及多个实体，多个关系，多跳，比较等相对复杂的问答场景中。
[0110]
本实施例知识推理/知识图谱的推理，指的是从给定的知识图谱推导出新的实体跟实体之间的关系，可以分为基于符号的推理和基于统计的推理。
[0111]
本实施例基于规则的推理就是说，可以抽象出一系列的规则，将这些规则应用于知识图谱中，进行补全纠错。这种思路也是很简单、直观的。基于规则的推理的优点是，推理结果精准，并且具有可解释性。因此规则推理在学术界和工业界都有广泛的应用。
[0112]
本实施例本体推理和规则推理，都是基于离散符号的知识表示来推理的。它们具有强逻辑约束，准确度高、易于解释等优点。但是不易于扩展。基于表示学习的推理，通过映射函数，将离散符号映射到向量空间进行数值表示，同时捕捉实体和关系之间的关联，再在映射后的向量空间中进行推理。
[0113]
本实施例知识图谱的目标是构建一个能够刻画现实世界的知识库，为自动问答、信息检索等应用提供支撑。因此，对知识的持久化存储并提供对目标知识的高效检索是合格的知识图谱必须具备的基本功能。
[0114]
本实施例按照存储方式的不同，知识图谱的存储可以分为基于表结构的存储和基于图结构的存储。
[0115]
本实施例基于表结构的存储：利用二维的数据表对知识图谱中的数据进行存储：三元组表、类型表、关系数据库。
[0116]
本实施例基于图结构的存储：利用图的方式对知识图谱中的数据进行存储：图数据库。
[0117]
本实施例三元组表：知识图谱中的事实是一个个的三元组，一种最简单直接的存储方式是设计一张三元组表用于存储知识图谱中所有的事实。
[0118]
本实施例类型表：为每种类型构建一张表，同一类型的实例存放在相同的表中。表的每一列表示该类实体的一个属性，每一行存储该类实体的一个实例。
[0119]
本实施例关系数据库以二维表结构对数据进行组织和存储。
[0120]
属性(attribute)：表中的每一列称为一个属性(字段)，用来描述实体集的某个特征。每个属性都有自己的取值范围，称为域。
[0121]
元组(tuple)：表中的每一行由一个实体的相关属性取值构成，称为元组(记录)，
它相对完整地描述了一个实体。元组中的一个属性值称为分量。
[0122]
本实施例基于图结构的存储，将实体看做节点，关系看做带有标签的边，那么知识图谱的数据很自然地满足图模型结构。
[0123]
本实施例图数据库基于有向图，其理论基础是图论。节点、边和属性是图数据库的核心概念。
[0124]
本实施例节点用于表示实体、事件等对象，可以类比于关系数据库中的记录或数据表中的行数据。例如人物、地点、电影等都可以作为图中的节点。
[0125]
本实施例边是指图中连接节点的有向线条，用于表示不同节点之间的关系。例如人物节点之间的夫妻关系、同事关系等都可以作为图中的边。
[0126]
本实施例属性用于描述节点或者边的特性。例如人物的姓名、夫妻关系的起止时间等都是属性。
[0127]
本实施例关系数据库查询：sql语言。sql语言从功能上可以分为四个部分：数据查询、数据操纵、数据定义和数据控制
[0128]
本实施例图数据库查询：sparql语言。sparql是simple protocoland rdf query language的缩写，是由w3c为rdf数据开发的一种查询语言和数据获取协议，是被图数据库广泛支持的查询语言。和sql 类似，sparql也是一种结构化的查询语言，用于对数据的获取与管理。
[0129]
实施例3
[0130]
在实施1的基础上，参照图5所示，本实施例提供一种规则引擎，其由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接收数据输入，解释业务规则，并根据业务规则作出业务决策。
[0131]
本实施例规则引擎整合了传入系统的fact集合和规则集合，从而去触发一个或多个业务操作。规则通常以声明式的方式在业务代码中实现，我们可能以为它很少会被改变。但事实上，这些业务逻辑的判断条件经常会被改变。
[0132]
在实施例中的业务逻辑或规则，通常是可以表示为“在某些条件下，执行某些任务”。在拥有大量规则和fact对象的业务系统中，可能会出现多个fact输入都会导致同样的输出，这种情况我们通常称作规则冲突。规则引擎可以采用不同的冲突解决方案来确定冲突规则的执行顺序。
[0133]
本实施例规则引擎中，通常有两种执行方式：
[0134]
正向链接：这是一种基于“数据驱动”的形式，基于插入的fact 对象和fact对象的更新，规则引擎利用可用的fact推理规则来提取出更多的fact对象，直到计算出最终目标，最终会有一个或多个规则被匹配，并计划执行。因此，规则引擎始于事实，始于结论。
[0135]
反向链接：这是一种基于“目标驱动”或推理形式，与正向链接相反。反向链条从规则引擎假设的结论开始，如果不能够直接满足这些假设，则搜索可满足假设的子目标。规则引擎会循环执行这一过程，直到证明结论或没有更多可证明的子目标为止。
[0136]
本实施例规则与过程的不同之处主要在于：业务流程代表业务做了什么；规则引擎代表决定做什么业务。规则引擎可以被视为复杂的 if/then语句解释器。被解释的if/then语句称为规则。规则的 if部分用于处理条件，比如account.getmoney()《0；规则的
then 部分包含执行的操作，比如sendwarning(account)。
[0137]
本实施例规则存储在正向链接规则引擎中，即引擎执行一个执行周期，该周期允许一个规则的操作触发其他规则的条件得到满足。这样，级联的规则会被激活，同时每条规则的操作都会被执行。正向链接的规则引擎适用于从简单输入(fact)得出高层次的结论的场景。
[0138]
本实施例一个规则文件是由两个概念组成：
[0139]
规则：用于控制业务流程的声明式语句。一个规则通常包含判断条件部分和执行操作部分。如果条件评估结果为true，则执行规则引擎操作部分。
[0140]
fact：规则执行所需要的数据。在上面的示例中account便是fact 对象。
[0141]
使用规则引擎可以给系统带来如下优势：
[0142]
高灵活性：在规则保存在知识库中，可以在规则变动轻易做出修改。
[0143]
容易掌控：规则比过程代码更易于理解，因此可以有效地来弥补业务分析师和开发人员之间的沟通问题。
[0144]
降低复杂度：在程序中编写大量的判断条件，很可能是会造成一场噩梦。使用规则引擎却能够通过一致的表示形式，更好的处理日益复杂的业务逻辑。
[0145]
可重用性：规则集中管理，可提高业务的规则的可重用性。而且，传统的代码程序通常会添加不必要的变数，很然进行重复利用。
[0146]
实施例4
[0147]
本实施例提供了一种基于人工智能的居民呼吸道传染病监测预警方法，包括以下步骤：
[0148]
用户进入社区微信公众号，在手机端登录基于人工智能的居民呼吸道传染病监测预警系统；
[0149]
进入移动端填报界面后，按照界面显示的个人信息、流调史信息以及症状信息等依次填报；
[0150]
针对社区居民填报的多类别症状信息，通过规则引擎及知识图谱进行运算分析，给出初步诊断结果；
[0151]
依据诊断结果给用户返回一个建议反馈信息，用户社区居民会在第一时间看到自己的信息反馈，作出相应的防护措施。
[0152]
综上，本发明解决了对于社区需重点监测人群的信息填报内容不全面，工作成本高、效率低，未能提高社区早期监测预警能力的问题。同时解决了对社区已知和未知发热伴呼吸道传染病的监测预警问题。
[0153]
本发明通过移动端实现对社区相关人员、社区健康监测人群和重点监测行业工作人员基本信息的自行填报，包括人员的基础信息、基础疾病、流行病学史、症状等信息。信息填报完成提交后，系统依据知识图谱及规则引擎诊断，自动反馈诊疗建议及防护建议。
[0154]
以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。