1. Name every service type
22 codes, one 270
Therapy, behavioral health and dental asked by name [1], never inferred from a general request.
Home / Case studies / Eligibility verification
Case study · Engine results, eligibility and benefits
Verification of benefits in one call: 22 service types per 270, second calls 23% to 0, and the 271 that lied by omission
Short answer: CorePulse named 22 service types in one 270 and the second billed call went from 33 of 141 to 0. Reading 791 stored general-request 271s, therapy benefits appeared 11% of the time and the authorization flag 0%; the parser was also filling blanks with $0, 10,574 times.
658 rows · 650 usable 271s22 service types · one 270791 stored 271s readBlank = VERIFY, never $0
Focus
VOB
Audience
Front desk
Metric
Second calls
Codes
22 service types
Framework
X12 270/271
Length
5 min
23% to 0
Share of verifications that needed a second billed 270, before and after asking 22 service types at once (33 of 141 to none) ASP-RCM engagement records
98.8%
Of 658 batch rows returned a usable 271 (650), covering 497 members and 7,186 benefit rows ASP-RCM engagement records
11%
Of 791 general-request 271s carried physical therapy benefits; the authorization indicator came back 0% of the time ASP-RCM engagement records
10,574
Fabricated $0 out-of-pocket maxima found in 12,484 parsed rows and reduced to 0 after the parser fix ASP-RCM engagement records
The batch and the question we asked of it
CorePulse, our eligibility verification engine, sent 658 eligibility rows for a multi-site health center in one batch: 650 usable, 497 unique members, 7,186 benefit rows across 132 service types.
Coverage outcome of the batch
Medical, dental and behavioral health lines, August 2026. Rebuilt from stored responses, zero new transactions.
Usable 271 returnedof 658 rows sent
65098.8% of 658
Active coverageof 650 usable
42465% of 650
Exceptionspayer answered, person needed
7812%: name mismatch, wrong payer, a benefit the 271 cannot express
Inactiveno active coverage
244% of 650
0200400600658 rows
TransportActiveExceptions to a personInactive
One verification, end to end
- 1270 built22 STCsEvery service type the client bills, named [1]
- 2271 returnedHTTP 200Stored raw, re-parsable, zero repeat transactions
- 3Parser with guardsblank = VERIFYNo default fills; network tiers never mixed
- 4Precedence resolverauth answerPayer policy layered on the 271
- 5Desk screenor exceptionBenefits per service type; 78 exceptions routed to a person
22 service types in a single 270
A verification that needed therapy or behavioral detail often meant a second billed transaction: 33 of 141, 23 percent. Naming the 22 service-type codes the client bills removed it.
Service types returned per payer, general request versus 22-type request
Payers anonymized. Every 22-type call returned HTTP 200, 0 rejections. Payer C is the ceiling: some payers answer thin however you ask; that row goes to a person.
13
Payer Ageneral request
22
+69%
Payer A22-type request
5
Payer Bgeneral request
21
+320%
Payer B22-type request
1
Payer Cgeneral request
6
+500%
Payer C22-type request
General request22 named service typesStill thin: phone or portal check
| Measure | Before | After |
|---|---|---|
| Verifications needing a second 270 | 33 of 141 (23%) | 0 |
| Service-type codes per request | General request | 22 named codes [1] |
| Transport result | n/a | Every call HTTP 200, 0 rejections |
| Service types returned, three payers | 13, 5, 1 | 22, 21, 6 |
The 271 that lies by omission
Presence of each benefit in 791 stored general-request 271s
Diagnostic read, August 2026. A front desk would see no therapy limit and no authorization flag, and both would be wrong by silence.
Dental benefitspresent
90%712 of 791
Mental health benefitspresent
84%664 of 791
Physical therapy benefitspresent
11%87 of 791, 8x less than dental
Authorization-required indicatorpresent
0%0 of 791
025%50%75%100%
Returned reliablyReturned oftenMissing: must be named in the 270
Fabrications found and removed, 12,484 rows
Each came from a default where a blank should have been. August to September 2026.
| Misstatement | Rows before | Rows after |
|---|---|---|
| Out-of-pocket maximum shown as $0 with no payer value | 10,574 | 0 |
| Deductible filled with no payer value | 9,139 | 0 |
| Copay shown as $0 with no payer value | 2,729 | 0 |
| In-network and out-of-network figures mixed | 4,122 | 0 |
| Out-of-network deductible filled from in-network, share of responses | 34% | 0 |
RuleA blank renders as VERIFY, never as $0. Each guard is mutation-tested; 16 misstatement classes found on 1,252 responses are blocked.
Five rules in the engine, not instructions to staff
2. Keep the stored 271
Re-parsable
Every response is kept. The 7,186 benefit rows here were rebuilt from storage with zero new transactions.
3. Blank means VERIFY
Mutation-tested guards
A value the payer did not send shows as VERIFY, never as $0 or copied from another network tier.
4. Authorization by precedence
6 of 35 to 24 of 35
Payer policy layered on the 271 answered 24 of 35 at high or medium confidence; 11 routed to the named payer portal.
5. Route the exceptions
78 rows
To a person with the payer's actual response attached, not a retry loop.
35 therapy patients: resolved, not filed
Authorization answers for 35 therapy patients
The engine says whether authorization is required and where to get it; it does not file the request.
271 alonepayer transaction
6 of 3517%
Precedence resolverhigh or medium confidence
24 of 3569%
Routed to named payer portalremaining
11 of 3531%
010203035
271 aloneResolverPortal hand-off
Engine measurements on real payer traffic, not a cash outcome
- ONo downstream outcome yetDenials avoided or copays collected are not measured. The page claims coverage fidelity, nothing further.
- OPayers that answer thinOne payer returned 6 service types when asked for 22. Those rows need a phone or portal check, still manual.
- OAuthorization is resolved, not filed24 of 35 answers came from policy precedence, not from the payer transaction. Filing the authorization remains a human step.
- OVoice follow-upNo production voice result exists. Our voice verification pages are workflow explainers, not measured outcomes.
Takeaway
The payer answers the question you ask. Name the service types you bill, keep every 271, and never let a blank become a $0.
Frequently asked questions
What is a one-call VOB?
A single 270 eligibility request that names every service-type code the practice bills, 22 in this build, so the 271 comes back with therapy, behavioral health and dental benefits in one transaction. On this batch it removed the second billed call entirely, from 33 of 141 verifications to 0.
Why did the 271 show no therapy benefits?
Because the general request did not ask for them. Across 791 stored responses to a general request, physical therapy benefits were present only 11 percent of the time and the authorization indicator 0 percent, while dental was present 90 percent and mental health 84 percent. Service types must be named.
What was the parser fixing?
Defaults that filled blanks with values the payer never sent: 10,574 out-of-pocket maxima shown as $0, 9,139 deductibles, 2,729 copays and 4,122 rows mixing network tiers, across 12,484 rows. All are now 0, and a blank renders as VERIFY.
Does the engine submit prior authorizations?
No. It resolves the answer. For 35 therapy patients the 271 alone answered 6; a precedence resolver over payer policy answered 24 at high or medium confidence and routed 11 to the named payer portal. Filing is still done by a person.
- X12: Service Type Codes (the codes named in a 270 eligibility request)
- 45 CFR 162.1201: Eligibility for a health plan transaction (HIPAA standard transactions)
Checked October 25, 2026. Engagement figures are from ASP-RCM records for the periods stated; rules change, confirm against the source before relying on them.
EngineEligibility AI engine: continuous 270/271 checksSuiteThe ASP-RCM AI suiteServicePhysical therapy billing servicesCase studyWhen the 271 comes back thin: voice verification workflowCase studyPrior authorization status automation explainerCase studyPhysical therapy visit-to-claim reconciliationCase studyHealth center four-month AR turnaround
See what your 271s are leaving blank
Send us a sample of stored eligibility responses. We will show which service types your payers return, which benefits come back empty, and where a $0 on your screen is really a blank.