EFM-CMS Interface Requirements

Version: Version 6, 6/04/2001

http://www.legalxml.org/california/files/CMS_API_Rqmts6.pdf

Revisions: Version 5, 5/23/2001 http://www.legalxml.org/california/files/CMS_API_Rqmts5.pdf Version 4, 4/12/2001 http://www.legalxml.org/california/files/CMS_API_Rqmts4.pdf Version 3, 3/12/2001 http://www.legalxml.org/california/files/CMS_API_Rqmts3.pdf Version 2, 2/15/2001 http://www.legalxml.org/california/files/CMS_API_Rqmts2.pdf Version 1, 2/13/2001. Initial draft.

Author(s): Version 6 Mark Yuan ([email protected]), Steve Spohn ([email protected]) Version 5 Mark Yuan ([email protected]), Steve Spohn ([email protected]) Version 4 Mark Yuan ([email protected]), Steve Spohn ([email protected]) Version 3 Mark Yuan ([email protected]), Steve Spohn ([email protected]) Version 2 Thomas Smith ([email protected]) Version 1 Thomas Smith ([email protected]) Additional Contributors: Dwight Daniels ([email protected]) Marty Halvorson ([email protected]) Rich Himes ([email protected]) John Messing ([email protected]) Moira Rowley ([email protected]) Thomas Smith ([email protected]) Editor: Roger Winters ([email protected]) EFM-CMS Interface Requirements

Abstract

Legal XML, Inc., is building standards to enable electronic filing of documents to a court file. The Court Filing Work Group has identified key components of this process. One of these is the Electronic Filing Manager (EFM) application. Among the tasks for an EFM is interacting with a court's Case Management System (CMS). Heretofore, one of the principal obstacles to the rapid deployment of electronic filing services has been the difficulty encountered in defining a standard way for any given EFM application to deal with the great variety of CMSs. The purpose of this document is to establish requirements for an interface for EFM-CMS interactions.

Status of Document

Released for comment.

Table of Contents

Abstract...... 2 Status of Document...... 2 Table of Contents...... 2 Introduction...... 3 Problem...... 4 Proposed Solution...... 5 Definitions...... 5 Dependencies...... 7 Assumptions...... 8 Requirements for the Specification...... 10 EFM-CMS Interface Requirements...... 10 1. CMS Data Configuration (CDC) XML...... 11 1.1 EFM-CMS Connection Management Details...... 11 1.2 Case Type Transactions...... 11 1.3 Data Elements...... 12 1.4 Response Data Elements...... 13 2. EFM-CMS Connection Management...... 13 2.1 Connection Initiation...... 14

06/04/2001 Version 6 2 EFM-CMS Interface Requirements

2.2 Authentication...... 14 2.3 Version Identification...... 15 2.4 Graceful Termination...... 15 3. Court Policy XML Population...... 16 3.1 CMS Data Configuration XML file...... 16 3.2 Version Control...... 16 3.3 Court Filing Policy XML Extensibility...... 17 4. Filings...... 17 4.1 EFM-Initiated Transactions...... 17 4.2 CMS-Initiated Responses...... 18 5. Confirmations...... 18 5.1 EFM-CMS Application Interactions...... 18 5.2 Confirmation to EFSP, Filer...... 19 6. Query/Response...... 20 6.1 Predefined (Normative) Queries...... 21 6.2 Queries...... 22 6.3 Responses...... 22 6.4 Controlling the Use of Query/Response...... 23 7. Court Initiated Transactions...... 23 7.1 Send Notice of Court Activity...... 24 8. Document Management System...... 24 8.1 DMS Support...... 25 8.2 CMS Integrated DMS...... 25 8.3 EFM-Provided DMS...... 25 9. Error Handling...... 25 9.1 General Error Detection and Reaction...... 26 10. Security and Audit...... 26 11. Supported Transport Technologies...... 27 Appendix...... 28 A1. Example EFM Architecture...... 28 A2. The EFSP-EFM-CMS Environment...... 29

Introduction

This is a requirements document written to identify those things considered to be necessary for an Electronic File Management (EFM) application to interact with a Case Management System (CMS) application for the purposes of processing electronic filings and queries. When completed and accepted by consensus of the Legal XML Court Filing Workgroup, this requirements document will be the basis for a specification document.

Perusal of the Appendices (A1. Example EFM Architecture, page 28, which describes one possible architecture, and A2. The EFSP-EFM-CMS Environment, page 29) is recommended for an introduction and background for this subject.

Problem

There are many important reasons for using standards to guide the building of electronic filing for courts anywhere. If every court were to go it alone, there would be a patchwork of systems with different software, procedures, document types, and results. Only a few courts would be able to afford to build such complex interacting systems. Attorneys would find it very difficult to use electronic filing technology when the requirements would change depending on the court. Few legal service providers, system developers, consultants, or integrators would find it profitable to build systems supporting such diverse systems. Electronic filing will not succeed or be widely available without standards.

Of the obstacles inhibiting the wide scale implementation of electronic filing in the courts, two are especially significant:

1. EFM applications must be designed to interface with any CMS applications so data can be reliably and efficiently exchanged between them.

2. EFP and Electronic Filing Service Provider (EFSP) applications must be able to collect and validate the data needed by any one of potentially hundreds or even thousands of different CMSs.

Experience has shown that the interfacing of EFM applications with CMS applications is a non- trivial undertaking. The complexity of the task increases with the sophistication and complexity of the CMS application. Since very few CMS applications have formal APIs (and, for the few that do, licensing can be an issue), EFSP and EFM application developers are often stymied in trying to implement electronic court filing services. The practical problems confronting the developers may include:

 Generally, they do not have access to the CMS application’s source code

 If they have the source code, they will have to spend substantial time working to understand the internal details of the application

 Work they might do on the software could void the warranties or support agreements provided by the vendors of the CMS application

Providers of commercial off-the-shelf CMS products, for their part, are faced with problems encountered because of variations in the court-specific configurations and highly customized products designed for specific customers. For courts that develop their own CMS systems, many of the same problems of non-standard applications and interfaces apply. They and vendors who

have arrived recently to the field, will find the existence of standard API calls to be very beneficial. The time and cost of the work required to marry an EFM to a CMS can be substantially reduced when one or both of the applications can be designed to a standard that defines common mechanisms for interaction. This requirements document begins the process of defining this standard.

Proposed Solution

An Application Program Interface (API) is a supported method by which an application exposes its functionality, allowing developers to create programs that will integrate with that application. This document establishes the requirements for a standard API for EFM-to-CMS interaction (the "Interface"). Implementation of an API can:

 Simplify the normally complex undertaking of interfacing EFM applications with CMS applications

 Give courts greater freedom of choice among the EFM and CMS applications available to them from vendors

 Accelerate the spread of electronic filing services throughout the courts

Definitions

API Application Program Interface, a supported method by which an application exposes its functionality. The API allows developers to create programs that integrate with that application without exposing proprietary processing codes of the application.

CDC XML CMS Data Configuration XML, an XML-structured document1 that describes the case types, transactions, data elements, and other particulars of a given court’s CMS.

CMS A court's Case Management System. A CMS may or may not also include or be logically or technically linked with a Document Management System (DMS).

1 At the time of this writing, Legal XML has not made a decision on whether these documents will be XML DTDs (Document Type Definitions), XML Schemas, or something else.

Court Filing DTD The current version, and any immediately prior version, of the JTC2/Legal XML Proposed Standard for Electronic Court Filing as described at http://www.legalxml.org/.

Court Policy XML

Courts shall express their policies and practices in an XML-structured document that complies with Legal XML, Inc.’s emerging Court Policy XML Specification. Electronic Filing Service Provider (EFSP) applications will interrogate the Court Policy XML of a particular court through the court’s (or its CMS’s) EFM application to determine what it can (or cannot) send to that court.

DMS A Document Management System is a records system that includes the scanning of paper documents into images (if included), indexing, storing, retrieving, searching, and manage documents (both paper and electronic).

DTD/Schema A Document Type Definition or W3C XML Schema, whichever method Legal XML, Inc chooses for various specifications.

EFM Electronic Filing Manager. A software application (sometimes called "middleware") that accepts electronic filings and processes those filings for submission to a court's CMS. The EFM returns acknowledgements to the filer (via the filer's EFP or EFSP) and the responses to user queries as received from the CMS.

EFP Electronic Filing Provider. A software application, residing on the filer's desktop or provided by an EFSP, that is used to create and/or transmit an electronic filing.

EFSP Electronic Filing Service Provider. This may be a for-profit business or organization that provides electronic filing services to filers of documents with courts. This involves software applications (EFPs) that filers use to prepare and/or to submit electronic documents to be filed, as well as software that sends their filings to a court. This service may be provided by private vendors or by courts themselves.

Filer The entity or person who makes an electronic filing.

2 JTC is the Joint Technology Committee of the Council of State Court Administrators (COSCA) and the National Association of Court Managers (NACM).

Interface The generic term used in this document to refer to an EFM-CMS API.

Privilege A court may treat certain information as privileged (or “confidential” or “sealed”) and restrict it from view by the general public. However, a subset of the public, such as attorneys, parties to the case, court staff, or others may be granted the privilege to view this information even though it is not generally available to the public.

RPC Remote Procedure Call. A means for cross-network application-to-application communication.

SOAP Simple Object Access Protocol. An XML-based protocol for cross-network communication (see http://www.w3.org/TR/2000/NOTE-SOAP-20000508/).

Dependencies

1. Court Filing Standard. JTC/Legal XML Proposed Court Filing Standard (http://www.legalxml.org/DocumentRepository/ProposedStandards/Clear/PS_10001/PS_100 01_2000_07_24.htm).

2. Court Policy XML. A work in progress within the Court Filing Workgroup of Legal XML. This standard document will be the vehicle for expressing a particular court’s policies affecting other aspects of Court Filing and related standards.

3. Query/Response XML. A work in progress within the Court Filing Workgroup of Legal XML. This standard document will be the vehicle for defining available queries and the range of responses related to court CMSs.

Other references of possible interest include:

1. Certification. Unofficial Note on Legal XML Certification. This is to establish the process by which applications are to be certified as compliant with standards established by Legal XML, Inc. (http://www.legalxml.org/california/files/Certification3.pdf).

2. CEFTS. Proposed California Electronic Filing Technical Standards (current version available via http://www.legalxml.org/california/#TechnicalStandards).

3. OXCI. Open XML Court Interface (OXCI) architecture, Working Draft. This is a collaborative effort whose goal is to design and develop a software application compliant with Legal XML

standards and with the API whose requirements are defined in this document. (http://www.legalxml.org/California/files/OXCIArchitecture2.pdf).

Assumptions

1. Audit Logs. We assume logs will be maintained by the EFM and CMS applications, and are outside the scope of the Interface defined in this document.

2. Document Fidelity. End-to-end document fidelity is an important issue, but outside the scope of this requirements document. We assume that mechanisms for ensuring document fidelity shall be covered by the LegalXML Signatures Workgroup (http://www.legalxml.org/signatures/).

3. Compliance Levels. We assume that compliance levels will be defined for required (also called "core") and optional functions of the API, and we assume that a multiple level compliance structure may emerge. (A base-level compliant API will include core functions. Higher level compliant implementations will implement the core functions plus a progressively greater number of optional functions.) See reference Certification in Dependencies on page 7 regarding Legal XML certification issues.

4. Document Management. The CMS may (or may not) perform document management functions. If it contains components that perform document management functions, then these components are better referred to as part or all of the Document Management System (DMS).

5. Transport Layer. The Interface can be designed to work over multiple transport layers, that is, the Interface should not be tied to a single transport layer protocol such as TCP/IP. See 11. Supported Transport Technologies on page 26.

6. Court Policy XML. The concept of Court Policy XML has been discussed in the JTC/Legal XML Court Filing Work Group’s Proposed Court Filing XML Standard, but the details and specifications for this critical piece have not yet been fully worked out or specified. Both the Court Policy XML and the CMS Data Configuration (CDC) XML (see page 10) shall be members of a class of XML constructs that influence or control the functioning of court filing related applications.

7. Application Coupling. The Interface assumes a “loosely-coupled” implementation. In practice, the EFM and the CMS may be either loosely or tightly coupled. (“Tightly-coupled”

applications have a persistent connection between them that is not found with “loosely- coupled” applications.)

8. Transaction Granularity. Some CMS applications have complex processing rules, where transaction types are not determined until some time after processing starts, and may require a finer granularity3 for transactions they can process as defined in CDC XML.

[For Discussion: It is not assumed that the EFM or CMS must be able to read XML. It is assumed that some CMSs will be able to write ASCII text/XML so they can update the CDC XML.]

Requirements for the Specification

The following requirements pertain to the Specification for which this document provides the foundation as a statement of Requirements.

1. Simplicity. Implementations for EFM and CMS applications should be as simple as possible. If complexity is necessary, it should be kept as much as possible within the EFM application. The reasons for the suggestion that complexity, when unavoidable, be assigned to the EFM application is based on the following:

 The gating factor (that is, the process that controls the passing of a transaction from one place to another) for electronic-filing implementations is expected to be on the CMS side and, where this is so, making the CMS implementation simpler should yield faster implementation

 EFM applications are probably going to be developed using newer technologies, so they will be better able to accommodate complexity

 It is easier to design a new application (an EFM) than to modify a legacy application (a CMS)

3 “More granularity implies more flexibility in customizing a system, because there are more, smaller increments (granules) from which to choose.” (Reproduced by Atomica from the Computer Desktop Encyclopedia, © 2001 Computer Language Company Inc. All rights reserved.)

2. Atomicity of Transactions. All API calls shall be atomic, that is, the entirety of information needed by each CMS to perform a given task (e.g., to add a new case) must be provided in a single transmission to that system. An EFM-CMS transaction may involve a series of database or processing transactions on the CMS, but that there is a series of steps is to be invisible across the Interface. The EFM or CMS will see each processing transaction as a whole transaction, i.e., an undivided atomic transaction.

3. Stateless Connections. The connection may be stateless, i.e., the state of the current transaction is independent of prior transactions, and therefore all transactions shall reflect that possibility.

EFM-CMS Interface Requirements

The ultimate purpose of this document is to provide unambiguous and sufficient requirements for the production of a Specification document. The following subsections identify functions proposed for the Interface.

1. CMS Data Configuration (CDC) XML

Once the Legal XML Court Filing XML was proposed as a Standard, the concept of a Court Policy XML emerged. A Court Policy XML would be needed to describe the preferences of a given court with respect to what it will accept as electronic court filings and how it will interpret various parts of the Court Filing XML DTD. Similarly, once the EFM-CMS Interface is proposed as a standard, another XML becomes necessary: one where parameters particular to a CMS are stored. This is called the Court Filing CMS Data Configuration XML, or more simply, the CDC XML. Requirements for a CDC XML include:

[Discussion Item: The CMS Interface Workgroup will be defining the CDC XML DTD. The DTD needs to be specified in the Specification document, and not in this Requirements document.]

1. Published CDC XML. The court (preferably through its CMS) must create and publish a file containing the court’s CDC XML. This transaction is independent of the EFM-CMS Interface: the CDC XML is to be created and written to a file without invoking the Interface (see 3. Court Policy XML Population, page 15).

2. Location of the CDC XML. The location of the CDC XML must be made known to the EFM application. The Universal Resource Indicator (URI) or file directory location of the CDC could reside in the Court Policy XML, assuming the EFM will know where to find that.

3. The DTD or Schema of the CDC XML. The DTD/Schema for a CDC XML must be as simple as possible. There must be no assumption made that the CMS programmer or the CMS application has access to XML or to Document Object Model (DOM) tools. This helps to fulfill the desire to keep the technology and learning curve related to the CMS as simple as possible, reflecting Requirement 1 (see Simplicity, page 9).

1.1 EFM-CMS Connection Management Details

Parameters controlling the initiation, control, and termination of EFM-CMS connections are to be contained in the CDC XML. Examples include:

1. A Transaction Timeout value and a Transaction Retry value (see 2.4 Graceful Termination, page 15).

1.2 Case Type Transactions

1. Supported Case Types. The CMS must identify the types of case filings it supports.

2. Consistency with the Court Filing DTD. The specification of the supported case types should reflect and not diverge from the hierarchy of the current or immediately prior Legal XML Court Filing DTD.

1.3 Data Elements

1. Required Data Elements. For each case type transaction it supports, the CMS must specify the data elements (fields) required and the name (label) by which the CMS knows each of them.

2. Optional Data Elements. For each case type transaction it supports, the CMS may specify optional data elements (fields) and the name (label) by which the CMS knows each of them.

3. Data Element Attributes. For each such optional or required data element, the CMS must specify its:

3.1. Length

3.2. Data type

3.3. The name of the Court Filing XML Standard DTD element in which the data is to be placed

4. Data Element Validation. For each data element, the CMS may specify validation criteria consisting of a:

4.1. range (for example, "greater than zero but less than five", or "not equal to zero");

4.2. list of values of unlimited length (for example, "MOTN1, MOTNS, MOTNW");

4.3. table consisting of an unlimited number of rows containing (1) a value to be matched, and (2) a literal describing that value (e.g., this is a row example: "MOTNS, Motion for Summary Judgment");4

4.4. a predefined constant (for example, "Date"). Predefined constants seem to be useful, if not necessary, unless a CMS is to publish its CDC XML file daily.

5. Character Encoding. UTF-8 character encoding is required.

1.4 Response Data Elements

In the near future the Query/Response content model of the Court Filing Standard will have to be developed. There is a discussion of the need for predefined standard queries and the Query/Response mechanism in the section on Interaction With Court Databases in the reference, California Electronic Filing Technical Standards (CEFTS) in Dependencies, on page 7. The Query/Response component will provide a means to identify:

1. The queries a court will honor and to which it will respond;

2. For each such query, the data elements the court will provide in response to the query;

3. For each such data element, a mapping to the Legal XML Court Filing DTD and its Query/Response content model.

4 Author's note: the literal could be used for populating a pick list presented to an end user.

2. EFM-CMS Connection Management

The typical implementation of an EFM-CMS interface will entail the EFM application interacting directly with the CMS application. There are variants to this generalization, such as when there is one EFM that must deal with several CMSs. There may even be situations where there is one CMS talking to several EFMs. For any variant, there must be a way for an EFM application and a CMS application to initiate and manage their interactions. There are three possible types of connections:

Type 1. Connections that are initialized for each individual transaction can be called “transient” connections. This is the least efficient method, because no assumptions can be made regarding the application at the other end of the connection, and the initiating application must assume that the other application has no knowledge of it. Because of this, the initiating application must read the Case Management System Data Configuration (CDC) XML every time a transaction is initiated.

Type 2. Connections that are initialized on a per-session basis can be called “session” connections. They allow required connection parameters (e.g., the CDC XML version, application authentication) to be maintained between transactions. Session connections allow a graceful termination by invalidating the session object.

Type 3. Connections that are initialized once per instantiation of the application can be called “tightly coupled” connections. This type of connection is a long-term version of type 2, above.

The methods required for this function are described in the following section.

2.1 Connection Initiation

1. Initiation. Either an EFM or a CMS can initiate a connection.

2. Connection Persistence. The duration of a connection can be persistent (i.e., indefinite) or, it can last only for the duration of a single transaction.

3. Connection Initiation Details. The details for establishing the connection are published in the Court Policy XML. These details include such things as the network name/address of the CMS, and whether sessions can be persistent or not.

It should be noted that if connections are initiated on a per session basis, then any connection initiation invalidates the previous session.

[Author's note: CDC XML is published by an individual court, so it seems reasonable that the CDC XML can contain information about where the EFM will find the CMS. It is less obvious how information about where the EFM is located will make its way into the CDC XML. The EFM location information could reside in the Court Policy XML, but it must also be available to EFSPs so that they can get to the Court Policy XML via the EFM. As an alternative, the bi-directional nature of connection initiation could be relaxed, so that only the EFM would be allowed to initiate connections.]

[For Discussion: At some point, people implementing these systems are going to have to get involved in the process. At the least, they will have to decide where the EFM and CMS can be found or they must agree upon a common location where anyone can look for this information.]

2.2 Authentication

1. Session Initiation. The EFM and the CMS must authenticate each other. The systems should assume nothing about who it is that is initiating the session.

2. Authenticate Method. The API must support an Authenticate method.

[Discussion: -- The requirement to have an audit trail, and hence, the importance of storing and being able to compare state information is recognized and, in fact, is assumed. However, the mechanism to do this is not appropriate for this requirements document and is left to the LegalXML Signatures Workgroup.]

2.3 Version Identification

1. Interface Version. The EFM and the CMS must verify that they are using the same or, at least, compatible versions of the Interface (API).

2. CDC XML Version. The EFM and the CMS must verify that the EFM is using the most recent version of the CDC XML published by the court (see also 3.2 Version Control on page 16).

[Discussion: (1) The CDC XML is likely to change infrequently; (2) the EFM must read and interpret the CDC XML each time a connection is initiated, and if the connection is type 1, then the EFM could spend considerable time or processing cycles, preparing for each connection.]

2.4 Graceful Termination

1. Bilateral Control. Either the CMS or the EFM must be able to gracefully terminate a transaction. The normal mode of transaction termination should be for the process initiating the transaction to be the one that terminates it.

2. Transaction Timeout. A transaction timeout value must be specified in the CDC XML, and the failure of either application to provide an expected response within the timeout period should cause a retry of the expected transaction. A retry should be identified as such; otherwise, the retry could be interpreted as a new request.

3. Transaction Retry Limit. A transaction retry limit value must be specified in the CDC XML, and the failure of that number of retries should result in the following sequence:

3.1. Retry

3.1.1. Reinitialize the connection

3.1.2. Reset the transaction retry counter

3.1.3. Send the transaction again, with the retry flag set

3.1.4. Increment the transaction retry counter

3.1.5. When the maximum number of retries has been exceeded, declare that the connection is broken

3.1.6. Gracefully terminate the connection. [Author's note: the Transaction retry limit value wasn't specifically identified in Tucson, but it seems to be necessary.]

4. Manual Intervention. Where manual processes are involved in completing a transaction, the end of the transaction should be the successful receipt of the transaction request. Such special transactions should be identified in the EFM-CMS API specifications.

3. Court Policy XML Population

Since the CMS application is responsible for publishing what it needs in the way of data elements and validation tests to process a filing, there must be a way for it to do so, namely by populating a Court Policy XML with specific information of this sort.

3.1 CMS Data Configuration XML file

1. CDC XML File Creation. The Court (preferably, the court’s CMS) must write a CDC XML file, as described above in 1. CMS Data Configuration (CDC) XML (see page 10). This is to be done independently from the Interface; that is, there is no function or method that belongs to the Interface that would perform this action. [Discussion: While it would be feasible for the CMS to append or modify a segment of the Court Filing Policy XML file (assuming it is a file) with CDC XML elements, the approach suggested here of a separate file for CDC XML appears to have the advantages of (1) simplicity for CMS developers (Requirement 1), and (2) avoiding the possibility of the CMS routines inadvertently damaging the Court Filing Policy XML file.]

2. Well-Formedness. The CDC XML must be well-formed.

3.2 Version Control

1. CDC XML Version. Each edition of the CDC XML file shall have a unique version identifier.

2. CMS Version Verification. The CMS shall be able to verify the version of the CDC XML that is to be used to format a given transaction, i.e., the CDC XML version identifier is included in every transaction.

3. Test Version. The CMS application may create and publish a test version of a CDC XML file.

[Discussion: This would allow courts to publish upcoming versions and provide EFSPs the opportunity to test their end-user applications (EFPs) with a test CDC XML. If this is indeed a useful function, then availability and location would need to be specified.] [Note to Version 4. The prior version of this document postulated the need for a "CDC XML Publication Window", a pre-designated period during which EFSPs would expect Courts to issue new CDC XML files. That concept was rejected in San Francisco, and replaced with using the Court-Initiated Transaction mechanism (see page 23).]

3.3 Court Filing Policy XML Extensibility

It is possible for a court to add one or more unique ("custom") elements to the set of elements defined in the Court Filing Proposed Standard (that is, extensibility is permitted). As discussed in 1.3 Data Elements (page 11), the CDC XML includes a mapping of CMS data elements to Court Filing Standard elements. This same mapping technique applies to custom elements: a CMS data element is mapped to an extension of the Court Filing DTD.

1. Court Filing DTD Extensions. Required Court Filing DTD extensions, identified in the CDC XML, shall also be required for the EFM or EFSP applications. Optional elements need not be provided by an EFSP, but the EFM and API must process all CDC XML- defined elements. [Discussion: The optional nature of the Interface's handling of extensions was discussed in Tucson as a means for discouraging deviations from the Court Filing Standard. This implies that there would be no such thing as a required extension. This was not deemed realistic in a later meeting in San Francisco and was changed to reflect that view. However, while prohibiting extensions makes the API unworkable, allowing extensions risks the proliferation of DTDs, so care must be exercised in requiring extensions.]

4. Filings

The following describes the functions/methods supported by the Interface for processing court filings. These transactions include party/address, attorney/address, fees paid, and all other data elements.

4.1 EFM-Initiated Transactions

1. Transaction Functions. There must be two filing transactions provided by the EFM-CMS Interface:

1.1. Submit initial filing

1.2. Submit subsequent filing

2. Atomic Transaction. All transactions must comply with the Atomicity of Transactions requirement (see page 10).

3. Required Data Elements. The EFM application must present to the Interface all required data elements for the pertinent case type transaction, as these required data elements are described in the CMS's CDC XML file.

4. Optional Data Elements. The EFM application may present to the Interface any optional data elements for the pertinent case type transaction as these optional data elements are described in the CMS's CDC XML file.

5. Validation of Data Elements. The EFM must validate any data elements it presents to the Interface using the validation criteria for that data element that are contained in the CMS's CDC XML file.

4.2 CMS-Initiated Responses

CMS responses to filing transactions are provided below, in 5. Confirmation on page 18.

5. Confirmations

5.1 EFM-CMS Application Interactions

The following applies strictly to the management of transactions between the EFM and CMS applications.

For transactions taking place across a computer network, normal network protocols are generally sufficient to manage communications. The only requirement there is for a confirmation or an error message. For other cases, acknowledgements must be generated by the application. There should be the same message content in these cases, i.e., confirmation or error, as is transmitted in the case of applications connected via a computer network.

1. Acknowledgement. The receiving application must always send an acknowledgement, whether positive (acknowledged) or negative (error[s] noted), for any transaction it receives; the acknowledgement must go back to the originating application. The response shall consist of a confirmation message or an error code.

2. No Acknowledgement. The failure to receive an acknowledgement shall lead to a retry of the transaction (see 2.4 Graceful Termination, page 15).

3. Connection Type. Any EFM or CMS interface should be able to tell whether the connection between the applications is through a network.

5.2 Confirmation to EFSP, Filer

The following pertains to the Confirmation element of the Legal XML Court Filing Standard DTD, Version 1.0. This applies to the situation when the CMS has determined whether it will accept or reject a filing.

1. CMS Response. The CMS must respond to a filer (or EFSP) regarding its acceptance or rejection of a filing.

2. Data Returned. The CMS must return as many of the data elements defined in the ConfirmationInformation content model of the Court Filing DTD as it can (see reference Court Filing Standard on page 7).

3. Filing Status Returned. For each document it processes, the CMS application must provide the EFM with a value that conforms to the FilingDisposition attributes of the LeadDocumentDisposition element in the Court Filing DTD (see reference to the Court Filing Standard on page 7).

4. Rejection Message. If a filing is rejected, the CMS must provide a message describing the nature of the rejection; this is provided for the Memo element of LeadDocumentDisposition.

5. No NAK5 Confirmation. When a specific NAK is sent, no confirmation message is sent.

5.3 Confirmation Messages with Manual Intervention.

Confirmation messages that follow completion of a manual intervention step allow (according to the Court Filing Standard) a second confirmation message to be sent, indicating the success or failure of the manual step.

When the manual intervention step is contained in the CMS, this confirmation message is treated as a separate transaction initiated by the CMS. Transactions where manual interventions are possible are identified in the CDC XML. The EFM is expected to retain, for a reasonable period (to be defined), confirmation routing information, including at least the return address, for all such transactions. The EFM, when in receipt of a confirmation message for which routing information no longer exists, must return an error message to the CMS.

5 (Negative AcKnowledgement) A communications code used to indicate that a message was not received, or that a terminal does not wish to transmit. Contrast with ACK. (Reproduced by Atomica from the Computer Desktop Encyclopedia, © 2001 Computer Language Company Inc. All rights reserved.)

6. Query/Response

A Query/Response placeholder is provided in the Court Filing standard; it is as yet undefined, awaiting the completion of this Requirements document. Assuming one accepts the propositions that (1) the information made available by the court to parties and their attorneys is privileged (as opposed to "public"), (2) that the CMS (and DMS, if any) have the most current and comprehensive records for a case, and (3) that courts will not (and should not) grant free reign to roam CMS databases to anyone, it follows that there must be a collection of predefined queries for extracting data from the CMS. (For more on this subject, see Interaction With Court Databases in reference CEFTS in Dependencies, page 7).

[Discussion:

 In Tucson, it was postulated that the queries serviceable by a CMS application would be specified in a segment of the court's Court Filing Policy XML, referred to as Court Policy Q/R XML (but as yet undocumented by Legal XML).

 In San Francisco, it was agreed that a predefined collection of queries would be too inflexible, and that courts would define any queries and responses they care to support in their Query/Response XMLs (with, perhaps, counterparts in their CDC XMLs) in a manner conceptually similar to how a CDC XML will be used to define CMS transactions. A core set of predefined queries will be "normative", meaning that they will in fact be predefined and optionally supported by individual courts. A mechanism for conveying the semantics of court-unique (non-normative) queries was not identified.

 Also in San Francisco, the limitation of systems to two levels of access privilege (privileged and non-privileged) was replaced with the concept of an unlimited number of court-defined access privileges. Again, this is to be expressed in a Query/Response XML or CDC XML.]

The EFM provides an equivalent functionality of a (non-privileged) Public Access interface, and extends it to privileged access.

6.1 Predefined (Normative) Queries

While properly belonging in a Requirements document for the Court Filing Query/Response XML, this section is a preliminary attempt to identify predefined, or normative, queries that such a document would need to define.

1. Candidate Predefined Queries. The following queries may be assumed to be essential, so that they must be predefined for all systems:

1.1. GetCaseInformation: This would return basic data for the case.

1.2. GetActorStatus: This would return the status of the parties and attorneys to the case, with an indication any rights they have been granted to see privileged data.

1.3. GetAttorneyForParty: This would return information identifying the attorney(s) representing a given party. [HALVORSON COMMENT: I contend this is available from Case History, and therefore an explicit query is not needed.]

1.4. GetCaseHistory: This would return the list of events and the dates for those events for the case.

1.5. GetDocumentListForCase: This would return an index to the documents that belong to the case. [HALVORSON COMMENT: I contend this is available from Case History, and therefore an explicit query is not needed.]

1.6. GetMatters-ActionsOfCase: This would return the pertinent Matters or Actions in the case (e.g., the initial complaint, cross actions). [HALVORSON COMMENT: I contend this is available from Case History, and therefore an explicit query is not needed.]

1.7. GetCalendarForCase: This would return the calendared, scheduled events for the case.

1.8. GetFilingFee: This would return the filing fee, if any, as computed by the CMS, that pertains to the party for the filing. (Note: Filing fees are expected to be published in the Court Filing Policy XML, but that would simply be a static schedule of fees; this item is dynamic, assuming that the CMS has the ability to calculate fee amounts based on variables related to the party and filing.).

[HALVORSON COMMENT: This is gilding the lily. It presumes that static fees are seldom the same as computed fees. Further, it assumes that, in essence, the user is going to make the equivalent of a test filing to obtain the cost of the actual filing.]

1.9. GetCasesForActor: This would return the cases in which the identified party or attorney is indexed as being involved.

1.10.GetDocument: This would return a document or an index reference to a document in the case. [Author's note: this is not intended to dictate a naming convention for Interface methods.]

1.11.RegisterNewActor: This would register a new actor (filer) in the case.

1.12.InactivateActor: This would inactivate an actor (filer) in the case.

[HALVORSON COMMENT: I contend neither query 1.11 or 1.12 is a function of either the API or Court Filing. In both cases, an attorney submits a filing (entry of appearance or excusal). In neither case, should this be a part of the API or court filing for that matter.]

It is assumed that all methods would have parameters for ActorID/Password to ensure the Actor has been granted the appropriate privileges for any given operation. This may be included in an audit trail.

2. Query Invocation. In passing a query to the CMS, the EFM must provide the name of the query and all required parameters. It may also pass optional parameters defined for that query.

6.2 Queries

1. EFM Rejection. The EFM must reject any query that is not identified in the CDC XML as one that is supported by the CMS. The EFM must not request a response from the CMS.

2. CMS Rejection. The CMS must respond with an error for any query that it receives for an unsupported or unknown query.

6.3 Responses

1. Query/Response Data Elements. For each supported Query, the CMS's CDC XML must specify the data elements that can be included in the Response and returned.

2. Query/Response Data Element Mapping. For each data element that is returned in a Response, the CMS's CDC XML must specify the Court Filing Query/Response DTD to be used for element mapping.

3. Empty Response. The CMS is allowed to return an “empty” response (data not available for this request).

6.4 Controlling the Use of Query/Response

1. Quotas, Transaction Volume Restrictions. [Discussion: While this was discussed, there was no resolution in Tucson regarding the enactment of quotas or other means for restricting the number of queries someone could make over a given time period.]

2. Access Restrictions. Certain information returned by Queries will be privileged, that is, provided based on the grant of a privilege to the attorneys or parties involved in the case. In

instances where such privilege is involved, EFSPs must validate the role of the requestor (using the GetActorStatus query) before submitting any other predefined queries.

3. Levels of Access Privilege. Courts will define for themselves the number of levels of access privilege they grant:

3.1. The court will specify the queries, query parameters, query elements, the content that is returned, and the query label in its Query/Response XML or its CDC XML. The court will also define its levels of access privilege.

3.2. At a minimum, there will be two levels of access: Privileged and Public, where Public is a subset of Privileged.

4. User Identification. The API will provide the information necessary for user authentication (an Actor Identifier assigned by the authenticating application.) User identification can occur in any of the following applications: EFSP, EFM or CMS. However, the CMS is free to ignore the user authentication information.

7. Court Initiated Transactions

[DISCUSSION: The Tucson group was unable to reach consensus on the necessity or desirability of a Court Initiated Transaction function. Arguments in favor of the proposition can be found in Court Initiated Transaction in reference CEFTS in Dependencies on page 7. Opposing arguments were (1) that the capability significantly increases the complexity of the Interface (more specifically, the EFM operation) because CMS-generated transactions (such as issuing a notice, judgment, or order) would need to be associated with a specific EFSP/party combination, and (2) that this type of capability is outside of the scope of the Court Filing Work Group. In San Francisco, it was decided that this capability would be optional.]

Courts may send confirmation messages on completion of manual intervention processes as court initiated transactions independent of any other court-initiated transaction. See 5.3 Confirmation Messages with Manual Intervention.

7.1 Send Notice of Court Activity

Court initiated transactions are the distribution of documents from the CMS through the EFM to filers through their EFSPs or to specific filers. Court initiated transactions are optional.

1. CMS Invocation. This function/method may be invoked by the CMS application and executed by the EFM application.

2. Object. The CMS may pass a document, document reference, BLOB, URI, or XML for delivery to the intended recipient.

3. Routing. The EFM must resolve the recipient address (unless the CMS can resolve the address) and route the message to the appropriate EFSP/filer.

4. Confirmation. The EFM application must observe the rules for transaction confirmation as specified in 5.1 EFM-CMS Application Interactions on page 18. The EFM must tell the CMS if it cannot process a transaction (because of an unknown Actor Identifier, an invalid document reference, etc.).

5. Undeliverable Documents. When documents are known to be undeliverable to the end- user/filer, the EFSP sends the filing back to the court or follows a special protocol for errors, moving up through the message delivery chain.

6. Changes in the CDC XML. The CMS shall notify the EFM (and thus the EFSPs) of changes to the CDC XML via a Court-Initiated Transaction. [Author’s note: If the Court-Initiated Transaction method is not implemented for a court (since it’s optional), then there is no a priori mechanism for a court to notify EFM/EFSPs of changes in CDC XML.]

8. Document Management System

Document management services may be provided by a CMS or by an optional component of the EFM. (In some cases, no document management system may be implemented).

[DISCUSSION: While not specified in Tucson, it seems obvious that the Interface must accommodate a DMS wherever it is implemented.]

8.1 DMS Support

1. DMS Support Indicator. The CMS must indicate, in its CDC XML, whether it supports a DMS capability.

2. Affected Functions. The following functions are affected:

2.1. Filings (page 17);

2.2. Query/Response (page 20);

2.3. Court-Initiated Transactions (page 23).

8.2 CMS-Integrated DMS

Although integral with the CMS, the DMS document repository may be located anywhere (outsourced, etc.) In such situations, the functionality of the DMS is integrated with the CMS.

1. Document Transfer. Where the DMS capability is integral to the CMS application, the Interface must support the exchange of one or more documents (BLOB or otherwise). [Author's note: A court’s indication of what it considers to be acceptable binary document formats (PDF, TIFF, etc.) is a proposed candidate for Court Filing Policy XML.]

2. Document Reference. The CMS must return a value for the CourtDocumentReference element of the Court Filing DTD (see Court Filing Standard, page 7). [Author's note: this follows from the Court Filing specification.]

8.3 EFM-Provided DMS

1. Document Reference. Where the DMS capability is not integral to the CMS, the CMS must nonetheless accept a Document Reference provided by the EFM (and originated by the DMS). [Author's note: This potentially calls for a design change for some CMS products.]

2. EFM Document Retrieval. The CMS must provide a document reference to the EFM when requested by the EFM. The EFM may maintain its own reference information for documents.

9. Error Handling

[DISCUSSION: While not thoroughly discussed in Tucson, it was generally agreed that the Interface Specification should include a mechanism for handling errors. Examples of errors might be a request for a transaction that is not supported by the CMS, a missing required parameter, an invalid value in a parameter, or an invalid combination of parameters.

9.1 General Error Detection and Reaction

1. Resiliency. The occurrence of an error in the data or transaction passed through the Interface should not cause the abnormal termination of the application.

2. Identification of Errors. An application detecting an error in a transaction must be able to inform the originating application of the precise nature of the error in a manner affording a programmatic reaction. This is to say that the specification for each transaction should have predefined error codes.

10. Security and Audit

Logging for purposes of audit is a function of the EFM or CMS application(s), and is not germane to the CMS Interface.

Security for the purposes of the Interface is addressed in 2.2 Authentication (page 14).

Security and audit capabilities beyond the scope of the Interface is the domain of the LegalXML Signatures workgroup (http://www.legalxml.org/signatures/).

[DISCUSSION: In Tucson, the CMS Interface Workgroup debated the need for and nature of security and audit capabilities for the Interface, with one school arguing that the measures inherent in 2.2 Authentication (page 14) were sufficient for the purposes of the Interface, and another suggesting that more was advisable, if not necessary. Assumption 1 (Audit, page 8) asserts that the EFM and CMS applications maintain logs of their calls to the Interface, and that the interface itself does not need to contend with that function. Also discussed was the need for a function that would compare logs from either application, but it was also argued that this was outside the scope of the Interface and introduced complexity in violation of Requirement 1 (Simplicity, page 9). An appendix discussing Security/Audit considerations was in earlier versions of this document, but it was removed in San Francisco in favor of a link to the LegalXML Signatures Workgroup for a more thorough treatment.]

11. Supported Transport Technologies

As used here, transport technology refers to RPC, SOAP, sockets, or other protocols for program-to-program communication (see definitions on page 8).

[DISCUSSION: In Tucson, the CMS Interface Workgroup agreed to defer discussion concerning selection of transport technology(s) for EFM-CMS communication until after requirements are vetted.]

Preliminary requirements regarding transport technology include:

1. Transparency. The Interface should be designed independently from any particular transport protocol.

2. CMS Accommodation. The transport layer(s) must reasonably accommodate legacy CMS applications.

[DISCUSSION: There is a potential trade-off here between the ability to accommodate CMSs and the speed of deployment of electronic filing. Ideally, the transport would be transparent to the Interface, and any viable possibility could be selected or negotiated by a CMS and EFM provider for a given court. A wide choice of options may, however, run counter to Requirement 1 (Simplicity, page 9) in that it could potentially require a broader range of expertise for the respective developers, and consequently slow deployment.]

Appendix

A1. Example EFM Architecture

The architecture, proposed by Rich Himes, is an example of an EFM application design. It is presented as illustrative background material.

Architecturally, this is a methodology for processing XML documents in the Legal XML Court Filing standard format. Its intended purpose is to describe those processes that will be generic across different court implementations, while providing adapters for local customization. Whereas the Legal XML Court Filing standard describes the format and content of the data, this architecture describes the process of receiving an electronic filing or query and coordinating with court-specific adapters. For example, there will be wide variation in the handling of electronic filings by court case management systems, but a court adapter can be used to present a standard interface.

In this figure, EFP represents the electronic filing providers [Note: the term "EFSP" rather than “EFP” is used in this document]. These are vendors and agencies outside the court that are capable of delivering Legal XML compliant court filings (some courts may also use this interface for internal filings). EFM is the electronic filing manager. CPM is the court policy manager that is used to perform a certain level of validation on filings for compliance with local court rules (note that there is a separate workgroup dedicated to defining this interface). CXA is the court XML adapter, which defines the interface for court-specific handling of filings and other requests [Note: it is the CXA's interface to the CMS that this Requirements document addresses]. The CMS and DMS are the court’s local case and document management systems.

A2. The EFSP-EFM-CMS Environment

This depiction of the electronic court filing environment is extracted from the California Electronic Filing Technical Standards produced by the California AOC (see reference CEFTS in Dependencies on page 7 for a link).

The California electronic filing technical standards effort adopts a conceptual model as depicted in Figure 1 below.

Legal XML Court Filing CMS XML API Internet Filers EFSP EFM CMS

Attorneys Electronic Filing Electronic Filing Case Practitioners Service Provider Manager Management Pro Pers (Organization) (Application) System (Application)

FIGURE 1

This model defines four primary elements of a future environment for statewide (and perhaps nationwide) electronic filing.

Figure 2 depicts an instance of the conceptual model for 2 courts and 2 EFSPs.

 Filers can be attorneys, individuals, corporations, or anyone who is a party to a case (or representing a party). Law firms and those with some variety of computerized management system will want to receive information about their filings from courts in XML.

 EFSPs have customers to whom they provide support and probably applications, from whom they collect court fees, and on behalf of whom they forward fees and filings to courts. They also obtain (query/response) and provide information about the cases that their customers want to see.

EFSP Court CMS Data Public Atty Policy Access A Config XML XML

Filer / Law EFSP Legal XML Firm Envelope EFM CMS 1

Law XML Firm Internet EFM-CMS Interface CMS

Pro Per Filer / EFM CMS 2 EFSP

Court Court Atty EFSP URL Policy Public Access B Directory XML

FIGURE 2

 Courts accept filings from any EFSP (with which they have agreements) through a single application (the EFM) that is interfaced to their CMS. Courts could conceivably act as EFSPs, but they should implement using the same model.

 Legal XML Envelope is the Legal XML Court Filing Standard, Version 1.0; all traffic to the court's EFM is packaged using this XML Standard. The Standard is available at http://www.legalxml.org/DocumentRepository/ProposedStandards/Clear/PS_10001/PS_1 0001_2000_07_24.htm.

 Court Policy XML tells the EFM and EFSPs the policies and requirements of a court with respect to how they might vary from the Court Filing Standard DTD.

 CMS Data Configuration (CDC) XML gives the EFM and EFSPs detailed information about the filing transactions, data, data formats, and queries/responses the CMS can support. (In the example, only CMS 1 is shown with CDC XML; presumably CMS 2 uses a less capable but more expensive custom interface.).

 Public Access is shown here as a matter of clarification. It is not a component of electronic filing, and is not to be confused with the flow of data back to filers. It provides general-purpose, non-privileged information for those who are not parties to cases.

 Criminal Cases are, of course, supported by the system: defense attorneys subscribe to EFSPs; District Attorneys or Public Defenders can use EFSPs, or their case management systems could presumably talk directly to a court’s EFM.

06/04/2001 Version 6 30