Lawyers, Are You Forgetting Something In Your Document Requests?
Attorneys–how often do you run document requests by litigation support before sending them out? Probably not often, but you might want to consider it if you are requesting electronically stored information (ESI) you expect to review in e-discovery software.
Electronic documents and ESI include metadata that may need to be specifically requested for both evidentiary purposes and to ensure information produced is optimized for document review. Consulting the litigation support department or e-discovery vendors about document production format will help ensure all necessary information about electronic documents is requested.
Download our Rule 26f Conference ESI Tips now!
Litigants May Specify Desired Document Format
As discussed in prior posts, parties requesting documents from litigation opponents may specify the preferred format of production. If the desired format is not specified, the requesting party may not like what it gets. Under most rules of civil procedure, when a form of production is not specified, parties producing documents and ESI may produce it as it is kept in the ordinary course of business. However, how information is kept for business purposes may not be conducive to litigation document reviews.
Specifying the desired form pending on the e-discovery tool used, additional files, such as load and text files may be needed so that it is compatible with the software.
This is why it might be a good idea for attorneys to consult their litigation support staff or e-discovery vendors to determine what files and data should accompany a document production. Parties entering into an e-discovery protocol may include a provision specifically identifying required metadata. Even in cases in which no protocol is entered, the preferred form of production and desired metadata may be included in the document requests themselves.
What Metadata Fields Should I Request?
Below are common formatting requirements for document productions.
IMAGES:
Produce documents in Single Page Group IV TIFF files
Image Resolution at least 300 DPI
Black and White unless color is necessary to understand the meaning
File Naming Convention: Match Bates Number
Insert Placeholder image for files produced in Native form (see Section 2)
Original document orientation shall be retained
FULL-TEXT EXTRACTION / OCR:
Produce full extracted text for all file types of ESI (Redacted text will not be produced)
Production format: Single text file for each document, not one text file per page
File Naming Convention: Match Beg Bates Number
LOAD FILE SPECIFICATIONS:
Images Load File: Opticon OPT file
Metadata Load File: Concordance DAT file with field header information added as the first line of the file. Export using Concordance default delimiters.
Extracted TEXT: Reference File Path to TEXT file in DAT file
Native Files Produced: Reference File Path to Native file in DAT file
ESI PRODUCTION METADATA FIELDS:
BegBates: Beginning Bates Number
EndBates: Ending Bates Number
BegAttach: Beginning Bates number of the first document in an attachment range
EndAttach: Ending Bates number of the last document in attachment range
Custodian: Name of the Custodian of the File(s) Produced – Last Name, First Name format
FileName: Filename of the original digital file name
NativeLink: Path and filename to produced Native file
EmailSubject: Subject line extracted from an email message
Title: Title field extracted from the metadata of a non-email document
Author: Author field extracted from the metadata of a non-email document
From: From field extracted from an email message
To: To or Recipient field extracted from an email message
Cc: CC or Carbon Copy field extracted from an email message
BCC: BCC or Blind Carbon Copy field extracted from an email message
DateRcvd: Received date of an email message (mm/dd/yyyy format)
DateSent: Sent date of an email message (mm/dd/yyyy format)
DateCreated: Date that a file was created (mm/dd/yyyy format)
DateModified: Modification date(s) of a non-email document
Fingerprint: MD5 or SHA-1 has value generated by creating a binary stream of the file
ProdVolume: Identifies production media deliverable
ExtractedText: File path to Extracted Text/OCR File
Redacted: “Yes,” for redacted documents; otherwise, blank
PAPER DOCUMENTS METADATA FIELDS:
BegBates: Beginning Bates Number
EndBates: Ending Bates Number
BegAttach: Beginning Bates number of the first document in an attachment range
EndAttach: Ending Bates number of the last document in attachment range
Custodian: Name of the Custodian of the File(s) Produced – Last Name, First Name format
ProdVolume: Identifies production media deliverable
Another resource is the Department of Justice Standard Specifications for Production of ESI or the Security and Exchange Commission’s Data Delivery Standards. These specifications include a list of metadata fields requested by the DOJ and SEC in their cases. However, both are thorough lists and all the fields included may not be necessary for every case. However, it is a good reference and many e-discovery software products offer the DOJ and SEC metadata lists as load file templates.
Download our Rule 26f Tips now!
Native Productions May be Best Approach
Finally, it bears noting that if parties agree to produce electronic documents in native format, load files containing relevant metadata may be unneeded because native files already contain original metadata. Using native productions is often a preferred method because it permits users to take advantage of analytic tools in e-discovery tools that may not be available with image-based productions accompanied by load files.
