Voice Perio Charting: How It Works, Where It Breaks, and What to Ask Before You Buy

Periodontal charting has a constraint the rest of the chart does not: the data only exists while the probe is in the pocket. That is what makes it a candidate for voice capture, and also what makes voice capture hard to evaluate. This is an explanation of how voice capture works for perio specifically, where it fails, and the handful of questions that separate a tool that files a real perio exam from one that produces text containing numbers. It should be useful whichever vendor you end up choosing.

Why perio has to be captured chairside

Every other note can be written after the patient leaves. Perio cannot, because the values are gone the moment the probe comes out.

That produces three options, and most practices rotate through all of them:

Two people. The hygienist probes and calls values; a second person sits at the keyboard and types. This works, which is why it persists. It also means pulling an assistant out of another operatory for a twenty-minute stretch, several times a day.

Gloves on the keyboard. The hygienist probes a quadrant, degloves or fumbles with a barrier-wrapped keyboard, enters values, regloves, continues. Infection control gets creative, and the appointment stretches.

Read back from memory. Probe the whole mouth, then reconstruct it at the end. This is where the data quietly stops being real — a full-mouth chart is up to 192 probing depths across six sites per tooth, before recession, bleeding points, mobility, furcation, and suppuration. Nobody holds that.

Voice capture exists to remove the second person without introducing either of the other two failure modes.

How voice capture actually works

The clinician wears or works near a microphone. As they probe, they speak values in the sequence their PMS expects — typically a buccal sweep across the arch, then a lingual sweep back. Software transcribes the speech, maps each number to a tooth and a site, and holds the exam in a review state until the provider confirms it.

The mapping is the interesting part. When the hygienist says “three,” that number is meaningless on its own; the system has to know it is the fourth value in the current sweep, which makes it tooth 14 mesio-buccal. So the system is tracking a position, and the question to put to a vendor is what happens when that position is wrong. Ask how the clinician corrects a value, moves to a different tooth, or marks a tooth as missing without touching a keyboard, and ask to see each of those done live. If a demo only ever shows numbers spoken in perfect order with no corrections, you have seen the happy path, not the product.

Where it breaks

Acoustics. The operatory is loud in exactly the wrong frequencies. High-speed suction, the ultrasonic scaler, the compressor cycling, a conversation at the next chair, and music. Masks muffle consonants. Ask any vendor how the system behaves with suction running, and insist on hearing it rather than being told.

Numbers that sound like other numbers. This is the characteristic perio failure. Two and three collide. Four and five collide. Seven and eleven collide when spoken fast. “Six” and “sticks” collide. Depths cluster in a narrow range, so there is little contextual signal to disambiguate from — unlike ordinary dictation, where the surrounding sentence rescues a misheard word. A 7 recorded as a 2 is not a typo; it is a treatment decision.

Cadence. Six sites per tooth implies a rhythm, and the system is following that rhythm to know where it is. Pause too long and it may or may not hold position. Speak two values in one breath and they may merge. Skip a tooth without saying so and every subsequent value in the sweep lands on the wrong tooth — the most damaging of these failures, because it is silent and it corrupts everything downstream of the skip.

That last point is why the review screen deserves as much of your attention as the recognition engine. The question is not whether the software ever misses; it is whether a miss is obvious to a human in five seconds. It is worth knowing what the research on AI documentation has actually measured here. One evaluation published in JMIR Medical Informatics generated 7,545 AI clinical notes and formally assessed 356 of them, finding omissions in 18%, hallucinations in 11.5%, and accidental inclusions in 9.3% — in that study, omissions ran about 1.6 times as common as hallucinations. It is a general clinical-documentation study rather than a perio-specific one, so it does not tell you how any perio product performs. What it does justify is a question: ask each vendor to show you what an unrecorded site looks like on the review screen, and satisfy yourself that a gap is at least as loud as a wrong value.

What “writes into the PMS” means for perio

This phrase does more concealing than any other in the category, and for perio there is a clean test.

A real perio exam stores each probing depth against a specific tooth and site in the PMS’s own periodontal tables, with an exam date and an attributed provider. It appears in the perio chart module. It graphs. It sits alongside prior exams for comparison. Hygiene recall logic and periodontal case presentation can read it.

A note containing numbers is free text. A human can read it. Nothing else can. The perio chart module stays empty.

Both can be described as “writes into the PMS.” Only one is a perio exam. When you evaluate, do not accept a screenshot of a note — ask to see the values populate the native perio chart, and ask which provider the exam is attributed to. To make this concrete: Intake.Dental writes a new perio exam with probe values into Dentrix Ascend via exam create/update plus probes, and into Open Dental attributed with ProvNum, and can produce a perio chart PDF; the two integrations are covered separately, for Open Dental and for Dentrix Ascend. Ask any vendor for the same level of specificity about each PMS you run.

Attribution also differs by system and by record type, and it is worth asking about separately. Ascend files against a real provider field. An Open Dental commlog has no provider field at all — Intake.Dental puts the provider’s name into the note body there, which is text rather than structured attribution. Ask each vendor which of those two things it is doing on each record type, because the answer determines whether the attribution is something the PMS can act on or only something a human can read.

The built-in microphone question

Several PMSs ship their own perio voice input. Some voice perio tools require that channel to be handed over to them.

If yours does, it is a replacement rather than an addition: your team’s existing native voice workflow changes or stops, and you become dependent on one vendor for a capability you previously owned outright. It is not automatically wrong — building on the PMS’s own write path is a legitimate engineering choice and can produce a genuinely structured exam. But it should be a disclosed design decision, not a surprise. Ask: does this coexist with the built-in perio microphone, or replace it? And test the answer with a hygienist who uses the built-in feature today.

History read-back is a separate capability

Writing a new exam and reading old exams are different API operations, often on entirely different endpoints. A tool can competently file today’s exam and be unable to tell you what the pocket depths were six months ago. Neither capability implies the other, so ask about each one.

Intake.Dental is explicit that it does not read existing perio history back out of either Open Dental or Dentrix Ascend. Put the same question to every vendor on your list rather than inferring the answer from the fact that the write works. If your case presentation depends on showing a patient the trend line, confirm where that trend line comes from.

A short buyer’s checklist

  • Show me values landing in the native perio chart module, not in a note.
  • Which provider is the exam attributed to, and is that a structured field or text in the note body?
  • Does this coexist with the PMS’s built-in perio microphone, or replace it?
  • Can it read prior perio exams, or only write new ones?
  • Demo it with suction running and with a deliberately skipped tooth.
  • How does the review screen surface a missing site?
  • Is audio stored, and if so under what consent? Products differ: some hold audio only in memory and keep nothing; some keep a transcript for a short window so an interrupted session can be resumed; some record and store audio under a separate opt-in. Ask which applies to each feature, not to the product as a whole.
  • How does it connect to my PMS? On Open Dental, API access is served by the eConnector running on your own server. Open Dental also publishes trust tiers — Authorized (87), Authorized In Transition (11), Dangerous/Unknown (22), Not Currently Active (11), plus 14 Native Integrations — which flag direct database access and unwhitelisted plugins as Dangerous/Unknown. Check the list, and where a vendor is not on it, ask how it connects. (Intake.Dental, used as a worked example above, is not currently listed in any tier.)
  • On the Henry Schein One side, API Exchange vendors are required to hold SOC 2 Type II and use OAuth 2.0. Confirm that a vendor claiming a place in that program actually holds one.
  • Separately from any program: is a BAA signed, and is PHI encrypted at rest at the field level?

The gap between voice perio vendors is not in whether they can hear a number. It is in what happens to that number afterward — whether it lands in a structured exam against the right tooth and site, attributed to a provider the PMS recognises, and put in front of that provider to review before it is filed.