1. 课程导入与架构总览

数字健康管理平台并不是一个“把健康数据搬到线上”的简单系统，而是一套围绕人、健康数据、服务流程与医疗资源构建的工程化基础设施。它要解决的核心问题是：如何让分散在可穿戴设备、体检机构、医院信息系统、用户自述与随访记录中的健康信息，被安全、连续、可解释地组织起来，并转化为可执行、可追踪、可评估的健康管理服务。

从业务边界看，数字健康管理平台通常覆盖“监测—评估—干预—随访—再评估”的闭环，但它不等于医院核心诊疗系统（HIS/EMR），也不等于单纯的健康科普 App。它的典型边界是：承接来自院内系统的诊断与检验结果，汇聚院外设备与用户行为数据，输出风险分层、干预建议、随访计划与效果指标；涉及诊断与处方时，必须回到具备资质的医疗机构与执业人员。明确这条边界，是后续架构设计不越权、不失控的前提。

平台的核心价值可以归纳为四点：连续性（把碎片化记录串成时间序列）、可解释性（每个风险结论都能回溯到数据与规则）、可协同性（医生、健康管理师、用户、家属在同一数据视图下协作）、可度量性（干预是否有效，用指标而非感觉判断）。这四点直接决定了架构中必须存在统一数据模型、规则引擎、权限体系与指标服务。

典型用户角色决定了功能与权限的切分方式。用户本人关注自我记录与提醒；家属或照护者关注异常告警与代管；健康管理师负责随访执行与方案调整；医生关注风险分层与临床决策支持；平台运营与质控人员关注数据质量、服务履约与合规审计；系统管理员关注接入、容量与安全。角色不同，看到的数据粒度、可执行动作与审计要求都不同，因此架构上必须把“身份—角色—数据范围—操作”四者绑定。

整体架构通常分为五层，自下而上依次为：接入与采集层（设备、App、机构接口、消息网关）、数据与存储层（主数据、时序数据、文档、指标库）、平台服务层（用户、权限、规则、工作流、通知、指标计算）、业务应用层（风险评估、干预方案、随访管理、健康档案、运营看板）、渠道与交互层（App、小程序、Web 工作台、开放 API）。层与层之间通过明确定义的接口通信，避免业务逻辑直接耦合到采集端。

工程化目标决定了这套架构“好不好用、能不能长期运行”。第一是数据一致性：同一指标在不同来源必须有统一编码、单位与时间基准，例如血压统一为 mmHg、时间统一为带时区的 ISO 8601，否则后续风险计算会失真。第二是可扩展性：新增一类设备或一家机构，应通过适配器接入，而不是改动核心业务代码。第三是安全与合规：健康数据属于敏感个人信息，传输加密、存储脱敏、最小权限与全量审计是硬性要求。第四是可观测性：采集延迟、规则命中率、随访完成率等指标要能被监控，否则平台“看起来在跑”，实际服务已经断链。

为了把上述目标落到可执行层面，下面给出一份架构分层职责与关键约束示例表，可作为后续章节设计评审的基线。表中参数为教学示例，实际项目需按业务规模与合规要求调整。