Stop being on hold for 14 minutes per patient.

For practices on Dentrix, Eaglesoft, Open Dental, or Curve: under one hour. We connect via your existing PMS API (or, for Open Dental, the standard ODBC bridge), pull a read-only snapshot of your last 12 months of claims and schedule, and run a hindsight analysis the same day so you see what we would have caught. Live operation begins the next morning. No data migration. No staff retraining offsite. No new servers.

If you're on a system not in our integration list, we'll either build the connector in 30 days or tell you upfront that we can't.

No. DRSupport sits on top of your PMS — not next to it. Your charts, schedule, and patient records still live in your existing system. We read from it and write back to it. Your clinical and front-desk team keep using the screens they know. The only new screen anyone sees is the owner dashboard, and that's optional.

Practices that have switched off their PMS to try DRSupport-only systems have always come back. We learned. We don't ask you to.

We sign a Business Associate Agreement before we sign anything else. Data is hosted in U.S. AWS regions, encrypted in transit (TLS 1.3) and at rest (AES-256). Access is role-based and logged immutably. We do not sell, share, or train third-party AI models on your patient data — read that twice, because it disqualifies most of our competitors.

We're HIPAA-aligned today and SOC 2 Type II by Q3 2026. Our Type I report is available now under NDA. If your DSO or attorney needs a security questionnaire, we have one pre-filled.

$1,500 per month per practice, flat. No per-claim, per-patient, or per-feature fees. No setup fee for practices on supported PMSes. No annual lock-in — you can cancel any month, with one month's notice. Multi-location practices add $700/month per additional location.

We also offer a 30-day pilot for $0. The pilot includes a hindsight analysis of your last 90 days showing exactly what DRSupport would have recovered. If the report doesn't justify the price, you don't continue.

About 90 minutes total, split into two sessions. Front desk learns the eligibility queue and the cancellation-recovery feed in 45 minutes. Billers learn the claim scrubber in 30 minutes. Doctors learn the SOAP note approval flow in 15 minutes — it's literally one button.

The point of DRSupport is that your staff does *less* once it's running, not more. We measure success in part by how rarely your team needs to log in. If they're spending more than 15 minutes a day in DRSupport, we're failing.

Two layers. First, the claim went out clean — meaning the denial is on something we couldn't predict (a payer rule change, a benefit detail the patient didn't disclose, a clinical question). DRSupport flags the denial overnight, drafts the appeal letter using the payer's specific denial code and your chart notes, and queues it for your biller's one-click approval the next morning.

Second, our denial-prevention rate isn't 100% — it's around 96–98%. The methodology page documents the math. Practices on DRSupport see denials drop from industry-average 8% to under 2%.

Yes. The most common starting wedge is the claim scrubber — measurable ROI in two weeks, and it doesn't touch clinical workflow. Some practices start with the SOAP-note module instead because the doctor's nightly charting is what's killing them.

Pricing is the same whether you turn on one module or all four. We made it that way deliberately so you adopt at the pace your team can actually absorb. Most practices have all four running within 60 days.

You do. Always. You can export your full data set in standard formats (CSV, FHIR, ADA dental claim format) at any time, including the day you cancel. We retain de-identified, aggregated claim metadata for product improvement — surface codes, denial reasons, payer rule patterns — never patient identifiers, never your charting content. The full data-handling policy is in our BAA and posted at drsupport.org/security.

If a competitor tells you anything different about their own product — that they "own" or "co-own" the data — that's the answer to a different question than the one you asked.