基于鸿蒙OS开发静脉输液智能监控系统（12）-医疗费用管理与医保报销计算

1. 中国医疗保险制度概述

1.1 三大基本医疗保险体系

中国现行基本医疗保险制度由三大体系构成，分别覆盖不同人群，在报销比例、起付线、封顶线等核心参数上存在显著差异。IVGuard 项目的医保报销计算模块需要准确理解这些制度差异，才能为用户提供有意义的费用估算。

1.1.1 城镇职工医疗保险（urban_worker）

城镇职工基本医疗保险（以下简称"职工医保"）是我国最早建立、保障水平最高的基本医疗保险制度，覆盖对象为城镇在职职工和退休人员。该制度由用人单位和职工共同缴费，单位缴费率一般为职工工资总额的6%左右，职工个人缴费率为本人工资收入的2%左右。职工医保设有个人账户和统筹基金两个账户：个人账户主要用于门诊费用和药店购药，统筹基金主要用于住院费用。

职工医保的核心优势在于：

• 报销比例高：三级医院住院报销比例通常可达80%-90%，远高于居民医保
• 起付线相对合理：以北京为例，三级医院住院起付线为1300元，二级医院为800元
• 封顶线高：年度最高支付限额普遍在40万-60万元，部分地区叠加大病保险后可达百万级别
• 退休人员优惠：多数地区对退休人员给予额外5%-10%的报销比例提升

在 IVGuard 中，职工医保对应的 insuranceType 编码为 'urban_worker'，是系统支持的默认参保类型。当用户选择该类型后，系统将自动应用职工医保的报销参数进行计算。

1.1.2 城镇居民医疗保险（urban_resident）

城镇居民基本医疗保险（以下简称"居民医保"）主要覆盖城镇非从业居民，包括未成年人、老年人、残疾人以及其他不符合职工医保参保条件的城镇居民。该制度采取个人缴费与政府补贴相结合的方式，2023年个人缴费标准约为350-380元/年，各级财政补助不低于610元/年。

居民医保的特点：

• 报销比例较低：三级医院住院报销比例通常为60%-70%，比职工医保低10-20个百分点
• 起付线与职工医保相近或略低：部分地区居民医保起付线与职工医保一致，部分地区略低
• 封顶线较低：年度最高支付限额通常在20万-40万元
• 无个人账户：居民医保不设个人账户，所有费用均通过统筹基金支付
• 门诊统筹：部分地区建立了门诊统筹制度，但报销比例较低（50%左右）

在 IVGuard 中，居民医保对应的 insuranceType 编码为 'urban_resident'。选择该类型后，系统将自动降低报销比例参数。

1.1.3 新型农村合作医疗（rural）

新型农村合作医疗（以下简称"新农合"）是为保障农民基本医疗需求而建立的医疗保障制度。2016年起，国务院要求整合城镇居民医保和新农合，建立统一的城乡居民基本医疗保险制度。但在实际操作中，部分省份尚未完全整合，因此 IVGuard 仍保留了 'rural' 这一参保类型。

新农合（或城乡居民医保）的特点：

• 报销比例最低：三级医院住院报销比例通常为50%-65%
• 起付线因地区差异大：经济发达地区起付线较高，欠发达地区较低
• 封顶线较低：年度最高支付限额通常在15万-30万元
• 异地就医报销比例降低：非转诊异地就医报销比例通常下降10%-20%
• 大病保险叠加：超过基本医保封顶线后可进入大病保险，报销比例不低于50%

在 IVGuard 中，新农合对应的 insuranceType 编码为 'rural'。系统目前将 'rural' 归入居民医保逻辑分支，使用居民医保的报销参数进行计算，这在多数已整合省份是合理的近似处理。

1.2 三类医保报销比例和起付线差异对比

参数	城镇职工	城镇居民	新农合/城乡居民
三级医院住院报销比例	80%-90%	60%-70%	50%-65%
二级医院住院报销比例	85%-92%	65%-75%	55%-70%
一级医院住院报销比例	90%-95%	75%-85%	65%-80%
三级医院起付线	800-1600元	800-1600元	500-1500元
二级医院起付线	500-1000元	500-1000元	300-800元
一级医院起付线	200-500元	200-500元	100-400元
年度封顶线	40-60万元	20-40万元	15-30万元

从上表可以看出，医院等级对报销比例有显著影响——等级越低的医院报销比例越高。这一政策设计的初衷是引导患者合理就医，避免大医院过度拥挤。在 IVGuard 中，医院等级通过 hospitalLevel 参数（取值 'level3'/'level2'/'level1'）体现，并直接影响 getOtherReimbursableRate() 函数的返回值。

1.3 基本医疗保险药品目录

国家医保药品目录是医保报销计算的核心依据。现行目录将药品分为三类：

甲类药品（class_a）

甲类药品是临床治疗必需、使用广泛、疗效确切、同类药品中价格或治疗费用较低的药品。甲类药品的特点：

• 全额纳入报销基数：甲类药品费用100%计入可报销金额
• 按标准比例报销：不设先自付比例，直接按照参保类型的报销比例计算
• 目录稳定性高：甲类药品调整频率低，通常为疗效确切的经典药物
• 常见甲类药品示例：氯化钾注射液、葡萄糖注射液、生理盐水、头孢唑林钠等基础输液和抗生素

在 IVGuard 中，甲类药品对应 insuranceCategory 值为 'class_a'。系统通过 IVDrugDatabase.getById() 查询药品信息后，根据此字段将药品费用归入 classADrugCost 进行计算。

乙类药品（class_b）

乙类药品是可供临床治疗选择使用、疗效确切、同类药品中比甲类药品价格或治疗费用略高的药品。乙类药品的特点：

• 部分纳入报销基数：需先自付一定比例（通常10%-15%），剩余部分按标准比例报销
• 先自付比例因地区而异：同一药品在不同省市的先自付比例可能不同
• 目录调整较频繁：乙类药品目录每年动态调整，新增创新药通常先进入乙类
• 常见乙类药品示例：奥美拉唑注射剂、头孢呋辛钠、氨溴索注射液等

在 IVGuard 中，乙类药品对应 insuranceCategory 值为 'class_b'。药品费用归入 classBDrugCost 计算。需要注意：当前 IVGuard 版本尚未实现乙类药品先自付比例的计算，这是一个已知的简化处理，将在后续版本中完善。

自费药品（self_pay）

自费药品是不在医保目录范围内的药品，医保不予报销，需患者全额自付。包括：

• 非目录药品：未纳入国家或地方医保目录的药品
• 限制使用药品超适应症使用：目录内药品但超出了医保限定支付范围
• 特需药品：部分进口高价药、新型靶向药等
• 常见自费药品示例：部分进口营养液、高端免疫调节剂等

在 IVGuard 中，自费药品对应 insuranceCategory 值为 'self_pay'，其费用归入 selfPayDrugCost。这部分金额在报销计算中不产生任何报销额度，完全由患者承担。

1.4 药品目录在 IVGuard 中的实现

IVGuard 通过 IVDrugDatabase 模块维护静脉注射药品数据库，每条药品记录包含 insuranceCategory 字段用于医保分类。数据初始化流程如下：

IVDrugDatabase.init()

该初始化操作加载预定义的药品数据，包括药品名称、规格、单价以及医保类别。通过 getById() 方法查询药品详情：

const drugInfo = IVDrugDatabase.getById(item.drugId)
if (drugInfo !== undefined) {
  if (drugInfo.insuranceCategory === 'class_a') {
    // 甲类药品处理
  } else if (drugInfo.insuranceCategory === 'class_b') {
    // 乙类药品处理
  } else {
    // 自费药品处理
  }
}

当药品ID在数据库中未找到时（drugInfo === undefined），系统默认将其归入自费药品类别，确保计算的保守性——宁可将未知药品归为自费，也不错误地给予报销额度。

---

2. 报销计算模型

2.1 核心概念

IVGuard 的医保报销计算模型围绕以下五个核心概念构建，每个概念都有明确的数学定义和业务含义。

起付线（deductible）

起付线是医保基金开始支付的门槛金额。患者发生的医疗费用低于起付线时，医保基金不予报销，全部由患者自付；超过起付线的部分才进入报销计算。

起付线的政策设计目的：

1. 抑制小病大治：提高患者对小额医疗费用的敏感度，避免因"反正医保报销"而过度就医
2. 减少管理成本：免除医保基金对大量小额报销的审核和处理成本
3. 保障大病风险：将有限基金集中用于保障大额医疗费用

在 IVGuard 中，起付线通过 InsurancePolicy.deductible 字段表示，单位为元。以北京职工医保为例：

• 三级医院住院起付线 = 1300元
• 二级医院住院起付线 = 800元
• 一个年度内第二次及以后住院，起付线降低50%

注意：IVGuard 当前版本未实现年度多次住院起付线递减的逻辑，每次计算均使用首次住院起付线。

报销比例（classARate / classBRate）

报销比例是医保基金支付可报销费用的百分比。IVGuard 区分甲类药品和乙类药品的报销比例，通过 InsurancePolicy 的 classARate 和 classBRate 两个百分比值分别表示。

报销比例的影响因素：

1. 参保类型：职工医保 > 居民医保 > 新农合
2. 医院等级：一级医院 > 二级医院 > 三级医院
3. 药品类别：甲类药品报销比例通常高于乙类药品5-10个百分点
4. 人员类别：退休人员通常比在职人员高5-10个百分点

例如，北京职工医保在三级医院的报销比例为：

• 甲类药品报销比例 = 85%
• 乙类药品报销比例 = 80%

这意味着：100元甲类药品费用中，85元由医保支付，15元由患者自付；100元乙类药品费用中，80元由医保支付，20元由患者自付。

封顶线（ceiling）

封顶线是医保基金年度最高支付限额。当累计报销金额达到封顶线后，超出部分不再由基本医保支付，需通过大病保险、商业保险或个人自付解决。

封顶线的设定原则：

1. 与当地经济发展水平挂钩：经济发达地区封顶线较高
2. 与缴费水平相匹配：职工医保缴费高，封顶线也高
3. 保障基本医疗需求：覆盖大多数常见病的治疗费用

在 IVGuard 中，封顶线通过 InsurancePolicy.ceiling 字段表示。例如：

• 北京职工医保封顶线 = 500,000元
• 成都职工医保封顶线 = 400,000元

自费金额（selfPay）

自费金额是患者最终需要自己承担的费用，计算公式为：

selfPay = totalCost - reimbursable

其中 totalCost 是全部费用之和，reimbursable 是医保实际报销金额。自费金额是 IVGuard 用户最关心的输出指标，它直接影响患者的经济负担。

自费金额的构成包括：

1. 起付线以下部分：未达起付线的全部费用
2. 按比例自付部分：医保报销比例之外的差额部分
3. 自费药品/项目：完全不在医保目录范围内的费用
4. 超封顶线部分：超过年度封顶线的费用

医保类别与报销基数

"报销基数"是计算报销金额的基础金额。不同医保类别纳入报销基数的方式不同：

费用类别	纳入报销基数方式	IVGuard 处理
甲类药品	100%纳入	classADrugCost × classARate / 100
乙类药品	扣除先自付后纳入*	classBDrugCost × classBRate / 100
自费药品	不纳入	不参与报销计算
其他费用(诊疗/护理等)	按医院等级比例纳入	otherCost × otherRate / 100

* 当前版本简化处理，未扣除先自付比例

2.2 自费金额计算公式推导

IVGuard 的报销计算遵循以下数学模型。本节将详细推导每一步计算过程，揭示从原始费用到最终自费金额的完整计算链路。

第一步：费用分类累加

给定一组费用条目 items: CostItem[]，首先将每项费用按其医保类别归入对应的累加器：

totalCost = Σ(item.totalPrice)                    // 总费用
drugCost = Σ(item.totalPrice | item.isDrug)       // 药品费用
otherCost = Σ(item.totalPrice | !item.isDrug)     // 非药品费用
classADrugCost = Σ(item.totalPrice | drug.insuranceCategory === 'class_a')
classBDrugCost = Σ(item.totalPrice | drug.insuranceCategory === 'class_b')
selfPayDrugCost = Σ(item.totalPrice | drug.insuranceCategory === 'self_pay')

分类逻辑的决策树：

对于每个 item:
├── item.isDrug === true
│   ├── drugInfo.insuranceCategory === 'class_a' → classADrugCost
│   ├── drugInfo.insuranceCategory === 'class_b' → classBDrugCost
│   ├── drugInfo.insuranceCategory === 'self_pay' → selfPayDrugCost
│   └── drugInfo === undefined → selfPayDrugCost (保守处理)
└── item.isDrug === false
    └── otherCost

第二步：计算各类别报销金额

各类别报销金额的计算公式：

classAReimbursable = classADrugCost × classARate / 100
classBReimbursable = classBDrugCost × classBRate / 100
otherReimbursable = otherCost × otherRate / 100

这三个公式遵循相同的模式：类别费用 × 该类别报销比例 / 100。其中 classARate、classBRate 来自 InsurancePolicy，otherRate 由 CostService.getOtherReimbursableRate() 根据 insuranceType 和 hospitalLevel 动态计算。

第三步：汇总并扣除起付线

totalReimbursable = classAReimbursable + classBReimbursable + otherReimbursable
totalReimbursable = totalReimbursable - deductible

起付线的扣除逻辑：将各类别报销金额加总后，统一扣除起付线。这意味着甲类、乙类和其它费用的报销额度可以"合并"用于冲抵起付线，而非分别扣除。这符合实际医保政策的处理方式——起付线是针对单次住院总费用的门槛，而非按类别分别设置。

第四步：边界条件处理

if (totalReimbursable < 0) totalReimbursable = 0
if (totalReimbursable > ceiling) totalReimbursable = ceiling

两个边界条件：

1. 负值截断：当各类别报销金额之和小于起付线时，totalReimbursable 会变为负数。此时将其截断为0，意味着医保不予报销，全部费用自付。
2. 封顶线限制：当报销金额超过封顶线时，将其截断至封顶线，意味着超出部分医保不再支付。

第五步：计算自费金额

selfPay = totalCost - totalReimbursable
if (selfPay < 0) selfPay = 0

最终自费金额 = 总费用 - 医保报销金额。由于 totalReimbursable 已经经过了起付线扣除和封顶线限制，selfPay 的计算结果已经包含了所有自费因素。最后的负值截断是防御性编程，正常情况下 totalReimbursable 不应超过 totalCost，但在浮点数运算中可能出现微小偏差。

完整公式总结

将以上步骤合并为单一表达式：

selfPay = totalCost - min(max(
  classADrugCost × classARate/100 + 
  classBDrugCost × classBRate/100 + 
  otherCost × otherRate/100 - 
  deductible, 
0), ceiling)

其中 min(max(x, 0), ceiling) 实现了"先截断至非负，再限制在封顶线以下"的双重约束。

2.3 其他费用报销比例推断

IVGuard 中的"其他费用"指非药品费用，包括护理费、诊疗费、床位费、检查费等。这类费用的报销比例不由 InsurancePolicy 直接存储，而是通过 CostService.getOtherReimbursableRate() 函数根据参保类型和医院等级动态推断。

推断规则

推断规则基于国家医保政策的通行标准设定：

城镇职工医疗保险（urban_worker）：

• 三级医院（level3）：80%
• 二级医院（level2）：85%
• 一级医院（level1）：90%

城镇居民医疗保险（urban_resident）：

• 三级医院（level3）：65%
• 二级医院（level2）：70%
• 一级医院（level1）：80%

新型农村合作医疗（rural）：

• 沿用居民医保比例（因多数省份已整合）

代码实现

static getOtherReimbursableRate(policy: InsurancePolicy): number {
  if (policy.insuranceType === 'urban_worker') {
    if (policy.hospitalLevel === 'level3') {
      return 80
    } else if (policy.hospitalLevel === 'level2') {
      return 85
    } else {
      return 90
    }
  } else {
    if (policy.hospitalLevel === 'level3') {
      return 65
    } else if (policy.hospitalLevel === 'level2') {
      return 70
    } else {
      return 80
    }
  }
}

设计考量

1. 为什么不在 InsurancePolicy 中存储 otherRate？ 因为 otherRate 完全可以由 insuranceType 和 hospitalLevel 两个已有字段推导得出，无需让用户手动输入。这减少了 InsuranceSetupPage 的配置步骤数，降低了用户出错的可能性。

2. 为什么职工医保一级医院报销比例是90%而非更高？ 90%是目前多数城市的实际上限。虽然部分城市对退休人员在一级医院可达95%，但 IVGuard 采用保守值，避免过度估算报销额度。

3. 为什么居民医保一级医院是80%？ 居民医保在一级医院的报销比例各地差异较大（75%-85%），80%是较为居中的取值。

4. 为什么 rural 归入居民医保分支？ 截至2024年底，全国绝大多数省份已完成城镇居民医保和新农合的整合，建立统一的城乡居民医保制度。因此将 rural 使用居民医保参数是合理的近似。

---

3. CostService 计算引擎（81行代码）

CostService 是 IVGuard 医疗费用计算的核心引擎，全部逻辑仅81行代码，却承载了从费用分类、报销计算到结果汇总的完整流程。这种简洁性源于清晰的计算模型设计和合理的数据结构抽象。

3.1 calculateSummary 算法详解

calculateSummary 是 CostService 的唯一静态方法，接收费用条目数组和医保策略两个参数，返回完整的费用汇总对象。

方法签名

static calculateSummary(items: CostItem[], policy: InsurancePolicy): CostSummary

完整算法流程

static calculateSummary(items: CostItem[], policy: InsurancePolicy): CostSummary {
  const summary = CostSummary.create()
  IVDrugDatabase.init()
  
  // 第一步：累加总费用和分类费用
  for (let i = 0; i < items.length; i++) {
    const item = items[i]
    summary.totalCost += item.totalPrice
    
    if (item.isDrug) {
      summary.drugCost += item.totalPrice
      const drugInfo = IVDrugDatabase.getById(item.drugId)
      if (drugInfo !== undefined) {
        if (drugInfo.insuranceCategory === 'class_a') {
          summary.classADrugCost += item.totalPrice
        } else if (drugInfo.insuranceCategory === 'class_b') {
          summary.classBDrugCost += item.totalPrice
        } else {
          summary.selfPayDrugCost += item.totalPrice
        }
      } else {
        summary.selfPayDrugCost += item.totalPrice
      }
    } else {
      summary.otherCost += item.totalPrice
    }
  }
  
  // 第二步：无医保策略时全部自费
  if (policy.insuranceType.length === 0) {
    summary.selfPay = summary.totalCost
    return summary
  }
  
  // 第三步：计算各类报销金额
  const classAReimbursable = summary.classADrugCost * policy.classARate / 100
  const classBReimbursable = summary.classBDrugCost * policy.classBRate / 100
  const otherReimbursableRate = CostService.getOtherReimbursableRate(policy)
  const otherReimbursable = summary.otherCost * otherReimbursableRate / 100
  
  // 第四步：扣除起付线，限制封顶线
  let totalReimbursable = classAReimbursable + classBReimbursable + otherReimbursable
  totalReimbursable = totalReimbursable - policy.deductible
  if (totalReimbursable < 0) totalReimbursable = 0
  if (totalReimbursable > policy.ceiling) totalReimbursable = policy.ceiling
  
  summary.reimbursable = totalReimbursable
  summary.selfPay = summary.totalCost - totalReimbursable
  if (summary.selfPay < 0) summary.selfPay = 0
  
  return summary
}

第一步详解：费用分类累加

这一步遍历所有费用条目，将每项费用按类别累加到 summary 对应字段。核心决策逻辑分为两级：

第一级：药品 vs 非药品

if (item.isDrug) {
  // 药品费用处理路径
} else {
  summary.otherCost += item.totalPrice
}

item.isDrug 是 CostItem 的布尔字段，标识该费用条目是否为药品。非药品费用直接累加到 otherCost，无需进一步分类。

第二级：药品医保类别分类

对于药品费用，通过 IVDrugDatabase.getById() 查询药品的医保类别，然后归入对应字段：

const drugInfo = IVDrugDatabase.getById(item.drugId)
if (drugInfo !== undefined) {
  if (drugInfo.insuranceCategory === 'class_a') {
    summary.classADrugCost += item.totalPrice
  } else if (drugInfo.insuranceCategory === 'class_b') {
    summary.classBDrugCost += item.totalPrice
  } else {
    summary.selfPayDrugCost += item.totalPrice
  }
} else {
  summary.selfPayDrugCost += item.totalPrice  // 保守处理
}

保守处理原则：当药品ID在数据库中未找到（drugInfo === undefined）时，将费用归入 selfPayDrugCost。这种处理方式遵循"宁可多算自费，不可虚增报销"的原则，避免因数据缺失而错误地给予报销额度。

分类累加完成后，summary 中各字段满足以下恒等式：

totalCost = drugCost + otherCost
drugCost = classADrugCost + classBDrugCost + selfPayDrugCost
totalCost = classADrugCost + classBDrugCost + selfPayDrugCost + otherCost

第二步详解：无医保策略快速返回

if (policy.insuranceType.length === 0) {
  summary.selfPay = summary.totalCost
  return summary
}

当用户未配置医保策略时（insuranceType 为空字符串），所有费用均为自费。这一步是一个短路优化，避免后续不必要的报销计算。同时，它也明确了业务语义：没有医保信息 = 全部自费。

判断条件使用 policy.insuranceType.length === 0 而非 !policy.insuranceType，是因为空字符串 '' 在 JavaScript 中是 falsy 值，两种写法效果相同，但 .length === 0 的意图更明确——我们检查的是字符串内容是否为空，而非变量是否存在。

第三步详解：各类别报销金额计算

const classAReimbursable = summary.classADrugCost * policy.classARate / 100
const classBReimbursable = summary.classBDrugCost * policy.classBRate / 100
const otherReimbursableRate = CostService.getOtherReimbursableRate(policy)
const otherReimbursable = summary.otherCost * otherReimbursableRate / 100

三个类别的报销金额计算公式结构统一：类别费用 × 报销比例 / 100。其中：

• classARate 和 classBRate 直接来自 InsurancePolicy，由用户在 InsuranceSetupPage 中配置
• otherRate 通过 getOtherReimbursableRate() 动态推断，无需用户手动设置

运算顺序：classADrugCost * policy.classARate / 100 而非 classADrugCost * (policy.classARate / 100)，两者在数学上等价，但前者的运算顺序从左到右，更符合阅读习惯。

第四步详解：起付线扣除与封顶线限制

let totalReimbursable = classAReimbursable + classBReimbursable + otherReimbursable
totalReimbursable = totalReimbursable - policy.deductible
if (totalReimbursable < 0) totalReimbursable = 0
if (totalReimbursable > policy.ceiling) totalReimbursable = policy.ceiling

这段代码实现了两个关键的边界约束：

1. 起付线扣除：从各类别报销金额之和中减去起付线。这意味着不同类别的报销额度可以"叠加"冲抵起付线——例如甲类药品报销20元 + 乙类药品报销30元 + 其他费用报销10元 = 60元，减去起付线50元 = 10元可报销。

2. 封顶线限制：如果报销金额超过封顶线，截断至封顶线。例如封顶线为50万元，计算得到报销60万元，则实际报销50万元。

负值截断的业务含义：当各类别报销金额之和小于起付线时，totalReimbursable 变为负数。这意味着本次费用未达到医保报销门槛，全部自费。截断为0后，selfPay = totalCost - 0 = totalCost，即全部费用由患者承担。

第五步详解：结果赋值

summary.reimbursable = totalReimbursable
summary.selfPay = summary.totalCost - totalReimbursable
if (summary.selfPay < 0) summary.selfPay = 0

最终将计算结果写入 summary 对象。selfPay 的负值截断是防御性编程——在理论上，由于 totalReimbursable 是各类别费用的一部分按比例计算而来，且不超过 totalCost 的 100%，因此 selfPay 不应为负。但在浮点数运算中可能出现 0.00001 级别的偏差，截断为0可避免显示异常。

3.2 计算示例

本节通过具体数字演示 calculateSummary 的完整计算过程，帮助理解算法的每一步变换。

示例场景

• 参保类型：城镇职工医保（urban_worker）
• 医院等级：三级医院（level3）
• 起付线：1300元
• 甲类报销比例：85%
• 乙类报销比例：80%
• 封顶线：500,000元

费用条目

序号	项目	类型	医保类别	单价(元)	数量	总价(元)
1	奥美拉唑	药品	乙类	68	2	136
2	氯化钾	药品	甲类	5	3	15
3	葡萄糖5%	药品	甲类	4.5	2	9
4	护理费	其他	-	30	1	30
合计						190

第一步：分类累加

totalCost = 136 + 15 + 9 + 30 = 190
drugCost = 136 + 15 + 9 = 160
otherCost = 30

奥美拉唑 → insuranceCategory = 'class_b' → classBDrugCost = 136
氯化钾   → insuranceCategory = 'class_a' → classADrugCost = 15
葡萄糖5% → insuranceCategory = 'class_a' → classADrugCost = 15 + 9 = 24

classADrugCost = 24
classBDrugCost = 136
selfPayDrugCost = 0

验证恒等式：classADrugCost + classBDrugCost + selfPayDrugCost = 24 + 136 + 0 = 160 = drugCost ✓

第二步：检查医保策略

insuranceType = 'urban_worker'，长度不为0，继续计算。

第三步：计算各类别报销金额

classAReimbursable = 24 × 85 / 100 = 20.4
classBReimbursable = 136 × 80 / 100 = 108.8
otherReimbursableRate = getOtherReimbursableRate('urban_worker', 'level3') = 80
otherReimbursable = 30 × 80 / 100 = 24

第四步：扣除起付线

totalReimbursable = 20.4 + 108.8 + 24 = 153.2
totalReimbursable = 153.2 - 1300 = -1146.8
totalReimbursable < 0 → totalReimbursable = 0

分析：虽然各类别报销金额合计为153.2元，但这远低于起付线1300元。因此，医保基金不予报销，全部费用由患者自付。这体现了起付线的"门槛"作用——只有当可报销金额超过起付线时，医保才开始支付。

第五步：计算自费金额

reimbursable = 0
selfPay = 190 - 0 = 190

最终结果：

• 总费用：190元
• 医保报销：0元
• 自费金额：190元

大额费用场景示例

继续上面的场景，假设患者住院产生了更多费用：

序号	项目	类型	医保类别	总价(元)
1	奥美拉唑	药品	乙类	136
2	氯化钾	药品	甲类	15
3	葡萄糖5%	药品	甲类	9
4	护理费	其他	-	30
5	头孢呋辛钠	药品	乙类	2400
6	CT检查费	其他	-	800
7	床位费	其他	-	500
8	手术费	其他	-	3000
合计				6890

分类累加：

classADrugCost = 24
classBDrugCost = 136 + 2400 = 2536
selfPayDrugCost = 0
otherCost = 30 + 800 + 500 + 3000 = 4330

报销计算：

classAReimbursable = 24 × 85% = 20.4
classBReimbursable = 2536 × 80% = 2028.8
otherReimbursable = 4330 × 80% = 3464
totalReimbursable = 20.4 + 2028.8 + 3464 = 5513.2
totalReimbursable = 5513.2 - 1300 = 4213.2
4213.2 < 500000 → 不触发封顶线
reimbursable = 4213.2
selfPay = 6890 - 4213.2 = 2676.8

最终结果：

• 总费用：6890元
• 医保报销：4213.2元
• 自费金额：2676.8元
• 报销率：61.1%

封顶线触发场景示例

假设年度累计费用已达极高金额：

classADrugCost = 50000
classBDrugCost = 200000
otherCost = 300000
totalCost = 550000

classAReimbursable = 50000 × 85% = 42500
classBReimbursable = 200000 × 80% = 160000
otherReimbursable = 300000 × 80% = 240000
totalReimbursable = 42500 + 160000 + 240000 = 442500
totalReimbursable = 442500 - 1300 = 441200
441200 < 500000 → 不触发封顶线（这次未触发）

但若继续累加，使得 totalReimbursable - deductible > 500000：

假设总报销额计算为 520000
520000 - 1300 = 518700
518700 > 500000 → totalReimbursable = 500000
selfPay = totalCost - 500000

此时超出封顶线的18,700元需要患者通过大病保险或自付解决。

居民医保对比示例

同样的190元费用，如果使用城镇居民医保（urban_resident）在三级医院：

起付线 = 1300元
甲类报销比例 = 75%
乙类报销比例 = 70%
otherRate = 65%

classAReimbursable = 24 × 75% = 18
classBReimbursable = 136 × 70% = 95.2
otherReimbursable = 30 × 65% = 19.5
totalReimbursable = 18 + 95.2 + 19.5 = 132.7
totalReimbursable = 132.7 - 1300 = -1167.3 → 0
selfPay = 190

同样未达起付线，全部自费。但注意即使在超过起付线的场景下，居民医保的报销金额也会比职工医保少约15%，这正是两种医保制度的差异所在。

不同医院等级对比示例

以职工医保为例，同样6890元的费用在不同等级医院的报销差异：

二级医院：

起付线 = 800元
甲类报销比例 = 85% (同三级)
乙类报销比例 = 80% (同三级)
otherRate = 85% (比三级高5%)

classAReimbursable = 24 × 85% = 20.4
classBReimbursable = 2536 × 80% = 2028.8
otherReimbursable = 4330 × 85% = 3680.5
totalReimbursable = 20.4 + 2028.8 + 3680.5 = 5729.7
totalReimbursable = 5729.7 - 800 = 4929.7
selfPay = 6890 - 4929.7 = 1960.3

一级医院：

起付线 = 500元 (假设)
甲类报销比例 = 85% (同三级)
乙类报销比例 = 80% (同三级)
otherRate = 90% (比三级高10%)

classAReimbursable = 24 × 85% = 20.4
classBReimbursable = 2536 × 80% = 2028.8
otherReimbursable = 4330 × 90% = 3897
totalReimbursable = 20.4 + 2028.8 + 3897 = 5946.2
totalReimbursable = 5946.2 - 500 = 5446.2
selfPay = 6890 - 5446.2 = 1443.8

对比总结：

医院等级	起付线	otherRate	报销金额	自费金额	报销率
三级	1300元	80%	4213.2元	2676.8元	61.1%
二级	800元	85%	4929.7元	1960.3元	71.6%
一级	500元	90%	5446.2元	1443.8元	79.0%

从三级到一级医院，自费金额从2676.8元降至1443.8元，节省了1233元（46%）。这正是医保政策引导患者合理就医的体现——选择较低等级医院就医，经济负担显著减轻。

---

4. InsuranceReference 医保参考数据（147行代码）

InsuranceReference 模块为 IVGuard 提供了6大城市的医保参考数据，使用户在配置医保策略时可以快速填入当地标准参数，而无需手动查阅政策文件。

4.1 6大城市参考值

InsuranceReference 预置了以下6个城市的医保参考数据，涵盖职工医保和居民医保的主要参数。

北京市

北京市作为首都，医保保障水平处于全国前列：

参数	职工医保	居民医保
三级医院起付线	1300元	1300元
二级医院起付线	800元	800元
甲类药品报销比例(三级)	85%	75%
乙类药品报销比例(三级)	80%	70%
年度封顶线	500,000元	400,000元

北京医保的特点是起付线较高（三级1300元），但报销比例和封顶线也处于较高水平。2024年起北京实施了门诊共济保障改革，将门诊费用纳入统筹基金支付范围。

上海市

上海市医保保障水平与北京相当，部分参数略高：

参数	职工医保	居民医保
三级医院起付线	1500元	1500元
二级医院起付线	1000元	1000元
甲类药品报销比例(三级)	85%	75%
乙类药品报销比例(三级)	80%	70%
年度封顶线	550,000元	450,000元

上海医保的起付线为全国最高之一（三级1500元），但封顶线也最高（55万），体现了"高门槛、高保障"的特点。

广州市

广州作为华南地区的医疗中心，医保参数具有代表性：

参数	职工医保	居民医保
三级医院起付线	1600元	1600元
二级医院起付线	800元	800元
甲类药品报销比例(三级)	80%	70%
乙类药品报销比例(三级)	75%	65%
年度封顶线	600,000元	450,000元

广州医保的报销比例低于京沪（甲类80% vs 85%），但封顶线高达60万，为全国最高。

杭州市

杭州作为长三角重要城市，医保参数处于中等偏上水平：

参数	职工医保	居民医保
三级医院起付线	1500元	1500元
二级医院起付线	800元	800元
甲类药品报销比例(三级)	82%	72%
乙类药品报销比例(三级)	78%	68%
年度封顶线	500,000元	400,000元

杭州医保在报销比例上略低于京沪（82%/78% vs 85%/80%），但封顶线与北京持平（50万）。杭州作为数字经济先行城市，医保信息化程度较高，医保电子凭证使用率在全国名列前茅。

成都市

成都作为西部中心城市，医保参数反映了中西部地区的保障水平：

参数	职工医保	居民医保
三级医院起付线	1200元	1200元
二级医院起付线	600元	600元
甲类药品报销比例(三级)	85%	75%
乙类药品报销比例(三级)	80%	70%
年度封顶线	400,000元	300,000元

成都的起付线相对较低（三级1200元），但封顶线也低于东部沿海城市。成都医保的一个特色是门诊统筹报销比例较高，慢性病患者受益明显。

武汉市

武汉作为中部重要城市，医保参数与成都相近：

参数	职工医保	居民医保
三级医院起付线	1200元	1200元
二级医院起付线	600元	600元
甲类药品报销比例(三级)	85%	75%
乙类药品报销比例(三级)	80%	70%
年度封顶线	400,000元	300,000元

武汉在2020年疫情期间实施了多项医保临时政策，包括核酸检测费用全额报销、新冠肺炎患者免费治疗等，体现了医保制度在公共卫生事件中的保障作用。

6城市横向对比

城市	职工三级起付线	职工甲类比例	职工乙类比例	职工封顶线(万)
北京	1300	85%	80%	50
上海	1500	85%	80%	55
广州	1600	80%	75%	60
杭州	1500	82%	78%	50
成都	1200	85%	80%	40
武汉	1200	85%	80%	40

从对比可以看出：

1. 起付线：上海和广州最高（1500-1600元），成都武汉最低（1200元）
2. 报销比例：北京上海成都武汉一致（甲类85%/乙类80%），广州略低（80%/75%），杭州居中（82%/78%）
3. 封顶线：广州最高（60万），上海次之（55万），成都武汉最低（40万）

居民医保普遍规律：

• 起付线与职工医保相同
• 报销比例低10-15个百分点
• 封顶线低10-20万元

参考数据的局限性

需要强调的是，以上参考数据仅为近似值，存在以下局限：

1. 时效性：医保政策每年调整，参考数据可能滞后于最新政策
2. 简化：实际医保政策远比6个参数复杂，涉及分段报销、门诊统筹、大病保险等
3. 个体差异：实际报销金额受个人账户余额、缴费基数、退休状态等影响
4. 特殊政策：部分地区有特殊政策（如北京门诊起付线降低、上海综合减负等）

因此，IVGuard 在使用这些参考数据时始终显示免责声明，提醒用户以当地医保局公布的政策为准。

4.2 buildPolicy 自动填充逻辑

InsuranceReference.buildPolicy() 方法是将参考数据转换为 InsurancePolicy 对象的桥梁函数。它接收参考数据、参保类型和医院等级三个参数，自动选择对应的参数子集填充到策略对象中。

方法签名

static buildPolicy(ref: InsuranceReferenceData, insuranceType: string, hospitalLevel: string): InsurancePolicy

完整实现

static buildPolicy(ref: InsuranceReferenceData, insuranceType: string, hospitalLevel: string): InsurancePolicy {
  const policy = new InsurancePolicy()
  policy.insuranceType = insuranceType
  policy.hospitalLevel = hospitalLevel
  
  if (insuranceType === 'urban_worker') {
    policy.deductible = hospitalLevel === 'level3' ? ref.workerDeductible3 : ref.workerDeductible2
    policy.classARate = ref.workerClassARate3
    policy.classBRate = ref.workerClassBRate3
    policy.ceiling = ref.workerCeiling
  } else {
    // 居民/新农合
    policy.deductible = hospitalLevel === 'level3' ? ref.residentDeductible3 : ref.residentDeductible2
    policy.classARate = ref.residentClassARate3
    policy.classBRate = ref.residentClassBRate3
    policy.ceiling = ref.residentCeiling
  }
  
  return policy
}

逻辑解析

该函数的核心逻辑是一个二分支结构：

分支一：职工医保（urban_worker）

if (insuranceType === 'urban_worker') {
  policy.deductible = hospitalLevel === 'level3' ? ref.workerDeductible3 : ref.workerDeductible2
  policy.classARate = ref.workerClassARate3
  policy.classBRate = ref.workerClassBRate3
  policy.ceiling = ref.workerCeiling
}

• 起付线根据医院等级选择三级或二级的起付线值（通过三元运算符）
• 报销比例使用三级医院的值（workerClassARate3、workerClassBRate3）
• 封顶线直接使用职工医保封顶线

分支二：居民医保/新农合（urban_resident / rural）

else {
  policy.deductible = hospitalLevel === 'level3' ? ref.residentDeductible3 : ref.residentDeductible2
  policy.classARate = ref.residentClassARate3
  policy.classBRate = ref.residentClassBRate3
  policy.ceiling = ref.residentCeiling
}

居民医保和新农合共用同一组参数，结构完全对应。

已知简化

1. 起付线仅区分三级和二级：当前实现中 hospitalLevel 为 'level1' 时，三元运算符会走到 : ref.workerDeductible2 分支，即一级医院使用了二级医院的起付线。这是一个已知的简化处理，后续版本应增加一级医院的专属起付线字段（workerDeductible1、residentDeductible1）。

2. 报销比例使用三级医院值：classARate 和 classBRate 始终使用三级医院的值，未根据医院等级动态调整。实际上，二级和一级医院的报销比例应更高。这一简化意味着 IVGuard 在二/一级医院的报销估算偏保守——估算的自费金额高于实际值，但不会出现误导用户以为报销更多的情况。

3. rural 类型未独立处理：新农合参数使用居民医保参数替代，在多数已整合省份是合理的，但在少数未整合省份可能不够准确。

4. 未考虑退休人员加成：多数地区对退休人员有额外5%-10%的报销比例提升，当前实现未区分在职与退休状态。

调用示例

const ref = InsuranceReference.getByCity('beijing')
const policy = InsuranceReference.buildPolicy(ref, 'urban_worker', 'level3')
// policy.insuranceType = 'urban_worker'
// policy.hospitalLevel = 'level3'
// policy.deductible = 1300
// policy.classARate = 85
// policy.classBRate = 80
// policy.ceiling = 500000

再以上海居民医保为例：

const ref = InsuranceReference.getByCity('shanghai')
const policy = InsuranceReference.buildPolicy(ref, 'urban_resident', 'level2')
// policy.insuranceType = 'urban_resident'
// policy.hospitalLevel = 'level2'
// policy.deductible = 1000  (上海居民二级起付线)
// policy.classARate = 75
// policy.classBRate = 70
// policy.ceiling = 450000

参考数据的数据结构

InsuranceReferenceData 包含以下字段：

class InsuranceReferenceData {
  city: string = ''                    // 城市名称
  workerDeductible3: number = 0        // 职工三级起付线
  workerDeductible2: number = 0        // 职工二级起付线
  workerClassARate3: number = 0        // 职工甲类报销比例(三级)
  workerClassBRate3: number = 0        // 职工乙类报销比例(三级)
  workerCeiling: number = 0            // 职工封顶线
  residentDeductible3: number = 0      // 居民三级起付线
  residentDeductible2: number = 0      // 居民二级起付线
  residentClassARate3: number = 0      // 居民甲类报销比例(三级)
  residentClassBRate3: number = 0      // 居民乙类报销比例(三级)
  residentCeiling: number = 0          // 居民封顶线
}

共10个数据字段，结构对称：职工5个 + 居民5个。城市名称字段用于UI展示和检索。

数据初始化采用硬编码方式，在 InsuranceReference.init() 中为6个城市逐一赋值：

static init(): void {
  const beijing = new InsuranceReferenceData()
  beijing.city = 'beijing'
  beijing.workerDeductible3 = 1300
  beijing.workerDeductible2 = 800
  beijing.workerClassARate3 = 85
  beijing.workerClassBRate3 = 80
  beijing.workerCeiling = 500000
  beijing.residentDeductible3 = 1300
  beijing.residentDeductible2 = 800
  beijing.residentClassARate3 = 75
  beijing.residentClassBRate3 = 70
  beijing.residentCeiling = 400000
  // ... 其他城市类似
  this.references.push(beijing)
  // ...
}

数据检索

InsuranceReference.getByCity() 根据城市名称检索参考数据：

static getByCity(city: string): InsuranceReferenceData {
  for (let i = 0; i < this.references.length; i++) {
    if (this.references[i].city === city) {
      return this.references[i]
    }
  }
  return new InsuranceReferenceData()  // 未找到时返回空数据
}

线性查找，6个城市的数据量极小，O(n)性能完全可接受。未找到城市时返回空的 InsuranceReferenceData 对象，所有字段为0或空字符串，调用方需处理此边界情况。

---

5. InsuranceSetupPage 5步问答设计

InsuranceSetupPage 是用户配置医保策略的交互界面，采用5步问答（Step-by-Step Wizard）模式，引导用户逐步输入医保参数。这种设计的核心优势在于：

1. 降低认知负担：将复杂的医保配置拆解为5个简单步骤，每步只关注一个参数
2. 提供参考值：通过城市选择自动填充，减少用户手动输入
3. 渐进式披露：后续步骤依赖前序步骤的选择，避免无效配置

5.1 Step 1：参保类型选择

用户首先选择自己的参保类型，这是所有后续计算的基础。

可选选项：

• 城镇职工医疗保险（urban_worker）：覆盖在职/退休职工
• 城镇居民医疗保险（urban_resident）：覆盖城镇非就业居民
• 新型农村合作医疗（rural）：覆盖农村居民

UI实现采用三个单选按钮，每个选项附带简要说明文字，帮助用户判断自己所属类型。

选择参保类型后，系统将：

1. 存储 insuranceType 值
2. 决定后续步骤中城市参考值使用职工参数还是居民参数
3. 影响 getOtherReimbursableRate() 的推断结果

参保类型选择的用户体验考量

多数用户对自己的参保类型有基本认知，但仍存在混淆的情况：

• 灵活就业人员：部分灵活就业者参加了职工医保，但误以为自己属于居民医保。IVGuard 通过选项说明文字"覆盖在职/退休职工，含灵活就业参保"消除歧义
• 城乡居民：已完成居民医保和新农合整合的省份，统一使用"urban_resident"即可
• 公费医疗：少数机关事业单位仍在实行公费医疗制度，IVGuard 暂不支持，需选择最接近的职工医保选项

5.2 Step 2：医院等级选择

用户选择就诊医院的等级，这直接影响报销比例和起付线。

可选选项：

• 三级医院（level3）：省/市级大医院，报销比例最低但医疗水平最高
• 二级医院（level2）：区/县级医院，报销比例居中
• 一级医院（level1）：社区/乡镇医院，报销比例最高

UI实现采用三个单选按钮，每个选项附带说明文字，如"三级医院：省市级大型综合医院"。

选择医院等级后，系统将：

1. 存储 hospitalLevel 值
2. 影响起付线的选择（三级起付线高于二级）
3. 影响 getOtherReimbursableRate() 的推断结果

医院等级选择的引导策略

部分用户可能不清楚就诊医院的等级，IVGuard 提供以下辅助判断信息：

• 三级医院：名称通常含"省"、“市”、“大学附属”、“中心"等关键词，如"省人民医院”、“市第一医院”、“XX大学附属医院”
• 二级医院：名称通常含"区"、“县”、“市第二/第三"等关键词，如"区中心医院”、“县人民医院”
• 一级医院：名称通常含"社区卫生"、“乡镇"等关键词，如"社区卫生服务中心”

5.3 Step 3：起付线输入

用户输入起付线金额（单位：元）。

UI设计：

• 数字输入框：允许输入0-10000的整数
• 参考值提示：根据已选城市和参保类型，显示当地标准起付线
• 快速填入按钮：一键将参考值填入输入框

例如，选择北京职工医保+三级医院后，显示"北京市职工医保三级医院起付线参考值：1300元"，用户可点击"使用参考值"按钮快速填入。

起付线输入的交互细节

1. 单位标注：输入框右侧显示"元"字，明确金额单位
2. 输入校验：只允许输入非负整数，非法输入自动清空
3. 参考值动态变化：切换参保类型或医院等级时，参考值提示随之更新
4. 手动修改：用户可在自动填入的基础上手动修改，适应特殊需求

5.4 Step 4：报销比例输入

用户输入甲类和乙类药品的报销比例（单位：%）。

UI设计：

• 两个数字输入框：甲类报销比例、乙类报销比例
• 参考值提示：根据已选城市显示当地标准比例
• 快速填入按钮：一键将参考值填入

例如，选择北京职工医保后：

• 甲类报销比例参考值：85%
• 乙类报销比例参考值：80%

为什么需要两个输入框？ 因为甲类和乙类药品的报销比例在多数城市是不同的（通常甲类比乙类高5个百分点），分开输入可以更精确地反映当地政策。

报销比例输入的交互细节

1. 百分比标注：输入框右侧显示"%"符号
2. 范围校验：0-100之间的整数，超出范围自动截断
3. 联动提示：甲类比例通常高于乙类，若用户输入的甲类比例低于乙类，显示黄色提示"甲类比例通常不低于乙类比例"
4. 常见值快捷选择：提供 70%、75%、80%、85%、90% 等常见值的快捷按钮

5.5 Step 5：封顶线输入与配置预览

用户输入年度封顶线金额（单位：元），并预览完整的医保策略配置。

UI设计：

• 数字输入框：封顶线金额
• 参考值提示：根据已选城市显示当地标准封顶线
• 配置预览卡片：汇总显示前4步配置的所有参数

预览卡片示例：

医保策略配置预览
━━━━━━━━━━━━━━━━━━
参保类型：城镇职工医疗保险
医院等级：三级医院
起付线：1300元
甲类报销比例：85%
乙类报销比例：80%
封顶线：500,000元
━━━━━━━━━━━━━━━━━━
其他费用报销比例：80%（自动推断）

用户确认无误后点击"完成"按钮，系统将保存 InsurancePolicy 对象到 DataStore，后续费用计算将自动使用该策略。

配置预览的设计意义

配置预览卡片不仅是对用户输入的总结，更重要的是：

1. 纠错机会：用户可以在最终确认前检查所有参数，发现输入错误及时修正
2. 透明度：显示"其他费用报销比例：80%（自动推断）"，让用户了解系统自动推断的参数
3. 信任建立：用户看到完整的参数列表，对计算结果的信任度更高

5.6 城市快速填入功能

InsuranceSetupPage 提供城市快速填入功能，是用户最常用的配置方式。用户选择城市后，系统自动将该城市的参考数据填入Step 3-5的输入框中。

实现流程：

1. 用户在城市下拉列表中选择城市（如"北京"）
2. 系统调用 InsuranceReference.getByCity('beijing') 获取参考数据
3. 根据Step 1选择的参保类型和Step 2选择的医院等级，调用 buildPolicy() 生成策略
4. 将策略参数自动填入Step 3-5的输入框
5. 用户可以在自动填入的基础上手动修改个别参数

这一功能的设计理念是"参考值优先，手动调整为辅"——大多数用户只需选择城市即可获得合理的估算参数，少数对当地政策了解的用户可以手动微调。

城市选择的UI设计

城市选择采用下拉列表（Dropdown）组件：

• 默认显示"选择城市"
• 展开后显示6个城市：北京、上海、广州、杭州、成都、武汉
• 选择城市后，下拉列表折叠，显示已选城市名称
• 城市名称后标注省份，如"北京（京）"、“上海（沪）”

城市选择与步骤的交互关系

城市选择可以在任意步骤进行，其效果是：

1. 如果在Step 1之前选择城市，仅预填充城市名称，不影响参保类型选择
2. 如果在Step 1-2完成后选择城市，自动填入Step 3-5的参考值
3. 如果在Step 3-5之间选择城市，覆盖已填入的值（需用户确认）

5.7 StepIndicator 组件可视化进度

StepIndicator 是一个可视化进度指示组件，显示用户当前处于5步中的哪一步。

UI设计：

• 5个圆形节点，横向排列
• 已完成步骤：实心圆+对勾，连接线高亮
• 当前步骤：实心圆+数字，连接线高亮
• 未到达步骤：空心圆+数字，连接线灰色

① ── ② ── ③ ── ④ ── ⑤
✓    ✓    ●    ○    ○

上图中，用户已完成Step 1-2，当前在Step 3。

StepIndicator 的实现要点：

1. 步骤间可回退：用户可以点击已完成的步骤回到前序步骤修改
2. 不可跳跃：用户不能跳过未完成的步骤直接进入后续步骤
3. 实时更新：每次步骤变更都触发UI刷新
4. 动画过渡：步骤切换时有平滑的过渡动画

StepIndicator 的组件结构

@Component
struct StepIndicator {
  @Prop currentStep: number = 1
  @Prop totalSteps: number = 5
  @Prop completedSteps: number = 0

  build() {
    Row() {
      ForEach(this.getStepList(), (step: StepInfo) => {
        // 渲染每个步骤节点和连接线
        StepNode({ step: step, isActive: step.index === this.currentStep })
        if (step.index < this.totalSteps) {
          StepConnector({ completed: step.index <= this.completedSteps })
        }
      })
    }
  }
}

5.8 5步问答的完整交互流程

用户从打开 InsuranceSetupPage 到完成配置的完整流程：

1. 页面加载：StepIndicator 显示在Step 1，城市下拉列表可见
2. Step 1：用户选择参保类型，StepIndicator 前进到Step 2
3. Step 2：用户选择医院等级，StepIndicator 前进到Step 3
4. 城市选择（可选）：用户选择城市，Step 3-5参考值自动填入
5. Step 3：确认起付线（已自动填入或手动输入），StepIndicator 前进到Step 4
6. Step 4：确认报销比例（已自动填入或手动输入），StepIndicator 前进到Step 5
7. Step 5：确认封顶线，预览配置，点击"完成"
8. 保存：系统将 InsurancePolicy 保存到 DataStore，页面关闭

整个流程预计耗时1-3分钟（使用城市快速填入）或5-10分钟（手动输入所有参数）。

---

6. CostPage 费用管理 UI

CostPage 是用户管理医疗费用的主界面，提供了费用录入、分类统计、报销计算和可视化展示的完整功能。

6.1 三大数字卡片

页面顶部以三个大型数字卡片展示核心费用指标：

总费用卡片

• 显示：summary.totalCost
• 样式：深蓝色背景，白色大字
• 格式：toFixed(2) 保留两位小数
• 含义：所有费用条目的金额总和

医保报销卡片

• 显示：summary.reimbursable
• 样式：绿色背景，白色大字
• 格式：toFixed(2)
• 含义：根据当前医保策略计算的可报销金额

自费金额卡片

• 显示：summary.selfPay
• 样式：红色背景，白色大字
• 格式：toFixed(2)
• 含义：患者实际需要自己承担的金额

三张卡片的数学关系：总费用 = 医保报销 + 自费金额。用户可以直观地通过三个数字理解费用构成。

卡片布局采用横向等宽排列，每张卡片内部垂直居中显示数值和标签。当数值为0时，卡片仍然显示但数值为"0.00"，避免布局跳动。

数字卡片的视觉设计

每张卡片的视觉层次：

1. 数值层：最大字号（36sp），加粗，白色
2. 标签层：中等字号（14sp），常规字重，白色半透明
3. 背景层：纯色背景，圆角（12vp），微妙阴影

@Component
struct CostCard {
  @Prop value: number = 0
  @Prop label: string = ''
  @Prop bgColor: string = '#2196F3'

  build() {
    Column() {
      Text(this.value.toFixed(2))
        .fontSize(36)
        .fontColor(Color.White)
        .fontWeight(FontWeight.Bold)
      Text(this.label)
        .fontSize(14)
        .fontColor('#CCFFFFFF')
        .margin({ top: 4 })
    }
    .width('100%')
    .height(100)
    .backgroundColor(this.bgColor)
    .borderRadius(12)
    .justifyContent(FlexAlign.Center)
    .alignItems(HorizontalAlign.Center)
  }
}

6.2 CostPieChart 饼图

CostPieChart 是一个环形饼图（Donut Chart），直观展示药品费用与其他费用的比例关系。

数据源：

• 药品费用扇区：summary.drugCost，蓝色填充
• 其他费用扇区：summary.otherCost，橙色填充

交互：

• 点击扇区高亮并显示详细金额
• 中心显示总费用

实现要点：

1. 使用 ArkUI 的 Canvas 组件绘制
2. 扇区角度计算：angle = (cost / totalCost) × 360
3. 当某类费用为0时，对应扇区不绘制
4. 当总费用为0时，显示空状态提示"暂无费用数据"

饼图的颜色编码与医保类别标签保持一致：

• 药品费用：蓝色系（#4A90D9）
• 其他费用：橙色系（#F5A623）

饼图绘制算法

环形饼图的绘制分为以下步骤：

1. 计算扇区角度：

const totalCost = summary.drugCost + summary.otherCost
if (totalCost === 0) return  // 无数据不绘制
const drugAngle = (summary.drugCost / totalCost) * 360
const otherAngle = (summary.otherCost / totalCost) * 360

2. 绘制扇区：从12点方向（-90度）开始，顺时针绘制

let startAngle = -90
// 绘制药品费用扇区
ctx.beginPath()
ctx.moveTo(centerX, centerY)
ctx.arc(centerX, centerY, radius, startAngle * Math.PI / 180, (startAngle + drugAngle) * Math.PI / 180)
ctx.closePath()
ctx.fillStyle = '#4A90D9'
ctx.fill()

startAngle += drugAngle
// 绘制其他费用扇区
ctx.beginPath()
ctx.moveTo(centerX, centerY)
ctx.arc(centerX, centerY, radius, startAngle * Math.PI / 180, (startAngle + otherAngle) * Math.PI / 180)
ctx.closePath()
ctx.fillStyle = '#F5A623'
ctx.fill()

3. 绘制中心空洞：使用白色圆形覆盖中心区域，形成环形效果

ctx.beginPath()
ctx.arc(centerX, centerY, innerRadius, 0, 2 * Math.PI)
ctx.fillStyle = '#FFFFFF'
ctx.fill()

4. 绘制中心文字：在空洞中心显示总费用

ctx.font = '24px sans-serif'
ctx.fillStyle = '#333333'
ctx.textAlign = 'center'
ctx.textBaseline = 'middle'
ctx.fillText('¥' + totalCost.toFixed(0), centerX, centerY)

6.3 费用明细列表

费用明细列表以表格形式展示所有费用条目的详细信息：

列定义：

列名	数据源	对齐方式
名称	item.name	左对齐
日期	item.date	居中
数量	item.quantity	居中
单价	item.unitPrice	右对齐
总价	item.totalPrice	右对齐
医保类别	buildDrugCategories(item)	居中

列表项交互：

• 左滑删除：向左滑动显示删除按钮
• 点击编辑：点击费用条目进入编辑模式
• 长按排序：长按后可拖拽调整顺序（预留功能）

空状态：当列表为空时，显示引导文字"点击下方 + 号添加费用条目"。

列表项的视觉设计

每个列表项的高度固定为72vp，内部布局：

┌──────────────────────────────────────────────┐
│  [药品图标] 奥美拉唑            [乙类标签]   │
│            2024-01-15  ×2  ¥68.00  ¥136.00  │
└──────────────────────────────────────────────┘

第一行：药品/项目名称 + 医保类别标签
第二行：日期 + 数量 + 单价 + 总价

药品图标与医保类别标签的颜色编码一致，增强视觉一致性。

6.4 医保类别标签

每条费用条目右侧显示医保类别标签，以不同颜色底色区分：

甲类标签

• 文字：“甲类”
• 样式：绿色底色（#4CAF50），白色文字，圆角矩形
• 对应：insuranceCategory === 'class_a'

乙类标签

• 文字：“乙类”
• 样式：橙色底色（#FF9800），白色文字，圆角矩形
• 对应：insuranceCategory === 'class_b'

自费标签

• 文字：“自费”
• 样式：红色底色（#F44336），白色文字，圆角矩形
• 对应：insuranceCategory === 'self_pay' 或药品信息缺失

其他标签

• 文字：“其他”
• 样式：灰色底色（#9E9E9E），白色文字，圆角矩形
• 对应：item.isDrug === false

标签的生成通过 buildDrugCategories() 函数实现：

static buildDrugCategories(items: CostItem[]): string[] {
  const categories: string[] = []
  for (let i = 0; i < items.length; i++) {
    const item = items[i]
    if (item.isDrug) {
      const drugInfo = IVDrugDatabase.getById(item.drugId)
      if (drugInfo !== undefined) {
        categories.push(drugInfo.insuranceCategory)
      } else {
        categories.push('self_pay')
      }
    } else {
      categories.push('other')
    }
  }
  return categories
}

该函数遍历所有费用条目，通过数据库查询药品的医保类别，返回类别数组。UI层根据类别值渲染对应颜色的标签。

标签组件实现

@Component
struct InsuranceTag {
  @Prop category: string = 'other'

  build() {
    Text(this.getLabelText())
      .fontSize(12)
      .fontColor(Color.White)
      .backgroundColor(this.getLabelColor())
      .borderRadius(4)
      .padding({ left: 8, right: 8, top: 2, bottom: 2 })
  }

  private getLabelText(): string {
    if (this.category === 'class_a') return '甲类'
    if (this.category === 'class_b') return '乙类'
    if (this.category === 'self_pay') return '自费'
    return '其他'
  }

  private getLabelColor(): string {
    if (this.category === 'class_a') return '#4CAF50'
    if (this.category === 'class_b') return '#FF9800'
    if (this.category === 'self_pay') return '#F44336'
    return '#9E9E9E'
  }
}

6.5 DrugSearchEntry 搜索设计

DrugSearchEntry 是药品搜索入口组件，嵌入在费用明细列表的顶部或添加费用对话框中。

搜索流程：

1. 用户在搜索框输入药品名称关键词
2. 系统调用 IVDrugDatabase.search(keyword) 进行模糊搜索
3. 搜索结果以下拉列表形式展示，每项显示药品名称和规格
4. 用户点击选中药品，系统自动填充药品名称和单价

搜索实现：

• 使用防抖（debounce）机制，300ms延迟后触发搜索
• 最小搜索长度：2个字符
• 最大显示结果数：10条
• 无结果时显示"未找到匹配药品"

搜索框UI：

• 左侧搜索图标
• 中间输入框，placeholder为"搜索药品名称"
• 右侧清除按钮（输入非空时显示）

搜索防抖实现

@Component
struct DrugSearchEntry {
  @State searchText: string = ''
  @State searchResults: DrugInfo[] = []
  private debounceTimer: number = -1

  build() {
    Column() {
      Row() {
        Image($r('app.media.ic_search'))
          .width(20)
          .height(20)
          .margin({ left: 12, right: 8 })
        TextInput({ placeholder: '搜索药品名称' })
          .layoutWeight(1)
          .onChange((value: string) => {
            this.searchText = value
            this.debounceSearch()
          })
        if (this.searchText.length > 0) {
          Image($r('app.media.ic_clear'))
            .width(16)
            .height(16)
            .margin({ right: 12 })
            .onClick(() => {
              this.searchText = ''
              this.searchResults = []
            })
        }
      }
      .height(44)
      .backgroundColor('#F5F5F5')
      .borderRadius(8)
      
      if (this.searchResults.length > 0) {
        List() {
          ForEach(this.searchResults, (drug: DrugInfo) => {
            ListItem() {
              Text(drug.name + ' ' + drug.specification)
                .fontSize(14)
                .padding(12)
            }
            .onClick(() => {
              this.onDrugSelected(drug)
            })
          })
        }
        .height(200)
      }
    }
  }

  private debounceSearch(): void {
    if (this.debounceTimer !== -1) {
      clearTimeout(this.debounceTimer)
    }
    this.debounceTimer = setTimeout(() => {
      if (this.searchText.length >= 2) {
        this.searchResults = IVDrugDatabase.search(this.searchText)
      } else {
        this.searchResults = []
      }
    }, 300)
  }
}

6.6 添加费用对话框

添加费用对话框支持两种费用类型的录入：

药品费用模式：

1. 用户点击"药品"标签切换到药品模式
2. 在搜索框输入药品名称
3. 从下拉列表选择药品，自动填充名称和单价
4. 输入数量，系统自动计算总价 = 单价 × 数量
5. 选择日期
6. 点击"添加"确认

其他费用模式：

1. 用户点击"其他"标签切换到其他费用模式
2. 手动输入费用名称（如"护理费"、“床位费”）
3. 手动输入单价
4. 输入数量
5. 选择日期
6. 点击"添加"确认

对话框UI结构：

┌─────────────────────────┐
│    添加费用              │
│ ┌──────┐ ┌──────┐      │
│ │ 药品 │ │ 其他 │      │
│ └──────┘ └──────┘      │
│                         │
│ [搜索药品名称...]       │
│                         │
│ 名称：奥美拉唑          │
│ 单价：68.00  数量：[2]  │
│ 总价：136.00            │
│ 日期：2024-01-15        │
│                         │
│     [取消]    [添加]     │
└─────────────────────────┘

输入验证：

• 名称不能为空
• 单价必须大于0
• 数量必须为正整数
• 日期不能为空
• 验证失败时在对应输入框下方显示红色提示文字

药品/其他模式切换

模式切换使用 Tabs 组件实现，两个 TabContent 分别承载药品模式和其他模式的UI：

Tabs({ index: this.modeIndex }) {
  TabContent() {
    // 药品模式UI
    Column() {
      DrugSearchEntry({ onDrugSelected: (drug) => {
        this.name = drug.name
        this.unitPrice = drug.price
      }})
      // ... 数量、日期输入
    }
  }.tabBar('药品')
  
  TabContent() {
    // 其他费用模式UI
    Column() {
      TextInput({ placeholder: '费用名称' })
        .onChange((value) => { this.name = value })
      // ... 单价、数量、日期输入
    }
  }.tabBar('其他')
}

总价自动计算

当单价或数量发生变化时，总价自动更新：

@Watch('unitPrice')
@Watch('quantity')
updateTotalPrice(): void {
  this.totalPrice = this.unitPrice * this.quantity
}

@Watch 装饰器监听 unitPrice 和 quantity 的变化，任一变化都触发 totalPrice 的重新计算。

6.7 免责声明

CostPage 底部显示免责声明文字，提醒用户费用估算的局限性：

⚠️ 费用估算仅供参考，以医院实际收费为准

免责声明的显示条件：

• 始终显示，不可关闭
• 字体较小（12sp），灰色文字（#999999）
• 位于页面最底部，不遮挡主要内容

免责声明的补充说明（点击展开）：

• 医保政策以当地医保局公布为准
• 参考数据基于2024年政策，可能已更新
• 特殊政策（大病保险、门诊慢病等）未纳入计算
• 乙类药品先自付比例未实现

---

7. 费用数据流

IVGuard 的费用管理涉及多个组件和模块之间的数据流转。本节详细描述从用户输入到最终展示的完整数据流。

7.1 添加费用流程

用户操作 → DrugSearchEntry → IVDrugDatabase.search → 选择药品
    ↓
CostItem.create(name, unitPrice, quantity, isDrug, drugId, date)
    ↓
costItems.push(newItem)
    ↓
DataStore.saveCostItems(costItems)
    ↓
CostService.calculateSummary(costItems, policy)
    ↓
更新 summary → UI 刷新

详细步骤：

1. 用户输入：用户在添加费用对话框中输入药品搜索关键词
2. 数据库搜索：IVDrugDatabase.search(keyword) 在药品数据库中模糊匹配，返回候选列表
3. 选择药品：用户从候选列表中选择目标药品，系统获取药品的 id、name、price、insuranceCategory
4. 创建费用条目：CostItem.create() 根据选择结果创建费用条目对象，计算 totalPrice = unitPrice × quantity
5. 追加到数组：costItems.push(newItem) 将新条目追加到费用数组
6. 持久化存储：DataStore.saveCostItems() 将更新后的费用数组保存到本地存储
7. 重新计算：CostService.calculateSummary() 根据最新费用数组和当前医保策略重新计算汇总
8. UI刷新：summary 对象更新后，ArkUI 的状态驱动机制自动刷新相关组件

添加费用流程的时序分析

从用户点击"添加"到UI刷新完成的典型耗时：

1. CostItem.create()：<1ms（内存操作）
2. costItems.push()：<1ms（数组操作）
3. DataStore.saveCostItems()：5-20ms（本地存储写入）
4. CostService.calculateSummary()：<5ms（纯计算，无IO）
5. UI刷新：16-33ms（一帧到两帧）

总耗时约20-60ms，用户感知为即时响应。

7.2 报销计算触发链路

每当费用数据发生变化时，报销计算自动触发：

costItems 变化（添加/删除/修改）
    ↓
@Watch('costItems') → onCostItemsChange()
    ↓
CostService.calculateSummary(costItems, policy)
    ↓
summary 更新 → 数字卡片刷新 + 饼图刷新

@Watch 装饰器监听 costItems 数组的变化，当数组内容发生改变时自动调用回调函数，触发重新计算。这确保了费用数据与报销计算结果始终同步。

@Watch 监听机制的实现

@Component
struct CostPage {
  @State costItems: CostItem[] = []
  @State summary: CostSummary = CostSummary.create()
  @State policy: InsurancePolicy = new InsurancePolicy()

  @Watch('costItems')
  onCostItemsChange(): void {
    this.recalculate()
  }

  @Watch('policy')
  onPolicyChange(): void {
    this.recalculate()
  }

  private recalculate(): void {
    this.summary = CostService.calculateSummary(this.costItems, this.policy)
  }
}

@Watch 分别监听 costItems 和 policy 两个状态变量，任一变化都触发重新计算。这确保了：

• 添加/删除费用条目后自动重算
• 修改医保策略后自动重算
• 两者同时变化也只触发一次重算（ArkUI 的批量更新机制）

7.3 医保策略变更触发链路

当用户修改医保策略时，也需要重新计算报销金额：

InsuranceSetupPage 保存 policy
    ↓
DataStore.saveInsurancePolicy(policy)
    ↓
CostPage 读取新 policy
    ↓
CostService.calculateSummary(costItems, newPolicy)
    ↓
summary 更新 → UI 刷新

策略变更的数据传递

InsuranceSetupPage 和 CostPage 之间的数据传递通过 DataStore 中转：

1. 写入：InsuranceSetupPage 调用 DataStore.saveInsurancePolicy(policy) 将策略保存到持久化存储
2. 读取：CostPage 在 aboutToAppear() 生命周期中调用 DataStore.loadInsurancePolicy() 加载策略
3. 通知：当策略变更时，通过 ArkUI 的 @Watch 机制触发重算

这种间接传递的设计优势在于：

• 两个页面无需直接引用，降低耦合度
• DataStore 提供持久化保证，应用重启后策略不丢失
• 多个页面可以共享同一策略数据

7.4 buildDrugCategories 医保类别映射流程

医保类别标签的生成是一个独立的映射流程：

costItems → buildDrugCategories()
    ↓
对每项 item:
├── item.isDrug === true
│   └── IVDrugDatabase.getById(item.drugId)
│       ├── insuranceCategory === 'class_a' → 绿色"甲类"标签
│       ├── insuranceCategory === 'class_b' → 橙色"乙类"标签
│       └── 'self_pay' / undefined → 红色"自费"标签
└── item.isDrug === false
    └── 灰色"其他"标签

该映射在费用列表渲染时执行，确保每条费用条目的标签颜色与其医保类别一致。

映射性能分析

buildDrugCategories() 的执行频率与列表渲染频率一致。每次费用数据变化都会触发重新映射，但由于：

1. 药品数据库使用 Map 结构，getById() 为 O(1) 查找
2. 典型费用条目数量在10-50条之间
3. 无IO操作，纯内存计算

总耗时通常 <1ms，不会成为性能瓶颈。

7.5 完整数据流图

┌─────────────┐     ┌─────────────────┐     ┌──────────────┐
│  用户输入    │────→│  CostItem       │────→│  costItems[] │
│  (添加费用)  │     │  .create()      │     │              │
└─────────────┘     └─────────────────┘     └──────┬───────┘
                                                    │
                                                    ↓
┌─────────────┐     ┌─────────────────┐     ┌──────────────┐
│  DataStore   │←────│  saveCostItems  │←────│  push item   │
│  (持久化)    │     │                 │     │              │
└─────────────┘     └─────────────────┘     └──────────────┘
                                                    │
                                                    ↓
┌─────────────┐     ┌─────────────────┐     ┌──────────────┐
│  CostPage    │←────│  CostSummary    │←────│  CostService │
│  (UI展示)    │     │                 │     │  .calculate  │
└─────────────┘     └─────────────────┘     └──────┬───────┘
                                                    │
                                           ┌────────┴────────┐
                                           ↓                 ↓
                                    ┌────────────┐    ┌────────────┐
                                    │ Insurance  │    │ IVDrug     │
                                    │ Policy     │    │ Database   │
                                    └────────────┘    └────────────┘

7.6 数据一致性保证

IVGuard 通过以下机制确保费用数据与计算结果的一致性：

1. 单一数据源：costItems 数组是唯一的费用数据源，所有组件都从该数组读取数据
2. 自动重算：费用变更通过 @Watch 自动触发重算，无需手动调用
3. 持久化同步：每次费用变更都同步到 DataStore，确保数据不丢失
4. 原子更新：费用条目的添加/删除/修改是原子操作，不会出现中间状态

数据一致性的边界情况

1. 应用异常退出：如果应用在 saveCostItems() 之前异常退出，最后一条操作会丢失。IVGuard 通过在 push 之前先 save 来降低此风险。

2. 并发修改：ArkUI 的单线程模型保证了状态变量不会被并发修改，无需加锁。

3. 浮点数精度：金额计算使用浮点数，显示时使用 toFixed(2) 截断。累积误差在正常使用场景下可忽略（误差 <0.01元）。

7.7 删除费用流程

删除费用的数据流与添加费用对称：

用户左滑点击删除
    ↓
costItems.splice(index, 1)
    ↓
DataStore.saveCostItems(costItems)
    ↓
@Watch('costItems') 触发 → CostService.calculateSummary()
    ↓
summary 更新 → UI 刷新

删除操作后，系统立即重新计算报销金额，确保三大数字卡片和饼图反映最新的费用构成。

7.8 编辑费用流程

编辑费用的数据流与添加类似，但多一步"替换"操作：

用户点击费用条目 → 进入编辑模式
    ↓
修改名称/数量/单价等
    ↓
costItems[index] = updatedItem
    ↓
DataStore.saveCostItems(costItems)
    ↓
@Watch('costItems') 触发 → CostService.calculateSummary()
    ↓
summary 更新 → UI 刷新

编辑操作的核心是数组元素的替换：costItems[index] = updatedItem。替换后，@Watch 监听到数组变化，触发重算。

---

8. 免责声明与合规考虑

IVGuard 作为一款医疗费用估算工具，其计算结果仅供参考，不能替代医院实际收费和医保经办机构的报销核定。本章详细阐述免责声明的必要性和已知的计算局限性。

8.1 核心免责声明

IVGuard 在 CostPage 底部和 InsuranceSetupPage 中均显示免责声明：

“费用估算仅供参考，以医院实际收费为准”

该声明的必要性基于以下原因：

1. 地区差异：中国各省市医保政策存在差异，IVGuard 仅覆盖6个城市的参考数据
2. 时效性：医保政策每年调整，IVGuard 的参考数据可能滞后于最新政策
3. 个体差异：实际报销金额受个人账户余额、历年缴费基数、是否退休等多种因素影响
4. 政策复杂性：特殊病种、门诊慢病、异地就医等政策未纳入计算

免责声明的法律背景

根据《互联网诊疗管理办法》和《移动医疗器械注册与备案技术审查指导原则》，涉及医疗费用计算的功能属于"辅助决策"类别，需要明确标注结果仅供参考。IVGuard 的免责声明符合以下法规要求：

1. 提示义务：向用户明示计算结果不具备法律效力
2. 数据来源说明：参考数据来源于公开政策文件，非官方发布
3. 精度限制：明确计算精度和已知的简化处理
4. 替代建议：建议用户咨询医院财务科或医保经办机构获取准确数据

8.2 医保政策时效性

医保政策并非一成不变，各级医保局每年都会根据基金运行情况和政策目标进行调整。主要变动包括：

1. 药品目录调整：国家医保局每年更新医保药品目录，新增和调出药品
2. 报销比例调整：部分地区根据基金结余情况调整报销比例
3. 起付线和封顶线调整：部分地区根据医疗费用增长调整起付线和封顶线
4. 门诊共济改革：2023年起全国推行门诊共济保障改革，将门诊费用纳入统筹基金

IVGuard 的参考数据基于2024年政策，建议用户：

• 定期检查当地医保局官网获取最新政策
• 如发现 IVGuard 参考数据与实际政策不符，手动调整参数

2024年重要政策变化

1. 国家医保药品目录2024版：新增126种药品，调出1种，目录内药品总数达3088种
2. 门诊共济保障改革：职工医保个人账户划入比例调整，门诊费用纳入统筹基金支付
3. DRG/DIP支付方式改革：住院费用逐步按疾病诊断相关分组（DRG）付费，改变传统按项目付费模式
4. 跨省异地就医直接结算：进一步扩大跨省异地就医直接结算覆盖范围

这些政策变化可能影响 IVGuard 的计算准确性，特别是 DRG 支付方式改革后，住院费用的计算逻辑可能与传统按项目付费模式不同。

8.3 特殊政策未涵盖

IVGuard 的计算模型未涵盖以下特殊医保政策：

大病保险

当基本医保报销金额达到封顶线后，患者可进入大病保险支付范围。大病保险的报销比例通常不低于50%，部分地区按费用分段递增（如0-5万报50%，5-10万报60%，10万以上报70%）。IVGuard 当前未实现大病保险的叠加计算。

影响评估：对于年度医疗费用超过封顶线的患者，IVGuard 估算的自费金额偏高（未计入大病保险报销），但不会误导用户以为报销更多。

未来计划：在后续版本中增加大病保险参数配置，包括大病保险起付线、分段报销比例和封顶线。

门诊慢病

部分地区对高血压、糖尿病等慢性病提供门诊报销政策，报销比例可达70%-80%。IVGuard 的计算模型主要针对住院费用，未单独处理门诊慢病报销。

影响评估：对于门诊慢病患者，IVGuard 的报销估算可能偏低。但鉴于 IVGuard 主要面向静脉注射场景（通常为住院治疗），门诊慢病报销的缺失影响有限。

异地就医

异地就医的报销政策与本地就医不同：

• 备案后异地就医：报销比例可能降低5%-10%
• 未备案异地就医：报销比例可能降低10%-20%
• 跨省异地就医：执行就医地医保目录，参保地报销比例

IVGuard 未区分本地就医和异地就医场景。

影响评估：对于异地就医患者，IVGuard 的报销估算可能偏高（未降低报销比例），可能导致用户低估自费金额。后续版本计划增加异地就医标识和对应的报销比例调整。

离休人员/特殊人群

离休人员、伤残军人等特殊人群享有更高的医保待遇，报销比例可达95%-100%。IVGuard 未涵盖这类特殊人群的参数配置。

影响评估：对于特殊人群，IVGuard 的报销估算偏低，但这部分人群占比极小，且有独立的医保经办体系，通常不使用通用型医保计算工具。

门诊共济

2023年起全国推行的门诊共济保障改革将门诊费用纳入统筹基金支付范围，报销比例通常为50%-60%。IVGuard 当前的计算模型未单独处理门诊费用，门诊费用的报销比例可能与住院费用不同。

影响评估：对于门诊静脉注射患者（如日间化疗），IVGuard 使用住院报销比例计算，可能导致估算偏高。后续版本需区分门诊和住院场景。

8.4 乙类药品先自付比例未实现

当前版本的一个重要简化：未实现乙类药品先自付比例的计算。

按照国家医保政策，乙类药品在使用时需要先自付一定比例（通常为10%-15%），剩余部分才按报销比例计算。例如：

• 乙类药品费用100元，先自付比例10%
• 先自付金额 = 100 × 10% = 10元
• 纳入报销基数金额 = 100 - 10 = 90元
• 按80%报销比例计算 = 90 × 80% = 72元
• 实际自付 = 10 + 90 × 20% = 28元

而 IVGuard 当前的计算方式：

• 乙类药品费用100元
• 按80%报销比例计算 = 100 × 80% = 80元
• 实际自付 = 100 × 20% = 20元

差异：当前计算方式将自费金额低估了8元（28 - 20），报销金额高估了8元（80 - 72）。

这是一个偏乐观的估算，可能误导用户以为报销金额比实际更高。后续版本需要增加乙类先自付比例参数，计算公式修正为：

classBReimbursable = classBDrugCost × (1 - classBSelfPayRate / 100) × classBRate / 100

其中 classBSelfPayRate 为乙类药品先自付比例，需要在 InsurancePolicy 和 InsuranceReferenceData 中新增字段。

乙类先自付比例的地区差异

地区	乙类先自付比例	说明
北京	10%	统一比例
上海	10%-15%	按药品分段
广州	5%-20%	按药品分段
杭州	5%-15%	按药品分段
成都	10%	统一比例
武汉	10%-15%	按药品分段

部分城市按药品分段设置先自付比例，增加了实现的复杂度。IVGuard 计划采用单一比例（默认10%），作为近似处理。

8.5 计算精度与浮点数处理

IVGuard 的费用计算使用 JavaScript 的 number 类型（IEEE 754 双精度浮点数），在金额显示时使用 toFixed(2) 保留两位小数。

浮点数精度问题

JavaScript 浮点数运算存在精度问题：

0.1 + 0.2 = 0.30000000000000004  // 而非 0.3
68 * 0.8 = 54.400000000000006    // 而非 54.4

在费用计算场景中，这类精度偏差通常在 1e-14 级别，经过 toFixed(2) 处理后不会影响显示结果。但在以下边界情况下可能产生问题：

1. 自费金额为0但实际显示-0.00：当 totalCost - reimbursable 的计算结果为 -0.0000000001 时，toFixed(2) 可能显示 “-0.00”
2. 累积误差：多次加减运算后，误差可能累积到影响 toFixed(2) 结果的程度

IVGuard 通过以下措施应对浮点数精度问题：

1. 负值截断：if (summary.selfPay < 0) summary.selfPay = 0 防止负值显示
2. 适时取整：在关键计算节点使用 Math.round(value * 100) / 100 进行四舍五入
3. 显示精度：所有金额显示统一使用 toFixed(2)，保持两位小数一致性

更精确的替代方案

如果需要更高的计算精度，可以考虑以下方案：

1. 整数运算：将所有金额乘以100转换为整数（分），计算完毕后除以100转回元
2. 高精度库：使用 decimal.js 等高精度数学库（需评估包体积影响）
3. 后端计算：将报销计算移至后端，使用支持精确十进制运算的语言（如 Java 的 BigDecimal）

当前版本采用 JavaScript 原生浮点数 + toFixed(2) 的方案，在99.9%的使用场景下精度足够，且不增加额外依赖。

8.6 其他合规考虑

数据隐私

IVGuard 的费用数据存储在本地设备上，不通过网络传输。涉及的用户信息包括：

• 医保参保类型
• 就诊医院等级
• 费用明细（药品名称、金额、日期）

这些信息不涉及身份证号、医保卡号等敏感个人信息，且仅存储在本地，符合《个人信息保护法》的最小必要原则。

医疗器械界定

根据《医疗器械分类目录》和《移动医疗器械注册与备案技术审查指导原则》，单纯的费用计算工具不属于医疗器械，无需进行医疗器械注册。IVGuard 的功能仅限于费用估算，不涉及诊断、治疗建议等医疗行为。

但需要注意以下边界：

• 如果未来增加"根据费用数据推荐用药方案"，则可能触及医疗器械界定
• 如果增加"智能审核医保报销合规性"，也可能触及监管边界
• 当前版本的功能范围明确在"费用计算工具"范畴内，不构成医疗器械

用户知情同意

IVGuard 在首次使用时显示用户协议和隐私政策，明确告知：

1. 费用计算结果仅供参考
2. 参考数据可能滞后于最新政策
3. 用户数据仅存储在本地
4. 不收集、不上传任何个人数据

用户点击"同意"后方可使用应用，确保知情同意。

---

附录

附录A：InsurancePolicy 数据结构

class InsurancePolicy {
  insuranceType: string = ''      // 'urban_worker' | 'urban_resident' | 'rural'
  hospitalLevel: string = ''      // 'level3' | 'level2' | 'level1'
  deductible: number = 0          // 起付线（元）
  classARate: number = 0          // 甲类药品报销比例（%）
  classBRate: number = 0          // 乙类药品报销比例（%）
  ceiling: number = 0             // 封顶线（元）
}

附录B：CostSummary 数据结构

class CostSummary {
  totalCost: number = 0           // 总费用
  drugCost: number = 0            // 药品费用
  otherCost: number = 0           // 其他费用
  classADrugCost: number = 0      // 甲类药品费用
  classBDrugCost: number = 0      // 乙类药品费用
  selfPayDrugCost: number = 0     // 自费药品费用
  reimbursable: number = 0        // 医保报销金额
  selfPay: number = 0             // 自费金额

  static create(): CostSummary {
    return new CostSummary()
  }
}

附录C：CostItem 数据结构

class CostItem {
  id: string = ''                 // 唯一标识
  name: string = ''               // 名称
  unitPrice: number = 0           // 单价
  quantity: number = 0            // 数量
  totalPrice: number = 0          // 总价 = unitPrice × quantity
  isDrug: boolean = false         // 是否为药品
  drugId: string = ''             // 药品ID（isDrug=true时有效）
  date: string = ''               // 日期

  static create(name: string, unitPrice: number, quantity: number,
                isDrug: boolean, drugId: string, date: string): CostItem {
    const item = new CostItem()
    item.id = Date.now().toString()
    item.name = name
    item.unitPrice = unitPrice
    item.quantity = quantity
    item.totalPrice = unitPrice * quantity
    item.isDrug = isDrug
    item.drugId = drugId
    item.date = date
    return item
  }
}

附录D：InsuranceReferenceData 数据结构

class InsuranceReferenceData {
  city: string = ''
  workerDeductible3: number = 0
  workerDeductible2: number = 0
  workerClassARate3: number = 0
  workerClassBRate3: number = 0
  workerCeiling: number = 0
  residentDeductible3: number = 0
  residentDeductible2: number = 0
  residentClassARate3: number = 0
  residentClassBRate3: number = 0
  residentCeiling: number = 0
}

附录E：6城市参考数据完整列表

城市	workerDeductible3	workerDeductible2	workerClassARate3	workerClassBRate3	workerCeiling	residentDeductible3	residentDeductible2	residentClassARate3	residentClassBRate3	residentCeiling
beijing	1300	800	85	80	500000	1300	800	75	70	400000
shanghai	1500	1000	85	80	550000	1500	1000	75	70	450000
guangzhou	1600	800	80	75	600000	1600	800	70	65	450000
hangzhou	1500	800	82	78	500000	1500	800	72	68	400000
chengdu	1200	600	85	80	400000	1200	600	75	70	300000
wuhan	1200	600	85	80	400000	1200	600	75	70	300000

附录F：报销计算快速参考表

职工医保（urban_worker）

医院等级	otherRate	典型甲类比例	典型乙类比例	典型起付线
level3	80%	85%	80%	1200-1600元
level2	85%	85%	80%	600-1000元
level1	90%	85%	80%	300-500元

居民医保（urban_resident）

医院等级	otherRate	典型甲类比例	典型乙类比例	典型起付线
level3	65%	75%	70%	1200-1600元
level2	70%	75%	70%	600-1000元
level1	80%	75%	70%	300-500元