A key consideration as a case begins is to make a determination on the production format to be used for documents in the case. The attorney should discuss both with the client and opposing counsel the types of documents most likely to be produced and how they should be produced.
The Federal Rules of Civil Procedure generally require the producing party to produce electronically stored information (“ESI”) in the form in which it is ordinarily maintained (“native” format) or in a reasonably usable form. The parties may also agree on the form in which production of ESI is to be made. Generally, the responding party is not required to convert native documents to a different format, but cannot convert ESI to a format that is difficult to use—for example, where the conversion renders the document unsearchable.
The best practice is to use both near-paper and native/near-native forms of production depending on the ESI format. ESI that is most easily converted to near paper-format such as ESI constituting PDF files, Microsoft Word documents, and common email formats, should be converted to and produced as .tiff or .pdf images and then Bates-numbered and given confidentiality designations. File types that are difficult to convert, such as Microsoft Excel, Microsoft PowerPoint and certain types of proprietary files, should be produced in native format. Certain types of native files, such as 3D CAD drawings, may be in a structured storage file format and need to be the subject of special discussion. These file types may need to be produced in native file format outside of a review tool in a native environment, such as a folder structure, to be reviewable.
The most common form of production in litigation is the “near-paper” format, which is formatted to be loaded into a review tool. The near-paper format is generated by converting the ESI to .tiff or .pdf files, in essence creating an image of the document as if it were in paper format or viewed on a screen. The image format often cannot itself be searched or indexed, so making a near-paper production requires the generation of an extracted text file and the collection of metadata, both to be provided with a load file so that the images may be searchable in a review tool. Hard copy documents are usually scanned and produced in an image format. Optical character recognition can be used to render scanned hard copy documents searchable.
Parties generally choose to make productions in near-paper or image format because this format provides the ability to add Bates numbering, make redactions and add confidentiality markings directly to the images. The producing party is also able to limit the metadata produced to agreed-upon fields or to only those fields required by local court rule. The notable disadvantages of this production format include the cost and time involved in converting the ESI to images, and creating the accompanying text and metadata files. In addition, many documents such as spreadsheets, databases and CAD files may be difficult to convert and produce in an image format.
Native format is producing responsive ESI in the form in which it is ordinarily maintained by the producing party, such as original Microsoft Excel, PowerPoint and Word files. The documents produced in this manner include all metadata maintained by documents in that format. Native production generally saves cost and time in processing and converting the ESI into images and load files. Native productions also create logistical difficulties, including the ability to number individual pages for document control, redact the documents or add confidentiality labels. While the ESI produced can be Bates-numbered and marked with confidentiality through a file naming convention, redactions generally must be handled by converting the document to a near-paper format. Further, the native production generally cannot limit the production of metadata associated with the document.
The review of native ESI can sometimes be more difficult, both for the producing party and the receiving party. Review platforms generally contain most of the native applications necessary to review these files, and many review tools allow direct review (without opening the native application) directly in the platform. Some types of native files must be reviewed by opening the native application, however, which can significantly increase the review time. Some types of native files may not be reviewable if the attorneys performing the review do not have the necessary software, which may be proprietary or unavailable. In such instances, the native file may not be deemed a “reasonably usable” form.
Some files cannot be produced in native format because they require conversion to be reviewable. Examples of these types of files include certain email formats and databases. Emails are often saved in a single text file or database rather than in separate files for each email. Databases and other data compilations include numerous irrelevant data fields and data points. These types of ESI are generally converted into near-native format: for example, emails may be converted to .htm, .msg or .rtf files and databases may be converted to .txt or .csv files, or exported to Microsoft Excel for production. Despite the conversion, near-native files will often include some or most of the original metadata. Like a native ESI production, conversion to and production in a near-native format is usually less costly and time sensitive compared with creating a near-paper production, but it has the same limitations as native production, including the inability to individually number pages, redact the document or add confidentiality markings.
Given that there are several variables that come into play, it is best to agree on the production formats of potentially responsive documents before the collection is done, if possible, and definitely before review.