You’re not In-Network with Your Insurance Plan. You’re In-Network with only some of their plans.

Every provider thinks they know their network status. Ask any RCM director which payors they’re contracted with and they’ll tell you without hesitation: Aetna: in-network, Cigna: in-network, or UnitedHealthcare: out-of-network.

The problem is that network status doesn’t live at the payor level. It simultaneously lives at the plan level, the product level, and the geography level. A provider can be in-network on an Aetna PPO and out-of-network on an Aetna EPO, in-network in New York and out-of-network in New Jersey under the same contract.

The assumption that “we know our network status” is one of the most expensive beliefs in the revenue cycle because the payor level isn’t where the determination gets made. It gets made at the claim. And by the time a claim denial surfaces, the intake decision that caused it is already weeks old.

At first glance, this looks like an eligibility problem. Eligibility tells you the patient is covered. Network status tells you whether your coverage, as this specific provider, applies to this patient’s specific plan. Those are different questions. Most verification workflows answer the first one and assume the second.

What Network Status Actually Is

To understand why this breaks so often, you need to see how network status actually works in practice.

A single payor, like Aetna, offers dozens of plan types: PPO, HMO, EPO, POS, HDHP. Within each plan type, there are variations by employer group, geography, and product line.

When a provider says they’re “contracted with Aetna,” what they actually mean is: they’re contracted with a specific subset of plans, in specific states, under specific contract terms. That contract may cover some of those plan types and not others.

Network status also isn’t static. Oftentimes contracts are renewed or plans get restructured. A plan you’re INN with this year may renegotiate next year, or add a product line your contract doesn’t cover. The rules that were right when the contract was signed may not be right when the claim is filed.

Cost-sharing differences between INN and OON services can vary significantly on the same procedure. That gap doesn’t show up in a payor-level assumption. It shows up in the claim or in the patient’s bill. Some payors also don’t cover certain services out of network, so entire modalities of care may be uncovered.

The information required to determine the correct network status for a given patient exists. It’s in your payor contracts: which payors, which plans within those payors, which states, INN versus OON, under what conditions. The problem is that almost no benefits verification workflow encodes those contracts as rules. So the determination gets made by a person, working from memory, from a portal that may not surface it, or from an SOP document that may not reflect current contract terms.

What the Verification Workflow Actually Requires

To understand where network status breaks down, you need to see what a complete verification actually involves for a single patient.

Typically, it starts before the patient calls. The practice has negotiated contracts with payors. Some payors route services through third-party administrators with their own plan configurations, their own portals, and their own rules that don’t always match what the primary payor shows.

When the patient calls to schedule, someone runs an eligibility check. The response comes back: coverage active, benefits available. What it doesn’t return: which specific plan this patient is on, which network tier that plan falls under for this provider, whether the INN benefits shown are the ones that apply to this provider or a different contracted tier.

Someone then needs to verify benefits. This often means calling the payor, navigating to the right representative, and asking the right questions. The representative may or may not have access to plan-level detail. The response may conflict with what the portal or a clearinghouse shows. The portal likely won’t show network status at all.

Someone then needs to cross-reference what the payor returned against the practice’s own contract terms. Which plans are we INN with? Does this patient’s plan fall within that set? In this state? Under the terms that are current, not the ones from the last contract cycle?

In most practices, it’s a memory check, or an SOP check, performed by a staff member working from a document that may not have been updated since the last contract renewal.

When we audit a new health system’s intake workflow at Silna, the most common finding is not a billing team making errors. It’s that the document the intake team is using to determine network status hasn’t been updated in over a year, and nobody flagged it because denials don’t surface until weeks after the intake decision that caused them.

If all of that runs correctly, the patient gets a quote, the claim goes out, and it reflects the right network status. If any piece of it runs wrong (e.g., the wrong plan assumed, the wrong tier applied, the SOP not updated), the error travels forward silently until billing touches it.

When a plan routes through an IPA, a separate layer of attribution and network logic enters the picture. IPA assignment, delegated risk configuration, and referral requirements can introduce error points that remain invisible until billing review.

Why the Standard Tools Don’t Make the Determination

There are four places providers try to get network status right today.

EDI and clearinghouse responses most often return benefits data across multiple network statuses. A standard 271 response may show both INN and OON benefits for the same patient. The tool doesn’t determine which set applies to this provider under this contract. It returns the data and hands the determination back. Someone on staff still has to decide. If they decide wrong, or don’t decide at all and proceed on the first number they see, the error is set.

Payor portals are inconsistent in what they surface. A few show network status explicitly. Many show benefits without indicating whether those benefits apply to this provider at this network tier. A staff member who knows how to read a portal response and cross-reference it against the practice’s contract may arrive at the right answer. One who doesn’t will proceed on what the portal shows, which may be accurate for a different provider relationship entirely.

Internal SOPs are where most practices settle for. Plain-English documents that encode the logic: which payors we’re INN with, which plans, which states, what to do when a response is ambiguous. The logic in those documents is usually right when it’s written. The problem is that contracts change, plans restructure, and the SOP doesn’t automatically update. A new staff member follows it correctly and gets the wrong answer because the underlying contract changed three months ago and nobody updated the document.

Phone calls are also the fallback. The rep on the other end frequently doesn’t have plan-level detail, and the response may contradict what the portal showed.

None of these tools make the determination. They each produce an input. Someone then uses that input to make the determination manually, inconsistently, without access to a real-time, authoritative view of current contract terms.

We’re seeing that the errors that come out of this process are often silent. They travel forward into patient estimates and claim submissions and show up weeks later as denials or unexpected patient balances. By that point, the billing team is working on a problem that was created at intake and that decision is already buried in a workflow nobody is looking at anymore.

Network Status Is Not a Lookup Problem

Here is the frame most verification workflows operate under: network status is a fact you look up. The patient has Aetna, you check whether you’re INN with Aetna, and then you verify benefits under that status.

However, network status is a determination you make by running contract logic against plan-level data. It requires knowing which of the payor’s plans this patient is on, cross-referencing that plan against your contract terms, accounting for geography and product type, and checking that the contract terms you’re applying are current.

The data required to run that logic correctly exists in your payor contracts. The gap is that almost no benefits verification workflow encodes those contracts as executable logic. So instead of the system making the determination, a person makes it by drawing on whatever combination of memory, portal data, and SOP documentation is available to them at that moment.

What Encoding the Rules Actually Looks Like

Silna’s approach to this: providers configure their payor contract rules directly in the platform. Which payors you’re contracted with, which plans within those payors are INN versus OON, for which states, under which conditions. Every benefit verification then runs against those rules automatically. The platform determines the correct network status for that patient, on that plan, in that geography and verifies benefits under the status that actually applies.

When a contract changes, the rules update. The determination isn’t sitting in a spreadsheet or an SOP waiting to drift out of sync with current terms. It runs at the point of verification, against logic that reflects the contract as it stands today.

There’s also a manual override. If a provider needs to verify under a specific network status regardless of what the contract rules return (for a specific patient situation, a carve-out, or an exception), they can. The flexibility is there when the situation calls for it. If there is a call needed, network status is always verified.

Payor contracts are complicated, plan configurations change, and edge cases exist. The point is that it replaces a manual, memory-dependent, SOP-driven process with one that’s configurable, auditable, and updated when the underlying contracts are. That’s a different category of reliability than what an SOP provides.

Where the Revenue Goes

When network status is misclassified at verification, the error runs in two directions at once.

The patient gets a cost estimate based on the wrong tier. A patient quoted INN cost-sharing who is actually OON will face a balance they didn’t expect and weren’t told about. That becomes a collection problem and, more often than it should, a reason the patient doesn’t come back.

The denial comes back weeks later and by the time billing touches it, the intake decision that caused it is buried. The revenue wasn’t lost at billing. It was lost when the wrong network status, determined manually from an SOP that may not have reflected current contract terms, informed the wrong estimate, which informed the wrong claim.

At Silna, we see this pattern repeat consistently: health systems come in estimating their claims denial rate at 8–10%. When we trace denials back to the intake decision that created them, the number is almost always higher, and the gap is sitting in network status errors that were set weeks before any claim was filed.

The billing team is executing on attempting to appeal based on information that was wrong before it reached them. And the staff member who made the wrong determination at intake isn’t the problem either. They were working from the best tools they had: a portal that didn’t show them network status, a clearinghouse response that returned benefits under multiple tiers, and a document someone wrote when the contract looked different.

Or the patient is turned away as ineligible when they are not.

The problem is that network status verification was built as a lookup when it needed to be built as a rules engine. Until it is, the determination will keep getting made manually, inconsistently, and silently wrong.