简而言之： 接口引擎（集成引擎）是一种专为医疗消息传递而构建的中间件。它监听多种协议（HL7 v2 的 MLLP、FHIR 和 SOAP 的 HTTP、文件、数据库、队列），转换消息（字段映射、代码翻译、格式转换，例如从 HL7 v2 转换为 FHIR），通过过滤器将消息路由到一个或多个目的地，并维护队列、重试、日志和仪表板，以确保消息永不丢失，并且所有故障都可见。医院使用它，以便每个系统只需与引擎连接一次，而不是与所有其他系统连接。知名的产品有 Mirth Connect（NextGen Connect，历史悠久的开源产品）、Rhapsody、InterSystems HealthShare / IRIS for Health、Infor Cloverleaf、Qvera QIE、Orion 以及众多其他产品；云服务提供商也提供托管的同类产品。
构建模块
接口引擎的构建模块包括通道（从源到其目的地的单一数据流)、源连接器或监听器（如 MLLP 和 HTTP)、用于决定消息是否继续的过滤器、用于映射字段和代码的转换器、目标连接器、带有重试机制的队列、带有警报的监控功能，以及通道变更和消息历史的审计记录。
无论使用何种术语，每个引擎都包含相同的组件：
- 通道（接口）：从源到一或多个目的地的单一数据流，具有独立的设置和统计信息。
- 源连接器/监听器：MLLP（用于 HL7 v2 的带帧的 TCP）、HTTP(S) 端点、SFTP 和文件轮询、数据库查询、JMS 或其他队列，部分产品支持 DICOM。
- 过滤器：决定消息是否继续处理的规则（例如，仅针对此患者类别处理 ADT^A01）。
- 转换器：用于更改消息的脚本或映射：重命名字段、通过查找表将本地代码映射到 LOINC、从 OBX 段构建 FHIR Observation、添加旧系统期望的 Z 段。
- 目标连接器：结果的去向，具有独立的协议和错误处理。
- 队列和重试：消息在被确认前会一直保留；失败的消息会以指数退避方式重试；“有毒”消息会进入人工处理的错误队列。
- 监控和告警：按通道的计数器、延迟、错误率，以及当通道静默时发出的告警（这是医疗集成中最有用的告警）。
- 审计：记录谁更改了哪个通道，以及用于故障排除的消息历史记录，并根据需要进行保留和访问控制，因为这是患者数据。
典型任务
医疗保健接口引擎的典型任务包括：HIS 到各部门的 ADT 扇出、将实验室结果路由到多个接收者、将本地代码转换为 LOINC、ATC 和 UCUM、桥接 HL7 v2、FHIR、CDA 和 CSV 格式、为遗留数据库提供 FHIR 接口、规范化设备数据流，以及将内部 MLLP 适配为外部 HTTPS。
- ADT 扇出：接收来自 HIS 的入院信息，按部门过滤和翻译，然后分发到实验室、放射科、药房、床位管理和患者门户。
- 结果路由：将 LIS 的 ORU 发送到 EHR、开具处方的 GP 系统、区域记录系统、患者的 FHIR 记录，每个系统接收不同的子集和格式。
- 代码翻译：将本地测试代码翻译为 LOINC，本地药物代码翻译为 ATC，将自由文本单位翻译为 UCUM，通过维护的查找表（映射实验室代码到 LOINC）。
- 格式桥接：HL7 v2 与 FHIR 之间的相互转换，CDA 到 FHIR，旧系统输出的 CSV 到任何格式。
- FHIR 门面：引擎暴露 FHIR 端点，并通过查询旧数据库或发送 v2 查询来响应这些请求，从而让应用程序看到一个不存在的 FHIR 服务器。
- 设备集成：将专有监护仪的馈送数据标准化为 IHE PCD 的 Observation。
- 协议适配：内部使用 MLLP，外部使用带 OAuth 的 HTTPS。
选择一个
选择接口引擎主要取决于六个标准：消息量以及延迟和中断的重要性、开箱即用的协议和标准支持（HL7 v2、FHIR R4、DICOM、国家格式)、开发人员体验、运维（如集群和故障转移)、许可条款（某些产品在 2025 年有所变更)，以及维护通道所需的技术技能。
- 流量和关键性：每天的消息量、可接受的延迟，以及两分钟的停机时间是否会造成影响（ADT 和结果信息尤其如此）。
- 开箱即用的协议和标准支持：HL7 v2 版本和解析器、FHIR R4 支持及验证、DICOM、美国的 X12、国家特定格式。
- 开发人员体验：脚本语言（Mirth 中使用 JavaScript，其他产品使用专有语言）、通道定义的版本控制、测试工具、部署到多个环境。
- 运维：集群、故障转移、监控集成、升级路径、支持模式。
- 许可：开源或社区版、按通道或按核心的订阅、托管云服务；某些历史悠久的开源产品的许可在 2025 年发生了变化，请检查当前条款。
- 可用技能：引擎的好坏取决于维护通道的人员。
安全运行
安全运行接口引擎意味着将通道定义视为代码进行版本控制、在生产环境中使用合成消息进行测试、由指定负责人管理代码查找表、在通道静默时发出警报、限制和清除消息历史（因为它是患者数据)、记录每个通道的用途，并且绝不让引擎成为记录系统。
将通道定义视为代码：纳入版本控制，经过审查，通过测试和预生产环境进行部署，并使用合成消息进行测试。将查找表（代码映射）置于治理之下，并指定负责人。为静默状态设置告警，而不仅仅是错误告警。限制对消息历史记录的访问，因为这是患者数据，必须进行保护和定期清除。记录每个通道的目的和负责人；未记录的通道往往会在其作者离职时导致部门停摆。切勿让引擎成为记录系统：它移动和转换数据，但不拥有数据。
何时不需要
当一个全新系统的所有合作伙伴都支持 FHIR 时，就不需要接口引擎了，在这种情况下，带有订阅功能的 FHIR 服务器和 API 网关可以处理路由和身份验证；或者当单个 HL7 v2 接口可以通过 HAPI HL7v2 或 hl7apy 等库处理时。当涉及多个系统和格式时，接口引擎才能发挥其价值。
对于所有合作伙伴都支持 FHIR 的全新系统，可以使用带有 Subscriptions 的FHIR 服务器和API 网关来实现身份验证、速率限制和路由，并在普通服务中进行转换。单个 HL7 v2 接口可以通过应用程序内部的小型库（Java 中的 HAPI HL7v2，Python 中的 hl7apy 或 python-hl7）来处理。当存在多个系统、多种格式以及需要一个非开发人员可以监控的操作控制台时，引擎的价值就体现出来了。
在 Anpheros 中
Anpheros Platform 位于引擎的 FHIR 端：医院通过其引擎或通过实验室连接器将它们想要共享的流量（结果、文档、就诊记录）路由到该平台，并通过 FHIR API 和 Webhook 读取数据。开发者网站展示了连接器应用的HL7 v2 到 FHIR 映射。
相关页面
- 医院系统集成详解
- 如何将实验室系统与 EHR 集成
- HL7 v2 消息详解：ADT 和 ORU
- 如何将本地实验室代码映射到 LOINC
- FHIR Subscriptions 详解
- HL7 v2 到 FHIR 映射（开发者网站）
来源
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- HAPI HL7v2 库
- HL7 v2-to-FHIR 实现指南
常见问题
接口引擎和 ESB 或 iPaaS 是同一回事吗？
属于同一家族，但有专长区分：接口引擎内置了对 HL7 v2、DICOM、CDA 和 FHIR 的支持，以及 MLLP、医疗特定监控和集成团队使用的词汇表。通用的 ESB 和 iPaaS 产品需要更多的构建才能完成相同的工作。
引擎可以自动将 HL7 v2 转换为 FHIR 吗？
一些引擎包含基于 HL7 v2-to-FHIR 指南的映射，并且可以处理常见的段。本地约定、Z 段和代码映射始终需要项目工作。
引擎是否存储患者数据？
它会持久化传输中的消息，并保留消息历史记录以进行故障排除，这些都是患者数据，必须受到保护并定期清除。它不应被用作长期存储或记录系统。
开源还是商业？
两者都在大型医院中投入生产。决策通常取决于支持、技能、集群需求以及当前的许可条款（某些产品的条款已发生变化）；在做出承诺之前请仔细核查。
在沙盒中免费试用
5 分钟完成第一次 FHIR 调用. 一个内置患者授权的 HL7 FHIR R4 API：先在沙盒中试用，然后连接您自己的应用或诊所系统。
免费 · 30 位合成患者 · 无需信用卡
Anpheros 致力于打造一个由患者掌控的医疗记录，并可在欧盟的 HL7 FHIR R4 平台上与任何诊所共享。这些指南旨在帮助您理解和整理您的健康信息，但不能替代您的医生。
关于 Anpheros →