Washington's My Health My Data Act (MHMD) defines a geofence as a virtual boundary 2,000 feet or less from a physical location. Around a facility providing in-person health care, the law prohibits using a geofence to identify or track people seeking care, collect consumer health data, or send health-related notifications, messages, or advertisements.
A familiar vendor demo can make location-based features sound routine: a mobile SDK detects nearby devices, an analytics platform measures visits, and a marketing tool triggers a message. The compliance question isn't whether the software uses GPS or whether anyone calls it geofencing. Washington businesses need to examine why the feature detects a location, what information it collects, and how the resulting data is used or shared.
Geofencing and MHMD at a Glance
MHMD bars any person from deploying a geofence around an entity that provides in-person health-care services when the geofence is used to identify or track consumers seeking care, collect consumer health data, or send notifications, messages, or advertisements related to health data or health-care services. The prohibition is set out in Washington's MHMD geofencing provision.
That rule is narrower than a ban on every location feature near every clinic, but broader than a rule limited to ad campaigns. A feature can raise concerns if its purpose, data flow, or downstream use connects location to health care. A vendor's label for a capability doesn't decide the issue.
The practical boundary
A company evaluating a location feature should look at three things:
- Purpose: Is the feature meant to identify or track people seeking care, collect health data, or deliver health-related communications?
- Data flow: Does it collect or pass location, device identifiers, or other information that can connect a person to a health-care visit?
- Downstream use: Can another system use the data to create an audience, infer health status, or trigger a message?
Location-aware mobile SDKs, venue analytics, and advertising tools can bring these questions into ordinary technology procurement. In-house counsel should expect to be asked whether a vendor's tools detect device presence near health-care facilities, not just whether a campaign is targeted at patients.
The useful approach is to treat the statutory prohibition as a product-design constraint. Map the feature's purpose and data flow, then ensure prohibited detection and activation are blocked before they happen.
How MHMD Defines a Geofence
MHMD's definition covers technology that uses GPS coordinates, cell-tower connectivity, cellular data, radio-frequency identification, Wi-Fi data, or another spatial or location-detection method to establish a virtual boundary or determine whether a consumer is inside it. The definition appears in Washington's MHMD statute.
Technology is only one part
The list matters because it's technology-neutral. A system doesn't escape the definition just because it relies on Wi-Fi positioning, a Bluetooth beacon, or device-location data supplied by a vendor rather than directly reading GPS. Product documentation might call a capability proximity analytics, venue measurement, or location-based activation. Those names don't change what the feature does.
The second element is the virtual boundary. The technology must establish one or locate a consumer within it. A company should therefore ask whether its systems define a zone around a place or determine that a device is inside one, including when a third party performs the detection.
The statutory distance is 2,000 feet or less from the perimeter of the physical location. That measurement is tied to the facility's perimeter, not to an advertising platform's chosen campaign radius. A platform setting that looks like a general marketing radius shouldn't be treated as the legal test.
For a Washington business, the practical question is whether a feature establishes or detects a virtual boundary near a covered facility, regardless of its internal name or marketing purpose. Map how the technology works before accepting a vendor's claim that its product isn't a geofencing tool.
Why Purpose and Data Flow Drive the Answer
“No GPS near clinics” is an incomplete compliance rule. It focuses on one technology and ignores the conduct MHMD regulates. A more useful test asks whether the feature's purpose, data flow, or downstream use links location to health care or consumer health data. The distinction is addressed in this analysis of laws protecting reproductive health data.
Consider a retail app that detects store visits. If it only measures ordinary retail traffic, that purpose doesn't automatically establish a prohibited use. But if the app uses visit information to identify people seeking health care, collect health data, or target health-related messages, the analysis changes. The same location signal can take on a different legal significance through its output and use.
Venue analytics create another borderline case. A vendor might receive device-location data to estimate visits without delivering an advertisement. Counsel still needs to ask whether the vendor or its customer can identify or track consumers seeking care, and whether the information is used to collect or infer health data.
A wellness promotion near a pharmacy may be an advertisement related to health care, depending on its content and how its audience is selected. A navigation feature that routes a person without health-related messaging presents a different factual picture, but its data flows still need review if location is collected or used to infer health status.
Counsel's test: Don't stop at “Is GPS on?” Trace what the feature is designed to do and what every recipient can do with its output.
A user's opt-in isn't a cure for conduct the statute categorically prohibits. Before launch, teams should align product purpose, vendor behavior, and data handling. For a broader look at operational data governance, see this guide to data management practices under MHMD.
A Practical Compliance Workflow for Washington Teams
A location exclusion only works if the right facilities are mapped and the block happens before a feature can act. A workable program starts with a reliable facility inventory and assigns ownership beyond the marketing team. Privacy, legal, engineering, and vendor management all need to know which systems can detect or use device presence.
Build controls into the data path
Start by listing each in-person health-care location relevant to the business. Geocode every site, then configure an exclusion zone that exceeds the statutory boundary. The margin is a practical safeguard against boundary errors, not a replacement for understanding the statutory threshold.
Next, test every location-aware feature and vendor integration. That includes mobile advertising SDKs, Bluetooth or Wi-Fi positioning, cell-derived location, venue analytics, and systems that infer presence from device identifiers. The feature name matters less than whether it collects or activates based on device presence.
Enforce the exclusion upstream. The block should prevent collection, audience creation, notifications, or sharing before those events occur. Deleting information later may address retained records, but it may not undo an earlier identification or tracking event. The Federal Privacy Forum's analysis of Washington's MHMD Act discusses the value of facility inventories, geocoding, exclusion zones, and upstream controls.
Assign the inventory and zone configuration to privacy engineering or another accountable control owner. Marketing shouldn't be the only team deciding where campaigns run when SDKs and analytics pipelines can collect location independently. Teams building healthcare products can also consult a healthcare compliance guide for broader compliance context.
How Broadly MHMD Defines Consumer Health Data
MHMD's consumer health data definition extends beyond medical records. It covers personal information linked or reasonably linkable to a consumer that identifies the person's past, present, or future mental or physical health status. That can include precise location information, information about a person seeking health care, and information inferred or extrapolated from data that didn't start out as health information.
Identifiers and inferences matter
A location record can become sensitive in context. Information that appears to be routine device or web data may help identify a person and reveal a health status when linked to a visit or other behavior. Legal analysis of the statute identifies an identifiable IP address, search terms, and user behavior as examples when they can reveal an individual's health status. See this legal analysis of consumer health data under MHMD.
That breadth creates a familiar trap for product teams: a dataset is described as analytics because it contains locations, identifiers, or behavioral signals rather than diagnoses. But if the information can reasonably be linked to a person and reveals health status, the label “analytics” doesn't settle its legal character.
Teams should assess what the information can reveal in combination, not only the field names in a schema. A location event, search term, or user action might appear innocuous in isolation yet contribute to a health inference when joined with other data.
For teams distinguishing Washington privacy-law coverage from federal health privacy rules, this guide to determining whether data falls under HIPAA or MHMD can help frame the analysis. Consumers and product teams reviewing connected health technology may also find this privacy guide for wearable app users useful context.
Matching Your Use Case to the Prohibition
The practical question isn't whether a feature is active or passive. It's which prohibited use the feature may enable and where the system can block it. The table below is a starting point for triage, not a substitute for tracing the complete data flow.
| Use Case | Legal Hook | Practical Control |
|---|---|---|
| Mobile ad SDK targeting | Identification or tracking of consumers seeking care, or health-related advertising | Configure and test an upstream exclusion before location enters campaign or audience logic. |
| Venue analytics or Wi-Fi positioning | Potential identification or tracking, and collection of consumer health data | Disable collection within the applicable exclusion area and confirm what the analytics provider retains or infers. |
| Vendor receives device-location data | Collection or downstream identification, depending on purpose and use | Restrict the vendor's use, require location controls, and verify that the data flow respects facility exclusions. |
| Wellness notification triggered by presence | Health-related notifications or messages | Prevent the location trigger from firing around covered facilities; assess the content and targeting purpose before launch. |
A feature can implicate more than one legal hook. For example, an SDK might collect location, pass an identifier to an ad platform, and enable a health-related communication. Teams should assess the full chain rather than assigning a single category based on the first component.
Where consent design is part of a broader MHMD review, counsel can also consider this explanation of consent levels under Washington’s MHMD Act. Consent review doesn’t replace the location analysis: the prohibited geofence use remains the central question.
Vendor Contracts and Data-Flow Mapping
A company’s own code isn’t the only place geofencing risk enters. SDKs, ad networks, analytics tools, and other vendors may collect or process location, or offer features that activate based on device presence. A contract should describe what the vendor can do, not just what the sales presentation says it does.
What procurement should require
Map each vendor’s inputs, processing, outputs, and onward disclosures. A provider receiving only a device identifier presents a different data-flow picture from a provider receiving precise location. Neither should be waved through without review, but precise location makes the connection to MHMD harder to ignore.
Contract terms should prohibit unauthorized geofencing near covered facilities and restrict use of location data to defined purposes. Require the vendor to disclose relevant functionality, identify subcontractors or downstream recipients, cooperate with audits, and notify the business of incidents under defined contractual timelines. A data-processing agreement should match the actual processing relationship, as addressed in this guide to data-processing agreements.
Procurement can use this checklist:
- Capability: Can the vendor activate, target, measure, or infer based on device presence near a health-care facility?
- Data received: Does the vendor process precise location, identifiers, or information that can be linked to a person?
- Restrictions: Does the contract prohibit prohibited geofencing and unrelated downstream use?
- Evidence: Can the vendor document its data flows and demonstrate how location exclusions work?
- Escalation: Who receives notice if the vendor changes a feature or discovers a relevant incident?
Ask directly: Can this vendor certify it does not enable geofencing within 2,000 feet of a covered facility? If the answer is vague, treat that as an unresolved control issue, not a satisfactory assurance.
Why Downstream Controls Are Not Enough
A deletion process can reduce how long information remains in a system. It doesn’t necessarily prevent the earlier conduct that matters under the geofencing prohibition. If a feature identifies or tracks a consumer when the device is detected, later deletion doesn’t make that detection disappear.
A consent screen shown after a location trigger may also arrive too late to prevent the triggering event. The legal analysis focuses on the prohibited use of the geofence, so teams shouldn’t assume that opt-in or an eventual deletion process will cure it. Counsel should instead ask where detection occurs and whether the system blocks it before collection or activation.
When a feature has operated without an upstream exclusion, the response should include containment and a review of what happened. Teams may need to identify the system, locations, data involved, recipients, and any activation or sharing. Deletion can be part of remediation, but it shouldn’t be described internally as proof that the original design was compliant.
A scheduled deletion job is a retention control. It isn’t a substitute for a launch-time exclusion.
Engineering and product sign-off should record whether the location control is enforced before the feature collects data or acts on it. Incident response should also feed back into that design review, so the team fixes the control rather than relying only on post-event cleanup.
The video below provides additional context for teams reviewing consent and location practices.
Pre-Launch Testing Checklist for Geofenced Features
A program-level policy won’t catch a misconfigured SDK or a new location-triggered feature. Each launch needs a feature-specific gate that records the purpose, the data flow, the exclusion behavior, and the person accountable for approval.
Test the control, not just the documentation
Before release, the privacy engineer or product manager should confirm:
- Purpose: A written description explains what the feature detects and why the business needs that location signal.
- Facility coverage: The relevant in-person health-care locations are in the maintained facility inventory and mapped for the feature.
- Exclusion configuration: The applicable zone exceeds the statutory boundary and is applied to the feature’s location logic.
- Enforcement point: A test confirms the exclusion blocks collection or activation upstream, before audience creation, messaging, or sharing.
- Vendor behavior: Each SDK, analytics provider, or ad partner has confirmed whether it can collect, activate, or infer based on device presence.
- Approval record: The launch record identifies the approver and the evidence reviewed.
- Retention review: The team documents how long the feature keeps relevant data and aligns that schedule with applicable MHMD obligations.
Testing should include the paths that matter in production: location capture, vendor transfer, audience generation, and triggered communications. A settings-page screenshot alone doesn’t show whether an SDK or downstream partner can still process location.
If a vendor changes functionality or the product team changes the feature’s purpose, the prior sign-off shouldn’t automatically carry forward. Reopen the review and test the control again before the changed behavior ships.
Quick Reference and Direct Answers on Geofencing MHMD
A practical decision rule is straightforward: if a location feature’s purpose or output touches health care, exclude the covered-facility area and document the control. If it doesn’t, document why the feature’s purpose and data flow remain outside the prohibition. A label such as “analytics,” “navigation,” or “retail traffic” isn’t enough on its own.
Direct answers
What counts as a geofence under MHMD? Technology using GPS, cell-tower connectivity, cellular data, RFID, Wi-Fi, or another spatial or location-detection method to establish a virtual boundary or locate a consumer inside it.
How far does the boundary extend? The statutory definition covers a boundary 2,000 feet or less from the perimeter of the physical location. Teams should configure practical exclusions with an appropriate margin rather than treating a vendor’s campaign radius as the legal measurement.
Does consumer opt-in cure a prohibited geofence use? No. The prohibition is categorical, so teams shouldn’t rely on an opt-in prompt to authorize a use the law prohibits.
Does deleting the data afterward solve the problem? Not by itself. Deletion may be a remediation step, but the control should prevent prohibited detection, collection, or activation upstream.
What should counsel review first? The facility inventory, the feature’s purpose, the complete data flow, vendor capabilities, and the point at which location is collected or used. That review should reach SDKs and analytics providers as well as advertising tools.
Washington businesses with location-aware products should treat the exclusion as an engineering control, not merely a campaign setting. A focused review of location data, vendor agreements, and product behavior can reveal whether a feature needs redesign before launch.
By Design Law Firm & Legal Consultancy, PLLC advises Washington businesses on MHMD data-flow reviews, privacy notices, consent design, retention, and vendor agreements. Companies assessing location-based products can visit By Design Law Firm & Legal Consultancy, PLLC to discuss a Washington-specific review. Contact our law office at (206) 593-1519.
