2. 家庭健康数据模型设计

家庭健康管理平台的数据模型，决定了系统能否把“一个家庭里多个成员、多种健康信息、长期变化”组织成可查询、可追溯、可分析的结构。如果只是把每次测量结果堆在一张表里，短期能看，长期必然出现三个问题：分不清数据属于谁、分不清同一指标在不同时间的变化、分不清用药与指标之间的因果关系。因此，本节从实体划分、主键设计、时间维度、关系建模四个角度，说明如何为家庭成员档案、健康指标、体征数据、病史与用药记录建立结构化模型。

一、先划分实体：家庭、成员、记录三层

家庭健康数据的最小组织单位不是“人”，而是“家庭”。一个家庭可以有多个成员，成员之间可能存在照护关系（如子女为老人代录数据）。因此建议采用三层实体：

• 家庭（Family）：承载账号、套餐、设备归属和共享权限，是数据隔离的边界。
• 成员（Member）：属于某个家庭，拥有独立档案，是健康数据的主体。
• 健康记录（Record）：挂在成员之下，按类型分为体征、指标、病史、用药等。

这样划分后，所有查询都可以先定位家庭，再定位成员，最后按时间或类型取记录，避免跨家庭数据串扰。成员档案本身不是“一张大表”，而应拆成基础身份、身体特征、慢病标签、紧急联系人等可扩展字段，便于后续增加新的健康维度。

二、主键与时间：让每条数据可追溯

结构化建模的关键是主键设计。建议每个成员使用全局唯一 member_id，每条健康记录使用 record_id，并强制携带三个时间字段：

• measured_at：测量或事件实际发生时间，由设备或用户录入。
• recorded_at：数据写入平台的时间，用于审计和补录识别。
• source：数据来源，如设备自动上传、手动录入、医院导入。

区分“发生时间”和“写入时间”非常重要。例如老人早上 7:00 测血压，子女晚上 20:00 才补录，如果只存一个时间，趋势图会把这次血压错误地画在晚上。因此，趋势分析必须使用 measured_at，而数据质量核查使用 recorded_at。

三、健康指标与体征数据：定义与观测分离

健康指标和体征数据容易混在一起。建议把“指标定义”和“指标观测值”分开：

• 指标定义表：描述指标名称、单位、正常范围、数据类型，如收缩压（mmHg，90–139）、空腹血糖（mmol/L，3.9–6.1）。
• 体征观测表：存储某成员某时刻的具体数值，如 member_id=M001, metric=收缩压, value=132, measured_at=2025-03-10 07:12。

这种“定义—观测”分离的好处是：新增指标不需要改表结构，只需增加一行定义；同一成员可以按指标、按时间灵活聚合。对于血压这类成对出现的指标，可以用 group_id 把收缩压和舒张压绑定为一次测量，避免两条记录时间不一致导致配对错误。

四、病史与用药记录：用关系表表达因果

病史和用药不是孤立字段，而是与成员、时间、指标都有关联的事件。建议采用关系建模：

• 病史记录：成员、疾病名称、确诊时间、状态（确诊/康复/观察）、来源医院。
• 用药记录：成员、药品名称、剂量、频次、开始时间、结束时间、医嘱来源。
• 关联关系：用药记录可关联到具体病史，体征异常可关联到用药时间段，用于分析“服药后血压是否下降”。

例如，成员 M001 在 2025-03-01 确诊高血压，同日开始服用氨氯地平 5mg 每日一次。平台在 2025-03-10 记录到收缩压 132mmHg，就可以通过时间区间关联，判断该读数落在用药期内，而不是孤立地看一个数字。

五、建模落地时的三个判断点

第一，是否允许同一指标多条记录。体征数据天然是时间序列，必须允许多条，不能覆盖。第二，病史和用药是否需要版本。如果用户修改了确诊时间或剂量，应保留修改历史，至少记录 updated_at 和变更来源。第三，异常值如何标记。观测值写入时，可依据指标定义中的正常范围自动打上 abnormal_flag，但标记只是提示，不能替代医生判断。

六、一个可参考的字段清单

这套模型的核心思想是：成员是主体，指标是口径，观测是事实，病史和用药是背景与干预。四者通过 member_id 和时间字段连接，既能支持单次查看，也能支持长期趋势和用药效果分析。实际开发中，可先按上述字段建最小可用表，再根据设备类型和业务需要扩展，避免一开始就设计过度复杂的结构。