Engineering

Tap once, it's in the chart

October 16, 2026

A dental note is finished when it is in the chart, not when it is on a phone. This is the engineering story of how a CareNotes note travels from a signed draft to a clinical-note row in eight practice management systems, and why we built two very different paths to get there.

In 2016 Sinsky and colleagues followed 57 physicians through their day and found that for every hour of face time with patients they spent nearly two hours on the EHR and desk work [1]. Dentistry has not been measured as closely, but the shape is familiar to anyone who has watched a hygienist finish a column of patients and then sit down to type. Ambient AI scribes attack the first half of that problem by drafting the note. Early evaluations of ambient scribes in primary care report meaningful reductions in documentation time [2], but they also surface a second, quieter cost: the draft still has to be moved. Copy, switch windows, find the patient, find the right note type, paste, save.

That second job is what the work since the spring removes. When a CareNotes note is signed, it is written to the patient's chart in the practice management system (PMS) the practice already uses. This post walks through how that works, system by system, with the actual data contracts, the failure modes we hit, and what we deliberately did not build.

Eight systems, two architectures

Dental PMS products fall into two camps, and the camp decides the integration.

Cloud PMS with a public API. Open Dental and Dentrix Ascend expose HTTPS APIs. CareNotes calls them directly from the phone. There is nothing to install in the practice, and the practice authorizes CareNotes with a key or an organization ID.

On-premise PMS with a local database. Dentrix (classic), Eaglesoft, PracticeWorks, SoftDent, and EXACT keep their data in a SQL database on a server in the office, typically with a vendor-specific schema and no supported remote write path. For these, CareNotes installs a small Windows service, the CareNotes Agent, on the practice server. The Agent sits behind a bridge layer that knows each PMS's schema and performs the writes locally. The phone never touches the database; it talks to the bridge over HTTPS, and the bridge talks to the Agent.

Curve Dental is the odd one out: a cloud product without a public write API for notes, so it is reached through the same Agent path, with the Agent authenticating to Curve as a dedicated CareNotes user rather than reading a local database.

In the app this is a pair of allow-lists: the systems a practice can link for schedule and huddle features, and the strict subset that accepts a finished note. A system has to be on the second list before the Done button offers to send anything. CareStack is on the first list and not the second, which is why a CareStack practice sees today's schedule in CareNotes but keeps notes in the app until writeback ships.

The months below are when each link reached practices. Treat them as approximate; the commit history before April is thin and a ship date is the week a practice first used it, not an announcement.

• April and June. Dentrix (classic) through the Agent, first notes, then schedule and provider resolution.
• September. Eaglesoft and PracticeWorks.
• September 20. EXACT, which carries most of our New Zealand practices.
• October. Curve Dental: schedule sync, Morning Huddle, and note upload.

Open Dental and Dentrix Ascend were live before this stretch; that is the pair we demonstrated at GNYDM 2025.

Path one: native APIs from the phone

Open Dental

Open Dental publishes a REST API over its data model, and the resource names map almost one-to-one onto the tables a long-time user would recognize: patients, appointments, procedures, procedure notes, perio exams and measurements [3]. Authentication pairs a developer key issued to CareNotes with a customer key the practice generates inside Open Dental. The practice pastes that key into CareNotes once and the app keeps it in the device keychain.

A clinical note in Open Dental is a procedure note: text attached to a specific procedure for a specific patient. So the writeback is a single create call with the patient, the procedure, and the note body. In practice the interesting work is resolving which procedure to attach to. When a note was started from a synced appointment we already hold the procedure reference; when it was started cold, the app looks up the day's procedures for the patient and asks.

Open Dental also carries fee schedules through the API, and CareNotes reads them when a clinician accepts a suggested CDT code, so the code lands with the practice's own fee rather than a placeholder.

Dentrix Ascend

Dentrix Ascend is Henry Schein One's cloud PMS, and it exposes an organization-scoped API through the HS1 developer program [4]. CareNotes authenticates with a token tied to the practice's organization and then works against a small set of resources: appointments for today's schedule, users for the provider list, visits for context, patient procedures for accepted codes, clinical notes for the signed note, and perio exams with their probe measurements.

Ascend's model is closer to a visit-centric EHR than Open Dental's procedure-centric one, so the note is attached to the patient and provider for the date rather than to a procedure. The app hides that difference behind one "send note" operation so the rest of the product does not care which cloud PMS it is talking to.

Path two: the Agent for on-premise systems

Everything else runs through the Agent, and the contract is deliberately simple. The phone sends one request describing the note: which practice, which patient and appointment in the PMS's own identifiers, which provider, the note type, the text, and the date. The bridge replies with a job ticket, not a result. The write has not happened yet. The Agent on the practice server picks the job up, opens the PMS database, and performs the insert in whatever shape that PMS expects. We send a single generic "clinical" note type for every Agent system and let the bridge map it to each product's clinical-note module, so there is no per-vendor branching on the phone.

Because the write is asynchronous, the phone polls the ticket on a short interval until it resolves to success or failure, with a deadline measured in tens of seconds rather than the few hundred milliseconds you would give a direct API call:

ticket = bridge.createNote(note)
until deadline:
    status = bridge.status(ticket)
    if status is success: return filed
    if status is failure: raise WritebackFailed(status.message)
    sleep(pollInterval)
raise WritebackTimeout

The deadline sounds generous for an insert. It is sized for the slow case: an Agent on a practice server that is also running backups, or an Eaglesoft database mid-maintenance. The UI stays on "Sending to Dentrix…" until this returns, and the note is not marked as filed until it does. If the Agent is offline, the bridge holds the job and the clinician sees a clear message instead of a silent miss.

Rate limits as a design constraint

The bridge enforces a per-minute request budget and answers HTTP 429 above it. That is plenty for notes and tight for schedules: a multi-day schedule window is one appointment call per day, each of which used to trigger a provider lookup. The fix was mundane and worth describing because it is the kind of thing a native API hides from you.

• A client-side token bucket paces outbound calls below the server's budget, leaving headroom for retries and the Agent's own traffic.
• On a 429 the client sets a short cooldown and waits rather than failing, so a schedule refresh resumes cleanly once the window drains.
• Providers are cached for the session. They rarely change mid-day, and the cache alone removed one call per schedule day.

Provider identity

The field that caused the most support tickets was the provider identifier. Every PMS has its own, often a short code like DDS1 set years ago by whoever installed the software, and the bridge requires a real one on every note. CareNotes resolves it in order: the provider on the synced appointment, then the patient's primary provider from the PMS, then a prompt. We never send an internal CareNotes user ID; the chart has to show the dentist the practice knows.

Schedule sync, the other direction

Writeback is the headline, but the read path is what makes it usable. Once a practice is linked, the day's appointments are pulled onto the phone, so the clinician taps a patient instead of typing a name, and the note is born already knowing the patient ID, appointment ID, and provider that the writeback will need. The same synced schedule feeds Morning Huddle, which reads the previous clinical notes for each patient and drafts a briefing for the morning meeting. Sync is the reason a writeback needs no form at the end.

Linking a practice is part of Premium, priced per location with unlimited users; the full list and setup steps are on the integrations page and in the Integration Guide.

What we did not build, and why

Claims. A finished note contains CDT codes and the clinician's reasoning, which is the raw material for a claim. CareNotes does not submit claims and does not pretend to. Codes are pushed to the PMS as accepted procedures only when the clinician has accepted them and the practice is linked, and the PMS's own billing workflow takes over from there.

Bypassing review. Nothing is written until the clinician signs the note. The model drafts; the dentist is the author of record. That is a product decision but it is also a safety one: large-language-model notes still carry omission and substitution errors at rates that make unreviewed filing inappropriate for clinical documentation [2].

Direct database writes from the phone. It would have been faster to ship. It would also have meant a mobile app with credentials to a practice's SQL server, which is exactly the kind of access the Security Rule's access-control and transmission-security standards ask you to minimize [5]. The Agent keeps the database credential on the server where it already lives.

Also this year

Two neighbors of this work, written up on their own: voice periodontal charting that lands in the chart, which reuses every endpoint above with six-site measurements instead of text, and keeping the audio on the phone while the transcript gets more accurate for each clinician. Recording from the operatory computer with the Chrome extension and a room microphone is the other way to stay hands-free when the phone is not in the room. Visits, the browser workspace, is in beta. The seed round behind this roadmap came from practicing dentists; that story is here.