Grateful patient fundraising and HIPAA: what donor data can a hospital foundation use?

Yes, a hospital can fundraise from patients — HIPAA explicitly permits it, with a strictly limited set of data and a mandatory opt-out on every solicitation. The compliance question that actually sinks grateful patient programs isn’t “is this allowed?” It’s “can you prove which fields crossed from the clinical side to the foundation, and where the opt-out lives?” That’s not a legal problem. It’s a data-modeling problem, and it’s exactly the kind a common data model is built to solve.

Can a hospital use patient data for fundraising?

Under the HIPAA Privacy Rule’s fundraising provision (as amended by the 2013 Omnibus Rule), a covered entity may use — or share with its foundation — a specific, enumerated set of information for fundraising without patient authorization:

• Demographic and contact information (name, address, phone, email, age, gender)
• Dates of care
• General department of service (cardiology, not the diagnosis)
• Treating physician
• Outcome information
• Health insurance status

Everything else — diagnosis, treatment detail, clinical notes — requires the patient’s written authorization. And two obligations travel with the permitted data: every fundraising communication must carry a clear, conspicuous way to opt out, and an opt-out must actually stop future solicitations.

The boundary is a data-modeling problem

Picture the audit conversation. The question is never abstract: it’s show me the fields that crossed the wall, show me the opt-out record, show me that the opted-out patient received nothing after that date. A foundation whose database is a CRM export enriched by hand cannot answer it. A foundation whose data maps to a neutral, enumerable shape can, because the boundary is written down:

• The constituent is not the patient record. The foundation holds a constituent — a relationship record built from the six permitted field families — never a copy of the chart. What crossed the wall is an enumerable list, not a habit.
• Consent is a first-class object, not a checkbox. The model carries consent as its own domain: what may be sent, to whom, on what basis, revoked when. An opt-out is a dated record with scope — which is what “honor the opt-out” means in practice.
• The gift officer’s world is already modeled. Portfolios, moves management, and interactions — the daily work of a grateful patient program — are core advancement domains, proven in the beta today.
• Privacy requests have a home. Retention rules and data-subject requests live in a privacy domain, so “delete this person” is an operation, not an archaeology project.

Why a common model, and not just a careful one?

A hospital foundation could enforce all of this with in-house discipline. But the moment the data is described in one vendor’s proprietary shape, the boundary is only as durable as that vendor relationship — and healthcare philanthropy changes CRMs like everyone else. Mapping to a neutral shape makes the consent and privacy structures portable: the opt-out survives the migration, because it isn’t a custom field, it’s part of the spine. The same logic behind donor data privacy under GDPR and CCPA applies here with higher stakes: regulated data deserves a shape no vendor owns.

Honest maturity note: consent, privacy, and portfolio domains are in the model now — the current shape is in the open acdm repository. The healthcare-specific refinements (department-of-service fields, grateful patient program structures) are precisely what a hospital foundation in the beta would help shape.

This post is part of a series on the model beyond its first adopters — the umbrella view is who is the Advancement Common Data Model for?

For how the privacy-first foundation works, see How It Works; for the standard itself, The Standard (ACDM).

ACDM is open and early; treat current releases as drafts. Examples use synthetic data. This post is not legal advice.