The cheapest denial to fix is the one stopped at the front door.

Section 02 · the transactionThe anatomy of a 270 and its 271.

You cannot manage what you treat as a black box. The 270 inquiry and the 271 response are structured documents with named loops and segments, and every eligibility denial you will ever receive traces back to a segment that was either not asked for, not returned, or not read.

The ASC X12N 270/271 pair is the HIPAA-named standard for eligibility and benefit inquiry and response, maintained by X12 and operationalized by the CAQH CORE operating rules. The 270 travels outbound from the provider and names four parties in nested hierarchical loops: the information source, which is the payer; the information receiver, which is the provider or clearinghouse; the subscriber; and, when the patient is not the policyholder, the dependent. Inside the subscriber or dependent loop, the inquiry carries identity segments and one or more service type codes that declare which benefit you are asking about.

That last part is where most implementations quietly underperform. A generic inquiry using service type code 30, health benefit plan coverage, answers only "is this person covered by anything." It does not reliably return the deductible status, copay, and prior authorization requirement for the service you are about to render. Asking at the service level is what converts an eligibility check into a verification of benefits. CAQH notes that the National Committee on Vital and Health Statistics recommended to HHS in June 2023 an updated CORE Eligibility and Benefits Data Content Operating Rule set requiring plans to return telemedicine benefits, prior authorization status, remaining coverage benefits, tiered benefits, and procedure-level detail. The direction of travel is more granularity, and providers who ask coarse questions today will still get coarse answers when the rule lands.

Read the response like a claim, not like a checkbox

A well-built verification does five things with a 271 that a checkbox implementation does not. It stores the effective and termination dates rather than a boolean. It stores remaining deductible and out-of-pocket amounts with the timestamp they were true. It keeps the other-payer segment even when a primary is already on file, because a new secondary appearing is a signal. It preserves free-text remark segments rather than discarding what the parser did not recognize. And it treats an AAA rejection as work to be assigned, not as an answer.

The ASP-RCM stack parses the 271 into structured benefit detail per service code: in-network and out-of-network deductible status, copay, coinsurance, out-of-pocket maximum, prior authorization requirement by service code, specialist referral rules, mental health and substance use parity exceptions, and ABA authorization rules where applicable. Round trip runs under 300 milliseconds at the 95th percentile through the gateway, against a clearinghouse baseline near 1.2 seconds. That latency figure is not vanity. When verification is fast enough to run synchronously at intake, it happens on every patient. When it is slow, staff learn to skip it.

Section 05 · the ordering problemKnowing who covers the patient is not the same as knowing who pays first.

Coordination of benefits is where correct eligibility still produces a denial. Every payer is confident it is not primary, and the burden of proving otherwise sits with the provider who submitted in the wrong order.

Order of benefits is governed by three different rule sets depending on who is involved, and mixing them up is the most common cause of a coordination denial. Between two commercial plans the ordering derives from the National Association of Insurance Commissioners coordination of benefits model regulation as adopted in each state: a plan covering a person as an employee or subscriber pays before a plan covering the same person as a dependent, and for a dependent child covered by two parents who are not separated or divorced, the birthday rule applies, meaning the plan of the parent whose birthday falls earlier in the calendar year is primary. Court decrees, active-employee versus retiree or COBRA status, and length of coverage break the remaining ties.

Where Medicare is involved, the framework is Medicare Secondary Payer, codified at 42 U.S.C. 1395y(b) and administered through the CMS Medicare Secondary Payer Manual, Publication 100-05. The main triggers are the working aged provision, disability with a large group health plan, the end-stage renal disease coordination period, and situations where workers compensation, no-fault, or liability insurance is responsible. CMS is explicit that running a 270/271 does not relieve a provider of the obligation to ask the MSP questions when insurance information has changed or is uncertain, and directs that MSP eligibility questions go to the plans identified in the 271 response. The HIPAA Eligibility Transaction System, the CMS real-time route for Medicare beneficiary eligibility, has returned non-group health plan MSP diagnosis codes on eligibility responses since the CMS HETS information bulletin of September 6, 2023, so providers can see which payer is primary for a category of care.

Medicaid sits at the end of the chain by statute. Section 1902(a)(25) of the Social Security Act and the third-party liability rules at 42 CFR 433.139 make Medicaid the payer of last resort, so every other liable payer must be identified and billed first. In practice that is a discovery problem rather than a sequencing problem: a Medicaid coordination denial almost never means staff ordered the payers wrong, it means nobody knew the commercial policy existed.

The operational lesson is that MSP screening is a conversation, not a query. The 271 tells you which plans exist; it does not tell you whether the spouse is still actively employed or whether last week's back pain is a work injury. CMS treats the questionnaire as an obligation precisely because the transaction cannot answer those questions. Build the screening questions into intake, record the answers with a date and an initial, and the appeal you eventually write will have something to stand on.

Section 08 · the workflowAutomation's real output is a shorter queue, not an empty one.

A verification stack that clears 90 percent of a panel automatically has not eliminated human work. It has concentrated it. The design question that decides whether the program succeeds is what happens to the remainder.

Every 271 lands in one of three states. Clean, meaning coverage is confirmed with usable benefit detail and it writes back to the practice management system without a human touching it. Rejected, meaning the payer returned an AAA segment because the subscriber was not found, the identifier was invalid, or the provider is not on file. Or ambiguous, meaning something came back but it does not answer the question: a coverage-active response with no benefit detail, a plan name that does not match the card the patient presented, or a Medicaid managed care response naming an organization you are not contracted with.

The failure mode in most shops is that the second and third states get treated as the first. A queue nobody owns becomes a report nobody reads, and every unresolved AAA in that report becomes a CARC 31 denial about 45 days later. The fix is unglamorous: name an owner, set a service level, and make the queue the only path out of the ambiguous state. Clean results never wait on a person, and no exception ever bypasses one.

One further behavior separates a mature program from a busy one. When a plan migration is detected mid-cycle, in-process claims should be rebilled under the corrected policy automatically rather than waiting for the denial to arrive and be worked. Catching the change is only half the value; acting on it before adjudication is the other half, and it is the half that keeps the correction out of the denial statistics entirely.