3. 临床数据采集接口技术
临床数据采集的接口技术并非单一标准，而是一组按“消息—文档—资源—影像—传输”分层协作的协议族。理解它们各自解决什么问题、在什么场景下不可替代，是接口选型的前提。本节先横向拆解六类接口的定位与关键机制，再给出可操作的选型判断路径。
一、六类接口的定位与关键机制
HL7 v2 是医院内部系统间最普遍的“消息型”接口，以竖线分隔的段（Segment）和字段（Field）组织数据，典型消息如 ADT（入院/出院/转科）、ORM（医嘱）、ORU（检验结果）。其核心特征是触发事件驱动：一个业务动作产生一条消息，接收方返回 ACK 确认。例如一条 ORU^R01 检验结果消息，MSH 段携带发送/接收应用与消息控制 ID，PID 段标识患者，OBR 段描述检验项目，OBX 段承载结果值与单位。HL7 v2 版本碎片化严重（v2.3、v2.5、v2.7 并存），字段常被本地化扩展，因此接口对接时必须以“消息结构 + 触发事件 + 本地 Z 段约定”三件套作为契约。
FHIR 是面向 Web 的现代标准，把临床数据抽象为 Resource（Patient、Observation、Encounter、MedicationRequest 等），通过 RESTful 接口以 JSON/XML 交换，支持查询参数、分页、批量 Bundle 和订阅（Subscription）。FHIR 的优势在于资源粒度细、可组合、易被前端和移动端消费，适合新建系统、互联网医院、科研数据平台和跨机构数据交换。其代价是资源间引用关系复杂，落地时需要明确 Profile（如 US Core、CN Core）来约束必填字段与术语集。
CDA 是“文档型”标准，强调一份临床文档的完整性与法律效力，典型如出院小结、会诊记录。CDA 文档由 Header（患者、作者、时间、文档类型）和 Body（结构化条目）组成，Body 可嵌套 Section 与 Entry，Entry 可进一步用 templateId 约束为 C-CDA 的具体模板。CDA 适合归档、交换和监管上报，但不适合高频实时查询。
DICOM 是医学影像的事实标准，定义影像对象（CT、MR、US 等）的像素数据、元数据（患者、检查、序列）以及网络服务（C-STORE、C-FIND、C-MOVE、WADO-RS）。影像采集通常走 DICOM 协议，而影像报告文本可经 HL7 v2 或 FHIR 回传，形成“影像 + 报告”的闭环。
Web Service 是通用传输层技术，SOAP/WSDL 在传统 HIS 集成中常见，REST/JSON 在新建系统中占主导。它本身不是临床语义标准，而是承载 HL7 v2、FHIR、CDA 的“管道”。选型时要区分“语义标准”和“传输协议”，避免把两者混为一谈。
消息队列（如 Kafka、RabbitMQ、ActiveMQ）解决的是异步、削峰、解耦和可靠投递问题。当采集端产生大量实时数据（如监护仪波形、检验流水线结果）时，直接同步调用接口容易造成阻塞和丢数，此时用消息队列做缓冲，消费者按自身节奏拉取并写入临床数据仓库，是更稳健的架构。
二、选型判断：从场景反推接口组合
接口选型不是“哪个标准更先进”，而是“哪个组合能最低成本地满足当前场景的实时性、语义完整性和系统兼容性”。可以按以下判断路径推进：
- 数据是“事件”还是“文档”还是“影像”？ 事件型（入院、医嘱、检验结果）优先 HL7 v2 或 FHIR；文档型（出院小结、会诊记录）优先 CDA；影像型优先 DICOM。
- 接收方是新建系统还是老旧系统？ 老旧 HIS 通常只支持 HL7 v2 + MLLP，新建平台可优先 FHIR REST。若双方能力不匹配，需在中间加适配层做协议转换。
- 实时性要求多高？ 秒级同步用 Web Service 直连；高并发、允许秒到分钟级延迟用消息队列缓冲；批量历史数据迁移可用 FHIR Batch 或文件导入。
- 是否需要跨机构交换？ 跨机构优先 FHIR（配合国家/区域 Profile）或 CDA 文档交换，DICOM 用于影像共享。
三、接口对接的关键参数与验证要点
以 HL7 v2 经 MLLP 接入为例，对接时需要确认以下参数：发送方与接收方应用名（MSH-3、MSH-5）、消息控制 ID（MSH-10）唯一性、字符集（MSH-18，常用 UNICODE UTF-8）、版本号（MSH-12）、触发事件（MSH-9）。接收端需返回 ACK，ACK 的 MSA-1 为 AA 表示接受，AE 表示错误，AR 表示拒绝。若发送方在超时时间内未收到 AA，应触发重传并记录日志。
FHIR 对接则需确认：Base URL、认证方式（OAuth 2.0 或 SMART on FHIR）、资源 Profile、搜索参数（如 Patient?identifier=、Observation?patient=&date=ge2024-01-01）、分页机制（Bundle 的 link.next）。验证时先做 GET /metadata 获取 CapabilityStatement，确认服务端支持的资源与交互，再逐资源做 CRUD 与搜索测试。
# HL7 v2 ORU^R01 消息片段示例（竖线分隔）
MSH|^~\&|LIS|HOSP|CDR|HOSP|20240612103000||ORU^R01|MSG000123|P|2.5|||UNICODE UTF-8
PID|1||P2024001^^^HOSP^MR||张三||19850312|M
OBR|1||ORD7788|血常规^LAB|||20240612102000
OBX|1|NM|WBC^白细胞||6.8|10^9/L|4.0-10.0|N|||F
OBX|2|NM|HGB^血红蛋白||135|g/L|130-175|N|||FDICOM 对接需确认 AE Title、IP 与端口、支持的 SOP Class（如 CT Image Storage）、传输语法（如 Explicit VR Little Endian）。用 C-ECHO 验证连通性，用 C-FIND 验证查询能力，用 C-STORE 验证写入，最后用 WADO-RS 或 C-MOVE 验证回取。消息队列则需确认 Topic/Queue 名称、分区数、副本数、消息保留时长、消费者组与偏移量提交方式，并做幂等消费设计，避免重复写入。
四、选型决策表（可直接用于项目评审）
| 场景 | 推荐语义标准 | 推荐传输方式 | 关键验证点 |
|---|---|---|---|
| HIS 患者主索引同步 | HL7 v2 ADT | MLLP / 消息队列 | MSH-10 唯一、ACK AA、PID-3 匹配 |
| 检验结果实时回传 | HL7 v2 ORU | 消息队列削峰 | OBX 单位、参考范围、异常标志 |
| 新建互联网医院问诊 | FHIR R4 | HTTPS REST | CapabilityStatement、OAuth、分页 |
| 出院小结归档上报 | CDA R2 | HTTPS / 文件交换 | templateId、Header 完整性、签名 |
| CT/MR 影像采集 | DICOM | DIMSE / WADO-RS | C-ECHO、SOP Class、字符集 |
| 监护波形高并发采集 | 自定义/HL7 v2 | Kafka 消息队列 | 分区、副本、幂等消费、延迟 |
接口选型的最终产出应是一份可执行的接口契约：明确每个数据源的语义标准、传输协议、触发方式、字段映射、异常处理与验证用例。只有把“标准选择”落到“字段级映射”和“失败重试策略”，采集链路才具备工程可维护性。