基于OpenEHR电子健康记录的临床研究患者筛选工具:开发研究

简介

临床研究是以患者为主要研究对象，以疾病的诊断、治疗和预后为重点的科学研究活动。临床研究中研究对象的确定是主要挑战之一。一项研究[1在114项接受调查的临床研究中，只有35项(31%)能够按计划完成患者筛查。在研究方案的设计过程中，研究人员为符合条件的患者制定详细的条件。过去，研究人员通过询问临床医生或手动发布招募广告来收集符合条件的患者，但这是一项劳动密集型和耗时的任务，对小型临床研究有帮助。电子健康记录(EHR)的广泛采用使EHR数据能够用于临床研究。

然而，将电子病历数据用于临床研究还存在许多障碍。临床数据碎片化和专有的健康信息系统使采用某些特定的筛查方法成为一项挑战[2-6］．这些方法每次都需要研究人员、临床医生和信息技术人员之间进行详细的沟通。因此，由于沟通错误，这是一个耗时且容易出错的过程[7］．只有少数电子病历供应商采用健康信息标准并采用受控术语[8］．研究人员必须将查询需求表达为关键字，以从电子病历中选择患者[9-12］．由于这些情况，临床研究需要基于电子病历的查询工具。基于表单的查询界面，例如整合生物学和床边的信息学(i2b2) [13]，为电子病历查询提供了一个有前景的方向。这些接口通过为内置编码概念提供受控的查询输入，部分满足了查询需求。然而，复杂的筛选条件不能有效和准确地表达这种方式，特别是对于派生概念。Wagholikar等[14]提出派生概念只能用结构化查询语言(Structured Query Language, SQL)来表达，这是一项具有挑战性的任务。SQL缺乏特定领域的高级表达式，这使得研究人员难以表达这些派生概念。此外，这些查询接口，如i2b2，大多被视为临床数据仓库，通过星型模型存储EHR数据。在面对子查询和连接查询时，基于关系数据库的查询工具效率低下[15］．

因此，基于标准化和可扩展的临床数据存储库(CDR)的以用户为中心的高水平表达的患者筛选工具可以促进EHR数据在临床研究中的使用。OpenEHR被认为是一种很有前途的工具，可以帮助建立CDR，并支持复杂筛查条件的表达。它从临床内容中提供了一种新的形式化建模范式[16］．它的几个特点使它在帮助建立临床研究的患者筛选工具方面很有吸引力。首先，它提供了开放的、语义支持的、基于标准的、独立于供应商的、与用例无关的信息模型来表示临床概念[17］．它在跨模板的许多特定临床用例中重用现有原型，以减少时间和精力，实现不同系统之间的语义互操作性。该特性为CDR的开发奠定了坚实的基础。有人提出了一些基于openehr的话单研究[18-20.］．其次，openEHR将模型分为原型模型(AM)和参考模型(RM)。AM可以用来表示领域知识。在AM中，许多编码值集或编码词汇表可以从受控术语资源中提取[21-25］．工程师只需要专注于基于RM的软件开发，便于维护性[26］．通过这种方式，开发人员可以为特定的需求提供不同的实现。此外，它还提供了openEHR openEHR表达式语言(EL) [27]来指定原型规则和决策表达式。OpenEHR EL可用于表示结合编码概念的高级查询表达式。领域特定语言在许多用例中显示出了前景。因此，与SQL相比，openEHR EL使临床研究人员可以查询EHRs。

然而，openEHR如何应用于临床研究的患者筛查仍是一个悬而未决的问题。具体来说，需要解决两个问题:缺乏高级表达式和低效查询。因此，在本研究中，openEHR EL用于为查询提供高级表达式，特别是派生概念。同时，由于这些派生概念由简单的概念和复杂的约束组成，因此会生成低效的查询。因此，Elasticsearch (ES) [28]用于构建用于患者筛查的底层CDR。通过为相应的原型和模板生成层次索引，我们的方法避免了执行连接查询和子查询。据我们所知，在使用ES的基于openehr的cdr中，几乎没有针对复杂医疗概念的查询工具。

本文其余部分的结构如下。我们的方法在材料和方法一节中提出。在收集了查询需求后，提出了一种基于原型和openEHR EL的符合条件的表示方法。然后，使用ES生成基于原型的层次索引。最后，开发了一个筛选工具来支持患者筛选任务。结果部分给出了筛选条件表示和执行性能评估。讨论部分描述了我们的方法的贡献，以及一些相关问题和未来的发展方向。最后，总结结论。

方法

需求收集

由于临床研究中由于请求碎片化、利益冲突、安全等原因难以收集实际的查询需求，我们将临床试验作为临床研究的代表案例。临床试验是一种实验，旨在回答有关可能的新治疗方法或使用现有(已知)治疗方法的新方法的特定问题。为分析临床研究筛查需求，从中国临床试验注册中心(ChiCTR)收集了截至2020年1月1日的389项脑卒中相关临床试验[29]，包括2178项纳入标准和2513项排除标准，共计4691项筛查标准。本文将这些条件作为查询需求。

筛选条件表述

患者筛选工具的主要功能之一是将自由文本中的筛选条件转换为计算机可读的表达式。罗斯等人[30.]分析了筛选条件的组成和结构。翁等[31]调查了临床试验中资格标准的正式表现。在这些研究中可以使用许多表示方法。发展患者筛查的主要考虑因素之一是使其在筛查条件的表示和电子病历中的数据表示之间兼容。

OpenEHR被提出来表示电子病历中的数据结构。EL是openEHR规范的一部分，用于指定原型规则和决策语言表达式。OpenEHR EL基于OpenEHR信息模型，与电子病历中的结构一致。因此，我们的研究使用openEHR EL来表示筛选条件。OpenEHR EL为不同类型的操作提供了完整的算术操作符、关系操作符、逻辑操作符，以及关于时间和集合的有限操作。这些操作人员在某些情况下不符合复杂筛查条件的要求(例如，对于符合“化疗和放疗后白细胞计数在特定时间内持续下降”要求的患者)。

因此，为了表示筛选条件，我们的方法可以分为两部分:

1. 直接从openEHR原型和模板定义概念
2. 根据临床需求，通过openEHR EL生成概念

表示筛选条件的过程如图所示图1．

‎ 查看此图

筛选概念定义

筛选条件由医学概念和相关约束条件构成。针对电子病历中筛选概念与数据项不匹配的问题，设计了一种基于openEHR原型和模板定义筛选概念的方法，用于构建电子病历中的数据结构。通过这种方式，可以将筛选条件以与ehr一致的方式表示，从而提高筛选效果。对于筛选概念的管理和复杂约束的表示，需要定义相关属性，如表1．

OpenEHR原型为临床概念定义了完整的领域内容，这些内容松散地绑定到属性和约束，以考虑设计中的通用性和可重用性。模板是一个或几个原型的合理组合，可以进一步加以约束。因此，openEHR模板用于直接定义筛选概念。概念定义的规则如下:

1. 模板对应于具有详细约束的原型，例如本地可选性、默认值。因此，它被认为是一个概念集。模板中的每个属性节点都映射到概念集下的子概念。
2. 当模板中的属性节点映射到一个概念时，该节点的本体名称被视为概念的名称。节点的数据类型被用作概念的类型，openEHR模板中节点的路径被映射到概念的路径。对于不同概念之间的层次关系，父属性可以通过前面的子路径来标识，因为这些路径可以被视为这些属性的标识符。
3. 对于DV_QUANTITY属性，属性“units”可以映射到概念的单元属性。
4. 对于DV_CODED_TEXT属性，属性“defining_code”可以映射到这个概念下的子概念。此属性定义可以来自不同的术语服务。因此，对于同一个子概念，DV_CODED_TEXT属性的概念下可能存在多个数据项。
5. 对于其他数据类型，仅根据步骤2将相关节点项映射为筛选概念。

对于筛选概念的StartTime和EndTime，从模板中提取是没有意义的。由于这些时间属性与特定的临床事件相关，因此在筛选患者时可以将其指定为临床概念。例如，实验室测试可能包含几个关于时间的概念，如结果时间、测试时间、样品收到日期和时间。根据不同的应用场景或不同研究人员的理解，可以将一个白细胞计数的概念绑定到不同的起始时间和结束时间。

筛选概念生成

虽然有些概念可以直接根据openEHR模板的规则定义，但在实际情况中，仍存在一些复杂的概念和约束条件，无法从这些模板中导出，例如“白细胞计数在化疗和放疗后的特定时间内继续下降”。对于约束“减少”，没有现成的表达式或操作符可以表示它。此外，化疗一般由相关药物指示，如阿曲他明、苯达莫司汀、氮胞苷等，而不是直接保存在EHRs中。这些表达，如化疗，需要结合现有的概念和限制来指定。

OpenEHR EL用于表示基于模板的复杂约束。应用openEHR EL生成定制概念需要在ehr中声明变量、绑定变量和数据项，并定义简单概念的逻辑表达式。

为了声明变量，openEHR EL支持变量声明、赋值和表达式。因此，定制的概念可以以变量的形式生成。例如，可以生成化疗，如图所示图2．

在概念定义筛选过程中实现了openEHR模板与概念的映射，电子病历的结构来源于原型和模板。因此，导出的概念是自定义的，可以直接作为EL表达式中的变量来实现隐式绑定。

‎ 查看此图

这些定制的概念由逻辑表达式和直接从模板定义的概念组成。根据约束类型的不同，定制方式可分为三种:

1. 第一种方法是用算术运算符约束已定义的概念。例如，身体质量指数(BMI)不会直接出现在电子病历中。根据这种情况筛选患者，BMI定义为“BMI:=体重/身高^2”。
2. 另一种方法是使用关系运算符生成定制的概念。例如，可以产生认知障碍，如图3．迷你精神状态测试(MMSE)是一种广泛使用的认知功能测试。任何24分或更低(满分30分)的分数都表示认知异常。这种知识可以是临床研究人员对中风的直觉，但不能通过筛查工具识别。
3. 复杂的定制概念可以通过组合算术运算符或逻辑运算符的条件链来生成。图4给出了一个例子。认知障碍诊断概念可以直接从问题/诊断模板中定义。两种测试量表用于测量不同程度的认知障碍。通过结合这三种表达方式，新的定制概念可以帮助筛选更多符合条件的患者，准确率更高。

‎ 查看此图

‎ 查看此图

在生成定制概念时，还需要考虑其他问题。其中一个问题是生成嵌套的概念。由于有些概念比较复杂，仅从模板定义的简单概念无法满足临床场景的需求。在这些情况下，首先需要生成中间概念，然后根据这些中间概念表达定制的概念。例如，虽然肥胖/超重可以在openEHR模板中定义，使用来自国际疾病分类第十版(ICD-10)的特定术语，编号为E66，但某些表达式可以在语义上被视为相同的标准，如下所示图5．

‎ 查看此图

关于筛选概念的约束

openEHR EL提供的运算符满足表示存在、算术、逻辑和关系约束的最大要求。在某些情况下，表示关于集合和时间的约束是一个挑战。

藏品的筛选条件非常灵活。一般来说，知识工程师需要为特定的临床需求定义这些约束条件。对于不同的医疗机构，甚至不同的临床医生，对这些限制的理解可能是不同的。因此，根据收集到的筛选条件，为方便起见，预定义了一些约束条件，如图所示表2．

为了进一步约束一些概念集，筛选工具支持临床研究自定义新的约束和编辑现有的约束，除了使用预定义的约束。

艾伦等[32]总结了比较两个事件的13种时间表示模式。它们由我们工具中的表达式表示，如表3．

这些时间限制在某些情况下无法满足要求，例如，“患者在48小时内接受了肝素治疗。”根据对采集标准的分析，在Allen等人[]的基础上，在我们的工具中引入了“interval”属性。32]模式来表示不同临床事件之间的间隔，例如，“diff([concept1].”StartTime， [concept2]. endtime) [><=] Interval "。

通过结合这些扩展约束和Allen等人提出的13种模式[32]，大多数筛选条件可以表示为时间约束。例如，“病人在48小时内接受肝素治疗”可以用两种方式表示，如图所示图6．

‎ 查看此图

执行筛选条件

不同于直接硬编码筛选表达式和约束的方法，如i2b2, ANother Tool for Language Recognition (ANTLR) [33用于解析openEHR EL表达式。此外，还实现了一个转换器，将筛选条件转换为底层查询语言。解耦设计采用openEHR两级建模机制，易于维护。

大多数基于openehr的话单基于关系数据库[19，20.］．由于数据分散在多个表中，因此不可避免地要引入多表连接和子查询。为了提高查询性能，本研究决定使用专用的搜索引擎来执行查询。ES可以在短时间内存储、搜索和分析大量数据，作为分布式搜索引擎可以满足患者筛查的性能要求。与关系数据库类似，每个类型化字段都可以被索引和查询。该体系结构是为在图7．

‎ 查看此图

数据作为文档存储在ES中，文档的模式是通过映射定义的。索引类似于数据库，类型类似于关系数据库中的表结构。ES文档以键值对的形式存储数据，文档也可以作为值的类类型来实现分层存储。为了在索引中查询EHR数据，本研究提出了一种将openEHR模板映射到索引结构的方法。

具体来说，openEHR模板用于生成符合Java持久性应用程序编程接口(API)或JPA的相应实体[34]，根据一系列规则。然后，根据hibernate搜索提供的es相关注释，描述实体和索引之间的映射关系[35］．最后，使用现有的hibernate搜索框架生成索引结构的模式。流程图如图所示图8．

‎ 查看此图

映射规则定义

映射规则决定了索引的详细结构，对性能有重要影响。模板索引映射规则可以分为以下几个部分:

1. 数据类型映射
2. 层次关系映射
3. 命名策略

需要一个组合原型和相应的模板作为导入其他原型的容器，包括人口统计学、影像学检查、实验室测试、问题诊断、用药顺序和程序。组合模板被设计成ES中的单个索引。对应筛选条件的定义，属性节点和层次关系是映射过程中的重点。

数据类型映射

openEHR模板属性的数据类型是在RM中定义的，由于ES的每个字段都有一个类型，因此每个RM需要添加相应的字段类型注释来映射到相应的实体对象类型。表4显示常用数据类型和实体之间的映射关系。

字段注释不仅决定ES中的数据类型，还决定在这些字段中执行索引和文本处理的分析器。所有数据类型都映射为三种字段类型:

1. GenericField:根据hibernate搜索提供的策略，为特定的属性类型使用默认字段类型和分析器。
2. KeywordField:它仅适用于其值被视为单个关键字的字符串字段。因此，它适用于受术语限制的诊断、实验室检查、影像学检查等。
3. FullTextField:与KeywordField相比，数据被视为自由文本，因此这只适用于字符串字段。文本被分割成几个标记作为索引。这里，对于DV_CODED_TEXT和DV_TEXT中的字符串字段，添加了两种字段注释，以便以不同的方式进行查询。

层次关系映射

组合模板只对应于一个索引结构。导入的原型在这个索引中生成层次关系。具有基本数据类型的属性，如字符串、int和date，可以作为值字段进行索引。这些导入的原型和底层的槽型原型以及集合类型的属性被索引为对象字段。几个Java Persistence实体是根据这些原型构建的。具体规则如下:

1. 每个原型都对应于一个包含索引注释的主实体对象。
2. 插槽原型和集合类型属性映射到主实体中的新嵌入实体。然而，这两种类型之间存在着区别。一个槽型原型可以被视为一个独立的医学概念，并被视为一个正常的对象字段，这意味着在索引期间它的所有属性都是平坦的。对于集合类型的属性，它通常附加到主要的医学概念，不能单独使用。因此，它被映射到一个嵌套的字段类型，可以在原型中保持原始结构。
3. 每个生成的实体都有一个标识文档的ID字段。
4. 每个生成的实体都用时间戳字段进行标记，该字段被视为比较的主要时间标记，可以在数据集成期间指定。
5. openEHR RM中定义的每个字段类型都被视为一个嵌入式实体。

命名策略

1. 原型数据类型中的属性名称是根据Java字段名预先定义的。特别是，Java字符串字段，它被两个注释，KeywordField和FullTextField，被映射到两个名为“{Java字段名}_keyword”和“{Java字段名}_text”的字段。
2. 对于直接在条目原型中的属性，名称是用原型的本体部分中提到的文本名称定义的。这个文本用“_”连接。为了在索引中进行唯一标识，每个属性的名称都以原型概念名称作为前缀;例如，openEHR-EHR-EVALUATION.problem_diagnosis中的“Body site”。v1将以“problem_diagnosis_Body_site”命名。
3. 对于槽型和集合型原型中的属性，名称由两部分决定:一是这些直接的父原型;另一个是在组合模板中导入的条目原型。对于多个级别的原型，名称是递归提供的。

筛选工具的开发

基于上述提出的方法和需求分析，我们使用openEHR开发了一个电子病历患者筛选工具。系统架构如图所示图9．我们的工具使用了一种松散耦合的体系结构，其中所有模块都是松散连接的，这样就可以更容易地维护和替换它们。具体来说，系统主要分为三个部分:

1. 概念编辑和管理:通过定义和生成来实现筛选概念的维护和管理。临床研究人员可以根据具体需求编辑和修改这些概念。
2. 筛选条件的构建/执行:为用户提供一个易于操作的可视化界面来编辑筛选条件，然后使用restful api在ES中执行查询。
3. 筛选配置结果:针对不同的数据需求，研究者可以在表单中预定义特定的数据视图。该模块通过自定义视图更方便地访问筛选结果。

‎ 查看此图

概念编辑与管理

该模块的主要功能是对筛选概念进行管理，并提供基于openEHR模板和openEHR EL的概念生成功能，使用户能够快速实现筛选概念与EHR数据的映射。

用于ehr的OpenEHR模板从模板库中获得，并由OpenEHR社区提供的工具进行解析[36］．根据获得的模板生成筛选概念。由于电子病历系统所使用的模板是用于日常医疗保健的，因此部分模板并不需要用于临床研究。因此，这些模板和相关节点可以根据实际情况进行选择。基本概念可以从这些模板定义，复杂的或派生的概念应该由基本概念生成，约束应该由openEHR EL提供，如图10．

‎ 查看此图

筛选条件施工/执行

筛选条件的构建/执行是该筛选工具的核心组成部分，研究人员用它正式构建筛选条件。根据筛选条件，通过调用ES提供的restful API来执行查询。

提供图形化编辑界面以支持筛选条件的构建。它的目的是以层次的形式组织构件来完成构造。筛选条件可以分为不同的组，对应不同的视觉成分。每个筛选概念都被填充到一个单独的组中。有意义的反馈是必要的，因为研究人员不知道电子病历中的确切数据。在构建筛选条件时，立即查询每组筛选条件的结果个数，以支持条件的修订。默认情况下，组通过逻辑连词连接。逻辑分离可以在组内使用。对于筛选概念的单个组，只需拖动充满必要信息的可视组件即可添加多个约束。可以在不同的组之间添加时间约束控件。 The user interface is shown in图11．

筛选条件包含复杂的收集和时间限制。用户可以根据自己的需要定义自定义的约束可视化组件。通过定义的可视化组件，生成对应的openEHR EL表达式来表示复杂条件，如图所示图12．

每次筛选条件都是从零开始构建的。这是不必要和耗时的，因为有些条件在一定程度上似乎是相似的，例如包含相同概念的条件。因此，我们的工具提供了保存构造的筛选条件以便执行后重用的功能。之后，用户可以重复使用筛选条件，无需再次施工。这些筛选条件以分层形式保存，所需的筛选条件在当前条件的相应级别上进行拖放。

‎ 查看此图

‎ 查看此图

筛选配置结果

筛选结果的查看可以帮助研究者查看所选患者的详细信息，从而进一步判断患者是否符合要求。一些研究平台通常使用病例报告表(CRF)来记录患者数据。我们的工具依赖于已开发的CRF生成服务，以帮助研究人员定制患者的结果表单，以便他们可以根据特定的需求查看信息。

结果

表征实验

在基于国内某三级甲等医院的openEHR CDR中进行了实验。总共从收集的389个临床试验中随机选择500个句子来分析和评估所提出的工具的有效性。一名临床医生和两名信息技术人员参加了实验。临床医生有责任在面对不同意见时提供医学领域的知识并给出可靠的证明。其中一个信息技术人员负责openEHR的问题，另一个是该工具的核心开发人员。

在这份CDR中，从34个openEHR模板中直接定义了超过30,000个概念。这些概念被用来表示上面提到的500个合格标准。在这些条件下，共找到589个概念。在发现的概念中，513个(87.1%)概念可以被表示，471个概念可以直接从模板中定义。此外，可配置操作需要生成42个概念，并且仍然存在表示76个概念的挑战。表5显示已配置概念的部分。

同时，我们还在i2b2 web客户端中进行了实验，以找出我们的工具与客户端之间的差异。通过比较所提供的查询函数，给出了两者之间的差异表6(Y表示是，N表示否)。

绩效评估

执行了一个评估来验证我们方法的查询性能。使用的数据来自之前提到的医院。EHRs存储了日常医疗服务过程中产生的所有信息，其中一部分是管理和收费信息，这些信息不是临床研究所需要的。因此，总共选择了七个原型和相关模板，包括人口统计、检查和实验室测试。所选模板显示在表7．考虑到数据的敏感性和数据整合的复杂性，仅提取与脑血管疾病相关的数据，包括人口学数据95226条、入院数据449880条、体征信息4239454条、实验室检测数据58322990条、订单信息12966659条、诊断信息158240条、影像检查数据176798条。数据存储结构基于原型关系映射生成[19]和我们的模板索引映射方法，如图13而且图14,分别。

‎ 查看此图

‎ 查看此图

测试用例在Windows 10中执行，使用16GB RAM和Inter(R) Core (TM) i5-4590 CPU，包括Microsoft SQL Server 2014-12.0.2269.0和Elasticsearch-7.11.1。

我们的研究选择了6个筛选条件作为测试用例，每个测试用例在两个测试环境中测试了5次，以消除意外错误。筛选条件的执行时间分为两部分:表达式的翻译时间和底层持久化层中的查询时间。所选的六个测试用例显示在表8．

这些测试用例的测试结果显示在表9(用于原型关系映射)和表10(用于模板索引映射)。他们的比较结果如图15．

‎ 查看此图

测试结果表明，两种方法获得的筛选结果数量相同，可以认为所提出的筛选工具能够正确获得筛选结果。

考虑到查询性能，一般来说，有索引的SQL查询优于没有索引的SQL查询。对于使用SQL (Query1和Query2)而没有连接的查询，表中的数据越多，执行时间就越长。此外，在连接三个表甚至四个表时，查询时间会迅速增加(Query3、Query4、Query5)。

至于使用ES执行，它在没有连接的查询(如Query1和Query2)中并没有显示出明显的优势。但是，对于与连接相关的查询，ES的性能优于SQL查询，因为患者数据是用单个文档编制的，不需要在不同文档之间进行连接，而且性能更稳定。同时，搜索引擎的执行时间与筛选条件的翻译时间之间只存在很小的差距。考虑到EHR数据在磁盘上的容量和在内存中运行的翻译，翻译时间对查询性能有严重影响。因此，还有很大的改进空间。

在两种方法之间的比较中，我们研究中的筛选执行方法比基于sql的方法表现出更好的性能，特别是在多表连接(Query4和Query5)的筛选上下文中。

讨论

主要结果

我们提出了一个使用openEHR的患者筛选工具，将筛选条件转换为ehr查询的表达式。该工具旨在支持在本地上下文中直接查询电子病历。综上所述，我们的工具具有以下特点:

• 首先，该工具支持从openEHR原型和模板定义和生成。这些概念可以是简单概念和派生概念。在以前的研究中，许多工具只是基于一些术语提供了一个固定的概念集。虽然提出了相关的概念扩展研究，但这些扩展的概念只能通过SQL表达式添加，这对临床研究人员来说是一个很大的挑战。
• 其次，与基于sql的方法相比，该工具提高了筛选性能。随着电子病历中数据的不断增加，在这些情况下查询存在严重的瓶颈。我们的方法提出了一个openEHR AMs的实现，以促进基于ES的查询增强。对于设计其他不局限于临床研究的查询工具具有一定的借鉴意义。
• 第三，该工具为openEHR社区在临床研究中二次使用电子病历提供了一个有前途的解决方案。据我们所知，还没有基于openEHR的这样的工具。我们的研究表明，尽管openEHR规范主要是为EHR环境设计的，但它们可以以本研究提出的方式用于临床研究。虽然我们的方法是在openEHR的上下文中提出的，但其他的信息模型也可以转化为openEHR信息模型，这一点已经被之前的研究证明了[37］．这样，我们的方法可以用于这些信息模型。

表达复杂概念的能力

根据表征实验的结果，我们的方法可以表征87.1%的概念。此外，由于筛选条件复杂，有76个概念(12.9%)未表达成功。一些原因如下:

• 首先，没有合适的原型或模板可以用来生成这些概念。换句话说，EHR信息模型没有涵盖必要的基本概念。此外，由于差异，我们的模板无法识别条件中出现的概念。对于这类问题，需要鼓励为特定的需求开发更多的原型和模板。另外，应该在模板中引入更多的本地知识。
• 其次，有些概念不是以结构化的方式出现的。如“严重冠脉狭窄”多记录在影像学检查的描述中。在这些情况下，不能直接从openEHR模板定义用于筛选的概念。这个限制可以通过两种方式解决。一种是像i2b2那样。自然语言处理(NLP)可以从医学文本中提取新概念，并在查询时与原始文本建立映射关系，以便回溯。另一种方法是独立处理这些医学文本，可以提出新的策略来查询文本和结构化数据。
• 第三，这些条件中提到的一些概念是粗粒度和模糊的。由于知识背景和考虑因素的不同，很难定义一个全面的表达式来满足所有查询的所有要求。例如，在“被诊断患有可能导致吞咽困难的疾病的患者”这一条件中，很难表示“疾病”。“疾病”的定义是笼统的，涉及许多概念。导致吞咽困难的疾病可以有不同的类型，包括脑/神经系统疾病、肌肉疾病和食道疾病。定义的结果可以是一个大列表。此外，不同的部门侧重于不同类型的疾病。例如，中风、帕金森氏症和其他脑/神经系统疾病在精神科被考虑。肿瘤科在发现吞咽困难时倾向于考虑食管癌。筛选条件中概念的一般描述是常见的，它们在阻碍准确查询方面起着重要作用。

局限性和未来发展方向

可视化编辑工具可以减轻研究人员的负担，但仍然需要一定的手工工作。例如，这些工具提供了一些模块，例如重用现有条件以方便使用。从零开始开发新的筛选条件仍然是不可避免的，特别是对于复杂的条件和以前没有使用过的条件。随着NLP技术的不断发展，自由文本中的筛选条件可以自动转换为可执行的查询，如本文中的SQL或openEHR EL表达式。

斯塔布斯等[38]提出了使用电子病历进行患者筛查的任务。部分参赛者[39，40]使用基于规则的方法、神经网络等，使用文本数据来确定哪些患者符合标准。一些研究[41-44通过信息提取将条件转换为计算机可解释的格式。Criteria2Query [45]提供自然语言界面，帮助找到符合条件的患者。此外，还提出了一些文本转sql的方法来对电子病历执行查询[46］．这通过预测关于数据库的给定条件的SQL查询来减少工作负载。

这些研究在一定程度上极大地减轻了研究人员的负担，使人们能够以熟悉的方式构建查询。他们的工作减少了与系统/数据库或管理员的广泛交互问题。然而，考虑到极其复杂的条件，端到端流程阻碍了人工参与。同时，对于条件与EHR数据之间的概念不匹配，他们没有提供一个可用的解决方案。

考虑到NLP技术和本文提出的方法的优势，我们未来的方向是结合机器学习方法、基于规则的方法和工程学来改进EHR查询。它们的组合将胜过任何单一方法。

结论

在本文中，我们使用openEHR开发了一个用于临床研究的患者筛选工具。该工具有助于解决概念不匹配的问题，特别是对于派生概念。与基于sql的方法相比，ES的使用提高了查询性能。该工具应用于中风相关的临床研究，并显示出前景。此外，我们还展示了一种使用openEHR二次使用EHR数据的有前途的解决方案。在未来，我们将通过利用NLP技术来增强该工具，使简单和派生概念的自动查询公式成为可能，以进一步减轻研究人员的负担。