From 07c5ca121ebc466ebaa2c775299f1af4b407ecd6 Mon Sep 17 00:00:00 2001 From: huangzhenbao <17818024429@163.com> Date: Tue, 31 Mar 2026 01:18:12 +0000 Subject: [PATCH] =?UTF-8?q?=E4=B8=8A=E4=BC=A0=E6=96=87=E4=BB=B6=E8=87=B3?= =?UTF-8?q?=E3=80=8C/=E3=80=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- 00-模块规划总览.md | 155 ++++++++++++++++ 01-智慧医养政府监管系统-模块规划.md | 167 +++++++++++++++++ 02-智慧医养数据库系统-模块规划.md | 174 ++++++++++++++++++ 03-智慧医养定期巡访系统-模块规划.md | 160 ++++++++++++++++ ...康养政府及上级企业审批业务系统-模块规划.md | 169 +++++++++++++++++ 5 files changed, 825 insertions(+) create mode 100644 00-模块规划总览.md create mode 100644 01-智慧医养政府监管系统-模块规划.md create mode 100644 02-智慧医养数据库系统-模块规划.md create mode 100644 03-智慧医养定期巡访系统-模块规划.md create mode 100644 04-智慧康养政府及上级企业审批业务系统-模块规划.md diff --git a/00-模块规划总览.md b/00-模块规划总览.md new file mode 100644 index 0000000..a61fe30 --- /dev/null +++ b/00-模块规划总览.md @@ -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_ diff --git a/01-智慧医养政府监管系统-模块规划.md b/01-智慧医养政府监管系统-模块规划.md new file mode 100644 index 0000000..984bc64 --- /dev/null +++ b/01-智慧医养政府监管系统-模块规划.md @@ -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阶段启动本系统，以确保驾驶舱数据来源的真实性和完整性。 diff --git a/02-智慧医养数据库系统-模块规划.md b/02-智慧医养数据库系统-模块规划.md new file mode 100644 index 0000000..fa62f2f --- /dev/null +++ b/02-智慧医养数据库系统-模块规划.md @@ -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个业务模块的数据需求。数据安全与合规（《个人信息保护法》、等保三级）需作为设计约束贯穿始终。 diff --git a/03-智慧医养定期巡访系统-模块规划.md b/03-智慧医养定期巡访系统-模块规划.md new file mode 100644 index 0000000..68e705f --- /dev/null +++ b/03-智慧医养定期巡访系统-模块规划.md @@ -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 端管理系统的交互模式。 diff --git a/04-智慧康养政府及上级企业审批业务系统-模块规划.md b/04-智慧康养政府及上级企业审批业务系统-模块规划.md new file mode 100644 index 0000000..c417252 --- /dev/null +++ b/04-智慧康养政府及上级企业审批业务系统-模块规划.md @@ -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服务，降低研发复杂度。