What your pharmacy and health apps actually share about you

The gap between HIPAA and the app on your phone

Most people assume anything health-related is covered by HIPAA, the US law that restricts how medical information gets shared. It isn’t. HIPAA applies to “covered entities”: your doctor’s office, your hospital, your health insurer, and the vendors those entities directly contract with to handle your records. It does not apply to the pharmacy loyalty app on your phone, the period tracker, the symptom checker, or the fitness app that also logs your medications. Those are consumer software products, and in the US they’re governed mostly by general consumer protection law and whatever the app’s own privacy policy says, not by medical privacy rules.

That gap matters because a lot of genuinely sensitive information flows through exactly those non-HIPAA apps. A pharmacy chain’s app, for instance, isn’t sending your prescription data to a hospital, it’s a retail company running a loyalty and refill product, and it can treat the data the way any retailer treats purchase history unless it has made specific promises not to.

What actually gets collected

Strip away the marketing language and most pharmacy and health apps collect three broad categories of data.

The first is what you tell the app directly: your name, date of birth, insurance info, the medications you’re refilling, symptoms you type into a checker, cycle dates in a period tracker, or workout and sleep data in a fitness app. This is the obvious stuff, and it’s usually covered somewhere in the privacy policy, even if nobody reads it.

The second is behavioral data collected by the software itself: which screens you open, how long you linger on a page about a specific condition, what you search for inside the app, push notification interactions, and location data if the app has permission to see it (which pharmacy apps often want, to find your nearest store). This layer is collected by analytics SDKs embedded in the app, tools like mobile analytics platforms or crash reporters that are standard in app development and that quietly report usage patterns back to the app maker and often to the SDK vendor too.

The third, and the one people underestimate, is inferred data. If you open a diabetes medication reminder every day, that’s a fairly strong signal you have diabetes, even if you never typed the word into a form. Ad tech companies specialize in this kind of inference: they don’t need you to declare a health condition if your app usage, browsing history, and purchase patterns already spell it out.

How the sharing actually happens

The mechanism isn’t usually a bulk sale of “medical records” to a shadowy buyer. It’s more mundane and more pervasive than that.

Advertising SDKs are the biggest pathway. When an app includes a software development kit from an ad network or analytics provider, that SDK runs inside the app and can send data directly to its own servers, separate from whatever the app developer intended. A pharmacy app built with a common analytics SDK is, by default, sending some slice of usage data to that SDK vendor, because that’s how the SDK is designed to work.

Data brokers are the second pathway. Some apps, particularly ones that are free and ad-supported, sell aggregated or semi-aggregated usage data to brokers, who combine it with data from dozens of other sources to build advertising profiles. Regulators in the US have taken enforcement action against health apps for exactly this, including cases where menstrual tracking data or mental health app usage ended up in ad targeting pipelines despite privacy policies implying otherwise. That pattern is the basis for several FTC actions over the past few years.

The third pathway is the pharmacy’s own marketing arm. Retail pharmacies run loyalty programs partly to build a purchase history they can use for their own targeted promotions, and partly because that purchase history has value to the retailer’s ad business, which sells targeted placements to other companies, including drug manufacturers, based on what customers have bought before. This is disclosed, generally, in the fine print of loyalty program terms, and it’s legal, because loyalty programs aren’t medical records in a legal sense even though the purchases themselves clearly are medically informative.

Why this matters even if you have nothing to hide

The usual dismissal, “I don’t care if someone knows I take blood pressure medication,” misses the actual risk model. The risk isn’t a single fact being known. It’s aggregation and downstream use you didn’t agree to and can’t see.

Health-inferred ad profiles get used for things like life insurance underwriting research, employment-adjacent risk scoring in some jurisdictions, and targeted advertising for things you’d rather not be targeted for, like predatory supplement companies or high-interest medical financing products aimed specifically at people whose data marks them as having a chronic condition. None of this requires anyone to “hack” anything. It’s the intended function of the ad targeting ecosystem operating on data you handed over through completely ordinary app use.

There’s also a reidentification risk with supposedly anonymized health data. Aggregated or “de-identified” datasets sold by brokers have repeatedly been shown, in academic research and in real incidents, to be reidentifiable when combined with other data sources, because health behavior combined with location and timing data is often unique enough to point back to one person.

What you can actually control

None of this means you need to go dark or stop using pharmacy apps, and no single step here makes you untraceable or fully private, because the app ecosystem and ad tech industry are built around collecting this data by default. What you can do is reduce the surface area.

Read the app’s data permissions before granting them, not after. Location access is the one worth scrutinizing hardest for pharmacy apps, since store-finder features usually work fine with permission granted only while the app is open, rather than always.

Use the web version instead of the app where one exists. Mobile apps typically embed more tracking SDKs than a browser session does, because a website is constrained by browser privacy controls and ad blockers in a way an app, which runs with its own permissions, is not.

Turn off ad personalization inside the app’s own settings if the option exists, and at the OS level (iOS’s “Allow Apps to Request to Track” and Android’s equivalent ad ID reset or opt-out). This doesn’t stop first-party data collection, but it does cut off a meaningful chunk of the cross-app profiling that turns your pharmacy usage into an ad-targeting input elsewhere.

Skip optional profile fields. Symptom checkers and fitness apps often ask for information beyond what the core function needs, like family medical history or detailed condition lists, that exists to enrich the profile rather than to make the tool work.

Consider whether you need the loyalty program at all. The discount is real, but so is the tradeoff. If a pharmacy chain has multiple physical locations you use interchangeably, a loyalty account tied to one identity builds a more detailed purchase history than paying without one.

A VPN doesn’t change any of this. It hides your network traffic’s origin from your ISP and from the sites you connect to, but it does nothing about data the app itself collects once you’re logged in and using it, since that data leaves your device with your consent through the app’s own channel. It’s a tool for a different threat model, not a fix for app-level data sharing.

The realistic takeaway

Pharmacy and health apps sit in a genuine regulatory gap, and the data they collect is more useful to advertisers and more sensitive to you than most other categories of app data. There isn’t a single setting that closes that gap completely, and anyone claiming there is one is oversimplifying. The practical move is to treat health apps with more scrutiny than you’d give a weather app, check permissions and ad settings deliberately, and accept that using the service at all means some data sharing happens, then work to minimize the parts you actually have control over.

If you want more explainers like this on how your data actually moves and what’s realistic to do about it, check out the rest of The Privacy Wire.