从苹果健康数据到临床叙事：用Python和Gemini构建AI驱动报告

引言

在近期的技术会议上，一个话题引起了我的注意：每年都有更多健康设备、传感器和应用涌现。智能手表追踪心率，智能秤测量身体数据，血糖仪记录血糖水平，各类应用帮助用户追踪睡眠或营养状况。如今，我们能收集到的关于自身身体的信息量已十分庞大。

本文的灵感来源于我与父亲Herminio ❤️的日常互动。每次就医时，他都会打开Apple Health应用，向医生展示心率变化、身体活动、睡眠时长及其他记录的指标。

看着这一幕，我不断问自己同一个问题：我们真的充分利用了这些信息吗？

在就诊时展示图表或许有用，但如果能自动处理、总结数据并将其转化为结构化的健康报告，这些数据将发挥更大价值。

因此，在本项目中，我使用Gemini将预先计算的指标转化为清晰有序的摘要。LLM并不分析所有原始记录或执行主要计算。数据处理流程负责计算指标并生成可视化内容，而模型则作为构建报告叙述的辅助层。

目标并非创建医疗应用或取代专业判断，而是构建一个原型，展示如何将Apple Health导出数据、确定性数据处理、可视化与LLM相结合，生成自动化报告。

本项目使用三位患者的模拟数据开发，因此无需真实临床信息即可复现完整流程。

✨ 为何选择Gemini？

本项目使用LLM将已处理的指标转化为结构化叙述，便于医疗专业人员审阅。

我选择Gemini出于实际原因：

• 〰️ 我已熟悉其API，它能与Python轻松集成，且Google AI Studio便于测试和调整提示词。
• 〰️ 在文本生成任务中，它在速度、性能和成本之间取得了良好平衡。
• 〰️ 其免费套餐也使得无需初始成本即可复现此MVP。

在此案例中，我使用通用模型，因为所有计算均在Python中完成，之后才将数据发送至Gemini。模型仅将结果组织为可读文本。

对于需要直接分析临床文档或医学影像的项目，也可评估MedGemma等专业模型。MedGemma是一系列针对医疗任务调整的Google开源模型。但其实现、评估和验证不在本教程范围内。

2. HealthKit：数据背后的框架

尽管大多数用户只与Apple Health应用交互，但其背后的框架是HealthKit。Apple提供HealthKit，使开发者能安全访问设备上存储的健康信息。

HealthKit作为中央存储库，iPhone和Apple Watch在此存储健康和健身数据。在用户明确许可下，授权应用可通过单一API读写信息，避免每个应用维护独立数据库。

HealthKit目前支持数百种数据类型，涵盖健康和福祉的多个领域。下图展示了部分类别的简化分组，以更清晰地呈现可用信息。

此分类专为本文创建，基于公开的HealthKit文档。它并非Apple官方分类，应视为作者为便于说明而创建的总结性解读。

得益于这一架构，HealthKit能够：

• 收集和存储健康与健身信息。
• 分析和可视化这些数据随时间的变化。
• 在授权应用间共享信息，减少重复，创造新的用户体验。

HealthKit最有趣的设计决策之一是其庞大的预定义类和数据类型目录，用于标准化健康指标。

起初，这对开发者可能显得限制。然而，这实际上是平台的主要优势之一，因为它确保所有存储信息遵循一致的数据模型。这意味着心率、血糖或体重始终代表相同类型的信息，并使用相同单位，无论记录来自何种设备或应用。

这种标准化简化了应用开发，提高了应用间的互操作性，并有助于维护HealthKit中存储数据的一致性。

2.1 数据源

HealthKit的主要优势之一是其将多个来源的数据整合到单一存储库的能力。

最常见的来源包括：

• iPhone：通过传感器记录步数、行走距离、活动数据及其他指标。
• Apple Watch：提供心率、心电图（ECG）、血氧饱和度（SpO₂）、体温、睡眠数据、锻炼及心肺功能（VO₂ Max）等生理指标。
• 第三方应用：可添加营养、心理健康、水分摄入、用药、月经周期或运动训练相关信息。
• 连接的医疗设备和可穿戴设备：HealthKit支持低功耗蓝牙（BLE）健康设备和医疗数据配置文件。它还能与FHIR（快速医疗互操作性资源）配合使用，从而整合血糖仪、血压计等设备的数据，以及来自授权医疗机构的临床记录。

3. HL7 / FHIR兼容性

到目前为止，我们主要讨论了设备和应用生成的数据。然而，2018年Apple通过引入健康记录功能扩展了健康应用，使用户能从支持的医疗机构导入结构化临床信息。同年，Apple还通过HealthKit API向授权应用开放了这些记录的访问权限。

健康记录基于HL7 FHIR构建，FHIR代表快速医疗互操作性资源。FHIR是HL7 International开发的标准，用于在医疗机构、应用和电子健康记录系统之间以电子方式表示和交换健康信息。

FHIR将信息组织为模块化资源，如患者、观察、状况、程序、用药请求和免疫接种。每个资源代表一条特定的临床信息，可在系统间连接、查询和交换。尽管FHIR也可用于构建临床文档，但其架构不要求将整个患者记录作为一个大文档处理。

当从支持的机构下载记录时，HealthKit将每条记录表示为HKClinicalRecord对象，保留原始FHIR资源。授权应用可请求所需的临床记录类型，并将其内容作为FHIR JSON处理。但这些记录为只读，意味着应用无法创建新的HKClinicalRecord对象或修改现有对象。

访问任何HealthKit信息都需要用户同意，但临床记录因其敏感性有额外要求。应用必须启用临床健康记录功能，包含所需授权，解释为何需要该信息，并为每种要访问的记录类型请求权限。此功能的使用还需经过Apple的审核流程。

在HealthKit中，临床记录以只读的HKClinicalRecord对象表示，保留了原始的FHIR内容。访问这些数据需要明确的用户授权，并需遵守额外的隐私和平台要求。

这种架构使得整合来自不同来源的信息成为可能，同时将访问权限集中在用户同意和隐私保护上。

4. HealthKit：临床用例

大量生理数据的可用性，加上FHIR等互操作性标准，为研究和临床应用创造了众多机会。

这些数据的价值不仅来自单个测量值，更在于如何随时间分析它们。追踪心率、睡眠、活动能力或活动水平的变化，有助于识别模式、总结相关信息，并支持不同医疗场景下的患者监测。

下图展示了一些代表性用例，包括早期异常检测、远程患者监测、临床摘要生成以及用于研究的合成数据生成。

5. 技术、临床与监管考量

在运行本教程或使用本文提供的代码之前，了解其范围并考虑与隐私、数据质量以及在医疗保健环境中使用人工智能相关的若干限制非常重要。

5.1 隐私与数据保护

健康信息是最敏感的个人数据类别之一。根据国家和使用环境的不同，它可能受到美国HIPAA或欧盟GDPR等法规的约束。

尽管本文仅使用模拟数据，任何处理真实信息的实施都应包含适当的控制措施，包括：

• 用户同意
• 访问管理
• 数据最小化
• 匿名化或假名化
• 加密
• 安全存储与处理

5.2 消费级数据并非诊断

通过消费级设备收集的测量值可以为识别趋势和支持长期监测提供有用信息。

然而，这些记录本身并不代表医学诊断，也不应替代使用认证临床设备进行的测量。

5.3 数据质量与连续性

测量质量可能受到设备放置不当、电池电量低、同步失败、设备未使用时段、传感器或应用程序差异等因素的影响。

这些情况可能导致：

• 记录不完整
• 重复测量
• 异常值
• 信息缺失时段
• 单位或采样频率差异

因此，在生成任何分析之前，应对数据进行验证、清洗和标准化。同时，识别可用信息不足以支持可靠结论的时段也很重要。

5.4 大语言模型的使用与限制

在本项目中，大语言模型不诊断疾病或推荐治疗方案。其作用是将预先计算的指标转换为清晰、结构化的摘要，以便医疗专业人员更轻松地审阅。

任何生成的输出都应视为需要人工审阅的草稿。模型可能会遗漏信息、误解结果或生成不完全基于输入数据的陈述。

5.5 代码范围

本文提供的代码库应被理解为教育和实验性的最小可行产品。它旨在使用模拟数据演示通用处理流程。

它并非医疗产品、诊断工具或可直接用于临床环境的实施方案。

在将代码适配到真实用例之前，需要在以下方面进行额外验证：

• 安全性与访问控制
• 错误处理与可追溯性
• 数据质量与来源
• 结果的可重复性
• 模型响应的评估
• 适用标准与法规的合规性
• 合格专业人员的审查与批准

本项目的目标是展示一种可能的架构并探索其主要组件，而非提供生产就绪的临床解决方案。

6. 构建Apple Health报告流水线

在本教程中，我们将构建一个Python流水线，用于处理Apple Health XML导出文件并生成结构化的PDF报告。

该流水线将：

• 读取并标准化导出的健康记录
• 计算活动能力、心血管和睡眠指标
• 将结果与可配置的参考值进行比较
• 生成图表
• 使用Gemini创建结构化叙述
• 将所有内容整合为最终的PDF报告

生成的报告包含四个主要部分：

• 活动能力：每日步数、步行速度、稳定性、步态指标和热量消耗
• ❤️ 心血管：静息心率、心率变异性、血氧饱和度、最大摄氧量和恢复指标
• 睡眠：平均睡眠时长以及高于或低于配置参考值的夜晚数
• AI生成摘要：包含患者概况、活动能力、心血管、睡眠和整体评估部分的结构化叙述

下图展示了项目的完整流程：

该实现遵循模块化架构，每个类负责流水线的一个阶段：

• HealthDataReader：读取并处理Apple Health导出文件
• HealthChartBuilder：生成可视化图表
• ✨ HealthSummaryGenerator：使用Gemini创建叙述
• HealthReportPDF：将指标、图表和生成的文本整合为最终报告

在接下来的部分中，我们将逐一回顾每个阶段。为保持文章重点突出，我将仅包含最相关的代码片段和设计决策。完整实现、配置文件、提示模板和模拟数据均可在项目代码库中找到。

6.1 前提条件

要跟随本教程，您需要：

• 在本地克隆项目代码库
• 一份Apple Health XML导出文件或代码库中包含的模拟文件之一
• 从Google AI Studio创建的Gemini API密钥
• 从项目requirements.txt文件安装的Python依赖项

您可以使用以下命令克隆代码库并安装依赖项：

RominaElenaMendezEscobar
/
apple-health-data

Python流水线，用于处理Apple Health XML导出文件、计算健康指标、生成可视化图表、使用Gemini创建结构化叙述，并基于模拟患者数据构建最终PDF报告。

从Apple Health数据到临床叙事：使用Python和Gemini构建AI驱动的报告

Apple Health报告流水线（Python + Gemini）

一个模块化的Python流水线，用于处理Apple Health XML导出文件、计算健康指标、生成可视化图表、使用Gemini创建AI辅助叙述，并构建结构化的PDF报告。

此代码库是一个基于模拟数据的教育性最小可行产品。它并非医疗设备、诊断工具或生产就绪的临床解决方案。

概述

该流水线：

• 读取并标准化Apple Health XML记录
• 计算活动能力、心血管和睡眠指标
• 将结果与可配置的参考值进行比较
• 使用Matplotlib生成图表
• 使用Gemini创建结构化叙述
• 将指标、图表和文本整合为PDF报告

HealthKit：数据背后的框架

HealthKit是Apple用于存储和共享由iPhone、Apple Watch、第三方应用及兼容设备收集的健康与健身信息的框架。

它提供了用于测量指标（如……）的标准化数据类型。

在GitHub上查看

✨Gemini API密钥

您可以从Google AI Studio创建API密钥。

创建完成后，在项目根目录添加一个 .env 文件：

gemini_api_key=YOUR_CREDENTIAL

6.2 数据源

Apple Health 允许用户将健康数据导出为包含 XML 文档的 ZIP 文件。

可通过健康应用生成导出文件：

• 在 iPhone 上打开健康应用。
• 点击个人资料图标。
• 选择"导出所有健康数据"。
• 确认导出操作。
• 解压生成的 ZIP 文件。

本教程使用该流程生成的 export.xml 结构。为避免暴露真实健康信息，代码仓库包含三个模拟患者文件：

• alex_28m.xml：28岁男性患者
• carlos_68m.xml：68岁男性患者
• maria_61f.xml：61岁女性患者

这些文件存储在 patients/ 文件夹中，可在不使用真实临床数据的情况下完整复现整个流程。

6.3 编排流程

整个项目由 main.py 文件协调，作为应用程序入口点。其职责不是直接处理数据，而是创建专用类并按正确顺序执行流程的每个阶段。

该文件还定义了待处理的患者列表。对于每位患者，包含 XML 文件路径和最终报告中显示的名称。文件采用显式声明方式以便于理解示例，虽然更通用的实现可以从文件夹中自动发现文件。

完整的 main.py 文件如下所示：

from healthChartBuilder import HealthChartBuilder
from healthDataReader import HealthDataReader
from healthReportPDF import HealthReportPDF
from healthSummaryGenerator import HealthSummaryGenerator
import utils
import os

if __name__ == "__main__":
   patients = [
       ("patients/alex_28m.xml",   "Alex Torres"),
       ("patients/maria_61f.xml",  "María González"),
       ("patients/carlos_68m.xml", "Carlos Mendez"),
   ]

   os.makedirs("reports", exist_ok=True)
   os.makedirs("charts",  exist_ok=True)
   os.makedirs("data",    exist_ok=True)

   env = utils.read_env()

   for xml_path, name in patients:
       print(f"
── {name} ──")
       prefix = name.lower().replace(' ', '_')

       # 步骤1：读取和计算
       reader = HealthDataReader(xml_path).load()

       # 步骤1.1：保存该患者的紧凑型LLM友好摘要
       reader.save(write_llm_summary=True, file_name=prefix)

       # 步骤2：生成图表
       builder = HealthChartBuilder(
           metrics    = reader.metrics,
           output_dir = "charts",
           prefix     = prefix,
       )
       charts = builder.build_all()

       # 步骤：使用Gemini生成叙述性摘要
       generator = HealthSummaryGenerator(
           json_path   = f"data/{prefix}_llm_summary.json",
           yml_path    = "config/params_health.yml",
           prompt_path = "prompt/prompt_summary.txt",
           api_key     = env["gemini_api_key"],
       ).load()
       llm_text = generator.generate()

       # 步骤3：构建PDF
       HealthReportPDF(
           metrics        = reader.metrics,
           charts         = charts,
           patient_name   = name,
           date_of_birth  = reader.date_of_birth,
           biological_sex = reader.biological_sex,
           start_date     = reader.df['start'].min(),
           end_date       = reader.df['start'].max(),
           out_path       = f"reports/{prefix}_report.pdf",
           llm_summary    = llm_text,
       ).build()

6.4 读取和处理 Apple Health 导出数据

HealthDataReader 类读取从 Apple Health 导出的 XML 文件，并将其转换为可用 Python 分析的结构。在此过程中，提取可用记录、标准化日期和数值、将分析限制在配置的时间段内，并计算流程后续阶段使用的指标。

该类接收 XML 文件路径，并可选择指定分析包含的月数：

reader = HealthDataReader( 
xml_path="patients/alex_28m.xml", months=6, 
).load()

load() 方法执行两个主要操作：

• _parse_xml() 读取文件、提取记录并转换为 Pandas DataFrame。
• _compute_metrics() 计算分析中使用的每日序列和聚合指标。

阈值配置

用于分类或比较指标的值并未硬编码在类中，而是从 config/params_health.yml 加载。

这种分离方式使得无需修改 Python 实现即可更新参考值：

threshold_steps_low:
  description: 步数红色区域阈值
  value: 3000
threshold_steps_mid:
  description: 步数橙色区域阈值
  value: 5000
threshold_steps_goal:
  description: 步数目标线
  value: 7000
threshold_speed_low:
  description: 步行速度临界低值
  value: 3.5
threshold_speed_goal:
  description: 步行速度参考值
  value: 4.5
threshold_steadiness:
  description: 步态稳定性警告值
  value: 0.60
threshold_spo2_low:
  description: SpO2临界阈值
  value: 95.0
threshold_spo2:
  description: SpO2最低参考值
  value: 96.0
threshold_sleep_min:
  description: 睡眠时长红色区域
  value: 5.0
threshold_sleep_mid:
  description: 睡眠时长橙色区域
  value: 6.0
threshold_sleep_goal:
  description: 睡眠时长目标
  value: 7.0
threshold_hrv:
  description: HRV最低参考值
  value: 25.0

这些参数影响项目的多个部分。例如，用于计算低于特定步数的天数、识别步行速度较低的时期、评估睡眠时长，以及定义后续图表和最终报告中使用的参考区域。

⚠️ 注意：仓库中包含的值仅用于演示，旨在支持模拟数据的示例。不应将其视为临床标准。在将代码适配到实际使用场景前，应由医疗专业人员根据人群、年龄组、临床背景和解决方案的具体目的，对阈值进行审查和验证。

指标选择

_compute_metrics() 方法定义处理哪些数据类型以及计算哪些指标。在当前实现中，指标主要分为三组：

• 活动能力与活动量：步数、步行速度、步长、步态稳定性、不对称性、活动能量和爬楼层数。
• ❤️ 心血管：静息心率、HRV、血氧饱和度、呼吸频率、VO₂ Max 和心率恢复。
• 睡眠：每日时长、平均睡眠时间以及低于或高于配置阈值的夜晚数。

每日序列根据记录类型使用总和或平均值计算：

steps = self._daily_sum("StepCount")
speed = self._daily_mean("WalkingSpeed")
hr = self._daily_mean("RestingHeartRate")
hrv = self._daily_mean("HeartRateVariabilitySDNN")
spo2 = self._daily_mean("OxygenSaturation")

⚠️ 注意：不仅阈值需要审查，还需确认类使用的统计方法是否适用于每个指标。例如，平均值可能受异常值影响。在生产环境中使用此方法前，可能需要评估中位数或百分位数等其他度量指标。

为LLM准备数据

除了完整的指标集外，该类还通过 to_llm_summary() 生成一个较小的 JSON 文件。

Python不会发送完整的时间序列，而是创建一种紧凑且确定性的表示形式，包含：

• 平均值和标准差；
• ↕️ 最小值和最大值；
• 分析期内的趋势；
• 最佳和最差的周平均值；
• 周变异性；
• ⏱️ 低于配置阈值的最长连续时段。

并非每个指标都包含所有这些字段，因为某些计算并不以相同方式适用于所有数据类型。这一决策有两个主要优势：

1. 减少发送给模型的数据量。Apple Health导出可能包含数千条记录。发送所有观测值会增加提示词大小、token使用量和执行成本，同时还会添加可能无助于最终摘要的重复信息。
2. 将计算保留在Python中。平均值、趋势、最小值和最大值、周统计数据和阈值连续时段均使用确定性代码预先计算。LLM接收固定且可验证的值，仅负责将其转化为自然语言摘要。

这种分离也使项目更易于维护。如果趋势计算发生变化或添加了新指标，可以在Python中完成更新，而无需改变语言模型的角色。

例如，模型会收到如下结构：

{
  "steps": {
    "mean": 9498.53,
    "std": 1728.37,
    "min": 5667.0,
    "max": 14201.0,
    "trend": "stable",
    "worst_week_mean": 8214.29,
    "best_week_mean": 10672.71,
    "weekly_volatility": 576.09,
    "worst_streak_below_threshold": 0
  }
}

6.5 生成临床图表

HealthChartBuilder类接收HealthDataReader计算出的指标，并生成后续包含在最终报告中的图表。

为了将展示逻辑与数据处理逻辑分离，该类使用两个配置文件：

• params_health.yml：定义每个图表中用于颜色区域和水平线的参考阈值。
• params_styles.yml：存储所有可视化中一致应用的调色板。

生成的图表

build_all()方法协调图表生成过程，并将每个可视化委托给独立的私有方法：

• 活动与移动能力 — _chart_steps()、_chart_mobility()和_chart_calories()：基于阈值颜色区域的每日步数、带参考线的步行速度，以及活动热量与基础热量。
• ❤️ 心血管 — _chart_hrv()和_chart_spo2()：带最小参考值的心率变异性，以及带临界、低和正常区域的血氧饱和度。
• 睡眠 — _chart_sleep()：基于阈值颜色区域显示的夜间睡眠时长。如果没有睡眠数据，图表会显示替代信息。

每个图表独立实现，因此可以在不影响流程其他部分的情况下进行修改或替换。

6.6 使用Gemini生成叙述性内容

HealthSummaryGenerator类接收HealthDataReader创建的摘要，并使用Gemini将其转化为结构化的自然语言文本。在此阶段，原始Apple Health记录不会发送给模型。相反，Gemini接收的是上一步已计算和汇总的指标。

为了构建提示词，该类使用三个输入文件：

• json_path：包含患者的紧凑摘要，包括先前计算的指标和统计数据。
• yml_path：指向params_health.yml，其中包含用于比较每个指标的阈值。
• prompt_path：包含提示词模板和模型必须遵循的指令。

load()方法读取这些文件并初始化Gemini客户端：

self.datos = utils.read_json_file(self.json_path)
self.yml = utils.read_yml_file(self.yml_path)
self.prompt = utils.read_txt_file(self.prompt_path)
self.client = genai.Client(api_key=self.api_key)

提示词结构

提示词模板定义了报告应如何生成。本文不包含完整提示词，其主要指令可总结如下：

• 患者背景：根据出生日期计算患者年龄，并考虑生物学性别和分析周期。
• 阈值比较：定义应使用params_health.yml中的哪个值来评估每个指标。
• 报告结构：要求包含患者概况、移动能力、心血管数据、睡眠和总体评估的固定章节。
• 趋势与连续性：要求模型考虑指标趋势、周变异性和低于配置阈值的连续时段。
• 限制：防止模型编造数据、使用不可用字段或对患者健康做出一般性判断。同时避免使用"健康"或"令人担忧"等主观术语。模型仅应报告每个值是高于、处于还是低于其对应阈值。

最后一点尤为重要，因为模型应描述可用值及其与配置阈值的关系，而不做出诊断或将摘要变成医疗建议。

构建与运行提示词

该类将提示词准备与模型调用分开：

• _build_prompt()将{datos}和{yml}占位符替换为实际的JSON数据和阈值配置。
• generate()将完整的提示词发送给Gemini并返回生成的文本。

prompt = self._build_prompt()

response = self.client.models.generate_content(
    model=self.model_id,
    contents=prompt,
    config=types.GenerateContentConfig(
        max_output_tokens=self.max_tokens,
        thinking_config=types.ThinkingConfig(
            thinking_budget=0
        ),
    ),
)

6.7 生成最终PDF报告

HealthReportPDF类结合前几个阶段产生的结果，使用ReportLab创建最终的PDF报告。

该类接收四个主要输入：

• 指标与KPI：直接从HealthDataReader生成的指标字典中获取。该类不重新计算主要统计数据，而是将其组织成KPI卡片、表格、警报和简短描述。
• 图表：接收HealthChartBuilder生成的图像路径，并将每个图表添加到相应的报告章节。
• ✨ Gemini摘要：接收HealthSummaryGenerator生成的叙述性内容，并将其作为独立章节包含。
• 配置：使用params_health.yml和params_styles.yml，应用与流程其余部分相同的阈值和视觉样式。

该类不计算平均值、趋势或周统计数据。这些值已由HealthDataReader生成。它仅执行针对配置阈值的简单比较，以决定表格应显示✓或⚠状态，以及是否应在报告中添加警报。

报告结构

生成的文档分为四个章节：

• ① 移动能力：步数、步行速度、稳定性、步态不对称性和活动量的KPI，以及相关图表和参考表格。
• ❤️ ② 心血管：静息心率、心率变异性、血氧饱和度、最大摄氧量和恢复指标。当Apple Watch数据不可用时，此章节会相应调整。
• ③ 睡眠：平均睡眠时长、低于最低阈值的夜晚数，以及达到配置目标的夜晚数。
• ④ AI生成摘要：Gemini生成的叙述性内容，从简单Markdown转换为格式化的PDF内容。

警报与参考状态

在构建报告章节之前，build()方法会检查主要指标是否超出其配置阈值。

例如，它可以在以下情况生成警报：

• 平均步数低于目标值；
• 步行速度低于参考值；
• HRV或SpO₂低于设定阈值；
• 平均睡眠时长未达到预期值。

这些警报基于简单对比，不代表医学诊断。

AI免责声明

AI生成部分始终包含可见的免责声明，说明文本由设备数据生成，并非临床评估或诊断，可能包含错误或不准确的解读。

该免责声明还提醒读者，在将生成的叙述用于任何健康相关决策前，应将其与原始指标进行核对，并由合格专业人员审阅。

7. 结论

本项目的主要挑战之一是将Apple Health记录转化为有用且可理解的信息。HealthKit一致的数据结构简化了这一处理过程，并支持创建可复用的处理流程。这也为互操作性打开了大门：在实际环境中，使用HL7 FHIR等标准表示结果，可简化其与应用程序、医院和电子健康记录系统的交换。

将计算与解读分离

一个相关的设计决策是将计算保留在Python中，仅使用Gemini生成叙述文本。平均值、趋势、阈值对比和每周统计数据均以可控方式计算，而模型接收已处理的值并将其转化为可读文本。

在将数据发送给LLM前进行汇总，还能减少token使用量、执行成本以及达到上下文窗口限制的风险。这种方法能更好地控制用于生成报告的信息。

个性化与数据质量

相同的指标和阈值并不适用于所有患者或所有用例。使这些值可配置，可使分析适应患者档案、监测目标以及项目的具体需求。

然而，仅靠配置并不能保证结果的可靠性。统计方法也应经过验证，处理流程应能衡量数据完整性。例如，应能区分真正的活动减少与因电量不足、同步问题或设备使用不规律导致的记录缺失。

在实际实施中，指标、阈值和验证规则应与医疗专业人员共同审阅。

安全与负责任的数据使用

健康数据需要针对隐私、访问、存储和保留制定具体控制措施。实际解决方案应定义收集哪些信息、谁可以访问、存储多长时间以及哪些数据可能发送给外部服务。

尽管这些主题不在本文讨论范围内，但应从设计过程之初就加以考虑。同意、数据最小化和保留政策不应仅在技术实施完成后才添加。这一原则也体现在Apple Health中，该平台要求明确授权才能读取和写入健康信息。

最后说明

本项目是一个使用模拟数据构建的教育性MVP。它尚未准备好投入生产，不应直接用于做出健康相关决策。

其主要目的是展示如何将连续健康数据、确定性处理、可视化与语言模型结合在一个模块化处理流程中。LLM有助于传达结果，但计算、验证规则和数据质量控制应保持可复现和可验证。

8. 参考文献

• Apple. (2018, 1月24日). Apple announces solution

原文：https://dev.to/gdg/from-apple-health-data-to-clinical-storytelling-building-an-ai-powered-report-with-python-and-3n8n