Reducing over- and under-payments to health care providers（减少对医疗服务提供者的超额支付与支付不足）¶
Industry Sector: Health Care
Business Function: Operations
Managing provider data through contract amendments, state regulations, and health plan-specific requirements is a daunting task which, when mistakes are made, can lead to significant volumes of over- or under-paid health claims. Integrating all this data into Palantir Foundry allows for automatically identifying and surfacing corrections, and approving those corrections to be written back into production systems.
Challenge¶
Managing provider data is difficult due to the number of data sources and complex business-specific rules that must be applied. Ensuring that all rules for contract amendments, state regulations, and health plan-specific requirements are accurately implemented is often done with lengthy manual intervention. The process can involve multiple teams communicating over email, sharing data in Excel, and requesting and making updates manually into production systems.
Provider data is managed differently across enterprises, but at its core, a given provider (TIN/NPI) is assigned a set of codes for a timespan based on their contract and state, which ultimately determines the payment rate for various services. The codes can change at anytime due to a contract amendment, state update, provider retirement, or other.
When mistakes are made, health claims can be over-paid, leading to profit losses and friction with providers if money is recouped, or health claims can be under-paid, also leading to friction with providers due to missed payments. In extreme cases, state government may get involved and implement sanctions.
Incorrectly paid claims is a significant issue for payers - even a 1% increase in payment accuracy can have an important impact on revenue, provider satisfaction, and overall service quality.
Solution¶
Key data sources (contracts, state regulations, sanctions, etc) are integrated into Palantir Foundry, specific business rules are applied to the integrated data, and suggested corrections are surfaced into an operational application for user review.
Specifically, provider data analysts access an application showing a list of proposed updates, ranked from highest to lowest impact on claims volume or dollar value. Clicking on a proposed update will show the proposal, along with the underlying data used to inform the suggestion, enabling the analysts to make a decision on the update. Analysts can make three decisions directly in the application:
- Approve an update: directly applies (writes back) the update to the relevant production system(s)
- Reject an update: removes the update from the queue and registers the justification for rejection for future algorithm improvement.
- Flag an update: moves the update to a separate queue where a different team can validate the underlying data supporting the suggestion, or change it accordingly.
The proposal interface is supported by a dashboard showing performance metrics (number of updates approved/rejected, claims impacted, value of claims rework prevented, etc).
Users and stakeholders¶
- Users: Analysts who review provider data, which typically include Contracting analysts and Provider Data analysts
- POC / Stakeholder: VP or Director of Claims Operations, VP of Provider Data Management
Impact¶
- Prevented tens of millions of claims from paying out incorrectly due to erroneous provider data (both over- and under-payments).
- Significantly reduced the time and labor required to identify and implement corrections to provider data.
- Increased provider satisfaction.
How it's made¶
The tools used are primarily Code Repositories, Workshop, and Quiver.
The crux of this workflow is a strong pipeline that surfaces suggested corrections to provider data setup. It is critical that the data pipeline take into account the specifics of each business rule. This workflow relies on the updates surfaced being accurate.
The updates are surfaced in an operational application where provider data analysts can review updates proposals, their supporting data, and make a decision on whether to accept/reject/flag it. A second applications shows a dashboard where users can review their performance and overall impact to the business.
Implement a similar use case¶
This use case implements the following Patterns. Follow the links below to read more about a particular Pattern and learn how it is implemented within Foundry.
- Alerting workflow (used for 7 other use cases)
- Operational process coordination (used for 8 other use cases)
Want more information on this use case? Looking to implement something similar? Get started with Palantir. ↗
中文翻译¶
减少对医疗服务提供者的超额支付与支付不足¶
行业领域：医疗保健
业务职能：运营
通过合同修订、州法规以及健康计划特定要求来管理提供者数据是一项艰巨的任务，一旦出现错误，就可能导致大量医疗索赔出现超额支付或支付不足。将所有此类数据整合到 Palantir Foundry 中，可以自动识别并呈现修正建议，并批准将这些修正写回生产系统。
挑战¶
由于数据源众多且必须应用复杂的业务特定规则，管理提供者数据十分困难。确保合同修订、州法规以及健康计划特定要求的所有规则都得到准确实施，通常需要大量的人工干预。这一过程可能涉及多个团队通过电子邮件沟通、在 Excel 中共享数据，并手动请求和更新生产系统。
不同企业对提供者数据的管理方式各异，但其核心是：某个特定的提供者（TIN/NPI）会根据其合同和所在州，在特定时间段内被分配一组代码，这些代码最终决定了各项服务的支付费率。这些代码可能因合同修订、州法规更新、提供者退休等原因随时发生变化。
一旦出现错误，医疗索赔可能被超额支付，导致利润损失，并在追回款项时与提供者产生摩擦；或者医疗索赔可能被支付不足，同样因未足额支付而与提供者产生摩擦。在极端情况下，州政府可能会介入并实施制裁。
错误支付的索赔对支付方来说是一个重大问题——即使支付准确率仅提高1%，也能对收入、提供者满意度以及整体服务质量产生重要影响。
解决方案¶
关键数据源（合同、州法规、制裁信息等）被整合到 Palantir Foundry 中，对整合后的数据应用特定的业务规则，并将建议的修正呈现到一个运营应用程序中，供用户审核。
具体来说，提供者数据分析师访问一个应用程序，该程序显示一份建议更新列表，按对索赔量或金额的影响从高到低排序。点击某个建议更新，将显示该提案以及用于支撑该建议的底层数据，使分析师能够对该更新做出决策。分析师可以直接在应用程序中做出三种决策：
- 批准更新： 直接将更新（写回）应用到相关的生产系统中。
- 拒绝更新： 将该更新从队列中移除，并记录拒绝理由，以便未来改进算法。
- 标记更新： 将该更新移至另一个队列，由不同的团队验证支撑该建议的底层数据，或据此进行修改。
提案界面由一个仪表盘提供支持，该仪表盘显示绩效指标（批准/拒绝的更新数量、受影响的索赔、防止的索赔返工金额等）。
用户与利益相关者¶
- 用户：负责审核提供者数据的分析师，通常包括合同分析师和提供者数据分析师。
- 联系人/利益相关者：索赔运营副总裁或总监、提供者数据管理副总裁。
影响¶
- 防止了数千万起因提供者数据错误而导致的索赔支付错误（包括超额支付和支付不足）。
- 显著减少了识别和实施提供者数据修正所需的时间和人力。
- 提高了提供者满意度。
实现方式¶
主要使用的工具包括 代码仓库、Workshop 和 Quiver。
此工作流的核心是一个强大的数据管道，用于呈现对提供者数据设置的建议修正。关键在于数据管道必须考虑每条业务规则的细节。该工作流依赖于所呈现更新的准确性。
这些更新呈现在一个运营应用程序中，提供者数据分析师可以在其中审核更新提案及其支撑数据，并决定是接受、拒绝还是标记该更新。第二个应用程序显示一个仪表盘，用户可以在其中查看自己的绩效以及对业务的整体影响。
实施类似用例¶
本用例实现了以下模式。点击下方链接可阅读关于特定模式的更多信息，并了解其在 Foundry 中的实现方式。
想了解更多关于此用例的信息？希望实施类似方案？立即开始使用 Palantir。 ↗