Skip to content

P
pac
Commit a9248e61 by luoqi
Options

Sync archived operational and design records into test

parents 70f95af3 15d08d44
Pipeline #3862 failed in 0 seconds
Showing with 542 additions and 0 deletions
docs/README.md
......@@ -22,6 +22,8 @@ PAC 客户召回与 FridayAI 的正式产品、原理和接口文档统一维护
临时规划、旧流程、环境快照、验收报告和重复销售稿移入 [_archive/](_archive/README.md)，保留原文件名、引用与移动清单。
2026 年 10 月新增归档：[美亚与患者事实开发记录](_archive/2026-10-meyer-and-patient-facts/README.md)、[运维验收与架构讨论](_archive/2026-10-operations-and-design/README.md)。
设计准则、行为埋点和架构决策已全部归档至 [_archive/design/](_archive/design/) 与 [_archive/adr/](_archive/adr/)。
Claude Code 的编号资料见 [FridayAI 开发档案](_archive/friday-ai/docs/README.md)。未结事项见[跟进清单](qa/follow-ups.md)，归档不表示解决。环境现状需要重新查询；当前行为以代码和正式文档为准。
docs/qa/2026-10-14-push-latency-local.md → docs/_archive/2026-10-operations-and-design/2026-10-14-push-latency-local.md
# Push 关键路径优化与排障（本地）
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
分支 `codex/push-latency-fix`，基于 main `99fb2648cacdafcd0f26ec8540d04c8465ecbb87`。独立 worktree，主目录及正在运行的本地服务未变。已提交并部署测试；生产未改动。
## 最终边界
......@@ -60,3 +62,23 @@
- 历史字段审计在后台完成 20ms，不阻塞响应。同期主档请求 195ms。健康 JSON status=ok。
- 本条真实预约没有慢环节，确认业务落库后毫秒级返回；它不能证明此前分钟级超时的具体根因，也不是宿主建预约到消费响应的端到端计时。
- 已获得真实预约样本，暂停本轮定时跟踪。生产未修改。
## 生产发布准备（2026-10-14）
- 用户验收测试并授权合 main、部署生产；检查发现 4 个召回主查询及其并行进程运行中，用户进一步明确允许中断本轮后部署。
- main 快进到 `584bd3dd34c2ed20f313d31c476b7f14220f4a88`；相比测试的业务代码相同，增加测试验收记录。没有将 test 的其他提交合入 main。
- 生产原版本 `99fb264`，可用内存约 11GiB、/data 可用134GiB，旧服务健康。队列为空但召回SQL活跃，不能据队列断言空闲。
- 有一条13:03:41开始的病历 push 仍标 running，早于原容器13:03:42启动；未将其状态改成功/失败。
- 回退目录 `/data/backups/pac-release/584bd3d-20261014`：原源码SHA、PAC旧镜像及回退标签、私密配置副本、Compose校验值、迁移元数据、AI/ingress原镜像和启动时间、构建/部署日志与退出标记。配置/镜像备份不是业务数据备份。
- 生产镜像构建退出0。使用 COMPOSE_MANAGED=1、固定SHA、标准发布脚本 --no-pull，只发布PAC；本次唯一数据库变更为并发索引，不重放数据。
## 生产发布验收
- 发布时间北京时间 19:02:51—19:10:29，固定 main@584bd3d，标准部署脚本退出0。
- 并发索引扫描/校验完成后等待旧快照；按用户本轮明确授权，仅取消了4条已核对SQL形态的旧召回主查询（1540/1556/1621/1554），随后迁移成功。没有取消其他查询或手工标记业务任务成功。
- 索引迁移19:10:12完成，ready/valid均true，索引350MB；Prisma无pending。
- 实际运行镜像与构建产物一致：PAC service `271291ef75ee`，web `b88c9fbdf169`，docs `2fb22de20fd0`。
- 公网 https://pac.friday.tech/health 返回JSON status=ok；公网/plans为200；loopback及私网health/web通过；docs `/docs/integration/channel-push` 本机和私网200。
- service/web env逐字未变，Compose校验值一致；FridayAI service/web及ingress镜像和启动时间均与发布前一致。
- 首次验收期间生产Friday尚无新push，未声称生产真实推送性能已验证；测试真实预约167ms的结果见上节。
- 主目录原有未跟踪AGENTS.md/output保持原样，本地服务未操作。
docs/_archive/2026-10-operations-and-design/2026-10-14-return-visit-push-fix-test.md 0 → 100644
# 测试回访推送修复验收
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
- 功能提交：dca8663；test 合并并部署：a627d29cbf75321c88f2a58b89ea174119ac62ff。
- 仅测试环境；未合入 main、未部署生产。主目录已有文件未改。
- 根因：回访/患者关系仍加载整个租户患者索引，138772 条查询结果通过 push(...rows) 展开触发 Maximum call stack size exceeded。
- 修复：两条链路按本批引用患者、tenant、sourceUnit 查询（关系包含本人和关系人），每块1000个ID；逐条合并结果，索引查询禁止省略引用范围。
- 同类检查：摄入模块其余查询展开为固定50条；CLI患者查询已有20000条分块；未发现另一处相同的无界租户查询展开。
- 本地：5 suites / 46 tests 通过；service 两组 type-check 通过。新工作区先构建 types/utils/host-connector 和 Prisma client。
- 部署退出0，迁移无pending，运行镜像校验通过，/health JSON status=ok。
- 回退资料：测试机 /root/pac-ops/return-visit-fix-20261014，旧service/web镜像已打回退标签。
## 单条原文重放
- 原失败 syncLog：5e6bcd20-2edc-4847-8d31-f54f348ef829。
- 原证据：afc4d32c-721c-4493-9443-6c494f272a30。
- 原文保持不变，经 HMAC 签名调用正常 /pac/v1/push/rows；严格限定 Friday、customer_return_visit、1条、回访267076、患者700687。
- 成功 syncLog：2edf876a-adad-419f-83cf-534107223b07。
- HTTP200 / code0 / hasFailures=false / failed=0 / factsFailed=0 / stubs=0。
- 请求396ms；lookup-transform9ms、upsert34ms、touched8ms。
- 该回访已落 patient_return_visits：患者与祥云小镇诊所匹配，已回访，执行人5992。
- 直接调用部署版本 AgentRosterService 验证：5992在该诊所名册，recentVisits=1，inRoster=true。
- 回访为独立资源，正常 transactionsWritten=0、personaEnqueued=0；未修改事实或重算召回。
- 未重放其他回访，未读写5i5ya业务数据。
## 生产发布（用户测试确认后授权）
- main 合并版本：fa09e5ff75aa4e9414e679166b492ad98a533375。
- 一并发布 main 原有未部署改动：FridayAI侧栏导航保持会话和诊所状态（a33528b，合并efc2f64）。该修复专项9项测试及ai-web类型检查通过。
- 发布前：同步日志无running，5个业务队列active/waiting/delayed均0；召回筛选查询pid12383/12411/12412已运行约33分钟，用户明确允许中断本轮后发布。
- PAC和FridayAI串行发布均exit0，运行镜像校验通过，无待执行迁移；PAC /health、AI /health/ready、私网页面与AI到PAC连通性通过。
- 发布后旧召回查询已不在pg_stat_activity；本轮未手动重算召回。
- 截至2026-10-14 23:25（上海）未看到发布后新push，不能将测试重放结果当作生产真实回访验收；已确认生产编译代码包含scopedPatientIndexLoader。
- 检查启动后日志未见ERROR/栈溢出；未向生产重放测试回访。
- 回退目录：/data/backups/pac-release/return-visit-20261014（旧镜像标签、环境配置、compose、发布日志和退出码）。
- main主目录未提交文件及本地服务未修改；QA记录保留在隔离工作区，尚未提交。
docs/_archive/2026-10-operations-and-design/2026-10-18-business-date-shanghai-test-validation.md 0 → 100644
# 下游北京业务日期修复验收（2026-10-18）
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
## 边界与改动
- 时刻继续以 UTC 保存；下游按 `Asia/Shanghai` 解释业务日期。
- 生日、回访任务日、`@db.Date` 保持纯日期语义，不将数据库的 UTC 零点载体当成事件时刻。
- 修复上次到诊派生日期、同日就诊计数、同日病历/医嘱关联、未来回访排除、外院治疗回访日期比较、周岁及生日边界、AI 日期话术、患者详情与批次日期展示。
- 到诊分档按北京自然日稳定划分；原有天数阈值不变。下次回访表单按北京时间提交。
- 摄入、源时区转换、事实字段、数据库结构、召回阈值与按实际时长计算的冷却窗口均未修改。
## 本地验证
- 后端完整回归：145 套、2429 项通过；3 套、24 项按原有条件跳过。
- 前端：5 套、77 项通过；前后端 TypeScript 检查通过。
- 实际 PostgreSQL 在 UTC、北京、洛杉矶会话时区分别验证：同日/前日/次日回访、未来回访、生日年龄均一致；事务只读且回滚。
- Node 三种进程时区验证一致；覆盖北京零点、跨月年、闰日、纯日期、摄入零点锚、到诊 DATE 派生及同日医生关联。
- 两处旧禁忌边界测试改为完整时刻断言：北京 2026-10-28 零点对应 `2026-10-27T16:00:00Z`。
## 存量与发布范围
- 读取时计算的日期随发布生效；已持久化的上次到诊、画像特征和已生成话术不会因代码发布全部自动改写。
- 历史画像须走已有患者定向强制重算；未运行全库重算、未重摄入事实。部署测试后用真实患者定向核验。
- 本次顺序：功能分支 → test → 测试发布与验证 → 同一功能分支独立合入 main。生产不发布。
## 已完成发布与验收
- 功能分支：`codex/business-date-shanghai`，提交 `2e5e22e`。
- test 合并及实际部署：`daff13e`。
- main 独立合并：`b7901c9`；已确认功能提交同时属于 main/test 历史，未将 test 合入 main。
- 测试发布退出码 0，57 个已有迁移无待执行项；实际容器镜像与新构建镜像一致。
- 测试健康接口返回 `status: ok`，网页 HTTP 200；前后端容器运行且重启计数为 0。
- 在部署镜像内验证北京零点、周岁边界通过。
- 选取 Friday 测试宿主 3 位真实患者，调用实际到诊派生字段刷新逻辑；日期分别为 2026-10-16、2026-10-13、2026-09-21，与 PostgreSQL 北京日期计算一致。同日去重计数分别为 1、2、1。
- 3 个样本刷新前后事实行摘要一致，未改摄入数据；这些样本原有末诊日期本就正确，不能据此声称修复了全部历史数据。跨日纠错由本地边界用例验证。
- 仅刷新所选患者的到诊派生字段，未运行全量画像或召回重算；已生成话术未批量重建。
- 生产未部署。主目录已有未提交文件、本地服务和美亚工作区未操作。
服务器验收与回退证据保留于测试机 `/root/pac-release-backups/business-date-20261018/`；本文未包含患者身份与凭据。
docs/_archive/2026-10-operations-and-design/2026-10-18-jvs-complaint-ingestion-prod-validation.md 0 → 100644
# 5i5ya 投诉摄入：生产发布与真实数据验收
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
日期：2026-10-18（Asia/Shanghai）
**结论：已合入 main 并部署生产；34 个真实患者身份对应的 75 张反馈单、184 条跟进，落库与重复摄入核验通过。**
## 版本与发布范围
- 功能提交：`3d29ada`，分支 `codex/jvs-complaint-ingestion`。
- main 合并及生产版本：`1793c1bcdd43ea70d420a5d00c549d1c9503fd59`。
- test 保持已验收版本 `c9360bcb853c3cd7d20ad1201e5e82c1e243a96b`。
- 从功能分支合入 main，没有将 test 上的其他功能带入生产。
- FridaySaaS 投诉未接入，召回规则未修改；本次没有新增数据库迁移。
- 沿用此前同一功能提交的本地测试结果：143 组、2,411 项通过，另行真实样本及隔离 PostgreSQL 验证 26 项通过。本轮执行生产构建及真实数据库验收。
## 发布前任务与部署
发布准备时摄入已结束，队列没有执行中的任务，但数据库仍有召回筛选长查询。不能仅凭摄入账本和队列为空判断系统空闲。用户明确允许中断本轮后，执行应用重建。
构建最初因 Dockerfile 外部解析器镜像下载失败而中止；使用删除首行解析器指令的临时 Dockerfile 副本，交由 Docker 内置解析器完成构建。其余构建指令、源码及生产构建参数保持一致，未修改仓库 Dockerfile。发布采用既有脚本的迁移、强制重建及验收流程，构建步骤替换为校验已构建镜像 ID 和固定提交。
生产约 17:21 完成应用替换：
- 57 份现有迁移，无待执行迁移。
- service 镜像：`1a258da2c107d5c2c2320a8075f27f5feb306791352f454ab3c1f5fbdfb830c3`。
- web 镜像：`96824485987118fba9bac734b1c943134ec64e1b2018f820f5920361358f8283`。
- 两容器实际镜像均与构建结果一致，检查时重启次数均为 0。
- `/health` 返回 `status: ok`；前端本机、私网及生产公网 `/plans` 均为 HTTP 200。
- 使用 managed 配置，只替换 PAC 应用容器，未重启托管 PostgreSQL/Redis。
- 旧版本 `76e7d5b` 和旧镜像保留，私有发布证据：`/data/pac-release-backups/complaint-20261018/`。
## 真实数仓到生产 PAC
发布后通过生产环境连接重新只读查询 `dw_group.fact_complain_out`，使用正式 `sync-incremental` 流程摄入。患者范围限定为 34 个品牌＋患者身份，单批 50、并发 1，使用 `--no-recompute`，未另启全量画像或召回计算。
| 验收项 | 结果 |
|---|---:|
| 源投诉及跟进行 | 194 |
| 聚合反馈单 | 75 |
| 有效未完成投诉 | 4 |
| 有效已完成投诉 | 20 |
| 非有效快照 | 51 |
| 跟进记录 | 184 |
| 逐条落库一致 | 75 / 75 |
| 投诉事务 / 事实版本 | 75 / 75 |
| 归属、内容、状态、时间差异 | 0 |
51 张非有效快照包括表扬、中性、未知或草稿等，保留为 `invalidated`，不作为有效投诉信号。
首轮于 17:22:45 完成，cohort 处理 9.392 秒，运行 ID `5c06e2f9-89e4-4712-b923-08ddff41c848`。正式 cohort 会同时处理这些患者的其他已有资源：整批新增 360 条事务、80 条事实，其中投诉为 75 条；整批及事实失败数均为 0。
逐条核对患者外部 ID、租户、品牌、诊所、状态、正文与标准字段、发生时间、来源版本时间和完整跟进；另以显式 `+08:00` 独立转换源时间，75 张反馈单及 184 条跟进均无差异。
第二轮于 17:23:12 完成，cohort 处理 7.333 秒，运行 ID `1a30e0f6-f96f-45ef-8db8-61f72064e969`。整批新增事务为 0、事实新增及替换均为 0；投诉仍为 75 条事务和 75 个事实版本，事实指纹不变，幂等验收通过。
两轮均确认全局增量游标未因抽样验收而推进。原始样本、患者清单和核对证据仅留在私有验收目录，不进入 Git。
## 后续自动摄入与边界
生产已注册 `jvs-dw` 常规调度：`15 0,8-22/2 * * *`，时区 Asia/Shanghai；验收结束后的下一次计划为当日 18:15。投诉历史发现由常规调度继续执行，本次 34 人验收不代表全量投诉已补齐。
最终检查无执行中的摄入、画像或召回账本记录，无活动数据库查询；画像队列另有 1 条延迟任务。未手动启动被中断召回轮次的全量重算。
源端没有 ETL 入仓时间及删除标记，窗口外迟到、时间字段完全不变的原地修订和物理删除仍属于既有采集边界。本次未增加对账机制。
主目录未提交文档、本地服务和美亚工作区未改动。本验收报告留在投诉独立工作区，暂未提交。
docs/_archive/2026-10-operations-and-design/2026-10-18-jvs-complaint-ingestion-test-validation.md 0 → 100644
# 5i5ya 投诉摄入：测试发布与真实数据验收
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
日期：2026-10-18（Asia/Shanghai）
**结论：已合入 test 并部署测试环境；34 个真实患者身份、75 张反馈单的两轮摄入与逐条核验通过。main 和生产未变更。**
## 发布版本与范围
- 功能分支：`codex/jvs-complaint-ingestion`。
- 功能提交：`3d29ada`。
- test 合并提交及服务器运行版本：`c9360bcb853c3cd7d20ad1201e5e82c1e243a96b`。
- main 保持：`76e7d5bc69e98d9f61d4a967c131c4a58d3d0207`。
- FridaySaaS 投诉未接入；召回规则、画像提取器、免打扰规则未修改。
- 主目录未提交文件和本地服务未改动。美亚工作区未改动。
复查重点：投诉按配置命名空间聚合，沿用宿主患者身份；变化发现与完整跟进读取分开；新资源首轮发现历史患者；北京时间统一转 UTC；非负面、草稿和未知数据保存无效快照；重复和旧快照重放不恢复已撤销的投诉效力。
## 本次本地验证
- 回归测试：143 组、2,411 项通过；24 项按配置跳过。
- 另行显式启用真实源样本和独立 PostgreSQL 验证：2 组、26 项通过；SQL 导出辅助项未启用。
- `@pac/types` 构建通过。
- 后端源码与测试的类型检查通过。
- 提交前差异检查通过。
真实样本及数据库专项验证覆盖同时间分类修订、旧版本重放、跨品牌同号、身份冲突、完整跟进和 UTC 转换。测试库与本地应用数据库隔离。
## 测试发布检查
发布前测试服务器在 test 分支，工作目录干净；健康接口正常，磁盘剩余约 111 GB；摄入账本无 running 任务，上轮摄入已于 16:34:36 完成。
使用现有发布脚本完成镜像构建、迁移检查和应用容器替换：
- 57 份现有迁移，无待执行迁移；本改动无新表和迁移。
- service 镜像：`c5932b8708e0c39d85e5b230435c267745a66f3119d6c96a69c6524f063ba8bd`。
- web 镜像：`15746e42828714c27e8866ba2b6446f778452fff2bb7c0ce561c975c9b8c60ff`。
- 容器实际镜像与构建结果一致；最终检查两容器重启次数均为 0。
- `/health` 返回 `status: ok`，前端 HTTP 200。
- 旧提交和镜像已留存，测试服务器发布证据位于 `/root/pac-release-backups/complaint-20261018/`（私有目录）。
## 真实数仓 → 测试 PAC
从测试容器重新只读查询数仓；不是将本地造数写入测试库。
| 验收内容 | 实际结果 |
|---|---:|
| 患者范围（品牌＋患者 ID） | 34 |
| 原始投诉及跟进行 | 194 |
| 聚合后的反馈单 | 75 |
| 有效、未完成投诉 | 4 |
| 有效、已完成投诉 | 20 |
| 非有效投诉快照 | 51 |
| 保留的跟进 | 184 |
| 逐条事实核验一致 | 75 / 75 |
| 投诉事务 | 75 |
| 投诉事实版本 | 75 |
| 核验差异 | 0 |
非有效快照包括表扬、中性、未知或草稿等，均为 `invalidated`、`signal_eligible=false`，不计入有效投诉。有效投诉合计 24 张。
通过正式 `sync-incremental` CLI，使用限定的患者清单、单批 50 人、并发 1、`--no-recompute` 运行两轮。沿用完整宿主 cohort 管线，因此同批患者其他资源也按已有机制正常摄入；没有另开全量画像或召回计算。
首轮：16:47:20 完成，cohort 处理约 9.5 秒；整批失败数和事实失败数均为 0。首轮运行 ID：`d4414cca-4495-42df-9dfc-51d47777471d`。
核对包括：患者外部 ID、租户、品牌、投诉诊所、状态、正文及标准字段、发生时间、版本时间和完整跟进内容。另用显式 `+08:00` 独立转换源时间，75 张反馈单与 184 条跟进全部通过，未依赖服务器默认时区。
第二轮：投诉事务仍为 75，事实版本仍为 75，全部事实的内容指纹与第一轮一致，无重复新增或版本抖动。
两轮均保持原全局增量游标不变，投诉首轮全量发现水位仍未被抽样验收提前推进。其余患者的存量发现由后续常规增量调度处理；本次验收不代表全量投诉已经补齐。
## 已知边界
源端没有 ETL 入仓时间或删除标记。现有回看机制仍无法保证发现窗口外的迟到回填、全部时间字段不变的原地修订或物理删除。本次未扩展为对账任务，也未把投诉信号加入召回决策。
原始数据、患者清单及逐条比对证据保存在私有验收目录，不进入 Git；本报告仅记录汇总和运行证据。
docs/_archive/2026-10-operations-and-design/2026-10-19-meyer-friday-pac-imaging-review.md 0 → 100644
# 美亚 × FridaySaaS × PAC：影像与分析数据方案设计
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。 原方案中的影像事件推送未被采用，当前实现按诊所分页轮询并批量查询分析。
> 评审修订稿 v0.4 · 2026-10-19
> 本稿确认方案方向与系统边界，具体实现另行设计。
**整体边界：美亚管理影像资产并提供影像算法能力，PAC 承担患者分析层，FridaySaaS 承担应用消费层。PAC 直接对接美亚的授权和数据接口，向 FridaySaaS 开放统一的患者分析能力。**
判断依据是：**数据由各自的权威系统负责，分析由 PAC 统一组织，应用围绕结果开展业务。** FridaySaaS 定义业务患者和组织归属，美亚维护影像资产及绑定关系，PAC 校验对应关系、留存依据并形成分析。三个系统可以使用同一份关联，但不能各自猜测患者身份或独立修正归属。
## 1. 整体关系：采集呈现、患者分析、业务应用分工
FridaySaaS 沿用现有美亚接入，同步患者、诊所和就诊信息，配合影像采集并提供阅片入口。PAC 直接获取美亚影像与分析，结合病历、治疗等患者事实，向 SaaS 输出分析能力。
```mermaid
flowchart TB
E[诊所设备与前置机] --> M["美亚 PACS<br/>影像资产、阅片、影像算法"]
M --> O[OSS 原片存储]
S["FridaySaaS<br/>业务管理、影像呈现、应用消费"] -->|同步患者、诊所与就诊| M
S -->|患者身份与业务数据| P["PAC<br/>数据接入、患者分析、开放输出"]
M -->|实时推送新增影像通知| P
P -->|直接授权访问影像、批量查询分析| M
P -->|分析结果、依据与状态| S
```
FridaySaaS 在患者详情、接诊、客服等场景使用 PAC 的分析。**召回只是其中一个场景，患者是否进入召回计划不应决定其能否获得分析。**
查看原片继续走 SaaS 阅片入口，PAC 工作台可沿用宿主槽位；PAC 为分析取片则直接访问美亚。**如果分析依赖用户打开页面，没人查看的影像就可能被漏掉；如果每次打开页面才取数并计算，响应又会受外部服务和算法耗时影响。** 因此，后台持续获取和分析，页面按需读取结果、查看原片。
## 2. 美亚：实时通知新增影像，分析结果延后获取
根据美亚联调回复及后续沟通，已确认：
| 已确认信息 | 对方案的影响 |
|---|---|
| 影像数据只创建，不修改、不删除 | 按新增采集与去重，不设计影像修改、删除的同步链路 |
| 影像生成后实时推送，接收方提供回调地址 | PAC 提供回调入口，直接接收新增影像通知 |
| 上传后后台识别病症，通常约 3–5 分钟，高峰预计仍为分钟级 | 影像通知与分析结果并非同时到达；该时间不是完成时限承诺 |
| 分析接口将支持批量查询；正常查询无数据时，美亚说明算法仍在处理中 | 批量获取结果，未取得结果的后续补拉，不要求完整分析状态接口 |
| 病症分析目前仅支持全景片，CBCT 暂不支持 | 对不支持的类型不反复补拉病症分析 |
**实时通知解决“发现新影像”，延后补拉解决“取得晚到分析”。** 如果收到通知时只查一次，尚未生成的分析就可能被漏掉；没有取得结果，也不能解释为没有发现问题。
## 3. FridaySaaS：做好业务身份、影像呈现和分析消费
SaaS 负责采集接入和呈现，向 PAC 提供患者业务数据及授权上下文，再消费分析结果。**无需为了转交 PAC，再建设一套美亚分析采集和重推链路。** 否则同一份分析要经过两套同步过程，既重复维护，也增加故障定位的环节。
SaaS 保留自身业务所需的关联和操作记录。医生采纳建议、客服据此跟进时，应记录引用的分析版本及必要内容。**否则分析更新后，就难以还原当时为什么做出那次业务操作。** 分析依据和版本由 PAC 管理，业务执行由 SaaS 管理。
新老影像功能可以保留，实际择一启用：旧影像沿用 SaaS 数据通路，美亚影像由 PAC 直连获取，来源差异由 PAC 接入层统一。**应用不应随影像来源切换而重新适配；同一张片迁入美亚，也不应被当成两份独立依据。**
## 4. PAC：统一分析，留存依据，对应用负责
**① 接入归一，身份与权限沿用业务边界**
美亚接入由 PAC 独立适配层负责，转换为 PAC 标准数据后用于分析。患者对应关系以 SaaS 业务身份和美亚绑定为依据，缺失或冲突时不猜测匹配。
PAC 负责美亚服务授权；用户能查看哪些患者和分析，仍依据 SaaS 的业务授权，由 PAC 校验执行。**服务能读取多家诊所，不代表每个调用方都有权访问这些患者。**
**② 留存分析依据，原片继续由美亚管理**
PAC 保存影像关联、原始分析依据和自身分析结果，并保留来源、版本及数据时效。**如果每次都临时向美亚取结果，同一份业务数据重放时可能取得不同内容，就无法解释当时为什么得出那个判断。**
原片仍存于美亚/OSS，由 PAC 按需授权访问。美亚暂时不可用时，PAC 仍能提供已留存的结果及依据，并说明数据截至时间；原片访问和最新分析获取则可能受影响。
**③ 区分来源，开放统一的患者分析能力**
PAC 可以使用美亚已有的算法结果，也可按需要获取原片、调用其他分析服务，再结合患者事实形成综合分析。承担分析层不要求底层影像算法全部自研。
**美亚发现了什么、PAC 综合判断了什么、医生确认了什么，应分别标明来源和依据。** 否则算法发现容易被误当成医生诊断，原始结果变化时也难以追溯受影响的结论。
对已接入且获授权的患者，PAC 向应用提供分析结论、依据、版本和状态。**未取得分析结果不代表没有发现问题；PAC 只表达已知的结果可用性与能力范围，不推断美亚内部处理状态。** SaaS 使用这些结果开展业务；结果回流时也应保留来源，避免同一结论被重复当成独立依据。
## 5. 当前方案与范围
**新增影像实时通知 PAC → 留存影像记录 → 批量查询分析 → 有结果保存，无结果延后补拉。** 回调确认以通知可靠落库为界，不等待分析完成。接入前的历史影像另做首次采集。
---
### 依据与范围
本稿依据本轮评审原则、2026-10-19 美亚联调回复及后续确认，以及既有代码和本地联调记录。直连取数已有验证基础，完整分析服务仍需后续设计与实现。
参考资料：系统集成方案（本机参考文件 `瑞尔口腔影像中心PACS项目系统集成方案v0.4.pdf`，未随归档分发）、私有化部署方案（本机参考文件 `瑞尔PACS影像中心私有化部署方案v0.1.pdf`，未随归档分发）、接口对接文档（本机参考文件 `PACS_瑞尔接口对接文档.pdf`，未随归档分发）。
docs/_archive/2026-10-operations-and-design/2026-10-20-data-warehouse-and-pac-positioning.md 0 → 100644
# 公司数仓的定位与 PAC 的职责边界
> 历史归档（2026-10-22）：保留原记录日期的方案、样本和验收结论，不代表当前运行状态；现行入口见本目录索引。
> 架构讨论稿 · 2026-10-20
**公司需要独立、可复用的数据能力。以 PAC 兼任公司级数据底座，是满足当前业务的过渡方案，不能作为长期的公司数仓定位。**
过渡的是 PAC 代为承担的公共数据职责；患者分析、行动判断与执行协作，仍然是 PAC 可以长期发展的产品能力。
## 1. 数仓是什么：公司的公共数据基础
数仓持续整合不同系统、不同业务的数据，形成**定义一致、来源可追溯、质量可核对、能够重复使用**的公共数据，服务经营分析、报表、算法和业务应用。
它的价值体现在三个方面：
- **整合**：患者、诊疗、收费、营销、人员、门店等数据能够关联使用。
- **一致**：身份、时间、状态和指标有明确口径，减少各部门各算一套。
- **复用**：一次可靠接入和公共加工，可以支持多个消费者。
数仓需要独立的数据模型和治理责任。把业务库集中复制到另一个数据库，只完成了数据汇集；还需要整合语义、明确质量和使用规则。
业务系统继续维护自己的记录并办理业务。数仓通常通过同步取得数据，不要求预约、收费、写病历等日常操作经过数仓。
## 2. 公司为什么需要：让数据服务多个业务
公司需要回答的问题已经超出单一患者场景：渠道带来的患者是否到诊、治疗和收费如何衔接、不同门店和人员的表现是否可比。这些问题需要跨系统的数据和共同口径。
如果每个产品独立取数、清洗和解释，同一份数据就会产生多套加工逻辑。新增应用、源系统变更和历史补数，都会重复付出成本；结果不一致时，也难以确定谁负责。
**建设时机取决于复用和治理需求，不只取决于数据量。** 多个消费者反复使用同一批数据、口径冲突持续出现、跨系统分析成为日常工作时，就应明确公共数据能力的建设责任。
这不意味着立即建设覆盖全公司的大型平台。可以从已有重复需求开始，逐步形成公共能力；前提是有人持续负责定义、质量和交付。
## 3. PAC 当前承担了什么：为患者应用补齐数据条件
PAC 已包含多源接入、字段与语义归一、来源留存、事实版本、画像及计划更新等能力，具备部分数据仓储与治理特征。当前主要业务落点是客户召回。
这些能力首先服务于 PAC：把已接入的患者记录转化为可解释的事实，支持画像、机会判断、工作分配和跟进。
**有数据加工和事实存储，不等于具备公司级数仓的覆盖范围与服务责任。** PAC 中某条记录可供召回判断，也不意味着它已经满足财务统计、经营分析或其他产品的全部要求。
## 4. 为什么只能过渡：应用边界不能替代公司数据边界
| 局限 | 对公司的影响 |
|---|---|
| 数据覆盖随患者应用需求选择 | PAC 已接入的数据，不能代表全公司的业务数据已完整覆盖 |
| 数据语义和加工围绕患者判断组织 | 其他业务仍需核对粒度、状态与统计口径，不能直接照用应用结果 |
| 原文与版本留存在已采集范围内 | 重放可以重处理已有记录，无法恢复从未接入的数据 |
| 数据交付与应用运行相互耦合 | 多个消费者长期依赖后，公共补数、质量和变更管理会挤占产品迭代，并扩大故障影响 |
继续无边界扩充 PAC，会使其同时承担公共数据供应和患者业务交付。两类责任的消费者、覆盖范围、质量要求和变更节奏不同，需要分别管理。
## 5. 长期边界：记录、公共数据与业务判断分别负责
| 角色 | 核心责任 |
|---|---|
| **源业务系统** | 维护权威业务记录，办理业务操作，明确数据及其变更含义 |
| **公司数仓／公共数据能力** | 可靠整合、公共身份与口径、历史留存、来源追溯、质量核对及共享数据交付 |
| **PAC** | 患者事实的领域解释、画像、机会与优先级判断、行动计划、分配和反馈 |
“单一可信源”应落实为明确的权威分工：业务事实以对应源系统为准，公共分析使用经过治理的数据和指标，PAC 的判断与行动状态由 PAC 管理。无需把所有读写集中到同一个数据库。
公共数据模型应表达可复用的业务含义；源系统差异在接入与加工中处理，应用特有判断留在应用边界内。公共模型可以演进，但不应随某个来源的表结构或某个应用的临时需求任意变化。
数据完整性和正确性也需要分工：源系统负责提供明确、可靠的记录，公共数据能力负责同步与加工质量，PAC 负责自身判断及证据使用。数仓无法自动消除源端缺失或含义不明的问题。
## 6. 过渡原则：沉淀公共能力，保留产品价值
- **当前可继续交付**：PAC 在明确数据范围和质量条件下提供患者分析与召回能力，不必等待完整数仓建成。
- **公共能力逐步独立**：优先沉淀被多个消费者重复需要的接入、归一、追溯和质量核对，明确责任人与交付约定。
- **迁移按数据范围推进**：公共数据具备可验证的完整性、时效和语义后，PAC 再逐步切换，避免同一数据长期存在相互冲突的加工路径。
- **产品职责持续保留**：数仓完善后，PAC 仍维护自己的分析、计划和执行状态，并对患者相关判断负责。
外部公司的同类数据也按此原则接入：主要供 PAC 使用时，可以直接进入其接入流程；需要跨产品复用时，应纳入公共数据能力，并保留来源、授权范围及组织隔离。
**目标是让公司获得稳定的数据资产，让 PAC 集中解决患者相关的判断与行动问题。是否独立部署、采用何种数据库及如何建表，属于后续设计。**
---
### 依据
- 当前 PAC 的[架构总览](../../../apps/pac-docs/content/docs/architecture/overview.mdx)、[三层模型](../../../apps/pac-docs/content/docs/architecture/three-layer-model.mdx)与[产品概述](../../../apps/pac-docs/content/docs/start/what-is-pac.mdx)。
- [DataWorks 数仓分层](https://www.alibabacloud.com/help/en/dataworks/user-guide/data-warehouse-layering)：源数据、公共加工与应用服务的职责区分。
docs/_archive/2026-10-operations-and-design/README.md 0 → 100644
# 2026 年 10 月运维验收与架构讨论归档
2026-10-22 整理。保存 11 份独有文档，包含历史发布记录、数仓定位讨论及影像方案的不同评审版本。
## 现行入口
- [美亚采集器](../../../apps/pac-service/src/integrations/meyer/README.md)
- [患者事实查询 API](../../../apps/pac-docs/content/docs/api/open/PatientFactsLookupController_lookup.mdx)
- [PAC 产品概述](../../../apps/pac-docs/content/docs/start/what-is-pac.mdx)
- [运维说明](../../operations/README.md)
- [美亚与患者事实开发历史](../2026-10-meyer-and-patient-facts/README.md)
## 归档清单
| 文件 | 内容 |
| --- | --- |
| [2026-10-14-push-latency-local.md](2026-10-14-push-latency-local.md) | Push 优化及测试、生产验收；含此前未提交的生产验收补充 |
| [2026-10-14-return-visit-push-fix-test.md](2026-10-14-return-visit-push-fix-test.md) | 回访推送修复、单条重放和发布验收 |
| [2026-10-18-business-date-shanghai-test-validation.md](2026-10-18-business-date-shanghai-test-validation.md) | 北京业务日期修复及跨时区验证 |
| [2026-10-18-jvs-complaint-ingestion-test-validation.md](2026-10-18-jvs-complaint-ingestion-test-validation.md) | 投诉摄入测试发布与真实样本验收 |
| [2026-10-18-jvs-complaint-ingestion-prod-validation.md](2026-10-18-jvs-complaint-ingestion-prod-validation.md) | 投诉摄入生产发布与真实样本验收 |
| [2026-10-20-data-warehouse-and-pac-positioning.md](2026-10-20-data-warehouse-and-pac-positioning.md) | 数仓与 PAC 的职责边界讨论 |
| [2026-10-16-meyer-friday-pac-imaging-review.md](2026-10-16-meyer-friday-pac-imaging-review.md) | 影像早期评审稿 v0.2 |
| [2026-10-16-meyer-friday-pac-imaging-review-document.html](2026-10-16-meyer-friday-pac-imaging-review-document.html) | v0.2 独立文档版 HTML |
| [2026-10-16-meyer-friday-pac-imaging-review.html](2026-10-16-meyer-friday-pac-imaging-review.html) | v0.2 展示版 HTML |
| [2026-10-19-meyer-friday-pac-imaging-review.md](2026-10-19-meyer-friday-pac-imaging-review.md) | 影像修订评审稿 v0.4 |
| [2026-10-19-meyer-friday-pac-imaging-review-document.html](2026-10-19-meyer-friday-pac-imaging-review-document.html) | v0.4 独立文档版 HTML |
## 阅读边界
- 环境状态、版本、数据量、耗时和发布结果均为原记录日期的证据；本次没有重新查询服务器。
- 两版影像方案保存了不同阶段的职责划分，早期事件推送建议未被采用。当前按诊所分页轮询影像、批量查询分析，具体行为以现行代码为准。
- 数仓文档是架构讨论，不表示公司数仓已经建成，也不改变 PAC 现有业务职责。
- 不在此复制患者查询原文、临时访问地址、生产备份或运行凭据。内部联调资料单独备份，不纳入 Git。
- 原本机 PDF 及外部仓库源码仅保留引用说明，未作为附件发布；本仓库链接已按新位置修正。
[移动与校验清单](manifest.json)记录原路径、新路径及整理前后摘要。原始文档另有完整可恢复备份。
docs/_archive/2026-10-operations-and-design/manifest.json 0 → 100644
{
"archived_on": "2026-10-22",
"files": [
{
"from": "docs/qa/2026-10-14-push-latency-local.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-14-push-latency-local.md",
"original_sha256": "9dbe13cb926a54834dcb35a4d013f6bb4297e46668cd40d91beb47cc83a7eb73",
"archived_sha256": "ad369f52632c4f7b118429f78864a6e19594f864072297cd4c8c0ef5e59f63a5",
"category": "historical_validation"
},
{
"from": "docs/qa/2026-10-14-return-visit-push-fix-test.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-14-return-visit-push-fix-test.md",
"original_sha256": "6e92dfeeade2ce23c28b0a5e09a0429c38453ba6efadb6d5c27c8381dd82a162",
"archived_sha256": "fa0d03f1009093bd744810c38adb9c5c2c3911cc93ba030007a582d071b18bb5",
"category": "historical_validation"
},
{
"from": "docs/qa/2026-10-16-meyer-friday-pac-imaging-review-document.html",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-16-meyer-friday-pac-imaging-review-document.html",
"original_sha256": "794cd8b72fb6fd75259f4cb63715d1f6f95e9f3e31ea555f43b1c6766a1373de",
"archived_sha256": "a3387fdf95b8156838b06a875d4c35cd2a5138010b6f44bb7087999a0f0cdf40",
"category": "historical_design"
},
{
"from": "docs/qa/2026-10-16-meyer-friday-pac-imaging-review.html",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-16-meyer-friday-pac-imaging-review.html",
"original_sha256": "0adb5e5adfe6674ca7cd15b0f62e12407b57e606628a1074c139e21c4c250765",
"archived_sha256": "b9bcbb7d3fff38d3bd22c33191d3106653e37f128a5d8e8c242c7fd41fa6c467",
"category": "historical_design"
},
{
"from": "docs/qa/2026-10-16-meyer-friday-pac-imaging-review.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-16-meyer-friday-pac-imaging-review.md",
"original_sha256": "2679e80c6546802bc9d29d130a684e2b3696e1b86c79a85c5ccff92808f2332d",
"archived_sha256": "e659a0769012faa8c6e090e0dc622b0a5f86dd9adcab9c4fe6c206474b759879",
"category": "historical_design"
},
{
"from": "docs/qa/2026-10-18-business-date-shanghai-test-validation.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-18-business-date-shanghai-test-validation.md",
"original_sha256": "fff7acd4aea01673487cc8b2e96b299d877081412f3e619bdd85d69ab0a26b32",
"archived_sha256": "99be312617b0445866ea5e193d9708658940a862adf4db4d9af6c113eb98ade7",
"category": "historical_validation"
},
{
"from": "docs/qa/2026-10-18-jvs-complaint-ingestion-prod-validation.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-18-jvs-complaint-ingestion-prod-validation.md",
"original_sha256": "ddee388593323a72b30d75388f534767db88370824b362f40d7946f7d0302edc",
"archived_sha256": "64af94eb97d52140f76113c28be8193a34a9236cf930e228b0ebf9822611ecc5",
"category": "historical_validation"
},
{
"from": "docs/qa/2026-10-18-jvs-complaint-ingestion-test-validation.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-18-jvs-complaint-ingestion-test-validation.md",
"original_sha256": "ba7149068b9b7e9fe7e9dde3e40d47c464007e156e72d542da3b95dee09cc64f",
"archived_sha256": "8c3116cddafd0d03464183beccd0841a062ceda2f44d763a2afd44a18baac42f",
"category": "historical_validation"
},
{
"from": "docs/qa/2026-10-19-meyer-friday-pac-imaging-review-document.html",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-19-meyer-friday-pac-imaging-review-document.html",
"original_sha256": "aebf50c50fd912e51c4aeea1d1dd78aa1b80658d61f1c73fe4889794ea7a78a3",
"archived_sha256": "c9541bf669f483732ed9ae7bec8fd597c1aae9087954dad17ff5a803256fd64b",
"category": "historical_design"
},
{
"from": "docs/qa/2026-10-19-meyer-friday-pac-imaging-review.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-19-meyer-friday-pac-imaging-review.md",
"original_sha256": "b85aaa9b8fc67efea031156935ede484e8975af30bfee0de481c88cfb4d57e47",
"archived_sha256": "4cef9b11cfdd1ddaf40c5526016d1f427c5fb867c561acf9610fc94f019c348b",
"category": "historical_design"
},
{
"from": "docs/qa/2026-10-20-data-warehouse-and-pac-positioning.md",
"to": "docs/_archive/2026-10-operations-and-design/2026-10-20-data-warehouse-and-pac-positioning.md",
"original_sha256": "c3acd20f181483a052d66306bc007290440c6e9769bced5c62c3abfa115895fa",
"archived_sha256": "597afabd5ecfc0a7b87babf8a428cb408101d9a051e0ef546145bcc62991cbce",
"category": "architecture_discussion"
}
],
"changes": "Add historical notices, repair repository links, label unavailable local references; preserve original content in private backup."
}
docs/_archive/README.md
......@@ -4,6 +4,13 @@
归档保存历史设计、实验、排查与交付证据。文件名与原文保留；移动时修正引用。归档不等于问题关闭，不以历史环境快照判断当前运行状态。
## 2026-10-22 整理
- [美亚与患者事实开发历史](2026-10-meyer-and-patient-facts/README.md)：8 份实现、字段审核与验证记录。
- [运维验收与架构讨论](2026-10-operations-and-design/README.md)：11 份 Push、日期、投诉验收记录及数仓、影像方案讨论，含不同版本 HTML。
内部联调原文与一次性检查产物另行备份，不作为正式产品文档发布。
## 2026-10-14 整理
| 分类 | 入口 | 移入文件 | 原位置与归档依据 |
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment