diff --git a/25-业务中台-模块规划.md b/25-业务中台-模块规划.md new file mode 100644 index 0000000..e265bb4 --- /dev/null +++ b/25-业务中台-模块规划.md @@ -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系统都依赖），再随业务发展逐步将共性能力沉淀到中台，切忌一开始就追求完整中台架构导致项目延期。 diff --git a/26-数据中台-模块规划.md b/26-数据中台-模块规划.md new file mode 100644 index 0000000..b5a8ffa --- /dev/null +++ b/26-数据中台-模块规划.md @@ -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，在各业务系统积累足够数据后再逐步完善数仓分层和数据治理体系。优先使用云托管大数据服务降低运维负担，待数据量规模化后再评估自建集群的必要性。 diff --git a/27-技术中台-模块规划.md b/27-技术中台-模块规划.md new file mode 100644 index 0000000..da4523f --- /dev/null +++ b/27-技术中台-模块规划.md @@ -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/日志服务等）降低运维复杂度，让团队聚焦业务能力建设。 diff --git a/mall 文件夹现状分析报告 × 智慧医养需求契合度.md b/mall 文件夹现状分析报告 × 智慧医养需求契合度.md new file mode 100644 index 0000000..f7625bd --- /dev/null +++ b/mall 文件夹现状分析报告 × 智慧医养需求契合度.md @@ -0,0 +1,660 @@ +# mall 文件夹现状分析报告 × 智慧医养需求契合度 + +------ + +## 一、mall 文件夹现状总结 + +### 1.1 项目定位 + +[mall](vscode-file://vscode-app/d:/%E8%BD%AF%E4%BB%B6/Microsoft%20VS%20Code/cfbea10c5f/resources/app/out/vs/code/electron-browser/workbench/workbench.html) 是一个基于 uni-app（uvue/UTS）+ Supabase + PostgreSQL 构建的**多角色通用电商平台**，覆盖消费者、商家、配送员、客服、运营管理员五种角色，支持微信小程序、H5、Android/iOS 多端运行。 + +**项目英文描述原文**（manifest.json）：`A multi-role e-commerce application.` + +这一定位直接说明了它的性质：**通用电商，而非医养平台。** + +------ + +### 1.2 已有模块清单 + +| 模块 | 覆盖能力 | 代表文件/服务 | +| --------------- | ----------------------------------------------------- | --------------------------------------- | +| **用户体系** | 注册/登录/绑定手机/邮箱/OAuth/找密码/用户中心 | `pages/user/`，`authService.uts` | +| **商品管理** | 商品 CRUD、SKU/规格/标签/保障/评价/图片/搜索 | `productService.uts`，`product/` | +| **分类管理** | 多级分类 | `productCategoryService.uts` | +| **购物车** | 加购/勾选/计价 | `pages/main/cart.uvue` | +| **下单支付** | 微信支付/支付宝/钱包余额/收银台 | `checkout.uvue`, `payment.uvue` | +| **订单管理** | 全状态流转（待付/已付/发货/签收/完成/取消）/退款/售后 | `orderService.uts`，`orders.uvue` | +| **物流配送** | 自建配送员端（任务/轨迹/车辆/收入）/第三方快递查询 | `pages/mall/delivery/` | +| **营销** | 优惠券/满减/积分/会员等级/分销/红包/订阅 | `marketingService.uts` | +| **商家入驻** | 商家端完整（商品/订单/库存/财务/营销/装修） | `pages/mall/merchant/` | +| **客服/工单** | 聊天室/工单/投诉处理 | `kefuService.uts`, `ticket-detail.uvue` | +| **内容管理** | CMS 文章/内容页 | `cmsService.uts`, `articles.vue` | +| **数据分析** | 销售/用户/商品/配送/优惠券分析，自定义报表 | `pages/mall/analytics/`, 16个分析服务 | +| **系统管理** | RBAC 权限/系统配置/装修/用户分组与标签 | `systemConfigService.uts` | +| **推送通知** | Supabase Realtime + Express Push Server | `server/push-server.js` | +| **LLM/AI 入口** | 语音识别页面（仅入口页，无业务接入） | `pages/llm/asr.uvue` | +| **订阅/会员** | 订阅套餐/会员价格 | `subscription/` | + +------ + +### 1.3 mall 明确没有的能力 + +| 缺失能力 | 关键词 | 确认状态 | +| ------------------------------ | -------------------- | -------------------------------- | +| 老人档案 / 家属关系 / 健康档案 | elder / 老人 / 档案 | ❌ 不存在 | +| 护理记录 / 医嘱 / 电子病历 | nursing / EMR / 医嘱 | ❌ 不存在 | +| 评估量表（ADL/MMSE/Barthel） | 评估 / 量表 | ❌ 不存在 | +| 服务签到 / GPS 留痕 / 派单工单 | checkin / GPS / 派单 | ❌ 不存在 | +| 预约类服务订单（时间 + 人员） | appointment / 预约 | ❌ 不存在 | +| IoT 设备接入 / 实时体征数据 | IoT / 体征 / 传感器 | ❌ 不存在 | +| GIS 地图 / 轨迹 / 电子围栏 | 地图 / 轨迹 / 围栏 | ❌ 不存在 | +| 审批流引擎 / 多级审批 | 审批 / 流程 | ❌ 不存在 | +| 直播带货（实现） | live / 直播 | ❌ 仅在文档中提及需求，代码无实现 | +| 长护险结算 / 医保支付对接 | 长护险 / 医保 / DRG | ❌ 不存在 | +| 药房管理 / 处方流转 | 药房 / 处方 | ❌ 不存在 | +| 呼叫中心 / SOS | 呼叫 / SOS | ❌ 不存在 | +| 志愿者管理 / 时间银行 | 志愿 / 时间银行 | ❌ 不存在 | +| 政府监管大屏 / 数据可视化平台 | 监管 / 大屏 | ❌ 不存在 | +| AI 模型平台 / 智能诊断 | AI 模型 / 辅诊 | ❌ 不存在（仅有 ASR 入口页） | +| 慢性病管理（随访/用药记录） | 慢病 / 随访 | ❌ 不存在 | + +------ + +### 1.4 mall 当前适合承接的业务边界 + +**适合：** 标准 B2C/B2B 交易流程、商品型+服务型订单、商家入驻与结算、营销活动、客服工单、配送履约、基础数据分析。 + +**不适合：** 医疗数据系统、政府监管平台、IoT 实时接入、呼叫中心、AI 医疗诊断、审批流、慢病管理、护理管理、家庭床位管理、药房系统、长护险结算、数据中台。 + +------ + +## 二、文档需求与 mall 契合度矩阵 + +> 契合度等级：**A（高契合）/ B（中契合）/ C（低契合）/ D（不建议放入 mall 主体）** + +------ + +### 模块 1：医养商城（线上商城部分） + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 商品/服务管理、用户注册登录、搜索详情收藏、订单支付退款物流、营销活动、客服售后工单、商家入驻、财务结算、设备租赁、直播带货、私域营销 | +| **mall 当前对应能力** | 商品/SKU/分类/搜索/收藏/订单/支付/退款/物流/优惠券/积分/营销/商家入驻/财务结算/商家端/客服工单全部覆盖；直播模块**无代码实现**；设备租赁**无独立模块** | +| **契合度等级** | **A（高契合）** — 线上商城核心交易部分 | +| **已有可复用部分** | 全套商城交易链路、商家管理、营销、财务、客服 | +| **当前缺失部分** | 服务类预约订单（含时间/人员字段）、设备租赁专项模块（含 IoT 状态监控）、直播系统、适老化交互 | +| **需新增业务功能** | 服务预约时间选择、护工/服务人员分配、设备租赁押金流程、电子合同签署、适老化大字体模式 | +| **需新增数据模型** | 服务类订单扩展字段（service_time, assignee_id, location）、device_rental 表、contract 表 | +| **需新增前端能力** | 日历选时组件、大字体适老化皮肤、直播 SDK 集成页 | +| **需新增后端能力** | 电子合同服务对接、直播推流服务 | +| **需新增技术栈** | 直播：声网/腾讯云直播 SDK；电子签名：e签宝/法大大 | +| **是否继续放入 mall** | **是** — 这是 mall 最适合承接的核心场景 | +| **是否拆分成独立服务** | 直播模块可单独运营；设备租赁 IoT 状态监控部分建议对接独立 IoT 服务 | +| **风险说明** | 文档中把"老人入住/退住/医护/护理记录/药房/医嘱"也放在了"医养商城"章节下，这部分**概念上不属于商城范畴**，强行堆入 mall 会严重破坏架构边界 | + +------ + +### 模块 1（延伸）：医养商城中超出商城边界的部分 + +以下内容虽然在文档的"医养商城"章节内，但本质上是**医疗机构管理系统（HIS-like 功能）**，不是电商功能： + +| 功能 | 等级 | 原因 | +| ----------------------------------- | ----- | ------------------------------------ | +| 老人入住/外出/探视/退住登记 | **D** | 机构运营管理，属于 LIS/养老机构系统 | +| 医护管理（医生/护士/电子病历/医嘱） | **D** | 标准 EMR 功能，需独立医疗系统 | +| 智能监护中心（体征监测） | **D** | IoT 实时数据接入，需独立 IoT 平台 | +| 体质辨识（中医辨识） | **D** | 医疗专业系统，AI 大模型支撑 | +| 药房管理（发药/退药/库存） | **D** | 标准药剂科信息系统（PIS/药房 HIS） | +| 全科医生签约 / 医养服务计划 | **D** | 家庭医生管理系统，属于"健康管理"平台 | +| 评估管理 / 人事管理 | **D** | HR 系统 + 评估系统 | + +------ + +### 模块 2：长护险与居家服务管理 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 长护险申请/评估/派单/服务执行/GPS+照片+签字留痕/与人保系统结算对账、居家服务下单/支付/确认/评价、AI 健康监测/语音情感分析 | +| **mall 当前对应能力** | 居家服务下单/支付/评价有基础商城框架可复用；其余无能力 | +| **契合度等级** | **C（低契合）** | +| **已有可复用部分** | 服务类订单框架、支付/退款、评价体系 | +| **当前缺失部分** | 长护险申请表单、失能等级评估、GPS 定位签到、照片/视频上传、电子签字、服务过程留痕、与人保对账接口、IoT 健康监测、NLP 语音分析 | +| **需新增技术栈** | 长护险接口 SDK（人保/各省系统）、GPS/LBS 定位、电子签名 SDK、语音 NLP 服务（ASR+情感分析） | +| **是否继续放入 mall** | **部分是**：居家服务下单/支付/评价可复用 mall 框架，做为"服务类商品"扩展 | +| **是否拆分成独立服务** | **是**：长护险评估流程、与人保对账、GPS 签到工单、AI 健康监测，必须拆为独立的"居家护理管理子系统" | +| **风险说明** | 长护险结算涉及医保合规接口，技术复杂度极高，不能与商城共库 | + +------ + +### 模块 3：智慧康养居家养老管理系统 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 老人档案（12 类字段）、服务预约（地理围栏校验/人脸验证）、家庭医生签约、老年活动中心、智能呼叫（5 种触发）、分级响应（急救联动）、工作台调度 | +| **mall 当前对应能力** | 有基础订单/用户/地址框架；其余无 | +| **契合度等级** | **C（低契合）** | +| **已有可复用部分** | 用户账户体系（需扩展为老人/家属双角色）、地址管理（扩展为服务上门地址）、基础评价/投诉 | +| **当前缺失部分** | 老人全息档案、家庭医生签约、活动中心预约、IoT 呼叫接入、急救调度联动、分级响应引擎 | +| **是否继续放入 mall** | **部分是**：老人档案、活动预约可作为 mall 用户体系的医养扩展 | +| **是否拆分成独立服务** | **是**：智能呼叫/SOS/急救联动必须独立；IoT 设备接入必须独立 | +| **风险说明** | 急救响应涉及 120 系统联动，属于公共安全领域，法律责任边界需清晰 | + +------ + +### 模块 4：智慧康养服务商管理系统 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | B2G/B2B/B2C 多级服务体系、服务商档案/资质/人员/GPS 轨迹、考核/信用评分/星级评定、订单全程留痕（定位/生物识别/图片）、500+ IoT 设备状态监控 | +| **mall 当前对应能力** | 商家入驻/资质审核/订单管理/财务结算/评价有基础；人员 GPS 轨迹无；IoT 无；信用评分无 | +| **契合度等级** | **B（中契合）** | +| **已有可复用部分** | 商家入驻审核流程、商品/服务上架、订单管理、财务分账 | +| **当前缺失部分** | 服务人员 GPS 轨迹管理、服务过程双录（视频+定位）、信用分模型、星级评定算法、IoT 设备状态监控 | +| **需新增技术栈** | GPS 实时定位服务（高德/腾讯地图 SDK）、视频录制存储（OSS）、信用评分引擎（待建） | +| **是否继续放入 mall** | **是**：服务商入驻、订单、财务可以在 mall 商家体系上扩展 | +| **是否拆分成独立服务** | **IoT 500+ 设备监控**必须独立 | + +------ + +### 模块 5：智慧康养社区助餐可视化系统 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 老人信息申请/补贴资格、人脸识别消费/点餐、配送上门（冷链/GPS追踪）、助餐数据大屏、营养膳食管理、政府补贴审核 | +| **mall 当前对应能力** | 线上下单/支付/配送有基础；人脸识别无；营养膳食无；政府补贴流程无；大屏无 | +| **契合度等级** | **B（中契合）** | +| **已有可复用部分** | 商品（菜品）上下架、线上点餐下单、支付、配送追踪框架 | +| **当前缺失部分** | 人脸识别核销、补贴自动抵扣、营养分析、助餐补贴审核流程、可视化大屏 | +| **需新增技术栈** | 人脸识别 SDK（百度/阿里）、营养成分数据库 API | +| **是否继续放入 mall** | **是**：助餐可以作为"服务类商品+到店核销"的 mall 扩展版本 | +| **是否拆分成独立服务** | 可视化大屏监管部分应作为独立监管系统 | + +------ + +### 模块 6：家庭床位及适老化改造系统 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 在线申请/智能资格预审（ADL评分）、三方协议电子签约、适老化改造方案（AI识别/3D可视化）、施工进度追踪（GPS工牌）、智能硬件设备管理（QR+RFID）、监管反馈（资金追踪/违规预警） | +| **mall 当前对应能力** | 在线申请表单框架有；其他无 | +| **契合度等级** | **C（低契合）** | +| **已有可复用部分** | 线上申请流程、审核状态流转（可复用商家入驻审核框架） | +| **当前缺失部分** | ADL 评分、电子合同三方签署、AI 图像识别改造方案、施工人员 GPS 追踪、RFID 设备管理、资金流向追溯 | +| **是否继续放入 mall** | **部分是**：申请表单/审核状态/电子合同可在 mall 扩展 | +| **是否拆分成独立服务** | **是**：RFID 设备管理、施工 GPS、AI 改造方案为独立专项系统 | + +------ + +### 模块 7：慢性病管理 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 患者端（评估/随访/用药记录/病种管理）、移动医生端（筛查/随访计划/患者建档）、医院管理端（HIS 嵌入工作站/ADL 量表/AI 方案推荐） | +| **mall 当前对应能力** | **零** | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **原因** | 这是标准的临床慢病管理系统（CDM System），属于医疗信息系统，需对接 HIS、EMR、医保，架构完全不同于电商 | +| **是否拆分成独立服务** | **必须**：独立慢病管理平台 | +| **风险说明** | 涉及医疗数据合规（等级保护三级）、患者隐私保护、医嘱资质，不能与商城混合部署 | + +------ + +### 模块 8：中心药房 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 药库管理（药品字典/采购/库存/供应商）、门诊/住院药房管理、医养商城药房（处方流转/药品配送）、药品追溯码、省阳采平台对接、共享库存、耗材供应链 | +| **mall 当前对应能力** | 商品管理框架（可映射药品 SKU）；处方流转/省平台对接/追溯码无 | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **原因** | 药品销售涉及《药品管理法》合规要求、处方药电子处方流转（需对接互联网医院/医保结算系统）、药品追溯码（国家监管码），属于高度合规的专项系统 | +| **是否拆分成独立服务** | **必须**：独立中心药房系统 + 互联网医院对接 | +| **风险说明** | 处方药电商资质、药品经营许可、互联网医院资质，缺一不可，技术门槛极高 | + +------ + +### 模块 9：人工智能服务 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 基于 DeepSeek 等大模型的智能推荐（诊断/用药/手术/检验）、医疗审核、知识图谱检索、区域辅诊监测 | +| **mall 当前对应能力** | ASR（语音识别）入口页一个；无任何 AI 业务能力 | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **是否拆分成独立服务** | **必须**：独立 AI 医疗服务平台（需 GPU 算力、向量数据库、医疗大模型微调） | + +------ + +### 模块 10：全生命周期监测平台 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 蓝牙定位基站（厘米级）、智能手环（多生命体征）、边缘 AI 摄像头（跌倒/行为识别）、全院 IoT、自动派单调度、家属互动、数据分析 | +| **mall 当前对应能力** | **零** | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **是否拆分成独立服务** | **必须**：独立 IoT 实时监测平台（需 MQTT/边缘计算/时序数据库） | + +------ + +### 模块 11：运营管理系统 + +| 字段 | 内容 | +| --------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 权限中枢（RBAC+ABAC）、服务生命周期管理、DRG 成本核算、多方分账、安全审计、运营驾驶舱、处方药械直通车、健康商城运营（含直播、积分、拼团）、适老化购物助手 | +| **mall 当前对应能力** | RBAC 权限/多方分账/优惠券/积分/拼团/运营分析有基础；DRG/处方流转/安全审计/直播无 | +| **契合度等级** | **B（中契合）** — 商城运营部分 | +| **已有可复用部分** | 运营数据分析、多方财务结算、营销工具箱（优惠券/积分/拼团）、客服体系 | +| **当前缺失部分** | DRG 成本核算、处方药械对接、安全审计（医疗合规）、适老化购物助手、多级机构审批 | +| **需新增技术栈** | 适老化 UI 组件库、医疗法规合规检查规则引擎 | +| **是否继续放入 mall** | **是**：商城运营功能可以，医疗合规/DRG 必须独立 | + +------ + +### 模块 12：业务中台 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 统一身份认证（电子健康码）、多角色权限（老人/家属/医护/机构）、服务门户管理（微信/APP/Web）、分级诊疗调度引擎、医养服务订单管理、DRG/DIP 规则库、异常预警处置、绩效考核、商保支付结算网关 | +| **mall 当前对应能力** | 服务门户多端接入（uni-app 已覆盖）；用户体系/订单管理有基础；其他无 | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **是否拆分成独立服务** | **必须**：业务中台是独立的平台层，需单独建设 | + +------ + +### 模块 13：数据中台 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | Hadoop/Spark 数据湖、HIS/LIS/PACS 对接、数据治理平台（200+标准）、医疗知识图谱（ICD-10/SNOMED CT）、AI 大模型平台（DeepSeek 微调）、360 患者健康画像 | +| **mall 当前对应能力** | **零** | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **是否拆分成独立服务** | **必须**：需要独立大数据基础设施（Hadoop/Spark 集群、向量数据库、GPU 算力） | + +------ + +### 模块 14：技术中台 + +| 字段 | 内容 | +| ---------------------- | ------------------------------------------------------------ | +| **文档要求概述** | 微服务架构、HL7/FHIR 协议、API 网关、消息队列、区块链存证、国密加密 | +| **mall 当前对应能力** | Supabase + RPC + RLS（单体应用模式）；无微服务/HL7/FHIR/区块链 | +| **契合度等级** | **D（不建议放入 mall 主体）** | +| **是否拆分成独立服务** | **必须**：技术中台是独立基础设施层 | + +------ + +### 模块 15：其他超出商城边界的系统 + +| 系统名 | 等级 | 原因 | +| ------------------------- | ------ | ---------------------------------- | +| 政府监管系统 / 数据驾驶舱 | D | 政务平台，需对接民政/卫健/公安数据 | +| 智慧医养数据库系统 | D | 全域医疗数据库，需等保三级 | +| 定期巡访系统 | D | 移动政务应用，GPS+签到+照片上传 | +| 审批业务系统 | D | 政务审批引擎，多级多部门会签 | +| 呼叫中心系统 | D | IVR/软交换/NLP，独立专项系统 | +| 评估系统 | D | ADL/MMSE 量表，专项医养评估工具 | +| 健康管理系统 | D | 电子病历/健康档案/IoT，医疗平台 | +| 安全系统 | D | IoT 传感器/视频/GPS，独立平台 | +| 志愿者管理系统 | D | 独立社区管理平台 | +| 短信平台系统 | C→独立 | 可对接第三方短信 SDK，但需独立服务 | +| 智能物联网管理系统 | D | IoT 设备接入，独立平台 | +| 医保 DIP 智能控费 | D | 医保专项系统，极高合规要求 | + +------ + +## 三、医养商城与 mall 的重点对比 + +### 3.1 高度契合的部分（mall 已覆盖） + +| 医养商城需求 | mall 对应能力 | 评估 | +| --------------------------------- | ------------------------------------------------------ | ------------ | +| 商品管理、SKU、审核、上下架 | `productService.uts` + admin/product 模块 | ✅ 直接可用 | +| 服务管理-服务上架/更新维护 | 商品模块可以承载"服务类商品" | ✅ 少量扩展 | +| 用户注册（手机/邮箱/微信/支付宝） | `pages/user/` 已实现 | ✅ 直接可用 | +| 搜索、详情、收藏、关注商家 | `search.uvue`、`favorites.uvue`、`followed-shops.uvue` | ✅ 直接可用 | +| 订单生成/支付/状态管理/物流 | 全订单链路已实现 | ✅ 直接可用 | +| 医保/微信/支付宝支付 | 支付宝/微信已有；医保支付**缺失** | ⚠️ 医保需新增 | +| 退款处理 | `apply-refund.uvue`、售后链路 | ✅ 直接可用 | +| 优惠券/积分/会员/活动/分销 | `marketingService.uts` 覆盖 | ✅ 直接可用 | +| 商家入驻/店铺管理/财务结算 | 商家端完整覆盖 | ✅ 直接可用 | +| 客服/工单/投诉处理 | `kefuService.uts`、客服模块 | ✅ 直接可用 | +| 物流配送/签收确认 | 配送端、物流查询 | ✅ 直接可用 | +| 数据统计/销售分析/用户行为 | analytics 模块 16 个服务 | ✅ 直接可用 | +| 消息通知 | 推送服务器 + Supabase Realtime | ✅ 可复用 | +| 线上商城积分兑换/礼品管理 | `points/index.uvue`、积分体系 | ✅ 直接可用 | +| 文章管理/广告管理/内容管理 | `cmsService.uts`、`articles.vue` | ✅ 直接可用 | + +### 3.2 需要扩展但可以在 mall 基础上做到的部分 + +| 医养商城需求 | 当前不足 | 扩展难度 | +| ---------------------------------- | -------------------------------------- | -------------------- | +| 服务类订单（含预约时间/服务人员） | 订单表缺少 service_time、assignee 字段 | 中 | +| 设备租赁模块（押金/租期/设备状态） | 无独立设备租赁流程 | 中 | +| 适老化交互（大字体/语音搜索） | 无适老化 UI 模式 | 中 | +| 直播功能 | 有需求文档，代码未实现 | 高（需集成直播 SDK） | +| 私域营销（社群运营/精准推送） | 基础推送有，私域社群无 | 中 | +| 生态商家对接（API 接入/联合营销） | 有商家体系，无生态 API 开放平台 | 中 | + +### 3.3 明确超出 mall 边界、不应堆入的部分 + +| 功能 | 原因 | +| ------------------------------- | ------------------------------------- | +| 老人入住/外出/退住/探视记录 | 养老机构 ERP 功能，属于 HIS-like 系统 | +| 医护管理/电子病历/医嘱/护理记录 | 完整 EMR 功能，医疗信息系统范畴 | +| 智能监护中心（体征实时监测） | IoT 实时数据流，需独立 IoT 平台 | +| 药房管理（处方/发药/库存） | 药剂科信息系统（PIS） | +| 体质辨识（中医 AI 辨证） | AI 医疗专项能力 | +| 全科医生签约/医养服务计划 | 家庭医生管理系统 | +| 长护险结算 | 医保合规接口，独立系统 | +| 医保/DRG/DIP 控费 | 医保专项系统 | + +------ + +## 四、总体判断 + +### 4.1 契合度总评 + +[mall](vscode-file://vscode-app/d:/%E8%BD%AF%E4%BB%B6/Microsoft%20VS%20Code/cfbea10c5f/resources/app/out/vs/code/electron-browser/workbench/workbench.html) 文件夹与《智慧医养.md》全文需求的整体关系是： + +> **局部契合**——在"医养商城（线上交易部分）"这一个模块上高度契合，但文档覆盖的 15 个以上独立系统中，mall 能直接承接的不超过 20%。 + +明确说明：**mall 是一个普通电商平台，不是医养平台**，两者在商业模型和技术架构上存在本质差异。如果将《智慧医养.md》的所有需求都堆进 mall，会导致架构崩溃、数据合规失控、系统维护灾难。 + +### 4.2 mall 更适合承接的范围 + +- ✅ **医养商城前台**：商品浏览/搜索/详情/收藏/购物车 +- ✅ **服务交易平台**：服务类商品下单、预约、评价 +- ✅ **服务商入驻与订单中心**：商家入驻/审核/商品管理/财务结算 +- ✅ **营销与会员运营**：优惠券/积分/会员等级/活动/分销 +- ✅ **配送与物流**：商品配送、助餐送餐、设备配送 +- ✅ **客服与售后**：工单/聊天/投诉/评价/回访 +- ✅ **助餐线上点餐**（需扩展人脸核销+补贴抵扣） +- ✅ **设备租赁商城**（需扩展租赁订单流程，IoT 监控独立） +- ✅ **直播带货**（需集成直播 SDK） +- ✅ **私域营销**（需扩展社群能力） + +### 4.3 哪些内容不应继续堆进 mall 主体 + +| 内容 | 应拆至 | +| ------------------------------------ | ------------------------------ | +| 医疗数据中台（HIS/EMR/患者档案） | 独立医疗数据平台 | +| DRG/DIP 医保控费 | 独立医保合规系统 | +| IoT 实时设备接入（手环/雷达/摄像头） | 独立 IoT 平台 | +| 呼叫中心（IVR/坐席/录音质检） | 独立呼叫中心系统 | +| GIS/轨迹/电子围栏 | 独立地图服务 / 引入地图 SDK | +| 审批流引擎（多级审批/政府审批） | 独立审批流平台（或低代码引擎） | +| 医疗 AI/知识图谱/辅诊平台 | 独立 AI 医疗平台 | +| 中心药房/电子处方/HIS 对接 | 独立药房信息系统 | +| 政府监管大屏/数据中台 | 独立政务数据平台 | +| 慢性病管理（随访/建档/HIS 嵌入） | 独立慢病管理平台 | +| 全生命周期监测（蓝牙基站/摄像头 AI） | 独立全场景监测平台 | +| 志愿者时间银行/社区管理 | 独立社区服务平台 | + +------ + +## 五、需要新增的业务功能 + +### 5.1 如果只是把 mall 扩展成"医养商城增强版" + +**新增业务功能：** + +1. 服务类订单扩展：预约时间选择 + 服务人员分配字段 +2. 设备租赁流程：押金/租期/归还/损坏评估 +3. 适老化交互模式：大字体皮肤、语音搜索、代客下单 +4. 医保结算支付通道（对接各省医保统筹支付） +5. 药品商品特殊管控（处方标记、购买限制） +6. 服务商入驻资质扩展（行业证书/服务能力评级） +7. 订单核销（到场/服务完成） + +**新增页面模块：** + +- 服务预约日历页 +- 设备租赁详情 + 押金管理页 +- 适老化首页（大字体版） +- 医保支付结果页 +- 服务商资质证书上传/审核页 + +**新增数据模型：** + +- `service_orders`（service_time, assignee_id, service_location, service_status） +- `device_rentals`（device_id, rent_start, rent_end, deposit, damage_status） +- `merchant_qualifications`（license_type, cert_url, expiry_date, audit_status） + +**新增库/技术栈：** + +- 医保支付 SDK（各省接口，待确认） +- 日历选时组件（uni-calendar 已有，需业务定制） +- 文件 OCR（营业执照/行业证书识别）：百度 OCR 或阿里云 OCR + +------ + +### 5.2 如果要对齐"医养商城 + 居家服务 + 服务商管理" + +**新增流程能力：** + +- 居家服务工单派单 → 服务员接单 → 出发 → 上门签到（GPS）→ 服务开始/结束留痕 → 评价 → 回访 +- 服务人员绑定档案（资质/技能标签/在线排班） +- 老人档案绑定（基本信息 + 紧急联系人 + 健康禁忌） +- 家属端：查看老人服务状态/评价服务/接收通知 + +**新增地图/定位/签到/留痕：** + +- 高德地图 / 腾讯地图 SDK 接入（服务人员 GPS 定位） +- 服务签到：GPS 打卡（距服务地址 ≤ 500m 验证） +- 照片上传：服务前后拍照存档（带 GPS 水印+时间戳） +- 电子签名：服务完成确认（客户签字确认） + +**新增支付与结算扩展：** + +- 长护险统筹支付通道（待对接保险系统） +- 补贴自动抵扣（对接民政补贴数据库，**待确认**） +- 多方分账（平台+服务商+服务员） + +**新增适老化交互：** + +- 超大字体模式 Toggle +- 语音输入搜索（调用系统语音识别） +- 一键呼叫家庭医生 / 紧急联系人 + +**新增设备租赁相关能力：** + +- 设备档案（型号/序列号/押金/租金规则） +- 租赁订单状态机（已下单/配送中/使用中/归还中/已结算） +- 设备状态查询页（待接 IoT 数据，可先 Mock 展示） + +**可能的接口和中间件：** + +- 高德/腾讯 Maps API（地图、路径规划、逆地理编码） +- 对象存储 OSS（服务留痕照片/视频存储） +- 电子签名服务（e签宝/法大大 API） +- 短信服务（阿里云短信/腾讯云短信，用于服务提醒、工单通知） + +------ + +### 5.3 如果要逐步逼近整份文档的一期能力 + +**必须独立建设的子系统：** + +| 子系统 | 建设方式 | mall 的角色 | +| ---------------------------------------- | --------------------------------------------- | -------------------------- | +| 居家护理管理平台（工单/GPS/签到/长护险） | 独立 Node.js/Java 微服务 | 提供订单状态消费接口 | +| IoT 实时接入平台（手环/传感器/摄像头） | MQTT + 时序数据库（InfluxDB/TDengine） | 提供设备信息展示页面入口 | +| 呼叫中心系统（IVR/坐席/智能派单） | 第三方云呼叫中心（如阿里云呼叫中心 CCC） | 工单状态同步 | +| 政府监管大屏 | 独立 Web（Vue + ECharts/D3.js）+ 数据汇聚层 | 提供商城侧运营数据 API | +| 审批流引擎 | 第三方低代码引擎（如钉钉/飞书审批）或独立建设 | 审批结果回调 | +| 慢病管理平台 | 连接 HIS 的独立系统 | 无关联 | +| 中心药房系统 | 连接 HIS/医保的独立药事系统 | 处方商品入口可在 mall | +| AI 医疗平台 | GPU 集群 + 大模型训练推理服务 | 商品推荐入口可调用 AI 服务 | +| 数据中台 | Hadoop/Spark + 数据湖 + 数据治理 | 提供商城运营数据 | + +**独立中台需求：** + +- 统一身份认证中心（电子健康码 + 多系统 SSO） +- 消息总线（各子系统事件解耦，如 Kafka/RocketMQ） +- API 网关（对外标准化接口，HL7/FHIR 适配） + +**重型基础设施：** + +- HL7/FHIR 协议适配层 +- 国密 SM4 加密存储（医疗数据合规） +- 区块链存证（服务记录不可篡改） +- 分布式存储（HDFS/OSS） +- GPU 算力集群（AI 模型训练） + +------ + +## 六、需要新增的库 / 技术栈 / 基础设施 + +### 必需新增 + +| 名称 | 用途 | 解决问题 | 层级 | 是否加入 mall | +| --------------------------------- | --------------------------------- | ------------------ | -------- | ------------------------ | +| **高德/腾讯地图 SDK** | 服务人员 GPS 定位、签到、路径规划 | 居家服务 GPS 留痕 | 前端 | **是**（加入 mall） | +| **阿里云/腾讯云 OSS** | 服务留痕照片/视频、营业执照、证书 | 大文件存储、CDN | 基础设施 | **是**（加入 mall） | +| **短信服务 SDK**（阿里云/腾讯云） | 服务提醒、工单通知、验证码、预警 | 通知闭环 | 中间件 | **是**（加入 mall） | +| **电子签名 SDK**（e签宝/法大大） | 服务完成确认、入驻协议、租赁合同 | 合规存证 | 后端 | **是**（加入 mall） | +| **OCR 识别**（百度/阿里云） | 营业执照、行业资质证书识别 | 商家资质审核自动化 | 后端 | **是**（加入 mall） | +| **Redis** | 会话缓存、工单队列、防重提交 | 性能与幂等控制 | 中间件 | **是**（加入 mall 后端） | + +### 建议新增 + +| 名称 | 用途 | 解决问题 | 层级 | 是否加入 mall | +| --------------------------------------- | -------------------------- | ------------------ | ------------ | ------------------------ | +| **直播 SDK**（声网 Agora / 腾讯云直播） | 直播带货、医生直播问诊 | 直播能力 | 前端/后端 | **是**（加入 mall） | +| **日历预约组件**（业务定制） | 服务预约时间选择 | 服务类订单时间管理 | 前端 | **是**（加入 mall） | +| **工单引擎**（轻量级自建） | 服务工单派单/流转/追踪 | 服务全流程管控 | 后端独立服务 | **否**（独立工单微服务） | +| **人脸识别 SDK**（百度/阿里） | 助餐核销、服务人员身份验证 | 合规认证 | 前端/后端 | **是**（加入 mall） | +| **消息队列**（RabbitMQ/阿里云 MQ） | 订单事件异步处理、通知解耦 | 高并发与系统解耦 | 中间件 | **否**（独立基础设施） | +| **API 网关**（Kong/阿里云 APIG） | 各子系统统一 API 管理 | 服务治理 | 基础设施 | **否**（独立建设） | + +### 可选新增（首期暂缓，后期升级建议） + +| 名称 | 用途 | 层级 | 是否加入 mall | +| --------------------------- | ------------------ | -------- | ----------------------- | +| MQTT Broker（如 EMQX） | IoT 设备实时接入 | 基础设施 | **否**（独立 IoT 平台） | +| InfluxDB / TDengine | 时序体征数据存储 | 数据库 | **否**（独立平台） | +| Hadoop/Spark | 数据湖建设 | 基础设施 | **否**（独立数据中台） | +| 区块链存证 | 服务记录不可篡改 | 中间件 | **否**（独立可信中台） | +| HL7/FHIR 适配层 | 医疗数据互操作 | 中间件 | **否**（独立中台） | +| 向量数据库（Milvus/Qdrant） | AI 知识检索 | 基础设施 | **否**（独立 AI 平台） | +| DeepSeek / 医疗大模型 | 辅诊/推荐/知识检索 | AI 平台 | **否**（独立 AI 平台） | + +------ + +## 七、建议拆分为独立服务的部分 + +- 智慧医养整体架构建议 + │ + ├── 【A: 继续在 mall 扩展】医养商城（主前台） + │ ├── 线上交易（商品/服务/设备租赁） + │ ├── 商家入驻与管理 + │ ├── 订单/支付/物流/售后 + │ ├── 营销（优惠券/积分/会员/直播/私域） + │ └── 助餐点餐（人脸核销+补贴抵扣扩展） + │ + ├── 【B: mall 旁边新增微服务】居家服务管理子系统 + │ ├── 工单派单/GPS签到/留痕 + │ ├── 服务人员档案与调度 + │ ├── 长护险结算对接 + │ └── （与 mall 通过 API 联动） + │ + ├── 【C: 独立建设】IoT 实时监测平台 + │ ├── MQTT 设备接入（手环/传感器） + │ ├── 时序数据存储 + │ ├── 告警引擎 + │ └── （mall 提供设备租赁商城入口，监测数据由此平台提供） + │ + ├── 【D: 独立建设】呼叫中心系统 + │ └── （与 mall 工单系统联动） + │ + ├── 【E: 独立建设】政府监管大屏平台 + │ └── （从 mall 和各子系统拉取运营数据） + │ + ├── 【F: 独立建设 or 采购】慢病管理平台 + │ └── （连接 HIS，与 mall 药品商城联动） + │ + ├── 【G: 独立建设 or 采购】中心药房系统 + │ └── （处方流转后可在 mall 药品专区展示/下单） + │ + ├── 【H: 独立建设】AI 医疗服务平台 + │ └── （提供 API 给 mall 商品推荐/健康知识） + │ + ├── 【I: 独立建设】数据中台 + │ └── （汇聚 mall + IoT + 医疗 + 政务数据） + │ + └── 【J: 独立建设或购买】审批流引擎 / 业务中台 + └── （mall 消费审批结果回调） + +------ + +## 八、分阶段实施建议（P0 / P1 / P2） + +### P0：医养商城核心版（基于 mall 直接扩展，0-3 个月） + +> 目标：上线一个真正可用的医养电商平台，复用 mall 80% 的现有能力。 + +**优先实现：** + +1. 服务类商品订单扩展（预约时间 + 服务人员字段） +2. 设备租赁商品模块（押金流程 + 租期管理） +3. 服务商/医疗机构资质入驻（扩展现有商家入驻：行业证书 OCR + 二级资质审核） +4. 适老化 UI 大字体皮肤模式 +5. 短信通知集成（订单提醒/服务提醒/工单通知） +6. 对象存储 OSS 接入（证书照片/服务留痕照片存储） +7. 修复安全风险：移除前端 service_role key，建立后端 API 中间层 + +**可直接复用 mall 现有能力（零改造）：** +商品/SKU/分类/搜索/收藏/下单/支付/退款/优惠券/积分/商家财务/运营数据分析/客服聊天/消息通知 + +### P1：居家服务 + 服务商管理版（新增工单子系统，3-6 个月） + +> 目标：实现居家服务全流程（下单→派单→GPS签到→留痕→评价→结算）。 + +**新增建设：** + +1. 居家服务工单微服务（独立，与 mall 联动） +2. 高德/腾讯地图 SDK（服务人员定位/路径/签到） +3. 照片+签名留痕上传（OSS + 水印） +4. 服务人员档案管理（技能标签/排班/绩效） +5. 电子签名对接（服务合同/完成确认） +6. 助餐系统扩展（人脸识别核销 + 补贴自动抵扣） +7. 初版家属端（查看服务状态/接收通知） + +### P2：平台生态化（独立系统对接 + 数据汇聚，6-12 个月） + +> 目标：打通 IoT、呼叫中心、政府监管，形成完整医养生态入口。 + +**建设：** + +1. IoT 设备接入平台（MQTT + 时序数据库，独立建设） +2. 呼叫中心系统对接（购买/集成云呼叫中心） +3. 政府监管大屏（独立 Web 应用） +4. 直播带货功能（集成声网/腾讯云直播 SDK） +5. 审批流引擎（采购低代码平台或独立建设） +6. 慢病管理/中心药房（外采或独立建设，与 mall 处方商品联动） +7. 数据中台基础建设（从 PostgreSQL 向外汇聚） + +------ + +## 九、风险与注意事项 + +| 风险项 | 严重程度 | 说明 | +| ----------------------------- | -------- | ------------------------------------------------------------ | +| **前端持有 service_role key** | 🔴 严重 | `BACKEND_MIGRATION_PLAN.md` 已说明此问题，P0 必须修复，否则整个数据库无安全边界 | +| **医疗数据合规风险** | 🔴 严重 | 老人健康档案、体征数据涉及《个人信息保护法》《数据安全法》，必须单独等级保护，不能与商城共库 | +| **"医养商城"功能边界误判** | 🔴 严重 | 文档中把 EMR/护理记录/医嘱/药房都写进了"医养商城"章节，但这些是 HIS 功能，不是商城功能，强行实现会造成架构灾难 | +| **长护险/医保接口合规** | 🔴 严重 | 需要有医疗机构资质才能对接医保结算，不是纯技术问题 | +| **IoT 实时延迟要求** | 🟡 中等 | 文档要求告警响应 ≤15 秒、写入延迟 ≤30 秒，Supabase 不适合作为 IoT 数据实时入库层 | +| **文档描述功能体量远超一期** | 🟡 中等 | 文档列出了 400+ 功能点，完整实现需 3-5 年，必须明确 P0 边界 | +| **Supabase 单点依赖** | 🟡 中等 | 目前整个 mall 强依赖 Supabase，随着医养业务复杂化，RLS/RPC 的复杂度会指数级上升 | +| **uni-app 跨端限制** | 🟡 中等 | 部分医养硬件对接（NFC/蓝牙/RFID）在 H5 环境下有限制，App 端需要原生插件 | +| **OCR/人脸识别数据合规** | 🟡 中等 | 人脸数据属于生物识别个人信息，需单独授权同意机制 | +| **处方药在线销售资质** | 🟡 中等 | 互联网药品销售需《互联网药品信息服务资格证书》，处方药须有电子处方，需提前规划合规路径 | +| **"待确认"项** | ⚪ 待确认 | 医保统筹支付接口、长护险保险公司接口、民政补贴数据库对接方案，需与政府方确认系统开放情况 | + +------ + +**分析完成。核心结论：mall 是一个成熟的通用电商底座，与《智慧医养.md》呈"局部契合"关系。建议将 mall 定位为"医养商城前台 + 服务交易平台"，P0 阶段直接在此基础上扩展服务类订单和设备租赁；医疗数据、IoT、呼叫中心、政府监管、AI、数据中台等系统必须独立建设，医养平台最终是一个以 mall 为商业交易前台、以多个专项子系统为支撑的分布式架构体系。** + +- ​ +- ​ +- ​ +- ​ +- ​ \ No newline at end of file