Teledentistry Software: What the Platform Has to Do, From Consent to the PMS Chart

The video call is the easy part of teledentistry software. Any HIPAA-ready video SDK will get a patient and a dentist talking. What decides whether a dental team keeps using the platform is everything around the call: who consented to what, where the photos went, which code went on the claim, whether a prescription was allowed, and whether the visit ever reached the practice’s chart.

I’m going to follow one visit through all of it. At 9 pm on a Thursday, a patient with a cracked lower molar opens her dental practice’s app, answers four questions, and uploads three photos. The dentist looks at them at 7:30 the next morning, decides it can wait for an in-person visit that afternoon, and the front desk books it. Simple for her. For the software, that’s a consent record, an identity check, an image pipeline, a clinical note, a code, a booking, and a write-back into the practice management system (PMS).

If you’re building a dental product and want the engineering side, our dental software development page covers what we build. This guide is the spec.

What Teledentistry Software Is: Four Kinds of Visit

Teledentistry software is the system that lets a dental team examine, triage, advise or follow up with a patient who isn’t in the chair. The American Dental Association defines teledentistry as “the use of telehealth systems and methodologies in dentistry” and names four ways to deliver it (ADA Policy on Teledentistry, updated 2020).

In my view, many dental questions after hours (“is this swelling an emergency?”, “did my crown crack?”) are photo questions, which makes store-and-forward the first thing to get right in a dental platform, ahead of the video call.

For where teledentistry sits among cloud PMSs, imaging and AI in a practice today, see our dental technology guide.

Teledentistry Companies: Three Kinds, and Which One You’d Be

Search for “teledentistry companies” and the first results are services that sell dental visits.

1. Virtual dental services. Companies such as The TeleDentists and Teledentistry.com sell virtual dental visits to patients and, in some cases, employers and health plans. Their customer is the patient or the payer, and the dentist usually hasn’t seen the patient before.
2. Platforms that practices license. MouthWatch sells TeleDent to dental teams, and Teledentix sells its own platform. The practice’s own dentists see their own patients through it.
3. Teledentistry inside other dental software. Integrations and features within systems a practice already runs. One example on the record: MouthWatch announced a TeleDent integration with Open Dental in February 2022 (Orthodontic Products). Aligner and orthodontic remote-monitoring apps sit here too; our guide to orthodontic remote-monitoring software covers that corner.

Which kind you’re building decides almost everything else. A virtual service needs dentist credentialing across states, a payment flow and a referral path back to local practices. A practice platform needs the practice’s branding, its schedule and a write-back into its PMS. A feature inside a PMS or engagement tool inherits that product’s patients and data, and the integration is the product.

What Teledentistry Software Has to Do: One Visit, Start to Finish

Back to the cracked molar. Here’s what the software did between 9 pm and the afternoon appointment, step by step, and where each step tends to break.

1. Intake, identity and consent. She answers a short triage form (which tooth, pain level, swelling, fever), confirms who she is, and signs or re-confirms a teledentistry consent. Breaks when the consent isn’t versioned, so nobody can say later which wording she agreed to.
2. Photos or video. She uploads three intraoral photos from her phone. Breaks when the app accepts a blurry, dark photo and the dentist can’t use it the next morning.
3. Review and triage. The dentist opens a queue at 7:30, sees her history next to the photos, and decides: in-person today. Breaks when the photos arrive without her medical history, allergies or last X-rays beside them.
4. Note and code. The dentist’s note is written and the visit is coded. The ADA’s CDT code set has two teledentistry codes, D9995 for live video and D9996 for store-and-forward, reported in addition to the other procedures for the visit, such as the evaluation. Payers decide whether and how they pay for each. California’s Medicaid dental program, for example, limits teledentistry in its managed care plans to diagnostic and preventive services (DHCS All Plan Letter 23-001, effective May 1, 2023), and commercial plans set their own rules. So the code records how care was delivered; it doesn’t promise payment. Breaks when the platform has no idea which code applies and leaves it to the front desk.
5. Prescription, if any. If she’d needed an antibiotic or pain control, it would go out here, inside the rules in the prescribing section below.
6. Write-back to the PMS. The note, the photos, the code and the outcome land in her chart in the practice’s PMS. This is the step most likely to break, and the one demos skip.
7. Follow-up. The afternoon appointment is booked, a reminder goes out, and the in-person dentist sees what the remote one saw. Reminder and recall logic is its own topic: see our guide to dental recall and reminder software.

The other common shape: a hygienist-led visit. In school, nursing-home and community programs, a hygienist or assistant is with the patient, takes the photos and X-rays, and a dentist reviews them remotely. State supervision rules decide who may do what: Texas’s proposed rule would let a dentist delegate to and supervise up to five non-dentist health professionals at once through teledentistry, and would let anyone provide photos or digital images to a Texas-licensed dentist or hygienist for screening, assessment or examination (proposed 22 TAC §108.16(e)).

For the software, that means a second user role at step 2 (the person capturing on site), a record of who was supervising, and the patient told that part of the visit was delegated.

That’s where I’d put the engineering time: steps 2 and 6. A great video experience with a broken write-back gives the practice a second chart to keep, and practices stop using a second chart.

Store-and-Forward Photos Are the Hard Engineering Problem

A live video call fails loudly: the patient sees a frozen screen and calls the office. A bad photo fails quietly. It uploads fine, sits in a queue overnight, and the dentist finds out at 7:30 am that it shows a thumb and half a tongue.

Here’s what the image side of a teledentistry platform needs:

• Guided capture on the patient’s own phone. Show which view to take (front, left, right, the problem tooth), check for blur and darkness before upload, and ask for a retake on the spot. That check costs the patient a few seconds and saves the dentist a callback.
• Uploads that survive weak connections. Resumable uploads and a sensible size limit per image, because the patient is on a phone, not office Wi-Fi.
• Every image tied to a patient, a date and, where known, a tooth. Without that metadata, images can’t be compared next month or filed correctly in the chart.
• Storage, retention and an access log. Photos are patient records. Encrypt them, keep them as long as your state’s record-retention rules require, and log who opened each one.
• Where state rules require it, a separate consent before images go to anyone else. Texas’s proposed teledentistry rule would require “explicit patient consent to forward patient identifiable information to a third party” (Texas State Board of Dental Examiners, proposed 22 TAC §108.16, 2025).

Intraoral photos are the easy end of dental imaging. X-rays, CBCT scans and the DICOM format bring their own storage and viewing problems, which our guide to cloud dental imaging and DICOM covers. If you plan to run AI over the photos, the triage logic, the evaluation, and the clinician sign-off are a separate build.

Prescribing Through Teledentistry: What the Software Must Allow and Block

Virtual dental services tend to be careful here. Some, such as Teledentistry.com, say on their own sites that they prescribe non-controlled medications only. That’s a business choice layered on top of the law, and your software needs to know both.

The baseline is the in-person standard. Texas’s proposed rule puts it plainly: a prescription issued through teledentistry would be judged “by the same standards that would apply to the issuance of the prescription in an in-person setting” (proposed 22 TAC §108.16(g)). Other states differ, so keep the rules in configuration a non-engineer can update.

Controlled substances follow DEA rules. The DEA and HHS have extended the pandemic-era telemedicine flexibilities four times. The current extension lets DEA-registered practitioners prescribe Schedule II-V controlled medications through audio-video telemedicine, and it runs from January 1 through December 31, 2026 (Fourth Temporary Extension, 90 FR 61301, published December 31, 2025).

The same notice explains the rule underneath: under the Ryan Haight Act, a practitioner may prescribe a controlled substance remotely only after at least one in-person medical evaluation of that patient, unless an exception such as these flexibilities applies, so an established patient the dentist has already examined in the office is a different case from a new one. Electronic prescribing of a controlled substance also has to meet the DEA’s EPCS requirements (21 CFR Part 1311).

What the software does with that:

• Route non-controlled prescriptions through an e-prescribing integration from the visit screen. We’ve built DoseSpot e-prescribing integrations; see DoseSpot e-prescribing and our page on e-prescription software development.
• Gate controlled-substance prescribing behind a rule check: is the visit audio-video, is the prescriber DEA-registered, is the current federal window in force, does the state allow it, and does the practice’s own policy allow it.
• Record the prescription in the visit note and write it back to the PMS with the rest of the visit.

What’s changing next. The fourth extension ends on December 31, 2026. The permanent rule is still pending: the DEA proposed a Special Registration for Telemedicine on January 17, 2025, as the same Federal Register notice records. Build the controlled-substance check as a dated rule you can switch, so a federal change is a configuration update you can ship the same day.

State Rules and HIPAA Turn Into Product Requirements

The consent screen is where most of the law lives in a teledentistry product. Two layers apply: the state dental board, and HIPAA.

State dental boards. Each state sets its own teledentistry rules, and they’re getting more specific. Texas’s proposed rule, written under House Bill 1700 (2025), is a good example of how detailed they can be.

It would require licensees to confirm the patient’s identity, verify the health history, disclose when a hygienist or assistant is delivering part of the service, and get informed consent covering the risks of electronic communication, the potential for a breach of confidentiality, the chance the connection fails, and the types of activities teledentistry is used for. It would also require notice of how to file a complaint with the board.

California sets requirements through its Medicaid dental program instead: providers must tell the patient about teledentistry before the first teledental service, get verbal or written consent and document it in the dental record, and the patient must still be able to get in-person care or help arranging a referral (DHCS All Plan Letter 23-001, April 26, 2023). Check your own state dental board, and your payers, before launch and again each year.

HIPAA. During the COVID-19 public health emergency, the HHS Office for Civil Rights relaxed enforcement for telehealth tools. That relief ended: the transition period closed on August 9, 2023 (HHS OCR). Today the normal rules apply in full. Any vendor that creates, receives, maintains or transmits patient information on the practice’s behalf is a business associate (45 CFR 160.103), so the video provider, the image store, the messaging service and the platform itself each need a BAA. More on the architecture side in our guide to HIPAA-compliant telehealth software.

Here’s how those rules turn into features:

Getting the Visit Into the PMS Chart

A visit that never reaches the chart didn’t happen, as far as the next dentist who opens that chart is concerned. So the write-back is a clinical requirement.

What a teledentistry visit should write back:

• the appointment or visit record, with its status
• the clinical note
• the procedure codes for the visit, including D9995 or D9996
• the photos and any X-rays, filed as documents or images
• any prescription
• the follow-up appointment, if one was booked

Whether you can write each of those depends on the PMS. Each vendor sets its own access route and its own list of what a third party may write.

That page lays out the route, the write list and the fees for each system. For PMSs that run on a server in the office, such as desktop Dentrix and Eaglesoft, the integration also needs a local service at each office, which we build.

Our delivered PMS write-back is on Open Dental: for a multi-location family dentistry practice running Open Dental, we connected the PMS to a clearinghouse and wrote verified insurance benefits back into its fields. Teledentistry write-back for any PMS, Open Dental included, is something we build to that vendor’s route.

For Open Dental’s API in depth, including its access tiers and events, see our separate guide.

Ten Questions to Ask a Teledentistry Software Vendor

Most demos show the video call. Ask about everything else; each question below comes with what a good answer sounds like.

1. Will you sign a BAA, and who are your subprocessors? A good answer names the video, storage and messaging providers and confirms a BAA with each.
2. Where does patient data live, and can we export all of it? You want a clear answer on hosting, and a full export of notes, images and consent records in a usable format if you leave.
3. Which PMS do you write back to, which objects, and through which vendor route? “We integrate with Dentrix” isn’t an answer. A note, an image and a code are three different writes.
4. How do you handle D9995 and D9996? The platform should know which applies to each visit and carry it into the write-back.
5. Can consent wording differ by state, and do you store which version each patient signed? If consent is one hard-coded screen, every state rule change becomes a support ticket.
6. How do you confirm the patient’s identity at each visit? Look for a check at the start of every visit, not only at sign-up, and a record of how identity was confirmed.
7. What happens when a patient uploads a blurry photo on a slow phone? Look for capture guidance and quality checks before upload.
8. How does prescribing work, and what’s your controlled-substance policy? Ask how they’ll handle the end of the federal telemedicine window on December 31, 2026.
9. Do you record visits, and if so, is recording a separate patient choice? A good answer: recording is off unless the practice turns it on, the patient opts in separately, and recordings follow the same retention and access rules as other records.
10. When a PMS vendor changes its API, who fixes the integration, and how fast? You want a named owner, monitoring of the vendor’s changes, and a stated response time in the contract.

When to Build Teledentistry Software Instead

We’ve built DoseSpot e-prescribing integrations, and our production PMS write-back runs on Open Dental, where we wrote verified insurance benefits back into the PMS for a multi-location family dentistry practice running Open Dental.

If no platform fits the visit you’ve designed, we build teledentistry software for dental product companies and DSOs: the consent and identity flow, store-and-forward capture, the dentist’s review queue, e-prescribing, and the write-back to each PMS through that vendor’s route. Our telehealth app development work sits behind the video side (outside dental, one telehealth app’s video sessions connected 80% faster after our video migration).

Discovery takes 6 weeks and ends with a clickable prototype and a fixed-price scope. We build in 2-4 week sprints, we sign a BAA with our clients, and you own the code and the data. More on how we scope dental products on our dental software development page.

For dental products that also need medical EHR data, ConnectHealth runs that side. That comes up when a teledentistry visit needs a patient’s medical history from a health system’s EHR, for example, in a hospital dental clinic or a community health center. ConnectHealth is our integration platform, and you run it yourself.

• Medical EHR connections: FHIR (the standard API for health records) read and write to Epic and athenahealth, subject to each EHR’s own app approval.
• In your own cloud: ConnectHealth deploys into your own cloud environment.

Prefer not to run it yourself? We build your product’s EHR connection on ConnectHealth for you. See ConnectHealth for Epic and athenahealth.