Part One of this blog post introduced this basic model workflow and discussed how to implement it in a Relativity review environment. Now, a little bit about the fields, why they’re important, and how we can use them throughout the review process.
The DETERMINATION field is the most important review field. We use it to describe whether a document is responsive, non-responsive, or requires further attention. Moreover, we can also use the DETERMINATION field to establish whether or not a document has been reviewed at all. That is, if the DETERMINATION field has any value in it, then we will conclude that an attorney has reviewed it. Not only does this make it easy for tracking document review progress, but if you’re using Relativity’s batching system this is the field you would naturally designate as the batch set’s Reviewed Field. Relativity’s automated batching system will consider a document reviewed if the DETERMINATION field has any value in it.
We configure the DETERMINATION field as a SingleChoice (not a MultipleChoice field) to avoid the scenario of, for example, a document being coded as both Responsive and Non-Responsive at once. This way, it’s very easy to create searches to isolate documents for production, sampling (i.e. of the subset of documents coded entirely as Non-Responsive), or further attention.
The REVIEW WORKFLOW field enables you to code for additional workflow related instructions. You may want Hot Documents to be flagged for immediate senior attorney review. You may also want to flag documents for redaction or other special handling. Different stages of a review project require certain administrative tasks to be performed and, therefore, it’s helpful to isolate documents as the review progresses. For example, in order to redact a document an image must first be generated of that document (it needs to be TIFFed). You typically cannot draw a redaction on a native or near-native version of a document. Having a search that points to any document coded Needs Redaction AND does not have an image will help you to keep tabs on documents that will require imaging sooner than later.
Because the REVIEW WORKFLOW field is a MultipleChoice field a document may be coded with one or more values at the same time. A document can be coded both Hot Document and Needs Redaction.
Therefore, it’s important that any review manager understands that coding any document with more than one REVIEW WORKFLOW value could route that document to more than one place (i.e. Hot Document review and Needs Redaction Review).
The REVIEW WORKFLOW field should not be used to capture coding related to the subject matter of individual documents. For example, if you need to keep track of documents suitable for witness deposition prep, create a different field called ISSUES or DEPO PREP as a MultipleChoice field. It’s best to keep REVIEW WORKFLOW reserved for coding that relates to workflow. There are a number of reasons why this makes sense, but one that stands out is reporting. For example, if a client requires a regular review progress report on an ISSUES field then it would be rather cumbersome to have to remove values that the client may not want to see in such a report (i.e. Needs Redaction, Hot Document, etc.).
The PRIVILEGE field allows reviewers to flag documents as being privileged for whatever reason necessary. Typically the two privileged reasons we see are Attorney-Client and Work Product. It’s best that the PRIVILEGE field be setup as a SingleChoice field to prevent instances of inconsistent coding. For example, setting up the field as a MultipleChoice field may result in a single document being coded as both Not Privileged and Attorney-Client, which is obviously problematic. It’s also worth noting again that, as a matter of workflow, we will be excluding anything coded with a privileged value and their family members from any production. Therefore, as in the examples discussed under Part One, if a single document among a family group is coded as Attorney-Client or Work Product then the entire family will be withheld from the production.
You can build as many additional workflow streams off of this model (i.e. Second Tier Review, Hot Document Review, QC Review, etc.). One example is the TECHNICAL FLAW REVIEW workflow that is typically conducted by the review manager or vendor as they’re generally more technically savvy than your average attorney and, therefore, better-equipped to make a determination as to whether a true technical issue exists (i.e. one that may require going back to the original data source) or whether the reviewer has merely misinterpreted the document (i.e. a CSS style sheet, ATT00001.htm file, etc.). I like to utilize a separate TECHNICAL FLAW REVIEW field with values that will provide the reviewing attorneys with useful guidance on what it is they’re seeing. For example, the reason for an initial DETERMINATION of Technical Flaw may be due to a local document viewer issue. During the TECHNICAL FLAW REVIEW the reviewer can attempt to reproduce any technical issue and code the document as View Native, which indicates that the reviewer should download the native and review the document locally.
The whole point of having a good workflow design is to ensure that every document efficiently receives the attention it requires. We’re simply trying to figure out if a document should be produced, not produced, or withheld for cause. To that end, the purpose of this workflow design keeps things relatively simple while still addressing the basics necessary to effectively review and confidently produce out of a given review data set.
