可扩展AI应用程序部署(FHIR-DHP)的标准化临床数据协调管道:验证和可用性研究

介绍

医疗保健的日益数字化产生了大量的临床数据，这些数据被收集并存储在电子健康记录(EHR)中。来自所有医疗领域的患者信息被捕获在独立系统中记录的不同数据集中。随着电子病历在医疗机构中的广泛使用，电子病历数据在临床和转译研究中的额外应用有大量的机会。例如，这些数据可用于开发人工智能(AI)算法，这有可能改变患者护理和医学研究。通过人工智能应用对历史数据的分析，可以优化资源密集、效率低下的临床工作流程[1，2]。特别是，人工识别和招募合适的患者参加临床试验的耗时和经济上昂贵的过程可以通过自动化大大减少[3.，4]。然而，由于IT基础设施过时、数据格式不一致、数据质量差、数据交换解决方案不足和数据孤岛等原因，医疗保健提供者之间缺乏数据互操作性，医疗数据的交换仍然有限[5，6]。要实现数据互操作性，必须结合以下步骤:(1)集成孤立的数据孤岛;(2)安全交换数据;(3)有效利用可用数据[7]。这些操作包括数据库模式匹配[8]和模式映射[9]，它允许转换源数据库和目标数据标准之间的关系。

采用统一的数据格式将促进医疗数据的交换，从而在私营和公共卫生保健部门内实现广泛的数据驱动协作。数据互操作性要求EHR数据以通用格式和标准化术语进行结构化。标准化通常通过采用健康级别7快速医疗保健互操作性资源(FHIR)模型来实现[10]，得到众多医疗机构和临床信息系统供应商的支持[11]。FHIR是一种国际工业标准，它将各种数据集集成在定义良好的可交换信息片段中，这些信息片段被称为FHIR资源。因此，FHIR促进了医疗保健组织之间的互操作性，并允许第三方开发人员提供可以轻松集成到现有系统中的医疗应用程序。FHIR能够协调数据，从而实现标准化的数据处理，并在不同的诊所和医院推出人工智能应用程序，而不管它们使用哪种信息系统。因此，FHIR是人工智能在诊所和医院可扩展开发和部署的重要组成部分。

然而，要应用人工智能，输入数据需要适应人工智能算法。传统的AI框架，如Tensorflow [12]和Pytorch [13]要求数据采用张量形式，这是一个n维的向量或矩阵，表示各种类型的数据(例如，表格，时间序列，图像和文本)。由于FHIR格式具有多层嵌套结构，因此需要特定于用例的数据预处理。例如，根据人工智能应用程序和所选择的数据源，应该设计一个自定义数据预处理管道，从而降低人工智能的可扩展性。先前的研究以不同的形式解决了这个问题，但侧重于单个应用，从而限制了FHIR的目的适用于任何用例[11]。已经有一些尝试将分层的FHIR结构扁平化并将其转换为基于ndjson的数据格式[14]或表格格式保存为CSV文件[15]。这种格式对人工智能更友好，因为它们以一种更易于访问和标准化的形式表示数据，用于通用人工智能框架的应用程序。尽管如此，基于ndjson的FHIR数据转换方法[14]没有提供数据选择准则和过滤功能[16]。[15]需要具有FHIRPath查询语言的专业知识。此外，基于fhr的数据预处理管道已经在不同的环境中实现，例如，电子数据捕获[17]，作为自然语言处理工具[12]，并作为基于资源描述框架的标准化协议[6]。尽管它们在处理EHR数据方面提供了巨大的好处，但现有的方法仅限于特定的用例，或者需要大量的数据准备才能执行标准化。此外，它们的最终输出不容易被常见的数据预处理工具访问，从而阻碍了人工智能的应用。

在本文中，我们通过提出以人工智能友好格式提供EHR数据的FHIR数据协调管道(DHP)来解决医疗保健部门数据互操作性的挑战。新开发的FHIR-DHP代表了一个数据工作流解决方案，其中包括上述操作，如数据交换、映射和导出。资料私隐在医疗保健领域是一个微妙的话题，并引起极大的伦理关注[18]。考虑到自动化的程度，FHIR-DHP应该允许在孤立的医院环境中预处理看不见的数据，这使得协调隐私保护。

方法

道德的考虑

由于该研究的方法仅包括开放数据集和数据预处理管道，作者没有寻求伦理审查委员会的评估。

FHIR-DHP架构开发

在我们的工作中，我们提出了一个通用的解决方案来协调医院电子病历数据。FHIR-DHP是基于提取-转换-负载框架设计的[19]，其中从不同来源提取(即查询)数据，处理成所需的格式，并加载到数据仓库中，即“患者模型”数据库(DB)。由于医院数据库包含高度敏感的患者数据，因此它位于医院的安全基础设施后面，与外部访问完全隔离。因此，设计了一个边缘计算解决方案，将FHIR-DHP引入医院自己的基础设施。边缘计算解决方案代表了一组执行数据查询、预处理、存储和导出的框架。在此设置中，运行标准化管道不需要直接访问敏感数据。对数据的查询是事先根据数据库文档定义的。

为了将数据转换成统一的形式，我们使用了FHIR数据模型，通过映射源数据库和所需数据标准之间的关系来应用该模型。FHIR标准很容易实现，因为它为数据表示提供了JSON、XML或资源描述格式的选择。使用Python编程语言开发映射管道，将查询到的医院数据转换为匹配的FHIR概念，并以JSON格式保存生成的资源。使用可用的数据库和FHIR文档检查源数据库和FHIR概念的特征语义。转换为FHIR的目的是只支持FHIR格式的核心版本4标准，以允许通用数据预处理。

为了防止远程数据标准化场景中的错误，有必要对FHIR资源进行语法验证。例如，数据类型的转换有时会导致错误的值，特别是对于日期特性。自动语法验证允许记录发生的错误，并在处理未见过的数据时改进协调管道。当语法验证完成后，应该将FHIR资源转移到数据仓库，以便为AI应用程序快速方便地检索标准化数据。

在数据导出的最后阶段，我们设计的输出既具有原始FHIR格式的优点，又具有高水平的临床细节，并且易于计算工具访问。我们希望以一种支持轻松的数据选择和过滤功能的方式重构数据表示，并且不需要了解FHIRPath查询语言。因此，这种输出格式可以将数据平滑地转换为传统AI框架所需的“张量”格式。

FHIR-DHP验证

为了演示和评估FHIR-DHP是如何工作的，我们使用了公开可用的重症监护医疗信息市场IV (MIMIC IV)数据库[20.]。MIMIC IV包括来自美国马萨诸塞州波士顿一家三级学术医疗中心重症监护病房的患者数据。我们从MIMIC IV中选择了广泛的表格，涵盖了住院期间发生的大多数事件以及核心患者详细信息、入院信息和医院转院(进一步称为核心表格)。事件表包括实验室结果、诊断、处方和其他详细信息，如表1．此外，MIMIC IV还包括所谓的参考表，其中包含与医院记录中使用的医学术语相匹配的词典。

将所选表格映射到FHIR标准。自动语义验证是不可行的，因此两位作者各自独立地手动验证了映射语义。有许多工具可以执行自动语法验证，例如基于python的包“fhir”。本文使用的资源[21]。为了评估从患者模型数据库导出的数据，我们检索了诊断记录。

结果

FHIR-DHP架构

本文介绍的方法代表了一种可扩展的协议，用于协调医院EHR数据集，该协议基于从数据查询到以标准化格式导出数据的5个阶段。

从医院数据库查询数据

为了将FHIR-DHP管道连接到医院数据库，需要使用通信服务器。该服务器运行所有必要的查询来检索患者数据。查询执行可以定期运行，也可以按患者批次运行，这样就不会使数据管道过载。此外，查询在进行数据映射之前，根据数据的语义关系对数据进行预结构。

将数据映射到FHIR

FHIR允许描述作为“资源”记录的数据格式和元素，以及用于交换电子病历的应用程序编程接口。为了执行映射，研究了源数据库和FHIR概念的特征语义以及数据表之间的关系。因此，定义了数据库表和FHIR资源之间的映射。没有找到匹配的FHIR概念的特征将被排除在外。然后以JSON格式保存生成的FHIR资源。

FHIR映射的句法验证

在验证期间，确保映射数据具有正确的数据类型以及维护层次结构的语法格式，并且条目遵循FHIR标准规范。在开发阶段首先验证所有映射，以确定结构错误和数据类型不一致。验证算法被合并到管道中，以确认远程数据标准化场景中转换数据的正确性。

将FHIR资源转移到患者模型数据库

患者模型选择的数据库是Postgres [22]，这是一个开源的关系数据库管理系统，具有SQL兼容性和JSON文档存储的特点。FHIR资源数据库仅用于协调一次本地可用数据，以便进一步应用各种基于人工智能的医疗解决方案。数据根据FHIR资源类型存储，其中每个资源保存在单独的JSON结构中。

导出数据为自定义JSON格式

要从患者模型DB导出数据，可以通过概述配置文件中感兴趣的表和特性来执行选择，然后使用配置文件确定应该查询哪些协调数据。编写FHIRPath查询是为了按照预定义键值结构的特定格式规则从FHIR资源中检索所有元素，并将提取的元素放入自定义JSON文件中。这种转换使FHIR资源的层次结构扁平化，使数据更容易被通用数据预处理工具访问。最终的平面化输出不需要FHIRPath查询语言的专业知识，并且支持轻松的数据选择和过滤。生成的文件还允许将数据简单地转换为传统AI框架所需的“张量”格式，并基于以下4个键进行快速数据选择:feature_name, table_name, value和metadata。

在图1，我们演示了FHIR- dhp如何以人工智能友好的格式将嵌套的FHIR语法重新编码为更易于访问的功能。给出了来自某观测资源的FHIR概念示例图1A，其中代码的实体“文本”定义了记录或测量标签。实体“text”经常在项“display”中重复出现。但是，根据编码系统的不同，这个“display”项可以改变，而“text”项总是保持不变，因此用作功能名称。来自FHIR资源的信息被分成4个概念键:特征名称(例如，“Blood pressure”)、值(例如，“114”)、表名(例如，“observation”)和元数据(图1b).对于给定的FHIR资源类型，元数据可能包括诸如日期、引用、编码系统细节和资源ID等概念。作为输出，功能名称以及相应的值和可用的元数据以自定义JSON结构(图1c).定义的格式允许基于资源类型(例如“table_name”)、特征名称和值进行简单的数据选择和聚合。标准化格式的附加信息可以很容易地从元数据键访问，并允许进一步的数据操作。

‎

FHIR-DHP验证

根据定义的FHIR映射对MIMIC IV数据进行查询。将核心表和事件表与参考表合并，以包含对医院记录的完整描述。结果，将数据分组并重组为FHIR标准所要求的信息块。手动独立的映射语义验证导致了轻微的差异，这些差异随后被解决以严格遵守FHIR标准。自动语法验证允许对标准化操作进行及时验证。

表2显示了MIMIC IV表映射到哪些FHIR资源。最大比例的表(12个表中的4个)被映射到观察FHIR资源类型，包括实验室、微生物学、输出和患者住院期间收集的图表事件。关于入学和转学的资料被翻译成遇到FHIR资源(12个表中的2个)。程序事件和国际疾病分类代码(12个表中的2个)存储在过程FHIR资源。假设处方表包含药物请求(12个表中的1个)，输入事件表包含药物管理记录(12个表中的1个)，这些表被映射到相应的FHIR资源类型。最后,条件利用FHIR资源将该表与患者的诊断细节进行映射(12个表中的1个)。

在表3，我们演示了如何将MIMIC IV“diagnoses_icd”表映射到条件进行了FHIR资源。" diagnoses_icd "表中的多个列，如" icd_code "、" icd_version "和" long_title "被映射到FHIR "条件。code”概念，它具有嵌套结构，并提供存储准确的国际疾病分类代码、编码系统版本和代码标题的密钥。完整的诊断标题被映射到“显示”和“文本”实体。

图2显示了如何将查询的诊断记录协调为人工智能友好格式的示例。标准化遵循上述的FHIR-DHP阶段。首先，查询“诊断ses_icd”和“d_icd_诊断”表中的原始数据(图2a)并根据定义的FHIR映射进行合并。然后，将这些特性重命名为表3为FHIR条件资源创建所需的实体，如“resourceType”和“id”(图2b).最后，将值放入嵌套的FHIR结构(图2c)，然后将数据转换为JSON格式(图2D)，可以自动验证(图2e)保存在患者模型数据库中。当资源的语法质量(如数据类型、嵌套结构或基数)未被批准时，将引发错误，从而阻止在患者模型DB中进一步保存该资源(图2e)，否则，将资源转移到存储(图2f)，所请求的数据以自定义的ai友好JSON格式导出(图2g)。

我们提供了一个将协调诊断数据进一步两步转换为“张量”格式的例子多媒体附录1(12，23]。

‎

讨论

主要研究结果

电子病历数据的统一是在临床常规和医学研究中提高合作、互操作性和患者护理质量的关键一步。为了推动医疗数据的统一，我们开发了FHIR-DHP，并在关键的MIMIC IV表上对其进行了评估。对来自MIMIC IV数据库的临床诊断记录提出了数据标准化的详细示例。通过采用边缘计算解决方案和通信服务器，FHIR- dhp允许在孤立环境中查询健康数据，通信服务器检索患者数据并对其进行基础结构，以便进一步映射到FHIR标准。验证步骤确保语法遵从性，并开始将格式化的数据传输到患者模型数据库。数据导出以自定义JSON文件格式提供FHIR资源。

由于FHIR格式的多层嵌套结构，其对人工智能算法的可访问性较低，因为它需要转换为与通用数据预处理工具兼容的格式。迄今为止，许多研究都试图解决这个问题。然而，这些研究的最终结果并不支持数据选择准则和过滤能力[14]，并要求具备FHIRPath查询语言的专业知识[15]。在本研究中，我们引入了一种代表更高抽象级别的自定义JSON格式，以支持基于以下4个键的更轻松的数据选择:feature_name, table_name, value和metadata。此外，新开发的JSON结构符合通用数据预处理框架的预期数据格式，这些框架旨在有效地处理表格数据。因此，所提供的输出有助于人工智能和患者队列识别算法的通用和快速部署。

与…相比17，24]，讨论了医院环境内执行FHIR-DHP在保护数据隐私方面的细节。这一步虽然至关重要，但在已发布的标准化协议中经常被省略或遗漏。边缘计算解决方案以保护隐私的方式设置了FHIR-DHP，其中与患者相关数据的预处理在医院内部执行，并且与外部访问完全隔离。所谓的联邦学习(FL)框架[25]可以集成到FHIR-DHP工作流程中，在本地运行算法，使用来自各自医院内部数据库的数据，并在云中集中合并模型参数，而无需任何患者数据离开医院。FL框架要求数据在不同的医院系统中采用一致的格式。开发的管道实现了这种格式，并使AI应用程序能够扩展。

到目前为止，只有2项研究试图对MIMIC IV数据库进行映射[26，27]。在[26]，在比我们的方法更少的表上执行映射(8对12表)。由[27最近才发布，尚未得到广泛验证。与[17，24，26]， FHIR- dhp包括对执行的FHIR映射的验证，这对于确保数据转换的有效性和坚持FHIR版本更新至关重要。此外，与[17，24，26]， FHIR-DHP代表了标准化电子病历数据的通用方法，可应用于各种医院数据库系统。

随着将FHIR-DHP引入医院环境，可以使用基于人工智能的算法优化许多患者住院参数。例如，住院时间和死亡率可以减少[28]，可以自动高效地识别适合试验治疗的患者[29]。因此，在人员时间和资源方面对医疗提供者的财务影响将大大减少。FHIR-DHP旨在使医疗保健更接近数字化转型，从而迈向“医疗保健4.0”[30.通过使电子病历数据“从病床到工作台”都可用。与“从实验室到病床”不同，通过颠覆转化研究的理念，利用人工智能充分挖掘医疗大数据的潜力，将进一步为基础研究提供信息和推进。

限制

我们要强调几点限制。FHIR- dhp仅适用于FHIR格式的核心标准。这些核心FHIR资源类型具有一组有限的概念，这些概念对映射的准确性提出了约束。尽管可以使用分析技术或FHIR扩展来扩展标准资源，但使用这些技术会使FHIR- dhp变得不那么通用。因此，我们仅使用标准的FHIR资源实现映射，并省略了一些在FHIR中没有匹配概念的MIMIC IV数据特征。此外，FHIR映射步骤取决于用于推断数据的语义和语法属性的数据库文档的详细程度。一个自动概念识别的解决方案可以潜在地解决这个问题。[6]仅限于少数FHIR资源，需要大量的数据准备。在此方向上的进一步实验可以缓解概念匹配问题和对详细数据库描述的要求。此外，FHIR-DHP的有效性和稳健性需要在其他电子病历数据集上进行测试，以评估其通用设置。此外，为了验证FHIR-DHP与机器学习管道的兼容性，还需要进一步的实验。

未来前景

拟议的FHIR-DHP管道突出了其中具有特色的基本数据标准化阶段，并具有成为具有人工智能友好数据格式的可互操作协调系统的潜力。FHIR-DHP实现了临床机构之间的互操作性和合作，并为临床试验快速识别患者队列;它还释放了大医疗数据的潜力。

结论

我们提供了一种全面的方法，将非标准化的EHR数据转换为协调的多层嵌套FHIR格式，然后转换为更具可读性和更高效的ai友好JSON结构。我们开发了一个5阶段的数据协调管道，其中包括验证检查。医院数据的人工智能友好格式允许人工智能和患者队列识别算法的通用和快速集成。卫生保健数据的统一和标准化，对于提高临床大数据处理、协作和多中心数据交换效率，促进医学研究、患者护理和临床试验队列识别具有重要价值。下一步将包括在医院环境中验证我们的方法，并应用保护隐私的FL框架来利用先进的人工智能部署。