AI Insurance Eligibility Verification: 270/271 Without PHI Over-Exposure

An eligibility check is one of HIPAA's named standard transactions. The AI agent driving it cannot ask the patient for more PHI than the 270 needs — and cannot store more of the 271 than the workflow requires.

What this workflow does

flowchart LR
  Patient["Patient call/chat"] -- "TLS 1.3" --> Edge["Cloudflare WAF"]
  Edge --> App["CallSphere App<br/>HIPAA + SOC 2 aligned"]
  App -- "encrypted" --> AI["AI Voice Agent"]
  AI -- "tool_call · audit" --> Audit[("Audit log<br/>§164.312")]
  AI --> EHR[("EHR · BAA-signed")]
  EHR --> AI
  AI --> Patient

A patient calls or texts ahead of an appointment. The AI agent collects member ID (or first name, last name, date of birth as a fallback), runs an X12 270 Eligibility, Coverage, or Benefit Inquiry through a clearinghouse to the payer, receives the 271 response, parses out coverage status, copay, deductible remaining, and prior-authorization-required flags, and confirms the appointment with accurate financial expectations. For self-pay or uninsured patients, the agent drops to the practice's cash-pay path.

Done well, this workflow eliminates 80%+ of front-desk eligibility work and prevents the most common revenue leak: the surprise denial after the visit. Done badly, it asks the patient for the wrong identifiers, stores the entire 271 indefinitely, and drips PHI into the LLM's context window.

HIPAA constraints

The X12 270/271 transactions are mandated by 45 CFR 162 Subpart K, with operating rules from CAQH CORE. The 270 should carry the minimum elements that produce a high-confidence match — member ID is best, but name plus date of birth plus payer ID is acceptable. The 271 response can carry far more than the workflow needs (full plan structure, family deductibles, ten years of coverage history). Minimum necessary at 45 CFR 164.502(b) requires the agent to surface only the fields the patient and the front desk need for this visit. The audit trail at 45 CFR 164.312(b) records every 270 sent and the disposition of the 271 received.

Trading-partner authentication under 45 CFR 164.312(d) requires mutual TLS or digital certificates for the connection to the clearinghouse or payer. Encryption in transit under 45 CFR 164.312(e) covers every hop.

How CallSphere implements it

CallSphere runs eligibility as the verify_insurance tool inside the Healthcare Voice Agent — one of 14 tools in the healthcare stack. The agent asks the patient first for the member ID and falls back to name plus DOB if needed. The 270 is built and sent through a HIPAA-aligned clearinghouse over mutual TLS. The 271 response is parsed by a deterministic parser, not the LLM — only the four fields that drive the workflow (active y/n, copay, deductible remaining, PA required y/n) are ever shown to the model. The full 271 is stored encrypted at rest in the healthcare_voice PostgreSQL database (1 of 115+ tables) for 30 days for retroactive billing audits, then rotated. Every check is captured in post-call analytics with sentiment (–1.0 to +1.0), lead score (0–100), AI summary, and audit trail. Platform is HIPAA and SOC 2 aligned, 37 agents and 90+ tools across 6 verticals. The eligibility tool is included on the $499/month Pro plan and $1,499/month Scale. Practices can verify it on the 14-day trial and review /industries/healthcare. Pricing detail at /pricing.

Implementation checklist

1. Connect to a single HIPAA-aligned clearinghouse with mutual TLS — Availity, Change Healthcare, Waystar, or similar.
2. Build the 270 with member ID first, then fallback identifiers — never ship more than the payer's matcher needs.
3. Parse the 271 deterministically; expose only active status, copay, deductible remaining, PA flag to the LLM.
4. Set a 30-day retention on the raw 271 for billing audits, then rotate.
5. Encrypt every 270/271 in transit (TLS 1.2+) and at rest (AES-256).
6. Audit-log every transaction with timestamp, payer, response code, and disposition.
7. Implement payer-specific quirks (BCBS plan ID prefixes, Medicare Advantage carve-outs, Medicaid MCO routing).
8. Surface real-time financial expectations to the patient: "Your copay today will be $40 and you have $300 remaining on your deductible."
9. Trigger the prior-authorization workflow automatically when the 271 returns a PA flag.
10. Sign BAAs with the clearinghouse and any sub-processor.
11. Train the agent to decline requests for eligibility on third parties — no spouse-checking-on-spouse without consent.
12. Run weekly QA on a sample of eligibility calls.

FAQ

Do we need patient authorization to run an eligibility check? No. Eligibility is payment under 45 CFR 164.501, covered by the treatment-payment-operations exception at 45 CFR 164.506(c). The Notice of Privacy Practices acknowledgment is sufficient.

Can the agent run eligibility for a patient calling on a friend's behalf? Only if the friend is the policyholder asking about their own coverage. Otherwise the agent declines and routes to the front desk for verification.

What if the 271 reveals coverage the patient did not know about? The agent surfaces only what is operationally relevant. It does not narrate the full coverage history. The front desk handles unusual coverage situations.

Does this workflow work for Medicaid? Yes. CMS HETS handles Medicare; state Medicaid agencies use 270/271 with state-specific operating rules. CallSphere supports both.

Sources

• 45 CFR 162 Subpart K Standards for Health Care Eligibility: https://www.ecfr.gov/current/title-45/part-162/subpart-K
• 45 CFR 164.502 Minimum necessary: https://www.ecfr.gov/current/title-45/section-164.502
• 45 CFR 164.312 Technical safeguards: https://www.ecfr.gov/current/title-45/section-164.312
• CMS HIPAA Eligibility Transaction System: https://www.cms.gov/data-research/cms-information-technology/hipaa-eligibility-transaction-system
• CAQH CORE Eligibility and Benefits Operating Rules: https://www.caqh.org/core/eligibility-benefits