Patient Intake, End to End: A Build Breakdown for a Dental Practice

Most dental front offices lose 15 to 25 minutes per new patient to paperwork: handing over the clipboard, deciphering handwriting, retyping insurance details into the practice management system, scanning the ID, chasing missing signatures. Multiply that by five new patients a day and you've burned a full staff shift every week on data entry that no human actually needs to do.

Here's how we'd build the fix, end to end, for a typical two-doctor general practice running Dentrix or Open Dental. This isn't a war story — Catalyst is new and we don't invent client results. It's a transparent walkthrough of how the build goes, what decisions you have to make along the way, and where automation hits its limits.

Step 1: Map the current intake before touching any software#

Before writing a single line of automation, we sit with the front desk for half a day and watch. Not interview — watch. Because what the office manager describes and what actually happens are usually two different workflows.

A typical map for a dental practice looks like this: patient calls or books online, receptionist creates a stub record in the PMS, patient gets an email with a PDF intake packet, 40% fill it out ahead of time, 60% show up and do it on the clipboard, front desk scans completed forms and manually types medical history and insurance into the PMS, insurance gets verified by phone or portal, hygienist pulls the chart and re-reads everything because the data entry was rushed.

We document every handoff, every duplicated field, every place where a human is acting as a copy-paste machine. That map becomes the spec. If you skip this step, you automate the wrong thing.

Step 2: Replace the PDF with a structured digital form#

The clipboard goes first. We build a mobile-friendly intake form — usually in something like Jotform, Typeform, or a HIPAA-compliant builder like MagicForms or Formstack Healthcare — that the patient receives via SMS link the moment they book.

A few decisions to make here:

• HIPAA compliance is non-negotiable. That means a Business Associate Agreement with whatever form vendor you pick. Free tiers usually don't qualify. Budget $30 to $100/month.
• Conditional logic matters more than you'd think. A patient who marks "no medical conditions" shouldn't see 40 follow-up questions. A patient who marks "diabetes" should see three.
• Insurance card capture works best as a photo upload, not typed entry. Patients get the member ID wrong roughly a third of the time when they type it.

The form sends a friendly reminder 24 hours before the appointment if it hasn't been filled out. That alone tends to move completion from 40% to about 80% before the patient walks in.

Step 3: OCR the insurance card and ID#

This is where the build gets interesting. The photo of the insurance card goes to an OCR step — we typically use Google Document AI or AWS Textract for the raw extraction, then run the output through a small language model prompt to normalize it into structured fields: carrier name, member ID, group number, plan type.

Why two passes? Raw OCR gives you text. It doesn't know that "DELTA DENTAL PPO" and "Delta Dental of California" should map to the same carrier in your PMS. The LM pass handles that normalization and flags anything ambiguous for human review.

The ID photo gets the same treatment for address and date of birth, which we cross-check against what the patient typed. Mismatches get flagged. About 5 to 10% of submissions will need a human glance — usually because the photo is blurry or the patient typo'd their own birthday.

Step 4: Insurance eligibility check#

Once we have clean carrier and member data, the workflow hits an eligibility API. For dental specifically, that's usually Vyne Dental, DentalXChange, or the carrier's direct API if your practice has the volume to justify integration.

The automation pulls back coverage details — annual maximum, deductible remaining, frequency limitations on cleanings and X-rays, downgrade clauses — and writes a structured summary into the patient record. The front desk doesn't have to call anyone for routine cases.

Honest caveat: about 15% of eligibility checks come back incomplete or ambiguous. Secondary insurance, recently changed plans, Medicaid carve-outs — these still need a human call. The automation flags these explicitly rather than pretending to handle them.

Step 5: Push into the PMS#

This is the step that most "AI intake" pitches gloss over, because it's the hardest. Dentrix, Eaglesoft, and Open Dental all have APIs of varying quality. Open Dental is the friendliest — they have a documented REST API. Dentrix is workable through their Developer Program. Eaglesoft is painful.

For practices on a system without a clean API, we fall back to one of two approaches:

1. Database-level integration if the PMS runs locally on a server you control and the schema is documented (Open Dental, older Dentrix installs).
2. A browser automation layer that logs into the PMS as a service user and types the data in, exactly like a human would. Slower, more fragile, but works on anything with a UI.

We always recommend the API route when it exists. Browser automation is a real option but it breaks every time the vendor pushes a UI update, and you'll pay for maintenance.

Step 6: Human review checkpoint#

This is the step we refuse to skip, no matter how clean the data looks. Before anything writes to the patient chart, the automation generates a one-page summary for the front desk to approve: patient demographics, insurance verification result, medical history flags, any fields the system wasn't confident about.

Approval takes about 60 seconds per patient. Compare that to the 15 to 25 minutes of manual entry it replaces. And critically, the human is still legally and clinically responsible for what hits the chart — the automation is a draft, not a decision-maker.

We build the review interface as a simple email or Slack message with an "approve" button and a "flag for review" button. Nothing fancy. The fancy version is where people stop using it.

What the practice actually gets at handoff#

When we hand off a build like this, the deliverables are:

• The patient-facing intake form with conditional logic and SMS delivery
• The OCR and normalization pipeline for cards and IDs
• The eligibility check integration with whichever clearinghouse fits your carrier mix
• The PMS write-back layer (API or browser automation)
• The front desk review interface
• A monitoring dashboard so you can see completion rates, flag rates, and where the workflow is getting stuck
• Documentation written for your office manager, not for a developer

We also stay on for 30 days of monitoring after launch, because something will break. A carrier will change their API response format. A patient will upload a photo of their cat instead of their insurance card. The first month is when you find out what your edge cases actually look like.

What this kind of build doesn't fix#

Automation won't fix a front desk culture that doesn't trust the system. If your team keeps a paper backup "just in case," you've doubled the work instead of halving it. The change management piece — getting the team to actually use the tool — matters as much as the build itself.

It also won't fix bad source data. If your existing patient records are a mess, the automation will faithfully connect to a mess. Cleanup is a separate project.

And it won't replace clinical judgment on medical history. The automation surfaces and structures the information. A hygienist or doctor still reads it and decides what matters.

If you're running a dental or medical practice and your front desk is drowning in intake paperwork, book a discovery call and we'll map your current workflow before we ever quote a build.