A pharmacy was three weeks from signing a contract for an AI prior-authorization (PA) tool that had aced every clinical evaluation and cleared a rigorous safety gate. The clinical case was airtight. Then someone on the team finally read the vendor's data-processing terms in full and found a single clause buried on page nineteen: the vendor reserved the right to use customer data, "including content submitted through the service," to "improve and train its models." In plain language, every patient chart the pharmacy fed into the tool could become training data for a model the pharmacy did not control, could not retrieve, and could not audit. The tool was clinically excellent and contractually unacceptable, and the gap between those two facts had almost cost the pharmacy a breach of its patients' trust and its legal obligations. The director who caught it said something the whole team remembered: "We evaluated whether the tool was good. We almost forgot to evaluate whether we were allowed to use it." This lesson is about the part of vendor selection that has nothing to do with how well the tool works and everything to do with whether the pharmacy can use it without violating its duty to protect patient information: security, the Health Insurance Portability and Accountability Act (HIPAA), and the due diligence that keeps the obligations which never leave the pharmacy from being quietly signed away.

The Obligation That Stays With You

Begin with the principle that governs everything else in this lesson: the pharmacy is a covered entity under HIPAA, and that responsibility does not transfer when you hand patient data to a vendor. Protected health information (PHI) is individually identifiable patient health information, and HIPAA is the federal law requiring covered entities to protect it. When a pharmacy gives PHI to an AI vendor that processes it on the pharmacy's behalf, the vendor becomes a business associate, but the pharmacy does not stop being responsible. The legal architecture is shared, not transferred: the vendor takes on obligations, and the pharmacy retains its own, including the duty to have chosen a vendor that can actually protect the data. A breach at the vendor is still, in the ways that matter to patients and regulators, the pharmacy's problem.

This is why due diligence is not optional paperwork or a box the legal department checks after the clinical team has fallen in love with a tool. It is the pharmacy fulfilling its own non-transferable duty. The earlier levels of this program established that the most dangerous PHI risk is often the convenient one, a well-meaning staff member pasting a chart into an unsanctioned tool. Vendor due diligence is the organizational equivalent of that same vigilance: the pharmacy making sure that the sanctioned tools it formally adopts are themselves worthy of the patient data they will receive, because a tool the organization blesses and binds into the workflow carries PHI at far greater scale than any single careless paste, and a weak data posture at the vendor level is a breach engine the pharmacy built on purpose. The clinical evaluation asks whether the tool is good; due diligence asks whether the pharmacy is permitted and able to protect patients while using it, and a no to the second question ends the conversation regardless of the answer to the first.

The duty to protect patient information does not transfer to the vendor. The vendor takes on obligations, but the pharmacy keeps its own, including the duty to have chosen a vendor that can actually protect the data.

The Business Associate Agreement Is the Floor, Not the Ceiling

The central legal instrument of vendor due diligence is the business associate agreement (BAA), the contract that legally binds a vendor handling PHI to protect it and restricts how the vendor may use and disclose it. The instant a pharmacy AI tool touches patient data, a BAA is required, and no BAA means the tool cannot lawfully receive PHI, full stop. So the first and most basic due-diligence question is simply whether the vendor will sign a BAA at all. A vendor that cannot or will not is disqualified for any use involving patient information, no matter how impressive the demo, and a surprising number of consumer-grade and general-purpose AI tools fall at exactly this hurdle because they were never built to be business associates.

But the presence of a BAA is the floor, not the ceiling, and treating "they signed a BAA" as the end of due diligence is a serious mistake. A BAA is a legal commitment, and a legal commitment is only as good as the security and practices behind it. A vendor can sign a BAA and still have weak encryption, sloppy access controls, an unclear data location, or a clause elsewhere in the contract that quietly permits the model-training use the BAA was supposed to prevent. The BAA establishes that the vendor is legally obligated to protect PHI; due diligence is the work of verifying that the vendor can and will actually do so, and that nothing else in the agreement undercuts the protection the BAA promises. The pharmacy's job is to read the BAA and the surrounding contract together as a single document and to ask, of the whole, whether the patient's information is genuinely protected or merely nominally covered.

The Data Posture Questions

Underneath the legal layer is the practical reality of what actually happens to patient data inside the vendor's systems, and this is where due diligence gets specific. The questions are concrete, and a vendor serious about healthcare will have clear answers; a vendor that fumbles them is telling you their data posture is not built for PHI.

Where does the data go, and where does it live? When patient information enters the tool, where is it processed and where is it stored, including whether it leaves the country or passes through subcontractors and other vendors the primary vendor relies on. A vendor's subcontractors handle your PHI too, and the BAA's protections have to flow down to them, so a vendor who cannot tell you who their subprocessors are cannot tell you where your patients' data actually goes.

Is the data encrypted, in transit and at rest? Encryption in transit protects data moving between the pharmacy and the vendor; encryption at rest protects it sitting in the vendor's storage. Both are baseline expectations for PHI, and a vendor that hedges on either is below the floor.

Who can access the data, and is that access logged? Which of the vendor's employees can see patient data, under what controls, and does the system keep an audit trail of who accessed what, so that a later question about who saw a patient's information has an answer. Access without logging is access you cannot account for.

Is the data used to train the vendor's models? This is the clause from the opening, and it deserves its own scrutiny because it is both common and easy to miss. Many AI vendors, by default or by buried clause, use customer-submitted content to improve their models. For PHI this is usually unacceptable: it means patient information is being absorbed into a model the pharmacy cannot control, audit, or retrieve, and it may surface in ways no one can predict. The due-diligence requirement is explicit, written assurance that patient data is not used for model training, or that any such use is so tightly restricted and de-identified that it satisfies the pharmacy's obligations. A vague verbal "we don't really do that" is not an answer; the contract has to say it.

What happens to the data when the relationship ends? When the pharmacy stops using the tool, is the patient data returned or securely destroyed, on what timeline, and with what proof? Data that lingers in a former vendor's systems after the relationship ends is a continuing exposure the pharmacy is still responsible for, so the exit terms are part of the data posture, not an afterthought.

A useful way to hold all of these questions together is to remember that each one traces the same patient's information along a different segment of its journey: how it arrives, where it rests, who touches it, whether it is quietly repurposed, and how it leaves. A weakness anywhere on that path is a weakness in the whole, because the patient does not care which segment failed, only that their information was exposed. The pharmacy that maps the full path, from the moment a chart enters the tool to the moment the data is destroyed at the end of the contract, and confirms protection at every segment, has done the data-posture work; the pharmacy that confirms encryption but never asks about model training, or signs a BAA but never asks about subprocessors, has confirmed part of the path and assumed the rest, which is exactly how a confident pharmacy walks into an exposure it never saw.

Security Due Diligence: Evidence, Not Assurances

Beyond the specific data questions is the broader question of whether the vendor runs a credible security program at all, and here the discipline is to ask for evidence rather than accept assurances. Any vendor will tell you they take security seriously; the ones who actually do can show you. The standard forms of evidence a healthcare buyer should expect include recognized third-party security attestations and audits, which demonstrate that an independent party has examined the vendor's controls rather than the vendor simply asserting them. A vendor that has invested in independent verification of its security is signaling a maturity that matters when the data at stake is your patients' health information.

The questions to press on include how the vendor handles a breach: is there a defined incident-response process, and a contractual commitment to notify the pharmacy promptly if patient data is exposed, within a timeframe that lets the pharmacy meet its own breach-notification obligations? Because the pharmacy's HIPAA duties include notifying when a breach occurs, a vendor whose breach-notification terms are vague or slow leaves the pharmacy unable to meet its own legal clock. Ask too about how the vendor manages access internally, how it vets its own staff, and how it handles the security of the subprocessors it relies on, because a vendor is only as secure as the weakest party it shares your data with. The throughline of security due diligence is to convert "trust us" into "show us," because in PHI handling the difference between a vendor that has security and a vendor that talks about security is the difference between a protected pharmacy and a pharmacy that will discover the gap during a breach.

Reading the Contract as the Real Product

The lesson of the opening story is that the contract, not the demo, is where the pharmacy's actual obligations and exposures live, and yet the contract is the part most often skimmed. The model-training clause that nearly slipped through was not hidden in bad faith; it was simply on page nineteen, in the kind of dense terms that everyone signs and few read. The discipline of due diligence is to treat the full contract, the BAA, the data-processing terms, the security exhibit, the terms of service, as a single object that has to be read together and read completely, because a protective BAA can be undercut by a permissive clause elsewhere, and the protection the pharmacy thinks it has is only the protection the whole document actually provides.

This is where clinical, security, privacy, and legal review have to operate as one process rather than as a relay race in which each team looks only at its own section and assumes someone else caught the rest. The clinical team that loves the tool may not read the data-processing terms; the legal team that reads the terms may not understand that "content submitted through the service" means patient charts; the security team may verify encryption while missing the training clause. The gap the opening pharmacy nearly fell into lives precisely in the seams between these reviews, and closing it requires that someone hold the whole picture and ask the integrating question: across the entire agreement, is our patients' information protected, and have we preserved every obligation HIPAA places on us rather than signed any of it away? The contract is not the formality that follows the real decision. For PHI, the contract is the real decision, because it determines whether the tool the clinical team chose is one the pharmacy is actually allowed and able to use.

Bringing It Together: One Integrated Decision

The three lessons of this chapter compose into a single decision rather than three separate gates. Vendor evaluation establishes whether the tool produces verifiable, safe clinical output on your real data. The proof-of-concept with a safety gate establishes whether it performs to a pre-committed safety standard at scale. And vendor due diligence establishes whether the pharmacy can use the tool without breaching its duty to protect patient information. A tool has to pass all three, and the order in which the answers arrive does not change the rule that any single failure ends the consideration. A tool that is clinically excellent and contractually unacceptable does not get adopted, the same way a tool that is contractually clean but clinically unsafe does not, because both routes end at the same place: a patient harmed by a tool the pharmacy chose.

What ties them together is the obligation that never leaves the pharmacy. Speed is the prize, the collapse of PA turnaround from roughly twenty-five minutes to about five is real and worth pursuing, but it is the prize only for a tool that is safe, grounded, and bound to protect the patient's information, and verifying all three before adoption is what separates a pharmacy that captures AI's value from one that imports AI's risks. Due diligence is the unglamorous half of that verification, the half with no demo and no time-savings number, and it is exactly the half that the new URAC Health Care AI Accreditation, with its track for AI users, expects a pharmacy to have done and documented. The director who read to page nineteen was doing the defining work of an AI pharmacy strategist: making sure that the tool the pharmacy was about to trust with its patients was one the pharmacy could trust with its patients, in every sense the law and the patient require, before a single chart ever entered it.

Key Takeaways

• The duty to protect protected health information (PHI) under HIPAA does not transfer to the vendor; the pharmacy remains a covered entity responsible for its own obligations, including the duty to have chosen a vendor that can actually protect the data, so a vendor breach is still the pharmacy's problem.
• Due diligence asks a different question than clinical evaluation: not whether the tool is good, but whether the pharmacy is permitted and able to protect patients while using it, and a no to that question ends the conversation regardless of how well the tool performs.
• A business associate agreement (BAA), the contract legally binding a PHI-handling vendor to protect it, is mandatory: no BAA means the tool cannot lawfully receive patient information, which disqualifies many consumer and general-purpose AI tools outright.
• The BAA is the floor, not the ceiling: a signed BAA can coexist with weak encryption, unclear data location, or a clause elsewhere that permits the model-training use the BAA was meant to prevent, so the BAA and the full contract must be read together as one document.
• The data-posture questions are concrete: where the data is processed and stored (including subprocessors), whether it is encrypted in transit and at rest, who can access it and whether access is logged, whether it is used to train the vendor's models, and what happens to it when the relationship ends.
• The model-training clause deserves specific scrutiny: many vendors use customer-submitted content to improve their models by default, which for PHI is usually unacceptable, and the requirement is explicit written assurance in the contract, not a vague verbal reassurance.
• Security due diligence demands evidence, not assurances: independent third-party security attestations, a defined incident-response and breach-notification process fast enough for the pharmacy to meet its own legal clock, and accountability for the subprocessors the vendor shares data with.
• The contract is the real product for PHI, not a formality after the decision; clinical, security, privacy, and legal review must operate as one process so the seams between them do not hide a permissive clause, and the three chapter gates (clinical evaluation, the safety-gate PoC, and due diligence) compose into one decision where any single failure ends adoption.