Dental Practice Intake: Private AI for Patient Processing and Insurance Verification

The practice runs five chairs across two floors in central Bangkok, with six dentists rotating through morning and afternoon blocks. On a busy day, over a hundred patients come through the front desk. Each one arrives with some combination of a national ID card, an insurance booklet, a referral letter, previous x-rays, and a medical history form filled out on a clipboard in the lobby.

The front desk staff of three handled all of this manually. They typed patient details into the practice management system, called insurance companies to verify coverage, flagged contraindications from the medical history, and matched each patient to the correct dentist and treatment room.

On a good day, intake took about fifteen minutes per patient. On a bad day, with a new patient carrying a thick insurance packet and an incomplete medical history, it could take thirty. Two or three slow intakes in a row created a cascade that pushed the entire morning schedule back.

The bottleneck was not the dentists. The chairs ran efficiently once patients were in them. The problem was getting patients from the waiting room into the right chair with verified insurance and a complete file.

The practice needed a private system because the data involved (patient medical histories, national ID numbers, insurance policy details) could not be sent to a third-party cloud API. PDPA compliance was not optional.

The system runs on a server in the practice's back office, behind the same network that serves the practice management software. It connects to three input surfaces: a document scanner at the front desk, an email inbox where patients send forms ahead of their visit, and a tablet in the waiting room for digital medical history.

When paperwork arrives through any of those paths, the OpenClaw agent picks it up. Scanned documents go through OCR, emailed PDFs are parsed directly, and the digital form submits structured data. All three paths converge into the same pipeline: extract patient identity, match against existing records, parse the medical history for relevant flags, and pull insurance details.

Insurance verification was the single most time-consuming manual step. The old process involved calling the insurer, reading a policy number over the phone, and waiting for confirmation. The new system queries insurer portals directly where APIs exist, and navigates web portals programmatically where they don't. The result is a coverage summary attached to the patient record before the dentist opens the chart.

Medical history parsing flags three things: medication interactions with common dental anesthetics, conditions that affect treatment planning (blood thinners, diabetes, cardiac conditions), and allergies. The flagging logic is deterministic, matching against a reference table maintained by the clinical director. The language model handles extraction from unstructured text, but the rules are explicit code.

Patient routing uses the appointment schedule, dentist specialization, treatment type, and chair availability. When intake is complete, the system assigns a chair and notifies the dental assistant. The patient's name appears on the chairside display with their file ready.

The morning starts with a queue. Patients who submitted forms by email or Line the night before already have partial records assembled. The front desk sees a list: name, appointment time, intake status. Green means complete and verified. Yellow means a document is missing or the insurer's portal was unreachable. Red means a new patient with no prior record.

When a patient arrives and hands over their ID and insurance booklet, the front desk drops them on the scanner. The system matches the ID to an existing record or creates a new one, extracts the insurance policy number, and starts the verification query. What used to be fifteen minutes of typing, calling, and cross-referencing is a scan, a glance, and a confirmation.

For returning patients, the system pulls the existing record, checks whether insurance has changed since the last visit, and verifies current coverage automatically.

Clinical flags work in the background. A patient on warfarin who filled out their medical history on the tablet gets a flag attached to their chart before the dentist opens it. When something goes wrong (an unreadable scan, an insurer portal that is down, an ambiguous medication name), it gets flagged for human review rather than processed with low confidence.

Average time from arrival to chair dropped from twenty-two minutes to under ten. The cascade effect of slow intakes disappeared because the system processes documents in parallel while the front desk handles in-person interactions.

Insurance verification, which previously took six to eight minutes per patient and required a phone call, now completes in under a minute for major Thai insurers. For international insurers with slower portals, the query starts automatically when documents are scanned rather than when the front desk gets to them in the queue.

The three front desk staff handle peak volumes that previously overwhelmed four. They spend less time on data entry and phone calls and more time on greeting patients, handling scheduling changes, and answering questions. The practice did not reduce headcount. It stopped needing to increase it.

Clinical flag accuracy is tracked monthly. In the first six months, the system flagged 340 medication interactions and allergy alerts with a false positive rate under 2%. Data stays on the practice's server, and patient records never pass through an external API, which simplifies PDPA compliance.

The system is built on OpenClaw, running on a single server in the practice's back office. The server connects to the local network with no inbound internet exposure. Outbound connections are limited to insurer verification portals and the practice's email provider.

Document processing uses a local OCR pipeline for scanned images. Thai and English text are extracted and passed to a structured parser that identifies fields: patient name, date of birth, national ID number, policy number, medication list. The parser combines regex patterns for well-formatted documents with language model extraction for handwritten or inconsistent forms.

Insurance verification is modular. Each insurer has its own adapter: some use REST APIs, some use headless browser automation. Adding a new insurer means writing a new adapter, not modifying the core system. Verification results are cached so repeat visits within the same coverage period do not re-query.

The medical history flagging system maintains a reference table of approximately 200 dental-relevant contraindications, maintained by the clinical director and versioned in the system. OpenClaw's plugin architecture registers each component as a typed tool, and the cron scheduler runs nightly reconciliation: unmatched insurance queries are retried, incomplete records are flagged for morning follow-up, and the next day's appointment list is pre-processed.