Washington My Health My Data Act - Part 9: The Attorney General’s Guidance

By Mike Hintze

This is Part 9 in a series of blog posts about the Washington My Health My Data Act. Previous parts include:

 This part discusses the highly-anticipated, but non-binding, guidance published by the Washington State Office of the Attorney General.

On Friday, June 30, the Washington State Office of the Attorney General (OAG) published its expected guidance on the Washington My Health My Data Act (MHMDA or the Act) in the form of seven “frequently asked questions.” Given the many ambiguities in the Act, this guidance has been eagerly awaited in the hope that it would provide some much-needed clarity.  And while it addresses one of the biggest areas of ambiguity and concern (the effective dates) and provides some useful insights into a handful of others, it, unfortunately, left many questions unanswered.

Further, to understand the impact of this guidance, it is important to note that the Act does not give the Attorney General formal rulemaking authority. Nor is this guidance a formal Attorney General opinion. In fact, the text at the end of the guidance reinforces its informal and nonbinding nature:

This FAQ may be periodically updated and is provided as a resource for general educational purposes and is not provided for the purpose of giving legal advice of any kind.  Readers should not rely on information in this guide regarding specific applications of the law and instead should seek private legal counsel.

Thus, it is clear that this guidance does not have the force of law. And judges may feel free to ignore it if they determine the language of the statute leads to a different interpretation.

Nevertheless, particularly because the Act originated with an Attorney General requested bill, and the OAG played a key role in the formulation of the legislation, the views of that office are likely to be taken as persuasive. Therefore, this guidance may give organizations seeking to comply with the law greater comfort that a particular interpretation may prevail. As such, these FAQs should be carefully considered by those seeking to develop MHMDA compliance plans.

Effective Dates

One of the most troublesome and concerning aspects of the Act is the way the effective dates were added to the statute. As discussed in Part 4 of this blog series, in several instances, effective dates were added to only the first subsection of a section in a way which, if read literally, would seem to apply to only that first subsection and not the subsequent parts of that section. Because those subsequent subsections were silent on effective dates, under Washington law, where an effective date is not stated in legislation, the relevant provisions come into effect 90 days after the end of the legislative session. In this case, that would be late July of this year. That literal interpretation, however, would lead to several absurd results.

The legislative history, as well as statements made by key players in the legislative process, suggest this problem was a drafting oversight and that the effective dates were intended to apply to the entirety of each section in which they appear. FAQ 1 of the new guidance, as expected, reflects that interpretation.

It states that for most of the substantive sections of the Act (i.e., sections 4-9), the requirements will come into effect March 31, 2024, with a delay until June 30, 2024, for those regulated entities that meet the definition of a “small business.” Only the prohibition on geofencing in section 10 of the Act, which is entirely silent on affected dates, will come into effect in late July of this year.

This guidance should give some comfort to companies that have been working on compliance but have realized that meeting many of the substantive obligations requires work that could not possibly be completed by late July of this year. Of course, because this guidance is not binding law, it is still possible that plaintiffs’ lawyers will seek to test this issue by claiming that the plain, literal reading of the statute results in a much earlier effective date for many of its substantive obligations. If aggressive plaintiffs seek to pursue such claims, this guidance should strengthen defensive arguments that such an overly-literal interpretation is contrary to legislative history and intent and, therefore, should be rejected.

The Scope of Consumer Health Data

As discussed in Part 2 of this blog series, the definition of “consumer health data” is extraordinarily broad and raises a number of questions about just how expansively it can be construed. FAQs 5 and 6 attempt to shed some light on the scope of consumer health data. But they focus on only two areas and leave a large number of much more significant ambiguities unresolved. 

FAQ 5 addresses the question of whether information about the purchase of toiletries (deodorant, mouthwash, toilet paper, etc.) constitute consumer health data because they relate to “bodily functions.” The OAG states that “ordinarily, information limited to the purchase of toiletry products would not be considered consumer health data.” By way of example, it states that “information about the purchase of toilet paper or deodorant is not consumer health data, an app that tracks someone’s digestion or perspiration is collecting consumer health data.”

Unfortunately, this guidance does little to provide much clarity or to constrain the potential sweeping scope of consumer health data.  

First, the general statement quoted above is qualified by “ordinarily” – suggesting that there are exceptions.  What are those exceptions? How many are there? Could the exceptions swallow the rule?

Second, the examples offered for what falls outside the scope reflect only an extreme benign end of the range of common product purchase information that could constitute consumer health data. Virtually every person purchases and/or uses toilet paper and deodorant, and the purchase of such products does not reveal anything about a person’s health. And even if it did, from a risk perspective, it is highly unlikely that the OAG would pursue a case involving such benign data or that a plaintiffs’ counsel could demonstrate any injury supporting a recovery in litigation. 

But what about the other types of purchase information connected to health, wellness, fitness, or nutrition which, though various elements of the “consumer health data” definition, are arguably covered? What about purchases of running shoes, low-calorie or high-fiber foods, exercise equipment, vitamins, meditation recordings, or gym memberships?  These are examples that have been raised in this this blog series and elsewhere but, unfortunately, they are not addressed in the FAQs and the questions being raised about them remain unanswered. 

Third, the examples provided for what is covered, if anything, reinforce the extremely broad nature of consumer health data. We already knew that those involved in the drafting of the bill were focused on certain data collected by applications. The clearest example, which was raised several times by bill supporters in testimony and elsewhere, is menstruation tracking apps that could reveal pregnancy.  Here, the FAQ states that apps that track “digestion or perspiration” are also covered.  Unlike menstruation, digestion and perspiration is something that every person does virtually every day. And perhaps with some exceptions at the extremes, such information, by itself, is not likely reveal any particular health status or condition. These examples thereby suggest that the “bodily function” aspect of the definition will be interpreted very expansively by the OAG.

FAQ 6 addresses inferences. It was already reasonably clear that inferred health data is in scope.  Supporters’ testimony and other statements made thorough the legislative process repeatedly cited the 2012 example were Target used purchase data related to a range of products to predict the likelihood that a consumer is pregnant. And this FAQ repeats that example and reiterates that such an inference is consumer health data. FAQ 6 notes that even health-related inferences made from the purchase of toiletries, tying back to the examples of non-health data cited in FAQ 5, would be consumer health data.

Interestingly, FAQ 6 concludes with the following: “In contrast, nonhealth data that a regulated entity collects but does not process to identify or associate a consumer with a physical or mental health status is not consumer health data.” Clearly, the inference of a physical or mental health status itself is consumer health data. But if non-health data is used to draw that inference, does that underlying data thereby become consumer health data? The above-quoted statement suggests it might. 

If non-health data is not processed to infer a health status (thereby identifying or associating the consumer with that status), then it is not consumer health data.  The converse of that suggests that if it is so processed, then that underlying (previously non-health) data might be transformed into consumer health data by virtue of it being used to infer health status. Thus, would a consumer have the right to request the regulated entity to delete not only the inference but also the underlying purchase data used to create that inference?  While not squarely addressed by this FAQ, the implication is that it would. 

Together, FAQs 5 and 6 provide some insight into the views of OAG on the definition of consumer health data – reinforcing that it is, indeed, very broad.  But there are many, many other ambiguities inherent in the definition of consumer health data that are not addressed in the FAQs. Hopefully, future updates to the OAG guidance will provide additional insights, but many gray areas will inevitably remain. Organizations will still need to make reasonable, risk-based classifications of the data they collect (and derive or infer) to guide their compliance approaches under the Act.

Resolving the Conflict Between Retention and Deletion Obligations

As described in Part 6 of this blog series, MHMDA gives consumers broad rights. And the right to have consumer health data deleted upon the consumer’s request lacks common exceptions found in virtually every other privacy law – including an absence of an exception for situations in which retention of the data is required by law.  Part 5 of this blog series notes that such a retention requirement exists in the Act itself, setting up an internal contradiction and a potential litigation trap.

Specifically, the onerous “authorization” requirements for any transfer of consumer health data that could constitute a “sale” include the requirements that the authorization documentation contain the consumer health data to be sold and that both the seller and the buyer of the data retain that authorization document for six years.  Thus, if the consumer who provided the authorization thereafter requests that either the buyer or the seller delete their consumer health data, the entity would be in a catch-22 position of having to violate either the deletion obligation or the obligation to retain the authorization containing that data. 

FAQ 7 resolves that conflict by clarifying that in response to such a deletion request, the entity can and should redact the consumer health data from the authorization while continuing to retain the redacted document for the required period.  Given the nature of the conflict, this is a sensible resolution.  Those companies that seek authorizations to sell consumer health data will surely find some comfort in this guidance.  The practical impact, however, is likely to be minimal because the requirements for obtaining a valid authorization remain so onerous that few companies will regularly seek to obtain them.

Privacy Policy Links

FAQ 4 addresses the requirement from Section 4(b) of the Act that a regulated entity must post a link to the required Consumer Health Data Privacy Policy on its homepage. As discussed extensively in Part 8 of this blog series, this seemingly simple requirement includes more than is apparent on its face and raises a number of challenging issues. Unfortunately, this FAQ takes on none of those issues and merely quotes the statutory language on the one, narrow issue it addresses, adding no new insight or information. 

It would have been helpful, for example, if the FAQ addressed whether the link must be direct. In other words, is a “privacy” link to the entity’s general privacy statement, which in turn links to a more specific Consumer Health Data Privacy Policy, sufficient to meet this obligation?  Relatedly, can the Consumer Health Data Privacy Policy be incorporated into the general privacy statement, or does it absolutely have to be a stand-alone document, even if redundant of information that is already in the general privacy statement?  Or it could have addressed any of the other genuinely difficult questions that the Act’s notice obligations raise. Instead, it addressed a question the answer to which was already apparent from the statutory language, as evidenced by the fact that the FAQ did nothing other than repeat that language. 

Update: Subsequent to this post, in early January 2024, the Office of the Attorney General (OAG) updated its (non-binding) guidance to clarify its position on the notice obligations. Specifically, FAQ 4 was changed to state that there must be a “separate and distinct link” on the “homepage” (which is defined broadly to mean, in effect, every page). Further, the update states that the Consumer Health Data Privacy Policy "may not contain additional information not required under the My Health My Data Act," suggesting it must also be a separate and distinct document from the company's main privacy notice.

Scope of Regulated Entities, Extraterritorial Impact, and Data Storage Location

FAQ 3 poses the following question: “How will a business located outside of the state of Washington but that stores its data in Washington be impacted?”

The formulation of the question suggests that it would address one of the more opaque but hugely impactful issues raised by the Act – the extraterritorial range of “consumers” whose data is within the scope of the Act (created by the odd definition of “collect” – as described below). But it did not. Instead, it mainly focused the scope of regulated entities covered by the Act.  Both of these issues are separately discussed in Part 3 of this blog series, but it appears as if the OAG’s FAQ 3 conflates them. 

Here too, the FAQ reiterates the statutory language to answer the question it poses:

Subject to some exceptions, a regulated entity is a legal entity that (a) conducts business in Washington, or produces or provides products or services that are targeted to consumers in Washington and (b) alone or jointly with others, determines the purpose and means of collecting, processing, sharing, or selling of consumer health data.

Clearly, to be a regulated entity, an organization must meet both of those two prongs from the statutory definition. If it does, it is a regulated entity subject to the Act.  If it does not, it is not a regulated entity. So, the next statement in the FAQ should come as no surprise: “An entity that only stores data in Washington is not a regulated entity.” Of course, it isn’t – unless it meets the two prongs of the statutory definition.  Whether or not an organization stores data in Washington is irrelevant to the question of whether the organization is a regulated entity that is subject to the Act. And nobody who has carefully read the statute has ever suggested otherwise.

But location of data storage is relevant to the definition of “consumer.” That is because a consumer is defined as “(a) a natural person who is a Washington resident; or (b) a natural person whose consumer health data is collected in Washington” (emphasis added). “Collect” in turn, is defined as “to buy, rent, access, retain, receive, acquire, infer, derive, or otherwise process consumer health data in any manner” (emphasis added). And finally, “process” means “any operation or set of operations performed on consumer health data.” The breadth of these cascading definitions suggests that consumer health data from an individual with no connection to Washington could be subject to the Act if the data is stored in Washington. That is, if the data is stored in Washington, it would be “processed” in Washington and, therefore, “collected” in Washington, making that individual a “consumer” for purposes of the Act. 

So why is data location important?  Not because it impacts whether an organization is a regulated entity subject to the Act, as the question posed in this FAQ suggests.  But rather, because it impacts the entirely separate question of how many individuals’ data would be subject to the Act. This is an important question because it can dramatically impact the volume of data that a regulated entity must treat as subject to the Act’s requirements.  And, in light of the Act’s private right of action, it can dramatically impact the size of a potential class of plaintiffs.  If the scope of “consumers” and, therefore, the potential class were limited to only residents of Washington and others whose data was actually collected (in the normal sense of the word) in Washington, that could be a quite small percentage of an organization’s global customer base.  But if it includes all individuals whose data in some way touches Washington state, that could be the organization’s entire global customer base. For plaintiffs’ counsel, this significantly increases their financial incentives to bring claims and litigate. 

Unfortunately, FAQ 3 did not address this much more interesting and impactful question about data location.

It did, however, shed some light on one question raised by the definition of regulated entity.  Recall that the first prong of the definition is that the entity “conducts business in Washington, or produces or provides products or services that are targeted to consumers in Washington.” There is some question about what it means to “target” consumers in Washington. And when the FAQ states that in general, all entities that “conduct business in Washington (or provide services or products to Washington)” may be subject to the Act, it suggests a broad reading of “targeted” – equating targeting with providing. Part 3 of this series suggested that it was likely enough that the company makes its online services or websites avaialble to or accessible by consumers located in Washington, and this language in the FAQ supports that broader reading.

Interestingly, FAQ 3 also points out that two sections – Section 9, which sets out the “authorization” requirement for data “sales,” and Section 10, which prohibits certain uses of geofencing – apply to all “persons” and not just regulated entities and that the scope of “persons” is not limited by geography.  This means that these provisions apply to individual natural persons – and not just businesses and other organizations. And, importantly, they apply to both individuals and organizations located anywhere in the world without regard to whether they conduct business in Washington or provide services or products to Washington. Whether the more extreme examples of potential extraterritorial application will have meaningful, real-world impact remains to be seen. But the potential this creates is quite stunning and fascinating.    

Finally, FAQ 3 states that processors located out of state who are processing data on behalf of regulated entities are subject to the Act. But that was not really in doubt.

Enforcement

FAQ 2 is perhaps the most obvious and, therefore, least interesting of those contained the OAG’s guidance.  It asks: “What is the Attorney General’s role in enforcing the My Health My Data Act?” And it answers with what we stated in Part 1 of this blog series and which anyone who has followed this Act already knows – that a violation of the MHMDA is deemed to be a violation of Washington Consumer Protection Act, which can be enforced by the Attorney General and/or through a private right of action.  Here too, there are a number of interesting issues related to enforcement, which the FAQ does not address. Those issues may be a topic for a further blog post in this series. 

  

Future posts will discuss other aspects of the Act and the issues it raises.