Can Lawyers Collaborate to Their and Their Clients’ Benefit?
Writing for my blog, to my family and friends, and to other lawyers is very satisfying to me. I have a mailing list of around 200 lawyers I know personally. I write to this group on topics I feel may be of interest to them. Many of my letters are tech oriented, as are some of these articles.
Recently, I got a very kind response from Attorney/Mediator Scott Curnutte of Elkins. Scott is one of the 3-4 best mediators I have ever worked with, especially on Family Law issues.
As some of my readers know, I have strongly endorsed the document assembly program, Pathagoras. Scott’s letter raised important issues for our profession. It is a tad technical, so feel free to skip it, but I found it to be helpful and interesting, AND it motivated the President/Designer of Pathagoras, Roy Lazris, to respond with his own creative and constructive ideas. I will post Roy’s letter also, in a few minutes. It is good to know that some of us are working hard to improve the quality and efficiency of our written work product.To their credit, the “non techies” are responding with their questions and comments. I hope our clients benefit from the dialogue. Burt Hunter
Next, Scott’s words of wisdom: (Scott is exceptionally bright, and this e-mail took time and work, and I sincerely appreciated it. J.B.H. 2/19/2012)
To paraphrase Cicero, if I’d had time, I would have written a shorter email, especially if I’d intended it for a larger audience. But, go ahead: I’m sure most people on the list already think I’m a bit of a windbag. I’m happy to continue hearing about this and other efforts you are making to push better use of technology in the practice of law.
The tone of this email seems a bit wistful, so I thought I’d drop you a note of encouragement. I’ve learned that being a tech pioneer, particularly an altruistic one, bears a striking resemblance to being a pioneer in the 19th century American plains: the view of wide open vistas, pregnant with innumerable possibilities AND the sound of crickets chirping and numbing loneliness. I also wanted to explain why I’m not following this particular set of wagon tracks. In theory, I share your enthusiasm for a central clause/form database. Even the evil insurance companies ultimately saw the wisdom of centralized, standardized form policies. The problem in the legal industry is the present state of the word-processing market, coupled with the lack of market pressure to develop better tools.
I realize a majority of attorneys use Microsoft Word and virtually all the remainder use WordPerfect. “Virtually all” isn’t “all,” however: I use Lotus WordPro. And, a hardy few of our sisters and brothers use OpenOffice or word processors for the Mac. Because we put up with it, the purveyors of word processors continue to lock us into proprietary formats. Because our documents tend to be heavily structured, with automatic numbering, footnotes, etc., the “minor” formatting differences become huge issues for us. It shouldn’t be this way, and it doesn’t have to. The entire point of HTML and the reason the WWW exploded was because Tim Berners-Lee saw the importance of separating content from structure. Over 10 years ago XML promised even more abstraction, including the ability to permit disparate databases with disparate naming conventions to exchange data. Notwithstanding their marketing claims, however, the word-processor manufacturers haven’t truly implemented XML.
Take any reasonably long pleading created with Word 2007 or later and saved as “Office Open XML” and then try to open it with any other word-processor, including OpenOffice or Google Docs; or, try the reverse. Go ahead and try it, I’ll wait (although you should make sure there are no children or people sensitive to cursing in the room when you do, especially if you’re working on a deadline)… At least one of the programs didn’t crash? You get 2 points. At least one of the programs actually opened the document without throwing an error message? You get 2 more points. Both programs actually opened the document without throwing an error message? You get 2 more points. Seriously: I will offer you a standing bet of $100 that you will suffer formatting problems at the very least. Accordingly, to fully implement your vision we either must:
1) all use the same word-processor and commit to continue doing so for the foreseeable future;
2) all use the same proprietary document-assembly program and commit to continue doing so for the foreseeable future; or
3) do our best to coordinate clauses so that when someone realizes that there is a huge market for XML editors with consumer-friendly features we can move more quickly to implement “pick, plug, print” (you can steal my phrase if you like it, but you have to footnote me).
Since I think option 3 is the best, I’m happy to send you whatever forms you would like to contribute to the content side of your project. I can’t commit to spend the time to test or work on the field/clause side of the project, however, because at present I can’t use Word forms. Obviously, you’ve gotten me a bit worked up on the topic, so let me conclude by describing the sod cabin I’m living in and the house I’m beginning to work on. For the last 15 years, we use fields to hold structured data like names, pronouns, addresses, party designations, venue, CS amounts, etc. Our Lotus WordPro forms have field references for that data. The field variables can either be input directly through WordPro, or can bilaterally exchange with structured fields within our Lotus Notes databases. I have not taken the time to implement large clause changes based upon field values. In other words, your Pathagoras
The reason I haven’t spent the time to implement more clause-based assembly within our existing system is because I decided to invest my time in the next version of our system. My office uses Lotus Notes for virtually everything, from communication to calendaring to content storage to document management. Every matter has a database which stores every bit of information about the case. It contains all of our communications relating to that client; notes from every meeting; every letter, pleading, or other document is stored with fields for the metadata.
I developed version 1 of the database when Kmart dumped >100,000 emails and internal documents in response to a discovery request. OCR helped to sort the majority and then we extracted the metadata by hand (author, recipient, date, subject, etc). When I went to Chicago to depose the executives, I had an instant list of every email they had sent, received, or seen. I borrowed from CaseMap the notion of storing “facts,” with links to the source.
In version 2, I expanded the database to store every scrap of information about a case. That meant that we could link everything. My hearing outlines–created within Lotus Notes–are then linked to the data within the database. So, when I tell the judge that my client’s 2009 income was $50,000, there is a hyperlink to the tax return. When I tell the judge that the statute or case says thus and so, there is a hyperlink to the full rule, statute, or case. When I tell the judge that opposing counsel sent an email saying such and such, there is a hyperlink to the email.
At the conclusion of the case, the bill can be reviewed against a view of all the entries in the database, since every phone call, email, letter, pleading, everything, is in there. And, we use it to manage our workflow: once a case manager has created the initial draft of a document, she sends a link to me; once I’ve completed and approved it, I send a link to her. The system can then automatically check for assignments which are past a certain due date.
For version 3, I’m working on the document assembly part. I’m using Java and XML to dynamically create documents from the data and form banks. I suppose the best way to explain it is to say that I can create a “document” which is more like watching a surveillance camera in real time. When it’s time to file a pleading or send a letter by creating a pdf, it’s akin to pressing the pause button on the surveillance camera.
The exciting part is the level of abstraction. Currently, we have a several step process to copy from the equitable distribution spreadsheet and paste it into the settlement agreement. I’m working on combining the live spreadsheet data with the structured data with form clauses: change the value of an item, and the settlement agreement dynamically changes the offsetting payment; change the distribution of an item, and the settlement agreement changes too. The other big feature of version 3 will be master checklists for the entire course of the case.
The checklists will initiate processes to prompt the user to input or obtain necessary information, as well as initiating the production of the documents referenced above. The checklists will have expected durations / deadlines. For the last two years, we’ve tried to structure our data capture about judges, attorneys, and case variables.
The idea is that a case without children, before Judge Jackson, with attorney A, would have a tighter timeline than a case with children, before Judge Longo, with attorney B. The data will permit us to identify common bottlenecks. More importantly, it will permit us to intelligently price our services. Finally, I intend to use it during our employee evaluations: you met or beat timelines x% of the time, etc. For version 4, I plan to automate the process of extracting metadata from documents we receive. Version 5 would automate the filing as well. Currently, everything is scanned and OCR’d.
Then, the case manager creates an entry in the particular client’s database, and manually inputs the important metadata. I want the OCR program to email the document to Lotus Notes, which would extract the metadata, determine the appropriate client, and make the appropriate entry in the database. Anyway, I’ve gone on far too long with this monologue, I just wanted to let you know that I’m glad you’re continuing to push, and I’m especially grateful that you’re so willing to share your thoughts and work.
This post was written by Burton Hunter