Business associates and third-party services

A business associate is an entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity. In software terms, that is most of your infrastructure: the cloud provider, the database host, the email service, the error tracker, the analytics platform, the support desk, the transcription service, the observability vendor.

Two consequences follow, and the second one is where the engineering work is.

The first is contractual: those relationships need business associate agreements, and that is a legal and procurement task rather than a technical one.

The second is that the list of vendors receiving PHI has to be accurate, and keeping it accurate is genuinely hard, because engineering changes it constantly and usually without noticing.

The list goes out of date because adding a dependency is easy

The way this happens is not sinister and it is not rare. A developer adds an error tracking SDK because debugging production is painful. The SDK captures exception context, which includes request payloads. A request payload on a clinical endpoint contains patient data. PHI is now flowing to a vendor who is not on any list, under no agreement, in a jurisdiction nobody checked.

Nobody decided to send PHI to that vendor. Somebody decided to improve error visibility, which is a good instinct, and the PHI was included because that is what error payloads contain.

The same pattern repeats across the system. An analytics library that captures form field values. A session replay tool that records the screen, including whatever chart is open. A support platform integration that syncs record context so agents have background. A feature flag service that receives user attributes. A logging pipeline that sends logs to a hosted service. A CDN that caches an authenticated response it should not have.

Each of these is a normal engineering choice that would be unremarkable in a non-regulated product.

Make the boundary explicit in code

The lasting fix is not a policy telling developers to be careful. It is making the flow of PHI to external services something the system controls rather than something individual code paths decide.

Three mechanisms matter most.

A filtering layer on anything leaving the system. Error reports, analytics events, and log lines pass through a filter that removes or masks known PHI fields before transmission. This is imperfect, because it depends on knowing which fields carry PHI, but it converts the default from "everything goes" to "only what passed the filter goes."

An explicit allowlist of external destinations. The set of hosts the application may transmit to, enforced at the network or client layer rather than by convention. A new SDK sending data to an unlisted domain fails loudly in development rather than silently in production.

A test that asserts what a payload contains. Take a representative error on a clinical endpoint, capture what the error handler would transmit, and assert that no PHI field appears in it. This catches the case where a filtering layer exists and a new field was added that it does not know about, which is the way filtering layers become incomplete over time.

That third one needs more attention. Every mechanism here degrades over time as fields are added and payloads change, and the assertion is what keeps degradation visible. Without it, the filter is correct on the day it was written and incomplete forever after, without anyone noticing.

Keep the inventory as a build artefact

The vendor list should not be a spreadsheet maintained by whoever remembers.

The version that stays accurate is generated from the system: the allowlist of permitted destinations is kept in the repository, changes to it require review, and the compliance record of signed agreements is checked against it. When an engineer adds a destination, they change a reviewed file, which puts the decision in front of somebody before it is released rather than finding it in an audit two years later.

That is the same pattern as the decision records on Required vs Addressable safeguards: keep the compliance artefact next to the code, where the people who will change it will see it.

The subprocessor problem

Your vendors have vendors. A service you have an agreement with may itself run on infrastructure you have never assessed, and may add subprocessors after you signed.

There is no simple engineering answer to this. What helps is treating the vendor list as tiered rather than flat: direct recipients of PHI get the most scrutiny, and for each of those, someone tracks the subprocessor disclosures the vendor publishes. It is unglamorous and it is the part most organisations skip entirely, which means a change in a vendor's infrastructure is invisible to you until something goes wrong.

What to check before adding a dependency

A short list, applied before the SDK goes in rather than after.

Does this service receive PHI, including incidentally through payloads, errors, or screen content? If the honest answer is unclear, assume yes and check by capturing what it actually transmits. Is there a signed agreement in place? Where does the data physically go, and does that matter for your obligations? What is the vendor's retention, and does it exceed yours? Can you delete data from the vendor when you delete it from your system, which matters for both retention and patient requests?

That last question catches a specific and common problem: a record is deleted from the primary system, correctly, and persists indefinitely in an analytics platform, an error tracker, and a support tool, because nobody built deletion that reaches the other systems.

The related patterns for finding where data has already spread are on where PHI leaks in a working application. If you want help tracing what your product currently transmits, get in touch.