touyun-elderly-care/docs/requirements/评估机构端-待设计清单.md
liuyun 87b6a532b4 docs: 入库需求与范围基线(P0 PRD + 参考文档 + 范围清单)
- docs/requirements/P0 PRD(交付开发·V1)
- docs/requirements/服务机构端-P0范围清单、评估机构端-待设计清单
- docs/refs/ 数据字典与接口契约、产品介绍

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-10-14 10:33:39 +08:00

31 lines
2.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 评估机构端 · 待设计清单(后续阶段)
> 状态:**宏观要做,但当前无任何文档定义,是纯缺口**。本文只列「需要设计什么」与「开放问题」,**不含既定需求**。补入正式需求后移出本文。
## 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_*` 留痕,字段已留。