3. 接口集成核心概念
在 HIS、LIS、RIS 三套系统之间做集成，技术名词很多，但真正决定项目成败的，往往不是“用了多新的技术”，而是“有没有把每种技术放在它最合适的位置”。本节把八类核心概念按“通信协议 / 数据标准 / 集成机制”三个层次梳理清楚，并给出可操作的选型依据。
一、先分清三个层次，避免概念混用
初学者最容易犯的错误，是把 HL7、DICOM 与 REST、消息队列放在同一维度比较。实际上它们分属不同层次：
- 数据标准层：HL7（v2.x / FHIR）定义医疗业务消息的语义，DICOM 定义医学影像及其元数据的格式与传输。它们回答“数据长什么样、字段什么含义”。
- 通信协议层：Web Service（SOAP/WSDL）、REST（HTTP+JSON/XML）回答“数据怎么在系统间传”。
- 集成机制层：消息队列、中间表、视图、触发器回答“数据以什么方式落地、同步、触发”。
一个典型的 HIS→LIS 申请单下发，可能是“HL7 v2 ORM 消息 + REST 传输 + 中间表落库 + 触发器通知 LIS 取单”的组合。选型不是二选一，而是分层组合。
二、八类技术的角色定位
| 技术 | 层次 | 典型角色 | 典型场景 |
|---|---|---|---|
| HL7 v2.x | 数据标准 | 业务消息语义（ADT/ORM/ORU） | 患者信息、申请单、检验结果 |
| HL7 FHIR | 数据标准 | 资源化、RESTful 医疗数据 | 新建平台、互联网医院 |
| DICOM | 数据标准 | 影像与影像元数据 | RIS/PACS/CT/MR 传输 |
| Web Service | 通信协议 | 强契约、事务型调用 | HIS 调 LIS 计费、状态查询 |
| REST | 通信协议 | 轻量、资源化接口 | 移动端、微服务、FHIR |
| 消息队列 | 集成机制 | 异步解耦、削峰、可靠投递 | 大批量结果回传、日志 |
| 中间表 | 集成机制 | 数据库级交换、可审计 | HIS 与 LIS 同库/异库对接 |
| 视图 | 集成机制 | 只读共享、实时查询 | 报表、字典、患者主索引 |
| 触发器 | 集成机制 | 数据变更即时响应 | 新申请单入库即通知 |
三、选型依据：五个判断维度
面对一个具体接口，建议按以下五个维度判断：
- 实时性要求：秒级强一致（如计费、状态回写）优先 Web Service/REST 同步调用；允许分钟级延迟（如结果批量回传）可用消息队列或中间表轮询。
- 数据量与峰值：日均几万条结果、早高峰集中回传，消息队列的削峰能力明显优于同步接口。
- 系统耦合度：厂商不愿开放数据库时，只能走 HL7/REST；若同库或允许建中间表，则中间表+触发器成本最低。
- 数据语义复杂度：影像必须 DICOM；检验结果、患者信息优先 HL7；内部管理类数据可用 JSON。
- 可维护性与审计：中间表天然留痕，便于对账；消息队列需配套死信队列与重投机制。
经验法则：跨厂商、跨网络、语义复杂 → 标准协议（HL7/DICOM）+ REST/WS；同库或同院内部 → 中间表 + 触发器/视图；高并发异步 → 消息队列。
四、一张图看清八类技术的协作关系
下图把 HIS、LIS、RIS 三个系统与八类技术放在同一张协作视图中，箭头方向表示数据流向，颜色区分层次。可以看到：HL7 与 DICOM 是“说什么”，REST/WS 与消息队列是“怎么送”，中间表/视图/触发器是“怎么落”。
五、一个可落地的选型决策表
把上面的判断维度整理成决策表，接口设计评审时可直接对照使用。表中“推荐方案”是常见组合，实际项目仍需结合厂商能力与网络条件调整。
| 接口场景 | 实时性 | 数据量 | 推荐方案 | 理由 |
|---|---|---|---|---|
| HIS 下发检验申请单 | 秒级 | 中 | HL7 ORM + 中间表 + 触发器 | 语义标准、落库可审计、触发即时 |
| LIS 回传检验结果 | 分钟级 | 大 | HL7 ORU + 消息队列 | 削峰、异步、失败可重投 |
| RIS 获取患者信息 | 秒级 | 小 | HL7 ADT 或 REST 查询 | 轻量、实时 |
| PACS 影像传输 | 秒级 | 大 | DICOM C-STORE / C-FIND | 影像必须 DICOM |
| HIS 调 LIS 计费状态 | 秒级 | 小 | Web Service 同步调用 | 强契约、事务一致 |
| 报表/字典共享 | 准实时 | 中 | 视图 | 只读、免同步、实时 |
| 新建互联网医院 | 秒级 | 中 | FHIR + REST | 资源化、易扩展 |
常见误区：用触发器做跨库业务逻辑。触发器适合“变更通知”，不适合承载复杂业务判断；一旦逻辑写在触发器里，排障和版本管理都会非常困难。复杂逻辑应放在接口服务或消息消费端。
六、选型时的三个实操建议
- 先定数据标准，再定传输方式。先确认字段语义（患者 ID、申请单号、结果值、单位、参考区间）由 HL7 还是自定义 JSON 承载，再决定用 REST 还是 MQ。语义不清，传输再快也会对不上账。
- 中间表必须带状态字段。建议至少包含
status（0 待处理 / 1 已处理 / 2 失败）、create_time、update_time、retry_count，否则无法判断“到底同步成功没有”。 - 消息队列必须配死信队列。消费失败的消息进入死信队列并告警，避免“消息丢了但没人知道”。
-- 中间表示例（HIS→LIS 检验申请）
CREATE TABLE lis_order_mid (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) NOT NULL, -- 申请单号
patient_id VARCHAR(32) NOT NULL, -- 患者主索引
item_code VARCHAR(32) NOT NULL, -- 检验项目代码
status TINYINT DEFAULT 0, -- 0待处理 1已处理 2失败
retry_count INT DEFAULT 0,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);
-- 触发器：新申请单入库后写入通知表
CREATE TRIGGER trg_lis_order_notify
AFTER INSERT ON lis_order_mid
FOR EACH ROW
INSERT INTO lis_notify_queue(order_no, event_type, create_time)
VALUES (NEW.order_no, 'NEW_ORDER', NOW());这段示例体现了“中间表 + 触发器 + 通知队列”的组合：中间表负责落库与审计，触发器负责即时通知，通知队列负责异步解耦。实际项目中，LIS 侧消费通知队列后回写 status=1，失败则 status=2 并累加 retry_count，运维据此对账。
总结来看，HL7 与 DICOM 解决“语义标准”，Web Service 与 REST 解决“传输方式”，消息队列、中间表、视图、触发器解决“落地机制”。选型的核心不是追求新技术，而是让每一层各司其职：标准层保证对得上，协议层保证送得到，机制层保证落得稳、查得清。