📚 课程目录第4章影像数据采集与接入

4. 影像数据采集与接入

影像数据管线的第一道关口是“把数据可靠地拿进来”。医院里的影像来源并不统一：放射科PACS通常通过DICOM C-FIND/C-MOVE或DICOMweb提供检索与下载；超声、内镜、病理等科室可能只有厂商私有API或共享目录；科研协作数据常以文件系统或对象存储（如S3/MinIO）形式交付。接入层的任务不是简单“拷贝文件”，而是把多源、异构、可能中断的数据流，转化为可追溯、可重放、可审计的标准化输入。

一、接入源与协议选择

不同来源对应不同的拉取语义。PACS的C-MOVE是“推送式”：向PACS发起检索后，PACS把影像推送到我们指定的接收端（C-STORE SCP），适合院内网、数据量中等、需要按检查号批量获取的场景。DICOMweb（QIDO-RS/WADO-RS）是HTTP REST风格，天然适合跨网、可缓存、易做断点续传，是新建管线的首选。厂商API往往返回私有JSON元数据加下载链接，需要单独适配器。文件系统和对象存储则以“清单+文件”方式交付，适合离线回填和历史数据迁移。

选择原则可以概括为：能走DICOMweb就不走C-MOVE，能走对象存储就不走共享目录。原因是HTTP/对象存储天然支持Range请求、ETag校验和并发，而C-MOVE一旦中断，重传粒度往往是整个检查，代价高。对于必须使用C-MOVE的老PACS，应在接收端做去重和断点记录。

二、增量拉取：以水位线驱动

增量拉取的核心是维护一个“水位线”（watermark），记录上次成功拉取到的时间点或序列号。以DICOMweb为例，典型流程是：按StudyDate或LastUpdated时间范围调用QIDO-RS查询研究列表，对每个Study调用WADO-RS下载实例。水位线应记录为last_success_study_time，并留出重叠窗口（如回退5分钟），防止PACS时间戳延迟导致漏拉。

# 增量拉取伪代码（DICOMweb）
watermark = load_state("last_success_study_time")  # 例：2024-06-01T08:00:00
query_from = watermark - timedelta(minutes=5)      # 重叠窗口防漏
studies = qido_rs(StudyDate=query_from..now)
for study in studies:
    instances = wado_rs(study.StudyInstanceUID)
    for inst in instances:
        save_to_staging(inst)          # 先落暂存区
        record_audit(inst, source="dicomweb")
update_state("last_success_study_time", now)

水位线更新必须发生在“该批次全部落盘并校验通过”之后，否则会出现“状态已推进但数据未到”的漏洞。建议采用“先写暂存、再提交水位线”的两阶段方式。

三、回填与断点续传

回填（backfill）用于补历史数据或修复漏拉。回填不能简单重跑全量，而应基于审计表定位缺口：查询本地已入库的StudyInstanceUID集合，与源端按时间范围枚举的结果做差集，只拉缺失部分。回填任务应限速，避免占满PACS带宽影响临床。

断点续传依赖两个记录：任务级断点（当前处理到哪个Study/Series）和文件级断点（当前实例已下载多少字节）。对于WADO-RS，可用HTTP Range从断点继续；对于C-MOVE，则需在接收端记录已收到的SOPInstanceUID，重连后跳过已存在实例。对象存储上传同理，使用分片上传的part记录实现续传。

断点状态建议持久化到数据库或Redis，并带任务ID、源标识、最后成功对象、时间戳。进程重启后先读断点，再决定从何处继续，而不是从头开始。

四、接入审计：让每一次拉取可追溯

审计是接入层的“黑匣子”。每条审计记录至少应包含：源系统标识、协议、请求时间、StudyInstanceUID/SeriesInstanceUID/SOPInstanceUID、操作类型（增量/回填/续传）、结果状态（成功/失败/跳过）、失败原因、字节数、耗时。审计表既是排障依据，也是数据完整性证明。

判断接入是否成功的依据不是“程序没报错”，而是：目标实例数=源端枚举数、校验和一致、审计表中无未解释的失败记录。对于关键批次，可抽样比对源端与本地实例的SOPInstanceUID和文件大小。

五、接入质量判断与常见问题

接入完成后，应做三项核对：一是数量核对，本地实例数是否等于源端枚举数；二是完整性核对，抽样比对SOPInstanceUID与文件大小；三是审计核对，失败记录是否都有明确原因和重试结果。常见问题包括：PACS时间戳与本地时钟不一致导致漏拉，应统一使用源端时间并留重叠窗口；C-MOVE接收端磁盘满导致静默丢包，应监控接收目录并设置告警；对象存储分片上传中断后未记录part，导致重复上传，应持久化uploadId与part列表。

不要用“文件已存在”作为唯一去重依据。同一SOPInstanceUID可能因重传产生不同文件名，应以SOPInstanceUID为准做幂等写入，避免重复入库。

把接入层做扎实，后续的清洗、脱敏、标注和建模才有可信的输入。增量拉取保证时效，回填补齐历史，断点续传保证鲁棒，审计保证可追溯——四者共同构成影像数据管线的入口防线。