16 KiB
16 KiB
信息采集需求对照审计
审计日期：2026-10-08。范围：当前后台老人七步、志愿者/家属自身档案登记与家庭关联。依据为导师三份说明，同时保留用户后续明确要求。
结论
七步核心资料表单及保存机制已经完成，但当前实现尚不等于导师文档中的完整信息采集业务闭环。本轮美化志愿者、家属登记和家庭关联，并修正下列实际问题；没有把未实现的OCR、签名、低龄例外、代录入口和初筛误写为已完成。
本轮修正：未确认同意前的敏感输入/草稿上传与回读、列表及只读号码显示、草稿网络恢复重试与关闭保护、民族拼音排序、配偶确认时点旧文案。
逐项对照
| 文档要求 | 当前状态 | 实際行为与差异 | 代码证据 |
|---|---|---|---|
| 《老人基本信息采集》§三、§四七步字段 | 已实现 | 管理员老人七步的核心字段、必填、选填、联动、最终统一提交均落地。残疾、慢病、父母隐藏字段会清除。 | 七步定义；服务端校验 |
| 《老人基本信息采集》§5.5草稿与进度 | 已实现主体，部分差异 | 按管理员/租户/老人保存加密草稿，1～7步恢复；每步保存的是草稿，正式档案最后提交。当前没有个人中心进度入口。 | 草稿与恢复 |
| 《老人基本信息采集》§1.3、§六同意前只采基础资料 | 本轮修复表单/草稿；正式旧接口仍有残余 | 未确认时禁填身份证、生日、民族、微信；前后端草稿仅保留姓名、性别、联系方式、账号基础资料。旧未确认草稿回读也过滤。旧正式步骤1/2接口为兼容仍可写含身份证资料，尚非所有接口的签署门控。 | 输入限制；草稿过滤；旧正式接口 |
| 《老人基本信息采集》§1.3、§5.3知情同意签署 | 部分实现 | 目前是采集人员勾选确认、服务端记确认人/时间；没有同意书版本、签名凭证、授权代理证明、撤回流程，不能等同于文档“consent_status=已签署”。 | 确认记录 |
| 《老人基本信息采集》步骤1身份证OCR | 未实现 | 身份证字符串校验可解析生日和性别；没有扫描上传/相机/OCR，姓名、籍贯不会由号码自动识别。 | 号码解析 |
| 《老人基本信息采集》步骤1低龄例外 | 未实现 | 当前低于60岁一律拦截；没有管理员强制录入、原因日志及特殊老人入口。specialCase保留字段不代表功能完成。 | 年龄拦截 |
| 《老人基本信息采集》步骤1唯一性、§六重复建档提示 | 校验已实现，体验部分 | 服务器校验重复身份证且有唯一索引。直到最终提交才检查，未提供“已建档，查看已有档案”入口。并发碰唯一键的错误理由可能仍泛化为账号已建身份。 | 唯一性；并发错误 |
| 《老人基本信息采集》步骤2海拔 | 查询已实现，数据未齐 | 有区划海拔接口/只读显示；没有完整已核实数据集，缺失提示不虚构0米。完整海拔效果仍需导师提供数据/来源。 | 海拔显示 |
| 《老人基本信息采集》步骤2配偶识别 | 已实现核实关联，提交时点有调整 | 同址已婚线索由人核实，最终第七步提交后另请求关联。本轮改正“保存第二步”旧提示。配偶确认与资料保存非同一事务，确认失败会提示再次核实。 | 候选与提示；实际确认时点 |
| 《老人基本信息采集》步骤7联系人 | 基础采集已实现，权限部分暂缓 | 至少1、最多10人；恰好1位第一联系人、姓名/关系/手机号必填、号码去重。统一仅紧急联系，不检测已注册家属、开通管理权限或创建影子成员。 | 联系人界面；仅联系人用途 |
| 《老人基本信息采集》§5.1独居派生 | 未独立实现 | 保存livingStatus=1可表示独居，但未提供文档is_living_alone独立派生字段或统一派生响应。 | 居住状况 |
| 《老人基本信息采集》§5.2采集人 | 管理员已实现 | 记录采集管理员、类型4、最近采集时间、首次完成时间；并未实现老人本人/家属/志愿者的采集入口及来源记录。 | 服务端写采集人 |
| 《老人基本信息采集》§5.1采集过程日志 | 部分 | 有采集元信息和访问日志保护，缺独立事件记录（采集方式、恢复、跳过、提交过程）。不把普通访问日志当作完整采集日志。 | 审计元信息 |
| 《老人基本信息采集》§5.3～§5.4初筛衔接及完成页 | 未实现完整闭环 | 提交后成功提示、关闭并刷新列表。没有签署引导、完整七模块总结页、初筛任务/五题页面和自动跳转。初筛是独立模块，不是七步资料采集本身。 | 提交后行为 |
| 《老人基本信息采集》§1.1～§1.2多角色代录 | 未实现角色端 | 当前是后台管理员创建三种身份的档案；志愿者/家属自身登记≠该角色替老人采集。家属添加老人、志愿者协助采集、老人本人完善资料入口和字段级权限尚无。 | 目标身份枚举；当前权限 |
| 《老人基本信息采集》§2.1～§2.3展示模式 | 按用户要求调整 | 文档管理员默认flat、查看view平铺、可切模式；现管理员老人新建/编辑强制step，查看也逐步。因用户明确要求，保持现设计，不当作bug回改。老人single一屏一题仍未实现。 | 当前逐步逻辑 |
| 《老人基本信息采集》步骤4自动跳页 | 有意调整 | 文档选自理/非残疾后直接进入下一步；现只联动清理，用户点击下一步。符合此前平滑、强制逐步确认的要求，保留手动继续。 | 照护联动 |
| 《老人基本信息采集》§六网络中断 | 本轮修复重试，部分 | 草稿读取失败恢复网络后可原地重试，保留当前输入；点击关闭保存失败会保持表单打开。浏览器强退、刷新或断网后关闭应用仍没有离线持久缓存。 | 原地重试；关闭保护 |
| 总体方案§2.2隐私；UI§13.2脱敏 | 本轮修复显示；存储/接口仍部分 | 列表及只读身份证/手机号/医保号已掩码，编辑可核对原值。身份证、医保、新联系人和草稿加密；contactPhone/旧emergencyPhone/member.mobile仍明文。列表接口仍返回全量敏感资料，显示遮挡不等于接口最小化。 | 显示遮罩；全量列表 |
| 总体方案§2.1、§2.2敏感查询载体 | 仍有差异 | 配偶候选查询用GET参数携带详细家庭地址，与总体方案禁止敏感资料进URL不一致。正式修正需协调查询接口，不把日志隐藏当成URL载体已修复。 | 候选请求 |
| 总体方案§22排序、字典维护 | 本轮修复民族排序；其余部分 | 民族、职业、区划在前端按拼音呈现。没有完整后端统一字典与sort_order；志愿者技能是文本而非标签字典；残疾选项目前按固定类别顺序。 | 民族字典；志愿者技能 |
| UI§6.8志愿者资质 | 未实现 | 本次登记已美化基本资料、技能、区域、时间、经验和审核状态；身份证/健康证/无犯罪记录证明上传与资质到期处理仍未实现。 | 志愿者服务卡片 |
| UI§5.1、§5.5家属端和家庭组 | 现有后台关联，部分 | 本次美化家属档案及后台关联页，有申请/核实/拒绝/解除/重新申请。没有家属移动首页、家庭组主管理员/普通成员/只读角色、代管工作台。 | 关联流程 |
| 《老人基本信息采集》§5.1具体数据库表 | 存储结构有调整 | 慢病及多联系人采用老人档案中的AES加密结构化JSON，并非独立elder_chronic_disease/family_member表；接口字段完整，但查询统计、跨系统迁移与表名不能宣称按文档逐字一致。 | 加密JSON存储 |
需要继续开发的优先顺序
- 统一知情同意与隐私边界：真正同意书/签署状态、正式旧接口门控、列表最小响应与受限完整值接口，联系方式加密迁移兼顾账号查找/唯一键，调整敏感地址查询载体。
- 补齐采集业务细节：管理员低龄例外+理由/日志、独居派生、采集事件、重复身份证定位已有档案、统一字典。
- 老人采集完成后的闭环：OCR和电子签署、完成摘要、独立健康初筛。
- 按角色扩展：老人本人一屏一题、家属/志愿者代录字段及对象权限、家属关联/影子成员、志愿者资质。
这份审计提出后续范围，未默认为本轮已授权把全部未实现模块补齐。强制七步、联系人暂不建家属账号是此前用户选择；后续开发时可重新明确这些范围。
文档内部需统一的描述
- §1.3要求签署前只采基础资料，§三和§5.3又描述完整采集后检查签署。应明确“基础预采→同意后完整采集→评估”顺序。
- §三给所有步骤“跳过”按钮，但1/2/4/7有必填。当前仅3/5/6可整步跳过；已有选填输入仍保留并检查格式，跳过不等于无提示删除。
- 步骤7写至少一位第一联系人；当前恰好一位，方便明确联系顺序，是更严格的业务选择。
- 总体方案§22.4同时出现“前端不排序”和“前端localeCompare排序”。当前前端呈现顺序已修，字典维护层仍待统一。
- 收入/婚姻/医保枚举在总体方案与采集说明间不完全一致。当前前后端采用统一协议（如0无收入），导入外部数据需显式映射，不能直接复用另一文档数字。
- 当前管理员ElementPlus页面与40px按钮并非老人移动端Vant/18px字/56px按钮；不能把后台美化等同于老人端适老页面验收。
验证与边界
本轮48项前端、53项健康后端测试全部通过；前后端构建成功，健康接口UP。采集与家庭关联页面定向类型无报错，整仓其他模块仍有原有类型错误。静态检查通过。 浏览器视觉验收因既有浏览权限拒绝未执行；未通过其他浏览器、截图或隐藏页面绕过。本轮无数据库结构变更。