Orthodontic Practice Software Problems: The 7 That Leak Contract Revenue, and How to Avoid Them

Why does fixing contracts turn into a practice management replacement proposal?

A group asks for one thing: stop the contract drift. Discovery starts, and within a fortnight the scope includes scheduling, imaging comparison, clinical notes and a patient portal, because those are also frustrating and this is the first time anyone has asked. The proposal that comes back replaces Dolphin Management or Ortho2 Edge entirely, at which point the project is a clinical migration and the doctors, correctly, lose enthusiasm.

What makes this specific to orthodontics is that the clinical system is genuinely good at the clinical part. Imaging, cephalometrics and the treatment card are not where the money leaks, and rebuilding them is expensive with almost no upside. The leak is in contracts, aligner case state and group level money, which is a layer rather than a system.

The discipline that works is to name the boundary in the kickoff and hold it. Keep the practice management system as the clinical system of record. Build the contract, case and money layer above it. That is the $60,000 to $130,000 first release in 12 to 16 weeks covering contract lifecycle with amendment handling, payment schedule sync and a group receivable dashboard, then $150,000 to $400,000 over 6 to 12 months for aligner sync, insurance benefit modelling, extraction and multi system consolidation. Any proposal that begins by migrating clinical data should be read again slowly.

What goes wrong when you migrate contract data out of spreadsheets and the ledger?

Your spreadsheet and your practice management ledger disagree. That is the entire migration problem, and it is not a data problem, it is an adjudication problem.

The disagreements are specific and each needs a human decision. A contract was amended in the system but the monthly at the processor was never changed, so collected to date does not match either record. A patient transferred between offices and exists twice. A treatment was extended without the agreement being re signed, so the enforceable amount and the recorded amount differ. A patient moved out of state at month fourteen with unearned revenue on the books and nobody closed the contract.

Nobody can automate those. A script can flag them, and then a named person from your team has to decide, patient by patient, which number is right. Groups that budget migration as a load discover this in week two and the timeline slips, because there is no way to proceed without the decisions.

What works is budgeting 2 to 4 weeks inside the 12 to 16 week first release, with a named person at roughly ten hours a week, and starting the exception queue in week one rather than after the build. The by product is worth having on its own: for many groups this is the first accurate statement of contract receivable they have had.

Why do the practice management, processor and aligner integrations break after launch?

All three break, and only one of them is a technical problem.

Practice management access is contractual. Dolphin's interface is usable, Ortho2 Edge varies by how you are hosted, and Cloud9 access depends on your agreement. If a vendor will not grant access you are into database level reads or scheduled extracts, which is real engineering and should be priced as such. Confirm access in writing before scoping, because the answer changes the shape of the build.

The processor breaks around schedule management. If your merchant provider has no interface for modifying a payment schedule, the amendment workflow either stays partly manual, which reintroduces the drift you are fixing, or you change processors, which is a decision with its own cost and timeline. Establish this in week one.

Aligner portals break because they are not yours. Where an interface exists, syncing case state is straightforward. Where it does not, a scheduled job pulling case status per doctor account works and needs maintenance whenever the portal changes, which it will. Price that as ongoing support rather than a one time build, and be honest internally that a portal change can interrupt the feed for a few days.

The fix across all three is to name the system, the access method, the contractual basis and the maintenance expectation in the statement of work rather than accepting a general claim about integration.

What happens when HIPAA scope is treated as a checkbox?

It surfaces as rework at the worst point, which is after the interface is built and before go live, when somebody asks where protected health information lives in the development environment.

The common failures are ordinary. Production data copied into a staging environment so testing feels realistic. Access controlled at application level but not separated per office, so a front desk employee at one location can see another location's patients. Audit logging built for debugging rather than for access review, so you can see errors but not who read a record. No defined path for revoking a terminated employee's access across offices, which is exactly the scenario an auditor asks about.

None of those are hard to build correctly the first time and all are expensive to retrofit, because they touch the data model and the access layer rather than a settings page.

The fix is to treat HIPAA as architecture with a cost attached. In our builds the associated work, meaning signed business associate agreements, encryption at rest and in transit, per office role separation, full access audit logging and synthetic data below production, is typically 10 to 15 percent of the cost. A developer who says they are compliant without describing those controls has not done this before, and the phrase to listen for is synthetic data below production, because teams that have done it say it unprompted.

Should you build custom or configure what you already own?

Stay on off the shelf if you have one to three locations, one practice management system, a single doctor setting fees and under about 400 starts a year. At that scale Dolphin or Ortho2 Edge plus a disciplined treatment coordinator plus a decent spreadsheet is cheaper and lower risk than anything we would build, and a consultant telling you otherwise is selling. The reconciliation pain is real at that size and it is one person, part time.

Even at larger scale, do not replace the clinical system. Imaging, cephalometrics and the treatment card should stay exactly where they are.

Build when three or more apply. Four or more locations, or more than one practice management system in production. A contract receivable above roughly $4 million that you cannot state accurately in an afternoon. More than about 30 percent of starts are aligner cases whose status lives outside your practice management system. You are acquiring and the prospect of migrating each acquisition onto your system is why you have not moved faster. Or a named person, usually a regional treatment coordinator or operations manager, spends more than 20 hours a month reconciling numbers between systems.

The clearest signal is when your growth plan requires standardising how contracts work across offices and the practice management system cannot enforce that standard. At that point the software is the constraint on the business.

How do hidden costs get into the quote?

The first is practice management access, which is a commercial unknown priced as a technical certainty. If the vendor will not grant interface access, database level reads or scheduled extracts are a different piece of work and a different number.

The second is processor migration. If the amendment workflow requires schedule management your current provider does not offer, changing processors carries its own project: stored card migration, customer communication and a period where two systems are live.

The third is the number of live systems at go live. Location count barely moves the price, but two practice management systems is materially more than one and five roughly doubles the reconciliation work, because each one has its own identifiers and its own idea of a patient record.

The fourth is aligner vendor coverage. Invisalign alone is one integration. Invisalign plus SureSmile plus an in house lab is three, each with its own state model.

The fifth is the document extraction work that makes clinical notes and explanation of benefits statements usable. Parsing approval notes, lab prescriptions and remittance advice into structured fields is genuinely valuable and it is a workstream, not a feature toggle. Scope it explicitly or it arrives as a change request in month four.

What separates an orthodontic build that works from one that fails?

The first separator is whether the developer models a contract as an event log rather than a row. Ask them to draw it before any proposal. If you see a table with a balance column, they have built dental software and not orthodontic software. You want to hear amendment, effective date and revenue recognition unprompted, and you want them to ask whether your insurance is assigned or patient paid before they draw anything.

The second is whether an amendment fires a workflow rather than an update. Recompute the schedule, push the corrected schedule to the processor, regenerate the agreement, send it for signature, flag the insurance assignment, and hard block if the amended total does not match the amended agreement. That block is what stops the drift.

The third is whether insurance is modelled as a benefit with a lifecycle rather than as a claim. A lifetime maximum paid down over months, assigned to the practice, subject to continued eligibility, with re verification on a cadence so a coverage change surfaces at month eleven rather than month fourteen.

The fourth is a group level patient identifier that survives a transfer between offices, because without it the group view is six copies of one office.

The last is ownership from day one rather than on final payment: the repository, the infrastructure accounts and the data, in your name, with a handover that is a repository, a runbook and two weeks of pairing. At Digital Heroes that is the arrangement from the first commit.