HealthCarePregnant/0-1-基础构想.md

# 孕产个案管理平台 · 基础构想

- **背景来源**：2026年6月17日 11:57 电话沟通（详见原始资料 0-原始资料.txt）
- **主题**：联合打造垂直领域的"孕产个案管理系统"，以 AI 全面数字化支撑个案管理

## 合作方与分工

| 角色 | 主体 | 职责 |
|------|------|------|
| **运营方（需求方）** | 陈总，以**中医为主**的医疗机构（联合菲斯克，基于"如初"资源）| 提供业务体系、检测设备与数据、医学理论依据、知识库内容，负责运营与服务 |
| **技术方（建设方）** | 我方 | 负责系统设计与搭建、AI 能力建设、数据/分析/知识库的工程实现 |

---

## 一、合作背景

- **运营方**为以**中医为主**的医疗机构，拟联合菲斯克（基于"如初"资源）共同打造一个**孕产健康运营平台**。
- 切入点：孕产期健康监管。孕妇**妊娠期糖尿病、妊娠期高血压**等发生比例高，存在明确的监管需求。
- 定位：不做大而全，聚焦孕产领域，做一个**垂直行业版的"孕产个案管理系统"**——这也被双方视为 **AI 落地的优质垂直方向**。

## 二、核心理念

- 借鉴美国流行的 **个案管理师（Case Manager）** 体制，该体制已有成熟的体系与标准。
- **中西医结合**：运营方以中医为主，平台在西医监测指标（血糖、血压等）之外，融入**中医体质辨识、辨证调养、孕期食疗与养护**，形成区别于通用孕产 App 的差异化护城河。
- 围绕孕产场景构建后台知识库及相关功能模块，形成专业、垂直的解决方案。
- 所依据的医学理论是**通用、可公开查证的知识（general knowledge）**，由专业医生介入即可落地，知识库可基于权威公开资料构建。
- 共识：垂直领域才有价值，竞争力不在于工具本身，而在于**延伸的服务**。

## 三、AI 的核心定位（系统灵魂）

AI 不是某个附加功能，而是贯穿全平台的中枢，目标是**全面数字化地支撑个案管理**，通过**人机协同**让个案管理师达到最高管理水平，保障孕妇健康与完美孕期体验。AI 承担以下角色：

| AI 角色 | 作用 |
|---------|------|
| **交互中枢** | 成为孕妇、个案管理师、医生、设备等各方的统一交互入口与协同纽带 |
| **知识库服务** | 基于权威知识库提供智能问答与日常查询，随时为各方提供专业解答 |
| **健康分析** | 实时分析设备采集的多项指标，识别异常、推断风险 |
| **趋势预测** | 基于纵向时间序列数据预测健康走向（如风险演变、指标趋势）|
| **管理支持** | 为个案管理师提供决策建议、计划生成、预警处置辅助，实现人机协同 |

> 核心理念：**AI 赋能、人机协同、医生兜底**。AI 负责全量数据处理、分析、预测与建议，个案管理师与医生负责判断与决策，二者协同实现"最高水平的孕期管理"。

## 四、闭环逻辑（达成一致）

1. **数据采集**：通过居家检测设备获取孕妇体征数据（设备带接口，可直接对接取数）。
2. **分析与管理**：基于专业医学理论建立分析/管理体系（模型暂未现成，但理论成熟，可由专业医生介入）。
3. **知识库**：导入权威资料（部分自有内容 + 网络/出版物等权威来源），支持日常查询。
4. **输出建议**：结合孕妇实际情况，给出监管建议与输出。

> 技术上无明显障碍，关键在于**体系梳理、内容准备和业务流程设计**。

## 五、产品范围

- **使用对象**：孕妇（孕产期为主）。
- **监测指标**：不止血糖、血压，涵盖数十种指标，例如维生素D含量（与胎儿发育相关）等（**具体以设备实际可测项为准，见附录五待验证假设**）。
- **服务与体验**：在健康监管之外，平台承载**孕期关怀与延伸服务**——健康教育、个性化指导、中医调养、答疑陪伴、孕期里程碑提醒等，目标是"健康监管 + 完美孕期体验"，也是商业竞争力的核心（竞争力来自延伸服务而非工具本身）。
- **健康习惯提醒**：基于时间与计划，定时提醒**运动、休息、喝水、服药、产检、监测打卡**等；提醒内容**个性化**——运动提醒须按孕周与风险分层动态调整（高风险孕妇改为"休息/放松"而非运动），避免一刀切。
- **游戏化与轻量小游戏**：通过**积分、徽章、连续打卡、轻量小游戏（如消消乐、正念放松、孕期知识问答闯关）**提升依从性、缓解焦虑、增强留存。需把握孕期分寸：**限制单次时长避免久坐刷屏、低压力非强竞技、可反向触发"起身活动"提醒**。
- **体验原则**：持续监测与预警本身可能加重孕妇焦虑，交互须**有温度、分级提醒、避免过度医疗化**，在"安心"与"警觉"之间取得平衡。

## 六、MVP 与演进策略

- **不追求一步到位**：首个原型聚焦**一个高价值闭环**（建议：妊娠期糖尿病 GDM 血糖管理——采集→规则预警→管理师干预→智能问答），验证后再横向扩展指标与场景。
- **冷启动路线**：知识库与智能问答**先行可用**；分析**先用规则引擎**（医生定义阈值），积累数据后再引入数据驱动模型与趋势预测。
- **演进**：单场景闭环 → 多指标覆盖 → 中西医结合调养 → 趋势预测 → 全量个案管理。

## 七、成功度量（KPI）

| 维度 | 指标示例 |
|------|----------|
| 监管有效性 | 预警及时率、预警准确率（误报/漏报）、高风险转诊及时率 |
| 用户依从 | 监测依从率、漏测率、计划执行率 |
| 健康结局 | 血糖/血压达标率、孕期不良结局发生率下降 |
| 体验与留存 | 用户留存率、满意度、焦虑量表改善 |
| 运营 | 单个案管理师可管理人数（人机协同效率提升）|

## 八、商业模式（待展开）

- **B2B**：向中医机构/月子中心/产科诊所提供平台与个案管理 SaaS。
- **B2C**：孕妇订阅制健康管理与关怀服务。
- **设备 + 服务**：检测设备 + 监管服务捆绑。
- **延伸服务变现**：营养、调养、母婴课程、转诊与增值医疗服务（呼应"竞争力靠延伸服务"）。

## 九、待办事项（Next Steps）

| 负责方 | 事项 |
|--------|------|
| 运营方（陈总）| 1. 提供检测设备可采集的**数据指标清单 + 精度 + 认证情况**（关键，见附录五）|
| 运营方（陈总）| 2. 提供所依据的**医学理论名称/介绍资料**（名称即可，便于技术方查阅）|
| 技术方（我方）| 3. 先**搭建一个基础原型**（建议从 GDM 单场景闭环切入），让讨论从概念转向可见系统 |
| 双方 | 4. 节后约时间当面碰（双方均在北京）|

## 十、待确认事项

- 后台分析模型需从零构建（理论现成、通用，模型待开发）。
- 知识库内容来源与权威性把控方式需进一步明确。
- 业务流程与服务延伸的具体安排尚待规划。
- AI 各能力（交互、问答、分析、预测、管理支持）的优先级与原型范围待划定。
- **合规定位、设备能力、临床安全等关键风险见附录五，需优先确认。**

---

# 附录：本体分析（Ontology Analysis）

> 说明：以下本体分析用于明确"分析模型"与"知识库"两大核心模块的概念结构、实体关系与运转逻辑，并将"个案管理师（Case Manager）"体制作为贯穿全局的方法论框架。本体（Ontology）即对领域内**概念、属性、关系、约束**的形式化定义，是后续建模、建库与系统设计的语义基础。
>
> 内容基于通行的个案管理标准框架（CMSA《个案管理实践标准》、CCMC 认证体系）与孕产母胎监护通行实践整理；具体医学阈值与理论依据需由专业医生最终确认。

## 一、个案管理师（Case Manager）体制本体

### 1.1 体制定义

个案管理是一种以**患者为中心**的协作式服务过程，通过评估、规划、协调、监督和倡导，整合医疗资源，满足个体的健康需求，兼顾**质量与成本**。个案管理师是这一过程的责任主体。

### 1.2 个案管理师的角色（Roles）

| 角色 | 职责 |
|------|------|
| 评估者 Assessor | 收集并评估孕妇的健康、风险、社会与心理状况 |
| 规划者 Planner | 制定个性化照护计划与目标 |
| 协调者 Coordinator | 协调医生、设备、家庭、机构等多方资源 |
| 监督者 Monitor | 持续跟踪指标、依从性与计划执行情况 |
| 教育者 Educator | 提供健康教育与自我管理指导 |
| 倡导者 Advocate | 代表孕妇利益，争取适当的医疗与支持资源 |

### 1.3 个案管理流程（Process Phases）—— 系统状态机的核心

标准个案管理是一个**闭环循环**，可直接映射为系统的核心工作流：

```
筛查 Screening
  → 评估 Assessment
    → 风险分层 Risk Stratification
      → 计划制定 Planning
        → 计划实施/协调 Implementation & Coordination
          → 监测与随访 Monitoring & Follow-up
            → 评价 Evaluation
              → (达标转出 Transition / 未达标回到评估)
```

> 该流程是"分析模型"与"业务流程"的骨架：每一阶段都有明确的输入、输出、判定条件与责任角色，适合用状态机或工作流引擎实现。

> **红旗（Red Flag）急症旁路**：上述循环适用于常规监管节奏，但**危急情况不能走常规流程**。当出现危急组合（如血压骤高 + 剧烈头痛 + 视物模糊提示子痫前期、胎动消失、阴道大量出血等）时，系统须**绕过常规循环直接升级**——立即提示就医/转急诊并通知医生。这是临床安全底线，见附录五。

### 1.4 体制核心概念（Class）

- **个案 Case**：一名孕妇的完整管理实例，贯穿整个孕产周期。
- **照护计划 Care Plan**：目标、干预措施、随访频率的集合。
- **干预 Intervention**：针对特定风险/指标的具体动作，包括：临床类（用药提醒、转诊）、生活方式类（饮食、运动、休息、喝水指导）、**习惯养成/游戏化类**（打卡、积分、徽章、轻量小游戏）。运动类干预须按孕周与风险分层个性化。
- **提醒 Reminder**：基于时间与计划触发的定时推送（运动/休息/喝水/服药/产检/监测打卡），由 AI 交互中枢执行，是提升依从性的关键手段。
- **风险分层 Risk Level**：低/中/高风险，决定监测强度与干预力度。
- **依从性 Compliance**：孕妇对监测与计划的执行程度。

### 1.5 干系人（Stakeholders）

除孕妇与个案管理师外，体系还涉及以下角色，影响交互、协同与转诊设计：

| 干系人 | 作用 |
|--------|------|
| 孕妇 Patient | 服务核心对象 |
| 个案管理师 Case Manager | 管理主体、人机协同核心 |
| 医生 Physician | 临床决策与高风险兜底 |
| 营养师 / 中医调养师 | 饮食、体质调养指导 |
| 家属 Family | 协助监测、情感支持 |
| 产科医院 / 转诊网络 | 急症与高风险转诊承接 |
| 运营客服 Operator | 服务运营、用户触达 |
| 数据合规员 DPO | 数据安全与隐私合规（见附录五）|

## 二、分析模型本体（Analysis Model Ontology）

### 2.1 核心实体（Entities / Classes）

| 实体 | 说明 | 关键属性 |
|------|------|----------|
| 孕妇 Patient | 管理与服务对象 | 孕周、年龄、既往史、孕次、风险等级 |
| 检测设备 Device | 居家数据采集来源 | 设备类型、接口、采集指标、精度 |
| 观测值 Observation | 单次指标测量结果 | 指标类型、数值、单位、时间戳、来源设备 |
| 指标 Indicator | 被监测的体征/生化项 | 名称、正常范围、孕期分段阈值、单位 |
| 风险 Risk | 由指标推断的健康风险 | 风险类型、等级、触发规则、置信度 |
| 预测 Prediction | 基于纵向时序数据对未来走向的预判 | 预测目标、时间窗、概率/趋势、依据数据 |
| 规则 Rule | 指标→风险的判定逻辑 | 条件、阈值、孕周适配、动作 |
| 预警 Alert | 超阈值或异常触发的事件（跨本体共享：在体制本体中由个案管理师处置）| 等级、关联指标、处置状态 |
| 照护计划 Care Plan | 分析结论驱动的干预方案 | 目标、措施、随访频率 |
| 个案管理师 Case Manager | 决策与服务责任人（跨本体共享：体制本体的核心角色）| 负责个案、处理预警 |

### 2.2 监测指标体系（Indicator Taxonomy）

> 以孕妇为对象，覆盖数十种指标。以下为分类框架，具体指标清单待运营方提供设备采集清单后补全。

- **代谢类**：血糖（空腹/餐后，妊娠期糖尿病 GDM 监测核心）、糖化血红蛋白等
- **心血管类**：血压（收缩压/舒张压，妊娠期高血压/子痫前期监测核心）、心率
- **营养/微量元素类**：维生素D（与胎儿骨骼发育相关）、铁、钙等
- **胎儿相关**：胎动、胎心（如设备支持）
- **中医辨证维度**：体质类型、舌象/脉象（如可采集）、症状证候，用于辨证调养建议
- **其他生化指标**：数十项，由检测设备能力决定（**实际可测项以设备能力为准，见附录五**）

> **红旗指标组合**：部分指标的特定组合构成急症信号（如血压骤升 + 头痛 + 视物模糊），须配置为旁路升级规则，直接触发就医提示。

### 2.3 分析模型的推理链（Reasoning Chain）

```
设备采集 → 观测值 Observation
   → 与指标阈值/孕周分段标准比对（Rule）
      → 推断风险 Risk + 生成预警 Alert
         → 触发照护计划/干预 Intervention
            → 个案管理师审核与处置
               → 随访复测 → 更新风险评估（闭环）
```

> 模型现状：**理论成熟、模型待建**。建议采用"规则引擎（临床阈值/指南规则）+ 后续数据驱动模型"的渐进路线，初期以可解释的规则为主，由专业医生定义阈值与孕周分段标准。

### 2.4 关键约束（Constraints）

- 指标阈值需按**孕周分段**（孕早/中/晚期标准不同）。
- 风险判定必须**可解释、可追溯**到具体规则与观测值。
- 高风险预警必须有**人工（个案管理师/医生）介入**环节，系统不替代临床决策。

## 三、知识库本体（Knowledge Base Ontology）

### 3.1 知识库定位

为分析模型提供**判定依据**，为孕妇/管理师提供**日常查询**支持，形成"采集—分析—知识—建议"的闭环。

### 3.2 知识实体（Knowledge Entities）

| 实体 | 说明 |
|------|------|
| 知识条目 Knowledge Item | 最小知识单元（一条结论/解释/建议）|
| 临床指南 Guideline | 权威诊疗/管理标准（如妊娠期糖尿病、妊娠期高血压指南）|
| 中医调养知识 TCM Knowledge | 体质辨识、辨证、食疗与孕期养护知识 |
| 指标释义 Indicator Reference | 各指标的含义、正常范围、异常意义 |
| 干预知识 Intervention Knowledge | 针对风险的处置/生活方式建议 |
| 来源 Source | 知识出处（权威出版物、网络资料、自有内容）|
| 主题/标签 Topic | 知识分类与检索维度 |

### 3.3 知识来源与可信度（Source & Provenance）

- **自有内容**：机构专家/医生输入的一部分专业内容。
- **权威外部来源**：现成出版物、权威网络资料。
- **可信度约束**：每条知识条目须标注来源与权威级别，支持溯源；优先采用权威指南。

### 3.4 知识库与分析模型的关系

```
知识库 Guideline / Rule Reference
        ↓ 提供阈值与判定依据
   分析模型 Rule / Risk
        ↓ 产生风险结论与建议
   知识库 Intervention Knowledge
        ↓ 支撑建议输出与日常查询
      孕妇 / 个案管理师
```

> 知识库与分析模型并非独立：知识库中的**指南与指标释义**是分析规则的来源，分析模型产生的**风险**又关联到知识库中的**干预建议**，二者通过"指标—规则—风险—干预"语义链耦合。

## 四、整体本体关系图（概念视图）

```mermaid
graph TD
    CM[个案管理师 Case Manager] -->|负责| Case[个案 Case]
    Case -->|属于| Patient[孕妇 Patient]
    Device[检测设备] -->|采集| Obs[观测值 Observation]
    Obs -->|关联| Indicator[指标 Indicator]
    Indicator -->|阈值依据| KB[知识库: 指南/释义]
    Obs -->|经规则判定| Rule[规则 Rule]
    Rule -->|推断| Risk[风险 Risk]
    Risk -->|触发| Alert[预警 Alert]
    Risk -->|匹配| Intervention[干预 Intervention]
    Intervention -->|内容来自| KB
    Alert -->|处置| CM
    CM -->|制定| CarePlan[照护计划 Care Plan]
    CarePlan -->|包含| Intervention
    Patient -->|查询| KB
```

## 五、待运营方/医生确认的本体细节

1. 设备可采集的**完整指标清单**及各指标接口字段。
2. 各指标的**孕周分段阈值**与异常判定标准（理论依据/指南名称）。
3. 个案管理师体制落地时的**角色边界**（系统自动 vs 人工介入的分界）。
4. 知识库**权威来源清单**与内容审核流程。

---

# 附录二：三大本体的数据融合（Ontology Data Fusion）

> 目标：让"个案管理师体制""分析模型""知识库"三个本体**不各自为政**，而是融合为一张统一的语义网络（知识图谱）。融合的核心是——同一个孕妇、同一项指标、同一条风险，在三个本体中指向**同一份数据实体**，从而实现"采集即分析、分析即关联知识、知识即驱动管理动作"的全链路打通。

## 一、融合原则

1. **统一锚点（孕妇为中心）**：所有数据围绕同一个 `孕妇ID` 聚合，个案、观测值、风险、计划、查询记录全部挂接到同一人。
2. **共享语义骨架**：三个本体共用一条主链——`指标 → 规则 → 风险 → 干预 → 知识`，任一本体引用的概念都来自同一套术语表（统一词表 / 编码标准）。
3. **单一事实来源（Single Source of Truth）**：每个实体（如"血压""妊娠期高血压"）在系统中只定义一次，三方引用同一定义，避免重复与冲突。
4. **可追溯（Provenance）**：任何一条风险结论都能反向追溯到"哪台设备、哪次观测、依据哪条规则、引用哪条指南、由哪位个案管理师处置"。

## 二、融合的关键连接点（Join Keys）

三个本体通过以下共享标识实现数据对齐：

| 共享标识 | 连接的本体 | 作用 |
|----------|-----------|------|
| `孕妇ID Patient ID` | 体制 ↔ 分析模型 ↔ 知识库 | 全局锚点，聚合一个人的所有数据 |
| `指标ID Indicator ID` | 分析模型 ↔ 知识库 | 观测值、规则阈值、指标释义共用同一指标定义 |
| `风险ID Risk ID` | 分析模型 ↔ 体制 ↔ 知识库 | 风险既触发管理动作，又关联干预知识 |
| `干预ID Intervention ID` | 体制 ↔ 知识库 | 照护计划中的干预，其内容来自知识库 |
| `指南ID Guideline ID` | 知识库 ↔ 分析模型 | 规则阈值的依据来源，可溯源 |
| `规则ID Rule ID` | 分析模型（内部）| 标识每条判定逻辑，供风险溯源 |
| `预警ID Alert ID` | 分析模型 ↔ 体制 | 风险触发的预警，关联到管理处置动作 |

> 实现要点：**指标与术语必须统一编码**（建议对接通行医学术语标准，如 LOINC 检验项、SNOMED CT 临床概念、ICD 诊断），保证设备数据、规则、知识三方"说同一种语言"。

## 三、融合后的统一数据视图

```mermaid
graph TD
    P[孕妇 Patient<br/>统一锚点]

    subgraph 分析模型本体
      O[观测值 Observation]
      I[指标 Indicator]
      R[规则 Rule]
      RK[风险 Risk]
    end

    subgraph 知识库本体
      G[临床指南 Guideline]
      IR[指标释义]
      IK[干预知识]
    end

    subgraph 个案管理师体制本体
      CM[个案管理师]
      CASE[个案 Case]
      CP[照护计划]
      IV[干预 Intervention]
      AL[预警 Alert]
    end

    P --> O
    P --> CASE
    O -->|同一指标ID| I
    I -->|同一指标ID| IR
    R -->|阈值依据/同一指南ID| G
    O --> R --> RK
    RK -->|同一风险ID| AL
    RK -->|同一风险ID| IK
    AL --> CM --> CP --> IV
    IV -->|内容来自/同一干预ID| IK
    P -.日常查询.-> G
    P -.日常查询.-> IR
```

> 这张图体现"三本体合一"：孕妇产生的每个观测值，自动经规则与知识库阈值判定为风险，风险同时驱动**管理动作（预警→个案管理师→计划→干预）**并关联**知识库干预内容**，孕妇还能直接查询同一知识库。数据一次录入、全链路复用。

## 四、数据融合的四个层次

| 层次 | 内容 | 说明 |
|------|------|------|
| 1. 标识融合 | 统一ID与编码标准 | 三本体引用同一实体，消除"同物异名" |
| 2. 模式融合 Schema | 统一数据模型/本体定义 | 用一套 Ontology/知识图谱统一描述实体与关系 |
| 3. 数据融合 Instance | 多源数据归一 | 多设备、多次测量、多来源知识归并到同一实体下 |
| 4. 语义融合 Semantic | 跨本体推理 | 可沿"观测→风险→干预→知识"链做联合推理与解释 |

## 五、多源数据的融合策略

- **设备多指标融合**：同一孕妇多台/多次设备数据，按 `孕妇ID + 指标ID + 时间戳` 归一为统一时间序列，便于趋势分析。
- **知识多来源融合**：自有内容 + 权威出版物 + 网络权威资料，统一为知识条目并标注来源与权威级别；冲突时按权威级别仲裁。
- **风险多规则融合**：一个风险可能由多条规则/多项指标共同支持，融合时记录所有触发依据与置信度，保证可解释。
- **时间维度融合**：所有数据按**孕周时间轴**对齐，使指标趋势、风险演变、干预效果可在同一时间线上比对。

## 六、融合的落地建议

1. 先建立**统一术语表 / 指标字典**（待运营方提供设备指标清单后落定编码）。
2. 以**知识图谱 / 本体库**作为融合载体，承载三本体的实体与关系。
3. 分析规则、知识条目、管理动作均通过**共享ID**引用同一实体，禁止各模块私自定义。
4. 全链路保留 `Provenance`（来源—观测—规则—指南—处置人），支撑可追溯与合规。

---

# 附录三：孕妇本体（以时间进程为主轴的纵向聚合本体）

> 目标：构建一个**以孕妇为唯一锚点、以孕周时间轴为主轴**的纵向本体（Longitudinal Patient Ontology）。把这名孕妇的静态属性、动态数据、指标、规则、风险、干预、管理动作与知识引用，全部按"时间进程"汇集到同一条时间线上，形成"一人一档、随孕周生长"的活体档案。
>
> 这是前述"三大本体数据融合"在**单个孕妇维度**上的实例化：所有数据通过 `孕妇ID + 孕周/时间戳` 聚合，可回放任意时刻的健康全貌与风险演变。

## 一、本体分层结构

孕妇本体由"一个恒定核 + 一条时间轴 + 多条挂接数据流"组成：

```
孕妇本体 Patient Ontology
├── ① 静态身份层（恒定属性，孕期内基本不变）
├── ② 时间主轴层（孕周时间线 + 关键节点）
└── ③ 时序挂接层（随时间生长的动态数据，全部挂到时间轴上）
      ├── 观测值流 Observations
      ├── 指标趋势 Indicator Trends
      ├── 风险演变 Risk Evolution
      ├── 预警事件 Alerts
      ├── 干预与管理动作 Interventions / Case Actions
      └── 知识引用 Knowledge References
```

## 二、① 静态身份层（恒定属性）

| 属性 | 示例/说明 |
|------|-----------|
| 孕妇ID | 全局唯一锚点 |
| 基本信息 | 年龄、身高、孕前体重、BMI |
| 孕产史 | 孕次、产次、既往不良孕产史 |
| 既往病史 | 高血压、糖尿病、甲状腺疾病等基础疾病 |
| 家族史 | 糖尿病、高血压、遗传病家族史 |
| 本次妊娠基线 | 末次月经(LMP)、预产期(EDD)、受孕方式、单/多胎 |
| 风险基线 | 入组初始风险分层（高龄、既往 GDM 妊娠期糖尿病 / PIH 妊娠期高血压史等） |

> 静态层决定**初始风险基线**与个性化阈值（如高龄、既往妊娠期糖尿病史者监测更严）。

## 三、② 时间主轴层（孕周时间线）

以**预产期/末次月经**推算孕周（Gestational Week），划分标准分期，并标注关键时间节点：

| 分期 | 孕周 | 阶段意义 |
|------|------|----------|
| 孕早期 | 0–13 周 | 建档、基线评估、早期风险筛查 |
| 孕中期 | 14–27 周 | GDM 筛查窗口、结构监测、稳定监管期 |
| 孕晚期 | 28–40+ 周 | 高血压/子痫前期高发、胎儿监护强化 |
| 产后 | 分娩后 | 转归评估、产后随访、计划转出 |

> 时间轴是本体主键之一：所有动态数据均带 `时间戳/对应孕周`，可按时间轴回放、对齐、比对。

## 四、③ 时序挂接层（随时间生长的动态数据）

下表展示各孕期挂接到时间轴上的核心内容（具体指标与阈值待医生/设备清单确认）：

| 孕期 | 重点监测指标 | 主要风险 | 监测频率（示例）| 管理动作 |
|------|-------------|----------|----------------|----------|
| 孕早期 | 血压、基础血糖、维生素D、基础生化 | 基础病恶化、营养缺乏 | 较低频 | 建档、基线评估、健康教育 |
| 孕中期 | 血糖（GDM筛查）、血压、体重、维生素D | 妊娠期糖尿病 GDM | 中频 | 风险分层调整、饮食/运动指导 |
| 孕晚期 | 血压、血糖、胎动/胎心、体重 | 妊娠期高血压/子痫前期 | 高频 | 强化监测、预警处置、必要转诊 |
| 产后 | 血压、血糖恢复、营养 | 产后高血压/血糖未恢复 | 随访 | 转归评估、随访、计划转出 |

## 五、纵向聚合数据模型（概念）

每条动态数据都是挂在时间轴上的"节点"，统一结构如下：

```
TimelineEntry {
  孕妇ID
  时间戳 / 孕周
  类型: 观测值 | 风险 | 预警 | 干预 | 管理动作 | 知识引用
  关联实体ID: 指标ID / 风险ID / 干预ID / 指南ID
  数值 / 状态
  来源 Provenance: 设备 / 规则 / 个案管理师 / 知识库
  关联个案管理流程阶段: 评估/分层/计划/监测/评价
}
```

> 由此，孕妇本体 = 静态核 + 一串按时间排序的 TimelineEntry。任取一个孕周即可还原当时的指标值、风险等级、正在执行的计划与依据。

## 六、时序规则（Temporal Rules）—— 时间进程带来的分析能力

把数据按时间汇集后，分析不再局限于"单点超标"，而能做**纵向时序判断**：

- **趋势规则**：血压/血糖连续多次上升 → 即使未超阈值也预警。
- **变化率规则**：体重短期内异常增长 → 子痫前期风险信号。
- **孕周适配规则**：同一数值在不同孕周判定不同（阈值随孕周动态切换）。
- **跨期对比**：本期指标与基线/上期对比，评估干预效果。
- **依从性时序**：监测中断/漏测的时间分布，触发提醒。

## 七、孕妇本体时间轴视图

```mermaid
timeline
    title 孕妇本体：按时间进程聚合
    建档(孕早期 0-13w) : 静态基线录入 : 初始风险分层 : 基础指标采集
    孕中期(14-27w) : GDM血糖筛查 : 血压/维生素D监测 : 风险分层调整 : 饮食运动干预
    孕晚期(28-40w) : 血压强化监测 : 子痫前期预警 : 胎动胎心跟踪 : 高风险人工介入
    产后 : 指标恢复评估 : 产后随访 : 转归与计划转出
```

```mermaid
graph LR
    PID[孕妇ID + 静态身份层] --> T[孕周时间主轴]
    T --> E1[孕早期 Entries]
    T --> E2[孕中期 Entries]
    T --> E3[孕晚期 Entries]
    T --> E4[产后 Entries]
    E1 -.观测/风险/干预/知识.-> DATA[(统一TimelineEntry)]
    E2 -.观测/风险/干预/知识.-> DATA
    E3 -.观测/风险/干预/知识.-> DATA
    E4 -.观测/风险/干预/知识.-> DATA
```

## 八、与三大本体的对应关系

| 孕妇本体的层 | 来自哪个本体 |
|--------------|--------------|
| 静态身份层、初始分层 | 个案管理师体制（评估/分层）|
| 观测值、指标、规则、风险 | 分析模型本体 |
| 干预内容、指标释义、指南依据 | 知识库本体 |
| 预警处置、照护计划、随访转出 | 个案管理师体制（计划/监测/评价）|

> 即：孕妇本体是三大本体在**一个人 + 一条时间轴**上的汇流点，实现"全部内容按时间进程汇集"。

## 九、待确认项

1. 孕周阈值的**动态切换标准**（各期各指标的正常范围）。
2. 各期**监测频率**的实际设定（示例频率需医生确认）。
3. 静态层中纳入哪些**风险基线因子**用于个性化阈值。
4. 时序规则中"趋势/变化率"的具体判定参数。

---

# 附录四：AI 能力本体（AI 如何嵌入三大本体）

> 目标：把正文"AI 的核心定位（系统灵魂）"在本体层落地。AI 不是独立模块，而是**贯穿个案管理师体制、分析模型、知识库、孕妇本体的能力层**，通过人机协同支撑个案管理师达到最高管理水平。本附录定义 AI 的能力实体、与各本体的嵌入关系，以及人机协同的边界。

## 一、AI 能力实体（AI Capability Entities）

| AI 能力 | 对应实体 | 输入 | 输出 | 嵌入的本体 |
|---------|----------|------|------|-----------|
| 交互中枢 | 会话 Conversation / 交互事件 Interaction | 各方提问、指令 | 应答、路由、协同动作 | 贯穿全部（人、孕妇、设备入口）|
| 知识库服务 | 智能问答 QA Session | 自然语言问题 + 知识库 | 带溯源的专业解答 | 知识库本体 |
| 健康分析 | 分析任务 Analysis Task | 观测值 + 规则/指南 | 风险 Risk + 预警 Alert | 分析模型本体 |
| 趋势预测 | 预测 Prediction | 纵向时序数据（孕妇本体）| 未来走向/概率/预后 | 分析模型本体 + 孕妇本体 |
| 管理支持 | 决策建议 Recommendation | 风险/预测/计划现状 | 计划建议、处置辅助 | 个案管理师体制本体 |

## 二、AI 在分析推理链中的位置

在原"采集→风险→干预"链上显式标出 AI 与人的分工：

```
设备采集 → 观测值
   → [AI·健康分析] 规则/指南比对 → 风险 Risk + 预警 Alert
      → [AI·趋势预测] 基于时序数据 → 预测 Prediction
         → [AI·管理支持] 生成决策建议 Recommendation
            → 个案管理师审核与决策（人）  ← 人机协同关键节点
               → 照护计划/干预（AI 辅助执行：提醒、随访、教育）
                  → [AI·交互中枢] 与孕妇/医生交互、答疑、关怀
                     → 随访复测 → 闭环
```

> 原则：**AI 负责全量处理、分析、预测与建议；个案管理师/医生负责判断与决策；高风险必须由人确认（医生兜底）**。

## 三、人机协同模型（Human-AI Collaboration）

| 环节 | AI 承担 | 人（个案管理师/医生）承担 |
|------|---------|--------------------------|
| 数据处理与分析 | 全量、实时 | 抽检、校准 |
| 风险识别 | 自动推断 + 置信度 | 复核异常与低置信结论 |
| 趋势预测 | 模型预测 | 临床判断与采纳 |
| 计划与干预 | 生成建议、执行提醒 | 审核、确认、个性化调整 |
| 高风险处置 | 预警、辅助 | **决策主体（兜底）** |
| 日常交互/关怀 | 主力（问答、教育、陪伴）| 必要时介入 |

## 四、AI 嵌入四大本体的关系图

```mermaid
graph TD
    subgraph AI 能力层
      AICONV[交互中枢 Conversation]
      AIQA[知识库服务 QA]
      AIANA[健康分析 Analysis]
      AIPRED[趋势预测 Prediction]
      AIREC[管理支持 Recommendation]
    end

    PATIENT[孕妇本体<br/>纵向时序数据] --> AIANA
    PATIENT --> AIPRED
    KB[知识库本体] --> AIQA
    KB --> AIANA
    AIANA --> RISK[分析模型: 风险/预警]
    AIPRED --> RISK
    RISK --> AIREC
    AIREC --> CM[个案管理师 人]
    CM -->|决策/兜底| PLAN[体制本体: 照护计划/干预]
    AICONV -->|答疑/关怀/协同| CM
    AICONV -->|答疑/教育/陪伴| MOM[孕妇 / 各方]
    PLAN --> PATIENT
```

> 这张图体现"AI 是贯穿四大本体的能力层"：AI 从孕妇本体与知识库取数，做分析与预测，产出建议交个案管理师决策，并作为交互中枢服务各方——人机协同形成完整闭环。

## 五、AI 约束与待确认项

### 5.1 AI 关键约束（必须遵守）

- **防幻觉**：所有医学问答与建议采用 **RAG（检索增强）+ 强制溯源**，只能基于知识库内容作答，**禁止模型自由生成超纲医学建议**；无依据时应明确"无法回答/建议咨询医生"。
- **可解释与留痕**：AI 的每条风险/预测/建议都须可解释、可追溯（依据哪些数据与知识），全程留痕以支撑合规与责任界定。
- **冷启动**：自有数据不足时，分析**先用规则引擎**，趋势预测待数据积累后引入；模型须经**回顾性验证 → 前瞻性验证**方可上线。
- **医生兜底**：高风险结论与急症一律由人确认，AI 不替代临床决策。

### 5.2 待确认项

1. 各 AI 能力的**自动化程度边界**（哪些可自动执行、哪些必须人工确认）。
2. 趋势预测的**目标与可用数据**（预测哪些结局、需要多长时间序列）。
3. 交互中枢面向不同角色（孕妇/管理师/医生）的**权限与话术边界**。
4. AI 建议的**可解释性与留痕**要求（合规与责任界定）。

---

# 附录五：关键风险、合规与待验证假设

> 说明：本附录汇集决定项目基本盘的高优先风险与必须尽早确认的假设。这些问题若不提前定调，后续立项与开发会反复返工，且可能触及合规红线。**建议在搭建原型前优先澄清第一、二节。**

## 一、监管定位（最高优先）

- **核心问题**：本系统是否构成**医疗器械软件（SaMD）**？在中国，软件若对疾病做出诊断或直接影响临床判断的输出，可能触发 **NMPA 二类/三类医疗器械注册**（周期长、成本高）。
- **建议定位**：明确为 **"健康管理 / 临床决策支持"，而非"诊断"**。系统提供提示、建议与监测，**临床判断与诊断始终归医生**。这样可将监管等级与责任风险降到最低，并与"医生兜底"原则一致。
- **宣传合规**：对外不得宣称"诊断、治疗、治愈"，遵守《广告法》与医疗宣传规定。
- **诊疗资质**：若涉及医生在线开方/诊断，需相应**互联网医院/诊疗资质**。

## 二、数据合规与隐私（最高优先）

- 孕产妇健康数据 + 胎儿信息属**最敏感个人信息**，受 **《个人信息保护法》《数据安全法》《健康医疗大数据管理办法》** 约束。
- 必备措施：**知情同意、最小化采集、加密存储与传输、分级访问权限、留存与删除策略、数据出境限制、审计日志**。
- 设立**数据合规责任人（DPO）**，建立数据处理记录与安全事件响应机制。

## 三、设备能力待验证假设（关键技术尽调）

- **假设**：运营方称居家检测设备"可采集数十种指标，维生素D、血糖等都能测"。
- **风险**：血糖、糖化血红蛋白、维生素D 等**生化指标通常需采血/实验室检测**，居家设备能否真正测量、精度如何、是否为 **NMPA 认证的医疗级设备**（而非消费级），直接决定分析模型的输入可信度。
- **行动**：在搭原型前，务必取得设备的 **「可测指标清单 + 测量原理 + 精度/误差 + 认证资质 + 数据接口规范」**。若实际仅能测血压/体重/心率等少数项，需重估分析模型与产品范围。

## 四、数据质量与可信度

- 居家自测存在**测量误差、操作/佩戴错误、数据缺失、甚至造假**风险。
- 需建立**数据质控层**：合理性校验（plausibility check）、异常值过滤、缺失处理、设备校准、来源标记。
- 低质量/缺失数据不得直接驱动高风险结论。

## 五、临床安全（Red Flag 急症机制）

- 标准个案管理循环适用于常规节奏，**急症必须旁路升级**。
- 配置**红旗规则库**：如子痫前期急症（高血压 + 剧烈头痛 + 视物模糊 + 上腹痛）、胎动消失、阴道大量出血、严重低/高血糖等，**直接触发"立即就医/转急诊" + 通知医生**，绕过常规流程。
- 明确**误报/漏报责任边界**与处置 SLA。

## 六、AI 特有风险

- **幻觉**：医学问答须 RAG + 溯源 + 不超纲（见附录四 5.1）。
- **偏差与代表性**：训练/规则需覆盖不同孕妇人群，避免系统性偏差。
- **可解释性**：高风险建议必须可解释、可追溯，便于医生复核与责任界定。

## 七、伦理与体验

- 持续监测与频繁预警可能**加重孕妇焦虑**，违背"完美孕期体验"目标。
- 交互设计须**有温度、分级提醒、避免过度医疗化**；预警措辞需经设计，避免制造恐慌。

## 八、风险优先级总览

| 优先级 | 风险/假设 | 不解决的后果 |
|--------|-----------|--------------|
| 🔴 最高 | 监管定位（SaMD 与否）| 触发器械注册，方向性返工 |
| 🔴 最高 | 设备实际可测能力 | 分析模型输入失真，构想落空 |
| 🔴 最高 | 数据合规与隐私 | 法律风险、无法上线 |
| 🟠 高 | 红旗急症机制 | 临床安全事故 |
| 🟠 高 | 数据质量质控 | 误判、信任崩塌 |
| 🟡 中 | AI 幻觉/可解释 | 错误建议、责任纠纷 |
| 🟡 中 | 焦虑/体验 | 用户流失、口碑受损 |