本方案面向港澳台地区医疗健康 App 的功能复用与技术适配，包含三个独立项目。

• 项目构成：项目一 · 国际版改造　|　项目二 · 双 App 合并　|　项目三 · 数据合规与跨境数据；
• 立项方式：分别立项、分别评估、分别验收，可独立推进；
• 共同基础：三个项目共用同一份前置资料与同一套判断口径。

0.1方案说明与阅读路径

0.2三个项目的范围与目标

0.3工作逻辑与推进方式

三个项目按同一条工作逻辑推进：

• 港澳台区域政策与要求确认——明确目标地区的监管要求、平台政策与可用服务范围；
• 国内版功能盘点——依据源代码与产品资料，逐项确认现有功能与实现方式；
• 功能复用判断——按「直接复用 / 配置后复用 / 改造后复用 / 不建议直接复用」四类逐项判定；
• 差异化适配分析——识别因语言、账号通道、计量单位、服务可用性带来的差异；
• 技术解决方案——给出分层架构、设备适配与数据处理的实现路径；
• 项目排期——在资料到位的前提下给出阶段划分与初步周期；
• 10 月底上线或交付可行性评估——按条件判断，结论保持「有条件」。

0.4表达口径与使用说明

全文按下表口径区分事实、判断与待核实事项：

0.5项目一览

在飞利浦灵析家用医疗设备 APP（以下简称「飞利浦灵析 APP」）国内版现有能力之上， 面向港澳台地区完成功能复用与技术适配。本章按统一结构给出四类复用判断与技术实现路径。

1.1项目背景

飞利浦灵析 APP 已在国内完成开发并上架应用市场，面向家庭用户，通过蓝牙连接血压计、体温计等家用医疗设备，将设备测量数据同步至 App，完成健康数据的展示、记录与管理。当前已具备以下能力：

• 账户能力：用户注册与登录、用户资料与账户体系、隐私授权；
• 设备能力：设备发现、绑定、连接保持与断线重连、设备管理；
• 数据能力：健康数据同步、展示、记录与历史查询；
• AI 能力：AI 健康助手与健康知识问答；
• 后台能力：用户管理、设备档案、运营数据与权限管理。

现阶段需要在此基础上，面向港澳台地区提供可用版本。目标地区在语言、账号与登录通道、计量单位、可用服务范围与监管要求上与国内版存在差异，因此本项目的工作集中在功能复用判断与区域适配改造两个方面，而不是重新建设一套 App。

1.2项目目标

本项目的目标可以归纳为四条：

• 形成可用的港澳台版本：目标地区的用户能够完成注册登录、连接设备、查看与管理健康数据，形成完整业务闭环；
• 最大化复用国内版能力：在不改动核心业务逻辑的前提下完成区域适配，降低后续多地区维护成本；
• 把区域差异收敛到一处：语言、单位、登录通道、服务地址、政策文本等随地区变化的要素集中在区域适配层，新增地区只增加配置；
• 把不确定项显式化：将需核实的技术点与需确认的政策事项分别列出，作为后续排期与范围收敛的依据。

1.3当前系统或业务能力

现有能力分为五类，构成本项目的复用基线：

1.4需求分析

面向港澳台地区，需求可分为三类：必须满足的合规与可用性要求、影响用户体验的本地化要求、影响系统架构的技术要求。下图给出六个影响域及其包含的具体问题。

1.5工作范围评估

本项目范围包含四类工作，并有三类明确不在范围内：

1.6功能或技术方案

技术上采用「核心能力复用 + 区域适配层 + 多地区配置」的组织方式：核心能力层与地区无关，原则上整体复用；随地区变化的能力单独收敛在区域适配层；新增地区时只增加适配层配置，不改动核心业务代码。

设备接入按分层方式组织：业务功能层调用统一设备能力模型，由设备适配层针对每个机型实现具体协议，对上层保持一致的接口契约。

按上述架构，本项目划分为十个方案模块，逐项给出实施重点与交付成果：

1.7功能清单或交付清单

功能清单按「功能大类 / 功能模块 / 子功能」三级组织，共 6 个功能大类、24 个功能模块、64 个子功能。每个子功能标注优先级，据此划分两个版本：V0.5 纳入全部 P0，V1.0 纳入全部功能。下表与图 1-5 使用同一份数据，两者数字一致。

下表为完整功能清单，共 64 个子功能。优先级标注该子功能进入哪个版本：P0 进入 V0.5 版本，P1 在 V1.0 版本补齐。即 V0.5 = 全部 P0（47 项），V1.0 = 全部功能（64 项）。优先级为当前初步判断，需结合资料核实与业务优先级最终确定。

1.8脱敏健康数据跨境回传方案

围绕港澳台版本 App 产生的部分核心健康数据，设计「海外数据处理、脱敏转换、安全传输、境内接收」的技术方案，用于支持境内运营分析、产品能力优化、设备运行分析、健康数据趋势研究，以及后续经评估的数据智能应用场景。方案以数据最小化为前提：只回传满足明确业务目的所必需的数据，优先采用聚合数据与脱敏数据。

（1）建设目标

（2）数据回传范围

（3）脱敏处理原则

脱敏按四类规则执行：直接身份信息删除（姓名、手机号、邮箱、证件信息、精确地址、登录账号、家庭成员姓名及自由文本中的身份信息默认删除）；用户 Token 化（需支持用户级分析时，由海外系统生成随机 Token，真实身份与 Token 的映射关系保留在海外环境）；设备标识处理（设备序列号、MAC 地址等替换为设备 Token 或哈希标识，按用途保留设备型号、类型、固件版本与运行状态）；时间与地区粒度调整（精确时间调整为日期或区间，精确地址调整为地区或城市级别，对数据量较小的群体聚合处理以降低重新识别风险）。

（4）技术架构与处理流程

海外系统保存完整原始数据，并在海外侧完成数据分类与脱敏；传输前进行字段白名单校验，传输过程使用加密通道；境内通过独立接收服务接收数据，境内系统不直接访问海外生产数据库，也不采用未经筛选的数据库整体复制，所有传输任务保留可追溯记录。

（5）分阶段实施策略

回传按三个阶段推进：第一阶段优先回传聚合统计数据（用户与设备数量、设备活跃情况、数据上传次数、设备异常数量、健康指标区间统计、产品使用趋势），用于运营分析、产品优化、设备质量分析与使用趋势研究；第二阶段在数据范围与使用目的明确后，评估回传假名化用户级数据（用户 Token、设备 Token、测量日期或区间、健康测量值、设备类型、地区标签、数据来源），境内不保存与 Token 对应的直接身份信息；第三阶段为专项数据处理，不作为默认回传内容。

（6）数据安全控制

境内数据访问按角色限制范围：

（7）数据删除与授权撤回

• 用户在海外侧删除数据后，海外系统更新数据状态，境内对应数据同步删除或停止使用；
• 已生成的分析结果按数据保留策略处理；
• 用户撤回授权后，停止后续数据传输，并对已进入分析系统的数据进行关联处理；
• 备份数据按既定生命周期管理。

（8）实施路径

（9）功能清单

1.9功能复用或适配判断

按下图四象限对 24 个功能模块逐一判定。横轴为技术改动量与复用难度，纵轴为区域与政策敏感度。

逐项判断如下：

1.10版本划分

功能清单中的每个子功能都标注了优先级，据此把项目一划分为两个交付版本，V0.5 先交付、V1.0 补齐：

V0.5 纳入全部 P0 子功能，是能独立完成业务闭环的最小可用版本：用户可以注册登录、绑定并连接设备、把测量数据同步进来并看到数据，并具备家庭账户与成员共享、必要的多语言与隐私授权，以及支撑上述能力的后台基础功能。V1.0 纳入全部子功能，在 V0.5 的基础上补齐 P1。两个版本共用同一套架构与区域适配层，V1.0 不重构 V0.5 已交付的实现，因此 V0.5 的范围越小，后续补齐的风险越低。

两个版本的对比：

各功能大类的版本构成如下：

1.11项目排期

1.1210 月底上线或交付可行性

实现路径（以前置资料到位为起点，关键环节并行推进）：

• 前置资料到位；
• 源代码、工程结构、设备 SDK 与裸协议审查；
• 设备复用性验证与 V0.5 范围确认；
• 区域化适配与核心功能并行开发；
• 多设备真机联调与回归测试；
• 发布构建与上架资料准备；
• 10 月 31 日完成首发版本交付及上架准备。

1.13项目报价范围

项目一基于现有国内版飞利浦灵析家用医疗设备 App 的源代码和工程基础，完成面向港澳台地区的国际版本适配。项目范围包括多语言适配、账号与登录体系调整、设备接入、健康数据记录与展示、家庭账户、AI 健康助手及第三方服务适配。

一期 V0.5 范围包含 5 款设备，其中 1 款采用设备 SDK 对接，其他设备采用设备裸协议对接。最终报价将以源代码、设备 SDK、协议文档、测试设备及第三方服务资料的技术核实结果为基础确认。

报价范围覆盖以下工作内容：

• 国内版源代码及工程结构分析；
• 现有功能复用与改造范围确认；
• 5 款设备的 SDK 及裸协议接入；
• 设备绑定、连接、数据采集和同步；
• 健康数据展示、记录和管理；
• 家庭账户及成员数据共享；
• 简体中文、繁体中文及英文多语言适配；
• 登录注册及账户体系调整；
• AI 健康助手接口适配；
• 第三方服务区域可用性适配；
• 海外服务端及数据链路调整；
• 区域化测试、回归测试及上架准备。

1.14项目风险

1.15前置资料

以下资料是本项目开展评估与实施的必要输入：

1.16待确认事项

1.17下一步实施建议

1. 先交资料，再定范围：优先提供源代码与工程资料、首发机型清单与 SDK 文档，作为复用判断与工作量评估的基准；
2. 先做单机型试点：选取一个代表性机型先行完成适配与真机验证，验证适配层设计后再批量推进其余机型；
3. 把区域差异先配置化：语言、单位、登录通道、服务地址、政策文本等在开发早期即做成配置项，避免后期返工；
4. 同步启动上架资料准备：应用商店资料与审核要求核对不依赖开发完成，可并行推进；
5. 政策事项单独跟踪：合规相关事项由项目方主导确认，我方提供技术要点与实现支持，确认结果用于收敛功能范围。

将可孚孚探 App 的功能与设备能力合并至可孚健康 App，形成统一入口、统一账号与统一数据归属， 并保留设备侧的持续数据上传能力。本章重点是两套体系在账号体系、数据归属、设备绑定关系与实时数据通道上的合并方式。

2.1项目背景

可孚健康 App 与可孚孚探 App 目前是两个独立应用，分别承载不同的业务能力：前者覆盖家庭健康管理与设备连接能力，后者承载动态血糖监测相关的设备与数据能力。两个应用并存带来三方面问题：

• 用户侧：需要在两个应用之间切换，账号与设备数据分散；
• 业务侧：同一用户的行为与数据无法形成统一视图；
• 技术侧：两套账号体系、两套数据存储与两套设备关系，维护成本重复投入。

因此需要将孚探的能力合并至可孚健康 App，形成统一入口、统一账号、统一数据归属。需要注意的是，合并的难点不在功能移植本身，而在账号体系与数据归属的统一：两个应用各自记录了用户与设备、用户与数据之间的关系，合并时这些关系必须重新映射，否则会出现数据可见性不一致。

2.2项目目标

• 统一入口：用户在一个应用内完成设备连接、数据查看与健康管理，不再需要区分两个 App；
• 统一账号：以可孚健康 App 现有账号体系为唯一主体系，不新增第二套账号入口；
• 统一数据归属：设备归属与数据归属随账号一并统一，权限校验集中在一处；
• 保留实时能力：设备侧持续数据上传能力在合并后不降级，异常情形可识别、可提示；
• 可控推进：合并方式与迁移范围可分批实施，避免一次性重构带来的整体风险。

2.3当前系统或业务能力

2.4需求分析

2.5工作范围评估

2.6功能或技术方案

合并方式有三条可选路线，改动范围与风险差异明显，先确定路线再评估工作量。

账户与数据归属是合并的技术核心。下图为两套体系的映射关系与处理原则。

目标架构按「主工程 + 业务模块 + 设备 SDK + 统一数据服务」四段组织，设备数据经采集与上行通道统一收敛到数据服务后供页面使用。

按上述架构，本项目划分为九个方案模块：

2.7功能清单或交付清单

功能清单按「功能大类 / 功能模块 / 子功能」三级组织，共 5 个功能大类、19 个功能模块、45 个子功能。每个子功能标注优先级，据此划分两个版本：V0.5 纳入全部 P0，V1.0 纳入全部功能。下表与图 2-4 使用同一份数据，两者数字一致。

下表为完整功能清单，共 45 个子功能。优先级标注该子功能进入哪个版本：P0 进入 V0.5 版本，P1 在 V1.0 版本补齐。即 V0.5 = 全部 P0（33 项），V1.0 = 全部功能（45 项）。优先级为当前初步判断，需结合资料核实与业务优先级最终确定。

2.8功能复用或适配判断

本公司功能清单中的 19 个功能模块逐项判断如下。判定口径与项目一一致：直接复用 / 配置后复用 / 改造后复用 / 不建议直接复用。

2.9版本划分

功能清单中的每个子功能都标注了优先级，据此把项目二划分为两个交付版本，V0.5 先交付、V1.0 补齐：

V0.5 纳入全部 P0 子功能，是合并后能独立跑通的最小可用版本：用户在一个应用内完成账号统一、绑定孚探设备、看到实时与历史数据，且数据归属与权限校验正确。V1.0 纳入全部子功能，在 V0.5 的基础上补齐 P1。两个版本共用同一套合并架构，V1.0 不重构 V0.5 已交付的实现。

两个版本的对比：

各功能大类的版本构成如下：

2.10项目排期

2.1110 月底上线或交付可行性

实现路径（以双端资料到位为起点，关键环节并行推进）：

• 双端代码及 SDK 资料到位；
• 合并架构与 SDK 集成方案确认；
• 账号映射及数据归属方案确认；
• 核心模块移植与 SDK 接入并行开发；
• CGM 数据采集、上报及异常链路验证；
• 端到端联调与回归测试；
• 灰度验证、发布构建及上架准备；
• 10 月 31 日完成首发版本交付及上架准备。

2.12项目报价范围

项目二基于可孚健康 App 源代码和可孚孚探设备 SDK，将可孚孚探 App 的设备能力、动态血糖监测能力及相关健康数据能力合并至可孚健康 App。项目重点包括统一入口、账号映射、数据归属、SDK 接入、设备数据采集、实时数据通道及健康数据展示。

最终报价将以双方源代码、孚探 SDK、账号数据结构、接口文档及测试设备的技术核实结果为基础确认。

报价范围覆盖以下工作内容：

• 可孚健康 App 源代码及工程结构分析；
• 可孚孚探 SDK 技术评估；
• 合并架构及 SDK 集成方案确认；
• 账号映射及数据归属方案确认；
• 孚探设备连接、绑定和数据采集；
• 动态血糖数据回调及上报链路适配；
• 健康数据记录、趋势及历史数据展示；
• 家庭账户及成员数据权限适配；
• 断线重连、失败重试及异常数据处理；
• 核心业务模块移植及主 App 集成；
• 基础数据接口和存储能力适配；
• 端到端联调、回归测试和上架支持。

2.13项目风险

2.14前置资料

2.15待确认事项

2.16下一步实施建议

1. 先交资料、先盘点：双方代码与工程结构、设备 SDK 与数据结构是全部后续判断的输入，建议优先交接；
2. 把路线确认放在开发之前：先确定合并路线，再评估移植工作量，避免边做边改；
3. 账号与数据归属方案单独评审：该方案涉及用户可感知的数据可见性，建议单独评审后实施；
4. 设备与数据通道先做单点验证：选取一个设备型号打通采集、上报、写入、展示全链路，再批量推进；
5. 迁移与合并分批推进：历史数据迁移、双端后台合并等长周期事项与首期解耦，避免阻塞 V0.5；
6. 明确灰度与回退方式：合并期间的过渡安排需提前确定，保证旧版本用户可用。

本项目面向港澳台地区的数据处理要求，梳理数据分类、数据流向与跨境访问场景， 明确需要确认的政策与合规事项，并界定合规方案的服务范围，为项目一、项目二的功能范围与架构选择提供约束。 本章提供现状梳理、技术层面的处理原则与合规服务范围，不出具合规结论。

3.1项目背景

项目一与项目二的目标地区为港澳台地区，用户数据、设备数据与账号数据将产生并存储在不同的位置，可能涉及跨地区的访问与流转。因此需要先完成两件事：

• 把数据说清楚：现有数据的分类、产生位置、存储位置与流转路径；
• 把要求说清楚：目标地区对医疗健康类数据的处理要求，以及这些要求对功能范围与架构选择的影响。

3.2项目目标

3.3数据分类与数据流向现状

数据按业务用途分为四类，产生位置、存储位置与需要确认的跨境访问场景见下图，特征对比见下表。

四类数据的特征对比如下：

3.4政策与监管要求影响分析

下表按目标地区列出需要确认的要求方向及其影响面。表中的「区域要求」只描述需要确认的主题，不引用非官方来源的解释，也不作合法性判断。

3.5数据处理技术原则与 AI 数据边界

在合规结论明确之前，可以先确定技术层面的处理原则。这些原则的作用是让架构具备可调整性：无论最终要求如何，都能通过配置调整而不需要返工重构。

AI 健康助手涉及数据外发，单独按下表控制数据边界：

3.6合规方案：服务范围与工作内容

本节说明合规方案包含哪些分析与匹配工作、交付什么成果，用于界定服务范围与协作界面。

合规服务包含以下四项分析工作：

在分析结果的基础上，完成以下四项匹配工作：

3.7项目报价范围

项目三作为独立的合规与数据技术专项，重点围绕港澳台地区的数据合规要求、健康数据分类、数据流转、海外数据隔离及脱敏健康数据跨境回传进行分析和技术落地。

本项目重点提供技术方案、系统实施及相关落地支持，不直接替代法律意见、法律认证或行政审批。

报价范围覆盖以下工作内容：

• 港澳台地区数据合规要求梳理；
• 健康数据分类和敏感数据识别；
• 数据采集、存储、使用和删除流程设计；
• 海外数据隔离方案；
• 脱敏健康数据跨境回传方案；
• 字段白名单、权限控制和审计机制；
• 用户授权、撤回授权和数据删除机制；
• App 隐私相关功能的技术要求；
• 数据访问、传输及处理日志；
• 合规实施清单和上线检查清单。

3.8待确认事项

3.9下一步实施建议

1. 先确认、再设计：优先推动上表中的确认事项；确认结果明确后，再按 3.6 节界定的服务范围推进落地实现方案的编制；
2. 技术实现保持可配置：存储位置、访问范围、授权项与提示话术在开发早期即做成配置项，使合规结论明确后的调整不需要返工；
3. 数据现状同步更新：国内版数据结构说明到位后，同步更新 3.3 节的数据分类与流向；
4. 把技术原则落入实现：3.5 节的处理原则与 AI 数据边界建议，需在项目一、项目二的实现中逐项落地；
5. 合规与法律事务分离跟踪：正式隐私政策与用户协议的起草、法律意见的出具由项目方法务与专业团队负责，我方提供技术要点与实现支持。

本章把三个项目的排期放在同一时间轴上，说明阶段划分、先后依赖与并行关系。 全部周期以「前置资料到位」为共同起点，属阶段性目标而非固定交付承诺。

4.1各项目排期总览

4.2关键路径与并行关系

三个项目在早期阶段可以并行，但存在两处必须串行的关键路径：

可并行推进的部分：

• 项目一与项目二的大部分工作可并行：两者都需要同一批设备与账号资料，但功能适配工作相对独立；
• 上架资料准备与开发并行：应用商店资料与审核要求核对不依赖开发完成；
• 项目三的数据现状梳理与项目一、二的启动并行：现状梳理不依赖开发进度，但合规方案的补充需要等待确认结果。

4.3排期口径与假设

本章按统一口径对 10 月底的上线或交付可行性给出判断。 结论保持「有条件」：可行性的前提是前置资料、设备验证与关键确认事项按计划落实， 本章不给出任何关于上线时间、审核结果或运行指标的承诺。

5.1评估口径与判断依据

可行性评估按以下口径进行，避免把「具备条件」等同于「一定达成」：

5.2各项目可行性判断

5.3结论与前提条件

初步结论：在下列前提条件均按计划落实的情况下，项目一与项目二在 10 月底完成各自的 V0.5 版本具备条件；项目三提供数据现状梳理，合规方案待确认事项完成后补充。

• 资料来源：国内版与孚探侧的代码、工程结构、技术栈资料按期提供；
• 设备条件：首发机型与设备型号确定，SDK、协议文档与测试设备齐备；
• 账号与数据：账号映射与数据归属方案按期确认；
• 区域适配：语言、单位、登录通道等适配项按期完成；
• 第三方服务：AI、推送等服务的区域可用性确认完成；
• 上架准备：应用商店所需材料与账号就绪。

本章集中列出本方案后续判断所依赖的前置资料与待确认事项。 前置资料决定工作量与范围的判断依据，待确认事项决定功能范围与架构选择的边界， 两者共同构成方案从「初步判断」走向「可执行」的前提。

6.1前置资料清单

6.2待确认事项汇总

6.3下一步实施建议

1. 优先完成资料交接：代码与工程资料、设备 SDK 与协议文档是全部后续判断的输入，建议按项目一、项目二的顺序统一安排；
2. 在开发启动前完成三项确认：首发机型范围、账号与数据归属方案、合并技术路线；
3. 先做单点验证再批量推进：项目一按机型试点、项目二按设备打通全链路，验证后再扩大范围；
4. 区域差异与合规相关配置早期配置化：语言、单位、登录通道、服务地址、授权项、提示话术等做成配置项，保留调整空间；
5. 政策与合规事项单独跟踪：由项目方主导确认，不与开发进度绑定，但结果需及时回流到功能范围；
6. 同步准备上架资料：应用商店材料与审核要求核对可与其他工作并行推进。