2. 医学影像数据标准与互操作基础

跨机构医学影像整合的第一道门槛不是网络带宽，而是“语义对齐”：A 医院说“胸部 CT 平扫”，B 医院说“CT 胸部 无增强”，如果双方对数据模型、编码和传输方式没有共同约定，即便文件能传过去，接收方也无法可靠地重建检查、序列与图像之间的层级关系。本节围绕 DICOM 信息模型、服务类与 SOP 类、传输语法，以及 HL7/FHIR 与影像报告的关联、IHE XDS/XDS-I 框架，梳理跨机构互操作真正依赖的标准骨架。

一、DICOM 信息模型：从患者到像素的四层结构

DICOM 的核心是“以患者为中心的层级信息模型”。最上层是 Patient（患者），由 Patient ID、姓名、出生日期等属性标识；其下是 Study（检查），代表一次就诊或一次检查申请，由 Study Instance UID 唯一标识；再往下是 Series（序列），表示同一采集条件下产生的一组图像，由 Series Instance UID 标识；最底层是 Instance（实例/图像），由 SOP Instance UID 标识。四层之间通过 UID 引用形成树状关系，而不是靠文件夹路径。

跨机构整合时，最常出问题的是 UID 的全局唯一性与一致性。Study Instance UID 一旦生成，就应贯穿整个检查生命周期，不能因为转院、复制或重新导入而改变。若某机构在导入外部数据时重新生成了 UID，就会导致同一检查在整合平台中出现两份，破坏后续的影像调阅与报告关联。因此，工程上通常要求：外部数据导入时保留原始 UID，仅在确认为新检查时才生成新 UID。

二、服务类与 SOP 类：DICOM 的“动词”与“名词”

DICOM 把网络操作抽象为 服务类（Service Class），把被操作的对象抽象为 SOP 类（Service-Object Pair Class）。服务类是“动词”，例如 C-STORE（存储）、C-FIND（查询）、C-MOVE（移动）、C-GET（获取）、C-ECHO（验证）；SOP 类是“名词”，例如 CT Image Storage、MR Image Storage、Secondary Capture Image Storage。二者组合成“对某类对象执行某类操作”的完整语义。

跨机构影像调阅通常走 Query/Retrieve 流程：调阅端先发 C-FIND，按 Patient ID、Study Date、Modality 等条件查询目标检查，拿到 Study Instance UID 和 Series Instance UID 后，再发 C-MOVE 或 C-GET 把图像拉回本地。这里的关键参数是 Query/Retrieve Level：PATIENT、STUDY、SERIES、IMAGE 四级，级别选错会导致返回结果过粗或过细。例如只想列出某患者的所有检查，应使用 STUDY 级；要定位到具体序列，则用 SERIES 级。

三、传输语法：字节层面的互操作

传输语法决定 DICOM 数据集的编码方式，包括字节序（小端/大端）、VR 表示方式（隐式/显式）以及像素数据是否压缩。常见取值包括 Implicit VR Little Endian、Explicit VR Little Endian、Explicit VR Big Endian、JPEG Lossless、JPEG 2000、RLE 等。跨机构传输时，双方必须在 Association 协商阶段就传输语法达成一致；若一方只支持未压缩，另一方只提供 JPEG 2000，则需要在网关侧做转码。

工程上建议：归档层保留原始传输语法，展示层按需转码为浏览器可解码的格式（如 JPEG 基线或 JPEG 2000）。转码会引入有损风险，因此必须记录原始 SOP Instance UID 与转码后实例的对应关系，避免报告关联断裂。

四、HL7/FHIR 与影像报告的关联

DICOM 负责影像与影像元数据，HL7 v2 与 FHIR 负责患者、就诊、医嘱和报告等临床信息。跨机构整合中，常见做法是：用 HL7 v2 的 ORM/ORU 消息或 FHIR 的 ImagingStudy、DiagnosticReport、Observation 资源承载检查申请与报告文本，再通过 Study Instance UID 与 DICOM 影像建立关联。FHIR 的 ImagingStudy 资源中，identifier 可放 Study Instance UID，series.instance.uid 可放 SOP Instance UID，subject 指向 Patient，encounter 指向就诊。这样，报告系统只需持有 Study UID，就能反查到全部影像。

实际落地时，最容易出错的是“报告与影像对不上”。常见原因有三类：一是报告中的 Accession Number 与 DICOM 中的 Accession Number 不一致；二是 Study UID 在导入时被重新生成；三是患者主索引未对齐，导致同一患者被拆成多条记录。排查时应先核对 Accession Number 与 Study UID，再核对 Patient ID 映射表。

五、IHE XDS/XDS-I：跨机构文档与影像共享框架

IHE XDS（Cross-Enterprise Document Sharing）定义了一套基于文档的跨机构共享架构，核心角色包括文档源（Document Source）、文档库（Document Repository）、文档注册中心（Document Registry）、文档消费方（Document Consumer）。XDS-I（XDS for Imaging）在此基础上扩展了影像文档的共享，增加了 Imaging Document Source 和 Imaging Document Consumer，并引入 WADO（Web Access to DICOM Objects）用于按需拉取影像。

XDS 的关键机制是“注册与存储分离”：文档内容存在 Repository，元数据注册到 Registry，消费方先查 Registry 拿到文档唯一标识，再去 Repository 取内容。元数据使用 ebXML RIM 定义，包含 patientId、classCode、confidentialityCode、formatCode、uniqueId 等字段。跨机构部署时，通常由区域影像平台承担 Registry 与 Repository 角色，各医院通过 XDS-I 接口注册和调阅。

六、最小可用的互操作检查清单