多年以前，我们做过一款非常朴素的 DICOM 文件批量脱敏工具。长这个样子。

它的目标很简单：
针对医学影像 DICOM 文件中的患者姓名、医院名称、医院地址等敏感字段进行处理，支持批量选择文件夹、设置匿名化或删除规则，然后输出脱敏后的 DICOM 文件。

那个版本功能不复杂，界面也比较原始，但在当时解决了一个非常实际的问题：
医学影像数据想要用于测试、研发、教学、算法训练和数据共享，第一步必须先把敏感信息处理干净。

几年过去了，医学影像数据的价值越来越高，数据安全要求也越来越严格。
于是，我们终于重新做了一款更加专业、更加适合真实业务场景的 DICOM 脱敏专用工具。

一、为什么现在更需要专业的 DICOM 脱敏工具？

这几年，“数据要素”已经成为医疗信息化建设中非常重要的关键词。

医院沉淀了大量高价值数据，其中医学影像数据尤其典型：

CT、MR、DR、超声等影像数据量大；
DICOM 文件中包含完整检查信息；
影像数据可用于科研、教学、算法训练、质控分析；
影像与报告、诊断、随访信息结合后，具有更高的数据价值。

但问题也非常突出：

医学影像数据不是普通文件。

一个 DICOM 文件里面不仅有图像本身，还可能包含大量患者相关信息、检查信息、设备信息、医院信息和操作人员信息。

例如：

PatientName 患者姓名
PatientID 患者编号
PatientBirthDate 出生日期
PatientSex 性别
PatientAge 年龄
InstitutionName 医院名称
InstitutionAddress 医院地址
AccessionNumber 检查号
StudyID 检查 ID
OperatorName 操作员姓名
以及更多隐藏在 DICOM Tag 中的敏感字段

如果这些数据未经处理就流转到研发、测试、科研或第三方环境中，就可能带来隐私泄露和合规风险。

所以，在数据要素流通、数据资产建设、影像 AI 研发、医学科研数据共享等场景下，DICOM 脱敏不是辅助功能，而是基础能力。

二、历史版本：解决了问题，但不够专业

早期版本的设计比较直接。

它主要面向几个固定字段，例如患者姓名、出生日期、性别、年龄、医院名称、医院地址、检查号、操作员姓名、StudyID 等，用户可以选择匿名化或删除。

这种方式的优点是简单、容易理解，上手快。

但随着实际使用场景越来越复杂，问题也逐渐暴露出来：

脱敏字段有限
只能处理少量常见字段，难以覆盖更多 DICOM Tag。
规则不够灵活
不同医院、不同项目、不同科研场景，对脱敏规则的要求并不一样。
缺少任务化管理
大批量处理时，很难追踪任务状态、成功数量、失败数量、跳过数量和处理日志。
缺少数据查看能力
用户很难在处理前直观看到 DICOM 文件中到底有哪些 Tag、当前值是什么、是否启用脱敏规则。
不适合产品化交付
老版本更像一个内部小工具，而不是一个可以长期使用、维护和授权管理的软件产品。
三、新版本：面向真实场景的 DICOM 脱敏专用工具

这次更新，我们不是简单地“换个界面”，而是重新设计了工具的整体能力。

新版本围绕三个核心目标展开：

第一，能批量处理。
支持面向文件、文件夹、目录结构的 DICOM 批量脱敏处理，适合真实数据集整理、科研数据准备、测试数据构建等场景。

第二，规则可配置。
不再只固定几个字段，而是围绕 DICOM Tag 建立脱敏规则体系。用户可以根据不同分组启用、禁用、匿名化或清空指定字段。

第三，处理可追踪。
通过任务列表、进度、成功数、失败数、跳过数、日志、源目录和目标目录等信息，让批量处理过程更加透明。

标题四、新版本主要功能亮点

1. 批量匿名化任务管

新版本提供了任务化处理界面。

每一次批量脱敏都可以作为一个任务进行管理，任务中可以查看：

任务 ID
任务名称
任务状态
处理进度
成功数量
失败数量
跳过数量
创建时间
开始时间
结束时间
操作日志
源目录
目标目录

这对于大批量 DICOM 文件处理非常重要。

以前脱敏工具只是“点一下开始处理”，处理完了也不知道中间发生了什么。
现在可以清楚看到每个任务的执行情况，方便排查问题，也方便形成可追溯的数据处理记录。

2. DICOM 数据查看

新版本增加了 DICOM 数据查看能力。

用户可以选择 DICOM 文件后，查看文件中的 Tag 信息，包括：

TAG 编号
NAME 字段名称
当前值
是否启用
规则值

同时右侧还可以进行图像预览。

这意味着用户在脱敏前，可以先确认文件中到底包含哪些敏感字段，再决定如何处理。

这对于医学影像研发人员非常实用。
因为不同设备、不同医院、不同检查类型生成的 DICOM Tag 内容并不完全一致，很多敏感信息并不总是出现在最常见的位置。

3. 分组化脱敏规则配置

新版本按照 DICOM 信息结构进行了规则分组，例如：

Patient
Visit
Study
Procedure Step
Series
Image
Result
Interpretation
Equipment
Other

每一组下可以配置对应的 DICOM Tag 处理规则。

例如 Patient 分组下可以配置：

Patient’s Name
Patient ID
Issuer of Patient ID
Patient’s Birth Date
Patient’s Birth Time
Patient’s Sex
Other Patient IDs
Other Patient Names
Patient’s Age

每个字段都可以设置是否启用，以及采用何种处理规则。

常见规则包括：

random：随机匿名化
clear：清空字段
custom：自定义值
保留原值
按项目规则扩展

这样一来，工具就不再是“固定字段脱敏”，而是变成了一个可配置、可扩展的 DICOM 脱敏规则引擎。

4. 更适合科研、测试、AI 数据准备

医学影像数据在很多场景下都需要脱敏后使用：

医学影像 AI 模型训练
算法验证数据集构建
医学影像报告系统测试
PACS / 云影像平台联调
医院科研项目数据整理
教学病例库建设
软件演示数据准备
第三方合作数据交付

这些场景有一个共同特点：

不能直接使用真实患者数据，但又需要尽量保留 DICOM 数据结构的完整性。

简单删除文件名或修改患者姓名是不够的。
真正可靠的做法，是识别并处理 DICOM 内部的敏感 Tag，同时尽量保持影像文件可读、可传输、可检索、可用于后续系统测试。

这正是新版本工具重点解决的问题。

五、数据要素时代，脱敏是数据流通的前置能力

医疗数据要素化，并不是简单地把数据“拿出来用”。

真正可用的数据，需要经历几个关键步骤：

数据采集
数据清洗
数据标准化
数据脱敏
数据质控
数据标注
数据治理
数据授权使用
数据安全审计

其中，数据脱敏是数据从院内走向研发、科研、教学、AI 训练和外部协作的重要前置环节。

没有脱敏，数据不敢流通；
脱敏不彻底，存在合规风险；
脱敏破坏结构，数据又无法使用。

所以，好的 DICOM 脱敏工具要同时解决三个问题：

安全性：敏感信息要处理干净。
可用性：处理后的 DICOM 文件还能正常使用。
可追溯性：处理过程、任务结果、失败原因要能查看。

这也是我们这次重新开发新版本工具的核心原因。

六、适合哪些用户使用？

这款工具主要适合以下人员和团队：

医学影像软件研发团队
PACS / RIS / 云影像平台开发团队
医院信息科
医学影像科科研人员
医学影像 AI 算法团队
医疗数据治理团队
高校医学影像教学团队
医疗软件测试团队
DICOM 数据集整理人员

如果你平时经常遇到这些问题：

手里有一批 DICOM 文件，不敢直接发给研发；
想做 AI 训练，但原始数据包含患者隐私；
测试 PACS 系统时缺少安全的测试数据；
科研合作中需要提供脱敏影像；
不确定 DICOM 文件里哪些字段包含敏感信息；
需要批量处理几百、几千甚至更多影像文件；

那么这款工具会非常适合你。

七、我们希望把它做成一个真正好用的 DICOM 脱敏工具

这次更新只是一个新的开始。

后续还会继续完善：

更多 DICOM Tag 内置规则
项目级脱敏模板
一键应用常用脱敏方案
脱敏前后对比报告
处理结果导出
更细粒度的日志审计
批量规则导入导出
授权管理
自动化脱敏任务
与影像云、PACS、对象存储结合
更适合国产化部署的版本

我们的目标不是做一个“能跑的小工具”，而是做一个真正能在医学影像研发、科研、教学和数据治理场景中长期使用的专业工具。

八、欢迎加入交流群，前期免费开放试用

目前新版本已经可以进行基础试用。

如果你正在做：

DICOM 数据处理
医学影像 AI
PACS / 云影像平台
医学影像科研
医疗数据治理
医学影像软件测试
DICOM 数据脱敏与匿名化

标题欢迎加入交流群一起讨论。

我们会在群内持续分享：

DICOM 脱敏实践经验
医学影像数据治理方法
DICOM Tag 脱敏规则设计
医学影像 AI 数据准备流程
工具使用教程
后续版本更新计划

前若干名加入交流群并参与反馈的用户，可以免费获得软件试用授权。

如果你有真实使用场景，也欢迎提出需求。
我们会根据实际场景持续完善这款 DICOM 脱敏专用工具，让它真正服务于医学影像数据安全流通和高质量利用。