# 智慧医养定期巡访系统 模块规划 --- ## 1. 模块定位 智慧医养定期巡访系统是面向**基层服务人员(巡访员/社工)** 的移动端工作管理系统,负责对辖区内老人进行定期上门巡视,以移动端打卡、照片记录、问卷采集等方式完成巡访任务,并将结果同步至后台供管理人员和监管部门查阅。 本系统的核心用户为外勤工作人员,工作场景以移动端为主,后台管理端为辅。 --- ## 2. 建设目标 1. 实现巡访计划的在线制定与分配,支持按区域/分组/人员多维度排班 2. 提供移动端巡访执行工具(GPS打卡 + 照片上传 + 问卷填写) 3. 构建"百台监管"能力,支持对大量设备/老人的批量巡检管理 4. 实现巡访记录的完整留存与异常上报闭环 5. 提供巡访完成率、覆盖率等统计报表 --- ## 3. 核心功能范围 ### 3.1 一级模块 - 计划制定管理 - 巡访内容配置 - 移动端执行工具 - 百台监管 - 分组管理 - 系统管理 ### 3.2 二级模块 - **计划制定**:巡访周期设置(日/周/月)、责任区域划分、人员分配、老人点位导入 - **巡访内容配置**:巡访问卷模板(生活状况/身体状况/安全检查)、必拍项配置、异常上报触发条件 - **移动端执行**:老人列表展示、GPS到达验证(地理围栏)、拍照/签名、问卷填写、异常标记上报 - **百台监管**:批量设备状态查看、设备异常汇总、设备维护工单 - **分组管理**:巡访小组创建、成员管理、任务分发规则 - **系统管理**:账号权限管理、巡访区域配置、问卷模板管理 ### 3.3 核心功能说明 | 功能 | 描述 | 技术要点 | | ------------ | ------------------------------------------ | ------------------------ | | GPS 打卡验证 | 距老人地址100m内方可开始巡访 | 高德定位API + 地理围栏 | | 照片上传 | 拍照(含水印:时间/位置/人员)并上传 | 移动端相机调用 + OSS存储 | | 问卷填写 | 动态表单,支持文本/单选/多选/评分 | 动态表单引擎 | | 异常上报 | 发现问题时触发工单,流转至呼叫中心或管理员 | 工单引擎 + 推送 | | 百台监管 | 同时查看100+设备/老人的巡访状态汇总 | 分页+状态聚合 | | 巡访统计 | 完成率、超时率、异常率、覆盖率趋势 | 统计服务 + 图表 | --- ## 4. 与现有 mall 的关系 **契合度:D(不适配)** mall 是以交易为核心的电商平台,其骑手模块虽具备移动端签到和轨迹功能,但与本系统存在根本差异: | 能力需求 | mall 骑手模块 | 结论 | | ------------------------- | ------------------------ | -------------------- | | GPS 地理围栏打卡 | 仅有轨迹追踪,无到达验证 | 需新建 | | 动态问卷填写(巡访记录) | 无 | 需新建 | | 照片上传(水印+位置信息) | 无 | 需新建 | | 巡访计划制定与分配 | 无(骑手是被动接单) | 需新建 | | 老人档案关联显示 | 无(无老人实体) | 需新建 | | 异常上报工单流转 | 客服工单(消费纠纷场景) | 业务逻辑不同,需重建 | mall 是通用电商平台,其骑手配送逻辑以订单为驱动;本系统以老人档案和巡访计划为驱动,两者在业务主线上差异显著,强行复用会引入大量冗余电商逻辑。 --- ## 5. 规划判断 **独立系统建设** - 移动端:uni-app(小程序 + H5,巡访员使用工作手机) - 后台管理端:Vue3 Web - 服务端:独立API服务 - 对接数据库系统(02)中的老人档案数据 --- ## 6. 需新增业务能力 1. **地理围栏打卡**:设定每位老人的合法打卡范围,防止虚假签到 2. **动态表单引擎**:支持管理员在线配置巡访问卷,无需发版 3. **照片水印**:自动在照片上叠加 GPS 坐标、时间、巡访员姓名 4. **巡访计划调度**:周期性任务自动生成+分配,支持断点续访(老人外出时改期) 5. **异常上报流转**:严重异常(独居老人无应答、设备损坏)自动触发呼叫中心告警 6. **离线支持**:弱网环境下数据本地缓存,网络恢复后自动同步 --- ## 7. 需新增数据模型 | 模型 | 关键字段 | | ----------------------- | ------------------------------------------------------------------------------------------ | | `visit_plan` | id, cycle_type, district_id, assignee_id, start_date, end_date, status | | `visit_task` | id, plan_id, elder_id, assignee_id, scheduled_date, status, checkin_time, checkin_location | | `visit_record` | id, task_id, photo_urls, form_data(JSONB), abnormal_flag, notes | | `visit_form_template` | id, name, fields(JSONB), version, is_active | | `visit_group` | id, name, members(array), district_ids | | `visit_abnormal_report` | id, record_id, type, description, dispatch_status, handler_id | --- ## 8. 需新增技术栈 / 第三方能力 / 中间件 | 类别 | 技术选型 | 用途 | | -------- | ------------------------------- | ------------------ | | 定位 | 高德 SDK(iOS/Android) | GPS 打卡、地理围栏 | | 文件存储 | 阿里云 OSS / 腾讯云 COS | 照片存储 | | 离线缓存 | uni-app 本地存储 + 同步队列 | 弱网支持 | | 动态表单 | 自研表单引擎(JSON Schema驱动) | 可配置巡访问卷 | | 图片处理 | Canvas水印叠加 | 照片水印 | --- ## 9. 外部系统对接关系 | 对接方 | 内容 | 方式 | | ------------------ | ------------------------ | ------------ | | 数据库系统(02) | 老人档案、地址坐标 | 内部API调用 | | 呼叫中心(06) | 异常上报触发紧急呼叫 | 内部消息队列 | | 政府监管(01) | 巡访完成率、异常数据汇总 | 内部API | | 系统管理中心(05) | 账号、权限、区域配置 | 内部API | --- ## 10. 风险与边界 | 风险 | 说明 | 应对 | | ------------------------ | ------------------------- | ------------------------------------------ | | 虚假签到 | 巡访员代打卡或远程操作 | GPS围栏(不可手动修改位置)+照片时间戳校验 | | 弱网断连 | 农村/老旧小区信号差 | 离线表单缓存 + 后台自动同步 | | 老人拒绝配合 | 老人不开门或拒绝拍照 | 支持填写"拒访原因",不强制照片 | | 边界:本系统不含设备管理 | IoT设备巡检由16号模块负责 | 本系统仅做人工上门巡访 | --- ## 11. 实施优先级与分期建议 **优先级:P2** | 分期 | 内容 | 前置条件 | | ------ | ---------------------------------- | ------------------ | | 第一期 | 移动端打卡 + 基础问卷 + 照片上传 | 老人档案(02)就绪 | | 第二期 | 计划自动生成 + 分组管理 + 统计报表 | — | | 第三期 | 异常自动告警 + 对接政府监管(01) | 呼叫中心(06)就绪 | --- ## 12. 结论 定期巡访系统是以**人工外勤服务**为核心的移动端垂直应用,所需的地理围栏打卡、动态问卷、照片水印等能力在 mall 中完全缺失,且其业务逻辑与电商场景毫无共通之处。 **必须独立建设**,建议采用轻量化架构,以移动端体验为核心设计目标,优先实现外勤人员的高效使用,避免照搬 PC 端管理系统的交互模式。