📚 课程目录第2章医学影像数据来源与采集工程

2. 医学影像数据来源与采集工程

医学影像数据湖的第一道工程关口不是存储，而是采集。数据湖里最终能检索到什么，取决于采集端是否把 DICOM、PACS、RIS、HIS 以及各类 modality 的数据完整、及时、可追溯地接进来。本节围绕“数据从哪里来、以什么方式进来、进来后如何对齐”展开，重点讲清 DICOM、PACS、RIS、HIS 四类系统的角色差异，以及边缘采集、批量导入、实时流接入三种接入方式的适用场景与工程要点。

一、四类数据源的角色与边界

在医学影像信息体系中，四类系统承担不同职责，采集时必须区分对待：

Modality（成像设备）：CT、MR、DR、US、PET-CT 等，是影像像素数据的原始产生者。设备按 DICOM 标准生成影像对象，包含 SOP Instance UID、Study/Series/Instance 三级标识，以及患者信息、检查参数、设备参数等。
PACS：影像归档与通信系统，是影像数据的主要汇聚点。PACS 通常已从各 modality 接收影像，数据湖从 PACS 拉取可避免直接对接大量设备。
RIS：放射信息系统，管理检查申请、预约、检查状态、报告。RIS 提供的是检查流程与报告文本数据，是影像与临床语义对齐的关键。
HIS：医院信息系统，管理患者主索引、就诊、住院、医嘱。HIS 提供患者身份与就诊上下文，是数据湖中患者主索引对齐的权威来源。

四类系统的数据在数据湖中通过 Study Instance UID、Patient ID、Accession Number 三个关键字段关联。采集工程的核心任务之一，就是保证这三个字段在各来源之间可对齐、可追溯。

二、三种接入方式的工程选择

边缘采集适合设备数量多、网络条件受限或需要近端预处理的场景。典型做法是在科室内部署采集网关，作为 DICOM C-STORE SCP 接收 modality 推送的影像，先在本地落盘并做完整性校验，再异步上传到数据湖。边缘节点需要处理设备并发、断网缓存、重传去重等问题。示例配置中，网关监听 11112 端口，AE Title 设为 EDGE_DL，本地缓存目录 /data/edge_cache，单文件校验采用 DICOM 标签完整性检查加 MD5 比对。

批量导入用于历史数据迁移或离线介质导入。工程上不建议直接扫描目录后盲目上传，而应先做清单校验：读取每个 DICOM 文件的 Study/Series/Instance UID，与来源系统提供的检查清单比对，识别缺失、重复和损坏文件。导入任务应支持断点续传，按 Study 粒度记录已导入状态，避免重复写入。示例中，一个 50 万检查的历史库导入，先按 Study 生成清单，再分批提交，每批 500 个 Study，失败项进入重试队列。

实时流接入适合检查完成后需要尽快进入数据湖的场景。常见做法是 PACS 或 RIS 在检查状态变为“已完成”时，向消息队列发送事件，采集服务消费事件后触发拉取。实时流的关键是幂等：同一 Study 可能因重试被多次通知，采集端必须基于 Study UID 做去重，确保数据湖中一个 Study 只落一份。示例事件字段包括 study_uid、patient_id、accession_no、modality、event_time、source_system。

三、数据源对接任务的关键控制点

无论采用哪种接入方式，数据源对接任务都需要关注以下控制点：

控制点	说明	示例判据
身份对齐	Patient ID 与 HIS 主索引一致	未匹配患者进入待处理队列
检查对齐	Accession Number 与 RIS 申请一致	缺失申请号的检查标记为异常
影像完整性	Series 内 Instance 数量与清单一致	缺片 Series 不进入正式索引
去重	基于 Study UID 幂等写入	重复事件只落一份
时效	从检查完成到可检索的延迟	实时流目标 < 5 分钟
审计	记录来源、时间、状态、校验结果	每条采集记录可追溯

实践提示：采集端不要直接信任来源系统的字段。DICOM 标签中患者姓名、ID 可能存在前后空格、全半角差异或编码不一致。建议在入库前统一做 trim、大小写归一和字符集转换，再写入索引。

四、一个可执行的采集任务配置示例

下面给出一个实时流接入任务的配置片段，用于说明关键参数如何落地。该配置属于教学示例，实际部署时需按现场网络、PACS 厂商和队列中间件调整。

task:
  name: pacs_realtime_ingest
  source:
    type: pacs
    protocol: dicom
    host: 10.20.30.40
    port: 104
    ae_title: DL_INGEST
    query_level: STUDY
  trigger:
    type: mq
    topic: pacs.study.completed
    consumer_group: dl-ingest-group
  mapping:
    study_uid: "0020,000D"
    patient_id: "0010,0020"
    accession_no: "0008,0050"
    modality: "0008,0060"
  dedup:
    key: study_uid
    window: 24h
  retry:
    max_attempts: 5
    backoff: exponential
  audit:
    store: true
    fields: [source_system, event_time, ingest_time, status, checksum]

该配置表达的核心逻辑是：以 PACS 为来源，通过消息队列触发，按 Study 级别拉取，使用 Study UID 去重，失败指数退避重试，并记录完整审计字段。实际运行时，采集服务消费到事件后，先查去重表，若已存在则跳过；否则向 PACS 发起 C-MOVE 或 C-GET，将影像写入对象存储，同时抽取元数据写入索引，最后更新审计记录。

五、采集质量的观察与判断

采集是否健康，不能只看“有没有数据”，而要看几个可观测指标：单位时间采集 Study 数、失败率、平均延迟、去重命中率、身份未匹配率。示例中，若某天失败率从 0.5% 升到 8%，且集中在某一台 modality，通常指向该设备网络或 AE Title 配置问题；若身份未匹配率升高，则应检查 HIS 主索引同步是否延迟。采集工程的价值，正在于把这些判断依据提前设计进任务里，而不是等数据湖里出现脏数据后再回头排查。