Insurance eligibility integration
Live todayReal-time ABA insurance eligibility verification, inside the intake pipeline
270/271 transactions through a Stedi-compatible clearinghouse connection. Coverage, plan, and cost-share context arrive in the Insurance stage — before a family waits three weeks on documents.
Coverage active
- Payer
- Blue Cross NC
- Plan
- PPO — Employer
- Effective
- 01/01/2026
- Copay
- $30 / visit
- Deductible met
- $1,120 / $2,000
- ABA benefit
- Covered · prior auth
Authorization path
- Physician verified
- Auth submitted
- Pending
- Authorized
What is the TargetFlo eligibility integration?
The TargetFlo eligibility integration sends ANSI X12 270 inquiries and receives 271 responses through a Stedi-compatible clearinghouse connection, giving intake coordinators real-time ABA insurance eligibility verification without leaving the pipeline. Checks run in the Insurance stage of Intake & Referrals, results attach to the client's insurance record, and the same data later informs the authorization and claims path.
How it works
From referral card to 271 response in five steps
- 01
Referral reaches Insurance stage
The card moves from New Intake to Insurance. The coordinator confirms payer and member ID from the fax or intake form.
- 02
TargetFlo builds the 270
Subscriber, dependent, payer ID, and service type are assembled into an ANSI X12 270 inquiry from the client record — no re-keying.
- 03
Clearinghouse routes to payer
The inquiry travels through a Stedi-compatible connection to the payer's real-time endpoint. Typical round trip is seconds.
- 04
271 comes back
Coverage status, plan, effective dates, copay, deductible progress, and ABA benefit details are parsed and attached to the referral.
- 05
Coordinator decides
Active coverage advances the card to Pending Documents. Inactive or ambiguous results flag the card for follow-up before the family waits on paperwork.
When it runs
Live todayStage two of nine, on purpose
Insurance sits immediately after New Intake in the TargetFlo pipeline. Checking eligibility before documents, diagnostics, and the FBA means the center and the family learn about a coverage problem in minutes, not after a month of work.
- Automatic prompt when a card enters the Insurance stage
- Re-run on demand at any later stage — before authorization or at re-enrollment
- Result and timestamp shown on the card and the client's insurance tab
- Inactive coverage keeps the card in Insurance with a visible warning
- 1Intake
- 2Insurance
- 3Documents
- 4Diagnostics
- 5FBA
- 6POC
- 7Authorization
- 8Enrolled
- 9Closed
What comes back
What a 271 response gives your coordinator
Parsed into fields on the referral and the client record. The raw payer response is preserved for anything the parser does not model.
| Element | What TargetFlo shows |
|---|---|
| Coverage status | Active, inactive, or not found for the requested service date |
| Plan details | Plan name, product type (HMO/PPO/Medicaid managed care), group number |
| Effective dates | Coverage begin and, when present, termination date |
| Cost share | Copay, coinsurance, deductible and out-of-pocket accumulators |
| ABA / behavioral health benefit | Service-type-specific benefit lines and prior authorization indicators when the payer returns them |
| Payer messages | Free-text 271 messages preserved verbatim for the coordinator |
Capabilities
Built for intake teams, not billing offices
Runs in the Insurance stage
Eligibility is a pipeline step, not a separate portal. Results attach to the referral card and the client's insurance record.
ANSI X12 270/271
Standard eligibility inquiry and response transactions, so results are consistent across payers and clearinghouses.
Payer mapping
Map your plan list to clearinghouse payer IDs once per organization. Coordinators pick a plan name; TargetFlo sends the right ID.
Retry and re-check
Transient clearinghouse or payer errors retry automatically. Coordinators can re-run a check before authorization or at re-enrollment.
Clear error states
Member not found, payer unavailable, and invalid subscriber data are distinct outcomes with distinct next actions.
History on the record
Every check is stored with request time, payer, and result so you can see what coverage looked like on the day a decision was made.
PHI-isolated storage
Member IDs, dates of birth, and 271 payloads live in the PHI schema. Operational reports see counts, not identifiers.
Audited
Who ran the check, when, and what came back — recorded in the same audit trail that covers document access.
Error handling & retry
Every failure has a name and a next action
Real-time eligibility fails in predictable ways. TargetFlo treats each one as a distinct outcome instead of a generic error.
| Outcome | What TargetFlo does | Coordinator next action |
|---|---|---|
| Payer or clearinghouse timeout | Automatic retry with backoff; card flagged if retries are exhausted | Wait or re-run; no re-keying needed |
| Subscriber / member not found | Result stored as not found; card flagged for follow-up | Verify member ID and DOB with the guardian, re-run |
| Invalid or missing data (AAA segment) | Payer's rejection reason surfaced verbatim | Correct the flagged field on the client record, re-run |
| Payer not supported for real-time | Payer flagged in mapping; manual verification task created | Call payer or use portal; record result manually |
| Coverage inactive | Result stored; card stays in Insurance with a warning | Confirm alternate coverage or move to Pending Documents / Closed with reason |
PHI handling
Member IDs stay in the PHI schema
An eligibility check carries some of the most sensitive data in intake: subscriber ID, date of birth, and a payer response that may describe diagnosis-specific benefits. TargetFlo's four-schema architecture keeps that data isolated from operational tables.
- Request and response payloads stored in the isolated PHI schema, encrypted at rest and in transit
- Operational dashboards see counts — checks run, active vs. inactive — never identifiers
- Role-based access controls who can view member and benefit details
- Every check written to the audit trail with actor, timestamp, payer, and outcome
Reference data, payer list
Pipeline counts, check volume
Users, roles, sessions
Member ID, DOB, 271 payload
FAQ
Eligibility integration FAQs
Related features
Run an eligibility check on your top payer during the demo
Book a demo and bring two or three payer names. We map them, run a 270, and show the 271 landing on a referral card in the Insurance stage.