A 270 is an electronic eligibility and benefit inquiry. A 271 is the response returned for that inquiry.
The pair helps an authorized provider office request and receive available benefit information. A response is a point-in-time administrative record, not a guarantee of authorization, medical necessity, coverage, claim acceptance, or payment.
How do a 270 request and 271 response work together?
The provider's approved system sends an inquiry, and the payer or its transaction partner returns a structured response. The systems use the request information to identify the relevant member, provider, date, and benefit inquiry under their rules.
The response may provide an eligibility status, benefit information, patient responsibility information, or an error. The available fields and wording depend on the payer and connection. Staff should not assume that every response contains the same details.
CMS offers a current Medicare example. Its CMS HETS 270/271 guidance says authorized users can send compliant 270 requests over a secure connection and receive 271 responses in real time. That system's access, timing, fields, and operating rules should not be generalized to commercial payers.
What should staff verify before sending an inquiry?
Staff should match the request to the correct patient, payer, provider, and intended service context. They should use information from approved registration and payer records rather than memory or an earlier account.
The payer or transaction partner determines the required request data. If the system rejects an inquiry or returns no match, staff should read the message before changing anything. A small difference can matter, but guessing can create a new mismatch.
The office should also confirm that the person sending the request has an operational reason and authorized access. Patient information belongs only in the practice's approved systems and channels.
How should staff read a 271 response?
Staff should read the whole response, not only an active or inactive label. An active status may describe one part of the plan relationship while leaving service-specific benefits, network terms, limitations, or other questions unresolved.
The office should record what the response actually says and when it was received. It should distinguish returned facts from assumptions. If an important item is absent or unclear, staff can use the payer's approved follow-up path and retain the clarification.
A response should remain linked to the inquiry that produced it. This helps another reviewer see which payer, date, and service context the office asked about. It also prevents a later inquiry from silently replacing the earlier record.
What does a 271 response not prove?
A 271 does not prove that a specific service is authorized, medically necessary, covered, accepted on a claim, or payable. It reports the benefit information available through that transaction at that time.
Plan enrollment and benefit information can change. A service may also involve requirements that are not fully represented in the response. The provider still owns clinical decisions, and the payer still applies the member's plan and current policies during its processes.
Staff should avoid telling a patient that the response guarantees payment. A careful explanation identifies what was verified, what remains unknown, and which next administrative step applies.
When should the office correct or repeat an inquiry?
A correction is appropriate when verified request data was wrong or incomplete. Staff should return to the approved source, correct only the confirmed administrative information, and preserve the earlier response.
A later inquiry may be useful when information changes or the office needs a current response. Repetition should have a documented reason. Sending the same request repeatedly does not make an unclear benefit certain.
If the response points to another process, such as a separate authorization review, staff should follow the payer's current instructions. The eligibility transaction itself does not complete that process.
| Review point | Administrative question | Evidence to retain |
|---|---|---|
| Request match | Is this the correct patient, payer, provider, and context? | Approved source data |
| Response scope | What information did the payer actually return? | Complete response |
| Limit | What is still unknown or handled elsewhere? | Notes and payer clarification |
| Correction | Was any request data verified as wrong? | Earlier and corrected inquiry records |
| Communication | What can staff say without promising an outcome? | Dated verification summary |
What does a no-outcome dental-office example look like?
Imagine a dental office checks medical benefits before discussing a possible claim workflow. The response shows some plan information but does not answer a service-specific question.
Staff save the response and contact the payer through an approved channel. They record the clarification and explain to the patient that the office has benefit information, not a promise of coverage or payment.
The treating provider makes any clinical decisions. The example ends before service, claim, or payer outcome.
Frequently asked questions
Is an active 271 response the same as confirmed coverage?
No. Active information does not establish that a specific service meets every plan, policy, authorization, network, or claim requirement.
Can staff rely on an old 271 response?
They should follow the payer's and practice's current verification process. A prior response is a dated record and may not reflect later enrollment or benefit information.
This guide is general administrative information, not legal, medical, coding, privacy, security, or coverage advice, and not a promise of eligibility, authorization, coverage, claim acceptance, or payment. Eligibility information and transaction requirements vary by payer, plan, patient, provider, service, system, and date.
