背景情况

急诊医疗服务（EMS）团队到达急诊科时，常常会遇到人口统计数据不完整或未知的病人——没有病历号（MRN），没有确认的姓名，有时甚至没有出生日期。然而，急救医疗运送记录仍然需要准确无误地记录在病历中。

为了支持安全可靠的记录，急救医疗机构、第三方集成服务和医院集成团队建立了安全接口，用于交换识别码和临床信息。当这些标识符不一致时，下游系统就无法自动发布转运记录，从而产生可避免的人工操作，并延误记录的完整性。本文概述了如何使用 FHIR Patient.Search (R4) 来填补最常见的人口统计空白并改进自动发布。

挑战

在许多 EMS 到医院的集成中，患者最初是以通用或临时标识符注册的。最终登记和任何记录合并可能要到稍后才会发生，有时是在出院后。在这些更新传播之前，EMS 患者标识符和电子病历 (EMR) 标识符可能一直不同步。

当转运记录因不匹配而无法发布时，集成通常会生成一个错误，并转到 EMR 工作队列进行人工审核。在 EMS 处理量大的情况下，队列会迅速增长。一个常见的根本原因是入站信息中缺少一个或多个人口统计字段，而这些字段是进行可靠的患者匹配和病历张贴所必需的，其中最常见的是

• 病历号 (MRN)
• 姓名
• 出生日期
• 性别

当今的工作方式

如今，缺失的人口统计数据可通过查询长期运行的 Microsoft SQL Server 数据库（已使用 20 多年）来补充，该数据库存储了 HL7 ADT（人口统计数据）消息的解释视图。集成层使用 JDBC 调用来执行存储过程并检索所需字段。

基于 FHIR 的方法

一种更先进的方法是直接从 FHIR 存储库中检索缺失的人口统计数据。具体来说，FHIR Patient.Search (R4) 提供了一种基于标准的方法，可使用传输记录发布时可用的任何部分信息来查找 MRN、姓名、出生日期和性别。

为了实现这一功能，一个专门的业务流程封装了 Patient.Search (R4) 调用，并将规范化响应返回给初始集成工作流。

工作流概述

请求源向业务流程提交 PatientSearch.Request（自定义消息类）。

然后，业务流程执行以下步骤：

• 获取 OAuth 访问令牌。
• 将 PatientSearch.Request（自定义消息类）转换为 HS.FHIRServer.Interop.Request.
• 将 HS.FHIRServer.Interop.Request 发送到外部 FHIR 存储库。
• 验证 FHIR 响应是否返回 HTTP OK (200)。
• 将 HTTP 流中的 FHIR 响应转换为 PatientSearch.Response（自定义消息类）。
• 将 PatientSearch.Response（自定义消息类）返回给发起流程。

其他工作流程注意事项包括

• 确保供应商至少提供以下信息之一：MRN、姓名、出生日期或性别。
• 如果返回多个 FHIR 患者响应，结果将按原样转发至 EMR，如果提供的字段不足以唯一标识患者，系统将生成错误。