Transcription
7 Steps to Electronic Filing withElectronic Court Filing 4.0The 7 Steps found within this Quick Start Guide will assist you withthe minimum requirements to implement e-Filing with the OASISElectronic Court Filing 4.0 Specification.QUICK START GUIDETHE ECF SPECIFICATION ALLOWS YOU TO: Standardize integration methods in your e-Filing implementation with XML Integrate with any potential e-Filing Service Provider or share e-Filing data betweensystems 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 applicationPREPARED BY:OASIS LegalXML Court Filing Technical CommitteeIn conjunction with the release of the Electronic Court Filing 4.0 Specification
INTRODUCTIONSTEP 1. IDENTIFY E-FILING SERVICE PROVIDER(S)In the software industry today, and especially inthe global justice space, there continues to be astrong movement toward the standardization ofdata definition and exchange methods, and it isoften the desire of administrators andtechnologists throughout federal, state, local,and tribal governments to apply thosestandards. In reality, however, it is oftenoverwhelming to review and fully comprehendthe documentation accompanying thosestandards. This document attempts to minimizethat factor for the OASIS Electronic Court Filing(ECF) specification, and allows the reader tocompletely understand what is required toimplement thespecification in theirenvironment.For those who are unfamiliar with the ECF specification, there iscommon misunderstanding that the specification itself is acomplete e-Filing solution. This is not the case. Rather, ECF isthe solution that allows those systems or entities participatingin the e-Filing process to communicate and exchange data withone another. The primary system utilized to prepare and submitcourt filings electronically is known as an Electronic FilingService Provider or EFSP. Your first step to implementing theECF specification will be to identify at least one EFSP. That’scorrect, at LEAST one EFSP is required, but the ECF specificationallows for multiple EFSPs if desired.While the ECF specification covers a wide rangeof use cases and possible data exchangetransactions, only a small sub-set of thosetransactions are required in order to implementthe specification. In fact, in 7 easy steps we canbreak down the tasks necessary for a fullycompliant ECF implementation.The steps for implementing ECF are:1.2.3.4.5.6.7.Identify e-Filing Service Provider(s)Identify an e-Filing ManagerChoose to implement ECF 4.0Develop your Court PolicyUnderstand MDE’s, Operations, and MessagesChoose a Service Interaction ProfileDevelop and ImplementThat’s it!? But wait a minute, the first two stepshave nothing to do with ECF, do they? In fact,they do. It turns out implementing ECF doeshave at least two prerequisites for an end-toend implementation. There must be 1) a systemthat produces the filing, and 2) a system thatreceives the filing. You will learn more as youread through the 7 easy l-courtfiling/Electronic Filing Service Providers are available to e-Filingimplementers in various forms and fashions, including but notlimited to the following: E-Filing Vendor – several commercial e-Filing systems areavailable in the market place, of which one or more couldbe selected for use in your e-Filing implementation. In House – many courts have developed their own eFiling systems that include an EFSP. System Customization – as an example, documentgeneration software could be customized to allow theuser to automatically generate and submit documents forfiling.Alright, so perhaps Step 1 is not necessarily “easy”, but if youare thinking about implementing e-Filing or the ECFspecification, odds are that you have either already identified anEFSP or have given thought to one of the above options.One of the enormous benefits of utilizing the ECF specification isthat it does not restrict you to a specific EFSP. Any or all of theseEFSPs could be implemented. In fact, utilizing the ECFspecification leaves the implementer’s environment open foradditional EFSP integrations, and it could easily be argued thatthis is necessary in most courts. Even in a single vendor e-Filingimplementation, the court will likely have a need to directlyintegrate with other government agencies (i.e. Prosecutor’soffices, public defender offices, law enforcement offices, lowercourts, appellate courts, among others) allowing them toelectronically file documents with the court directly through theautomated systems of that agency.PAGE 2
As you will learn in Step 4, in ECF specificationterms the EFSP will be responsible for acting asthe Filing Assembly Major Design Element(MDE) and generating the XML core filingmessage, for submission to the court as anelectronic filing.complete an end-to-end e-Filing system. These applicationsinclude a Case Management System (CMS) and a DocumentManagement System (DMS). As with EFSPs and EFMs theseapplications may exist in a variety of formats, but must beconsidered and available to completely process an e-Filingutilizing the ECF specification.STEP 2. IDENTIFY AN E-FILING MANAGERSTEP 3. CHOOSE TO IMPLEMENT ECF 4.0Now that you have an EFSP, the next step is todetermine the manner by which the courtwould like to consume and manage electronicfilings generated by that EFSP. Applicationsimplemented for this purpose are commonlyreferred to as the Electronic Filing Manager orEFM, and often vary widely in the level offunctionality they provide.Now that an EFSP and EFM have been identified, there is a highlikelihood that you will need to choose a method by which toeither integrate those applications with one another, or withothers applications within your e-Filing system. In many cases,multiple components of an e-Filing system exist within the sameapplication and therefore do not require integration with eachother; however it would be extremely rare for ALL componentsof an end-to-end e-Filing system to exist completely within thesame application. As a result, there will be a need for thecomponents of these separate applications to communicatewith one another to fully process an electronic filing.As with EFSPs, Electronic Filing Managers arealso available to e-Filing implementers invarious forms and fashions. In addition, yourselection of an EFM may be highly dependenton what EFSP(s) have been identified.Commercial vendors typically offer what wouldbe considered EFM functions within theirsoftware and may or may not require its useshould you select that vendor’s system. Or, thecourt’s case management system software mayhave built-in EFM capabilities. The court alsohas the option to custom develop their ownEFM software. The beauty of the ECFspecification is that it doesn’t matter which EFMoption you choose, it is designed to work withany of them.WithreferencetoECFspecificationterminology, the EFM will act as the FilingReview MDE and will be responsible forinteracting with the Filing Assembly MDEprovided by the EFSP to communicate theacknowledgement and acceptance of newfilings, and to provide updates on the status ofsaid filings. Specific XML messages have beendefined for this purpose.It is important to also acknowledge that there isan expectation that additional applications willexist in a court’s e-Filing enviroment urtfiling/To further illustrate this point, consider the following examplesof possible e-Filing systems: A vendor provides both your EFSP and EFM, but the Courthosts its own Document Management (DMS) and CaseManagement Systems (CMS). A vendor provides an EFSP, but the Court hosts its ownEFM within its CMS. A Court developed its own EFSP and EFM separate of theCMS and DMS.These examples demonstrate the variety of options that areavailable when constructing an e-Filing system, and that acomplete e-Filing solution will almost always require someintegration points. This integration may be the EFSP and EFMexchanging data with one another, or the EFM communicatingwith external DMS and CMS applications. If we are assumingthis as fact, then we can also assume that a method forintegration between these applications is vital to the success ofa complete e-Filing implementation.This is exactly why the ECF 4.0 specification has come intoexistence. The authors of the specification saw this inevitabletruth, and the need to develop an integration method that isstandardized and repeatable, allowing courts and vendors alikePAGE 3
to develop applications capable of interactingwith multiple external application in a singularway for the purpose of e-Filing. STEP 4. DEVELOP YOUR COURT POLICY Perhaps most important step in implementingthe ECF specification is to define the ECF CourtPolicy. The court policy is integral to the e-Filingprocess as it defines a myriad of requirementsthe Filing Assembly MDE must consider. Indefining a court policy, the Court must giveconsiderable thought to exactly howcomprehensive an e-Filing application it wishesto implement. Will it include a single or multiplecase type, allow for electronic service, orprovide access to other case documents?Answers to these questions should be definedin the court policy.Additionally, the Court will need to determinehow e-Filed documents will be “signed” anddefine a document signature profile. The ECFspecification allows for digital signatures andXML signatures, among others, or in theabsence of more formal signature technologiesa “null” signature profile. Most courts havefound it perfectly acceptable to implement thenull signature profile along with a “/s/ FilerName” on the document signature line, as, incombination with the e-Filing process itself, itdemonstrates the intent to sign and file.Further demonstrating the importance of courtpolicy, it will define codes associated withspecific courts, or code lists an EFSP might berequired to use to associate data it is submittingwithin the core filing message. Courts arerequired to provide their court policy in twoformats; 1) Human-Readable, and 2) MachineReadable.Human-Readable Court Policy is a textualdocument publishing the court’s rules andrequirements for electronic filing. To becompliant with the ECF 4.0 specification, eachcourt MUST publish a human-readable courtpolicy that MUST include each of the alxml-courtfiling/ The unique court identifier.The location of the machine-readable court policy.A definition of what constitutes a “lead document” in thecourt.A description of how the filingPartyID and filingAttorneyID are to be maintained during electroniccommunications regarding the case.A description of how the court processes (dockets) matters.A description of any instances in which the court willmandate an element that the ECF 4.0 schema makesoptional.A description of any restrictions to data property valuesother than code list restrictions.Any other rules required for electronic filing in the court.Machine-Readable Court Policy is an ECF 4.0 message thatdescribes the features of the ECF 4.0 implementation supportedby the implementing court, the court’s code lists, and any otherinformation a Filing Assembly MDE would need to know inorder to electronically file successfully into that court. Machinereadable court Policy includes structures for identifying runtime and development-time policy information.Run-time information includes information that will be updatedfrom time to time, such as code lists (e.g., acceptable documenttypes, codes for various criminal charges, and civil causes ofaction) and the court’s public key for digital signatures andencryption.Development-time information includes court rules governingelectronic filing that are needed at the time an application isdeveloped but which are not likely to change. These include: The service interaction profile(s) that the court supports(see step 6).The MDEs, query operations and case types supported bythe court’s ECF 4.0 system.Whether a court will accept the filing of a URL in lieu of theelectronic document itself.Whether the court accepts documents requiring payment ofa filing fee.Whether the court accepts electronic filing of sealeddocuments.Whether the court accepts multiple (batch) filings.The court-specific extensions to the ECF 4.0 specification,including the required elements.The maximum sizes allowed for a single attachment and acomplete message stream.PAGE 4
Thankfully, implementing courts don’t have tostress over how to format their machinereadable court policy, as the ECF specificationprovides the xml structure to be used. Here’s ashort snippet as an example: j:CaseCourt nc:OrganizationIdentification nc:IdentificationID ESS-SC /nc:IdentificationID /nc:OrganizationIdentification j:CourtName Essex Superior Court /j:CourtName /j:CaseCourt Self explanatory, right? To those familiar withXML it should be, and to those who have neverseen XML it should seem clear that the court’sID is “ESS-SC” and the court’s name is “EssexSuperior Court”. The rest of the XML defined inthe ECF Court Policy Response Message issimilar.Court Policy TipWrite your Human-Readable court policy and completely defineall the requirements with all the elements described above withinthat policy, then work with your technical team members totranslate that policy into the Machine-Readable XML version.STEP 5. UNDERSTAND MDE’S, OPERATIONS,AND MESSAGES2.The Filing Review MDE will generate, the Court Policy ResponseMessage, the Record Docketing Message, the Review Filing CallbackMessage, and initiate the Record Filing and Notify Filing ReviewComplete operations.3.The Court Record MDE will generate the Record Docketing CallbackMessage and initiate the Notify Docketing Complete operation.4.For each message initiated, the receiving MDE shall generate theMessage Receipt Message synchronously.This means that in terms of mapping data to the ECF messageschemas, the majority of the work will occur in these sevenmessages defined in the purple text. The specification providesdetailed schemas for each message, so that task is simplydetermining where to insert the data your implementationrequires within the schema. Let’s look at an example and codesnippet from each message.The CourtPolicyQueryMessage is a simple message generatedby the Filing Assembly MDE to get the requirements of thecourt it is attempting to file in. The key to this transaction forthe court is knowing which Filing Assembly MDE is making therequest, therefore the query message defines the requestor.Here’s a snippet: ecf:QuerySubmitter ecf:EntityPerson nc:PersonOtherIdentification nc:IdentificationID 1 /nc:IdentificationID nc:IdentificationCategoryText Vendor A /nc:IdentificationCategoryText /nc:PersonOtherIdentification /ecf:EntityPerson /ecf:QuerySubmitter Perhaps the hardest step in implementing theECF specification is understanding the processflow and its components, then correctlymapping the data the court finds necessary toprocess a filing with the XML schemas providedby the ECF specification. Gaining thisunderstanding of minimum requirements forECF should help tremendously. There areliterally only three MDE’s (in green), sevenmessage interactions (in purple), and fiveoperations (in blue) required to implement afully compliant ECF e-Filing solution, and arebriefly described here.In this example, the court assigned ID, “1”, is defined as well asa textual description, “Vendor A”, so that the court knows whoto respond to with the CourtPolicyResponseMessage. In termsof mapping this indicates the court will need to assign an ID foreach EFSP, and map that ID to these data elements in preparingfor implementation. Here’s a snippet of the court’s response:1.This court policy response indicates that currently the court isonly accepting filings in the Civil case type, where filing fees maybe applicable, and effective 8/1/2008. This demonstrates clearlyThe Filing Assembly MDE will generate the CourtPolicy Query Message, Core Filing Message initiatethe Get Policy and Review Filing alxml-courtfiling/ DevelopmentPolicyParameters SupportedCaseType Civil /SupportedCaseType FilingFeesMayBeApplicableIndicator true /FilingFeesMayBeApplicableIndicator EffectiveDate nc:Date 2008-08-01 /nc:Date /EffectiveDate /DevelopmentPolicyParameters PAGE 5
how the court will map the case types for whichit will allow e-Filing to occur within the courtPolicy message.In this case, the Filing Assembly MDE now hasthe knowledge that it may generate aCoreFilingMessage for civil filings. In thatmessage, it will define the document(s) to befiled. Here’s a snippet of the message: FilingLeadDocument s:id "MotionToContinue.doc" nc:DocumentApplicationName Microsoft Word /nc:DocumentApplicationName nc:DocumentDescriptionText Motion to Continue /nc:DocumentDescriptionText nc:DocumentLanguageCode eng /nc:DocumentLanguageCode /FilingLeadDocument In this small snippet, we see that the documentdefined in this filing is a “Motion to Continue”,it is the lead document, and it can be identifiedby the file name of “MotionToContinue.doc”.The Filing Review MDE should immediatelyrespond to the submission of theCoreFilingMessagewithaMessageReceiptMessage. The majority of thismessage repeats information provided by thesubmitter, but the important piece will indicatewhether or not the message was received.Here’s a snippet: message:Error message:ErrorCode 0 /message:ErrorCode message:ErrorText No error /message:ErrorText /message:Error In the sample above, a code of “0” wasreturned indicating no errors occurred and thefiling was received by the Filing Review MDE.The court will need to define a set of errorcodes for use in this message, and descriptionsfor each code, then map them to this message.Once a determination has been made, either byautomation or through manual intervention andreview that the filing is good and will beaccepted, the Filing Review MDE will initiatetheRecord Filing operation with ourtfiling/RecordDocketingMessage. This message should define the filingin a way that allows the Court Record MDE to fully process itand respond. Here’s a snippet of that definition: ecf:DocumentMetadata j:RegisterActionDescriptionText MOT /j:RegisterActionDescriptionText ecf:FilingAttorneyID nc:IdentificationID 562455 /nc:IdentificationID /ecf:FilingAttorneyID /ecf:DocumentMetadata The snippet here show’s that the document has now beendefined for specific data elements that will be recorded by theCourt Record MDE, likely in the CMS and DMS. In this case“MOT” represents a code within the system for Motion, and the“562455” represents the state bar number of the attorney filingthe document.Once the Court Record MDE completes processing, it willinitiate the Notify Docketing Complete operation and sendRecordDocketingCallbackMessage to the Filing Review MDE.This message will contain the following snippet: nc:DocumentPostDate nc:DateTime 2007-06-06T14:20:46.0Z /nc:DateTime /nc:DocumentPostDate ecf:FilingStatus nc:StatusDescriptionText Without modification /nc:StatusDescriptionText ecf:FilingStatusCode Docketed /ecf:FilingStatusCode /ecf:FilingStatus In this instance, the Filing Review MDE now becomes awarethat the document has been fully “Docketed”, “WithoutModification”, at “14:20:46” on “6/6/2007”. A mapping effortwill need to occur so that data relevant to the court’s CMS ispositioned correctly within this schema.This information can now be relayed full circle by the FilingReview MDE to the Filing Assembly MDE with CallbackMessage. This message will confirm thestatus of the filing for the Filing Assembly MDE and wouldcontain the following snippet: nc:DocumentFileDate nc:DateTime 2007-06-06T14:20:46.0Z /nc:DateTime /nc:DocumentFileDate ecf:FilingStatus nc:StatusDescriptionText Without modification /nc:StatusDescriptionText ecf:FilingStatusCode Accepted /ecf:FilingStatusCode /ecf:FilingStatus PAGE 6
With this information the Filing Assembly MDEcan now update any data in the EFSP and notifythe filer to indicate the document was“Accepted” by the court on “8/13/2007”,“Without Modification”.This brief narration of the events, operations,and messages should demonstrate that whilethe ECF specification may appear complex, inreality the process is simple, and the messagesare basic in nature. Mapping the data utilized inyour systems to the ECF message schemas willbe extremely important, especially whenattempting to avoid confusion between systemson the meaning of an error code or statusdescription.STEP 6. CHOOSE A SERVICE INTERACTIONPROFILEusing the specifications described in the Web ServicesInteroperability (WS-I) Basic Profile 1.1, and WS-I Basic SecurityProfile 1.0 To utilize the web services profile, it simply requiresthat the appropriate web services be developed and madeavailable for each MDE for the purpose of initiating each of therequired operations, and submitting messages for consumption.The Media Service Interaction Profile 1.0 specification defines atransmission system in which the sending MDE stores messagetransmissions on portable media (e.g., a compact disc) which isthen physically transported to the receiving MDE where it isconnected for retrieval of the message transmissions. Thisspecification may be needed in the absence of an activenetwork between the sending and receiving MDEs. While this isnot the most popular SIP, it is a viable SIP that could accomplishthe tasks involved in completely processing e-Filings. Therecommendation for this SIP, however, would be that it only beused in emergency situations or perhaps in those situationswhere bulk filing may occur.With an understanding of the overall processflow and its components in place, the system isnow in need of a method by with thesecomponents will communicate and exchangemessages. The ECF specification defines thismethod as the Service Interaction Profile orSIP.If neither of these approved SIPs makes sense for yourenvironment, it is highly recommended that you define anddevelop your own SIP for implementation, and submit the SIP tothe OASIS ECF technical committee for approval as aspecification.An ECF 4.0 SIP defines a transmission systemthat supports the functional requirements ofelectronic filing and the MDE operations andmessage structures, and implements certainnon-functional requirements, but does notgovern the content of messages. A serviceinteraction profile will define how a messagegets from the sending MDE to the receivingMDE in a given messaging framework.Finally, all the pieces are in place to get to work. We’veidentified our EFSP(s) and EFM, we know we are going to usethe ECF 4.0 specification, we understand the specification andthe concept of MDE’s and the specification’s use of operationsand messages, and we have selected a SIP that will allow thecomponents to communicate with one another. This shouldnow allow you to set a course to develop and implement youre-Filing solution. As always, the development andimplementation process will be highly dependent upon thechoices you have made, but in an overall sense, you will need tosupport the following operations.GET POLICY - The Filing Assembly MDE MAY obtain a court’smachine-readable court policy at any time by invoking theGetPolicy operation on the Filing Review MDE with theidentifier for the court. The Filing Review MDE returns themachine-readable court policy in a synchronous response. Thisstep may be omitted if the Filing Assembly MDE already has thecurrent court policy.The ECF technical committee has currentlydefined and accepted two possible SIPs thatmay be used in compliance with the ECFspecification. This does not, however, precludean implementer from defining and developingtheir own SIP for consideration and acceptanceinto the specification.STEP 7. DEVELOP AND IMPLEMENTThe Web Services Service Interaction Profile2.0 specification defines a transmission l-courtfiling/PAGE 7
REVIEW FILING - The Filing Assembly MDEMUST submit the filing to the court by invokingthe ReviewFiling operation on the Filing ReviewMDE. The ReviewFiling operation includesmessages for the core filing, for case on, and for the filing payment. TheFiling Review MDE responds synchronously witha receipt message that includes the filingidentifier issued by the court.RECORD FILING - If the clerk reviews andaccepts the filing, the Filing Review MDE MUSTinvoke the RecordFiling operation on the CourtRecord MDE.The RecordFiling operationincludes information from the ReviewFilingoperation with any modifications or commentsby the clerk. The Court Record MDE respondssynchronously with an acknowledgement of therequest.NOTIFY DOCKETING COMPLETE - The CourtRecordMDEMUSTinvoketheNotifyDocketingComplete operation on theFiling Review MDE as a callback message to theRecordFiling operation to indicate whether thefiling was accepted or rejected by the courtrecord system. If the Court Record MDErejected the filing, an explanation MUST beprovided. If the Court Record MDE accepts thefiling, the docketing information MUST beprovided. The Filing Review MDE respondssynchronously with an acknowledgement of thecallback message.NOTIFY FILING REVIEW COMPLETE - If the courtrejects the filings or the Filing Review MDEreceives the Notify Docketing Completemessage, the Filing Review MDE MUST invokethe NotifyFilingReviewComplete on the FilingAssembly MDE as a callback message to theReviewFiling operation to indicate whether thefiling was accepted and docketed by the clerkand court record system. The operation MAYreturn the filed documents or links to thedocuments. If the filing included a payment andthe filing was accepted by the court recordsystem, a receipt for the payment MUST urtfiling/included in the operation. The Filing Assembly MDE respondssynchronously with an acknowledgement of the callbackmessage.LEGAL SERVICE MDEMany would argue that an e-Filing implementation without theability to electronically serve your pleadings as part of theelectronic filing process is, in essence, an incomplete solution.There is validity to this argument, and it should be consideredstrongly as you plan for your e-Filing implementation. From theperspective of the ECF specification, it is important to note, thatwhile implementing legal service is not a requirement of thespecification it is sufficiently accounted for within thespecification with the Legal Service MDE. In short, the LegalService MDE allows an implementer to publish a base servicelist, which would be typically populated with party and attorneyinformation from the court’s case management system, for useby a Filing Assembly MDE or EFSP for the purpose of electronicservice.CONCLUSIONIn the following section entitled “Important Links”, we’veprovided the information to directly download the full ECFspecification and correlated documents. As previously stated,the full specification can appear overwhelming, if referenced inlight of the steps outlined here, you should find you can focusonly on those sections required for an ECF compliantimplementation, and therefore more clearly understand how topiece together your solution. In doing so, you should have an eFiling environment that achieves the purpose of thespecification in allowing you to integrate with multipleapplications in a singular and standardized way.IMPORTANT LINKSOasis ECF Technical Committee Web courtfiling/Full ECF 4.0 ec-cd01.zipECF 4.0 Web Services Service Interaction 4.0-webservices-spec-cd01.zipPAGE 8
software and may or may not require its use should you select that vendor's system. Or, the court's case management system software may have built-in EFM capabilities. The court also has the option to custom develop their own EFM software. The beauty of the ECF specification is that it doesn't matter which EFM
