Court Registry Component

Summary

The Registry is a REQUIRED logical component within the system which is equivalent/analogous to the Filing Review MDE from the ECF specification; which enables a court to receive and review a filing message and prepare the contents for recording in its case management and document management systems, sending a response concerning the filing to the Filer (Filing Assembly MDE). It also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing.

This component is responsible for interacting with:

  • The Filer in its process of submitting case files for review and filing with the Court.
  • The Court to subnit case files and documents.

Court Webhook

This component MUST implement a Webhook endpoint in order to receive asynchronous events from the Court. This endpoint is equivalent/analogous to the NotifyDocketingComplete operation provided by the Filing Review MDE from the ECF specification. The payloads posted to the endpoint provide similar information to that of the RecordDocketingCallbackMessage parameter of the NotifyDocketingComplete operation.

This endpoint must be able to accept the following event payloads:

  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

Registry Webhook

This componet interacts with the Filer component asynchronously through Webhooks. It expects the Filer to implement an endpoint that will receive the following event payloads:

  • Payment Accepted/Rejected - A message indicating the payment for the filing was either accepted, or rejected and why
  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

If the clerk rejects the filings or the Registry receives an event from the Court, the Registry MUST post an event to the Filer's Webhook endpoint as an asynchronous response indicating whether the filing was accepted and filed with the court record system. From the ECF specification, and left here for discussion... The operation MAY return the filed documents or links to the documents, but MUST include the [FIPS 180-2] SHA 256 document hash, a condensed representation of a document intended to protect document integrity.

If the filing included a payment, and the filing was accepted by the clerk and court record system, a receipt for the payment MUST be included in the operation.

Implementation

Along with the required Webhook(s) the Registry MUST implement the following.

Generates Messages:

  • Court Policy Response Message
  • Record Docketing Message
  • Filing Event Messages

Performs Activities:

  • Submits filings to the Court; /Court/Record - Post
  • Notifies the Filer of filing related events through the Registry Webhook

Implement Functionality For:

  • /Registry/Policy - Get
  • /Registry/Filing - Post

Summary

The Registry is a REQUIRED logical component within the system which is equivalent/analogous to the Filing Review MDE from the ECF specification; which enables a court to receive and review a filing message and prepare the contents for recording in its case management and document management systems, sending a response concerning the filing to the Filer (Filing Assembly MDE). It also enables filers to obtain court-specific policies regarding electronic filing and to check on the status of a filing.

This component is responsible for interacting with:

  • The Filer in its process of submitting case files for review and filing with the Court.
  • The Court to subnit case files and documents.

Court Webhook

This component MUST implement a Webhook endpoint in order to receive asynchronous events from the Court. This endpoint is equivalent/analogous to the NotifyDocketingComplete operation provided by the Filing Review MDE from the ECF specification. The payloads posted to the endpoint provide similar information to that of the RecordDocketingCallbackMessage parameter of the NotifyDocketingComplete operation.

This endpoint must be able to accept the following event payloads:

  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

Registry Webhook

This componet interacts with the Filer component asynchronously through Webhooks. It expects the Filer to implement an endpoint that will receive the following event payloads:

  • Payment Accepted/Rejected - A message indicating the payment for the filing was either accepted, or rejected and why
  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

If the clerk rejects the filings or the Registry receives an event from the Court, the Registry MUST post an event to the Filer's Webhook endpoint as an asynchronous response indicating whether the filing was accepted and filed with the court record system. From the ECF specification, and left here for discussion... The operation MAY return the filed documents or links to the documents, but MUST include the [FIPS 180-2] SHA 256 document hash, a condensed representation of a document intended to protect document integrity.

If the filing included a payment, and the filing was accepted by the clerk and court record system, a receipt for the payment MUST be included in the operation.

Implementation

Along with the required Webhook(s) the Registry MUST implement the following.

Generates Messages:

  • Court Policy Response Message
  • Record Docketing Message
  • Filing Event Messages

Performs Activities:

  • Submits filings to the Court; /Court/Record - Post
  • Notifies the Filer of filing related events through the Registry Webhook

Implement Functionality For:

  • /Registry/Policy - Get
  • /Registry/Filing - Post

The Filer MAY obtain a court’s machine-readable court policy at any time. The Registry returns the machine-readable court policy in a synchronous response. The content of the machine readable court policy is simular to that described in Section 2.4.2 of the ECF specification. This step may be omitted if the Filer already has the current court policy.

A specific case file.

Court Record Component

The Court is a REQUIRED logical component within the system which is equivalent/analogous to the Court Record MDE from the ECF specification, which; Enables a court to record electronic documents and court list entries in its case management and document management systems and returns the results to the Registry. The Court also enables a Filer to obtain service information for all parties in a case, to obtain information about cases maintained in the court’s court list, register of actions and calendars, and to access documents maintained in the court’s electronic records.

Court Record Webhook

This componet interacts with the Registry component asynchronously through Webhooks. It expects the Registry to implement an endpoint that will receive the following event payloads:

  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

The Court MUST post an event to the Registry 's Webhook endpoint as an asynchronous response indicating whether the filing was accepted or rejected by the court record system. If the Court rejected the filing, an explanation MUST be provided. If the Court accepts the filing, the case file information (e.g. date and time the document was entered into the court record, judge assigned, document identifiers and next court event scheduled) MUST be provided.

Implementation

The Court MUST implement the following.

Generates Messages:

  • Filing event messages

Performs Activities:

  • Notifies the Registry of filing related events through the Court Record Webhook

Implement Functionality For:

  • /Court/Record - Post

The Court is a REQUIRED logical component within the system which is equivalent/analogous to the Court Record MDE from the ECF specification, which; Enables a court to record electronic documents and court list entries in its case management and document management systems and returns the results to the Registry. The Court also enables a Filer to obtain service information for all parties in a case, to obtain information about cases maintained in the court’s court list, register of actions and calendars, and to access documents maintained in the court’s electronic records.

Court Record Webhook

This componet interacts with the Registry component asynchronously through Webhooks. It expects the Registry to implement an endpoint that will receive the following event payloads:

  • Filing Accepted/Rejected - A message indicating the filing was either accepted and registered with the court, or rejected and why.

The Court MUST post an event to the Registry 's Webhook endpoint as an asynchronous response indicating whether the filing was accepted or rejected by the court record system. If the Court rejected the filing, an explanation MUST be provided. If the Court accepts the filing, the case file information (e.g. date and time the document was entered into the court record, judge assigned, document identifiers and next court event scheduled) MUST be provided.

Implementation

The Court MUST implement the following.

Generates Messages:

  • Filing event messages

Performs Activities:

  • Notifies the Registry of filing related events through the Court Record Webhook

Implement Functionality For:

  • /Court/Record - Post

Documents within a specific case file.

get

Not implemented. Reserved for future implementation. The content and response body schemas and examples are provided for informational purposes only.

The Filer MAY obtain the Court’s service information for all parties in an existing case at any time using the appropriate case number on the Court. The service list returned assists the filer in maintaining the filer’s service list and is not a substitute for the filer’s service list. To provide this information, the Court MUST have access to the court’s registry with all updated information about case participants. There MUST be only one such registry per court, though multiple courts MAY share the same registry. The Court responds synchronously to the Filer with a service list reflecting the most current contact information available to the court, which is necessary to complete secondary service, whether electronically or by other means.

If the court provides a Hub Service, the electronic service information returned from this query MUST include the court’s Service ID for all case participants who have one.

A party to a case is always the official target of service. In practice, the system will actually deliver to pro se litigants and to attorneys as intermediaries.

The duty to complete secondary service is upon the filer, and not the court, except when the court is the filer.

The query returns a service list current as of the transaction. No assumption can be made that the data returned by the operation will remain current for use at any future point in time.

This method is equivalent/analogous to the GetServiceInformation operation in the ECF standards.

Legal Service Component

Not implemented. Reserved for future implementation. The content and response body schemas and examples are provided for informational purposes only.

Enables a party to receive service electronically FROM other parties in the case. Note that service TO other parties in the case is performed by the Filer.

Not implemented. Reserved for future implementation. The content and response body schemas and examples are provided for informational purposes only.

Enables a party to receive service electronically FROM other parties in the case. Note that service TO other parties in the case is performed by the Filer.