This case is my eDiscovery nightmare.
Worse than a clown with snakes.
Let’s review what happened.
The case involved numerous allegations of discovery wrongdoing against the Plaintiff.
The Defendants brought a motion for “discovery abuses intended to harass defendants, cause unnecessary delay, and needlessly increase the cost of litigation.”
The Defendants claimed they had spent $51,122 in legal fees and expenses related to the Plaintiffs’ “document dump.”
The motion was granted and denied in part. Branhaven, LLC v. Beeftek, Inc., 2013 U.S. Dist. LEXIS 13364, 13-14, 22 (D. Md. Jan. 4, 2013).
It Started Like Any Other eDiscovery Dispute…
The litigation had the “traditional” eDiscovery dispute with the Plaintiffs not producing email ESI, because they had not accessed the information, and other significant production delays. As the rather hot bench explained:
Plaintiff’s delay in addressing the lack of access to these email servers is inexcusable. There is no more obvious and critical source of information in the 21st century than a company’s email accounts. Plaintiff’s counsel’s failure to identify and produce this discovery in a timely fashion and in an acceptable form and manner while suggesting — if not misleading defendants — that it had identified responsive documents is sanctionable.
Branhaven, at *13-14.
Things continued to be problematic for the Plaintiffs, who claimed ESI from laptops would be produced in what the Court described as “blithely” assertions that discovery would be produced “at a mutually convenient time.” In reality, the subject laptops had not been sent to the client (presumedly to for review, raising the issue why hadn’t the hard drives been imaged), until a new associate attorney found them. Branhaven, at *14. Their conduct ultimately resulted in sanctions in the form of fees and costs.
…and then Came the PDFs and Whether the ESI Should Have Been Produced as TIFFs with Bates Numbers to be in a Reasonably Useable Form
The Plaintiffs produced their ESI as PDF’s. The Defendants challenged the production, because the production was untimely and not in TIFF format with Bates Numbers on every page. Branhaven, at *14-15.
The nightmare of a TIFF over a PDF production with Bates Stamps included the Plaintiffs arguing that the discovery request did not request Bates Stamps; nor is it an express requirement in the Federal Rules of Civil Procedure, case law or the local discovery guidelines. Branhaven, at *16.
Moreover, the Protocol for Discovery of Electronically Stored Information (Local Rules of District of Maryland) which states that TIFF is the preferred format is only advisory. The Court called this a “weak defense.” Id.
The Court stated the following on the production:
Moreover, as defendants point out, Fed. R. Civ. P. 34(b)(2)(E)(ii) provides two options regarding the form in which a party may produce documents and plaintiff did not satisfy either. The July 20 production was not in a form “in which it is ordinarily maintained” or in “a reasonably usable form” — as Mr. McNeil showed (especially considering the lateness of the production with depositions looming in a few days). The Advisory Committee Notes to Rule 34 warn that: “[a] party that responds to a discovery request by simply producing electronically stored information in a form of its choice, without identifying that form in advance of the production in the response required by Rule 34(b) runs the risk that the requesting party can show that the produced form is not reasonably usable . . .” (emphasis added). That is precisely what happened here. Branhaven did not advise of the intended form of its production in its March response. Defendant was blindsided by the volume of the documents (since the prior productions consisted of 388 pages). Moreover, defendants had every reason to think that the documents would be completely Bates-stamped, as prior productions were and further defendants had no reason to think that this production would be so incredibly voluminous, as to require special arrangements and explicit agreement.
Branhaven, at *16-17.
The crux of production issue was whether or not the PDF’s were in a reasonably useable form. The Court held they were not, because of the lack of Bates Numbers and the fact they were not in TIFF format. Branhaven, at *17. Additionally, because of the production, the Court awarded the Defendants “the reasonable litigation support costs involved in receiving and processing” the document production. Branhaven, at *19.
Bow Tie Thoughts
Why is this a case a nightmare for me? Because it applies a paper model of discovery to electronically stored information, requiring a conversion of ESI into a TIFF with Bates Stamps (a conversion which can triple processing costs with some service providers). What is even stranger about it is the form of production battle centered on PDFs vs TIFF, both of which are static images. One difference is a PDF can be either non-searchable (thus like a TIFF) or searchable (thus more like a native file).
Demanding electronically stored information be converted to a static image with Bates Numbers is right up there with demanding MP3s be reversed burned to 8 Track. A party should have a good reason to take a native file, that is fully searchable and strip its searchable features. This truly makes it like a piece of paper, rendering the review tools that can do everything from sorting data in chronological order to technology assisted review be useless. It is like trying to fuel a hybrid car with coal.
Removing ESI’s searchable features also violate the Federal Rules of Civil Procedure and a substantial body of case law.
Moreover, claiming there is a functional difference between PDF vs TIFF as static images is like fighting over VHS vs Beta. The problem with such fights is we are in the 21st Century and not the 1970s. It is almost like arguing Beta is better than Video on Demand, because the issue is not the form, but whether you can analyze the content.
What drives these all too frequent fights? It is attorneys who want pieces of paper to have Bates Stamps. This worked up until the 1990s, but we now live in a world where the content on a smartphone can fill the first floor of a library. Data needs to be reviewed as data for there to be any chance to meaningfully understand its content. Moreover, as to the Bates Numbering to organize the ESI issue, native files can have a “control number” that is the functional equivalent of a Bates Number for management in a review platform. If there is still a concern about whether a file has been changed, parties can use MD5 hash values instead, to ensure the ESI has not been modified.
Finally, I believe forward thinking local rules are extremely helpful for litigants. However, as technology changes, these rules need to be updated to incorporate how computer-assisted review can cut costs, advances in processing or even the cost-effectiveness of remote depositions. What was forward thinking in 2006 can be outdated in 2013.
In the end, converting standard ESI like email to TIFFs to brand Bates Numbers should give lawyers nightmares of high processing costs, slow manual review and unhappy clients. It should only be done when the native file itself is not in a reasonably useable form, thus the static image is the only reasonably useable form.
Great comments, I totally agree about not applying a paper model to electronic data. A challenging issue with any evidence, however, is to make sure that units of evidence (files, databases, etc) are uniquely identifiable so that they can be referenced and cited appropriately, both in speaking and writing. I’ve seen a number of ways of doing this, do you have any recommendations?
Just what we need, an official statement that a production has to be Bates Stamped in order to be acceptable. We’re never going to lose that little number on each page, and all of the complications of figuring out how to get it there, are we? 😉
I’m with you Josh, this is not a move forward for the legal field.
There is a need for judges to have a better understanding of the technical issues. But the need for a quick page citation in depositions or at trial does militate in favor of the use of some form of indexing, and the use of “bates numbers” meet that need. And of course that does not mean stamping individual pages with a metal stamping device, followed by scanning the paper to images, but rather imprinting sequential numbers on a series of electronic documents. It can be done under Acrobat without much difficulty, even across separate documents.
I believe that, in some cases, the court should be authorized to order “native plus” production: native format, plus some form of indexed format.
Thank you for the comment.
I think we should stress the difference between conducting document review of say 30,000 email messages and attachments vs marking 500 deposition exhibits selected from the discovery production. I would encourage attorneys to review near-native and have an agreement on how deposition exhibits will be marked to reduce processing costs. There are several ways people handle this issue, from printing deposition exhibits with either the control number or MD5 hash value as a footer on the exhibit, to using a native viewer in deposition. PDF’s could be an option as well. I would encourage parties to meet and confer to reach an agreement.
Isn’t there a middle ground though in this? If a review is done in near native or native format, and only the responsive docs are TIFF’d and produced allowing bates numbering and redaction as needed, but also delivered with extracted or searchable text files from the native along with reasonable metadata fields, doesn’t this also allow for both the value of analysis of the data in conjunction with a static image that can easily be used in evidence? Selective native production for certain file types like Excel could also be thrown in if needed, etc.
I fully agree and what you described has been a document review best practice for a long time. I think it is important to specify the difference between conducting review over requesting the discovery and its format. In review workflows, launching the native application can cause an increase in review time, opposed to simply reviewing in near-native and launching the native file when necessary. However, if the production is entirely static images, you do not have a native to review in a near-native viewer and the processing costs have also increased (depending on the service provider).
You also have to look at how the review platforms work. Most review the underlining data for their tools to be effective. For example, I once had a client that wanted to run ESI converted to TIFFs with OCR with through an ECA tool. The product simply did not work that way. They needed the natives. As these tools are always improving, it is important to know what they need to work effectively.
Josh – you are spot on in this blog, as are your follow-up comments. Legacy is hard to part with, as we all know, and “Bates stamping” is about as archaic as it gets. Most lawyers don’t even know what a Bates stamp looks like (when my father sold his pharmacy last year, one of my treasured mementos is his Bates stamper). Let’s move to QSR or bar codes or exhibit numbers when they become necessary. I cannot tell you how long some of my former trials could have been shortened without having to call out Bates numbers! Great post!
Great post Josh – Instead of using an Excel file as an example (which just about everyone has finally conceded has virtually no value in TIFF), I ask people to look at an email or Word document that has some of the text hyperlinked (e.g. CLICK HERE). Where does the link go? Another document? A website? An email? If the doc is produced in TIFF… and even with metadata and extracted text, all that the receiving party would see (and be able to search on) are the words “click AND here”… and they would never know that those two words were linked to somewhere else. IMHO, the tools that are commonly available today enable attorneys to gain additional insight into the document collection that Tiff/Text/DAT just can’t provide.
Ed, I concede that pure native has some benefits, but I think there are still legitimate reasons for TIFF/Text/DAT. Your example is a good one, but I think I would propose to handle that type of document as a special production once identified by the receiving party or if determined substantive by the reviewing party. For all we know, that link may go to a site or content that is not in my client’s control, not responsive or the content that was originally on that website at the time of the original document’s creation may be out of date or changed (not to mention, a native file like like that would not necessarily add to the value around data analytics since the linked information would not have been any more searchable in native form than with an extracted searchable text file since I THINK the extracted text would have the actual URL path. A link to a file or attachment would also not likely not lead to an actual doc in a native production either). I know I may sound like a Luddite given the very impressive list of thought leaders (of which I include you) out there that support this movement, however I still think that there are valid reasons for holding onto the current best practice, at least for the time being. (Let me buy you coffee and we can continue this :)).
What a great line, Why is this a case a nightmare for me? Because it applies a paper model of discovery to electronically stored information. Alot of good issues.
Brian – You know me too well… I’m always up for a cup of coffee!
You’re definitely not being a Luddite. We still have a few of them in my world… they’re the ones that take pst files from multiple custodians and ask us to blow it all back to paper!
I agree that TIFF/Text/DAT has its place and can be used in a large number of cases today. It is a format of production that so many are comfortable with and works with just about all of the software platforms that are out there in the marketplace, with the exception of the ECA capabilities that Josh alludes to in one of his responses above.
I believe, however, that as the software we use for review and production continues to evolve, the ability to bring native files into the mix will continue to lower costs for both producing party AND the receiving party.
More importantly, as the platforms become more and more robust in handling natives, the use of native files will continue to improve the accuracy and consistency of decision making. IMHO, that is the overriding reason to migrate our best practices away from TIFF and toward native files. Everybody wins.
As a bridge, I would like to see TIFF/TEXT/DAT/NATIVE become more of a “default” production setting. I believe that over time, as attorneys become used to the benefits of using natives, the requirement for TIFF would slip away.
“As a bridge, I would like to see TIFF/TEXT/DAT/NATIVE become more of a “default” production setting. I believe that over time, as attorneys become used to the benefits of using natives, the requirement for TIFF would slip away.”
This is absolutely correct. I support the zeal for advocating native file review and production, but I think it needs to be tempered by reality. Very many people (firms, courts, companies) haven’t even reached this bridge! Being shocked and/or dismayed that the entire legal industry isn’t at the very cutting edge of e-Discovery processes makes no sense.
This is less about applying a paper model to ESI than it is about managing cases and evidence easily and efficiently. They want to apply the paper model because it’s what they know how to do. In the end that really means is being able to quickly locate, cite and identify evidence when it’s needed for briefs, depositions and trial.
As Josh suggests there are (to the technically inclined) common sense ways to manage native files in these venues (only image exhibits, use doc control numbers/hash identifiers, etc), but there is no uniform or commonly utilized approach. Also, both sides of a case need to be on the exact same page. Given that it’s still a struggle to get counsels to discuss evidence and case management, at all, at 26(f) conferences with anything but a superficial technical understanding, it shouldn’t be surprising to see why this further step of detail remains lagging.
Keep advocating for best practices and continue to develop and standardize, where appropriate, these best practices. But understand the reality that 95% of the legal world is not even halfway across the bridge.
Litigation (and eDisovery) is conducted very differently in Australia.
Discovery (eDiscovery) is not an automatic right and it is generally limited even when leave is given.
Bates stamping of produced (discovered) documents is not practiced. Documents admitted or tendered into evidence are reproduced either in an exhibit, or tendered as a part of a bundle. They do not have any unique identifying number.
Court rules encourage electronic production of discovered documents, PDF and/or native files are the preferred format. Most firms do not have the need for the software necessary to economically carry out a review of a large number of TIFF documents.