4. DICOM数据解析与元数据提取实战

跨机构影像整合的第一步，是把各厂商设备产出的 DICOM 文件“读得进、读得对、读得全”。DICOM 文件本质是一个由数据元素（Data Element）顺序排列而成的二进制容器，每个元素由标签（Tag）、值表示（VR）、值长度（VL）和值域（Value）四部分组成。标签用 (组号,元素号) 的十六进制表示，例如 (0010,0010) 是患者姓名，(0008,0060) 是模态，(0020,000D) 是检查实例 UID。理解这个“标签—VR—值”的三元结构，是后续一切解析工作的基础。

DICOM 的层级模型是元数据提取的骨架：患者（Patient）→ 检查/研究（Study）→ 序列（Series）→ 图像实例（Instance/SOP）。患者层用 PatientID、PatientName 等标识身份；检查层用 StudyInstanceUID、StudyDate、AccessionNumber 描述一次就诊；序列层用 SeriesInstanceUID、Modality、SeriesNumber 区分同一检查下的不同扫描；图像层用 SOPInstanceUID、InstanceNumber、Rows、Columns、PixelSpacing 描述单帧。跨机构整合时，最关键的匹配键是三个 UID 加 PatientID，而厂商差异往往就藏在这些字段的编码、长度和填充方式里。

工具选择上，DCMTK 与 pydicom 是两条主流路线。DCMTK 是 C++ 工具集，命令行程序 dcmdump、dcm2json、dcmftest 适合批量巡检和快速查看；pydicom 是 Python 库，适合写脚本做结构化提取、清洗和入库。实际工程中常见组合是：先用 dcmdump 抽样确认文件可读性，再用 pydicom 编写提取管道。下面给出一个可运行的 pydicom 提取示例，覆盖四个层级的关键属性。

import pydicom
from pydicom.errors import InvalidDicomError

def extract_meta(path):
    try:
        ds = pydicom.dcmread(path, stop_before_pixels=True,
                             force=False)
    except InvalidDicomError:
        return {"status": "not_dicom", "path": path}

    def g(tag, default=""):
        v = ds.get(tag, default)
        return str(v).strip() if v is not None else default

    return {
        "status": "ok",
        "PatientID":       g("PatientID"),
        "PatientName":     g("PatientName"),
        "StudyInstanceUID":g("StudyInstanceUID"),
        "StudyDate":       g("StudyDate"),
        "AccessionNumber": g("AccessionNumber"),
        "SeriesInstanceUID":g("SeriesInstanceUID"),
        "Modality":        g("Modality"),
        "SeriesNumber":    g("SeriesNumber"),
        "SOPInstanceUID":  g("SOPInstanceUID"),
        "InstanceNumber":  g("InstanceNumber"),
        "Rows":            g("Rows"),
        "Columns":         g("Columns"),
        "PixelSpacing":    g("PixelSpacing"),
        "Manufacturer":    g("Manufacturer"),
    }

这段代码有两个工程要点。第一，stop_before_pixels=True 让解析在像素数据前停止，元数据提取不需要加载动辄几十 MB 的像素，速度可提升一个数量级。第二，force=False 保证遇到非 DICOM 文件时抛异常而不是强行解析，便于在批量任务中把“坏文件”单独隔离。返回字典里特意保留了 Manufacturer，因为厂商差异分析必须以此为依据。

多厂商差异是实战中最容易踩坑的地方。GE、Siemens、Philips、Canon 等设备在标准字段之外，还会写入大量私有标签（组号为奇数，如 (0009,xxxx)、(0019,xxxx)）。这些私有标签不能作为跨机构匹配依据，但可能携带重建参数、剂量信息等有价值内容。另一个常见差异是字符集：中文患者姓名可能以 GB18030、ISO_IR 100 或 UTF-8 编码，pydicom 会依据 (0008,0005) SpecificCharacterSet 自动解码，但若该标签缺失或厂商写错，就会出现乱码。此时需要显式指定编码重新读取，例如 pydicom.dcmread(path, specific_charset="GB18030")。

UID 的处理同样需要谨慎。DICOM UID 是数字加点组成的字符串，最大长度 64 字节，且必须以偶数长度存储（不足时补空字符 \x00）。部分老设备会在 UID 尾部留下填充符，直接入库会导致同一检查被识别为两条记录。稳妥做法是提取后统一执行 uid.strip().rstrip("\x00")，并校验是否符合 ^[0-9.]{1,64}$ 的正则。日期字段 StudyDate 标准格式为 YYYYMMDD，但个别设备会写成 YYYY.MM.DD 或空值，入库前应做格式归一化。

把上述逻辑串成批量管道时，建议按“扫描—解析—校验—归一化—入库”五步组织，但每一步都要有明确的失败出口。扫描阶段用 os.walk 收集文件并记录路径；解析阶段对每个文件调用 extract_meta，捕获异常并写入错误日志；校验阶段检查 UID 正则、日期格式、必填字段是否为空；归一化阶段统一编码、去填充、格式化日期；入库阶段以 SOPInstanceUID 为主键做幂等写入，避免重复导入。一个常见的判断依据是：若某目录下超过 5% 的文件返回 not_dicom，应暂停入库并人工排查，而不是继续污染数据表。

最后需要强调，元数据提取不是“读出来就完事”，而是要为跨机构整合建立可信的键值体系。患者层和检查层的 UID 是跨机构对齐的主键，序列层和图像层的 UID 用于内部完整性校验。厂商私有标签可以保留在扩展字段中供后续分析，但绝不能进入匹配逻辑。只有把“标准字段归一化、私有字段隔离、UID 严格校验”这三件事做扎实，后续的影像去标识、索引构建和跨院调阅才有可靠的数据基础。