FDI, Universal, and Palmer: Why Clinical Dental AI Mislabels Teeth Across Charting Standards

A dental AI model that reads a bitewing and returns “distal caries, tooth 18” has told you one of two completely different things. Under Universal numbering that is the lower left second molar; under FDI notation it is the upper right third molar, opposite side and opposite arch.
Both readings are structurally valid, both survive a range check, and neither arrives with a flag declaring which one the model meant. This is one of the few AI failures in a dental stack that produces a confidently wrong, site-specific recommendation rather than an obvious error.
Eighteen of the 32 FDI permanent tooth codes also fall inside the Universal 1 to 32 range. Those tokens parse cleanly in both systems and mean different teeth, so a missing notation flag fails silently.
The reason this survives in production is that no single practice uses one notation end to end. The imaging vendor, the practice management system, and the referral letter in the patient's chart can each speak a different one, and the model sits downstream of all three.
Three Notations Coexist Inside One Practice
Tooth identity looks like a solved problem until you audit where the identifiers in your pipeline actually originate. What follows is the working detail on each convention, because the conversion bugs live in the differences, not in the definitions.
Universal Numbering (ADA)
The Universal system assigns permanent teeth 1 through 32 in a single continuous sweep, starting at the maxillary right third molar as number 1 and ending at the mandibular right third molar as number 32. Primary teeth get letters A through T on the same path.
It is the US default and it is what your practice management system, your claims, and your EOBs almost certainly carry. It is also the notation most likely to be assumed silently, because a bare integer under 33 looks like a valid Universal number no matter where it came from.
FDI Two-Digit Notation (ISO 3950)
FDI encodes the quadrant in the first digit — 1 for permanent upper right, 2 for upper left, 3 for lower left, 4 for lower right — and the position in the second, counting 1 through 8 outward from the midline. FDI 46 is the lower right first molar, the same tooth Universal calls 30.
Primary quadrants continue the same pattern with 5 through 8, so a primary upper right second molar is 55. FDI is the notation your European-manufactured sensor, CBCT software, and every peer-reviewed paper in the literature will hand you.
Palmer Notation
Palmer names a tooth with a digit 1 through 8, or a letter A through E for primary teeth, wrapped in a bracket glyph that indicates the quadrant. It is still standard in orthodontics and among UK-trained clinicians, which means it shows up in referral letters and surgical reports rather than in structured data.
Palmer notation stores the quadrant in a bracket glyph, not a character. PDF text extraction and OCR routinely drop that glyph, leaving a bare 1 to 8 with no arch or side attached.
Some documents substitute the ASCII convention — UR6, LL7 — which survives extraction cleanly. The ones that use the true glyph do not, and the degraded output is a digit that looks like a perfectly reasonable FDI position.
Here is how the three compare on the attributes that actually matter to a data pipeline rather than to a clinician at the chair.
| Attribute | Universal (ADA) | FDI / ISO 3950 | Palmer |
|---|---|---|---|
| Permanent teeth | 1 to 32, single sweep | 11 to 48, two digits | 1 to 8 per quadrant |
| Primary teeth | Letters A to T | 51 to 85 | Letters A to E per quadrant |
| Quadrant in the token | No, implied by position | Yes, first digit | Yes, in a bracket glyph |
| Supernumerary | 51 to 82, and AS to TS | No scheme in the base standard | No scheme |
| Typical source in your data | PMS, claims, EOBs | Imaging vendors, CBCT software, literature | Referral letters, surgical reports |
| Dominant failure mode | Assumed as the default for any bare integer | Reinterpreted as Universal below 33 | Quadrant stripped by OCR |
Why One Formula Cannot Convert Between Them
The most common implementation mistake is a single arithmetic expression that converts a Universal number to an FDI code. It works for a stretch of teeth, then inverts, because Universal sweeps in one direction while FDI counts outward from the midline in each quadrant independently.
The actual relationship requires four separate expressions, one per quadrant, and two of them run backwards relative to the other two:
- Quadrant 1, upper right. Universal 1 through 8 maps to FDI 18 down to 11. The FDI position is 9 minus the Universal number, so the sequence descends.
- Quadrant 2, upper left. Universal 9 through 16 maps to FDI 21 through 28. The FDI position is the Universal number minus 8, ascending.
- Quadrant 3, lower left. Universal 17 through 24 maps to FDI 38 down to 31. The position is 25 minus the Universal number, descending again.
- Quadrant 4, lower right. Universal 25 through 32 maps to FDI 41 through 48. The position is the Universal number minus 24, ascending.
Two inversions and four offsets mean there are six places where an off-by-one can hide, and the boundaries at 8/9, 16/17, and 24/25 are where they cluster. A mapper that is wrong by one at the 16/17 boundary does not return an error; it returns a tooth in the wrong arch.
Universal numbers run 1 to 32 in one continuous sweep; FDI counts 1 to 8 outward from the midline in each quadrant. The relationship reverses at every quadrant boundary, so no single linear formula converts them.
The Half That Fails Loudly And The Half That Does Not
Teams usually discover the notation problem, patch the obvious cases, and conclude the pipeline is safe. What they have actually built is a filter that catches slightly less than half the bad input.
The arithmetic that matters. FDI defines 32 permanent tokens: 11 to 18, 21 to 28, 31 to 38, and 41 to 48.
Eighteen of those — 11 to 18, 21 to 28, plus 31 and 32 — are also valid Universal numbers. The other fourteen fall outside the Universal range and throw, which is precisely why a low error rate in the logs reads as proof the parser handles mixed notation.
Consider what the silent 56% actually does. FDI 31, the lower left central incisor, is accepted as Universal 31, the lower right second molar — a contralateral swap across a different tooth type.
FDI 11, the upper right central incisor, becomes Universal 11, the upper left canine. Neither substitution produces a nonsensical result on a chart, which is exactly why a clinician reviewing a summary can sign off on it without noticing.
Where Notation Enters The Pipeline
Notation is not a property of your model. It is a property of every upstream system that hands you a tooth identifier, and each one deserves an explicit declaration:
- Imaging vendors and DICOM. Sensor and CBCT software typically stamp tooth identifiers using the manufacturer's locale default, which means European hardware ships FDI into a US practice by default. That default can change on a firmware or software upgrade.
- The practice management system. Open Dental stores the tooth on a procedure as a Universal string with primary teeth as letters, and Dentrix follows the same convention. If you are pulling through the Open Dental API, you are reading Universal unless something upstream rewrote it.
- Referral letters and scanned documents. These arrive as PDFs or images and go through OCR, which is where Palmer quadrant glyphs disappear. Any dental NLP extraction step is operating on already-degraded input.
- Interchange formats. There is no dedicated tooth resource in FHIR; oral health data generally lands in a bodySite element carrying SNOMED CT tooth concepts, which are notation-independent and therefore safe.
- Claims. The ADA claim form expects Universal numbers and letters in the tooth field, so whatever your internal representation is, it has to render correctly at that boundary or the claim is wrong on its face.
- The language model itself. Ask an LLM to summarize a chart and it will convert between notations fluently and without hesitation, including when it is wrong. Fluency is the delivery mechanism here, not the safeguard.
The pattern across all six is the same: notation is a fact about the source, not about the record. Attaching it at the source-system level, and versioning it, is the only way to survive a vendor changing a default without telling you.
Primary And Supernumerary Codes Break Naive Mappers
A mapper that covers permanent teeth 1 through 32 is a mapper that has not met a pediatric chart. Universal switches to a completely different alphabet for primary teeth while FDI simply continues numbering, so the two representations share no structure at all below the permanent dentition.
The supernumerary case is worse, because the ranges collide outright. Universal numbers supernumerary permanent teeth 51 through 82, and FDI numbers primary teeth 51 through 85.
Universal numbers supernumerary permanent teeth 51 to 82; FDI numbers primary teeth 51 to 85. In a pediatric chart the token 52 is either a supernumerary upper right molar or a primary lateral incisor.
There is no way to resolve that token from its value alone. Dentition state, patient age, and the declared source notation are the only signals that separate the two readings, and a mapper that guesses will guess consistently wrong for one whole population.
How To Store A Tooth Identifier
The fix is a data modeling decision, not a model quality decision. A bare tooth number should never exist anywhere in your system after ingest.
- Store a tuple, not a number. Every tooth reference carries the source system, the declared notation, the raw token exactly as received, and the canonical ID. The raw token is what lets you re-derive everything when you find a mapping bug six months later.
- Make notation non-nullable and reject unknowns. A default value is the bug. If a feed arrives without a declared notation, that record goes to a quarantine queue, not to inference.
- Pick a notation-independent canonical form. FDI works because the quadrant is explicit and primary dentition extends without a separate alphabet; SNOMED CT tooth concepts work better still because they carry no positional arithmetic at all. Render Universal only at the claims and UI boundary.
- Version the mapping table. A change to the conversion logic is a release event with the same blast radius as a model version change, and it belongs in the same pinning and rollback discipline you apply to Bedrock-hosted clinical models.
Store tooth identity as a tuple: source system, declared notation, raw token, and canonical ID. Make the notation field non-nullable at ingest and reject unknown values instead of defaulting to Universal.
This is the same discipline that keeps chart consolidation across practices from producing a merged record that is internally inconsistent. Once two sources with different notations have been flattened into one integer column, the information needed to un-flatten them is gone.
How Do You Know Your Mapping Is Right?
Notation bugs are cheap to test for and expensive to find in production, which makes them one of the better returns available in a clinical AI evaluation suite. Five checks cover nearly all of it:
- Round-trip the full identifier space. Convert canonical to each notation and back for all 32 permanent teeth, all 20 primary teeth, and the supernumerary codes. Any quadrant-boundary error fails this immediately.
- Assert rejection on ambiguous bare tokens. Feed the 18 collision values with no declared notation and assert the pipeline refuses them. A test that passes those through is testing the wrong behavior.
- Cross-check against the charted dentition. An assertion about a tooth that the PMS records as extracted or congenitally absent is the cheapest mismatch signal available, and it catches quadrant inversions with high sensitivity.
- Reconcile against image geometry. The region of interest on a radiograph implies a quadrant, and that implication should agree with the asserted tooth. This is a natural gate to build into AI radiograph analysis before any finding is written back.
- Run shadow mode against historical charts. Replay a month of real records, compare every mapped identifier against the PMS ground truth, and report per-quadrant mismatch counts. The acceptable number here is zero, not 99% agreement.
Round-trip every identifier: canonical to notation and back must be the identity across all 32 permanent, 20 primary, and supernumerary codes. Quadrant-boundary bugs fail this test immediately.
In production, the ongoing signal is distributional. Chart the histogram of asserted tooth IDs per source system and watch for a new cluster in the 11 to 18 band or an implausible spike in third-molar calls, both of which mean an upstream vendor changed a default — the same class of silent regression that model drift monitoring exists to catch.
What A Silent Off-By-One Costs
Run the arithmetic on your own volume rather than on a benchmark. At 900 tooth-specific claims a month and a 2% notation mismatch rate, that is 18 claims carrying the wrong tooth, each one generating a denial, a staff correction, and a resubmission.
The rework cost is the small part. The claim, the clinical note, the consent document, and the AI-assisted dental chart now disagree about which tooth was treated, and reconciling that after the fact is a records problem rather than a billing one.
Downstream, a mislabeled tooth propagates into treatment planning. A wrong-site recommendation that reaches AI implant planning or an endodontic referral is the failure category every state board disciplinary docket already has language for, which is why dental board rules on AI-assisted clinical decisions put the burden on the practice rather than the vendor.
Keep in mind that tooth-level findings are PHI in context, so the reconciliation store, the quarantine queue, and the audit log all sit inside the same BAA perimeter as the model itself. The mapping layer is not exempt from HIPAA-grade handling of clinical dental AI simply because it only moves integers around.
Frequently Asked Questions
What is the difference between FDI and Universal tooth numbering?
Universal assigns 1 to 32 in a single sweep from the upper right third molar. FDI uses two digits: quadrant 1 to 4, then position 1 to 8 counting outward from the midline. FDI 46 and Universal 30 are the same lower right first molar.
Which tooth numbering system should clinical AI use internally?
Use one notation-independent canonical form — FDI or SNOMED CT tooth concepts — and render Universal only at the claim and UI boundary. Storing the display notation as the source of truth is what creates drift.
How do you detect a tooth numbering mismatch before it reaches a patient?
Cross-check every AI-asserted tooth against the charted dentition, existing restorative history, and the radiograph region of interest. A call on an extracted or absent tooth is the cheapest mismatch signal you have.
Why is Palmer notation the hardest for AI pipelines to parse?
Palmer encodes quadrant in a bracket glyph rather than a character, so OCR and PDF extraction strip it. The surviving 1 to 8 digit carries no arch or side, and a defaulted quadrant is a coin flip on four options.
Do primary and supernumerary teeth break tooth number mapping?
Yes. Universal uses letters A to T for primary teeth and 51 to 82 for supernumerary permanent teeth, while FDI uses 51 to 85 for primary teeth. A mapper covering only permanent 1 to 32 mislabels pediatric charts.
How do you monitor tooth notation drift in production?
Chart the distribution of asserted tooth IDs per source system. A new cluster in the 11 to 18 band, or a spike in third-molar calls, means an upstream vendor changed its notation default on upgrade.
Get A Second Set Of Eyes On Your Charting Pipeline
If you are wiring a detection or charting model into a live practice and your ingest layer accepts a bare tooth number from more than one source, you already have this exposure whether or not it has surfaced yet. The 18 ambiguous tokens do not announce themselves.
NexV builds and operates HIPAA-grade clinical AI across imaging, practice management, and claims environments, and notation reconciliation is a fixed item in every deployment we run. Reach out for a working session and we will inventory the notation declared by each of your sources, build the round-trip validation suite against your own dentition data, and hand you a shadow-mode plan that quantifies your current mismatch rate before anything writes back to a chart. Start with our work on AI caries detection if you want to see how the same reconciliation gates apply to a specific finding type.