From e57c9035fffc459dd77105602531d28fd34d2a52 Mon Sep 17 00:00:00 2001 From: huangzhenbao <17818024429@163.com> Date: Tue, 31 Mar 2026 01:18:33 +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 --- 05-智慧康养系统管理中心-模块规划.md | 173 ++++++++++++++++++++++ 06-智慧康养呼叫中心系统-模块规划.md | 166 +++++++++++++++++++++ 07-养老需求及老人情况评估系统-模块规划.md | 160 ++++++++++++++++++++ 08-智慧康养健康管理系统-模块规划.md | 164 ++++++++++++++++++++ 09-智慧康养安全系统-模块规划.md | 166 +++++++++++++++++++++ 5 files changed, 829 insertions(+) create mode 100644 05-智慧康养系统管理中心-模块规划.md create mode 100644 06-智慧康养呼叫中心系统-模块规划.md create mode 100644 07-养老需求及老人情况评估系统-模块规划.md create mode 100644 08-智慧康养健康管理系统-模块规划.md create mode 100644 09-智慧康养安全系统-模块规划.md 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 框架内改造，应独立建设**，并将用户中心服务作为全平台的基础设施对外提供。 diff --git a/06-智慧康养呼叫中心系统-模块规划.md b/06-智慧康养呼叫中心系统-模块规划.md new file mode 100644 index 0000000..b86bfc5 --- /dev/null +++ b/06-智慧康养呼叫中心系统-模块规划.md @@ -0,0 +1,166 @@ +# 智慧康养呼叫中心系统 模块规划 + +--- + +## 1. 模块定位 + +智慧康养呼叫中心系统是连接老人、家属与服务人员的**服务调度核心枢纽**，承担老人紧急求助（SOS）、服务咨询、服务预约、投诉建议等电话/在线呼叫的接入、分发与处理职能。 + +本系统是养老服务体系中的"神经中枢"，也是政府监管部门评价平台服务质量的关键指标来源，对于平台的安全性和口碑具有决定性意义。 + +--- + +## 2. 建设目标 + +1. 提供7×24小时老人紧急求助响应能力（SOS一键呼叫→坐席接听→就近派单） +2. 实现来电弹屏，坐席第一时间获取老人档案与服务历史 +3. 构建录音质检体系，持续提升服务质量 +4. 提供智能IVR及工单流转，减少人工坐席压力 +5. 输出呼叫中心数据报表，支持政府监管与运营决策 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 来电弹屏 +- 通话录音管理 +- VIP客户分流 +- 智能IVR工单系统 +- 多方通话 +- 坐席监控 +- 录音质检 +- 数据报表 + +### 3.2 二级模块 + +- **来电弹屏**：来电号码识别→老人档案弹出（姓名/年龄/失能等级/历史工单/设备状态） +- **通话录音**：全程录音存储、按时间/坐席/主叫号码检索播放 +- **VIP分流**：设置优先级规则，高风险老人（独居/高失能）来电优先分配 +- **IVR工单**：语音导航菜单、意图识别、自动创建服务工单、转人工触发条件 +- **多方通话**：坐席+老人+家属+服务员三方通话，紧急情况协调 +- **坐席监控**：在线坐席数、通话时长、等待队列、坐席状态实时仪表盘 +- **录音质检**：随机抽查或AI自动质检（关键词+情感分析） +- **数据报表**：日/月呼入量、应答率、平均处理时长、SOS触发量 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 技术要点 | +| ----------- | ---------------------------------------------- | --------------------------------- | +| 来电弹屏 | 来电触发→CTI接口获取主叫→查老人档案→弹出工作台 | CTI中间件（阿里云呼叫中心/融云） | +| 智能IVR | 语音菜单→ASR识别→意图分类→服务路由 | ASR语音识别（科大讯飞/腾讯） | +| SOS紧急响应 | 设备SOS按下→呼叫中心立即振铃+老人位置推送 | IoT告警消息队列→WebSocket推送坐席 | +| AI录音质检 | 通话录音→ASR转写→关键词/合规检测→质检评分 | ASR + NLP（情感分析） | +| 工单流转 | 呼叫创建工单→分配服务员→执行→回访确认 | 工单引擎 + 状态机 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 具备客服工单模块（消费纠纷处理），但其与本系统存在根本性差异： + +| 能力需求 | mall 客服模块 | 结论 | +| --------------------------- | ---------------- | ------------------------ | +| CTI电话系统接入（来电弹屏） | 无 | 须独立建设 | +| SOS紧急告警接入 | 无 | 须独立建设 | +| 老人档案弹屏（非订单详情） | 无 | 须独立建设 | +| 录音管理与AI质检 | 无 | 须独立建设 | +| 坐席监控仪表盘 | 无 | 须独立建设 | +| 智能IVR | 无 | 须独立建设 | +| 服务工单（养老服务场景） | 仅有消费纠纷工单 | 业务逻辑完全不同，须重建 | + +mall 是通用电商平台，不具备CTI（Computer Telephony Integration）电话接入能力，强行在 mall 中叠加呼叫中心逻辑将导致架构崩溃。 + +--- + +## 5. 规划判断 + +**独立系统建设** + +- 呼叫中心接入层：对接云呼叫中心（阿里云/腾讯云）或自建Asterisk +- 坐席工作台：Vue3 PC Web（实时通信，WebSocket） +- 移动端（服务员接单）：uni-app +- 服务端：独立工单服务 + CTI中间件对接层 + +--- + +## 6. 需新增业务能力 + +1. **CTI系统集成**：电话线路接入、号码路由、来电识别 +2. **SOS紧急响应流程**：设备→呼叫中心→坐席响应→派单→处置→回执全流程 +3. **智能IVR配置工具**：可视化配置语音菜单树 +4. **录音存储与合规**：通话录音≥6个月存储，加密存储，访问审计 +5. **坐席工作台一体化**：打电话+查档案+创工单+分派任务一屏完成 +6. **服务工单生命周期**：呼叫→工单创建→分派→执行→回访→关单 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| --------------- | ------------------------------------------------------------------------------------- | +| `call_record` | id, caller_no, elder_id, agent_id, call_type, duration, recording_url, started_at | +| `call_ticket` | id, call_id, ticket_type, elder_id, description, priority, status, assignee_id | +| `ticket_action` | id, ticket_id, action_type, operator_id, note, action_time | +| `sos_event` | id, elder_id, device_id, trigger_type, location, agent_id, response_time, resolved_at | +| `ivr_config` | id, menu_tree(JSONB), version, is_active | +| `agent_session` | id, agent_id, status(online/busy/offline), current_call_id, session_start | +| `quality_check` | id, call_id, checker_id(human/AI), score, keywords_hit, issues, created_at | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ---------- | --------------------------------------------- | ------------------------- | +| 云呼叫中心 | 阿里云呼叫中心（CCC）/ 腾讯云呼叫中心（TCCC） | 电话线路接入、CTI | +| ASR | 科大讯飞 / 腾讯云语音识别 | IVR语音识别、录音转写 | +| 实时通信 | WebSocket | 坐席状态实时推送、SOS告警 | +| 消息队列 | RabbitMQ | IoT告警→呼叫中心异步解耦 | +| 录音存储 | OSS（加密桶） | 通话录音合规存储 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| ------------------ | ------------------------ | ------------ | +| IoT安全系统（09） | SOS设备告警事件接入 | 消息队列 | +| 数据库系统（02） | 老人档案弹屏查询 | 内部API | +| 居家养老管理（10） | 服务工单派发给服务员 | 内部API | +| 政府监管（01） | SOS响应时长、呼叫量统计 | 内部API | +| 定期巡访（03） | 巡访异常上报转入呼叫工单 | 内部消息队列 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | -------------------------------------------------------- | -------------------------------------- | +| 云呼叫中心费用 | 按分钟计费，高并发时成本高 | 评估坐席规模，合理选型（自建vs云服务） | +| SOS响应时效 | 老人紧急求助必须在30秒内响应 | 专属SOS队列 + 强制振铃全坐席 | +| 录音合规 | 通话录音涉及隐私 | 加密存储、访问审计、保留期满自动销毁 | +| 边界：不含在线客服 | 文字在线客服由运营管理系统（24）负责，本系统仅做电话呼叫 | 明确功能边界 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P1** + +| 分期 | 内容 | 前置条件 | +| ------ | --------------------------------- | --------------------------------- | +| 第一期 | SOS紧急响应 + 来电弹屏 + 基础工单 | 老人档案（02）、IoT设备（09）就绪 | +| 第二期 | IVR配置 + 录音管理 + 坐席监控报表 | — | +| 第三期 | AI录音质检 + VIP分流策略 | ASR质量验证后上线 | + +--- + +## 12. 结论 + +呼叫中心系统是养老平台的安全生命线，其 CTI 接入、SOS 紧急响应、来电弹屏等核心能力在 mall 中完全缺失，**必须作为独立系统建设**。 + +建议优先上线 SOS 紧急响应功能，作为平台第一期的核心安全保障，然后逐步完善 IVR 自助服务和 AI 质检能力，持续降低人工坐席运营成本。 diff --git a/07-养老需求及老人情况评估系统-模块规划.md b/07-养老需求及老人情况评估系统-模块规划.md new file mode 100644 index 0000000..f18fde7 --- /dev/null +++ b/07-养老需求及老人情况评估系统-模块规划.md @@ -0,0 +1,160 @@ +# 养老需求及老人情况评估系统 模块规划 + +--- + +## 1. 模块定位 + +养老需求及老人情况评估系统是养老服务体系的**服务入口与资质认证节点**，承担对老人进行综合能力评估（ADL日常生活能力量表、MMSE认知功能量表等）的数字化管理，是长护险认定、政府补贴核算、服务计划制定和等级护理的核心前置条件。 + +本系统的核心用户为**专业评估人员**（社工/护士/评估师），工作场景以移动端上门评估为主，后台管理为辅。 + +--- + +## 2. 建设目标 + +1. 实现评估标准和评估量表的在线配置与版本管理 +2. 提供移动端评估执行工具，支持评估人员上门时完成信息录入 +3. 构建评估数据的存储、查询、统计与上传功能 +4. 为长护险认定（18）、政府补贴（04）和服务计划（10）提供评估结论依据 +5. 支持政府监管部门查阅评估数据与统计报告 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 综合评估管理 +- 评估标准配置 +- 评估内容配置 +- 评估人员移动端 +- 评估数据管理 +- 统计分析 + +### 3.2 二级模块 + +- **综合评估管理**：评估任务分配、评估进度跟踪、评估结论审核 +- **评估标准配置**：国标评估标准（MNA/ADL/MMSE）导入、地方标准自定义 +- **评估内容配置**：量表题目管理、评分规则配置、评估报告模板 +- **评估人员移动端**：待评估老人列表、上门GPS打卡、量表填写、拍照采集、提交审核 +- **评估数据管理**：评估记录查询/修改授权/归档、历次评估对比、文件上传审核 +- **统计分析**：按区域/等级/时段的评估完成率、失能等级分布、趋势分析 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 技术要点 | +| -------------- | -------------------------------------- | ----------------------- | +| ADL量表 | 10项日常生活能力评估，自动计算失能等级 | 动态表单 + 自动评分算法 | +| MMSE量表 | 30分制认知功能筛查量表 | 动态表单 + 评分规则引擎 | +| GPS打卡到位 | 到达老人地址100m内才可开始评估 | 高德定位 + 地理围栏 | +| 评估报告生成 | 根据量表结果自动生成格式化评估报告 | 报告模板引擎（PDF生成） | +| 评估数据上传 | 评估结论上传至民政/医保系统 | ⚠️ 待确认接口规范 | +| 多版本量表管理 | 支持国家标准量表与地方特色量表并存 | 版本控制 + 权限分配 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是通用电商平台，不具备任何医疗评估相关能力： + +| 能力需求 | mall 现状 | 结论 | +| ------------------------ | ------------------------ | ------------ | +| 临床量表（ADL/MMSE）管理 | 无 | 须独立建设 | +| 医学评分算法 | 无 | 须独立建设 | +| 评估报告PDF生成 | 无 | 须独立建设 | +| 老人档案关联 | 无老人实体 | 须依托02模块 | +| 评估人员角色体系 | 无（mall无专业评估角色） | 须重建 | +| GPS围栏+问卷一体化 | 无 | 须新建 | + +mall 是通用电商平台，不具备专业医养评估能力，强行堆入评估功能会导致医疗数据与商业数据混存，违反数据合规要求。 + +--- + +## 5. 规划判断 + +**独立系统建设** + +- 移动端：uni-app（小程序 + H5，评估人员使用） +- 后台管理端：Vue3 PC Web +- 服务端：独立API，评估结论通过接口输出给18/10/04等模块 +- 评估数据存储：独立表结构，关联02号模块老人档案 + +--- + +## 6. 需新增业务能力 + +1. **量表引擎**：动态题目配置 + 分支逻辑 + 自动评分 + 等级判定（国标ADL/MMSE/MNA等） +2. **评估流程管理**：预约→分配→执行→提交→审核→归档的完整工作流 +3. **评估报告模板**：可配置的评估报告格式，支持机构定制 +4. **评估历史对比**：展示同一老人多次评估结果的趋势变化 +5. **评估数据权威性**：评估结论一旦审核通过不可随意修改（记录变更日志） +6. **批量导出**：支持按时间/区域批量导出评估报告（用于政府报备） + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------------- | ----------------------------------------------------------------------------------------------- | +| `assessment_task` | id, elder_id, assignee_id, scheduled_date, status, visit_checkin_time, visit_photo | +| `assessment_record` | id, task_id, scale_type(ADL/MMSE), form_data(JSONB), total_score, disability_grade, assessor_id | +| `assessment_scale` | id, name, version, questions(JSONB), scoring_rules(JSONB), is_active | +| `assessment_report` | id, record_id, report_pdf_url, generated_at, approved_by, approved_at | +| `disability_grade_config` | id, scale_type, score_range_min, score_range_max, grade_name, grade_code | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| -------- | ------------------------------- | ------------------------- | +| PDF生成 | iText / Flying Saucer（服务端） | 评估报告生成 | +| 定位 | 高德SDK | GPS打卡到位验证 | +| 电子签名 | 移动端Canvas手写签名 | 老人/家属签字确认评估结论 | +| 动态表单 | JSON Schema驱动自研 | 量表题目动态渲染 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| ------------------ | -------------------------- | --------------------- | +| 数据库系统（02） | 老人档案读取、失能等级写回 | 内部API | +| 长护险（18） | 评估结论作为长护险认定依据 | 内部API（只读输出） | +| 政府补贴（04） | 评估等级作为补贴核算输入 | 内部API | +| 居家养老管理（10） | 评估结论影响服务计划制定 | 内部API | +| 政府监管（01） | 评估统计数据汇总 | 内部API | +| 民政/医保系统 | 评估结论上报 | ⚠️ 待确认各省接口规范 | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | ---------------------------------------- | ---------------------------------------- | +| 量表标准差异 | 各省市长护险评估标准不同 | 量表引擎支持多套标准并存，按地区切换 | +| 评估结论异议 | 老人/家属对评估等级不服 | 提供复核申请流程，保留原始照片和填写记录 | +| 数据权威性 | 评估结论用于补贴核算，误录影响重大 | 双人核审机制 + 修改留痕 | +| 边界：不含病历管理 | 本系统仅做养老能力评估，不做完整医疗病历 | 医疗病历由20号（慢性病管理）负责 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P1** + +| 分期 | 内容 | 前置条件 | +| ------ | ---------------------------------------- | ------------------ | +| 第一期 | 移动端评估执行 + ADL/MMSE量表 + 报告生成 | 老人档案（02）就绪 | +| 第二期 | 评估工作流（预约→审核→归档） + 统计分析 | — | +| 第三期 | 与长护险/补贴系统对接 + 政务数据上报 | 接口确认后 | + +--- + +## 12. 结论 + +养老需求评估系统是整个服务体系的"入口闸门"，评估结论直接决定长护险认定、补贴核算和服务计划，其医疗专业属性（量表、评分算法、报告合规）使其完全无法在 mall 平台基础上构建。 + +**必须独立建设**，且需在P1阶段优先完成，确保后续长护险（18）、补贴审批（04）、服务计划（10）有可靠的评估数据支撑。 diff --git a/08-智慧康养健康管理系统-模块规划.md b/08-智慧康养健康管理系统-模块规划.md new file mode 100644 index 0000000..518522b --- /dev/null +++ b/08-智慧康养健康管理系统-模块规划.md @@ -0,0 +1,164 @@ +# 智慧康养健康管理系统 模块规划 + +--- + +## 1. 模块定位 + +智慧康养健康管理系统是基于**老人健康档案和智能设备数据**的预防性健康干预平台，通过综合健康档案管理、实时生命体征监控、中医体质辨识、健康评估分析和个性化健康管理方案，为老人提供持续性的健康关注服务。 + +本系统属于**健康管理（大健康）** 领域，介于养老服务与医疗之间，核心用户为家庭医生、健康管理师及老人/家属端。 + +--- + +## 2. 建设目标 + +1. 建立老人综合健康档案，记录基础体检数据、慢病史、用药记录 +2. 对接IoT健康设备（血压计/血糖仪/心率监测带），实现实时数据采集 +3. 提供中医体质辨识评估（九种体质分型），输出调养建议 +4. 构建个性化健康管理方案，支持家庭医生在线制定与跟踪 +5. 提供健康评估报告，支持健康小屋服务场景 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 综合健康档案 +- 健康数据实时监控 +- 中医体质辨识 +- 智能设备管理 +- 健康小屋服务 +- 健康管理方案 +- 健康评估分析 + +### 3.2 二级模块 + +- **综合健康档案**：体检记录、慢病史、用药清单、家族病史、过敏史 +- **实时监控**：血压/心率/血糖/血氧实时采集、趋势曲线、阈值告警 +- **中医辨识**：九种体质评估量表、体质报告、调养方案（饮食/起居/运动） +- **智能设备管理**：设备绑定/解绑、设备状态监控、采集频率配置 +- **健康小屋**：社区健康小屋预约、到场体检数据采集、健康咨询 +- **健康方案**：家庭医生制定个性化方案（运动/饮食/用药提醒/复查计划） +- **健康评估**：周/月健康评估报告、健康趋势分析、风险预警 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 技术要点 | +| --------------- | ----------------------------------------------- | --------------------- | +| IoT设备数据采集 | 蓝牙/WiFi健康设备实时上报体征数据 | MQTT协议 / 设备SDK | +| 阈值告警 | 个性化阈值（每人可配置），超标自动推送家属/护士 | 时序数据库 + 规则引擎 | +| 健康趋势图 | 展示过去30/90天体征变化趋势 | ECharts折线图 | +| 中医体质量表 | 60题标准中医体质量表，自动计算9种体质得分 | 动态表单 + 评分算法 | +| 健康方案提醒 | 按处方/方案定时提醒老人用药/运动 | 定时任务 + 微信推送 | +| 健康小屋预约 | 在线预约社区健康检测站时间段 | 预约日历 + 出行提醒 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是电商交易平台，不具备任何健康管理能力： + +| 能力需求 | mall 现状 | 结论 | +| -------------------------- | --------- | ------------------------ | +| 健康档案（慢病/用药/体检） | 无 | 须独立建设 | +| IoT体征设备接入 | 无 | 须独立建设 | +| 时序体征数据存储/查询 | 无 | 须独立建设（时序数据库） | +| 中医体质量表评估 | 无 | 须独立建设 | +| 个性化健康方案管理 | 无 | 须独立建设 | +| 阈值告警规则引擎 | 无 | 须独立建设 | + +--- + +## 5. 规划判断 + +**独立系统建设** + +- 老人/家属端：uni-app（小程序+H5） +- 家庭医生端：Vue3 Web 或 uni-app +- 服务端：独立API，时序数据库（TimescaleDB）处理体征流数据 +- IoT接入层：MQTT Broker + 设备SDK适配层 + +--- + +## 6. 需新增业务能力 + +1. **IoT设备协议适配**：蓝牙BLE + WiFi健康设备（需与IoT管理系统16协同） +2. **时序数据存储与查询**：高频体征数据（每分钟写入）的高效存储与查询 +3. **个性化阈值引擎**：按老人配置血压/血糖/心率的高低阈值及告警策略 +4. **中医体质评估算法**：国标中医体质量表（CCMQ）评分与体质分类 +5. **健康报告自动生成**：每月健康摘要报告，发送家属端 +6. **家庭医生工作台**：管理所服务老人的健康方案和预警 + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ----------------------- | -------------------------------------------------------------------------------- | +| `health_profile` | elder_id, chronic_diseases(array), medications(JSONB), allergies, family_history | +| `health_record` | id, elder_id, metric_type, value, unit, collected_at, source(device/manual) | +| `health_device_binding` | elder_id, device_id, device_type, bind_at, status | +| `health_threshold` | elder_id, metric_type, min_warning, max_warning, min_danger, max_danger | +| `health_alert` | id, elder_id, metric_type, value, level, notified_at, ack_status | +| `tcm_assessment` | elder_id, answers(JSONB), constitution_type, generated_at, report_url | +| `health_plan` | id, elder_id, doctor_id, start_date, end_date, items(JSONB), status | +| `health_checkin` | id, station_id, elder_id, metrics_collected(JSONB), checkin_at | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ---------- | ------------------------- | ------------------ | +| 时序数据库 | TimescaleDB（PG扩展） | 体征时序数据存储 | +| IoT接入 | EMQX（MQTT Broker） | 健康设备数据接入 | +| 数据可视化 | ECharts | 体征趋势图表 | +| 推送 | 微信模板消息 + 系统推送 | 健康提醒、告警通知 | +| 定时任务 | 分布式定时调度（XXL-JOB） | 每月健康报告生成 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| -------------------- | ----------------------------- | -------- | +| IoT管理（16） | 健康设备状态、异常告警 | 消息队列 | +| 数据库系统（02） | 老人档案关联 | 内部API | +| 安全系统（09） | 生命体征危急预警→SOS触发 | 消息队列 | +| 慢性病管理（20） | 慢病历史数据共享 | 内部API | +| 呼叫中心（06） | 健康危急告警→呼叫中心呼出关怀 | 消息队列 | +| 全生命周期监测（23） | 健康数据汇入监测平台 | 内部API | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------- | ------------------------------------------ | ------------------------------------------------------ | +| 设备数据准确性 | 家用健康设备精度有限，不可作为临床诊断依据 | 系统界面明确标注"仅供健康参考，非医学诊断" | +| 健康数据合规 | 体征数据属于敏感个人信息 | 国密加密存储、审计日志 | +| IoT设备兼容性 | 市面设备品牌众多，协议各异 | 优先接入主流品牌（乐心/鱼跃/华为），建立设备厂商白名单 | +| 边界：不含开药/诊断 | 本系统不提供医疗诊断，不开具处方 | 诊断/处方由慢性病管理（20）或HIS系统负责 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2** + +| 分期 | 内容 | 前置条件 | +| ------ | ---------------------------------------- | ------------------ | +| 第一期 | 健康档案管理 + 手动录入体征 + 基础趋势图 | 老人档案（02）就绪 | +| 第二期 | IoT设备接入 + 阈值告警 + 家庭医生工作台 | IoT管理（16）就绪 | +| 第三期 | 中医体质辨识 + 健康报告 + 健康小屋预约 | — | + +--- + +## 12. 结论 + +智慧康养健康管理系统是大健康赛道的核心服务，IoT体征采集、时序数据处理、中医体质评估等核心能力在 mall 中完全缺失，**必须独立建设**。 + +建议P1阶段先完成基础健康档案（配合02模块），P2阶段补充IoT接入和智能告警。注意与慢性病管理（20）的边界划分：本系统偏"预防与监测"，慢性病管理偏"诊断与治疗"。 diff --git a/09-智慧康养安全系统-模块规划.md b/09-智慧康养安全系统-模块规划.md new file mode 100644 index 0000000..e826ef5 --- /dev/null +++ b/09-智慧康养安全系统-模块规划.md @@ -0,0 +1,166 @@ +# 智慧康养安全系统 模块规划 + +--- + +## 1. 模块定位 + +智慧康养安全系统是以**IoT设备 + AI算法**为核心的老人安全保障系统，通过防走失定位、生命体征危急监测、主动报警、紧急求助（SOS）、视频关爱和智能安防等手段，为老人提供全天候的人身安全保障，并在发现危险时触发呼叫中心应急响应。 + +本系统是整个平台安全网的"感知层"，是呼叫中心（06）SOS响应的数据来源。 + +--- + +## 2. 建设目标 + +1. 实现老人佩戴设备的实时GPS定位与电子围栏（防走失） +2. 监测生命体征（心率/跌倒）的危急状态，超阈值自动告警 +3. 支持老人主动SOS呼救（设备按键/APP），触发呼叫中心响应 +4. 提供家属/护理员视频关爱能力（与老人视频通话） +5. 集成环境监测（燃气/烟雾/门磁）与智能安防设备 + +--- + +## 3. 核心功能范围 + +### 3.1 一级模块 + +- 防走失定位 +- 生命体征危急监测 +- 主动报警（SOS） +- 紧急求助通道 +- 监护体系 +- 环境监测 +- 视频关爱 +- 智能安防 + +### 3.2 二级模块 + +- **防走失定位**：实时GPS追踪、历史轨迹回放、电子围栏（离开安全区触发告警） +- **生命体征监测**：心率/血氧实时监测、异常告警、跌倒检测（加速度传感器） +- **主动报警（SOS）**：设备端SOS按键触发、APP端一键SOS、大声呼叫检测 +- **紧急求助通道**：SOS→呼叫中心实时振铃→老人位置推送→就近派单闭环 +- **监护体系**：家属监护绑定、监护权限分级（查看位置/接收告警） +- **环境监测**：烟雾报警器/燃气泄漏检测/门磁传感器接入 +- **视频关爱**：家属与老人发起视频通话（需老人同意）、定时视频关怀提醒 +- **智能安防**：摄像头接入（固定点位监控，非隐私区域）、异常行为检测 + +### 3.3 核心功能说明 + +| 功能 | 描述 | 技术要点 | +| ------------ | -------------------------------------- | --------------------------- | +| 电子围栏 | 设置安全区域多边形，老人离开后秒级告警 | GIS地理围栏 + MQTT推送 | +| 跌倒检测 | 设备三轴加速度异常模式识别 | 设备端算法 + 服务端确认 | +| SOS响应链路 | 设备SOS→MQTT→消息队列→呼叫中心坐席振铃 | MQTT + RabbitMQ + WebSocket | +| 视频通话 | 端到端加密视频通话（需设备支持） | WebRTC / 音视频SDK | +| 环境告警联动 | 烟雾告警→自动呼叫紧急联系人 | 设备事件 + 自动外呼 | + +--- + +## 4. 与现有 mall 的关系 + +**契合度：D（不适配）** + +mall 是通用电商平台，完全不具备安全监控与IoT设备接入能力： + +| 能力需求 | mall 现状 | 结论 | +| ----------------------- | --------- | ----------------------------- | +| GPS定位与地理围栏 | 无 | 须独立建设 | +| IoT设备事件接入（MQTT） | 无 | 须独立建设 | +| SOS紧急响应链路 | 无 | 须独立建设 | +| 跌倒检测算法 | 无 | 须独立建设（或集成设备端SDK） | +| 视频通话 | 无 | 须独立建设 | +| 环境传感器接入 | 无 | 须独立建设 | + +mall 是通用电商平台，不具备IoT设备通信层，强行加入会导致架构崩溃。 + +--- + +## 5. 规划判断 + +**独立系统建设** + +- 家属/老人端：uni-app（位置查看、SOS触发、视频通话） +- 服务端：独立IoT接入服务 + 告警处理服务 +- IoT层：MQTT Broker 接收设备上报 +- 与呼叫中心（06）通过消息队列对接，实现SOS闭环 + +--- + +## 6. 需新增业务能力 + +1. **MQTT设备通信层**：标准化IoT设备上报协议，支持不同品牌设备接入 +2. **地理围栏服务**：按老人配置安全区域，实时检测越界行为 +3. **跌倒算法集成**：对接设备厂商跌倒检测SDK，或基于加速度数据自研算法 +4. **告警优先级分队列**：跌倒/SOS（最高优先级）> 心率异常 > 围栏越界 > 环境告警 +5. **家属告警推送**：多通道推送（微信服务通知 + APP推送 + 短信） +6. **视频通话集成**：低延迟音视频SDK，支持老人设备（平板/智能屏） + +--- + +## 7. 需新增数据模型 + +| 模型 | 关键字段 | +| ------------------ | ------------------------------------------------------------------------------------------------- | +| `safety_device` | id, elder_id, device_type, device_sn, bind_at, battery_level, last_heartbeat | +| `location_track` | id, device_id, elder_id, lat, lng, speed, timestamp | +| `geo_fence` | id, elder_id, fence_name, polygon_points(JSONB), alert_type | +| `safety_alarm` | id, elder_id, alarm_type(fall/sos/fence/env), severity, device_id, location, triggered_at, ack_at | +| `guardian_binding` | elder_id, guardian_user_id, relation_type, permission_level, notify_types(array) | +| `env_sensor` | id, elder_id, sensor_type(smoke/gas/door), location_desc, last_reading, status | +| `video_care_log` | id, initiator_id, elder_id, call_type, duration, started_at, end_reason | + +--- + +## 8. 需新增技术栈 / 第三方能力 / 中间件 + +| 类别 | 技术选型 | 用途 | +| ----------- | --------------------------------------- | ---------------------- | +| MQTT Broker | EMQX | IoT设备消息接入 | +| GIS | 高德 Web服务 API | 地理围栏计算、轨迹回放 | +| 音视频 | 腾讯云实时音视频（TRTC）/ 声网（Agora） | 家属视频关爱 | +| 消息队列 | RabbitMQ / Kafka | 告警异步解耦 | +| 推送 | 极光/腾讯推送 + 短信 | 家属多通道告警通知 | + +--- + +## 9. 外部系统对接关系 + +| 对接方 | 内容 | 方式 | +| ---------------- | -------------------------------------------- | -------------------- | +| 呼叫中心（06） | SOS/跌倒告警→坐席振铃响应 | 消息队列 → WebSocket | +| IoT管理（16） | 设备注册、状态同步、固件升级 | 内部API | +| 健康管理（08） | 体征危急值→健康告警 | 消息队列 | +| 政府监管（01） | SOS事件统计、响应时效汇报 | 内部API | +| 数据库系统（02） | 老人档案查询、档案写回（紧急联系人通知记录） | 内部API | + +--- + +## 10. 风险与边界 + +| 风险 | 说明 | 应对 | +| ------------------ | ---------------------------------------- | ----------------------------------------------- | +| 设备电池续航 | GPS定位高频上报耗电快 | 分级上报频率（活动时高频/静止时低频） | +| 误报率 | 跌倒/围栏告警误报会导致家属恐慌 | 设备端初步过滤 + 服务端二次确认（延迟10秒确认） | +| 视频通话合规 | 在老人居室内录像涉及隐私 | 明确告知，家属视频前需老人端统一确认 | +| 网络中断 | 设备离线时无法实时告警 | 设备本地缓存告警 + 恢复网络后立即上报 | +| 边界：不含设备采购 | 本系统负责软件接入，设备采购由运营方决定 | 建立设备入网认证标准 | + +--- + +## 11. 实施优先级与分期建议 + +**优先级：P2（但SOS功能需在P1阶段配合呼叫中心完成）** + +| 分期 | 内容 | 前置条件 | +| -------- | ------------------------------------------ | ------------------ | +| P1配合 | SOS设备接入 + 呼叫中心联动（核心安全底线） | 呼叫中心（06）就绪 | +| P2第一期 | GPS定位 + 电子围栏 + 基础告警 | IoT管理（16）就绪 | +| P2第二期 | 跌倒检测 + 环境监控 + 视频关爱 | — | + +--- + +## 12. 结论 + +智慧康养安全系统是平台安全保障网的感知层，其 IoT 设备接入、地理围栏、SOS 响应链路等核心能力在 mall 中完全缺失，**必须独立建设**。 + +SOS→呼叫中心的紧急响应链路具有生命安全意义，应作为P1阶段与呼叫中心（06）联合上线的优先功能，其余能力在P2阶段逐步完善。