3. DICOM信息模型与患者-检查-序列层级

DICOM 并不是把一张影像当作一个孤立文件来管理，它首先定义了一套信息模型：现实世界中的患者、就诊过程、检查行为和具体影像对象，被映射成四个逐级包含的实体——Patient（患者）、Study（检查）、Series（序列）、Instance（实例）。理解这四层模型，是后续做数据入库、检索、去重、归档和跨系统交换的基础。因为几乎所有 DICOM 查询、存储和路由操作，最终都落在“用哪一级的 UID 去定位哪一级的对象”这个问题上。

四层模型：从人到一张影像

四层之间是“一对多”的包含关系，而不是并列关系。一个 Patient 可以有多次 Study；一次 Study 通常包含多个 Series；一个 Series 包含多个 Instance（即一张影像或一个 SOP 实例）。每一层都有自己的标识符，且这些标识符在全局范围内唯一。

  • Patient（患者层）：由 Patient ID、姓名、出生日期、性别等属性描述。Patient ID 是院内或域内的患者主索引，通常由 HIS/RIS 分配，不是 DICOM 全局唯一标识。
  • Study（检查层）：一次检查对应一次就诊或一次影像申请，由 Study Instance UID 唯一标识，并携带 Study Date、Accession Number、Study ID、检查描述等。
  • Series（序列层）：一次检查中按采集方式、方位、序列参数划分的影像集合，由 Series Instance UID 标识，携带 Modality、Series Number、Body Part 等。
  • Instance（实例层）：单个 SOP 实例，由 SOP Instance UID 标识，携带 Instance Number、SOP Class UID 等，是实际存储和传输的最小单位。

需要特别区分两类 UID：SOP Class UID 描述“这是什么类型的对象”，例如 CT 图像存储、MR 图像存储、结构化报告等，它标识的是对象的类别；SOP Instance UID 描述“这是哪一个具体对象”，它标识的是该类别下的一个唯一实例。前者像“型号”，后者像“序列号”。

DICOM 四层信息模型与 UID 定位关系 Patient 患者层 Patient ID（院内主索引） · 姓名 · 出生日期 · 性别 定位键：Patient ID + Issuer（非全局唯一） Study 检查层 Study Instance UID（全局唯一） · Study Date · Accession Number · Study ID 定位键：Study Instance UID Series 序列层 Series Instance UID（全局唯一） · Modality · Series Number · Body Part 定位键：Study UID + Series Instance UID Instance 实例层 SOP Instance UID（全局唯一） · SOP Class UID · Instance Number 定位键：SOP Instance UID（最小存储单位） 1 : N 1 : N 1 : N SOP Class UID 对象“类型” 如 CT Image Storage

UID 的生成规则

DICOM UID 是一串由数字和点号组成的字符串，最长 64 个字符，采用“根 + 后缀”的结构。根部分由组织向 ISO 或 DICOM 注册机构申请获得，保证全球不冲突；后缀部分由本地系统自行分配。生成时必须满足两个硬性约束：全局唯一和长度不超过 64 字符。

一种常见且合规的生成方式是：使用已注册的根（例如 1.2.840.xxxxx），拼接日期时间、设备标识和随机/递增序号。例如：

根:        1.2.840.113619.2.55.3
日期:      20240517
设备号:    0001
序号:      000001
结果:      1.2.840.113619.2.55.3.20240517.0001.000001

实际工程中更推荐使用 UUID 派生法：先生成 128 位 UUID，去掉连字符后转成十进制大整数，再拼接到根后面。这样既避免时间回拨导致的重复，也便于分布式系统各自独立生成而不冲突。无论哪种方式，生成后都应做一次长度校验和格式校验（只允许数字和点，且不以点开头或结尾）。

UID 的解析与层级定位

UID 本身不携带语义，不能从字符串直接读出“这是第几次检查”。解析的本质是用 UID 作为键去查询数据库或索引。在 PACS 或影像数据平台中，通常建立如下索引关系：

层级主键外键/关联典型查询
PatientPatient ID + Issuer—按患者查所有检查
StudyStudy Instance UIDPatient ID按检查 UID 查序列列表
SeriesSeries Instance UIDStudy Instance UID按序列 UID 查实例列表
InstanceSOP Instance UIDSeries Instance UID按实例 UID 取影像文件

解析时要注意：Study Instance UID 在同一个检查的所有序列和实例中保持不变，这是跨层关联的关键。也就是说，一个 CT 检查下的平扫序列、增强序列、定位像序列，虽然 Series Instance UID 各不相同，但它们的 Study Instance UID 完全一致。同理，同一序列下所有切片的 Series Instance UID 相同，只有 SOP Instance UID 不同。

判断两个文件是否属于同一次检查，比较 Study Instance UID 即可；判断是否属于同一序列，比较 Series Instance UID；判断是否为同一张影像，比较 SOP Instance UID。不要用 Patient ID 或 Study Date 做唯一性判断，它们可能重复。

实际数据流中的层级传递

在 DICOM 网络传输（如 C-STORE、C-FIND）中，四层 UID 是随数据集一起传递的。以一次 CT 检查上传为例：设备生成 Study Instance UID 后，该检查下所有序列共用它；每个序列生成自己的 Series Instance UID；每张切片生成独立的 SOP Instance UID，并携带对应的 SOP Class UID（如 1.2.840.10008.5.1.4.1.1.2 表示 CT 图像存储）。接收端按这些 UID 建立索引，就能还原出完整的层级树。

常见错误：把 SOP Class UID 当成实例唯一标识。SOP Class UID 只说明“这是 CT 图像”，同一检查中成百上千张切片共享同一个 SOP Class UID，真正区分每一张的是 SOP Instance UID。入库时若用 SOP Class UID 做唯一键，会导致大量覆盖或冲突。

工程实践中的校验要点

在数据接入环节，建议对每条记录做以下检查：Study/Series/SOP Instance UID 是否为空、是否符合 DICOM UID 格式、长度是否超限；同一 Study Instance UID 下的 Patient ID 是否一致；同一 Series Instance UID 下的 Modality 是否一致。这些校验能提前发现设备配置错误或数据拼接问题。对于需要跨院交换的场景，还要确认 UID 根是否来自已注册的组织，避免与外部数据冲突。

掌握四层模型和 UID 机制后，后续的查询检索、去重合并、归档迁移和权限控制，都可以围绕“在哪一层、用哪个 UID、关联到哪一层”来设计，而不是把 DICOM 文件当作普通文件堆来处理。

← 上一章 📖 返回目录 下一章 →