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

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

## 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_*` 留痕，字段已留。