Every vendor that touches prescription data will tell you they are HIPAA compliant and will sign a business associate agreement. Both statements are close to meaningless as differentiators, because both are the entry fee. What separates vendors is whether the controls behind the paperwork are properties of the system or promises about behaviour.
These are the questions that actually distinguish them, with the regulatory citations so you can check the answers yourself.
Start by knowing what the BAA must already contain
A business associate contract has required elements under 45 CFR 164.504(e)(2), and a vendor is not doing you a favour by including them. The contract must already establish permitted uses and disclosures, require Security Rule safeguards for electronic PHI, require reporting of uses or disclosures not provided for by the contract including breaches of unsecured PHI, bind subcontractors to the same restrictions, make PHI available for access under 164.524 and for amendment and for an accounting of disclosures, open internal practices and records to the Secretary, and return or destroy all PHI at termination.
So the useful question is not “will you sign a BAA”. It is what you add beyond the minimum.
The breach clock, and why you should shorten it
Under 45 CFR 164.410, a business associate must notify the covered entity of a breach of unsecured PHI “without unreasonable delay and in no case later than 60 calendar days after discovery”, where discovery is the first day the breach is known or would have been known by exercising reasonable diligence. The notification must identify each individual whose PHI was or is reasonably believed to have been accessed, acquired, used or disclosed.
Sixty days is the legal ceiling, and it is a long time to wait when your own notification obligations to patients run from what your business associate tells you. Negotiating initial notice down to a few days is normal, and a vendor’s reaction to being asked is informative in itself.
Ask what PHI the vendor actually needs
The minimum necessary standard at 45 CFR 164.502(b) applies to what a business associate requests, not only to what you disclose.
For margin analytics, ask what identifiers the vendor genuinely requires. A system computing the economics of a fill needs the drug, the quantity, the payer routing, the amounts and a stable reference back to the prescription. It does not necessarily need a patient name on a dashboard. Ask which screens display patient identifiers and whether operational views can be built without them at all.
Tenant isolation: a property or a promise?
This is the single most revealing technical question in a multi-tenant product.
“Our application always filters by the customer identifier” is a promise about developer discipline. It holds until one query is written without the filter, which is a category of bug that has leaked customer data at companies far larger than any pharmacy software vendor.
The stronger answer is that isolation is enforced by the database itself, so a query missing its scope returns nothing rather than someone else’s rows. Ask specifically whether row-level security is enabled and forced on every table holding customer data, whether the policies cover writes as well as reads (a read-only policy still allows a row to be written stamped with another customer’s identifier), how the current tenant is established and whether it can leak across a pooled connection, and whether an automated check stops a new table shipping without a policy.
That last one matters most over time. Isolation applied once decays as the schema grows unless something enforces it on every change.
Who at the vendor can read your data, and would you know?
Someone at any vendor can read your data, because support requires it. Assume it. What is not normal is being unable to reconstruct who did, when and why.
Ask whether there is a log of PHI access, whether it records the person and not just the service, and above all whether it is append-only. An audit log the application can edit or delete is a report, not an audit log. The answer you want is that the runtime database role has no permission to update or delete those rows at all, which is different from the application choosing not to. Then ask whether you can see your own.
The unglamorous ones
Encryption. In transit is table stakes. At rest, ask what specifically is encrypted and where the keys live. Ask separately about secrets that are bearer credentials in their own right, such as multi-factor seeds, which defeat a second factor permanently if they leak in plaintext.
Authentication. Is multi-factor authentication mandatory or merely available? Those are different products, and an account reaching PHI should not be able to opt out.
Logs. Ask whether PHI can end up in application logs. Most vendors have never considered it, and logs are frequently the least protected copy of your data, shipped to third-party tooling and readable by more people than the database is.
Subprocessors. Ask for the list in writing, and for notice when it changes. Under 164.504(e)(2)(ii)(D) subcontractors must be bound to the same restrictions, so the list is the shape of your actual exposure.
Termination. Ask what return-or-destroy means in practice, what format the export takes, and how long deletion takes.
SOC 2, and what it does and does not tell you
SOC 2 is an attestation report produced by an independent auditor against the AICPA Trust Services Criteria. A Type I describes controls at a point in time. A Type II tests whether they operated effectively across an observation window, typically several months to a year, and Type II is the one worth having.
Treat the report as a summary of substance, not a substitute for it. Whatever a vendor holds, ask for the written control descriptions themselves, the subprocessor list, and a demonstration of the mechanisms on a live system. Most of the controls above are demonstrable in a twenty-minute screen share, and a vendor confident in its architecture will offer exactly that. A logo on a trust page with no demonstration behind it is marketing, whoever issued it.
The answers that sound good versus the answers that matter
| Question | Sounds good | Actually matters |
|---|---|---|
| Tenant isolation | ”We are fully multi-tenant and secure” | Row-level security, forced, covering writes, checked on every new table |
| Staff access | ”Access is restricted to authorised personnel” | An append-only log the runtime cannot edit, and you can read it |
| Encryption | ”Bank-level encryption” | Named algorithms, and where the keys live |
| MFA | ”We support two-factor authentication” | It is mandatory and cannot be turned off |
| Breach | ”We comply with HIPAA” | A contractual clock materially shorter than the 60 days in 164.410 |
| Assurance | ”We are HIPAA compliant” | Control descriptions you can read, demonstrated on a live system |
Attergo’s answers today
Isolation. Postgres row-level security on every tenant-scoped table, forced so the table owner cannot bypass it, with separate policies for select, insert, update and delete so a write cannot be stamped with another tenant’s identifier. The tenant is set inside the same transaction as the work, so it cannot survive on a pooled connection into the next request. A query issued outside that scope sees no rows at all, so the failure mode of a forgotten scope is an empty screen in development rather than a leak in production. An automated check fails the build if a table carrying a tenant identifier ships without a policy.
Access logging. A PHI access log records the user, the action, the entity and the source address. The application’s database role has update and delete revoked on it outright, so it is append-only in the strict sense rather than by convention. The ingested payload archive is append-only for the same reason, with only its processing status writable.
Authentication. A time-based one-time password second factor, mandatory rather than optional. Seeds are encrypted at rest with AES-256-GCM under a key held in the environment, so a read-only database leak does not hand over a working second factor.
Logs. A build-failing test scans the API and every shared package for PHI reaching a log statement. It is a test rather than a lint rule specifically so it cannot be silenced with an inline comment.
BAA. We sign one before any PHI moves, and we will negotiate the notification clock below the regulatory ceiling.
Assurance. A formal control program aligned to SOC 2 Type II criteria, maintained as audit evidence, with security documentation available under NDA and every mechanism above demonstrable on a live system in the evaluation itself.
One note on scope. The platform is eight products on one event spine, and the questions above apply to the spine, because that is where your data actually lives. Isolation, access logging and the immutable archive protect every product equally, which is the point of building on one spine at all.