创建契合度及模块规划仓库
This commit is contained in:
169
模块规划/04-智慧康养政府及上级企业审批业务系统-模块规划.md
Normal file
169
模块规划/04-智慧康养政府及上级企业审批业务系统-模块规划.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# 智慧康养政府及上级企业审批业务系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养政府及上级企业审批业务系统是面向**政府主管部门（民政局/卫健委）及上级集团企业管理人员**的多级行政审批平台，承担补贴申请审核、企业资质审核、家庭床位审批、新闻发布及建议反馈管理等行政审批职能。
|
||||
|
||||
本系统的核心是**审批工作流引擎**，支持多级审批（街道→区→市）、权限管理和微信端移动审批，是连接政府行政决策与平台业务系统的关键枢纽。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现民政补贴申请的在线提交、多级审核与结果下发闭环
|
||||
2. 支持企业资质审核（服务商、机构）的标准化审批流程
|
||||
3. 构建家庭床位改造申请的全流程审批管理
|
||||
4. 提供微信端移动审批能力，提升政府工作人员的审批效率
|
||||
5. 支持政府新闻/通知的发布管理与居民建议反馈处理
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 微信端登录与入口
|
||||
- 补贴申请审核
|
||||
- 企业资质审核
|
||||
- 家庭床位审核
|
||||
- 多级审核引擎
|
||||
- 权限管理
|
||||
- 新闻发布
|
||||
- 建议反馈
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **微信端登录**：政府工作人员微信扫码登录、身份绑定、权限初始化
|
||||
- **补贴申请审核**：补贴类型配置、申请材料查阅、审核意见填写、退回/通过/挂起状态管理
|
||||
- **企业资质审核**：服务商/机构申请列表、材料核验（营业执照/许可证）、黑名单管理
|
||||
- **家庭床位审核**：改造申请列表、实地核查结果录入、改造资金核定、竣工验收
|
||||
- **多级审核引擎**：审批节点配置（街道→区→市）、超时自动提醒、代审/转审
|
||||
- **权限管理**：按行政区划的审批角色分配、数据可见范围设置
|
||||
- **新闻发布**：通知/新闻/政策文件的富文本编辑与发布
|
||||
- **建议反馈**：居民/服务商反馈列表、回复、分类统计
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | ------------------------------------------- | ----------------------------- |
|
||||
| 多级审核流 | 配置审批节点、条件分支（金额阈值→升级审核） | 审批流引擎（如Activiti/自研） |
|
||||
| 补贴申请审核 | 审核老人补贴资格、金额核定、批次下发 | 业务规则引擎 + 批处理 |
|
||||
| 企业资质审核 | OCR识别营业执照/许可证，自动提取关键字段 | OCR第三方API |
|
||||
| 微信端审批 | 待审list + 审核详情 + 一键通过/退回 | uni-app微信小程序 |
|
||||
| 竣工验收 | 家庭床位改造完成后的图片+审核员现场确认 | 移动端拍照 + 电子签名 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 的核心流程是消费者下单→商家接单→骑手配送→消费者确认收货，整个流程以"消费行为"驱动。
|
||||
|
||||
本系统的核心流程是申请提交→多级政府审核→行政决定下发，整个流程以"行政审批"驱动：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| -------------------------- | --------------------------- | ------------------ |
|
||||
| 多节点审批工作流引擎 | 无（无审批流概念） | 须独立建设 |
|
||||
| 政府角色体系（街道/区/市） | 无 | 须独立建设 |
|
||||
| 补贴核算规则引擎 | 无 | 须独立建设 |
|
||||
| OCR证照识别 | 无 | 须独立建设 |
|
||||
| 家庭床位申请全流程 | 无 | 须独立建设 |
|
||||
| 行政文件/新闻发布 | 仅有CMS文章管理（商城公告） | 领域不同，不可复用 |
|
||||
|
||||
mall 是通用电商平台，不具备行政审批能力，强行为其添加政府审批逻辑会导致架构混乱和权限体系崩溃。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设**
|
||||
|
||||
- 移动端：uni-app（微信小程序，政府工作人员使用）
|
||||
- PC端：Vue3 Web管理后台（主审批界面）
|
||||
- 服务端：独立审批流引擎 + 业务API
|
||||
- 工作流引擎：自研轻量级或集成 Camunda/Flowable（根据复杂度决策）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **可配置审批流引擎**：支持管理员在线配置审批节点、条件分支、超时策略
|
||||
2. **补贴核算规则库**：按老人失能等级、服务类型、地区标准的补贴金额计算
|
||||
3. **材料OCR识别**：营业执照、身份证、许可证关键信息自动提取
|
||||
4. **批次审批**：支持对同一批补贴申请的批量通过/退回
|
||||
5. **电子签章**：审批决定需支持电子签章，具备法律效力
|
||||
6. **消息通知**：审批结果主动推送至申请方（微信模板消息）
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| -------------------------- | ------------------------------------------------------------------------------ |
|
||||
| `approval_flow_def` | id, name, nodes(JSONB), conditions(JSONB), version |
|
||||
| `approval_instance` | id, flow_def_id, biz_type, biz_id, current_node, status, submitter_id |
|
||||
| `approval_node_record` | id, instance_id, node_name, approver_id, action, opinion, action_time |
|
||||
| `subsidy_application` | id, elder_id, subsidy_type, amount_applied, amount_approved, period, documents |
|
||||
| `org_qualification_review` | id, org_id, org_type, material_urls, ocr_data(JSONB), status |
|
||||
| `home_bed_application` | id, elder_id, address, estimated_cost, inspector_id, inspect_report, status |
|
||||
| `gov_news` | id, title, content, category, publisher_id, published_at, status |
|
||||
| `feedback` | id, submitter_type, content, category, status, reply, replier_id |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | ----------------------- | -------------------- |
|
||||
| 工作流引擎 | Flowable / 自研轻量版 | 多级审批流配置与执行 |
|
||||
| OCR | 腾讯云OCR / 阿里云OCR | 证照信息自动识别 |
|
||||
| 电子签章 | 法大大 / 契约锁 | 审批决定电子签章 |
|
||||
| 推送 | 微信模板消息 / 服务通知 | 审批结果通知 |
|
||||
| 富文本编辑 | TinyMCE / WangEditor | 新闻/政策文件发布 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 说明 |
|
||||
| ------------------ | -------------------------- | ----------------- |
|
||||
| 数据库系统（02） | 老人档案、服务商资质 | 内部API调用 |
|
||||
| 家庭床位系统（15） | 床位改造申请数据来源 | 内部API |
|
||||
| 服务商管理（11） | 服务商资质审核结果下发 | 内部API |
|
||||
| 居家养老管理（10） | 补贴审核结果与服务计划关联 | 内部API |
|
||||
| 政府监管（01） | 审批数据汇总至监管大屏 | 内部API |
|
||||
| 民政局/政务平台 | 补贴拨付指令下发 | ⚠️ 待确认接口规范 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------ | --------------------------------------------- | -------------------------- |
|
||||
| 各地审批流程差异 | 不同省市民政补贴审批节点不同 | 审批流可配置化，避免硬编码 |
|
||||
| 电子签章法律效力 | 部分地区不承认电子签章 | 提供纸质备档导出功能 |
|
||||
| 审批超时 | 政府人员忙碌导致流程积压 | 自动催办、超时转派机制 |
|
||||
| 边界：不含资金拨付 | 补贴核定在本系统，实际拨付由财务/民政系统执行 | 明确接口，只输出拨付指令 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ----------------------------------------------- | ------------------------------ |
|
||||
| 第一期 | 企业资质审核 + 家庭床位审核（优先，有业务需求） | 15号模块家庭床位系统就绪 |
|
||||
| 第二期 | 补贴申请全流程 + 多级审批引擎 | 老人档案（02）和评估（07）完成 |
|
||||
| 第三期 | 微信端移动审批 + 电子签章 + 政务系统对接 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
审批业务系统是平台与政府行政流程的接口，核心能力（工作流引擎、政府角色体系、补贴规则引擎）在 mall 中完全缺失，**必须作为独立系统建设**。
|
||||
|
||||
建议工作流引擎采用可配置设计，以应对各地政府审批流程差异，避免因流程变化导致频繁改动代码。OCR与电子签章建议接入成熟的第三方SaaS服务，降低研发复杂度。
|
||||
173
模块规划/05-智慧康养系统管理中心-模块规划.md
Normal file
173
模块规划/05-智慧康养系统管理中心-模块规划.md
Normal file
@@ -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 框架内改造，应独立建设**，并将用户中心服务作为全平台的基础设施对外提供。
|
||||
166
模块规划/06-智慧康养呼叫中心系统-模块规划.md
Normal file
166
模块规划/06-智慧康养呼叫中心系统-模块规划.md
Normal file
@@ -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 质检能力，持续降低人工坐席运营成本。
|
||||
160
模块规划/07-养老需求及老人情况评估系统-模块规划.md
Normal file
160
模块规划/07-养老需求及老人情况评估系统-模块规划.md
Normal file
@@ -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）有可靠的评估数据支撑。
|
||||
164
模块规划/08-智慧康养健康管理系统-模块规划.md
Normal file
164
模块规划/08-智慧康养健康管理系统-模块规划.md
Normal file
@@ -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）的边界划分：本系统偏"预防与监测"，慢性病管理偏"诊断与治疗"。
|
||||
166
模块规划/09-智慧康养安全系统-模块规划.md
Normal file
166
模块规划/09-智慧康养安全系统-模块规划.md
Normal file
@@ -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阶段逐步完善。
|
||||
173
模块规划/10-智慧康养居家养老管理系统-模块规划.md
Normal file
173
模块规划/10-智慧康养居家养老管理系统-模块规划.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# 智慧康养居家养老管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养居家养老管理系统是面向**居家老人、上门服务员和机构管理员**的核心服务调度系统，承担老人档案管理、服务项目订单管理、家庭医生签约管理、老年活动中心管理及智能呼叫调度等职能。
|
||||
|
||||
本系统是整个平台服务量最大的模块，是居家养老"最后一公里"服务的落地载体。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 建立完整的居家老人服务档案体系，包含个人基本信息、服务历史、家庭关系
|
||||
2. 实现居家服务（上门护理/助浴/助餐/家政）的在线预约、派单和执行管理
|
||||
3. 构建家庭医生签约管理功能，支持线上问诊和服务计划制定
|
||||
4. 提供老年活动中心（日间照料）的入托/活动/绩效管理
|
||||
5. 集成智能呼叫调度，支持服务员端实时接单和工作台管理
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 老人档案管理
|
||||
- 服务订单管理
|
||||
- 服务项目管理
|
||||
- 家庭医生管理
|
||||
- 老年活动中心
|
||||
- 智能呼叫调度
|
||||
- 工作台管理
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **老人档案**：基本信息、家庭关系、失能等级（来自07评估）、紧急联系人、服务计划
|
||||
- **服务订单**：服务预约（老人/家属端）、订单分配（系统/手动）、服务执行确认（GPS打卡+照片）、评价
|
||||
- **服务项目**：服务目录维护（助浴/助餐/助洁/护理）、定价、服务时长标准
|
||||
- **家庭医生**：签约管理、服务计划制定、健康随访、在线咨询
|
||||
- **老年活动中心**：日间照料入托申请、活动课程、出勤记录、绩效报表
|
||||
- **智能呼叫**：老人一键呼叫→系统自动匹配就近服务员→推送接单通知
|
||||
- **工作台**：服务员端今日任务、路线规划、打卡记录、服务报告提交
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | --------------------------------------------- | -------------------------- |
|
||||
| 智能派单 | 根据老人地址+服务类型+服务员技能/距离自动分配 | GIS距离计算 + 技能匹配算法 |
|
||||
| GPS签到 | 服务员到达老人家地理围栏内才可开始服务 | 高德定位 + 地理围栏 |
|
||||
| 服务执行确认 | 服务完成后拍照/老人/家属电子签名 | 移动端拍照 + Canvas签名 |
|
||||
| 家庭医生签约 | 家庭医生与老人1:N签约，绑定服务计划 | 签约关系表 + 计划模板 |
|
||||
| 活动中心出勤 | 刷卡/人脸/签到记录日间照料出勤 | 一卡通API调用 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：C（低契合，部分可参考）**
|
||||
|
||||
mall 具备部分可参考的能力，但差异显著：
|
||||
|
||||
| 能力 | mall 现状 | 可复用程度 |
|
||||
| ------------------ | ------------------------- | ------------------------------------------- |
|
||||
| 用户下单与服务预约 | 有商品下单流程 | 参考结构，需大量改造（服务型订单≠商品订单） |
|
||||
| 骑手配送端 | 有骑手App（GPS接单/打卡） | 可参考移动端框架，核心逻辑差异大 |
|
||||
| 订单状态机 | 有（7种状态） | 参考状态机设计，适配服务订单状态 |
|
||||
| 工单/客服 | 有简单客服工单 | 不同场景，参考意义有限 |
|
||||
| 评价体系 | 有商品评分 | 改造成服务评价 |
|
||||
| 商品分类/目录 | 有SKU体系 | 可参考目录结构，服务无库存概念 |
|
||||
| **老人档案** | **无** | **须独立建设** |
|
||||
| **家庭医生签约** | **无** | **须独立建设** |
|
||||
| **活动中心管理** | **无** | **须独立建设** |
|
||||
| **GPS智能派单** | **无** | **须独立建设** |
|
||||
|
||||
**建设路径：mall + 独立微服务（C级）**
|
||||
|
||||
mall 的订单状态机和移动端框架可作为参考蓝本，但不建议直接在 mall 代码库中增量开发，需独立建设服务型订单系统，并通过 API 对接 mall 的支付能力（如果服务需要收费）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall + 独立微服务（以独立为主）**
|
||||
|
||||
- 老人/家属端：uni-app（小程序），复用 mall 的支付/登录组件
|
||||
- 服务员端：uni-app（独立应用，类似骑手端但完全重写）
|
||||
- 管理后台：Vue3 Web（独立）
|
||||
- 服务端：独立服务型订单服务（参考 mall 设计但独立部署）
|
||||
- 支付：对接 mall 现有支付网关（政府补贴/个人自费混合结算）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **服务型订单引擎**：服务订单（无库存概念）的预约→分配→签到→执行→确认→评价→结算
|
||||
2. **智能派单算法**：基于GIS距离 + 服务员技能 + 可用时间窗口的最优匹配
|
||||
3. **家庭医生签约与随访管理**：签约周期管理、随访计划提醒、在线咨询记录
|
||||
4. **补贴抵扣结算**：政府补贴额度 + 个人自费混合支付，支持长护险抵扣
|
||||
5. **服务质量监控**：服务员GPS轨迹核验、超时预警、服务评分聚合
|
||||
6. **老年活动中心管理**：日间照料预约、活动排班、出勤统计、绩效报表
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------------ | ----------------------------------------------------------------------------------------------------------- |
|
||||
| `home_service_order` | id, elder_id, service_type, scheduled_at, assignee_id, checkin_at, checkout_at, status, fee, subsidy_amount |
|
||||
| `service_catalog` | id, name, category, description, price, duration_min, required_skills |
|
||||
| `service_execution` | id, order_id, checkin_photo, checkout_photo, elder_signature, notes, result_confirmed |
|
||||
| `family_doctor_contract` | id, doctor_id, elder_id, start_date, end_date, plan_id, status |
|
||||
| `doctor_followup` | id, contract_id, date, method(online/offline), notes, health_data_ref |
|
||||
| `activity_center` | id, name, address, capacity, manager_id |
|
||||
| `day_care_booking` | id, elder_id, center_id, date, checkin_at, checkout_at |
|
||||
| `call_dispatch` | id, elder_id, call_type, dispatch_time, assignee_id, response_time |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ---------------- | -------------------------------- |
|
||||
| GIS | 高德路径规划API | 智能派单距离计算、服务员路线导航 |
|
||||
| 定位 | 高德SDK | 服务员GPS打卡 |
|
||||
| 电子签名 | Canvas手写签名 | 服务完成老人确认签字 |
|
||||
| 补贴结算 | 自研补贴计算引擎 | 政府补贴额度抵扣计算 |
|
||||
| 在线咨询 | 腾讯云IM / 融云 | 家庭医生与老人文字/语音咨询 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ---------------- | ---------------------------- | --------------- |
|
||||
| 评估系统（07） | 失能等级→服务计划制定依据 | 内部API（只读） |
|
||||
| 服务商管理（11） | 服务员来源、技能标签、考核分 | 内部API |
|
||||
| 长护险（18） | 补贴抵扣额度同步 | 内部API |
|
||||
| 呼叫中心（06） | 呼叫工单→服务派单 | 内部API |
|
||||
| 安全系统（09） | SOS触发→居家服务员就近响应 | 消息队列 |
|
||||
| mall支付（19） | 个人自费部分支付 | 内部支付网关 |
|
||||
| 数据库系统（02） | 老人档案读写 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ---------------------- | ---------------------------------------------- | ---------------------------------------- |
|
||||
| 补贴结算规则复杂 | 各省市补贴标准不统一 | 补贴规则可配置化，不硬编码 |
|
||||
| 服务员定位造假 | GPS打卡可能被外挂软件欺骗 | 设备+位置双重验证+照片时间戳 |
|
||||
| 家庭医生供给不足 | 签约需要真实医生资质 | 引入第三方家庭医生平台 ⚠️ 待确认合作模式 |
|
||||
| 边界：不含机构住院护理 | 本系统为居家上门服务，机构内护理由其他模块处理 | 明确服务范围 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------------ | -------------------------------- |
|
||||
| 第一期 | 老人档案 + 服务订单（预约+执行）+ 服务员端 | 数据库（02）、系统管理（05）就绪 |
|
||||
| 第二期 | 智能派单 + 补贴抵扣 + 评价体系 | 评估（07）、长护险（18）完成 |
|
||||
| 第三期 | 家庭医生签约 + 活动中心 + 统计报表 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
居家养老管理系统是平台服务量最大的核心模块，mall 的订单状态机和移动端框架有一定参考价值（C级契合），但老人档案、智能派单、家庭医生签约等核心业务能力在 mall 中完全缺失。
|
||||
|
||||
**建议以独立系统建设为主，参考 mall 设计模式，通过 API 对接 mall 的支付能力**，避免在 mall 内部堆砌医养业务逻辑导致架构污染。P1阶段优先完成核心服务订单闭环，家庭医生和活动中心在P1后期或P2补充。
|
||||
173
模块规划/11-智慧康养服务商管理系统-模块规划.md
Normal file
173
模块规划/11-智慧康养服务商管理系统-模块规划.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# 智慧康养服务商管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养服务商管理系统是连接**平台（政府/运营方）与服务供给侧（服务商/从业人员）** 的 B2G/B2B/B2C 三维业务系统，负责服务商的注册准入、资质审核、人员管理、服务范围配置、订单履约管理、信用评分和 IoT 服务监控（500+ 终端）。
|
||||
|
||||
本系统是整个平台"服务能力供给"的核心，服务商数量与质量直接决定居家养老、社区助餐等业务的履约能力。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现服务商在线注册申请→政府资质审核→平台入驻的完整准入流程
|
||||
2. 管理服务商人员档案、技能认证、绩效考核
|
||||
3. 支持服务商自主配置服务范围（区域）和服务项目（价格/时长）
|
||||
4. 构建服务商信用体系，基于服务完成率、评分、投诉率等维度动态评分
|
||||
5. 提供服务监控能力，对 500+ IoT 终端和服务执行进行实时追踪
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 服务商注册与审核
|
||||
- 服务商档案管理
|
||||
- 服务人员管理
|
||||
- 服务范围与项目管理
|
||||
- 订单管理
|
||||
- 绩效与考核体系
|
||||
- 信用评分体系
|
||||
- 服务监控
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **注册审核**：服务商申请→资质材料上传→审核→入驻通知→账号激活
|
||||
- **档案管理**：基本信息、营业执照、服务许可、合同管理、开票信息
|
||||
- **人员管理**：招募、技能认证（护工/护士/医生证）、排班、考勤
|
||||
- **服务范围**：地图选区设置服务覆盖区域、可承接服务类型
|
||||
- **订单管理**：待接单队列、执行中订单、历史订单、订单异常处置
|
||||
- **绩效考核**：月度绩效报表、服务完成率、评分均值、投诉率分析
|
||||
- **信用评分**：综合评分算法（完成率/投诉/证书效期等），等级标签
|
||||
- **服务监控**：500+ IoT 终端状态汇总、告警统计、设备分布地图
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------- | --------------------------------------------------------------------- | ---------------------------- |
|
||||
| 资质审核流程 | 材料OCR识别 + 人工审核 + 多级批准 | OCR + 工作流引擎 |
|
||||
| 服务区域配置 | 地图绘制多边形服务区域 | 高德地图绘图API + 多边形存储 |
|
||||
| 信用评分算法 | 加权综合评分 = 完成率×40% + 评分均值×30% + 投诉率×-20% + 证书效期×10% | 定期计算任务 |
|
||||
| 500+ 设备监控 | 实时展示所有设备在线率、告警数、最近上报 | MQTT状态聚合 + 分页仪表盘 |
|
||||
| 订单分析 | 服务商维度的订单量/收入/退款分析 | 统计服务 + 图表 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：B（中契合，商家管理可参考）**
|
||||
|
||||
mall 具备完整的商家（Merchant）管理体系，与本系统存在结构性相似：
|
||||
|
||||
| 能力 | mall 现状 | 可复用程度 |
|
||||
| -------------------- | ----------------------- | -------------------------------- |
|
||||
| 商家注册与审核 | 有（资质上传+人工审核） | B - 可参考审核流程，但字段需扩展 |
|
||||
| 商家商品/服务管理 | 有（商品目录+SKU） | B - 服务目录可参考，去除库存概念 |
|
||||
| 订单管理（商家侧） | 有（接单/拒单/发货） | B - 参考状态机，改造为服务型订单 |
|
||||
| 商家账单/提现 | 有 | B - 可直接复用或少量改造 |
|
||||
| 商家评分/评价 | 有 | B - 扩展为信用评分体系 |
|
||||
| **服务人员管理** | **无** | **须新建** |
|
||||
| **IoT设备监控** | **无** | **须新建** |
|
||||
| **地理服务区域配置** | **无** | **须新建** |
|
||||
| **信用评分算法** | **无** | **须新建** |
|
||||
| **政府准入审批** | **无** | **须新建（B2G部分）** |
|
||||
|
||||
**建设路径：mall 商家管理基础 + 大量独立微服务扩展**
|
||||
|
||||
建议在独立系统中参考 mall 商家管理的设计模式（审核流程、账单结算），但不在 mall 内部改造，以避免电商逻辑与医养业务逻辑的交叉污染。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall + 独立微服务（以独立为主，参考 mall B 级能力）**
|
||||
|
||||
- 服务商端：uni-app（小程序）
|
||||
- 平台管理端：Vue3 Web
|
||||
- 服务端：独立服务商服务（参考 mall 商家服务的设计架构）
|
||||
- IoT监控层：依托 IoT 管理（16）和安全系统（09）的数据聚合
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **服务商准入评审**：资质材料多维度核验（国标服务资质要求）
|
||||
2. **从业人员证件管理**：护理员/护士/医生证有效期自动预警
|
||||
3. **地理服务区域可视化配置**：服务商在地图上自助划定服务范围
|
||||
4. **信用评分引擎**：可配置权重的综合信用评分，等级自动更新
|
||||
5. **服务商资金分账**：订单完成后自动结算到服务商子账户
|
||||
6. **IoT监控聚合**：500+ 设备按服务商维度聚合展示状态
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ---------------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| `service_provider` | id, name, biz_license_no, service_license_no, district_code, credit_score, credit_grade, status |
|
||||
| `provider_qualification_doc` | provider_id, doc_type, doc_url, ocr_result(JSONB), expire_date, verify_status |
|
||||
| `provider_staff` | id, provider_id, name, cert_type, cert_no, cert_expire, skill_tags, status |
|
||||
| `provider_service_area` | provider_id, polygon_points(JSONB), effective_date |
|
||||
| `provider_service_catalog` | provider_id, service_catalog_id, price, min_duration_min, max_concurrent |
|
||||
| `provider_order` | id, provider_id, order_id (ref home_service_order), status, staff_id |
|
||||
| `provider_credit_record` | id, provider_id, score_before, score_after, reason, calc_at |
|
||||
| `provider_wallet` | provider_id, balance, frozen_amount, last_settled_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ------------------------- | ------------------------ |
|
||||
| GIS | 高德地图绘图API | 服务区域多边形绘制与存储 |
|
||||
| OCR | 腾讯云OCR | 营业执照/证书自动识别 |
|
||||
| 分账 | 微信商户分账 / 支付宝分账 | 服务费用自动分账给服务商 |
|
||||
| 定时任务 | XXL-JOB | 每日信用评分重算 |
|
||||
| 消息推送 | 微信模板消息 | 审核结果、订单通知 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ------------------ | ------------------------ | -------- |
|
||||
| 审批系统（04） | 服务商资质审批结论 | 内部API |
|
||||
| 居家养老管理（10） | 服务员派单、订单数据 | 内部API |
|
||||
| IoT管理（16） | 设备监控数据聚合 | 内部API |
|
||||
| 数据库系统（02） | 服务商档案写入、人员档案 | 内部API |
|
||||
| mall支付（19） | 服务费支付与分账 | 支付网关 |
|
||||
| 政府监管（01） | 服务商信用、服务量统计 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------ | -------------------------------- | --------------------------------------------- |
|
||||
| 服务商造假资质 | 伪造营业执照或资质证书 | OCR + 人工双重验证 + 工商查询API（⚠️ 待确认） |
|
||||
| 分账合规 | 资金分账需满足第三方支付监管要求 | 使用持牌支付机构的分账功能 |
|
||||
| 信用评分算法公平性 | 新入驻服务商样本量少，评分不准确 | 新商家保护期机制（前30单不计负评） |
|
||||
| 边界：不含服务员劳动合同 | HR管理和劳动合同不在本系统范围 | 仅管理技能资质和绩效，不涉及劳动关系 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ---------------------------------------- | -------------------------- |
|
||||
| 第一期 | 服务商注册审核 + 人员管理 + 服务目录配置 | 审批系统（04）就绪 |
|
||||
| 第二期 | 订单管理 + 服务区域配置 + 结算分账 | 居家养老（10）订单系统就绪 |
|
||||
| 第三期 | 信用评分 + IoT监控 + 绩效报表 | IoT管理（16）就绪 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
服务商管理系统是平台服务能力的供给端，mall 商家管理体系（审核流程、账单结算）对本模块具有中等参考价值（B级），但服务人员证件管理、地理服务区域、IoT监控等核心医养特性能力须独立建设。
|
||||
|
||||
**建议参考 mall 商家管理的设计模式独立建设**，通过API对接 mall 支付分账能力，避免在 mall 内部直接改造带来的代码耦合风险。
|
||||
160
模块规划/12-智慧康养志愿者管理系统-模块规划.md
Normal file
160
模块规划/12-智慧康养志愿者管理系统-模块规划.md
Normal file
@@ -0,0 +1,160 @@
|
||||
# 智慧康养志愿者管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养志愿者管理系统是基于**"时间银行"公益机制**的志愿服务管理平台，核心创新在于通过区块链技术存证志愿服务时长，并允许志愿者以积累的"公益时间"兑换礼品或未来的养老服务权益。
|
||||
|
||||
本系统的核心用户为社会志愿者（及其家庭），以及负责志愿服务调度的社区工作人员。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 构建志愿者注册、技能认证和服务调度管理体系
|
||||
2. 实现时间银行账户管理：服务时长记录→区块链存证→时间积分发放
|
||||
3. 提供礼品管理（200+ SKU）和时间积分兑换功能
|
||||
4. 支持志愿服务数据统计汇总，供政府监管部门查阅
|
||||
5. 通过公益激励机制吸引社会志愿者参与养老服务
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 志愿者注册与档案管理
|
||||
- 志愿服务发布与调度
|
||||
- 服务执行管理
|
||||
- 时间银行账户体系
|
||||
- 礼品管理与兑换
|
||||
- 统计报表
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **志愿者注册**：实名认证、技能标签（陪聊/助餐/助医/文体）、服务意愿设置
|
||||
- **服务发布**：社区发布服务需求、轮播/推送给合适志愿者
|
||||
- **服务执行**：志愿者签到（GPS打卡）、服务时长记录、老人确认
|
||||
- **时间银行**：时长积分账户余额、收支明细、区块链存证哈希查询
|
||||
- **礼品管理**：礼品目录（200+ SKU）、库存管理、积分价格配置
|
||||
- **兑换管理**：志愿者提交兑换申请、审核、实物/服务发放
|
||||
- **统计报表**：志愿者人数、服务时长、覆盖老人数、兑换数量
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | -------------------------------------- | ------------------------------------- |
|
||||
| 时间银行积分 | 每分钟服务 = 1积分，专用于养老服务兑换 | 积分引擎（独立于mall积分） |
|
||||
| 区块链存证 | 每笔服务记录上链，防止篡改 | 联盟链（蚂蚁链/腾讯云区块链）写入存证 |
|
||||
| 礼品200+ SKU | 实物礼品库存管理与积分兑换 | 类似 mall 商品SKU但无购买概念 |
|
||||
| GPS服务签到 | 到达服务地点才可开始计时 | 高德定位 + 地理围栏 |
|
||||
| 志愿者匹配 | 按技能标签+距离推送服务需求 | 技能过滤 + GIS距离排序 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
表面上礼品兑换与 mall 商品管理有结构相似性，但存在根本性差异：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ------------------------ | ------------------------------------ | -------------------------- |
|
||||
| 时间银行积分（公益时长） | 有积分体系，但为消费积分（购物赠送） | 业务逻辑完全不同，不可复用 |
|
||||
| 区块链存证 | 无 | 须独立建设 |
|
||||
| 礼品管理（兑换模式） | 有商品，但为销售模式 | 兑换无需支付，逻辑完全不同 |
|
||||
| 志愿者注册与技能管理 | 无志愿者实体 | 须独立建设 |
|
||||
| 志愿服务发布与调度 | 无 | 须独立建设 |
|
||||
| GPS服务计时 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备时间银行/公益激励的概念，积分体系的逻辑与商业电商积分完全不同，强行复用会造成数据模型混乱。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设**
|
||||
|
||||
- 志愿者端：uni-app（微信小程序）
|
||||
- 管理后台：Vue3 Web
|
||||
- 区块链存证：对接联盟链SDK（蚂蚁链/腾讯云区块链）
|
||||
- 礼品管理：独立实物库管系统（参考仓储管理）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **公益时间积分引擎**：独立于商业积分的时间积分体系，以分钟为单位计算
|
||||
2. **区块链存证接入**：每笔完成服务→生成服务证明→上链存证→返回存证哈希
|
||||
3. **志愿者技能标签体系**：标准化志愿服务技能分类（国标参考或自定义）
|
||||
4. **服务发布与匹配**：社区发布养老志愿服务需求，系统智能推送给匹配志愿者
|
||||
5. **礼品库存管理**：200+ SKU实物礼品入库/出库/预警
|
||||
6. **兑换审核流程**：积分兑换申请→库存核查→发货→确认收到
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------ |
|
||||
| `volunteer` | id, user_id, name, id_verified, skill_tags, status, time_bank_balance |
|
||||
| `volunteer_service_task` | id, community_id, task_name, skill_required, elder_id, scheduled_at, status |
|
||||
| `volunteer_service_record` | id, task_id, volunteer_id, checkin_at, checkout_at, minutes_earned, blockchain_hash |
|
||||
| `time_bank_ledger` | id, volunteer_id, change_type(earn/redeem), minutes, balance_after, related_id, created_at |
|
||||
| `blockchain_cert` | id, record_id, chain_type, tx_hash, block_height, cert_url, created_at |
|
||||
| `gift_catalog` | id, name, sku_code, image, point_cost, stock, category, status |
|
||||
| `gift_redemption` | id, volunteer_id, gift_id, quantity, total_points, address, status, tracking_no |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ------------------------- | -------------------- |
|
||||
| 区块链 | 蚂蚁链 BaaS / 腾讯云TBaaS | 志愿服务时长存证 |
|
||||
| 定位 | 高德SDK | GPS签到打卡 |
|
||||
| 库存管理 | 自研轻量WMS | 礼品出入库管理 |
|
||||
| 推送 | 微信模板消息 | 服务需求推送给志愿者 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ------------------ | ------------------------ | ------- |
|
||||
| 数据库系统（02） | 老人档案（服务对象信息） | 内部API |
|
||||
| 政府监管（01） | 志愿者服务统计数据 | 内部API |
|
||||
| 系统管理中心（05） | 志愿者账号管理 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------ | ---------------------------------------- | ------------------------------------- |
|
||||
| 区块链成本 | 上链每笔有Gas费用 | 采用联盟链（低成本）而非公链 |
|
||||
| 虚假签到 | 志愿者远程打卡骗取时间积分 | GPS围栏严格核验 + 老人确认签字 |
|
||||
| 礼品库存管理难度 | 200+ SKU需完善的WMS功能 | 分阶段上架，先以小规模验证 |
|
||||
| 时间银行可持续性 | 公益时间未来能否真正换取服务 | ⚠️ 该商业模式需业务方提前规划兑付规则 |
|
||||
| 边界：不含志愿者薪酬发放 | 志愿服务为公益性质，不涉及劳动合同和薪酬 | 仅时间积分，不含货币结算 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------ | ------------------ |
|
||||
| 第一期 | 志愿者注册 + 服务记录 + 基础时间积分 | 老人档案（02）就绪 |
|
||||
| 第二期 | 区块链存证 + 礼品兑换 | 区块链SDK选型确认 |
|
||||
| 第三期 | 服务匹配优化 + 统计报表 + 政府对接 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
志愿者管理系统虽然在礼品管理方面与 mall 有表面相似性，但时间银行（公益积分）与区块链存证的核心机制与商业电商积分逻辑完全不同，**不可在 mall 基础上改造，必须独立建设**。
|
||||
|
||||
建议区块链存证采用联盟链方案（阿里/腾讯BaaS），兼顾成本控制和存证可信度。礼品管理模块建议轻量实现，优先保证服务记录和时间积分的准确性与可信性。
|
||||
164
模块规划/13-智慧康养短信平台系统-模块规划.md
Normal file
164
模块规划/13-智慧康养短信平台系统-模块规划.md
Normal file
@@ -0,0 +1,164 @@
|
||||
# 智慧康养短信平台系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养短信平台系统是全平台的**消息基础设施**，为所有业务模块提供短信发送能力，包括业务通知短信（服务确认/审核结果/订单变更）、健康预警短信（体征异常推送家属）、系统告警短信（设备离线/SOS事件）以及模板管理、接口对接和发送统计等能力。
|
||||
|
||||
本系统是平台级基础能力，不面向终端用户直接提供界面，而是作为内部服务对其他模块暴露 API。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 提供统一的短信发送 API，所有业务模块通过统一入口发送短信，避免各模块各自对接运营商
|
||||
2. 管理短信模板，支持变量占位符（老人姓名/服务时间/家属联系方式）
|
||||
3. 实现健康预警短信的优先级发送（体征危急值 = 最高优先级）
|
||||
4. 提供发送统计与失败重试机制
|
||||
5. 支持多运营商/多通道切换，保障发送成功率
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 短信发送服务
|
||||
- 健康预警短信
|
||||
- 告警自动发送
|
||||
- 模板管理
|
||||
- 运营商接口对接
|
||||
- 发送统计
|
||||
- 权限管理
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **短信发送服务**：单发、群发、定时发送 API
|
||||
- **健康预警**：健康管理系统（08）触发危急值短信，优先级队列
|
||||
- **告警自动发送**：安全系统（09）SOS/跌倒/走失告警短信自动发送给家属/护工
|
||||
- **模板管理**：内置系统模板 + 自定义模板，工信部报备管理
|
||||
- **运营商对接**：阿里云短信/腾讯云短信/云之讯等多通道配置，自动故障切换
|
||||
- **发送统计**：每日/月发送量、成功率、费用统计、模板使用排行
|
||||
- **权限管理**：各模块调用限额、IP白名单、API密钥管理
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | ------------------------------------------------------ | ------------------------- |
|
||||
| 统一短信API | 内部HTTP API接口，接收目标号码+模板+变量，返回发送结果 | RESTful API + 异步回调 |
|
||||
| 优先级队列 | SOS告警 > 健康危急 > 业务通知，高优先级跳过排队 | 分级消息队列（多个Queue） |
|
||||
| 多通道切换 | 主通道失败→自动切换备用通道（<30s内） | 健康检查 + 故障转移逻辑 |
|
||||
| 模板变量渲染 | 模板中 ${name}、${time} 占位符替换 | 字符串模板引擎 |
|
||||
| 失败重试 | 发送失败后按指数退避重试（最多3次） | 重试队列 + 退避算法 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：C（低契合，架构可参考但不可直接复用）**
|
||||
|
||||
mall 自身集成了短信发送功能（注册验证码/订单通知），但：
|
||||
|
||||
| 能力 | mall 现状 | 结论 |
|
||||
| ---------------- | ------------------------- | -------------------------------- |
|
||||
| 短信发送基础能力 | 有（阿里云短信SDK集成） | 可参考实现方式，但未做成独立服务 |
|
||||
| 模板管理界面 | 无（模板硬编码在业务层） | 须新建专项管理界面 |
|
||||
| 优先级消息队列 | 无 | 须新建 |
|
||||
| 多通道故障切换 | 无 | 须新建 |
|
||||
| 健康预警短信业务 | 无（纯电商领域无此需求） | 须新建 |
|
||||
| 多模块统一API | 无（短信dispersed在各处） | 须统一接入点设计 |
|
||||
|
||||
**建设路径：独立微服务（C→D，以独立为主）**
|
||||
|
||||
鉴于全平台27个模块都需要短信能力，建议将本系统建设为独立的基础设施微服务（类似短信网关），而非在 mall 中扩展。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立微服务（短信基础设施）**
|
||||
|
||||
- 无独立用户界面（仅有内部管理后台）
|
||||
- 对内：提供HTTP/gRPC短信发送API
|
||||
- 对外：对接阿里云/腾讯云短信平台
|
||||
- 管理界面：轻量级Vue3 Web（模板管理+统计查看）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **统一短信网关API**：标准化短信发送接口（单发/批量发/定时发）
|
||||
2. **模板管理与工信部报备**：短信模板的创建、审核状态管理、报备流程追踪
|
||||
3. **多通道编排**：配置主备通道，自动健康检查和故障切换
|
||||
4. **优先级队列**：至少三级优先级（紧急/普通/营销）
|
||||
5. **发送限流**：按调用方（模块）设置每小时/每日发送上限，防止异常刷量
|
||||
6. **号码黑名单**：支持用户退订（短信STOP指令处理），合规管理
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| -------------------- | --------------------------------------------------------------------------------------------- |
|
||||
| `sms_template` | id, code, name, content, variables(array), channel_template_ids(JSONB), status, registered_at |
|
||||
| `sms_send_record` | id, template_id, receiver, variables(JSONB), channel, priority, status, sent_at, fail_reason |
|
||||
| `sms_channel_config` | id, provider(aliyun/tencent), access_key, priority_level, is_active, health_status |
|
||||
| `sms_quota_config` | caller_module, hour_limit, day_limit, current_hour_count, current_day_count |
|
||||
| `sms_blacklist` | phone_no, reason, added_at, added_by |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | -------------------------------- | ------------------------ |
|
||||
| 短信服务商 | 阿里云SMS（主）+ 腾讯云SMS（备） | 短信发送通道 |
|
||||
| 消息队列 | RabbitMQ（多级优先级队列） | 异步发送、优先级管理 |
|
||||
| 缓存 | Redis | 限流计数器、号码频率控制 |
|
||||
| 监控 | Prometheus指标暴露 | 发送成功率、队列深度监控 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方（调用方） | 典型短信场景 |
|
||||
| ---------------- | ------------------------------- |
|
||||
| 健康管理（08） | 体征危急值告警 → 家属 |
|
||||
| 安全系统（09） | SOS/跌倒/走失 → 家属+紧急联系人 |
|
||||
| 长护险（18） | 服务完成确认 → 老人/监察员 |
|
||||
| 审批系统（04） | 补贴审核结果 → 申请人 |
|
||||
| 居家养老（10） | 服务预约确认 → 老人 |
|
||||
| 医养商城（19） | 订单发货/物流更新 → 消费者 |
|
||||
| 系统管理（05） | 账号注册/密码重置验证码 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ----------------- | -------------------------------------------------------- | --------------------------- |
|
||||
| 工信部模板审核 | 短信模板需报备审核，周期1-3天 | 提前规划模板，预留报备时间 |
|
||||
| 短信费用失控 | 告警类短信量大，费用可能超预期 | 限流配置 + 每日用量预警 |
|
||||
| 号码归属地屏蔽 | 某些运营商拦截短信 | 多通道备份 + 短信到达率监控 |
|
||||
| 边界：不含APP推送 | APP推送由各业务模块自行集成极光/腾讯推送，本系统仅做短信 | 明确能力范围 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1（基础设施，其他模块依赖）**
|
||||
|
||||
| 分期 | 内容 | 说明 |
|
||||
| ---------------- | ------------------------------------------- | ------------------------------- |
|
||||
| 第一期（P1同步） | 基础短信发送API + 验证码模板 + 阿里云单通道 | 所有P1模块的账号/通知依赖此能力 |
|
||||
| 第二期 | 模板管理界面 + 优先级队列 + 多通道切换 | — |
|
||||
| 第三期 | 用量统计報表 + 限流控制 + 黑名单管理 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
短信平台是全平台级基础设施，须在P1阶段早期完成基础能力建设，支撑其他模块的通知依赖。
|
||||
|
||||
mall 现有分散的短信代码可作为起点参考，但须重新设计为**独立微服务架构**，提供统一API入口，实现多通道管理、优先级调度和合规管控，避免27个模块各自维护短信代码的维护灾难。
|
||||
167
模块规划/14-智慧康养社区助餐可视化系统-模块规划.md
Normal file
167
模块规划/14-智慧康养社区助餐可视化系统-模块规划.md
Normal file
@@ -0,0 +1,167 @@
|
||||
# 智慧康养社区助餐可视化系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智慧康养社区助餐可视化系统是以**老年人助餐服务**为核心的 O2O（线上到线下）平台，涵盖老人在线/到店点餐、刷卡/人脸识别结算、配送上门和助餐站可视化大屏管理等功能。
|
||||
|
||||
本系统集商业价值（可快速产生可视化效果，用于招商展示）与民生价值（解决独居老人就餐难题）于一体，是平台早期可见成果最显著的模块之一。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 支持老人在线点餐（小程序）和到店自助点餐（人脸识别终端）
|
||||
2. 实现助餐费用管理（政府补贴 + 个人支付混合）
|
||||
3. 提供配送上门服务（对接骑手配送系统）
|
||||
4. 构建助餐站可视化大屏（当日就餐人数/菜品销量/补贴使用情况）
|
||||
5. 与政府监管系统对接，输出助餐运营数据
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 基本信息申请
|
||||
- 在线点餐
|
||||
- 到店自助点餐（人脸识别）
|
||||
- 配送上门
|
||||
- 助餐站管理系统
|
||||
- 可视化大屏
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **基本信息申请**：老人助餐资格申请（年龄/失能等级），平台审核后享受补贴
|
||||
- **在线点餐**：菜品浏览、加购、下单、补贴自动抵扣、支付剩余金额
|
||||
- **自助点餐**：到店自助点餐机器（iPad/触摸屏），人脸识别身份+自动出餐
|
||||
- **配送上门**：不方便外出的老人选择配送，骑手接单配送
|
||||
- **助餐站管理**：菜品管理（每日菜单）、厨师出餐管理、库存管理、补贴核销
|
||||
- **可视化大屏**：当日就餐实时统计、补贴消耗、配送追踪地图
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | -------------------------------------------- | --------------------------- |
|
||||
| 人脸识别点餐 | 老人到助餐站刷脸，自动识别身份+弹出菜单 | 人脸识别SDK + 自助终端 |
|
||||
| 补贴自动抵扣 | 下单时自动计算政府补贴额度，老人只付差价 | 补贴计算引擎 |
|
||||
| 骑手配送对接 | 配送上门订单对接骑手系统（类 mall 外卖配送） | 参考 mall 骑手模块 |
|
||||
| 可视化大屏 | 实时展示当日助餐站运营数据 | ECharts + WebSocket实时刷新 |
|
||||
| 每日菜单管理 | 助餐站每日上午更新菜品，老人11点前下单 | 定时任务 + 菜品状态 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：B（中契合）**
|
||||
|
||||
mall 的外卖/餐饮类订单机制与本系统相似度较高：
|
||||
|
||||
| 能力 | mall 现状 | 可复用程度 |
|
||||
| ------------------ | -------------------------- | -------------------------------------- |
|
||||
| 餐品目录管理 | 有商品CRUD，可视为菜品管理 | B - 直接参考，去除库存/物流复杂度 |
|
||||
| 在线下单支付 | 有完整下单链路 | B - 可直接参考，需加入补贴抵扣逻辑 |
|
||||
| 骑手配送 | 有骑手端+配送追踪 | **B - 配送上门可直接复用mall骑手模块** |
|
||||
| 商家管理（助餐站） | 有（类似外卖商家） | B - 可参考商家端改造为助餐站管理 |
|
||||
| 支付体系 | 微信/支付宝支付 | B - 可直接对接 |
|
||||
| **人脸识别点餐** | **无** | **须独立建设** |
|
||||
| **政府补贴结算** | **无** | **须独立建设** |
|
||||
| **可视化大屏** | **无** | **须独立建设** |
|
||||
| **助餐资格申请** | **无** | **须独立建设** |
|
||||
|
||||
**建设路径：mall + 独立微服务（以mall为基础，扩展医养特性）**
|
||||
|
||||
配送模块可直接复用 mall 骑手配送代码，在线点餐可参考 mall 下单流程；但补贴结算、人脸识别、可视化大屏需独立开发。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall + 独立微服务**
|
||||
|
||||
- 老人点餐端：uni-app（小程序），复用 mall 下单/支付组件
|
||||
- 助餐站管理端：uni-app 或 Vue3 Web（兼容平板收银台）
|
||||
- 骑手配送：**直接复用 mall 骑手模块**（仅需配置助餐专属配送逻辑）
|
||||
- 独立服务：补贴计算服务、人脸识别接入服务、可视化大屏服务
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **助餐资格审核**：老人申请助餐资格→机构审核→激活补贴账户
|
||||
2. **补贴计算与核销**：按老人等级和地区标准计算补贴金额，订单完成后核销
|
||||
3. **人脸识别点餐终端**：对接助餐站触摸屏/平板的人脸识别硬件
|
||||
4. **每日菜单管理**：重复性菜品录入简化（复制前日菜单/固定菜库）
|
||||
5. **可视化大屏**：ECharts实时刷新，数据精确到分钟级
|
||||
6. **营养建议**：根据老人健康档案（可选），在点餐时展示营养搭配建议
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `meal_station` | id, name, address, district_code, manager_id, status |
|
||||
| `meal_qualification` | elder_id, start_date, end_date, daily_subsidy, status |
|
||||
| `meal_menu` | id, station_id, date, dishes(JSONB), publish_at, order_deadline |
|
||||
| `meal_dish` | id, name, image, price, category, allergen_tags |
|
||||
| `meal_order` | id, elder_id, station_id, menu_date, order_type(delivery/dine-in/self-service), items(JSONB), total, subsidy_amount, self_pay, status |
|
||||
| `meal_delivery` | id, order_id, rider_id, pickup_at, delivered_at, address, status |
|
||||
| `meal_face_record` | id, elder_id, station_id, recognized_at, order_id |
|
||||
| `meal_subsidy_ledger` | id, elder_id, month, used_amount, balance, settled_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ------------------------------- | ---------------- |
|
||||
| 人脸识别 | 腾讯云人脸识别 / 海康威视人脸机 | 到店刷脸点餐 |
|
||||
| 可视化 | ECharts + WebSocket | 大屏实时数据展示 |
|
||||
| 骑手配送 | 复用mall骑手模块 | 配送上门 |
|
||||
| 支付 | 复用mall支付网关 | 自费部分收款 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ---------------- | ------------------------------ | --------------- |
|
||||
| mall骑手模块 | 配送上门订单推送给骑手 | 内部API（复用） |
|
||||
| mall支付 | 自费部分支付 | mall支付网关 |
|
||||
| 数据库系统（02） | 老人身份核验、档案关联 | 内部API |
|
||||
| 审批系统（04） | 助餐资格审核（如需政府审批） | 内部API |
|
||||
| 政府监管（01） | 助餐运营数据上报 | 内部API |
|
||||
| 长护险（18） | 部分助餐费用可能纳入长护险报销 | ⚠️ 待确认 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ---------------------- | -------------------------------------------- | ------------------------------------ |
|
||||
| 人脸识别硬件兼容 | 不同助餐站硬件品牌不统一 | 制定统一的人脸设备入网标准 |
|
||||
| 补贴结算合规 | 补贴核销需接受民政部门审计 | 完整留存核销记录，支持导出 |
|
||||
| 菜品食品安全 | 助餐属于食品服务，有卫生要求 | 系统记录供餐机构卫生证，定期提醒续期 |
|
||||
| 边界：不含厨房备餐管理 | 系统不管理厨房内部流程，仅管理菜品目录和订单 | 明确系统边界 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------------------ | ---------------------------- |
|
||||
| 第一期 | 在线点餐 + 到店核销（一卡通/扫码）+ 基础补贴抵扣 | mall支付、老人档案（02）就绪 |
|
||||
| 第二期 | 骑手配送上门 + 人脸识别终端 + 菜单管理 | mall骑手模块就绪 |
|
||||
| 第三期 | 可视化大屏 + 补贴核销报表 + 政府对接 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
社区助餐系统是平台最具展示价值的民生服务模块，mall 在在线订餐和骑手配送方面具有 B 级可复用能力，尤其是**骑手模块可直接复用**，显著节省开发成本。
|
||||
|
||||
建议以 mall 订单/配送能力为基础，独立开发助餐补贴结算、人脸识别点餐和可视化大屏三大核心扩展能力，**快速上线形成招商展示效果**，同时为后续政府补贴审计积累数据基础。
|
||||
161
模块规划/15-家庭床位及适老化改造系统-模块规划.md
Normal file
161
模块规划/15-家庭床位及适老化改造系统-模块规划.md
Normal file
@@ -0,0 +1,161 @@
|
||||
# 家庭床位及适老化改造系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
家庭床位及适老化改造系统是对接**政府补贴政策**的居家养老基础设施建设管理系统，覆盖家庭养老床位的申请审核、适老化改造项目管理、智能硬件设备安装与管理、上门服务管理以及完工后的监管与数据反馈全生命周期。
|
||||
|
||||
本系统是政府"家庭养老床位"补贴项目落地的数字化载体，兼具政策性（审批合规）和服务性（改造施工管理）特征。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现家庭床位申请→政府审核→签约的在线化流程
|
||||
2. 管理适老化改造项目（无障碍改造/辅具适配/智能设备安装）的施工进度
|
||||
3. 提供智能硬件设备的入户安装记录和运营状态管理
|
||||
4. 构建上门服务管理（改造施工人员的任务派发与执行记录）
|
||||
5. 支持改造完成后的监管验收和数据分析
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 家庭床位申请与签约
|
||||
- 适老化改造管理
|
||||
- 智能硬件设备管理
|
||||
- 上门服务管理
|
||||
- 监管与验收
|
||||
- 数据分析
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **申请与签约**：老人/家属提交申请（住房信息/失能等级）→政府审核→合同签约→补贴确认
|
||||
- **适老化改造**：改造项目清单（防滑扶手/坡道/加宽门框等）、预算核定、施工队派单
|
||||
- **硬件设备**：智能设备清单（呼叫器/摄像头/传感器）、安装记录、设备与老人档案绑定
|
||||
- **上门服务**：施工人员任务分配、进场打卡（GPS+照片）、阶段验收、完工交付
|
||||
- **监管验收**：政府/机构人员现场验收、照片留存、验收结论、补贴拨付触发
|
||||
- **数据分析**：改造户数、覆盖率、改造类型分布、设备使用率
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 技术要点 |
|
||||
| ------------ | -------------------------------------------------------- | --------------------------------- |
|
||||
| 改造项目清单 | 标准化改造项目目录，老人可选择，自动计算补贴金额 | 项目目录 + 补贴单价配置 |
|
||||
| 施工进度追踪 | 施工人员上传每阶段进度照片，管理员远程查看 | 移动端拍照 + OSS存储 + 进度状态机 |
|
||||
| 硬件设备绑定 | 设备SN码与老人档案绑定，安装完成后自动接入安全系统（09） | 设备注册API调用 |
|
||||
| 验收流程 | 竣工照片+验收人员签字→触发补贴核定指令 | 电子签名 + 工作流 |
|
||||
| 数据看板 | 改造进度、户数统计、资金使用率 | ECharts |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：C（低契合，部分结构可参考）**
|
||||
|
||||
mall 的服务型订单和上门服务概念与本系统有部分相似性：
|
||||
|
||||
| 能力 | mall 现状 | 可复用程度 |
|
||||
| -------------------------- | -------------------- | ---------------------------------- |
|
||||
| 服务订单状态机 | 有（居家服务参考） | C - 可参考状态流转设计 |
|
||||
| 上门服务人员（类骑手） | 骑手端GPS打卡+照片 | C - 可参考移动端设计，场景差异大 |
|
||||
| 审核流程 | 商家入驻审核（基础） | C - 参考意义有限，合同签约逻辑不同 |
|
||||
| **家庭床位申请（政策性）** | **无** | **须独立建设** |
|
||||
| **改造项目目录与补贴核算** | **无** | **须独立建设** |
|
||||
| **IoT设备入户安装** | **无** | **须独立建设** |
|
||||
| **政府验收与补贴拨付触发** | **无** | **须独立建设** |
|
||||
|
||||
**建设路径：mall + 独立微服务（以独立为主，参考 mall 服务订单设计模式）**
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall + 独立微服务（独立为主）**
|
||||
|
||||
- 老人/家属申请端：uni-app（小程序）
|
||||
- 施工人员端：uni-app（移动端）
|
||||
- 管理/验收端：Vue3 Web
|
||||
- 服务端：独立项目管理服务
|
||||
- 与安全系统（09）和IoT管理（16）通过API对接完成设备注册
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **家庭床位申请流程**：在线填写住房信息、上传证明材料、等待政府审核
|
||||
2. **标准改造项目目录**：国家/地方补贴支持的改造项目清单和补贴金额上限
|
||||
3. **施工人员任务派发**：按地区和技能分配施工任务，移动端接单
|
||||
4. **多阶段验收机制**：开工照片→中期照片→竣工照片→政府/机构验收
|
||||
5. **设备入户注册**：安装设备后自动注册到IoT平台，与老人档案绑定
|
||||
6. **补贴核算与拨付请求**：验收通过后自动生成补贴申请单，流转至审批系统（04）
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------------- | -------------------------------------------------------------------------------------------------- |
|
||||
| `home_bed_application` | id, elder_id, address, house_type, disability_grade, status, approved_at, contract_url |
|
||||
| `renovation_project` | id, application_id, items(JSONB), total_estimated_cost, subsidy_amount, start_date, end_date |
|
||||
| `renovation_item_catalog` | id, name, category, unit, max_subsidy_per_unit, description |
|
||||
| `renovation_execution` | id, project_id, worker_id, checkin_time, checkin_photo, phase, phase_photos(array), notes |
|
||||
| `renovation_acceptance` | id, project_id, acceptor_id, accept_type(gov/platform), accept_date, result, photos, signature_url |
|
||||
| `iot_device_install` | id, project_id, device_sn, device_type, elder_id, install_at, registered_to_iot_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ---------------------- | ------------------------ |
|
||||
| 文件存储 | 阿里云OSS | 施工照片存储 |
|
||||
| 电子签名 | Canvas签名 / 法大大 | 验收签字 |
|
||||
| 工作流 | 参考04号模块轻量工作流 | 申请→审核→签约→施工→验收 |
|
||||
| GIS | 高德地图 | 施工人员打卡定位 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ---------------- | ------------------------------------ | ------------- |
|
||||
| 审批系统（04） | 家庭床位申请政府审核、验收后补贴申请 | 内部工作流API |
|
||||
| 数据库系统（02） | 老人档案查询、失能等级核验 | 内部API |
|
||||
| IoT管理（16） | 安装设备注册到IoT平台 | 内部API |
|
||||
| 安全系统（09） | 安装设备后与老人绑定，启动监测 | 内部API |
|
||||
| 政府监管（01） | 改造覆盖率、验收完成率统计 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------ | ---------------------------------------------------------------- | ----------------------------------- |
|
||||
| 补贴政策地区差异 | 各地适老化改造补贴标准不同 | 改造项目目录和补贴金额可按地区配置 |
|
||||
| 施工质量纠纷 | 改造完工后老人不满意 | 完整照片留存 + 验收签字防止事后争议 |
|
||||
| 设备安装标准 | 不同品牌设备安装规范不同 | 建立设备安装规范文档 |
|
||||
| 边界：不含房屋结构性改造 | 只管理适老化改造（辅具/设备/无障碍），不涉及房屋产权和结构性施工 | 明确改造项目范围 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1（政策窗口期必须抓住）**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------------ | --------------------------------- |
|
||||
| 第一期 | 家庭床位申请 + 基本改造项目管理 + 施工执行 | 老人档案（02）就绪 |
|
||||
| 第二期 | 政府验收流程 + 补贴核算 + IoT设备注册 | 审批系统（04）、IoT管理（16）就绪 |
|
||||
| 第三期 | 数据分析 + 政府监管对接 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
家庭床位及适老化改造系统兼具政策性和服务性，mall 的服务订单框架对本系统有一定参考价值（C级），但改造项目管理、政府审批闭环、IoT设备入户注册等核心医养特性须独立建设。
|
||||
|
||||
**建议以独立系统建设为主**，在P1阶段优先完成申请→审核→施工→验收的核心流程，把握政府"家庭养老床位"建设补贴的政策窗口期。
|
||||
161
模块规划/16-智能物联网管理系统-模块规划.md
Normal file
161
模块规划/16-智能物联网管理系统-模块规划.md
Normal file
@@ -0,0 +1,161 @@
|
||||
# 智能物联网管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
智能物联网管理系统是整个智慧医养平台的 **IoT 设备基础设施管理层**，负责对全平台所有智能终端设备（智能呼叫终端、定位终端、健康监测设备、跌倒监测设备）进行统一注册、状态监控、数据接入、固件管理和告警处理。
|
||||
|
||||
本系统是底层技术中间件，不直接对终端用户提供功能界面，而是为安全系统（09）、健康管理（08）、家庭床位（15）等上层业务模块提供设备能力支撑。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 构建统一的 IoT 设备注册和台账管理体系，支持 4 类主要设备类型
|
||||
2. 实现设备状态实时监控（在线/离线/低电量/故障）
|
||||
3. 提供标准化的设备数据接入协议（MQTT/HTTP双模）
|
||||
4. 支持批量设备管理（固件远程升级、批量配置下发）
|
||||
5. 建立设备告警处理闭环（设备告警→业务系统→调度→处置）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 设备注册与台账
|
||||
- 设备状态监控
|
||||
- 数据接入层（MQTT/HTTP）
|
||||
- 设备分组管理
|
||||
- 固件管理
|
||||
- 告警管理
|
||||
- 数据API（供上层业务调用）
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **设备注册**：4类设备（呼叫终端/定位终端/健康监测/跌倒监测）注册、SN码绑定老人
|
||||
- **状态监控**：实时在线率、最近心跳时间、电量、信号强度、异常设备清单
|
||||
- **MQTT接入**：设备端MQTT连接、Topic规范（设备状态/数据上报/指令下发）
|
||||
- **设备分组**：按机构/区域/设备类型分组，支持批量操作
|
||||
- **固件管理**：新固件包上传、兼容性校验、批量或定向远程升级
|
||||
- **告警管理**：设备离线告警、低电量预警、故障上报、告警转业务系统
|
||||
- **数据API**：历史数据查询、实时状态查询、设备列表过滤
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 设备类型 | 主要功能 | 数据上报频率 | 告警触发条件 |
|
||||
| ------------ | --------------------- | -------------- | ------------------- |
|
||||
| 智能呼叫终端 | SOS按键、通话 | 心跳1次/5分钟 | SOS触发/离线>30分钟 |
|
||||
| 定位终端 | GPS/LBS定位、运动轨迹 | 定位1次/5分钟 | 离开围栏/低电<20% |
|
||||
| 健康监测 | 血压/心率/血氧 | 每次测量时 | 指标超阈值 |
|
||||
| 跌倒监测 | 三轴加速度实时采集 | 跌倒事件触发时 | 跌倒检测阳性 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 是电商平台，完全不具备 IoT 基础设施能力：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| -------------------------- | --------- | ---------- |
|
||||
| MQTT Broker（IoT消息接入） | 无 | 须独立建设 |
|
||||
| 设备注册与台账管理 | 无 | 须独立建设 |
|
||||
| 设备固件OTA升级 | 无 | 须独立建设 |
|
||||
| 时序数据存储与查询 | 无 | 须独立建设 |
|
||||
| 设备状态实时监控仪表盘 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备任何 IoT 设备通信能力，强行堆入会导致架构崩溃。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（IoT基础设施层）**
|
||||
|
||||
- MQTT Broker：EMQX（开源版或企业版）
|
||||
- 设备管理平台：后端 Go/Java + Vue3 Web管理端
|
||||
- 时序数据库：TimescaleDB（PostgreSQL扩展）
|
||||
- 规则引擎：EMQX Rule Engine 或 自研告警规则服务
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **MQTT Broker 部署与配置**：高可用EMQX集群，支持TLS双向认证
|
||||
2. **设备接入协议规范**：制定统一的MQTT Topic命名规范和数据格式（JSON Schema）
|
||||
3. **设备认证体系**：每个设备预烧入证书，防止伪设备接入
|
||||
4. **OTA固件升级**：分批次推送固件，支持升级失败自动回滚
|
||||
5. **告警路由规则**：按告警类型和严重级别路由到对应业务系统（MQ）
|
||||
6. **设备可视化地图**：GIS地图展示全部设备的地理分布和状态
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------- | ----------------------------------------------------------------------------------------------------------- |
|
||||
| `iot_device` | id, device_type, device_sn, manufacturer, model, elder_id, org_id, status, firmware_version, last_heartbeat |
|
||||
| `iot_device_cert` | device_id, cert_pem, private_key_hash, issued_at, expire_at |
|
||||
| `iot_telemetry` | device_id, metric_type, value, reported_at（时序表） |
|
||||
| `iot_alert` | id, device_id, alert_type, severity, payload(JSONB), received_at, routed_to, routed_at |
|
||||
| `iot_firmware` | id, version, device_type, file_url, release_notes, compatible_models(array) |
|
||||
| `iot_firmware_task` | id, firmware_id, target_device_ids(array), status, progress, started_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ----------- | ------------------ | ------------------------------- |
|
||||
| MQTT Broker | EMQX（开源/企业） | IoT设备消息接入，支持百万级连接 |
|
||||
| 时序数据库 | TimescaleDB | 设备上报的时序数据存储 |
|
||||
| 消息队列 | Kafka | 设备告警事件的高吞吐处理 |
|
||||
| GIS | 高德地图API | 设备分布地图 |
|
||||
| OTA | 自研 + OSS文件存储 | 固件文件存储与下发 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ------------------ | -------------------------- | ------------- |
|
||||
| 安全系统（09） | SOS/跌倒/定位数据输出 | Kafka消息消费 |
|
||||
| 健康管理（08） | 健康监测数据输出 | Kafka消息消费 |
|
||||
| 家庭床位（15） | 入户设备注册 | 内部注册API |
|
||||
| 政府监管（01） | 设备在线率统计 | 内部统计API |
|
||||
| 系统管理中心（05） | 设备接口型号注册（主数据） | 内部API |
|
||||
| 技术中台（27） | API网关和服务注册 | 内部基础设施 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------ | -------------------------------------------------- | ------------------------------------------ |
|
||||
| 设备兼容性 | 不同厂商设备通信协议不统一 | 建立设备入网认证标准，要求厂商适配统一协议 |
|
||||
| 高并发数据写入 | 大量设备同时上报数据时写入压力大 | 时序数据库 + 写入缓冲队列（Kafka） |
|
||||
| MQTT安全 | 设备证书管理不当可能导致非授权接入 | TLS双向认证 + 设备证书轮换策略 |
|
||||
| 边界：不含设备采购 | 本系统只负责软件接入管理，不负责设备硬件选型和采购 | 明确边界，由运营方制定设备白名单 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2（但需在P1阶段完成基础框架，支撑安全系统SOS功能）**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| -------- | ------------------------------------------------------ | ---------------- |
|
||||
| P1配合 | MQTT Broker部署 + SOS设备接入（支撑呼叫中心+安全系统） | 基础设施部署完成 |
|
||||
| P2第一期 | 设备注册台账 + 状态监控 + 告警路由 | — |
|
||||
| P2第二期 | OTA固件升级 + 设备地图 + 时序数据查询API | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
智能物联网管理系统是全平台 IoT 能力的基础设施层，mall 完全不具备此类能力，**必须独立建设**。
|
||||
|
||||
建议采用 EMQX 开源版本起步，视设备规模决定是否升级为企业版。MQTT Broker 的部署应在 P1 阶段与安全系统（09）同步完成，以支撑 SOS 紧急响应的核心安全功能。
|
||||
166
模块规划/17-医保DIP智能控费-模块规划.md
Normal file
166
模块规划/17-医保DIP智能控费-模块规划.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# 医保DIP智能控费 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
医保DIP智能控费系统是面向**医疗机构和医保管理人员**的医保费用智能管控平台，基于按病种分值付费（DIP）和疾病诊断相关组（DRG）规则，实现医保编码智能辅助、入院前费用预测、住院中实时控费预警和出院结算审核。
|
||||
|
||||
本系统属于**医疗信息化（HIS/医保）** 专业领域，是高度垂直的医保费用管理系统，与养老服务主业存在领域差异，但与养老机构（提供医疗服务的）的医保结算存在关联。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现医保智能编码辅助（ICD-10疾病编码、手术操作编码）
|
||||
2. 提供病例DRG/DIP分组自动判定，减少编码错误和拒付风险
|
||||
3. 构建住院费用实时监控，超出分值预警并给出控费建议
|
||||
4. 支持出院结算审核（自动校验编码与费用的匹配度）
|
||||
5. 提供医保费用分析报表（科室/病种/医生维度）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 医保智能编码
|
||||
- 医保智能审核
|
||||
- DRG/DIP智能管理
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **医保智能编码**：
|
||||
- 主诊断编码辅助（ICD-10，41个子功能）
|
||||
- 手术操作编码辅助
|
||||
- 编码知识库维护
|
||||
- 编码错误校验
|
||||
- **医保智能审核**（77个子功能）：
|
||||
- 入院指征审核
|
||||
- 用药合理性审核（超适应症/超量）
|
||||
- 耗材合规审核
|
||||
- 诊疗行为监控
|
||||
- **DRG/DIP智能管理**（77个子功能）：
|
||||
- 病例DRG自动分组
|
||||
- DIP分值计算
|
||||
- 分组异常预警
|
||||
- 费用超支预测与控制建议
|
||||
- 科室DIP点数分析
|
||||
- 医保基金使用率仪表盘
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 专业要求 |
|
||||
| -------------- | --------------------------------------------------- | --------------------------- |
|
||||
| ICD-10编码辅助 | 医生输入疾病名称→智能匹配ICD-10编码，提示高风险编码 | 国家医保局ICD-10规则库 |
|
||||
| DRG自动分组 | 根据主诊断+手术操作+并发症自动判定DRG分组 | 国家DRG分组规则（CHS-DRG） |
|
||||
| DIP分值计算 | 病种+均次费用→计算DIP分值，与医保支付额比对 | 各省DIP分值表（地区差异大） |
|
||||
| 费用实时监控 | 住院中实时预测最终费用是否超出DRG上限 | 费用预测模型 |
|
||||
| 审核规则库 | 内置超5000条医保合规规则（诊疗+用药+耗材） | 持续更新国家/地方医保政策 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 是通用电商平台，不具备任何医保相关能力：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ------------------ | --------- | ---------- |
|
||||
| ICD-10医疗编码体系 | 无 | 须独立建设 |
|
||||
| DRG/DIP分组算法 | 无 | 须独立建设 |
|
||||
| 医保合规规则引擎 | 无 | 须独立建设 |
|
||||
| HIS系统集成 | 无 | 须独立建设 |
|
||||
| 医保费用分析 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备医保编码/DRG分组等专业医疗信息化能力，强行堆入会导致数据合规失控。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（专项医疗信息化系统）**
|
||||
|
||||
- 系统性质：高度专业的医疗信息化系统，通常需要专业医疗IT厂商参与
|
||||
- 集成方式：可考虑采购成熟的DRG/DIP控费产品（如嘉和美康、海虹医保等），而非全自研
|
||||
- 与养老平台关系：通过API对接，养老机构的医疗服务数据输入本系统
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **ICD-10编码知识库**：国家医保局官方编码库（41880+编码条目）
|
||||
2. **DRG/DIP规则引擎**：全国版DRG规则 + 各省DIP分值表（⚠️ 地区差异大，需分省配置）
|
||||
3. **医保合规规则库**：5000+条诊疗/用药/耗材医保合规规则，持续更新
|
||||
4. **HIS数据集成接口**：从养老机构HIS系统获取就诊数据（HL7 FHIR标准）
|
||||
5. **费用预测模型**：基于历史数据训练的住院费用预测
|
||||
6. **实时预警推送**：费用超预警时推送给主治医生/财务
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------------ | --------------------------------------------------------------------------------------------- |
|
||||
| `icd10_code` | code, name, category, effective_date, is_medical_insurance_covered |
|
||||
| `drg_group_rule` | id, version, conditions(JSONB), drg_code, base_payment |
|
||||
| `dip_score_table` | province_code, disease_code, score, effective_year |
|
||||
| `admission_case` | id, patient_id, org_id, admit_date, discharge_date, main_diagnose_code, drg_group, total_cost |
|
||||
| `insurance_audit_record` | id, case_id, rule_id, hit_type, description, risk_level, suggested_action |
|
||||
| `cost_alert` | id, case_id, alert_type, threshold, actual_cost, predicted_cost, alerted_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | ---------------------------------- | -------------------------------- |
|
||||
| 医疗互操作 | HL7 FHIR R4协议 | 与HIS系统数据交换 |
|
||||
| 规则引擎 | Drools / 自研规则引擎 | 医保合规规则执行 |
|
||||
| NLP | 医疗NLP（自研或第三方） | 疾病名称→ICD-10编码智能匹配 |
|
||||
| 数据仓库 | ClickHouse | 医保费用分析报表（大数据量OLAP） |
|
||||
| 医保数据 | 各省医保局API（⚠️ 待确认接入条件） | 实时分值获取和结算 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 说明 |
|
||||
| ----------------- | ------------------------- | ------------------------------- |
|
||||
| 养老机构HIS系统 | 电子病历、医嘱、费用数据 | HL7 FHIR接口 |
|
||||
| 国家/省医保局系统 | DRG/DIP分值查询、结算提交 | ⚠️ 待确认各省接口规范和接入条件 |
|
||||
| 中心药房（21） | 药品费用数据 | 内部API |
|
||||
| 数据中台（26） | 医保费用数据汇入 | 内部数据管道 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------ | ---------------------------------------------------- | ---------------------------------- |
|
||||
| 各省DIP规则差异 | DIP分值表和规则每省不同，且每年更新 | 规则可配置，建立规则版本管理机制 |
|
||||
| 医保接口准入门槛 | 需经过医保局系统对接资质认证 | ⚠️ 提前了解各省医保局接入要求 |
|
||||
| 数据合规（病历数据） | 医疗数据属于最高级别隐私数据 | 等保三级、国密加密、数据不出境 |
|
||||
| 专业性门槛高 | DRG/DIP业务逻辑需要医保专业人员参与 | 建议与专业医保IT厂商合作，非全自研 |
|
||||
| 边界：不含医保结算资金流 | 本系统处理规则和预警，实际资金划拨由医保经办机构完成 | 输出结算建议，不直接操作资金 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------ | ----------------------------- |
|
||||
| 第一期 | 编码辅助 + 基础DRG分组 | HIS系统确认、医保接口条件确认 |
|
||||
| 第二期 | 实时费用监控 + 合规审核规则库 | — |
|
||||
| 第三期 | DIP智能控费 + 医保费用分析报表 | — |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
医保DIP智能控费是高度专业的医疗信息化系统，其ICD-10编码体系、DRG/DIP规则引擎、医保合规规则库等核心能力在 mall 中完全缺失，**必须作为独立系统建设**。
|
||||
|
||||
鉴于专业门槛高、规则更新频繁、各省差异显著，**强烈建议评估采购成熟的医保控费产品**（国内头部厂商）而非全自研，平台侧主要负责集成接口和数据展示，以降低研发风险和维护成本。
|
||||
168
模块规划/18-长护险与居家服务管理-模块规划.md
Normal file
168
模块规划/18-长护险与居家服务管理-模块规划.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# 长护险与居家服务管理 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
长护险与居家服务管理系统是对接**长期护理保险（长护险）政策**的服务履约与结算管理系统，覆盖长护险资格申请评估、服务计划制定与派单、上门服务执行（GPS签到+人脸/电子签名+照片留存）、服务记录审核、医保经办机构结算对账，以及可选的 AI 辅助服务规划。
|
||||
|
||||
本系统是平台与医保基金直接挂钩的高价值业务通道，服务质量直接影响医保结算资金回款。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现长护险参保资格核查与失能等级评估（对接07号评估系统）
|
||||
2. 构建符合医保合规要求的服务计划制定和派单体系
|
||||
3. 提供服务执行的三要素留证：GPS定位 + 人脸识别/电子签名 + 照片
|
||||
4. 实现服务完成后的结算清单生成与医保经办机构对账
|
||||
5. 支持 AI 辅助服务方案推荐（可选，基于老人评估数据）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 申请评估管理
|
||||
- 服务计划制定与派单
|
||||
- 服务执行监管
|
||||
- 结算对账
|
||||
- AI服务集成（可选）
|
||||
- 居家服务管理
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **申请评估**：参保资格核查、失能等级认定（来自07评估）、护理等级核定（轻/中/重）
|
||||
- **服务计划**：按护理等级配置服务项目（国家规定的长护险服务包）、月度小时数上限
|
||||
- **派单**：按服务计划派单给服务商/护理员，支持长期定期派单
|
||||
- **服务执行**：护理员上门 GPS 打卡→开始计时→人脸识别老人→执行服务→老人签字→照片→提交
|
||||
- **审核**：机构/医保经办审核服务记录（照片/签名/GPS轨迹）
|
||||
- **结算对账**：月度服务工时汇总、应付金额计算、医保经办机构结算清单生成、差异处理
|
||||
- **AI辅助**：基于评估数据智能推荐服务方案（⚠️ 待确认AI能力建设时间点）
|
||||
- **居家服务管理**：非长护险服务（自费/政府补贴）的同平台统一管理
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 合规要求 |
|
||||
| ------------ | ---------------------------------------------------- | ------------------------- |
|
||||
| GPS定位签到 | 护理员必须到达老人家200m范围内才可打卡开始 | 医保稽查要求 |
|
||||
| 人脸识别确认 | 服务完成后对老人进行人脸识别，确认本人在场 | 防止"挂空单" |
|
||||
| 电子签名 | 老人/家属在手机或PAD上手写签字确认服务完成 | 合规留证 |
|
||||
| 照片留存 | 每次服务至少拍3张照片（开始/过程/结束）附时间水印 | 医保稽查留证要求 |
|
||||
| 月度结算清单 | 每月月末生成服务工时汇总，对应护理费用，提交医保经办 | 长护险结算规范 |
|
||||
| 服务包配置 | 按各省长护险政策配置服务项目目录和每次时长标准 | ⚠️ 各省政策差异，需可配置 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：C（低契合，服务型订单框架可参考）**
|
||||
|
||||
mall 的服务型订单框架（预约→分配→执行→确认→结算）与本系统在整体流程上有一定相似性：
|
||||
|
||||
| 能力 | mall 现状 | 可复用程度 |
|
||||
| ------------------------ | ------------- | ---------------------------------------- |
|
||||
| 服务订单状态机 | 有（C级参考） | 可参考状态流转 |
|
||||
| 服务人员GPS打卡 | 骑手端有 | C - 可参考移动端交互框架 |
|
||||
| 支付结算 | 有（C/B级） | 长护险是医保结算非消费支付，逻辑完全不同 |
|
||||
| **长护险资格核查** | **无** | **须独立建设** |
|
||||
| **医保服务包配置** | **无** | **须独立建设** |
|
||||
| **人脸识别老人身份** | **无** | **须独立建设** |
|
||||
| **医保经办机构结算接口** | **无** | **须独立建设** |
|
||||
| **三要素留证体系** | **无** | **须独立建设** |
|
||||
|
||||
**建设路径：mall + 独立微服务（以独立为主，参考 mall 服务订单框架）**
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall + 独立微服务（以独立为主）**
|
||||
|
||||
- 护理员执行端：uni-app（GPS+人脸+签名+拍照，独立应用）
|
||||
- 老人/家属端：uni-app（查看服务记录、电子签名）
|
||||
- 机构管理端：Vue3 Web（派单+审核+对账）
|
||||
- 结算对接：⚠️ 需对接各省医保经办机构结算API，接口规范待确认
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **长护险参保资格核查**：接入医保系统查询老人参保状态（⚠️ 待确认接口）
|
||||
2. **服务包规则引擎**：按护理等级和省份配置服务项目、每次时长、月度上限
|
||||
3. **三要素留证引擎**：GPS + 人脸识别 + 签名三要素同时验证，缺一不可提交
|
||||
4. **服务记录防篡改**：留证数据加密存储（可选区块链存证）
|
||||
5. **月度批量结算**：按月汇总工时、生成符合各省医保规范的结算清单格式
|
||||
6. **结算差异处理**：医保核减后的差异原因分析、重审申请
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------------- | --------------------------------------------------------------------------------------------------------------- |
|
||||
| `ltc_insurance_eligibility` | elder_id, insured_no, nursing_grade, start_date, end_date, monthly_hours_limit |
|
||||
| `ltc_service_plan` | id, elder_id, nursing_grade, items(JSONB), monthly_hours, plan_period |
|
||||
| `ltc_service_order` | id, plan_id, elder_id, staff_id, scheduled_at, service_type, duration_min, status |
|
||||
| `ltc_execution_record` | id, order_id, checkin_gps, checkin_time, face_verify_result, photos(array), signature_url, checkout_time, notes |
|
||||
| `ltc_monthly_settlement` | id, org_id, period_month, total_orders, total_minutes, amount_claimed, amount_approved, status |
|
||||
| `ltc_settlement_item` | settlement_id, order_id, service_type, minutes, unit_price, claimed_amount, approved_amount, reject_reason |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------------- | ----------------------------------- | -------------------- |
|
||||
| 人脸识别 | 腾讯云人脸识别 / 百度人脸 | 服务完成老人身份确认 |
|
||||
| 定位 | 高德SDK + 地理围栏 | 护理员到场验证 |
|
||||
| 电子签名 | Canvas手写签名 | 老人确认签字 |
|
||||
| 区块链（可选） | 蚂蚁链/腾讯TBaaS | 服务记录存证防篡改 |
|
||||
| 医保对接 | 各省医保经办机构API（⚠️ 待确认SDK） | 结算清单提交 |
|
||||
| 加密存储 | 国密SM4 | 留证数据加密 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 说明 |
|
||||
| ------------------ | ------------------------------------------ | ----------------- |
|
||||
| 评估系统（07） | 失能等级→护理等级认定依据 | 内部API（只读） |
|
||||
| 医保系统 | 参保资格查询 + 月度结算清单提交 | ⚠️ 待确认各省接口 |
|
||||
| 服务商管理（11） | 护理员来源、技能资质 | 内部API |
|
||||
| 居家养老管理（10） | 服务订单共享（长护险派单在10的框架下执行） | 内部API |
|
||||
| 短信平台（13） | 服务确认短信（老人/家属） | 内部API调用 |
|
||||
| 数据中台（26） | 结算数据归集用于分析 | 内部数据管道 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| -------------------------- | ---------------------------------------- | -------------------------------------- |
|
||||
| 各省长护险规则差异 | 服务包项目、报销比例、每月上限均不同 | 服务包规则全部可配置化，不硬编码 |
|
||||
| 医保接口准入 | 需经医保局系统对接备案 | ⚠️ 提前规划准入申请 |
|
||||
| 稽查留证要求 | 医保稽查对留证格式有规范要求 | 严格按当地医保规范设计留证格式 |
|
||||
| 三要素误识别 | 人脸识别失败导致服务无法提交 | 保留手动上报备用通道（但需更严格审核） |
|
||||
| 边界：不含医保保险公司管理 | 本系统负责服务履约侧，不管理医保基金收付 | 清单提交后由医保经办机构处理 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1（高商业价值，政策驱动）**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ---------------------------------------------------- | ---------------------------- |
|
||||
| 第一期 | 服务计划派单 + 护理员执行（GPS+照片+签名）+ 月度汇总 | 评估（07）、服务商（11）就绪 |
|
||||
| 第二期 | 人脸识别留证 + 结算清单对接医保 | 人脸服务申请、医保接口确认 |
|
||||
| 第三期 | AI服务规划推荐 + 区块链存证 | AI能力就绪 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
长护险与居家服务管理是平台与医保基金直接挂钩的核心业务，三要素留证合规（GPS+人脸+签名）和医保结算接口是本系统成功的关键。
|
||||
|
||||
mall 的服务订单框架有一定参考价值（C级），但长护险合规留证、医保服务包规则引擎、医保经办结算对接等核心能力须独立建设。**建议在P1阶段优先完成**，把握长护险推进带来的政策业务机遇。
|
||||
185
模块规划/19-医养商城-模块规划.md
Normal file
185
模块规划/19-医养商城-模块规划.md
Normal file
@@ -0,0 +1,185 @@
|
||||
# 医养商城 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
医养商城是整个智慧医养平台中**与 mall 契合度最高（A级）的模块**，面向老人、家属及机构提供医疗养老相关商品和服务的 B2C/B2B 电商平台，涵盖商品销售（医疗器械/保健品/辅具/适老化用品）、服务类商品（上门护理/到家就诊）、IoT 设备租赁、直播带货等 420+ 功能细项。
|
||||
|
||||
mall 的核心电商能力（商品管理/订单/支付/物流/营销/商家入驻）可以直接在此场景复用，但需识别出"写在医养商城章节但本质属于其他系统（HIS/IoT/EMR）的功能"，这些功能须独立建设，不可堆入 mall。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 基于 mall 平台快速构建医养垂直电商能力，覆盖实物商品和服务商品
|
||||
2. 接入多品类服务商（医疗器械/保健品/适老化/康复辅具），实现多商家入驻
|
||||
3. 提供 IoT 设备租赁/分期购买能力（呼叫器/血压仪/防跌倒手环等）
|
||||
4. 落地直播带货能力（老人适用的直播形式）
|
||||
5. 实现私域流量体系（家庭群/社区群/老人圈互动转化）
|
||||
6. 打通与其他模块的数据（健康档案→智能推荐，服务评估→服务类商品推荐）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 商品管理
|
||||
- 用户交互
|
||||
- 订单管理
|
||||
- 物流配送
|
||||
- 数据分析
|
||||
- 营销推广
|
||||
- 客服售后
|
||||
- 商家入驻
|
||||
- 生态商家对接
|
||||
- 私域营销
|
||||
- 直播带货
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **商品管理**：商品CRUD、SPU/SKU、分类（医疗器械/保健品/适老化/康复辅具/服务类）、审核、下架、批量导入
|
||||
- **用户交互**：搜索/筛选/评价、老年友好界面（大字体/高对比色/语音搜索）
|
||||
- **订单管理**：下单/付款/发货/收货/退款/客服全链路，含服务类订单（预约制）
|
||||
- **IoT设备租赁**：设备租期管理、押金、到期续租、设备归还、维修工单
|
||||
- **物流配送**：接入快递（快递100聚合）+ mall骑手配送（本地即时配送）
|
||||
- **营销推广**：优惠券/满减/积分/会员/拼团/闪购/推荐奖励
|
||||
- **客服售后**：在线客服（IM）+ 工单 + 退款仲裁
|
||||
- **商家入驻**：资质审核（医疗器械经营许可）+ 商品审核 + 结算分账
|
||||
- **生态商家对接**：外部健康服务平台API接入（⚠️ 待确认合作商家）
|
||||
- **私域营销**：家庭群裂变、家属端分享给子女、社区话题种草
|
||||
- **直播带货**：商品链接挂载、直播间下单、直播数据分析
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
**区分关键：mall能力可复用 vs 须独立建设**
|
||||
|
||||
| 功能类型 | 功能 | 归属 | 建设方式 |
|
||||
| -------- | ---------------------------------- | ----------------------- | ------------------- |
|
||||
| 真正电商 | 商品管理/SKU/购物车/下单/支付/退款 | mall核心 | **直接复用/小改造** |
|
||||
| 真正电商 | 商家入驻/结算分账/物流 | mall能力 | **直接复用** |
|
||||
| 真正电商 | 优惠券/积分/会员/拼团 | mall营销 | **直接复用** |
|
||||
| 真正电商 | 在线客服/工单 | mall能力 | **直接复用** |
|
||||
| 垂直扩展 | 医疗器械分类/资质审核（经营许可） | 医养扩展 | mall基础+扩展字段 |
|
||||
| 垂直扩展 | 服务类商品（预约制订单） | 医养扩展 | mall订单+服务化改造 |
|
||||
| 垂直扩展 | 老年友好UI/语音搜索 | 前端改造 | uni-app改造 |
|
||||
| 须独立 | IoT设备租赁管理（租期/押金/归还） | IoT管理（16）+ 商城联动 | 独立租赁服务 |
|
||||
| 须独立 | 健康档案驱动的智能推荐 | AI服务（22）提供 | 独立AI推荐服务 |
|
||||
| 须独立 | 直播带货 | 22或独立直播服务 | 独立流媒体服务 |
|
||||
| 须独立 | 处方流转/药品销售（需资质） | 中心药房（21） | 独立药房系统 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：A（高契合，核心电商功能直接复用）**
|
||||
|
||||
mall 作为本模块的技术底座，可以直接提供以下能力：
|
||||
|
||||
| 能力域 | 可复用内容 | 复用程度 |
|
||||
| ---------- | -------------------------------- | ------------------------------------ |
|
||||
| 商品体系 | SPU/SKU/分类/属性/图片/价格/库存 | **A - 直接使用，扩展医养分类字段** |
|
||||
| 订单全链路 | 下单→支付→发货/预约→完成→退款 | **A - 实物商品直接用，服务类需适配** |
|
||||
| 支付体系 | 微信支付/支付宝/钱包/积分抵扣 | **A - 直接使用** |
|
||||
| 物流 | 快递聚合API + 骑手即时配送 | **A - 直接使用** |
|
||||
| 营销 | 优惠券/积分/活动/拼团/闪购 | **A - 直接使用** |
|
||||
| 商家入口 | 商家入驻审核/商品管理/账单 | **A - 扩展医疗器械资质字段** |
|
||||
| 客服 | IM客服/工单/退款 | **A - 直接使用** |
|
||||
| 推荐 | 基础推荐算法 | B - 需扩展健康数据维度 |
|
||||
|
||||
**补充说明**：mall 中已有直播带货的代码框架，但根据需求文档描述该功能尚未完善，需进一步开发完善。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**mall 内扩展（A级，优先P0推进）**
|
||||
|
||||
- 在 mall 现有代码基础上扩展医养商城
|
||||
- 新增：医养商品分类体系、医疗器械资质字段、服务类订单适配、老年友好UI
|
||||
- 独立建设：IoT设备租赁服务（对接16号模块）、直播带货服务、AI推荐服务
|
||||
- **WARNING**：不要将 HIS/EMR/IoT 功能硬塞进 mall 代码，这些在需求文档中写在"医养商城"章节内，但本质上是独立系统
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **医养商品分类体系**：医疗器械（一/二/三类）/保健品/适老化用品/康复辅具/服务的分类体系
|
||||
2. **商家资质扩展**：医疗器械经营许可证号、药品经营许可证（与中心药房21联动）
|
||||
3. **服务类订单适配**：无库存的预约制服务（上门护理/到家就诊），时间段选择
|
||||
4. **老年友好UI**：大字体模式、简化导航、语音搜索（无障碍设计）
|
||||
5. **IoT设备租赁**：租期（月/季/年）、押金管理、到期提醒、归还处理
|
||||
6. **完善直播带货**：商品链接挂载、实时弹幕购物车、回放
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型（在 mall 基础上扩展）
|
||||
|
||||
| 模型/字段扩展 | 说明 |
|
||||
| ---------------------------- | -------------------------------------- |
|
||||
| `product.medical_license_no` | 医疗器械注册证号 |
|
||||
| `merchant.device_license_no` | 医疗器械经营许可证 |
|
||||
| `product_category`（扩展） | 新增医养分类树（医疗器械/辅具/服务等） |
|
||||
| `service_product_schedule` | 服务类商品的可预约时间段配置 |
|
||||
| `iot_rental_order` | 租赁订单：设备ID/租期/押金/状态 |
|
||||
| `live_stream_room` | 直播间配置、关联商品、观看数、下单数 |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| -------- | ---------------------------- | ---------------- |
|
||||
| 直播 | 腾讯云直播（CSS）+ 播放器SDK | 商品直播带货 |
|
||||
| 语音搜索 | 科大讯飞语音识别 | 老年用户语音输入 |
|
||||
| 无障碍 | uni-app无障碍API | 老年友好UI |
|
||||
| 推荐引擎 | 依托22号AI服务模块 | 健康档案驱动推荐 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 方式 |
|
||||
| ---------------- | ------------------------------ | ------------- |
|
||||
| IoT管理（16） | 设备租赁关联设备台账 | 内部API |
|
||||
| 居家养老（10） | 服务类商品预约对接居家服务订单 | 内部API |
|
||||
| 运营管理（24） | 商城运营数据汇聚 | 内部数据API |
|
||||
| AI服务（22） | 健康档案驱动个性化推荐 | 内部AI推荐API |
|
||||
| 中心药房（21） | 处方药品销售（处方流转） | 内部API |
|
||||
| 数据库系统（02） | 老人身份验证、健康档案关联 | 内部API |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ----------------- | ------------------------------------------------- | ---------------------------------------------- |
|
||||
| 医疗器械经营合规 | 销售二/三类医疗器械需特定资质 | 平台需获取医疗器械经营许可，或仅作信息撮合平台 |
|
||||
| 处方药销售合规 | 处方药需处方流转合规 | 对接中心药房（21）的处方流转系统 |
|
||||
| IoT租赁设备归还 | 设备归还、押金退还、设备检验复杂 | 建立标准化退租流程，与IoT管理联动 |
|
||||
| 直播内容合规 | 医疗器械直播有严格广告法约束 | 建立商品直播审核机制 |
|
||||
| 边界：不含HIS系统 | 商城中的诊疗建议/健康评估功能须对接独立的专业系统 | 严格区分电商功能与医疗功能 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P0（最优先推进，mall核心能力直接可用）**
|
||||
|
||||
| 分期 | 内容 | 说明 |
|
||||
| -------- | ----------------------------------------------------- | ----------------------------- |
|
||||
| P0第一期 | 医养商品分类 + 商家入驻（医疗器械资质）+ 实物商品销售 | 基于mall直接扩展，2-4周可上线 |
|
||||
| P0第二期 | 服务类商品预约 + 营销工具 + 客服 | — |
|
||||
| P1配合 | IoT设备租赁 + 老年友好UI | IoT管理（16）就绪 |
|
||||
| P1-P2 | 直播带货 + AI推荐 + 私域营销 | 直播技术验证后 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
医养商城是全平台中与 mall **契合度最高的模块（A级）**，mall 的商品管理、订单全链路、支付、物流、营销、商家入驻等核心能力可直接复用，**预计在 mall 基础上2-4周内可完成医养商城MVP版本上线**。
|
||||
|
||||
关键注意事项：需求文档中"医养商城"章节内包含的部分功能（IoT设备租赁管理、健康档案驱动推荐、直播带货、处方流转）本质上属于其他独立系统，**不应堆入 mall 代码**，而应通过 API 对接方式实现协作。
|
||||
|
||||
建议立即将医养商城列为P0优先启动项目，以此验证 mall 平台的医养化改造路径，为后续模块建设积累经验。
|
||||
161
模块规划/20-慢性病管理-模块规划.md
Normal file
161
模块规划/20-慢性病管理-模块规划.md
Normal file
@@ -0,0 +1,161 @@
|
||||
# 慢性病管理 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
慢性病管理系统是面向**老年慢性病患者（高血压/糖尿病/冠心病等）全病程管理**的专业医疗信息化系统，覆盖患者服务端、移动医生端、医生工作站（嵌入HIS）和医院管理端四个角色视图，实现慢性病的早期筛查、连续监测、规范治疗、用药提醒和复诊管理。
|
||||
|
||||
本系统是连接"居家健康监测"（健康管理08）与"专业医疗诊疗"之间的慢病管理中间层，也是医养结合战略的核心医疗侧体现。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 为慢性病患者（老人）提供自我健康管理工具（用药提醒/血压血糖记录/随访提醒）
|
||||
2. 支持移动医生端随时查看患者健康数据、开具随访计划
|
||||
3. 嵌入HIS的医生工作站，实现慢病管理与日常诊疗一体化
|
||||
4. 提供医院管理端的慢病患者群组分析和质量控制
|
||||
5. 打通健康管理（08）的体征数据，实现慢病异常早预警
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 患者服务端
|
||||
- 移动医生端
|
||||
- 医生工作站（嵌入HIS）
|
||||
- 医院管理端
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **患者服务端**：慢病档案、用药清单与提醒、血压/血糖自测记录、随访提醒、复诊预约、健康教育（文章/视频）
|
||||
- **移动医生端**：我的患者列表、患者健康趋势、随访记录、在线问诊、处方开具（⚠️ 需互联网医院资质）
|
||||
- **医生工作站（HIS嵌入）**：慢病患者库、慢病路径管理、历史随访记录、与HIS医嘱联动
|
||||
- **医院管理端**：科室慢病患者统计、达标率分析、医生绩效（随访完成率）、质量控制报表
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 前提条件 |
|
||||
| ---------- | ---------------------------------------------- | ----------------------------- |
|
||||
| 慢病档案 | 基于老人档案（02）扩展，增加主诊断/用药/手术史 | 老人档案（02）就绪 |
|
||||
| 用药提醒 | 按处方设置每日多次用药提醒，支持家属勾选确认 | 处方数据来源（HIS或手动录入） |
|
||||
| 随访计划 | 医生设置随访时间表，系统提醒患者和医生双方 | 医生工作站在HIS中就绪 |
|
||||
| 在线问诊 | 图文/视频问诊（需互联网医院牌照） | ⚠️ 需互联网医院资质 |
|
||||
| 处方开具 | 电子处方（需与医保处方流转系统对接） | ⚠️ 需互联网处方资质 |
|
||||
| 达标率分析 | 基于血压/血糖控制目标的患者达标率统计 | 患者体征数据积累足够 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 是通用电商平台，不具备任何慢性病管理能力：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ---------------------------- | --------- | ------------------- |
|
||||
| 慢病档案（诊断/用药/手术史） | 无 | 须独立建设 |
|
||||
| 随访计划管理 | 无 | 须独立建设 |
|
||||
| 医生工作站（HIS集成） | 无 | 须独立建设 |
|
||||
| 互联网问诊/处方 | 无 | 须独立建设（+资质） |
|
||||
| 达标率统计分析 | 无 | 须独立建设 |
|
||||
| 医学体征趋势分析 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备慢性病管理和医疗诊疗专业能力，强行堆入会导致数据合规失控和医疗责任风险。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（专业医疗信息化系统）**
|
||||
|
||||
- 患者端：uni-app（小程序+H5）
|
||||
- 医生端：uni-app（移动端）+ Vue3 Web（工作站）
|
||||
- 管理端：Vue3 Web
|
||||
- HIS集成：通过HL7/FHIR接口与现有HIS系统对接
|
||||
- **互联网医院牌照**：在线问诊和处方需要机构具备互联网医院资质（⚠️ 非技术问题，需提前规划）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **慢病路径管理**：标准化慢病管理路径（高血压/糖尿病/冠心病等），按路径执行随访
|
||||
2. **体征数据整合**：整合健康管理（08）的IoT体征数据，提供医生视角的患者健康时间轴
|
||||
3. **随访计划执行**：自动生成随访任务提醒，记录随访完成情况
|
||||
4. **处方流转**：电子处方→药房取药/配送（联动中心药房21和医养商城19）
|
||||
5. **患者教育内容**：慢病自我管理科普内容（文章/视频/问卷）
|
||||
6. **质量控制**：科室或机构维度的慢病管理质量报表
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------------- | --------------------------------------------------------------------------------------- |
|
||||
| `chronic_disease_profile` | elder_id, disease_code(ICD-10), diagnosis_date, severity, medications(JSONB), doctor_id |
|
||||
| `medication_reminder` | id, profile_id, drug_name, dosage, frequency, reminder_times(array), is_active |
|
||||
| `followup_plan` | id, profile_id, doctor_id, cycle(月/季), next_date, items(JSONB) |
|
||||
| `followup_record` | id, plan_id, actual_date, method, vitals(JSONB), notes, doctor_id |
|
||||
| `online_consultation` | id, patient_id, doctor_id, consult_type, status, prescription_id, started_at |
|
||||
| `e_prescription` | id, consultation_id, drug_list(JSONB), dispensed_at, pharmacy_id |
|
||||
| `disease_control_target` | disease_code, metric_type, target_min, target_max, unit |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | --------------------------------- | ----------------- |
|
||||
| 医疗互操作 | HL7 FHIR R4 | 与HIS系统数据交换 |
|
||||
| 视频问诊 | 腾讯云TRTC / 声网 | 在线视频问诊 |
|
||||
| 处方流转 | 各省处方流转平台接口（⚠️ 待确认） | 电子处方外配 |
|
||||
| 电子病历 | 符合电子病历规范（卫生部标准） | 随访记录规范存储 |
|
||||
| 推送 | 微信模板消息 | 用药/随访提醒 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 说明 |
|
||||
| ---------------- | ----------------------------- | ------------- |
|
||||
| 健康管理（08） | 患者体征数据（血压/血糖时序） | 内部API |
|
||||
| 中心药房（21） | 电子处方流转取药 | 内部API |
|
||||
| 医养商城（19） | 处方药品配送 | 内部API |
|
||||
| 数据库系统（02） | 老人档案基础数据 | 内部API |
|
||||
| 机构HIS系统 | 医嘱、诊断记录共享 | HL7 FHIR |
|
||||
| 处方流转平台 | 电子处方外配（各省平台不同） | ⚠️ 待确认接口 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ----------------------- | ---------------------------------------------------- | -------------------------------------------------- |
|
||||
| 互联网医院资质 | 在线问诊/处方需机构具备互联网医院牌照 | ⚠️ 需提前规划资质申请，技术可先建设 |
|
||||
| 电子处方合规 | 处方须医生电子签名，且不得泄露 | CA电子签名（国密）+ 加密存储 |
|
||||
| 医疗责任风险 | 平台提供建议而非诊断，界限须清晰 | 系统界面明确"本系统提供慢病辅助管理，不能替代问诊" |
|
||||
| 数据合规 | 病历属于最高级别个人敏感数据 | 等保三级 + 国密 + 数据不出境 |
|
||||
| 边界：不含急诊/住院管理 | 本系统管理慢性病，急性期就诊须到医院，不在系统范围内 | 明确功能边界 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ---------------------------------------------- | ---------------------------------- |
|
||||
| 第一期 | 慢病档案 + 用药提醒 + 随访计划（无需医院资质） | 老人档案（02）、健康数据（08）就绪 |
|
||||
| 第二期 | 医生工作站 + HIS集成 + 随访记录 | HIS系统确认、接口规范 |
|
||||
| 第三期 | 在线问诊 + 电子处方 + 处方外配 | 互联网医院资质获取 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
慢性病管理系统是医养结合战略的医疗侧核心，其慢病路径、HIS集成、互联网问诊等能力在 mall 中完全缺失，**必须独立建设**。
|
||||
|
||||
建议第一期先建设不依赖医院资质的功能（慢病档案/用药提醒/随访提醒），快速给老人提供价值；互联网问诊和电子处方依赖资质准备，作为后续阶段叠加。
|
||||
173
模块规划/21-中心药房-模块规划.md
Normal file
173
模块规划/21-中心药房-模块规划.md
Normal file
@@ -0,0 +1,173 @@
|
||||
# 中心药房 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
中心药房系统是面向**养老机构/医疗机构**的专业药事管理系统，覆盖药库（仓储）管理、门诊药房、住院药房、医养商城药房（线上配送）和共享中心药房（省阳采平台对接），实现药品的全生命周期管理（采购→入库→发药→追溯）。
|
||||
|
||||
本系统是典型的医疗信息化专业系统，需满足《药品管理法》《医院信息系统基本功能规范》等法规要求，并对接国家药品追溯系统和省级阳光采购平台。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现药库（院内药房仓储）的精细化管理（批次/效期/库存预警）
|
||||
2. 落地门诊药房配药发药流程（医嘱核对→调配→发药→签收）
|
||||
3. 管理住院药房的口服/静脉用药（摆药→送药→核对）
|
||||
4. 对接医养商城，实现处方药线上购买与配送（⚠️ 需处方流转资质）
|
||||
5. 接入共享中心药房模式（省阳光采购平台对接）
|
||||
6. 实现药品全程追溯码管理
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 药库管理
|
||||
- 门诊药房
|
||||
- 住院药房
|
||||
- 医养商城药房（处方流转）
|
||||
- 药品预警管理
|
||||
- 耗材管理
|
||||
- 设备管理（药房设备）
|
||||
- 共享中心药房（省阳采）
|
||||
- 药品追溯码管理
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
- **药库管理**：药品采购入库、供应商管理、批次/效期管理、库存盘点、库存调拨
|
||||
- **门诊药房**：处方审核（药师审核）、调配出药、发药记录、用药指导
|
||||
- **住院药房**：摆药单生成、口服药摆药、静脉配药（PIVAS）、送药核对
|
||||
- **商城药房**：处方上传审核、线上付款、配送或自取、处方单存档
|
||||
- **药品预警**：近效期预警（3/6/12个月）、低库存预警、过期药品管理
|
||||
- **耗材管理**：医用耗材入库/发放/盘点
|
||||
- **设备管理**：药房设备台账（发药机/冰箱/保险柜）维护记录
|
||||
- **省阳采对接**：目录对接、在线采购、回款管理
|
||||
- **药品追溯**：条码扫描入库、发药扫码、药监局追溯系统上报
|
||||
|
||||
### 3.3 核心功能说明
|
||||
|
||||
| 功能 | 描述 | 合规要点 |
|
||||
| -------------------- | ---------------------------------------------- | -------------------------------- |
|
||||
| 处方审核（四查十对） | 药师审核处方（查处方/查药品/查配伍/查用法） | 《处方管理办法》要求 |
|
||||
| 处方流转 | 电子处方→线上购药→外配药房发药 | 需互联网医院+处方流转资质 |
|
||||
| 药品追溯码 | 每个药品包装扫码入库，发药时再次扫码，上报药监 | 《药品追溯条例》要求 |
|
||||
| 近效期预警 | 批次效期提前预警，触发优先发药或退货 | GMP/GSP规范 |
|
||||
| 省阳采对接 | 按省级阳光采购平台目录采购、回款 | 各省采购平台接口（⚠️ 差异大） |
|
||||
| 高警讯药品管理 | 高危药品的特殊存储和发药记录 | 国家卫健委《高警讯药品管理规范》 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 有商品管理和库存体系，表面上与药库管理有相似性，但存在根本质的差异：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| -------------------- | -------------- | ----------------- |
|
||||
| 药品批次/效期管理 | 商品无批次概念 | 须独立建设 |
|
||||
| 处方审核（四查十对） | 无 | 须独立建设 |
|
||||
| 药品追溯码系统 | 无 | 须独立建设 |
|
||||
| 医嘱-处方联动 | 无 | 须独立（依赖HIS） |
|
||||
| 省阳采平台对接 | 无 | 须独立建设 |
|
||||
| 药监局接口上报 | 无 | 须独立建设 |
|
||||
| 高警讯药品管理 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备药事管理专业能力，强行堆入会导致数据合规失控和药品安全风险。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（专业药事管理系统）**
|
||||
|
||||
- 药师/仓库端：Vue3 PC Web（主要使用场景为院内PC）
|
||||
- 移动辅助端：uni-app（送药/盘点扫码）
|
||||
- 与慢性病管理（20）和HIS系统通过HL7接口对接处方数据
|
||||
- **建议评估采购成熟的HIS药房模块**，而非全自研
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **药品主数据库**：国家药品编码（YPH）、通用名/商品名、剂型、规格、价格
|
||||
2. **批次管理**：每个批次独立追踪（批号/生产日期/效期/供应商/入库单号）
|
||||
3. **处方审核引擎**：内置配伍禁忌数据库、用药剂量校验
|
||||
4. **药品追溯码接入**：国家药品监管局追溯系统API（各省接口统一程度待确认）
|
||||
5. **省阳采对接**：采购申请→省平台下单→入库核对→回款管理
|
||||
6. **共享药房能力**：多机构共享一个中心药房，按机构分账
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | --------------------------------------------------------------------------------------------------------- |
|
||||
| `drug_master` | id, national_code(YPH), generic_name, brand_name, dosage_form, specification, unit, category |
|
||||
| `drug_batch` | id, drug_id, batch_no, manufacturer, produce_date, expire_date, purchase_price, quantity_in, quantity_out |
|
||||
| `drug_stock` | drug_id, location_id, available_qty, locked_qty, last_updated |
|
||||
| `prescription_review` | id, prescription_id, pharmacist_id, review_result, issues(JSONB), reviewed_at |
|
||||
| `drug_dispensing` | id, prescription_id, batch_id, qty, dispensed_by, dispensed_at, patient_id |
|
||||
| `drug_trace_record` | id, drug_id, trace_code, event_type(in/out/dispose), reported_at, report_status |
|
||||
| `low_stock_alert` | drug_id, current_qty, min_qty, alert_at, handled |
|
||||
| `near_expire_alert` | batch_id, expire_date, alert_days_before, alert_at, action_taken |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ----------- | ------------------------------------------ | --------------------- |
|
||||
| 药品数据库 | 国家标准数据库（CFDA数据）或商业药品知识库 | 药品主数据 + 配伍禁忌 |
|
||||
| 二维码/条码 | ZXing / 硬件扫码枪 | 药品追溯码扫描 |
|
||||
| 医疗互操作 | HL7 FHIR | 与HIS/处方系统交换 |
|
||||
| 省阳采平台 | 各省采购平台API（⚠️ 差异大） | 阳光采购对接 |
|
||||
| 药监追溯 | 国家药品追溯系统API | 药品追溯码上报 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方 | 内容 | 说明 |
|
||||
| ------------------ | ------------------------------ | --------------------- |
|
||||
| 慢性病管理（20） | 电子处方流转到中心药房 | 内部API（HL7 FHIR） |
|
||||
| 医养商城（19） | 处方药线上购买，从药房出库配送 | 内部API |
|
||||
| 医保DIP（17） | 药品费用数据提供给医保审核 | 内部API |
|
||||
| 机构HIS系统 | 医嘱→处方→发药 | HL7 FHIR |
|
||||
| 国家药监局追溯系统 | 药品码上报 | 官方API |
|
||||
| 省阳光采购平台 | 采购目录对接 | ⚠️ 各省接口规范待确认 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| -------------------- | ------------------------------------------------ | ---------------------------------------- |
|
||||
| 药品追溯接口 | 各省药监局追溯接口进度不一 | 优先实现自建追溯记录，国家接口就绪后对接 |
|
||||
| 省阳采差异 | 各省阳光采购平台接口规格不同 | 设计可配置的采购平台适配层 |
|
||||
| 处方流转资质 | 需互联网处方流转资质 | ⚠️ 提前规划资质 |
|
||||
| 效期管理复杂度 | 临期药品FIFO（先进先出）需严格执行 | 系统强制FIFO发药策略 |
|
||||
| 边界：不含诊断和开方 | 本系统只管理处方后的药事流程，开方在HIS/慢病系统 | 明确与开方系统的接口边界 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------ | ---------------------------------- |
|
||||
| 第一期 | 药库管理 + 门诊药房（院内流程） | HIS系统确认 |
|
||||
| 第二期 | 处方流转线上化 + 商城药房 | 处方流转资质、慢性病管理（20）就绪 |
|
||||
| 第三期 | 省阳采对接 + 药品追溯 + 共享中心药房 | 各省接口确认 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
中心药房系统是高度专业的药事管理系统，其批次/效期管理、处方审核、药品追溯等核心能力与 mall 的商品管理存在根本性差异，**必须独立建设**。
|
||||
|
||||
**强烈建议评估采购成熟的HIS药房模块**（如东软医疗、金仕达、卫宁健康等），大幅降低研发风险。处方流转与省阳采对接需提前开展资质申请和接口调研。
|
||||
193
模块规划/22-人工智能服务-模块规划.md
Normal file
193
模块规划/22-人工智能服务-模块规划.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# 人工智能服务 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
人工智能服务平台是以**国产大模型（DeepSeek等）为基础**的医养专项AI能力集群，通过对医疗多模态数据的预训练和垂直微调，为医养平台各业务系统提供智能推荐、医疗审核辅助、知识检索、辅诊统计分析等标准化AI能力。
|
||||
|
||||
本系统不面向终端用户，而是作为**AI能力中间层**，通过API向其他业务模块（居家养老、医养商城、慢性病管理、全生命周期监测等）提供AI服务支撑。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 构建基于大模型的临床决策辅助系统（智能推荐+辅诊+医疗审核）
|
||||
2. 构建医养知识检索系统（疾病/药物/诊疗方案多维度知识库）
|
||||
3. 构建区域辅诊监测分析系统（机构级/区域级辅诊效果评估）
|
||||
4. 提供大模型能力的安全、标准化API输出
|
||||
5. 建立AI模型的全生命周期管理（训练→测试→部署→监控→迭代）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
- 智能推荐
|
||||
- 医疗审核
|
||||
- 知识检索
|
||||
- 区域辅诊监测分析
|
||||
- 大模型管理平台
|
||||
|
||||
### 3.2 二级功能清单
|
||||
|
||||
**智能推荐（11项）**：
|
||||
|
||||
- 关联症状问诊推荐
|
||||
- 进一步问诊推荐
|
||||
- 疑似诊断推荐
|
||||
- 特殊疾病处置建议
|
||||
- 误诊提醒
|
||||
- 漏诊提醒
|
||||
- 危急重症提醒
|
||||
- 检查检验推荐
|
||||
- 用药推荐
|
||||
- 操作治疗推荐
|
||||
- 手术推荐
|
||||
|
||||
**医疗审核（4项）**：
|
||||
|
||||
- 检查合理性审核
|
||||
- 检验合理性审核
|
||||
- 操作治疗合理性审核
|
||||
- 手术合理性审核
|
||||
|
||||
**知识检索（17项）**：
|
||||
|
||||
- 关键字/疾病/药物/临床路径/指南/病历/检验/检查/症状/手术/操作治疗/量表/健教知识/文献/法律法规目录检索
|
||||
- 知识收藏
|
||||
- 知识库维护
|
||||
|
||||
**区域辅诊监测（7项）**：
|
||||
|
||||
- 辅诊查询（机构/区域）
|
||||
- 审核查询
|
||||
- 风险查询
|
||||
- 辅诊统计
|
||||
- 审核总体统计
|
||||
- 检查检验审核统计
|
||||
- 手术操作审核统计
|
||||
- 诊断质控统计
|
||||
|
||||
### 3.3 核心架构说明
|
||||
|
||||
| 层次 | 内容 |
|
||||
| --------------- | ----------------------------------------- |
|
||||
| 大模型基座 | DeepSeek等国产大模型，通用理解和生成能力 |
|
||||
| 垂直预训练 | 医疗文献、临床指南、中医古籍、药品说明书 |
|
||||
| 场景微调（SFT） | 辅诊任务、用药推荐、护理方案等场景数据 |
|
||||
| AI应用层 | 各业务场景调用的标准化API接口 |
|
||||
| 监控运维层 | 模型性能监控、Hallucination检测、版本管理 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
mall 是通用电商平台，不具备任何医疗AI能力：
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| -------------------- | --------- | ----------------------- |
|
||||
| 大模型部署与微调 | 无 | 须独立建设（需GPU算力） |
|
||||
| 医疗知识库与向量检索 | 无 | 须独立建设 |
|
||||
| 辅诊推荐算法 | 无 | 须独立建设 |
|
||||
| 医疗合规审核规则 | 无 | 须独立建设 |
|
||||
| 区域AI监测分析 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备任何AI训练和推理能力，强行堆入会导致架构崩溃（GPU算力需求与电商系统运行需求完全不同）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（AI平台，高专业性）**
|
||||
|
||||
- AI推理服务：Python FastAPI（GPU服务器部署）
|
||||
- 知识库检索：Elasticsearch + 向量数据库（Milvus/Qdrant）
|
||||
- 管理界面：Vue3 Web（模型管理、知识库维护）
|
||||
- 算力：GPU服务器（推荐A100/H100）或云GPU（阿里云/腾讯云GPU实例）
|
||||
- 大模型：DeepSeek-R1 或 DeepSeek-V3（中文医疗能力强的国产模型）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **医疗知识图谱构建**：疾病-症状-药物-检查-治疗方案关联关系网络
|
||||
2. **向量化医学文档库**：临床指南/诊疗规范文档向量化存储，支持语义检索
|
||||
3. **大模型微调管道**：LoRA/QLoRA微调流程，支持定期增量训练
|
||||
4. **推理API服务**：各AI能力（辅诊/推荐/检索）的标准化REST API
|
||||
5. **Hallucination防护**：医疗AI回答的置信度评分和人工审核机制
|
||||
6. **模型版本管理**：多版本模型对比测试，灰度发布
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型（AI平台侧）
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------- | ---------------------------------------------------------------------------------------------- |
|
||||
| `ai_model_registry` | id, name, version, base_model, fine_tune_type, deploy_status, accuracy_metrics(JSONB) |
|
||||
| `knowledge_doc` | id, category, title, content, vector_embedding(vector), source, updated_at |
|
||||
| `ai_inference_log` | id, api_endpoint, request_hash, response_hash, latency_ms, model_version, created_at |
|
||||
| `ai_audit_record` | id, inference_id, reviewer_id, review_result, issues, created_at |
|
||||
| `disease_knowledge` | id, icd_code, disease_name, symptoms(array), treatments(JSONB), drugs(array), source_guideline |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ------------ | ---------------------------------------- | ------------------ |
|
||||
| 大模型 | DeepSeek-R1/V3（本地部署）或DeepSeek API | 核心推理能力 |
|
||||
| 向量数据库 | Milvus / Qdrant | 知识库语义检索 |
|
||||
| 全文检索 | Elasticsearch | 知识文档全文检索 |
|
||||
| 模型服务框架 | vLLM / TGI | 大模型高效推理服务 |
|
||||
| 训练框架 | LLaMA-Factory / Axolotl（LoRA微调） | 垂直领域微调 |
|
||||
| GPU算力 | 本地A100/H100 或 云GPU（阿里云/腾讯云） | 模型推理与训练 |
|
||||
| 监控 | Arize AI / 自研 | 模型性能与幻觉监控 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接方（调用方） | AI能力需求 |
|
||||
| -------------------- | ---------------------------- |
|
||||
| 慢性病管理（20） | 辅诊推荐、用药建议 |
|
||||
| 医养商城（19） | 健康档案驱动的个性化商品推荐 |
|
||||
| 全生命周期监测（23） | 异常行为识别、健康趋势预测 |
|
||||
| 居家养老管理（10） | 服务方案AI推荐 |
|
||||
| 运营管理（24） | 智能报告生成 |
|
||||
| 数据中台（26） | 健康画像与风险预测模型 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| --------------------------- | -------------------------------- | -------------------------------------------------------- |
|
||||
| 医疗AI幻觉（Hallucination） | 大模型对医疗建议可能输出错误内容 | 强制人工审核关键推荐 + RAG（知识增强检索）降低幻觉率 |
|
||||
| GPU算力成本 | 本地GPU服务器成本高昂 | 初期用API接口（DeepSeek云API），规模化后自建 |
|
||||
| 医疗AI合规 | 医疗AI辅助诊断受监管（需备案） | 明确定位为"辅助工具"而非"诊断工具"，符合医疗器械监管要求 |
|
||||
| 数据训练合规 | 用患者数据训练模型需合规授权 | 数据脱敏处理 + 患者知情同意 |
|
||||
| 边界：AI仅辅助，不替代医生 | 所有AI推荐须经医生确认后执行 | 系统界面明确标注"AI辅助建议，以医生判断为准" |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------------ | ---------------------------- |
|
||||
| 第一期 | 知识检索（RAG）+ 基础推荐（DeepSeek API） | 医疗知识库构建完成 |
|
||||
| 第二期 | 辅诊推荐 + 用药建议 + 医疗审核 | 本地GPU算力就绪或API成本可控 |
|
||||
| 第三期 | 垂直微调模型 + 区域辅诊监测 + 模型管理平台 | 标注数据积累足够 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
人工智能服务是整个医养平台的"智慧大脑"，其大模型部署、医疗知识图谱、辅诊推荐等核心能力在 mall 中完全缺失，**必须独立建设**。
|
||||
|
||||
建议初期采用 DeepSeek API 方式快速落地知识检索和基础推荐，待标注数据积累到一定规模后再进行垂直微调和私有化部署，降低初期投入风险。所有AI医疗建议必须设置人工审核环节，确保医疗安全。
|
||||
213
模块规划/23-全生命周期监测平台-模块规划.md
Normal file
213
模块规划/23-全生命周期监测平台-模块规划.md
Normal file
@@ -0,0 +1,213 @@
|
||||
# 全生命周期监测平台 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
全生命周期监测平台（以下简称"监测平台"）是以**IoT传感器 + AI分析 + GIS空间定位**为三大技术支柱，面向机构养老、居家养老、社区养老三类场景的**全场景感知与智能响应系统**。
|
||||
|
||||
监测平台实现对老人生命体征、行动轨迹、生活行为的24小时全方位感知，并通过AI分析引擎对异常数据进行实时识别与智能调度，最终形成"感知→分析→预警→响应→复盘"的完整闭环。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 实现老人定位（室内+室外）及空间资源（床位/房间/设备）的统一管理
|
||||
2. 实现体征数据（心率/血压/血氧/血糖等）的持续监测与预警
|
||||
3. 实现行为分析（活动规律/睡眠质量/跌倒检测）与智能巡检
|
||||
4. 实现紧急事件的多级智能调度与响应追踪
|
||||
5. 提供给家属的实时服务互动与关爱功能
|
||||
6. 为运营管理、数据中台提供高质量监测数据资产
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
1. 智能定位与空间管理
|
||||
2. 健康监测与预警
|
||||
3. 行为分析与智能巡检
|
||||
4. 智能调度与响应
|
||||
5. 运营管理与质控
|
||||
6. 家属服务互动
|
||||
7. 系统管理与运维
|
||||
|
||||
### 3.2 二级模块
|
||||
|
||||
**智能定位与空间管理**：
|
||||
|
||||
- 实时位置追踪（室内UWB/BLE定位 + 室外GPS）
|
||||
- 电子围栏管理（自定义危险区域、夜间离床检测）
|
||||
- 空间档案（床位管理、房间资源、设备位置地图）
|
||||
- 人员流向与空间热力图分析
|
||||
|
||||
**健康监测与预警**：
|
||||
|
||||
- 体征数据采集（手环/腕表/床垫传感器等多设备接入）
|
||||
- 体征基线建立（个体化正常值区间）
|
||||
- 实时预警（三级告警：提醒/警告/危险）
|
||||
- 历史体征趋势分析与报告
|
||||
- 体征异常AI识别（结合AI服务22号模块）
|
||||
|
||||
**行为分析与智能巡检**：
|
||||
|
||||
- 活动量统计（步数/活跃时间/久坐检测）
|
||||
- 睡眠质量分析（入睡时间/浅眠/深眠/REM）
|
||||
- 跌倒智能检测（传感器 + 视频AI双重验证）
|
||||
- 巡检任务管理（护理人员GPS打卡 + 任务清单）
|
||||
- 巡检记录与异常上报
|
||||
|
||||
**智能调度与响应**：
|
||||
|
||||
- SOS紧急呼叫（一键求救 + 自动定位）
|
||||
- 多级调度规则（就近护理员→值班护士→急救系统）
|
||||
- 响应计时与追踪
|
||||
- 事件处置闭环（处置记录 + 回访 + 总结）
|
||||
- 对接120急救系统（⚠️ 待确认接口标准）
|
||||
|
||||
**运营管理与质控**：
|
||||
|
||||
- 护理服务质量指标看板
|
||||
- 巡检完成率、响应及时率等KPI统计
|
||||
- 老人满意度采集
|
||||
- 规范化服务流程审核
|
||||
|
||||
**家属服务互动**：
|
||||
|
||||
- 家属APP/小程序（老人实时状态查看）
|
||||
- 关爱视频通话（⚠️ 须协调隐私保护规则）
|
||||
- 健康报告推送（周报/月报自动生成）
|
||||
- 服务记录可视化（家属端查看护理记录）
|
||||
|
||||
**系统管理与运维**：
|
||||
|
||||
- 设备管理（设备注册/激活/更换/批量OTA升级）
|
||||
- 账号权限管理（机构管理员/护理人员/家属多角色）
|
||||
- 系统集成配置（与IoT平台16号模块接口对接）
|
||||
- 异常日志与运维告警
|
||||
|
||||
### 3.3 核心功能矩阵
|
||||
|
||||
| 功能模块 | 技术支柱 | 关键指标 |
|
||||
| -------- | --------------------- | -------------- |
|
||||
| 室内定位 | UWB/BLE/RFID | 定位精度≤1m |
|
||||
| 跌倒检测 | 加速度传感器 + 视频AI | 检测准确率≥95% |
|
||||
| SOS响应 | 一键呼叫 + 调度 | 响应时长≤30秒 |
|
||||
| 体征预警 | IoT + 规则引擎 | 预警延迟≤5秒 |
|
||||
| 家属告知 | 推送 + APP | 及时通知率100% |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| --------------------------- | --------- | ---------- |
|
||||
| IoT设备接入与数据采集 | 无 | 须独立建设 |
|
||||
| 定位引擎（UWB/BLE/GPS融合） | 无 | 须独立建设 |
|
||||
| 实时体征监测流处理 | 无 | 须独立建设 |
|
||||
| AI行为分析（跌倒/睡眠） | 无 | 须独立建设 |
|
||||
| 多级调度与响应引擎 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备任何IoT感知和实时流处理能力，强行堆入会导致架构崩溃（实时流式数据处理与电商事务型处理的技术栈完全不同）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立系统建设（IoT + AI + GIS综合平台）**
|
||||
|
||||
- **IoT接入层**：通过16号模块（智能物联网管理系统，EMQX Broker）统一接入
|
||||
- **数据处理层**：Apache Kafka（实时流）+ TimescaleDB/InfluxDB（时序数据库）
|
||||
- **AI分析层**：调用22号AI服务模块（跌倒检测/异常识别/行为分析）
|
||||
- **GIS定位层**：室内用UWB/BLE定位SDK + 室外GPS，地图可视化用高德/百度SDK
|
||||
- **应用层**：机构管理后台（Vue3）+ 家属小程序（uni-app）+ 护理人员APP
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **室内定位引擎**：UWB硬件部署方案 + BLE信标融合定位算法
|
||||
2. **时序数据管理**：体征数据的高频写入、压缩存储、降采样查询
|
||||
3. **实时规则引擎**：可配置的体征预警规则，支持个体化阈值设置
|
||||
4. **跌倒检测算法**：基于加速度传感器数据的跌倒模型（或采购成熟IoT设备自带算法）
|
||||
5. **多级调度流程**：可配置的事件升级规则，支持超时自动升级
|
||||
6. **视频流处理**：摄像头接入 + 隐私保护（模糊化处理）
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | --------------------------------------------------------------------------------------------------- |
|
||||
| `elder_location` | id, elder_id, x, y, floor, location_type(indoor/outdoor), device_id, ts(时序主键) |
|
||||
| `vital_sign_record` | id, elder_id, device_id, metric_type, value, unit, quality, ts |
|
||||
| `vital_alert` | id, elder_id, alert_level(1/2/3), metric_type, trigger_value, threshold, status, resolved_at |
|
||||
| `fall_event` | id, elder_id, detected_by, device_id, location, video_clip_url, confirmed, confirmed_by, created_at |
|
||||
| `inspection_task` | id, elder_id, nurse_id, planned_time, checkin_time, checkin_location, status, items(JSONB) |
|
||||
| `sos_event` | id, elder_id, trigger_type, location, assigned_nurse_id, response_time_s, resolved_at, summary |
|
||||
| `space_resource` | id, institution_id, type(bed/room/area), code, floor, polygon_coords(JSONB), status |
|
||||
| `family_notification` | id, elder_id, family_user_id, event_type, content, push_status, push_at |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | ------------------------------- | ---------------------- |
|
||||
| 时序数据库 | TimescaleDB / InfluxDB | 体征数据高频存储与查询 |
|
||||
| 消息流 | Apache Kafka | 实时体征数据流处理 |
|
||||
| 室内定位 | 主流UWB设备（海康/大华/移远等） | 室内精确定位 |
|
||||
| 规则引擎 | Drools / 自定义规则配置 | 可配置体征预警规则 |
|
||||
| 地图SDK | 高德地图SDK | 室外定位可视化 |
|
||||
| 实时通信 | WebSocket / MQTT | 前端实时状态推送 |
|
||||
| 视频流 | GB28181协议 / RTSP | 摄像头视频接入 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接系统 | 方向 | 内容 |
|
||||
| ------------------------ | ----------------- | ------------------------------------ |
|
||||
| 智能物联网管理系统（16） | 依赖 | 设备接入、OTA升级、设备状态管理 |
|
||||
| 人工智能服务（22） | 依赖 | 跌倒检测、行为异常识别、健康趋势预测 |
|
||||
| 呼叫中心（06） | 双向 | SOS事件传递、调度联动 |
|
||||
| 安全系统（09） | 双向 | 围栏报警、安全事件联动 |
|
||||
| 数据中台（26） | 单向输出 | 监测数据汇入数据湖 |
|
||||
| 家属端小程序 | 双向 | 健康数据展示、推送通知 |
|
||||
| 120急救系统 | 单向（⚠️ 待确认） | 危急事件自动通报 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| --------------- | ------------------------------------------ | ----------------------------------------- |
|
||||
| 隐私保护 | 摄像头+位置追踪涉及个人隐私 | 严格权限管控 + 视频脱敏 + 获取知情同意 |
|
||||
| 设备成本 | UWB室内定位硬件成本较高 | 低价值区域可用BLE替代（精度降低但成本低） |
|
||||
| 数据量 | 高频体征数据量极大（秒级采样） | 时序数据库 + 数据降采样策略 |
|
||||
| 跌倒漏报 | 传感器类跌倒检测存在漏报 | 多设备融合检测（传感器+视频双重验证） |
|
||||
| 网络依赖 | 断网环境下感知数据无法上传 | 设备本地缓存 + 网络恢复后补传 |
|
||||
| 边界：监测≠护理 | 本系统提供感知数据，护理操作由护理人员执行 | 清晰划分系统边界，避免功能重复建设 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ---------------------------------------------- | ----------------------- |
|
||||
| 第一期 | 健康监测（体征采集+预警）+ 家属通知 + 基础管理 | IoT物联网平台（16）就绪 |
|
||||
| 第二期 | 室内定位 + 跌倒检测 + SOS响应调度 | UWB硬件采购安装完成 |
|
||||
| 第三期 | AI行为分析 + 全场景可视化大屏 + 数据中台对接 | AI服务（22）就绪 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
全生命周期监测平台是医养机构服务品质的核心保障，涉及IoT感知、实时流处理、AI分析和GIS定位等复杂技术栈，mall 完全缺乏这些能力，**必须独立建设**。
|
||||
|
||||
建议以"健康监测+家属通知"为MVP快速上线，以获得用户信任，再逐步扩展至室内定位、跌倒检测等高价值功能。室内定位设备须优先考虑已具备边缘计算能力的一体化IoT设备，降低软件开发成本。
|
||||
235
模块规划/24-运营管理系统-模块规划.md
Normal file
235
模块规划/24-运营管理系统-模块规划.md
Normal file
@@ -0,0 +1,235 @@
|
||||
# 运营管理系统 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
运营管理系统是面向**平台运营人员、机构管理者和商务人员**的综合运营中枢，承担平台权限管控、服务生命周期管理、数字营销推广、财务分账结算、安全审计和经营决策分析等核心职能。
|
||||
|
||||
该系统是整个医养平台能够商业化运转的**管理骨干**，直接关系到平台运营效率、合规性和商业可持续性。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 建立统一的账号权限中枢，覆盖多机构、多角色、多租户管理
|
||||
2. 管理服务产品的全生命周期（上线→运营→下架）
|
||||
3. 提供多维度数字营销工具（优惠券/补贴/广告位/活动）
|
||||
4. 构建平台财务分账结算和提现管理体系
|
||||
5. 建立完整的安全审计与操作日志体系
|
||||
6. 提供关键经营指标的实时看板与决策分析报告
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
1. 权限管理中枢
|
||||
2. 服务生命周期管理
|
||||
3. 数字化营销工具箱
|
||||
4. 财务分账中枢
|
||||
5. 安全审计模块
|
||||
6. 决策支持与数据分析
|
||||
7. 商城运营功能（直播/智能设备/积分拼团等）
|
||||
|
||||
### 3.2 二级功能清单
|
||||
|
||||
**权限管理中枢**：
|
||||
|
||||
- 超级管理员账号体系（平台级）
|
||||
- 机构管理员账号体系（机构级多租户）
|
||||
- 角色权限矩阵（RBAC细粒度权限配置）
|
||||
- 操作员批量导入/导出
|
||||
- 账号安全策略（密码周期/两步验证/IP白名单）
|
||||
|
||||
**服务生命周期管理**：
|
||||
|
||||
- 服务/产品上架审核流程
|
||||
- 服务类目管理与价格备案
|
||||
- 服务版本管理与历史记录
|
||||
- 服务下架工单与善后处理
|
||||
- 服务SLA指标配置（响应时效/评分门槛等）
|
||||
|
||||
**数字化营销工具箱**：
|
||||
|
||||
- 优惠券配置（折扣/减满/礼品卡）
|
||||
- 平台补贴（老人减免/政府补贴联动）
|
||||
- 广告位管理（Banner/首页推荐/弹窗）
|
||||
- 活动策划（限时特卖/节日活动/抽奖）
|
||||
- 积分体系管理（积分规则/兑换商品/有效期）
|
||||
- 拼团活动管理（成团规则/价格配置）
|
||||
- 会员等级与权益配置
|
||||
|
||||
**财务分账中枢**：
|
||||
|
||||
- 订单对账（平台订单与财务账单核对）
|
||||
- 多方分账规则配置（平台抽成/机构分成/服务商分成）
|
||||
- 政府补贴资金台账
|
||||
- 服务商提现申请与审批
|
||||
- 财务报表（日/周/月/年报）
|
||||
- 税务凭证导出（⚠️ 待确认开票接入方式）
|
||||
|
||||
**安全审计模块**：
|
||||
|
||||
- 全量操作日志（操作人/时间/IP/操作内容）
|
||||
- 异常登录检测（异地登录/多次失败告警）
|
||||
- 敏感数据访问审计
|
||||
- 合规性自检报告
|
||||
- 数据导出审批流程
|
||||
|
||||
**决策支持与数据分析**：
|
||||
|
||||
- 关键经营指标实时看板（GMV/DAU/服务完成率等）
|
||||
- 机构运营排行（服务量/评分/投诉率）
|
||||
- 用户行为漏斗分析
|
||||
- 服务商绩效报告
|
||||
- 营销活动效果分析
|
||||
- 自定义报表导出
|
||||
|
||||
**商城运营功能（来源于源文档22号系统的商城描述）**：
|
||||
|
||||
- 直播带货管理（主播入驻/场次管理/商品关联）
|
||||
- 智能AI设备管理（配套设备销售与服务绑定）
|
||||
- 积分拼团活动（与积分体系联动）
|
||||
- 秒杀活动管理
|
||||
- 新人礼包配置
|
||||
- B2B批量采购专区管理
|
||||
|
||||
### 3.3 核心功能矩阵
|
||||
|
||||
| 功能模块 | 操作人员 | 业务价值 |
|
||||
| -------- | -------- | -------------- |
|
||||
| 权限中枢 | 平台超管 | 安全合规基础 |
|
||||
| 分账结算 | 财务人员 | 商业模式落地 |
|
||||
| 营销工具 | 运营人员 | 用户增长与留存 |
|
||||
| 经营分析 | 管理层 | 决策依据 |
|
||||
| 安全审计 | 合规人员 | 监管合规 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：B（中度契合，可参考 mall 架构后扩展建设）**
|
||||
|
||||
### mall 可直接参考 / 复用的能力：
|
||||
|
||||
| mall 现有能力 | 对应运营功能 | 参考方式 |
|
||||
| ---------------- | ---------------- | ---------------------------------- |
|
||||
| RBAC权限管理 | 权限管理中枢 | 直接参考架构，扩展多租户支持 |
|
||||
| 优惠券与营销活动 | 数字化营销工具箱 | 参考优惠券数据模型，扩展补贴类型 |
|
||||
| 商家分账与结算 | 财务分账中枢 | 参考分账逻辑，扩展政府补贴通道 |
|
||||
| 订单统计报表 | 决策支持看板 | 参考报表结构，扩展医养业务指标 |
|
||||
| 积分体系 | 积分与会员管理 | 直接复用积分规则引擎，扩展兑换商品 |
|
||||
| 广告位管理 | 广告位管理 | 直接复用 |
|
||||
| 直播管理模块 | 直播带货管理 | 直接参考 |
|
||||
|
||||
### 须独立建设的能力（mall 没有）：
|
||||
|
||||
| 医养特有需求 | 说明 |
|
||||
| ---------------- | -------------------------------------- |
|
||||
| 多机构多租户管理 | mall 不涉及机构树与多租户隔离 |
|
||||
| 政府补贴台账 | 政府补贴与医保资金管理，非商业平台概念 |
|
||||
| 服务SLA管理 | 养老服务有响应时效要求，mall 无此配置 |
|
||||
| 合规审计报告 | 医养监管需要合规自检，mall 无此模块 |
|
||||
| 医养类目管理 | 养老服务类目体系与商品类目完全不同 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**B级建设策略：以 mall 运营后台为参考基础，扩展医养特有运营能力**
|
||||
|
||||
- 复用 mall 的权限框架（RBAC）、营销工具（优惠券/积分/广告位）等通用能力
|
||||
- 在此基础上扩展：多租户、政府补贴台账、服务生命周期管理、合规审计
|
||||
- 建议在业务中台（25号）统一身份基础上构建，避免权限体系重复
|
||||
|
||||
**技术选型**：
|
||||
|
||||
- 后端：Node.js + PostgreSQL（与 mall 一致的技术栈，降低团队学习成本）
|
||||
- 前端：Vue3 + Element Plus（PC端管理后台）
|
||||
- 数据分析：ClickHouse（OLAP查询）+ ECharts（可视化）
|
||||
- 分账服务：复用 mall 分账逻辑，扩展政府补贴通道
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **多租户机构管理**：机构树/区域隔离/数据权限边界
|
||||
2. **政府补贴资金管理**：补贴类型配置、资金到账确认、补贴发放核销
|
||||
3. **服务SLA引擎**：服务类型与响应时效绑定，超时自动预警
|
||||
4. **合规审计报告**：可导出的合规自检报告，支持监管查阅
|
||||
5. **医养类目管理**：养老服务分类体系（居家/机构/社区/医疗辅助）
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | ------------------------------------------------------------------------------------- |
|
||||
| `institution` | id, parent_id, name, type, region_code, contract_start, contract_end, status |
|
||||
| `operation_audit_log` | id, operator_id, module, action, target_id, target_type, ip, request_hash, created_at |
|
||||
| `govt_subsidy_record` | id, elder_id, subsidy_type, amount, source, apply_at, approved_at, paid_at, status |
|
||||
| `service_sla_config` | id, service_type, response_time_minutes, escalation_rules(JSONB), updated_by |
|
||||
| `ad_slot` | id, slot_name, position, institution_id, start_time, end_time, media_url, click_count |
|
||||
| `settlement_rule` | id, institution_id, platform_rate, merchant_rate, govt_channel, effective_date |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ------------ | ------------------------------------------ | ---------------------- |
|
||||
| OLAP分析 | ClickHouse | 运营报表高性能聚合查询 |
|
||||
| 数据可视化 | ECharts / AntV G2 | 经营看板图表 |
|
||||
| 审计日志存储 | Elasticsearch | 全量操作日志快速检索 |
|
||||
| 分账服务 | 复用 mall 分账 + 医保专属通道（⚠️ 待确认） | 多方分账与政府补贴 |
|
||||
| 开票接口 | 百旺/航天信息云开票API（⚠️ 待确认） | 财务发票开具 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接系统 | 方向 | 内容 |
|
||||
| ------------------ | ---------------- | ------------------------------ |
|
||||
| 业务中台（25） | 依赖 | 统一身份与权限底座 |
|
||||
| 数据中台（26） | 依赖（数据查询） | 经营分析数据来源 |
|
||||
| 医养商城（19） | 双向 | 商城活动配置/营销投放/财务对账 |
|
||||
| 服务商管理（11） | 双向 | 服务商分账、绩效看板 |
|
||||
| 政府监管系统（01） | 单向上报 | 合规数据上报 |
|
||||
| 短信平台（13） | 调用 | 营销短信、账单通知 |
|
||||
| 长护险（18） | 双向 | 政府补贴台账联动 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ---------------------------------------- | ------------------------------------ | -------------------------------------------------- |
|
||||
| 权限设计复杂度 | 多机构+多角色+多租户权限矩阵设计复杂 | 采用成熟RBAC框架，严格数据权限行级过滤 |
|
||||
| 分账合规 | 多方分账涉及税务和监管要求 | 与财务和法务团队确认分账规则，对接合规开票系统 |
|
||||
| 政府补贴接入 | 各地政府补贴标准不统一 | 补贴类型/金额参数化配置，支持按区域定制 |
|
||||
| 数据分析性能 | 运营报表涉及大量聚合查询 | PostgreSQL主库用于事务，ClickHouse用于分析 |
|
||||
| 边界：本系统管商务运营，不管个人医疗数据 | 避免将老人健康数据直接暴露在运营后台 | 严格数据权限隔离，运营人员无法直接访问老人健康档案 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P0（核心基础，尽早建设）**
|
||||
|
||||
| 分期 | 内容 | 说明 |
|
||||
| ------ | ------------------------------------------------------- | ------------ |
|
||||
| 第一期 | 权限中枢 + 服务管理 + 基础财务结算 | 平台上线必备 |
|
||||
| 第二期 | 营销工具箱 + 经营看板 + 合规审计 | 运营增长必备 |
|
||||
| 第三期 | 政府补贴台账 + 多维度分析报表 + 直播/拼团等商城扩展功能 | 商业化深化 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
运营管理系统是平台商业化运转的核心骨干，**优先级最高（P0）**。
|
||||
|
||||
mall 的权限管理、营销工具、分账结算和积分体系可为本模块提供直接参考（B级），可节省约 40% 的开发工作量。但多机构租户、政府补贴、服务SLA、合规审计等医养特有能力须独立扩展建设。
|
||||
|
||||
建议以 mall 为参考基线，在业务中台（25号）统一身份底座上构建运营管理后台，避免重复建设权限模型。
|
||||
210
模块规划/25-业务中台-模块规划.md
Normal file
210
模块规划/25-业务中台-模块规划.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# 业务中台 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
业务中台是整个医养平台的**共享业务能力底座**，通过服务化拆分将各业务系统共同依赖的核心能力抽离为独立微服务，对上层各业务系统（居家养老、商城、监管、康复等）提供统一调用接口，实现"能力复用、数据一致、避免烟囱"。
|
||||
|
||||
业务中台不直接面向终端用户，而是作为**平台级基础设施层**，支撑所有P0/P1业务系统的稳定运行。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 建立统一身份中心（用户/员工/机构/老人多主体统一管理）
|
||||
2. 建立多端接入层（APP、小程序、PC、大屏、IoT设备统一接入）
|
||||
3. 建立医疗业务中心（分级诊疗、家庭医生签约、服务契约管理）
|
||||
4. 建立监管调度中心（DRG/DIP规则库、审批流引擎、合规校验）
|
||||
5. 建立服务资源中心（适老化改造、商保结算网关、服务商结算）
|
||||
6. 提供统一的消息通知和推送服务
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
1. 用户服务中心
|
||||
2. 医疗业务中心
|
||||
3. 监管调度中心
|
||||
4. 服务资源中心
|
||||
5. 消息通知中心
|
||||
6. 中台管理与治理
|
||||
|
||||
### 3.2 二级功能清单
|
||||
|
||||
**用户服务中心（统一身份）**：
|
||||
|
||||
- 统一账号注册/登录/注销（手机号/微信/人脸等多方式）
|
||||
- 多角色统一管理（老人/家属/护理员/医生/机构管理员/政府监管人员）
|
||||
- 多端统一会话管理（微信小程序/APP/H5/PC）
|
||||
- 账号安全策略（实名认证/设备绑定/异常登录检测）
|
||||
- 老人档案统一主数据（身份信息/健康基线/家属关系/享受政策）
|
||||
- 机构档案统一主数据（机构信息/资质证书/床位/签约服务商）
|
||||
|
||||
**医疗业务中心**：
|
||||
|
||||
- 分级诊疗流程（社区首诊→转诊大医院→下转康复）
|
||||
- 家庭医生签约管理（签约关系/签约服务包/续签/违约处理）
|
||||
- 服务契约管理（服务协议/服务标准/服务期限/续约提醒）
|
||||
- 转介管理（机构间老人转接/流程审批/信息随行）
|
||||
- 病历摘要共享（老人医疗信息跨机构安全访问，⚠️ 需医疗数据授权体系）
|
||||
|
||||
**监管调度中心**：
|
||||
|
||||
- DRG/DIP规则库维护（结合17号医保控费模块）
|
||||
- 审批流引擎（可配置多级审批，供全平台业务使用）
|
||||
- 合规预校验（服务上架合规/营销合规/资质有效期校验）
|
||||
- 服务监督指标（服务完成率/投诉率/整改率联动追踪）
|
||||
|
||||
**服务资源中心**：
|
||||
|
||||
- 适老化改造项目管理（申请→审核→施工→验收，结合15号模块）
|
||||
- 商保结算网关（对接商业险预授权与理赔结算，⚠️ 待确认商保合作方）
|
||||
- 服务资源台账（护理员/设备/床位的统一资源登记与调配）
|
||||
- 服务商结算统一入口
|
||||
|
||||
**消息通知中心**：
|
||||
|
||||
- 统一消息路由（短信/推送/站内信/微信模板消息）
|
||||
- 消息模板管理
|
||||
- 消息发送日志与状态追踪
|
||||
- 优先级队列（紧急预警 > 业务通知 > 营销消息）
|
||||
- 对接13号短信平台
|
||||
|
||||
**中台管理与治理**：
|
||||
|
||||
- API网关（统一鉴权/限流/熔断/路由）
|
||||
- 微服务注册与发现（Nacos/Consul）
|
||||
- 配置中心（各服务配置统一管理）
|
||||
- 服务调用链路追踪（SkyWalking/Jaeger）
|
||||
- 服务健康监控（Prometheus + Grafana）
|
||||
|
||||
### 3.3 能力共享关系
|
||||
|
||||
| 上层业务系统 | 调用中台能力 |
|
||||
| -------------- | --------------------------- |
|
||||
| 居家养老（10） | 统一身份+消息通知+服务契约 |
|
||||
| 医养商城（19） | 统一身份+消息通知 |
|
||||
| 运营管理（24） | 统一身份（权限底座）+审批流 |
|
||||
| 呼叫中心（06） | 统一身份+老人档案（主数据） |
|
||||
| 健康管理（08） | 统一身份+老人档案+消息通知 |
|
||||
| 长护险（18） | 监管调度+商保结算网关 |
|
||||
| 评估系统（07） | 统一身份+老人档案 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ------------------------------------- | ---------------------------------- | ---------- |
|
||||
| 多主体统一身份（老人/医护/机构/政府） | mall 仅有消费者+商家+骑手+客服角色 | 须独立重建 |
|
||||
| 分级诊疗与签约管理 | 无 | 须独立建设 |
|
||||
| DRG/DIP规则库与合规校验 | 无 | 须独立建设 |
|
||||
| 商保结算网关 | 无 | 须独立建设 |
|
||||
| 微服务治理与API网关 | mall 为单一应用，无中台架构 | 须独立建设 |
|
||||
| 审批流引擎 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商单体/单角色系统，不具备医养平台所需的多主体、多角色、中台化治理能力，强行堆入会导致数据隔离失控和架构崩溃。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立建设（微服务中台架构）**
|
||||
|
||||
- **API网关**：Kong / APISIX（统一鉴权/限流/路由）
|
||||
- **服务注册与发现**：Nacos
|
||||
- **消息中间件**：RabbitMQ / Kafka（异步消息解耦）
|
||||
- **配置中心**：Nacos Config / Apollo
|
||||
- **数据库**：PostgreSQL（主业务数据）+ Redis（缓存/会话）
|
||||
- **链路追踪**：SkyWalking
|
||||
- **容器化**：Docker + Kubernetes（K8s）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **多主体身份模型**：支持老人/家属/护理员/医生/机构管理员/政府监管6+类角色的统一管理
|
||||
2. **同一账号多角色切换**：一个手机号可关联多个角色（如一个人既是家属也是护理员）
|
||||
3. **数据权限行级隔离**：不同机构的数据严格隔离，不同角色的数据访问范围不同
|
||||
4. **可视化审批流引擎**：拖拽式审批节点配置，供全平台各业务场景复用
|
||||
5. **医疗数据授权与访问控制**：老人授权特定医生访问其病历的细粒度权限控制
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| ------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `unified_user` | id, phone, face_id, wechat_openid, real_name, id_card, roles(array), status |
|
||||
| `elder_master` | id, user_id, gender, birth_date, address, health_baseline(JSONB), policy_tags(array), institution_id |
|
||||
| `family_relation` | id, elder_id, family_user_id, relation_type, is_emergency_contact, authorized_access(JSONB) |
|
||||
| `doctor_patient_contract` | id, doctor_id, elder_id, service_package_id, start_date, end_date, status, renewal_count |
|
||||
| `approval_workflow` | id, name, nodes(JSONB), applicable_modules(array), version, is_active |
|
||||
| `approval_instance` | id, workflow_id, apply_user_id, target_id, target_type, current_node, status, created_at |
|
||||
| `message_record` | id, user_id, channel(sms/push/wechat), template_id, content, status, sent_at |
|
||||
| `service_resource` | id, type, institution_id, resource_data(JSONB), status, available_from |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ------------ | -------------------- | -------------------- |
|
||||
| API网关 | Kong / APISIX | 统一鉴权/限流/熔断 |
|
||||
| 服务注册发现 | Nacos | 微服务治理 |
|
||||
| 消息中间件 | RabbitMQ | 异步业务解耦 |
|
||||
| 链路追踪 | SkyWalking | 微服务调用链路分析 |
|
||||
| 监控 | Prometheus + Grafana | 服务健康监控 |
|
||||
| 实名认证 | 公安三要素API | 老人/员工实名认证 |
|
||||
| 人脸识别 | 百度/旷视 人脸SDK | 人脸登录/打卡核验 |
|
||||
| 容器编排 | Docker + Kubernetes | 微服务部署与弹性伸缩 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接系统 | 方向 | 内容 |
|
||||
| ------------------ | ----------------------- | ------------------------ |
|
||||
| 全平台所有业务系统 | 被调用 | 统一身份/消息/审批流提供 |
|
||||
| 医保DIP（17） | 依赖 | 合规规则库同步 |
|
||||
| 短信平台（13） | 调用 | 消息发送路由 |
|
||||
| 第三方实名认证平台 | 调用（⚠️ 待确认供应商） | 实名核验 |
|
||||
| 商保合作方 | 调用（⚠️ 待确认） | 预授权与理赔结算接口 |
|
||||
| 政府监管系统（01） | 单向上报 | 合规数据上报 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------ | ------------------------------ | -------------------------------------------- |
|
||||
| 中台过度设计 | 过早抽象中台导致开发周期延长 | 先解决P0业务需求，逐步沉淀共性能力到中台 |
|
||||
| 多角色权限矩阵复杂 | 角色多、权限细粒度设计复杂 | 采用成熟RBAC+ABAC框架，严格评审行级权限规则 |
|
||||
| 数据隔离合规 | 多机构数据隔离是监管要求 | 行级安全（RLS）+ 租户ID过滤强制执行 |
|
||||
| 医疗数据访问授权 | 老人病历跨机构访问涉及数据伦理 | 明确老人授权同意后才可访问，记录完整访问日志 |
|
||||
| 商保网关接入复杂 | 各商业险公司接口不统一 | 先对接1-2家主流商保公司，逐步扩展 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P1（P0业务系统的必要前置）**
|
||||
|
||||
| 分期 | 内容 | 说明 |
|
||||
| ------ | ---------------------------------- | ------------------------- |
|
||||
| 第一期 | 统一身份+多角色+API网关+消息通知 | P0/P1业务系统上线前须完成 |
|
||||
| 第二期 | 审批流引擎+医疗业务中心+监管调度 | P1系统建设期间同步构建 |
|
||||
| 第三期 | 商保结算网关+转介管理+中台治理完善 | P2阶段按需扩展 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
业务中台是整个医养平台的**底层业务基础设施**，mall 不具备医养平台所需的多主体身份、中台化治理、审批流引擎等任何中台能力，**必须独立建设**。
|
||||
|
||||
业务中台应以"够用即可，避免过度设计"为原则：优先建设统一身份与API网关（所有P0系统都依赖），再随业务发展逐步将共性能力沉淀到中台，切忌一开始就追求完整中台架构导致项目延期。
|
||||
220
模块规划/26-数据中台-模块规划.md
Normal file
220
模块规划/26-数据中台-模块规划.md
Normal file
@@ -0,0 +1,220 @@
|
||||
# 数据中台 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
数据中台是整个医养平台的**数据资产管理与智能分析体系**，负责汇聚全平台各业务系统产生的数据（结构化/半结构化/非结构化），通过数据湖、数据仓库、主题库和专题库的分层架构，为运营决策、AI模型训练、政府监管上报和区域医养事业评估提供高质量数据支撑。
|
||||
|
||||
数据中台不直接面向业务用户，而是作为**数据资产的统一管理层**，对上层消费系统（运营管理、AI服务、政府监管）提供标准化数据服务。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 构建医养数据湖，统一汇聚全平台数据资产
|
||||
2. 建立 ODS → 基准层 → 主题层 → 专题层的分层数仓体系
|
||||
3. 建立数据治理平台（数据质量/数据血缘/数据目录）
|
||||
4. 构建医疗知识图谱（ICD-10/SNOMED CT/中医知识体系）
|
||||
5. 构建 AI 大模型训练数据管理平台（DeepSeek 垂直微调数据集管理）
|
||||
6. 提供标准化的数据服务API（报表查询/指标计算/数据导出）
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
1. 数据湖基座
|
||||
2. 数据仓库（分层体系）
|
||||
3. 数据治理平台
|
||||
4. 医疗知识图谱
|
||||
5. AI大模型训练数据管理
|
||||
6. 数据服务与API
|
||||
|
||||
### 3.2 二级功能清单
|
||||
|
||||
**数据湖基座**：
|
||||
|
||||
- 全平台数据接入（数据库CDC/Kafka流/文件上传）
|
||||
- 多源异构数据统一存储（结构化表/JSON/文件/时序数据）
|
||||
- 数据分区策略（按时间/机构/数据类型分区）
|
||||
- 数据访问权限管理（列级/行级权限）
|
||||
- 数据生命周期管理（冷热分层/自动归档）
|
||||
|
||||
**数据仓库分层体系**：
|
||||
|
||||
- ODS层（贴源层）：从各业务系统实时/批量同步原始数据
|
||||
- 基准层（DWD）：数据清洗/标准化/维度建模
|
||||
- 主题层（DWS）：老人域/机构域/服务域/健康域等主题宽表
|
||||
- 专题层（ADS）：运营指标/监管上报/AI训练集等面向具体场景的专题表
|
||||
|
||||
**数据治理平台**：
|
||||
|
||||
- 数据目录（元数据管理，数据资产全景地图）
|
||||
- 数据血缘（字段级来源追踪）
|
||||
- 数据质量规则配置（完整性/一致性/时效性监控）
|
||||
- 数据标准（统一字段命名、枚举值、编码规范）
|
||||
- 数据问题工单（数据质量问题发现→修复→关闭闭环）
|
||||
|
||||
**医疗知识图谱**：
|
||||
|
||||
- ICD-10疾病分类体系（国家标准10000+节点）
|
||||
- SNOMED CT 国际医学术语（⚠️ 待确认授权）
|
||||
- 药品知识图谱（药品-适应症-禁忌-相互作用-价格）
|
||||
- 中医知识体系（证候-方剂-药材-经络关系）
|
||||
- 护理规范知识库（养老护理操作规范、评估量表）
|
||||
- 知识图谱查询API（供AI服务22号调用）
|
||||
|
||||
**AI大模型训练数据管理**：
|
||||
|
||||
- 标注任务管理（标注人员分配/质检/审核）
|
||||
- 训练数据集版本管理（数据集切割/版本记录）
|
||||
- 数据脱敏工具（患者隐私字段自动脱敏）
|
||||
- 训练数据质量评估（标注一致性、数据分布分析）
|
||||
- 与AI服务（22号）训练管道对接
|
||||
|
||||
**数据服务与API**：
|
||||
|
||||
- 统一查询API（支持SQL/REST两种接口）
|
||||
- 指标计算服务（平台关键指标实时/离线计算）
|
||||
- 监管报表生成（对接01号政府监管系统的数据上报）
|
||||
- 数据导出服务（Excel/CSV/JSON格式导出审批）
|
||||
- 数据订阅推送（增量数据变化推送给订阅系统）
|
||||
|
||||
### 3.3 数据分层模型
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ 专题层ADS │ 运营看板 │ 监管上报 │ AI训练集 │ 选题分析 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ 主题层DWS │ 老人主题 │ 机构主题 │ 服务主题 │ 健康主题 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ 基准层DWD │ 清洗/标准化/维度建模（数据规范化处理） │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ 同步层ODS │ 全平台27个业务系统原始数据实时/批量同步 │
|
||||
├─────────────────────────────────────────────────────────┤
|
||||
│ 数据湖 │ 结构化+半结构化+非结构化数据统一存储 │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ----------------------------- | --------- | ---------- |
|
||||
| 数据湖架构（Hadoop/对象存储） | 无 | 须独立建设 |
|
||||
| 分层数仓（ODS/DWD/DWS/ADS） | 无 | 须独立建设 |
|
||||
| 数据治理平台 | 无 | 须独立建设 |
|
||||
| 医疗知识图谱 | 无 | 须独立建设 |
|
||||
| AI训练数据管理 | 无 | 须独立建设 |
|
||||
| OLAP分析引擎 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备任何大数据处理和数据治理能力，强行堆入会导致维护灾难（OLTP与OLAP完全不同的技术栈和运维要求）。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立建设（大数据平台架构）**
|
||||
|
||||
云原生路线（推荐云部署，降低运维难度）：
|
||||
|
||||
- **数据湖存储**：阿里云OSS / 腾讯云COS（对象存储）
|
||||
- **实时数据接入**：Apache Kafka（CDC流数据）
|
||||
- **批量数据同步**：DataX / SeaTunnel（从各业务系统导入）
|
||||
- **计算引擎**：Apache Spark（批计算）+ Apache Flink（流计算）
|
||||
- **数据仓库**：ClickHouse（OLAP分析）或阿里云MaxCompute（云数仓）
|
||||
- **数据治理**：Apache Atlas / 自研
|
||||
- **知识图谱**：Neo4j（图数据库）
|
||||
- **调度**：Apache DolphinScheduler（数据任务调度）
|
||||
- **可视化**：Superset / 自研（数据探索）
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **数据标准体系**：统一全平台的字段命名规范、枚举值标准、编码规范
|
||||
2. **医疗数据脱敏工具**：批量脱敏（姓名/身份证/手机号/病历关键信息）
|
||||
3. **数据访问审批流程**：敏感数据（健康档案/医疗记录）的访问申请与审批
|
||||
4. **数据质量监控**：每日自动检测数据完整性、一致性，异常自动告警
|
||||
5. **监管数据上报格式**：按照民政/卫健委数据上报标准生成上报文件（⚠️ 待确认各地标准）
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型（数据治理侧）
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| `data_catalog` | id, table_name, layer(ods/dwd/dws/ads), description, owner, sensitivity_level, update_frequency |
|
||||
| `data_lineage` | id, source_table, source_column, target_table, target_column, transform_logic, created_at |
|
||||
| `data_quality_rule` | id, table_name, rule_type, rule_config(JSONB), alert_threshold, is_active |
|
||||
| `data_quality_result` | id, rule_id, check_date, total_count, fail_count, fail_rate, status |
|
||||
| `knowledge_node` | id, graph_type(icd10/drug/cm), code, name, properties(JSONB), created_at |
|
||||
| `knowledge_relation` | id, source_node_id, target_node_id, relation_type, weight, source_doc |
|
||||
| `dataset_version` | id, name, purpose(ai_train/report/export), snapshot_date, record_count, status, is_desensitized |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ---------- | ----------------------- | ---------------------- |
|
||||
| 数据湖存储 | 阿里云OSS / 腾讯云COS | 原始数据湖存储 |
|
||||
| 数据同步 | DataX / SeaTunnel | 业务系统→数仓增量同步 |
|
||||
| 流处理 | Apache Flink | 实时数据流处理与聚合 |
|
||||
| 批处理 | Apache Spark | 大规模批计算任务 |
|
||||
| OLAP引擎 | ClickHouse | 高性能分析查询 |
|
||||
| 图数据库 | Neo4j | 医疗知识图谱存储与查询 |
|
||||
| 任务调度 | Apache DolphinScheduler | 数据任务的DAG调度 |
|
||||
| 数据治理 | Apache Atlas | 元数据管理与血缘追踪 |
|
||||
| 数据可视化 | Apache Superset | 数据探索与自助分析 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接系统 | 方向 | 内容 |
|
||||
| -------------------- | --------------------- | -------------------------------- |
|
||||
| 全部27个业务系统 | 数据流入 | 业务数据同步到ODS层 |
|
||||
| 政府监管系统（01） | 数据流出 | 上报标准格式数据文件 |
|
||||
| AI服务（22） | 双向 | 知识图谱API供应 + 训练数据集供应 |
|
||||
| 运营管理（24） | 数据流出 | 经营分析指标供应 |
|
||||
| ClickHouse（分析库） | 数据流出 | ADS层面向分析的宽表 |
|
||||
| SNOMED CT授权方 | 数据引入（⚠️ 待确认） | 国际医学术语授权 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| -------------------------------- | ---------------------------------------------- | ---------------------------------------------------------- |
|
||||
| 建设周期长 | 大数据平台建设周期往往在6-12个月以上 | P2优先级，待核心业务系统稳定后再建 |
|
||||
| 运维复杂度 | Kafka/Spark/Flink/ClickHouse等技术栈运维门槛高 | 优先选用云托管服务（如阿里云DataWorks）降低运维成本 |
|
||||
| 数据隐私合规 | 医疗数据属于敏感个人信息（PIPL/等保三级） | 数据分类分级 + 脱敏 + 访问审批 + 等保合规 |
|
||||
| 数据标准不统一 | 各业务系统字段定义不统一，数据清洗工作量大 | 在业务中台（25）建立统一数据标准，从源头控制数据质量 |
|
||||
| 知识图谱授权 | SNOMED CT商业授权费用较高 | 先用ICD-10（国标免费）+自建医养知识图谱，后续评估SNOMED CT |
|
||||
| 边界：数据中台只做数据，不做业务 | 避免将业务逻辑放到数仓中实现 | 严格区分数据层和应用层的职责边界 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2**
|
||||
|
||||
| 分期 | 内容 | 前置条件 |
|
||||
| ------ | ------------------------------------------- | ------------------------------- |
|
||||
| 第一期 | ODS同步 + ClickHouse + 运营基础报表 | P0/P1业务系统产生足够数据后启动 |
|
||||
| 第二期 | 数据治理 + 主题层建模 + 知识图谱（ICD-10） | 数仓稳定运行3-6个月后启动 |
|
||||
| 第三期 | AI训练数据管理 + SNOMED CT + 全链路数据血缘 | AI服务（22）建设期间同步 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
数据中台是医养平台的**数据智慧层**，mall 完全不具备大数据处理和数据治理能力，**必须独立建设**。
|
||||
|
||||
建议初期不追求完整的大数据平台，而是以"ClickHouse + 基础运营报表 + 数据同步"为MVP，在各业务系统积累足够数据后再逐步完善数仓分层和数据治理体系。优先使用云托管大数据服务降低运维负担，待数据量规模化后再评估自建集群的必要性。
|
||||
235
模块规划/27-技术中台-模块规划.md
Normal file
235
模块规划/27-技术中台-模块规划.md
Normal file
@@ -0,0 +1,235 @@
|
||||
# 技术中台 模块规划
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块定位
|
||||
|
||||
技术中台是整个医养平台的**技术基础设施层**，负责为所有业务系统提供统一的微服务架构、医疗互联互通协议（HL7/FHIR）、API网关治理、消息队列、区块链存证和国密安全加密等基础技术能力，确保整个平台的高可用、高安全、高可扩展性。
|
||||
|
||||
技术中台不直接提供业务功能，而是作为平台**技术底座**，是所有业务系统稳定运行的基础保障。
|
||||
|
||||
---
|
||||
|
||||
## 2. 建设目标
|
||||
|
||||
1. 建立微服务架构体系（服务拆分/注册/发现/治理）
|
||||
2. 实现医疗互联互通标准协议（HL7 FHIR R4）的统一适配
|
||||
3. 构建独立API网关（统一鉴权/限流/熔断/审计）
|
||||
4. 建立统一消息队列体系（异步解耦/顺序保障/死信处理）
|
||||
5. 构建区块链存证服务（服务记录/审批数据/电子签章不可篡改）
|
||||
6. 建立国密加密体系（SM2/SM3/SM4满足医疗数据合规加密要求）
|
||||
7. 提供统一的监控告警、日志采集和链路追踪能力
|
||||
|
||||
---
|
||||
|
||||
## 3. 核心功能范围
|
||||
|
||||
### 3.1 一级模块
|
||||
|
||||
1. 微服务治理平台
|
||||
2. 医疗互联互通协议层（HL7/FHIR）
|
||||
3. API网关
|
||||
4. 消息队列服务
|
||||
5. 区块链存证服务
|
||||
6. 国密安全加密服务
|
||||
7. 统一监控与可观测性
|
||||
|
||||
### 3.2 二级功能清单
|
||||
|
||||
**微服务治理平台**：
|
||||
|
||||
- 服务注册与发现（Nacos）
|
||||
- 服务配置中心（动态配置下发，无需重启）
|
||||
- 服务熔断与降级（Sentinel/Resilience4j）
|
||||
- 负载均衡策略配置
|
||||
- 灰度发布与蓝绿部署支持
|
||||
- 服务版本管理与 API 契约管理（OpenAPI 3.0）
|
||||
|
||||
**医疗互联互通协议层**：
|
||||
|
||||
- HL7 FHIR R4 资源适配（Patient/Observation/MedicationRequest等标准资源）
|
||||
- FHIR Server（开源 HAPI FHIR）
|
||||
- 接口适配网关（将各业务系统内部接口适配为FHIR标准接口）
|
||||
- 医疗数据交换格式校验（与外部HIS/LIS/PACS对接时格式验证）
|
||||
- 互联互通成熟度等级评测支持（⚠️ 待确认目标等级与评测节点）
|
||||
|
||||
**API网关**：
|
||||
|
||||
- 统一鉴权（JWT/OAuth2.0/API Key多种鉴权方式）
|
||||
- 请求限流（按IP/用户/接口的多维度限流）
|
||||
- 熔断降级（自动熔断异常服务，返回fallback响应）
|
||||
- 请求路由（按路径/版本/灰度标签路由）
|
||||
- 接口审计日志（所有API调用完整记录）
|
||||
- SSL/TLS终止（统一证书管理，加密传输）
|
||||
|
||||
**消息队列服务**：
|
||||
|
||||
- 业务解耦消息发布订阅（各业务系统间异步通信）
|
||||
- 顺序消息支持（如审批流程的顺序节点推进）
|
||||
- 延迟消息（定时提醒/超时预警等场景）
|
||||
- 消息重试与死信队列（消费失败后的重试与人工处理）
|
||||
- 消息轨迹追踪（消息全链路状态查询）
|
||||
- 与区块链存证联动（关键业务消息的存证触发）
|
||||
|
||||
**区块链存证服务**：
|
||||
|
||||
- 存证数据写入（服务记录/长护险服务凭证/审批结果/电子合同）
|
||||
- 存证哈希查询（按业务ID查询对应区块链哈希）
|
||||
- 存证验真（对比本地数据与链上哈希，验证未被篡改）
|
||||
- 区块链平台管理（节点状态/存证量统计）
|
||||
- 对接公信力区块链平台（⚠️ 待确认：百度超级链/腾讯TrustSQL/蚂蚁链等，需政府监管认可）
|
||||
|
||||
**国密安全加密服务**：
|
||||
|
||||
- SM2（非对称加密）：关键数据的加密存储与数字签名
|
||||
- SM3（哈希算法）：数据完整性校验（替代SHA-256）
|
||||
- SM4（对称加密）：批量数据的加密传输与存储
|
||||
- 密钥管理服务（KMS）（密钥生成/存储/轮换/销毁）
|
||||
- 国密TLS（TLCP协议支持，⚠️ 需专用服务器支持）
|
||||
- 电子签章服务（结合SM2完成电子文件签章）
|
||||
|
||||
**统一监控与可观测性**：
|
||||
|
||||
- 指标监控（Prometheus + Grafana：系统负载/接口响应时间/错误率）
|
||||
- 日志采集（ELK：Elasticsearch + Logstash + Kibana）
|
||||
- 分布式链路追踪（SkyWalking / Jaeger）
|
||||
- 告警规则配置与通知（告警→飞书/钉钉/短信通知）
|
||||
- 容量规划看板（各服务资源使用趋势预测）
|
||||
- 故障自动诊断（AIOps初级能力，基于历史告警模式）
|
||||
|
||||
### 3.3 技术架构总览
|
||||
|
||||
| 层次 | 组件 | 作用 |
|
||||
| -------- | ----------------------------- | -------------------- |
|
||||
| 接入层 | API网关（Kong/APISIX） | 统一入口、鉴权、限流 |
|
||||
| 服务层 | Nacos + Sentinel | 服务注册、发现、熔断 |
|
||||
| 通信层 | RabbitMQ / Kafka | 异步消息解耦 |
|
||||
| 安全层 | 国密SDK + KMS | 数据安全加密 |
|
||||
| 互联层 | HAPI FHIR Server | 医疗标准协议适配 |
|
||||
| 存证层 | 区块链平台 | 关键数据不可篡改 |
|
||||
| 可观测层 | ELK + Prometheus + SkyWalking | 全链路监控 |
|
||||
| 基础设施 | Docker + Kubernetes | 容器化部署与弹性伸缩 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 与现有 mall 的关系
|
||||
|
||||
**契合度：D（不适配）**
|
||||
|
||||
| 能力需求 | mall 现状 | 结论 |
|
||||
| ----------------------------- | ------------------------------------- | ---------- |
|
||||
| HL7/FHIR 医疗互联互通协议 | 无 | 须独立建设 |
|
||||
| 区块链存证服务 | 无 | 须独立建设 |
|
||||
| 国密加密体系（SM2/SM3/SM4） | 无 | 须独立建设 |
|
||||
| 微服务治理平台 | mall 为单体或简单分层架构，无中台治理 | 须独立建设 |
|
||||
| 统一API网关（含医疗合规审计） | 无 | 须独立建设 |
|
||||
| 分布式消息队列 | 无 | 须独立建设 |
|
||||
|
||||
mall 是通用电商平台，不具备任何医疗互联互通、区块链存证、国密加密等专业技术能力，强行堆入会导致整体架构崩溃和医疗数据合规失控。
|
||||
|
||||
---
|
||||
|
||||
## 5. 规划判断
|
||||
|
||||
**独立建设（Platform Engineering，技术基础设施优先建设）**
|
||||
|
||||
建议云原生方案（降低运维难度，按需弹性伸缩）：
|
||||
|
||||
- **容器化**：Docker + Kubernetes（阿里云ACK / 腾讯云TKE托管）
|
||||
- **API网关**：Kong（开源版）/ APISIX
|
||||
- **服务治理**：Spring Cloud Alibaba（Nacos + Sentinel + Seata）
|
||||
- **消息队列**：RabbitMQ（业务消息）+ Kafka（日志/流数据）
|
||||
- **区块链**：⚠️ 待确认平台（需政府认可，优先考虑已在民政系统使用的公链）
|
||||
- **国密**：BouncyCastle（Java国密库）/ GmSSL（C/Python国密库）
|
||||
- **FHIR Server**：HAPI FHIR（开源，Java）
|
||||
- **监控**：Prometheus + Grafana + SkyWalking + ELK
|
||||
|
||||
---
|
||||
|
||||
## 6. 需新增业务能力
|
||||
|
||||
1. **DevOps流水线**：CI/CD自动化发布（Jenkins / GitLab CI + Helm Chart部署）
|
||||
2. **灾备方案**：关键数据的异地双活或同城双备（医疗数据丢失不可接受）
|
||||
3. **等保三级合规**：系统安全等级保护三级认证（医疗信息系统要求）
|
||||
4. **国密TLS通信**：部分政府对接接口可能要求国密通信链路
|
||||
5. **接口标准文档**：OpenAPI 3.0规范维护，供对接方接入使用
|
||||
|
||||
---
|
||||
|
||||
## 7. 需新增数据模型（基础设施侧）
|
||||
|
||||
| 模型 | 关键字段 |
|
||||
| --------------------- | ---------------------------------------------------------------------------------- |
|
||||
| `blockchain_record` | id, biz_type, biz_id, data_hash(SM3), chain_tx_id, chain_time, verify_status |
|
||||
| `api_call_log` | id, gateway_id, path, method, client_ip, user_id, status_code, latency_ms, ts |
|
||||
| `encryption_key_meta` | id, key_type(SM2/SM4), key_version, created_at, expire_at, status, managed_by_kms |
|
||||
| `fhir_resource_log` | id, resource_type, resource_id, operation, requestor, source_system, created_at |
|
||||
| `service_health` | id, service_name, instance_id, status, cpu_pct, mem_pct, latency_p99, check_at |
|
||||
| `alert_rule` | id, metric_name, condition, threshold, severity, notify_channels(JSONB), is_active |
|
||||
|
||||
---
|
||||
|
||||
## 8. 需新增技术栈 / 第三方能力 / 中间件
|
||||
|
||||
| 类别 | 技术选型 | 用途 |
|
||||
| ----------- | ------------------------------------- | ------------------- |
|
||||
| 容器编排 | Kubernetes（云托管） | 服务部署与弹性伸缩 |
|
||||
| API网关 | Kong / APISIX（开源） | 统一鉴权/限流/路由 |
|
||||
| 服务注册 | Nacos | 微服务注册与配置 |
|
||||
| 熔断限流 | Sentinel | 流量控制与熔断 |
|
||||
| 消息队列 | RabbitMQ + Kafka | 业务解耦 + 日志流 |
|
||||
| 链路追踪 | SkyWalking | 分布式链路追踪 |
|
||||
| 日志管理 | ELK Stack | 日志采集与查询 |
|
||||
| 监控 | Prometheus + Grafana | 指标监控与可视化 |
|
||||
| FHIR服务 | HAPI FHIR（开源） | HL7 FHIR R4标准适配 |
|
||||
| 国密加密 | BouncyCastle / GmSSL | SM2/SM3/SM4加密 |
|
||||
| KMS密钥管理 | 阿里云KMS / 腾讯云KMS | 密钥安全管理 |
|
||||
| 区块链 | ⚠️ 待确认（蚂蚁链/腾讯链/百度超级链） | 关键数据存证 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 外部系统对接关系
|
||||
|
||||
| 对接系统 | 方向 | 内容 |
|
||||
| ---------------- | ------------------------- | ------------------------------------ |
|
||||
| 全部27个业务系统 | 依赖 | API网关/消息队列/国密加密/区块链存证 |
|
||||
| 志愿者管理（12） | 调用区块链存证 | 时间银行积分存证 |
|
||||
| 长护险（18） | 调用区块链存证 | 服务凭证存证 |
|
||||
| 政府审批（04） | 调用区块链存证 + 电子签章 | 审批结果存证 |
|
||||
| 外部HIS/LIS | 依赖FHIR适配层 | 医疗数据互联互通 |
|
||||
| 运营监控人员 | 使用监控平台 | 系统健康状态监控 |
|
||||
| 等保测评机构 | 外部审查 | 等保三级合规评测 |
|
||||
|
||||
---
|
||||
|
||||
## 10. 风险与边界
|
||||
|
||||
| 风险 | 说明 | 应对 |
|
||||
| ------------------------------ | ------------------------------------------- | ------------------------------------------------------------ |
|
||||
| 技术复杂度高 | 微服务+区块链+国密+FHIR并行建设复杂度极高 | 分期建设，P0阶段先建API网关+微服务治理，其他逐步扩展 |
|
||||
| 区块链平台选择 | 国内区块链平台众多，政府认可度不同 | 与政府监管部门确认认可的区块链平台后再选型 |
|
||||
| 国密TLS兼容 | 国密TLS需要专用客户端支持，兼容性有限 | 非强制要求时用标准TLS，政府接口按要求提供国密通道 |
|
||||
| FHIR标准复杂 | FHIR资源模型学习成本高，国内HIS适配程度不一 | 先完成Patient/Observation等核心资源，逐步扩展 |
|
||||
| 等保三级成本 | 等保三级测评和整改成本较高（数十万元+） | 提前规划等保要求，在系统设计阶段就满足技术要求，避免后期整改 |
|
||||
| 边界：技术中台只做通用技术能力 | 不在技术中台中实现任何业务逻辑 | 技术中台只提供协议/安全/治理/存证等通用技术服务 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 实施优先级与分期建议
|
||||
|
||||
**优先级：P2（分期建设，基础部分需在P0之前就绪）**
|
||||
|
||||
| 分期 | 内容 | 时间节点 |
|
||||
| ------------------------ | ---------------------------------------------------------- | ------------------ |
|
||||
| 前置建设（P0系统上线前） | Docker+K8s基础环境 + API网关 + Nacos + RabbitMQ + 基础监控 | 在P0系统开发前完成 |
|
||||
| 第一期 | 国密加密服务 + ELK日志 + SkyWalking链路追踪 | P0/P1系统建设期间 |
|
||||
| 第二期 | HAPI FHIR Server + 外部HIS对接 | P1系统建设期间 |
|
||||
| 第三期 | 区块链存证 + 等保三级合规建设 + 国密TLS | P2阶段按需推进 |
|
||||
|
||||
---
|
||||
|
||||
## 12. 结论
|
||||
|
||||
技术中台是整个医养平台的**技术底座**，其微服务治理、API网关、国密加密、HL7/FHIR协议、区块链存证等能力在 mall 中完全缺失，**必须独立建设**。
|
||||
|
||||
技术中台的建设应遵循"先基础后专业"的原则：优先完成API网关、微服务治理、容器化部署等通用基础设施（在P0业务系统之前就绪），再根据业务需求逐步引入HL7/FHIR医疗互联互通、国密加密和区块链存证等专业医疗技术能力。建议优先采用云托管服务（K8s/KMS/日志服务等）降低运维复杂度，让团队聚焦业务能力建设。
|
||||
Reference in New Issue
Block a user