健康计划：BI显示MLR变动，AI能解释原因吗？

一位健康计划的首席财务官在经历了一轮惯常的数据提取、电子表格和人工对账之后完成月度结账，发现财务数据因高于预期的医疗赔付率（MLR）而落后于预算。BI 仪表板可以快速呈现这一差异。但“MLR 上升”并不是真正的答案。它是问题的开端。

• 是哪条业务线或哪个市场在推动它？
• 是理赔成本上升了吗？如果是，是由于利用率、单位成本还是服务组合？
• 是某个团体或产品定价错误了吗？
• 人群发病率发生变化了吗？
• 可以采取什么纠正措施？

AI 在支付方财务中的真正机会不在于识别差异。而在于理解是什么导致了差异以及如何应对。

金融领域的 AI 转型会同时带来三件事的变化。答案在几分钟内即可获得，而不是一个报告周期。领导者可以自行深入下钻，无需预设报告或等待分析师。AI 可以超越理赔、收入和会员数据，延伸到临床信息、质量指标和风险评分，同时读取所有这些内容，以评估是什么在驱动差异。

当数据和业务领域的专业知识各自孤立时，这项工作从来都不切实际。那么挑战就变成了：AI 能否对健康计划的数据和业务有足够的理解，使财务部门能够信任其洞察并据此行动。

这正是 Databricks 和 Abacus 的结合之处。Databricks 提供数据和 AI 能力，让组织能够以新的方式与受治理的企业数据交互。Abacus 带来支付方专属的数据基础、业务背景和运营知识，这些能力在涉及医疗财务的问题时正是所需的。

从找到洞察到提出下一个问题

多年来，商业智能的运作方式是预判某人可能想问的问题。团队构建报告。分析师创建仪表板。高管审阅某人决定放在页面上的指标。

当某个数字发生变化时，弄清楚原因意味着要离开仪表板，找到合适的分析师或团队来调查，再拉取一份报告或协调多个记录系统。而每一个答案都会留下一些东西：又一份要运行的报告，又一个要构建和维护的仪表板。当下一个问题到来时，每一个都已经过时了。

团队工作更多，回报却递减。

对话式 AI 改变了这种交互模式。财务领导者不再止步于仪表板设计要展示的内容，而是可以用通俗语言提出问题、得到答案，并基于刚刚了解到的情况继续追问。这种体验开始变得不那么像浏览报告，而更像是在调查业务。

真正被打破的是两类专业知识之间的壁垒。高管了解业务并拥有决策权，但无法查询数据；分析师了解数据、数据存放在哪里、如何结构化、如何操作它，但并不总是知道哪个问题重要。AI 消除了这种交接：需要答案的人现在可以直接去问。

但这种对话的质量取决于 AI 在其底层理解了什么。

AI 需要的不仅仅是数据访问权限

多年来，数据现代化问题主要关乎访问：我们能否把理赔、会员、提供方、合同、临床和财务数据汇聚在一起，以便人们使用？这一点仍然至关重要，但 AI 增加了另一项要求。它需要理解这些数据的含义。

以 MLR 这个指标为例，它是指保费收入中用于计划会员医疗护理的份额。定义容易，计算却很难。理赔和保费来自不同的结构和不同的时间线，而“医疗”费用实际上是一堆组成部分，包括医疗理赔、药房理赔和返利、已发生但未报告（IBNR）、支付完整性追回款、风险调整转移、提供方结算等等。然后还必须按业务线、市场或产品进行切分，而定义这些分组需要并非开箱即用的业务逻辑。

没有这种背景，AI 系统即使能够访问海量数据，也仍然无法产生足够的洞察。

这些业务背景中的大部分传统上存在于不同的地方：

• 数据模型、
• 报告逻辑、
• 文档、
• 电子表格、
• 机构知识，以及
• 构建这些报告的人的大脑里。

为了让 AI 可靠地回答财务问题，更多的这种背景必须变得明确、一致且可复用。

这就是为什么支付方专属的数据基础很重要。健康计划数据并不会以围绕高管想提的问题整齐组织好的形式到来。理赔、资格、提供方、合同、临床和财务信息来自不同的系统，格式不同，关系和时序也不同。在 AI 能够有效地跨这些数据进行推理之前，数据必须以一种反映健康计划运营方式的方式被连接和组织起来。

Abacus 提供了这样的支付方专属基础：将医疗保健数据汇聚到一致的结构中，并添加理解会员、理赔、提供方、合同、临床信息和财务指标之间关系所需的业务背景。

即便基于相同的底层数据，“同一个”指标也常常因计算者不同而有不同的定义。一个版本出现在 CFO 的月度报告包中，另一个版本出现在临时分析请求中，最终总得有人去协调它们。AI 无法自行解决这个问题。如果没有一致的定义，它反而会放大这个问题。

对财务领导者来说，问题不仅仅是准确性。而是要有信心，相信答案反映了业务的运营方式。

正是这些让财务、精算和运营团队能够基于一致的绩效视图开展工作的定义，也为 AI 提供了正确解读问题所需的上下文。目标不仅仅是让数据存在于一个地方；而是在数据被使用的任何地方，对数据的含义保持一致的理解，无论是一位高管以对话方式提问，还是分析师在制作传统报告。

从差异到行动

回到那位 CFO。MLR 超出预算。在哪里？是什么驱动的？哪些人群、服务或提供者造成了这一变化？组织接下来应该做什么？

每个问题都比前一个需要更多的上下文。第一个问题需要一项财务指标和预算对比。第二个问题需要差异之下的各个组成部分。第三个问题跨越了理赔、会员、提供者、合同和护理管理数据。到第四个问题时，对话已经从财务报告转向了运营。

这就是为什么真正的机会不在于以更好的方式展示某个 KPI。而在于一条从高管信号到运营层面双击下钻的连通路径，让财务部门能够走完这条路，而不必反复把问题交回给分析师去核对另一套报告或数据点。AI 并不取代关于组织应该做什么的判断；它缩短了从看到某些东西发生了变化到充分理解它从而能够采取行动之间的距离。没有来回往返，每次迭代都更快，而更快的迭代会提升决策本身的价值：护理管理活动更早启动，新兴趋势更早被纳入定价，纠正措施可以在仍能改变结果的时候实施。

一个支付方智能基础，回答众多问题

MLR 是一个有用的例子，因为它处于财务与运营的交汇处，但其底层架构并不专属于 MLR。同样的互联支付方数据和业务上下文可以支持支付完整性、护理总成本、风险调整、质量和提供者绩效等各方面的问题。

这改变了健康计划思考 AI 投资的方式。另一种选择是一堆彼此割裂的 AI 用例，每一个都围绕自己的数据、自己的定义和自己对业务的视图来构建。这正是健康计划多年来试图消除的那种碎片化，只不过上面加了一个 AI 界面。

一个通用的支付方智能基础开辟了一条不同的路径：把底层数据和上下文一次性做对，然后随着新问题、新工作流和新 AI 体验的出现而复用它。

一个已经跨用例连接并情境化其数据的健康计划，在新问题出现时具有先发优势。在一个基础上，AI 可以同时审视多个领域，而不是一次只看一个。糟糕的绩效很少由单一变量驱动，无论是承保、护理管理、风险调整、质量、网络还是提供者参与。重要的是它们之间的相互作用，然而这种多层面的问题如今很难回答，因为每个领域都掌握在不同的团队和数据集手中。

Databricks 与 Abacus 如何协同工作

Databricks 和 Abacus 解决这个问题的不同部分。Databricks 提供数据与 AI 平台能力，用于治理企业数据和构建 AI 驱动的分析体验，包括允许业务用户以自然语言询问组织数据的对话式体验。

Abacus 带来了这些体验所依托的支付方专属基础：经过规范化和连接的医疗数据、支付方专属模型和业务上下文，以及对信息如何在健康计划财务和运营工作流之间流动的深刻理解。

这一区别很重要。通用平台为构建 AI 体验提供了强大的能力，但健康计划数据带有支付方环境特有的术语、关系、业务规则和运营复杂性。正是捕捉这些上下文，才使那些能力能够回答健康计划领导者所提出的问题。

Databricks 和 Abacus 共同开辟了一条从 AI 就绪技术到 AI 就绪支付方数据、最终到反映健康计划运营方式的答案的路径。

支付方财务面临的下一个问题

对支付方财务而言，有趣的问题不再是 AI 能否生成答案。而是这个答案是否足够理解业务，从而有用且值得信赖。

当一位 CFO 问为什么 MLR 发生了变化时，技术应该做的不仅仅是呈现差异。它应该帮助财务部门顺着这个问题穿越底层支付方数据、理解发生了什么变化，并推动组织更接近行动。这需要界面之下有受治理的数据、共享的业务含义和支付方专属上下文——而这正是 Databricks 和 Abacus 正在共同努力实现的目标：不仅仅是让健康计划数据更容易查询，而是让答案对负责据此采取行动的人更有用。

欢迎在 9 月 17 日太平洋时间上午 9 点开始的我们的网络研讨会上观看实际演示。预留您的席位，点击这里！