Almost every DME platform claims both. The claims mean different things, and the difference is worth understanding before you sit through a demo.
Eligibility verification is largely solved — prior auth is not
Eligibility runs on a settled standard — the X12 270 inquiry and 271 response. Any platform connected to a clearinghouse can pull a real-time coverage check. The differentiation isn’t whether a system has eligibility. It’s where the check fires and what happens when it fails.
Ask: does eligibility run automatically at intake, or does someone click a button? Does a failed check block the order, or just log a note? Does it re-verify before delivery on orders that sat in a queue for three weeks, since plans change mid-month? A platform that runs eligibility once, on demand, at whatever point staff remember, has eligibility verification the way a filing cabinet has document management.
Prior auth is a different situation entirely, and it isn’t the software’s fault
Prior authorization for DMEPOS is HCPCS-driven and payer-specific. Medicare maintains a Required Prior Authorization List; commercial payers and Medicaid MCOs maintain their own, on their own schedules, and communicate through portals, faxes, and phone calls. No vendor can automate what the payer hasn’t exposed.
So “prior auth automation” in DME software today usually means one of four things, ranked by how much work it actually removes:
A tracking field
Someone types an auth number. The system stores it. This is a database, not automation.
Rules-based flagging
The system knows which HCPCS codes require auth for which payers and blocks delivery until one exists. Genuinely useful, and the most common real capability.
Portal integration or RPA
Software logs into payer portals on your behalf. Works until the portal changes.
Standards-based electronic submission
X12 278, or increasingly FHIR.
That fourth tier is about to become the baseline. Under CMS’s Interoperability and Prior Authorization final rule (CMS-0057-F), impacted payers (Medicare Advantage, Medicaid and CHIP, and QHPs on federally facilitated exchanges) must implement a FHIR-based Prior Authorization API, with compliance dates generally beginning January 1, 2027 (CMS fact sheet). Operational requirements already took effect in 2026: decision timeframes and specific denial reasons.
Note what that rule regulates. Payers, not you, and not your software vendor. But it determines what your vendor can build.
The question to ask instead
Don’t ask whether a platform has prior auth automation. Ask which of the four tiers it’s at, per payer type, today. Then ask what their CMS-0057-F roadmap is — whether they’re building against the Da Vinci implementation guides, and when.
A vendor who can’t distinguish tier two from tier four is at tier one.
