An eligibility check is an X12 transaction pair that asks a payer, before a visit, whether a patient is actually covered and what they will owe. The 270 is the inquiry — does this patient have active coverage, and what does the cost-sharing look like — and the 271 is the payer's response, which can carry service-type granularity that sometimes includes telehealth-specific benefits. Like the claim transactions, these are HIPAA-standard formats, so the eligibility conversation runs on the same X12 plumbing as billing.
Run at scheduling time, an eligibility check prevents the worst billing surprise in healthcare: delivering a visit that no one will pay for, leaving either the patient with an unexpected bill or the provider unreimbursed. It also feeds accurate copay collection, so the patient is asked for the right amount up front rather than chased afterward. For a telemedicine product, where visits are quick to book and easy to over-schedule, this front-door check is disproportionately valuable.
The engineering reality is that 271 responses are notoriously uneven across payers. Some return rich, structured benefit detail; others return little more than a yes-or-no, and the telehealth specifics you most want may simply be absent. The practical guidance is to design for partial answers — never assume a clean, complete response — and to provide human-readable fallbacks so staff can verify coverage another way when the data is thin. The common mistake is building the scheduling flow to hard-block on a perfect eligibility response; in the real world that will strand patients whose payers simply return sparse data.
