HIPAA is not a legal checkbox handled after launch — it decides what you can log in analytics, cache on-device, write into an email footer, or send to a third-party pixel. Product teams who treat it as day-one architecture ship faster than those who bolt it on during a compliance review.
Quick answer: HIPAA governs Protected Health Information (PHI) held by covered entities and their business associates. The minimum-necessary standard means every field you log, store, or transmit needs a named business justification — not just a technical convenience.
What HIPAA Actually Controls: PHI, Covered Entities, and Business Associates
HIPAA applies to two kinds of organizations — covered entities (providers, health plans, clearinghouses) and their business associates (any vendor that creates, receives, maintains, or transmits PHI on an entity's behalf) — and it protects specific identifiers tied to health information, not health data as a general concept.
Most product teams get this backwards. They assume "we handle health information" is the trigger. It isn't. The trigger is (1) who you are under the law, and (2) whether the data in question actually meets the technical definition of PHI at all.
Protected Health Information (PHI) is individually identifiable health information tied to one of 18 identifier categories defined under the Safe Harbor de-identification standard (45 CFR § 164.514(b)(2)) — names, dates more specific than year, geographic subdivisions smaller than a state, device identifiers, and more. Strip all 18, or get a qualified statistician's expert determination, and the data legally stops being PHI. Redact just the name and leave a ZIP+4 and a visit date, and it's still PHI.
| Role | Definition | Typical Example | HIPAA Obligation |
|---|---|---|---|
| Covered entity | Provider, health plan, or clearinghouse that transmits health info electronically for standard transactions | Hospital system, health insurer, telehealth clinic | Full Privacy and Security Rule compliance |
| Business associate | Vendor that creates, receives, maintains, or transmits PHI on a covered entity's behalf | Scheduling SaaS, cloud host, billing platform, analytics processor | Signed BAA, equivalent safeguards, breach reporting |
| Neither (direct-to-consumer) | Health app selling directly to consumers with no covered-entity relationship | General wellness or symptom-tracking app | No HIPAA obligation, but likely covered by the FTC Health Breach Notification Rule |
For most healthtech PMs building B2B or B2B2C software — a scheduling tool sold into a hospital, an analytics layer sold into a health plan — you are the business associate. That means a signed BAA needs to exist before a single PHI record touches your system, not after your first enterprise deal closes. For the full regulatory landscape beyond HIPAA — state privacy laws, FDA software-as-a-medical-device thresholds, interoperability rules — our Healthtech Complete Guide covers the surrounding terrain this article assumes.
The Minimum-Necessary Principle: Your Best Product Design Filter
The minimum-necessary standard (45 CFR §§ 164.502(b), 164.514(d)) requires covered entities and business associates to limit PHI use, disclosure, and requests to the smallest amount reasonably needed for the task at hand — which, translated into product terms, means every field in your schema, log line, and event payload needs a named business reason to exist.
According to HHS's Office for Civil Rights, minimum necessary doesn't apply to disclosures between providers for treatment — a doctor can pull a full chart. It does apply to nearly everything else: administrative workflows, marketing, research, and, critically for PMs, analytics and internal tooling. That's exactly the layer most product teams touch first, and exactly the layer where HIPAA training rarely reaches.
Turn it into four questions before any field ships:
- Does this need to be identifiable, or would a bucketed or derived value do the same job? ("Age 34" versus "age band 30–39.")
- Who actually needs to see this field, and can role-based access enforce that instead of "everyone with a login"?
- Does this need to persist, or can it be computed at request time and discarded?
- Does this need to leave your first-party system at all — to a log aggregator, an analytics SDK, an ad platform?
This is the same instinct that governs regulated fintech products, where GLBA and PCI DSS impose comparable need-to-know limits on transaction and account data; our fintech complete guide walks through that parallel constraint in more detail. The pattern repeats across regulated industries: the specific rule changes, the product discipline it demands does not.
Before and After: Rewriting an Event-Tracking Spec for HIPAA
A naive event-tracking spec logs whatever the SDK captures by default — email addresses, free-text fields, diagnosis-adjacent categories — and pipes it straight to third-party analytics tools with no BAA in place. A minimum-necessary spec buckets values, pseudonymizes identifiers, and keeps anything PHI-adjacent inside a BAA-covered warehouse only.
The naive version
event: appointment_scheduled
properties:
user_email: "jane.doe@email.com"
full_name: "Jane Doe"
appointment_reason: "follow-up, depression medication adjustment"
physician_name: "Dr. Amara Osei"
clinic_address: "123 Main St, Suite 4"
device_advertising_id: "IDFA-xxxx"
destinations: Segment -> Amplitude -> Google Analytics -> Meta Pixel
Every property here is either a direct identifier or, combined with appointment_reason, close enough to a diagnosis to count as PHI. Routing it to Google Analytics or a Meta Pixel with no BAA turns a routine analytics call into a reportable disclosure.
The minimum-necessary version
event: appointment_scheduled
properties:
user_id_hash: "a91f3e...c2" # rotating pseudonymous ID
appointment_category: "behavioral_health" # bucketed, not diagnosis-specific
scheduling_channel: "self_service_app"
days_until_appointment: 6
clinic_region: "northeast" # state-level, not street address
destinations: internal analytics warehouse only (BAA in place, no ad pixels)
| Field | Naive Approach | Minimum-Necessary Approach | Why It Matters |
|---|---|---|---|
| Identity | Email or full name | Rotating pseudonymous hash | Removes a direct HIPAA identifier from every downstream tool |
| Reason for visit | Free-text or diagnosis-linked string | Bucketed category (behavioral_health, primary_care) | Bucketing below diagnosis-level granularity is the difference between an insight and a disclosure |
| Location | Street address | State or region only | Address is one of the 18 Safe Harbor identifiers; region typically isn't |
| Destination | Ad and marketing pixels | First-party, BAA-covered warehouse | No BAA, no PHI — full stop, regardless of how useful the signal is |
| Retention | Indefinite, default SDK settings | Defined TTL tied to the business need | Minimum necessary applies to retention, not just collection |
Beyond the schema, three practices catch most teams off guard:
- Session-replay and heatmap tools (the
FullStory/Hotjarcategory) capture DOM content by default, including anything rendered on an authenticated PHI-bearing screen. Treat them as PHI recipients requiring a BAA, or exclude them from those screens entirely. - Error-monitoring stack traces often serialize request payloads, including query params carrying patient IDs. A crash report is still a disclosure if it contains PHI.
- Free-text fields ("reason for visit," "notes to provider") are the single most common way diagnosis-adjacent information leaks into analytics that were only ever supposed to track behavior, not health status.
HIPAA Doesn't Stop at the App: Growth Loops, Marketing Email, and Third-Party Trackers
Growth tactics that are default-safe in consumer SaaS — retargeting pixels, lookalike audiences, personalized win-back emails — become compliance incidents the moment PHI (an appointment type, a diagnosis-linked page view) reaches an ad platform. That's precisely what the FTC alleged against GoodRx and BetterHelp in 2023.
Neither company was a HIPAA covered entity. Both got penalized anyway. GoodRx and BetterHelp each settled with the FTC — reported penalties in the range of $1.5 million and $7.8 million respectively — for sharing health-related browsing and intake data with Meta and Google ad products without adequate user consent, under the FTC Health Breach Notification Rule. The lesson for PMs: falling outside HIPAA's definition of a covered entity does not mean falling outside health-data regulation.
For teams that are covered entities or business associates, HHS's Office for Civil Rights went further with a December 2022 bulletin stating that tracking technologies — analytics scripts, session-replay tools, ad pixels — embedded on any page or app screen that can transmit PHI require a BAA with the vendor, full stop.
The guidance drew pushback from hospital groups over how broadly it defines a "tracking technology," and parts of it have faced legal challenges since, but the underlying expectation hasn't moved: if a third-party script can see PHI, treat it as a business associate or remove it from that surface.
Two contrasts are useful here:
- Standard ecommerce growth playbooks — cart-abandonment emails referencing exactly what a shopper viewed, retargeting based on browsing history — read completely differently when the "cart" is a prescription refill or a therapy booking. Our ecommerce and retail complete guide covers the baseline growth pattern healthtech PMs must deliberately deviate from.
- For the mechanics of how tracking pixels, conversion APIs, and ad-platform matching actually work under the hood — useful context for knowing exactly what a script can and can't see — see our martech and adtech complete guide.
Practical rule of thumb: no PHI in marketing email personalization, ever, even inside a first-party ESP. "We noticed you have an upcoming cardiology appointment" is a compelling subject line and a HIPAA problem in the same sentence.
Building HIPAA Into the Product Development Lifecycle
HIPAA compliance is cheapest when it's a sprint-planning decision, not a pre-launch security gate: BAAs signed before any vendor touches PHI, logging and caching rules defined per data class, and role-based permission models built before user story one — not retrofitted after a security review flags them.
Vendor selection is a compliance decision, not a procurement afterthought
Every subprocessor that can touch PHI — cloud hosting, error monitoring, customer support tooling, even an LLM vendor powering a chatbot feature — needs either a signed BAA or a guarantee that PHI never reaches it. NIST SP 800-66, the implementation guide for the HIPAA Security Rule, is a genuinely useful reference for PMs scoping which technical safeguards (access control, audit logging, encryption at rest and in transit) a given vendor decision implicates.
Minimum necessary changes by role, not just by feature flag
A clinician view and a patient view of the same record legitimately need different fields visible, logged, and cached — a permission model that hardcodes "logged in equals full access" fails minimum necessary by design. This is where the standard intersects directly with interface design; our guide to clinician vs. patient dual-user design covers how those permission models should differ by role rather than by a single feature toggle.
The cost asymmetry is real
According to IBM's annual Cost of a Data Breach Report, healthcare has been the costliest industry per breach for well over a decade running, with average costs exceeding $10 million in recent editions — consistently the highest of any sector tracked. That gap exists because health-data breaches trigger regulatory penalties, breach-notification costs, and reputational damage simultaneously. "Ship now, add compliance later" is a false economy specifically in this category, more so than in most adjacent regulated domains.
Product teams arriving from edtech often underestimate this gap. FERPA imposes a real but narrower version of the same constraint on student education records; our edtech complete guide is a useful comparison point for understanding how much further HIPAA's minimum-necessary standard reaches into everyday product analytics, support tooling, and growth marketing than its closest analog in another regulated vertical.
Capturing the "No" So It Survives the Next Roadmap Review
The hardest HIPAA calls aren't the obvious ones — nobody proposes emailing diagnosis codes to a marketing list on purpose. They're the tempting, half-good ideas: a push notification that references why an appointment matters, an onboarding flow that pre-fills health history from a partner API to cut friction. Killing one of these for minimum-necessary reasons is the right call, and also the fastest way to create a gap in institutional memory.
Six months later, a new PM or a new exec asks why the product doesn't do the obviously-better thing, and nobody remembers the compliance conversation that killed it the first time. This is less a documentation problem than a capture problem — the reasoning has to survive being said out loud in a meeting and never written down. That's the honest, narrow case for building the habit into a tool rather than a wiki page nobody opens.
Key Takeaways
- HIPAA applies to PHI held by covered entities and business associates — know which one your product is before a single subprocessor contract is signed.
- Minimum necessary (
45 CFR §§ 164.502(b), 164.514(d)) is a design filter, not just a legal test: apply it to every schema field, log line, and event property. - Analytics is usually where HIPAA gets violated first, and usually by accident — default SDK capture and free-text fields are the most common leaks.
- Growth marketing is not exempt:
GoodRxandBetterHelp's FTC settlements show even non-covered health apps face real penalties for sharing data with ad platforms. - Third-party trackers (
Google Analytics,Meta Pixel, session-replay tools) need a BAA or need to be removed from any PHI-bearing surface — OCR has said so explicitly since December 2022. - Compliance is cheaper as architecture decided in sprint planning than as a remediation project after a near-miss, consistent with IBM's long-running data on healthcare breach costs.
- Document the reasoning behind features you cut for HIPAA reasons — the same idea will resurface, and "we already checked" needs evidence, not memory.
Frequently Asked Questions
Does HIPAA apply to my health app if I'm not a hospital or insurer?
Only if you meet the legal definition of a covered entity or business associate. Direct-to-consumer wellness, symptom-tracking, or fitness apps without a healthcare-provider relationship often fall outside HIPAA entirely — but as GoodRx and BetterHelp learned, they're likely still regulated by the FTC's Health Breach Notification Rule, which covers many of the same disclosure scenarios.
What counts as PHI versus just "health-related data"?
PHI is health information combined with at least one of 18 identifier categories (name, precise dates, geographic detail smaller than a state, device IDs, and others) and held by a covered entity or business associate. Data stripped of all 18 identifiers under the Safe Harbor method, or cleared through an expert statistical determination, legally stops being PHI.
Can I use Google Analytics or a Meta Pixel on a HIPAA-covered product?
Only with a signed BAA in place and a verified guarantee that PHI never reaches the vendor — a bar OCR's December 2022 guidance made explicit and one that standard ad-pixel implementations rarely clear. Most healthtech teams solve this by keeping third-party trackers off any authenticated, PHI-bearing screen entirely rather than trying to configure around the risk.
Who's actually responsible for HIPAA compliance — legal, security, or product?
All three, but product usually decides the real exposure first, because product chooses what data gets collected, logged, and sent where, often before legal or security ever reviews the feature. That's exactly why minimum necessary needs to be a product habit built into specs, not a downstream audit finding.
What's the real difference between a BAA and a normal vendor contract?
A Business Associate Agreement is a specific HIPAA-required contract obligating a vendor that handles PHI to apply equivalent safeguards to the covered entity and to report breaches on defined timelines. A standard vendor contract, however strong its general security language, carries none of those specific legal obligations — which is why "they said they take security seriously" isn't a substitute for a signed BAA.