My Health My Data Act for AI-Built Apps: Why It Catches Apps That Are Not Health Apps

Short answer. Founders read the words "health data" and stop. They do not build a health app, so they move on. That is the wrong test. The Washington My Health My Data Act asks what your data says about a person's body, not what your product calls itself. It has no size bar at all. And its duties start in code: which columns you write, which third parties receive them, and how many separate yes clicks you collect before either happens.

This is the third piece in our US privacy series. The first covered the CCPA and the browser opt-out signal. The second covered the state laws outside California, where scope is a row count. This one covers the law that ignores counts entirely.

The law starts where HIPAA stops

Most founders have heard of HIPAA. Fewer know how narrow it is. It binds health plans, clearing houses, most care providers, and the firms that serve them. If you are none of those, it does not reach you. Our guide to the HIPAA gap covers that side.

The state Attorney General describes this Act as the first privacy law in the country built to protect health data that falls outside HIPAA. That is the design brief. It exists to cover the apps HIPAA leaves out.

There is a second point here that nearly all write-ups get wrong, and it matters most to firms that do handle medical records. Read the exemptions in section 19.373.100. The wording is precise. The chapter "does not apply to information that meets the definition of protected health information" under HIPAA. It lets off the information. It does not let off the firm.

There is no size test, and that is the whole point

Yesterday we looked at four state laws that count rows. This one does not count anything. Section 19.373.010 defines a regulated entity in two clauses. First, you do business in the state, or you make products or services aimed at people there. Second, you decide the purpose and the means of handling health data. That is it. There is no third clause about revenue. There is no floor.

The Act does use the term "small business". Read what it does. A small business is one that handles the health data of fewer than 100,000 people in a year. Or one that earns under half its gross income from that data and handles fewer than 25,000 people. Being small is not an exemption. It bought a later start date, and that date has gone. Larger firms had to comply from 31 March 2024. Small ones from 30 June 2024. Both dates are behind us.

One more clause widens the net. A consumer is a person who lives in the state, or a person whose health data is collected there. So a traveller loading your app in Seattle can pull you into scope. People acting in a job context are left out.

What counts as health data is wider than the name suggests

This is the part that catches teams off guard. The Act sets out thirteen kinds of health data. Some are obvious: a diagnosis, a treatment, a prescription. Others are not. Three are worth reading closely.

Measurements of a body count. The list covers bodily functions, vital signs, symptoms and measurements of them. Not a diagnosis. A measurement. A heart rate. A sleep score. A weight field. A step count. None of those needs a doctor to be in scope.

Where a person goes can count. The list covers precise location data that could reasonably point to someone trying to reach health services or supplies. Your app does not have to know why they went. It only has to know they were there.

Guesses count, and this one is the big one. The list closes with any data you handle in order to tie a person to the twelve kinds above, when that data is worked out from non-health data. The text names the methods: proxy, derived, inferred or emergent data, "including algorithms or machine learning". So the output of a model can be health data even when each input was plain.

The state's own guidance gives two worked examples, and they are more useful than any summary. Buying toilet paper or deodorant is not health data. But an app that tracks a person's digestion or perspiration is collecting it. And a store that gave shoppers a pregnancy score from their basket was holding health data, even though it inferred the lot.

Two more details close the gap. "Collect" is defined to include infer and derive, so working something out is collecting it. And personal data is defined to include a cookie ID, an IP address or a device ID. Nobody has to log in. A first visit is enough to start a record.

Precise location is the line most apps cross by accident

The Act puts a number on precise. It means data that fixes where a person is, to an accuracy of 1,750 feet or better. That is about 530 metres.

Readers of our piece on the other state laws will know that figure. Virginia uses the same one. That is the only good news here, because it means one schema rule answers both.

Now compare it to what your code actually stores. A browser location call returns a latitude and longitude good to a few metres. That is two orders of magnitude inside the line. A float pair in a table is precise location data. There is no argument to have.

The Act also bans one specific pattern outright. It defines a geofence as a virtual boundary of 2,000 feet or less around a place, built from GPS, cell towers, wifi or any other way of locating someone. The state's own guidance says the law makes it unlawful to use a geofence around a place that provides health care. Note the units. Two thousand feet is close to a third of a mile. A radius you set for a delivery zone, an ad audience or a "near me" feature can land on a clinic when nobody meant it to.

Consent is two consents, not one

Section 19.373.030 splits the duty in a way most consent tools do not. You may collect health data with consent for a named purpose, or where you need it to give the person the thing they asked for. Fine so far. Then read the next line. You may share it only with consent "separate and distinct from the consent obtained to collect".

Two yes clicks. One to hold it. A second to pass it on. A single tick box cannot do both jobs.

The request itself is specified too. It must clearly say four things: the kinds of data, the purpose and the exact ways it will be used, the kinds of firms you share with, and how the person can take the yes back later.

The Act then rules out three ways of getting a yes. It does not count if it comes bundled inside a broad terms-of-use agreement. It does not count from someone hovering over, muting, pausing or closing a piece of content. And it does not count if you used a "deceptive design", which the Act defines as an interface built to wear down a person's ability to choose.

That last one has a plain reading for anyone shipping a banner. If reject takes three clicks and accept takes one, you have a design problem before you have a legal one. We walk through the code-level version of this in our piece on tracking scripts that fire before a user says yes. The usual failure is not the wording. It is that the tags load on page one and the banner is decoration.

The policy is its own file, and "home page" is not just your home page

Here is the requirement an outside scan can actually see, which makes it the one to fix first.

Section 19.373.020 says you must keep a health data policy that clearly sets out five things: the kinds of data you collect and why, where you get it from, the kinds you share, a list of the kinds of third parties and the named affiliates you share with, and how a person exercises their rights.

Then it says you must prominently publish a link to it on your home page. The state's guidance adds two terms that are easy to miss. The link must be its own, separate and distinct. And the policy "may not contain additional information not required" under the Act. So folding it into your main privacy page fails twice over. It is not a separate link, and it carries extra text.

Now the detail almost nobody implements. The Act defines "home page" to mean the front page of a site and any web page where personal data is collected. For an app, it means the store listing and a link inside the app itself, from the settings or about screen.

Two more lines in the same section bite later. You may not collect, use or share a kind of data your policy does not name, or for a purpose it does not name, without first disclosing it and getting a fresh yes. And you breach the Act if you sign a contract with a processor to handle the data in a way your own policy does not match.

That last one is a paperwork trap with a technical fix. You cannot check it without a list of what you hold and who touches it. If you have never written that list, start there. Our guide to the record of processing builds it once in a form you can reuse for each of these laws.

Selling needs a signed authorisation, not a setting

Sharing needs consent. Selling is a second act with a heavier form. It is unlawful to sell health data, or offer to, without first getting a valid authorisation from the person. That is a signed form, not a toggle.

The state's guidance adds a duty that will outlast most startups: where a person signs off on a sale, both the seller and the buyer must keep a copy of that form for six years. The same guidance explains how to square that with a later delete request. You may redact the part naming the data sold and keep the rest.

Note what that means for your delete path. A delete request here reaches archived and backup systems. So "we removed the row from the live table" is not the same as done. If delete is a weak point for you, our piece on erasure requests covers the engineering, which is the same work whichever law asks.

Why the enforcement shape is different

Each state law in our last piece is enforced by the state alone. Colorado says so plainly in its own guidance: no private right to sue. This Act is built the other way, and the wording is worth quoting because the mechanism is unusual.

Section 19.373.090 does not create a penalty. It reclassifies. The legislature finds the practices covered by the chapter are "matters vitally affecting the public interest" for the purpose of the state Consumer Protection Act. A violation "is an unfair or deceptive act in trade or commerce and an unfair method of competition" under that Act.

So the Act borrows another law's enforcement. And the state's own guidance spells out what that means: each breach of it is in itself a breach of the Consumer Protection Act, "which is enforced by the Attorney General as well as through private action".

Be careful with what follows from that, because this is where a lot of writing on the topic overreaches. The statute routes violations into a law that private parties can use. It does not itself set damages, and how courts apply it here is not settled. We are not going to guess at that. What we will say is the part that changes engineering: with most privacy laws, one regulator decides whether your product is worth a look. Here, that is not the only route.

Six checks you can run today

None of these needs a lawyer. All of them need someone who can read your code.

1. Grep your schema for coordinates. Look for latitude, longitude, lat, lng, geo, coords. Any float pair from a device is precise location data. Decide whether you need it at all. Rounding to a city is the cheapest fix there is.

2. List each field that measures a body. Weight, steps, sleep, heart rate, cycle dates, mood scores, symptom logs, food diaries. Write the list down. It is usually longer than the team expects.

3. List each score your model writes back. Any column your system fills in that sorts people by habit, risk or condition. If a doctor would recognise the grouping, treat it as health data.

4. Open the network tab and watch. Load a page that carries one of those fields. Which third parties get a request? Tracking, session replay, ad tags and error trackers all see more than teams assume. Session replay is the worst offender because it captures form fields by default.

5. Check for the separate policy link. On your home page, and on each page with a form. Its own link, its own file, nothing extra in it.

6. Count your consents. Is there one yes, or two? If sharing rides on the same tick box as collecting, that is the gap, and it is a front-end change, not a policy rewrite.

Work top down. Steps one to four tell you whether the law reaches you. Steps five and six are the ones an outsider can see without your permission, which makes them the ones to fix first. If you want those two done for you before you start on the rest, a free scan reads them from outside in under a minute.

What Launch Ready Code checks, and what it does not

We have audited more than 700 AI-built apps. The average Launch Readiness Score on a first look is 44 out of 100. That number is dragged down mostly by security headers, database rules and exposed keys, not by privacy work. We say that plainly because it would be easy to imply otherwise here.

Our Compliance Score runs 60 automated checks and reads your policy pages. One of them is CCPA opt-out signal detection. Be clear about the limit: that check is written against the California rule, not this one. It tells you whether your product listens to a browser signal at all, which is a good early sign, but it is not a health data check.

What an outside scan can see: whether a health data policy link of its own exists, whether your pages carry it, what fires before a user consents, which third parties receive requests, and whether reject is as easy as accept. What it cannot see: your database columns, your model outputs, how long your backups live, or the contracts you signed with vendors. Those need someone inside the code.

And the honest limit on all of it: we do not certify anything, and we are not your lawyers. We tell you what your product does. A lawyer tells you what that means for you. Both are cheaper before launch than after a complaint.

Want the outside view free? Run a free scan and see what a stranger sees. Want a one-off read with a senior engineer signing off? That is the Launch Readiness Audit Report. Want the health and privacy checks as a set? The Compliance Score page lists what is in it, and the pricing page compares the options. The rest of this series sits on the blog, and the wider list is in our compliance checklist for AI-built products.