Informational only, not legal advice. This article reflects operational and engineering perspectives on data-handling practices. Organizations should confirm their regulatory determinations with qualified legal counsel.
Where PHI actually goes in most mid-market healthcare organizations
Ask the compliance officer where their organization’s protected health information lives and you’ll typically get a confident answer: the EHR, the billing system, the cloud storage provider covered by a BAA. Those are the systems the organization knows about. They’re covered. The documentation exists.
Then ask a follow-up question: where does PHI go in the operational layer? The collaboration tools, the analytics platforms, the scheduling software, the AI features the team adopted over the last 18 months, the integration the developer built to pull data into the reporting dashboard?
That’s where the answers get less certain.
The BAA chain is almost always incomplete
A Business Associate Agreement creates a legal relationship between your organization and a vendor handling PHI on your behalf. The vendor is required to apply the same standards you’re under, and to pass those requirements down to any subprocessors they use.
In theory, this creates a chain of protection that covers every system that touches your data. In practice, most organizations have BAA chains with gaps. The gaps appear in predictable places:
- ✓AI and analytics tools. Many AI-powered tools that teams adopt for productivity, research, or analysis are not covered by a BAA — either because the vendor hasn't issued one or because the organization didn't know to ask.
- ✓Integrations and connectors. When a developer builds an integration to pull data from one system into another, the data-handling obligations for that integration — and any intermediate systems it touches — may not be clearly assigned.
- ✓Operational software your team actually uses. Scheduling tools, communication platforms, document collaboration apps. If PHI ever appears in them — in a message, an attachment, an exported report — the BAA question applies.
- ✓Shadow tools. Team members use tools that IT didn’t procure and compliance didn’t review. By the time those tools appear in an audit, they’ve already touched data.
How organizations typically discover the gaps
Most PHI data-flow gaps are discovered reactively, not proactively. The three most common discovery events:
Audits and regulatory examinations. An examiner asks for documentation of every system that touches PHI. The organization realizes it can’t produce a complete map. The conversation becomes difficult.
Security incidents. A breach notification requires documenting where affected data traveled. The investigation surfaces systems that weren’t on the map.
Due diligence. An acquisition, investment, or partnership triggers a data-handling review. The gaps discovered under due-diligence pressure are expensive to remediate on a deal timeline.
None of these are good moments to learn that your data-flow map is incomplete.
The AI layer specifically
Artificial intelligence tools have introduced a new category of data-flow risk that most BAA chain reviews haven’t fully caught up with. The challenge is specific:
Many AI tools process data by sending it to a third-party model or service. The data goes somewhere. Whether that somewhere is covered by a BAA — whether a BAA even exists for that vendor, whether the vendor’s processing practices are consistent with your obligations — is a question most organizations haven’t answered.
This is true for AI tools your team purchased deliberately. It’s doubly true for AI features embedded in other software — the analytics tool that added an AI summary feature, the communication platform that added AI-assisted drafting, the EHR module that added an AI-powered coding suggestion. These features often add data-flow surfaces without a corresponding review.
What a data-flow mapping exercise actually looks like
The answer to “where does our PHI go?” isn’t a policy document. It’s a data-flow mapping exercise — a structured review of every system that touches regulated data, the relationships between those systems, and the coverage status of the BAA chain.
This kind of review typically surfaces:
- ✓Systems handling PHI that weren’t on the compliance team’s radar
- ✓BAA gaps — vendors handling PHI without a BAA in place
- ✓Subprocessor gaps — vendors whose own subprocessors handle PHI without the chain of coverage extending to them
- ✓AI-specific exposures — tools sending data to third-party models or services without a clear compliance determination
The output is a clear picture of where the data actually goes, where the coverage gaps are, and what needs to be remediated. That’s the starting point for getting the map right.
The posture that closes the gap
For some organizations, the answer to a complex BAA-chain gap is remediation: find the gaps, get the BAAs in place, put the operational controls in place to keep the map accurate over time.
For organizations adopting AI specifically, there’s a more fundamental posture shift available: build the AI and analytics environment so that sensitive data doesn’t need to leave in the first place. If the data never travels to a third-party service, the BAA-chain question for AI tools is resolved at the architectural level, not the contract level.
Both paths are real. The right one depends on where an organization is starting and what it’s trying to accomplish. Either way, the starting point is knowing where the data actually goes.
If your organization is working through this question, the → Compliance & Data-Protection Advisory page describes how we help organizations map what they have, find the gaps, and design a path forward. The conversation is operational and practical — not a legal opinion, and not a promise about what an auditor will say.