Tell us how your practice bills.

Yes. Point it at SQL Server Express or higher instead of LocalDB and every workstation shares one database. Migrations run on startup, and the records two people are most likely to edit at once carry a row version so the second save is reported rather than silently overwriting the first. LocalDB is a per-user process and cannot be reached from another machine, so it is the single-machine option only.

Yes for electronic claims, and there are two routes. ABILITY/Inovalon reaches Medicare and commercial, enrolled separately with a service id each. Availity is the other, and it is where most commercial payers and a large share of state Medicaid programs are reached — the half of a DME book Medicare crossover does not cover. One account of either kind is enough. If you hold both, ABILITY keeps priority, so commercial traffic is not silently rerouted the day an Availity key gets filled in. The route is chosen by what you have configured rather than by a dropdown, and which one a claim went down is named on the confirmation and in the audit trail, because that is the first question when a payer says a claim never arrived. Check the endpoint paths and authentication against your clearinghouse's integration guide before the first live claim: those are configuration here precisely because they may not match what we assumed.

Only for tracking that updates itself, and for buying labels. Both go through EasyPost on one account, which covers USPS, UPS, FedEx and DHL — so there is no separate enrollment per carrier — and a single test-or-production switch covers both, so live labels cannot be bought against a test account by mistake. Without a key, tracking numbers are still recorded and scans are entered by hand; nothing else changes. One caveat before you rely on it: the payload mapping is tested against real EasyPost tracker data, but the endpoint and authentication follow their published documentation and have not been exercised against a live key, so verify it during setup.

Yes, by CSV. The import matches on Medicare ID, or on name plus date of birth — never name alone, because merging two people who share a name puts one patient's equipment on another's claim. It reports per row rather than aborting, so a file of two thousand patients with one bad date imports 1,999 and names the one. Inventory, HCPCS codes and payer fee schedules import the same way.

Thirteen codes ship as a demonstration. The real DMEPOS list runs to thousands and changes, so you import yours — code, description, base price, rental category and whether it needs prior authorization. A category spelling the import does not recognize is reported rather than guessed, because defaulting one to Purchase is the exact state the import exists to correct.

Yes, and it builds the claim rather than only recording the policy. Loops 2320 and 2330 carry what the primary decided — its own adjustment reason codes and what it paid, passed through unchanged, because a secondary reads those to work out what it owes and tidying them is inventing the primary's decision. It refuses rather than guessing: no active secondary on the date of service, or a primary that has not answered yet, and it says which. Only a remittance counts as the primary having answered, so a payment the patient made is never mistaken for one. Crossover from Medicare still handles many secondaries on its own; this is for the ones it does not.

It estimates it, and the report says so on its face. The figure is derived over the invoices you raised — never stored, so it cannot drift from them — at the state and local rates you entered. Rates are entered rather than shipped, because fifty seeded rates would be a promise to maintain them four times a year, and a stale rate looks authoritative in a way a blank field does not. Treat it as a floor rather than a filing amount: local rates stack in most states, home-rule cities run their own tax base rather than merely their own rate, and nexus is a legal conclusion rather than arithmetic. It never prints "tax owed", and a zero always says which zero it is — no rate entered, or nothing marked taxable.

No. It records them — check, EFT, card, cash, or posted automatically from an 835 — with the method and reference you need to reconcile against a bank statement. But there is no card processing, no ACH and no bank connection. Statements are bills you send, and a commission run is a document you hand to whoever does the paying: marking it paid records that a payment happened somewhere else, with the reference you were given.

It is your SQL Server database and your folders, on your hardware. Nothing is encrypted in a format only we can read and nothing is held anywhere you cannot reach. There is no export step to negotiate because there is nothing to export from.

No. EasyDME is a Windows desktop application, and that is a deliberate shape rather than a stage it will grow out of — it keeps your database on your own hardware with no hosted tenant. If you need people working from home browsers or several practices in different states, this is the wrong product and we would rather say so early.

We quote per practice rather than publishing a price list, because a two-person supply shop and a twenty-seat rental operation are not the same install. Tell us roughly how many patients and workstations you have and we will give you a number.