1. 课程导入与工程全景

医学影像数据治理并不是“把 DICOM 文件拷来拷去”这么简单。它要解决的是：影像数据从产生、流转、存储、使用到销毁的全生命周期中，如何保证合规、可用、可追溯、可审计。在真实工程里，数据治理的范畴通常横跨四类工作：数据接入与标准化、质量与完整性管理、安全与隐私保护、以及面向科研或 AI 的数据交付。匿名化（Anonymization）只是安全与隐私保护中的一环，但它往往是最先被问到、也最容易做错的一环。

先厘清一个常见误区：匿名化不等于“删掉姓名”。DICOM 文件里除了 PatientName，还有 PatientID、AccessionNumber、StudyDate、InstitutionName、ReferringPhysicianName、私有标签（Private Tags）、以及可能被烧录进像素的 PHI（Burned-in Annotation）。如果只改一个字段，数据仍然可能通过“日期+机构+检查号”被重新识别。因此，工程上更准确的说法是：去标识化（De-identification），即按照既定规则移除或替换一组标识符，使数据在目标使用场景下不再能直接或间接关联到个人。

为了把“闸门”放到正确的位置，先看一张工程全景图。下图不是流程图，而是数据域与角色关系图：左侧是数据源与原始区，中间是治理与匿名化处理链，右侧是交付与使用区；下方标注了典型角色与关键交付物。图中每个对象都对应真实工程中的系统、文件或角色，而不是抽象概念。

从图中可以看到，匿名化位于“治理与匿名化处理链”的第②步，但它并不是孤立的一步。它依赖第①步的标准化结果（例如字符集统一、Study/Series 层级整理），又为第③步的质量检查提供输入，同时必须被第④步的审计覆盖。工程上常见的失败模式是：只做标签替换，不做像素脱敏；或者做了匿名化，但没有保存映射表，导致后续无法回溯或无法做纵向随访。

接下来明确本课程中反复出现的几个核心对象与参数。DICOM 标签是匿名化的基本操作单元，常用标签包括：

• PatientName (0010,0010)：通常替换为匿名代号，如 ANON_0001。
• PatientID (0010,0020)：替换为与映射表一致的伪 ID，保持同一患者跨检查一致。
• StudyDate (0008,0020) / SeriesDate (0008,0021)：常用“日期偏移”策略，例如统一减去 180 天，保留时间间隔关系。
• AccessionNumber (0008,0050)：通常清空或替换，避免与 RIS 关联。
• InstitutionName (0008,0080)：可替换为泛化值，如 SITE_A。
• ReferringPhysicianName (0008,0090)：清空或替换。
• 私有标签 (Private Tags)：必须逐厂商检查，很多设备会在私有标签中写入患者信息。

UID 的处理是另一个关键点。DICOM 的 SOPInstanceUID、StudyInstanceUID、SeriesInstanceUID 必须保持唯一性和引用一致性。工程做法是：使用确定性重映射，即同一原始 UID 始终映射到同一新 UID，通常基于 HMAC-SHA256 加盐生成，而不是随机 UUID。这样既能去标识，又能保证 Study/Series/Instance 之间的引用关系不被打断。示例参数：盐值长度 32 字节，输出 UID 前缀 1.2.826.0.1.3680043.10.999.，后接哈希截断值。

像素脱敏同样不能忽略。超声、X 光、部分 CT 定位像中常出现烧录文字（Burned-in Annotation），例如患者姓名、检查日期、机构名称。处理方式有两种：一是用矩形区域遮盖（Redaction），二是用 OCR 检测后替换。工程上建议先做 OCR 扫描，输出可疑区域坐标，再人工确认或自动遮盖。验收时可用 DICOM 查看器逐帧检查，或编写脚本统计像素中是否残留文字特征。

本课程最终要交付的不是“一个脚本”，而是一套可复现的工程能力。课程项目设定如下：给定一批脱敏前的 DICOM 数据（示例数据约 200 个 Study，涵盖 CT 和 MR），要求完成从接入、匿名化、质量检查到交付的完整流程，并输出以下成果：

1. 一份匿名化规则配置表，明确每个标签的动作（清空、替换、偏移、保留）。
2. 一个可运行的匿名化处理脚本或工具配置，支持批量处理并生成日志。
3. 一份数据质量报告，包含缺失序列、像素异常、UID 引用完整性检查结果。
4. 一份审计说明，记录处理时间、操作人、规则版本和映射表存放位置。