Learning Center
Plans & pricing Sign in
Sign Out

Steps to Electronic Filing with Electronic Court Filing


									 7 Steps to Electronic Filing with
 Electronic Court Filing 4.0

The 7 Steps found within this Quick Start Guide will assist you with
the minimum requirements to implement e-Filing with the OASIS
Electronic Court Filing 4.0 Specification.



          Standardize integration methods in your e-Filing implementation with XML
          Integrate with any potential e-Filing Service Provider or share e-Filing data between
           systems or with partners
          Setup a single method of processing data related to e-Filing
          Find out how to implement legal service in your e-Filing application


             OASIS LegalXML Court Filing Technical Committee
             In conjunction with the release of the Electronic Court Filing 4.0 Specification
INTRODUCTION                                                 STEP 1. IDENTIFY E-FILING SERVICE PROVIDER(S)

In the software industry today, and especially in            For those who are unfamiliar with the ECF specification, there is
the global justice space, there continues to be a            common misunderstanding that the specification itself is a
strong movement toward the standardization of                complete e-Filing solution. This is not the case. Rather, ECF is
data definition and exchange methods, and it is              the solution that allows those systems or entities participating
often the desire of administrators and                       in the e-Filing process to communicate and exchange data with
technologists throughout federal, state, local,              one another. The primary system utilized to prepare and submit
and tribal governments to apply those                        court filings electronically is known as an Electronic Filing
standards. In reality, however, it is often                  Service Provider or EFSP. Your first step to implementing the
overwhelming to review and fully comprehend                  ECF specification will be to identify at least one EFSP. That’s
the documentation accompanying those                         correct, at LEAST one EFSP is required, but the ECF specification
standards. This document attempts to minimize                allows for multiple EFSPs if desired.
that factor for the OASIS Electronic Court Filing
                                                             Electronic Filing Service Providers are available to e-Filing
(ECF) specification, and allows the reader to
                                                             implementers in various forms and fashions, including but not
completely understand what is required to
                                                             limited to the following:
implement the         specification in their
                                                                   E-Filing Vendor – several commercial e-Filing systems are
While the ECF specification covers a wide range
                                                                    available in the market place, of which one or more could
of use cases and possible data exchange
                                                                    be selected for use in your e-Filing implementation.
transactions, only a small sub-set of those
transactions are required in order to implement                    In House – many courts have developed their own e-
the specification. In fact, in 7 easy steps we can                  Filing systems that include an EFSP.
break down the tasks necessary for a fully
                                                                   System Customization – as an example, document
compliant ECF implementation.
                                                                    generation software could be customized to allow the
                                                                    user to automatically generate and submit documents for
The steps for implementing ECF are:

1.   Identify e-Filing Service Provider(s)
                                                             Alright, so perhaps Step 1 is not necessarily “easy”, but if you
2.   Identify an e-Filing Manager
3.   Choose to implement ECF 4.0
                                                             are thinking about implementing e-Filing or the ECF
4.   Develop your Court Policy                               specification, odds are that you have either already identified an
5.   Understand MDE’s, Operations, and Messages              EFSP or have given thought to one of the above options.
6.   Choose a Service Interaction Profile
7.   Develop and Implement                                   One of the enormous benefits of utilizing the ECF specification is
                                                             that it does not restrict you to a specific EFSP. Any or all of these
                                                             EFSPs could be implemented. In fact, utilizing the ECF
That’s it!? But wait a minute, the first two steps           specification leaves the implementer’s environment open for
have nothing to do with ECF, do they? In fact,               additional EFSP integrations, and it could easily be argued that
they do. It turns out implementing ECF does                  this is necessary in most courts. Even in a single vendor e-Filing
have at least two prerequisites for an end-to-               implementation, the court will likely have a need to directly
end implementation. There must be 1) a system                integrate with other government agencies (i.e. Prosecutor’s
that produces the filing, and 2) a system that               offices, public defender offices, law enforcement offices, lower
receives the filing. You will learn more as you              courts, appellate courts, among others) allowing them to
read through the 7 easy steps.                               electronically file documents with the court directly through the
                                                             automated systems of that agency.                                                                PAGE 2
As you will learn in Step 4, in ECF specification            complete an end-to-end e-Filing system. These applications
terms the EFSP will be responsible for acting as             include a Case Management System (CMS) and a Document
the Filing Assembly Major Design Element                     Management System (DMS). As with EFSPs and EFMs these
(MDE) and generating the XML core filing                     applications may exist in a variety of formats, but must be
message, for submission to the court as an                   considered and available to completely process an e-Filing
electronic filing.                                           utilizing the ECF specification.


Now that you have an EFSP, the next step is to               Now that an EFSP and EFM have been identified, there is a high
determine the manner by which the court                      likelihood that you will need to choose a method by which to
would like to consume and manage electronic                  either integrate those applications with one another, or with
filings generated by that EFSP. Applications                 others applications within your e-Filing system. In many cases,
implemented for this purpose are commonly                    multiple components of an e-Filing system exist within the same
referred to as the Electronic Filing Manager or              application and therefore do not require integration with each
EFM, and often vary widely in the level of                   other; however it would be extremely rare for ALL components
functionality they provide.                                  of an end-to-end e-Filing system to exist completely within the
                                                             same application. As a result, there will be a need for the
As with EFSPs, Electronic Filing Managers are                components of these separate applications to communicate
also available to e-Filing implementers in                   with one another to fully process an electronic filing.
various forms and fashions. In addition, your
selection of an EFM may be highly dependent                  To further illustrate this point, consider the following examples
on what EFSP(s) have been identified.                        of possible e-Filing systems:
Commercial vendors typically offer what would
be considered EFM functions within their
software and may or may not require its use                        A vendor provides both your EFSP and EFM, but the Court
should you select that vendor’s system. Or, the                     hosts its own Document Management (DMS) and Case
court’s case management system software may                         Management Systems (CMS).
have built-in EFM capabilities. The court also                     A vendor provides an EFSP, but the Court hosts its own
has the option to custom develop their own                          EFM within its CMS.
EFM software. The beauty of the ECF
specification is that it doesn’t matter which EFM                  A Court developed its own EFSP and EFM separate of the
option you choose, it is designed to work with                      CMS and DMS.
any of them.
                                                             These examples demonstrate the variety of options that are
With      reference     to  ECF     specification
                                                             available when constructing an e-Filing system, and that a
terminology, the EFM will act as the Filing
                                                             complete e-Filing solution will almost always require some
Review MDE and will be responsible for
                                                             integration points. This integration may be the EFSP and EFM
interacting with the Filing Assembly MDE
                                                             exchanging data with one another, or the EFM communicating
provided by the EFSP to communicate the
                                                             with external DMS and CMS applications. If we are assuming
acknowledgement and acceptance of new
                                                             this as fact, then we can also assume that a method for
filings, and to provide updates on the status of
                                                             integration between these applications is vital to the success of
said filings. Specific XML messages have been
                                                             a complete e-Filing implementation.
defined for this purpose.
                                                             This is exactly why the ECF 4.0 specification has come into
It is important to also acknowledge that there is
                                                             existence. The authors of the specification saw this inevitable
an expectation that additional applications will
                                                             truth, and the need to develop an integration method that is
exist in a court’s e-Filing enviroment to
                                                             standardized and repeatable, allowing courts and vendors alike                                                             PAGE 3
to develop applications capable of interacting                  The unique court identifier.
with multiple external application in a singular                The location of the machine-readable court policy.
way for the purpose of e-Filing.                                A definition of what constitutes a “lead document” in the
STEP 4. DEVELOP YOUR COURT POLICY                               A description of how the <filingPartyID> and
                                                                 <filingAttorneyID> are to be maintained during electronic
Perhaps most important step in implementing                      communications regarding the case.
the ECF specification is to define the ECF Court                A description of how the court processes (dockets) matters.
Policy. The court policy is integral to the e-Filing            A description of any instances in which the court will
process as it defines a myriad of requirements                   mandate an element that the ECF 4.0 schema makes
the Filing Assembly MDE must consider. In                        optional.
defining a court policy, the Court must give                    A description of any restrictions to data property values
considerable thought to exactly how                              other than code list restrictions.
comprehensive an e-Filing application it wishes                 Any other rules required for electronic filing in the court.
to implement. Will it include a single or multiple
case type, allow for electronic service, or                  Machine-Readable Court Policy is an ECF 4.0 message that
provide access to other case documents?                      describes the features of the ECF 4.0 implementation supported
Answers to these questions should be defined                 by the implementing court, the court’s code lists, and any other
in the court policy.                                         information a Filing Assembly MDE would need to know in
                                                             order to electronically file successfully into that court. Machine-
Additionally, the Court will need to determine               readable court Policy includes structures for identifying run-
how e-Filed documents will be “signed” and                   time and development-time policy information.
define a document signature profile. The ECF
specification allows for digital signatures and              Run-time information includes information that will be updated
XML signatures, among others, or in the                      from time to time, such as code lists (e.g., acceptable document
absence of more formal signature technologies                types, codes for various criminal charges, and civil causes of
a “null” signature profile. Most courts have                 action) and the court’s public key for digital signatures and
found it perfectly acceptable to implement the               encryption.
null signature profile along with a “/s/ Filer
Name” on the document signature line, as, in                 Development-time information includes court rules governing
combination with the e-Filing process itself, it             electronic filing that are needed at the time an application is
demonstrates the intent to sign and file.                    developed but which are not likely to change. These include:

Further demonstrating the importance of court                   The service interaction profile(s) that the court supports
policy, it will define codes associated with                     (see step 6).
specific courts, or code lists an EFSP might be                 The MDEs, query operations and case types supported by
required to use to associate data it is submitting               the court’s ECF 4.0 system.
within the core filing message. Courts are                      Whether a court will accept the filing of a URL in lieu of the
required to provide their court policy in two                    electronic document itself.
formats; 1) Human-Readable, and 2) Machine-                     Whether the court accepts documents requiring payment of
Readable.                                                        a filing fee.
                                                                Whether the court accepts electronic filing of sealed
Human-Readable Court Policy is a textual                         documents.
document publishing the court’s rules and                       Whether the court accepts multiple (batch) filings.
requirements for electronic filing. To be                       The court-specific extensions to the ECF 4.0 specification,
compliant with the ECF 4.0 specification, each                   including the required elements.
court MUST publish a human-readable court                       The maximum sizes allowed for a single attachment and a
policy that MUST include each of the following:                  complete message stream.                                                               PAGE 4
Thankfully, implementing courts don’t have to                       2.      The Filing Review MDE will generate, the Court Policy Response
stress over how to format their machine                                     Message, the Record Docketing Message, the Review Filing Callback
                                                                            Message, and initiate the Record Filing and Notify Filing Review
readable court policy, as the ECF specification                             Complete operations.
provides the xml structure to be used. Here’s a
short snippet as an example:                                        3.      The Court Record MDE will generate the Record Docketing Callback
                                                                            Message and initiate the Notify Docketing Complete operation.
     <j:CaseCourt>                                                  4.      For each message initiated, the receiving MDE shall generate the
                                                                            Message Receipt Message synchronously.
     <j:CourtName>Essex Superior Court</j:CourtName>                This means that in terms of mapping data to the ECF message
     </j:CaseCourt>                                                 schemas, the majority of the work will occur in these seven
                                                                    messages defined in the purple text. The specification provides
                                                                    detailed schemas for each message, so that task is simply
Self explanatory, right? To those familiar with
                                                                    determining where to insert the data your implementation
XML it should be, and to those who have never
                                                                    requires within the schema. Let’s look at an example and code
seen XML it should seem clear that the court’s
                                                                    snippet from each message.
ID is “ESS-SC” and the court’s name is “Essex
Superior Court”. The rest of the XML defined in                     The CourtPolicyQueryMessage is a simple message generated
the ECF Court Policy Response Message is                            by the Filing Assembly MDE to get the requirements of the
similar.                                                            court it is attempting to file in. The key to this transaction for
                                                                    the court is knowing which Filing Assembly MDE is making the
Court Policy Tip
                                                                    request, therefore the query message defines the requestor.
Write your Human-Readable court policy and completely define        Here’s a snippet:
all the requirements with all the elements described above within
that policy, then work with your technical team members to               <ecf:QuerySubmitter>
translate that policy into the Machine-Readable XML version.             <ecf:EntityPerson> <nc:PersonOtherIdentification>
                                                                         <nc:IdentificationCategoryText>Vendor A</nc:IdentificationCategoryText>
STEP 5. UNDERSTAND MDE’S, OPERATIONS,                                    </ecf:EntityPerson>
AND MESSAGES                                                             </ecf:QuerySubmitter>

Perhaps the hardest step in implementing the                        In this example, the court assigned ID, “1”, is defined as well as
ECF specification is understanding the process                      a textual description, “Vendor A”, so that the court knows who
flow and its components, then correctly                             to respond to with the CourtPolicyResponseMessage. In terms
mapping the data the court finds necessary to                       of mapping this indicates the court will need to assign an ID for
process a filing with the XML schemas provided                      each EFSP, and map that ID to these data elements in preparing
by the ECF specification. Gaining this                              for implementation. Here’s a snippet of the court’s response:
understanding of minimum requirements for
ECF should help tremendously. There are                                  <DevelopmentPolicyParameters>
literally only three MDE’s (in green), seven                             <SupportedCaseType>Civil</SupportedCaseType>
message interactions (in purple), and five                               <EffectiveDate>
operations (in blue) required to implement a                             <nc:Date>2008-08-01</nc:Date>
fully compliant ECF e-Filing solution, and are                           </EffectiveDate>
briefly described here.
1.      The Filing Assembly MDE will generate the Court
        Policy Query Message, Core Filing Message initiate
                                                                    This court policy response indicates that currently the court is
        the Get Policy and Review Filing operation.                 only accepting filings in the Civil case type, where filing fees may
                                                                    be applicable, and effective 8/1/2008. This demonstrates clearly                                                                                         PAGE 5
how the court will map the case types for which              RecordDocketingMessage. This message should define the filing
it will allow e-Filing to occur within the court             in a way that allows the Court Record MDE to fully process it
Policy message.                                              and respond. Here’s a snippet of that definition:

In this case, the Filing Assembly MDE now has                 <ecf:DocumentMetadata>
the knowledge that it may generate a                          <j:RegisterActionDescriptionText>MOT</j:RegisterActionDescriptionText>
CoreFilingMessage for civil filings. In that                  <nc:IdentificationID>562455</nc:IdentificationID>
message, it will define the document(s) to be                 </ecf:FilingAttorneyID></ecf:DocumentMetadata>
filed. Here’s a snippet of the message:

 <FilingLeadDocument s:id="MotionToContinue.doc">
                                                             The snippet here show’s that the document has now been
 <nc:DocumentApplicationName>Microsoft Word                  defined for specific data elements that will be recorded by the
 </nc:DocumentApplicationName>                               Court Record MDE, likely in the CMS and DMS. In this case
 <nc:DocumentDescriptionText>Motion to Continue
 </nc:DocumentDescriptionText>                               “MOT” represents a code within the system for Motion, and the
 <nc:DocumentLanguageCode>eng                                “562455” represents the state bar number of the attorney filing
                                                             the document.

                                                             Once the Court Record MDE completes processing, it will
In this small snippet, we see that the document
                                                             initiate the Notify Docketing Complete operation and send
defined in this filing is a “Motion to Continue”,
                                                             RecordDocketingCallbackMessage to the Filing Review MDE.
it is the lead document, and it can be identified
                                                             This message will contain the following snippet:
by the file name of “MotionToContinue.doc”.
The Filing Review MDE should immediately                      <nc:DateTime>2007-06-06T14:20:46.0Z</nc:DateTime>
respond to the submission of the                              </nc:DocumentPostDate>
CoreFilingMessage             with             a              …
MessageReceiptMessage. The majority of this                   <nc:StatusDescriptionText>Without modification</nc:StatusDescriptionText>
message repeats information provided by the                   <ecf:FilingStatusCode>Docketed</ecf:FilingStatusCode>
submitter, but the important piece will indicate
whether or not the message was received.
Here’s a snippet:                                            In this instance, the Filing Review MDE now becomes aware
                                                             that the document has been fully “Docketed”, “Without
 <message:Error>                                             Modification”, at “14:20:46” on “6/6/2007”. A mapping effort
  <message:ErrorCode>0</message:ErrorCode>                   will need to occur so that data relevant to the court’s CMS is
  <message:ErrorText>No error</message:ErrorText>            positioned correctly within this schema.

                                                             This information can now be relayed full circle by the Filing
In the sample above, a code of “0” was                       Review MDE to the Filing Assembly MDE with the
returned indicating no errors occurred and the               NotifyFilingReviewComplete                         operation
filing was received by the Filing Review MDE.                ReviewFilingCallbackMessage. This message will confirm the
The court will need to define a set of error                 status of the filing for the Filing Assembly MDE and would
codes for use in this message, and descriptions              contain the following snippet:
for each code, then map them to this message.
Once a determination has been made, either by                 <nc:DateTime>2007-06-06T14:20:46.0Z</nc:DateTime>
automation or through manual intervention and                 <ecf:FilingStatus>
review that the filing is good and will be                    <nc:StatusDescriptionText>Without modification</nc:StatusDescriptionText>
accepted, the Filing Review MDE will initiate                 <ecf:FilingStatusCode>Accepted</ecf:FilingStatusCode>
the     Record Filing operation with the                                                                             PAGE 6
With this information the Filing Assembly MDE                using the specifications described in the Web Services
can now update any data in the EFSP and notify               Interoperability (WS-I) Basic Profile 1.1, and WS-I Basic Security
the filer to indicate the document was                       Profile 1.0 To utilize the web services profile, it simply requires
“Accepted” by the court on “8/13/2007”,                      that the appropriate web services be developed and made
“Without Modification”.                                      available for each MDE for the purpose of initiating each of the
                                                             required operations, and submitting messages for consumption.
This brief narration of the events, operations,
and messages should demonstrate that while                   The Media Service Interaction Profile 1.0 specification defines a
the ECF specification may appear complex, in                 transmission system in which the sending MDE stores message
reality the process is simple, and the messages              transmissions on portable media (e.g., a compact disc) which is
are basic in nature. Mapping the data utilized in            then physically transported to the receiving MDE where it is
your systems to the ECF message schemas will                 connected for retrieval of the message transmissions. This
be extremely important, especially when                      specification may be needed in the absence of an active
attempting to avoid confusion between systems                network between the sending and receiving MDEs. While this is
on the meaning of an error code or status                    not the most popular SIP, it is a viable SIP that could accomplish
description.                                                 the tasks involved in completely processing e-Filings. The
                                                             recommendation for this SIP, however, would be that it only be
STEP 6. CHOOSE A SERVICE INTERACTION                         used in emergency situations or perhaps in those situations
PROFILE                                                      where bulk filing may occur.

With an understanding of the overall process                 If neither of these approved SIPs makes sense for your
flow and its components in place, the system is              environment, it is highly recommended that you define and
now in need of a method by with these                        develop your own SIP for implementation, and submit the SIP to
components will communicate and exchange                     the OASIS ECF technical committee for approval as a
messages. The ECF specification defines this                 specification.
method as the Service Interaction Profile or
SIP.                                                         STEP 7. DEVELOP AND IMPLEMENT

An ECF 4.0 SIP defines a transmission system                 Finally, all the pieces are in place to get to work. We’ve
that supports the functional requirements of                 identified our EFSP(s) and EFM, we know we are going to use
electronic filing and the MDE operations and                 the ECF 4.0 specification, we understand the specification and
message structures, and implements certain                   the concept of MDE’s and the specification’s use of operations
non-functional requirements, but does not                    and messages, and we have selected a SIP that will allow the
govern the content of messages. A service                    components to communicate with one another. This should
interaction profile will define how a message                now allow you to set a course to develop and implement your
gets from the sending MDE to the receiving                   e-Filing solution. As always, the development and
MDE in a given messaging framework.                          implementation process will be highly dependent upon the
                                                             choices you have made, but in an overall sense, you will need to
The ECF technical committee has currently                    support the following operations.
defined and accepted two possible SIPs that                  GET POLICY - The Filing Assembly MDE MAY obtain a court’s
may be used in compliance with the ECF                       machine-readable court policy at any time by invoking the
specification. This does not, however, preclude              GetPolicy operation on the Filing Review MDE with the
an implementer from defining and developing                  identifier for the court. The Filing Review MDE returns the
their own SIP for consideration and acceptance               machine-readable court policy in a synchronous response. This
into the specification.                                      step may be omitted if the Filing Assembly MDE already has the
                                                             current court policy.
The Web Services Service Interaction Profile
2.0 specification defines a transmission system                                                               PAGE 7
REVIEW FILING - The Filing Assembly MDE                      included in the operation. The Filing Assembly MDE responds
MUST submit the filing to the court by invoking              synchronously with an acknowledgement of the callback
the ReviewFiling operation on the Filing Review              message.
MDE. The ReviewFiling operation includes
messages for the core filing, for case type-                 LEGAL SERVICE MDE
specific     information,    for  court-specific
information, and for the filing payment. The                 Many would argue that an e-Filing implementation without the
Filing Review MDE responds synchronously with                ability to electronically serve your pleadings as part of the
a receipt message that includes the filing                   electronic filing process is, in essence, an incomplete solution.
identifier issued by the court.                              There is validity to this argument, and it should be considered
                                                             strongly as you plan for your e-Filing implementation. From the
RECORD FILING - If the clerk reviews and                     perspective of the ECF specification, it is important to note, that
accepts the filing, the Filing Review MDE MUST               while implementing legal service is not a requirement of the
invoke the RecordFiling operation on the Court               specification it is sufficiently accounted for within the
Record MDE.         The RecordFiling operation               specification with the Legal Service MDE. In short, the Legal
includes information from the ReviewFiling                   Service MDE allows an implementer to publish a base service
operation with any modifications or comments                 list, which would be typically populated with party and attorney
by the clerk. The Court Record MDE responds                  information from the court’s case management system, for use
synchronously with an acknowledgement of the                 by a Filing Assembly MDE or EFSP for the purpose of electronic
request.                                                     service.

NOTIFY DOCKETING COMPLETE - The Court                        CONCLUSION
Record      MDE       MUST      invoke     the
NotifyDocketingComplete operation on the                     In the following section entitled “Important Links”, we’ve
Filing Review MDE as a callback message to the               provided the information to directly download the full ECF
RecordFiling operation to indicate whether the               specification and correlated documents. As previously stated,
filing was accepted or rejected by the court                 the full specification can appear overwhelming, if referenced in
record system. If the Court Record MDE                       light of the steps outlined here, you should find you can focus
rejected the filing, an explanation MUST be                  only on those sections required for an ECF compliant
provided. If the Court Record MDE accepts the                implementation, and therefore more clearly understand how to
filing, the docketing information MUST be                    piece together your solution. In doing so, you should have an e-
provided. The Filing Review MDE responds                     Filing environment that achieves the purpose of the
synchronously with an acknowledgement of the                 specification in allowing you to integrate with multiple
callback message.                                            applications in a singular and standardized way.

rejects the filings or the Filing Review MDE                 IMPORTANT LINKS
receives the Notify Docketing Complete
message, the Filing Review MDE MUST invoke                   Oasis ECF Technical Committee Web Site
the NotifyFilingReviewComplete on the Filing       

Assembly MDE as a callback message to the
ReviewFiling operation to indicate whether the               Full ECF 4.0 Specification
filing was accepted and docketed by the clerk      
and court record system. The operation MAY
return the filed documents or links to the                   ECF 4.0 Web Services Service Interaction Profile
documents. If the filing included a payment and    
the filing was accepted by the court record
system, a receipt for the payment MUST be                                                                                  PAGE 8

To top