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服务，降低研发复杂度。 diff --git a/契合度/05-智慧康养系统管理中心-模块规划.md b/契合度/05-智慧康养系统管理中心-模块规划.md new file mode 100644 index 0000000..44d176b --- /dev/null +++ b/契合度/05-智慧康养系统管理中心-模块规划.md @@ -0,0 +1,173 @@ +# 智慧康养系统管理中心 模块规划 + +--- + +## 1. 模块定位 + +智慧康养系统管理中心是整个智慧医养平台的**运营管理骨架**，承担跨模块的基础设施管理职责，包括机构体系管理、账号与权限管理、一卡通管理、公告管理、老年大学/老人圈等社区服务，以及系统级资源监控与基础数据维护。 + +本模块是其他所有业务模块正常运转的前提，优先级高（P1），应在平台启动早期完成核心功能建设。 + +--- + +## 2. 建设目标 + +1. 构建平台级统一账号体系，支持多角色（政府/机构/服务商/老人/家属）的身份注册与权限分配 +2. 实现下属机构（日间照料中心/养老院/社区服务站）的层级化管理 +3. 提供一卡通（NFC/条形码/人脸）管理能力，支撑老人身份识别与服务核销 +4. 完成系统级资源监控（服务健康状态、API调用量、告警） +5. 管理基础数据字典（服务类型/行政区划/设备型号）与公告发布 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 下属机构系统管理 +- 账号与权限管理 +- 一卡通管理 +- 智慧库（知识库） +- 公告管理 +- 老年大学 +- 老人圈与家属圈 +- 日志管理 +- 智能设备接口管理 +- 系统资源监控 +- 基础数据维护 + +### 3.2 二级模块 + +- **机构管理**：机构树形结构维护（集团→子公司→门店）、机构信息编辑、状态管理 +- **权限管理**：角色定义、菜单权限、数据权限（按机构/区划隔离）、操作日志 +- **一卡通管理**：卡片发放/挂失/补卡、NFC/人脸/条码多模式绑定、服务核销记录 +- **智慧库**：操作手册/服务规范/政策文件的知识库，支持全文检索 +- **公告管理**：平台公告/机构通知发布与推送，支持按角色定向发布 +- **老年大学**：课程管理、报名管理、直播/视频课件、学员档案 +- **老人圈/家属圈**：社区话题/相册/活动报名（类轻量级社交） +- **日志管理**：操作日志查询、错误日志、审计日志导出 +- **设备接口管理**：IoT设备型号注册、通信协议配置、设备厂商对接文档 +- **系统监控**：服务健康度、数据库连接、接口延迟、磁盘/内存仪表盘 +- **基础数据**：行政区划字典、服务类型字典、失能等级标准、货币/单位设置 + +### 3.3 核心功能说明 + +| 功能 | 说明 | 技术要点 | +| ---------- | ------------------------------------ | ----------------------------------- | +| 机构树管理 | 支持3-5级机构层级，数据权限按树隔离 | 邻接表/闭包表 + RBAC | +| 一卡通核销 | 老人刷卡→实时读取身份→记录服务消耗 | NFC Reader API / 人脸识别SDK | +| 权限管理 | 菜单+按钮+数据三级权限，支持临时授权 | RBAC + 行级过滤 | +| 老年大学 | 课程视频点播 + 直播（推流/拉流） | 视频云服务（腾讯云/阿里云视频点播） | +| 系统监控 | 可观测性仪表盘 | Prometheus + Grafana | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 具备基础的管理后台（商家管理、订单管理）和 RBAC 权限框架，表面上与本模块存在重叠，但存在关键差异： + +| 能力需求 | mall 现状 | 结论 | +| ------------------------- | --------------------------------------- | ------ | +| 多层级机构树管理 | 仅有平台商家列表（单层） | 须重建 | +| 一卡通（NFC/人脸绑定） | 无 | 须新建 | +| 老年大学（课程/直播） | 无 | 须新建 | +| 老人圈/家属圈（社区功能） | 无 | 须新建 | +| 系统级资源监控 | 无运维仪表盘 | 须新建 | +| 医养专属基础数据字典 | mall 有商品分类等字典，但无医养业务字典 | 须重建 | + +mall 的 RBAC 模型可作为参考，但其角色体系（商家/消费者/骑手）与医养角色（政府/机构/服务员/老人/家属）完全不同，直接复用会造成权限混乱。 + +--- + +## 5. 规划判断 + +**独立系统建设** + +- 后台管理端：Vue3 PC Web（主要使用场景） +- 移动端入口：uni-app（公告推送、老人圈/老年大学） +- 服务端：独立API，提供用户中心服务供其他模块调用 +- 本模块的用户账号体系是25号（业务中台）用户服务中心的具体实现载体 + +--- + +## 6. 需新增业务能力 + +1. **多租户机构隔离**：实现机构间的数据物理隔离或逻辑隔离，防止越权访问 +2. **一卡通全链路管理**：发卡→绑定→激活→核销→挂失→补卡完整生命周期 +3. **人脸识别绑定**：老人人脸特征采集（合规告知后）与一卡通绑定 +4. **知识库全文检索**：内部操作手册、政策文件的快速检索 +5. **老年大学直播**：推流端（PC/移动）+ 拉流端（老人手机/平板） +6. **老人圈内容审核**：发布内容的关键词过滤与人工审核机制 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------------------- | --------------------------------------------------------------------- | +| `org_tree` | id, parent_id, name, org_type, level, district_code | +| `sys_role` | id, org_id, name, permissions(JSONB) | +| `sys_user` | id, org_id, role_ids, username, status, last_login | +| `one_card` | id, elder_id, card_no, card_type(NFC/face/barcode), status, issued_at | +| `one_card_consume` | id, card_id, service_id, amount, consumed_at, terminal_id | +| `knowledge_base` | id, org_id, title, content, category, search_vector | +| `announcement` | id, org_id, title, content, target_roles, published_at | +| `elderly_university_course` | id, name, teacher, schedule, live_url, replay_url, enrollments | +| `system_monitor_metric` | id, service_name, metric_type, value, collected_at | +| `data_dict` | id, category, code, value, sort_order, is_active | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| -------- | --------------------------------- | -------------------- | +| 人脸识别 | 腾讯云人脸识别 / 阿里云人脸核身 | 一卡通人脸绑定与核验 | +| 视频直播 | 腾讯云直播（CSS）/ 阿里云视频直播 | 老年大学直播 | +| 全文检索 | PostgreSQL FTS / Elasticsearch | 知识库检索 | +| 监控 | Prometheus + Grafana | 系统资源监控 | +| NFC读卡 | uni-app NFC API | 一卡通NFC读取 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| -------------- | -------------------------------- | ----------- | +| 业务中台（25） | 统一身份认证，本模块为其落地实现 | 内部API | +| 所有业务模块 | 权限验证、字典查询、公告推送 | 内部SDK/API | +| IoT管理（16） | 设备接口注册与协议配置 | 内部API | +| 政府监管（01） | 机构台账、账号统计 | 内部API | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | ------------------------------------ | -------------------------------------- | +| 人脸数据合规 | 人脸属于生物识别信息，需明确知情同意 | 采集前书面告知，单独存储，设置访问审计 | +| 权限过于复杂 | 多角色多层级权限矩阵维护困难 | 采用基于角色的模板权限 + 例外管理 | +| 老年大学直播稳定性 | 老人网络条件差，直播卡顿 | 提供回放作为主要使用方式，直播为辅 | +| 边界：不含HIS系统 | 本系统不包含医疗业务中台逻辑 | 医疗业务由25号模块（业务中台）负责 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P1** + +| 分期 | 内容 | 说明 | +| -------------- | ------------------------------------ | ----------------------------- | +| 第一期（必须） | 账号权限管理 + 机构树 + 基础数据字典 | P0/P1所有模块的账号依赖此部分 | +| 第二期 | 一卡通管理 + 公告 + 日志 | 运营启动时需要 | +| 第三期 | 老年大学 + 老人圈 + 系统监控 | 增值服务，不影响核心业务 | + +--- + +## 12. 结论 + +系统管理中心是整个平台能够运转的基础设施模块，**账号权限管理和机构树管理必须在P0阶段同步完成**，否则所有业务模块均无法正常部署。 + +核心能力与 mall 的 RBAC 框架存在角色和结构上的本质差异，**不建议在 mall 框架内改造，应独立建设**，并将用户中心服务作为全平台的基础设施对外提供。