Complexity 1: We generally do not receive claims in a timely manner

If we always received the claim data during the same month in which the visit occurred, things would be much simpler, but we receive the claim data only after it has been paid and that can take several months. Medicaid pays 99% of their claims within 90 days, whereas commercial payers generally average about 85% payment within 90 days.

Complexity 1a: We have to process data through the entire program period each time we receive new claim data

If our data was always up-to-date (i.e. the data dump at the end of August always included all of August’s claims), we could potentially only process the new data and append it to the existing data. But since we receive older claims, we have to recalculate and update the data for the entire program period.

This isn’t particularly hard – it just forces us away from some of the easier approaches.

Complexity 1b: What numbers do we report if we don’t have up-to-date data?

Let’s say we are in early October and we just received the most recent claim data for September. How do we show the September numbers when we only have a small percentage of September’s claims?

There are two common ways to handle this:

• Runout. The program defines a runout period (normally 90 days) and we only process claims up to the start of the runout period. So when we receive claims through October 31, we only report data through the end of July (July + 3 months = October).
  • This provides relatively accurate data, but the reporting is always behind.

• Completion factors. Our partners provide completion factors, which are actuary numbers by which to boost the numbers. For example, if the claim data up through October 31 contains:
  • 10% of October’s claims, the October factor can be 10 (so the claim data that we do have is amplified 10X).
  • 50% of September’s claims, the September factor can be 2.
  • 35% of August claims, the August factor can be 2.857.
  • This provides more up-to-date information, but the most recent data is estimated.

Complexity 1c: Attribution changes and restatement

Imagine that I saw a new doctor (Dr. New, because I was tired of Dr. Old) in February, but for some reason the claim was not paid until August (so we first process it sometime in September). Every month we determine that Dr. Old is my attributed doctor, but then in September we determine that I should have been attributed to Dr. New for the past six months. This is usually handled one of two ways:

• We make the change retroactively, which has a big ripple effect on both Dr. Old’s data and Dr. New’s data. Providers generally don’t like seeing so much difference between the monthly reports.

• We keep me attributed to Dr. Old through the end of July, and then change my attribution to Dr. New in August. This keeps the reports less noisy, but it’s also not accurate. To counter this, they will occasionally ask us to do a restatement, which would fix teh attribution to Dr. New in February. These restatement reports can be noisy, but at least they can better anticipate the noise better.

Complexity 1d: We need to include true-ups in our monthly payments 

This is related to the above complexity, but it is a little more complicated. Imagine these two scenarios:

1. After a restatement, we realize that we made monthly payments to Dr. Old rather than to Dr. New. We need to adjust this, such that we reduce payment for Dr. Old (to account for the incorrect payments) and make a one-time larger payment to Dr. New to account for his lack of payment.

2. I stay attributed to Dr. Old for the entire program period, but I was super healthy until I had a heart attack In February. This means that my risk score is much higher and starting in February, the capitation payments made to Dr. Old should also be much higher. But I don’t receive the claim for the heart attack until September, so we need to adjust September’s payment to make up for the difference.

The true-up scenarios can become somewhat complicated.

Complexity 1e: We have to run two sets of program logic through the first half of the year

Programs usually have a full six month run out on the final payment. In other words, if the program year ends in Dec 2024, we normally don’t close out the program until after June 2025 (to ensure that we have the most of the data). As we receive new claims in 2025, we update the numbers for program year 2024. 

Assuming that the partner also contracted for the 2025 version of the program (which normally contains some updates to the 2024 version), when we process new data in May 2025, we have to process the claims from 1/1/2024 – 12/31/2024 using the 2024 program logic, and the claims from 1/1/2025 – 4/30/2025 using the 2025 logic.

If the report wants to compare numbers across years, however, we normally need to use the 2025 logic for both the new numbers and the comparison numbers. Hence, we may have to process the 2024 claims twice – once using the logic from the 2024 program logic and again using the 2025 program logic.

Complexity 2: Programs can change during the program year

This may seem counter-intuitive, but it is common to update a program during the program year. For example, they might schedule a change to the attribution look-back window to start on June 1st. These changes are usually retroactive to the beginning of the program year, but not always.

Sometimes these changes are sufficiently large that it might require a new contract, and if a provider doesn’t sign the contract, they may continue to use the original rules while other providers use the updated rules.

Complexity 3: Dynamic member and attribution changes can break the program

If a program does entirely different things for a pediatric member vs. an adult member, how does that work if the member becomes an adult during the program year?

Likewise, if a doctor gets a monthly capitation payment or a care coordination fee based on monthly granularity, what happens if the attribution changes in the middle of a month?

Some programs simplify this by ensuring that neither of these can happen.

• For the member’s age, they might:
  • Use the member’s age at the beginning of the period.
  • Use the member’s age at the end of the period.
  • Use the member’s age on an arbitrary date within the period.
  • Hence, we might treat a pediatric member as an adult or visa versa.

• For the monthly attribution, they might:
  • Use the attributed provider at the beginning of the month.
  • Use the attributed provider at the end of the month.
  • Use the attributed provider at an arbitrary point of the month.
  • Use the provider who is attributed for the most number of days within the month.

Programs also have rules involving which providers get paid for which members. For example, imagine that Jan – June I am attributed to Provider Old and Aug – Dec I am attributed to Provider New. While (I think) that both providers get to keep their 6 monthly capitation/care coordination fees, the yearly bonus payment can be handled many different ways:

• Both providers are scored against the months that they were attributed and each gets credit for 6 member months associated with the patient (i.e. both get a piece of the pie).
• Sometimes only the attributed provider at the end of the program year gets paid (e.g. Provider New). In this case, either:
  • Provider New is scored and paid as if the member were attributed to them for the entire period.
  • Provider New is scored and paid for the six months that they were attributed.
• Neither gets paid as they might require that they are attributed for more than six months.

Complexity 4: Computing member metrics gets confusing when attribution changes

A member’s attribution to a provider can change multiple times through the program year. This sounds easy, but:

• It’s possible that the metric logic is different for each provider (depending on contract overrides). For example, I might disregard specific claims for Provider New, but not for Provider Old.
• Do I assign member months to Provider Old if they are not attributed at the end of the contract year?
• Some programs cap the dollar amount associated with a patient. For example, if I cost the insurance company $1,000,000 in 20204, their program logic might cap that to $150,000 (to reduce punishing providers for their outlier members). But this cap may reset across providers, such that my total cost of care might be $150,000 if I were only attributed to a single provider, but it could be $300,000 if my attribution were split between two providers.

Complexity 5: Other contracting complexities

Programs may have different rules to handle:

• Providers that join a program partway through the program year.
• Providers that decide to leave the program during the program year.
• Providers that merge with other providers.
• Providers that de-merge to form two separate legal entities.

Each program has their own rules for handling these situations.