Question 1

We already receive claim status through EDI. What work is still left in payer portals?

Accepted Answer

The 835/837 rails carry standardized status for the largest payers. What they don't carry: denial detail beyond a code, appeal submission, requests for records, and the regional and Medicaid managed-care payers no clearinghouse connects. That remainder is manual portal work today, and it's where AR days accumulate. Agents log into those portals, retrieve status and denial detail, assemble and file appeal packages, and write structured results back to your PM system.

Question 2

Which parts of denial follow-up are automated, and which decisions stay with our team?

Accepted Answer

Retrieval, assembly, and filing automate: pulling the denial reason and remark codes, gathering the claim's documentation, preparing the appeal package, submitting it, and tracking the response. Whether to appeal (the judgment on coding, medical necessity, or writing it off) stays with your team, presented with the evidence already assembled. That boundary is deliberate: a false read on a denial becomes a compliance problem weeks later, so the agent's job is to make your decision fast, not to make it.

Question 3

What happens when a claim cannot be matched or a denial reason is ambiguous?

Accepted Answer

It stops rather than force-matching. A claim that can't be confidently matched to the portal's record, or a denial whose reason is ambiguous, routes to a person with the portal evidence attached, never a guessed match written back to the PM system. A clean denial is a successful run with a business finding; a portal failure is a separate technical error. The two never mix in your queue.

Question 4

How do portal changes and appeal deadlines affect the automation?

Accepted Answer

Portal changes are absorbed by reading the live page rather than replaying a script; a restructured claim-search flow degrades to an escalation, not a silent miss. Deadlines are tracked per denial from the payer's own stated windows, and follow-ups are scheduled inside them. Anything approaching a deadline without resolution surfaces to your team with time still on the clock, because a perfectly executed appeal filed late is worth nothing.

Question 5

How are PHI, credentials, appeal documents, and execution history handled?

Accepted Answer

Claims and remittance data move through HIPAA-compliant, SOC 2 Type II infrastructure under a BAA. Portal logins are your credentials, least-privilege scoped, rotatable, revocable. Every status check and appeal submission is recorded with timestamps and the documents filed, so the question 'did we appeal this, when, and with what' is execution history, not archaeology. The complete posture is on the security page.

Question 6

What if a payer or clearinghouse portal we need is not in the library?

Accepted Answer

Add it the way the existing ones were added: scope the portal with a worked claim example in the builder, or have Asteroid build and run it managed. Regional and Medicaid managed-care portals (the ones EDI never covered) are the most common additions, and they follow the same retrieve-classify-write-back pattern as the portals already in the catalogue, inheriting the same evidence and escalation design.

Chase down every claim and denial.

Every claim checked. Denials acted on.

Frequently asked questions