超声与医学影像工作流笔记

超声与医学影像工作流笔记
超声成像模式
B-mode
M-mode
Doppler
TDI
多部位对比的产品设计思路
医学影像模态速查
DICOM 文件格式
文件结构
内容类型与场景
Pixel Data 编码
超声 DICOM 的三种形态
静态图像
动态序列
视频流
DICOM 导出与转换
标准导出层级
逸超设备导出格式
视频格式转换
医学影像标注
标注类型与推荐格式
Python vs Java 标注生态对比
标注工具: highdicom 详解
核心设计理念
支持的 IOD 类型
vs pydicom / dcmqi
适用场景选择
代码示例
优势与局限
医疗 AI 获批方向
获批容易的方向特征
任务难度 vs 获批可能性
医疗信息化的临床困局
引子: 高级系统操作员
反向演化: 评级越高, 医生越累
评审标准成了"产品经理"
强制流程: 从智能到拦截
代码"九龙城寨"
系统正在驯化医生
workaround 悖论
临床思维的萎缩
极端推演: 医生的不可替代性
反思: 翅膀还是镣铐
常见问题
为什么一个 Study 会有多个 Series
借物表

超声成像模式

超声不是只有一种"拍片子", 不同模式解决不同问题. 了解这些基本概念后, 看 DICOM 文件时才能理解它存的是哪类数据 ^[1].

模式	全称	原理简述	典型用途
B-mode	Brightness mode	二维灰阶, 回波幅度用亮度表示	常规解剖成像, 看结构形态
M-mode	Motion mode	单一声束线上随时间变化的位移曲线	心脏瓣膜运动、室壁运动分析
Doppler	多普勒血流成像	检测红细胞散射的频移, 计算血流速度和方向	血流速度测量、狭窄/反流评估
TDI	Tissue Doppler Imaging	低通滤波滤除高速血流, 保留低速组织(心肌)运动信号	心肌运动速度、应变/应变率分析

B-mode

最基础的二维灰阶成像. 探头向体内发射超声波, 接收组织界面的回波, 按回波强度用不同灰度显示. 亮度高 = 回声强(如骨骼、钙化), 亮度低 = 回声弱(如血液、囊肿).

常说的"B超"就是这个模式. 腹部、产科、浅表器官检查都以 B-mode 为主.

M-mode

在 B-mode 图像上选定一条取样线, 记录该线上各点随时间运动的位移曲线. 横轴是时间, 纵轴是深度, 亮度表示回声强度.

时间分辨率极高, 是分析心脏瓣膜开放/关闭时序、室壁运动幅度的经典工具.

Doppler

利用多普勒效应: 超声遇到运动的红细胞时, 回波频率会发生偏移, 频移大小与血流速度成正比. 通过检测频移可以判断血流方向 (朝向/远离探头)、测量血流速度、评估血管狭窄和瓣膜反流.

TDI

组织多普勒成像 (Tissue Doppler Imaging) 是 Doppler 技术的变体. 普通彩色多普勒检测的是高速血流 (红细胞运动), TDI 通过低通滤波器把高速血流信号滤掉, 只保留低速高振幅的组织运动信号 (心肌).

临床应用: 测量二尖瓣环/三尖瓣环组织速度 (e’, a’, s’)、评估左室舒张功能 (E/e’ 比值)、心脏再同步化治疗 (CRT) 的优化.

TDI 有角度依赖性, 取样线需尽量与心肌运动方向平行. 新一代斑点追踪超声 (STE) 已部分取代 TDI, 但 TDI 因时间分辨率高、操作简便仍在临床广泛使用.

多部位对比的产品设计思路

看超声诊断时注意到几个实际需求, 记录一下:

配图占位, 正式发布前需替换为图床链接

一些诊断需要结合病史来看, 基础病会影响诊断结果.

很多诊断需要结合多部位, 有些病也需要其他检查来结合判断 (比如 CT).

很有使用价值的图, 我觉得这才是我们应该做的. 超声设备无法简单的做出这种界面, 我们很容易做出来, 又很有应用价值. 医生在分析和案例分享学习时, 能比 PDF/PPT 更高效.

切入邻床实际, 医生接到一位患者, 拿到病例表现, 去做部位检查. 因为涉及到多部位, 有需要频繁切换来对比观看, 超声机器上不方便. 他可能想要这么个界面: 多个部位对比着看, 左右点击一下就方便多部位参照.

医学影像模态速查

医疗影像涉及多种成像模态, 不同原理适用于不同临床场景. 以下是一份快速参考表, 方便工作中遇到陌生缩写时查阅.

基础模态:

缩写	全称	中文	说明
CT	Computed Tomography	计算机断层扫描	X 射线断层成像, 看骨骼、出血、肿瘤
MR / MRI	Magnetic Resonance Imaging	磁共振成像	磁场 + 射频, 擅长软组织 (脑、肌肉、韧带)
DR	Digital Radiography	数字 X 光片	基础拍片 (胸片、骨折筛查)
US	Ultrasound	超声	B 超、心脏彩超
PET	Positron Emission Tomography	正电子发射断层	看代谢活动 (肿瘤常用)
SPECT	Single Photon Emission CT	单光子核素显像	核医学检查
DSA	Digital Subtraction Angiography	数字减影血管造影	看血管 (脑/心/肢体)
CR	Computed Radiography	计算 X 光	老一代 DR 前技术

衍生组合模态:

缩写	全称	说明
CBCT	Cone Beam CT	锥形束 CT, 牙科/口腔常见
CTA	CT Angiography	CT 血管成像, 看血管堵不堵
MRA	MR Angiography	磁共振血管成像, MRI 版血管检查
fMRI	Functional MRI	功能磁共振, 看脑功能活动
PET-CT	PET + CT 融合	肿瘤分期常用
PET-MR	PET + MRI 融合	更高端联合检查

US 是 ultrasound 的缩写, 在 DICOM 标签和 SOP Class UID 中经常出现. 理解各模态的定位有助于后续阅读 DICOM 相关内容.

DICOM 文件格式

文件结构

DICOM 文件包含两部分:

File Meta Header（文件头）
包括标识信息 (如 SOP Class、Transfer Syntax UID、创建时间等).

Data Set（数据集）
由一个个 Data Element（标签）组成, 比如 (0010,0010) PatientName、(0028,0010) Rows、(7FE0,0010) Pixel Data ← 真正的图像像素在这里!

内容类型与场景

DICOM 按内容可以粗分为几类, 不同类别 Pixel Data 的结构和处理方式完全不同 ^[2]:

单帧图像: 一张静态图, 如一帧 X 光或 CT 单层. Pixel Data 就是一帧像素矩阵.
多帧图像: 同一序列的多帧堆叠, 可看作短视频. Pixel Data 是多帧像素数组, 帧数在 (0028,0008) Number of Frames 里.
视频（动态序列）: 超声、透视、内窥镜常见. Pixel Data 是多帧像素序列, 以时间轴索引.
多视频（多序列）: 某些设备一次扫描输出多个 DICOM 序列文件夹, 每个序列对应一个视频或体积.
3D/体积数据: CT、MRI 多切片组成三维体积, 每个切片一帧, 按 Z 坐标排列.
结构化报告（DICOM SR）: 文本或标注信息, 如测量值、病灶标注, 无像素数据.
RT 系列（放疗）: 结构集、剂量、计划等, 可混合图像与向量数据.

常见 SOP Class 示例:

CT/MR 单帧: CT Image Storage、MR Image Storage
超声多帧: Ultrasound Multi-frame Image Storage (1.2.840.10008.5.1.4.1.1.3.1)
增强型: Enhanced MR Image Storage、Enhanced CT Image Storage
放疗: RT Structure Set Storage

不同场景下的文件形态:

场景	DICOM 表现	文件数量	Pixel Data 特征
普通胸片	单个 `.dcm`	1	单帧，2D 灰度
MRI 扫描（100层）	100个 `.dcm` 或一个多帧 `.dcm`	多个或1个	每帧代表一个切片
超声动态视频	1个 `.dcm`	1	多帧，含时间轴
超声多序列	多个 `.dcm` 文件，每个一个视频序列	多个	每个有多帧
内窥镜或术中记录	有时封装 MPEG-2 / H.264 视频流	1个 `.dcm`	Pixel Data 中是压缩视频流

Pixel Data 编码

DICOM Pixel Data 的编码方式主要有四种:

未压缩 (Raw): 原始像素矩阵, 常见于 CT、MR
JPEG / JPEG2000: 有损或无损压缩, 超声、CR、DR 常用
MPEG-2 / H.264: 视频流压缩, 内窥镜和超声视频常见
RLE: 无损游程编码, 某些老设备还在用

超声 DICOM 的三种形态

超声设备导出的 DICOM 有三种形态, 处理时必须先判断是哪种, 否则读图或转视频时会踩坑.

静态图像

医生按键冻结画面时保存的"单张截图", 用于测量、诊断、报告等场景. 特点是 (0028,0008) Number of Frames 不存在或值为 1, Pixel Data 为单帧灰度或彩色图像. 常见 SOP Class: Ultrasound Image Storage (1.2.840.10008.5.1.4.1.1.6.1).

动态序列

超声扫描过程中记录的动态视频序列, 可用于回放或导出为 AVI/MP4. 实际就是时间轴连续的图片, 如需导出视频需要做编码转换 (有较大性能占用). 特点是 (0028,0008) Number of Frames 存在且 > 1 (例如 120), (0018,1063) Frame Time 记录每帧间隔 (单位 ms). 常见 SOP Class: Ultrasound Multi-frame Image Storage (1.2.840.10008.5.1.4.1.1.3.1).

视频流

一些高端设备（尤其是内窥或心超）使用 MPEG-2 或 H.264 编码的视频流嵌入在 Pixel Data 中. 对应 SOP Class: Video Ultrasound Image Storage (1.2.840.10008.5.1.4.1.1.6.2). 实际就是编码压缩过的多帧图像, 占用体积比多帧小很多, 可直接导出 (几乎无性能占用).

用 pydicom 快速判读形态的代码:

import pydicom

ds = pydicom.dcmread("example.dcm")
frames = getattr(ds, "NumberOfFrames", 1)
sop_class = ds.SOPClassUID

if frames == 1:
    print("静态图像 DICOM")
elif "Video" in str(sop_class):
    print("视频流 DICOM (MPEG/H.264)")
else:
    print(f"多帧 DICOM ({frames} 帧)")

DICOM 导出与转换

标准导出层级

导出批次（Export Batch）
└─ 20251015_100893_0001_20251015_100047534
    ├─ 病人1（Patient 1）
    │   └─ Anonymous_0001
    │       ├─ DICOMDIR
    │       └─ DICOM
    │           └─ PAT00001
    │               ├─ STU00001  ← 第一次扫描 (Study)
    │               │   ├─ SER00001  ← B 模序列 (Series)
    │               │   │   ├─ I0000001  ← 单张图像 (Instance)
    │               │   │   ├─ I0000002
    │               │   │   └─ I0000003
    │               │   └─ SER00002  ← 彩色血流序列
    │               │       ├─ I0000001
    │               │       └─ I0000002
    │               └─ STU00002  ← 第二次扫描
    │                   └─ SER00001
    │                       ├─ I0000001
    │                       └─ I0000002
    │
    ├─ 病人2（Patient 2）
    │   └─ Anonymous_0002
    │       ├─ DICOMDIR
    │       └─ DICOM
    │           └─ PAT00002
    │               ├─ STU00001
    │               │   ├─ SER00001
    │               │   │   ├─ I0000001
    │               │   │   └─ I0000002
    │               │   └─ SER00002
    │               │       └─ I0000001
    │               └─ STU00002
    │                   └─ SER00001
    │                       ├─ I0000001
    │                       └─ I0000002
    │
    └─ 病人3（Patient 3）
        └─ Anonymous_0003
            ├─ DICOMDIR
            └─ DICOM
                └─ PAT00003
                    └─ STU00001
                        └─ SER00001
                            ├─ I0000001
                            ├─ I0000002
                            └─ I0000003

层级关系: Patient → Study (一次检查) → Series (一个序列/模式) → Instance (单张图像/帧)

逸超设备导出格式

C:.
├─20251015_100893_0001_20251016_114732235   ← 患者ID_导出时间ID
│  └─Anonymous Anonymous Anonymous_20251015_100893_0001  ← 病人目录（患者级别）
│      │  DICOMDIR                            ← DICOM目录文件（索引）
│      └─DICOM
│          └─PAT00001                         ← 病人ID（内部编号）
│              └─STU00001                     ← Study（一次检查/研究）
│                  ├─SER00001                 ← Series（一次采集序列）
│                  │  │  I0000001, I0000002   ← 图像帧（DICOM文件）
│                  │  └─converted             ← 转换后文件夹（MP4、JPG等）
│                  ├─SER00002
│                  └─SER00003

逸超设备会在每个 Series 下自动创建 converted 文件夹, 预转好 MP4/JPG, 方便非 DICOM 系统直接使用. 这点很贴心, 不用自己写脚本转视频了.

视频格式转换

格式	编码方式	特点	推荐场景
MP4 (H.264)	有损压缩	通用、兼容性极高、文件小、质量较好	✅ 推荐：用于展示、教学、科研报告等
AVI (无压缩或MJPEG)	可无损	文件大，但保真	医学分析、算法训练前数据准备
MOV (H.264 / ProRes)	有损或轻压缩	苹果生态友好，质量高	视频编辑、科研展示
MKV (H.264 / H.265)	有损压缩	可封装多通道音视频、元数据	特殊研究项目
H.265 / HEVC	有损高效压缩	同质量体积更小，但编码慢	长序列或云端传输

从 DICOM 多帧 Pixel Data 导出视频时, 要逐帧解码再编码, CPU 占用很高. 如果 DICOM 本身是视频流编码 (MPEG/H.264), 可以直接提取流封装到 MP4, 几乎零性能消耗.

医学影像标注

标注类型与推荐格式

医学影像标注主要有四种形式, 对应不同的数据格式和工具链:

1. 像素级分割 (Segmentation)

器官或病灶的 mask, 常用格式: DICOM SEG、NIfTI、PNG mask. 生成工具: Python highdicom / dcmqi, 解析工具: Java dcm4che-seg.

2. 二维标记 (点/框/多边形)

ROI、测量线、医生手动圈选, 常用格式: DICOM Presentation State (PR)、私有 JSON. 生成和解析都相对简单.

3. 结构化描述 (诊断结论)

“前列腺体积 xxml, 疑似病灶区域 xx” 这类文本诊断, 标准格式是 DICOM SR (Structured Report). Python 用 highdicom 生成, Java 用 dcm4che-sr 解析. SR 使用 SNOMED CT、UCUM、LOINC 等标准化术语编码, 可机器解析、符合 IHE 标准.

4. AI 推理结果

模型输出的 mask、评分、概率, 通常自定义 JSON + DICOM SEG. 简单灵活但非标准, 适合内部训练数据集.

目标	推荐做法	原因
构建标准化医学标注系统	DICOM SR + SEG	符合国际标准, 方便医院/PACS 对接
简单 AI 数据集标注	JSON + NIfTI/PNG mask	简单易操作
Java 环境	`dcm4che-sr` / `dcm4che-seg`	官方支持
Python 预处理或 AI	`highdicom` / `dcmqi`	社区主流

Python vs Java 标注生态对比

为什么不推荐"让 Java 来做标注生成"? 主要是以下几个现实原因:

标注生成往往依赖图像数据处理
医学标注不仅是元信息写入, 还涉及像素、mask、坐标、图像空间映射. Java 没有成熟的医学影像处理库 —— 没有 SimpleITK、nibabel、numpy, 坐标系、体素、spacing、affine matrix 等都需要自己实现. Python 则有成熟生态 (highdicom, SimpleITK, dcmqi), 能直接读写、变换、验证.
✅ Python: seg = highdicom.seg.Segmentation(...) 一行生成符合标准的 SEG 文件.
❌ Java: 得手工拼 DICOM dataset 结构, 几百行 XML 树状属性.
DICOM SR 的语义编码复杂
SR 文件需要使用标准化术语编码 (SNOMED CT、UCUM、LOINC). Python 的 highdicom.sr 封装了各种编码模板 (如 TID 1500、TID 300), 可直接使用. Java 的 dcm4che-sr 层次较低, 需要手动创建 Attributes 树、填 CodeSequence, 非常繁琐.
✅ Python: MeasurementReport(...) 一行构建完整报告.
❌ Java: 得手工拼 ContentSequence、ValueType、ConceptNameCodeSequence、ConceptCodeSequence.
医学标注多与 AI / 图像算法绑定
实际上标注文件常来自 AI 推理结果或人工审阅系统. AI 推理 → 通常是 Python 环境 (PyTorch / MONAI). 标注后生成 DICOM SEG/SR → Python 一站式完成更自然. Java 若要参与标注生成, 反而要跨语言调用 Python 算法输出, 增加复杂度.

标注工具: highdicom 详解

前面聊完标注的理论, 下面介绍一个实战中非常好用的工具. highdicom 不是替代 pydicom, 而是把 pydicom 做不到的"高层抽象"补上 —— 让你不用手写复杂的 DICOM tag、序列结构、坐标系、像素变换, 就能读写各种 DICOM 影像与衍生对象 ^[3].

核心设计理念

highdicom 由 Imaging Data Commons (IDC) 和 Google 支持, 遵循几条非常明确的设计原则:

1. 基于 pydicom, 但更高层

所有 highdicom 类型都继承自 pydicom.dataset.Dataset. 熟悉 pydicom 的人可以随时用底层 API inspect 或修改对象. 这保证了向下兼容.

2. 强制标准合规 (严格验证)

highdicom 不允许创建非合规的 DICOM 对象. 所有参数在构造时验证, 非法参数直接抛异常. 对象一旦构造完成就保证处于合法状态 —— 没有中间非法态.

3. 解码宽容, 编码严格

编码时: 绝不妥协, 必须符合标准
解码时: 容忍真实世界中的轻微偏差, 但遇到严重违规时明确报错

4. 对象不可变性

通过 highdicom API 创建的对象在构造完成后是"事实不可变"的 —— 这反映了 DICOM 标准的设计意图, 防止意外篡改.

支持的 IOD 类型

highdicom 支持创建和解析以下 DICOM IOD (Information Object Definition):

IOD	用途	典型场景
SEG (Segmentation)	分割掩码	器官/肿瘤分割、语义分割结果存储
SR (Structured Report)	结构化报告	测量值、诊断结论、AI 推理文本
PM (Parametric Map)	参数图	概率图、SUV map、像素级数值
ANN (Microscopy Bulk Simple Annotations)	病理批量标注	WSI 中大量细胞/核的检测标注
SC (Secondary Capture)	二次捕获	截图、可视化结果
KOS (Key Object Selection)	关键对象选择	标记关键帧/关键影像

支持 放射学 (CT/MR/超声) 和 病理学 (Whole Slide Image) 两种模态, 这是很少有库能同时做到的.

vs pydicom / dcmqi

这三个工具在 DICOM 生态里处于不同层级, 不是竞争关系而是互补关系 ^[4]:

维度	pydicom	highdicom	dcmqi
语言	Python	Python	C++ (CLI)
底层依赖	纯 Python	pydicom	DCMTK
抽象层级	低-中	高	中-高
通用 DICOM 读写	✅ 优秀	✅ (通过 pydicom)	⚠️ 有限
DICOM-SEG 生成	❌ 手动	✅ 原生高层 API	✅ 原生
DICOM-SR 生成	❌ 手动	✅ 原生高层 API	✅ TID1500
AI/ML 输出编码	❌ 手动	✅ 为此设计	⚠️ 可行
像素变换 (LUT)	❌ 不自动	✅ 自动应用	✅ (DCMTK)
WSI (病理全切片)	⚠️ 基础	✅ 优化支持	❌ 不支持
命令行工具	❌	❌	✅ 有 CLI
3D Slicer 集成	⚠️ 插件	✅ 增长中	✅ 原生

一句话总结:

pydicom 是"螺丝刀" —— 通用、灵活, 但需要手动拼 DICOM 结构
highdicom 是"电钻" —— 高层抽象, 开箱即用, 专门为 AI 输出标准化
dcmqi 是"气动扳手" —— C++ 性能, CLI 友好, 深度集成 3D Slicer

实际项目中常见的组合是: pydicom + highdicom 做 Python 全流程, dcmqi 做 Slicer 集成和批量转换.

适用场景选择

选 highdicom 的场景:

做 AI 推理后处理, 需要把分割结果/测量值/概率图写成标准 DICOM 格式
需要 医院/PACS 系统集成, 医院不接受 PNG/JSON/numpy
做 病理 WSI 分析, 需要处理 DICOM 格式的全切片图像
不想手写几百行 DICOM tag 构造代码

选 pydicom 的场景:

只需要 简单读写 DICOM → numpy
做探索性数据分析, 需要灵活修改 tag
构建自定义工具, 需要完全控制数据结构
不想引入额外依赖 (highdicom 依赖 pydicom + numpy + Pillow)

选 dcmqi 的场景:

需要 命令行工具 做批量转换 (如 NIfTI → DICOM-SEG)
已经在 3D Slicer 生态 里
偏好 C++ 性能和 DCMTK 的稳定性
做定量成像 (radiomics, parametric maps)

代码示例

创建 DICOM-SEG (分割掩码):

import highdicom as hd
from pydicom.sr.codedict import codes

# 1. 定义分割算法
algorithm = hd.AlgorithmIdentificationSequence(
    name='AI Segmentation Model',
    family=codes.cid7162.ArtificialIntelligence,
    version='v1.0'
)

# 2. 定义分割对象
segment = hd.seg.SegmentDescription(
    segment_number=1,
    segment_label='Tumor',
    segmented_property_category=codes.cid7150.Tissue,
    segmented_property_type=codes.cid7166.Neoplasm,
    algorithm_type=hd.seg.SegmentAlgorithmTypeValues.AUTOMATIC,
    algorithm_identification=algorithm
)

# 3. 创建 SEG 对象 (mask 是 numpy array)
seg = hd.seg.Segmentation(
    source_images=[source_dicom],      # 原始 DICOM 列表
    pixel_array=mask,                  # 分割掩码 (numpy ndarray)
    segmentation_type=hd.seg.SegmentationTypeValues.BINARY,
    segment_descriptions=[segment],
    series_instance_uid=hd.UID(),
    series_number=2,
    sop_instance_uid=hd.UID(),
    instance_number=1,
    manufacturer='YourLab',
    manufacturer_model_name='AI Model v1'
)

seg.save_as('tumor_segmentation.dcm')

对比 pydicom 的手动方式: 你需要自己构造 PixelData, SegmentSequence, SharedFunctionalGroupsSequence 等几十个 tag, 几百行代码, 很容易漏掉必填项导致 PACS 拒收.

创建 DICOM-SR (结构化报告):

import highdicom as hd
from pydicom.sr.codedict import codes

# 观察者信息
observer = hd.sr.ObserverContext(
    observer_type=hd.sr.ObserverTypeValues.PERSON,
    observer_identifying_attributes=hd.sr.PersonObserverIdentifyingAttributes(
        name='Dr. Smith'
    )
)

observation_context = hd.sr.ObservationContext(
    observer_person_context=observer
)

# 测量值
measurement = hd.sr.Measurement(
    name=codes.SCT.TumorSize,
    value=23.5,
    unit=codes.UCUM.Millimeter
)

# 构建报告
report = hd.sr.MeasurementReport(
    observation_context=observation_context,
    procedure_reported=codes.SCT.ImagingProcedure,
    imaging_measurements=[measurement]
)

# 创建 SR 文档
sr = hd.sr.Comprehensive3DSR(
    evidence=[source_image],
    content=report[0],
    series_instance_uid=hd.UID(),
    series_number=100,
    sop_instance_uid=hd.UID(),
    instance_number=1
)

sr.save_as('measurement_report.dcm')

highdicom.sr 封装了 TID 1500、TID 300 等标准模板, 自动处理 SNOMED-CT、UCUM、LOINC 等术语编码. 用 pydicom 做同样的事需要手动拼 ContentSequence、ConceptNameCodeSequence、ConceptCodeSequence —— 非常容易出错.

优势与局限

核心优势:

自动元数据传播: 创建 SEG/SR 时自动从源图像复制 Patient/Study/Series 信息, 并添加对源图像的引用. 不需要手动维护这些关联.
标准代码抽象: 通过 pydicom.sr.codedict.codes 提供 SNOMED-CT、UCUM 等标准术语的便捷访问. 不用记复杂的 code value 和 coding scheme.
跨模态统一: 同一套 API 处理放射学 (CT/MR/超声) 和病理学 (WSI). 对于做多模态 AI 的团队, 不用为不同模态写不同的 DICOM 处理逻辑.
临床互操作性: 生成的 DICOM 对象符合标准, 能被 OHIF Viewer、3D Slicer、医院 PACS 直接读取. 这是科研到临床落地的关键一步.

已知局限:

SR 可扩展性瓶颈: SR 的深层嵌套结构不适合大规模对象检测场景. 在病理 WSI 中, 如果一张切片检测到数百万个细胞/核, SR 文档会变得极其臃肿. 这也是 DICOM WG-26 开发 ANN (Microscopy Bulk Simple Annotations) IOD 的原因.
DICOM-only 假设: highdicom 假设模型训练和推理预处理直接操作源图像. 如果中间有非 DICOM 格式 (如配准后的中间结果), highdicom 没有原生支持.
编码概念挑战: highdicom 能帮你正确使用标准编码, 但不能替你想清楚该用什么编码. 当标准中没有对应概念时, 仍需自定义编码方案 (惯例用 “99” 前缀), 而消费者需要额外信息才能正确解读.
对非合规文件的容忍度有限: 解码时虽有一定宽容度, 但不会尝试修复来自其他实现的非合规文件. 遇到严重违规时直接报错, 不会像某些工具那样"尽量读出来".

医疗 AI 获批方向

了解医疗 AI 注册审批的通行规律, 有助于评估哪些方向更容易落地. 以下从模态、部位、软件形态三个维度对比不同方向的审批难度.

模态 × 部位 × 软件形态 × 难点对比:

模态	部位 / 任务	软件形态	监管难点	技术难点	数据难点
CT	肺结节检测、脑出血、冠脉钙化、骨折	设备内置 / 工作站插件	风险等级高 (II/III 类), 需大量临床验证	小目标检测、低对比度病灶、金属伪影	多中心 CT 协议差异、剂量差异
MRI	脑萎缩、白质病灶、前列腺、膝关节	工作站插件	序列多、参数不统一, 跨设备一致性难	3D 分割、弱边界结构、低信噪比	不同医院 MRI 协议差异极大
X-ray	肺炎/结核、骨折、骨龄	工作站插件	误诊风险高, 需解释性	重叠结构、低对比度骨折	标注成本高、病灶稀疏
超声	心脏 EF、甲状腺 TI-RADS、产科测量	设备内置为主	强依赖操作者, 难标准化	speckle 噪声、实时性要求高	采集质量不稳定、跨探头差异
病理	IHC 定量、肿瘤分级、宫颈细胞	工作站插件	监管最严格 (III 类)	超大图像 (WSI)、细胞级别检测	标注极难、跨染色差异巨大

获批容易的方向特征

医疗 AI 的核心难点不是模型, 而是 安全性 + 可靠性 + 可控性. 能获批的方向往往具备以下特征:

任务边界清晰 — 输入固定、输出固定、评价指标明确 (Dice、Sensitivity、Specificity). 监管最喜欢这类. 典型: 肺结节检测 (CT)、脑出血检测 (CT)、EF 测量 (超声).

风险可控 — NMPA 对"自动诊断"极其谨慎, 获批的几乎都是辅助诊断 (CAD)、辅助分割、辅助量化, 而非"AI 自动给出诊断结论".

设备厂商推动 — 设备内置 AI (联影、迈瑞、东软、西门子、飞利浦) 最容过审, 因为算法版本固定、输入数据质量稳定、风险可控. 这也是超声 AI 获批多为设备内置的原因.

任务难度 vs 获批可能性

任务类型	难度	获批可能性	原因
检测 (Detection)	中	高	任务边界清晰
分割 (Segmentation)	中	高	可量化、风险低
分类 (Classification)	高	中	误诊风险高
诊断 (Diagnosis)	极高	极低	监管不允许自动诊断
治疗方案推荐	极高	极低	高风险、需可解释性
多模态推理 (VLM)	极高	未来趋势	目前监管路径不清晰

这部分内容跟医疗信息化的临床困局有关联 — 审批通过只是第一步, 产品落地到医院后遇到的系统集成和使用体验问题, 才是真正的考验.

医疗信息化的临床困局

这部分来自一期医疗播客的听感整理 ^[5], 讲的是医院信息化系统在临床一线的真实困境. 做医学影像 AI 的人, 最终产品要落地到医院, 这些坑迟早要踩.

引子: 高级系统操作员

一位三甲医院的医生朋友吐槽说, 他现在根本不像个医生, 像个高级系统操作员. 这个自嘲听着心酸, 却又精准.

以前开处方, 噼里啪啦点三五下鼠标就完事儿; 现在为了开一张处方, 得点上十几下甚至更多. 问题是, 这些多出来的点击, 并没有让诊疗更精准, 反而是在应付系统的各种拦截和校验.

这就是医疗信息化的"反向演化".

反向演化: 评级越高, 医生越累

什么叫"反向演化"? 信息化评级越高, 系统反而越难用, 医生反而越累.

看看那些大三甲: 今天过个电子病历五级, 明天拿个互联互通四甲, 牌匾挂满走廊, 看着特牛. 但你进诊室看看医生怎么干活? 点保存至少要转圈五秒钟 —— 因为那五秒钟里, 后台可能在同时跑一大堆为了应付检查而写的校验和上报逻辑.

维度	“演化前”	“演化后”
评级	无	五级/四甲/互联互通
牌匾	无	挂满走廊
开处方点击数	3-5 下	十几下甚至更多
系统响应速度	秒开	转圈 5 秒+
医生体验	顺畅	被逼疯

评审标准成了"产品经理"

为了拿那个牌匾, 厂商必须在规定时间内满足几百条硬性指标. 问题是: 系统是为评审专家设计的, 不是为医生设计的.

评审专家看的是有没有这个功能、能不能截图证明、流程是否闭环. 至于医生用着方不方便、病人等得焦不焦虑, 不在评分标准里. 所以厂商的优先级很清楚: 先让评审能过, 再考虑医生体验 (如果有时间的话), 病人体验排不上号.

结果就是: 系统功能清单越来越长, 但核心体验越来越差.

强制流程: 从智能到拦截

评审里有一条叫"闭环管理". 以 VTE 深静脉血栓风险评估 为例:

理想场景: 系统自动抓取历史检验数据、病程录里的卧床关键词、病案首页年龄, 后台静默计算, 只在极高危时弹一个提示:“这个病人要注意血栓了”.

现实场景: 厂商为了达标、为了赶上检查, 直接在前端加一把锁 —— 医生开医嘱的按钮上挂个钩子程序, 只要评估为空, 则禁止下一步. 哪怕这病人跟血栓八竿子打不着, 医生也必须手动把十几项评估全勾选一遍, 否则连药都开不出来.

这就从"辅助"变成了"强制拦截". 全院几百名医生, 每天要多浪费数千分钟去填这些为了填而填的表格.

代码"九龙城寨"

这种为了应付各种评级而赶工出来的系统, 代码质量可想而知:

今天加个质控节点
明天加个医保接口
后天加个上报任务

所有代码都是补丁叠补丁, 违章建筑搭违章建筑. 根本没时间重构底层. 这也是为什么很多大医院的系统越用越卡 —— 后台可能同时跑着一堆互相关联的校验和上报逻辑, 互相绊脚.

更让人担心的是技术隐患: 这些代码不是按临床逻辑写的, 是按评审逻辑写的. 评审变了, 代码就得改, 但旧的逻辑可能还在跑, 造成各种意想不到的冲突.

系统正在驯化医生

现在的 HIS 系统里不仅有弹窗, 还有漫天的红色星号和拦截规则. 有医生说: “现在是系统在教我怎么看病了.”

医学是门艺术, 充满了灰色地带和特例. 但系统不管你是谁, 直接弹个巨大的红叉:“适应症不符”. 这时候医生只有两条路:

走申诉流程: 写说明、审批解锁 —— 黄花菜都凉了, 救人如救火
workaround 绕过: 填一个能骗过系统但不准确的诊断, 先把药开出来

很多医生被迫选择了第二条路.

workaround 悖论

为了绕过系统的死板规则, 医生不得不填写一些"系统想看到"的数据, 而不是真实的临床情况. 结果是: 电子病历结构严谨、逻辑闭环、质控满分, 但这可能牺牲了临床的真实性. 一份份堪称完美的病历, 变成了系统想要看到的标准答案, 而不是病人真实情况的记录.

这就形成了一个诡异的悖论: 系统要求数据准确 → 医生为了救人被迫填假数据 → 系统里的数据越来越"完美"但越来越假. 这不只是效率问题, 这是在污染医疗数据. 未来基于这些数据进行 AI 训练, 学出来的模型会有多离谱?

更诛心的是, 这种环境正在毁掉下一代医生.

临床思维的萎缩

老专家还有经验去判断系统对不对, 但刚入职的年轻医生呢? 他们入行第一天面对的就是这种环境. 久而久之, 他们习惯了:

系统不拦截 = 对的
系统拦截了 = 错的

遇到问题, 第一反应不是去查文献、动脑子, 而是看系统允不允许. 这就是临床思维的萎缩. 如果继续沿着这个逻辑演化下去, 理论上找个识字、会操作电脑、经过简单培训的人, 只要听话, 按着系统提示点, 也能看病.

极端推演: 医生的不可替代性

继续推演下去, 医疗信息化的方向是标准化 → 结构化 → 工业化:

诊断有 CDSS 和大模型辅助治疗
用药有系统自动审查
费用有 DRG/DIP 控费
所有动作被拆解成 SOP

医生的角色在标准化场景里, 确实有被流程化的趋势 —— 就像工厂流水线上点确认键的操作工. 但即便如此, 人类医生有两个功能是 AI 永远替代不了的:

1. 不能坐牢 —— 法律责任

医学总有失败概率. 如果全是系统自动诊断, 病人出事了谁负责? 把服务器砸了? 把写代码的程序员抓去坐牢? 必须有一个自然人在电子病历上签下自己的名字, 这个签名就是承诺承担法律责任.

2. 不能挨骂 —— 情感缓冲

当一个癌症晚期的病人绝望崩溃, 或者家属因为排队太久想发火的时候, AI 再智能, 安慰也是冷冰冰的. 你得有个人在那听着、哄着、握着患者的手. 人类需要同类的温度, 也需要一个发泄情绪的对象.

所以未来的医生, 在系统面前是操作员, 在法律面前是背锅侠, 在患者面前是出气筒 —— 但至少, 还是个人.

反思: 翅膀还是镣铐

数字化本身没错, 人工智能也没错. 技术本该是医生的翅膀, 帮他们飞得更高、看得更准.

但如果我们把管理便利凌驾于临床价值之上, 把通过评审看得比医生体验还重, 那双翅膀就会变成沉重的镣铐. 医院可能会越来越像一个高效率的医疗工厂, 而不像以人为本的临床现场. 效率极高、标准极严、周转极快, 但就是没有"人味儿".

卓别林在拧螺丝, 医生在点鼠标. 我们不能为了追求数字化的完美, 而牺牲了医学的温度.

这个问题留给所有身处其中的人: 如果坐在你对面的医生, 只是一个被算法规训过的流程确认者, 不再有独立的临床裁量权 —— 你敢把自己的命交给这套系统吗?

常见问题

为什么一个 Study 会有多个 Series

一个 Study (一次检查) 下出现多个 Series (序列) 很常见, 原因包括:

不同成像模式: B 模、彩色多普勒 (CFM)、脉冲多普勒 (PW)、M 模等, 每种模式生成一个独立 Series.
不同探头: 同一次检查中切换了探头 (如腹部探头、腔内探头), 也会分成不同 Series.
静态图像 vs 动态视频: 一些仪器把保存的"视频片段"和"静态截图"分别保存为独立 Series.
参数变化: 改变了深度、焦点、增益或测量设置后, 设备可能重新开始一个 Series.
复合图像或测量图: 测量报告图（带测量线的图像）或复合模式 (Compound Imaging) 也可能单独作为 Series.

借物表

[1]: 超声视频中级 - B站 — 基础概念来源

[2]: DICOM Standard - NEMA — DICOM 标准官方文档

[3]: highdicom GitHub / 论文 arXiv:2106.07806 / 文档 — highdicom 官方资源

[4]: awesome-dicom - GitHub — DICOM 生态资源汇总

[5]: 医术洞见播客 — 中国医院信息化正在经历一场诡异的"反向演化"