Key Takeaways
- Washington’s My Health My Data Act regulates a category of data that HIPAA never touched: the health information collected by apps, websites, and wearables that sit outside the traditional healthcare system. If your mHealth app touches a Washington resident, the law almost certainly applies to you, regardless of your company’s size, revenue, or physical location.
- The Act is built on a strict opt-in consent model, a sweeping deletion right, a standalone privacy policy requirement, and a ban on geofencing around healthcare facilities. It is enforced not only by the state Attorney General but by a private right of action, which means individual consumers can sue, and the first class action has already been filed.
- Compliance is an architecture problem, not a paperwork problem. Separate consent flows, granular data deletion, consent withdrawal, and rigorous third-party SDK governance all have to be designed into the app from the first sprint, because retrofitting them after launch is slow, expensive, and legally risky.
The Privacy Gap That HIPAA Left Wide Open
Most people assume that when an app asks about their symptoms, tracks their cycle, logs their workouts, or records their mood, that information is protected the same way a conversation with their doctor is. It usually is not. HIPAA, the federal law most Americans think of as the guardian of health privacy, only governs a specific set of covered entities: most healthcare providers, health plans, and the clearinghouses and business associates that work with them. The moment health data is generated outside that perimeter, by a direct-to-consumer wellness app, a fitness tracker, or a website, HIPAA’s protections evaporate.
That gap is not small, and the data flowing through it is not trivial. Independent research has repeatedly found that consumer health apps share user data far more freely than people realize. A widely cited BMJ study of medicines-related mobile apps found that 79% transmitted user data to outside parties, with a sample of 24 apps sending information to 55 distinct entities owned by 46 parent companies, and those third parties in turn advertising the ability to pass data along to 216 “fourth parties,” including advertising networks, telecom corporations, and a consumer credit reporting agency. A separate scoping review of popular women’s mHealth apps found that 87% shared user data with third parties, while only a little over half gave users any information about data security at all. The mobile health market itself, meanwhile, has grown into one of the largest categories in digital health, with current estimates placing it in the range of $63 billion to $93 billion globally and projections pushing it past $150 billion by the end of the decade.
Washington decided to close that gap. In 2023, the state legislature passed the My Health My Data Act, and Governor Jay Inslee signed it into law on April 27. The state Attorney General’s office describes it as the first privacy-focused law in the country to protect personal health data that falls outside the reach of HIPAA, built specifically to keep sensitive health information from being collected and shared without a consumer’s consent. The political backdrop mattered: the law was introduced in the wake of the Supreme Court’s Dobbs decision, with reproductive health privacy as a central motivation, and public support was strong, with the Attorney General noting that 76% of Washingtonians backed the measure.
For anyone building an mHealth product, the takeaway is direct. The set of data your app collects, including symptoms, conditions, biometric readings, location, and even inferences you draw about a user’s health from non-health data, is now squarely regulated when it belongs to a Washington consumer. In this post, we will walk through what the My Health My Data Act actually requires, why its enforcement teeth make it different from most privacy laws, and how to design your app so that compliance is built into the architecture rather than bolted on after the fact.
Why This Law Is Different, and Why It Should Have Your Attention
Plenty of privacy regulations have arrived over the past few years, and it would be easy to file the My Health My Data Act alongside the rest as one more compliance checkbox. That would be a mistake. Several features make this law unusually broad and unusually dangerous to ignore.
The first is that it has almost no front door you can avoid. Most state privacy laws include applicability thresholds, exempting companies below a certain revenue or that process data on fewer than some number of consumers. The My Health My Data Act has no such thresholds based on revenue or number of consumers. If you are a regulated entity handling consumer health data, you are in scope, full stop. Many small companies that comfortably sat outside the California or Virginia privacy laws find themselves directly covered here.
The second is its geographic reach. The law protects two groups: natural persons who are Washington residents, and natural persons whose consumer health data is collected in Washington. A regulated entity is any legal entity that conducts business in Washington or targets products and services to Washington consumers, and that determines the purpose and means of processing that data. In practice, a mobile app distributed through the app stores reaches Washington residents by default unless you take deliberate steps to exclude them. Your servers can sit in another state or another country and you are still covered, and out-of-state processors handling that data are covered too.
The third, and the reason this law keeps privacy lawyers up at night, is how broadly it defines the data it protects. “Consumer health data” is not limited to diagnoses or clinical records. It reaches information that identifies a consumer’s past, present, or future physical or mental health status, and the statute and the Attorney General’s guidance make clear that this sweeps in bodily functions, biometric data, precise location information that could indicate an attempt to access health services, and, critically, health data that is derived, inferred, or extrapolated from non-health information. The Attorney General offers a vivid example: a purchase of toilet paper is not health data, but an app that tracks someone’s digestion or perspiration is collecting consumer health data. If your app analyzes shopping habits, location patterns, or search behavior and uses them to infer something about a user’s health, those inferences are regulated even though the raw inputs were not.
The breadth of that definition has led experienced privacy counsel to describe this as a law for which perfect, risk-free compliance may be impossible. That is a sobering assessment, and it is precisely why a deliberate, well-architected compliance strategy matters so much. You cannot eliminate the risk, but you can dramatically reduce it through thoughtful design.
The Enforcement Teeth: A Private Right of Action
Here is the feature that separates the My Health My Data Act from a routine compliance obligation. Under the law, any violation is treated as a per se violation of the Washington Consumer Protection Act. That matters because the Consumer Protection Act is enforced not only by the state Attorney General, but through a private right of action that lets individual consumers sue for violations of any provision of the Act.
Most state privacy laws reserve enforcement for a regulator. The My Health My Data Act hands that power to every consumer in the state. For a company building a consumer app with potentially millions of users, that changes the risk calculus entirely. A single compliance failure is not one regulatory inquiry. It is the raw material for a class action.
That is not a hypothetical concern. On February 10, 2025, the first class action under the My Health My Data Act was filed against Amazon in the Western District of Washington. The case, Maxwell v. Amazon, alleges that Amazon’s advertising software development kit, embedded in thousands of third-party mobile applications, harvested the precise location data of tens of millions of people without their consent and used it for profit. According to the complaint, the SDK was integrated into more than 10,000 different apps, including widely used location-based apps, and the location data it collected could reveal sensitive details such as visits to healthcare facilities. The plaintiffs argue that because precise location data can reveal attempts to access health services, collecting it without separate consent violates the Act.
There are two lessons in that case for every mHealth builder. The first is that the law’s reach extends to companies most people would never associate with healthcare. Amazon is not a health company, but the inferential nature of location data pulled it into scope. The second is that the most acute risk often lives in the third-party code you embed rather than the code you write yourself. The Amazon case turns on an SDK, a bundle of pre-written code that thousands of developers dropped into their apps to handle advertising and analytics. If your app includes advertising, analytics, attribution, or any other third-party SDK that touches location or health-adjacent data, that SDK is now a potential source of liability you are responsible for.
While the Attorney General’s office handles regulatory enforcement, with the possibility of injunctions, restitution, and civil penalties, it is the private right of action that should drive your design decisions. Build as though a plaintiff’s attorney will eventually scrutinize every consent prompt and every data transmission in your app, because under this law, one might.
What the Act Actually Requires
With the stakes established, here is the substance. The My Health My Data Act imposes a set of concrete obligations, and each one translates into specific design and engineering work. A capable healthcare app development team should be able to map every requirement below to a corresponding feature in your build.
A Standalone Consumer Health Data Privacy Policy
The Act requires regulated entities to maintain a dedicated consumer health data privacy policy, and the requirements are exacting. The policy must disclose the categories of consumer health data you collect, the purposes of collection and use, the sources of the data, the categories of data you share, and the specific categories of third parties and affiliates that receive it, along with how consumers can exercise their rights.
Two details trip up companies repeatedly. First, this must be a standalone policy. It cannot be folded into your general privacy policy, and the Washington Attorney General has been explicit that the consumer health data privacy policy may not contain additional information not required under the Act. No marketing language, no bundling with unrelated disclosures. Second, you must prominently publish a link to it on your homepage, and for an app, that means a distinct, accessible link on your homepage, your app store listing pages, and within the app itself.
Separate Opt-In Consent for Collection and for Sharing
This is the heart of the law, and it is where mHealth apps most often need to rethink their architecture. The Act establishes an opt-in model requiring one of two legal bases to process consumer health data: consent, or necessity to provide a product or service the consumer requested. Crucially, consent to collect and consent to share are two separate things. You cannot obtain a single blanket agreement. You need distinct, affirmative, opt-in consent for collection, and then separate consent before you share that data with anyone.
The definition of valid consent is demanding. It must be a clear affirmative act that is freely given, specific, informed, opt-in, voluntary, and unambiguous. The statute expressly rules out several common patterns: consent cannot be inferred from a user accepting a broad terms-of-use agreement, it cannot come from a user hovering over or closing a piece of content, and it cannot be obtained through deceptive designs, the dark patterns that nudge users toward agreeing. If your current onboarding bundles every permission into one “I agree” button, it does not meet this standard.
A Sweeping Right to Delete
The Act grants consumers a robust set of rights, including the right to confirm whether you are collecting, sharing, or selling their health data, the right to access that data along with a list of every third party and affiliate that received it, the right to withdraw consent, and the right to have their data deleted. Businesses generally must respond to these requests within 45 days, with one possible 45-day extension when reasonably necessary.
The deletion right deserves special attention because it goes further than any comparable privacy law. When a consumer requests deletion, you must delete their consumer health data from your records, and you must also notify all affiliates, processors, contractors, and third parties with whom you shared that data and direct them to delete it too. Those downstream parties have their own obligation to comply. Privacy counsel have noted that this deletion right is unusually sweeping and lacks many of the standard exceptions found in other laws, which makes engineering for clean, complete, cascading deletion one of the harder technical challenges the Act presents.
A Near-Total Restriction on Selling Data
If collection and sharing require opt-in consent, selling consumer health data requires something stronger still. The Act makes it unlawful to sell or offer to sell consumer health data without first obtaining a valid written authorization from the consumer that is separate from consent. This authorization has specific required contents, expires after one year, and both the seller and the purchaser must retain copies for six years. For most mHealth businesses, the practical answer is simple: do not sell consumer health data, and architect your data flows so that you can demonstrate you are not.
A Ban on Geofencing Around Health Facilities
Finally, the Act prohibits a specific and revealing practice. It is unlawful to use a geofence around any facility that provides in-person healthcare services in order to identify or track people seeking care, collect their consumer health data, or send them messages or advertisements related to their health. The law defines a geofence as a virtual boundary of 2,000 feet or less around the perimeter of the physical location, and these restrictions have been in force since July 2023. If your app or your advertising partners use location-based targeting, you need to ensure none of it draws a virtual perimeter around clinics, hospitals, pharmacies, or other care facilities.
Designing for Compliance: An Architecture-First Approach
The recurring theme in Dogtown Media’s work on healthcare apps is that compliance is something you build in from day one, not something you retrofit after launch. Retrofitting security and privacy into an app designed without them is always more expensive and less effective than designing them in from the start. The My Health My Data Act makes that principle non-negotiable, because several of its requirements are impossible to satisfy with a surface-level fix. Here is how the obligations above translate into architecture.
Build a Granular Consent Management Layer
Because the Act requires separate opt-in consent for collection and for sharing, and because consent must be specific and purpose-bound, a single permissions dialog will not do. Your app needs a dedicated consent management layer that can request, record, and enforce consent at a granular level. That means presenting distinct, plainly worded prompts for each category of data and each purpose, logging exactly what each user consented to and when, and gating data flows on that record so that nothing is collected or shared without a matching consent on file.
This layer also has to handle withdrawal. The Act gives consumers the right to withdraw consent, and your system must make that as easy as granting it, then propagate the withdrawal so that data flows stop immediately. Designing this well means treating consent not as a one-time checkbox but as a living state attached to each user that your app continuously reads before acting. Done right, this same infrastructure positions you to comply with other emerging state health-privacy laws, since the underlying pattern of granular, auditable, purpose-specific consent is becoming the norm.
Engineer for Complete, Cascading Deletion
The deletion right requires that you be able to find and erase all of a user’s consumer health data on request, and to instruct every downstream recipient to do the same. That is a serious data-architecture requirement. The Washington Attorney General has made clear that the right reaches a consumer’s data even in archived and backup systems, which means knowing, at all times, everywhere a given user’s health data lives, including backups, logs, analytics stores, and the systems of every processor and third party you share with.
In practice, this argues for designing your data model so that consumer health data is identifiable and retrievable by user from the outset, rather than scattered untraceably across services. It argues for maintaining a current map of every third party and processor that receives data, with an automated or at least well-documented mechanism to send deletion instructions downstream. The kind of architecture that supports efficient retrieval and removal of all user-related data is far easier to put in place at design time than to reconstruct under the pressure of a deletion request or a lawsuit.
Govern Your Third-Party SDKs Ruthlessly
The Maxwell v. Amazon case is a warning that the most dangerous code in your app may be code you did not write. Advertising SDKs, analytics libraries, attribution tools, and crash reporters routinely collect device identifiers, location, and behavioral data, and any of that can become regulated consumer health data under this law, especially location data that could indicate health-seeking behavior.
Treating SDK governance as a first-class compliance activity means inventorying every third-party component in your app and understanding exactly what data each one collects and transmits. It means scrutinizing whether any of them gather precise location or health-adjacent data, and removing, replacing, or reconfiguring those that do unless you have a clean consent basis. And it means flowing your contractual obligations down to those vendors, since the Act requires that your agreements with processors bind them to your instructions. A practical principle for mHealth apps under this law is data minimization at the SDK layer: if a third-party component does not need location or health-adjacent data to function, do not let it collect that data at all.
Bind Your Processors by Contract
The Act treats your vendors as processors, and it requires that they handle consumer health data only under a binding contract that sets out your processing instructions and limits them to those instructions. If a processor acts outside your instructions, it becomes a regulated entity in its own right and takes on full liability, but that does not get you off the hook. Your data processing agreements need to define the purpose, the permitted operations, retention and deletion rules, and the obligation to assist you with consumer requests, and they need to flow those same requirements down to any subprocessors.
Apply a Reasonable Standard of Care to Security
Underpinning all of this, the Act requires that you restrict access to consumer health data to the people and service providers who genuinely need it, and that you implement administrative, technical, and physical safeguards meeting the reasonable standard of care in your industry. That standard scales with the volume and sensitivity of the data you handle, but for any app processing health data it points to the familiar pillars of strong security: encryption of data in transit and at rest, robust authentication and access controls, audit logging, and a tested plan for responding to incidents. These are the same foundations that underpin HIPAA-compliant healthcare apps, and building to that standard serves you well here even when HIPAA itself does not apply.
HIPAA Is the Floor, Not the Ceiling
A common and dangerous misconception among mHealth founders is that being HIPAA-compliant, or being outside HIPAA’s scope entirely, settles the privacy question. It does not. HIPAA is the federal floor, not the ceiling, and state-level health-privacy laws routinely impose obligations that go well beyond it.
The My Health My Data Act is the clearest example. It deliberately regulates the consumer health data that HIPAA leaves untouched, which means a direct-to-consumer wellness app that never comes within a mile of HIPAA can still be fully subject to Washington’s law. And even for apps that do handle HIPAA-covered data, the Act layers additional requirements on top for any consumer health data that falls outside HIPAA’s protected health information. The Act exempts data already governed by HIPAA and certain other sectoral laws, but the gaps between those regimes are exactly where this law operates.
This is why the most resilient strategy is to design to the highest applicable standard rather than the minimum one. Washington was first, but it is not alone. The broader trend toward state consumer health-privacy laws is firmly established, and the architectural patterns the My Health My Data Act demands, granular consent, comprehensive deletion, tight third-party governance, are becoming table stakes across jurisdictions. An mHealth app engineered to these standards is not just compliant in Washington. It is positioned for the regulatory environment that is still taking shape everywhere else, and it earns something increasingly valuable in a market where users have learned to be suspicious of health apps. It earns trust.
A Practical Compliance Roadmap
Translating all of this into action is more manageable when you sequence it. Here is a path that takes an mHealth product from uncertainty to a defensible compliance posture.
Step 1: Run a Data Mapping and Gap Analysis
You cannot comply with a law about data flows until you know your own. Map every point where your app collects, infers, stores, shares, or sells consumer health data, including the data your third-party SDKs touch. Classify what qualifies as consumer health data under the Act’s broad definition, paying particular attention to inferences and to precise location. Then benchmark your current practices against the Act’s requirements to find the gaps. This single exercise surfaces most of the work ahead.
Step 2: Rebuild Consent and the Privacy Policy
With the gaps identified, implement the granular consent architecture: separate, specific, opt-in prompts for collection and for sharing, purpose-bound logging, and frictionless withdrawal, with no dark patterns anywhere in the flow. In parallel, draft the standalone consumer health data privacy policy with exactly the required disclosures and nothing extra, and place prominent links to it on your homepage, your app store pages, and inside the app.
Step 3: Implement Rights Fulfillment and Deletion
Build the mechanisms that let users exercise their rights within the 45-day window: access, deletion, consent withdrawal, and appeal of denied requests. Engineer deletion to be complete and cascading, capable of erasing a user’s data across all your systems and instructing every downstream recipient to do the same. Maintain the current map of processors and third parties that this depends on.
Step 4: Lock Down Third Parties and Contracts
Inventory and govern every SDK and processor. Remove or reconfigure components that collect location or health-adjacent data without a clean consent basis, audit your advertising partners for any geofencing around care facilities, and put compliant data processing agreements in place that bind every vendor and subprocessor to your instructions.
Step 5: Validate, Monitor, and Maintain
Compliance is not a launch milestone. It is an ongoing operational capability. Test your consent flows and rights-request handling before launch, monitor them after, and schedule periodic reviews as your app evolves and as enforcement trends develop. The regulatory environment will keep changing, and the apps that stay compliant are the ones that treat compliance as a living part of the product rather than a one-time project.
Build It Right the First Time
The My Health My Data Act represents a genuine shift in how health data is regulated in the United States. For the first time, the health information that lives in consumer apps, wearables, and websites, the data HIPAA never reached, carries real legal weight, backed by a private right of action that is already producing litigation. For mHealth companies, that is not a reason to retreat from Washington or to treat the law as an obstacle. It is a reason to build better.
The good news is that everything the Act demands is achievable with the right approach. Separate consent, cascading deletion, disciplined SDK governance, and a security posture meeting a reasonable standard of care are all solvable engineering problems, provided they are designed into the product from the beginning rather than patched in after a complaint arrives. Apps built this way do not just avoid liability. They stand out in a crowded market as products that genuinely respect the sensitive data users entrust to them.
That is the hard part, and it is the part worth getting right: the clinical and technical judgment to architect consent, data flows, and third-party integrations so they satisfy one of the strictest health-privacy laws in the country without compromising the experience that makes your app worth using. If you are building an mHealth product and want a partner who understands both the regulatory landscape and the engineering required to navigate it, the team at Dogtown Media builds compliant, secure health applications from the ground up.
Frequently Asked Questions
Does the My Health My Data Act apply to my app if my company is not based in Washington?
Very likely yes. The Act protects Washington residents and anyone whose consumer health data is collected in Washington, and it applies to any regulated entity that conducts business in Washington or targets products and services to Washington consumers. Because mobile apps distributed through the app stores reach Washington residents by default, most mHealth apps are in scope regardless of where the company is headquartered or where its servers are located. Out-of-state processors handling that data are covered as well.
My app is already HIPAA-compliant. Doesn’t that cover me?
No. HIPAA and the My Health My Data Act protect different data. HIPAA governs protected health information held by covered entities and their business associates, while the Act governs consumer health data that falls outside HIPAA, which is exactly the kind of data most consumer apps collect. The Act exempts data already covered by HIPAA, but it imposes its own separate requirements on everything else. HIPAA is the floor, not the ceiling, and being HIPAA-compliant does not by itself make you compliant with Washington’s law.
What counts as “consumer health data” under the Act?
The definition is deliberately broad. It covers information that identifies a consumer’s past, present, or future physical or mental health status, including conditions, treatments, bodily functions, biometric data, and precise location information that could indicate an attempt to access health services. Critically, it also includes health information that is derived, inferred, or extrapolated from non-health data. If your app infers something about a user’s health from their behavior, purchases, or location, those inferences are regulated even if the underlying inputs are not.
What is the private right of action, and why does it matter so much?
Under the Act, any violation is treated as a violation of the Washington Consumer Protection Act, which consumers can enforce directly by suing. Most privacy laws reserve enforcement for a regulator, but this one lets individual consumers bring claims, which makes class action litigation a real and significant risk for any app with a large user base. The first class action under the Act was filed against Amazon in February 2025 over location data collected through an advertising SDK embedded in thousands of apps, illustrating that the risk is already material.
What is the single most important thing to get right when designing for compliance?
Consent architecture. The Act requires separate, specific, opt-in consent for collecting consumer health data and, again, for sharing it, and it explicitly prohibits inferring consent from broad terms-of-use agreements or dark patterns. Most apps fail this requirement because they bundle all permissions into a single agreement. Building a granular consent management layer that requests, logs, and enforces purpose-specific consent, and that handles withdrawal cleanly, addresses the core of the law and lays the foundation for the rest of your compliance work.
How should we handle third-party SDKs?
Treat them as a primary compliance risk. The Amazon litigation centers on an advertising SDK, not first-party code, because SDKs frequently collect device identifiers, location, and behavioral data that can become regulated consumer health data. Inventory every third-party component in your app, determine exactly what data each collects and transmits, and remove or reconfigure any that gather location or health-adjacent data without a clean consent basis. A data-minimization approach at the SDK layer, where components only collect what they genuinely need, substantially reduces your exposure.
When did the Act take effect, and what are the deadlines?
The Act was signed in 2023. Its geofencing restrictions have been in force since July 23, 2023. The main compliance obligations took effect on March 31, 2024, for most regulated entities, with small businesses given until June 30, 2024. In other words, the law is fully in effect now, and enforcement, including private litigation, is already underway.
