Dental practices and DSOs
Dental software built around Dentrix, not against it
Your practice already runs on a practice management system. The software worth building fits around it: eligibility checks, imaging, and a rollup view your PMS vendor never sells.
What a dental buyer should ask any vendor
4 things that decide this
- 01Ask which practice system the software has to work with. Dentrix, Eaglesoft and Open Dental each store the same chart data in a different shape. A vendor who has not opened the real database is guessing.
- 02Ask how an eligibility check runs. The X12 270 request and 271 response are the same format medical claims use. A dental check can ride that same clearinghouse rail instead of a bolt-on dental-only tool.
- 03Ask where imaging lives. A digital X-ray or scan tied to a patient becomes protected health data the moment that link exists, whether it sits in the PMS or a separate system nobody checks.
- 04Ask how a DSO sees across locations. Each office runs its own PMS install with its own database. A group-level view is a data problem the PMS vendor was never built to solve.
The practice management system is the constraint, not the target
Dentrix, Eaglesoft and Open Dental each hold the chart, the schedule and the ledger for a practice. None of them expose a modern API by default. Switching a practice off one is rarely on the table, since staff are trained on it and the data behind it goes back years.
So the real work is reading around the system, not replacing it. Open Dental publishes an open API and an open database, which makes it easier to connect to. Dentrix and Eaglesoft usually mean a direct database link, a bridge tool, or a nightly export. Each one breaks differently when the practice updates its software.
A group of practices feels this at scale. Ten offices can mean ten separate PMS installs, each on its own database and its own version. Rolling that up into one view of production, collections or scheduling is a data problem first, a report second.
- 01Confirm which PMS a practice runs before scoping anything. The three systems are not interchangeable targets.
- 02Treat a PMS upgrade as a dependency that can break the integration, not a one-time setup cost.
- 03Design the DSO rollup as a data pipeline with its own schema, not a live query fanned out across ten databases.
- Patient visitChart and imaging captured in the PMS.
- Eligibility check270 sent, 271 returned before or after the visit.
- Claim submittedCoded procedures leave the PMS.
- PMS updatesA version change moves the schema underneath.
- Integration reads itSilently wrong, unless someone is watching.
- DSO rollupTen local databases, one honest view.
Most dental software projects budget for the first three steps and skip the fourth. That is the one that quietly breaks a working integration months later.
An eligibility check is the same problem as a medical claim
Dental benefits are checked the same way medical benefits are. An X12 270 request goes to a payer or clearinghouse, and a 271 answer comes back with what is actually covered. Treating this as a dental-only problem means rebuilding work that is already solved.
This shape shows up in insurance audit work too: read the record, check it against the payer's rules, send anything unclear to a person. The format is different here. That habit, read it, check it, let a person decide the hard cases, carries over.
Imaging has its own version of this problem. A digital X-ray tied to a patient counts as protected health data under HIPAA the moment that link exists. It does not matter which system stores the file. A build made without that in mind usually finds out during a security review, not before.
- Route a 270/271 exchange through the same clearinghouse pattern used for medical eligibility, not a dental-specific reinvention.
- Treat any image tied to a patient as protected health information from the first commit.
- Log who accessed a chart and when, at the record level, before an auditor asks for it.
The dental and DSO work we take
Built around the PMS a practice already runs, not a replacement for it.
PMS integration
Reading Open Dental's documented API, or building a bridge to Dentrix or Eaglesoft, with a plan for what happens when the practice upgrades.
Eligibility and benefits checks
270/271 exchanges run through a clearinghouse, so coverage is confirmed before the chair time rather than argued about after.
DSO rollups across locations
A pipeline that pulls production, collections and scheduling data out of ten separate PMS installs into one consistent view.
Imaging and chart handling
Storage and access controls built around imaging and chart data as protected health information, not as generic file uploads.
Patient intake and scheduling tools
Booking and intake software that writes back into the PMS instead of living as a disconnected form nobody in the office trusts.
Audit trails for who touched what
Access logged at the record level, so a who-saw-what question has an answer instead of a guess.
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
Bolt-on dental tool against a built integration
Most off-the-shelf dental add-ons stop at the first column. A DSO running several locations needs the second.
| Criterion | Generic dental add-on | What a built integration does |
|---|---|---|
| PMS connection | Assumes one system, usually the most common one. | Built for the PMS the practice actually runs, with a fallback plan for version drift. |
| Eligibility checks | A separate dental-only tool with its own login. | 270/271 exchange wired through the existing clearinghouse relationship. |
| Multi-location view | Per-office dashboards, manually compared. | One pipeline consolidating every location's PMS data. |
| Imaging access | Treated as a file upload feature. | Access-controlled and logged as protected health information. |
| PMS upgrades | Breaks quietly, discovered when a report looks wrong. | Monitored, so a schema change is caught before it corrupts a rollup. |
The stack this work runs on
Integration
Data
Application
What dental practices and DSOs ask us first
01Can you integrate with Open Dental?
Yes. Open Dental publishes an open API and an open database. That makes it the easiest of the three major dental systems to build against. We read and write to it directly, without a third-party bridge where one is not needed.
02What about Dentrix or Eaglesoft?
Both work, and neither exposes an open API by default. The usual path is a direct database link or a certified bridge tool, scoped to what the practice actually needs to read or write. We test the link against an upgrade before we rely on it, since that is where these connections tend to break.
03How do you handle imaging data under HIPAA?
As protected health data from the first design choice, not as a generic file type. Any digital X-ray or scan tied to a patient gets access control, encryption and logging at the record level. A signed agreement with a storage vendor is a contract. It is not a stand-in for those controls.
04We run a DSO with 12 locations on different PMS versions. Can you build one view across all of them?
Yes, and that version mismatch is exactly why a live query across all 12 databases fails in practice. We build a pipeline that pulls and normalises each location's data on its own schedule. The result is a consistent rollup, so a schema difference at one office does not break the report for the other eleven.
05How does dental eligibility checking actually work?
It runs on the same X12 270/271 transaction format used for medical eligibility. A 270 request goes out through a clearinghouse asking what a plan covers, and the 271 response comes back with the answer. Building or connecting to this properly means treating it as a document-and-rules problem, not a form that emails a payer.
Go deeper
- Healthcare software development →The wider constraints: audit trails, drift, and human-in-the-loop clinical AI.
- EHR integration →The same connect-around-the-record-system problem, one layer up from dental.
- HIPAA-compliant development →The controls a build needs before protected health information reaches any system.
- What a BAA does not cover →Why a signed agreement with your storage vendor is not the same as a compliant build.
