# 疗效保障项目方案与 Milestone

> 版本：v1.2  
> 面向对象：集团管理层、业务负责人、5i5ya / Friday SaaS 相关负责人、技术负责人  
> 文档目的：明确“疗效保障”项目的项目范围、一期业务闭环、系统边界、实施路径，以及项目对 PAC 框架的依赖关系。  
> 核心结论：**疗效保障是一个正式业务项目，PAC 是该项目采用的集团级患者分析框架。** 疗效保障项目一期聚焦“治疗链已完成患者的疗效保障召回服务”，通过 PAC 完成患者事实汇聚、实时分析、Persona 画像、Follow-up Plan 生成、证据链管理与执行反馈闭环。

---

## 1. 项目定义

本项目当前名称为：**疗效保障项目**。

疗效保障项目不是单独新增一个回访页面，也不是在 5i5ya 或 Friday SaaS 中重复开发一套回访任务功能。

疗效保障项目的核心是：

```text
基于患者真实业务事实，持续分析患者状态，生成可执行的疗效保障计划，并将计划、依据、摘要和话术输出给业务宿主系统执行。
```

项目采用 PAC 框架作为底层分析能力。

```text
疗效保障项目 = 业务项目
PAC = 支撑疗效保障项目的集团级患者分析框架
```

两者关系如下：

| 对象 | 定位 |
|---|---|
| 疗效保障项目 | 面向业务落地的正式项目，当前一期聚焦治疗链已完成患者召回服务 |
| PAC 框架 | 面向患者事实、画像、计划、证据链和 AI 分析的底层框架 |
| 5i5ya / Friday SaaS | 业务宿主系统，负责业务动作承接、执行记录落地、预约 / 回访等业务闭环 |
| DW / BI / CDP / SCRM | 患者事实数据来源或辅助数据源 |
| 企微 / 外呼系统 | 触达通道，不是 PAC 的替代对象 |

PAC 不直接替代 5i5ya、Friday、企微、外呼系统或 SCRM。PAC 负责分析、计划与证据链；宿主系统负责业务动作执行和业务数据落地。

---

## 2. 项目背景

### 2.1 5i5ya 已存在回访功能

瑞尔集团现有 5i5ya 系统已经具备回访相关能力，包括回访任务、跟进记录、接待任务、400 回访记录、SCRM 跟进记录、销售机会等对象。

这些对象分别来自自建、批量创建、系统推送、尘锋同步等不同入口。

因此，疗效保障项目不是从 0 建设一个新的“回访功能”，也不是替代 5i5ya 现有回访模块。

疗效保障项目需要补齐的是：

| 能力 | 说明 |
|---|---|
| 统一患者事实视角 | 将来自不同系统、不同入口的患者变化汇聚为可追溯事实 |
| 实时分析能力 | 基于最新患者事实重新分析患者状态 |
| Persona 画像能力 | 将患者状态沉淀为可版本化、可扩展的画像特征 |
| Follow-up Plan 能力 | 基于 Persona 生成可执行的疗效保障计划 |
| 证据链能力 | 说明为什么产生该计划、依据哪些事实、使用了哪个版本 |
| AI 辅助能力 | 支持摘要、话术、计划解释、价值分析等分析任务 |

### 2.2 Friday 已完成智能召回 POC

Friday SaaS 侧已经完成智能召回能力探索，并在通善口腔做过 POC。

该 POC 验证了基于患者数据进行筛选、排序、辅助话术与回访建议的业务可行性。

后续不应继续将该能力固化在 Friday SaaS 内部，而应将其抽象为 PAC 框架能力，由 Friday SaaS、5i5ya 及后续其他宿主系统通过接口接入。

### 2.3 试点门诊范围

疗效保障项目一期试点门诊如下：

| 试点门诊 | 城市 |
|---|---|
| 杭州大厦 | 杭州 |
| 杭州高德 | 杭州 |
| 无锡学前街 | 无锡 |
| 上海世纪公园 | 上海 |
| 北京朝阳公园 | 北京 |

### 2.4 疗效保障需要支持的业务视角

疗效保障项目需要支持以下业务视角：

| 视角 | 需要支持的内容 |
|---|---|
| 回访谁 | 去重、价值排序、风险判断、近期是否适合触达 |
| 为什么回访 | 患者事实、治疗链状态、Persona 特征、Plan 生成依据 |
| 何时回访 | 基于治疗链状态、复查周期、预约状态、近期触达情况生成建议 |
| 谁回访 | 客服、前台、400、医生助理等执行角色匹配 |
| 怎么回访 | One Page Summary、参考话术、历史事实、待关注事项 |
| 回访后看什么 | 进度、效果、转化、执行质量、计划状态变化 |
| 如何解释 | 患者事实、Persona 版本、Plan 版本、证据引用 |

这些不是单个页面功能，而是疗效保障项目需要通过 PAC 框架持续输出的数据与分析能力。

---

## 3. 项目一期业务范围

### 3.1 一期业务场景

疗效保障项目一期业务场景为：

> **治疗链已完成患者的疗效保障召回服务。**

这是业务使用侧口径，也就是宿主系统通过 API Pool 2 查询和使用的能力。

宿主系统不需要理解 PAC 内部如何完成患者事实汇聚、Persona 分析、Plan 编排和 Agent 调用。宿主系统需要获得的是：

- 哪些患者进入“治疗链已完成患者疗效保障召回服务”范围。
- 为什么这些患者需要被召回。
- 建议什么时候触达。
- 建议由谁触达。
- 触达时应该参考哪些患者事实。
- 一线人员可使用的 One Page Summary。
- 一线人员可参考的话术。
- 执行后如何回写执行结果。

### 3.2 一期选择该场景的原因

一期选择“治疗链已完成患者疗效保障召回服务”，原因如下：

1. 业务边界相对清晰。
2. 数据来源相对明确。
3. 与预约、复查、诊后体验、老客户关系维护均有关联。
4. 可验证 PAC 的事实接入、实时分析、画像、计划、话术与执行反馈链路。
5. 可在 W5-W6 形成第一个业务可用闭环。

### 3.3 一期业务输出

一期需要输出以下业务能力：

| 输出能力 | 说明 |
|---|---|
| 患者召回列表 | 满足治疗链已完成疗效保障条件的患者清单 |
| 召回优先级 | 基于价值、时间、复查风险、近期触达情况等生成 |
| 召回原因 | 说明患者为什么进入本次疗效保障范围 |
| One Page Summary | 一线使用的患者简要信息 |
| 参考话术 | 根据患者事实与疗效保障目标生成 |
| 参考证据 | 关联患者事实、画像版本、Plan 版本 |
| Follow-up Plan | 建议触达时间、触达方式、执行角色 |
| 执行结果回写 | 宿主系统将执行情况反馈给 PAC |

---

## 4. 项目一期系统范围

疗效保障项目一期系统范围包括三类能力：API Pool 1、API Pool 2、Agent Pool。

这些能力属于 PAC 框架的组成部分，但在一期项目中按“治疗链已完成患者疗效保障召回服务”的业务闭环落地。

### 4.1 API Pool 1：事实输入池

API Pool 1 是宿主系统 / 数据源系统给 PAC 的患者事实输入池。

终态上，API Pool 1 需要支持：

- 业务系统主动 Push。
- PAC 主动 Pull。
- 业务系统 API。
- 异步 DW。
- BI / CDP / SCRM 等外部数据源。
- 批量冷启动。
- 增量更新。
- 单患者即时刷新。

一期项目先支持 **DW 数据源接入**。

一期 API Pool 1 输入范围如下：

| 输入范围 | 说明 |
|---|---|
| 患者基础信息 | 患者 ID、姓名、联系方式、所属门诊、主诊 / 客服等基础信息 |
| 就诊事实 | 到诊、接诊、治疗链相关时间线 |
| 治疗事实 | 已完成治疗、治疗链完成状态、后续复查相关信息 |
| 预约事实 | 已预约、取消预约、未来预约等状态 |
| 收费 / 消费事实 | 用于判断价值与后续服务机会 |
| 已有回访 / 跟进事实 | 近期是否已触达、触达结果、触达频次 |

一期通过 DW 表 / 中间表方式接入，避免一开始要求 5i5ya 或 Friday 改造所有业务节点。

后续可逐步增加业务系统 Push、宿主系统 API Pull、单患者即时刷新等能力。

### 4.2 API Pool 2：能力查询池

API Pool 2 是 PAC 给宿主系统的能力查询池。

一期项目中，API Pool 2 输出一个明确业务能力：

> **查询治疗链已完成患者疗效保障召回服务结果。**

API Pool 2 一期输出内容包括：

| 输出对象 | 说明 |
|---|---|
| 患者召回列表 | 满足治疗链已完成疗效保障条件的患者清单 |
| 召回优先级 | 基于价值、时间、复查风险、近期触达情况等生成 |
| 召回原因 | 为什么该患者进入疗效保障范围 |
| One Page Summary | 给一线使用的患者简要信息 |
| 参考话术 | 根据患者事实与疗效保障目标生成 |
| 参考证据 | 关联患者事实、画像版本、Plan 版本 |
| Follow-up Plan | 建议触达时间、触达方式、执行角色 |
| 执行结果回写接口 | 宿主系统将执行情况反馈给 PAC |

### 4.3 Agent Pool：AI 分析工具池

Agent Pool 是 PAC 内部调用的 AI 分析工具池。

Agent 不直接操作宿主系统，不直接创建预约，不直接写 5i5ya 或 Friday 的业务数据。

Agent 的作用是参与 PAC 内部分析链路，辅助完成 Persona、Plan、Summary、话术、证据解释等分析任务。

一期 Agent Pool 包括：

| Agent / 分析工具 | 一期作用 |
|---|---|
| 话术 Agent | 根据患者事实、Plan 目标和沟通场景生成参考话术 |
| 患者筛选 / 排序分析 Agent | 辅助解释患者为什么进入召回范围，并给出排序依据 |
| Follow-up Plan 分析 Agent | 辅助生成或解释 Plan，包括触达目标、节奏和建议执行方式 |
| 病历 / 诊疗摘要 Agent | 生成一线可读的诊疗 Summary 和 One Page Summary 材料 |

Agent 的输出由 PAC 分析编排层统一管理，不能直接作为宿主系统业务动作。

### 4.4 一期不纳入范围

一期项目不纳入以下内容：

- 不重构 5i5ya 既有回访任务体系。
- 不重构 Friday SaaS 的业务流程。
- 不直接替代企微、外呼、SCRM。
- 不一次性覆盖所有回访场景。
- 不一次性建设完整 CDP。
- 不把所有患者运营逻辑一次性 Agent 化。
- 不要求 API Pool 1 一次性接入所有业务系统实时 Push。

一期目标不是缩减项目，而是限定第一阶段业务闭环范围。

---

## 5. PAC 框架核心约束

疗效保障项目应用 PAC 框架。以下约束属于 PAC 框架的基础约束，不是一期临时约束。

### 5.1 实时分析是建立 Follow-up Plan 的唯一基础

PAC 生成或重构 Follow-up Plan 时，必须基于当前可获得的最新患者事实进行分析。

这里的“实时分析”不是指所有数据都必须秒级同步，而是指：

```text
Plan 不能基于静态名单、一次性导出表格、人工固定标签或历史计划惯性直接生成。
Plan 必须基于 PAC 当前掌握的最新患者事实重新分析后生成。
```

PAC 的基础链路是：

```text
患者事实变化 → PAC 更新时间轴 → 实时重算 Persona → 生成 / 重构 Follow-up Plan → 输出给宿主系统执行
```

### 5.2 Persona 只存储特征与特征描述

PAC 的 Persona 画像只存储：

```text
Persona = 特征 + 特征描述 + 证据引用 + 版本信息
```

以“客户价值”为例：

| 存储对象 | 说明 |
|---|---|
| 特征 | 客户价值 |
| 特征描述 | 对该患者价值来源、服务机会、复查意义、后续关系维护价值的自然语言描述 |
| 证据引用 | 对应患者事实、时间轴记录、诊疗记录、收费 / 预约 / 回访事实等 |
| 版本信息 | Persona 版本、分析时间、使用规则 / Agent / 模型版本 |

PAC 不把“价值描述”进一步拆成固定字段，例如不要求拆成固定的 value_score、treatment_value、relationship_value、risk_score 等字段供宿主系统逐字段消费。

API Pool 2 可以返回：

- Persona 特征名称。
- Persona 特征描述。
- Persona 版本。
- 证据引用。
- Follow-up Plan 关联关系。

API Pool 2 不承诺支持对画像描述内容进行字段级解析。

该约束用于避免 PAC 被宿主系统反向绑定成一组固定业务字段，也避免为了适配单一场景过早固化画像模型。后续如需增加结构化特征，应以“新增特征维度”的方式扩展，而不是拆解已有特征描述。

### 5.3 接口 1 与接口 2 必须区分

PAC 严格区分两类接口。

| 接口 | 定义 | 是否触发重新分析 |
|---|---|---|
| 接口 1 | 患者事实变化接口 | 是 |
| 接口 2 | Follow-up Plan 执行结果接口 | 否 |

接口 1 是宿主系统 / 数据源系统给 PAC 的患者真实事实变化。接口 1 的数据会进入患者事实时间轴，并参与 Persona 和 Follow-up Plan 的重新分析。

接口 2 是宿主系统在执行 PAC 输出的 Follow-up Plan 后，对 PAC 的执行反馈。接口 2 只用于更新 Follow-up Plan 的执行状态，不直接作为患者重新分析的证据。

如果不区分接口 1 和接口 2，会导致客服执行过程被误当成患者事实，污染 Persona 画像。

### 5.4 Agent 是受控分析工具

Agent 是 PAC 内部分析工具，不是业务系统操作员。

Agent 的边界如下：

- Agent 不直接写宿主系统数据。
- Agent 不直接创建预约。
- Agent 不直接决定业务动作是否落地。
- Agent 输出必须落地保存。
- Agent 输出必须带版本。
- Agent 输出必须关联输入事实、规则、Prompt 或模型版本。
- Agent 输出可以被规则引擎、排序器、编排器二次处理。
- 业务最终输出由 PAC 的分析编排层统一生成。

### 5.5 证据链与版本化

PAC 输出的每一个 Persona 和 Follow-up Plan 都必须可解释。

需要能回答：

- 为什么这个患者进入名单？
- 为什么优先级高？
- 为什么建议现在触达？
- 为什么建议这个话术？
- 依据哪些患者事实？
- 使用了哪个画像版本？
- 使用了哪个 Plan 版本？
- 使用了哪些规则或 Agent？

---

## 6. PAC 框架方案

### 6.1 PAC 定义

PAC，全称 Patient Analyze Center，是集团级患者分析框架。

PAC 是框架，不是单个业务功能。

PAC 为疗效保障以及后续更多患者运营场景提供统一能力：

```text
患者事实接入 → 患者事实时间轴 → 实时分析 → Persona 画像 → Follow-up Plan → 输出给宿主系统执行
```

### 6.2 PAC 系统边界

PAC 负责：

- 接收患者事实变化。
- 保存患者真实事实数据时间轴。
- 基于最新事实实时分析患者状态。
- 生成 Persona 画像。
- 保存 Persona 画像版本。
- 生成 Follow-up Plan。
- 保存 Follow-up Plan 版本。
- 生成参考话术、One Page Summary、病历 Summary、诊疗价值摘要等辅助材料。
- 向宿主系统提供查询接口。
- 接收 Follow-up Plan 的执行结果，更新计划执行状态。

PAC 不负责：

- 不直接创建 5i5ya 或 Friday 的预约业务数据。
- 不直接替代 5i5ya 的回访任务体系。
- 不直接替代企业微信、外呼系统、SCRM。
- 不把接口 2 的执行反馈作为患者重新分析的证据。
- 不以字段级强契约反向绑定宿主系统。

宿主系统是否真实完成预约、是否将回访记录落到自己的业务表、是否触发企业微信或外呼系统，是宿主系统自己的业务责任。

PAC 提供可落地接口和执行结果接收能力，但不越界替代宿主业务系统。

### 6.3 PAC 总体架构

```mermaid
flowchart LR
    A[Friday SaaS] -->|业务事实 / 查询使用| P[PAC 框架]
    B[5i5ya] -->|业务事实 / 查询使用| P
    C[异步 DW / BI / CDP] -->|批量或增量数据| P

    P --> D[患者事实时间轴]
    D --> E[实时分析 / Persona 引擎]
    E --> F[Follow-up Plan 引擎]
    F --> G[话术 / One Page Summary / 参考材料]

    P -->|API Pool 2| A
    P -->|API Pool 2| B

    A -->|执行回访 / 预约 / 记录| H[业务动作落地]
    B -->|执行回访 / 预约 / 记录| H

    H -->|接口 2：执行结果反馈| P
    A -->|接口 1：患者事实变化| P
    B -->|接口 1：患者事实变化| P
```

### 6.4 三层核心模型

#### 第一层：患者事实层

接收来自宿主系统的真实业务变化，例如：

- 患者档案变化。
- 预约变化。
- 到诊变化。
- 诊断变化。
- 治疗变化。
- 收费变化。
- 回访任务在宿主系统中的执行落地变化。
- SCRM 跟进记录、销售机会等外部变化。

这些数据作为患者事实时间轴落地，是 PAC 重新分析患者的证据来源。

#### 第二层：Persona 画像层

PAC 根据患者事实生成画像。

画像维度必须可扩展，不做一次性写死。例如：

- 患者价值画像。
- 治疗链状态画像。
- 未完成治疗画像。
- 复查风险画像。
- 沟通偏好画像。
- 客户体验风险画像。
- 家庭 / 社会关系画像。
- 推荐关系画像。
- 医生 / 客服关系画像。

今天只做“价值”，后续可以加“社会关系”“投诉风险”等维度。画像维度是可演进资产，不是固定字段。

#### 第三层：Follow-up Plan 层

基于 Persona 画像生成疗效保障计划。

Follow-up Plan 包含：

- 回访目标。
- 回访优先级。
- 推荐执行时间。
- 推荐执行人 / 执行角色。
- 推荐触达方式。
- 参考话术。
- One Page Summary。
- 证据引用。
- Plan 版本。
- 执行状态。

### 6.5 三类 Pool 与分析编排层

PAC 技术侧抽象为三类 Pool：

```text
API Pool 1：事实输入池
API Pool 2：能力查询池
Agent Pool：AI 分析工具池
```

三类 Pool 由 PAC 内部分析编排层统一调度。

```text
API Pool 1 → 患者事实时间轴 → 分析编排层 → Agent Pool / 规则引擎 / 排序器 → Persona / Plan → API Pool 2
```

### 6.6 PAC 本地落地的数据资产

PAC 必须本地落地以下数据：

| 数据资产 | 说明 |
|---|---|
| 患者事实时间轴 | 来自接口 1 的真实患者事实变化 |
| Persona 画像版本 | 每次分析生成的画像版本 |
| Follow-up Plan 版本 | 每次生成或重构的计划版本 |
| 支持材料 | One Page Summary、病历 Summary、参考话术、AI 生成材料等 |
| Agent 调用记录 | 输入、输出、模型、Prompt、Token、调用状态等 |
| 执行反馈记录 | 来自接口 2 的 Plan 执行状态反馈 |

这些数据不是临时展示内容，而是疗效保障项目可追溯、可解释、可审计的基础。

---

## 7. Milestone

### 7.1 总体节奏

第一个业务可用节点设定在 **W5-W6**。

这里的 W1-W2 表示第一周到第二周，不是“一到两周”。

| 阶段 | 时间 | 目标 |
|---|---|---|
| Phase 1 | W1-W2 | PAC 框架搭建 |
| Phase 2 | W2-W3 | API Pool 1 一期接入，先支持 DW 数据源 |
| Phase 3 | W3-W4 | Agent Pool 一期能力 + Persona / Plan 初版 |
| Phase 4 | W4-W5 | API Pool 2 一期能力 + 宿主查询能力 |
| Phase 5 | W5-W6 | 第一个业务可用节点：治疗链已完成患者疗效保障召回服务 |
| Phase 6 | W6 之后 | 试点优化与第二业务场景准备 |

### 7.2 Phase 1：PAC 框架搭建（W1-W2）

目标：先把 PAC 做成独立可运行的分析框架，而不是直接写死成单一回访功能。

交付内容：

- PAC 独立服务工程骨架。
- 基础数据库结构。
- 患者事实时间轴模型。
- Persona 版本模型。
- Follow-up Plan 版本模型。
- API Pool 1 / API Pool 2 基础路由。
- Agent Pool 调用框架。
- 基础权限与租户 / 门诊隔离。
- 基础日志、审计、调用记录。

### 7.3 Phase 2：API Pool 1 一期接入，先支持 DW（W2-W3）

目标：先打通 DW 到 PAC 的事实输入链路。

交付内容：

- DW 数据源接入。
- 试点门诊患者基础数据接入。
- 治疗链完成状态接入。
- 预约、收费、回访 / 跟进等必要事实接入。
- 增量更新机制。
- 数据入库校验。
- 数据版本与时间轴落地。

### 7.4 Phase 3：Agent Pool 一期能力 + Persona / Plan 初版（W3-W4）

目标：形成第一版患者分析结果和 Plan 生成能力。

交付内容：

- 话术 Agent。
- 患者筛选 / 排序分析 Agent。
- Follow-up Plan 分析 Agent。
- 病历 / 诊疗摘要 Agent。
- 治疗链已完成患者识别规则。
- 召回优先级计算。
- Persona 初版。
- Follow-up Plan 初版。
- One Page Summary 初版。
- 参考话术初版。

### 7.5 Phase 4：API Pool 2 一期能力 + 宿主查询（W4-W5）

目标：让宿主系统可以查询 PAC 输出结果。

交付内容：

- 查询治疗链已完成患者疗效保障召回列表。
- 查询患者 One Page Summary。
- 查询患者 Follow-up Plan。
- 查询召回原因与证据。
- 查询参考话术。
- 执行结果回写接口。
- 基础鉴权与门诊隔离。
- 宿主系统调用示例。

### 7.6 Phase 5：第一个业务可用节点（W5-W6）

目标：试点门诊可以使用 PAC 输出结果进行实际回访执行。

交付内容：

- 5 家试点门诊数据跑通。
- 生成第一批治疗链已完成患者疗效保障召回清单。
- 生成对应 One Page Summary、参考话术和 Follow-up Plan。
- 宿主系统或运营侧可以查询和使用。
- 执行结果可以回写 PAC。
- PAC 可以根据最新事实和执行结果更新计划状态。
- 形成第一版业务效果观察数据。

### 7.7 Phase 6：W6 之后，试点优化与第二场景准备

目标：基于试点反馈优化规则、话术、Plan 生成逻辑，并准备第二个业务场景。

可扩展方向包括：

- 复查提醒。
- 诊后跟进。
- 未完成治疗召回。
- 沉睡客户激活。
- 高价值病例跟进。
- 家庭关系 / 社会关系运营。
- 活动邀约。
- 投诉后安抚。

---

## 8. 验收口径

一期项目完成时，需要达到以下结果：

1. PAC 可以从 DW 获取 5 家试点门诊所需患者事实。
2. PAC 可以形成患者事实时间轴。
3. PAC 可以对治疗链已完成患者进行实时分析。
4. PAC 可以生成 Persona / 分析结果。
5. PAC 可以生成 Follow-up Plan。
6. PAC 可以生成 One Page Summary 与参考话术。
7. 宿主系统可以通过 API Pool 2 查询结果。
8. 宿主系统可以回写执行结果。
9. PAC 可以保存事实、画像、计划、话术、执行结果的版本与证据关系。
10. PAC 的 Persona 画像按“特征 + 特征描述 + 证据引用 + 版本信息”落地，不对特征描述做字段级拆解存储。
11. 试点门诊可以基于该能力进行实际回访执行。

---

## 9. 组织分工

### 9.1 PAC 团队

负责：

- PAC 框架搭建。
- API Pool 1 / API Pool 2 设计与实现。
- Agent Pool 分析链路实现。
- Persona / Follow-up Plan 模型设计。
- 数据版本、证据链、审计与日志。
- 与 DW、5i5ya、Friday 的系统对接。

### 9.2 5i5ya 团队

负责：

- 提供现有回访、跟进、接待、预约、患者等业务对象说明。
- 提供必要的数据接口或 DW 数据口径支持。
- 承接疗效保障结果在 5i5ya 侧的展示、任务承接或执行记录落地。

### 9.3 Friday SaaS 团队

负责：

- 提供 Friday 已完成智能召回 POC 的业务经验与规则资产。
- 提供 Friday 侧患者、预约、治疗、收费、回访等数据口径。
- 配合将 Friday 内部智能召回能力抽象沉淀到 PAC 框架。

### 9.4 运营侧

负责：

- 试点门诊执行组织。
- 回访执行人员安排。
- 业务反馈收集。
- 话术与 One Page Summary 使用反馈。
- 回访结果复盘。

---

## 10. 与现在已经执行的技术方案的关系

当前已经执行的技术方案，与本方案在工程方向上本质一致。

本方案不是推翻现有技术方案，也不是要求重新设计一套系统，而是在现有技术方案基础上完成以下调整：

1. 将项目名称从“智能召回 / Recall Service”调整为“疗效保障项目”。
2. 将底层能力统一定义为 PAC 框架。
3. 补充 PAC 与疗效保障项目之间的关系定义。
4. 补充患者事实、Persona、Follow-up Plan、证据链、执行反馈等边界约束。
5. 明确一期业务范围为“治疗链已完成患者的疗效保障召回服务”。

现有技术方案中的以下工程方向继续保留：

| 保留方向 | 说明 |
|---|---|
| 独立服务 | PAC 作为独立分析框架部署，不嵌入某一个宿主系统内部 |
| 独立数据库 | PAC 本地落地患者事实、Persona 版本、Plan 版本、执行记录和证据链 |
| 宿主低成本接入 | 5i5ya、Friday SaaS 等宿主系统通过接口方式接入 PAC |
| iframe / 独立页面接入 | 可作为一期快速承载方式，后续可扩展为更深度集成 |
| Token Exchange 鉴权 | 宿主系统通过换票机制获得 PAC 访问凭证 |
| 同步引擎 | 支持从 DW / 宿主系统拉取增量患者事实 |
| 多租户 / 多门诊隔离 | 支持集团内不同系统、不同门诊的数据隔离 |
| 规则配置 | 支持不同业务场景下的筛选、排序、触达规则配置 |
| AI 调用记录 | 记录 Agent / 模型调用过程、版本、成本和结果 |
| API 文档 | 对 API Pool 1、API Pool 2 形成清晰接口契约 |

因此，二者关系可以表述为：

```text
现在已经执行的技术方案 = PAC 框架的工程实现基础
本方案 = 在现有工程方向上，补充项目定义、业务边界、PAC 框架约束与一期落地路径
```

调整后的项目关系为：

```text
疗效保障项目 = 正式业务项目
PAC 框架 = 疗效保障项目采用的集团级患者分析框架
当前已执行技术方案 = PAC 框架的工程基础
```

后续执行时，不需要重新推翻技术路线；需要在现有技术方案上统一命名、补齐边界定义，并按本方案的一期业务范围推进落地。

