Retrieve Medicare Denials and Submit Appeals

Pull the real denial reason for a Medicare claim from the Medicare Administrative Contractor’s portal, then submit the redetermination packet through CMS esMD and capture the confirmation. Read-only retrieval first, appeal submission second, both on the federal path.

Go-live in as little as 30 min·Browser agent·Customer portal login

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Building internally? Read the docs →

How Asteroid runs this workflow

From a denied Medicare claim to a filed redetermination

A denied claim arrives from your billing system, Asteroid signs in to the MAC portal and captures the denial reason and remark codes, your team or your appeal tool builds the packet, and Asteroid submits it through esMD and returns the confirmation, and any denial the packet does not address stops for a person.

Medicare MAC provider portals
CMS esMD

How it actually runs

1. Sign in to the MAC provider portal for your jurisdiction under your credentials.
2. Look up the denied claim and capture adjudication status, denial reason, remark codes, and remittance detail. This step is read-only.
3. Check the redetermination packet your team or appeal tool produced against the captured denial.
4. Submit the packet through esMD or the MAC portal and capture the submission confirmation.
5. Return denial detail, confirmation, and the appeal deadline as structured JSON.

Retrieval runs on its own as a read-only proof of value. Submission is added once the retrieval output is feeding your appeal process. The two halves are separate agents on the same credential.

A denied Medicare fee-for-service claim: claim number, beneficiary, provider, and date of service

1. Sign in to the MAC portal
2. Retrieve the denial
3. Assemble the redetermination packet
4. Submit through esMD
5. Record the confirmation
6. Denial detail and appeal confirmation in your billing system

Each claim’s denial reason and remark codes, the redetermination submission confirmation, and the deadline write back to your billing system, traceable to the portal and the esMD receipt.

A denial the packet does not address: a denial reason with no matching documentation, a missed redetermination window, or a claim the portal cannot find stops the run with the portal’s wording attached. A person decides whether to appeal. The agent never files an appeal it cannot support.

The agent files the appeal your billers write

A redetermination succeeds on the clinical and coding argument, and that argument belongs to your billers or your appeal tool. What Asteroid removes is everything around it: finding the denial reason on a portal built for humans, assembling and uploading the documentation, capturing the receipt, and tracking the deadline. A packet that does not address the denial stops the run.

What runs today

The MAC retrieval and esMD submission agents are in the catalogue pipeline. The same read-then-appeal shape runs today on commercial payers in claim status, denial retrieval, and appeals and denial management. Medicare adds a federal submission path and a fixed redetermination window. If Medicare is your largest payer, scope the retrieval half first; the rest of the category is in the claims library.

Frequently asked questions

Which MACs and jurisdictions does this cover?

Each Medicare Administrative Contractor runs its own provider portal, so each is its own agent build on the same retrieval shape: sign in, look up the claim, capture status, denial reason, and remark codes. Your jurisdiction determines which MAC portal you need. Bring the credential for that portal and the build is scoped against it. Multi-jurisdiction billers run one agent per MAC under one output schema.

Does the agent submit through esMD directly, or through the MAC portal?

It depends on the path your organization uses. esMD is normally reached through a Health Information Handler gateway rather than a plain provider portal, and some MACs accept redetermination documentation on their own portals. The build is scoped to whichever path you have access to, and the output is the same: a submission confirmation tied to the claim. The retrieval half runs regardless of which submission path you choose.

What credentials are needed, and how is PHI handled?

Your MAC portal login and, for submission, your esMD or HIH access, held in agent profiles you control and can revoke. Claim and beneficiary data is PHI and stays between the portal, the esMD submission, and your billing system. Nothing is logged or stored elsewhere. Every run executes under a BAA on SOC 2 Type II infrastructure.

What stops the run and goes to a person?

A claim the portal cannot find, a denial reason the packet does not address, and a redetermination window that has passed. Each returns with the portal’s wording as a named exception, and a person decides whether and how to appeal. The agent never submits documentation that does not match the denial. Portal downtime and login failures are reported separately as technical failures.

Can we start with retrieval only?

Yes, and most do. Retrieval is read-only, needs only the MAC portal login, and returns the real denial reasons your billers read by hand today. Once that output is feeding your appeal process, submission is added as a second agent on the same credential. Both halves return structured JSON per claim, so your billing system sees one record per denial from retrieval through confirmation.