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

149 KiB

Raw Blame History

投云长护险管理系统 · 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 先记住这五条，能少走一半弯路

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

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 ⭐ 五条多属地纪律（写死）

属地差异走配置、不走代码——新增州市＝加一份 L2 配置，不改代码、不发版；
属地项目必须可映射——L2 中每一项都必须在 L3 里有映射；昆明 45 项中无法映射国家的 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         │
        └─────────────┘

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

三条数据铁律：

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

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

硬锁的设计纪律：

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

3.4 角色与权限

角色定义

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

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

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

三条权限原则（写死）：

最小必要——护理员只能看/操作派给自己的任务；
家属只见自家、默认只读；
院长不改数据——院长不设任何数据修改权限（后端在所有写接口上一律返回 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`。为什么：这是"先质控再上报"铁律的底线，不因"小机构人手少"而放宽；机构若只有一人，必须再配一个能审的人（哪怕兼职），否则该记录无法进上报池
院长兼质控时，写接口还 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 次报告
官方自陈	昆明医保局承认护理员"年龄偏大、智能设备操作困难"	昆明市医保局公开材料

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

三条不可协商的原则：

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

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	（可选）备注	一句话描述，可跳过

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

三条设计纪律（写死）：

免拍 ≠ 不留痕——免拍项仍自动记录四要素：签到时间、服务时长、项目清单、语音描述（如有）。四要素齐全即算留痕；
分档可配置——机构可按自身风险偏好调整哪些项必拍。默认按上表，机构可加严、不建议放宽；
照片不为"好看"——不要求老人摆姿势、不要求面对镜头。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 条的实践依据：已有公开报道——某些地区要求家属"每日线上打卡 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	✅	是否启用（软停用不物理删）	【本期】

⚠️ 关键设计（三条，写死）：

elder_svc 只存"做哪些"，plan 只存"怎么做"——前者是长期稳定底表（派单带入源），后者是周期生效的正式安排（频次／时长／拍照档）。两者不互相替代、不重复存规格字段。

项目只能从 L4 选——svc_id 必须落在本机构 svc_org 内，不可自创、不可写机构目录外项目（与 plan_item 同纪律，防"个人项目库"绕开属地合规）。

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

⚠️ 五条多属地纪律在表结构上的落地：

走配置不走代码 → 新增州市＝插一行 loc_config + 一批 svc_local，代码零改动；

必须可映射 → svc_mapping 保证每项可追；map_status = local_only 的项上报时自动排除；

机构不可改目录 → svc_org 只有 is_enabled 和 price 可改，其余只读；

国家新增项显式提示 → is_new_national = 1 的项独立区块显示；

映射表不对外 → 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

⚠️ 三条硬设计（都是合规点）：

签到签退时间、时长一律系统取，接口不接受客户端传入这两个值——防"补录时间"；

定位失败不阻塞提交——老人家里弱网是常态，不能因为定位不到就不让干活；

时长不设"最低时长硬拦"，只记 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 挂"居养管理"。

③ 三条不可越界的线（软件管不了，须靠机构＋规则）：

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

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

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

{
  "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）	实施	列入签约前必办清单，双方签字

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

首期范围：本期交付待遇档案／派单工单／履约留痕／质控闸门四块；结算对账、人员资质、院长看板为二期。
资质校验："无资质不派单"是政策要求，但资质库在二期。首期＝人工登记＋派单时提示，不是自动禁派。
医保状态同步：首期不做自动同步。状态由机构人工维护，系统只能"提醒该核状态＋录后拦派单"，不能替你发现状态变化。
接口对接：首期按**"人工登记＋文件导入导出"**设计，预留专线口。不得表述为"已接通医保系统"——正确表述是"具备按医保部门统一接口规范对接的条件"。

背景事实（昆明现状，写死）：昆明长护险信息系统已于 2025-01-01 切换到云南省医疗保障信息平台，定点护理机构的护理员是直接用「云南医保服务平台」APP 手工录入服务数据（签到/签退、扫脸、定位、拍照、服务项目与时长明细）。系统只自动算开始/结束时间，项目明细靠护理员护理完成后手工选择、手工录入，机构须 T+2 内上传。⇒ 这不是"系统间自动传递"，而是"护理员在医保 APP 上人肉录入"。故我方系统 P0 不接医保直连、不自动同步评估/服务数据，是符合昆明现行事实的正确边界，不得误设计成"自动同步医保数据"的接口。
结算数据：首期不自动生成结算申报数据；服务记录可导出，申报仍按现行方式人工办理。
巡查与评分：本系统只做日常留痕与国家文书查阅项对照，不预测巡查评分、不承诺合格；判定权在统筹地区医疗保障经办机构。
本轮新增能力（2026-10-12）：等待期垫付台账、十态待遇状态、扑空登记、拒拍出路、批量导入等，均为**"需求已写定、开发中"**；对客不得表述为"现已上线可验收"。
身份核验（2026-10-12 新增待补）：首期不承诺"扫脸/人证识别"。系统当前只做拍照留痕，"谁在现场、是不是本人"的核验机制仍在确认中。对客正确表述＝"身份核验的落地方式正在与医保/机构确认"，不得说"已实现扫脸核验"。

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

149 KiB Raw Blame History Unescape Escape