touyun-elderly-care/docs/requirements/评估机构端-待设计清单.md

评估机构端 · 待设计清单（后续阶段）

状态：宏观要做，但当前无任何文档定义，是纯缺口。本文只列「需要设计什么」与「开放问题」，不含既定需求。补入正式需求后移出本文。

1. 现状（唯一落点）

• 服务机构端 PRD 仅在 elder 表记录外部评估机构：assess_org（评估机构名）、assess_date（评估结论日期）、assess_level（失能等级）。
• 无评估端产品、门户、接口、角色。
• 政策口径：服务机构端「不做评估、不出评估结论」，评估属评估机构职责（P0 PRD §11.1）。

2. 待设计领域（开放）

1. 定位与形态：评估机构端是独立后台？独立 APP？还是与服务机构端同一平台下的另一类租户？
2. 角色与账号：评估机构管理员、评估员；与服务机构端 org/user 的关系（多租户模型如何区分两类机构）。
3. 评估任务生命周期：受理 → 派评估员 → 上门评估 → 出结论 → 回传。
4. 评估量表与等级判定：国家/云南失能评估标准、量表结构化、等级计算（sev_1..3）。
5. 结论回流：评估结论如何写入服务机构端 elder.assess_level（接口直连 vs 文件导入）。
6. 与医保/官方对接：评估结论是否来自省平台；接口规范未发布（同服务机构端 R5 预留口径）。
7. 复评/到期重评：与服务机构端「复评等待期」「待遇到期」状态联动。

3. 关键开放问题（待确认）

• 评估机构是否也是「多租户 org」？org.org_type 是否需要新增评估机构类型？
• 评估结论的权威来源：我方系统自产，还是对接官方/医保平台拉取？
• 现有 elder.assess_* 三字段是否够用，还是需扩展为独立评估域（如 assess_task/assess_result）？

4. 结构预留建议（本期可做、不改逻辑）

• 保持 elder.assess_* 字段现状，未来升级为独立评估域表（任务/结果/量表）。
• 服务机构端 P0 不阻塞：评估结论当前以「机构线下确认为准」落 elder.insur_verify_* 留痕，字段已留。