Does a Medical Practice Need a Do Not Sell or Share Link?

Ask a practice owner whether their site needs a Do Not Sell link and the answer arrives before the question finishes: we do not sell patient data. That statement is almost always true, it is said in good faith, and it does not answer the question, because the statutes did not define the word the way ordinary usage does.

This is one of the few places in privacy law where the everyday meaning of a term and its legal meaning diverge far enough to produce confident, sincere errors. Working through the definition takes ten minutes and changes what a practice concludes about its own website.

What the Do Not Sell link actually signals

The link is not a promise. It is a mechanism, and its presence is an admission that something within the definition is happening. That is why adding one defensively is not costless, and why omitting one when it is required is a visible, externally checkable failure.

California's framework, described by the California Attorney General, requires businesses that sell or share personal information to provide a clear and conspicuous link enabling consumers to opt out. The obligation attaches to the activity, not to the industry. A business that neither sells nor shares does not need the link and should not have one.

California then adds a second, separately defined activity: sharing, meaning disclosure to a third party for cross-context behavioural advertising. Sharing is regulated whether or not anything of value comes back at all. This is precisely why the required link reads "Do Not Sell or Share My Personal Information" rather than referring to sales alone.

Why "we do not sell data" is usually the wrong test

Set the definitions against what a typical practice website does.

An advertising pixel on a treatment page passes a persistent identifier, the page address and the visitor's IP address to a platform, which uses them to build and target audiences including audiences the practice will later advertise to. Nobody sent an invoice. Personal information was disclosed to a third party, and it was disclosed for cross-context behavioural advertising, which is the definition of sharing almost verbatim.

The other common defence is that the data is anonymous. It is worth being precise here, because the argument fails on a technicality that is not really a technicality: a persistent identifier is personal information when it is reasonably linkable to a person, and a large advertising platform receiving it generally holds what is needed to link it. The reasoning is worked through in what counts as PHI on a website, and it applies with equal force outside HIPAA.

A third defence deserves a mention because it is the most technically sophisticated and still does not land. Practices sometimes point out that they have signed the advertising platform's data processing terms, which designate the platform as a service provider acting on their instructions rather than as an independent third party. That designation genuinely matters, and it is the correct structure where it holds. It holds only while the platform actually confines itself to your instructions. A platform that also uses what it receives to improve its own models or to build audiences usable by other advertisers is not behaving as a service provider on that data, whatever the contract is called, and the analysis reverts.

The useful question to put to a vendor is therefore narrower than whether they will sign something. It is whether the specific data flow from your site is confined to your purposes, in writing, with the setting that enforces it identified by name. Vendors who can answer that will answer it quickly.

Where the HIPAA exemption leaves you

Every state privacy law contains a HIPAA-related exemption, and this is where practices reasonably expect to be released. Whether they are depends on which shape their state wrote.

An entity-level exemption excludes the covered entity itself, and where one applies the analysis genuinely ends. A data-level exemption excludes only protected health information as 45 CFR 160.103 defines it, and leaves everything else in scope.

The practical consequence is uncomfortable, because the population a data-level exemption fails to protect is exactly the population a website generates. People who browsed and never became patients are not patients, so nothing about them is PHI, so nothing about them is exempt. A practice with excellent digital marketing has a large number of these people, and they are the ones an advertising audience is built from.

Which shape applies is set state by state, and it is recorded per state in our California breakdown and its companions. This is the single most useful thing to check before concluding that being a covered entity settles the matter.

So does your practice need a Do Not Sell link?

Three questions, in order, and the first two dispose of most cases.

Does a state privacy law apply to you at all? Comprehensive privacy laws generally have thresholds based on revenue, records processed, or share of revenue derived from selling data. Many single-location practices fall below all of them. Note that the health data statutes discussed in consumer health data under state law largely do not have such thresholds, so a practice can be below the comprehensive-law floor and squarely inside a health data statute.

Are you selling or sharing as defined? Not as understood. If advertising tags on your pages pass identifiers to platforms for audience building, assume yes until someone demonstrates otherwise from a network log.

Does your state's HIPAA exemption reach the data in question? Entity-level, and you are likely done. Data-level, and your non-patient website data is still in scope.

If the answers put you in scope, the link is the visible part and not the hard part. The harder requirement in California is honouring a recognised opt-out preference signal such as Global Privacy Control, which arrives in the browser request itself. A visitor who has enabled it has opted out before your page rendered, without clicking anything, and a link cannot satisfy an obligation to respect a signal that was already sent.

What to do instead of guessing

The reason this question stays unresolved in most practices is that it is being answered from memory rather than from evidence. Nobody knows what the tags are doing, so the discussion stays at the level of intentions, and intentions are genuinely good.

Start from the network log. Get the list of third parties receiving data from your pages, then ask what each receives and why. That list is the input every one of the three questions above needs, and it is usually the first time anyone has seen it.

Then consider what a default of nothing does to the analysis. If non-essential tags are held until a visitor agrees, the sharing that triggers these obligations does not happen by default, the opt-out signal is honoured by construction because nothing was going to fire anyway, and the record of what each visitor chose exists if anyone asks. That is what consent gating produces, and combined with state privacy detection it means the right notice reaches the right visitor without maintaining a decision tree per state.

One caution to close on. Do not add a Do Not Sell link defensively because it seems safer. The link asserts that you sell or share, and it commits you to honouring requests made through it. Publishing one you cannot service is worse than not publishing it, and it is the kind of inconsistency that reads badly precisely when someone is looking.

The mirror image of that caution is worth stating too, because practices tend to make one error or the other. A privacy policy that flatly declares you never sell or share personal information, published on a site whose pages pass identifiers to three advertising platforms, is a statement that can be checked against observable behaviour by anyone in about two minutes. Under most state regimes an inaccurate privacy disclosure is independently actionable as a deceptive practice, entirely separately from whatever the underlying sharing rules require. That means the policy language can create exposure that the sharing itself would not have.

The uncomfortable conclusion is that the safest position is not the most reassuring language. It is language that matches what a network log shows, which requires knowing what the log shows before writing the policy. Practices almost always do it in the opposite order.