How to Build Dental Practice Management Software (Like Dentrix or Eaglesoft)

A dental group running 20 chairs pays $10K-$16K per month for Dentrix or Eaglesoft. That is $120K-$192K per year, every year, for software you do not own and cannot modify. If you need a feature your software does not have, you wait for the vendor's roadmap. If your workflows do not match how the product was designed, you work around it.

The American Dental Association's Health Policy Institute reported that DSO-affiliated dentists now represent 22% of all practicing dentists in the US, up from 6% in 2010. At that consolidation rate, the economics of custom software become viable for a growing share of the market.

Dental Service Organizations (DSOs) with 10 or more offices do the math. The licensing cost does not scale linearly, but even at negotiated rates, it is significant. More importantly, generic software forces every practice in the network to fit one set of workflows. Orthodontics practices need braces tracking. Oral surgery needs IV sedation documentation. Neither fits cleanly in software built for general dentistry.

The same pattern plays out across healthcare. Multi-location medical groups look at Kareo's per-provider fees and reach the same conclusion. Chiropractic chains, physical therapy networks, and optometry groups all face this: pay a vendor forever, or build once and own it.

This article covers what goes into a full practice management platform, where the complexity actually lives, and what it costs.

Who builds this

"The practices that thrive in DSO environments are the ones whose software works for their specialty, not against it. Generic platforms were built for the average workflow. The average workflow isn't how anyone actually practices." -- Dr. Chris Salierno, Chief Dental Officer at Tend, writing in Dental Economics, 2023.

The decision to build is rarely about the technology. It is about unit economics and control.

DSOs with 10 or more offices are the most common buyer. At that scale, custom software pays back in 6-12 months. After that, the platform is a competitive asset. You can build features your competitors cannot buy from a vendor.

Dental franchise systems need a unified platform across franchisees. When 40 locations run different software, consolidated reporting is impossible. A single platform changes the economics of running the network.

Specialty practices with unusual workflows. Orthodontics tracks each patient's treatment in stages across 18-24 months. Oral surgery documents sedation, anesthesia, and surgical procedure notes that have nothing to do with a standard cleaning workflow. Generic software adds friction to these practices every day.

Medical practices facing the same problem. The architecture is identical. Different procedure codes (CPT instead of ADA codes), different clinical modules (no tooth chart, different note templates), same infrastructure underneath. If you are a multi-location medical group tired of paying per-provider fees to Kareo or similar, the same build applies.

What the software needs to do

There are six core modules. Five of them are manageable. One is hard.

Patient scheduling

Dental scheduling is not just picking an open time slot. Each appointment type has a duration, required equipment, and provider requirements that all need to match simultaneously.

A crown preparation takes 90 minutes. A periodic cleaning takes 45 minutes. An emergency extraction takes 30 minutes. Each appointment type needs to know its duration, which equipment it requires (Chair 1 has X-ray; Chair 3 has nitrous oxide), and which providers are qualified to perform it.

The scheduling engine finds slots where the right provider and the right equipment are both free at the same time. This is a constraint satisfaction problem. When a patient calls to book a crown prep with Dr. Martinez, the system needs to find a 90-minute window where Dr. Martinez is available and a chair with X-ray equipment is also available.

For multi-location DSOs, add location selection. A patient might prefer to book at their nearest office, but the system should surface availability at other locations if their preferred one is full.

Clinical records and the tooth chart

The patient chart is the clinical core of the software. It holds everything that happened to the patient clinically.

Clinical notes follow SOAP format: Subjective (what the patient says), Objective (what the clinician observes), Assessment (diagnosis), and Plan (treatment). Good dental software makes SOAP note entry fast, with templates for common procedures and free-text fields for anything unusual.

The tooth chart is the most visually distinctive part of dental software. It is an interactive diagram of all 32 teeth. A clinician clicks a tooth and marks its condition: cavity, crown, missing, implant, cracked, root canal completed. The chart becomes a visual record of the patient's dental history. Colors and symbols communicate status at a glance.

X-rays and intraoral photos attach directly to the patient record, linked to the specific date they were taken. Pulling up a patient's record shows their full radiographic history, not just a folder of image files.

Medical history and allergies are separate fields with hard-coded required review prompts. If a patient is allergic to penicillin and the practice has not confirmed this before treatment, that is a liability problem.

Treatment planning

After a clinician identifies what a patient needs, they build a treatment plan. The plan lists proposed treatments, estimated costs for each, and links to applicable insurance coverage.

The patient reviews the plan and approves what they want to do and when. Some patients approve everything. Others decline expensive procedures and revisit later. The system tracks the status of each treatment item: planned, approved, completed, declined, cancelled.

Good treatment planning software shows the patient their financial obligation alongside the clinical recommendation. Insurance covers X. The patient owes Y. This conversation happens before any work is done, which reduces collection disputes later.

Insurance billing

This is the hard part. It is the reason healthcare software takes longer and costs more than software in other industries. Change Healthcare's 2024 annual report processes over 15 billion healthcare transactions per year, which illustrates both the scale of the problem and why no vendor connects directly to insurers: the EDI clearinghouse model handles the routing complexity that individual software vendors cannot.

Dental insurance uses ADA procedure codes. A periodic oral exam is D0120. A periapical X-ray is D0220. A tooth extraction is D7140 for a simple extraction, D7210 for a surgical extraction. Every billable service has a code, and claims must use the correct code or they will be denied.

Claims go out electronically in EDI 837P format. EDI stands for Electronic Data Interchange. The 837P is the standard transaction format for professional claims. You do not send this directly to insurance companies. You send it to a clearinghouse.

A clearinghouse is an intermediary that validates claims, translates EDI formats, and routes them to the correct payer. Change Healthcare and Availity are the two dominant clearinghouses. Your software connects to one via their API or SFTP. The clearinghouse handles the routing.

After the insurer processes the claim, they send back an Electronic Remittance Advice (ERA), which is EDI 835 format. The ERA tells you what the insurer paid, what they denied, and why they denied it. Denial reason codes come as two-character codes (PR for patient responsibility, CO for contractual obligation, OA for other adjustments). Your software needs to parse these and present them in plain language to the billing staff.

The patient owes the balance. The billing module tracks what was billed, what insurance paid, and what the patient still owes. It generates patient statements and tracks payment plans.

You cannot skip clearinghouse integration and connect directly to insurers. Insurance companies do not offer direct API access to software vendors. This is not a technical gap you can close with clever engineering. The clearinghouse model is the industry standard, and your software needs to work within it.

HIPAA compliance

Patient health data is Protected Health Information under HIPAA. Building software that handles PHI comes with a set of technical requirements that are non-negotiable. RaftLabs has built HIPAA-compliant systems for healthcare groups, and the most common mistake we see is treating compliance as a final checklist rather than an architectural decision made before the first line of code. Retrofitting encryption and access logging onto a system built without them costs 2x what building it right from the start does.

All PHI must be encrypted at rest using AES-256. All data in transit must use TLS 1.3. Every access to a patient record must be logged: who accessed it, when, from which IP address, and what they did.

Role-based access controls determine who can see what. A front-desk coordinator books appointments and handles billing. They do not need to see clinical notes. A hygienist sees clinical notes and treatment history. They do not need to access billing records. An office manager sees everything. These access rules must be enforced at the data layer, not just in the UI.

Every cloud vendor you use must sign a Business Associate Agreement (BAA). AWS, Google Cloud, and Azure all offer HIPAA-eligible services and BAAs, but you must use only their HIPAA-eligible service tiers. Not all AWS services are HIPAA-eligible. Your team needs to verify each service before using it.

The practice must conduct an annual security risk assessment. The software supports this by providing audit logs and access reports that demonstrate who accessed what and when.

HIPAA compliance adds $30K-$50K to the build compared to an equivalent non-regulated application. The cost covers security architecture review, encrypted storage configuration, audit logging infrastructure, access control implementation, and documentation of compliance controls.

Patient communication

Patients forget appointments. A 10-15% no-show rate is common in dental practices. Automated reminders cut that significantly.

The communication module sends appointment reminders by SMS and email at 48 hours and 2 hours before each appointment. It sends recall reminders when patients are due for their 6-month cleaning. After visits, it sends care instructions specific to the procedure performed.

A patient portal gives patients online access to their forms, records, and upcoming appointments. For new patients, the portal handles intake forms digitally. The patient fills them out at home before their first visit. No paper clipboards. No front-desk data entry.

Reporting

A practice manager needs to see a small set of reports regularly. Production (revenue) broken down by provider, by procedure code, and by insurance plan shows where money comes from. Collection rate shows the gap between what was billed and what was collected. Case acceptance rate shows how often patients approve treatment plans versus declining them. New patient count and cancellation rate round out the standard weekly review.

Multi-location DSOs need all of these rolled up across the network, with the ability to drill down to any individual location.

Tech stack

The stack for a HIPAA-compliant dental platform is straightforward, but the configuration details matter.

React on the frontend handles the interactive tooth chart and clinical UI. Node.js handles the backend API and EDI processing. PostgreSQL stores all patient data with Transparent Data Encryption enabled for HIPAA's encryption-at-rest requirement. All of this runs on AWS HIPAA-eligible services, with a signed BAA from Amazon.

EDI integration connects to Change Healthcare or Availity via their API. This handles 837P claim submission and 835 remittance parsing. Twilio handles SMS and email for patient communication. For identity and authentication, a HIPAA-compliant identity provider (Auth0 Healthcare or AWS Cognito with the right configuration) handles session management and MFA.

Timeline and cost

The build takes 20-26 weeks for a full platform. The insurance billing module and HIPAA infrastructure consume the most time.

A simpler build for a single-location practice without EDI integration can ship in 14-16 weeks. It would handle scheduling, clinical records, patient communication, and manual billing. The trade-off is that billing staff must submit claims manually through the insurer's own portal, which is significantly slower than electronic submission.

For a full DSO-grade platform with multi-location support, EDI integration, and all reporting: $200K-$320K. That range moves based on how many specialties the software needs to support, whether you need a native mobile app for providers, and how complex the multi-location data architecture is.

HIPAA compliance accounts for $30K-$50K of that total. It is not optional. Any software handling patient health data is legally required to meet these standards. Treating it as optional until you grow creates significant liability and will require expensive remediation later.

What makes the build worth it

Generic dental software is built for the median practice. It handles a periodic cleaning workflow well. It handles billing for basic procedures well. When your workflows diverge from the median, you either work around the software or you pay for customization that never quite fits.

A custom build starts with your workflows. If you run an orthodontics practice, the software models your braces tracking process. If you run a DSO with 40 locations, the reporting shows you what you actually need to see, not what the vendor decided all practices need.

The licensing math makes the decision easier over time. At $500-$800 per provider per month, a DSO with 30 providers pays $15K-$24K per month, or $180K-$288K per year. A custom platform at $250K pays back in 10-16 months and continues paying dividends for as long as you operate.

If you are scoping a practice management platform and want to know how the architecture applies to your specific workflows, RaftLabs works with healthcare and dental groups to scope and build HIPAA-compliant systems. The first conversation is a 30-minute scope call, no commitment.