1. PACS与AI在线推理集成工程导论

PACS（Picture Archiving and Communication System，影像归档与通信系统）是医院影像业务的中枢。它并不只是“存片子的服务器”，而是由影像采集网关、DICOM 通信服务、归档存储、数据库索引、工作流引擎与诊断阅片客户端共同构成的系统。CT、MR、DR、US 等设备完成检查后，按 DICOM 标准把影像推送到 PACS；PACS 负责把影像与患者、检查、序列、图像之间的层级关系登记入库，再通过查询/检索服务把影像分发给阅片工作站。理解这一结构，是理解 AI 推理“插在哪里、拿什么数据、把结果送回哪里”的前提。

DICOM 标准是集成工程的共同语言。它规定了信息对象定义（如 CT Image、MR Image、Secondary Capture）、服务类（C-STORE 存储、C-FIND 查询、C-MOVE 调阅、Worklist 管理）以及文件封装格式。一次检查在 DICOM 层级上通常表现为：Patient → Study → Series → Instance（SOP Instance）。AI 集成中经常用到的标识包括 PatientID、StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID，它们决定了结果能否准确挂回原检查。此外，像素数据、窗宽窗位、像素间距、层厚、方向余弦等标签，直接影响 AI 模型的输入质量与几何一致性。

AI 推理在影像流程中的位置，可以理解为“影像到达 PACS 之后、医生阅片之前”的一个并行处理环节。典型链路是：设备完成检查 → PACS 归档 → 触发 AI 任务 → 拉取序列 → 预处理 → 模型推理 → 后处理 → 结果回写 → 医生在阅片端看到结构化结果或叠加标注。这里的关键不是模型本身，而是“触发时机、数据获取方式、结果回写格式”三件事。触发可以是归档事件驱动，也可以是定时扫描；数据获取可以是 PACS 主动推送，也可以是 AI 侧按 StudyInstanceUID 主动拉取；结果回写可以是 DICOM SR、SC 图、PDF 报告，也可以是独立数据库中的结构化字段。

在线推理与离线推理的差异，决定了集成方案的设计取向。在线推理强调“检查完成即触发、结果尽快可用”，因此必须考虑任务队列、并发控制、超时重试与失败告警；离线推理则更关注批量吞吐、数据版本一致性与结果可复现。两者在数据获取方式上也有区别：在线推理通常只拉取当前检查的序列，离线推理往往需要跨检查、跨设备批量导出。工程上常见的做法是共用同一套预处理与模型服务，但用不同的调度器和结果存储路径隔离。

集成工程的整体目标，可以概括为四句话：数据不丢、结果不串、延迟可控、过程可查。“数据不丢”要求从 PACS 拉取影像时校验 StudyInstanceUID 与 SeriesInstanceUID，确保序列完整；“结果不串”要求回写时严格绑定原检查标识，避免把 A 患者的结果挂到 B 患者；“延迟可控”要求对推理链路做分段计时，定位瓶颈在拉取、预处理还是模型本身；“过程可查”要求记录每次任务的输入、输出、耗时与状态，便于排障与审计。

实际落地时，最常见的挑战集中在三处。第一是 DICOM 兼容性：不同厂商设备的标签填充习惯不同，例如某些设备不写 PixelSpacing 或方向信息，导致 AI 预处理失败。第二是结果回写格式：DICOM SR 适合结构化测量，SC 图适合叠加标注，而独立数据库适合快速检索，选择哪种取决于阅片端能否直接消费。第三是并发与资源：一台 CT 高峰期可能同时完成多例检查，若 AI 服务串行处理，排队延迟会迅速累积。一个可参考的示例参数是：单例胸部 CT 约 300 层，预处理与推理合计目标控制在 60 秒内，队列长度超过 20 时触发扩容或降级策略。这些数值属于教学示例，实际需按设备型号、模型复杂度和硬件资源实测调整。