Audit logs are one of those things every dental PMS claims to have. Run an actual query — “show me everyone who accessed patient X's chart in March” — and the gap between marketing claims and operational reality shows up immediately. Most clinics discover, when they actually need the log, that either it doesn't exist, doesn't capture the right events, or isn't queryable without engineering involvement.
This article is for the clinic owner, IT lead, or compliance officer who needs to evaluate whether their PMS audit log will actually function under the conditions where audit logs matter.
Who actually asks for audit logs
Four scenarios where dental audit logs get queried in earnest:
- PDPC investigation.Singapore Personal Data Protection Commission opens an investigation following a data breach notification or complaint. They'll ask for the access history of affected records and for evidence of the technical controls that were in place.
- IRAS audit. Tax audits typically focus on financial records, but auditors increasingly ask for modification history of invoices, write-offs, and adjustments (see GST 9% mechanics).
- Patient access requests. Under PDPA Section 21, patients can request a record of when their data was accessed and by whom. Less common but legally binding when received. 30-day response window.
- Internal investigations. Suspected misconduct (a former employee, a malpractice claim, a missing payment) — clinic management needs to reconstruct who did what.
In every case, the question is similar: who, what, when, from where. The log either has the answer or it doesn't.
What a real audit log captures
Five categories of events that need logging for dental PHI:
1. Read events, not just write events
Most weak audit logs only capture writes (someone edited a chart, someone created an invoice). They miss reads — someone opened patient X's chart and looked at it without changing anything. For PDPA purposes, “who viewed this” is often more relevant than “who edited this.”
Reading is the most common form of access. If the audit log doesn't capture it, the log can't answer the most common audit question.
2. Authentication context
Every log entry needs the actor (which user), authentication time (when they logged in), and source (IP address or device identifier). “Admin” as an actor isn't enough — multiple staff use admin accounts in some clinics.
Source IP matters in particular for detecting “impossible travel” patterns (the same account accessed records from Singapore and Manila in the same hour). This is how compromised credentials get caught.
3. Data exports
Bulk exports — CSV downloads of patient lists, PDF generation of treatment history, screenshots of chart data — are higher-risk events than individual record access. Modern PMS log every export with the export scope (which records, which fields).
Many older systems don't capture exports at all. The data leaves silently. When an investigation later asks “was this list of patients exported in the last 6 months?” the answer is “we don't know.”
4. Adjustments and write-offs
On the financial side, every modification to a finalised invoice needs a logged actor + reason. Write-offs, discounts, courtesy adjustments, credit notes. This is what IRAS auditors look at when they spot-check an invoice with an unusual adjustment.
See same-day billing for the broader case for audit-logged adjustments at discharge.
5. Inter-clinic data movement
For multi-location dental groups, any movement of records between clinics is a logged event — referrals, consolidated reports, shared imaging. The log identifies source clinic, destination clinic, records moved, actor, time. This is the evidence of tenant isolation in operation (see PDPA + tenant isolation).
Architecture: what makes a log trustworthy
Five technical properties separate a real audit log from a glorified activity feed:
- Append-only. No edits, no deletes. Any modification of the log itself is itself a log entry.
- Tamper-evident. Cryptographic chaining (each entry references the hash of the previous) so attempts to rewrite history are detectable.
- Long-term retention. 7+ years for dental records (matches professional retention standards). Daily backups. Cold storage for older entries.
- Queryable by clinic admin.Not just engineering. The clinic admin should be able to answer “who accessed patient X this month” through the UI in seconds.
- Exportable. When PDPC asks for the log, the clinic can export the relevant subset as CSV or JSON without a vendor support ticket.
What weak audit logs miss
Common failure patterns we see in dental PMS audit features:
- Read-only access not logged (silent observation by staff who shouldn't be looking)
- Bulk operations recorded as a single event without the scope (“exported records” vs “exported 1,247 records including X, Y, Z”)
- Admin-level overrides not differentiated from regular access
- Logs stored in the same database as the data they audit (ransomware encrypts both at once)
- Logs accessible only via vendor support ticket (every query becomes a multi-day workflow)
What to look for in PMS audit logs
Six concrete questions to ask vendors:
- Are read events logged in addition to writes?
- Can a clinic admin run a query through the UI without engineering involvement?
- Are bulk exports tracked with their scope?
- Is the log append-only and tamper-evident?
- Is the log stored separately from the transactional database?
- What's the retention period? (Should be 7+ years.)
What to do next
Run a sample query on your current PMS today. Pick a patient seen in the last week and ask the system to tell you everyone who accessed their record. If the answer takes longer than a minute, or requires a vendor support ticket, the audit log is not fit for the moments it's actually needed.
See the Oralstack security posture for the audit log implementation, including append-only events and clinic-admin-queryable history.