影像与分析数据方案设计

① 关联基础：先明确影像属于谁

FridaySaaS 向美亚同步患者、诊所和就诊信息，美亚据此关联影像；SaaS 校验并留存对应关系，再向 PAC 提供。

② 数据供给：同步影像信息与分析结果

以下以启用美亚新影像为例，表示目标链路：

原片由美亚管理，SaaS 向 PAC 提供影像业务信息与分析结果。美亚到 SaaS 如何获取变更，仍需确认。

新老影像功能可以保留，实际使用时择一启用；选用旧影像时，也由 SaaS 统一向 PAC 提供数据。

③ 查看原片：用户按需打开宿主入口

SaaS 负责权限和入口；启用新影像时，由美亚提供阅片服务。数据同步持续进行，查看原片由用户按需发起。

美亚负责采集接入、原片存储、影像关联、阅片，以及其提供的分析。对外不仅要能查询当前数据，还要让 SaaS 知道数据发生了什么变化。

只发现新增，会漏掉什么如果只能查新影像列表，SaaS 可以知道“多了一张片”，却未必知道这张片后来分析完成、被改绑到另一位患者，或被撤销。下游就可能继续使用过期甚至归属错误的依据。

因此，对美亚真正要提的要求是：

提供可追溯、可补拉的影像及分析变更机制，包含新增、修改、撤销和归属变化。

3.1 为什么需要留新影像数据

如果 SaaS 只在用户打开页面时代理查询美亚，它承担的是展示功能，无法承担稳定的下游数据供给。 没人打开页面时，PAC 仍需要知道患者有了新的影像或分析。

既然 PAC 从 SaaS 接收数据，SaaS 就应保存一份能够重试、重推、核对的影像业务记录：

原片继续由美亚管理。SaaS 保存索引和结果，不重复建设影像存储；临时签名 URL 不能作为永久地址。

这样即使美亚暂时不可用，SaaS 和 PAC 仍可查询已留存的影像信息和分析结果；原片访问和最新变更同步则可能受影响。 分析结果会影响后续业务判断，值得留存，而不应仅在查看页面时临时取一次。

美亚接入、获取变更和归属校验由 SaaS 对接层负责；open-connector 从 SaaS 已保存的业务记录向 PAC 推送。供应商协议与下游数据传输各自负责自己的部分。

SaaS 自身业务同样受益即使不接 PAC，留存业务记录也能支撑 SaaS 自身业务：将影像与就诊、病历、收费关联，用于检查进度跟进、复诊查阅、经营分析，以及追溯当时使用的分析结果。如果不留存，这些业务就需要反复查询美亚并临时关联数据，受其接口可用性和查询能力限制；分析结果更新或撤销后，若美亚不提供历史版本，SaaS 就难以还原当时使用的依据。

3.2 新老影像怎么归一

业务语义归一，来源实现分开。 新老功能可以保留，实际择一使用；对下游都应能回答同一组问题：

• 影像属于谁、在哪里拍摄，是什么类型、什么时候拍摄；
• 当前是否有效，怎样查看，有哪些分析结果。

如果下游直接依赖“老影像的一套字段”和“美亚的另一套字段”，每切换一次影像系统，下游都要跟着改。 统一表达后，来源切换主要由 SaaS 处理，PAC 继续按宿主事实消费。

但统一不等于强行写入旧表。美亚有检查、切片、绑定状态和外部文件标识；如果旧结构表达不了，不能为了兼容丢掉它们，也不能把临时链接塞进旧文件地址就算完成。是否复用旧表，是方案采纳后的存储设计选择。

如果未来把历史影像迁入美亚，应保留新旧标识的对应关系。同一张片换了存储位置，不应被当成一次新的拍摄或重复的分析依据。

PAC 在这条链路中的职责保持两项：

1. 消费影像分析。 将宿主提供的有效分析结果作为诊断信号源之一，与其他患者事实共同用于画像与召回，并保留来源依据。
2. 提供影像查看入口。 沿用宿主槽位打开 FridaySaaS，由宿主处理新老影像入口、权限和阅片授权。

美亚生成的分析，由 SaaS 接收、留底后推给 PAC。如果 PAC 每次处理事实都临时向美亚取结果，重放同一份数据时可能拿到不同内容，就无法解释当时为什么得出那个判断。

PAC 可以知道数据来源是美亚，但美亚不应成为 PAC 核心的直接依赖。否则接入下一家影像供应商时，PAC 又要接一套鉴权、患者映射和同步机制，还可能与 SaaS 的权限及归属规则形成两套判断。 这些差异应由宿主消化。

本轮评审确认的是职责和数据留存方向：

方案采纳前，优先向美亚确认两件事：

• 01变更怎样获取有无通知；没有通知时，能否完整拉到新增、修订、撤销和归属变化，并补查遗漏。
• 02分析怎样产生和识别何时触发，怎样区分未分析、处理中、失败、完成零发现，以及结果后来是否修改。

这两项决定后续采用通知还是轮询，以及分析能否可靠成为诊断信号。具体字段、存储结构、调度周期和任务拆分，在方向采纳、能力确认后再制定。