Every healthcare buyer asks every PII vendor the same question early in procurement: “Do you have a BAA?” It is a reasonable question, and for most vendors it is the right one. For a vendor that ships self-hosted software, it is aimed at the wrong target. Philterd does not sign a Business Associate Agreement, and the reason is not reluctance or a paperwork shortcut. It is that there is no business-associate relationship to govern. This guide walks through why, from the definitions up, so your compliance team can confirm it rather than take it on faith.
What HIPAA actually says
A HIPAA Business Associate Agreement is a contract between a covered entity and a business associate. The term is defined in 45 CFR § 160.103: a business associate is a person or entity that, on behalf of a covered entity, creates, receives, maintains, or transmits protected health information.
The four operative verbs all describe contact with the data. A business associate is something that handles your PHI. The BAA exists to govern that handling: how the associate safeguards the PHI it touches, what it may do with it, and what happens when the relationship ends.
So the real question behind “do you have a BAA?” is: does this vendor handle our PHI? If the answer is no, there is nothing for a BAA to govern.
The architecture test
Apply the definition to two vendor models.
A SaaS vendor that processes PHI in the vendor’s cloud. You send records to the vendor’s service, the vendor’s systems process them, and results come back. The vendor receives, maintains, and transmits your PHI on your behalf. That is the textbook business-associate relationship, and a BAA is required. This is a perfectly valid architecture; it simply comes with a business-associate role.
Self-hosted software running entirely inside your own environment. You deploy the software in your own cloud account or data center. It runs against your data, inside your perimeter, under your access controls. The vendor’s systems never see the data. Philterd works this way: Philter, Phileas, and the rest of the toolkit run inside your infrastructure. Customer PHI never reaches Philterd, is never processed by Philterd, and is never accessible to Philterd at runtime.
Run the test against the second model and it fails every verb in the definition. Philterd does not create, receive, maintain, or transmit your PHI. Philterd is therefore not a business associate, and there is no BAA to sign. This is a direct consequence of the architecture: software you self-host cannot create a business-associate relationship with the software vendor.
The GDPR mirror
The same logic holds under GDPR. Article 28 governs the relationship between a data controller and a data processor, where a processor is an organization that processes personal data on behalf of a controller. A Data Processing Agreement governs that processing.
Philterd does not process your personal data on your behalf, because Philterd does not process your personal data at all. With self-hosted software, you are both controller and processor; Philterd sits outside that boundary as a software vendor. There is no processor relationship, so there is no DPA to sign.
What this changes for your own BAA and DPA chain
Nothing about your own obligations changes. Your agreements with downstream parties (your cloud provider, an EHR vendor, any SaaS service you send output to) are exactly what they were. Self-hosting Philter does not remove any of those.
If anything, it makes that chain cleaner. Running HIPAA Safe Harbor de-identification before data leaves your perimeter can take an entire class of downstream vendor BAAs off the table, because the data is no longer PHI by the time it reaches them. The point of redacting at the edge is to shrink the set of systems and vendors that ever see regulated data.
The one edge case: consulting
There is one situation where the question changes. In a consulting engagement, Philterd staff may work inside your environment. Most engagements are scoped to synthetic data, policy design, deployment review, and model training that does not require seeing real records. When an engagement genuinely requires Philterd staff to handle real PHI, that is governed by the engagement contract, which spells out how PHI is handled, rather than by a standing BAA. The distinction is that this is about people doing a defined piece of work, not about the software having ongoing access to your data.
A note on vendor architecture
If a PII vendor asks you to sign a BAA, it is worth understanding what that BAA covers. It almost certainly means the vendor processes your PHI in their cloud, which is a different architectural decision from running redaction inside your own perimeter. Both can be HIPAA-compliant. Only the second keeps the data in your control the entire time. The presence or absence of a BAA is not a measure of how seriously a vendor takes compliance; it is a signal of where the data is processed.
The bottom line
Philterd does not sign a BAA because there is no business-associate relationship to govern, and does not sign a DPA because there is no processor relationship to govern. Your data never reaches us. Your compliance posture is improved by that fact, not weakened by it.
If your procurement or security team wants to verify this reasoning, point them at the security overview, or talk to the team about your specific deployment.