174 lines
10 KiB
Markdown
174 lines
10 KiB
Markdown
# 智慧康养居家养老管理系统 模块规划
|
||
|
||
---
|
||
|
||
## 1. 模块定位
|
||
|
||
智慧康养居家养老管理系统是面向**居家老人、上门服务员和机构管理员**的核心服务调度系统，承担老人档案管理、服务项目订单管理、家庭医生签约管理、老年活动中心管理及智能呼叫调度等职能。
|
||
|
||
本系统是整个平台服务量最大的模块，是居家养老"最后一公里"服务的落地载体。
|
||
|
||
---
|
||
|
||
## 2. 建设目标
|
||
|
||
1. 建立完整的居家老人服务档案体系，包含个人基本信息、服务历史、家庭关系
|
||
2. 实现居家服务（上门护理/助浴/助餐/家政）的在线预约、派单和执行管理
|
||
3. 构建家庭医生签约管理功能，支持线上问诊和服务计划制定
|
||
4. 提供老年活动中心（日间照料）的入托/活动/绩效管理
|
||
5. 集成智能呼叫调度，支持服务员端实时接单和工作台管理
|
||
|
||
---
|
||
|
||
## 3. 核心功能范围
|
||
|
||
### 3.1 一级模块
|
||
|
||
- 老人档案管理
|
||
- 服务订单管理
|
||
- 服务项目管理
|
||
- 家庭医生管理
|
||
- 老年活动中心
|
||
- 智能呼叫调度
|
||
- 工作台管理
|
||
|
||
### 3.2 二级模块
|
||
|
||
- **老人档案**：基本信息、家庭关系、失能等级（来自07评估）、紧急联系人、服务计划
|
||
- **服务订单**：服务预约（老人/家属端）、订单分配（系统/手动）、服务执行确认（GPS打卡+照片）、评价
|
||
- **服务项目**：服务目录维护（助浴/助餐/助洁/护理）、定价、服务时长标准
|
||
- **家庭医生**：签约管理、服务计划制定、健康随访、在线咨询
|
||
- **老年活动中心**：日间照料入托申请、活动课程、出勤记录、绩效报表
|
||
- **智能呼叫**：老人一键呼叫→系统自动匹配就近服务员→推送接单通知
|
||
- **工作台**：服务员端今日任务、路线规划、打卡记录、服务报告提交
|
||
|
||
### 3.3 核心功能说明
|
||
|
||
| 功能 | 描述 | 技术要点 |
|
||
| ------------ | --------------------------------------------- | -------------------------- |
|
||
| 智能派单 | 根据老人地址+服务类型+服务员技能/距离自动分配 | GIS距离计算 + 技能匹配算法 |
|
||
| GPS签到 | 服务员到达老人家地理围栏内才可开始服务 | 高德定位 + 地理围栏 |
|
||
| 服务执行确认 | 服务完成后拍照/老人/家属电子签名 | 移动端拍照 + Canvas签名 |
|
||
| 家庭医生签约 | 家庭医生与老人1:N签约，绑定服务计划 | 签约关系表 + 计划模板 |
|
||
| 活动中心出勤 | 刷卡/人脸/签到记录日间照料出勤 | 一卡通API调用 |
|
||
|
||
---
|
||
|
||
## 4. 与现有 mall 的关系
|
||
|
||
**契合度：C（低契合，部分可参考）**
|
||
|
||
mall 具备部分可参考的能力，但差异显著：
|
||
|
||
| 能力 | mall 现状 | 可复用程度 |
|
||
| ------------------ | ------------------------- | ------------------------------------------- |
|
||
| 用户下单与服务预约 | 有商品下单流程 | 参考结构，需大量改造（服务型订单≠商品订单） |
|
||
| 骑手配送端 | 有骑手App（GPS接单/打卡） | 可参考移动端框架，核心逻辑差异大 |
|
||
| 订单状态机 | 有（7种状态） | 参考状态机设计，适配服务订单状态 |
|
||
| 工单/客服 | 有简单客服工单 | 不同场景，参考意义有限 |
|
||
| 评价体系 | 有商品评分 | 改造成服务评价 |
|
||
| 商品分类/目录 | 有SKU体系 | 可参考目录结构，服务无库存概念 |
|
||
| **老人档案** | **无** | **须独立建设** |
|
||
| **家庭医生签约** | **无** | **须独立建设** |
|
||
| **活动中心管理** | **无** | **须独立建设** |
|
||
| **GPS智能派单** | **无** | **须独立建设** |
|
||
|
||
**建设路径：mall + 独立微服务（C级）**
|
||
|
||
mall 的订单状态机和移动端框架可作为参考蓝本，但不建议直接在 mall 代码库中增量开发，需独立建设服务型订单系统，并通过 API 对接 mall 的支付能力（如果服务需要收费）。
|
||
|
||
---
|
||
|
||
## 5. 规划判断
|
||
|
||
**mall + 独立微服务（以独立为主）**
|
||
|
||
- 老人/家属端：uni-app（小程序），复用 mall 的支付/登录组件
|
||
- 服务员端：uni-app（独立应用，类似骑手端但完全重写）
|
||
- 管理后台：Vue3 Web（独立）
|
||
- 服务端：独立服务型订单服务（参考 mall 设计但独立部署）
|
||
- 支付：对接 mall 现有支付网关（政府补贴/个人自费混合结算）
|
||
|
||
---
|
||
|
||
## 6. 需新增业务能力
|
||
|
||
1. **服务型订单引擎**：服务订单（无库存概念）的预约→分配→签到→执行→确认→评价→结算
|
||
2. **智能派单算法**：基于GIS距离 + 服务员技能 + 可用时间窗口的最优匹配
|
||
3. **家庭医生签约与随访管理**：签约周期管理、随访计划提醒、在线咨询记录
|
||
4. **补贴抵扣结算**：政府补贴额度 + 个人自费混合支付，支持长护险抵扣
|
||
5. **服务质量监控**：服务员GPS轨迹核验、超时预警、服务评分聚合
|
||
6. **老年活动中心管理**：日间照料预约、活动排班、出勤统计、绩效报表
|
||
|
||
---
|
||
|
||
## 7. 需新增数据模型
|
||
|
||
| 模型 | 关键字段 |
|
||
| ------------------------ | ----------------------------------------------------------------------------------------------------------- |
|
||
| `home_service_order` | id, elder_id, service_type, scheduled_at, assignee_id, checkin_at, checkout_at, status, fee, subsidy_amount |
|
||
| `service_catalog` | id, name, category, description, price, duration_min, required_skills |
|
||
| `service_execution` | id, order_id, checkin_photo, checkout_photo, elder_signature, notes, result_confirmed |
|
||
| `family_doctor_contract` | id, doctor_id, elder_id, start_date, end_date, plan_id, status |
|
||
| `doctor_followup` | id, contract_id, date, method(online/offline), notes, health_data_ref |
|
||
| `activity_center` | id, name, address, capacity, manager_id |
|
||
| `day_care_booking` | id, elder_id, center_id, date, checkin_at, checkout_at |
|
||
| `call_dispatch` | id, elder_id, call_type, dispatch_time, assignee_id, response_time |
|
||
|
||
---
|
||
|
||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||
|
||
| 类别 | 技术选型 | 用途 |
|
||
| -------- | ---------------- | -------------------------------- |
|
||
| GIS | 高德路径规划API | 智能派单距离计算、服务员路线导航 |
|
||
| 定位 | 高德SDK | 服务员GPS打卡 |
|
||
| 电子签名 | Canvas手写签名 | 服务完成老人确认签字 |
|
||
| 补贴结算 | 自研补贴计算引擎 | 政府补贴额度抵扣计算 |
|
||
| 在线咨询 | 腾讯云IM / 融云 | 家庭医生与老人文字/语音咨询 |
|
||
|
||
---
|
||
|
||
## 9. 外部系统对接关系
|
||
|
||
| 对接方 | 内容 | 方式 |
|
||
| ---------------- | ---------------------------- | --------------- |
|
||
| 评估系统（07） | 失能等级→服务计划制定依据 | 内部API（只读） |
|
||
| 服务商管理（11） | 服务员来源、技能标签、考核分 | 内部API |
|
||
| 长护险（18） | 补贴抵扣额度同步 | 内部API |
|
||
| 呼叫中心（06） | 呼叫工单→服务派单 | 内部API |
|
||
| 安全系统（09） | SOS触发→居家服务员就近响应 | 消息队列 |
|
||
| mall支付（19） | 个人自费部分支付 | 内部支付网关 |
|
||
| 数据库系统（02） | 老人档案读写 | 内部API |
|
||
|
||
---
|
||
|
||
## 10. 风险与边界
|
||
|
||
| 风险 | 说明 | 应对 |
|
||
| ---------------------- | ---------------------------------------------- | ---------------------------------------- |
|
||
| 补贴结算规则复杂 | 各省市补贴标准不统一 | 补贴规则可配置化，不硬编码 |
|
||
| 服务员定位造假 | GPS打卡可能被外挂软件欺骗 | 设备+位置双重验证+照片时间戳 |
|
||
| 家庭医生供给不足 | 签约需要真实医生资质 | 引入第三方家庭医生平台 ⚠️ 待确认合作模式 |
|
||
| 边界：不含机构住院护理 | 本系统为居家上门服务，机构内护理由其他模块处理 | 明确服务范围 |
|
||
|
||
---
|
||
|
||
## 11. 实施优先级与分期建议
|
||
|
||
**优先级：P1**
|
||
|
||
| 分期 | 内容 | 前置条件 |
|
||
| ------ | ------------------------------------------ | -------------------------------- |
|
||
| 第一期 | 老人档案 + 服务订单（预约+执行）+ 服务员端 | 数据库（02）、系统管理（05）就绪 |
|
||
| 第二期 | 智能派单 + 补贴抵扣 + 评价体系 | 评估（07）、长护险（18）完成 |
|
||
| 第三期 | 家庭医生签约 + 活动中心 + 统计报表 | — |
|
||
|
||
---
|
||
|
||
## 12. 结论
|
||
|
||
居家养老管理系统是平台服务量最大的核心模块，mall 的订单状态机和移动端框架有一定参考价值（C级契合），但老人档案、智能派单、家庭医生签约等核心业务能力在 mall 中完全缺失。
|
||
|
||
**建议以独立系统建设为主，参考 mall 设计模式，通过 API 对接 mall 的支付能力**，避免在 mall 内部堆砌医养业务逻辑导致架构污染。P1阶段优先完成核心服务订单闭环，家庭医生和活动中心在P1后期或P2补充。
|