The Early Case Assessment (ECA) Debate Continues

As we emerge from the Memorial Day weekend and head into a short work week, it appears from my standard morning perusal of news and updates in eDiscovery and Governance, Risk and Compliance) GRC, that there is a “raging” debate about the definition of Early Case Assessment (ECA).  Well, maybe its not really “raging”.  However, there does appear to be significant ongoing debate with legacy litigators on one side, technologists on the other and many others either misinformed, under-informed or uninterested.

The latest players to enter the debate are George Socha & Tom Gelbmann or EDRM fame.  In an article published on the Law.com site on June 1, 2010 titled, “Don't Box ECA”, the pair contend that Early Case Assessment (ECA) actually proceeds eDiscovery.  They go on to contend that, “Early case assessment is a process. It predates e-discovery and extends beyond the limits of EDD's range.  ECA is a traditional aspect of the work done by in-house and outside counsel as they decide what to do about a new matter. It starts when the attorneys pick up the first whiff of a lawsuit, and covers a broad swath of potential preliminary decisions to make and actions to undertake.”  All of these observations are true.   And, it shows that shows some great examples of how Early Case Assessment (ECA) is a process that includes and requires the participation of litigators and technologists.

Litigators have proven, beyond a shadow of a doubt, that they can not appropriate complete an acceptable Early Case Assessment (ECA) process with the use of technology.  And, without the leadership of an experienced and knowledgeable litigator at the helm, the best Early Case Assessment (ECA) technology on the market is not going work.

For Early Case Assessment (ECA) to succeed, there has to be an experienced litigator using the right technology.  Any approach that leaves one or the other one the sidelines is doomed to failure.  Further and finally, I believe that the court system(s) and judges need to "get up to speed" on the technology of Early Case Assessment (ECA) and led the charge to ensure that "it" is used and used properly.

The full text of George and Tom’s article is as follows:

The latest electronic data discovery buzz phrase is most definitely "early case assessment." But if you examine the Electronic Discovery Reference Model (http://www.edrm.net/), which offers guidelines and standards for e-discovery consumers and providers, you will search in vain for a box entitled ECA.

By not including one, have we missed a crucial step in the e-discovery process?
No. In our opinion, the term early case assessment is misapplied in the e-discovery context. While ECA can — and often should — address e-discovery issues, early case assessment sweeps much more broadly. To the extent ECA connects with e-discovery, the EDRM diagram already accommodates it.

WHAT IS EDRM?
First, a bit of context for readers who may not be familiar with the Electronic Discover Reference Model project. Run by the authors, it includes more than 300 participants from 42 providers, 18 consumer organizations, and 48 individuals.

The group currently is tackling eight projects, ranging from an Information Management Reference Model, to Jobs, to XML, to Search. We held our 2010 Kickoff Meeting last month in St. Paul, Minn.
Participants pay fees ranging from $150 for an individual working on one project, to $7,500 for providers with more than 10 people, for all projects.

WHAT IS ECA?
Early case assessment is a process. It predates e-discovery and extends beyond the limits of EDD's range.
ECA is a traditional aspect of the work done by in-house and outside counsel as they decide what to do about a new matter.

It starts when the attorneys pick up the first whiff of a lawsuit, and covers a broad swath of potential preliminary decisions to make and actions to undertake.

For counsel inside and out, these ECA decisions and actions may include, but are not limited to:

• Is there a case? What is it about? What are the issues? Are they legal? Factual?
• How much does this matter appear to be worth? Is it only an issue of money? Is it an "above the fold" problem? Are important principles at stake? Is the matter likely to have an impact on the company's reputation? What about the stock price?
• Is this an isolated matter? Or part of a pattern? Are we looking at a class action lawsuit, maybe multi-district litigation?
• How much should I budget for this matter? How much for attorney fees, experts, EDD costs, other expenses? What about settlement?
• Is there insurance coverage? How much? Under what circumstances? Are we self-insured? Is excess coverage available? Do we need to set aside reserves?
• What resources do I need to devote to this matter? Internal versus external? Hard costs versus soft?
• Do I need outside attorneys? If so, whom? How many? At what level? With what expertise? Do I need local counsel? Do I want to share counsel with others?
• Who can tell me more about the matter? Can I get help from my colleagues in the law department? From current employees? Former employees? Consulting experts?
• Who has something I might need for the case? What do they have – insights? Experience? Information on paper? Information in electronic form? Tangible objects?
• Do we need a litigation hold? And if so, what does that entail? E-discovery can play a real and important role in ECA, as demonstrated by a quick examination of some of the EDRM stages. Think of the EDRM diagram as ECA writ small.

EXAMPLES
Here are a few examples:

Identification: Do I have quick and ready access to electronically stored information? What content can help me better address the issues listed above?
What types of ESI are we going to confront? E-mail? Structured data? Office files (e.g., word processing, spreadsheets)? The contents of wikis, blogs, and other social media?
Where might the ESI be located? On what systems? In what geographical locations? Who knows about it, controls it, can get me to it, or can get it to me?

Preservation and Collection: When do I need to begin preserving ESI? How should I do that? What forms of preservation should I consider? What legal hold process? How soon can I collect ESI for early analysis? Will it be part of a preservation process, or something separate?

Processing: If I have identified ESI of potential interest, does it need some level of processing before I can begin to assess or analyze that data?
Do I need to get ESI converted to forms I can more readily evaluate? Are there ways to help me quickly find some wheat in the chaff?
Should some ESI be indexed, for rapid iterative searches?

Analysis: Here is the "assessment" piece. What can I glean from the readily available ESI that helps address the topics listed above?

Review and Production: Is there any portion of this ESI that I need to get to someone else quickly, and if so, in what form?

Presentation: At this early stage, do I need to put any of this ESI in front of someone else — to draw out more information, attempt to validate or refute what I think I know, or attempt to persuade someone?

Labels: Early Case Assessment, ECA, eDiscovery, eDiscovery Best Practices, EDRM, Socha

posted by Charles Skamser @ 10:26 AM 0 Comments

eDiscovery XML

Coming from the object oriented software development world and more recently from the Software-as-a-Service (SaaS) development world, XML or eXtensible Markup Language is a mainstay. However, with my new pond being eDiscovery technology, XML is just another acronym that everyone has to learn. And, although us eDiscovery technology gurus may never catch up to the SaaS nerds, I would suspect that XML is going to have to be a big part of our pond as we all seek to exchange and integrate the massive amounts of ESI that we have so eloquently generated.

As such, I found the following article, E-Discovery Guru Not Yet Wed to XML, by Craig Ball published on the Law Technology News site on March 25, 2008 to be extremely informative and timely. The text of Mr. Ball's article is as follows:

I want to love XML. I want to embrace it with the passion of my wiser colleagues, excited by its schemas, titillated by its well-formed code, flushed from its pull-parsing. I want to love XML as much as the cool kids do. So why does it leave me cold?

I want XML the dragon slayer: all the functionality of native electronic evidence coupled with the ease of identification, reliable redaction and intelligibility of paper documents. The promise is palpable; but for now, XML is just a clever replacement for load files, those clumsy Sancho Panzas that serve as squire to addled TIFF image productions. Maybe that's reason enough to love XML.

XML is eXtensible Markup Language, an unfamiliar name for a familiar technology. Markup languages are coded identifiers paired with text and other information. They can define the appearance of content, like the reveal-codes screen of Corel Inc.'s WordPerfect documents. They also serve to tag content to distinguish whether 09011957 is a birth date (09/01/1957), a phone number (0-901-1957) or a Bates number. Plus, markup languages allow machines to talk to each other in ways humans understand.

Internet surfers rely on a markup language called HyperText Markup Language or HTML that forms the pages of the World Wide Web. There's a good chance the e-mail you send or receive is HTML, too. If you've tried to move documents between WordPerfect and Microsoft Corp.'s Word, or synchronize information across different programs, you know success hinges on how well one application understands the data of another.

Something as simple as importing day-first European date formats to month-first U.S. systems causes big headaches if the recipient doesn't know what it's getting.
Standardized markup languages alleviate problems by tagging data to describe it (e.g., ), constraining data by imposing conditions (e.g., restricting dates to U.S. formats: ) and supporting hierarchic structuring of information (e.g., 01/09/1957).

There are so many kinds of data and metadata unique to applications and industries that a universal tagging system would be absurdly complex and couldn't keep pace with technology and business. Accordingly, XML is extensible; that is, anyone can create tags and set their descriptions and parameters. Then, just as persons with different native tongues can agree to converse in a language both speak, different computer systems can communicate using an agreed-upon XML implementation. It's Esperanto for electrons.

In e-discovery, we deal with information piecemeal, such as native documents and system metadata or e-mail messages and headers. We even deconstruct evidence by imaging it and stripping it of searchability, only to have to reconstruct the lost text and produce it with the image. Metadata, header data and searchable text tend to be produced in containers called load files housing delimited text, meaning that values in each row of data follow a rigid sequence and are separated by characters like commas, tabs or quotation marks. Using load files entails negotiating their organization or agreeing to employ a structure geared to review software such as CT Summation or Lexis Nexis Concordance. Conventional load files are unforgiving. Deviate from the required sequence, or omit, misplace or include an extra delimiter, and it's a train wreck.

By tagging each value to identify its content and connection to the evidence, XML brings intelligence and resilience to load files. More importantly, XML fosters the ability to move data from one environment to another simply by matching the tags to proper counterparts.
Like our multilingual speakers using a common language, as long as two systems employ the same XML tags and organization (typically shared as an XML Schema Definition or XSD file), they can quickly and intelligibly share information. Parties and vendors exchanging data can fashion a common schema custom tailored to their data or employ a published schema suited to the task.

There is no standard e-discovery XML schema in wide use, but consultants George Socha and Tom Gelbmann are promoting one crafted as part of their groundbreaking Electronic Discovery Reference Model project. Socha (a member of LTN's Editorial Advisory Board) and Gelbmann have done an impressive job securing commitments from e-discovery service providers to adopt EDRM XML as an industry lingua franca. See http://edrm.net.

A mature e-discovery XML schema must incorporate and authenticate native and nontextual data and ensure that the resulting XML stays valid and well-formed. It's feasible to encode and incorporate binary formats using MIME (the same way they travel via e-mail), and to authenticate by hashing; but these refinements aren't yet a part of the EDRM schema.

So stay tuned. I don't love XML yet, but it promises to be everyone's new best friend.

Craig Ball, a member of the editorial advisory boards of both LTN and Law.com Legal Technology is a trial lawyer and computer forensics/EDD special master, based in Austin, Texas.

Labels: EDRM, eXtensible Markup Language, Glebmann, Metadata, Socha, XML

posted by Charles Skamser @ 4:10 PM 0 Comments