How to Verify Medicare Eligibility: HETS, MAC Portals, and What Changed With IVRs

Published October 14, 2026

For Original Medicare, the core electronic eligibility system is CMS's HIPAA Eligibility Transaction System, or HETS. HETS accepts HIPAA 270 eligibility requests over a secure connection and returns 271 responses with Medicare beneficiary eligibility information that providers use to prepare claims, estimate patient liability and check service-specific coverage.

Most providers never log into anything labeled "HETS." They reach the same data through a practice-management system, a clearinghouse, a billing vendor or their Medicare Administrative Contractor's (MAC's) provider portal. The important distinction for a Medicare eligibility check is between the underlying data and the interface used to retrieve it, and between Original Medicare and the private Medicare Advantage plans that the response may point to.

HETS is the main real-time Medicare eligibility transaction

CMS describes the HETS 270/271 application as real-time only; it does not accept batch transactions. "Real-time" refers to the response, not the data: CMS's companion guide notes that HETS data is updated once daily. That still makes HETS well suited to checking coverage close to the point of service or investigating a specific historical date.

HETS accepts requests for periods up to four years in the past and up to four months in the future, measured from the transaction date; requests outside that range return an error. A provider therefore does not need to rely on an old scanned Medicare card. The card identifies the patient, and the eligibility transaction establishes the coverage that applied on the date queried.

What a Medicare eligibility check should establish

A 271 response is a source of operational data, not a yes-or-no coverage flag. According to CMS's HETS companion guide, responses can include Part A and Part B entitlement, Part A deductible and Part B deductible and coinsurance information, Medicare Advantage plan enrollment, Medicare Secondary Payer enrollment, home health periods, hospice care periods and Qualified Medicare Beneficiary (QMB) enrollment periods. Not every field matters for every encounter. The objective is to retrieve the fields that change who should be billed, what the patient may owe, or what else needs verifying before the claim goes out.

Medicare Advantage and Medicare Secondary Payer results deserve particular attention because of how little HETS returns about them. For both, HETS provides enrollment and contact information, and CMS directs coverage questions to the plan itself. QMB periods matter for a different reason: they affect what a provider may bill the patient for Medicare cost sharing, which makes them a compliance question as much as a billing one.

MAC portals use HETS data

MAC provider portals offer eligibility lookups alongside claim status, remittance and other account tools, and for eligibility they generally draw on HETS. Noridian's Medicare Portal guide states that HETS is the authoritative source for the eligibility information it displays, and the myCGS user manual says the portal uses CMS's HETS 270/271 system, as CMS requires, for all eligibility inquiries. CMS's own fact sheet on checking Medicare eligibility makes the same point more broadly: MAC portals, billing agencies, clearinghouses and software vendors use HETS data.

The same fact sheet adds a caveat worth building into any workflow: you may see different Medicare eligibility responses depending on the tool you use. The data source is shared, but each tool decides which fields to request and how to display them. Choose the channel based on what the case needs. An automated check suits a vendor or clearinghouse connection, while a case that also needs claim-level follow-up may be easier to handle in the MAC portal, where eligibility and claim information sit in one place.

Most MAC phone lines no longer give eligibility

Phone verification used to be a third route, but for most providers it no longer is. In CMS Change Request 13754, issued in September 2024, CMS directed most MACs to disable beneficiary eligibility information in their interactive voice response (IVR) systems by March 31, 2025, as a pilot, and pointed providers to MAC portals, billing agencies, clearinghouses, software vendors or HETS instead. Palmetto GBA disabled IVR eligibility in January 2025, and Noridian announced that neither its IVR nor its representatives would disclose patient eligibility over the phone.

The change did not apply to every contractor; the change request's list of participating MACs is not universal. Teams that still rely on phone verification should confirm their own MAC's current policy rather than assume. For most organizations, the practical implication is clear: Medicare eligibility now has to come from an electronic channel, which makes clean HETS access and portal credentials an operational dependency rather than a convenience.

Use the MBI lookup when the patient can't provide their number

Every HETS request needs the beneficiary's Medicare Beneficiary Identifier (MBI). When a patient cannot provide it, MAC portals offer an MBI lookup tool. Noridian's lookup asks for the patient's first and last name, date of birth and Social Security number, and is intended for cases where providers are not able to obtain the MBI from the patient; myCGS requires the same four data elements. Once the MBI is in hand, record it with the eligibility result so downstream teams do not repeat the lookup.

A new enrollment requirement for vendor and clearinghouse requests

There is a recent change worth flagging for any organization that checks eligibility through a vendor or clearinghouse. As of May 11, 2026, HETS requires an active HETS EDI enrollment, which CMS also calls an attestation, for every National Provider Identifier (NPI) a vendor or clearinghouse submits. The provider sets up that enrollment through its MAC. Without it, HETS rejects the request, and CMS's MLN Connects newsletter identifies the resulting AAA error code 41 as meaning there is no current, valid relationship between the NPI and the third-party vendor.

The operational consequence is that a failed eligibility check may now be an enrollment problem, not evidence that the beneficiary cannot be found. Teams that see a sudden rise in HETS rejections should separate transaction-access errors from genuine coverage results before reworking accounts.

HETS keeps changing in smaller ways too. CMS's October 1, 2026 notice says the HETS2026-4 release is scheduled for December 2026 and may introduce changes to the 270 request and 271 response, so organizations with their own HETS connections should watch for the updated companion guide.

Medicare Advantage changes the next step

One of the most important results of any Medicare eligibility check is whether the beneficiary was enrolled in a Medicare Advantage plan on the relevant date. Original Medicare and Medicare Advantage are not interchangeable billing environments, even though both are Medicare coverage. If the response shows Medicare Advantage enrollment, the provider needs to identify the plan and then verify its benefits, network rules, prior authorization requirements and claims routing. HETS surfaces that the patient is in a plan; it does not replace plan-specific verification.

This is one reason an RCM team should never reduce its eligibility output to "Medicare active." The next payer may be CMS through Original Medicare or a private Medicare Advantage organization administering the member's coverage, and the rules differ substantially. (For one consequence of that difference, see what federal auditors found about Medicare Advantage denials.)

Check the date, not just the current status

A beneficiary's current coverage may not match the coverage in effect when the service occurred, which matters most when investigating an older denial or a coordination-of-benefits issue. Because HETS supports historical queries within its four-year window, a follow-up team should query the date on the claim rather than relying on today's status. Preserving the queried date range and the response timestamp makes it possible to show later exactly what the provider knew when it made the billing decision.

Eligibility does not establish that a service will be paid

A Medicare eligibility response establishes coverage facts, but it does not prove that every claim requirement has been met. Medical necessity, coding, provider enrollment, benefit limits, prior authorization where it applies, coordination of benefits and claim-specific rules can all still determine payment. "Eligible" in a work queue should mean that the relevant Medicare eligibility fields were verified, not that reimbursement is assured. For services with other Medicare requirements, the eligibility result is one input into a broader pre-service or billing workflow.

Build one eligibility record regardless of access channel

An organization might retrieve Medicare information through a clearinghouse one day and a MAC portal the next, and given CMS's caveat, the two responses may not look identical. The downstream record should still be consistent. Useful fields include the beneficiary identifier, the date of service queried, Part A and Part B status, Medicare Advantage plan information, secondary-payer enrollment, QMB periods, any service-specific coverage data the encounter needs, the verification source, the response timestamp and any unresolved next action.

That is the core of a repeatable benefits verification process, and it is where a multi-channel workflow beats a folder of portal screenshots. SuperDial is designed to retrieve payer information across electronic channels, portals and phone and to return structured outputs with source evidence, so the answer looks the same regardless of which interface supplied it. Our guide to why insurance eligibility checks still fail covers what a bare "active" response tends to leave out.

The right question is broader than "Is the patient active?"

For Original Medicare, HETS is the foundation of eligibility verification, and MAC portals present the same data alongside the claim tools providers already use. Phone lines, for most MACs, are no longer part of the picture. The outcome that matters is not a green eligibility indicator. It is a clear record of which Medicare coverage was in force on the relevant date and what that means for the next billing step.

When teams capture coverage type, date, plan information and the other relevant fields consistently, Medicare eligibility verification stops depending on individual staff knowing which screen to check.

FAQ

How do providers check Medicare eligibility?

Through HETS, CMS's real-time 270/271 eligibility system, usually by way of a clearinghouse, billing vendor, practice-management system or the MAC's provider portal. MAC portals display HETS data.

Can I still check Medicare eligibility by phone?

For most MACs, no. Under CMS Change Request 13754, most MACs removed beneficiary eligibility information from their IVR systems by March 31, 2025, and directed providers to portals, vendors, clearinghouses or HETS. Confirm your own MAC's current policy.

How far back can a HETS eligibility request go?

Up to four years in the past and up to four months in the future, measured from the date of the transaction.

What is AAA error code 41 in a HETS response?

Since May 11, 2026, it indicates that there is no current, valid HETS EDI enrollment linking the submitted NPI to the vendor or clearinghouse sending the request. The fix is an enrollment issue, set up by the provider through its MAC, not a beneficiary issue.

How do I find a patient's MBI?

Ask the patient first. If they cannot provide it, MAC portals such as Noridian's and myCGS offer an MBI lookup that requires the patient's name, date of birth and Social Security number.

Sources

All retrieved October 5, 2026.

Run a pilot on a real workflow.

Bring a representative batch, define the output schema, and validate ROI with your payer mix in 30 to 90 days.

Book a Demo
Superdial white logo
The communication layer for revenue cycle teams.
Workflows
Benefits Verification
Prior Authorization
Claim Status
Credentialing & Enrollment
Provider Data Management
Who We Serve
RCM Companies
Provider Groups
Health Systems
Payers
Digital Health
Pharma
Company
Case Studies
Newsroom
Security
Blog
API Docs
Book a Demo
Careers