huangzhenbao/------------
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

上传文件至「/」

Browse Source
This commit is contained in:
huangzhenbao
2026-03-31 01:18:12 +00:00
commit 07c5ca121e
5 changed files with 825 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

155
00-模块规划总览.md Normal file
View File

@@ -0,0 +1,155 @@
# 智慧医养系统 模块规划总览
> 本文档基于《(首期开发需求确认)智慧医养.md》与《mall 文件夹现状分析报告 × 智慧医养需求契合度.md》两份源文档综合整理，作为全部27个子模块规划文档的索引与决策依据。
---
## 一、项目背景
智慧医养系统旨在构建覆盖"居家—社区—机构"三级养老服务的数字化平台，整合政府监管、老人服务、服务商运营、健康管理、IoT设备、医保结算等多维度能力。
现有技术资产（mall平台）基于 **uni-app（uvue/UTS）+ Supabase + PostgreSQL** 构建，覆盖消费者/商家/骑手/客服/管理员五大角色，具备完整的电商流转能力。
智慧医养系统的建设，需在评估 mall 现有能力基础上，明确"直接复用""扩展复用"与"独立建设"三种建设路径，合理规避重复投入与架构污染。
---
## 二、建设路径分类说明
| 等级 | 标识 | 含义 | 建设路径 |
| ---- | ------ | --------------------------------------- | ----------------------------- |
| A | 高契合 | mall 核心能力直接覆盖，局部扩展即可投产 | mall 内扩展 |
| B | 中契合 | mall 提供基础骨架，需补充行业专属业务层 | mall + 独立微服务 |
| C | 低契合 | mall 仅有碎片化参考价值，需大量定制开发 | mall + 独立微服务（部分复用） |
| D | 不适配 | mall 电商架构与该系统领域存在根本性差异 | 独立系统建设 |
---
## 三、27个模块总览
### 3.1 智慧医养系统（16个模块）
| 编号 | 模块名称 | 契合度 | 建设路径 | 优先级 | 规划文档 |
| ---- | ---------------------------------- | ------ | ----------------- | ------ | -------------------------------------------------------------------------------------------------------- |
| 01 | 智慧医养政府监管系统 | D | 独立系统 | P2 | [01-智慧医养政府监管系统-模块规划.md](./01-智慧医养政府监管系统-模块规划.md) |
| 02 | 智慧医养数据库系统 | D | 独立系统 | P2 | [02-智慧医养数据库系统-模块规划.md](./02-智慧医养数据库系统-模块规划.md) |
| 03 | 智慧医养定期巡访系统 | D | 独立系统 | P2 | [03-智慧医养定期巡访系统-模块规划.md](./03-智慧医养定期巡访系统-模块规划.md) |
| 04 | 智慧康养政府及上级企业审批业务系统 | D | 独立系统 | P2 | [04-智慧康养政府及上级企业审批业务系统-模块规划.md](./04-智慧康养政府及上级企业审批业务系统-模块规划.md) |
| 05 | 智慧康养系统管理中心 | D | 独立系统 | P1 | [05-智慧康养系统管理中心-模块规划.md](./05-智慧康养系统管理中心-模块规划.md) |
| 06 | 智慧康养呼叫中心系统 | D | 独立系统 | P1 | [06-智慧康养呼叫中心系统-模块规划.md](./06-智慧康养呼叫中心系统-模块规划.md) |
| 07 | 养老需求及老人情况评估系统 | D | 独立系统 | P1 | [07-养老需求及老人情况评估系统-模块规划.md](./07-养老需求及老人情况评估系统-模块规划.md) |
| 08 | 智慧康养健康管理系统 | D | 独立系统 | P2 | [08-智慧康养健康管理系统-模块规划.md](./08-智慧康养健康管理系统-模块规划.md) |
| 09 | 智慧康养安全系统 | D | 独立系统 | P2 | [09-智慧康养安全系统-模块规划.md](./09-智慧康养安全系统-模块规划.md) |
| 10 | 智慧康养居家养老管理系统 | C | mall + 独立微服务 | P1 | [10-智慧康养居家养老管理系统-模块规划.md](./10-智慧康养居家养老管理系统-模块规划.md) |
| 11 | 智慧康养服务商管理系统 | B | mall + 独立微服务 | P1 | [11-智慧康养服务商管理系统-模块规划.md](./11-智慧康养服务商管理系统-模块规划.md) |
| 12 | 智慧康养志愿者管理系统 | D | 独立系统 | P2 | [12-智慧康养志愿者管理系统-模块规划.md](./12-智慧康养志愿者管理系统-模块规划.md) |
| 13 | 智慧康养短信平台系统 | C→独立 | 独立微服务 | P1 | [13-智慧康养短信平台系统-模块规划.md](./13-智慧康养短信平台系统-模块规划.md) |
| 14 | 智慧康养社区助餐可视化系统 | B | mall + 独立微服务 | P1 | [14-智慧康养社区助餐可视化系统-模块规划.md](./14-智慧康养社区助餐可视化系统-模块规划.md) |
| 15 | 家庭床位及适老化改造系统 | C | mall + 独立微服务 | P1 | [15-家庭床位及适老化改造系统-模块规划.md](./15-家庭床位及适老化改造系统-模块规划.md) |
| 16 | 智能物联网管理系统 | D | 独立系统 | P2 | [16-智能物联网管理系统-模块规划.md](./16-智能物联网管理系统-模块规划.md) |
### 3.2 应用系统（7个模块）
| 编号 | 模块名称 | 契合度 | 建设路径 | 优先级 | 规划文档 |
| ---- | -------------------- | ------ | ----------------- | ------ | ---------------------------------------------------------------------------- |
| 17 | 医保DIP智能控费 | D | 独立系统 | P2 | [17-医保DIP智能控费-模块规划.md](./17-医保DIP智能控费-模块规划.md) |
| 18 | 长护险与居家服务管理 | C | mall + 独立微服务 | P1 | [18-长护险与居家服务管理-模块规划.md](./18-长护险与居家服务管理-模块规划.md) |
| 19 | 医养商城 | **A** | mall 内扩展 | **P0** | [19-医养商城-模块规划.md](./19-医养商城-模块规划.md) |
| 20 | 慢性病管理 | D | 独立系统 | P2 | [20-慢性病管理-模块规划.md](./20-慢性病管理-模块规划.md) |
| 21 | 中心药房 | D | 独立系统 | P2 | [21-中心药房-模块规划.md](./21-中心药房-模块规划.md) |
| 22 | 人工智能服务 | D | 独立系统 | P2 | [22-人工智能服务-模块规划.md](./22-人工智能服务-模块规划.md) |
| 23 | 全生命周期监测平台 | D | 独立系统 | P2 | [23-全生命周期监测平台-模块规划.md](./23-全生命周期监测平台-模块规划.md) |
### 3.3 运营管理系统（1个模块）
| 编号 | 模块名称 | 契合度 | 建设路径 | 优先级 | 规划文档 |
| ---- | ------------ | ------ | ----------------- | ------ | ------------------------------------------------------------ |
| 24 | 运营管理系统 | B | mall + 独立微服务 | **P0** | [24-运营管理系统-模块规划.md](./24-运营管理系统-模块规划.md) |
### 3.4 中台能力层（3个模块）
| 编号 | 模块名称 | 契合度 | 建设路径 | 优先级 | 规划文档 |
| ---- | -------- | ------ | -------- | ------ | ---------------------------------------------------- |
| 25 | 业务中台 | D | 独立系统 | P1 | [25-业务中台-模块规划.md](./25-业务中台-模块规划.md) |
| 26 | 数据中台 | D | 独立系统 | P2 | [26-数据中台-模块规划.md](./26-数据中台-模块规划.md) |
| 27 | 技术中台 | D | 独立系统 | P2 | [27-技术中台-模块规划.md](./27-技术中台-模块规划.md) |
---
## 四、优先级分期建议
### P0 优先（首期必做）
| 模块 | 理由 |
| --------------- | --------------------------------------------- |
| 19-医养商城 | mall 高契合，快速产生商业价值，验证平台可行性 |
| 24-运营管理系统 | 支撑所有业务线运营，是整个平台的管理骨架 |
### P1 优先（首期同步推进）
| 模块 | 理由 |
| --------------- | ------------------------------------------- |
| 05-系统管理中心 | 基础权限与机构管理，所有系统依赖 |
| 06-呼叫中心 | 养老服务核心入口，SOS急救和服务调度关键路径 |
| 07-评估系统 | 老人服务的评估入口，长护险/补贴核定前置 |
| 10-居家养老管理 | 最大用户群体，订单+档案+家庭医生 |
| 11-服务商管理 | B2B/B2G服务供给侧，服务商履约能力来源 |
| 13-短信平台 | 系统级基础设施，全平台通知依赖 |
| 14-社区助餐 | 易标杆，可视化大屏具备招商展示价值 |
| 15-家庭床位改造 | 政策补贴窗口，申请+审核+上门服务闭环 |
| 18-长护险 | 医保结算通道，商业价值高，政策驱动 |
| 25-业务中台 | 统一身份与多角色权限是P0/P1模块的基础 |
### P2 阶段（深化期）
01-政府监管、02-数据库、03-定期巡访、04-审批业务、08-健康管理、09-安全系统、12-志愿者管理、16-IoT管理、17-医保DIP、20-慢性病管理、21-中心药房、22-AI服务、23-全生命周期监测、26-数据中台、27-技术中台
---
## 五、mall 现有能力可复用清单
| 能力域 | 具体能力 | 可复用模块 |
| -------------- | --------------------------- | ------------------------ |
| 用户认证 | 微信登录、手机验证、JWT | 全部模块用户端 |
| 商品管理 | 商品CRUD、SKU体系、分类管理 | 19-医养商城 |
| 订单全生命周期 | 下单/付款/发货/退款 | 19-医养商城、14-社区助餐 |
| 支付体系 | 微信/支付宝/钱包/积分 | 19-医养商城、14-社区助餐 |
| 物流配送 | 配送员端、轨迹追踪 | 19-医养商城、14-社区助餐 |
| 营销工具 | 优惠券/积分/会员/推荐 | 19-医养商城 |
| 商家入驻 | 商家资质审核、商品上架 | 11-服务商管理（参考） |
| 工单/客服 | 工单流转、消息通知 | 06-呼叫中心（参考） |
| RBAC | 角色权限管理 | 05-系统管理中心（参考） |
| 数据分析 | 16个统计服务 | 24-运营管理系统 |
---
## 六、mall 缺失的核心能力（全部需新建）
- 老人档案与家庭关系管理（EMR前置）
- 护理记录与照护评估量表（ADL/MMSE）
- GPS服务签到与电子签名（长护险合规）
- IoT设备接入层（MQTT、边缘计算）
- GIS地理围栏（防走失/服务范围管控）
- 审批工作流引擎（多级审批管理）
- 呼叫中心CTI接口（来电弹屏、录音）
- HL7/FHIR 医疗互操作协议
- 医保结算接口（各省统筹医保API）
- 长护险险种规则引擎
- 民政补贴核算与拨付
- 区块链存证（时间银行、数据可信）
- 政务大屏 / GIS可视化（ECharts + AMap高级API）
- 视频监控流媒体接入
---
## 七、文档使用说明
1. 每个子模块规划文档均遵循统一的12节结构，便于横向比较与评审
2. "与现有 mall 的关系"章节明确区分"可复用"与"须独立"，避免架构污染
3. 标注"⚠️ 待确认"的内容需在需求细化阶段与业务方/政府方再次确认
4. 所有规划文档均基于需求文档内容整理，未添加源文档未提及的功能
---
_生成时间：基于第一期需求确认文档_
_文档版本：v1.0_

167
01-智慧医养政府监管系统-模块规划.md Normal file
View File

@@ -0,0 +1,167 @@
# 智慧医养政府监管系统 模块规划
---
## 1. 模块定位
智慧医养政府监管系统是面向**政府监管部门**（民政局、卫健委、医保局等）的数字化治理工具，承担对辖区内养老服务体系的全面数据感知、实时监控与行政监管职能。
本系统属于**B2G（政企）** 方向，核心用户为政府工作人员，而非消费者或商家，与 mall 的 B2C/B2B 电商定位存在根本性差异。
---
## 2. 建设目标
1. 构建辖区养老资源数字驾驶舱，实现服务机构、老人数量、志愿者、服务商的实时可视化监管
2. 实现养老服务质量的在线监督（视频监控、服务执行轨迹）
3. 提供社区服务呼叫监管与报警调度能力，支持紧急事件闭环处置
4. 输出行政决策所需的统计报表与趋势分析
---
## 3. 核心功能范围
### 3.1 一级模块
- 数据驾驶舱
- 养老资源监管
- 视频监控监管
- 统计分析
- 报警调度
### 3.2 二级模块
- 数据驾驶舱：GIS地图总览、服务机构分布、实时服务数量播报、关键指标看板
- 养老资源监管：机构台账管理、服务商资质查验、从业人员档案核查、老人服务率统计
- 视频监控：机构视频接入、实时预览、录像回放、报警联动
- 统计分析：老人统计、志愿者服务时长统计、社区呼叫监管报表、服务完成率分析
- 报警调度：告警接收、工单派发、处置跟踪、事后复盘
### 3.3 核心功能说明
| 功能模块 | 核心能力描述 | 技术要点 |
| ---------------- | --------------------------------------- | ----------------------- |
| 数据驾驶舱 | 辖区养老全景GIS可视化，关键指标实时播报 | AMap API + ECharts大屏 |
| 养老资源监管 | 机构/服务商/人员多维度台账与实时状态 | 多表关联查询、状态机 |
| 视频监控监管 | 对接机构NVR/IPC，实现Web端实时查看 | 流媒体服务器（SRS/ZLM） |
| 志愿者统计 | 志愿服务时长、服务类型、覆盖率分析 | 聚合统计 + 图表展示 |
| 老人统计 | 按年龄/失能等级/地址等多维度统计 | 分组聚合、GIS热力图 |
| 社区服务呼叫监管 | 监控呼叫中心呼入/处置/完结全过程 | 呼叫中心API数据同步 |
| 报警调度 | 接收IoT/人工告警，派发处置工单 | 工作流引擎 + 实时推送 |
---
## 4. 与现有 mall 的关系
**契合度：D（不适配）**
mall 是通用电商平台，具备用户购物、商家销售、骑手配送、管理员后台等角色闭环，本质是交易驱动的商业系统。
政府监管系统所需的能力与 mall 存在根本性差异：
| 能力需求 | mall 现状 | 结论 |
| ---------------------------------- | -------------------------- | ---------- |
| GIS 全息地图（辖区视角） | 无 | 须独立建设 |
| 流媒体视频监控接入 | 无 | 须独立建设 |
| 政府角色体系（监管员/局长/巡查员） | 无 | 须独立建设 |
| 行政报表与决策看板 | 无 | 须独立建设 |
| 养老资源台账（机构/人员/服务商） | 无 | 须独立建设 |
| 报警调度工作流 | 无（现有工单系统为客服侧） | 须独立建设 |
mall 电商数据模型（商品、订单、SKU、优惠券）对本模块无参考价值，强行嵌入将导致数据架构污染和权限体系混乱。
---
## 5. 规划判断
**独立系统建设（全新项目）**
- 独立数据库（养老资源库、监管日志库）
- 独立后端服务（Go/Java 微服务，满足高并发实时数据推送）
- 独立前端（大屏端 + PC Web管理端，非移动端优先）
- 独立部署，可对接政务云或专线
---
## 6. 需新增业务能力
1. **GIS 地理信息引擎**：辖区养老资源空间分布、轨迹热力图、服务覆盖半径
2. **流媒体服务接入**：NVR/IPC 视频流（RTSP → HLS/WebRTC 转码）
3. **大屏可视化框架**：政府汇报级数据驾驶舱（全屏自适应、动效播报）
4. **告警规则引擎**：基于阈值/时间窗的多类型告警触发
5. **工作流/工单引擎**：报警事件 → 派单 → 处置 → 归档 完整闭环
6. **统计报表引擎**：多维度、可配置、可导出（Excel/PDF）
---
## 7. 需新增数据模型
| 数据模型 | 说明 |
| ---------------------- | ---------------------------------------------- |
| `gov_institution` | 养老机构台账（名称、地址、坐标、等级、床位数） |
| `gov_service_provider` | 服务商资质档案 |
| `gov_elder_stats` | 老人统计快照（按区域/失能等级） |
| `gov_volunteer_stats` | 志愿者服务时长统计 |
| `gov_alarm` | 报警记录（类型、来源、状态、派单记录） |
| `gov_dispatch_order` | 报警处置工单 |
| `gov_video_channel` | 监控摄像头通道配置 |
| `gov_report_config` | 报表模板配置 |
---
## 8. 需新增技术栈 / 第三方能力 / 中间件
| 类别 | 技术选型 | 用途 |
| -------- | -------------------------- | -------------------------- |
| GIS | 高德地图开放平台（政务AK） | 地图展示、地理编码、热力图 |
| 可视化 | ECharts / DataV | 大屏图表 |
| 流媒体 | SRS / ZLMediaKit | 视频流转码与分发 |
| 实时推送 | WebSocket / SSE | 实时告警推送到大屏 |
| 报表 | Apache POI / JasperReports | 导出Excel/PDF |
| 消息队列 | RabbitMQ / Kafka | 告警异步处理 |
---
## 9. 外部系统对接关系
| 对接方 | 对接内容 | 对接方式 |
| ------------------- | ---------------------------- | --------------------------------- |
| 呼叫中心系统（06） | 呼叫记录、服务工单完成状态 | 内部API/消息队列 |
| IoT管理系统（16） | 设备告警事件 | MQTT / 消息队列 |
| 居家养老管理（10） | 老人服务完成率、档案数量 | 内部API |
| 服务商管理（11） | 服务商资质状态、服务执行数据 | 内部API |
| 安全系统（09） | SOS告警、防走失告警 | 消息队列 |
| 政务云/民政局系统 | 补贴核算结果、老人基础信息 | ⚠️ 待确认（各地政务接口规范不同） |
| 视频监控设备（NVR） | 实时视频流 | RTSP 拉流 |
---
## 10. 风险与边界
| 风险 | 说明 | 应对 |
| ---------------- | ------------------------------------------- | ----------------------------------- |
| 政务接口差异化 | 各省/市政务系统接口规范不统一 | ⚠️ 需与目标地方政府提前确认接口协议 |
| 视频监控合规 | 视频数据涉及个人隐私，需符合等保三级要求 | 加密存储、访问审计、最小权限原则 |
| 大屏数据延迟 | 实时数据量大，可能出现刷新延迟 | 数据分层缓存（Redis + CDN静态资源） |
| 多级政府角色权限 | 市级>区级>街道>机构的数据权限隔离 | 基于组织树的行政区划 RBAC |
| 边界：不含审批 | 审批业务由04号模块负责，本系统仅做查阅/监管 | 明确模块边界，避免功能重叠 |
---
## 11. 实施优先级与分期建议
**优先级：P2（深化期）**
| 分期 | 内容 | 前置条件 |
| ------ | ----------------------------------------- | ------------------------- |
| 第一期 | 数据驾驶舱（静态数据可视化）+基础台账管理 | 10/11/07模块基础数据就绪 |
| 第二期 | 视频监控接入 + 实时告警 | IoT/安全系统（09/16）完成 |
| 第三期 | 报表导出 + 政务数据对接 | 政务接口协议确认 |
---
## 12. 结论
智慧医养政府监管系统是面向政府用户的B2G系统，所需的GIS大屏、视频流媒体、行政RBAC、监管报表等核心能力在 mall 平台中完全缺失，**必须作为独立系统建设**。
建议在P1阶段核心业务模块（10/11/07/05）完成数据积累后，再于P2阶段启动本系统，以确保驾驶舱数据来源的真实性和完整性。

174
02-智慧医养数据库系统-模块规划.md Normal file
View File

@@ -0,0 +1,174 @@
# 智慧医养数据库系统 模块规划
---
## 1. 模块定位
智慧医养数据库系统是整个智慧医养平台的**核心数据资产管理层**，负责集中存储和统一管理全平台所有业务实体的基础档案数据，包括老人、机构、服务商、从业人员、志愿者、服务记录、安全预警及智能健康数据。
本系统是其他所有业务模块的数据底座，并非独立对外提供用户界面的应用系统，其核心价值在于数据的权威性、一致性与安全性。
---
## 2. 建设目标
1. 建立全平台统一的老人基础信息库，作为服务派发、评估、补贴核算的唯一数据来源
2. 沉淀机构、服务商、从业人员的资质档案，支撑监管与准入管理
3. 维护服务数据库，记录服务类型、标准、执行记录
4. 汇聚安全预警与智能健康数据，为健康管理和安全系统提供底层支撑
5. 提供统一的数据访问API，供各业务模块按权限调用
---
## 3. 核心功能范围
### 3.1 一级模块
- 老人基础信息库
- 机构数据库
- 服务商数据库
- 服务数据库
- 从业人员数据库
- 志愿者数据库
- 安全预警数据库
- 智能健康数据库
### 3.2 二级模块
- **老人基础信息库**：基本信息、家庭关系、失能评估等级、服务状态、照片/身份证
- **机构数据库**：机构名称/类型/地址/坐标、许可证、床位数、运营状态、联系人
- **服务商数据库**：服务商资质、服务范围、人员配置、信用评分、合同状态
- **服务数据库**：服务项目目录、服务标准、定价体系、完成记录、评价数据
- **从业人员数据库**：身份信息、资质证书（护工/护士/医生）、所属机构、健康证
- **志愿者数据库**：个人信息、服务技能、时间银行账户余额、服务记录
- **安全预警数据库**：告警类型、来源设备、触发时间、处置状态、处置记录
- **智能健康数据库**：生命体征数据（血压/心率/血糖）、采集设备、采集时间、阈值配置
### 3.3 核心功能说明
| 数据库模块 | 核心数据项 | 与其他模块关系 |
| -------------- | ------------------------------------------------------------------------------ | ------------------------------------- |
| 老人基础信息库 | 老人ID、姓名、性别、出生日期、身份证、联系方式、地址坐标、失能等级、紧急联系人 | 被07/10/11/15/18/19等所有服务模块调用 |
| 机构数据库 | 机构ID、名称、类型（日间照料/养老院等）、区划代码、许可证有效期 | 被01/05/10/11调用 |
| 服务商数据库 | 服务商ID、营业执照、服务类型、覆盖区域、信用分 | 被11/01调用 |
| 服务数据库 | 服务项目ID、分类、标准描述、价格、执行时长标准 | 被10/11/15/18调用 |
| 从业人员数据库 | 人员ID、执业证书号、证书有效期、所属机构 | 被11/07/10调用 |
| 志愿者数据库 | 志愿者ID、技能标签、时间银行余额 | 被12/01调用 |
| 安全预警数据库 | 告警ID、设备ID、告警类型（跌倒/走失/SOS）、经纬度 | 被09/01/06调用 |
| 智能健康数据库 | 健康记录ID、老人ID、指标类型、数值、采集时间 | 被08/23/01调用 |
---
## 4. 与现有 mall 的关系
**契合度：D（不适配）**
mall 的数据模型以交易为核心：用户表（消费者/商家/骑手）、商品表、订单表、SKU表、支付记录等，是以"商品销售"为业务主线构建的模型体系。
智慧医养数据库系统所需的数据模型与 mall 存在根本性差异：
| 需求数据模型 | mall 类比项 | 差异说明 |
| -------------------- | ------------ | ----------------------------------------------------------- |
| 老人档案（EMR前置） | 无 | mall 用户表只有基础账号信息，无失能等级、家庭关系等医养字段 |
| 机构台账（行政属性） | 商家表 | 商家是交易主体，机构是行政监管对象，字段和权限逻辑完全不同 |
| 从业人员资质 | 商品描述字段 | 无对应数据模型 |
| 健康体征时序数据 | 无 | 时序数据库需求，mall 无此类存储能力 |
| 时间银行账户 | 积分账户 | 结构类似但业务逻辑（区块链存证、公益时长）完全不同 |
强行在 mall 数据库中扩展上述字段，将导致用户表/商家表臃肿失控，数据合规审计无法实施。
---
## 5. 规划判断
**独立数据库体系建设**
- 业务数据库：PostgreSQL（主业务实体档案）
- 时序数据库：InfluxDB 或 TimescaleDB（健康体征流数据）
- 独立后端数据服务层（Data Access Layer），提供REST/gRPC API
- 统一数据权限模型（按机构/区划/角色的行级数据隔离）
---
## 6. 需新增业务能力
1. **统一老人ID体系**：跨系统唯一标识，关联身份证号、服务记录、健康数据
2. **资质证书有效期管理**：自动预警即将到期的机构许可证/人员执业证书
3. **数据变更审计日志**：所有档案修改记录完整追溯链
4. **数据导入/导出工具**：支持从民政系统批量导入老人档案（Excel/CSV/API）
5. **数据权限隔离**：按行政区划（市/区/街道/社区）的行级权限控制
6. **健康数据阈值配置**：每位老人可配置个性化的健康指标预警阈值
---
## 7. 需新增数据模型
| 模型名称 | 关键字段 |
| ------------------------- | ---------------------------------------------------------------------------------------------------- |
| `elder_profile` | id, id_card_no, name, gender, dob, address, gps_lat, gps_lng, disability_grade, emergency_contact_id |
| `elder_family_relation` | elder_id, member_name, relation_type, phone |
| `institution` | id, name, type, license_no, license_expire_date, district_code, beds_total, beds_available |
| `service_provider` | id, biz_license_no, service_types, coverage_area, credit_score, status |
| `service_catalog` | id, name, category, standard_desc, price, duration_minutes |
| `practitioner` | id, elder_or_org_id, cert_type, cert_no, cert_expire_date, org_id |
| `volunteer` | id, user_id, skills, time_bank_balance, total_service_hours |
| `safety_alarm` | id, elder_id, device_id, alarm_type, location, status, handler_id, resolved_at |
| `health_record` | id, elder_id, metric_type, value, unit, collected_at, device_id |
| `health_threshold_config` | elder_id, metric_type, min_val, max_val, alert_level |
---
## 8. 需新增技术栈 / 第三方能力 / 中间件
| 类别 | 技术选型 | 用途 |
| ---------- | ----------------------------- | ------------------------- |
| 时序数据库 | TimescaleDB（PostgreSQL扩展） | 健康体征流数据存储 |
| 数据脱敏 | 应用层脱敏中间件 | 老人身份证/手机号展示保护 |
| 数据审计 | pgaudit（PostgreSQL审计插件） | 数据变更日志 |
| 数据同步 | Debezium（CDC） | 与政务系统的数据同步 |
| API网关 | NGINX + JWT验证 | 数据访问统一鉴权 |
| 数据备份 | 国产备份方案（等保要求） | 每日增量 + 周全量备份 |
---
## 9. 外部系统对接关系
| 对接方 | 对接内容 | 说明 |
| --------------------- | -------------------- | ------------------- |
| 民政局系统 | 老人基础信息批量导入 | ⚠️ 待确认接口规范 |
| 公安身份验证系统 | 身份证实名核验 | 第三方实名API |
| 医保系统 | 老人参保信息查询 | ⚠️ 待确认 |
| 所有业务模块（01-27） | 档案数据查询与写入 | 内部API，按权限隔离 |
---
## 10. 风险与边界
| 风险 | 说明 | 应对 |
| -------------------------- | ---------------------------------------------- | -------------------------------------- |
| 数据合规（个人信息保护法） | 老人身份证、健康数据属于敏感个人信息 | 国密加密存储、访问审计、最小权限 |
| 数据一致性 | 多模块并发写入同一老人档案 | 乐观锁 + 事件溯源（Event Sourcing） |
| 政务数据标准差异 | 不同地区民政台账字段不统一 | 建立数据映射层，保留原始字段 |
| 边界：不含健康档案（HIS） | 本系统存储生命体征数据，不承担完整 EMR/HIS功能 | 完整病历由医疗系统（慢性病管理20）维护 |
---
## 11. 实施优先级与分期建议
**优先级：P2（但属于P1模块的底层依赖，需提前规划）**
> 注意：本模块虽定级P2，但其数据模型设计必须在P0/P1阶段开始时同步完成，否则其他模块无法落库。
| 分期 | 内容 |
| ----------- | ---------------------------------------------------------------- |
| P0 阶段同步 | 设计并建立老人档案、机构、服务商核心表结构（即使功能界面未完成） |
| P1 阶段 | 完善数据管理界面、CRUD操作、数据导入工具 |
| P2 阶段 | 时序健康数据接入、政务系统数据同步、审计日志完善 |
---
## 12. 结论
智慧医养数据库系统是全平台的数据基石，其数据模型与 mall 的电商数据模型存在本质差异，**不可在 mall 数据库中扩展实现**。
必须在项目启动阶段完成核心数据模型设计，以独立数据服务的形式对外提供结构化访问，支撑全部27个业务模块的数据需求。数据安全与合规（《个人信息保护法》、等保三级）需作为设计约束贯穿始终。

160
03-智慧医养定期巡访系统-模块规划.md Normal file
View File

@@ -0,0 +1,160 @@
# 智慧医养定期巡访系统 模块规划
---
## 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 端管理系统的交互模式。

169
04-智慧康养政府及上级企业审批业务系统-模块规划.md Normal file
View File

@@ -0,0 +1,169 @@
# 智慧康养政府及上级企业审批业务系统 模块规划
---
## 1. 模块定位
智慧康养政府及上级企业审批业务系统是面向**政府主管部门（民政局/卫健委）及上级集团企业管理人员**的多级行政审批平台，承担补贴申请审核、企业资质审核、家庭床位审批、新闻发布及建议反馈管理等行政审批职能。
本系统的核心是**审批工作流引擎**，支持多级审批（街道→区→市）、权限管理和微信端移动审批，是连接政府行政决策与平台业务系统的关键枢纽。
---
## 2. 建设目标
1. 实现民政补贴申请的在线提交、多级审核与结果下发闭环
2. 支持企业资质审核（服务商、机构）的标准化审批流程
3. 构建家庭床位改造申请的全流程审批管理
4. 提供微信端移动审批能力，提升政府工作人员的审批效率
5. 支持政府新闻/通知的发布管理与居民建议反馈处理
---
## 3. 核心功能范围
### 3.1 一级模块
- 微信端登录与入口
- 补贴申请审核
- 企业资质审核
- 家庭床位审核
- 多级审核引擎
- 权限管理
- 新闻发布
- 建议反馈
### 3.2 二级模块
- **微信端登录**：政府工作人员微信扫码登录、身份绑定、权限初始化
- **补贴申请审核**：补贴类型配置、申请材料查阅、审核意见填写、退回/通过/挂起状态管理
- **企业资质审核**：服务商/机构申请列表、材料核验（营业执照/许可证）、黑名单管理
- **家庭床位审核**：改造申请列表、实地核查结果录入、改造资金核定、竣工验收
- **多级审核引擎**：审批节点配置（街道→区→市）、超时自动提醒、代审/转审
- **权限管理**：按行政区划的审批角色分配、数据可见范围设置
- **新闻发布**：通知/新闻/政策文件的富文本编辑与发布
- **建议反馈**：居民/服务商反馈列表、回复、分类统计
### 3.3 核心功能说明
| 功能 | 描述 | 技术要点 |
| ------------ | ------------------------------------------- | ----------------------------- |
| 多级审核流 | 配置审批节点、条件分支（金额阈值→升级审核） | 审批流引擎（如Activiti/自研） |
| 补贴申请审核 | 审核老人补贴资格、金额核定、批次下发 | 业务规则引擎 + 批处理 |
| 企业资质审核 | OCR识别营业执照/许可证，自动提取关键字段 | OCR第三方API |
| 微信端审批 | 待审list + 审核详情 + 一键通过/退回 | uni-app微信小程序 |
| 竣工验收 | 家庭床位改造完成后的图片+审核员现场确认 | 移动端拍照 + 电子签名 |
---
## 4. 与现有 mall 的关系
**契合度：D（不适配）**
mall 的核心流程是消费者下单→商家接单→骑手配送→消费者确认收货，整个流程以"消费行为"驱动。
本系统的核心流程是申请提交→多级政府审核→行政决定下发，整个流程以"行政审批"驱动：
| 能力需求 | mall 现状 | 结论 |
| -------------------------- | --------------------------- | ------------------ |
| 多节点审批工作流引擎 | 无（无审批流概念） | 须独立建设 |
| 政府角色体系（街道/区/市） | 无 | 须独立建设 |
| 补贴核算规则引擎 | 无 | 须独立建设 |
| OCR证照识别 | 无 | 须独立建设 |
| 家庭床位申请全流程 | 无 | 须独立建设 |
| 行政文件/新闻发布 | 仅有CMS文章管理（商城公告） | 领域不同，不可复用 |
mall 是通用电商平台，不具备行政审批能力，强行为其添加政府审批逻辑会导致架构混乱和权限体系崩溃。
---
## 5. 规划判断
**独立系统建设**
- 移动端：uni-app（微信小程序，政府工作人员使用）
- PC端：Vue3 Web管理后台（主审批界面）
- 服务端：独立审批流引擎 + 业务API
- 工作流引擎：自研轻量级或集成 Camunda/Flowable（根据复杂度决策）
---
## 6. 需新增业务能力
1. **可配置审批流引擎**：支持管理员在线配置审批节点、条件分支、超时策略
2. **补贴核算规则库**：按老人失能等级、服务类型、地区标准的补贴金额计算
3. **材料OCR识别**：营业执照、身份证、许可证关键信息自动提取
4. **批次审批**：支持对同一批补贴申请的批量通过/退回
5. **电子签章**：审批决定需支持电子签章，具备法律效力
6. **消息通知**：审批结果主动推送至申请方（微信模板消息）
---
## 7. 需新增数据模型
| 模型 | 关键字段 |
| -------------------------- | ------------------------------------------------------------------------------ |
| `approval_flow_def` | id, name, nodes(JSONB), conditions(JSONB), version |
| `approval_instance` | id, flow_def_id, biz_type, biz_id, current_node, status, submitter_id |
| `approval_node_record` | id, instance_id, node_name, approver_id, action, opinion, action_time |
| `subsidy_application` | id, elder_id, subsidy_type, amount_applied, amount_approved, period, documents |
| `org_qualification_review` | id, org_id, org_type, material_urls, ocr_data(JSONB), status |
| `home_bed_application` | id, elder_id, address, estimated_cost, inspector_id, inspect_report, status |
| `gov_news` | id, title, content, category, publisher_id, published_at, status |
| `feedback` | id, submitter_type, content, category, status, reply, replier_id |
---
## 8. 需新增技术栈 / 第三方能力 / 中间件
| 类别 | 技术选型 | 用途 |
| ---------- | ----------------------- | -------------------- |
| 工作流引擎 | Flowable / 自研轻量版 | 多级审批流配置与执行 |
| OCR | 腾讯云OCR / 阿里云OCR | 证照信息自动识别 |
| 电子签章 | 法大大 / 契约锁 | 审批决定电子签章 |
| 推送 | 微信模板消息 / 服务通知 | 审批结果通知 |
| 富文本编辑 | TinyMCE / WangEditor | 新闻/政策文件发布 |
---
## 9. 外部系统对接关系
| 对接方 | 内容 | 说明 |
| ------------------ | -------------------------- | ----------------- |
| 数据库系统（02） | 老人档案、服务商资质 | 内部API调用 |
| 家庭床位系统（15） | 床位改造申请数据来源 | 内部API |
| 服务商管理（11） | 服务商资质审核结果下发 | 内部API |
| 居家养老管理（10） | 补贴审核结果与服务计划关联 | 内部API |
| 政府监管（01） | 审批数据汇总至监管大屏 | 内部API |
| 民政局/政务平台 | 补贴拨付指令下发 | ⚠️ 待确认接口规范 |
---
## 10. 风险与边界
| 风险 | 说明 | 应对 |
| ------------------ | --------------------------------------------- | -------------------------- |
| 各地审批流程差异 | 不同省市民政补贴审批节点不同 | 审批流可配置化，避免硬编码 |
| 电子签章法律效力 | 部分地区不承认电子签章 | 提供纸质备档导出功能 |
| 审批超时 | 政府人员忙碌导致流程积压 | 自动催办、超时转派机制 |
| 边界：不含资金拨付 | 补贴核定在本系统，实际拨付由财务/民政系统执行 | 明确接口，只输出拨付指令 |
---
## 11. 实施优先级与分期建议
**优先级：P2**
| 分期 | 内容 | 前置条件 |
| ------ | ----------------------------------------------- | ------------------------------ |
| 第一期 | 企业资质审核 + 家庭床位审核（优先，有业务需求） | 15号模块家庭床位系统就绪 |
| 第二期 | 补贴申请全流程 + 多级审批引擎 | 老人档案（02）和评估（07）完成 |
| 第三期 | 微信端移动审批 + 电子签章 + 政务系统对接 | — |
---
## 12. 结论
审批业务系统是平台与政府行政流程的接口，核心能力（工作流引擎、政府角色体系、补贴规则引擎）在 mall 中完全缺失，**必须作为独立系统建设**。
建议工作流引擎采用可配置设计，以应对各地政府审批流程差异，避免因流程变化导致频繁改动代码。OCR与电子签章建议接入成熟的第三方SaaS服务，降低研发复杂度。