Hospital Foundations: Grateful Patient Programs Within HIPAA Limits

What the HIPAA Fundraising Provision Actually Permits

The governing text is 45 CFR 164.514(f). It says that a covered entity, such as a hospital, "may use, or disclose to a business associate or to an institutionally related foundation," certain protected health information "for the purpose of raising funds for its own benefit, without an authorization." Three parts of that sentence matter. The permission belongs to the covered entity, meaning the hospital or health system, not the foundation. The fundraising must be for the covered entity's own benefit, so a hospital cannot share patient lists with an unrelated charity, even a worthy one. And only the listed categories qualify.

The list is short and specific. The original Privacy Rule allowed only demographics and dates of care. The 2013 Omnibus Rule, which implemented the HITECH Act, expanded it after hospitals explained that they could not target appeals sensibly or avoid soliciting patients who had poor outcomes. In the 2013 final rule preamble, HHS explained that it added department of service, treating physician, and outcome information so that covered entities could better direct their communications and screen out patients who should not receive a solicitation. HHS also emphasized that the minimum necessary standard still applies. You may use these categories, but only as much of them as the fundraising purpose requires.

Notice what is not on the list: diagnosis, procedure codes, medications, test results, clinical notes, and the nature of the condition treated. A foundation may know that a patient was seen in the cardiology department by a particular cardiologist on certain dates and that the outcome was good. It may not, under this permission, know that the patient had a triple bypass. That distinction drives almost every practical decision in a compliant program, and it becomes especially important once AI enters the picture, as we discuss later.

Separately Incorporated Foundations and Business Associate Agreements

Many hospital foundations are separate 501(c)(3) organizations rather than departments inside the hospital. That structure matters under HIPAA. A foundation is generally not a covered entity in its own right, because it does not provide or bill for health care. It receives PHI because the covered entity is permitted to disclose it. The rule names two kinds of recipients. An "institutionally related foundation" is, as HHS has described it, a charitable foundation whose charter explicitly links its charitable purpose to supporting the covered entity. A foundation that raises money for a range of unrelated causes does not qualify. The other route is a business associate, meaning a person or organization that performs a function on the hospital's behalf involving PHI, under a written business associate agreement, or BAA.

Structures vary, and so does practice. In some systems the foundation receives PHI as an institutionally related foundation. In others, the hospital treats the foundation as a business associate and signs a BAA, often because the foundation also performs services for the hospital or because the hospital wants contractual control over safeguards, breach notification, and permitted uses. Many hospitals put a written data sharing agreement in place either way. Whatever the structure, the foundation's communications on the hospital's behalf are fundraising communications under the rule, so the foundation must include opt-outs and honor the suppression list exactly as the hospital would.

The BAA question gets sharper one level down. Your wealth screening vendor, your direct mail house, your email platform, your CRM host, and any AI service that receives patient-derived lists are handling PHI. If they receive it, they generally need to be business associates of the hospital, or subcontractors of a business associate with their own downstream agreements. HHS guidance on cloud computing makes clear that a cloud service provider that creates, receives, maintains, or transmits electronic PHI is a business associate even if it never looks at the data. A foundation that signs up for a new analytics tool with a credit card and uploads a discharge file has almost certainly created a compliance problem, regardless of how good the tool is.

A useful practice is a single inventory, maintained jointly with the hospital's privacy office, of every system and vendor that touches patient-derived fundraising data, with the agreement that covers each. Before any new tool goes into use, it gets added to that inventory and reviewed. Our AI vendor security evaluation guide provides a framework for that review.

Where HIPAA Is Not the Strictest Rule: Part 2 and State Law

HIPAA sets a federal minimum. Where another federal law or a state law is more protective of patient privacy, the stricter rule generally applies alongside it. For grateful patient programs, two areas come up again and again.

The first is substance use disorder treatment records covered by 42 CFR Part 2, which applies to federally assisted programs that hold themselves out as providing SUD diagnosis, treatment, or referral. HHS's February 2024 final rule aligned Part 2 more closely with HIPAA in several ways, but on fundraising it went its own direction. According to the HHS fact sheet on the Part 2 final rule, the rule creates a new right for patients to opt out of receiving fundraising communications, and a covered entity that intends to use Part 2 records for its own fundraising must first give patients a clear and conspicuous opportunity to opt out. That is an opt-out before use, not just an opt-out in each communication. Many health systems simply exclude Part 2 program patients from fundraising extracts entirely, which is the simplest way to avoid errors. Covered entities that handle Part 2 records also had to update their Notice of Privacy Practices, with a compliance date of February 16, 2026.

The second is state law. Many states have specific confidentiality statutes for HIV and AIDS information, mental health treatment records, genetic testing results, and reproductive health services, and some of those statutes limit disclosure more tightly than HIPAA does. New York's HIV confidentiality law in Public Health Law Article 27-F is one frequently cited example. California's Confidentiality of Medical Information Act is another state framework that foundations in that state need to consider. Because these laws vary so much, the practical answer for most foundations is conservative extract rules: work with the privacy office to exclude encounters from sensitive service lines, such as behavioral health, infectious disease clinics, reproductive health, and addiction medicine, from routine fundraising files unless counsel has specifically approved their inclusion. For more on how state law layers onto federal rules, see our article on state privacy laws and AI.

Behavioral health deserves a plain operational stance. The department of service field can reveal that a patient was seen in psychiatry, and the treating physician field can reveal the same thing if the physician is a psychiatrist. Even when a particular state does not prohibit the use, most foundations decide that soliciting patients on the basis of a behavioral health encounter is not worth the risk to trust. Keep those encounters out of fundraising extracts by default, and if a behavioral health service line has its own philanthropic priorities, raise money for it through community, board, and general hospital channels rather than patient lists.

Where AI Fits in a Grateful Patient Program

With the rules in place, AI can make a grateful patient program substantially more effective. The key is to design each use around the data it actually needs, inside agreements that cover the vendors involved.

Wealth screening of patient lists

Wealth screening is the oldest analytical tool in healthcare philanthropy, and most major screening vendors now layer machine learning onto public records. For a grateful patient program, a screening file should contain only what matching requires: name, address, and perhaps age or date of birth. Department, physician, and outcome fields are not needed to find property records, so they should not be sent. The vendor must be under a BAA, and the contract should specify that patient data will not be retained beyond the engagement or used to train the vendor's models for other clients. Our guide to AI donor research and prospect discovery covers screening methods in more depth.

Prioritizing prospects for gift officers

After screening, the challenge is triage. A mid-sized hospital may produce tens of thousands of new patient records a year, and a small major gifts team can meaningfully engage only a few hundred prospects. Scoring models can combine capacity indicators, prior giving to the foundation, engagement signals such as event attendance, and permitted fields such as recency of care to rank who a gift officer should research first. Keep these models simple and explainable. A gift officer should be able to see why a prospect ranked highly, and your privacy officer should be able to confirm that no impermissible clinical field fed the score. Our article on AI donor scoring models explains how to build and validate these.

Physician and clinician partnership programs

Many hospitals run physician partnership or referral programs, in which clinicians who choose to participate can let the foundation know that a patient has expressed interest in giving back. AI can support the administrative side: routing referral forms, reminding gift officers to follow up, preparing short summaries of a physician's program priorities so gift officers can speak knowledgeably about them, and drafting thank-you notes to referring physicians. It should not be used to mine clinician notes for signals of gratitude, or to prompt physicians during clinical workflows to identify donors. Both would pull clinical information into fundraising in ways the rule and the ethics guidance do not support.

Drafting stewardship and impact communications

Stewardship is where generative AI is most useful and least risky, provided you keep PHI out of the prompts. Impact reports about a new cardiac catheterization lab, fund updates for donors to a pediatric endowment, and thank-you letters for gifts to the nursing scholarship fund can all be drafted from program data and donor gift records without touching patient information. The foundation's donor records, gifts, and preferences are typically not PHI when the donor relationship is independent of care, but for grateful patient donors the line can blur, so the safe habit is to prompt with gift and program details only. For workflow ideas, see our guides to automated stewardship sequences and major gift proposal development.

Building a Program Your Privacy Officer Will Sign Off On

The foundations that run grateful patient programs well treat the hospital's privacy and compliance office as a design partner, not a gatekeeper to be persuaded at the end. Bring them in before choosing tools, show them the exact fields in each extract, and ask them to help write the policy. That collaboration usually produces a faster, more durable program than one built first and reviewed later.

A written grateful patient policy, approved by both the hospital and the foundation board, gives everyone a reference point. It should cover the data fields used, the exclusions applied, timing rules, the opt-out process, the clinician partnership guidelines, the approved vendor list, and the rules for AI use. It should also name who reviews new uses and how often the policy is revisited. Staff training should follow, including for volunteers who make calls and clinicians who participate in referral programs. If your foundation is earlier in its AI journey, our overview of AI for healthcare nonprofits provides broader context.