1. HL7与FHIR协同集成工程导论

在医疗信息化项目中，几乎没有人能绕开 HL7。只要涉及医院信息系统（HIS）、电子病历（EMR）、检验系统（LIS）、影像系统（PACS）或区域卫生平台之间的数据交换，HL7 标准就会出现在接口文档、集成引擎配置和联调日志里。但真正进入工程实施后，团队很快会遇到一个现实问题：同样是“HL7”，v2、v3 和 FHIR 三套规范在消息结构、交互方式和实现难度上差异巨大，选错版本或混用不当，往往导致接口反复返工。本课程的目标，就是帮助开发者、集成工程师和医疗信息化从业者建立一套可落地的协同集成方法，能够在同一集成平台上让 HL7 v2、v3 与 FHIR 各司其职、稳定互通。

三套规范的定位差异

理解协同集成，首先要看清三者的设计哲学。HL7 v2 诞生于 1987 年，采用竖线分隔的段（Segment）与字段（Field）结构，典型消息如 ADT^A01（患者入院）、ORM^O01（医嘱）、ORU^R01（检验结果）。它的优势是轻量、传输快、被绝大多数医疗设备与老旧系统原生支持；缺点是字段位置靠约定，不同厂商对同一字段的解释常有偏差，例如 PID-3 患者标识在不同系统中可能放病历号、也可能放住院号。

HL7 v3 则走向另一个极端，采用 RIM（参考信息模型）和 XML 结构，强调语义严谨与全局一致性。一条 v3 消息往往包含大量命名空间、模板 ID 和角色关系，学习曲线陡峭，实际部署成本高，因此在院内点对点接口中普及度远不如 v2，更多出现在区域平台和公共卫生数据交换场景。

FHIR（Fast Healthcare Interoperability Resources）是 HL7 近年主推的现代标准，基于 RESTful API，用 Resource（资源）表达临床对象，如 Patient、Observation、Encounter、MedicationRequest。它支持 JSON/XML 两种序列化，天然适配 Web 与移动端，查询灵活、可组合性强。FHIR 并不否定 v2/v3，而是提供更面向互联网和云端的交互层。

协同集成的典型场景

场景一：院内异构系统互联。HIS 通过 HL7 v2 的 ADT 消息向集成引擎推送患者入院、转科、出院事件，引擎将 PID、PV1 段映射为 FHIR Patient 与 Encounter 资源，写入临床数据中心。此时 v2 负责“快”，FHIR 负责“统一存储与查询”。

场景二：检验结果回传。LIS 以 ORU^R01 发送结果，引擎解析 OBX 段中的检验项目编码、结果值、单位、参考范围，转换为 FHIR Observation，并绑定 LOINC 编码。若 LIS 只支持 v2，而科研平台只认 FHIR，转换层就是唯一桥梁。

场景三：区域平台上报。基层医院使用 v2，区域平台要求 v3 或 FHIR。此时需要做术语映射（如本地检验码 → LOINC、本地药品码 → ATC 或 RxNorm）和结构转换，同时保留原始消息用于追溯。

场景四：患者端查询。移动 App 通过 FHIR API 查询报告，后端从 CDR 读取 Observation 资源，而 CDR 的数据来源可能是 v2 消息。用户看到的是 FHIR，背后跑的是 v2 到 FHIR 的持续转换。

工程化思维与学习路径

协同集成不是“把消息转过去”这么简单，它需要工程化思维。第一，接口契约先行：明确每个字段的来源、目标、必填性与默认值，例如 PID-3 映射到 Patient.identifier，必须约定 system 与 value 的取值规则。第二，术语治理：建立本地码与标准码的映射表，LOINC、SNOMED CT、ICD-10 的版本要锁定。第三，可观测性：每条消息要有唯一 Message Control ID，转换失败要能定位到具体段和字段，日志中保留原始报文与转换后资源。第四，幂等与重试：同一患者重复入院消息不能产生重复 Encounter，需用业务主键去重。