# 投云长护险管理系统 · P0 PRD

**交付版本 · 2026-10-11 · 云南投云科技有限公司**

> **📝 修订注（2026-10-12 · R1–R9 质疑回填）**：依机构老板 22 条质疑，**把产品能改的直接写进需求**，做不到的如实标注。**改动清单**：①§3.2 待遇状态 **七态 → 十态**（新增 `待起付/等待期`、`复评等待期`、`跨统筹区转移中`；`住院暂停` 补恢复出路）；②§3.2 工单状态 **七态 → 八态**（新增 `未遇/扑空`）；③新增 **§4.5.1 拒拍出路**、**§4.5.2 拍照分档属地核对**、**§4.9.1 扑空专门形态**；④§5.5.1 新增 **B1-A 垫付台账与结转**、**B1-B 批量导入**；⑤§7.4 字段对照同步＋新增 6 个字段；⑥§8.1 新增 `3003/3004` 错误码；⑦新增 **§十三 质疑回填记录**（能改的 vs 做不到的分开列）；⑧新增 **§7.3.1 多业务线扩展（R8 预留）**＋`elder/order/svc_org` 三表加 `biz_line` 字段（本期恒 `ltci`）、§8.4 增 R8 行；⑨新增 **§13.2b 待补清单（P-9 身份核验缺口）**＋§14 增第 8 条对客边界；⑩新增 **§5.5.2 老人个人项目库（`elder_svc` 表，R10）**＋§7.2 增 `elder_svc` 表（**22 表 → 23 表**）＋§7.4 增 2 个字段＋§8.3 增 2 个接口＋§9 增验收项。**逐条依据见 §十三。** 其余章节逐字保留。

> **📝 修订注（2026-10-14 · 居家护理六流程对齐 · 只补字段不动交互）**：依《居家护理》六份流程文档（流程 01–05＋4.5）与 PRD 交叉核对，**补齐流程文档已明确、但 PRD 数据字典缺字段的 5 处硬缺口**（**只补字段、不做功能**，交互细则后补）：①`record` 表补 `biz_line` 字段（R8 从三表扩到四表，自费单独计时落点）；②`elder` 表补参保核验留痕（`insur_verify_status`/`insur_verify_date`）＋缴费年限（`insur_years`）＋上门评估五块信息（`need_assess` JSON）；③`plan` 表补 `plan_basis`（计划依据/护理服务建议）；④`settlement` 表补 `amount_fund`/`amount_self_pay`（个人自付拆分）。**自费服务（当场收款/同意凭证）本期不做、只留字段**（与 §11.2「平台不碰资金」红线一致）。

---

## 〇、怎么用这份文档（开发先看这里）

| 项 | 说明 |
|---|---|
| **这份文档是什么** | **本期要开发的东西，全在这里，不用再看别的文档。** 前面的 PRD-00～03、数据字典与接口契约，内容已全部并入本文档 |
| **本期范围** | **P0 四块**：①待遇档案／②派单工单／③履约留痕／④质控闸门。**二期三块（结算对账／资质人员／院长看板）不做，只留字段** |
| **本期要交付几个端** | **三个端 ＋ 一套后端**：护理员 APP（安卓）／机构管理后台（Web）／家属端（微信公众号 H5） |
| **设计总纲（一句话）** | **既满足长护险政策要求，又让机构用得方便、不复杂。两者冲突时——换实现方式，不砍合规、不逼一线硬扛。** |
| **文档结构** | 第一～三章＝全局规则（三端通用）；第四～六章＝三个端各自的页面；第七章＝数据库；第八章＝接口；第九章＝验收；第十章＝不做什么 |

### 0.1 先记住这五条，能少走一半弯路

1. **硬锁要"点不动"，不要"弹提醒"**——提醒会被忽略，点不动才会被遵守。
2. **锁得少、锁得准**——只锁政策明文要求的，日常照护一律宽松。
3. **必填自由文本 = 0**——护理员端不许有任何必须打字的字段。
4. **状态靠人工维护**——本期**没有**医保接口，别按"能自动感知状态"来设计。
5. **属地差异走配置、不走代码**——新增一个州市＝加配置数据，**不改代码、不发版**。

### 0.2 术语与技术口径对齐（防歧义）

| PRD 里的中文 | 技术口径 |
|---|---|
| 老人档案 | `elder` 表，主键 `elder_id` |
| 服务计划 | `plan` / `plan_item` 两张表 |
| 工单 | `order` 表，一次服务一条 |
| 服务留痕 | `record` ＋ `record_item` ＋ `record_photo` ＋ `record_abnormal` |
| 质控记录 | `qc` 表（可多次退回补正，留历史） |
| 服务项目 | `svc_national`(L1) / `svc_local`(L2) / `svc_mapping`(L3) / `svc_org`(L4) |
| 人员与资质 | `staff` 表【预留】 |

> **⚠️ 命名纪律（写死）**：**不得使用 `checkin`／`clockin`／`punch` 作为留痕表名**——留痕＝`record`。这是合规口径在代码层的落地（不做打卡工具）。

---

## 一、全局术语与分期用语

### 1.1 业务对象术语（全系统统一，不得混用）

| 术语 | 定义 | 禁止的说法 |
|---|---|---|
| **参保人** | 参加长护险的人员（政策用语） | 不说"客户""用户" |
| **待遇享受对象** | 已通过评估、正在享受待遇的参保人 | — |
| **服务对象 / 老人** | 机构实际提供护理服务的人（**界面用"老人"更亲和**） | 正式文书用"参保人" |
| **护理员** | 执行上门/院内护理服务的一线人员 | 正式文书用"护理服务人员" |
| **服务项目** | 长护险目录内的护理项目（核心主数据） | 不说"服务内容""护理项" |
| **服务计划** | 针对某位老人、由机构制定并经确认的周期服务安排 | 不说"护理方案" |
| **工单** | 计划落地后生成的一次具体服务任务 | 不说"订单""派工单" |
| **留痕** | 服务执行过程的记录（签到、项目、时长、语音、照片、异常） | **不说"打卡记录"** |
| **异常上报** | 服务现场发现问题的上报（压疮、呛咳、跌倒等） | 不说"报警" |
| **质控放行** | 质控员审核后允许该记录进入上报流程 | 不说"通过审核" |
| **上报池** | 已质控放行、待上报医保的记录集合（**二期**） | — |

### 1.2 分期用语（对客材料必须区分）

| 说法 | 含义 |
|---|---|
| **首期 / P0** | 本次交付的四块 |
| **二期 / P1** | 结算对账、资质人员、院长看板 |
| **预留位** | 数据结构与接口已留好，**功能未开发** |

---

## 二、⭐⭐ 多属地规范（本系统最大的架构特征）

> **背景**：**云南实行州（市）级统筹**（云政办规〔2025〕9 号原文），每个州市是**独立统筹区**。系统必须**同时服务昆明机构与其他州市机构**。

### 2.1 属地目录两类（规则只有两句）

| 地区类型 | 服务项目目录 | 项目数 | 官方代码 |
|---|---|:---:|:---:|
| **新建制州市**（曲靖/玉溪/楚雄/文山/西双版纳/大理/临沧 等） | **国家统一目录** | 36 | ✅ 有 |
| **昆明市**（老试点） | **本地目录** | 45 | ❌ 无 |

> **⚠️ 推定项纪律**：七州市中**仅西双版纳有原文明确**"执行国家统一的长护险服务项目目录"；其余 6 个州市为**推定**。**签约前须向属地医保机构逐一核实**，不得在正式对客材料中当既定事实写。

### 2.2 目录四层结构（数据模型基础）

| 层 | 编号前缀 | 内容 | 维护方 | 机构可见 | 可修改 |
|---|---|---|---|---|---|
| **L1 国家基准库** | `NAT_` | 国家 36 项 ＋ 官方项目代码 | 我方 | 只读 | ❌ |
| **L2 属地目录库** | `LOC_` | 每统筹区一套（昆明 45 项；州市直接引用 L1） | 我方 | 只读 | ❌ |
| **L3 属地↔国家映射表** | `MAP_` | 昆明 45 ↔ 国家 36 逐项映射 | 我方 | **不可见** | ❌ |
| **L4 机构项目库** | `ORG_` | 机构勾选的项目 ＋ 自填价格 | **机构** | 机构自管 | ✅ 仅价格与启用状态 |

### 2.3 属地加载规则（机构无感知）

```
① 机构注册 → 必填【参保地 / 统筹区】
        ↓
② 系统自动加载该统筹区的 L2 属地目录
        ↓
   州市机构：看到国家 36 项（含代码）
   昆明机构：看到本地 45 项（系统已内置 L3 映射）
        ↓
③ 机构在属地目录中【勾选】本机构开展的项目 → 【配价】→ 形成 L4 机构项目库
        ↓
④ 派单时 → 读 L4（机构实际开展的项目）
   上报时 → 读 L3 转换出的国家代码（二期对接时生效）
```

### 2.4 ⭐ 五条多属地纪律（写死）

1. **属地差异走配置、不走代码**——新增州市＝加一份 L2 配置，**不改代码、不发版**；
2. **属地项目必须可映射**——L2 中每一项都必须在 L3 里有映射；**昆明 45 项中无法映射国家的 5 项，标注"仅属地执行、不可按国家目录上报"**；
3. **机构不可改目录、不可自创项目**——只能选用＋配价。**改目录＝合规事故**；
4. **国家新增项必须显式提示**——昆明目录里没有、国家目录里有的 5 项（**吞咽功能训练／言语功能训练／雾化吸入／压疮预防照护及指导／理发**），在昆明机构勾选界面**必须显式列出并标注"过渡期新增·建议纳入"**，**不得因为本地目录没有就默认隐藏**；
5. **映射表不进对客材料**——L3 是我方技术资产，对客只说"预置属地目录＋国家目录，自动映射"。

> **⭐ 昆明 45 项 ↔ 国家 36 项映射统计（已逐项核过）**：完全对应 **19** 项／被合并 **15** 项／近似对应 **6** 项／仅属地 **5** 项 ＝ 45。L3 全量数据见《20261011-昆明45项↔国家36项-逐项映射表》。

### 2.5 ⭐ 服务计划的项目数量规则（属地差异，必须内置）

| 地区 | 护理方式 | 一级护理 | 二级护理 | 三级护理 | 附加 |
|---|---|:---:|:---:|:---:|---|
| **昆明** | 医养结合机构 | ≥18 项 | ≥15 项 | ≥13 项 | 可再选 ≤5 项 |
| **昆明** | 养老机构 | ≥18 项 | ≥15 项 | ≥13 项 | 可再选 ≤5 项 |
| **昆明** | 居家（机构上门） | 每周 ≥6 次／月 ≥40 小时 | 每周 ≥5 次／月 ≥36 小时 | 每周 ≥4 次／月 ≥32 小时 | — |
| **昆明** | 居家（个体护理人员） | ≥15 项 | ≥13 项 | ≥10 项 | 可再选 ≤5 项 |
| **州市** | 按属地实施细则配置 | **本期不校验** | **本期不校验** | **本期不校验** | — |

> **⚠️ 州市规则本期怎么做（已定，写死）**：**州市机构本期不做项数校验**——界面只提示"**州市项数规则待属地实施细则明确**"，**不拦、不卡**。
> **理由**：①各州市实施细则尚未发布，规则无从谈起；②国家 36 项**没有**"一级≥18 项"这类表述，它与昆明 45 项的颗粒度对不上，**照搬昆明＝给了错规则**；③项数规则是**配置数据不是代码结构**，细则出来后**补一份配置即可，不改代码、不发版**（属地差异走配置的既定纪律）。
> **⚠️ 不得的做法**：**不得把昆明规则（18/15/13）照搬给州市机构**——给错规则比不给更糟。

> **⚠️ 等级方向（全系统必须写清，不得省略）**：昆明口径**"重度失能一级＝失能等级最高级，一级护理＝护理级别最高级"**。
> ⇒ **一级护理要求最高**（≥18 项／每周 6 次），与"一级最轻"的直觉**相反**。**界面上必须写"一级护理（最高级）"，不得只写"一级护理"。**

---

## 三、数据主干、状态机、硬锁、权限

### 3.1 数据主干（五个核心对象的关系）

```
        ┌─────────────┐
        │  ① 老人档案  │  ← 待遇状态（有效期、护理等级、参保地）
        │  ELDER      │
        └──────┬──────┘
               │ 1 : N
        ┌──────▼──────┐
        │  ② 服务计划  │  ← 周期、项目清单、频次、时长、三方确认
        │  PLAN       │
        └──────┬──────┘
               │ 1 : N
        ┌──────▼──────┐
        │  ③ 工单      │  ← 某天某次某项目、派给谁、状态
        │  ORDER      │
        └──────┬──────┘
               │ 1 : 1
        ┌──────▼──────┐
        │  ④ 服务留痕  │  ← 签到/签退、时长、语音、照片、项目执行
        │  RECORD     │
        └──────┬──────┘
               │ N : 1（汇总）
        ┌──────▼──────┐
        │  ⑤ 质控记录  │  ← 审核结论、放行/退回、异常处理
        │  QC         │
        └─────────────┘

   横向：⑥ 人员与资质（〔二期〕，本期=人工登记）
   出口：⑦ 上报池 → 结算对账（〔二期〕）
```

**三条数据铁律**：
1. **一次录入、三端同源**——同一事实只录一次，不在别处手工重填；
2. **不可无痕修改**——任何修改留补正痕迹、保留原值；
3. **属地字段贯穿**——每个老人档案必带**参保地**，全链路据此取目录与规则。

### 3.2 状态机（三个核心对象）

**① 老人档案 · 待遇状态（十态）**

> **⭐ 2026-10-12 修订（R2·质疑回填）**：原七态，**新增三类真实业务态**——`待起付/等待期`、`复评等待期`、`跨统筹区转移中`，并把 `住院暂停` 补上"恢复"出路。**每一态都必须明确三件事：能否派单 / 能否计费 / 如何恢复**（见下表末三列），避免"状态定义不清 ⇒ 误拦正常业务"。

| 状态 | 触发 | 系统动作（硬锁） | 可否派单 | 可否计费 | 如何恢复 |
|---|---|---|:---:|:---:|---|
| **待建档** | 签约后未建档 | 提醒倒计时（签约后 1 个月内）；超期标红 | ❌ | ❌ | 建档完成 ⇒ 转 `正常享受` |
| **待起付（等待期/垫付期）** | 待遇已受理、**6 个月等待期未满** | **允许录服务（进"垫付期服务台账"）、不计费**（见 §5.5.1 B1-A） | ✅ | ❌ | 等待期满、待遇生效 ⇒ **勾选"结转"** 转 `正常享受`（原垫付记录保留） |
| **正常享受** | 待遇有效期内 | 允许建档、计划、派单、服务 | ✅ | ✅ | — |
| **住院暂停** | 老人住院 | ⚠️ **L1 生效：不可新增服务、不可计费**；已有服务保留 | ❌ | ❌ | **出院后人工确认 ⇒ 走"恢复"流程**，校验待遇仍有效 ⇒ 转 `正常享受` |
| **复评等待期** | 待遇到期、**复评结论未出** | 停止新增服务；**保留已有记录、提示续评进度** | ❌ | ❌ | 复评结论出 ⇒ 按新等级转 `正常享受` 或 `已终止` |
| **跨统筹区转移中** | 老人**参保地变更**（如昆明→玉溪） | **冻结派单**；触发**目录切换预览**（旧 45 项 → 新属地目录）；历史记录**全保留** | ❌ | ❌ | 新参保地确认 ⇒ **重载属地目录** + 重制服务计划 ⇒ 转 `正常享受`（旧记录只读留档） |
| **死亡** | 老人去世 | 终止一切服务流程；档案转存档 | ❌ | ❌ | 不可恢复 |
| **长期异地居住** | 迁居外地 | 暂停服务 | ❌ | ❌ | 回迁 ⇒ 人工确认 ⇒ `正常享受` |
| **待遇到期** | 待遇有效期届满 | 停止新增服务；提示续评 | ❌ | ❌ | 续评通过 ⇒ `正常享受`；未续 ⇒ `已终止` |
| **已终止** | 协议终止 | 只读归档 | ❌ | ❌ | 不可恢复 |

> **⚠️ 状态变更靠人工维护（本期）**：**首期不做医保状态自动同步**（省级接口规范未发布）。系统**只能"提醒该核状态＋录后拦派单"，不能替代机构发现状态变化**。此条必须写进对客边界说明。**上表"如何恢复"均为"人工确认后系统放行"，不是系统自动发现。**

> **⭐⭐ 关于"等待期/垫付期"的设计要点（2026-10-12 新增）**：
> - **为什么要这个态**：长护险有 **6 个月等待期**，机构常在等待期内先垫钱上门。**这段时间的服务"录得进、留得住痕、但不计费"**——若不给状态而一律按"无有效待遇"拦（L1），等于把最需要凭证的一段变成纸面空白。
> - **与 L1 的关系**：L1（`1001` 无有效待遇不可服务）**只拦"要计费的在享服务"**；`待起付` 态走**独立形态的垫付台账**，**不被误拦**。
> - **不自动转正**：等待期满**不自动**把垫付记录转为正式记录（计费规则不同，自动转＝埋合规雷）；改由机构**勾选 + 一键结转**（见 §5.5.1 B1-A）。

**② 工单状态（八态）**

| 状态 | 说明 | 可否编辑 |
|---|---|---|
| **待派单** | 计划已生成工单，未指定护理员 | ✅ |
| **已派单** | 已指定护理员 | ✅ 可调整（调单） |
| **服务中** | 护理员已签到 | ❌ |
| **已完成** | 已签退并留痕 | ❌（仅补正） |
| **异常** | 服务中上报异常 | ❌ |
| **已取消** | 请假/轮岗等取消 | ❌（留取消原因） |
| **逾期未做** | 过了服务时段仍无记录 | ❌（进风险预警） |
| **未遇（扑空）** | **已到访但未能服务**（老人不在家/拒绝服务/临时改期） | ❌（**到访时间＋定位＋原因必留**，见 §4.9.1） |

> **⭐ 2026-10-12 新增「未遇（扑空）」态**：原口径下"白跑一趟"只能靠**口头说明**，**无佐证 ⇒ 巡查看作"空单废单"**，有被判"虚假服务"的风险。新增此态后，**"到了、没人、怎么处理"三件事都留痕**，把"白跑"从"说不清"变成"有据可查"。**它是异常上报的一个专门子类，不是新流程。**

**③ 留痕与质控状态**

| 状态 | 说明 |
|---|---|
| **草稿** | 服务中未提交（离线也在此状态） |
| **已提交** | 护理员签退提交 |
| **待质控** | 进入质控队列 |
| **已放行** | 质控通过 → 进上报池〔二期〕 |
| **已退回** | 质控退回，护理员可补正 |
| **已上报** | 〔二期〕 |

### 3.3 六条硬锁（本期实现口径，含降级说明）

| # | 硬锁 | 本期实现 | 说明 |
|---|---|---|---|
| **L1** | 无有效待遇 → 不能建档/服务 | ✅ **点不动** | 状态人工维护，系统不感知变化。**⚠️ 例外：`待起付（等待期）` 态允许服务，但走垫付台账、不计费**（见 §3.2、§5.5.1 B1-A） |
| **L2** | 无服务计划 → 不能生成工单 | ✅ **点不动** | — |
| **L3** | 无有效工单 → 不能录入留痕 | ✅ **点不动** | — |
| **L4** | 无完整留痕 → 不能进上报池 | ✅ **点不动** | 上报池本身为二期 |
| **L5** | 无质控放行 → 不能上报 | ✅ 本期以"放行"为准 | 上报动作在二期 |
| **L6** | 无有效资质 → 不能派该项目的单 | ⚠️ **本期降级：人工登记＋派单提示** | **本期不做自动禁派**；二期升级为**自动拦截** |

> **⚠️ L6 的对客口径（必须逐字使用）**：
> **"『无资质不派单』是政策硬要求，但资质库在二期。首期处理方式是『人工登记＋派单时系统提示』，不是自动禁派。二期升级为自动拦截。"**
> **对客材料不得写"系统自动禁派"**——本期做不到。

**硬锁的设计纪律**：
1. **"点不动"优先于"弹提醒"**；
2. **只锁政策明文要求的 6 条**——日常照护记录方式**一律宽松**；
3. **锁的位置要"最早"**——在流程起点拦，不在终点拦；
4. **拦截必须给"怎么解"**——不能只说"不能做"，要说"先做什么才能做"（接口的 `hint` 字段）。

### 3.4 角色与权限

**角色定义**

| 角色 | 谁 | 主要场景 |
|---|---|---|
| **护理员** | 一线服务人员 | 手机 APP：看任务、干活、留痕 |
| **组长 / 主管** | 排班与派单负责人 | 后台：排班、派单、调单 |
| **质控员** | 服务质量把关人 | 后台：建档、计划、审核、异常处理 |
| **院长** | 机构负责人 | 后台：查看（**本期无看板，只见列表**） |
| **家属** | 老人家属 | 公众号：查看、可选确认 |
| **机构管理员** | 系统配置人 | 后台：机构信息、账号权限、属地配置 |

**权限矩阵（五角色 × 本期操作）**

| 操作 | 护理员 | 组长 | 质控员 | 院长 | 家属 |
|---|:---:|:---:|:---:|:---:|:---:|
| 查看今日任务 | ✅ 自己 | ✅ 本组 | ✅ 全部 | ✅ 全部 | — |
| 签到／签退／录服务 | ✅ | ✅ | — | — | — |
| 上报服务异常 | ✅ | ✅ | ✅ | — | ✅ 可反馈 |
| 老人建档 | — | — | ✅ | — | — |
| 制定/变更服务计划 | — | ✅ | ✅ | — | — |
| 排班派单／调单 | — | ✅ 本组 | ✅ 全部 | — | — |
| 质控审核／放行 | — | ✅ 本组 | ✅ 全部 | — | — |
| 机构项目库配价 | — | — | ✅ | — | — |
| 查看服务记录 | 自己 | 本组 | 全部 | 全部 | **仅自家老人** |
| 人员资质维护 | — | — | 〔二期〕 | — | — |
| 结算申报／对账 | — | — | 〔二期〕 | 〔二期〕 | — |
| 经营看板 | — | 〔二期〕 | 〔二期〕 | 〔二期〕 | — |

**三条权限原则（写死）**：
1. **最小必要**——护理员只能看/操作**派给自己的任务**；
2. **家属只见自家、默认只读**；
3. **院长不改数据**——院长**不设任何数据修改权限**（后端在所有写接口上一律返回 403）。

> **⚠️ 第 3 条的修正（详见下方补充 2）**：上述"院长写接口 403"**修正为"仅当账号只持 `director` 时 403"**；**若同时持 `qc`／`leader`／`admin`，按角色并集放行**。**"院长不改数据"的本意是"不许凭身份直接改记录"，不是"院长永远不能写"**——院长要能配账号（`admin`）、兼质控时审记录（`qc`）。两处必须一起读。

#### 3.4.1 角色补充说明（四条，开发按此实现，不得自行发挥）

> **为什么单列这一节**：上面那张矩阵是"业务操作视角"，开发照着做还差四件事没说清——**机构管理员归谁管、一个人能不能兼多个角色、敏感字段谁能看、什么叫"本组"**。这四条**逐条定死**，不留解释空间。

---

**补充 1｜机构管理员（`admin`）的归属与权限**

| 项 | 规定 |
|---|---|
| **它是不是一个独立岗位** | **不是**。它是**"系统配置权限"**，不是业务角色 |
| **本期由谁担任** | **本期默认由院长（`director`）兼任**——即院长账号同时持有 `director` + `admin` 两个角色（见补充 2） |
| **它能做什么** | 后台：**机构信息维护、账号新增/停用、角色分配、属地配置**（＝B8 系统设置全部） |
| **它不能做什么** | **不得触碰任何业务数据**（不建档、不定计划、不派单、不审记录）——**配置权与业务权分离**，防止"改配置绕过硬锁" |
| **单人机构怎么办** | 若机构只有一人（个体护理人员），**该账号可同时持 `admin` + `qc`**；**但其自身录入的业务记录仍须由他人质控**（见补充 2 末尾例外条） |

> **⚠️ 落地纪律**：`admin` **只在后台"系统设置"菜单可见**；持 `admin` 但未持 `qc`／`leader` 的账号，**登录后看不到 B1–B4 业务菜单**。

---

**补充 2｜一人多角色规则（小机构必需）**

| 项 | 规定 |
|---|---|
| **能不能一人多角色** | **能**。**小机构"院长兼质控""组长兼质控"是常态**，不允许多角色＝系统用不起来 |
| **数据怎么存** | `user.role` **改为可存多值**：**逗号分隔字符串**（如 `director,admin`／`leader,qc`）；**字段长度 varchar(50)**（足够 5 个角色） |
| **权限怎么算** | **取并集**——某人持多个角色，则**拥有各角色权限的合并**（如"组长+质控"＝能派单**且**能审记录） |
| **切换角色？** | **不做**。按当前账号**全部角色**计算，**本期不做角色切换器**（避免复杂） |
| **⚠️ 唯一例外（重要）** | **禁止"自审自放行"**：**同一账号录入的服务记录，不得由该账号自己质控放行**——系统须校验 `record.created_by ≠ qc.operator_id`，否则返回 **`4001`**。<br>**为什么**：这是**"先质控再上报"铁律**的底线，**不因"小机构人手少"而放宽**；机构若只有一人，**必须再配一个能审的人**（哪怕兼职），否则**该记录无法进上报池** |
| **院长兼质控时，写接口还 403 吗** | **不返回**。按**角色并集判权，不按"院长"身份一刀切** |

---

**补充 3｜字段级权限（敏感信息谁能看）**

> 矩阵只到"操作级"（能不能建档），但**同一张档案里不同字段敏感度不同**。以下**三个字段**必须做**字段级控制**：

| 字段 | 所属表 | 谁能看 | 规则 |
|---|---|---|---|
| **身份证号** `id_card_no` | `staff`／`elder` | **仅 `admin` 与 `qc`** | 列表页**一律掩码**（如 `5301**********1234`）；**点"查看完整"才明文**，且**每次查看留痕**（谁、何时、看了谁的） |
| **手机号** `phone` | `staff`／`elder` | **`admin`／`qc`／`leader`（仅本组）** | 护理员端**只显示"姓氏+称呼"**，**不显示任何手机号**；家属端**一律不返回护理员手机号**（走机构统一联系） |
| **服务照片** `record_photo` | 留痕 | **`qc`／`leader`（本组）／护理员看自己**；**`director` 可看** | **家属端本期一律不展示**（`visible_to_family` 恒 0） |

> **⚠️ 两条落地纪律**：
> ① **掩码在服务端做，不在前端做**——前端掩码＝明文已下发到浏览器，等于没掩码；
> ② **明文查看必须留痕**（写操作日志表）——对应巡查表·信息管理第 4 条"数据不出机构、访问可追溯"。

---

**补充 4｜"本组"的定义（组织架构）**

| 项 | 规定 |
|---|---|
| **"本组"指什么** | **一个"护理组"**＝**1 名组长 + N 名护理员**，是**派单与质控的最小单位** |
| **本期怎么建组** | **不单独建"组"表**。**改为**：`staff` 表增加字段 **`group_leader_id`**（该护理员归属的组长），**由 `admin` 在人员管理里指定** |
| **组长看 "本组" 怎么算** | 组长登录 → **查 `staff` 表中 `group_leader_id = 本人 staff_id` 的护理员** → **只看这些人的任务与记录** |
| **质控员看 "全部"** | `qc` **不受组限制**，**看本机构全部** |
| **组长兼质控** | 按**权限并集**——**既是本组组长（管本组派单），又是质控员（审全部记录）** |
| **没有组长的机构** | **允许为空**——若机构不分组，护理员 `group_leader_id` **留空**，此时**只有 `qc`／`admin` 看全部**；**`leader` 看不到任何人**（提示"您尚未被指派组员，请联系管理员"） |

> **⭐ 为什么用 `group_leader_id` 而不建"组表"**：**本期是单机构、组数少、结构简单**，一个外键字段就够；**建组表＝多一张表、多一套增删改查界面**，**本期不值当**。二期若做"多机构/连锁"（P2），**再升级为独立组织架构模块**——**迁移路径已留**（把 `group_leader_id` 升格为 `group` 表 + 关系表即可，不影响已有数据）。

---

**补充小节汇总（开发速查）**

| # | 事项 | 一句话结论 |
|:---:|---|---|
| 1 | 机构管理员归谁 | **不是独立岗位**，本期由**院长兼任**；只管配置、不碰业务 |
| 2 | 一人多角色 | **允许**，`user.role` 存多值、**权限取并集**；**唯一禁止"自审自放行"**（`4001`） |
| 3 | 字段级权限 | **身份证仅 admin/qc 明文可见且留痕**；**手机号与照片按端控制**；**掩码在服务端做** |
| 4 | "本组"定义 | **1 组长 + N 护理员**；**用 `staff.group_leader_id` 实现，不建组表** |



---

## 四、护理员移动端 APP（P0 主战场：③履约留痕）

> **形态**：**独立 APP**（安卓为主），**我方统一上架**。
> **一句话设计目标**：**让一个 50 岁上下、不擅长智能手机的护理员，在老人家里、可能没网的情况下，不学就会、不误操作地完成一次服务记录。**

### 4.1 用户画像（**有据可查，非臆测**）

| 项 | 数据 | 来源 |
|---|---|---|
| 年龄 | **40–59 岁占 83.25%**，30 岁以下仅 2% | 《2025 养老护理员职业现状调研报告》 |
| 学历 | 初中及以下 **56.13%** | 《2024 报告》 |
| 性别 | 女性 **89.25%** | 《2025 报告》 |
| 使用障碍 | 中老年 **82.9% 有使用障碍、仅 24.44% 能独立操作** | CNNIC 第 56 次报告 |
| 官方自陈 | 昆明医保局承认护理员"**年龄偏大、智能设备操作困难**" | 昆明市医保局公开材料 |

**⇒ 设计含义**：**这个群体"学不会"不是态度问题，是能力现实**。任何需要"培训才会用"的设计，都是失败的设计。

**三条不可协商的原则**：
1. **不为留痕而留痕**——记录必须对护理员**自己也**有用；
2. **不是增加一个系统，是减少她要开的**——替代纸质本、微信群汇报；
3. **不许比现在更慢**——比现有习惯慢的操作，两周内会被绕过。

### 4.2 页面地图（5 个页面，不再多）

| 序 | 页面 | 一句话职责 | 进入方式 |
|:---:|---|---|---|
| **M1** | **今日任务**（首页） | 今天去哪几家、几点、做什么 | 打开 APP 直接进 |
| **M2** | **服务执行** | 签到 →（干活）→ 签退，勾项目 | 点 M1 的卡片进入 |
| **M3** | **异常上报** | 一键上报压疮/呛咳/跌倒等 | M2 内入口＋M1 底部 |
| **M4** | **任务详情** | 老人情况、服务计划、注意事项 | M1 卡片长按/侧滑 |
| **M5** | **我的** | 我的工时、我的消息、我的资质 | 底部第二栏 |

> **⚠️ 刻意不做**：统计报表、排班管理、对话聊天、打字录入、消息广场、积分排名。
> **底部导航只有两栏**：📋 任务（默认）／👤 我的。**不做第三栏。**

### 4.3 M1 今日任务（首页）

```
┌───────────────────────────────────────┐
│  今天 10月11日 周六          [王大娘]  │  ← 顶部：日期 + 我的名字（大字）
├───────────────────────────────────────┤
│  ┌─────────────────────────────────┐  │
│  │ ⏰ 09:00  李奶奶家               │  │  ← 任务卡片（大卡）
│  │ 翻身 · 喂饭 · 口腔清洁           │  │  ← 项目摘要（最多 3 项 + 等 N 项）
│  │ 预计 60 分钟          [ 开始 ]  │  │  ← 大按钮
│  └─────────────────────────────────┘  │
│  ┌─────────────────────────────────┐  │
│  │ ⏰ 11:00  张爷爷家      ✅已完成 │  │  ← 已完成卡片（灰底）
│  └─────────────────────────────────┘  │
│  ┌─────────────────────────────────┐  │
│  │ ⏰ 14:30  赵奶奶家               │  │
│  └─────────────────────────────────┘  │
│  今天 3 家 · 已完成 1 家               │  ← 底部汇总（小字）
└───────────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **日期行** | 大字；**当天**，不显示其他日期（不做日历） |
| **任务卡片** | 按**时间顺序**排列；**待办在前、已完成沉底** |
| **卡片三要素** | **时间**（大字）＋ **老人称呼**（大字）＋ **项目摘要**（最多 3 项，多的显示"等 N 项"） |
| **状态分色** | 待办＝白底；已完成＝灰底＋✅；**异常＝橙底**；**逾期未做＝橙红底** |
| **主按钮** | **[开始]** —— 唯一的大按钮，**点击即进入 M2** |
| **已完成卡片** | 不可点进 M2（防重复提交）；点进 M4 可看记录 |
| **底部汇总** | "今天 N 家 · 已完成 M 家"，**小字、不可点** |

**关键交互规则**

| 场景 | 规则 |
|---|---|
| **老人住院中** | 卡片**置灰并显示"住院中·暂停服务"**，**[开始] 按钮不可点**（L1 硬锁） |
| **待遇已到期** | 同上，显示"待遇已到期·请联系机构" |
| **无任务** | 显示大图＋"今天没有任务，好好休息"（**不给空白页**） |
| **逾期未做** | 卡片转橙红＋顶部条提示（**不是责怪语气**，写"这单还没记录，别忘了"） |

> **⭐ 住院状态显示（已定：显示）**：护理员上门前就知道**别白跑一趟**。**⚠️ 前提**：状态靠**机构人工维护**（本期无接口自动同步），所以提示语**不说"系统检测到住院"**，只说"**住院中·暂停服务**"（事实陈述）。

### 4.4 M2 服务执行（核心页面）

> **目标：≤4 次点击完成一次服务记录，不打一个字，没网也能做。**

**点击路径（严格 ≤4 击）**

```
① 点【开始】（M1）
        ↓
② 【签到】  ← 自动定位＋时间，无需输入
        ↓
   （干活）
        ↓
③ 【勾选服务项目】← 项目已按计划预勾，她只需"取消没做的"
        ↓
④ 【签退】  ← 自动计算时长
        ↓
   完成（自动提交或进离线队列）
──────────────────────────────
合计：4 击
```

> **⭐ 关键设计**：**项目默认全部预勾选**。护理员只需"**取消没做的那一项**"。
> **理由**：计划内项目**绝大多数都会做到**。默认全勾＝她多数情况直接点签退（**实际 2 击**）。**这是把"4 击"进一步降成"常态 3 击"的关键。**

**页面布局（三段式，不跳页）**

```
┌───────────────────────────────────────┐
│  ← 李奶奶家 · 翻身·喂饭·口腔清洁        │
├───────────────────────────────────────┤
│         ┌───────────────┐             │
│         │   [ 签 到 ]   │             │  ← ① 签到区（超大按钮）
│         │  09:02 已定位  │             │
│         └───────────────┘             │
├───────────────────────────────────────┤
│  本次服务项目（已按计划预选）            │  ← ② 项目区
│  ☑ 协助翻身叩背排痰        📷 需拍照   │  ← 必拍档：显式标 📷
│  ☑ 协助进食/水及指导                   │
│  ☑ 口腔清洁                            │
│  ☐ 生命体征测量（本次未做）             │  ← 她取消勾选的
│  ＋ 临时加项                            │  ← 少用入口
├───────────────────────────────────────┤
│      ┌─────────────────────┐          │
│      │    [ 签  退 ]       │          │  ← ③ 签退区
│      │  已完成 · 58 分钟    │          │
│      └─────────────────────┘          │
└───────────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **签到** | **一键**；自动记录**时间＋定位**（定位失败不阻塞，标"未获取"）；**不允许手工改时间** |
| **项目清单** | 来源＝服务计划；**默认全勾**；顺序＝计划顺序 |
| **取消勾选** | 点一下即取消；**取消必拍档会提示** |
| **签退** | **一键**；自动算时长；**不填任何文字** |
| **时长** | 系统自动计算；不设最低时长强制（**提示但不拦**） |
| **提交** | 有网＝自动提交；无网＝**进离线队列，界面无差别** |

### 4.5 ⭐ 拍照分档规则（本期核心设计）

| 档 | 适用项目 | 记录方式 | 系统行为 |
|---|---|---|---|
| **必拍档** | **沐浴、转移（搬抬类）、导管类（导尿/置管/深静脉置管/气管切开）、鼻饲/喂食（协助进食/水含管饲）、压疮护理** | **强制拍照 ＋ 结构化标签**（压疮专项） | **未拍照 → [签退] 按钮不可点**，提示"这项需要拍一张照片" |
| **免拍档** | **翻身、喂饭、陪伴聊天、剪指甲、整理床铺、口腔清洁、协助更衣等日常项** | **语音描述 ＋ 家属可选确认** | 不要求拍照；**默认不弹语音**，她可主动录 |
| **可拍档** | **擦身（擦浴）、协助如厕、失禁照护** | 默认免拍，**出现异常才要求补拍** | 异常上报时引导补拍 |

> **⭐ 压疮护理：已定"加"，实现方式＝"照片＋结构化标签"（2026-10-11 定）**
>
> **为什么加**：①**国家 36 项目录里本就有独立项**「压疮预防照护及指导」（`L0000106020010000`）；②**压疮是唯一"照片几乎无法替代"的项目**——严重程度与进展只能靠前后对比图；③**出事时没有照片，机构无法自证不是自己造成的** ⇒ **这一项加的其实是机构的免责能力**。
>
> **⚠️ 不能做成"多一项必拍"**（那等于又给一线加活）。正确做法＝**拍照后附结构化标签**：

| 步骤 | 交互 | 说明 |
|:---:|---|---|
| 1 | 拍照 | 与既有必拍流程一致 |
| 2 | **点选部位** | 9 个常见部位：骶尾部／足跟／髋部／坐骨结节／肩胛部／枕部／耳廓／踝部／其他 |
| 3 | **点选分期** | 1 期／2 期／3 期／4 期／不可分期／深部组织损伤（**采用临床指南标准分期，不自行发明**） |
| 4 | （可选）备注 | 一句话描述，可跳过 |

> **为什么必须结构化**：**照片只能看，数据才能用**——有了部位＋分期，质控端可做"同一部位持续未愈合"预警、导出文书可直接填"压疮情况"栏。**纯照片做不到这两件事。**
> **⚠️ 纪律**：结构化标签**全部为点选，不打字**；**标签可跳过不填**（只强制拍照，不强制标签）。

**三条设计纪律（写死）**：

1. **免拍 ≠ 不留痕**——免拍项仍自动记录**四要素**：签到时间、服务时长、项目清单、语音描述（如有）。**四要素齐全即算留痕**；
2. **分档可配置**——机构可按自身风险偏好**调整哪些项必拍**。默认按上表，**机构可加严、不建议放宽**；
3. **照片不为"好看"**——**不要求老人摆姿势、不要求面对镜头**。**APP 内不得出现任何"请正面拍摄""请露出老人面部"之类提示**。

> **⚠️ 分档默认值的来源与纪律（2026-10-12 新增，S5 回填）**：**上表分档是我方"建议默认值"，不是医保规定值。** 签约/上线前**必须与当地医保/服务规范逐项核对后确认**（列入《签约前必办清单》）。**理由**：属地巡查对"哪些项须留照片"的口径不完全一致——**把它做成"可配置"是为了改得动，把它"明示出来"才是消除风险**。**不得用"可配置"三个字把这项风险藏起来。**

### 4.5.1 ⭐ 拒拍/无法拍摄的出路（2026-10-12 新增，Q13 回填）

> **要解决的真问题**：必拍项**只有"拍"这一条路**时——老人/家属坚决不让拍，护理员**要么强行拍（挨投诉）**，**要么放弃签退（活干不下去）**。**两条路对一线都是死路。** 必须给**第三条路**。

| 元素 | 规则 |
|---|---|
| **入口** | 必拍项拍照区下方**小字**：【无法拍摄？】 |
| **点击后** | 弹**原因点选**（不打字，4 选 1）：①老人/家属拒绝 ②老人状态不宜拍（如已休息/情绪激动） ③设备故障／无拍摄条件 ④其他 |
| **选完** | **可直接签退**（解除 `3001` 拦截）；该记录打 `is_refused_photo=1`＋原因 |
| **标记后果** | 质控端**显著标出"未拍（原因）"**，进**质控重点关注**；**不视为违规**（这是"如实说明"，不是"漏做"） |
| **留痕** | 拒拍动作本身**记入操作日志**，与补正记录同源可查 |

> **⭐ 设计要点**：**让"没拍"本身变成一个"有痕的证据"**——比"逼她拍"或"让她拍不了就走不掉"都强。**注意**：`is_refused_photo=1` **不等于免责**，只是**把"为什么没拍"说清楚**；是否认账由医保/机构判定。
> **与 §4.9 异常上报的区别**：异常上报是"**发现了问题**"（压疮/呛咳）；拒拍登记是"**该拍的没拍成**"。**两件事，两个入口，不混。**

### 4.5.2 拍照分档的"属地核对清单"（S5·签约前必办）

| 步 | 动作 | 产出 |
|:---:|---|---|
| 1 | 取当地（统筹区）巡查/服务规范原文 | 一份可引用的官方件 |
| 2 | 逐项比对"哪些项须留照片" vs 上表默认分档 | 差异清单 |
| 3 | 差异项在**机构配置层**调整（不改代码） | 配置值 |
| 4 | 写入签约/上线确认单，双方签字 | 存证 |

> **登记落点**：`20261012-签约前必办清单`（含拍照分档核对项）。**未完成此核对，不得对外宣称"拍照分档已符合当地要求"。**

> **⭐ 责任划法（R-3 补，2026-10-12）**：
> - **我方＝供"建议值"**（上表默认分档）；**机构＝"核对确认"**（逐项比对、签字）。
> - **核对遗漏的责任，以签约前《属地核对确认单》签收为界**——签字前发现的差异＝协作核对范畴；签字后属地要求变化的＝新的适用要求，另行处理。
> - **交付要求**：**首次交付即支持"分档批量改"**（整批调整，非逐项手调），列入 **P-5 验收**。

### 4.6 临时加项（少用但必须有）

| 项 | 规则 |
|---|---|
| 入口 | 项目区底部 **[＋ 临时加项]**（**小字、不显眼**） |
| 如何选 | **只能从属地目录里选**（不能自由输入）——保障"不得自创项目" |
| 记录 | 加项**单独标记**，质控端显示"计划外加项" |
| 提示 | 选完提示"计划外项目已记录，机构会看到"（**告知，不是警告**） |

> **为什么必须有**：护理员现场发现老人需要额外照护，**如果没有入口，她会口头说、然后不记录**——这正是"**发现了没进系统**"的断链点。

### 4.7 时长提示（不强制）

| 情况 | 系统行为 |
|---|---|
| 时长 ≥ 计划时长的 70% | 正常，无提示 |
| 时长 < 计划时长的 70% | **提示**"本次用时较短，确认要签退吗？"——**可继续**，不拦 |
| 时长 < 5 分钟 | 提示"用时很短，是否误操作？"——**可继续**，但质控端标黄 |

> **⚠️ 两条纪律**：①**不设最低时长硬拦**（硬拦会逼护理员"耗时间"或"造假"）；②**提示不能带责怪语气**——写"确认要签退吗"，**不写"服务时长不足"**。
>
> **⭐ 补充基线（2026-10-11）**：国家目录官方电子版**逐项给了「推荐服务时长」**（沐浴 30–60 分钟、常规换药 20–30 分钟、快速血糖 3–5 分钟…）。已提取全 36 项，见
> `20261011-服务时长参考基线（源自官方电子版）.md`。**建议二期或本期末**把它接入为**项目级**时长基线（现表为"计划时长百分比"通用口径，不涉具体项目）。
> **接入时的红线不变**：仍为**提示级＋标签级，不拦截、不扣分**；措辞用"推荐时长"，**不得**写成"标准时长/规定时长"。

### 4.8 离线逻辑（关键）

| 场景 | 行为 |
|---|---|
| 完全无网 | **签到/勾选/签退全部可用**；数据进本地队列；**界面无任何"网络异常"红字** |
| 弱网（有信号但慢） | 同上；不弹"加载中" |
| 恢复联网 | **后台自动补传**；补传成功**不弹窗打扰**（只在"我的"里显示"已同步"） |
| 补传失败 | 重试 3 次 → "我的"里标"待同步"，**提示"回家连上 WIFI 就会自动传"** |
| 照片 | 本地压缩后存储（**避免占满手机**）；补传后**默认保留 7 天**再清理 |

> **⭐ 为什么这是硬指标**：老人家里（尤其老旧小区、城中村）**无网/弱网是常态**。**要求"必须联网才能记录"＝要求护理员在门口等信号**。

### 4.9 M3 异常上报

```
┌───────────────────────────────────────┐
│  ← 上报异常                            │
├───────────────────────────────────────┤
│  这是谁？（自动带入：李奶奶）            │  ← 自动，不用选
│  什么问题？（点选，可多选）              │  ← 九宫格大按钮
│  ┌──────┬──────┬──────┐               │
│  │ 压疮  │ 呛咳  │ 跌倒  │               │
│  ├──────┼──────┼──────┤               │
│  │ 发热  │ 皮肤破损│ 情绪异常│             │
│  ├──────┼──────┼──────┤               │
│  │ 进食困难│ 排泄异常│ 其他  │             │
│  └──────┴──────┴──────┘               │
│  【按住说话】 说一句就行                 │  ← 语音，非必填
│  📷 拍一张（可选）                      │
│        ┌──────────────────┐            │
│        │   提交上报        │            │
│        └──────────────────┘            │
└───────────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **对象** | **自动带入**（从当前任务），不需选择 |
| **问题分类** | **9 宫格点选**，**点击即选中**，可多选 |
| **语音说明** | **按住说话**；**非必填**；最长 60 秒；自动转文字（仅内部记录用） |
| **照片** | **可选**；不强制（**避免吓得不敢报**） |
| **提交** | 一键；**即时推送**给组长与质控员 |

> **⚠️ 关键取舍**：**异常上报"一切可选"（分类必选，其余可选）**——**异常上报的价值在于"报上来"，不在于"报得多详细"**。如果要求必填照片、必填描述，**护理员会选择不报**。

**提交后**：推送给组长＋质控员（APP 推送＋后台待办）；护理员侧显示"已上报，机构看到了"，**不留任务在 APP 里**；异常记录关联到该次留痕；**不影响计划**（改计划是质控员的事，**APP 不提供改计划功能**）。

### 4.9.1 ⭐ 未遇（扑空）专门形态（2026-10-12 新增，Q12 回填）

> **要解决的真问题**：护理员按时到了、**老人不在家 / 家属临时不让做 / 老人已住院**——原口径下**只能口头跟组长说**，**系统无佐证 ⇒ 巡查看作"空单废单"**，机构被判"虚假服务"的风险落在自己头上。

| 元素 | 规则 |
|---|---|
| **入口** | M2 服务执行页底部小字：【没见到老人？】 |
| **点击后** | 弹**原因点选**（不打字，4 选 1）：①老人/家属不在家 ②家属临时不同意服务 ③老人已住院/已送医 ④其他 |
| **随手可留** | **到访时间自动取**、**定位自动取**（证明"我确实来过"）；可语音补一句（非必填） |
| **结果** | 工单转 **`not_met`（未遇）**，**不是"已完成"、也不是"逾期未做"**；**不产生服务记录、不计费** |
| **推送** | 推给组长＋质控员，**组长可当场决定**：改期（生成新工单）或作废（留原因） |

> **⭐ 与"异常上报"的关系**：**扑空是"异常上报"下的一个专门子类，复用同一套推送与留痕机制，不是新流程**（避免另起一套把 APP 做重）。
> **与"逾期未做"的区别**：**逾期未做＝到点没记录**（可能压根没去）；**未遇＝去了、有到访时间与定位、但没做成**。**两者性质完全不同，必须分开——这正是"空单废单"能被说清的关键。**

### 4.10 M4 任务详情（只读）

| 区块 | 内容 |
|---|---|
| **老人基本信息** | 称呼、性别、年龄（**不显示身份证号等敏感信息**） |
| **本次服务计划** | 项目清单、频次、预计时长 |
| **⚠️ 注意事项** | **醒目区块**：过敏史、吞咽障碍、压疮位置、禁食要求等 |
| **上次服务** | 时间＋项目（**帮她想起来上次做到哪**） |
| **家属联系人** | 一键拨号（**走隐私号**，不显示真实号码） |

**权限**：**纯只读**——**不得在此页修改任何内容**（防误改）。

> **⭐ 注意事项区块的填写来源**：**这一块是"该加的专项漏加"的防线**。内容由**质控员在制定服务计划时填写**，**护理员只读**。例：老人有吞咽障碍 → 写"**进食需慢、小口、坐起 90 度，出现呛咳立即停止**"。**这比"系统提示加项"更直接有效**——因为它告诉护理员"怎么做"，不只是"要做什么"。

### 4.11 M5 我的

| 区块 | 内容 | 说明 |
|---|---|---|
| **我的工时** | 本月服务次数、总时长 | **不显示金额**（本期无结算） |
| **我的消息** | 机构通知、异常反馈 | 系统通知＋机构群发 |
| **我的资质** | 资质类型、有效期 | **本期人工登记展示**；〔二期〕做到期提醒 |
| **同步状态** | "已同步 / N 条待同步" | **离线补传的可见出口** |
| **设置** | 字号调节、退出登录 | **字号可再放大**（照顾老花） |

> **⚠️ 不做**：不做积分、不做排名、不做"服务之星"——**评比会诱发造假**。

### 4.12 APP 已定事项

| # | 事项 | 定论 |
|:---:|---|---|
| 1 | **必拍档是否加"压疮护理"** | ✅ **已定：加**。实现＝**照片 ＋ 结构化标签**（部位 9 选项 ＋ 分期 6 选项，均可跳过）。详见 §4.5 |
| 2 | **APP 名称与图标** | ✅ **开发期占位名"投云长护"**；图标用**青蓝色板＋简洁图形**（不用人脸、不用心形）。**上架前再定终名**（改名成本极低） |

> **⚠️ APP 名的一个前置问题（上架前必须想清）**：公司与品牌是两套——**公司＝云南投云科技有限公司、品牌＝滇云守护**。**APP 叫"投云长护"还是"滇云守护"，本质是回答"这个 APP 是公司产品线的一员，还是品牌下的一个端口"。** 本期不影响开发。

---

## 五、机构管理后台（①②④ ＋ 文书/设置）

> **本期只做 B1–B4 ＋ B7/B8 精简版**；**B0 院长看板、B5 结算对账、B6 人员资质为二期，本期不在导航中出现**。
> **一句话设计目标**：**让组长"调单比微信群快"，让质控员"日常做完就是合规记录"，不用天天补台账。**

### 5.1 主导航（登录后，只有 6 项）

```
投云长护 · 机构后台
┌──────────────────────────────────────┐
│  服务对象  排班派单  工单留痕  质控中心  │  ← 4 个主功能
│  文书档案  系统设置                     │  ← 2 个辅助
└──────────────────────────────────────┘
```

| 序 | 导航项 | 分期 | 谁用 |
|:---:|---|:---:|---|
| 1 | **服务对象**（B1） | **本期** | 质控员 |
| 2 | **排班派单**（B2） | **本期** | 组长 |
| 3 | **工单留痕**（B3） | **本期** | 质控员/院长 |
| 4 | **质控中心**（B4） | **本期** | 质控员 |
| 5 | **文书档案**（B7 精简版） | **本期** | 质控员 |
| 6 | **系统设置**（B8 精简版） | **本期** | 机构管理员 |

> **⚠️ 本期不出现的导航项**：**院长看板（B0）／结算对账（B5）／人员资质（B6）**。
> **对客口径**：**"首期就做了这几块，余下二期上"**——**不承诺菜单**。**不做"导航都在、点进去没数据"**。

**登录后落在哪（已定）**：**直接落"服务对象"列表页（B1），不做看板首页**。理由：本期机构日常最常进的就是"找人"。

**⭐ 登录页的属地信息（多属地提示）**

```
┌──────────────────────────────┐
│   投云长护 · 机构后台          │
│   机构：XX 养老服务中心        │
│   属地：昆明市                │  ← 显示参保地
│   目录：昆明市 45 项           │  ← 显示加载了哪套目录
│   [ 账号 ]  [ 密码 ]  [ 登录 ] │
└──────────────────────────────┘
```

> **⭐ 为什么显示"属地"和"目录"**：①让机构**知道自己在哪套规则下**；②**这是多属地能力的可视化**——**对客演示时，这一行就是卖点**；③**属地不可自助修改**（改属地＝重新签约）。

### 5.2 B1 服务对象

```
┌────────────────────────────────────────────────────────────┐
│ 服务对象                     [+ 新建老人档案]  [搜索]        │
├────────────────────────────────────────────────────────────┤
│ [全部] [正常享受] [住院暂停] [待建档] [待遇到期]  ← 状态筛选   │
├────────────────────────────────────────────────────────────┤
│ 姓名     护理等级   状态       计划    下次服务    操作      │
│ 李奶奶   一级(最高)  正常享受   ✓已制定  10-11 09:00  查看   │
│ 张爷爷   二级       住院暂停   ✓已制定  —（暂停）     查看   │
│ 赵奶奶   三级       ⚠️待建档   —        —          建档   │
│ 王大爷   一级(最高)  待遇到期   ✓已制定  —（暂停）     查看   │
└────────────────────────────────────────────────────────────┘
```

| 字段 | 规则 |
|---|---|
| **姓名** | 显示老人称呼（**不显示身份证号**，点进详情才可见且需权限） |
| **护理等级** | **必须带"（最高级）"标注在一级后** |
| **状态** | 5 色标签：正常（绿）／住院暂停（橙）／待建档（黄）／待遇到期（橙红）／已终止（灰） |
| **计划** | 显示"✓已制定"或"—"；**未制定的标黄并显示倒计时** |

**⭐ 建档（含法定时限倒计时）**

| 项 | 规则 |
|---|---|
| **建档时限** | **签约后 1 个月内**（政策要求）；顶部显示 **"距建档截止还有 N 天"**，超期标红 |
| **必填** | 称呼、性别、年龄、参保地、护理等级、待遇有效期、家属联系人 |
| **注意事项区块** | ⚠️ **醒目区块**：过敏史、吞咽障碍、压疮位置、禁食要求等——**这是 APP 端 M4 的数据来源** |
| **属地字段** | 参保地**自动取机构属地**（跨属地老人需手工选，并提示规则差异） |
| **敏感信息** | 身份证号等**加密存储、按权限查看、访问留痕** |
| **参保核验（第 1 步·前置）** | 建档前先核参保：凭**身份证号＋医保参保号**核对参保状态、参保类别（职工/居民）。**本期无医保接口，不做在线核验**——核验以机构线下确认为准、结果记备注留痕；接口发布后升级为在线核验（入站接口预留） |
| **录入方式（降负担）** | 身份证 **OCR 拍照自动回填**（回填后仍走 18 位＋校验位校验，OCR 只是省打字不替代校验）；出生日期由身份证带出；地址＝**行政区划级联选择＋门牌文字/语音**；全表**语音双通道兜底** |
| **评估结论承载（等级唯一来源）** | 失能等级**只能来自评估结论**：A 路径＝**拍照上传评估结论副本（系统自动打水印＋时间戳）**；B 路径＝官方接口拉取〔接口发布后〕。**禁止**建档人自行"勾选/填写"出等级；**无结论佐证的档案不能转"正常享受"** |

> **⚠️ 建档时限来源**：昆医保通〔2025〕27 号第三十四条"建立服务实名制档案，**1 个月内**"。

**服务计划（建档后第二步）**

| 项 | 规则 |
|---|---|
| **计划时限** | **签约后 5 个工作日内**制定（政策要求）；页面显示倒计时 |
| **计划内容** | 服务项目（**从属地目录中选**）、频次、时长、配比 |
| **护理方式（决定校验规则）** | **在制定计划时选择**（医养结合／养老机构／居家机构／居家个体）——**它不属老人档案的固定属性**（同一老人换护理方式＝换计划），**系统据此套用 §2.5 对应的项数规则**（州市本期无规则，见下） |
| **项目数量校验** | **按属地规则**：**昆明**＝一级≥18 项/二级≥15/三级≥13，居家按周次数与月时长，**不满足则不能提交**；**州市**＝**本期不校验**（只提示"州市项数规则待属地实施细则明确"），**不拦不卡** |
| **目录外提示** | 昆明机构勾选时，**国家新增项（吞咽训练等 5 项）显式列出并标"过渡期新增·建议纳入"** |
| **三方确认** | 计划需经**家属/长护专员确认**后生效——本期以**系统内确认记录**为准 |
| **变更留痕** | 计划变更**全程留痕**（谁改、何时改、原值、新值） |

> **⭐ 为什么"项目数量校验"是硬要求**：昆明 45 项明确规定了不同护理方式/等级的最低项数，**这是巡查会查的**。系统拦住，比事后被查出来好。
> **⚠️ 州市为何本期不校验（已定）**：各州市**实施细则未发布**，且国家 36 项**没有项数规则表述**、与昆明 45 项颗粒度对不上 ⇒ **照搬昆明＝给错规则**。项数规则属**配置数据**，细则出来后**补配置即可，不改代码**。**界面提示语固定为"州市项数规则待属地实施细则明确"。**

### 5.3 B2 排班派单（组长主战场）

```
┌────────────────────────────────────────────────────────────────┐
│ 排班派单          [日视图 ●] [周视图 ○]    10-11 周六  [← →]   │
├────────────────────────────────────────────────────────────────┤
│          09:00      11:00      14:30      16:00                │
│ 王阿姨   ●李奶奶               ●赵奶奶                         │
│ 刘阿姨           ●张爷爷              ●孙奶奶                  │
│ 陈阿姨                                  ⚠️ 空缺                 │  ← 空缺自动标
├────────────────────────────────────────────────────────────────┤
│ ⚠️ 2 个空缺待派  ·  1 个时间冲突  ·  王阿姨今日 3 单（负荷偏高） │
└────────────────────────────────────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **默认视图** | **日视图**（组长每天实际是按天调的） |
| **横轴** | 时间段；**纵轴**＝护理员 |
| **卡片** | 显示老人称呼＋项目数；点击即**调单面板** |
| **自动提示** | ① **空缺** ② **时间冲突** ③ **负荷偏高** |
| **颜色** | 正常＝蓝；冲突＝红；空缺＝橙虚框 |

**⭐ 调单：严格 ≤3 步**

```
① 点卡片（或点空缺位）
        ↓
② 弹出「改派给谁」，列出可用护理员（含负荷显示）
        ↓
③ 点选目标护理员 → 确认
────────────────────────────
合计：3 步
```

| 环节 | 设计要点 |
|---|---|
| **第 2 步** | **只列"可派的人"**：该时段空闲的、有资质的（**本期为提示，非拦**）、不在休假的 |
| **资质提示** | 〔本期〕**该护理员资质已过期/无该项目资质，请确认** ——**红色提示但可继续**（L6 降级口径） |
| **负荷显示** | 每个人后面显示"今日已有 N 单"，**不排序、不强制** |
| **确认** | **一次确认即生效**；**自动通知护理员 APP** |
| **留痕** | 调单记录**谁改的、改前改后、时间**（评查用） |

> **⭐ 计时验收标准**：**同一调单操作，"微信群沟通"与"系统操作"各计时，系统不得更慢。** 这是第 7 条硬指标。**如果做不到，组长两周内就会绕过系统。**

**批量派单（提效，但非必须）**

| 项 | 规则 |
|---|---|
| **一键派单** | 选时间段 → 系统按"同资质 → 历史服务过该老人 → 距离近 → 当日负荷低"**推荐** → 组长确认 |
| **批量确认** | 推荐的**可整批确认**，也可逐条改 |
| **⚠️ 纪律** | **推荐 ≠ 自动派**——**必须组长确认**（自动派单一旦出错，责任无法归属） |

> **⚠️ 推荐权重说明**：默认权重如上；**不做"熟练度/口碑"排序**（易引发"偏心"质疑）。**这项属现场实测型**——真实排序是否合理，须在机构走访中**观察组长实际派单 10 次**后校准。**不阻塞开发**，代码写成可配置参数。

**冲突检测（自动，不可绕过）**

| 冲突类型 | 系统行为 |
|---|---|
| **同一护理员时间重叠** | **红色警示＋不可保存**（硬拦） |
| **同一老人同时段两次服务** | **红色警示＋不可保存**（硬拦） |
| **跨机构/跨站点冲突** | 本期不做（单机构内检测） |
| **护理员休假/离职** | 排班表已排除；如手工指定则提示 |

> **⚠️ 只有时间冲突硬拦**，其余（负荷、资质、距离）**都只是提示**——**"锁得少、锁得准"**。

### 5.4 B3 工单留痕（查看与追溯）

**列表筛选**：按老人（默认，最常用）／按时间／按护理员／按状态。

**留痕详情（一条记录看全）**

```
┌──────────────────────────────────────────────┐
│ 李奶奶 · 10-11 09:02–10:00 · 王阿姨            │
├──────────────────────────────────────────────┤
│ ✅ 签到 09:02  📍 已定位                       │
│ ✅ 签退 10:00  时长 58 分钟                    │
├──────────────────────────────────────────────┤
│ 协助翻身叩背排痰   ✔️ 已执行  📷 照片 1 张     │
│ 协助进食/水及指导  ✔️ 已执行                  │
│ 口腔清洁          ✔️ 已执行                  │
│ 生命体征测量      ✖️ 未执行（计划内）          │
│ ⭐ 临时加项：协助如厕（计划外）                │
├──────────────────────────────────────────────┤
│ 🎤 语音说明：[播放]                           │
│ ⚠️ 异常上报：无                               │
├──────────────────────────────────────────────┤
│ 质控：待审核     [ 放行 ]  [ 退回 ]            │
└──────────────────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **照片** | 缩略图＋点击放大；**显示拍摄时间**（防事后补拍） |
| **未执行项** | **显式标出**（这是质控重点） |
| **临时加项** | **单独标记**"计划外" |
| **语音** | 可播放；自动转文字（辅助阅读，**不作为正式记录**） |
| **修改** | **不可直接改**——只能"补正"，**保留原值＋补正痕迹** |

### 5.5 B4 质控中心（质控员主战场）

```
┌──────────────────────────────────────────────────────────────┐
│ 质控中心                                                     │
├──────────────────────────────────────────────────────────────┤
│ 【待我处理】14 项                     ← ① 主动推送区（最关键） │
│  ⚠️ 3 条异常上报待处理                                        │
│  🔴 2 条逾期未做（超 24 小时）                                │
│  🟡 5 条留痕待放行                                            │
│  🟡 2 位老人计划未制定（含倒计时）                             │
│  ⚠️ 2 条住院状态老人仍有派单                                   │
├──────────────────────────────────────────────────────────────┤
│ 【待放行队列】  记录列表 → 逐条放行 / 退回                     │
├──────────────────────────────────────────────────────────────┤
│ 【异常处理台】  异常上报列表 → 处理 / 转派 / 关闭（附处理意见） │
└──────────────────────────────────────────────────────────────┘
```

**⭐ 五类主动推送（不等人工查）**

| # | 推送项 | 触发条件 | 优先级 |
|:---:|---|---|:---:|
| 1 | **异常上报待处理** | 护理员提交异常 | 🔴 高 |
| 2 | **逾期未做** | 工单过时段仍无记录（**超 24 小时标红**） | 🔴 高 |
| 3 | **住院状态仍有派单** | 老人状态＝住院暂停，但存在待办工单 | ⚠️ 高 |
| 4 | **计划未制定/超期** | 签约后 5 个工作日未制定计划 | 🟡 中 |
| 5 | **留痕待放行** | 服务完成未审核 | 🟡 中 |

> **⭐ 第 3 条是本系统的一个特色防线**：老人住院了，**如果机构没及时改状态，系统仍然允许派单**（因为状态靠人工维护）。所以这里加一道**"交叉检查"**：**只要挂了住院标记，就回头查有没有未取消的工单**——**用事后校验弥补"状态非自动"的短板**。
> **⚠️ 注意措辞**：这是**内部质控线索**，对客不说"系统自动发现住院"。

**放行与退回**

| 操作 | 规则 |
|---|---|
| **放行** | 一键；**放行后进"上报池"**〔二期〕；本期放行＝记录"质控通过" |
| **退回** | 必填**退回原因**（下拉选择，不要求打字）；**退回后护理员可补正** |
| **批量放行** | 支持；但**异常记录、未执行项记录不可批量放行**（必须逐条看） |
| **全量＋分级** | **不是抽检**——所有记录都过质控队列，**异常与高危级别不允许跳过** |

> **⚠️ 为什么"全量而不是抽检"**：抽检是**监管方的**做法；**机构自己的质控必须是全量的**——因为出问题时，**"我们抽检了没抽到"不是理由**。

**异常处理**

| 环节 | 规则 |
|---|---|
| 收到 | 即时推送（组长＋质控员同时收到） |
| 判断 | 质控员判断：**需改计划？需上报医保？需联系家属？** |
| 处理 | 记录处理意见（**下拉＋可选补充**，不强制打字） |
| 联动 | ⚠️ **如判断需加专项 → 联动到服务计划变更**（对应"该加的专项漏加"防线） |
| 关闭 | 处理完关闭，**全过程留痕** |

> **⭐ 这个联动是关键**：**护理员发现压疮 → 上报 → 质控员判断需加压疮护理 → 直接改计划 → 下次派单自动带出该项目**。**这一条链走通，"发现了没进系统"的断链就补上了。**

> **质控超时提醒（已定）**：**设**，默认阈值 **24 小时**，**每天最多提醒 1 次**，且**不阻塞任何流程**（未放行只影响"能否上报"，不影响护理员接单与服务）。属**现场实测型**——真实值须问机构质控岗"您现在多久看一次服务记录"；做成**机构可在 B8 自行配置**的项。

### 5.5.1 ⭐ B1–B4 交互细则（开发按此实现，逐条不省）

> **这一节补的是"字段级校验 ＋ 边界态 ＋ 反馈"**——上面说了"有什么"，这里说**"填错/漏填/状态不对时系统怎么办"**。**完整版见 `PRD-02 机构管理后台` §3.5／§4.6／§5.4／§6.6**，本节为交付开发用的收口版。

**【B1 服务对象】**

| 项 | 规则 |
|---|---|
| **建档必填校验** | 身份证 **18 位＋校验位算法**；出生日期**由身份证自动带出**（手改须填原因）；参保地默认取机构属地、**跨属地须二次确认**；待遇止 > 起 |
| **身份证防重** | 同机构内 `id_card_no` **不可重复建档**；命中已有档案⇒**提示"已有档案，是否查看"**（不报错，避免重复建档＝档案管理扣分） |
| **建档连锁动作** | 保存成功⇒自动生成档案号＋状态转"正常享受"＋倒计时切"距计划截止 N 天"＋待办出现"制定服务计划" |
| **防误操作** | **档案不可物理删除**，只能"终止"；**变更护理等级须二次确认＋必填原因** |
| **边界态** | 无档案⇒空状态＋大按钮（不留白表格）；超期⇒行标红＋顶部红条；住院中⇒"制定计划/派单"按钮**置灰**并提示"住院期间不可新增服务" |

**【B1-A 垫付期台账与"结转"】（2026-10-12 新增，Q7 回填）**

> **背景**：长护险有 **6 个月等待期**，机构常先垫钱上门。这段服务**录得进、留得住痕、但不计费**。

| 项 | 规则 |
|---|---|
| **录得进** | `待起付（等待期）` 态下**允许派单、允许服务、允许留痕**（`record.is_prepaid=1`） |
| **不计费** | `is_prepaid=1` 的记录 `billable=0`，**不进结算池、不进医保可见的上报池** |
| **不误拦** | L1（`1001`）**只拦"要计费的在享服务"**；等待期走垫付台账，**不被误拦** |
| **结转入口** | 待遇生效（转 `正常享受`）后，档案页出现**〔结转垫付期服务〕**按钮 |
| **结转规则** | 机构**勾选**若干垫付记录 ⇒ 一键生成对应**正式服务记录**；**原垫付记录永久保留**（只读），两套并存；**不自动转**（计费规则不同，自动转＝埋合规雷） |
| **原始时间戳（R-1 补，2026-10-12）** | **结转不改变原始时间戳**：转正后的记录，其**签到时间、定位、照片仍为该次服务的原始值**（**不改为"结转日"**），仅新增 **"来源＝垫付台账（`is_prepaid=1`）"** 标记。**目的**：①不踩"无有效待遇不能服务"硬锁；②不制造虚假"补正痕迹"。 |
| **留痕** | 结转动作**记操作日志**（谁、何时、结转了哪几条） |

> **⭐ 设计要点**：**等待期恰是最需要台账的阶段**——机构垫了钱要留证、要跟家属交代、要跟医保说清"这段是我先做的"。做成**独立台账 + 手动结转**，既不违反"无待遇不能结算"，又不让这段服务变纸面空白，**还不埋"自动算钱算错"的雷**。

**【B1-B 数据初始化 · 批量导入】（2026-10-12 新增，Q17 回填）**

| 项 | 规则 |
|---|---|
| **支持对象** | **参保人档案、护理员档案、服务项目配价** 三类均支持 **Excel 批量导入** |
| **模板** | 系统提供**标准模板**（含必填列、格式说明）；**模板下载**在导入页 |
| **校验** | 导入前**逐行校验**（身份证 18 位＋校验位、必填非空、参保地合法、项目须在属地目录内）；**错误行不写入、生成错误报告**（行号＋原因） |
| **重复处理** | 命中已有 `id_card_no` ⇒ **标"已存在"**，由机构选"跳过/更新"，**不静默覆盖** |
| **上限** | 单次导入 **[待定·建议 ≤2000 行]**（开发联调时定）；超限提示分批 |
| **留痕** | 每次导入**记操作日志**（导入人、时间、成功/失败条数、文件名） |

> **⭐ 为什么必须有**：机构手里的老人/护理员名单**本来就在 Excel 里**——若只能一条条手录，**上线第一周就劝退**。**"换新账本，不用手抄几百个名字"是能否落地的关键一环。**

**【B1-C 老人个人项目库】（2026-10-12 新增，R10）**

> **触发**：机构提出"床位护理 + 居家护理"双线，且要求**目录能按老人维度适配**——即同一机构里，不同老人应有各自长期固定的服务项目组合，派单时直接带入，而不是每次从机构大目录重新挑一遍。

**它与"服务计划"的分工（先讲清，防两套数据打架）**：

| 结构 | 回答的问题 | 性质 | 变化频率 |
|---|---|---|---|
| **`elder_svc` 老人个人项目库** | 这个老人**长期能做 / 常做**哪些项目 | **稳定底表**（派单带入源） | 低（老人能力变了才改） |
| **`plan` / `plan_item` 服务计划** | 这个周期内**按什么规格**执行（频次／时长／拍照档／护理方式） | **周期生效的正式安排**（版本化） | 中（随评估等级、周期调整） |

**关系一句话**：**派单时先读 `elder_svc` 带入"该老人常做项目"当默认勾选，再叠加 `plan` 的规格（频次／时长／拍照档）落成工单。** `elder_svc` 只回答"做哪些"，`plan` 只回答"怎么做"——**两者不互相替代、不重复存。**

**核心规则**：

| 项 | 规则 |
|---|---|
| **归属** | 一张 `elder_svc` 挂在一位老人 `elder_id` 下（**一人一份**，一账号一老人天然一致） |
| **项目来源** | 只能从**本机构 L4 项目库（`svc_org`）**里勾选，**不可自创、不可写机构目录外的项目**（与 `plan_item` 同纪律） |
| **数量约束** | **沿用 §2.5 属地项数规则**（昆明按护理等级 ≥13/15/18 项，附加 ≤5 项）——**不是无上限自由堆**，防止"个人项目库"绕过属地合规 |
| **默认带入** | 制定服务计划时，**一键"从个人项目库带入"**，自动生成 `plan_item` 初稿；派单时再按 `plan` 展开 |
| **护理方式切换** | 老人换护理方式（如居家 → 机构）＝ **重制个人项目库**（因 §2.5 项数规则按护理方式套用），**旧库只读留档**（同"计划变更留旧版"纪律） |
| **变更留痕** | 增删项目**全程留痕**（谁、何时、原值、新值）——与计划变更同标准 |
| **可空** | 老人可不维护个人项目库；此时制定计划仍从 L4 手动勾选（**回退路径不变**，新能力是**可选加速**，不是**新增强制步骤**） |

**交互落地（后台）**：
- 老人档案页新增「**个人项目库**」区块；未维护时显"未设置，制定计划时手动选"；
- 制定/续计划弹层新增「**从个人项目库带入**」按钮——**点了带入可改**（带入只是初稿，最终仍以计划为准）；
- 质控员 / 管理员可编辑（与"制定/变更服务计划"同权限，见 §3.4 权限表），护理员端**只读**。

> **⭐ 为什么这么做**：你要的"按老人维度适配"，本质是"**每个老人的默认项目清单**"。直接做成独立 `elder_svc` 底表，①**不污染** `plan` 的"周期生效 + 版本化"语义；②**派单带入**省掉"每次重新挑一遍"；③**可空**保证老机构、老流程**零迁移成本**。**"双线机构"尤其受益**——床位线和居家线可以各维护各的老人清单，互不串。

**【B2 排班派单】**

**派单前置校验（按序跑，前 5 条硬拦、6–7 条仅提示、第 8 条可见性过滤）**：

| 序 | 校验 | 不通过 |
|:---:|---|---|
| 1 | 工单状态＝待派单/已派单 | 拒绝 |
| 2 | 老人状态＝正常享受 | **硬拦**（L1） |
| 3 | 有有效计划 | **硬拦**（L2） |
| 4 | 护理员当班未休假 | **硬拦** |
| 5 | 时间不冲突 | **硬拦**（`2001`） |
| 6 | 有该项目/等级资质 | **仅提示**（`1006`，红字可继续，L6 降级） |
| 7 | 属组长本组 | **不出现该人选**（过滤，非报错） |

- **"可派的人"列表**：只给**事实**（姓名／今日 N 单／资质状态），**不排序**——排序＝暗示，组长会盲从；
- **调单严格 3 步**：点卡片（弹层不跳页）→点"改派给谁"→点人确认（**即时生效＋自动推 APP＋写留痕**）；**不弹二次确认**（高频操作，且可改回）；
- **批量派单**：推荐**必须人工确认**，**不做一键全派**；**B-1 权重未取值时不显示推荐列**（宁可不给，不给错的）；
- **边界态**：今日无排班⇒空状态＋"生成工单"；全是空缺⇒顶部黄条＋空缺位橙虚框；调单时**原护理员已签到⇒不允许调**（提示已开始，如需处理走异常上报）。

**【B3 工单留痕】**（含**补正**的正确做法）

| 项 | 规则 |
|---|---|
| **补正（本页最易做错）** | **原记录永久保留**，补正产生**新增更正说明**，两条并列；**❌ 不给"编辑"按钮直接改** |
| **不能补正什么** | **签到时间、定位、照片本身**——**这三项是"服务发生过"的证据，结构上不可动** |
| **补正次数** | 不限但每次留痕；同记录补正 **≥3 次⇒自动进质控重点** |
| **照片** | 后台 `qc`/`leader`(本组)/`director` 可看；**默认不可下载**；**家属端一律不展示** |
| **时间线** | 按时间倒序，**逾期未做显式占一行**（"少做一次"比"做错"更需被看见） |
| **导出** | **必须记操作日志**＋文件**带水印**（机构名＋时间＋操作人） |

> **⚠️ 为什么这么严**：巡查表违法违规查处类明确列"**伪造、变造服务记录**"。**给一个"随便改"的按钮，就是把机构架在火上。**

**【B4 质控中心】**

**放行前"对账自检"（按序，任一不通过不放行）**：

| 序 | 检查 | 不通过 |
|:---:|---|---|
| 1 | 留痕四要素齐（时间/项目/时长/护理员） | `1004` |
| 2 | 必拍项已拍 | `3001` |
| 3 | 状态＝待质控 | 幂等提示"已放行" |
| 4 | **放行人 ≠ 记录录入人** | **`4001`** 自审自放行 |

- **退回原因用下拉**（6 选项，不要求打字——质控员可能也是 50 岁）；
- **批量放行的安全边界**：有**异常/未执行项/临时加项/时长异常/补正过**的，**一律不可批量**——**批量是为省手，不是为省眼**；
- **五类推送必须有"消除条件"**（否则列表只长不消，两周后就被无视）；
- **时效可视**：每条待放行记录显示"已等待 X 小时"，超阈值（默认 24h，**待走访回填**）标黄、超 2 倍标红；**提醒不阻塞流程**；
- **边界态**：全部处理完⇒显示"✅ 今日已清空"（不留空表格）；待处理 >50⇒分批＋总数提示；已被他人认领⇒标"处理中（张质控）"避免重复处理。

---

### 5.6 B7 文书档案（精简版）

| 功能 | 说明 |
|---|---|
| **一人一档** | 每位老人的档案（基本信息＋服务计划＋全部服务记录＋异常记录） |
| **导出即合规版式** | 导出对齐**国家 2026 版文书**格式（第 9 条硬指标） |
| **按需检索** | 按老人/时间导出 |
| **协议期满移交** | 支持整包导出 |

> **⭐ 措辞纪律（写死，所有界面文案适用）**：**本模块不得出现"迎检""应对巡查""守住分值""检查前准备"等表述。** **正确表述**：**"日常留痕，随时可导出"**。理由：巡查是监管方的评价动作，**把它说成"要应对的事"，等于承认平时没做好**。
> **本期不做**：电子签章、公文流转、模板自定义 —— **留二期**。

### 5.7 B8 系统设置（精简版）

| 分组 | 内容 |
|---|---|
| **机构信息** | 名称、地址、法人、联系方式、**参保地（只读）** |
| **属地与目录** | 显示当前属地与加载的目录（**只读**）；**国家新增项提示开关**（默认开） |
| **账号与权限** | 新增/停用账号、分配角色（护理员/组长/质控员/院长，**可多选**，见 §3.4.1 补充 2）、**指定护理员归属组长**（下拉选本机构组长，可留空＝未分组，见 §3.4.1 补充 4） |
| **服务项目与配价** | **L4 机构项目库**：从属地目录勾选 ＋ 配价 |
| **对接档位** | 显示当前档位（A 人工登记／B 文件导入导出）；**C 档预留，显示"待接口发布"** |
| **拍照分档配置** | 机构可**加严**必拍项（**不建议放宽**，界面会提示） |
| **质控提醒配置** | 质控超时提醒阈值（默认 24 小时） |

**⭐ 服务项目与配价（多属地的落地页）**

```
┌────────────────────────────────────────────────────────────┐
│ 服务项目与配价        属地：昆明市  →  加载：昆明市目录(45项)  │
├────────────────────────────────────────────────────────────┤
│ [全部] [生活照护] [医疗护理]      ← 按属地目录分类           │
├────────────────────────────────────────────────────────────┤
│ ☑ 头面部清洁、梳理     ¥XX /次   [启用●]                    │
│ ☑ 温水擦浴            ¥XX /次   [启用●]                    │
│ ☐ 会阴护理            ¥XX /次   [停用○]                    │
├────────────────────────────────────────────────────────────┤
│ ⭐ 国家目录新增项（本地方案未含，建议纳入）                    │
│ ☐ 吞咽功能训练        国家代码 L0000204030010000            │
│ ☐ 言语功能训练        国家代码 L0000204040010000            │
│ ☐ 压疮预防照护及指导   国家代码 L0000106020010000            │
│ （以上为过渡期新增，纳入后可按国家目录上报）                   │
└────────────────────────────────────────────────────────────┘
```

| 规则 | 说明 |
|---|---|
| **项目来源** | **只能从属地目录勾选**（不可自创、不可自由输入） |
| **配价** | 机构自填价格；**公示价＝备案价＝上传价须一致**（三价一致，二期校验，本期提示） |
| **启用/停用** | 停用的项目不参与派单 |
| **国家新增项区** | ⭐ **独立区块、显式列出**——即使本地目录没有，**也要让机构看见并可选** |
| **属地切换** | **不可自助**——变更属地须联系我方（属重新配置） |

### 5.8 后台权限与已定事项

| 操作 | 组长 | 质控员 | 院长 | 机构管理员 |
|---|:---:|:---:|:---:|:---:|
| 服务对象建档/改计划 | — | ✅ | — | — |
| 排班派单/调单 | ✅ **本组** | ✅ 全部 | — | — |
| 工单留痕查看 | **本组** | ✅ 全部 | ✅ 全部 | — |
| 质控放行/退回 | ✅ **本组** | ✅ 全部 | — | — |
| 文书导出 | — | ✅ | ✅ | — |
| 系统设置（B8） | — | — | — | ✅ |

> **⚠️ 四条口径（与 §3.4.1 一致）**：① **"本组"＝查 `staff.group_leader_id = 本人 staff_id` 的护理员**，不分组时组长看不到任何人；② **机构管理员不碰业务数据**，只在 B8 系统设置里有权限；③ **"院长无修改权限"修正为"仅当只持 `director` 时写接口 403"**，兼 `qc`／`admin` 按并集放行；④ **一人可兼多角色**，**唯一禁止"自审自放行"**（`4001`）。

---

## 六、家属轻量端（微信公众号）

> **形态**：**微信公众号**（不做独立 APP、不做小程序）。**服务号优先**，**菜单 → H5 页面**。
> **一句话设计目标**：**让家属"偶尔看一眼"就够——不装 APP、不打卡、不被派任务。**

### 6.1 ⭐ 三条铁律（本端最重要的设计约束）

1. **零任务**——**不做每日打卡、不做强制确认、不做任何"必须完成"的事**；
2. **默认只读**——家属**没有任何修改权限**（可"反馈"，但改不了任何记录）；
3. **只看得见自家**——**只能看自己关联的老人**。

> **⚠️ 第 1 条的实践依据**：已有公开报道——某些地区要求家属"**每日线上打卡 1 小时**"，**操作困难、怨声载道**。
> **我方判断**：**家属是"外援"，不是"员工"**。**给家属派任务，是把机构的责任转嫁给家属**。

### 6.2 页面地图（3 个页面，不再多）

| 序 | 页面 | 一句话职责 | 是否必须 |
|:---:|---|---|:---:|
| **F1** | **我家老人** | 老人基本情况、当前服务计划（只读） | ✅ |
| **F2** | **服务记录** | 谁来过、做了什么、多久（只读） | ✅ |
| **F3** | **确认与反馈** | 可选确认某次服务 ／ 留言反馈 | ⭕ 可选 |

**公众号菜单**：`[ 我家老人 ]` `[ 服务记录 ]` `[ 有问题找机构 ]`——**只有三个菜单项**。

**首次进入：绑定老人（仅一次）**

```
┌──────────────────────────────────┐
│  绑定家里的老人                   │
│  请输入老人姓名 + 手机号后 4 位    │
│  [ 姓名 ]  [ 手机号后4位 ]        │
│     [  绑  定  ]                 │
│  温馨提示：绑定后，您可以查看      │
│  老人的服务记录。如绑定不成功，    │
│  请联系机构。                     │
└──────────────────────────────────┘
```

| 规则 | 说明 |
|---|---|
| **绑定方式** | 姓名 ＋ 手机号后 4 位（**不用验证码，简化**） |
| **绑定失败** | 提示"请联系机构核对信息" |
| **可绑几位** | 允许多人绑同一位老人 |
| **解绑** | 需联系机构 |
| **⚠️ 防泄露** | 姓名＋手机号后 4 位**已足以防止随机猜测**；**不做"输入身份证"这类高门槛验证** |

### 6.3 F1 我家老人

| 字段 | 规则 |
|---|---|
| **老人称呼** | 只显示称呼，**不显示身份证、住址等敏感信息** |
| **护理等级** | **必须写"一级护理（最高级）"** |
| **服务计划** | 项目＋频次；**只读** |
| **服务人员** | 显示**姓名**（本期 `staff` 表**无"工号"字段**，不做工号；**不显示手机号**，走机构统一联系） |
| **不显示** | 价格、费用、限额、基金支付比例——**家属端不涉及钱** |

### 6.4 F2 服务记录

```
┌───────────────────────────────────┐
│  李奶奶的服务记录                  │
├───────────────────────────────────┤
│  今天 10-11                        │
│  ┌─────────────────────────────┐  │
│  │ 09:02–10:00  王阿姨 · 58 分钟 │  │
│  │ 翻身叩背、进食、口腔清洁        │  │
│  │                  [知道啦 ○]  │  │  ← 可选确认
│  └─────────────────────────────┘  │
│  昨天 10-10                        │
│  ┌─────────────────────────────┐  │
│  │ 09:15–10:05  王阿姨 · 50 分钟 │  │
│  │ 翻身叩背、进食、擦浴           │  │
│  │                  ✅ 已确认     │  │
│  └─────────────────────────────┘  │
└───────────────────────────────────┘
```

| 元素 | 规则 |
|---|---|
| **排序** | 时间倒序（最新的在最上） |
| **每条显示** | 日期、时间段、**服务人员姓名**、**时长**、**服务项目清单** |
| **照片** | ⚠️ **本期一律不展示**——见 §6.7 |
| **异常** | 如有异常上报，显示"已向机构反馈"（**不展示异常细节**，避免家属过度焦虑） |
| **服务人员** | 显示姓名；**如由多位护理员服务，如实显示实际那个人**（对不上号＝信任问题） |

> **⭐ 家属端最实在的一件事**：**看到"计划里有的项目，实际做了没有"。** 例：计划含"生命体征测量"，某天记录里标"未执行"——**家属能看到**。
> **⚠️ 但措辞要格外小心**：**不呈现为"护理员没做"，而呈现为"本次未执行"**——因为"未执行"可能是老人当时状态不适合，原因在机构侧。

### 6.5 F3 确认与反馈

**可选确认（与拍照分档配套）**

```
┌───────────────────────────────────┐
│  10-11 09:02–10:00                 │
│  王阿姨上门做了：翻身叩背、进食、口腔清洁 │
│  您知道这次服务吗？                 │
│  [ ✅ 知道啦 ]   [ 有疑问 ]        │
│  （不点也没关系）                    │  ← 明确告知"非必须"
└───────────────────────────────────┘
```

| 规则 | 说明 |
|---|---|
| **是否必须** | **完全可选**——不点，**不影响服务记录成立** |
| **点击"知道啦"** | 记为该次服务的**家属确认**（软证据） |
| **点击"有疑问"** | 跳转到反馈，**通知机构**（走独立通道，不进异常上报流程） |
| **明确告知** | **必须显示"不点也没关系"**——否则等同于隐性派任务 |
| **次数限制** | 一条记录只能确认一次 |

> **⭐ 为什么"不点也没关系"必须写在界面上**：**我们承诺零任务，就必须把这句话写出来。** 否则家属会认为"是不是应该点"，**那就变成了软性任务**。

**反馈（有问题找机构）**

| 项 | 规则 |
|---|---|
| **入口** | 菜单第三项 ＋ 每次服务记录下方 |
| **形式** | **可选分类**（服务态度/时间不准/项目没做/其他）＋ **可选文字或语音** |
| **必填** | **只有分类必选** |
| **响应** | 通知机构（组长＋质控员）；**机构应在 24 小时内响应**（内部要求，非对外承诺） |
| **闭环** | 机构处理后，家属端显示"已处理" |
| **⚠️ 边界** | **反馈不是投诉受理**——不承诺处理时效、不替代医保投诉渠道 |

### 6.6 边界（写死，本端最容易出事）

| 项 | 边界 |
|---|---|
| **费用** | **家属端完全不涉及钱**——不显示价格、不显示限额、不显示基金支付比例、不做账单 |
| **评价** | **不做星级评分**——评分会让护理员为好评而"讨好"或"摆拍" |
| **异常细节** | 不展示异常上报的具体内容（只显示"已向机构反馈"） |
| **真人联系** | **不提供护理员个人手机号**；联系走机构 |
| **医疗建议** | **不给任何医疗判断或建议** |
| **替代官方** | 家属端**不是官方渠道**——待遇查询、评估申请等仍走官方 |

**⭐ 隐私号（与全站口径一致）**：**真实号码永不展示**（全站统一，无开关）。**家属→机构**通过机构统一电话；**家属→护理员不提供**。

### 6.7 措辞纪律（本端专属，写死）

| # | 规则 | 反例 | 正例 |
|:---:|---|---|---|
| 1 | **不写"未做"，写"本次未执行"** | "护理员没做翻身" | "本次未执行" |
| 2 | **不写"迟到"，写实际时间** | "护理员迟到了" | "09:15 到达" |
| 3 | **不写"缺勤"** | "今天没人来" | "今天暂无服务记录" |
| 4 | **不出现"监督""考核""举报"** | "您可以监督护理员" | — |
| 5 | **"知道啦"不设默认勾选** | 默认已勾选 | 必须主动点 |
| 6 | **不承诺任何时效** | "我们会在 2 小时内处理" | "我们会尽快处理" |
| 7 | **等级必带"（最高级）"** | "一级护理" | "一级护理（最高级）" |

### 6.8 家属端已定事项

| # | 事项 | 定论 |
|:---:|---|---|
| 1 | **照片对家属可见** | **本期不给**：字段 `visible_to_family` **恒为 0**，后台**不建开关**，家属端**一律不展示服务照片**。核心判断：**这个口子一旦开就回不去**——家属看惯了照片，某次因隐私或疏忽没拍，反而会被理解成"没做"。二期若要开，须先定照片保留期限与打码规则 |
| 2 | **"知道啦"是否显示确认人姓名** | **显示**，格式 **"姓氏＋关系"**（如"张女士（女儿）"），**不显示全名、不显示手机号**。多位子女时能避免重复追问，也让机构知道谁来对接的 |

---

## 七、数据库设计（23 张表）

> **通用字段**（每张表都有，下文不再重复）：`created_at`／`created_by`／`updated_at`／`updated_by`／`is_deleted`（**本期一律软删除，不物理删**）。

### 7.1 表总览（23 张）

| # | 表名 | 中文 | 本期用途 |
|:---:|---|---|---|
| 1 | `org` | 机构 | 机构信息、属地、账号根 |
| 2 | `user` | 账号 | 登录账号（后台四角色） |
| 3 | `staff` | 人员 | 护理员/医护基础信息＋**资质字段预留** |
| 4 | `elder` | 老人档案 | 待遇状态、等级、参保地 |
| 5 | `elder_status_log` | 待遇状态变更日志 | **状态变更留痕** |
| 6 | `elder_svc` | 老人个人项目库 | **老人长期可做/常做项目清单（派单带入源，R10）** |
| 7 | `plan` | 服务计划（头） | 周期、等级、护理方式、确认信息 |
| 8 | `plan_item` | 服务计划（项） | 计划内含哪些项目、频次、时长 |
| 9 | `svc_national` | 国家基准库 | 国家 36 项＋官方代码 |
| 10 | `svc_local` | 属地目录库 | 昆明 45 项；州市引用 L1 |
| 11 | `svc_mapping` | 属地↔国家映射 | **机构不可见** |
| 12 | `svc_org` | 机构项目库 | 机构勾选＋配价 |
| 13 | `order` | 工单 | 一次服务任务 |
| 14 | `record` | 服务留痕（主） | 签到签退、时长、语音、状态 |
| 15 | `record_item` | 留痕项目明细 | 每个项目的"做了/没做/免拍" |
| 16 | `record_photo` | 留痕照片 | 照片存储引用 |
| 17 | `record_abnormal` | 异常上报 | 9 宫格分类＋语音＋照片 |
| 18 | `qc` | 质控记录 | 放行/退回、异常处理 |
| 19 | `report` | 上报池 | 【预留】R4，建表不写业务数据 |
| 20 | `settlement` | 结算 | 【预留】R1，建表不写业务数据 |
| 21 | `dict_abnormal_type` | 异常分类字典 | 9 宫格配置 |
| 22 | `dict_photo_tier` | 拍照分档字典 | 必拍/免拍/可拍配置 |
| 23 | `loc_config` | 统筹区配置 | 含目录来源（昆明 45 / 州市 36） |

### 7.2 核心表字段定义

**`org` 机构表**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `org_id` | varchar(32) | ✅ | 机构 ID（主键） | 【系统】 |
| `org_name` | varchar(100) | ✅ | 机构全称（**须与备案名称一致**） | 【本期】 |
| `org_type` | varchar(20) | ✅ | `medical_care`（医养结合）／`nursing_home`（养老机构）／`home_care`（居家上门）／`home_individual`（居家个体） | 【本期】 |
| `credit_code` | varchar(18) | ✅ | 统一社会信用代码 | 【本期】 |
| `loc_code` | varchar(12) | ✅ | **参保地／统筹区代码**（决定加载哪套目录） | 【本期】 |
| `loc_name` | varchar(50) | ✅ | 统筹区名称（冗余，便于展示） | 【本期】 |
| `svc_source` | varchar(10) | ✅ | 本机构目录来源：`national`／`local` | 【本期】 |
| `license_no` | varchar(50) | ○ | 定点服务机构编号 | 【本期】 |
| `address` | varchar(200) | ✅ | 机构地址 | 【本期】 |
| `contact_name` / `contact_phone` | varchar | ✅ | 联系人／电话 | 【本期】 |
| `bed_count` | int | ○ | **床位备案数**（机构护理类必填） | 【本期】 |
| `sign_date` | date | ○ | 定点服务协议签订日（建档倒计时基准） | 【本期】 |

**`user` 账号表**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `user_id` | varchar(32) | ✅ | 账号 ID | 【系统】 |
| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
| `login_name` | varchar(50) | ✅ | 登录名（手机号） | 【本期】 |
| `real_name` | varchar(30) | ✅ | 真实姓名 | 【本期】 |
| `role` | varchar(50) | ✅ | **角色（可多值，逗号分隔）**：`nurse`／`leader`／`qc`／`admin`／`director`；如 `director,admin`、`leader,qc`。**判权＝并集**（见 §3.4.1 补充 2） | 【本期】 |
| `staff_id` | varchar(32) | ○ | 关联 `staff` 表（护理员角色必填） | 【本期】 |
| `status` | varchar(10) | ✅ | `active`／`disabled` | 【本期】 |

> **⚠️ 权限落地纪律**：**角色写在后端权限校验，不在界面做开关**。**仅当账号只持 `director` 时，写接口返回 403**；**若同时持 `qc`／`leader`／`admin`，按角色并集放行**（§3.4.1 补充 2）。

**`staff` 人员表（含 R2 预留）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `staff_id` | varchar(32) | ✅ | 人员 ID | 【系统】 |
| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
| `id_card_no` | varchar(18) | ✅ | 身份证号（**实名制**，加密存储） | 【本期】 |
| `person_code` | varchar(20) | ○ | **医保人员编码**（LN+6位区划+6位顺序；**字段留余量**） | 【预留】R4 |
| `phone` | varchar(15) | ✅ | 手机号（APP 登录用） | 【本期】 |
| `job_type` | varchar(20) | ✅ | `nurse`／`nurse_medical`／`manager` | 【本期】 |
| `work_type` | varchar(10) | ✅ | `fulltime`／`parttime` | 【本期】 |
| `entry_date` / `leave_date` | date | ○ | 入职／离职日 | 【本期】 |
| `employ_status` | varchar(10) | ✅ | `on_job`／`leave`／`transfer` | 【本期】 |
| `cert_type` / `cert_no` / `cert_level` / `cert_expire` / `cert_status` | varchar/date | ○ | **资质五字段**（本期**人工录入**） | **【预留】R2** |
| `cert_verify_url` | varchar(200) | ○ | 联网查验结果留痕 | **【预留】R2** |
| **`group_leader_id`** | varchar(32) | ○ | **归属组长**（＝该护理员所在"组"的组长 `staff_id`；本组界定的唯一依据，见 §3.4.1 补充 4）。**可为空＝机构未分组** | 【本期】 |

> **⚠️ 本期数据不空转纪律**：**`cert_*` 字段本期就要人工录入**——签约机构手上都有证书信息，**先录进去，二期直接可用**。
> **⚠️ 界面纪律**：本期 `cert_*` 字段**只在精简版人员管理里可填可看**，**不做到期提醒、不做禁派拦截**（那是二期）。

**`elder` 老人档案表（① 待遇档案）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `elder_id` | varchar(32) | ✅ | 老人 ID | 【系统】 |
| `org_id` | varchar(32) | ✅ | 所属机构 | 【本期】 |
| **`loc_code`** | varchar(12) | ✅ | **参保地／统筹区**（全链路取目录依据） | 【本期】 |
| `name` | varchar(30) | ✅ | 姓名 | 【本期】 |
| `gender` | char(1) | ✅ | `M`／`F` | 【本期】 |
| `birth_date` | date | ✅ | 出生日期（系统算年龄） | 【本期】 |
| `id_card_no` | varchar(18) | ✅ | 身份证号（加密） | 【本期】 |
| `phone` | varchar(15) | ○ | 联系电话 | 【本期】 |
| `address` | varchar(200) | ✅ | 居住地址（服务上门用） | 【本期】 |
| `guardian_name` / `guardian_phone` | varchar | ○ | 紧急联系人 | 【本期】 |
| `insur_no` | varchar(30) | ✅ | **医保参保号** | 【本期】 |
| `insur_type` | varchar(10) | ✅ | `employee`／`resident` | 【本期】 |
| `insur_years` | int | ○ | **缴费年限**（参保核验时登记，流程 01 第 1 步） | 【本期】 |
| `insur_verify_status` | varchar(20) | ○ | **参保核验状态**：`verified`／`unverified`——**本期无医保接口，核验以机构线下确认为准**，结果记此字段留痕；接口发布后升级在线核验 | 【本期】 |
| `insur_verify_date` | date | ○ | 参保核验日期（留痕） | 【本期】 |
| `assess_level` | varchar(20) | ✅ | **失能等级**：`sev_1`（重度一级·**最高级**）／`sev_2`／`sev_3` | 【本期】 |
| `care_level` | varchar(20) | ✅ | **护理等级**：`care_1`（一级·**最高级**）／`care_2`／`care_3` | 【本期】 |
| `assess_date` | date | ✅ | 评估结论日期 | 【本期】 |
| `assess_org` | varchar(100) | ○ | 评估机构名称 | 【本期】 |
| `benefit_start` / `benefit_end` | date | ✅ | **待遇有效期起止** | 【本期】 |
| `treat_status` | varchar(20) | ✅ | **待遇状态**（见 §7.4） | 【本期】 |
| `status_source` | varchar(10) | ✅ | `manual`／`api`——**本期恒 `manual`** | **【预留】R5** |
| `status_change_date` | date | ○ | 状态最后变更日 | 【本期】 |
| `hosp_start` / `hosp_end` | date | ○ | **住院起止日**（`住院暂停` 时必填） | 【本期】 |
| `photo_tier_override` | json | ○ | 机构对本老人拍照分档的**加严覆盖**（**只能加严**） | 【本期】 |
| `need_assess` | json | ○ | **上门需求评估五块信息**（流程 02 第 2 步采集，供第 3 步制定计划引用）：`living_env`（居住环境）／`care_condition`（照护条件）／`svc_demand`（服务项目诉求）／`special_risk`（特殊风险）／`time_preference`（时间偏好）。**结构化 JSON 承载，非纯文本备注** | 【本期】 |
| `note` | text | ○ | 备注（**含"注意事项"区块内容**） | 【本期】 |

> **⚠️ 等级显示纪律**：`assess_level`／`care_level` 在界面上**必须带"最高级"字样**，**不允许前端省略**。
> **⚠️ 认知衰退边界**：`assess_level` 只反映**日常活动 6 项**自评＋正式评估结论；**认知/感知觉 7 项须上门评估，系统不筛**。此口径须出现在任何展示等级的页面注脚。

**`elder_status_log` 待遇状态变更日志**

| 字段 | 类型 | 必填 | 说明 |
|---|---|:---:|---|
| `log_id` | varchar(32) | ✅ | 主键 |
| `elder_id` | varchar(32) | ✅ | 老人 ID |
| `from_status` / `to_status` | varchar(20) | ✅ | 变更前后状态 |
| `change_reason` | varchar(200) | ✅ | **变更原因（必填，不允许空）** |
| `source` | varchar(10) | ✅ | `manual`／`api` |
| `operator_id` | varchar(32) | ✅ | 操作人 |
| `evidence_file` | varchar(200) | ○ | 佐证材料（如出院小结照片路径） |
| `changed_at` | datetime | ✅ | 变更时间 |

> **⚠️ 关键设计**：**待遇状态每一次变更都必须写一条日志，`change_reason` 强制必填**。
> **理由**：`treat_status` 直接决定"能不能服务、能不能计费"。**如果不留痕，"住院期间照做"这类问题将无法追溯**。**这条日志是机构自己的护身符。**

**`elder_svc` 老人个人项目库（R10，派单带入源）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `elder_svc_id` | varchar(32) | ✅ | 主键 | 【系统】 |
| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
| `svc_id` | varchar(32) | ✅ | **引用 L4 `svc_org.org_svc_id`**（只从本机构项目库选） | 【本期】 |
| `svc_name_snapshot` | varchar(100) | ✅ | **项目名快照**（同 `plan_item` 纪律，防目录改名） | 【本期】 |
| `svc_code_snapshot` | varchar(20) | ○ | **国家代码快照**（上报基准，二期用） | 【预留】R4 |
| `care_mode` | varchar(20) | ✅ | **护理方式**（`inst_medical`／`inst_nursing`／`home_org`／`home_individual`）——**换方式＝重制个人项目库** | 【本期】 |
| `is_active` | tinyint | ✅ | 是否启用（软停用不物理删） | 【本期】 |

> **⚠️ 关键设计（三条，写死）**：
> 1. **`elder_svc` 只存"做哪些"，`plan` 只存"怎么做"**——前者是长期稳定底表（派单带入源），后者是周期生效的正式安排（频次／时长／拍照档）。**两者不互相替代、不重复存规格字段**。
> 2. **项目只能从 L4 选**——`svc_id` 必须落在本机构 `svc_org` 内，**不可自创、不可写机构目录外项目**（与 `plan_item` 同纪律，防"个人项目库"绕开属地合规）。
> 3. **`care_mode` 是硬键**——老人换护理方式（居家→机构）必须**重制**个人项目库（因 §2.5 项数规则按护理方式套用），**旧库只读留档**（同"计划变更留旧版"纪律）。**可空**：老人可不维护，此时制定计划仍从 L4 手动勾选。

**`plan` 服务计划表（② 服务计划）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `plan_id` | varchar(32) | ✅ | 计划 ID | 【系统】 |
| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
| `plan_period_start` / `plan_period_end` | date | ✅ | **计划周期** | 【本期】 |
| `care_level` | varchar(20) | ✅ | 计划对应护理等级（**改等级须重新制定计划**） | 【本期】 |
| `care_mode` | varchar(20) | ✅ | `inst_medical`／`inst_nursing`／`home_org`／`home_individual` | 【本期】 |
| `item_count` | int | ✅ | **计划项目数**（系统按属地规则校验） | 【本期】 |
| `item_count_rule` | varchar(100) | ○ | 校验依据快照（如"昆明·医养结合·一级护理 ≥18 项"） | 【本期】 |
| `extra_item_count` | int | ○ | 附加项数（**≤5**） | 【本期】 |
| `week_freq` / `month_hours` | int | ○ | 居家类的**每周次数／每月小时数** | 【本期】 |
| `plan_status` | varchar(20) | ✅ | `draft`／`active`／`changed`／`ended` | 【本期】 |
| `confirm_elder` / `confirm_guardian` | tinyint | ○ | 确认（0/1，**可选，不强制**） | 【本期】 |
| `confirm_time` | datetime | ○ | 确认时间 | 【本期】 |
| `plan_basis` | json | ○ | **计划依据**（流程 02 第 3 步结构化留痕"定计划参考了什么"）：护理服务建议的**来源机构／建议方向／建议项目／日期**。评估/经办侧给的**外部参考**，机构据实录入，证明"计划不是凭空定的" | 【本期】 |
| `change_from_plan_id` | varchar(32) | ○ | **变更来源计划**（**旧计划不删**） | 【本期】 |

> **⚠️ 计划变更纪律**：**改计划＝新建一条计划 + 指向旧计划**，**绝不原地改**。
> **理由**：政策要求"服务与计划相吻合"。若原地改，历史工单会突然"对上"一个当时不存在的计划——**这恰恰是"篡改数据"的典型形态**。**留旧版＝留证据。**

**`plan_item` 计划项目明细表**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `plan_item_id` / `plan_id` | varchar(32) | ✅ | 主键／计划 ID | 【系统】/【本期】 |
| `svc_id` | varchar(32) | ✅ | **引用 `svc_local` 或 `svc_national` 的 ID** | 【本期】 |
| `svc_name_snapshot` | varchar(100) | ✅ | **项目名快照**（防目录改名后历史计划显示错乱） | 【本期】 |
| `svc_code_snapshot` | varchar(20) | ○ | **国家代码快照**（上报基准，二期用） | 【预留】R4 |
| `freq_type` | varchar(20) | ○ | `daily`／`weekly_n`／`monthly_n`／`as_needed` | 【本期】 |
| `freq_value` | int | ○ | 频次值 | 【本期】 |
| `duration_min` | int | ○ | **单次时长（分钟）** | 【本期】 |
| `photo_tier` | varchar(10) | ✅ | **拍照档位**：`must`／`optional`／`free` | 【本期】 |
| `caution_note` | text | ○ | **注意事项**（显示在 APP M4） | 【本期】 |
| `is_medical` / `need_cert` | tinyint | ✅ | 是否医疗护理类／是否要求持证 | 【本期】 |

> **⚠️ `svc_name_snapshot` 不是冗余，是必需**：目录会更新。**快照保证历史计划与历史留痕永远显示当时的项目名**，否则三年前的服务记录会突然"变成"另一个项目名——**这在稽核中是致命的**。

**服务项目四层表（L1–L4）**

`svc_national`（L1 · 36 项）：`nat_id`／`nat_code`（**17 字符**，字段留余量 `varchar(20)`）／`nat_name`／`nat_category`（`life`/`medical`）／`nat_sub_category`／`recommend_staff`／`recommend_duration`／`is_medical`／`version`

`svc_local`（L2）：`loc_id`／`loc_code`／`local_item_name`／`local_category`／`svc_time`／`min_freq`／`staff_qual`／`is_medical`／`source_doc`／`map_status`（`mapped`/`local_only`）

`svc_mapping`（L3 · **机构不可见**）：`map_id`／`loc_id`／`nat_id`（**可空＝无法映射**）／`map_type`（`one_to_one`／`many_to_one`／`partial`／`local_only`／`national_only`）／`map_note`／`status`（`confirmed`/`pending`）

`svc_org`（L4）：`org_svc_id`／`org_id`／`src_type`／`src_id`／`is_enabled`／`price`【预留R1】／`price_effective`【预留R1】／`is_new_national`

> **⚠️ 五条多属地纪律在表结构上的落地**：
> 1. **走配置不走代码** → 新增州市＝插一行 `loc_config` + 一批 `svc_local`，**代码零改动**；
> 2. **必须可映射** → `svc_mapping` 保证每项可追；`map_status = local_only` 的项**上报时自动排除**；
> 3. **机构不可改目录** → `svc_org` **只有 `is_enabled` 和 `price` 可改**，其余只读；
> 4. **国家新增项显式提示** → `is_new_national = 1` 的项**独立区块显示**；
> 5. **映射表不对外** → `svc_mapping` 表**不提供任何机构侧接口**。

**`order` 工单表（③ 派单工单）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `order_id` | varchar(32) | ✅ | 工单 ID | 【系统】 |
| `elder_id` / `org_id` | varchar(32) | ✅ | 老人／机构 | 【本期】 |
| `plan_id` | varchar(32) | ✅ | **来源计划**（L2 硬锁落地） | 【本期】 |
| `service_date` | date | ✅ | **服务日期** | 【本期】 |
| `time_slot_start` / `time_slot_end` | datetime | ✅ | **服务时段**（用于冲突检测） | 【本期】 |
| `assignee_id` | varchar(32) | ○ | 派给谁（`staff_id`） | 【本期】 |
| `assign_time` | datetime | ○ | 派单时间 | 【本期】 |
| `assign_mode` | varchar(20) | ○ | `manual`／`batch_recommend`（**批量必须人工确认**） | 【本期】 |
| `order_status` | varchar(20) | ✅ | **工单状态**（见 §7.4） | 【本期】 |
| `item_list` | json | ✅ | 本次工单项目的快照 | 【本期】 |
| `need_photo` | tinyint | ✅ | 本次是否含必拍项 | 【本期】 |
| `cancel_reason` | varchar(200) | ○ | 取消原因（已取消必填） | 【本期】 |
| `reschedule_log` | json | ○ | **调单记录** | 【本期】 |
| `qualification_check` | varchar(20) | ○ | 资质校验结果（**本期恒 `unchecked`**） | **【预留】R2** |
| **`billable`** / **`price_snapshot`** / **`settle_period`** | varies | ○ | 可计费／服务时点价／结算周期 | **【预留】R1** |
| `exception_flag` | tinyint | ○ | 是否异常费用 | **【预留】R6** |

> **⚠️ 一种硬冲突、其余软提示**：派单/调单时，**只对"同一 `assignee_id` 且 `time_slot` 重叠"返回硬错误（拒绝保存）**；其余情况**一律只返回提示、不拦**。
> **理由**：**拦截要准，不能把便利性拦掉。** 组长宁愿微信群说一句就改了，也不会忍受系统处处拦住。

**`record` 服务留痕表（③ 履约留痕）**

| 字段 | 类型 | 必填 | 说明 | 标记 |
|---|---|:---:|---|---|
| `record_id` | varchar(32) | ✅ | 留痕 ID | 【系统】 |
| `order_id` | varchar(32) | ✅ | **来源工单**（L3 硬锁落地） | 【本期】 |
| `elder_id` / `assignee_id` | varchar(32) | ✅ | 老人／护理员 | 【本期】 |
| `checkin_time` | datetime | ✅ | **签到时间（系统自动取，不允许手工改）** | 【本期】 |
| `checkout_time` | datetime | ○ | **签退时间（同上）** | 【本期】 |
| `duration_min` | int | ○ | 实际时长（**系统算，人不能改**） | 【本期】 |
| `checkin_lat` / `checkin_lng` | decimal(10,6) | ○ | 签到定位（**定位失败不阻塞**） | 【本期】 |
| `locate_status` | varchar(20) | ✅ | `ok`／`failed`／`denied`（**失败照常可提交**） | 【本期】 |
| `record_status` | varchar(20) | ✅ | **留痕状态**（见 §7.4） | 【本期】 |
| `voice_file` | varchar(200) | ○ | 语音备注（免拍档留痕四要素之一） | 【本期】 |
| `offline_flag` | tinyint | ✅ | 是否离线创建 | 【本期】 |
| `client_md5` | varchar(32) | ✅ | **客户端指纹**（防重复上传、防篡改） | 【系统】 |
| `submit_time` | datetime | ○ | 提交时间 | 【系统】 |
| `actual_duration_tier` | varchar(10) | ○ | 时长档位（**<5 分钟标黄**） | 【系统】 |
| `biz_line` | varchar(20) | ✅ | **业务线**：本期恒 `ltci`（长护险）。**预留 `self_pay`（自费）等分线位**——自费服务须落在留痕层单独计时、单独记账，与待遇服务**两条时间线不重叠**（见 §7.3.1 R8 与流程 04 第 4 步） | 【预留】R8 |

> **⚠️ 三条硬设计（都是合规点）**：
> 1. **签到签退时间、时长一律系统取，接口不接受客户端传入这两个值**——防"补录时间"；
> 2. **定位失败不阻塞提交**——老人家里弱网是常态，**不能因为定位不到就不让干活**；
> 3. **时长不设"最低时长硬拦"**，只记 `actual_duration_tier`，**由质控看，不由系统罚**。

**`record_item` 留痕项目明细表**：`record_item_id`／`record_id`／`svc_id`／`exec_result`（**`done`／`undo_not_done`（本次未执行）／`undo_refused`（老人拒绝）**）／`undo_reason`／`extra_flag`／`photo_required`

> **⚠️ 措辞纪律落到数据层**：`exec_result` 的枚举值**必须是 `undo_not_done`（本次未执行）而不是 `not_done`（未做）**。
> **理由**：**"未做"含指责意味，"本次未执行"是事实陈述**——这条在字段命名层就要卡住，不让前端有机会写"未做"。

**`record_photo` 留痕照片表**：`photo_id`／`record_id`／`svc_id`／`file_path`（**压缩后 ≤500KB**）／`file_size`／`visible_to_family`（**本期恒 0**）／`upload_batch`／`keep_until`（**补传后至少 7 天**）

**`record_abnormal` 异常上报表**：`abnormal_id`／`record_id`／`elder_id`／`reporter_id`／`abnormal_type`（**9 宫格，必选**）／`abnormal_desc`（可选）／`voice_file`／`has_photo`／`notify_status`／`handle_status`／`handle_result`／`link_plan_change`

> **⚠️ "一切可选、分类必选"的落地**：**只有 `abnormal_type` 是必填，其余全可选**。**宁要一条没人名没照片的异常，也不要一条没报上来的压疮。**

**`qc` 质控记录表（④ 质控闸门）**：`qc_id`／`record_id`／`qc_type`（`normal`／`auto_push`／`recheck`）／`push_reason`（**五类**）／`qc_result`／`qc_note`（**退回时必填**）／`qc_staff_id`／`qc_time`／`pass_time`／`first_qc_id`

> **⚠️ 全量非抽检（落库层面保证）**：**每一条 `record_status = submitted` 的留痕，都必须生成一条 `qc` 记录**（定时任务扫描生成）。
> **理由**：抽检＝总有漏的；而**"先质控再上报"是国家明文**。**全量生成 qc 记录，是把"不抽检"从人工承诺变成数据结构。**

### 7.3 二期预留表（本期建表，不写入业务数据）

**`report` 上报表**：`report_id`／`record_id`／`order_id`／`report_status`／`report_time`／`official_no`（**官方受理号**）／`loc_code`／`nat_code_snapshot`／`adapter_result`

**`settlement` 结算表**：`settle_id`／`org_id`／`settle_period`／`amount_total`／`amount_passed`／`amount_rejected`／**`amount_fund`（基金支付部分）／`amount_self_pay`（个人自付部分）**／`submit_date`／`pay_date`／`exception_reason`／`handle_deadline`

> **⚠️ 个人自付拆分（流程 05 对齐）**：长护险基金支付 70%（职工）/ 50%（居民），**个人自付 30% / 50%**。结算时须**分开记、分开展示**——`amount_fund`＝待医保结算的基金部分，`amount_self_pay`＝待老人自付的应收部分（由机构向老人/家属直接收取，不走基金）。**与"自费项目"是两回事**：个人自付＝待遇内个人掏的部分；自费项目＝目录外、100% 自购。

### 7.3.1 ⭐ 多业务线扩展（R8 预留 · 2026-10-12 新增）

> **问题**：机构不止有长护险业务，还有**自费陪护、居养（养老机构）、民政补贴**等其他业态。**本系统是"长护险这一条业务线的专业账本"，不是机构全业务 ERP**——但须**结构上留口子**，避免将来"多业务"变成"推倒重来"。

**① 定位（写死，不膨胀）**：
- **本期只做长护险这一条线**（`biz_line` 恒 `ltci`），把这条线的合规账做扎实。
- **不把其他业务硬塞进长护险规则**——自费不需要评估等级、民政补贴走民政通口径、居养走民政系统，各是各的规则，**混在一个状态机里会把长护险的账弄脏**。

**② 预留方式（只留结构，不改本期逻辑）**：
- 在 `elder`／`order`／`svc_org`／`record` **四表加 `biz_line` 字段**（默认恒 `ltci`）——**这是"开一条新线"的锚点，不是"本期实现多业务"**。**`record` 表加 `biz_line` 是流程 04 自费服务"单独计时、不走基金"的落点**：自费服务与待遇服务同在一张 `record` 表，靠 `biz_line` 区分两条时间线。
- 二期若机构确有需求，则**按业务线挂不同"规则包"**：`ltci` 挂"评估等级＋待遇状态＋36/45 目录＋六条硬锁"；`self_pay` 挂"不要求等级、不拦派单、只记账"；`civil_subsidy` 挂"补贴目录＋民政通口径"；`residence` 挂"居养管理"。

**③ 三条不可越界的线（软件管不了，须靠机构＋规则）**：
1. **资金不能串**：长护险基金（政府管）与自费（老板自己的钱）**财务上必须分开**，系统只能"分开记、分开展示"，**"该不该混着花"是合规问题，系统拦不住人**。
2. **政府接口各走各的**：长护险走医保平台、民政补贴走民政通、居养走民政系统——**三条接口是三个政府系统**，系统可预留对接位，**接口何时通由政府定，我方不承诺**。
3. **业务线优先级由机构定**：同一老人可能同时有"长护险档案"和"自费档案"，**哪个优先、能不能叠加**，是机构的经营决策，系统只忠实记录。

**④ 对客口径（一句可用）**："这个系统管的是你长护险这条线；你另外的自费/居养/补贴业务，我们在同一个账号里给你**预留了分线位置**，但**先别把三套规则揉在一起**——揉在一起，长护险的合规账就脏了。"

### 7.4 状态机 ↔ 字段值对照

**待遇状态 `elder.treat_status`（十态）**

| 值 | 中文 | 可否新建计划 | 可否派单 | 可否服务 | 可否计费 |
|---|---|:---:|:---:|:---:|:---:|
| `pending_file` | 待建档 | ✅ | ❌ | ❌ | ❌ |
| `waiting_period` | **待起付（等待期/垫付期）** | ✅ | ✅ | ✅（**仅垫付台账**） | ❌ |
| `active` | 正常享受 | ✅ | ✅ | ✅ | ✅ |
| `hosp_pause` | 住院暂停 | ❌ | ❌ | ❌ | ❌ |
| `review_waiting` | **复评等待期** | ❌ | ❌ | ❌ | ❌ |
| `transferring` | **跨统筹区转移中** | ❌ | ❌ | ❌ | ❌ |
| `dead` | 死亡 | ❌ | ❌ | ❌ | ❌ |
| `long_away` | 长期异地居住 | ❌ | ❌ | ❌ | ❌ |
| `benefit_expired` | 待遇到期 | ❌ | ❌ | ❌ | ❌ |
| `terminated` | 已终止 | ❌ | ❌ | ❌ | ❌ |

> **接口层强制**：任何创建 `order` 的请求，**先校验 `elder.treat_status ∈ {active, waiting_period}`**，不满足**直接拒绝**（不是警告）。**这就是 L1 的代码落地。** **⚠️ 新增 `waiting_period` 是唯一例外**：允许创建 `order`，但该 `order` 生成的 `record` **标记 `is_prepaid=1`**，**不计入结算池**（`billable=0`）。**L1 拒绝逻辑不变，只是把等待期从"一律拒"改为"允许但隔离"。**

**工单状态 `order.order_status`（八态）**：`to_assign`（待派单）／`assigned`（已派单）／`serving`（服务中）／`done`（已完成）／`abnormal`（异常）／`cancelled`（已取消）／`overdue`（逾期未做）／**`not_met`（未遇·扑空）**

**留痕状态 `record.record_status`（六态）**：`draft`／`submitted`／`pending_qc`／`passed`／`returned`／`reported`〔二期〕

> **⭐ 2026-10-12 新增字段（供开发建表/改表）**：
> - `record.is_prepaid`（`tinyint(1)` 默认 0）——**垫付台账标记**；为 1 的记录 `billable=0`。
> - `record.is_refused_photo`（`tinyint(1)` 默认 0）——**拒拍/无法拍摄标记**；与 `refuse_photo_reason` 配套（见 §4.5.1）。
> - `record.refuse_photo_reason`（`varchar(50)`）——拒拍原因枚举（见 §4.5.1）。
> - `order.not_met_reason`（`varchar(50)`）——扑空原因枚举；`order.not_met_at`（`datetime`）到访时间；定位沿用签到定位字段。
> - `elder.prev_loc_code`（`varchar(20)`）——**跨统筹区转移前的参保地**，用于"转移中"态展示与目录切换预览。
> - `elder.transfer_confirm_at`（`datetime`）——转移确认时间（人工确认后写入）。
> - `elder_svc.care_mode`（`varchar(20)`）——**个人项目库护理方式键**（R10，换方式＝重制库）。
> - `elder_svc.is_active`（`tinyint(1)` 默认 1）——个人项目库启用状态（软停用不物理删）。

---

## 八、接口契约

> **三端（APP／后台／家属端）共用同一套后端接口。** 本节定义**语义契约**（谁调、传什么、返什么、什么情况拒），不定义传输协议细节。
> **统一响应结构**（所有接口）：

```json
{
  "code": 0,              // 0=成功；非0=失败（见 8.1）
  "message": "成功",       // 面向开发；错误时给可读原因
  "data": { },            // 业务数据
  "hint": ""              // ⚠️ 面向用户的"怎么解"提示（硬锁拒绝时必须返回）
}
```

### 8.1 统一错误码表

| code | 含义 | 前端处置 |
|:---:|---|---|
| `0` | 成功 | — |
| `1001` | **无有效待遇，不可服务**（L1） | 显示 `hint`，禁止进入服务页 |
| `1002` | **无有效计划，不可派单**（L2） | 引导"先制定计划" |
| `1003` | **无有效工单，不可录痕**（L3） | 拒绝提交 |
| `1004` | **留痕不完整，不可进上报池**（L4） | 列出缺什么 |
| `1005` | **未质控放行，不可上报**（L5） | 提示先质控 |
| `1006` | **资质不匹配（本期仅提示，不拦截）**（L6） | **仅提示，允许继续** |
| `2001` | 派单时间冲突（同人同时段重叠） | **硬拒**，提示换人或改时 |
| `2002` | 计划项目数不满足属地规则 | **仅提示**，可保存 |
| `3001` | 必拍项未拍照，不可签退 | 硬拒，引导拍照；**提供【无法拍摄？】出路**（见 §4.5.1，选原因即放行） |
| `3002` | 定位失败（**非错误，仅标记**） | 允许提交 |
| `3003` | **未遇（扑空）已登记**（非错误，状态变更） | 工单转 `not_met`，推组长决策 |
| `3004` | **垫付期记录不可计费**（非错误，仅标记） | `billable=0`，允许提交 |
| `4001` | 越权：非本机构/非本人数据；**或"自审自放行"**（同一账号录入的记录不得由本人质控放行，见 §3.4.1 补充 2） | 403 |

> **⚠️ `1006` 的设计是刻意的**：**资质校验本期返回"提示级"而不是"拒绝级"**。这样**二期只需把 `1006` 从"提示"改成"硬拒"**，前端代码基本不用动——**这就是"预留位"在接口层的价值**。

### 8.2 本期接口清单（40+ 接口）

**A · 待遇档案（①）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/elder/create` | POST | 新建老人档案 | 建档时限倒计时；`loc_code` 必填 |
| `/elder/detail` | GET | 档案详情 | 权限：本机构 |
| `/elder/status/change` | POST | **变更待遇状态** | **`change_reason` 必填**；写 `elder_status_log` |
| `/elder/status/log` | GET | 状态变更历史 | 只读 |
| `/elder/list` | GET | 老人列表（后台 B1） | 支持按状态/等级筛 |

**B · 服务计划（②）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/plan/create` | POST | 制定计划 | **项目数按属地规则校验**（`2002` 提示级） |
| `/plan/change` | POST | **变更计划（新建＋指向旧）** | **不原地改**；旧计划转 `changed` |
| `/plan/detail` | GET | 计划详情 | 含 `item_list` |
| `/plan/confirm` | POST | 老人/家属确认 | 可选 |
| `/svc/local/list` | GET | **按参保地加载属地目录** | 昆明→45项；州市→36项 |
| `/svc/org/list` | GET | 机构项目库 | — |
| `/svc/org/config` | POST | 勾选＋配价 | **只允许改 `is_enabled`/`price`** |
| `/svc/org/new-national` | GET | **国家新增项列表** | 昆明机构**必须显式展示** |

**C · 老人个人项目库（R10）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/elder-svc/list` | GET | 某老人的个人项目库 | 权限：本机构 |
| `/elder-svc/save` | POST | 增删个人项目库（整表覆盖） | **`svc_id` 必须落在本机构 `svc_org` 内**；`care_mode` 变更＝重制（旧库留档）；写操作日志 |

**C · 派单工单（③）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/order/generate` | POST | 由计划生成工单 | **L2**：无计划拒绝 |
| `/order/assign` | POST | 派单 | **L1**：待遇非 `active` 拒绝；`2001` 时间冲突硬拒；`1006` 资质提示 |
| `/order/reassign` | POST | 调单 | 记 `reschedule_log`；**≤3 步** |
| `/order/batch-recommend` | GET | 批量推荐 | **仅返回推荐，必须人工确认** |
| `/order/today` | GET | 护理员今日任务（M1） | 仅本人 |
| `/order/cancel` | POST | 取消工单 | `cancel_reason` 必填 |
| `/order/detail` | GET | 工单详情（M4） | 含**注意事项区块** |

**D · 履约留痕（③）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/record/checkin` | POST | 签到 | **服务器取时间**；定位失败不阻塞（`3002`） |
| `/record/item/save` | POST | 保存项目执行 | `exec_result` 枚举 |
| `/record/photo/upload` | POST | 上传照片 | **压缩校验 ≤500KB**；返回 `photo_id` |
| `/record/checkout` | POST | 签退提交 | **必拍未拍拒绝**（`3001`）；计算时长 |
| `/record/offline/sync` | POST | **离线补传** | `client_md5` 去重；**静默不弹窗** |
| `/record/detail` | GET | 留痕详情 | — |
| `/abnormal/report` | POST | **异常上报** | 仅 `abnormal_type` 必填 |
| `/abnormal/list` | GET | 异常列表（后台 B4） | 主动推送来源 |

**E · 质控闸门（④）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/qc/pending/list` | GET | 待质控列表（含主动推送） | **全量**，非抽检 |
| `/qc/detail` | GET | 质控详情 | 含留痕全文与照片 |
| `/qc/pass` | POST | 放行 | 写 `qc_result=passed`、`pass_time` |
| `/qc/return` | POST | 退回 | **`qc_note` 必填** |
| `/qc/exception/link` | POST | **异常联动改计划** | 生成新 `plan_id` 并回填 `link_plan_change` |

**F · 家属端（③）**

| 接口 | 方法 | 说明 | 关键校验 |
|---|---|---|---|
| `/family/bind` | POST | 绑定（姓名＋手机号后4位） | **只看自家** |
| `/family/elder` | GET | 我家老人信息 | 过滤 `visible_to_family` |
| `/family/records` | GET | 服务记录列表 | **不返回价格字段** |
| `/family/ack` | POST | **可选确认** | **非必做，不记录"未确认"为异常** |
| `/family/feedback` | POST | 反馈 | — |

### 8.3 硬锁在接口层的落点总表（L1–L6）

| 锁 | 接口 | 触发条件 | 结果 |
|---|---|---|---|
| **L1** | `/order/assign`、`/record/checkin` | `elder.treat_status ≠ active` | `1001` **拒绝** |
| **L2** | `/order/generate` | 无 `plan_status=active` 的计划 | `1002` **拒绝** |
| **L3** | `/record/*` | 无有效 `order` | `1003` **拒绝** |
| **L4** | `/qc/pass` | 留痕缺必填要素 | `1004` **拒绝** |
| **L5** | `/report/*`〔二期〕 | 无 `qc_result=passed` | `1005` **拒绝** |
| **L6** | `/order/assign` | `staff.cert_status ≠ valid` | `1006` **仅提示，不拒绝**（**二期改硬拒**） |

### 8.4 ⭐ 二期预留位落地对照（R1–R6，逐项核对）

> **本节证明"只加不改"是可验证的**——二期每项功能，都能在本期表结构里找到它要用的字段。

| # | 二期功能 | 本期已建的字段/表 | 二期要新增的 | **要改的** |
|:---:|---|---|---|---|
| **R1** | 结算对账 | `order.billable`／`price_snapshot`／`settle_period`；`svc_org.price` | `settlement` 表、申报页、导出格式 | **无** |
| **R2** | 资质人员 | `staff.cert_*` 五字段；`order.qualification_check` | 到期提醒任务、禁派逻辑、资质管理页 | **无**（`1006` 改硬拒属逻辑开关） |
| **R3** | 院长看板 | 数据层可直接聚合现有表 | 聚合视图、图表页 | **无** |
| **R4** | 上报池与接口 | `report` 表；`order`/`plan_item` 的 `official_no`/`loc_code`/代码快照 | 适配层实现、上报页 | **无** |
| **R5** | 医保状态同步 | `elder.status_source` | 接口实现 | **无**（只改字段值来源） |
| **R6** | 异常费用 | `order.exception_flag`／`exception_reason`／`handle_deadline` | 异常处理页、超时提醒 | **无** |
| **R8** | 多业务线 | `elder.biz_line`／`order.biz_line`／`svc_org.biz_line`／`record.biz_line`（本期恒 `ltci`） | 业务线规则包、分线档案、分线记账 | **无**（本期只留字段，不改逻辑） |

**接口契约层预留**

| 预留项 | 本期定义（写死） | 二期 |
|---|---|---|
| **适配层输入输出格式** | **按国家编码规范定稿**（机构编码 13 位 `LH`+区划+序号、人员编码 14 位 `LN`+区划+序号、**项目代码 17 字符**） | 直接实现 |
| **A/B/C 三档** | A 人工登记／B 文件导入导出【本期】／C 专线前置机【预留】 | 实现 C 档 |
| **错误码 `1006`** | **提示级**（不拦） | 改**拒绝级** |

> **⚠️ 项目代码位数说明**：原写"14 位"系归纳有误。**经专项复核定型为 17 字符**，且**仅内部逻辑推演、未与官方原件对照** ⇒ **正式上报前必须以官方电子版核对**。详见《20261011-国家36项代码复核报告》。**字段长度一律按 `varchar(20)` 设计，留余量。**

---

## 九、数据安全与留痕（合规条款的工程落地）

> 这一节不是"技术选型"，是**政策明文要求在本系统的落地方式**。

| 要求（政策） | 工程实现 |
|---|---|
| **一人一档** | `elder` 表 ＋ 全链路 `elder_id` 外键，`order`/`record`/`qc` 均可回溯到人 |
| **实名制管理** | `staff.id_card_no` 加密存储、唯一约束；`user` 绑定 `staff_id` |
| **不可伪造/变造** | ①`checkin/checkout` 服务器取时；②`elder_status_log` 必填原因；③`record` 软删除不物理删；④`client_md5` 防重复提交 |
| **记录与计划/数据/考勤相吻合** | `plan_item` → `order.item_list` → `record_item` **三级快照一致** |
| **材料调取** | 全表导出接口，按老人/时间段/项目导出，**导出即合规版式** |
| **数据保留** | 照片 `keep_until`（补传后 ≥7 天），业务数据软删除保留 |
| **隐私号** | 家属端接口**一律不返回护理员真实手机号** |

> **⚠️ 一条容易忽略的工程纪律**：**`record` 与 `qc` 表一律软删除**——`is_deleted` 置 1，**原始记录永久保留**。
> **理由**：长护险数据是**基金支付凭证**。若允许物理删除，"事后删记录"就变成可能。**软删除＝"不可无痕修改"的最后一道工程防线。**

---

## 十、验收条款

### 10.1 12 条易用性硬指标（**验收圣经**，每个页面都要回指）

| # | 硬指标 | 验收方式 | 本期 |
|:---:|---|---|:---:|
| 1 | 完成一次服务记录 **≤4 次点击** | 计数验收 | ✅ |
| 2 | **必填自由文本 = 0** | 走查 | ✅ |
| 3 | **离线可用＋自动补传** | 断网实测 | ✅ |
| 4 | 关键字号 **≥20pt**、不做多层菜单 | 走查 | ✅ |
| 5 | **首屏即任务** | 走查 | ✅ |
| 6 | **误操作可撤销**、录错不直接扣钱 | 功能验收 | ✅ |
| 7 | 组长**调单 ≤3 步**、不比微信群慢 | 计时验收 | ✅ |
| 8 | **异常主动推送** | 触发验证 | ✅ |
| 9 | **导出即合规版式** | 导出比对国家 2026 版文书 | ✅ |
| 10 | 院长看板**只放三块** | 走查 | **〔二期〕** |
| 11 | 家属端**零任务** | 走查 | ✅ |
| 12 | **最小必要留痕** | 规则验收 | ✅ |

> **本期验收 11 条**（第 10 条随院长看板延至二期）。

**验收方式定义（避免扯皮）**

| 方式 | 具体做法 |
|---|---|
| **计数验收** | 真人从"打开 APP"到"提交一次服务记录"，**实际点击数 ≤4** |
| **走查验收** | 逐屏人工检查，打勾确认 |
| **断网实测** | 飞行模式下完成一次完整服务记录，联网后确认自动补传成功 |
| **计时验收** | 同一调单操作，"微信群沟通"与"系统操作"各计时，系统**不得更慢** |
| **规则验收** | 构造规则用例（高风险项不拍照能否提交／日常项不拍照能否提交） |

### 10.2 分端专项验收

**护理员 APP 端**

| # | 条款 | 验收方式 |
|:---:|---|---|
| 1 | ≤4 击（常态预勾选时为 3 击） | 实测 |
| 2 | M2/M3 **无任何必填文本输入框** | 走查 |
| 3 | 飞行模式下完成完整服务记录；联网自动补传 | 断网实测 |
| 4 | 正文 ≥20pt；**页面层级 ≤2** | 走查 |
| 5 | 打开 APP **直接进 M1**，登录态保持 | 走查 |
| 6 | 误点签退 → **10 秒内可撤销** | 功能验收 |
| 12 | 必拍档未拍照 → 不可签退；免拍档未拍照 → **可正常签退** | 规则验收 |
| **A1** | **新用户 10 分钟内独立完成一次记录**（不给培训、只给手机） | 真人实测（**本端最硬的一条**） |
| A2 | 住院状态老人卡片置灰且不可开始 | 构造用例 |
| A3 | 定位失败不阻塞签到 | 关闭定位权限实测 |
| A4 | 照片本地压缩后单张 ≤500KB | 技术验收 |
| A5 | 异常上报全程 ≤30 秒（不含拍照） | 计时验收 |

> **⭐ A1 说明**：**如果新护理员需要培训才会用，说明设计失败了**。建议上线前找**未接触过系统的真实护理员**实测。

**机构后台端**

| # | 条款 | 方式 |
|:---:|---|---|
| 7 | 从点卡片到改派生效 **≤3 步**；与微信群计时对比**不更慢** | 实测 |
| 8 | 护理员提交异常 → **组长/质控员 10 秒内**收到推送 | 触发验证 |
| 9 | 导出档案 → 逐项比对**国家 2026 版文书**格式 | 走查 |
| 6 | 调单可撤销；放行可撤回（**限时 10 分钟内**） | 功能验收 |
| B1 | **登录后 1 屏内看到"待我处理"事项** | 走查 |
| B2 | 本期不出现的功能**在导航中完全不存在**（不是置灰） | 走查 |
| B3 | 一级护理显示为"一级护理（最高级）" | 走查 |
| B4 | 昆明机构登录可见"国家新增项"区块 | 构造用例（以昆明属地登录） |
| B5 | 州市机构登录**只看到 36 项**、无映射提示 | 构造用例 |
| B6 | 计划项目数不满足属地规则 → **不可提交** | 构造用例 |
| B7 | 留痕记录**不可直接改**，只能补正且保留原值 | 技术验收 |
| B8 | **老人个人项目库**：项目只能从本机构 L4 选；`care_mode` 变更＝重制（旧库只读留档）；制定计划可"一键带入"且可改 | 构造用例＋技术验收 |

**家属端**

| # | 条款 | 方式 |
|:---:|---|---|
| 11 | **无任何"必须完成"的交互**；"知道啦"默认不勾选、可跳过；界面显式写"不点也没关系" | 走查 |
| 4 | 字号 ≥20pt（**家属中含老年人，字号尤其重要**） | 走查 |
| F1 | **绑定成功率**：模拟 20 位家属，**≥18 位一次成功** | 真人实测 |
| F2 | 家属**看不到非关联老人**（换绑测试、URL 手工改参测试） | 安全验收 |
| F3 | 照片**默认不可见** | 走查 |
| F4 | 家属端**任何页面均无价格/金额字样** | 走查（搜"元""费用""限额"零命中） |
| F5 | 家属端**无评分/星级组件** | 走查 |
| F6 | 反馈提交后**机构端 10 秒内可见** | 触发验证 |
| F7 | 措辞检查：**"未做""迟到""缺勤""监督""举报"零命中** | 走查 |

---

## 十一、不做什么（写死，防后续加需求）

### 11.1 全系统不做的（红线）

| 不做 | 理由 |
|---|---|
| 做评估机构 | 不参与失能等级评估、不出评估结论 |
| 碰基金资金 | 不经手长护基金、不做资金池 |
| 替代官方系统 | 官方 APP／省平台是"只对接"，不替代 |
| 卖老人数据 | 平台不对外提供老人原始数据 |
| 承诺结果 | 不承诺遴选通过、不承诺巡查得分、不承诺不被罚 |
| 用广告法禁用词 | 不用"最／第一／国家级"等 |

### 11.2 护理员 APP 不做的

| 不做 | 理由 |
|---|---|
| 打字录入 | 与"必填自由文本 = 0"矛盾 |
| 排班/调班 | 属组长职责，APP 上做会乱 |
| 查看/修改服务计划 | 属质控职责；**防一线改计划绕过合规** |
| 统计报表、排行榜 | 与"干活现场"无关，且评比诱发造假 |
| 家属沟通功能 | 隐私号转接由机构侧统一处理 |
| 服务评价（护理员评老人） | **伦理风险**，坚决不做 |
| 积分、勋章、打卡日历 | 把照护变成游戏，**方向错** |
| 支付/收款相关 | 本期无结算，且平台不碰资金 |

### 11.3 机构后台不做的

| 不做 | 理由 |
|---|---|
| 院长看板（B0） | 二期；**本期不做空首页** |
| 结算对账（B5） | 二期 |
| 人员资质管理（B6） | 二期；本期**只在排班时提示** |
| 自动派单（无人确认） | 出错无法归属责任 |
| 抽检式质控 | 机构质控必须全量 |
| 自定义服务项目 | 合规红线 |
| 属地自助切换 | 属重新配置 |
| 员工绩效排名 | 评比诱发造假，且与长护合规无关 |
| "迎检"类功能与话术 | 措辞纪律 |

### 11.4 家属端不做的

| 不做 | 理由 |
|---|---|
| 每日打卡/签到 | **核心红线**（已有反面案例） |
| 强制确认 | 同上 |
| 星级评分 | 诱发摆拍与讨好，且不真实 |
| 费用/账单展示 | 家属端不涉及钱 |
| 在线支付 | 平台不碰资金 |
| 展示护理员手机号 | 隐私号原则 |
| 医疗建议 | 合规红线 |
| 展示异常细节 | 避免过度焦虑 |
| 替代官方渠道 | 不做评估申请、待遇查询入口 |
| 家属上传照片/视频 | 与"零任务"矛盾，且涉隐私 |

---

## 十二、遗留待确认（**均不阻塞开发**）

| # | 事项 | 影响 | 处置 |
|:---:|---|---|---|
| 1 | 各州市实施细则是否另行细化服务项目 | 属地目录库内容 | 签约前逐一核实；**推定不影响结构** |
| 2 | 昆明 45 项是否已更新 | 属地目录库内容 | 建议 0871-65919196 核实 |
| 3 | ⚠️ **国家项目代码须官方电子版最终确认** | 二期上报准确性 | **仅影响二期上报**（P0 不含上报）；字段已按 `varchar(20)` 留余量 |
| 4 | 照片**保留期限**（政策要求 vs 机构成本） | 存储策略 | 有地方要求"保存 10 年"；**按属地要求配置化，不当统一硬编码** |
| 5 | 派单推荐权重、质控提醒阈值 | 配置值 | **已有默认值，可直接开发**；走访后只改配置、不改代码 |

> **⚠️ 处理原则**：**这 5 项都不阻塞 P0 开发**——前 4 项是"数据内容"和"配置值"，不是"结构"。**唯第 3 项须在真正对接上报前收口**（属二期）。

---

## 十三、⭐ 本轮质疑回填记录（2026-10-12）

> **本节回答一件事**：机构老板的 22 条质疑里，**哪些我们改了 PRD（能改就改）、哪些是产品客观做不到（如实说明）。**
> **原则**：**能改的写进需求；做不到的不硬撑。** 本节只记"改了什么"，不重复需求正文。

### 13.1 已改入 PRD 的（产品能做的 —— 已写进需求）

| # | 质疑 | 改动落点 | 性质 |
|:---:|---|---|---|
| **R1** | Q7 等待期 6 个月空窗，服务"录不进" | **新增 `待起付（等待期）` 态**（§3.2）＋**垫付台账与结转**（§5.5.1 B1-A）＋字段 `is_prepaid`（§7.4） | 能改，已改 |
| **R2** | Q8 状态颗粒度不够（复评中/跨市搬家/住院回来） | **新增 `复评等待期`、`跨统筹区转移中` 两态**，**`住院暂停` 补"恢复"出路**（§3.2、§7.4），状态由七态 → **十态** | 能改，已改 |
| **R3** | Q12 临时加单/取消/**白跑一趟**无佐证 | **新增工单态 `未遇（扑空）`**（§3.2）＋**异常上报子形态**（§4.9.1）＋字段 `not_met_reason/not_met_at`（§7.4） | 能改，已改 |
| **R4** | Q13 必拍项**只有"拍"一条路**，不让拍就卡死 | **新增拒拍出路**（§4.5.1）：选原因即放行＋`is_refused_photo` 标记 + `3001` 出口 | 能改，已改 |
| **R5** | Q14 拍照分档**依据谁**、属地不一致怎么办 | **明示"默认值须属地核对"**＋**属地核对清单**（§4.5.2）；分档本就可配置（§4.5 纪律 2） | 能改，已明示 |
| **R6** | Q17 几百人资料**谁录** | **参保人/护理员/项目配价 Excel 批量导入**（§5.5.1 B1-B） | 能改，已改 |
| **R7** | Q2 等级变动联动 | **`跨统筹区转移中`/`复评等待期` 均绑"重制计划"动作**；限额联动属二期院长看板 | 部分改，已改骨架 |
| **R8** | 机构不止长护险业务 | **多业务线预留 `biz_line`**（§7.3.1）：本期恒 `ltci`，只留字段不动逻辑 | 能改，已留口子 |
| **R9** | 履约留痕**身份核验**怎么做 | **PRD 现无身份核验机制（缺口）**：谁在现场、是不是本人，需补"扫脸/人证一致/签字"三类核验方式与字段（见下表 ⚠️ 待补） | ⚠️ 缺口，待补 |
| **R10** | 目录能否**按老人维度**适配（双线机构诉求） | **新增 `elder_svc` 老人个人项目库**（§5.5.2 B1-C）＋`elder_svc` 表（§7.2，**22→23 表**）＋2 字段（§7.4）＋2 接口（§8.2 C）＋验收 B8（§10.2）。**床位线明确 P0 不做**，仅保留 `bed_count` 备案数占位 | 能改，已改 |
| **R11** | 居家护理六流程与 PRD 字段缺位对齐（2026-10-14） | **只补字段、不做功能**：①`record.biz_line`（R8 三表→四表）②`elder.insur_years`/`insur_verify_status`/`insur_verify_date`/`need_assess` ③`plan.plan_basis` ④`settlement.amount_fund`/`amount_self_pay`。**自费服务（收款/同意凭证）本期不做、只留字段** | 能改，已补字段 |

> **说明**：**R1–R6 全部为"设计已定"，开发排期须按此更新**（此前 `开发排期与模块拆分（第5步）` 未含这 6 项，须回填工时）。**R9 为新增待补项，尚未进需求正文**——待确认后补入 §4.5（履约留痕拍照）＋§7.4（字段）＋验收指标。

### 13.2 产品客观做不到的（如实说明，不硬撑）

| # | 质疑 | 为什么做不到 | 对客正确表述 |
|:---:|---|---|---|
| **N1** | Q3 昆明/省级**接口何时发**、时间表 | **接口规范发布权在统筹区经办机构**，非我方可控；昆明在省级平台（易联众建） | "**具备按医保部门统一接口规范对接的条件**"，**不给日期、不说"已接通"** |
| **N2** | Q6 **备案价**来源口径 | `昆医保通〔2025〕27号` 提三价一致，但**备案价取值口径未获公开原文** | "**备案价口径须回官方原件核实**"；系统侧只做三价不一致拦截 |
| **N3** | Q10 **昆明经办认不认**"补正" | **行政认可与否由经办机构定**，非产品能力 | "系统侧原值永久保留、只增更正说明"；**认不认须与医保核** |
| **N4** | Q11 昆明**认不认国家 2026 版文书** | 同上，**属地采纳权在医保** | "导出模板可按国家文书双向适配"；**采纳与否须核** |
| **N5** | Q4 **等保备案 / 公司存续** | **公司资质与商务层面事项**，非产品模块 | 由公司另出**书面材料**，产品文档不代答 |
| **N6** | Q15 昆明**逐项计价口径** | 属属地政策，未获逐项原文 | 系统只算时长、**不参与报账**；计价口径须核 |
| **N7** | Q20 **有上线客户吗** | **没有就是没有** | **如实说**：首个客户（玉溪自红）在实施阶段；用**对冲包**补信任（见 §14.3） |
| **N8** | Q19/Q21/Q22 报价/SLA/退出条款 | **商务决策**，不是产品能力 | 由商务出**书面条款**，产品文档不代答 |

> **⭐ 一句话**：**上表 8 条不是"我们没做"，是"这事不由我方单方面定"。** 对客时**如实说"这部分要一起找医保/由公司出材料"**，比硬答更可信。

### 13.2b ⭐ 待补清单（已识别缺口 · 尚未进需求正文）

> **本节回答一件事**：哪些是"产品能做、但当前 PRD 还没定义"的缺口。**待补 ≠ 做不到**，是**尚未设计、留待确认后补入**。补入后移出本节。

| # | 缺口 | 现状 | 待补内容（确认后补入 §4.5 / §7.4 / 验收） |
|:---:|---|---|---|
| **P-9** | **履约留痕·身份核验** | 现有 PRD **只有"拍照留痕"，没有"谁在现场、是不是本人"的核验机制** | 三选一或组合：①**扫脸核验**（护理员/老人人脸比对，需第三方识别或医保 APP 能力）；②**人证一致**（身份证号＋姓名比对＋签字）；③**签字确认**（护理员＋老人/家属电子签名）。须补字段：核验方式、核验结果、核验时间、经办人，并明确**无网络/老人无法扫脸的兜底**（如家属代签＋拍照佐证）。**注意：是否可调用医保 APP 扫脸，须与统筹区经办机构确认，非我方可自行定** |

> **原则**：**P-9 是"待补"不是"已做"**。对客表述＝"**身份核验的落地方式，正在与医保/机构确认核验手段**"，**不得说"已实现扫脸"**。

### 13.3 需商务/公司配合出书面材料的（产品侧无法单独收口）

| # | 事项 | 归属 | 建议动作 |
|:---:|---|---|---|
| **B-1** | **首个客户对冲包**（POC 试运行 / 首年实施费减免 / 达标付费） | 商务 | 三选一或组合，**写进报价与合同** |
| **B-2** | **等保备案现状、公司后续维护存续** | 公司 | 出**书面承诺/资质说明** |
| **B-3** | **SLA、驻场、响应时限、退款、试用期数据条款** | 商务 | 写入**服务合同附件** |
| **B-4** | **拍照分档属地核对**（§4.5.2） | 实施 | 列入**签约前必办清单**，双方签字 |

---

## 十四、对客边界说明（**六条，逐字可用**）

1. **首期范围**：本期交付**待遇档案／派单工单／履约留痕／质控闸门**四块；**结算对账、人员资质、院长看板为二期**。
2. **资质校验**：**"无资质不派单"是政策要求，但资质库在二期**。首期＝**人工登记＋派单时提示**，**不是自动禁派**。
3. **医保状态同步**：首期**不做自动同步**。状态**由机构人工维护**，系统只能"提醒该核状态＋录后拦派单"，**不能替你发现状态变化**。
4. **接口对接**：首期按**"人工登记＋文件导入导出"**设计，**预留专线口**。**不得表述为"已接通医保系统"**——正确表述是"**具备按医保部门统一接口规范对接的条件**"。
   > **背景事实（昆明现状，写死）**：昆明长护险信息系统已于 **2025-01-01 切换到云南省医疗保障信息平台**，定点护理机构的护理员是**直接用「云南医保服务平台」APP 手工录入**服务数据（签到/签退、扫脸、定位、拍照、**服务项目与时长明细**）。**系统只自动算开始/结束时间，项目明细靠护理员护理完成后手工选择、手工录入**，机构须 **T+2 内**上传。⇒ **这不是"系统间自动传递"，而是"护理员在医保 APP 上人肉录入"**。故我方系统 P0 **不接医保直连、不自动同步评估/服务数据**，是符合昆明现行事实的正确边界，**不得误设计成"自动同步医保数据"的接口**。
5. **结算数据**：首期**不自动生成结算申报数据**；服务记录可导出，**申报仍按现行方式人工办理**。
6. **巡查与评分**：本系统只做**日常留痕与国家文书查阅项对照**，**不预测巡查评分、不承诺合格**；判定权在统筹地区医疗保障经办机构。
7. **本轮新增能力（2026-10-12）**：**等待期垫付台账、十态待遇状态、扑空登记、拒拍出路、批量导入**等，均为**"需求已写定、开发中"**；**对客不得表述为"现已上线可验收"**。
8. **身份核验（2026-10-12 新增待补）**：**首期不承诺"扫脸/人证识别"**。系统当前只做**拍照留痕**，**"谁在现场、是不是本人"的核验机制仍在确认中**。对客正确表述＝"**身份核验的落地方式正在与医保/机构确认**"，**不得说"已实现扫脸核验"**。

---

**云南投云科技有限公司**
编制：滇小构｜2026-10-11（P0 PRD · 交付开发版 · V1）｜2026-10-12 按 22 条质疑回填修订｜2026-10-14 居家护理六流程字段对齐（只补字段）