Typical implementation for a small-to-medium DME provider runs 90–120 days from kickoff to go-live. Enterprise and multi-location operations run longer — the variable isn’t the software, it’s the state of your data and how many payer configurations you’re carrying.
Here’s what the phases actually contain.
Discovery and configuration (weeks 1–4)
Someone maps your current workflows: how orders enter, who touches them, where documentation lives, which payers you bill and under what rules. This is where multi-location operations diverge. Each location has its own NPI and billing number, and configuration has to reflect that. Payer fee schedules, contract rates, and item masters get loaded. If your HCPCS catalog has drifted over five years of manual edits, this is where you find out.
Data migration (weeks 3–8, overlapping)
The hardest part, and the most underestimated. What moves: patients, active rentals with their current month position, open orders, inventory and serialized assets, AR balances, and historical documentation. What doesn’t move cleanly: anything stored outside the legacy system. Scanned PDFs in a shared drive, proof of delivery in a filing cabinet, payer rules in someone’s head.
The historical documentation matters more than most teams expect. Under Medicare’s DMEPOS supplier standards, you’re responsible for maintaining proof of delivery and beneficiary instruction records (42 CFR § 424.57(c)). Those obligations follow you across a system change. A migration that brings patients but abandons documentation leaves you exposed on any audit touching a pre-migration claim.
Payer and clearinghouse setup (weeks 4–10)
EDI enrollment with your DME MAC, ERA and EFT setup, clearinghouse connections, eligibility verification feeds. This is largely out of your vendor’s control and out of yours. Payer enrollment timelines are what they are. Start early.
Testing and parallel run (weeks 8–12)
Submit test claims. Verify remittances post correctly. Confirm capped rental schedules picked up at the right month — this is the single most common migration failure, and it’s expensive in both directions. Bill month 14 of a 13-month cap and you’re returning an overpayment.
Go-live and stabilization (weeks 12–16)
Cutover, then two to four weeks where AR days temporarily rise because staff are learning the system while claims still need to go out.
What extends the timeline
Factor | Impact |
Clean, structured legacy data | Baseline |
Data in spreadsheets or paper | +3–6 weeks |
Multiple locations, separate NPIs | +2–4 weeks |
Heavy custom payer rules | +2–4 weeks |
Slow payer/clearinghouse enrollment | +2–8 weeks, largely outside your control |
No internal project owner | Indefinite |
That last row is the real one. Implementations don’t stall on technology. They stall when nobody on the provider side owns decisions about how workflows should change.
What “fully operational” means
Go-live isn’t the finish line. Expect roughly 60 days past cutover before AR days return to baseline, and another quarter before your team is using the system’s denial workflows rather than the workarounds they built in the old one. Plan for it. The providers who budget for a temporary dip get through it; the ones who expect day-one improvement conclude the software failed.
