LegalXML Member Section
Electronic Court Filing Technical Committee
Face-to-Face Meeting
February 24, 2005
Meeting Minutes
Greeting by Dan Becker, Utah StateCourt Administrator
Introductions
Review of rules of operation
Present:
Robin Gibson
Dallas Powell
Tom Carlson
John Greacen
Bob March
James Cusik
Rex McElrath
Richard Baker
Shane Durham
Eric Tingom
Committee review of comments on requirements led by Shane Durham
This document is geared towards the business. The specs will be focused on the components. At this point for functional requirements we will focus on the ‘black box’ system rather than the components.
Where does the need for user authentication need to be brought in? We need to come to an agreement as to where things get put in. Things like authentication belong in the system the question is where.
Make clear that our requirements are for a national standard and some specific local needs will need to be extended to accommodate local needs such as Utah digital signature laws.
Discussion on authentication:
Need for authentication in processes that are not electronically continuous may have a requirement that the document/submission and submitter were authenticated and may need to pass the fact of authentication along with the filing (sneaker net).
We will include the concept of sneaker net as a profile in the non-functional requirements.
Authentication profiles agreed to-Login userid/password and digital signature
Details of the authentication needs to be added to technical requirements to the specification
We will add a summary use case to show how all the other use cases are connected.
Discussion of Docketing:
As a separate process in the clerk review/case management commitment sequence
This needs to be articulated at a finer level of detail
Discussion of Filer assembles and submits filing to court:
User identification is not part of the messaging profile, but the action is part of the profile
Suggest a transmit use case to analyze this issue.
Lead document: should we continue to require that the envelope accommodate multiple lead documents as long as they go to the same case in the same court?Yes.
The definition of lead document came into question what does it mean? It is not limited to papers asking the court to take action. The term actually exists only to differentiate between documents that are docketed and those that are submitted as attachments to documents that are docketed.
Multi-case filings should be added to scope
Does court filing blue support transmission to the elected clerk of court such as liens, deeds, etc., that are not court-related such as when the clerk of court is also a county clerk so that they do not have to have a separate system to accept filings?
The best we can hope for is to create a generic filing process that encompasses court filing and we can include more detail in version 2 of court filing blue.
We edited the Transmit Use Case
Primary use case is the most likely flow, extensions are alternate flows.
Our scope needs to include the filing of draft documents such as proposed orders. Extend in 2.4.
Remove 2.5 Payment processing and replace with payment information which deals with the method of payment and at least the amount of payment applicable and a maximum limit and the purpose of the payment.
Fee information will be represented as a query from the case management system and may have an extension in the functional requirements.
Completion of filing: a series of events that begins with the clerk accepting the filing, the commitment of the data into the case management system, and a filing completed receipt back to the filer of completion of the filing, as opposed to the receipt of the filing document.
It looks like we need to determine our filing states and the processing related to them in our model.
Filing states discussed including: rejected, received, and processed,and documents are accepted or rejected within a multiple document submission.
We will need to reconsider if a filing must have a document with it in the review of these requirements. The determination was that a filing may contain only data and no document.
Does the notification of filing need to contain information out of the case management system? Yes. It should be optional to return the filed documents, but at least the hash of the document should be included. Include request to seal with the documentation.
Attendance on conference call in addition to face-to-face:
Roger Winters
Don Bergeron
Mark Oldenberg
Jeff Barlow
Christopher Smith
Roger De Philips
Jim Beard
Allen Jensen
Review of day’s discussion led by John Greacen on the call.
Well begin tomorrow with the query response DTD queries.
Sneaker net—a method to deliver fully electronic information to the court when all forms of direct electronic communication are unavailable. The sneaker net could include submission of electronic filings on a CD or other medium. Sneaker net may also be used for large filings that are not reasonable for Internet transmission.
Process for authenticating the filer using user id and digital signatures and recognize that some applications require no authentication. In the future when electronic notarization can be done, it may be incorporated.
Many elected clerks perform county clerk functions for other governmental activities, such as real property, etc., and the document filing mechanism should ultimately support these function as well as the court clerk’s functions. We will include a general use case for transmitting a document that will appear before the submission of a court filing and will note that this will receive further definition in later versions.
Developed a transmit use case that states that every transmission includes an acknowledgement of the transmission.
Focused on method of payment, and agreed the actual payment process itself will not be supported in blue, or all possible payment mechanisms. The first level of information will be the method of payment of the applicable fees. I paid by ach, credit card, debit account, etc. The filing itself will include the method by which the payment will be made and the purpose of the payment including the number of a trust account. The payment may include a maximum amount for the payment if some latitude is needed to accomplish the filing. The filing application will query the court CMS system for the fees applicable to the filing in question, the fees will be displayed to the filer for payment, but no further processing will be supported.In particular, efiling systems will not include the capability of computing filing fees. If the court does not include the capability of providing the fees, the filer will have to rely on the published court fees schedule to determine the fees that need to accompany the filing.
We should support filings that do not include documents—e.g., the payment of a criminal fine—and we want to encourage the courts and lawyers to use the full capabilities of XML “documents” without the creation of artificial filing cover sheets,using XML instances instead. This resulted in the discussion on the messages being returned to the filer on the status of a filing and the documents in the filing. There will be only 2 messages about the status of the filing submission itself, we received it, and a final message after the clerk has reviewed the filing and committed information to the case management system database. That message can be “processed’ with a report on the acceptance or rejection of documents in a multiple document submission. Codes and comments associated with rejections can be included. And document statuses of accepted or rejected will be included.
We will not have a message that transmits the action of the clerk review, but we will wait until the information is committed to the case management system. However, one of the queries will support a request for information on the status of the filing. Responses to that query can include interim filing status information. The return of the final status will include the final hash of the document put into the system and may include links or the documents themselves. We will support the request for sealing of documents.
February 25, 2004
Minutes
Jim Cabral
Shane Durham
Eric Tingom
Tom Carlson
Robin Gibson
Dallas Powell
James Cusick
Bob March
John Greacen
Rex McElrath
Richard Baker
Query and Response
Can we specify some levels of query, and the courts don’t have to implement all of it?
How do we define a specific set of queries, and deal with courts that don’t want to use them? How do we require that a vendor’s product is to perform a specific query?
We need to begin with the COSCA/NACM standard to define what the “required” queries are. Eric will take this as a task.
Our XML syntax should support ad hoc queries.
We compared a list of the queries identified in QnR Proposed Standard, Nov 22, 2002 to the list in the story boards for the requirements.
The use of this spec assumes certain capabilities in the court’s case management system in order for these specifications to operate as defined.
Parking lot: how to support courts that do not have the capability to generate the register of actions in a form and format usable for these queries specifically that the data is parse-able?
Parking Lot: should there be a list of document separate from the register of actions?
Get case list is a type of search based on party name or attorney, initiation date, case categorization. Let’s make this optional.
Our role in defining these queries that are not essential to court filing applications. We provide a useful function to define communications paths and recognize the issues of public access and privacy and preface this work with that recognition.
Combination of court identifier and case identifier makes a unique identifier.
There should be a document identifier that uniquely identifies the document similarly to case identifier. A get document query returns the binary content of the document object/content.
Get filing: would return document links or ids specifically usable to allow the filer to identify the status of a not-yet completed filing.
Get filing list by case: it is a time critical issue to know what filings have been submitted for this case. The query will need to return a list of the filings on this case. The user will then be able to use get filing using the identifiers returned in the list.
Get component policy: policy files applicable to a specific component such as docketing. Assuming at this point that we are going to have policies.
Get calculated fees
Go to policy next.
Much of the policy discussion pertains to the technical level of this development rather than to the requirements level.
Agreed to discuss policies with respect to processes. What policies must be conformed to?
Case types for which filing is permitted
Court locations
Case categorization uses court identified strata of case typing regarding case category, case sub-category and case type
court categorization includes location details
document types
local schema and extensions must be included in court policy
court accepts one lead or multiple lead documents in a single submission
code sets are desirable in policy
does the court accept the submission of a document as a URL
does the court accept sealed documents and the way in which they accept sealed documents
maximum document size
are efiling service/convenience fees required for filing
external ways of enforcing schema constraints beyond simple schema validation
version controlling mechanisms on schema and code sets
code sets:
party types/categorization
document types
Primary/formal service and secondary service
Secondary service is subsequent service notification of opposing parties by attorneys.
When you do your first filing into a case, you register on the case. When you do the second filing, you can query for the list of parties to be served on filings subsequent to the first
Get case participant must also return the parties on the case for use with service.
Long discussion of the merits of a registry containing more information beyond a contact list resolved into the registry only containing a list of parties to be contacted and the EFSP is responsible for negotiating and executing the secondary service with the party.
The list of the parties to receive secondary service is owned by the court and is retrieved at the time of secondary service.
The address that is given is the address of the EFSP, but we will require the EFSP to communicate and update the court on the ultimate communication address.
Discussed when the secondary service is started.The intent of rules is to notify parties of the submission to the court, not to notify them of admission of the filing into the court record, so anytime up to the completion of submission would be acceptable.
Secondary service notice will be submitted after the receipt of delivery to the court is issued.
Nest steps in the process
Two week comment period April 11-28 people will have to file formal comments or objections and a posted conference call will address those comments and objections and the Kavi based votes will be +- on the whole and on controversial items.
Conference Call attendees:
Don Bergeron
Nick Pope
Jeff Barlow
Mark Oldenberg
Christopher Smith
Allen Jensen
Jim Beard
Robert O’Brien
Shogun Naidoo
Tom Clark
Roger Winters
Went through queries policy, service, non-functional requirements, and next steps.
Queries: went over the ones we had in the old DTD and spec on query and response. Talked about them and recognized there is an enormous ferment about electronic access to court information and concluded there are some queries that are directly supporting efiling functions and those will be required features, but most will be optional articulating how to implement public access to various parts of the court record. In addition to queries we will articulate, an individual court can define ad hoc local queries. The ones we agreed on began with getcaselist, getcase, 2 parking lot items support separate query for documents for a non integrated dms/cms and couldn’t get the docs from the register of actions, how to support courts that cannot produce a parse-able register of actions. Getdocument, two different get document systems, the first getting document filed and the second is getting the document committed to the court record. Getfilingstatus returns only the status from the getfiling query. Getfilinglist identifies a case or name and returns all of the filings for today in that case or that you submitted today to the court. Getcalculatedfee –the filing assembler will not calculate filing fees and this query will transmit this filing to the court and return the calculation of the filing fees from the case management system and thus there will be only one authoritative way to calculate fees.
On court policy we identified three levels: human consumable information not presented in machine-readable form. Human consumable is outside of the scope of blue. The other two will be included in the spec. the different types of development time parameters, one-time used pieces of information used by the system developer. Includes special court rules such as accept a URL in lieu of a document, maximum document size, efiling fees, multiple lead documents in the same filing, document formats acceptable, subset schema and version controls acceptable to the court in WSDLstyle presentation. Runtime parameters are the codelists the court will be modifying periodically and will be queried on a real-time basis by the filer or EFSP. These include case categorizations that are permitted, these will be presented in text and codes for filing information. And court categorization, including name, location, branches, text and code. Document types and party types are other code tables.
Service: a service provider is a generic term to include the court, first obtains a list from the court of the parties in the case and which are served electronically and their electronic address. The list is obtained by case at the time of service so it is up to date. Primary service establishes jurisdiction by the court—summons, warrant, and subpoena. Secondary service is what we are talking about, and primary service is out of scope for blue. Service effected by the service provider and will return service to the address and by the method by which original appearance was made. How the EFSP ultimately communicates with the party is between the party and the EFSP. The court will require the EFSP to keep the court current on the information used to communicate service to the party/client. Service will be done following the receipt by the EFSP of the acknowledgement of the filing’sreceipt. Service will be providing notice of the filing and will not have to convey the document itself. The EFSP will return to the filer a list of the persons who must be served by snail mail.