Last time we set the stage for a document review by identifying the basic planning and preparation that needs to take place prior to beginning a document review project. In this article we will take a look at the actual mechanics of the coding of documents.
Prior to starting a review, the universe of documents will be broken up into batches and made available to the review team. There are a number of ways to organize the batching of the documents such as thread groups, custodians, or even search term clusters.
Once the documents are ready for review and coding, it is necessary to create a document review coding form or layout in the database which reviewers will use to mark documents responsive or non-responsive.
For consistency across cases, one good practice is to have a coding layout template. This will utilize a standard set of tagging fields and choices in the review database that can be used in all cases. It saves time in that it doesn’t need to be created whenever there is a new case and has the added benefit of the review team and attorneys becoming accustomed to a systematized process.
The most common coding decisions a reviewer will be required to make are: Responsive, Non-Responsive, Privileged, Responsive-Redact, Redact–Privileged, and Further Review. The primary tags are defined and should be used as follows:
- Responsive. These documents will be produced because they are relevant, responsive to a document request, and not privileged;
- Non-Responsive. These documents will not be produced because they are not relevant, not responsive to a document request, fall outside the date range, or have some other exclusionary criteria;
- Responsive-Redact. These are responsive documents that will be produced, but they need to be redacted before production because they contain information that should not be produced such as personally identifiable information or trade secret information. The reviewing attorney will redact the sensitive material and these documents will then be produced in redacted form;
- Privileged. These are responsive documents that will be withheld from production entirely because they contain privileged information, attorney work product, or other protected information. These documents will later be itemized on a privilege log. Redact–Privileged. These are responsive documents that will be produced, but they need to be redacted because they contain privileged or work product information. The reviewing attorney will redact the privileged material from these documents, and they will be produced in redacted form. The redacted or privileged portion of the documents must be itemized on a privilege log or redaction log. When this tag is chosen, the reviewing attorney should be prompted to enter the basis for the privilege (e.g., attorney-client or work product)
- Further Review. Documents are coded with this tag when the reviewing attorney is uncertain as to the appropriate tag. This can also be used in cases of password protected documents or documents in a foreign language. It is helpful to include a Comments field on the coding form so that the reviewer may enter an explanation for the further review coding. This way, the Project Manager can review the comments and elevate the documents to the case team as necessary. This will make sure that the coding decision made by the case team will be shared with the review team at large so that guidance can be applied to similar documents.
Lawyers and e-discovery professionals may have different names for these coding choices, but the key point here is to use the chosen review designations consistently.
There are also a few logical practices that should be followed when coding documents. The coding choices outlined above facilitate compliance with best practices. For example, if a document is determined to be Responsive to a document request, it must then be determined if the document contains any privileged, work product, or other sensitive information that should not be produced. If the document is privileged, has the privilege been waived? If so, the document can be produced. If privilege is not waived, can the privileged information be redacted? If it can be redacted, the coded tag should be Redact–Privileged, If it cannot be redacted, then the tag should be Privileged
These coding practices are not usually written down anywhere; rather, they are a common-sense approach to preserving the attorney-client privilege and they reasonably ensure that privileged materials are not produced in discovery. It is also a best practice to code families of documents consistently during document review. If, for example, an email (the “parent” document) is coded Responsive, then any attachments to the email (the “child” documents) should also be coded Responsive. The reasoning behind this rule is simple: When the author of an email attaches a document to the email and sends the email and attachment, it is the intent of the author for both the email message and the attached document to be viewed together as a single communication. This, combined with the general notion of producing documents in the manner in which they are maintained, support the practice of consistent coding within document families.
Another form of coding that may occur during document review is to apply confidentiality designations to individual documents. Confidentiality designations are almost always very case-specific. In most circumstances, the designation of documents as confidential or otherwise are governed by a protective or confidentiality order to which the parties of the case have agreed.
Depending upon the needs of the case, the typical confidentiality designations are “Confidential,” “Highly Confidential” or “Attorneys Eyes Only.” A coding field with these confidentiality designations should be created prior to the start of the document review and added to the coding layout
When the documents with these designations are eventually produced, the selected confidentiality value will normally be endorsed on the images or printed pages or appended to the file name for native files.
The review team must have a thorough understanding of confidentiality criteria to ensure consistency in the application of confidentiality designations. The review team should be given screening criteria, such as categories of documents or specific topics that will assist them in making such decisions.
Issue coding involves categorizing documents in ways that may be helpful to the legal team. It may be necessary to categorize documents as relating to certain issues, subjects, or events in the case. Issue coding is helpful, organizes documents based on the issues in the case, and makes locating documents related to a particular topic faster and easier in later stages of the case. Issue tags are generally not mutually exclusive. Because a document may pertain to more than one issue or subject in a particular case, the document may require multiple issue tags.
The case team must develop a list of the issues, subjects, or events for which documents are to be categorized. Each issue on the list should be very brief—no more than a word or two. The issue tags should be added to the coding layout so the review team may apply the tags to documents. It is important to keep in mind that issue coding can be time consuming and may add significantly to the time and cost of a document review.
Document review is not a rote activity, but a crucial, fact-gathering and case-building opportunity. Often, the information found in documents will shape and guide development of legal strategies in the case. Document reviewers usually begin to possess facts and information about the case that non-reviewing attorneys do not have, and it is important that the reviewers are able to communicate these facts and information to the senior attorneys on a case. By properly planning a document review and by taking a consistently systematic approach to the actual mechanics of review, document review teams –and more importantly clients—will have some assurance of a successful outcome.