Dental Practice Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the claims module swallow the whole project so often?

Because it is the module everyone agrees is essential and almost nobody scopes honestly. Claims looks like a form that gets sent somewhere. It is actually electronic data interchange work with a certification process, sandbox access controlled by a third party, test files that fail on details nobody documented, and turnaround times you do not control. When a team has not shipped it before, the estimate is wrong by a factor that is not recoverable inside the schedule.

The damage is not just the claims module. It is that scheduling, charting and the patient portal sit finished but unreleased behind it, because the plan promised one launch.

The fix is to phase deliberately. Ship scheduling, charting, treatment planning, the portal and payments first, and keep posting claims through your existing tool while that runs. Your front desk gets value in month four instead of month nine, and the claims work then happens against a system already proven in daily use, with real procedure data to test against instead of fixtures. If a vendor resists this sequencing, ask them directly how many electronic claims integrations they have taken through certification. The answer usually explains the resistance.

What goes wrong migrating charting, ledgers and imaging?

Three data sets, three different failure modes, and practices routinely plan for one.

Charting is the hardest to move faithfully. A tooth and surface model with historic restorations, existing conditions, treatment plans in various states of acceptance, and perio charting does not map cleanly between systems, because each product made different modelling choices about what a surface is and how a plan phase behaves. Some of it does not migrate at all and has to be kept as read only history.

Ledgers carry their own trap. Historic balances, insurance write offs, unapplied credits and payment plans all have to reconcile to the penny, and a discrepancy discovered after cutover is a patient conversation you cannot win. Imaging is usually the least bad, since studies often stay where they are and get linked rather than moved, but the link has to survive, and a patient identifier that was reassigned during a previous migration will break it silently for a subset of records nobody thinks to check.

What works is deciding explicitly, before the build, what migrates as live data, what migrates as read only history, and what stays in the old system with a documented lookup path. Then reconcile ledgers in a report your practice manager signs off, and keep the old system readable for at least a year. Practices that plan a clean break discover in month two that a hygienist needs a perio chart from 2019 and it is gone.

Why do the imaging, clearinghouse and eRx integrations break after launch?

These three have one thing in common: none of them is under your control, and all of them change without telling you.

Imaging bridges to sensor and panoramic software from vendors such as DEXIS, Carestream and Sirona depend on software development kits whose quality varies widely, and a driver or version update on a single operatory machine can break the bridge on that chair only, which presents as a confusing intermittent fault rather than an outage. Clearinghouse connections change payer requirements and rejection codes on their own schedule. Prescribing through a certified network carries its own version and credential requirements, and the controlled substance side adds identity requirements that expire.

Design for the reality. Every integration needs a health check that runs on a schedule and alerts on failure, not just an error message when a user hits it. Rejections need to land in a worked queue with an owner rather than a report nobody opens. Version pinning and a documented upgrade test for imaging machines belongs in your operations runbook, because the vendor will not coordinate with you. And budget for periodic recertification rather than treating integration as a one time cost.

What happens when HIPAA controls are not designed in from day one?

Retrofitting them is expensive, and the retrofit usually lands at the worst moment, when a group is preparing for an audit or answering a security questionnaire from an acquirer.

The controls that shape architecture rather than sitting on top of it are specific. Encryption of protected health information at rest and in transit with managed keys. Role based access down to the location, so a front desk employee at one site cannot browse another site's patients. An audit log of who viewed or changed each patient record, which has to be written at the data layer rather than bolted into the interface. Automatic session timeout. Signed business associate agreements with every subprocessor, meaning your host, your messaging provider, your clearinghouse and your imaging cloud, each of which needs checking rather than assuming. And a tested recovery process, since a ransomware event that loses patient records is itself a reportable breach.

The practical fix is to make audit logging and access control part of the first module built, not the last. If the first release ships without them, every subsequent module inherits the gap and the eventual remediation touches everything. A vendor who raises business associate agreements and audit logs before you do is telling you something useful. A vendor who waits for you to raise them is telling you something too.

Should you build custom or configure what you already own?

Stay put if you are a solo office or a small group. Dentrix, Eaglesoft and Open Dental cover that shape properly, and paying to rebuild scheduling from scratch is a poor trade against marketing or an extra chair.

Open Dental deserves specific mention because it is open source with an accessible database, which lets you build the reporting, membership or multi location layer you actually lack while keeping a proven clinical engine. For many groups that is the correct answer: keep charting, claims and the clinical record where they are, and build only the piece that does not exist. A full replacement makes sense when the incumbent's data model itself is the blocker rather than its interface, which is less common than it feels during a frustrating week.

Build when the case is structural. Eight or more locations or a dental service organisation where per seat licensing plus per location data silos have become a monthly tax with no group level visibility. A front desk running three or four disconnected tools with hours of manual reconciliation between them. Or a workflow the product refuses to bend to, such as a membership plan, a specialty referral pipeline or a proprietary treatment acceptance flow. If none of that is true, keep the incumbent.

How do hidden costs get into the quote?

Integration count is the main one, and the tell is a quote produced without asking which imaging system and which clearinghouse you use. That quote is fiction, because those two answers move the number more than the feature list does.

Compliance work is the second. It is real engineering time on access control, audit logging, encryption and recovery testing, and it is frequently priced as a line item when it should be priced as a percentage of everything.

Then the ones that arrive late. Certification and recertification cycles for claims and prescribing, which cost calendar as much as money. Data migration split across charting, ledgers and imaging, each with different effort. Training and parallel running, because your team is billable and the hours they spend learning a new system are real cost. Payment processing scope, where taking card data anywhere near your own servers expands compliance obligations sharply. And the permanent maintenance line for hosting, monitoring and integration upkeep, which does not end when the build does. One more worth naming because groups rarely ask: the cost of running the old system alongside the new one during parallel operation, since most vendors charge for that period whether you are actively using the product or simply keeping it readable.

What separates a build that works from one that fails here?

Sequencing separates them. The builds that work put a usable slice in front of staff within a few months and give the hardest module room to breathe afterwards. The builds that fail promise everything at once, then spend the back half of the schedule on claims while the rest of the system ages without users.

The vendor markers are consistent too. They ask which imaging vendor and which clearinghouse in the first call and scope around them, rather than quoting first. They raise business associate agreements, audit logging and encryption without prompting. They can name electronic claims work they have taken through certification rather than describing it in general terms. And they propose a migration plan that distinguishes live data from read only history rather than promising everything moves.

Then the commercial side, settled before kickoff rather than at handover. You own the code, the patient data and the infrastructure accounts, in writing, from the first commit. The entire point of going custom is to stop renting your own operations, and a group that ends up unable to move its own patient records has bought the same dependency it was trying to escape, at a higher price.