United States
Modern Dental EHR Architecture
Every dental practice runs a distributed system, whether anyone designed it or not: clinical record, scheduling, imaging, billing, communications, and a handful of integrations, all holding overlapping copies of the same facts. Architecture is the discipline of deciding — on purpose — where each fact lives, who may change it, and how the copies stay honest. Practices that skip the deciding still get an architecture; they just get one made of defaults and accidents.
Trace one visit and you have drawn your architecture
Follow a single new-patient visit through the stack. The patient books — a scheduling record exists, perhaps created by an online-booking tool that then syncs to the PMS. Intake forms arrive from a forms service and land, structured or as PDFs, in the record. Insurance eligibility is checked through a clearinghouse. The clinician charts findings and writes notes in the EHR; radiographs are captured in an imaging system linked by a bridge. A treatment plan becomes a scheduled follow-up and a ledger entry; a claim goes out through the clearinghouse; reminders flow from a communications platform that keeps its own copy of the patient. That is eight or more systems touching one visit — each holding some version of the patient, each an integration seam where copies can drift. Architecture is simply making that map explicit and putting rules on it.
Whiteboard every system that holds patient data in your practice, draw arrows for each data flow, and mark each arrow with three facts: direction, frequency, and what happens when it fails. Most practices discover arrows nobody owns and at least one system holding data nobody remembers granting it.
System of record: one owner per fact
The central architectural rule is that every data object gets exactly one system of record — the place where the canonical version lives and where changes are made. Every other system holding that object holds a copy, and copies are caches: useful, necessary, and never authoritative. When two systems disagree about a phone number or an appointment time, the system-of-record designation is what makes the disagreement resolvable in seconds instead of becoming a debate.
| Data object | Common system of record | Typical cache holders | The drift to watch for |
|---|---|---|---|
| Patient identity & demographics | PMS/EHR platform | Comms tools, imaging, forms services | Duplicate patients created by tools that write instead of match |
| Schedule | PMS | Online booking, comms/reminder tools | Two writers to one calendar — double-booking by architecture |
| Clinical chart & notes | EHR | Referral letters, exported documents | Edits made in exports that never return to the record |
| Imaging | Imaging system | EHR viewers, patient portals | Broken patient linkage after merges or renames |
| Ledger & balances | PMS billing module | Payment processors, statements services | Payments posted in one system, absent in the other |
| Communication consent & preferences | Deliberately chosen — often the comms platform | PMS patient flags | Opt-outs honored in one system and violated by another |
Communication preferences are the object practices most often leave ownerless — and the one where drift means messaging a patient who opted out. Whichever system you designate, verify the opt-out propagates to every other system capable of sending a message, and test it with a real number.
Integration patterns, and the questions that expose them
Vendors say "we integrate" about wildly different machinery. The honest taxonomy: real-time APIs (changes propagate in seconds, the strongest and rarest); scheduled syncs (batch updates on an interval — fine until the interval matters); file drops (exports consumed by another system, fragile and often unmonitored); database-level access (a partner reads your PMS database directly — powerful, and worth understanding before you allow it); and interface bridges (local software gluing two products, common for imaging, and a frequent casualty of updates). Standards exist in this space — HL7 and FHIR for health data exchange, DICOM for imaging — and dentistry's adoption of them is real but uneven, so treat a standards acronym as the beginning of a question, not the end of one.
Six questions that classify any claimed integration
- Direction: which system writes, which reads — or is it genuinely two-way, and what wins on conflict?
- Frequency: real-time, hourly, nightly? Is the interval acceptable for this data object?
- Identity: how are patients matched across the two systems, and what happens to near-misses?
- Failure behavior: when it breaks, does anything alert anyone — or does data quietly stop flowing until a patient notices?
- Reconciliation: is there a report that proves the two systems agree, and does anyone run it?
- Ownership: which vendor supports the integration itself, and who do you call when each blames the other?
Identity is the keystone — treat it like one
Every integration in the stack assumes both systems agree on who the patient is. That assumption fails in mundane ways: a nickname on the booking form, a typo'd birthdate, a remarriage name change, a family sharing one phone number. Each failure either creates a duplicate record — splitting one patient's history across two charts — or, worse, matches two different people to one record. Duplicates degrade quietly: notes attach to the wrong copy, balances split, recall fires twice. Cross-linked records are a safety problem. Identity hygiene is therefore not data janitorial work; it is the maintenance of the assumption your entire architecture rests on.
- Enforce search-before-create everywhereEvery workflow and every integrated tool that can create a patient must search first, on multiple fields. Find out what your online-booking and forms tools actually do when details differ slightly — many create first and ask questions never.
- Run the duplicate report on a scheduleMost platforms can list probable duplicates. Assign the report to a named person on a recurring cadence, and merge with care — merges are usually irreversible, so the workflow deserves a written procedure.
- Fix identity at the system of record onlyName changes, birthdate corrections, and merges happen in the designated owner system and propagate outward. Correcting a copy fixes one screen and guarantees future drift.
- Audit the seams twice a yearSample recent patients created by each integrated tool and verify they matched to existing records correctly. The seams that create patients are the seams that create duplicates.
Frequently asked questions
Do HL7 and FHIR actually apply to dental software?
They exist and are increasingly relevant — FHIR in particular is the direction of travel for health data exchange, and DICOM is well established for imaging — but adoption across dental products is uneven, and a vendor's "FHIR support" can range from a robust API to a checkbox. Treat standards claims as prompts for specifics: which resources, which direction, demonstrated against which partner systems.
Is an all-in-one dental platform better architecture than best-of-breed tools?
An all-in-one collapses many integration seams by putting more objects in one system of record — genuinely simpler, at the cost of accepting one vendor's weakest modules and concentrating your exit risk. Best-of-breed buys stronger individual tools and pays for them in seams you must govern. Neither is inherently right; what is wrong is choosing best-of-breed and then declining to do the integration governance it requires.
What should we do when two systems show different data for the same patient?
Resolve the instance, then the mechanism. The system-of-record designation answers which value is canonical — correct the copy from the owner, never the reverse. Then ask how the drift happened: a failed sync, a staff member editing the cache, an identity mismatch? Recurring disagreement on one seam means the integration lacks monitoring or reconciliation, which is an architecture gap, not a data-entry problem.
How can a non-technical practice owner audit their own integrations?
You need no technical skill to demand three artifacts per integration: a plain-language description of direction and frequency, evidence of what alerting exists when it fails, and a reconciliation check proving the systems agree — run one patient through and compare. Any integration for which no one can produce all three is running on faith, and the vendor conversation that follows is worth having this quarter rather than after an incident.
Our imaging bridge breaks every few updates. Is that normal?
It is common, which is different from acceptable. Local bridge software sits between two vendors' release cycles and is frequently tested against neither in advance. Practical defenses: delay non-urgent updates until the bridge vendor confirms compatibility, know exactly who supports the bridge itself, keep the acquisition workflow's failure mode understood (can you still capture images and link them later?), and weigh chronic bridge fragility as a real cost when either product next comes up for renewal.
Related on Dental EHR
How we handle this information
We keep material limitations visible, separate advertising from editorial judgment, and avoid inventing live scores or recommendations when the underlying evidence is not available.
Related in this network
Related properties may share common ownership. A cross-property link is not an endorsement — see our ownership disclosures.