删除患者姓名，影像就能安全分享了吗？不一定。DICOM 文件可能在元数据、嵌套序列、私有标签、像素文字或关联报告中保存识别信息；文件名和数据导出表也可能暴露身份。DICOM 标准明确指出，属性保密配置本身不能保证整个信息对象已经脱敏。

本文面向医疗影像研发与数据管理团队，介绍一种基于风险的脱敏思路。具体规则应结合使用目的、接收方、适用法规和组织流程确定；示例不构成可直接用于生产的完整脱敏工具。

一、先定义要解决的问题

明确数据用于教学、研发、临床研究还是公开发布；接收者是谁，是否能够再分享，是否需要保留同一患者的纵向关系。内部受控研究与公开发布面临的再识别风险不同，不能使用同一套规则后就认为结果一定安全。

制定数据清单：模态、厂商、影像类型、派生对象、结构化报告和其他附带文件。确定哪些字段必须删除、替换、进行一致映射或在经过风险评估后保留，并记录负责人和规则版本。

二、元数据：姓名以外还有什么？

患者编号、出生日期、检查日期、机构、操作者、描述字段和自由文本都可能暴露身份；某些识别信息还可能出现在嵌套序列中。私有标签的含义因厂商而异，不能只检查几个常见标准标签。

DICOM PS3.15 附录 E 定义了属性保密配置和选项，用于指导属性的移除或替换。标准同时指出，这些配置应是完整脱敏流程的一部分，不保证对象中所有可识别信息都已去除。DICOM 标准

三、像素文字、叠加层和报告

某些影像可能把姓名或检查信息直接烧录在像素中，超声图像、截图和扫描文档尤其需要关注。删除元数据不会改变像素；需要根据场景使用人工检查或合适的文字检测工具，并验证遮挡不会破坏所需的医学信息。

还应检查叠加层、结构化报告、封装文档、截图和派生对象。不能依赖单个标志字段就断定不存在烧录信息；抽样复核应覆盖不同厂商、模态和异常文件。

四、UID 映射为什么要保持一致？

DICOM 对象通过 Study、Series、SOP Instance 等 UID 建立关联。替换 UID 时，如果同一个原 UID 在不同对象中被映射为不同新 UID，影像、报告或标注之间的引用可能断裂；直接保留原 UID 又可能保留与原系统关联的线索。

一种工程思路是对同一批数据使用受控的一致映射，并检查所有引用。若业务需要可逆映射，映射表必须与输出数据隔离、严格授权、留痕并按规定管理；若不需要恢复身份，应避免保留不必要的关联信息。具体映射方式和保留期限需要风险评估。

五、日期与研究价值之间的权衡

研究可能需要时间间隔，而真实检查日期可能提高识别风险。可由合规与研究团队评估是否删除、替换或按规则处理日期，同时检查同一患者的事件顺序和间隔是否满足研究需求。不存在对所有研究都合适的统一偏移策略。

此外，罕见疾病、年龄、地区和特殊事件组合可能使个人重新被识别。即便单个字段不含姓名，与其他公开信息关联仍可能存在风险；访问控制、数据使用协议和接收方管理也是脱敏流程的一部分。

六、建立可复现的验证流水线

准备覆盖多个厂商、模态、私有标签、嵌套序列、烧录文字、损坏文件和派生对象的测试集。检查规则是否按预期执行、引用是否完整、文件能否被目标软件读取、必要研究信息是否保留。对失败或无法可靠处理的对象隔离待审，不能默认放行。

输出前检查文件名、目录、压缩包注释、导出清单及日志。随机抽查与针对高风险对象的重点检查应共同进行；记录脱敏工具版本、配置、样本范围、失败项和人工复核结果。

七、工具选择与常见误区

pydicom、DCMTK 和 GDCM 等库可以帮助读取或处理 DICOM 数据，但“能改标签”不等于完成合规脱敏。工具的默认行为、支持的对象类型、私有标签处理和像素处理能力都需要验证。不要在真实患者数据上直接运行未经审查的示例脚本。

常见误区包括只清空姓名、忽略像素文字、把同一 UID 映射成不同值、把映射表放在输出目录、忽略派生报告，以及认为脱敏后就可以无条件公开。每一项都可能让技术正确的某一步无法实现整体目标。

参考资料：DICOM PS3.15 附录 E；pydicom 文档。

不积跬步，无以至千里。——《荀子》