211 lines
11 KiB
Markdown
211 lines
11 KiB
Markdown
# 业务中台 模块规划
|
||
|
||
---
|
||
|
||
## 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系统都依赖），再随业务发展逐步将共性能力沉淀到中台，切忌一开始就追求完整中台架构导致项目延期。
|