📚 课程目录第3章 PACS通信协议与接口

3. PACS通信协议与接口

在PACS影像AI在线推理集成工程中，AI推理服务并不是孤立运行的，它必须与PACS、RIS、HIS以及临床工作站之间形成稳定的数据交换闭环。这个闭环的底层依赖两类协议族：一类是DICOM服务类，负责影像对象的查询、检索、传输与存储；另一类是HL7与FHIR，负责患者、检查、报告等临床信息的交换。理解这些协议各自解决什么问题、在什么场景下使用，是后续接口适配和工程落地的基础。

DICOM服务类：影像数据交换的核心机制

DICOM协议采用客户端-服务端模型，通过DIMSE（DICOM Message Service Element）定义了一组服务类。在PACS集成中最常用的是C-STORE、C-FIND、C-MOVE和C-GET。它们并不是可以随意替换的，而是分别对应不同的操作语义。

C-STORE是推送式存储服务。发送方（SCU）主动将DICOM对象推送到接收方（SCP），接收方返回状态码表示是否成功接收。在AI推理场景中，当推理服务生成结构化报告或二次标注影像后，通常通过C-STORE将结果对象回写到PACS。C-STORE的关键参数包括SOP Class UID、SOP Instance UID、Transfer Syntax UID以及AE Title。状态码0x0000表示成功，0xA700表示资源不足，0xA900表示数据集与SOP类不匹配，工程中需要根据状态码决定重试或告警。

C-FIND是查询服务，用于在PACS中检索符合条件的研究、序列或实例。它不传输影像数据，只返回匹配记录的属性集合。典型用法是AI调度服务通过C-FIND查询“某时间段内、某设备来源、某检查部位”的研究列表，再决定哪些研究需要进入推理队列。C-FIND的查询条件通过Query/Retrieve Level（Patient/Study/Series/Image）和匹配键（如PatientID、StudyDate、Modality）组合表达。需要特别注意的是，不同厂商对通配符匹配、返回字段完整性和分页行为的支持差异较大。

C-MOVE是拉取式传输服务。请求方（SCU）向PACS发起C-MOVE，指定目标AE Title，PACS作为SCP将影像通过C-STORE推送到目标节点。也就是说，C-MOVE的发起方并不直接接收数据，而是由PACS将数据“转推”到第三方。在AI推理集成中，如果推理节点希望从PACS获取影像，通常由调度服务发起C-MOVE，将影像推送到推理节点的C-STORE SCP端口。

C-GET与C-MOVE类似，但数据直接返回给请求方本身，不需要指定第三方AE Title。C-GET在某些PACS上支持较好，在另一些厂商实现中则被限制或禁用。工程选型时，如果推理节点本身具备C-STORE SCP能力，C-GET可以减少一次网络跳转；如果PACS对C-GET支持不完整，则应优先使用C-MOVE。

HL7消息与FHIR影像资源

DICOM解决的是影像对象层面的交换，而检查申请、患者基本信息、报告状态等临床上下文通常由HL7承载。HL7 v2消息以段（Segment）和字段（Field）的管道分隔格式表达，例如ADT^A01表示患者入院，ORM^O01表示医嘱消息，ORU^R01表示结果报告。在AI推理集成中，HL7消息常用于触发推理任务：当RIS发出“检查已完成”的消息时，集成引擎可以解析消息中的患者ID和检查号，再通过DICOM C-FIND定位对应研究。

FHIR则是更现代的RESTful资源模型。与影像AI集成最相关的是ImagingStudy、DiagnosticReport、Patient和ServiceRequest资源。ImagingStudy资源通过identifier、subject、series等字段描述一次影像检查，其中series.instance字段可以关联到DICOM SOP Instance UID。FHIR的优势在于JSON/XML结构化表达、标准HTTP方法和统一资源寻址，适合与Web化的AI服务对接。但需要注意，FHIR本身不传输像素数据，它只提供元数据和引用，实际影像仍需通过DICOM获取。

PACS厂商接口差异与适配方法

不同PACS厂商对DICOM服务类的实现存在显著差异，这是集成工程中最容易踩坑的地方。常见差异包括：C-FIND返回字段不完整或顺序不一致；C-MOVE目标AE Title校验严格，未注册的AE会被拒绝；C-GET被禁用或仅支持部分SOP类；字符集处理不一致导致中文患者姓名乱码；Transfer Syntax协商失败导致传输中断；以及查询分页行为不同，部分PACS不支持分页而一次性返回大量结果。

适配的基本策略是“先探测、再抽象、后容错”。探测阶段通过DICOM Echo（C-ECHO）验证连通性，再用小范围C-FIND确认返回字段和字符集。抽象阶段将厂商差异封装在适配层中，对上层暴露统一的查询、拉取、回写接口。容错阶段针对状态码和超时设计重试、降级和告警策略。例如，当C-MOVE返回0xA801（移动目标未知）时，应检查目标AE Title是否已在PACS中注册；当C-STORE返回0xA900时，应核对SOP Class UID与数据集是否匹配。

工程建议：在集成初期建立一份“PACS能力矩阵”，逐项记录目标PACS对C-FIND、C-MOVE、C-GET、字符集、Transfer Syntax、AE Title注册方式的支持情况。这份矩阵可以直接指导适配层配置和测试用例设计，避免在联调阶段反复试错。

下面给出一个适配层配置示例，用于描述不同PACS节点的能力差异。该示例为教学用途的合理假设，实际字段应根据项目情况调整。

pacs_nodes:
  - name: "PACS_A"
    ae_title: "AI_GATEWAY"
    host: "10.10.20.31"
    port: 104
    c_find: true
    c_move: true
    c_get: false
    charset: "ISO_IR 100"
    transfer_syntax:
      - "1.2.840.10008.1.2.1"   # Explicit VR Little Endian
      - "1.2.840.10008.1.2"     # Implicit VR Little Endian
    move_destination_ae: "AI_INFER"
    query_page_size: 200

  - name: "PACS_B"
    ae_title: "AI_GATEWAY"
    host: "10.10.20.45"
    port: 11112
    c_find: true
    c_move: true
    c_get: true
    charset: "GB18030"
    transfer_syntax:
      - "1.2.840.10008.1.2.1"
    move_destination_ae: "AI_INFER"
    query_page_size: 0   # 0表示不支持分页

在实际联调中，建议按以下顺序验证：先执行C-ECHO确认网络与AE Title可达；再用C-FIND查询一条已知研究，检查返回字段是否包含StudyInstanceUID、SeriesInstanceUID和SOPInstanceUID；然后发起C-MOVE，确认影像能推送到推理节点的C-STORE SCP端口；最后验证推理结果通过C-STORE回写PACS后，能在工作站中正常打开。每一步都应记录状态码和耗时，作为后续排障的基线。

对于HL7和FHIR路径，适配重点在于消息映射和资源转换。HL7 v2消息需要解析MSH、PID、OBR等段，提取患者ID、检查号和检查状态；FHIR则需要处理资源引用和分页Bundle。无论走哪条路径，最终都要落到DICOM层面的研究定位和影像获取，因此DICOM服务类的稳定性是整个集成链路的基础。