Increasingly, lawyers are “going native” for production. The trend appears to be in its early stages, but all indications are that the use of native productions is expanding. Examples of this phenomenon include lawyers asking their opponents for Microsoft Excel and PowerPoint documents, or agreeing to turn over video and voicemail messages rather than producing a transcript of those items. It’s possible that soon only documents requiring redaction will be exempt from requests for native production.
A “native” document is one that remains in the file format in which it was created. For example, this article was originally written in Microsoft Word; the document in Word format is this article’s native format. A music file might be in mp3 format, or a video clip in wav format. Generally, you need the underlying computer application in order to access and view documents or files in their native format.
Historically, most documents have been produced in a “converted” format, such as tiff (tagged image file format) or, more recently, pdf (portable document format), in which the documents were put through a technological process that “petrifies” the face of the document in a digital format, creating an image or picture of the original document. What results is essentially an electronic photocopy of the document.
This process has served lawyers well for a long time, particularly since what has historically been produced is an image of a paper record that has been digitized. These formats opened up the possibility of digitizing paper records, eliminating the need to copy paper documents to exchange them. In addition, a secondary technical process could be run across documents in image format to make them searchable. All of the documents could then be loaded into a database and catalogued, improving the ability to organize them. And documents in tiff or pdf format could be easily redacted through the conversion, helping lawyers preserve privilege and eliminating the old process of cutting up records. Finally, there was little risk associated with converting document formats, since not much “information” was lost in converting a paper document to an image; any information loss (such as the colour of ink used in a signature) could be validated by inspecting the original.
But things change when “native” electronic documents, rather than paper ones, must be produced.
First, conversion can negatively affect the readability and usability of documents. For example, spreadsheets do not convert well, usually because the spreadsheet is too large and extends beyond a standard 8.5 x 11-inch format. It is not uncommon for spreadsheets to convert into hundreds and thousands of pages, with rows and columns broken across different pages. This is not only unwieldy, but expensive (as conversion is often charged on a per-page basis).
Second, a lot of information can be lost through the format-conversion process. Formulas in spreadsheets, “notes” on presentation slides, and “track changes” in documents are not represented on the converted image.
Third, some document formats cannot be converted to an image format. For example, video and audio cannot be “printed” through the conversion process. Additionally, the only way to access records in some proprietary formats, such as some medical diagnostic images, is to get them in those proprietary formats.
Finally, sometimes formatting is simply lost when the file is converted into another format, meaning documents either do not look the same as when they were created, or are so poorly laid out they become more challenging to work with. Formatting loss can also just be annoying.
The most common objection to producing documents in native format revolves around the disclosure of metadata. Sometimes this can be a valid concern, but it’s mostly not (since most metadata is simply a benign property of the document). Arguably, removing some metadata from the document actually downgrades the quality of the document. Furthermore, if parties are entitled to production of a record equivalent to the original, arguably only a “native” version would satisfy that requirement.
A more valid concern is that native format documents can be volatile and subject to alteration. This can be addressed in a number of ways, usually by taking the simple precaution of using a write blocker to access native files. Another solution is to place native documents within a litigation support application that can accept native documents (e-docs); these applications are designed to receive documents in native format and permit the user to view them without changing them. However, not all litigation support applications have this capability.
Exchanging native documents can not only improve the quality of the electronic documents being exchanged by preserving the full content of the records, but also lower the overall cost of production, because the step of converting the documents into image formats is eliminated.
However, native format exchange carries its own technical challenges. If you would like to exchange documents natively, it’s helpful to discuss this with opposing counsel so you both obtain the correct advice on technical exchange protocols.
I generally recommend that native documents are exchanged in “production load file format,” which links the native document with a load file. This means the native documents have been placed into a litigation support tool and processed so certain fields of metadata have been “extracted” into a database, and the textual contents of those documents have been indexed for searching.
A further advantage is that a “hash value” or identifying signature has been calculated for each document. A hash value is a calculator of all information about a document that services to uniquely identify each record and to indicate whether it’s been changed. These hash values can also be exchanged. A load file can accompany the native documents, making it easy to load into a litigation support tool and begin working with the documents right away. Documents that need to be redacted for privilege can also be exchanged in this format, so that the entire collection can be produced at once.
Dera J. Nevin is the senior director, litigation support, and e-discovery counsel at McCarthy Tétrault LLP. A practising lawyer, she also oversees the firm’s e-discovery operations and can be reached at [email protected].
A “native” document is one that remains in the file format in which it was created. For example, this article was originally written in Microsoft Word; the document in Word format is this article’s native format. A music file might be in mp3 format, or a video clip in wav format. Generally, you need the underlying computer application in order to access and view documents or files in their native format.
Historically, most documents have been produced in a “converted” format, such as tiff (tagged image file format) or, more recently, pdf (portable document format), in which the documents were put through a technological process that “petrifies” the face of the document in a digital format, creating an image or picture of the original document. What results is essentially an electronic photocopy of the document.
This process has served lawyers well for a long time, particularly since what has historically been produced is an image of a paper record that has been digitized. These formats opened up the possibility of digitizing paper records, eliminating the need to copy paper documents to exchange them. In addition, a secondary technical process could be run across documents in image format to make them searchable. All of the documents could then be loaded into a database and catalogued, improving the ability to organize them. And documents in tiff or pdf format could be easily redacted through the conversion, helping lawyers preserve privilege and eliminating the old process of cutting up records. Finally, there was little risk associated with converting document formats, since not much “information” was lost in converting a paper document to an image; any information loss (such as the colour of ink used in a signature) could be validated by inspecting the original.
But things change when “native” electronic documents, rather than paper ones, must be produced.
First, conversion can negatively affect the readability and usability of documents. For example, spreadsheets do not convert well, usually because the spreadsheet is too large and extends beyond a standard 8.5 x 11-inch format. It is not uncommon for spreadsheets to convert into hundreds and thousands of pages, with rows and columns broken across different pages. This is not only unwieldy, but expensive (as conversion is often charged on a per-page basis).
Second, a lot of information can be lost through the format-conversion process. Formulas in spreadsheets, “notes” on presentation slides, and “track changes” in documents are not represented on the converted image.
Third, some document formats cannot be converted to an image format. For example, video and audio cannot be “printed” through the conversion process. Additionally, the only way to access records in some proprietary formats, such as some medical diagnostic images, is to get them in those proprietary formats.
Finally, sometimes formatting is simply lost when the file is converted into another format, meaning documents either do not look the same as when they were created, or are so poorly laid out they become more challenging to work with. Formatting loss can also just be annoying.
The most common objection to producing documents in native format revolves around the disclosure of metadata. Sometimes this can be a valid concern, but it’s mostly not (since most metadata is simply a benign property of the document). Arguably, removing some metadata from the document actually downgrades the quality of the document. Furthermore, if parties are entitled to production of a record equivalent to the original, arguably only a “native” version would satisfy that requirement.
A more valid concern is that native format documents can be volatile and subject to alteration. This can be addressed in a number of ways, usually by taking the simple precaution of using a write blocker to access native files. Another solution is to place native documents within a litigation support application that can accept native documents (e-docs); these applications are designed to receive documents in native format and permit the user to view them without changing them. However, not all litigation support applications have this capability.
Exchanging native documents can not only improve the quality of the electronic documents being exchanged by preserving the full content of the records, but also lower the overall cost of production, because the step of converting the documents into image formats is eliminated.
However, native format exchange carries its own technical challenges. If you would like to exchange documents natively, it’s helpful to discuss this with opposing counsel so you both obtain the correct advice on technical exchange protocols.
I generally recommend that native documents are exchanged in “production load file format,” which links the native document with a load file. This means the native documents have been placed into a litigation support tool and processed so certain fields of metadata have been “extracted” into a database, and the textual contents of those documents have been indexed for searching.
A further advantage is that a “hash value” or identifying signature has been calculated for each document. A hash value is a calculator of all information about a document that services to uniquely identify each record and to indicate whether it’s been changed. These hash values can also be exchanged. A load file can accompany the native documents, making it easy to load into a litigation support tool and begin working with the documents right away. Documents that need to be redacted for privilege can also be exchanged in this format, so that the entire collection can be produced at once.
Dera J. Nevin is the senior director, litigation support, and e-discovery counsel at McCarthy Tétrault LLP. A practising lawyer, she also oversees the firm’s e-discovery operations and can be reached at [email protected].
