医疗数据结构化处理方法、装置及设备

技术领域

本发明涉及信息处理技术领域，特别是涉及医疗数据结构化处理方法、装置及设备。

背景技术

医院提供的电子病历数据一般都是采用自然语言描述患者的情况，比如主诉是什么症状、既往得过什么疾病，信息量丰富。为了利用信息量丰富的电子病历进行后续规则的编写，通常会希望能够从自然语言中抽取出数字化的信息，比如：将自然语言表达的主诉中的疾病与icd10疾病标准进行对应。

对于自然语言的处理大致分为两类：一是分类，二是结构化预测。结构化预测问题包括将病历结构化，指将医院的电子病历全量信息做集中处理，以得到结构清晰的病历信息，让病历信息格式化，利于查看。如从病历中抽取包含疾病、症状、手术等多种专业属性较强的信息，以及时间、动作、医生姓名等日常用语的信息。

然而在将病历结构化的过程中，通常需要对病历中的数据进行分词处理，但由于病历中的术语书写随意，所以往往会出现词典外的词，这样的词就无法提取，即会出现OOV(Out of Vocabulary)问题。如此，会造成病历结构化过程失败。

因此，如何减少源代码的修改及生成发布、使分词更加准确并解决OOV问题以及让病历信息格式化，是本领域技术人员急需解决的技术问题。

发明内容

本发明提供了一种医疗数据结构化处理方法、装置及设备，能够减少源代码的修改及生成发布、使分词更加准确并解决OOV问题以及让病历信息格式化。

本发明提供了如下方案：

一种医疗数据结构化处理方法，包括：

利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据；

利用分词工具基于预先构建的基库对所述半结构化的中间数据进行分词处理，获取分词结果，所述预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个；

采用预设模型根据与所述分词结果中每一分词对应的标注规则分别对所述每一分词进行序列标注，生成结构化的目标数据。

可选地，所述预设规则引擎包括根据java代码和groovy编写的规则引擎。

可选地，所述利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据包括：

对所述待处理数据进行预处理；

获取需要解析的字段及字段规则，根据所述字段规则从预处理后的所述待处理数据中获取所述字段对应的值，生成键值对格式的半结构化的中间数据。

可选地，所述预先构建的基库包括多个层级及多类信息。

可选地，所述分词工具包括jieba分词工具。

可选地，所述分词结果包括每一分词对应的词性，所述采用预设模型根据与所述分词结果中每一分词对应的标注规则分别对所述每一分词进行序列标注，生成结构化的目标数据包括：

确定所述分词结果中每一分词对应的标注规则；

根据对应的所述标注规则以及所述词性对每一分词进行序列标注，生成结构化的目标数据。

可选地，所述预设模型包括隐马尔科夫模型、结构化感知机和条件随机场中的一种或几种。

一种医疗数据结构化处理装置，包括：

解析模块，用于利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据；

分词模块，与所述解析模块连接，用于利用分词工具基于预先构建的基库对所述半结构化的中间数据进行分词处理，获取分词结果，所述预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个；

标注模块，与所述分词模块连接，用于采用预设模型根据与所述分词结果中每一分词对应的标注规则分别对所述每一分词进行序列标注，生成结构化的目标数据。

一种医疗数据结构化处理设备，包括存储器和处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，当所述计算机程序被所述处理器执行时，实现所述的数据结构化处理方法。

一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被执行时，实现所述的数据结构化处理方法。

根据本发明提供的具体实施例，本发明公开了以下技术效果：

本发明提供的医疗数据结构化处理方法，首先利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据。其中，待处理数据包括病历的全量数据。不同的医院的病历类型不尽相同，病历类型包括门诊病历、住院病历、手术病历和出院病历等，不同的医院的病历全量格式也不尽相同，病历全量格式包括txt、html及xml等。对于不同医院的不同病历类型的不同病历全量格式，本发明在预设规则引擎中配置一套自适应的全量解析规则，将已有的病历全量信息通过对应的预设规则进行解析，得到更加清晰的病历信息，预设规则可以通过不同医院的不同类型做灵活的配置，减少源代码的修改及生成发布。然后，利用分词工具基于预先构建的基库对半结构化的中间数据进行分词处理，获取分词结果，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个。通过分词工具将包含全量信息的待处理数据分成基础词得到分词结果。最后，采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据，其中，序列标注包括对每一分词进行标注和将标注后的所有分词排列组合形成结构化的目标数据。预设模型可以通过统计的方式进行预测，通过标注完成的分词，可以得到专有名词组合的规律，并形成统计结果，从而得到结构化的目标数据。因此，通过本发明提供的数据结构化处理方法优化了病历结构化过程，并顺利地输出结构化数据。

进一步地，由于病历中存在随意书写的口语化词汇，这样的口语化词汇与基库中的专业术语无法匹配，也即OOV问题。为了解决这一问题，本发明通过将基库中的语料标注后，得到的信息不是一个具体的词与另一个具体的词的统计信息，而是一个词的抽象特征，即词性，进一步通过学习训练后得到的是词性之间结合的统计信息，所以只要词性关系合理，即可进行提取，从而通过提升抽象层次的方式具备了泛化能力，解决了OOV问题。

当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例提供的医疗数据结构化处理方法的流程框图；

图2是本发明另一个实施例提供的医疗数据结构化处理方法的流程框图；

图3是本发明又一个实施例提供的医疗数据结构化处理方法的流程框图；

图4是本发明一个实施例提供的医疗数据结构化处理装置的结构框图；

图5是本发明一个实施例提供的医疗数据结构化处理设备的架构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

下面对本发明实施例提供的具体实现方案进行详细介绍。

本发明提供一种医疗数据结构化处理方法，采用规则引擎对待处理数据进行解析，在此基础上，结合分词工具和算法模型进行分词和序列标注，来实现数据的结构化处理，来解决传统的结构化过程中分词无法识别专有名词术语的问题，使病历结构化并顺利输出结构化目标数据。

实施例一

图1是本发明一个实施例提供的医疗数据结构化处理方法的流程框图。如图1所示，本实施例提供了一种医疗数据结构化处理方法，该方法具体可以包括以下步骤：

S10：利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据；

S20：利用分词工具基于预先构建的基库对半结构化的中间数据进行分词处理，获取分词结果，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个；

其中，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个，基本能够涵盖病历中可能出现的所有词汇，进一步地，该预先构建的基库包括若干基础词和与基础词对应的标注，在构建过程中基于已有的基础词和标注训练得到该预先构建的基库。

S30：采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据。

本实施例提供的医疗数据结构化处理方法，首先利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据。其中，待处理数据包括病历的全量数据。不同的医院的病历类型不尽相同，病历类型包括门诊病历、住院病历、手术病历和出院病历等，不同的医院的病历全量格式也不尽相同，病历全量格式包括txt、html及xml等。对于不同医院的不同病历类型的不同病历全量格式，本发明在预设规则引擎中配置一套自适应的全量解析规则，将已有的病历全量信息通过对应的预设规则进行解析，得到更加清晰的病历信息，预设规则可以通过不同医院的不同类型做灵活的配置，减少源代码的修改及生成发布。然后，利用分词工具基于预先构建的基库对半结构化的中间数据进行分词处理，获取分词结果，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个。通过分词工具将包含全量信息的待处理数据分成基础词得到分词结果。最后，采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据，其中，序列标注包括对每一分词进行标注和将标注后的所有分词排列组合形成结构化的目标数据。预设模型可以通过统计的方式进行预测，通过标注完成的分词，可以得到专有名词组合的规律，并形成统计结果，从而得到结构化的目标数据。因此，通过本发明提供的数据结构化处理方法优化了病历结构化过程，并顺利地输出结构化数据。

由于病历中存在随意书写的口语化词汇，这样的口语化词汇与基库中的专业术语无法匹配，也即OOV问题。为了解决这一问题，本发明通过将基库中的语料标注后，得到的信息不是一个具体的词与另一个具体的词的统计信息，而是一个词的抽象特征，即词性，进一步通过学习训练后得到的是词性之间结合的统计信息，所以只要词性关系合理，即可进行提取，从而通过提升抽象层次的方式具备了泛化能力，解决了OOV问题。

业务系统的每次发布都是重量级的操作，要经历代码拉取、编译打包、原应用关停、分发服务器及应用启动等一系列动作，可以通过引入自动化发布工具来减轻这一操作，但是自动化发布工具的引入需要花费很高的成本。为了降低成本，现有技术中采用一些可以免去发布且可以让逻辑即时生效的手段，例如：直接使用动态预言如python开发，无需编译打包的过程即可实时生效，但是对于企业级应用，无法在生产环节直接更改逻辑。对此，本申请提供了一种预设规则引擎来解决上述问题。

具体地，预设规则引擎包括根据java代码和groovy编写的规则引擎。其中，java代码编写的部分是静态的，groovy编写是的部分是灵活的。在编译期只建立整体逻辑框架，对于存在灵活逻辑的地方，更改为定制化代码，如groovy，在不变和变化之间寻求平衡，不变的部分使用静态语言如Java，变化部分使用可即时编译生效的脚本语言如Groovy。如此，既可以免去发布且可以让逻辑即时生效，也可以在生产环节直接更改逻辑。

进一步地，对于Groovy本身还可以进行一些封装，形成新的DSL(Domain SpecificLanguage)。DSL可以是代码形式，也可以是配置形式，从而可以减少业务人员的工作量。

具体地，在一个实施例中，预设规则引擎首先分析业务逻辑，提取中逻辑主干部分，并使用java代码编写主干部分，然后识别灵活的逻辑部分，确定灵活逻辑部分所需业务上下文Context，在Groovy概念中使用Binding对象表达，在Drools中有类似概念称为Fact，在Java代码中使用集成Groovy，在Jvm中运行脚本语言Groovy，接着使用规则管理封装Groovy，创建一个规则对象，创建规则集对象，预设规则引擎运行，将编译结果进行缓存，输出结果。其中，由于Groovy语言每次编译都有开销，所以对编译结果进行缓存，以免下次重复编译，以提升性能。

其中，在Java代码中使用集成Groovy有三种方式，分别如下：

1.基于shell脚本，这种方式最轻量，按照Groovy语法编写的编程语言即可。

2.基于通用基础类，这种方法需要指定类文件地址，其中HisScript就是类文件名，带上后缀的全名为HisScript.groovy。

3.基于groovy的类加载器

其中，规则对象的属性包括规则id、规则名称、规则描述、规则序号、规则优先级、父规则、子规则、前序规则、后续规则及上下文类型。具体地，一个规则可属于一个或多个规则集，用规则序号表示，如果在同一个规则集中同时满足触发条件，则可以规则序号判断执行顺序，当优先级相同时，则随机执行。规则之间存在继承关系，对于父规则的逻辑一些属性，子规则默认继承。前序规则表示执行本规则前需要立刻执行的前序规则，后续规则表示执行本规则后需要立刻执行后续规则。规则所需要的上下文有不同的类型，是一个Java类，通常一个具体业务中，上下文的类型是确定的，上下文类型也可以存在父子关系。

其中，规则集对象是一组规则的集合，也具备自身属性，包括：规则集id、规则集名称、优先级、业务id、独占标识。具体地，优先级表示规则执行的顺序，业务id表达具体属于哪个业务，如病历结构化，或两核风控，独占标识表达同一业务中多个规则集之间的互斥关系。

其中，预设规则引擎运行的具体过程如下：待处理数据传入后，根据业务id，进入不同的业务逻辑，选择不同的规则集；校验是否仅存在一独占规则，或不存在任何规则，若即不存在独占规则也不存在任何规则，则根据规则集优先级，进行规则集执行顺序的编排；根据规则集内部规则的优先级及前序后续依赖关系，进行规则执行顺序的编排，注意优先级及前后续依赖关系是存在冲突的可能性的，此时需要解决循环依赖的问题，如遇循环依赖，一种方式是在编排过程就进行快速失败处理，另一种方式是在建立规则的时候进行循环依赖的判断；规则执行的中间数据和结果都可以放在具体的Binding对象之中。需要注意的是，规则入参不可改变，参考函数式编程思想，入参应为final标识数据，但final修饰符其实无法对引用类型对象的value起效，所以仍然存在被修改的可能，因而在不强制限定的情况下，需要由规则引擎控制。

采用java代码和groovy编写的规则引擎灵活性较高，但是安全性得不到保障，因而需要对权限进行严格的控制，并且在编写规则引擎时进行验证，验证的方式有：1.对于规则中的上下文类型，使用枚举形式提供，在Java代码中，可作为上下文的类统一继承自一个RuleEngineContextRoot接口，该接口表达该类是一个上下文对象，进一步地，Spring项目启动时，扫描RuleEngineContextRoot接口的子类，将这些子类放于内存中，供页面下来枚举选择；2.将规则生命周期拆分成规则编写、规则验证、规则生效和规则回滚，规则编写阶段是于页面中进行规则编写，此时可将规则保存为草稿，仅为文本内容，未执行；规则验证分为安全性验证及可运行验证，安全性验证时在规则引擎中设定黑白名单操作，严格限制Groovy中可调用的类和方法，可运行验证时后台会进行Groovy类的编译尝试，以及使用伪造的Binding对象对规则进行执行，如果无法成功编译或运行，则说明规则语法异常，验证不通过，只有规则验证通过，才可进行规则生效操作，生效后的规则可于运行期执行，规则每修改生效一次，后台均会对上一个版本的规则留存，并标识操作人、操作时间、备注等信息，另外可基于规则版本进行回滚。另一种保证Groovy安全的方法是在测试环境中进行规则编写及验证，验证后进行生产发布，这种方式流程安全，轻快灵便。

需要特别说明的是，本发明提供的预设规则引擎与现有的规则引擎具有诸多区别。例如：现有的规则引擎一般都是使用When...Then结构表达规则，若满足When，则执行Then，但是在实际应用场景中通常无需此结构，因此，本发明提供的预设规则引擎没有采用When...Then结构表达规则，当需要使用此结构时，直接在规则体中写if语句即可实现；现有的规则引擎中如果上下文内容改变，则意味着Fact更新，这会导致规则需要重新执行，由于实际应用场景中较少出现这一情况，因此，本发明提供的预设规则引擎不进行此设定，从而可以实现轻量化；现有的规则引擎不强制进行规则安全及可用性验证，而本发明提供的预设规则引擎需要强制进行规则安全及可用性验证，可进行预检查，提升了开发效率；现有的规则引擎引入页面脚本功能，通常不具备缓存能力，而本发明提供的预设规则引擎具有缓存能力，提升了性能；现有的规则引擎的上下文对象不进行类型校验，而本发明提供的预设规则引擎结合Java反射机制进行上下文对象的明确定义。

图2是本发明另一个实施例提供的医疗数据结构化处理方法的流程框图。如图2所示，在一个具体的实施例中，利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据包括：

S11：对待处理数据进行预处理；

其中，对待处理数据的预处理包括格式转换和首尾字截取等，格式转换例如将HTML转换称为txt文本格式，首尾字截取是通过首尾字进行字符串截取。

S12：获取需要解析的字段及字段规则，根据字段规则从预处理后的待处理数据中获取字段对应的值，生成键值对格式的半结构化的中间数据。

其中，键值对格式包括MAP键值对格式，半结构化的中间数据由标签字段加标签值的键值对构成，通过对应键值对获取对应标签内容。根据字段规则从预处理后的待处理数据中获取键值对格式的半结构化的中间数据包括：通过Groovy处理自定义代码，通过在页面上写入的自定义代码，处理全量信息，得到目标字段内容，然后判断是否存在补充代码，若存在，则通过Groovy处理补充代码。

在一个实施例中，利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据还包括：通过对应正则等方式对待处理数据进行处理获取全量时间，以及基于已有的科室名称，通过详细字段对比获取待处理数据包括的所有科室信息，得到待处理数据对应的科室。

在一个具体的实施例中，预先构建的基库包括多个层级及多类信息，例如药品基库中包括药品名、通用名、剂型、成分等信息。

在一个具体的实施例中，分词工具包括jieba分词工具，基于词典及最大概率路径进行分词，词典来自于基库及基于基库得到的更细力度的基础词。

图3是本发明又一个实施例提供的医疗数据结构化处理方法的流程框图。如图3所示，在一个具体的实施例中，分词结果包括每一分词对应的词性，采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据包括：

S31：确定分词结果中每一分词对应的标注规则；

S32：根据对应的标注规则以及词性对每一分词进行序列标注，生成结构化的目标数据。

在一个具体的实施例中，序列标注是对一组输入{x1,x2,...,xn}进行{y1,y2,...,yn}的标注，x是序列中的每一个元素，y则是输出。在自然语言处理中，x序列就是一段自然语言文本，y则是一套标注规则。

基库由语料训练后得到，语料包括医学描述以及对医学描述中专有术语的标注，相同语料可用于不同模型的训练，通过大量语料进入不同机器学习模型进行训练，并观测其准确率及召回率。对于不同的基库可以采用不同的标注方式，例如，对于疾病基库，将其拆分为疾病性质、疾病部位、病理状态等，对于药品基库，将其拆分为药品成分、药品剂型等，对于手术基库，将其拆分为手术部位、手术病因、手术方法、手术特定词等。通过语料标注后得到的信息是一个词的抽象特征，即词性。在一个实施例中，语料的标注如下表1所示：

表1

在一个具体的实施例中，以疾病为例，假设输入的待处理数据为“患者半年前检查发现伤寒性脑膜炎”，通过分词和序列标注后，输出的结构化的目标数据将为“患者/n半年前/t检查/v发现/v(伤寒性/nyjx脑膜/nyjb炎/nyjz)/nyj/w”。

在一个具体的实施例中，预设模型通过统计的方式进行预测，通过标注完成的语料，我们可以得到专有名词组合的一定规律，并形成统计结果。优选地，预设模型包括隐马尔科夫模型、结构化感知机和条件随机场中的一种或几种。以隐马尔科夫模型为例，通过大量的语料学习后，会生成一张二维“转移频次矩阵”表，如下表2示出了以疾病为例的“转移频次矩阵”，“转移频次矩阵”表达了各个标签之间的概率转移关系，如“疾病性质”后是“疾病部位”的频次是300，“疾病部位”后是“疾病病理状态”的频次是200。

表2

进一步地，“转移频次矩阵”表还可以人工优化，例如，可以手动设置频次的权重。根据经验可以知道疾病部位后紧跟疾病病理状态的概率会大于其他情况，因此，如果手动设置权重，则可将疾病部位、病理状态之间的权重手动设定为1.2倍，从而可以在语料数量不足的情况下，体现人工干预的能力。

在一个具体的实施例中，以“病毒性脑膜炎”为语料，首先进行分词，识别得到“病毒性”，词性是nyjx，然后识别得到“脑膜”，词性是nyjb，再识别出“炎”，词性是nyjz。接着，基于预设模型得到，nyjx后紧跟nyjb是合理的组合，及nyjb后紧跟nyjz是合理的组合，将其三者组合为一个完整的词，也即结构化的目标数据。从而通过提升抽象层次的方式具备了泛化能力，解决了oov问题。

再进一步地，可以使用分类报告及混淆矩阵对以上预设模型进行评分，评估不同模型的性能，进行模型选择，并持续进行语料的学习反馈提升模型性能。

更进一步地，分类报告及混淆矩阵是对模型性能的表示，包含查准率、召回率、F1-Score三项评分指标。

实施例二

图4是本发明一个实施例提供的医疗数据结构化处理装置的结构框图。如图4所示，本实施例提供一种医疗数据结构化处理装置，用于实现上述实施例提供的数据结构化处理方法，在本实施例中，数据结构化处理装置包括解析模块10、分词模块20和标注模块30。解析模块10用于利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据。分词模块20与解析模块10连接，用于利用分词工具基于预先构建的基库对半结构化的中间数据进行分词处理，获取分词结果，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个。标注模块30与分词模块20连接，用于采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据。

本实施例提供的医疗数据结构化处理装置，首先利用预设规则引擎根据对应的预设规则对待处理数据进行解析，获取半结构化的中间数据。其中，待处理数据包括病历的全量数据。不同的医院的病历类型也不尽相同，病历类型例如门诊病历、住院病历、手术病历和出院病历等，不同的医院的病历全量格式也不尽相同，病历全量格式例如txt、html及xml等。对于不同医院的不同病历类型的不同病历全量格式，本发明在预设规则引擎中配置一套自适应的全量解析规则，将已有的病历全量信息通过对应的预设规则进行解析，得到更加清晰的病历信息，预设规则可以通过不同医院的不同类型做灵活的配置，减少源代码的修改及生成发布。然后，利用分词工具基于预先构建的基库对半结构化的中间数据进行分词处理，获取分词结果，预先构建的基库包括疾病基库、手术基库、药品基库、诊疗基库以及材料基库中的一个或多个。通过分词工具将包含全量信息的待处理数据分成基础词得到分词结果。最后，采用预设模型根据与分词结果中每一分词对应的标注规则分别对每一分词进行序列标注，生成结构化的目标数据，其中，序列标注包括对每一分词进行标注和将标注后的所有分词排列组合形成结构化的目标数据。预设模型可以通过统计的方式进行预测，通过标注完成的分词，可以得到专有名词组合的规律，并形成统计结果，从而得到结构化的目标数据。因此，通过本发明提供的数据结构化处理方法优化了病历结构化过程，并顺利地输出结构化数据。

由于病历中存在随意书写的口语化词汇，这样的口语化词汇与基库中的专业术语无法匹配，也即OOV问题。为了解决这一问题，本发明通过将基库中的语料标注后，得到的信息不是一个具体的词与另一个具体的词的统计信息，而是一个词的抽象特征，即词性，进一步通过学习训练后得到的是词性之间结合的统计信息，所以只要词性关系合理，即可进行提取，从而通过提升抽象层次的方式具备了泛化能力，解决了OOV问题。

关于实施例二没有详述的部分，请参见上述实施例一。

实施例三

对应上述方法，本发明还提供了一种医疗数据结构化处理设备，包括：

处理器和存储器，存储器上存储有可在处理器上运行的计算机程序，当计算机程序被处理器执行时，执行上述任意一个实施例提供的医疗数据结构化处理方法。

其中，图5示例性的展示出了医疗数据结构化处理设备，具体可以包括处理器1510，视频显示适配器1511，磁盘驱动器1512，输入/输出接口1513，网络接口1514，以及存储器1520。上述处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520之间可以通过通信总线1530进行通信连接。

其中，处理器1510可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本发明所提供的技术方案。

存储器1520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1520可以存储用于控制电子设备运行的操作系统1521，用于控制电子设备的低级别操作的基本输入输出系统(BIOS)。另外，还可以存储网页浏览器1523，数据存储管理系统1524，以及设备标识信息处理系统1525等等。上述设备标识信息处理系统1525就可以是本发明实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本发明所提供的技术方案时，相关的程序代码保存在存储器1520中，并由处理器1510来调用执行。

输入/输出接口1513用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口1514用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线包括一通路，在设备的各个组件(例如处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，与存储器1520)之间传输信息。

另外，该电子设备还可以从虚拟资源对象领取条件信息数据库中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器1510、视频显示适配器1511、磁盘驱动器1512、输入/输出接口1513、网络接口1514，存储器1520，总线等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本发明方案所必需的组件，而不必包含图中所示的全部组件。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

实施例四

在本实施例中还提供计算机可读存储介质，计算机可读存储介质内存储有计算机程序，计算机程序被执行时，实现上述任意一个实施例提供的医疗数据结构化处理方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本发明所提供的技术方案，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。