In Episode 115, our CEO, Kelly Twigger discusses the first of several disputes about the language of the parties’ ESI protocol and the court’s input on search terms, privilege log and several other key issues in In re Meta Pixel Healthcare Litigation.
Introduction
Welcome to this week’s episode of our Case of the Week series brought to you by eDiscovery Assistant in partnership with ACEDS. eDiscovery Assistant is a platform that helps lawyers and legal professionals leverage the power of ESI as evidence by reimagining how to conduct research for eDiscovery, as well as training in eDiscovery.
My name is Kelly Twigger. I am the CEO and founder at eDiscovery Assistant, as well as the principal at ESI Attorneys. Each week on our Case of the Week series, I choose a recent decision in ediscovery and talk to you about the practical implications of that judge’s ruling, what it means for you, your practice, and for your clients, and how to do the discovery of ESI better.
Unlike any other substantive area in the law, the constantly evolving landscape of technology means that trial courts on both the federal and state level are regularly issuing new opinions on parties’ obligations around ESI. Because the bulk of our learning in ediscovery comes through case law, diving into the details of those decisions and what our practical takeaways are is one of the best ways to understand the issues and details we need to focus on in planning and executing any discovery.
Before we dive in, if you haven’t yet had a chance to grab our 2022 Case Law Report, you can download a copy of that to see the landscape of decisions. Each of the decisions in eDiscovery Assistant is a public link, meaning that you can link to those decisions in your writing. You can also review the full text of the decision without having a subscription to log in.
Background
This week’s decision breaks down the Court’s review of the party’s proposed ESI protocol in the In re Meta Pixel Healthcare Litigation that is pending in the Northern district of California. It comes just as we are releasing our Practical Guide on drafting a thoughtful ESI protocol this week. If you’re interested in receiving a copy of the guide, you can download it here.
As always, we tag each of our decisions in our eDiscovery Assistant database by our proprietary issue tagging structure. This week’s issues include privilege log, search terms, ESI protocol, and scope of preservation.
Facts and Analysis
Let’s dive into this week’s decision. As I mentioned, it comes from the In re Meta Pixel Healthcare Litigation. This one is from United States Magistrate Judge Virginia DeMarchi. Judge DeMarchi is extremely prolific on eDiscovery issues, and she has 103 decisions in our eDiscovery Assistant database. She’s very knowledgeable and really forces the parties to sit down and look at the details. That’s one of the reasons that I wanted to pick out this case for you today.
Usually on our Case of the Week, we split up our facts and the analysis but because the Court is looking at proposed ESI protocol provisions in this decision, the facts and analysis are very intertwined, so we’re going to cover those together.
What are the underlying facts of the case here? The plaintiffs alleged that Meta improperly acquired their confidential health information in violation of both state and federal laws by means of a tracking tool called the Meta pixel. Each of the plaintiff’s healthcare providers allegedly installed this pixel, which is a piece of code that goes on a website, on their patient portals and in other places on their websites. Plaintiffs claim that when they logged into the patient portal or engaged in other activity on their healthcare providers websites, the pixel transmitted certain information to Meta that is then sold by Meta to its business partners. Those are the underlying facts of the case.
We are before the Court here on multiple issues in dispute over the parties’ proposed ESI protocol. This decision lists seven different areas of dispute, but not all of them are resolved on this decision.
There are multiple decisions on discovery in this particular case in the eDiscovery Assistant database, and we’ll probably cover some of the subsequent ones later, just because the process of how this ESI protocol comes about is very interesting.
I chose this decision to review because of what the Court requires of the parties is one of the best and most efficient ways for discovery to be conducted, with some limitations and some caveats. For judges across the country, I’d love for them to use this as an example of what the party’s responsibilities are in discovery, specifically as it pertains to search. It also highlights the issues that parties need to be thinking about in a protocol and the value of each.
Let’s dig into those seven areas, the first of which is preservation. The Court starts here by telling both parties that it’s disappointed that neither one of them have made a full disclosure of the potential sources of ESI or why certain categories of ESI need to be preserved before the date the Court set for submission of the parties’ proposals for an ESI protocol. Instead, according to the Court, Meta came to the Court seeking to have a list of sources that did not need to be preserved, and the Court balked at that. Instead, the Court declined to enter “an order affirmatively relieving Meta or any party of whatever obligations it may have otherwise have to preserve the specific data sources.”
This is interesting because it is in contrast to the model order in the Northern district of California, which was drafted, I believe, in 2015, and is in desperate need of updating. But that order specifically lists sources of ESI that are inaccessible and not required for preservation. The fact that the Court took a different stance here and said to Meta, “I’m not going to specifically exclude sources of preservation, you guys need to sit down and talk about them” is telling.
The Court also dismissed plaintiff’s position that “all relevant evidence must be preserved unless a party seeks a protective order,” calling that approach “fundamentally inconsistent with the cooperative approach contemplated by this district’s ESI guidelines.” Instead, the Court ordered the parties to meet and confer about their respective sources of relevant and responsive ESI, and to come to an agreement on all of those sources, if possible, and whether a party wish to be relieved of whatever obligations it has to preserve specific data sources or categories of ESI. The Court also required the parties to explain to the adverse party why those sources or categories need not be preserved.
That’s where the Court came down on preservation, and that’s an excellent guidepost for parties. Essentially, the Court saying, Hey, I’m not going to take anything off the table. You guys have to sit down and talk to each other and determine where the sources of relevant and responsive ESI exist, and if you have sources that don’t contain responsive information or for proportionality reasons are difficult to get to, then you need to have that discussion and all those facts need to be on the table. Putting all those facts on the table is something that we rarely see in litigation, particularly in asymmetric litigation like we have here.
Next topic that the Court moved to is search. This is one that I think was really important and primary reason that I chose this decision. As we see regularly in case law, the parties here could not agree on the process for applying search terms or for the use of technology-assisted review. The Court does something here that I’ve not seen before — it essentially lays out for the approach that it will adopt since the parties have not agreed. The Court’s approach puts the obligation on the producing party to use data to identify appropriate search terms for a request and to test those terms and provide the data for the other side to review and follow up. If the Court had made that process a mandatory requirement for both sides, we’d be in good shape, but it didn’t really.
Specifically here, the Court puts together an iterative process for determining search terms that puts the burden on the producing party to identify search terms responsive to specific requests and its obligations under Rule 26, using the following steps: first, each party must disclose the custodial and noncustodial ESI data sources it reasonably believes contain information relevant to the claims and defenses asserted in the action and proportional to the needs of the case, taking into the account the request for discovery that producing party has received, as well as the type of ESI for each data source.
Next, once disclosed, the other side may propose additional sources and the parties must meet and confer on issues. So that’s your process. Regarding the use of search terms, however, the Court noted that a party may use search terms to identify responsive documents, but it is not required to. However, if a party does use search terms, it is required to disclose that it intends to use those search terms to the requesting party with a hit report that includes unique hits, hits with families, and the total number of documents hit for the search terms applied to each data source.
In preparing its proposed search terms, a producing party “may” review a “null set sample for each data source.” This is again part of the Court’s steps on the parties using search terms here. The null set sample is a statistically valid, randomly generated sample set of documents from a given data source that do not hit on any search terms, which the producing party reviews for relevant, responsive, and non-privileged documents. At the time the producing party discloses its proposed search terms to the receiving party, it “may” provide the results of its review of the null set sample, i.e., a disclosure of how many relevant, responsive, and non-privileged documents from the null set sample were not captured by the proposed search terms in order to demonstrate the effectiveness of its proposed search terms. Once that information is provided by the producing party, the receiving party has time to provide additional terms as part of the iterative process.
This iterative process would be fantastic, except for one major flaw, which you may have noticed by the air quotes I used. The Court does not “require” the review of the null set sample to ensure the value of the search terms, and the value of hit reports with no other data is really very low for a receiving party. Hit reports are of value to the producing party, but only really with additional data. To accomplish what the Court wants to have happen here, it needed to require the producing party to review the null set data for data sources to ensure that the search firms were providing responsive information. By using the language “may” instead of “shall” or “will”, the Court has basically given the producing party an out on search.
The Court also addresses the language on the use of technology-assisted review, and the Court includes language in its proposed Appendix A attached to this order for the parties to include in their ESI protocol. That language on TAR allows a party to use TAR to filter out or exclude non-responsive documents. If a party does use TAR to filter out or exclude non-responsive documents, it must disclose, 1) the custodial and noncustodial data sources against which TAR will be run; 2) the TAR tool being used and the name of the vendor; and 3) the measures used to validate the results of the TAR methodology. Keep in mind that the Court said “must” here, so this is the place where that information has to be disclosed.
However, a producing party need not disclose whether it is using TAR, continuous active learning, or other predictive coding tools merely to prioritize the review of ESI. That’s a little bit of a bizarre distinction because TAR generally would be employed for both filtering out non-responsive documents and prioritizing review at the same time. I’m not really sure what the Court is getting at with that distinction here. But I do like the fact that the Court requires the parties to exchange those three pieces of information about TAR. That’s where we come out to on search and TAR as far as the party’s ESI protocol goes.
The next topic the Court takes up is privilege logs. The Court really requires the parties to include what they’ve already negotiated to date in the protocol, and those include the following: that communications involving trial counsel of record that postdate the filing complaint need not be logged (that’s fairly standard); that the logs will comply with Federal Rules Civil Procedure 26(b)(5) for all documents withheld or redacted on the basis of privilege, attorney work product, or any other basis, and produced in Microsoft Excel; and that the parties will negotiate interim and final deadlines for the production of privileged logs that permit any disputes about claims of privilege or work product protection to be addressed in advance of the close of discovery. Very important language.
This language on privilege logs is much more detailed than is often provided for in an ESI protocol, and it’s good. Requiring redactions to be logged is really key, we’ve talked about this multiple times, and I’ve written about it. It’s also included in a special section in our ESI Protocols Practical Guide that’s coming out this week. It’s very important to log redactions, and it’s also important to include two metadata fields with that logging. One that shows a yes/no for redaction on a document, and the other that lists the basis for redaction. That allows the receiving party to be able to filter by information that has been redacted and then be able to review those redactions quickly. That’s important because under this ESI protocol, the Court sets out specific deadlines by which the receiving party has to respond to issues it believes have not been presented correctly by the producing party. That’s where the Court comes down on privilege logs, again, including that redaction, which I think is key.
The Court next addresses hyperlinked documents. If you’ve seen the webinar that we did recently with ACEDS and Onna on modern attachments, you know that the Court here is referring to the links and e-mails or other communications as hyperlinks instead of as perhaps pointers, which is one potential language replacement for that hyperlinks. The problem with using hyperlinks to describe pointers to documents is that hyperlinks can also be links out to other areas on the web that don’t necessarily include a document that would otherwise be considered an “attachment”. I use air quotes on attachments because that’s how we normally consider documents that would be physically attached to an email. This, again, is an issue of language that is not resolved and needs to be, and the Court referring to the hyperlinked documents here just really emphasizes that necessity of the clarity of language that is needed.
The plaintiffs here want all of the hyperlinked documents produced with the documents that include the link. Essentially, if there’s an email that has a link in it, we want the document attached to the e-mail as an attachment. At this point, Meta says that it needs more time to figure out its potential compliance. Keep in mind this decision is dated May 18th, 2023, and the Court orders the parties to meet and confer on the open and remaining issues for presentation to the Court at a May 23rd hearing. That’s only five days later, and Meta is not going to get a lot of time to figure out the answers to these questions that it needs.
That is an open issue yet on the ESI protocol that is actually addressed in a subsequent decision in this case.
The next issue before the Court is email threading, and this is one we’ve talked about previously on Case of the Week, and we’re creating content for the eDiscovery Academy. The parties here are agreeing to produce only the last in-time email of an email thread versus each of the emails in a thread as separate documents. What remains at issue is whether Meta can produce the metadata for each of the underlying emails. You’re familiar with an email thread, I’m sure you can open your inbox and see one where the last in time email is the last email that was received, and all of the other emails that are on that thread are below it. It’s incredibly voluminous to review documents one email stacked at a time. The first e-mail and then the first e-mail and the second e-mail, and then the first e-mail, second e-mail, third e-mail. What they’re proposing is just take the last one and give that to the other side and it’s got everything else included. The issue, though, is you need to be able to sort information. The plaintiffs here are asking for the metadata associated with all of those lesser included e-mails. Meta is telling the Court here that it needs more time to be able to resolve that issue. The Court leaves that one for resolution at the May 23rd hearing, again, just a few days after this decision.
The final issue for the Court is some language that was proposed by Meta to be included in the protocol about technical feasibility. I said that it was proposed by Meta. It’s not actually stated in the decision who proposed it, I’m just reading between the lines here to be able to say that that was likely proposed by Meta. Essentially here, the party who proposed it wants to include a get-out-of-jail free card that says a party will only comply “to the extent it is reasonably and technically feasible.” And the Court basically says no. In fact, its exact words are,
the ESI protocol should not include provisions that state that a party will only comply to the extent it is reasonably and technically feasible. This invites mischief. While the Court hopes and expects that the ESI protocol will not require any party to undertake obligations that are not ‘reasonably and technically feasible’, a party that encounters unexpected difficulties in complying with the protocol should alert the adverse party about the problem and propose a solution.
I love that the Court stood up and said, no, this is just going to be problematic because you’re just going to hide behind what is not technically feasible. I see that being an issue specifically with the pointers or the hyperlinked documents as the Court refers to them here. I love that the Court shut down that particular language and has specific requirements for for the parties.
Takeaways
What are our takeaways here? What the Court requires here is exactly what should happen, specifically as it relates to preservation and part of what the Court said on search. Both the parties should be coming to the table with the potential sources of ESI and discussing where relevant information lives and what the technical issues are to be addressed at the outset of the case before the ESI protocol is in place —before, before, before. That the Court is requiring the parties to hash out each of these very important issues is key, and we need to see more of this from the courts.
That being said, it’s incumbent on the parties to raise these issues with the courts. But I love that we’ve got Judge DeMarchi, who’s so well-versed in these issues and handling them and walking the parties through what they need to do to comply. But I am disappointed that the Court gave the parties an out on the Court’s plan for exchanging search terms and data around whether those terms will reveal responsive information. By using “may” instead of “shall” or “will”, the Court gives both parties, but primarily Meta here, as it has the bulk of the data, the opportunity to beg off the requirement to use a null set to demonstrate the viability of the proposed search terms. That leaves plaintiffs or any receiving party in the same position it would be in if it was required to select search terms out of the blue. This plan just lets the producing party pick the terms with the Federal Rules as the bar.
We need courts to hold parties accountable for what needs to happen in discovery so we can stop litigating each of these arguments. There are consistent, technological ways to identify search terms and to test those terms that are not expensive. Cost is not a barrier here. This case is asymmetric litigation, as I mentioned earlier, which means that one party bears the primary burden for all discovery. But the reality is that we need one standard on process to apply to across all types of cases. It is tempered by proportionality and the relevance requirements of the Federal Rules, and those are sufficient boundaries. Using the phrase “may” here instead of “shall” or “will”, will to preclude the open exchange that the Federal Rules require.
Conclusion
That’s our Case of the Week for this week. Thank you so much for joining me. We’re back again next week with another decision from our eDiscovery Assistant database. As always, if you have a suggestion for a case to be covered on Case of the Week, drop me a line. If you’d like to receive the Case of the Week delivered directly to your inbox via our weekly newsletter, you can sign up on our blog. If you’re interested in doing a free trial of our case law and resource database, you can sign up to get started.
Thanks so much, and have a great week.
