From Chairside to Codebase: Dentists and Chiropractors Building Their Own Software with AI

The Clinician Who Ships Code

Every practice has a list of things its software almost does. The booking widget that cannot show new-patient exams separately. The recall report that has to be exported, filtered and pasted into a spreadsheet every Monday. The chiropractic care plan where nobody notices a patient has quietly stopped coming after visit six of twelve. For years the answer was the same: request it from the vendor, wait, or pay a developer.

That has changed. AI coding assistants such as Claude, ChatGPT, Cursor and GitHub Copilot can take a request written in plain English — “build a page that shows my open hygiene appointments next week and lets a patient book one” — and produce working code, explain it line by line, and fix it when something breaks. Dentists, chiropractors, practice owners and office managers who have never written software are building small, focused tools for their own practices, often over a few evenings.

This is not about replacing your practice management system or the vendors you rely on. It is about filling the gaps around them with tools shaped exactly to how your practice works. This post covers what clinicians are building, a worked example of an online booking page, and the guardrails that matter when the data is patient data.

What Actually Changed

Writing code was never the hardest part of building software; knowing what to build was. Clinicians have always had the second part. They know which patients fall through the cracks, which phone calls the front desk takes fifty times a day, and which report the associate dentist actually reads. What they lacked was the first part, and that is the part AI assistants now handle well.

• You describe, it builds. Requirements in everyday language become a working project with files, a server and a web page.
• It explains its work. Ask “what does this function do?” or “why did it fail?” and you get an answer in plain terms, which is how many clinicians are learning to code as they go.
• It iterates quickly. “Make the button bigger,” “only show Tuesdays and Thursdays,” “add the hygienist’s name” — each change takes minutes rather than a ticket and a sprint.

The judgment still has to come from you: what the tool should do, what it must never do, and whether the result is right. That is a role clinicians are already trained for.

What Dentists and Chiropractors Are Building

Their own online booking

A booking page that matches the practice’s rules instead of a generic widget: new-patient exams only with certain dentists, emergency slots held back until the morning, a chiropractic adjustment that books 15 minutes while an initial consultation books 45. The page reads real openings from the schedule and writes the appointment straight into the practice system, so the front desk sees it like any other booking.

Recall and reactivation lists

“Patients due for a cleaning who have no appointment booked,” or “patients who completed fewer than half the visits on their care plan in the last 90 days.” A short script turns these into a call list every morning, or sends a friendly text with a booking link.

A morning huddle dashboard

One screen with today’s schedule, unconfirmed appointments, patients with an outstanding balance, and treatment that was diagnosed but never scheduled. Practices that run multiple locations build the same view across every office.

Intake that lands in the chart

A new-patient form on the website that creates the patient record, attaches the signed consent as a document and adds a note for the clinical team (where the practice system supports each of these), instead of a PDF that someone retypes.

Follow-ups and reviews

A post-visit message the day after a procedure, a check-in after the third adjustment, or a review request after a completed appointment — triggered by what actually happened in the schedule rather than a fixed timer.

The Wall Everyone Hits: Getting to the Practice Data

The AI assistant can build the page in an afternoon. What it cannot do on its own is reach your appointment book. Every practice management system stores its data differently, many have no public API, and the ones that do each have their own approval process, data formats and rules. This is where most clinician projects stall: the interface is finished, but there is no reliable way to read the schedule or write a booking back.

CRMBridge exists to remove that wall. The CRMBridge Integrator connects to the practice’s system, with a guided setup the practice authorizes, and your tool talks to one REST API that works the same whether the practice runs Dentrix, Eaglesoft, Open Dental, Dentally, Curve, Jane, ChiroTouch or any of the 40+ supported systems. Your app asks for open slots, patients, providers or balances, and books appointments, creates patients and adds notes with the same calls everywhere.

Worked Example: An Online Booking Page in an Afternoon

Here is the shape of a real project: a small page on the practice website that shows the next two weeks of openings for one provider and books the one the patient picks.

Step 1: Get API access and use the sandbox

Create a free developer account; once it is approved, create an app. Build everything against the sandbox environment, which accepts the same requests as production but holds no real patient data, so nothing you try while learning touches the real schedule. When the tool works, link the app to your practice’s location (the CRMBridge Integrator is installed at the practice) and switch to production.

Step 2: Tell the assistant what you want

A good first prompt is specific about the behaviour and about the rules:

Build a small web app for my dental practice.
- One page that lists open 30-minute slots for provider DR1 for the next 14 days,
  using the CRMBridge AvailableSlots API.
- When a patient picks a slot, ask for name, date of birth, phone and email,
  then book it with CreateNewAppointment (create the patient first if needed).
- All CRMBridge calls must happen on the server. Keep the API keys in
  environment variables, never in the browser or in the code.
- Show a clear confirmation, and a friendly message if the slot was just taken.
Explain each file you create.

Step 3: The two calls that do the work

The assistant will write code around two API calls. First, the open slots:

POST https://api.crmbridge.ai/v1/AvailableSlots
BusinessID / LocationId / APIToken headers

{
  "CRMPracticeId": "1",
  "ProviderId": "DR1",
  "FromDate": "2026-11-02",
  "ToDate": "2026-11-15",
  "StartHour": 8,
  "EndHour": 17,
  "SlotDuration": 30,
  "IncludeWeekends": false
}

// Response (shortened)
{
  "TotalSlots": 37,
  "LocationTimeZone": "America/Chicago",
  "Slots": [
    { "SlotDateTime": "2026-11-03T09:00:00", "Operatory": "OP2", "DurationMinutes": 30 },
    { "SlotDateTime": "2026-11-03T09:30:00", "Operatory": "OP2", "DurationMinutes": 30 }
  ]
}

Then the booking, written straight into the practice system and confirmed in the same response:

POST https://api.crmbridge.ai/v1/CreateNewAppointment
BusinessID / LocationId / APIToken headers
Idempotency-Key: web-booking-7f3a2c

{
  "CRMPracticeid": "1",
  "PatientId": "10233",
  "ProviderId": "DR1",
  "OperatoryId": "OP2",
  "AppointmentDate": "2026-11-03",
  "TimeHour": "09",
  "TimeMin": "00",
  "AppointmentLength": "30",
  "AppointmentReason": "New patient exam (booked online)",
  "Realtime": true
}

With "Realtime": true the API waits for the practice system and returns the outcome — booked, with the new appointment’s id, or refused with the reason — so the page can show “You’re booked” or offer another time. The Idempotency-Key header means a double-click or a retried request never books twice.

Step 4: Test, then go live

Try the edge cases in the sandbox: a slot taken by the front desk a moment earlier, a patient who already exists, a holiday, a provider’s day off. Ask the assistant to add a test for each. When everything behaves, switch to production with your practice’s location and put the page on your website.

For Chiropractors and Allied-Health Clinics

Chiropractic practices tend to book in patterns rather than single visits, which is exactly where generic booking tools struggle. For clinics on ChiroTouch or Jane, good first projects include:

• Care-plan booking that offers the next three visits at the patient’s usual day and time in one step.
• Drop-off alerts for patients whose visits stopped partway through a plan, with a one-tap rebooking link.
• Walk-in and same-day boards that show who can be fitted in between scheduled adjustments.
• Simple outcome check-ins sent after a set number of visits, with replies saved as a note in the patient’s record.

The same API calls apply: read the schedule, book the visit, add the note. A tool built for one chiropractic clinic can be reused by a colleague on a different system without rewriting the integration.

Explore Your Data Before Writing Any Code

If you are not sure what to build yet, start by asking questions. The CRMBridge MCP server lets AI assistants such as Claude and ChatGPT read your practice data directly, scoped to one location you approve: “Which patients are overdue for recall?”, “How many new patients did we see last month?”, “What is unscheduled from treatment plans?”. Questions you find yourself asking every week are the best candidates for a tool.

The Guardrails: Patient Data Is Not a Side Project

The ease of building is exactly why the guardrails matter. Anything that touches the schedule or the chart handles protected health information, and the responsibilities that come with it do not get smaller because the code was written by an assistant.

• Keep patient data out of chat windows. Build and test in the sandbox with made-up patients. Only use AI tools with real patient information under an agreement that covers it, such as a business associate agreement in the US, and follow your local privacy rules (HIPAA, PIPEDA and provincial laws in Canada, UK GDPR).
• Keys stay on the server. API credentials belong in server-side environment variables. Never in browser code, a spreadsheet or a public code repository.
• Start read-only. A dashboard or a call list cannot damage the schedule. Turn on write access deliberately, for the one thing that needs it, once the read side is right.
• Review what was written. Ask the assistant to explain the security of its own code: how users are authenticated, what is validated, what is logged. Logs should never contain patient details. For anything patients use, have a developer you trust look it over.
• Host it properly. Use a managed hosting service with HTTPS, automatic updates and backups rather than a computer under the front desk.
• Know when to hand over. When a tool becomes something other practices depend on, or something your practice cannot run without, it is time to involve a professional developer or a software partner to maintain it.

The Practices That Build

The clinicians who are doing this well are not trying to become software companies. They pick one problem they see every day, build the smallest tool that fixes it, and improve it a little each week. The booking page comes first; the recall list follows; then the huddle dashboard that the whole team opens every morning.

AI assistants have made the building part approachable. A single, well-documented API to the practice management system makes the result something you can actually rely on — and something you can take with you if the practice changes systems.