- Claims take 60 to 90 days to travel from patient visit to your reporting system. Your 'current' utilization data is a picture of the world from three months ago.
- Value-based contracts are particularly exposed because performance is measured on the same lagged data used to make real-time decisions.
- Completion factors and IBNR — concepts actuaries use routinely — should be standard tools in every VBC operations team.
This is the conversation I have had more times than I can count. A care management director is frustrated that their outreach program is not moving the needle. A CFO is confused about why their cost trend looks better than what the actuaries are projecting. A quality team is chasing HEDIS gaps that seem to close on their own.
In almost every case, when we trace the problem back to its root, we land in the same place: the data being used to make decisions is not as current as anyone assumes. Claims data, which is the backbone of nearly every VBC workflow, does not travel in real time. It travels through a long pipeline with multiple stops, and by the time it appears in a report, the world has moved on.
This is not a technology failure. It is not a vendor problem. It is simply how claims move through the healthcare system. But most VBC teams have never sat down and mapped out exactly how long that journey takes, which means they are making forward-looking decisions on backward-looking data without fully realizing it.
What happens between a patient visit and a line in your report
The journey of a claim is longer than most people picture. Here is what it actually looks like from the moment a patient leaves the office to the moment that visit shows up as a data point in your VBC dashboard.
Every step takes time, and the steps do not always run back to back. Providers have up to 365 days to submit a claim after the date of service. Many submit within 30 days, but small practices, rural providers, and hospital outpatient departments often run later. The clearinghouse validates the format and routes it, typically within a few days. The payer then adjudicates: they check eligibility, apply benefit rules, coordinate benefits if needed, and either pay, deny, or pend the claim for more information. That process alone can take two to six weeks. The 835 remittance file then travels back, gets loaded into the billing system and, eventually, into a data warehouse where analysts can see it.
Think of it like sending a letter through a postal system that has six different sorting facilities, each with its own processing team and queue. The letter left the doctor's office. You just do not know which stop it is currently sitting at, or how many stops are left.
Why this hits value-based contracts harder than anything else
In a traditional fee-for-service model, claims lag is an administrative inconvenience. You did the work. You submitted the claim. You got paid, eventually. The timing of when the data shows up in a report does not change the fundamental transaction.
Value-based contracts work differently. They are built on forward-looking decisions. Gap closure programs, care management outreach, risk stratification, quality measure tracking, performance reporting. All of these require you to look at what is happening now and decide what to do next.
The problem is that 'what is happening now' in a claims-based system is always a picture of what happened 60 to 90 days ago.
Imagine trying to navigate a city using a GPS that shows you where every car was 90 days ago. The roads are the same. But the traffic is completely different. You would take a different route if you could see what is actually happening right now.
That is the core problem with lag-unaware VBC operations. The road map is accurate. The real-time conditions are invisible. And most teams are making routing decisions as if the two are the same thing.
Four ways incomplete data is breaking real VBC workflows
These are not hypothetical. Each of these is a pattern I have seen repeatedly across health plans, ACOs, and provider groups operating in value-based arrangements.
A concrete example: the same report, three months apart
Let me make this tangible with a specific scenario that is representative of what we see when we pull the same report at different points in the data maturity cycle.
The team made a reasonable decision with the data they had. The problem is that nobody flagged that the data was incomplete. The report looked like a complete picture. It was not.
The IBNR problem: actuaries know this. Most ops teams do not.
In insurance, there is a concept called IBNR: Incurred But Not Reported. It refers to claims that represent real events, real patient encounters, real cost, but have not yet been received and processed by the payer.
Actuaries account for IBNR every time they set reserves or project future costs. They know that the claims currently in the database are not the full picture. They build a liability for the work that has already happened but has not yet been submitted. This is standard actuarial practice.
Most VBC operations teams do not have a parallel concept. They look at the claims that are in the database and call that the reality. They build strategies on it.
Imagine you run a delivery business and you track every package that has been signed for at the destination. You have a complete record of all delivered packages. But there are another 500 packages still on trucks somewhere between the warehouse and the door. They are real. They represent real cost and real activity. They just do not appear in your count yet. If you make capacity and routing decisions based only on the signed packages, you are systematically undercounting your real volume. That is exactly what most VBC teams are doing with claims data.
The gap between what is in the system today and what will eventually be in the system is your IBNR exposure. It is not hypothetical. It is real cost and real utilization that has already occurred. It just has not been billed yet.
What 'mature' data means and why the 90-day rule is a starting point, not a finish line
In healthcare analytics, a claim is considered 'mature' when enough time has passed that the realistic window for submission and adjudication is essentially closed. A common rule of thumb is 90 days after the date of service for most outpatient claims. For inpatient stays, specialty care, and complex cases, the window is longer: 120 to 180 days is more appropriate.
Before that window closes, your data is incomplete. Not wrong, but incomplete. Like a puzzle with missing pieces. You can see the general shape of the picture, but you would be making a mistake to call it finished.
The practical implication: if you are measuring performance for a period that ended 30 days ago, you are looking at a puzzle where somewhere between 30 and 40 percent of the pieces are still in transit. If you are measuring a period that ended 120 days ago, you are looking at something very close to the final picture.
This is why finance teams and actuaries always wait for run-out periods before trusting cost or utilization figures. The data needs time to run out fully before it tells the true story. Most VBC operations workflows are not built with this waiting period in mind.
Building a lag-aware VBC operation
The goal is not to eliminate lag. You cannot. It is structural to how claims move through the system. The goal is to stop treating immature data as if it were mature, and to build your workflows around what the data can actually tell you at each stage of its maturity.
Label every report with its data age, not just its date range
A report covering January through March means nothing on its own. What matters is when the data was pulled. A pull on April 1 is looking at very different data than a pull on July 1, even though both are labeled 'Q1.' Add a data pull date and a maturity indicator to every report so decision-makers know what they are working with.
Use completion factors to estimate mature values from immature data
A completion factor is a multiplier that adjusts immature data toward its expected mature value. If historical patterns show that 45-day data is typically 68 percent complete for your population, you can divide the raw number by 0.68 to approximate the mature value. Actuaries use completion factors routinely. VBC analytics teams rarely do. Building them into your reporting layer turns incomplete data into a directional signal rather than a misleading absolute.
Never trigger member-level actions on data under 60 days old
Build a rule into your care management workflows: any outreach or action triggered by a clinical gap or utilization flag must be based on a date of service that is at least 60 days in the past. This one rule alone eliminates most of the false-positive gap closure and risk stratification errors described above.
Separate your strategic and operational reporting layers
Operational reports, such as this week's admissions or this month's ED visits, are inherently immature data. They are useful for spotting directional trends and recent events but should never be used for performance evaluation or contract benchmarking. Strategic reports, such as annual cost trends, quality measure rates, and shared savings projections, should only be run on data with a full run-out period applied.
Build dual views into your dashboards
Show a 'current snapshot' view alongside a 'mature period' view so decision-makers understand they are looking at two different lenses. The current snapshot tells you what is happening. The mature period tells you what actually happened. Both are useful. Treating them as the same thing is where the mistakes happen.
Apply an IBNR buffer to all mid-year financial projections
If you are projecting shared savings, risk corridor performance, or total cost of care at any point during the year, you need to explicitly account for claims not yet in the system. Work with your actuarial team to develop an IBNR estimate specific to your population and provider mix. It should be a line item in every mid-year financial projection, not an afterthought.
Five questions to ask before trusting any VBC report
Claims data lag is one of those problems that feels invisible until someone makes a decision it cannot support. The team chases gaps that are already closed. The CFO gets surprised by cost trends that were predictable. The care management program targets members who no longer need the intervention. None of these failures look like a data problem from the outside. They look like an execution problem, or a performance problem, or a program design problem. The data gets blamed last, if at all.
The fix is not a new data warehouse or a faster ETL pipeline. It is building the organization's relationship with data maturity into every workflow that touches VBC decisions. That means labeling reports with their data age, building completion factors into projections, setting rules for when data is mature enough to act on, and having an honest conversation about IBNR at every financial review.
It is unglamorous work. But it is the difference between a VBC operation that makes decisions on what is actually happening and one that is always, unknowingly, making decisions on what happened three months ago.
Is your VBC data pipeline working against you?
We help health plans, ACOs, and provider groups build data maturity frameworks, completion factor models, and reporting layers that reflect what is actually happening, not what happened 90 days ago.
