Prevent Eligibility Denials: 270/271 Checklist for U.S. Admissions

By /

A 270 is the electronic eligibility inquiry a provider sends to a payer; a 271 is the payer’s structured response. Use the 270 to verify coverage and financial responsibility before a patient walks through the door, but treat every 271 as a point-in-time snapshot, not a payment guarantee. Getting 270 271 eligibility right depends less on technology and more on what data you send and how fast you send it.

TL;DR:

  • Sending accurate full identifiers, including secondary identifiers like MBI and TIN, significantly improves match rates and reduces avoidable rejection errors during eligibility inquiries.
  • The 271 response provides essential benefit details, such as active coverage status, effective dates, and remaining benefits, which are critical for accurate admission planning.
  • Automated systems that capture and transmit data once at referral can greatly decrease manual errors, speed up eligibility verification, and streamline bed-filling processes.
  • Real-time eligibility checks are essential for urgent admissions and should be completed within seconds, while batch processing suits scheduled admissions with less time sensitivity.
  • Complying with HIPAA standards and understanding payer-specific guides ensure code accuracy, protect patient information, and avoid regulatory penalties.
Smartadmissions
Simplify Eligibility Verification
Smart Admissions automates referral management and insurance eligibility verification for faster, more consistent healthcare admissions.

Explore Smart Admissions

Table of Contents

What 270 and 271 Transactions Are (and When to Run Them)

The 270 and 271 are a matched pair of electronic data interchange transactions defined under ASC X12, and HIPAA requires covered entities to support them under the transaction standard rule at 45 CFR 162. The 270 is your question: is this patient covered, and for what? The 271 is the payer’s answer, delivered in a structured format your practice management system or clearinghouse can parse automatically instead of a staff member reading a fax.

Both transactions follow the 005010X279A1 implementation guide, commonly shortened to the 5010 version. If your team works with an EDI vendor or clearinghouse, that guide (and the TR3 documentation X12 publishes) defines exactly which segments and loops are valid. X12 publishes example files and implementation reference material for teams building or troubleshooting the raw transaction structure, which is worth bookmarking if your IT staff ever needs to inspect a raw 270 file line by line.

Understanding 270 271 eligibility also means understanding the two ways these transactions move. Real-time processing sends the 270 and gets a 271 back in seconds, typically while a patient is on the phone or in the admissions office. Batch processing sends a group of inquiries overnight and returns responses in a bulk file, which many hospitals still use for scheduled admissions the next day. Admissions coordinators handling same-day or urgent placements almost always need real-time; billing teams doing pre-registration for elective procedures a week out can often use batch without losing anything.

Here’s where a lot of new admissions staff get tripped up: a 271 is not proof that a claim will pay. CMS states plainly that HETS returns real-time Medicare eligibility data as a point-in-time snapshot, not a payment guarantee. Coverage can lapse, plans can change, and prior authorization requirements sit outside the 271 entirely. A second wrinkle: every payer writes its own companion guide on top of the base X12 standard, so the same 270 sent to two different insurers can return meaningfully different 271 content. That is why 271 eligibility guidelines from one payer rarely transfer cleanly to another without checking that payer’s own documentation first.

What to Put on the 270 to Maximize Your Match Rate

The 270 eligibility criteria a payer’s system checks against are stricter than most admissions staff assume, and a single typo in a middle name or a transposed birth date is enough to trigger a rejection instead of a real answer. The goal is redundancy: give the payer’s system more than one way to confirm this is the right patient.

At minimum, plan to include:

  • Full legal name, matching exactly what the payer has on file, not a nickname or a maiden name a family member gave you.
  • Date of birth, formatted correctly for the transaction (CCYYMMDD in most 5010 implementations).
  • Member or policy ID, including the Medicare Beneficiary Identifier (MBI) for Medicare patients rather than a legacy HICN.
  • Subscriber relationship code, so the system knows whether the patient is the policyholder or a dependent.
  • NPI of the requesting provider, placed in the appropriate loop so the payer can validate the request came from a recognized entity.
  • Service Type Code (STC) in the EQ01 segment, telling the payer what kind of benefit information you actually want back.

State Medicaid programs tend to be the strictest about this. Ohio Medicaid’s provider guidance notes that submitting at least two pieces of identifying information meaningfully improves match results compared to relying on member ID alone. That single habit, adding a second identifier as a rule rather than an exception, prevents a large share of avoidable rejections.

If you need a copay figure specific to a particular practitioner or location rather than a generic plan-level number, don’t stop at the subscriber loop. Payer companion guides recommend passing the practitioner’s NPI in the NM109 element and the Tax ID Number in the REF loop to get a location-specific or practitioner-specific benefit amount rather than the plan default. Many facilities skip this step and then wonder why the copay quoted at intake doesn’t match what the biller sees three weeks later.

On service type codes, resist the urge to always send STC 30 (“Health Benefit Plan Coverage”) because it feels safe. STC 30 returns a broad summary, but if you already know the patient needs skilled nursing, physical therapy, or a specific diagnostic service, request the matching STC directly, and include the relevant CPT or HCPCS code when the payer supports procedure-level queries. You’ll get a narrower, more useful answer instead of a generic coverage blob you have to interpret manually.

Pro Tip: Build a short reference card for your front desk listing the three or four STCs your facility uses most often (skilled nursing, physical therapy, durable medical equipment, behavioral health) so staff aren’t guessing which code to enter under time pressure.

Reading a 271 Response: What EB01 Codes Actually Tell You

The heart of any 271 is the EB segment, and the first data element, EB01, is the code that tells you what kind of benefit information follows. EB01 value “1” means active coverage. “6” means inactive. “A” through several other letters cover things like co-insurance, deductible remaining, and out-of-pocket maximums. If your staff only reads the plan name and skips past EB01, they’re missing the part of the transaction that actually answers “is this patient covered right now.”

Paired with EB01, the DTP segment carries dates, coverage effective dates, benefit period start and end, and sometimes plan year boundaries. A 271 showing active coverage with a DTP date range that ends next week is a very different situation than one showing coverage effective through year end, and that distinction should drive whether your team schedules a follow-up verification before the admission date.

CMS’s companion guide documents the full list of data elements a compliant 271 can return, and for admissions purposes, the fields that matter most day to day are:

  • Coverage status and effective dates — is the plan active, and through when.
  • Copayment, coinsurance, and deductible amounts — often broken out by service type rather than as one flat number.
  • Plan-level identifiers — group number, plan ID, and sometimes the specific product name.
  • Medicare Advantage or Part D notations — flagging whether a Medicare-eligible patient has actually enrolled in a private MA plan, which changes who you bill entirely.
  • Remaining benefit limits — visit caps or dollar caps still available for a given service type.

One structural detail trips people up: STCs in a 271 often come with “child” components nested underneath the primary EB segment, additional detail tied to a specific service type rather than the plan as a whole. If your system only surfaces the top-level EB01 value and drops the nested detail, you can miss the fact that physical therapy has a 20-visit annual cap even though general coverage shows active. When a field is simply absent from the 271 rather than showing zero or “not covered,” that usually means the payer didn’t have data for that specific STC, not that the benefit doesn’t exist. Silence in a 271 is not the same as a denial.

The CAQH CORE Eligibility & Benefits Infrastructure Rule sets a maximum real-time response window of 20 seconds for a compliant payer system, which matters operationally: if your clearinghouse is regularly taking longer than that to return a 271, the delay is likely happening on your side of the connection, not the payer’s.

Common AAA Error Codes and How to Fix Them Fast

When a 270 fails, the payer doesn’t just go silent, it sends back an AAA segment with a reject reason code, and most admissions staff have never been taught what these codes actually mean. Learning the top handful saves hours of vendor support calls.

  1. AAA 72 (Invalid/Missing Subscriber/Insured ID) usually means a typo in the member ID or a formatting mismatch, like including dashes the payer’s system doesn’t expect. Re-key the ID exactly as it appears on the insurance card.
  2. AAA 71 (Patient Birth Date Does Not Match) almost always traces back to a data entry error at registration. Cross-check the DOB against a photo ID, not just what the family verbally provides.
  3. AAA 62 (Date of Service Not Within Allowable Inquiry Period) means you’ve stepped outside the payer’s accepted window. HETS enforces a Medicare inquiry range of up to four years in the past and four months into the future relative to the request date; commercial payers often use tighter windows.
  4. AAA 42 (Unable to Respond at Current Time) is typically a payer system issue, not something on your end. Retry after a few minutes before escalating.
  5. AAA 15 (Required Application Data Missing) points to an incomplete transaction, often a missing NM1 loop or a required qualifier left blank.

Before calling a vendor about a mystery rejection, run through a short internal checklist: confirm the required NM1 segments are all present, validate that your ISA, GS, and ST envelope counts match what’s actually in the file, verify the date-of-service window falls within the payer’s allowable range, and if the standard member ID fails, retry using the MBI or policy number as an alternate identifier. This four-step sequence resolves a large share of AAA rejections without ever picking up the phone.

Pro Tip: Keep a running log of which AAA codes hit most often for each payer. If one plan consistently throws AAA 62, that’s a sign your team is querying too far outside its accepted date window, not a random glitch.

Connectivity, HETS Access, and CAQH CORE Response Rules

Before your facility can send a single 270, you need the right connectivity in place, and Medicare works differently than commercial payers. CMS’s HETS system operates in real time only; there’s no batch option for Medicare eligibility checks. To connect, your organization needs a submitter ID and a signed Trading Partner Agreement, typically arranged through a clearinghouse or EDI vendor rather than a direct connection for most skilled nursing and post-acute facilities.

For commercial payers, the operating rules layer comes from CAQH CORE rather than CMS. The CAQH CORE Eligibility & Benefits Infrastructure Rule standardizes:

  • Connectivity methods, so payers can’t require a proprietary connection method that locks out smaller providers.
  • Acknowledgement requirements, using 999 functional acknowledgements to confirm a file was received and structurally valid, and TA1 interchange acknowledgements for envelope-level problems.
  • Real-time response times, capped at 20 seconds maximum for a compliant payer system.
  • System availability expectations, requiring payers to publish and generally maintain scheduled uptime for their eligibility systems.

CAQH CORE’s own guidance frames these response-time and acknowledgement rules as predictability tools, and that predictability is exactly what admissions teams should be measuring internally. If your average 271 turnaround is creeping toward that 20 second ceiling, or your rejection rate on 999 or TA1 acknowledgements is climbing, that’s a signal worth tracking before it becomes a pattern of missed admission deadlines.

The last piece, and the one most teams skip, is actually reading each payer’s companion guide before assuming a standard 270 will work everywhere. A companion guide tells you which STCs a payer supports, how many service types they’ll return in a single response, and any quirks around date-range handling. One useful habit borrowed from EDI implementers: submit the same 270 to two or three of your top payers and compare the 271s side by side. The differences you find, usually around STC coverage and date formatting, tell you more about that payer’s real behavior than any PDF will.

Admissions Checklist: Turning the Rules Into Daily Practice

Everything above becomes useful only when it’s built into a repeatable intake workflow. Here’s a sequence that works for scheduled admissions:

  1. Capture full identifiers at first contact. Legal name, DOB, member ID, and a secondary identifier like SSN or MBI, entered exactly as they appear on the insurance card, not transcribed from memory.
  2. Run the 270 within 48 to 72 hours of a scheduled admission, close enough to catch a coverage change but early enough to fix a problem before the patient arrives. Same-day or urgent admissions should always use real-time verification instead of waiting for a batch cycle.
  3. Select the STC that matches the actual service, skilled nursing, physical therapy, behavioral health, whatever applies, and include CPT or HCPCS values when the payer’s companion guide supports procedure-level detail.
  4. Read the full 271, not just the headline EB01 value. Check nested STC detail, remaining benefit limits, and DTP date ranges before telling a family what their financial responsibility will be.
  5. Document every 271 response, including the date and time it was received, in the patient’s record. If a claim later denies for eligibility reasons despite a clean 271, that documentation is your strongest appeal evidence.
  6. Escalate to the payer directly when a 271 is ambiguous or incomplete, rather than guessing at coverage. A quick provider services call to confirm plan-level detail beats a denied claim weeks later.
  7. Re-verify before the actual admission date if more than a few days passed between your initial check and intake, since coverage can lapse or change mid-cycle.

This sequence lines up closely with the 48 to 72 hour rule many admissions teams already follow for real-time eligibility checks, and it pairs well with a broader step-by-step eligibility verification checklist if you’re building or revising your intake process from scratch.

Pro Tip: Assign one team member per shift as the “eligibility escalation” contact. When a 271 comes back ambiguous, staff should have one clear person to hand it to instead of letting it sit in a queue until someone has time.

How Automation Reduces 270/271 Friction in Daily Admissions

Most of the errors covered above, mistyped IDs, wrong STCs, missed date windows, come from manual data entry under time pressure, not from the underlying X12 standard being complicated. Automation doesn’t change what a 270 or 271 contains; it changes how reliably the right data gets into the request in the first place.

A well-integrated workflow looks like this: patient demographic and insurance data gets captured once at the point of referral or intake, an automated system assembles the 270 using that captured data (pulling the correct NPI, TIN, and STC based on the service being requested), the transaction routes through a clearinghouse or directly to HETS for Medicare, and the returned 271 gets parsed and mapped back into the fields your admissions and billing staff actually look at, rather than landing as a raw EDI file nobody wants to read.

The verifiable benefit here isn’t magic, it’s fewer opportunities for the transcription errors that cause AAA rejections, and faster turnaround because the system isn’t waiting on someone to manually re-key a birth date between systems. For a facility juggling dozens of referrals a week, cutting even a handful of rejected inquiries per day means faster answers for families and faster bed-fill decisions for administrators. That’s the practical case for automation in eligibility verification, not fewer humans involved, but fewer avoidable errors slowing the ones who are.

Regulatory Compliance Issues and Penalties Tied to 270/271 Transactions

HIPAA’s transaction standard rule, codified at 45 CFR 162, requires covered entities and their clearinghouses to support the 270/271 transaction set in its standard format, and noncompliance carries real exposure. Refusing to accept a properly formatted 270, or returning a 271 that doesn’t conform to the required data elements, can trigger HIPAA enforcement action from the Department of Health and Human Services, separate from any claim-level billing dispute.

The more common compliance issue in practice isn’t outright refusal, it’s misrepresentation. Treating a 271’s coverage confirmation as a binding payment guarantee, then billing a patient based on that assumption when the claim later denies, creates both a compliance headache and a patient trust problem. Every companion guide and CMS resource is explicit that a 271 response is informational, not a payment commitment, and facilities that build financial counseling scripts assuming otherwise are setting themselves up for disputes.

Data handling matters too. Because 270 and 271 transactions carry protected health information, the same HIPAA privacy and security safeguards that apply to any PHI transmission apply here, encryption in transit, access controls, and audit logging on who queried which patient’s eligibility and when. Facilities using a clearinghouse or EDI vendor should confirm that vendor’s own HIPAA compliance posture as part of any business associate agreement, not assume it by default.

Eligibility Handling Differences Across Provider Settings

Hospitals, outpatient clinics, and physician offices don’t use 270/271 the same way, and treating them identically causes friction. Hospitals typically run eligibility checks in batches ahead of scheduled admissions and again in real time for emergency department intake, often requesting broader STCs since inpatient stays can touch multiple benefit categories, room and board, ancillary services, skilled nursing follow-up, in a single visit.

Outpatient facilities and post-acute settings, the primary audience for admissions automation, tend to run tighter, more frequent real-time checks because scheduling windows are shorter and coverage for services like physical therapy or skilled nursing often carries visit caps that need to be tracked over the length of stay, not just confirmed once at intake.

Physician offices generally query the narrowest STC set, often just the specific service being rendered that day, and lean more heavily on real-time responses since same-day scheduling is the norm. The core transaction logic doesn’t change across settings, but the STCs requested, the frequency of verification, and how tightly the 271 data needs to map into billing all shift based on the type of care being delivered and how long the patient relationship runs.

Where Admissions Teams Actually Get 270/271 Right

Most facilities treat eligibility verification as a compliance checkbox instead of what it actually is: the single highest-leverage step in the entire admissions process. Teams that get this right almost always start in the same place, not with new software, but with a hard look at data quality. If your front desk is entering names inconsistently or skipping the secondary identifier, no amount of automation will fix the AAA rejections that follow.

The fastest quick win I’ve seen argued for consistently across companion guide documentation is running a single test: pick your two or three highest-volume payers, submit an identical 270 to each, and compare what comes back. You’ll find real differences in STC support, date handling, and how much detail actually lands in the 271, and that fifteen minute exercise teaches your team more about payer behavior than any training document. Fix the data quality problem first, understand your top payers’ quirks second, and only then start layering in tools to speed up the parts that are already working correctly.

— Harry

Smart Admissions: Automating the 270/271 Workflow Without the Manual Rekeying

There are platforms available that serve as alternatives to manual eligibility checks for skilled nursing, rehabilitation, and post-acute facilities: instead of staff re-typing patient identifiers across an EMR, a clearinghouse portal, and a payer website, these platforms capture data once at referral and carry it through the entire 270/271 cycle automatically.

Smartadmissions

Some platforms integrate with existing EMR systems to pull identifiers that drive match rates, such as legal name, DOB, member ID, and NPI, helping the 270 go out clean the first time instead of bouncing back with an AAA rejection. Once the 271 returns, these platforms parse the coverage status, benefit fields, and plan-level detail directly into admissions dashboards, allowing teams to read clear answers instead of raw EDI files. This mapping can result in real time savings, less manual entry, fewer rejected inquiries, and faster answers for families waiting on bed decisions.

If your team is still verifying eligibility by hand or juggling separate payer portals, see how automated admissions compare to manual verification and get in touch for a walkthrough of how the eligibility workflow fits your intake process.

Sources

Scroll to Top