------------/mall 文件夹现状分析报告 × 智慧医养需求契合度.md

mall 文件夹现状分析报告 × 智慧医养需求契合度

---

一、mall 文件夹现状总结

1.1 项目定位

mall 是一个基于 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 文件夹与《智慧医养.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 为商业交易前台、以多个专项子系统为支撑的分布式架构体系。

• ​
• ​
• ​
• ​
• ​