Short answer. Nevada's health data law does not ask what is in your database. It asks what you do with it. A row saying a customer bought a product twice is not health data. That same row becomes health data the moment your code uses it to work out that she is pregnant. Most founders check the first question, answer no, and stop reading. The law is built around the second one.
This is about Senate Bill 370. Nevada passed it in 2023. It has been in force since 31 March 2024. It now sits in state law as sections 603A.400 through 603A.550. A few days ago we wrote about Washington's My Health My Data Act. The two laws are cousins. They are not twins. Where they part company is where your build work changes.
We read two documents side by side. The bill as first filed, and the version that actually passed. Three things changed between them. All three change who is on the hook. Almost nothing written about this law mentions them. That is because most of it was written from the summary rather than the text.
The test is a verb, not a noun
Start with how the law names the thing it guards.
The bill filed in March 2023 said health data meant information "related to the past, present or future health of the consumer." That is a noun test. You look at a field and ask what it is about.
The version that passed says something else. Health data means information tied to a person that a firm uses to identify that person's health status, past, present or future. That is a verb test. You look at your code and ask what it does.
The gap between those two lines is the whole article. Under the first, a shopping history is not health data. It is about shopping. Under the second, that same history becomes health data in the hands of a firm that runs it through a model to guess who is expecting a baby. The data did not change. The use did.
Then the law says the quiet part out loud. Health data covers anything on the guarded list that is "derived or extrapolated from information that is not consumer health data." Then it names how that happens. Proxy data. Derived data. Inferred data. Emergent data. Anything made "through an algorithm, machine learning or any other means."
Read that line again if you build with AI. It describes what a recommendation engine does. It describes what a customer-sorting prompt does too. A founder who has never typed the word "health" into a schema can still make health data. Every night. In a scheduled job. The law counts that as collecting it.
The same swap shows up in the location clause. The filed bill covered location "reasonably capable of being used" to show someone seeking care. The law that passed covers location "that a regulated entity uses to indicate" someone seeking care. What the data could do was traded for what you do with it. Twice, in one section. That is not a drafting accident. It is the shape of the whole statute.
There is no size you can be to avoid it
Most US privacy laws open by telling small firms to relax. They set a revenue floor, or a record count. Below it, nothing applies. Nevada does not do that.
A firm is covered if two things are true. First, it does business in Nevada, or aims products or services at people there. Second, it decides why and how health data gets handled, shared or sold. That is the whole test. No dollar figure appears in it anywhere.
We worked through the states that do use thresholds in our piece on US state privacy laws and the tests that trigger them. Nevada sits outside that pattern. Say you have a two-person app with eleven paying users. One of them lives in Reno. You are inside the door if your code does the thing described above. A launch-week product is as covered as a public company.
So the usual first move fails here. You cannot count rows and decide you are too small. The only honest way to answer is to look at what your code does with the rows you have.
The HIPAA door closed the other way round
Here is the second change between the two versions. It cuts in an odd direction.
The filed bill let you out for information handled under HIPAA. The law that passed lets you out if you are a person or entity that is subject to HIPAA. That is a way out for the whole firm, not for a type of data.
It sounds broader. For a hospital it is. For everyone reading this it is narrower, in the way that counts.
HIPAA reaches health plans. It reaches most doctors and clinics. It reaches clearing houses, and the vendors who handle guarded records for them. It was never written to reach a wellness app. Or a symptom tracker. Or a fitness product, a fertility tool, a mood journal, or a marketplace that books you a clinic slot. Those firms sit outside HIPAA. So they also sit outside this way out. And they hold exactly the data Nevada wrote this law about.
Turn that around and it is stark. The firms most likely to assume a health law covers them are the ones it does not. The firms most sure that health law is not their problem are the ones this law is aimed at. Have you ever told an investor "we are not a HIPAA company"? Then you have said the sentence that puts you inside this statute. Our walk-through of where HIPAA starts and stops maps that boundary.
One more firm-level way out exists, for banks and others covered by the federal Gramm-Leach-Bliley Act. The rest are narrow. Research under the federal rules. Patient safety work. Substance use records under 42 C.F.R. Part 2. None of them describes a normal software company.
What the law asks you to build
Set the arguing aside. If you are covered, here is the list, in the order it appears.
| Duty | What it means in a product | Clock |
|---|---|---|
| A health data privacy policy | A separate page with eleven named items on it. Your sources, who you share with, how someone asks you to stop. A link to it goes on your main site. | Before you collect |
| A clear yes before collecting | Consent that is affirmative and voluntary. Asked for before you collect. Four things must be disclosed in the asking. | Before you collect |
| A second clear yes before sharing | Sharing needs its own consent, "separate and distinct" from the one for collecting. One checkbox cannot do both jobs. | Before you share |
| Answer four kinds of request | Confirm what you hold. List who you gave it to. Stop collecting or sharing. Delete. | 45 days, once extendable by 45 |
| Delete down the chain | Delete from your own records. Then tell every vendor and third party you shared with. They delete too. | 30 days, then 30 more |
| Run an appeal process | A published route to challenge a refusal. If you still say no, you hand over the Attorney General's contact details. | 45 days to answer |
| Limit who can read it | Staff and vendors only. And only where it is reasonably needed for the job the user asked for. | Ongoing |
| Written permission to sell | A signed form with nine required parts. It expires after a year. Both sides keep it for six years after that. | Before any sale |
Two of those rows deserve a pause. They are where an AI-built product tends to fall down first.
The second consent. Most apps have one consent moment. It sits at sign-up and covers everything. This law splits it in two. Collecting is one yes. Sharing is another. The text says it has to be separate and distinct. Think about where your data goes. Your analytics tool. Your error tracker. Your email service. If any of them receives a field your model used to work out health status, that is sharing. A sign-up checkbox did not cover it.
Deleting down the chain. You get thirty days to delete from your own systems. In the same thirty days you must tell everyone you passed the data to. Then they get thirty days. You cannot send that message if you do not know where the data went. This is why we keep pointing people at data mapping before anything else. The delete duty is only as good as the list of places you have to delete from. Backups get a longer leash. Up to six months, and only where restoring the archive makes it necessary.
The request plumbing will look familiar if you have built for Europe. Our checklist for handling data subject requests and our piece on the right to erasure describe the same plumbing. Different timers on it. If you have that already, the Nevada version is a change to the clocks and one extra kind of request. It is not a rebuild.
The consent rules that were written, then cut
This is the third change between the two bills. It is the one nobody seems to have written about.
The filed bill had a whole section on what does not count as consent. Consent could not come from accepting general terms of use. It could not come from a person hovering over a piece of content, or muting it, or pausing it, or closing it. And it could not come from a screen "designed or manipulated with the effect of subverting or impairing the autonomy, decision making or choice of the user."
In the version that passed, that section reads, in full: "(Deleted by amendment.)"
So the law asks for consent that is affirmative and voluntary. Then it says nothing at all about what fails that bar. The three-line list of banned tricks is gone. Washington kept its version. Nevada dropped its own.
Do not read that as permission. "Affirmative, voluntary" still has to mean something. And breaking this law is a deceptive trade practice under Nevada's consumer rules. That is the same body of law that deals with misleading screens anyway. What the cut really takes away is your checklist. You can no longer point at three named tricks and show you avoided them. You are back to a standard, argued after the fact.
The build advice does not change. If anything it gets simpler. Ask on its own. Ask first. Do not bundle it into terms of use. Do not treat silence, a dismissed banner or a closed tab as a yes. Those were going to be the rules. Now they are just the safe way to meet a vaguer one.
Nobody can sue you. That helps less than it sounds
The filed bill let people bring their own case. Damages, costs and legal fees. The law that passed says the opposite in one short line. These provisions "do not create a private right of action."
That is a real split from Washington. There, health data claims have been brought by individuals under the state's own consumer law. It is a good part of why Nevada has had a much quieter two years than its neighbour.
Read it carefully before you relax. Two things survive. Breaking this law is still a deceptive trade practice, which is the Attorney General's ground to stand on. And the section says it "must not be construed to affect any other provision of law." So everything else a claimant might reach for sits untouched outside this statute. Contract. A claim you misled them. The general consumer fraud route.
The honest way to put it is this. The risk is narrow, not absent. No stream of small claims. One office, one lever, and a standard written broadly.
The 1,750-foot number means three different things
The geofence rule gets quoted most and read least. Nevada bans a geofence within 1,750 feet of a clinic, a home for dependants, or anyone else giving care in person. The ban bites where the point of the fence is to track people seeking care, gather health data, or send them ads about it.
That same figure turns up twice more. The repeat is not decoration.
- The banned distance. 1,750 feet from the door of a care provider. Roughly a third of a mile.
- Inside the word itself. The law defines a geofence as a virtual boundary "with a radius of 1,750 feet or less." A boundary counts as a geofence only if it is that tight.
- Inside the words "precise location." Location counts as precise when it pins someone down "within a radius of 1,750 feet."
The second one is the strange one. Here is what it does. Draw a circle two miles wide over a hospital district. By this definition you have not drawn a geofence at all. The ban is written to catch the tight ring around one clinic door. That is the thing ad tech was actually doing. The wording does not clearly reach the loose ring. Would a court read it that literally? That is a lawyer's question, not ours. We raise it because most summaries quote the first number only. A reader comes away thinking all location targeting near a hospital is banned. The text does not say that.
Do you buy location-based ads, or ship an SDK that does? Hand this section to whoever runs that spend. It is also a reminder of where the risk usually comes from. A vendor, not your own code.
Six checks you can run this week
None of these needs a lawyer to start. The first two take about ten minutes.
- Read your own labels. Open your segments, feature flags, tags, event names and model output fields. Say each one out loud. Does any of them describe a body, a condition, a treatment, a cycle, a symptom, or a life event with a medical shape? Then you are making health data, and the rest of this list applies.
- Grep for the guess. Search your code for the place where a score, a label or a prediction gets written back onto a user record. That write is the moment ordinary data turns into health data. Note every one.
- Follow those fields outward. Take each field from step two. List every place it leaves your system. Analytics. Error tracking. Email. Support tools. The warehouse. Ad pixels. That list is both your sharing-consent problem and your delete-notice list.
- Count your consents. Look at what your sign-up flow really asks. Is sharing bundled into the same tick box as collecting? Then it does not meet the separate-and-distinct wording.
- Test deletion end to end. Delete a real test account. Then go hunting for it in every place from step three. Thirty days is not long if today's answer is that nobody knows who to email.
- Lock down who can read the rows. The access limit is a duty, not advice. Can any signed-in service read any user's row? Start there. Our guide to row-level security on Supabase covers the common version in AI-built products, and our privacy-by-design piece covers the habit behind it.
What we are not claiming
We should be straight about where our own product stops. This is a case where it stops early.
Our scan looks at a live address from the outside. It can tell you that an endpoint answers without asking who is calling. That keys are sitting in your front-end code. That your rows can be read by the wrong service. Across the 700+ AI-built apps we have audited, the average Launch Readiness Score is 44 out of 100. And 67% of those scans turn up exposed API keys or secrets. Those findings matter here. Every duty in this law assumes the data is not already leaking out the side of the building.
But none of that answers the Nevada question. Does your code use ordinary data to work out someone's health? That is a question about what happens inside your pipeline. An outside scan never sees in there. No scanner we know of answers it, ours included. It is not a surface question. It is about intent written into code. Step one and step two above are you answering it by hand. We would rather hand you the test than pretend we run it.
We also have not measured how many AI-built products make health data this way. We do not collect that. So there is no figure for it here, and none should be read into one.
None of this is legal advice. It is a reading of the text by people who build software. We wrote it because the summaries we found all repeat the filed bill rather than the law. If you are near the line, the sections are short. Read them. Then ask someone qualified in Nevada.
See what an outsider can already reach
Before the consent questions comes a simpler one. Is the data locked up at all? Our free scan checks your live product from the outside. You get a Launch Readiness Score out of 100 and the findings behind it.
New to the vocabulary? Our plain-English glossary defines the terms. The compliance checklist for AI-built products is the wider job this sits inside. And if you send health-shaped data to an assistant or an agent, read our piece on what a hosted MCP server exposes. That is a new door onto the same rows.
The habit worth keeping. You add a field that stores something your model worked out, rather than something the user typed. Write down what it is for and who receives it. Do that every time. Kept as you go, that one note is most of what this law asks for. It is all of what you will wish you had when someone asks you to delete it.
Frequently asked questions
Does Nevada SB 370 apply to a small SaaS with only a few Nevada users?
It can. The law sets no revenue floor and no minimum record count. A firm is covered if it does business in Nevada, or aims products or services at people there. It must also be the one deciding why and how health data gets used, shared or sold. A two-person product with one customer in Reno meets the first half of that test. The second half comes down to what your code does with the data. Company size never enters into it.
What counts as health data under the Nevada law?
It is data tied to a person that your firm uses to work out that person's health. Past, present or future. The wording matters here. The test is about use, not about type. The law lists health conditions and diagnoses. Treatments and procedures. Medicines. Bodily functions and symptoms. Reproductive and sexual health care. Gender-affirming care. It then covers anything in those groups worked out from data that was not health data to start with. That includes data made by an algorithm or by machine learning. That last clause is how plain product data turns into health data inside an AI-built app.
Is my company exempt from Nevada SB 370 because of HIPAA?
Only if HIPAA really applies to your company. The law that passed lets out any person or entity that is subject to HIPAA. That is a way out for the firm, not for a type of data. HIPAA reaches health plans, most providers, clearing houses and the vendors who serve them. It does not reach a wellness app. Or a symptom tracker, a fitness product, or a booking marketplace. Firms in that gap hold health-shaped data and get no way out here. That is the opposite of what most of them assume.
Can a customer sue my company under the Nevada health data law?
Not under this law. It says plainly that its rules do not create a private right of action. The state's Attorney General enforces it instead. Breaking it counts as a deceptive trade practice under Nevada's consumer rules. Keep two things in mind, though. The law also says it must not be read to affect any other law. So everyday claims outside it still stand. And this is a real split from Washington's My Health My Data Act. There, people have brought their own claims through that state's consumer law.
How long do I have to respond to a request or delete data under SB 370?
You get forty-five days to answer a request once you have checked who the person is. You can take another forty-five if the number or scale of their requests makes it fair to. You must tell them you are taking the extra time, and why. Deleting is faster and runs in two stages. You have thirty days to delete from your own records. In that same window you must tell every affiliate, vendor, contractor or third party you shared the data with. Each of them then gets thirty days to delete it too. Data sitting in archives or backups can wait longer. Up to six months, and only where restoring the system calls for it.
Does the geofence ban stop all ad targeting near a hospital?
Not as written. The ban covers the area within 1,750 feet of a clinic, hospital or other in-person care provider. It bites only where the point is to track people seeking care, gather health data, or send them messages and ads about it. Here is the catch. The law says a geofence is a virtual boundary with a radius of 1,750 feet or less. So a much wider targeting area may not be a geofence at all. The same figure also sets the bar for what counts as precise location. Do you buy ads by location? Read the section itself, not a summary of it.
Research sources
- Nevada Legislature, S.B. 370 Second Reprint (reprinted with amendments adopted 25 May 2023), the version that passed, and the reference for the definition of consumer health data as information a regulated entity uses to identify health status, for the inclusion of proxy, derivative, inferred and emergent data produced through an algorithm or machine learning, for the definition of a regulated entity with no revenue or volume threshold, for the entity-level exemptions covering any person or entity subject to HIPAA and financial institutions subject to the Gramm-Leach-Bliley Act, for the eleven required elements of the health data privacy policy, for affirmative and voluntary consent before collection and separate and distinct consent before sharing, for section 23 being deleted by amendment, for the forty-five day response deadline and its forty-five day extension, for the thirty-day deletion and downstream notification deadlines and the six-month backup allowance, for the appeal process and the requirement to supply the Attorney General's contact details, for access being limited to employees and processors where reasonably necessary, for the nine required elements of written authorisation to sell and its one-year expiry and six-year retention, for the 1,750-foot geofencing prohibition and the definition of a geofence as a boundary with a radius of 1,750 feet or less, for the definition of precise geolocation information at a radius of 1,750 feet, and for the provision stating that the sections do not create a private right of action.
- Nevada Legislature, S.B. 370 as introduced, 23 March 2023, used only for comparison against the enacted text, and the reference for the original definition of consumer health data as information related to health, for the original location clause covering data reasonably capable of being used to indicate an attempt to receive care, for the original information-level rather than entity-level HIPAA exemption, for the original section 23 listing terms-of-use acceptance, hovering, muting, pausing and closing content, and manipulative interfaces as things that cannot constitute consent, for the original 2,000-foot geofencing distance, and for the original provision authorising a civil action by any person who is a victim of a violation.
- Nevada Revised Statutes 603A.540, as codified, used to confirm that the enacted geofencing provision and its 1,750-foot definition carried into the codified statute unchanged, and that the consumer health data provisions took effect on 31 March 2024.
- Nevada Revised Statutes 603A.550, as codified, used to confirm the enacted enforcement provision, that a violation constitutes a deceptive trade practice for the purposes of NRS 598.0903 to 598.0999, that the provisions do not create a private right of action, and that they must not be construed to affect any other provision of law.
- Jai Mittal, Founder & CTO, Launch Ready Code — Proprietary data from 700+ AI-built app security audits, 2025–2026. Average Launch Readiness Score: 44/100. Exposed API keys or secrets found in 67% of scans.