A vendor asks for “access to your practice management system”. Before you say yes, the question that matters is not whether they are trustworthy. It is what their log-in is allowed to do if someone else gets hold of it.
Read-only is the answer that limits the damage. This page explains what it means technically and how to check it.
What does read-only mean at the database level?
Every practice system stores its data in a database with user accounts of its own, separate from the log-ins staff use on screen.
- Open Dental runs on MySQL (or MariaDB). A database user can be granted
SELECTonly, which permits reading rows and nothing else.INSERT,UPDATEandDELETEare separate grants. - Dentrix (G series) exposes its data through a FairCom SQL interface with its own users and views such as
admin.payment_view. A user can be limited to the views and denied write statements. - Eaglesoft runs on Sybase SQL Anywhere. The same idea: a user with
SELECTontransactions_header,patient,appointmentand the lookup tables, and no write rights.
A read-only integration uses an account like that. It can see a payment. It cannot delete one, post one, change an appointment, or alter a chart note, no matter what software is running on the vendor’s side.
How do you check a vendor is actually read-only?
Ask three questions and expect specific answers.
- Which database user does your connector use, and what grants does it have? The answer should be a user name and the word SELECT. “We use the API” is not an answer on its own; ask which API scopes.
- Which tables and columns do you read? A vendor who can list them has thought about it. A vendor who says “everything” has not.
- Can you show me the grant statement? For Open Dental:
SHOW GRANTS FOR 'vendor'@'%'run by your IT person returns one line, and it should contain SELECT and nothing else.
If the vendor also needs to write (for example, to post appointment confirmations back into the schedule), that is a legitimate need for some products. It is also a bigger risk, and it belongs in the BAA and in your vendor list as read-write.
Why does it matter if the vendor is breached?
Assume the worst case: the vendor’s systems are compromised and the attacker holds the connector’s credentials.
| Vendor access | What the attacker can do to your PMS |
|---|---|
| Read-only | Read whatever the account can see, for as long as the credential works |
| Read-write | All of the above, plus delete payments, alter balances, change appointments, insert records, or encrypt the database |
Reading is bad enough, which is why the credential should also be revocable in one step and the connection encrypted. But reading cannot corrupt the ledger you reconcile every day, and it cannot destroy the audit trail you would need afterwards. The data security checklist has the rest of the controls.
What about API access instead of a database user?
Some systems offer an API rather than a database log-in. Open Dental, for example, has an API with permissions set per key. The same questions apply: which endpoints, and are any of them writes. An API key that can create appointments is read-write, whatever the vendor calls the integration. Ask for the list of endpoints or scopes in writing and keep it with the BAA, so that when staff change, the next office manager knows what each vendor can do.
What read-only does not protect against
- It does not stop the vendor from storing a copy of what it reads. Ask where the copy lives, how long it is kept, and who can see it.
- It does not stop a vendor from reading more than it needs. That is why the table list matters.
- It does not replace the BAA. HIPAA treats the vendor as a business associate regardless of the access level.
What Calibic adds
Calibic’s connectors are read-only toward Open Dental, Dentrix and Eaglesoft. They never write, edit or delete a record. The tables each connector reads are listed on the Coverage page: in Open Dental that includes securitylog, userod, histappointment and deletedobject; in Dentrix admin.appthist, admin.payment_view and admin.adjustment_view; in Eaglesoft transactions_header, patient, appointment and the provider and service type lookups. Calibic does not read images or X-rays and does not take payments. It is built for HIPAA, and a Business Associate Agreement is sent with every sign up. Protect, which depends on this access, is LIVE.
Next step: read the Coverage page for the per-system list.