AI fitness coaches cross the consumer-health-data line through their inferences, not just their inputs
"We are just a fitness app" is the most common operator response when MHMDA is raised, and it is the answer most likely to be wrong. RCW 19.373.010 names fitness data as a consumer health data category and reaches "information that is derived or extrapolated from non-health information." An AI fitness coach that reads step counts, heart-rate variability, sleep duration, and recovery scores and generates training recommendations, sleep-quality classifications, or readiness scores is generating consumer health data on every inference cycle. The output sits inside Chapter 19.373 RCW even when the underlying sensor stream is mundane.
Why the inference clause catches AI fitness coaches
Raw step counts, raw heart rate, and raw sleep duration are themselves on the named consumer-health-data list at RCW 19.373.010 (fitness data). When the AI layer reads those streams and outputs a recovery score, a readiness flag, a "you appear under-recovered today" message, or a "you may be developing overtraining" warning, the output is an inferred health status. The inference clause of RCW 19.373.010 brings inferred health status inside the statute. An AI coach that also infers stress, mood, or anxiety from heart-rate variability ranges has crossed into mental-health-information territory.
Five compliance hooks specific to AI fitness coaches
1. Standalone Consumer Health Data Privacy Policy. RCW 19.373.020 requires a Consumer Health Data Privacy Policy as a distinct document, prominently linked from the homepage. For fitness coaches, the policy must specifically address sensor data ingestion (wearable sync), inferred metrics (recovery, readiness, sleep quality), AI-generated recommendations, and any sharing with model providers or analytics partners.
2. Two-layer consent before sensor sync. RCW 19.373.030 requires affirmative consent for collection and a separate consent for sharing. An app that activates Apple Health, Garmin Connect, Whoop, or Oura sync as part of onboarding needs to surface the collection consent before sync starts and the sharing consent before any data leaves the user's account.
3. Wearable integrations are sharing. Pulling data from Apple Health, Google Fit, Garmin Connect, or Strava is collection on your side and a sharing event between the user's data source and your service. The sharing consent must cover both directions if your app sends inferred metrics back to the user's wearable account or to coaching partners.
4. Model providers and training-data exposure. If your AI layer calls OpenAI, Anthropic, Azure OpenAI, or any external API to generate recommendations, that vendor is a processor under RCW 19.373.060. The default vendor terms usually do not satisfy MHMDA on their face; a written DPA addendum or vendor MHMDA-aware terms are required. If the default vendor contract allows training on submitted data, that is a sharing event for which separate consent is required.
5. Geofence and adtech audit. RCW 19.373.080 prohibits geofences within 2,000 feet of in-person healthcare facilities. AI fitness coaches that target ads or in-app notifications based on proximity to gyms or clinics need to verify no SDK uses sub-2,000-foot geofences near healthcare facilities.
Common gaps I find in AI fitness coach reviews
- Privacy policy is generic SaaS boilerplate with one paragraph on health; no standalone Consumer Health Data Privacy Policy exists.
- Consent is one acceptance at signup; the sharing consent for analytics, model providers, or coaching partners is missing.
- The vendor contract is the default API terms; no MHMDA-aware processor addendum exists.
- Training opt-out is unsurfaced; the vendor's default may use prompts and metrics for model improvement.
- Marketing copy claims the product is "not a medical device" or "just for fitness," which does not change MHMDA scope.
- Subject-rights mechanics (access, withdrawal, deletion) are not built into the app; RCW 19.373.040 requires a 45-day response window with one 45-day extension.
The HIPAA carve-out usually does not apply
Most AI fitness coaches are direct-to-consumer products, not HIPAA-covered entities or business associates of one. The exemption at RCW 19.373.100 is data-specific, not entity-blanket. A fitness app that is not HIPAA-covered cannot claim a HIPAA exemption. A fitness app that integrates with a HIPAA-covered employer wellness program may have a narrower MHMDA surface for the covered data flows but remains inside MHMDA for any direct-to-consumer feature, marketing data, or analytics SDK.
Per se CPA exposure
RCW 19.373.090 converts any MHMDA violation into a per se Washington Consumer Protection Act violation. AI fitness coaches handling thousands of Washington users generate per se CPA standing day after day if the policy or consent UX is non-compliant. The remedy is actual damages, discretionary treble damages capped at $25,000 on the enhancement, and one-way attorney's fees to a prevailing plaintiff, with a four-year SOL.
Sergei's practical note
If your AI fitness coach reads any sensor stream and produces any inferred metric, MHMDA reaches the inference. Treat the standalone Consumer Health Data Privacy Policy, two-layer consent UX, and written vendor addendum as the baseline compliance program, deployed before scale, not after the first AG inquiry. Send me the policy URL, the consent UX screenshots, and the model-provider contract. The $125 written email evaluation is the right starting point; the $499 scope memo, $900 memo plus DPA language, or $1,500 memo plus drafted standalone policy follow if the gaps justify it.
Educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar. Nothing on this page creates an attorney-client relationship or is Washington legal advice. Related: MHMDA for AI Health Tools cluster hub; AI symptom checker MHMDA compliance; AI health vendor and processor contracts; AI Health Tool MHMDA Analyzer.