Articles in this Series

LĩST - the Litigation Support Technology Group

What is LĩST?

The LĩST Draft Documents

The LĩST draft Practice Direction

The LĩST Data Exchange Protocol

Disclosure Documents
Disclosure Data

Why a Data Exchange Protocol?

LĩST Publications

Some LĩST definitions

Document
Anything in which information of any description is recorded as defined in CPR Part 31.

Disclosure Documents
Documents disclosed by a party in accordance with CPR Part 31

Disclosure Data
Electronic data which identifies Disclosure Documents, including for example the type of Document, the date of the Document, the names of the author/sender and the recipient, and the party disclosing the Document.

Litigation Support and Electronic Disclosure

LĩST Data Exchange Protocol Part 2 of 2 - Disclosure Data

LiST's Data Exchange Protocol appears as two documents, Part 1 about Disclosure Documents and Part 2 on Disclosure Data. Both can be found on LiST's Publications page.

If you have not read it already, you may care to look at my introduction to the List Data Exchange Protocol and other LiST-related documents on the index opposite.

Technical but relevant beyond the experts

The Disclosure Data part of the LiST Data Exchange Protocol is (and indeed describes itself as) a "highly technical Protocol couched in technical language". It is expressly aimed at experts using litigation support systems, both within law firms and at the external service providers who work for them. For all that, it is crisply and succinctly written and makes accessible a subject which is important beyond its narrow target audience.

My purpose here is to explain why the Data Exchange Protocol is within the grasp of those outside the experts and, more importantly, to explain how its principles can be useful to those who do not have litigation support systems and staff.

Part 2 of LiST's Data Exchange Protocol says that adherence to the Protocol "may require a party to enlist the expertise of an external consultant". That is what I do, and is both my reason for writing about this area and the qualification for doing so. I mention it at the beginning, rather than shyly slipping it in at the end, because the availability of such services, and the fact that you can rent litigation software, host it externally and outsource the scanning and coding, means that anyone engaged in document-heavy litigation can compete on equal terms with the large firms whose experts wrote the Data Exchange Protocol.

What follows is therefore a summary of LiST's Data Exchange Protocol for the benefit of those who may not have in-house expertise or software but who are receptive to the idea that their clients' interests, and their own commercial interests, lie in competing for document-heavy dispute work with large and technically-proficient firms, and in doing it cost-effectively.

If you still think that this is all out of your league, here are some more thoughts:

The Protocol, when adopted, will be voluntary. It follows (and the draft repeatedly acknowledges) that parties may agree what they like. It is the principles and the framework which matter, and the apparent complexity is necessary but optional (and in any event largely illusory).
You do not need to understand the technical minutiae as long as someone on your side does.
Size is no indicator of quality or expertise - I have seen some very expensive junk data come out of very well-known firms. The converse - that smaller, less inherently expert firms can give ship-shape electronic Disclosure - is also true.

Why the Protocol is necessary

Different database systems have different ways of holding and using data. Firms have varying house styles. Date formats, the way the names of individuals and organisations are laid out and the names of the underlying data fields are obvious examples.

Party A	Party B
Accepts partial dates	Requires true dates and rejects anything else
Sets out names as John Smith of Smith Co Ltd	Requires names in the format Smith, John (Smith Co Ltd)
Separates multiple names with semi-colons	Uses the pipe character \| between multiple names
Holds the originators of documents in a data field called Author	The originator of a document is a Sender
Numbers documents with integers held in a field called DocNo of the field type number	Uses a mixture of letters and numbers to identify documents in a character field
Can handle multiple Attachment relationships and grandparent-parent-child relationships	Only allows one-to-one attachment links between documents

In addition to these differences, Party A's system uses single-page .tif images and Party B's only works with Acrobat .pdf files.

You do not need to understand the detail to get the picture - there is more to a potential exchange of documents than just sending over a couple of CDs. On the face of it, you would get better interchange at a social gathering involving a Hungarian, a Mongolian and a Finn than you would get from this diversity of data.

This prevents push-button transfer of data between parties. LiST puts it this way:

"Exchanging Disclosure Data is therefore rarely a straightforward exercise and involves data manipulation of varying degrees of complexity in order to change the format of the other party's Disclosure Data"

Customised processes are therefore required each time data is to be exchanged. There are, LiST says, no standards to regulate this, and the purpose of the Protocol is to devise some:

"Adoption of the standards contained in this Protocol will mean that, for parties who so wish, much of the processing of Disclosure Data can now be automated and greatly simplified, with concomitant cost and time savings."

The apparently voluntary nature of this is subtly qualified in the next paragraph with a reminder that the Practice Direction 31 to CPR Part 31 requires parties to discuss and co-operate over the exchange of electronic documents. So - it is voluntary, but in a suitable case you must do it anyway.

How does the Protocol work?

LiST does not seek to make every database system work in the same way, although it hopes (and probably realistically) that the Protocol will become sufficiently widely accepted that software companies will produce Protocol-compliant import and export functions.

The Protocol applies only at the moment at which data is exchanged with other parties. The biggest part of the Protocol sets out rules for formats which every system ought to be able to create and to import, albeit with some technical manipulation at each end of the process. John Smith of Smith Co Ltd and Smith, John (Smith Co Ltd) may be entirely different ways of expressing a name, but the components of the name are identical. Varying amounts of time and skill may be needed to turn one into the other, but it is possible - and certainly a great deal quicker and cheaper than retyping them all. It is no great problem to relabel Authors as Senders and vice versa, nor to turn .tif images into .pdfs.

What the Protocol does is to devise a set of rules which, although they may not exactly match the running requirements of either party's system, creates data which is capable if being imported and exported by both (or all, in a multi-party dispute).

Parallels with language

Think of the Protocol format as a scheme for a lingua franca, a language used beyond the place where it is native. For a long time, French was used by diplomats of all countries - the Congress of Vienna, attended by all the participants in the Napoleonic Wars, was conducted entirely in French and the resulting Treaty of Vienna of 1815 was printed in French. No doubt all the participants (except the French presumably) hastened to translate it as soon as they got home.

The parallel with data exchange is fairly exact, the more so when you know that an alternative term for lingua franca is "vehicular language". Business transactions between parties of different languages is widely conducted in the "vehicle" of English and translated at each end. The Data Exchange File ("DEF") envisaged by LiST is in a vehicular language.

We can pursue this parallel further. It is not a requirement in such business transactions for the principals on each side to speak English themselves - they can employ people to do it for them, and to turn the results into their own language. The principal gives instructions, the translator gives effect to them in the common language, and the results are brought back in a comprehensible form. It is equally not a requirement that the fee earners understand the exchange format for documents data, as long as the end-result works in their litigation system.

For this to work as a commercial matter ("commercial" meaning in this context that you do not start from scratch each time) the intermediate "language" used must have some commonality with the languages at each end of the process or, at least, some structural rules which, with minor variations, apply each time. The monoglot party-goers referred to above were not chosen as randomly as may appear - the languages of the three countries have a common Uralic root. This does not mean that a Hungarian can order a beer in Ulan Bator or a Mongolian chat up a girl in Helsinki, but there are many characteristics common between their languages. The aim of the Protocol is to set some structural rules which, with agreed variation, can be used between most parties to litigation.

The Protocol Requirements

The bulk of the Data Exchange Protocol defines, describes and elaborates on this primary proposition - the structural basis whose outcome is a chunk of text like that shown above. Field types are defined, and patterns are set for giving dates, names, file types, field separators and many other things. Sections are helpfully split up under sub-headings like Definition, Usage, Reasoning and Examples, giving a comprehensive blue-print for data exchange in under 24 pages. The theme running through it all is consistency.

I do not intend to summarise them. If you want to see the detail click here and read it. It is written in clear enough terms to be comprehensible. A Finnish businessman trying to structure a corporate deal with a Mongolian does not do it with a dictionary in hand, nor does he turn his back on the deal - he hires someone to translate.

The Procedure

It will not be long, I think, before the courts are using the Protocol as a model. It may have no statutory force, but a Judge or Master at a Case Management Conference who finds himself confronted by two parties who cannot agree how to exchange their electronic data will throw a copy at them and tell them to follow it.

That will bring them to heel fast enough because, for all its merits as a vehicular language, the Protocol in undiluted form is more complex than is needed for most cases. That is not a criticism - any attempt to be a generic solution to a wide range of circumstances is bound to be more complex than is required for most individual situations. The draft Protocol reiterates more often than I can count that parties may decide what they wish if it gets the job done economically - I paraphrase but the gist is clear.

Usually, the use of the Protocol will simply be agreed between the parties in correspondence or around a table - the Americans call this a "meet and confer", an expression enshrined in the rules. Lawyers are better off out of it - they should tell their expert what they want to achieve and leave him or her to it (glance back at the sample Data Exchange File above if you doubt me on this).

None of those I have been involved with have followed the draft Protocol to the letter. They have each been a pragmatic solution to a problem made up from the common ground between each party's litigation support system (there may be more than two in a multi-party action) and the needs of the lawyers on all sides.

The upshot is an agreement which may then be included in an Order and thus become enforceable. Some of these orders are very precise both as to specific data requirements ("Names will be provided in the format ...") and as to the broader obligations ("The parties agree that they will use their best endeavours to ...").

In due course, data arrives, on a CD, DVD or portable drive. What happens next strays beyond the scope of this article but, if the parties have not done those things which they ought not to have done and not left undone those things which they ought to have done, the data ends up in the system ready to be searched and filtered along with your own documents data.

Is it worth it?

If the arrangement was predicated on the right facts (a lot of documents to go through), was properly structured between the lawyers and litigation support experts on all sides, and was complied with, then there are obvious savings of time and money. If such arrangements fail, it is almost always because one party is cavalier with its obligations or not competent to fulfil them. In such cases, costs inevitably increase.

This is not usually the fault of the technology or of the principles in the Data Exchange Protocol. If a firm bogs up its data preparation it is very likely that its list and hard copy files would have been in a similar state of disarray and more expensive than expected to deal with. Whatever it costs to knock bad data into shape, it can at least be done globally to some extent.

In rejecting the electronic Disclosure route on grounds of cost, lawyers usually overlook the fact that a large Disclosure exercise going to cost a lot of money anyway. The Data Exchange Protocol "seeks to simplify and speed up procedures and reduce cost". It will achieve that object if it is properly used.

I do not have the equipment, the staff or the skills

The real question is "Do you have the cases?". If you do not have document-heavy cases, then you need not worry about the Protocol - although the draft Practice Direction envisages the need for some at least of the same skills for a wider range of cases. A frank answer to the question "Do you have the cases?" may provoke an enquiry on your part as to why you do not.

The use of technology as envisaged by LiST is a great leveller. There are many firms, including not a few sole practitioners, who have the legal skill and knowledge, and the clients, to do good, high-value contentious work fighting big technology-rich firms. For such firms, the Achilles heel is handling the documents. A high proportion of that burden, however, is nothing to do with legal skills or with the analysis of the documents' contents, but to do with the mechanics of listing and exchanging documents.

Outsource it. Hire someone to be project manager. Send him to the meet and confer and have him negotiate the disclosure agreement. Delegate the task of rooting out your clients' documents - supervise it, keep control of the obligations and the client relations but don't do at your charging rate what someone else can do just as well for less. Leave it to him to turn the documents, electronic or paper, into usable data, outsourcing to a bureau where necessary. Let him find you some suitable software to rent, somewhere to host it and get you trained to use it. Concentrate on the law and the tactics.

None of this is cheap, but in a document-heavy case it is cheaper than handling a paper mountain and very much better value than losing the client or the case.

Looked at in this way, the target audience for LiST's Data Exchange Protocol is not just those who actually have litigation support systems but anyone who is willing to rent the equipment and outsource the skills.

Contact me if anything covered in this section is relevant to what YOU want to achieve NOW.

Chris Dale Lawyer Support	Blog Services Biography Contact Home