A payment was on the account last Tuesday. Today it is not. Somebody removed it, and Open Dental knows who, because it wrote the action to a table the moment it happened.
Where is the audit trail in Open Dental?
Open Dental calls it the Audit Trail and it is opened from the Tools menu. The window shows one row per logged action, with filters for user, patient, date range and permission type.
There are also two per-patient views. In the Account module, the audit trail button next to a payment or adjustment shows the history of that one entry. In the Appointments module, right-clicking an appointment shows its history, which comes from a separate table called histappointment.
What does the security log record?
Behind the window is a MySQL table called securitylog. Each row has these columns.
| Column | What it holds |
|---|---|
| SecurityLogNum | A running number, so rows can never be reordered |
| PermType | Which permission was used, as a number (for example PaymentCreate, AdjustmentEdit, ProcDelete) |
| UserNum | Who did it, linked to the userod table |
| LogDateTime | When, to the second, on the server clock |
| PatNum | Which patient, if any |
| CompName | Which workstation |
| FKey | The record that was touched, such as the payment number |
| LogText | A short description, for example “Delete payment of $420” |
Two things make this log better than what Dentrix or Eaglesoft offer. It names the user, and it names the workstation. If two people share a login, CompName is often what tells them apart.
There is also a securityloghash table that stores a hash of each row. If a row is edited directly in the database, the hash no longer matches and the Audit Trail window flags it.
What does it not record?
The log records actions, not values. The entry for a payment edit says a payment was edited and often the amount, but it does not store every field before and after. For a deleted payment the amount is in the text. For an edited appointment note, you get the fact of the edit.
It also records a lot of noise. Opening the Chart module writes a row. Printing a report writes a row. Running a query writes a row. On a busy office the module access permissions are the highest volume rows in the table by far. They are useful for one question (who opened this patient’s chart) and useless for another (who moved money).
And it only records what Open Dental does through its own screens. A change made directly in MySQL by someone with the password leaves no securitylog row, only a broken hash.
How do I actually run an audit?
Pick a week. Open the Audit Trail window, set the dates, and filter to these permission types one at a time: PaymentEdit, AdjustmentCreate, AdjustmentEdit, InsWriteOffEdit, ProcDelete. On a healthy office the list for a week is short.
For each entry, ask two questions. Does the day sheet for that date show the same amount? Is there a note in the account explaining why?
A worked example. The filter for PaymentEdit over one week returns 23 rows. 20 are edits to the payment note or type. 3 have LogText beginning “Delete”. Two of the three were deleted and re-entered within five minutes, the same amount, by the same user, which is a correction. The third is a $420 payment deleted at 2:14 PM on workstation WS-03, with nothing re-entered. That is the one that needs a conversation, and the log gives you the user, the time and the chair to have it from.
Keep a note of what you checked and when. An audit nobody wrote down is not an audit.
What Calibic adds
Protect is LIVE for Open Dental. Calibic reads securitylog, userod and histappointment read-only every few minutes and keeps its own copy of the entries that matter: payments, adjustments, write-offs, procedure deletions, appointment breaks and logins. It deliberately ignores the module access rows so the digest is not “someone opened the chart” two thousand times a day. In our own audit of three practices (about 1.4 million change events, internal audit, October 2026, anonymised) the old rules raised 5,959 alerts and the calibrated rules raised 15.
Each alert keeps the before and after values, the user, the workstation and the time, so the evidence is there even if the row is later edited. Calibic never writes to securitylog and cannot delete a row from it.
Read how alerts are kept as evidence on the Protect product page. The sibling guide covers the Dentrix audit trail, where no user is recorded at all, and the Open Dental integration page lists everything Calibic reads.