Abstract
推动健康信息的互操作性将显著有益于健康研究，包括代谢型别（phenotyping）、临床试验支持以及公共卫生监测。联邦机构，包括 ONC、CDC 和 CMS，已经共同合作，通过采用 Fast Healthcare Interoperability Resources（FHIR）来促进互操作性。然而，健康数据的异构结构和格式在将电子健康记录（EHR）数据转换为 FHIR 资源时，面临着挑战。 当关键健康信息嵌入到无结构数据中，而没有在规范的结构化格式中，挑战就变得更加重大。以前的研究依赖于使用多个独立的规则基础或深度学习基础的 NLP 工具来完成 FHIR 资源的转换，这需要大量的开发成本，大量的训练数据，以及对多个单独 NLP 工具细致的集成。 在本次研究中，我们评估了大语言模型（LLMs）的能力，将临床 narratives 转换为 HL7 FHIR 资源。我们专门为将临床文本转换为 FHIR 药物声明资源开发了 FHIR-GPT。在使用 3,671 个临床文本片段的实验中，FHIR-GPT 的精确匹配率超过 90%，超越了现有方法的表现。 FHIR-GPT 提升了现有 NLP 残缺匹配率 3% 用于路线，12% 用于剂量数量，35% 用于原因，42% 用于表单，以及超过 50% 用于时间表。我们的发现为利用大语言模型来增强健康数据互操作性提供了基础。未来的研究将致力于通过扩展生成到其他 FHIR 资源来扩展这些成功，以进一步深化这些成果。
Introduction
互操作性增强了医疗保健提供者提供安全、有效和以患者为中心的医疗服务的能力。它还为个人和照顾者提供了进入电子健康数据以进行医疗协调和管理的新型途径 1 。促进互操作性已成为各种健康倡议的组成部分，涵盖了从确保健康公平到应对公共卫生紧急情况的各个方面 2 。 联邦机构，包括国家医疗信息协调办公室（ONC） 1 、疾病控制与预防中心（CDC） 3 和联邦医疗保险与医疗补助服务中心（CMS） 4 ，共同合作通过采用 Fast Healthcare Interoperability Resources (FHIR)，这是一种由 Health Level 7 (HL7®) 标准发展组织开发的下一代互操作性标准。 FHIR 专为促进健康数据的迅速、高效交换而设计。FHIR 在各种健康研究目的下，正逐步在结构化与非结构化数据的建模与集成中得到广泛应用。其应用范围从开发计算 phenotyping 6–8 到支持临床试验 9–12 ，构建监控系统 13,14 ，以及更多。我们参考这两篇综述论文 15,16 ，以获取更多关于 FHIR 应用方面的见解。
将健康数据转换为 FHIR 格式带来挑战，因为各种健康组织都有其独特的基础设施、标准和数据组织方式，用于生成、存储和组织健康数据 17 。当关键健康信息嵌入到非结构化数据中，而非规范化的结构化格式时，这一挑战变得更加显著。 已有努力推动无结构数据转换为 FHIR 资源，来自学术界和商业界的。在学术研究中，Hong 等人 18 集成了临床自然语言处理工具，包括 cTAKES 19 、MedXN 20 和 MedTime 20 ，从对应的文档部分中提取临床实体，并将它们标准化为 FHIR 资源。Wang 等人 21 开发了 Opioid2FHIR 21，这是一个采用多种基于深度学习的自然语言处理（NLP）技术来提取和标准化 opioid 信息的系统。在商业领域，Google Cloud 已经发布 Healthcare Natural Language API 22 ，该 API 能够将医疗文本输入转换为 FHIR 资源。 亚马逊医疗理解 23 可以从临床词汇中提取和规范化医学概念，尽管它不具备将所有提取信息映射到 FHIR 资源的能力。Azure 健康数据 24 在将半结构化数据转换为 FHIR 资源方面表现出色，但不处理自由文本的无结构输入。所有上述的 FHIR 转换工具都需要与多个 NLP 工具进行顺序协作。 这些包括一个用于提取医学概念的命名实体识别（NER）工具，一个用于识别与目标概念相关的关联工具，一个用于标准化提取的概念成词典的工具，以及一个用于将标准化的概念整合到有效 FHIR 格式中的工具。每个 NLP 工具的开发和训练对资源投入巨大，需要大量时间和数据。 创建一个整合多个 NLP 工具的管道需要大量的计算资源、标注数据和人类努力。此外，在管道中进行的转换过程中，转换的准确性也会降低。
因此，我们提出利用预训练的大语言模型（LLMs）来简化现有方法，该方法依赖于一系列 NLP 工具的管道，以促进自由文本输入转化为 FHIR 资源的转换。我们的贡献可以简要总结为以下几点：
- 我们手动标注了一个包含 3,671 条片段的数据库，这些片段来自出院摘要，以及与之对应的已转换的药物声明资源。据我们所知，这是最大且最精炼的人工标注文本到 FHIR 资源转换对的数据库。
- 我们展示了大语言模型，特别是 FHIR-GPT，能够在精确匹配率下超越现有的自然语言处理方法，在转换 FHIR 资源方面。
Results
标注结果以表 1 中呈现。简而言之，我们对 3,671 对自由文本到 FHIR 药物声明资源的转换进行了标注。输入的自由文本来源于 280 份住院记录。输入数据的字符长度呈现出平均约 66 个字符，标准差相对较高，为 65。 注释资源包含 625 种不同药物的 26 种形式，与 354 种不同原因相关，以及 16 种给药途径。这些元素在可获得性上表现出不同水平，从原因约为 30% 到时间表安排约为 65%。SNOMED CT 是最常用的语言术语系统，被用于药物、形式、途径和原因，而 HL7 自己的代码集则用于时间表安排。注释资源存储在 .JSON 结构的平均对象数量为 58.2（标准差 = 16.2），平均深度为 6.7（标准差 = 0.5）。
变换结果以表 2 中显示。简而言之，使用 GPT-4 的 FHIR-GPT，所有元素的精确匹配率超过 90% 的准确率，超越了基准模型和所有其他大语言模型。具体而言，与现有的人工智能管道相比，FHIR-GPT 在路线、剂量、原因、表单和时间表上分别提高了 3%、12%、35%、42% 和超过 50% 的准确率。 在所有大语言模型中，我们观察到随着参数大小的增加，准确性也在增加的趋势。GPT-4，拥有大约 1.7 万亿参数，超越了 180 亿参数的 Falcon 模型，并进一步改进了 70 亿参数的 Llama-2 模型。在所有元素中，对于大语言模型和现有方法来说，最具有挑战性的部分是时间调度和原因。时间调度，由 10 个对象组成，需要计算和推理（例如，通过频率和分布推断持续时间，原因涉及关系抽取和处理基数，因为一种药物可能用于多个原因。
Methods
在本节中，我们深入探讨了数据标注、大语言模型的使用以及评估过程中所采用的技术细节。对于直观的流程图示例，请参阅图 1。
a. 用于生成 FHIR 资源的片段释放总结将被使用。b. 专家注释了关于药物的词_span 在释放总结中。c. 根据我们注释的 transformed FHIR 药物使用陈述资源。从面板 b 中相同的颜色着色。这些结果代表了真实世界的变换。d. 用于指导大语言模型生成 FHIR 资源的示例提示。e. 工作流程详细说明了我们如何对数据集进行标注，以及比较大语言模型和现有的人工智能流程在将自由文本输入转换为关联的 FHIR 资源时的性能。
Data Annotation
HAPI FHIR 公用测试服务器 25 负责托管数百万个已转换 FHIR 资源的示例。然而，我们在转换前无法获取其源数据。根据我们所知，在 FHIR 标准下，没有一个主要公开的数据库是由临床记录生成的。因此，我们决定标注一个包含自由文本输入和结构化输出的 FHIR 资源的数据库。 后者将作为我们评估在 FHIR 转换中大语言模型性能的标准。
我们手动标注了与药物相关的临床叙述，以遵循 FHIR v6.0.0：R6 实施指南 26 。按照官方 FHIR 定义，药物声明表示患者可能正在服用药物，过去曾经服用过，或将来可能服用。 这一转变具有特别的意义，因为许多与药物相关的详细信息，如治疗目的和剂量指示，往往在结构化数据中缺失。在电子健康记录（EHR）系统中，临床笔记通常代表获取和转换为标准化格式的唯一可用来源。 在电子健康记录系统（EHR）内部的临床记录可能是获取并转换此信息进入标准化格式的唯一来源。药物使用陈述（MedicationStatement）包含了各种药物内容，包括剂量、时间表、原因、剂型、给药途径、强度等。欲了解药物使用陈述资源中各元素的详细示例，请参阅表 1。
临床文本输入来自 MIMIC-III 数据集中的出院摘要 27 。2018 年 n2c2 药物提取挑战 28 ，本质上是一个命名实体识别任务，提供了解释了出院摘要中 MIMIC-III 数据集中的实体的药物提及和实体关联的词范围（包括药物给药途径、频率、持续时间、副作用、形式、强度、剂量和原因）中的药物提及。所有实体均由临床专家人工标注。 我们从出院摘要中提取了语句片段，每个片段中包含了一个药物的提及和所有相关的实体，还包括了从提取的词 spans 前后的原始出院摘要中的缓冲词汇。为了确保这些语句片段构成完整的句子，我们在提取词 spans 前后的原始出院摘要中加入了一些缓冲词汇。这些提取的语句片段，每个与特定的药物相关，作为标注和变换的输入。
人类对向 FHIR 标准转换的注释包括三个关键步骤。第一步涉及识别与每种药物相关的元素，这一任务通过重复利用 n2c2 数据集中的专家注释得到了有效解决，这些注释准确地确定了每个元素的词义范围。第二步要求将自由文本中的元素标准化到临床术语编码系统中。 元素与不同的编码系统相关联，我们在表 1 中详细描述了哪些编码系统被使用。值得注意的是，药物名称分别被编码在三个不同的编码系统中。最初，药物名称被映射到 MIMIC-III 的患者处方表中，其中提供了 NDC 编码。对于无法映射药物名称到患者处方表的输入数据，从数据集中排除了这些数据。 随后，使用 RxNav toolkit 提供的 API，NDC 代码映射到 RxNorm 代码和 SNOMED CT 药品代码 29 。对于其他所有元素，如原因、途径和表格，主要使用 SNOMED CT 编码系统，除非 HL7.org 提供自己的代码集。这些代码的转换主要依赖于人工查找。我们从 SNOMED CT 浏览器，国际版 30 中查找了 SNOMED CT 术语的详细信息。 第三步涉及将标识符、代码、文本、扩展和结构整合成一个完整的处方声明资源。在整个研究过程中，我们采用了.json 结构格式。经过官方 FHIR 验证器的转换 31 ，处方声明将通过验证，以确保与 FHIR 标准的兼容性，包括结构、数据类型、计数集、显示名称等。
标注任务由 Y. Li 和 H.W. 组织完成，他们共同解决了歧义或不确定性的内容。我们在论文接受后，将标注数据集提供给公众，只用于授权使用。
Large Language Models
我们尝试的大型语言模型包括 OpenAI GPT-4 32 、Llama-2-70B 33 和 Falcon-180B 34 。我们通过 Azure OpenAI 服务访问了 GPT-4 的 API，根据 MIMIC 数据的责任使用指南推荐。我们使用的具体模型是 gpt-4-32k，在其 2023-05-15 版本时。为了提高效率，我们进行了多样的异步 API 调用。对于 Llama-2-70B 和 Falcon-180B，我们部署在我们的 HIPAA 规范的防火墙本地服务器上，使用了多个 GPU 前端。 GPTQ 35 被用于加速 Llama-2-70B 和 Falcon-180B 的推理时间。
我们要求这些语言模型（大语言模型）将自由文本输入转换为遵循 FHIR 标准的药物声明资源，采用少量样本的提示设置。每个临床片段都被单独输入到大语言模型中以生成药物声明资源。 我们使用了五个独立的提示来指导大语言模型将自由文本输入转换为 MedicationStatement 资源的元素，包括药物详情（如药物名称、剂量和形式）、途径、时间、剂量和原因，依次。所有几 shot 提示都遵循了以下模板：任务说明，预期的 FHIR 模板，以 . 结尾。JSON 格式，4-5 个变换的例子，模型可以从其中选择代码的全面列表，以及需要转换的输入文本。在我们的实验中，我们没有进行微调或领域特定的适应，因此我们最初让大语言模型为数据集（N=∼100）的一部分生成 FHIR 格式。然后，我们人工审查了大语言模型生成的 FHIR 输出与人类注释之间的差异。发现了常见错误，并利用这些错误来优化提示。 各大语言模型的提示语存在微小差异，因为不同大语言模型可能对不同的提示敏感。重要的是要记住，我们并未获得所有药品名称的全面 NDC、RxNorm 和 SNOMED Medication 代码列表，以及原因下的 SNOMED Finding 代码。 我们没有指令大语言模型查找 SNOMED 代码，因为 SNOMED CT 药物和发现代码的完整列表，数量可能超过数千或更多个令牌限制，这超出了大语言模型的处理范围。相反，我们的指令是让它们识别输入文本中提到的上下文，并将其转换为适当的 JSON 格式。 例如，期望的输出是 {“reason”: [{“concept”: {“text”: “头昏”}}]} 而不是更详细的信息 {“reason”:[{’concept’: {’text’: ’headache’, ’coding’: [{’system’: ’SNOMED’, ’code’: ’25064002’,’display’: ’Headache’}]}}]}。对于其他代码集，如 SNOMED CT Form 代码，我们在数百个数字的编码上允许大语言模型直接编码。请参阅附录以获得提示。
Evaluation
我们比较了经过处理的资源与两个现有方法的输出：NLP2FHIR 18 和 Google Healthcare Natural Language (NL) API 22 。两者的方法生成的结果都缺少了我们的人工标注和大语言模型生成所涵盖的元素。18 NLP2FHIR，22 Google Healthcare Natural Language (NL) API NLP2FHIR 项目基于之前 FHIR 实施指南的版本构建，而 Google 医疗保健 NLP API 主要将概念标准化为 UMLS CUI，而不是 SNOMED CT 代码，这些代码在我们的标注和大语言模型的转换中使用。我们对项目进行了适应和转换，以确保进行公平的比较。我们将在我们的 HIPAA 认证的隔离本地服务器上部署 NLP2FHIR 框架。 我们通过 Google Cloud 医疗健康 API 访问 Google 医疗保健 NL API，该 API 也符合 HIPAA 规定。
在评估由大语言模型生成的 FHIR 资源时，我们的初始步骤是确认输出为有效的 JSON 格式。一旦 JSON 格式检查成功通过，我们评估的主要标准是精确匹配率。这一标准要求由大语言模型生成的资源在所有方面完全匹配人类注释，包括结构、编码和约束。 与以往的研究报告了词扫描的 F1，精确率和召回率分数，这些研究将变换视为 NER（命名实体识别）任务不同，我们没有使用这些指标。这个决定是基于这样的考虑，即这些指标可能忽略了根据上下文进行推断和标准化内容的基本方面。精确地确定词组并不能保证能够正确地识别出对应的代码，并且能够推导出正确的 FHIR 格式。
Conclusion
在本次研究中，我们提供了利用大语言模型来增强健康数据互操作性的基础，通过将自由文本输入转换为 FHIR 资源。FHIR-GPT 模型不仅训练自由，而且能提高转换准确性。未来的研究将通过扩展生成到更多 FHIR 资源，并比较更多大语言模型的性能，来在此基础上取得成功。
Footnotes
Emails: yikuan.li{at}northwestern.edu, hanyin.wang{at}northwestern.edu, halid.yerebakan{at}siemens-healthineers.com, yoshihisa.shinagawa{at}siemens-healthineers.com, yuan.luo{at}northwestern.edu
Resolved some format issues.
References
Subject Area
