There are battles that do not make sense. This is one of those cases.
In a civil dispute over fraudulent investments, the Plaintiff brought a motion to compel the Defendant to “Bates Label” electronically stored information in native file format, because the local Discovery Practices Handbook required Bates numbering of ESI. U.S. Holdings, Inc. v. Suntrust Bank, 2011 U.S. Dist. LEXIS 29956, at 13-14 (S.D. Fla. Mar. 23, 2011).
The Defendant countered that to “Bates Label” their prior discovery produced in native file format, they would need to re-produce it as TIFF’s for branding of Bates Labels. U.S. Holdings, Inc. at *13. Moreover, the conversion costs would be between $16,000 to $75,000. Id.
The Plaintiff’s counter argument was $16,000 was not overly expensive given the claims in the lawsuit (notice no mention of $75,000). U.S. Holdings, Inc. at *13.
The Court stated that the local “Discovery Practices Handbook” required ESI to be produced with Bates Labels. U.S. Holdings, Inc. at *13.
However, the Court denied the Plaintiff’s motion to compel, but ordered all future ESI productions to be Bates Labeled (and by default converted to a static image and therefore driving up the costs of discovery). U.S. Holdings, Inc. at *13-14.
The Court explained that the Plaintiff did not counter the Defendant’s argument that Bates Labeling of ESI requires conversion of native files to TIFF or PDF. Id.
The Court specifically held:
It appears that there was no objection to the production of ESI in native format; and, it appears that the vast majority of the ESI produced is not directly relevant to the claims and defenses in the case at bar. Therefore, at this stage of the litigation, and under the circumstances of this case, Defendants are not be required to Bates label the ESI already produced. However, any future production of ESI shall be Bates labeled.
U.S. Holdings, Inc. at *13-14.
Bow Tie Thoughts
Any default local “discovery handbook” requiring ESI to be converted to a static image for “Bates Labeling” needs a date with a recycle bin.
First, Federal Rule of Civil Procedure Rule 1 states the following, in relevant part:
These rules govern the procedure in all civil actions and proceedings in the United States district courts… They should be construed and administered to secure the just, speedy, and inexpensive determination of every action and proceeding. (As amended Dec. 29, 1948, eff. Oct. 20, 1949; Feb. 28, 1966, eff. July 1, 1966; Apr. 22, 1993, eff. Dec. 1, 1993; Apr. 30, 2007, eff. Dec. 1, 2007.)
Any interpretation of a “Discovery Handbook” that can increase the cost of litigation $16,000 to $75,000 clearly violates the first rule of the Federal Rules of Civil Procedure that cases be “administered to secure the just, speedy, and inexpensive determination of every action and proceeding.”
Second, Federal Rule of Civil Procedure Rule 34(b)(2)(E) states, in relevant part:
(i) A party must produce documents as they are kept in the usual course of business or must organize and label them to correspond to the categories in the request;
(ii) If a request does not specify a form for producing electronically stored information, a party must produce it in a form or forms in which it is ordinarily maintained or in a reasonably usable form or forms; and
(iii) A party need not produce the same electronically stored information in more than one form.
Jannx Med. Sys. v. Methodist Hosps., Inc., 2010 U.S. Dist. LEXIS 122574, at *8 (N.D. Ind. Nov. 17, 2010).
The above interpretation of the “Discovery Handbook” stands directly opposed to Federal Rule of Civil Procedure Rule 34(b)(2)(E).
The issue of “Bates Labeling” electronically stored information is understandable given the decades of legal assistants stamping paper documents. However, that dogmatic practice has come to an end with electronically stored information. Data cannot be forced into a paper model of production that 1) drives up the cost of discovery and 2) violates the Federal Rules of Civil Procedure. Just imagine converting an Excel file with multiple tabs and fields to a static image solely for the sake of branding a number on it.
The issue of “Bates Labeling” is solved with 1) Assigning records control numbers and 2) Producing MD5 or SHA5 hash numbers as production fields with metadata. These digital fingerprints are the 21st Century way to address these issues, not compounding the cost of discovery by converting searchable native files to static images for the sake of branding them with a number.
Parties should discuss at a meet and confer how ESI should be produced. There is nothing that should stop parties from determining that “Bates Labeling” of ESI is producing a hash value, reported to the Court in a joint statement, which can be codified as a court order at a Federal Rule of Civil Procedure Rule 16(b) conference.
The future is now. We should not limit discovery “Bates numbers” to paper productions of the 1950s with the technology available today.
I’m afraid this post may lead folks into serious issues. The implicit endorsment of producing data in native format comes without any discussion regarding the myriad of problems (and increased costs) that can accompany producing in native. Off the top of my head, these include the inability to place “confidentiality designation” endorsements on each page of documents which might warrant such treatment, the fact that native documents are inherently editable–on purpose or by accident, the increased review burdens that can be created by the need to review for hidden content or metadata which is irrelevant, privileged, or otherwise not discoverable and would be screened out during the processing phase when producing non-native data, the inability to redact where appropriate, and the need for control copies that can be used in depositions and hearings. Obviously, there are ways of coping with the problems identified above, but these always come with additional cost and case management burdens. While a local rule requiring bates labeling is probably inappropriate, producing in fully searchable .tifs, with an appropriate load file, and OCR for all “scanned” documents complies with the discovery act, and, in many cases, is a cost effective way of producing data. In my view, it is most important that the parties are meeting and conferring and agreeing on these form of production issues early, and bringing them to the judge’s attention before production if an agreement proves impossible. Bottom line, native productions are not always cheaper or better.
Thank you for your thoughtful comment. I think we are in agreement about form of production concerns and that a meet and confer is the right place to determine the best form of production.
In my opinion, there is a problem with parties converting ESI to a static image as a default standard form of production, because of a “discovery handbook.” I have not seen a service provider that charges less for processing ESI as static images than producing ESI in native file format.
You are correct that redaction issues may require conversion, however, I think parties should begin the discussion with producing native files in the form they are ordinarily maintained. If there is confidential information, such as HIPPA, social security numbers, trade secrets, etc, the parties must discuss the best form of production for their case at the meet and confer.
Again, thank you for your comment.
Great insight. It is silly that we continue to convert “fully-enabled” ESI to “lesser” formats. I understand the arguments against native data, but almost all of those tie back to the “because that’s the way we’ve always done it!” defense.
Native is not perfect – in fact, the whole eDiscovery (and discovery) process is pretty messy. But with the enormous volumes of data that we have, the growing importance of metadata, the inability to properly convert some data types to image formats (e.g. spreadsheets, structured data, etc.) and the loss of linkages in that conversion – native just makes sense as the default. We can deal with images and/or paper printouts and/or bates stamps as the exception when it’s needed. Not vice-versa.
I don’t do complex civil litigation, and I probably never will have a case involving e-discovery, but my 1st thought is, if someone wanted me to produce my Excel spreadsheets in the form of still, static, non-manipulable, non-searchable .tiff files, I would jump at the chance. Likewise even as to files that might not be as potentially useful as spreadsheets, but might contain metadata, such as my word processing files and e-mail (.eml) files.
And I certainly never would demand that an adverse party convert their files into something less useful than the originals before ending them to me.
I second Mr. Shook’s position, and question whether the “the myriad of problems (and increased costs) that can accompany producing in native” are a valid concern in most cases. The key for me in this decision is the court’s statement that “the vast majority of the ESI produced is not directly relevant to the claims and defenses in the case at bar.” The Defendant gets an overbroad request and responds to it in the cheapest manner possible by producing native. This eliminates conversion costs and greatly reduces production costs (and also avoids the cost of fighting over the overbreadth of the requests). I’ve been in this position and have responded exactly the same way. I do consider whether this approach will work with the data set: do I have to redact many documents? are there significant privilege issues or is the data set run-of-the-mill business docs and e-mail? I’m not concerned about editability of the native files because I retain a copy of what was produced and can hash if needed. And I’m not concerned about “control copies” because, as the court noted, the vast majority of these docs won’t ever be used by anyone. If I have to redact a few documents, I’ll image just those docs.
Control numbers or hash numbers work fine.
By the way, I recently produced a subtantial amount of mixed ESI in native format in response to a request for production that specifically requested native in the instructions. Opposing counsel then complained about the production and said he had to pay a vendor to TIFF all the files to load into Concordance. He was not aware that the instructions in his document requests demanded native format. This is a reminder that meet-and-confer discussions don’t always eliminate problems because counsel might be asking for things they heard about at a CLE without understanding the ramifications.
Bravo, Josh, on a great post conveying the right message. The millions upon millions of dollars wasted to get Bates numbers on production that may never be used in a proceeding just cannot be justified by the specious Bogeyman-style arguments thrown against native production. I really question whether TIFFing unnecessarily is a negligent waste of client funds unless the client is fully and fairly informed about less costly alternatives and consents in writing to the excess expenditure.