Most dental software still asks the dentist to log every finding three times — once in the case note, once by clicking through a dropdown to shade the chart, and a third time so the front desk has a billing line to charge against. The fields look slightly different each time, the wording drifts, and at the end of the day someone reconciles. The cost isn't just minutes per visit; it's the silent gap between what the dentist actually did, what the chart shows, and what the patient was billed for.
Oralstack inverts that flow. The dentist types the case note the way they already speak it — “46MOD filling A3 CR done, 47MO done, fluoride done, SAP done” — and the system parses the prose into two structured outputs at the same time: chart entries that shade the odontogram on save, and billing line items the front desk can charge. This article walks through what the parser actually recognises, how it handles ambiguity, and where the dentist still gets the last word.
The case note is the input, not a side effect
In a form-led PMS, the case note is documentation the dentist writes afterthe clinical work is captured in dropdowns. In a parser-led PMS, the case note is the input — the chart and the bill are derived from it. That ordering matters because the dentist already writes in domain shorthand: tooth numbers in FDI, surfaces in single letters, procedures in abbreviations the profession has used for fifty years. Asking them to re-enter the same information through a dropdown is the part of charting software that feels worst, and it's the part that introduces the most drift.
A typical Oralstack case note for a single visit might look like this:
- SAP done
- Fluoride done
- Etch · bond · sectional matrix
- 46MOD filling A3 CR done
- 47MO filling A3 CR done
Five lines, written in the order they happened. The parser reads it and produces two structured outputs.
What the parser recognises
The chart side covers the standard vocabulary a Singapore dentist actually writes. Tooth numbers in FDI (11–18, 21–28, 31–38, 41–48). Surfaces as single letters (M, D, B, L, O — with P normalised to L and I normalised to O for incisal). Conditions written either in full or as the common abbreviations: RCT for root canal, exo for extraction, SRP for scaling and root planing, GIC or Fuji II / Fuji IX for glass ionomer, fmc for full metal crown, NCCL for non-carious cervical lesion, SSCfor stainless steel crown. Status follows the wording — “done” or “completed” produces a completed entry; “planned” or “tx plan” produces a planned entry; watch / monitor / KIV all map to a watch finding.
The billing side maps the same prose into Singapore service codes — SVC009 for exam and consultation, SVC093 for combined scaling and polishing, SVC087 for fluoride application, SVC121 for tooth-coloured filling (complex), and so on. Every billing match links back to the source phrase in the case note, so the front desk can see exactly which sentence produced which line.
Tier inference
Singapore patients pay one of several rates: full Private, CHAS Blue (lower-income subsidy), CHAS Orange (middle-income subsidy), Pioneer Generation (≥1949 birth cohort), or Merdeka Generation (1950–59 birth cohort). The right rate depends on the patient's eligibility profile, not the procedure. Oralstack reads the patient's tier from their record and substitutes the correct schedule before showing the dentist the matched lines. The dentist sees “Inferred tier: Private” (or whichever applies) at the top of the billing matches block, with one click to override if eligibility has changed since the last visit.
This matters because in a busy clinic, the question that gets asked at the desk — was this patient on CHAS Blue or Orange last month?— has a real answer in the eligibility record that the parser already consulted. The front desk doesn't look it up; they confirm.
Two structured outputs from one prose input
For the case note above, the parser produces:
Chart matches (2)
- #46 MOD · Filling (Composite) · status: completed — source phrase “46MOD filling A3 CR”
- #47 MO · Filling (Composite) · status: completed — source phrase “47MO filling A3 CR done”
Billing matches (5)
- SVC009 · Exam and consultation
- SVC093 · Scaling and polishing
- SVC087 · Fluoride application
- SVC121 · Tooth-coloured filling (complex) · #46 MOD
- SVC121 · Tooth-coloured filling (complex) · #47 MO
Both outputs are visible in the same panel as the case note. Nothing is saved silently — the dentist sees what was matched, confirms or edits, and saves. On save, the chart shades and the billing draft is ready for front-desk review at discharge.
Confidence, sections, and ambiguity
Every parsed entry returns a confidence score (low, medium, or high) and a section tag (charting, treatment, plan, OHI, prescription, follow-up, admin). High-confidence matches are the ones the parser will save without prompting — “46MOD filling done” is unambiguous in form, surface, and procedure. Lower-confidence matches surface for confirmation: a phrase like “adv exo 38” near a treatment-plan section header is parsed as extraction plannedon tooth 38, not as a completed extraction. A bare reference like “tooth 36” with no condition attached doesn't produce an entry at all — it's correctly read as a reference, not a finding.
Section context is what makes this work. The same word can mean different things in different parts of the note. “Watch” under a treatment heading is a watch-finding; “watch” in a follow-up section is a recall hint. The parser classifies the section first, then matches conditions in that context. Negated phrases (“no caries”, “no mobility”) are recognised and excluded.
What this changes operationally
Three things shift when the case note becomes the input:
- Single source of truth. The chart and the bill are projections of the case note. Fix the case note, both update. There is no end-of-day reconciliation step where a missing line item is hunted down — the line item came from the note itself.
- Same-day-bill rate goes up.The discharge moment is faster because the billing draft is ready before the patient stands up. The front desk reviews and confirms; they don't re-key. (See Same-day billing for dental clinics for the math on why this matters for a 3-chair practice.)
- Dentist owns clinical accuracy; system owns coding. The dentist writes what they did, in the words they always have. The parser handles the boring part — mapping prose to codes, splitting into chart and billing, applying the right tier rate. The dentist gets the last word on every matched entry.
Limits and the cases where the dentist still types more
The parser is not a clinical AI; it's pattern-matching with section context and a carefully curated vocabulary. It handles the high-frequency procedures and abbreviations that make up the bulk of a general-practice day. Three areas still benefit from explicit dentist input:
- Truly novel phrasing.If the dentist writes a procedure description the parser hasn't seen before, the line shows as unmatched and the dentist can either edit the wording or add the entry by clicking through the palette.
- Multi-visit treatment plans. Plans that span future visits are parsed into plannedfindings on the chart — but the dentist confirms the visit assignment, since the system doesn't infer scheduling.
- Adjustments and write-offs.Bill adjustments still flow through the billing module's own audit-logged controls, not the case note. Discounts and courtesy adjustments shouldn't be inferred from prose.
What to do next
See the parser running in the charting workflow — the case-note panel shows live parsed matches as the prose is typed. For the broader discharge story, the billing workflow picks up where the parser leaves off: review, payment, receipt, recall, done.
For a worked example of what this looks like in a 3-chair Singapore practice, the DFI Synergy case study covers the full clinical-to-discharge flow.