医疗影像-检查标识符解析

无名小僧
9 阅读6分钟

医疗影像检查标识符解析

1. DICOM 检查标识符概述

1.1 AccessionNumber 定义

AccessionNumber（检查号）是 DICOM 标准中 Tag (0008,0050) 定义的字段，中文常译为"检查号"或" accession 号"。

官方定义：

A string of characters that leads to the ordering of a particular Study (request). Its position in the Request is to allow the Accession Number to be used as a "key" when looking up Study information in an information system.

简单理解：AccessionNumber 是放射检查请求（Request）中用于排序和检索特定检查的字符串，是检查信息系统的检索"键"。

核心特性：

特性说明
类型字符串（String）
VRSH (Short String)
唯一性在同一个 HIS/RIS 系统中应唯一
业务含义代表一次检查预约或检查请求
生命周期通常在检查登记时生成

1.2 放射检查核心 ID 体系

在 DICOM 标准中，一次放射检查涉及多个层级的标识符，它们构成了一个完整的标识体系：

graph TB
    P["患者层 Patient"] --> S["检查层 Study"]
    S --> SE["序列层 Series"]
    SE --> I["实例层 Instance"]

    P --- P1["PatientID"]
    P --- P2["PatientName"]
    P --- P3["PatientBirthDate"]

    S --- S1["StudyInstanceUID"]
    S --- S2["AccessionNumber"]
    S --- S3["StudyID"]

    SE --- SE1["SeriesInstanceUID"]
    SE --- SE2["Modality"]

    I --- I1["SOPInstanceUID"]
    I --- I2["InstanceNumber"]

2. 放射检查相关 ID 详解

2.1 PatientID (患者标识)

Tag: (0010,0020)

定义：患者在信息系统中的唯一标识符。

特点：

  • 在整个患者生命周期内保持不变
  • 跨不同检查、跨不同医院系统（通过 MPI 机制）可追溯
  • 是患者主索引 (MPI) 的核心字段

示例：

PatientID: "PAT12345678"

2.2 StudyInstanceUID (检查实例UID)

Tag: (0020,000D)

定义：唯一标识一次检查的 UID。

特点：

  • 全局唯一，由生成系统按 DICOM 规范生成
  • 永远不会改变，即使检查被修改
  • 是 DICOM 网络传输和存储的核心检索键

生成规则：基于时间戳 + 随机数，确保全球唯一性

示例：

StudyInstanceUID: "1.2.840.113619.2.55.3.1234567890.1"

2.3 StudyID (检查号)

Tag: (0020,0010)

定义：检查在检查部门内部使用的标识符。

特点：

  • 短字符串，通常为数字
  • 在同一科室内部唯一
  • 不如 StudyInstanceUID 稳定，可能在检查过程中改变

与 AccessionNumber 的区别：

  • StudyID 是检查设备/科室内部的编号
  • AccessionNumber 是放射科信息系统中统一管理的编号

示例：

StudyID: "1" 或 "CT001"

2.4 AccessionNumber (检查号)

Tag: (0008,0050)

定义：用于对特定检查请求进行排序的字符串。

特点：

  • 由 RIS（放射科信息系统）生成
  • 在同一个 RIS 系统中唯一
  • 代表一次检查申请或预约
  • 是检查登记 (Study Registration) 的核心字段

业务含义：

  • 关联到检查申请单 (Order/Request)
  • 是影像检查与临床申请关联的桥梁
  • 用于计费、报告归档等业务环节

示例：

AccessionNumber: "ACC2024031900001"

2.5 SeriesInstanceUID (序列UID)

Tag: (0020,000E)

定义：唯一标识检查中某个序列的 UID。

特点：

  • 同一检查 (Study) 下可有多个序列
  • 每个序列代表一次采集（如 axial、sagittal、coronal）
  • 用于组织和检索系列图像

示例：

SeriesInstanceUID: "1.2.840.113619.2.55.3.1234567890.1.1"

2.6 SOPInstanceUID (实例UID)

Tag: (0008,0018)

定义：唯一标识某个特定 DICOM 实例（如单张图像）的 UID。

特点：

  • 是 DICOM 文件的唯一标识
  • 在整个生命周期内不可改变
  • 用于图像的精确定位和引用

示例：

SOPInstanceUID: "1.2.840.113619.2.55.3.1234567890.1.1.1"

3. ID 之间的关系图解

3.1 层级关系图

graph TB
    P["Patient 患者层"] -->|"1:N| 一个患者可以有多个检查"| S["Study 检查层"]
    S -->|"1:N| 一个检查可以有多个序列"| SE["Series 序列层"]
    SE -->|"1:N| 一个序列可以有多张图像"| I["Instance 实例层"]

    P --- P1["PatientID"]
    P --- P2["PatientName"]
    P --- P3["PatientBirthDate"]

    S --- S1["StudyInstanceUID"]
    S --- S2["AccessionNumber"]
    S --- S3["StudyID"]
    S --- S4["StudyDate"]
    S --- S5["Modality"]

    SE --- SE1["SeriesInstanceUID"]
    SE --- SE2["SeriesNumber"]

    I --- I1["SOPInstanceUID"]
    I --- I2["InstanceNumber"]

3.2 AccessionNumber 与 StudyInstanceUID 的对应关系

一对一关系：

graph LR
    AN["AccessionNumber ACC001"] -->|"生成并关联"| SU["StudyInstanceUID UID.1"]

在绝大多数情况下，一次检查登记生成一个 AccessionNumber，同时 PACS 会为该检查分配一个唯一的 StudyInstanceUID。

3.3 ID 流转示意图

flowchart LR
    O["门诊/住院<br/>开检查单"] --> R["RIS<br/>登记预约"]
    R --> D["影像设备<br/>检查采集"]
    D --> P["PACS<br/>存档调阅"]

    R -->|"生成"| AN["AccessionNumber<br/>(0008,0050)"]
    D -->|"生成"| SU["StudyInstanceUID<br/>(0020,000D)"]

4. AccessionNumber 对应多个 StudyUID 的场景分析

4.1 常规场景：一对一关系

在标准工作流程中，一个 AccessionNumber 通常对应一个 StudyInstanceUID：

graph LR
    AN["AccessionNumber ACC001"] -->|"对应"| SU["StudyInstanceUID UID.1"]

这是因为：

  • 每次检查申请对应一次独立的检查
  • 检查申请单 (Order) 是基本的业务单元
  • 计费、报告归档都以检查申请为单元

4.2 特殊场景：一对多关系

虽然不常见，但在以下业务场景中，一个 AccessionNumber 可能对应多个 StudyInstanceUID：

场景一：合并检查 (Combined Studies)

当多个检查部位或序列需要在同一预约下完成时：

graph TB
    AN["AccessionNumber ACC001"] --> SU1["StudyInstanceUID UID.1"]
    AN --> SU2["StudyInstanceUID UID.2"]
    AN --> SU3["StudyInstanceUID UID.3"]

    SU1 --> M1["胸部 CT"]
    SU2 --> M2["腹部 CT"]
    SU3 --> M3["骨盆 CT"]

典型案例：

  • 全身骨扫描 (Whole Body Bone Scan) + 局部 SPECT/CT
  • PET-CT 全身扫描中的 CT 部分和 PET 部分分开处理
  • 腹部 + 盆腔联合检查
场景二：补充检查 (Add-on Studies)

原始检查后发现需要额外采集：

graph TB
    T0["T0: 登记 ACC001"] --> T1["采集胸部 CT"]
    T1 --> T2["生成 StudyInstanceUID UID.1"]

    T2 --> T3["T1: 临床发现异常"]
    T3 --> T4["补充腹部扫描"]
    T4 --> T5["生成 StudyInstanceUID UID.2<br/>(仍在 ACC001 下)"]

典型案例：

  • CT 增强检查：平扫 + 增强分两次采集
  • 术中冰冻切片后需要再次扫描确认
  • 紧急补充诊断图像
场景三：历史检查关联 (Historical Linkage)

为保持业务连续性，将历史检查关联到新 AccessionNumber：

graph TB
    AN2["AccessionNumber ACC002<br/>(新建申请)"] --> SU5["StudyInstanceUID UID.5<br/>(当前检查)"]
    AN2 --> SU3["StudyInstanceUID UID.3<br/>(历史检查)"]

典型案例：

  • 患者要求将新旧检查对比分析
  • 医疗纠纷保留历史影像
  • 随访检查的基线对比
场景四：检查拆分 (Study Split)

某些情况下一个检查被拆分成多个 Study：

graph TB
    ACC["AccessionNumber ACC001<br/>(膝关节 MRI)"] --> SU1["UID.1<br/>矢状面 T1"]
    ACC --> SU2["UID.2<br/>冠状面 PD"]
    ACC --> SU3["UID.3<br/>横断面 T2"]

典型案例：

  • 不同检查技师的分工采集
  • 设备故障后的图像恢复
  • 多参数 MRI 的分别处理

4.3 一对多关系的影响

影响维度说明
检索复杂度一个 AccessionNumber 需要查询多个 Study
报告显示报告需要关联多个 Study 的图像
计费关联费用可能需要分摊到多个 Study
归档策略多个 Study 可能需要统一的归档管理

4.4 一对多关系图解

graph TB
    RIS["业务系统层 RIS/HIS"]
    AN["AccessionNumber ACC001<br/>(检查申请单/预约)"]

    PACS["影像系统层 PACS"]
    SU1["StudyInstanceUID.1 胸部 CT"]
    SU2["StudyInstanceUID.2 腹部 CT"]
    SU3["StudyInstanceUID.3 骨盆 CT"]
    SE1["SeriesInstanceUID.1.1"]
    SE2["SeriesInstanceUID.2.1"]
    SE3["SeriesInstanceUID.3.1"]

    SU1 --> SE1
    SU2 --> SE2
    SU3 --> SE3

    AN --> SU1
    AN --> SU2
    AN --> SU3

5. 典型工作流程示例

5.1 标准检查流程中的 ID 流转

graph TB
    O1["步骤 1: 门诊开单<br/>患者: 张三, PatientID: PAT123456<br/>申请: 胸部 CT 平扫+增强<br/>生成: AccessionNumber ACC2024031900001"]

    O2["步骤 2: RIS 登记<br/>AccessionNumber: ACC2024031900001<br/>StudyID: CT001 (科室内部号)<br/>预约时间: 2024-03-19 14:00<br/>预约地点: CT 室 1"]

    O3["步骤 3: CT 检查<br/>CT 设备扫描完成<br/>生成: StudyInstanceUID 1.2.840.xxxxx.1<br/>(同时保存 AccessionNumber)"]

    O4["步骤 4: PACS 存档<br/>StudyInstanceUID: 1.2.840.xxxxx.1<br/>AccessionNumber: ACC2024031900001<br/>检查日期: 2024-03-19<br/>图像序列: 3 个 (定位片/平扫/增强)"]

    O5["步骤 5: 影像诊断<br/>医生根据 AccessionNumber 调取图像<br/>撰写报告，关联 StudyInstanceUID<br/>报告归档时再次关联 AccessionNumber"]

    O1 --> O2 --> O3 --> O4 --> O5

5.2 ID 追踪矩阵

业务环节PatientIDStudyInstanceUIDAccessionNumberStudyID
门诊开单✓ 录入-✓ 生成-
RIS 登记✓-✓✓ 分配
设备扫描✓ (继承)✓ 生成✓ (继承)✓ (继承)
PACS 存储✓✓✓✓
报告撰写✓✓✓✓
归档调阅✓✓ (主要键)✓ (辅助键)-

6. 总结

6.1 核心概念对比

标识符层级唯一性生命周期主要用途
PatientID患者层跨系统唯一永久患者身份识别
StudyInstanceUID检查层全球唯一永久PACS 检索、传输
AccessionNumber检查层RIS 内唯一检查周期预约、计费、报告关联
StudyID检查层科室内部可变科室内部管理
SeriesInstanceUID序列层全球唯一永久序列组织
SOPInstanceUID实例层全球唯一永久图像标识

6.2 关键要点

  1. AccessionNumber 是业务键：代表一次检查申请或预约，是放射科信息系统的核心管理单元。

  2. StudyInstanceUID 是技术键：是 DICOM 标准定义的技术标识符，用于 PACS 内部的图像组织和网络传输。

  3. 一对一为主，一对多为辅：绝大多数情况下，一个 AccessionNumber 对应一个 StudyInstanceUID；但在合并检查、补充检查等特殊场景下，可能存在一对多关系。

  4. ID 关联确保数据完整性：通过在 DICOM 头中保存多个关联字段（如同时保存 AccessionNumber 和 StudyInstanceUID），确保不同系统间的数据可追溯、可关联。

6.3 实际应用建议

  • RIS 设计与开发：确保 AccessionNumber 生成算法的唯一性，考虑一对多场景的查询支持
  • PACS 集成：同时索引 AccessionNumber 和 StudyInstanceUID，支持多路径检索
  • 影像调阅：优先使用 StudyInstanceUID 精确检索，支持按 AccessionNumber 批量调阅
  • 数据归档：考虑一个 AccessionNumber 对应多个 Study 的归档策略
avatar
文章
阅读
粉丝