DICOM 文件来源与完整性
原始 DICOM、重新封装和重建 DICOM 有什么区别？
原始 DICOM 是平台直接提供、保存时不改写字节的文件；重新封装保留 DICOM 数据集来源，但改变文件封装或生成兼容副本；重建 DICOM 则依据平台像素和医学标签重新生成文件。三者都可能使用 .dcm 后缀，不能仅凭后缀判断是否为医院原始数据。
四种常见来源放在一起看
| 来源类别 | 获取方式 | 数据特征 | 交给医生前注意 |
|---|---|---|---|
| 服务器原始 DICOM Part 10 | 平台提供完整 DICOM 文件，保存时不改写文件字节。 | 像素、位深、标签和序列取决于本次检查的原文件。 | 核对本次检查与报告，并询问接诊医院的接收方式。 |
| DICOM 重新封装 | 为已有 DICOM 数据集补充标准文件封装，或制作兼容副本。 | 需分别核对像素和元数据的保留情况。 | 向接诊方说明文件经过重新封装。 |
| 重建 DICOM | 依据平台提供的影像数据和医学标签组织为新文件。 | 能保留的信息以实际平台数据为准，不能推定等同原文件。 | 明确说明来源，临床是否可用由接诊医生判断。 |
| 显示图片／截图 | 保存网页显示的 JPG、PNG 或屏幕截图。 | 通常缺少完整序列和可供医学查看器读取的标签。 | 不能替代完整 DICOM 检查，可按医生要求作为辅助资料。 |
为什么能打开不代表与原始文件相同
DICOM 查看器能读取文件，只能说明它支持当前格式。文件可能经过重新封装、标签调整或像素重建，原始扫描的部分信息未必完整保留。
云影像下载在交付中区分平台原始文件与重建文件，不把改后缀的图片描述成原始 DICOM。支持目录与系统指南会说明已验证入口的文件来源，不能把某个入口的结果推广到同厂商所有医院。
完整性应该核对哪些内容
- 检查身份：确认属于本次检查，避免混入另一次检查。
- 序列与实例：对照平台实际声明与取得的文件，确认无缺失、重复或身份冲突。
- 文件与像素：检查文件结构及像素是否可读取，不能只看 ZIP 能否解压。
- 报告：报告与影像分开核对；取得报告不代表取得全部影像。
DICOM 实例可以包含多帧，文件数量也不一定等于网页显示的“图片张数”。仅凭数量相等不能证明整套检查无误。
SHA256 能证明什么
SHA256 可用于核对文件传输前后是否一致。相同文件的摘要一致，可以帮助发现下载损坏或内容变化。
摘要本身不能证明医院是否提供了全部序列，也不能独自证明文件来自扫描设备。来源说明、上下游数量与身份核对、文件校验需要结合起来看。
医生要求原始影像时怎么准备
- 先核对任务结果标示的文件来源、检查日期和序列；想确认文件能否打开，可用本站免费在线 DICOM 浏览器选择本地 ZIP、目录或 .dcm 文件，或使用兼容的桌面查看器。能预览、位深或 HU 数值都不能单独证明文件是医院原始数据。
- 保留完整检查目录和可取得的报告，向接诊医院确认其接收 U 盘、光盘还是指定上传入口，以及所需文件格式。
- 需要平台原始文件而当前交付为重建文件时，向出片医院咨询原始影像导出方式。
技术核对不等于诊断适用性认证；是否满足此次诊疗需求由接诊医生判断。
常见问题
.dcm 文件一定是原始 DICOM 吗？
不是。原始、重新封装或重建的文件都可能使用 .dcm 扩展名，需要查看平台来源与处理说明。
把 JPG 改成 .dcm 能恢复原始影像吗？
不能。修改后缀不会生成完整的标准 DICOM 数据，也不能恢复已丢失的像素、序列或扫描参数。
重建 DICOM 与截图封装一样吗？
不一定。使用平台全分辨率像素和医学标签重建，与保存屏幕截图的输入信息不同；两者都不应冒充服务器原始文件。
文件数量与网页张数不一样就是缺片吗？
不一定。一个 DICOM 实例可能包含多帧；需要结合平台的检查、序列、实例和帧数定义进行核对，不能只比较文件个数。