This is Part 4 of 10 in the eFiling Blog Series, check out Part 3 here.
Courts understand the critical importance of and need for integrating the eFiling system (EFS) with the court’s Case Management System (CMS).[1] OK; but what should that integration look like? Just like saying you need transportation to get from home to work, saying the court needs to integrate the systems does not end the discussion. Do you want to buy a car? Join a carpool? Take the bus?
The good news is, there are choices. The other news, though, is that each choice has its own implications. Like the transportation choices, some offer great power and simpler maintenance; but at a price of limited flexibility and unanticipated dependencies.
First, how tightly integrated should the EFS be integrated with the CMS? At first blush, one might assume the tighter the better. If the EFS and CMS are actually the same system, one would think they could more easily act in concert.
Perhaps. However, consider where the CMS “lives”. Almost certainly the strongest security surrounds the CMS, and it will be placed behind a secure firewall. A firewall exists to control – read “limit” – access to that which lays behind it. In a tightly integrated EFS/CMS, “holes” must be drilled through the firewall to allow the filed documents in. Like holes over an ice-covered lake, while no one hole may jeopardize its integrity, the more you drill, the greater the risk of failure.
Furthermore, the CMS will, of necessity, require a certain amount of “down”, or off-line, time. During the down time, the system may be unable to accept filings.
Shielding the EFS from the CMS using an intermediate system can ameliorate these limitations. Essentially, the CMS will “push” a replica of the salient part of its data (the EFS only needs access to some, not all, CMS data) to a cache available 24/7 to the EFS. Communication between the EFS and the CMS can then operate in a much more flexible asynchronous (when ready) fashion, rather than facing either lock-step synchronicity with the attendant “dead” periods during which filing services would not be available. The tradeoffs include synchronicity (must the E-Filing system have access to up-to-the-second current CMS data?) and the overhead of “pushing” CMS data to the EFS.
Second, eFiled documents must be docketed in the CMS. One of the major advantages of eFiling to the court is leveraging the system to facilitate or completely perform the posting, depending on the type of document and the court’s comfort level with rule-driven posting (usually starting quite conservative, and becoming more automated as experience is gained).[2] This requires integration with the CMS. Otherwise, docketing will still have to be done by the clerk, just as in the “paper” system.
Some CMS’s allow direct, or “hard link”, integration. However, where either the CMS does not have hard link capability, or if there are other reasons not to couple the systems quite so tightly, the EFS should be capable of providing the linkage from its end.
Each CMS has its own set of “codes” or object types, for documents. These can run the gamut from very general to very specific. For example, “Motion” could generically refer to any kind of motion; while “Motion to Allow Substitution of Counsel” would be quite specific.
This creates a couple of challenges for EFS/CMS integration. On the one hand, since courts typically have to “accept” just about anything that is filed (I keep hearing the example of a napkin, which seems a little farfetched; but you get the idea), the fact that the “code” used on a document may be incomplete or incorrect cannot stop the filing process. However, it can and should affect whether and how the docket entry in the CMS is made. A solid EFS with good workflow capability can be used to set the docketing “rheostat” from full clerk review every time, to “exceptions only”, to full auto docketing.
The “plumbing” of the EFS/CMS integration can come in different forms; and is generally dependent on the sophistication of the CMS. The preferred method of getting information from the EFS to the CMS is by using Web Services. Most modern CMS’s are built with Web Service capability. In those cases, EFS/CMS communication can be straightforward, based on the EFS standards. Because the Web Services are standards-based, they easily accommodate subsequent changes in either the EFS or CMS.
Older CMS’s, which may not be Web Service enabled, must be accessed either through a custom-built Application Program Interface (API), or through direct database access through database querying. API’s provide a lot more control and security, but have a cost to build and maintain. Major changes on either side of the EFS/CMS fence will probably require changes to the API’s.
Of course, in addition to receiving documents from outside filers, a court also generates its own documents, like notices, orders, letters, etc. Older CMS’s probably have data fields for physical mailing addresses. But not all have data fields for email addresses or websites.
Again, it often makes sense to offload the responsibility for sending out documents to the EFS, which can keep track not only of who should get what, but where the documents should be electronically delivered, not to mention what was sent, and when, and whether it was received.
To take advantage of the key benefits of eFiling requires integration of the EFS and the CMS. How that actually looks depends on business, financial, technical infrastructure (CMS, communications, ECF architecture, and so on), security, and performance considerations. Each court should carefully examine how it makes the most sense to integrate its systems.
[1] See Mrs. Wormer’s Coat, posted February 17, 2014
[2] Formally known as the Court Record MDE (Major Design Element) of the ECF filing standards. See the coming post concerning The Life of a Document After eFiling.
Coming up next: Blog 5 of 10: eFiling Blog Series – Life of a Document After eFiling
Trackbacks/Pingbacks