KHCC 与 HAKEEM 的 HL7 集成

大多数工程师从没见过真正的 HL7 消息。

如果你在 fintech 工作过，你大概解析过 ISO 8583。如果你在物流行业工作过，你处理过 EDI。如果你构建过两个医院系统之间的实时集成，你见过 HL7 v2，而且你有了之前没有的观点。

电子健康解决方案的团队在 2010-2013 年的合作期间，构建了 King Hussein 癌症中心（KHCC） 与约旦国家 EHR HAKEEM 之间的 HL7 集成。这是那段工作的真实样貌。

HL7 v2 消息看起来是什么样的

线格式是让工程师皱眉的第一件事。

MSH|^~\&|KHCC|KHCC|HAKEEM|MOH|20120315120000||ADT^A01|MSG00001|P|2.3
EVN|A01|20120315120000
PID|1||12345^^^KHCC^MR||AL-MANSOUR^AHMAD^MOHAMMED||19750304|M|||AMMAN^JO||||AR|M||12345
PV1|1|I|ONCOLOGY^101^1^KHCC||||SMITH^JOHN^A^^^DR

这是一条 ADT^A01—入出院转科消息，事件 A01 代表患者入院。每个段用竖线分隔。段内字段也用竖线分隔，子字段用 ^，子子字段用 &，重复字段用 ~。

MSH 段是消息头：发送应用、发送机构、接收应用、接收机构、时间戳、消息类型、消息 ID、处理 ID、版本。PID 段是患者身份：ID 列表、姓名、出生日期、性别、地址、语言。版本—HL7 v2.3—于 1997 年定稿。这个竖线分隔格式早于 XML 对企业系统的征服。它不漂亮，但它直接映射到医院实际存储和交换患者数据的方式，这就是为什么它在 FHIR、CDA 和每一个被设计来取代它的标准出现之后的几十年里，仍然是医疗领域的主导线格式。

为什么 KHCC 是具体的挑战

King Hussein 癌症中心不是综合医院，而是约旦旗舰专科肿瘤机构—在 Princess Ghida Talal 赞助下成立的卓越中心，使命横跨整个地区的治疗、研究和教育。患者通过其他医院的转诊到来，其中许多已经在 HAKEEM 上。

这意味着患者的记录不是从 KHCC 开始的。它从转诊机构开始—比如 Prince Hamza 医院—那里首先诊断出需要肿瘤学专业知识的病情。他们的人口统计信息、初步诊断、用药历史和实验室结果都住在 HAKEEM 里。

当那个患者到达 KHCC 时，KHCC 有自己的 EHR，自己的患者 ID 空间，自己针对化疗方案、放射治疗计划和肿瘤特定实验室检测的数据模型。

挑战不是「把 KHCC 的数据放进 HAKEEM」。挑战是跨两个对同一个人分配了不同 ID 的系统解析患者身份，然后做保持两个系统都是最新的双向同步，而不产生重复或丢失临床上下文。

HL7 v2 是那个问题的传输层，不是解决方案。

真正难的部分

患者身份不是已解决的问题。 KHCC 分配了自己的病历号，HAKEEM 维护着自己的国家患者标识符方案。PID-3 字段专门容纳患者 ID 列表—因为一个患者在多个系统里有多个标识符。但知道 KHCC 的患者 12345 就是 HAKEEM 的患者 98765，需要一个映射表，而构建那个表需要对姓名+出生日期+性别+地址做概率匹配，或者人工核对，或者—在实践中—两者都要，对不同置信度阈值用不同规则。

事件排序在临床上有意义。 HL7 ADT 消息携带事件类型：A01 是入院，A02 是转科，A03 是出院，A08 是信息更新。这些事件必须按顺序到达和处理，否则临床图像是错误的。一个先入院、转科、然后出院的患者，和那些消息乱序到达并被按入院、出院、转科到一个他已经离开的科室处理的，看起来截然不同。

在高吞吐量集成里，消息不总是按顺序到达。TCP 给你可靠传输，但当消息被异步生产时，它不给你应用级排序保证。你需要序列号、ACK/NAK 确认，以及一个有重试逻辑的队列，在不丢失消息或用重复消息淹没目标的情况下处理 NAK。

发送系统的实现才是真正的规格说明。 HL7 v2.3 是一个有可选字段和大量实现变化空间的标准。KHCC 的 EHR 实际在 PID-3 里发送的东西才是重要的—不是规格说明里写的应该在那里的东西。花了时间和 KHCC 技术团队分析他们实际的出站消息，因为实现文档是不完整的。这很正常，每个 HL7 集成都有这个故事。

路由层是什么样的

集成使用 VistA 里的 HL7 消息包—在 HAKEEM 侧处理入站消息解析和路由的 MUMPS 例程。团队为特定事件类型写了例程：主要是患者移动的 ADT 事件，以及实验室单和结果的 ORM/ORU 对。

转诊流程：

1. 转诊医院（在 HAKEEM 上）把患者送到 KHCC。
2. KHCC 为患者挂号，分配他们的病历号。
3. KHCC 向 HAKEEM 发送一条 ADT^A01 确认入院。
4. HAKEEM 路由层接收 A01，通过主患者索引映射解析患者身份，用 KHCC 的就诊信息更新患者记录。
5. KHCC 肿瘤实验室检测的结果通过 ORU^R01 消息流回，落在患者的 HAKEEM 记录里—对仍然持有患者主要护理关系的转诊医生可见。

最后这点在临床上很重要。KHCC 的肿瘤科医生在治疗癌症，转诊医院的全科医生还在管这个患者的高血压、糖尿病和其他一切问题。他们需要看到肿瘤科结果，而不需要患者在机构之间带着纸质记录。HL7 集成才让这成为可能。

十二年后这看起来如何

HL7 v2 不是漂亮的软件，但它是那种赢得尊重的丑陋—因为问题域是丑陋的，不是因为设计者没有努力。医疗数据是混乱的，因为医疗本身是混乱的。患者有多个标识符，因为他们与多个系统交互。事件需要排序，因为临床时间线对诊断有意义。字段可选性看起来是松散，实际上是标准在容纳必须使用它的临床专科的广度。

FHIR 在大多数方面确实更好。2012 年，FHIR 还是草稿规格。HL7 v2 是医院系统说的语言，你和那里有的东西集成。

构建医疗集成的工程师在做大多数行业看不见的工作。把实验室结果从实验室系统载到病历再到医生屏幕的 HL7 消息是基础链路。没人注意到它，直到它坏了。这些链路还在跑。