上传文件至「契合度」

契合度/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阶段启动本系统，以确保驾驶舱数据来源的真实性和完整性。

契合度/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个业务模块的数据需求。数据安全与合规（《个人信息保护法》、等保三级）需作为设计约束贯穿始终。

契合度/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 端管理系统的交互模式。

契合度/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服务，降低研发复杂度。

契合度/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 框架内改造，应独立建设**，并将用户中心服务作为全平台的基础设施对外提供。