AI for Dental Labs: Turn Handwritten Rx Slips Into Cases

Yes. A vision-capable AI model such as ChatGPT, Claude or Gemini can read many handwritten Rx slips and dentist emails and turn them into structured case fields that an automation then creates in your lab system. It will make mistakes, so every case needs a staff check of tooth numbers, shade, material and due date before it is released.

Lab-automation vendors dominate what you will find online, and they quote accuracy figures that tell you nothing about your own dentists' handwriting. The other route is to build a small intake step yourself, measure it on your own past slips, and log every error until you know what it can and cannot be trusted with.

Follow me on Instagram@sagnikteaches

What the pipeline looks like from slip to case

The flow has five stages, and the AI is only one of them.

Connect on LinkedInSagnik Bhattacharya

1. Capture. A paper slip arrives with an impression or a model; a staff member photographs or scans it at the bench. A dentist email arrives with a PDF or a photo attached. Both land in one folder or one inbox.
2. Extract. A vision model reads the image or text and returns the fields as structured data, with a confidence note for anything unclear.
3. Check. A technician sees the original beside the extracted fields, corrects anything wrong, and approves.
4. Create. Approved data is pushed into your lab management system by import, email-in or API, or lands in a spreadsheet row for pasting.
5. Log. Each correction is recorded, so you can see what the model gets wrong and how often.

Stage 3 is not optional. The tutorial on AI mistakes in dental practices describes how over-automation causes harm in dentistry; the same applies to the lab, where an unnoticed misread becomes a remake.

Subscribe on YouTube@sagnikteaches

The fields to extract and where handwriting fails

An Rx slip is a short form with a predictable set of fields, which is why extraction works at all. Different dentists' handwriting breaks it in different places, so list the fields and rank them by the cost of a mistake.

The tooth-number row deserves a second look. Dentists record tooth positions in more than one notation system, and a slip may mix them or leave the system unstated. The lower left first molar is 36 in the two-digit FDI system and 19 in Universal numbering, while a bare "8" could be an upper central incisor in Universal numbering or the eighth tooth from the midline in Palmer notation, where a small bracket marks the quadrant and is easily lost in a poor scan. A model can read the digits perfectly and still land on the wrong tooth. Make your extraction prompt return the notation as the dentist wrote it, plus a field for the system, and set a rule that an unstated system is flagged for a human.

Choosing the model and the tools

You need three things: a model that reads images, a way to run it on each new slip, and somewhere to put the result. For the model, ChatGPT, Claude and Gemini all accept image input, and in the Claude apps a PDF can run to 1,000 pages, with charts and layout read only up to 100 pages. Use a chat window for the first test, with patient names covered, and an API or a business plan for production; API use is billed separately from chat subscriptions such as ChatGPT Plus or Claude Pro. Business plans from these vendors state that they do not train on business content by default; confirm that on the vendor's page before sending patient information.

For the plumbing, a no-code automation tool such as Zapier or Make can watch an inbox or folder, send the file to a model, and write a row in a spreadsheet or call your lab system. Zapier's free plan will not run this flow: it allows only two-step Zaps (one trigger, one action) and leaves out the AI by Zapier step, so budget for a paid plan; Professional starts at $19.99 a month billed annually for 750 tasks. Check that the AI step you choose accepts an image or PDF attachment, because not every built-in AI step does; if it does not, a short script or a direct call to the model vendor's API will. A general comparison of when to use a vision model and when to use traditional OCR is in the tutorial on AI document extraction versus traditional OCR, and the principles of reading handwriting into a sheet are in how to turn handwritten forms into spreadsheet data with AI.

Some lab management systems already offer their own scanning or intake feature. Ask your vendor what it does, what it costs and where the data goes, then compare it with your own test results rather than the brochure. The tutorial on what to check before hiring an AI automation agency lists questions that apply to a vendor as well.

A traditional OCR service is the other named option. Amazon Textract detects typed and handwritten text and pulls out form fields and tables, and Google Cloud's Document AI has a Form Parser for key-value fields; both are developer services, so they suit a lab with someone who can set up an API connection. Put whichever engine you shortlist through the same 60-slip test described below, because the scoring does not care which engine produced the fields.

The extraction prompt, with a sample output

A reliable extraction prompt does four things: it names the fields, asks for exactly what is written, requires a flag for uncertainty, and forbids guessing. Here is a version to start from.

You read dental laboratory prescription slips and emails.
Extract these fields as JSON: dentist_name, practice, account_no,
patient_ref, date_sent, date_needed, restoration_type, teeth,
tooth_notation_system, shade, material, enclosures, special_notes.
Rules:
- Copy what is written. Never guess or complete a missing value.
- If a value is missing or you are less than sure, set it to null
  and add the field name to "check_fields" with a short reason.
- Write dates as written, and add "date_format_unclear": true if day
  and month could be swapped.
- For teeth, return the numbers exactly as written; if the notation
  system is not stated, set tooth_notation_system to "unstated".
- Do not interpret clinical meaning.
Return only JSON.

Illustrative output for one slip, an imaginary example with no real patient: {"dentist_name": "Dr [surname]", "practice": "[practice name]", "account_no": "R-2041", "patient_ref": "J.M. / 4471", "date_sent": "12/03", "date_needed": "21/03", "date_format_unclear": true, "restoration_type": "crown", "teeth": ["36"], "tooth_notation_system": "unstated", "shade": "A3", "material": "zirconia", "enclosures": ["impression", "bite"], "special_notes": "light contact mesially", "check_fields": ["teeth: notation unstated", "shade: A3 or A2, last character unclear"]}. What a technician fixes: confirms the notation with the practice's usual convention, looks at the shade box on the original and settles A2 or A3, and confirms the date order from the sent date. Each of those flags is the system working, not failing: it knew what it did not know.

Dentist emails need a second prompt, because the information is in prose: "Please make a zirconia crown on the lower left six for Mrs [surname], shade A2, needed next Friday." Here the risks are relative dates ("next Friday") and missing fields. Tell the model to return the sent date of the email alongside the phrase, and to leave the computed date to your automation, which can work it out from the email's timestamp.

How to test accuracy on your own past slips

This is the step the vendor pages skip, and it is what turns a promising demo into a decision. You need 50 to 100 past cases for which you already hold the correct, verified record, and a mix of handwriting. Aim to include your three or four worst writers on purpose.

1. Build the answer key. For each slip, take the field values from the verified case in your system. Do this before you run the model, so you do not mark it against its own answers.
2. Remove patient identifiers if you can. Cover the patient name or use cases that are long closed, and check your agreements. If you must test with real data, use a business-grade service and delete the files after.
3. Run every slip through the prompt, with the same settings, and save the outputs.
4. Score field by field. Mark each field correct, wrong, or null-with-flag. A flagged null counts as safe, because a human will check it; a confident wrong value is the dangerous outcome.
5. Break results down by field and by dentist. An overall percentage hides that tooth numbers may be 96 per cent right while shade is 82.
6. Decide thresholds. For example: no confident-wrong values on tooth, shade or material in the sample; if there are any, change the prompt or keep that field fully manual.

A worked example with numbers (illustrative). A lab tests 60 slips, with 10 fields each, which is 600 field readings. The model returns 548 correct, 31 flagged for checking, and 21 confident-wrong. That is 91.3 per cent correct, 5.2 per cent safely flagged and 3.5 per cent confident-wrong. By field: the 21 confident-wrong readings split into 9 dates, 6 shades, 4 free-text notes, 2 tooth numbers. The lab reads that as: dates need the "format unclear" rule, shades need a mandatory human look at the original, and the two tooth errors came from one dentist whose 6 looks like 0, so that dentist's slips always go to a person. The headline 91 per cent is much less useful than that breakdown.

The check step on every case

A pre-filled form that a person confirms takes far less time than typing, and it keeps a human accountable for every case. Design the screen so the check is easy. Show the photo of the slip on one side and the extracted fields on the other, highlight the flagged fields, and make the four high-cost fields (teeth, shade, material, due date) require a click each, rather than a single "approve" button. If staff approve everything in two seconds, they are not checking.

Illustrative timing. Typing a case by hand takes about 3 minutes. Checking a pre-filled one takes about 1 minute, with another minute on the 15 per cent of cases that have a flag. For a lab handling 40 cases a day, hand entry is 120 minutes. The checked flow is 40 minutes plus about 6 cases times 1 minute for flags, so around 46 minutes. That saves roughly 74 minutes a day, or about 27 hours over 22 working days. The more valuable effect is that the data is captured at the bench in the same format every time.

What about the cost of the model? Anthropic's vision guide counts an image in 28-by-28-pixel patches: a 1,000 by 1,000 pixel image is 1,296 tokens, and on the newest models a large phone photo is scaled down to at most 4,784 tokens. Take a full-size photo plus about 500 tokens of prompt, so roughly 5,300 input tokens, and about 500 output tokens. At the Claude Sonnet list price of $2 per million input tokens and $10 per million output tokens, that is about $0.011 plus $0.005, or under two cents per slip. At 880 slips a month it comes to about $14, plus the automation tool's plan. Cropping each photo to the slip at about 1,000 pixels a side cuts the input to roughly a third, as long as the handwriting stays legible. Other vendors count image tokens differently, so measure a batch of ten before you trust the estimate.

Getting the approved data into a lab system with no API

If your lab software has no public connection, that does not stop the project; it changes stage four. Three routes work, in rising order of effort. First, the checked data lands in a spreadsheet with one row per case and the columns in the same order as your system's entry screen, so a technician pastes values across in seconds instead of typing them. Second, if the system can import a CSV file for new cases, the same sheet exports to that format; test the import with five dummy cases, because import tools can be fussy about date formats and code lists. Third, if the system accepts cases by email or offers a webhook, the automation sends the approved record straight in.

Here is a small example. A lab's system imports CSV with columns for account, patient reference, product code, teeth, shade and due date. The model returns "zirconia crown" but the system wants product code ZC-01. Add a lookup table in the spreadsheet that maps the model's wording to your product codes, and make any unmatched text a flag rather than a guess. The lookup is also a place to catch abbreviations that dentists use and your staff know but the model does not. Keep the table under version control, meaning one named person edits it and dates each change, so a quiet edit cannot change how cases are priced.

The error log that makes the system better

Every correction a technician makes is data. Keep it in a spreadsheet with one row per correction, or have your check screen write it for you. An illustrative filled-in log looks like this:

Review the log weekly for the first month. Patterns show quickly: one dentist, one field, one kind of scan. Fix the cause (a better photo set-up, a prompt line, a manual rule for one dentist), then re-run last week's slips to see whether it helped. When a field has gone three months without a confident-wrong value across several hundred cases, you have evidence to speed its check; until then keep it as it is. Also log near misses where a technician catches a problem further down, in design or production, because those show what the check screen failed to flag.

Glare, bridges on one slip and other intake failures

• Bad photos. A slip photographed at an angle under a bench lamp, with glare across the shade box. OpenAI's vision guide itself warns that rotated or upside-down text can be misread and advises enlarging small text, and Anthropic's notes that a downsized image can lose legibility. Fix it with a fixed scanning stand, a plain background and even light; this often helps more than changing models.
• Multiple cases on one slip. A bridge and two crowns on the same form. Ask for an array of items per slip, and make the check screen show each.
• Silent drift. A vendor updates a model and results change. Re-run your 60-slip test whenever you change model or prompt, and every quarter regardless.
• Ignoring the digital cases. Some dentists send a scan with a typed prescription. That is an easier job (text, not handwriting) and often best handled by a different, simpler rule.
• Privacy by accident. Slips photographed on a personal phone and stored in a camera roll. Set one capture route, with images deleted after intake.

On privacy generally: patient details belong to the dentist's patient, and the dentist's contract with you may say what you may do with them. Ask clients, in writing, whether a service that reads slips is acceptable, and keep a record of what they said. A business plan with a data agreement and training off is the minimum, and a vendor that offers a region or retention setting is better still.

A six-week rollout for a small lab

Weeks one and two: build the answer key from 60 past slips, write the extraction prompt and score the results. Week three: fix the prompt and set the manual rules per field and per dentist. Week four: run in shadow mode, where staff enter cases as normal while the system extracts in parallel and the log compares the two. Week five: switch to checked intake for two or three dentists with the cleanest handwriting. Week six: add the rest, one at a time, and start the weekly log review. At each stage, a staff member owns the decision to continue, pause or roll back.

If you would rather work through this with someone, mapping your own intake route and choosing the tools is what my AI implementation consultation covers. Before then, take ten of last month's slips, run them through the prompt above in a business-grade chat window, and compare the output to the cases you already hold. Ten slips will tell you more than any vendor's brochure.

Questions dental lab owners ask about slip reading

How accurate is AI on handwritten Rx slips?

It varies by handwriting, scan quality and which fields you measure. Do not trust any vendor figure. Test 50 to 100 of your own past slips against the verified case record, score each field separately, and decide your threshold from that.

Can I skip the human check if accuracy is high?

Not for tooth numbers, shade, material and due date. A single wrong digit makes a restoration for the wrong tooth. A person confirming a pre-filled case takes seconds; remaking one costs far more. Relax checks only on low-risk fields, and only with evidence from your error log.

Do patient details on slips raise a privacy problem?

Yes. Slips carry patient names and sometimes dates of birth. Use a business-grade service with a data agreement, switch off training on your data, and ask your dental clients whether their contracts or patient notices restrict what a lab may send to outside services.

Will this work with my lab management software?

Possibly. Check whether yours offers CSV import, an API, an email-in feature or a webhook. If it offers none, the AI step can still produce a checked spreadsheet row that staff paste or import, which keeps the benefit without a direct connection.

Further reads

• Which Dental Front Desk Tasks Can AI Take Over? — The practice side of the same relationship, with what AI handles at the desk.
• How Dental Practices Use AI for Recalls and Appointment Reminders — How your dentist clients use AI for recalls, so you know their workflow.
• AI Readiness Checklist for Accountants, Solicitors, Consultants — A short readiness check before you automate any intake process.
• Dental Lab Quality Control Checklist and Remake Log With AI — Stage checklists for crowns, dentures and implant work, a remake log with cause codes, and a monthly AI prompt that finds repeat causes.
• Dental Lab Communication: AI Replies on Turnaround and Remakes — Draft status, turnaround and remake replies from your case data and policy sheet, with hand-off rules and tracking links for a dental lab.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Anthropic API pricing and vision docs, Claude upload limits help article, Anthropic and OpenAI articles on API billing, OpenAI vision guide, Gemini file upload help, Zapier pricing page, Amazon Textract and Google Document AI docs, and the dental notation overview on Wikipedia, checked 4 November 2026.