Medicare Compliance: Why the Right Modifier Starts Before the Claim

Medicare compliance doesn’t begin when a claim reaches the billing queue. From identifying potential coverage issues and managing ABNs to selecting the right modifiers and preserving supporting documentation, every step in the workflow can influence what happens next. This article explores how GA, GX, GY, and GZ fit into the larger Medicare compliance picture—and why stronger processes upstream can help practices prevent avoidable billing and compliance issues downstream.

Medicare compliance is often treated as a coding exercise. But some of the most consequential compliance decisions happen before a claim ever reaches the billing queue.

When a service may not be covered, the practice must determine why Medicare may deny it, whether an Advance Beneficiary Notice of Noncoverage (ABN) is required, whether the beneficiary was properly notified, and how that situation should ultimately be represented on the claim.

That makes Medicare compliance a cross-functional process—not simply a matter of selecting the right modifier. The GA, GX, GY, and GZ modifiers are useful examples of how coverage rules, patient communication, documentation, and revenue cycle operations intersect.

The Real Compliance Risk Is Often Upstream

A Medicare claim can be coded correctly and still create a compliance problem if the steps leading up to the claim were handled incorrectly.

Consider a service that is generally covered by Medicare but may be denied because the patient's particular circumstances do not satisfy applicable medical-necessity requirements. The billing team cannot simply decide after the fact that the patient should be responsible for the charge.

The practice may first need to determine whether an ABN should have been issued, whether it was completed correctly, whether it was provided before the service, and whether the patient's response was appropriately documented.

CMS describes the ABN as a notice used when Original Medicare is expected to deny a service that it normally covers in particular circumstances. When the applicable requirements are met, the notice can shift potential financial liability to the beneficiary.

The important distinction is this:

Medicare compliance does not begin when the claim is submitted. It begins when the practice recognizes that coverage may be an issue.

That is why compliance should be built into the workflow rather than treated as a final billing checkpoint.

Four Modifiers, Four Different Compliance Signals

GA, GX, GY, and GZ are not interchangeable indicators of "Medicare won't pay."

Each communicates something different about the anticipated denial and the beneficiary notification process.

Modifier	What it communicates	ABN situation	General billing significance
GA	Medicare is expected to deny a service as not reasonable and necessary, and the required ABN is on file	Mandatory ABN issued	Indicates the line is associated with a valid ABN
GX	A voluntary notice of liability was issued for a service expected to be denied for reasons other than medical necessity	Voluntary ABN	May be used with GY or separately, depending on the circumstances
GY	The item or service is statutorily excluded or does not meet the definition of a Medicare benefit	ABN generally not required	Identifies a service Medicare does not cover under the benefit rules
GZ	Medicare is expected to deny the service as not reasonable and necessary, but no ABN was obtained	No ABN	Claim line is subject to automatic denial

 

CMS specifically describes GA as the modifier used when a mandatory ABN has been issued and retained for a service expected to be denied as not reasonable and necessary. GY applies to services excluded by statute or outside the definition of a Medicare benefit, while GZ identifies services expected to be denied as not reasonable and necessary when no ABN was signed.

GX is somewhat different: CMS describes it as a voluntary notice of liability for services expected to be denied for reasons other than medical necessity, such as statutory exclusions or other non-covered situations. CMS also notes that GX may be used with GY.

The key question isn't "Which modifier do we use?"

It is:

"What is the coverage issue, and what happened before the claim was created?"

That question leads the billing team toward the correct modifier rather than encouraging modifier selection in isolation.

GA: When an ABN Supports the Billing Decision

Modifier GA is generally associated with a service that Medicare would ordinarily cover but that the provider expects Medicare to deny because the service is not reasonable and necessary in the particular situation.

A required ABN has been issued and is on file.

For example, a provider may determine that a service could fall outside Medicare's medical-necessity requirements based on the patient's circumstances or applicable coverage policy. If the practice appropriately provides the ABN and the beneficiary accepts the applicable option, the claim can reflect that notification through the GA modifier when appropriate.

The important compliance point is that the modifier does not replace the ABN.

GA is a claim-level representation of a preceding administrative and beneficiary-notification process.

CMS states that providers should retain the ABN and make it available upon request rather than routinely submitting it with the claim.

Where practices can run into trouble:

The risk increases when the front office, clinical team, and billing department operate independently.

A billing team may see a GA modifier as evidence that an ABN exists. But the underlying document still needs to satisfy the applicable requirements.

That means practices should have a reliable way to connect:

Expected denial → ABN → beneficiary decision → documentation → claim modifier

If one link is missing, the claim may no longer tell the complete compliance story.

GX and GY: When the Issue Is Coverage, Not Medical Necessity

GX and GY require a different way of thinking.

Not every Medicare non-covered service is a medical-necessity denial.

Some services are excluded by statute or do not fall within the definition of a Medicare benefit. In those situations, GY is used to identify the service as statutorily excluded or outside the Medicare benefit category. CMS states that an ABN is not required for these denials, although other circumstances or requirements may call for beneficiary notification.

GX can enter the picture when a voluntary ABN has been provided for a service expected to be denied for a reason other than medical necessity. CMS specifically describes GX as a voluntary notice of liability modifier and notes that it may be used with GY.

This distinction matters because a practice should not automatically interpret every non-covered service as a medical-necessity issue.

The first step is identifying the actual coverage basis.

GZ: The Modifier That Should Trigger a Process Review

GZ is perhaps the most useful modifier from a revenue-cycle management perspective because it can reveal a process failure upstream.

CMS defines GZ as the modifier used when a provider expects Medicare to deny an item or service as not reasonable and necessary and an ABN was not signed.

More importantly, CMS policy provides for automatic denial of claim lines submitted with GZ, without complex medical review. That policy has been in effect for dates of service beginning July 1, 2011.

In practical terms, a GZ claim should not simply be viewed as another denial.

It can be viewed as a workflow signal.

If a practice repeatedly generates GZ claims, the more useful question may be:

Why are services reaching the billing stage when the practice already expects Medicare to deny them and the required ABN process has not occurred?

The answer could involve:

• Coverage rules not being reviewed during scheduling
• Medical-necessity requirements not being identified early enough
• Front-office staff not recognizing an ABN situation
• Clinical and administrative teams using different workflows
• ABNs being presented too late
• Documentation not being transferred reliably into the billing workflow
• Coding staff discovering the issue only after the service has been performed

That makes GZ frequency a potentially useful internal compliance indicator—not merely a claim-denial statistic.

The ABN Is Part of the Revenue Cycle

One of the most common conceptual mistakes is treating the ABN as a piece of paperwork that belongs exclusively to the front desk.

It is better understood as part of the revenue cycle.

The process can be viewed in five stages:

1. Identify the Coverage Risk

Before the service is delivered, determine whether Medicare coverage could be affected by medical necessity, frequency limitations, statutory exclusions, or applicable coverage requirements.

Coverage policies—including applicable National Coverage Determinations (NCDs), Local Coverage Determinations (LCDs), and other Medicare guidance—should inform the assessment.

2. Determine Whether an ABN Is Appropriate

The practice must distinguish between services that Medicare generally covers but may deny in a particular circumstance and services that Medicare excludes altogether.

That distinction is fundamental to choosing the appropriate notification and billing approach.

3. Communicate Before the Service

When an ABN is required, timing matters.

CMS's ABN guidance describes the notice as an advance notice and explains that it should be provided when the provider expects Medicare to deny a service it normally covers.

A retrospective notice after the service has already been performed does not accomplish the same purpose.

4. Preserve the Documentation

The practice should be able to demonstrate what the patient was told, why the notice was issued, what service it covered, and how the beneficiary responded.

This is where integration between the EHR, practice-management system, document management process, and billing workflow becomes important.

5. Translate the Decision into the Claim

Only after the underlying coverage and notification circumstances are established should the appropriate modifier be applied.

The claim is the final representation of the process—not the place where the process begins.

What Medicare Compliance Looks Like in a Well-Controlled RCM Workflow

A strong Medicare compliance process should make it difficult for an incorrect modifier to reach claim submission.

One way to accomplish this is to establish a compliance checkpoint between clinical documentation and billing.

For example:

Coverage review

↓

Potential denial identified

↓

Determine whether ABN is required

↓

ABN issued and documented, when applicable

↓

Patient decision recorded

↓

Service performed

↓

Documentation reviewed

↓

Modifier validated

↓

Claim submitted

This approach shifts the focus from correcting claims after they fail to preventing predictable problems before submission.

Technology Can Strengthen the Process—But Should Not Replace Judgment

Automated coding and claim-editing tools can help identify questionable modifier combinations, missing information, or claims that require additional review.

But automation is most useful when it reinforces a clearly defined compliance workflow.

A system can flag a GZ claim.

It cannot, by itself, determine whether the practice should have identified the coverage issue three days earlier during scheduling, whether the ABN was appropriately issued, or whether the documentation accurately reflects the patient's circumstances.

That still requires a coordinated process and knowledgeable staff.

A Practical Medicare Compliance Audit Checklist

Instead of auditing Medicare claims only after a denial or payer request, practices can periodically review their own modifier activity.

Consider asking:

Coverage

• Are services being screened against applicable Medicare coverage requirements?
• Are staff able to distinguish medical-necessity concerns from statutory exclusions?
• Are relevant LCDs and NCDs incorporated into operational workflows where applicable?

ABN Management

• Is the correct ABN being used?
• Is the notice being provided before the service when required?
• Is the form complete and understandable?
• Is the beneficiary's response documented?
• Can the practice retrieve the ABN when requested?

CMS identifies Form CMS-R-131 as the ABN for Original Medicare fee-for-service beneficiaries and provides instructions for its use.

Coding

• Does the modifier accurately represent the reason for anticipated noncoverage?
• Are GA, GX, GY, and GZ being distinguished correctly?
• Are incompatible or unnecessary modifier combinations being prevented?
• Are coding edits catching problems before claim submission?

Documentation

• Does the medical record support the service billed?
• Is the reason for anticipated noncoverage documented where appropriate?
• Can the practice connect the clinical record, ABN, and claim?

Revenue Cycle

• How frequently are GZ modifiers being submitted?
• Are certain CPT/HCPCS codes generating repeated noncoverage issues?
• Are certain locations, providers, specialties, or workflows generating disproportionately more modifier-related denials?
• Are recurring denials being fed back into front-office and clinical workflows?

The last group of questions is particularly important.

A denial report tells you what happened to the claim. A compliance review should also tell you why the claim got there in the first place.

Bristol's Perspective: Medicare Compliance Should Be Designed Into the Revenue Cycle

At Bristol Healthcare, we see Medicare compliance as more than a coding checkpoint.

The strongest compliance processes connect coverage knowledge, documentation, coding, billing, and denial management rather than allowing each function to operate as a separate silo.

That perspective changes how modifier issues are handled.

Instead of simply correcting a GA, GY, or GZ claim after submission, the goal is to understand the workflow that produced it.

• If GZ claims are recurring, for example, the solution may not be another claim edit. It may involve improving how potential medical-necessity issues are identified during intake.
• If GA claims are frequently missing supporting ABNs, the underlying issue may be document retention or communication between front-office and billing teams.
• If GY claims are being misclassified, the opportunity may be to strengthen coding guidance around statutory exclusions and Medicare benefit categories.

This is where a coordinated Revenue Cycle Management approach can make a difference.

At Bristol, our billing and coding teams can use claim-level review, coding validation, documentation checks, and denial analysis to identify patterns that may otherwise remain hidden in individual claims. Technology and AI-assisted coding tools can further support these workflows by flagging potential issues for human review before claims move downstream.

The objective isn't simply to produce a cleaner claim.

It is to build a cleaner process behind the claim.

The Bottom Line

Medicare compliance is rarely determined by a single modifier.

GA, GX, GY, and GZ are the visible output of a much larger process involving coverage rules, beneficiary notification, documentation, coding, and billing.

When that process is designed correctly, the billing team is not forced to solve compliance problems after the service has already been delivered. Instead, potential coverage issues can be identified earlier, communicated appropriately, documented accurately, and reflected correctly on the claim.

For healthcare organizations, that is the bigger opportunity: move Medicare compliance upstream—from claim correction to process control.