3. 跨系统接口基础与协议选型

检测结果从检验科信息系统（LIS）流向电子病历（EMR）、区域检验平台、公卫上报系统或患者端时，真正决定“能不能通、通得稳不稳”的，往往不是数据本身，而是接口协议的选择。同一份血常规结果，用 REST 传和用 HL7 v2 传，语义表达、错误处理、扩展能力和运维成本完全不同。本节不追求把每种协议讲全，而是围绕“检测结果交换”这一具体场景，厘清五种主流方式的适用边界与选型依据。

先看数据形态：结果交换到底在传什么

一份检测结果的最小语义单元通常包含：患者标识（如病案号、就诊号）、标本信息（标本号、采集时间）、检验项目（项目代码、名称）、结果值（数值、单位、参考区间）、异常标志（H/L/危急值）、审核状态与报告时间。不同协议的差异，本质上是“如何承载这些字段、如何表达层级关系、如何确认送达”。

例如一个血钾结果：项目代码 K，结果值 6.8 mmol/L，参考区间 3.5–5.3，异常标志 H，危急值标记为真。这个结构在 REST+JSON 中是一段嵌套对象，在 HL7 v2 中是 OBX 段，在 FHIR 中是 Observation 资源。理解这一点，选型时就不会只比较“哪个新”，而会比较“哪个能准确表达我的结果语义”。

五种方式的定位与边界

REST（含 JSON/XML）：基于 HTTP 的轻量接口，适合系统间点对点、实时性要求中等、字段结构相对稳定的场景。优点是开发门槛低、调试直观、易与 Web 前端和移动端集成；缺点是缺乏医疗领域统一的语义约束，患者、标本、结果之间的层级关系需要自行约定，跨机构对接时容易出现“字段名一样、含义不同”的歧义。适合院内 LIS 与 EMR 的定制化对接、患者端报告查询。

FHIR：以资源（Resource）为核心的标准，Observation、Patient、Specimen、DiagnosticReport 等资源天然对应检测结果交换中的对象。优点是语义明确、支持 RESTful 交互、扩展机制规范，适合区域平台、多机构互操作、需要长期演进的接口。代价是学习曲线较陡，服务端实现和校验成本高于普通 REST，对老系统改造压力较大。

HL7 v2：以消息段（MSH、PID、OBR、OBX 等）为核心的经典标准，在检验领域沉淀深厚，绝大多数 LIS 和仪器接口都原生支持。优点是成熟、稳定、仪器厂商支持度高，适合 LIS 与检验仪器、院内系统之间的结果传输。缺点是版本碎片化（v2.3、v2.4、v2.5 并存）、字段位置依赖强、扩展需借助 Z 段，跨版本解析容易出错。

WebService（SOAP/WSDL）：基于 XML 的强契约接口，适合对事务性、安全性、跨平台一致性要求高的场景，如部分区域平台和医保接口。优点是契约明确、支持 WS-Security；缺点是报文冗长、调试繁琐、性能开销大，在轻量级结果查询场景中逐渐被 REST/FHIR 替代。

消息队列（MQ）：不是数据格式，而是传输机制，常与 HL7 v2 或 JSON 消息配合使用。适合结果批量推送、异步解耦、削峰填谷，例如 LIS 审核完成后向多个订阅方广播报告。优点是可靠投递、支持重试与顺序控制；缺点是引入中间件运维成本，且“消息送达”不等于“业务处理成功”，需要额外的确认与对账机制。

选型时真正要问的四个问题

第一，对接双方是否属于同一机构、同一厂商体系。院内同厂商系统，REST 或 HL7 v2 都能快速落地；跨机构、跨厂商，FHIR 或带明确契约的 WebService 更能降低歧义。

第二，结果是否需要被多个下游同时消费。若一份报告要同时推给 EMR、区域平台、患者端和质控系统，用 MQ 广播比让 LIS 逐个调用接口更可靠，也更容易做失败重投。

第三，实时性要求是“秒级”还是“分钟级”。急诊危急值需要秒级触达，适合 REST 或 MQ 直推；常规批量报告可接受分钟级延迟，用 MQ 异步更稳。

第四，接口的生命周期有多长。临时科研对接可以用轻量 REST；要运行五年以上的区域互操作接口，应优先考虑 FHIR 这类有标准演进路径的协议。

一个可参考的选型判断表

落地时必须补上的三个约束

无论选哪种协议，检测结果交换都要明确三件事。其一是患者与标本的匹配规则：以病案号还是就诊号为主键，标本号是否全局唯一，跨系统时如何避免张冠李戴。其二是结果状态机：初步、审核、更正、危急值已通知，这些状态必须在接口字段中可表达，否则下游无法判断报告是否可发布。其三是确认与对账：发送方要能知道对方是否成功接收并入库，MQ 场景下尤其要区分“消息已投递”和“业务已处理”，建议以报告唯一号做定时对账。

把协议选型与这三条约束一起考虑，接口才不只是“能通”，而是“结果可信、状态可追、异常可查”。