I agree with Gary. To add to the challenges with these issues, for us the security continues to increase in complexity with the retrieval of a case history or documents. These more complex issues manifest themselves
more in Criminal, Family, Domestic Violence, Probate, and Juvenile efiling systems being used. For example, we have some courts that allow a filer to know of the existence of a case but no case title, no data, just enough so that they can efile to it. However
there are times when the case is public but the events are sealed or confidential entries. In these cases we have to actually submit who is requesting the information to determine the data that can be returned. Some courts allow the requesters to see that
there are items in the case history but the text for the entries are blocked in the event that there is sensitive data embedded (exparte, in camera, children data,…). Some courts simply block the existence of such an entry. Some courts want us to actually
pass and test the requester to determine if they are a participant on the case which changes the data that is returned. Our assumption with ECF is to handle the minimum public requirement.
Dallas
From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org]
On Behalf Of Graham, Gary
Sent: Tuesday, June 16, 2015 3:31 PM
To: James E Cabral; Jim McMillan; Bryant Austin; legalxml-courtfiling@lists.oasis-open.org
Subject: [LIKELY_SPAM]RE: [legalxml-courtfiling] RE: ECF 4.0 GetDocument specification/implementation
We do it differently in Arizona with our e-filing vendors.
Dallas Powell is correct that different CMS systems have different relationships/cardinalities with documents. However he failed to also mention that some Case Management Systems allow multiple lead documents
per docket entry as well as multiple connected documents.
Furthermore, a single document (either lead or connected) may exist in multiple renditions (e.g. pdf, and docx, etc.).
In Arizona, we do not require the documents and document renditions to be combined when returning the GetDocumentResponse. The document renditions are returned individually.
Bryant Austin is quite correct that a Document ID is something not quite the same as a Docket ID. This distinction was not very apparent a few years ago when all filings came in the form of paper. Now in the
electronic document world, most modern Case Management Systems make a distinction between an event and a document.
Although I believe a CaseDocketID maps to an Event ID, we are forced to use it as though it were a Document Rendition ID.
This lack of clarity/distinction is especially challenging in the GetCaseRequest. GetCaseRequest contains an IncludeDocketEntryIndicator but no IncludeDocumentIndicator. Although the IncludeDocketEntryIndicator
should be used to request the case events (e.g. register of actions, proceedings, etc.) we are forced to use it to request a listing of case documents. It would be useful to have indicators for each (i.e. events and documents) individually.
We do not return document content for restricted documents or restricted cases in Arizona.
So in Arizona, for a GetCaseRequest where the IncludeDocketEntryIndicator is true (understood as a request for document information and not event information) we return the Document Rendition ID values in the
DocumentIdentification element within ecf:DocumentRendition within ecf:CourtEventDocument as shown in the XML fragment below:
<ecf:CourtEventDocument
s:id="Document1">
<nc:DocumentStatus>
<nc:StatusText>Filed</nc:StatusText>
<nc:StatusDate>
<nc:DateTime>2012-08-24T02:34:22-07:00</nc:DateTime>
</nc:StatusDate>
</nc:DocumentStatus>
<nc:DocumentTitleText>Notice
of Appeal</nc:DocumentTitleText>
<ecf:DocumentMetadata>
<j:RegisterActionDescriptionText/>
<aoc:FilingAttorneyID/>
<aoc:FilingPartyID/>
</ecf:DocumentMetadata>
<ecf:DocumentRendition>
<nc:DocumentIdentification>
<nc:IdentificationID>1745169</nc:IdentificationID>
<nc:IdentificationCategoryText>DocumentDocketID</nc:IdentificationCategoryText>
</nc:DocumentIdentification>
<ecf:DocumentRenditionMetadata>
<ecf:DocumentAttachment/>
</ecf:DocumentRenditionMetadata>
</ecf:DocumentRendition>
</ecf:CourtEventDocument>
</aoc:CaseCourtEvent>
For a GetDocumentRequest, then the ID for the requested document rendition is passed in the nc:CaseDocketID element.
In the GetDoucmentResponse, the identifier for the returned document rendition is in DocumentIdentification as shown in the fragment below:
<ecf:Document
s:id="Document1">
<nc:DocumentApplicationName>application/pdf</nc:DocumentApplicationName>
<nc:DocumentCategoryText>Civil
Cover Sheet</nc:DocumentCategoryText>
<nc:DocumentDescriptionText>Certificate
of Service</nc:DocumentDescriptionText>
<nc:DocumentFiledDate>
<nc:Date>2010-08-06</nc:Date>
</nc:DocumentFiledDate>
<nc:DocumentStatus>
<nc:StatusText>accepted</nc:StatusText>
<nc:StatusDate>
<nc:DateTime>2010-08-06T12:00:00.0-07:00</nc:DateTime>
</nc:StatusDate>
<nc:StatusDescriptionText/>
</nc:DocumentStatus>
<ecf:DocumentMetadata>
<j:RegisterActionDescriptionText/>
<aoc:FilingAttorneyID/>
<aoc:FilingPartyID/>
</ecf:DocumentMetadata>
<ecf:DocumentRendition>
<nc:DocumentFileControlID>C20140006</nc:DocumentFileControlID>
<nc:DocumentIdentification>
<nc:IdentificationID>133551</nc:IdentificationID>
<nc:IdentificationCategoryText>DocumentID</nc:IdentificationCategoryText>
</nc:DocumentIdentification>
<ecf:DocumentRenditionMetadata>
<ecf:DocumentAttachment>
<nc:BinaryDescriptionText>application/pdf</nc:BinaryDescriptionText>
<nc:BinarySizeValue>10000</nc:BinarySizeValue>
<ecf:AttachmentSequenceID>2</ecf:AttachmentSequenceID>
</ecf:DocumentAttachment>
</ecf:DocumentRenditionMetadata>
</ecf:DocumentRendition>
</ecf:Document>
</DocumentResponseMessage>
FYI. I received the following related use case from Dallas Powell:
Perhaps most people know this but there are some CMS systems where you can only have one document per docket entry while other CMS systems allows for one lead document per docket entry and multiple attachments.
There is also a security setting for each level as well. Here is an example: Washoe 2nd District had a situation where the case was public, the docket entry was public, the lead document (a complaint) was public, but the attachments were sealed
because they were pictures of a women in a compromising situation and the court was not willing to expose information that is considered lewd or pornographic in nature. When you retrieve a document from a docket entry and there are multiple documents if
there is only one ID then the system must first combine the documents into a single document before it can return the information. Sometimes courts split the documents up just due to size and not security as well.
__
Jim Cabral
502 509-4532
Shouldn’t we be using NIEM Core “DocumentIdentification” ?
http://apps.ncsc.org/niem/ShowElement.aspx?element=nc:DocumentIdentification
I agree with Brian that there in nearly all instances a document identification number being sent from a filer’s / EFSP system and in turn placed in the court’s document repository (even if it is linked documents
in a CMS)
Jim M
I am hesitant to add more questions, but as I have been working through implementation of ECF 4.01 I have found the following and am not sure of the real intent. The beginning definition of the GetDocument message in the
ecf-4.01-spec states a case number and a document number, but the xsd files show a nc:CaseTrackingID and a nc:CaseDocketID (pertinent parts of the definitions are below for reference). The niem definition seems to have a definite difference between
a docket and a document. I don’t understand how a document can be located with just the case tracking ID and the docket ID without a document number. There can be many documents associated with a case and each document should have its own identifying number.
Thanks!
The ecf-4.01-spec document states the following, “3.2.13 GetDocument
The Filing Assembly MDE MAY invoke the GetDocument query operation, including the case number and document number, on the Court Record MDE to retrieve a particular document from a case.
The Court Record MDE will respond synchronously with the requested document or instructions on how to access it.”
The ECF-4.0-DocumentQueryMessage.xsd has the following:
“ <xsd:complexType name="DocumentQueryMessageType">
<xsd:annotation>
<xsd:documentation>A request for an electronic document in the court's official record. </xsd:documentation>
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="ecf:QueryMessageType">
<xsd:sequence>
<xsd:element ref="nc:CaseTrackingID"/>
<xsd:element ref="nc:CaseDocketID"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>”
The niem-core.xsd has the following, “
<xsd:element name="CaseDocketID" type="niem-xsd:string" nillable="true">
<xsd:annotation>
<xsd:documentation>An identifier used to reference a case docket.</xsd:documentation>”