[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Record Docketing and Callbacks
|
I think we go out of scope if we look to report what the "Court Records System" does with documents once they have been e-filed and served. It seems to me that the e-filed document is uniquely identified when submitted - by the case into which filed, the document title, the filename (e.g., ORDER.PDF), and other metadata it has when submitted for review (and processing). The key data the e-filer and others need at that point are 1) filing identification information (link to document plus metadata), 2) date/time received and/or officially filed (which can be different dates/times), and 3) any error messages.
Once the clerk gets a document that has been e-filed (it's in the door, in the clerk's custody now), the clerk will do things with the filing, may date/time stamp it, may assign it a sequence number within the case file, may enter it on an index of "today's filings," etc. This adds index information and metadata that might be needed to locate the e-filed item in the "Court Records System." However, there is no reason the data added from putting a filing into the Court Records System should be reported back. Come to the court or the clerk's office when you want to examine the record as it is within that Court Records System - learn then what index entries were given to the document, e.g., unique identification codes, sequence number assigned in the file folder, name of the clerk who processed it, date/time of the money receipt issued, etc. - access that information when it's needed. (Put another way, you only need to get back the same information the bicycle messenger would have brought you if you had filed a paper - except for the e-service information, which is handled a little differently. The messenger isn't hanging around until the document is fully processed into the "Court Records System" so information about that can be brought back to the filer's office.)
I hope this is helpful.
Roger
Roger Winters King County Continuing Legal Education (CLE) Coordinator and Programs and Projects Manager 516 Third Avenue, E-609 MS: KCC-JA-0609 Seattle, Washington 98104 V: (206) 296-7838 F: (206) 296-0906 roger.winters@metrokc.gov
From: Cabral, James E.
[mailto:JCabral@mtgmc.com]
Everyone,
Tom Clarke and Scott Came are currently working on defining the domain models and GJXDM mappings for the Record Docketing and callbacks. In the attached email discussion of the content of each message, I identified two questions for the TC. I referenced the second issue in the "Proposed Service Model for ECF 3.0" document because it relates to the service model . But the first issue is a possible simplification of all the callbacks that I do not recall we have decided as a TC.
Again, please direct your comments to the entire TC so that we may resolve these issues as soon as possible.
thanks, Jim Cabral James
E. Cabral Jr. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
From: Cabral,
James E. Scott,
Here's what I recall, in sequential order:
1. The ReviewFiling synchronous callback includes - the time the filing was received by the Filing Review MDE - the court-assigned case number - any error messages
2. The RecordDocketing includes - all the metadata and attached documents in the ReviewFiling message that is accepted by the clerk, as edited by the clerk - the court-assigned case number - the payment receipt
3. The RecordDocketing synchronous callback includes - the time it was received by the Court Record System - any error messages
4. The RecordDocketing asynchronous callback includes - all the metadata and attached documents in the RecordDocketing message, as modified by the Court Record System - the document identifiers for each document filed into the Court Record System - any error messages
5. The ReviewFiling asynchronous callback includes - all the metadata and attached documents in the RecordDocketing message, as edited by the Court Record System - the court-assigned case number - the disposition (accepted/rejected) of each document in the original ReviewFiling message - the document identifiers for each document filed into the Court Record System - the payment receipt (if the court processes payments) - a place for error codes
I am unclear on a couple things:
1. One simplification would be to remove the metadata and documents from the callbacks. In that case, it seems to me that we would still need to include a way to indicate to the filer what information the clerk or Court Record System changed. Or should we just say that it their responsibility to download the documents and check them for changes?
2. Another question I have is how this all relates to service. Since the service recipients receive the filing concurrently with the court, do they need to also receive notification of the changes the clerk or Court Record System make? And should the service recipients receive the document identifiers for each document? Currently, we do not have a mechanism designed to support that.
That's all I can remember. I probably missed some but it should be a good start for your strawman.
jim
From: Scott
Came [mailto:scott@justiceintegration.com] Jim, do you have an understanding of existing
consensus regarding what should go into the callbacks and Record Docketing
message structure? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]