Dental technologies are the software and devices a dental practice runs on, from the practice management system at the front desk to the sensors, scanners and cone beam units in the operatory. Most practices assemble them from several vendors, and the connections between them decide how much work staff repeat.
This guide maps the core systems, explains how dental images are stored and shared, covers the CDT code set and dental claims, describes what connecting to Open Dental involves, and ends with the environmental equipment rule and a selection checklist.
Which dental technologies does a practice run on?
Building software that connects to a dental practice?
Agnotic builds dental integrations for the client: Open Dental API work, imaging links, claims data and scheduling sync.
Dental technologies in a typical practice center on a practice management system that holds charts, treatment plans, schedules and the ledger. Around it sit imaging software for intraoral sensors, panoramic and cone beam units, intraoral scanners for digital impressions, patient communication tools and a claims clearinghouse, each from its own vendor.
Unlike most medical specialties, dentistry often uses a practice management system as its clinical record. The tooth chart, periodontal charting, procedure history and treatment plan live in the same database as appointments and payments.
That design makes the practice management system the hub for every integration. A new patient app, analytics product or AI imaging tool almost always needs to read from it and, in many cases, write back to it.
How do the core systems divide the work?
Each system owns a different part of the patient's visit, and problems appear where ownership is unclear. Agreeing which system is the source of truth for each data type prevents duplicate entry.
- Practice management system: patient demographics, insurance, appointments, the tooth chart, completed procedures, treatment plans and the ledger.
- Imaging software: radiographs, intraoral photos and cone beam volumes, linked to the patient record by an identifier passed from the practice management system.
- Intraoral scanner and CAD/CAM: digital impressions and restoration designs, usually stored in the scanner vendor's platform and sent to labs from there.
- Communication tools: reminders, recalls, online scheduling and forms, which read appointments and write back confirmations.
- Clearinghouse: claim submission, eligibility checks and payment remittance between the practice and dental payers.
In practice, the patient identifier is the thread that holds this together. When a new imaging or communication tool is added, the first design decision is which identifier it uses and what happens when demographic details differ between systems.
Intraoral scanner files usually travel from the scanner vendor's platform straight to the dental lab. The practice record should still hold a link to each lab case, the lab used, the due date and the delivered restoration, so a remake or warranty question can be answered from the chart.
Multi-location groups add a second question: one database or many. A dental service organization with a separate practice database per office needs a reporting layer that maps each office's patients, providers and fee schedules into one model before it can compare locations.
Digital radiography and image formats
Dental images are often stored in the imaging vendor's own format and opened through a bridge from the practice management system. DICOM is the shared standard for medical images, and the ADA has published guidance on applying it in dentistry.
The format choice matters most when something changes. A practice that switches imaging vendors, refers a patient to a specialist or adds an AI reading tool needs images that carry the patient, date, tooth and device details with them, which a proprietary format may not provide outside its own viewer.
- Bridges: a bridge typically launches the imaging software with the selected patient's identifier and demographics from the practice management system.
- Identifier risk: a bridge that passes the wrong ID, or meets an existing ID with different details, can file images to the wrong patient or change demographics in the imaging program, so IDs are reconciled before a bridge goes live.
- Export: ask whether the imaging software can export DICOM with patient and acquisition metadata, and test it with real images before buying.
- Cone beam volumes: these files are much larger than intraoral images, so storage, backup and viewer access need separate planning.
AI tools that read radiographs depend on these choices. A tool that receives DICOM with intact metadata can match its findings to the right patient and tooth, while one that works from screenshots or exported JPEGs loses that context.
How do CDT codes and dental claims work?
Dental procedures are reported with the Code on Dental Procedures and Nomenclature (CDT), which the American Dental Association maintains. The ADA describes CDT as the HIPAA standard for reporting dental procedures and notes that the code on a claim must come from the CDT version in effect on the date of service.
- Annual updates: the ADA revises CDT every year, so code tables need effective dates and the claim logic picks the version by date of service.
- Licensing: the ADA treats CDT as its intellectual property, so a product that shows CDT descriptors should confirm its licensing position with the ADA.
- Claim transaction: electronic dental claims travel in the HIPAA dental claim format, usually through a clearinghouse that also returns acknowledgments and remittance.
- Teledentistry: CDT includes codes for live and store-and-forward teledentistry, reported alongside the procedures delivered in the visit.
- Tooth and surface data: many dental codes need the tooth number, surfaces or quadrant, so the claim depends on the chart being recorded at that level.
Tooth numbering is part of the data contract. US practices generally use the Universal numbering system, while the FDI notation is common in other countries, so a product that serves practices in more than one country has to convert between them.
Treatment plans connect clinical and financial data. A plan lists proposed procedures by tooth, the practice estimates insurance coverage against them, and the patient accepts some or all phases. Software that reads treatment plans needs to tell proposed, accepted and completed procedures apart.
Claim rejections usually trace back to the chart. A practice that reviews rejected claims by reason, such as a missing tooth number, a surface the code does not allow or an outdated code, can fix the template or picklist that caused the problem instead of correcting each claim by hand.
Some dental services are billed to medical plans instead, such as certain oral surgery or sleep apnea appliance cases. Those use medical code sets and claim formats, so a dental product that handles them needs both paths.
What does connecting to Open Dental involve?
Connecting to Open Dental usually means using its REST API, whose resources mostly map to Open Dental's database tables. Open Dental's programming resources describe the API as the only permitted way to write to the database, because direct writes are unsafe and leave no record of which program or user made a change.
- Deployment mode: the API can run on an office workstation, on the office's database server, or through Open Dental's cloud endpoint, and the right choice depends on where the outside product runs.
- Keys: each request carries a developer key and a customer key, and the practice can enable or disable the customer key in its own setup.
- Reads: reading data for dashboards or reporting does not need Open Dental's approval, so many products read broadly and write narrowly.
- Writes: appointments, patient updates and notes go through the API, which applies Open Dental's own checks and security logging.
A safe sequence for a new integration is to start read only, prove the data mapping on a copy of a real practice database, then add writes one resource at a time with the practice's staff checking the results in Open Dental itself.
Check licence and API terms on Open Dental's own site rather than relying on older articles, because the terms and modes have changed across versions.
Amalgam separators and other compliance equipment
Not every dental technology is digital. Under the EPA dental effluent rule, 40 CFR 441.30, covered dental offices had to install amalgam separators meeting a standard of at least 95 percent removal efficiency, or an equivalent device, by 14 July 2020.
- Who is covered: offices that place or remove amalgam and send wastewater to a public sewer system, with exclusions for some specialty practices and mobile units.
- Maintenance: separators are inspected on the manufacturer's schedule, and a malfunctioning unit is repaired or replaced promptly.
- Practices: waste amalgam stays out of the drain, and vacuum lines are cleaned only with products the rule allows.
- Records: inspections, canister replacements and the one-time compliance report are kept for the control authority.
These duties create records an office has to keep. A simple maintenance log inside the practice's operations software, with reminders tied to the manufacturer's schedule, keeps them in one place for an inspection.
A dental technology selection checklist
- 1. Source of truth: name the system that owns demographics, the chart, images and the ledger.
- 2. Identifier: confirm which patient ID every bridge and app uses and how mismatches are handled.
- 3. Image export: confirm DICOM export with metadata before buying imaging software.
- 4. Code licensing: confirm the licensing position for any product that displays CDT descriptors.
- 5. Claims path: check dental claim support through the chosen clearinghouse, and medical claim support where needed.
- 6. Write-back rules: decide which data an outside product may write and route those writes through the API.
- 7. Code updates: load each year's CDT version with its effective date so claims use the version valid on the date of service.
- 8. Business associate terms: put agreements in place with each vendor that stores or handles patient data.
How Agnotic can help
Dental software projects usually come down to the practice management system, the image store and the identifiers between them. Agnotic Technologies takes on that integration work for the client: Open Dental API integrations, imaging links that keep patient IDs consistent, claims and treatment plan data feeds, and scheduling and recall sync for patient-facing apps.
Agnotic designs each integration to read broadly and write carefully, through the supported API, so the practice's own records and permission settings stay in control.
Plan a dental integration with Agnotic
Review Open Dental integration services, or visit the specialties hub for more practice software articles.
Related reading on Agnotic
Continue with imaging standards, device software and other specialty technology guides.
