Giving a vendor access to your practice database, safely

What read only actually means

The phrase gets used for three very different arrangements, and the gap between the weakest and the strongest is the whole subject. They stack, so a vendor can be at one level, two, or all three, and the difference is worth a direct question rather than an assumption.

Level one, a policy

The vendor says it does not write to your database. Nothing enforces that statement. It may be entirely true today and still be one release away from not being true, because there is no mechanism standing between an intention and a mistake. Most vendors who describe themselves as read only are describing this level.

Level two, a permission

The database account the vendor connects as has been granted read privileges and nothing else. Now the database itself refuses a write, whatever the software asks for. This is enforcement rather than intention, it lives on your side of the arrangement, and you can inspect it without asking anyone's permission.

Level three, a guard in the software

Every query the vendor's software builds is checked before it is sent, and anything that is not a read is refused at that point, on top of the account permission. The value is that the two layers fail independently. A permission that gets loosened during a support call does not silently open a door, because the software still will not ask.

An office manager can ask which level applies and should expect a straight answer in one sentence. A vendor operating at level two or three will say so immediately and will usually volunteer how to verify it. A vendor that answers with reassurance rather than a mechanism is telling you it is at level one, whether or not it uses those words.

There is an honest nuance here that a lot of vendor writing skips. A product that writes something back is not automatically disqualified. Writing a note into a chart after a call, for example, is a normal and useful thing for a billing product to do, and refusing it on principle can cost your team more than it protects. What matters is whether the vendor can enumerate the write: exactly what it writes, into which part of the record, on which separate credential, who triggered it, and how you switch it off. A vendor that can list its writes has thought about them. A vendor that cannot list them does not know what its software does, and that is the finding, not the writing itself.

How to verify a claim instead of trusting it

Everything above is only useful if you can check it, and you can, without hiring a consultant. Four questions do most of the work, and all four have answers you can confirm on your own side rather than take on faith.

1. 1Ask for the exact database user the vendor connects as. Then look at what that user has actually been granted in your own system. Whoever supports your practice software can show you this in a few minutes, and it either has write privileges or it does not. This single check turns a marketing sentence into a fact.
2. 2Ask for the list of tables the vendor reads. A vendor that built the integration knows this list, because it had to write it. If nobody can produce one, you have learned something more important than the list itself: the scope of the access is not understood by the people who hold it.
3. 3Ask whether the connection is outbound or inbound. Outbound means a machine in your office initiates the connection and sends data out. Inbound means something on the internet reaches into your network, which requires a port to be opened, and an open port is reachable by everyone, not only by the vendor. The answer changes what your practice is exposed to, so it deserves a plain answer rather than a diagram.
4. 4Ask what happens if you revoke the account tonight. You are testing two things at once: whether the vendor knows what depends on that account, and whether you can actually end the arrangement without a negotiation. Access you cannot withdraw quickly is not access you control.

Notice what these four have in common. None of them asks the vendor to be trustworthy. Each one produces an answer that is either verifiable in your own system or immediately revealing when it does not arrive. That is the point of asking them in this form.

The API versus direct database argument

You will run into the advice that a vendor should connect through an official interface rather than to the database directly, and that direct database access is the riskier of the two. It is worth taking that argument seriously, because part of it is correct.

The real case for an interface

An official interface scopes a vendor to what the interface chooses to expose, so it cannot wander into parts of the record it has no business reading. The company that makes your practice software has sanctioned it, which means somebody other than the vendor has thought about the access. And it is documented, so what it can and cannot do is written down somewhere you can read. Those are genuine advantages and none of them are marketing.

The case that rarely gets written down

Not every practice management system has one, so for many offices this is a choice between an interface that does not exist and an integration that does. The ones that exist carry cost and availability constraints of their own, and when the interface is slow or down, your data is stale and nobody in your office can tell why. An interface can also write. Being sanctioned says nothing about which operations it permits, and plenty of them permit a great deal. Most importantly, a sanctioned channel says nothing whatsoever about what the vendor at the other end does with the data once it has arrived.

Ask those three and the transport argument mostly dissolves. You may still prefer an official interface, and that is a reasonable preference to hold for reasons of support and longevity. But prefer it for what it is, a sanctioned and documented channel, rather than for a safety property it does not automatically carry. An office that chooses an interface and never asks what leaves the building has not made itself safer. It has only made itself feel safer.

Where the business associate agreement fits

If a vendor can see protected health information on behalf of your practice, it is acting as a business associate and there needs to be an agreement in place covering that. Your practice is the covered entity, which means the obligation to have the agreement sits with you rather than with the vendor. This is why the question comes before you grant access, not after the software is already running.

Most offices sign these without reading them, which is understandable and still a mistake. Five things in the document are worth your attention.

• What data is covered. The agreement should describe the information the vendor will handle, not gesture at it. Vague scope means nobody agreed on anything.
• What the vendor may do with it. Look specifically for permission to use your data for the vendor's own purposes, such as improving a product or building comparisons. That may be fine with you. It should be a decision rather than a discovery.
• Subcontractors. Whoever the vendor passes data to inherits the obligation, and you are entitled to know that chain exists.
• Breach notification timing. A number of days appears here. Read it, because your own obligations start when you are told.
• What happens at the end. When the relationship ends, what is returned, what is destroyed, and on what timeline.

A vendor that declines to sign one is a finding rather than a detail. So is a vendor that says it does not need one because the data it handles is anonymised. That claim is testable: ask whether a specific patient could be identified from what is transmitted, directly or by combining it with anything else the vendor holds. If the transmission includes names, dates of birth, member identifiers or anything else tied to a person, the claim does not hold and the agreement is required. This page is a practical guide written for office managers and it is not legal advice, so bring the agreement itself to whoever advises your practice on contracts.

What leaves the building

This is the question offices rarely think to ask, and it should come first. Reading data and transmitting data are separate acts, and vendors differ enormously on the second one. A product can read a great deal locally and send almost nothing out, and another can read very little and transmit all of it to somewhere you have never heard of. The access question and the transmission question have different answers, so ask them separately.

Go category by category rather than accepting a summary, because a summary is where the exceptions hide. For each of these, ask whether it is transmitted, where it is stored once it arrives, and who at the vendor can see it.

• Patient names.
• Dates of birth.
• Member and subscriber identifiers.
• Addresses.
• Phone numbers.
• Clinical note text.
• Images, including anything attached to a claim.

Then ask the question almost nobody asks, and the one that surprises people: what appears in your logs. Data can be handled carefully inside a product and still be written in full into a support log, a crash report or a diagnostic file, where a different set of people can read it and where it is retained under different rules. A vendor that has thought about this will answer without hesitating, because it had to make a decision to get it right. A vendor that has not will pause, and the pause is the answer.

Nine questions to ask before you grant access

Copy these into an email and send them before anything is installed. They are ordered so that the answers build on each other, and every one of them is a question a vendor who has done this work can answer in a sentence.

1. 1What database user will you connect as, and what permissions does that user need?
2. 2Can you give me the list of tables you read?
3. 3Is anything ever written back? If so, what is written, where does it go, and on which credential?
4. 4Is the connection outbound from my office, or inbound from outside?
5. 5What of my patients' data leaves the building, field by field?
6. 6Where is that data stored, and who at your company can see it?
7. 7Will you sign a business associate agreement, and can I read it before I sign anything?
8. 8What patient data appears in your logs, and how long are those logs kept?
9. 9If I revoke your access tonight, what stops working, and what do you still hold?

The answers matter, and so does the manner of answering. A vendor that responds to all nine in writing, specifically, without hedging and without redirecting you to a sales call, has already told you most of what you were trying to find out. One that answers seven and goes quiet on two has told you which two to keep asking about.